[PATCH 0/2] scsi_dh patchset fixes

[PATCH 0/2] scsi_dh patchset fixes

[Hannes Reinecke]

Hi James,

these patches just fix the suggestions made by you and Mike C.
- Check the return code from try_module_get()
- Use GFP_ATOMIC in the IO path

Patches apply on top of my previous patchset for the scsi_dh fixes.

Please apply.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] scsi_dh patchset fixes

[James Bottomley]

On Fri, 2008-07-04 at 15:45 +0200, Hannes Reinecke wrote:
> Hi James,
> 
> these patches just fix the suggestions made by you and Mike C.
> - Check the return code from try_module_get()
> - Use GFP_ATOMIC in the IO path

I thought the final agreement was that these should be GFP_NOIO?

> Patches apply on top of my previous patchset for the scsi_dh fixes.

Could you not do this?  The GFP_KERNEL will spit might sleep warnings on
certain configs and the try_module_get could cause an oops on removal.
Either of these might confuse a bisection search if it accidentally
landed in them.  In general, for unapplied patches with identified bugs,
the patches should be fixed before applying.

Thanks,

James

Re: [PATCH 0/2] scsi_dh patchset fixes

[Hannes Reinecke]

Hi James,

James Bottomley wrote:
> On Fri, 2008-07-04 at 15:45 +0200, Hannes Reinecke wrote:
>> Hi James,
>>
>> these patches just fix the suggestions made by you and Mike C.
>> - Check the return code from try_module_get()
>> - Use GFP_ATOMIC in the IO path
> 
> I thought the final agreement was that these should be GFP_NOIO?
> 
Ok, will do so.

>> Patches apply on top of my previous patchset for the scsi_dh fixes.
> 
> Could you not do this?  The GFP_KERNEL will spit might sleep warnings on
> certain configs and the try_module_get could cause an oops on removal.
> Either of these might confuse a bisection search if it accidentally
> landed in them.  In general, for unapplied patches with identified bugs,
> the patches should be fixed before applying.
> 
Whatever you say :-)
I'll redo the patchset.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html