Changes in target_core_user.c

8fa7292f - treewide: Switch/rename to timer_delete[_sync]()

Sat, 05 Apr 2025 08:17:26 +0000

treewide: Switch/rename to timer_delete[_sync]()timer_delete[_sync]() replaces del_timer[_sync](). Convert the whole treeover and remove the historical wrapper inlines.Conversion was done with coccinelle plus manual fixups where necessary.Signed-off-by: Thomas Gleixner Signed-off-by: Ingo Molnar List of files: /linux-6.15/drivers/target/target_core_user.c

5cd3167a - scsi: target: tcmu: Constify some structures

Mon, 11 Nov 2024 13:10:56 +0000

scsi: target: tcmu: Constify some structures'struct nla_policy' and 'struct match_table_t' are not modified in thisdriver.Constifying these structures moves some data to a read-only section, soincrease overall security, especially when the structure holds somefunction pointers, which is the case of struct nla_policy.On a x86_64, with allmodconfig:Before:====== text data bss dec hex filename 93188 6933 338 100459 1886b drivers/target/target_core_user.oAfter:===== text data bss dec hex filename 93508 6581 338 100427 1884b drivers/target/target_core_user.oSigned-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/f83cd8469cc17391178e1181e8c26c4c1fb6028f.1731330634.git.christophe.jaillet@wanadoo.frReviewed-by: Bodo Stroesser Signed-off-by: Martin K. Petersen List of files: /linux-6.15/drivers/target/target_core_user.c

56440d7e - genetlink: hold RCU in genlmsg_mcast()

Fri, 11 Oct 2024 17:12:17 +0000

genetlink: hold RCU in genlmsg_mcast()While running net selftests with CONFIG_PROVE_RCU_LIST=y I sawone lockdep splat [1].genlmsg_mcast() uses for_each_net_rcu(), and must therefore hold RCU.Instead of letting all callers guard genlmsg_multicast_allns()with a rcu_read_lock()/rcu_read_unlock() pair, do it in genlmsg_mcast().This also means the @flags parameter is useless, we need to always useGFP_ATOMIC.[1][10882.424136] =============================[10882.424166] WARNING: suspicious RCU usage[10882.424309] 6.12.0-rc2-virtme #1156 Not tainted[10882.424400] -----------------------------[10882.424423] net/netlink/genetlink.c:1940 RCU-list traversed in non-reader section!![10882.424469]other info that might help us debug this:[10882.424500]rcu_scheduler_active = 2, debug_locks = 1[10882.424744] 2 locks held by ip/15677:[10882.424791] #0: ffffffffb6b491b0 (cb_lock){++++}-{3:3}, at: genl_rcv (net/netlink/genetlink.c:1219)[10882.426334] #1: ffffffffb6b49248 (genl_mutex){+.+.}-{3:3}, at: genl_rcv_msg (net/netlink/genetlink.c:61 net/netlink/genetlink.c:57 net/netlink/genetlink.c:1209)[10882.426465]stack backtrace:[10882.426805] CPU: 14 UID: 0 PID: 15677 Comm: ip Not tainted 6.12.0-rc2-virtme #1156[10882.426919] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[10882.427046] Call Trace:[10882.427131] [10882.427244] dump_stack_lvl (lib/dump_stack.c:123)[10882.427335] lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822)[10882.427387] genlmsg_multicast_allns (net/netlink/genetlink.c:1940 (discriminator 7) net/netlink/genetlink.c:1977 (discriminator 7))[10882.427436] l2tp_tunnel_notify.constprop.0 (net/l2tp/l2tp_netlink.c:119) l2tp_netlink[10882.427683] l2tp_nl_cmd_tunnel_create (net/l2tp/l2tp_netlink.c:253) l2tp_netlink[10882.427748] genl_family_rcv_msg_doit (net/netlink/genetlink.c:1115)[10882.427834] genl_rcv_msg (net/netlink/genetlink.c:1195 net/netlink/genetlink.c:1210)[10882.427877] ? __pfx_l2tp_nl_cmd_tunnel_create (net/l2tp/l2tp_netlink.c:186) l2tp_netlink[10882.427927] ? __pfx_genl_rcv_msg (net/netlink/genetlink.c:1201)[10882.427959] netlink_rcv_skb (net/netlink/af_netlink.c:2551)[10882.428069] genl_rcv (net/netlink/genetlink.c:1220)[10882.428095] netlink_unicast (net/netlink/af_netlink.c:1332 net/netlink/af_netlink.c:1357)[10882.428140] netlink_sendmsg (net/netlink/af_netlink.c:1901)[10882.428210] ____sys_sendmsg (net/socket.c:729 (discriminator 1) net/socket.c:744 (discriminator 1) net/socket.c:2607 (discriminator 1))Fixes: 33f72e6f0c67 ("l2tp : multicast notification to the registered listeners")Signed-off-by: Eric Dumazet Cc: James Chapman Cc: Tom Parkin Cc: Johannes Berg Link: https://patch.msgid.link/20241011171217.3166614-1-edumazet@google.comSigned-off-by: Jakub Kicinski List of files: /linux-6.15/drivers/target/target_core_user.c

