linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: "Bruno Prémont" <bonbons@linux-vserver.org>,
	"Greg KH" <gregkh@linuxfoundation.org>,
	"Peter Zijlstra" <peterz@infradead.org>,
	linux-kernel@vger.kernel.org,
	"Linus Torvalds" <torvalds@linux-foundation.org>
Subject: Re: [PATCH] Prevent crash on missing sysfs attribute group
Date: Tue, 3 Apr 2012 09:15:43 +0200	[thread overview]
Message-ID: <20120403071543.GA17502@gmail.com> (raw)
In-Reply-To: <m1d37pgugy.fsf@fess.ebiederm.org>


* Eric W. Biederman <ebiederm@xmission.com> wrote:

> Nacked-by: "Eric W. Biederman" <ebiederm@xmission.com>
> 
> Bruno Prémont <bonbons@linux-vserver.org> writes:
> 
> > Prevent kernel from crashing when a device is being registered with sysfs
> > but has no (aka NULL) group attributes, but warn about it so calling path
> > can get fixed.
> 
> The idea is reasonable but the implementation is horrible.
> 
> >> Will do - but the underlying generic bug should be fixed as 
> >> well: we must not crash just because some attributes are missing 
> >> in a rarely used sub-driver ...
> >> 
> >> We should WARN_ON(), etc. - but not crash.
> 
> FIX perf to include sanity checks.

Huh, so put repeated, duplicated, inconsistently applied sanity 
checks into dozens of sysfs attribute using kernel subsystems?

Major FAIL, dude.

> Anything we do in sysfs is just pointless because perf was 
> clever and the offender did not show up in the backtrace.
> 
> Right now perf is so bad we just waste everyone's time.
>
> > Greg, is this ok for you or should the check be moved out to 
> > calling internal_create_group()?
> 
> Please put changes in internal_create_group where all of the 
> rest of the checks are.

So you *do* agree that a check in a generic place is useful 
after all? ;-)

> We should do something like:
> if (!grp->attrs) {
> 	WARN(1, "sysfs: idiot subsystem did not include attrs for group: %s/%s\n"
>         	kobj->name, grp->name?"":grp->name);
> 	return -EINVAL;
> }
>
> As it stands your patch is horrible it leaves sysfs in an 
> inconsistent state.  Creating the directory and leaving it 
> there.  Not returning an error code.  It looks like there are 
> all kinds of weird problems that removing the group or 
> updating the group could get into if we go with your patch.

This is actually a sensible suggestion. Bruno, mind updating 
your patch to do something like this? Assuming Greg agrees with 
putting the check/warning there.

Eric's rant about putting sanit checks at every usage site is 
just crazy talk.

Thanks,

	Ingo

  reply	other threads:[~2012-04-03  7:15 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-02 14:27 [3.4-rc1 crash]: NULL pointer deref in fs/sysfs/group.c:create_files -- sysctl related? Bruno Prémont
2012-04-02 14:50 ` Bruno Prémont
2012-04-02 19:01   ` Eric W. Biederman
2012-04-02 19:34     ` Bruno Prémont
2012-04-02 20:04       ` David Ahern
2012-04-03  8:30         ` Jiri Olsa
2012-04-02 21:24       ` Peter Zijlstra
2012-04-02 21:46         ` Peter Zijlstra
2012-04-03  5:38           ` Bruno Prémont
2012-04-03  6:02           ` Ingo Molnar
2012-04-03  6:17             ` [PATCH] Prevent crash on missing sysfs attribute group Bruno Prémont
2012-04-03  6:31               ` Ingo Molnar
2012-04-03  7:11               ` Eric W. Biederman
2012-04-03  7:15                 ` Ingo Molnar [this message]
2012-04-03  7:41                   ` [PATCH v2] Prevent crash on unset sysfs group attributes Bruno Prémont
2012-04-03  7:51                     ` Eric W. Biederman
2012-04-03  7:53                     ` Ingo Molnar
2012-04-03  7:59                     ` [PATCH v2a] sysfs: " Bruno Prémont
2012-04-03  8:06                       ` Ingo Molnar
2012-04-03  7:50                   ` [PATCH] Prevent crash on missing sysfs attribute group Eric W. Biederman
2012-04-03  8:04                     ` Ingo Molnar
2012-04-03  8:52                       ` Eric W. Biederman
2012-04-03 10:16                         ` Ingo Molnar
2012-04-03 10:46                           ` Eric W. Biederman
2012-04-03 22:34                             ` Ingo Molnar
2012-04-03 14:27                     ` Peter Zijlstra
2012-04-03 23:22                       ` Eric W. Biederman
2012-04-03 23:26                         ` Greg KH

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=20120403071543.GA17502@gmail.com \
    --to=mingo@kernel.org \
    --cc=bonbons@linux-vserver.org \
    --cc=ebiederm@xmission.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).