1. 05 Mar, 2016 1 commit
    • Karol Herbst's avatar
      x86/mm/kmmio: Fix mmiotrace for hugepages · cfa52c0c
      Karol Herbst authored
      Because Linux might use bigger pages than the 4K pages to handle those mmio
      ioremaps, the kmmio code shouldn't rely on the pade id as it currently does.
      
      Using the memory address instead of the page id lets us look up how big the
      page is and what its base address is, so that we won't get a page fault
      within the same page twice anymore.
      Tested-by: default avatarPierre Moreau <pierre.morrow@free.fr>
      Signed-off-by: default avatarKarol Herbst <nouveau@karolherbst.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Luis R. Rodriguez <mcgrof@suse.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Toshi Kani <toshi.kani@hp.com>
      Cc: linux-mm@kvack.org
      Cc: linux-x86_64@vger.kernel.org
      Cc: nouveau@lists.freedesktop.org
      Cc: pq@iki.fi
      Cc: rostedt@goodmis.org
      Link: http://lkml.kernel.org/r/1456966991-6861-1-git-send-email-nouveau@karolherbst.deSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      cfa52c0c
  2. 25 Feb, 2016 1 commit
    • Jan Beulich's avatar
      x86/mm: Avoid premature success when changing page attributes · 405e1133
      Jan Beulich authored
      set_memory_nx() (and set_memory_x()) currently differ in behavior from
      all other set_memory_*() functions when encountering a virtual address
      space hole within the kernel address range: They stop processing at the
      hole, but nevertheless report success (making the caller believe the
      operation was carried out on the entire range). While observed to be a
      problem - triggering the CONFIG_DEBUG_WX warning - only with out of
      tree code, I suspect (but didn't check) that on x86-64 the
      CONFIG_DEBUG_PAGEALLOC logic in free_init_pages() would, when called
      from free_initmem(), have the same effect on the set_memory_nx() called
      from mark_rodata_ro().
      
      This unexpected behavior is a result of change_page_attr_set_clr()
      special casing changes to only the NX bit, in that it passes "false" as
      the "checkalias" argument to __change_page_attr_set_clr(). Since this
      flag becomes the "primary" argument of both __change_page_attr() and
      __cpa_process_fault(), the latter would so far return success without
      adjusting cpa->numpages. Success to the higher level callers, however,
      means that whatever cpa->numpages currently holds is the count of
      successfully processed pages. The cases when __change_page_attr() calls
      __cpa_process_fault(), otoh, don't generally mean the entire range got
      processed (as can be seen from one of the two success return paths in
      __cpa_process_fault() already adjusting ->numpages).
      Signed-off-by: default avatarJan Beulich <jbeulich@suse.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/56BB0AD402000078000D05BF@prv-mh.provo.novell.comSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      405e1133
  3. 20 Feb, 2016 1 commit
  4. 14 Feb, 2016 1 commit
    • Borislav Petkov's avatar
      x86/mm: Fix INVPCID asm constraint · e2c7698c
      Borislav Petkov authored
      So we want to specify the dependency on both @pcid and @addr so that the
      compiler doesn't reorder accesses to them *before* the TLB flush. But
      for that to work, we need to express this properly in the inline asm and
      deref the whole desc array, not the pointer to it. See clwb() for an
      example.
      
      This fixes the build error on 32-bit:
      
        arch/x86/include/asm/tlbflush.h: In function ‘__invpcid’:
        arch/x86/include/asm/tlbflush.h:26:18: error: memory input 0 is not directly addressable
      
      which gcc4.7 caught but 5.x didn't. Which is strange. :-\
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Luis R. Rodriguez <mcgrof@suse.com>
      Cc: Michael Matz <matz@suse.de>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Toshi Kani <toshi.kani@hp.com>
      Cc: linux-mm@kvack.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      e2c7698c
  5. 09 Feb, 2016 6 commits
    • Andy Lutomirski's avatar
      x86/dmi: Switch dmi_remap() from ioremap() [uncached] to ioremap_cache() · ce1143aa
      Andy Lutomirski authored
      DMI cacheability is very confused on x86.
      
      dmi_early_remap() uses early_ioremap(), which uses FIXMAP_PAGE_IO,
      which is __PAGE_KERNEL_IO, which is __PAGE_KERNEL, which is cached.
      
      Don't ask me why this makes any sense.
      
      dmi_remap() uses ioremap(), which requests an uncached mapping.
      
      However, on non-EFI systems, the DMI data generally lives between
      0xf0000 and 0x100000, which is in the legacy ISA range, which
      triggers a special case in the PAT code that overrides the cache
      mode requested by ioremap() and forces a WB mapping.
      
      On a UEFI boot, however, the DMI table can live at any physical
      address.  On my laptop, it's around 0x77dd0000.  That's nowhere near
      the legacy ISA range, so the ioremap() implicit uncached type is
      honored and we end up with a UC- mapping.
      
      UC- is a very, very slow way to read from main memory, so dmi_walk()
      is likely to take much longer than necessary.
      
      Given that, even on UEFI, we do early cached DMI reads, it seems
      safe to just ask for cached access.  Switch to ioremap_cache().
      
      I haven't tried to benchmark this, but I'd guess it saves several
      milliseconds of boot time.
      Signed-off-by: default avatarAndy Lutomirski <luto@kernel.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Jean Delvare <jdelvare@suse.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Luis R. Rodriguez <mcgrof@suse.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Toshi Kani <toshi.kani@hp.com>
      Link: http://lkml.kernel.org/r/3147c38e51f439f3c8911db34c7d4ab22d854915.1453791969.git.luto@kernel.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      ce1143aa
    • Andy Lutomirski's avatar
      x86/mm: If INVPCID is available, use it to flush global mappings · d8bced79
      Andy Lutomirski authored
      On my Skylake laptop, INVPCID function 2 (flush absolutely
      everything) takes about 376ns, whereas saving flags, twiddling
      CR4.PGE to flush global mappings, and restoring flags takes about
      539ns.
      Signed-off-by: default avatarAndy Lutomirski <luto@kernel.org>
      Reviewed-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Luis R. Rodriguez <mcgrof@suse.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Toshi Kani <toshi.kani@hp.com>
      Cc: linux-mm@kvack.org
      Link: http://lkml.kernel.org/r/ed0ef62581c0ea9c99b9bf6df726015e96d44743.1454096309.git.luto@kernel.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      d8bced79
    • Andy Lutomirski's avatar
      x86/mm: Add a 'noinvpcid' boot option to turn off INVPCID · d12a72b8
      Andy Lutomirski authored
      This adds a chicken bit to turn off INVPCID in case something goes
      wrong.  It's an early_param() because we do TLB flushes before we
      parse __setup() parameters.
      Signed-off-by: default avatarAndy Lutomirski <luto@kernel.org>
      Reviewed-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Luis R. Rodriguez <mcgrof@suse.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Toshi Kani <toshi.kani@hp.com>
      Cc: linux-mm@kvack.org
      Link: http://lkml.kernel.org/r/f586317ed1bc2b87aee652267e515b90051af385.1454096309.git.luto@kernel.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      d12a72b8
    • Andy Lutomirski's avatar
      x86/mm: Add INVPCID helpers · 060a402a
      Andy Lutomirski authored
      This adds helpers for each of the four currently-specified INVPCID
      modes.
      Signed-off-by: default avatarAndy Lutomirski <luto@kernel.org>
      Reviewed-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Luis R. Rodriguez <mcgrof@suse.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Toshi Kani <toshi.kani@hp.com>
      Cc: linux-mm@kvack.org
      Link: http://lkml.kernel.org/r/8a62b23ad686888cee01da134c91409e22064db9.1454096309.git.luto@kernel.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      060a402a
    • Andrey Ryabinin's avatar
      x86/kasan: Write protect kasan zero shadow · 063fb3e5
      Andrey Ryabinin authored
      After kasan_init() executed, no one is allowed to write to kasan_zero_page,
      so write protect it.
      Signed-off-by: default avatarAndrey Ryabinin <aryabinin@virtuozzo.com>
      Reviewed-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Luis R. Rodriguez <mcgrof@suse.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Toshi Kani <toshi.kani@hp.com>
      Cc: linux-mm@kvack.org
      Link: http://lkml.kernel.org/r/1452516679-32040-3-git-send-email-aryabinin@virtuozzo.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      063fb3e5
    • Andrey Ryabinin's avatar
      x86/kasan: Clear kasan_zero_page after TLB flush · 69e0210f
      Andrey Ryabinin authored
      Currently we clear kasan_zero_page before __flush_tlb_all(). This
      works with current implementation of native_flush_tlb[_global]()
      because it doesn't cause do any writes to kasan shadow memory.
      But any subtle change made in native_flush_tlb*() could break this.
      Also current code seems doesn't work for paravirt guests (lguest).
      
      Only after the TLB flush we can be sure that kasan_zero_page is not
      used as early shadow anymore (instrumented code will not write to it).
      So it should cleared it only after the TLB flush.
      Signed-off-by: default avatarAndrey Ryabinin <aryabinin@virtuozzo.com>
      Reviewed-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Luis R. Rodriguez <mcgrof@suse.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Toshi Kani <toshi.kani@hp.com>
      Cc: linux-mm@kvack.org
      Link: http://lkml.kernel.org/r/1452516679-32040-2-git-send-email-aryabinin@virtuozzo.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      69e0210f
  6. 08 Feb, 2016 4 commits
    • Ingo Molnar's avatar
      x86/mm/numa: Check for failures in numa_clear_kernel_node_hotplug() · 5f7ee246
      Ingo Molnar authored
      numa_clear_kernel_node_hotplug() uses memblock_set_node() without
      checking for failures.
      
      memblock_set_node() is a complex function that might extend the
      memblock array - which extension might fail - so check for this
      possibility.
      
      It's not supposed to happen (because realistically if we have so
      little memory that this fails then we likely won't be able to
      boot anyway), but do the check nevertheless.
      
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Brad Spengler <spender@grsecurity.net>
      Cc: Chen Tang <imtangchen@gmail.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: PaX Team <pageexec@freemail.hu>
      Cc: Taku Izumi <izumi.taku@jp.fujitsu.com>
      Cc: Tang Chen <tangchen@cn.fujitsu.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Wen Congyang <wency@cn.fujitsu.com>
      Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Cc: y14sg1 <y14sg1@comcast.net>
      Cc: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      5f7ee246
    • Ingo Molnar's avatar
      x86/mm/numa: Clean up numa_clear_kernel_node_hotplug() · c1a0bf34
      Ingo Molnar authored
      So we fixed an overflow bug in numa_clear_kernel_node_hotplug():
      
        2b54ab3c66d4 ("x86/mm/numa: Fix memory corruption on 32-bit NUMA kernels")
      
      ... and the bug was indirectly caused by poor coding style,
      such as using start/end local variables unnecessarily, which
      lost the physaddr_t type.
      
      So make the code more readable and try to fully comment all
      the thinking behind the logic.
      
      No change in functionality.
      
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Brad Spengler <spender@grsecurity.net>
      Cc: Chen Tang <imtangchen@gmail.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: PaX Team <pageexec@freemail.hu>
      Cc: Taku Izumi <izumi.taku@jp.fujitsu.com>
      Cc: Tang Chen <tangchen@cn.fujitsu.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Wen Congyang <wency@cn.fujitsu.com>
      Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Cc: y14sg1 <y14sg1@comcast.net>
      Cc: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      c1a0bf34
    • Ingo Molnar's avatar
    • Ingo Molnar's avatar
      x86/mm/numa: Fix 32-bit memblock range truncation bug on 32-bit NUMA kernels · 59fd1214
      Ingo Molnar authored
      The following commit:
      
        a0acda91 ("acpi, numa, mem_hotplug: mark all nodes the kernel resides un-hotpluggable")
      
      Introduced numa_clear_kernel_node_hotplug(), which function is executed
      during early bootup, and which marks all currently reserved memblock
      regions as hot-memory-unswappable as well.
      
      y14sg1 <y14sg1@comcast.net> reported that when running 32-bit NUMA kernels,
      the grsecurity/PAX kernel patch flagged a size overflow in this function:
      
        PAX: size overflow detected in function x86_numa_init arch/x86/mm/numa.c:691 [...]
      
      ... the reason for the overflow is that memblock_clear_hotplug() takes physical
      addresses as arguments, while the start/end variables used by
      numa_clear_kernel_node_hotplug() are 'unsigned long', which is 32-bit on PAE
      kernels, but which has 64-bit physical addresses.
      
      So on 32-bit PAE kernels that have physical memory above the 4GB boundary,
      we truncate a 64-bit physical address range to 32 bits and pass it to
      memblock_clear_hotplug(), which at minimum prevents the original memory-hotplug
      bugfix from working, but might have other side effects as well.
      
      The fix is to use the proper type to handle physical addresses, phys_addr_t.
      Reported-by: default avatary14sg1 <y14sg1@comcast.net>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Brad Spengler <spender@grsecurity.net>
      Cc: Chen Tang <imtangchen@gmail.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: PaX Team <pageexec@freemail.hu>
      Cc: Taku Izumi <izumi.taku@jp.fujitsu.com>
      Cc: Tang Chen <tangchen@cn.fujitsu.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Wen Congyang <wency@cn.fujitsu.com>
      Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Cc: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      59fd1214
  7. 05 Feb, 2016 1 commit
    • Dmitry Vyukov's avatar
      x86: Fix KASAN false positives in thread_saved_pc() · 75edb54a
      Dmitry Vyukov authored
      thread_saved_pc() reads stack of a potentially running task.
      This can cause false KASAN stack-out-of-bounds reports,
      because the running task concurrently poisons and unpoisons
      own stack.
      
      The same happens in get_wchan(), and get get_wchan() was fixed
      by using READ_ONCE_NOCHECK(). Do the same here.
      
      Example KASAN report triggered by sysrq-t:
      
        BUG: KASAN: out-of-bounds in sched_show_task+0x306/0x3b0 at addr ffff880043c97c18
        Read of size 8 by task syz-executor/23839
        [...]
        page dumped because: kasan: bad access detected
        [...]
        Call Trace:
         [<ffffffff8175ea0e>] __asan_report_load8_noabort+0x3e/0x40
         [<ffffffff813e7a26>] sched_show_task+0x306/0x3b0
         [<ffffffff813e7bf4>] show_state_filter+0x124/0x1a0
         [<ffffffff82d2ca00>] fn_show_state+0x10/0x20
         [<ffffffff82d2cf98>] k_spec+0xa8/0xe0
         [<ffffffff82d3354f>] kbd_event+0xb9f/0x4000
         [<ffffffff843ca8a7>] input_to_handler+0x3a7/0x4b0
         [<ffffffff843d1954>] input_pass_values.part.5+0x554/0x6b0
         [<ffffffff843d29bc>] input_handle_event+0x2ac/0x1070
         [<ffffffff843d3a47>] input_inject_event+0x237/0x280
         [<ffffffff843e8c28>] evdev_write+0x478/0x680
         [<ffffffff817ac653>] __vfs_write+0x113/0x480
         [<ffffffff817ae0e7>] vfs_write+0x167/0x4a0
         [<ffffffff817b13d1>] SyS_write+0x111/0x220
      Signed-off-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Acked-by: default avatarAndrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: glider@google.com
      Cc: kasan-dev@googlegroups.com
      Cc: kcc@google.com
      Cc: linux-kernel@vger.kernel.org
      Cc: ryabinin.a.a@gmail.com
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      75edb54a
  8. 03 Feb, 2016 24 commits
  9. 01 Feb, 2016 1 commit
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net · 34229b27
      Linus Torvalds authored
      Pull networking fixes from David Miller:
       "This looks like a lot but it's a mixture of regression fixes as well
        as fixes for longer standing issues.
      
         1) Fix on-channel cancellation in mac80211, from Johannes Berg.
      
         2) Handle CHECKSUM_COMPLETE properly in xt_TCPMSS netfilter xtables
            module, from Eric Dumazet.
      
         3) Avoid infinite loop in UDP SO_REUSEPORT logic, also from Eric
            Dumazet.
      
         4) Avoid a NULL deref if we try to set SO_REUSEPORT after a socket is
            bound, from Craig Gallek.
      
         5) GRO key comparisons don't take lightweight tunnels into account,
            from Jesse Gross.
      
         6) Fix struct pid leak via SCM credentials in AF_UNIX, from Eric
            Dumazet.
      
         7) We need to set the rtnl_link_ops of ipv6 SIT tunnels before we
            register them, otherwise the NEWLINK netlink message is missing
            the proper attributes.  From Thadeu Lima de Souza Cascardo.
      
         8) Several Spectrum chip bug fixes for mlxsw switch driver, from Ido
            Schimmel
      
         9) Handle fragments properly in ipv4 easly socket demux, from Eric
            Dumazet.
      
        10) Don't ignore the ifindex key specifier on ipv6 output route
            lookups, from Paolo Abeni"
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (128 commits)
        tcp: avoid cwnd undo after receiving ECN
        irda: fix a potential use-after-free in ircomm_param_request
        net: tg3: avoid uninitialized variable warning
        net: nb8800: avoid uninitialized variable warning
        net: vxge: avoid unused function warnings
        net: bgmac: clarify CONFIG_BCMA dependency
        net: hp100: remove unnecessary #ifdefs
        net: davinci_cpdma: use dma_addr_t for DMA address
        ipv6/udp: use sticky pktinfo egress ifindex on connect()
        ipv6: enforce flowi6_oif usage in ip6_dst_lookup_tail()
        netlink: not trim skb for mmaped socket when dump
        vxlan: fix a out of bounds access in __vxlan_find_mac
        net: dsa: mv88e6xxx: fix port VLAN maps
        fib_trie: Fix shift by 32 in fib_table_lookup
        net: moxart: use correct accessors for DMA memory
        ipv4: ipconfig: avoid unused ic_proto_used symbol
        bnxt_en: Fix crash in bnxt_free_tx_skbs() during tx timeout.
        bnxt_en: Exclude rx_drop_pkts hw counter from the stack's rx_dropped counter.
        bnxt_en: Ring free response from close path should use completion ring
        net_sched: drr: check for NULL pointer in drr_dequeue
        ...
      34229b27