Re: [PATCH 3/4] coredump: ELF-FDPIC: enable to omit anonymous shared memory

["Kawai, Hidehiro" <hidehiro.kawai.ez@hitachi.com>]

Hi David and Robin,

Thank you for your reply.

Robin Holt wrote:
> On Wed, Feb 21, 2007 at 11:33:31AM +0000, David Howells wrote:
> 
>>Kawai, Hidehiro <hidehiro.kawai.ez@hitachi.com> wrote:
>>
>>>Is coredump_setting_sem a global semaphore?  If so, it prevents concurrent
>>>core dumping.
>>
>>No, it doesn't.  Look again:
>>
>>	int do_coredump(long signr, int exit_code, struct pt_regs * regs)
>>	{
>>		<setup vars>
>>
>> >>>>		down_read(&coredump_settings_sem);

Oh, I'm sorry.  I have overlooked it.  There is no problem.


>>>Additionally, while some process is dumped, writing to
>>>coredump_omit_anon_shared of unrelated process will be blocked.
>>
>>Yes, but that's probably reasonable.  How likely (a) is a process to coredump,
>>and (b) is a coredump to occur simultaneously with someone altering their
>>settings?
> 
> And (c) altering the setting during a core dump going to produce an
> unusable core dump.  I don't think the locking is that difficult to add
> and it just makes sense.  I would venture a guess that it will take less
> time to actually do the locking than to continue arguing it is not needed
> when it clearly appears it is needed for even a small number of cases.

Okay, the probability that the process is blocked in the proc handler seems
to be small.  But I'm not sure if problems never occur in enterprise use.
So I'd like to use down_write_trylock() as Robin said before. And if it
fails to acquire the lock, it returns EBUSY immediately.
Do you have any comments?

Thanks,
-- 
Hidehiro Kawai
Hitachi, Ltd., Systems Development Laboratory

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