On Wed, Jun 10, 2020 at 07:09:16PM -0700, Linus Torvalds wrote: > On Wed, Jun 10, 2020 at 6:42 PM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > > > > From: Minchan Kim <minchan@xxxxxxxxxx> > > Subject: mm: use only pidfd for process_madvise syscall > > No. > > I'm not taking this crazy series. > > First we have patch 18/25, which introduces process_madvise() that > takes a pidfd. > > Then we have patch 21/25, which says > > "There is a demand[1] to support pid as well pidfd for process_madvise.." > > and points to > > https://lore.kernel.org/linux-mm/9d849087-3359-c4ab-fbec-859e8186c509@xxxxxxxxxxxxx/ > > And then finally we have patch 24/25, which says > > "Based on discussion[1], people didn't feel we need to support both > pid and pidfd for every new coming API[2] so this patch keeps only > pidfd" > > and points to > > https://lore.kernel.org/linux-mm/20200509124817.xmrvsrq3mla6b76k@wittgenstein/ > > Fine. Discussion is good. But this patch-series is crazy, and I refuse > to take this kind of schizophrenic patches that can't make up their > mind. > > Make up your mind, dammit! Don't send me patches that vacillate > between two standpoints and make the history and the eventual final > end result really hard to tell. > > What will it be tomorrow? Another two patches that decide to go the > other way and then back? > > I'm going to flush this whole madvise patch-set down the toilet, > because after having this kind of whip-lash looking through it, I > can't take it any more. > > So all of 17-25 are just going in the garbage until people can make up > their minds. At next revision, I will merge 18 and 23 into a patch with dropping 21 and 24. Andrew, I will resend it after rc window is closed. Thanks. [patch 18/25] mm/madvise: introduce process_madvise() syscall: an external memory hinting API [patch 21/25] mm/madvise: support both pid and pidfd for process_madvise [patch 23/25] mm: support vector address ranges for process_madvise [patch 24/25] mm: use only pidfd for process_madvise syscall
