Skip to contentSkip to conversation

remove exofs, the T10 OSD code and block/scsi bidi support V3

PATCH In review Christoph Hellwig 6 participants 23 messages Nov 11, 2018 – Dec 23, 2018

Subsystems (13)
Documentation VFS SCSI USB +9 more subsystems
lore
Share & tools
lore
#0 lore raw

The only real user of the T10 OSD protocol, the pNFS object layout driver never went to the point of having shipping products, and we removed it 1.5 years ago. Exofs is just a simple example without real life users.

The code has been mostly unmaintained for years and is getting in the way of block / SCSI changes, so I think it's finally time to drop it.

Quote from Boaz:

"As I said then. It is used in Universities for studies and experiments. Every once in a while. I get an email with questions and reports.

But yes feel free to remove the all thing!!

I guess I can put it up on github. In a public tree.

Just that I will need to forward port it myself, til now you guys been doing this for me ;-)"

Now the last time this caused a bit of a stir, but still no actual users, not even for SG_IO passthrough commands. So here we go again, this time including removing everything in the scsi and block layer supporting it, and thus shrinking struct request.

#1 lore raw

PATCH 1/8 fs: remove exofs

This was an example for using the SCSI OSD protocol, which we're trying to remove.

---
 Documentation/filesystems/exofs.txt |  185 ----
 Documentation/scsi/osd.txt          |    5 -
 MAINTAINERS                         |    1 -
 fs/Kconfig                          |    3 -
 fs/Makefile                         |    1 -
 fs/exofs/BUGS                       |    3 -
 fs/exofs/Kbuild                     |   20 -
 fs/exofs/Kconfig                    |   13 -
 fs/exofs/Kconfig.ore                |   14 -
 fs/exofs/common.h                   |  262 -----
 fs/exofs/dir.c                      |  661 ------------
 fs/exofs/exofs.h                    |  240 -----
 fs/exofs/file.c                     |   83 --
 fs/exofs/inode.c                    | 1514 ---------------------------
 fs/exofs/namei.c                    |  323 ------
 fs/exofs/ore.c                      | 1178 ---------------------
 fs/exofs/ore_raid.c                 |  756 -------------
 fs/exofs/ore_raid.h                 |   62 --
 fs/exofs/super.c                    | 1050 -------------------
 fs/exofs/sys.c                      |  205 ----
 20 files changed, 6579 deletions(-)
 delete mode 100644 Documentation/filesystems/exofs.txt
 delete mode 100644 fs/exofs/BUGS
 delete mode 100644 fs/exofs/Kbuild
 delete mode 100644 fs/exofs/Kconfig
 delete mode 100644 fs/exofs/Kconfig.ore
 delete mode 100644 fs/exofs/common.h
 delete mode 100644 fs/exofs/dir.c
 delete mode 100644 fs/exofs/exofs.h
 delete mode 100644 fs/exofs/file.c
 delete mode 100644 fs/exofs/inode.c
 delete mode 100644 fs/exofs/namei.c
 delete mode 100644 fs/exofs/ore.c
 delete mode 100644 fs/exofs/ore_raid.c
 delete mode 100644 fs/exofs/ore_raid.h
 delete mode 100644 fs/exofs/super.c
 delete mode 100644 fs/exofs/sys.c
Documentation/filesystems/exofs.txt deleted +0 -185
deleted file mode 100644
index 23583a136975..000000000000
@@ -1,185 +0,0 @@
-===============================================================================
-WHAT IS EXOFS?
-===============================================================================
-
-exofs is a file system that uses an OSD and exports the API of a normal Linux
-file system. Users access exofs like any other local file system, and exofs
-will in turn issue commands to the local OSD initiator.
-
-OSD is a new T10 command set that views storage devices not as a large/flat
-array of sectors but as a container of objects, each having a length, quota,
-time attributes and more. Each object is addressed by a 64bit ID, and is
-contained in a 64bit ID partition. Each object has associated attributes
-attached to it, which are integral part of the object and provide metadata about
-the object. The standard defines some common obligatory attributes, but user
-attributes can be added as needed.
-
-===============================================================================
-ENVIRONMENT
-===============================================================================
-
-To use this file system, you need to have an object store to run it on.  You
-may download a target from:
-http://open-osd.org
-
-See Documentation/scsi/osd.txt for how to setup a working osd environment.
-
-===============================================================================
-USAGE
-===============================================================================
-
-1. Download and compile exofs and open-osd initiator:
-  You need an external Kernel source tree or kernel headers from your
-  distribution. (anything based on 2.6.26 or later).
-
-  a. download open-osd including exofs source using:
-     [parent-directory]$ git clone git://git.open-osd.org/open-osd.git
-
-  b. Build the library module like this:
-     [parent-directory]$ make -C KSRC=$(KER_DIR) open-osd
-
-     This will build both the open-osd initiator as well as the exofs kernel
-     module. Use whatever parameters you compiled your Kernel with and
-     $(KER_DIR) above pointing to the Kernel you compile against. See the file
-     open-osd/top-level-Makefile for an example.
-
-2. Get the OSD initiator and target set up properly, and login to the target.
-  See Documentation/scsi/osd.txt for farther instructions. Also see ./do-osd
-  for example script that does all these steps.
-
-3. Insmod the exofs.ko module:
-   [exofs]$ insmod exofs.ko
-
-4. Make sure the directory where you want to mount exists. If not, create it.
-   (For example, mkdir /mnt/exofs)
-
-5. At first run you will need to invoke the mkfs.exofs application
-
-   As an example, this will create the file system on:
-   /dev/osd0 partition ID 65536
-
-   mkfs.exofs --pid=65536 --format /dev/osd0
-
-   The --format is optional. If not specified, no OSD_FORMAT will be
-   performed and a clean file system will be created in the specified pid,
-   in the available space of the target. (Use --format=size_in_meg to limit
-   the total LUN space available)
-
-   If pid already exists, it will be deleted and a new one will be created in
-   its place. Be careful.
-
-   An exofs lives inside a single OSD partition. You can create multiple exofs
-   filesystems on the same device using multiple pids.
-
-   (run mkfs.exofs without any parameters for usage help message)
-
-6. Mount the file system.
-
-   For example, to mount /dev/osd0, partition ID 0x10000 on /mnt/exofs:
-
-	mount -t exofs -o pid=65536 /dev/osd0 /mnt/exofs/
-
-7. For reference (See do-exofs example script):
-	do-exofs start - an example of how to perform the above steps.
-	do-exofs stop - an example of how to unmount the file system.
-	do-exofs format - an example of how to format and mkfs a new exofs.
-
-8. Extra compilation flags (uncomment in fs/exofs/Kbuild):
-	CONFIG_EXOFS_DEBUG - for debug messages and extra checks.
-
-===============================================================================
-exofs mount options
-===============================================================================
-Similar to any mount command:
-	mount -t exofs -o exofs_options /dev/osdX mount_exofs_directory
-
-Where:
-    -t exofs: specifies the exofs file system
-
-    /dev/osdX: X is a decimal number. /dev/osdX was created after a successful
-               login into an OSD target.
-
-    mount_exofs_directory: The directory to mount the file system on
-
-    exofs specific options: Options are separated by commas (,)
-		pid=<integer> - The partition number to mount/create as
-                                container of the filesystem.
-                                This option is mandatory. integer can be
-                                Hex by pre-pending an 0x to the number.
-		osdname=<id>  - Mount by a device's osdname.
-                                osdname is usually a 36 character uuid of the
-                                form "d2683732-c906-4ee1-9dbd-c10c27bb40df".
-                                It is one of the device's uuid specified in the
-                                mkfs.exofs format command.
-                                If this option is specified then the /dev/osdX
-                                above can be empty and is ignored.
-                to=<integer>  - Timeout in ticks for a single command.
-                                default is (60 * HZ) [for debugging only]
-
-===============================================================================
-DESIGN
-===============================================================================
-
-* The file system control block (AKA on-disk superblock) resides in an object
-  with a special ID (defined in common.h).
-  Information included in the file system control block is used to fill the
-  in-memory superblock structure at mount time. This object is created before
-  the file system is used by mkexofs.c. It contains information such as:
-	- The file system's magic number
-	- The next inode number to be allocated
-
-* Each file resides in its own object and contains the data (and it will be
-  possible to extend the file over multiple objects, though this has not been
-  implemented yet).
-
-* A directory is treated as a file, and essentially contains a list of <file
-  name, inode #> pairs for files that are found in that directory. The object
-  IDs correspond to the files' inode numbers and will be allocated according to
-  a bitmap (stored in a separate object). Now they are allocated using a
-  counter.
-
-* Each file's control block (AKA on-disk inode) is stored in its object's
-  attributes. This applies to both regular files and other types (directories,
-  device files, symlinks, etc.).
-
-* Credentials are generated per object (inode and superblock) when they are
-  created in memory (read from disk or created). The credential works for all
-  operations and is used as long as the object remains in memory.
-
-* Async OSD operations are used whenever possible, but the target may execute
-  them out of order. The operations that concern us are create, delete,
-  readpage, writepage, update_inode, and truncate. The following pairs of
-  operations should execute in the order written, and we need to prevent them
-  from executing in reverse order:
-	- The following are handled with the OBJ_CREATED and OBJ_2BCREATED
-	  flags. OBJ_CREATED is set when we know the object exists on the OSD -
-	  in create's callback function, and when we successfully do a
-	  read_inode.
-	  OBJ_2BCREATED is set in the beginning of the create function, so we
-	  know that we should wait.
-		- create/delete: delete should wait until the object is created
-		  on the OSD.
-		- create/readpage: readpage should be able to return a page
-		  full of zeroes in this case. If there was a write already
-		  en-route (i.e. create, writepage, readpage) then the page
-		  would be locked, and so it would really be the same as
-		  create/writepage.
-		- create/writepage: if writepage is called for a sync write, it
-		  should wait until the object is created on the OSD.
-		  Otherwise, it should just return.
-		- create/truncate: truncate should wait until the object is
-		  created on the OSD.
-		- create/update_inode: update_inode should wait until the
-		  object is created on the OSD.
-	- Handled by VFS locks:
-		- readpage/delete: shouldn't happen because of page lock.
-		- writepage/delete: shouldn't happen because of page lock.
-		- readpage/writepage: shouldn't happen because of page lock.
-
-===============================================================================
-LICENSE/COPYRIGHT
-===============================================================================
-The exofs file system is based on ext2 v0.5b (distributed with the Linux kernel
-version 2.6.10).  All files include the original copyrights, and the license
-is GPL version 2 (only version 2, as is true for the Linux kernel).  The
-Linux kernel can be downloaded from www.kernel.org.
Documentation/scsi/osd.txt +0 -5
index 5a9879bad073..2bc2ab06b0c0 100644
@@ -24,11 +24,6 @@ osd-uld:
 platform, both for the in-kernel initiator as well as connected targets. It
 currently has no useful user-mode API, though it could have if need be.
 
-exofs:
-  Is an OSD based Linux file system. It uses the osd-initiator and osd-uld,
-to export a usable file system for users.
-See Documentation/filesystems/exofs.txt for more details
-
 osd target:
   There are no current plans for an OSD target implementation in kernel. For all
 needs, a user-mode target that is based on the scsi tgt target framework is
