[<prev] [next>] [day] [month] [year] [list]
Message-Id: <20190318211713.3462-1-willy@infradead.org>
Date: Mon, 18 Mar 2019 14:17:09 -0700
From: Matthew Wilcox <willy@...radead.org>
To: linux-usb@...r.kernel.org, Oliver Neukum <oneukum@...e.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Mathias Nyman <mathias.nyman@...el.com>,
Johan Hovold <johan@...nel.org>,
Matthew Wilcox <willy@...radead.org>,
Roger Quadros <rogerq@...com>,
Alan Stern <stern@...land.harvard.edu>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
Dmitry Torokhov <dtor@...omium.org>,
"Gustavo A. R. Silva" <gustavo@...eddedor.com>,
Miquel Raynal <miquel.raynal@...tlin.com>,
Mathias Payer <mathias.payer@...elwelt.net>,
Mans Rullgard <mans@...sr.com>,
Kai-Heng Feng <kai.heng.feng@...onical.com>,
Jia-Ju Bai <baijiaju1990@...il.com>,
linux-kernel@...r.kernel.org
Subject: [PATCH 0/4] Convert USB subsystem to XArray
I would like to remove the IDR and radix tree APIs from the kernel.
This patch series converts all the IDRs and radix trees in the USB
subsystem to use the XArray APIs. Testing of these patches has been
minimal, mostly limited to compilation testing. I would be grateful if
you could take these patches through your tree. To cut down on wasted
electrons, only this cover letter is being distributed to everyone
listed by get-maintainers; the patches can be found on the linux-usb
mailing list.
Please check these patches over carefully and test them; there may be
off-by-one errors, locking mistakes, or various other failures on my part.
Substantive interface changes
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- The IDR and radix tree required callers to handle their own locking.
The XArray embeds a spinlock which is taken for modifications to
the data structure; plain lookups occur under the RCU read lock or
under the spinlock.
- You can take the spinlock yourself (xa_lock() and friends) to protect
related data.
- idr_alloc() returned -ENOSPC, radix_tree_insert() returned -EEXIST.
xa_insert() and xa_alloc() return -EBUSY.
- The search keys which the radix tree calls "tags", the XArray calls
"marks".
- There is no preloading in the XArray API. Most users of the
preloading APIs only needed to use it because they were trying to
allocate under their own spinlock. If your locking is exceptionally
complicated, you may need to use xa_insert() with a NULL pointer.
- The radix tree provided GFP flags as part of the tree definition;
the XArray (like the IDR) passes GFP flags at the point of allocation.
- radix_tree_insert() of a NULL pointer was not well-specified. The
XArray treats it as reserving the entry (it reads back as NULL but
a subsequent xa_insert() to that slot will fail).
- xa_alloc() and xa_alloc_cyclic() need the XArray initialised with
XA_FLAGS_ALLOC or XA_FLAGS_ALLOC1. If the allocation is 1-based,
then specifying a limit on the allocation which includes 0 will
never allocate ID 0.
- xa_alloc_cyclic() returns 1 if the allocation wraps, unlike
idr_alloc_cyclic() which provides no indication.
- There is no equivalent to idr_for_each(); the xa_for_each() iterator
is similar to idr_for_each_entry().
- idr_replace() has no exact equivalent. Some users relied on its exact
semantics of only storing if the entry was non-NULL, but all users of
idr_replace() were able to use xa_store() or xa_cmpxchg().
- The family of radix tree gang lookup functions have been replaced with
xa_extract().
Matthew Wilcox (4):
usb: Convert xhci-mem to XArray
cdc-acm: Convert acm_minors to XArray
usb: Convert usb_bus_idr to XArray
usb/serial: Convert serial_minors to XArray
drivers/usb/class/cdc-acm.c | 33 ++++++-------
drivers/usb/core/devices.c | 10 ++--
drivers/usb/core/hcd.c | 40 ++++-----------
drivers/usb/core/usb.c | 1 -
drivers/usb/host/r8a66597-hcd.c | 4 +-
drivers/usb/host/xhci-mem.c | 86 ++++++++++++---------------------
drivers/usb/host/xhci.h | 5 +-
drivers/usb/mon/mon_main.c | 7 ++-
drivers/usb/serial/usb-serial.c | 21 ++++----
include/linux/usb/hcd.h | 3 +-
10 files changed, 74 insertions(+), 136 deletions(-)
--
2.20.1
Powered by blists - more mailing lists