On Wed, Jun 24, 2020 at 01:58:27PM +0200, Joerg Roedel wrote:
> Hi Greg,
>
> On Wed, Jun 24, 2020 at 11:09:06AM +0200, Greg KH wrote:
> > So what exact stable kernel version(s) do you want to see this patch
> > applied to?
>
> It is needed in kernels <= v5.4. Linux v5.5 has replaced the code
Hi Greg,
On Wed, Jun 24, 2020 at 11:09:06AM +0200, Greg KH wrote:
> So what exact stable kernel version(s) do you want to see this patch
> applied to?
It is needed in kernels <= v5.4. Linux v5.5 has replaced the code with
the bug.
Joerg
___
On Wed, Jun 24, 2020 at 08:41:21AM +, Suravee Suthikulpanit wrote:
> Currently, an integer is used to specify the size in unmap_sg().
> With 2GB worth of pages (512k 4k pages), it requires 31 bits
> (i.e. (1 << 19) << 12), which overflows the integer, and ends up
> unmapping more pages than
Currently, an integer is used to specify the size in unmap_sg().
With 2GB worth of pages (512k 4k pages), it requires 31 bits
(i.e. (1 << 19) << 12), which overflows the integer, and ends up
unmapping more pages than intended. Subsequently, this results in
IO_PAGE_FAULT.
Uses size_t instead of
On Wed, Jun 24, 2020 at 08:41:21AM +, Suravee Suthikulpanit wrote:
> Currently, an integer is used to specify the size in unmap_sg().
> With 2GB worth of pages (512k 4k pages), it requires 31 bits
> (i.e. (1 << 19) << 12), which overflows the integer, and ends up
> unmapping more pages than
