linux-kernel - Re: [Syzkaller & bisect] There is "io_ring_exit_work" related Call Trace in v5.2-rc5 kernel

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] [day] [month] [year] [list]

Date:   Fri, 3 Feb 2023 10:08:16 +0800
From:   Pengfei Xu <pengfei.xu@...el.com>
To:     Jens Axboe <axboe@...nel.dk>
CC:     Pavel Begunkov <asml.silence@...il.com>,
        <linux-kernel@...r.kernel.org>, <heng.su@...el.com>
Subject: Re: [Syzkaller & bisect] There is "io_ring_exit_work" related Call
 Trace in v5.2-rc5 kernel

Hi Jens Axboe,

On 2023-02-02 at 13:37:43 -0700, Jens Axboe wrote:
> On 2/2/23 12:44?PM, Jens Axboe wrote:
> > On 2/2/23 1:56?AM, Pengfei Xu wrote:
> >> Hi Pavel Begunkov,
> >>
> >> On 2023-02-01 at 15:52:47 +0000, Pavel Begunkov wrote:
> >>> On 1/28/23 14:49, Pavel Begunkov wrote:
> >>>> On 1/28/23 08:44, Pengfei Xu wrote:
> >>>>> Hi Pavel Begunkov and kernel expert,
> >>>>>
> >>>>> Greeting!
> >>>>>
> >>>>> There is "io_ring_exit_work" related Call Trace in v5.2-rc5 kernel in guest
> >>>>> on Sapphire Rapids server.
> >>>>
> >>>> Thanks for the report, we'll take a look
> >>>
> >>> Not reproducible for me. Apparently, the repro creates a normal ring
> >>> and immediately closes it, then io_ring_exit_work() hangs waiting to
> >>> the task to execute task_work.
> >>   Ah, I put the reproduced virtual machine in gitlab.
> >>   git clone https://gitlab.com/xupengfe/repro_vm_env.git
> >>   cd repro_vm_env
> >>   tar -xvf repro_vm_env.tar.gz
> >>   cd repro_vm_env; ./start3.sh  // it needs qemu-system-x86_64 and I used v7.1.0
> >>      //start3.sh will load bzImage_2241ab53cbb5cdb08a6b2d4688feb13971058f65 v6.2-rc5 kernel
> >>   In vm and login with root,  there is no password for root.
> >>   After login vm successfully, ./repro   to reproduce this issue.
> >>   It could be reproduced in about 6min.
> >>
> >>   If you already have qemu-system-x86_64, please ignore below info.
> >>   If you want to install qemu v7.1.0 version,
> >>   git clone https://github.com/qemu/qemu.git
> >>   cd qemu
> >>   git checkout -f v7.1.0
> >>   mkdir build
> >>   cd build
> >>   yum install -y ninja-build.x86_64
> >>   ../configure --target-list=x86_64-softmmu --enable-kvm --enable-vnc --enable-gtk --enable-sdl
> >>   make
> >>   make install
> >>   Done.
> > 
> > Are you sure you attached the right kconfig in the initial report? It
> > is from 5.18.x.
  Yes, the kconfig from initial report is first used by 5.18.x kernel,
  and I added some new kconfig item based on the kconfig like kernel ibt:
  CONFIG_X86_KERNEL_IBT=y and so on.

  And use the kconfig then "make olddefconfig" to generate the kconfig
  for latest kernel.

  I will add above vm environment and kconfig making info for reproduced
  steps if I find new kernel issues.
  Thanks for remind!

> 
> Looks like a bug in 9p, can you try this?
  Thanks for your patch!
  The following patch was installed on top of v6.2-rc5 kernel, and tested this
  issue in vm on SPR and RPL-S platforms(reproduced platforms as before).
  This issue could not be reproduced in 40 min.
  Test result shows that this patch solves the problem.

  Thanks!
  BR.
> 
> 
> diff --git a/net/9p/client.c b/net/9p/client.c
> index 622ec6a586ee..5756d812d3d4 100644
> --- a/net/9p/client.c
> +++ b/net/9p/client.c
> @@ -18,6 +18,7 @@
>  #include <linux/sched/signal.h>
>  #include <linux/uaccess.h>
>  #include <linux/uio.h>
> +#include <linux/task_work.h>
>  #include <net/9p/9p.h>
>  #include <linux/parser.h>
>  #include <linux/seq_file.h>
> @@ -652,6 +653,24 @@ static struct p9_req_t *p9_client_prepare_req(struct p9_client *c,
>  	return ERR_PTR(err);
>  }
>  
> +static int p9_sigpending(void)
> +{
> +	int sigpending = 0;
> +
> +	if (signal_pending(current)) {
> +		if (test_thread_flag(TIF_NOTIFY_SIGNAL))
> +			clear_notify_signal();
> +		if (task_work_pending(current))
> +			task_work_run();
> +		if (signal_pending(current)) {
> +			sigpending = 1;
> +			clear_thread_flag(TIF_SIGPENDING);
> +		}
> +	}
> +
> +	return sigpending;
> +}
> +
>  /**
>   * p9_client_rpc - issue a request and wait for a response
>   * @c: client session
> @@ -687,12 +706,7 @@ p9_client_rpc(struct p9_client *c, int8_t type, const char *fmt, ...)
>  	req->tc.zc = false;
>  	req->rc.zc = false;
>  
> -	if (signal_pending(current)) {
> -		sigpending = 1;
> -		clear_thread_flag(TIF_SIGPENDING);
> -	} else {
> -		sigpending = 0;
> -	}
> +	sigpending = p9_sigpending();
>  
>  	err = c->trans_mod->request(c, req);
>  	if (err < 0) {
> @@ -789,12 +803,7 @@ static struct p9_req_t *p9_client_zc_rpc(struct p9_client *c, int8_t type,
>  	req->tc.zc = true;
>  	req->rc.zc = true;
>  
> -	if (signal_pending(current)) {
> -		sigpending = 1;
> -		clear_thread_flag(TIF_SIGPENDING);
> -	} else {
> -		sigpending = 0;
> -	}
> +	sigpending = p9_sigpending();
>  
>  	err = c->trans_mod->zc_request(c, req, uidata, uodata,
>  				       inlen, olen, in_hdrlen);
> 
> -- 
> Jens Axboe
>