Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1287359 > unrolled thread

[patch RESEND] atp870u: 64 bit bug in atp885_init()

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [patch RESEND] atp870u: 64 bit bug in atp885_init() Dan Carpenter <dan.carpenter@oracle.com> - 2015-12-09 11:30 +0100
    Re: [patch RESEND] atp870u: 64 bit bug in atp885_init() One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2015-12-09 13:00 +0100
      Re: [patch RESEND] atp870u: 64 bit bug in atp885_init() Ondrej Zary <linux@rainbow-software.org> - 2015-12-09 13:10 +0100
      Re: [patch RESEND] atp870u: 64 bit bug in atp885_init() Dan Carpenter <dan.carpenter@oracle.com> - 2015-12-09 14:50 +0100
        Re: [patch RESEND] atp870u: 64 bit bug in atp885_init() One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2015-12-09 15:20 +0100
          Re: [patch RESEND] atp870u: 64 bit bug in atp885_init() Dan Carpenter <dan.carpenter@oracle.com> - 2015-12-09 18:50 +0100
            Re: [patch RESEND] atp870u: 64 bit bug in atp885_init() Julia Lawall <julia.lawall@lip6.fr> - 2015-12-09 19:20 +0100
              Re: [patch RESEND] atp870u: 64 bit bug in atp885_init() Dan Carpenter <dan.carpenter@oracle.com> - 2015-12-09 19:30 +0100
                Re: [patch RESEND] atp870u: 64 bit bug in atp885_init() One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2015-12-09 20:40 +0100

#1287359 — [patch RESEND] atp870u: 64 bit bug in atp885_init()

On 64 bit CPUs there is a memory corruption bug on probe().  It should
be a u32 pointer instead of an unsigned long pointer or we write past
the end of the setupdata[] array.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
---
Resending because we have shuffled the code around so the patch needed
to be refreshed against linux-next.  Although I do wonder why we are
still working on this code since it has never worked on 64 bit systems
so probably all the users gave up a decade ago.

diff --git a/drivers/scsi/atp870u.c b/drivers/scsi/atp870u.c
index 8b52a9d..b46997c 100644
--- a/drivers/scsi/atp870u.c
+++ b/drivers/scsi/atp870u.c
@@ -1413,11 +1413,11 @@ static void atp885_init(struct Scsi_Host *shpnt)
 			atpdev->global_map[m] = 0;
 			for (k = 0; k < 4; k++) {
 				atp_writew_base(atpdev, 0x3c, n++);
-				((unsigned long *)&setupdata[m][0])[k] = atp_readl_base(atpdev, 0x38);
+				((u32 *)&setupdata[m][0])[k] = atp_readl_base(atpdev, 0x38);
 			}
 			for (k = 0; k < 4; k++) {
 				atp_writew_base(atpdev, 0x3c, n++);
-				((unsigned long *)&atpdev->sp[m][0])[k] = atp_readl_base(atpdev, 0x38);
+				((u32 *)&atpdev->sp[m][0])[k] = atp_readl_base(atpdev, 0x38);
 			}
 			n += 8;
 		}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1287443

On Wed, 9 Dec 2015 13:24:53 +0300
Dan Carpenter <dan.carpenter@oracle.com> wrote:

> On 64 bit CPUs there is a memory corruption bug on probe().  It should
> be a u32 pointer instead of an unsigned long pointer or we write past
> the end of the setupdata[] array.
> 
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> Reviewed-by: Hannes Reinecke <hare@suse.com>
> ---
> Resending because we have shuffled the code around so the patch needed
> to be refreshed against linux-next.  Although I do wonder why we are
> still working on this code since it has never worked on 64 bit systems
> so probably all the users gave up a decade ago.

So this is untested ? If so please make it very clear in the commit
message because the kernel is IMHO getting too full of polished, neat,
recently modified, never tested, never used code.

I agree it would be better if the driver was simply deleted. I've not
even seen an ATP870 bug report in years.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1287448

On Wednesday 09 December 2015 12:53:39 One Thousand Gnomes wrote:
> On Wed, 9 Dec 2015 13:24:53 +0300
> Dan Carpenter <dan.carpenter@oracle.com> wrote:
> 
> > On 64 bit CPUs there is a memory corruption bug on probe().  It should
> > be a u32 pointer instead of an unsigned long pointer or we write past
> > the end of the setupdata[] array.
> > 
> > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> > Reviewed-by: Hannes Reinecke <hare@suse.com>
> > ---
> > Resending because we have shuffled the code around so the patch needed
> > to be refreshed against linux-next.  Although I do wonder why we are
> > still working on this code since it has never worked on 64 bit systems
> > so probably all the users gave up a decade ago.
> 
> So this is untested ? If so please make it very clear in the commit
> message because the kernel is IMHO getting too full of polished, neat,
> recently modified, never tested, never used code.
> 
> I agree it would be better if the driver was simply deleted. I've not
> even seen an ATP870 bug report in years.

