Vasundhara Volam [Thu, 4 Oct 2018 05:43:48 +0000 (11:13 +0530)]
bnxt_en: return proper error when FW returns HWRM_ERR_CODE_RESOURCE_ACCESS_DENIED
[ Upstream commit
3a1d52a54a6a4030b294e5f5732f0bfbae0e3815 ]
Return proper error code when Firmware returns
HWRM_ERR_CODE_RESOURCE_ACCESS_DENIED for HWRM_NVM_GET/SET_VARIABLE
commands.
Cc: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Michael Pobega [Thu, 4 Oct 2018 18:58:21 +0000 (14:58 -0400)]
ALSA: hda/sigmatel - Disable automute for Elo VuPoint
[ Upstream commit
d153135e93a50cdb6f1b52e238909e9965b56056 ]
The Elo VuPoint 15MX has two headphone jacks of which neither work by
default. Disabling automute allows ALSA to work normally with the
speakers & left headphone jack.
Future pin configuration changes may be required in the future to get
the right headphone jack working in tandem.
Signed-off-by: Michael Pobega <mpobega@neverware.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jacopo Mondi [Mon, 17 Sep 2018 11:30:54 +0000 (07:30 -0400)]
media: i2c: adv748x: Support probing a single output
[ Upstream commit
eccf442ce156ec2b4e06b1239d5fdcb0c732f63f ]
Currently the adv748x driver will fail to probe unless both of its
output endpoints (TXA and TXB) are connected.
Make the driver support probing provided that there is at least one
input, and one output connected and protect the clean-up function from
accessing un-initialized fields.
Following patches will fix other uses of un-initialized TXs in the driver,
such as power management functions.
Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Niklas Söderlund [Wed, 26 Sep 2018 21:40:06 +0000 (17:40 -0400)]
media: rcar-vin: fix redeclaration of symbol
[ Upstream commit
4e673ed4e2bfac00b3c3043a84e007874c17c84d ]
When adding support for parallel subdev for Gen3 it was missed that the
symbol 'i' in rvin_group_link_notify() was already declared, remove the
dupe as it's only used as a loop variable this have no functional
change. This fixes warning:
rcar-core.c:117:52: originally declared here
rcar-core.c:173:30: warning: symbol 'i' shadows an earlier one
Fixes:
1284605dc821cebd ("media: rcar-vin: Handle parallel subdev in link_notify")
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Acked-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Nathan Chancellor [Fri, 21 Sep 2018 10:00:45 +0000 (06:00 -0400)]
media: pxa_camera: Fix check for pdev->dev.of_node
[ Upstream commit
44d7f1a77d8c84f8e42789b5475b74ae0e6d4758 ]
Clang warns that the address of a pointer will always evaluated as true
in a boolean context.
drivers/media/platform/pxa_camera.c:2400:17: warning: address of
'pdev->dev.of_node' will always evaluate to 'true'
[-Wpointer-bool-conversion]
if (&pdev->dev.of_node && !pcdev->pdata) {
~~~~~~~~~~^~~~~~~ ~~
1 warning generated.
Judging from the rest of the kernel, it seems like this was an error and
just the value of of_node should be checked rather than the address.
Reported-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Matthias Reichl [Tue, 28 Aug 2018 13:49:42 +0000 (09:49 -0400)]
media: rc: ir-rc6-decoder: enable toggle bit for Kathrein RCU-676 remote
[ Upstream commit
85e4af0a7ae2f146769b7475ae531bf8a3f3afb4 ]
The Kathrein RCU-676 remote uses the 32-bit rc6 protocol and toggles
bit 15 (0x8000) on repeated button presses, like MCE remotes.
Add it's customer code 0x80460000 to the 32-bit rc6 toggle
handling code to get proper scancodes and toggle reports.
Signed-off-by: Matthias Reichl <hias@horus.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Nathan Chancellor [Thu, 4 Oct 2018 16:39:20 +0000 (09:39 -0700)]
qed: Avoid implicit enum conversion in qed_ooo_submit_tx_buffers
[ Upstream commit
8fa74e3c49204bdf788d99ef71840490cccc210d ]
Clang warns when one enumerated type is implicitly converted to another.
drivers/net/ethernet/qlogic/qed/qed_ll2.c:799:32: warning: implicit
conversion from enumeration type 'enum core_tx_dest' to different
enumeration type 'enum qed_ll2_tx_dest' [-Wenum-conversion]
tx_pkt.tx_dest = p_ll2_conn->tx_dest;
~ ~~~~~~~~~~~~^~~~~~~
1 warning generated.
Fix this by using a switch statement to convert between the enumerated
values since they are not 1 to 1, which matches how the rest of the
driver handles this conversion.
Link: https://github.com/ClangBuiltLinux/linux/issues/125
Suggested-by: Tomer Tayar <Tomer.Tayar@cavium.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Acked-by: Tomer Tayar <Tomer.Tayar@cavium.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Nathan Chancellor [Thu, 4 Oct 2018 02:37:54 +0000 (19:37 -0700)]
ata: ep93xx: Use proper enums for directions
[ Upstream commit
6adde4a36f1b6a562a1057fbb1065007851050e7 ]
Clang warns when one enumerated type is implicitly converted to another.
drivers/ata/pata_ep93xx.c:662:36: warning: implicit conversion from
enumeration type 'enum dma_data_direction' to different enumeration type
'enum dma_transfer_direction' [-Wenum-conversion]
drv_data->dma_rx_data.direction = DMA_FROM_DEVICE;
~ ^~~~~~~~~~~~~~~
drivers/ata/pata_ep93xx.c:670:36: warning: implicit conversion from
enumeration type 'enum dma_data_direction' to different enumeration type
'enum dma_transfer_direction' [-Wenum-conversion]
drv_data->dma_tx_data.direction = DMA_TO_DEVICE;
~ ^~~~~~~~~~~~~
drivers/ata/pata_ep93xx.c:681:19: warning: implicit conversion from
enumeration type 'enum dma_data_direction' to different enumeration type
'enum dma_transfer_direction' [-Wenum-conversion]
conf.direction = DMA_FROM_DEVICE;
~ ^~~~~~~~~~~~~~~
drivers/ata/pata_ep93xx.c:692:19: warning: implicit conversion from
enumeration type 'enum dma_data_direction' to different enumeration type
'enum dma_transfer_direction' [-Wenum-conversion]
conf.direction = DMA_TO_DEVICE;
~ ^~~~~~~~~~~~~
Use the equivalent valued enums from the expected type so that Clang no
longer warns about a conversion.
DMA_TO_DEVICE = DMA_MEM_TO_DEV = 1
DMA_FROM_DEVICE = DMA_DEV_TO_MEM = 2
Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Nicholas Piggin [Mon, 27 Aug 2018 03:03:02 +0000 (13:03 +1000)]
powerpc/64s/radix: Explicitly flush ERAT with local LPID invalidation
[ Upstream commit
053c5a753e951c5dd1729af2cf4d8107f2e6e09b ]
Local radix TLB flush operations that operate on congruence classes
have explicit ERAT flushes for POWER9. The process scoped LPID flush
did not have a flush, so add it.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Anton Blanchard [Mon, 1 Oct 2018 23:01:04 +0000 (09:01 +1000)]
powerpc/time: Use clockevents_register_device(), fixing an issue with large decrementer
[ Upstream commit
8b78fdb045de60a4eb35460092bbd3cffa925353 ]
We currently cap the decrementer clockevent at 4 seconds, even on systems
with large decrementer support. Fix this by converting the code to use
clockevents_register_device() which calculates the upper bound based on
the max_delta passed in.
Signed-off-by: Anton Blanchard <anton@ozlabs.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dan Carpenter [Mon, 1 Oct 2018 16:44:30 +0000 (19:44 +0300)]
ASoC: qdsp6: q6asm-dai: checking NULL vs IS_ERR()
[ Upstream commit
8e9f7265eda9f3a662ca1ca47a69042a7840735b ]
The q6asm_audio_client_alloc() doesn't return NULL, it returns error
pointers.
Fixes:
2a9e92d371db ("ASoC: qdsp6: q6asm: Add q6asm dai driver")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Rafael J. Wysocki [Tue, 2 Oct 2018 21:42:02 +0000 (23:42 +0200)]
cpuidle: menu: Fix wakeup statistics updates for polling state
[ Upstream commit
5f26bdceb9c0a5e6c696aa2899d077cd3ae93413 ]
If the CPU exits the "polling" state due to the time limit in the
loop in poll_idle(), this is not a real wakeup and it just means
that the "polling" state selection was not adequate. The governor
mispredicted short idle duration, but had a more suitable state been
selected, the CPU might have spent more time in it. In fact, there
is no reason to expect that there would have been a wakeup event
earlier than the next timer in that case.
Handling such cases as regular wakeups in menu_update() may cause the
menu governor to make suboptimal decisions going forward, but ignoring
them altogether would not be correct either, because every time
menu_select() is invoked, it makes a separate new attempt to predict
the idle duration taking distinct time to the closest timer event as
input and the outcomes of all those attempts should be recorded.
For this reason, make menu_update() always assume that if the
"polling" state was exited due to the time limit, the next proper
wakeup event for the CPU would be the next timer event (not
including the tick).
Fixes:
a37b969a61c1 "cpuidle: poll_state: Add time limit to poll_idle()"
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Bob Moore [Wed, 3 Oct 2018 18:45:38 +0000 (11:45 -0700)]
ACPICA: Never run _REG on system_memory and system_IO
[ Upstream commit
8b1cafdcb4b75c5027c52f1e82b47ebe727ad7ed ]
These address spaces are defined by the ACPI spec to be
"always available", and thus _REG should never be run on them.
Provides compatibility with other ACPI implementations.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Erik Schmauss <erik.schmauss@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Viresh Kumar [Wed, 3 Oct 2018 09:52:03 +0000 (15:22 +0530)]
OPP: Return error on error from dev_pm_opp_get_opp_count()
[ Upstream commit
09f662f95306f3e3d47ab6842bc4b0bb868a80ad ]
Return error number instead of 0 on failures.
Fixes:
a1e8c13600bf ("PM / OPP: "opp-hz" is optional for power domains")
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jordan Crouse [Fri, 14 Sep 2018 15:03:46 +0000 (09:03 -0600)]
msm/gpu/a6xx: Force of_dma_configure to setup DMA for GMU
[ Upstream commit
32aa27e15c28d3898ed6f9b3c98f95f34a81eab2 ]
The point of the 'force_dma' parameter for of_dma_configure
is to force the device to be set up even if DMA capability is
not described by the firmware which is exactly the use case
we have for GMU - we need SMMU to get set up but we have no
other dma capabilities since memory is managed by the GPU
driver. Currently we pass false so of_dma_configure() fails
and subsequently GMU and GPU probe does as well.
Fixes:
4b565ca5a2c ("drm/msm: Add A6XX device support")
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Tested-by: Sibi Sankar <sibis@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Arun Kumar Neelakantam [Wed, 3 Oct 2018 11:38:20 +0000 (17:08 +0530)]
rpmsg: glink: smem: Support rx peak for size less than 4 bytes
[ Upstream commit
928002a5e9dab2ddc1a0fe3e00739e89be30dc6b ]
The current rx peak function fails to read the data if size is
less than 4bytes.
Use memcpy_fromio to support data reads of size less than 4 bytes.
Cc: stable@vger.kernel.org
Fixes:
f0beb4ba9b18 ("rpmsg: glink: Remove chunk size word align warning")
Signed-off-by: Arun Kumar Neelakantam <aneela@codeaurora.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Nathan Chancellor [Mon, 24 Sep 2018 19:57:16 +0000 (12:57 -0700)]
IB/mlx4: Avoid implicit enumerated type conversion
[ Upstream commit
b56511c15713ba6c7572e77a41f7ddba9c1053ec ]
Clang warns when one enumerated type is implicitly converted to another.
drivers/infiniband/hw/mlx4/mad.c:1811:41: warning: implicit conversion
from enumeration type 'enum mlx4_ib_qp_flags' to different enumeration
type 'enum ib_qp_create_flags' [-Wenum-conversion]
qp_init_attr.init_attr.create_flags = MLX4_IB_SRIOV_TUNNEL_QP;
~ ^~~~~~~~~~~~~~~~~~~~~~~
drivers/infiniband/hw/mlx4/mad.c:1819:41: warning: implicit conversion
from enumeration type 'enum mlx4_ib_qp_flags' to different enumeration
type 'enum ib_qp_create_flags' [-Wenum-conversion]
qp_init_attr.init_attr.create_flags = MLX4_IB_SRIOV_SQP;
~ ^~~~~~~~~~~~~~~~~
The type mlx4_ib_qp_flags explicitly provides supplemental values to the
type ib_qp_create_flags. Make that clear to Clang by changing the
create_flags type to u32.
Reported-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Lijun Ou [Sun, 30 Sep 2018 09:00:31 +0000 (17:00 +0800)]
RDMA/hns: Limit the size of extend sge of sq
[ Upstream commit
05ad5482a5904c416bcfd74afd7193e206e563ce ]
The hip08 split two hardware version. The version id are 0x20 and 0x21
according to the PCI revison. The max size of extend sge of sq is limited
to 2M for 0x20 version and 8M for 0x21 version. It may be exceeded to 2M
according to the algorithm that compute the product of wqe count and
extend sge number of every wqe. But the product always less than 8M.
Signed-off-by: Lijun Ou <oulijun@huawei.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Lijun Ou [Sun, 30 Sep 2018 09:00:30 +0000 (17:00 +0800)]
RDMA/hns: Bugfix for CM test
[ Upstream commit
15fc056fba7b17b9abfbe80a12f188403fc949fb ]
It will print the warning when the MSB bit of SLID is not zero running
cm_req_handler function that test CM. It needs to fixed zero when test
RoCE device.
Signed-off-by: Lijun Ou <oulijun@huawei.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Lijun Ou [Sun, 30 Sep 2018 09:00:29 +0000 (17:00 +0800)]
RDMA/hns: Submit bad wr when post send wr exception
[ Upstream commit
c80e066100b5fed722c8da67c1bd2312e7bcf129 ]
When user issues a RDMA read and enables sq inline, it needs to report a
bad wr to user.
Signed-off-by: Lijun Ou <oulijun@huawei.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Lijun Ou [Sun, 30 Sep 2018 09:00:28 +0000 (17:00 +0800)]
RDMA/hns: Bugfix for reserved qp number
[ Upstream commit
06ef0ee4b569101f3a07ce08335dbf29fd1404ef ]
It needs to include two special qps for every port. The hip08 have four
ports and the all reserved qp numbers are eight.
Signed-off-by: Lijun Ou <oulijun@huawei.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Zhu Yanjun [Sun, 30 Sep 2018 06:27:16 +0000 (02:27 -0400)]
IB/rxe: avoid srq memory leak
[ Upstream commit
aae0484e15f062ad2c2502e68e15dfb8b8f84608 ]
In rxe_queue_init, q and q->buf are allocated. In do_mmap_info, q->ip is
allocated. When error occurs, rxe_srq_from_init and the later error
handler do not free these allocated memories. This will make memory leak.
Signed-off-by: Zhu Yanjun <yanjun.zhu@oracle.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Wei Yongjun [Sat, 29 Sep 2018 03:55:16 +0000 (03:55 +0000)]
IB/mthca: Fix error return code in __mthca_init_one()
[ Upstream commit
39f2495618c5e980d2873ea3f2d1877dd253e07a ]
Fix to return a negative error code from the mthca_cmd_init() error
handling case instead of 0, as done elsewhere in this function.
Fixes:
80fd8238734c ("[PATCH] IB/mthca: Encapsulate command interface init")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Radoslaw Tyl [Mon, 24 Sep 2018 07:24:20 +0000 (09:24 +0200)]
ixgbe: Fix crash with VFs and flow director on interface flap
[ Upstream commit
5d826d209164b0752c883607be4cdbbcf7cab494 ]
This patch fix crash when we have restore flow director filters after reset
adapter. In ixgbe_fdir_filter_restore() filter->action is outside of the
rx_ring array, as it has a VF identifier in the upper 32 bits.
Signed-off-by: Radoslaw Tyl <radoslawx.tyl@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Nathan Chancellor [Fri, 21 Sep 2018 10:13:59 +0000 (03:13 -0700)]
i40e: Use proper enum in i40e_ndo_set_vf_link_state
[ Upstream commit
43ade6ad18416b8fd5bb3c9e9789faa666527eec ]
Clang warns when one enumerated type is converted implicitly to another.
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:4214:42: warning:
implicit conversion from enumeration type 'enum i40e_aq_link_speed' to
different enumeration type 'enum virtchnl_link_speed'
[-Wenum-conversion]
pfe.event_data.link_event.link_speed = I40E_LINK_SPEED_40GB;
~ ^~~~~~~~~~~~~~~~~~~~
1 warning generated.
Use the proper enum from virtchnl_link_speed, which has the same value
as I40E_LINK_SPEED_40GB, VIRTCHNL_LINK_SPEED_40GB. This appears to be
missed by commit
ff3f4cc267f6 ("virtchnl: finish conversion to virtchnl
interface").
Link: https://github.com/ClangBuiltLinux/linux/issues/81
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Radoslaw Tyl [Wed, 5 Sep 2018 07:00:51 +0000 (09:00 +0200)]
ixgbe: Fix ixgbe TX hangs with XDP_TX beyond queue limit
[ Upstream commit
8d7179b1e2d64b3493c0114916486fe92e6109a9 ]
We have Tx hang when number Tx and XDP queues are more than 64.
In XDP always is MTQC == 0x0 (64TxQs). We need more space for Tx queues.
Signed-off-by: Radoslaw Tyl <radoslawx.tyl@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
NeilBrown [Wed, 3 Oct 2018 05:04:41 +0000 (15:04 +1000)]
md: allow metadata updates while suspending an array - fix
[ Upstream commit
059421e041eb461fb2b3e81c9adaec18ef03ca3c ]
Commit
35bfc52187f6 ("md: allow metadata update while suspending.")
added support for allowing md_check_recovery() to still perform
metadata updates while the array is entering the 'suspended' state.
This is needed to allow the processes of entering the state to
complete.
Unfortunately, the patch doesn't really work. The test for
"mddev->suspended" at the start of md_check_recovery() means that the
function doesn't try to do anything at all while entering suspend.
This patch moves the code of updating the metadata while suspending to
*before* the test on mddev->suspended.
Reported-by: Jeff Mahoney <jeffm@suse.com>
Fixes:
35bfc52187f6 ("md: allow metadata update while suspending.")
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Anirudh Venkataramanan [Thu, 20 Sep 2018 00:43:02 +0000 (17:43 -0700)]
ice: Fix forward to queue group logic
[ Upstream commit
be8ff000bf83e658e63ab64cf4d2755abc5add5b ]
When adding a rule, queue region size needs to be provided as log base 2
of the number of queues in region. Fix that.
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sergei Shtylyov [Mon, 10 Sep 2018 20:22:16 +0000 (23:22 +0300)]
clocksource/drivers/sh_cmt: Fix clocksource width for 32-bit machines
[ Upstream commit
37e7742c55ba856eaec7e35673ee370f36eb17f3 ]
The driver seems to abuse *unsigned long* not only for the (32-bit)
register values but also for the 'sh_cmt_channel::total_cycles' which
needs to always be 64-bit -- as a result, the clocksource's mask is
needlessly clamped down to 32-bits on the 32-bit machines...
Fixes:
19bdc9d061bc ("clocksource: sh_cmt clocksource support")
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sergei Shtylyov [Sat, 8 Sep 2018 20:54:05 +0000 (23:54 +0300)]
clocksource/drivers/sh_cmt: Fixup for 64-bit machines
[ Upstream commit
22627c6f3ed3d9d0df13eec3c831b08f8186c38e ]
When trying to use CMT for clockevents on R-Car gen3 SoCs, I noticed
that 'max_delta_ns' for the broadcast timer (CMT) was shown as 1000 in
/proc/timer_list. It turned out that when calculating it, the driver did
1 << 32 (causing what I think was undefined behavior) resulting in a zero
delta, later clamped to 1000 by cev_delta2ns(). The root cause turned out
to be that the driver abused *unsigned long* for the CMT register values
(which are 16/32-bit), so that the calculation of 'ch->max_match_value'
in sh_cmt_setup_channel() used the wrong branch. Using more proper 'u32'
instead fixed 'max_delta_ns' and even fixed the switching an active
clocksource to CMT (which caused the system to turn non-interactive
before).
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Gustavo Pimentel [Thu, 23 Aug 2018 11:34:53 +0000 (13:34 +0200)]
tools: PCI: Fix compilation warnings
[ Upstream commit
fef31ecaaf2c5c54db85b35e893bf8abec96b93f ]
Current compilation produces the following warnings:
tools/pci/pcitest.c: In function 'run_test':
tools/pci/pcitest.c:56:9: warning: unused variable 'time'
[-Wunused-variable]
double time;
^~~~
tools/pci/pcitest.c:55:25: warning: unused variable 'end'
[-Wunused-variable]
struct timespec start, end;
^~~
tools/pci/pcitest.c:55:18: warning: unused variable 'start'
[-Wunused-variable]
struct timespec start, end;
^~~~~
tools/pci/pcitest.c:146:1: warning: control reaches end of non-void
function [-Wreturn-type]
}
^
Fix them:
- remove unused variables
- change function return from int to void, since it's not used
Signed-off-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
[lorenzo.pieralisi@arm.com: rewrote the commit log]
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Chen Yu [Fri, 21 Sep 2018 06:26:38 +0000 (14:26 +0800)]
PM / hibernate: Check the success of generating md5 digest before hibernation
[ Upstream commit
749fa17093ff67b31dea864531a3698b6a95c26c ]
Currently if get_e820_md5() fails, then it will hibernate nevertheless.
Actually the error code should be propagated to upper caller so that
the hibernation could be aware of the result and terminates the process
if md5 digest fails.
Suggested-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Chen Yu <yu.c.chen@intel.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Nathan Chancellor [Thu, 20 Sep 2018 23:30:25 +0000 (16:30 -0700)]
mtd: rawnand: sh_flctl: Use proper enum for flctl_dma_fifo0_transfer
[ Upstream commit
e2bfa4ca23d9b5a7bdfcf21319fad9b59e38a05c ]
Clang warns when one enumerated type is converted implicitly to another:
drivers/mtd/nand/raw/sh_flctl.c:483:46: warning: implicit conversion
from enumeration type 'enum dma_transfer_direction' to different
enumeration type 'enum dma_data_direction' [-Wenum-conversion]
flctl_dma_fifo0_transfer(flctl, buf, rlen, DMA_DEV_TO_MEM) > 0)
~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~
drivers/mtd/nand/raw/sh_flctl.c:542:46: warning: implicit conversion
from enumeration type 'enum dma_transfer_direction' to different
enumeration type 'enum dma_data_direction' [-Wenum-conversion]
flctl_dma_fifo0_transfer(flctl, buf, rlen, DMA_MEM_TO_DEV) > 0)
~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~
2 warnings generated.
Use the proper enums from dma_data_direction to satisfy Clang.
DMA_MEM_TO_DEV = DMA_TO_DEVICE = 1
DMA_DEV_TO_MEM = DMA_FROM_DEVICE = 2
Reported-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tudor Ambarus [Tue, 2 Oct 2018 13:20:35 +0000 (16:20 +0300)]
ARM: dts: at91: sama5d2_ptc_ek: fix bootloader env offsets
[ Upstream commit
f602b4871c5f7ac01d37d8b285ca947ba7613065 ]
The offsets for the bootloader environment and its redundant partition
were inverted. Fix the addresses to match our nand flash map available at:
http://www.at91.com/linux4sam/pub/Linux4SAM/SambaSubsections//demo_nandflash_map_lnx4sam5x.png
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tudor Ambarus [Tue, 2 Oct 2018 13:00:36 +0000 (16:00 +0300)]
ARM: dts: at91: at91sam9x5cm: fix addressable nand flash size
[ Upstream commit
6f270d88a0c4a11725afd8fd2001ae408733afbf ]
at91sam9x5cm comes with a 2Gb NAND flash. Fix the rootfs size to
match this limit.
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tudor Ambarus [Tue, 2 Oct 2018 13:00:35 +0000 (16:00 +0300)]
ARM: dts: at91: sama5d4_xplained: fix addressable nand flash size
[ Upstream commit
df90fc64367ffdb6f1b5c0f0c4940d44832b0174 ]
sama5d4_xplained comes with a 4Gb NAND flash. Increase the rootfs
size to match this limit.
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
zhong jiang [Wed, 26 Sep 2018 12:09:32 +0000 (20:09 +0800)]
powerpc/xive: Move a dereference below a NULL test
[ Upstream commit
cd5ff94577e004e0a4457e70d0ef3a030f4010b8 ]
Move the dereference of xc below the NULL test.
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Naveen N. Rao [Thu, 27 Sep 2018 08:10:58 +0000 (13:40 +0530)]
powerpc/pseries: Fix how we iterate over the DTL entries
[ Upstream commit
9258227e9dd1da8feddb07ad9702845546a581c9 ]
When CONFIG_VIRT_CPU_ACCOUNTING_NATIVE is not set, we look up dtl_idx in
the lppaca to determine the number of entries in the buffer. Since
lppaca is in big endian, we need to do an endian conversion before using
this in our calculation to determine the number of entries in the
buffer. Without this, we do not iterate over the existing entries in the
DTL buffer properly.
Fixes:
7c105b63bd98 ("powerpc: Add CONFIG_CPU_LITTLE_ENDIAN kernel config option.")
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Naveen N. Rao [Thu, 27 Sep 2018 08:10:57 +0000 (13:40 +0530)]
powerpc/pseries: Fix DTL buffer registration
[ Upstream commit
db787af1b8a6b4be428ee2ea7d409dafcaa4a43c ]
When CONFIG_VIRT_CPU_ACCOUNTING_NATIVE is not set, we register the DTL
buffer for a cpu when the associated file under powerpc/dtl in debugfs
is opened. When doing so, we need to set the size of the buffer being
registered in the second u32 word of the buffer. This needs to be in big
endian, but we are not doing the conversion resulting in the below error
showing up in dmesg:
dtl_start: DTL registration for cpu 0 (hw 0) failed with -4
Fix this in the obvious manner.
Fixes:
7c105b63bd98 ("powerpc: Add CONFIG_CPU_LITTLE_ENDIAN kernel config option.")
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Nathan Chancellor [Mon, 1 Oct 2018 03:47:38 +0000 (20:47 -0700)]
cxgb4: Use proper enum in IEEE_FAUX_SYNC
[ Upstream commit
258b6d141878530ba1f8fc44db683822389de914 ]
Clang warns when one enumerated type is implicitly converted to another.
drivers/net/ethernet/chelsio/cxgb4/cxgb4_dcb.c:390:4: warning: implicit
conversion from enumeration type 'enum cxgb4_dcb_state' to different
enumeration type 'enum cxgb4_dcb_state_input' [-Wenum-conversion]
IEEE_FAUX_SYNC(dev, dcb);
^~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/chelsio/cxgb4/cxgb4_dcb.h:70:10: note: expanded
from macro 'IEEE_FAUX_SYNC'
CXGB4_DCB_STATE_FW_ALLSYNCED);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
Use the equivalent value of the expected type to silence Clang while
resulting in no functional change.
CXGB4_DCB_STATE_FW_ALLSYNCED = CXGB4_DCB_INPUT_FW_ALLSYNCED = 3
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Nathan Chancellor [Mon, 1 Oct 2018 03:51:43 +0000 (20:51 -0700)]
cxgb4: Use proper enum in cxgb4_dcb_handle_fw_update
[ Upstream commit
3b0b8f0d9a259f6a428af63e7a77547325f8e081 ]
Clang warns when one enumerated type is implicitly converted to another.
drivers/net/ethernet/chelsio/cxgb4/cxgb4_dcb.c:303:7: warning: implicit
conversion from enumeration type 'enum cxgb4_dcb_state' to different
enumeration type 'enum cxgb4_dcb_state_input' [-Wenum-conversion]
? CXGB4_DCB_STATE_FW_ALLSYNCED
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/chelsio/cxgb4/cxgb4_dcb.c:304:7: warning: implicit
conversion from enumeration type 'enum cxgb4_dcb_state' to different
enumeration type 'enum cxgb4_dcb_state_input' [-Wenum-conversion]
: CXGB4_DCB_STATE_FW_INCOMPLETE);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2 warnings generated.
Use the equivalent value of the expected type to silence Clang while
resulting in no functional change.
CXGB4_DCB_STATE_FW_INCOMPLETE = CXGB4_DCB_INPUT_FW_INCOMPLETE = 2
CXGB4_DCB_STATE_FW_ALLSYNCED = CXGB4_DCB_INPUT_FW_ALLSYNCED = 3
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dan Carpenter [Mon, 1 Oct 2018 16:44:41 +0000 (19:44 +0300)]
mei: samples: fix a signedness bug in amt_host_if_call()
[ Upstream commit
185647813cac080453cb73a2e034a8821049f2a7 ]
"out_buf_sz" needs to be signed for the error handling to work.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jon Derrick [Fri, 7 Sep 2018 19:22:30 +0000 (13:22 -0600)]
x86/PCI: Apply VMD's AERSID fixup generically
[ Upstream commit
4f475e8e0a6d4f5d430350d1f74f7e4899fb1692 ]
A root port Device ID changed between simulation and production. Rather
than match Device IDs which may not be future-proof if left unmaintained,
match all root ports which exist in a VMD domain.
Signed-off-by: Jon Derrick <jonathan.derrick@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Chuck Lever [Mon, 1 Oct 2018 18:25:36 +0000 (14:25 -0400)]
sunrpc: Fix connect metrics
[ Upstream commit
3968a8a5310404c2f0b9e4d9f28cab13a12bc4fd ]
For TCP, the logic in xprt_connect_status is currently never invoked
to record a successful connection. Commit
2a4919919a97 ("SUNRPC:
Return EAGAIN instead of ENOTCONN when waking up xprt->pending")
changed the way TCP xprt's are awoken after a connect succeeds.
Instead, change connection-oriented transports to bump connect_count
and compute connect_time the moment that XPRT_CONNECTED is set.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Nishanth Menon [Tue, 28 Aug 2018 00:50:56 +0000 (19:50 -0500)]
clk: keystone: Enable TISCI clocks if K3_ARCH
[ Upstream commit
2f149e6e14bcb5e581e49307b54aafcd6f74a74f ]
K3_ARCH uses TISCI for clocks as well. Enable the same
for the driver support.
Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-by: Santosh Shilimkar <ssantosh@kernel.org>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Gabriel Krisman Bertazi [Tue, 2 Oct 2018 16:43:51 +0000 (12:43 -0400)]
ext4: fix build error when DX_DEBUG is defined
[ Upstream commit
799578ab16e86b074c184ec5abbda0bc698c7b0b ]
Enabling DX_DEBUG triggers the build error below. info is an attribute
of the dxroot structure.
linux/fs/ext4/namei.c:2264:12: error: ‘info’
undeclared (first use in this function); did you mean ‘insl’?
info->indirect_levels));
Fixes:
e08ac99fa2a2 ("ext4: add largedir feature")
Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Keyon Jie [Fri, 28 Sep 2018 09:38:59 +0000 (17:38 +0800)]
ALSA: hda: Fix mismatch for register mask and value in ext controller.
[ Upstream commit
c32bf867cb6721d6ea04044d33f19c8bd81280c1 ]
E.g. for snd_hdac_ext_bus_link_power_up(), we should set mask to be
AZX_MLCTL_SPA(it was 0), and AZX_MLCTL_SPA as value to power up it,
here correct it and several similar mismatches.
Signed-off-by: Keyon Jie <yang.jie@linux.intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Nathan Chancellor [Tue, 11 Sep 2018 23:20:25 +0000 (16:20 -0700)]
dmaengine: timb_dma: Use proper enum in td_prep_slave_sg
[ Upstream commit
5e621f5d538985f010035c6f3e28c22829d36db1 ]
Clang warns when implicitly converting from one enumerated type to
another. Avoid this by using the equivalent value from the expected
type.
drivers/dma/timb_dma.c:548:27: warning: implicit conversion from
enumeration type 'enum dma_transfer_direction' to different enumeration
type 'enum dma_data_direction' [-Wenum-conversion]
td_desc->desc_list_len, DMA_MEM_TO_DEV);
^~~~~~~~~~~~~~
1 warning generated.
Reported-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Nathan Chancellor [Tue, 11 Sep 2018 23:40:20 +0000 (16:40 -0700)]
dmaengine: ep93xx: Return proper enum in ep93xx_dma_chan_direction
[ Upstream commit
9524d6b265f9b2b9a61fceb2ee2ce1c2a83e39ca ]
Clang warns when implicitly converting from one enumerated type to
another. Avoid this by using the equivalent value from the expected
type.
In file included from drivers/dma/ep93xx_dma.c:30:
./include/linux/platform_data/dma-ep93xx.h:88:10: warning: implicit
conversion from enumeration type 'enum dma_data_direction' to different
enumeration type 'enum dma_transfer_direction' [-Wenum-conversion]
return DMA_NONE;
~~~~~~ ^~~~~~~~
1 warning generated.
Reported-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sergey Senozhatsky [Fri, 28 Sep 2018 09:53:04 +0000 (18:53 +0900)]
printk: CON_PRINTBUFFER console registration is a bit racy
[ Upstream commit
884e370ea88c109a3b982f4eb9ecd82510a3a1fe ]
CON_PRINTBUFFER console registration requires us to do several
preparation steps:
- Rollback console_seq to replay logbuf messages which were already
seen on other consoles;
- Set exclusive_console flag so console_unlock() will ->write() logbuf
messages only to the exclusive_console driver.
The way we do it, however, is a bit racy
logbuf_lock_irqsave(flags);
console_seq = syslog_seq;
console_idx = syslog_idx;
logbuf_unlock_irqrestore(flags);
<< preemption enabled
<< irqs enabled
exclusive_console = newcon;
console_unlock();
We rollback console_seq under logbuf_lock with IRQs disabled, but
we set exclusive_console with local IRQs enabled and logbuf unlocked.
If the system oops-es or panic-s before we set exclusive_console - and
given that we have IRQs and preemption enabled there is such a
possibility - we will re-play all logbuf messages to every registered
console, which may be a bit annoying and time consuming.
Move exclusive_console assignment to the same IRQs-disabled and
logbuf_lock-protected section where we rollback console_seq.
Link: http://lkml.kernel.org/r/20180928095304.9972-1-sergey.senozhatsky@gmail.com
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Petr Mladek [Thu, 13 Sep 2018 12:34:06 +0000 (14:34 +0200)]
printk: Do not miss new messages when replaying the log
[ Upstream commit
f92b070f2dc89a8ff1a0cc8b608e20abef894c7d ]
The variable "exclusive_console" is used to reply all existing messages
on a newly registered console. It is cleared when all messages are out.
The problem is that new messages might appear in the meantime. These
are then visible only on the exclusive console.
The obvious solution is to clear "exclusive_console" after we replay
all messages that were already proceed before we started the reply.
Reported-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Link: http://lkml.kernel.org/r/20180913123406.14378-1-pmladek@suse.com
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: linux-kernel@vger.kernel.org
Acked-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Alexey Kardashevskiy [Mon, 10 Sep 2018 08:29:09 +0000 (18:29 +1000)]
KVM: PPC: Inform the userspace about TCE update failures
[ Upstream commit
f7960e299f13f069d6f3d4e157d91bfca2669677 ]
We return H_TOO_HARD from TCE update handlers when we think that
the next handler (realmode -> virtual mode -> user mode) has a chance to
handle the request; H_HARDWARE/H_CLOSED otherwise.
This changes the handlers to return H_TOO_HARD on every error giving
the userspace an opportunity to handle any request or at least log
them all.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Guenter Roeck [Sun, 23 Sep 2018 13:54:11 +0000 (06:54 -0700)]
watchdog: w83627hf_wdt: Support NCT6796D, NCT6797D, NCT6798D
[ Upstream commit
57cbf0e3a0fd48e5ad8f3884562e8dde4827c1c8 ]
The watchdog controller on NCT6796D, NCT6797D, and NCT6798D is compatible
with the wtachdog controller on other Nuvoton chips.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Wim Van Sebroeck <wim@linux-watchdog.org>
Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Romain Izard [Fri, 14 Sep 2018 10:13:38 +0000 (12:13 +0200)]
watchdog: sama5d4: fix timeout-sec usage
[ Upstream commit
2e0432f8f8ad11b4bd208445360220efa5b37d82 ]
When using watchdog_init_timeout to update the default timeout value,
an error means that there is no "timeout-sec" in the relevant device
tree node.
This should not prevent binding of the driver to the device.
Fixes:
976932e40036 ("watchdog: sama5d4: make use of timeout-secs provided in devicetree")
Signed-off-by: Romain Izard <romain.izard.pro@gmail.com>
Reviewed-by: Marcus Folkesson <marcus.folkesson@gmail.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Wolfram Sang [Tue, 28 Aug 2018 10:13:48 +0000 (12:13 +0200)]
watchdog: renesas_wdt: stop when unregistering
[ Upstream commit
14de99b44b34dbb9d0f64845b1cbb675e047767e ]
We want to go into a sane state when unregistering. Currently, it
happens that the watchdog stops when unbinding because of RuntimePM
stopping the core clock. When rebinding, the core clock gets reactivated
and the watchdog fires even though it hasn't been opened by userspace
yet. Strange scenario, yes, but sane state is much preferred anyhow.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Wolfram Sang [Tue, 28 Aug 2018 10:13:47 +0000 (12:13 +0200)]
watchdog: core: fix null pointer dereference when releasing cdev
[ Upstream commit
953b9dd7725bad55a922a35e75bff7bebf7b9978 ]
watchdog_stop() calls watchdog_update_worker() which needs a valid
wdd->wd_data pointer. So, when unregistering the cdev, clear the
pointers after we call watchdog_stop(), not before.
Fixes:
bb292ac1c602 ("watchdog: Introduce watchdog_stop_on_unregister helper")
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Miquel Raynal [Mon, 1 Oct 2018 14:13:47 +0000 (16:13 +0200)]
irqchip/irq-mvebu-icu: Fix wrong private data retrieval
[ Upstream commit
2b4dab69dcca13c5be2ddaf1337ae4accd087de6 ]
The irq_domain structure has an host_data pointer that just stores
private data. It is meant to not be touched by the IRQ core. However,
when it comes to MSI, the MSI layer adds its own private data there
with a structure that also has a host_data pointer.
Because this IRQ domain is an MSI domain, to access private data we
should do a d->host_data->host_data, also wrapped as
'platform_msi_get_host_data()'.
This bug was lying there silently because the 'icu' structure retrieved
this way was just called by dev_err(), only producing a
'(NULL device *):' output on the console.
Reviewed-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Andrew Zaborowski [Mon, 24 Sep 2018 16:10:22 +0000 (18:10 +0200)]
nl80211: Fix a GET_KEY reply attribute
[ Upstream commit
efdfce7270de85a8706d1ea051bef3a7486809ff ]
Use the NL80211_KEY_IDX attribute inside the NL80211_ATTR_KEY in
NL80211_CMD_GET_KEY responses to comply with nl80211_key_policy.
This is unlikely to affect existing userspace.
Signed-off-by: Andrew Zaborowski <andrew.zaborowski@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Thinh Nguyen [Tue, 11 Sep 2018 19:42:05 +0000 (12:42 -0700)]
usb: dwc3: gadget: Check ENBLSLPM before sending ep command
[ Upstream commit
87dd96111b0bb8e616fcbd74dbf4bb4182f2c596 ]
When operating in USB 2.0 speeds (HS/FS), if GUSB2PHYCFG.ENBLSLPM or
GUSB2PHYCFG.SUSPHY is set, it must be cleared before issuing an endpoint
command.
Current implementation only save and restore GUSB2PHYCFG.SUSPHY
configuration. We must save and clear both GUSB2PHYCFG.ENBLSLPM and
GUSB2PHYCFG.SUSPHY settings. Restore them after the command is
completed.
DWC_usb3 3.30a and DWC_usb31 1.90a programming guide section 3.2.2
Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jia-Ju Bai [Sat, 15 Sep 2018 03:04:40 +0000 (11:04 +0800)]
usb: gadget: udc: fotg210-udc: Fix a sleep-in-atomic-context bug in fotg210_get_status()
[ Upstream commit
2337a77c1cc86bc4e504ecf3799f947659c86026 ]
The driver may sleep in an interrupt handler.
The function call path (from bottom to top) in Linux-4.17 is:
[FUNC] fotg210_ep_queue(GFP_KERNEL)
drivers/usb/gadget/udc/fotg210-udc.c, 744:
fotg210_ep_queue in fotg210_get_status
drivers/usb/gadget/udc/fotg210-udc.c, 768:
fotg210_get_status in fotg210_setup_packet
drivers/usb/gadget/udc/fotg210-udc.c, 949:
fotg210_setup_packet in fotg210_irq (interrupt handler)
To fix this bug, GFP_KERNEL is replaced with GFP_ATOMIC.
If possible, spin_unlock() and spin_lock() around fotg210_ep_queue()
can be also removed.
This bug is found by my static analysis tool DSAC.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Vakul Garg [Fri, 28 Sep 2018 16:18:08 +0000 (21:48 +0530)]
selftests/tls: Fix recv(MSG_PEEK) & splice() test cases
[ Upstream commit
0ed3015c9964dab7a1693b3e40650f329c16691e ]
TLS test cases splice_from_pipe, send_and_splice &
recv_peek_multiple_records expect to receive a given nummber of bytes
and then compare them against the number of bytes which were sent.
Therefore, system call recv() must not return before receiving the
requested number of bytes, otherwise the subsequent memcmp() fails.
This patch passes MSG_WAITALL flag to recv() so that it does not return
prematurely before requested number of bytes are copied to receive
buffer.
Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Simon Wunderlich [Mon, 1 Oct 2018 14:26:59 +0000 (17:26 +0300)]
ath9k: fix reporting calculated new FFT upper max
[ Upstream commit
4fb5837ac2bd46a85620b297002c704e9958f64d ]
Since the debug print code is outside of the loop, it shouldn't use the loop
iterator anymore but instead print the found maximum index.
Cc: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Vincent Donnefort [Mon, 3 Sep 2018 00:02:07 +0000 (09:02 +0900)]
PM / devfreq: stopping the governor before device_unregister()
[ Upstream commit
2f061fd0c2d852e32e03a903fccd810663c5c31e ]
device_release() is freeing the resources before calling the device
specific release callback which is, in the case of devfreq, stopping
the governor.
It is a problem as some governors are using the device resources. e.g.
simpleondemand which is using the devfreq deferrable monitoring work. If it
is not stopped before the resources are freed, it might lead to a use after
free.
Signed-off-by: Vincent Donnefort <vincent.donnefort@arm.com>
Reviewed-by: John Einar Reitan <john.reitan@arm.com>
[cw00.choi: Fix merge conflict]
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Matthias Kaehlcke [Fri, 3 Aug 2018 20:05:09 +0000 (13:05 -0700)]
PM / devfreq: Fix handling of min/max_freq == 0
[ Upstream commit
df5cf4a36178c5d4f2b8b9469cb2f722e64cd102 ]
Commit
ab8f58ad72c4 ("PM / devfreq: Set min/max_freq when adding the
devfreq device") initializes df->min/max_freq with the min/max OPP when
the device is added. Later commit
f1d981eaecf8 ("PM / devfreq: Use the
available min/max frequency") adds df->scaling_min/max_freq and the
following to the frequency adjustment code:
max_freq = MIN(devfreq->scaling_max_freq, devfreq->max_freq);
With the current handling of min/max_freq this is incorrect:
Even though df->max_freq is now initialized to a value != 0 user space
can still set it to 0, in this case max_freq would be 0 instead of
df->scaling_max_freq as intended. In consequence the frequency adjustment
is not performed:
if (max_freq && freq > max_freq) {
freq = max_freq;
To fix this set df->min/max freq to the min/max OPP in max/max_freq_store,
when the user passes a value of 0. This also prevents df->max_freq from
being set below the min OPP when df->min_freq is 0, and similar for
min_freq. Since it is now guaranteed that df->min/max_freq can't be 0 the
checks for this case can be removed.
Fixes:
f1d981eaecf8 ("PM / devfreq: Use the available min/max frequency")
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Enric Balletbo i Serra [Wed, 4 Jul 2018 08:45:50 +0000 (10:45 +0200)]
PM / devfreq: Fix devfreq_add_device() when drivers are built as modules.
[ Upstream commit
23c7b54ca1cd1797ef39169ab85e6d46f1c2d061 ]
When the devfreq driver and the governor driver are built as modules,
the call to devfreq_add_device() or governor_store() fails because the
governor driver is not loaded at the time the devfreq driver loads. The
devfreq driver has a build dependency on the governor but also should
have a runtime dependency. We need to make sure that the governor driver
is loaded before the devfreq driver.
This patch fixes this bug by adding a try_then_request_governor()
function. First tries to find the governor, and then, if it is not found,
it requests the module and tries again.
Fixes:
1b5c1be2c88e (PM / devfreq: map devfreq drivers to governor using name)
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Florian Fainelli [Mon, 1 Oct 2018 17:33:02 +0000 (10:33 -0700)]
ata: ahci_brcm: Allow using driver or DSL SoCs
[ Upstream commit
7fb44929cb0e5cdcde143e1ca3ca57b5b8247db0 ]
The Broadcom STB AHCI controller is the same as the one found on DSL
SoCs, so we will utilize the same driver on these systems as well.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Nathan Chancellor [Sun, 23 Sep 2018 06:31:15 +0000 (23:31 -0700)]
rtlwifi: btcoex: Use proper enumerated types for Wi-Fi only interface
[ Upstream commit
31138a827d1b3d6e4855bddb5a1e44e7b32309c0 ]
Clang warns when one enumerated type is implicitly converted to another.
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c:1327:34:
warning: implicit conversion from enumeration type 'enum
btc_chip_interface' to different enumeration type 'enum
wifionly_chip_interface' [-Wenum-conversion]
wifionly_cfg->chip_interface = BTC_INTF_PCI;
~ ^~~~~~~~~~~~
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c:1330:34:
warning: implicit conversion from enumeration type 'enum
btc_chip_interface' to different enumeration type 'enum
wifionly_chip_interface' [-Wenum-conversion]
wifionly_cfg->chip_interface = BTC_INTF_USB;
~ ^~~~~~~~~~~~
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c:1333:34:
warning: implicit conversion from enumeration type 'enum
btc_chip_interface' to different enumeration type 'enum
wifionly_chip_interface' [-Wenum-conversion]
wifionly_cfg->chip_interface = BTC_INTF_UNKNOWN;
~ ^~~~~~~~~~~~~~~~
3 warnings generated.
Use the values from the correct enumerated type, wifionly_chip_interface.
BTC_INTF_UNKNOWN = WIFIONLY_INTF_UNKNOWN = 0
BTC_INTF_PCI = WIFIONLY_INTF_PCI = 1
BTC_INTF_USB = WIFIONLY_INTF_USB = 2
Link: https://github.com/ClangBuiltLinux/linux/issues/135
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ben Greear [Thu, 6 Sep 2018 16:46:20 +0000 (19:46 +0300)]
ath10k: fix vdev-start timeout on error
[ Upstream commit
833fd34d743c728afe6d127ef7bee67e7d9199a8 ]
The vdev-start-response message should cause the
completion to fire, even in the error case. Otherwise,
the user still gets no useful information and everything
is blocked until the timeout period.
Add some warning text to print out the invalid status
code to aid debugging, and propagate failure code.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Anshuman Khandual [Sat, 22 Sep 2018 15:39:55 +0000 (21:09 +0530)]
arm64/numa: Report correct memblock range for the dummy node
[ Upstream commit
77cfe950901e5c13aca2df6437a05f39dd9a929b ]
The dummy node ID is marked into all memory ranges on the system. So the
dummy node really extends the entire memblock.memory. Hence report correct
extent information for the dummy node using memblock range helper functions
instead of the range [0LLU, PFN_PHYS(max_pfn) - 1)].
Fixes:
1a2db30034 ("arm64, numa: Add NUMA support for arm64 platforms")
Acked-by: Punit Agrawal <punit.agrawal@arm.com>
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Suzuki K Poulose [Wed, 26 Sep 2018 16:32:37 +0000 (17:32 +0100)]
kvm: arm/arm64: Fix stage2_flush_memslot for 4 level page table
[ Upstream commit
d2db7773ba864df6b4e19643dfc54838550d8049 ]
So far we have only supported 3 level page table with fixed IPA of
40bits, where PUD is folded. With 4 level page tables, we need
to check if the PUD entry is valid or not. Fix stage2_flush_memslot()
to do this check, before walking down the table.
Acked-by: Christoffer Dall <cdall@kernel.org>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Zhen Lei [Sun, 19 Aug 2018 07:51:10 +0000 (15:51 +0800)]
iommu/arm-smmu-v3: Fix unexpected CMD_SYNC timeout
[ Upstream commit
0f02477d16980938a84aba8688a4e3a303306116 ]
The condition break condition of:
(int)(VAL - sync_idx) >= 0
in the __arm_smmu_sync_poll_msi() polling loop requires that sync_idx
must be increased monotonically according to the sequence of the CMDs in
the cmdq.
However, since the msidata is populated using atomic_inc_return_relaxed()
before taking the command-queue spinlock, then the following scenario
can occur:
CPU0 CPU1
msidata=0
msidata=1
insert cmd1
insert cmd0
smmu execute cmd1
smmu execute cmd0
poll timeout, because msidata=1 is overridden by
cmd0, that means VAL=0, sync_idx=1.
This is not a functional problem, since the caller will eventually either
timeout or exit due to another CMD_SYNC, however it's clearly not what
the code is supposed to be doing. Fix it, by incrementing the sequence
count with the command-queue lock held, allowing us to drop the atomic
operations altogether.
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
[will: dropped the specialised cmd building routine for now]
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Robin Murphy [Thu, 6 Sep 2018 16:59:50 +0000 (17:59 +0100)]
iommu/io-pgtable-arm: Fix race handling in split_blk_unmap()
[ Upstream commit
85c7a0f1ef624ef58173ef52ea77780257bdfe04 ]
In removing the pagetable-wide lock, we gained the possibility of the
vanishingly unlikely case where we have a race between two concurrent
unmappers splitting the same block entry. The logic to handle this is
fairly straightforward - whoever loses the race frees their partial
next-level table and instead dereferences the winner's newly-installed
entry in order to fall back to a regular unmap, which intentionally
echoes the pre-existing case of recursively splitting a 1GB block down
to 4KB pages by installing a full table of 2MB blocks first.
Unfortunately, the chump who implemented that logic failed to update the
condition check for that fallback, meaning that if said race occurs at
the last level (where the loser's unmap_idx is valid) then the unmap
won't actually happen. Fix that to properly account for both the race
and recursive cases.
Fixes:
2c3d273eabe8 ("iommu/io-pgtable-arm: Support lockless operation")
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
[will: re-jig control flow to avoid duplicate cmpxchg test]
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Felix Fietkau [Sat, 29 Sep 2018 11:13:09 +0000 (13:13 +0200)]
mt76: fix handling ps-poll frames
[ Upstream commit
36d910960fae3f9e74bedf3e0ef39ee26bdaa51f ]
Hardware station lookup for pspoll frames can fail, which makes the driver
ignore ps-poll frames. Fix the resulting powersave issues by looking up
the station for pspoll frames in software
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Felix Fietkau [Wed, 26 Sep 2018 19:37:38 +0000 (21:37 +0200)]
mt76x2: disable WLAN core before probe
[ Upstream commit
62e04f8a31fcc375c978b7f83b4229a10c3e746d ]
If the WLAN core is still active during initialization, it might cause
the MCU or DMA to hang. This can happen during soft reboot, so disable
the core + clock early to avoid this issue.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Lorenzo Bianconi [Fri, 21 Sep 2018 13:57:50 +0000 (15:57 +0200)]
mt76x2: fix tx power configuration for VHT mcs 9
[ Upstream commit
60b6645ef1a9239a02c70adeae136298395d145a ]
Fix tx power configuration for VHT 1SS/STBC mcs 9 since
in MT_TX_PWR_CFG_{8,9} mcs 8,9 bits are GENMASK(21,16) and
GENMASK(29,24) while GENMASK(15,6) are marked as reserved
Fixes:
7bc04215a66b ("mt76: add driver code for MT76x2e")
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dennis Dalessandro [Wed, 26 Sep 2018 17:55:53 +0000 (10:55 -0700)]
IB/hfi1: Ensure ucast_dlid access doesnt exceed bounds
[ Upstream commit
3144533bf667c8e53bb20656b78295960073e57b ]
The dlid assignment made by looking into the u_ucast_dlid array does not
do an explicit check for the size of the array. The code path to arrive at
def_port, the index value is long and complicated so its best to just have
an explicit check here.
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Michael J. Ruhl [Fri, 28 Sep 2018 14:34:57 +0000 (07:34 -0700)]
IB/hfi1: Error path MAD response size is incorrect
[ Upstream commit
935c84ac649a147e1aad2c48ee5c5a1a9176b2d0 ]
If a MAD packet has incorrect header information, the logic uses the reply
path to report the error. The reply path expects *resp_len to be set
prior to return. Unfortunately, *resp_len is set to 0 for this path.
This causes an incorrect response packet.
Fix by ensuring that the *resp_len is defaulted to the incoming packet
size (wc->bytes_len - sizeof(GRH)).
Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jaegeuk Kim [Fri, 28 Sep 2018 07:24:39 +0000 (00:24 -0700)]
f2fs: keep lazytime on remount
[ Upstream commit
095680f24f2673d860fd1d3d2f54f40f330b4c63 ]
This patch fixes losing lazytime when remounting f2fs.
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Hans de Goede [Sun, 23 Sep 2018 13:58:11 +0000 (15:58 +0200)]
ACPI / LPSS: Resume BYT/CHT I2C controllers from resume_noirq
[ Upstream commit
48402cee6889fb3fce58e95fea1471626286dc63 ]
On some Cherry Trail systems the GPU ACPI fwnode has power-resources which
point to the PMIC, which is connected over a LPSS I2C controller.
We add a device-link to make sure that the I2C controller is resumed before
the GPU is. But the pci-core changes the power-state of PCI devices from
D3 to D0 at noirq time (to restore the PCI config registers) and before
this commit we were bringing up the I2C controllers from a resume_early
handler which runs later. More specifically the pm-core will first run
all resume_noirq handlers in order and then all resume_early handlers.
So we must not only make sure that the handlers are run in the right order,
but also that the resume of the I2C controller is done at noirq time.
The behavior before this commit, resuming the I2C controller from a
resume_early handler leads to the following errors:
i2c_designware
808622C1:06: controller timed out
ACPI Error: AE_ERROR, Returned by Handler for [UserDefinedRegion]
ACPI Error: Method parse/execution failed \_SB.P18W._ON, AE_ERROR
video LNXVIDEO:00: Failed to change power state to D0
This commit changes the acpi_lpss.c code to resume the BYT/CHT I2C
controllers at resume_noirq time fixing this.
Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Hans de Goede [Sun, 23 Sep 2018 13:58:08 +0000 (15:58 +0200)]
ACPI / LPSS: Make acpi_lpss_find_device() also find PCI devices
[ Upstream commit
1e30124ac60abc41d74793900f8b4034f29bcb3d ]
On some Cherry Trail systems the GPU ACPI fwnode has power-resources which
point to the PMIC, which is connected over one of the LPSS I2C controllers.
To get the suspend/resume ordering correct for this we need to be able to
add device-links between the GPU and the I2c controller. The GPU is a PCI
device, so this requires acpi_lpss_find_device() to also work on PCI devs.
Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Trond Myklebust [Sun, 9 Sep 2018 02:09:48 +0000 (22:09 -0400)]
SUNRPC: Fix priority queue fairness
[ Upstream commit
f42f7c283078ce3c1e8368b140e270755b1ae313 ]
Fix up the priority queue to not batch by owner, but by queue, so that
we allow '1 << priority' elements to be dequeued before switching to
the next priority queue.
The owner field is still used to wake up requests in round robin order
by owner to avoid single processes hogging the RPC layer by loading the
queues.
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yuchung Cheng [Thu, 27 Sep 2018 18:21:19 +0000 (11:21 -0700)]
tcp: up initial rmem to 128KB and SYN rwin to around 64KB
[ Upstream commit
a337531b942bd8a03e7052444d7e36972aac2d92 ]
Previously TCP initial receive buffer is ~87KB by default and
the initial receive window is ~29KB (20 MSS). This patch changes
the two numbers to 128KB and ~64KB (rounding down to the multiples
of MSS) respectively. The patch also simplifies the calculations s.t.
the two numbers are directly controlled by sysctl tcp_rmem[1]:
1) Initial receiver buffer budget (sk_rcvbuf): while this should
be configured via sysctl tcp_rmem[1], previously tcp_fixup_rcvbuf()
always override and set a larger size when a new connection
establishes.
2) Initial receive window in SYN: previously it is set to 20
packets if MSS <= 1460. The number 20 was based on the initial
congestion window of 10: the receiver needs twice amount to
avoid being limited by the receive window upon out-of-order
delivery in the first window burst. But since this only
applies if the receiving MSS <= 1460, connection using large MTU
(e.g. to utilize receiver zero-copy) may be limited by the
receive window.
With this patch TCP memory configuration is more straight-forward and
more properly sized to modern high-speed networks by default. Several
popular stacks have been announcing 64KB rwin in SYNs as well.
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Wei Wang <weiwan@google.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Soheil Hassas Yeganeh <soheil@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Chen-Yu Tsai [Thu, 30 Aug 2018 08:09:24 +0000 (16:09 +0800)]
ARM: dts: sun8i: h3: bpi-m2-plus: Fix address for external RGMII Ethernet PHY
[ Upstream commit
db9fd9d13e30fc67737ac9893a82e6b095e85a64 ]
The external RTL8211E RGMII Ethernet PHY is configured via external
resistors to use the address 0x1. The 0x0 address is a broadcast address
for this family of PHYs, and should not be used explicitly.
Fixes:
8c7ba536e709 ("ARM: sun8i: bananapi-m2-plus: Enable dwmac-sun8i")
Fixes:
4904337fe34f ("ARM: dts: sunxi: Restore EMAC changes (boards)")
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Philipp Rossak [Wed, 1 Aug 2018 09:48:01 +0000 (11:48 +0200)]
ARM: dts: sun8i: h3-h5: ir register size should be the whole memory block
[ Upstream commit
6c700289a3e84d5d3f2a95cf27732a7f7fce105b ]
The size of the register should be the size of the whole memory block,
not just the registers, that are needed.
Signed-off-by: Philipp Rossak <embed3d@gmail.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jaegeuk Kim [Tue, 25 Sep 2018 22:25:21 +0000 (15:25 -0700)]
f2fs: return correct errno in f2fs_gc
[ Upstream commit
61f7725aa148ee870436a29d3a24d5c00ab7e9af ]
This fixes overriding error number in f2fs_gc.
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Huazhong Tan [Wed, 26 Sep 2018 18:28:40 +0000 (19:28 +0100)]
net: hns3: Fix loss of coal configuration while doing reset
[ Upstream commit
e4fd75022c24eb28cc1034e97e60cecc24f325f3 ]
The user's coal configuration will be lost after reset, so the tx_coal
and rx_coal fields are added to the struct hns_nic_priv to save the coal
configuration and used to restore the user's configuration after the reset
is complete.
Fixes:
bb6b94a896d4 ("net: hns3: Add reset interface implementation in client")
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yunsheng Lin [Wed, 26 Sep 2018 18:28:37 +0000 (19:28 +0100)]
net: hns3: Fix for netdev not up problem when setting mtu
[ Upstream commit
93d8daf460183871a965dae339839d9e35d44309 ]
Currently hns3_nic_change_mtu will try to down the netdev before
setting mtu, and it does not up the netdev when the setting fails,
which causes netdev not up problem.
This patch fixes it by not returning when the setting fails.
Fixes:
a8e8b7ff3517 ("net: hns3: Add support to change MTU in HNS3 hardware")
Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
H. Nikolaus Schaller [Fri, 28 Sep 2018 15:54:00 +0000 (17:54 +0200)]
ARM: dts: omap5: enable OTG role for DWC3 controller
[ Upstream commit
656c1a65ab555ee5c7cd0d6aee8ab82ca3c1795f ]
Since SMPS10 and OTG cable detection extcon are described here, and
work to enable OTG power when an OTG cable is plugged in, we can
define OTG mode in the controller (which is disabled by default in
omap5.dtsi).
Tested on OMAP5EVM and Pyra.
Suggested-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Vignesh R [Fri, 28 Sep 2018 06:04:42 +0000 (11:34 +0530)]
ARM: dts: dra7: Enable workaround for errata i870 in PCIe host mode
[ Upstream commit
b830526f304764753fcb8b4a563a94080e982a6c ]
Add ti,syscon-unaligned-access property to PCIe RC nodes to set
appropriate bits in CTRL_CORE_SMA_SW_7 register to enable workaround for
errata i870.
Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
YueHaibing [Wed, 26 Sep 2018 09:18:14 +0000 (17:18 +0800)]
net: xen-netback: fix return type of ndo_start_xmit function
[ Upstream commit
a9ca7f17c6d240e269a24cbcd76abf9a940309dd ]
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, so make sure the implementation in
this driver has returns 'netdev_tx_t' value, and change the function
return type to netdev_tx_t.
Found by coccinelle.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
YueHaibing [Wed, 26 Sep 2018 09:15:38 +0000 (17:15 +0800)]
net: ovs: fix return type of ndo_start_xmit function
[ Upstream commit
eddf11e18dff0e8671e06ce54e64cfc843303ab9 ]
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, so make sure the implementation in
this driver has returns 'netdev_tx_t' value, and change the function
return type to netdev_tx_t.
Found by coccinelle.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Wang YanQing [Sat, 27 Apr 2019 08:28:26 +0000 (16:28 +0800)]
bpf, x32: Fix bug for BPF_JMP | {BPF_JSGT, BPF_JSLE, BPF_JSLT, BPF_JSGE}
commit
711aef1bbf88212a21f7103e88f397b47a528805 upstream.
The current method to compare 64-bit numbers for conditional jump is:
1) Compare the high 32-bit first.
2) If the high 32-bit isn't the same, then goto step 4.
3) Compare the low 32-bit.
4) Check the desired condition.
This method is right for unsigned comparison, but it is buggy for signed
comparison, because it does signed comparison for low 32-bit too.
There is only one sign bit in 64-bit number, that is the MSB in the 64-bit
number, it is wrong to treat low 32-bit as signed number and do the signed
comparison for it.
This patch fixes the bug and adds a testcase in selftests/bpf for such bug.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=205469
Reported-by: Tony Ambardar <itugrok@yahoo.com>
Cc: Tony Ambardar <itugrok@yahoo.com>
Cc: stable@vger.kernel.org #v4.19
Signed-off-by: Wang YanQing <udknight@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Luke Nelson [Sat, 29 Jun 2019 05:57:50 +0000 (22:57 -0700)]
bpf, x32: Fix bug with ALU64 {LSH, RSH, ARSH} BPF_K shift by 0
commit
6fa632e719eec4d1b1ebf3ddc0b2d667997b057b upstream.
The current x32 BPF JIT does not correctly compile shift operations when
the immediate shift amount is 0. The expected behavior is for this to
be a no-op.
The following program demonstrates the bug. The expexceted result is 1,
but the current JITed code returns 2.
r0 = 1
r1 = 1
r1 <<= 0
if r1 == 1 goto end
r0 = 2
end:
exit
This patch simplifies the code and fixes the bug.
Fixes:
03f5781be2c7 ("bpf, x86_32: add eBPF JIT compiler for ia32")
Co-developed-by: Xi Wang <xi.wang@gmail.com>
Signed-off-by: Xi Wang <xi.wang@gmail.com>
Signed-off-by: Luke Nelson <luke.r.nels@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Wang YanQing <udknight@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Luke Nelson [Sat, 29 Jun 2019 05:57:49 +0000 (22:57 -0700)]
bpf, x32: Fix bug with ALU64 {LSH, RSH, ARSH} BPF_X shift by 0
commit
68a8357ec15bdce55266e9fba8b8b3b8143fa7d2 upstream.
The current x32 BPF JIT for shift operations is not correct when the
shift amount in a register is 0. The expected behavior is a no-op, whereas
the current implementation changes bits in the destination register.
The following example demonstrates the bug. The expected result of this
program is 1, but the current JITed code returns 2.
r0 = 1
r1 = 1
r2 = 0
r1 <<= r2
if r1 == 1 goto end
r0 = 2
end:
exit
The bug is caused by an incorrect assumption by the JIT that a shift by
32 clear the register. On x32 however, shifts use the lower 5 bits of
the source, making a shift by 32 equivalent to a shift by 0.
This patch fixes the bug using double-precision shifts, which also
simplifies the code.
Fixes:
03f5781be2c7 ("bpf, x86_32: add eBPF JIT compiler for ia32")
Co-developed-by: Xi Wang <xi.wang@gmail.com>
Signed-off-by: Xi Wang <xi.wang@gmail.com>
Signed-off-by: Luke Nelson <luke.r.nels@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Wang YanQing <udknight@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Wang YanQing [Sun, 28 Apr 2019 02:33:02 +0000 (10:33 +0800)]
bpf, x32: Fix bug for BPF_ALU64 | BPF_NEG
commit
b9aa0b35d878dff9ed19f94101fe353a4de00cc4 upstream.
The current implementation has two errors:
1: The second xor instruction will clear carry flag which
is necessary for following sbb instruction.
2: The select coding for sbb instruction is wrong, the coding
is "sbb dreg_hi,ecx", but what we need is "sbb ecx,dreg_hi".
This patch rewrites the implementation and fixes the errors.
This patch fixes below errors reported by bpf/test_verifier in x32
platform when the jit is enabled:
"
0: (b4) w1 = 4
1: (b4) w2 = 4
2: (1f) r2 -= r1
3: (4f) r2 |= r1
4: (87) r2 = -r2
5: (c7) r2 s>>= 63
6: (5f) r1 &= r2
7: (bf) r0 = r1
8: (95) exit
processed 9 insns (limit 131072), stack depth 0
0: (b4) w1 = 4
1: (b4) w2 = 4
2: (1f) r2 -= r1
3: (4f) r2 |= r1
4: (87) r2 = -r2
5: (c7) r2 s>>= 63
6: (5f) r1 &= r2
7: (bf) r0 = r1
8: (95) exit
processed 9 insns (limit 131072), stack depth 0
......
Summary: 1189 PASSED, 125 SKIPPED, 15 FAILED
"
Signed-off-by: Wang YanQing <udknight@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniel Vetter [Sun, 21 Jul 2019 20:19:56 +0000 (22:19 +0200)]
fbdev: Ditch fb_edid_add_monspecs
commit
3b8720e63f4a1fc6f422a49ecbaa3b59c86d5aaf upstream.
It's dead code ever since
commit
34280340b1dc74c521e636f45cd728f9abf56ee2
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Fri Dec 4 17:01:43 2015 +0100
fbdev: Remove unused SH-Mobile HDMI driver
Also with this gone we can remove the cea_modes db. This entire thing
is massively incomplete anyway, compared to the CEA parsing that
drm_edid.c does.
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Tavis Ormandy <taviso@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190721201956.941-1-daniel.vetter@ffwll.ch
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pavel Tatashin [Tue, 19 Nov 2019 22:10:06 +0000 (17:10 -0500)]
arm64: uaccess: Ensure PAN is re-enabled after unhandled uaccess fault
commit
94bb804e1e6f0a9a77acf20d7c70ea141c6c821e upstream.
A number of our uaccess routines ('__arch_clear_user()' and
'__arch_copy_{in,from,to}_user()') fail to re-enable PAN if they
encounter an unhandled fault whilst accessing userspace.
For CPUs implementing both hardware PAN and UAO, this bug has no effect
when both extensions are in use by the kernel.
For CPUs implementing hardware PAN but not UAO, this means that a kernel
using hardware PAN may execute portions of code with PAN inadvertently
disabled, opening us up to potential security vulnerabilities that rely
on userspace access from within the kernel which would usually be
prevented by this mechanism. In other words, parts of the kernel run the
same way as they would on a CPU without PAN implemented/emulated at all.
For CPUs not implementing hardware PAN and instead relying on software
emulation via 'CONFIG_ARM64_SW_TTBR0_PAN=y', the impact is unfortunately
much worse. Calling 'schedule()' with software PAN disabled means that
the next task will execute in the kernel using the page-table and ASID
of the previous process even after 'switch_mm()', since the actual
hardware switch is deferred until return to userspace. At this point, or
if there is a intermediate call to 'uaccess_enable()', the page-table
and ASID of the new process are installed. Sadly, due to the changes
introduced by KPTI, this is not an atomic operation and there is a very
small window (two instructions) where the CPU is configured with the
page-table of the old task and the ASID of the new task; a speculative
access in this state is disastrous because it would corrupt the TLB
entries for the new task with mappings from the previous address space.
As Pavel explains:
| I was able to reproduce memory corruption problem on Broadcom's SoC
| ARMv8-A like this:
|
| Enable software perf-events with PERF_SAMPLE_CALLCHAIN so userland's
| stack is accessed and copied.
|
| The test program performed the following on every CPU and forking
| many processes:
|
| unsigned long *map = mmap(NULL, PAGE_SIZE, PROT_READ|PROT_WRITE,
| MAP_SHARED | MAP_ANONYMOUS, -1, 0);
| map[0] = getpid();
| sched_yield();
| if (map[0] != getpid()) {
| fprintf(stderr, "Corruption detected!");
| }
| munmap(map, PAGE_SIZE);
|
| From time to time I was getting map[0] to contain pid for a
| different process.
Ensure that PAN is re-enabled when returning after an unhandled user
fault from our uaccess routines.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Tested-by: Mark Rutland <mark.rutland@arm.com>
Cc: <stable@vger.kernel.org>
Fixes:
338d4f49d6f7 ("arm64: kernel: Add support for Privileged Access Never")
Signed-off-by: Pavel Tatashin <pasha.tatashin@soleen.com>
[will: rewrote commit message]
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Hildenbrand [Wed, 6 Nov 2019 05:17:10 +0000 (21:17 -0800)]
mm/memory_hotplug: fix updating the node span
commit
656d571193262a11c2daa4012e53e4d645bbce56 upstream.
We recently started updating the node span based on the zone span to
avoid touching uninitialized memmaps.
Currently, we will always detect the node span to start at 0, meaning a
node can easily span too many pages. pgdat_is_empty() will still work
correctly if all zones span no pages. We should skip over all zones
without spanned pages and properly handle the first detected zone that
spans pages.
Unfortunately, in contrast to the zone span (/proc/zoneinfo), the node
span cannot easily be inspected and tested. The node span gives no real
guarantees when an architecture supports memory hotplug, meaning it can
easily contain holes or span pages of different nodes.
The node span is not really used after init on architectures that
support memory hotplug.
E.g., we use it in mm/memory_hotplug.c:try_offline_node() and in
mm/kmemleak.c:kmemleak_scan(). These users seem to be fine.
Link: http://lkml.kernel.org/r/20191027222714.5313-1-david@redhat.com
Fixes:
00d6c019b5bc ("mm/memory_hotplug: don't access uninitialized memmaps in shrink_pgdat_span()")
Signed-off-by: David Hildenbrand <david@redhat.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Hildenbrand [Sat, 19 Oct 2019 03:19:33 +0000 (20:19 -0700)]
mm/memory_hotplug: don't access uninitialized memmaps in shrink_pgdat_span()
commit
00d6c019b5bc175cee3770e0e659f2b5f4804ea5 upstream.
We might use the nid of memmaps that were never initialized. For
example, if the memmap was poisoned, we will crash the kernel in
pfn_to_nid() right now. Let's use the calculated boundaries of the
separate zones instead. This now also avoids having to iterate over a
whole bunch of subsections again, after shrinking one zone.
Before commit
d0dc12e86b31 ("mm/memory_hotplug: optimize memory
hotplug"), the memmap was initialized to 0 and the node was set to the
right value. After that commit, the node might be garbage.
We'll have to fix shrink_zone_span() next.
Link: http://lkml.kernel.org/r/20191006085646.5768-4-david@redhat.com
Fixes:
f1dd2cd13c4b ("mm, memory_hotplug: do not associate hotadded memory to zones until online") [
d0dc12e86b319]
Signed-off-by: David Hildenbrand <david@redhat.com>
Reported-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: David Hildenbrand <david@redhat.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Wei Yang <richardw.yang@linux.intel.com>
Cc: Alexander Duyck <alexander.h.duyck@linux.intel.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: Damian Tometzki <damian.tometzki@gmail.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Halil Pasic <pasic@linux.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Jun Yao <yaojun8558363@gmail.com>
Cc: Logan Gunthorpe <logang@deltatee.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Mike Rapoport <rppt@linux.ibm.com>
Cc: Pankaj Gupta <pagupta@redhat.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Pavel Tatashin <pavel.tatashin@microsoft.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Qian Cai <cai@lca.pw>
Cc: Rich Felker <dalias@libc.org>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Steve Capper <steve.capper@arm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Will Deacon <will@kernel.org>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Cc: Yu Zhao <yuzhao@google.com>
Cc: <stable@vger.kernel.org> [4.13+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Matthew Wilcox (Oracle) [Tue, 14 May 2019 20:05:45 +0000 (16:05 -0400)]
idr: Fix idr_get_next race with idr_remove
commit
5c089fd0c73411f2170ab795c9ffc16718c7d007 upstream.
If the entry is deleted from the IDR between the call to
radix_tree_iter_find() and rcu_dereference_raw(), idr_get_next()
will return NULL, which will end the iteration prematurely. We should
instead continue to the next entry in the IDR. This only happens if the
iteration is protected by the RCU lock. Most IDR users use a spinlock
or semaphore to exclude simultaneous modifications. It was noticed once
the PID allocator was converted to use the IDR, as it uses the RCU lock,
but there may be other users elsewhere in the kernel.
We can't use the normal pattern of calling radix_tree_deref_retry()
(which catches both a retry entry in a leaf node and a node entry in
the root) as the IDR supports storing entries which are unaligned,
which will trigger an infinite loop if they are encountered. Instead,
we have to explicitly check whether the entry is a retry entry.
Fixes:
0a835c4f090a ("Reimplement IDR and IDA using the radix tree")
Reported-by: Brendan Gregg <bgregg@netflix.com>
Tested-by: Brendan Gregg <bgregg@netflix.com>
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>