Re: CIFS mount: 3.2.0-rc3 suspend crash

["Srivatsa S. Bhat" <srivatsa.bhat-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>]

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