linux-kernel - Re: [PATCH 1/1] um: fix error return code in winch

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <YofQgDo38fAnPZEy@dev-arch.thelio-3990X>
Date:   Fri, 20 May 2022 10:31:44 -0700
From:   Nathan Chancellor <nathan@...nel.org>
To:     Johannes Berg <johannes@...solutions.net>
Cc:     Thorsten Leemhuis <regressions@...mhuis.info>,
        Richard Weinberger <richard@....at>,
        Zhen Lei <thunder.leizhen@...wei.com>,
        Jeff Dike <jdike@...toit.com>,
        anton ivanov <anton.ivanov@...bridgegreys.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Eduard-Gabriel Munteanu <maxdamage@...din.ro>,
        linux-um <linux-um@...ts.infradead.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        regressions <regressions@...ts.linux.dev>
Subject: Re: [PATCH 1/1] um: fix error return code in winch_tramp()

On Fri, May 20, 2022 at 07:18:28PM +0200, Johannes Berg wrote:
> On Fri, 2022-05-20 at 08:55 -0700, Nathan Chancellor wrote:
> > On Fri, May 20, 2022 at 08:08:01AM +0200, Thorsten Leemhuis wrote:
> > > On 11.04.22 20:45, Richard Weinberger wrote:
> > > > ----- Ursprüngliche Mail -----
> > > > > Von: "Nathan Chancellor" <nathan@...nel.org>
> > > > > I attempted to print out the error code but it seems like there is no
> > > > > output in the console after "reboot: System halted". If I add an
> > > > > unconditional print right before the call to os_set_fd_block(), I see it
> > > > > during start up but I do not see it during shutdown. Is there some way
> > > > > to see that console output during shutdown?
> > > > 
> > > > I think in this case the easiest way is attaching gdb with a breakpoint.
> > > 
> > > I noticed this in my list of open regressions. It seems there wasn't any
> > > progress to get this regression fixed (please let me know in case I
> > > missed something), but I guess nobody considered it urgent which is
> > > likely not that much of a problem in this case.
> > 
> > Yes, sorry, I tried to get gdb to reveal something but I couldn't get it
> > to work then I had to move onto other work. We have worked around this
> > for the time being but it would still be nice to figure out what is
> > going on here; I am just not sure when I am going to have time to
> > participate in that process.
> > 
> 
> This fixes it for me, can you check it?

Yes, that works for me as well, thanks for looking into it!

Tested-by: Nathan Chancellor <nathan@...nel.org>

> diff --git a/arch/um/drivers/chan_user.c b/arch/um/drivers/chan_user.c
> index 6040817c036f..25727ed648b7 100644
> --- a/arch/um/drivers/chan_user.c
> +++ b/arch/um/drivers/chan_user.c
> @@ -220,7 +220,7 @@ static int winch_tramp(int fd, struct tty_port *port, int *fd_out,
>  		       unsigned long *stack_out)
>  {
>  	struct winch_data data;
> -	int fds[2], n, err;
> +	int fds[2], n, err, pid;
>  	char c;
>  
>  	err = os_pipe(fds, 1, 1);
> @@ -238,8 +238,9 @@ static int winch_tramp(int fd, struct tty_port *port, int *fd_out,
>  	 * problem with /dev/net/tun, which if held open by this
>  	 * thread, prevents the TUN/TAP device from being reused.
>  	 */
> -	err = run_helper_thread(winch_thread, &data, CLONE_FILES, stack_out);
> -	if (err < 0) {
> +	pid = run_helper_thread(winch_thread, &data, CLONE_FILES, stack_out);
> +	if (pid < 0) {
> +		err = pid;
>  		printk(UM_KERN_ERR "fork of winch_thread failed - errno = %d\n",
>  		       -err);
>  		goto out_close;
> @@ -263,7 +264,7 @@ static int winch_tramp(int fd, struct tty_port *port, int *fd_out,
>  		goto out_close;
>  	}
>  
> -	return err;
> +	return pid;
>  
>   out_close:
>  	close(fds[1]);
> 
> 
> Kind of obvious, really. :)
> 
> johannes