2022-09-23 19:45:33

by Maciej W. Rozycki

[permalink] [raw]
Subject: [PATCH] parport_pc: Avoid FIFO port location truncation

Match the data type of a temporary holding a reference to the FIFO port
with the type of the original reference coming from `struct parport',
avoiding data truncation with LP64 ports such as SPARC64 that refer to
PCI port I/O locations via their corresponding MMIO addresses and will
therefore have non-zero bits in the high 32-bit part of the reference.
And in any case it is cleaner to have the data types matching here.

Signed-off-by: Maciej W. Rozycki <[email protected]>
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Link: https://lore.kernel.org/linux-pci/20220419033752.GA1101844@bhelgaas/
---
Hi,

Found by code inspection in tracking down the cause of an oops; cf.
<https://lore.kernel.org/lkml/[email protected]/>.
Credit to Bjorn for the details of the SPARC64 peculiarity.

I guess nobody has actually ever used a PCI parallel port with a SPARC64
machine, so it's probably not worth backporting, but I have chosen to add
a `Fixes' tag regardless for tracking, statistics, or whatever it might be
useful for, even though the offending temporary has been added long before
our GIT history (with or around Linux 2.3.10 AFAICT).

Maciej
---
drivers/parport/parport_pc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

linux-parport-pc-fifo-unsigned-long.diff
Index: linux-macro/drivers/parport/parport_pc.c
===================================================================
--- linux-macro.orig/drivers/parport/parport_pc.c
+++ linux-macro/drivers/parport/parport_pc.c
@@ -468,7 +468,7 @@ static size_t parport_pc_fifo_write_bloc
const unsigned char *bufp = buf;
size_t left = length;
unsigned long expire = jiffies + port->physport->cad->timeout;
- const int fifo = FIFO(port);
+ const unsigned long fifo = FIFO(port);
int poll_for = 8; /* 80 usecs */
const struct parport_pc_private *priv = port->physport->private_data;
const int fifo_depth = priv->fifo_depth;


2022-10-03 11:24:07

by Sudip Mukherjee

[permalink] [raw]
Subject: Re: [PATCH] parport_pc: Avoid FIFO port location truncation

On Fri, Sep 23, 2022 at 7:52 PM Maciej W. Rozycki <[email protected]> wrote:
>
> Match the data type of a temporary holding a reference to the FIFO port
> with the type of the original reference coming from `struct parport',
> avoiding data truncation with LP64 ports such as SPARC64 that refer to
> PCI port I/O locations via their corresponding MMIO addresses and will
> therefore have non-zero bits in the high 32-bit part of the reference.
> And in any case it is cleaner to have the data types matching here.
>
> Signed-off-by: Maciej W. Rozycki <[email protected]>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Link: https://lore.kernel.org/linux-pci/20220419033752.GA1101844@bhelgaas/

Thanks for the patch Maciej.

Acked-by: Sudip Mukherjee <[email protected]>

Greg, can you please add it to your tree. I know I am late and the
merge window is now open.


--
Regards
Sudip

2022-10-03 14:24:27

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH] parport_pc: Avoid FIFO port location truncation

On Mon, Oct 03, 2022 at 12:19:14PM +0100, Sudip Mukherjee wrote:
> On Fri, Sep 23, 2022 at 7:52 PM Maciej W. Rozycki <[email protected]> wrote:
> >
> > Match the data type of a temporary holding a reference to the FIFO port
> > with the type of the original reference coming from `struct parport',
> > avoiding data truncation with LP64 ports such as SPARC64 that refer to
> > PCI port I/O locations via their corresponding MMIO addresses and will
> > therefore have non-zero bits in the high 32-bit part of the reference.
> > And in any case it is cleaner to have the data types matching here.
> >
> > Signed-off-by: Maciej W. Rozycki <[email protected]>
> > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> > Link: https://lore.kernel.org/linux-pci/20220419033752.GA1101844@bhelgaas/
>
> Thanks for the patch Maciej.
>
> Acked-by: Sudip Mukherjee <[email protected]>
>
> Greg, can you please add it to your tree. I know I am late and the
> merge window is now open.

Will have to wait until 6.1-rc1 is out, I'll take it then, thanks.

greg k-h