linux-kernel - Re: [PATCH 2/2] serial: pl011: 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]

Message-ID: <20140219144751.75f7fb70@alan.etchedpixels.co.uk>
Date:	Wed, 19 Feb 2014 14:47:51 +0000
From:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To:	Mark Brown <broonie@...nel.org>
Cc:	Russell King - ARM Linux <linux@....linux.org.uk>,
	Greg KH <gregkh@...uxfoundation.org>,
	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
Subject: Re: [PATCH 2/2] serial: pl011: Move uart_register_driver call to
 device probe

> Please try to avoid this sort of misdirected yelling, it's not helping

I don't see any misdirected yelling

> anything to complain that people are following the recommendations of
> the maintainer or to demand that this somehow gets hacked around in
> arch/ when we're trying to convince all the architectures to get their
> drivers merged into subsystem trees so they're reviewed by the subsystem
> maintainers.

It's not a case of hacking around it in arch. It's a case of fixing up
problems where they belong, which btw is what Greg has in his tree -
specifically ef2889f7ffee67f0aed49e854c72be63f1466759 and
6f134c3c770355b7e930d3ffc558864668f13055 which keep the handling of the
minor clash cock-up in the drivers affected.

No garbage in the core tty drivers, no racy delayed registration in the
core uart code. In the longer term we should probably just abolish the
fixed minor numbers, nothing in the real world cares about them enough to
justify keeping them forever.

> you're doing here is making disparaging remarks and telling people to
> adopt bad practices because someone else made a mistake a decade ago.

I'm not telling anyone to adopt bad practices - at least its news to me
that "stopping the merge of buggy crap" is now a bad practice.

> That is how problems like this get created in the first place.

We were having a discussion about the fact the proposed patch for
deferring the processing was buggy, and probably unfixably so. That's a
code correctness discussion. Merging overcomplicated buggy crap causes
problems.

> > And the proposed change set is buggy as hell - because we register things
> > like 8250 devices at least four ways on the same x86 machine all of which
> > could in theory occur in parallel.
> 
> Then you need to convince Greg of that.  The most recent set of patches
> are exactly what he asked for.

No there's an assumption that when someone asks for patches the proposed
changes actually *work*. As Russell has demonstrated - the general
deferral patches for the uart/tty layer are broken. The driver specific
fixups in -next on the other hand appear to be fine providing the amba
bus probe remains serialized (and trivially fixed if it doesn't).

Alan

--
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/