Re: CIFS lockup regression on SMB1 in 6.10

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

 



Sorry it's taken me a few to get back to this, vacation weekend delays. The bisect was not as helpful as I would have thought, due to being stuck with too many "git bisect skip". Seems there was some other bug causing OOPSen in the CIFS code, which happened to overlap the sequence of commits that were near our bug. The bisect results, for what they're worth, are:

	There are only 'skip'ped commits left to test.
	The first bad commit could be any of:
	1a5b4edd97cee40922ca8bfb91008338d3a1de60
	dc5939de82f149633d6ec1c403003538442ec9ef
	3758c485f6c9124d8ad76b88382004cbc28a0892
	56257334e8e0075515aedc44044a5585dcf7f465
	ab58fbdeebc7f9fe8b9bc202660eae3a10e5e678
	edea94a69730b74a8867bbafe742c3fc4e580722
	a975a2f22cdce7ec0c678ce8d73d2f6616cb281c
	c20c0d7325abd9a8bf985a934591d75d514a3d4d
	69c3c023af25edb5433a2db824d3e7cc328f0183
	753b67eb630db34e36ec4ae1e86c75e243ea4fc9
	3ee1a1fc39819906f04d6c62c180e760cd3a689d
	We cannot bisect more!

The OOPS messages from the (unrelated?) bug were:

	refcount_t: underflow; use-after-free.
	...
	? refcount_warn_saturate+0xd9/0xe0
	? report_bug+0x11d/0x160
	? handle_bug+0x36/0x70
	? exc_invalid_op+0x1f/0x90
	? asm_exc_invalid_op+0x16/0x20
	? refcount_warn_saturate+0xd9/0xe0
	? refcount_warn_saturate+0xd9/0xe0
	cifs_readahead_complete+0x2db/0x300 [cifs]
	process_one_work+0x13e/0x240
	worker_thread+0x31a/0x460
	? rescuer_thread+0x480/0x480
	kthread+0xc6/0xf0
	? kthread_complete_and_exit+0x20/0x20
	ret_from_fork+0x44/0x50
	? kthread_complete_and_exit+0x20/0x20
	ret_from_fork_asm+0x11/0x20

I have not yet tried David Howells' patch.  Will give that a whirl next.

Kris


Steve French wrote:
Let me know if any luck narrowing down the culprit

On Mon, Sep 2, 2024 at 11:56 PM matoro wrote:
Kris, a bisesct attempt would be immensely helpful.  My attempt failed as
there were other unrelated problems in the commit range which caused my test
reproducer (compiling python) to fail, but your reproducer seems much more
reliable (reading images).  Could you please take a crack at it and see what
turns up?  I think that's probably the only way to get upstream to take up
our case.




[Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux