linux-kernel - Re: [PATCH] serial: 8250: Clear port->pm on port specific driver unbind

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

Date:   Fri, 14 Apr 2023 10:35:31 +0300 (EEST)
From:   Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
To:     Tony Lindgren <tony@...mide.com>
cc:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jirislaby@...nel.org>,
        Johan Hovold <johan@...nel.org>,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Vignesh Raghavendra <vigneshr@...com>,
        linux-omap@...r.kernel.org,
        linux-serial <linux-serial@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] serial: 8250: Clear port->pm on port specific driver
 unbind

On Fri, 14 Apr 2023, Tony Lindgren wrote:

> * Andy Shevchenko <andriy.shevchenko@...ux.intel.com> [230413 16:06]:
> > On Thu, Apr 13, 2023 at 10:03:41AM +0300, Tony Lindgren wrote:
> > > Let's fix the issue by clearing port->pm in serial8250_unregister_port().
> > 
> > Sounds to me like a fix that needs a Fixes tag.
> 
> Maybe commit c161afe9759d ("8250: allow platforms to override PM hook.").
> 
> That's a bit unclear though as the hardware specific functions were
> available at that point as they were passed in platform data. This can
> be seen with git blame c161afe9759d drivers/serial/8250.c. To me it seems
> the port->pm became potentially invalid if a serial port device driver
> started implementing PM runtime?
> 
> Maybe just tagging it with Cc: stable is better if no obvious Fixes tag
> can be figured out.

I'd just put that c161afe9759d there. It seems quite harmless even if it 
would be unnecessary before some driver commit which is much harder to 
pinpoint (and it would likely turn out old enough to not matter anyway 
for the kernels stable cares about).

I forgot to give this earlier:

Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>

-- 
 i.