On Wed, Dec 12, 2007 at 12:27:01PM +0100, Enrico Weigelt wrote:
> No I'd like to request an feature for catching the console.
> IMHO, it's enough to have an option to vzctl start, which tells
> it to not to detach and bring the VE's console to the current tty.
Unfortunately this is much trickier t
David Miller wrote:
> From: "Denis V. Lunev" <[EMAIL PROTECTED]>
> Date: Wed, 12 Dec 2007 14:05:55 +0300
>
>> -static int halve_threshold = 25;
>> -static int inflate_threshold = 50;
>> -static int halve_threshold_root = 15;
>> -static int inflate_threshold_root = 25;
>
> halve_threshold_root and
Hi all,
here is a patch for vzctl to catch init output. output is written to
VEROOT/var/log/init.log
I tested it with some debian templates (sysvinit), but it would be great is
someone else tries/test it with other templates.
- Dietmar
> -Ursprüngliche Nachricht-
> Von: [EMAIL PROTEC
[IPV4] Thresholds in fib_trie.c are used as consts, so make them const.
There are several thresholds for trie fib hash management. They are used
in the code as a constants. Make them constants from the compiler point of
view.
Signed-off-by: Denis V. Lunev <[EMAIL PROTECTED]>
---
diff --git a/net/
* Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> /proc/timer_stats currently reports the user of a timer by pid, which
> is a reasonable approach. However if you are not in the initial pid
> namespace the pid that is reported is nonsense.
>
> Therefore until we can make timer_stats pid namesp
The _find calls calculate the hash value using the
xfrm_state_hmask, without the xfrm_state_lock. But the
value of this mask can change in the _resize call under
the state_lock, so we risk to fail in finding the desired
entry in hash.
I think, that the hash value is better to calculate
under th
Ingo Molnar <[EMAIL PROTECTED]> writes:
> * Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>
>> /proc/timer_stats currently reports the user of a timer by pid, which
>> is a reasonable approach. However if you are not in the initial pid
>> namespace the pid that is reported is nonsense.
>>
>> Th
Hi all,
I'm working on a xen to openvz migration, and I still have some issue to fix.
but some seem to be not possible yet.
actually, on our diskless servers (xen and others), we are using nfsroot. And at start, in the initrd, we are using a script
that make a connexion on the nfs boot server
* Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> > What the heck??? Please solve this properly instead of hiding it.
> > /proc/timer_stats is damn useful and it's a must-have for powertop
> > to work.
>
> Hmm. Perhaps the dependency conflict should go in the other direction
> then.
>
> My g
[IPV6] Always pass a valid nl_info to inet6_rt_notify.
This makes the code in the inet6_rt_notify more straightforward and provides
groud for namespace passing.
Signed-off-by: Denis V. Lunev <[EMAIL PROTECTED]>
---
net/ipv6/ip6_fib.c |3 ++-
net/ipv6/route.c | 27 +---
On 12 December 2007 21:42:25 Serge E. Hallyn wrote:
> Ok sorry - by letting this thread sit a few days I lost track of where
> we were.
>
> I see now, so you're saying fl_pid for nfs is not in fact a task pid.
> It's a magically derived unique id. (And you say it is unique across
> all the nfs cli
There are to many spaces between type and function name in the declaration
of fib rules manipulation routines. Eat them and save a couple of lines.
Signed-off-by: Denis V. Lunev <[EMAIL PROTECTED]>
---
include/net/fib_rules.h | 16 +++-
1 files changed, 7 insertions(+), 9 deletions(
On Thu, Dec 13, 2007 at 05:18:42PM +0300, Denis V. Lunev wrote:
> There are to many spaces between type and function name in the declaration
> of fib rules manipulation routines. Eat them and save a couple of lines.
If this patch is going in, it would be nice to get rid of "extern" as
well.
From: "Denis V. Lunev" <[EMAIL PROTECTED]>
Date: Thu, 13 Dec 2007 17:18:42 +0300
> There are to many spaces between type and function name in the declaration
> of fib rules manipulation routines. Eat them and save a couple of lines.
>
> Signed-off-by: Denis V. Lunev <[EMAIL PROTECTED]>
This is j
David Miller wrote:
> From: "Denis V. Lunev" <[EMAIL PROTECTED]>
> Date: Thu, 13 Dec 2007 17:18:42 +0300
>
>> There are to many spaces between type and function name in the declaration
>> of fib rules manipulation routines. Eat them and save a couple of lines.
>>
>> Signed-off-by: Denis V. Lunev <
From: Alexey Dobriyan <[EMAIL PROTECTED]>
Date: Thu, 13 Dec 2007 17:47:07 +0300
> On Thu, Dec 13, 2007 at 05:18:42PM +0300, Denis V. Lunev wrote:
> > There are to many spaces between type and function name in the declaration
> > of fib rules manipulation routines. Eat them and save a couple of lin
From: "Denis V. Lunev" <[EMAIL PROTECTED]>
Date: Thu, 13 Dec 2007 18:01:32 +0300
> Could you still apply it, or I will need to send fully functional set to
> you including this?
Please combine the changes so that when you change the args
you fixup the whitespace as well.
Oleg Nesterov <[EMAIL PROTECTED]> writes:
> Sorry for the delay, and sorry, can't read this series carefully now.
> A couple of question though.
>
> On 12/12, Eric W. Biederman wrote:
>>
>> Currently task_active_pid_ns is not safe to call after a
>> task becomes a zombie and exit_task_namespaces i
On 12/12, Eric W. Biederman wrote:
>
> -static int is_sig_init(struct task_struct *tsk)
> +static int is_sig_init(struct task_struct *init, struct pid *sender)
> {
> - if (likely(!is_global_init(tsk->group_leader)))
> + if (!is_container_init(init))
> + return 0;
> +
> + i
Sorry for the delay, and sorry, can't read this series carefully now.
A couple of question though.
On 12/12, Eric W. Biederman wrote:
>
> Currently task_active_pid_ns is not safe to call after a
> task becomes a zombie and exit_task_namespaces is called,
> as nsproxy becomes NULL. By reading the
Quoting Vitaliy Gusev ([EMAIL PROTECTED]):
> On 12 December 2007 21:42:25 Serge E. Hallyn wrote:
> > Ok sorry - by letting this thread sit a few days I lost track of where
> > we were.
> >
> > I see now, so you're saying fl_pid for nfs is not in fact a task pid.
> > It's a magically derived unique
On 12/12, Eric W. Biederman wrote:
>
> By making the rule (for init dropping signals):
> When sending a signal to init, the presence of a signal handler that
> is not SIG_DFL allows the signal to be sent to init. If the signal
> is not sent it is silently dropped without becoming pending.
But is
On 12/13, Eric W. Biederman wrote:
>
> Oleg Nesterov <[EMAIL PROTECTED]> writes:
>
> > On 12/12, Eric W. Biederman wrote:
> >>
> >> Currently task_active_pid_ns is not safe to call after a
> >> task becomes a zombie and exit_task_namespaces is called,
> >> as nsproxy becomes NULL. By reading the
Ingo Molnar <[EMAIL PROTECTED]> writes:
> * Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>
>> > What the heck??? Please solve this properly instead of hiding it.
>> > /proc/timer_stats is damn useful and it's a must-have for powertop
>> > to work.
>>
>> Hmm. Perhaps the dependency conflict sho
Oleg Nesterov <[EMAIL PROTECTED]> writes:
> On 12/12, Eric W. Biederman wrote:
>>
>> By making the rule (for init dropping signals):
>> When sending a signal to init, the presence of a signal handler that
>> is not SIG_DFL allows the signal to be sent to init. If the signal
>> is not sent it is
From: "Denis V. Lunev" <[EMAIL PROTECTED]>
Date: Thu, 13 Dec 2007 11:06:18 +0300
> [IPV4] Thresholds in fib_trie.c are used as consts, so make them const.
>
> There are several thresholds for trie fib hash management. They are used
> in the code as a constants. Make them constants from the compil
From: "Denis V. Lunev" <[EMAIL PROTECTED]>
Date: Thu, 13 Dec 2007 16:58:54 +0300
> [IPV6] Always pass a valid nl_info to inet6_rt_notify.
>
> This makes the code in the inet6_rt_notify more straightforward and provides
> groud for namespace passing.
>
> Signed-off-by: Denis V. Lunev <[EMAIL PROT
Oleg Nesterov <[EMAIL PROTECTED]> writes:
> On 12/12, Eric W. Biederman wrote:
>>
>> -static int is_sig_init(struct task_struct *tsk)
>> +static int is_sig_init(struct task_struct *init, struct pid *sender)
>> {
>> -if (likely(!is_global_init(tsk->group_leader)))
>> +if (!is_container_in
On 12/13, Eric W. Biederman wrote:
>
> Oleg Nesterov <[EMAIL PROTECTED]> writes:
>
> > So, do you mean we can ignore the problems with the signals which are
> > currently blocked by /sbin/init?
>
> Yes. Further I am saying those signals will never become pending if
> we do not have a signal hand
[EMAIL PROTECTED] (Eric W. Biederman) writes:
>
> Yes. If we are not in process context (in_interrupt) we do infer
> the sender incorrectly. Duh. I saw something in earlier patches
> people had posted didn't understand it, and didn't get an answer
> when I asked about it.
Grr. Rather I didn't
Oleg Nesterov <[EMAIL PROTECTED]> writes:
> OK, if we change the semantics for /sbin/init signals we can avoid
> a lot of problems,
Yes. Otherwise we must track the source of the signals.
>> No. We should treat signals that we process for /sbin/init completely
>> normally.
>
> ... including th
* Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> > the problem is, this interface stores historic PIDs too - i.e. PIDs
> > of tasks that might have exited already.
>
> Well struct pid * works in that case if you grab the reference to it.
but the display of the stats might happen much later. Th
Ingo Molnar <[EMAIL PROTECTED]> writes:
> * Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>
>> > the problem is, this interface stores historic PIDs too - i.e. PIDs
>> > of tasks that might have exited already.
>>
>> Well struct pid * works in that case if you grab the reference to it.
>
> but th
* Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> >> Well struct pid * works in that case if you grab the reference to
> >> it.
> >
> > but the display of the stats might happen much later. The point of
> > this API is to save pid+comm, which gives users a good idea about
> > what caused the ev
Ingo Molnar <[EMAIL PROTECTED]> writes:
> * Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>
>> >> Well struct pid * works in that case if you grab the reference to
>> >> it.
>> >
>> > but the display of the stats might happen much later. The point of
>> > this API is to save pid+comm, which gives
Hi,
While I was testing 2.6.24-rc5-mm1's fair group scheduler (with cgroup),
the system hangs. please confirm. it's reproducible on my box.
My test program is attached.
What happens:
the system hangs. (panic ?)
Environ:
ia64/NUMA 8CPU systems. 4 cpus per node.
How to reproduce:
Compile a
36 matches
Mail list logo
