Hi Oliver,
On Jan 24, 2008 1:49 PM, Oliver Neukum [EMAIL PROTECTED] wrote:
A quick glance through the files at sourceforge indicates that this
device use a file transfer protocol. Mapping this to a simple device
is hard. A fs is quite natural a representation of that.
Sure but the filesystems
Hi Oliver,
On Jan 24, 2008 2:24 PM, Oliver Neukum [EMAIL PROTECTED] wrote:
Sure but the filesystems in fs/ are general purpose and they can be
mounted on top of any block device (except for the in-memory ones like
nfs, cifs, jffs, ...
But none of them mess around with *hardware*. Sure, you
Hi,
On Jan 24, 2008 2:58 PM, Oliver Neukum [EMAIL PROTECTED] wrote:
So we put it into drivers/usb/misc
Does that change the code?
Yes. It's assumes only one device is plugged in.
On Jan 24, 2008 2:58 PM, Oliver Neukum [EMAIL PROTECTED] wrote:
How do you make a block device on top of this
Hi Greg,
On Jan 24, 2008 6:44 PM, Greg KH [EMAIL PROTECTED] wrote:
No, that's not the problem. The code should just be using
usb_register_driver() and then doing what it needs to do in the probe()
callback, like any other USB driver.
By calling usb_find_device() it allows more than one
Hi Greg,
On Jan 24, 2008 7:20 PM, Greg KH [EMAIL PROTECTED] wrote:
So it's not a simple code change at all.
Just create a root directory for every device that is seen in the
probe() function. That should be pretty simple to do.
Yeah, that would work but why do we want to mount all devices
Hi Oliver,
On Jan 24, 2008 9:57 PM, Oliver Neukum [EMAIL PROTECTED] wrote:
Are you proposing to mount a _character_ device?
/me looks
Yeah, I am proposing to mount whatever usb_register_dev() pops up in
/dev (which indeed is a character device). Is that a problem?
Pekka
Hi,
On Jan 24, 2008 10:00 PM, Oliver Neukum [EMAIL PROTECTED] wrote:
A discussion about lifetime rules for objects in sysfs anyone? ;-
Furthermore, you need to unmount all devices before you can unplug one of them.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
Hi,
On Jan 23, 2008 9:52 PM, Nishanth Aravamudan <[EMAIL PROTECTED]> wrote:
> On at least one of the machines in question, wasn't it the case that
> node 0 had all the memory and node 1 had all the CPUs? In that case, you
> would have to boot off a memoryless node? And as long as that is a
>
Hi Christoph,
On Jan 23, 2008 1:18 AM, Christoph Lameter <[EMAIL PROTECTED]> wrote:
> My patch is useless (fascinating history of the changelog there through).
> fallback_alloc calls kmem_getpages without GFP_THISNODE. This means that
> alloc_pages_node() will try to allocate on the current node
Hi Christoph,
On Jan 23, 2008 1:18 AM, Christoph Lameter [EMAIL PROTECTED] wrote:
My patch is useless (fascinating history of the changelog there through).
fallback_alloc calls kmem_getpages without GFP_THISNODE. This means that
alloc_pages_node() will try to allocate on the current node but
Hi,
On Jan 23, 2008 9:52 PM, Nishanth Aravamudan [EMAIL PROTECTED] wrote:
On at least one of the machines in question, wasn't it the case that
node 0 had all the memory and node 1 had all the CPUs? In that case, you
would have to boot off a memoryless node? And as long as that is a
physically
Hi,
Mel Gorman wrote:
Faulting instruction address: 0xc03c8c00
cpu 0x0: Vector: 300 (Data Access) at [c05c3840]
pc: c03c8c00: __lock_text_start+0x20/0x88
lr: c00dadec: .cache_grow+0x7c/0x338
sp: c05c3ac0
msr: 80009032
dar: 40
Hi,
Mel Gorman wrote:
Faulting instruction address: 0xc03c8c00
cpu 0x0: Vector: 300 (Data Access) at [c05c3840]
pc: c03c8c00: __lock_text_start+0x20/0x88
lr: c00dadec: .cache_grow+0x7c/0x338
sp: c05c3ac0
msr: 80009032
dar: 40
Hi Thomas,
On Jan 19, 2008 10:00 PM, Thomas Renninger <[EMAIL PROTECTED]> wrote:
> +static int pnp_alloc_port(struct pnp_resource_table *res)
> +{
[snip]
> + res->port_resource = krealloc(res->port_resource,
> + (sizeof(struct resource) * res->allocated_ports)
> +
Hi Thomas,
On Jan 19, 2008 10:00 PM, Thomas Renninger [EMAIL PROTECTED] wrote:
+static int pnp_alloc_port(struct pnp_resource_table *res)
+{
[snip]
+ res-port_resource = krealloc(res-port_resource,
+ (sizeof(struct resource) * res-allocated_ports)
+ +
Hi Olaf,
[Adding Christoph as cc.]
On Jan 15, 2008 5:09 PM, Olaf Hering <[EMAIL PROTECTED]> wrote:
> Current linus tree crashes in kmem_cache_init, as shown below. The
> system is a 8cpu 2.2GHz POWER5 system, model 9117-570, with 4GB ram.
> Firmware is 240_332, 2.6.23 boots ok with the same
Hi,
On Jan 17, 2008 8:34 AM, CaT <[EMAIL PROTECTED]> wrote:
> There are 75 processes on the box of which almost 47 are kernel
> processes + init. Of the rest, the top 3 have an RSS of 9.4meg, 6.2meg
> and 4.8meg, 7 are at around 2meg and the rest are below 2meg with the
> majority below 1. So
Hi,
On Jan 17, 2008 8:34 AM, CaT [EMAIL PROTECTED] wrote:
There are 75 processes on the box of which almost 47 are kernel
processes + init. Of the rest, the top 3 have an RSS of 9.4meg, 6.2meg
and 4.8meg, 7 are at around 2meg and the rest are below 2meg with the
majority below 1. So unless
Hi Olaf,
[Adding Christoph as cc.]
On Jan 15, 2008 5:09 PM, Olaf Hering [EMAIL PROTECTED] wrote:
Current linus tree crashes in kmem_cache_init, as shown below. The
system is a 8cpu 2.2GHz POWER5 system, model 9117-570, with 4GB ram.
Firmware is 240_332, 2.6.23 boots ok with the same config.
Hi Bryan,
On Jan 8, 2008 10:28 AM, Bryan Wu <[EMAIL PROTECTED]> wrote:
> 1. Push patches to LKML when merge window open (2 weeks after a stable
> kernel version release, for example 2 weeks after 2.6.24 released)
You shouldn't wait for the merge window to open to send patches for
review for the
Hi Bryan,
On Jan 8, 2008 10:28 AM, Bryan Wu [EMAIL PROTECTED] wrote:
1. Push patches to LKML when merge window open (2 weeks after a stable
kernel version release, for example 2 weeks after 2.6.24 released)
You shouldn't wait for the merge window to open to send patches for
review for the
Hi Michal,
On Jan 7, 2008 3:00 PM, Michal Simek <[EMAIL PROTECTED]> wrote:
> > You can have as many maintainers as you want but you probably don't
> > want to make it too many. There aren't any "official" responsibilities
> > as a maintainer, it really depends on how much time and effort you're
>
Hi Michael,
On Jan 7, 2008 1:29 PM, Michal Simek <[EMAIL PROTECTED]> wrote:
> Is it possible to create git repository in git.kernel.org for Microblaze
> cpu?
You need to ask the kernel.org administrators for that:
http://www.kernel.org/faq/#account
On Jan 7, 2008 1:29 PM, Michal Simek
Hi Michael,
On Jan 7, 2008 1:29 PM, Michal Simek [EMAIL PROTECTED] wrote:
Is it possible to create git repository in git.kernel.org for Microblaze
cpu?
You need to ask the kernel.org administrators for that:
http://www.kernel.org/faq/#account
On Jan 7, 2008 1:29 PM, Michal Simek [EMAIL
Hi Michal,
On Jan 7, 2008 3:00 PM, Michal Simek [EMAIL PROTECTED] wrote:
You can have as many maintainers as you want but you probably don't
want to make it too many. There aren't any official responsibilities
as a maintainer, it really depends on how much time and effort you're
willing
Hi Andi,
On Jan 4, 2008 4:39 PM, Andi Kleen <[EMAIL PROTECTED]> wrote:
> > The kernel process request that _all_ contributors run their patches
> > through checkpath.pl and fix the problems.
>
> That's new. When and by whom was that rule been introduced? And with what
> rationale?
Not be new to
Hi Andi,
On Jan 4, 2008 4:39 PM, Andi Kleen [EMAIL PROTECTED] wrote:
The kernel process request that _all_ contributors run their patches
through checkpath.pl and fix the problems.
That's new. When and by whom was that rule been introduced? And with what
rationale?
Not be new to anyone
Hi Arjan,
On Jan 3, 2008 2:56 AM, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> +int do_warn_on(const unsigned long condition, const char *file,
> + const int line, const char *function)
> +{
> + if (unlikely(condition)) {
> + printk(KERN_WARNING
Hi Arjan,
On Jan 3, 2008 2:56 AM, Arjan van de Ven [EMAIL PROTECTED] wrote:
+int do_warn_on(const unsigned long condition, const char *file,
+ const int line, const char *function)
+{
+ if (unlikely(condition)) {
+ printk(KERN_WARNING WARNING: at
ither SLAB or SLUB), and
> then both SLAB and SLUB just have the exact same interfaces.
>
> Which means that SLOB could also trivially implement the same thing, with
> no new #ifdef'fery or other crud.
>
> It's totally untested, but looks fairly obvious.
Looks good to me. Thanks! :-
ins <[EMAIL PROTECTED]>
> ---
> To minimize ifdeffery, this leaves it with S_IWUSR though unwritable:
> I'm assuming that's acceptable.
I already sent the remaining bits to Linus but this looks much
cleaner. Thanks Hugh!
Acked-by: Pekka Enberg <[EMAIL PROTECTED]>
--
To unsubscribe
]
---
To minimize ifdeffery, this leaves it with S_IWUSR though unwritable:
I'm assuming that's acceptable.
I already sent the remaining bits to Linus but this looks much
cleaner. Thanks Hugh!
Acked-by: Pekka Enberg [EMAIL PROTECTED]
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
), and
then both SLAB and SLUB just have the exact same interfaces.
Which means that SLOB could also trivially implement the same thing, with
no new #ifdef'fery or other crud.
It's totally untested, but looks fairly obvious.
Looks good to me. Thanks! :-)
Reviewed-by: Pekka Enberg [EMAIL PROTECTED
On Dec 24, 2007 9:12 PM, Christoph Lameter <[EMAIL PROTECTED]> wrote:
> Hmmm... What is the combination of config variables that causes this? I
> moved the count_partial function in mm in order to make the merge of slab
> defrag easier.
I think it's CONFIG_PROC_FS without CONFIG_SYSFS.
--
To
On Dec 24, 2007 9:12 PM, Christoph Lameter [EMAIL PROTECTED] wrote:
Hmmm... What is the combination of config variables that causes this? I
moved the count_partial function in mm in order to make the merge of slab
defrag easier.
I think it's CONFIG_PROC_FS without CONFIG_SYSFS.
--
To
o
> please give it a second look ;-)
Sure, I'm fine with that. Can you Andrew please drop mine and use
Ingo's instead?
Acked-by: Pekka Enberg <[EMAIL PROTECTED]>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTE
implicit declaration of function 'count_partial'
Looks good. Thanks!
Reviewed-by: Pekka Enberg <[EMAIL PROTECTED]>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/ma
Hi Ingo,
On Dec 22, 2007 3:14 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> Also please apply the cleanup patch below, it fixes 34 checkpatch errors
> and warnings in mm/slub.c.
Those are already fixed in -mm:
Hi Andi,
On Dec 22, 2007 2:54 PM, Andi Kleen <[EMAIL PROTECTED]> wrote:
> > Yeah but then again removing an interface that has been around for
> > ever
>
> Version 2.1 hasn't been around forever and at least slabtop does not
> work over version number changes in my experience.
True but the
Hi,
On Dec 22, 2007 2:37 PM, Andi Kleen <[EMAIL PROTECTED]> wrote:
> Removing an interface that exposes lots of internal details when you
> rewrite the subsystem and those internal details all change seems
> like a good reason to me.
Yeah but then again removing an interface that has been around
Hi Thomas,
On Dec 5, 2007 11:25 AM, Thomas Bogendoerfer <[EMAIL PROTECTED]> wrote:
> > These:
> >
> > > +#define READ_SC(p, r)readb((p)->membase + RD_##r)
> > > +#define WRITE_SC(p, r, v)writeb((v), (p)->membase + WR_##r)
> >
> > and these:
> >
> > > +#define READ_SC_PORT(p, r)
Hi Thomas,
On Dec 5, 2007 11:25 AM, Thomas Bogendoerfer [EMAIL PROTECTED] wrote:
These:
+#define READ_SC(p, r)readb((p)-membase + RD_##r)
+#define WRITE_SC(p, r, v)writeb((v), (p)-membase + WR_##r)
and these:
+#define READ_SC_PORT(p, r) read_sc_port(p,
Hi,
On Dec 22, 2007 2:37 PM, Andi Kleen [EMAIL PROTECTED] wrote:
Removing an interface that exposes lots of internal details when you
rewrite the subsystem and those internal details all change seems
like a good reason to me.
Yeah but then again removing an interface that has been around for
Hi Andi,
On Dec 22, 2007 2:54 PM, Andi Kleen [EMAIL PROTECTED] wrote:
Yeah but then again removing an interface that has been around for
ever
Version 2.1 hasn't been around forever and at least slabtop does not
work over version number changes in my experience.
True but the default
Hi Ingo,
On Dec 22, 2007 3:14 PM, Ingo Molnar [EMAIL PROTECTED] wrote:
Also please apply the cleanup patch below, it fixes 34 checkpatch errors
and warnings in mm/slub.c.
Those are already fixed in -mm:
'count_partial'
Looks good. Thanks!
Reviewed-by: Pekka Enberg [EMAIL PROTECTED]
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
it a second look ;-)
Sure, I'm fine with that. Can you Andrew please drop mine and use
Ingo's instead?
Acked-by: Pekka Enberg [EMAIL PROTECTED]
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
oise improvement as well.
>
> Acked-by: Ingo Molnar <[EMAIL PROTECTED]>
I thought it might be a bug but couldn't figure it out. The patch
looks good to me too, Christoph.
Reviewed-by: Pekka Enberg <[EMAIL PROTECTED]>
On Dec 22, 2007 1:17 AM, Ingo Molnar <[EMAIL PROTECTED]> wrote
Hi,
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> > In an extreme case (boot with slub_min_order=9 to get huge page sized
> > slabs) SLUB can win against SLAB:
> >
> > N=10 Time: 0.338 Minimally faster
> > N=20 Time: 0.560 10% faster
> > N=50 Time: 1.353 15% faster
On Dec 21,
Hi,
Christoph Lameter [EMAIL PROTECTED] wrote:
In an extreme case (boot with slub_min_order=9 to get huge page sized
slabs) SLUB can win against SLAB:
N=10 Time: 0.338 Minimally faster
N=20 Time: 0.560 10% faster
N=50 Time: 1.353 15% faster
On Dec 21, 2007 2:09 PM,
thought it might be a bug but couldn't figure it out. The patch
looks good to me too, Christoph.
Reviewed-by: Pekka Enberg [EMAIL PROTECTED]
On Dec 22, 2007 1:17 AM, Ingo Molnar [EMAIL PROTECTED] wrote:
And i hereby nominate Pekka as SLUB/SLAB co-maintainer and spokesperson
;-)
Heh, thanks
Hi,
On Dec 20, 2007 4:38 PM, David Newall <[EMAIL PROTECTED]> wrote:
> >>> and another one, this time tainted with the nvidia module:
> >>> 5194.130985] Unable to handle kernel paging request at 0300
> >>> RIP:
>
> Numbers like that don't suggest hardware faults. All those zeros:
Hi,
On Dec 20, 2007 4:38 PM, David Newall [EMAIL PROTECTED] wrote:
and another one, this time tainted with the nvidia module:
5194.130985] Unable to handle kernel paging request at 0300
RIP:
Numbers like that don't suggest hardware faults. All those zeros: It's
far too
Hi John,
On Dec 17, 2007 5:47 PM, John Reiser <[EMAIL PROTECTED]> wrote:
> In mm/slab.c, the DEBUG variant of cache_alloc_debugcheck_after
> might call cachep->ctor(objp, cachep, 0); but the non-DEBUG
> variant does absolutely nothing. idr_pre_get is a routine
> which notices the difference.
Hi John,
On Dec 17, 2007 5:47 PM, John Reiser [EMAIL PROTECTED] wrote:
In mm/slab.c, the DEBUG variant of cache_alloc_debugcheck_after
might call cachep-ctor(objp, cachep, 0); but the non-DEBUG
variant does absolutely nothing. idr_pre_get is a routine
which notices the difference.
How
Hi,
On Dec 10, 2007 11:31 PM, Jonathan Corbet <[EMAIL PROTECTED]> wrote:
> I'm just getting around to looking at this. One thing jumped out at me:
>
> > + if (bio->bi_throttle) {
> > + struct request_queue *q = bio->bi_queue;
> > + bio->bi_throttle = 0; /* or detect
Hi Richard,
On Dec 10, 2007 9:29 PM, Richard Knutsson <[EMAIL PROTECTED]> wrote:
> Remove local definition of TRUE/FALSE.
This is already fixed in Francois' tree:
http://git.kernel.org/?p=linux/kernel/git/romieu/netdev-2.6.git;a=commitdiff;h=2af61e99e3d1c959840ea007ff56b15db794fb99
Hi Richard,
On Dec 10, 2007 9:29 PM, Richard Knutsson [EMAIL PROTECTED] wrote:
Remove local definition of TRUE/FALSE.
This is already fixed in Francois' tree:
http://git.kernel.org/?p=linux/kernel/git/romieu/netdev-2.6.git;a=commitdiff;h=2af61e99e3d1c959840ea007ff56b15db794fb99
Hi,
On Dec 10, 2007 11:31 PM, Jonathan Corbet [EMAIL PROTECTED] wrote:
I'm just getting around to looking at this. One thing jumped out at me:
+ if (bio-bi_throttle) {
+ struct request_queue *q = bio-bi_queue;
+ bio-bi_throttle = 0; /* or detect multiple endio
Hi Ingo,
On Dec 9, 2007 10:50 AM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> yes, i understand the initial announcement (and the Kconfig entry still
> says the same), but that is not matched up by the reality i see in the
> actual code - SLUB clearly uses a queue/list of objects (as cited in my
>
new;
>
> + /* We handle __GFP_ZERO in the caller */
> + gfpflags &= ~__GFP_ZERO;
> +
> if (!c->page)
> goto new_slab;
In case you didn't already merge this:
Reviewed-by: Pekka Enberg <[EMAIL PROTECTED]>
--
To unsubscribe from this
Hi Ingo,
On Dec 8, 2007 10:29 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> so it has a "free list", which is clearly per cpu. Hang on! Isnt that
> actually a per CPU queue? Which SLUB has not, we are told? The "U" in
> SLUB. How on earth can an allocator in 2007 claim to have no queuing
> (which
Hi Ingo,
On Dec 8, 2007 10:29 PM, Ingo Molnar [EMAIL PROTECTED] wrote:
so it has a free list, which is clearly per cpu. Hang on! Isnt that
actually a per CPU queue? Which SLUB has not, we are told? The U in
SLUB. How on earth can an allocator in 2007 claim to have no queuing
(which is in
;
+
if (!c-page)
goto new_slab;
In case you didn't already merge this:
Reviewed-by: Pekka Enberg [EMAIL PROTECTED]
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org
Hi Ingo,
On Dec 9, 2007 10:50 AM, Ingo Molnar [EMAIL PROTECTED] wrote:
yes, i understand the initial announcement (and the Kconfig entry still
says the same), but that is not matched up by the reality i see in the
actual code - SLUB clearly uses a queue/list of objects (as cited in my
Hi Dave,
On Dec 4, 2007 3:31 AM, Dave Young <[EMAIL PROTECTED]> wrote:
> Kobject_put should be called when kobject register functioin fails, so the
> the kobj ref count touch zero and then the proper cleanup routines will be
> called.
[snip]
> diff -upr linux/drivers/block/pktcdvd.c
Hi,
On Mon, Dec 03, 2007 at 08:41:44PM +0900, Tetsuo Handa wrote:
> > We couldn't know how much memory was allocated by kmalloc() in 2.4 era, and
> > we can know it 2.6 era.
> > But are we going back to 2.4 era for out-of-tree kernel modules?
On Dec 3, 2007 3:57 PM, Adrian Bunk <[EMAIL
Hi,
On Mon, Dec 03, 2007 at 12:59:00PM +0100, Ingo Molnar wrote:
> > "audit thousands of callsites in 8 million lines of code first" is a
> > nice euphemism for hiding from the blame forever. We had 10 years for it
On Dec 3, 2007 2:13 PM, Andi Kleen <[EMAIL PROTECTED]> wrote:
> Ok your approach
Hi,
On Mon, Dec 03, 2007 at 12:59:00PM +0100, Ingo Molnar wrote:
audit thousands of callsites in 8 million lines of code first is a
nice euphemism for hiding from the blame forever. We had 10 years for it
On Dec 3, 2007 2:13 PM, Andi Kleen [EMAIL PROTECTED] wrote:
Ok your approach is then
Hi,
On Mon, Dec 03, 2007 at 08:41:44PM +0900, Tetsuo Handa wrote:
We couldn't know how much memory was allocated by kmalloc() in 2.4 era, and
we can know it 2.6 era.
But are we going back to 2.4 era for out-of-tree kernel modules?
On Dec 3, 2007 3:57 PM, Adrian Bunk [EMAIL PROTECTED]
Hi Dave,
On Dec 4, 2007 3:31 AM, Dave Young [EMAIL PROTECTED] wrote:
Kobject_put should be called when kobject register functioin fails, so the
the kobj ref count touch zero and then the proper cleanup routines will be
called.
[snip]
diff -upr linux/drivers/block/pktcdvd.c
s = page->slab;
> BUG_ON(!s);
Looks good to me.
Reviewed-by: Pekka Enberg <[EMAIL PROTECTED]>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
;
- page = get_object_page(object);
+ page = virt_to_head_page(object);
BUG_ON(!page);
+
+ if (unlikely(!PageSlab(page)))
+ return PAGE_SIZE compound_order(page);
+
s = page-slab;
BUG_ON(!s);
Looks good to me.
Reviewed-by: Pekka Enberg
Hi Vegard,
On Nov 27, 2007 5:16 PM, Vegard Nossum <[EMAIL PROTECTED]> wrote:
> +config KMEMCHECK
> + bool "Trap use of uninitialized memory"
> + depends on X86_32 && !CC_OPTIMIZE_FOR_SIZE
> + help
> + This option enables tracing of dynamically allocated kernel memory
> +
Hi Vegard,
On Nov 27, 2007 5:16 PM, Vegard Nossum [EMAIL PROTECTED] wrote:
+config KMEMCHECK
+ bool Trap use of uninitialized memory
+ depends on X86_32 !CC_OPTIMIZE_FOR_SIZE
+ help
+ This option enables tracing of dynamically allocated kernel memory
+ to
Hi,
On Fri, Nov 23, 2007 at 10:52:06AM +0200, Pekka Enberg wrote:
> > Current git head doesn't compile. Looks like fall-out from the x86 merge?
On Nov 23, 2007 12:13 PM, WANG Cong <[EMAIL PROTECTED]> wrote:
> Hmm, I believe this patch[1] from Jeff can solve the problem. ;
Hi,
Current git head doesn't compile. Looks like fall-out from the x86 merge?
[EMAIL PROTECTED]:~/src/linux/uml-2.6$ make ARCH=um
SYMLINK arch/um/include/kern_constants.h
SYMLINK arch/um/include/sysdep
make[1]: `arch/um/sys-i386/user-offsets.s' is up to date.
CHK
Hi,
Current git head doesn't compile. Looks like fall-out from the x86 merge?
[EMAIL PROTECTED]:~/src/linux/uml-2.6$ make ARCH=um
SYMLINK arch/um/include/kern_constants.h
SYMLINK arch/um/include/sysdep
make[1]: `arch/um/sys-i386/user-offsets.s' is up to date.
CHK
Hi,
On Fri, Nov 23, 2007 at 10:52:06AM +0200, Pekka Enberg wrote:
Current git head doesn't compile. Looks like fall-out from the x86 merge?
On Nov 23, 2007 12:13 PM, WANG Cong [EMAIL PROTECTED] wrote:
Hmm, I believe this patch[1] from Jeff can solve the problem. ;-)
[1] http://lkml.org/lkml
Hi Michael,
On Monday 05 November 2007 13:23:50 Pekka Enberg wrote:
> > Is CONFIG_DEBUG_SLAB enabled? Usually these kind of random corruptions
> > are caused by someone passing a bad pointer to kfree() or
> > kmem_cache_free().
On 11/5/07, Michael Buesch <[EMAIL PROT
Hi Michael,
On Sat, 2007-11-03 at 21:06 +0100, Michael Buesch wrote:
> Who is responsible for slab btw?
> I mean, someone should be interested in getting this bug fixed. :)
> When using slab I see random corruptions. I think related to rmmod, but
> I'm not sure. I don't see this with slub.
Is
Hi Michael,
On Sat, 2007-11-03 at 21:06 +0100, Michael Buesch wrote:
Who is responsible for slab btw?
I mean, someone should be interested in getting this bug fixed. :)
When using slab I see random corruptions. I think related to rmmod, but
I'm not sure. I don't see this with slub.
Is
Hi Michael,
On Monday 05 November 2007 13:23:50 Pekka Enberg wrote:
Is CONFIG_DEBUG_SLAB enabled? Usually these kind of random corruptions
are caused by someone passing a bad pointer to kfree() or
kmem_cache_free().
On 11/5/07, Michael Buesch [EMAIL PROTECTED] wrote:
Yeah.
What I also
Hi,
On 10/29/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
> > We don't need preempt_enable for CONFIG_SMP, right?
>
> preempt_enable is needed if preemption is enabled.
Disabled? But yeah, I see that slab_trylock() can leave preemption
disabled if cmpxchg fails. Was confused by the
Hi,
On 10/29/07, Christoph Lameter [EMAIL PROTECTED] wrote:
We don't need preempt_enable for CONFIG_SMP, right?
preempt_enable is needed if preemption is enabled.
Disabled? But yeah, I see that slab_trylock() can leave preemption
disabled if cmpxchg fails. Was confused by the #ifdefs... :-)
Hi Rusty,
On Saturday 27 October 2007 21:47:09 Pekka Enberg wrote:
> > > + kfree(oldsb);
> > > + *sb = (struct stringbuf *)enomem_string;
> >
> > Why don't we just return -ENOMEM here just like all other APIs in the
> > kernel?
Hi Rusty,
On 10/26/07, Rusty Russell <[EMAIL PROTECTED]> wrote:
>This just seems like more optimization and complexity that we need.
> Interfaces
> using vsnprintf don't seem like good candidates for optimization.
>
> How about this? It's as simple as I could make it...
FWIW I like
Hi Rusty,
On 10/26/07, Rusty Russell [EMAIL PROTECTED] wrote:
This just seems like more optimization and complexity that we need.
Interfaces
using vsnprintf don't seem like good candidates for optimization.
How about this? It's as simple as I could make it...
FWIW I like this
Hi Rusty,
On Saturday 27 October 2007 21:47:09 Pekka Enberg wrote:
+ kfree(oldsb);
+ *sb = (struct stringbuf *)enomem_string;
Why don't we just return -ENOMEM here just like all other APIs in the
kernel?
On 10/27/07, Rusty Russell [EMAIL PROTECTED] wrote
Hi,
The current Linus' git does not compile on i386 for UM defconfig:
CC init/do_mounts.o
In file included from init/do_mounts.c:19:
init/do_mounts.h: In function 'bstat':
init/do_mounts.h:25: error: storage size of 'stat' isn't known
init/do_mounts.h:25: warning: unused variable 'stat'
e-fix.patch
> > revoke-vs-git-block.patch
> >
> > Not sure - opinions sought.
On 10/2/07, Pekka Enberg <[EMAIL PROTECTED]> wrote:
> Needs more work to fix problems raised by viro. I am cooking up a
> patch but it won't be ready for 2.6.24.
FYI the patches (with known bug
Hi,
On 10/24/07, Matthew Wilcox <[EMAIL PROTECTED]> wrote:
> +static void sb_vprintf(struct stringbuf *sb, const char *format, va_list
> args)
> +{
> + char *s;
> + int size;
> +
> + if (sb->alloc == -ENOMEM)
> + return;
> + if (sb->alloc == 0) {
> +
Hi,
On 10/26/07, Neil Brown <[EMAIL PROTECTED]> wrote:
> It seems that the new requirement is that if the address_space
> chooses not to write out the page, it should now call SetPageActive().
> If that is the case, I think it should be explicit in the
> documentation - please?
Agreed.
-
To
Hi Hugh,
On 10/25/07, Hugh Dickins <[EMAIL PROTECTED]> wrote:
> @@ -349,10 +349,6 @@ static pageout_t pageout(struct page *pa
> res = mapping->a_ops->writepage(page, );
> if (res < 0)
> handle_write_error(mapping, page, res);
> -
Hi,
On 10/26/07, Neil Brown [EMAIL PROTECTED] wrote:
It seems that the new requirement is that if the address_space
chooses not to write out the page, it should now call SetPageActive().
If that is the case, I think it should be explicit in the
documentation - please?
Agreed.
-
To
Hi Hugh,
On 10/25/07, Hugh Dickins [EMAIL PROTECTED] wrote:
@@ -349,10 +349,6 @@ static pageout_t pageout(struct page *pa
res = mapping-a_ops-writepage(page, wbc);
if (res 0)
handle_write_error(mapping, page, res);
- if
, Pekka Enberg [EMAIL PROTECTED] wrote:
Needs more work to fix problems raised by viro. I am cooking up a
patch but it won't be ready for 2.6.24.
FYI the patches (with known bugs) can be found here in case anyone is
interested:
http://www.kernel.org/pub/linux/kernel/people/penberg/patches/revoke
Hi,
On 10/24/07, Matthew Wilcox [EMAIL PROTECTED] wrote:
+static void sb_vprintf(struct stringbuf *sb, const char *format, va_list
args)
+{
+ char *s;
+ int size;
+
+ if (sb-alloc == -ENOMEM)
+ return;
+ if (sb-alloc == 0) {
+ sb-s =
Hi,
The current Linus' git does not compile on i386 for UM defconfig:
CC init/do_mounts.o
In file included from init/do_mounts.c:19:
init/do_mounts.h: In function 'bstat':
init/do_mounts.h:25: error: storage size of 'stat' isn't known
init/do_mounts.h:25: warning: unused variable 'stat'
Hi,
On 10/25/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> I think the OpenBSD people decided to actually do something about this,
> and I suspect it had *nothing* to do with license issues, and everything
> to do with these kinds of problems. I wish them all the luck, although
> personally I
901 - 1000 of 1778 matches
Mail list logo
