- 12 Jan, 2017 11 commits
-
-
Srinivas Pandruvada authored
commit 143fca77 upstream. While applying patch d443a0aa: "HID: hid-sensor-hub: clear memory to avoid random data", there was some issues in applying correct version of the patch. This resulted in the breakage of sensor functions as all request like power-up will be reset by the memset() in the function sensor_hub_set_feature(). The reset of caller buffer should be in the function sensor_hub_get_feature(), not in the sensor_hub_set_feature(). Fixes: d443a0aa ("HID: hid-sensor-hub: clear memory to avoid random data") Signed-off-by:
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Helge Deller authored
commit 41744213 upstream. The cr16 interval timer of each CPU is not syncronized to other cr16 timers in other CPUs in a SMP system. So, delay the registration of the cr16 clocksource until all CPUs have been detected and then - if we are on a SMP machine - mark the cr16 clocksource as unstable and lower it's rating before registering it at the clocksource framework. This patch fixes the stalled CPU warnings which we have seen since introduction of the cr16 clocksource. Signed-off-by:
Helge Deller <deller@gmx.de> Signed-off-by:
-
Helge Deller authored
commit b4a9eb4c upstream. Add a leading line break else printed line gets too long. Signed-off-by:
-
Eric Biggers authored
commit 42d97eb0 upstream. Attempting to link a device node, named pipe, or socket file into an encrypted directory through rename(2) or link(2) always failed with EPERM. This happened because fscrypt_has_permitted_context() saw that the file was unencrypted and forbid creating the link. This behavior was unexpected because such files are never encrypted; only regular files, directories, and symlinks can be encrypted. To fix this, make fscrypt_has_permitted_context() always return true on special files. This will be covered by a test in my encryption xfstests patchset. Fixes: 9bd8212f ("ext4 crypto: add encryption policy and password salt support") Signed-off-by:
Eric Biggers <ebiggers@google.com> Reviewed-by:
Richard Weinberger <richard@nod.at> Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Signed-off-by:
-
Ioan-Adrian Ratiu authored
commit 1d0f9530 upstream. Commit 16200948 ("ALSA: usb-audio: Fix race at stopping the stream") was incomplete causing another more severe kernel panic, so it got reverted. This fixes both the original problem and its fallout kernel race/crash. The original fix is to move the endpoint member NULL clearing logic inside wait_clear_urbs() so the irq triggering the urb completion doesn't call retire_capture/playback_urb() after the NULL clearing and generate a panic. However this creates a new race between snd_usb_endpoint_start()'s call to wait_clear_urbs() and the irq urb completion handler which again calls retire_capture/playback_urb() leading to a new NULL dereference. We keep the EP deactivation code in snd_usb_endpoint_start() because removing it will break the EP reference counting (see [1] [2] for info), however we don't need the "can_sleep" mechanism anymore because a new function was introduced (snd_usb_endpoint_sync_pending_stop()) which synchronizes pending stops and gets called inside the pcm prepare callback. It also makes sense to remove can_sleep because it was also removed from deactivate_urbs() signature in [3] so we benefit from more simplification. [1] commit 015618b9 ("ALSA: snd-usb: Fix URB cancellation at stream start") [2] commit e9ba389c ("ALSA: usb-audio: Fix scheduling-while-atomic bug in PCM capture stream") [3] commit ccc1696d ("ALSA: usb-audio: simplify endpoint deactivation code") Fixes: f8114f85 ("Revert "ALSA: usb-audio: Fix race at stopping the stream"") Signed-off-by:
Ioan-Adrian Ratiu <adi@adirat.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Takashi Iwai authored
commit c7efff92 upstream. Although the old quirk table showed ASUS X71SL with ALC663 codec being compatible with asus-mode3 fixup, the bugzilla reporter explained that asus-model8 fits better for the dual headphone controls. So be it. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=191781Signed-off-by:
-
Takashi Iwai authored
commit 85bcf96c upstream. ASUS ROG Ranger VIII with ALC1150 codec requires the extra GPIO pin to up for the front panel. Just use the existing fixup for setting up the GPIO pins. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=189411Signed-off-by:
-
Florian Fainelli authored
commit e7c9a3d9 upstream. The Octeon driver calls into PHYLIB which now checks for net_device->dev.parent, so make sure we do set it before calling into any MDIO/PHYLIB related function. Fixes: ec988ad7 ("phy: Don't increment MDIO bus refcount unless it's a different owner") Reported-by:
Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Marcin Niestroj authored
commit 01d1f7a9 upstream. Datasheet specifies typical and maximum execution times for which CMD register is occupied after previous command execution. We took these values as minimum and maximum time for usleep_range() call before making a new command execution. To be sure, that the CMD register is no longer occupied we need to wait *at least* the maximum time specified by datasheet. Signed-off-by:
Marcin Niestroj <m.niestroj@grinn-global.com> Signed-off-by:
Jonathan Cameron <jic23@kernel.org> Signed-off-by:
-
Akinobu Mita authored
commit b4e8a0eb upstream. According to the datasheet, the shortest available integration time for ALS ADC conversion is 1.5625ms but illuminance_integration_time_available sysfs file shows wrong value. Cc: Crestez Dan Leonard <leonard.crestez@intel.com> Cc: Jonathan Cameron <jic23@kernel.org> Cc: Hartmut Knaack <knaack.h@gmx.de> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Signed-off-by:
Akinobu Mita <akinobu.mita@gmail.com> Fixes: d5d8f49b ("max44000: Expose ambient sensor scaling") Signed-off-by:
-
Lorenzo Bianconi authored
commit 65c8aea0 upstream. Using realbits as i2c/spi read len, when that value is not byte aligned (e.g 12 bits), lead to skip msb part of out data registers. Fix this taking into account scan_type.shift in addition to scan_type.realbits as read length: read_len = DIV_ROUND_UP(realbits + shift, 8) This fix has been tested on 8, 12, 16, 24 bit sensors Fixes: e7385de5 ("iio:st_sensors: align on storagebits boundaries") Signed-off-by:
Lorenzo Bianconi <lorenzo.bianconi@st.com> Tested-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
- 09 Jan, 2017 29 commits
-
-
Greg Kroah-Hartman authored
-
Mika Kuoppala authored
commit b1b7ec98 upstream. For limiting the max frequency of gpu, the max freq tunable is not enough to hard limit the max gap. We now have also per client boost max freq. When this tunable was introduced, it was mistakenly made read only. Allow user to gain control by setting it writable. Fixes: 29ecd78d ("drm/i915: Define a separate variable and control for RPS waitboost frequency") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1481718380-9170-1-git-send-email-mika.kuoppala@intel.com (cherry picked from commit 73a79871) Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Paulo Zanoni authored
commit 6ba0566c upstream. BSpec got updated and this workaround is now listed as standard required programming for all subsequent projects. This is confirmed to fix Skylake screen flickering issues (probably caused by the fact that we initialized a ring in the first page of stolen, but I didn't 100% confirm this theory). v2: this is the patch that fixes the screen flickering, document it. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94605Tested-by:
Dominik Klementowski <dominik232@gmail.com> Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1481727338-9901-1-git-send-email-paulo.r.zanoni@intel.com (cherry picked from commit d4353761) Signed-off-by:
-
Ville Syrjälä authored
commit 1f3dc3e3 upstream. Looks like we're only initializing dev_priv->atomic_cdclk_freq at resume and commit times, not at init time. Let's do that as well. We're now hitting the 'WARN_ON(intel_state->cdclk == 0)' in hsw_compute_linetime_wm() on account of populating intel_state->cdclk from dev_priv->atomic_cdclk_freq. Previously we were mispopulating intel_state->cdclk with dev_priv->cdclk_freq which always had a proper value at init time and hence the WARN_ON() didn't trigger. Cc: Matthew Auld <matthew.auld@intel.com> Reported-by:
Matthew Auld <matthew.auld@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98902 Fixes: 14676ec6 ("drm/i915: Fix cdclk vs. dev_cdclk mess when not recomputing things") Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1480428837-4207-1-git-send-email-ville.syrjala@linux.intel.comTested-by:
-
Ville Syrjälä authored
commit 14676ec6 upstream. When we end up not recomputing the cdclk, we need to populate intel_state->cdclk with the "atomic_cdclk_freq" instead of the current cdclk_freq. When no pipes are active, the actual cdclk_freq may be lower than what the configuration of the planes and pipes would require from the point of view of the software state. This fixes bogus WARNS from skl_max_scale() which is trying to check the plane software state against the cdclk frequency. So any time it got called during DPMS off for instance, we might have tripped the warn if the current mode would have required a higher than minimum cdclk. v2: Drop the dev_cdclk stuff (Maarten) Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Cc: bruno.pagani@ens-lyon.org Cc: Daniel J Blueman <daniel.blueman@gmail.com> Cc: Paul Bolle <pebolle@tiscali.nl> Cc: Joseph Yasi <joe.yasi@gmail.com> Tested-by:
Paul Bolle <pebolle@tiscali.nl> Tested-by: Joseph Yasi <joe.yasi@gmail.com> (v1) Fixes: 1a617b77 ("drm/i915: Keep track of the cdclk as if all crtc's were active.") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98214Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1479141311-11904-2-git-send-email-ville.syrjala@linux.intel.com (cherry picked from commit e0ca7a6b) Signed-off-by:
-
Hans de Goede authored
commit bb98e72a upstream. On my Cherrytrail CUBE iwork8 Air tablet PIPE-A would get stuck on loading i915 at boot 1 out of every 3 boots, resulting in a non functional LCD. Once the i915 driver has successfully loaded, the panel can be disabled / enabled without hitting this issue. The getting stuck is caused by vlv_init_display_clock_gating() clearing the DPOUNIT_CLOCK_GATE_DISABLE bit in DSPCLK_GATE_D when called from chv_pipe_power_well_ops.enable() on driver load, while a pipe is enabled driving the DSI LCD by the BIOS. Clearing this bit while DSI is in use is a known issue and intel_dsi_pre_enable() / intel_dsi_post_disable() already set / clear it as appropriate. This commit modifies vlv_init_display_clock_gating() to leave the DPOUNIT_CLOCK_GATE_DISABLE bit alone fixing the pipe getting stuck. Changes in v2: -Replace PIPE-A with "a pipe" or "the pipe" in the commit msg and comment Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97330Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
-
Hans de Goede authored
commit 22ca0d49 upstream. Set the CHV_GPIO_GPIOEN bit when updating GPIOs from chv_exec_gpio. Fixes: a0a6d4ff ("drm/i915/dsi: add support for gpio elements on CHV") Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Thomas Petazzoni authored
commit 8354491c upstream. Since commit 71ce391d ("net: mvpp2: enable proper per-CPU TX buffers unmapping"), we are not correctly DMA unmapping TX buffers for fragments. Indeed, the mvpp2_txq_inc_put() function only stores in the txq_cpu->tx_buffs[] array the physical address of the buffer to be DMA-unmapped when skb != NULL. In addition, when DMA-unmapping, we use skb_headlen(skb) to get the size to be unmapped. Both of this works fine for TX descriptors that are associated directly to a SKB, but not the ones that are used for fragments, with a NULL pointer as skb: - We have a NULL physical address when calling DMA unmap - skb_headlen(skb) crashes because skb is NULL This causes random crashes when fragments are used. To solve this problem, we need to: - Store the physical address of the buffer to be unmapped unconditionally, regardless of whether it is tied to a SKB or not. - Store the length of the buffer to be unmapped, which requires a new field. Instead of adding a third array to store the length of the buffer to be unmapped, and as suggested by David Miller, this commit refactors the tx_buffs[] and tx_skb[] arrays of 'struct mvpp2_txq_pcpu' into a separate structure 'mvpp2_txq_pcpu_buf', to which a 'size' field is added. Therefore, instead of having three arrays to allocate/free, we have a single one, which also improve data locality, reducing the impact on the CPU cache. Fixes: 71ce391d ("net: mvpp2: enable proper per-CPU TX buffers unmapping") Reported-by:
Raphael G <raphael.glon@corp.ovh.com> Cc: Raphael G <raphael.glon@corp.ovh.com> Signed-off-by:
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Al Viro authored
commit 128394ef upstream. Both damn things interpret userland pointers embedded into the payload; worse, they are actually traversing those. Leaving aside the bad API design, this is very much _not_ safe to call with KERNEL_DS. Bail out early if that happens. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Ben Hutchings authored
commit 79e51b5c upstream. Currently it is impossible to edit the value of a config symbol with a prompt longer than (terminal width - 2) characters. dialog_inputbox() calculates a negative x-offset for the input window and newwin() fails as this is invalid. It also doesn't check for this failure, so it busy-loops calling wgetch(NULL) which immediately returns -1. The additions in the offset calculations also don't match the intended size of the window. Limit the window size and calculate the offset similarly to show_scroll_win(). Fixes: 692d97c3 ("kconfig: new configuration interface (nconfig)") Signed-off-by:
Ben Hutchings <ben.hutchings@codethink.co.uk> Signed-off-by:
-
Andy Grover authored
commit d0905ca7 upstream. Don't free the cmd in tcmu_check_expired_cmd, it's still referenced by an entry in our cmd_id->cmd idr. If userspace ever resumes processing, tcmu_handle_completions() will use the now-invalid cmd pointer. Instead, don't free cmd. It will be freed by tcmu_handle_completion() if userspace ever recovers, or tcmu_free_device if not. Reported-by:
Bryant G Ly <bgly@us.ibm.com> Tested-by:
Andy Grover <agrover@redhat.com> Signed-off-by:
Bart Van Assche <bart.vanassche@sandisk.com> Signed-off-by:
-
Dan Williams authored
commit af7d9f0c upstream. Fix the format specifier so that the attribute can be parsed correctly. Currently it returns decimal 1000 for a 4096-byte alignment. Reported-by:
Dave Jiang <dave.jiang@intel.com> Fixes: 315c5625 ("libnvdimm, pfn: add 'align' attribute, default to HPAGE_SIZE") Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
-
David Daney authored
commit b6cc9474 upstream. On arm64 NUMA kernels we can pass "numa=off" on the command line to disable NUMA. A side effect of this is that kmalloc_node() calls to non-zero nodes will crash the system with an OOPS: [ 0.000000] ITS@0x0000901000020000: allocated 2097152 Devices @10002000000 (flat, esz 8, psz 64K, shr 1) [ 0.000000] Unable to handle kernel NULL pointer dereference at virtual address 00001680 [ 0.000000] pgd = fffffc0009470000 [ 0.000000] [00001680] *pgd=0000010ffff90003, *pud=0000010ffff90003, *pmd=0000010ffff90003, *pte=0000000000000000 [ 0.000000] Internal error: Oops: 96000006 [#1] SMP . . . [ 0.000000] [<fffffc00081c8950>] __alloc_pages_nodemask+0xa4/0xe68 [ 0.000000] [<fffffc000821fa70>] new_slab+0xd0/0x564 [ 0.000000] [<fffffc0008221e24>] ___slab_alloc+0x2e4/0x514 [ 0.000000] [<fffffc0008239498>] __slab_alloc+0x48/0x58 [ 0.000000] [<fffffc0008222c20>] __kmalloc_node+0xd0/0x2dc [ 0.000000] [<fffffc0008115374>] __irq_domain_add+0x7c/0x164 [ 0.000000] [<fffffc0008b461dc>] its_probe+0x784/0x81c [ 0.000000] [<fffffc0008b462bc>] its_init+0x48/0x1b0 [ 0.000000] [<fffffc0008b4543c>] gic_init_bases+0x228/0x360 [ 0.000000] [<fffffc0008b456bc>] gic_of_init+0x148/0x1cc [ 0.000000] [<fffffc0008b5aec8>] of_irq_init+0x184/0x298 [ 0.000000] [<fffffc0008b43f9c>] irqchip_init+0x14/0x38 [ 0.000000] [<fffffc0008b12d60>] init_IRQ+0xc/0x30 [ 0.000000] [<fffffc0008b10a3c>] start_kernel+0x240/0x3b8 [ 0.000000] [<fffffc0008b101c4>] __primary_switched+0x30/0x6c [ 0.000000] Code: 912ec2a0 b9403809 0a0902fb 37b007db (f9400300) . . . This is caused by code like this in kernel/irq/irqdomain.c domain = kzalloc_node(sizeof(*domain) + (sizeof(unsigned int) * size), GFP_KERNEL, of_node_to_nid(of_node)); When NUMA is disabled, the concept of a node is really undefined, so of_node_to_nid() should unconditionally return NUMA_NO_NODE. Fix by returning NUMA_NO_NODE when the nid is not in the set of possible nodes. Reported-by:
Gilbert Netzer <noname@pdc.kth.se> Signed-off-by:
David Daney <david.daney@cavium.com> Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Nicholas Piggin authored
commit ff45000f upstream. The boot wrapper performs its own relocations and does not require PT_INTERP segment. However currently we don't tell the linker that. Prior to binutils 2.28 that works OK. But since binutils commit 1a9ccd70f9a7 ("Fix the linker so that it will not silently generate ELF binaries with invalid program headers. Fix readelf to report such invalid binaries.") binutils tries to create a program header segment due to PT_INTERP, and the link fails because there is no space for it: ld: arch/powerpc/boot/zImage.pseries: Not enough room for program headers, try linking with -N ld: final link failed: Bad value So tell the linker not to do that, by passing --no-dynamic-linker. Reported-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
Nicholas Piggin <npiggin@gmail.com> [mpe: Drop dependency on ld-version.sh and massage change log] Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Geoff Levand authored
commit 6dff5b67 upstream. GCC 5 generates different code for this bootwrapper null check that causes the PS3 to hang very early in its bootup. This check is of limited value, so just get rid of it. Signed-off-by:
Geoff Levand <geoff@infradead.org> Signed-off-by:
-
Nicholas Piggin authored
commit f87f253b upstream. From 80f23935 ("powerpc: Convert cmp to cmpd in idle enter sequence"): PowerPC's "cmp" instruction has four operands. Normally people write "cmpw" or "cmpd" for the second cmp operand 0 or 1. But, frequently people forget, and write "cmp" with just three operands. With older binutils this is silently accepted as if this was "cmpw", while often "cmpd" is wanted. With newer binutils GAS will complain about this for 64-bit code. For 32-bit code it still silently assumes "cmpw" is what is meant. In this case, cmpwi is called for, so this is just a build fix for new toolchains. Signed-off-by:
-
NeilBrown authored
commit 1cded9d2 upstream. There are two problems with refcounting of auth_gss messages. First, the reference on the pipe->pipe list (taken by a call to rpc_queue_upcall()) is not counted. It seems to be assumed that a message in pipe->pipe will always also be in pipe->in_downcall, where it is correctly reference counted. However there is no guaranty of this. I have a report of a NULL dereferences in rpc_pipe_read() which suggests a msg that has been freed is still on the pipe->pipe list. One way I imagine this might happen is: - message is queued for uid=U and auth->service=S1 - rpc.gssd reads this message and starts processing. This removes the message from pipe->pipe - message is queued for uid=U and auth->service=S2 - rpc.gssd replies to the first message. gss_pipe_downcall() calls __gss_find_upcall(pipe, U, NULL) and it finds the *second* message, as new messages are placed at the head of ->in_downcall, and the service type is not checked. - This second message is removed from ->in_downcall and freed by gss_release_msg() (even though it is still on pipe->pipe) - rpc.gssd tries to read another message, and dereferences a pointer to this message that has just been freed. I fix this by incrementing the reference count before calling rpc_queue_upcall(), and decrementing it if that fails, or normally in gss_pipe_destroy_msg(). It seems strange that the reply doesn't target the message more precisely, but I don't know all the details. In any case, I think the reference counting irregularity became a measureable bug when the extra arg was added to __gss_find_upcall(), hence the Fixes: line below. The second problem is that if rpc_queue_upcall() fails, the new message is not freed. gss_alloc_msg() set the ->count to 1, gss_add_msg() increments this to 2, gss_unhash_msg() decrements to 1, then the pointer is discarded so the memory never gets freed. Fixes: 9130b8db ("SUNRPC: allow for upcalls for same uid but different gss service") Link: https://bugzilla.opensuse.org/show_bug.cgi?id=1011250Signed-off-by:
NeilBrown <neilb@suse.com> Signed-off-by:
Trond Myklebust <trond.myklebust@primarydata.com> Signed-off-by:
-
Trond Myklebust authored
commit 54e4a0df upstream. We must not call nfs_pageio_init_read() on a new nfs_pageio_descriptor while holding a reference to a layout segment, as that can deadlock pnfs_update_layout(). Fixes: d67ae825 ("pnfs/flexfiles: Add the FlexFile Layout Driver") Signed-off-by:
-
Trond Myklebust authored
commit ae5a459d upstream. We must ensure that we don't schedule a layoutreturn if the layout stateid has been marked as invalid. Fixes: 2a59a041 ("pNFS: Fix pnfs_set_layout_stateid() to clear...") Signed-off-by:
-
Trond Myklebust authored
commit 7b650994 upstream. If we no longer hold any layout segments, we're normally expected to consider the layout stateid to be invalid. However we cannot assume this if we're about to, or in the process of sending a layoutreturn. Fixes: 334a8f37 ("pNFS: Don't forget the layout stateid if...") Signed-off-by:
-
Trond Myklebust authored
commit 6604b203 upstream. If there is an I/O error, we should not call LAYOUTGET until the LAYOUTRETURN that reports the error is complete. Signed-off-by:
-
Al Viro authored
commit c0cf3ef5 upstream. What matters when deciding if we should make a page uptodate is not how much we _wanted_ to copy, but how much we actually have copied. As it is, on architectures that do not zero tail on short copy we can leave uninitialized data in page marked uptodate. Signed-off-by:
-
Ilya Dryomov authored
commit 5c056fdc upstream. After sending an authorizer (ceph_x_authorize_a + ceph_x_authorize_b), the client gets back a ceph_x_authorize_reply, which it is supposed to verify to ensure the authenticity and protect against replay attacks. The code for doing this is there (ceph_x_verify_authorizer_reply(), ceph_auth_verify_authorizer_reply() + plumbing), but it is never invoked by the the messenger. AFAICT this goes back to 2009, when ceph authentication protocols support was added to the kernel client in 4e7a5dcd ("ceph: negotiate authentication protocol; implement AUTH_NONE protocol"). The second param of ceph_connection_operations::verify_authorizer_reply is unused all the way down. Pass 0 to facilitate backporting, and kill it in the next commit. Signed-off-by:
Ilya Dryomov <idryomov@gmail.com> Reviewed-by:
Sage Weil <sage@redhat.com> Signed-off-by:
-
Alan Stern authored
commit 6496ebd7 upstream. One some systems, the firmware does not allow certain PCI devices to be put in deep D-states. This can cause problems for wakeup signalling, if the device does not support PME# in the deepest allowed suspend state. For example, Pierre reports that on his system, ACPI does not permit his xHCI host controller to go into D3 during runtime suspend -- but D3 is the only state in which the controller can generate PME# signals. As a result, the controller goes into runtime suspend but never wakes up, so it doesn't work properly. USB devices plugged into the controller are never detected. If the device relies on PME# for wakeup signals but is not capable of generating PME# in the target state, the PCI core should accurately report that it cannot do wakeup from runtime suspend. This patch modifies the pci_dev_run_wake() routine to add this check. Reported-by:
Pierre de Villemereuil <flyos@mailoo.org> Tested-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Acked-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> CC: Lukas Wunner <lukas@wunner.de> Signed-off-by:
-
Shiraz Saleem authored
commit 91c42b72 upstream. hw_stats is a pointer to i40_iw_dev_stats struct in i40iw_get_hw_stats(). Use hw_stats and not &hw_stats in the memcpy to copy the i40iw device stats data into rdma_hw_stats counters. Fixes: b40f4757 ("IB/core: Make device counter infrastructure dynamic") Signed-off-by:
Shiraz Saleem <shiraz.saleem@intel.com> Signed-off-by:
Faisal Latif <faisal.latif@intel.com> Signed-off-by:
Doug Ledford <dledford@redhat.com> Signed-off-by:
-
Miklos Szeredi authored
commit 3f9ca755 upstream. New inode operations were forgotten to be added to bad_inode. Most of the time the op is checked for NULL before being called but marking the inode bad and the check can race (very unlikely). However in case of ->get_link() only DCACHE_SYMLINK_TYPE is checked before calling the op, so there's no race and will definitely oops when trying to follow links on such a beast. Also remove comments about extinct ops. Signed-off-by:
Miklos Szeredi <mszeredi@redhat.com> Signed-off-by:
-
Jingkui Wang authored
commit 5a8a6b89 upstream. We were assigning I2C bus controller instead of client as parent device. Besides being logically wrong, it messed up with devm handling of input device. As a result we were leaving input device and event node behind after rmmod-ing the driver, which lead to a kernel oops if one were to access the event node later. Let's remove the assignment and rely on devm_input_allocate_device() to set it up properly for us. Signed-off-by:
Jingkui Wang <jkwang@google.com> Fixes: 7132fe4f ("Input: drv260x - add TI drv260x haptics driver") Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Laurent Pinchart authored
commit d183e4ef upstream. A break is missing resulting in the hue control enabling or disabling the decode completely. Fix it. Fixes: c43875f6 ("[media] tvp5150: replace MEDIA_ENT_F_CONN_TEST by a control") Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com> Signed-off-by:
-
Andrey Utkin authored
commit 5fc4b067 upstream. This fixes a lockup at device probing which happens on some solo6010 hardware samples. This is a regression introduced by commit e1ceb25a ("[media] SOLO6x10: remove unneeded register locking and barriers") The observed lockup happens in solo_set_motion_threshold() called from solo_motion_config(). This extra "flushing" is not fundamentally needed for every write, but apparently the code in driver assumes such behaviour at last in some places. Actual fix was proposed by Hans Verkuil. Fixes: e1ceb25a ("[media] SOLO6x10: remove unneeded register locking and barriers") Signed-off-by:
Andrey Utkin <andrey.utkin@corp.bluecherry.net> Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
-
