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

Message-ID: <4DD0BC7E.3060901@suse.de>
Date:	Mon, 16 May 2011 07:56:14 +0200
From:	Hannes Reinecke <hare@...e.de>
To:	Oliver Neukum <oliver@...kum.org>
Cc:	James Bottomley <James.Bottomley@...senpartnership.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>, Charles Hannum <root@...ck.net>,
	linux-kernel@...r.kernel.org, Greg Kroah-Hartman <gregkh@...e.de>,
	Alan Stern <stern@...land.harvard.edu>,
	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 05/14/2011 09:11 PM, Oliver Neukum wrote:
> Am Donnerstag, 12. Mai 2011, 22:36:03 schrieb James Bottomley:
>
>> Instinct tells me the correct set of fixes is to add a sync cache from
>> release (so we automatically sync on last close, which is usually when
>> an ordered remove happens), keep the one on shutdown, just in case the
>> system goes down with stuff still mounted and print a nasty message on
>> suspend for a write back device that's been removed.
>>
>> I also think we shouldn't abort the suspend if the disk doesn't respond
>> correctly to start/stop ... the power is going to be disconnected
>> anyway, so it's no issue if the disk spins for a second or so longer.
>>
>> The problem this is going to cause is double sync on shutdown (once when
>> final unmount closes the device and once on shutdown) ... do people
>> agree that's a price worth paying?
>>
>> Something like this?
>
> Hi,
>
> it seems to me that the error codes should really be evaluated a bit better.
> How about this?
>
> 	Regards
> 		Oliver
>
>  From 2ab03ae46d6dc126a51ee9cd38206fbdc8bf6a34 Mon Sep 17 00:00:00 2001
> From: Oliver Neukum<oliver@...kum.org>
> Date: Mon, 25 Oct 2010 12:25:26 +0200
> Subject: [PATCH 2/5] SCSI:sd:error handling in sd_sync_cache()
>
> The SCSI commands sd_sync_cache() uses may fail.
> These errors needs to be evaluated to return correct
> error codes. This fixes system suspension while a device
> removal is being handled.
>
> Signed-off-by: Oliver NEukum<oneukum@...e.de>
Yep, this makes sense.

Acked-by: Hannes Reinecke <hare@...e.de>

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@...e.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
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/