linux.git/drivers/target/target_core_user.c, branch v5.13

scsi: target: tcmu: Fix xarray RCU warning

2021-05-21T20:15:48+00:00

Commit f5ce815f34bc ("scsi: target: tcmu: Support DATA_BLOCK_SIZE = N *
PAGE_SIZE") introduced xas_next() calls to iterate xarray elements.  These
calls triggered the WARNING "suspicious RCU usage" at tcmu device set up
[1]. In the call stack of xas_next(), xas_load() was called.  According to
its comment, this function requires "the xa_lock or the RCU lock".

To avoid the warning:

 - Guard the small loop calling xas_next() in tcmu_get_empty_block with RCU
   lock.

 - In the large loop in tcmu_copy_data using RCU lock would possibly
   disable preemtion for a long time (copy multi MBs). Therefore replace
   XA_STATE, xas_set and xas_next with a single xa_load.

[1]

[ 1899.867091] =============================
[ 1899.871199] WARNING: suspicious RCU usage
[ 1899.875310] 5.13.0-rc1+ #41 Not tainted
[ 1899.879222] -----------------------------
[ 1899.883299] include/linux/xarray.h:1182 suspicious rcu_dereference_check() usage!
[ 1899.890940] other info that might help us debug this:
[ 1899.899082] rcu_scheduler_active = 2, debug_locks = 1
[ 1899.905719] 3 locks held by kworker/0:1/1368:
[ 1899.910161]  #0: ffffa1f8c8b98738 ((wq_completion)target_submission){+.+.}-{0:0}, at: process_one_work+0x1ee/0x580
[ 1899.920732]  #1: ffffbd7040cd7e78 ((work_completion)(&q->sq.work)){+.+.}-{0:0}, at: process_one_work+0x1ee/0x580
[ 1899.931146]  #2: ffffa1f8d1c99768 (&udev->cmdr_lock){+.+.}-{3:3}, at: tcmu_queue_cmd+0xea/0x160 [target_core_user]
[ 1899.941678] stack backtrace:
[ 1899.946093] CPU: 0 PID: 1368 Comm: kworker/0:1 Not tainted 5.13.0-rc1+ #41
[ 1899.953070] Hardware name: System manufacturer System Product Name/PRIME Z270-A, BIOS 1302 03/15/2018
[ 1899.962459] Workqueue: target_submission target_queued_submit_work [target_core_mod]
[ 1899.970337] Call Trace:
[ 1899.972839]  dump_stack+0x6d/0x89
[ 1899.976222]  xas_descend+0x10e/0x120
[ 1899.979875]  xas_load+0x39/0x50
[ 1899.983077]  tcmu_get_empty_blocks+0x115/0x1c0 [target_core_user]
[ 1899.989318]  queue_cmd_ring+0x1da/0x630 [target_core_user]
[ 1899.994897]  ? rcu_read_lock_sched_held+0x3f/0x70
[ 1899.999695]  ? trace_kmalloc+0xa6/0xd0
[ 1900.003501]  ? __kmalloc+0x205/0x380
[ 1900.007167]  tcmu_queue_cmd+0x12f/0x160 [target_core_user]
[ 1900.012746]  __target_execute_cmd+0x23/0xa0 [target_core_mod]
[ 1900.018589]  transport_generic_new_cmd+0x1f3/0x370 [target_core_mod]
[ 1900.025046]  transport_handle_cdb_direct+0x34/0x50 [target_core_mod]
[ 1900.031517]  target_queued_submit_work+0x43/0xe0 [target_core_mod]
[ 1900.037837]  process_one_work+0x268/0x580
[ 1900.041952]  ? process_one_work+0x580/0x580
[ 1900.046195]  worker_thread+0x55/0x3b0
[ 1900.049921]  ? process_one_work+0x580/0x580
[ 1900.054192]  kthread+0x143/0x160
[ 1900.057499]  ? kthread_create_worker_on_cpu+0x40/0x40
[ 1900.062661]  ret_from_fork+0x1f/0x30

Link: https://lore.kernel.org/r/20210519135440.26773-1-bostroesser@gmail.com
Fixes: f5ce815f34bc ("scsi: target: tcmu: Support DATA_BLOCK_SIZE = N * PAGE_SIZE")
Reported-by: Shin'ichiro Kawasaki 
Tested-by: Shin'ichiro Kawasaki 
Signed-off-by: Bodo Stroesser 
Signed-off-by: Martin K. Petersen

scsi: target: tcmu: Return from tcmu_handle_completions() if cmd_id not found

2021-04-29T02:55:00+00:00

If tcmu_handle_completions() finds an invalid cmd_id while looping over cmd
responses from userspace it sets TCMU_DEV_BIT_BROKEN and breaks the
loop. This means that it does further handling for the tcmu device.

Skip that handling by replacing 'break' with 'return'.

Additionally change tcmu_handle_completions() from unsigned int to bool,
since the value used in return already is bool.

Link: https://lore.kernel.org/r/20210423150123.24468-1-bostroesser@gmail.com
Signed-off-by: Bodo Stroesser 
Signed-off-by: Martin K. Petersen

scsi: target: tcmu: Make data_pages_per_blk changeable via configfs

2021-04-13T02:40:56+00:00

Make data_pages_per_blk changeable similar to the way it is done for
max_data_area_mb. One can change the value by typing:

  echo "data_pages_per_blk=N" >control

The value is printed when doing:

  cat info

In addition, a new readonly attribute 'data_pages_per_blk' returns the
value on read.

Link: https://lore.kernel.org/r/20210324195758.2021-7-bostroesser@gmail.com
Signed-off-by: Bodo Stroesser 
Signed-off-by: Martin K. Petersen

scsi: target: tcmu: Replace block size definitions with new udev members

2021-04-13T02:40:56+00:00

Replace DATA_PAGES_PER_BLK and DATA_BLOCK_SIZE with new struct elements
tcmu_dev->data_pages_per_blk and tcmu_dev->data_blk_size.  These new
variables are still loaded with constant definition DATA_PAGES_PER_BLK_DEF
(= 1) and DATA_PAGES_PER_BLK_DEF * PAGE_SIZE.

There is no way yet to set the values via configfs.

Link: https://lore.kernel.org/r/20210324195758.2021-6-bostroesser@gmail.com
Signed-off-by: Bodo Stroesser 
Signed-off-by: Martin K. Petersen

scsi: target: tcmu: Remove function tcmu_get_block_page()

2021-04-13T02:40:55+00:00

There is only one caller of tcmu_get_block_page left. Since it is a
one-liner, we can remove the function.

Link: https://lore.kernel.org/r/20210324195758.2021-5-bostroesser@gmail.com
Signed-off-by: Bodo Stroesser 
Signed-off-by: Martin K. Petersen

scsi: target: tcmu: Support DATA_BLOCK_SIZE = N * PAGE_SIZE

2021-04-13T02:40:55+00:00

Change tcmu to support DATA_BLOCK_SIZE being a multiple of PAGE_SIZE. There
are two reasons why one would like to have a bigger DATA_BLOCK_SIZE:

 1) If userspace - e.g. due to data compression, encryption or
    deduplication - needs to have receive or transmit data in a consecutive
    buffer, we can define DATA_BLOCK_SIZE to the maximum size of a SCSI
    READ/WRITE to enforce that userspace sees just one consecutive
    buffer. That way we can avoid the need for doing data copy in
    userspace.

 2) Using a bigger data block size can speed up command processing in
    tcmu. The number of free data blocks to look up in bitmap is reduced
    substantially. The lookup for data pages in radix_tree can be done more
    efficiently if there are multiple pages in a data block. The maximum
    number of IOVs to set up is lower so cmd entries in the ring become
    smaller.

