[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4B11F1A6.9090505@redhat.com>
Date: Sat, 28 Nov 2009 22:59:34 -0500
From: Masami Hiramatsu <mhiramat@...hat.com>
To: Oleg Nesterov <oleg@...hat.com>
CC: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
linux-kernel@...r.kernel.org, dhowells@...hat.com,
hidehiro.kawai.ez@...achi.com, lethal@...ux-sh.org, mingo@...e.hu,
roland@...hat.com, vapier@...too.org,
Takahiro Yasui <tyasui@...hat.com>
Subject: Re: + binfmt-introduce-coredump-parameter-structure.patch added to
-mm tree
Oleg Nesterov wrote:
> On 11/26, Masami Hiramatsu wrote:
>>
>> $ grep -r DUMP_WRITE arch/*/include
>> arch/ia64/include/asm/elf.h: DUMP_WRITE(&phdr, sizeof(phdr)); \
>> arch/ia64/include/asm/elf.h: DUMP_WRITE((void *) gate_phdrs[\
>
> arch/um/sys-i386/asm/elf.h uses DUMP_WRITE() too.
>
>> Oops, certainly, that's a problem.
>> IMHO, we should not do like that, all parameter required by a macro should be
>> specified explicitly, since it reduces readability so much...
>> I think we'd better make those macros inline function, check it's return value
>> for error handling.
>
> Agreed, DUMP_WRITE() in its current form should die. Not only
> it has implicit parameter, it does "goto" from the macro body
> and it has multiple definitions withing the same file.
>
> But perhaps this needs a separate patch? It is not trivial to kill
> DUMP_WRITE(), you can fix this patch if you change DUMP_WRITE()
> to use cprm->file instead of file.
Hmm, certainly, that should be separated. So I just change DUMP_WRITE()
to use cprm->limit/file.
Thank you,
--
Masami Hiramatsu
Software Engineer
Hitachi Computer Products (America), Inc.
Software Solutions Division
e-mail: mhiramat@...hat.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists