linux-kernel - Re: [2.6.30] Kernel bug with dock driver

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Mon, 15 Jun 2009 17:29:28 -0300
From:	Henrique de Moraes Holschuh <hmh@....eng.br>
To:	Joerg Platte <jplatte@...sa.net>
Cc:	linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [2.6.30] Kernel bug with dock driver

On Mon, 15 Jun 2009, Joerg Platte wrote:
> > If the bug cannot be reproduced in that condition, it is happening
> > because userspace is trapping the lever release event (as it should),
> > and doing something the kernel doesn't like with it (which is a bug
> > in the kernel in any case).  That might help you track down a better
> > way to reproduce the issue.
> 
> if [ -d $ULTRABAY_SYSDIR ]; then
>         sync
>         echo 1 > $ULTRABAY_SYSDIR/delete
>         logger "removed $ULTRABAY_SYSDIR"
> fi
> sync
> # Turn off power to the UltraBay:
> if [ -f /sys/devices/platform/dock.2/undock ]; then
>         echo 1 > /sys/devices/platform/dock.2/undock
>         logger "/sys/devices/platform/dock.2/undock"

There might be a race there, as you call undock but you don't really know if
the SCSI device was deleted.

> What I discovered today after modifying ultrabay_open was that in some cases 
> the script is called again directly after inserting a drive to the bay. But 
> only, if the execution of this script takes some more time (I added a sleep 2 
> after the second sync to be able to see which command might trigger the bug).

So, please try to reproduce this by sending a number of delete requests
back-to-back in a row, and also mixing delete requests with undock requests.
When you find out what causes the OOPS (and it _is_ a bug in the kernel if
any of those oops), we can try to direct the bug report to someone who can
fix the problem.

> to undock a device while it is in the process of being undocked? How should I 
> modify the udev rule to prevent another execution each time a drive is 
> inserted into the bay?

You will need locking, unfortunately.  Also, check if there is a device in
the bay.  event+device in bay == hotunplug.  event+no device in bay ==
hotplug.

That is, if the events don't already tell you (i.e. different events for
plug and unplug).  I don't recall right now if the ACPI events are
different, but I do recall the thinkpad BIOS follows the ACPI spec correctly
on this area.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
--
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/