linux-kernel - Re: [PATCH v4 4/8] mm: Move immutable fields of 'struct vm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 20 Jan 2021 10:13:37 -0800
From:   Nick Desaulniers <ndesaulniers@...gle.com>
To:     Will Deacon <will@...nel.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Linux Memory Management List <linux-mm@...ck.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Jan Kara <jack@...e.cz>, Minchan Kim <minchan@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        "Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Vinayak Menon <vinmenon@...eaurora.org>,
        Hugh Dickins <hughd@...gle.com>,
        kernel-team <kernel-team@...roid.com>
Subject: Re: [PATCH v4 4/8] mm: Move immutable fields of 'struct vm_fault'
 into anonymous struct

On Wed, Jan 20, 2021 at 9:36 AM Will Deacon <will@...nel.org> wrote:
>
> 'struct vm_fault' contains both information about the fault being
> serviced alongside mutable fields contributing to the state of the
> fault-handling logic. Unfortunately, the distinction between the two is
> not clear-cut, and a number of callers end up manipulating the structure
> temporarily before restoring it when returning.
>
> Try to clean this up by moving the immutable fault information into an
> anonymous struct, which will later be marked as 'const'. GCC will then
> complain (with an error) about modification of these fields after they
> have been initialised, although LLVM currently allows them without even
> a warning:
>
> https://bugs.llvm.org/show_bug.cgi?id=48755

I think this paragraph+link would be better on patch 8/8.

>
> Ideally, the 'flags' field would be part of the new structure too, but
> it seems as though the ->page_mkwrite() path is not ready for this yet.
>
> Cc: Kirill A. Shutemov <kirill.shutemov@...ux.intel.com>
> Suggested-by: Linus Torvalds <torvalds@...ux-foundation.org>
> Link: https://lore.kernel.org/r/CAHk-=whYs9XsO88iqJzN6NC=D-dp2m0oYXuOoZ=eWnvv=5OA+w@mail.gmail.com
> Signed-off-by: Will Deacon <will@...nel.org>
> ---
>  include/linux/mm.h | 13 ++++++++-----
>  1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 251a2339befb..b4a5cb9bff7d 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -517,11 +517,14 @@ static inline bool fault_flag_allow_retry_first(unsigned int flags)
>   * pgoff should be used in favour of virtual_address, if possible.
>   */
>  struct vm_fault {
> -       struct vm_area_struct *vma;     /* Target VMA */
> -       unsigned int flags;             /* FAULT_FLAG_xxx flags */
> -       gfp_t gfp_mask;                 /* gfp mask to be used for allocations */
> -       pgoff_t pgoff;                  /* Logical page offset based on vma */
> -       unsigned long address;          /* Faulting virtual address */
> +       struct {
> +               struct vm_area_struct *vma;     /* Target VMA */
> +               gfp_t gfp_mask;                 /* gfp mask to be used for allocations */
> +               pgoff_t pgoff;                  /* Logical page offset based on vma */
> +               unsigned long address;          /* Faulting virtual address */
> +       };
> +       unsigned int flags;             /* FAULT_FLAG_xxx flags
> +                                        * XXX: should really be 'const' */
>         pmd_t *pmd;                     /* Pointer to pmd entry matching
>                                          * the 'address' */
>         pud_t *pud;                     /* Pointer to pud entry matching
> --
> 2.30.0.284.gd98b1dd5eaa7-goog
>


-- 
Thanks,
~Nick Desaulniers