On 16/03/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
"Catalin Marinas" <[EMAIL PROTECTED]> writes:
> It seems to fix the leak. I looked at the logs and proc_set_tty calls
> put_pid twice for pid 245 (the unresolved leak) and get_pid for pid
> 296, which is later passed to put_pid via do_tty_
"Catalin Marinas" <[EMAIL PROTECTED]> writes:
> On 14/03/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>> How does this look?
>
> It seems to fix the leak. I looked at the logs and proc_set_tty calls
> put_pid twice for pid 245 (the unresolved leak) and get_pid for pid
> 296, which is later pas
"Catalin Marinas" <[EMAIL PROTECTED]> writes:
> On 14/03/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>> How does this look?
>
> It seems to fix the leak. I looked at the logs and proc_set_tty calls
> put_pid twice for pid 245 (the unresolved leak) and get_pid for pid
> 296, which is later pas
On 14/03/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
How does this look?
It seems to fix the leak. I looked at the logs and proc_set_tty calls
put_pid twice for pid 245 (the unresolved leak) and get_pid for pid
296, which is later passed to put_pid via do_tty_hangup.
I still get the "erro
How does this look?
I don't have the setup to test this easily, but this bit makes seems to make
sense. I will keep code reviewing and see if I can convince myself that this
is correct or incorrect in the mean time...
diff --git a/drivers/char/tty_io.c b/drivers/char/tty_io.c
index e453268..fc1
On 13/03/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
"Catalin Marinas" <[EMAIL PROTECTED]> writes:
> void proc_clear_tty(struct task_struct *p)
> {
> + struct tty_struct *tty;
> +
> spin_lock_irq(&p->sighand->siglock);
> + tty = p->signal->tty;
> + if (tty) {
> +
"Catalin Marinas" <[EMAIL PROTECTED]> writes:
> On 09/03/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>> If I can manage to focus on this, it looks like the information I need to
>> start fixing this.
>
> I had a look at the second leak reported it seems to be caused by the
> same proc_set_tty
"Catalin Marinas" <[EMAIL PROTECTED]> writes:
> On 09/03/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>> If I can manage to focus on this, it looks like the information I need to
>> start fixing this.
>
> I had a look at the second leak reported it seems to be caused by the
> same proc_set_tty
On 09/03/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
If I can manage to focus on this, it looks like the information I need to
start fixing this.
I had a look at the second leak reported it seems to be caused by the
same proc_set_tty() call but, in this case, there is no
disassociate_tty()
"Catalin Marinas" <[EMAIL PROTECTED]> writes:
> Eric,
>
> For a longer explanation, see the second part of this e-mail. In
> short, the patch below seems to fix this particular leak. I'm not sure
> that's the correct/complete fix as I seem to still get a 2nd report.
> Any info is welcomed.
Sure.
On 09/03/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
"Catalin Marinas" <[EMAIL PROTECTED]> writes:
> On 08/03/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>> "Catalin Marinas" <[EMAIL PROTECTED]> writes:
>
> I think it's only the pid_chain and rcu member that could be placed in
> a list
Eric,
For a longer explanation, see the second part of this e-mail. In
short, the patch below seems to fix this particular leak. I'm not sure
that's the correct/complete fix as I seem to still get a 2nd report.
Any info is welcomed.
diff --git a/drivers/char/tty_io.c b/drivers/char/tty_io.c
inde
"Catalin Marinas" <[EMAIL PROTECTED]> writes:
> On 08/03/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>> "Catalin Marinas" <[EMAIL PROTECTED]> writes:
>
> I think it's only the pid_chain and rcu member that could be placed in
> a list and kmemleak scans the memory for these two offsets as well
On 08/03/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
"Catalin Marinas" <[EMAIL PROTECTED]> writes:
> I'm trying to track down a kmemleak report (on an ARM platform) which
> seems to have appeared with commit
> ab521dc0f8e117fd808d3e425216864d60390500. As I'm not familiar with the
> TTY layer
"Catalin Marinas" <[EMAIL PROTECTED]> writes:
> Hi Eric,
>
> I'm trying to track down a kmemleak report (on an ARM platform) which
> seems to have appeared with commit
> ab521dc0f8e117fd808d3e425216864d60390500. As I'm not familiar with the
> TTY layer at all, is it possible that the above commit
Hi Eric,
I'm trying to track down a kmemleak report (on an ARM platform) which
seems to have appeared with commit
ab521dc0f8e117fd808d3e425216864d60390500. As I'm not familiar with the
TTY layer at all, is it possible that the above commit missed a
put_pid() call on some path?
The /sbin/init app
16 matches
Mail list logo