linux-kernel - Re: [PATCH 1/2] serial: samsung: Move uart_register

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 21 Jan 2014 00:38:56 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	Tushar Behera <tushar.behera@...aro.org>,
	linux-kernel@...r.kernel.org, linux-serial@...r.kernel.org,
	linux-samsung-soc@...r.kernel.org, jslaby@...e.cz,
	ben.dooks@...ethink.co.uk, broonie@...nel.org
Subject: Re: [PATCH 1/2] serial: samsung: Move uart_register_driver call to
	device probe

On Mon, Jan 20, 2014 at 04:26:23PM -0800, Greg KH wrote:
> On Tue, Jan 21, 2014 at 12:07:06AM +0000, Russell King - ARM Linux wrote:
> > On Mon, Jan 20, 2014 at 03:51:28PM -0800, Greg KH wrote:
> > > On Mon, Jan 20, 2014 at 11:16:03PM +0000, Russell King - ARM Linux wrote:
> > > > I don't believe the driver model has any locking to prevent a drivers
> > > > ->probe function running concurrently with it's ->remove function for
> > > > two (or more) devices.
> > > 
> > > The bus prevents this from happening.
> > > 
> > > > The locking against this is done on a per-device basis, not a per-driver
> > > > basis.
> > > 
> > > No, on a per-bus basis.
> > 
> > I don't see it.
> > 
> > Let's start from driver_register().
> 
> Which happens from module probing, which is single-threaded, right?

Yes, to _some_ extent - the driver is added to the bus list of drivers
before existing drivers are probed, so it's always worth bearing in
mind that if a new device comes along, it's possible for that device
to be offered to even a driver which hasn't finished returning from
its module_init().

> > If you think there's a per-driver lock that's held over probes or removes,
> > please point it out.  I'm fairly certain that there isn't, because we have
> > to be able to deal with recursive probes (yes, we've had to deal with
> > those in the past.)
> 
> Hm, you are right, I think that's why we had to remove the locks.  The
> klist stuff handles us getting the needed locks for managing our
> internal lists of devices and drivers, and those should be fine.
> 
> So, let's go back to your original worry, what are you concerned about?
> A device being removed while probe() is called?

My concern is that we're turning something which should be simple into
something unnecessarily complex.  By that, I mean something along the
lines of:

static DEFINE_MUTEX(foo_mutex);
static unsigned foo_devices;

static int foo_probe(struct platform_device *pdev)
{
	int ret;

	mutex_lock(&foo_mutex);
	if (foo_devices++ == 0)
		uart_register_driver(&driver);

	ret = foo_really_probe_device(pdev);
	if (ret) {
		if (--foo_devices == 0)
			uart_unregister_driver(&driver);
	}
	mutex_unlock(&foo_mutex);

	return ret;
}

static int foo_remove(struct platform_device *pdev)
{
	mutex_lock(&foo_mutex);
	foo_really_remove(pdev);
	if (--foo_devices == 0)
		uart_unregister_driver(&driver);
	mutex_unlock(&foo_mutex);

	return 0;
}

in every single serial driver we have...  Wouldn't it just be better to
fix the major/minor number problem rather than have to add all that code
repetitively to all those drivers?

-- 
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/