Add auto detection of the ds1307 device on the I2C #92
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Code should add instructions to kernel to auto-detect the presence of ds1307 device on I2C bus on address 0x68 and in case it is found auto assign it. The main drive is to make sure that devices (like Pi) do have correct time before init process is started thus make sure that all daemons have correct time during startup phase. I'm pretty sure that the code added is wrong, jsut don t knwo whom to contact to get help to add this functionality :) I've reused parts from the DOC: https://www.kernel.org/doc/Documentation/i2c/instantiating-devices
krzk
pushed a commit
to krzk/linux
that referenced
this pull request
Jul 9, 2015
Dummy dai can be used by multiple sound card. But it only belong to one card's dapm list. If another card use it, there will be dapm_assert_locked warning. [ 20.015782] WARNING: CPU: 1 PID: 661 at sound/soc/soc-dapm.c:124 dapm_assert_locked.isra.36+0x4c/0x58() [ 20.025249] Modules linked in: [ 20.028349] CPU: 1 PID: 661 Comm: aplay Not tainted 4.1.0-rc6-next-20150605-00004-gaee05d8-dirty torvalds#92 [ 20.037528] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) [ 20.044110] Backtrace: [ 20.046614] [<80012e00>] (dump_backtrace) from [<80012fa0>] (show_stack+0x18/0x1c) [ 20.054229] r6:809e8060 r5:00000000 r4:00000000 r3:00000000 [ 20.060002] [<80012f88>] (show_stack) from [<807a0f74>] (dump_stack+0x80/0x9c) [ 20.067293] [<807a0ef4>] (dump_stack) from [<8002b144>] (warn_slowpath_common+0x7c/0xb4) [ 20.075427] r5:0000007c r4:00000000 [ 20.079065] [<8002b0c8>] (warn_slowpath_common) from [<8002b1a0>] (warn_slowpath_null+0x24/0x2c) [ 20.087898] r8:00000001 r7:88007c28 r6:ed94a680 r5:809e83e4 r4:ed83d6c0 [ 20.094747] [<8002b17c>] (warn_slowpath_null) from [<8058403c>] (dapm_assert_locked.isra.36+0x4c/0x58) [ 20.104101] [<80583ff0>] (dapm_assert_locked.isra.36) from [<805842ec>] (dapm_mark_dirty+0x64/0xa4) [ 20.113165] [<80584288>] (dapm_mark_dirty) from [<805853a8>] (soc_dapm_dai_stream_event.isra.42+0x30/0xc8) [ 20.122863] r8:ed9b5dbc r7:00000000 r6:00000001 r5:00000001 r4:ed83d6c0 [ 20.129706] [<80585378>] (soc_dapm_dai_stream_event.isra.42) from [<80587e28>] (snd_soc_dapm_stream_event+0x78/0xa0) [ 20.140264] r5:ee2ee62c r4:00000001 [ 20.143918] [<80587db0>] (snd_soc_dapm_stream_event) from [<8058957c>] (soc_pcm_prepare+0x138/0x21c) [ 20.153058] r8:ed8d9480 r7:00000000 r6:ed9b0e00 r5:00000001 r4:ee2ee62c r3:00000000 ... This patch is to not probe the dummy component in soc_probe_component. Then there is no widget created for dummy DAI, and also don't need to check the dummy dai in dapm_connect_dai_link_widgets(). Signed-off-by: Shengjiu Wang <shengjiu.wang@freescale.com> Signed-off-by: Mark Brown <broonie@kernel.org>
ddstreet
referenced
this pull request
in ddstreet/linux
Jul 31, 2015
GIT 78add8a6901c143cfb091fae54e793af8a48ee41
commit e323d56eb06b266b77c2b430cb5f1977ba549e03
Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Date: Fri Jun 12 10:53:25 2015 +0900
clk: exynos4: Fix wrong clock for Exynos4x12 ADC
The TSADC gate clock was used in Exynos4x12 DTSI for exynos-adc driver.
However TSADC is present only on Exynos4210 so on Trats2 board (with
Exynos4412 SoC) the exynos-adc driver could not be probed:
ERROR: could not get clock /adc@126C0000:adc(0)
exynos-adc 126c0000.adc: failed getting clock, err = -2
exynos-adc: probe of 126c0000.adc failed with error -2
Instead on Exynos4x12 SoCs the main clock used by Analog to Digital
Converter is located in different register and it is named in datasheet
as PCLK_ADC. Regardless of the name the purpose of this PCLK_ADC clock
is the same as purpose of TSADC from Exynos4210.
The patch adds gate clock for Exynos4x12 using the proper register so
backward compatibility is preserved. This fixes the probe of exynos-adc
driver on Exynos4x12 boards and allows accessing sensors connected to it
on Trats2 board (ntc,ncp15wb473 AP and battery thermistors).
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: <stable@vger.kernel.org>
Fixes: c63c57433003 ("ARM: dts: Add ADC's dt data to read raw data for exynos4x12")
Reviewed-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Acked-by: Tomasz Figa <tomasz.figa@gmail.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
commit fe0d34d242fa1e0dec059e774d146a705420bc9a
Author: Rusty Russell <rusty@rustcorp.com.au>
Date: Wed Jul 29 05:52:14 2015 +0930
module: weaken locking assertion for oops path.
We don't actually hold the module_mutex when calling find_module_all
from module_kallsyms_lookup_name: that's because it's used by the oops
code and we don't want to deadlock.
However, access to the list read-only is safe if preempt is disabled,
so we can weaken the assertion. Keep a strong version for external
callers though.
Fixes: 0be964be0d45 ("module: Sanitize RCU usage and locking")
Reported-by: He Kuang <hekuang@huawei.com>
Cc: stable@kernel.org
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
commit ca0169cfa2b37814a4da760e7097467042d2464d
Author: Hai Li <hali@codeaurora.org>
Date: Mon Jul 27 13:49:45 2015 -0400
drm/msm: Enable clocks during enable/disable_vblank() callbacks
AHB clock should be enabled before accessing registers during
enable/disable_vblank(). Since these 2 callbacks are called in
atomic context while clk_prepare may cause thread sleep, a work
is scheduled to control vblanks.
v2: fixup spinlock initialization
Signed-off-by: Hai Li <hali@codeaurora.org>
[add comment about cancel_work_sync() before drm_irq_uninstall()]
Signed-off-by: Rob Clark <robdclark@gmail.com>
commit 55ceb5071d7a629ec290938c0a234467f57801f4
Author: jilai wang <jilaiw@codeaurora.org>
Date: Wed Jul 8 18:25:40 2015 -0400
drm/msm/mdp5: Add support for msm8x74v1
msm8x74v1 has different MDP5 version (v1.0) from msm8x74v2 (v1.2).
Add a separate config data to support msm8x74v1.
Signed-off-by: Jilai Wang <jilaiw@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
commit 4aeea572a7154c82abee18375db6dfc8379324ee
Author: jilai wang <jilaiw@codeaurora.org>
Date: Tue Jul 7 17:17:28 2015 -0400
drm/msm/mdp5: Add DMA pipe planes for MDP5
This change is to add planes which use DMA pipes for MDP5.
Signed-off-by: Jilai Wang <jilaiw@codeaurora.org>
[slight comment adjust to s/Construct public planes/Construct video
planes/ since DMA planes are public planes too, they just can't scale
or CSC]
Signed-off-by: Rob Clark <robdclark@gmail.com>
commit 8e6170d1f73dd49a8b98d8b29d1d6e59ff819706
Author: Kyle Huey <me@kylehuey.com>
Date: Mon Jul 13 10:35:45 2015 -0700
ARM: tegra: Add Tegra124 PMU support
This patch modifies the device tree for Tegra124 based devices to enable
the Cortex A15 PMU. The interrupt numbers are taken from NVIDIA Tegra K1
TRM (DP-06905-001_v03p). This patch was tested on a Jetson TK1.
Signed-off-by: Kyle Huey <khuey@kylehuey.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
commit b2df19e35e023e922ab7b6cc1cd9efd751e5d062
Author: jilai wang <jilaiw@codeaurora.org>
Date: Wed Jul 8 18:12:40 2015 -0400
drm/msm/mdp: Add capabilities to MDP planes (v2)
MDP planes can be implemented using different type of HW pipes,
RGB/VIG/DMA pipes for MDP5 and RGB/VG/DMA pipes for MDP4. Each type
of pipe has different HW capabilities such as scaling, color space
conversion, decimation... Add a variable in plane data structure
to specify the difference of each plane which comes from mdp5_cfg data
and use it to differenciate the plane operation.
V1: Initial change
V2: Fix a typo in mdp4_kms.h
Signed-off-by: Jilai Wang <jilaiw@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
commit c09adc18aa2916c76322861e8a2120ff2a3452e0
Author: Stephane Viau <sviau@codeaurora.org>
Date: Mon Jul 6 16:35:31 2015 -0400
drm/msm/mdp5: add more YUV formats for MDP5
Add packed YUV422 and planar YUV420 formats to MDP supported
formats.
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
commit 6fd8b7e8b3aec6be833115c6f0e56fb888ec2c15
Author: Rob Clark <robdclark@gmail.com>
Date: Tue Jul 28 15:09:00 2015 -0400
fixup! drm/msm/mdp5: use 2 memory clients for YUV formats on newer mdp5
commit 589e72d416fa4cea501d77d01e1b377d03779327
Author: Wentao Xu <wentaox@codeaurora.org>
Date: Mon Jul 6 16:35:30 2015 -0400
drm/msm/mdp5: use 2 memory clients for YUV formats on newer mdp5
Newer MDP5 uses 2 shared memory pool clients for certain YUV formats.
For example, if VIG0 is used to fetch data in YUYV format, it will use
VIG0_Y for Y component, and VIG0_Cr for UV packed.
Signed-off-by: Wentao Xu <wentaox@codeaurora.org>
[rebase]
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
commit fe9e51fabcd9c32939e5e59ba695f0bfca97290b
Author: Wentao Xu <wentaox@codeaurora.org>
Date: Mon Jul 6 16:35:29 2015 -0400
drm/msm/mdp: mark if a MDP format is YUV at definition
This makes it easy to determine if a format is YUV. The old
method of using chroma sample type incorrectly marks YUV444 as
RGB format.
Signed-off-by: Wentao Xu <wentaox@codeaurora.org>
[rebase]
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
commit 4e59a31078dc77ac07897c6f4dcb20c98e2b1611
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date: Mon Jul 6 11:09:41 2015 +0200
drm/msm/dp: use flags argument of devm_gpiod_get to set direction
Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions)
which appeared in v3.17-rc1, the gpiod_get* functions take an additional
parameter that allows to specify direction and initial value for output.
Use this to simplify the driver. Furthermore this is one caller less
that stops us making the flags argument to gpiod_get*() mandatory.
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Rob Clark <robdclark@gmail.com>
commit 8ef625a74f6d1c9fa8d940b8c88757a859bb34f9
Author: Hai Li <hali@codeaurora.org>
Date: Fri Jul 3 10:09:46 2015 -0400
drm/msm/dsi: Save/Restore PLL status across PHY reset
Reset DSI PHY silently changes its PLL registers to reset status,
which will make cached status in clock driver invalid and result
in wrong output rate of link clocks. The current restore mechanism
in DSI PLL does not cover all the cases. This change is to recover
PLL status after PHY reset to match HW status with cached status
in clock driver.
Signed-off-by: Hai Li <hali@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
commit de03fbbbfbd04a82ddb3fe3abf096d717ed97f57
Author: Markus Elfring <elfring@users.sourceforge.net>
Date: Sat Jun 27 22:23:28 2015 +0200
drm/msm/dsi: One function call less in dsi_init() after error detection
The dsi_destroy() function was called in two cases by the dsi_init() function
during error handling even if the passed variable contained a null pointer.
* This implementation detail could be improved by adjustments for jump
targets according to the Linux coding style convention.
* Drop an unnecessary initialisation for the variable "msm_dsi" then.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
[add couple missing ERR_PTR()'s]
Signed-off-by: Rob Clark <robdclark@gmail.com>
commit 4d5fa81f42043e6a5bb9ce856b9f804cf21d202b
Author: Markus Elfring <elfring@users.sourceforge.net>
Date: Sat Jun 27 22:05:31 2015 +0200
drm/msm/dsi: Delete an unnecessary check before the function call "dsi_destroy"
The dsi_destroy() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Rob Clark <robdclark@gmail.com>
commit 37c5a9eea828c5b094ebfe3bba5b28712fbf3f30
Author: Hai Li <hali@codeaurora.org>
Date: Fri Jun 26 16:03:26 2015 -0400
drm/msm/mdp5: Allocate CTL0/1 for dual DSI single FLUSH
This change takes advantage of a HW feature that synchronize
flush operation on CTL1 to CTL0, to keep dual DSI pipes in
sync.
Signed-off-by: Hai Li <hali@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
commit 2d9aa78a562c8b5e59eb7aab1c63b44ca3601ed6
Author: Hai Li <hali@codeaurora.org>
Date: Fri Jun 26 16:03:25 2015 -0400
drm/msm/mdp5: Allocate CTL for each display interface
In MDP5, CTL contains information of the whole pipeline whose
output goes down to a display interface. In various cases, one
interface may require 2 CRTCs, but only one CTL. Some interfaces
also require to use certain CTLs.
Instead of allocating CTL for each active CRTC, this change is to
associate a CTL with each interface.
Signed-off-by: Hai Li <hali@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
commit 00f3ec37d29efed8983a2add67b692ca509ec99b
Author: Rob Herring <robh@kernel.org>
Date: Mon Jul 27 15:55:14 2015 -0500
clk: kill off set_irq_flags usage
set_irq_flags is ARM specific with custom flags which have genirq
equivalents. Convert drivers to use the genirq interfaces directly, so we
can kill off set_irq_flags. The translation of flags is as follows:
IRQF_VALID -> !IRQ_NOREQUEST
IRQF_PROBE -> !IRQ_NOPROBE
IRQF_NOAUTOEN -> IRQ_NOAUTOEN
For IRQs managed by an irqdomain, the irqdomain core code handles clearing
and setting IRQ_NOREQUEST already, so there is no need to do this in
.map() functions and we can simply remove the set_irq_flags calls. Some
users also modify IRQ_NOPROBE and this has been maintained although it
is not clear that is really needed. There appears to be a great deal of
blind copy and paste of this code.
Signed-off-by: Rob Herring <robh@kernel.org>
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Cc: Mike Turquette <mturquette@baylibre.com>
Acked-by: Stephen Boyd <sboyd@codeaurora.org>
Cc: linux-clk@vger.kernel.org
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
commit d99215ae06be51558b723a3648515e672898ca4b
Author: Jun Nie <jun.nie@linaro.org>
Date: Thu Jul 23 15:02:53 2015 +0800
clk: zx: Constify parent names in clock init data
The array of parent names can be made as array of const pointers to
const strings.
Signed-off-by: Jun Nie <jun.nie@linaro.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
commit 105644e59a2b1c43fe2eeba6595d142c390552c2
Author: Jun Nie <jun.nie@linaro.org>
Date: Thu Jul 23 15:02:52 2015 +0800
clk: zx: Add audio and GPIO clock for zx296702
Add SPDIF/I2S and GPIO clock for zx296702
Signed-off-by: Jun Nie <jun.nie@linaro.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
commit 4599dd2c926915b5e8c27e0ca21a6172f9d6881c
Author: Jun Nie <jun.nie@linaro.org>
Date: Thu Jul 23 15:02:51 2015 +0800
clk: zx: Add audio div clock method for zx296702
Add SPDIF/I2S divider clock method for zx296702
Signed-off-by: Jun Nie <jun.nie@linaro.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
commit 7764d0cdc3dbf15010f66e0e2e5786f0f03d402a
Author: Vaibhav Hiremath <vaibhav.hiremath@linaro.org>
Date: Wed Jul 22 15:04:53 2015 +0530
clk: s2mps11: Use kcalloc instead of kzalloc for array allocation
This patch cleans up the driver for,
- Use devm_kcalloc() variant instead of devm_kzalloc() for array
allocation.
- clk_prepare()/unprepare(), remove "ret" variable as it is not required
- use __exit for cleanup function
As I am referring this driver as a reference for my 88pm800 clk driver,
applying same changes here as well.
Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org>
Tested-by: Anand Moon <linux.amoon@gmail.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
commit a57aa18539f8b232065f574f438edb646c6b9d9b
Author: Stephen Boyd <sboyd@codeaurora.org>
Date: Fri Jul 24 12:24:48 2015 -0700
clk: Silence warnings about lock imbalances
The recursive spinlock implementation trips up sparse and it
complains that these functions have lock imbalances. That isn't
really true though, so add some __acquires() and __releases()
information so that sparse is quiet.
drivers/clk/clk.c:116:22: warning: context imbalance in 'clk_enable_lock' - wrong count at exit
drivers/clk/clk.c:141:9: warning: context imbalance in 'clk_enable_unlock' - unexpected unlock
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
commit 661e2180cf050a2f859d466f30d74e990b9345be
Author: Stephen Boyd <sboyd@codeaurora.org>
Date: Fri Jul 24 12:21:12 2015 -0700
clk: basic-type: Silence warnings about lock imbalances
The basic clock types use conditional locking for the register
accessor spinlocks. Add __acquire() and __release() markings in
the right locations so that sparse isn't tripped up on the
conditional locking.
drivers/clk/clk-mux.c:68:12: warning: context imbalance in 'clk_mux_set_parent' - different lock contexts for basic block
drivers/clk/clk-divider.c:379:12: warning: context imbalance in 'clk_divider_set_rate' - different lock contexts for basic block
drivers/clk/clk-gate.c:71:9: warning: context imbalance in 'clk_gate_endisable' - different lock contexts for basic block
drivers/clk/clk-fractional-divider.c:36:9: warning: context imbalance in 'clk_fd_recalc_rate' - different lock contexts for basic block
drivers/clk/clk-fractional-divider.c:68:12: warning: context imbalance in 'clk_fd_set_rate' - different lock contexts for basic block
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
commit 169f05e80522e2848c9089a17976ebf31e735d5c
Author: Stephen Boyd <sboyd@codeaurora.org>
Date: Fri Jul 24 11:55:42 2015 -0700
clk: qcom: Give clk-qcom.ko module a GPLv2 license
The missing license causes the clk-qcom.ko module to taint the
kernel. Add the appropriate license to avoid taint.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
commit 37bff2c159a3629b592e54162239cb8c337c965d
Author: Stephen Boyd <sboyd@codeaurora.org>
Date: Fri Jul 24 09:31:29 2015 -0700
clk: gpio: Mark parent_names array const
Let's encourage const arrays of parent names like other basic
clock types.
Cc: Sergej Sawazki <ce3a@gmx.de>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
commit afe76c8fd030dd6b75fa69f7af7b7eb1e212f248
Author: Jim Quinlan <jim2101024@gmail.com>
Date: Fri May 15 15:45:47 2015 -0400
clk: allow a clk divider with max divisor when zero
This commit allows certain Broadcom STB clock dividers to be used with
clk-divider.c. It allows for a clock whose field value is the equal
to the divisor, execpt when the field value is zero, in which case the
divisor is 2^width. For example, consider a divisor clock with a two
bit field:
value divisor
0 4
1 1
2 2
3 3
Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
Signed-off-by: Michael Turquette <mturquette@baylibre.com>
commit 25d4d341d31b349836e1b12d10be34b9b575c12b
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Mon Jul 13 17:07:43 2015 +0300
clk: socfpga: switch to GENMASK()
Convert the code to use GENMASK() helper instead of div_mask() macro.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Dinh Nguyen <dinguyen@opensource.altera.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
commit 4b5fb7dc9096d949a22651370bb6bf11f21edb30
Author: Robert Jarzmik <robert.jarzmik@free.fr>
Date: Sun Jul 12 22:49:53 2015 +0200
clk: pxa: fix core frequency reporting unit
Legacy drivers which are not yet ported, such as cpufreq-pxa[23]xx, rely
on pxaXXx_get_clk_frequency_khz() to find the CPU core frequency.
This reporting was broken because the expected unit is kHz and not
Hz. Fix the reporting for pxa25x, pxa27x and pxa3xx.
Fixes: fe7710fae477 ("clk: add pxa25x clock drivers")
Fixes: d40670dc6169 ("clk: add pxa27x clock drivers")
Fixes: 9bbb8a338fb2 ("clk: pxa: add pxa3xx clock driver")
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
commit 2bbfe00147a7c075f5c43e657ec218afea662819
Author: Douglas Anderson <dianders@chromium.org>
Date: Tue Jul 21 13:41:23 2015 -0700
clk: rockchip: Fix PLL bandwidth
In the TRM we see that BWADJ is "a 12-bit bus that selects the values
1-4096 for the bandwidth divider (NB)":
NB = BWADJ[11:0] + 1
The recommended setting of NB: NB = NF / 2.
So:
NB = NF / 2
BWADJ[11:0] + 1 = NF / 2
BWADJ[11:0] = NF / 2 - 1
Right now, we have:
{ \
.rate = _rate##U, \
.nr = _nr, \
.nf = _nf, \
.no = _no, \
.bwadj = (_nf >> 1), \
}
That means we set bwadj to NF / 2, not NF / 2 - 1
All of this is a bit confusing because we specify "NR" (the 1-based
value), "NF" (the 1-based value), "NO" (the 1-based value), but
"BWADJ" (the 0-based value) instead of "NB" (the 1-based value).
Let's change to working with "NB" and fix the off by one error. This
may affect PLL jitter in a small way (hopefully for the better).
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
commit 9da9e761273702b3afd6e3538c23ece95693e586
Author: Dinh Nguyen <dinguyen@opensource.altera.com>
Date: Mon Jul 6 22:59:06 2015 -0500
clk: ti: make use of of_clk_parent_fill helper function
Use of_clk_parent_fill to fill in the parent clock names' array.
Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
Cc: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
commit 8a53fb2bceea00081c4a6af7b477bea8ec00b74b
Author: Dinh Nguyen <dinguyen@opensource.altera.com>
Date: Mon Jul 6 22:59:05 2015 -0500
clk: sunxi: make use of of_clk_parent_fill helper function
Use of_clk_parent_fill to fill in the parent clock names' array.
Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: "Emilio López" <emilio@elopez.com.ar>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
commit 0b4e7f0842fe5c8bd19654999f6c41c4119e7c90
Author: Dinh Nguyen <dinguyen@opensource.altera.com>
Date: Mon Jul 6 22:59:04 2015 -0500
clk: st: make use of of_clk_parent_fill helper function
Use of_clk_parent_fill to fill in the parent clock names' array.
Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
Tested-by Gabriel Fernandez <gabriel.fernandez@st.com>
Cc: Peter Griffin <peter.griffin@linaro.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
commit 5f23eff7af6bc1d8cc8e17fc12e8d989042236ed
Author: Dinh Nguyen <dinguyen@opensource.altera.com>
Date: Mon Jul 6 22:59:03 2015 -0500
clk: keystone: make use of of_clk_parent_fill helper function
Use of_clk_parent_fill to fill in the parent clock names' array.
Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
Acked-by: Santosh Shilimkar <ssantosh@kernel.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
commit f0557fbe1303aade362bd578753a1c898a80851c
Author: Dinh Nguyen <dinguyen@opensource.altera.com>
Date: Mon Jul 6 22:59:01 2015 -0500
clk: at91: make use of of_clk_parent_fill helper function
Use of_clk_parent_fill to fill in the parent clock names' array.
Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
commit 75ce0cdb6243d42daca6130e5feb71f536bb136e
Author: James Liao <jamesjj.liao@mediatek.com>
Date: Fri Jul 10 16:39:34 2015 +0800
clk: mediatek: Add MT8173 MMPLL change rate support
MT8173 MMPLL frequency settings are different from common PLLs.
It needs different post divider settings for some ranges of frequency.
This patch add support for MT8173 MMPLL frequency setting by adding
div-rate table to lookup suitable post divider setting under a
specified frequency.
Signed-off-by: James Liao <jamesjj.liao@mediatek.com>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
commit 196de71a9d9e9090406a87362d22b67ae633fa7a
Author: James Liao <jamesjj.liao@mediatek.com>
Date: Fri Jul 10 16:39:33 2015 +0800
clk: mediatek: Fix calculation of PLL rate settings
Avoid u32 overflow when calculate post divider setting, and
increase the max post divider setting from 3 (/8) to 4 (/16).
Signed-off-by: James Liao <jamesjj.liao@mediatek.com>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
commit b3be457e5854e3095cd0be850058c765aaf467ab
Author: James Liao <jamesjj.liao@mediatek.com>
Date: Fri Jul 10 16:39:32 2015 +0800
clk: mediatek: Fix PLL registers setting flow
Write postdiv and pcw settings at the same time for PLLs if postdiv
and pcw settings are on the same register.
This is need by PLLs such as MT8173 MMPLL and ARM*PLL.
Signed-off-by: James Liao <jamesjj.liao@mediatek.com>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
commit 9783c0d98501aa146ff467916ab4b8830a655d7c
Author: Stephen Boyd <sboyd@codeaurora.org>
Date: Thu Jul 16 12:50:27 2015 -0700
clk: Allow providers to configure min/max rates
clk providers are using the consumer APIs to set min/max rates on
the clock they're providing. To encourage clk providers to move
away from the consumer APIs, add a provider API to set the
min/max rate of a clock. The assumption is that this is done
before the clock can be requested via clk_get() and that the
clock rate is already within the boundaries of the min/max that's
configured.
Tested-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
commit 5c757456c16ce056a40a120e63235bc00c94ee7f
Author: Axel Lin <axel.lin@ingics.com>
Date: Thu Jul 16 22:15:53 2015 +0800
clk: twl6040: Convert to use devm_clk_register
Use devm_clk_register() to simplify the code by removing
twl6040_clk_remove().
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
commit 264e3b75de4eee6e4ee4616bf2b2a3d522cad72a
Author: Axel Lin <axel.lin@ingics.com>
Date: Thu Jul 16 21:59:43 2015 +0800
clk: s2mps11: Simplify s2mps11_clk_probe unwind paths
The devm_clk_unregister() in .probe error case is not necessary as it will
be automatically called when probe fails.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
commit 5a1cfafaeab5237523d43cd033e1fb42bf5c1933
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Tue Jun 23 15:09:27 2015 +0200
clk: shmobile: Remove unneeded #include <linux/clkdev.h>
The CCF implementations for the various shmobile SoCs don't use clkdev
functionality, hence drop the inclusion of <linux/clkdev.h>.
Add the missing #include <linux/slab.h>, which was included implicitly
through <asm/clkdev.h> before.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
commit 14cc4e9578841a4c0025ce064133b2da53c9d1c9
Author: Stephen Boyd <sboyd@codeaurora.org>
Date: Wed Jul 15 12:58:22 2015 -0700
clk: ti: Force pointer to be __iomem
Add __force here so that sparse doesn't complain about us playing
tricks with __iomem.
Acked-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
commit 76642eb4cb040b436319e5aa747a5ef026207eef
Author: Stephen Boyd <sboyd@codeaurora.org>
Date: Wed Jul 15 12:04:53 2015 -0700
clk: ti: clk-3xxx: Remove unused structures
Sparse complains about these structures missing static, but they
also don't look to be used. Remove them.
drivers/clk/ti/clk-3xxx.c:74:30: warning: symbol 'clkhwops_omap3430es2_ssi_wait' was not declared. Should it be static?
drivers/clk/ti/clk-3xxx.c:157:30: warning: symbol 'clkhwops_omap3430es2_hsotgusb_wait' was not declared. Should it be static?
Acked-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
commit 3fe6d697420c706b640730dbbae17f48b3aad506
Author: Stephen Boyd <sboyd@codeaurora.org>
Date: Wed Jul 15 12:03:52 2015 -0700
clk: ti: Mark ti_clk_features static
This variable isn't exported outside of this file so mark it
static. Silences the following sparse warning:
drivers/clk/ti/clk.c:36:24: warning: symbol 'ti_clk_features' was not declared. Should it be static?
Acked-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
commit f645f72d876586c4950dcd5bf516744db0aeb30b
Author: Stephen Boyd <sboyd@codeaurora.org>
Date: Wed Jul 15 11:55:42 2015 -0700
clk: ti: Check kzalloc() for failures
smatch reports a failure to check kzalloc() here:
drivers/clk/ti/clk.c:232
omap2_clk_provider_init() error: potential null dereference 'io'.
(kzalloc returns null)
Check for an allocation failure and return -ENOMEM.
Acked-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
commit e306479ac252928b84cc563c6e790f9b7e7ae427
Author: Axel Lin <axel.lin@ingics.com>
Date: Sat Jun 20 15:27:03 2015 +0800
clk: h8300: Fix signness bug
of_clk_get_parent_count() may return negative error code, so num_parents
needs to be int rather than unsigned int.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
commit d7a304e9d018c99dda80f4c16ec0fe817b5be4a1
Author: Stephen Boyd <sboyd@codeaurora.org>
Date: Tue Jul 14 16:57:29 2015 -0700
clk: qcom: Set CLK_SET_RATE_PARENT on ce1 clocks
The other ce clocks have the flag set, but ce1 doesn't, so
clk_set_rate() doesn't propagate up the tree to the ce1_src_clk.
Set the flag as this is supported.
Reported-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Tested-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Fixes: 02824653200b ("clk: qcom: Add APQ8084 Global Clock Controller support")
Fixes: d33faa9ead8d ("clk: qcom: Add support for MSM8974's global clock controller (GCC)")
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
commit c5e857a46af24a772f445edcc01a861ee2d6a713
Author: Stephen Boyd <sboyd@codeaurora.org>
Date: Tue Jul 14 12:45:19 2015 -0700
clk: gpio: Unlock mutex on error path
We don't unlock the mutex if we fail to allocate the parent names
array. Unlock it and return an error in this case as well.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Acked-by: Julia Lawall <julia.lawall@lip6.fr>
Cc: Sergej Sawazki <ce3a@gmx.de>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
commit 006cb8b66e18ce7aff934883f6c50e3b85052681
Author: Stephen Boyd <sboyd@codeaurora.org>
Date: Mon Jul 13 17:06:53 2015 -0700
clk: h8300: Use standard Linux I/O accessors
There doesn't seem to be any reason why we can't use the standard
readb()/writeb() accessors here because ctrl_inb() and
ctrl_outb() match the generic implementation of readb() and
writeb() that the h8300 architecture uses. This allows us to test
compile this driver on other architectures besides h8300.
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
commit 9298f0267c7ed620f8d8261ded8518ebf8e89f9e
Author: Stephen Boyd <sboyd@codeaurora.org>
Date: Mon Jul 13 16:54:04 2015 -0700
clk: h8300: Drop allocation printk and cleanup sizeof style
We don't need to print an error on allocation failures, drop it.
While we're here, change the sizeof() to be sizeof(*<ptr>) to
make code more future proof.
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
commit a8a7af8607a2551ce9699ffea7ccc7bd54b59064
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Tue Jul 28 13:18:42 2015 +0200
drm: Remove __drm_modeset_lock_all
The last user is gone, no need for trylocking any more in this legacy
helper.
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
commit d553fca625bb9a147c5eadcede7e40c9ba2bd8eb
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Tue Jul 28 13:18:41 2015 +0200
drm/fb-helper: Stop using trylocks in force_restore
Since the panic handling is gone this is only used for force-restoring
the fbdev/fbcon from sysrq, and that's done with a work item. No need
any more to do trylocks, we can just do normal locking.
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
commit 3828c43eb59d13f7105950021102bc0c787090fe
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Tue Jul 28 13:18:40 2015 +0200
drm/fbdev: Return -EBUSY when oopsing
Trying to do anything with kms drivers when oopsing has become a
failing proposition. But since we can end up in the fbdev code simply
due to the console unblanking that's done unconditionally just
removing our panic handler isn't enough. We need to block all fbdev
callbacks when oopsing.
There was already one in the blank handler, but it failed silently.
That makes it impossible for drivers (like i915) who subclass these
functions to figure this out.
Instead consistently return -EBUSY so that everyone knows that we
really don't want to be bothered right now. This also allows us to
remove a pile of FIXMEs from the i915 fbdev code (since due to the
failure code they now won't attempt to grab dangerous locks any more).
Cc: Dave Airlie <airlied@gmail.com>
Cc: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
commit 5de3bd463534117dc95e27c7f318e49e41985eff
Author: Archit Taneja <architt@codeaurora.org>
Date: Wed Jul 22 14:58:20 2015 +0530
drm/fb_cma_helper: Use new drm_fb_helper functions
Use the newly created wrapper drm_fb_helper functions instead of calling
core fbdev functions directly. They also simplify the fb_info creation.
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
commit e71570b47816b841c163d3a7a5bd540165523884
Author: Archit Taneja <architt@codeaurora.org>
Date: Wed Jul 22 14:58:16 2015 +0530
drm/udl: Use new drm_fb_helper functions
Use the newly created wrapper drm_fb_helper functions instead of calling
core fbdev functions directly. They also simplify the fb_info creation.
v2:
- remove unused variable device in udlfb_create
Cc: David Airlie <airlied@linux.ie>
Cc: Haixia Shi <hshi@chromium.org>
Cc: "Stéphane Marchesin" <marcheu@chromium.org>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
commit dad4e3022391fa560f9062599764db993eb81af7
Author: Archit Taneja <architt@codeaurora.org>
Date: Wed Jul 22 14:58:13 2015 +0530
drm/qxl: Use new drm_fb_helper functions
Use the newly created wrapper drm_fb_helper functions instead of calling
core fbdev functions directly. They also simplify the fb_info creation.
Cc: David Airlie <airlied@linux.ie>
Cc: Frediano Ziglio <fziglio@redhat.com>
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
commit 2115744d7b2f05bacdc069d0b49c307c6bcdbdfe
Author: Archit Taneja <architt@codeaurora.org>
Date: Wed Jul 22 14:58:10 2015 +0530
drm/gma500: Use new drm_fb_helper functions
Use the newly created wrapper drm_fb_helper functions instead of calling
core fbdev functions directly. They also simplify the fb_info creation.
v2:
- removed unused variable 'device' in psbfb_create
Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Reviewed-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
commit 1011f98d86dc6d6efe98ef04468d046189ce6ccb
Author: Archit Taneja <architt@codeaurora.org>
Date: Wed Jul 22 14:58:09 2015 +0530
drm/exynos: Use new drm_fb_helper functions
Use the newly created wrapper drm_fb_helper functions instead of calling
core fbdev functions directly. They also simplify the fb_info creation.
v2:
- Remove unnecessary dealloc cmap in error handling path
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Joonyoung Shim <jy0922.shim@samsung.com>
Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
commit 4960d05ef9f626e1e42ae0c0b4bdb65ce37fba0d
Author: Archit Taneja <architt@codeaurora.org>
Date: Wed Jul 22 14:58:08 2015 +0530
drm/msm: Use new drm_fb_helper functions
Use the newly created wrapper drm_fb_helper functions instead of calling
core fbdev functions directly. They also simplify the fb_info creation.
Cc: Rob Clark <robdclark@gmail.com>
Cc: Stephane Viau <sviau@codeaurora.org>
Cc: Hai Li <hali@codeaurora.org>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
commit b756ecb40a01b8d85bc7662d2bfb77da05d813c5
Author: Archit Taneja <architt@codeaurora.org>
Date: Wed Jul 22 14:58:07 2015 +0530
drm/tegra: Use new drm_fb_helper functions
Use the newly created wrapper drm_fb_helper functions instead of calling
core fbdev functions directly. They also simplify the fb_info creation.
v2:
- Fix up error handling path in tegra_fbdev_probe
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: "Terje Bergström" <tbergstrom@nvidia.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
commit 377eb331375f54fb908a8d90b0807b184b639b14
Author: Archit Taneja <architt@codeaurora.org>
Date: Wed Jul 22 14:58:06 2015 +0530
drm/omap: Use new drm_fb_helper functions
Use the newly created wrapper drm_fb_helper functions instead of calling
core fbdev functions directly. They also simplify the fb_info creation.
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
commit d0bda2cd4e30a65f671152e59d296f70f4cef8c2
Author: Archit Taneja <architt@codeaurora.org>
Date: Wed Jul 22 14:58:05 2015 +0530
drm/ast: Use new drm_fb_helper functions
Use the newly created wrapper drm_fb_helper functions instead of calling
core fbdev functions directly. They also simplify the fb_info creation.
Cleaned up the error handling in astfb_create a bit.
v2:
- removed unused variable 'device' in astfb_create
Cc: David Airlie <airlied@linux.ie>
Cc: "Y.C. Chen" <yc_chen@aspeedtech.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
commit 6d7906fce79a6606c35022d7f9f839ad3e403bec
Author: Archit Taneja <architt@codeaurora.org>
Date: Wed Jul 22 14:58:04 2015 +0530
drm/armada: Use new drm_fb_helper functions
Use the newly created wrapper drm_fb_helper functions instead of calling
core fbdev functions directly. They also simplify the fb_info creation.
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
commit 27f8f10314120ca55a2a2a2ff455228aca6980f1
Author: Archit Taneja <architt@codeaurora.org>
Date: Wed Jul 22 14:58:03 2015 +0530
drm/rockchip: Use new drm_fb_helper functions
Use the newly created wrapper drm_fb_helper functions instead of calling
core fbdev functions directly. They also simplify the fb_info creation.
This is an effort to create a top level drm fbdev emulation option.
Cc: Mark Yao <mark.yao@rock-chips.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
commit 8b34fe593ec6392aaef74c244fe2c091f424dee8
Author: Florian Fainelli <f.fainelli@gmail.com>
Date: Tue Jul 14 13:03:33 2015 -0700
ata: ahci_brcmstb: Fix warnings with CONFIG_PM_SLEEP=n
When CONFIG_PM_SLEEP is disabled, brcm_ahci_{suspend,resume} are not
used, which causes such a build warning to occur:
CC drivers/ata/ahci_brcmstb.o
drivers/ata/ahci_brcmstb.c:212:12: warning: 'brcm_ahci_suspend' defined
but not used [-Wunused-function]
static int brcm_ahci_suspend(struct device *dev)
^
drivers/ata/ahci_brcmstb.c:224:12: warning: 'brcm_ahci_resume' defined
but not used [-Wunused-function]
static int brcm_ahci_resume(struct device *dev)
^
LD drivers/ata/built-in.o
Fixes: 766a2d979632 ("ata: add Broadcom AHCI SATA3 driver for STB chips")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
commit c7906acec31005324b461195478dae5a65904630
Author: Archit Taneja <architt@codeaurora.org>
Date: Fri Jun 26 13:15:14 2015 +0530
drm/msm/dsi: Modify dsi manager bridge ops to work with external bridges
The dsi bridge ops call drm_panel functions to set up the connected
drm_panel. Add checks to make sure these aren't called when we're
connected to an external bridge.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
commit 77eb5ee6944ea00f10100f46ce521d247f573d48
Author: Archit Taneja <architt@codeaurora.org>
Date: Fri Jun 26 13:15:13 2015 +0530
drm/msm/dsi: Allow dsi to connect to an external bridge
There are platforms where the DSI output can be connected to another
encoder bridge chip (DSI to HDMI, DSI to LVDS etc).
Add support for external bridge support to the dsi driver. We assume that
the external bridge chip would be of the type drm_bridge. The dsi driver's
internal drm_bridge (msm_dsi->bridge) is linked to the external bridge's
drm_bridge struct.
In the case we're connected to an external bridge, we don't need to create
and manage a connector within our driver, it's the bridge driver's
responsibility to create one.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
commit 3213afb8bf5cf8d8c68a2c2376bf1dda52afae5d
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date: Tue Jul 28 10:25:03 2015 -0700
Revert "Input: zforce - don't overwrite the stack"
This reverts commit 7d01cd261c76f95913c81554a751968a1d282d3a because
with given FRAME_MAXSIZE of 257 the check will never trigger and it
causes warnings from GCC (with -Wtype-limits). Also the check was
incorrect as it was not accounting for the already read 2 bytes of data
stored in the buffer.
commit 40747338f97226962accfb5f70da193e750b398f
Author: Archit Taneja <architt@codeaurora.org>
Date: Fri Jun 26 13:15:12 2015 +0530
drm/msm/dsi: Create a helper to check if there is a connected device
Create a helper msm_dsi_device_connected() which checks whether we have a
device connected to the dsi host or not. This check gets messy when we
have support external bridges too. Having an inline function makes it
more legible.
For now, the check only consists of msm_dsi->panel being non-NULL. Later,
this will check if we have an external bridge or not.
This helper isn't used in dsi_connector related code as that's specific
to only when a drm_panel is connected.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
commit 7a771d4b0d5827ff5528eab48b5e63f41ab15a37
Author: Archit Taneja <architt@codeaurora.org>
Date: Fri Jun 26 13:15:11 2015 +0530
drm/msm/dsi: Refer to connected device as 'device' instead of 'panel'
We currently support only panels connected to dsi output. We're going to
also support external bridge chips now.
Change 'panel_node' to 'device_node' in the struct msm_dsi_host and
'panel_flags' to 'device_flags' in msm_dsi. This makes things sound a
bit more generic.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
commit 2111491b81933189c9e8d0bc34de1ec5e4b52b33
Author: Archit Taneja <architt@codeaurora.org>
Date: Fri Jun 26 13:15:10 2015 +0530
drm/msm/dsi: Make TE gpio optional
Platforms containing only DSI video mode devices don't need a TE gpio.
Make TE gpio optional.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
commit c5d6f02944d27afabd5b474930031e933058da14
Author: Archit Taneja <architt@codeaurora.org>
Date: Fri Jun 26 13:13:05 2015 +0530
drm/msm: mdp4 lvds: get panel node via of graph parsing
We currently get the output connected to LVDS by looking for a phandle
called 'qcom,lvds-panel' under the mdp DT node.
Use the more standard of_graph approach to create an lvds output port,
and retrieve the panel node from the port's endpoint data.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
commit c3f502202f958661d197fc6cd4a2f43979cc7814
Author: Archit Taneja <architt@codeaurora.org>
Date: Fri Jun 26 13:13:04 2015 +0530
drm/msm: dsi host: Use device graph parsing to parse connected panel
The dsi host looks for the connected panel node by parsing for a child
named 'panel'. This hierarchy isn't very flexible. The connected
panel is forced to be a child to the dsi host, and hence, a mipi dsi
device. This isn't suitable for dsi devices that don't use mipi dsi
as their control bus.
Follow the of_graph approach of creating ports and endpoints to
represent the connections between the dsi host and the panel connected
to it. In our case, the dsi host will only have one output port, linked
to the panel's input port.
Update DT binding documentation with device graph usage info.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
commit 50af680c113dd41c46cd1fd5b7f1dbfca956c0b1
Author: jilai wang <jilaiw@codeaurora.org>
Date: Thu Jun 25 17:37:42 2015 -0400
drm/msm/mdp5: Add plane blending operation support for MDP5 (v2)
This change is to add properties alpha/zpos/blend_mode to mdp5 plane
for alpha blending operation to generate the blended output.
v1: Initial change
v2: Change "premultilied" property to enum (Rob's comment)
Signed-off-by: Jilai Wang <jilaiw@codeaurora.org>
[Don't actually expose alpha/premultiplied props to userspace yet
pending a chance for discussion and some userspace to exercise it]
Signed-off-by: Rob Clark <robdclark@gmail.com>
commit 967f092ae15206bdc89e1a204593116a1d470500
Author: Olof Johansson <olof@lixom.net>
Date: Tue Jul 28 18:31:18 2015 +0200
arm-soc: document merges
Signed-off-by: Olof Johansson <olof@lixom.net>
commit 76f90d76c27aaf1408378cd2009002859a79da92
Author: Thierry Reding <treding@nvidia.com>
Date: Fri Aug 1 15:50:44 2014 +0200
of: Add vendor prefix for Sharp Microelectronics
Use "sharp" as the vendor prefix for Sharp Microelectronics in device
tree compatible strings.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Rob Herring <robh@kernel.org>
commit 0e3d05cf83a896268108f118c486916aafe86177
Author: Olof Johansson <olof@lixom.net>
Date: Tue Jul 28 17:32:43 2015 +0200
arm-soc: document merges
Signed-off-by: Olof Johansson <olof@lixom.net>
commit 227942809b52f23cda414858b635c0285f11de00
Author: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
Date: Thu Jul 16 13:34:23 2015 +0530
cpufreq: powernv: Restore cpu frequency to policy->cur on unthrottling
If frequency is throttled due to OCC reset then cpus will be in Psafe
frequency, so restore the frequency on all cpus to policy->cur when
OCCs are active again. And if frequency is throttled due to Pmax
capping then restore the frequency of all the cpus in the chip on
unthrottling.
Signed-off-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
commit 3dd3ebe5bb3837aeac28a23f8f22b97cb84abab6
Author: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
Date: Thu Jul 16 13:34:22 2015 +0530
cpufreq: powernv: Report Psafe only if PMSR.psafe_mode_active bit is set
On a reset cycle of OCC, although the system retires from safe
frequency state the local pstate is not restored to Pmin or last
requested pstate. Now if the cpufreq governor initiates a pstate
change, the local pstate will be in Psafe and we will be reporting a
false positive when we are not throttled.
So in powernv_cpufreq_throttle_check() remove the condition which
checks if local pstate is less than Pmin while checking for Psafe
frequency. If the cpus are forced to Psafe then PMSR.psafe_mode_active
bit will be set. So, when OCCs become active this bit will be cleared.
Let us just rely on this bit for reporting throttling.
Signed-off-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
Reviewed-by: Preeti U Murthy <preeti@linux.vnet.ibm.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
commit 735366fc407755626058218fc8d0430735a669ac
Author: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
Date: Thu Jul 16 13:34:21 2015 +0530
cpufreq: powernv: Call throttle_check() on receiving OCC_THROTTLE
Re-evaluate the chip's throttled state on recieving OCC_THROTTLE
notification by executing *throttle_check() on any one of the cpu on
the chip. This is a sanity check to verify if we were indeed
throttled/unthrottled after receiving OCC_THROTTLE notification.
We cannot call *throttle_check() directly from the notification
handler because we could be handling chip1's notification in chip2. So
initiate an smp_call to execute *throttle_check(). We are irq-disabled
in the notification handler, so use a worker thread to smp_call
throttle_check() on any of the cpu in the chipmask.
Signed-off-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
commit cb166fa937a2fbc14badcafca86202354c34a213
Author: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
Date: Thu Jul 16 13:34:20 2015 +0530
cpufreq: powernv: Register for OCC related opal_message notification
OCC is an On-Chip-Controller which takes care of power and thermal
safety of the chip. During runtime due to power failure or
overtemperature the OCC may throttle the frequencies of the CPUs to
remain within the power budget.
We want the cpufreq driver to be aware of such situations to be able
to report the reason to the user. We register to opal_message_notifier
to receive OCC messages from opal.
powernv_cpufreq_throttle_check() reports any frequency throttling and
this patch will report the reason or event that caused throttling. We
can be throttled if OCC is reset or OCC limits Pmax due to power or
thermal reasons. We are also notified of unthrottling after an OCC
reset or if OCC restores Pmax on the chip.
Signed-off-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
commit 196ba2d514a13f6af1b3d78de71ce74ed2fc8bdc
Author: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
Date: Thu Jul 16 13:34:19 2015 +0530
powerpc/powernv: Add definition of OPAL_MSG_OCC message type
Add OPAL_MSG_OCC message definition to opal_message_type to receive
OCC events like reset, load and throttled. Host performance can be
affected when OCC is reset or OCC throttles the max Pstate.
We can register to opal_message_notifier to receive OPAL_MSG_OCC type
of message and report it to the userspace so as to keep the user
informed about the reason for a performance drop in workloads.
The reset and load OCC events are notified to kernel when FSP sends
OCC_RESET and OCC_LOAD commands. Both reset and load messages are
sent to kernel on successful completion of reset and load operation
respectively.
The throttle OCC event indicates that the Pmax of the chip is reduced.
The chip_id and throttle reason for reducing Pmax is also queued along
with the message.
Signed-off-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
commit 053819e0bf8407746cc5febf7a4947bee50377b4
Author: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
Date: Thu Jul 16 13:34:18 2015 +0530
cpufreq: powernv: Handle throttling due to Pmax capping at chip level
The On-Chip-Controller(OCC) can throttle cpu frequency by reducing the
max allowed frequency for that chip if the chip exceeds its power or
temperature limits. As Pmax capping is a chip level condition report
this throttling behavior at chip level and also do not set the global
'throttled' on Pmax capping instead set the per-chip throttled
variable. Report unthrottling if Pmax is restored after throttling.
This patch adds a structure to store chip id and throttled state of
the chip.
Signed-off-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
Reviewed-by: Preeti U Murthy <preeti@linux.vnet.ibm.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
commit a34e63b14486e98cf78c99bf8ef141de7508dbc2
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date: Mon Jul 27 23:11:50 2015 +0200
cpufreq: Pass CPU number to cpufreq_policy_alloc()
Change cpufreq_policy_alloc() to take a CPU number instead of a CPU
device pointer as its argument, as it is the only function called by
cpufreq_add_dev() taking a device pointer argument at this point.
That will allow us to split the CPU online part from cpufreq_add_dev()
more cleanly going forward.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
commit 4d1f3a5bcb489cc6f7cbc128e0c292fed7868d32
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date: Mon Jul 27 23:11:44 2015 +0200
cpufreq: Do not update related_cpus on every policy activation
The related_cpus mask includes CPUs whose cpufreq_cpu_data per-CPU
pointers have been set the the given policy. Since those pointers
are only set at the policy creation time and unset when the policy
is deleted, the related_cpus should not be updated between those
two operations.
For this reason, avoid updating it whenever the first of the
"related" CPUs goes online.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
commit d9612a495b0bc93f5db0e0033fe4ee7abb7167c7
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date: Mon Jul 27 23:11:37 2015 +0200
cpufreq: Drop unused dev argument from two functions
The dev argument of cpufreq_add_policy_cpu() and
cpufreq_add_dev_interface() is not used by any of them,
so drop it.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
commit d4d854d6c7706e6a5cda297e350e3626d55e9bc9
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date: Mon Jul 27 23:11:30 2015 +0200
cpufreq: Drop unnecessary label from cpufreq_add_dev()
The leftover out_release_rwsem label in cpufreq_add_dev() is not
necessary any more and confusing, so drop it.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
commit 11ce707e6c2aea05e1f54680fb89a8a44ded5db4
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date: Mon Jul 27 23:11:21 2015 +0200
cpufreq: Drop cpufreq_policy_restore()
Notice that when cpufreq_policy_restore() is called, its per-CPU
cpufreq_cpu_data variable has been already dereferenced and if that
variable is not NULL, the policy local pointer in cpufreq_add_dev()
contains its value.
Therefore it is not necessary to dereference it again and the
policy pointer can be used directly. Moreover, if that pointer
is not NULL, the policy is inactive (or the previous check would
have made us return from cpufreq_add_dev()) so the restoration
code from cpufreq_policy_restore() can be moved to that point
in cpufreq_add_dev().
Do that and drop cpufreq_policy_restore().
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
commit 15c0b4d222f83672407419f9c9e167e996d8ad2b
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date: Mon Jul 27 23:11:09 2015 +0200
cpufreq: Rework two functions related to CPU offline
Since __cpufreq_remove_dev_prepare() and __cpufreq_remove_dev_finish()
are about CPU offline rather than about CPU removal, rename them to
cpufreq_offline_prepare() and cpufreq_offline_finish(), respectively.
Also change their argument from a struct device pointer to a CPU
number, because they use the CPU number only internally anyway
and make them void as their return values are ignored.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
commit ede76209c1f166af8a6b8fb2c5e0f2fc0e2e317b
Author: Rob Clark <robdclark@gmail.com>
Date: Tue Jul 28 11:05:03 2015 -0400
drm/msm: don't install plane properties on crtc
This was a hold-over from the pre-atomic days and legacy userspace that
only understood CRTCs. Fortunately we don't have any properties, so
this doesn't change anything. But before we start growing some plane
properties, we should fix this.
Signed-off-by: Rob Clark <robdclark@gmail.com>
commit 559ed40752dc63e68f9b9ad301b20e6a3fe5cf21
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date: Sun Jul 26 02:07:47 2015 +0200
cpufreq: Avoid attempts to create duplicate symbolic links
After commit 87549141d516 (cpufreq: Stop migrating sysfs files on
hotplug) there is a problem with CPUs that share cpufreq policy
objects with other CPUs and are initially offline.
Say CPU1 shares a policy with CPU0 which is online and is registered
first. As part of the registration process, cpufreq_add_dev() is
called for it. It creates the policy object and a symbolic link
to it from the CPU1's sysfs directory. If CPU1 is registered
subsequently and it is offline at that time, cpufreq_add_dev() will
attempt to create a symbolic link to the policy object for it, but
that link is present already, so a warning about that will be
triggered.
To avoid that warning, make cpufreq use an additional CPU mask
containing related CPUs that are actually present for each policy
object. That mask is initialized when the policy object is populated
after its creation (for the first online CPU using it) and it includes
CPUs from the "policy CPUs" mask returned by the cpufreq driver's
->init() callback that are physically present at that time. Symbolic
links to the policy are created only for the CPUs in that mask.
If cpufreq_add_dev() is invoked for an offline CPU, it checks the
new mask and only creates the symlink if the CPU was not in it (the
CPU is added to the mask at the same time).
In turn, cpufreq_remove_dev() drops the given CPU from the new mask,
removes its symlink to the policy object and returns, unless it is
the CPU owning the policy object. In that case, the policy object
is moved to a new CPU's sysfs directory or deleted if the CPU being
removed was the last user of the policy.
While at it, notice that cpufreq_remove_dev() can't fail, because
its return value is ignored, so make it ignore return values from
__cpufreq_remove_dev_prepare() and __cpufreq_remove_dev_finish()
and prevent these functions from aborting on errors returned by
__cpufreq_governor(). Also drop the now unused sif argument from
them.
Fixes: 87549141d516 (cpufreq: Stop migrating sysfs files on hotplug)
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reported-and-tested-by: Russell King <linux@arm.linux.org.uk>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
commit 766ffb69803943c2b580a44ac14a189b875d21f6
Author: Will Deacon <will.deacon@arm.com>
Date: Tue Jul 28 16:14:03 2015 +0100
arm64: pgtable: fix definition of pte_valid
pte_valid should check if the PTE_VALID bit (1 << 0) is set in the pte,
so fix the macro definition to use bitwise & instead of logical &&.
Signed-off-by: Will Deacon <will.deacon@arm.com>
commit 5dbaf90a6780b2989515212cb2584b7771cecad1
Author: David Woodhouse <David.Woodhouse@intel.com>
Date: Tue Mar 24 14:54:56 2015 +0000
iommu/vt-d: Add initial shell of SVM support
Add CONFIG_INTEL_IOMMU_SVM, and allocate PASID tables.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
commit 15bbdec3931e617231c12b0920e497e87ec8c2c6
Author: Sakari Ailus <sakari.ailus@linux.intel.com>
Date: Mon Jul 13 14:31:30 2015 +0300
iommu: Make the iova library a module
The iova library has use outside the intel-iommu driver, thus make it a
module.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
commit 9b41760b03816b34f4c9eee2cbb8fda8439920fc
Author: Sakari Ailus <sakari.ailus@linux.intel.com>
Date: Mon Jul 13 14:31:29 2015 +0300
iommu: iova: Export symbols
Use EXPORT_SYMBOL_GPL() to export the iova library symbols. The symbols
include:
init_iova_domain();
iova_cache_get();
iova_cache_put();
iova_cache_init();
alloc_iova();
find_iova();
__free_iova();
free_iova();
put_iova_domain();
reserve_iova();
copy_reserved_iova();
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
commit ae1ff3d623905947158fd3394854c23026337810
Author: Sakari Ailus <sakari.ailus@linux.intel.com>
Date: Mon Jul 13 14:31:28 2015 +0300
iommu: iova: Move iova cache management to the iova library
This is necessary to separate intel-iommu from the iova library.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
commit 8f6429c7cb59f28433253575cc8e3262eed63592
Author: Robin Murphy <robin.murphy@arm.com>
Date: Thu Jul 16 19:40:12 2015 +0100
iommu/iova: Avoid over-allocating when size-aligned
Currently, allocating a size-aligned IOVA region quietly adjusts the
actual allocation size in the process, returning a rounded-up
power-of-two-sized allocation. This results in mismatched behaviour in
the IOMMU driver if the original size was not a power of two, where the
original size is mapped, but the rounded-up IOVA size is unmapped.
Whilst some IOMMUs will happily unmap already-unmapped pages, others
consider this an error, so fix it by computing the necessary alignment
padding without altering the actual allocation size. Also clean up by
making pad_size unsigned, since its callers always pass unsigned values
and negative padding makes little sense here anyway.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
commit d169ba3e093c0932f466ba68314555317e072def
Author: Archit Taneja <architt@codeaurora.org>
Date: Fri Jun 26 13:13:03 2015 +0530
drm/msm: dsi host: add missing of_node_put()
Decrement device node refcount if of_get_child_by_name is successfully
called.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
commit 71b65445f0ed04c2afe3660f829779fddb2890c1
Author: Mika Westerberg <mika.westerberg@linux.intel.com>
Date: Tue Jul 28 13:51:21 2015 +0300
ACPI / PM: Use target_state to set the device power state
Commit 20dacb71ad28 ("ACPI / PM: Rework device power management to follow
ACPI 6") changed the device power management to use…
ddstreet
referenced
this pull request
in ddstreet/linux
Aug 6, 2015
GIT 32f494c98c21b03a78c2305cde6ae1b421db576e
commit 32f494c98c21b03a78c2305cde6ae1b421db576e
Author: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed Aug 5 16:41:48 2015 +1000
crypto: authenc - select CRYPTO_NULL
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
commit aa7c043d9783f538319e77deeae5d90ff5d6907b
Author: Richard Guy Briggs <rgb@redhat.com>
Date: Sat Aug 1 15:41:13 2015 -0400
audit: eliminate unnecessary extra layer of watch parent references
The audit watch parent count was imbalanced, adding an unnecessary layer of
watch parent references. Decrement the additional parent reference when a
watch is reused, already having a reference to the parent.
audit_find_parent() gets a reference to the parent, if the parent is
already known. This additional parental reference is not needed if the
watch is subsequently found by audit_add_to_parent(), and consumed if
the watch does not already exist, so we need to put the parent if the
watch is found, and do nothing if this new watch is added to the parent.
If the parent wasn't already known, it is created with a refcount of 1
and added to the audit_watch_group, then incremented by one to be
subsequently consumed by the newly created watch in
audit_add_to_parent().
The rule points to the watch, not to the parent, so the rule's refcount
gets bumped, not the parent's.
See LKML, 2015-07-16
Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
Signed-off-by: Paul Moore <pmoore@redhat.com>
commit f8259b262bedd5ec71e55de5953464ea86ff69d9
Author: Richard Guy Briggs <rgb@redhat.com>
Date: Sat Aug 1 15:41:12 2015 -0400
audit: eliminate unnecessary extra layer of watch references
The audit watch count was imbalanced, adding an unnecessary layer of watch
references. Only add the second reference when it is added to a parent.
Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
Signed-off-by: Paul Moore <pmoore@redhat.com>
commit 6abc8ca19df0078de17dc38340db3002ed489ce7
Author: Tejun Heo <tj@kernel.org>
Date: Tue Aug 4 15:20:55 2015 -0400
cgroup: define controller file conventions
Traditionally, each cgroup controller implemented whatever interface
it wanted leading to interfaces which are widely inconsistent.
Examining the requirements of the controllers readily yield that there
are only a few control schemes shared among all.
Two major controllers already had to implement new interface for the
unified hierarchy due to significant structural changes. Let's take
the chance to establish common conventions throughout all controllers.
This patch defines CGROUP_WEIGHT_MIN/DFL/MAX to be used on all weight
based control knobs and documents the conventions that controllers
should follow on the unified hierarchy. Except for io.weight knob,
all existing unified hierarchy knobs are already compliant. A
follow-up patch will update io.weight.
v2: Added descriptions of min, low and high knobs.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Li Zefan <lizefan@huawei.com>
Cc: Peter Zijlstra <peterz@infradead.org>
commit 1dadafa86a779884f14a6e7a3ddde1a57b0a0a65
Author: Tim Gardner <tim.gardner@canonical.com>
Date: Tue Aug 4 11:26:04 2015 -0600
workqueue: Make flush_workqueue() available again to non GPL modules
Commit 37b1ef31a568fc02e53587620226e5f3c66454c8 ("workqueue: move
flush_scheduled_work() to workqueue.h") moved the exported non GPL
flush_scheduled_work() from a function to an inline wrapper.
Unfortunately, it directly calls flush_workqueue() which is a GPL function.
This has the effect of changing the licensing requirement for this function
and makes it unavailable to non GPL modules.
See commit ad7b1f841f8a54c6d61ff181451f55b68175e15a ("workqueue: Make
schedule_work() available again to non GPL modules") for precedent.
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
commit b03ba9e314c12b2127243145b5c1f41b2408de62
Author: Sifan Naeem <sifan.naeem@imgtec.com>
Date: Wed Jul 29 11:55:26 2015 +0100
spi: img-spfi: fix multiple calls to request gpio
spfi_setup may be called many times by the spi framework, but
gpio_request_one can only be called once without freeing, repeatedly
calling gpio_request_one will cause an error to be thrown, which
causes the request to spi_setup to be marked as failed.
We can have a per-spi_device flag that indicates whether or not the
gpio has been requested. If the gpio has already been requested use
gpio_direction_output to set the direction of the gpio.
Fixes: 8c2c8c03cdcb ("spi: img-spfi: Control CS lines with GPIO")
Signed-off-by: Sifan Naeem <sifan.naeem@imgtec.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
commit d4ea7d86457a8d0ea40ce77bdeda1fc966cc35ec
Author: Ian Campbell <ijc@hellion.org.uk>
Date: Sat Aug 1 18:13:25 2015 +0100
regulator: axp20x: Add module alias
This allows the module to be autoloaded.
Together with 07949bf9c63c ("cpufreq: dt: allow driver to boot
automatically") this is sufficient to allow a modular kernel (such
as Debian's) to enable cpufreq on a Cubietruck.
Signed-off-by: Ian Campbell <ijc@hellion.org.uk>
Signed-off-by: Mark Brown <broonie@kernel.org>
commit 5dbe135a153837ce9367bdfacf7aabfc6fb76f4b
Author: Robert Baldyga <r.baldyga@samsung.com>
Date: Fri Jul 31 16:00:51 2015 +0200
usb: gadget: epautoconf: remove ep and desc configuration from ep_matches()
As function ep_matches() is used to match endpoint with usb descriptor it's
highly unintuitive that it modifies endpoint and descriptor structures fields.
This patch moves code configuring ep and desc from ep_matches() to
usb_ep_autoconfig_ss(), so now function ep_matches() does nothing more than
its name suggests.
[ balbi@ti.com : fix build warning ]
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
commit b58713d53a8f41d57b24c93de0b1c7e9550ba70f
Author: Robert Baldyga <r.baldyga@samsung.com>
Date: Fri Jul 31 16:00:50 2015 +0200
usb: gadget: epautoconf: remove pxa quirk from ep_matches()
The same effect can be achieved by using capabilities flags, so now we can
get rid of handling of hardware specific limitations in generic code.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
commit b86f33a3a371a4c3aa8dbb2f4125634a4e0d09dc
Author: Robert Baldyga <r.baldyga@samsung.com>
Date: Fri Jul 31 16:00:49 2015 +0200
usb: gadget: epautoconf: add endpoint capabilities flags verification
Introduce endpoint matching mechanism basing on endpoint capabilities
flags. We check if endpoint supports transfer type and direction requested
in ep descriptor. Since we have this new endpoint matching mechanism
there is no need to have old code guessing endpoint capabilities basing
on its name, so we are getting rid of it. Remove also the obsolete comment.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
commit 47bef386511517449e2f24a89a41084af53616f8
Author: Robert Baldyga <r.baldyga@samsung.com>
Date: Fri Jul 31 16:00:48 2015 +0200
usb: gadget: atmel_usba_udc: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
commit 916f7ac5dbc312969a90bc35a5f4fcbfc2965d60
Author: Robert Baldyga <r.baldyga@samsung.com>
Date: Fri Jul 31 16:00:47 2015 +0200
usb: renesas: gadget: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
commit 8501955e888662ca56775eec2eb804e7bc7fce0d
Author: Robert Baldyga <r.baldyga@samsung.com>
Date: Fri Jul 31 16:00:46 2015 +0200
usb: musb: gadget: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
commit eb4cbc19526d62657b838d6f0b694a000e5b4c81
Author: Robert Baldyga <r.baldyga@samsung.com>
Date: Fri Jul 31 16:00:45 2015 +0200
usb: isp1760: udc: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
commit 927d9f77fe3d5f9261eeb465e2b60768e400ffc9
Author: Robert Baldyga <r.baldyga@samsung.com>
Date: Fri Jul 31 16:00:44 2015 +0200
usb: gadget: udc-xilinx: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
commit 0648772d51c0ff3949397cb0cbcf2435ee32c550
Author: Robert Baldyga <r.baldyga@samsung.com>
Date: Fri Jul 31 16:00:43 2015 +0200
usb: gadget: s3c2410_udc: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
commit bc1b9f300ae06c64fcd056fb959b3d709ad2ef33
Author: Robert Baldyga <r.baldyga@samsung.com>
Date: Fri Jul 31 16:00:42 2015 +0200
usb: gadget: s3c-hsudc: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
commit 0ec8026d7afee625f52631708d84435ea4735da6
Author: Robert Baldyga <r.baldyga@samsung.com>
Date: Fri Jul 31 16:00:41 2015 +0200
usb: gadget: r8a66597-udc: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
commit a180e3da97a323510071b2b5e42b5dc07df239da
Author: Robert Baldyga <r.baldyga@samsung.com>
Date: Fri Jul 31 16:00:40 2015 +0200
usb: gadget: pxa27x_udc: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
commit 36411b6b042d350a43fe1e0d3ce78fbda30f4f02
Author: Robert Baldyga <r.baldyga@samsung.com>
Date: Fri Jul 31 16:00:39 2015 +0200
usb: gadget: pxa25x_udc: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
commit 85a4ed003b39f70ba478e613a9be2c334f1079e7
Author: Robert Baldyga <r.baldyga@samsung.com>
Date: Fri Jul 31 16:00:38 2015 +0200
usb: gadget: pch_udc: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
commit 7d4ba80d3a91222de577b652a8936f935de8b409
Author: Robert Baldyga <r.baldyga@samsung.com>
Date: Fri Jul 31 16:00:37 2015 +0200
usb: gadget: omap_udc: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
commit c23c3c3c3059f3dc47268cd7a28b96b9efdbc1ea
Author: Robert Baldyga <r.baldyga@samsung.com>
Date: Fri Jul 31 16:00:36 2015 +0200
usb: gadget: net2280: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
commit f95aec51da16250841a4254db36f9771446cdbb6
Author: Robert Baldyga <r.baldyga@samsung.com>
Date: Fri Jul 31 16:00:35 2015 +0200
usb: gadget: net2272: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
commit 43710a8dba9ae607decdeaf7a56a51dd5b42184e
Author: Robert Baldyga <r.baldyga@samsung.com>
Date: Fri Jul 31 16:00:34 2015 +0200
usb: gadget: mv_udc_core: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
commit c12a30629f8b5fe8c2aba42c3128df702bbc9e83
Author: Robert Baldyga <r.baldyga@samsung.com>
Date: Fri Jul 31 16:00:33 2015 +0200
usb: gadget: mv_u3d_core: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
commit 8ddbf94fd5b536b3adf5ffa631c5951718e7301d
Author: Robert Baldyga <r.baldyga@samsung.com>
Date: Fri Jul 31 16:00:32 2015 +0200
usb: gadget: m66592-udc: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
commit 4d75c8bd613c5ba99ee02cfe38610c82e7fe8362
Author: Robert Baldyga <r.baldyga@samsung.com>
Date: Fri Jul 31 16:00:31 2015 +0200
usb: gadget: lpc32xx_udc: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
commit 892269925991b449ae47dcc0debb324ae451022e
Author: Robert Baldyga <r.baldyga@samsung.com>
Date: Fri Jul 31 16:00:30 2015 +0200
usb: gadget: gr_udc: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
commit b0bf5fbfbd30ffbb9e45169f78412f0596e16412
Author: Robert Baldyga <r.baldyga@samsung.com>
Date: Fri Jul 31 16:00:29 2015 +0200
usb: gadget: goku_udc: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
commit 455d11c93582c4167f55af0969b83821450be120
Author: Robert Baldyga <r.baldyga@samsung.com>
Date: Fri Jul 31 16:00:28 2015 +0200
usb: gadget: fusb300_udc: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
commit 60a28c63712f190b45e9d8f0ca593c927970fd51
Author: Robert Baldyga <r.baldyga@samsung.com>
Date: Fri Jul 31 16:00:27 2015 +0200
usb: gadget: fsl_udc_core: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
commit e8fc42f6a19af320d7a4718c05c3f249bf5d3151
Author: Robert Baldyga <r.baldyga@samsung.com>
Date: Fri Jul 31 16:00:26 2015 +0200
usb: gadget: fsl_qe_udc: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
commit 8d29237a436dc8e2b5c44dd0ca662a680f16deb5
Author: Robert Baldyga <r.baldyga@samsung.com>
Date: Fri Jul 31 16:00:25 2015 +0200
usb: gadget: fotg210-udc: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
commit 7a3b8e7098946b44c014f3df0ceef27fb273c142
Author: Robert Baldyga <r.baldyga@samsung.com>
Date: Fri Jul 31 16:00:24 2015 +0200
usb: gadget: dummy-hcd: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
commit b079dd6156a6544e0383642a9ec97d17485aa244
Author: Robert Baldyga <r.baldyga@samsung.com>
Date: Fri Jul 31 16:00:23 2015 +0200
usb: gadget: bdc: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
commit 1b0ba527702268992a62227dde4911477f057ca5
Author: Robert Baldyga <r.baldyga@samsung.com>
Date: Fri Jul 31 16:00:22 2015 +0200
usb: gadget: bcm63xx_udc: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
commit b9ed96d7d579416a8fd2e1cef66541bfdad2720f
Author: Robert Baldyga <r.baldyga@samsung.com>
Date: Fri Jul 31 16:00:21 2015 +0200
usb: gadget: at91_udc: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
commit 6f02ac5ac9bba538593e4359dd5e83c4d42822fe
Author: Robert Baldyga <r.baldyga@samsung.com>
Date: Fri Jul 31 16:00:20 2015 +0200
usb: gadget: amd5536udc: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
commit a474d3b73ba7f22844e672ac004f01cd9b8be159
Author: Robert Baldyga <r.baldyga@samsung.com>
Date: Fri Jul 31 16:00:19 2015 +0200
usb: dwc3: gadget: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
commit 2954522f135246287c36524bc96e9dae8c40f8a9
Author: Robert Baldyga <r.baldyga@samsung.com>
Date: Fri Jul 31 16:00:18 2015 +0200
usb: dwc2: gadget: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
commit a7e3f1410855db6b67ec29a386e74be2df3cc311
Author: Robert Baldyga <r.baldyga@samsung.com>
Date: Fri Jul 31 16:00:17 2015 +0200
usb: chipidea: udc: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
commit 68b5c947515a252b9e416e419fca4c1382912948
Author: Robert Baldyga <r.baldyga@samsung.com>
Date: Fri Jul 31 16:00:16 2015 +0200
staging: emxx_udc: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Fixed typo in "epc-nulk" to "epc-bulk".
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
commit 80e6e3847f851fc05e63265050115e29e2a50d7e
Author: Robert Baldyga <r.baldyga@samsung.com>
Date: Fri Jul 31 16:00:15 2015 +0200
usb: gadget: add endpoint capabilities helper macros
Add macros useful while initializing array of endpoint capabilities
structures. These macros makes structure initialization more compact
to decrease number of code lines and increase readability of code.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
commit 734b5a2addd333829a6d647ee14a3609c7a87c44
Author: Robert Baldyga <r.baldyga@samsung.com>
Date: Fri Jul 31 16:00:14 2015 +0200
usb: gadget: add endpoint capabilities flags
Introduce struct usb_ep_caps which contains information about capabilities
of usb endpoints - supported transfer types and directions. This structure
should be filled by UDC driver for each of its endpoints, and will be
used in epautoconf in new ep matching mechanism which will replace ugly
guessing of endpoint capabilities basing on its name.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
commit cc476b42a39d5a66d94f46cade972dcb8ee278df
Author: Robert Baldyga <r.baldyga@samsung.com>
Date: Fri Jul 31 16:00:13 2015 +0200
usb: gadget: encapsulate endpoint claiming mechanism
So far it was necessary for usb functions to set ep->driver_data in
endpoint obtained from autoconfig to non-null value, to indicate that
endpoint is claimed by function (in autoconfig it was checked if endpoint
has set this field to non-null value, and if it has, it was assumed that
it is claimed). It could cause bugs because if some function doesn't
set this field autoconfig could return the same endpoint more than one
time.
To help to avoid such bugs this patch adds claimed flag to struct usb_ep,
and encapsulates endpoint claiming mechanism inside usb_ep_autoconfig_ss()
and usb_ep_autoconfig_reset(), so now usb functions don't need to perform
any additional actions to mark endpoint obtained from autoconfig as claimed.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
commit 94e5c23d3c52f58f4051810a15aeacc085127ad1
Author: Axel Lin <axel.lin@ingics.com>
Date: Tue Aug 4 13:52:22 2015 +0800
spi: pxa2xx: Add terminating entry for pxa2xx_spi_pci_compound_match
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
commit 89a6356676eba38e498507b5b67dcc07a714a149
Author: Colin Ian King <colin.king@canonical.com>
Date: Fri Jul 31 13:42:29 2015 +0100
spi: spidev: fix inconsistent indenting
Fix inconsistent indenting in spidev_open, no functional change.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
commit 0f4315a8f1a73f130bbc5dde134b704ea6dda56c
Author: Felipe Balbi <balbi@ti.com>
Date: Tue Aug 4 11:02:45 2015 -0500
usb: gadget: f_uac2: fix build warning
commit 913e4a90b6f9 ("usb: gadget: f_uac2:
finalize wMaxPacketSize according to bandwidth")
added a possible build warning when calling
min(). In order to fix the warning, we just
make sure to call min_t() and tell that its
arguments should be u16.
Cc: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
commit 7f352964852ede9e95d18fd3825c5200fb48b3a5
Author: Saurabh Karajgaonkar <skarajga@visteon.com>
Date: Tue Aug 4 14:02:28 2015 +0000
usb: musb: musb_dsps: Simplify return statement
Replace redundant variable use in return statement.
Signed-off-by: Saurabh Karajgaonkar <skarajga@visteon.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
commit c5673f5ce4c0faa97df419877bcdebbd76d43151
Author: Saurabh Karajgaonkar <skarajga@visteon.com>
Date: Tue Aug 4 14:02:03 2015 +0000
usb: phy: phy-keystone: Simplify return statement
Replace redundant variable use in return statement.
Signed-off-by: Saurabh Karajgaonkar <skarajga@visteon.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
commit 4b68b50fd45e2f429da574c74d9a3788a861434f
Author: Saurabh Karajgaonkar <skarajga@visteon.com>
Date: Tue Aug 4 14:01:31 2015 +0000
usb: phy: phy-mxs-usb: Simplify return statement
Replace redundant variable use in return statement.
Signed-off-by: Saurabh Karajgaonkar <skarajga@visteon.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
commit 5406898354ebfb11f49b955fb5e49a62786a542f
Author: Mengdong Lin <mengdong.lin@intel.com>
Date: Tue Aug 4 15:47:35 2015 +0100
ASoC: topology: fix typo in soc_tplg_kcontrol_bind_io()
Signed-off-by: Mengdong Lin <mengdong.lin@intel.com>
Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
commit 6d3ec14d703c660c4baf8d726538b5415e23b4fb
Author: Lukas Czerner <lczerner@redhat.com>
Date: Tue Aug 4 11:21:52 2015 -0400
jbd2: limit number of reserved credits
Currently there is no limitation on number of reserved credits we can
ask for. If we ask for more reserved credits than 1/2 of maximum
transaction size, or if total number of credits exceeds the maximum
transaction size per operation (which is currently only possible with
the former) we will spin forever in start_this_handle().
Fix this by adding this limitation at the start of start_this_handle().
This patch also removes the credit limitation 1/2 of maximum transaction
size, since we really only want to limit the number of reserved credits.
There is not much point to limit the credits if there is still space in
the journal.
This accidentally also fixes the online resize, where due to the
limitation of the journal credits we're unable to grow file systems with
1k block size and size between 16M and 32M. It has been partially fixed
by 2c869b262a10ca99cb866d04087d75311587a30c, but not entirely.
Thanks Jan Kara for helping me getting the correct fix.
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
commit 21caf3a765b0a88f8fedf63b36e5d15683b73fe5
Author: Lorenzo Nava <lorenx4@gmail.com>
Date: Thu Jul 2 17:28:03 2015 +0100
ARM: 8398/1: arm DMA: Fix allocation from CMA for coherent DMA
This patch allows the use of CMA for DMA coherent memory allocation.
At the moment if the input parameter "is_coherent" is set to true
the allocation is not made using the CMA, which I think is not the
desired behaviour.
The patch covers the allocation and free of memory for coherent
DMA.
Signed-off-by: Lorenzo Nava <lorenx4@gmail.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
commit c0e736629b89ec176ab4dba45943364cbdc135ba
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Tue Aug 4 15:22:11 2015 +0200
drm/fb-helper: Move drm_fb_helper_force_kernel_mode() inside #ifdef
If CONFIG_MAGIC_SYSRQ is not set:
drivers/gpu/drm/drm_fb_helper.c:390:13: warning: 'drm_fb_helper_force_kernel_mode' defined but not used [-Wunused-function]
static bool drm_fb_helper_force_kernel_mode(void)
^
Move drm_fb_helper_force_kernel_mode() inside the existing #ifdef to fix
this.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
commit b996f201b74e52f9e9da47e1377e0b948d5ba25c
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Tue Aug 4 15:22:10 2015 +0200
drm/fb-helper: Clarify drm_fb_helper_restore_fbdev_mode*()
As of commit 5ea1f752ae04be40 ("drm: add
drm_fb_helper_restore_fbdev_mode_unlocked()"),
drm_fb_helper_restore_fbdev_mode() is no longer public, and drivers
should call drm_fb_helper_restore_fbdev_mode_unlocked() from their
->lastclose callbacks instead.
Update the documentation to reflect this, and absorb the one liner
drm_fb_helper_restore_fbdev_mode() into its single caller.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
commit 714dc94e0d22ef951722f5d6ec316f4a7867f850
Author: Jiri Kosina <jkosina@suse.com>
Date: Tue Aug 4 15:46:10 2015 +0200
Revert "HID: core/input: Fix accessing freed memory during driver unbind"
This reverts commit e19232a20913513fbb4b21ac8f45a4b9a805d6e4.
It's broken and is going to be replaced with the one from
for-4.2/upstream-fixes-devm-fixed branch.
This is for-next branch only revert, both the original commit and the
revert will never make it to Linus (instead a fixed version will be
sent directly).
commit 0621809e37936e7c2b3eac9165cf2aad7f9189eb
Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Date: Mon Aug 3 14:57:30 2015 +0900
HID: hid-input: Fix accessing freed memory during device disconnect
During unbinding the driver was dereferencing a pointer to memory
already freed by power_supply_unregister().
Driver was freeing its internal description of battery through pointers
stored in power_supply structure. However, because the core owns the
power supply instance, after calling power_supply_unregister() this
memory is freed and the driver cannot access these members.
Fix this by storing the pointer to internal description of battery in a
local variable before calling power_supply_unregister(), so the pointer
remains valid.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Reported-by: H.J. Lu <hjl.tools@gmail.com>
Fixes: 297d716f6260 ("power_supply: Change ownership from driver to core")
Cc: <stable@vger.kernel.org>
Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
commit 3f14a63a544374225c17221a5058748360428dc3
Author: Jason Gerecke <killertofu@gmail.com>
Date: Mon Aug 3 10:17:05 2015 -0700
HID: wacom: Remove WACOM_QUIRK_NO_INPUT
WACOM_QUIRK_NO_INPUT is a signal to the driver that input devices
should not be created for a particular device. This quirk was used by
the wireless receiver to prevent any devices from being created during
the initial probe (defering it instead until we got a tablet connection
event in 'wacom_wireless_work').
This quirk is not necessary now that a device_type is associated with each
device. Any input device allocated by 'wacom_allocate_inputs' which is
not necessary for a particular device is freed in 'wacom_register_inputs'.
In particular, none of the wireless receivers devices have the pen, pad,
or touch device types set so the same effect is achieved without the need
to be explicit.
We now return early in wacom_retrieve_hid_descriptor for wireless devices
(to prevent the device_type from being overridden) but since we ignore the
HID descriptor for the wireless reciever anyway, this is not an issue.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
commit ccad85cc1ee34509840e5af80a436ceaf0b71edb
Author: Jason Gerecke <killertofu@gmail.com>
Date: Mon Aug 3 10:17:04 2015 -0700
HID: wacom: Replace WACOM_QUIRK_MONITOR with WACOM_DEVICETYPE_WL_MONITOR
The monitor interface on the wireless receiver is more logically expressed
as a type of device instead of a quirk.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
commit 8dc8641e619228153ab0bc609f9f534126e87c08
Author: Jason Gerecke <killertofu@gmail.com>
Date: Mon Aug 3 10:17:03 2015 -0700
HID: wacom: Use calculated pkglen for wireless touch interface
Commit 01c846f introduced the 'wacom_compute_pktlen' function which
automatically determines the correct value for an interface's pkglen
by scanning the HID descriptor. This function returns the correct
value for the wireless receiver's touch interface, removing the need
for us to set it manually here.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
commit 061357a06c69dfa805a033ae22d668de16191cd4
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Tue Aug 4 14:28:17 2015 +0200
ARM: shmobile: R-Mobile: Use CPG/MSTP Clock Domain attach/detach helpers
The R-Mobile PM Domain driver manages both power domains and a clock
domain.
The clock domain part is very similar to the CPG/MSTP Clock Domain,
which is used on shmobile SoCs without device power domains, except for
the way how clocks suitable for power management are selected:
- The former uses the first clock tied to the device through the NULL
con_id, which is a relic from the legacy pm_clk_notifier-based
method in drivers/sh/pm_runtime.c,
- The latter looks for suitable clocks in DT, which is more
future-proof.
All platforms using this driver are now supported in DT-based ARM
multi-platform builds only, hence switch to using the CPG/MSTP Clock
Domain helpers.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
commit a1a1fdd83722a30efc705a5032ace2ad20b2ca6d
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Tue Aug 4 15:25:35 2015 +0200
clk: shmobile: mstp: Consider "zb_clk" suitable for power management
Currently the CPG/MSTP Clock Domain code looks for MSTP clocks to power
manage a device.
Unfortunately, on R-Mobile APE6 (r8a73a4) and SH-Mobile AG5 (sh73a0),
the Bus State Controller (BSC) is not power-managed by an MSTP clock,
but by a plain CPG clock (zb_clk). Add a special case to handle this,
so the clock is properly managed, and devices connected to the BSC work
as expected.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
commit 6989c8c4cfa7f7cd406906e1abbe7b073d3d66e0
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Tue Aug 4 14:28:15 2015 +0200
drivers: sh: Disable PM runtime for multi-platform ARM with genpd
If the default PM Domain using PM_CLK is used for PM runtime, the real
Clock Domain cannot be registered from DT later.
Hence do not enable it when running a multi-platform kernel with genpd
support on R-Car or RZ. The CPG/MSTP Clock Domain driver will take care
of PM runtime management of the module clocks.
Now most multi-platform ARM shmobile platforms (SH-Mobile, R-Mobile,
R-Car, RZ) use DT-based PM Domains to take care of PM runtime management
of the module clocks, simplify the platform logic by replacing the
explicit SoC checks by a single check for the presence of MSTP clocks in
DT.
Backwards-compatiblity with old DTs (mainly for R-Car Gen2) is provided
by checking for the presence of a "#power-domain-cells" property in DT.
The default PM Domain is still needed for:
- backwards-compatibility with old DTs that lack PM Domain properties,
- the CONFIG_PM=n case,
- legacy (non-DT) ARM/shmobile platforms without genpd support
(r8a7778, r8a7779),
- legacy SuperH.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
commit d7c01f3aba883c57aacc57f884e9081d00d1dec7
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Tue Aug 4 14:28:14 2015 +0200
drivers: sh: Disable legacy default PM Domain on emev2
EMMA Mobile EV2 doesn't have MSTP clocks. All its device drivers manage
clocks explicitly, without relying on Runtime PM, so it doesn't need the
legacy default PM Domain.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
commit ba56d432e1dc98aa5df5930a0707d79e40fd5e39
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Tue Aug 4 14:28:13 2015 +0200
ARM: shmobile: r8a7794 dtsi: Add CPG/MSTP Clock Domain
Add an appropriate "#power-domain-cells" property to the cpg_clocks
device node, to create the CPG/MSTP Clock Domain.
Add "power-domains" properties to all device nodes for devices that are
part of the CPG/MSTP Clock Domain and can be power-managed through an
MSTP clock. This applies to most on-SoC devices, which have a
one-to-one mapping from SoC device to DT device node.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
commit 23a7abb77197044b6e708e0d0d31d89bf1e68bf1
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Tue Aug 4 14:28:12 2015 +0200
ARM: shmobile: r8a7793 dtsi: Add CPG/MSTP Clock Domain
Add an appropriate "#power-domain-cells" property to the cpg_clocks
device node, to create the CPG/MSTP Clock Domain.
Add "power-domains" properties to all device nodes for devices that are
part of the CPG/MSTP Clock Domain and can be power-managed through an
MSTP clock. This applies to most on-SoC devices, which have a
one-to-one mapping from SoC device to DT device node.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
commit a5ab8bf59f7ec14081e161bad52430e37def1189
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Tue Aug 4 14:28:11 2015 +0200
ARM: shmobile: r8a7791 dtsi: Add CPG/MSTP Clock Domain
Add an appropriate "#power-domain-cells" property to the cpg_clocks
device node, to create the CPG/MSTP Clock Domain.
Add "power-domains" properties to all device nodes for devices that are
part of the CPG/MSTP Clock Domain and can be power-managed through an
MSTP clock. This applies to most on-SoC devices, which have a
one-to-one mapping from SoC device to DT device node. Notable
exceptions are the "display" and "sound" nodes, which represent multiple
SoC devices, each having their own MSTP clocks.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
commit 835a058492b1d539e891af12ce37713b1fb327e9
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Tue Aug 4 14:28:10 2015 +0200
ARM: shmobile: r8a7790 dtsi: Add CPG/MSTP Clock Domain
Add an appropriate "#power-domain-cells" property to the cpg_clocks
device node, to create the CPG/MSTP Clock Domain.
Add "power-domains" properties to all device nodes for devices that are
part of the CPG/MSTP Clock Domain and can be power-managed through an
MSTP clock. This applies to most on-SoC devices, which have a
one-to-one mapping from SoC device to DT device node. Notable
exceptions are the "display" and "sound" nodes, which represent multiple
SoC devices, each having their own MSTP clocks.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
commit 3397481089b3ab931536b26fb65ef4a41eefdb67
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Tue Aug 4 14:28:09 2015 +0200
ARM: shmobile: r8a7779 dtsi: Add CPG/MSTP Clock Domain
Add an appropriate "#power-domain-cells" property to the cpg_clocks
device node, to create the CPG/MSTP Clock Domain.
Add "power-domains" properties to all device nodes for devices that are
part of the CPG/MSTP Clock Domain and can be power-managed through an
MSTP clock. This applies to most on-SoC devices, which have a
one-to-one mapping from SoC device to DT device node.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
commit 6d3bba42aef6eb7594b845518a51d5aa094d3502
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Tue Aug 4 14:28:08 2015 +0200
ARM: shmobile: r8a7778 dtsi: Add CPG/MSTP Clock Domain
Add an appropriate "#power-domain-cells" property to the cpg_clocks
device node, to create the CPG/MSTP Clock Domain.
Add "power-domains" properties to all device nodes for devices that are
part of the CPG/MSTP Clock Domain and can be power-managed through an
MSTP clock. This applies to most on-SoC devices, which have a
one-to-one mapping from SoC device to DT device node. A notable
exception is the "sound" node, which represents multiple SoC devices,
each having their own MSTP clocks.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
commit d45696723575a6a7fbb43b754fb89121746b5982
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Tue Aug 4 14:28:07 2015 +0200
ARM: shmobile: r7s72100 dtsi: Add CPG/MSTP Clock Domain
Add an appropriate "#power-domain-cells" property to the cpg_clocks
device node, to create the CPG/MSTP Clock Domain.
Add "power-domains" properties to all device nodes for devices that are
part of the CPG/MSTP Clock Domain and can be power-managed through an
MSTP clock. This applies to most on-SoC devices, which have a
one-to-one mapping from SoC device to DT device node.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
commit 584bf98feb6c38875b76d17ed52e89711b4b5577
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Tue Aug 4 14:28:06 2015 +0200
clk: shmobile: rz: Add CPG/MSTP Clock Domain support
Add Clock Domain support to the RZ Clock Pulse Generator (CPG) driver
using the generic PM Domain. This allows to power-manage the module
clocks of SoC devices that are part of the CPG/MSTP Clock Domain using
Runtime PM, or for system suspend/resume.
SoC devices that are part of the CPG/MSTP Clock Domain and can be
power-managed through an MSTP clock should be tagged in DT with a proper
"power-domains" property.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Stephen Boyd <sboyd@codeaurora.org>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
commit 3602362dcc18fd46a066583fe2a13b57b3df159e
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Tue Aug 4 14:28:05 2015 +0200
clk: shmobile: rcar-gen2: Add CPG/MSTP Clock Domain support
Add Clock Domain support to the R-Car Gen2 Clock Pulse Generator (CPG)
driver using the generic PM Domain. This allows to power-manage the
module clocks of SoC devices that are part of the CPG/MSTP Clock Domain
using Runtime PM, or for system suspend/resume.
SoC devices that are part of the CPG/MSTP Clock Domain and can be
power-managed through an MSTP clock should be tagged in DT with a proper
"power-domains" property.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Stephen Boyd <sboyd@codeaurora.org>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
commit 4aabed77053836418de7065a37414526099b889c
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Tue Aug 4 14:28:04 2015 +0200
clk: shmobile: r8a7779: Add CPG/MSTP Clock Domain support
Add Clock Domain support to the R-Car H1 Clock Pulse Generator (CPG)
driver using the generic PM Domain. This allows to power-manage the
module clocks of SoC devices that are part of the CPG/MSTP Clock Domain
using Runtime PM, or for system suspend/resume.
SoC devices that are part of the CPG/MSTP Clock Domain and can be
power-managed through an MSTP clock should be tagged in DT with a proper
"power-domains" property.
Also update the reg property in the DT binding doc example to match the
actual dtsi, which uses #address-cells and #size-cells == 1, not 2.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Stephen Boyd <sboyd@codeaurora.org>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
commit aef2b0f2dbc72f79289d74d7c1fefcd25ae11627
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Tue Aug 4 14:28:03 2015 +0200
clk: shmobile: r8a7778: Add CPG/MSTP Clock Domain support
Add Clock Domain support to the R-Car M1A Clock Pulse Generator (CPG)
driver using the generic PM Domain. This allows to power-manage the
module clocks of SoC devices that are part of the CPG/MSTP Clock Domain
using Runtime PM, or for system suspend/resume.
SoC devices that are part of the CPG/MSTP Clock Domain and can be
power-managed through an MSTP clock should be tagged in DT with a proper
"power-domains" property.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Stephen Boyd <sboyd@codeaurora.org>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
commit 1fcc5dc775d0d79153dda6fee1502ab96344b823
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Tue Aug 4 14:28:02 2015 +0200
clk: shmobile: Add CPG/MSTP Clock Domain support
Add Clock Domain support to the Clock Pulse Generator (CPG) Module Stop
(MSTP) Clocks driver using the generic PM Domain. This allows to
power-manage the module clocks of SoC devices that are part of the
CPG/MSTP Clock Domain using Runtime PM, or for system suspend/resume.
SoC devices that are part of the CPG/MSTP Clock Domain and can be
power-managed through an MSTP clock should be tagged in DT with a
proper "power-domains" property.
The CPG/MSTP Clock Domain code will scan such devices for clocks that
are suitable for power-managing the device, by looking for a clock that
is compatible with "renesas,cpg-mstp-clocks".
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Stephen Boyd <sboyd@codeaurora.org>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
commit a4198fd4b487afc60810f5a12b994721df220022
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu Jul 30 17:53:23 2015 +0800
crypto: testmgr - Reenable authenc tests
Now that all implementations of authenc have been converted we can
reenable the tests.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
commit aeb4c132f33d21f6cf37558a932e66e40dd8982e
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu Jul 30 17:53:22 2015 +0800
crypto: talitos - Convert to new AEAD interface
This patch converts talitos to the new AEAD interface. IV generation
has been removed since it's equivalent to a software implementation.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
commit e19ab1211d2848ebd028c824041d8ea249fa3aae
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu Jul 30 17:53:20 2015 +0800
crypto: qat - Convert to new AEAD interface
This patch converts qat to the new AEAD interface. IV generation
has been removed since it's equivalent to a software implementation.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Tested-by: Tadeusz Struk <tadeusz.struk@intel.com>
commit c1359495c8a19fa686aa48512e0290d2f3846273
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu Jul 30 17:53:19 2015 +0800
crypto: picoxcell - Convert to new AEAD interface
This patch converts picoxcell to the new AEAD interface. IV
generation has been removed since it's equivalent to a software
implementation.
As picoxcell cannot handle SG lists longer than 16 elements,
this patch has made the software fallback mandatory. If an SG
list comes in that exceeds the limit, we will simply use the
fallback.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
commit d7295a8dc965ee0d5b3f9b1eb7f556c2bfa78420
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu Jul 30 17:53:18 2015 +0800
crypto: ixp4xx - Convert to new AEAD interface
This patch converts ixp4xx to the new AEAD interface. IV generation
has been removed since it's a purely software implementation.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
commit 479bcc7c5b9e1cbf3278462d786c37e468d5d404
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu Jul 30 17:53:17 2015 +0800
crypto: caam - Convert authenc to new AEAD interface
This patch converts the authenc implementations in caam to the
new AEAD interface. The biggest change is that seqiv no longer
generates a random IV. Instead the IPsec sequence number is used
as the IV.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
commit 92d95ba91772279b6ef9c6e09661f67abcf27259
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu Jul 30 17:53:16 2015 +0800
crypto: authenc - Convert to new AEAD interface
This patch converts authenc to the new AEAD interface.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
commit 7079ce62c0e9bfcca35214105c08a2d00fbea9ee
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu Jul 30 17:53:14 2015 +0800
crypto: testmgr - Disable authenc test and convert test vectors
This patch disables the authenc tests while the conversion to the
new IV calling convention takes place. It also replaces the authenc
test vectors with ones that will work with the new IV convention.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
commit fdf036507f1fc036d5a06753e9e8b13f46de73e8
Author: Fan Zhang <zhangfan@linux.vnet.ibm.com>
Date: Wed May 13 10:58:41 2015 +0200
KVM: s390: host STP toleration for VMs
If the host has STP enabled, the TOD of the host will be changed during
synchronization phases. These are performed during a stop_machine() call.
As the guest TOD is based on the host TOD, we have to make sure that:
- no VCPU is in the SIE (implicitly guaranteed via stop_machine())
- manual guest TOD calculations are not affected
"Epoch" is the guest TOD clock delta to the host TOD clock. We have to
adjust that value during the STP synchronization and make sure that code
that accesses the epoch won't get interrupted in between (via disabling
preemption).
Signed-off-by: Fan Zhang <zhangfan@linux.vnet.ibm.com>
Reviewed-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
Acked-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
commit 8578531dea9672fa17cce66d320ed7d7c17c837f
Author: Martin Schwidefsky <schwidefsky@de.ibm.com>
Date: Mon Aug 3 16:16:40 2015 +0200
s390/vtime: limit MT scaling value updates
The MT scaling values are updated on each calll to do_account_vtime.
This function is called for each HZ interrupt and for each context
switch. Context switch can happen often, the STCCTM instruction
on this path is noticable. Limit the updates to once per jiffy.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
commit 5a7ff75a0c63222d138d944240146dc49a9624e1
Author: Heiko Carstens <heiko.carstens@de.ibm.com>
Date: Tue Aug 4 09:15:58 2015 +0200
s390/syscalls: ignore syscalls reachable via sys_socketcall
x86 will wire up all syscalls reachable via sys_socketcall. Therefore this
will yield a lot of warnings from the checksyscalls.sh scripts on s390
where we currently don't wire them up directly.
This might change in the future, but this needs to be done carefully in
order to not break anything.
For the time being just tell the checksyscalls script to ignore the missing
syscalls on s390.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
commit a763bc8b656d11b7424cd2696e19efca301d8aa4
Author: Philipp Hachtmann <phacht@linux.vnet.ibm.com>
Date: Fri May 8 17:40:44 2015 +0200
s390/numa: enable support in s390 configs
Signed-off-by: Philipp Hachtmann <phacht@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
commit c29a7baf091fc6b2c9e40561030f8c62e6145a19
Author: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Date: Thu Mar 6 18:47:21 2014 +0100
s390/numa: add emulation support
NUMA emulation (aka fake NUMA) distributes the available memory to nodes
without using real topology information about the physical memory of the
machine.
Splitting the system memory into nodes replicates the memory management
structures for each node. Particularly each node has its own "mm locks"
and its own "kswapd" task.
For large systems, under certain conditions, this results in improved
system performance and/or latency based on reduced pressure on the mm
locks and the kswapd tasks.
NUMA emulation distributes CPUs to nodes while respecting the original
machine topology information. This is done by trying to avoid to separate
CPUs which reside on the same book or even on the same MC. Because the
current Linux scheduler code requires a stable cpu to node mapping, cores
are pinned to nodes when the first CPU thread is set online.
This patch is based on the initial implementation from Philipp Hachtmann.
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
commit 56113f6e6f8d57d3c184544c6421422558a9988e
Author: Joe Perches <joe@perches.com>
Date: Mon Aug 3 10:49:29 2015 -0700
ASoC: atmel_ssc_dai: Correct misuse of 0x%<decimal>
Correct misuse of 0x%d in logging message.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
commit 4e491fe7920cb84dd0a2ea79800173ab1802fa22
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date: Tue Aug 4 10:47:23 2015 +0300
extcon: Fix signedness bugs about break error handling
Unsigned is never less than zero so this error handling won't work.
Fixes: be052cc87745 ('extcon: Fix hang and extcon_get/set_cable_state().')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Roger Quadros <rogerq@ti.com>
[cw00.choi: Change the patch title and fix signedness bug of find_cable_index_by_id() ]
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
commit 76bea64c4c8d7fa911eb485c4c2b8583e813331e
Author: Aaron Sierra <asierra@xes-inc.com>
Date: Mon Aug 3 18:56:21 2015 -0500
crypto: talitos - Remove zero_entry static initializer
Compiling the talitos driver with my GCC 4.3.1 e500v2 cross-compiler
resulted in a failed build due to the anonymous union/structures
introduced in this commit:
crypto: talitos - enhanced talitos_desc struct for SEC1
The build error was:
drivers/crypto/talitos.h:56: error: unknown field 'len' specified in initializer
drivers/crypto/talitos.h:56: warning: missing braces around initializer
drivers/crypto/talitos.h:56: warning: (near initialization for 'zero_entry.<anonymous>')
drivers/crypto/talitos.h:57: error: unknown field 'j_extent' specified in initializer
drivers/crypto/talitos.h:58: error: unknown field 'eptr' specified in initializer
drivers/crypto/talitos.h:58: warning: excess elements in struct initializer
drivers/crypto/talitos.h:58: warning: (near initialization for 'zero_entry')
make[2]: *** [drivers/crypto/talitos.o] Error 1
make[1]: *** [drivers/crypto] Error 2
make: *** [drivers] Error 2
This patch eliminates the errors by relying on the C standard's
implicit assignment of zero to static variables.
Signed-off-by: Aaron Sierra <asierra@xes-inc.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
commit f6e45c24f401f3d0e648bfba304c83b64d763559
Author: Stephan Mueller <smueller@chronox.de>
Date: Mon Aug 3 09:08:05 2015 +0200
crypto: doc - AEAD API conversion
The AEAD API changes are now reflected in the crypto API doc book.
Signed-off-by: Stephan Mueller <smueller@chronox.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
commit 327cbbabfb77c321fb9f21068c18e6bb951d07a7
Author: Colin Ian King <colin.king@canonical.com>
Date: Mon Aug 3 00:05:03 2015 +0100
crypto: img-hash - fix spelling mistake in dev_err error message
Trival change, fix spelling mistake 'aquire' -> 'acquire' in
dev_err message.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
commit f109ff110b0f3e34cea45996734da485a2fdaa42
Author: Hariprasad Shenai <hariprasad@chelsio.com>
Date: Tue Aug 4 14:36:20 2015 +0530
cxgb4: Update T6 register ranges
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit d86bd29e0b31f30d5d85ab21385b59703ecc6464
Author: Hariprasad Shenai <hariprasad@chelsio.com>
Date: Tue Aug 4 14:36:19 2015 +0530
cxgb4/cxgb4vf: read the correct bits of PL Who Am I register
Read the correct bits of PL Who Am I for the Source PF field which has
changed in T6
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit bf8ebb67dae0a07db7aebe7a65c178ff24d90842
Author: Hariprasad Shenai <hariprasad@chelsio.com>
Date: Tue Aug 4 14:36:18 2015 +0530
cxgb4: Add support to dump edc bist status
Add support to dump edc bist status for ECC data errors
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 5888111cb8f7368304db42787c9495d4b2b82e06
Author: Hariprasad Shenai <hariprasad@chelsio.com>
Date: Tue Aug 4 14:36:17 2015 +0530
cxgb4: Add debugfs support to dump meminfo
Add debug support to dump memory address ranges of various hardware
modules of the adapter.
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit c231afa3ccf176490dcafc3666559e7567690e76
Author: Christian Borntraeger <borntraeger@de.ibm.com>
Date: Tue Aug 4 09:33:44 2015 +0200
compiler.h: cast away attributes in WRITE_ONCE magic
kernel build bot showed a warning triggered by commit
76695af20c01 ("locking, arch: use WRITE_ONCE()/READ_ONCE() in
smp_store_release()/smp_load_acquire()"). Turns out that sparse
does not like WRITE_ONCE accessing elements from the (sparse)
rcu address space.
fs/afs/inode.c:448:9: sparse: incorrect type in initializer (different address spaces)
fs/afs/inode.c:448:9: expected struct afs_permits *__val
fs/afs/inode.c:448:9: got void [noderef] <asn:4>*<noident>
Solution is to force cast away the sparse attributes for the initializer
of the union in WRITE_SAME. As this now gets too long, lets split
the macro.
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
commit 6b1621c4a15b9110cda7cc2e2eb3e8e1a0c2bcfc
Author: Chanwoo Choi <cw00.choi@samsung.com>
Date: Fri Jul 24 12:58:41 2015 +0900
ARM: EXYNOS: Add exynos3250 compatible to use generic cpufreq driver
This patch add exynos3250 compatible string to exynos_cpufreq_matches
for supporting generic cpufreq driver on Exynos3250.
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Kukjin Kim <kgene@kernel.org>
commit d4f279f154138d252854a21d34626f1c7ca85b60
Author: Thomas Abraham <thomas.ab@samsung.com>
Date: Wed Jul 1 15:10:37 2015 +0200
ARM: EXYNOS: switch to using generic cpufreq driver for exynos5250
The new CPU clock type allows the use of generic CPUfreq driver.
Switch Exynos5250 to using generic cpufreq driver.
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
[b.zolnierkie: split Exynos5250 support from the original patch]
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Reviewed-by: Javier Martinez Canillas <javier@dowhile0.org>
Tested-by: Javier Martinez Canillas <javier@dowhile0.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Kukjin Kim <kgene@kernel.org>
commit a6affd24f439feddec04bab4d1e3ad6579868367
Author: Robert Shearman <rshearma@brocade.com>
Date: Mon Aug 3 17:50:04 2015 +0100
mpls: Use definition for reserved label checks
In multiple locations there are checks for whether the label in hand
is a reserved label or not using the arbritray value of 16. Factor
this out into a #define for better maintainability and for
documentation.
Signed-off-by: Robert Shearman <rshearma@brocade.com>
Acked-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 0335f5b500adcc28bc3fd5d8a1e4482c348cff4a
Author: Robert Shearman <rshearma@brocade.com>
Date: Mon Aug 3 17:39:21 2015 +0100
ipv4: apply lwtunnel encap for locally-generated packets
lwtunnel encap is applied for forwarded packets, but not for
locally-generated packets. This is because the output function is not
overridden in __mkroute_output, unlike it is in __mkroute_input.
The lwtunnel state is correctly set on the rth through the call to
rt_set_nexthop, so all that needs to be done is to override the dst
output function to be lwtunnel_output if there is lwtunnel state
present and it requires output redirection.
Signed-off-by: Robert Shearman <rshearma@brocade.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit abf7c1c540f8330fead5d50730d92606dcbe7a7e
Author: Robert Shearman <rshearma@brocade.com>
Date: Mon Aug 3 17:39:20 2015 +0100
lwtunnel: set skb protocol and dev
In the locally-generated packet path skb->protocol may not be set and
this is required for the lwtunnel encap in order to get the lwtstate.
This would otherwise have been set by ip_output or ip6_output so set
skb->protocol prior to calling the lwtunnel encap
function. Additionally set skb->dev in case it is needed further down
the transmit path.
Signed-off-by: Robert Shearman <rshearma@brocade.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 2475b22526d70234ecfe4a1ff88aed69badefba9
Author: Ross Lagerwall <ross.lagerwall@citrix.com>
Date: Mon Aug 3 15:38:03 2015 +0100
xen-netback: Allocate fraglist early to avoid complex rollback
Determine if a fraglist is needed in the tx path, and allocate it if
necessary before setting up the copy and map operations.
Otherwise, undoing the copy and map operations is tricky.
This fixes a use-after-free: if allocating the fraglist failed, the copy
and map operations that had been set up were still executed, writing
over the data area of a freed skb.
Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 10e2eb878f3ca07ac2f05fa5ca5e6c4c9174a27a
Author: Eric Dumazet <edumazet@google.com>
Date: Sat Aug 1 12:14:33 2015 +0200
udp: fix dst races with multicast early demux
Multicast dst are not cached. They carry DST_NOCACHE.
As mentioned in commit f8864972126899 ("ipv4: fix dst race in
sk_dst_get()"), these dst need special care before caching them
into a socket.
Caching them is allowed only if their refcnt was not 0, ie we
must use atomic_inc_not_ze…
kszaq
pushed a commit
to kszaq/linux
that referenced
this pull request
Apr 9, 2016
Dave Jones got the following lockdep splat: > ====================================================== > [ INFO: possible circular locking dependency detected ] > 3.12.0-rc3+ torvalds#92 Not tainted > ------------------------------------------------------- > trinity-child2/15191 is trying to acquire lock: > (&rdp->nocb_wq){......}, at: [<ffffffff8108ff43>] __wake_up+0x23/0x50 > > but task is already holding lock: > (&ctx->lock){-.-...}, at: [<ffffffff81154c19>] perf_event_exit_task+0x109/0x230 > > which lock already depends on the new lock. > > > the existing dependency chain (in reverse order) is: > > -> codesnake#3 (&ctx->lock){-.-...}: > [<ffffffff810cc243>] lock_acquire+0x93/0x200 > [<ffffffff81733f90>] _raw_spin_lock+0x40/0x80 > [<ffffffff811500ff>] __perf_event_task_sched_out+0x2df/0x5e0 > [<ffffffff81091b83>] perf_event_task_sched_out+0x93/0xa0 > [<ffffffff81732052>] __schedule+0x1d2/0xa20 > [<ffffffff81732f30>] preempt_schedule_irq+0x50/0xb0 > [<ffffffff817352b6>] retint_kernel+0x26/0x30 > [<ffffffff813eed04>] tty_flip_buffer_push+0x34/0x50 > [<ffffffff813f0504>] pty_write+0x54/0x60 > [<ffffffff813e900d>] n_tty_write+0x32d/0x4e0 > [<ffffffff813e5838>] tty_write+0x158/0x2d0 > [<ffffffff811c4850>] vfs_write+0xc0/0x1f0 > [<ffffffff811c52cc>] SyS_write+0x4c/0xa0 > [<ffffffff8173d4e4>] tracesys+0xdd/0xe2 > > -> #2 (&rq->lock){-.-.-.}: > [<ffffffff810cc243>] lock_acquire+0x93/0x200 > [<ffffffff81733f90>] _raw_spin_lock+0x40/0x80 > [<ffffffff810980b2>] wake_up_new_task+0xc2/0x2e0 > [<ffffffff81054336>] do_fork+0x126/0x460 > [<ffffffff81054696>] kernel_thread+0x26/0x30 > [<ffffffff8171ff93>] rest_init+0x23/0x140 > [<ffffffff81ee1e4b>] start_kernel+0x3f6/0x403 > [<ffffffff81ee1571>] x86_64_start_reservations+0x2a/0x2c > [<ffffffff81ee1664>] x86_64_start_kernel+0xf1/0xf4 > > -> #1 (&p->pi_lock){-.-.-.}: > [<ffffffff810cc243>] lock_acquire+0x93/0x200 > [<ffffffff8173419b>] _raw_spin_lock_irqsave+0x4b/0x90 > [<ffffffff810979d1>] try_to_wake_up+0x31/0x350 > [<ffffffff81097d62>] default_wake_function+0x12/0x20 > [<ffffffff81084af8>] autoremove_wake_function+0x18/0x40 > [<ffffffff8108ea38>] __wake_up_common+0x58/0x90 > [<ffffffff8108ff59>] __wake_up+0x39/0x50 > [<ffffffff8110d4f8>] __call_rcu_nocb_enqueue+0xa8/0xc0 > [<ffffffff81111450>] __call_rcu+0x140/0x820 > [<ffffffff81111b8d>] call_rcu+0x1d/0x20 > [<ffffffff81093697>] cpu_attach_domain+0x287/0x360 > [<ffffffff81099d7e>] build_sched_domains+0xe5e/0x10a0 > [<ffffffff81efa7fc>] sched_init_smp+0x3b7/0x47a > [<ffffffff81ee1f4e>] kernel_init_freeable+0xf6/0x202 > [<ffffffff817200be>] kernel_init+0xe/0x190 > [<ffffffff8173d22c>] ret_from_fork+0x7c/0xb0 > > -> #0 (&rdp->nocb_wq){......}: > [<ffffffff810cb7ca>] __lock_acquire+0x191a/0x1be0 > [<ffffffff810cc243>] lock_acquire+0x93/0x200 > [<ffffffff8173419b>] _raw_spin_lock_irqsave+0x4b/0x90 > [<ffffffff8108ff43>] __wake_up+0x23/0x50 > [<ffffffff8110d4f8>] __call_rcu_nocb_enqueue+0xa8/0xc0 > [<ffffffff81111450>] __call_rcu+0x140/0x820 > [<ffffffff81111bb0>] kfree_call_rcu+0x20/0x30 > [<ffffffff81149abf>] put_ctx+0x4f/0x70 > [<ffffffff81154c3e>] perf_event_exit_task+0x12e/0x230 > [<ffffffff81056b8d>] do_exit+0x30d/0xcc0 > [<ffffffff8105893c>] do_group_exit+0x4c/0xc0 > [<ffffffff810589c4>] SyS_exit_group+0x14/0x20 > [<ffffffff8173d4e4>] tracesys+0xdd/0xe2 > > other info that might help us debug this: > > Chain exists of: > &rdp->nocb_wq --> &rq->lock --> &ctx->lock > > Possible unsafe locking scenario: > > CPU0 CPU1 > ---- ---- > lock(&ctx->lock); > lock(&rq->lock); > lock(&ctx->lock); > lock(&rdp->nocb_wq); > > *** DEADLOCK *** > > 1 lock held by trinity-child2/15191: > #0: (&ctx->lock){-.-...}, at: [<ffffffff81154c19>] perf_event_exit_task+0x109/0x230 > > stack backtrace: > CPU: 2 PID: 15191 Comm: trinity-child2 Not tainted 3.12.0-rc3+ torvalds#92 > ffffffff82565b70 ffff880070c2dbf8 ffffffff8172a363 ffffffff824edf40 > ffff880070c2dc38 ffffffff81726741 ffff880070c2dc90 ffff88022383b1c0 > ffff88022383aac0 0000000000000000 ffff88022383b188 ffff88022383b1c0 > Call Trace: > [<ffffffff8172a363>] dump_stack+0x4e/0x82 > [<ffffffff81726741>] print_circular_bug+0x200/0x20f > [<ffffffff810cb7ca>] __lock_acquire+0x191a/0x1be0 > [<ffffffff810c6439>] ? get_lock_stats+0x19/0x60 > [<ffffffff8100b2f4>] ? native_sched_clock+0x24/0x80 > [<ffffffff810cc243>] lock_acquire+0x93/0x200 > [<ffffffff8108ff43>] ? __wake_up+0x23/0x50 > [<ffffffff8173419b>] _raw_spin_lock_irqsave+0x4b/0x90 > [<ffffffff8108ff43>] ? __wake_up+0x23/0x50 > [<ffffffff8108ff43>] __wake_up+0x23/0x50 > [<ffffffff8110d4f8>] __call_rcu_nocb_enqueue+0xa8/0xc0 > [<ffffffff81111450>] __call_rcu+0x140/0x820 > [<ffffffff8109bc8f>] ? local_clock+0x3f/0x50 > [<ffffffff81111bb0>] kfree_call_rcu+0x20/0x30 > [<ffffffff81149abf>] put_ctx+0x4f/0x70 > [<ffffffff81154c3e>] perf_event_exit_task+0x12e/0x230 > [<ffffffff81056b8d>] do_exit+0x30d/0xcc0 > [<ffffffff810c9af5>] ? trace_hardirqs_on_caller+0x115/0x1e0 > [<ffffffff810c9bcd>] ? trace_hardirqs_on+0xd/0x10 > [<ffffffff8105893c>] do_group_exit+0x4c/0xc0 > [<ffffffff810589c4>] SyS_exit_group+0x14/0x20 > [<ffffffff8173d4e4>] tracesys+0xdd/0xe2 The underlying problem is that perf is invoking call_rcu() with the scheduler locks held, but in NOCB mode, call_rcu() will with high probability invoke the scheduler -- which just might want to use its locks. The reason that call_rcu() needs to invoke the scheduler is to wake up the corresponding rcuo callback-offload kthread, which does the job of starting up a grace period and invoking the callbacks afterwards. One solution (championed on a related problem by Lai Jiangshan) is to simply defer the wakeup to some point where scheduler locks are no longer held. Since we don't want to unnecessarily incur the cost of such deferral, the task before us is threefold: 1. Determine when it is likely that a relevant scheduler lock is held. 2. Defer the wakeup in such cases. 3. Ensure that all deferred wakeups eventually happen, preferably sooner rather than later. We use irqs_disabled_flags() as a proxy for relevant scheduler locks being held. This works because the relevant locks are always acquired with interrupts disabled. We may defer more often than needed, but that is at least safe. The wakeup deferral is tracked via a new field in the per-CPU and per-RCU-flavor rcu_data structure, namely ->nocb_defer_wakeup. This flag is checked by the RCU core processing. The __rcu_pending() function now checks this flag, which causes rcu_check_callbacks() to initiate RCU core processing at each scheduling-clock interrupt where this flag is set. Of course this is not sufficient because scheduling-clock interrupts are often turned off (the things we used to be able to count on!). So the flags are also checked on entry to any state that RCU considers to be idle, which includes both NO_HZ_IDLE idle state and NO_HZ_FULL user-mode-execution state. This approach should allow call_rcu() to be invoked regardless of what locks you might be holding, the key word being "should". Reported-by: Dave Jones <davej@redhat.com> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Cc: Peter Zijlstra <peterz@infradead.org>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Apr 15, 2016
This adds test cases mostly around ARG_PTR_TO_RAW_STACK to check the verifier behaviour. [...] torvalds#84 raw_stack: no skb_load_bytes OK torvalds#85 raw_stack: skb_load_bytes, no init OK torvalds#86 raw_stack: skb_load_bytes, init OK torvalds#87 raw_stack: skb_load_bytes, spilled regs around bounds OK torvalds#88 raw_stack: skb_load_bytes, spilled regs corruption OK torvalds#89 raw_stack: skb_load_bytes, spilled regs corruption 2 OK torvalds#90 raw_stack: skb_load_bytes, spilled regs + data OK torvalds#91 raw_stack: skb_load_bytes, invalid access 1 OK torvalds#92 raw_stack: skb_load_bytes, invalid access 2 OK torvalds#93 raw_stack: skb_load_bytes, invalid access 3 OK torvalds#94 raw_stack: skb_load_bytes, invalid access 4 OK torvalds#95 raw_stack: skb_load_bytes, invalid access 5 OK torvalds#96 raw_stack: skb_load_bytes, invalid access 6 OK torvalds#97 raw_stack: skb_load_bytes, large access OK Summary: 98 PASSED, 0 FAILED Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Sep 29, 2016
There is at least one Chelsio 10Gb card which uses VPD area to store some custom blocks (example below). However pci_vpd_size() returns the length of the first block only assuming that there can be only one VPD "End Tag" and VFIO blocks access beyond that offset (since 4e1a635) which leads to the situation when the guest "cxgb3" driver fails to probe the device. The host system does not have this problem as the drives accesses the config space directly without pci_read_vpd()/... This adds a quirk to override the VPD size to a bigger value. The maximum size is taken from EEPROMSIZE in drivers/net/ethernet/chelsio/cxgb3/common.h. We do not read the tag as the cxgb3 driver does as the driver supports writing to EEPROM/VPD and when it writes, it only checks for 8192 bytes boundary. The quirk is registerted for all devices supported by the cxgb3 driver. This adds a quirk to the PCI layer (not to the cxgb3 driver) as the cxgb3 driver itself accesses VPD directly and the problem only exists with the vfio-pci driver (when cxgb3 is not running on the host and may not be even loaded) which blocks accesses beyond the first block of VPD data. However vfio-pci itself does not have quirks mechanism so we add it to PCI. Tested on: Ethernet controller [0200]: Chelsio Communications Inc T310 10GbE Single Port Adapter [1425:0030] This is its VPD: 0000 Large item 42 bytes; name 0x2 Identifier String b'10 Gigabit Ethernet-SR PCI Express Adapter' #00 [EC] len=7: b'D76809 ' #0a [FN] len=7: b'46K7897' torvalds#14 [PN] len=7: b'46K7897' #1e [MN] len=4: b'1037' torvalds#25 [FC] len=4: b'5769' #2c [SN] len=12: b'YL102035603V' #3b [NA] len=12: b'00145E992ED1' 0c00 Large item 16 bytes; name 0x2 Identifier String b'S310E-SR-X ' 0c13 Large item 234 bytes; name 0x10 #00 [PN] len=16: b'TBD ' torvalds#13 [EC] len=16: b'110107730D2 ' torvalds#26 [SN] len=16: b'97YL102035603V ' torvalds#39 [NA] len=12: b'00145E992ED1' torvalds#48 [V0] len=6: b'175000' torvalds#51 [V1] len=6: b'266666' #5a [V2] len=6: b'266666' torvalds#63 [V3] len=6: b'2000 ' #6c [V4] len=2: b'1 ' torvalds#71 [V5] len=6: b'c2 ' #7a [V6] len=6: b'0 ' torvalds#83 [V7] len=2: b'1 ' torvalds#88 [V8] len=2: b'0 ' #8d [V9] len=2: b'0 ' torvalds#92 [VA] len=2: b'0 ' torvalds#97 [RV] len=80: b's\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'... 0d00 Large item 252 bytes; name 0x11 #00 [VC] len=16: b'122310_1222 dp ' torvalds#13 [VD] len=16: b'610-0001-00 H1\x00\x00' torvalds#26 [VE] len=16: b'122310_1353 fp ' torvalds#39 [VF] len=16: b'610-0001-00 H1\x00\x00' #4c [RW] len=173: b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'... 0dff Small item 0 bytes; name 0xf End Tag Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Oct 24, 2016
There is at least one Chelsio 10Gb card which uses VPD area to store some custom blocks (example below). However pci_vpd_size() returns the length of the first block only assuming that there can be only one VPD "End Tag" and VFIO blocks access beyond that offset (since 4e1a635) which leads to the situation when the guest "cxgb3" driver fails to probe the device. The host system does not have this problem as the drives accesses the config space directly without pci_read_vpd()/... This adds a quirk to override the VPD size to a bigger value. The maximum size is taken from EEPROMSIZE in drivers/net/ethernet/chelsio/cxgb3/common.h. We do not read the tag as the cxgb3 driver does as the driver supports writing to EEPROM/VPD and when it writes, it only checks for 8192 bytes boundary. The quirk is registerted for all devices supported by the cxgb3 driver. This adds a quirk to the PCI layer (not to the cxgb3 driver) as the cxgb3 driver itself accesses VPD directly and the problem only exists with the vfio-pci driver (when cxgb3 is not running on the host and may not be even loaded) which blocks accesses beyond the first block of VPD data. However vfio-pci itself does not have quirks mechanism so we add it to PCI. This is the controller: Ethernet controller [0200]: Chelsio Communications Inc T310 10GbE Single Port Adapter [1425:0030] This is what I parsed from its vpd: === b'\x82*\x0010 Gigabit Ethernet-SR PCI Express Adapter\x90J\x00EC\x07D76809 FN\x0746K' 0000 Large item 42 bytes; name 0x2 Identifier String b'10 Gigabit Ethernet-SR PCI Express Adapter' 002d Large item 74 bytes; name 0x10 #00 [EC] len=7: b'D76809 ' #0a [FN] len=7: b'46K7897' torvalds#14 [PN] len=7: b'46K7897' #1e [MN] len=4: b'1037' torvalds#25 [FC] len=4: b'5769' #2c [SN] len=12: b'YL102035603V' #3b [NA] len=12: b'00145E992ED1' 007a Small item 1 bytes; name 0xf End Tag 0c00 Large item 16 bytes; name 0x2 Identifier String b'S310E-SR-X ' 0c13 Large item 234 bytes; name 0x10 #00 [PN] len=16: b'TBD ' torvalds#13 [EC] len=16: b'110107730D2 ' torvalds#26 [SN] len=16: b'97YL102035603V ' torvalds#39 [NA] len=12: b'00145E992ED1' torvalds#48 [V0] len=6: b'175000' torvalds#51 [V1] len=6: b'266666' #5a [V2] len=6: b'266666' torvalds#63 [V3] len=6: b'2000 ' #6c [V4] len=2: b'1 ' torvalds#71 [V5] len=6: b'c2 ' #7a [V6] len=6: b'0 ' torvalds#83 [V7] len=2: b'1 ' torvalds#88 [V8] len=2: b'0 ' #8d [V9] len=2: b'0 ' torvalds#92 [VA] len=2: b'0 ' torvalds#97 [RV] len=80: b's\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'... 0d00 Large item 252 bytes; name 0x11 #00 [VC] len=16: b'122310_1222 dp ' torvalds#13 [VD] len=16: b'610-0001-00 H1\x00\x00' torvalds#26 [VE] len=16: b'122310_1353 fp ' torvalds#39 [VF] len=16: b'610-0001-00 H1\x00\x00' #4c [RW] len=173: b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'... 0dff Small item 0 bytes; name 0xf End Tag 10f3 Large item 13315 bytes; name 0x62 !!! unknown item name 98: b'\xd0\x03\x00@`\x0c\x08\x00\x00\x00\x00\x00\x00\x00\x00\x00' === Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Dec 8, 2016
There is at least one Chelsio 10Gb card which uses VPD area to store some non-standard blocks (example below). However pci_vpd_size() returns the length of the first block only assuming that there can be only one VPD "End Tag". Since 4e1a635 ("vfio/pci: Use kernel VPD access functions"), VFIO blocks access beyond that offset, which prevents the guest "cxgb3" driver from probing the device. The host system does not have this problem as its driver accesses the config space directly without pci_read_vpd(). Add a quirk to override the VPD size to a bigger value. The maximum size is taken from EEPROMSIZE in drivers/net/ethernet/chelsio/cxgb3/common.h. We do not read the tag as the cxgb3 driver does as the driver supports writing to EEPROM/VPD and when it writes, it only checks for 8192 bytes boundary. The quirk is registered for all devices supported by the cxgb3 driver. This adds a quirk to the PCI layer (not to the cxgb3 driver) as the cxgb3 driver itself accesses VPD directly and the problem only exists with the vfio-pci driver (when cxgb3 is not running on the host and may not be even loaded) which blocks accesses beyond the first block of VPD data. However vfio-pci itself does not have quirks mechanism so we add it to PCI. This is the controller: Ethernet controller [0200]: Chelsio Communications Inc T310 10GbE Single Port Adapter [1425:0030] This is what I parsed from its VPD: === b'\x82*\x0010 Gigabit Ethernet-SR PCI Express Adapter\x90J\x00EC\x07D76809 FN\x0746K' 0000 Large item 42 bytes; name 0x2 Identifier String b'10 Gigabit Ethernet-SR PCI Express Adapter' 002d Large item 74 bytes; name 0x10 #00 [EC] len=7: b'D76809 ' #0a [FN] len=7: b'46K7897' torvalds#14 [PN] len=7: b'46K7897' #1e [MN] len=4: b'1037' torvalds#25 [FC] len=4: b'5769' #2c [SN] len=12: b'YL102035603V' #3b [NA] len=12: b'00145E992ED1' 007a Small item 1 bytes; name 0xf End Tag 0c00 Large item 16 bytes; name 0x2 Identifier String b'S310E-SR-X ' 0c13 Large item 234 bytes; name 0x10 #00 [PN] len=16: b'TBD ' torvalds#13 [EC] len=16: b'110107730D2 ' torvalds#26 [SN] len=16: b'97YL102035603V ' torvalds#39 [NA] len=12: b'00145E992ED1' torvalds#48 [V0] len=6: b'175000' torvalds#51 [V1] len=6: b'266666' #5a [V2] len=6: b'266666' torvalds#63 [V3] len=6: b'2000 ' #6c [V4] len=2: b'1 ' torvalds#71 [V5] len=6: b'c2 ' #7a [V6] len=6: b'0 ' torvalds#83 [V7] len=2: b'1 ' torvalds#88 [V8] len=2: b'0 ' #8d [V9] len=2: b'0 ' torvalds#92 [VA] len=2: b'0 ' torvalds#97 [RV] len=80: b's\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'... 0d00 Large item 252 bytes; name 0x11 #00 [VC] len=16: b'122310_1222 dp ' torvalds#13 [VD] len=16: b'610-0001-00 H1\x00\x00' torvalds#26 [VE] len=16: b'122310_1353 fp ' torvalds#39 [VF] len=16: b'610-0001-00 H1\x00\x00' #4c [RW] len=173: b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'... 0dff Small item 0 bytes; name 0xf End Tag 10f3 Large item 13315 bytes; name 0x62 !!! unknown item name 98: b'\xd0\x03\x00@`\x0c\x08\x00\x00\x00\x00\x00\x00\x00\x00\x00' === Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Dec 12, 2016
There is at least one Chelsio 10Gb card which uses VPD area to store some non-standard blocks (example below). However pci_vpd_size() returns the length of the first block only assuming that there can be only one VPD "End Tag". Since 4e1a635 ("vfio/pci: Use kernel VPD access functions"), VFIO blocks access beyond that offset, which prevents the guest "cxgb3" driver from probing the device. The host system does not have this problem as its driver accesses the config space directly without pci_read_vpd(). Add a quirk to override the VPD size to a bigger value. The maximum size is taken from EEPROMSIZE in drivers/net/ethernet/chelsio/cxgb3/common.h. We do not read the tag as the cxgb3 driver does as the driver supports writing to EEPROM/VPD and when it writes, it only checks for 8192 bytes boundary. The quirk is registered for all devices supported by the cxgb3 driver. This adds a quirk to the PCI layer (not to the cxgb3 driver) as the cxgb3 driver itself accesses VPD directly and the problem only exists with the vfio-pci driver (when cxgb3 is not running on the host and may not be even loaded) which blocks accesses beyond the first block of VPD data. However vfio-pci itself does not have quirks mechanism so we add it to PCI. This is the controller: Ethernet controller [0200]: Chelsio Communications Inc T310 10GbE Single Port Adapter [1425:0030] This is what I parsed from its VPD: === b'\x82*\x0010 Gigabit Ethernet-SR PCI Express Adapter\x90J\x00EC\x07D76809 FN\x0746K' 0000 Large item 42 bytes; name 0x2 Identifier String b'10 Gigabit Ethernet-SR PCI Express Adapter' 002d Large item 74 bytes; name 0x10 #00 [EC] len=7: b'D76809 ' #0a [FN] len=7: b'46K7897' torvalds#14 [PN] len=7: b'46K7897' #1e [MN] len=4: b'1037' torvalds#25 [FC] len=4: b'5769' #2c [SN] len=12: b'YL102035603V' #3b [NA] len=12: b'00145E992ED1' 007a Small item 1 bytes; name 0xf End Tag 0c00 Large item 16 bytes; name 0x2 Identifier String b'S310E-SR-X ' 0c13 Large item 234 bytes; name 0x10 #00 [PN] len=16: b'TBD ' torvalds#13 [EC] len=16: b'110107730D2 ' torvalds#26 [SN] len=16: b'97YL102035603V ' torvalds#39 [NA] len=12: b'00145E992ED1' torvalds#48 [V0] len=6: b'175000' torvalds#51 [V1] len=6: b'266666' #5a [V2] len=6: b'266666' torvalds#63 [V3] len=6: b'2000 ' #6c [V4] len=2: b'1 ' torvalds#71 [V5] len=6: b'c2 ' #7a [V6] len=6: b'0 ' torvalds#83 [V7] len=2: b'1 ' torvalds#88 [V8] len=2: b'0 ' #8d [V9] len=2: b'0 ' torvalds#92 [VA] len=2: b'0 ' torvalds#97 [RV] len=80: b's\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'... 0d00 Large item 252 bytes; name 0x11 #00 [VC] len=16: b'122310_1222 dp ' torvalds#13 [VD] len=16: b'610-0001-00 H1\x00\x00' torvalds#26 [VE] len=16: b'122310_1353 fp ' torvalds#39 [VF] len=16: b'610-0001-00 H1\x00\x00' #4c [RW] len=173: b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'... 0dff Small item 0 bytes; name 0xf End Tag 10f3 Large item 13315 bytes; name 0x62 !!! unknown item name 98: b'\xd0\x03\x00@`\x0c\x08\x00\x00\x00\x00\x00\x00\x00\x00\x00' === Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jun 1, 2017
split __bpf_prog_run() interpreter into stack allocation and execution parts. The code section shrinks which helps interpreter performance in some cases. text data bss dec hex filename 26350 10328 624 37302 91b6 kernel/bpf/core.o.before 25777 10328 624 36729 8f79 kernel/bpf/core.o.after Very short programs got slower (due to extra function call): Before: test_bpf: torvalds#89 ALU64_ADD_K: 1 + 2 = 3 jited:0 7 PASS test_bpf: torvalds#90 ALU64_ADD_K: 3 + 0 = 3 jited:0 8 PASS test_bpf: torvalds#91 ALU64_ADD_K: 1 + 2147483646 = 2147483647 jited:0 7 PASS test_bpf: torvalds#92 ALU64_ADD_K: 4294967294 + 2 = 4294967296 jited:0 11 PASS test_bpf: torvalds#93 ALU64_ADD_K: 2147483646 + -2147483647 = -1 jited:0 7 PASS After: test_bpf: torvalds#89 ALU64_ADD_K: 1 + 2 = 3 jited:0 11 PASS test_bpf: torvalds#90 ALU64_ADD_K: 3 + 0 = 3 jited:0 11 PASS test_bpf: torvalds#91 ALU64_ADD_K: 1 + 2147483646 = 2147483647 jited:0 11 PASS test_bpf: torvalds#92 ALU64_ADD_K: 4294967294 + 2 = 4294967296 jited:0 14 PASS test_bpf: torvalds#93 ALU64_ADD_K: 2147483646 + -2147483647 = -1 jited:0 10 PASS Longer programs got faster: Before: test_bpf: torvalds#266 BPF_MAXINSNS: Ctx heavy transformations jited:0 20286 20513 PASS test_bpf: torvalds#267 BPF_MAXINSNS: Call heavy transformations jited:0 31853 31768 PASS test_bpf: torvalds#268 BPF_MAXINSNS: Jump heavy test jited:0 9815 PASS test_bpf: torvalds#269 BPF_MAXINSNS: Very long jump backwards jited:0 6 PASS test_bpf: torvalds#270 BPF_MAXINSNS: Edge hopping nuthouse jited:0 13959 PASS test_bpf: torvalds#271 BPF_MAXINSNS: Jump, gap, jump, ... jited:0 210 PASS test_bpf: torvalds#272 BPF_MAXINSNS: ld_abs+get_processor_id jited:0 21724 PASS test_bpf: torvalds#273 BPF_MAXINSNS: ld_abs+vlan_push/pop jited:0 19118 PASS After: test_bpf: torvalds#266 BPF_MAXINSNS: Ctx heavy transformations jited:0 19008 18827 PASS test_bpf: torvalds#267 BPF_MAXINSNS: Call heavy transformations jited:0 29238 28450 PASS test_bpf: torvalds#268 BPF_MAXINSNS: Jump heavy test jited:0 9485 PASS test_bpf: torvalds#269 BPF_MAXINSNS: Very long jump backwards jited:0 12 PASS test_bpf: torvalds#270 BPF_MAXINSNS: Edge hopping nuthouse jited:0 13257 PASS test_bpf: torvalds#271 BPF_MAXINSNS: Jump, gap, jump, ... jited:0 213 PASS test_bpf: torvalds#272 BPF_MAXINSNS: ld_abs+get_processor_id jited:0 19389 PASS test_bpf: torvalds#273 BPF_MAXINSNS: ld_abs+vlan_push/pop jited:0 19583 PASS For real world production programs the difference is noise. This patch is first step towards reducing interpreter stack consumption. Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: David S. Miller <davem@davemloft.net>
iaguis
pushed a commit
to kinvolk/linux
that referenced
this pull request
Feb 6, 2018
Rebase patches onto 4.12.14
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jan 14, 2019
Currently, this will hit a BUG_ON for these symlinks as follows: - kernel message ------------[ cut here ]------------ kernel BUG at drivers/staging/erofs/xattr.c:59! SMP PTI CPU: 1 PID: 1170 Comm: getllxattr Not tainted 4.20.0-rc6+ torvalds#92 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-2.fc27 04/01/2014 RIP: 0010:init_inode_xattrs+0x22b/0x270 Code: 48 0f 45 ea f0 ff 4d 34 74 0d 41 83 4c 24 e0 01 31 c0 e9 00 fe ff ff 48 89 ef e8 e0 31 9e ff eb e9 89 e8 e9 ef fd ff ff 0f 0$ <0f> 0b 48 89 ef e8 fb f6 9c ff 48 8b 45 08 a8 01 75 24 f0 ff 4d 34 RSP: 0018:ffffa03ac026bdf8 EFLAGS: 00010246 ------------[ cut here ]------------ ... Call Trace: erofs_listxattr+0x30/0x2c0 ? selinux_inode_listxattr+0x5a/0x80 ? kmem_cache_alloc+0x33/0x170 ? security_inode_listxattr+0x27/0x40 listxattr+0xaf/0xc0 path_listxattr+0x5a/0xa0 do_syscall_64+0x43/0xf0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 ... ---[ end trace 3c24b49408dc0c72 ]--- Fix it by checking ->xattr_isize in init_inode_xattrs(), and it also fixes improper return value -ENOTSUPP (it should be -ENODATA if xattr is enabled) for those inodes. Fixes: b17500a ("staging: erofs: introduce xattr & acl support") Cc: <stable@vger.kernel.org> # 4.19+ Reported-by: Li Guifu <bluce.liguifu@huawei.com> Tested-by: Li Guifu <bluce.liguifu@huawei.com> Reviewed-by: Chao Yu <yuchao0@huawei.com> Signed-off-by: Gao Xiang <gaoxiang25@huawei.com>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jan 16, 2019
Currently, this will hit a BUG_ON for these symlinks as follows: - kernel message ------------[ cut here ]------------ kernel BUG at drivers/staging/erofs/xattr.c:59! SMP PTI CPU: 1 PID: 1170 Comm: getllxattr Not tainted 4.20.0-rc6+ torvalds#92 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-2.fc27 04/01/2014 RIP: 0010:init_inode_xattrs+0x22b/0x270 Code: 48 0f 45 ea f0 ff 4d 34 74 0d 41 83 4c 24 e0 01 31 c0 e9 00 fe ff ff 48 89 ef e8 e0 31 9e ff eb e9 89 e8 e9 ef fd ff ff 0f 0$ <0f> 0b 48 89 ef e8 fb f6 9c ff 48 8b 45 08 a8 01 75 24 f0 ff 4d 34 RSP: 0018:ffffa03ac026bdf8 EFLAGS: 00010246 ------------[ cut here ]------------ ... Call Trace: erofs_listxattr+0x30/0x2c0 ? selinux_inode_listxattr+0x5a/0x80 ? kmem_cache_alloc+0x33/0x170 ? security_inode_listxattr+0x27/0x40 listxattr+0xaf/0xc0 path_listxattr+0x5a/0xa0 do_syscall_64+0x43/0xf0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 ... ---[ end trace 3c24b49408dc0c72 ]--- Fix it by checking ->xattr_isize in init_inode_xattrs(), and it also fixes improper return value -ENOTSUPP (it should be -ENODATA if xattr is enabled) for those inodes. Fixes: b17500a ("staging: erofs: introduce xattr & acl support") Cc: <stable@vger.kernel.org> # 4.19+ Reported-by: Li Guifu <bluce.liguifu@huawei.com> Tested-by: Li Guifu <bluce.liguifu@huawei.com> Reviewed-by: Chao Yu <yuchao0@huawei.com> Signed-off-by: Gao Xiang <gaoxiang25@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
frno7
pushed a commit
to frno7/linux
that referenced
this pull request
Mar 10, 2019
commit 7077fff upstream. Currently, this will hit a BUG_ON for these symlinks as follows: - kernel message ------------[ cut here ]------------ kernel BUG at drivers/staging/erofs/xattr.c:59! SMP PTI CPU: 1 PID: 1170 Comm: getllxattr Not tainted 4.20.0-rc6+ torvalds#92 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-2.fc27 04/01/2014 RIP: 0010:init_inode_xattrs+0x22b/0x270 Code: 48 0f 45 ea f0 ff 4d 34 74 0d 41 83 4c 24 e0 01 31 c0 e9 00 fe ff ff 48 89 ef e8 e0 31 9e ff eb e9 89 e8 e9 ef fd ff ff 0f 0$ <0f> 0b 48 89 ef e8 fb f6 9c ff 48 8b 45 08 a8 01 75 24 f0 ff 4d 34 RSP: 0018:ffffa03ac026bdf8 EFLAGS: 00010246 ------------[ cut here ]------------ ... Call Trace: erofs_listxattr+0x30/0x2c0 ? selinux_inode_listxattr+0x5a/0x80 ? kmem_cache_alloc+0x33/0x170 ? security_inode_listxattr+0x27/0x40 listxattr+0xaf/0xc0 path_listxattr+0x5a/0xa0 do_syscall_64+0x43/0xf0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 ... ---[ end trace 3c24b49408dc0c72 ]--- Fix it by checking ->xattr_isize in init_inode_xattrs(), and it also fixes improper return value -ENOTSUPP (it should be -ENODATA if xattr is enabled) for those inodes. Fixes: b17500a ("staging: erofs: introduce xattr & acl support") Cc: <stable@vger.kernel.org> # 4.19+ Reported-by: Li Guifu <bluce.liguifu@huawei.com> Tested-by: Li Guifu <bluce.liguifu@huawei.com> Reviewed-by: Chao Yu <yuchao0@huawei.com> Signed-off-by: Gao Xiang <gaoxiang25@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
angelsl
pushed a commit
to angelsl/linux
that referenced
this pull request
Mar 18, 2019
commit 7077fff upstream. Currently, this will hit a BUG_ON for these symlinks as follows: - kernel message ------------[ cut here ]------------ kernel BUG at drivers/staging/erofs/xattr.c:59! SMP PTI CPU: 1 PID: 1170 Comm: getllxattr Not tainted 4.20.0-rc6+ torvalds#92 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-2.fc27 04/01/2014 RIP: 0010:init_inode_xattrs+0x22b/0x270 Code: 48 0f 45 ea f0 ff 4d 34 74 0d 41 83 4c 24 e0 01 31 c0 e9 00 fe ff ff 48 89 ef e8 e0 31 9e ff eb e9 89 e8 e9 ef fd ff ff 0f 0$ <0f> 0b 48 89 ef e8 fb f6 9c ff 48 8b 45 08 a8 01 75 24 f0 ff 4d 34 RSP: 0018:ffffa03ac026bdf8 EFLAGS: 00010246 ------------[ cut here ]------------ ... Call Trace: erofs_listxattr+0x30/0x2c0 ? selinux_inode_listxattr+0x5a/0x80 ? kmem_cache_alloc+0x33/0x170 ? security_inode_listxattr+0x27/0x40 listxattr+0xaf/0xc0 path_listxattr+0x5a/0xa0 do_syscall_64+0x43/0xf0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 ... ---[ end trace 3c24b49408dc0c72 ]--- Fix it by checking ->xattr_isize in init_inode_xattrs(), and it also fixes improper return value -ENOTSUPP (it should be -ENODATA if xattr is enabled) for those inodes. Fixes: b17500a ("staging: erofs: introduce xattr & acl support") Cc: <stable@vger.kernel.org> # 4.19+ Reported-by: Li Guifu <bluce.liguifu@huawei.com> Tested-by: Li Guifu <bluce.liguifu@huawei.com> Reviewed-by: Chao Yu <yuchao0@huawei.com> Signed-off-by: Gao Xiang <gaoxiang25@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
shenki
pushed a commit
to shenki/linux
that referenced
this pull request
Mar 18, 2019
commit 7077fff upstream. Currently, this will hit a BUG_ON for these symlinks as follows: - kernel message ------------[ cut here ]------------ kernel BUG at drivers/staging/erofs/xattr.c:59! SMP PTI CPU: 1 PID: 1170 Comm: getllxattr Not tainted 4.20.0-rc6+ torvalds#92 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-2.fc27 04/01/2014 RIP: 0010:init_inode_xattrs+0x22b/0x270 Code: 48 0f 45 ea f0 ff 4d 34 74 0d 41 83 4c 24 e0 01 31 c0 e9 00 fe ff ff 48 89 ef e8 e0 31 9e ff eb e9 89 e8 e9 ef fd ff ff 0f 0$ <0f> 0b 48 89 ef e8 fb f6 9c ff 48 8b 45 08 a8 01 75 24 f0 ff 4d 34 RSP: 0018:ffffa03ac026bdf8 EFLAGS: 00010246 ------------[ cut here ]------------ ... Call Trace: erofs_listxattr+0x30/0x2c0 ? selinux_inode_listxattr+0x5a/0x80 ? kmem_cache_alloc+0x33/0x170 ? security_inode_listxattr+0x27/0x40 listxattr+0xaf/0xc0 path_listxattr+0x5a/0xa0 do_syscall_64+0x43/0xf0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 ... ---[ end trace 3c24b49408dc0c72 ]--- Fix it by checking ->xattr_isize in init_inode_xattrs(), and it also fixes improper return value -ENOTSUPP (it should be -ENODATA if xattr is enabled) for those inodes. Fixes: b17500a ("staging: erofs: introduce xattr & acl support") Cc: <stable@vger.kernel.org> # 4.19+ Reported-by: Li Guifu <bluce.liguifu@huawei.com> Tested-by: Li Guifu <bluce.liguifu@huawei.com> Reviewed-by: Chao Yu <yuchao0@huawei.com> Signed-off-by: Gao Xiang <gaoxiang25@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
jackpot51
referenced
this pull request
in pop-os/linux
May 3, 2019
BugLink: https://bugs.launchpad.net/bugs/1819515 commit 7077fff upstream. Currently, this will hit a BUG_ON for these symlinks as follows: - kernel message ------------[ cut here ]------------ kernel BUG at drivers/staging/erofs/xattr.c:59! SMP PTI CPU: 1 PID: 1170 Comm: getllxattr Not tainted 4.20.0-rc6+ #92 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-2.fc27 04/01/2014 RIP: 0010:init_inode_xattrs+0x22b/0x270 Code: 48 0f 45 ea f0 ff 4d 34 74 0d 41 83 4c 24 e0 01 31 c0 e9 00 fe ff ff 48 89 ef e8 e0 31 9e ff eb e9 89 e8 e9 ef fd ff ff 0f 0$ <0f> 0b 48 89 ef e8 fb f6 9c ff 48 8b 45 08 a8 01 75 24 f0 ff 4d 34 RSP: 0018:ffffa03ac026bdf8 EFLAGS: 00010246 ------------[ cut here ]------------ ... Call Trace: erofs_listxattr+0x30/0x2c0 ? selinux_inode_listxattr+0x5a/0x80 ? kmem_cache_alloc+0x33/0x170 ? security_inode_listxattr+0x27/0x40 listxattr+0xaf/0xc0 path_listxattr+0x5a/0xa0 do_syscall_64+0x43/0xf0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 ... ---[ end trace 3c24b49408dc0c72 ]--- Fix it by checking ->xattr_isize in init_inode_xattrs(), and it also fixes improper return value -ENOTSUPP (it should be -ENODATA if xattr is enabled) for those inodes. Fixes: b17500a ("staging: erofs: introduce xattr & acl support") Cc: <stable@vger.kernel.org> # 4.19+ Reported-by: Li Guifu <bluce.liguifu@huawei.com> Tested-by: Li Guifu <bluce.liguifu@huawei.com> Reviewed-by: Chao Yu <yuchao0@huawei.com> Signed-off-by: Gao Xiang <gaoxiang25@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Aug 31, 2019
…ing driver fails If a gadget driver is in the pending drivers list, a UDC becomes available and udc_bind_to_driver() fails, then it gets deleted from the pending list. i.e. list_del(&driver->pending) in check_pending_gadget_drivers(). Then if that gadget driver is unregistered, usb_gadget_unregister_driver() does a list_del(&driver->pending) again thus causing a page fault as that list entry has been poisoned by the previous list_del(). Fix this by using list_del_init() instead of list_del() in check_pending_gadget_drivers(). Test case: - Make sure no UDC is available - modprobe g_mass_storage file=wrongfile - Load UDC driver so it becomes available lun0: unable to open backing file: wrongfile - modprobe -r g_mass_storage [ 60.900431] Unable to handle kernel paging request at virtual address dead000000000108 [ 60.908346] Mem abort info: [ 60.911145] ESR = 0x96000044 [ 60.914227] Exception class = DABT (current EL), IL = 32 bits [ 60.920162] SET = 0, FnV = 0 [ 60.923217] EA = 0, S1PTW = 0 [ 60.926354] Data abort info: [ 60.929228] ISV = 0, ISS = 0x00000044 [ 60.933058] CM = 0, WnR = 1 [ 60.936011] [dead000000000108] address between user and kernel address ranges [ 60.943136] Internal error: Oops: 96000044 [#1] PREEMPT SMP [ 60.948691] Modules linked in: g_mass_storage(-) usb_f_mass_storage libcomposite xhci_plat_hcd xhci_hcd usbcore ti_am335x_adc kfifo_buf omap_rng cdns3 rng_core udc_core crc32_ce xfrm_user crct10dif_ce snd_so6 [ 60.993995] Process modprobe (pid: 834, stack limit = 0x00000000c2aebc69) [ 61.000765] CPU: 0 PID: 834 Comm: modprobe Not tainted 4.19.59-01963-g065f42a60499 torvalds#92 [ 61.008658] Hardware name: Texas Instruments SoC (DT) [ 61.014472] pstate: 60000005 (nZCv daif -PAN -UAO) [ 61.019253] pc : usb_gadget_unregister_driver+0x7c/0x108 [udc_core] [ 61.025503] lr : usb_gadget_unregister_driver+0x30/0x108 [udc_core] [ 61.031750] sp : ffff00001338fda0 [ 61.035049] x29: ffff00001338fda0 x28: ffff800846d40000 [ 61.040346] x27: 0000000000000000 x26: 0000000000000000 [ 61.045642] x25: 0000000056000000 x24: 0000000000000800 [ 61.050938] x23: ffff000008d7b0d0 x22: ffff0000088b07c8 [ 61.056234] x21: ffff000001100000 x20: ffff000002020260 [ 61.061530] x19: ffff0000010ffd28 x18: 0000000000000000 [ 61.066825] x17: 0000000000000000 x16: 0000000000000000 [ 61.072121] x15: 0000000000000000 x14: 0000000000000000 [ 61.077417] x13: ffff000000000000 x12: ffffffffffffffff [ 61.082712] x11: 0000000000000030 x10: 7f7f7f7f7f7f7f7f [ 61.088008] x9 : fefefefefefefeff x8 : 0000000000000000 [ 61.093304] x7 : ffffffffffffffff x6 : 000000000000ffff [ 61.098599] x5 : 8080000000000000 x4 : 0000000000000000 [ 61.103895] x3 : ffff000001100020 x2 : ffff800846d40000 [ 61.109190] x1 : dead000000000100 x0 : dead000000000200 [ 61.114486] Call trace: [ 61.116922] usb_gadget_unregister_driver+0x7c/0x108 [udc_core] [ 61.122828] usb_composite_unregister+0x10/0x18 [libcomposite] [ 61.128643] msg_cleanup+0x18/0xfce0 [g_mass_storage] [ 61.133682] __arm64_sys_delete_module+0x17c/0x1f0 [ 61.138458] el0_svc_common+0x90/0x158 [ 61.142192] el0_svc_handler+0x2c/0x80 [ 61.145926] el0_svc+0x8/0xc [ 61.148794] Code: eb03003f d10be033 54ffff21 a94d0281 (f9000420) [ 61.154869] ---[ end trace afb22e9b637bd9a7 ]--- Segmentation fault Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Noltari
pushed a commit
to Noltari/linux
that referenced
this pull request
Nov 10, 2019
…ing driver fails commit 163be6f upstream. If a gadget driver is in the pending drivers list, a UDC becomes available and udc_bind_to_driver() fails, then it gets deleted from the pending list. i.e. list_del(&driver->pending) in check_pending_gadget_drivers(). Then if that gadget driver is unregistered, usb_gadget_unregister_driver() does a list_del(&driver->pending) again thus causing a page fault as that list entry has been poisoned by the previous list_del(). Fix this by using list_del_init() instead of list_del() in check_pending_gadget_drivers(). Test case: - Make sure no UDC is available - modprobe g_mass_storage file=wrongfile - Load UDC driver so it becomes available lun0: unable to open backing file: wrongfile - modprobe -r g_mass_storage [ 60.900431] Unable to handle kernel paging request at virtual address dead000000000108 [ 60.908346] Mem abort info: [ 60.911145] ESR = 0x96000044 [ 60.914227] Exception class = DABT (current EL), IL = 32 bits [ 60.920162] SET = 0, FnV = 0 [ 60.923217] EA = 0, S1PTW = 0 [ 60.926354] Data abort info: [ 60.929228] ISV = 0, ISS = 0x00000044 [ 60.933058] CM = 0, WnR = 1 [ 60.936011] [dead000000000108] address between user and kernel address ranges [ 60.943136] Internal error: Oops: 96000044 [#1] PREEMPT SMP [ 60.948691] Modules linked in: g_mass_storage(-) usb_f_mass_storage libcomposite xhci_plat_hcd xhci_hcd usbcore ti_am335x_adc kfifo_buf omap_rng cdns3 rng_core udc_core crc32_ce xfrm_user crct10dif_ce snd_so6 [ 60.993995] Process modprobe (pid: 834, stack limit = 0x00000000c2aebc69) [ 61.000765] CPU: 0 PID: 834 Comm: modprobe Not tainted 4.19.59-01963-g065f42a60499 torvalds#92 [ 61.008658] Hardware name: Texas Instruments SoC (DT) [ 61.014472] pstate: 60000005 (nZCv daif -PAN -UAO) [ 61.019253] pc : usb_gadget_unregister_driver+0x7c/0x108 [udc_core] [ 61.025503] lr : usb_gadget_unregister_driver+0x30/0x108 [udc_core] [ 61.031750] sp : ffff00001338fda0 [ 61.035049] x29: ffff00001338fda0 x28: ffff800846d40000 [ 61.040346] x27: 0000000000000000 x26: 0000000000000000 [ 61.045642] x25: 0000000056000000 x24: 0000000000000800 [ 61.050938] x23: ffff000008d7b0d0 x22: ffff0000088b07c8 [ 61.056234] x21: ffff000001100000 x20: ffff000002020260 [ 61.061530] x19: ffff0000010ffd28 x18: 0000000000000000 [ 61.066825] x17: 0000000000000000 x16: 0000000000000000 [ 61.072121] x15: 0000000000000000 x14: 0000000000000000 [ 61.077417] x13: ffff000000000000 x12: ffffffffffffffff [ 61.082712] x11: 0000000000000030 x10: 7f7f7f7f7f7f7f7f [ 61.088008] x9 : fefefefefefefeff x8 : 0000000000000000 [ 61.093304] x7 : ffffffffffffffff x6 : 000000000000ffff [ 61.098599] x5 : 8080000000000000 x4 : 0000000000000000 [ 61.103895] x3 : ffff000001100020 x2 : ffff800846d40000 [ 61.109190] x1 : dead000000000100 x0 : dead000000000200 [ 61.114486] Call trace: [ 61.116922] usb_gadget_unregister_driver+0x7c/0x108 [udc_core] [ 61.122828] usb_composite_unregister+0x10/0x18 [libcomposite] [ 61.128643] msg_cleanup+0x18/0xfce0 [g_mass_storage] [ 61.133682] __arm64_sys_delete_module+0x17c/0x1f0 [ 61.138458] el0_svc_common+0x90/0x158 [ 61.142192] el0_svc_handler+0x2c/0x80 [ 61.145926] el0_svc+0x8/0xc [ 61.148794] Code: eb03003f d10be033 54ffff21 a94d0281 (f9000420) [ 61.154869] ---[ end trace afb22e9b637bd9a7 ]--- Segmentation fault Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
jason-mckinney
pushed a commit
to jason-mckinney/linux
that referenced
this pull request
Nov 11, 2019
…ing driver fails commit 163be6f upstream. If a gadget driver is in the pending drivers list, a UDC becomes available and udc_bind_to_driver() fails, then it gets deleted from the pending list. i.e. list_del(&driver->pending) in check_pending_gadget_drivers(). Then if that gadget driver is unregistered, usb_gadget_unregister_driver() does a list_del(&driver->pending) again thus causing a page fault as that list entry has been poisoned by the previous list_del(). Fix this by using list_del_init() instead of list_del() in check_pending_gadget_drivers(). Test case: - Make sure no UDC is available - modprobe g_mass_storage file=wrongfile - Load UDC driver so it becomes available lun0: unable to open backing file: wrongfile - modprobe -r g_mass_storage [ 60.900431] Unable to handle kernel paging request at virtual address dead000000000108 [ 60.908346] Mem abort info: [ 60.911145] ESR = 0x96000044 [ 60.914227] Exception class = DABT (current EL), IL = 32 bits [ 60.920162] SET = 0, FnV = 0 [ 60.923217] EA = 0, S1PTW = 0 [ 60.926354] Data abort info: [ 60.929228] ISV = 0, ISS = 0x00000044 [ 60.933058] CM = 0, WnR = 1 [ 60.936011] [dead000000000108] address between user and kernel address ranges [ 60.943136] Internal error: Oops: 96000044 [archlinux#1] PREEMPT SMP [ 60.948691] Modules linked in: g_mass_storage(-) usb_f_mass_storage libcomposite xhci_plat_hcd xhci_hcd usbcore ti_am335x_adc kfifo_buf omap_rng cdns3 rng_core udc_core crc32_ce xfrm_user crct10dif_ce snd_so6 [ 60.993995] Process modprobe (pid: 834, stack limit = 0x00000000c2aebc69) [ 61.000765] CPU: 0 PID: 834 Comm: modprobe Not tainted 4.19.59-01963-g065f42a60499 torvalds#92 [ 61.008658] Hardware name: Texas Instruments SoC (DT) [ 61.014472] pstate: 60000005 (nZCv daif -PAN -UAO) [ 61.019253] pc : usb_gadget_unregister_driver+0x7c/0x108 [udc_core] [ 61.025503] lr : usb_gadget_unregister_driver+0x30/0x108 [udc_core] [ 61.031750] sp : ffff00001338fda0 [ 61.035049] x29: ffff00001338fda0 x28: ffff800846d40000 [ 61.040346] x27: 0000000000000000 x26: 0000000000000000 [ 61.045642] x25: 0000000056000000 x24: 0000000000000800 [ 61.050938] x23: ffff000008d7b0d0 x22: ffff0000088b07c8 [ 61.056234] x21: ffff000001100000 x20: ffff000002020260 [ 61.061530] x19: ffff0000010ffd28 x18: 0000000000000000 [ 61.066825] x17: 0000000000000000 x16: 0000000000000000 [ 61.072121] x15: 0000000000000000 x14: 0000000000000000 [ 61.077417] x13: ffff000000000000 x12: ffffffffffffffff [ 61.082712] x11: 0000000000000030 x10: 7f7f7f7f7f7f7f7f [ 61.088008] x9 : fefefefefefefeff x8 : 0000000000000000 [ 61.093304] x7 : ffffffffffffffff x6 : 000000000000ffff [ 61.098599] x5 : 8080000000000000 x4 : 0000000000000000 [ 61.103895] x3 : ffff000001100020 x2 : ffff800846d40000 [ 61.109190] x1 : dead000000000100 x0 : dead000000000200 [ 61.114486] Call trace: [ 61.116922] usb_gadget_unregister_driver+0x7c/0x108 [udc_core] [ 61.122828] usb_composite_unregister+0x10/0x18 [libcomposite] [ 61.128643] msg_cleanup+0x18/0xfce0 [g_mass_storage] [ 61.133682] __arm64_sys_delete_module+0x17c/0x1f0 [ 61.138458] el0_svc_common+0x90/0x158 [ 61.142192] el0_svc_handler+0x2c/0x80 [ 61.145926] el0_svc+0x8/0xc [ 61.148794] Code: eb03003f d10be033 54ffff21 a94d0281 (f9000420) [ 61.154869] ---[ end trace afb22e9b637bd9a7 ]--- Segmentation fault Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
jackpot51
referenced
this pull request
in pop-os/linux
Dec 12, 2019
…ing driver fails BugLink: https://bugs.launchpad.net/bugs/1852111 commit 163be6f upstream. If a gadget driver is in the pending drivers list, a UDC becomes available and udc_bind_to_driver() fails, then it gets deleted from the pending list. i.e. list_del(&driver->pending) in check_pending_gadget_drivers(). Then if that gadget driver is unregistered, usb_gadget_unregister_driver() does a list_del(&driver->pending) again thus causing a page fault as that list entry has been poisoned by the previous list_del(). Fix this by using list_del_init() instead of list_del() in check_pending_gadget_drivers(). Test case: - Make sure no UDC is available - modprobe g_mass_storage file=wrongfile - Load UDC driver so it becomes available lun0: unable to open backing file: wrongfile - modprobe -r g_mass_storage [ 60.900431] Unable to handle kernel paging request at virtual address dead000000000108 [ 60.908346] Mem abort info: [ 60.911145] ESR = 0x96000044 [ 60.914227] Exception class = DABT (current EL), IL = 32 bits [ 60.920162] SET = 0, FnV = 0 [ 60.923217] EA = 0, S1PTW = 0 [ 60.926354] Data abort info: [ 60.929228] ISV = 0, ISS = 0x00000044 [ 60.933058] CM = 0, WnR = 1 [ 60.936011] [dead000000000108] address between user and kernel address ranges [ 60.943136] Internal error: Oops: 96000044 [#1] PREEMPT SMP [ 60.948691] Modules linked in: g_mass_storage(-) usb_f_mass_storage libcomposite xhci_plat_hcd xhci_hcd usbcore ti_am335x_adc kfifo_buf omap_rng cdns3 rng_core udc_core crc32_ce xfrm_user crct10dif_ce snd_so6 [ 60.993995] Process modprobe (pid: 834, stack limit = 0x00000000c2aebc69) [ 61.000765] CPU: 0 PID: 834 Comm: modprobe Not tainted 4.19.59-01963-g065f42a60499 #92 [ 61.008658] Hardware name: Texas Instruments SoC (DT) [ 61.014472] pstate: 60000005 (nZCv daif -PAN -UAO) [ 61.019253] pc : usb_gadget_unregister_driver+0x7c/0x108 [udc_core] [ 61.025503] lr : usb_gadget_unregister_driver+0x30/0x108 [udc_core] [ 61.031750] sp : ffff00001338fda0 [ 61.035049] x29: ffff00001338fda0 x28: ffff800846d40000 [ 61.040346] x27: 0000000000000000 x26: 0000000000000000 [ 61.045642] x25: 0000000056000000 x24: 0000000000000800 [ 61.050938] x23: ffff000008d7b0d0 x22: ffff0000088b07c8 [ 61.056234] x21: ffff000001100000 x20: ffff000002020260 [ 61.061530] x19: ffff0000010ffd28 x18: 0000000000000000 [ 61.066825] x17: 0000000000000000 x16: 0000000000000000 [ 61.072121] x15: 0000000000000000 x14: 0000000000000000 [ 61.077417] x13: ffff000000000000 x12: ffffffffffffffff [ 61.082712] x11: 0000000000000030 x10: 7f7f7f7f7f7f7f7f [ 61.088008] x9 : fefefefefefefeff x8 : 0000000000000000 [ 61.093304] x7 : ffffffffffffffff x6 : 000000000000ffff [ 61.098599] x5 : 8080000000000000 x4 : 0000000000000000 [ 61.103895] x3 : ffff000001100020 x2 : ffff800846d40000 [ 61.109190] x1 : dead000000000100 x0 : dead000000000200 [ 61.114486] Call trace: [ 61.116922] usb_gadget_unregister_driver+0x7c/0x108 [udc_core] [ 61.122828] usb_composite_unregister+0x10/0x18 [libcomposite] [ 61.128643] msg_cleanup+0x18/0xfce0 [g_mass_storage] [ 61.133682] __arm64_sys_delete_module+0x17c/0x1f0 [ 61.138458] el0_svc_common+0x90/0x158 [ 61.142192] el0_svc_handler+0x2c/0x80 [ 61.145926] el0_svc+0x8/0xc [ 61.148794] Code: eb03003f d10be033 54ffff21 a94d0281 (f9000420) [ 61.154869] ---[ end trace afb22e9b637bd9a7 ]--- Segmentation fault Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Connor Kuehl <connor.kuehl@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
ruscur
pushed a commit
to ruscur/linux
that referenced
this pull request
Apr 22, 2020
Cc: Borislav Petkov <bp@alien8.de> WARNING: 'adddress' may be misspelled - perhaps 'address'? torvalds#64: FILE: Documentation/admin-guide/kernel-parameters.txt:1717: + initrdmem= [KNL] Specify a physical adddress and size from which WARNING: please, no spaces at the start of a line torvalds#82: FILE: arch/x86/kernel/setup.c:240: + if (ramdisk_image == 0) {$ WARNING: braces {} are not necessary for single statement blocks torvalds#82: FILE: arch/x86/kernel/setup.c:240: + if (ramdisk_image == 0) { + ramdisk_image = phys_initrd_start; + } ERROR: code indent should use tabs where possible torvalds#83: FILE: arch/x86/kernel/setup.c:241: + ramdisk_image = phys_initrd_start;$ WARNING: please, no spaces at the start of a line torvalds#83: FILE: arch/x86/kernel/setup.c:241: + ramdisk_image = phys_initrd_start;$ WARNING: please, no spaces at the start of a line torvalds#84: FILE: arch/x86/kernel/setup.c:242: + }$ WARNING: please, no spaces at the start of a line torvalds#92: FILE: arch/x86/kernel/setup.c:251: + if (ramdisk_size == 0) {$ WARNING: braces {} are not necessary for single statement blocks torvalds#92: FILE: arch/x86/kernel/setup.c:251: + if (ramdisk_size == 0) { + ramdisk_size = phys_initrd_size; + } ERROR: code indent should use tabs where possible torvalds#93: FILE: arch/x86/kernel/setup.c:252: + ramdisk_size = phys_initrd_size;$ WARNING: please, no spaces at the start of a line torvalds#93: FILE: arch/x86/kernel/setup.c:252: + ramdisk_size = phys_initrd_size;$ WARNING: please, no spaces at the start of a line torvalds#94: FILE: arch/x86/kernel/setup.c:253: + }$ WARNING: please, no spaces at the start of a line torvalds#124: FILE: init/do_mounts_initrd.c:55: + return early_initrdmem(p);$ WARNING: Missing Signed-off-by: line by nominal patch author 'ron minnich <rminnich@gmail.com>' total: 2 errors, 11 warnings, 56 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. NOTE: Whitespace errors detected. You may wish to use scripts/cleanpatch or scripts/cleanfile ./patches/initrdmem=-option-to-specify-initrd-physical-address.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Borislav Petkov <bp@alien8.de> Cc: H. Peter Anvin (Intel) <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Matthew Garrett <mjg59@google.com> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Ronald G. Minnich <rminnich@gmail.com> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
ruscur
pushed a commit
to ruscur/linux
that referenced
this pull request
Apr 24, 2020
Cc: Borislav Petkov <bp@alien8.de> WARNING: 'adddress' may be misspelled - perhaps 'address'? torvalds#64: FILE: Documentation/admin-guide/kernel-parameters.txt:1717: + initrdmem= [KNL] Specify a physical adddress and size from which WARNING: please, no spaces at the start of a line torvalds#82: FILE: arch/x86/kernel/setup.c:240: + if (ramdisk_image == 0) {$ WARNING: braces {} are not necessary for single statement blocks torvalds#82: FILE: arch/x86/kernel/setup.c:240: + if (ramdisk_image == 0) { + ramdisk_image = phys_initrd_start; + } ERROR: code indent should use tabs where possible torvalds#83: FILE: arch/x86/kernel/setup.c:241: + ramdisk_image = phys_initrd_start;$ WARNING: please, no spaces at the start of a line torvalds#83: FILE: arch/x86/kernel/setup.c:241: + ramdisk_image = phys_initrd_start;$ WARNING: please, no spaces at the start of a line torvalds#84: FILE: arch/x86/kernel/setup.c:242: + }$ WARNING: please, no spaces at the start of a line torvalds#92: FILE: arch/x86/kernel/setup.c:251: + if (ramdisk_size == 0) {$ WARNING: braces {} are not necessary for single statement blocks torvalds#92: FILE: arch/x86/kernel/setup.c:251: + if (ramdisk_size == 0) { + ramdisk_size = phys_initrd_size; + } ERROR: code indent should use tabs where possible torvalds#93: FILE: arch/x86/kernel/setup.c:252: + ramdisk_size = phys_initrd_size;$ WARNING: please, no spaces at the start of a line torvalds#93: FILE: arch/x86/kernel/setup.c:252: + ramdisk_size = phys_initrd_size;$ WARNING: please, no spaces at the start of a line torvalds#94: FILE: arch/x86/kernel/setup.c:253: + }$ WARNING: please, no spaces at the start of a line torvalds#124: FILE: init/do_mounts_initrd.c:55: + return early_initrdmem(p);$ WARNING: Missing Signed-off-by: line by nominal patch author 'ron minnich <rminnich@gmail.com>' total: 2 errors, 11 warnings, 56 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. NOTE: Whitespace errors detected. You may wish to use scripts/cleanpatch or scripts/cleanfile ./patches/initrdmem=-option-to-specify-initrd-physical-address.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Borislav Petkov <bp@alien8.de> Cc: H. Peter Anvin (Intel) <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Matthew Garrett <mjg59@google.com> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Ronald G. Minnich <rminnich@gmail.com> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
May 10, 2020
The threaded interrupt handler may still be called after the usb_gadget_disconnect is called, it causes the structures used at interrupt handler was freed before it uses, eg the usb_request. This issue usually occurs we remove the udc function during the transfer. Below is the example when doing stress test for android switch function, the EP0's request is freed by .unbind (configfs_composite_unbind -> composite_dev_cleanup), but the threaded handler accesses this request during handling setup packet request. In fact, there is no protection between unbind the udc and udc interrupt handling, so we have to avoid the interrupt handler is occurred or scheduled during the .unbind flow. init: Sending signal 9 to service 'adbd' (pid 18077) process group... android_work: did not send uevent (0 0 000000007bec2039) libprocessgroup: Successfully killed process cgroup uid 0 pid 18077 in 6ms init: Service 'adbd' (pid 18077) received signal 9 init: Sending signal 9 to service 'adbd' (pid 18077) process group... libprocessgroup: Successfully killed process cgroup uid 0 pid 18077 in 0ms init: processing action (init.svc.adbd=stopped) from (/init.usb.configfs.rc:14) init: Received control message 'start' for 'adbd' from pid: 399 (/vendor/bin/hw/android.hardware.usb@1. init: starting service 'adbd'... read descriptors read strings Unable to handle kernel read from unreadable memory at virtual address 000000000000002a android_work: sent uevent USB_STATE=CONNECTED Mem abort info: ESR = 0x96000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000000e97f1000 using random self ethernet address [000000000000002a] pgd=0000000000000000 Internal error: Oops: 96000004 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 232 Comm: irq/68-5b110000 Not tainted 5.4.24-06075-g94a6b52b5815 torvalds#92 Hardware name: Freescale i.MX8QXP MEK (DT) pstate: 00400085 (nzcv daIf +PAN -UAO) using random host ethernet address pc : composite_setup+0x5c/0x1730 lr : android_setup+0xc0/0x148 sp : ffff80001349bba0 x29: ffff80001349bba0 x28: ffff00083a50da00 x27: ffff8000124e6000 x26: ffff800010177950 x25: 0000000000000040 x24: ffff000834e18010 x23: 0000000000000000 x22: 0000000000000000 x21: ffff00083a50da00 x20: ffff00082e75ec40 x19: 0000000000000000 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000001 x11: ffff80001180fb58 x10: 0000000000000040 x9 : ffff8000120fc980 x8 : 0000000000000000 x7 : ffff00083f98df50 x6 : 0000000000000100 x5 : 00000307e8978431 x4 : ffff800011386788 x3 : 0000000000000000 x2 : ffff800012342000 x1 : 0000000000000000 x0 : ffff800010c6d3a0 Call trace: composite_setup+0x5c/0x1730 android_setup+0xc0/0x148 cdns3_ep0_delegate_req+0x64/0x90 cdns3_check_ep0_interrupt_proceed+0x384/0x738 cdns3_device_thread_irq_handler+0x124/0x6e0 cdns3_thread_irq+0x94/0xa0 irq_thread_fn+0x30/0xa0 irq_thread+0x150/0x248 kthread+0xfc/0x128 ret_from_fork+0x10/0x18 Code: 910e8000 f9400693 12001ed7 79400f79 (3940aa61) ---[ end trace c685db37f8773fba ]--- Kernel panic - not syncing: Fatal exception SMP: stopping secondary CPUs Kernel Offset: disabled CPU features: 0x0002,20002008 Memory Limit: none Rebooting in 5 seconds.. Reviewed-by: Jun Li <jun.li@nxp.com> Signed-off-by: Peter Chen <peter.chen@nxp.com>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
May 20, 2020
The threaded interrupt handler may still be called after the usb_gadget_disconnect is called, it causes the structures used at interrupt handler was freed before it uses, eg the usb_request. This issue usually occurs we remove the udc function during the transfer. Below is the example when doing stress test for android switch function, the EP0's request is freed by .unbind (configfs_composite_unbind -> composite_dev_cleanup), but the threaded handler accesses this request during handling setup packet request. In fact, there is no protection between unbind the udc and udc interrupt handling, so we have to avoid the interrupt handler is occurred or scheduled during the .unbind flow. init: Sending signal 9 to service 'adbd' (pid 18077) process group... android_work: did not send uevent (0 0 000000007bec2039) libprocessgroup: Successfully killed process cgroup uid 0 pid 18077 in 6ms init: Service 'adbd' (pid 18077) received signal 9 init: Sending signal 9 to service 'adbd' (pid 18077) process group... libprocessgroup: Successfully killed process cgroup uid 0 pid 18077 in 0ms init: processing action (init.svc.adbd=stopped) from (/init.usb.configfs.rc:14) init: Received control message 'start' for 'adbd' from pid: 399 (/vendor/bin/hw/android.hardware.usb@1. init: starting service 'adbd'... read descriptors read strings Unable to handle kernel read from unreadable memory at virtual address 000000000000002a android_work: sent uevent USB_STATE=CONNECTED Mem abort info: ESR = 0x96000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000000e97f1000 using random self ethernet address [000000000000002a] pgd=0000000000000000 Internal error: Oops: 96000004 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 232 Comm: irq/68-5b110000 Not tainted 5.4.24-06075-g94a6b52b5815 torvalds#92 Hardware name: Freescale i.MX8QXP MEK (DT) pstate: 00400085 (nzcv daIf +PAN -UAO) using random host ethernet address pc : composite_setup+0x5c/0x1730 lr : android_setup+0xc0/0x148 sp : ffff80001349bba0 x29: ffff80001349bba0 x28: ffff00083a50da00 x27: ffff8000124e6000 x26: ffff800010177950 x25: 0000000000000040 x24: ffff000834e18010 x23: 0000000000000000 x22: 0000000000000000 x21: ffff00083a50da00 x20: ffff00082e75ec40 x19: 0000000000000000 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000001 x11: ffff80001180fb58 x10: 0000000000000040 x9 : ffff8000120fc980 x8 : 0000000000000000 x7 : ffff00083f98df50 x6 : 0000000000000100 x5 : 00000307e8978431 x4 : ffff800011386788 x3 : 0000000000000000 x2 : ffff800012342000 x1 : 0000000000000000 x0 : ffff800010c6d3a0 Call trace: composite_setup+0x5c/0x1730 android_setup+0xc0/0x148 cdns3_ep0_delegate_req+0x64/0x90 cdns3_check_ep0_interrupt_proceed+0x384/0x738 cdns3_device_thread_irq_handler+0x124/0x6e0 cdns3_thread_irq+0x94/0xa0 irq_thread_fn+0x30/0xa0 irq_thread+0x150/0x248 kthread+0xfc/0x128 ret_from_fork+0x10/0x18 Code: 910e8000 f9400693 12001ed7 79400f79 (3940aa61) ---[ end trace c685db37f8773fba ]--- Kernel panic - not syncing: Fatal exception SMP: stopping secondary CPUs Kernel Offset: disabled CPU features: 0x0002,20002008 Memory Limit: none Rebooting in 5 seconds.. Reviewed-by: Jun Li <jun.li@nxp.com> Signed-off-by: Peter Chen <peter.chen@nxp.com> Signed-off-by: Felipe Balbi <balbi@kernel.org>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Dec 1, 2022
BPF CI fails for arm64 and s390x each with the following result: [...] All error logs: serial_test_kprobe_multi_bench_attach:PASS:get_syms 0 nsec serial_test_kprobe_multi_bench_attach:PASS:kprobe_multi_empty__open_and_load 0 nsec libbpf: prog 'test_kprobe_empty': failed to attach: Operation not supported serial_test_kprobe_multi_bench_attach:FAIL:bpf_program__attach_kprobe_multi_opts unexpected error: -95 torvalds#92 kprobe_multi_bench_attach:FAIL [...] Add the test to the deny list. Fixes: 5b6c7e5 ("selftests/bpf: Add attach bench test") Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Feb 1, 2023
If we bring up secondaries in parallel they might get confused unless we impose some ordering here: [ 1.360149] x86: Booting SMP configuration: [ 1.360221] .... node #0, CPUs: #1 #2 #3 #4 #5 torvalds#6 torvalds#7 torvalds#8 torvalds#9 torvalds#10 torvalds#11 torvalds#12 torvalds#13 torvalds#14 torvalds#15 torvalds#16 torvalds#17 torvalds#18 torvalds#19 torvalds#20 torvalds#21 torvalds#22 torvalds#23 [ 1.366225] .... node #1, CPUs: torvalds#24 torvalds#25 torvalds#26 torvalds#27 torvalds#28 torvalds#29 torvalds#30 torvalds#31 torvalds#32 torvalds#33 torvalds#34 torvalds#35 torvalds#36 torvalds#37 torvalds#38 torvalds#39 torvalds#40 torvalds#41 torvalds#42 torvalds#43 torvalds#44 torvalds#45 torvalds#46 torvalds#47 [ 1.370219] .... node #0, CPUs: torvalds#48 torvalds#49 torvalds#50 torvalds#51 #52 #53 torvalds#54 torvalds#55 torvalds#56 torvalds#57 #58 torvalds#59 torvalds#60 torvalds#61 torvalds#62 torvalds#63 torvalds#64 torvalds#65 torvalds#66 torvalds#67 torvalds#68 torvalds#69 #70 torvalds#71 [ 1.378226] .... node #1, CPUs: torvalds#72 torvalds#73 torvalds#74 torvalds#75 torvalds#76 torvalds#77 torvalds#78 torvalds#79 torvalds#80 torvalds#81 torvalds#82 torvalds#83 torvalds#84 torvalds#85 torvalds#86 torvalds#87 torvalds#88 torvalds#89 torvalds#90 torvalds#91 torvalds#92 torvalds#93 torvalds#94 torvalds#95 [ 1.382037] Brought 96 CPUs to x86/cpu:kick in 72232606 cycles [ 0.104104] smpboot: CPU 26 Converting physical 0 to logical die 1 [ 0.104104] smpboot: CPU 27 Converting physical 1 to logical package 2 [ 0.104104] smpboot: CPU 24 Converting physical 1 to logical package 3 [ 0.104104] smpboot: CPU 27 Converting physical 0 to logical die 2 [ 0.104104] smpboot: CPU 25 Converting physical 1 to logical package 4 [ 1.385609] Brought 96 CPUs to x86/cpu:wait-init in 9269218 cycles [ 1.395285] Brought CPUs online in 28930764 cycles [ 1.395469] smp: Brought up 2 nodes, 96 CPUs [ 1.395689] smpboot: Max logical packages: 2 [ 1.396222] smpboot: Total of 96 processors activated (576000.00 BogoMIPS) Do the full topology update in smp_store_cpu_info() under a spinlock to ensure that things remain consistent. [Usama Arif: fixed rebase conflict] Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Signed-off-by: Usama Arif <usama.arif@bytedance.com> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Feb 8, 2023
The toplogy update is performed by the AP via smp_callin() after the BSP has called do_wait_cpu_initialized(), setting the AP's bit in cpu_callout_mask to allow it to proceed. In preparation to enable further parallelism of AP bringup, add locking to serialize the update even if multiple APs are (in future) permitted to proceed through the next stages of bringup in parallel. Without such ordering (and with that future extra parallelism), confusion ensues: [ 1.360149] x86: Booting SMP configuration: [ 1.360221] .... node #0, CPUs: #1 #2 #3 #4 #5 torvalds#6 torvalds#7 torvalds#8 torvalds#9 torvalds#10 torvalds#11 torvalds#12 torvalds#13 torvalds#14 torvalds#15 torvalds#16 torvalds#17 torvalds#18 torvalds#19 torvalds#20 torvalds#21 torvalds#22 torvalds#23 [ 1.366225] .... node #1, CPUs: torvalds#24 torvalds#25 torvalds#26 torvalds#27 torvalds#28 torvalds#29 torvalds#30 torvalds#31 torvalds#32 torvalds#33 torvalds#34 torvalds#35 torvalds#36 torvalds#37 torvalds#38 torvalds#39 torvalds#40 torvalds#41 torvalds#42 torvalds#43 torvalds#44 torvalds#45 torvalds#46 torvalds#47 [ 1.370219] .... node #0, CPUs: torvalds#48 torvalds#49 torvalds#50 torvalds#51 #52 #53 torvalds#54 torvalds#55 torvalds#56 torvalds#57 #58 torvalds#59 torvalds#60 torvalds#61 torvalds#62 torvalds#63 torvalds#64 torvalds#65 torvalds#66 torvalds#67 torvalds#68 torvalds#69 #70 torvalds#71 [ 1.378226] .... node #1, CPUs: torvalds#72 torvalds#73 torvalds#74 torvalds#75 torvalds#76 torvalds#77 torvalds#78 torvalds#79 torvalds#80 torvalds#81 torvalds#82 torvalds#83 torvalds#84 torvalds#85 torvalds#86 torvalds#87 torvalds#88 torvalds#89 torvalds#90 torvalds#91 torvalds#92 torvalds#93 torvalds#94 torvalds#95 [ 1.382037] Brought 96 CPUs to x86/cpu:kick in 72232606 cycles [ 0.104104] smpboot: CPU 26 Converting physical 0 to logical die 1 [ 0.104104] smpboot: CPU 27 Converting physical 1 to logical package 2 [ 0.104104] smpboot: CPU 24 Converting physical 1 to logical package 3 [ 0.104104] smpboot: CPU 27 Converting physical 0 to logical die 2 [ 0.104104] smpboot: CPU 25 Converting physical 1 to logical package 4 [ 1.385609] Brought 96 CPUs to x86/cpu:wait-init in 9269218 cycles [ 1.395285] Brought CPUs online in 28930764 cycles [ 1.395469] smp: Brought up 2 nodes, 96 CPUs [ 1.395689] smpboot: Max logical packages: 2 [ 1.396222] smpboot: Total of 96 processors activated (576000.00 BogoMIPS) [Usama Arif: fixed rebase conflict] Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Signed-off-by: Usama Arif <usama.arif@bytedance.com> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Feb 9, 2023
The toplogy update is performed by the AP via smp_callin() after the BSP has called do_wait_cpu_initialized(), setting the AP's bit in cpu_callout_mask to allow it to proceed. In preparation to enable further parallelism of AP bringup, add locking to serialize the update even if multiple APs are (in future) permitted to proceed through the next stages of bringup in parallel. Without such ordering (and with that future extra parallelism), confusion ensues: [ 1.360149] x86: Booting SMP configuration: [ 1.360221] .... node #0, CPUs: #1 #2 #3 #4 #5 torvalds#6 torvalds#7 torvalds#8 torvalds#9 torvalds#10 torvalds#11 torvalds#12 torvalds#13 torvalds#14 torvalds#15 torvalds#16 torvalds#17 torvalds#18 torvalds#19 torvalds#20 torvalds#21 torvalds#22 torvalds#23 [ 1.366225] .... node #1, CPUs: torvalds#24 torvalds#25 torvalds#26 torvalds#27 torvalds#28 torvalds#29 torvalds#30 torvalds#31 torvalds#32 torvalds#33 torvalds#34 torvalds#35 torvalds#36 torvalds#37 torvalds#38 torvalds#39 torvalds#40 torvalds#41 torvalds#42 torvalds#43 torvalds#44 torvalds#45 torvalds#46 torvalds#47 [ 1.370219] .... node #0, CPUs: torvalds#48 torvalds#49 torvalds#50 torvalds#51 #52 #53 torvalds#54 torvalds#55 torvalds#56 torvalds#57 #58 torvalds#59 torvalds#60 torvalds#61 torvalds#62 torvalds#63 torvalds#64 torvalds#65 torvalds#66 torvalds#67 torvalds#68 torvalds#69 #70 torvalds#71 [ 1.378226] .... node #1, CPUs: torvalds#72 torvalds#73 torvalds#74 torvalds#75 torvalds#76 torvalds#77 torvalds#78 torvalds#79 torvalds#80 torvalds#81 torvalds#82 torvalds#83 torvalds#84 torvalds#85 torvalds#86 torvalds#87 torvalds#88 torvalds#89 torvalds#90 torvalds#91 torvalds#92 torvalds#93 torvalds#94 torvalds#95 [ 1.382037] Brought 96 CPUs to x86/cpu:kick in 72232606 cycles [ 0.104104] smpboot: CPU 26 Converting physical 0 to logical die 1 [ 0.104104] smpboot: CPU 27 Converting physical 1 to logical package 2 [ 0.104104] smpboot: CPU 24 Converting physical 1 to logical package 3 [ 0.104104] smpboot: CPU 27 Converting physical 0 to logical die 2 [ 0.104104] smpboot: CPU 25 Converting physical 1 to logical package 4 [ 1.385609] Brought 96 CPUs to x86/cpu:wait-init in 9269218 cycles [ 1.395285] Brought CPUs online in 28930764 cycles [ 1.395469] smp: Brought up 2 nodes, 96 CPUs [ 1.395689] smpboot: Max logical packages: 2 [ 1.396222] smpboot: Total of 96 processors activated (576000.00 BogoMIPS) [Usama Arif: fixed rebase conflict] Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Signed-off-by: Usama Arif <usama.arif@bytedance.com> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Feb 15, 2023
The toplogy update is performed by the AP via smp_callin() after the BSP has called do_wait_cpu_initialized(), setting the AP's bit in cpu_callout_mask to allow it to proceed. In preparation to enable further parallelism of AP bringup, add locking to serialize the update even if multiple APs are (in future) permitted to proceed through the next stages of bringup in parallel. Without such ordering (and with that future extra parallelism), confusion ensues: [ 1.360149] x86: Booting SMP configuration: [ 1.360221] .... node #0, CPUs: #1 #2 #3 #4 #5 torvalds#6 torvalds#7 torvalds#8 torvalds#9 torvalds#10 torvalds#11 torvalds#12 torvalds#13 torvalds#14 torvalds#15 torvalds#16 torvalds#17 torvalds#18 torvalds#19 torvalds#20 torvalds#21 torvalds#22 torvalds#23 [ 1.366225] .... node #1, CPUs: torvalds#24 torvalds#25 torvalds#26 torvalds#27 torvalds#28 torvalds#29 torvalds#30 torvalds#31 torvalds#32 torvalds#33 torvalds#34 torvalds#35 torvalds#36 torvalds#37 torvalds#38 torvalds#39 torvalds#40 torvalds#41 torvalds#42 torvalds#43 torvalds#44 torvalds#45 torvalds#46 torvalds#47 [ 1.370219] .... node #0, CPUs: torvalds#48 torvalds#49 torvalds#50 torvalds#51 #52 #53 torvalds#54 torvalds#55 torvalds#56 torvalds#57 #58 torvalds#59 torvalds#60 torvalds#61 torvalds#62 torvalds#63 torvalds#64 torvalds#65 torvalds#66 torvalds#67 torvalds#68 torvalds#69 #70 torvalds#71 [ 1.378226] .... node #1, CPUs: torvalds#72 torvalds#73 torvalds#74 torvalds#75 torvalds#76 torvalds#77 torvalds#78 torvalds#79 torvalds#80 torvalds#81 torvalds#82 torvalds#83 torvalds#84 torvalds#85 torvalds#86 torvalds#87 torvalds#88 torvalds#89 torvalds#90 torvalds#91 torvalds#92 torvalds#93 torvalds#94 torvalds#95 [ 1.382037] Brought 96 CPUs to x86/cpu:kick in 72232606 cycles [ 0.104104] smpboot: CPU 26 Converting physical 0 to logical die 1 [ 0.104104] smpboot: CPU 27 Converting physical 1 to logical package 2 [ 0.104104] smpboot: CPU 24 Converting physical 1 to logical package 3 [ 0.104104] smpboot: CPU 27 Converting physical 0 to logical die 2 [ 0.104104] smpboot: CPU 25 Converting physical 1 to logical package 4 [ 1.385609] Brought 96 CPUs to x86/cpu:wait-init in 9269218 cycles [ 1.395285] Brought CPUs online in 28930764 cycles [ 1.395469] smp: Brought up 2 nodes, 96 CPUs [ 1.395689] smpboot: Max logical packages: 2 [ 1.396222] smpboot: Total of 96 processors activated (576000.00 BogoMIPS) [Usama Arif: fixed rebase conflict] Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Signed-off-by: Usama Arif <usama.arif@bytedance.com> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
gyroninja
added a commit
to gyroninja/linux
that referenced
this pull request
Jan 28, 2024
As of 5ec8e8e(mm/sparsemem: fix race in accessing memory_section->usage) KMSAN now calls into RCU tree code during kmsan_get_metadata. This will trigger a write that will reenter into KMSAN getting the system stuck doing infinite recursion. #0 kmsan_get_context () at mm/kmsan/kmsan.h:106 #1 __msan_get_context_state () at mm/kmsan/instrumentation.c:331 #2 0xffffffff81495671 in get_current () at ./arch/x86/include/asm/current.h:42 #3 rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 #4 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 #5 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#6 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#7 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82 torvalds#8 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75 torvalds#9 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143 torvalds#10 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97 torvalds#11 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36 torvalds#12 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91 torvalds#13 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 torvalds#14 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 torvalds#15 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#16 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#17 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82 torvalds#18 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75 torvalds#19 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143 torvalds#20 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97 torvalds#21 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36 torvalds#22 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91 torvalds#23 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 torvalds#24 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 torvalds#25 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#26 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#27 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82 torvalds#28 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75 torvalds#29 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143 torvalds#30 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97 torvalds#31 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36 torvalds#32 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91 torvalds#33 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 torvalds#34 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 torvalds#35 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#36 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#37 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82 torvalds#38 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75 torvalds#39 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143 torvalds#40 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97 torvalds#41 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36 torvalds#42 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91 torvalds#43 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 torvalds#44 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 torvalds#45 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#46 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#47 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82 torvalds#48 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75 torvalds#49 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143 torvalds#50 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97 torvalds#51 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36 #52 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91 #53 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 torvalds#54 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 torvalds#55 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#56 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#57 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82 #58 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75 torvalds#59 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143 torvalds#60 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97 torvalds#61 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36 torvalds#62 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91 torvalds#63 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 torvalds#64 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 torvalds#65 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#66 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#67 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82 torvalds#68 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75 torvalds#69 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143 #70 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97 torvalds#71 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36 torvalds#72 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91 torvalds#73 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 torvalds#74 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 torvalds#75 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#76 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#77 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff86203c90) at ./arch/x86/include/asm/kmsan.h:82 torvalds#78 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff86203c90) at mm/kmsan/shadow.c:75 torvalds#79 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff86203c90, is_origin=false) at mm/kmsan/shadow.c:143 torvalds#80 kmsan_get_shadow_origin_ptr (address=0xffffffff86203c90, size=8, store=false) at mm/kmsan/shadow.c:97 torvalds#81 0xffffffff81b1dc72 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=8, store=false) at mm/kmsan/instrumentation.c:36 torvalds#82 __msan_metadata_ptr_for_load_8 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:92 torvalds#83 0xffffffff814fdb9e in filter_irq_stacks (entries=<optimized out>, nr_entries=4) at kernel/stacktrace.c:397 torvalds#84 0xffffffff829520e8 in stack_depot_save_flags (entries=0xffffffff8620d974 <init_task+1012>, nr_entries=4, alloc_flags=0, depot_flags=0) at lib/stackdepot.c:500 torvalds#85 0xffffffff81b1e560 in __msan_poison_alloca (address=0xffffffff86203da0, size=24, descr=<optimized out>) at mm/kmsan/instrumentation.c:285 torvalds#86 0xffffffff8562821c in _printk (fmt=0xffffffff85f191a5 "\0016Attempting lock1") at kernel/printk/printk.c:2324 torvalds#87 0xffffffff81942aa2 in kmem_cache_create_usercopy (name=0xffffffff85f18903 "mm_struct", size=1296, align=0, flags=270336, useroffset=<optimized out>, usersize=<optimized out>, ctor=0x0 <fixed_percpu_data>) at mm/slab_common.c:296 torvalds#88 0xffffffff86f337a0 in mm_cache_init () at kernel/fork.c:3262 torvalds#89 0xffffffff86eacb8e in start_kernel () at init/main.c:932 torvalds#90 0xffffffff86ecdf94 in x86_64_start_reservations (real_mode_data=0x140e0 <exception_stacks+28896> <error: Cannot access memory at address 0x140e0>) at arch/x86/kernel/head64.c:555 torvalds#91 0xffffffff86ecde9b in x86_64_start_kernel (real_mode_data=0x140e0 <exception_stacks+28896> <error: Cannot access memory at address 0x140e0>) at arch/x86/kernel/head64.c:536 torvalds#92 0xffffffff810001d3 in secondary_startup_64 () at /pool/workspace/linux/arch/x86/kernel/head_64.S:461 torvalds#93 0x0000000000000000 in ??
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Mar 3, 2025
If track_pfn_copy() fails, we already added the dst VMA to the maple tree. As fork() fails, we'll cleanup the maple tree, and stumble over the dst VMA for which we neither performed any reservation nor copied any page tables. Consequently untrack_pfn() will see VM_PAT and try obtaining the PAT information from the page table -- which fails because the page table was not copied. The easiest fix would be to simply clear the VM_PAT flag of the dst VMA if track_pfn_copy() fails. However, the whole thing is about "simply" clearing the VM_PAT flag is shaky as well: if we passed track_pfn_copy() and performed a reservation, but copying the page tables fails, we'll simply clear the VM_PAT flag, not properly undoing the reservation ... which is also wrong. So let's fix it properly: set the VM_PAT flag only if the reservation succeeded (leaving it clear initially), and undo the reservation if anything goes wrong while copying the page tables: clearing the VM_PAT flag after undoing the reservation. Note that any copied page table entries will get zapped when the VMA will get removed later, after copy_page_range() succeeded; as VM_PAT is not set then, we won't try cleaning VM_PAT up once more and untrack_pfn() will be happy. Note that leaving these page tables in place without a reservation is not a problem, as we are aborting fork(); this process will never run. A reproducer can trigger this usually at the first try: https://gitlab.com/davidhildenbrand/scratchspace/-/raw/main/reproducers/pat_fork.c [ 45.239440] WARNING: CPU: 26 PID: 11650 at arch/x86/mm/pat/memtype.c:983 get_pat_info+0xf6/0x110 [ 45.241082] Modules linked in: ... [ 45.249119] CPU: 26 UID: 0 PID: 11650 Comm: repro3 Not tainted 6.12.0-rc5+ torvalds#92 [ 45.250598] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 [ 45.252181] RIP: 0010:get_pat_info+0xf6/0x110 ... [ 45.268513] Call Trace: [ 45.269003] <TASK> [ 45.269425] ? __warn.cold+0xb7/0x14d [ 45.270131] ? get_pat_info+0xf6/0x110 [ 45.270846] ? report_bug+0xff/0x140 [ 45.271519] ? handle_bug+0x58/0x90 [ 45.272192] ? exc_invalid_op+0x17/0x70 [ 45.272935] ? asm_exc_invalid_op+0x1a/0x20 [ 45.273717] ? get_pat_info+0xf6/0x110 [ 45.274438] ? get_pat_info+0x71/0x110 [ 45.275165] untrack_pfn+0x52/0x110 [ 45.275835] unmap_single_vma+0xa6/0xe0 [ 45.276549] unmap_vmas+0x105/0x1f0 [ 45.277256] exit_mmap+0xf6/0x460 [ 45.277913] __mmput+0x4b/0x120 [ 45.278512] copy_process+0x1bf6/0x2aa0 [ 45.279264] kernel_clone+0xab/0x440 [ 45.279959] __do_sys_clone+0x66/0x90 [ 45.280650] do_syscall_64+0x95/0x180 Likely this case was missed in: d155df5 ("x86/mm/pat: clear VM_PAT if copy_p4d_range failed") ... and instead of undoing the reservation we simply cleared the VM_PAT flag. Keep the documentation of these functions in include/linux/pgtable.h, one place is more than sufficient -- we should clean that up for the other functions like track_pfn_remap/untrack_pfn separately. Fixes: d155df5 ("x86/mm/pat: clear VM_PAT if copy_p4d_range failed") Fixes: 2ab6403 ("x86: PAT: hooks in generic vm code to help archs to track pfnmap regions - v3") Reported-by: xingwei lee <xrivendell7@gmail.com> Reported-by: yuxin wang <wang1315768607@163.com> Reported-by: Marius Fleischer <fleischermarius@gmail.com> Signed-off-by: David Hildenbrand <david@redhat.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20241029210331.1339581-1-david@redhat.com Closes: https://lore.kernel.org/lkml/CAJg=8jwijTP5fre8woS4JVJQ8iUA6v+iNcsOgtj9Zfpc3obDOQ@mail.gmail.com/ Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Rik van Riel <riel@surriel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Peter Xu <peterx@redhat.com>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Mar 21, 2025
If track_pfn_copy() fails, we already added the dst VMA to the maple tree. As fork() fails, we'll cleanup the maple tree, and stumble over the dst VMA for which we neither performed any reservation nor copied any page tables. Consequently untrack_pfn() will see VM_PAT and try obtaining the PAT information from the page table -- which fails because the page table was not copied. The easiest fix would be to simply clear the VM_PAT flag of the dst VMA if track_pfn_copy() fails. However, the whole thing is about "simply" clearing the VM_PAT flag is shaky as well: if we passed track_pfn_copy() and performed a reservation, but copying the page tables fails, we'll simply clear the VM_PAT flag, not properly undoing the reservation ... which is also wrong. So let's fix it properly: set the VM_PAT flag only if the reservation succeeded (leaving it clear initially), and undo the reservation if anything goes wrong while copying the page tables: clearing the VM_PAT flag after undoing the reservation. Note that any copied page table entries will get zapped when the VMA will get removed later, after copy_page_range() succeeded; as VM_PAT is not set then, we won't try cleaning VM_PAT up once more and untrack_pfn() will be happy. Note that leaving these page tables in place without a reservation is not a problem, as we are aborting fork(); this process will never run. A reproducer can trigger this usually at the first try: https://gitlab.com/davidhildenbrand/scratchspace/-/raw/main/reproducers/pat_fork.c [ 45.239440] WARNING: CPU: 26 PID: 11650 at arch/x86/mm/pat/memtype.c:983 get_pat_info+0xf6/0x110 [ 45.241082] Modules linked in: ... [ 45.249119] CPU: 26 UID: 0 PID: 11650 Comm: repro3 Not tainted 6.12.0-rc5+ torvalds#92 [ 45.250598] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 [ 45.252181] RIP: 0010:get_pat_info+0xf6/0x110 ... [ 45.268513] Call Trace: [ 45.269003] <TASK> [ 45.269425] ? __warn.cold+0xb7/0x14d [ 45.270131] ? get_pat_info+0xf6/0x110 [ 45.270846] ? report_bug+0xff/0x140 [ 45.271519] ? handle_bug+0x58/0x90 [ 45.272192] ? exc_invalid_op+0x17/0x70 [ 45.272935] ? asm_exc_invalid_op+0x1a/0x20 [ 45.273717] ? get_pat_info+0xf6/0x110 [ 45.274438] ? get_pat_info+0x71/0x110 [ 45.275165] untrack_pfn+0x52/0x110 [ 45.275835] unmap_single_vma+0xa6/0xe0 [ 45.276549] unmap_vmas+0x105/0x1f0 [ 45.277256] exit_mmap+0xf6/0x460 [ 45.277913] __mmput+0x4b/0x120 [ 45.278512] copy_process+0x1bf6/0x2aa0 [ 45.279264] kernel_clone+0xab/0x440 [ 45.279959] __do_sys_clone+0x66/0x90 [ 45.280650] do_syscall_64+0x95/0x180 Likely this case was missed in commit d155df5 ("x86/mm/pat: clear VM_PAT if copy_p4d_range failed") ... and instead of undoing the reservation we simply cleared the VM_PAT flag. Keep the documentation of these functions in include/linux/pgtable.h, one place is more than sufficient -- we should clean that up for the other functions like track_pfn_remap/untrack_pfn separately. Reported-by: xingwei lee <xrivendell7@gmail.com> Reported-by: yuxin wang <wang1315768607@163.com> Closes: https://lore.kernel.org/lkml/CABOYnLx_dnqzpCW99G81DmOr+2UzdmZMk=T3uxwNxwz+R1RAwg@mail.gmail.com/ Reported-by: Marius Fleischer <fleischermarius@gmail.com> Closes: https://lore.kernel.org/lkml/CAJg=8jwijTP5fre8woS4JVJQ8iUA6v+iNcsOgtj9Zfpc3obDOQ@mail.gmail.com/ Fixes: d155df5 ("x86/mm/pat: clear VM_PAT if copy_p4d_range failed") Fixes: 2ab6403 ("x86: PAT: hooks in generic vm code to help archs to track pfnmap regions - v3") Cc: Ingo Molnar <mingo@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Dan Carpenter <dan.carpenter@linaro.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Rik van Riel <riel@surriel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Peter Xu <peterx@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Mar 25, 2025
If track_pfn_copy() fails, we already added the dst VMA to the maple tree. As fork() fails, we'll cleanup the maple tree, and stumble over the dst VMA for which we neither performed any reservation nor copied any page tables. Consequently untrack_pfn() will see VM_PAT and try obtaining the PAT information from the page table -- which fails because the page table was not copied. The easiest fix would be to simply clear the VM_PAT flag of the dst VMA if track_pfn_copy() fails. However, the whole thing is about "simply" clearing the VM_PAT flag is shaky as well: if we passed track_pfn_copy() and performed a reservation, but copying the page tables fails, we'll simply clear the VM_PAT flag, not properly undoing the reservation ... which is also wrong. So let's fix it properly: set the VM_PAT flag only if the reservation succeeded (leaving it clear initially), and undo the reservation if anything goes wrong while copying the page tables: clearing the VM_PAT flag after undoing the reservation. Note that any copied page table entries will get zapped when the VMA will get removed later, after copy_page_range() succeeded; as VM_PAT is not set then, we won't try cleaning VM_PAT up once more and untrack_pfn() will be happy. Note that leaving these page tables in place without a reservation is not a problem, as we are aborting fork(); this process will never run. A reproducer can trigger this usually at the first try: https://gitlab.com/davidhildenbrand/scratchspace/-/raw/main/reproducers/pat_fork.c [ 45.239440] WARNING: CPU: 26 PID: 11650 at arch/x86/mm/pat/memtype.c:983 get_pat_info+0xf6/0x110 [ 45.241082] Modules linked in: ... [ 45.249119] CPU: 26 UID: 0 PID: 11650 Comm: repro3 Not tainted 6.12.0-rc5+ torvalds#92 [ 45.250598] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 [ 45.252181] RIP: 0010:get_pat_info+0xf6/0x110 ... [ 45.268513] Call Trace: [ 45.269003] <TASK> [ 45.269425] ? __warn.cold+0xb7/0x14d [ 45.270131] ? get_pat_info+0xf6/0x110 [ 45.270846] ? report_bug+0xff/0x140 [ 45.271519] ? handle_bug+0x58/0x90 [ 45.272192] ? exc_invalid_op+0x17/0x70 [ 45.272935] ? asm_exc_invalid_op+0x1a/0x20 [ 45.273717] ? get_pat_info+0xf6/0x110 [ 45.274438] ? get_pat_info+0x71/0x110 [ 45.275165] untrack_pfn+0x52/0x110 [ 45.275835] unmap_single_vma+0xa6/0xe0 [ 45.276549] unmap_vmas+0x105/0x1f0 [ 45.277256] exit_mmap+0xf6/0x460 [ 45.277913] __mmput+0x4b/0x120 [ 45.278512] copy_process+0x1bf6/0x2aa0 [ 45.279264] kernel_clone+0xab/0x440 [ 45.279959] __do_sys_clone+0x66/0x90 [ 45.280650] do_syscall_64+0x95/0x180 Likely this case was missed in commit d155df5 ("x86/mm/pat: clear VM_PAT if copy_p4d_range failed") ... and instead of undoing the reservation we simply cleared the VM_PAT flag. Keep the documentation of these functions in include/linux/pgtable.h, one place is more than sufficient -- we should clean that up for the other functions like track_pfn_remap/untrack_pfn separately. Reported-by: xingwei lee <xrivendell7@gmail.com> Reported-by: yuxin wang <wang1315768607@163.com> Closes: https://lore.kernel.org/lkml/CABOYnLx_dnqzpCW99G81DmOr+2UzdmZMk=T3uxwNxwz+R1RAwg@mail.gmail.com/ Reported-by: Marius Fleischer <fleischermarius@gmail.com> Closes: https://lore.kernel.org/lkml/CAJg=8jwijTP5fre8woS4JVJQ8iUA6v+iNcsOgtj9Zfpc3obDOQ@mail.gmail.com/ Fixes: d155df5 ("x86/mm/pat: clear VM_PAT if copy_p4d_range failed") Fixes: 2ab6403 ("x86: PAT: hooks in generic vm code to help archs to track pfnmap regions - v3") Cc: Ingo Molnar <mingo@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Dan Carpenter <dan.carpenter@linaro.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Rik van Riel <riel@surriel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Peter Xu <peterx@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com>
micromaomao
added a commit
to micromaomao/linux-dev
that referenced
this pull request
Apr 6, 2025
Hi 9p-fs maintainers,
(CC'ing Landlock and Fanotify/inotify people as this affects both use
cases, although most of my investigation has been on Landlock)
Previously [1], I noticed that when using 9pfs filesystems, the Landlock
LSM is blocking access even for files / directories allowed by rules, and
that this has something to do with 9pfs creating new inodes despite
Landlock holding a reference to the existing one. Because Landlock uses
inodes' in-memory state (i_security) to identify allowed fs
objects/hierarchies, this causes Landlock to partially break on 9pfs, at
least in uncached mode, which is the default:
# mount -t 9p -o trans=virtio test /mnt
# env LL_FS_RO=/etc:/usr:/bin:/lib:/mnt/readme LL_FS_RW= /sandboxer bash
Executing the sandboxed command...
bash: cannot set terminal process group (164): Inappropriate ioctl for device
bash: no job control in this shell
# cat /mnt/readme
cat: /mnt/readme: Permission denied
This, however, works if somebody is holding onto the dentry (and it also
works with cache=loose), as in both cases the inode is reused:
# tail -f /mnt/readme &
[1] 196
# env LL_FS_RO=/etc:/usr:/bin:/lib:/mnt/readme LL_FS_RW= /sandboxer bash
Executing the sandboxed command...
bash: cannot set terminal process group (164): Inappropriate ioctl for device
bash: no job control in this shell
# cat /mnt/readme
aa
It also works on directories if one have a shell that cd into the
directory. Note that this means only certain usage of Landlock are
affected - for example, sandboxing applications that takes a list of files
to allow, landlocks itself, then evecve. On the other hand, this does not
affect applications that opens a file, then Landlocks itself while keeping
the file it needs open.
While the above is a very simple example, this is problematic in
real-world use cases if Landlock is used to sandox applications on system
that has files mounted via 9pfs, or use 9pfs as the root filesystem. In
addition, this also affects fanotify / inotify when using inode mark (for
local access):
root@d8c28a676d72:/# ./fanotify-basic-open /readme & # on virtiofs
[1] 173
root@d8c28a676d72:/# cat readme
aa
FAN_OPEN: File /readme
root@d8c28a676d72:/# mount -t 9p -o trans=virtio test /mnt
root@d8c28a676d72:/# ./fanotify-basic-open /mnt/readme & # on 9pfs
[2] 176
root@d8c28a676d72:/# cat /mnt/readme
aa
root@d8c28a676d72:/#
Same can be demonstrated with inotifywait. The source code for
fanotify-basic-open, adopted from the fanotify man page, is available at
the end of this email.
Note that this is not a security bug for Landlock since it can only cause
legitimate access to be denied, but might be a problem for fanotify perm
(although I do recognize that using perm on individual inodes is already
perhaps a bit unreliable?)
It seems that there was an attempt at making 9pfs reuse inodes, based on
qid.path, however it was reverted [2] due to issues with servers that
present duplicate qids, for example on a QEMU host that has multiple
filesystems mounted under a single 9pfs export without multidevs=remap, or
in the case of other servers that doesn't necessarily support remapping
qids ([3] and more). I've done some testing on v6.12-rc4 which has the
simplified 9pfs inode code before it was reverted, and found that Landlock
works (however, we of course then have the issue demonstrated in [2]).
Unrelated to the above problem, it also seems like even with the revert in
[2], because in cached mode inode are still reused based on qid (and type,
version (aka mtime), etc), the setup mentioned in [2] still causes
problems in th latest kernel with cache=loose:
host # cd /tmp/linux-test
host # mkdir m1 m2
host # mount -t tmpfs tmpfs m1
host # mount -t tmpfs tmpfs m2
host # mkdir m1/dir m2/dir # needs to be done together so that they have the same mtime
host # echo foo > m1/dir/foo
host # echo bar > m2/dir/bar
guest # mount -t 9p -o trans=virtio,cache=loose test /mnt
guest # cd /mnt/m1/dir
qemu-system-x86_64: warning: 9p: Multiple devices detected in same VirtFS export, which might lead to file ID collisions and severe misbehaviours on guest! You should either use a separate export for each device shared from host or use virtfs option 'multidevs=remap'!
guest # ls
foo
guest # ls /mnt/m2/dir
foo # <- should be bar
guest # uname -a
Linux d8c28a676d72 6.14.0-dev torvalds#92 SMP PREEMPT_DYNAMIC Sun Apr 6 18:47:54 BST 2025 x86_64 GNU/Linux
With the above in mind, I have a proposal for 9pfs to:
1. Reuse inodes even in uncached mode
2. However, reuse them based on qid.path AND the actual pathname, by doing
the appropriate testing in v9fs_test(_new)?_inode(_dotl)?
The main problem here is how to store the pathname in a sensible way and
tie it to the inode. For now I opted with an array of names acquired with
take_dentry_name_snapshot, which reuses the same memory as the dcache to
store the actual strings, but doesn't tie the lifetime of the dentry with
the inode (I thought about holding a reference to the dentry in the
v9fs_inode, but it seemed like a wrong approach and would cause dentries
to not be evicted/released).
Maybe ideally there could be a general way for filesystems to tell
VFS/dcache to "pin" a dentry as long as the inode is alive, but still
allows the dentry and inode to be evicted based on memory pressure? In
fact, if the dentry is alive, we might not even need to do this in 9pfs,
as we will automatically get the same inode pointed to by the dentry.
Currently this pathname is immutable once attached to an inode, and
therefore it is not protected by locks or RCU, but this might have to
change for us to support renames that preserve the inode on next access.
This is not in this patchset yet. Also let me know if I've missed any
locks etc (I'm new to VFS, or for that matter, the kernel).
Storing one pathname per inode also means we don't reuse the same inode
for hardlinks -- maybe this can be fixed as well in a future version, if
this approach sounds good?
From some QEMU documentation I read [4] it seems like there is a plan to
resolve these kind of problems in a new version of the protocol, by
expanding the qid to include the filesystem identifier of a file on the
host, so maybe this can be disabled after a successful protocol version
check with the host? For now this is implemented as a default option,
inodeident=path, which can be set to 'none' to instead get the previous
behaviour.
This patchset is still a bit of a work in progress, and I've not tested
the performance impact. It currently uses strncmp to compare paths but
this might be able to be optimized into a hash comparison first. It
should also normally only need to do it for one pair of filenames, as the
test is only done if qid.path matches in the first place.
Also, currently the inode is not reused in cached mode if mtime changed
AND the dentry was evicted -- I considered removing the qid.version test
in v9fs_test_inode_dotl but I think perhaps care needs to be taken to
ensure we can refresh an inode that potentially has data cached? This is
a TODO for this patchset.
Another TODO is to maybe add support for case-insensitive matching?
For this patch series I've tested modifying files on both host and guest,
changing a file from regular file to dir then back while preserving ino,
keeping a file open in the guest with a fd, and using Landlock (which
results in an ihold but does not keep the dentry) then trying to access
the file from both inside and outside the Landlocked shell.
Let me know what's your thought on this -- if this is a viable approach
I'm happy to work on it more and do more testing. The main motivation
behind this is getting Landlock to work "out of the box" on 9pfs.
This patch series was based on, and tested on v6.14 + [5]
Kind regards,
Tingmao
[1]: landlock-lsm#45
[2]: https://lore.kernel.org/all/20241024-revert_iget-v1-4-4cac63d25f72@codewreck.org/
[3]: https://lore.kernel.org/all/20240923100508.GA32066@willie-the-truck/
[4]: https://wiki.qemu.org/Documentation/9p#Protocol_Plans
[5]: https://lore.kernel.org/all/cover.1743956147.git.m@maowtm.org/
fanotify-basic-open.c:
#define _GNU_SOURCE /* Needed to get O_LARGEFILE definition */
#include <errno.h>
#include <fcntl.h>
#include <limits.h>
#include <poll.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/fanotify.h>
#include <unistd.h>
/* Read all available fanotify events from the file descriptor 'fd'. */
static void handle_events(int fd)
{
const struct fanotify_event_metadata *metadata;
struct fanotify_event_metadata buf[200];
ssize_t size;
char path[PATH_MAX];
ssize_t path_len;
char procfd_path[PATH_MAX];
struct fanotify_response response;
for (;;) {
size = read(fd, buf, sizeof(buf));
if (size == -1 && errno != EAGAIN) {
perror("read");
exit(EXIT_FAILURE);
}
/* Check if end of available data reached. */
if (size <= 0)
break;
/* Point to the first event in the buffer. */
metadata = buf;
/* Loop over all events in the buffer. */
while (FAN_EVENT_OK(metadata, size)) {
if (metadata->fd >= 0) {
if (metadata->mask & FAN_OPEN) {
printf("FAN_OPEN: ");
}
/* Retrieve and print pathname of the accessed file. */
snprintf(procfd_path, sizeof(procfd_path),
"/proc/self/fd/%d", metadata->fd);
path_len = readlink(procfd_path, path,
sizeof(path) - 1);
if (path_len == -1) {
perror("readlink");
exit(EXIT_FAILURE);
}
path[path_len] = '\0';
printf("File %s\n", path);
/* Close the file descriptor of the event. */
close(metadata->fd);
}
/* Advance to next event. */
metadata = FAN_EVENT_NEXT(metadata, size);
}
}
}
int main(int argc, char *argv[])
{
char buf;
int fd, poll_num;
nfds_t nfds;
struct pollfd fds[2];
/* Check mount point is supplied. */
if (argc != 2) {
fprintf(stderr, "Usage: %s FILE\n", argv[0]);
exit(EXIT_FAILURE);
}
fd = fanotify_init(0, O_RDONLY | O_LARGEFILE);
if (fd == -1) {
perror("fanotify_init");
exit(EXIT_FAILURE);
}
if (fanotify_mark(fd, FAN_MARK_ADD | FAN_MARK_INODE, FAN_OPEN, AT_FDCWD,
argv[1]) == -1) {
perror("fanotify_mark");
exit(EXIT_FAILURE);
}
while (1) {
handle_events(fd);
}
}
mattiaswal
pushed a commit
to kernelkit/linux
that referenced
this pull request
Apr 10, 2025
[ Upstream commit dc84bc2 ] If track_pfn_copy() fails, we already added the dst VMA to the maple tree. As fork() fails, we'll cleanup the maple tree, and stumble over the dst VMA for which we neither performed any reservation nor copied any page tables. Consequently untrack_pfn() will see VM_PAT and try obtaining the PAT information from the page table -- which fails because the page table was not copied. The easiest fix would be to simply clear the VM_PAT flag of the dst VMA if track_pfn_copy() fails. However, the whole thing is about "simply" clearing the VM_PAT flag is shaky as well: if we passed track_pfn_copy() and performed a reservation, but copying the page tables fails, we'll simply clear the VM_PAT flag, not properly undoing the reservation ... which is also wrong. So let's fix it properly: set the VM_PAT flag only if the reservation succeeded (leaving it clear initially), and undo the reservation if anything goes wrong while copying the page tables: clearing the VM_PAT flag after undoing the reservation. Note that any copied page table entries will get zapped when the VMA will get removed later, after copy_page_range() succeeded; as VM_PAT is not set then, we won't try cleaning VM_PAT up once more and untrack_pfn() will be happy. Note that leaving these page tables in place without a reservation is not a problem, as we are aborting fork(); this process will never run. A reproducer can trigger this usually at the first try: https://gitlab.com/davidhildenbrand/scratchspace/-/raw/main/reproducers/pat_fork.c WARNING: CPU: 26 PID: 11650 at arch/x86/mm/pat/memtype.c:983 get_pat_info+0xf6/0x110 Modules linked in: ... CPU: 26 UID: 0 PID: 11650 Comm: repro3 Not tainted 6.12.0-rc5+ torvalds#92 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:get_pat_info+0xf6/0x110 ... Call Trace: <TASK> ... untrack_pfn+0x52/0x110 unmap_single_vma+0xa6/0xe0 unmap_vmas+0x105/0x1f0 exit_mmap+0xf6/0x460 __mmput+0x4b/0x120 copy_process+0x1bf6/0x2aa0 kernel_clone+0xab/0x440 __do_sys_clone+0x66/0x90 do_syscall_64+0x95/0x180 Likely this case was missed in: d155df5 ("x86/mm/pat: clear VM_PAT if copy_p4d_range failed") ... and instead of undoing the reservation we simply cleared the VM_PAT flag. Keep the documentation of these functions in include/linux/pgtable.h, one place is more than sufficient -- we should clean that up for the other functions like track_pfn_remap/untrack_pfn separately. Fixes: d155df5 ("x86/mm/pat: clear VM_PAT if copy_p4d_range failed") Fixes: 2ab6403 ("x86: PAT: hooks in generic vm code to help archs to track pfnmap regions - v3") Reported-by: xingwei lee <xrivendell7@gmail.com> Reported-by: yuxin wang <wang1315768607@163.com> Reported-by: Marius Fleischer <fleischermarius@gmail.com> Signed-off-by: David Hildenbrand <david@redhat.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Rik van Riel <riel@surriel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: linux-mm@kvack.org Link: https://lore.kernel.org/r/20250321112323.153741-1-david@redhat.com Closes: https://lore.kernel.org/lkml/CABOYnLx_dnqzpCW99G81DmOr+2UzdmZMk=T3uxwNxwz+R1RAwg@mail.gmail.com/ Closes: https://lore.kernel.org/lkml/CAJg=8jwijTP5fre8woS4JVJQ8iUA6v+iNcsOgtj9Zfpc3obDOQ@mail.gmail.com/ Signed-off-by: Sasha Levin <sashal@kernel.org>
ptr1337
pushed a commit
to CachyOS/linux
that referenced
this pull request
Apr 10, 2025
[ Upstream commit dc84bc2 ] If track_pfn_copy() fails, we already added the dst VMA to the maple tree. As fork() fails, we'll cleanup the maple tree, and stumble over the dst VMA for which we neither performed any reservation nor copied any page tables. Consequently untrack_pfn() will see VM_PAT and try obtaining the PAT information from the page table -- which fails because the page table was not copied. The easiest fix would be to simply clear the VM_PAT flag of the dst VMA if track_pfn_copy() fails. However, the whole thing is about "simply" clearing the VM_PAT flag is shaky as well: if we passed track_pfn_copy() and performed a reservation, but copying the page tables fails, we'll simply clear the VM_PAT flag, not properly undoing the reservation ... which is also wrong. So let's fix it properly: set the VM_PAT flag only if the reservation succeeded (leaving it clear initially), and undo the reservation if anything goes wrong while copying the page tables: clearing the VM_PAT flag after undoing the reservation. Note that any copied page table entries will get zapped when the VMA will get removed later, after copy_page_range() succeeded; as VM_PAT is not set then, we won't try cleaning VM_PAT up once more and untrack_pfn() will be happy. Note that leaving these page tables in place without a reservation is not a problem, as we are aborting fork(); this process will never run. A reproducer can trigger this usually at the first try: https://gitlab.com/davidhildenbrand/scratchspace/-/raw/main/reproducers/pat_fork.c WARNING: CPU: 26 PID: 11650 at arch/x86/mm/pat/memtype.c:983 get_pat_info+0xf6/0x110 Modules linked in: ... CPU: 26 UID: 0 PID: 11650 Comm: repro3 Not tainted 6.12.0-rc5+ torvalds#92 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:get_pat_info+0xf6/0x110 ... Call Trace: <TASK> ... untrack_pfn+0x52/0x110 unmap_single_vma+0xa6/0xe0 unmap_vmas+0x105/0x1f0 exit_mmap+0xf6/0x460 __mmput+0x4b/0x120 copy_process+0x1bf6/0x2aa0 kernel_clone+0xab/0x440 __do_sys_clone+0x66/0x90 do_syscall_64+0x95/0x180 Likely this case was missed in: d155df5 ("x86/mm/pat: clear VM_PAT if copy_p4d_range failed") ... and instead of undoing the reservation we simply cleared the VM_PAT flag. Keep the documentation of these functions in include/linux/pgtable.h, one place is more than sufficient -- we should clean that up for the other functions like track_pfn_remap/untrack_pfn separately. Fixes: d155df5 ("x86/mm/pat: clear VM_PAT if copy_p4d_range failed") Fixes: 2ab6403 ("x86: PAT: hooks in generic vm code to help archs to track pfnmap regions - v3") Reported-by: xingwei lee <xrivendell7@gmail.com> Reported-by: yuxin wang <wang1315768607@163.com> Reported-by: Marius Fleischer <fleischermarius@gmail.com> Signed-off-by: David Hildenbrand <david@redhat.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Rik van Riel <riel@surriel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: linux-mm@kvack.org Link: https://lore.kernel.org/r/20250321112323.153741-1-david@redhat.com Closes: https://lore.kernel.org/lkml/CABOYnLx_dnqzpCW99G81DmOr+2UzdmZMk=T3uxwNxwz+R1RAwg@mail.gmail.com/ Closes: https://lore.kernel.org/lkml/CAJg=8jwijTP5fre8woS4JVJQ8iUA6v+iNcsOgtj9Zfpc3obDOQ@mail.gmail.com/ Signed-off-by: Sasha Levin <sashal@kernel.org>
Kaz205
pushed a commit
to Kaz205/linux
that referenced
this pull request
Apr 10, 2025
[ Upstream commit dc84bc2 ] If track_pfn_copy() fails, we already added the dst VMA to the maple tree. As fork() fails, we'll cleanup the maple tree, and stumble over the dst VMA for which we neither performed any reservation nor copied any page tables. Consequently untrack_pfn() will see VM_PAT and try obtaining the PAT information from the page table -- which fails because the page table was not copied. The easiest fix would be to simply clear the VM_PAT flag of the dst VMA if track_pfn_copy() fails. However, the whole thing is about "simply" clearing the VM_PAT flag is shaky as well: if we passed track_pfn_copy() and performed a reservation, but copying the page tables fails, we'll simply clear the VM_PAT flag, not properly undoing the reservation ... which is also wrong. So let's fix it properly: set the VM_PAT flag only if the reservation succeeded (leaving it clear initially), and undo the reservation if anything goes wrong while copying the page tables: clearing the VM_PAT flag after undoing the reservation. Note that any copied page table entries will get zapped when the VMA will get removed later, after copy_page_range() succeeded; as VM_PAT is not set then, we won't try cleaning VM_PAT up once more and untrack_pfn() will be happy. Note that leaving these page tables in place without a reservation is not a problem, as we are aborting fork(); this process will never run. A reproducer can trigger this usually at the first try: https://gitlab.com/davidhildenbrand/scratchspace/-/raw/main/reproducers/pat_fork.c WARNING: CPU: 26 PID: 11650 at arch/x86/mm/pat/memtype.c:983 get_pat_info+0xf6/0x110 Modules linked in: ... CPU: 26 UID: 0 PID: 11650 Comm: repro3 Not tainted 6.12.0-rc5+ torvalds#92 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:get_pat_info+0xf6/0x110 ... Call Trace: <TASK> ... untrack_pfn+0x52/0x110 unmap_single_vma+0xa6/0xe0 unmap_vmas+0x105/0x1f0 exit_mmap+0xf6/0x460 __mmput+0x4b/0x120 copy_process+0x1bf6/0x2aa0 kernel_clone+0xab/0x440 __do_sys_clone+0x66/0x90 do_syscall_64+0x95/0x180 Likely this case was missed in: d155df5 ("x86/mm/pat: clear VM_PAT if copy_p4d_range failed") ... and instead of undoing the reservation we simply cleared the VM_PAT flag. Keep the documentation of these functions in include/linux/pgtable.h, one place is more than sufficient -- we should clean that up for the other functions like track_pfn_remap/untrack_pfn separately. Fixes: d155df5 ("x86/mm/pat: clear VM_PAT if copy_p4d_range failed") Fixes: 2ab6403 ("x86: PAT: hooks in generic vm code to help archs to track pfnmap regions - v3") Reported-by: xingwei lee <xrivendell7@gmail.com> Reported-by: yuxin wang <wang1315768607@163.com> Reported-by: Marius Fleischer <fleischermarius@gmail.com> Signed-off-by: David Hildenbrand <david@redhat.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Rik van Riel <riel@surriel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: linux-mm@kvack.org Link: https://lore.kernel.org/r/20250321112323.153741-1-david@redhat.com Closes: https://lore.kernel.org/lkml/CABOYnLx_dnqzpCW99G81DmOr+2UzdmZMk=T3uxwNxwz+R1RAwg@mail.gmail.com/ Closes: https://lore.kernel.org/lkml/CAJg=8jwijTP5fre8woS4JVJQ8iUA6v+iNcsOgtj9Zfpc3obDOQ@mail.gmail.com/ Signed-off-by: Sasha Levin <sashal@kernel.org>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Code should add instructions to kernel to auto-detect the presence of ds1307 device on I2C bus on address 0x68 and in case it is found auto assign it. The main drive is to make sure that devices (like Pi) do have correct time before init process is started thus make sure that all daemons have correct time during startup phase. I'm pretty sure that the code added is wrong, jsut don t knwo whom to contact to get help to add this functionality :) I've reused parts from the DOC: https://www.kernel.org/doc/Documentation/i2c/instantiating-devices