All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Anirban Sinha" <ASinha@zeugmasystems.com>
To: "Darren Hart" <dvhltc@us.ibm.com>
Cc: "Ingo Molnar" <mingo@elte.hu>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Peter Zijlstra" <a.p.zijlstra@chello.nl>,
	<linux-kernel@vger.kernel.org>,
	"Kaz Kylheku" <KKylheku@zeugmasystems.com>
Subject: RE: futex question
Date: Fri, 2 Oct 2009 17:36:59 -0700	[thread overview]
Message-ID: <DDFD17CC94A9BD49A82147DDF7D545C501FD860D@exchange.ZeugmaSystems.local> (raw)
In-Reply-To: <4AC68F13.8050601@us.ibm.com>

>
>
>Thanks for sending the patch.  I'm looking into it now.  Couple
questions:
>
>1) What caused you to instrument this path in the first place?  Were
you
>seeing some unexpected behavior?

Basically, all this started as a means to aid debug or at least isolate
cases of memory corruption. When a process holding a futex died, the
robust futex cleanup operation can be foiled if there are any memory
corruptions in the user land. The "carefully inspecting the user land
linked list" part would bail out silently. So no process would get
EOWNERDEAD and wake up. So we decided to add printks so that we can
track these silent return cases.

We thought that actual number of cases of silently bailing out would be
rare so we did not expect any of those logs in the kernel buffer under
regular circumstances. To our surprise, we found lots of those logs!
This puzzled us.  I looked at the code again and again but it deed some
seem to have any issues. Then it occurred to us (kaz) that an execve()
call can also cause invalid pointer values to remain in the task
structure. I did some testing and it seemed to indicate that this was
indeed the case.

There is a discussion on this by Kaz on the linux mips mailing list:

http://www.linux-mips.org/archives/linux-mips/2009-09/msg00130.html



>
>2) I wonder why we would need to clear the robust list, but I don't see
>other things like pi_blocked_on, etc. in execve being cleared. 

Yea, may be. We don't use pi-futexes, so not too much confident of the
pi futex codebase there. You can look into those too.


 I'm
>looking into this now (perhaps we don't do the same cleanup, need to
>check).... have to get on the plane...

Have a good trip and thanks for looking into it. :)

Ani

>>
>>
>> Signed-off-by: Anirban Sinha <asinha@zeugmasystems.com>
>> ---
>>  fs/compat.c |    3 +++
>>  fs/exec.c   |    3 +++
>>  2 files changed, 6 insertions(+), 0 deletions(-)
>>
>> diff --git a/fs/compat.c b/fs/compat.c
>> index 6d6f98f..c3d117c 100644
>> --- a/fs/compat.c
>> +++ b/fs/compat.c
>> @@ -1510,6 +1510,9 @@ int compat_do_execve(char * filename,
>>         if (retval)
>>                 goto out_file;
>>
>> +#ifdef CONFIG_FUTEX
>> +       current->compat_robust_list = NULL;
>> +#endif
>>         bprm->argc = compat_count(argv, MAX_ARG_STRINGS);
>>         if ((retval = bprm->argc) < 0)
>>                 goto out;
>> diff --git a/fs/exec.c b/fs/exec.c
>> index 172ceb6..e9334b8 100644
>> --- a/fs/exec.c
>> +++ b/fs/exec.c
>> @@ -1323,6 +1323,9 @@ int do_execve(char * filename,
>>         retval = bprm_mm_init(bprm);
>>         if (retval)
>>                 goto out_file;
>> +#ifdef CONFIG_FUTEX
>> +       current->robust_list = NULL;
>> +#endif
>>
>>         bprm->argc = count(argv, MAX_ARG_STRINGS);
>>         if ((retval = bprm->argc) < 0)
>>
>>
>
>
>--
>Darren Hart
>IBM Linux Technology Center
>Real-Time Linux Team

  reply	other threads:[~2009-10-03  0:37 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-30  1:10 futex question Anirban Sinha
2009-10-01  9:22 ` Ingo Molnar
2009-10-01 16:54   ` Anirban Sinha
2009-10-01 23:46   ` Anirban Sinha
2009-10-02 23:38     ` Darren Hart
2009-10-03  0:36       ` Anirban Sinha [this message]
2009-10-03  4:14         ` Eric Dumazet
2009-10-04  8:44       ` Thomas Gleixner
     [not found]         ` <DDFD17CC94A9BD49A82147DDF7D545C501F457C5@exchange.ZeugmaSystems.local>
2009-10-04 16:37           ` Anirban Sinha
2009-10-04 16:59             ` Thomas Gleixner
2009-10-05 10:36               ` Peter Zijlstra
2009-10-05 10:56                 ` Thomas Gleixner
2009-10-05 11:16                   ` Peter Zijlstra
2009-10-05 11:19                     ` Ingo Molnar
2009-10-05 11:50                       ` Thomas Gleixner
2009-10-05 11:47                     ` Thomas Gleixner
2009-10-05 13:11                       ` Anirban Sinha
2009-10-05 13:28                         ` Thomas Gleixner
2009-10-05 14:03                           ` Anirban Sinha
2009-10-05 18:36                             ` Anirban Sinha
2009-10-05 11:58                 ` Peter Zijlstra
2009-10-05 11:59                   ` Thomas Gleixner
2009-10-05 12:18                     ` Peter Zijlstra
2009-10-05 12:24                       ` Ingo Molnar
2009-10-05 14:09                         ` Darren Hart
2009-10-05 18:11                 ` Anirban Sinha

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DDFD17CC94A9BD49A82147DDF7D545C501FD860D@exchange.ZeugmaSystems.local \
    --to=asinha@zeugmasystems.com \
    --cc=KKylheku@zeugmasystems.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=dvhltc@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.