1. 31 1月, 2012 1 次提交
  2. 28 1月, 2012 4 次提交
  3. 13 1月, 2012 2 次提交
    • R
      module_param: make bool parameters really bool (drivers & misc) · 90ab5ee9
      Rusty Russell 提交于
      module_param(bool) used to counter-intuitively take an int.  In
      fddd5201 (mid-2009) we allowed bool or int/unsigned int using a messy
      trick.
      
      It's time to remove the int/unsigned int option.  For this version
      it'll simply give a warning, but it'll break next kernel version.
      Acked-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      90ab5ee9
    • R
      module_param: avoid bool abuse, add bint for special cases. · 69116f27
      Rusty Russell 提交于
      For historical reasons, we allow module_param(bool) to take an int (or
      an unsigned int).  That's going away.
      
      A few drivers really want an int: they set it to -1 and a parameter
      will set it to 0 or 1.  This sucks: reading them from sysfs will give
      'Y' for both -1 and 1, but if we change it to an int, then the users
      might be broken (if they did "param" instead of "param=1").
      
      Use a new 'bint' parser for them.
      
      (ntfs has a different problem: it needs an int for debug_msgs because
      it's also exposed via sysctl.)
      
      Cc: Steve Glendinning <steve.glendinning@smsc.com>
      Cc: Jean Delvare <khali@linux-fr.org>
      Cc: Guenter Roeck <guenter.roeck@ericsson.com>
      Cc: Hoang-Nam Nguyen <hnguyen@de.ibm.com>
      Cc: Christoph Raisch <raisch@de.ibm.com>
      Cc: Roland Dreier <roland@kernel.org>
      Cc: Sean Hefty <sean.hefty@intel.com>
      Cc: Hal Rosenstock <hal.rosenstock@gmail.com>
      Cc: linux390@de.ibm.com
      Cc: Anton Altaparmakov <anton@tuxera.com>
      Cc: Jaroslav Kysela <perex@perex.cz>
      Cc: Takashi Iwai <tiwai@suse.de>
      Cc: lm-sensors@lm-sensors.org
      Cc: linux-rdma@vger.kernel.org
      Cc: linux-s390@vger.kernel.org
      Cc: linux-ntfs-dev@lists.sourceforge.net
      Cc: alsa-devel@alsa-project.org
      Acked-by: Takashi Iwai <tiwai@suse.de> (For the sound part)
      Acked-by: Guenter Roeck <guenter.roeck@ericsson.com> (For the hwmon driver)
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      69116f27
  4. 05 1月, 2012 5 次提交
  5. 04 1月, 2012 11 次提交
  6. 20 12月, 2011 2 次提交
  7. 16 12月, 2011 1 次提交
    • B
      ib_srpt: Initial SRP Target merge for v3.3-rc1 · a42d985b
      Bart Van Assche 提交于
      This patch adds the kernel module ib_srpt SCSI RDMA Protocol (SRP) target
      implementation conforming to the SRP r16a specification for the mainline
      drivers/target infrastructure.
      
      This driver was originally developed by Vu Pham and has been optimized by
      Bart Van Assche and merged into upstream LIO based on his srpt-lio-4.1
      branch here:
      
         https://github.com/bvanassche/srpt-lio/commits/srpt-lio-4.1/
      
      This updated patch also contains the following two changes from
      lio-core-2.6.git/master.  One is to fix a bug with 1 >= task->task_sg[]
      chained mappings in ib_srpt, and the other to convert the configfs control
      plane to reference IB Port GUID and struct srpt_port directly following
      mainline v4.x target_core_fabric_configfs.c convertion for ib_srpt
      to work with rtslib/rtsadmin v2 code.
      
      These seperate patches can be found here:
      
      ib_srpt: Fix bug with chainged SGLs in srpt_map_sg_to_ib_sge
      http://www.risingtidesystems.com/git/?p=lio-core-2.6.git;a=commitdiff;h=ea485147563b6555a97dbf811825fbb586519252
      
      ib_srpt: Convert se_wwn endpoint reference to struct srpt_port->port_wwn
      http://www.risingtidesystems.com/git/?p=lio-core-2.6.git;a=commitdiff;h=4e544a210acb227df1bb4ca5086e65bdf4e648ea
      
      This also includes the following recent v1 -> v2 review changes:
      
      ib_srpt: Fix potential out-of-bounds array access
      ib_srpt: Avoid failed multipart RDMA transfers
      ib_srpt: Fix srpt_alloc_fabric_acl failure case return value
      ib_srpt: Update comments to reference $driver/$port layout
      ib_srpt: Fix sport->port_guid formatting code
      ib_srpt: Remove legacy use_port_guid_in_session_name module parameter
      ib_srpt: Convert srp_max_rdma_size into per port configfs attribute
      ib_srpt: Convert srp_max_rsp_size into per port configfs attribute
      ib_srpt: Convert srpt_sq_size into per port configfs attribute
      
      and v2 -> v3 review changes:
      
      ib_srpt: Fix possible race with srp_sq_size in srpt_create_ch_ib
      ib_srpt: Fix possible race with srp_max_rsp_size in srpt_release_channel_work
      ib_srpt: Fix up MAX_SRPT_RDMA_SIZE define
      ib_srpt: Make srpt_map_sg_to_ib_sge() failure case return -EAGAIN
      ib_srpt: Convert port_guid to use subnet_prefix + interface_id formatting
      ib_srpt: Make srpt_check_stop_free return kref_put status
      ib_srpt: Make compilation with BUG=n proceed`
      ib_srpt: Use new target_core_fabric.h include
      ib_srpt: Check hex2bin() return code to silence build warning
      
      Cc: Bart Van Assche <bvanassche@acm.org>
      Cc: Roland Dreier <roland@purestorage.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Vu Pham <vu@mellanox.com>
      Cc: David Dillow <dillowda@ornl.gov>
      Signed-off-by: NNicholas A. Bellinger <nab@risingtidesystems.com>
      a42d985b
  8. 14 12月, 2011 3 次提交
  9. 07 12月, 2011 1 次提交
  10. 06 12月, 2011 6 次提交
  11. 01 12月, 2011 1 次提交
  12. 30 11月, 2011 2 次提交
    • E
      IB: Fix RCU lockdep splats · 580da35a
      Eric Dumazet 提交于
      Commit f2c31e32 ("net: fix NULL dereferences in check_peer_redir()")
      forgot to take care of infiniband uses of dst neighbours.
      
      Many thanks to Marc Aurele who provided a nice bug report and feedback.
      Reported-by: NMarc Aurele La France <tsi@ualberta.ca>
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Cc: David Miller <davem@davemloft.net>
      Cc: <stable@kernel.org>
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      580da35a
    • M
      IB/ipoib: Prevent hung task or softlockup processing multicast response · 3874397c
      Mike Marciniszyn 提交于
      This following can occur with ipoib when processing a multicast reponse:
      
          BUG: soft lockup - CPU#0 stuck for 67s! [ib_mad1:982]
          Modules linked in: ...
          CPU 0:
          Modules linked in: ...
          Pid: 982, comm: ib_mad1 Not tainted 2.6.32-131.0.15.el6.x86_64 #1 ProLiant DL160 G5
          RIP: 0010:[<ffffffff814ddb27>]  [<ffffffff814ddb27>] _spin_unlock_irqrestore+0x17/0x20
          RSP: 0018:ffff8802119ed860  EFLAGS: 00000246
          0000000000000004 RBX: ffff8802119ed860 RCX: 000000000000a299
          RDX: ffff88021086c700 RSI: 0000000000000246 RDI: 0000000000000246
          RBP: ffffffff8100bc8e R08: ffff880210ac229c R09: 0000000000000000
          R10: ffff88021278aab8 R11: 0000000000000000 R12: ffff8802119ed860
          R13: ffffffff8100be6e R14: 0000000000000001 R15: 0000000000000003
          FS:  0000000000000000(0000) GS:ffff880028200000(0000) knlGS:0000000000000000
          CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
          CR2: 00000000006d4840 CR3: 0000000209aa5000 CR4: 00000000000406f0
          DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
          DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
          Call Trace:
          [<ffffffffa032c247>] ? ipoib_mcast_send+0x157/0x480 [ib_ipoib]
          [<ffffffff8100bc8e>] ? apic_timer_interrupt+0xe/0x20
          [<ffffffff8100bc8e>] ? apic_timer_interrupt+0xe/0x20
          [<ffffffffa03283d4>] ? ipoib_path_lookup+0x124/0x2d0 [ib_ipoib]
          [<ffffffffa03286fc>] ? ipoib_start_xmit+0x17c/0x430 [ib_ipoib]
          [<ffffffff8141e758>] ? dev_hard_start_xmit+0x2c8/0x3f0
          [<ffffffff81439d0a>] ? sch_direct_xmit+0x15a/0x1c0
          [<ffffffff81423098>] ? dev_queue_xmit+0x388/0x4d0
          [<ffffffffa032d6b7>] ? ipoib_mcast_join_finish+0x2c7/0x510 [ib_ipoib]
          [<ffffffffa032dab8>] ? ipoib_mcast_sendonly_join_complete+0x1b8/0x1f0 [ib_ipoib]
          [<ffffffffa02a0946>] ? mcast_work_handler+0x1a6/0x710 [ib_sa]
          [<ffffffffa015f01e>] ? ib_send_mad+0xfe/0x3c0 [ib_mad]
          [<ffffffffa00f6c93>] ? ib_get_cached_lmc+0xa3/0xb0 [ib_core]
          [<ffffffffa02a0f9b>] ? join_handler+0xeb/0x200 [ib_sa]
          [<ffffffffa029e4fc>] ? ib_sa_mcmember_rec_callback+0x5c/0xa0 [ib_sa]
          [<ffffffffa029e79c>] ? recv_handler+0x3c/0x70 [ib_sa]
          [<ffffffffa01603a4>] ? ib_mad_completion_handler+0x844/0x9d0 [ib_mad]
          [<ffffffffa015fb60>] ? ib_mad_completion_handler+0x0/0x9d0 [ib_mad]
          [<ffffffff81088830>] ? worker_thread+0x170/0x2a0
          [<ffffffff8108e160>] ? autoremove_wake_function+0x0/0x40
          [<ffffffff810886c0>] ? worker_thread+0x0/0x2a0
          [<ffffffff8108ddf6>] ? kthread+0x96/0xa0
          [<ffffffff8100c1ca>] ? child_rip+0xa/0x20
      
      Coinciding with stack trace is the following message:
      
          ib0: ib_address_create failed
      
      The code below in ipoib_mcast_join_finish() will note the above
      failure in the address handle but otherwise continue:
      
                      ah = ipoib_create_ah(dev, priv->pd, &av);
                      if (!ah) {
                              ipoib_warn(priv, "ib_address_create failed\n");
                      } else {
      
      The while loop at the bottom of ipoib_mcast_join_finish() will attempt
      to send queued multicast packets in mcast->pkt_queue and eventually
      end up in ipoib_mcast_send():
      
              if (!mcast->ah) {
                      if (skb_queue_len(&mcast->pkt_queue) < IPOIB_MAX_MCAST_QUEUE)
                              skb_queue_tail(&mcast->pkt_queue, skb);
                      else {
                              ++dev->stats.tx_dropped;
                              dev_kfree_skb_any(skb);
                      }
      
      My read is that the code will requeue the packet and return to the
      ipoib_mcast_join_finish() while loop and the stage is set for the
      "hung" task diagnostic as the while loop never sees a non-NULL ah, and
      will do nothing to resolve.
      
      There are GFP_ATOMIC allocates in the provider routines, so this is
      possible and should be dealt with.
      
      The test that induced the failure is associated with a host SM on the
      same server during a shutdown.
      
      This patch causes ipoib_mcast_join_finish() to exit with an error
      which will flush the queued mcast packets.  Nothing is done to unwind
      the QP attached state so that subsequent sends from above will retry
      the join.
      Reviewed-by: NRam Vepa <ram.vepa@qlogic.com>
      Reviewed-by: NGary Leshner <gary.leshner@qlogic.com>
      Signed-off-by: NMike Marciniszyn <mike.marciniszyn@qlogic.com>
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      3874397c
  13. 29 11月, 2011 1 次提交