lkml.org 
[lkml]   [2015]   [Aug]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
Subjectparse_args() is too unforgivable?
On 08/24, Oleg Nesterov wrote:
>
> I booted the kernel with the additional patch below, and nothing bad has
> happened,

Until I tried reboot it once with "locktorture.verbose=true" paramater.
It didn't boot.

This is because parse_args() just aborts after it hits the error, so other
arguments at the same initcall level are simply ignored.

Fixed by the patch below, but I simply can't believe nobody hit this (imo)
bug before.

Why does parse_args() do this?? I simply can't understand why parse_args()
adds more random and hard-to-understand problems if one of the args ("=true"
in this particular case) is wrong.

Yes, the patch below is probably oversimplified / incomplete but imho the
current behaviour is confusing. At least I was greatly confused ;) At least
(I think) it makes sense to let the user know that the rest of command line
was probably ignored.

Oleg.
---

--- a/kernel/params.c
+++ b/kernel/params.c
@@ -220,19 +220,19 @@ char *parse_args(const char *doing,
doing, param);

switch (ret) {
+ case 0:
+ break;
case -ENOENT:
pr_err("%s: Unknown parameter `%s'\n", doing, param);
- return ERR_PTR(ret);
+ break;
case -ENOSPC:
pr_err("%s: `%s' too large for parameter `%s'\n",
doing, val ?: "", param);
- return ERR_PTR(ret);
- case 0:
break;
default:
pr_err("%s: `%s' invalid for parameter `%s'\n",
doing, val ?: "", param);
- return ERR_PTR(ret);
+ break;
}
}



\
 
 \ /
  Last update: 2015-08-24 20:41    [W:0.127 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site