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]

Message-Id: <200906150936.41983.jplatte@naasa.net>
Date:	Mon, 15 Jun 2009 09:36:39 +0200
From:	Joerg Platte <jplatte@...sa.net>
To:	Henrique de Moraes Holschuh <hmh@....eng.br>
Cc:	linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [2.6.30] Kernel bug with dock driver

Am Monday, 15. June 2009 schrieb Henrique de Moraes Holschuh:
> Do it in single user mode with udev helpers *killed*, but just release

Today I tried to reproduce the bug in runlevel 2 (Debian based system) without 
success, even after a suspend to disk. In the past this was one method to 
trigger bugs with the bay.

> the lever, _don't_ pull the drive off the bay, unless you do verify that
> the bay LED went off.
>
> ***NEVER*** remove an Ultrabay device with the Ultrabay LED still lit,
> especially if it is a PATA device.

I did this accidentally some times before and the bay is still working. But 
I'll try to not to do it again :)

> 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.

Userspace scripts are written by me (based on some information from 
thinkwiki). 
The udev rule looks like this:
ATTR{type}=="ata_bay", ATTR{docked}=="1", KERNEL=="dock.*", ACTION=="change", 
SUBSYSTEM=="platform", RUN+="/usr/local/sbin/ultrabay_open"

and ultrabay_open contains the following lines of shell code:
#!/bin/bash
ULTRABAY_SYSDIR='/sys/class/scsi_device/1:0:0:0/device'
shopt -s nullglob

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"
else
        echo eject > /proc/acpi/ibm/bay
fi
# Tell the user we're OK
logger "/proc/acpi/ibm/beep"
echo 12 > /proc/acpi/ibm/beep

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 maybe yesterday this script was called twice and the kernel does not like 
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?

regards,
Jörg

--
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/