This cleans up the irqflags tracing code quite a bit and ties it
in to various missing callsites that caused an imbalance when
CONFIG_PROVE_LOCKING was enabled.

Previously this was catching on:

 987 #ifdef CONFIG_PROVE_LOCKING
 988     DEBUG_LOCKS_WARN_ON(!p->hardirqs_enabled);
 989     DEBUG_LOCKS_WARN_ON(!p->softirqs_enabled);
 990 #endif
 991     retval = -EAGAIN;

with hardirqs being doubly enabled, and subsequently bailing out
with the following call trace:

	Call trace:
	[<88035224>] __lock_acquire+0x616/0x6a6
	[<88015a8c>] do_fork+0xf8/0x2b0
	[<880331ec>] trace_hardirqs_on_caller+0xd4/0x114
	[<88241074>] _spin_unlock_irq+0x20/0x64
	[<88035224>] __lock_acquire+0x616/0x6a6
	[<8800386c>] kernel_thread+0x48/0x70
	[<88024ecc>] ____call_usermodehelper+0x0/0x110
	[<88024ecc>] ____call_usermodehelper+0x0/0x110
	[<88003894>] kernel_thread_helper+0x0/0x14
	[<88024bac>] __call_usermodehelper+0x38/0x70
	[<88025dc0>] worker_thread+0x150/0x274
	[<88035b9c>] lock_release+0x0/0x198
	[<88024b74>] __call_usermodehelper+0x0/0x70
	[<88028cf0>] autoremove_wake_function+0x0/0x30
	[<88028bf2>] kthread+0x3e/0x70
	[<88025c70>] worker_thread+0x0/0x274
	[<8800389c>] kernel_thread_helper+0x8/0x14
	[<88028bb4>] kthread+0x0/0x70
	[<88003894>] kernel_thread_helper+0x0/0x14
Reported-by: Nobuhiro Iwamatsu <iwamatsu.nobuhiro@renesas.com>
Signed-off-by: Stuart Menefy <stuart.menefy@st.com>
Signed-off-by: Matt Fleming <matt@console-pimps.org>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>