MAINTAINERS +0 -1
index 2f3eba4484aa..bff844944d55 100644
@@ -11131,7 +11131,6 @@ M:	Boaz Harrosh <[email protected]>
 S:	Maintained
 F:	drivers/scsi/osd/
 F:	include/scsi/osd_*
-F:	fs/exofs/
 
 OV2659 OMNIVISION SENSOR DRIVER
 M:	"Lad, Prabhakar" <[email protected]>
fs/Kconfig +0 -3
index ac474a61be37..2557506051a3 100644
@@ -254,12 +254,9 @@ source "fs/romfs/Kconfig"
 source "fs/pstore/Kconfig"
 source "fs/sysv/Kconfig"
 source "fs/ufs/Kconfig"
-source "fs/exofs/Kconfig"
 
 endif # MISC_FILESYSTEMS
 
-source "fs/exofs/Kconfig.ore"
-
 menuconfig NETWORK_FILESYSTEMS
 	bool "Network File Systems"
 	default y
fs/Makefile +0 -1
index 293733f61594..4a930ee78d68 100644
@@ -124,7 +124,6 @@ obj-$(CONFIG_OCFS2_FS)		+= ocfs2/
 obj-$(CONFIG_BTRFS_FS)		+= btrfs/
 obj-$(CONFIG_GFS2_FS)           += gfs2/
 obj-$(CONFIG_F2FS_FS)		+= f2fs/
-obj-y				+= exofs/ # Multiple modules
 obj-$(CONFIG_CEPH_FS)		+= ceph/
 obj-$(CONFIG_PSTORE)		+= pstore/
 obj-$(CONFIG_EFIVAR_FS)		+= efivarfs/
fs/exofs/BUGS deleted +0 -3
deleted file mode 100644
index 1b2d4c63a579..000000000000
@@ -1,3 +0,0 @@
-- Out-of-space may cause a severe problem if the object (and directory entry)
-  were written, but the inode attributes failed. Then if the filesystem was
-  unmounted and mounted the kernel can get into an endless loop doing a readdir.
fs/exofs/Kbuild deleted +0 -20
deleted file mode 100644
index a364fd0965ec..000000000000
@@ -1,20 +0,0 @@
-#
-# Kbuild for the EXOFS module
-#
-# Copyright (C) 2008 Panasas Inc.  All rights reserved.
-#
-# Authors:
-#   Boaz Harrosh <[email protected]>
-#
-# This program is free software; you can redistribute it and/or modify
-# it under the terms of the GNU General Public License version 2
-#
-# Kbuild - Gets included from the Kernels Makefile and build system
-#
-
-# ore module library
-libore-y := ore.o ore_raid.o
-obj-$(CONFIG_ORE) += libore.o
-
-exofs-y := inode.o file.o namei.o dir.o super.o sys.o
-obj-$(CONFIG_EXOFS_FS) += exofs.o
fs/exofs/Kconfig deleted +0 -13
deleted file mode 100644
index 86194b2f799d..000000000000
@@ -1,13 +0,0 @@
-config EXOFS_FS
-	tristate "exofs: OSD based file system support"
-	depends on SCSI_OSD_ULD
-	help
-	  EXOFS is a file system that uses an OSD storage device,
-	  as its backing storage.
-
-# Debugging-related stuff
-config EXOFS_DEBUG
-	bool "Enable debugging"
-	depends on EXOFS_FS
-	help
-	  This option enables EXOFS debug prints.
fs/exofs/Kconfig.ore deleted +0 -14
deleted file mode 100644
index 2daf2329c28d..000000000000
@@ -1,14 +0,0 @@
-# ORE - Objects Raid Engine (libore.ko)
-#
-# Note ORE needs to "select ASYNC_XOR". So Not to force multiple selects
-# for every ORE user we do it like this. Any user should add itself here
-# at the "depends on EXOFS_FS || ..." with an ||. The dependencies are
-# selected here, and we default to "ON". So in effect it is like been
-# selected by any of the users.
-config ORE
-	tristate
-	depends on EXOFS_FS || PNFS_OBJLAYOUT
-	select ASYNC_XOR
-	select RAID6_PQ
-	select ASYNC_PQ
-	default SCSI_OSD_ULD
fs/exofs/common.h deleted +0 -262

262 lines not on this page · raw message

fs/exofs/dir.c deleted +0 -661

661 lines not on this page · raw message

fs/exofs/exofs.h deleted +0 -240

240 lines not on this page · raw message

fs/exofs/file.c deleted +0 -83

83 lines not on this page · raw message

fs/exofs/inode.c deleted +0 -1514

1,482 lines not on this page · raw message

fs/exofs/namei.c deleted +0 -323

323 lines not on this page · raw message

fs/exofs/ore.c deleted +0 -1178

1,178 lines not on this page · raw message

fs/exofs/ore_raid.c deleted +0 -756

756 lines not on this page · raw message

fs/exofs/ore_raid.h deleted +0 -62

62 lines not on this page · raw message

fs/exofs/super.c deleted +0 -1050

1,050 lines not on this page · raw message

fs/exofs/sys.c deleted +0 -205

205 lines not on this page · raw message

The rest of this diff is not shown. View the raw message.

Signature · 1 line
2.19.1

Part of the diff is not shown here. View the raw message.

#2 lore raw

PATCH 2/8 scsi: remove the SCSI OSD library

In reply to Christoph Hellwig

Now that all the users are gone the SCSI OSD library can be removed as well.

---
 Documentation/scsi/osd.txt       |  192 ---
 drivers/scsi/Kconfig             |    2 -
 drivers/scsi/Makefile            |    1 -
 drivers/scsi/osd/Kbuild          |   20 -
 drivers/scsi/osd/Kconfig         |   49 -
 drivers/scsi/osd/osd_debug.h     |   30 -
 drivers/scsi/osd/osd_initiator.c | 2076 ------------------------------
 drivers/scsi/osd/osd_uld.c       |  571 --------
 include/scsi/osd_initiator.h     |  511 --------
 include/scsi/osd_ore.h           |  201 ---
 10 files changed, 3653 deletions(-)
 delete mode 100644 Documentation/scsi/osd.txt
 delete mode 100644 drivers/scsi/osd/Kbuild
 delete mode 100644 drivers/scsi/osd/Kconfig
 delete mode 100644 drivers/scsi/osd/osd_debug.h
 delete mode 100644 drivers/scsi/osd/osd_initiator.c
 delete mode 100644 drivers/scsi/osd/osd_uld.c
 delete mode 100644 include/scsi/osd_initiator.h
 delete mode 100644 include/scsi/osd_ore.h
Documentation/scsi/osd.txt deleted +0 -192
deleted file mode 100644
index 2bc2ab06b0c0..000000000000
@@ -1,192 +0,0 @@
-The OSD Standard
-================
-OSD (Object-Based Storage Device) is a T10 SCSI command set that is designed
-to provide efficient operation of input/output logical units that manage the
-allocation, placement, and accessing of variable-size data-storage containers,
-called objects. Objects are intended to contain operating system and application
-constructs. Each object has associated attributes attached to it, which are
-integral part of the object and provide metadata about the object. The standard
-defines some common obligatory attributes, but user attributes can be added as
-needed.
-
-See: http://www.t10.org/ftp/t10/drafts/osd2/ for the latest draft for OSD 2
-or search the web for "OSD SCSI"
-
-OSD in the Linux Kernel
-=======================
-osd-initiator:
-  The main component of OSD in Kernel is the osd-initiator library. Its main
-user is intended to be the pNFS-over-objects layout driver, which uses objects
-as its back-end data storage. Other clients are the other osd parts listed below.
-
-osd-uld:
-  This is a SCSI ULD that registers for OSD type devices and provides a testing
-platform, both for the in-kernel initiator as well as connected targets. It
-currently has no useful user-mode API, though it could have if need be.
-
-osd target:
-  There are no current plans for an OSD target implementation in kernel. For all
-needs, a user-mode target that is based on the scsi tgt target framework is
-available from Ohio Supercomputer Center (OSC) at:
-http://www.open-osd.org/bin/view/Main/OscOsdProject
-There are several other target implementations. See http://open-osd.org for more
-links.
-
-Files and Folders
-=================
-This is the complete list of files included in this work:
-include/scsi/
-	osd_initiator.h   Main API for the initiator library
-	osd_types.h	  Common OSD types
-	osd_sec.h	  Security Manager API
-	osd_protocol.h	  Wire definitions of the OSD standard protocol
-	osd_attributes.h  Wire definitions of OSD attributes
-
-drivers/scsi/osd/
-	osd_initiator.c   OSD-Initiator library implementation
-	osd_uld.c	  The OSD scsi ULD
-	osd_ktest.{h,c}	  In-kernel test suite (called by osd_uld)
-	osd_debug.h	  Some printk macros
-	Makefile	  For both in-tree and out-of-tree compilation
-	Kconfig		  Enables inclusion of the different pieces
-	osd_test.c	  User-mode application to call the kernel tests
-
-The OSD-Initiator Library
-=========================
-osd_initiator is a low level implementation of an osd initiator encoder.
-But even though, it should be intuitive and easy to use. Perhaps over time an
-higher lever will form that automates some of the more common recipes.
-
-init/fini:
-- osd_dev_init() associates a scsi_device with an osd_dev structure
-  and initializes some global pools. This should be done once per scsi_device
-  (OSD LUN). The osd_dev structure is needed for calling osd_start_request().
-
-- osd_dev_fini() cleans up before a osd_dev/scsi_device destruction.
-
-OSD commands encoding, execution, and decoding of results:
-
-struct osd_request's is used to iteratively encode an OSD command and carry
-its state throughout execution. Each request goes through these stages:
-
-a. osd_start_request() allocates the request.
-
-b. Any of the osd_req_* methods is used to encode a request of the specified
-   type.
-
-c. osd_req_add_{get,set}_attr_* may be called to add get/set attributes to the
-   CDB. "List" or "Page" mode can be used exclusively. The attribute-list API
-   can be called multiple times on the same request. However, only one
-   attribute-page can be read, as mandated by the OSD standard.
-
-d. osd_finalize_request() computes offsets into the data-in and data-out buffers
-   and signs the request using the provided capability key and integrity-
-   check parameters.
-
-e. osd_execute_request() may be called to execute the request via the block
-   layer and wait for its completion.  The request can be executed
-   asynchronously by calling the block layer API directly.
-
-f. After execution, osd_req_decode_sense() can be called to decode the request's
-   sense information.
-
-g. osd_req_decode_get_attr() may be called to retrieve osd_add_get_attr_list()
-   values.
-
-h. osd_end_request() must be called to deallocate the request and any resource
-   associated with it. Note that osd_end_request cleans up the request at any
-   stage and it must always be called after a successful osd_start_request().
-
-osd_request's structure:
-
-The OSD standard defines a complex structure of IO segments pointed to by
-members in the CDB. Up to 3 segments can be deployed in the IN-Buffer and up to
-4 in the OUT-Buffer. The ASCII illustration below depicts a secure-read with
-associated get+set of attributes-lists. Other combinations very on the same
-basic theme. From no-segments-used up to all-segments-used.
-
-|________OSD-CDB__________|
-|                         |
-|read_len (offset=0)     -|---------\
-|                         |         |
-|get_attrs_list_length    |         |
-|get_attrs_list_offset   -|----\    |
-|                         |    |    |
-|retrieved_attrs_alloc_len|    |    |
-|retrieved_attrs_offset  -|----|----|-\
-|                         |    |    | |
-|set_attrs_list_length    |    |    | |
-|set_attrs_list_offset   -|-\  |    | |
-|                         | |  |    | |
-|in_data_integ_offset    -|-|--|----|-|-\
-|out_data_integ_offset   -|-|--|--\ | | |
-\_________________________/ |  |  | | | |
-                            |  |  | | | |
-|_______OUT-BUFFER________| |  |  | | | |
-|      Set attr list      |</  |  | | | |
-|                         |    |  | | | |
-|-------------------------|    |  | | | |
-|   Get attr descriptors  |<---/  | | | |
-|                         |       | | | |
-|-------------------------|       | | | |
-|    Out-data integrity   |<------/ | | |
-|                         |         | | |
-\_________________________/         | | |
-                                    | | |
-|________IN-BUFFER________|         | | |
-|      In-Data read       |<--------/ | |
-|                         |           | |
-|-------------------------|           | |
-|      Get attr list      |<----------/ |
-|                         |             |
-|-------------------------|             |
-|    In-data integrity    |<------------/
-|                         |
-\_________________________/
-
-A block device request can carry bidirectional payload by means of associating
-a bidi_read request with a main write-request. Each in/out request is described
-by a chain of BIOs associated with each request.
-The CDB is of a SCSI VARLEN CDB format, as described by OSD standard.
-The OSD standard also mandates alignment restrictions at start of each segment.
-
-In the code, in struct osd_request, there are two _osd_io_info structures to
-describe the IN/OUT buffers above, two BIOs for the data payload and up to five
-_osd_req_data_segment structures to hold the different segments allocation and
-information.
-
-Important: We have chosen to disregard the assumption that a BIO-chain (and
-the resulting sg-list) describes a linear memory buffer. Meaning only first and
-last scatter chain can be incomplete and all the middle chains are of PAGE_SIZE.
-For us, a scatter-gather-list, as its name implies and as used by the Networking
-layer, is to describe a vector of buffers that will be transferred to/from the
-wire. It works very well with current iSCSI transport. iSCSI is currently the
-only deployed OSD transport. In the future we anticipate SAS and FC attached OSD
-devices as well.
-
-The OSD Testing ULD
-===================
-TODO: More user-mode control on tests.
-
-Authors, Mailing list
-=====================
-Please communicate with us on any deployment of osd, whether using this code
-or not.
-
-Any problems, questions, bug reports, lonely OSD nights, please email:
-   OSD Dev List <[email protected]>
-
-More up-to-date information can be found on:
-http://open-osd.org
-
-Boaz Harrosh <[email protected]>
-
-References
-==========
-Weber, R., "SCSI Object-Based Storage Device Commands",
-T10/1355-D ANSI/INCITS 400-2004,
-http://www.t10.org/ftp/t10/drafts/osd/osd-r10.pdf
-
-Weber, R., "SCSI Object-Based Storage Device Commands -2 (OSD-2)"
-T10/1729-D, Working Draft, rev. 3
-http://www.t10.org/ftp/t10/drafts/osd2/osd2r03.pdf
drivers/scsi/Kconfig +0 -2
index dfdc6940de2f..167e9824b597 100644
@@ -1516,6 +1516,4 @@ source "drivers/scsi/pcmcia/Kconfig"
 
 source "drivers/scsi/device_handler/Kconfig"
 
