> Christoph,
>
> > Ok. If the stable maintainers are ok with your small fix I'm not
> > going to complain too loudly. But I'm always worried about stable
> > trees divering too much from mainline.
>
> The seemingly innocuous transition from SG_GAPS to virt boundary has
> caused several data cor
Christoph,
> Ok. If the stable maintainers are ok with your small fix
> I'm not going to complain too loudly. But I'm always worried about
> stable trees divering too much from mainline.
The seemingly innocuous transition from SG_GAPS to virt boundary has
caused several data corruption regress
On Tue, Aug 22, 2017 at 11:43:19PM -0700, Christoph Hellwig wrote:
> Ok. If the stable maintainers are ok with your small fix
> I'm not going to complain too loudly. But I'm always worried about
> stable trees divering too much from mainline.
Given that 90% of the time we do this, something brea
Ok. If the stable maintainers are ok with your small fix
I'm not going to complain too loudly. But I'm always worried about
stable trees divering too much from mainline.
> Wouldn't it make sense to backport the changes to set the virt_boundary
> (which probably still is the SG_GAPS flag in such an old kernel)?
We can make storvsc use SG_GAPS. But the following patch is missing in 4.1
stable block layer to make this work on some I/O situations. Backporting is
m
Wouldn't it make sense to backport the changes to set the virt_boundary
(which probably still is the SG_GAPS flag in such an old kernel)?
6 matches
Mail list logo
