| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma
Pull rdma fixes from Doug Ledford:
"One ocrdma fix:
- The new CQ API support was added to ocrdma, but they got the arming
logic wrong, so without this, transfers eventually fail when they
fail to arm the interrupt properly under load
Two related fixes for mlx4:
- When we added the 64bit extended counters support to the core IB
code, they forgot to update the RoCE side of the mlx4 driver (the
IB side they properly updated).
I debated whether or not to include these patches as they could be
considered feature enablement patches, but the existing code will
blindy copy the 32bit counters, whether any counters were requested
at all (a bug).
These two patches make it (a) check to see that counters were
requested and (b) copy the right counters (the 64bit support is
new, the 32bit is not). For that reason I went ahead and took
them"
* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma:
IB/mlx4: Add support for the port info class for RoCE ports
IB/mlx4: Add support for extended counters over RoCE ports
RDMA/ocrdma: Fix arm logic to align with new cq API
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux
Pull i2c fixes from Wolfram Sang:
"Some bugfixes from I2C for you:
A fix for a RuntimePM regression with OMAP, a fix to enable TCO for
Lewisburg platforms, and a typo fix while we are here"
* 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
i2c: i801: Adding Intel Lewisburg support for iTCO
i2c: uniphier: fix typos in error messages
i2c: omap: Fix PM regression with deferred probe for pm_runtime_reinit
|
|
It has been observed that sometimes disabling the dc6 fails
and dc6 state pops back up, brief moment after disabling. This
has to be dmc save/restore timing issue or other bug in the
way dc states are handled.
Try to work around this issue as we don't have firmware fix
yet available. Verify that the value we wrote for the dmc sticks,
and also enforce it by rewriting it, if it didn't.
v2: Zero rereads on rewrite for extra paranoia (Imre)
Testcase: kms_flip/basic-flip-vs-dpms
References: https://bugs.freedesktop.org/show_bug.cgi?id=93768
Cc: Patrik Jakobsson <[email protected]>
Cc: Rodrigo Vivi <[email protected]>
Cc: Imre Deak <[email protected]>
Signed-off-by: Mika Kuoppala <[email protected]>
Reviewed-by: Imre Deak <[email protected]>
Signed-off-by: Imre Deak <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
(cherry picked from commit 779cb5d3ddd72950ec726f86e38f7575c7fbdd4c)
Signed-off-by: Jani Nikula <[email protected]>
|
|
The DMC can incorrectly run off and allow DC states on it's own. We
don't know the root-cause for this yet but this patch makes it more
visible.
Reviewed-by: Mika Kuoppala <[email protected]>
Signed-off-by: Patrik Jakobsson <[email protected]>
Signed-off-by: Imre Deak <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
(cherry picked from commit 832dba889e27487c3087149f1039acc3feb89003)
Signed-off-by: Jani Nikula <[email protected]>
|
|
set_power_state defaults to no displays, so we need to update
the display configuration after setting up the powerstate on the
first call. In most cases this is not an issue since ends up
getting called multiple times at any given modeset and the proper
order is achieved in the display changed handling at the top of
the function.
Reviewed-by: Christian König <[email protected]>
Acked-by: Jordan Lazare <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Cc: [email protected]
|
|
set_power_state defaults to no displays, so we need to update
the display configuration after setting up the powerstate on the
first call. In most cases this is not an issue since ends up
getting called multiple times at any given modeset and the proper
order is achieved in the display changed handling at the top of
the function.
Reviewed-by: Christian König <[email protected]>
Acked-by: Jordan Lazare <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Cc: [email protected]
|
|
I.e., doesn't make sense to change power states or check the
temperature when the asic is powered off.
Reviewed-by: Christian König <[email protected]>
Acked-by: Harry Wentland <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
|
|
Looks like a copy paste typo when we added powerplay
support.
Reviewed-by: Christian König <[email protected]>
Acked-by: Harry Wentland <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
|
|
Looks like a copy/paste typo.
Reviewed-by: Christian König <[email protected]>
Noticed-by: David Panariti <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
|
|
The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
Spotted-by: Mika Kuoppala <[email protected]>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93441
CC: Chris Wilson <[email protected]>
Signed-off-by: Imre Deak <[email protected]>
Reviewed-by: Mika Kuoppala <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
(cherry picked from commit 4d800030238878c1a98d1d3a37a3d673eea661ce)
Signed-off-by: Jani Nikula <[email protected]>
|
|
The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
Signed-off-by: Imre Deak <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
(cherry picked from commit ecb2448218acf23c401434c26be256147833b221)
Signed-off-by: Jani Nikula <[email protected]>
|
|
The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
Signed-off-by: Imre Deak <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
(cherry picked from commit 5b0921748c0b1d0362bbfa802dc25a5c23de7e76)
Signed-off-by: Jani Nikula <[email protected]>
|
|
The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
Signed-off-by: Imre Deak <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
(cherry picked from commit 3f3f42b887fbffc3353e44ef9f32456c19ae4280)
Signed-off-by: Jani Nikula <[email protected]>
|
|
The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
Signed-off-by: Imre Deak <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
(cherry picked from commit 6fa9a5ecf7a54450b255229ac1fc6df276cf0653)
Signed-off-by: Jani Nikula <[email protected]>
|
|
The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
While at it also add the missing reference around the HW access in
i915_interrupt_info().
v2:
- update the commit message mentioning that this also fixes the
HW access in the interrupt info debugfs entry (Daniel)
Signed-off-by: Imre Deak <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
(cherry picked from commit e129649b7a3e1d50d196e159492496777769437e)
Signed-off-by: Jani Nikula <[email protected]>
|
|
The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
CC: Chris Wilson <[email protected]>
Signed-off-by: Imre Deak <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
(cherry picked from commit e27daab49718e3232318d8b539cb302521b4b724)
Signed-off-by: Jani Nikula <[email protected]>
|
|
The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93439
CC: Chris Wilson <[email protected]>
Signed-off-by: Imre Deak <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
(cherry picked from commit 1c8fdda1ea947ae8cf994969a1c285acc7089cb9)
Signed-off-by: Jani Nikula <[email protected]>
|
|
The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
Signed-off-by: Imre Deak <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
(cherry picked from commit 4feed0ebfa45879bc422c9a0bfa3cffec82ea60a)
Signed-off-by: Jani Nikula <[email protected]>
|
|
The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
Signed-off-by: Imre Deak <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
(cherry picked from commit 6392f8478e6f119467b1ad06e30e1f078e62efc1)
Signed-off-by: Jani Nikula <[email protected]>
|
|
The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
Signed-off-by: Imre Deak <[email protected]>
Reviewed-by: Mika Kuoppala <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
(cherry picked from commit 12fda3876d08519bdf6f0acc70dd35754b422ed5)
Signed-off-by: Jani Nikula <[email protected]>
|
|
The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
Signed-off-by: Imre Deak <[email protected]>
Revieved-by: Mika Kuoppala <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
(cherry picked from commit 1729050eb4bbc192e54069e82069f2811313c1dd)
Signed-off-by: Jani Nikula <[email protected]>
|
|
We have many places in the code where we check if a given display power
domain is enabled and if so access registers backed by this power
domain. We assumed that some modeset lock will prevent the power
reference from vanishing in the middle of the HW access, but this
assumption doesn't always hold. In such cases we get either the wakeref
not held, or an unclaimed register access error message. To fix this in
a future-proof way that's independent of other locks wrap any such
access with a get_ref_if_enabled()/put_ref() pair.
Kudos to Ville and Joonas for the ideas of this new interface.
v2:
- init the power_domains ptr when declaring it everywhere (Joonas)
v3:
- don't report the device to be powered if runtime PM is disabled
CC: Mika Kuoppala <[email protected]>
CC: Chris Wilson <[email protected]>
CC: Joonas Lahtinen <[email protected]>
CC: Ville Syrjälä <[email protected]>
Signed-off-by: Imre Deak <[email protected]>
Reviewed-by: Joonas Lahtinen <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
(cherry picked from commit 09731280028ce03e6a27e1998137f1775a2839f3)
Signed-off-by: Jani Nikula <[email protected]>
|
|
git commit 904818e2f229f3d94ec95f6932a6358c81e73d78
"s390/kernel: introduce fpu-internal.h with fpu helper functions"
introduced the fpregs_store / fp_regs_load helper. These function
fail to save and restore the floating pointer control registers.
The effect is that the FPC is not correctly handled on signal
delivery and signal return.
Cc: [email protected] # 4.4
Signed-off-by: Martin Schwidefsky <[email protected]>
|
|
git commit 8070361799ae1e3f4ef347bd10f0a508ac10acfb
"s390: add support for vector extension"
broke 31-bit compat processes in regard to signal handling.
The restore_sigregs_ext32() function is used to restore the additional
elements from the user space signal frame. Among the additional elements
are the upper registers halves for 64-bit register support for 31-bit
processes. The copy_from_user that is used to retrieve the high-gprs
array from the user stack uses an incorrect length, 8 bytes instead of
64 bytes. This causes incorrect upper register halves to get loaded.
Cc: [email protected] # 3.8+
Signed-off-by: Martin Schwidefsky <[email protected]>
|
|
We can get a hash pte fault with 4k base page size and find the pte
already inserted with 64K base page size. In that case we need to clear
the existing slot information from the old pte. Fix this correctly
With THP, we also clear the slot information with respect to all
the 64K hash pte mapping that 16MB page. They are all invalid
now. This make sure we don't find the slot valid when we fault with
4k base page size. Finding the slot valid should not result in any wrong
behavior because we do check again in hash page table for the validity.
But we can avoid that check completely.
Fixes: a43c0eb8364c022 ("powerpc/mm: Convert 4k hash insert to C")
Signed-off-by: Aneesh Kumar K.V <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
|
|
During error recovery, the device could be removed as part of the
partial hotplug. The criterion used to come with partial hotplug
is: if the device driver provides error_detected(), slot_reset()
and resume() callbacks, it's immune from hotplug. Otherwise,
it's going to experience partial hotplug during EEH recovery. But
the criterion isn't correct enough: mlx4_core driver for Mellanox
adapters provides error_detected(), slot_reset() callbacks, but
resume() isn't there. Those Mellanox adapters won't be to involved
in the partial hotplug.
This fixes the criterion to a practical one: adpater with driver
that provides error_detected(), slot_reset() will be immune from
partial hotplug. resume() isn't mandatory.
Fixes: f2da4ccf ("powerpc/eeh: More relaxed hotplug criterion")
Cc: [email protected] #v4.4+
Signed-off-by: Gavin Shan <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can
Marc Kleine-Budde says:
====================
pull-request: can 2016-02-21
this is a pull reqeust of one patch for net/master.
The patch is by Gerhard Uttenthaler and fixes a potential tx overflow in the
ems_usb driver.
====================
Signed-off-by: David S. Miller <[email protected]>
|
|
Yuval Mintz says:
====================
bnx2x: Fix 848xx phys
This series contains link-related fixes, mostly for the 848xx phys
[2 patches are for 84833, and 2 patches are for 84858].
====================
Signed-off-by: David S. Miller <[email protected]>
|
|
Current initialization sequence is lacking, causing some configurations
to fail.
Signed-off-by: Yuval Mintz <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Signed-off-by: Yuval Mintz <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
The phy's firmware version isn't being parsed properly as it's
currently parsed like the rest of the 848xx phys.
Signed-off-by: Yuval Mintz <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
There's a problem in current 84833 phy configuration -
in case 1Gb link is configured and jumbo-sized packets are being
used, device will experience RX crc errors.
Signed-off-by: Yuval Mintz <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Currently, when link is using KR2 it cannot be forced to any speed other
than 20g.
Signed-off-by: Yuval Mintz <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth
Johan Hedberg says:
====================
pull request: bluetooth 2016-02-20
Here's an important patch for 4.5 which fixes potential invalid pointer
access when processing completed Bluetooth HCI commands.
Please let me know if there are any issues pulling. Thanks.
====================
Signed-off-by: David S. Miller <[email protected]>
|
|
The dm9000 driver doesn't work in at least one device-tree
configuration, spitting an error message on irq resource :
[ 1.062495] dm9000 8000000.ethernet: insufficient resources
[ 1.068439] dm9000 8000000.ethernet: not found (-2).
[ 1.073451] dm9000: probe of 8000000.ethernet failed with error -2
The reason behind is that the interrupt might be provided by a gpio
controller, not probed when dm9000 is probed, and needing the probe
deferral mechanism to apply.
Currently, the interrupt is directly taken from resources. This patch
changes this to use the more generic platform_get_irq(), which handles
the deferral.
Moreover, since commit Fixes: 7085a7401ba5 ("drivers: platform: parse
IRQ flags from resources"), the interrupt trigger flags are honored in
platform_get_irq(), so remove the needless code in dm9000.
Signed-off-by: Robert Jarzmik <[email protected]>
Acked-by: Marcel Ziswiler <[email protected]>
Cc: Sergei Shtylyov <[email protected]>
Tested-by: Sergei Ianovich <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
address
fix incorrect indexing of dev->dev_addr[] when copying the MAC address
of FMV-J182 at buf[5].
Signed-off-by: Ken Kawasaki <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Device emulation supports max size of 4096.
Signed-off-by: Shrikrishna Khare <[email protected]>
Signed-off-by: Bhavesh Davda <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Murali Karicheri says:
====================
net: ti: netcp: restore get/set_pad_info() functionality
This series fixes a regression and add some improvements for the ease
of maintainance. Incorporated comments against v1.
Changelogs:
v2 : combined 2-3 into one patch as this involves a header change
fixed a parse warning in 3/4 per comment from Arnd.
Removed Sign-off from Arnd against 1/4
added comments in 3/3 to alert on the usage of sw data per review
comments
v1 : added 2-4 to accomodate feedback received from review
v0 : initial version to fix the regression (From Grygorii)
====================
Signed-off-by: David S. Miller <[email protected]>
|
|
SW data field in descriptor can be used by software to hold private
data for the driver. As there are 4 words available for this purpose,
use separate macros to place it or retrieve the same to/from
descriptors. Also do type cast of data types accordingly.
Cc: Wingman Kwok <[email protected]>
Cc: Mugunthan V N <[email protected]>
CC: Arnd Bergmann <[email protected]>
CC: Grygorii Strashko <[email protected]>
CC: David Laight <[email protected]>
Signed-off-by: Murali Karicheri <[email protected]>
Acked-by: Arnd Bergmann <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Rename the pad to sw_data as per description of this field in the hardware
spec(refer sprugr9 from www.ti.com). Latest version of the document is
at http://www.ti.com/lit/ug/sprugr9h/sprugr9h.pdf and section 3.1
Host Packet Descriptor describes this field.
Define and use a constant for the size of sw_data field similar to
other fields in the struct for desc and document the sw_data field
in the header. As the sw_data is not touched by hw, it's type can be
changed to u32.
Rename the helpers to match with the updated dma desc field sw_data.
Cc: Wingman Kwok <[email protected]>
Cc: Mugunthan V N <[email protected]>
CC: Arnd Bergmann <[email protected]>
CC: Grygorii Strashko <[email protected]>
CC: David Laight <[email protected]>
Signed-off-by: Murali Karicheri <[email protected]>
Acked-by: Arnd Bergmann <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
The commit 899077791403 ("netcp: try to reduce type confusion in
descriptors") introduces a regression in Kernel 4.5-rc1 and it breaks
get/set_pad_info() functionality.
The TI NETCP driver uses pad0 and pad1 fields of knav_dma_desc to
store DMA/MEM buffer pointer and buffer size respectively. And in both
cases for Keystone 2 the pointer type size is 32 bit regardless of
LAPE enabled or not, because CONFIG_ARCH_DMA_ADDR_T_64BIT originally
is not expected to be defined.
Unfortunately, above commit changed buffer's pointers save/restore
code (get/set_pad_info()) and added intermediate conversation to u64
which works incorrectly on 32bit Keystone 2 and causes TI NETCP driver
crash in RX/TX path due to "Unable to handle kernel NULL pointer"
exception. This issue was reported and discussed in [1].
Hence, fix it by partially reverting above commit and restoring
get/set_pad_info() functionality as it was before.
[1] https://www.mail-archive.com/[email protected]/msg95361.html
Cc: Wingman Kwok <[email protected]>
Cc: Mugunthan V N <[email protected]>
CC: David Laight <[email protected]>
CC: Arnd Bergmann <[email protected]>
Reported-by: Franklin S Cooper Jr <[email protected]>
Signed-off-by: Grygorii Strashko <[email protected]>
Signed-off-by: Murali Karicheri <[email protected]>
Acked-by: Arnd Bergmann <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Wei has been picking this up for quite a while now.
Signed-off-by: Ian Campbell <[email protected]>
Cc: Wei Liu <[email protected]>
Acked-by: Wei Liu <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Dmitry Vyukov noted recently that the sctp_port_hashtable had an error in
its size computation, observing that the current method never guaranteed
that the hashsize (measured in number of entries) would be a power of two,
which the input hash function for that table requires. The root cause of
the problem is that two values need to be computed (one, the allocation
order of the storage requries, as passed to __get_free_pages, and two the
number of entries for the hash table). Both need to be ^2, but for
different reasons, and the existing code is simply computing one order
value, and using it as the basis for both, which is wrong (i.e. it assumes
that ((1<<order)*PAGE_SIZE)/sizeof(bucket) is still ^2 when its not).
To fix this, we change the logic slightly. We start by computing a goal
allocation order (which is limited by the maximum size hash table we want
to support. Then we attempt to allocate that size table, decreasing the
order until a successful allocation is made. Then, with the resultant
successful order we compute the number of buckets that hash table supports,
which we then round down to the nearest power of two, giving us the number
of entries the table actually supports.
I've tested this locally here, using non-debug and spinlock-debug kernels,
and the number of entries in the hashtable consistently work out to be
powers of two in all cases.
Signed-off-by: Neil Horman <[email protected]>
Reported-by: Dmitry Vyukov <[email protected]>
CC: Dmitry Vyukov <[email protected]>
CC: Vladislav Yasevich <[email protected]>
CC: "David S. Miller" <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Using request-based DM mpath configured with the following stacking
(.request_fn DM mpath ontop of scsi-mq paths):
echo Y > /sys/module/scsi_mod/parameters/use_blk_mq
echo N > /sys/module/dm_mod/parameters/use_blk_mq
'struct dm_rq_target_io' would leak if a request is requeued before a
blk-mq clone is allocated (or fails to allocate). free_rq_tio()
wasn't being called.
kmemleak reported:
unreferenced object 0xffff8800b90b98c0 (size 112):
comm "kworker/7:1H", pid 5692, jiffies 4295056109 (age 78.589s)
hex dump (first 32 bytes):
00 d0 5c 2c 03 88 ff ff 40 00 bf 01 00 c9 ff ff ..\,....@.......
e0 d9 b1 34 00 88 ff ff 00 00 00 00 00 00 00 00 ...4............
backtrace:
[<ffffffff81672b6e>] kmemleak_alloc+0x4e/0xb0
[<ffffffff811dbb63>] kmem_cache_alloc+0xc3/0x1e0
[<ffffffff8117eae5>] mempool_alloc_slab+0x15/0x20
[<ffffffff8117ec1e>] mempool_alloc+0x6e/0x170
[<ffffffffa00029ac>] dm_old_prep_fn+0x3c/0x180 [dm_mod]
[<ffffffff812fbd78>] blk_peek_request+0x168/0x290
[<ffffffffa0003e62>] dm_request_fn+0xb2/0x1b0 [dm_mod]
[<ffffffff812f66e3>] __blk_run_queue+0x33/0x40
[<ffffffff812f9585>] blk_delay_work+0x25/0x40
[<ffffffff81096fff>] process_one_work+0x14f/0x3d0
[<ffffffff81097715>] worker_thread+0x125/0x4b0
[<ffffffff8109ce88>] kthread+0xd8/0xf0
[<ffffffff8167cb8f>] ret_from_fork+0x3f/0x70
[<ffffffffffffffff>] 0xffffffffffffffff
crash> struct -o dm_rq_target_io
struct dm_rq_target_io {
...
}
SIZE: 112
Fixes: e5863d9ad7 ("dm: allocate requests in target when stacking on blk-mq devices")
Cc: [email protected] # 4.0+
Signed-off-by: Mike Snitzer <[email protected]>
|
|
Patch <703df6c09795> ("power: bq27xxx_battery: Reorganize I2C
into a module") has removed the device name numbering from
bq27xxx_battery_i2c_probe. Fix that by restoring the code.
Fixes: 703df6c097956d17a818e63961c82e8e9eef9fef
Signed-off-by: Ivaylo Dimitrov <[email protected]>
Reviewed-by: Pali Rohár <[email protected]>
Tested-by: Pali Rohár <[email protected]>
Signed-off-by: Sebastian Reichel <[email protected]>
|
|
Update reviewers for bq27xxx, so that Pali and Andrew
are reviewers with status and maintainer inherited from
the power supply subsystem entry.
Signed-off-by: Sebastian Reichel <[email protected]>
Acked-by: Pali Rohár <[email protected]>
Acked-by: Andrew F. Davis <[email protected]>
|
|
This patch fixes the problem that more CAN messages could be sent to the
interface as could be send on the CAN bus. This was more likely for slow baud
rates. The sleeping _start_xmit was woken up in the _write_bulk_callback. Under
heavy TX load this produced another bulk transfer without checking the
free_slots variable and hence caused the overflow in the interface.
Signed-off-by: Gerhard Uttenthaler <[email protected]>
Cc: linux-stable <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
|
|
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fixes from Ingo Molnar:
"This is unusually large, partly due to the EFI fixes that prevent
accidental deletion of EFI variables through efivarfs that may brick
machines. These fixes are somewhat involved to maintain compatibility
with existing install methods and other usage modes, while trying to
turn off the 'rm -rf' bricking vector.
Other fixes are for large page ioremap()s and for non-temporal
user-memcpy()s"
* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/mm: Fix vmalloc_fault() to handle large pages properly
hpet: Drop stale URLs
x86/uaccess/64: Handle the caching of 4-byte nocache copies properly in __copy_user_nocache()
x86/uaccess/64: Make the __copy_user_nocache() assembly code more readable
lib/ucs2_string: Correct ucs2 -> utf8 conversion
efi: Add pstore variables to the deletion whitelist
efi: Make efivarfs entries immutable by default
efi: Make our variable validation list include the guid
efi: Do variable name validation tests in utf8
efi: Use ucs2_as_utf8 in efivarfs instead of open coding a bad version
lib/ucs2_string: Add ucs2 -> utf8 helper functions
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull perf fixes from Ingo Molnar:
"A handful of CPU hotplug related fixes"
* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
perf/core: Plug potential memory leak in CPU_UP_PREPARE
perf/core: Remove the bogus and dangerous CPU_DOWN_FAILED hotplug state
perf/core: Remove bogus UP_CANCELED hotplug state
perf/x86/amd/uncore: Plug reference leak
|