Maybe because it worked. Although the code was horrible. I've done some big changes to this driver recently (tested, of course).
I can't test this patch as I don't have ATP885 card, only ATP870.

-- 
Ondrej Zary
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1287506

Everyone knows I didn't test it but it's an obvious one line fix for
memory corruption.  If no one uses the code, at least this is harmless
and silences a static checker warning.

In olden times we used to say, "Oh this bounds checking is crap but it's
root only so let's leave it alone."  But these days we just fix it.
It's easier to just fix everything instead of trying to decide which
bugs are critical.

regards,
dan carpenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1287518

On Wed, 9 Dec 2015 16:45:12 +0300
Dan Carpenter <dan.carpenter@oracle.com> wrote:

> Everyone knows I didn't test it but it's an obvious one line fix for
> memory corruption.  If no one uses the code, at least this is harmless
> and silences a static checker warning.
> 
> In olden times we used to say, "Oh this bounds checking is crap but it's
> root only so let's leave it alone."  But these days we just fix it.
> It's easier to just fix everything instead of trying to decide which
> bugs are critical.

Unfortunately it's all too easy to look down 50 commit messages to an
apaprently active file all "fixing small bugs" or "correcting indenting"
without realising that every single one of them should have been tagged

"[UNTESTED]: "

so that anyone looking at the code can see immediately its historical
hazardous waste.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1287688

We should add a tag to indicate that we are sending a patch for a crappy
driver.

IMHO-this-driver-is-garbage: Your Name <email>

If it got 10 votes of no confidence it would be moved to staging and
then deleted.

Anyway, realistically, let's just apply this fix.  It's tempting to
think we could delete all atp885 related code, but maybe people are
still using it with 32 bit kernels.  Or someone could delete it, but I'm
not brave enough to be the one to do it.

regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1287707

On Wed, 9 Dec 2015, Dan Carpenter wrote:

> We should add a tag to indicate that we are sending a patch for a crappy
> driver.
>
> IMHO-this-driver-is-garbage: Your Name <email>
>
> If it got 10 votes of no confidence it would be moved to staging and
> then deleted.

Forgive my ignorance, but what is the exact procedure?  For example, the
following file: drivers/pcmcia/vrc4173_cardu.c contains the following
code: INIT_WORK(&socket->tq_work, cardu_bh, socket);.  The last time
INIT_WORK took three arguments was Linux 2.6.19, so I think no one has
been compiling this code recently.  There would be the .c file and the
associated .h file to move to staging, but it's less clear to me eg what
to do with the Kconfig entry and the Makefile entry.  And is there
anything else to take into account?

thanks,
julia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1287729

On Wed, Dec 09, 2015 at 07:11:15PM +0100, Julia Lawall wrote:
> Forgive my ignorance, but what is the exact procedure?  For example, the
> following file: drivers/pcmcia/vrc4173_cardu.c contains the following
> code: INIT_WORK(&socket->tq_work, cardu_bh, socket);.  The last time
> INIT_WORK took three arguments was Linux 2.6.19, so I think no one has
> been compiling this code recently.  There would be the .c file and the
> associated .h file to move to staging, but it's less clear to me eg what
> to do with the Kconfig entry and the Makefile entry.  And is there
> anything else to take into account?

You should just delete that code along with the Kconfig and Makefile
entries.  Don't bother moving it to staging.  The move to staging is
supposed to give people one last chance to yell if they absolutely need
the code.  No one has compiled this code for years so no one will miss
it.

regards,
dan carpenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1287777

> You should just delete that code along with the Kconfig and Makefile
> entries.  Don't bother moving it to staging.  The move to staging is
> supposed to give people one last chance to yell if they absolutely need
> the code.  No one has compiled this code for years so no one will miss
> it.

And for stuff which might be worth saving (eg something that looks rather
broken but has possibly got users) the driver goes into staging
in its own directory and the Makefile and Kconfig entry for it move into
the staging directory with the hope that someone screams and maintains it.

Alan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web