From: Johan Hovold <johan@kernel.org>
To: "Fabio M. De Francesco" <fmdefrancesco@gmail.com>
Cc: Alex Elder <elder@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
greybus-dev@lists.linaro.org, linux-staging@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4] staging: greybus: Convert uart.c from IDR to XArray
Date: Mon, 30 Aug 2021 11:12:28 +0200 [thread overview]
Message-ID: <YSyg/Db1So0LDGR+@hovoldconsulting.com> (raw)
In-Reply-To: <20210829092250.25379-1-fmdefrancesco@gmail.com>
On Sun, Aug 29, 2021 at 11:22:50AM +0200, Fabio M. De Francesco wrote:
> Convert greybus/uart.c from IDR to XArray. The abstract data type XArray
> is more memory-efficient, parallelisable, and cache friendly. It takes
> advantage of RCU to perform lookups without locking. Furthermore, IDR is
> deprecated because XArray has a better (cleaner and more consistent) API.
Where does it say that IDR is deprecated? Almost all drivers use IDR/IDA
and its interfaces are straight-forward. In most cases we don't care
about a possible slight increase in efficiency either, and so also in
this case. Correctness is what matters and doing these conversions risks
introducing regressions.
And I believe IDR use XArray internally these days anyway.
> Signed-off-by: Fabio M. De Francesco <fmdefrancesco@gmail.com>
> ---
>
> v3->v4:
> Remove mutex_lock/unlock around xa_load(). These locks seem to
> be unnecessary because there is a 1:1 correspondence between
> a specific minor and its gb_tty and there is no reference
> counting. I think that the RCU locks used inside xa_load()
> are sufficient to protect this API from returning an invalid
> gb_tty in case of concurrent access. Some more considerations
> on this topic are in the following message to linux-kernel list:
> https://lore.kernel.org/lkml/3554184.2JXonMZcNW@localhost.localdomain/
This just doesn't make sense (and a valid motivation would need to go in
the commit message if there was one).
> v2->v3:
> Fix some issues according to a review by Alex Elder <elder@ieee.org>
> v1->v2:
> Fix an issue found by the kernel test robot. It is due to
> passing to xa_*lock() the same old mutex that IDR used with
> the previous version of the code.
>
> drivers/staging/greybus/uart.c | 32 ++++++++++++++------------------
> 1 file changed, 14 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/staging/greybus/uart.c b/drivers/staging/greybus/uart.c
> index 73f01ed1e5b7..f66983adb51b 100644
> --- a/drivers/staging/greybus/uart.c
> +++ b/drivers/staging/greybus/uart.c
> @@ -22,7 +22,7 @@
> #include <linux/serial.h>
> #include <linux/tty_driver.h>
> #include <linux/tty_flip.h>
> -#include <linux/idr.h>
> +#include <linux/xarray.h>
> #include <linux/fs.h>
> #include <linux/kdev_t.h>
> #include <linux/kfifo.h>
> @@ -32,8 +32,9 @@
>
> #include "gbphy.h"
>
> -#define GB_NUM_MINORS 16 /* 16 is more than enough */
> -#define GB_NAME "ttyGB"
> +#define GB_NUM_MINORS 16 /* 16 is more than enough */
> +#define GB_RANGE_MINORS XA_LIMIT(0, GB_NUM_MINORS)
> +#define GB_NAME "ttyGB"
>
> #define GB_UART_WRITE_FIFO_SIZE PAGE_SIZE
> #define GB_UART_WRITE_ROOM_MARGIN 1 /* leave some space in fifo */
> @@ -67,8 +68,7 @@ struct gb_tty {
> };
>
> static struct tty_driver *gb_tty_driver;
> -static DEFINE_IDR(tty_minors);
> -static DEFINE_MUTEX(table_lock);
> +static DEFINE_XARRAY(tty_minors);
>
> static int gb_uart_receive_data_handler(struct gb_operation *op)
> {
> @@ -341,8 +341,7 @@ static struct gb_tty *get_gb_by_minor(unsigned int minor)
> {
> struct gb_tty *gb_tty;
>
> - mutex_lock(&table_lock);
> - gb_tty = idr_find(&tty_minors, minor);
> + gb_tty = xa_load(&tty_minors, minor);
> if (gb_tty) {
> mutex_lock(&gb_tty->mutex);
> if (gb_tty->disconnected) {
> @@ -353,19 +352,18 @@ static struct gb_tty *get_gb_by_minor(unsigned int minor)
> mutex_unlock(&gb_tty->mutex);
> }
> }
> - mutex_unlock(&table_lock);
You can't just drop the locking here since you'd introduce a potential
use-after-free in case gb_tty is freed after the lookup but before the
port reference is taken.
That said, this driver is already broken since it can currently free the
gb_tty while there are references to the port. I'll try to fix it up...
> return gb_tty;
> }
But as you may have gathered, I don't think doing these conversions is a
good idea.
Johan
next prev parent reply other threads:[~2021-08-30 9:12 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-29 9:22 [PATCH v4] staging: greybus: Convert uart.c from IDR to XArray Fabio M. De Francesco
2021-08-30 9:12 ` Johan Hovold [this message]
2021-08-30 11:10 ` Fabio M. De Francesco
2021-08-30 11:52 ` Johan Hovold
2021-08-30 12:16 ` Matthew Wilcox
2021-08-30 12:33 ` Johan Hovold
2021-08-30 13:16 ` Fabio M. De Francesco
2021-08-30 13:20 ` [greybus-dev] " Alex Elder
2021-08-31 8:07 ` Johan Hovold
2021-08-31 10:42 ` Alex Elder
2021-08-31 11:51 ` Johan Hovold
2021-08-31 11:50 ` Fabio M. De Francesco
2021-08-31 12:18 ` Johan Hovold
2021-09-01 12:09 ` Alex Elder
2021-09-01 13:56 ` Fabio M. De Francesco
2021-09-01 14:29 ` Matthew Wilcox
2021-09-01 15:39 ` Fabio M. De Francesco
2021-08-30 13:31 ` Matthew Wilcox
2021-08-31 8:16 ` Johan Hovold
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YSyg/Db1So0LDGR+@hovoldconsulting.com \
--to=johan@kernel.org \
--cc=elder@kernel.org \
--cc=fmdefrancesco@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=greybus-dev@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.