Messages in this thread Patch in this message | | | Date | Mon, 24 Aug 2015 20:31:26 +0200 | From | Oleg Nesterov <> | Subject | parse_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; } }
| |