Change proc/<pid>/cmdline to 8k

Change proc/<pid>/cmdline to 8k

[Navin P]

Hi,

  I want to change the cmdline of a process to support 8096 . It works
well on ppc where the page size is 65k.
  But when i try to increase it on x86 (i686)

http://lxr.free-electrons.com/source/fs/proc/base.c  by doing
6*PAGE_SIZE, i get kernel panic after some time

199 static int proc_pid_cmdline(struct seq_file *m, struct pid_namespace *ns,
200                             struct pid *pid, struct task_struct *task)
201 {
202         /*
203          * Rely on struct seq_operations::show() being called once
204          * per internal buffer allocation. See single_open(), traverse().
205          */
206         BUG_ON(m->size < PAGE_SIZE);
207         m->count += get_cmdline(task, m->buf, 6*PAGE_SIZE);
208         return 0;
209 }
210


Regards,
Navin

Change proc/<pid>/cmdline to 8k

[Greg KH]

On Thu, Jun 04, 2015 at 09:52:08AM +0530, Navin P wrote:
> Hi,
> 
>   I want to change the cmdline of a process to support 8096 . It works
> well on ppc where the page size is 65k.
>   But when i try to increase it on x86 (i686)
> 
> http://lxr.free-electrons.com/source/fs/proc/base.c  by doing
> 6*PAGE_SIZE, i get kernel panic after some time
> 
> 199 static int proc_pid_cmdline(struct seq_file *m, struct pid_namespace *ns,
> 200                             struct pid *pid, struct task_struct *task)
> 201 {
> 202         /*
> 203          * Rely on struct seq_operations::show() being called once
> 204          * per internal buffer allocation. See single_open(), traverse().
> 205          */
> 206         BUG_ON(m->size < PAGE_SIZE);
> 207         m->count += get_cmdline(task, m->buf, 6*PAGE_SIZE);
> 208         return 0;
> 209 }
> 210

That shows you that this will not work, sorry.

Change proc/<pid>/cmdline to 8k

[Navin P]

On Thu, Jun 4, 2015 at 10:47 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Thu, Jun 04, 2015 at 09:52:08AM +0530, Navin P wrote:
>> Hi,
>>
>>   I want to change the cmdline of a process to support 8096 . It works
>> well on ppc where the page size is 65k.
>>   But when i try to increase it on x86 (i686)
>>
>> http://lxr.free-electrons.com/source/fs/proc/base.c  by doing
>> 6*PAGE_SIZE, i get kernel panic after some time
>>
>> 199 static int proc_pid_cmdline(struct seq_file *m, struct pid_namespace *ns,
>> 200                             struct pid *pid, struct task_struct *task)
>> 201 {
>> 202         /*
>> 203          * Rely on struct seq_operations::show() being called once
>> 204          * per internal buffer allocation. See single_open(), traverse().
>> 205          */
>> 206         BUG_ON(m->size < PAGE_SIZE);
>> 207         m->count += get_cmdline(task, m->buf, 6*PAGE_SIZE);
>> 208         return 0;
>> 209 }
>> 210
>
> That shows you that this will not work, sorry.

Can you please help me and guide me into achieving this ?

Change proc/<pid>/cmdline to 8k

[Greg KH]

On Thu, Jun 04, 2015 at 01:11:48PM +0530, Navin P wrote:
> On Thu, Jun 4, 2015 at 10:47 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Thu, Jun 04, 2015 at 09:52:08AM +0530, Navin P wrote:
> >> Hi,
> >>
> >>   I want to change the cmdline of a process to support 8096 . It works
> >> well on ppc where the page size is 65k.
> >>   But when i try to increase it on x86 (i686)
> >>
> >> http://lxr.free-electrons.com/source/fs/proc/base.c  by doing
> >> 6*PAGE_SIZE, i get kernel panic after some time
> >>
> >> 199 static int proc_pid_cmdline(struct seq_file *m, struct pid_namespace *ns,
> >> 200                             struct pid *pid, struct task_struct *task)
> >> 201 {
> >> 202         /*
> >> 203          * Rely on struct seq_operations::show() being called once
> >> 204          * per internal buffer allocation. See single_open(), traverse().
> >> 205          */
> >> 206         BUG_ON(m->size < PAGE_SIZE);
> >> 207         m->count += get_cmdline(task, m->buf, 6*PAGE_SIZE);
> >> 208         return 0;
> >> 209 }
> >> 210
> >
> > That shows you that this will not work, sorry.
> 
> Can you please help me and guide me into achieving this ?

