linux-kernel - [PATCH] scsi/sd: fix suspend with USB-connected Android phone (one line)

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-next>] [day] [month] [year] [list]

Message-ID: <BANLkTi=XNyR8GD43GGnMag+=JmhUd_5HtA@mail.gmail.com>
Date:	Wed, 11 May 2011 18:35:05 -0400
From:	Charles Hannum <root@...ck.net>
To:	linux-kernel@...r.kernel.org
Subject: [PATCH] scsi/sd: fix suspend with USB-connected Android phone (one line)

Short version: My laptop doesn't suspend when my Android phone is
connected and has been “ejected”.

Long version:

Android phones connect as USB mass storage devices.  After the “Turn
on USB storage” button has been clicked, there are a few different
ways to detach the “disk”:

1) pull the cable
2) click “Turn off USB storage”
3) “eject” the device

In cases 2 & 3, the USB device is still attached to the system, but
will now return MEDIUM NOT PRESENT for many commands, including
SYNCHRONIZE CACHE—basically it acts like any device with removable
media.  However, the act of the “media” being removed does not
invalidate sdkp->WCE; therefore sd_shutdown() and sd_suspend() still
call sd_sync_cache(), which *fails* because it gets a MEDIUM NOT
PRESENT sense code.  In the sd_suspend() case, this causes the entire
suspend to fail, and the laptop rewakes immediately.

There are a few different ways to fix this; e.g. one could
specifically test media_not_present() if a sense code is returned in
sd_sync_cache().  However, the following patch seems simpler, and
avoids calling sd_sync_cache() at all in this case.  sdkp->WCE will be
reset when new medium is recognized and sd_read_cache_type() is
called.  Note this code always gets called—it's in the same path as
sd_read_capacity(), which has to be called for the device to be usable
again; thus the patch is inherently safe.

Kernel tested: 2.6.38 (Ubuntu Natty)

View attachment "sd-suspend.diff" of type "text/x-patch" (278 bytes)