[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#682007: [squeeze-backports] NULL pointer dereference in __fscache_read_or_alloc_pages

Jonathan Nieder <jrnieder@gmail.com> 2012-07-21 12:04:

tags 682007 + upstream patch moreinfo
quit

Hi,

Brian Kroth wrote:


kernel BUG at /build/buildd-linux_3.2.20-1~bpo60+1-amd64-tQMw4f/linux-3.2.20/fs/buffer.c:3088!


This is

		BUG_ON(!PagePrivate(page));                     \

in

	static int
	drop_buffers(struct page *page, struct buffer_head **buffers_to_free)
	{
		struct buffer_head *head = page_buffers(page);

I suspect it's the same underlying problem, but maybe not.

Please test the attached patches, for example following the instructions
below:

0. prerequisites:

	apt-get install git build-essential

1. get the kernel history, if you don't already have it:

	git clone \
	  git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
I take it then that this is a patch against the latest greatest kernel, not against the source for the backports kernel I'm currently running? 


2. configure, build, test:

	cd linux
	git fetch origin
	git checkout origin/master

	cp /boot/config-$(uname -r) .config; # current configuration
	scripts/config --disable DEBUG_INFO
	make localmodconfig; # optional: minimize configuration
	make deb-pkg; # optionally with -j<num> for parallel build
	dpkg -i ../<name of package>; # as root
	reboot
	... test test test ...

  Hopefully it reproduces the bug.  So
Oh, I see you want to compare two nearly identical kernels (both fairly recent) to isolate if just the patches are helpful rather than some mix between the two. 


3. try the patches:

	cd linux
	git am -3sc $(ls -1 /path/to/patches/[01]*)
	make deb-pkg; # maybe with -j4
	dpkg -i ../<name of package>; # as root
	reboot
	... test test test ...

Thanks and hope that helps,
Jonathan
I can try and build/install this on one of our machines (I'd prefer not to push it everywhere yet), but without a reliably reproducible (on-demand that is) test case I'm not sure what it will show except that it perhaps doesn't introduce further blatant bugs.
Anyways, I'll wait on the results of my previous test first to see if we have a reliable test case from it before moving forward.
At this point the grep -r abc ... test is just hitting the cache over and over again, so it's not showing a whole lot.
One other thing I'd tried before was something like this run a couple of times in a row (hmm, I suppose I could try them in parallel too): 

find /fsc_mounted_nfs -type f -exec cat {} > /dev/null \;
A couple of them paniced, but with inconsistent messages, so I had left them out for now. Perhaps that's worth another shot ... 

Thanks,
Brian

Attachment: signature.asc
Description: Digital signature

Reply to: