public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: "Ma, Xindong" <xindong.ma@intel.com>
Cc: "akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"oleg@redhat.com" <oleg@redhat.com>,
	"mhocko@suse.cz" <mhocko@suse.cz>,
	"mingo@kernel.org" <mingo@kernel.org>,
	"peterz@infradead.org" <peterz@infradead.org>,
	"riel@redhat.com" <riel@redhat.com>,
	"ionut.m.alexa@gmail.com" <ionut.m.alexa@gmail.com>,
	"peter@hurleysoftware.com" <peter@hurleysoftware.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Zhang, Di" <di.zhang@intel.com>,
	"Sun, Zhonghua" <zhonghua.sun@intel.com>
Subject: Re: [PATCH] move exit_task_work() before exit_fs().
Date: Mon, 29 Dec 2014 02:18:40 +0000	[thread overview]
Message-ID: <20141229021839.GK22149@ZenIV.linux.org.uk> (raw)
In-Reply-To: <3917C05D9F83184EAA45CE249FF1B1DD0266FC80@SHSMSX103.ccr.corp.intel.com>

On Mon, Dec 29, 2014 at 01:33:37AM +0000, Ma, Xindong wrote:
> > On Fri, Dec 26, 2014 at 03:45:25PM +0800, Leon Ma wrote:
> > > We encountered following panic. The scenario is the process is exiting
> > > and executing its task work. When closing dev node, the driver
> > > triggers a firmware reload according to device status. Because task->fs is
> > set to NULL in exit_fs(), panic happens.
> > > Task work is a common interface, we should not limite the resource the
> > user will utilize.
> > 
> > Fix your driver.  Forget ->fs being NULL; what will happen if your process is
> > chrooted?
> Thanks, But I'm not clear what is the limitation added to chroot env?

???

How about "the pathname of firmware apparently will be looked up inside the
chroot"?  Look, this is completely broken - you *can't* assume anything about
the fs context in which ->release() will be run, period.  It's not guaranteed
to have anything in common with the environment in which the file had been
opened, BTW - there might literally be not a single filesystem in common for
both.

This "reload firmware in ->release()" is absolutely braindead.  The fact that
it as much as dereferences current->fs demonstrates that it's broken.  Don't
do that.

      reply	other threads:[~2014-12-29  2:18 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-26  7:45 [PATCH] move exit_task_work() before exit_fs() Leon Ma
2014-12-26 17:38 ` Oleg Nesterov
2014-12-29  0:58   ` Ma, Xindong
2014-12-29  1:09     ` Peter Hurley
2014-12-29  1:32       ` Ma, Xindong
2014-12-26 19:30 ` Al Viro
2014-12-29  1:33   ` Ma, Xindong
2014-12-29  2:18     ` Al Viro [this message]

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=20141229021839.GK22149@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=akpm@linux-foundation.org \
    --cc=di.zhang@intel.com \
    --cc=ionut.m.alexa@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhocko@suse.cz \
    --cc=mingo@kernel.org \
    --cc=oleg@redhat.com \
    --cc=peter@hurleysoftware.com \
    --cc=peterz@infradead.org \
    --cc=riel@redhat.com \
    --cc=xindong.ma@intel.com \
    --cc=zhonghua.sun@intel.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox