[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4F9BB87C.4050103@b1-systems.de>
Date: Sat, 28 Apr 2012 11:29:32 +0200
From: Karsten Keil <keil@...systems.de>
To: Tilman Schmidt <tilman@...p.cc>
CC: Karsten Keil <isdn@...ux-pingi.de>,
David Miller <davem@...emloft.net>,
Hansjoerg Lipp <hjlipp@....de>,
i4ldeveloper@...tserv.isdn4linux.de, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/8] isdn/gigaset: ratelimit CAPI message dumps
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Am 27.04.2012 12:29, schrieb Tilman Schmidt:
> Am 26.04.2012 08:39, schrieb Karsten Keil:
>> Am 26.04.2012 01:02, schrieb Tilman Schmidt:
>>> Introduce a global ratelimit for CAPI message dumps to protect
>>> against possible log flood. Drop the ratelimit for ignored
>>> messages which is now covered by the global one.
>>
>> Hmm, I think the only CAPI messages which would need a ratelimit
>> are related to the DATA_B3 messages. If you need CAPI debug
>> messages in most cases you do not need all of the DATA_B3, but
>> you do not want to miss any other message related to the call
>> control. With a general rate limit you do not have the control,
>> which messages are logged and which are not.
>
> The ratelimit introduced by this patch only applies to messages
> other than DATA_B3. Logging DATA_B3 messages is not done via
> dump_cmsg().
>
Thanks for the clarification, forget about my objection.
I ack this patch now.
> I'd like to ratelimit specifically non-DATA_B3 messages because I
> saw a (possibly buggy) CAPI application flooding the log with
> FACILITY messages. Equally important, I'd like to make the
> ratelimit in do_nothing() / do_unsupported() bursty because I had
> a case where I needed to see several ignored/unhandled CAPI
> messages in quick succession. So this patch is killing two birds
> with one stone for me.
>
> The burst limit of 20 messages in 20 seconds is chosen to allow a
> complete call setup sequence to be logged, while limiting to one
> message per second in the long run.
>
>> And here maybe some cases, when even the DATA_B3 are important
>> (e.g. searching bugs in flow control), so I would make it still
>> conditional to allow to print all messages.
>
> DATA_B3 dumps produce an enormous amount of log data and are
> therefore controlled separately by the DEBUG_MCMD flag. Someone
> who enables that should know what she or he does. But if you need
> them, you need them all. A ratelimit doesn't make sense there in
> my experience.
>
>> And I'm not sure, if this is really something for stable.
>
> It's pretty simple and localized, a net simplification, and only
> affects generation of debugging messages, so I think it's safe.
> But if you see a problem there I can drop the "CC: stable" line.
>
I let the decision about it to you and the stable maintainers.
- --
Karsten Keil
Linux Kernel Development
Tel: +49 175 7249132
Mail: keil@...systems.de
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk+buHwACgkQo5VVC52CNcRoygCfWwPlWZ+A48OwEkr/MtK6PeNG
0UEAnipdxPSZDKa4s99LlGYwvggWIIAJ
=CLr6
-----END PGP SIGNATURE-----
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists