Re: [PATCH v2] futex: mark get_robust_list as deprecated

[Pavel Emelyanov <xemul@xxxxxxxxxxxxx>]

On 08/03/2012 03:02 PM, Cyrill Gorcunov wrote:
> On Fri, Aug 03, 2012 at 12:17:43PM +0200, richard -rw- weinberger wrote:
>> On Thu, Aug 2, 2012 at 1:11 PM, Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote:
>>> richard -rw- weinberger <richard.weinberger@xxxxxxxxx> writes:
>>>
>>>> On Fri, Mar 23, 2012 at 8:08 PM, Kees Cook <keescook@xxxxxxxxxxxx> wrote:
>>>>> Notify get_robust_list users that the syscall is going away.
>>>>>
>>>>> Suggested-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
>>>>> Signed-off-by: Kees Cook <keescook@xxxxxxxxxxxx>
>>>>> ---
>>>>
>>>> I'm using this system call in an application and noticed that's marked
>>>> as deprecated now.
>>>> My application collects all kind of information from crashing programs.
>>>> It's installed in /proc/sys/kernel/core_pattern.
>>>>
>>>> If program X is crashing it executes get_robust_list(X) to get the
>>>> address of the robust list
>>>> and reads the list from /proc/X/mem.
>>>>
>>>> Is there another way to get the robust list from another program (by it's pid)?
>>>
>>> The folks doing checkpoint/restart claim to not need this, so there
>>> might be a way either that or they just haven't hit this problem yet.
>>>
>>> What you are doing sounds like a reasonable use of get_robust_list to me.
>>>
>>
>> CRIU folks, how do you deal with futex robust lists?
> 
> Well, I believe we were over-optimistic in claiming that we don't need this
> syscall (to be fair I think we simply yet not faced the problem Eric points).
> So we need some way to fetch this address and set it back. If get_robust_list
> get deprecated maybe we could print it out in /proc/pid/stat or something?

I agree with Cyrill, sorry for the confusion last time. We do need some way 
to get the list location. The exact API is not critical, we can work with
either of the mentioned above.

> 	Cyrill
> .
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/