- 24 May, 2013 3 commits
-
-
Gabriel de Perthuis authored
commit 03b71c6c upstream. The search ioctl skips items that are too large for a result buffer, but inline items of a certain size occuring before any search result is found would trigger an overflow and stop the search entirely. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=57641Signed-off-by:
Gabriel de Perthuis <g2p.code+btrfs@gmail.com> Signed-off-by:
Josef Bacik <jbacik@fusionio.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Sukanto Ghosh authored
commit b4fed079 upstream. The format of the lower 32-bits of the 64-bit operand to 'dc cisw' is unchanged from ARMv7 architecture and the upper bits are RES0. This implies that the 'way' field of the operand of 'dc cisw' occupies the bit-positions [31 .. (32-A)]. Due to the use of 64-bit extended operands to 'clz', the existing implementation of __flush_dcache_all is incorrectly placing the 'way' field in the bit-positions [63 .. (64-A)]. Signed-off-by:
Sukanto Ghosh <sghosh@apm.com> Tested-by:
Anup Patel <anup.patel@linaro.org> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
-
Will Deacon authored
commit 9c413e25 upstream. During boot, we take the debug OS lock before interrupts are enabled. This is required to prevent clearing of PSTATE.D on the interrupt entry path, which could result in spurious debug exceptions before we've got round to resetting things like the hardware breakpoints registers to a sane state. A problem with this approach is that taking the OS lock prevents an external JTAG debugger from debugging the system, which is especially irritating during boot, where JTAG debugging can be most useful. This patch clears mdscr_el1 rather than taking the lock, clearing the MDE and KDE bits and preventing self-hosted hardware debug exceptions from occurring. Tested-by:
Mark Rutland <mark.rutland@arm.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
- 19 May, 2013 37 commits
-
-
Greg Kroah-Hartman authored
-
Andy Grover authored
commit e3e84cda upstream. We can still see the error reported in https://patchwork.kernel.org/patch/2338981/ when using fileio backed by a block device. I'm assuming this will get us past that error (from sbc_parse_cdb), and also assuming it's OK to have our max_sectors be larger than the block's queue max hw sectors? Reported-by:
Eric Harney <eharney@redhat.com> Signed-off-by:
Andy Grover <agrover@redhat.com> Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
-
Eric W. Biederman authored
commit 780a7654 upstream. audit rule additions containing "-F auid!=4294967295" were failing with EINVAL because of a regression caused by e1760bd5. Apparently some userland audit rule sets want to know if loginuid uid has been set and are using a test for auid != 4294967295 to determine that. In practice that is a horrible way to ask if a value has been set, because it relies on subtle implementation details and will break every time the uid implementation in the kernel changes. So add a clean way to test if the audit loginuid has been set, and silently convert the old idiom to the cleaner and more comprehensible new idiom. RGB notes: In upstream, audit_rule_to_entry has been refactored out. This is patch is already upstream in functionally the same form in commit 780a7654 . The decimal constant was cast to unsigned to quiet GCC 4.6 32-bit architecture warnings. Reported-By:
Steve Grubb <sgrubb@redhat.com> Signed-off-by:
"Eric W. Biederman" <ebiederm@xmission.com> Tested-by:
Richard Guy Briggs <rgb@redhat.com> Signed-off-by:
Eric Paris <eparis@redhat.com> Backported-by:
-
Helge Deller authored
commit 6880b015 upstream. People/distros vary how they prefix the toolchain name for 64bit builds. Rather than enforce one convention over another, add a for loop which does a search for all the general prefixes. For 64bit builds, we now search for (in order): hppa64-unknown-linux-gnu hppa64-linux-gnu hppa64-linux For 32bit builds, we look for: hppa-unknown-linux-gnu hppa-linux-gnu hppa-linux hppa2.0-unknown-linux-gnu hppa2.0-linux-gnu hppa2.0-linux hppa1.1-unknown-linux-gnu hppa1.1-linux-gnu hppa1.1-linux This patch was initiated by Mike Frysinger, with feedback from Jeroen Roovers, John David Anglin and Helge Deller. Signed-off-by:
Mike Frysinger <vapier@gentoo.org> Signed-off-by:
Jeroen Roovers <jer@gentoo.org> Signed-off-by:
John David Anglin <dave.anglin@bell.net> Signed-off-by:
Helge Deller <deller@gmx.de> Signed-off-by:
-
Mike Frysinger authored
commit 93782eba upstream. The ifeq operator does not accept globs, so this little bit of code will never match (unless uname literally prints out "parsic*"). Rewrite to use a pattern matching operator so that NATIVE is set to 1 on parisc. Signed-off-by:
-
John David Anglin authored
commit bbbfde78 upstream. The "b" branch instruction used in the fork_like macro only can handle 17-bit pc-relative offsets. This fails with an out of range offset with some .config files. Rewrite to use the "be" instruction which can branch to any address in a space. Signed-off-by:
-
John David Anglin authored
commit f0a18819 upstream. Currently, race conditions exist in the handling of TLB interruptions in entry.S. In particular, dirty bit updates can be lost if an accessed interruption occurs just after the dirty bit interruption on a different cpu. Lost dirty bit updates result in user pages not being flushed and general system instability. This change adds lock and unlock macros to synchronize all PTE and TLB updates done in entry.S. As a result, userspace stability is significantly improved. Signed-off-by:
-
John David Anglin authored
parisc: only re-enable interrupts if we need to schedule or deliver signals when returning to userspace commit c207a76b upstream. Helge and I have found that we have a kernel stack overflow problem which causes a variety of random failures. Currently, we re-enable interrupts when returning from an external interrupt incase we need to schedule or delivery signals. As a result, a potentially unlimited number of interrupts can occur while we are running on the kernel stack. It is very limited in space (currently, 16k). This change defers enabling interrupts until we have actually decided to schedule or delivery signals. This only occurs when we about to return to userspace. This limits the number of interrupts on the kernel stack to one. In other cases, interrupts remain disabled until the final return from interrupt (rfi). Signed-off-by:
-
Oleg Nesterov authored
commit 264b83c0 upstream. argv_split(empty_or_all_spaces) happily succeeds, it simply returns argc == 0 and argv[0] == NULL. Change call_usermodehelper_exec() to check sub_info->path != NULL to avoid the crash. This is the minimal fix, todo: - perhaps we should change argv_split() to return NULL or change the callers. - kill or justify ->path[0] check - narrow the scope of helper_lock() Signed-off-by:
Oleg Nesterov <oleg@redhat.com> Acked-By:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Dave Airlie authored
commit e9ced8e0 upstream. When UMS was deprecated it removed support for nomodeset commandline we really want this in distro land so we can debug stuff, everyone should fallback to vesa correctly. v2: oops -1 isn't used anymore, restore original behaviour -1 is default, so we can boot with nomodeset on the command line, then use radeon.modeset=1 to override it for debugging later. Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Kees Cook authored
commit fefaedcf upstream. The "boxes" parameter points into userspace memory. It should be verified like any other operation against user memory. Signed-off-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
-
Axel Lin authored
commit 61559af1 upstream. When set dmic_samplephase and dmic_clk_rate bits for dmic_cfg, current code checks pdata->dmic_data_sel which is wrong. Signed-off-by:
Axel Lin <axel.lin@ingics.com> Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
-
Benjamin LaHaise authored
commit 6368087e upstream. When a 32 bit version of ipmitool is used on a 64 bit kernel, the ipmi_devintf code fails to correctly acquire ipmi_mutex. This results in incomplete data being retrieved in some cases, or other possible failures. Add a wrapper around compat_ipmi_ioctl() to take ipmi_mutex to fix this. Signed-off-by:
Benjamin LaHaise <bcrl@kvack.org> Signed-off-by:
Corey Minyard <cminyard@mvista.com> Signed-off-by:
-
Chen Gang authored
commit a5f2b3d6 upstream. When calling memcpy, read_data and write_data need additional 2 bytes. write_data: for checking: "if (size > IPMI_MAX_MSG_LENGTH)" for operating: "memcpy(bt->write_data + 3, data + 1, size - 1)" read_data: for checking: "if (msg_len < 3 || msg_len > IPMI_MAX_MSG_LENGTH)" for operating: "memcpy(data + 2, bt->read_data + 4, msg_len - 2)" Signed-off-by:
Chen Gang <gang.chen@asianux.com> Signed-off-by:
-
Lan Tianyu authored
commit 28fe5c82 upstream. The EC driver works abnormally with IBF flag always set. IBF means "The host has written a byte of data to the command or data port, but the embedded controller has not yet read it". If IBF is set in the EC status and not cleared, this will cause all subsequent EC requests to fail with a timeout error. Change the EC driver so that it doesn't refuse to restart a transaction if IBF is set in the status. Also increase the number of transaction restarts to 5, as it turns out that 2 is not sufficient in some cases. This bug happens on several different machines (Asus V1S, Dell Latitude E6530, Samsung R719, Acer Aspire 5930G, Sony Vaio SR19VN and others). [rjw: Changelog] References: https://bugzilla.kernel.org/show_bug.cgi?id=14733 References: https://bugzilla.kernel.org/show_bug.cgi?id=15560 References: https://bugzilla.kernel.org/show_bug.cgi?id=15946 References: https://bugzilla.kernel.org/show_bug.cgi?id=42945 References: https://bugzilla.kernel.org/show_bug.cgi?id=48221Signed-off-by:
Lan Tianyu <tianyu.lan@intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Nicholas Bellinger authored
commit d2bdbee0 upstream. This patch fixes a regression bug introduced in v3.9-rc1 where if the underlying struct block_device for a IBLOCK backend is configured with WCE=1 + DPOFUA=1 settings, the rw = WRITE assignment no longer occurs in iblock_execute_rw(), and rw = 0 is passed to iblock_submit_bios() in effect causing a READ bio operation to occur. The offending commit is: commit d0c8b259 Author: Nicholas Bellinger <nab@linux-iscsi.org> Date: Tue Jan 29 22:10:06 2013 -0800 target/iblock: Use backend REQ_FLUSH hint for WriteCacheEnabled status Note the WCE=1 + DPOFUA=0, WCE=0 + DPOFUA=1, and WCE=0 + DPOFUA=0 cases are not affected by this regression bug. Reported-by:
Chris Boot <bootc@bootc.net> Tested-by:
Hannes Reinecke <hare@suse.de> Signed-off-by:
-
Joern Engel authored
commit ccf5ae83 upstream. It is possible for one thread to to take se_sess->sess_cmd_lock in core_tmr_abort_task() before taking a reference count on se_cmd->cmd_kref, while another thread in target_put_sess_cmd() drops se_cmd->cmd_kref before taking se_sess->sess_cmd_lock. This introduces kref_put_spinlock_irqsave() and uses it in target_put_sess_cmd() to close the race window. Signed-off-by:
Joern Engel <joern@logfs.org> Acked-by:
-
Shlomo Pongratz authored
commit 3eccfdb0 upstream. Fix two issues in OOO commands processing done at iscsit_attach_ooo_cmdsn. Handle command serial numbers wrap around by using iscsi_sna_lt and not regular comparisson. The routine iterates until it finds an entry whose serial number is greater than the serial number of the new one, thus the new entry should be inserted before that entry and not after. Signed-off-by:
Shlomo Pongratz <shlomop@mellanox.com> Signed-off-by:
-
Dirk Brandewie authored
commit ca182aee upstream. The ffmpeg benchmark in the phoronix test suite has threads on multiple cores that rely on the progress on of threads on other cores and ping pong back and forth fast enough to make the core appear less busy than it "should" be. If the core has been at minimum p-state for a while bump the pstate up to kick the core to see if it is in this ping pong state. If the core is truly idle the p-state will be reduced at the next sample time. If the core makes more progress it will send more work to the thread bringing both threads out of the ping pong scenario and the p-state will be selected normally. This fixes a performance regression of approximately 30% Signed-off-by:
Dirk Brandewie <dirk.j.brandewie@intel.com> Signed-off-by:
-
Dirk Brandewie authored
commit d8f469e9 upstream. There are two ways that the maximum p-state can be clamped, via a policy change and via the sysfs file. The acpi-thermal driver adjusts the p-state policy in response to thermal events. These changes override the users settings at the moment. Use the lowest of the two requested values this ensures that we will not exceed the requested pstate from either mechanism. Reported-by:
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by:
-
Dirk Brandewie authored
commit 1abc4b20 upstream. Idle time is taken into account in the APERF/MPERF ratio calculation there is no reason for the driver to track it seperately. This reduces the work in the driver and makes the code more readable. Removal of the tracking of sample duration removes the possibility of the divide by zero exception when the duration is sub 1us References: https://bugzilla.kernel.org/show_bug.cgi?id=56691Reported-by:
Mike Lothian <mike@fireburn.co.uk> Signed-off-by:
-
Wei Yongjun authored
commit 35623715 upstream. Fix to return -ENODEV in the chip not found error handling case instead of 0, as done elsewhere in this function. Signed-off-by:
Wei Yongjun <yongjun_wei@trendmicro.com.cn> Cc: Jingoo Han <jg1.han@samsung.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Jonghwan Choi <jhbird.choi@samsung.com> Signed-off-by:
-
Inderpal Singh authored
commit 08858461 upstream. The kernel crashes while resuming from AFTR idle mode. It happens because L2 cache was not going into retention state. This patch configures the USE_RETENTION bit of ARM_L2_OPTION register so that it does not depend on MANUAL_L2RSTDISABLE_CONTROL of ARM_COMMON_OPTION register for L2RSTDISABLE signal. Signed-off-by:
Inderpal Singh <inderpal.singh@linaro.org> Tested-by:
Chander Kashyap <chander.kashyap@linaro.org> Signed-off-by:
Olof Johansson <olof@lixom.net> Signed-off-by:
-
Geert Uytterhoeven authored
commit 22ee3b57 upstream. If gcc (e.g. 4.1.2) decides not to inline vsock_init_tables(), this will cause a section mismatch: WARNING: net/vmw_vsock/vsock.o(.text+0x1bc): Section mismatch in reference from the function __vsock_core_init() to the function .init.text:vsock_init_tables() The function __vsock_core_init() references the function __init vsock_init_tables(). This is often because __vsock_core_init lacks a __init annotation or the annotation of vsock_init_tables is wrong. This may cause crashes if VSOCKETS=y and VMWARE_VMCI_VSOCKETS=m. Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Philipp Reisner authored
commit 7c689e63 upstream. With an automatic after split-brain recovery policy of "after-sb-1pri call-pri-lost-after-sb", when trying to drbd_set_role() to R_SECONDARY, we run into a deadlock. This was first recognized and supposedly fixed by 2009-06-10 "Fixed a deadlock when using automatic split brain recovery when both nodes are" replacing drbd_set_role() with drbd_change_state() in that code-path, but the first hunk of that patch forgets to remove the drbd_set_role(). We apparently only ever tested the "two primaries" case. Signed-off-by:
Philipp Reisner <philipp.reisner@linbit.com> Signed-off-by:
Lars Ellenberg <lars.ellenberg@linbit.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Lars Ellenberg authored
commit 94ad0a10 upstream. We forgot to free the disk_conf, so for each attach/detach cycle we leaked 336 bytes. Signed-off-by:
-
Philipp Reisner authored
commit ef57f9e6 upstream. Signed-off-by:
-
Guenter Roeck authored
commit 60403f7a upstream. A race condition exists when registering the first watchdog device. Sequence of events: - watchdog_register_device calls watchdog_dev_register - watchdog_dev_register creates the watchdog misc device by calling misc_register. At that time, the matching character device (/dev/watchdog0) does not yet exist, and old_wdd is not set either. - Userspace gets an event and opens /dev/watchdog - watchdog_open is called and sets wdd = old_wdd, which is still NULL, and tries to dereference it. This causes the kernel to panic. Seen with systemd trying to open /dev/watchdog immediately after it was created. Reported-by:
Arkadiusz Miskiewicz <arekm@maven.pl> Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Tested-by:
Wim Van Sebroeck <wim@iguana.be> Signed-off-by:
-
Tomoya MORINAGA authored
commit 5c1ef591 upstream. pdc_desc_get() is called from pd_prep_slave_sg, and the function is called from interrupt context(e.g. Uart driver "pch_uart.c"). In fact, I saw kernel error message. So, GFP_ATOMIC must be used not GFP_NOIO. Signed-off-by:
Tomoya MORINAGA <tomoya.rohm@gmail.com> Signed-off-by:
Vinod Koul <vinod.koul@intel.com> Signed-off-by:
-
Cong Wang authored
[ Upstream commit 84c4a9df ] We forget to call dev_put() on error path in xfrm6_fill_dst(), its caller doesn't handle this. Signed-off-by:
Cong Wang <amwang@redhat.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Steffen Klassert <steffen.klassert@secunet.com> Cc: David S. Miller <davem@davemloft.net> Signed-off-by:
-
Amerigo Wang authored
[ Upstream commit 5dbd5068 ] There is a hole in struct ip6_tnl_parm2, so we have to zero the struct on stack before copying it to user-space. Cc: David S. Miller <davem@davemloft.net> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit f77d6021 ] We have seen multiple NULL dereferences in __inet6_lookup_established() After analysis, I found that inet6_sk() could be NULL while the check for sk_family == AF_INET6 was true. Bug was added in linux-2.6.29 when RCU lookups were introduced in UDP and TCP stacks. Once an IPv6 socket, using SLAB_DESTROY_BY_RCU is inserted in a hash table, we no longer can clear pinet6 field. This patch extends logic used in commit fcbdf09d ("net: fix nulls list corruptions in sk_prot_alloc") TCP/UDP/UDPLite IPv6 protocols provide their own .clear_sk() method to make sure we do not clear pinet6 field. At socket clone phase, we do not really care, as cloning the parent (non NULL) pinet6 is not adding a fatal race. Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Jiri Pirko authored
[ Upstream commit 233c7df0 ] Currently, if macvlan in passthru mode is created and data are rxed and you remove this device, following panic happens: NULL pointer dereference at 0000000000000198 IP: [<ffffffffa0196058>] macvlan_handle_frame+0x153/0x1f7 [macvlan] I'm using following script to trigger this: <script> while [ 1 ] do ip link add link e1 name macvtap0 type macvtap mode passthru ip link set e1 up ip link set macvtap0 up IFINDEX=`ip link |grep macvtap0 | cut -f 1 -d ':'` cat /dev/tap$IFINDEX >/dev/null & ip link del dev macvtap0 done </script> I run this script while "ping -f" is running on another machine to send packets to e1 rx. Reason of the panic is that list_first_entry() is blindly called in macvlan_handle_frame() even if the list was empty. vlan is set to incorrect pointer which leads to the crash. I'm fixing this by protecting port->vlans list by rcu and by preventing from getting incorrect pointer in case the list is empty. Introduced by: commit eb06acdc "macvlan: Introduce 'passthru' mode to takeover the underlying device" Signed-off-by:
Jiri Pirko <jiri@resnulli.us> Acked-by:
-
Josh Boyer authored
[ Upstream commit 4f924b2a ] Protect the SIOCGCM* ioctl macros with parenthesis. Reported-by:
Paul Wouters <pwouters@redhat.com> Signed-off-by:
Josh Boyer <jwboyer@redhat.com> Signed-off-by:
-
Sergei Shtylyov authored
[ Upstream commit 4b264a16 ] The driver wrongly claimed I/O ports at an address returned by pci_iomap() -- even if it was passed an MMIO address. Fix this by claiming/releasing all PCI resources in the PCI driver's probe()/remove() methods instead and get rid of 'must_free_region' flag weirdness (why would Cardbus claim anything for us?). Signed-off-by:
Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by:
-
Sergei Shtylyov authored
[ Upstream commit c81400be ] When unloading the driver that drives an EISA board, a message similar to the following one is displayed: Trying to free nonexistent resource <0000000000013000-000000000001301f> Then an user is unable to reload the driver because the resource it requested in the previous load hasn't been freed. This happens most probably due to a typo in vortex_eisa_remove() which calls release_region() with 'dev->base_addr' instead of 'edev->base_addr'... Reported-by:
Matthew Whitehead <tedheadster@gmail.com> Tested-by:
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by:
-
Konstantin Khlebnikov authored
[ Upstream commit b56141ab ] This patch fixes race between inet_frag_lru_move() and inet_frag_lru_add() which was introduced in commit 3ef0eb0d ("net: frag, move LRU list maintenance outside of rwlock") One cpu already added new fragment queue into hash but not into LRU. Other cpu found it in hash and tries to move it to the end of LRU. This leads to NULL pointer dereference inside of list_move_tail(). Another possible race condition is between inet_frag_lru_move() and inet_frag_lru_del(): move can happens after deletion. This patch initializes LRU list head before adding fragment into hash and inet_frag_lru_move() doesn't touches it if it's empty. I saw this kernel oops two times in a couple of days. [119482.128853] BUG: unable to handle kernel NULL pointer dereference at (null) [119482.132693] IP: [<ffffffff812ede89>] __list_del_entry+0x29/0xd0 [119482.136456] PGD 2148f6067 PUD 215ab9067 PMD 0 [119482.140221] Oops: 0000 [#1] SMP [119482.144008] Modules linked in: vfat msdos fat 8021q fuse nfsd auth_rpcgss nfs_acl nfs lockd sunrpc ppp_async ppp_generic bridge slhc stp llc w83627ehf hwmon_vid snd_hda_codec_hdmi snd_hda_codec_realtek kvm_amd k10temp kvm snd_hda_intel snd_hda_codec edac_core radeon snd_hwdep ath9k snd_pcm ath9k_common snd_page_alloc ath9k_hw snd_timer snd soundcore drm_kms_helper ath ttm r8169 mii [119482.152692] CPU 3 [119482.152721] Pid: 20, comm: ksoftirqd/3 Not tainted 3.9.0-zurg-00001-g9f95269 #132 To Be Filled By O.E.M. To Be Filled By O.E.M./RS880D [119482.161478] RIP: 0010:[<ffffffff812ede89>] [<ffffffff812ede89>] __list_del_entry+0x29/0xd0 [119482.166004] RSP: 0018:ffff880216d5db58 EFLAGS: 00010207 [119482.170568] RAX: 0000000000000000 RBX: ffff88020882b9c0 RCX: dead000000200200 [119482.175189] RDX: 0000000000000000 RSI: 0000000000000880 RDI: ffff88020882ba00 [119482.179860] RBP: ffff880216d5db58 R08: ffffffff8155c7f0 R09: 0000000000000014 [119482.184570] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88020882ba00 [119482.189337] R13: ffffffff81c8d780 R14: ffff880204357f00 R15: 00000000000005a0 [119482.194140] FS: 00007f58124dc700(0000) GS:ffff88021fcc0000(0000) knlGS:0000000000000000 [119482.198928] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [119482.203711] CR2: 0000000000000000 CR3: 00000002155f0000 CR4: 00000000000007e0 [119482.208533] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [119482.213371] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [119482.218221] Process ksoftirqd/3 (pid: 20, threadinfo ffff880216d5c000, task ffff880216d3a9a0) [119482.223113] Stack: [119482.228004] ffff880216d5dbd8 ffffffff8155dcda 0000000000000000 ffff000200000001 [119482.233038] ffff8802153c1f00 ffff880000289440 ffff880200000014 ffff88007bc72000 [119482.238083] 00000000000079d5 ffff88007bc72f44 ffffffff00000002 ffff880204357f00 [119482.243090] Call Trace: [119482.248009] [<ffffffff8155dcda>] ip_defrag+0x8fa/0xd10 [119482.252921] [<ffffffff815a8013>] ipv4_conntrack_defrag+0x83/0xe0 [119482.257803] [<ffffffff8154485b>] nf_iterate+0x8b/0xa0 [119482.262658] [<ffffffff8155c7f0>] ? inet_del_offload+0x40/0x40 [119482.267527] [<ffffffff815448e4>] nf_hook_slow+0x74/0x130 [119482.272412] [<ffffffff8155c7f0>] ? inet_del_offload+0x40/0x40 [119482.277302] [<ffffffff8155d068>] ip_rcv+0x268/0x320 [119482.282147] [<ffffffff81519992>] __netif_receive_skb_core+0x612/0x7e0 [119482.286998] [<ffffffff81519b78>] __netif_receive_skb+0x18/0x60 [119482.291826] [<ffffffff8151a650>] process_backlog+0xa0/0x160 [119482.296648] [<ffffffff81519f29>] net_rx_action+0x139/0x220 [119482.301403] [<ffffffff81053707>] __do_softirq+0xe7/0x220 [119482.306103] [<ffffffff81053868>] run_ksoftirqd+0x28/0x40 [119482.310809] [<ffffffff81074f5f>] smpboot_thread_fn+0xff/0x1a0 [119482.315515] [<ffffffff81074e60>] ? lg_local_lock_cpu+0x40/0x40 [119482.320219] [<ffffffff8106d870>] kthread+0xc0/0xd0 [119482.324858] [<ffffffff8106d7b0>] ? insert_kthread_work+0x40/0x40 [119482.329460] [<ffffffff816c32dc>] ret_from_fork+0x7c/0xb0 [119482.334057] [<ffffffff8106d7b0>] ? insert_kthread_work+0x40/0x40 [119482.338661] Code: 00 00 55 48 8b 17 48 b9 00 01 10 00 00 00 ad de 48 8b 47 08 48 89 e5 48 39 ca 74 29 48 b9 00 02 20 00 00 00 ad de 48 39 c8 74 7a <4c> 8b 00 4c 39 c7 75 53 4c 8b 42 08 4c 39 c7 75 2b 48 89 42 08 [119482.343787] RIP [<ffffffff812ede89>] __list_del_entry+0x29/0xd0 [119482.348675] RSP <ffff880216d5db58> [119482.353493] CR2: 0000000000000000 Oops happened on this path: ip_defrag() -> ip_frag_queue() -> inet_frag_lru_move() -> list_move_tail() -> __list_del_entry() Signed-off-by:
Konstantin Khlebnikov <khlebnikov@openvz.org> Cc: Jesper Dangaard Brouer <brouer@redhat.com> Cc: Florian Westphal <fw@strlen.de> Cc: Eric Dumazet <edumazet@google.com> Cc: David S. Miller <davem@davemloft.net> Acked-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
Jesper Dangaard Brouer <brouer@redhat.com> Signed-off-by:
-
