Re: [PATCH v2 1/2] treewide: remove unused address argument from pte_alloc functions

2018-10-13 Thread SF Markus Elfring
>>> The changes were obtained by applying the following Coccinelle script. How do you think about to adjust the order of provided information in the commit description? 1. Update goals 2. Transformation implementation at the end >> "^(?:pte_alloc(?:_one(?:_kernel)?)?|__pte_alloc(?:_kernel)?)$";

Re: [PATCH v2 1/2] treewide: remove unused address argument from pte_alloc functions

2018-10-12 Thread Joel Fernandes
On Fri, Oct 12, 2018 at 08:51:45PM +0200, SF Markus Elfring wrote: > > The changes were obtained by applying the following Coccinelle script. > > A bit of clarification happened for its implementation details. > https://systeme.lip6.fr/pipermail/cocci/2018-October/005374.html > > I have taken als

Re: [PATCH v2 1/2] treewide: remove unused address argument from pte_alloc functions

2018-10-12 Thread SF Markus Elfring
> The changes were obtained by applying the following Coccinelle script. A bit of clarification happened for its implementation details. https://systeme.lip6.fr/pipermail/cocci/2018-October/005374.html I have taken also another look at the following SmPL code. > identifier fn =~ > "^(__pte_allo

Re: [PATCH v2 1/2] treewide: remove unused address argument from pte_alloc functions

2018-10-12 Thread Anton Ivanov
On 10/12/18 2:37 AM, Joel Fernandes (Google) wrote: This series speeds up mremap(2) syscall by copying page tables at the PMD level even for non-THP systems. There is concern that the extra 'address' argument that mremap passes to pte_alloc may do something subtle architecture related in the fu

Re: [PATCH v2 1/2] treewide: remove unused address argument from pte_alloc functions

2018-10-12 Thread Julia Lawall
> I wrote something like this as below but it failed to compile, Julia any > suggestions on how to express this? > > @pte_alloc_func_proto depends on patch exists@ > type T1, T2, T3, T4; > identifier fn =~ > "^(__pte_alloc|pte_alloc_one|pte_alloc|__pte_alloc_kernel|pte_alloc_one_kernel)$"; > @@ > >

Re: [PATCH v2 1/2] treewide: remove unused address argument from pte_alloc functions

2018-10-12 Thread Joel Fernandes
On Fri, Oct 12, 2018 at 06:38:57PM +0200, Julia Lawall wrote: > > I wrote something like this as below but it failed to compile, Julia any > > suggestions on how to express this? > > > > @pte_alloc_func_proto depends on patch exists@ > > type T1, T2, T3, T4; > > identifier fn =~ > > "^(__pte_alloc|

Re: [PATCH v2 1/2] treewide: remove unused address argument from pte_alloc functions

2018-10-12 Thread Joel Fernandes
On Fri, Oct 12, 2018 at 02:09:06PM +0300, Kirill A. Shutemov wrote: > On Thu, Oct 11, 2018 at 06:37:55PM -0700, Joel Fernandes (Google) wrote: > > diff --git a/arch/m68k/include/asm/mcf_pgalloc.h > > b/arch/m68k/include/asm/mcf_pgalloc.h > > index 12fe700632f4..4399d712f6db 100644 > > --- a/arch/m

Re: [PATCH v2 1/2] treewide: remove unused address argument from pte_alloc functions

2018-10-12 Thread Joel Fernandes
On Fri, Oct 12, 2018 at 02:56:19PM +0100, Anton Ivanov wrote: > > On 10/12/18 2:37 AM, Joel Fernandes (Google) wrote: > > This series speeds up mremap(2) syscall by copying page tables at the > > PMD level even for non-THP systems. There is concern that the extra > > 'address' argument that mremap

Re: [PATCH v2 1/2] treewide: remove unused address argument from pte_alloc functions

2018-10-12 Thread Kirill A. Shutemov
On Thu, Oct 11, 2018 at 06:37:55PM -0700, Joel Fernandes (Google) wrote: > diff --git a/arch/m68k/include/asm/mcf_pgalloc.h > b/arch/m68k/include/asm/mcf_pgalloc.h > index 12fe700632f4..4399d712f6db 100644 > --- a/arch/m68k/include/asm/mcf_pgalloc.h > +++ b/arch/m68k/include/asm/mcf_pgalloc.h > @@

[PATCH v2 1/2] treewide: remove unused address argument from pte_alloc functions

2018-10-11 Thread Joel Fernandes (Google)
This series speeds up mremap(2) syscall by copying page tables at the PMD level even for non-THP systems. There is concern that the extra 'address' argument that mremap passes to pte_alloc may do something subtle architecture related in the future, that makes the scheme not work. Also we find that