All of lore.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 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.