Why do you want this?  What problem are you trying to solve that you
have come to the conclusion that increasing the size of the command line
is the solution?

thanks,

greg k-h

Change proc/<pid>/cmdline to 8k

[Navin P]

On Thu, Jun 4, 2015 at 1:34 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Thu, Jun 04, 2015 at 01:11:48PM +0530, Navin P wrote:
>> On Thu, Jun 4, 2015 at 10:47 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
>> > On Thu, Jun 04, 2015 at 09:52:08AM +0530, Navin P wrote:
>> >> Hi,
>> >>
>> >>   I want to change the cmdline of a process to support 8096 . It works
>> >> well on ppc where the page size is 65k.
>> >>   But when i try to increase it on x86 (i686)
>> >>
>> >> http://lxr.free-electrons.com/source/fs/proc/base.c  by doing
>> >> 6*PAGE_SIZE, i get kernel panic after some time
>> >>
>> >> 199 static int proc_pid_cmdline(struct seq_file *m, struct pid_namespace *ns,
>> >> 200                             struct pid *pid, struct task_struct *task)
>> >> 201 {
>> >> 202         /*
>> >> 203          * Rely on struct seq_operations::show() being called once
>> >> 204          * per internal buffer allocation. See single_open(), traverse().
>> >> 205          */
>> >> 206         BUG_ON(m->size < PAGE_SIZE);
>> >> 207         m->count += get_cmdline(task, m->buf, 6*PAGE_SIZE);
>> >> 208         return 0;
>> >> 209 }
>> >> 210
>> >
>> > That shows you that this will not work, sorry.
>>
>> Can you please help me and guide me into achieving this ?
>
> Why do you want this?  What problem are you trying to solve that you
> have come to the conclusion that increasing the size of the command line
> is the solution?
>
I'm trying to learn things so that default cmd linux across all
distributions for ia64 and ppc which has PAGE_SIZE has 64k works . We
have this 3rd party application with deeply mounted dir that runs as a
testcase more than 5k chars . We can change it , i thought if that was
the problem ? So just trying to learn. I tried changing the PAGE_SHIFT
but that made the kernel non-bootable or stuck at booting.

This panics only when you access the pid with more than 4k chars.

Change proc/<pid>/cmdline to 8k

[Greg KH]

On Thu, Jun 04, 2015 at 09:06:10PM +0530, Navin P wrote:
> On Thu, Jun 4, 2015 at 1:34 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Thu, Jun 04, 2015 at 01:11:48PM +0530, Navin P wrote:
> >> On Thu, Jun 4, 2015 at 10:47 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> >> > On Thu, Jun 04, 2015 at 09:52:08AM +0530, Navin P wrote:
> >> >> Hi,
> >> >>
> >> >>   I want to change the cmdline of a process to support 8096 . It works
> >> >> well on ppc where the page size is 65k.
> >> >>   But when i try to increase it on x86 (i686)
> >> >>
> >> >> http://lxr.free-electrons.com/source/fs/proc/base.c  by doing
> >> >> 6*PAGE_SIZE, i get kernel panic after some time
> >> >>
> >> >> 199 static int proc_pid_cmdline(struct seq_file *m, struct pid_namespace *ns,
> >> >> 200                             struct pid *pid, struct task_struct *task)
> >> >> 201 {
> >> >> 202         /*
> >> >> 203          * Rely on struct seq_operations::show() being called once
> >> >> 204          * per internal buffer allocation. See single_open(), traverse().
> >> >> 205          */
> >> >> 206         BUG_ON(m->size < PAGE_SIZE);
> >> >> 207         m->count += get_cmdline(task, m->buf, 6*PAGE_SIZE);
> >> >> 208         return 0;
> >> >> 209 }
> >> >> 210
> >> >
> >> > That shows you that this will not work, sorry.
> >>
> >> Can you please help me and guide me into achieving this ?
> >
> > Why do you want this?  What problem are you trying to solve that you
> > have come to the conclusion that increasing the size of the command line
> > is the solution?
> >
> I'm trying to learn things so that default cmd linux across all
> distributions for ia64 and ppc which has PAGE_SIZE has 64k works . We
> have this 3rd party application with deeply mounted dir that runs as a
> testcase more than 5k chars .

