1. 25 1月, 2018 1 次提交
    • L
      RDMA/srpt: Fix RCU debug build error · f97f43c9
      Leon Romanovsky 提交于
      Combination of CONFIG_DEBUG_OBJECTS_RCU_HEAD=y and
      CONFIG_INFINIBAND_SRPT=m produces the following build error.
      
      ERROR: "init_rcu_head" [drivers/infiniband/ulp/srpt/ib_srpt.ko] undefined!
      make[1]: *** [scripts/Makefile.modpost:92: __modpost] Error 1
      make: *** [Makefile:1216: modules] Error 2
      
      The reason to it that init_rcu_head() is not exported and not supposed
      to be used in modules. It is needed for dynamic initialization of
      statically allocated rcu_head structures.
      
      Fixes: 795bc112 ("IB/srpt: Make it safe to use RCU for srpt_device.rch_list")
      Fixes: a1125314 ("IB/srpt: Rework multi-channel support")
      Signed-off-by: NBart Van Assche <bart.vanassche@wdc.com>
      Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      f97f43c9
  2. 19 1月, 2018 13 次提交
  3. 09 1月, 2018 11 次提交
  4. 04 1月, 2018 2 次提交
  5. 14 11月, 2017 5 次提交
  6. 31 10月, 2017 1 次提交
    • K
      treewide: Fix function prototypes for module_param_call() · e4dca7b7
      Kees Cook 提交于
      Several function prototypes for the set/get functions defined by
      module_param_call() have a slightly wrong argument types. This fixes
      those in an effort to clean up the calls when running under type-enforced
      compiler instrumentation for CFI. This is the result of running the
      following semantic patch:
      
      @match_module_param_call_function@
      declarer name module_param_call;
      identifier _name, _set_func, _get_func;
      expression _arg, _mode;
      @@
      
       module_param_call(_name, _set_func, _get_func, _arg, _mode);
      
      @fix_set_prototype
       depends on match_module_param_call_function@
      identifier match_module_param_call_function._set_func;
      identifier _val, _param;
      type _val_type, _param_type;
      @@
      
       int _set_func(
      -_val_type _val
      +const char * _val
       ,
      -_param_type _param
      +const struct kernel_param * _param
       ) { ... }
      
      @fix_get_prototype
       depends on match_module_param_call_function@
      identifier match_module_param_call_function._get_func;
      identifier _val, _param;
      type _val_type, _param_type;
      @@
      
       int _get_func(
      -_val_type _val
      +char * _val
       ,
      -_param_type _param
      +const struct kernel_param * _param
       ) { ... }
      
      Two additional by-hand changes are included for places where the above
      Coccinelle script didn't notice them:
      
      	drivers/platform/x86/thinkpad_acpi.c
      	fs/lockd/svc.c
      Signed-off-by: NKees Cook <keescook@chromium.org>
      Signed-off-by: NJessica Yu <jeyu@kernel.org>
      e4dca7b7
  7. 18 10月, 2017 4 次提交
  8. 25 8月, 2017 1 次提交
  9. 07 7月, 2017 1 次提交
  10. 08 5月, 2017 1 次提交
    • B
      IB/srpt: Avoid that aborting a command triggers a kernel warning · bd2c52d7
      Bart Van Assche 提交于
      Avoid that the following warning is triggered:
      
      WARNING: CPU: 10 PID: 166 at ../drivers/infiniband/ulp/srpt/ib_srpt.c:2674 srpt_release_cmd+0x139/0x140 [ib_srpt]
      CPU: 10 PID: 166 Comm: kworker/u24:8 Not tainted 4.9.4-1-default #1
      Workqueue: tmr-fileio target_tmr_work [target_core_mod]
      Call Trace:
       [<ffffffffaa3c4f70>] dump_stack+0x63/0x83
       [<ffffffffaa0844eb>] __warn+0xcb/0xf0
       [<ffffffffaa0845dd>] warn_slowpath_null+0x1d/0x20
       [<ffffffffc06ba429>] srpt_release_cmd+0x139/0x140 [ib_srpt]
       [<ffffffffc06e4377>] target_release_cmd_kref+0xb7/0x120 [target_core_mod]
       [<ffffffffc06e4d7f>] target_put_sess_cmd+0x2f/0x60 [target_core_mod]
       [<ffffffffc06e15e0>] core_tmr_lun_reset+0x340/0x790 [target_core_mod]
       [<ffffffffc06e4816>] target_tmr_work+0xe6/0x140 [target_core_mod]
       [<ffffffffaa09e4d3>] process_one_work+0x1f3/0x4d0
       [<ffffffffaa09e7f8>] worker_thread+0x48/0x4e0
       [<ffffffffaa09e7b0>] ? process_one_work+0x4d0/0x4d0
       [<ffffffffaa0a46da>] kthread+0xca/0xe0
       [<ffffffffaa0a4610>] ? kthread_park+0x60/0x60
       [<ffffffffaa71b775>] ret_from_fork+0x25/0x30
      Signed-off-by: NBart Van Assche <bart.vanassche@sandisk.com>
      Reviewed-by: NHannes Reinecke <hare@suse.com>
      Cc: Doug Ledford <dledford@redhat.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: David Disseldorp <ddiss@suse.de>
      Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
      bd2c52d7