* [PATCH AUTOSEL 5.4 102/459] RDMA/umem: Fix ib_umem_find_best_pgsz()
From: Sasha Levin @ 2020-02-14 15:55 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Artemy Kovalyov, Leon Romanovsky, Gal Pressman, Jason Gunthorpe,
Sasha Levin, linux-rdma
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Artemy Kovalyov <artemyko@mellanox.com>
[ Upstream commit 36798d5ae1af62e830c5e045b2e41ce038690c61 ]
Except for the last entry, the ending iova alignment sets the maximum
possible page size as the low bits of the iova must be zero when starting
the next chunk.
Fixes: 4a35339958f1 ("RDMA/umem: Add API to find best driver supported page size in an MR")
Link: https://lore.kernel.org/r/20200128135612.174820-1-leon@kernel.org
Signed-off-by: Artemy Kovalyov <artemyko@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Tested-by: Gal Pressman <galpress@amazon.com>
Reviewed-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/infiniband/core/umem.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
index 24244a2f68cc5..0d42ba8c0b696 100644
--- a/drivers/infiniband/core/umem.c
+++ b/drivers/infiniband/core/umem.c
@@ -166,10 +166,13 @@ unsigned long ib_umem_find_best_pgsz(struct ib_umem *umem,
* for any address.
*/
mask |= (sg_dma_address(sg) + pgoff) ^ va;
- if (i && i != (umem->nmap - 1))
- /* restrict by length as well for interior SGEs */
- mask |= sg_dma_len(sg);
va += sg_dma_len(sg) - pgoff;
+ /* Except for the last entry, the ending iova alignment sets
+ * the maximum possible page size as the low bits of the iova
+ * must be zero when starting the next chunk.
+ */
+ if (i != (umem->nmap - 1))
+ mask |= va;
pgoff = 0;
}
best_pg_bit = rdma_find_pg_bit(mask, pgsz_bitmap);
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 101/459] drm/amd/display: Retrain dongles when SINK_COUNT becomes non-zero
From: Sasha Levin @ 2020-02-14 15:55 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Harry Wentland, Louis Li, Wenjing Liu, Hersen Wu, Eric Yang,
Alex Deucher, Sasha Levin, amd-gfx, dri-devel
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Harry Wentland <harry.wentland@amd.com>
[ Upstream commit 3eb6d7aca53d81ce888624f09cd44dc0302161e8 ]
[WHY]
Two years ago the patch referenced by the Fixes tag stopped running
dp_verify_link_cap_with_retries during DP detection when the reason
for the detection was a short-pulse interrupt. This effectively meant
that we were no longer doing the verify_link_cap training on active
dongles when their SINK_COUNT changed from 0 to 1.
A year ago this was partly remedied with:
commit 80adaebd2d41 ("drm/amd/display: Don't skip link training for empty dongle")
This made sure that we trained the dongle on initial hotplug (without
connected downstream devices).
This is all fine and dandy if it weren't for the fact that there are
some dongles on the market that don't like link training when SINK_COUNT
is 0 These dongles will in fact indicate a SINK_COUNT of 0 immediately
after hotplug, even when a downstream device is connected, and then
trigger a shortpulse interrupt indicating a SINK_COUNT change to 1.
In order to play nicely we will need our policy to not link train an
active DP dongle when SINK_COUNT is 0 but ensure we train it when the
SINK_COUNT changes to 1.
[HOW]
Call dp_verify_link_cap_with_retries on detection even when the detection
is triggered from a short pulse interrupt.
With this change we can also revert this commit which we'll do in a separate
follow-up change:
commit 80adaebd2d41 ("drm/amd/display: Don't skip link training for empty dongle")
Fixes: 0301ccbaf67d ("drm/amd/display: DP Compliance 400.1.1 failure")
Suggested-by: Louis Li <Ching-shih.Li@amd.com>
Tested-by: Louis Li <Ching-shih.Li@amd.com>
Cc: Wenjing Liu <Wenjing.Liu@amd.com>
Cc: Hersen Wu <hersenxs.wu@amd.com>
Cc: Eric Yang <Eric.Yang2@amd.com>
Reviewed-by: Wenjing Liu <Wenjing.Liu@amd.com>
Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index c0f1c62c59b42..3aedc724241ef 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -948,8 +948,7 @@ bool dc_link_detect(struct dc_link *link, enum dc_detect_reason reason)
same_edid = is_same_edid(&prev_sink->dc_edid, &sink->dc_edid);
if (link->connector_signal == SIGNAL_TYPE_DISPLAY_PORT &&
- sink_caps.transaction_type == DDC_TRANSACTION_TYPE_I2C_OVER_AUX &&
- reason != DETECT_REASON_HPDRX) {
+ sink_caps.transaction_type == DDC_TRANSACTION_TYPE_I2C_OVER_AUX) {
/*
* TODO debug why Dell 2413 doesn't like
* two link trainings
--
2.20.1
^ permalink raw reply related
* Re: [PATCH AUTOSEL 5.5 418/542] pwm: Remove set but not set variable 'pwm'
From: Uwe Kleine-König @ 2020-02-14 17:40 UTC (permalink / raw)
To: Sasha Levin; +Cc: linux-kernel, stable, yu kuai, Thierry Reding, linux-pwm
In-Reply-To: <20200214154854.6746-418-sashal@kernel.org>
Hello Sasha,
On Fri, Feb 14, 2020 at 10:46:50AM -0500, Sasha Levin wrote:
> From: yu kuai <yukuai3@huawei.com>
>
> [ Upstream commit 9871abffc81048e20f02e15d6aa4558a44ad53ea ]
>
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/pwm/pwm-pca9685.c: In function ‘pca9685_pwm_gpio_free’:
> drivers/pwm/pwm-pca9685.c:162:21: warning: variable ‘pwm’ set but not used [-Wunused-but-set-variable]
>
> It is never used, and so can be removed. In that case, hold and release
> the lock 'pca->lock' can be removed since nothing will be done between
> them.
>
> Fixes: e926b12c611c ("pwm: Clear chip_data in pwm_put()")
> Signed-off-by: yu kuai <yukuai3@huawei.com>
> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> ---
> drivers/pwm/pwm-pca9685.c | 4 ----
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/pwm/pwm-pca9685.c b/drivers/pwm/pwm-pca9685.c
> index 168684b02ebce..b07bdca3d510d 100644
> --- a/drivers/pwm/pwm-pca9685.c
> +++ b/drivers/pwm/pwm-pca9685.c
> @@ -159,13 +159,9 @@ static void pca9685_pwm_gpio_set(struct gpio_chip *gpio, unsigned int offset,
> static void pca9685_pwm_gpio_free(struct gpio_chip *gpio, unsigned int offset)
> {
> struct pca9685 *pca = gpiochip_get_data(gpio);
> - struct pwm_device *pwm;
>
> pca9685_pwm_gpio_set(gpio, offset, 0);
> pm_runtime_put(pca->chip.dev);
> - mutex_lock(&pca->lock);
> - pwm = &pca->chip.pwms[offset];
> - mutex_unlock(&pca->lock);
Even though I bet this change won't introduce a regression, it only
fixes a harmless warning. So I wonder if it objectively qualifies to be
applied for stable.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH v26 10/22] x86/sgx: Linux Enclave Driver
From: Andy Lutomirski @ 2020-02-14 17:40 UTC (permalink / raw)
To: Sean Christopherson
Cc: Jethro Beekman, Jarkko Sakkinen, linux-kernel, x86, linux-sgx,
akpm, dave.hansen, nhorman, npmccallum, haitao.huang,
andriy.shevchenko, tglx, kai.svahn, bp, josh, luto, kai.huang,
rientjes, cedric.xing, puiterwijk, linux-security-module,
Haitao Huang
In-Reply-To: <20200214171146.GD20690@linux.intel.com>
> On Feb 14, 2020, at 9:11 AM, Sean Christopherson <sean.j.christopherson@intel.com> wrote:
>
> On Fri, Feb 14, 2020 at 10:24:10AM +0100, Jethro Beekman wrote:
>>> On 2020-02-13 19:07, Sean Christopherson wrote:
>>> On Thu, Feb 13, 2020 at 02:59:52PM +0100, Jethro Beekman wrote:
>>>> On 2020-02-09 22:25, Jarkko Sakkinen wrote:
>>>>> +/**
>>>>> + * struct sgx_enclave_add_pages - parameter structure for the
>>>>> + * %SGX_IOC_ENCLAVE_ADD_PAGE ioctl
>>>>> + * @src: start address for the page data
>>>>> + * @offset: starting page offset
>>>>> + * @length: length of the data (multiple of the page size)
>>>>> + * @secinfo: address for the SECINFO data
>>>>> + * @flags: page control flags
>>>>> + * @count: number of bytes added (multiple of the page size)
>>>>> + */
>>>>> +struct sgx_enclave_add_pages {
>>>>> + __u64 src;
>>>>> + __u64 offset;
>>>>> + __u64 length;
>>>>> + __u64 secinfo;
>>>>> + __u64 flags;
>>>>> + __u64 count;
>>>>> +};
>>>>
>>>> Compared to the last time I looked at the patch set, this API removes the
>>>> ability to measure individual pages chunks. That is not acceptable.
>>>
>>> Why is it not acceptable? E.g. what specific use case do you have that
>>> _requires_ on measuring partial 4k pages of an enclave?
>>
>> The use case is someone gives me an enclave and I want to load it. If I don't
>> load it exactly as the enclave author specified, the enclave hash will be
>> different, and it won't work.
>
> And if our ABI says "thou shall measure in 4k chunks", then it's an invalid
> enclave if its author generated MRENCLAVE using a different granularity.
ISTM, unless there’s a particularly compelling reason, if an enclave is valid, we should be able to load it.
^ permalink raw reply
* [PATCH AUTOSEL 5.4 099/459] selftests: settings: tests can be in subsubdirs
From: Sasha Levin @ 2020-02-14 15:55 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Matthieu Baerts, Kees Cook, Shuah Khan, Sasha Levin,
linux-kselftest
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Matthieu Baerts <matthieu.baerts@tessares.net>
[ Upstream commit ac87813d4372f4c005264acbe3b7f00c1dee37c4 ]
Commit 852c8cbf34d3 ("selftests/kselftest/runner.sh: Add 45 second
timeout per test") adds support for a new per-test-directory "settings"
file. But this only works for tests not in a sub-subdirectories, e.g.
- tools/testing/selftests/rtc (rtc) is OK,
- tools/testing/selftests/net/mptcp (net/mptcp) is not.
We have to increase the timeout for net/mptcp tests which are not
upstreamed yet but this fix is valid for other tests if they need to add
a "settings" file, see the full list with:
tools/testing/selftests/*/*/**/Makefile
Note that this patch changes the text header message printed at the end
of the execution but this text is modified only for the tests that are
in sub-subdirectories, e.g.
ok 1 selftests: net/mptcp: mptcp_connect.sh
Before we had:
ok 1 selftests: mptcp: mptcp_connect.sh
But showing the full target name is probably better, just in case a
subsubdir has the same name as another one in another subdirectory.
Fixes: 852c8cbf34d3 (selftests/kselftest/runner.sh: Add 45 second timeout per test)
Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
tools/testing/selftests/kselftest/runner.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/kselftest/runner.sh b/tools/testing/selftests/kselftest/runner.sh
index a8d20cbb711cf..e84d901f85672 100644
--- a/tools/testing/selftests/kselftest/runner.sh
+++ b/tools/testing/selftests/kselftest/runner.sh
@@ -91,7 +91,7 @@ run_one()
run_many()
{
echo "TAP version 13"
- DIR=$(basename "$PWD")
+ DIR="${PWD#${BASE_DIR}/}"
test_num=0
total=$(echo "$@" | wc -w)
echo "1..$total"
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 098/459] watchdog: qcom: Use platform_get_irq_optional() for bark irq
From: Sasha Levin @ 2020-02-14 15:55 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sai Prakash Ranjan, Bjorn Andersson, Guenter Roeck, Stephen Boyd,
Wim Van Sebroeck, Sasha Levin, linux-arm-msm, linux-watchdog
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
[ Upstream commit e0b4f4e0cf7fa9d62628d4249c765ec18dffd143 ]
platform_get_irq() prints an error message when the interrupt
is not available. So on platforms where bark interrupt is
not specified, following error message is observed on SDM845.
[ 2.975888] qcom_wdt 17980000.watchdog: IRQ index 0 not found
This is also seen on SC7180, SM8150 SoCs as well.
Fix this by using platform_get_irq_optional() instead.
Fixes: 36375491a4395654 ("watchdog: qcom: support pre-timeout when the bark irq is available")
Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20191213064934.4112-1-saiprakash.ranjan@codeaurora.org
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>
---
drivers/watchdog/qcom-wdt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/watchdog/qcom-wdt.c b/drivers/watchdog/qcom-wdt.c
index a494543d3ae1b..eb47fe5ed2805 100644
--- a/drivers/watchdog/qcom-wdt.c
+++ b/drivers/watchdog/qcom-wdt.c
@@ -246,7 +246,7 @@ static int qcom_wdt_probe(struct platform_device *pdev)
}
/* check if there is pretimeout support */
- irq = platform_get_irq(pdev, 0);
+ irq = platform_get_irq_optional(pdev, 0);
if (irq > 0) {
ret = devm_request_irq(dev, irq, qcom_wdt_isr,
IRQF_TRIGGER_RISING,
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 097/459] drivers: watchdog: stm32_iwdg: set WDOG_HW_RUNNING at probe
From: Sasha Levin @ 2020-02-14 15:55 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Christophe Roullier, Guenter Roeck, Wim Van Sebroeck, Sasha Levin,
linux-watchdog, linux-stm32, linux-arm-kernel
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Christophe Roullier <christophe.roullier@st.com>
[ Upstream commit 85fdc63fe256b595f923a69848cd99972ff446d8 ]
If the watchdog hardware is already enabled during the boot process,
when the Linux watchdog driver loads, it should start/reset the watchdog
and tell the watchdog framework. As a result, ping can be generated from
the watchdog framework (if CONFIG_WATCHDOG_HANDLE_BOOT_ENABLED is set),
until the userspace watchdog daemon takes over control
Fixes:4332d113c66a ("watchdog: Add STM32 IWDG driver")
Signed-off-by: Christophe Roullier <christophe.roullier@st.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20191122132246.8473-1-christophe.roullier@st.com
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>
---
drivers/watchdog/stm32_iwdg.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/drivers/watchdog/stm32_iwdg.c b/drivers/watchdog/stm32_iwdg.c
index a3a329011a06b..25188d6bbe152 100644
--- a/drivers/watchdog/stm32_iwdg.c
+++ b/drivers/watchdog/stm32_iwdg.c
@@ -262,6 +262,24 @@ static int stm32_iwdg_probe(struct platform_device *pdev)
watchdog_set_nowayout(wdd, WATCHDOG_NOWAYOUT);
watchdog_init_timeout(wdd, 0, dev);
+ /*
+ * In case of CONFIG_WATCHDOG_HANDLE_BOOT_ENABLED is set
+ * (Means U-Boot/bootloaders leaves the watchdog running)
+ * When we get here we should make a decision to prevent
+ * any side effects before user space daemon will take care of it.
+ * The best option, taking into consideration that there is no
+ * way to read values back from hardware, is to enforce watchdog
+ * being run with deterministic values.
+ */
+ if (IS_ENABLED(CONFIG_WATCHDOG_HANDLE_BOOT_ENABLED)) {
+ ret = stm32_iwdg_start(wdd);
+ if (ret)
+ return ret;
+
+ /* Make sure the watchdog is serviced */
+ set_bit(WDOG_HW_RUNNING, &wdd->status);
+ }
+
ret = devm_watchdog_register_device(dev, wdd);
if (ret)
return ret;
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 095/459] libertas: don't exit from lbs_ibss_join_existing() with RCU read lock held
From: Sasha Levin @ 2020-02-14 15:55 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Nicolai Stange, Kalle Valo, Sasha Levin, libertas-dev,
linux-wireless, netdev
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Nicolai Stange <nstange@suse.de>
[ Upstream commit c7bf1fb7ddca331780b9a733ae308737b39f1ad4 ]
Commit e5e884b42639 ("libertas: Fix two buffer overflows at parsing bss
descriptor") introduced a bounds check on the number of supplied rates to
lbs_ibss_join_existing().
Unfortunately, it introduced a return path from within a RCU read side
critical section without a corresponding rcu_read_unlock(). Fix this.
Fixes: e5e884b42639 ("libertas: Fix two buffer overflows at parsing bss descriptor")
Signed-off-by: Nicolai Stange <nstange@suse.de>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/marvell/libertas/cfg.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/marvell/libertas/cfg.c b/drivers/net/wireless/marvell/libertas/cfg.c
index c9401c121a14e..68985d7663491 100644
--- a/drivers/net/wireless/marvell/libertas/cfg.c
+++ b/drivers/net/wireless/marvell/libertas/cfg.c
@@ -1785,6 +1785,7 @@ static int lbs_ibss_join_existing(struct lbs_private *priv,
rates_max = rates_eid[1];
if (rates_max > MAX_RATES) {
lbs_deb_join("invalid rates");
+ rcu_read_unlock();
goto out;
}
rates = cmd.bss.rates;
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 089/459] powerpc/pseries/vio: Fix iommu_table use-after-free refcount warning
From: Sasha Levin @ 2020-02-14 15:55 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Tyrel Datwyler, Tyrel Datwyler, Alexey Kardashevskiy,
Michael Ellerman, Sasha Levin, linuxppc-dev
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
[ Upstream commit aff8c8242bc638ba57247ae1ec5f272ac3ed3b92 ]
Commit e5afdf9dd515 ("powerpc/vfio_spapr_tce: Add reference counting to
iommu_table") missed an iommu_table allocation in the pseries vio code.
The iommu_table is allocated with kzalloc and as a result the associated
kref gets a value of zero. This has the side effect that during a DLPAR
remove of the associated virtual IOA the iommu_tce_table_put() triggers
a use-after-free underflow warning.
Call Trace:
[c0000002879e39f0] [c00000000071ecb4] refcount_warn_saturate+0x184/0x190
(unreliable)
[c0000002879e3a50] [c0000000000500ac] iommu_tce_table_put+0x9c/0xb0
[c0000002879e3a70] [c0000000000f54e4] vio_dev_release+0x34/0x70
[c0000002879e3aa0] [c00000000087cfa4] device_release+0x54/0xf0
[c0000002879e3b10] [c000000000d64c84] kobject_cleanup+0xa4/0x240
[c0000002879e3b90] [c00000000087d358] put_device+0x28/0x40
[c0000002879e3bb0] [c0000000007a328c] dlpar_remove_slot+0x15c/0x250
[c0000002879e3c50] [c0000000007a348c] remove_slot_store+0xac/0xf0
[c0000002879e3cd0] [c000000000d64220] kobj_attr_store+0x30/0x60
[c0000002879e3cf0] [c0000000004ff13c] sysfs_kf_write+0x6c/0xa0
[c0000002879e3d10] [c0000000004fde4c] kernfs_fop_write+0x18c/0x260
[c0000002879e3d60] [c000000000410f3c] __vfs_write+0x3c/0x70
[c0000002879e3d80] [c000000000415408] vfs_write+0xc8/0x250
[c0000002879e3dd0] [c0000000004157dc] ksys_write+0x7c/0x120
[c0000002879e3e20] [c00000000000b278] system_call+0x5c/0x68
Further, since the refcount was always zero the iommu_tce_table_put()
fails to call the iommu_table release function resulting in a leak.
Fix this issue be initilizing the iommu_table kref immediately after
allocation.
Fixes: e5afdf9dd515 ("powerpc/vfio_spapr_tce: Add reference counting to iommu_table")
Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com>
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1579558202-26052-1-git-send-email-tyreld@linux.ibm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/platforms/pseries/vio.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/platforms/pseries/vio.c b/arch/powerpc/platforms/pseries/vio.c
index 79e2287991dbb..f682b7babc09c 100644
--- a/arch/powerpc/platforms/pseries/vio.c
+++ b/arch/powerpc/platforms/pseries/vio.c
@@ -1176,6 +1176,8 @@ static struct iommu_table *vio_build_iommu_table(struct vio_dev *dev)
if (tbl == NULL)
return NULL;
+ kref_init(&tbl->it_kref);
+
of_parse_dma_window(dev->dev.of_node, dma_window,
&tbl->it_index, &offset, &size);
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 096/459] libertas: make lbs_ibss_join_existing() return error code on rates overflow
From: Sasha Levin @ 2020-02-14 15:55 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Nicolai Stange, Kalle Valo, Sasha Levin, libertas-dev,
linux-wireless, netdev
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Nicolai Stange <nstange@suse.de>
[ Upstream commit 1754c4f60aaf1e17d886afefee97e94d7f27b4cb ]
Commit e5e884b42639 ("libertas: Fix two buffer overflows at parsing bss
descriptor") introduced a bounds check on the number of supplied rates to
lbs_ibss_join_existing() and made it to return on overflow.
However, the aforementioned commit doesn't set the return value accordingly
and thus, lbs_ibss_join_existing() would return with zero even though it
failed.
Make lbs_ibss_join_existing return -EINVAL in case the bounds check on the
number of supplied rates fails.
Fixes: e5e884b42639 ("libertas: Fix two buffer overflows at parsing bss descriptor")
Signed-off-by: Nicolai Stange <nstange@suse.de>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/marvell/libertas/cfg.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/marvell/libertas/cfg.c b/drivers/net/wireless/marvell/libertas/cfg.c
index 68985d7663491..4e3de684928bf 100644
--- a/drivers/net/wireless/marvell/libertas/cfg.c
+++ b/drivers/net/wireless/marvell/libertas/cfg.c
@@ -1786,6 +1786,7 @@ static int lbs_ibss_join_existing(struct lbs_private *priv,
if (rates_max > MAX_RATES) {
lbs_deb_join("invalid rates");
rcu_read_unlock();
+ ret = -EINVAL;
goto out;
}
rates = cmd.bss.rates;
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 093/459] rtw88: fix rate mask for 1SS chip
From: Sasha Levin @ 2020-02-14 15:55 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Ping-Ke Shih, Yan-Hsuan Chuang, Chris Chiu, Kalle Valo,
Sasha Levin, linux-wireless, netdev
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Ping-Ke Shih <pkshih@realtek.com>
[ Upstream commit 35a68fa5f96a80797e11b6952a47c5a84939a7bf ]
The rate mask is used to tell firmware the supported rate depends on
negotiation. We loop 2 times for all VHT/HT 2SS rate mask first, and then
only keep the part according to chip's NSS.
This commit fixes the logic error of '&' operations for VHT/HT rate, and
we should run this logic before adding legacy rate.
To access HT MCS map, index 0/1 represent MCS 0-7/8-15 respectively. Use
NL80211_BAND_xxx is incorrect, so fix it as well.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Reviewed-by: Chris Chiu <chiu@endlessm.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/realtek/rtw88/main.c | 12 +++++-------
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw88/main.c b/drivers/net/wireless/realtek/rtw88/main.c
index 806af37192bc2..88e2252bf8a2b 100644
--- a/drivers/net/wireless/realtek/rtw88/main.c
+++ b/drivers/net/wireless/realtek/rtw88/main.c
@@ -556,8 +556,8 @@ void rtw_update_sta_info(struct rtw_dev *rtwdev, struct rtw_sta_info *si)
if (sta->vht_cap.cap & IEEE80211_VHT_CAP_SHORT_GI_80)
is_support_sgi = true;
} else if (sta->ht_cap.ht_supported) {
- ra_mask |= (sta->ht_cap.mcs.rx_mask[NL80211_BAND_5GHZ] << 20) |
- (sta->ht_cap.mcs.rx_mask[NL80211_BAND_2GHZ] << 12);
+ ra_mask |= (sta->ht_cap.mcs.rx_mask[1] << 20) |
+ (sta->ht_cap.mcs.rx_mask[0] << 12);
if (sta->ht_cap.cap & IEEE80211_HT_CAP_RX_STBC)
stbc_en = HT_STBC_EN;
if (sta->ht_cap.cap & IEEE80211_HT_CAP_LDPC_CODING)
@@ -567,6 +567,9 @@ void rtw_update_sta_info(struct rtw_dev *rtwdev, struct rtw_sta_info *si)
is_support_sgi = true;
}
+ if (efuse->hw_cap.nss == 1)
+ ra_mask &= RA_MASK_VHT_RATES_1SS | RA_MASK_HT_RATES_1SS;
+
if (hal->current_band_type == RTW_BAND_5G) {
ra_mask |= (u64)sta->supp_rates[NL80211_BAND_5GHZ] << 4;
if (sta->vht_cap.vht_supported) {
@@ -600,11 +603,6 @@ void rtw_update_sta_info(struct rtw_dev *rtwdev, struct rtw_sta_info *si)
wireless_set = 0;
}
- if (efuse->hw_cap.nss == 1) {
- ra_mask &= RA_MASK_VHT_RATES_1SS;
- ra_mask &= RA_MASK_HT_RATES_1SS;
- }
-
switch (sta->bandwidth) {
case IEEE80211_STA_RX_BW_80:
bw_mode = RTW_CHANNEL_WIDTH_80;
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 094/459] brcmfmac: sdio: Fix OOB interrupt initialization on brcm43362
From: Sasha Levin @ 2020-02-14 15:55 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Jean-Philippe Brucker, Arend van Spriel, Kalle Valo, Sasha Levin,
linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
netdev
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Jean-Philippe Brucker <jean-philippe@linaro.org>
[ Upstream commit 8c8e60fb86a90a30721bbd797f58f96b3980dcc1 ]
Commit 262f2b53f679 ("brcmfmac: call brcmf_attach() just before calling
brcmf_bus_started()") changed the initialization order of the brcmfmac
SDIO driver. Unfortunately since brcmf_sdiod_intr_register() is now
called before the sdiodev->bus_if initialization, it reads the wrong
chip ID and fails to initialize the GPIO on brcm43362. Thus the chip
cannot send interrupts and fails to probe:
[ 12.517023] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
[ 12.531214] ieee80211 phy0: brcmf_bus_started: failed: -110
[ 12.536976] ieee80211 phy0: brcmf_attach: dongle is not responding: err=-110
[ 12.566467] brcmfmac: brcmf_sdio_firmware_callback: brcmf_attach failed
Initialize the bus interface earlier to ensure that
brcmf_sdiod_intr_register() properly sets up the OOB interrupt.
BugLink: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908438
Fixes: 262f2b53f679 ("brcmfmac: call brcmf_attach() just before calling brcmf_bus_started()")
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
.../net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index 1dea0178832ea..a935993a3c514 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -4226,6 +4226,12 @@ static void brcmf_sdio_firmware_callback(struct device *dev, int err,
}
if (err == 0) {
+ /* Assign bus interface call back */
+ sdiod->bus_if->dev = sdiod->dev;
+ sdiod->bus_if->ops = &brcmf_sdio_bus_ops;
+ sdiod->bus_if->chip = bus->ci->chip;
+ sdiod->bus_if->chiprev = bus->ci->chiprev;
+
/* Allow full data communication using DPC from now on. */
brcmf_sdiod_change_state(bus->sdiodev, BRCMF_SDIOD_DATA);
@@ -4242,12 +4248,6 @@ static void brcmf_sdio_firmware_callback(struct device *dev, int err,
sdio_release_host(sdiod->func1);
- /* Assign bus interface call back */
- sdiod->bus_if->dev = sdiod->dev;
- sdiod->bus_if->ops = &brcmf_sdio_bus_ops;
- sdiod->bus_if->chip = bus->ci->chip;
- sdiod->bus_if->chiprev = bus->ci->chiprev;
-
err = brcmf_alloc(sdiod->dev, sdiod->settings);
if (err) {
brcmf_err("brcmf_alloc failed\n");
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 092/459] ath10k: Correct the DMA direction for management tx buffers
From: Sasha Levin @ 2020-02-14 15:55 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Rakesh Pillai, Kalle Valo, Sasha Levin, ath10k, linux-wireless,
netdev
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Rakesh Pillai <pillair@codeaurora.org>
[ Upstream commit 6ba8b3b6bd772f575f7736c8fd893c6981fcce16 ]
The management packets, send to firmware via WMI, are
mapped using the direction DMA_TO_DEVICE. Currently in
case of wmi cleanup, these buffers are being unmapped
using an incorrect DMA direction. This can cause unwanted
behavior when the host driver is handling a restart
of the wlan firmware.
We might see a trace like below
[<ffffff8008098b18>] __dma_inv_area+0x28/0x58
[<ffffff8001176734>] ath10k_wmi_mgmt_tx_clean_up_pending+0x60/0xb0 [ath10k_core]
[<ffffff80088c7c50>] idr_for_each+0x78/0xe4
[<ffffff80011766a4>] ath10k_wmi_detach+0x4c/0x7c [ath10k_core]
[<ffffff8001163d7c>] ath10k_core_stop+0x58/0x68 [ath10k_core]
[<ffffff800114fb74>] ath10k_halt+0xec/0x13c [ath10k_core]
[<ffffff8001165110>] ath10k_core_restart+0x11c/0x1a8 [ath10k_core]
[<ffffff80080c36bc>] process_one_work+0x16c/0x31c
Fix the incorrect DMA direction during the wmi
management tx buffer cleanup.
Tested HW: WCN3990
Tested FW: WLAN.HL.3.1-00784-QCAHLSWMTPLZ-1
Fixes: dc405152bb6 ("ath10k: handle mgmt tx completion event")
Signed-off-by: Rakesh Pillai <pillair@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/ath/ath10k/wmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index 4f707c6394bba..90f1197a6ad84 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -9422,7 +9422,7 @@ static int ath10k_wmi_mgmt_tx_clean_up_pending(int msdu_id, void *ptr,
msdu = pkt_addr->vaddr;
dma_unmap_single(ar->dev, pkt_addr->paddr,
- msdu->len, DMA_FROM_DEVICE);
+ msdu->len, DMA_TO_DEVICE);
ieee80211_free_txskb(ar->hw, msdu);
return 0;
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] kvm/emulate: fix a -Werror=cast-function-type
From: Jim Mattson @ 2020-02-14 17:40 UTC (permalink / raw)
To: Qian Cai
Cc: Sean Christopherson, Paolo Bonzini, Vitaly Kuznetsov, Wanpeng Li,
Joerg Roedel, kvm list, LKML
In-Reply-To: <1581700124.7365.70.camel@lca.pw>
On Fri, Feb 14, 2020 at 9:08 AM Qian Cai <cai@lca.pw> wrote:
>
> On Fri, 2020-02-14 at 08:59 -0800, Sean Christopherson wrote:
> > On Fri, Feb 14, 2020 at 10:56:08AM -0500, Qian Cai wrote:
> > > arch/x86/kvm/emulate.c: In function 'x86_emulate_insn':
> > > arch/x86/kvm/emulate.c:5686:22: error: cast between incompatible
> > > function types from 'int (*)(struct x86_emulate_ctxt *)' to 'void
> > > (*)(struct fastop *)' [-Werror=cast-function-type]
> > > rc = fastop(ctxt, (fastop_t)ctxt->execute);
> > >
> > > Fixes: 3009afc6e39e ("KVM: x86: Use a typedef for fastop functions")
> > > Signed-off-by: Qian Cai <cai@lca.pw>
> > > ---
> > > arch/x86/kvm/emulate.c | 8 +++++---
> > > 1 file changed, 5 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
> > > index ddbc61984227..17ae820cf59d 100644
> > > --- a/arch/x86/kvm/emulate.c
> > > +++ b/arch/x86/kvm/emulate.c
> > > @@ -5682,10 +5682,12 @@ int x86_emulate_insn(struct x86_emulate_ctxt *ctxt)
> > > ctxt->eflags &= ~X86_EFLAGS_RF;
> > >
> > > if (ctxt->execute) {
> > > - if (ctxt->d & Fastop)
> > > - rc = fastop(ctxt, (fastop_t)ctxt->execute);
> >
> > Alternatively, can we do -Wno-cast-function-type? That's a silly warning
> > IMO.
>
> I am doing W=1 on linux-next where some of the warnings might be silly but the
> recent commit changes all warnings to errors forces me having to silence those
> somehow.
>
> >
> > If not, will either of these work?
> >
> > rc = fastop(ctxt, (void *)ctxt->execute);
> >
> > or
> > rc = fastop(ctxt, (fastop_t)(void *)ctxt->execute);
>
> I have no strong preference. I originally thought just to go back the previous
> code style where might be more acceptable, but it is up to maintainers.
It seems misguided to define a local variable just to get an implicit
cast from (void *) to (fastop_t). Sean's first suggestion gives you
the same implicit cast without the local variable. The second
suggestion makes both casts explicit.
^ permalink raw reply
* [PATCH AUTOSEL 5.4 091/459] ext4, jbd2: ensure panic when aborting with zero errno
From: Sasha Levin @ 2020-02-14 15:55 UTC (permalink / raw)
To: linux-kernel, stable
Cc: zhangyi (F), Jan Kara, Theodore Ts'o, Sasha Levin, linux-ext4
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: "zhangyi (F)" <yi.zhang@huawei.com>
[ Upstream commit 51f57b01e4a3c7d7bdceffd84de35144e8c538e7 ]
JBD2_REC_ERR flag used to indicate the errno has been updated when jbd2
aborted, and then __ext4_abort() and ext4_handle_error() can invoke
panic if ERRORS_PANIC is specified. But if the journal has been aborted
with zero errno, jbd2_journal_abort() didn't set this flag so we can
no longer panic. Fix this by always record the proper errno in the
journal superblock.
Fixes: 4327ba52afd03 ("ext4, jbd2: ensure entering into panic after recording an error in superblock")
Signed-off-by: zhangyi (F) <yi.zhang@huawei.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/20191204124614.45424-3-yi.zhang@huawei.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/jbd2/checkpoint.c | 2 +-
fs/jbd2/journal.c | 15 ++++-----------
2 files changed, 5 insertions(+), 12 deletions(-)
diff --git a/fs/jbd2/checkpoint.c b/fs/jbd2/checkpoint.c
index a1909066bde66..62cf497f18eb4 100644
--- a/fs/jbd2/checkpoint.c
+++ b/fs/jbd2/checkpoint.c
@@ -164,7 +164,7 @@ void __jbd2_log_wait_for_space(journal_t *journal)
"journal space in %s\n", __func__,
journal->j_devname);
WARN_ON(1);
- jbd2_journal_abort(journal, 0);
+ jbd2_journal_abort(journal, -EIO);
}
write_lock(&journal->j_state_lock);
} else {
diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c
index 389c9be4e7919..65e78d3a2f64c 100644
--- a/fs/jbd2/journal.c
+++ b/fs/jbd2/journal.c
@@ -2123,12 +2123,10 @@ static void __journal_abort_soft (journal_t *journal, int errno)
__jbd2_journal_abort_hard(journal);
- if (errno) {
- jbd2_journal_update_sb_errno(journal);
- write_lock(&journal->j_state_lock);
- journal->j_flags |= JBD2_REC_ERR;
- write_unlock(&journal->j_state_lock);
- }
+ jbd2_journal_update_sb_errno(journal);
+ write_lock(&journal->j_state_lock);
+ journal->j_flags |= JBD2_REC_ERR;
+ write_unlock(&journal->j_state_lock);
}
/**
@@ -2170,11 +2168,6 @@ static void __journal_abort_soft (journal_t *journal, int errno)
* failure to disk. ext3_error, for example, now uses this
* functionality.
*
- * Errors which originate from within the journaling layer will NOT
- * supply an errno; a null errno implies that absolutely no further
- * writes are done to the journal (unless there are any already in
- * progress).
- *
*/
void jbd2_journal_abort(journal_t *journal, int errno)
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 088/459] powerpc/papr_scm: Fix leaking 'bus_desc.provider_name' in some paths
From: Sasha Levin @ 2020-02-14 15:55 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Vaibhav Jain, Michael Ellerman, Sasha Levin, linuxppc-dev
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Vaibhav Jain <vaibhav@linux.ibm.com>
[ Upstream commit 5649607a8d0b0e019a4db14aab3de1e16c3a2b4f ]
String 'bus_desc.provider_name' allocated inside
papr_scm_nvdimm_init() will leaks in case call to
nvdimm_bus_register() fails or when papr_scm_remove() is called.
This minor patch ensures that 'bus_desc.provider_name' is freed in
error path for nvdimm_bus_register() as well as in papr_scm_remove().
Fixes: b5beae5e224f ("powerpc/pseries: Add driver for PAPR SCM regions")
Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200122155140.120429-1-vaibhav@linux.ibm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/platforms/pseries/papr_scm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/platforms/pseries/papr_scm.c b/arch/powerpc/platforms/pseries/papr_scm.c
index ee07d0718bf1a..66fd517c48164 100644
--- a/arch/powerpc/platforms/pseries/papr_scm.c
+++ b/arch/powerpc/platforms/pseries/papr_scm.c
@@ -342,6 +342,7 @@ static int papr_scm_nvdimm_init(struct papr_scm_priv *p)
p->bus = nvdimm_bus_register(NULL, &p->bus_desc);
if (!p->bus) {
dev_err(dev, "Error creating nvdimm bus %pOF\n", p->dn);
+ kfree(p->bus_desc.provider_name);
return -ENXIO;
}
@@ -498,6 +499,7 @@ static int papr_scm_remove(struct platform_device *pdev)
nvdimm_bus_unregister(p->bus);
drc_pmem_unbind(p);
+ kfree(p->bus_desc.provider_name);
kfree(p);
return 0;
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 076/459] x86/sysfb: Fix check for bad VRAM size
From: Sasha Levin @ 2020-02-14 15:55 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Arvind Sankar, Christopher Head, Borislav Petkov, Sasha Levin
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Arvind Sankar <nivedita@alum.mit.edu>
[ Upstream commit dacc9092336be20b01642afe1a51720b31f60369 ]
When checking whether the reported lfb_size makes sense, the height
* stride result is page-aligned before seeing whether it exceeds the
reported size.
This doesn't work if height * stride is not an exact number of pages.
For example, as reported in the kernel bugzilla below, an 800x600x32 EFI
framebuffer gets skipped because of this.
Move the PAGE_ALIGN to after the check vs size.
Reported-by: Christopher Head <chead@chead.ca>
Tested-by: Christopher Head <chead@chead.ca>
Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=206051
Link: https://lkml.kernel.org/r/20200107230410.2291947-1-nivedita@alum.mit.edu
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/x86/kernel/sysfb_simplefb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/sysfb_simplefb.c b/arch/x86/kernel/sysfb_simplefb.c
index 01f0e2263b86b..298fc1edd9c95 100644
--- a/arch/x86/kernel/sysfb_simplefb.c
+++ b/arch/x86/kernel/sysfb_simplefb.c
@@ -90,11 +90,11 @@ __init int create_simplefb(const struct screen_info *si,
if (si->orig_video_isVGA == VIDEO_TYPE_VLFB)
size <<= 16;
length = mode->height * mode->stride;
- length = PAGE_ALIGN(length);
if (length > size) {
printk(KERN_WARNING "sysfb: VRAM smaller than advertised\n");
return -EINVAL;
}
+ length = PAGE_ALIGN(length);
/* setup IORESOURCE_MEM as framebuffer memory */
memset(&res, 0, sizeof(res));
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 086/459] tracing: Fix tracing_stat return values in error handling paths
From: Sasha Levin @ 2020-02-14 15:55 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Luis Henriques, Steven Rostedt, Sasha Levin
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Luis Henriques <luis.henriques@canonical.com>
[ Upstream commit afccc00f75bbbee4e4ae833a96c2d29a7259c693 ]
tracing_stat_init() was always returning '0', even on the error paths. It
now returns -ENODEV if tracing_init_dentry() fails or -ENOMEM if it fails
to created the 'trace_stat' debugfs directory.
Link: http://lkml.kernel.org/r/1410299381-20108-1-git-send-email-luis.henriques@canonical.com
Fixes: ed6f1c996bfe4 ("tracing: Check return value of tracing_init_dentry()")
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
[ Pulled from the archeological digging of my INBOX ]
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
kernel/trace/trace_stat.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/kernel/trace/trace_stat.c b/kernel/trace/trace_stat.c
index 9ab0a1a7ad5ee..1257dc6c07796 100644
--- a/kernel/trace/trace_stat.c
+++ b/kernel/trace/trace_stat.c
@@ -282,18 +282,22 @@ static int tracing_stat_init(void)
d_tracing = tracing_init_dentry();
if (IS_ERR(d_tracing))
- return 0;
+ return -ENODEV;
stat_dir = tracefs_create_dir("trace_stat", d_tracing);
- if (!stat_dir)
+ if (!stat_dir) {
pr_warn("Could not create tracefs 'trace_stat' entry\n");
+ return -ENOMEM;
+ }
return 0;
}
static int init_stat_file(struct stat_session *session)
{
- if (!stat_dir && tracing_stat_init())
- return -ENODEV;
+ int ret;
+
+ if (!stat_dir && (ret = tracing_stat_init()))
+ return ret;
session->file = tracefs_create_file(session->ts->name, 0644,
stat_dir,
--
2.20.1
^ permalink raw reply related
* Re: [PATCH resend 0/2] dts: keystone-k2g-evm: Display support
From: santosh.shilimkar @ 2020-02-14 17:40 UTC (permalink / raw)
To: Jyri Sarha, dri-devel, ssantosh, linux-arm-kernel, devicetree
Cc: tomi.valkeinen, laurent.pinchart, peter.ujfalusi, bparrot,
praneeth, robh+dt, mark.rutland
In-Reply-To: <cover.1581671951.git.jsarha@ti.com>
On 2/14/20 1:22 AM, Jyri Sarha wrote:
> Resend because the earlier recipient list was wrong.
>
> Now that drm/tidss is queued for mainline, lets add display support for
> k2g-evm. There is no hurry since tidss is out only in v5.7, but it
> should not harm to have the dts changes in place before that.
>
> Jyri Sarha (2):
> ARM: dts: keystone-k2g: Add DSS node
> ARM: dts: keystone-k2g-evm: add HDMI video support
>
> arch/arm/boot/dts/keystone-k2g-evm.dts | 101 +++++++++++++++++++++++++
> arch/arm/boot/dts/keystone-k2g.dtsi | 22 ++++++
> 2 files changed, 123 insertions(+)
>
Ok. Will add this to the next queue.
Regards,
Santosh
^ permalink raw reply
* Re: [PATCH v2 13/25] fs: Add zero_user_large
From: Matthew Wilcox @ 2020-02-14 16:03 UTC (permalink / raw)
To: Kirill A. Shutemov; +Cc: linux-fsdevel, linux-mm, linux-kernel
In-Reply-To: <20200214135248.zqcqx3erb4pnlvmu@box>
On Fri, Feb 14, 2020 at 04:52:48PM +0300, Kirill A. Shutemov wrote:
> On Tue, Feb 11, 2020 at 08:18:33PM -0800, Matthew Wilcox wrote:
> > From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
> >
> > We can't kmap() a THP, so add a wrapper around zero_user() for large
> > pages.
>
> I would rather address it closer to the root: make zero_user_segments()
> handle compound pages.
Hah. I ended up doing that, but hadn't sent it out. I don't like
how ugly it is:
@@ -219,18 +219,57 @@ static inline void zero_user_segments(struct page *page,
unsigned start1, unsigned end1,
unsigned start2, unsigned end2)
{
- void *kaddr = kmap_atomic(page);
-
- BUG_ON(end1 > PAGE_SIZE || end2 > PAGE_SIZE);
-
- if (end1 > start1)
- memset(kaddr + start1, 0, end1 - start1);
-
- if (end2 > start2)
- memset(kaddr + start2, 0, end2 - start2);
-
- kunmap_atomic(kaddr);
- flush_dcache_page(page);
+ unsigned int i;
+
+ BUG_ON(end1 > thp_size(page) || end2 > thp_size(page));
+
+ for (i = 0; i < hpage_nr_pages(page); i++) {
+ void *kaddr;
+ unsigned this_end;
+
+ if (end1 == 0 && start2 >= PAGE_SIZE) {
+ start2 -= PAGE_SIZE;
+ end2 -= PAGE_SIZE;
+ continue;
+ }
+
+ if (start1 >= PAGE_SIZE) {
+ start1 -= PAGE_SIZE;
+ end1 -= PAGE_SIZE;
+ if (start2) {
+ start2 -= PAGE_SIZE;
+ end2 -= PAGE_SIZE;
+ }
+ continue;
+ }
+
+ kaddr = kmap_atomic(page + i);
+
+ this_end = min_t(unsigned, end1, PAGE_SIZE);
+ if (end1 > start1)
+ memset(kaddr + start1, 0, this_end - start1);
+ end1 -= this_end;
+ start1 = 0;
+
+ if (start2 >= PAGE_SIZE) {
+ start2 -= PAGE_SIZE;
+ end2 -= PAGE_SIZE;
+ } else {
+ this_end = min_t(unsigned, end2, PAGE_SIZE);
+ if (end2 > start2)
+ memset(kaddr + start2, 0, this_end - start2);
+ end2 -= this_end;
+ start2 = 0;
+ }
+
+ kunmap_atomic(kaddr);
+ flush_dcache_page(page + i);
+
+ if (!end1 && !end2)
+ break;
+ }
+
+ BUG_ON((start1 | start2 | end1 | end2) != 0);
}
I think at this point it has to move out-of-line too.
> > +static inline void zero_user_large(struct page *page,
> > + unsigned start, unsigned size)
> > +{
> > + unsigned int i;
> > +
> > + for (i = 0; i < thp_order(page); i++) {
> > + if (start > PAGE_SIZE) {
>
> Off-by-one? >= ?
Good catch; I'd also noticed that when I came to redo the zero_user_segments().
^ permalink raw reply
* Re: [PATCH resend 0/2] dts: keystone-k2g-evm: Display support
From: santosh.shilimkar @ 2020-02-14 17:40 UTC (permalink / raw)
To: Jyri Sarha, dri-devel, ssantosh, linux-arm-kernel, devicetree
Cc: mark.rutland, bparrot, praneeth, robh+dt, peter.ujfalusi,
tomi.valkeinen, laurent.pinchart
In-Reply-To: <cover.1581671951.git.jsarha@ti.com>
On 2/14/20 1:22 AM, Jyri Sarha wrote:
> Resend because the earlier recipient list was wrong.
>
> Now that drm/tidss is queued for mainline, lets add display support for
> k2g-evm. There is no hurry since tidss is out only in v5.7, but it
> should not harm to have the dts changes in place before that.
>
> Jyri Sarha (2):
> ARM: dts: keystone-k2g: Add DSS node
> ARM: dts: keystone-k2g-evm: add HDMI video support
>
> arch/arm/boot/dts/keystone-k2g-evm.dts | 101 +++++++++++++++++++++++++
> arch/arm/boot/dts/keystone-k2g.dtsi | 22 ++++++
> 2 files changed, 123 insertions(+)
>
Ok. Will add this to the next queue.
Regards,
Santosh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH AUTOSEL 5.4 083/459] powerpc/powernv/ioda: Fix ref count for devices with their own PE
From: Sasha Levin @ 2020-02-14 15:55 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Frederic Barrat, Andrew Donnellan, Michael Ellerman, Sasha Levin,
linuxppc-dev
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Frederic Barrat <fbarrat@linux.ibm.com>
[ Upstream commit 05dd7da76986937fb288b4213b1fa10dbe0d1b33 ]
The pci_dn structure used to store a pointer to the struct pci_dev, so
taking a reference on the device was required. However, the pci_dev
pointer was later removed from the pci_dn structure, but the reference
was kept for the npu device.
See commit 902bdc57451c ("powerpc/powernv/idoa: Remove unnecessary
pcidev from pci_dn").
We don't need to take a reference on the device when assigning the PE
as the struct pnv_ioda_pe is cleaned up at the same time as
the (physical) device is released. Doing so prevents the device from
being released, which is a problem for opencapi devices, since we want
to be able to remove them through PCI hotplug.
Now the ugly part: nvlink npu devices are not meant to be
released. Because of the above, we've always leaked a reference and
simply removing it now is dangerous and would likely require more
work. There's currently no release device callback for nvlink devices
for example. So to be safe, this patch leaks a reference on the npu
device, but only for nvlink and not opencapi.
Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com>
Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20191121134918.7155-2-fbarrat@linux.ibm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/platforms/powernv/pci-ioda.c | 19 ++++++++++++-------
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
index 59de6a5bc41c2..2432a50d48d58 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1062,14 +1062,13 @@ static struct pnv_ioda_pe *pnv_ioda_setup_dev_PE(struct pci_dev *dev)
return NULL;
}
- /* NOTE: We get only one ref to the pci_dev for the pdn, not for the
- * pointer in the PE data structure, both should be destroyed at the
- * same time. However, this needs to be looked at more closely again
- * once we actually start removing things (Hotplug, SR-IOV, ...)
+ /* NOTE: We don't get a reference for the pointer in the PE
+ * data structure, both the device and PE structures should be
+ * destroyed at the same time. However, removing nvlink
+ * devices will need some work.
*
* At some point we want to remove the PDN completely anyways
*/
- pci_dev_get(dev);
pdn->pe_number = pe->pe_number;
pe->flags = PNV_IODA_PE_DEV;
pe->pdev = dev;
@@ -1084,7 +1083,6 @@ static struct pnv_ioda_pe *pnv_ioda_setup_dev_PE(struct pci_dev *dev)
pnv_ioda_free_pe(pe);
pdn->pe_number = IODA_INVALID_PE;
pe->pdev = NULL;
- pci_dev_put(dev);
return NULL;
}
@@ -1205,6 +1203,14 @@ static struct pnv_ioda_pe *pnv_ioda_setup_npu_PE(struct pci_dev *npu_pdev)
struct pci_controller *hose = pci_bus_to_host(npu_pdev->bus);
struct pnv_phb *phb = hose->private_data;
+ /*
+ * Intentionally leak a reference on the npu device (for
+ * nvlink only; this is not an opencapi path) to make sure it
+ * never goes away, as it's been the case all along and some
+ * work is needed otherwise.
+ */
+ pci_dev_get(npu_pdev);
+
/*
* Due to a hardware errata PE#0 on the NPU is reserved for
* error handling. This means we only have three PEs remaining
@@ -1228,7 +1234,6 @@ static struct pnv_ioda_pe *pnv_ioda_setup_npu_PE(struct pci_dev *npu_pdev)
*/
dev_info(&npu_pdev->dev,
"Associating to existing PE %x\n", pe_num);
- pci_dev_get(npu_pdev);
npu_pdn = pci_get_pdn(npu_pdev);
rid = npu_pdev->bus->number << 8 | npu_pdn->devfn;
npu_pdn->pe_number = pe_num;
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 080/459] dmaengine: fsl-qdma: fix duplicated argument to &&
From: Sasha Levin @ 2020-02-14 15:55 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Chen Zhou, Peng Ma, Vinod Koul, Sasha Levin, dmaengine
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Chen Zhou <chenzhou10@huawei.com>
[ Upstream commit 4b048178854da11656596d36a107577d66fd1e08 ]
There is duplicated argument to && in function fsl_qdma_free_chan_resources,
which looks like a typo, pointer fsl_queue->desc_pool also needs NULL check,
fix it.
Detected with coccinelle.
Fixes: b092529e0aa0 ("dmaengine: fsl-qdma: Add qDMA controller driver for Layerscape SoCs")
Signed-off-by: Chen Zhou <chenzhou10@huawei.com>
Reviewed-by: Peng Ma <peng.ma@nxp.com>
Tested-by: Peng Ma <peng.ma@nxp.com>
Link: https://lore.kernel.org/r/20200120125843.34398-1-chenzhou10@huawei.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/dma/fsl-qdma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/fsl-qdma.c b/drivers/dma/fsl-qdma.c
index 89792083d62c5..95cc0256b3878 100644
--- a/drivers/dma/fsl-qdma.c
+++ b/drivers/dma/fsl-qdma.c
@@ -304,7 +304,7 @@ static void fsl_qdma_free_chan_resources(struct dma_chan *chan)
vchan_dma_desc_free_list(&fsl_chan->vchan, &head);
- if (!fsl_queue->comp_pool && !fsl_queue->comp_pool)
+ if (!fsl_queue->comp_pool && !fsl_queue->desc_pool)
return;
list_for_each_entry_safe(comp_temp, _comp_temp,
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 081/459] wan/hdlc_x25: fix skb handling
From: Sasha Levin @ 2020-02-14 15:55 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Martin Schiller, David S . Miller, Sasha Levin, netdev
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Martin Schiller <ms@dev.tdt.de>
[ Upstream commit 953c4a08dfc9ffe763a8340ac10f459d6c6cc4eb ]
o call skb_reset_network_header() before hdlc->xmit()
o change skb proto to HDLC (0x0019) before hdlc->xmit()
o call dev_queue_xmit_nit() before hdlc->xmit()
This changes make it possible to trace (tcpdump) outgoing layer2
(ETH_P_HDLC) packets
Additionally call skb_reset_network_header() after each skb_push() /
skb_pull().
Signed-off-by: Martin Schiller <ms@dev.tdt.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wan/hdlc_x25.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wan/hdlc_x25.c b/drivers/net/wan/hdlc_x25.c
index 5643675ff7241..bf78073ee7fd9 100644
--- a/drivers/net/wan/hdlc_x25.c
+++ b/drivers/net/wan/hdlc_x25.c
@@ -62,11 +62,12 @@ static int x25_data_indication(struct net_device *dev, struct sk_buff *skb)
{
unsigned char *ptr;
- skb_push(skb, 1);
-
if (skb_cow(skb, 1))
return NET_RX_DROP;
+ skb_push(skb, 1);
+ skb_reset_network_header(skb);
+
ptr = skb->data;
*ptr = X25_IFACE_DATA;
@@ -79,6 +80,13 @@ static int x25_data_indication(struct net_device *dev, struct sk_buff *skb)
static void x25_data_transmit(struct net_device *dev, struct sk_buff *skb)
{
hdlc_device *hdlc = dev_to_hdlc(dev);
+
+ skb_reset_network_header(skb);
+ skb->protocol = hdlc_type_trans(skb, dev);
+
+ if (dev_nit_active(dev))
+ dev_queue_xmit_nit(skb, dev);
+
hdlc->xmit(skb, dev); /* Ignore return value :-( */
}
@@ -93,6 +101,7 @@ static netdev_tx_t x25_xmit(struct sk_buff *skb, struct net_device *dev)
switch (skb->data[0]) {
case X25_IFACE_DATA: /* Data to be transmitted */
skb_pull(skb, 1);
+ skb_reset_network_header(skb);
if ((result = lapb_data_request(dev, skb)) != LAPB_OK)
dev_kfree_skb(skb);
return NETDEV_TX_OK;
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 065/459] drm/nouveau/nouveau: fix incorrect sizeof on args.src an args.dst
From: Sasha Levin @ 2020-02-14 15:55 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Colin Ian King, Ben Skeggs, Sasha Levin, dri-devel, nouveau
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Colin Ian King <colin.king@canonical.com>
[ Upstream commit f42e4b337b327b1336c978c4b5174990a25f68a0 ]
The sizeof is currently on args.src and args.dst and should be on
*args.src and *args.dst. Fortunately these sizes just so happen
to be the same size so it worked, however, this should be fixed
and it also cleans up static analysis warnings
Addresses-Coverity: ("sizeof not portable")
Fixes: f268307ec7c7 ("nouveau: simplify nouveau_dmem_migrate_vma")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c b/drivers/gpu/drm/nouveau/nouveau_dmem.c
index fa14399415965..0ad5d87b5a8e5 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dmem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dmem.c
@@ -635,10 +635,10 @@ nouveau_dmem_migrate_vma(struct nouveau_drm *drm,
unsigned long c, i;
int ret = -ENOMEM;
- args.src = kcalloc(max, sizeof(args.src), GFP_KERNEL);
+ args.src = kcalloc(max, sizeof(*args.src), GFP_KERNEL);
if (!args.src)
goto out;
- args.dst = kcalloc(max, sizeof(args.dst), GFP_KERNEL);
+ args.dst = kcalloc(max, sizeof(*args.dst), GFP_KERNEL);
if (!args.dst)
goto out_free_src;
--
2.20.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.