There are many places in the kernel where the construction like
foo = list_entry(head->next, struct foo_struct, list);
are used.
The code might look more descriptive and neat if using the macro
list_first_entry(head, type, member) \
list_entry((head)->next, type, member)
Her
[snip]
> --- linux-2.6.orig/net/bridge/br_private.h2007-04-17
> 13:26:48.0 -0700 +++ linux-2.6/net/bridge/br_private.h
> 2007-04-17 13:30:29.0 -0700 @@ -36,7 +36,7 @@
> {
> unsigned char prio[2];
> unsigned char addr[6];
> -};
> +} __attribute__((aligned(8)));
Dave Hansen wrote:
> On Tue, 2007-04-17 at 19:34 +0400, Pavel Emelianov wrote:
>> +#define SHOW_TOP_SLABS 10
>
> Real minor nit on this one: SHOW_TOP_SLABS sounds like a bool. "Should
> I show the top slabs?"
>
> This might be a bit more clear:
>
> #define TOP_NR_SLABS_TO_SHOW 10
>
> or
>
>
On 4/17/07, Pavel Emelianov <[EMAIL PROTECTED]> wrote:
The out_of_memory() function and SysRq-M handler call
show_mem() to show the current memory usage state.
I am still somewhat unhappy about the spinlock, but I don't really
have a better suggestion either. Other than that, looks good to me.
On Tue, 17 Apr 2007, Eric Dumazet wrote:
> This nr_pages should be in struct kmem_list3, not in struct kmem_cache,
> or else you defeat NUMA optimizations if touching a field in kmem_cache
> at kmem_getpages()/kmem_freepages() time.
We already touch ->flags, ->gfpflags, and ->gfporder in kmem_ge
On Tue, 2007-04-17 at 19:34 +0400, Pavel Emelianov wrote:
> > +#define SHOW_TOP_SLABS 10
On Tue, 17 Apr 2007, Dave Hansen wrote:
> Real minor nit on this one: SHOW_TOP_SLABS sounds like a bool. "Should
> I show the top slabs?"
>
> This might be a bit more clear:
>
> #define TOP_NR_SLABS_TO_SHO
On Tue, 17 Apr 2007 15:18:56 +0400 Pavel Emelianov wrote:
> There are many places in the kernel where the construction like
>
>foo = list_entry(head->next, struct foo_struct, list);
>
> are used.
> The code might look more descriptive and neat if using the macro
>
>list_first_entry(hea
On Tue, Apr 17, 2007 at 03:18:56PM +0400, Pavel Emelianov wrote:
> There are many places in the kernel where the construction like
>
>foo = list_entry(head->next, struct foo_struct, list);
>
> are used.
> The code might look more descriptive and neat if using the macro
>
>list_first_ent
On Mon, 16 Apr 2007 14:23:26 +0400 Pavel Emelianov wrote:
> If the kernel OOPS-ed or BUG-ed then it probably should
> considered as tainted. Use die_counter introduced by many
> architectures to determine whether or not the kernel died.
>
> This saves a lot of time explaining oddities in the
> ca
On Tue, 2007-04-17 at 21:43 +0200, Miklos Szeredi wrote:
> > > > I'm a bit lost about what is currently done and who advocates for what.
> > > >
> > > > It seems to me the MNT_ALLOWUSERMNT (or whatever :) flag should be
> > > > propagated. In the /share rbind+chroot example, I assume the admin
>
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Tue, 17 Apr 2007 23:24:36 +0200
> I suspect you missed part of Stephen patch :
>
> (maybe some mailer problem...)
My bad, sorry :(
I pushed the other version of the fix to Linus just now.
I'll put Stephen's version in if he sends me a fixup relative
David Miller a écrit :
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Tue, 17 Apr 2007 13:37:23 -0700
The previous patch relied on the bridge id being aligned by
the compiler (which happens as a side effect). So please use
this instead.
compare_ether_addr() implicitly requires that the addr
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Tue, 17 Apr 2007 13:37:23 -0700
> The previous patch relied on the bridge id being aligned by
> the compiler (which happens as a side effect). So please use
> this instead.
>
> compare_ether_addr() implicitly requires that the addresses
> passed a
The previous patch relied on the bridge id being aligned by
the compiler (which happens as a side effect). So please use
this instead.
compare_ether_addr() implicitly requires that the addresses
passed are 2-bytes aligned in memory.
This is not true for br_stp_change_bridge_id() and
br_stp_recalc
David Miller wrote:
From: Pavel Emelianov <[EMAIL PROTECTED]>
Date: Tue, 17 Apr 2007 15:49:30 +0400
From: Evgeny Kravtsunov <[EMAIL PROTECTED]>
compare_ether_addr() implicitly requires that the addresses
passed are 2-bytes aligned in memory.
This is not true for br_stp_change_bridge_id() a
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Tue, 17 Apr 2007 12:55:41 -0700
> David Miller wrote:
> > From: Pavel Emelianov <[EMAIL PROTECTED]>
> > Date: Tue, 17 Apr 2007 15:49:30 +0400
> >
> >
> >> From: Evgeny Kravtsunov <[EMAIL PROTECTED]>
> >>
> >> compare_ether_addr() implicitly requ
Miklos Szeredi <[EMAIL PROTECTED]> writes:
>> > I'm still not sure, what your problem is.
>>
>> My problem right now is that I see a serious complexity escalation in
>> the user interface that we must support indefinitely.
>>
>> I see us taking a nice powerful concept and seriously watering it d
From: Pavel Emelianov <[EMAIL PROTECTED]>
Date: Mon, 16 Apr 2007 16:08:25 +0400
> Otherwise the following calltrace will lead to a wrong
> lockdep warning:
>
> neigh_proxy_process()
> `- lock(neigh_table->proxy_queue.lock);
> arp_redo /* via tbl->proxy_redo */
> arp_process
> neigh_ev
> > > I'm a bit lost about what is currently done and who advocates for what.
> > >
> > > It seems to me the MNT_ALLOWUSERMNT (or whatever :) flag should be
> > > propagated. In the /share rbind+chroot example, I assume the admin
> > > would start by doing
> > >
> > > mount --bind /share /shar
From: Pavel Emelianov <[EMAIL PROTECTED]>
Date: Tue, 17 Apr 2007 15:49:30 +0400
> From: Evgeny Kravtsunov <[EMAIL PROTECTED]>
>
> compare_ether_addr() implicitly requires that the addresses
> passed are 2-bytes aligned in memory.
>
> This is not true for br_stp_change_bridge_id() and
> br_stp_re
On Tue, 2007-04-17 at 19:44 +0200, Miklos Szeredi wrote:
> > I'm a bit lost about what is currently done and who advocates for what.
> >
> > It seems to me the MNT_ALLOWUSERMNT (or whatever :) flag should be
> > propagated. In the /share rbind+chroot example, I assume the admin
> > would start by
> > mount --make-rshared /
> > mkdir -p /mnt/ns/$USER
> > mount --rbind / /mnt/ns/$USER
> > mount --make-rslave /mnt/ns/$USER
>
> This was my main point - that the tree in which users can mount will be
> a slave of /, so that propagating the "are user mounts allowed" flag
> among peers is safe and
On Tue, 2007-04-17 at 19:34 +0400, Pavel Emelianov wrote:
> +#define SHOW_TOP_SLABS 10
Real minor nit on this one: SHOW_TOP_SLABS sounds like a bool. "Should
I show the top slabs?"
This might be a bit more clear:
#define TOP_NR_SLABS_TO_SHOW 10
or
#define NR_SLABS_TO_SHOW 10
-- Dave
_
> > I'm still not sure, what your problem is.
>
> My problem right now is that I see a serious complexity escalation in
> the user interface that we must support indefinitely.
>
> I see us taking a nice powerful concept and seriously watering it down.
> To some extent we have to avoid confusing s
Miklos Szeredi <[EMAIL PROTECTED]> writes:
> I'm still not sure, what your problem is.
My problem right now is that I see a serious complexity escalation in
the user interface that we must support indefinitely.
I see us taking a nice powerful concept and seriously watering it down.
To some exten
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > I'm a bit lost about what is currently done and who advocates for what.
> >
> > It seems to me the MNT_ALLOWUSERMNT (or whatever :) flag should be
> > propagated. In the /share rbind+chroot example, I assume the admin
> > would start by doing
> >
>
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > > > > > Also for bind-mount and remount operations the flag has to be
> > > > > > propagated
> > > > > > down its propagation tree. Otherwise a unpriviledged mount in a
> > > > > > shared
> > > > > > mount wont get reflected in its peers and slaves
> I'm a bit lost about what is currently done and who advocates for what.
>
> It seems to me the MNT_ALLOWUSERMNT (or whatever :) flag should be
> propagated. In the /share rbind+chroot example, I assume the admin
> would start by doing
>
> mount --bind /share /share
> mount --make-s
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > > > MNT_USER and MNT_USERMNT? I claim no way will people keep those
> > > > straight. How about MNT_ALLOWUSER and MNT_USER?
> > >
> > > Umm, is "allowuser" more clear than "usermnt"? What is allowed to the
> >
> > I think so, yes. One makes it c
The out_of_memory() function and SysRq-M handler call
show_mem() to show the current memory usage state.
This is also helpful to see which slabs are the largest
in the system.
Thanks Pekka for good idea of how to make it better.
The nr_pages is stored on kmem_list3 because:
1. as Eric pointed o
Hi,
On 4/17/07, Pavel Emelianov <[EMAIL PROTECTED]> wrote:
The out_of_memory() function and SysRq-M handler call
show_mem() to show the current memory usage state.
This is also helpful to see which slabs are the largest
in the system.
Makes sense.
On 4/17/07, Pavel Emelianov <[EMAIL PROTECTE
On Tue, 17 Apr 2007 16:22:48 +0300
"Pekka Enberg" <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On 4/17/07, Pavel Emelianov <[EMAIL PROTECTED]> wrote:
> > +static unsigned long get_cache_size(struct kmem_cache *cachep)
> > +{
> > + unsigned long slabs;
> > + struct kmem_list3 *l3;
> > +
Hi Pavel,
At some point in time, I wrote:
> > So, now we have two locks protecting cache_chain? Please explain why
> > you can't use the mutex.
On Tue, 17 Apr 2007, Pavel Emelianov wrote:
> Because OOM can actually happen with this mutex locked. For example
> kmem_cache_create() locks it and call
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
> "Serge E. Hallyn" <[EMAIL PROTECTED]> writes:
> >>
> >> Why are directory permissions not sufficient to allow/deny non-priveleged
> > mounts?
> >> I don't understand that contention yet.
> >
> > The same scenarios laid out previously in this thread.
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > > From: Miklos Szeredi <[EMAIL PROTECTED]>
> > >
> > > If MNT_USERMNT flag is not set in the target vfsmount, then
> >
> > MNT_USER and MNT_USERMNT? I claim no way will people keep those
> > straight. How about MNT_ALLOWUSER and MNT_USER?
>
> Umm
Pavel Emelianov <[EMAIL PROTECTED]> writes:
> There are many places in the kernel where the construction like
>
>foo = list_entry(head->next, struct foo_struct, list);
>
> are used.
> The code might look more descriptive and neat if using the macro
>
>list_first_entry(head, type, membe
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
> "Serge E. Hallyn" <[EMAIL PROTECTED]> writes:
> >>
> >> Why are directory permissions not sufficient to allow/deny non-priveleged
> > mounts?
> >> I don't understand that contention yet.
> >
> > The same scenarios laid out previously in this thread.
Pekka J Enberg wrote:
> Hi Pavel,
>
> At some point in time, I wrote:
>>> So, now we have two locks protecting cache_chain? Please explain why
>>> you can't use the mutex.
>
> On Tue, 17 Apr 2007, Pavel Emelianov wrote:
>> Because OOM can actually happen with this mutex locked. For example
>> kme
Pekka Enberg wrote:
> Hi,
>
> On 4/17/07, Pavel Emelianov <[EMAIL PROTECTED]> wrote:
>> The out_of_memory() function and SysRq-M handler call
>> show_mem() to show the current memory usage state.
>>
>> This is also helpful to see which slabs are the largest
>> in the system.
>
> Makes sense.
Tha
The out_of_memory() function and SysRq-M handler call
show_mem() to show the current memory usage state.
This is also helpful to see which slabs are the largest
in the system.
Signed-off-by: Pavel Emelianov <[EMAIL PROTECTED]>
Signed-off-by: Kirill Korotaev <[EMAIL PROTECTED]>
---
diff --git a/
> > > MNT_USER and MNT_USERMNT? I claim no way will people keep those
> > > straight. How about MNT_ALLOWUSER and MNT_USER?
> >
> > Umm, is "allowuser" more clear than "usermnt"? What is allowed to the
>
> I think so, yes. One makes it clear that we're talking about allowing
> user (something
From: Evgeny Kravtsunov <[EMAIL PROTECTED]>
compare_ether_addr() implicitly requires that the addresses
passed are 2-bytes aligned in memory.
This is not true for br_stp_change_bridge_id() and
br_stp_recalculate_bridge_id() in which one of the addresses
is unsigned char *, and thus may not be 2-b
There are many places in the kernel where the construction like
foo = list_entry(head->next, struct foo_struct, list);
are used.
The code might look more descriptive and neat if using the macro
list_first_entry(head, type, member) \
list_entry((head)->next, type, member)
Her
[double freeing of struct utrace leading to oops in
__rcu_process_callbacks]
Hi, Roland,
utrace debugging you've put into 2.6.21-rc6-mm1 helped. Two double-frees
reproduced:
1) BUG at kernel/utrace.c:176
rcu_utrace_free
utrace_reap
utrace_release_task
release_task
> Interesting
>
> So far even today these things can happen, however they are sufficiently
> unlikely the tools don't account for them.
>
> Once a hostile user can cause them things are more of a problem.
>
> > (Unless you want to tackle each problem legacy tool one at a time to
> > remove p
> > From: Miklos Szeredi <[EMAIL PROTECTED]>
> >
> > If MNT_USERMNT flag is not set in the target vfsmount, then
>
> MNT_USER and MNT_USERMNT? I claim no way will people keep those
> straight. How about MNT_ALLOWUSER and MNT_USER?
Umm, is "allowuser" more clear than "usermnt"? What is allowed
"Serge E. Hallyn" <[EMAIL PROTECTED]> writes:
>>
>> Why are directory permissions not sufficient to allow/deny non-priveleged
> mounts?
>> I don't understand that contention yet.
>
> The same scenarios laid out previously in this thread. I.e.
>
> 1. user hallyn does mount --bind / /home/hallyn/ro
If the kernel OOPS-ed or BUG-ed then it probably should
considered as tainted. Use die_counter introduced by many
architectures to determine whether or not the kernel died.
This saves a lot of time explaining oddities in the
calltrace seen via SysRq-P.
Signed-off-by: Pavel Emelianov <[EMAIL PROTE
On Mon, 2007-04-16 at 23:07 +0200, Karel Zak wrote:
> On Mon, Apr 16, 2007 at 10:39:46AM -0700, Ram Pai wrote:
>
> > This patch disambiguates multiple mount-instances of the same
> > filesystem (or part of the same filesystem), by introducing a new
> > interface /proc/mounts_new. The interface has
49 matches
Mail list logo
