- 13 Dec, 2015 40 commits
-
-
Arnd Bergmann authored
commit 777d738a upstream. create_request_message() computes the maximum length of a message, but uses the wrong type for the time stamp: sizeof(struct timespec) may be 8 or 16 depending on the architecture, while sizeof(struct ceph_timespec) is always 8, and that is what gets put into the message. Found while auditing the uses of timespec for y2038 problems. Fixes: b8e69066 ("ceph: include time stamp in every MDS request") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Yan, Zheng <zyan@redhat.com> Signed-off-by:
Luis Henriques <luis.henriques@canonical.com>
-
Chuck Lever authored
commit 7b3d770c upstream. ib_req_notify_cq(IB_CQ_REPORT_MISSED_EVENTS) returns a positive value if WCs were added to a CQ after the last completion upcall but before the CQ has been re-armed. Commit 7f23f6f6 ("xprtrmda: Reduce lock contention in completion handlers") assumed that when ib_req_notify_cq() returned a positive RC, the CQ had also been successfully re-armed, making it safe to return control to the provider without losing any completion signals. That is an invalid assumption. Change both completion handlers to continue polling while ib_req_notify_cq() returns a positive value. Fixes: 7f23f6f6 ("xprtrmda: Reduce lock contention in ...") Signed-off-by:
Chuck Lever <chuck.lever@oracle.com> Reviewed-by:
Sagi Grimberg <sagig@mellanox.com> Reviewed-by:
Devesh Sharma <devesh.sharma@avagotech.com> Tested-By:
Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by:
-
Florian Westphal authored
commit dbc3617f upstream. nfnetlink_bind request_module()s all the time as nfnetlink_get_subsys() shifts the argument by 8 to obtain the subsys id. So using type instead of type << 8 always returns NULL. Fixes: 03292745 ("netlink: add nlk->netlink_bind hook for module auto-loading") Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
Masahiro Yamada authored
commit 3f5ceec9 upstream. fdt_translate_address() returns OF_BAD_ADDR on error. It is defined as a u64 value, so the variable "addr" should be defined as u64 as well. Fixes: fb11ffe7 ("of/fdt: add FDT serial scanning for earlycon") Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Tony Lindgren authored
commit 75c08f17 upstream. Commit 68bab866 ("mfd: twl6040: Optional clk32k clock handling") added clock handling for the 32k clock from palmas-clk. However, that patch did not consider a typical situation where twl6040 is built-in, and palmas-clk is a loadable module like we have in omap2plus_defconfig. If palmas-clk is not loaded before twl6040 probes, we will get a "clk32k is not handled" warning during booting. This means that any drivers relying on this clock will mysteriously fail, including omap5-uevm WLAN and audio. Note that for WLAN, we probably should also eventually get the clk32kgaudio for MMC3 directly as that's shared between audio and WLAN SDIO at least for omap5-uevm. It seems the WLAN chip cannot get it as otherwise MMC3 won't get properly probed. Fixes: 68bab866 ("mfd: twl6040: Optional clk32k clock handling") Signed-off-by:
Tony Lindgren <tony@atomide.com> Reviewed-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Ralf Baechle authored
commit f25319d2 upstream. Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Fixes: f24219b4 (cherry picked from commit f0a232cde7be18a207fd057dd79bbac8a0a45dec) Signed-off-by:
-
Linus Walleij authored
commit 7bdccef3 upstream. A static code checker found a memory leak in the Versatile ICST code. Fix it. Fixes: a183da63 "clk: versatile: respect parent rate in ICST clock" Reported-by:
Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Yuchung Cheng authored
commit 9e45a3e3 upstream. Currently ca_seq_rtt_us does not use Kern's check. Fix that by checking if any packet acked is a retransmit, for both RTT used for RTT estimation and congestion control. Fixes: 5b08e47c ("tcp: prefer packet timing to TS-ECR for RTT") Signed-off-by:
Yuchung Cheng <ycheng@google.com> Signed-off-by:
Neal Cardwell <ncardwell@google.com> Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
David S. Miller <davem@davemloft.net> [ luis: backported to 3.16: adjusted context ] Signed-off-by:
-
Takashi Sakamoto authored
commit fef586d5 upstream. In former commit, metering is supported for BeBoB based models customized by M-Audio. The data in transaction is aligned to big-endianness, while in the driver code u16 typed variable is assigned to the data. This causes sparse warnings. bebob_maudio.c:651:31: warning: cast to restricted __be16 bebob_maudio.c:651:31: warning: cast to restricted __be16 bebob_maudio.c:651:31: warning: cast to restricted __be16 bebob_maudio.c:651:31: warning: cast to restricted __be16 This commit fixes this bug by using __be16 variable for the data. Fixes: 3149ac48('ALSA: bebob: Add support for M-Audio special Firewire series') Signed-off-by:
Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Takashi Sakamoto authored
commit 463543ac upstream. In former commit, snd_efw_command_get_phys_meters() was added to handle metering data. The given buffer is used to save transaction result and to convert between endianness. But this causes sparse warnings. fireworks_command.c:269:25: warning: incorrect type in argument 1 (different base types) fireworks_command.c:269:25: expected unsigned int [usertype] *p fireworks_command.c:269:25: got restricted __be32 [usertype] * This commit fixes this bug. Fixes: bde8a8f2('ALSA: fireworks: Add transaction and some commands') Signed-off-by:
-
Lukas Wunner authored
commit 3c67d839 upstream. In its original version, drm_framebuffer_init() returned a negative int if drm_mode_object_get() failed (f453ba04, "DRM: add mode setting support"). This was accidentally disabled by commit 4b096ac1 ("drm: revamp locking around fb creation/destruction"). Thus, drm_framebuffer_init() pretends success if drm_mode_object_get() failed. Reinstate the original behaviour. Also fix erroneous kernel-doc of drm_mode_object_get(). Fixes: 4b096ac1 ("drm: revamp locking around fb creation/ destruction") Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Lukas Wunner <lukas@wunner.de> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Takashi Sakamoto authored
commit df483388 upstream. When committed to upstream, these four modules had wrong entries for Makefile. This forces them to be loadable modules even if they're set as built-in. This commit fixes this bug. Fixes: b5b04336('ALSA: fireworks: Add skelton for Fireworks based devices') Fixes: fd6f4b0d('ALSA: bebob: Add skelton for BeBoB based devices') Fixes: 1a4e39c2('ALSA: oxfw: Move to its own directory') Fixes: 14ff6a09('ALSA: dice: Move file to its own directory') Signed-off-by:
-
Arnd Bergmann authored
commit 54c09889 upstream. The z2 machine calls pxa27x_set_pwrmode() in order to power off the machine, but this function gets discarded early at boot because it is marked __init, as pointed out by kbuild: WARNING: vmlinux.o(.text+0x145c4): Section mismatch in reference from the function z2_power_off() to the function .init.text:pxa27x_set_pwrmode() The function z2_power_off() references the function __init pxa27x_set_pwrmode(). This is often because z2_power_off lacks a __init annotation or the annotation of pxa27x_set_pwrmode is wrong. This removes the __init section modifier to fix rebooting and the build error. Signed-off-by:
Robert Jarzmik <robert.jarzmik@free.fr> [ luis: backported to 3.16: adjusted context ] Signed-off-by:
-
Roger Quadros authored
commit e74eba04 upstream. The error handling path is broken as cawake_gpio was defined as unsigned integer causing the following warnings on boards that don't use SSI port and so don't have cawake_gpio defined. e.g. beagleboard C4. [ 30.094635] WARNING: CPU: 0 PID: 322 at drivers/gpio/gpiolib.c:86 gpio_to_desc+0xa4/0xb8() [ 30.103363] invalid GPIO -2 [ 30.106292] Modules linked in: omap_ssi_port(+) cpufreq_dt cfbfillrect cfbimgblt leds_gpio cfbcopyarea thermal_sys led_class hwmon gpio_keys encoder_tfp410 connector_analog_tv connector_dvi omap_hdq snd phy_i [ 30.145477] CPU: 0 PID: 322 Comm: modprobe Not tainted 4.3.0-rc4-00030-gca978c0-dirty #335 [ 30.154174] Hardware name: Generic OMAP3-GP (Flattened Device Tree) [ 30.160827] [<c0016ef4>] (unwind_backtrace) from [<c00131f4>] (show_stack+0x10/0x14) [ 30.168975] [<c00131f4>] (show_stack) from [<c033cf08>] (dump_stack+0x80/0x9c) [ 30.176635] [<c033cf08>] (dump_stack) from [<c003e920>] (warn_slowpath_common+0x7c/0xb8) [ 30.185180] [<c003e920>] (warn_slowpath_common) from [<c003e9f0>] (warn_slowpath_fmt+0x30/0x40) [ 30.194366] [<c003e9f0>] (warn_slowpath_fmt) from [<c0376314>] (gpio_to_desc+0xa4/0xb8) [ 30.202819] [<c0376314>] (gpio_to_desc) from [<c0376ac8>] (gpio_request_one+0x14/0x11c) [ 30.211273] [<c0376ac8>] (gpio_request_one) from [<c037370c>] (devm_gpio_request_one+0x3c/0x78) [ 30.220458] [<c037370c>] (devm_gpio_request_one) from [<bf184210>] (ssi_port_probe+0x118/0x504 [omap_ssi_port]) [ 30.231170] [<bf184210>] (ssi_port_probe [omap_ssi_port]) from [<c03d4cfc>] (platform_drv_probe+0x48/0xa4) [ 30.241424] [<c03d4cfc>] (platform_drv_probe) from [<c03d3678>] (driver_probe_device+0x1dc/0x2a0) [ 30.250793] [<c03d3678>] (driver_probe_device) from [<c03d37d0>] (__driver_attach+0x94/0x98) [ 30.259643] [<c03d37d0>] (__driver_attach) from [<c03d1d60>] (bus_for_each_dev+0x54/0x88) [ 30.268249] [<c03d1d60>] (bus_for_each_dev) from [<c03d2d50>] (bus_add_driver+0xe8/0x1f8) [ 30.276916] [<c03d2d50>] (bus_add_driver) from [<c03d4118>] (driver_register+0x78/0xf4) [ 30.285369] [<c03d4118>] (driver_register) from [<c03d5380>] (__platform_driver_probe+0x34/0xd8) [ 30.294647] [<c03d5380>] (__platform_driver_probe) from [<c00097e4>] (do_one_initcall+0x80/0x1d8) [ 30.303985] [<c00097e4>] (do_one_initcall) from [<c011617c>] (do_init_module+0x5c/0x1cc) [ 30.312561] [<c011617c>] (do_init_module) from [<c00c7a68>] (load_module+0x18c8/0x1f0c) [ 30.320983] [<c00c7a68>] (load_module) from [<c00c8188>] (SyS_init_module+0xdc/0x150) [ 30.329223] [<c00c8188>] (SyS_init_module) from [<c000f7e0>] (ret_fast_syscall+0x0/0x1c) Fixes: b209e047 ("HSI: Introduce OMAP SSI driver") Signed-off-by:
Roger Quadros <rogerq@ti.com> Signed-off-by:
Sebastian Reichel <sre@kernel.org> Signed-off-by:
-
Geliang Tang authored
commit f098a045 upstream. When device_register() fails, kfree() is called in hsi_client_release(), hence there is no need to call kfree in err3 again. Fixes: a2aa2473 ("HSI: Add common DT binding for HSI client devices") Signed-off-by:
Geliang Tang <geliangtang@163.com> Signed-off-by:
-
Eric Dumazet authored
commit 161642e2 upstream. Recent TCP listener patches exposed a prior af_packet bug : match_fanout_group() blindly assumes it is always safe to cast sk to a packet socket to compare fanout with af_packet_priv But SYNACK packets can be sent while attached to request_sock, which are smaller than a "struct sock". We can read non existent memory and crash. Fixes: c0de08d0 ("af_packet: don't emit packet on orig fanout group") Fixes: ca6fb065 ("tcp: attach SYNACK messages to request sockets instead of listener") Signed-off-by:
-
Eric W. Biederman authored
commit 850dcc4d upstream. After a packet has been encapsulated by a tunnel we should use the tunnel sockets local multicast loopback flag to control if the encapsulated packet should be locally loopback back. Pass sk into ip_local_out_sk so that in the rare case we are dealing with a tunneled packet whose tunnel destination address is a multicast address the kernel properly decides to loopback this packet. In practice I don't think this matters as ip_queue_xmit is used by tcp, l2tp and sctp none of which I am aware of uses ip level multicasting as they are all point to point communications protocols. Let's fix this before someone uses ip_queue_xmit for a tunnel protocol that does use multicast. Fixes: aad88724 ("ipv4: add a sock pointer to dst->output() path.") Fixes: b0270e91 ("ipv4: add a sock pointer to ip_queue_xmit()") Signed-off-by:
"Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by:
-
Flavio Leitner authored
commit 0647e708 upstream. Remove __nf_conntrack_find() from headers. Fixes: dcd93ed4 ("netfilter: nf_conntrack: remove dead code") Signed-off-by:
Flavio Leitner <fbl@sysclose.org> Signed-off-by:
-
Dan Carpenter authored
commit 1f35d04a upstream. The iomap[] array has PCIM_IOMAP_MAX (6) elements and not DEVICE_COUNT_RESOURCE (16). This bug was found using a static checker. It may be that the "if (!(mask & (1 << i)))" check means we never actually go past the end of the array in real life. Fixes: ec04b075 ('iomap: implement pcim_iounmap_regions()') Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Jonas Gorski authored
commit db1319e1 upstream. Commit d445913c ("usb: ehci-orion: add optional PHY support") added support for optional phys, but devm_phy_optional_get returns -ENOSYS if GENERIC_PHY is not enabled. This causes probe failures, even when there are no phys specified: [ 1.443365] orion-ehci f1058000.usb: init f1058000.usb fail, -38 [ 1.449403] orion-ehci: probe of f1058000.usb failed with error -38 Similar to dwc3, treat -ENOSYS as no phy. Fixes: d445913c ("usb: ehci-orion: add optional PHY support") Signed-off-by:
Jonas Gorski <jogo@openwrt.org> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Andy Shevchenko authored
commit 39416677 upstream. We replace __fls() by __ffs() since we have to find a *minimum* data width that satisfies both source and destination. While here, rename dwc_fast_fls() to dwc_fast_ffs() which it really is. Fixes: 4c2d56c5 (dw_dmac: introduce dwc_fast_fls()) Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Vinod Koul <vinod.koul@intel.com> Signed-off-by:
-
Dan Carpenter authored
commit 1f9c6e1b upstream. There were several bugs here. 1) The done label was in the wrong place so we didn't copy any information out when there was no command given. 2) We were using PAGE_SIZE as the size of the buffer instead of "PAGE_SIZE - pos". 3) snprintf() returns the number of characters that would have been printed if there were enough space. If there was not enough space (and we had fixed the memory corruption bug #2) then it would result in an information leak when we do simple_read_from_buffer(). I've changed it to use scnprintf() instead. I also removed the initialization at the start of the function, because I thought it made the code a little more clear. Fixes: 5e6e3a92 ('wireless: mwifiex: initial commit for Marvell mwifiex driver') Signed-off-by:
Amitkumar Karwar <akarwar@marvell.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Valentin Rothberg authored
commit 90adf98d upstream. Since commit 1c6c6952 ("genirq: Reject bogus threaded irq requests") threaded IRQs without a primary handler need to be requested with IRQF_ONESHOT, otherwise the request will fail. scripts/coccinelle/misc/irqf_oneshot.cocci detected this issue. Fixes: b5874f33 ("wm831x_power: Use genirq") Signed-off-by:
Valentin Rothberg <valentinrothberg@gmail.com> Signed-off-by:
-
Johannes Berg authored
commit 8ec6d978 upstream. The ifmgd->ave_beacon_signal value cannot be taken as is for comparisons, it must be divided by since it's represented like that for better accuracy of the EWMA calculations. This would lead to invalid driver RSSI events. Fix the used value. Fixes: 615f7b9b ("mac80211: add driver RSSI threshold events") Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Christophe Leroy authored
commit 0ff28d9f upstream. Using sendfile with below small program to get MD5 sums of some files, it appear that big files (over 64kbytes with 4k pages system) get a wrong MD5 sum while small files get the correct sum. This program uses sendfile() to send a file to an AF_ALG socket for hashing. /* md5sum2.c */ int main(int argc, char **argv) { int sk = socket(AF_ALG, SOCK_SEQPACKET, 0); struct stat st; struct sockaddr_alg sa = { .salg_family = AF_ALG, .salg_type = "hash", .salg_name = "md5", }; int n; bind(sk, (struct sockaddr*)&sa, sizeof(sa)); for (n = 1; n < argc; n++) { int size; int offset = 0; char buf[4096]; int fd; int sko; int i; fd = open(argv[n], O_RDONLY); sko = accept(sk, NULL, 0); fstat(fd, &st); size = st.st_size; sendfile(sko, fd, &offset, size); size = read(sko, buf, sizeof(buf)); for (i = 0; i < size; i++) printf("%2.2x", buf[i]); printf(" %s\n", argv[n]); close(fd); close(sko); } exit(0); } Test below is done using official linux patch files. First result is with a software based md5sum. Second result is with the program above. root@vgoip:~# ls -l patch-3.6.* -rw-r--r-- 1 root root 64011 Aug 24 12:01 patch-3.6.2.gz -rw-r--r-- 1 root root 94131 Aug 24 12:01 patch-3.6.3.gz root@vgoip:~# md5sum patch-3.6.* b3ffb9848196846f31b2ff133d2d6443 patch-3.6.2.gz c5e8f687878457db77cb7158c38a7e43 patch-3.6.3.gz root@vgoip:~# ./md5sum2 patch-3.6.* b3ffb9848196846f31b2ff133d2d6443 patch-3.6.2.gz 5fd77b24e68bb24dcc72d6e57c64790e patch-3.6.3.gz After investivation, it appears that sendfile() sends the files by blocks of 64kbytes (16 times PAGE_SIZE). The problem is that at the end of each block, the SPLICE_F_MORE flag is missing, therefore the hashing operation is reset as if it was the end of the file. This patch adds SPLICE_F_MORE to the flags when more data is pending. With the patch applied, we get the correct sums: root@vgoip:~# md5sum patch-3.6.* b3ffb9848196846f31b2ff133d2d6443 patch-3.6.2.gz c5e8f687878457db77cb7158c38a7e43 patch-3.6.3.gz root@vgoip:~# ./md5sum2 patch-3.6.* b3ffb9848196846f31b2ff133d2d6443 patch-3.6.2.gz c5e8f687878457db77cb7158c38a7e43 patch-3.6.3.gz Signed-off-by:
Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by:
Jens Axboe <axboe@fb.com> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Eric Biggers authored
commit 6ae08069 upstream. pipe_write() would return 0 if it failed to merge the beginning of the data to write with the last, partially filled pipe buffer. It should return an error code instead. Userspace programs could be confused by write() returning 0 when called with a nonzero 'count'. The EFAULT error case was a regression from f0d1bec9 ("new helper: copy_page_from_iter()"), while the ops->confirm() error case was a much older bug. Test program: #include <assert.h> #include <errno.h> #include <unistd.h> int main(void) { int fd[2]; char data[1] = {0}; assert(0 == pipe(fd)); assert(1 == write(fd[1], data, 1)); /* prior to this patch, write() returned 0 here */ assert(-1 == write(fd[1], NULL, 1)); assert(errno == EFAULT); } Signed-off-by:
Eric Biggers <ebiggers3@gmail.com> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Maciej W. Rozycki authored
commit b582ef5c upstream. Do not clobber the buffer space passed from `search_binary_handler' and originally preloaded by `prepare_binprm' with the executable's file header by overwriting it with its interpreter's file header. Instead keep the buffer space intact and directly use the data structure locally allocated for the interpreter's file header, fixing a bug introduced in 2.1.14 with loadable module support (linux-mips.org commit beb11695 [Import of Linux/MIPS 2.1.14], predating kernel.org repo's history). Adjust the amount of data read from the interpreter's file accordingly. This was not an issue before loadable module support, because back then `load_elf_binary' was executed only once for a given ELF executable, whether the function succeeded or failed. With loadable module support supported and enabled, upon a failure of `load_elf_binary' -- which may for example be caused by architecture code rejecting an executable due to a missing hardware feature requested in the file header -- a module load is attempted and then the function reexecuted by `search_binary_handler'. With the executable's file header replaced with its interpreter's file header the executable can then be erroneously accepted in this subsequent attempt. Signed-off-by:
Maciej W. Rozycki <macro@imgtec.com> Signed-off-by:
-
Kinglong Mee authored
commit b130ed59 upstream. Only override netfs->primary_index when registering success. Signed-off-by:
Kinglong Mee <kinglongmee@gmail.com> Signed-off-by:
David Howells <dhowells@redhat.com> Signed-off-by:
-
Kinglong Mee authored
commit 86108c2e upstream. If netfs exist, fscache should not increase the reference of parent's usage and n_children, otherwise, never be decreased. v2: thanks David's suggest, move increasing reference of parent if success use kmem_cache_free() freeing primary_index directly v3: don't move "netfs->primary_index->parent = &fscache_fsdef_index;" Signed-off-by:
-
Egbert Eich authored
commit 28fb4cb7 upstream. Due to a missing initialization there was no way to map fbdev memory. Thus for example using the Xserver with the fbdev driver failed. This fix adds initialization for fix.smem_start and fix.smem_len in the fb_info structure, which fixes this problem. Requested-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
Egbert Eich <eich@suse.de> [pulled from SuSE tree by me - airlied] Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Jason Liu authored
commit 1cc8e345 upstream. There is an alignment mismatch issue between the of_reserved_mem and the CMA setup requirement. The of_reserved_mem will try to get the alignment value from the DTS and pass it to __memblock_alloc_base to do the memory block base allocation, but the alignment value specified in the DTS may not satisfy the CAM setup requirement since CMA setup required the alignment as the following in the code: align = PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order); The sanity check in the function of rmem_cma_setup will fail if the alignment does not setup correctly and thus CMA will fail to setup. This patch is to fixup the alignment to meet the CMA setup required. Mailing-list-thread: https://lkml.org/lkml/2015/11/9/138Signed-off-by:
Jason Liu <r64343@freescale.com> Acked-by:
Marek Szyprowski <m.szyprowski@samsung.com> Cc: Grant Likely <grant.likely@linaro.org> Cc: Rob Herring <robh+dt@kernel.org> Signed-off-by:
-
Paolo Bonzini authored
commit cbdb967a upstream. This is needed to avoid the possibility that the guest triggers an infinite stream of #DB exceptions (CVE-2015-8104). VMX is not affected: because it does not save DR6 in the VMCS, it already intercepts #DB unconditionally. Reported-by:
Jan Beulich <jbeulich@suse.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Eric Northup authored
commit 54a20552 upstream. It was found that a guest can DoS a host by triggering an infinite stream of "alignment check" (#AC) exceptions. This causes the microcode to enter an infinite loop where the core never receives another interrupt. The host kernel panics pretty quickly due to the effects (CVE-2015-5307). Signed-off-by:
Eric Northup <digitaleric@google.com> Signed-off-by:
-
Nadav Amit authored
commit c9cdd085 upstream. Defining XE, XM and VE vector numbers. Signed-off-by:
Nadav Amit <namit@cs.technion.ac.il> Signed-off-by:
-
K. Y. Srinivasan authored
commit 8cf308e1 upstream. Don't set the SRB_FLAGS_QUEUE_ACTION_ENABLE flag since we are not specifying tags. Without this, the qlogic driver doesn't work properly with storvsc. Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
James Bottomley <JBottomley@Odin.com> Signed-off-by:
-
Hans de Goede authored
commit f71c882d upstream. Like some of the other Yoga models the Lenovo Yoga 900 does not have a hw rfkill switch, and trying to read the hw rfkill switch through the ideapad module causes it to always reported blocking breaking wifi. This commit adds the Lenovo Yoga 900 to the no_hw_rfkill dmi list, fixing the wifi breakage. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1275490Reported-and-tested-by:
Kevin Fenzi <kevin@scrye.com> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Darren Hart <dvhart@linux.intel.com> Signed-off-by:
-
Filipe Manana authored
commit f1cd1f0b upstream. When listing a inode's xattrs we have a time window where we race against a concurrent operation for adding a new hard link for our inode that makes us not return any xattr to user space. In order for this to happen, the first xattr of our inode needs to be at slot 0 of a leaf and the previous leaf must still have room for an inode ref (or extref) item, and this can happen because an inode's listxattrs callback does not lock the inode's i_mutex (nor does the VFS does it for us), but adding a hard link to an inode makes the VFS lock the inode's i_mutex before calling the inode's link callback. If we have the following leafs: Leaf X (has N items) Leaf Y [ ... (257 INODE_ITEM 0) (257 INODE_REF 256) ] [ (257 XATTR_ITEM 12345), ... ] slot N - 2 slot N - 1 slot 0 The race illustrated by the following sequence diagram is possible: CPU 1 CPU 2 btrfs_listxattr() searches for key (257 XATTR_ITEM 0) gets path with path->nodes[0] == leaf X and path->slots[0] == N because path->slots[0] is >= btrfs_header_nritems(leaf X), it calls btrfs_next_leaf() btrfs_next_leaf() releases the path adds key (257 INODE_REF 666) to the end of leaf X (slot N), and leaf X now has N + 1 items searches for the key (257 INODE_REF 256), with path->keep_locks == 1, because that is the last key it saw in leaf X before releasing the path ends up at leaf X again and it verifies that the key (257 INODE_REF 256) is no longer the last key in leaf X, so it returns with path->nodes[0] == leaf X and path->slots[0] == N, pointing to the new item with key (257 INODE_REF 666) btrfs_listxattr's loop iteration sees that the type of the key pointed by the path is different from the type BTRFS_XATTR_ITEM_KEY and so it breaks the loop and stops looking for more xattr items --> the application doesn't get any xattr listed for our inode So fix this by breaking the loop only if the key's type is greater than BTRFS_XATTR_ITEM_KEY and skip the current key if its type is smaller. Signed-off-by:
Filipe Manana <fdmanana@suse.com> [ luis: backported to 3.16: - drop btrfs_key_type(), which was dropped upstream by 962a298f ("btrfs: kill the key type accessor helpers") ] Signed-off-by:
-
Peter Oberparleiter authored
commit 863e02d0 upstream. Writing a number to /sys/bus/scsi/devices/<sdev>/queue_ramp_up_period returns the value of that number instead of the number of bytes written. This behavior can confuse programs expecting POSIX write() semantics. Fix this by returning the number of bytes written instead. Signed-off-by:
Peter Oberparleiter <oberpar@linux.vnet.ibm.com> Reviewed-by:
Hannes Reinecke <hare@suse.de> Reviewed-by:
Matthew R. Ochs <mrochs@linux.vnet.ibm.com> Reviewed-by:
Ewan D. Milne <emilne@redhat.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Peter Zijlstra authored
commit b71b437e upstream. Arnaldo reported that tracepoint filters seem to misbehave (ie. not apply) on inherited events. The fix is obvious; filters are only set on the actual (parent) event, use the normal pattern of using this parent event for filters. This is safe because each child event has a reference to it. Reported-by:
Arnaldo Carvalho de Melo <acme@kernel.org> Tested-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: David Ahern <dsahern@gmail.com> Cc: Frédéric Weisbecker <fweisbec@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/r/20151102095051.GN17308@twins.programming.kicks-ass.netSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Filipe Manana authored
commit 1d512cb7 upstream. If we are using the NO_HOLES feature, we have a tiny time window when running delalloc for a nodatacow inode where we can race with a concurrent link or xattr add operation leading to a BUG_ON. This happens because at run_delalloc_nocow() we end up casting a leaf item of type BTRFS_INODE_[REF|EXTREF]_KEY or of type BTRFS_XATTR_ITEM_KEY to a file extent item (struct btrfs_file_extent_item) and then analyse its extent type field, which won't match any of the expected extent types (values BTRFS_FILE_EXTENT_[REG|PREALLOC|INLINE]) and therefore trigger an explicit BUG_ON(1). The following sequence diagram shows how the race happens when running a no-cow dellaloc range [4K, 8K[ for inode 257 and we have the following neighbour leafs: Leaf X (has N items) Leaf Y [ ... (257 INODE_ITEM 0) (257 INODE_REF 256) ] [ (257 EXTENT_DATA 8192), ... ] slot N - 2 slot N - 1 slot 0 (Note the implicit hole for inode 257 regarding the [0, 8K[ range) CPU 1 CPU 2 run_dealloc_nocow() btrfs_lookup_file_extent() --> searches for a key with value (257 EXTENT_DATA 4096) in the fs/subvol tree --> returns us a path with path->nodes[0] == leaf X and path->slots[0] == N because path->slots[0] is >= btrfs_header_nritems(leaf X), it calls btrfs_next_leaf() btrfs_next_leaf() --> releases the path hard link added to our inode, with key (257 INODE_REF 500) added to the end of leaf X, so leaf X now has N + 1 keys --> searches for the key (257 INODE_REF 256), because it was the last key in leaf X before it released the path, with path->keep_locks set to 1 --> ends up at leaf X again and it verifies that the key (257 INODE_REF 256) is no longer the last key in the leaf, so it returns with path->nodes[0] == leaf X and path->slots[0] == N, pointing to the new item with key (257 INODE_REF 500) the loop iteration of run_dealloc_nocow() does not break out the loop and continues because the key referenced in the path at path->nodes[0] and path->slots[0] is for inode 257, its type is < BTRFS_EXTENT_DATA_KEY and its offset (500) is less then our delalloc range's end (8192) the item pointed by the path, an inode reference item, is (incorrectly) interpreted as a file extent item and we get an invalid extent type, leading to the BUG_ON(1): if (extent_type == BTRFS_FILE_EXTENT_REG || extent_type == BTRFS_FILE_EXTENT_PREALLOC) { (...) } else if (extent_type == BTRFS_FILE_EXTENT_INLINE) { (...) } else { BUG_ON(1) } The same can happen if a xattr is added concurrently and ends up having a key with an offset smaller then the delalloc's range end. So fix this by skipping keys with a type smaller than BTRFS_EXTENT_DATA_KEY. Signed-off-by:
-
