1. 15 7月, 2015 4 次提交
  2. 01 7月, 2015 1 次提交
  3. 24 6月, 2015 1 次提交
  4. 18 6月, 2015 1 次提交
    • L
      x86/mm/pat, drivers/infiniband/ipath: Use arch_phys_wc_add() and require PAT disabled · 7ea402d0
      Luis R. Rodriguez 提交于
      We are burrying direct access to MTRR code support on
      x86 in order to take advantage of PAT. In the future, we
      also want to make the default behaviour of ioremap_nocache()
      to use strong UC, use of mtrr_add() on those systems
      would make write-combining void.
      
      In order to help both enable us to later make strong
      UC default and in order to phase out direct MTRR access
      code port the driver over to arch_phys_wc_add() and
      annotate that the device driver requires systems to
      boot with PAT disabled, with the 'nopat' kernel parameter.
      
      This is a workable compromise given that the ipath device
      driver powers the old HTX bus cards that only work in
      AMD systems, while the newer IB/qib device driver
      powers all PCI-e cards. The ipath device driver is
      obsolete, hardware is hard to find and because of this
      its a reasonable compromise to require users of ipath
      to boot with 'nopat'.
      Signed-off-by: NLuis R. Rodriguez <mcgrof@suse.com>
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Acked-by: NDoug Ledford <dledford@redhat.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Andy Walls <awalls@md.metrocast.net>
      Cc: Antonino Daplas <adaplas@gmail.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Dave Airlie <airlied@redhat.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Hal Rosenstock <hal.rosenstock@gmail.com>
      Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Michael S. Tsirkin <mst@redhat.com>
      Cc: Mike Marciniszyn <mike.marciniszyn@intel.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
      Cc: Roger Pau Monné <roger.pau@citrix.com>
      Cc: Roland Dreier <roland@purestorage.com>
      Cc: Sean Hefty <sean.hefty@intel.com>
      Cc: Stefan Bader <stefan.bader@canonical.com>
      Cc: Suresh Siddha <sbsiddha@gmail.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: Ville Syrjälä <syrjala@sci.fi>
      Cc: infinipath@intel.com
      Cc: jbeulich@suse.com
      Cc: konrad.wilk@oracle.com
      Cc: linux-rdma@vger.kernel.org
      Cc: mchehab@osg.samsung.com
      Cc: toshi.kani@hp.com
      Link: http://lkml.kernel.org/r/1434053994-2196-4-git-send-email-mcgrof@do-not-panic.com
      Link: http://lkml.kernel.org/r/1434356898-25135-5-git-send-email-bp@alien8.deSigned-off-by: NIngo Molnar <mingo@kernel.org>
      7ea402d0
  5. 16 6月, 2015 5 次提交
  6. 13 6月, 2015 20 次提交
  7. 12 6月, 2015 2 次提交
  8. 11 6月, 2015 4 次提交
  9. 09 6月, 2015 2 次提交
    • S
      iser-target: Fix possible use-after-free · 524630d5
      Sagi Grimberg 提交于
      iser connection termination process happens in 2 stages:
      - isert_wait_conn:
        - resumes rdma disconnect
        - wait for session commands
        - wait for flush completions (post a marked wr to signal we are done)
        - wait for logout completion
        - queue work for connection cleanup (depends on disconnected/timewait
          events)
      - isert_free_conn
        - last reference put on the connection
      
      In case we are terminating during IOs, we might be posting send/recv
      requests after we posted the last work request which might lead
      to a use-after-free condition in isert_handle_wc.
      After we posted the last wr in isert_wait_conn we are guaranteed that
      no successful completions will follow (meaning no new work request posts
      may happen) but other flush errors might still come. So before we
      put the last reference on the connection, we repeat the process of
      posting a marked work request (isert_wait4flush) in order to make sure all
      pending completions were flushed.
      Signed-off-by: NSagi Grimberg <sagig@mellanox.com>
      Signed-off-by: NJenny Falkovich <jennyf@mellanox.com>
      Cc: stable@vger.kernel.org # 3.10+
      Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
      524630d5
    • S
      iser-target: release stale iser connections · 2f1b6b7d
      Sagi Grimberg 提交于
      When receiving a new iser connect request we serialize
      the pending requests by adding the newly created iser connection
      to the np accept list and let the login thread process the connect
      request one by one (np_accept_wait).
      
      In case we received a disconnect request before the iser_conn
      has begun processing (still linked in np_accept_list) we should
      detach it from the list and clean it up and not have the login
      thread process a stale connection. We do it only when the connection
      state is not already terminating (initiator driven disconnect) as
      this might lead us to access np_accept_mutex after the np was released
      in live shutdown scenarios.
      Signed-off-by: NSagi Grimberg <sagig@mellanox.com>
      Signed-off-by: NJenny Falkovich <jennyf@mellanox.com>
      Cc: stable@vger.kernel.org # 3.10+
      Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
      2f1b6b7d