Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37;
Date:   Wed, 4 Oct 2023 08:04:15 +0200
From:   Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To:     Lee Jones <lee@kernel.org>
Cc:     linux-kernel@vger.kernel.org,
        Daniel Starke <daniel.starke@siemens.com>,
        Fedor Pchelkin <pchelkin@ispras.ru>,
        Jiri Slaby <jirislaby@kernel.org>,
        linux-serial@vger.kernel.org,
        syzbot+5f47a8cea6a12b77a876@syzkaller.appspotmail.com
Subject: Re: [PATCH 1/1] tty: n_gsm: Avoid sleeping during .write() whilst
 atomic
Message-ID: <2023100457-entail-freefall-06fd@gregkh>
References: <20231003170020.830242-1-lee@kernel.org>
 <2023100320-immorally-outboard-573a@gregkh>
 <20231003185500.GD8453@google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20231003185500.GD8453@google.com>
Precedence: bulk

On Tue, Oct 03, 2023 at 07:55:00PM +0100, Lee Jones wrote:
> On Tue, 03 Oct 2023, Greg Kroah-Hartman wrote:
> 
> > On Tue, Oct 03, 2023 at 06:00:20PM +0100, Lee Jones wrote:
> > > The important part of the call stack being:
> > > 
> > >   gsmld_write()             # Takes a lock and disables IRQs
> > >     con_write()
> > >       console_lock()
> > 
> > Wait, why is the n_gsm line discipline being used for a console?
> > 
> > What hardware/protocol wants this to happen?
> > 
> > gsm I thought was for a very specific type of device, not a console.
> > 
> > As per:
> > 	https://www.kernel.org/doc/html/v5.9/driver-api/serial/n_gsm.html
> > this is a specific modem protocol, why is con_write() being called?
> 
> What it's meant for and what random users can make it do are likely to
> be quite separate questions.  This scenario is user driven and can be
> replicated simply by issuing a few syscalls (open, ioctl, write).

I would recommend that any distro/system that does not want to support
this specific hardware protocol, just disable it for now (it's marked as
experimental too), if they don't want to deal with the potential
sleep-while-atomic issue.

> > And Lee, you really don't have this hardware, right?  So why are you
> > dealing with bug reports for it?  :)
> 
> 'cos Syzkaller.

Ah, yeah, fake report, no real issue here then :)

thanks,

greg k-h