summaryrefslogtreecommitdiffstats
path: root/Documentation/i2c/i2c-stub (unfollow)
Commit message (Collapse)AuthorFilesLines
2013-06-30powerpc/eeh: Fix fetching bus for single-dev-PEGavin Shan1-1/+2
While running Linux as guest on top of phyp, we possiblly have PE that includes single PCI device. However, we didn't return its PCI bus correctly and it leads to failure on recovery from EEH errors for single-dev-PE. The patch fixes the issue. Cc: <stable@vger.kernel.org> # v3.7+ Cc: Steve Best <sbest@us.ibm.com> Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-06-30ARM: dt: Only print warning, not WARN() on bad cpu map in device treeOlof Johansson1-2/+3
Due to recent changes and expecations of proper cpu bindings, there are now cases for many of the in-tree devicetrees where a WARN() will hit on boot due to badly formatted /cpus nodes. Downgrade this to a pr_warn() to be less alarmist, since it's not a new problem. Tested on Arndale, Cubox, Seaboard and Panda ES. Panda hits the WARN without this, the others do not. Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Olof Johansson <olof@lixom.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-06-30powerpc/pci: Improve device hotplug initializationGuenter Roeck1-5/+12
Commit 37f02195b (powerpc/pci: fix PCI-e devices rescan issue on powerpc platform) fixes a problem with interrupt and DMA initialization on hot plugged devices. With this commit, interrupt and DMA initialization for hot plugged devices is handled in the pci device enable function. This approach has a couple of drawbacks. First, it creates two code paths for device initialization, one for hot plugged devices and another for devices known during the initial PCI scan. Second, the initialization code for hot plugged devices is only called when the device is enabled, ie typically in the probe function. Also, the platform specific setup code is called each time pci_enable_device() is called, not only once during device discovery, meaning it is actually called multiple times, once for devices discovered during the initial scan and again each time a driver is re-loaded. The visible result is that interrupt pins are only assigned to hot plugged devices when the device driver is loaded. Effectively this changes the PCI probe API, since pci_dev->irq and the device's dma configuration will now only be valid after pci_enable() was called at least once. A more subtle change is that platform specific PCI device setup is moved from device discovery into the driver's probe function, more specifically into the pci_enable_device() call. To fix the inconsistencies, add new function pcibios_add_device. Call pcibios_setup_device from pcibios_setup_bus_devices if device setup is not complete, and from pcibios_add_device if bus setup is complete. With this change, device setup code is moved back into device initialization, and called exactly once for both static and hot plugged devices. [ This also fixes a regression introduced by the above patch which causes dev->irq to be overwritten under some cirumstances after MSIs have been enabled for the device which leads to crashes due to the MSI core "hijacking" dev->irq to store the base MSI number and not the LSI. --BenH ] Cc: Yuanquan Chen <Yuanquan.Chen@freescale.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Hiroo Matsumoto <matsumoto.hiroo@jp.fujitsu.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-06-29Fix: kernel/ptrace.c: ptrace_peek_siginfo() missing __put_user() validationMathieu Desnoyers1-9/+11
This __put_user() could be used by unprivileged processes to write into kernel memory. The issue here is that even if copy_siginfo_to_user() fails, the error code is not checked before __put_user() is executed. Luckily, ptrace_peek_siginfo() has been added within the 3.10-rc cycle, so it has not hit a stable release yet. Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Acked-by: Oleg Nesterov <oleg@redhat.com> Cc: Andrey Vagin <avagin@openvz.org> Cc: Roland McGrath <roland@redhat.com> Cc: Paul McKenney <paulmck@linux.vnet.ibm.com> Cc: David Howells <dhowells@redhat.com> Cc: Dave Jones <davej@redhat.com> Cc: Pavel Emelyanov <xemul@parallels.com> Cc: Pedro Alves <palves@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-06-29UBIFS: fix a horrid bugArtem Bityutskiy1-3/+27
Al Viro pointed me to the fact that '->readdir()' and '->llseek()' have no mutual exclusion, which means the 'ubifs_dir_llseek()' can be run while we are in the middle of 'ubifs_readdir()'. This means that 'file->private_data' can be freed while 'ubifs_readdir()' uses it, and this is a very bad bug: not only 'ubifs_readdir()' can return garbage, but this may corrupt memory and lead to all kinds of problems like crashes an security holes. This patch fixes the problem by using the 'file->f_version' field, which '->llseek()' always unconditionally sets to zero. We set it to 1 in 'ubifs_readdir()' and whenever we detect that it became 0, we know there was a seek and it is time to clear the state saved in 'file->private_data'. I tested this patch by writing a user-space program which runds readdir and seek in parallell. I could easily crash the kernel without these patches, but could not crash it with these patches. Cc: stable@vger.kernel.org Reported-by: Al Viro <viro@zeniv.linux.org.uk> Tested-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-06-29UBIFS: prepare to fix a horrid bugArtem Bityutskiy1-12/+12
Al Viro pointed me to the fact that '->readdir()' and '->llseek()' have no mutual exclusion, which means the 'ubifs_dir_llseek()' can be run while we are in the middle of 'ubifs_readdir()'. First of all, this means that 'file->private_data' can be freed while 'ubifs_readdir()' uses it. But this particular patch does not fix the problem. This patch is only a preparation, and the fix will follow next. In this patch we make 'ubifs_readdir()' stop using 'file->f_pos' directly, because 'file->f_pos' can be changed by '->llseek()' at any point. This may lead 'ubifs_readdir()' to returning inconsistent data: directory entry names may correspond to incorrect file positions. So here we introduce a local variable 'pos', read 'file->f_pose' once at very the beginning, and then stick to 'pos'. The result of this is that when 'ubifs_dir_llseek()' changes 'file->f_pos' while we are in the middle of 'ubifs_readdir()', the latter "wins". Cc: stable@vger.kernel.org Reported-by: Al Viro <viro@zeniv.linux.org.uk> Tested-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-06-28mn10300: Use early_param() to parse "mem=" parameterAkira Takeuchi1-33/+21
This fixes the problem that "init=" options may not be passed to kernel correctly. parse_mem_cmdline() of mn10300 arch gets rid of "mem=" string from redboot_command_line. Then init_setup() parses the "init=" options from static_command_line, which is a copy of redboot_command_line, and keeps the pointer to the init options in execute_command variable. Since the commit 026cee0 upstream (params: <level>_initcall-like kernel parameters), static_command_line becomes overwritten by saved_command_line at do_initcall_level(). Notice that saved_command_line is a command line which includes "mem=" string. As a result, execute_command may point to weird string by the length of "mem=" parameter. I noticed this problem when using the command line like this: mem=128M console=ttyS0,115200 init=/bin/sh Here is the processing flow of command line parameters. start_kernel() setup_arch(&command_line) parse_mem_cmdline(cmdline_p) * strcpy(boot_command_line, redboot_command_line); * Remove "mem=xxx" from redboot_command_line. * *cmdline_p = redboot_command_line; setup_command_line(command_line) <-- command_line is redboot_command_line * strcpy(saved_command_line, boot_command_line) * strcpy(static_command_line, command_line) parse_early_param() strlcpy(tmp_cmdline, boot_command_line, COMMAND_LINE_SIZE); parse_early_options(tmp_cmdline); parse_args("early options", cmdline, NULL, 0, 0, 0, do_early_param); parse_args("Booting ..", static_command_line, ...); init_setup() <-- save the pointer in execute_command rest_init() kernel_thread(kernel_init, NULL, CLONE_FS | CLONE_SIGHAND); At this point, execute_command points to "/bin/sh" string. kernel_init() kernel_init_freeable() do_basic_setup() do_initcalls() do_initcall_level() (*) strcpy(static_command_line, saved_command_line); Here, execute_command gets to point to "200" string !! Signed-off-by: David Howells <dhowells@redhat.com>
2013-06-28mn10300: Allow to pass array name to get_user()Akira Takeuchi1-1/+1
This fixes the following compile error: CC block/scsi_ioctl.o block/scsi_ioctl.c: In function 'sg_scsi_ioctl': block/scsi_ioctl.c:449: error: invalid initializer Signed-off-by: David Howells <dhowells@redhat.com>
2013-06-28drm/qxl: add missing access check for execbuffer ioctlDave Airlie1-0/+5
Reported-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-06-28powerpc/eeh: Add eeh_dev to the cache during bootThadeu Lima de Souza Cascardo1-2/+2
commit f8f7d63fd96ead101415a1302035137a866f8998 ("powerpc/eeh: Trace eeh device from I/O cache") broke EEH on pseries for devices that were present during boot and have not been hotplugged/DLPARed. eeh_check_failure will get the eeh_dev from the cache, and will get NULL. eeh_addr_cache_build adds the addresses to the cache, but eeh_dev for the giving pci_device is not set yet. Just reordering the call to eeh_addr_cache_insert_dev works fine. The ordering is similar to the one in eeh_add_device_late. Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com> Acked-by: Gavin Shan <shangw@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-06-27rbd: send snapshot context with writesJosh Durgin1-1/+5
Sending the right snapshot context with each write is required for snapshots to work. Due to the ordering of calls, the snapshot context is never set for any requests. This causes writes to the current version of the image to be reflected in all snapshots, which are supposed to be read-only. This happens because rbd_osd_req_format_write() sets the snapshot context based on obj_request->img_request. At this point, however, obj_request->img_request has not been set yet, to the snapshot context is set to NULL. Fix this by moving rbd_img_obj_request_add(), which sets obj_request->img_request, before the osd request formatting calls. This resolves: http://tracker.ceph.com/issues/5465 Reported-by: Karol Jurak <karol.jurak@gmail.com> Signed-off-by: Josh Durgin <josh.durgin@inktank.com> Reviewed-by: Sage Weil <sage@inktank.com> Reviewed-by: Alex Elder <elder@linaro.org>
2013-06-27dlci: validate the net device in dlci_del()Zefan Li1-0/+12
We triggered an oops while running trinity with 3.4 kernel: BUG: unable to handle kernel paging request at 0000000100000d07 IP: [<ffffffffa0109738>] dlci_ioctl+0xd8/0x2d4 [dlci] PGD 640c0d067 PUD 0 Oops: 0000 [#1] PREEMPT SMP CPU 3 ... Pid: 7302, comm: trinity-child3 Not tainted 3.4.24.09+ 40 Huawei Technologies Co., Ltd. Tecal RH2285 /BC11BTSA RIP: 0010:[<ffffffffa0109738>] [<ffffffffa0109738>] dlci_ioctl+0xd8/0x2d4 [dlci] ... Call Trace: [<ffffffff8137c5c3>] sock_ioctl+0x153/0x280 [<ffffffff81195494>] do_vfs_ioctl+0xa4/0x5e0 [<ffffffff8118354a>] ? fget_light+0x3ea/0x490 [<ffffffff81195a1f>] sys_ioctl+0x4f/0x80 [<ffffffff81478b69>] system_call_fastpath+0x16/0x1b ... It's because the net device is not a dlci device. Reported-by: Li Jinyue <lijinyue@huawei.com> Signed-off-by: Li Zefan <lizefan@huawei.com> Cc: stable@vger.kernel.org Signed-off-by: David S. Miller <davem@davemloft.net>
2013-06-27dlci: acquire rtnl_lock before calling __dev_get_by_name()Zefan Li1-5/+9
Otherwise the net device returned can be freed at anytime. Signed-off-by: Li Zefan <lizefan@huawei.com> Cc: stable@vger.kernel.org Signed-off-by: David S. Miller <davem@davemloft.net>
2013-06-27af_key: fix info leaks in notify messagesMathias Krause1-0/+2
key_notify_sa_flush() and key_notify_policy_flush() miss to initialize the sadb_msg_reserved member of the broadcasted message and thereby leak 2 bytes of heap memory to listeners. Fix that. Signed-off-by: Mathias Krause <minipli@googlemail.com> Cc: Steffen Klassert <steffen.klassert@secunet.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2013-06-27ipv6: ip6_sk_dst_check() must not assume ipv6 dstEric Dumazet1-1/+7
It's possible to use AF_INET6 sockets and to connect to an IPv4 destination. After this, socket dst cache is a pointer to a rtable, not rt6_info. ip6_sk_dst_check() should check the socket dst cache is IPv6, or else various corruptions/crashes can happen. Dave Jones can reproduce immediate crash with trinity -q -l off -n -c sendmsg -c connect With help from Hannes Frederic Sowa Reported-by: Dave Jones <davej@redhat.com> Reported-by: Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by: Eric Dumazet <edumazet@google.com> Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2013-06-26net: fix kernel deadlock with interface rename and netdev name retrieval.Nicolas Schichan4-30/+41
When the kernel (compiled with CONFIG_PREEMPT=n) is performing the rename of a network interface, it can end up waiting for a workqueue to complete. If userland is able to invoke a SIOCGIFNAME ioctl or a SO_BINDTODEVICE getsockopt in between, the kernel will deadlock due to the fact that read_secklock_begin() will spin forever waiting for the writer process (the one doing the interface rename) to update the devnet_rename_seq sequence. This patch fixes the problem by adding a helper (netdev_get_name()) and using it in the code handling the SIOCGIFNAME ioctl and SO_BINDTODEVICE setsockopt. The netdev_get_name() helper uses raw_seqcount_begin() to avoid spinning forever, waiting for devnet_rename_seq->sequence to become even. cond_resched() is used in the contended case, before retrying the access to give the writer process a chance to finish. The use of raw_seqcount_begin() will incur some unneeded work in the reader process in the contended case, but this is better than deadlocking the system. Signed-off-by: Nicolas Schichan <nschichan@freebox.fr> Acked-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2013-06-26perf: Disable monitoring on setuid processes for regular usersStephane Eranian1-7/+9
There was a a bug in setup_new_exec(), whereby the test to disabled perf monitoring was not correct because the new credentials for the process were not yet committed and therefore the get_dumpable() test was never firing. The patch fixes the problem by moving the perf_event test until after the credentials are committed. Signed-off-by: Stephane Eranian <eranian@google.com> Tested-by: Jiri Olsa <jolsa@redhat.com> Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: <stable@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-06-26gpio/omap: don't use linear domain mapping for OMAP1Javier Martinez Canillas1-1/+21
Commit ede4d7a5 ("gpio/omap: convert gpio irq domain to linear mapping") converted the OMAP GPIO driver to use a linear mapping for the GPIO IRQ domain instead of using a legacy mapping. Not using a legacy mapping has a number of benefits but it requires the platform to support SPARSE_IRQ which currently is not supported on OMAP1. So this change caused a regression on OMAP1 platforms [1]. Since this issue is not present on all OMAP2+ platforms, there is no need to revert the driver to use legacy domain mapping for all the platforms. [1]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg89005.html Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by: Tony Lindgren <tony@atomide.com>
2013-06-26net/tg3: Avoid delay during MMIO accessGavin Shan1-0/+36
When the EEH error is the result of a fenced host bridge, MMIO accesses can be very slow (milliseconds) to timeout and return all 1's, thus causing the driver various timeout loops to take way too long and trigger soft-lockup warnings (in addition to taking minutes to recover). It might be worthwhile to check if for any of these cases, ffffffff is a valid possible value, and if not, bail early since that means the HW is either gone or isolated. In the meantime, checking that the PCI channel is offline would be workaround of the problem. Cc: <stable@vger.kernel.org> # v3.0+ Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2013-06-26ipv6: check return value of ipv6_get_lladdrHannes Frederic Sowa1-5/+4
We should check the return value of ipv6_get_lladdr in inet6_set_iftoken. A possible situation, which could leave ll_addr unassigned is, when the user removed her link-local address but a global scoped address was already set. In this case the interface would still be IF_READY and not dead. In that case the RS source address is some value from the stack. v2: Daniel Borkmann noted a small indent inconstancy; no semantic changes. Cc: Daniel Borkmann <dborkman@redhat.com> Acked-by: Daniel Borkmann <dborkman@redhat.com> Reviewed-by: Flavio Leitner <fbl@redhat.com> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2013-06-26macvtap: fix recovery from gup errorsMichael S. Tsirkin1-2/+4
get user pages might fail partially in macvtap zero copy mode. To recover we need to put all pages that we got, but code used a wrong index resulting in double-free errors. Reported-by: Brad Hubbard <bhubbard@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2013-06-26tun: fix recovery from gup errorsMichael S. Tsirkin1-2/+4
get user pages might fail partially in tun zero copy mode. To recover we need to put all pages that we got, but code used a wrong index resulting in double-free errors. Reported-by: Brad Hubbard <bhubbard@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2013-06-26gre: fix a possible skb leakEric Dumazet3-9/+14
commit 68c331631143 ("v4 GRE: Add TCP segmentation offload for GRE") added a possible skb leak, because it frees only the head of segment list, in case a skb_linearize() call fails. This patch adds a kfree_skb_list() helper to fix the bug. Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Pravin B Shelar <pshelar@nicira.com> Cc: Daniel Borkmann <dborkman@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2013-06-25ipv6: Process unicast packet with Router Alert by checking flag in skb.YOSHIFUJI Hideaki / 吉藤英明1-3/+2
Router Alert option is marked in skb. Previously, IP6CB(skb)->ra was set to positive value for such packets. Since commit dd3332bf ("ipv6: Store Router Alert option in IP6CB directly."), IP6SKB_ROUTERALERT is set in IP6CB(skb)->flags, and the value of Router Alert option (in network byte order) is set to IP6CB(skb)->ra for such packets. Multicast forwarding path uses that flag and value, but unicast forwarding path does not use the flag and misuses IP6CB(skb)->ra value. Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2013-06-25cpufreq: fix NULL pointer deference at od_set_powersave_bias()Jacob Shin1-4/+13
When initializing the default powersave_bias value, we need to first make sure that this policy is running the ondemand governor. Reported-and-tested-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Jacob Shin <jacob.shin@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-06-25rbd: fetch object order before using itJosh Durgin1-4/+4
rbd_dev_v2_header_onetime() fetches striping information, and checks whether the image can be read by compariing the stripe unit to the object size. It determines the object size by shifting the object order, which is 0 at this point since it has not been read yet. Move the call to get the image size and object order before rbd_dev_v2_header_onetime() so it is set before use. Signed-off-by: Josh Durgin <josh.durgin@inktank.com> Reviewed-by: Sage Weil <sage@inktank.com>
2013-06-25fcoe: Use correct API to set vlan tag for FCoE Ethertype skbsRobert Love1-2/+5
fcoe_xmit was coded such that it would skip the vlan net device/layer and instead set some vlan flags and transmit on the real net device. The real net device has code that would add the vlan tag for fcoe skbs. This avoids some extra processing for data frames and provides a small performance improvement. Since fcoe_xmit was not using the vlan net device, __vlan_put_tag within the real net device's xmit routine was ultimately being called to set the vlan tag. With the below change the behavior of __vlan_put_tag changed slightly, it now sets the skb->protocol = vlan_proto. vlan_proto was not a field being set by fcoe_xmit, so the skb->protocol is now not being set to ETH_P_8021Q, as it should be. This patch converts fcoe_xmit to use the vlan_put_tag routine which will tag the skb and fcoe will continue to transmit fcoe skbs on the real net device. For reference, the below change was the one that altered the __vlan_put_tag behavior. commit 86a9bad3ab6b6f858fd4443b48738cabbb6d094c Author: Patrick McHardy <kaber@trash.net> Date: Fri Apr 19 02:04:30 2013 +0000 net: vlan: add protocol argument to packet tagging functions Add a protocol argument to the VLAN packet tagging functions. In case of HW tagging, we need that protocol available in the ndo_start_xmit functions, so it is stored in a new field in the skb. The new field fits into a hole (on 64 bit) and doesn't increase the sks's size. Signed-off-by: Robert Love <robert.w.love@intel.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Acked-by: John Fastabend <john.r.fastabend@intel.com>
2013-06-25crypto: algboss - Hold ref count on larvalHerbert Xu3-13/+14
On Thu, Jun 20, 2013 at 10:00:21AM +0200, Daniel Borkmann wrote: > After having fixed a NULL pointer dereference in SCTP 1abd165e ("net: > sctp: fix NULL pointer dereference in socket destruction"), I ran into > the following NULL pointer dereference in the crypto subsystem with > the same reproducer, easily hit each time: > > BUG: unable to handle kernel NULL pointer dereference at (null) > IP: [<ffffffff81070321>] __wake_up_common+0x31/0x90 > PGD 0 > Oops: 0000 [#1] SMP > Modules linked in: padlock_sha(F-) sha256_generic(F) sctp(F) libcrc32c(F) [..] > CPU: 6 PID: 3326 Comm: cryptomgr_probe Tainted: GF 3.10.0-rc5+ #1 > Hardware name: Dell Inc. PowerEdge T410/0H19HD, BIOS 1.6.3 02/01/2011 > task: ffff88007b6cf4e0 ti: ffff88007b7cc000 task.ti: ffff88007b7cc000 > RIP: 0010:[<ffffffff81070321>] [<ffffffff81070321>] __wake_up_common+0x31/0x90 > RSP: 0018:ffff88007b7cde08 EFLAGS: 00010082 > RAX: ffffffffffffffe8 RBX: ffff88003756c130 RCX: 0000000000000000 > RDX: 0000000000000000 RSI: 0000000000000003 RDI: ffff88003756c130 > RBP: ffff88007b7cde48 R08: 0000000000000000 R09: ffff88012b173200 > R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000282 > R13: ffff88003756c138 R14: 0000000000000000 R15: 0000000000000000 > FS: 0000000000000000(0000) GS:ffff88012fc60000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > CR2: 0000000000000000 CR3: 0000000001a0b000 CR4: 00000000000007e0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > Stack: > ffff88007b7cde28 0000000300000000 ffff88007b7cde28 ffff88003756c130 > 0000000000000282 ffff88003756c128 ffffffff81227670 0000000000000000 > ffff88007b7cde78 ffffffff810722b7 ffff88007cdcf000 ffffffff81a90540 > Call Trace: > [<ffffffff81227670>] ? crypto_alloc_pcomp+0x20/0x20 > [<ffffffff810722b7>] complete_all+0x47/0x60 > [<ffffffff81227708>] cryptomgr_probe+0x98/0xc0 > [<ffffffff81227670>] ? crypto_alloc_pcomp+0x20/0x20 > [<ffffffff8106760e>] kthread+0xce/0xe0 > [<ffffffff81067540>] ? kthread_freezable_should_stop+0x70/0x70 > [<ffffffff815450dc>] ret_from_fork+0x7c/0xb0 > [<ffffffff81067540>] ? kthread_freezable_should_stop+0x70/0x70 > Code: 41 56 41 55 41 54 53 48 83 ec 18 66 66 66 66 90 89 75 cc 89 55 c8 > 4c 8d 6f 08 48 8b 57 08 41 89 cf 4d 89 c6 48 8d 42 e > RIP [<ffffffff81070321>] __wake_up_common+0x31/0x90 > RSP <ffff88007b7cde08> > CR2: 0000000000000000 > ---[ end trace b495b19270a4d37e ]--- > > My assumption is that the following is happening: the minimal SCTP > tool runs under ``echo 1 > /proc/sys/net/sctp/auth_enable'', hence > it's making use of crypto_alloc_hash() via sctp_auth_init_hmacs(). > It forks itself, heavily allocates, binds, listens and waits in > accept on sctp sockets, and then randomly kills some of them (no > need for an actual client in this case to hit this). Then, again, > allocating, binding, etc, and then killing child processes. > > The problem that might be happening here is that cryptomgr requests > the module to probe/load through cryptomgr_schedule_probe(), but > before the thread handler cryptomgr_probe() returns, we return from > the wait_for_completion_interruptible() function and probably already > have cleared up larval, thus we run into a NULL pointer dereference > when in cryptomgr_probe() complete_all() is being called. > > If we wait with wait_for_completion() instead, this panic will not > occur anymore. This is valid, because in case a signal is pending, > cryptomgr_probe() returns from probing anyway with properly calling > complete_all(). The use of wait_for_completion_interruptible is intentional so that we don't lock up the thread if a bug causes us to never wake up. This bug is caused by the helper thread using the larval without holding a reference count on it. If the helper thread completes after the original thread requesting for help has gone away and destroyed the larval, then we get the crash above. So the fix is to hold a reference count on the larval. Cc: <stable@vger.kernel.org> # 3.6+ Reported-by: Daniel Borkmann <dborkman@redhat.com> Tested-by: Daniel Borkmann <dborkman@redhat.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2013-06-25drm/i915: make compact dma scatter lists creation work with SWIOTLB backend.Konrad Rzeszutek Wilk1-3/+12
Git commit 90797e6d1ec0dfde6ba62a48b9ee3803887d6ed4 ("drm/i915: create compact dma scatter lists for gem objects") makes certain assumptions about the under laying DMA API that are not always correct. On a ThinkPad X230 with an Intel HD 4000 with Xen during the bootup I see: [drm:intel_pipe_set_base] *ERROR* pin & fence failed [drm:intel_crtc_set_config] *ERROR* failed to set mode on [CRTC:3], err = -28 Bit of debugging traced it down to dma_map_sg failing (in i915_gem_gtt_prepare_object) as some of the SG entries were huge (3MB). That unfortunately are sizes that the SWIOTLB is incapable of handling - the maximum it can handle is a an entry of 512KB of virtual contiguous memory for its bounce buffer. (See IO_TLB_SEGSIZE). Previous to the above mention git commit the SG entries were of 4KB, and the code introduced by above git commit squashed the CPU contiguous PFNs in one big virtual address provided to DMA API. This patch is a simple semi-revert - were we emulate the old behavior if we detect that SWIOTLB is online. If it is not online then we continue on with the new compact scatter gather mechanism. An alternative solution would be for the the '.get_pages' and the i915_gem_gtt_prepare_object to retry with smaller max gap of the amount of PFNs that can be combined together - but with this issue discovered during rc7 that might be too risky. Reported-and-Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> CC: Chris Wilson <chris@chris-wilson.co.uk> CC: Imre Deak <imre.deak@intel.com> CC: Daniel Vetter <daniel.vetter@ffwll.ch> CC: David Airlie <airlied@linux.ie> CC: <dri-devel@lists.freedesktop.org> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-06-25libata-acpi: add back ACPI based hotplug functionalityAaron Lu3-1/+40
Commit 30dcf76acc69 "libata: migrate ACPI code over to new bindings" mistakenly dropped the code to register hotplug notificaion handler for ATA port/devices, causing regression for people using ATA bay, as kernel bug #59871 shows. Fix this by adding back the hotplug notification handler registration code. Since this code has to be run once and notification needs to be installed on every ATA port/devices handle no matter if there is actual device attached, we can't do this in binding time for ATA device ACPI handle, as the binding only occurs when a SCSI device is created, i.e. there is device attached. So introduce the ata_acpi_hotplug_init() function to loop scan all ATA ACPI handles and if it is available, install the notificaion handler for it during ATA init time. With the ATA ACPI handle binding to SCSI device tree, it is possible now that when the SCSI hotplug work removes the SCSI device, the ACPI unbind function will find that the corresponding ACPI device has already been deleted by dock driver, causing a scaring message like: [ 128.263966] scsi 4:0:0:0: Oops, 'acpi_handle' corrupt Fix this by waiting for SCSI hotplug task finish in our notificaion handler, so that the removal of ACPI device done in ACPI unbind function triggered by the removal of SCSI device is run earlier when ACPI device is still available. [rjw: Rebased] References: https://bugzilla.kernel.org/show_bug.cgi?id=59871 Reported-bisected-and-tested-by: Dirk Griesbach <spamthis@freenet.de> Signed-off-by: Aaron Lu <aaron.lu@intel.com> Acked-by: Tejun Heo <tj@kernel.org> Cc: 3.6+ <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-06-24powerpc/pci: Fix boot panic on mpc83xx (regression)Rojhalat Ibrahim1-15/+9
The following commit caused a fatal oops when booting on mpc83xx with a non-express PCI bus (regardless of whether a PCI device is present): commit 50d8f87d2b39313dae9d0a2d9b23d377328f2f7b Author: Rojhalat Ibrahim <imr@rtschenk.de> Date: Mon Apr 8 10:15:28 2013 +0200 powerpc/fsl-pci Make PCIe hotplug work with Freescale PCIe controllers Up to now the PCIe link status on Freescale PCIe controllers was only checked once at boot time. So hotplug did not work. With this patch the link status is checked on every config read. PCIe devices not present at boot time are found after doing 'echo 1 >/sys/bus/pci/rescan'. Signed-off-by: Rojhalat Ibrahim <imr@rtschenk.de> Signed-off-by: Kumar Gala <galak@kernel.crashing.org> This patch fixes the issue by calling setup_indirect_pci for all device types. fsl_indirect_read_config is now only used for booke/86xx PCIe controllers. Reported-by: Michael Guntsche <mike@it-loops.com> Cc: Scott Wood <scottwood@freescale.com> Signed-off-by: Rojhalat Ibrahim <imr@rtschenk.de> Signed-off-by: Scott Wood <scottwood@freescale.com>
2013-06-24ath9k_htc: Handle IDLE state transition properlySujith Manoharan1-1/+1
Make sure that a chip reset is done when IDLE is turned off - this fixes authentication timeouts. Cc: stable@vger.kernel.org Reported-by: Ignacy Gawedzki <i@lri.fr> Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-06-24ath9k: fix an RCU issue in calling ieee80211_get_tx_ratesFelix Fietkau1-1/+5
ath_txq_schedule is called outside of the drv_tx call, so it needs RCU protection. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-06-24netfilter: ipt_ULOG: fix incorrect setting of ulog timerGao feng1-4/+8
The parameter of setup_timer should be &ulog->nlgroup[i]. the incorrect parameter will cause kernel panic in ulog_timer. Bug introducted in commit 355430671ad93546b34b4e91bdf720f3a704efa4 "netfilter: ipt_ULOG: add net namespace support for ipt_ULOG" ebt_ULOG doesn't have this problem. [ I have mangled this patch to fix nlgroup != 0 case, we were also crashing there --pablo ] Tested-by: George Spelvin <linux@horizon.com> Reported-by: Borislav Petkov <bp@alien8.de> Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2013-06-24ARM: 7773/1: PJ4B: Add support for errata 4742Gregory CLEMENT4-3/+59
This commit fixes the regression on Armada 370 (the kernal hang during boot) introduced by the commit: "ARM: 7691/1: mm: kill unused TLB_CAN_READ_FROM_L1_CACHE and use ALT_SMP instead". When coming out of either a Wait for Interrupt (WFI) or a Wait for Event (WFE) IDLE states, a specific timing sensitivity exists between the retiring WFI/WFE instructions and the newly issued subsequent instructions. This sensitivity can result in a CPU hang scenario. The workaround is to insert either a Data Synchronization Barrier (DSB) or Data Memory Barrier (DMB) command immediately after the WFI/WFE instruction. This commit was based on the work of Lior Amsalem, but heavily modified to apply the errata fix dynamically according to the processor type thanks to the suggestions of Russell King and Nicolas Pitre. Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Reviewed-by: Will Deacon <will.deacon@arm.com> Acked-by: Nicolas Pitre <nico@linaro.org> Tested-by: Willy Tarreau <w@1wt.eu> Cc: <stable@vger.kernel.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2013-06-24ARM: 7772/1: Fix missing flush_kernel_dcache_page() for noMMUSimon Baatz1-0/+6
Commit 1bc3974 (ARM: 7755/1: handle user space mapped pages in flush_kernel_dcache_page) moved the implementation of flush_kernel_dcache_page() into mm/flush.c but did not implement it on noMMU ARM. Signed-off-by: Simon Baatz <gmbnomis@gmail.com> Acked-by: Kevin Hilman <khilman@linaro.org> Cc: <stable@vger.kernel.org> # 3.2+: 1bc3974: ARM: 7755/1 Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2013-06-24ARM: 7763/1: kernel: fix __cpu_logical_map default initializationLorenzo Pieralisi4-3/+5
The __cpu_logical_map array is statically initialized to 0, which is a valid MPIDR value. To prevent issues with the current implementation, this patch defines an MPIDR_INVALID value, and statically initializes the __cpu_logical_map[] array to it. Entries in the arm_dt_init_cpu_maps() tmp_map array used to stash DT reg properties while parsing DT are initialized with the MPIDR_INVALID value as well for consistency. Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Nicolas Pitre <nico@linaro.org> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2013-06-24ARM: 7762/1: kernel: fix arm_dt_init_cpu_maps() to skip non-cpu nodesLorenzo Pieralisi1-0/+3
The introduction of the cpu-map topology node in the cpus node implies that cpus node might have children that are not cpu nodes. The DT parsing code needs updating otherwise it would check for cpu nodes properties in nodes that are not required to contain them, resulting in warnings that have no bearing on bindings defined in the dts source file. Cc: <stable@vger.kernel.org> [3.8+] Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2013-06-24ARM: 7760/1: cpu_fa526_do_idle: remove WFIJonas Jensen1-1/+0
As it was already suggested by Russell King and Arnd Bergmann: https://lkml.org/lkml/2013/5/16/133 moxart and gemini seem to be the only platforms using CPU_FA526, and instead of pointing arm_pm_idle to an empty function from platform code, it makes sense to remove WFI code from the processor specific idle function. Applies to arm-soc/for-next (and 3.10-rc1). Changes since v1: 1. remove WFI but make sure cpu_fa526_do_idle do not fall through to cpu_fa526_dcache_clean_area Note: moxart boots and prints to UART without this patch, but input is broken. Signed-off-by: Jonas Jensen <jonas.jensen@gmail.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2013-06-24mfd: tps6586x: correct device name of the regulator cellMarc Dietrich2-2/+2
Change the device name of the regulator function to the one chosen for MODULE_ALIAS. This fixes kernel auto-module loading for the regulator function. Signed-off-by: Marc Dietrich <marvin24@gmx.de> Signed-off-by: Mark Brown <broonie@linaro.org>
2013-06-24netfilter: ctnetlink: send event when conntrack label was modifiedFlorian Westphal2-1/+2
commit 0ceabd83875b72a29f33db4ab703d6ba40ea4c58 (netfilter: ctnetlink: deliver labels to userspace) sets the event bit when we raced with another packet, instead of raising the event bit when the label bit is set for the first time. commit 9b21f6a90924dfe8e5e686c314ddb441fb06501e (netfilter: ctnetlink: allow userspace to modify labels) forgot to update the event mask in the "conntrack already exists" case. Both issues result in CTA_LABELS attribute not getting included in the conntrack event. Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2013-06-24netfilter: nf_nat_sip: fix manglingBalazs Peter Odor1-1/+2
In (b20ab9c netfilter: nf_ct_helper: better logging for dropped packets) there were some missing brackets around the logging information, thus always returning drop. Closes https://bugzilla.kernel.org/show_bug.cgi?id=60061 Signed-off-by: Balazs Peter Odor <balazs@obiserver.hu> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2013-06-24ACPI / dock / PCI: Synchronous handling of dock events for PCI devicesRafael J. Wysocki3-58/+133
The interactions between the ACPI dock driver and the ACPI-based PCI hotplug (acpiphp) are currently problematic because of ordering issues during hot-remove operations. First of all, the current ACPI glue code expects that physical devices will always be deleted before deleting the companion ACPI device objects. Otherwise, acpi_unbind_one() will fail with a warning message printed to the kernel log, for example: [ 185.026073] usb usb5: Oops, 'acpi_handle' corrupt [ 185.035150] pci 0000:1b:00.0: Oops, 'acpi_handle' corrupt [ 185.035515] pci 0000:18:02.0: Oops, 'acpi_handle' corrupt [ 180.013656] port1: Oops, 'acpi_handle' corrupt This means, in particular, that struct pci_dev objects have to be deleted before the struct acpi_device objects they are "glued" with. Now, the following happens the during the undocking of an ACPI-based dock station: 1) hotplug_dock_devices() invokes registered hotplug callbacks to destroy physical devices associated with the ACPI device objects depending on the dock station. It calls dd->ops->handler() for each of those device objects. 2) For PCI devices dd->ops->handler() points to handle_hotplug_event_func() that queues up a separate work item to execute _handle_hotplug_event_func() for the given device and returns immediately. That work item will be executed later. 3) hotplug_dock_devices() calls dock_remove_acpi_device() for each device depending on the dock station. This runs acpi_bus_trim() for each of them, which causes the underlying ACPI device object to be destroyed, but the work items queued up by handle_hotplug_event_func() haven't been started yet. 4) _handle_hotplug_event_func() queued up in step 2) are executed and cause the above failure to happen, because the PCI devices they handle do not have the companion ACPI device objects any more (those objects have been deleted in step 3). The possible breakage doesn't end here, though, because hotplug_dock_devices() may return before at least some of the _handle_hotplug_event_func() work items spawned by it have a chance to complete and then undock() will cause _DCK to be evaluated and that will cause the devices handled by the _handle_hotplug_event_func() to go away possibly while they are being accessed. This means that dd->ops->handler() for PCI devices should not point to handle_hotplug_event_func(). Instead, it should point to a function that will do the work of _handle_hotplug_event_func() synchronously. For this reason, introduce such a function, hotplug_event_func(), and modity acpiphp_dock_ops to point to it as the handler. Unfortunately, however, this is not sufficient, because if the dock code were not changed further, hotplug_event_func() would now deadlock with hotplug_dock_devices() that called it, since it would run unregister_hotplug_dock_device() which in turn would attempt to acquire the dock station's hp_lock mutex already acquired by hotplug_dock_devices(). To resolve that deadlock use the observation that unregister_hotplug_dock_device() won't need to acquire hp_lock if PCI bridges the devices on the dock station depend on are prevented from being removed prematurely while the first loop in hotplug_dock_devices() is in progress. To make that possible, introduce a mechanism by which the callers of register_hotplug_dock_device() can provide "init" and "release" routines that will be executed, respectively, during the addition and removal of the physical device object associated with the given ACPI device handle. Make acpiphp use two new functions, acpiphp_dock_init() and acpiphp_dock_release(), that call get_bridge() and put_bridge(), respectively, on the acpiphp bridge holding the given device, for this purpose. In addition to that, remove the dock station's list of "hotplug devices" and make the dock code always walk the whole list of "dependent devices" instead in such a way that the loops in hotplug_dock_devices() and dock_event() (replacing the loops over "hotplug devices") will take references to the list entries that register_hotplug_dock_device() has been called for. That prevents the "release" routines associated with those entries from being called while the given entry is being processed and for PCI devices this means that their bridges won't be removed (by a concurrent thread) while hotplug_event_func() handling them is being executed. This change is based on two earlier patches from Jiang Liu. References: https://bugzilla.kernel.org/show_bug.cgi?id=59501 Reported-and-tested-by: Alexander E. Patrakov <patrakov@gmail.com> Tracked-down-by: Jiang Liu <jiang.liu@huawei.com> Tested-by: Illya Klymov <xanf@xanf.me> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Yinghai Lu <yinghai@kernel.org> Cc: 3.9+ <stable@vger.kernel.org>
2013-06-24s390/ipl: Fix FCP WWPN and LUN format strings for readMichael Holzheu1-4/+4
The following git commit changed the behavior of sscanf: commit 53809751ac230a3611b5cdd375f3389f3207d471 Author: Jan Beulich <JBeulich@suse.com> Date: Mon Dec 17 16:01:31 2012 -0800 sscanf: don't ignore field widths for numeric conversions This broke the WWPN and LUN sysfs attributes for s390 reipl and dump on panic. Example: $ echo 0x0123456701234567 > /sys/firmware/reipl/fcp/wwpn $ cat /sys/firmware/reipl/fcp/wwpn 0x0001234567012345 So fix this and use format strings that work also with the new sscanf implementation: $ echo 0x012345670123456789 > /sys/firmware/reipl/fcp/wwpn $ cat /sys/firmware/reipl/fcp/wwpn 0x0123456701234567 Cc: stable@vger.kernel.org # 3.8+ Reviewed-by: Steffen Maier <maier@linux.vnet.ibm.com> Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2013-06-24qlcnic: Do not sleep while holding spinlockShahed Shaikh1-1/+1
This patch reverts commit a4791254b6625b06aa33e36304f6e8a1a4a1fdea ("qlcnic: change mdelay to msleep") which overwrote a commit 68b3f28c11bf896be32ad2a2e151aaa5f4a7c98e ("qlcnic: Fix scheduling while atomic bug") Signed-off-by: Shahed Shaikh <shahed.shaikh@qlogic.com> Signed-off-by: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2013-06-24drivers: net: cpsw: fix compilation error with cpsw driverMugunthan V N1-0/+1
drivers/net/ethernet/ti/cpsw.c: In function 'cpsw_suspend': drivers/net/ethernet/ti/cpsw.c:1979:26: error: 'priv' undeclared (first use in this function) drivers/net/ethernet/ti/cpsw.c:1979:26: note: each undeclared identifier is reported only once for each function it appears in make[4]: *** [drivers/net/ethernet/ti/cpsw.o] Error 1 The compilation error was introduced by the following commit 6d3d76f (drivers: net: cpsw: fix cpsw clock gating issue across suspend/resume) Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2013-06-24tcp: doc : fix the syncookies default valueShan Wei1-2/+2
syncookies is on for default since in commit e994b7c901 (tcp: Don't make syn cookies initial setting depend on CONFIG_SYSCTL). And fix a typo of CONFIG_SYN_COOKIES. Signed-off-by: Shan Wei <davidshan@tencent.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2013-06-24sh_eth: fix misreporting of transmit abortSergei Shtylyov1-2/+3
Due to obviously missing braces, EESR.TABT (transmit abort) interrupt may be reported even if it hasn't happened, just when EESR.TWB (transmit descriptor write-back) interrupt happens. Luckily (?), EESR.TWB is disabled by the driver via the TRIMD register and all the interrupt masks, so that transmit abort is never actually logged... Put the braces where they should be and fix the incoherent comment, while at it. Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2013-06-24sh_eth: fix unhandled RFE interruptSergei Shtylyov2-16/+19
EESR.RFE (receive FIFO overflow) interrupt is enabled by the driver on all SoCs and sh_eth_error() handles it but it's not present in any initializer/assignment of the 'eesr_err_check' field of 'struct sh_eth_cpu_data'. This leads to that interrupt not being handled and cleared, and finally to disabling IRQ and the driver being non-functional. Modify DEFAULT_EESR_ERR_CHECK macro and all explicit initializers of the above mentioned field to contain the EESR.RFE bit. Remove useless backslashes from the initializers, while at it. Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2013-06-24qmi_wwan: add various Novatel Gobi1K IDsDan Williams1-1/+7
Found in the Windows INF files while investigating the Novatel/Verizon USB-1000 device. The USB-1000 is verified as a Gobi1K device and works with QMI after loading appropriate firmware. Signed-off-by: Dan Williams <dcbw@redhat.com> Acked-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: David S. Miller <davem@davemloft.net>