Applications shouldn't be messing around with the kernel command line.

> We can change it , i thought if that was
> the problem ? So just trying to learn. I tried changing the PAGE_SHIFT
> but that made the kernel non-bootable or stuck at booting.

You can not easily, if at all, change the PAGE_SIZE of an architecture.
That is a non-trivial task that takes a ton of knowledge about the
platform.

> This panics only when you access the pid with more than 4k chars.

A pid is a number, not a string.  What do you mean by "pid" in this
context?

greg k-h

Change proc/<pid>/cmdline to 8k

[Valdis.Kletnieks at vt.edu]

On Fri, 05 Jun 2015 07:07:30 +0900, Greg KH said:

> Applications shouldn't be messing around with the kernel command line.

He's looking at /proc/<PID>/cmdline, which is a different beast.

Presumably, he's looking at 'ps axwwwwwwwwwww' and still not seeing the
full process commandline, and that irritates him for some reason...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150604/8ecb1fb5/attachment.bin 

Change proc/<pid>/cmdline to 8k

[Valdis.Kletnieks at vt.edu]

On Thu, 04 Jun 2015 21:06:10 +0530, Navin P said:
> have this 3rd party application with deeply mounted dir that runs as a
> testcase more than 5k chars . We can change it , i thought if that was
> the problem ?

So why is a long commandline a problem that needs solving? Are you actually
caring what the command line says?  If so, why?

Hint: There's no guarantee that your commandline contain the actual full
command string.  Consider this on an x86_84 kernel (yes, my $HOME does
need a good cleaning))

% /bin/echo * | wc
      1    1884   25797

1,884 parameters in argv[], totalling some 24K of data.  Which means that
20k isn't displayable.  And extending it to 64k won't fix the problem, as
demonstrated by looking at a rather large mail folder I have:

% /bin/echo ietf/* | wc
      1   62257  673721

OK, how far can we take this?

%  echo | xargs --show-limits echo
Your environment variables take up 1918 bytes
POSIX upper limit on argument length (this system): 2093186
POSIX smallest allowable upper limit on argument length (all systems): 4096
Maximum length of command we could actually use: 2091268
Size of command buffer we are actually using: 131072

Apparently, up to 2M or so...

So what problem are you trying to solve, and why?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150604/2332681d/attachment.bin 

Change proc/<pid>/cmdline to 8k

[Greg KH]

On Thu, Jun 04, 2015 at 06:18:11PM -0400, Valdis.Kletnieks at vt.edu wrote:
> On Fri, 05 Jun 2015 07:07:30 +0900, Greg KH said:
> 
> > Applications shouldn't be messing around with the kernel command line.
> 
> He's looking at /proc/<PID>/cmdline, which is a different beast.

Ah, doh, you are right, nevermind...

> Presumably, he's looking at 'ps axwwwwwwwwwww' and still not seeing the
> full process commandline, and that irritates him for some reason...

Yeah, that's not a good thing to rely on to even be correct, as it is
easy for an application to change that value.

Change proc/<pid>/cmdline to 8k

[Navin P]

On Fri, Jun 5, 2015 at 3:49 AM,  <Valdis.Kletnieks@vt.edu> wrote:
> On Thu, 04 Jun 2015 21:06:10 +0530, Navin P said:
>> have this 3rd party application with deeply mounted dir that runs as a
>> testcase more than 5k chars . We can change it , i thought if that was
>> the problem ?
>
> So why is a long commandline a problem that needs solving? Are you actually
> caring what the command line says?  If so, why?
>
> Hint: There's no guarantee that your commandline contain the actual full
> command string.  Consider this on an x86_84 kernel (yes, my $HOME does
> need a good cleaning))
>
> % /bin/echo * | wc
>       1    1884   25797
>
> 1,884 parameters in argv[], totalling some 24K of data.  Which means that
> 20k isn't displayable.  And extending it to 64k won't fix the problem, as
> demonstrated by looking at a rather large mail folder I have:
>
> % /bin/echo ietf/* | wc
>       1   62257  673721
>
> OK, how far can we take this?
>
> %  echo | xargs --show-limits echo
> Your environment variables take up 1918 bytes
> POSIX upper limit on argument length (this system): 2093186
> POSIX smallest allowable upper limit on argument length (all systems): 4096
> Maximum length of command we could actually use: 2091268
> Size of command buffer we are actually using: 131072
>
> Apparently, up to 2M or so...
>
> So what problem are you trying to solve, and why?

Thanks.

In fs/proc/base.c

static int proc_pid_cmdline(struct seq_file *m, struct pid_namespace *ns,
200                             struct pid *pid, struct task_struct *task)
201 {
202         /*
203          * Rely on struct seq_operations::show() being called once
204          * per internal buffer allocation. See single_open(), traverse().
205          */
206         BUG_ON(m->size < PAGE_SIZE);
207         m->count += get_cmdline(task, m->buf, PAGE_SIZE);
208         return 0;
209 }


