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 <[email protected]>
> > wrote:
> >
> > > On 4/26/20 10:26 AM, Randy Dunlap wrote:
> > > > On 4/26/20 12:16 AM, [email protected] 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/[email protected]
>
> It seems to be not related to process_madvise.
>
> >
> > - http://lkml.kernel.org/r/[email protected]
> > (I did this)
>
> Thanks!
>
> >
> > - http://lkml.kernel.org/r/[email protected]
>
> I will send foldable patches to handle comments.
>
> >
> > - issues arising from the review of
> > http://lkml.kernel.org/r/[email protected]
>
> 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