-source "drivers/scsi/osd/Kconfig"
-
 endmenu
drivers/scsi/Makefile +0 -1
index fcb41ae329c4..8826111fdf4a 100644
@@ -150,7 +150,6 @@ obj-$(CONFIG_CHR_DEV_SG)	+= sg.o
 obj-$(CONFIG_CHR_DEV_SCH)	+= ch.o
 obj-$(CONFIG_SCSI_ENCLOSURE)	+= ses.o
 
-obj-$(CONFIG_SCSI_OSD_INITIATOR) += osd/
 obj-$(CONFIG_SCSI_HISI_SAS) += hisi_sas/
 
 # This goes last, so that "real" scsi devices probe earlier
drivers/scsi/osd/Kbuild deleted +0 -20
deleted file mode 100644
index 58cecd45b0f5..000000000000
@@ -1,20 +0,0 @@
-#
-# Kbuild for the OSD modules
-#
-# Copyright (C) 2008 Panasas Inc.  All rights reserved.
-#
-# Authors:
-#   Boaz Harrosh <[email protected]>
-#   Benny Halevy <[email protected]>
-#
-# This program is free software; you can redistribute it and/or modify
-# it under the terms of the GNU General Public License version 2
-#
-
-# libosd.ko - osd-initiator library
-libosd-y := osd_initiator.o
-obj-$(CONFIG_SCSI_OSD_INITIATOR) += libosd.o
-
-# osd.ko - SCSI ULD and char-device
-osd-y := osd_uld.o
-obj-$(CONFIG_SCSI_OSD_ULD) += osd.o
drivers/scsi/osd/Kconfig deleted +0 -49

49 lines not on this page · raw message