Link: https://lore.kernel.org/r/20210324195758.2021-4-bostroesser@gmail.com
Signed-off-by: Bodo Stroesser 
Signed-off-by: Martin K. Petersen

scsi: target: tcmu: Prepare for PAGE_SIZE != DATA_BLOCK_SIZE

2021-04-13T02:40:55+00:00

Rename some variables and definitions as a first preparation for
DATA_BLOCK_SIZE != PAGE_SIZE and add the new DATA_PAGES_PER_BLK definition
containing the number of pages per data block.

Rename tcmu_try_get_block_page() to tcmu_try_get_data_page(). Keep name
tcmu_get_block_page() since it will go away in a following commit when
there is only one caller left.  Subsequent commits will then add full
support for DATA_PAGES_PER_BLK != 1, which also means DATA_BLOCK_SIZE =
DATA_PAGES_PER_BLK * PAGE_SIZE

Link: https://lore.kernel.org/r/20210324195758.2021-3-bostroesser@gmail.com
Signed-off-by: Bodo Stroesser 
Signed-off-by: Martin K. Petersen

scsi: target: tcmu: Adjust names of variables and definitions

2021-04-13T02:40:55+00:00

Some definitions and members of struct tcmu_dev had misleading
names. Examples:

 - ring_size was used for the size of mailbox + cmd ring + data area

 - CMDR_SIZE was used for size of mailbox + cmd ring

I added the new definition MB_CMDR_SIZE (mailbox + command ring), changed
CMDR_SIZE to hold the size of the command ring only and replaced in struct
tcmu_dev the member ring_size with mmap_pages, because the member is now
used in tcmu_mmap() only, where we need page count, not size.

I also added the new struct tcmu_dev member 'cmdr' which is used to replace
some occurences of '(void *)mb + CMDR_OFF' with 'udev->cmdr' for better
readability.

Link: https://lore.kernel.org/r/20210324195758.2021-2-bostroesser@gmail.com
Signed-off-by: Bodo Stroesser 
Signed-off-by: Martin K. Petersen

scsi: target: tcmu: Adjust parameter in call to tcmu_blocks_release()

2021-03-16T03:18:37+00:00

In commit f7c89771d07d ("scsi: target: tcmu: Replace radix_tree with
XArray") the meaning of last parameter of tcmu_blocks_release() was
changed.  So in the callers we should subtract 1 from the previous
parameter.

Unfortunately that change got lost at one of the two places where
tcmu_blocks_release() is called. That does not lead to any problems, but we
should adjust it anyway.

Link: https://lore.kernel.org/r/20210310184458.10741-1-bostroesser@gmail.com
Signed-off-by: Bodo Stroesser 
Signed-off-by: Martin K. Petersen

scsi: target: tcmu: Use GFP_NOIO while handling cmds or holding cmdr_lock

2021-03-10T04:47:17+00:00

Especially when using tcmu with tcm_loop, memory allocations with
GFP_KERNEL for a LUN can cause write back to the same LUN.

So we have to use GFP_NOIO when allocation is done while handling commands
or while holding cmdr_lock.

Link: https://lore.kernel.org/r/20210305190009.32242-1-bostroesser@gmail.com
Reviewed-by: Mike Christie 
Signed-off-by: Bodo Stroesser 
Signed-off-by: Martin K. Petersen