Re: [syzbot] [xfs?] BUG: unable to handle kernel paging request in clear_user_rep_good

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, May 01, 2023 at 11:49:55AM -0700, Linus Torvalds wrote:
> The bug goes back to commit 0db7058e8e23 ("x86/clear_user: Make it
> faster") from about a year ago, which made it into v6.1.

Gah, sorry about that. :-\

> It only affects old hardware that doesn't have the ERMS capability
> flag, which *probably* means that it's mostly only triggerable in
> virtualization (since pretty much any CPU from the last decade has
> ERMS, afaik).
> 
> Borislav - opinions? This needs fixing for v6.1..v6.3, and the options are:
> 
>  (1) just fix up the exception entry. I think this is literally this
> one-liner, but somebody should double-check me. I did *not* actually
> test this:
> 
>     --- a/arch/x86/lib/clear_page_64.S
>     +++ b/arch/x86/lib/clear_page_64.S
>     @@ -142,8 +142,8 @@ SYM_FUNC_START(clear_user_rep_good)
>             and $7, %edx
>             jz .Lrep_good_exit
> 
>     -.Lrep_good_bytes:
>             mov %edx, %ecx
>     +.Lrep_good_bytes:
>             rep stosb
> 
>      .Lrep_good_exit:
> 
>    because the only use of '.Lrep_good_bytes' is that exception table entry.
> 
>  (2) backport just that one commit for clear_user
> 
>      In this case we should probably do commit e046fe5a36a9 ("x86: set
> FSRS automatically on AMD CPUs that have FSRM") too, since that commit
> changes the decision to use 'rep stosb' to check FSRS.
> 
>  (3) backport the entire series of commits:
> 
>         git log --oneline v6.3..034ff37d3407
> 
> Or we could even revert that commit 0db7058e8e23, but it seems silly
> to revert when we have so many ways to fix it, including a one-line
> code movement.
> 
> Borislav / stable people? Opinions?

So right now I feel like (3) would be the right thing to do. Because
then stable and upstream will be on the same "level" wrt user-accessing
primitives. And it's not like your series depend on anything from
mainline (that I know of) so backporting them should be relatively easy.

But (1) is definitely a lot easier for stable people modulo the fact
that it won't be an upstream commit but a special stable-only fix.

So yeah, in that order.

I guess I'd let stable people decide here what they wanna do.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette




[Index of Archives]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux