1. 10 3月, 2018 1 次提交
  2. 01 3月, 2018 6 次提交
    • J
      s390/qeth: fix IPA command submission race · d22ffb5a
      Julian Wiedmann 提交于
      If multiple IPA commands are build & sent out concurrently,
      fill_ipacmd_header() may assign a seqno value to a command that's
      different from what send_control_data() later assigns to this command's
      reply.
      This is due to other commands passing through send_control_data(),
      and incrementing card->seqno.ipa along the way.
      
      So one IPA command has no reply that's waiting for its seqno, while some
      other IPA command has multiple reply objects waiting for it.
      Only one of those waiting replies wins, and the other(s) times out and
      triggers a recovery via send_ipa_cmd().
      
      Fix this by making sure that the same seqno value is assigned to
      a command and its reply object.
      Do so immediately before submitting the command & while holding the
      irq_pending "lock", to produce nicely ascending seqnos.
      
      As a side effect, *all* IPA commands now use a reply object that's
      waiting for its actual seqno. Previously, early IPA commands that were
      submitted while the card was still DOWN used the "catch-all" IDX seqno.
      Signed-off-by: NJulian Wiedmann <jwi@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d22ffb5a
    • J
      s390/qeth: fix IP address lookup for L3 devices · c5c48c58
      Julian Wiedmann 提交于
      Current code ("qeth_l3_ip_from_hash()") matches a queried address object
      against objects in the IP table by IP address, Mask/Prefix Length and
      MAC address ("qeth_l3_ipaddrs_is_equal()"). But what callers actually
      require is either
      a) "is this IP address registered" (ie. match by IP address only),
      before adding a new address.
      b) or "is this address object registered" (ie. match all relevant
         attributes), before deleting an address.
      
      Right now
      1. the ADD path is too strict in its lookup, and eg. doesn't detect
      conflicts between an existing NORMAL address and a new VIPA address
      (because the NORMAL address will have mask != 0, while VIPA has
      a mask == 0),
      2. the DELETE path is not strict enough, and eg. allows del_rxip() to
      delete a VIPA address as long as the IP address matches.
      
      Fix all this by adding helpers (_addr_match_ip() and _addr_match_all())
      that do the appropriate checking.
      
      Note that the ADD path for NORMAL addresses is special, as qeth keeps
      track of how many times such an address is in use (and there is no
      immediate way of returning errors to the caller). So when a requested
      NORMAL address _fully_ matches an existing one, it's not considered a
      conflict and we merely increment the refcount.
      
      Fixes: 5f78e29c ("qeth: optimize IP handling in rx_mode callback")
      Signed-off-by: NJulian Wiedmann <jwi@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c5c48c58
    • J
      Revert "s390/qeth: fix using of ref counter for rxip addresses" · 4964c66f
      Julian Wiedmann 提交于
      This reverts commit cb816192.
      
      The issue this attempted to fix never actually occurs.
      l3_add_rxip() checks (via l3_ip_from_hash()) if the requested address
      was previously added to the card. If so, it returns -EEXIST and doesn't
      call l3_add_ip().
      As a result, the "address exists" path in l3_add_ip() is never taken
      for rxip addresses, and this patch had no effect.
      
      Fixes: cb816192 ("s390/qeth: fix using of ref counter for rxip addresses")
      Signed-off-by: NJulian Wiedmann <jwi@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4964c66f
    • J
      s390/qeth: fix double-free on IP add/remove race · 14d066c3
      Julian Wiedmann 提交于
      Registering an IPv4 address with the HW takes quite a while, so we
      temporarily drop the ip_htable lock. Any concurrent add/remove of the
      same IP adjusts the IP's use count, and (on remove) is then blocked by
      addr->in_progress.
      After the register call has completed, we check the use count for
      concurrently attempted add/remove calls - and possibly straight-away
      deregister the IP again. This happens via l3_delete_ip(), which
      1) looks up the queried IP in the htable (getting a reference to the
         *same* queried object),
      2) deregisters the IP from the HW, and
      3) frees the IP object.
      
      The caller in l3_add_ip() then does a second free on the same object.
      
      For this case, skip all the extra checks and lookups in l3_delete_ip()
      and just deregister & free the IP object ourselves.
      
      Fixes: 5f78e29c ("qeth: optimize IP handling in rx_mode callback")
      Signed-off-by: NJulian Wiedmann <jwi@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      14d066c3
    • J
      s390/qeth: fix IP removal on offline cards · 98d823ab
      Julian Wiedmann 提交于
      If the HW is not reachable, then none of the IPs in qeth's internal
      table has been registered with the HW yet. So when deleting such an IP,
      there's no need to stage it for deregistration - just drop it from
      the table.
      
      This fixes the "add-delete-add" scenario on an offline card, where the
      the second "add" merely increments the IP's use count. But as the IP is
      still set to DISP_ADDR_DELETE from the previous "delete" step,
      l3_recover_ip() won't register it with the HW when the card goes online.
      
      Fixes: 5f78e29c ("qeth: optimize IP handling in rx_mode callback")
      Signed-off-by: NJulian Wiedmann <jwi@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      98d823ab
    • J
      s390/qeth: fix overestimated count of buffer elements · 12472af8
      Julian Wiedmann 提交于
      qeth_get_elements_for_range() doesn't know how to handle a 0-length
      range (ie. start == end), and returns 1 when it should return 0.
      Such ranges occur on TSO skbs, where the L2/L3/L4 headers (and thus all
      of the skb's linear data) are skipped when mapping the skb into regular
      buffer elements.
      
      This overestimation may cause several performance-related issues:
      1. sub-optimal IO buffer selection, where the next buffer gets selected
         even though the skb would actually still fit into the current buffer.
      2. forced linearization, if the element count for a non-linear skb
         exceeds QETH_MAX_BUFFER_ELEMENTS.
      
      Rather than modifying qeth_get_elements_for_range() and adding overhead
      to every caller, fix up those callers that are in risk of passing a
      0-length range.
      
      Fixes: 2863c613 ("qeth: refactor calculation of SBALE count")
      Signed-off-by: NJulian Wiedmann <jwi@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      12472af8
  3. 14 2月, 2018 1 次提交
  4. 12 2月, 2018 1 次提交
    • L
      vfs: do bulk POLL* -> EPOLL* replacement · a9a08845
      Linus Torvalds 提交于
      This is the mindless scripted replacement of kernel use of POLL*
      variables as described by Al, done by this script:
      
          for V in IN OUT PRI ERR RDNORM RDBAND WRNORM WRBAND HUP RDHUP NVAL MSG; do
              L=`git grep -l -w POLL$V | grep -v '^t' | grep -v /um/ | grep -v '^sa' | grep -v '/poll.h$'|grep -v '^D'`
              for f in $L; do sed -i "-es/^\([^\"]*\)\(\<POLL$V\>\)/\\1E\\2/" $f; done
          done
      
      with de-mangling cleanups yet to come.
      
      NOTE! On almost all architectures, the EPOLL* constants have the same
      values as the POLL* constants do.  But they keyword here is "almost".
      For various bad reasons they aren't the same, and epoll() doesn't
      actually work quite correctly in some cases due to this on Sparc et al.
      
      The next patch from Al will sort out the final differences, and we
      should be all done.
      Scripted-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a9a08845
  5. 10 2月, 2018 2 次提交
  6. 07 2月, 2018 1 次提交
    • M
      s390: introduce execute-trampolines for branches · f19fbd5e
      Martin Schwidefsky 提交于
      Add CONFIG_EXPOLINE to enable the use of the new -mindirect-branch= and
      -mfunction_return= compiler options to create a kernel fortified against
      the specte v2 attack.
      
      With CONFIG_EXPOLINE=y all indirect branches will be issued with an
      execute type instruction. For z10 or newer the EXRL instruction will
      be used, for older machines the EX instruction. The typical indirect
      call
      
      	basr	%r14,%r1
      
      is replaced with a PC relative call to a new thunk
      
      	brasl	%r14,__s390x_indirect_jump_r1
      
      The thunk contains the EXRL/EX instruction to the indirect branch
      
      __s390x_indirect_jump_r1:
      	exrl	0,0f
      	j	.
      0:	br	%r1
      
      The detour via the execute type instruction has a performance impact.
      To get rid of the detour the new kernel parameter "nospectre_v2" and
      "spectre_v2=[on,off,auto]" can be used. If the parameter is specified
      the kernel and module code will be patched at runtime.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      f19fbd5e
  7. 05 2月, 2018 1 次提交
  8. 02 2月, 2018 1 次提交
  9. 26 1月, 2018 1 次提交
  10. 23 1月, 2018 3 次提交
  11. 20 1月, 2018 2 次提交
    • D
      dax: require 'struct page' by default for filesystem dax · 569d0365
      Dan Williams 提交于
      If a dax buffer from a device that does not map pages is passed to
      read(2) or write(2) as a target for direct-I/O it triggers SIGBUS. If
      gdb attempts to examine the contents of a dax buffer from a device that
      does not map pages it triggers SIGBUS. If fork(2) is called on a process
      with a dax mapping from a device that does not map pages it triggers
      SIGBUS. 'struct page' is required otherwise several kernel code paths
      break in surprising ways. Disable filesystem-dax on devices that do not
      map pages.
      
      In addition to needing pfn_to_page() to be valid we also require devmap
      pages.  We need this to detect dax pages in the get_user_pages_fast()
      path and so that we can stop managing the VM_MIXEDMAP flag. For DAX
      drivers that have not supported get_user_pages() to date we allow them
      to opt-in to supporting DAX with the CONFIG_FS_DAX_LIMITED configuration
      option which requires ->direct_access() to return pfn_t_special() pfns.
      This leaves DAX support in brd disabled and scheduled for removal.
      
      Note that when the initial dax support was being merged a few years back
      there was concern that struct page was unsuitable for use with next
      generation persistent memory devices. The theoretical concern was that
      struct page access, being such a hotly used data structure in the
      kernel, would lead to media wear out. While that was a reasonable
      conservative starting position it has not held true in practice. We have
      long since committed to using devm_memremap_pages() to support higher
      order kernel functionality that needs get_user_pages() and
      pfn_to_page().
      
      
      Cc: Jeff Moyer <jmoyer@redhat.com>
      Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Reviewed-by: NJan Kara <jack@suse.cz>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NGerald Schaefer <gerald.schaefer@de.ibm.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      569d0365
    • D
      mm, dax: introduce pfn_t_special() · 785a3fab
      Dan Williams 提交于
      In support of removing the VM_MIXEDMAP indication from DAX VMAs,
      introduce pfn_t_special() for drivers to indicate that _PAGE_SPECIAL
      should be used for DAX ptes. This also helps identify drivers like
      dccssblk that only want to use DAX in a read-only fashion without
      get_user_pages() support.
      
      Ideally we could delete axonram and dcssblk DAX support, but if we need
      to keep it better make it explicit that axonram and dcssblk only support
      a sub-set of DAX due to missing _PAGE_DEVMAP support.
      
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      785a3fab
  12. 09 1月, 2018 2 次提交
  13. 03 1月, 2018 3 次提交
  14. 02 1月, 2018 1 次提交
  15. 21 12月, 2017 14 次提交