linux-i2c.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Viresh Kumar <viresh.kumar@linaro.org>
To: Jean Delvare <jdelvare@suse.de>
Cc: Wolfram Sang <wsa@the-dreams.de>,
	linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org,
	gregkh@linuxfoundation.org, Johan Hovold <johan@kernel.org>,
	Alex Elder <elder@linaro.org>
Subject: Re: [PATCH 2/2] i2c-dev: Don't block the adapter from unregistering
Date: Wed, 6 Jul 2016 13:55:40 -0700	[thread overview]
Message-ID: <20160706205540.GJ4127@ubuntu> (raw)
In-Reply-To: <20160706191218.483fd9fd@endymion>

On 06-07-16, 19:12, Jean Delvare wrote:
> Well well... I don't like this patch at all to be honest.

Sure, I didn't like it much as well. I just wanted people to comment on what
else we can do here. We don't really want to add out-of-mainline stuff here.

> My first question would be: what is keeping /dev/i2c-* open all the
> time? Originally i2c-dev was developed with development and debugging
> tools in mind (the i2c-tools suite.) The device nodes were never meant
> to be kept open for more than a few seconds.

We thought that buggy userspace shouldn't be allowed to get kernel into trouble.
Isn't that the case ?

In our case this is what happens:
- userspace opens the file descriptor
- we try to forcefully remove the module from phone (that doesn't talk to
  userspace to stop using the device).
- The module doesn't get ejected unless the app closes the fd.

> Do you have user-space i2c device drivers on your system? Which ones,

No. Its probably an app written by some of our module app developers.

> and why (I would expect all useful i2c devices to have a kernel
> driver.)

That's what we have.

> Requesting and freeing the i2c adapter for every transaction is going

Well, we are just finding it (taking a reference of it) and the dropping its
reference.

> to add a lot of overhead to all existing tools :-(

:(

> It's not like every user can open i2c device nodes and block the
> system. Only selected users should be able to open i2c device nodes
> (only root by default) so they should be responsible for not
> misbehaving.

Hmmm. The problem is that they weren't told when the module tries to go away and
so they don't know that they need to close the fd.

Also coming to the earlier thing, I though even the buggy userspace thing
shouldn't be allowed to block kernel device unregisteration.

-- 
viresh

  reply	other threads:[~2016-07-06 20:55 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-06  2:57 [PATCH 0/2] i2c-dev: Don't let userspace block adapter Viresh Kumar
2016-07-06  2:57 ` [PATCH 1/2] i2c-dev: don't get i2c adapter via i2c_dev Viresh Kumar
2016-07-06 17:04   ` Jean Delvare
2016-07-06 17:07     ` Viresh Kumar
2016-07-07 13:16   ` Jean Delvare
2016-07-07 15:35     ` Viresh Kumar
2016-07-08  1:31   ` Wolfram Sang
2016-07-06  2:57 ` [PATCH 2/2] i2c-dev: Don't block the adapter from unregistering Viresh Kumar
2016-07-06  4:32   ` kbuild test robot
2016-07-06  6:55   ` Wolfram Sang
2016-07-06 13:50     ` Viresh Kumar
2016-07-06 17:12     ` Jean Delvare
2016-07-06 20:55       ` Viresh Kumar [this message]
2016-07-11 12:22         ` Jean Delvare
2016-07-11 21:50           ` Greg KH
2016-07-18 20:20             ` Viresh Kumar
2016-07-25  9:39             ` Jean Delvare
2016-07-25 22:31               ` Viresh Kumar
2016-07-26  7:41                 ` Jean Delvare
2016-07-26 15:18                   ` Dmitry Torokhov
2016-07-06  8:22   ` Peter Rosin
2016-07-06 14:33     ` Viresh Kumar
2016-07-06 14:43       ` Lars-Peter Clausen
2016-07-06 15:04         ` Peter Rosin
2016-07-06 15:37           ` Viresh Kumar
2016-07-06 15:35         ` Viresh Kumar
2016-07-06 14:41 ` [PATCH 0/2] i2c-dev: Don't let userspace block adapter Lars-Peter Clausen
2016-07-06 15:34   ` Viresh Kumar

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=20160706205540.GJ4127@ubuntu \
    --to=viresh.kumar@linaro.org \
    --cc=elder@linaro.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jdelvare@suse.de \
    --cc=johan@kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=wsa@the-dreams.de \
    /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;
as well as URLs for NNTP newsgroup(s).