Are you the publisher? Claim or contact us about this channel


Embed this content in your HTML

Search

Report adult content:

click to rate:

Account: (login)

More Channels


Channel Catalog


Channel Description:

lkml.org - the realtime linux kernel mailinglist archive
    0 0

    Linus Torvalds writes: (Summary) wrote:

    [...]

    that were missing them,
    Oh Christ, couldn't they have just added the one-liner SPDX tags rather than doing that crazy "new 22 line boiler plate garbage to fifteen random Makefiles"?
    fifteen random Makefiles"?
    I pulled it, but let's try to reign in the crazy "lets add filler lines" behavior, ok?
    lines" behavior, ok?
    Alex, can you talk to the AMD lawyers and ask them about just putting the SPDX line instead?
    the SPDX line instead?
    Linus
    Linus
    Linus

    0 0

    Linus Torvalds writes: (Summary) On Fri, Dec 8, 2017 at 7:56 AM, Mauro Carvalho Chehab <mchehab@osg.samsung.com> wrote:

    [...]

    changes - just comment changes at the source files; Guys, this was just pure garbage, and obviously noboduy actually looked at that shit-for-brains patch.
    looked at that shit-for-brains patch.
    There were several idiotic things like this:
    There were several idiotic things like this:
      -/******************************
      +/*****************************
    
    because part of it was apparently generated with some overly stupid
    search-and-replace. That pointless
    noise may now be hiding the real changes.

    0 0

    Linus Torvalds writes: (Summary) That said, can't we separate this out into the copy_mm() phase only?
    phase only?
    We have "arch_dup_mmap()" that is called on fork() only, so that could do the LDT copy from the old mm, and the actual init_new_context would just zero it out.
    just zero it out.
    Then there wouldn't be any odd "check if this is an execve" because the copying would be done in the right place.
    the copying would be done in the right place.
    Hmm?
    Hmm?
    Linus
    Linus
    Linus

    0 0

    Linus Torvalds writes: (Summary)

    [...]

    me commit id, that would help.
    The fix in there should be 5b06bbcfc2c6 ("x86/power: Fix some ordering bugs in __restore_processor_context()") so you can certainly see if it works before that (or just reverting it).
    works before that (or just reverting it).
    But there are also a few other x86 low-level things there, and that fix really looks very safe, so I'd almost expect something else to have triggered your problem. Linus
    Linus
    Linus

    0 0

    Linus Torvalds writes: (Summary) Aha.
    Yeah, people do.
    Yeah, people do.
    Andy?
    Andy?

    [...]

    ...should take 10 seconds or so.
    I'm told 0day does *some* suspend/resume testing, but I think it's pretty limited, partly because the kinds of machines it primarily works on don't really support suspend/resume at all. This came in from the x86 trees (and those do their own tests too, but probably not suspend/resume either), but it hit my tree fairly soon after going into the x86 -tip trees.
    fairly soon after going into the x86 -tip trees.
    Linus
    Linus
    Linus

    0 0

    Linus Torvalds writes: (Summary) Things like that.
    So I think that if people worry about leaking pointers, they should primarily go for:
    primarily go for:
    - just use %p and now get the hashed value
    - just use %p and now get the hashed value
    - if the hashed value is pointless, ask yourself whether the pointer itself is important. Maybe it should be removed?
    - as a last option, if you really think the true pointer value is important, why is root so special, and maybe you should use %px and make sure you have proper sensible permissions.
    make sure you have proper sensible permissions.
    ..and %pK just isn't really the answer in any of those cases.

    0 0

    Linus Torvalds writes: (Summary) wrote:

    [...]

    *dbg_userword(cachep, objp));
    Is there actually any point to the %px at all?
    Is there actually any point to the %px at all?
    Why not remove it?

    [...]

    realobj, size);
    and here, is the pointer actually interesting, or should we just give the offset to the allocation?
    the offset to the allocation?
    But if the pointer is interesting, then ack.
    But if the pointer is interesting, then ack.
    Linus
    Linus
    Linus

    0 0

    Linus Torvalds writes: (Summary) On Thu, Nov 30, 2017 at 6:35 AM, Jiri Slaby <jslaby@suse.cz> I'm applying this directly to my tree since I didn't see anybody else react to it, but the whole pattern worries me.
    react to it, but the whole pattern worries me.
    Also, clearly nobody actually uses the odder corners of futex ops anyway. Maybe we should deprecate them entirely?
    Jiri, did you notice by testing, or what?
    Jiri, did you notice by testing, or what?
    Linus
    Linus
    Linus

    0 0

    Linus Torvalds writes: (Summary) And the comment does seem relevant for 32-bit too:
    relevant for 32-bit too:

    [...]

    * and LDT, which happen in fix_processor_context(). You've moved down the 32-bit fix_processor_context() call to after the loadsegment() calls, which smells wrong.
    after the loadsegment() calls, which smells wrong.
    That said, this *all* smells wrong. Why is there a special fix_processor_context() function at all with different 32-bit and 64-bit behavior? There's no logic to what is done where.
    Linus
    Linus
    Linus

    0 0
  • 12/10/17--18:08: Linux 4.15-rc3
  • Linus Torvalds writes: (Summary) Johnson (1): firmware: cleanup FIRMWARE_IN_KERNEL message Robin Murphy (1): iommu/vt-d: Fix scatterlist offset handling Roger He (5): drm/ttm: use NUM_PAGES_TO_ALLOC always drm/ttm: add page order in page pool drm/ttm: add set_pages_wb for handling page order more than zero drm/ttm: add page order support in ttm_pages_put drm/ttm: roundup the shrink request to prevent skip huge pool Roger Quadros (1): usb: gadget: core: Fix ->udc_set_speed() speed handling Rudolf Marek (1): x86/cpufeatures: Make X86_BUG_FXSAVE_LEAK detectable in CPUID on AMD Russell King (4): sfp: fix RX_LOS signal handling sfp: improve RX_LOS handling sfp: warn about modules requiring address change sequence phylink: ensure we take the link down when phylink_stop() is called Sakari Ailus (2): media: ov13858: Select V4L2_FWNODE media: imx274: Fix error handling, add MAINTAINERS entry Sara Sharon (3): iwlwifi: pcie: fix erroneous "Read fa

    0 0

    Linus Torvalds writes: (Summary) I think we actually leave the user-space percpu segment in %gs (or the stack canary base), so that one we should actually save/restore, but I'm getting the feeling that we should just reset the other segment registers to known values on 32-bit.
    registers to known values on 32-bit.
    Also, why does the 32-bit code do
    Also, why does the 32-bit code do
    loadsegment(es, ctxt->es);
    loadsegment(es, ctxt->es);
    but the 64-bit code does
    but the 64-bit code does
    asm volatile ("movw %0, %%es" :: "r" (ctxt->es)); It has been written as some kind of "save and restore registers", but that's not what it really then does - or what it should do.
    then does - or what it should do.
    It should make sure to restore a sane kernel state, not some random register state.
    register state.
    And the 32-bit and 64-bit code really should strive to be at least _sanely_ different, not this randomly and insanely different mess.

    0 0

    Linus Torvalds writes: (Summary) On Mon, Dec 11, 2017 at 10:41 AM, Andy Lutomirski <luto@amacapital.net> wrote:

    [...]

    do some trivial fix/revert and fix it for real next time around? I don't think we want some trivial fix/revert just to keep it working. This code is too fragile as-is, and I think that "make it work" is more than reverting. You did fix real issues on x86-64 with odd segment use, for example.
    segment use, for example.
    Linus
    Linus
    Linus