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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 5 Dec 2011 09:41:26 -0800
From:	Tejun Heo <tj@...nel.org>
To:	"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>
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

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.

Thank you.

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