Switch branches/tags
Commits on Jan 23, 2018
  1. odroid-c:Modified mcp251x can driver for using amlogic irq.

    Kevin Kim
    Kevin Kim committed Jan 23, 2018
    Change-Id: I127348f69fc4517f7e2e7dea68d6efd35e073320
Commits on Jan 3, 2018
Commits on Dec 4, 2017
  1. display/hdmi: add 480x320p60hz

    JeonghwaCho committed Nov 17, 2017
    Change-Id: I88e3e254650c63630c36d2c523ae82e9ea905967
Commits on Sep 10, 2017
  1. Merge pull request #311 from alegag/odroidc-3.10.y

    mdrjr committed Sep 10, 2017
    Missing ifdef causing compilation issue.  Fixed
  2. Missing ifdef causing compilation issue. Fixed

    alegag committed Sep 10, 2017
    Compilation throw error:
    drivers/amlogic/ethernet/am_net8218.c:1473:2: error: unknown field 'ndo_poll_controller' specified in initializer
      .ndo_poll_controller = fake_netpoll,
    drivers/amlogic/ethernet/am_net8218.c:1473:25: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types]
      .ndo_poll_controller = fake_netpoll,
    drivers/amlogic/ethernet/am_net8218.c:1473:25: note: (near initialization for 'am_netdev_ops.ndo_do_ioctl')
    This declaration depends on CONFIG_NET_POOL_CONTROLLER, the `#ifdef` solves the compilation issue.
Commits on Sep 4, 2017
  1. Merge tag 'v3.10.107' of git://…

    mdrjr committed Sep 3, 2017
    …t/stable/linux-stable into odroidc-3.10.y
    This is the 3.10.107 stable release
Commits on Sep 3, 2017
  1. Merge tag 'v3.10.106' of git://…

    mdrjr committed Sep 3, 2017
    …t/stable/linux-stable into odroidc-3.10.y
    This is the 3.10.106 stable release
  2. Merge tag 'v3.10.105' of git://…

    mdrjr committed Sep 3, 2017
    …t/stable/linux-stable into odroidc-3.10.y
    This is the 3.10.105 stable release
Commits on Jul 5, 2017
  1. Merge pull request #305 from mad-ady/odroidc-3.10.y

    mdrjr committed Jul 5, 2017
    Add fake netpoll support in order to enable netconsole
Commits on Jun 27, 2017
  1. Linux 3.10.107

    Willy Tarreau
    Willy Tarreau committed Jun 27, 2017
Commits on Jun 22, 2017
  1. Allow stack to grow up to address space limit

    hdeller authored and Willy Tarreau committed Jun 19, 2017
    commit bd726c9 upstream.
    Fix expand_upwards() on architectures with an upward-growing stack (parisc,
    metag and partly IA-64) to allow the stack to reliably grow exactly up to
    the address space limit given by TASK_SIZE.
    Signed-off-by: Helge Deller <>
    Acked-by: Hugh Dickins <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Willy Tarreau <>
  2. mm: fix new crash in unmapped_area_topdown()

    Hugh Dickins Willy Tarreau
    Hugh Dickins authored and Willy Tarreau committed Jun 20, 2017
    commit f4cb767 upstream.
    Trinity gets kernel BUG at mm/mmap.c:1963! in about 3 minutes of
    mmap testing.  That's the VM_BUG_ON(gap_end < gap_start) at the
    end of unmapped_area_topdown().  Linus points out how MAP_FIXED
    (which does not have to respect our stack guard gap intentions)
    could result in gap_end below gap_start there.  Fix that, and
    the similar case in its alternative, unmapped_area().
    Fixes: 1be7107 ("mm: larger stack guard gap, between vmas")
    Reported-by: Dave Jones <>
    Debugged-by: Linus Torvalds <>
    Signed-off-by: Hugh Dickins <>
    Acked-by: Michal Hocko <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Willy Tarreau <>
