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@xxxxxxxxxxxxx> wrote: > > > > > On 4/26/20 10:26 AM, Randy Dunlap wrote: > > > > On 4/26/20 12:16 AM, akpm@xxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxx > > It seems to be not related to process_madvise. > > > > > - http://lkml.kernel.org/r/2a767d50-4034-da8c-c40c-280e0dda910e@xxxxxxx > > (I did this) > > Thanks! > > > > > - http://lkml.kernel.org/r/20200310222008.GB72963@xxxxxxxxxx > > I will send foldable patches to handle comments. > > > > > - issues arising from the review of > > http://lkml.kernel.org/r/20200302193630.68771-8-minchan@xxxxxxxxxx > > 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
