1. 21 Apr, 2017 7 commits
  2. 20 Apr, 2017 14 commits
  3. 19 Apr, 2017 1 commit
    • Sergei Shtylyov's avatar
      sh_eth: unmap DMA buffers when freeing rings · 1debdc8f
      Sergei Shtylyov authored
      The DMA API debugging (when enabled) causes:
      
      WARNING: CPU: 0 PID: 1445 at lib/dma-debug.c:519 add_dma_entry+0xe0/0x12c
      DMA-API: exceeded 7 overlapping mappings of cacheline 0x01b2974d
      
      to be  printed after repeated initialization of the Ether device, e.g.
      suspend/resume or 'ifconfig' up/down. This is because DMA buffers mapped
      using dma_map_single() in sh_eth_ring_format() and sh_eth_start_xmit() are
      never unmapped. Resolve this problem by unmapping the buffers when freeing
      the descriptor  rings;  in order  to do it right, we'd have to add an extra
      parameter to sh_eth_txfree() (we rename this function to sh_eth_tx_free(),
      while at it).
      
      Based on the commit a47b70ea ("ravb: unmap descriptors when freeing
      rings").
      Signed-off-by: default avatarSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1debdc8f
  4. 18 Apr, 2017 10 commits
  5. 17 Apr, 2017 8 commits
    • Linus Torvalds's avatar
      Merge branch 'parisc-4.11-5' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux · 20bb78f6
      Linus Torvalds authored
      Pull parisc fix from Helge Deller:
       "One patch which fixes get_user() for 64-bit values on 32-bit kernels.
      
        Up to now we lost the upper 32-bits of the returned 64-bit value"
      
      * 'parisc-4.11-5' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
        parisc: Fix get_user() for 64-bit value on 32-bit kernel
      20bb78f6
    • Namhyung Kim's avatar
      ftrace: Fix function pid filter on instances · d879d0b8
      Namhyung Kim authored
      When function tracer has a pid filter, it adds a probe to sched_switch
      to track if current task can be ignored.  The probe checks the
      ftrace_ignore_pid from current tr to filter tasks.  But it misses to
      delete the probe when removing an instance so that it can cause a crash
      due to the invalid tr pointer (use-after-free).
      
      This is easily reproducible with the following:
      
        # cd /sys/kernel/debug/tracing
        # mkdir instances/buggy
        # echo $$ > instances/buggy/set_ftrace_pid
        # rmdir instances/buggy
      
        ============================================================================
        BUG: KASAN: use-after-free in ftrace_filter_pid_sched_switch_probe+0x3d/0x90
        Read of size 8 by task kworker/0:1/17
        CPU: 0 PID: 17 Comm: kworker/0:1 Tainted: G    B           4.11.0-rc3  #198
        Call Trace:
         dump_stack+0x68/0x9f
         kasan_object_err+0x21/0x70
         kasan_report.part.1+0x22b/0x500
         ? ftrace_filter_pid_sched_switch_probe+0x3d/0x90
         kasan_report+0x25/0x30
         __asan_load8+0x5e/0x70
         ftrace_filter_pid_sched_switch_probe+0x3d/0x90
         ? fpid_start+0x130/0x130
         __schedule+0x571/0xce0
         ...
      
      To fix it, use ftrace_clear_pids() to unregister the probe.  As
      instance_rmdir() already updated ftrace codes, it can just free the
      filter safely.
      
      Link: http://lkml.kernel.org/r/20170417024430.21194-2-namhyung@kernel.org
      
      Fixes: 0c8916c3 ("tracing: Add rmdir to remove multibuffer instances")
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarMasami Hiramatsu <mhiramat@kernel.org>
      Signed-off-by: default avatarNamhyung Kim <namhyung@kernel.org>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      d879d0b8
    • David S. Miller's avatar
      Merge branch 'bpf-fixes' · acf167f3
      David S. Miller authored
      Daniel Borkmann says:
      
      ====================
      Two BPF fixes
      
      The set fixes cb_access and xdp_adjust_head bits in struct bpf_prog,
      that are used for requirement checks on the program rather than f.e.
      heuristics. Thus, for tail calls, we cannot make any assumptions and
      are forced to set them.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      acf167f3
    • Daniel Borkmann's avatar
      bpf: fix checking xdp_adjust_head on tail calls · c2002f98
      Daniel Borkmann authored
      Commit 17bedab2 ("bpf: xdp: Allow head adjustment in XDP prog")
      added the xdp_adjust_head bit to the BPF prog in order to tell drivers
      that the program that is to be attached requires support for the XDP
      bpf_xdp_adjust_head() helper such that drivers not supporting this
      helper can reject the program. There are also drivers that do support
      the helper, but need to check for xdp_adjust_head bit in order to move
      packet metadata prepended by the firmware away for making headroom.
      
      For these cases, the current check for xdp_adjust_head bit is insufficient
      since there can be cases where the program itself does not use the
      bpf_xdp_adjust_head() helper, but tail calls into another program that
      uses bpf_xdp_adjust_head(). As such, the xdp_adjust_head bit is still
      set to 0. Since the first program has no control over which program it
      calls into, we need to assume that bpf_xdp_adjust_head() helper is used
      upon tail calls. Thus, for the very same reasons in cb_access, set the
      xdp_adjust_head bit to 1 when the main program uses tail calls.
      
      Fixes: 17bedab2 ("bpf: xdp: Allow head adjustment in XDP prog")
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Cc: Martin KaFai Lau <kafai@fb.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c2002f98
    • Daniel Borkmann's avatar
      bpf: fix cb access in socket filter programs on tail calls · 6b1bb01b
      Daniel Borkmann authored
      Commit ff936a04 ("bpf: fix cb access in socket filter programs")
      added a fix for socket filter programs such that in i) AF_PACKET the
      20 bytes of skb->cb[] area gets zeroed before use in order to not leak
      data, and ii) socket filter programs attached to TCP/UDP sockets need
      to save/restore these 20 bytes since they are also used by protocol
      layers at that time.
      
      The problem is that bpf_prog_run_save_cb() and bpf_prog_run_clear_cb()
      only look at the actual attached program to determine whether to zero
      or save/restore the skb->cb[] parts. There can be cases where the
      actual attached program does not access the skb->cb[], but the program
      tail calls into another program which does access this area. In such
      a case, the zero or save/restore is currently not performed.
      
      Since the programs we tail call into are unknown at verification time
      and can dynamically change, we need to assume that whenever the attached
      program performs a tail call, that later programs could access the
      skb->cb[], and therefore we need to always set cb_access to 1.
      
      Fixes: ff936a04 ("bpf: fix cb access in socket filter programs")
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6b1bb01b
    • Florian Westphal's avatar
      ipv6: drop non loopback packets claiming to originate from ::1 · 0aa8c13e
      Florian Westphal authored
      We lack a saddr check for ::1. This causes security issues e.g. with acls
      permitting connections from ::1 because of assumption that these originate
      from local machine.
      
      Assuming a source address of ::1 is local seems reasonable.
      RFC4291 doesn't allow such a source address either, so drop such packets.
      Reported-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Acked-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0aa8c13e
    • David S. Miller's avatar
      Merge branch 'mediatek-tx-bugs' · 71947f0f
      David S. Miller authored
      Sean Wang says:
      
      ====================
      mediatek: Fix crash caused by reporting inconsistent skb->len to BQL
      
      Changes since v1:
      - fix inconsistent enumeration which easily causes the potential bug
      
      The series fixes kernel BUG caused by inconsistent SKB length reported
      into BQL. The reason for inconsistent length comes from hardware BUG which
      results in different port number carried on the TXD within the lifecycle of
      SKB. So patch 2) is proposed for use a software way to track which port
      the SKB involving instead of hardware way. And patch 1) is given for another
      issue I found which causes TXD and SKB inconsistency that is not expected
      in the initial logic, so it is also being corrected it in the series.
      
      The log for the kernel BUG caused by the issue is posted as below.
      
      [  120.825955] kernel BUG at ... lib/dynamic_queue_limits.c:26!
      [  120.837684] Internal error: Oops - BUG: 0 [#1] SMP ARM
      [  120.842778] Modules linked in:
      [  120.845811] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.11.0-rc1-191576-gdbcef47 #35
      [  120.853488] Hardware name: Mediatek Cortex-A7 (Device Tree)
      [  120.859012] task: c1007480 task.stack: c1000000
      [  120.863510] PC is at dql_completed+0x108/0x17c
      [  120.867915] LR is at 0x46
      [  120.870512] pc : [<c03c19c8>]    lr : [<00000046>]    psr: 80000113
      [  120.870512] sp : c1001d58  ip : c1001d80  fp : c1001d7c
      [  120.881895] r10: 0000003e  r9 : df6b3400  r8 : 0ed86506
      [  120.887075] r7 : 00000001  r6 : 00000001  r5 : 0ed8654c  r4 : df0135d8
      [  120.893546] r3 : 00000001  r2 : df016800  r1 : 0000fece  r0 : df6b3480
      [  120.900018] Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
      [  120.907093] Control: 10c5387d  Table: 9e27806a  DAC: 00000051
      [  120.912789] Process swapper/0 (pid: 0, stack limit = 0xc1000218)
      [  120.918744] Stack: (0xc1001d58 to 0xc1002000)
      
      ....
      
      121.085331] 1fc0: 00000000 c0a52a28 00000000 c10855d4 c1003c58 c0a52a24 c100885c 8000406a
      [  121.093444] 1fe0: 410fc073 00000000 00000000 c1001ff8 8000807c c0a009cc 00000000 00000000
      [  121.101575] [<c03c19c8>] (dql_completed) from [<c04cb010>] (mtk_napi_tx+0x1d0/0x37c)
      [  121.109263] [<c04cb010>] (mtk_napi_tx) from [<c05e28cc>] (net_rx_action+0x24c/0x3b8)
      [  121.116951] [<c05e28cc>] (net_rx_action) from [<c010152c>] (__do_softirq+0xe4/0x35c)
      [  121.124638] [<c010152c>] (__do_softirq) from [<c012a624>] (irq_exit+0xe8/0x150)
      [  121.131895] [<c012a624>] (irq_exit) from [<c017750c>] (__handle_domain_irq+0x70/0xc4)
      [  121.139666] [<c017750c>] (__handle_domain_irq) from [<c0101404>] (gic_handle_irq+0x58/0x9c)
      [  121.147953] [<c0101404>] (gic_handle_irq) from [<c010e18c>] (__irq_svc+0x6c/0x90)
      [  121.155373] Exception stack(0xc1001ef8 to 0xc1001f40)
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      71947f0f
    • Sean Wang's avatar
      net: ethernet: mediatek: fix inconsistency of port number carried in TXD · 134d2152
      Sean Wang authored
      Fix port inconsistency on TXD due to hardware BUG that would cause
      different port number is carried on the same TXD between tx_map()
      and tx_unmap() with the iperf test. It would cause confusing BQL
      logic which leads to kernel panic when dual GMAC runs concurrently.
      Signed-off-by: default avatarSean Wang <sean.wang@mediatek.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      134d2152