All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
To: "Srivatsa S. Bhat"
	<srivatsa.bhat-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Cc: Woody Suwalski
	<terraluna977-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org>,
	Linux PM mailing list
	<linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Belisko Marek
	<marek.belisko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Network Development
	<netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Greg Kroah-Hartman <gregkh-l3A5Bk7waGM@public.gmane.org>,
	davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org
Subject: Re: CIFS mount: 3.2.0-rc3 suspend crash
Date: Mon, 5 Dec 2011 09:41:26 -0800	[thread overview]
Message-ID: <20111205174126.GF627@google.com> (raw)
In-Reply-To: <4ED8C940.20509-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>

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

WARNING: multiple messages have this Message-ID (diff)
From: Tejun Heo <tj@kernel.org>
To: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
Cc: Woody Suwalski <terraluna977@gmail.com>,
	Jeff Layton <jlayton@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>,
	"Rafael J. Wysocki" <rjw@sisk.pl>,
	Linux PM mailing list <linux-pm@vger.kernel.org>,
	Belisko Marek <marek.belisko@gmail.com>,
	linux-cifs@vger.kernel.org,
	Network Development <netdev@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	davem@davemloft.net
Subject: Re: CIFS mount: 3.2.0-rc3 suspend crash
Date: Mon, 5 Dec 2011 09:41:26 -0800	[thread overview]
Message-ID: <20111205174126.GF627@google.com> (raw)
In-Reply-To: <4ED8C940.20509@linux.vnet.ibm.com>

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

  parent reply	other threads:[~2011-12-05 17:41 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-29 23:34 CIFS mount: 3.2.0-rc3 suspend crash Woody Suwalski
2011-11-30  5:33 ` Srivatsa S. Bhat
2011-11-30 11:25   ` Jeff Layton
2011-11-30 22:34     ` Woody Suwalski
     [not found]       ` <4ED6AF7B.9090101-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2011-12-01 11:33         ` Jeff Layton
2011-12-01 11:33           ` Jeff Layton
     [not found]           ` <20111201063315.5aa68bd4-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
2011-12-01 17:11             ` Srivatsa S. Bhat
2011-12-01 17:11               ` Srivatsa S. Bhat
     [not found]               ` <4ED7B55F.5010703-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2011-12-01 17:30                 ` Srivatsa S. Bhat
2011-12-01 17:30                   ` Srivatsa S. Bhat
     [not found]                   ` <4ED7B9A0.7060900-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2011-12-01 18:17                     ` Srivatsa S. Bhat
2011-12-01 18:17                       ` Srivatsa S. Bhat
     [not found]                       ` <4ED7C49D.4090902-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2011-12-01 18:59                         ` Jeff Layton
2011-12-01 18:59                           ` Jeff Layton
     [not found]                           ` <20111201135932.4bca20bb-xSBYVWDuneFaJnirhKH9O4GKTjYczspe@public.gmane.org>
2011-12-01 20:10                             ` Srivatsa S. Bhat
2011-12-01 20:10                               ` Srivatsa S. Bhat
     [not found]                               ` <4ED7DF48.3050402-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2011-12-01 21:01                                 ` Jeff Layton
2011-12-01 21:01                                   ` Jeff Layton
2011-12-01 22:32                     ` Steve French
2011-12-01 22:32                       ` Steve French
     [not found]                       ` <CAH2r5mvwAzgqCggwRQuhSbCBM2NGeao_hqPFjNyW5yqr_48zSA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-12-01 23:15                         ` Woody Suwalski
2011-12-01 23:15                           ` Woody Suwalski
     [not found]     ` <20111130062502.68d9db59-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
2011-12-01 23:40       ` Woody Suwalski
2011-12-01 23:40         ` Woody Suwalski
2011-12-02 12:49         ` Srivatsa S. Bhat
     [not found]           ` <4ED8C940.20509-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2011-12-05 17:41             ` Tejun Heo [this message]
2011-12-05 17:41               ` Tejun Heo
     [not found]               ` <20111205174126.GF627-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2011-12-05 18:09                 ` Srivatsa S. Bhat
2011-12-05 18:09                   ` Srivatsa S. Bhat
     [not found]                   ` <4EDD08D0.9030401-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2011-12-05 18:31                     ` Steve French
2011-12-05 18:31                       ` Steve French
2011-12-06 21:33       ` Rafael J. Wysocki
2011-12-06 21:33         ` Rafael J. Wysocki
     [not found]         ` <201112062233.50317.rjw-KKrjLPT3xs0@public.gmane.org>
2011-12-06 21:38           ` Jeff Layton
2011-12-06 21:38             ` Jeff Layton
     [not found]             ` <20111206163810.24663e3f-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
2011-12-07  2:57               ` Steve French
2011-12-07  2:57                 ` Steve French
2011-12-07  3:45             ` Srivatsa S. Bhat

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20111205174126.GF627@google.com \
    --to=tj-dgejt+ai2ygdnm+yrofe0a@public.gmane.org \
    --cc=davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org \
    --cc=gregkh-l3A5Bk7waGM@public.gmane.org \
    --cc=jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=marek.belisko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=rjw-KKrjLPT3xs0@public.gmane.org \
    --cc=srivatsa.bhat-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org \
    --cc=terraluna977-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.