linux-kernel - Re: mmotm 2020-04-26-00-15 uploaded (mm/madvise.c)

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] [day] [month] [year] [list]

Message-ID: <20200429084318.wh7gjokuk445mr5d@butterfly.localdomain>
Date:   Wed, 29 Apr 2020 10:43:18 +0200
From:   Oleksandr Natalenko <oleksandr@...hat.com>
To:     Minchan Kim <minchan@...nel.org>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Randy Dunlap <rdunlap@...radead.org>, broonie@...nel.org,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org, linux-next@...r.kernel.org, mhocko@...e.cz,
        mm-commits@...r.kernel.org, sfr@...b.auug.org.au
Subject: Re: mmotm 2020-04-26-00-15 uploaded (mm/madvise.c)

On Mon, Apr 27, 2020 at 04:45:12PM -0700, Minchan Kim wrote:
> Hi Andrew,
> 
> On Mon, Apr 27, 2020 at 01:50:53PM -0700, Andrew Morton wrote:
> > On Sun, 26 Apr 2020 15:48:35 -0700 Randy Dunlap <rdunlap@...radead.org> wrote:
> > 
> > > On 4/26/20 10:26 AM, Randy Dunlap wrote:
> > > > On 4/26/20 12:16 AM, akpm@...ux-foundation.org wrote:
> > > >> The mm-of-the-moment snapshot 2020-04-26-00-15 has been uploaded to
> > > >>
> > > >>    http://www.ozlabs.org/~akpm/mmotm/
> > > >>
> > > >> mmotm-readme.txt says
> > > >>
> > > >> README for mm-of-the-moment:
> > > >>
> > > >> http://www.ozlabs.org/~akpm/mmotm/
> > > >>
> > > >> This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
> > > >> more than once a week.
> > > >>
> > > >> You will need quilt to apply these patches to the latest Linus release (5.x
> > > >> or 5.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
> > > >> http://ozlabs.org/~akpm/mmotm/series
> > > >>
> > > >> The file broken-out.tar.gz contains two datestamp files: .DATE and
> > > >> .DATE-yyyy-mm-dd-hh-mm-ss.  Both contain the string yyyy-mm-dd-hh-mm-ss,
> > > >> followed by the base kernel version against which this patch series is to
> > > >> be applied.
> > > > 
> > > > Hi,
> > > > I'm seeing lots of build failures in mm/madvise.c.
> > > > 
> > > > Is Minchin's patch only partially applied or is it just missing some pieces?
> > > > 
> > > > a.  mm/madvise.c needs to #include <linux/uio.h>
> > > > 
> > > > b.  looks like the sys_process_madvise() prototype in <linux/syscalls.h>
> > > > has not been updated:
> > > > 
> > > > In file included from ../mm/madvise.c:11:0:
> > > > ../include/linux/syscalls.h:239:18: error: conflicting types for ‘sys_process_madvise’
> > > >   asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
> > > >                   ^
> > > > ../include/linux/syscalls.h:225:2: note: in expansion of macro ‘__SYSCALL_DEFINEx’
> > > >   __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
> > > >   ^~~~~~~~~~~~~~~~~
> > > > ../include/linux/syscalls.h:219:36: note: in expansion of macro ‘SYSCALL_DEFINEx’
> > > >  #define SYSCALL_DEFINE6(name, ...) SYSCALL_DEFINEx(6, _##name, __VA_ARGS__)
> > > >                                     ^~~~~~~~~~~~~~~
> > > > ../mm/madvise.c:1295:1: note: in expansion of macro ‘SYSCALL_DEFINE6’
> > > >  SYSCALL_DEFINE6(process_madvise, int, which, pid_t, upid,
> > > >  ^~~~~~~~~~~~~~~
> > > > In file included from ../mm/madvise.c:11:0:
> > > > ../include/linux/syscalls.h:880:17: note: previous declaration of ‘sys_process_madvise’ was here
> > > >  asmlinkage long sys_process_madvise(int which, pid_t pid, unsigned long start,
> > > >                  ^~~~~~~~~~~~~~~~~~~
> > > 
> > > I had to add 2 small patches to have clean madvise.c builds:
> > > 
> > 
> > hm, not sure why these weren't noticed sooner, thanks.
> > 
> > This patchset is looking a bit tired now.
> > 
> > Things to be addressed (might be out of date):
> > 
> > - http://lkml.kernel.org/r/293bcd25-934f-dd57-3314-bbcf00833e51@redhat.com
> 
> It seems to be not related to process_madvise.
> 
> > 
> > - http://lkml.kernel.org/r/2a767d50-4034-da8c-c40c-280e0dda910e@suse.cz
> >   (I did this)
> 
> Thanks!
> 
> > 
> > - http://lkml.kernel.org/r/20200310222008.GB72963@google.com
> 
> I will send foldable patches to handle comments.
> 
> > 
> > - issues arising from the review of
> >   http://lkml.kernel.org/r/20200302193630.68771-8-minchan@kernel.org
> 
> Oleksandr, What's the outcome of this issue?
> Do we still need to change based on the comment?
> 

My current understanding is that we do not mess with signals excessively
in the given code path.

-- 
  Best regards,
    Oleksandr Natalenko (post-factum)
    Principal Software Maintenance Engineer