- 13 Jul, 2015 6 commits
-
-
Hans de Goede authored
commit 5f0ee9d1 upstream. Make the check to skip the rate check more lax, so that it applies to all hw_version 4 models. This fixes the touchpad not being detected properly on Asus PU551LA laptops. Reported-and-tested-by: David Zafra Gómez <dezeta@klo.es> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Kamal Mostafa <kamal@canonical.com>
-
Jan Kara authored
commit f18c34e4 upstream. If the specified maximum length of the string is a multiple of unsigned long, we would load one long behind the specified maximum. If that happens to be in a next page, we can hit a page fault although we were not expected to. Fix the off-by-one bug in the test whether we are at the end of the specified range. Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Kamal Mostafa <kamal@canonical.com>
-
Andy Lutomirski authored
commit 425be567 upstream. The early_idt_handlers asm code generates an array of entry points spaced nine bytes apart. It's not really clear from that code or from the places that reference it what's going on, and the code only works in the first place because GAS never generates two-byte JMP instructions when jumping to global labels. Clean up the code to generate the correct array stride (member size) explicitly. This should be considerably more robust against screw-ups, as GAS will warn if a .fill directive has a negative count. Using '. =' to advance would have been even more robust (it would generate an actual error if it tried to move backwards), but it would pad with nulls, confusing anyone who tries to disassemble the code. The new scheme should be much clearer to future readers. While we're at it, improve the comments and rename the array and common code. Binutils may start relaxing jumps to non-weak labels. If so, this change will fix our build, and we may need to backport this change. Before, on x86_64: 0000000000000000 <early_idt_handlers>: 0: 6a 00 pushq $0x0 2: 6a 00 pushq $0x0 4: e9 00 00 00 00 jmpq 9 <early_idt_handlers+0x9> 5: R_X86_64_PC32 early_idt_handler-0x4 ... 48: 66 90 xchg %ax,%ax 4a: 6a 08 pushq $0x8 4c: e9 00 00 00 00 jmpq 51 <early_idt_handlers+0x51> 4d: R_X86_64_PC32 early_idt_handler-0x4 ... 117: 6a 00 pushq $0x0 119: 6a 1f pushq $0x1f 11b: e9 00 00 00 00 jmpq 120 <early_idt_handler> 11c: R_X86_64_PC32 early_idt_handler-0x4 After: 0000000000000000 <early_idt_handler_array>: 0: 6a 00 pushq $0x0 2: 6a 00 pushq $0x0 4: e9 14 01 00 00 jmpq 11d <early_idt_handler_common> ... 48: 6a 08 pushq $0x8 4a: e9 d1 00 00 00 jmpq 120 <early_idt_handler_common> 4f: cc int3 50: cc int3 ... 117: 6a 00 pushq $0x0 119: 6a 1f pushq $0x1f 11b: eb 03 jmp 120 <early_idt_handler_common> 11d: cc int3 11e: cc int3 11f: cc int3 Signed-off-by: Andy Lutomirski <luto@kernel.org> Acked-by: H. Peter Anvin <hpa@linux.intel.com> Cc: Binutils <binutils@sourceware.org> Cc: Borislav Petkov <bp@alien8.de> Cc: H.J. Lu <hjl.tools@gmail.com> Cc: Jan Beulich <JBeulich@suse.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/ac027962af343b0c599cbfcf50b945ad2ef3d7a8.1432336324.git.luto@kernel.orgSigned-off-by: Ingo Molnar <mingo@kernel.org> [ luis: backported to 3.16: adjusted context ] Signed-off-by: Luis Henriques <luis.henriques@canonical.com> Signed-off-by: Kamal Mostafa <kamal@canonical.com>
-
Jim Bride authored
commit e058c945 upstream. According to the HSW b-spec we need to try clock divisors of 63 and 72, each 3 or more times, when attempting DP AUX channel communication on a server chipset. This actually wasn't happening due to a short-circuit that only checked the DP_AUX_CH_CTL_DONE bit in status rather than checking that the operation was done and that DP_AUX_CH_CTL_TIME_OUT_ERROR was not set. [v2] Implemented alternate solution suggested by Jani Nikula. Signed-off-by: Jim Bride <jim.bride@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Kamal Mostafa <kamal@canonical.com>
-
Laura Abbott authored
commit 72586c60 upstream. Commit 32f13521 ("n_tty: Line copy to user buffer in canonical mode") changed cannonical mode copying to use copy_to_user but missed adding the call to the audit framework. Add in the appropriate functions to get audit support. Fixes: 32f13521 ("n_tty: Line copy to user buffer in canonical mode") Reported-by: Miloslav Trmač <mitr@redhat.com> Signed-off-by: Laura Abbott <labbott@fedoraproject.org> Reviewed-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [ luis: backported to 3.16: adjusted context ] Signed-off-by: Luis Henriques <luis.henriques@canonical.com> Signed-off-by: Kamal Mostafa <kamal@canonical.com>
-
Wolfram Sang authored
commit 1ef9f058 upstream. Fix this from the logs: usb 7-1: New USB device found, idVendor=046d, idProduct=08ca ... usb 7-1: Warning! Unlikely big volume range (=3072), cval->res is probably wrong. usb 7-1: [5] FU [Mic Capture Volume] ch = 1, val = 4608/7680/1 Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Kamal Mostafa <kamal@canonical.com>
-
- 07 Jul, 2015 19 commits
-
-
Philipp Zabel authored
commit 392bceed upstream. The driver configures the IDLE condition to interrupt the SDMA engine. Since the SDMA UART ROM script doesn't clear the IDLE bit itself, this caused repeated 1-byte DMA transfers, regardless of available data in the RX FIFO. Also, when returning due to the IDLE condition, the UART ROM script already increased its counter, causing residue to be off by one. This patch clears the IDLE condition to avoid repeated 1-byte DMA transfers and decreases count by when the DMA transfer was aborted due to the IDLE condition, fixing serial transfers using DMA on i.MX6Q. Reported-by: Peter Seiderer <ps.report@gmx.net> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Kamal Mostafa <kamal@canonical.com>
-
Axel Lin authored
commit e5d73218 upstream. Remove extra space between platform prefix and DRIVER_NAME in MODULE_ALIAS. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Kamal Mostafa <kamal@canonical.com>
-
Patrick Riphagen authored
commit 1df5b888 upstream. This adds support for new Xsens device, Motion Tracker Development Board, using Xsens' own Vendor ID Signed-off-by: Patrick Riphagen <patrick.riphagen@xsens.com> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Kamal Mostafa <kamal@canonical.com>
-
Paul Cercueil authored
commit 9df56035 upstream. There are a few issues with the burst mode support. For one we don't setup the rx buffer, so the buffer will never be filled and all samples will read as the zero. Furthermore the tx buffer has the wrong type, which means the driver sends the wrong command and not the right data is returned. The final issue is that in burst mode all channels are transferred. Hence the length of the transfer length should be the number of hardware channels * 2 bytes. Currently the driver uses indio_dev->scan_bytes for this. But if the timestamp channel is enabled the scan_bytes will be larger than the burst length. Fix this by just calculating the burst length based on the number of hardware channels. Signed-off-by: Paul Cercueil <paul.cercueil@analog.com> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Fixes: 5eda3550 ("staging:iio:adis16400: Preallocate transfer message") Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Kamal Mostafa <kamal@canonical.com>
-
Sachin Kamat authored
commit a9fbbbd7 upstream. 'rx' is not used in this function. Remove it. Signed-off-by: Sachin Kamat <sachin.kamat@samsung.com> Acked-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org> [ kamal: 3.13-stable prereq for 9df56035 iio: adis16400: Fix burst mode ] Signed-off-by: Kamal Mostafa <kamal@canonical.com>
-
Paul Cercueil authored
commit c2a8b623 upstream. We unfortunately can't use ~0UL for the scan mask to indicate that the only valid scan mask is all channels selected. The IIO core needs the exact mask to work correctly and not a super-set of it. So calculate the masked based on the channels that are available for a particular device. Signed-off-by: Paul Cercueil <paul.cercueil@analog.com> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Fixes: 5eda3550 ("staging:iio:adis16400: Preallocate transfer message") Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Kamal Mostafa <kamal@canonical.com>
-
Paul Cercueil authored
commit 7323d598 upstream. Previously, the two voltage channels had the same ID, which didn't cause conflicts in sysfs only because one channel is named and the other isn't; this is still violating the spec though, two indexed channels should never have the same index. Signed-off-by: Paul Cercueil <paul.cercueil@analog.com> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Kamal Mostafa <kamal@canonical.com>
-
Lars-Peter Clausen authored
commit 69ca2d77 upstream. Add the scale for the pressure channel, which is currently missing. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Fixes: 76ada52f ("iio:adis16400: Add support for the adis16448") Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Kamal Mostafa <kamal@canonical.com>
-
Andrew Morton authored
commit 2b1d3ae9 upstream. load_elf_binary() returns `retval', not `error'. Fixes: a87938b2 ("fs/binfmt_elf.c: fix bug in loading of PIE binaries") Reported-by: James Hogan <james.hogan@imgtec.com> Cc: Michael Davidson <md@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Kamal Mostafa <kamal@canonical.com>
-
Andy Grover authored
commit 5a7125c6 upstream. See https://bugzilla.redhat.com/show_bug.cgi?id=1025672 We need to put() the reference to the scsi host that we got in pscsi_configure_device(). In VIRTUAL_HOST mode it is associated with the dev_virt, not the hba_virt. Signed-off-by: Andy Grover <agrover@redhat.com> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Kamal Mostafa <kamal@canonical.com>
-
Guenter Roeck authored
commit 1b63bf61 upstream. The following error message is seen when loading the nct6775 driver with DEBUG_LOCK_ALLOC enabled. BUG: key ffff88040b2f0030 not in .data! ------------[ cut here ]------------ WARNING: CPU: 0 PID: 186 at kernel/locking/lockdep.c:2988 lockdep_init_map+0x469/0x630() DEBUG_LOCKS_WARN_ON(1) Caused by a missing call to sysfs_attr_init() when initializing sysfs attributes. Reported-by: Alexey Orishko <alexey.orishko@gmail.com> Reviewed-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Kamal Mostafa <kamal@canonical.com>
-
Al Viro authored
commit 2159184e upstream. when we find that a child has died while we'd been trying to ascend, we should go into the first live sibling itself, rather than its sibling. Off-by-one in question had been introduced in "deal with deadlock in d_walk()" and the fix needs to be backported to all branches this one has been backported to. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Kamal Mostafa <kamal@canonical.com>
-
Sasha Levin authored
commit dcbff39d upstream. match_token() expects a NULL terminator at the end of the token list so that it would know where to stop. Not having one causes it to overrun to invalid memory. In practice, passing a mount option that omfs didn't recognize would sometimes panic the system. Signed-off-by: Sasha Levin <sasha.levin@oracle.com> Signed-off-by: Bob Copeland <me@bobcopeland.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Kamal Mostafa <kamal@canonical.com>
-
Rusty Russell authored
commit 83a35114 upstream. This bug has been there since day 1; addresses in the top guest physical page weren't considered valid. You could map that page (the check in check_gpte() is correct), but if a guest tried to put a pagetable there we'd check that address manually when walking it, and kill the guest. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Kamal Mostafa <kamal@canonical.com>
-
Chris Lesiak authored
commit adba6575 upstream. When configured via device tree, the associated iio device needs to be measuring voltage for the conversion to resistance to be correct. Return -EINVAL if that is not the case. Signed-off-by: Chris Lesiak <chris.lesiak@licor.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Kamal Mostafa <kamal@canonical.com>
-
Borislav Petkov authored
commit 17fea54b upstream. Derek noticed that a critical MCE gets reported with the wrong error type description: [Hardware Error]: CPU 34: Machine Check Exception: 5 Bank 9: f200003f000100b0 [Hardware Error]: RIP !INEXACT! 10:<ffffffff812e14c1> {intel_idle+0xb1/0x170} [Hardware Error]: TSC 49587b8e321cb [Hardware Error]: PROCESSOR 0:306e4 TIME 1431561296 SOCKET 1 APIC 29 [Hardware Error]: Some CPUs didn't answer in synchronization [Hardware Error]: Machine check: Invalid ^^^^^^^ The last line with 'Invalid' should have printed the high level MCE error type description we get from mce_severity, i.e. something like: [Hardware Error]: Machine check: Action required: data load error in a user process this happens due to the fact that mce_no_way_out() iterates over all MCA banks and possibly overwrites the @msg argument which is used in the panic printing later. Change behavior to take the message of only and the (last) critical MCE it detects. Reported-by: Derek <denc716@gmail.com> Signed-off-by: Borislav Petkov <bp@suse.de> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tony Luck <tony.luck@intel.com> Link: http://lkml.kernel.org/r/1431936437-25286-3-git-send-email-bp@alien8.deSigned-off-by: Ingo Molnar <mingo@kernel.org> [ kamal: backport to 3.13-stable: context ] Signed-off-by: Kamal Mostafa <kamal@canonical.com>
-
Mark Rutland authored
commit 965278dc upstream. At boot time we round the memblock limit down to section size in an attempt to ensure that we will have mapped this RAM with section mappings prior to allocating from it. When mapping RAM we iterate over PMD-sized chunks, creating these section mappings. Section mappings are only created when the end of a chunk is aligned to section size. Unfortunately, with classic page tables (where PMD_SIZE is 2 * SECTION_SIZE) this means that if a chunk is between 1M and 2M in size the first 1M will not be mapped despite having been accounted for in the memblock limit. This has been observed to result in page tables being allocated from unmapped memory, causing boot-time hangs. This patch modifies the memblock limit rounding to always round down to PMD_SIZE instead of SECTION_SIZE. For classic MMU this means that we will round the memblock limit down to a 2M boundary, matching the limits on section mappings, and preventing allocations from unmapped memory. For LPAE there should be no change as PMD_SIZE == SECTION_SIZE. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Reported-by: Stefan Agner <stefan@agner.ch> Tested-by: Stefan Agner <stefan@agner.ch> Acked-by: Laura Abbott <labbott@redhat.com> Tested-by: Hans de Goede <hdegoede@redhat.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Steve Capper <steve.capper@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> [ kamal: backport to 3.13-stable: block_start, block_end rename ] Signed-off-by: Kamal Mostafa <kamal@canonical.com>
-
Philippe Reynes authored
commit a29ef819 upstream. According to the imx27 documentation, fec has a 4 Kbyte memory space map. Moreover, the actual 16 Kbyte mapping overlaps the SCC (Security Controller) memory register space. So, we reduce the memory register space to 4 Kbyte. Signed-off-by: Philippe Reynes <tremyfr@gmail.com> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Fixes: 9f0749e3 ("ARM i.MX27: Add devicetree support") Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Kamal Mostafa <kamal@canonical.com>
-
Michael Brunner authored
commit f230e8ff upstream. This patch fixes an inverted return value of the gpio get_direction function. The wrong value causes the direction sysfs entry and GPIO debugfs file to indicate incorrect GPIO direction settings. In some cases it also prevents setting GPIO output values. The problem is also present in all other stable kernel versions since linux-3.12. Reported-by: Jochen Henneberg <jh@henneberg-systemdesign.com> Signed-off-by: Michael Brunner <michael.brunner@kontron.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Kamal Mostafa <kamal@canonical.com>
-
- 06 Jul, 2015 1 commit
-
-
Kamal Mostafa authored
[3.13-stable only] Revert "ARM: net: delegate filter to kernel interpreter when imm_offset() return value can't fit into 12bits." This reverts commit a39d787c. Not suitable for 3.13 (no bpf_jit_binary_free). Cc: Brad Figg <brad.figg@canonical.com> Signed-off-by: Kamal Mostafa <kamal@canonical.com>
-
- 30 Jun, 2015 6 commits
-
-
Paolo Bonzini authored
commit ce40cd3f upstream. Malicious (or egregiously buggy) userspace can trigger it, but it should never happen in normal operation. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reference: CVE-2015-4692 Signed-off-by: Kamal Mostafa <kamal@canonical.com>
-
Ben Hutchings authored
pipe_iov_copy_{from,to}_user() may be tried twice with the same iovec, the first time atomically and the second time not. The second attempt needs to continue from the iovec position, pipe buffer offset and remaining length where the first attempt failed, but currently the pipe buffer offset and remaining length are reset. This will corrupt the piped data (possibly also leading to an information leak between processes) and may also corrupt kernel memory. This was fixed upstream by commits f0d1bec9 ("new helper: copy_page_from_iter()") and 637b58c2 ("switch pipe_read() to copy_page_to_iter()"), but those aren't suitable for stable. This fix for older kernel versions was made by Seth Jennings for RHEL and I have extracted it from their update. CVE-2015-1805 References: https://bugzilla.redhat.com/show_bug.cgi?id=1202855Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Kamal Mostafa <kamal@canonical.com>
-
James Smart authored
commit 27f344eb upstream. Add a memory barrier to ensure the valid bit is read before any of the cqe payload is read. This fixes an issue seen on Power where the cqe payload was getting loaded before the valid bit. When this occurred, we saw an iotag out of range error when a command completed, but since the iotag looked invalid the command didn't get completed to scsi core. Later we hit the command timeout, attempted to abort the command, then waited for the aborted command to get returned. Since the adapter already returned the command, we timeout waiting, and end up escalating EEH all the way to host reset. This patch fixes this issue. Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: James Smart <james.smart@emulex.com> --- lpfc_sli.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) Signed-off-by: Christoph Hellwig <hch@lst.de> Cc: Chris J Arges <chris.j.arges@canonical.com> Signed-off-by: Kamal Mostafa <kamal@canonical.com>
-
Sasha Levin authored
commit 161f873b upstream. We used to read file_handle twice. Once to get the amount of extra bytes, and once to fetch the entire structure. This may be problematic since we do size verifications only after the first read, so if the number of extra bytes changes in userspace between the first and second calls, we'll have an incoherent view of file_handle. Instead, read the constant size once, and copy that over to the final structure without having to re-read it again. Signed-off-by: Sasha Levin <sasha.levin@oracle.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Reference: CVE-2015-1420 Cc: Moritz Muehlenhoff <jmm@debian.org> Signed-off-by: Kamal Mostafa <kamal@canonical.com>
-
Kamal Mostafa authored
This reverts commit bb551e64. New feature; not qualified for -stable kernels. Signed-off-by: Kamal Mostafa <kamal@canonical.com>
-
Kamal Mostafa authored
[3.13-stable only] Revert "Drivers: hv: vmbus: Correcting truncation error for constant HV_CRASH_CTL_CRASH_NOTIFY" This reverts commit a40cec45. New feature; not qualified for -stable kernels. Signed-off-by: Kamal Mostafa <kamal@canonical.com>
-
- 22 Jun, 2015 1 commit
-
-
Kamal Mostafa authored
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
-
- 18 Jun, 2015 1 commit
-
-
Christian König authored
commit 7c0411d2 upstream. We have that bug for years and some users report side effects when fixing it on older hardware. So revert it for VM_CONTEXT0_PAGE_TABLE_END_ADDR, but keep it for VM 1-15. Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Kamal Mostafa <kamal@canonical.com>
-
- 17 Jun, 2015 6 commits
-
-
Shawn Bohrer authored
[ Upstream commit 6e540309 ] 421b3885 "udp: ipv4: Add udp early demux" introduced a regression that allowed sockets bound to INADDR_ANY to receive packets from multicast groups that the socket had not joined. For example a socket that had joined 224.168.2.9 could also receive packets from 225.168.2.9 despite not having joined that group if ip_early_demux is enabled. Fix this by calling ip_check_mc_rcu() in udp_v4_early_demux() to verify that the multicast packet is indeed ours. Signed-off-by: Shawn Bohrer <sbohrer@rgmadvisors.com> Reported-by: Yurij M. Plotnikov <Yurij.Plotnikov@oktetlabs.ru> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Kamal Mostafa <kamal@canonical.com>
-
Ian Campbell authored
[ Upstream commit 31a41898 ] When we come to tear things down in netback_remove() and generate the uevent it is possible that the xenstore directory has already been removed (details below). In such cases netback_uevent() won't be able to read the hotplug script and will write a xenstore error node. A recent change to the hypervisor exposed this race such that we now sometimes lose it (where apparently we didn't ever before). Instead read the hotplug script configuration during setup and use it for the lifetime of the backend device. The apparently more obvious fix of moving the transition to state=Closed in netback_remove() to after the uevent does not work because it is possible that we are already in state=Closed (in reaction to the guest having disconnected as it shutdown). Being already in Closed means the toolstack is at liberty to start tearing down the xenstore directories. In principal it might be possible to arrange to unregister the device sooner (e.g on transition to Closing) such that xenstore would still be there but this state machine is fragile and prone to anger... A modern Xen system only relies on the hotplug uevent for driver domains, when the backend is in the same domain as the toolstack it will run the necessary setup/teardown directly in the correct sequence wrt xenstore changes. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Wei Liu <wei.liu2@citrix.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Kamal Mostafa <kamal@canonical.com>
-
Eric Dumazet authored
[ Upstream commit beb39db5 ] We have two problems in UDP stack related to bogus checksums : 1) We return -EAGAIN to application even if receive queue is not empty. This breaks applications using edge trigger epoll() 2) Under UDP flood, we can loop forever without yielding to other processes, potentially hanging the host, especially on non SMP. This patch is an attempt to make things better. We might in the future add extra support for rt applications wanting to better control time spent doing a recv() in a hostile environment. For example we could validate checksums before queuing packets in socket receive queue. Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Willem de Bruijn <willemb@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Kamal Mostafa <kamal@canonical.com>
-
WANG Cong authored
[ Upstream commit 86e363dc ] For mq qdisc, we add per tx queue qdisc to root qdisc for display purpose, however, that happens too early, before the new dev->qdisc is finally set, this causes q->list points to an old root qdisc which is going to be freed right before assigning with a new one. Fix this by moving ->attach() after setting dev->qdisc. For the record, this fixes the following crash: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 975 at lib/list_debug.c:59 __list_del_entry+0x5a/0x98() list_del corruption. prev->next should be ffff8800d1998ae8, but was 6b6b6b6b6b6b6b6b CPU: 1 PID: 975 Comm: tc Not tainted 4.1.0-rc4+ #1019 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 0000000000000009 ffff8800d73fb928 ffffffff81a44e7f 0000000047574756 ffff8800d73fb978 ffff8800d73fb968 ffffffff810790da ffff8800cfc4cd20 ffffffff814e725b ffff8800d1998ae8 ffffffff82381250 0000000000000000 Call Trace: [<ffffffff81a44e7f>] dump_stack+0x4c/0x65 [<ffffffff810790da>] warn_slowpath_common+0x9c/0xb6 [<ffffffff814e725b>] ? __list_del_entry+0x5a/0x98 [<ffffffff81079162>] warn_slowpath_fmt+0x46/0x48 [<ffffffff81820eb0>] ? dev_graft_qdisc+0x5e/0x6a [<ffffffff814e725b>] __list_del_entry+0x5a/0x98 [<ffffffff814e72a7>] list_del+0xe/0x2d [<ffffffff81822f05>] qdisc_list_del+0x1e/0x20 [<ffffffff81820cd1>] qdisc_destroy+0x30/0xd6 [<ffffffff81822676>] qdisc_graft+0x11d/0x243 [<ffffffff818233c1>] tc_get_qdisc+0x1a6/0x1d4 [<ffffffff810b5eaf>] ? mark_lock+0x2e/0x226 [<ffffffff817ff8f5>] rtnetlink_rcv_msg+0x181/0x194 [<ffffffff817ff72e>] ? rtnl_lock+0x17/0x19 [<ffffffff817ff72e>] ? rtnl_lock+0x17/0x19 [<ffffffff817ff774>] ? __rtnl_unlock+0x17/0x17 [<ffffffff81855dc6>] netlink_rcv_skb+0x4d/0x93 [<ffffffff817ff756>] rtnetlink_rcv+0x26/0x2d [<ffffffff818544b2>] netlink_unicast+0xcb/0x150 [<ffffffff81161db9>] ? might_fault+0x59/0xa9 [<ffffffff81854f78>] netlink_sendmsg+0x4fa/0x51c [<ffffffff817d6e09>] sock_sendmsg_nosec+0x12/0x1d [<ffffffff817d8967>] sock_sendmsg+0x29/0x2e [<ffffffff817d8cf3>] ___sys_sendmsg+0x1b4/0x23a [<ffffffff8100a1b8>] ? native_sched_clock+0x35/0x37 [<ffffffff810a1d83>] ? sched_clock_local+0x12/0x72 [<ffffffff810a1fd4>] ? sched_clock_cpu+0x9e/0xb7 [<ffffffff810def2a>] ? current_kernel_time+0xe/0x32 [<ffffffff810b4bc5>] ? lock_release_holdtime.part.29+0x71/0x7f [<ffffffff810ddebf>] ? read_seqcount_begin.constprop.27+0x5f/0x76 [<ffffffff810b6292>] ? trace_hardirqs_on_caller+0x17d/0x199 [<ffffffff811b14d5>] ? __fget_light+0x50/0x78 [<ffffffff817d9808>] __sys_sendmsg+0x42/0x60 [<ffffffff817d9838>] SyS_sendmsg+0x12/0x1c [<ffffffff81a50e97>] system_call_fastpath+0x12/0x6f ---[ end trace ef29d3fb28e97ae7 ]--- For long term, we probably need to clean up the qdisc_graft() code in case it hides other bugs like this. Fixes: 95dc1929 ("pkt_sched: give visibility to mq slave qdiscs") Cc: Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com> Acked-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Kamal Mostafa <kamal@canonical.com>
-
Mark Salyzyn authored
[ Upstream commit b48732e4 ] got a rare NULL pointer dereference in clear_bit Signed-off-by: Mark Salyzyn <salyzyn@android.com> Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org> ---- v2: switch to sock_flag(sk, SOCK_DEAD) and added net/caif/caif_socket.c v3: return -ECONNRESET in upstream caller of wait function for SOCK_DEAD Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Kamal Mostafa <kamal@canonical.com>
-
Richard Cochran authored
[ Upstream commit 397a253a ] Currently, the calibration function that corrects the initial offsets among multiple devices only works the first time. If the function is called more than once, the calibration fails and bogus offsets will be programmed into the devices. In a well hidden spot, the device documentation tells that trigger indexes 0 and 1 are special in allowing the TRIG_IF_LATE flag to actually work. This patch fixes the issue by using one of the special triggers during the recalibration method. Signed-off-by: Richard Cochran <richardcochran@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Kamal Mostafa <kamal@canonical.com>
-