On Thu, Jun 21, 2012 at 9:49 PM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
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.
OK, I will submit a new patch which just holds
On Fri, 22 Jun 2012, Ming Lei wrote:
On Thu, Jun 21, 2012 at 9:49 PM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
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.
OK, I
On Fri, Jun 22, 2012 at 12:12 AM, Alan Stern st...@rowland.harvard.edu wrote:
On Fri, 22 Jun 2012, Ming Lei wrote:
On Thu, Jun 21, 2012 at 9:49 PM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
We also have not made the rule that a shutdown will complete in a
specific amount of
On Tue, Jun 19, 2012 at 10:00:36AM +0800, Ming Lei wrote:
On Tue, Jun 19, 2012 at 6:25 AM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
Have you read Documentation/stable_kernel_patches.txt? Please do so and
I haven't read Documentation/stable_kernel_patches.txt, but read
On Thu, Jun 21, 2012 at 6:37 AM, Greg Kroah-Hartman
gre...@linuxfoundation.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
On Mon, Jun 18, 2012 at 09:52:57AM +0800, Ming Lei wrote:
On Sat, Jun 16, 2012 at 6:03 AM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
On Mon, Jun 11, 2012 at 01:13:20PM +0800, Ming Lei wrote:
Firstly, .shutdown callback may touch a uninitialized hardware
if dev-driver is set and
On Tue, Jun 19, 2012 at 6:25 AM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
Have you read Documentation/stable_kernel_patches.txt? Please do so and
I haven't read Documentation/stable_kernel_patches.txt, but read
Documentation/stable_kernel_rules.txt, :-)
see why I can't take this
On Mon, Jun 11, 2012 at 01:13:20PM +0800, Ming Lei wrote:
Firstly, .shutdown callback may touch a uninitialized hardware
if dev-driver is set and .probe is not completed.
Secondly, device_shutdown() may dereference a null pointer to cause
oops when dev-driver is cleared after it is checked
On Mon, 11 Jun 2012, Ming Lei wrote:
@@ -1820,6 +1833,18 @@ void device_shutdown(void)
list_del_init(dev-kobj.entry);
spin_unlock(devices_kset-list_lock);
+ /* hold lock to avoid race with .probe/.release */
+ if (dev-parent
On Mon, Jun 11, 2012 at 10:16 PM, Alan Stern st...@rowland.harvard.edu wrote:
+
+ if (nonlocked)
+ dev_err(dev, can't hold %slock for shutdown\n,
+ nonlocked == 1 ? : parent );
Even if the parent can't be locked, you
On Mon, 11 Jun 2012, Ming Lei wrote:
On Mon, Jun 11, 2012 at 10:16 PM, Alan Stern st...@rowland.harvard.edu
wrote:
+
+ � � � � � � if (nonlocked)
+ � � � � � � � � � � dev_err(dev, can't hold %slock for shutdown\n,
+ � � � � � � � � � � � � � � � � � � nonlocked == 1 ? : parent );
On Tue, Jun 12, 2012 at 12:02 AM, Alan Stern st...@rowland.harvard.edu wrote:
On Mon, 11 Jun 2012, Ming Lei wrote:
I have considered doing it, but which may consume another 1sec.
Also if the parent lock has been held, it is very possibly that the
device can't be probed or removed at the same
Firstly, .shutdown callback may touch a uninitialized hardware
if dev-driver is set and .probe is not completed.
Secondly, device_shutdown() may dereference a null pointer to cause
oops when dev-driver is cleared after it is checked in
device_shutdown().
So just try to hold device lock and its
13 matches
Mail list logo