Commits on Jun 21, 2017
  1. mm: larger stack guard gap, between vmas

    Hugh Dickins Willy Tarreau
    Hugh Dickins authored and Willy Tarreau committed Jun 19, 2017
    commit 1be7107 upstream.
    Stack guard page is a useful feature to reduce a risk of stack smashing
    into a different mapping. We have been using a single page gap which
    is sufficient to prevent having stack adjacent to a different mapping.
    But this seems to be insufficient in the light of the stack usage in
    userspace. E.g. glibc uses as large as 64kB alloca() in many commonly
    used functions. Others use constructs liks gid_t buffer[NGROUPS_MAX]
    which is 256kB or stack strings with MAX_ARG_STRLEN.
    This will become especially dangerous for suid binaries and the default
    no limit for the stack size limit because those applications can be
    tricked to consume a large portion of the stack and a single glibc call
    could jump over the guard page. These attacks are not theoretical,
    Make those attacks less probable by increasing the stack guard gap
    to 1MB (on systems with 4k pages; but make it depend on the page size
    because systems with larger base pages might cap stack allocations in
    the PAGE_SIZE units) which should cover larger alloca() and VLA stack
    allocations. It is obviously not a full fix because the problem is
    somehow inherent, but it should reduce attack space a lot.
    One could argue that the gap size should be configurable from userspace,
    but that can be done later when somebody finds that the new 1MB is wrong
    for some special case applications.  For now, add a kernel command line
    option (stack_guard_gap) to specify the stack gap size (in page units).
    Implementation wise, first delete all the old code for stack guard page:
    because although we could get away with accounting one extra page in a
    stack vma, accounting a larger gap can break userspace - case in point,
    a program run with "ulimit -S -v 20000" failed when the 1MB gap was
    counted for RLIMIT_AS; similar problems could come with RLIMIT_MLOCK
    and strict non-overcommit mode.
    Instead of keeping gap inside the stack vma, maintain the stack guard
    gap as a gap between vmas: using vm_start_gap() in place of vm_start
    (or vm_end_gap() in place of vm_end if VM_GROWSUP) in just those few
    places which need to respect the gap - mainly arch_get_unmapped_area(),
    and and the vma tree's subtree_gap support for that.
    Original-patch-by: Oleg Nesterov <>
    Original-patch-by: Michal Hocko <>
    Signed-off-by: Hugh Dickins <>
    [wt: backport to 4.11: adjust context]
    [wt: backport to 4.9: adjust context ; kernel doc was not in admin-guide]
    [wt: backport to 4.4: adjust context ; drop ppc hugetlb_radix changes]
    [wt: backport to 3.18: adjust context ; no FOLL_POPULATE ;
         s390 uses generic arch_get_unmapped_area()]
    [wt: backport to 3.16: adjust context]
    [wt: backport to 3.10: adjust context ; code logic in PARISC's
         arch_get_unmapped_area() wasn't found ; code inserted into
         expand_upwards() and expand_downwards() runs under anon_vma lock;
         changes for gup.c:faultin_page go to memory.c:__get_user_pages();
         included Hugh Dickins' fixes]
    Signed-off-by: Willy Tarreau <>
Commits on Jun 20, 2017
  1. x86/mm/32: Enable full randomization on i386 and X86_32

    Hector Marco-Gisbert Willy Tarreau
    Hector Marco-Gisbert authored and Willy Tarreau committed Mar 10, 2016
    commit 8b8addf upstream.
    Currently on i386 and on X86_64 when emulating X86_32 in legacy mode, only
    the stack and the executable are randomized but not other mmapped files
    (libraries, vDSO, etc.). This patch enables randomization for the
    libraries, vDSO and mmap requests on i386 and in X86_32 in legacy mode.
    By default on i386 there are 8 bits for the randomization of the libraries,
    vDSO and mmaps which only uses 1MB of VA.
    This patch preserves the original randomness, using 1MB of VA out of 3GB or
    4GB. We think that 1MB out of 3GB is not a big cost for having the ASLR.
    The first obvious security benefit is that all objects are randomized (not
    only the stack and the executable) in legacy mode which highly increases
    the ASLR effectiveness, otherwise the attackers may use these
    non-randomized areas. But also sensitive setuid/setgid applications are
    more secure because currently, attackers can disable the randomization of
    these applications by setting the ulimit stack to "unlimited". This is a
    very old and widely known trick to disable the ASLR in i386 which has been
    allowed for too long.
    Another trick used to disable the ASLR was to set the ADDR_NO_RANDOMIZE
    personality flag, but fortunately this doesn't work on setuid/setgid
    applications because there is security checks which clear Security-relevant
    This patch always randomizes the mmap_legacy_base address, removing the
    possibility to disable the ASLR by setting the stack to "unlimited".
    Signed-off-by: Hector Marco-Gisbert <>
    Acked-by: Ismael Ripoll Ripoll <>
    Acked-by: Kees Cook <>
    Acked-by: Arjan van de Ven <>
    Cc: Linus Torvalds <>
    Cc: Peter Zijlstra <>
    Cc: Thomas Gleixner <>
    Cc: kees Cook <>
    Signed-off-by: Ingo Molnar <>
    Signed-off-by: Ben Hutchings <>
    Signed-off-by: Willy Tarreau <>
  2. x86: standardize mmap_rnd() usage

    kees authored and Willy Tarreau committed Apr 14, 2015
    commit 8216814 upstream.
    In preparation for splitting out ET_DYN ASLR, this refactors the use of
    mmap_rnd() to be used similarly to arm, and extracts the checking of
    Signed-off-by: Kees Cook <>
    Reviewed-by: Ingo Molnar <>
    Cc: Oleg Nesterov <>
    Cc: Andy Lutomirski <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Ben Hutchings <>
    Signed-off-by: Willy Tarreau <>
  3. ipv6: check raw payload size correctly in ioctl

    jbainbri authored and Willy Tarreau committed Apr 26, 2017
    commit 105f552 upstream.
    In situations where an skb is paged, the transport header pointer and
    tail pointer can be the same because the skb contents are in frags.
    This results in ioctl(SIOCINQ/FIONREAD) incorrectly returning a
    length of 0 when the length to receive is actually greater than zero.
    skb->len is already correctly set in ip6_input_finish() with
    pskb_pull(), so use skb->len as it always returns the correct result
    for both linear and paged data.
    Signed-off-by: Jamie Bainbridge <>
    Signed-off-by: Willy Tarreau <>
  4. printk: use rcuidle console tracepoint

    Sergey Senozhatsky Willy Tarreau
    Sergey Senozhatsky authored and Willy Tarreau committed Feb 18, 2017
    commit fc98c3c upstream.
    Use rcuidle console tracepoint because, apparently, it may be issued
    from an idle CPU:
      hw-breakpoint: Failed to enable monitor mode on CPU 0.
      hw-breakpoint: CPU 0 failed to disable vector catch
      [ ERR: suspicious RCU usage.  ]
      4.10.0-rc8-next-20170215+ #119 Not tainted
      ./include/trace/events/printk.h:32 suspicious rcu_dereference_check() usage!
      other info that might help us debug this:
      RCU used illegally from idle CPU!
      rcu_scheduler_active = 2, debug_locks = 0
      RCU used illegally from extended quiescent state!
      2 locks held by swapper/0/0:
       #0:  (cpu_pm_notifier_lock){......}, at: [<c0237e2c>] cpu_pm_exit+0x10/0x54
       #1:  (console_lock){+.+.+.}, at: [<c01ab350>] vprintk_emit+0x264/0x474
      stack backtrace:
      CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.10.0-rc8-next-20170215+ #119
      Hardware name: Generic OMAP4 (Flattened Device Tree)
    This RCU warning, however, is suppressed by lockdep_off() in printk().
    lockdep_off() increments the ->lockdep_recursion counter and thus
    disables RCU_LOCKDEP_WARN() and debug_lockdep_rcu_enabled(), which want
    lockdep to be enabled "current->lockdep_recursion == 0".
    Signed-off-by: Sergey Senozhatsky <>
    Reported-by: Tony Lindgren <>
    Tested-by: Tony Lindgren <>
    Acked-by: Paul E. McKenney <>
    Acked-by: Steven Rostedt (VMware) <>
    Cc: Petr Mladek <>
    Cc: Peter Zijlstra <>
    Cc: Thomas Gleixner <>
    Cc: Tony Lindgren <>
    Cc: Russell King <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>
    [wt: changes are in kernel/printk.c in 3.10]
    Signed-off-by: Willy Tarreau <>
  5. tun: read vnet_hdr_sz once

    wdebruij authored and Willy Tarreau committed Feb 3, 2017
    commit e1edab8 upstream.
    When IFF_VNET_HDR is enabled, a virtio_net header must precede data.
    Data length is verified to be greater than or equal to expected header
    length tun->vnet_hdr_sz before copying.
    Read this value once and cache locally, as it can be updated between
    the test and use (TOCTOU).
    [js] we have TUN_VNET_HDR in 3.12
    Signed-off-by: Willem de Bruijn <>
    Reported-by: Dmitry Vyukov <>
    CC: Eric Dumazet <>
    Acked-by: Eric Dumazet <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Jiri Slaby <>
    Signed-off-by: Willy Tarreau <>
  6. kvm: nVMX: Allow L1 to intercept software exceptions (#BP and #OF)

    Jim Mattson Willy Tarreau
    Jim Mattson authored and Willy Tarreau committed Dec 12, 2016
    commit ef85b67 upstream.
    When L2 exits to L0 due to "exception or NMI", software exceptions
    (#BP and #OF) for which L1 has requested an intercept should be
    handled by L1 rather than L0. Previously, only hardware exceptions
    were forwarded to L1.
    Signed-off-by: Jim Mattson <>
    Signed-off-by: Paolo Bonzini <>
    Signed-off-by: Willy Tarreau <>
  7. ftrace/x86: Fix triple fault with graph tracing and suspend-to-ram

    jpoimboe authored and Willy Tarreau committed Apr 13, 2017
    commit 34a477e upstream.
    On x86-32, with CONFIG_FIRMWARE and multiple CPUs, if you enable function
    graph tracing and then suspend to RAM, it will triple fault and reboot when
    it resumes.
    The first fault happens when booting a secondary CPU:
            (accesses 'kill_ftrace_graph')
    The early head_32.S code calls into load_ucode_ap(), which has an an
    ftrace hook, so it calls prepare_ftrace_return(), which calls
    ftrace_graph_is_dead(), which tries to access the global
    'kill_ftrace_graph' variable with a virtual address, causing a fault
    because the CPU is still in real mode.
    The fix is to add a check in prepare_ftrace_return() to make sure it's
    running in protected mode before continuing.  The check makes sure the
    stack pointer is a virtual kernel address.  It's a bit of a hack, but
    it's not very intrusive and it works well enough.
    For reference, here are a few other (more difficult) ways this could
    have potentially been fixed:
    - Move startup_32_smp()'s call to load_ucode_ap() down to *after* paging
      is enabled.  (No idea what that would break.)
    - Track down load_ucode_ap()'s entire callee tree and mark all the
      functions 'notrace'.  (Probably not realistic.)
    - Pause graph tracing in ftrace_suspend_notifier_call() or bringup_cpu()
      or __cpu_up(), and ensure that the pause facility can be queried from
      real mode.
    Reported-by: Paul Menzel <>
    Signed-off-by: Josh Poimboeuf <>
    Tested-by: Paul Menzel <>
    Reviewed-by: Steven Rostedt (VMware) <>
    Cc: "Rafael J . Wysocki" <>
    Cc: Borislav Petkov <>
    Cc: Len Brown <>
    Signed-off-by: Thomas Gleixner <>
    Signed-off-by: Willy Tarreau <>
  8. nfsd: check for oversized NFSv2/v3 arguments

    J. Bruce Fields Willy Tarreau
    J. Bruce Fields authored and Willy Tarreau committed Apr 21, 2017
    commit e6838a2 upstream.
    A client can append random data to the end of an NFSv2 or NFSv3 RPC call
    without our complaining; we'll just stop parsing at the end of the
    expected data and ignore the rest.
    Encoded arguments and replies are stored together in an array of pages,
    and if a call is too large it could leave inadequate space for the
    reply.  This is normally OK because NFS RPC's typically have either
    short arguments and long replies (like READ) or long arguments and short
    replies (like WRITE).  But a client that sends an incorrectly long reply
    can violate those assumptions.  This was observed to cause crashes.
    Also, several operations increment rq_next_page in the decode routine
    before checking the argument size, which can leave rq_next_page pointing
    well past the end of the page array, causing trouble later in
    So, following a suggestion from Neil Brown, add a central check to
    enforce our expectation that no NFSv2/v3 call has both a large call and
    a large reply.
    As followup we may also want to rewrite the encoding routines to check
    more carefully that they aren't running off the end of the page array.
    We may also consider rejecting calls that have any extra garbage
    appended.  That would be safer, and within our rights by spec, but given
    the age of our server and the NFS protocol, and the fact that we've
    never enforced this before, we may need to balance that against the
    possibility of breaking some oddball client.
    Reported-by: Tuomas Haanpää <>
    Reported-by: Ari Kauppi <>
    Reviewed-by: NeilBrown <>
    Signed-off-by: J. Bruce Fields <>
    Signed-off-by: Willy Tarreau <>
  9. p9_client_readdir() fix

    Al Viro Willy Tarreau
    Al Viro authored and Willy Tarreau committed Apr 14, 2017
    commit 71d6ad0 upstream.
    Don't assume that server is sane and won't return more data than
    asked for.
    Signed-off-by: Al Viro <>
    Signed-off-by: Willy Tarreau <>
  10. xen/x86: don't lose event interrupts

    sstabellini authored and Willy Tarreau committed Apr 16, 2016
    commit c06b6d7 upstream.
    On slow platforms with unreliable TSC, such as QEMU emulated machines,
    it is possible for the kernel to request the next event in the past. In
    that case, in the current implementation of xen_vcpuop_clockevent, we
    simply return -ETIME. To be precise the Xen returns -ETIME and we pass
    it on. However the result of this is a missed event, which simply causes
    the kernel to hang.
    Instead it is better to always ask the hypervisor for a timer event,
    even if the timeout is in the past. That way there are no lost
    interrupts and the kernel survives. To do that, remove the
    VCPU_SSHOTTMR_future flag.
    Signed-off-by: Stefano Stabellini <>
    Acked-by: Juergen Gross <>
    Cc: Julia Lawall <>
    Signed-off-by: Jiri Slaby <>
    Signed-off-by: Willy Tarreau <>
  11. RDS: Fix the atomicity for congestion map update

    SantoshShilimkar authored and Willy Tarreau committed Apr 14, 2016
    commit e47db94 upstream.
    Two different threads with different rds sockets may be in
    rds_recv_rcvbuf_delta() via receive path. If their ports
    both map to the same word in the congestion map, then
    using non-atomic ops to update it could cause the map to
    be incorrect. Lets use atomics to avoid such an issue.
    Full credit to Wengang <> for
    finding the issue, analysing it and also pointing out
    to offending code with spin lock based fix.
    Reviewed-by: Leon Romanovsky <>
    Signed-off-by: Wengang Wang <>
    Signed-off-by: Santosh Shilimkar <>
    Signed-off-by: David S. Miller <>
    Cc: Julia Lawall <>
    Signed-off-by: Jiri Slaby <>
    Signed-off-by: Willy Tarreau <>
  12. MIPS: Fix crash registers on non-crashing CPUs

    cminyard authored and Willy Tarreau committed Apr 11, 2016
    commit c80e1b6 upstream.
    As part of handling a crash on an SMP system, an IPI is send to
    all other CPUs to save their current registers and stop.  It was
    using task_pt_regs(current) to get the registers, but that will
    only be accurate if the CPU was interrupted running in userland.
    Instead allow the architecture to pass in the registers (all
    pass NULL now, but allow for the future) and then use get_irq_regs()
    which should be accurate as we are in an interrupt.  Fall back to
    task_pt_regs(current) if nothing else is available.
    Signed-off-by: Corey Minyard <>
    Cc: David Daney <>
    Signed-off-by: Ralf Baechle <>
    Cc: Julia Lawall <>
    Signed-off-by: Jiri Slaby <>
    Signed-off-by: Willy Tarreau <>
  13. ip6mr: fix notification device destruction

    Nikolay Aleksandrov Willy Tarreau
    Nikolay Aleksandrov authored and Willy Tarreau committed Apr 21, 2017
    commit 723b929 upstream.
    Andrey Konovalov reported a BUG caused by the ip6mr code which is caused
    because we call unregister_netdevice_many for a device that is already
    being destroyed. In IPv4's ipmr that has been resolved by two commits
    long time ago by introducing the "notify" parameter to the delete
    function and avoiding the unregister when called from a notifier, so
    let's do the same for ip6mr.
    The trace from Andrey:
    ------------[ cut here ]------------
    kernel BUG at net/core/dev.c:6813!
    invalid opcode: 0000 [#1] SMP KASAN
    Modules linked in:
    CPU: 1 PID: 1165 Comm: kworker/u4:3 Not tainted 4.11.0-rc7+ #251
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs
    Workqueue: netns cleanup_net
    task: ffff880069208000 task.stack: ffff8800692d8000
    RIP: 0010:rollback_registered_many+0x348/0xeb0 net/core/dev.c:6813
    RSP: 0018:ffff8800692de7f0 EFLAGS: 00010297
    RAX: ffff880069208000 RBX: 0000000000000002 RCX: 0000000000000001
    RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88006af90569
    RBP: ffff8800692de9f0 R08: ffff8800692dec60 R09: 0000000000000000
    R10: 0000000000000006 R11: 0000000000000000 R12: ffff88006af90070
    R13: ffff8800692debf0 R14: dffffc0000000000 R15: ffff88006af90000
    FS:  0000000000000000(0000) GS:ffff88006cb00000(0000)
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007fe7e897d870 CR3: 00000000657e7000 CR4: 00000000000006e0
    Call Trace:
     unregister_netdevice_many.part.105+0x87/0x440 net/core/dev.c:7881
     unregister_netdevice_many+0xc8/0x120 net/core/dev.c:7880
     ip6mr_device_event+0x362/0x3f0 net/ipv6/ip6mr.c:1346
     notifier_call_chain+0x145/0x2f0 kernel/notifier.c:93
     __raw_notifier_call_chain kernel/notifier.c:394
     raw_notifier_call_chain+0x2d/0x40 kernel/notifier.c:401
     call_netdevice_notifiers_info+0x51/0x90 net/core/dev.c:1647
     call_netdevice_notifiers net/core/dev.c:1663
     rollback_registered_many+0x919/0xeb0 net/core/dev.c:6841
     unregister_netdevice_many.part.105+0x87/0x440 net/core/dev.c:7881
     unregister_netdevice_many net/core/dev.c:7880
     default_device_exit_batch+0x4fa/0x640 net/core/dev.c:8333
     ops_exit_list.isra.4+0x100/0x150 net/core/net_namespace.c:144
     cleanup_net+0x5a8/0xb40 net/core/net_namespace.c:463
     process_one_work+0xc04/0x1c10 kernel/workqueue.c:2097
     worker_thread+0x223/0x19c0 kernel/workqueue.c:2231
     kthread+0x35e/0x430 kernel/kthread.c:231
     ret_from_fork+0x31/0x40 arch/x86/entry/entry_64.S:430
    Code: 3c 32 00 0f 85 70 0b 00 00 48 b8 00 02 00 00 00 00 ad de 49 89
    47 78 e9 93 fe ff ff 49 8d 57 70 49 8d 5f 78 eb 9e e8 88 7a 14 fe <0f>
    0b 48 8b 9d 28 fe ff ff e8 7a 7a 14 fe 48 b8 00 00 00 00 00
    RIP: rollback_registered_many+0x348/0xeb0 RSP: ffff8800692de7f0
    ---[ end trace e0b29c57e9b3292c ]---
    Reported-by: Andrey Konovalov <>
    Signed-off-by: Nikolay Aleksandrov <>
    Tested-by: Andrey Konovalov <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Willy Tarreau <>
  14. sctp: listen on the sock only when it's state is listening or closed

    lxin authored and Willy Tarreau committed Apr 6, 2017
    commit 34b2789 upstream.
    Now sctp doesn't check sock's state before listening on it. It could
    even cause changing a sock with any state to become a listening sock
    when doing sctp_listen.
    This patch is to fix it by checking sock's state in sctp_listen, so
    that it will listen on the sock with right state.
    Reported-by: Andrey Konovalov <>
    Tested-by: Andrey Konovalov <>
    Signed-off-by: Xin Long <>
    Acked-by: Marcelo Ricardo Leitner <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Willy Tarreau <>
  15. net: neigh: guard against NULL solicit() method

    Eric Dumazet Willy Tarreau
    Eric Dumazet authored and Willy Tarreau committed Mar 23, 2017
    commit 48481c8 upstream.
    Dmitry posted a nice reproducer of a bug triggering in neigh_probe()
    when dereferencing a NULL neigh->ops->solicit method.
    This can happen for arp_direct_ops/ndisc_direct_ops and similar,
    which can be used for NUD_NOARP neighbours (created when dev->header_ops
    is NULL). Admin can then force changing nud_state to some other state
    that would fire neigh timer.
    Signed-off-by: Eric Dumazet <>
    Reported-by: Dmitry Vyukov <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Willy Tarreau <>
  16. gfs2: avoid uninitialized variable warning

    arndb authored and Willy Tarreau committed Jan 26, 2016
    commit 67893f1 upstream.
    We get a bogus warning about a potential uninitialized variable
    use in gfs2, because the compiler does not figure out that we
    never use the leaf number if get_leaf_nr() returns an error:
    fs/gfs2/dir.c: In function 'get_first_leaf':
    fs/gfs2/dir.c:802:9: warning: 'leaf_no' may be used uninitialized in this function [-Wmaybe-uninitialized]
    fs/gfs2/dir.c: In function 'dir_split_leaf':
    fs/gfs2/dir.c:1021:8: warning: 'leaf_no' may be used uninitialized in this function [-Wmaybe-uninitialized]
    Changing the 'if (!error)' to 'if (!IS_ERR_VALUE(error))' is
    sufficient to let gcc understand that this is exactly the same
    condition as in IS_ERR() so it can optimize the code path enough
    to understand it.
    Signed-off-by: Arnd Bergmann <>
    Signed-off-by: Bob Peterson <>
    Signed-off-by: Willy Tarreau <>
  17. hostap: avoid uninitialized variable use in hfa384x_get_rid

    arndb authored and Willy Tarreau committed Jan 28, 2016
    commit 48dc5fb upstream.
    The driver reads a value from hfa384x_from_bap(), which may fail,
    and then assigns the value to a local variable. gcc detects that
    in in the failure case, the 'rlen' variable now contains
    uninitialized data:
    In file included from ../drivers/net/wireless/intersil/hostap/hostap_pci.c:220:0:
    drivers/net/wireless/intersil/hostap/hostap_hw.c: In function 'hfa384x_get_rid':
    drivers/net/wireless/intersil/hostap/hostap_hw.c:842:5: warning: 'rec' may be used uninitialized in this function [-Wmaybe-uninitialized]
      if (le16_to_cpu(rec.len) == 0) {
    This restructures the function as suggested by Russell King, to
    make it more readable and get more reliable error handling, by
    handling each failure mode using a goto.
    Signed-off-by: Arnd Bergmann <>
    Signed-off-by: Kalle Valo <>
    Signed-off-by: Willy Tarreau <>
  18. tty: nozomi: avoid a harmless gcc warning

    arndb authored and Willy Tarreau committed Jan 25, 2016
    commit a4f642a upstream.
    The nozomi wireless data driver has its own helper function to
    transfer data from a FIFO, doing an extra byte swap on big-endian
    architectures, presumably to bring the data back into byte-serial
    order after readw() or readl() perform their implicit byteswap.
    This helper function is used in the receive_data() function to
    first read the length into a 32-bit variable, which causes
    a compile-time warning:
    drivers/tty/nozomi.c: In function 'receive_data':
    drivers/tty/nozomi.c:857:9: warning: 'size' may be used uninitialized in this function [-Wmaybe-uninitialized]
    The problem is that gcc is unsure whether the data was actually
    read or not. We know that it is at this point, so we can replace
    it with a single readl() to shut up that warning.
    I am leaving the byteswap in there, to preserve the existing
    behavior, even though this seems fishy: Reading the length of
    the data into a cpu-endian variable should normally not use
    a second byteswap on big-endian systems, unless the hardware
    is aware of the CPU endianess.
    There appears to be a lot more confusion about endianess in this
    driver, so it probably has not worked on big-endian systems in
    a long time, if ever, and I have no way to test it. It's well
    possible that this driver has not been used by anyone in a while,
    the last patch that looks like it was tested on the hardware is
    from 2008.
    Signed-off-by: Arnd Bergmann <>
    Signed-off-by: Willy Tarreau <>
  19. net/packet: fix overflow in check for tp_reserve

    xairy authored and Willy Tarreau committed Mar 29, 2017
    commit bcc5364 upstream.
    When calculating po->tp_hdrlen + po->tp_reserve the result can overflow.
    Fix by checking that tp_reserve <= INT_MAX on assign.
    Signed-off-by: Andrey Konovalov <>
    Acked-by: Eric Dumazet <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Willy Tarreau <>
  20. net/packet: fix overflow in check for tp_frame_nr

    xairy authored and Willy Tarreau committed Mar 29, 2017
    commit 8f8d28e upstream.
    When calculating rb->frames_per_block * req->tp_block_nr the result
    can overflow.
    Add a check that tp_block_size * tp_block_nr <= UINT_MAX.
    Since frames_per_block <= tp_block_size, the expression would
    never overflow.
    Signed-off-by: Andrey Konovalov <>
    Acked-by: Eric Dumazet <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Willy Tarreau <>
  21. powerpc: Reject binutils 2.24 when building little endian

    mpe authored and Willy Tarreau committed Apr 23, 2015
    commit 60e065f upstream.
    There is a bug in binutils 2.24 which causes miscompilation if we're
    building little endian and using weak symbols (which the kernel does).
    It is fixed in binutils commit 57fa7b8c7e59 "Correct elf_merge_st_other
    arguments for weak symbols", which is in binutils 2.25 and has been
    backported to the binutils 2.24 branch and has been picked up by most
    distros it seems.
    However if we're running stock 2.24 (no extra version) then the bug is
    present, so check for that and bail.
    Signed-off-by: Michael Ellerman <>
    Signed-off-by: Willy Tarreau <>