| Message ID | 20180220171842.22452-1-chris@chris-wilson.co.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Quoting Chris Wilson (2018-02-20 17:18:42) > We make use of unsafe kernel parameters in igt, which generates a > warning and taints the kernel. The warning is unhelpful as we then need > to filter it out again, so kill it at source. > > Cc: Petri Latvala <petri.latvala@intel.com> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Longterm goal is that we replace poking the unsafe parameters (indeed we remove them) by explicit debug mechanisms. -Chris
On Tue, 20 Feb 2018, Chris Wilson <chris@chris-wilson.co.uk> wrote: > We make use of unsafe kernel parameters in igt, which generates a > warning and taints the kernel. The warning is unhelpful as we then need > to filter it out again, so kill it at source. Is your goal to upstream this or what? BR, Jani. > > Cc: Petri Latvala <petri.latvala@intel.com> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch> > --- > kernel/params.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/kernel/params.c b/kernel/params.c > index cc9108c2a1fd..ce89f757e6da 100644 > --- a/kernel/params.c > +++ b/kernel/params.c > @@ -111,8 +111,8 @@ bool parameq(const char *a, const char *b) > static void param_check_unsafe(const struct kernel_param *kp) > { > if (kp->flags & KERNEL_PARAM_FL_UNSAFE) { > - pr_warn("Setting dangerous option %s - tainting kernel\n", > - kp->name); > + pr_notice("Setting dangerous option %s - tainting kernel\n", > + kp->name); > add_taint(TAINT_USER, LOCKDEP_STILL_OK); > } > }
Quoting Jani Nikula (2018-02-26 10:42:40) > On Tue, 20 Feb 2018, Chris Wilson <chris@chris-wilson.co.uk> wrote: > > We make use of unsafe kernel parameters in igt, which generates a > > warning and taints the kernel. The warning is unhelpful as we then need > > to filter it out again, so kill it at source. > > Is your goal to upstream this or what? First asking if we see merit in this. If so, I can rewrite the commitmsg to emphasise that this is a direct result of user behaviour and so emitting a WARN is over the top. However, the counter argument is that this sets a kernel taint, so shouldn't it warn as well? -Chris
On Mon, 26 Feb 2018, Chris Wilson <chris@chris-wilson.co.uk> wrote: > Quoting Jani Nikula (2018-02-26 10:42:40) >> On Tue, 20 Feb 2018, Chris Wilson <chris@chris-wilson.co.uk> wrote: >> > We make use of unsafe kernel parameters in igt, which generates a >> > warning and taints the kernel. The warning is unhelpful as we then need >> > to filter it out again, so kill it at source. >> >> Is your goal to upstream this or what? > > First asking if we see merit in this. If so, I can rewrite the commitmsg > to emphasise that this is a direct result of user behaviour and so > emitting a WARN is over the top. However, the counter argument is that > this sets a kernel taint, so shouldn't it warn as well? I erred on the side of ensuring the reason for tainting doesn't go unnoticed when I added that. But I don't think the logging level was ever discussed, it's just what I thought best at the time. I don't think I care as long as it stays below debug level. BR, Jani.
diff --git a/kernel/params.c b/kernel/params.c index cc9108c2a1fd..ce89f757e6da 100644 --- a/kernel/params.c +++ b/kernel/params.c @@ -111,8 +111,8 @@ bool parameq(const char *a, const char *b) static void param_check_unsafe(const struct kernel_param *kp) { if (kp->flags & KERNEL_PARAM_FL_UNSAFE) { - pr_warn("Setting dangerous option %s - tainting kernel\n", - kp->name); + pr_notice("Setting dangerous option %s - tainting kernel\n", + kp->name); add_taint(TAINT_USER, LOCKDEP_STILL_OK); } }