08 May, 2011

1 commit


11 Sep, 2010

1 commit


03 Sep, 2010

1 commit

  • This patch fixes a lockdep warning:

    [ 516.287584] =========================================================
    [ 516.288386] [ INFO: possible irq lock inversion dependency detected ]
    [ 516.288386] 2.6.35b #7
    [ 516.288386] ---------------------------------------------------------
    [ 516.288386] swapper/0 just changed the state of lock:
    [ 516.288386] (&qdisc_tx_lock){+.-...}, at: [] est_timer+0x62/0x1b4
    [ 516.288386] but this lock took another, SOFTIRQ-unsafe lock in the past:
    [ 516.288386] (est_tree_lock){+.+...}
    [ 516.288386]
    [ 516.288386] and interrupts could create inverse lock ordering between them.
    ...

    So, est_tree_lock needs BH protection because it's taken by
    qdisc_tx_lock, which is used both in BH and process contexts.
    (Full warning with this patch at netdev, 02 Sep 2010.)

    Fixes commit: ae638c47dc040b8def16d05dc6acdd527628f231
    ("pkt_sched: gen_estimator: add a new lock")

    Signed-off-by: Jarek Poplawski
    Signed-off-by: David S. Miller

    Jarek Poplawski
     

12 Jun, 2010

1 commit

  • gen_kill_estimator() API is incomplete or not well documented, since
    caller should make sure an RCU grace period is respected before
    freeing stats_lock.

    This was partially addressed in commit 5d944c640b4
    (gen_estimator: deadlock fix), but same problem exist for all
    gen_kill_estimator() users, if lock they use is not already RCU
    protected.

    A code review shows xt_RATEEST.c, act_api.c, act_police.c have this
    problem. Other are ok because they use qdisc lock, already RCU
    protected.

    Signed-off-by: Eric Dumazet
    Signed-off-by: David S. Miller

    Eric Dumazet
     

11 Jun, 2010

1 commit

  • gen_kill_estimator() / gen_new_estimator() is not always called with
    RTNL held.

    net/netfilter/xt_RATEEST.c is one user of these API that do not hold
    RTNL, so random corruptions can occur between "tc" and "iptables".

    Add a new fine grained lock instead of trying to use RTNL in netfilter.

    Signed-off-by: Eric Dumazet
    Signed-off-by: David S. Miller

    Eric Dumazet
     

30 Mar, 2010

1 commit

  • …it slab.h inclusion from percpu.h

    percpu.h is included by sched.h and module.h and thus ends up being
    included when building most .c files. percpu.h includes slab.h which
    in turn includes gfp.h making everything defined by the two files
    universally available and complicating inclusion dependencies.

    percpu.h -> slab.h dependency is about to be removed. Prepare for
    this change by updating users of gfp and slab facilities include those
    headers directly instead of assuming availability. As this conversion
    needs to touch large number of source files, the following script is
    used as the basis of conversion.

    http://userweb.kernel.org/~tj/misc/slabh-sweep.py

    The script does the followings.

    * Scan files for gfp and slab usages and update includes such that
    only the necessary includes are there. ie. if only gfp is used,
    gfp.h, if slab is used, slab.h.

    * When the script inserts a new include, it looks at the include
    blocks and try to put the new include such that its order conforms
    to its surrounding. It's put in the include block which contains
    core kernel includes, in the same order that the rest are ordered -
    alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
    doesn't seem to be any matching order.

    * If the script can't find a place to put a new include (mostly
    because the file doesn't have fitting include block), it prints out
    an error message indicating which .h file needs to be added to the
    file.

    The conversion was done in the following steps.

    1. The initial automatic conversion of all .c files updated slightly
    over 4000 files, deleting around 700 includes and adding ~480 gfp.h
    and ~3000 slab.h inclusions. The script emitted errors for ~400
    files.

    2. Each error was manually checked. Some didn't need the inclusion,
    some needed manual addition while adding it to implementation .h or
    embedding .c file was more appropriate for others. This step added
    inclusions to around 150 files.

    3. The script was run again and the output was compared to the edits
    from #2 to make sure no file was left behind.

    4. Several build tests were done and a couple of problems were fixed.
    e.g. lib/decompress_*.c used malloc/free() wrappers around slab
    APIs requiring slab.h to be added manually.

    5. The script was run on all .h files but without automatically
    editing them as sprinkling gfp.h and slab.h inclusions around .h
    files could easily lead to inclusion dependency hell. Most gfp.h
    inclusion directives were ignored as stuff from gfp.h was usually
    wildly available and often used in preprocessor macros. Each
    slab.h inclusion directive was examined and added manually as
    necessary.

    6. percpu.h was updated not to include slab.h.

    7. Build test were done on the following configurations and failures
    were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
    distributed build env didn't work with gcov compiles) and a few
    more options had to be turned off depending on archs to make things
    build (like ipr on powerpc/64 which failed due to missing writeq).

    * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
    * powerpc and powerpc64 SMP allmodconfig
    * sparc and sparc64 SMP allmodconfig
    * ia64 SMP allmodconfig
    * s390 SMP allmodconfig
    * alpha SMP allmodconfig
    * um on x86_64 SMP allmodconfig

    8. percpu.h modifications were reverted so that it could be applied as
    a separate patch and serve as bisection point.

    Given the fact that I had only a couple of failures from tests on step
    6, I'm fairly confident about the coverage of this conversion patch.
    If there is a breakage, it's likely to be something in one of the arch
    headers which should be easily discoverable easily on most builds of
    the specific arch.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo
     