396 int get_cmdline(struct task_struct *task, char *buffer, int buflen)
397 {
398         int res = 0;
399         unsigned int len;
400         struct mm_struct *mm = get_task_mm(task);
401         if (!mm)
402                 goto out;
403         if (!mm->arg_end)
404                 goto out_mm;    /* Shh! No looking before we're done */
405
406         len = mm->arg_end - mm->arg_start;
407
408         if (len > buflen)
409                 len = buflen;

We are truncating the cmdline to PAGE_SIZE in mm/util.c

I did created a program that prints argv[1] and counts wc -c ie
./longarg 12345...5k | wc -c you get 4096  on i686.

I also need this for things like  perl -e 'running code' that is
longer and i want to grep for some strings that are present at the end
so the code can be around 5k-8k by multiple users.

Change proc/<pid>/cmdline to 8k

[Navin P]

On Fri, Jun 5, 2015 at 8:51 AM, Navin P <navinp1912@gmail.com> wrote:
> On Fri, Jun 5, 2015 at 3:49 AM,  <Valdis.Kletnieks@vt.edu> wrote:

After all your perseverance , i have got what i wanted with 4 lines
change on linux-4.0 fc22 :)
I just made the proc cmdlines buffer size to a max of 100*4k. I hit
the execve limit E2BIG when i had lot more more than 128000 but then i
stopped beyond that.

diff --git a/linux-4.0_orig/fs/proc/base.c b/linux-4.0/fs/proc/base.c
index 3f3d7ae..06f19ee 100644
--- a/linux-4.0_orig/fs/proc/base.c
+++ b/linux-4.0/fs/proc/base.c
@@ -204,7 +204,7 @@ static int proc_pid_cmdline(struct seq_file *m,
struct pid_namespace *ns,
  * per internal buffer allocation. See single_open(), traverse().
  */
  BUG_ON(m->size < PAGE_SIZE);
- m->count += get_cmdline(task, m->buf, PAGE_SIZE);
+ m->count += get_cmdline(task, m->buf, 100*PAGE_SIZE);
  return 0;
 }

@@ -2166,7 +2166,7 @@ static ssize_t proc_pid_attr_write(struct file *
file, const char __user * buf,
  if (!task)
  goto out_no_task;
  if (count > PAGE_SIZE)
- count = PAGE_SIZE;
+ count = 100*PAGE_SIZE;

  /* No partial writes. */
  length = -EINVAL;
diff --git a/linux-4.0_orig/fs/seq_file.c b/linux-4.0/fs/seq_file.c
index 555f821..047d13e 100644
--- a/linux-4.0_orig/fs/seq_file.c
+++ b/linux-4.0/fs/seq_file.c
@@ -101,7 +101,7 @@ static int traverse(struct seq_file *m, loff_t offset)
  return 0;
  }
  if (!m->buf) {
- m->buf = seq_buf_alloc(m->size = PAGE_SIZE);
+ m->buf = seq_buf_alloc(m->size = (100*PAGE_SIZE));
  if (!m->buf)
  return -ENOMEM;
  }
@@ -197,7 +197,7 @@ ssize_t seq_read(struct file *file, char __user
*buf, size_t size, loff_t *ppos)

  /* grab buffer if we didn't have one */
  if (!m->buf) {
- m->buf = seq_buf_alloc(m->size = PAGE_SIZE);
+ m->buf = seq_buf_alloc(m->size = (100*PAGE_SIZE));
  if (!m->buf)
  goto Enomem;
  }


Thanks.