On Fri, Jul 12, 2019 at 09:43:03PM +0300, Alexey Izbyshev wrote: > On 7/12/19 8:46 PM, Alexey Dobriyan wrote: > > On Fri, Jul 12, 2019 at 06:36:26PM +0200, Oleg Nesterov wrote: > >> On 07/12, Alexey Izbyshev wrote: > >>> > >>> --- a/fs/proc/base.c > >>> +++ b/fs/proc/base.c > >>> @@ -275,6 +275,8 @@ static ssize_t get_mm_cmdline(struct mm_struct *mm, > >>> char __user *buf, > >>> if (got <= offset) > >>> break; > >>> got -= offset; > >>> + if (got < size) > >>> + size = got; > >> > >> Acked-by: Oleg Nesterov <[email protected]> > > > > The proper fix to all /proc/*/cmdline problems is to revert > > > > f5b65348fd77839b50e79bc0a5e536832ea52d8d > > proc: fix missing final NUL in get_mm_cmdline() rewrite > > > > 5ab8271899658042fabc5ae7e6a99066a210bc0e > > fs/proc: simplify and clarify get_mm_cmdline() function > > > Should this be interpreted as an actual suggestion to revert the patches, > fix the conflicts, test and submit them, or is this more like thinking out > loud?
Of course! Do you have a reproducer? > In the former case, will it be OK for long term branches? For everyone. If a rewrite causes 1 bug, 1 user visible change and a infoleak, it is called revert. > get_mm_cmdline() does seem easier to read for me before 5ab8271899658042. > But it also has different semantics in corner cases, for example: All semantics changes are recent. > - If there is no NUL at arg_end-1, it reads only the first string in > the combined arg/env block, and doesn't terminate it with NUL. That's because fixed-length /proc/*/cmdline did that. > - If there is any problem with access_remote_vm() or copy_to_user(), > it returns -EFAULT even if some data were copied to userspace. > > On the other hand, 5ab8271899658042 was merged not too long ago (about a > year), > so it's possible that the current semantics isn't heavily relied upon.
