svn commit: r319874 - head/sys/kern

[Konstantin Belousov]

On Wed, Jun 14, 2017 at 10:04:00PM -0700, Gleb Smirnoff wrote:
> On Tue, Jun 13, 2017 at 03:06:43PM +0300, Konstantin Belousov wrote:
> K> On Mon, Jun 12, 2017 at 04:43:56PM -0700, Gleb Smirnoff wrote:
> K> > On Mon, Jun 12, 2017 at 09:11:11PM +0000, Konstantin Belousov wrote:
> K> > K> Author: kib
> K> > K> Date: Mon Jun 12 21:11:11 2017
> K> > K> New Revision: 319874
> K> > K> URL: https://svnweb.freebsd.org/changeset/base/319874
> K> > K> 
> K> > K> Log:
> K> > K>   Print unimplemented syscall number to the ctty on SIGSYS, if enabled
> K> > K>   by the knob kern.lognosys.
> K> > 
> K> > Why is it off by default?
> K> In some (non-default) situation it may cause lot of ctty output.
> K> I made the knob tunable to allow it to be set very early (init)
> K> if needed.
> 
> I remember myself being a beginner UNIX user, and all this
> "bad system call, core dumped" messages were so annoyingly
> uninformative for me, and I had no idea how to track to the
> actual problem. This feature gives a lot of clue for a beginner
> user, but having it default to off, devaluates its value.
> 
> To avoid possible tty spam for an application that produces ton
> of bad syscalls, but ignores SIGSYS, we can enable the feature
> for those processes, who doesn't ignore SIGSYS.
I am curious how would you define the process or thread state which
ignores SIGSYS. The signal can be ignored or blocked in the signal mask,
or catched. All these dispositions cause controlling terminal spam.

Also, I do no see a good solution for rate-limiting the message. I argue
that rate-limiting must be per-process or even per-thread and not system
global, but I do not want to add even an int field to struct thread for
this.