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

net: drop_monitor: fix the value of maxattr

2014-01-15T23:27:10+00:00

[ Upstream commit d323e92cc3f4edd943610557c9ea1bb4bb5056e8 ]

maxattr in genl_family should be used to save the max attribute
type, but not the max command type. Drop monitor doesn't support
any attributes, so we should leave it as zero.

Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

drop_monitor: dont sleep in atomic context

2012-07-16T16:03:44+00:00

[ Upstream commit bec4596b4e6770c7037f21f6bd27567b152dc0d6 ]

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 
Signed-off-by: Greg Kroah-Hartman

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

drop_monitor: use genl_register_family_with_ops()

2010-07-27T03:59:42+00:00

[ Fix unused local variable build warnings. -DaveM ]

Signed-off-by: Changli Gao 
Acked-by: Neil Horman 
Signed-off-by: David S. Miller

drop_monitor: Add error code to detect duplicate state changes

2010-07-20T20:28:04+00:00

	Patch to add -EAGAIN error to dropwatch netlink message handling code.
-EAGAIN will be returned anytime userspace attempts to transition the state of
the drop monitor service to a state that its already in.  That allows user space
to detect this condition, so it doesn't wait for a success ACK that will never
arrive.  Tested successfully by me

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