[PATCH] parport_pc: Avoid FIFO port location truncation

[PATCH] parport_pc: Avoid FIFO port location truncation

[Maciej W. Rozycki]

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 <macro@orcam.me.uk>
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/alpine.DEB.2.21.2209220223080.29493@angie.orcam.me.uk/>.  
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;

Re: [PATCH] parport_pc: Avoid FIFO port location truncation

[Sudip Mukherjee]

On Fri, Sep 23, 2022 at 7:52 PM Maciej W. Rozycki <macro@orcam.me.uk> 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 <macro@orcam.me.uk>
> 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 <sudipm.mukherjee@gmail.com>

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


-- 
Regards
Sudip

Re: [PATCH] parport_pc: Avoid FIFO port location truncation

[Greg Kroah-Hartman]

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 <macro@orcam.me.uk> 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 <macro@orcam.me.uk>
> > 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 <sudipm.mukherjee@gmail.com>
> 
> 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