From: Dmitry Safonov <dsafonov@virtuozzo.com>
To: Michael Ellerman <mpe@ellerman.id.au>,
Dmitry Safonov <0x7f454c46@gmail.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org, linux-mm@kvack.org,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCHv3 0/8] powerpc/mm: refactor vDSO mapping code
Date: Tue, 8 Nov 2016 15:47:22 +0300 [thread overview]
Message-ID: <97bc21c0-d7b7-d771-3f2b-1d7a862a2eee@virtuozzo.com> (raw)
In-Reply-To: <87pom6lu6a.fsf@concordia.ellerman.id.au>
On 11/08/2016 02:57 AM, Michael Ellerman wrote:
> Dmitry Safonov <0x7f454c46@gmail.com> writes:
>
>> 2016-10-27 20:09 GMT+03:00 Dmitry Safonov <dsafonov@virtuozzo.com>:
>>
>> ping?
>
> There's another series doing some similar changes:
>
> http://www.spinics.net/lists/linux-mm/msg115860.html
Well, that version makes arch_mremap hook more general with renaming
vdso pointer. While this series erases that hook totaly.
So, we've agreed that it would be better without this hook, but with
generic version of vdso_mremap special_mapping helper:
https://marc.info/?i=d1aa8bec-a53e-cd30-e66a-39bebb6a400a@codeaurora.org
> And I don't like all the macro games in 3/8, eg:
>
> +#ifndef BITS
> +#define BITS 32
> +#endif
> +
> +#undef Elf_Ehdr
> +#undef Elf_Sym
> +#undef Elf_Shdr
> +
> +#define _CONCAT3(a, b, c) a ## b ## c
> +#define CONCAT3(a, b, c) _CONCAT3(a, b, c)
> +#define Elf_Ehdr CONCAT3(Elf, BITS, _Ehdr)
> +#define Elf_Sym CONCAT3(Elf, BITS, _Sym)
> +#define Elf_Shdr CONCAT3(Elf, BITS, _Shdr)
> +#define VDSO_LBASE CONCAT3(VDSO, BITS, _LBASE)
> +#define vdso_kbase CONCAT3(vdso, BITS, _kbase)
> +#define vdso_pages CONCAT3(vdso, BITS, _pages)
> +
> +#undef pr_fmt
> +#define pr_fmt(fmt) "vDSO" __stringify(BITS) ": " fmt
> +
> +#define lib_elfinfo CONCAT3(lib, BITS, _elfinfo)
> +
> +#define find_section CONCAT3(find_section, BITS,)
> +static void * __init find_section(Elf_Ehdr *ehdr, const char *secname,
> + unsigned long *size)
>
>
> I'd rather we kept the duplication of code than the obfuscation those
> macros add.
>
> If we can come up with a way to share more of the code without having to
> do all those tricks then I'd be interested.
Well, ok, I thought it's quite common even outside of tracing:
e.g, fs/compat_binfmt_elf.c does quite the same trick.
But as you find it obscured - than ok, I will resend without that
common-vdso part.
>
> cheers
>
--
Dmitry
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
prev parent reply other threads:[~2016-11-08 12:50 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-27 17:09 Dmitry Safonov
2016-10-27 17:09 ` [PATCHv3 1/8] powerpc/vdso: unify return paths in setup_additional_pages Dmitry Safonov
2016-11-08 0:10 ` Michael Ellerman
2016-11-08 12:29 ` Dmitry Safonov
2016-10-27 17:09 ` [PATCHv3 2/8] powerpc/vdso: remove unused params in vdso_do_func_patch{32,64} Dmitry Safonov
2016-10-27 17:09 ` [PATCHv3 3/8] powerpc/vdso: separate common code in vdso_common Dmitry Safonov
2016-10-27 17:09 ` [PATCHv3 4/8] powerpc/vdso: introduce init_vdso{32,64}_pagelist Dmitry Safonov
2016-10-27 17:09 ` [PATCHv3 5/8] powerpc/vdso: split map_vdso from arch_setup_additional_pages Dmitry Safonov
2016-10-27 17:09 ` [PATCHv3 6/8] powerpc/vdso: switch from legacy_special_mapping_vmops Dmitry Safonov
2016-10-27 17:09 ` [PATCHv3 7/8] mm: kill arch_mremap Dmitry Safonov
2016-10-27 17:09 ` [PATCHv3 8/8] powerpc/vdso: remove arch_vma_name Dmitry Safonov
2016-11-07 11:21 ` [PATCHv3 0/8] powerpc/mm: refactor vDSO mapping code Dmitry Safonov
2016-11-07 23:57 ` Michael Ellerman
2016-11-08 12:47 ` Dmitry Safonov [this message]
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=97bc21c0-d7b7-d771-3f2b-1d7a862a2eee@virtuozzo.com \
--to=dsafonov@virtuozzo.com \
--cc=0x7f454c46@gmail.com \
--cc=benh@kernel.crashing.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=paulus@samba.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox