From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Schmitz Subject: Re: [PATCH 0/9] Refactoring exit Date: Tue, 29 Jun 2021 11:42:16 +1200 Message-ID: <36123b5d-daa0-6c2b-f2d4-a942f069fd54@gmail.com> References: <87a6njf0ia.fsf@disp2133> <87tulpbp19.fsf@disp2133> <87zgvgabw1.fsf@disp2133> <875yy3850g.fsf_-_@disp2133> <6e283d24-7121-ae7c-d5ad-558f85858a09@gmail.com> <7ad6c3a9-b983-46a5-fc95-f961b636d3fe@gmail.com> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=MnOd9iaFXNVD5FJdstRfyB3AFTdce3B7edCsrT/B65c=; b=pqa8SXQ/hrN3EE8tWnQaXTgQQ3IZBW/4UPp07rsEpJERt1vDmlBqwfOVQJuTRyq0Am H/71eemQRinvfC1+TvsMm3hta9jb1/e0qATCWojjxQKaLzr4Oml0uSu5Xq0jVZVXJqER MDi/VtgB+XdWcx9atuL8LQkkSpJ0xM/te+EfGO7nhhSi9Mhs8zUsnBMZEpBTkGIA4Fpk 3pUjAvMP3WS/7h60szKRz131Yf2UsqM8p6CgL0/4ZV5qJrWEmM56TyOTQZFHm/pbrDd7 L/MwUK09uULPkJsmlecXAHPFUVAJaGDsqbKUmRTCqPFtorFVPxlMJpH98IJ4wEi9vvlQ LPbA== In-Reply-To: Content-Language: en-US List-ID: Content-Type: text/plain; charset="utf-8"; format="flowed" To: Geert Uytterhoeven Cc: Al Viro , "Eric W. Biederman" , Linus Torvalds , linux-arch , Jens Axboe , Oleg Nesterov , Linux Kernel Mailing List , Richard Henderson , Ivan Kokshaysky , Matt Turner , alpha , linux-m68k , Arnd Bergmann , Tejun Heo , Kees Cook Hi Geert, On 29/06/21 9:18 am, Geert Uytterhoeven wrote: > >>>> The question then is - will bdflush fail gracefully, or spin retrying >>>> the syscall? >>> Will add to my todo list... >>> BTW, you can boot this ramdisk on ARAnyM, too. >> True. I can't find that ramdisk image anywhere - if you can point me to >> some archive, I'll give that a try. > http://ftp.mac.linux-m68k.org/pub/linux-mac68k/initrd/ Thanks - removing the if (func==1) do_exit(0); part does give similar behaviour as before - kernel warns five times, then shuts up (without change, warns twice only, and /sbin/update no longer runs). Removing the syscall from the m68k syscall table altogether still gives a working ramdisk. /sbin/update is still running, so evidently doesn't care about the invalid syscall result ... Cheers,     Michael > > Gr{oetje,eeting}s, > > Geert >