net: drop the always take qdisc busylock patch

This used to be a bitfield with __QDISC___STATE_RUNNING, but after
mainline f9eb8aea2a1e ("net_sched: transform qdisc running bit into
a seqcount") it is no longer that simple.  If we persist in faking
out the lock state with this commit, we'll see the followiing from
migrate_enable when SCHED_DEBUG is on:

  WARNING: CPU: 0 PID: 1464 at kernel/sched/core.c:3415 migrate_enable+0x12a/0x160
  CPU: 0 PID: 1464 Comm: dhclient Not tainted 4.8.0-rc8-00284-g247e358567b5 #40
  Hardware name: Dell Inc. OptiPlex 760                 /0M858N, BIOS A16 08/06/2013
   0000000000000000 ffff880037083bc8 ffffffff81308435 0000000000000000
   0000000000000000 ffff880037083c08 ffffffff8105c68f 00000d5737084000
   ffff880072083500 0000000000000002 ffff880072167c00 ffffffff81ec9aa0
  Call Trace:
   [<ffffffff81308435>] dump_stack+0x4f/0x6a
   [<ffffffff8105c68f>] __warn+0xdf/0x100
   [<ffffffff8105c768>] warn_slowpath_null+0x18/0x20
   [<ffffffff8108161a>] migrate_enable+0x12a/0x160
   [<ffffffff81943bb2>] rt_spin_unlock+0x22/0x30
   [<ffffffff81782b74>] __dev_queue_xmit+0x384/0x580
   [<ffffffff81782d7b>] dev_queue_xmit+0xb/0x10
   [<ffffffff8188ded0>] packet_sendmsg+0xb30/0x1390
   [<ffffffff81943bb2>] ? rt_spin_unlock+0x22/0x30
   [<ffffffff8109c8f3>] ? __wake_up_sync_key+0x43/0x50
   [<ffffffff812ade4c>] ? sock_has_perm+0x4c/0x90
   [<ffffffff8176742d>] ? sock_def_readable+0x6d/0x70
   [<ffffffff817637e3>] sock_sendmsg+0x33/0x40
   [<ffffffff81763866>] sock_write_iter+0x76/0xd0
   [<ffffffff8119b19f>] __vfs_write+0xbf/0x120
   [<ffffffff8119c213>] vfs_write+0xb3/0x1b0
   [<ffffffff8104ed48>] ? __do_page_fault+0x1c8/0x570
   [<ffffffff8119d524>] SyS_write+0x44/0xa0
   [<ffffffff81943e1b>] entry_SYSCALL_64_fastpath+0x13/0x8f

Given the mainline commit above and the one above it that reduces the scope
of the root lock usage: commit edb09eb17ed8 (net: sched: do not acquire qdisc
spinlock in qdisc/class stats dump"), and the resulting splat, we drop this
change for now.

If we redo it at a later date, we should address the obviously false use
of "unlikely" that it causes.

Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2 files changed
tree: da073e6ac1f7fa70eddf00b34cdb78e6440e010c
  1. patches/