On Wed, 2008-02-13 at 14:09 +0900, Yasunori Goto wrote:
> Thanks Badari-san.
>
> I understand what was occured. :-)
>
> > On Tue, 2008-02-12 at 13:56 -0800, Badari Pulavarty wrote:
> > > > > + /*
> > > > > +* Its ugly, but this is the best I can do - HELP !!
> > > > > +* We don't know
On Wed, 2008-02-13 at 14:09 +0900, Yasunori Goto wrote:
Thanks Badari-san.
I understand what was occured. :-)
On Tue, 2008-02-12 at 13:56 -0800, Badari Pulavarty wrote:
+ /*
+* Its ugly, but this is the best I can do - HELP !!
+* We don't know where the allocations
Thanks Badari-san.
I understand what was occured. :-)
> On Tue, 2008-02-12 at 13:56 -0800, Badari Pulavarty wrote:
> > > > + /*
> > > > +* Its ugly, but this is the best I can do - HELP !!
> > > > +* We don't know where the allocations for section memmap and usemap
> > > > +* came
On Tue, 2008-02-12 at 15:03 -0800, Badari Pulavarty wrote:
> Here is the version with your suggestion. Do you like this better ?
I do like how it looks, better, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
On Tue, 2008-02-12 at 14:15 -0800, Dave Hansen wrote:
> On Tue, 2008-02-12 at 14:07 -0800, Badari Pulavarty wrote:
> > On Tue, 2008-02-12 at 13:57 -0800, Dave Hansen wrote:
> > > On Tue, 2008-02-12 at 13:56 -0800, Badari Pulavarty wrote:
> > > >
> > > > +static void __remove_section(struct zone
On Tue, 2008-02-12 at 14:15 -0800, Dave Hansen wrote:
> On Tue, 2008-02-12 at 14:07 -0800, Badari Pulavarty wrote:
> > On Tue, 2008-02-12 at 13:57 -0800, Dave Hansen wrote:
> > > On Tue, 2008-02-12 at 13:56 -0800, Badari Pulavarty wrote:
> > > >
> > > > +static void __remove_section(struct zone
On Tue, 2008-02-12 at 14:07 -0800, Badari Pulavarty wrote:
> On Tue, 2008-02-12 at 13:57 -0800, Dave Hansen wrote:
> > On Tue, 2008-02-12 at 13:56 -0800, Badari Pulavarty wrote:
> > >
> > > +static void __remove_section(struct zone *zone, unsigned long
> > > section_nr)
> > > +{
> > > + if
On Tue, 2008-02-12 at 13:56 -0800, Badari Pulavarty wrote:
> > > + /*
> > > +* Its ugly, but this is the best I can do - HELP !!
> > > +* We don't know where the allocations for section memmap and usemap
> > > +* came from. If they are allocated at the boot time, they would come
> >
On Tue, 2008-02-12 at 13:57 -0800, Dave Hansen wrote:
> On Tue, 2008-02-12 at 13:56 -0800, Badari Pulavarty wrote:
> >
> > +static void __remove_section(struct zone *zone, unsigned long
> > section_nr)
> > +{
> > + if (!valid_section_nr(section_nr))
> > + return;
> > +
> > +
On Tue, 2008-02-12 at 13:56 -0800, Badari Pulavarty wrote:
>
> +static void __remove_section(struct zone *zone, unsigned long
> section_nr)
> +{
> + if (!valid_section_nr(section_nr))
> + return;
> +
> + unregister_memory_section(__nr_to_section(section_nr));
> +
On Tue, 2008-02-12 at 12:59 -0800, Dave Hansen wrote:
> On Tue, 2008-02-12 at 09:22 -0800, Badari Pulavarty wrote:
> > +static void __remove_section(struct zone *zone, unsigned long
> > phys_start_pfn)
> > +{
> > + if (!pfn_valid(phys_start_pfn))
> > + return;
>
> I think you need at
On Tue, 2008-02-12 at 09:22 -0800, Badari Pulavarty wrote:
> +static void __remove_section(struct zone *zone, unsigned long phys_start_pfn)
> +{
> + if (!pfn_valid(phys_start_pfn))
> + return;
I think you need at least a WARN_ON() there.
I'd probably also not use pfn_valid(),
ry() static.
> > > >
> > > > Another bug fix - before calling unregister_memory()
> > > > remove_memory_block() gets a ref on kobject. unregister_memory()
> > > > need to drop that ref before calling sysdev_unregister().
> > > >
> > >
gt; > the object just freed up. Since no one uses the code,
> > > lets take the code out. And also, make register_memory() static.
> > >
> > > Another bug fix - before calling unregister_memory()
> > > remove_memory_block() gets a ref on kobject. unregister_me
. unregister_memory()
need to drop that ref before calling sysdev_unregister().
I'd say this:
Subject: [-mm PATCH] register_memory/unregister_memory clean ups
is rather tame. These are more than cleanups! These sound like
machine-crashing bugs. Do they crash machines? How
Thanks Badari-san.
I understand what was occured. :-)
On Tue, 2008-02-12 at 13:56 -0800, Badari Pulavarty wrote:
+ /*
+* Its ugly, but this is the best I can do - HELP !!
+* We don't know where the allocations for section memmap and usemap
+* came from. If they are
On Tue, 2008-02-12 at 15:03 -0800, Badari Pulavarty wrote:
Here is the version with your suggestion. Do you like this better ?
I do like how it looks, better, thanks.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
On Tue, 2008-02-12 at 14:07 -0800, Badari Pulavarty wrote:
On Tue, 2008-02-12 at 13:57 -0800, Dave Hansen wrote:
On Tue, 2008-02-12 at 13:56 -0800, Badari Pulavarty wrote:
+static void __remove_section(struct zone *zone, unsigned long
section_nr)
+{
+ if
On Tue, 2008-02-12 at 13:56 -0800, Badari Pulavarty wrote:
+ /*
+* Its ugly, but this is the best I can do - HELP !!
+* We don't know where the allocations for section memmap and usemap
+* came from. If they are allocated at the boot time, they would come
+* from
On Tue, 2008-02-12 at 13:57 -0800, Dave Hansen wrote:
On Tue, 2008-02-12 at 13:56 -0800, Badari Pulavarty wrote:
+static void __remove_section(struct zone *zone, unsigned long
section_nr)
+{
+ if (!valid_section_nr(section_nr))
+ return;
+
+
On Tue, 2008-02-12 at 13:56 -0800, Badari Pulavarty wrote:
+static void __remove_section(struct zone *zone, unsigned long
section_nr)
+{
+ if (!valid_section_nr(section_nr))
+ return;
+
+ unregister_memory_section(__nr_to_section(section_nr));
+
On Tue, 2008-02-12 at 09:22 -0800, Badari Pulavarty wrote:
+static void __remove_section(struct zone *zone, unsigned long phys_start_pfn)
+{
+ if (!pfn_valid(phys_start_pfn))
+ return;
I think you need at least a WARN_ON() there.
I'd probably also not use pfn_valid(),
On Tue, 2008-02-12 at 14:15 -0800, Dave Hansen wrote:
On Tue, 2008-02-12 at 14:07 -0800, Badari Pulavarty wrote:
On Tue, 2008-02-12 at 13:57 -0800, Dave Hansen wrote:
On Tue, 2008-02-12 at 13:56 -0800, Badari Pulavarty wrote:
+static void __remove_section(struct zone *zone, unsigned
calling unregister_memory()
remove_memory_block() gets a ref on kobject. unregister_memory()
need to drop that ref before calling sysdev_unregister().
I'd say this:
Subject: [-mm PATCH] register_memory/unregister_memory clean ups
is rather tame. These are more
On Tue, 2008-02-12 at 12:59 -0800, Dave Hansen wrote:
On Tue, 2008-02-12 at 09:22 -0800, Badari Pulavarty wrote:
+static void __remove_section(struct zone *zone, unsigned long
phys_start_pfn)
+{
+ if (!pfn_valid(phys_start_pfn))
+ return;
I think you need at least a
nd also, make register_memory() static.
> >
> > Another bug fix - before calling unregister_memory()
> > remove_memory_block() gets a ref on kobject. unregister_memory()
> > need to drop that ref before calling sysdev_unregister().
> >
>
> I'd say this:
>
&
lets take the code out. And also, make register_memory() static.
> >
> > Another bug fix - before calling unregister_memory()
> > remove_memory_block() gets a ref on kobject. unregister_memory()
> > need to drop that ref before calling sysdev_unregister().
> >
>
> I'd say this:
&g
unregister_memory()
> need to drop that ref before calling sysdev_unregister().
>
I'd say this:
> Subject: [-mm PATCH] register_memory/unregister_memory clean ups
is rather tame. These are more than cleanups! These sound like
machine-crashing bugs. Do they crash machines? How come nobo
On Mon, 2008-02-11 at 09:54 -0800, Greg KH wrote:
> On Mon, Feb 11, 2008 at 09:23:18AM -0800, Badari Pulavarty wrote:
> > Hi Andrew,
> >
> > While testing hotplug memory remove against -mm, I noticed
> > that unregister_memory() is not cleaning up /sysfs entries
> > correctly. It also
On Mon, Feb 11, 2008 at 09:23:18AM -0800, Badari Pulavarty wrote:
> Hi Andrew,
>
> While testing hotplug memory remove against -mm, I noticed
> that unregister_memory() is not cleaning up /sysfs entries
> correctly. It also de-references structures after destroying
> them (luckily in the code
Hi Andrew,
While testing hotplug memory remove against -mm, I noticed
that unregister_memory() is not cleaning up /sysfs entries
correctly. It also de-references structures after destroying
them (luckily in the code which never gets used). So, I cleaned
up the code and fixed the extra reference
: [-mm PATCH] register_memory/unregister_memory clean ups
is rather tame. These are more than cleanups! These sound like
machine-crashing bugs. Do they crash machines? How come nobody noticed
it?
All very strange...
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
On Mon, 2008-02-11 at 09:54 -0800, Greg KH wrote:
On Mon, Feb 11, 2008 at 09:23:18AM -0800, Badari Pulavarty wrote:
Hi Andrew,
While testing hotplug memory remove against -mm, I noticed
that unregister_memory() is not cleaning up /sysfs entries
correctly. It also de-references
Hi Andrew,
While testing hotplug memory remove against -mm, I noticed
that unregister_memory() is not cleaning up /sysfs entries
correctly. It also de-references structures after destroying
them (luckily in the code which never gets used). So, I cleaned
up the code and fixed the extra reference
to drop that ref before calling sysdev_unregister().
I'd say this:
Subject: [-mm PATCH] register_memory/unregister_memory clean ups
is rather tame. These are more than cleanups! These sound like
machine-crashing bugs. Do they crash machines? How come nobody noticed
()
need to drop that ref before calling sysdev_unregister().
I'd say this:
Subject: [-mm PATCH] register_memory/unregister_memory clean ups
is rather tame. These are more than cleanups! These sound like
machine-crashing bugs. Do they crash machines? How come nobody noticed
On Mon, Feb 11, 2008 at 09:23:18AM -0800, Badari Pulavarty wrote:
Hi Andrew,
While testing hotplug memory remove against -mm, I noticed
that unregister_memory() is not cleaning up /sysfs entries
correctly. It also de-references structures after destroying
them (luckily in the code which
37 matches
Mail list logo
