lkml.org 
[lkml]   [2017]   [Mar]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [net/bpf] 3051bf36c2 BUG: unable to handle kernel paging request at 0000a7cf
    On Wed, 8 Mar 2017, Linus Torvalds wrote:

    > Adding x86 people too, since this seems to be something off about
    > ARCH_HAS_SET_MEMORY for x86-32.
    >
    > The code seems to be shared between x86-32 and 64, I'm not seeing why
    > set_memory_r[ow]() should fail on one but not the other.

    Indeed.

    > Considering that it seems to be flaky even on 32-bit, maybe it's
    > timing-related, or possibly related to TLB sizes or whatever (ie more
    > likely hidden by a larger TLB on more modern hardware?)

    The only difference I can see is the way how __tlb_flush_all() is
    happening. We have 3 variants:

    invpcid_flush_all() - depends on X86_FEATURE_INVPCID and X86_FEATURE_PGE
    cr4 based flush - depends on X86_FEATURE_PGE
    cr3 based flush

    No idea which variant is used in that failure case.

    > Anyway, just looking at change_page_attr_set_clr(), I notice that the
    > page alias checking treats NX specially:
    >
    > /* No alias checking for _NX bit modifications */
    > checkalias = (pgprot_val(mask_set) | pgprot_val(mask_clr)) != _PAGE_NX;
    >
    > which seems insane. Why would NX be different from other protection
    > bits (like _PAGE_RW)?

    The reason is that the alias mapping should never be executable at all.

    Thanks,

    tglx

    \
     
     \ /
      Last update: 2017-03-09 14:43    [W:5.156 / U:0.180 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site