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
15 matches
Mail list logo