drivers/scsi/osd/osd_debug.h deleted +0 -30
deleted file mode 100644
index 26341261bb5c..000000000000
@@ -1,30 +0,0 @@
-/*
- * osd_debug.h - Some kprintf macros
- *
- * Copyright (C) 2008 Panasas Inc.  All rights reserved.
- *
- * Authors:
- *   Boaz Harrosh <[email protected]>
- *   Benny Halevy <[email protected]>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2
- *
- */
-#ifndef __OSD_DEBUG_H__
-#define __OSD_DEBUG_H__
-
-#define OSD_ERR(fmt, a...) printk(KERN_ERR "osd: " fmt, ##a)
-#define OSD_INFO(fmt, a...) printk(KERN_NOTICE "osd: " fmt, ##a)
-
-#ifdef CONFIG_SCSI_OSD_DEBUG
-#define OSD_DEBUG(fmt, a...) \
-	printk(KERN_NOTICE "osd @%s:%d: " fmt, __func__, __LINE__, ##a)
-#else
-#define OSD_DEBUG(fmt, a...) do {} while (0)
-#endif
-
-/* u64 has problems with printk this will cast it to unsigned long long */
-#define _LLU(x) (unsigned long long)(x)
-
-#endif /* ndef __OSD_DEBUG_H__ */
drivers/scsi/osd/osd_initiator.c deleted +0 -2076

2,076 lines not on this page · raw message

drivers/scsi/osd/osd_uld.c deleted +0 -571

571 lines not on this page · raw message

include/scsi/osd_initiator.h deleted +0 -511

49 lines not on this page · raw message

include/scsi/osd_ore.h deleted +0 -201

201 lines not on this page · raw message

The rest of this diff is not shown. View the raw message.

Signature · 1 line
2.19.1

Part of the diff is not shown here. View the raw message.

#3 lore raw

PATCH 3/8 scsi: remove bidirectional command support

In reply to Christoph Hellwig

No real need for bidi support once the OSD code is gone.

---
 drivers/scsi/cxgbi/libcxgbi.c      | 13 +++---
 drivers/scsi/iscsi_tcp.c           |  9 +----
 drivers/scsi/libiscsi.c            | 64 +++---------------------------
 drivers/scsi/libiscsi_tcp.c        |  8 ++--
 drivers/scsi/scsi_debug.c          | 51 +++++-------------------
 drivers/scsi/scsi_error.c          |  3 --
 drivers/scsi/scsi_lib.c            | 58 ++-------------------------
 drivers/scsi/virtio_scsi.c         | 14 ++-----
 drivers/target/loopback/tcm_loop.c | 15 -------
 drivers/usb/storage/uas.c          | 11 +----
 include/scsi/scsi_cmnd.h           | 19 +--------
 include/scsi/scsi_eh.h             |  1 -
 12 files changed, 35 insertions(+), 231 deletions(-)
drivers/scsi/cxgbi/libcxgbi.c +5 -8
index 75f876409fb9..4466ae5c9a74 100644
@@ -1211,7 +1211,7 @@ scmd_get_params(struct scsi_cmnd *sc, struct scatterlist **sgl,
 		unsigned int *sgcnt, unsigned int *dlen,
 		unsigned int prot)
 {
-	struct scsi_data_buffer *sdb = prot ? scsi_prot(sc) : scsi_out(sc);
+	struct scsi_data_buffer *sdb = prot ? scsi_prot(sc) : &sc->sdb;
 
 	*sgl = sdb->table.sgl;
 	*sgcnt = sdb->table.nents;
@@ -1427,8 +1427,7 @@ static void task_release_itt(struct iscsi_task *task, itt_t hdr_itt)
 	log_debug(1 << CXGBI_DBG_DDP,
 		  "cdev 0x%p, task 0x%p, release tag 0x%x.\n",
 		  cdev, task, tag);
-	if (sc &&
-	    (scsi_bidi_cmnd(sc) || sc->sc_data_direction == DMA_FROM_DEVICE) &&
+	if (sc && sc->sc_data_direction == DMA_FROM_DEVICE &&
 	    cxgbi_ppm_is_ddp_tag(ppm, tag)) {
 		struct cxgbi_task_data *tdata = iscsi_task_cxgbi_data(task);
 		struct cxgbi_task_tag_info *ttinfo = &tdata->ttinfo;
@@ -1460,9 +1459,7 @@ static int task_reserve_itt(struct iscsi_task *task, itt_t *hdr_itt)
 	u32 tag = 0;
 	int err = -EINVAL;
 
-	if (sc &&
-	    (scsi_bidi_cmnd(sc) || sc->sc_data_direction == DMA_FROM_DEVICE)
-	) {
+	if (sc && sc->sc_data_direction == DMA_FROM_DEVICE) {
 		struct cxgbi_task_data *tdata = iscsi_task_cxgbi_data(task);
 		struct cxgbi_task_tag_info *ttinfo = &tdata->ttinfo;
 
@@ -1896,7 +1893,7 @@ int cxgbi_conn_alloc_pdu(struct iscsi_task *task, u8 opcode)
 	if (SKB_MAX_HEAD(cdev->skb_tx_rsvd) > (512 * MAX_SKB_FRAGS) &&
 	    (opcode == ISCSI_OP_SCSI_DATA_OUT ||
 	     (opcode == ISCSI_OP_SCSI_CMD &&
-	      (scsi_bidi_cmnd(sc) || sc->sc_data_direction == DMA_TO_DEVICE))))
+	      sc->sc_data_direction == DMA_TO_DEVICE)))
 		/* data could goes into skb head */
 		headroom += min_t(unsigned int,
 				SKB_MAX_HEAD(cdev->skb_tx_rsvd),
@@ -1971,7 +1968,7 @@ int cxgbi_conn_init_pdu(struct iscsi_task *task, unsigned int offset,
 		return 0;
 
 	if (task->sc) {
-		struct scsi_data_buffer *sdb = scsi_out(task->sc);
+		struct scsi_data_buffer *sdb = &task->sc->sdb;
 		struct scatterlist *sg = NULL;
 		int err;
 
drivers/scsi/iscsi_tcp.c +1 -8
index 23354f206533..a78b46bb2b71 100644
@@ -514,7 +514,7 @@ static int iscsi_sw_tcp_pdu_init(struct iscsi_task *task,
 	if (!task->sc)
 		iscsi_sw_tcp_send_linear_data_prep(conn, task->data, count);
 	else {
-		struct scsi_data_buffer *sdb = scsi_out(task->sc);
+		struct scsi_data_buffer *sdb = &task->sc->sdb;
 
 		err = iscsi_sw_tcp_send_data_prep(conn, sdb->table.sgl,
 						  sdb->table.nents, offset,
@@ -948,12 +948,6 @@ static umode_t iscsi_sw_tcp_attr_is_visible(int param_type, int param)
 	return 0;
 }
 
-static int iscsi_sw_tcp_slave_alloc(struct scsi_device *sdev)
-{
-	blk_queue_flag_set(QUEUE_FLAG_BIDI, sdev->request_queue);
-	return 0;
-}
-
 static int iscsi_sw_tcp_slave_configure(struct scsi_device *sdev)
 {
 	struct iscsi_sw_tcp_host *tcp_sw_host = iscsi_host_priv(sdev->host);
@@ -981,7 +975,6 @@ static struct scsi_host_template iscsi_sw_tcp_sht = {
 	.eh_device_reset_handler= iscsi_eh_device_reset,
 	.eh_target_reset_handler = iscsi_eh_recover_target,
 	.use_clustering         = DISABLE_CLUSTERING,
-	.slave_alloc            = iscsi_sw_tcp_slave_alloc,
 	.slave_configure        = iscsi_sw_tcp_slave_configure,
 	.target_alloc		= iscsi_target_alloc,
 	.proc_name		= "iscsi_tcp",
drivers/scsi/libiscsi.c +6 -58

109 lines not on this page · raw message

drivers/scsi/libiscsi_tcp.c +4 -4
index 4fcb9e65be57..1ec8332df515 100644
@@ -491,7 +491,7 @@ static int iscsi_tcp_data_in(struct iscsi_conn *conn, struct iscsi_task *task)
 	struct iscsi_tcp_task *tcp_task = task->dd_data;
 	struct iscsi_data_rsp *rhdr = (struct iscsi_data_rsp *)tcp_conn->in.hdr;
 	int datasn = be32_to_cpu(rhdr->datasn);
-	unsigned total_in_length = scsi_in(task->sc)->length;
+	unsigned total_in_length = task->sc->sdb.length;
 
 	/*
 	 * lib iscsi will update this in the completion handling if there
@@ -576,11 +576,11 @@ static int iscsi_tcp_r2t_rsp(struct iscsi_conn *conn, struct iscsi_task *task)
 			      data_length, session->max_burst);
 
 	data_offset = be32_to_cpu(rhdr->data_offset);
-	if (data_offset + data_length > scsi_out(task->sc)->length) {
+	if (data_offset + data_length > task->sc->sdb.length) {
 		iscsi_conn_printk(KERN_ERR, conn,
 				  "invalid R2T with data len %u at offset %u "
 				  "and total length %d\n", data_length,
-				  data_offset, scsi_out(task->sc)->length);
+				  data_offset, task->sc->sdb.length);
 		return ISCSI_ERR_DATALEN;
 	}
 
@@ -692,7 +692,7 @@ iscsi_tcp_hdr_dissect(struct iscsi_conn *conn, struct iscsi_hdr *hdr)
 		if (tcp_conn->in.datalen) {
 			struct iscsi_tcp_task *tcp_task = task->dd_data;
 			struct ahash_request *rx_hash = NULL;
-			struct scsi_data_buffer *sdb = scsi_in(task->sc);
+			struct scsi_data_buffer *sdb = &task->sc->sdb;
 
 			/*
 			 * Setup copy of Data-In into the struct scsi_cmnd
drivers/scsi/scsi_debug.c +9 -42

129 lines not on this page · raw message

drivers/scsi/scsi_error.c +0 -3
index dd338a8cd275..8bdfa2999916 100644
@@ -965,7 +965,6 @@ void scsi_eh_prep_cmnd(struct scsi_cmnd *scmd, struct scsi_eh_save *ses,
 	ses->cmnd = scmd->cmnd;
 	ses->data_direction = scmd->sc_data_direction;
 	ses->sdb = scmd->sdb;
-	ses->next_rq = scmd->request->next_rq;
 	ses->result = scmd->result;
 	ses->underflow = scmd->underflow;
 	ses->prot_op = scmd->prot_op;
@@ -976,7 +975,6 @@ void scsi_eh_prep_cmnd(struct scsi_cmnd *scmd, struct scsi_eh_save *ses,
 	scmd->cmnd = ses->eh_cmnd;
 	memset(scmd->cmnd, 0, BLK_MAX_CDB);
 	memset(&scmd->sdb, 0, sizeof(scmd->sdb));
-	scmd->request->next_rq = NULL;
 	scmd->result = 0;
 
 	if (sense_bytes) {
@@ -1029,7 +1027,6 @@ void scsi_eh_restore_cmnd(struct scsi_cmnd* scmd, struct scsi_eh_save *ses)
 	scmd->cmnd = ses->cmnd;
 	scmd->sc_data_direction = ses->data_direction;
 	scmd->sdb = ses->sdb;
-	scmd->request->next_rq = ses->next_rq;
 	scmd->result = ses->result;
 	scmd->underflow = ses->underflow;
 	scmd->prot_op = ses->prot_op;
drivers/scsi/scsi_lib.c +4 -54

111 lines not on this page · raw message

drivers/scsi/virtio_scsi.c +3 -11
index c3c95b314286..bf95436ebb50 100644
@@ -127,16 +127,8 @@ static inline struct Scsi_Host *virtio_scsi_host(struct virtio_device *vdev)
 
 static void virtscsi_compute_resid(struct scsi_cmnd *sc, u32 resid)
 {
-	if (!resid)
-		return;
-
-	if (!scsi_bidi_cmnd(sc)) {
+	if (resid)
 		scsi_set_resid(sc, resid);
-		return;
-	}
-
-	scsi_in(sc)->resid = min(resid, scsi_in(sc)->length);
-	scsi_out(sc)->resid = resid - scsi_in(sc)->resid;
 }
 
 /**
@@ -430,9 +422,9 @@ static int virtscsi_add_cmd(struct virtqueue *vq,
 
 	if (sc && sc->sc_data_direction != DMA_NONE) {
 		if (sc->sc_data_direction != DMA_FROM_DEVICE)
-			out = &scsi_out(sc)->table;
+			out = &sc->sdb.table;
 		if (sc->sc_data_direction != DMA_TO_DEVICE)
-			in = &scsi_in(sc)->table;
+			in = &sc->sdb.table;
 	}
 
 	/* Request header.  */
drivers/target/loopback/tcm_loop.c +0 -15
index bc8918f382e4..a43bb76cccf6 100644
@@ -128,14 +128,6 @@ static void tcm_loop_submission_work(struct work_struct *work)
 		set_host_byte(sc, DID_ERROR);
 		goto out_done;
 	}
-	if (scsi_bidi_cmnd(sc)) {
-		struct scsi_data_buffer *sdb = scsi_in(sc);
-
-		sgl_bidi = sdb->table.sgl;
-		sgl_bidi_count = sdb->table.nents;
-		se_cmd->se_cmd_flags |= SCF_BIDI;
-
-	}
 
 	transfer_length = scsi_transfer_length(sc);
 	if (!scsi_prot_sg_count(sc) &&
@@ -304,12 +296,6 @@ static int tcm_loop_target_reset(struct scsi_cmnd *sc)
 	return FAILED;
 }
 
-static int tcm_loop_slave_alloc(struct scsi_device *sd)
-{
-	blk_queue_flag_set(QUEUE_FLAG_BIDI, sd->request_queue);
-	return 0;
-}
-
 static struct scsi_host_template tcm_loop_driver_template = {
 	.show_info		= tcm_loop_show_info,
 	.proc_name		= "tcm_loopback",
@@ -325,7 +311,6 @@ static struct scsi_host_template tcm_loop_driver_template = {
 	.cmd_per_lun		= 1024,
 	.max_sectors		= 0xFFFF,
 	.use_clustering		= DISABLE_CLUSTERING,
-	.slave_alloc		= tcm_loop_slave_alloc,
 	.module			= THIS_MODULE,
 	.track_queue_depth	= 1,
 };
drivers/usb/storage/uas.c +2 -9
index 1f7b401c4d04..1c3bff3d57b0 100644
@@ -368,25 +368,19 @@ static void uas_data_cmplt(struct urb *urb)
 	struct scsi_cmnd *cmnd = urb->context;
 	struct uas_cmd_info *cmdinfo = (void *)&cmnd->SCp;
 	struct uas_dev_info *devinfo = (void *)cmnd->device->hostdata;
-	struct scsi_data_buffer *sdb = NULL;
+	struct scsi_data_buffer *sdb = &cmnd->sdb;
 	unsigned long flags;
 	int status = urb->status;
 
 	spin_lock_irqsave(&devinfo->lock, flags);
 
 	if (cmdinfo->data_in_urb == urb) {
-		sdb = scsi_in(cmnd);
 		cmdinfo->state &= ~DATA_IN_URB_INFLIGHT;
 		cmdinfo->data_in_urb = NULL;
 	} else if (cmdinfo->data_out_urb == urb) {
-		sdb = scsi_out(cmnd);
 		cmdinfo->state &= ~DATA_OUT_URB_INFLIGHT;
 		cmdinfo->data_out_urb = NULL;
 	}
-	if (sdb == NULL) {
-		WARN_ON_ONCE(1);
-		goto out;
-	}
 
 	if (devinfo->resetting)
 		goto out;
@@ -426,8 +420,7 @@ static struct urb *uas_alloc_data_urb(struct uas_dev_info *devinfo, gfp_t gfp,
 	struct usb_device *udev = devinfo->udev;
 	struct uas_cmd_info *cmdinfo = (void *)&cmnd->SCp;
 	struct urb *urb = usb_alloc_urb(0, gfp);
-	struct scsi_data_buffer *sdb = (dir == DMA_FROM_DEVICE)
-		? scsi_in(cmnd) : scsi_out(cmnd);
+	struct scsi_data_buffer *sdb = &cmnd->sdb;
 	unsigned int pipe = (dir == DMA_FROM_DEVICE)
 		? devinfo->data_in_pipe : devinfo->data_out_pipe;
 
include/scsi/scsi_cmnd.h +1 -18
index d6fd2aba0380..71e08cfc9916 100644
@@ -209,23 +209,6 @@ static inline int scsi_get_resid(struct scsi_cmnd *cmd)
 #define scsi_for_each_sg(cmd, sg, nseg, __i)			\
 	for_each_sg(scsi_sglist(cmd), sg, nseg, __i)
 
-static inline int scsi_bidi_cmnd(struct scsi_cmnd *cmd)
-{
-	return blk_bidi_rq(cmd->request) &&
-		(cmd->request->next_rq->special != NULL);
-}
-
-static inline struct scsi_data_buffer *scsi_in(struct scsi_cmnd *cmd)
-{
-	return scsi_bidi_cmnd(cmd) ?
-		cmd->request->next_rq->special : &cmd->sdb;
-}
-
-static inline struct scsi_data_buffer *scsi_out(struct scsi_cmnd *cmd)
-{
-	return &cmd->sdb;
-}
-
 static inline int scsi_sg_copy_from_buffer(struct scsi_cmnd *cmd,
 					   void *buf, int buflen)
 {
@@ -347,7 +330,7 @@ static inline void set_driver_byte(struct scsi_cmnd *cmd, char status)
 
 static inline unsigned scsi_transfer_length(struct scsi_cmnd *scmd)
 {
-	unsigned int xfer_len = scsi_out(scmd)->length;
+	unsigned int xfer_len = scmd->sdb.length;
 	unsigned int prot_interval = scsi_prot_interval(scmd);
 
 	if (scmd->prot_flags & SCSI_PROT_TRANSFER_PI)
include/scsi/scsi_eh.h +0 -1
index 2b7e227960e1..3810b340551c 100644
@@ -39,7 +39,6 @@ struct scsi_eh_save {
 	unsigned char prot_op;
 	unsigned char *cmnd;
 	struct scsi_data_buffer sdb;
-	struct request *next_rq;
 	/* new command support */
 	unsigned char eh_cmnd[BLK_MAX_CDB];
 	struct scatterlist sense_sgl;
Signature · 1 line
2.19.1
#4 lore raw

PATCH 4/8 scsi: stop setting up request->special

In reply to Christoph Hellwig

No more need in a blk-mq world where the scsi command and request are allocated together.

---
 drivers/scsi/qedf/qedf_io.c | 6 ------
 drivers/scsi/qedi/qedi_fw.c | 7 -------
 drivers/scsi/scsi_lib.c     | 3 ---
 drivers/scsi/sd.c           | 1 -
 drivers/scsi/sr.c           | 1 -
 5 files changed, 18 deletions(-)
drivers/scsi/qedf/qedf_io.c +0 -6
index 6bbc38b1b465..6ca583bdde23 100644
@@ -1128,12 +1128,6 @@ void qedf_scsi_completion(struct qedf_ctx *qedf, struct fcoe_cqe *cqe,
 		return;
 	}
 
-	if (!sc_cmd->request->special) {
-		QEDF_WARN(&(qedf->dbg_ctx), "request->special is NULL so "
-		    "request not valid, sc_cmd=%p.\n", sc_cmd);
-		return;
-	}
-
 	if (!sc_cmd->request->q) {
 		QEDF_WARN(&(qedf->dbg_ctx), "request->q is NULL so request "
 		   "is not valid, sc_cmd=%p.\n", sc_cmd);
drivers/scsi/qedi/qedi_fw.c +0 -7
index 25d763ae5d5a..e2a995a6e8e7 100644
@@ -616,13 +616,6 @@ static void qedi_scsi_completion(struct qedi_ctx *qedi,
 		goto error;
 	}
 
-	if (!sc_cmd->request->special) {
-		QEDI_WARN(&qedi->dbg_ctx,
-			  "request->special is NULL so request not valid, sc_cmd=%p.\n",
-			  sc_cmd);
-		goto error;
-	}
-
 	if (!sc_cmd->request->q) {
 		QEDI_WARN(&qedi->dbg_ctx,
 			  "request->q is NULL so request is not valid, sc_cmd=%p.\n",
drivers/scsi/scsi_lib.c +0 -3
index 369c15a701f1..d65f838af6eb 100644
@@ -1561,10 +1561,7 @@ static blk_status_t scsi_mq_prep_fn(struct request *req)
 
 	scsi_init_command(sdev, cmd);
 
-	req->special = cmd;
-
 	cmd->request = req;
-
 	cmd->tag = req->tag;
 	cmd->prot_op = SCSI_PROT_NORMAL;
 
drivers/scsi/sd.c +0 -1
index 4a6ed2fc8c71..96e906e438d2 100644
@@ -1026,7 +1026,6 @@ static blk_status_t sd_setup_read_write_cmnd(struct scsi_cmnd *SCpnt)
 	ret = scsi_init_io(SCpnt);
 	if (ret != BLK_STS_OK)
 		return ret;
-	WARN_ON_ONCE(SCpnt != rq->special);
 
 	SCSI_LOG_HLQUEUE(1,
 		scmd_printk(KERN_INFO, SCpnt,
drivers/scsi/sr.c +0 -1
index 38ddbbfe5f3c..039c27c2d7b3 100644
@@ -394,7 +394,6 @@ static blk_status_t sr_init_command(struct scsi_cmnd *SCpnt)
 	ret = scsi_init_io(SCpnt);
 	if (ret != BLK_STS_OK)
 		goto out;
-	WARN_ON_ONCE(SCpnt != rq->special);
 	cd = scsi_cd(rq->rq_disk);
 
 	/* from here on until we're complete, any goto out
Signature · 1 line
2.19.1
#5 lore raw

PATCH 5/8 bsg: refactor bsg_ioctl

In reply to Christoph Hellwig

Move all actual functionality into helpers, just leaving the dispatch in this function.

---
 block/bsg.c | 158 ++++++++++++++++++++++++----------------------------
 1 file changed, 72 insertions(+), 86 deletions(-)
block/bsg.c +72 -86
index 9a442c23a715..8bf3af9543d0 100644
@@ -138,32 +138,35 @@ static const struct bsg_ops bsg_scsi_ops = {
 	.free_rq		= bsg_scsi_free_rq,
 };
 
-static struct request *
-bsg_map_hdr(struct request_queue *q, struct sg_io_v4 *hdr, fmode_t mode)
+static int bsg_sg_io(struct request_queue *q, fmode_t mode, void __user *uarg)
 {
 	struct request *rq, *next_rq = NULL;
+	struct bio *bio, *bidi_bio = NULL;
+	struct sg_io_v4 hdr;
 	int ret;
 
-	if (!q->bsg_dev.class_dev)
-		return ERR_PTR(-ENXIO);
+	if (copy_from_user(&hdr, uarg, sizeof(hdr)))
+		return -EFAULT;
 
-	if (hdr->guard != 'Q')
-		return ERR_PTR(-EINVAL);
+	if (!q->bsg_dev.class_dev)
+		return -ENXIO;
 
-	ret = q->bsg_dev.ops->check_proto(hdr);
+	if (hdr.guard != 'Q')
+		return -EINVAL;
+	ret = q->bsg_dev.ops->check_proto(&hdr);
 	if (ret)
-		return ERR_PTR(ret);
+		return ret;
 
-	rq = blk_get_request(q, hdr->dout_xfer_len ?
+	rq = blk_get_request(q, hdr.dout_xfer_len ?
 			REQ_OP_SCSI_OUT : REQ_OP_SCSI_IN, 0);
 	if (IS_ERR(rq))
-		return rq;
+		return PTR_ERR(rq);
 
-	ret = q->bsg_dev.ops->fill_hdr(rq, hdr, mode);
+	ret = q->bsg_dev.ops->fill_hdr(rq, &hdr, mode);
 	if (ret)
 		goto out;
 
-	rq->timeout = msecs_to_jiffies(hdr->timeout);
+	rq->timeout = msecs_to_jiffies(hdr.timeout);
 	if (!rq->timeout)
 		rq->timeout = q->sg_timeout;
 	if (!rq->timeout)
@@ -171,7 +174,7 @@ bsg_map_hdr(struct request_queue *q, struct sg_io_v4 *hdr, fmode_t mode)
 	if (rq->timeout < BLK_MIN_SG_TIMEOUT)
 		rq->timeout = BLK_MIN_SG_TIMEOUT;
 
-	if (hdr->dout_xfer_len && hdr->din_xfer_len) {
+	if (hdr.dout_xfer_len && hdr.din_xfer_len) {
 		if (!test_bit(QUEUE_FLAG_BIDI, &q->queue_flags)) {
 			ret = -EOPNOTSUPP;
 			goto out;
@@ -184,42 +187,29 @@ bsg_map_hdr(struct request_queue *q, struct sg_io_v4 *hdr, fmode_t mode)
 		}
 
 		rq->next_rq = next_rq;
-		ret = blk_rq_map_user(q, next_rq, NULL, uptr64(hdr->din_xferp),
-				       hdr->din_xfer_len, GFP_KERNEL);
+		ret = blk_rq_map_user(q, next_rq, NULL, uptr64(hdr.din_xferp),
+				       hdr.din_xfer_len, GFP_KERNEL);
 		if (ret)
 			goto out_free_nextrq;
 	}
 
-	if (hdr->dout_xfer_len) {
-		ret = blk_rq_map_user(q, rq, NULL, uptr64(hdr->dout_xferp),
-				hdr->dout_xfer_len, GFP_KERNEL);
-	} else if (hdr->din_xfer_len) {
-		ret = blk_rq_map_user(q, rq, NULL, uptr64(hdr->din_xferp),
-				hdr->din_xfer_len, GFP_KERNEL);
+	if (hdr.dout_xfer_len) {
+		ret = blk_rq_map_user(q, rq, NULL, uptr64(hdr.dout_xferp),
+				hdr.dout_xfer_len, GFP_KERNEL);
+	} else if (hdr.din_xfer_len) {
+		ret = blk_rq_map_user(q, rq, NULL, uptr64(hdr.din_xferp),
+				hdr.din_xfer_len, GFP_KERNEL);
 	}
 
 	if (ret)
 		goto out_unmap_nextrq;
-	return rq;
 
-out_unmap_nextrq:
+	bio = rq->bio;
 	if (rq->next_rq)
-		blk_rq_unmap_user(rq->next_rq->bio);
-out_free_nextrq:
-	if (rq->next_rq)
-		blk_put_request(rq->next_rq);
-out:
-	q->bsg_dev.ops->free_rq(rq);
-	blk_put_request(rq);
-	return ERR_PTR(ret);
-}
-
-static int blk_complete_sgv4_hdr_rq(struct request *rq, struct sg_io_v4 *hdr,
-				    struct bio *bio, struct bio *bidi_bio)
-{
-	int ret;
+		bidi_bio = rq->next_rq->bio;
 
-	ret = rq->q->bsg_dev.ops->complete_rq(rq, hdr);
+	blk_execute_rq(q, NULL, rq, !(hdr.flags & BSG_FLAG_Q_AT_TAIL));
+	ret = rq->q->bsg_dev.ops->complete_rq(rq, &hdr);
 
 	if (rq->next_rq) {
 		blk_rq_unmap_user(bidi_bio);
@@ -229,6 +219,20 @@ static int blk_complete_sgv4_hdr_rq(struct request *rq, struct sg_io_v4 *hdr,
 	blk_rq_unmap_user(bio);
 	rq->q->bsg_dev.ops->free_rq(rq);
 	blk_put_request(rq);
+
+	if (copy_to_user(uarg, &hdr, sizeof(hdr)))
+		return -EFAULT;
+	return ret;
+
+out_unmap_nextrq:
+	if (rq->next_rq)
+		blk_rq_unmap_user(rq->next_rq->bio);
+out_free_nextrq:
+	if (rq->next_rq)
+		blk_put_request(rq->next_rq);
+out:
+	q->bsg_dev.ops->free_rq(rq);
+	blk_put_request(rq);
 	return ret;
 }
 
@@ -363,31 +367,39 @@ static int bsg_release(struct inode *inode, struct file *file)
 	return bsg_put_device(bd);
 }
 
+static int bsg_get_command_q(struct bsg_device *bd, int __user *uarg)
+{
+	return put_user(bd->max_queue, uarg);
+}
+
+static int bsg_set_command_q(struct bsg_device *bd, int __user *uarg)
+{
+	int queue;
+
+	if (get_user(queue, uarg))
+		return -EFAULT;
+	if (queue < 1)
+		return -EINVAL;
+
+	spin_lock_irq(&bd->lock);
+	bd->max_queue = queue;
+	spin_unlock_irq(&bd->lock);
+	return 0;
+}
+
 static long bsg_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
 {
 	struct bsg_device *bd = file->private_data;
-	int __user *uarg = (int __user *) arg;
-	int ret;
+	void __user *uarg = (void __user *) arg;
 
 	switch (cmd) {
-		/*
-		 * our own ioctls
-		 */
+	/*
+	 * Our own ioctls
+	 */
 	case SG_GET_COMMAND_Q:
-		return put_user(bd->max_queue, uarg);
-	case SG_SET_COMMAND_Q: {
-		int queue;
-
-		if (get_user(queue, uarg))
-			return -EFAULT;
-		if (queue < 1)
-			return -EINVAL;
-
-		spin_lock_irq(&bd->lock);
-		bd->max_queue = queue;
-		spin_unlock_irq(&bd->lock);
-		return 0;
-	}
+		return bsg_get_command_q(bd, uarg);
+	case SG_SET_COMMAND_Q:
+		return bsg_set_command_q(bd, uarg);
 
 	/*
 	 * SCSI/sg ioctls
@@ -400,36 +412,10 @@ static long bsg_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
 	case SG_GET_RESERVED_SIZE:
 	case SG_SET_RESERVED_SIZE:
 	case SG_EMULATED_HOST:
-	case SCSI_IOCTL_SEND_COMMAND: {
-		void __user *uarg = (void __user *) arg;
+	case SCSI_IOCTL_SEND_COMMAND:
 		return scsi_cmd_ioctl(bd->queue, NULL, file->f_mode, cmd, uarg);
-	}
-	case SG_IO: {
-		struct request *rq;
-		struct bio *bio, *bidi_bio = NULL;
-		struct sg_io_v4 hdr;
-		int at_head;
-
-		if (copy_from_user(&hdr, uarg, sizeof(hdr)))
-			return -EFAULT;
-
-		rq = bsg_map_hdr(bd->queue, &hdr, file->f_mode);
-		if (IS_ERR(rq))
-			return PTR_ERR(rq);
-
-		bio = rq->bio;
-		if (rq->next_rq)
-			bidi_bio = rq->next_rq->bio;
-
-		at_head = (0 == (hdr.flags & BSG_FLAG_Q_AT_TAIL));
-		blk_execute_rq(bd->queue, NULL, rq, at_head);
-		ret = blk_complete_sgv4_hdr_rq(rq, &hdr, bio, bidi_bio);
-
-		if (copy_to_user(uarg, &hdr, sizeof(hdr)))
-			return -EFAULT;
-
-		return ret;
-	}
+	case SG_IO:
+		return bsg_sg_io(bd->queue, file->f_mode, uarg);
 	default:
 		return -ENOTTY;
 	}
Signature · 1 line
2.19.1
Reviewed-by Tested-by on v1 5/8
#6 lore raw

Re: [PATCH 5/8] bsg: refactor bsg_ioctl

Quoted 8 lines · Christoph Hellwig

Move all actual functionality into helpers, just leaving the dispatch in this function.

---
 block/bsg.c | 158 ++++++++++++++++++++++++----------------------------
 1 file changed, 72 insertions(+), 86 deletions(-)

Looks fine to me. Did ran the same small test-tool I ran against Jens' patches, nothing broke.

Signature · 4 lines
With Best Regards, Benjamin Block      /      Linux on IBM Z Kernel Development
IBM Systems & Technology Group   /  IBM Deutschland Research & Development GmbH
Vorsitz. AufsR.: Martina Koederitz       /      Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: AmtsG Stuttgart, HRB 243294
Tested-by
#7 lore raw

RE: [PATCH 5/8] bsg: refactor bsg_ioctl

Quoted 13 lines · Christoph Hellwig
Quoted 8 lines

Move all actual functionality into helpers, just leaving the dispatch in this function.

---
 block/bsg.c | 158 ++++++++++++++++++++++++----------------------------
 1 file changed, 72 insertions(+), 86 deletions(-)
Quoted 5 lines

Looks fine to me. Did ran the same small test-tool I ran against Jens' patches, nothing broke.

Tested the scsi pass-through (ufs-bsg) path - nothing is broken.

#8 lore raw

PATCH 6/8 bsg-lib: handle bidi requests without block layer help

In reply to Christoph Hellwig

We can just stash away the second request in struct bsg_job instead of using the block layer req->next_rq field, allowing for the eventual removal of the latter.

---
 block/bsg-lib.c                   | 44 +++++++++++++++++++---
 block/bsg.c                       | 62 ++++++-------------------------
 drivers/scsi/scsi_transport_sas.c |  1 -
 include/linux/bsg-lib.h           |  4 ++
 4 files changed, 54 insertions(+), 57 deletions(-)
block/bsg-lib.c +38 -6
index 192129856342..005e2b75d775 100644
@@ -51,11 +51,40 @@ static int bsg_transport_fill_hdr(struct request *rq, struct sg_io_v4 *hdr,
 		fmode_t mode)
 {
 	struct bsg_job *job = blk_mq_rq_to_pdu(rq);
+	int ret;
 
 	job->request_len = hdr->request_len;
 	job->request = memdup_user(uptr64(hdr->request), hdr->request_len);
+	if (IS_ERR(job->request))
+		return PTR_ERR(job->request);
+
+	if (hdr->dout_xfer_len && hdr->din_xfer_len) {
+		job->bidi_rq = blk_get_request(rq->q, REQ_OP_SCSI_IN, 0);
+		if (IS_ERR(job->bidi_rq)) {
+			ret = PTR_ERR(job->bidi_rq);
+			goto out;
+		}
+
+		ret = blk_rq_map_user(rq->q, job->bidi_rq, NULL,
+				uptr64(hdr->din_xferp), hdr->din_xfer_len,
+				GFP_KERNEL);
+		if (ret)
+			goto out_free_bidi_rq;
+
+		job->bidi_bio = job->bidi_rq->bio;
+	} else {
+		job->bidi_rq = NULL;
+		job->bidi_bio = NULL;
+	}
 
-	return PTR_ERR_OR_ZERO(job->request);
+	return 0;
+
+out_free_bidi_rq:
+	if (job->bidi_rq)
+		blk_put_request(job->bidi_rq);
+out:
+	kfree(job->request);
+	return ret;
 }
 
 static int bsg_transport_complete_rq(struct request *rq, struct sg_io_v4 *hdr)
@@ -93,7 +122,7 @@ static int bsg_transport_complete_rq(struct request *rq, struct sg_io_v4 *hdr)
 	/* we assume all request payload was transferred, residual == 0 */
 	hdr->dout_resid = 0;
 
-	if (rq->next_rq) {
+	if (job->bidi_rq) {
 		unsigned int rsp_len = job->reply_payload.payload_len;
 
 		if (WARN_ON(job->reply_payload_rcv_len > rsp_len))
@@ -111,6 +140,11 @@ static void bsg_transport_free_rq(struct request *rq)
 {
 	struct bsg_job *job = blk_mq_rq_to_pdu(rq);
 
+	if (job->bidi_rq) {
+		blk_rq_unmap_user(job->bidi_bio);
+		blk_put_request(job->bidi_rq);
+	}
+
 	kfree(job->request);
 }
 
@@ -200,7 +234,6 @@ static int bsg_map_buffer(struct bsg_buffer *buf, struct request *req)
  */
 static bool bsg_prepare_job(struct device *dev, struct request *req)
 {
-	struct request *rsp = req->next_rq;
 	struct bsg_job *job = blk_mq_rq_to_pdu(req);
 	int ret;
 
@@ -211,8 +244,8 @@ static bool bsg_prepare_job(struct device *dev, struct request *req)
 		if (ret)
 			goto failjob_rls_job;
 	}
-	if (rsp && rsp->bio) {
-		ret = bsg_map_buffer(&job->reply_payload, rsp);
+	if (job->bidi_rq) {
+		ret = bsg_map_buffer(&job->reply_payload, job->bidi_rq);
 		if (ret)
 			goto failjob_rls_rqst_payload;
 	}
@@ -369,7 +402,6 @@ struct request_queue *bsg_setup_queue(struct device *dev, const char *name,
 	}
 
 	q->queuedata = dev;
-	blk_queue_flag_set(QUEUE_FLAG_BIDI, q);
 	blk_queue_rq_timeout(q, BLK_DEFAULT_SG_TIMEOUT);
 
 	ret = bsg_register_queue(q, dev, name, &bsg_transport_ops);
block/bsg.c +12 -50

110 lines not on this page · raw message

drivers/scsi/scsi_transport_sas.c +0 -1
index 692b46937e52..60f1a81d2034 100644
@@ -213,7 +213,6 @@ static int sas_bsg_initialize(struct Scsi_Host *shost, struct sas_rphy *rphy)
 		to_sas_host_attrs(shost)->q = q;
 	}
 
-	blk_queue_flag_set(QUEUE_FLAG_BIDI, q);
 	return 0;
 }
 
include/linux/bsg-lib.h +4 -0
index b356e0006731..7f14517a559b 100644
@@ -69,6 +69,10 @@ struct bsg_job {
 	int result;
 	unsigned int reply_payload_rcv_len;
 
+	/* BIDI support */
+	struct request *bidi_rq;
+	struct bio *bidi_bio;
+
 	void *dd_data;		/* Used for driver-specific storage */
 };
 
Signature · 1 line
2.19.1
#9 lore raw

Re: [PATCH 6/8] bsg-lib: handle bidi requests without block layer help

Quoted 17 lines · Christoph Hellwig

We can just stash away the second request in struct bsg_job instead of using the block layer req->next_rq field, allowing for the eventual removal of the latter.

---
 block/bsg-lib.c                   | 44 +++++++++++++++++++---
 block/bsg.c                       | 62 ++++++-------------------------
 drivers/scsi/scsi_transport_sas.c |  1 -
 include/linux/bsg-lib.h           |  4 ++
 4 files changed, 54 insertions(+), 57 deletions(-)
block/bsg-lib.c +0 -0
index 192129856342..005e2b75d775 100644

block/bsg-lib.c static int bsg_scsi_fill_hdr(struct request *rq, struct sg_io_v4 *hdr, · line 79

Quoted 6 lines
block/bsg-lib.c +3 -0
@@ -74,6 +74,9 @@ static int bsg_scsi_fill_hdr(struct request *rq, struct sg_io_v4 *hdr,
 {
 	struct scsi_request *sreq = scsi_req(rq);
 
+	if (hdr->dout_xfer_len && hdr->din_xfer_len)
+		return -EOPNOTSUPP;
+

This seems like a non-obvious user-breakage. So apart from removing the in-kernel stuff that uses bidirectional commands you also forbid userspace from every using them? That seems wrong to me.

There is other SCSI Command Sets than OSD that provide bidirectional commands, even SBC has some (i.e. X*WRITE*, COMPARE AND WRITE).

Signature · 4 lines
With Best Regards, Benjamin Block      /      Linux on IBM Z Kernel Development
IBM Systems & Technology Group   /  IBM Deutschland Research & Development GmbH
Vorsitz. AufsR.: Martina Koederitz       /      Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: AmtsG Stuttgart, HRB 243294
#10 lore raw

Re: [PATCH 6/8] bsg-lib: handle bidi requests without block layer help

Quoted 6 lines · Benjamin Block

This seems like a non-obvious user-breakage. So apart from removing the in-kernel stuff that uses bidirectional commands you also forbid userspace from every using them? That seems wrong to me.

There is other SCSI Command Sets than OSD that provide bidirectional commands, even SBC has some (i.e. X*WRITE*, COMPARE AND WRITE).

Yes, there are a few. But the only driver that even supports them right now is iscsi_tcp to start with, and we have to drag a significant amount of code around just to support this corner case.

#11 lore raw

Re: [PATCH 6/8] bsg-lib: handle bidi requests without block layer help

Quoted 5 lines · Christoph Hellwig
Quoted 4 lines · Benjamin Block

This seems like a non-obvious user-breakage. So apart from removing the in-kernel stuff that uses bidirectional commands you also forbid userspace from every using them? That seems wrong to me.

Quoted 7 lines
Quoted 2 lines

There is other SCSI Command Sets than OSD that provide bidirectional commands, even SBC has some (i.e. X*WRITE*, COMPARE AND WRITE).

Yes, there are a few. But the only driver that even supports them right now is iscsi_tcp to start with, and we have to drag a significant amount of code around just to support this corner case.

But we are not talking about kernel-support here, this interface is user-facing, and for an interfaces that was made so people could send arbitrary SCSI commands, that the kernel doesn't support.

Its probably also more complicated to make sure that no one is using that, in contrast to the OSD stuff that - as state in the patch-letter - never made it out of academia. Its not like anyone has to release anything open if they use BSG/SG, its just syscalls after all.

Signature · 4 lines
With Best Regards, Benjamin Block      /      Linux on IBM Z Kernel Development
IBM Systems & Technology Group   /  IBM Deutschland Research & Development GmbH
Vorsitz. AufsR.: Martina Koederitz       /      Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: AmtsG Stuttgart, HRB 243294
Tested-by on v1 6/8
#12 lore raw

RE: [PATCH 6/8] bsg-lib: handle bidi requests without block layer help

In reply to Christoph Hellwig
Quoted 12 lines

-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of Christoph Hellwig
Sent: Sunday, November 11, 2018 3:32 PM
To: [email protected]; [email protected]; [email protected]
Cc: Johannes Thumshirn <[email protected]>; Benjamin Block <[email protected]>; [email protected]; linux- [email protected]; [email protected]
Subject: [PATCH 6/8] bsg-lib: handle bidi requests without block layer help

Quoted 5 lines

We can just stash away the second request in struct bsg_job instead of using the block layer req->next_rq field, allowing for the eventual removal of the latter.

Regardless of the ongoing discussion with Benjamin - Tested the scsi pass-through (ufs-bsg) path - nothing is broken.

#13 lore raw

PATCH 7/8 block: remove req->special

In reply to Christoph Hellwig

No users left.

---
 block/blk-mq.c         | 1 -
 include/linux/blkdev.h | 2 --
 2 files changed, 3 deletions(-)
block/blk-mq.c +0 -1
index 411be60d0cb6..c1bb0c0b2ad8 100644
@@ -322,7 +322,6 @@ static struct request *blk_mq_rq_ctx_init(struct blk_mq_alloc_data *data,
 #if defined(CONFIG_BLK_DEV_INTEGRITY)
 	rq->nr_integrity_segments = 0;
 #endif
-	rq->special = NULL;
 	/* tag was already set */
 	rq->extra_len = 0;
 	rq->__deadline = 0;
include/linux/blkdev.h +0 -2
index e67ad2dd025e..adafeb1e0c2b 100644
@@ -216,8 +216,6 @@ struct request {
 	unsigned short write_hint;
 	unsigned short ioprio;
 
-	void *special;		/* opaque pointer available for LLD use */
-
 	unsigned int extra_len;	/* length of alignment and padding */
 
 	enum mq_rq_state state;
Signature · 1 line
2.19.1
#14 lore raw

PATCH 8/8 block: remove bidi support

In reply to Christoph Hellwig

Unused now, and another field in struct request bites the dust.

---
 block/blk-mq-debugfs.c | 1 -
 block/blk-mq.c         | 3 ---
 include/linux/blkdev.h | 6 ------
 3 files changed, 10 deletions(-)
block/blk-mq-debugfs.c +0 -1
index f021f4817b80..82f5e836fe30 100644
@@ -115,7 +115,6 @@ static const char *const blk_queue_flag_name[] = {
 	QUEUE_FLAG_NAME(STOPPED),
 	QUEUE_FLAG_NAME(DYING),
 	QUEUE_FLAG_NAME(BYPASS),
-	QUEUE_FLAG_NAME(BIDI),
 	QUEUE_FLAG_NAME(NOMERGES),
 	QUEUE_FLAG_NAME(SAME_COMP),
 	QUEUE_FLAG_NAME(FAIL_IO),
block/blk-mq.c +0 -3
index c1bb0c0b2ad8..95c858b9309e 100644
@@ -330,7 +330,6 @@ static struct request *blk_mq_rq_ctx_init(struct blk_mq_alloc_data *data,
 
 	rq->end_io = NULL;
 	rq->end_io_data = NULL;
-	rq->next_rq = NULL;
 
 	data->ctx->rq_dispatched[op_is_sync(op)]++;
 	refcount_set(&rq->ref, 1);
@@ -537,8 +536,6 @@ inline void __blk_mq_end_request(struct request *rq, blk_status_t error)
 		rq_qos_done(rq->q, rq);
 		rq->end_io(rq, error);
 	} else {
-		if (unlikely(blk_bidi_rq(rq)))
-			blk_mq_free_request(rq->next_rq);
 		blk_mq_free_request(rq);
 	}
 }
include/linux/blkdev.h +0 -6
index adafeb1e0c2b..944157e78f06 100644
@@ -236,9 +236,6 @@ struct request {
 	 */
 	rq_end_io_fn *end_io;
 	void *end_io_data;
-
-	/* for bidi */
-	struct request *next_rq;
 };
 
 static inline bool blk_op_is_scsi(unsigned int op)
@@ -588,7 +585,6 @@ struct request_queue {
 #define QUEUE_FLAG_STOPPED	1	/* queue is stopped */
 #define QUEUE_FLAG_DYING	2	/* queue being torn down */
 #define QUEUE_FLAG_BYPASS	3	/* act as dumb FIFO queue */
-#define QUEUE_FLAG_BIDI		4	/* queue supports bidi requests */
 #define QUEUE_FLAG_NOMERGES     5	/* disable merge attempts */
 #define QUEUE_FLAG_SAME_COMP	6	/* complete on same CPU-group */
 #define QUEUE_FLAG_FAIL_IO	7	/* fake timeout */
@@ -663,8 +659,6 @@ static inline bool blk_account_rq(struct request *rq)
 	return (rq->rq_flags & RQF_STARTED) && !blk_rq_is_passthrough(rq);
 }
 
-#define blk_bidi_rq(rq)		((rq)->next_rq != NULL)
-
 #define list_entry_rq(ptr)	list_entry((ptr), struct request, queuelist)
 
 #define rq_data_dir(rq)		(op_is_write(req_op(rq)) ? WRITE : READ)
Signature · 1 line
2.19.1
#15 lore raw
In reply to Christoph Hellwig
Quoted 15 lines · Christoph Hellwig

The only real user of the T10 OSD protocol, the pNFS object layout driver never went to the point of having shipping products, and we removed it 1.5 years ago. Exofs is just a simple example without real life users.

The code has been mostly unmaintained for years and is getting in the way of block / SCSI changes, so I think it's finally time to drop it.

Quote from Boaz:

"As I said then. It is used in Universities for studies and experiments. Every once in a while. I get an email with questions and reports.

But yes feel free to remove the all thing!!

Quoted 7 lines

I guess I can put it up on github. In a public tree.

Just that I will need to forward port it myself, til now you guys been doing this for me ;-)"

Now the last time this caused a bit of a stir, but still no actual users, not even for SG_IO passthrough commands.

What?? Do any Linux distros track what commands are sent to any (or all) of the SG_IO passthroughs? I would hope that the last part of that sentence remains unprovable.

Doug Gilbert

"I've told you a million times, don't exaggerate!"

#16 lore raw
In reply to Christoph Hellwig
Quoted 5 lines · Christoph Hellwig

The only real user of the T10 OSD protocol, the pNFS object layout driver never went to the point of having shipping products, and we removed it 1.5 years ago. Exofs is just a simple example without real life users.

You have failed to say what is your motivation for this patchset? What is it you are trying to fix/improve.

For the sake of "not used much" I fail to see the risk taking of this removal.

Quoted 8 lines

The code has been mostly unmaintained for years and is getting in the way of block / SCSI changes, so I think it's finally time to drop it.

Quote from Boaz:

"As I said then. It is used in Universities for studies and experiments. Every once in a while. I get an email with questions and reports.

Quoted 7 lines

But yes feel free to remove the all thing!!

I guess I can put it up on github. In a public tree.

Just that I will need to forward port it myself, til now you guys been doing this for me ;-)"

Yes I wrote that for V1. But I wrote the *opposite* thing in a later mail. Which nullifies this statement above. So please remove this quote in future submits.

Here is what I wrote later as response of V2 of this set:

<Re: remove exofs and the T10 OSD code V2>

I think I'm changing my mind about this.

Because of two reasons:

One: I see 3 thousands bit-rots in the Kernel and particularly SCSI drivers that are much older and fat-and-ugliness consuming then the clean osd stack. For example the all ISA bus and ZONE_DMA stuff.

Two: I have offered many times, every time this came up. That if anyone has a major (or even minor) change to the block and/or scsi layers that he/she has done. And that now breaks the compilation/run time of OSD or exofs.
I'm personally willing to spend my weekends and fix it myself. Send me a URL of the tree with the work done, and I will send the patches needed to revitalize OSD/exofs as part of that change set.

I have never received any such requests to date.

So I would please like to protest on two of Christoph's statements above.

"The code has been mostly unmaintained for years and is getting in the
way of block / SCSI changes"

1. What does "maintained" means? I have for all these years been immediately responsive to any inquiries and patches to the code in question. And am listed as MAINTAINER of this code.
2. I have regularly, for ever, every kernel release around the RC3-RC4 time frame, compiled and ran my almost automatic setup and made sure the things still run as expected (No regressions).

So Yes the code has not seen any new fixtures for years. But it is regularly tested and proven to work, on latest kernel. So it fails the definition of a "bit rot"

Christoph you've been saying for so long "getting in the way of block/SCSI changes". And every time and again this time please tell me, you never answered before. What are these changes you want to make? can I please help?

Send me any tree where exofs/osd compilation is broken and I will personally fix it in "ONE WEEK" time.

(If compilation is fine but you know runtime will break, its nice to have an
heads up, but if not my automatic system will detect it anyway)

Lets say that if in the FUTURE a change-set is submitted that breaks OSD/EXOFS compilation, and I failed to respond with a fix within "ONE WEEK". Then this goes in as part of that change-set. And not with the argument of "Not used, not maintained" - But as "Breaks compilation of the following changes" I promise I will gladly ACK it then.

So for now. A personal NACK from me on the grounds that. You never told me why / what this is breaking.

Thanks
Boaz

</Re: remove exofs and the T10 OSD code V2>

Quoted 5 lines

Now the last time this caused a bit of a stir, but still no actual users, not even for SG_IO passthrough commands. So here we go again, this time including removing everything in the scsi and block layer supporting it, and thus shrinking struct request.

Again. T10-OSD or not. Bidi is currently actively used. By Linus rules You are not allowed to remove it.

Two use paths:
1. Management CDBS of private vendors yes via iscsi. virt_io and usb-scsi
2. Target mode support of WRITE-RETURN-XOR, and COMPARE_AND_WRITE

---
You guys should do what you feel best. Even not answering my questions and of course not agreeing with my advise, .i.e about breaking people's setups.

But please remove the wrong quote from me. Please quote my objection of the matter. (pretty please because you may surly ignore that request as well)

[I am not fighting about this at all. Please do what you need to do.
Just want to set the record strait that's all]

Cheers :-)
Boaz

#17 lore raw
Quoted 9 lines · Boaz Harrosh
Quoted 5 lines · Christoph Hellwig

The only real user of the T10 OSD protocol, the pNFS object layout driver never went to the point of having shipping products, and we removed it 1.5 years ago. Exofs is just a simple example without real life users.

You have failed to say what is your motivation for this patchset? What is it you are trying to fix/improve.

Drop basically unused support, which allows us to

1) reduce the size of every kernel with block layer support, and even more for every kernel with scsi support
2) reduce the size of the critical struct request structure by 128 bits, thus reducing the memory used by every blk-mq driver significantly, never mind the cache effects
3) stop having the maintainance overhead for this code in the block layer, which has been rather painful at times

#18 lore raw
Quoted 8 lines · Christoph Hellwig
Quoted 7 lines · Boaz Harrosh
Quoted 5 lines · Christoph Hellwig

The only real user of the T10 OSD protocol, the pNFS object layout driver never went to the point of having shipping products, and we removed it 1.5 years ago. Exofs is just a simple example without real life users.

Quoted 7 lines
Quoted 2 lines

You have failed to say what is your motivation for this patchset? What is it you are trying to fix/improve.

Drop basically unused support, which allows us to

1) reduce the size of every kernel with block layer support, and even more for every kernel with scsi support

By proposing the removal of bidi support from the block layer, it isn't just the SCSI subsystem that will be impacted. Those NVMe documents that you referred me to earlier in the year, in the command tables in 1.3c and earlier you have noticed the 2 bit direction field and what 11b means? Even if there aren't any bidi NVMe commands *** yet, the fact that NVMe's 64 byte command format has provision for 4 (not 2) independent data transfers (data + meta, for each direction). Surely NVMe will sooner or later take advantage of those ... a command like READ GATHERED comes to mind.

Quoted 3 lines

2) reduce the size of the critical struct request structure by 128 bits, thus reducing the memory used by every blk-mq driver significantly, never mind the cache effects

Hmm, one pointer (that is null in the non-bidi case) should be enough, that's 64 or 32 bits.

Quoted 2 lines

3) stop having the maintainance overhead for this code in the block layer, which has been rather painful at times

You won't get any sympathy from me :-) The sg driver is trying to inject _SCSI_ commands into the SCSI mid-level for onward processing by SCSI LLDs. So WTF does it have to deal with the block layer.

While on the subject of bidi, the order of transfers: is the data-out (to the target) always before the data-in or is it the target device that decides (depending on the semantics of the command) who is first?

Doug Gilbert

*** there could already be vendor specific bidi NVMe commands out
there (ditto for SCSI)

#19 lore raw
Quoted 12 lines · Douglas Gilbert
Quoted 2 lines

1) reduce the size of every kernel with block layer support, and even more for every kernel with scsi support

By proposing the removal of bidi support from the block layer, it isn't just the SCSI subsystem that will be impacted. Those NVMe documents that you referred me to earlier in the year, in the command tables in 1.3c and earlier you have noticed the 2 bit direction field and what 11b means? Even if there aren't any bidi NVMe commands *** yet, the fact that NVMe's 64 byte command format has provision for 4 (not 2) independent data transfers (data + meta, for each direction). Surely NVMe will sooner or later take advantage of those ... a command like READ GATHERED comes to mind.

NVMe on the other hand does have support for separate read and write buffers as in the current SCSI bidi support, as it encodes the data transfers in that SQE. So IFF NVMe does bidi commands it would have to use a single buffer for data in/out, which can be easily done in the block layer without the current bidi support that chains two struct request instances for data in and data out.

Quoted 6 lines
Quoted 3 lines

2) reduce the size of the critical struct request structure by 128 bits, thus reducing the memory used by every blk-mq driver significantly, never mind the cache effects

Hmm, one pointer (that is null in the non-bidi case) should be enough, that's 64 or 32 bits.

Due to the way we use request chaining we need two fields at the moment. ->special and ->next_rq. If we'd refactor the whole thing for the basically non-existent user we could indeed probably get it down to a single pointer.

Quoted 3 lines

While on the subject of bidi, the order of transfers: is the data-out (to the target) always before the data-in or is it the target device that decides (depending on the semantics of the command) who is first?

The way I read SAM data needs to be transferred to the device for processing first, then the processing occurs and then it is transferred out, so the order seems fixed.

Quoted 5 lines

Doug Gilbert

*** there could already be vendor specific bidi NVMe commands out
there (ditto for SCSI)

For NVMe they'd need to transfer data in and out in the same buffer to sort work, and even then only if we don't happen to be bounce buffering using swiotlb, or using a network transport. Similarly for SCSI only iSCSI at the moment supports bidi CDBs, so we could have applications using vendor specific bidi commands on iSCSI, which is exactly what we're trying to find out, but it is a bit of a very niche use case.

#20 lore raw
Quoted 14 lines · Christoph Hellwig
Quoted 12 lines · Douglas Gilbert
Quoted 2 lines

1) reduce the size of every kernel with block layer support, and even more for every kernel with scsi support

By proposing the removal of bidi support from the block layer, it isn't just the SCSI subsystem that will be impacted. Those NVMe documents that you referred me to earlier in the year, in the command tables in 1.3c and earlier you have noticed the 2 bit direction field and what 11b means? Even if there aren't any bidi NVMe commands *** yet, the fact that NVMe's 64 byte command format has provision for 4 (not 2) independent data transfers (data + meta, for each direction). Surely NVMe will sooner or later take advantage of those ... a command like READ GATHERED comes to mind.

Quoted 4 lines

NVMe on the other hand does have support for separate read and write buffers as in the current SCSI bidi support, as it encodes the data transfers in that SQE. So IFF NVMe does bidi commands it would have to use a single buffer for data in/out,

There is no such thing as "buffer" there is at first a bio, and after virtual-to-iommu mapping a scatter-gather-list. All these are currently governed by a struct request.
request, bio, and sgl, have a single direction, All API's expect a single direction.

All BIDI did was to say. Lets not change any API or structure but just use two of them at the same time.

All the wiser is the very high level user, and the very low HW driver like iscsi. All the middlewere was never touched.

In the view of a bidi target like say an osd. It all stream looks like a single "Buffer" on the wire, were some of it is read and some of it is written to.

Quoted 1 line

which can be easily done

?? Did you try. It will take much more than an additional pointer sir

Quoted 3 lines

in the block layer without the current bidi support that chains two struct request instances for data in and data out.

That was the all trick of not changing a single API or structure Just have two of the same thing, we already know how to handle

Quoted 9 lines
Quoted 6 lines
Quoted 3 lines

2) reduce the size of the critical struct request structure by 128 bits, thus reducing the memory used by every blk-mq driver significantly, never mind the cache effects

Hmm, one pointer (that is null in the non-bidi case) should be enough, that's 64 or 32 bits.

Due to the way we use request chaining we need two fields at the moment. ->special and ->next_rq.

No! ->special is nothing to do with bidi. ->special is a field to be used by LLD's only and are not to be touched by block layer or transports or high level users.

Request has the single ->next_rq for bidi. And could be eliminated by sharing space with the elevator info. Do you want a patch?

(So in effect it can be taking 0 bytes, and yes a little bit of code)

Quoted 4 lines

If we'd refactor the whole thing
for the basically non-existent user we could indeed probably get it down to a single pointer.

Quoted 8 lines
Quoted 3 lines

While on the subject of bidi, the order of transfers: is the data-out (to the target) always before the data-in or is it the target device that decides (depending on the semantics of the command) who is first?

The way I read SAM data needs to be transferred to the device for processing first, then the processing occurs and then it is transferred out, so the order seems fixed.

Not sure what is the "SAM" above. But most of the BIDI commands I know, osd and otherwise, the order is command specific, and many times it is done in parallel.
Read some bits than write some bits, rinse and repeat ...

(You see in scsi the all OUT buffer is part of the actual CDB, so in effect
any READ is a BIDI. The novelty here is the variable sizes and the SW stack memory targets for the different operations)

Quoted 6 lines
Quoted 5 lines

Doug Gilbert

*** there could already be vendor specific bidi NVMe commands out
there (ditto for SCSI)

Quoted 8 lines

For NVMe they'd need to transfer data in and out in the same buffer to sort work, and even then only if we don't happen to be bounce buffering using swiotlb, or using a network transport. Similarly for SCSI only iSCSI at the moment supports bidi CDBs, so we could have applications using vendor specific bidi commands on iSCSI, which is exactly what we're trying to find out, but it is a bit of a very niche use case.

Again bidi works NOW. Did not yet see the big gain, of throwing it out.

Jai Maa
Boaz

#21 lore raw
In reply to Douglas Gilbert
Quoted 8 lines

-----Original Message-----
From: [email protected] <linux-kernel- [email protected]> On Behalf Of Douglas Gilbert
Sent: Wednesday, December 19, 2018 9:02 PM
Subject: Re: remove exofs, the T10 OSD code and block/scsi bidi support V3

...

Quoted 3 lines

While on the subject of bidi, the order of transfers: is the data-out (to the target) always before the data-in or is it the target device that decides (depending on the semantics of the command) who is first?

In SCSI, that was command-specific. Some necessitated intermixing the transfers, while others did all one direction before all the other direction.

---
Robert Elliott, HPE Persistent Memory

#22 lore raw
In reply to Christoph Hellwig
Quoted 8 lines · Christoph Hellwig
Quoted 7 lines · Boaz Harrosh
Quoted 5 lines · Christoph Hellwig

The only real user of the T10 OSD protocol, the pNFS object layout driver never went to the point of having shipping products, and we removed it 1.5 years ago. Exofs is just a simple example without real life users.

Quoted 7 lines
Quoted 2 lines

You have failed to say what is your motivation for this patchset? What is it you are trying to fix/improve.

Drop basically unused support, which allows us to

1) reduce the size of every kernel with block layer support, and even more for every kernel with scsi support

Do you have numbers? its mainly code-segment so I don't think you will see any real life measurable difference.

Quoted 3 lines

2) reduce the size of the critical struct request structure by 128 bits, thus reducing the memory used by every blk-mq driver significantly, never mind the cache effects

128 bits? I see the "struct request *next_rq;"
is there another one?

It could share space with elv; && flush;
Do you want a patch?

Quoted 3 lines

3) stop having the maintainance overhead for this code in the block layer, which has been rather painful at times

I hear you man. Life is pain. But is it really such an overhead? I mean it is already implemented. What else is there to do? Please please show me? (Sorry for being slow)

Jai Maa
Boaz