caf22c96 - scsi: target: tcmu: Annotate struct tcmu_tmr with __counted_by

Fri, 22 Sep 2023 17:53:01 +0000

scsi: target: tcmu: Annotate struct tcmu_tmr with __counted_byPrepare for the coming implementation by GCC and Clang of the __counted_byattribute. Flexible array members annotated with __counted_by can havetheir accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS(for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-familyfunctions).As found with Coccinelle[1], add __counted_by for struct tcmu_tmr.[1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocciCc: Bodo Stroesser Cc: "Martin K. Petersen" Cc: linux-scsi@vger.kernel.orgCc: target-devel@vger.kernel.orgSigned-off-by: Kees Cook Link: https://lore.kernel.org/r/20230922175300.work.148-kees@kernel.orgReviewed-by: "Gustavo A. R. Silva" Reviewed-by: Bodo Stroesser Signed-off-by: Martin K. Petersen List of files: /linux-6.15/drivers/target/target_core_user.c

4b2e2875 - scsi: target: tcmu: Replace strlcpy() with strscpy()

Wed, 21 Jun 2023 03:00:33 +0000

scsi: target: tcmu: Replace strlcpy() with strscpy()strlcpy() reads the entire source buffer first. This read may exceed thedestination size limit. This is both inefficient and can lead to linearread overflows if a source string is not NUL-terminated [1]. In an effortto remove strlcpy() completely [2], replace strlcpy() here with strscpy().No return values were used, so direct replacement is safe.[1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy[2] https://github.com/KSPP/linux/issues/89Signed-off-by: Azeem Shaikh Link: https://lore.kernel.org/r/20230621030033.3800351-3-azeemshaikh38@gmail.comReviewed-by: Kees Cook Signed-off-by: Martin K. Petersen List of files: /linux-6.15/drivers/target/target_core_user.c

1c71222e - mm: replace vma->vm_flags direct modifications with modifier calls

Thu, 26 Jan 2023 19:37:49 +0000

mm: replace vma->vm_flags direct modifications with modifier callsReplace direct modifications to vma->vm_flags with calls to modifierfunctions to be able to track flag changes and to keep vma lockingcorrectness.[akpm@linux-foundation.org: fix drivers/misc/open-dice.c, per Hyeonggon Yoo]Link: https://lkml.kernel.org/r/20230126193752.297968-5-surenb@google.comSigned-off-by: Suren Baghdasaryan Acked-by: Michal Hocko Acked-by: Mel Gorman Acked-by: Mike Rapoport (IBM) Acked-by: Sebastian Reichel Reviewed-by: Liam R. Howlett Reviewed-by: Hyeonggon Yoo <42.hyeyoo@gmail.com>Cc: Andy Lutomirski Cc: Arjun Roy Cc: Axel Rasmussen Cc: David Hildenbrand Cc: David Howells Cc: Davidlohr Bueso Cc: David Rientjes Cc: Eric Dumazet Cc: Greg Thelen Cc: Hugh Dickins Cc: Ingo Molnar Cc: Jann Horn Cc: Joel Fernandes Cc: Johannes Weiner Cc: Kent Overstreet Cc: Laurent Dufour Cc: Lorenzo Stoakes Cc: Matthew Wilcox Cc: Minchan Kim Cc: Paul E. McKenney Cc: Peter Oskolkov Cc: Peter Xu Cc: Peter Zijlstra Cc: Punit Agrawal Cc: Sebastian Andrzej Siewior Cc: Shakeel Butt Cc: Soheil Hassas Yeganeh Cc: Song Liu Cc: Vlastimil Babka Cc: Will Deacon Signed-off-by: Andrew Morton List of files: /linux-6.15/drivers/target/target_core_user.c

9c5d03d3 - genetlink: start to validate reserved header bytes

Thu, 25 Aug 2022 00:18:30 +0000

genetlink: start to validate reserved header bytesWe had historically not checked that genlmsghdr.reservedis 0 on input which prevents us from using those preciousbytes in the future.One use case would be to extend the cmd field, which iscurrently just 8 bits wide and 256 is not a lot of commandsfor some core families.To make sure that new families do the right thing by defaultput the onus of opting out of validation on existing families.Signed-off-by: Jakub Kicinski Acked-by: Paul Moore (NetLabel)Signed-off-by: David S. Miller List of files: /linux-6.15/drivers/target/target_core_user.c

325d5c5f - scsi: target: tcmu: Avoid holding XArray lock when calling lock_page

Tue, 17 May 2022 19:29:13 +0000

scsi: target: tcmu: Avoid holding XArray lock when calling lock_pageIn tcmu_blocks_release(), lock_page() is called to prevent a race causingpossible data corruption. Since lock_page() might sleep, calling it whileholding XArray lock is a bug.To fix this, replace the xas_for_each() call with xa_for_each_range().Since the latter does its own handling of XArray locking, the xas_lock()and xas_unlock() calls around the original loop are no longer necessary.The switch to xa_for_each_range() slows down the loop slightly. This isacceptable since tcmu_blocks_release() is not relevant for performance.Link: https://lore.kernel.org/r/20220517192913.21405-1-bostroesser@gmail.comFixes: bb9b9eb0ae2e ("scsi: target: tcmu: Fix possible data corruption")Reported-by: Dan Carpenter Signed-off-by: Bodo Stroesser Signed-off-by: Martin K. Petersen List of files: /linux-6.15/drivers/target/target_core_user.c

bb9b9eb0 - scsi: target: tcmu: Fix possible data corruption

Thu, 21 Apr 2022 02:37:35 +0000

scsi: target: tcmu: Fix possible data corruptionWhen tcmu_vma_fault() gets a page successfully, before the current contextcompletes page fault procedure, find_free_blocks() may run and callunmap_mapping_range() to unmap the page. Assume that whenfind_free_blocks() initially completes and the previous page faultprocedure starts to run again and completes, then one truncated page hasbeen mapped to userspace. But note that tcmu_vma_fault() has gotten arefcount for the page so any other subsystem won't be able to use the pageunless the userspace address is unmapped later.If another command subsequently runs and needs to extend dbi_thresh it mayreuse the corresponding slot for the previous page in data_bitmap. Thenthough we'll allocate new page for this slot in data_area, no page faultwill happen because we have a valid map and the real request's data will belost.Filesystem implementations will also run into this issue but they usuallylock the page when vm_operations_struct->fault gets a page and unlock thepage after finish_fault() completes. For truncate filesystems lock pages intruncate_inode_pages() to protect against racing wrt. page faults.To fix this possible data corruption scenario we can apply a method similarto the filesystems. For pages that are to be freed, tcmu_blocks_release()locks and unlocks. Make tcmu_vma_fault() also lock found page undercmdr_lock. At the same time, since tcmu_vma_fault() gets an extra pagerefcount, tcmu_blocks_release() won't free pages if pages are in page faultprocedure, which means it is safe to call tcmu_blocks_release() beforeunmap_mapping_range().With these changes tcmu_blocks_release() will wait for all page faults tobe completed before calling unmap_mapping_range(). And later, ifunmap_mapping_range() is called, it will ensure stale mappings are removed.Link: https://lore.kernel.org/r/20220421023735.9018-1-xiaoguang.wang@linux.alibaba.comReviewed-by: Bodo Stroesser Signed-off-by: Xiaoguang Wang Signed-off-by: Martin K. Petersen List of files: /linux-6.15/drivers/target/target_core_user.c

a6968f7a - scsi: target: tcmu: Fix possible page UAF

Fri, 11 Mar 2022 13:22:05 +0000

scsi: target: tcmu: Fix possible page UAFtcmu_try_get_data_page() looks up pages under cmdr_lock, but it does nottake refcount properly and just returns page pointer. Whentcmu_try_get_data_page() returns, the returned page may have been freed bytcmu_blocks_release().We need to get_page() under cmdr_lock to avoid concurrenttcmu_blocks_release().Link: https://lore.kernel.org/r/20220311132206.24515-1-xiaoguang.wang@linux.alibaba.comReviewed-by: Bodo Stroesser Signed-off-by: Xiaoguang Wang Signed-off-by: Martin K. Petersen List of files: /linux-6.15/drivers/target/target_core_user.c

c7ede4f0 - scsi: target: tcmu: Make cmd_ring_size changeable via configfs

Wed, 16 Feb 2022 02:21:49 +0000

scsi: target: tcmu: Make cmd_ring_size changeable via configfsMake cmd_ring_size changeable similar to the way it is done formax_data_area_mb. The reason is that our tcmu client will create thousandsof tcmu instances, and this will consume lots of mem with default 8Mb cmdring size for every backstore.One can change the value by typing: echo "cmd_ring_size_mb=N" > controlThe "N" is a integer between 1 to 8, if set 1, the cmd ring can hold about6k cmds(tcmu_cmd_entry about 176 byte) at least.The value is printed when doing: cat infoIn addition, a new readonly attribute 'cmd_ring_size_mb' returns the valuein read.Link: https://lore.kernel.org/r/1644978109-14885-1-git-send-email-kanie@linux.alibaba.comReviewed-by: Xiaoguang Wang Reviewed-by: Bodo Stroesser Signed-off-by: Guixin Liu Signed-off-by: Martin K. Petersen List of files: /linux-6.15/drivers/target/target_core_user.c

1d2ac7b6 - scsi: target: tcmu: Allocate zeroed pages for data area

Wed, 13 Oct 2021 17:16:06 +0000

scsi: target: tcmu: Allocate zeroed pages for data areaTcmu populates the data area (used for communication with userspace) withpages that are allocated by calling alloc_page(GFP_NOIO). Thereforeprevious content of the allocated pages is exposed to user space. Avoidthis by adding __GFP_ZERO flag.Zeroing the pages does (nearly) not affect tcmu throughput, becauseallocated pages are re-used for the data transfers of later SCSI cmds.Link: https://lore.kernel.org/r/20211013171606.25197-1-bostroesser@gmail.comSigned-off-by: Bodo Stroesser Signed-off-by: Martin K. Petersen List of files: /linux-6.15/drivers/target/target_core_user.c

c20bda34 - scsi: target: tcmu: Use struct_size() helper in kmalloc()

Mon, 27 Sep 2021 22:43:44 +0000

scsi: target: tcmu: Use struct_size() helper in kmalloc()Make use of the struct_size() helper instead of an open-coded version, inorder to avoid any potential type mistakes or integer overflows that, inthe worst scenario, could lead to heap overflows.Link: https://github.com/KSPP/linux/issues/160Link: https://lore.kernel.org/r/20210927224344.GA190701@embeddedorReviewed-by: Bodo Stroesser Signed-off-by: Gustavo A. R. Silva Signed-off-by: Martin K. Petersen List of files: /linux-6.15/drivers/target/target_core_user.c

018c1491 - scsi: target: tcmu: Add new feature KEEP_BUF

Tue, 13 Jul 2021 17:50:21 +0000

scsi: target: tcmu: Add new feature KEEP_BUFWhen running command pipelining for WRITE direction commands (e.g. tapedevice write), userspace sends cmd completion to cmd ring before processingwrite data. In that case userspace has to copy data before sendingcompletion, because cmd completion also implicitly releases the data bufferin data area.The new feature KEEP_BUF allows userspace to optionally keep the bufferafter completion by setting new bit TCMU_UFLAG_KEEP_BUF intcmu_cmd_entry_hdr->uflags. In that case buffer has to be releasedexplicitly by writing the cmd_id to new action item free_kept_buf.All kept buffers are released during reset_ring and if userspace closes uiodevice (tcmu_release).Link: https://lore.kernel.org/r/20210713175021.20103-1-bostroesser@gmail.comReviewed-by: Mike Christie Signed-off-by: Bodo Stroesser Signed-off-by: Martin K. Petersen List of files: /linux-6.15/drivers/target/target_core_user.c

82473125 - scsi: target: tcmu: Fix boolreturn.cocci warnings

Sat, 15 May 2021 23:03:58 +0000

scsi: target: tcmu: Fix boolreturn.cocci warningsdrivers/target/target_core_user.c:1424:9-10: WARNING: return of 0/1 in function 'tcmu_handle_completions' with return type bool Return statements in functions returning bool should use true/false instead of 1/0.Generated by: scripts/coccinelle/misc/boolreturn.cocciLink: https://lore.kernel.org/r/20210515230358.GA97544@60d1edce16e0Fixes: 9814b55cde05 ("scsi: target: tcmu: Return from tcmu_handle_completions() if cmd_id not found")CC: Bodo Stroesser Reported-by: kernel test robot Acked-by: Bodo Stroesser Signed-off-by: kernel test robot Signed-off-by: Martin K. Petersen List of files: /linux-6.15/drivers/target/target_core_user.c

b4150b68 - scsi: target: tcmu: Fix xarray RCU warning

Wed, 19 May 2021 13:54:40 +0000

scsi: target: tcmu: Fix xarray RCU warningCommit f5ce815f34bc ("scsi: target: tcmu: Support DATA_BLOCK_SIZE = N *PAGE_SIZE") introduced xas_next() calls to iterate xarray elements. Thesecalls triggered the WARNING "suspicious RCU usage" at tcmu device set up[1]. In the call stack of xas_next(), xas_load() was called. According toits 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/0x30Link: https://lore.kernel.org/r/20210519135440.26773-1-bostroesser@gmail.comFixes: 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 List of files: /linux-6.15/drivers/target/target_core_user.c

3ac0fcb4 - scsi: target: tcmu: Rename TCM_DEV_BIT_PLUGGED to TCMU_DEV_BIT_PLUGGED

Wed, 12 May 2021 14:06:54 +0000

scsi: target: tcmu: Rename TCM_DEV_BIT_PLUGGED to TCMU_DEV_BIT_PLUGGEDThe bit definition TCM_DEV_BIT_PLUGGED should correctly be namedTCMU_DEV_BIT_PLUGGED, since all other bits in the same bitfield have prefixTCMU_.Link: https://lore.kernel.org/r/20210512140654.31249-1-bostroesser@gmail.comSigned-off-by: Bodo Stroesser Signed-off-by: Martin K. Petersen List of files: /linux-6.15/drivers/target/target_core_user.c

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

Fri, 23 Apr 2021 15:01:23 +0000

scsi: target: tcmu: Return from tcmu_handle_completions() if cmd_id not foundIf tcmu_handle_completions() finds an invalid cmd_id while looping over cmdresponses from userspace it sets TCMU_DEV_BIT_BROKEN and breaks theloop. 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.comSigned-off-by: Bodo Stroesser Signed-off-by: Martin K. Petersen List of files: /linux-6.15/drivers/target/target_core_user.c

08976cb5 - scsi: target: tcmu: Make data_pages_per_blk changeable via configfs

Wed, 24 Mar 2021 19:57:58 +0000

scsi: target: tcmu: Make data_pages_per_blk changeable via configfsMake data_pages_per_blk changeable similar to the way it is done formax_data_area_mb. One can change the value by typing: echo "data_pages_per_blk=N" >controlThe value is printed when doing: cat infoIn addition, a new readonly attribute 'data_pages_per_blk' returns thevalue on read.Link: https://lore.kernel.org/r/20210324195758.2021-7-bostroesser@gmail.comSigned-off-by: Bodo Stroesser Signed-off-by: Martin K. Petersen List of files: /linux-6.15/drivers/target/target_core_user.c

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

Wed, 24 Mar 2021 19:57:57 +0000

scsi: target: tcmu: Replace block size definitions with new udev membersReplace DATA_PAGES_PER_BLK and DATA_BLOCK_SIZE with new struct elementstcmu_dev->data_pages_per_blk and tcmu_dev->data_blk_size. These newvariables 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.comSigned-off-by: Bodo Stroesser Signed-off-by: Martin K. Petersen List of files: /linux-6.15/drivers/target/target_core_user.c