public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Bartosz Golaszewski <brgl@bgdev.pl>
To: Wolfram Sang <wsa@kernel.org>
Cc: linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org,
	Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Subject: [PATCH v2 0/2] i2c: fortify the subsystem against user-space induced deadlocks
Date: Thu, 29 Dec 2022 17:00:43 +0100	[thread overview]
Message-ID: <20221229160045.535778-1-brgl@bgdev.pl> (raw)

From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

Several subsystems in the kernel that export device files to user-space
suffer from a bug where keeping an open file descriptor associated with
this device file, unbinding the device from its driver and then calling
any of the supported system calls on that file descriptor will result in
either a crash or - as is the case with i2c - a deadlock.

This behavior has been blamed on extensive usage of device resource
management interfaces but it seems that devres has nothing to do with it,
the problem would be the same whether using devres or freeing resources
in .remove() that should survive the driver detach.

Many subsystems already deal with this by implementing some kind of flags
in the character device data together with locking preventing the
user-space from dropping the subsystem data from under the open device.

In i2c the deadlock comes from the fact that the function unregistering
the adapter waits for a completion which will not be passed until all
references to the character device are dropped.

The first patch in this series is just a tweak of return values of the
notifier callback. The second addresses the deadlock problem in a way
similar to how we fixed this issue in the GPIO subystem. Details are in
the commit message.

v1 -> v2:
- keep the device release callback and use it to free the IDR number
- rebase on top of v6.2-rc1

Bartosz Golaszewski (2):
  i2c: dev: fix notifier return values
  i2c: dev: don't allow user-space to deadlock the kernel

 drivers/i2c/i2c-core-base.c |  26 ++-------
 drivers/i2c/i2c-dev.c       | 112 +++++++++++++++++++++++++++++-------
 include/linux/i2c.h         |   2 -
 3 files changed, 96 insertions(+), 44 deletions(-)

-- 
2.37.2


             reply	other threads:[~2022-12-29 16:00 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-29 16:00 Bartosz Golaszewski [this message]
2022-12-29 16:00 ` [PATCH v2 1/2] i2c: dev: fix notifier return values Bartosz Golaszewski
2023-01-17 10:04   ` Wolfram Sang
2023-03-08 16:58   ` Geert Uytterhoeven
2023-03-08 19:33     ` Bartosz Golaszewski
2023-03-08 19:51       ` Geert Uytterhoeven
2023-03-09  7:47         ` Geert Uytterhoeven
2022-12-29 16:00 ` [PATCH v2 2/2] i2c: dev: don't allow user-space to deadlock the kernel Bartosz Golaszewski
2023-01-17 10:08   ` Wolfram Sang
2023-01-17 10:10     ` Bartosz Golaszewski
2023-01-17 10:26       ` Wolfram Sang
2023-01-17 18:57   ` Wolfram Sang
2023-01-18 12:51     ` Bartosz Golaszewski
     [not found]   ` <20230118145914.3012-1-hdanton@sina.com>
2023-01-18 15:07     ` Bartosz Golaszewski
2023-01-12  9:01 ` [PATCH v2 0/2] i2c: fortify the subsystem against user-space induced deadlocks Bartosz Golaszewski
2023-01-12  9:09   ` Wolfram Sang

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=20221229160045.535778-1-brgl@bgdev.pl \
    --to=brgl@bgdev.pl \
    --cc=bartosz.golaszewski@linaro.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=wsa@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox