Re: [PATCH] block: fix splitting segments on boundary masks

Re: [PATCH] block: fix splitting segments on boundary masks

[Tony Battersby]

Although I was not originally involved in the development of these
patches, I recently came across them while looking over the source:

upstream commit 429120f3df2d ("block: fix splitting segments on boundary masks")
    Cc: stable@vger.kernel.org # v5.1+
    Fixes: dcebd755926b ("block: use bio_for_each_bvec() to compute multi-page bvec count")

upstream commit 4a2f704eb2d8 ("block: fix get_max_segment_size() overflow on 32bit arch")
    Fixes: 429120f3df2d ("block: fix splitting segments on boundary masks")

https://www.spinics.net/lists/linux-block/msg48605.html
https://www.spinics.net/lists/linux-block/msg48959.html


The first patch mentions fixing problems with filesystem corruption, so
it seems important, but it has never been included in any -stable
kernel.  Is there a specific reason these patches have been excluded
from -stable, or is it just a mistake?

These patches would be relevant to kernel versions 5.1 - 5.4, with 5.4.y
being the only active stable kernel series in that range.  The patches
apply cleanly on top of 5.4.51.

Tony Battersby
Cybernetics

Re: [PATCH] block: fix splitting segments on boundary masks

[Guenter Roeck]

On 7/9/20 7:35 AM, Tony Battersby wrote:
> Although I was not originally involved in the development of these
> patches, I recently came across them while looking over the source:
> 
> upstream commit 429120f3df2d ("block: fix splitting segments on boundary masks")
>     Cc: stable@vger.kernel.org # v5.1+
>     Fixes: dcebd755926b ("block: use bio_for_each_bvec() to compute multi-page bvec count")
> 
> upstream commit 4a2f704eb2d8 ("block: fix get_max_segment_size() overflow on 32bit arch")
>     Fixes: 429120f3df2d ("block: fix splitting segments on boundary masks")
> 
> https://www.spinics.net/lists/linux-block/msg48605.html
> https://www.spinics.net/lists/linux-block/msg48959.html
> 
> 
> The first patch mentions fixing problems with filesystem corruption, so
> it seems important, but it has never been included in any -stable
> kernel.  Is there a specific reason these patches have been excluded
> from -stable, or is it just a mistake?
> 
See here:

https://www.spinics.net/lists/stable/msg355009.html

Looks like it was queued but dropped because of the problem that
was later fixed with the patch below. Maybe it is time to revisit
and apply both patches now.

Thanks,
Guenter

> These patches would be relevant to kernel versions 5.1 - 5.4, with 5.4.y
> being the only active stable kernel series in that range.  The patches
> apply cleanly on top of 5.4.51.
> 
> Tony Battersby
> Cybernetics
> 

Re: [PATCH] block: fix splitting segments on boundary masks

[Greg KH]

On Thu, Jul 09, 2020 at 08:26:01AM -0700, Guenter Roeck wrote:
> On 7/9/20 7:35 AM, Tony Battersby wrote:
> > Although I was not originally involved in the development of these
> > patches, I recently came across them while looking over the source:
> > 
> > upstream commit 429120f3df2d ("block: fix splitting segments on boundary masks")
> >     Cc: stable@vger.kernel.org # v5.1+
> >     Fixes: dcebd755926b ("block: use bio_for_each_bvec() to compute multi-page bvec count")
> > 
> > upstream commit 4a2f704eb2d8 ("block: fix get_max_segment_size() overflow on 32bit arch")
> >     Fixes: 429120f3df2d ("block: fix splitting segments on boundary masks")
> > 
> > https://www.spinics.net/lists/linux-block/msg48605.html
> > https://www.spinics.net/lists/linux-block/msg48959.html
> > 
> > 
> > The first patch mentions fixing problems with filesystem corruption, so
> > it seems important, but it has never been included in any -stable
> > kernel.  Is there a specific reason these patches have been excluded
> > from -stable, or is it just a mistake?
> > 
> See here:
> 
> https://www.spinics.net/lists/stable/msg355009.html
> 
> Looks like it was queued but dropped because of the problem that
> was later fixed with the patch below. Maybe it is time to revisit
> and apply both patches now.

Ok, let me queue both up for 5.4.y now and see what happens :)

thanks,

greg k-h