linux-kernel - Re: [PATCHv2] lib/ratelimit: Lockless ratelimiting

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 26 Jun 2018 18:46:23 +0100
From:   Dmitry Safonov <dima@...sta.com>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Arnd Bergmann <arnd@...db.de>, David Airlie <airlied@...ux.ie>,
        Dmitry Safonov <0x7f454c46@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jani Nikula <jani.nikula@...ux.intel.com>,
        Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
        Rodrigo Vivi <rodrigo.vivi@...el.com>,
        Theodore Ts'o <tytso@....edu>,
        Thomas Gleixner <tglx@...utronix.de>,
        intel-gfx@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org
Subject: Re: [PATCHv2] lib/ratelimit: Lockless ratelimiting

Hi Andy, thanks for the review,

On Tue, 2018-06-26 at 20:04 +0300, Andy Shevchenko wrote
[..]
> >  #define RATELIMIT_STATE_INIT(name, interval_init, burst_init)
> > {                \
> > -               .lock           =
> > __RAW_SPIN_LOCK_UNLOCKED(name.lock),  \
> 
> name is now redundant, isn't it?

It is. Worth to split on the second patch or keep callers changes in
this patch?

> > @@ -42,9 +41,10 @@ static inline void ratelimit_state_init(struct
> > ratelimit_state *rs,
> >  {
> >         memset(rs, 0, sizeof(*rs));
> > 
> > -       raw_spin_lock_init(&rs->lock);
> >         rs->interval    = interval;
> >         rs->burst       = burst;
> > +       atomic_set(&rs->printed, 0);
> > +       atomic_set(&rs->missed, 0);
> 
> Can it be
> 
> *rs = RATELIMIT_STATE_INIT(interval, burst);
> 
> ?
> 
> (Yes, the '(struct ratelimit_state)' has to be added to macro to
> allow this)

Sure.

> >  static inline void ratelimit_state_exit(struct ratelimit_state
> > *rs)
> >  {
> > +       int missed;
> > +
> >         if (!(rs->flags & RATELIMIT_MSG_ON_RELEASE))
> >                 return;
> > 
> > -       if (rs->missed) {
> > +       if ((missed = atomic_xchg(&rs->missed, 0)))
> 
> Perhaps
> 
> missed = ...
> if (missed)
> 
> ?

Ok, will change - checkpatch has warned me, but I thought it's just a
preference than a rule.

> 
> >                 pr_warn("%s: %d output lines suppressed due to
> > ratelimiting\n",
> > -                       current->comm, rs->missed);
> > -               rs->missed = 0;
> > -       }
> > +                       current->comm, missed);
> >  }
> > +static void ratelimit_end_interval(struct ratelimit_state *rs,
> > const char *func)
> > +{
> > +       rs->begin = jiffies;
> > +
> > +       if (!(rs->flags & RATELIMIT_MSG_ON_RELEASE)) {
> > +               unsigned missed = (unsigned)atomic_xchg(&rs-
> > >missed, 0);
> > +
> > +               if (missed)
> > +                       pr_warn("%s: %u callbacks suppressed\n",
> > func, missed);
> 
> Instead of casting, perhaps
> 
> int missed = ...
> 
> I think you already has a guard against going it below zero. Or I
> missed something?

No, I do:
atomic_add_unless(&rs->missed, 1, -1);

So, it's guard against overflow, but not against negative.
That's why I do print it as unsigned.

-- 
Thanks,
             Dmitry