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
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.
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 ?
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
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.
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
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...
On Thu, Jun 04, 2015 at 06:18:11PM -0400, Valdis.Kletnieks@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.
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?
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.
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.
participants (3)
-
Greg KH -
Navin P -
Valdis.Kletnieks＠vt.edu