18 Aug, 2009

1 commit

  • In 5e140dfc1fe87eae27846f193086724806b33c7d "net: reorder struct Qdisc
    for better SMP performance" the definition of struct gnet_stats_basic
    changed incompatibly, as copies of this struct are shipped to
    userland via netlink.

    Restoring old behavior is not welcome, for performance reason.

    Fix is to use a private structure for kernel, and
    teach gnet_stats_copy_basic() to convert from kernel to user land,
    using legacy structure (struct gnet_stats_basic)

    Based on a report and initial patch from Michael Spang.

    Reported-by: Michael Spang
    Signed-off-by: Eric Dumazet
    Signed-off-by: David S. Miller

    Eric Dumazet
     

26 May, 2009

1 commit


19 May, 2009

1 commit


27 Nov, 2008

1 commit

  • Since all other gen_estimator functions use bstats and rate_est params
    together, and searching for them is optimized now, let's use this also
    in gen_estimator_active(). The return type of gen_estimator_active()
    is changed to bool, and gen_find_node() parameters to const, btw.

    In tcf_act_police_locate() a check for ACT_P_CREATED is added before
    calling gen_estimator_active().

    Signed-off-by: Jarek Poplawski
    Signed-off-by: David S. Miller

    Jarek Poplawski
     

26 Nov, 2008

1 commit

  • Found that while trying average rate policing, it was possible to
    request average rate policing without a rate estimator. This results
    in no policing which is harmless but incorrect.

    Since policing could be setup in two steps, need to check
    in the kernel.

    Signed-off-by: Stephen Hemminger
    Signed-off-by: David S. Miller

    Stephen Hemminger
     

25 Nov, 2008

1 commit

  • gen_kill_estimator() linear lists lookups are very slow, and e.g. while
    deleting a large number of HTB classes soft lockups were reported. Here
    is another try to fix this problem: this time internally, with rbtree,
    so similarly to Jamal's hashing idea IIRC. (Looking for next hits could
    be still optimized, but it's really fast as it is.)

    Reported-by: Badalian Vyacheslav
    Reported-by: Denys Fedoryshchenko
    Signed-off-by: Jarek Poplawski
    Acked-by: Jamal Hadi Salim
    Signed-off-by: David S. Miller

    Jarek Poplawski
     

19 Aug, 2008

1 commit


14 Aug, 2008

1 commit


29 Jan, 2008

3 commits


20 Oct, 2007

1 commit

  • remove asm/bitops.h includes

    including asm/bitops directly may cause compile errors. don't include it
    and include linux/bitops instead. next patch will deny including asm header
    directly.

    Cc: Adrian Bunk
    Signed-off-by: Jiri Slaby
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jiri Slaby
     

18 Jul, 2007

1 commit

  • -Fixes ABBA deadlock noted by Patrick McHardy :

    > There is at least one ABBA deadlock, est_timer() does:
    > read_lock(&est_lock)
    > spin_lock(e->stats_lock) (which is dev->queue_lock)
    >
    > and qdisc_destroy calls htb_destroy under dev->queue_lock, which
    > calls htb_destroy_class, then gen_kill_estimator and this
    > write_locks est_lock.

    To fix the ABBA deadlock the rate estimators are now kept on an rcu list.

    -The est_lock changes the use from protecting the list to protecting
    the update to the 'bstat' pointer in order to avoid NULL dereferencing.

    -The 'interval' member of the gen_estimator structure removed as it is
    not needed.

    Signed-off-by: Ranko Zivojnovic
    Signed-off-by: David S. Miller

    Ranko Zivojnovic
     

11 Jul, 2007

1 commit

  • As noticed by Jarek Poplawski , the timer removal in
    gen_kill_estimator races with the timer function rearming the timer.

    Check whether the timer list is empty before rearming the timer
    in the timer function to fix this.

    Signed-off-by: Patrick McHardy
    Acked-by: Jarek Poplawski
    Signed-off-by: David S. Miller

    Patrick McHardy
     

11 Feb, 2007

1 commit


10 Apr, 2006

1 commit


17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds