public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dtor_core@ameritech.net>
To: Greg KH <greg@kroah.com>
Cc: Linus Torvalds <torvalds@osdl.org>,
	Chuck Ebbert <76306.1226@compuserve.com>,
	Andrew Morton <akpm@osdl.org>, Ingo Molnar <mingo@elte.hu>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: Fw: Re: oops in choose_configuration()
Date: Tue, 7 Mar 2006 22:22:10 -0500	[thread overview]
Message-ID: <200603072222.11504.dtor_core@ameritech.net> (raw)
In-Reply-To: <20060308012744.GA24739@kroah.com>

On Tuesday 07 March 2006 20:27, Greg KH wrote:
> On Tue, Mar 07, 2006 at 08:13:28PM -0500, Dmitry Torokhov wrote:
> > On Tuesday 07 March 2006 19:57, Linus Torvalds wrote:
> > > 
> > > On Tue, 7 Mar 2006, Chuck Ebbert wrote:
> > > > 
> > > > At least one susbsystem rolls its own method of adding env vars to the
> > > > uevent buffer, and it's so broken it triggers the WARN_ON() in
> > > > lib/vsprintf.c::vsnprintf() by passing a negative length to that function.
> > > 
> > > Well, snprintf() should be safe, though. It will warn if the caller is 
> > > lazy, but these days, the thing does
> > > 
> > > 	max(buf_size - len, 0)
> > > 
> > > which should mean that the input layer passes in 0 instead of a negative 
> > > number. And snprintf() will then _not_ print anything. 
> > > 
> > > So I think input_add_uevent_bm_var() is safe, even if it's not pretty.
> > > 
> > > However, input_devices_read() doesn't do any sanity checking at all, and 
> > > if that ever ends up printing more than a page, that would be bad. I 
> > > didn't look very closely, but it looks worrisome.
> > > 
> > > Dmitry?
> > 
> > I had all this code converted to seq_file, but it depends on converting
> > input handlers to class interfaces and it is not possible nowadays
> > because with latest Greg's changes to class code we would try to
> > register class devices while registering class devices/interfaces
> > (psmouse creates input_dev which binds to mousedev interface which in
> > turn tries to create mouseX which is also belongs to input class) and
> > deadlocking. Greg promised current implementation is only a temporary
> > solution.
> > 
> > I suppose I could separate those changes...
> 
> That would probably be a good idea :)
> 

Hmm, what is the policy for attr->show()? With hotplug variables we
return -ENOMEM if there is not enough memory to store all data, but
what about attributes? Should we also return error (and which one,
-ENOMEM, -ENOBUFS?) or fill as much as we can and return up to
PAGE_SIZE? With sysfs not kernel nor application can really recover
if attribute needs buffer larger than a page. Or just rely on BUG_ON
in fs/sysfs/file.c::fill_read_buffer()?

-- 
Dmitry

  reply	other threads:[~2006-03-08  3:22 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-07 21:54 Fw: Re: oops in choose_configuration() Chuck Ebbert
2006-03-08  0:54 ` Greg KH
2006-03-08  0:57 ` Linus Torvalds
2006-03-08  1:13   ` Dmitry Torokhov
2006-03-08  1:27     ` Greg KH
2006-03-08  3:22       ` Dmitry Torokhov [this message]
2006-03-08  5:23         ` Greg KH
2006-03-08  6:06           ` Dmitry Torokhov
2006-03-08  6:15             ` Greg KH
2006-03-08  4:28   ` Joe Korty
2006-03-08  4:44     ` Dmitry Torokhov
  -- strict thread matches above, loose matches on Subject: below --
2006-03-08  3:29 Chuck Ebbert
2006-03-08  3:48 ` Dmitry Torokhov
2006-03-08  4:01 ` Linus Torvalds
     [not found] <20060304121723.19fe9b4b.akpm@osdl.org>
     [not found] ` <Pine.LNX.4.64.0603041235110.22647@g5.osdl.org>
     [not found]   ` <20060304213447.GA4445@kroah.com>
     [not found]     ` <20060304135138.613021bd.akpm@osdl.org>
     [not found]       ` <20060304221810.GA20011@kroah.com>
2006-03-05 23:48         ` Andrew Morton
2006-03-06  3:27           ` Linus Torvalds
2006-03-06  8:48             ` Andrew Morton
2006-03-08  1:31               ` Greg KH
2006-03-08  1:49                 ` Andrew Morton
2006-03-06  5:00           ` Linus Torvalds
2006-03-06  7:47             ` Mike Galbraith
2006-03-07  5:51               ` Mike Galbraith
2006-03-07  5:56                 ` Nick Piggin
2006-03-06  9:14             ` Ingo Molnar
2006-03-06 10:31             ` Andrew Morton
2006-03-06 11:04           ` Jesper Juhl
2006-03-06 11:15             ` Andrew Morton
2006-03-06 15:59               ` Dave Jones

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=200603072222.11504.dtor_core@ameritech.net \
    --to=dtor_core@ameritech.net \
    --cc=76306.1226@compuserve.com \
    --cc=akpm@osdl.org \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=torvalds@osdl.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