1. 04 Oct, 2016 6 commits
    • Stefan Assmann's avatar
      i40e: fix MSI-X vector redistribution if hw limit is reached · 4ce20abc
      Stefan Assmann authored
      The driver allocates 1 vector per CPU thread and the current hardware
      limit for vectors is 129 per PF. On systems with 128 or more threads
      this currently means all vectors are used by the PF leaving no room for
      additional features like VMDq, iWARP, etc...
      The code that should redistribute the vectors in this case is broken and
      never triggers. Fixed the code so that it actually triggers if the
      hardware limit is reached and adjust the number of queue pairs
      accordingly.
      Also the number of initially requested iWARP vectors was not properly
      saved when the vector limit was reached, and therefore always zero.
      
      Comparison with debug statement.
      Before:
      i40e 0000:2d:00.0: VMDq disabled, not enough MSI-X vectors
      i40e 0000:2d:00.0: IWARP disabled, not enough MSI-X vectors
      i40e 00.0 MSI-X vector distribution: PF 128, VMDq 0, FDSB 0, iWARP 0
      After:
      i40e 0000:2d:00.0: MSI-X vector limit reached, attempting to redistribute vectors
      i40e 00.0 MSI-X vector distribution: PF 78, VMDq 8, FDSB 0, iWARP 42
      Signed-off-by: default avatarStefan Assmann <sassmann@kpanic.de>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      4ce20abc
    • Stefan Assmann's avatar
      i40e: check if vectors are already depleted when doing VMDq allocation · 9ca57e97
      Stefan Assmann authored
      During MSI-X vector allocation for VMDq, a check for "no vectors left"
      was missing, add it. This prevents more vectors to be allocated than
      available.
      Signed-off-by: default avatarStefan Assmann <sassmann@kpanic.de>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      9ca57e97
    • Christophe Jaillet's avatar
      ptp: Fix resource leak in case of error · b9118b72
      Christophe Jaillet authored
      A call to 'ida_simple_remove()' is missing in the error handling path.
      
      This as been spotted with the following coccinelle script which tries to
      detect missing 'ida_simple_remove()' call in error handling paths.
      
      ///////////////
      @@
      expression x;
      identifier l;
      @@
      
      *   x = ida_simple_get(...);
          ...
          if (...) {
          ...
          }
          ...
          if (...) {
             ...
             goto l;
          }
          ...
      *   l: ... when != ida_simple_remove(...);
      Signed-off-by: default avatarChristophe JAILLET <christophe.jaillet@wanadoo.fr>
      Acked-by: default avatarRichard Cochran <richardcochran@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b9118b72
    • Wei Yongjun's avatar
      net: qcom/emac: fix return value check in emac_sgmii_config() · 0fd7d43f
      Wei Yongjun authored
      In case of error, the function ioremap() returns NULL pointer
      not ERR_PTR(). The IS_ERR() test in the return value check
      should be replaced with NULL test.
      
      Also add check for return value of platform_get_resource().
      
      Fixes: 54e19bc7 ("net: qcom/emac: do not use devm on internal
      phy pdev")
      Signed-off-by: default avatarWei Yongjun <weiyongjun1@huawei.com>
      Acked-by: default avatarTimur Tabi <timur@codeaurora.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0fd7d43f
    • Shmulik Ladkani's avatar
      net: skbuff: Limit skb_vlan_pop/push() to expect skb->data at mac header · b6a79208
      Shmulik Ladkani authored
      skb_vlan_pop/push were too generic, trying to support the cases where
      skb->data is at mac header, and cases where skb->data is arbitrarily
      elsewhere.
      
      Supporting an arbitrary skb->data was complex and bogus:
       - It failed to unwind skb->data to its original location post actual
         pop/push.
         (Also, semantic is not well defined for unwinding: If data was into
          the eth header, need to use same offset from start; But if data was
          at network header or beyond, need to adjust the original offset
          according to the push/pull)
       - It mangled the rcsum post actual push/pop, without taking into account
         that the eth bytes might already have been pulled out of the csum.
      
      Most callers (ovs, bpf) already had their skb->data at mac_header upon
      invoking skb_vlan_pop/push.
      Last caller that failed to do so (act_vlan) has been recently fixed.
      
      Therefore, to simplify things, no longer support arbitrary skb->data
      inputs for skb_vlan_pop/push().
      
      skb->data is expected to be exactly at mac_header; WARN otherwise.
      Signed-off-by: default avatarShmulik Ladkani <shmulik.ladkani@gmail.com>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: Pravin Shelar <pshelar@ovn.org>
      Cc: Jiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b6a79208
    • Shmulik Ladkani's avatar
      net/sched: act_vlan: Push skb->data to mac_header prior calling skb_vlan_*() functions · f39acc84
      Shmulik Ladkani authored
      Generic skb_vlan_push/skb_vlan_pop functions don't properly handle the
      case where the input skb data pointer does not point at the mac header:
      
      - They're doing push/pop, but fail to properly unwind data back to its
        original location.
        For example, in the skb_vlan_push case, any subsequent
        'skb_push(skb, skb->mac_len)' calls make the skb->data point 4 bytes
        BEFORE start of frame, leading to bogus frames that may be transmitted.
      
      - They update rcsum per the added/removed 4 bytes tag.
        Alas if data is originally after the vlan/eth headers, then these
        bytes were already pulled out of the csum.
      
      OTOH calling skb_vlan_push/skb_vlan_pop with skb->data at mac_header
      present no issues.
      
      act_vlan is the only caller to skb_vlan_*() that has skb->data pointing
      at network header (upon ingress).
      Other calles (ovs, bpf) already adjust skb->data at mac_header.
      
      This patch fixes act_vlan to point to the mac_header prior calling
      skb_vlan_*() functions, as other callers do.
      Signed-off-by: default avatarShmulik Ladkani <shmulik.ladkani@gmail.com>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: Pravin Shelar <pshelar@ovn.org>
      Cc: Jiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f39acc84
  2. 03 Oct, 2016 17 commits
  3. 02 Oct, 2016 7 commits
    • Linus Torvalds's avatar
      Linux 4.8 · c8d2bc9b
      Linus Torvalds authored
      c8d2bc9b
    • Linus Torvalds's avatar
      Merge branch 'fixes' of git://git.armlinux.org.uk/~rmk/linux-arm · f76d9c61
      Linus Torvalds authored
      Pull ARM fixes from Russell King:
       "Three relatively small fixes for ARM:
      
         - Roger noticed that dma_max_pfn() was calculating the upper limit
           wrongly, by adding the PFN offset of memory twice.
      
         - A fix from Robin to correct parsing of MPIDR values when the
           address size is larger than one BE32 unit.
      
         - A fix from Srinivas to ensure that we do not rely on the boot
           loader (or previous Linux kernel) setting the translation table
           base register a certain way in the decompressor, which can lead to
           crashes"
      
      * 'fixes' of git://git.armlinux.org.uk/~rmk/linux-arm:
        ARM: 8618/1: decompressor: reset ttbcr fields to use TTBR0 on ARMv7
        ARM: 8617/1: dma: fix dma_max_pfn()
        ARM: 8616/1: dt: Respect property size when parsing CPUs
      f76d9c61
    • Srinivas Ramana's avatar
      ARM: 8618/1: decompressor: reset ttbcr fields to use TTBR0 on ARMv7 · 117e5e9c
      Srinivas Ramana authored
      If the bootloader uses the long descriptor format and jumps to
      kernel decompressor code, TTBCR may not be in a right state.
      Before enabling the MMU, it is required to clear the TTBCR.PD0
      field to use TTBR0 for translation table walks.
      
      The commit dbece458 ("ARM: 7501/1: decompressor:
      reset ttbcr for VMSA ARMv7 cores") does the reset of TTBCR.N, but
      doesn't consider all the bits for the size of TTBCR.N.
      
      Clear TTBCR.PD0 field and reset all the three bits of TTBCR.N to
      indicate the use of TTBR0 and the correct base address width.
      
      Fixes: dbece458 ("ARM: 7501/1: decompressor: reset ttbcr for VMSA ARMv7 cores")
      Acked-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Signed-off-by: default avatarSrinivas Ramana <sramana@codeaurora.org>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      117e5e9c
    • Linus Torvalds's avatar
      Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · be67d60b
      Linus Torvalds authored
      Pull x86 fixes from Thomas Gleixner:
       "The last regression fixes for 4.8 final:
      
         - Two patches addressing the fallout of the CR4 optimizations which
           caused CR4-less machines to fail.
      
         - Fix the VDSO build on big endian machines
      
         - Take care of FPU initialization if no CPUID is available otherwise
           task struct size ends up being zero
      
         - Fix up context tracking in case load_gs_index fails"
      
      * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        x86/entry/64: Fix context tracking state warning when load_gs_index fails
        x86/boot: Initialize FPU and X86_FEATURE_ALWAYS even if we don't have CPUID
        x86/vdso: Fix building on big endian host
        x86/boot: Fix another __read_cr4() case on 486
        x86/init: Fix cr4_init_shadow() on CR4-less machines
      be67d60b
    • Linus Torvalds's avatar
      Merge branch 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus · 66188fb1
      Linus Torvalds authored
      Pull MIPS fixes from Ralf Baechle:
       "Another round of fixes:
      
         - CM: Fix mips_cm_max_vp_width for non-MT kernels on MT systems
         - CPS: Avoid BUG() when offlining pre-r6 CPUs
         - DEC: Avoid gas warnings due to suspicious instruction scheduling by
           manually expanding assembler macros.
         - FTLB: Fix configuration by moving confiuguratoin after probing
         - FTLB: clear execution hazard after changing FTLB enable
         - Highmem: Fix detection of unsupported highmem with cache aliases
         - I6400: Don't touch FTLBP chicken bits
         - microMIPS: Fix BUILD_ROLLBACK_PROLOGUE
         - Malta: Fix IOCU disable switch read for MIPS64
         - Octeon: Fix probing of devices attached to GPIO lines
         - uprobes: Misc small fixes"
      
      * 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
        MIPS: CM: Fix mips_cm_max_vp_width for non-MT kernels on MT systems
        MIPS: Fix detection of unsupported highmem with cache aliases
        MIPS: Malta: Fix IOCU disable switch read for MIPS64
        MIPS: Fix BUILD_ROLLBACK_PROLOGUE for microMIPS
        MIPS: clear execution hazard after changing FTLB enable
        MIPS: Configure FTLB after probing TLB sizes from config4
        MIPS: Stop setting I6400 FTLBP
        MIPS: DEC: Avoid la pseudo-instruction in delay slots
        MIPS: Octeon: mark GPIO controller node not populated after IRQ init.
        MIPS: uprobes: fix use of uninitialised variable
        MIPS: uprobes: remove incorrect set_orig_insn
        MIPS: fix uretprobe implementation
        MIPS: smp-cps: Avoid BUG() when offlining pre-r6 CPUs
      66188fb1
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc · 0c7fc30f
      Linus Torvalds authored
      Pull sparc fixes from David Miller:
      
       1) Fix section mismatches in some builds, from Paul Gortmaker.
      
       2) Need to count huge zero page mappings when doing TSB sizing, from
          Mike Kravetz.
      
       3) Fix handing of cpu_possible_mask when nr_cpus module option is
          specified, from Atish Patra.
      
       4) Don't allocate irq stacks until nr_irqs has been processed, also
          from Atish Patra.
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc:
        sparc64: Fix non-SMP build.
        sparc64: Fix irq stack bootmem allocation.
        sparc64: Fix cpu_possible_mask if nr_cpus is set
        sparc64 mm: Fix more TSB sizing issues
        sparc64: fix section mismatch in find_numa_latencies_for_group
      0c7fc30f
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net · bb6bbc7c
      Linus Torvalds authored
      Pull networking fixes from David Miller:
      
       1) Fix wrong TCP checksums on MTU probing when checksum offloading is
          disabled, from Douglas Caetano dos Santos.
      
       2) Fix qdisc backlog updates in qfq and sfb schedulers, from Cong Wang.
      
       3) Route lookup flow key protocol value is wrong in ip6gre_xmit_other(),
          fix from Lance Richardson.
      
       4) Scheduling while atomic in multicast routing code of ipv4 and ipv6,
          fix from Nikolay Aleksandrov.
      
       5) Fix packet alignment in fec driver, from Eric Nelson.
      
       6) Fix perf regression in sctp due to struct layout and cache misses,
          from Xin Long.
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net:
        sctp: fix the issue sctp_diag uses lock_sock in rcu_read_lock
        sctp: change to check peer prsctp_capable when using prsctp polices
        sctp: remove prsctp_param from sctp_chunk
        sctp: move sent_count to the memory hole in sctp_chunk
        tg3: Avoid NULL pointer dereference in tg3_io_error_detected()
        act_ife: Fix false encoding
        act_ife: Fix external mac header on encode
        VSOCK: Don't dec ack backlog twice for rejected connections
        Revert "net: ethernet: bcmgenet: use phydev from struct net_device"
        net: fec: align IP header in hardware
        net: fec: remove QUIRK_HAS_RACC from i.mx27
        net: fec: remove QUIRK_HAS_RACC from i.mx25
        ipmr, ip6mr: fix scheduling while atomic and a deadlock with ipmr_get_route
        ip6_gre: fix flowi6_proto value in ip6gre_xmit_other()
        tcp: fix a compile error in DBGUNDO()
        tcp: fix wrong checksum calculation on MTU probing
        sch_sfb: keep backlog updated with qlen
        sch_qfq: keep backlog updated with qlen
        can: dev: fix deadlock reported after bus-off
      bb6bbc7c
  4. 01 Oct, 2016 4 commits
  5. 30 Sep, 2016 6 commits
    • Linus Torvalds's avatar
      Merge branch 'akpm' (patches from Andrew) · dbd8805b
      Linus Torvalds authored
      Merge more fixes from Andrew Morton:
       "Three fixes"
      
      * emailed patches from Andrew Morton <akpm@linux-foundation.org>:
        include/linux/property.h: fix typo/compile error
        ocfs2: fix deadlock on mmapped page in ocfs2_write_begin_nolock()
        mm: workingset: fix crash in shadow node shrinker caused by replace_page_cache_page()
      dbd8805b
    • John Youn's avatar
      include/linux/property.h: fix typo/compile error · 37aa7271
      John Youn authored
      This fixes commit d76eebfa ("include/linux/property.h: fix build
      issues with gcc-4.4.4").
      
      With that commit we get the following compile error when using the
      PROPERTY_ENTRY_INTEGER_ARRAY macro.
      
       include/linux/property.h:201:39: error: `u32_data' undeclared (first
                       use in this function)
        PROPERTY_ENTRY_INTEGER_ARRAY(_name_, u32, _val_)
                                             ^
       include/linux/property.h:193:17: note: in definition of macro
                       `PROPERTY_ENTRY_INTEGER_ARRAY'
        { .pointer = { _type_##_data = _val_ } },  \
                       ^
      
      This needs a '.' to reference the union member.  It seems this was just
      overlooked here since it is done correctly in similar constructs in
      other parts of the original commit.
      
      This fix is in preparation of upcoming commits that will use this macro.
      
      Fixes: commit d76eebfa ("include/linux/property.h: fix build issues with gcc-4.4.4")
      Link: http://lkml.kernel.org/r/2de3b929290d88a723ed829a3e3cbd02044714df.1475114627.git.johnyoun@synopsys.comSigned-off-by: default avatarJohn Youn <johnyoun@synopsys.com>
      Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      37aa7271
    • Eric Ren's avatar
      ocfs2: fix deadlock on mmapped page in ocfs2_write_begin_nolock() · c33f0785
      Eric Ren authored
      The testcase "mmaptruncate" of ocfs2-test deadlocks occasionally.
      
      In this testcase, we create a 2*CLUSTER_SIZE file and mmap() on it;
      there are 2 process repeatedly performing the following operations
      respectively: one is doing memset(mmaped_addr + 2*CLUSTER_SIZE - 1, 'a',
      1), while the another is playing ftruncate(fd, 2*CLUSTER_SIZE) and then
      ftruncate(fd, CLUSTER_SIZE) again and again.
      
      This is the backtrace when the deadlock happens:
      
         __wait_on_bit_lock+0x50/0xa0
         __lock_page+0xb7/0xc0
         ocfs2_write_begin_nolock+0x163f/0x1790 [ocfs2]
         ocfs2_page_mkwrite+0x1c7/0x2a0 [ocfs2]
         do_page_mkwrite+0x66/0xc0
         handle_mm_fault+0x685/0x1350
         __do_page_fault+0x1d8/0x4d0
         trace_do_page_fault+0x37/0xf0
         do_async_page_fault+0x19/0x70
         async_page_fault+0x28/0x30
      
      In ocfs2_write_begin_nolock(), we first grab the pages and then allocate
      disk space for this write; ocfs2_try_to_free_truncate_log() will be
      called if -ENOSPC is returned; if we're lucky to get enough clusters,
      which is usually the case, we start over again.
      
      But in ocfs2_free_write_ctxt() the target page isn't unlocked, so we
      will deadlock when trying to grab the target page again.
      
      Also, -ENOMEM might be returned in ocfs2_grab_pages_for_write().
      Another deadlock will happen in __do_page_mkwrite() if
      ocfs2_page_mkwrite() returns non-VM_FAULT_LOCKED, and along with a
      locked target page.
      
      These two errors fail on the same path, so fix them by unlocking the
      target page manually before ocfs2_free_write_ctxt().
      
      Jan Kara helps me clear out the JBD2 part, and suggest the hint for root
      cause.
      
      Changes since v1:
      1. Also put ENOMEM error case into consideration.
      
      Link: http://lkml.kernel.org/r/1474173902-32075-1-git-send-email-zren@suse.comSigned-off-by: default avatarEric Ren <zren@suse.com>
      Reviewed-by: default avatarHe Gang <ghe@suse.com>
      Acked-by: default avatarJoseph Qi <joseph.qi@huawei.com>
      Cc: Mark Fasheh <mfasheh@suse.de>
      Cc: Joel Becker <jlbec@evilplan.org>
      Cc: Junxiao Bi <junxiao.bi@oracle.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      c33f0785
    • Johannes Weiner's avatar
      mm: workingset: fix crash in shadow node shrinker caused by replace_page_cache_page() · 22f2ac51
      Johannes Weiner authored
      Antonio reports the following crash when using fuse under memory pressure:
      
        kernel BUG at /build/linux-a2WvEb/linux-4.4.0/mm/workingset.c:346!
        invalid opcode: 0000 [#1] SMP
        Modules linked in: all of them
        CPU: 2 PID: 63 Comm: kswapd0 Not tainted 4.4.0-36-generic #55-Ubuntu
        Hardware name: System manufacturer System Product Name/P8H67-M PRO, BIOS 3904 04/27/2013
        task: ffff88040cae6040 ti: ffff880407488000 task.ti: ffff880407488000
        RIP: shadow_lru_isolate+0x181/0x190
        Call Trace:
          __list_lru_walk_one.isra.3+0x8f/0x130
          list_lru_walk_one+0x23/0x30
          scan_shadow_nodes+0x34/0x50
          shrink_slab.part.40+0x1ed/0x3d0
          shrink_zone+0x2ca/0x2e0
          kswapd+0x51e/0x990
          kthread+0xd8/0xf0
          ret_from_fork+0x3f/0x70
      
      which corresponds to the following sanity check in the shadow node
      tracking:
      
        BUG_ON(node->count & RADIX_TREE_COUNT_MASK);
      
      The workingset code tracks radix tree nodes that exclusively contain
      shadow entries of evicted pages in them, and this (somewhat obscure)
      line checks whether there are real pages left that would interfere with
      reclaim of the radix tree node under memory pressure.
      
      While discussing ways how fuse might sneak pages into the radix tree
      past the workingset code, Miklos pointed to replace_page_cache_page(),
      and indeed there is a problem there: it properly accounts for the old
      page being removed - __delete_from_page_cache() does that - but then
      does a raw raw radix_tree_insert(), not accounting for the replacement
      page.  Eventually the page count bits in node->count underflow while
      leaving the node incorrectly linked to the shadow node LRU.
      
      To address this, make sure replace_page_cache_page() uses the tracked
      page insertion code, page_cache_tree_insert().  This fixes the page
      accounting and makes sure page-containing nodes are properly unlinked
      from the shadow node LRU again.
      
      Also, make the sanity checks a bit less obscure by using the helpers for
      checking the number of pages and shadows in a radix tree node.
      
      Fixes: 449dd698 ("mm: keep page cache radix tree nodes in check")
      Link: http://lkml.kernel.org/r/20160919155822.29498-1-hannes@cmpxchg.orgSigned-off-by: default avatarJohannes Weiner <hannes@cmpxchg.org>
      Reported-by: default avatarAntonio SJ Musumeci <trapexit@spawn.link>
      Debugged-by: default avatarMiklos Szeredi <miklos@szeredi.hu>
      Cc: <stable@vger.kernel.org>	[3.15+]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      22f2ac51
    • Javi Merino's avatar
      MAINTAINERS: Switch to kernel.org email address for Javi Merino · 9a2172a8
      Javi Merino authored
      Change my email address to my kernel.org account instead of the ARM one.
      Signed-off-by: default avatarJavi Merino <javi.merino@arm.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      9a2172a8
    • David Howells's avatar
      rxrpc: Fix the call timer handling · 405dea1d
      David Howells authored
      The call timer's concept of a call timeout (of which there are three) that
      is inactive is that it is the timeout has the same expiration time as the
      call expiration timeout (the expiration timer is never inactive).  However,
      I'm not resetting the timeouts when they expire, leading to repeated
      processing of expired timeouts when other timeout events occur.
      
      Fix this by:
      
       (1) Move the timer expiry detection into rxrpc_set_timer() inside the
           locked section.  This means that if a timeout is set that will expire
           immediately, we deal with it immediately.
      
       (2) If a timeout is at or before now then it has expired.  When an expiry
           is detected, an event is raised, the timeout is automatically
           inactivated and the event processor is queued.
      
       (3) If a timeout is at or after the expiry timeout then it is inactive.
           Inactive timeouts do not contribute to the timer setting.
      
       (4) The call timer callback can now just call rxrpc_set_timer() to handle
           things.
      
       (5) The call processor work function now checks the event flags rather
           than checking the timeouts directly.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      405dea1d