linux-toradex.git/net/core/drop_monitor.c, branch v3.10.8

drop_monitor: dont sleep in atomic context

2012-06-04T15:42:01+00:00

drop_monitor calls several sleeping functions while in atomic context.

 BUG: sleeping function called from invalid context at mm/slub.c:943
 in_atomic(): 1, irqs_disabled(): 0, pid: 2103, name: kworker/0:2
 Pid: 2103, comm: kworker/0:2 Not tainted 3.5.0-rc1+ #55
 Call Trace:
  [] __might_sleep+0xca/0xf0
  [] kmem_cache_alloc_node+0x1b3/0x1c0
  [] ? queue_delayed_work_on+0x11c/0x130
  [] __alloc_skb+0x4b/0x230
  [] ? reset_per_cpu_data+0x160/0x160 [drop_monitor]
  [] reset_per_cpu_data+0x2f/0x160 [drop_monitor]
  [] send_dm_alert+0x4b/0xb0 [drop_monitor]
  [] process_one_work+0x130/0x4c0
  [] worker_thread+0x159/0x360
  [] ? manage_workers.isra.27+0x240/0x240
  [] kthread+0x93/0xa0
  [] kernel_thread_helper+0x4/0x10
  [] ? kthread_freezable_should_stop+0x80/0x80
  [] ? gs_change+0xb/0xb

Rework the logic to call the sleeping functions in right context.

Use standard timer/workqueue api to let system chose any cpu to perform
the allocation and netlink send.

Also avoid a loop if reset_per_cpu_data() cannot allocate memory :
use mod_timer() to wait 1/10 second before next try.

Signed-off-by: Eric Dumazet 
Cc: Neil Horman 
Reviewed-by: Neil Horman 
Signed-off-by: David S. Miller

drop_monitor: Add module alias to enable automatic module loading

2012-05-30T02:33:56+00:00

Now that we have module alias macros for generic netlink families, lets use
those to mark modules with the appropriate family names for loading

Signed-off-by: Neil Horman 
CC: Eric Dumazet 
CC: David Miller 
Signed-off-by: David S. Miller

drop_monitor: convert to modular building

2012-05-17T20:09:07+00:00

When I first wrote drop monitor I wrote it to just build monolithically.  There
is no reason it can't be built modularly as well, so lets give it that
flexibiity.

I've tested this by building it as both a module and monolithically, and it
seems to work quite well

Change notes:

v2)
* fixed for_each_present_cpu loops to be more correct as per Eric D.
* Converted exit path failures to BUG_ON as per Ben H.

v3)
* Converted del_timer to del_timer_sync to close race noted by Ben H.

Signed-off-by: Neil Horman 
CC: "David S. Miller" 
CC: Eric Dumazet 
CC: Ben Hutchings 
Reviewed-by: Ben Hutchings 
Signed-off-by: David S. Miller

net: core: Use pr_

2012-05-17T09:00:04+00:00

Use the current logging style.

This enables use of dynamic debugging as well.

