linux-kernel - Re: [PATCH] driver core: fix shutdown races with probe/remove(v2)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 21 Jun 2012 06:49:42 -0700
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Ming Lei <ming.lei@...onical.com>
Cc:	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
	Alan Stern <stern@...land.harvard.edu>, stable@...r.kernel.org
Subject: Re: [PATCH] driver core: fix shutdown races with probe/remove(v2)

On Thu, Jun 21, 2012 at 09:21:08AM +0800, Ming Lei wrote:
> On Thu, Jun 21, 2012 at 6:37 AM, Greg Kroah-Hartman
> <gregkh@...uxfoundation.org> wrote:
> > On Tue, Jun 19, 2012 at 10:00:36AM +0800, Ming Lei wrote:
> 
> >> so I marked it as -stable because I have explained how the race can be
> >> exploited in reality.
> >
> > Ok, but as this has been there since when, 2.5, I'll refrain from
> > marking it this way, as no one has reported a real problem like this
> > before.
> 
> So have you agreed on keeping Cc: stable in v3?

No.

> >> I still have more many examples in kernel about timeout value...
> >
> > Yes, I know this, but now you are putting a limit on the amount of time
> 
> No, I don't put a limit on it, see my below explanation.
> 
> > a probe function can take, when before, we have never had one.  That's
> > not something to be taken lightly, and is one I know is not true.
> >
> >> > Why not just do a real lock and try for forever?
> >>
> >> IMO, there are two advantages not just doing a real lock for forever:
> >>
> >> - avoiding buggy device/driver to hang the system
> >> - with trylock, we can log the buggy device so that it is a bit
> >> easier to troubleshoot the buggy drivers, suppose the bug is
> >> only triggered 1 time in one year or more
> >
> > No, just fix the driver, I don't want to put a time limit on how long
> 
> Surely we need to fix the driver, but the problem is that it may be very
> difficult to fix the driver without the log introduced in the patch, so why
> not take it without obvious side effect?

Because nothing is wrong with the driver if it takes that long, it's not
"broken" at all, because we have never made the rule that a probe
function has to complete in a specific amount of time.

We also have not made the rule that a shutdown will complete in a
specific amount of time either, so there is no problem if that takes a
long time as well.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/