netdev - Re: CIFS mount: 3.2.0-rc3 suspend crash

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4EDD08D0.9030401@linux.vnet.ibm.com>
Date:	Mon, 05 Dec 2011 23:39:20 +0530
From:	"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>
To:	Tejun Heo <tj@...nel.org>
CC:	Woody Suwalski <terraluna977@...il.com>,
	Jeff Layton <jlayton@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linux PM mailing list <linux-pm@...r.kernel.org>,
	Belisko Marek <marek.belisko@...il.com>,
	linux-cifs@...r.kernel.org,
	Network Development <netdev@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...e.de>, davem@...emloft.net
Subject: Re: CIFS mount: 3.2.0-rc3 suspend crash

On 12/05/2011 11:11 PM, Tejun Heo wrote:

> Hello, Srivatsa.
> 
> On Fri, Dec 02, 2011 at 06:19:04PM +0530, Srivatsa S. Bhat wrote:
>> So how about solving this problem more fundamentally, such as defining a
>> freezable wrapper over kernel_recvmsg like:
>>
>> #define kernel_recvmsg_freezable(sock, msg, vec, num, size, flags)      \
>> ({                                                                      \
>>         kernel_recvmsg(sock, msg, vec, num, size, flags)                \
>> 	try_to_freeze();                                                \
>> })
>>
>> and using it instead of kernel_recvmsg(), throughout the kernel?
>>
>> But kernel_recvmsg is an exported symbol. So if we are very very unwilling
>> to change the kernel ABI, we could probably think about adding try_to_freeze()
>> inside kernel_recvmsg itself,like this (but see below about my thoughts about
>> which one is better):
> 
> I don't necessarily object to introducing the wrapper but I don't
> really think we should be doing s//g over the source tree without
> understanding where it's actually necessary.  For kernel threads and
> user threads out of the signal delivery path, try_to_freeze() is an
> exceptional event which introduces behavior which can be difficult to
> reproduce track down and spreading it without actually knowing what
> the surrounding code is doing doesn't sound like a good idea to me.
> 


Yeah, I agree. But I remember seeing almost _exactly_ the same code
as CIFS loop in some other place. I'll see if I can track it down and
also understand if it might cause problems. If I find it to be worth it
to use the same solution as above, I'll try adding the wrapper and using
it there. Else, better to keep it as it is, as you mentioned. Thank you.

Regards,
Srivatsa S. Bhat

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html