lkml.org 
[lkml]   [2006]   [Mar]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Connector: Filesystem Events Connector
    On 3/24/06, Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
    > On Fri, Mar 24, 2006 at 01:42:17AM -0800, Matt Helsley (matthltc@us.ibm.com)
    > wrote:
    > > On Fri, 2006-03-24 at 11:11 +0300, Evgeniy Polyakov wrote:
    > > > On Thu, Mar 23, 2006 at 11:35:50PM -0800, Matt Helsley
    > (matthltc@us.ibm.com) wrote:
    > > > > I would argue preemption should be disabled around the if-block at the
    > > > > very least. Suppose your rate limit is 10k calls/sec and you have 4
    > > > > procs. Each proc has a sequence of three instructions:
    > > > >
    > > > > load fsevent_sum into register rx (rx <= 1000)
    > > > > rx++ (rx <= 1001)
    > > > > store contents of register rx in fsevent_sum (fsevent_sum <= 1001)
    > > > >
    > > > >
    > > > > Now consider the following sequence of steps:
    > > > >
    > > > > load fsevent_sum into rx (rx <= 1000)
    > > > > <preempted>
    > > > > <3 other processors each manage to increment the sum by 3333 bringing
    > us
    > > > > to 9999>
    > > > > <resumed>
    > > > > rx++ (rx <= 1001)
    > > > > store contents of rx in fsevent_sum (fsevent_sum <= 1001)
    > > > >
    > > > > So every processor now thinks it won't exceed the rate limit by
    > > > > generating more events when in fact we've just exceeded the limit. So,
    > > > > unless my example is flawed, I think you need to disable preemption
    > > > > here.
    > > >
    > > > Doesn't it just exceed the limit by one event per cpu?
    > >
    > > The example exceeds it by one at the time of the final store. Thanks to
    > > the fact that the value is then 1001 it may shortly be exceeded by much
    > > more than 1.
    >
    > +
    > + if (jiffies - last <= fsevent_ratelimit) {
    > + if (fsevent_sum > fsevent_burst_limit)
    > + return -2;
    > + fsevent_sum++;
    >
    > Only process (and not process' syscall) can preempt us here,
    > so fsevent_sum can only exceed fsevent_burst_limit by one per process
    > (process can not preempt itself, so when it has finished syscall which
    > ends up in event generation, fsevent_sum will be increased).
    >
    > + } else {
    > + last = jiffies;
    > + fsevent_sum = 0;
    > + }
    >
    > Actually, since jiffies and atomic operations are already used, I do not
    > think addition of new atomic_inc_return or something similar will
    > even somehow change the picture.
    rate limit is just for some abnormal cases, for example, an
    application leads to a unlimited event loop, it should be very few, in
    the worst case, the user application which induced this case will
    terminate, this should be a reasonable result.
    rate limit is intent to prevent this kind of case and avoid DoS of system.
    >
    >
    > > Cheers,
    > > -Matt Helsley
    >
    > --
    > Evgeniy Polyakov
    >
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-03-24 15:06    [W:0.024 / U:89.856 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site