Hi Kees, On Thu, Sep 06, 2018 at 11:24:11AM -0700, Kees Cook wrote: > On Wed, Sep 5, 2018 at 7:24 PM, Steven Rostedt wrote: > > On Thu, 6 Sep 2018 09:41:58 +1000 > > Stephen Rothwell wrote: > >> On Wed, 5 Sep 2018 15:57:02 -0700 Kees Cook wrote: > >> > > >> > I'd like to discuss ways that we could deprecate APIs more sanely. At > >> > present I've seen (and used) two approaches, fast and slow: > >> > >> As the one who often has the "fun" of coping with API changes, I would > >> like to be involved in this discussion. > >> > >> My first point would be that (almost) every time someone has tried the > >> "ultra fast" method (i.e. add new interface, convert everyone in the > >> current kernel, remove the old interface all in one go) we have had new > >> users of the old interface introduced at the same time. (pain for the > >> linux-next bunny :-() > > > > Can this be solved with a script on kernel.org? Or a zero-day bot that > > checks new commits (and perhaps patches to LKML) that checks for > > deprecated functions being added by new code (like strcpy) and the > > author would then get a nasty email about adding deprecated interfaces. > > > > This would solve the issue of not everyone using the latest checkpatch, > > as this wouldn't be a voluntary self-check. It would also quickly > > educate developers on what code is not acceptable to be added. > > I think this boils down to how our development ecosystem works. Things > are pretty "voluntary" right now: one could easily ignore zero-day or > checkpatch all the time, and if a maintainer isn't checking these > things, a patch will go in. I have the feeling that the problem is a bit different than what you're actually describing. It's not so much that we ignore (as in voluntarily ignore) these new deprecated functions, but more that it's quite easy to overlook them if you're not following closely the current effort being done, especially when you don't really have a security culture. And then, there's some changes where the benefit is really not obvious (kmalloc_array comes to my mind). Polling actively some file isn't going to work, since well, we're all too busy and lazy to actually do that, but maybe adding warnings/errors to checkpatch would help, in a similar way than what's being done for the msleep vs mdelay warning, with a link to the documentation to explain why that is needed in the first place. I think that this would help to address the discoverability of those API changes. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com