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]
Message-ID: <98791b0f-0c00-0d0d-4831-3c36fce55888@redhat.com>
Date:   Wed, 1 Mar 2023 09:26:15 +0100
From:   David Hildenbrand <david@...hat.com>
To:     Suren Baghdasaryan <surenb@...gle.com>, akpm@...ux-foundation.org
Cc:     sfr@...b.auug.org.au, error27@...il.com, willy@...radead.org,
        Liam.Howlett@...cle.com, jgg@...pe.ca, yuzhao@...gle.com,
        dhowells@...hat.com, hughd@...gle.com,
        mathieu.desnoyers@...icios.com, pasha.tatashin@...een.com,
        laurent.dufour@...ibm.com, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, kernel test robot <lkp@...el.com>
Subject: Re: [PATCH 1/2] mm/mmap: remove unnecessary vp->vma check in
 vma_prepare

On 01.03.23 03:27, Suren Baghdasaryan wrote:
> vp->vma in vma_prepare() is always non-NULL, therefore checking it is
> not necessary. Remove the extra check.
> 
> Fixes: e8f071350ea5 ("mm/mmap: write-lock VMAs in vma_prepare before modifying them")
> Reported-by: kernel test robot <lkp@...el.com>
> Reported-by: Dan Carpenter <error27@...il.com>

It would be great to mention that this simply silences a smatch warning. 
Otherwise, one might be mislead that this commit fixes an actual BUG ;)

> Link: https://lore.kernel.org/r/202302281802.J93Nma7q-lkp@intel.com/
> Signed-off-by: Suren Baghdasaryan <surenb@...gle.com>
> ---
> Fix cleanly apply over mm-unstable, SHA in "Fixes" is from that tree.
> 
>   mm/mmap.c | 3 +--
>   1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 0cd3714c2182..0759d53b470c 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -505,8 +505,7 @@ static inline void init_vma_prep(struct vma_prepare *vp,
>    */
>   static inline void vma_prepare(struct vma_prepare *vp)
>   {
> -	if (vp->vma)
> -		vma_start_write(vp->vma);
> +	vma_start_write(vp->vma);
>   	if (vp->adj_next)
>   		vma_start_write(vp->adj_next);
>   	/* vp->insert is always a newly created VMA, no need for locking */

Yes, that looks correct.

Reviewed-by: David Hildenbrand <david@...hat.com>

-- 
Thanks,

David / dhildenb

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