Pass the work_struct pointer to the work function rather than context data.
The work function can use container_of() to work out the data.
For the cases where the container of the work_struct may go away the moment the
pending bit is cleared, it is made possible to defer the release of the
structure by deferring the clearing of the pending bit.
To make this work, an extra flag is introduced into the management side of the
work_struct. This governs auto-release of the structure upon execution.
Ordinarily, the work queue executor would release the work_struct for further
scheduling or deallocation by clearing the pending bit prior to jumping to the
work function. This means that, unless the driver makes some guarantee itself
that the work_struct won't go away, the work function may not access anything
else in the work_struct or its container lest they be deallocated.. This is a
problem if the auxiliary data is taken away (as done by the last patch).
However, if the pending bit is *not* cleared before jumping to the work
function, then the work function *may* access the work_struct and its container
with no problems. But then the work function must itself release the
work_struct by calling work_release().
In most cases, automatic release is fine, so this is the default. Special
initiators exist for the non-auto-release case (ending in _NAR).
Signed-Off-By: David Howells <dhowells@redhat.com>
Reclaim a word from the size of the work_struct by folding the pending bit and
the wq_data pointer together. This shouldn't cause misalignment problems as
all pointers should be at least 4-byte aligned.
Signed-Off-By: David Howells <dhowells@redhat.com>
Define a type for the work function prototype. It's not only kept in the
work_struct struct, it's also passed as an argument to several functions.
This makes it easier to change it.
Signed-Off-By: David Howells <dhowells@redhat.com>
Separate delayable work items from non-delayable work items be splitting them
into a separate structure (delayed_work), which incorporates a work_struct and
the timer_list removed from work_struct.
The work_struct struct is huge, and this limits it's usefulness. On a 64-bit
architecture it's nearly 100 bytes in size. This reduces that by half for the
non-delayable type of event.
Signed-Off-By: David Howells <dhowells@redhat.com>
* master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6:
[TG3]: Add missing unlock in tg3_open() error path.
[IPV6]: Fix address/interface handling in UDP and DCCP, according to the scoping architecture.
[IRDA]: Lockdep fix.
[BLUETOOTH]: Fix unaligned access in hci_send_to_sock.
[XFRM]: nlmsg length not computed correctly in the presence of subpolicies
[XFRM]: Sub-policies broke policy events
[IGMP]: Fix IGMPV3_EXP() normalization bit shift value.
[Bluetooth] Ignore L2CAP config requests on disconnect
[Bluetooth] Always include MTU in L2CAP config responses
[Bluetooth] Check if RFCOMM session is still attached to the TTY
[Bluetooth] Handling pending connect attempts after inquiry
[Bluetooth] Attach low-level connections to the Bluetooth bus
[IPV6] IP6TUNNEL: Add missing nf_reset() on input path.
[IPV6] IP6TUNNEL: Delete all tunnel device when unloading module.
[IPV6] ROUTE: Do not enable router reachability probing in router mode.
[IPV6] ROUTE: Prefer reachable nexthop only if the caller requests.
[IPV6] ROUTE: Try to use router which is not known unreachable.
mpc832x, as in mpc8360, needs to explicitly find and create the
platform device for ucc_geth in 2.6.19. This code will likely be
readapted to Benh's new of_ methods for 2.6.20.
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Sparse noticed a locking imbalance in tg3_open(). This patch adds an
unlock to one of the error paths, so that tg3_open() always exits
without the lock held.
Signed-off-by: Ira W. Snyder <kernel@irasnyder.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
TCP and RAW do not have this issue. Closes Bug #7432.
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
The "u16 *" derefs of skb->data need to be wrapped inside of
a get_unaligned().
Thanks to Gustavo Zacarias for the bug report.
Signed-off-by: David S. Miller <davem@davemloft.net>
I actually dont have a test case for these; i just found them by
inspection. Refer to patch "[XFRM]: Sub-policies broke policy events"
for more info
Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
Acked-by: Masahide NAKAMURA <nakam@linux-ipv6.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
XFRM policy events are broken when sub-policy feature is turned on.
A simple test to verify this:
run ip xfrm mon on one window and add then delete a policy on another
window ..
Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
Acked-by: Masahide NAKAMURA <nakam@linux-ipv6.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
The IGMPV3_EXP() macro doesn't correctly shift the normalization bit, so
time-out values are longer than they should be.
Thanks to Dirk Ooms for finding the problem in IGMPv3 - MLDv2 had a
similar problem that was already fixed a year ago. :-(
Signed-off-by: David L Stevens <dlstevens@us.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Any L2CAP connection in disconnecting state shall not response
to any further config requests from the remote side. So in case
such a request is received, ignore it.
Signed-off-by: Ville Tervo <ville.tervo@nokia.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
When sending a positive config response it shall include the actual
MTU to be used on this channel. This differs from the Bluetooth 1.1
specification where it was enough to acknowledge the config request.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
If the RFCOMM session is no longer attached to the TTY device, then it
makes no sense to go through with changing the termios settings.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
After an inquiry completed or got canceled the Bluetooth core should
check for any pending connect attempts.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
To receive uvents for the low-level ACL and SCO links, they must be
assigned to a subsystem. It is enough to attach them to the already
established Bluetooth bus.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
RFC4191 explicitly states that the procedures are applicable to
hosts only. We should not have changed behavior of routers.
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Only routers in "FAILED" state should be considered unreachable.
Otherwise, we do not try to use speicific routes unless all least specific
routers are considered unreachable.
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
o Explicitly align data segment to PAGE_SIZE boundary otherwise depending on
config options and tool chain it might be placed on a non PAGE_SIZE aligned
boundary and vmlinux loaders like kexec fail when they encounter a
PT_LOAD type segment which is not aligned to PAGE_SIZE boundary.
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: Andi Kleen <ak@suse.de>
ipath uses skb functions and won't build without CONFIG_NET.
Spotted by Randy Dunlap.
Signed-off-by: Bryan O'Sullivan <bryan.osullivan@qlogic.com>
Acked-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
This is a quick hack to overcome the fact that SRCU currently does not
allow static initializers, and we need to sometimes initialize those
things before any other initializers (even "core" ones) can do so.
Currently we don't allow this at all for modules, and the only user that
needs is right now is cpufreq. As reported by Thomas Gleixner:
"Commit b4dfdbb3c7 ("[PATCH] cpufreq:
make the transition_notifier chain use SRCU breaks cpu frequency
notification users, which register the callback > on core_init
level."
Cc: Thomas Gleixner <tglx@timesys.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Arjan van de Ven <arjan@infradead.org>
Cc: Andrew Morton <akpm@osdl.org>,
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Switch to using irq_handler_t for interrupt function handler pointers.
Change name of m68knommu's irq_hanlder_t data structure so it doesn't
clash with the common type (include/linux/interrupt.h).
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Fix printk format warnings:
drivers/char/ftape/zftape/zftape-buffers.c:87: warning: format '%d' expects type
'int', but argument 3 has type 'size_t'
drivers/char/ftape/zftape/zftape-buffers.c:104: warning: format '%d' expects type
'int', but argument 3 has type 'size_t'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This is to fix compile error of x86-64 memory hotplug without any NUMA
option.
CC arch/x86_64/mm/init.o
arch/x86_64/mm/init.c:501: error: redefinition of 'memory_add_physaddr_to_nid'
include/linux/memory_hotplug.h:71: error: previous definition of 'memory_add_phys
addr_to_nid' was here
arch/x86_64/mm/init.c:509: error: redefinition of 'memory_add_physaddr_to_nid'
arch/x86_64/mm/init.c:501: error: previous definition of 'memory_add_physaddr_to_
nid' was here
I confirmed compile completion with !NUMA, (NUMA & !ACPI_NUMA),
or (NUMA & ACPI_NUMA).
Signed-off-by: Yasunori Goto <y-goto@jp.fujitsu.com>
Acked-by: Andi Kleen <ak@suse.de>
Cc: "Randy.Dunlap" <rdunlap@xenotime.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Having unbound PCMCIA devices: doing a 'find /sys' after a 'rmmod pcmcia'
gives an oops because the pcmcia_device is not unregisterd from the driver
core.
fixes bugzilla #7481
Signed-off-by: Daniel Ritz <daniel.ritz@gmx.ch>
Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Pavol Gono <Palo.Gono@gmail.com>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch has removed one too many semicolon in crypto.h.
Signed-off-by: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
I moved from Sweden to Finland 2.5 years ago, thought it might be time
to update my CREDITS entry (simply removing the address completely
seemed the sanest option).
Signed-off-by: David Weinehall <tao@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This reverts commit 37605a6900.
Again.
This same bug has now been introduced twice: it was done earlier by
commit b8d35192c5, only to be reverted
last time in commit 72945b2b90.
We must NOT try to queue up notify handlers to another thread than the
normal ACPI execution thread, because the notifications on some systems
seem to just keep on accumulating until we run out of memory and/or
threads.
Keeping events within the one deferred execution thread automatically
throttles the events properly.
At least the Compaq N620c will lock up completely on the first thermal
event without this patch reverted.
Cc: David Brownell <david-b@pacbell.net>
Cc: Len Brown <len.brown@intel.com>
Cc: Alexey Starikovskiy <alexey.y.starikovskiy@linux.intel.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
When showing the stack backtrace, make sure that we never accept not
only an unchanging frame pointer, but also a frame pointer that moves
back down the stack frame. It must always grow up (toward older stack
frames).
I doubt this has triggered, but a subtly corrupt stack with extremely
unlucky contents could cause us to loop forever on a bogus endless frame
pointer chain.
This review was triggered by much worse problems happening in some of
the other stack unwinding code.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
lockdep got confused by certain locks in modules:
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
Call Trace:
[<ffffffff8026f40d>] dump_trace+0xaa/0x3f2
[<ffffffff8026f78f>] show_trace+0x3a/0x60
[<ffffffff8026f9d1>] dump_stack+0x15/0x17
[<ffffffff802abfe8>] __lock_acquire+0x724/0x9bb
[<ffffffff802ac52b>] lock_acquire+0x4d/0x67
[<ffffffff80267139>] rt_spin_lock+0x3d/0x41
[<ffffffff8839ed3f>] :ip_conntrack:__ip_ct_refresh_acct+0x131/0x174
[<ffffffff883a1334>] :ip_conntrack:udp_packet+0xbf/0xcf
[<ffffffff8839f9af>] :ip_conntrack:ip_conntrack_in+0x394/0x4a7
[<ffffffff8023551f>] nf_iterate+0x41/0x7f
[<ffffffff8025946a>] nf_hook_slow+0x64/0xd5
[<ffffffff802369a2>] ip_rcv+0x24e/0x506
[...]
Steven Rostedt found the bug: static_obj() check did not take
PERCPU_ENOUGH_ROOM into account, so in-module DEFINE_PER_CPU-area locks
were triggering this message.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Steven Rostedt <srostedt@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The scheduler on Andreas Friedrich's hyperthreading system stopped
working properly: the scheduler would never move tasks to another CPU!
The lask known working kernel was 2.6.8.
After a couple of attempts to corner the bug, the following smoking gun
was found:
BIOS reported wrong ACPI idfor the processor
CPU#1: set_cpus_allowed(), swapper:1, 3 -> 2
[<c0103bbe>] show_trace_log_lvl+0x34/0x4a
[<c0103ceb>] show_trace+0x2c/0x2e
[<c01045f8>] dump_stack+0x2b/0x2d
[<c0116a77>] set_cpus_allowed+0x52/0xec
[<c0101d86>] cpu_idle_wait+0x2e/0x100
[<c0259c57>] acpi_processor_power_exit+0x45/0x58
[<c0259752>] acpi_processor_remove+0x46/0xea
[<c025c6fb>] acpi_start_single_object+0x47/0x54
[<c025cee5>] acpi_bus_register_driver+0xa4/0xd3
[<c04ab2d7>] acpi_processor_init+0x57/0x77
[<c01004d7>] init+0x146/0x2fd
[<c0103a87>] kernel_thread_helper+0x7/0x10
a quick look at cpu_idle_wait() shows how broken that code is
on i386: it changes the init task's affinity map but never
restores it ...
and because all userspace tasks get forked by init, they all
inherited that single-CPU affinity mask. x86_64 cloned this
bug too.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Cc: Andreas Friedrich <andreas.friedrich@fujitsu-siemens.com>
Cc: Wolfgang Erig <Wolfgang.Erig@fujitsu-siemens.com>
Cc: Andrew Morton <akpm@osdl.org>
Cc: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
the new dwarf2 unwinder crashes while trying to dump the stack:
Leftover inexact backtrace:
Unable to handle kernel paging request at ffffffff82800000 RIP:
[<ffffffff8026cf26>] dump_trace+0x35b/0x3d2
PGD 203027 PUD 205027 PMD 0
Oops: 0000 [2] PREEMPT SMP
CPU 0
Modules linked in:
Pid: 30, comm: khelper Not tainted 2.6.19-rc6-rt1 #11
RIP: 0010:[<ffffffff8026cf26>] [<ffffffff8026cf26>] dump_trace+0x35b/0x3d2
RSP: 0000:ffff81003fb9d848 EFLAGS: 00010006
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffff805b3520 RDI: 0000000000000000
RBP: ffffffff827ffff9 R08: ffffffff80aad000 R09: 0000000000000005
R10: ffffffff80aae000 R11: ffffffff8037961b R12: ffff81003fb9d858
R13: 0000000000000000 R14: ffffffff80598460 R15: ffffffff80ab1fc0
FS: 0000000000000000(0000) GS:ffffffff806c4200(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: ffffffff82800000 CR3: 0000000000201000 CR4: 00000000000006e0
this crash happened because it did not sanitize the dwarf2 data it
got, and got an unaligned stack pointer - which happily walked past
the process stack (and eventually reached the end of kernel memory
and pagefaulted there) due to this naive iteration condition:
HANDLE_STACK (((long) stack & (THREAD_SIZE-1)) != 0);
note that i386 is alot more conservative when it comes to trusting
stack pointers:
static inline int valid_stack_ptr(struct thread_info *tinfo, void *p)
{
return p > (void *)tinfo &&
p < (void *)tinfo + THREAD_SIZE - 3;
}
but the x86_64 code did not take this bit of i386 code.
The fix is to align the stack pointer.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Cc: Andi Kleen <ak@suse.de>
Cc: Jan Beulich <jbeulich@novell.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
