Re: WARN in do_rt_tgsigqueueinfo()

[Mateusz Guzik]

On Thu, May 15, 2014 at 11:54:15AM -0400, Dave Jones wrote:
> On Thu, May 15, 2014 at 05:04:12PM +0200, Peter Zijlstra wrote:
> 
>  > > > trinity$ MALLOC_CHECK_=0 ./trinity -xinit_module -xreboot -xshutdown -xunshare -xnfsservctl -xclock_nanosleep -xuselib -xumount -xmount -m --quiet -C 400 -l off -xmremap
>  > > > 
>  > > > [watchdog] kernel became tainted! (512/0) Last seed was 4072360471
>  > > > 
>  > > > [15908.562512] ------------[ cut here ]------------
>  > > > [15908.567245] WARNING: CPU: 22 PID: 3312 at /usr/src/linux-2.6/kernel/signal.c:3060 do_rt_tgsigqueueinfo+0xb4/0xc0()
>  > > > 
>  > > > This is apparently a very common thing to hit according to google.
>  > > 
>  > > Well, it warns about an argument received from userland, so nothing fishy
>  > > going on as far as kernel consistency is concerned if that's what you mean.
>  > 
>  > I hadn't looked that far.. I just manged to hit it two times in a row
>  > while waiting for my bug to trigger.
> 
> There's a ton of 'noise' like this that fuzzing turns up.
> I've been collecting some of the stuff to shut it up..
> 
> http://codemonkey.org.uk/junk/silence-fuzz-testing-noise.patch
> http://codemonkey.org.uk/junk/silence-noisy-deprecated-warnings-while-fuzzing.patch
> 
> I'm of the opinion that a user-triggerable WARN is a bug, but aparently
> not everyone else feels that way.
> 

imho warning sysadmins about userspace using deprecated stuff is fine as
long as users are not able to spam the console with it.

Warning reported here just looks scary and provides no information for
sysadmins so I guess it hould be changed.

I see no value in removing this stuff. If it shows up in production you
most likely want to know. Filtering this out during fuzzing should be an
issue.

my $0,03
-- 
Mateusz Guzik
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/