Convert printk(KERN_ to pr_.
Add pr_fmt. Remove embedded prefixes, use
%s, __func__ instead.

Signed-off-by: Joe Perches 
Signed-off-by: David S. Miller

drop_monitor: prevent init path from scheduling on the wrong cpu

2012-05-03T01:02:48+00:00

I just noticed after some recent updates, that the init path for the drop
monitor protocol has a minor error.  drop monitor maintains a per cpu structure,
that gets initalized from a single cpu.  Normally this is fine, as the protocol
isn't in use yet, but I recently made a change that causes a failed skb
allocation to reschedule itself .  Given the current code, the implication is
that this workqueue reschedule will take place on the wrong cpu.  If drop
monitor is used early during the boot process, its possible that two cpus will
access a single per-cpu structure in parallel, possibly leading to data
corruption.

This patch fixes the situation, by storing the cpu number that a given instance
of this per-cpu data should be accessed from.  In the case of a need for a
reschedule, the cpu stored in the struct is assigned the rescheule, rather than
the currently executing cpu

Tested successfully by myself.

Signed-off-by: Neil Horman 
CC: David Miller 
Signed-off-by: David S. Miller

drop_monitor: Make updating data->skb smp safe

2012-04-28T06:18:48+00:00

Eric Dumazet pointed out to me that the drop_monitor protocol has some holes in
its smp protections.  Specifically, its possible to replace data->skb while its
being written.  This patch corrects that by making data->skb an rcu protected
variable.  That will prevent it from being overwritten while a tracepoint is
modifying it.

Signed-off-by: Neil Horman 
Reported-by: Eric Dumazet 
CC: David Miller 
Acked-by: Eric Dumazet 
Signed-off-by: David S. Miller

drop_monitor: fix sleeping in invalid context warning

2012-04-28T06:18:48+00:00

Eric Dumazet pointed out this warning in the drop_monitor protocol to me:

[   38.352571] BUG: sleeping function called from invalid context at kernel/mutex.c:85
[   38.352576] in_atomic(): 1, irqs_disabled(): 0, pid: 4415, name: dropwatch
[   38.352580] Pid: 4415, comm: dropwatch Not tainted 3.4.0-rc2+ #71
[   38.352582] Call Trace:
[   38.352592]  [] ? trace_napi_poll_hit+0xd0/0xd0
[   38.352599]  [] __might_sleep+0xca/0xf0
[   38.352606]  [] mutex_lock+0x26/0x50
[   38.352610]  [] ? trace_napi_poll_hit+0xd0/0xd0
[   38.352616]  [] tracepoint_probe_register+0x29/0x90
[   38.352621]  [] set_all_monitor_traces+0x105/0x170
[   38.352625]  [] net_dm_cmd_trace+0x2a/0x40
[   38.352630]  [] genl_rcv_msg+0x21a/0x2b0
[   38.352636]  [] ? zone_statistics+0x99/0xc0
[   38.352640]  [] ? genl_rcv+0x30/0x30
[   38.352645]  [] netlink_rcv_skb+0xa9/0xd0
[   38.352649]  [] genl_rcv+0x20/0x30
[   38.352653]  [] netlink_unicast+0x1ae/0x1f0
[   38.352658]  [] netlink_sendmsg+0x2b6/0x310
[   38.352663]  [] sock_sendmsg+0x10f/0x130
[   38.352668]  [] ? move_addr_to_kernel+0x60/0xb0
[   38.352673]  [] ? verify_iovec+0x64/0xe0
[   38.352677]  [] __sys_sendmsg+0x386/0x390
[   38.352682]  [] ? handle_mm_fault+0x139/0x210
[   38.352687]  [] ? do_page_fault+0x1ec/0x4f0
[   38.352693]  [] ? set_next_entity+0x9d/0xb0
[   38.352699]  [] ? tty_ldisc_deref+0x9/0x10
[   38.352703]  [] ? pick_next_task_fair+0x63/0x140
[   38.352708]  [] sys_sendmsg+0x44/0x80
[   38.352713]  [] system_call_fastpath+0x16/0x1b

It stems from holding a spinlock (trace_state_lock) while attempting to register
or unregister tracepoint hooks, making in_atomic() true in this context, leading
to the warning when the tracepoint calls might_sleep() while its taking a mutex.
Since we only use the trace_state_lock to prevent trace protocol state races, as
well as hardware stat list updates on an rcu write side, we can just convert the
spinlock to a mutex to avoid this problem.

Signed-off-by: Neil Horman 
Reported-by: Eric Dumazet 
CC: David Miller 
Acked-by: Eric Dumazet 
Signed-off-by: David S. Miller

drop_monitor: allow more events per second

2012-04-21T20:28:38+00:00

It seems there is a logic error in trace_drop_common(), since we store
only 64 drops, even if they are from same location.

This fix is a one liner, but we probably need more work to avoid useless
atomic dec/inc

Now I can watch 1 Mpps drops through dropwatch...

Signed-off-by: Eric Dumazet 
Cc: Neil Horman 
Acked-by: Neil Horman 
Signed-off-by: David S. Miller

net,rcu: convert call_rcu(free_dm_hw_stat) to kfree_rcu()

2011-05-08T05:50:59+00:00

The rcu callback free_dm_hw_stat() just calls a kfree(),
so we use kfree_rcu() instead of the call_rcu(free_dm_hw_stat).

Signed-off-by: Lai Jiangshan 
Acked-by: Neil Horman 
Acked-by: David S. Miller 
Signed-off-by: Paul E. McKenney 
Reviewed-by: Josh Triplett

net: fix incorrect spelling in drop monitor protocol

2011-03-22T01:20:26+00:00

It was pointed out to me recently that my spelling could be better :)

Signed-off-by: Neil Horman 
Signed-off-by: David S. Miller