linux-kernel - Re: [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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 12 May 2011 18:41:32 -0400
From:	Charles Hannum <root@...ck.net>
To:	James Bottomley <James.Bottomley@...senpartnership.com>
Cc:	Alan Stern <stern@...land.harvard.edu>,
	"Rafael J. Wysocki" <rjw@...k.pl>, linux-kernel@...r.kernel.org,
	Greg Kroah-Hartman <gregkh@...e.de>,
	linux-scsi <linux-scsi@...r.kernel.org>,
	linux-usb@...r.kernel.org
Subject: Re: [PATCH] scsi/sd: fix suspend with USB-connected Android phone
 (one line)

On Thu, May 12, 2011 at 17:43, James Bottomley
<James.Bottomley@...senpartnership.com> wrote:
> It depends what the drive is caching and what's removable.  If it's some
> type of hybrid, and the cache isn't mapped to the media for instance.

Except that the SCSI spec says the cache affected by SYNCHRONIZE CACHE
is related to the medium.

> The point really is that if the cache is in the housing, setting it to
> write through when it's not is not a correct reflection of reality.

Since this pretty clearly violates the intent of the spec, I have to
ask whether you are aware of any such device.  I've never seen one.

Also, the only actual behavioral difference between my proposed patch
and your proposed one is to print out a message; you still weren't
calling sd_sync_cache() if the medium was not present.  I'm not
beholden to a specific patch—but printing out an extra message, which
seems to imply that something is wrong, is decidely uncool in the
original case I referenced (my Android phone, after “Turn on USB
storage” and then “/usr/bin/eject”), where nothing is wrong other than
the driver trying to SYNCHRONIZE CACHE to a medium that it already
knows is not present.

> or actually, just checking the value when it looks at the return code.

That was what I did first, but then I realized two things:

1) The pre-use (before clicking “Turn on USB storage”) state has
WCE==0 because the mode page code hasn't been called at that point.
There is no good reason the pre-use and post-eject behavior should be
different, given that the device itself is in *exactly* the same state
at these points.

2) I definitely do not want a spurious message that could be
interpreted as an error, since this is perfectly normal and acceptable
use.
--
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/