public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Arnd Bergmann <arnd@kernel.org>
Cc: "Guenter Roeck" <linux@roeck-us.net>,
	"Niklas Schnelle" <schnelle@linux.ibm.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Jiri Slaby" <jirislaby@kernel.org>,
	"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
	linux-serial@vger.kernel.org,
	"Heiko Carstens" <hca@linux.ibm.com>,
	linux-kernel@vger.kernel.org,
	"Yang Yingliang" <yangyingliang@huawei.com>
Subject: Re: [PATCH 1/1] tty: serial: handle HAS_IOPORT dependencies
Date: Mon, 25 Nov 2024 13:26:35 +0200	[thread overview]
Message-ID: <Z0Re61Tk5lN2Xuxi@smile.fi.intel.com> (raw)
In-Reply-To: <be43108e-4135-4927-ba58-141836fde6af@app.fastmail.com>

On Mon, Nov 25, 2024 at 12:06:16PM +0100, Arnd Bergmann wrote:
> On Mon, Nov 25, 2024, at 11:33, Andy Shevchenko wrote:
> > On Mon, Nov 25, 2024 at 10:53:46AM +0100, Arnd Bergmann wrote:
> >> 
> >> This does however revert f4c23a140d80 ("serial: 8250:
> >> fix null-ptr-deref in serial8250_start_tx()") and
> >> might bring back the bug came from opening an
> >> uninitialized uart. On the other hand, I don't see
> >> why that doesn't also crash from accessing the invalid
> >> I/O port on the same architectures.
> >
> > AFAICS it does only partial revert, so I don't see how your patch
> > may break that.
> 
> I think it's a complete revert, it's just not entirely obvious
> since serial8250_setup_port() got split out by 9d86719f8769
> ("serial: 8250: Allow using ports higher than
> SERIAL_8250_RUNTIME_UARTS") and the original callsite got
> moved by your ffd8e8bd26e9 ("serial: 8250: Extract platform
> driver").

Ah, okay.

> What I suspect is going on with the f4c23a140d80 commit
> is the same bug I mentioned earlier in this thread, where
> __serial8250_isa_init_ports() just always registers
> 'nr_uarts' (CONFIG_SERIAL_8250_RUNTIME_UARTS) ports,
> unlike any other serial driver.

But the configuration can give less than old_serial_port contains.
See dozens of the explicit settings in the defconfigs.

> This used to be required before 9d86719f8769 ("serial:
> 8250: Allow using ports higher than SERIAL_8250_RUNTIME_UARTS"),
> but I don't see why this is still a thing now, other than
> for using setserial on i486-class PCs with nonstandard ISA
> ports.
> 
> On non-x86 machines, it only ever seems to create extra
> ports that are likely to crash the system if opened, either
> because they lack proper serial_in/serial_out callbacks,
> or because the default UPIO_PORT callbacks end up poking
> unmapped memory.
> 
> Do you see any reason why we can't just do the version below?

Perhaps we may do this way (it seems better to me than previous suggestions),
but it also needs to be carefully checked against those configurations that set
it explicitly.

...

If we go this way, it would be also nice to add a comment explaining that
this is module parameter (as it's done for those ones above).

> +unsigned int nr_uarts = ARRAY_SIZE(old_serial_port);;

...

>  	/*
> -	 * Set up initial ISA ports based on nr_uart module param, or else
> -	 * default to CONFIG_SERIAL_8250_RUNTIME_UARTS. Note that we do not
> -	 * need to increase nr_uarts when setting up the initial ISA ports.

> +	 * Set up initial ISA ports based on nr_uart module param. Note that 

Just in case it has a trailing whitespace.

> +	 * we do not need to increase nr_uarts when setting up the initial
> +	 * ISA ports.
>  	 */

-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2024-11-25 11:26 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-05 15:29 [PATCH 0/1] tty: Handle HAS_IOPORT dependencies Niklas Schnelle
2024-04-05 15:29 ` [PATCH 1/1] tty: serial: handle " Niklas Schnelle
2024-04-08  9:54   ` Ilpo Järvinen
2024-04-08 10:17     ` Arnd Bergmann
2024-04-08 10:25       ` Ilpo Järvinen
2024-10-01  9:04       ` Niklas Schnelle
2024-04-08 15:35     ` Niklas Schnelle
2024-04-08 15:41       ` Ilpo Järvinen
2024-04-08 15:50         ` Arnd Bergmann
2024-05-23  2:11   ` Maciej W. Rozycki
2024-10-01 11:21     ` Niklas Schnelle
2024-10-01 15:31       ` Arnd Bergmann
2024-10-01 16:41       ` Maciej W. Rozycki
2024-10-02 12:44         ` Niklas Schnelle
2024-10-02 18:12           ` Maciej W. Rozycki
2024-10-02 22:00             ` Arnd Bergmann
2024-10-02 22:59               ` Maciej W. Rozycki
2024-10-04  6:53                 ` Arnd Bergmann
2024-10-04 16:24                   ` Maciej W. Rozycki
2024-10-04 16:57                     ` Arnd Bergmann
2024-10-04 10:09                 ` Niklas Schnelle
2024-10-04 12:48                   ` Arnd Bergmann
2024-10-04 16:03                     ` Niklas Schnelle
2024-10-04 14:44                   ` Niklas Schnelle
2024-10-04 16:34                   ` Maciej W. Rozycki
2024-11-22 15:18   ` Guenter Roeck
2024-11-22 15:35     ` Niklas Schnelle
2024-11-22 16:31       ` Arnd Bergmann
2024-11-22 17:22         ` Guenter Roeck
2024-11-22 19:24           ` Arnd Bergmann
2024-11-22 20:44             ` Guenter Roeck
2024-11-22 22:51               ` Arnd Bergmann
2024-11-23  2:14                 ` Guenter Roeck
2024-11-25  7:55             ` Andy Shevchenko
2024-11-25  9:53               ` Arnd Bergmann
2024-11-25 10:33                 ` Andy Shevchenko
2024-11-25 11:06                   ` Arnd Bergmann
2024-11-25 11:26                     ` Andy Shevchenko [this message]
2024-11-25 13:50                       ` Arnd Bergmann
2024-11-25 15:42                         ` Andy Shevchenko
2024-11-25 16:54                         ` Maciej W. Rozycki
2024-11-25 17:54                           ` Arnd Bergmann
2024-11-25 18:42                             ` Maciej W. Rozycki
2024-12-04 18:51                             ` Guenter Roeck
2024-11-25 15:59                     ` Arnd Bergmann
2024-12-04 21:09                       ` Guenter Roeck
2024-12-04 22:17                         ` Arnd Bergmann
2024-12-04 22:44                           ` Guenter Roeck
2024-12-05  7:08                             ` Arnd Bergmann
2024-12-05 14:31                               ` Guenter Roeck
2024-12-06 15:44                           ` Andy Shevchenko
2024-12-06 16:02                             ` Arnd Bergmann
2025-01-16 12:26                               ` Andy Shevchenko
2024-11-22 17:07       ` Guenter Roeck
2024-11-22 23:27         ` Niklas Schnelle
2024-11-22 23:34         ` Niklas Schnelle
2024-11-23  9:21           ` Arnd Bergmann
2024-04-05 22:33 ` [PATCH 0/1] tty: Handle " Andy Shevchenko
2024-04-06  8:06   ` Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z0Re61Tk5lN2Xuxi@smile.fi.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=arnd@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hca@linux.ibm.com \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=jirislaby@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=schnelle@linux.ibm.com \
    --cc=yangyingliang@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox