linux-kernel - Re: [PATCH] ARM: remove ARM710 specific assembler code

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:	Mon, 19 May 2014 11:18:49 +0100
From:	Catalin Marinas <catalin.marinas@....com>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	Paul Bolle <pebolle@...cali.nl>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Arnd Bergmann <arnd@...db.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ARM: remove ARM710 specific assembler code

On Sat, May 17, 2014 at 11:26:38AM +0100, Russell King - ARM Linux wrote:
> On Sat, May 17, 2014 at 10:56:02AM +0100, Catalin Marinas wrote:
> > > The difference between what you're proposing and what happened to ARMv3
> > > is that ARMv3 was broken for quite some time (we read from some of the
> > > CP15 registers which are read-only in ARMv3) and no one ever raised a
> > > problem with that.  So, after a sufficient period of time, it got removed
> > > - and no one batted an eyelid.  That's the correct way to do it - allow
> > > code to age, and if no one notices it's been broken, then it can be
> > > removed.
> > 
> > I’m more for pro-actively “breaking” it with a DEPRECATED
> > dependency. For example, if you suspect that some code like ARM710T is
> > no longer in use, we mark it and see if anyone complains about this over
> > a two years period. If not, it gets removed.
> > 
> > Waiting for code to get broken is another way but it’s less
> > predictable.
> 
> When code being used gets broken, it's nice to think that we'll get
> bug reports which will tell us if it's still being used.

But if you don't get any reports, you can't really whether it's broken
(just because it compiles doesn't mean it still works). So we end up
with keeping code in the kernel for much longer than necessary.

> The problem
> with DEPRECATED is that it will get lost amongst all the thousands
> of other config options and won't be noticed.  Just like EXPERIMENTAL
> or any of the other similar options we've had.

DEPRECATED is meant for documenting the planned removal. If people
complain afterwards, it's their problem for not reporting it earlier.

But we can make it even clearer by adding "depends on n" for DEPRECATED
or just making it not user selectable, so that people would need to
actively change the Kconfig source. They can't complain they haven't
noticed.

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