From: walter harms <wharms@bfs.de>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
x86@kernel.org, Russ Anderson <rja@sgi.com>,
linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org
Subject: Re: [patch v2] x86, UV: integer wrap bug in uv_hub_ipi_value()
Date: Sun, 02 Dec 2012 15:33:59 +0000 [thread overview]
Message-ID: <50BB74E7.9060306@bfs.de> (raw)
In-Reply-To: <20121202104438.GD16078@elgon.mountain>
Am 02.12.2012 11:44, schrieb Dan Carpenter:
> This is a static checker fix. The problem is that we store the bits
> from "uv_apicid_hibits" into "apicid" (the high 16 bits) but then we
> shift it 16 bit to the left. "apicid" is an int so it wraps and we lose
> them.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> ---
> v2: Style fix. Don't use ulong.
>
> I don't have this hardware so I can't test it. There may also be other
> bugs which this patch does not addressed. These files are only compiled
> on x86_64 and "unsigned long" is used throughout to mean 64 bits.
>
> diff --git a/arch/x86/include/asm/uv/uv_hub.h b/arch/x86/include/asm/uv/uv_hub.h
> index 21f7385..e7a83d5 100644
> --- a/arch/x86/include/asm/uv/uv_hub.h
> +++ b/arch/x86/include/asm/uv/uv_hub.h
> @@ -577,7 +577,7 @@ static unsigned long uv_hub_ipi_value(int apicid, int vector, int mode)
> {
> apicid |= uv_apicid_hibits;
> return (1UL << UVH_IPI_INT_SEND_SHFT) |
> - ((apicid) << UVH_IPI_INT_APIC_ID_SHFT) |
> + ((unsigned long)apicid << UVH_IPI_INT_APIC_ID_SHFT) |
> (mode << UVH_IPI_INT_DELIVERY_MODE_SHFT) |
> (vector << UVH_IPI_INT_VECTOR_SHFT);
> }
> diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c b/arch/x86/kernel/apic/x2apic_uv_x.c
> index 8cfade9..6d93b2f 100644
> --- a/arch/x86/kernel/apic/x2apic_uv_x.c
> +++ b/arch/x86/kernel/apic/x2apic_uv_x.c
> @@ -194,13 +194,13 @@ static int __cpuinit uv_wakeup_secondary(int phys_apicid, unsigned long start_ri
> pnode = uv_apicid_to_pnode(phys_apicid);
> phys_apicid |= uv_apicid_hibits;
> val = (1UL << UVH_IPI_INT_SEND_SHFT) |
> - (phys_apicid << UVH_IPI_INT_APIC_ID_SHFT) |
> + ((unsigned long)phys_apicid << UVH_IPI_INT_APIC_ID_SHFT) |
> ((start_rip << UVH_IPI_INT_VECTOR_SHFT) >> 12) |
> APIC_DM_INIT;
> uv_write_global_mmr64(pnode, UVH_IPI_INT, val);
>
> val = (1UL << UVH_IPI_INT_SEND_SHFT) |
> - (phys_apicid << UVH_IPI_INT_APIC_ID_SHFT) |
> + ((unsigned long)phys_apicid << UVH_IPI_INT_APIC_ID_SHFT) |
> ((start_rip << UVH_IPI_INT_VECTOR_SHFT) >> 12) |
> APIC_DM_STARTUP;
> uv_write_global_mmr64(pnode, UVH_IPI_INT, val);
making this more readable is hard but what is about:
val=(1UL << UVH_IPI_INT_SEND_SHFT) |
((unsigned long)phys_apicid << UVH_IPI_INT_APIC_ID_SHFT) |
((start_rip << UVH_IPI_INT_VECTOR_SHFT) >> 12);
uv_write_global_mmr64(pnode, UVH_IPI_INT, val|APIC_DM_INIT);
uv_write_global_mmr64(pnode, UVH_IPI_INT, val|APIC_DM_STARTUP);
just my 2 cents,
re
wh
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
WARNING: multiple messages have this Message-ID (diff)
From: walter harms <wharms@bfs.de>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
x86@kernel.org, Russ Anderson <rja@sgi.com>,
linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org
Subject: Re: [patch v2] x86, UV: integer wrap bug in uv_hub_ipi_value()
Date: Sun, 02 Dec 2012 16:33:59 +0100 [thread overview]
Message-ID: <50BB74E7.9060306@bfs.de> (raw)
In-Reply-To: <20121202104438.GD16078@elgon.mountain>
Am 02.12.2012 11:44, schrieb Dan Carpenter:
> This is a static checker fix. The problem is that we store the bits
> from "uv_apicid_hibits" into "apicid" (the high 16 bits) but then we
> shift it 16 bit to the left. "apicid" is an int so it wraps and we lose
> them.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> ---
> v2: Style fix. Don't use ulong.
>
> I don't have this hardware so I can't test it. There may also be other
> bugs which this patch does not addressed. These files are only compiled
> on x86_64 and "unsigned long" is used throughout to mean 64 bits.
>
> diff --git a/arch/x86/include/asm/uv/uv_hub.h b/arch/x86/include/asm/uv/uv_hub.h
> index 21f7385..e7a83d5 100644
> --- a/arch/x86/include/asm/uv/uv_hub.h
> +++ b/arch/x86/include/asm/uv/uv_hub.h
> @@ -577,7 +577,7 @@ static unsigned long uv_hub_ipi_value(int apicid, int vector, int mode)
> {
> apicid |= uv_apicid_hibits;
> return (1UL << UVH_IPI_INT_SEND_SHFT) |
> - ((apicid) << UVH_IPI_INT_APIC_ID_SHFT) |
> + ((unsigned long)apicid << UVH_IPI_INT_APIC_ID_SHFT) |
> (mode << UVH_IPI_INT_DELIVERY_MODE_SHFT) |
> (vector << UVH_IPI_INT_VECTOR_SHFT);
> }
> diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c b/arch/x86/kernel/apic/x2apic_uv_x.c
> index 8cfade9..6d93b2f 100644
> --- a/arch/x86/kernel/apic/x2apic_uv_x.c
> +++ b/arch/x86/kernel/apic/x2apic_uv_x.c
> @@ -194,13 +194,13 @@ static int __cpuinit uv_wakeup_secondary(int phys_apicid, unsigned long start_ri
> pnode = uv_apicid_to_pnode(phys_apicid);
> phys_apicid |= uv_apicid_hibits;
> val = (1UL << UVH_IPI_INT_SEND_SHFT) |
> - (phys_apicid << UVH_IPI_INT_APIC_ID_SHFT) |
> + ((unsigned long)phys_apicid << UVH_IPI_INT_APIC_ID_SHFT) |
> ((start_rip << UVH_IPI_INT_VECTOR_SHFT) >> 12) |
> APIC_DM_INIT;
> uv_write_global_mmr64(pnode, UVH_IPI_INT, val);
>
> val = (1UL << UVH_IPI_INT_SEND_SHFT) |
> - (phys_apicid << UVH_IPI_INT_APIC_ID_SHFT) |
> + ((unsigned long)phys_apicid << UVH_IPI_INT_APIC_ID_SHFT) |
> ((start_rip << UVH_IPI_INT_VECTOR_SHFT) >> 12) |
> APIC_DM_STARTUP;
> uv_write_global_mmr64(pnode, UVH_IPI_INT, val);
making this more readable is hard but what is about:
val=(1UL << UVH_IPI_INT_SEND_SHFT) |
((unsigned long)phys_apicid << UVH_IPI_INT_APIC_ID_SHFT) |
((start_rip << UVH_IPI_INT_VECTOR_SHFT) >> 12);
uv_write_global_mmr64(pnode, UVH_IPI_INT, val|APIC_DM_INIT);
uv_write_global_mmr64(pnode, UVH_IPI_INT, val|APIC_DM_STARTUP);
just my 2 cents,
re
wh
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
next prev parent reply other threads:[~2012-12-02 15:33 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-17 15:16 [patch] x86, UV: integer wrap bug in uv_hub_ipi_value() Dan Carpenter
2012-11-17 15:16 ` Dan Carpenter
2012-11-20 0:48 ` Russ Anderson
2012-11-20 0:48 ` Russ Anderson
2012-11-20 4:28 ` Dan Carpenter
2012-11-20 4:28 ` Dan Carpenter
2012-11-20 4:55 ` H. Peter Anvin
2012-11-20 4:55 ` H. Peter Anvin
2012-11-20 11:10 ` Alan Cox
2012-11-20 16:27 ` Russ Anderson
2012-11-20 16:27 ` Russ Anderson
2012-11-20 17:09 ` H. Peter Anvin
2012-11-20 17:09 ` H. Peter Anvin
2012-11-20 17:07 ` Russ Anderson
2012-11-20 17:07 ` Russ Anderson
2012-11-21 7:39 ` Dan Carpenter
2012-11-21 7:39 ` Dan Carpenter
2012-12-02 10:44 ` [patch v2] " Dan Carpenter
2012-12-02 10:44 ` Dan Carpenter
2012-12-02 15:33 ` walter harms [this message]
2012-12-02 15:33 ` walter harms
2012-12-02 17:28 ` [patch v3] " Dan Carpenter
2012-12-02 17:28 ` Dan Carpenter
2012-12-02 17:35 ` Dan Carpenter
2012-12-02 17:35 ` Dan Carpenter
2012-12-03 7:58 ` [patch v4] " Dan Carpenter
2012-12-03 7:58 ` Dan Carpenter
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=50BB74E7.9060306@bfs.de \
--to=wharms@bfs.de \
--cc=dan.carpenter@oracle.com \
--cc=hpa@zytor.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=rja@sgi.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.