linux-hardening - Re: [GIT PULL] bcachefs updates for 6.8

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: Thu, 11 Jan 2024 19:05:06 -0500
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: Kees Cook <keescook@...omium.org>
Cc: Matthew Wilcox <willy@...radead.org>, 
	Linus Torvalds <torvalds@...ux-foundation.org>, linux-bcachefs@...r.kernel.org, linux-fsdevel@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org
Subject: Re: [GIT PULL] bcachefs updates for 6.8

On Thu, Jan 11, 2024 at 03:42:19PM -0800, Kees Cook wrote:
> On Thu, Jan 11, 2024 at 10:57:18PM +0000, Matthew Wilcox wrote:
> > On Wed, Jan 10, 2024 at 05:47:20PM -0800, Linus Torvalds wrote:
> > > No, because the whole idea of "let me mark something deprecated and
> > > then not just remove it" is GARBAGE.
> > > 
> > > If somebody wants to deprecate something, it is up to *them* to finish
> > > the job. Not annoy thousands of other developers with idiotic
> > > warnings.
> > 
> > What would be nice is something that warned about _new_ uses being
> > added.  ie checkpatch.  Let's at least not make the problem worse.
> 
> For now, we've just kind of "dealt with it". For things that show up
> with new -W options we've enlisted sfr to do the -next builds with it
> explicitly added (but not to the tree) so he could generate nag emails
> when new warnings appeared. That could happen if we added it to W=1
> builds, or some other flag like REPORT_DEPRECATED=1.
> 
> Another ugly idea would be to do a treewide replacement of "func" to
> "func_deprecated", and make "func" just a wrapper for it that is marked
> with __deprecated. Then only new instances would show up (assuming people
> weren't trying to actively bypass the deprecation work by adding calls to
> "func_deprecated"). :P Then the refactoring to replace "func_deprecated"
> could happen a bit more easily.
> 
> Most past deprecations have pretty narrow usage. This is not true with
> the string functions, which is why it's more noticeable here. :P

Before doing the renaming - why not just leave a kdoc comment that marks
it as deprecated? Seems odd that checkpatch was patched, but I can't
find anything marking it as deprecated when I cscope to it.