On 2.12.2013, at 21.00, Bodo Stroesser <bstroes...@ts.fujitsu.com> wrote:

> From: Bodo Stroesser <bstroes...@ts.fujitsu.com>
> Date: Mon, 2 Dec 2013 18:52:10 +0100
> Subject: [PATCH 1/3] st.ko: fix enlarge_buffer
> 
> This patch removes a bug in enlarge_buffer() that can make a
> read or write fail under special conditions.
> 
> After changing TRY_DIRECT_IO to 0 and ST_MAX_SG to 32 in
> st_options.h, a program that writes a first block of 128k and
> than a second bigger block (e.g. 256k) fails. The second write
> returns errno EOVERFLOW, as enlarge_buffer() checks the sg list
> and detects that it already is full.
> As enlarge_buffer uses different page allocation orders
> depending on the size of the buffer needed, the check does not
> make sense.
> 
Yes, it is not useful any more. It may have been necessary at some time but I 
am now not sure about that either ;-)

> Cc: Kai Makisara <kai.makis...@kolumbus.fi>

Acked-by: Kai Mäkisara <kai.makis...@kolumbus.fi>

Thanks,
Kai

> Signed-off-by: Bodo Stroesser <bstroes...@ts.fujitsu.com>
> 
> ---
> 
> --- a/drivers/scsi/st.c       2013-12-02 18:52:10.000000000 +0100
> +++ b/drivers/scsi/st.c       2013-12-02 18:52:10.000000000 +0100
> @@ -3719,7 +3719,7 @@ static struct st_buffer *new_tape_buffer
> 
> static int enlarge_buffer(struct st_buffer * STbuffer, int new_size, int 
> need_dma)
> {
> -     int segs, nbr, max_segs, b_size, order, got;
> +     int segs, max_segs, b_size, order, got;
>       gfp_t priority;
> 
>       if (new_size <= STbuffer->buffer_size)
> @@ -3729,9 +3729,6 @@ static int enlarge_buffer(struct st_buff
>               normalize_buffer(STbuffer);  /* Avoid extra segment */
> 
>       max_segs = STbuffer->use_sg;
> -     nbr = max_segs - STbuffer->frp_segs;
> -     if (nbr <= 0)
> -             return 0;
> 
>       priority = GFP_KERNEL | __GFP_NOWARN;
>       if (need_dma)

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to