Nick Piggin wrote:
This should work because the result gets used before reading again:
read_cr3(a);
write_cr3(a | 1);
read_cr3(a);
But this might be reordered so that b gets read before the write:
read_cr3(a);
write_cr3(a | 1);
read_cr3(b);
?
I don't see how, as write_cr3 clobbers memory.
Christoph Lameter wrote:
On Tue, 2 Oct 2007, Pavel Emelyanov wrote:
Christoph Lameter wrote:
On Mon, 1 Oct 2007, Pavel Emelyanov wrote:
+
Quick check, slub_free_notify() and slab_alloc_notify() are called
from serialized contexts, right?
Yup.
How is it serialized?
They are booth called
[EMAIL PROTECTED] wrote:
Cedric Le Goater [EMAIL PROTECTED] wrote:
|
| however, we have an issue with the signal notification in __do_notify()
| we could kill a process in a different pid namespace.
|
| So I took a quick look at the code as it is (before this patchset)
| and the
Daniel Lezcano wrote:
Eric W. Biederman wrote:
Daniel Lezcano [EMAIL PROTECTED] writes:
The following patch change autobind fonction to use the ordernum
from the network namespace instead of using the local static variable.
Why do we care?
Information leak?
Some application is expecting a
Arjan,
I can experiment with any constraints if you suggest which one.
From our experiments with gcc, it compares asm strings (sic!!!) to find matches
to be merged! Sigh...
Below are 2 programs which differ in one space in read_cr3_b() asm statement.
The first one compiles incorrectly, while 2nd
Eric W. Biederman wrote:
Daniel Lezcano [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
Daniel Lezcano [EMAIL PROTECTED] writes:
The following patch change autobind fonction to use the ordernum
from the network namespace instead of using the local static variable.
Why do we care?
How does the compiler know it doesn't depend on memory?
When it has no m (or equivalent like g) constrained argument
and no memory clobber.
How do you say it depends on memory?
You add any of the above.
You really need something as heavy as volatile?
You could do a memory clobber, but
Eric W. Biederman wrote:
Daniel Lezcano [EMAIL PROTECTED] writes:
Hi,
I was looking at some cornercases and trying to figure out what happens if
someone does:
1 - fd = socket(...)
2 - unshare(CLONE_NEWNET)
3 - bind(fd, ...) / listen(fd, ...)
There is here an interaction between two
On Wednesday 03 October 2007 16:18, H. Peter Anvin wrote:
Nick Piggin wrote:
This should work because the result gets used before reading again:
read_cr3(a);
write_cr3(a | 1);
read_cr3(a);
But this might be reordered so that b gets read before the write:
read_cr3(a);
Denis V. Lunev wrote:
Daniel Lezcano wrote:
Eric W. Biederman wrote:
Daniel Lezcano [EMAIL PROTECTED] writes:
The following patch change autobind fonction to use the ordernum
from the network namespace instead of using the local static variable.
Why do we care?
Information leak?
Some
Some time ago Sukadev noticed that the vmlinux size has
grown 5Kb due to merged pid namespaces. One of the big
problems with it was fat inline functions. The other thing
was noticed by Matt - the checks for task's pid to be not
NULL take place and make the kernel grow due to inlining,
but these
This is a pid which is attached to tasks when they detach
their pids. This is done in detach_pid() and transfer_pid().
The pid_alive() check is changed to reflect this fact.
Signed-off-by: Pavel Emelyanov [EMAIL PROTECTED]
---
diff --git a/include/linux/sched.h b/include/linux/sched.h
index
Since we now have all the tasks have non-zero pids we may
call the __pid_nr() instead of pid_nr() when the pid is
get from task with task_pid() or similar call.
Besides, there are some other places where the check for
pid to be not NULL is already done, so change them too.
Signed-off-by:
There are two places that do so - the cgroups subsystem
and the autofs code.
Signed-off-by: Pavel Emelyanov [EMAIL PROTECTED]
---
diff --git a/fs/autofs/root.c b/fs/autofs/root.c
index 592f640..5efff3c 100644
--- a/fs/autofs/root.c
+++ b/fs/autofs/root.c
@@ -214,7 +214,7 @@ static struct
Just make the __pid_nr() etc functions that expect the argument
to always be not NULL.
Signed-off-by: Pavel Emelyanov [EMAIL PROTECTED]
---
diff --git a/include/linux/pid.h b/include/linux/pid.h
index e29a900..50b6899 100644
--- a/include/linux/pid.h
+++ b/include/linux/pid.h
@@ -135,21 +135,32
On 10/3/07, Paul Jackson [EMAIL PROTECTED] wrote:
- What are these apparent 'exec notifications' that are provided to
user space that the following mentions - I cannot find any other
mention of them:
With the ability to classify tasks differently for different
Eric W. Biederman wrote:
Cedric Le Goater [EMAIL PROTECTED] writes:
my 2 cnts,
when 'restarting' a socket bound to an abstract name, we will have
a EADDRINUSE if we try to rebind it to an abtract name which is
already in use by a socket in a another namespace ?
No.
ok. i just went
On 10/3/07, Paul Jackson [EMAIL PROTECTED] wrote:
From: Paul Jackson [EMAIL PROTECTED]
The code in kernel/cgroup.c attach_task() which skips the
attachment of a task to the group it is already in has to be
removed. Cpusets depends on reattaching a task to its current
cpuset, in order to
On 10/3/07, Pavel Emelyanov [EMAIL PROTECTED] wrote:
+
+ strcpy(files[RES_USAGE].name, usage_in_bytes);
This prevents the resource counters from being used for anything that
doesn't measure its limit/usage in bytes. E.g. number of tasks.
I like the idea of having a unified interface, but
On Wed, Oct 03, 2007 at 06:20:43PM +0400, Pavel Emelyanov wrote:
Just make the __pid_nr() etc functions that expect the argument
to always be not NULL.
Signed-off-by: Pavel Emelyanov [EMAIL PROTECTED]
static inline pid_t pid_nr(struct pid *pid)
{
pid_t nr = 0;
if (pid)
-
Daniel Lezcano [EMAIL PROTECTED] writes:
Yes, it will work.
Do we want to be inside a network namespace and to use a socket belonging to
another network namespace ? If yes, then my remark is irrelevant.
Yes we do.
Shall we close all fd sockets when doing an unshare ? like a close-on-exec
On 10/3/07, Paul Jackson [EMAIL PROTECTED] wrote:
So after changing the 'cpus' of a cpuset, you (something in
user space) then has to rewrite every pid in that cpusets
tasks file back to that same tasks file, in order to get the
change to be applied to each of those tasks, and get them to
On 10/3/07, Paul Menage [EMAIL PROTECTED] wrote:
What's wrong with, in update_cpumask(), doing a loop across all
members of the cgroup and updating their cpus_allowed fields?
i.e. something like:
struct cgroup_iter it;
struct task_struct *p;
while ((p = cgroup_iter_next(cs-css.cgroup, it))) {
Eric W. Biederman wrote:
Daniel Lezcano [EMAIL PROTECTED] writes:
Yes, it will work.
Do we want to be inside a network namespace and to use a socket belonging to
another network namespace ? If yes, then my remark is irrelevant.
Yes we do.
Shall we close all fd sockets when doing an unshare
Paul M wrote:
Given that later in cpusets.txt you say:
If hotplug functionality is used
to remove all the CPUs that are currently assigned to a cpuset,
then the kernel will automatically update the cpus_allowed of all
tasks attached to CPUs in that cpuset to allow all CPUs
why can't the
Andrew - please kill this patch.
Looks like Paul Menage has a better solution
that I will be trying out.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson [EMAIL PROTECTED] 1.925.600.0401
On 10/3/07, Paul Jackson [EMAIL PROTECTED] wrote:
So far as I can tell, this patch just removes a minor optimization,
It's not minor for any subsystem that has a non-trivial attach() operation.
Any further suggestions, or embarrassing (;) questions?
What was wrong with my suggestion from a
On 10/3/07, Paul Jackson [EMAIL PROTECTED] wrote:
But now (correct me if I'm wrong here) cgroups has a per-cgroup task
list, and the above loop has cost linear in the number of tasks
actually in the cgroup, plus (unfortunate but necessary and tolerable)
the cost of taking a global
- There are many instances of the local variable 'cont', referring
to a struct cgroup pointer. I presume the spelling 'cont' is a
holdover from the time when we called these containers.
Yes, and since cgroup is short for control group, cont still
seemed like a reasonable
On 10/3/07, Paul Jackson [EMAIL PROTECTED] wrote:
I can't say for sure, but I suspect that if cgroups had always
been cgroups (short for control groups), then these local 'cont'
variables would have a different name.
Oh, absolutely. I just refrained from changing them in the rename
since the
One more cgroup code review detail ...
The following is evidence of some more stale comments in
kernel/cpuset.c. Some routines which used to be in that file, but
which are now reimplemented in cgroups, are still named in cpuset.c
comments:
$ grep -E 'cpuset_rmdir|cpuset_exit|cpuset_fork'
hi,
i implemented some statistics for your memory controller.
it's tested with 2.6.23-rc2-mm2 + memory controller v7.
i think it can be applied to 2.6.23-rc4-mm1 as well.
YAMOMOTO Takshi
todo: something like nr_active/inactive in /proc/vmstat.
here's the version i'm working on
32 matches
Mail list logo
