[ Sorry for the duplicate. I typoed Francois' email address. ]
From: Pekka Enberg <[EMAIL PROTECTED]>
Convert the internal JUMBO_FRAME #ifdef to CONFIG_IP1000_JUMBO_FRAME proper and
fix compilation errors.
Cc: Francois Romieu <[EMAIL PROTECTED]>
Cc: Sorbica Shieh <[EMAIL PROTECTED]>
Cc: Jesse
From: Pekka Enberg <[EMAIL PROTECTED]>
Convert the internal JUMBO_FRAME #ifdef to CONFIG_IP1000_JUMBO_FRAME proper and
fix compilation errors.
Cc: Francois Romieu <[EMAIL PROTECTED]>
Cc: Sorbica Shieh <[EMAIL PROTECTED]>
Cc: Jesse Huang <[EMAIL PROTECTED]>
Signed-off-by: Pekka Enberg <[EMAIL
From: Pekka Enberg [EMAIL PROTECTED]
Convert the internal JUMBO_FRAME #ifdef to CONFIG_IP1000_JUMBO_FRAME proper and
fix compilation errors.
Cc: Francois Romieu [EMAIL PROTECTED]
Cc: Sorbica Shieh [EMAIL PROTECTED]
Cc: Jesse Huang [EMAIL PROTECTED]
Signed-off-by: Pekka Enberg [EMAIL PROTECTED]
[ Sorry for the duplicate. I typoed Francois' email address. ]
From: Pekka Enberg [EMAIL PROTECTED]
Convert the internal JUMBO_FRAME #ifdef to CONFIG_IP1000_JUMBO_FRAME proper and
fix compilation errors.
Cc: Francois Romieu [EMAIL PROTECTED]
Cc: Sorbica Shieh [EMAIL PROTECTED]
Cc: Jesse Huang
On Mon, 25 Feb 2008, Michael Buesch wrote:
> > Neither of which seem like acceptable solutions for a 2.6.23 -> 2.6.24
> > _regression_. Or maybe I am just too naive to believe Linus' statement
> > on not letting the kernel regress...
>
> So, please sign-off the patch that we have, if you think
On Mon, 25 Feb 2008, Michael Buesch wrote:
Neither of which seem like acceptable solutions for a 2.6.23 - 2.6.24
_regression_. Or maybe I am just too naive to believe Linus' statement
on not letting the kernel regress...
So, please sign-off the patch that we have, if you think it's right
Hi Greg,
On Sun, 24 Feb 2008, Greg KH wrote:
> > Lets make this simple: it used to work before and now it doesn't.
> > Therefore it's a regression that must be addressed. Period.
>
> Isn't the resolution Michael is suggesting is, "use the different driver"?
Alexey said it didn't work but even
Hi Michael,
On Sun, 24 Feb 2008, Michael Buesch wrote:
> > The ony way I see this was possible, you manually changed the
> > module loading order, so that the b43xx module was loaded prior
> > to the ssb and b44 modules. Right?
>
> Right. So "so I'm left with either no wifi or no ethenet" being
Hi Michael,
On Sun, 24 Feb 2008, Michael Buesch wrote:
The ony way I see this was possible, you manually changed the
module loading order, so that the b43xx module was loaded prior
to the ssb and b44 modules. Right?
Right. So so I'm left with either no wifi or no ethenet being wrong.
Hi Greg,
On Sun, 24 Feb 2008, Greg KH wrote:
Lets make this simple: it used to work before and now it doesn't.
Therefore it's a regression that must be addressed. Period.
Isn't the resolution Michael is suggesting is, use the different driver?
Alexey said it didn't work but even if it
Hi Alexey,
On Sat, Feb 23, 2008 at 2:37 PM, Pekka Enberg <[EMAIL PROTECTED]> wrote:
> > So does reverting commit 753f492093da7a40141bfe083073400f518f4c68
> > ("[B44]: port to native ssb support") fix the regression?
> >
On Sat, 23 Feb 2008, Alexey Zaytsev wrote:
> Compiling it right now.
>
>
Hi Alexey,
On Sat, Feb 23, 2008 at 2:37 PM, Pekka Enberg [EMAIL PROTECTED] wrote:
So does reverting commit 753f492093da7a40141bfe083073400f518f4c68
([B44]: port to native ssb support) fix the regression?
On Sat, 23 Feb 2008, Alexey Zaytsev wrote:
Compiling it right now.
I'm sure it
From: Pekka Enberg <[EMAIL PROTECTED]>
UML has some header magic that expects a non-inline __kmalloc() function to be
available. Fixes the following link time errors:
arch/um/drivers/built-in.o: In function `kmalloc':
/home/penberg/linux-2.6/arch/um/include/um_malloc.h:14: undefined reference to
From: Pekka Enberg <[EMAIL PROTECTED]>
This adds a proper function for kmalloc page allocator pass-through. While it
simplifies any code that does slab tracing code a lot, I think it's a
worthwhile cleanup in itself.
Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
---
include/linux/slub_def.h |
From: Pekka Enberg [EMAIL PROTECTED]
UML has some header magic that expects a non-inline __kmalloc() function to be
available. Fixes the following link time errors:
arch/um/drivers/built-in.o: In function `kmalloc':
/home/penberg/linux-2.6/arch/um/include/um_malloc.h:14: undefined reference to
From: Pekka Enberg [EMAIL PROTECTED]
This adds a proper function for kmalloc page allocator pass-through. While it
simplifies any code that does slab tracing code a lot, I think it's a
worthwhile cleanup in itself.
Signed-off-by: Pekka Enberg [EMAIL PROTECTED]
---
include/linux/slub_def.h |
From: Bastian Blank <[EMAIL PROTECTED]>
The commit 8811930dc74a503415b35c4a79d14fb0b408a361 ("splice: missing user
pointer access verification") added access_ok() to copy_from_user_mmap_sem()
which only ensures we can copy the struct iovecs from userspace to the kernel
but we also must check
Hi Christoph,
On Tue, 5 Feb 2008, Pekka Enberg wrote:
> > > We could do that Any idea how to display that kind of information in a
> > > meaningful way. Parameter conventions for slabinfo?
> >
> > We could just print out one total summary and one summary for each CPU (and
> > maybe show % of
Hi Christoph,
On Tue, 5 Feb 2008, Pekka Enberg wrote:
We could do that Any idea how to display that kind of information in a
meaningful way. Parameter conventions for slabinfo?
We could just print out one total summary and one summary for each CPU (and
maybe show % of total
On Tue, 5 Feb 2008, Eric Dumazet wrote:
> > Looks good but I am wondering if we want to make the statistics per-CPU so
> > that we can see the kmalloc/kfree ping-pong of, for example, hackbench
> > better?
>
> AFAIK Christoph patch already have percpu statistics :)
Heh, sure, but it's not
Hi Christoph,
On Mon, 4 Feb 2008, Christoph Lameter wrote:
> The statistics provided here allow the monitoring of allocator behavior
> at the cost of some (minimal) loss of performance. Counters are placed in
> SLUB's per cpu data structure that is already written to by other code.
Looks good
Hi Christoph,
On Mon, 4 Feb 2008, Christoph Lameter wrote:
The statistics provided here allow the monitoring of allocator behavior
at the cost of some (minimal) loss of performance. Counters are placed in
SLUB's per cpu data structure that is already written to by other code.
Looks good but I
On Tue, 5 Feb 2008, Eric Dumazet wrote:
Looks good but I am wondering if we want to make the statistics per-CPU so
that we can see the kmalloc/kfree ping-pong of, for example, hackbench
better?
AFAIK Christoph patch already have percpu statistics :)
Heh, sure, but it's not exported to
Hi Vegard,
On Sun, 27 Jan 2008, Vegard Nossum wrote:
> Though in this case, idr_pre_get() actually *is* called first. Hmm...
> I think there's a pretty big chance that kmemcheck is at fault :-(
Depends on how you track object initialization. An object returned by
kmem_cache_alloc() is always
Hi Vegard,
On Sun, 27 Jan 2008, Vegard Nossum wrote:
Though in this case, idr_pre_get() actually *is* called first. Hmm...
I think there's a pretty big chance that kmemcheck is at fault :-(
Depends on how you track object initialization. An object returned by
kmem_cache_alloc() is always
Hi Greg,
On Thu, Jan 24, 2008 at 07:42:20PM +0200, Pekka Enberg wrote:
> > Yeah, that would work but why do we want to mount all devices under
> > the same mount point? If you move device discovery to ->probe() it's
> > simple to have per-device mount points by overriding ->get_sb() to
> > check
Hi Greg,
On Thu, Jan 24, 2008 at 07:42:20PM +0200, Pekka Enberg wrote:
Yeah, that would work but why do we want to mount all devices under
the same mount point? If you move device discovery to -probe() it's
simple to have per-device mount points by overriding -get_sb() to
check for
From: Pekka Enberg <[EMAIL PROTECTED]>
If the node we're booting on doesn't have memory, bootstrapping kmalloc()
caches resorts to fallback_alloc() which requires ->nodelists set for all
nodes. Fix that by calling set_up_list3s() for CACHE_CACHE in
kmem_cache_init().
Tested-by: Mel Gorman
On Wed, 23 Jan 2008, Pekka J Enberg wrote:
> As far as I can tell, there are two ways to fix this:
[snip]
> (2) initialize cache_cache.nodelists with initmem_list3 equivalents
> for *each node hat has normal memory*
An untested patch follows:
---
mm/slab
Hi,
On Wed, 23 Jan 2008, Mel Gorman wrote:
> Applied in combination with the N_NORMAL_MEMORY revert and it fails to
> boot. Console is as follows;
Thanks for testing!
On Wed, 23 Jan 2008, Mel Gorman wrote:
> [c05c3b40] c00dadb4 .cache_grow+0x7c/0x338
> [c05c3c00]
Hi,
On Wed, 23 Jan 2008, Pekka J Enberg wrote:
> > I still think Christoph's kmem_getpages() patch is correct (to fix
> > cache_grow() oops) but I overlooked the fact that none the callers of
> > cache_alloc_node() deal with bootstrapping (with the exception of
>
On Wed, 23 Jan 2008, Pekka J Enberg wrote:
> I still think Christoph's kmem_getpages() patch is correct (to fix
> cache_grow() oops) but I overlooked the fact that none the callers of
> cache_alloc_node() deal with bootstrapping (with the exception of
> __cache_alloc_node() t
Hi Mel,
On Wed, 23 Jan 2008, Mel Gorman wrote:
> diff -rup -X /usr/src/patchset-0.6/bin//dontdiff
> linux-2.6.24-rc8-005-revert-memoryless-slab/mm/slab.c
> linux-2.6.24-rc8-010_handle_missing_l3/mm/slab.c
> --- linux-2.6.24-rc8-005-revert-memoryless-slab/mm/slab.c 2008-01-22
>
Hi,
On Wed, 23 Jan 2008, Pekka J Enberg wrote:
I still think Christoph's kmem_getpages() patch is correct (to fix
cache_grow() oops) but I overlooked the fact that none the callers of
cache_alloc_node() deal with bootstrapping (with the exception of
__cache_alloc_node() that even
On Wed, 23 Jan 2008, Pekka J Enberg wrote:
I still think Christoph's kmem_getpages() patch is correct (to fix
cache_grow() oops) but I overlooked the fact that none the callers of
cache_alloc_node() deal with bootstrapping (with the exception of
__cache_alloc_node() that even has
Hi,
On Wed, 23 Jan 2008, Mel Gorman wrote:
Applied in combination with the N_NORMAL_MEMORY revert and it fails to
boot. Console is as follows;
Thanks for testing!
On Wed, 23 Jan 2008, Mel Gorman wrote:
[c05c3b40] c00dadb4 .cache_grow+0x7c/0x338
[c05c3c00]
On Wed, 23 Jan 2008, Pekka J Enberg wrote:
As far as I can tell, there are two ways to fix this:
[snip]
(2) initialize cache_cache.nodelists with initmem_list3 equivalents
for *each node hat has normal memory*
An untested patch follows:
---
mm/slab.c | 39
From: Pekka Enberg [EMAIL PROTECTED]
If the node we're booting on doesn't have memory, bootstrapping kmalloc()
caches resorts to fallback_alloc() which requires -nodelists set for all
nodes. Fix that by calling set_up_list3s() for CACHE_CACHE in
kmem_cache_init().
Tested-by: Mel Gorman [EMAIL
Hi,
On Wed, 16 Jan 2008, Johannes Weiner wrote:
> > is there any reason why kfree() takes a const pointer just to degrade it
> > with the call to slab_free()/__cache_free() again? The promise that the
> > pointee is not modified is just bogus in this case, anyway, isn't it?
On Wed, 16 Jan
Hi,
On Tue, 15 Jan 2008, Christoph Hellwig wrote:
> Something like the loop above is not going to go in for sure. Once we
> get rid of the sb->s_files we can put the list_head in struct file to
> new use eventually if we don't want to get rid of it. E.g. and
> per-inode list would be much
Hi,
On Tue, 15 Jan 2008, Christoph Hellwig wrote:
Something like the loop above is not going to go in for sure. Once we
get rid of the sb-s_files we can put the list_head in struct file to
new use eventually if we don't want to get rid of it. E.g. and
per-inode list would be much better
Hi,
On Wed, 16 Jan 2008, Johannes Weiner wrote:
is there any reason why kfree() takes a const pointer just to degrade it
with the call to slab_free()/__cache_free() again? The promise that the
pointee is not modified is just bogus in this case, anyway, isn't it?
On Wed, 16 Jan 2008,
Hi Matt,
On Thu, 10 Jan 2008, Pekka J Enberg wrote:
> I'll double check the results for SLUB next but it seems obvious that your
> patches are a net gain for SLOB and should be applied. One problem though
> with SLOB seems to be that its memory efficiency is not so stable. Any
&g
On Wed, 9 Jan 2008, Matt Mackall wrote:
>
> slob: split free list by size
>
[snip]
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
On Mon, 7 Jan 2008, Matt Mackall wrote:
> slob: fix free block merging at head of subpage
>
> We weren't merging freed blocks at the beginning of the free list.
> Fixing this showed a 2.5% efficiency improvement in a userspace test
> harness.
[snip]
Reviewed-by: Pekka Enberg <[EMAIL PROTECTED]>
Hi Matt,
On Wed, 9 Jan 2008, Matt Mackall wrote:
> Huh, that's a fairly negligible change on your system. Is that with or
> without the earlier patch? That doesn't appear to change much here.
> Guess I'll have to clean up my stats patch and send it to you.
Ok, if I apply both of the patches, I
Hi Matt,
On Wed, 9 Jan 2008, Matt Mackall wrote:
Huh, that's a fairly negligible change on your system. Is that with or
without the earlier patch? That doesn't appear to change much here.
Guess I'll have to clean up my stats patch and send it to you.
Ok, if I apply both of the patches, I get
On Wed, 9 Jan 2008, Matt Mackall wrote:
slob: split free list by size
[snip]
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
On Mon, 7 Jan 2008, Matt Mackall wrote:
slob: fix free block merging at head of subpage
We weren't merging freed blocks at the beginning of the free list.
Fixing this showed a 2.5% efficiency improvement in a userspace test
harness.
[snip]
Reviewed-by: Pekka Enberg [EMAIL PROTECTED]
--
To
Hi Matt,
On Thu, 10 Jan 2008, Pekka J Enberg wrote:
I'll double check the results for SLUB next but it seems obvious that your
patches are a net gain for SLOB and should be applied. One problem though
with SLOB seems to be that its memory efficiency is not so stable. Any
ideas why
Hi Matt,
On Wed, 9 Jan 2008, Matt Mackall wrote:
> I kicked this around for a while, slept on it, and then came up with
> this little hack first thing this morning:
>
>
> slob: split free list by size
>
[snip]
> And the results are fairly miraculous, so please double-check them
Hi Matt,
On Wed, 9 Jan 2008, Matt Mackall wrote:
I kicked this around for a while, slept on it, and then came up with
this little hack first thing this morning:
slob: split free list by size
[snip]
And the results are fairly miraculous, so please double-check them on
your
Hi Matt,
On Mon, 7 Jan 2008, Matt Mackall wrote:
> Fascinating. Which kernel version are you using? This patch doesn't seem
> to have made it to mainline:
>
> ---
>
> slob: fix free block merging at head of subpage
>
> We weren't merging freed blocks at the beginning of the free list.
> Fixing
Hi Christoph,
On Sat, 5 Jan 2008, Pekka J Enberg wrote:
> > So, I have this silly memory profiler derived from the kleak patches by
> > the relayfs people and would love to try it out on an embedded workload
> > where SLUB memory footprint is terrible. Any suggestions?
Hi Matt,
On Sun, 6 Jan 2008, Matt Mackall wrote:
> I don't have any particular "terrible" workloads for SLUB. But my
> attempts to simply boot with all three allocators to init=/bin/bash in,
> say, lguest show a fair margin for SLOB.
Sorry, I once again have bad news ;-). I did some testing with
Hi Greg,
On Mon, 7 Jan 2008, Greg KH wrote:
> This feels to me like a "feature addition", and as such, I don't think
> it is aplicable for the .23-stable tree.
It's an ABI regression (slabtop, for example, doesn't work) when
CONFIG_SLUB is enabled.
Pekka
--
To
From: Pekka Enberg <[EMAIL PROTECTED]>
[ Upstream commits: 57ed3eda977a215f054102b460ab0eb5d8d112e6,
6b6adc22a01941165d5af9a3e69e28e948b28f47, and
158a962422e4a54dc256b6a9b9562f3d30d34d9c ]
This adds a read-only /proc/slabinfo file on SLUB, that makes slabtop work.
[ [EMAIL PROTECTED]:
From: Pekka Enberg [EMAIL PROTECTED]
[ Upstream commits: 57ed3eda977a215f054102b460ab0eb5d8d112e6,
6b6adc22a01941165d5af9a3e69e28e948b28f47, and
158a962422e4a54dc256b6a9b9562f3d30d34d9c ]
This adds a read-only /proc/slabinfo file on SLUB, that makes slabtop work.
[ [EMAIL PROTECTED]: build
Hi Greg,
On Mon, 7 Jan 2008, Greg KH wrote:
This feels to me like a feature addition, and as such, I don't think
it is aplicable for the .23-stable tree.
It's an ABI regression (slabtop, for example, doesn't work) when
CONFIG_SLUB is enabled.
Pekka
--
To unsubscribe
Hi Matt,
On Sun, 6 Jan 2008, Matt Mackall wrote:
I don't have any particular terrible workloads for SLUB. But my
attempts to simply boot with all three allocators to init=/bin/bash in,
say, lguest show a fair margin for SLOB.
Sorry, I once again have bad news ;-). I did some testing with
Hi Christoph,
On Sat, 5 Jan 2008, Pekka J Enberg wrote:
So, I have this silly memory profiler derived from the kleak patches by
the relayfs people and would love to try it out on an embedded workload
where SLUB memory footprint is terrible. Any suggestions?
On Sat, 5 Jan 2008, Christoph
Hi Matt,
On Mon, 7 Jan 2008, Matt Mackall wrote:
Fascinating. Which kernel version are you using? This patch doesn't seem
to have made it to mainline:
---
slob: fix free block merging at head of subpage
We weren't merging freed blocks at the beginning of the free list.
Fixing this
Hi Matt,
On Thu, 3 Jan 2008, Matt Mackall wrote:
> > SLUB can align these without a 2 byte
> > overhead. In some configurations this results in SLUB using even less
> > memory than SLOB. See f.e. Pekka's test at
> > http://marc.info/?l=linux-kernel=118405559214029=2
>
> Available memory
Hi Matt,
On Thu, 3 Jan 2008, Matt Mackall wrote:
SLUB can align these without a 2 byte
overhead. In some configurations this results in SLUB using even less
memory than SLOB. See f.e. Pekka's test at
http://marc.info/?l=linux-kernelm=118405559214029w=2
Available memory after boot
Hi Jiri,
On Thu, 3 Jan 2008, Jiri Slaby wrote:
> this happened, while playing with broken dvd.
[snip]
> Buffer I/O error on device sr0, logical block 5441
> end_request: I/O error, dev sr0, sector 136
> ISOFS: unable to read i-node block
> Unable to handle kernel NULL pointer dereference at
Hi Jiri,
On Thu, 3 Jan 2008, Jiri Slaby wrote:
this happened, while playing with broken dvd.
[snip]
Buffer I/O error on device sr0, logical block 5441
end_request: I/O error, dev sr0, sector 136
ISOFS: unable to read i-node block
Unable to handle kernel NULL pointer dereference at
Hi Marcin,
On Thu, 27 Dec 2007, Marcin Slusarz wrote:
> * alloc_slabmgmt: initialize all slab fields in 1 function
> * slab->nodeid was initialized twice: in alloc_slabmgmt
> and immediately after it in cache_grow
Looks good to me.
Reviewed-by: Pekka Enberg <[EMAIL PROTECTED]>
--
To
Hi Marcin,
On Thu, 27 Dec 2007, Marcin Slusarz wrote:
* alloc_slabmgmt: initialize all slab fields in 1 function
* slab-nodeid was initialized twice: in alloc_slabmgmt
and immediately after it in cache_grow
Looks good to me.
Reviewed-by: Pekka Enberg [EMAIL PROTECTED]
--
To unsubscribe
From: Pekka Enberg <[EMAIL PROTECTED]>
This adds a read-only /proc/slabinfo file that is ABI compatible with SLAB for
SLUB.
Cc: Ingo Molnar <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
Cc: Christoph Lameter <[EMAIL PROTECTED]>
Cc: Peter Zijlstra <[EMAIL PROTECTED]>
Signed-off-by: Pekka
From: Pekka Enberg [EMAIL PROTECTED]
This adds a read-only /proc/slabinfo file that is ABI compatible with SLAB for
SLUB.
Cc: Ingo Molnar [EMAIL PROTECTED]
Cc: Andi Kleen [EMAIL PROTECTED]
Cc: Christoph Lameter [EMAIL PROTECTED]
Cc: Peter Zijlstra [EMAIL PROTECTED]
Signed-off-by: Pekka Enberg
Hi,
On Wed, 19 Dec 2007, Serge E. Hallyn wrote:
> > I assume you mean S_REVOKE_LOCK and not ->i_mutex, right?
>
> No I did mean the i_mutex since you take the i_mutex when you set
> S_REVOKE_LOCK. So between that and the comment above do_lookup(),
> I assumed you were trying to lock out
Hi Jonathan,
(Thanks for the review!)
On Tue, 18 Dec 2007, Jonathan Corbet wrote:
> This is a relatively minor detail in the rather bigger context of this
> patch, but...
>
> > @@ -642,6 +644,7 @@ struct inode {
> > struct list_headinotify_watches; /* watches on this inode */
> >
Hi Jonathan,
(Thanks for the review!)
On Tue, 18 Dec 2007, Jonathan Corbet wrote:
This is a relatively minor detail in the rather bigger context of this
patch, but...
@@ -642,6 +644,7 @@ struct inode {
struct list_headinotify_watches; /* watches on this inode */
struct
Hi,
On Wed, 19 Dec 2007, Serge E. Hallyn wrote:
I assume you mean S_REVOKE_LOCK and not -i_mutex, right?
No I did mean the i_mutex since you take the i_mutex when you set
S_REVOKE_LOCK. So between that and the comment above do_lookup(),
I assumed you were trying to lock out concurrent
Hi Serge,
(Thanks for looking at this. I appreciate the review!)
On Mon, 17 Dec 2007, [EMAIL PROTECTED] wrote:
> > struct vfsmount *mnt = nd->mnt;
> > - struct dentry *dentry = __d_lookup(nd->dentry, name);
> > + struct dentry *dentry;
> >
> > +again:
> > + dentry =
Hi John,
On Mon, 17 Dec 2007, John Reiser wrote:
> idr_pre_get calls kmem_cache_alloc, which constructs 'struct idr_layer'
> via the cachep->ctor() call from cache_alloc_debugcheck_after to
> idr_cache_ctor, and not via cache_init_objs. So if DEBUG is off,
> then idr_cache_ctor does not get its
Hi John,
On Mon, 17 Dec 2007, John Reiser wrote:
idr_pre_get calls kmem_cache_alloc, which constructs 'struct idr_layer'
via the cachep-ctor() call from cache_alloc_debugcheck_after to
idr_cache_ctor, and not via cache_init_objs. So if DEBUG is off,
then idr_cache_ctor does not get its
Hi Serge,
(Thanks for looking at this. I appreciate the review!)
On Mon, 17 Dec 2007, [EMAIL PROTECTED] wrote:
struct vfsmount *mnt = nd-mnt;
- struct dentry *dentry = __d_lookup(nd-dentry, name);
+ struct dentry *dentry;
+again:
+ dentry = __d_lookup(nd-dentry, name);
From: Pekka Enberg <[EMAIL PROTECTED]>
Add the ->revoke() file operation to VFS documentation.
Cc: Alan Cox <[EMAIL PROTECTED]>
Cc: Al Viro <[EMAIL PROTECTED]>
Cc: Christoph Hellwig <[EMAIL PROTECTED]>
Cc: Peter Zijlstra <[EMAIL PROTECTED]>
Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
---
From: Pekka Enberg <[EMAIL PROTECTED]>
Add revoke support to ext2, ext3 and ext4 by wiring f_ops->revoke with
generic_file_revoke.
Cc: Alan Cox <[EMAIL PROTECTED]>
Cc: Al Viro <[EMAIL PROTECTED]>
Cc: Christoph Hellwig <[EMAIL PROTECTED]>
Cc: Peter Zijlstra <[EMAIL PROTECTED]>
Signed-off-by:
From: Pekka Enberg <[EMAIL PROTECTED]>
Make revokeat system call available to user-space on i386.
[EMAIL PROTECTED]: fix 32-bit userspace]
Cc: Alan Cox <[EMAIL PROTECTED]>
Cc: Al Viro <[EMAIL PROTECTED]>
Cc: Christoph Hellwig <[EMAIL PROTECTED]>
Cc: Peter Zijlstra <[EMAIL PROTECTED]>
From: Pekka Enberg <[EMAIL PROTECTED]>
Add fs/revoke.c and fs/revoked_inode.c to build when CONFIG_MMU is enabled.
Cc: Alan Cox <[EMAIL PROTECTED]>
Cc: Al Viro <[EMAIL PROTECTED]>
Cc: Christoph Hellwig <[EMAIL PROTECTED]>
Cc: Peter Zijlstra <[EMAIL PROTECTED]>
Signed-off-by: Pekka Enberg <[EMAIL
From: Pekka Enberg <[EMAIL PROTECTED]>
The revokeat(2) system call ensures that after successful revocation you can
only access an inode via a file descriptor that is obtained from a subsequent
open(2) call. The open(2) system call can be blocked by the caller with
chmod(2) and chown(2) prior to
From: Pekka Enberg <[EMAIL PROTECTED]>
Add file, inode, and addresspace operations for inodes that represent revoked
files.
Cc: Alan Cox <[EMAIL PROTECTED]>
Cc: Al Viro <[EMAIL PROTECTED]>
Cc: Christoph Hellwig <[EMAIL PROTECTED]>
Cc: Peter Zijlstra <[EMAIL PROTECTED]>
Signed-off-by: Pekka
From: Pekka Enberg <[EMAIL PROTECTED]>
The revoke operation cannibalizes the revoked struct inode and removes it from
the inode cache thus forcing subsequent callers to look up the real inode.
Therefore we must make sure that while the revoke operation is in progress
(e.g. flushing dirty pages to
From: Pekka Enberg <[EMAIL PROTECTED]>
This adds special handling for revoked shared memory mappings. We want to
raise SIGBUS if someone accesses a revoked mapping and return ENODEV if
somebody tries to remap one with mmap(2).
Cc: Alan Cox <[EMAIL PROTECTED]>
Cc: Al Viro <[EMAIL PROTECTED]>
Cc:
On Thu, 13 Dec 2007, Christoph Lameter wrote:
> Remove a recently added useless masking of GFP_ZERO. GFP_ZERO is
> already masked out in new_slab() (See how it calls allocate_slab). No need
> to do it twice. This reverts the SLUB parts of
> 7fd272550bd43cc1d7289ef0ab2fa50de137e767.
Oh noes,
On Thu, 13 Dec 2007, Christoph Lameter wrote:
Remove a recently added useless masking of GFP_ZERO. GFP_ZERO is
already masked out in new_slab() (See how it calls allocate_slab). No need
to do it twice. This reverts the SLUB parts of
7fd272550bd43cc1d7289ef0ab2fa50de137e767.
Oh noes, brown
From: Pekka Enberg [EMAIL PROTECTED]
Add the -revoke() file operation to VFS documentation.
Cc: Alan Cox [EMAIL PROTECTED]
Cc: Al Viro [EMAIL PROTECTED]
Cc: Christoph Hellwig [EMAIL PROTECTED]
Cc: Peter Zijlstra [EMAIL PROTECTED]
Signed-off-by: Pekka Enberg [EMAIL PROTECTED]
---
From: Pekka Enberg [EMAIL PROTECTED]
Add revoke support to ext2, ext3 and ext4 by wiring f_ops-revoke with
generic_file_revoke.
Cc: Alan Cox [EMAIL PROTECTED]
Cc: Al Viro [EMAIL PROTECTED]
Cc: Christoph Hellwig [EMAIL PROTECTED]
Cc: Peter Zijlstra [EMAIL PROTECTED]
Signed-off-by: Pekka Enberg
From: Pekka Enberg [EMAIL PROTECTED]
Add fs/revoke.c and fs/revoked_inode.c to build when CONFIG_MMU is enabled.
Cc: Alan Cox [EMAIL PROTECTED]
Cc: Al Viro [EMAIL PROTECTED]
Cc: Christoph Hellwig [EMAIL PROTECTED]
Cc: Peter Zijlstra [EMAIL PROTECTED]
Signed-off-by: Pekka Enberg [EMAIL PROTECTED]
From: Pekka Enberg [EMAIL PROTECTED]
Add file, inode, and addresspace operations for inodes that represent revoked
files.
Cc: Alan Cox [EMAIL PROTECTED]
Cc: Al Viro [EMAIL PROTECTED]
Cc: Christoph Hellwig [EMAIL PROTECTED]
Cc: Peter Zijlstra [EMAIL PROTECTED]
Signed-off-by: Pekka Enberg [EMAIL
From: Pekka Enberg [EMAIL PROTECTED]
The revokeat(2) system call ensures that after successful revocation you can
only access an inode via a file descriptor that is obtained from a subsequent
open(2) call. The open(2) system call can be blocked by the caller with
chmod(2) and chown(2) prior to
From: Pekka Enberg [EMAIL PROTECTED]
The revoke operation cannibalizes the revoked struct inode and removes it from
the inode cache thus forcing subsequent callers to look up the real inode.
Therefore we must make sure that while the revoke operation is in progress
(e.g. flushing dirty pages to
From: Pekka Enberg [EMAIL PROTECTED]
This adds special handling for revoked shared memory mappings. We want to
raise SIGBUS if someone accesses a revoked mapping and return ENODEV if
somebody tries to remap one with mmap(2).
Cc: Alan Cox [EMAIL PROTECTED]
Cc: Al Viro [EMAIL PROTECTED]
Cc:
From: Pekka Enberg [EMAIL PROTECTED]
Make revokeat system call available to user-space on i386.
[EMAIL PROTECTED]: fix 32-bit userspace]
Cc: Alan Cox [EMAIL PROTECTED]
Cc: Al Viro [EMAIL PROTECTED]
Cc: Christoph Hellwig [EMAIL PROTECTED]
Cc: Peter Zijlstra [EMAIL PROTECTED]
Signed-off-by: Pekka
Hi Dave,
On Tue, 4 Dec 2007, Dave Young wrote:
> the kobject reference is get in kobject_init, and then kobject_add, if
> kobject_add fail, it will only cleanup the reference got by itsself.
>
> This topic is discussed in:
> http://lkml.org/lkml/2007/11/30/9
Ok, thanks! Please the explanation
Hi Dave,
On Tue, 4 Dec 2007, Dave Young wrote:
the kobject reference is get in kobject_init, and then kobject_add, if
kobject_add fail, it will only cleanup the reference got by itsself.
This topic is discussed in:
http://lkml.org/lkml/2007/11/30/9
Ok, thanks! Please the explanation to the
Hi,
On Thu, 29 Nov 2007 12:05:13 -0700 Matthew Wilcox <[EMAIL PROTECTED]> wrote:
> > The database performance group have found that half the cycles spent
> > in kmem_cache_free are spent in this one call to BUG_ON. Moving it
> > into the CONFIG_SLAB_DEBUG-only function cache_free_debugcheck() is
Hi,
On Thu, 29 Nov 2007 12:05:13 -0700 Matthew Wilcox [EMAIL PROTECTED] wrote:
The database performance group have found that half the cycles spent
in kmem_cache_free are spent in this one call to BUG_ON. Moving it
into the CONFIG_SLAB_DEBUG-only function cache_free_debugcheck() is a
1 - 100 of 518 matches
Mail list logo
