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] [day] [month] [year] [list]
Date:	Mon, 5 Dec 2011 12:31:12 -0600
From:	Steve French <smfrench@...il.com>
To:	"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>
Cc:	Tejun Heo <tj@...nel.org>, 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 Mon, Dec 5, 2011 at 12:09 PM, Srivatsa S. Bhat
<srivatsa.bhat@...ux.vnet.ibm.com> wrote:
> 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.

Agreed ...


-- 
Thanks,

Steve
--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