Linus,
Please pull the latest x86-fixes-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git x86-fixes-for-linus
You'll get a conflict in arch/x86/include/asm/uv/uv_hub.h (you merged a v1
version of the patch from email - the conflicts are trivial, please pick my
version).
Thanks,
Ingo
---
arch/x86/boot/compressed/Makefile | 1 +
arch/x86/include/asm/uv/uv_hub.h | 86 ++++++++++++++++++++----------------
arch/x86/kernel/amd_iommu_init.c | 10 ++++
arch/x86/kernel/apic/x2apic_uv_x.c | 12 +++---
arch/x86/kernel/process.c | 4 +-
arch/x86/kernel/process_32.c | 14 +++---
arch/x86/kernel/process_64.c | 24 +++++-----
arch/x86/mm/kmemcheck/error.c | 19 ++++----
arch/x86/tools/chkobjdump.awk | 16 +++++-
drivers/char/agp/amd64-agp.c | 9 ++--
lib/dma-debug.c | 5 ++
11 files changed, 118 insertions(+), 82 deletions(-)
FUJITA Tomonori (1):
x86/agp: Fix agp_amd64_init() initialization with CONFIG_GART_IOMMU enabled
H. Peter Anvin (1):
x86, compress: Force i386 instructions for the decompressor
Ingo Molnar (1):
Merge branch 'iommu/fixes' of git://git.kernel.org/.../joro/linux-2.6-iommu into x86/urgent
Joerg Roedel (2):
x86/amd-iommu: Fix initialization failure panic
Merge branches 'dma-debug/fixes' and 'amd-iommu/fixes' into iommu/fixes
Masami Hiramatsu (1):
x86: Fix objdump version check in chkobjdump.awk for different formats.
Mike Travis (1):
x86: SGI UV: Fix writes to led registers on remote uv hubs
Pekka Enberg (2):
x86: Use KERN_DEFAULT log-level in __show_regs()
x86, kmemcheck: Use KERN_WARNING for error reporting
Shaun Ruffell (1):
dma-debug: Do not add notifier when dma debugging is disabled.
On Thu, Dec 31, 2009 at 01:03:22PM +0100, Ingo Molnar wrote:
> Shaun Ruffell (1):
>
> dma-debug: Do not add notifier when dma debugging is disabled.
Looks like that last one breaks powerpc allyesconfig builds:
http://marc.info/?l=linux-next&m=126221673819746&w=2
--
Regards/Gruss,
Boris.
* Borislav Petkov <[email protected]> wrote:
> On Thu, Dec 31, 2009 at 01:03:22PM +0100, Ingo Molnar wrote:
> > Shaun Ruffell (1):
> >
> > dma-debug: Do not add notifier when dma debugging is disabled.
>
> Looks like that last one breaks powerpc allyesconfig builds:
>
> http://marc.info/?l=linux-next&m=126221673819746&w=2
It's a build warning, not a broken build. Updated (v2) pull request below,
with the fix for this. [diffstat manually constructed - i hope i got that
right.]
Thanks and a happy new year,
Ingo
Linus,
Please pull the latest x86-fixes-for-linus-2 git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git x86-fixes-for-linus-2
Thanks,
Ingo
------------------>
arch/x86/boot/compressed/Makefile | 1 +
arch/x86/include/asm/uv/uv_hub.h | 74 ++++++++++++++++--------------------
arch/x86/kernel/amd_iommu_init.c | 10 +++++
arch/x86/kernel/process.c | 4 +-
arch/x86/kernel/process_32.c | 14 +++---
arch/x86/kernel/process_64.c | 24 ++++++------
arch/x86/mm/kmemcheck/error.c | 19 ++++-----
arch/x86/tools/chkobjdump.awk | 16 ++++++-
drivers/char/agp/amd64-agp.c | 9 ++--
lib/dma-debug.c | 8 +++-
10 files changed, 98 insertions(+), 81 deletions(-)
FUJITA Tomonori (1):
x86/agp: Fix agp_amd64_init() initialization with CONFIG_GART_IOMMU enabled
H. Peter Anvin (1):
x86, compress: Force i386 instructions for the decompressor
Ingo Molnar (1):
dma-debug: Fix bug causing build warning
Joerg Roedel (1):
x86/amd-iommu: Fix initialization failure panic
Masami Hiramatsu (1):
x86: Fix objdump version check in chkobjdump.awk for different formats.
Mike Travis (1):
x86: SGI UV: Fix writes to led registers on remote uv hubs
Pekka Enberg (2):
x86: Use KERN_DEFAULT log-level in __show_regs()
x86, kmemcheck: Use KERN_WARNING for error reporting
Shaun Ruffell (1):
dma-debug: Do not add notifier when dma debugging is disabled.
Commit-ID: a8fe9ea200ea21421ea750423d1d4d4f7ce037cf
Gitweb: http://git.kernel.org/tip/a8fe9ea200ea21421ea750423d1d4d4f7ce037cf
Author: Ingo Molnar <[email protected]>
AuthorDate: Thu, 31 Dec 2009 15:16:23 +0100
Committer: Ingo Molnar <[email protected]>
CommitDate: Thu, 31 Dec 2009 15:16:23 +0100
dma-debug: Fix bug causing build warning
Stephen Rothwell reported the following build warning:
lib/dma-debug.c: In function 'dma_debug_device_change':
lib/dma-debug.c:680: warning: 'return' with no value, in function returning non-void
Introduced by commit f797d9881b62c2ddb1d2e7bd80d87141949c84aa
("dma-debug: Do not add notifier when dma debugging is disabled").
Return 0 [notify-done] when disabled. (this is standard bus notifier behavior.)
Signed-off-by: Shaun Ruffell <[email protected]>
Signed-off-by: Joerg Roedel <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
---
lib/dma-debug.c | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/lib/dma-debug.c b/lib/dma-debug.c
index 7399744..cf90620 100644
--- a/lib/dma-debug.c
+++ b/lib/dma-debug.c
@@ -670,14 +670,13 @@ static int device_dma_allocations(struct device *dev)
return count;
}
-static int dma_debug_device_change(struct notifier_block *nb,
- unsigned long action, void *data)
+static int dma_debug_device_change(struct notifier_block *nb, unsigned long action, void *data)
{
struct device *dev = data;
int count;
if (global_disable)
- return;
+ return 0;
switch (action) {
case BUS_NOTIFY_UNBOUND_DRIVER:
On Thu, Dec 31, 2009 at 02:31:08PM +0000, tip-bot for Ingo Molnar wrote:
> Stephen Rothwell reported the following build warning:
>
> lib/dma-debug.c: In function 'dma_debug_device_change':
> lib/dma-debug.c:680: warning: 'return' with no value, in function returning non-void
>
> Introduced by commit f797d9881b62c2ddb1d2e7bd80d87141949c84aa
> ("dma-debug: Do not add notifier when dma debugging is disabled").
Oops, sorry. Stupid mistake :-(
Joerg
On Sat, 16 Jan 2010, Ingo Molnar wrote:
>
> Cyrill Gorcunov (1):
> x86: kernel_thread() -- initialize SS to a known state
This looks bogus. Why does it do it only on x86-64?
Either people care about SS or they don't (the answer, I suspect, is "they
don't"). But if they care, we should do it on both 32-bit _and_ 64-bit,
no?
Linus
On Sat, Jan 16, 2010 at 12:34:42PM -0800, Linus Torvalds wrote:
>
>
> On Sat, 16 Jan 2010, Ingo Molnar wrote:
> >
> > Cyrill Gorcunov (1):
> > x86: kernel_thread() -- initialize SS to a known state
>
> This looks bogus. Why does it do it only on x86-64?
>
> Either people care about SS or they don't (the answer, I suspect, is "they
> don't"). But if they care, we should do it on both 32-bit _and_ 64-bit,
> no?
>
> Linus
Linus, this is Xen specific. There was a Xen related series sent by Ian,
and seems we still need this patch together with get_kernel_rpl() (as I understand,
I'm not familiar with Xen code, that was a suspicious about SS as it's said
in commit message). So Ian mentioned
|
| > Yeah, I didn't found any explicit %ss reloading for this _particular_
| > case (as I marked in patch changelog). So the only suspicious is Xen
| > itself. So as only Christian get ability to test -- we will see the
| > results.
|
| The difference with Xen is that it must squash the RPL of SS (to 3 for
| 64 bit and 1 for 32 bit, 32 bit doesn't matter here though). Perhaps a
| NULL selector can only have RPL==0? (I'm away from my architecture docs
| so I can't check). In any case specifying a non-NULL SS selector allows
| the squashing to occur correctly.
|
In turn reported said that only _this_ patch alone doesn't help him and
Ian replied we need both patches.
Ian CC'ed if details needed.
-- Cyrill
On 01/16/2010 12:34 PM, Linus Torvalds wrote:
>
>
> On Sat, 16 Jan 2010, Ingo Molnar wrote:
>>
>> Cyrill Gorcunov (1):
>> x86: kernel_thread() -- initialize SS to a known state
>
> This looks bogus. Why does it do it only on x86-64?
>
> Either people care about SS or they don't (the answer, I suspect, is "they
> don't"). But if they care, we should do it on both 32-bit _and_ 64-bit,
> no?
>
It is bogus -- it's basically Xen braindamage.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
On 01/16/2010 01:06 PM, H. Peter Anvin wrote:
> On 01/16/2010 12:34 PM, Linus Torvalds wrote:
>>
>>
>> On Sat, 16 Jan 2010, Ingo Molnar wrote:
>>>
>>> Cyrill Gorcunov (1):
>>> x86: kernel_thread() -- initialize SS to a known state
>>
>> This looks bogus. Why does it do it only on x86-64?
>>
>> Either people care about SS or they don't (the answer, I suspect, is "they
>> don't"). But if they care, we should do it on both 32-bit _and_ 64-bit,
>> no?
>>
>
> It is bogus -- it's basically Xen braindamage.
>
As to why make it x86-64 only... it matches what the old assembly code
did. We figured that that was the lowest risk option for unbreaking Xen.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
On Sat, 2010-01-16 at 23:53 +0300, Cyrill Gorcunov wrote:
> On Sat, Jan 16, 2010 at 12:34:42PM -0800, Linus Torvalds wrote:
> >
> >
> > On Sat, 16 Jan 2010, Ingo Molnar wrote:
> > >
> > > Cyrill Gorcunov (1):
> > > x86: kernel_thread() -- initialize SS to a known state
> >
> > This looks bogus. Why does it do it only on x86-64?
> >
> > Either people care about SS or they don't (the answer, I suspect, is "they
> > don't"). But if they care, we should do it on both 32-bit _and_ 64-bit,
> > no?
> >
> > Linus
>
> Linus, this is Xen specific. There was a Xen related series sent by Ian,
> and seems we still need this patch together with get_kernel_rpl() (as I understand,
> I'm not familiar with Xen code, that was a suspicious about SS as it's said
> in commit message). So Ian mentioned
>
> |
> | > Yeah, I didn't found any explicit %ss reloading for this _particular_
> | > case (as I marked in patch changelog). So the only suspicious is Xen
> | > itself. So as only Christian get ability to test -- we will see the
> | > results.
> |
> | The difference with Xen is that it must squash the RPL of SS (to 3 for
> | 64 bit and 1 for 32 bit, 32 bit doesn't matter here though). Perhaps a
> | NULL selector can only have RPL==0? (I'm away from my architecture docs
> | so I can't check). In any case specifying a non-NULL SS selector allows
> | the squashing to occur correctly.
> |
>
> In turn reported said that only _this_ patch alone doesn't help him and
> Ian replied we need both patches.
>
> Ian CC'ed if details needed.
Thanks, I think you've covered or quoted everything.
Although I think Linus' basic point is still valid -- why isn't a valid
SS needed for 32 bit? The selectors have real meaning there even for
native, don't they?
(I'm travelling all tomorrow and unlikely to be getting mail).
Ian.
--
Ian Campbell
It is always the best policy to tell the truth, unless, of course,
you are an exceptionally good liar.
-- Jerome K. Jerome
On Sat, Jan 16, 2010 at 09:16:56PM +0000, Ian Campbell wrote:
...
> > |
> > | > Yeah, I didn't found any explicit %ss reloading for this _particular_
> > | > case (as I marked in patch changelog). So the only suspicious is Xen
> > | > itself. So as only Christian get ability to test -- we will see the
> > | > results.
> > |
> > | The difference with Xen is that it must squash the RPL of SS (to 3 for
> > | 64 bit and 1 for 32 bit, 32 bit doesn't matter here though). Perhaps a
> > | NULL selector can only have RPL==0? (I'm away from my architecture docs
> > | so I can't check). In any case specifying a non-NULL SS selector allows
> > | the squashing to occur correctly.
> > |
> >
> > In turn reported said that only _this_ patch alone doesn't help him and
> > Ian replied we need both patches.
> >
> > Ian CC'ed if details needed.
>
> Thanks, I think you've covered or quoted everything.
>
> Although I think Linus' basic point is still valid -- why isn't a valid
> SS needed for 32 bit? The selectors have real meaning there even for
> native, don't they?
>
Well, the point was (I suppose) why we've started to set SS selector here
at all. It's due to Xen. Old code was doing so, and that happened Xen is
relating on it (as you actually said).
Also this is kernel thread which is supposed to execute in kernel space.
And kernel itself already set SS selector when it needs. So to eliminate
redunant operations we don't set SS here. And if there was not such
issue on a Xen side -- we would not set SS here as well.
Again, to be fair I just don't have rights to blame Xen here -- I rely on your
and Christian reports only.
> (I'm travelling all tomorrow and unlikely to be getting mail).
>
> Ian.
>
-- Cyrill
On Sat, Jan 16, 2010 at 3:34 PM, Linus Torvalds
<[email protected]> wrote:
>
>
> On Sat, 16 Jan 2010, Ingo Molnar wrote:
>>
>> Cyrill Gorcunov (1):
>> x86: kernel_thread() -- initialize SS to a known state
>
> This looks bogus. Why does it do it only on x86-64?
>
> Either people care about SS or they don't (the answer, I suspect, is "they
> don't"). But if they care, we should do it on both 32-bit _and_ 64-bit,
> no?
32-bit doesn't care about ss or esp since it won't pop them from the
stack when returning to the same privilege level.
--
Brian Gerst
On 01/16/2010 01:16 PM, Ian Campbell wrote:
>
> Although I think Linus' basic point is still valid -- why isn't a valid
> SS needed for 32 bit? The selectors have real meaning there even for
> native, don't they?
>
No, they aren't used for native for either 32 or 64 bits.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
On Sat, 2010-01-16 at 19:18 -0500, Brian Gerst wrote:
> On Sat, Jan 16, 2010 at 3:34 PM, Linus Torvalds
> <[email protected]> wrote:
> >
> >
> > On Sat, 16 Jan 2010, Ingo Molnar wrote:
> >>
> >> Cyrill Gorcunov (1):
> >> x86: kernel_thread() -- initialize SS to a known state
> >
> > This looks bogus. Why does it do it only on x86-64?
> >
> > Either people care about SS or they don't (the answer, I suspect, is "they
> > don't"). But if they care, we should do it on both 32-bit _and_ 64-bit,
> > no?
>
> 32-bit doesn't care about ss or esp since it won't pop them from the
> stack when returning to the same privilege level.
Right! That's the bit of behaviour I wasn't thinking of.
Thanks, Ian.
--
Ian Campbell
Under every stone lurks a politician.
-- Aristophanes