From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: [PATCH 0/9] Refactoring exit Date: Sun, 27 Jun 2021 22:13:32 +0000 Message-ID: References: <87a6njf0ia.fsf@disp2133> <87tulpbp19.fsf@disp2133> <87zgvgabw1.fsf@disp2133> <875yy3850g.fsf_-_@disp2133> Mime-Version: 1.0 Return-path: Content-Disposition: inline In-Reply-To: Sender: Al Viro List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: "Eric W. Biederman" Cc: Linus Torvalds , Michael Schmitz , linux-arch , Jens Axboe , Oleg Nesterov , Linux Kernel Mailing List , Richard Henderson , Ivan Kokshaysky , Matt Turner , alpha , Geert Uytterhoeven , linux-m68k , Arnd Bergmann , Ley Foon Tan , Tejun Heo , Kees Cook On Thu, Jun 24, 2021 at 10:45:23PM +0000, Al Viro wrote: > 13) there's bdflush(1, whatever), which is equivalent to exit(0). > IMO it's long past the time to simply remove the sucker. Incidentally, calling that from ptraced process on alpha leads to the same headache for tracer. _If_ we leave it around, this is another candidate for "hit yourself with that special signal" - both alpha and m68k have that syscall, and IMO adding an asm wrapper for that one is over the top. Said that, we really ought to bury that thing: commit 2f268ee88abb33968501a44368db55c63adaad40 Author: Andrew Morton Date: Sat Dec 14 03:16:29 2002 -0800 [PATCH] deprecate use of bdflush() Patch from Robert Love We can never get rid of it if we do not deprecate it - so do so and print a stern warning to those who still run bdflush daemons. Deprecated for 18.5 years by now - I seriously suspect that we have some contributors younger than that...