* Re: linux-next: build failure after merge of the nfs tree
From: Trond Myklebust @ 2010-10-21 14:33 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Bryan Schumaker
In-Reply-To: <20101021113858.f8b9849f.sfr@canb.auug.org.au>
On Thu, 2010-10-21 at 11:38 +1100, Stephen Rothwell wrote:
> Hi Trond,
>
> After merging the nfs tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> fs/nfs/dir.c: In function 'nfs_readdir_free_large_page':
> fs/nfs/dir.c:475: error: implicit declaration of function 'vm_unmap_ram'
> fs/nfs/dir.c: In function 'nfs_readdir_large_page':
> fs/nfs/dir.c:496: error: implicit declaration of function 'vm_map_ram'
> fs/nfs/dir.c:496: warning: assignment makes pointer from integer without a cast
>
> Caused by commit b8aa6064474e186f598584508f9230d49a0004af ("NFS: readdir
> with vmapped pages"). Forgot to include linux/vmalloc.h. See Rule 1 (in
> Documentation/SubmitChecklist).
>
> I have used the nfs tree from next-20101020 for today.
Thanks Stephen! Fixed in my linux-next branch.
Bryan, please make sure that you update your patches.
Cheers
Trond
^ permalink raw reply
* Re: linux-next: User Mode Linux broken
From: Thomas Gleixner @ 2010-10-21 16:09 UTC (permalink / raw)
To: Richard Weinberger
Cc: peterz, hpa, mingo, linux-kernel@vger.kernel.org, linux-next
In-Reply-To: <201010211315.26679.richard@nod.at>
On Thu, 21 Oct 2010, Richard Weinberger wrote:
> Thomas,
>
> Your commit c5f7563 ("genirq: Provide compat handling for chip->enable()")
> breaks UML.
> It does not start anymore.
>
> When I apply this patch it works fine again.
> http://userweb.kernel.org/~akpm/mmotm/broken-out/um-migrate-from-__do_irq-to-
> generic_handle_irq.patch
>
> Maybe your patch breaks all users of __do_IRQ()?
Not intentionally :)
The irq_chip of um has it's own dummy enable function, so the compat
code uses it.
+static void compat_irq_enable(struct irq_data *data)
+{
+ data->chip->enable(data->irq);
+}
+
...
+ if (chip->enable)
+ chip->irq_enable = compat_irq_enable;
+
+ /*
+ * The real defaults
+ */
+ if (!chip->irq_enable)
+ chip->irq_enable = default_enable;
So I really can't see how's that supposed to break UM
Thanks,
tglx
^ permalink raw reply
* Re: linux-next: Tree for October 21 (xen)
From: Randy Dunlap @ 2010-10-21 16:13 UTC (permalink / raw)
To: Stephen Rothwell, xen-devel, Konrad Rzeszutek Wilk; +Cc: linux-next, LKML
In-Reply-To: <20101021151529.392fecea.sfr@canb.auug.org.au>
On Thu, 21 Oct 2010 15:15:29 +1100 Stephen Rothwell wrote:
> Hi all,
>
> Reminder: do not add 2.6.38 destined stuff to linux-next until after
> 2.6.37-rc1 is released.
>
> Changes since 20101020:
When CONFIG_SMP is not enabled:
arch/x86/pci/xen.c:401: error: 'nr_ioapics' undeclared (first use in this function)
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: linux-next: Tree for October 21 (xen)
From: Konrad Rzeszutek Wilk @ 2010-10-21 16:32 UTC (permalink / raw)
To: Randy Dunlap, stefano.stabellini
Cc: Stephen Rothwell, xen-devel, linux-next, LKML
In-Reply-To: <20101021091316.0587c1a8.randy.dunlap@oracle.com>
On Thu, Oct 21, 2010 at 09:13:16AM -0700, Randy Dunlap wrote:
> On Thu, 21 Oct 2010 15:15:29 +1100 Stephen Rothwell wrote:
>
> > Hi all,
> >
> > Reminder: do not add 2.6.38 destined stuff to linux-next until after
> > 2.6.37-rc1 is released.
> >
> > Changes since 20101020:
>
>
> When CONFIG_SMP is not enabled:
>
> arch/x86/pci/xen.c:401: error: 'nr_ioapics' undeclared (first use in this function)
Thank you,
Stefano, this one is yours.
^ permalink raw reply
* Re: linux-next: Tree for October 21 (xen)
From: Stefano Stabellini @ 2010-10-21 16:53 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Randy Dunlap, Stefano Stabellini, Stephen Rothwell,
xen-devel@lists.xensource.com, linux-next@vger.kernel.org, LKML
In-Reply-To: <20101021163225.GA2456@dumpdata.com>
On Thu, 21 Oct 2010, Konrad Rzeszutek Wilk wrote:
> On Thu, Oct 21, 2010 at 09:13:16AM -0700, Randy Dunlap wrote:
> > On Thu, 21 Oct 2010 15:15:29 +1100 Stephen Rothwell wrote:
> >
> > > Hi all,
> > >
> > > Reminder: do not add 2.6.38 destined stuff to linux-next until after
> > > 2.6.37-rc1 is released.
> > >
> > > Changes since 20101020:
> >
> >
> > When CONFIG_SMP is not enabled:
> >
> > arch/x86/pci/xen.c:401: error: 'nr_ioapics' undeclared (first use in this function)
>
> Thank you,
>
> Stefano, this one is yours.
>
Yep.
It was a missing #include in arch/x86/pci/xen.c, I fixed it adding a
commit to my linux-next branch.
---
commit fa4c2e29e4a30dc3e9d3f83944eeea63f78350a5
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu Oct 21 17:40:08 2010 +0100
xen: add a missing #include to arch/x86/pci/xen.c
Add missing #include <asm/io_apic.h> to arch/x86/pci/xen.c.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index 4f5df3d..4a32df2 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -10,6 +10,7 @@
#include <linux/acpi.h>
#include <linux/io.h>
+#include <asm/io_apic.h>
#include <asm/pci_x86.h>
#include <asm/xen/hypervisor.h>
^ permalink raw reply related
* Re: linux-next: build warning after merge of the devicetree tree
From: Grant Likely @ 2010-10-21 17:04 UTC (permalink / raw)
To: Ingo Molnar
Cc: Stephen Rothwell, linux-next, linux-kernel, Andres Salomon,
Andrew Morton
In-Reply-To: <20101021080526.GB8775@elte.hu>
On Thu, Oct 21, 2010 at 10:05:26AM +0200, Ingo Molnar wrote:
> > On Thu, Oct 21, 2010 at 01:37:26PM +1100, Stephen Rothwell wrote:
> > diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c
> > index 4417f49..23216f7 100644
> > --- a/arch/x86/kernel/irq.c
> > +++ b/arch/x86/kernel/irq.c
> > @@ -276,12 +276,14 @@ void smp_x86_platform_ipi(struct pt_regs *regs)
> >
> > EXPORT_SYMBOL_GPL(vector_used_by_percpu_irq);
> >
> > +#ifdef CONFIG_OF
> > unsigned int irq_create_of_mapping(struct device_node *controller,
> > const u32 *intspec, unsigned int intsize)
> > {
> > return intspec[0];
> > }
> > EXPORT_SYMBOL_GPL(irq_create_of_mapping);
> > +#endif
>
> Sigh, 'of' is the most misnamed Linux subsystem in history! 'CONFIG_OF_' always
> makes me ask 'config of what?' irq_create_of_mapping ditto.
>
> Why not OFW or OPENFIRMWARE?
That's not the half of it. Most of the new platforms using this code
don't have openfirmware either. This subsystem merely supports the
device tree data structure which originated with OpenFirmware, but has
been used heavily in non-ofw systems for many years now. Something
like dt_* would be more accurate.
The of_ prefixes are entirely historical. Off and on I consider doing
a mass rename, but I shy away from the scope of the work (plus nobody
has complained loud enough to make it a priority). If I were to do
such a thing it would probably be best to use a script to handle all
the renames, and I'd want to organize with Linus to get it committed
when it will have the least impact on everyone. Probably
immediately after a merge window closes.
BTW, I'm actually dropping the patch that added this function to x86
for this merge window since the patch that uses it isn't quite ready
yet. It will sit in my test tree for another cycle.
g.
^ permalink raw reply
* Re: linux-next: Tree for October 21 (xen)
From: Randy Dunlap @ 2010-10-21 17:13 UTC (permalink / raw)
To: Stefano Stabellini
Cc: Konrad Rzeszutek Wilk, Stephen Rothwell,
xen-devel@lists.xensource.com, linux-next@vger.kernel.org, LKML
In-Reply-To: <alpine.DEB.2.00.1010211738530.10348@kaball-desktop>
On 10/21/10 09:53, Stefano Stabellini wrote:
> On Thu, 21 Oct 2010, Konrad Rzeszutek Wilk wrote:
>> On Thu, Oct 21, 2010 at 09:13:16AM -0700, Randy Dunlap wrote:
>>> On Thu, 21 Oct 2010 15:15:29 +1100 Stephen Rothwell wrote:
>>>
>>>> Hi all,
>>>>
>>>> Reminder: do not add 2.6.38 destined stuff to linux-next until after
>>>> 2.6.37-rc1 is released.
>>>>
>>>> Changes since 20101020:
>>>
>>>
>>> When CONFIG_SMP is not enabled:
>>>
>>> arch/x86/pci/xen.c:401: error: 'nr_ioapics' undeclared (first use in this function)
>>
>> Thank you,
>>
>> Stefano, this one is yours.
>>
>
> Yep.
> It was a missing #include in arch/x86/pci/xen.c, I fixed it adding a
> commit to my linux-next branch.
Ack. Thanks.
> ---
>
> commit fa4c2e29e4a30dc3e9d3f83944eeea63f78350a5
> Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Date: Thu Oct 21 17:40:08 2010 +0100
>
> xen: add a missing #include to arch/x86/pci/xen.c
>
> Add missing #include <asm/io_apic.h> to arch/x86/pci/xen.c.
>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>
> diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
> index 4f5df3d..4a32df2 100644
> --- a/arch/x86/pci/xen.c
> +++ b/arch/x86/pci/xen.c
> @@ -10,6 +10,7 @@
> #include <linux/acpi.h>
>
> #include <linux/io.h>
> +#include <asm/io_apic.h>
> #include <asm/pci_x86.h>
>
> #include <asm/xen/hypervisor.h>
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: linux-next: User Mode Linux broken
From: Richard Weinberger @ 2010-10-21 19:22 UTC (permalink / raw)
To: Thomas Gleixner
Cc: peterz, hpa, mingo, linux-kernel@vger.kernel.org, linux-next
In-Reply-To: <alpine.LFD.2.00.1010211805040.2418@localhost6.localdomain6>
Am Donnerstag 21 Oktober 2010, 18:09:22 schrieb Thomas Gleixner:
> On Thu, 21 Oct 2010, Richard Weinberger wrote:
> > Thomas,
> >
> > Your commit c5f7563 ("genirq: Provide compat handling for
> > chip->enable()") breaks UML.
> > It does not start anymore.
> >
> > When I apply this patch it works fine again.
> > http://userweb.kernel.org/~akpm/mmotm/broken-out/um-migrate-from-__do_irq
> > -to- generic_handle_irq.patch
> >
> > Maybe your patch breaks all users of __do_IRQ()?
>
> Not intentionally :)
>
> The irq_chip of um has it's own dummy enable function, so the compat
> code uses it.
>
> +static void compat_irq_enable(struct irq_data *data)
> +{
> + data->chip->enable(data->irq);
> +}
> +
>
> ...
>
> + if (chip->enable)
> + chip->irq_enable = compat_irq_enable;
> +
> + /*
> + * The real defaults
> + */
> + if (!chip->irq_enable)
> + chip->irq_enable = default_enable;
>
> So I really can't see how's that supposed to break UM
>
This patch solves the issue for me.
What do you think?
Thanks,
//richard
diff --git a/kernel/irq/resend.c b/kernel/irq/resend.c
index 891115a..1fb4012 100644
--- a/kernel/irq/resend.c
+++ b/kernel/irq/resend.c
@@ -60,8 +60,11 @@ void check_irq_resend(struct irq_desc *desc, unsigned int
irq)
/*
* Make sure the interrupt is enabled, before resending it:
*/
+#ifndef CONFIG_GENERIC_HARDIRQS_NO_DEPRECATED
+ desc->irq_data.chip->enable(irq);
+#elif
desc->irq_data.chip->irq_enable(&desc->irq_data);
-
+#endif
/*
* We do not resend level type interrupts. Level type
* interrupts are resent by hardware when they are still
^ permalink raw reply related
* Re: linux-next: User Mode Linux broken
From: Thomas Gleixner @ 2010-10-21 19:45 UTC (permalink / raw)
To: Richard Weinberger
Cc: peterz, hpa, mingo, linux-kernel@vger.kernel.org, linux-next
In-Reply-To: <201010212122.38437.richard@nod.at>
On Thu, 21 Oct 2010, Richard Weinberger wrote:
> Am Donnerstag 21 Oktober 2010, 18:09:22 schrieb Thomas Gleixner:
> > On Thu, 21 Oct 2010, Richard Weinberger wrote:
> > > Thomas,
> > >
> > > Your commit c5f7563 ("genirq: Provide compat handling for
> > > chip->enable()") breaks UML.
> > > It does not start anymore.
> > >
> > > When I apply this patch it works fine again.
> > > http://userweb.kernel.org/~akpm/mmotm/broken-out/um-migrate-from-__do_irq
> > > -to- generic_handle_irq.patch
> > >
> > > Maybe your patch breaks all users of __do_IRQ()?
> >
> > Not intentionally :)
> >
> > The irq_chip of um has it's own dummy enable function, so the compat
> > code uses it.
> >
> > +static void compat_irq_enable(struct irq_data *data)
> > +{
> > + data->chip->enable(data->irq);
> > +}
> > +
> >
> > ...
> >
> > + if (chip->enable)
> > + chip->irq_enable = compat_irq_enable;
> > +
> > + /*
> > + * The real defaults
> > + */
> > + if (!chip->irq_enable)
> > + chip->irq_enable = default_enable;
> >
> > So I really can't see how's that supposed to break UM
> >
>
> This patch solves the issue for me.
> What do you think?
>
> Thanks,
> //richard
>
> diff --git a/kernel/irq/resend.c b/kernel/irq/resend.c
> index 891115a..1fb4012 100644
> --- a/kernel/irq/resend.c
> +++ b/kernel/irq/resend.c
> @@ -60,8 +60,11 @@ void check_irq_resend(struct irq_desc *desc, unsigned int
> irq)
> /*
> * Make sure the interrupt is enabled, before resending it:
> */
> +#ifndef CONFIG_GENERIC_HARDIRQS_NO_DEPRECATED
> + desc->irq_data.chip->enable(irq);
> +#elif
> desc->irq_data.chip->irq_enable(&desc->irq_data);
> -
> +#endif
> /*
> * We do not resend level type interrupts. Level type
> * interrupts are resent by hardware when they are still
Why shold it solve it ? irq_enable is set to compat_irq_enable which
in turn calls chip->enable.
So how's that different ?
Thanks,
tglx
^ permalink raw reply
* Re: linux-next: User Mode Linux broken
From: Richard Weinberger @ 2010-10-21 20:27 UTC (permalink / raw)
To: Thomas Gleixner
Cc: peterz, hpa, mingo, linux-kernel@vger.kernel.org, linux-next
In-Reply-To: <alpine.LFD.2.00.1010212143300.3467@localhost6.localdomain6>
Am Donnerstag 21 Oktober 2010, 21:45:35 schrieb Thomas Gleixner:
> On Thu, 21 Oct 2010, Richard Weinberger wrote:
> > Am Donnerstag 21 Oktober 2010, 18:09:22 schrieb Thomas Gleixner:
> > > On Thu, 21 Oct 2010, Richard Weinberger wrote:
> > > > Thomas,
> > > >
> > > > Your commit c5f7563 ("genirq: Provide compat handling for
> > > > chip->enable()") breaks UML.
> > > > It does not start anymore.
> > > >
> > > > When I apply this patch it works fine again.
> > > > http://userweb.kernel.org/~akpm/mmotm/broken-out/um-migrate-from-__do
> > > > _irq -to- generic_handle_irq.patch
> > > >
> > > > Maybe your patch breaks all users of __do_IRQ()?
> > >
> > > Not intentionally :)
> > >
> > > The irq_chip of um has it's own dummy enable function, so the compat
> > > code uses it.
> > >
> > > +static void compat_irq_enable(struct irq_data *data)
> > > +{
> > > + data->chip->enable(data->irq);
> > > +}
> > > +
> > >
> > > ...
> > >
> > > + if (chip->enable)
> > > + chip->irq_enable = compat_irq_enable;
> > > +
> > > + /*
> > > + * The real defaults
> > > + */
> > > + if (!chip->irq_enable)
> > > + chip->irq_enable = default_enable;
> > >
> > > So I really can't see how's that supposed to break UM
> >
> > This patch solves the issue for me.
> > What do you think?
> >
> > Thanks,
> > //richard
> >
> > diff --git a/kernel/irq/resend.c b/kernel/irq/resend.c
> > index 891115a..1fb4012 100644
> > --- a/kernel/irq/resend.c
> > +++ b/kernel/irq/resend.c
> > @@ -60,8 +60,11 @@ void check_irq_resend(struct irq_desc *desc, unsigned
> > int irq)
> >
> > /*
> >
> > * Make sure the interrupt is enabled, before resending it:
> > */
> >
> > +#ifndef CONFIG_GENERIC_HARDIRQS_NO_DEPRECATED
> > + desc->irq_data.chip->enable(irq);
> > +#elif
> >
> > desc->irq_data.chip->irq_enable(&desc->irq_data);
> >
> > -
> > +#endif
> >
> > /*
> >
> > * We do not resend level type interrupts. Level type
> > * interrupts are resent by hardware when they are still
>
> Why shold it solve it ? irq_enable is set to compat_irq_enable which
> in turn calls chip->enable.
>
> So how's that different ?
I took a closer look on the issue.
check_irq_resend() gets called before irq_chip_set_defaults().
In the first call to check_irq_resend() desc->irq_data.chip->irq_enable is
NULL. UML dies due to a NULL-pointer dereference...
I don't know why check_irq_resend() is called before irq_chip_set_defaults().
It's your code. ;-)
Thanks,
//richard
^ permalink raw reply
* Re: [Xen-devel] linux-next: build warning after merge of the final tree (xen tree related)
From: Jeremy Fitzhardinge @ 2010-10-21 21:39 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Xen Devel, linux-next, linux-kernel
In-Reply-To: <20101021145326.9f133f40.sfr@canb.auug.org.au>
On 10/20/2010 08:53 PM, Stephen Rothwell wrote:
> Hi Jeremy,
>
> After merging the final tree, today's linux-next build (i386 defconfig)
> produced this warning:
>
> arch/x86/mm/fault.c: In function 'vmalloc_sync_all':
> arch/x86/mm/fault.c:244: warning: assignment makes integer from pointer without a cast
>
> Introduced by commit aef8b70e5c4b7753fc4bf20dbb01e93fc8883027 ("x86: hold
> mm->page_table_lock while doing vmalloc_sync").
This change got merged into tip/master, and it looks like there's
already a fix there for this warning. I've dropped it from my branch.
Thanks,
J
^ permalink raw reply
* linux-next: manual merge of the net tree with Linus' tree
From: Stephen Rothwell @ 2010-10-22 1:19 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Koki Sanagi, Frederic Weisbecker,
Jesse Gross
Hi all,
Today's linux-next merge of the net tree got a conflict in net/core/dev.c
between commit cf66ba58b5cb8b1526e9dd2fb96ff8db048d4d44 ("netdev: Add
tracepoints to netdev layer") from Linus' tree and commits
05532121da0728eaedac2a0a5c3cecad3a95d765 ("net: 802.1q: make
vlan_hwaccel_do_receive() return void") and
3701e51382a026cba10c60b03efabe534fba4ca4 ("vlan: Centralize handling of
hardware acceleration") from the net tree.
Just context changes. I fixed it up (see below) and can carry the fix as
necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc net/core/dev.c
index 154e25e,6d4218c..0000000
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@@ -128,9 -128,8 +128,10 @@@
#include <linux/jhash.h>
#include <linux/random.h>
#include <trace/events/napi.h>
+#include <trace/events/net.h>
+#include <trace/events/skb.h>
#include <linux/pci.h>
+ #include <linux/inetdevice.h>
#include "net-sysfs.h"
@@@ -2835,10 -2898,6 +2905,8 @@@ static int __netif_receive_skb(struct s
if (!netdev_tstamp_prequeue)
net_timestamp_check(skb);
+ trace_netif_receive_skb(skb);
- if (vlan_tx_tag_present(skb) && vlan_hwaccel_do_receive(skb))
- return NET_RX_SUCCESS;
+
/* if we've gotten here through NAPI, check netpoll */
if (netpoll_receive_skb(skb))
return NET_RX_DROP;
^ permalink raw reply
* linux-next: manual merge of the tip tree with Linus' tree
From: Stephen Rothwell @ 2010-10-22 2:08 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
Cc: linux-next, linux-kernel, Shaohua Li, Alexander van Heukelum
Hi all,
Today's linux-next merge of the tip tree got a conflict in
include/linux/percpu-defs.h between commit
c957ef2c59e952803766ddc22e89981ab534606f ("percpu: Introduce a
read-mostly percpu API") from Linus', tree and commit
fe8e0c25cad28e8858ecfa5863333c70685a6811 ("x86, 32-bit: Align percpu area
and irq stacks to THREAD_SIZE") from the tip tree.
Just overlapping additions. I fixed it up (see below) and can carry the
fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc include/linux/percpu-defs.h
index 27ef6b1,ab20d11..0000000
--- a/include/linux/percpu-defs.h
+++ b/include/linux/percpu-defs.h
@@@ -139,15 -139,18 +139,27 @@@
__aligned(PAGE_SIZE)
/*
+ * Declaration/definition used for per-CPU variables that must be read mostly.
+ */
+#define DECLARE_PER_CPU_READ_MOSTLY(type, name) \
+ DECLARE_PER_CPU_SECTION(type, name, "..readmostly")
+
+#define DEFINE_PER_CPU_READ_MOSTLY(type, name) \
+ DEFINE_PER_CPU_SECTION(type, name, "..readmostly")
+
+/*
+ * Declaration/definition used for large per-CPU variables that must be
+ * aligned to something larger than the pagesize.
+ */
+ #define DECLARE_PER_CPU_MULTIPAGE_ALIGNED(type, name, size) \
+ DECLARE_PER_CPU_SECTION(type, name, "..page_aligned") \
+ __aligned(size)
+
+ #define DEFINE_PER_CPU_MULTIPAGE_ALIGNED(type, name, size) \
+ DEFINE_PER_CPU_SECTION(type, name, "..page_aligned") \
+ __aligned(size)
+
+ /*
* Intermodule exports for per-CPU variables. sparse forgets about
* address space across EXPORT_SYMBOL(), change EXPORT_SYMBOL() to
* noop if __CHECKER__.
^ permalink raw reply
* linux-next: manual merge of the xen tree with the tip tree
From: Stephen Rothwell @ 2010-10-22 3:03 UTC (permalink / raw)
To: Jeremy Fitzhardinge, Xen Devel
Cc: linux-next, linux-kernel, Gianluca Guida, Yinghai Lu,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
[-- Attachment #1: Type: text/plain, Size: 720 bytes --]
Hi all,
Today's linux-next merge of the xen tree got a conflict in
arch/x86/mm/init_32.c between commit
1d931264af0f10649b35afa8fbd2e169da51ac08 ("x86-32, memblock: Make
add_highpages honor early reserved ranges") from the tip tree and commit
07147a06ac3b1b028124ea00ba44e69eb8ea7685 ("x86/32: honor reservations of
high memory") from the xen tree.
I have no idea how to fix this up, sorry, so I have used the xen tree
from next-20101021 for today.
There were also conflicts in:
arch/x86/xen/mmu.c
include/linux/early_res.h
kernel/early_res.c
These last two were deleted in the tip tree.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the xen tree with the tip tree
From: Stephen Rothwell @ 2010-10-22 3:36 UTC (permalink / raw)
To: Jeremy Fitzhardinge, Xen Devel
Cc: linux-next, linux-kernel, Gianluca Guida, Yinghai Lu,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
In-Reply-To: <20101022140335.c4a3a48f.sfr@canb.auug.org.au>
Hi Jeremy,
On Fri, 22 Oct 2010 14:03:35 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the xen tree got a conflict in
> arch/x86/mm/init_32.c between commit
> 1d931264af0f10649b35afa8fbd2e169da51ac08 ("x86-32, memblock: Make
> add_highpages honor early reserved ranges") from the tip tree and commit
> 07147a06ac3b1b028124ea00ba44e69eb8ea7685 ("x86/32: honor reservations of
> high memory") from the xen tree.
>
> I have no idea how to fix this up, sorry, so I have used the xen tree
> from next-20101021 for today.
It occurred to me that the conflicts might be useful to you, so here they
are:
diff --cc arch/x86/mm/init_32.c
index 5d0a671,573bc7f..0000000
--- a/arch/x86/mm/init_32.c
+++ b/arch/x86/mm/init_32.c
@@@ -423,28 -422,71 +423,78 @@@ static void __init add_one_highpage_ini
totalhigh_pages++;
}
-struct add_highpages_data {
- unsigned long start_pfn;
- unsigned long end_pfn;
-};
-
-static int __init add_highpages_work_fn(unsigned long start_pfn,
- unsigned long end_pfn, void *datax)
+void __init add_highpages_with_active_regions(int nid,
+ unsigned long start_pfn, unsigned long end_pfn)
{
++<<<<<<< HEAD
+ struct range *range;
+ int nr_range;
+ int i;
+
+ nr_range = __get_free_all_memory_range(&range, nid, start_pfn, end_pfn);
++=======
+ int node_pfn;
+ struct page *page;
+ phys_addr_t chunk_end, chunk_max;
+ unsigned long final_start_pfn, final_end_pfn;
+ struct add_highpages_data *data = (struct add_highpages_data *)datax;
++>>>>>>> xen
- final_start_pfn = max(start_pfn, data->start_pfn);
- final_end_pfn = min(end_pfn, data->end_pfn);
- if (final_start_pfn >= final_end_pfn)
- return 0;
+ for (i = 0; i < nr_range; i++) {
+ struct page *page;
+ int node_pfn;
++<<<<<<< HEAD
+ for (node_pfn = range[i].start; node_pfn < range[i].end;
+ node_pfn++) {
++=======
+ chunk_end = PFN_PHYS(final_start_pfn);
+ chunk_max = PFN_PHYS(final_end_pfn);
+
+ /*
+ * Check for reserved areas.
+ */
+ for (;;) {
+ phys_addr_t chunk_start;
+ chunk_start = early_res_next_free(chunk_end);
+
+ /*
+ * Reserved area. Just count high mem pages.
+ */
+ for (node_pfn = PFN_DOWN(chunk_end);
+ node_pfn < PFN_DOWN(chunk_start); node_pfn++) {
+ if (pfn_valid(node_pfn))
+ totalhigh_pages++;
+ }
+
+ if (chunk_start >= chunk_max)
+ break;
+
+ chunk_end = early_res_next_reserved(chunk_start, chunk_max);
+ for (node_pfn = PFN_DOWN(chunk_start);
+ node_pfn < PFN_DOWN(chunk_end); node_pfn++) {
++>>>>>>> xen
if (!pfn_valid(node_pfn))
continue;
page = pfn_to_page(node_pfn);
add_one_highpage_init(page);
}
}
-
- return 0;
-
}
++<<<<<<< HEAD
++=======
+
+ void __init add_highpages_with_active_regions(int nid, unsigned long start_pfn,
+ unsigned long end_pfn)
+ {
+ struct add_highpages_data data;
+
+ data.start_pfn = start_pfn;
+ data.end_pfn = end_pfn;
+ work_with_active_regions(nid, add_highpages_work_fn, &data);
+ }
+
++>>>>>>> xen
#else
static inline void permanent_kmaps_init(pgd_t *pgd_base)
{
diff --cc arch/x86/xen/mmu.c
index f72d18c,930986d..0000000
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@@ -56,7 -55,7 +56,11 @@@
#include <asm/e820.h>
#include <asm/linkage.h>
#include <asm/page.h>
++<<<<<<< HEAD
+#include <asm/init.h>
++=======
+ #include <asm/pat.h>
++>>>>>>> xen
#include <asm/xen/hypercall.h>
#include <asm/xen/hypervisor.h>
* Unmerged path include/linux/early_res.h
* Unmerged path kernel/early_res.c
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply
* Re: linux-next: manual merge of the xen tree with the tip tree
From: Yinghai Lu @ 2010-10-22 4:03 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Jeremy Fitzhardinge, Xen Devel, linux-next, linux-kernel,
Gianluca Guida, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra
In-Reply-To: <20101022143607.132d381c.sfr@canb.auug.org.au>
On 10/21/2010 08:36 PM, Stephen Rothwell wrote:
> Hi Jeremy,
>
> On Fri, 22 Oct 2010 14:03:35 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> Today's linux-next merge of the xen tree got a conflict in
>> arch/x86/mm/init_32.c between commit
>> 1d931264af0f10649b35afa8fbd2e169da51ac08 ("x86-32, memblock: Make
>> add_highpages honor early reserved ranges") from the tip tree and commit
>> 07147a06ac3b1b028124ea00ba44e69eb8ea7685 ("x86/32: honor reservations of
>> high memory") from the xen tree.
>>
>> I have no idea how to fix this up, sorry, so I have used the xen tree
>> from next-20101021 for today.
>
x86-32, memblock: Make add_highpages honor early reserved ranges
is updated version with memblock for
x86/32: honor reservations of high memory
Assume Jeremy would update the xen tree.
Thanks
Yinghai
^ permalink raw reply
* linux-next: Tree for October 22
From: Stephen Rothwell @ 2010-10-22 4:23 UTC (permalink / raw)
To: linux-next; +Cc: LKML
[-- Attachment #1: Type: text/plain, Size: 12511 bytes --]
Hi all,
Reminder: do not add 2.6.38 destined stuff to linux-next until after
2.6.37-rc1 is released.
Changes since 20101021:
The davinci tree lost its conflicts.
The nfs tree lost its build failure.
The v4l-dvb tree lost its build failure.
The net tree gained a conflict against Linus' tree.
The spi tree lost its conflicts.
The tip tree lost its conflicts, but gained another against Linus' tree.
The xen tree gained a complex conflict against the tip tree, so I used
the version from next-20101021.
----------------------------------------------------------------------------
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/v2.6/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log files
in the Next directory. Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc
and sparc64 defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary.
Below is a summary of the state of the merge.
We are up to 177 trees (counting Linus' and 22 trees of patches pending
for Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Randy Dunlap for doing many randconfig builds.
There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
$ git checkout master
$ git reset --hard stable
Merging origin/master
Merging fixes/fixes
Merging arm-current/master
Merging m68k-current/for-linus
Merging powerpc-merge/merge
Merging sparc-current/master
Merging scsi-rc-fixes/master
Merging net-current/master
Merging sound-current/for-linus
Merging pci-current/for-linus
Merging wireless-current/master
Merging kbuild-current/rc-fixes
Merging quilt/driver-core.current
Merging quilt/tty.current
Merging quilt/usb.current
Merging quilt/staging.current
Merging cpufreq-current/fixes
Merging input-current/for-linus
Merging md-current/for-linus
Merging audit-current/for-linus
Merging crypto-current/master
Merging ide-curent/master
Merging dwmw2/master
Merging gcl-current/merge
Merging arm/devel
Merging davinci/davinci-next
Merging i.MX/for-next
Merging msm/for-next
Merging omap/for-next
Merging pxa/for-next
Merging samsung/next-samsung
Merging s5p/for-next
Merging tegra/for-next
CONFLICT (content): Merge conflict in drivers/spi/Kconfig
CONFLICT (content): Merge conflict in drivers/spi/Makefile
Merging avr32/avr32-arch
Merging blackfin/for-linus
Merging cris/for-next
Merging ia64/test
Merging m68k/for-next
Merging m68knommu/for-next
Merging microblaze/next
Merging mips/mips-for-linux-next
Merging parisc/next
Merging powerpc/next
CONFLICT (content): Merge conflict in arch/powerpc/kernel/time.c
Merging 4xx/next
Merging 52xx-and-virtex/next
Merging galak/next
Merging s390/features
Merging sh/master
CONFLICT (content): Merge conflict in arch/sh/kernel/perf_event.c
Merging genesis/master
Merging sparc/master
Merging tile/master
Merging xtensa/master
CONFLICT (content): Merge conflict in arch/xtensa/configs/iss_defconfig
Merging ceph/for-next
Merging cifs/master
Merging configfs/linux-next
Merging ecryptfs/next
Merging ext3/for_next
Merging ext4/next
Merging fatfs/master
Merging fuse/for-next
Merging gfs2/master
Merging hfsplus/for-next
Merging jfs/next
Merging logfs/master
CONFLICT (content): Merge conflict in fs/logfs/logfs.h
Merging nfs/linux-next
Merging nfsd/nfsd-next
Merging nilfs2/for-next
Merging ocfs2/linux-next
Merging omfs/for-next
Merging squashfs/master
Merging udf/for_next
Merging v9fs/for-next
Merging ubifs/linux-next
Merging xfs/master
Merging vfs/for-next
Merging pci/linux-next
Merging hid/for-next
Merging quilt/i2c
Merging bjdooks-i2c/next-i2c
Merging quilt/jdelvare-hwmon
Merging hwmon-staging/hwmon-next
Merging quilt/kernel-doc
Merging v4l-dvb/master
Merging kbuild/for-next
Merging kconfig/for-next
Merging ide/master
Merging libata/NEXT
Merging infiniband/for-next
Merging acpi/test
Merging idle-test/idle-test
Merging ieee1394/for-next
Merging ubi/linux-next
Merging kvm/linux-next
CONFLICT (content): Merge conflict in drivers/s390/kvm/kvm_virtio.c
Merging dlm/next
Merging swiotlb/master
Merging ibft/master
Merging scsi/master
Merging async_tx/next
Merging net/master
CONFLICT (content): Merge conflict in Documentation/feature-removal-schedule.txt
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/board-zoom-peripherals.c
CONFLICT (delete/modify): drivers/ieee1394/eth1394.c deleted in HEAD and modified in net/master. Version net/master of drivers/ieee1394/eth1394.c left in tree.
CONFLICT (content): Merge conflict in drivers/net/pcmcia/smc91c92_cs.c
CONFLICT (content): Merge conflict in net/core/dev.c
$ git rm -f drivers/ieee1394/eth1394.c
Merging wireless/master
Merging bluetooth/master
Merging mtd/master
Merging crypto/master
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/devices.c
Merging sound/for-next
CONFLICT (content): Merge conflict in arch/arm/mach-s3c64xx/dev-audio.c
CONFLICT (content): Merge conflict in drivers/video/sh_mobile_hdmi.c
Merging sound-asoc/for-next
Merging cpufreq/next
Merging quilt/rr
Merging input/next
CONFLICT (content): Merge conflict in drivers/input/keyboard/Kconfig
Merging lsm/for-next
Merging block/for-next
CONFLICT (content): Merge conflict in fs/ext4/mballoc.c
Applying: ext4: merge fix for blkdev_issue_zeroout API change
Merging quilt/device-mapper
Merging embedded/master
Merging firmware/master
Merging pcmcia/master
Merging battery/master
Merging leds/for-mm
Merging backlight/for-mm
Merging mmc/mmc-next
Merging kgdb/kgdb-next
CONFLICT (content): Merge conflict in drivers/char/sysrq.c
Merging slab/for-next
CONFLICT (content): Merge conflict in include/linux/percpu.h
Merging uclinux/for-next
Merging md/for-next
Merging mfd/for-next
CONFLICT (content): Merge conflict in drivers/mfd/sh_mobile_sdhi.c
Merging hdlc/hdlc-next
Merging drm/drm-next
Merging viafb/viafb-next
Merging voltage/for-next
Merging security-testing/next
Merging lblnet/master
Merging agp/agp-next
Merging uwb/for-upstream
Merging watchdog/master
Merging bdev/master
Merging dwmw2-iommu/master
Merging cputime/cputime
Merging osd/linux-next
Merging jc_docs/docs-next
Merging nommu/master
Merging trivial/for-next
CONFLICT (content): Merge conflict in net/irda/irnet/irnet_ppp.c
Merging audit/for-next
Merging quilt/aoe
Merging suspend/linux-next
Merging fsnotify/for-next
Merging irda/for-next
Merging catalin/for-next
CONFLICT (content): Merge conflict in arch/arm/kernel/Makefile
CONFLICT (content): Merge conflict in arch/arm/mach-vexpress/ct-ca9x4.c
CONFLICT (content): Merge conflict in arch/arm/mm/flush.c
Merging alacrity/linux-next
CONFLICT (content): Merge conflict in include/linux/Kbuild
Merging i7core_edac/linux_next
CONFLICT (content): Merge conflict in MAINTAINERS
Merging i7300_edac/linux_next
Merging devicetree/next-devicetree
Merging spi/next-spi
Merging omap_dss2/for-next
Merging tip/auto-latest
CONFLICT (content): Merge conflict in arch/x86/Kconfig
CONFLICT (content): Merge conflict in include/linux/percpu-defs.h
Merging rcu/rcu/next
Merging oprofile/for-next
Merging xen/upstream/xen
CONFLICT (content): Merge conflict in arch/x86/mm/init_32.c
CONFLICT (content): Merge conflict in arch/x86/xen/mmu.c
CONFLICT (delete/modify): include/linux/early_res.h deleted in HEAD and modified in xen/upstream/xen. Version xen/upstream/xen of include/linux/early_res.h left in tree.
CONFLICT (delete/modify): kernel/early_res.c deleted in HEAD and modified in xen/upstream/xen. Version xen/upstream/xen of kernel/early_res.c left in tree.
$ git reset --hard
Merging refs/next/20101021/xen
CONFLICT (content): Merge conflict in arch/x86/mm/fault.c
[master 23393a1] Merge commit 'next/20101021/xen'
Merging swiotlb-xen/master
CONFLICT (content): Merge conflict in drivers/pci/Makefile
Merging xen-pvhvm/linux-next
Merging edac-amd/for-next
Merging percpu/for-next
CONFLICT (content): Merge conflict in include/linux/percpu.h
CONFLICT (content): Merge conflict in mm/percpu.c
Merging workqueues/for-next
CONFLICT (content): Merge conflict in fs/gfs2/main.c
Merging sfi/sfi-test
Merging asm-generic/next
Merging drivers-x86/linux-next
Merging hwpoison/hwpoison
Merging sysctl/master
Merging quilt/driver-core
CONFLICT (content): Merge conflict in drivers/misc/Makefile
Merging quilt/tty
Merging quilt/usb
CONFLICT (content): Merge conflict in drivers/usb/gadget/rndis.c
CONFLICT (content): Merge conflict in drivers/usb/host/Kconfig
CONFLICT (content): Merge conflict in drivers/usb/host/Makefile
Applying: scsi/sd: update for hw_sector_size rename
Merging staging-next/staging-next
CONFLICT (rename/modify): Merge conflict in drivers/misc/ti-st/st_core.c
CONFLICT (rename/modify): Merge conflict in drivers/misc/ti-st/st_kim.c
CONFLICT (content): Merge conflict in arch/arm/plat-omap/devices.c
CONFLICT (content): Merge conflict in drivers/misc/Makefile
CONFLICT (content): Merge conflict in drivers/staging/Makefile
CONFLICT (content): Merge conflict in drivers/staging/batman-adv/hard-interface.c
CONFLICT (content): Merge conflict in drivers/staging/cx25821/cx25821-audio-upstream.c
CONFLICT (content): Merge conflict in drivers/staging/cx25821/cx25821-audio.h
CONFLICT (delete/modify): drivers/staging/mrst-touchscreen/Makefile deleted in HEAD and modified in staging-next/staging-next. Version staging-next/staging-next of drivers/staging/mrst-touchscreen/Makefile left in tree.
CONFLICT (delete/modify): drivers/staging/mrst-touchscreen/intel-mid-touch.c deleted in HEAD and modified in staging-next/staging-next. Version staging-next/staging-next of drivers/staging/mrst-touchscreen/intel-mid-touch.c left in tree.
CONFLICT (delete/modify): drivers/staging/ti-st/st.h deleted in staging-next/staging-next and modified in HEAD. Version HEAD of drivers/staging/ti-st/st.h left in tree.
CONFLICT (delete/modify): drivers/staging/ti-st/st_core.h deleted in staging-next/staging-next and modified in HEAD. Version HEAD of drivers/staging/ti-st/st_core.h left in tree.
$ git rm -f drivers/staging/mrst-touchscreen/Makefile drivers/staging/mrst-touchscreen/intel-mid-touch.c
$ git rm -f drivers/staging/ti-st/st.h drivers/staging/ti-st/st_core.h
Applying: staging: ath6kl: Fixing the driver to use modified mmc_host structure
Merging slabh/slabh
Merging bkl-trivial/trivial
CONFLICT (content): Merge conflict in drivers/block/ataflop.c
CONFLICT (content): Merge conflict in drivers/char/pcmcia/cm4000_cs.c
CONFLICT (content): Merge conflict in drivers/char/pcmcia/cm4040_cs.c
CONFLICT (content): Merge conflict in drivers/mmc/card/block.c
Merging bkl-llseek/llseek
CONFLICT (content): Merge conflict in drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
CONFLICT (content): Merge conflict in drivers/net/wireless/ath/ath9k/debug.c
Applying: ath9k: fix up for .llseek fop change
Merging bkl-vfs/vfs
CONFLICT (content): Merge conflict in fs/cifs/cifsfs.c
CONFLICT (content): Merge conflict in fs/nilfs2/super.c
Merging bkl-config/config
CONFLICT (content): Merge conflict in fs/compat_ioctl.c
Merging irqflags/master
Merging cleancache/linux-next
CONFLICT (content): Merge conflict in include/linux/fs.h
CONFLICT (content): Merge conflict in mm/Kconfig
Merging scsi-post-merge/merge-base:master
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: linux-next: User Mode Linux broken
From: Thomas Gleixner @ 2010-10-22 7:03 UTC (permalink / raw)
To: Richard Weinberger
Cc: peterz, hpa, mingo, linux-kernel@vger.kernel.org, linux-next
In-Reply-To: <201010212227.12919.richard@nod.at>
On Thu, 21 Oct 2010, Richard Weinberger wrote:
> Am Donnerstag 21 Oktober 2010, 21:45:35 schrieb Thomas Gleixner:
> > Why shold it solve it ? irq_enable is set to compat_irq_enable which
> > in turn calls chip->enable.
> >
> > So how's that different ?
>
> I took a closer look on the issue.
>
> check_irq_resend() gets called before irq_chip_set_defaults().
> In the first call to check_irq_resend() desc->irq_data.chip->irq_enable is
> NULL. UML dies due to a NULL-pointer dereference...
>
> I don't know why check_irq_resend() is called before irq_chip_set_defaults().
> It's your code. ;-)
Well, but it only gets called via enable_irq(). So that means
something is calling enable_irq _before_ request/setup_irq().
arch/um/kernel/irq.c:init_IRQ() does that :)
Thanks,
tglx
^ permalink raw reply
* Re: linux-next: manual merge of the xen tree with the tip tree
From: Ingo Molnar @ 2010-10-22 8:01 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Jeremy Fitzhardinge, Xen Devel, linux-next, linux-kernel,
Gianluca Guida, Yinghai Lu, Thomas Gleixner, H. Peter Anvin,
Peter Zijlstra, Linus Torvalds
In-Reply-To: <20101022140335.c4a3a48f.sfr@canb.auug.org.au>
* Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> Today's linux-next merge of the xen tree got a conflict in
> arch/x86/mm/init_32.c between commit
> 1d931264af0f10649b35afa8fbd2e169da51ac08 ("x86-32, memblock: Make
> add_highpages honor early reserved ranges") from the tip tree and commit
> 07147a06ac3b1b028124ea00ba44e69eb8ea7685 ("x86/32: honor reservations of
> high memory") from the xen tree.
Jeremy,
Commit 07147a06ac is all over the x86 tree:
arch/x86/mm/init_32.c | 42 ++++++++++++++++++++++++++++++++----------
include/linux/early_res.h | 3 +++
kernel/early_res.c | 30 ++++++++++++++++++++++++++++++
3 files changed, 65 insertions(+), 10 deletions(-)
... but there's no x86 person who acked it or was Cc:-ed to this commit AFAICS. It
was not even posted to lkml! Nor does the commit title suggest that it affects core
kernel code as well.
Also, the AuthorDate field is a total lie:
commit 07147a06ac3b1b028124ea00ba44e69eb8ea7685
Author: Gianluca Guida <gianluca.guida@citrix.com>
AuthorDate: Sun Aug 2 01:25:48 2009 +0100
Commit: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
CommitDate: Mon Oct 4 14:22:11 2010 -0700
x86/32: honor reservations of high memory
This commit was written on Aug 2 2009, really? kernel/early_res.c, which is modified
by half of this commit, was _CREATED_ in February 2010 ...
I realize that some original patch, much different from this one, was probably
written in 2009, and that via a series of undocumented rebases and modifications to
the patch you achieved this state.
Crap like that is just _NOT_ acceptable, and you know that perfectly well - if you
do this to arch/x86/ i'll be forced to ask for the Xen tree to be removed from
linux-next and be done via the x86 tree again.
Ingo
^ permalink raw reply
* Re: linux-next: User Mode Linux broken
From: Richard Weinberger @ 2010-10-22 10:50 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: peterz, hpa, mingo, linux-kernel, linux-next
In-Reply-To: <alpine.LFD.2.00.1010220900230.3467@localhost6.localdomain6>
On Fri, 22 Oct 2010 09:03:44 +0200 (CEST), Thomas Gleixner
<tglx@linutronix.de> wrote:
> On Thu, 21 Oct 2010, Richard Weinberger wrote:
>> Am Donnerstag 21 Oktober 2010, 21:45:35 schrieb Thomas Gleixner:
>> > Why shold it solve it ? irq_enable is set to compat_irq_enable which
>> > in turn calls chip->enable.
>> >
>> > So how's that different ?
>>
>> I took a closer look on the issue.
>>
>> check_irq_resend() gets called before irq_chip_set_defaults().
>> In the first call to check_irq_resend() desc->irq_data.chip->irq_enable is
>> NULL. UML dies due to a NULL-pointer dereference...
>>
>> I don't know why check_irq_resend() is called before irq_chip_set_defaults().
>> It's your code. ;-)
>
> Well, but it only gets called via enable_irq(). So that means
> something is calling enable_irq _before_ request/setup_irq().
>
> arch/um/kernel/irq.c:init_IRQ() does that :)
Sorry I'm not very familiar with the IRQ stuff.
Does that mean init_IRQ() is not allowed to call enable_irq()?
Thanks,
//richard
> Thanks,
>
> tglx
^ permalink raw reply
* Re: linux-next: User Mode Linux broken
From: Thomas Gleixner @ 2010-10-22 11:12 UTC (permalink / raw)
To: Richard Weinberger; +Cc: peterz, hpa, mingo, linux-kernel, linux-next
In-Reply-To: <ed248baebfad9b050f53a6832435a9a5@radon2.swed.at>
On Fri, 22 Oct 2010, Richard Weinberger wrote:
> On Fri, 22 Oct 2010 09:03:44 +0200 (CEST), Thomas Gleixner
> <tglx@linutronix.de> wrote:
> > On Thu, 21 Oct 2010, Richard Weinberger wrote:
> >> Am Donnerstag 21 Oktober 2010, 21:45:35 schrieb Thomas Gleixner:
> >> > Why shold it solve it ? irq_enable is set to compat_irq_enable which
> >> > in turn calls chip->enable.
> >> >
> >> > So how's that different ?
> >>
> >> I took a closer look on the issue.
> >>
> >> check_irq_resend() gets called before irq_chip_set_defaults().
> >> In the first call to check_irq_resend() desc->irq_data.chip->irq_enable is
> >> NULL. UML dies due to a NULL-pointer dereference...
> >>
> >> I don't know why check_irq_resend() is called before irq_chip_set_defaults().
> >> It's your code. ;-)
> >
> > Well, but it only gets called via enable_irq(). So that means
> > something is calling enable_irq _before_ request/setup_irq().
> >
> > arch/um/kernel/irq.c:init_IRQ() does that :)
>
> Sorry I'm not very familiar with the IRQ stuff.
> Does that mean init_IRQ() is not allowed to call enable_irq()?
Well, nothing is supposed to call enable_irq() before an interrupt is
installed with request_irq() or setup_irq().
Patch below should fix your problem.
Thanks,
tglx
---
diff --git a/arch/um/kernel/irq.c b/arch/um/kernel/irq.c
index a746e30..6abc1af 100644
--- a/arch/um/kernel/irq.c
+++ b/arch/um/kernel/irq.c
@@ -395,7 +395,6 @@ void __init init_IRQ(void)
irq_desc[TIMER_IRQ].action = NULL;
irq_desc[TIMER_IRQ].depth = 1;
irq_desc[TIMER_IRQ].chip = &SIGVTALRM_irq_type;
- enable_irq(TIMER_IRQ);
for (i = 1; i < NR_IRQS; i++) {
irq_desc[i].status = IRQ_DISABLED;
irq_desc[i].action = NULL;
^ permalink raw reply related
* Re: linux-next: User Mode Linux broken
From: Thomas Gleixner @ 2010-10-22 13:27 UTC (permalink / raw)
To: Richard Weinberger; +Cc: peterz, hpa, mingo, linux-kernel, linux-next
In-Reply-To: <alpine.LFD.2.00.1010221309370.3345@localhost6.localdomain6>
On Fri, 22 Oct 2010, Thomas Gleixner wrote:
> On Fri, 22 Oct 2010, Richard Weinberger wrote:
> Well, nothing is supposed to call enable_irq() before an interrupt is
> installed with request_irq() or setup_irq().
>
> Patch below should fix your problem.
Yuck. Missed the second instance. Updated patch below.
Thanks,
tglx
---
diff --git a/arch/um/kernel/irq.c b/arch/um/kernel/irq.c
index a746e30..97e204b 100644
--- a/arch/um/kernel/irq.c
+++ b/arch/um/kernel/irq.c
@@ -395,13 +395,11 @@ void __init init_IRQ(void)
irq_desc[TIMER_IRQ].action = NULL;
irq_desc[TIMER_IRQ].depth = 1;
irq_desc[TIMER_IRQ].chip = &SIGVTALRM_irq_type;
- enable_irq(TIMER_IRQ);
for (i = 1; i < NR_IRQS; i++) {
irq_desc[i].status = IRQ_DISABLED;
irq_desc[i].action = NULL;
irq_desc[i].depth = 1;
irq_desc[i].chip = &normal_irq_type;
- enable_irq(i);
}
}
^ permalink raw reply related
* Re: linux-next: manual merge of the xen tree with the tip tree
From: Jeremy Fitzhardinge @ 2010-10-22 18:39 UTC (permalink / raw)
To: Ingo Molnar
Cc: Stephen Rothwell, Xen Devel, Peter Zijlstra, Linus Torvalds,
linux-kernel, linux-next, H. Peter Anvin, Thomas Gleixner,
Yinghai Lu, Gianluca Guida
In-Reply-To: <20101022080129.GA8474@elte.hu>
On 10/22/2010 01:01 AM, Ingo Molnar wrote:
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
>> Hi all,
>>
>> Today's linux-next merge of the xen tree got a conflict in
>> arch/x86/mm/init_32.c between commit
>> 1d931264af0f10649b35afa8fbd2e169da51ac08 ("x86-32, memblock: Make
>> add_highpages honor early reserved ranges") from the tip tree and commit
>> 07147a06ac3b1b028124ea00ba44e69eb8ea7685 ("x86/32: honor reservations of
>> high memory") from the xen tree.
> Jeremy,
>
> Commit 07147a06ac is all over the x86 tree:
>
> arch/x86/mm/init_32.c | 42 ++++++++++++++++++++++++++++++++----------
> include/linux/early_res.h | 3 +++
> kernel/early_res.c | 30 ++++++++++++++++++++++++++++++
> 3 files changed, 65 insertions(+), 10 deletions(-)
>
> ... but there's no x86 person who acked it or was Cc:-ed to this commit AFAICS. It
> was not even posted to lkml! Nor does the commit title suggest that it affects core
> kernel code as well.
>
> Also, the AuthorDate field is a total lie:
>
> commit 07147a06ac3b1b028124ea00ba44e69eb8ea7685
> Author: Gianluca Guida <gianluca.guida@citrix.com>
> AuthorDate: Sun Aug 2 01:25:48 2009 +0100
> Commit: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> CommitDate: Mon Oct 4 14:22:11 2010 -0700
>
> x86/32: honor reservations of high memory
>
> This commit was written on Aug 2 2009, really? kernel/early_res.c, which is modified
> by half of this commit, was _CREATED_ in February 2010 ...
Most of the code in early_res.c was simply moved from
arch/x86/.../e820.c, so the patch chunks were applied to the new file
when the code was moved.
> I realize that some original patch, much different from this one, was probably
> written in 2009, and that via a series of undocumented rebases and modifications to
> the patch you achieved this state.
The modified code was almost entirely unchanged over that period, so the
datestamp and original authorship of the patch was basically correct.
However...
> Crap like that is just _NOT_ acceptable, and you know that perfectly well - if you
> do this to arch/x86/ i'll be forced to ask for the Xen tree to be removed from
> linux-next and be done via the x86 tree again.
Hey, hey, hold your horses. This is a wildly obsolete patch that we
were discussing a few weeks ago, but Yinghai did a proper alternative
for the memblock universe.
It was never in linux-next, and never intended to be. I'm not sure why
it has appeared in linux-next now; it isn't in my branch. I wonder if
it appeared in another Xen-related branch. Let me investigate.
J
^ permalink raw reply
* Re: linux-next: manual merge of the xen tree with the tip tree
From: Jeremy Fitzhardinge @ 2010-10-22 19:10 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Xen Devel, Peter Zijlstra, linux-kernel, linux-next,
H. Peter Anvin, Thomas Gleixner, Yinghai Lu, Ingo Molnar,
Gianluca Guida
In-Reply-To: <20101022140335.c4a3a48f.sfr@canb.auug.org.au>
On 10/21/2010 08:03 PM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the xen tree got a conflict in
> arch/x86/mm/init_32.c between commit
> 1d931264af0f10649b35afa8fbd2e169da51ac08 ("x86-32, memblock: Make
> add_highpages honor early reserved ranges") from the tip tree and commit
> 07147a06ac3b1b028124ea00ba44e69eb8ea7685 ("x86/32: honor reservations of
> high memory") from the xen tree.
Hm, that change has been completely obsoleted by the memblock stuff from
tip. Oh, I see. Another change which ended up reverting that patch via
a merge got dropped, so it got left lying around. I'll pull it out.
(Not sure why it merges cleanly for me however; I guess because you've
already got the older xen branch in there which contains the merge.)
Anyway, update pushed.
J
^ permalink raw reply
* Re: [Xen-devel] Re: linux-next: manual merge of the xen tree with the tip tree
From: Stefano Stabellini @ 2010-10-22 21:32 UTC (permalink / raw)
To: Jeremy Fitzhardinge
Cc: Ingo Molnar, Stephen Rothwell, Xen Devel, Peter Zijlstra,
Linus Torvalds, linux-kernel@vger.kernel.org,
linux-next@vger.kernel.org, H. Peter Anvin, Thomas Gleixner,
Yinghai Lu, Gianluca Guida
In-Reply-To: <4CC1DA58.8000606@goop.org>
On Fri, 22 Oct 2010, Jeremy Fitzhardinge wrote:
> > Crap like that is just _NOT_ acceptable, and you know that perfectly well - if you
> > do this to arch/x86/ i'll be forced to ask for the Xen tree to be removed from
> > linux-next and be done via the x86 tree again.
>
> Hey, hey, hold your horses. This is a wildly obsolete patch that we
> were discussing a few weeks ago, but Yinghai did a proper alternative
> for the memblock universe.
>
> It was never in linux-next, and never intended to be. I'm not sure why
> it has appeared in linux-next now; it isn't in my branch. I wonder if
> it appeared in another Xen-related branch. Let me investigate.
I think I merged in my tree a snapshot of Jeremy's upstream/xen that
apparently was not meant for upstream at all.
And I did that just to solve a trivial 5 lines conflict because my patch
series don't actually depend on any of Jeremy's patches.
I solved the problem taking the radical approach: I removed the
merge with upstream/xen altogether and also removed the commit that
conflicts with one of Jeremy's commits.
There shouldn't be any more conflicts now, and surely there shouldn't be
any more unwanted old commits.
I apologize for any problems caused but none of this was intentional.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox