Re: [PATCH net-next v3] net: phy: broadcom: add 1000Base-X support for BCM54616S
Hi Vladimir,
On 8/3/19 6:49 AM, Vladimir Oltean wrote:
> Hi Tao,
>
> On Sat, 3 Aug 2019 at 00:56, Tao Ren wrote:
>>
>> genphy_read_status() cannot report correct link speed when BCM54616S PHY
>> is configured in RGMII->1000Base-KX mode (for example, on Facebook CMM
>> BMC platform), and it is because speed-related fields in MII registers
>> are assigned different meanings in 1000X register set. Actually there
>> is no speed field in 1000X register set because link speed is always
>> 1000 Mb/s.
>>
>> The patch adds "probe" callback to detect PHY's operation mode based on
>> INTERF_SEL[1:0] pins and 1000X/100FX selection bit in SerDES 100-FX
>> Control register. Besides, link speed is manually set to 1000 Mb/s in
>> "read_status" callback if PHY-switch link is 1000Base-X.
>>
>> Signed-off-by: Tao Ren
>> ---
>> Changes in v3:
>> - rename bcm5482_read_status to bcm54xx_read_status so the callback can
>> be shared by BCM5482 and BCM54616S.
>> Changes in v2:
>> - Auto-detect PHY operation mode instead of passing DT node.
>> - move PHY mode auto-detect logic from config_init to probe callback.
>> - only set speed (not including duplex) in read_status callback.
>> - update patch description with more background to avoid confusion.
>> - patch #1 in the series ("net: phy: broadcom: set features explicitly
>> for BCM54616") is dropped: the fix should go to get_features callback
>> which may potentially depend on this patch.
>>
>> drivers/net/phy/broadcom.c | 41 +-
>> include/linux/brcmphy.h| 10 --
>> 2 files changed, 44 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
>> index 937d0059e8ac..ecad8a201a09 100644
>> --- a/drivers/net/phy/broadcom.c
>> +++ b/drivers/net/phy/broadcom.c
>> @@ -383,9 +383,9 @@ static int bcm5482_config_init(struct phy_device *phydev)
>> /*
>> * Select 1000BASE-X register set (primary SerDes)
>> */
>> - reg = bcm_phy_read_shadow(phydev, BCM5482_SHD_MODE);
>> - bcm_phy_write_shadow(phydev, BCM5482_SHD_MODE,
>> -reg | BCM5482_SHD_MODE_1000BX);
>> + reg = bcm_phy_read_shadow(phydev, BCM54XX_SHD_MODE);
>> + bcm_phy_write_shadow(phydev, BCM54XX_SHD_MODE,
>> +reg | BCM54XX_SHD_MODE_1000BX);
>>
>> /*
>> * LED1=ACTIVITYLED, LED3=LINKSPD[2]
>> @@ -409,7 +409,7 @@ static int bcm5482_config_init(struct phy_device *phydev)
>> return err;
>> }
>>
>> -static int bcm5482_read_status(struct phy_device *phydev)
>> +static int bcm54xx_read_status(struct phy_device *phydev)
>> {
>> int err;
>>
>> @@ -464,6 +464,35 @@ static int bcm54616s_config_aneg(struct phy_device
>> *phydev)
>> return ret;
>> }
>>
>> +static int bcm54616s_probe(struct phy_device *phydev)
>> +{
>> + int val, intf_sel;
>> +
>> + val = bcm_phy_read_shadow(phydev, BCM54XX_SHD_MODE);
>> + if (val < 0)
>> + return val;
>> +
>> + /* The PHY is strapped in RGMII to fiber mode when INTERF_SEL[1:0]
>> +* is 01b.
>> +*/
>> + intf_sel = (val & BCM54XX_SHD_INTF_SEL_MASK) >> 1;
>> + if (intf_sel == 1) {
>> + val = bcm_phy_read_shadow(phydev, BCM54616S_SHD_100FX_CTRL);
>> + if (val < 0)
>> + return val;
>> +
>> + /* Bit 0 of the SerDes 100-FX Control register, when set
>> +* to 1, sets the MII/RGMII -> 100BASE-FX configuration.
>> +* When this bit is set to 0, it sets the GMII/RGMII ->
>> +* 1000BASE-X configuration.
>> +*/
>> + if (!(val & BCM54616S_100FX_MODE))
>> + phydev->dev_flags |= PHY_BCM_FLAGS_MODE_1000BX;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> static int brcm_phy_setbits(struct phy_device *phydev, int reg, int set)
>> {
>> int val;
>> @@ -655,6 +684,8 @@ static struct phy_driver broadcom_drivers[] = {
>> .config_aneg= bcm54616s_config_aneg,
>> .ack_interrupt = bcm_phy_ack_intr,
>> .config_intr= bcm_phy_config_intr,
>> + .read_status= bcm54xx_read_status,
>> + .probe = bcm54616s_probe,
>> }, {
>> .phy_id = PHY_ID_BCM5464,
>> .phy_id_mask= 0xfff0,
>> @@ -689,7 +720,7 @@ static struct phy_driver broadcom_drivers[] = {
>> .name = "Broadcom BCM5482",
>> /* PHY_GBIT_FEATURES */
>> .config_init= bcm5482_config_init,
>> - .read_status= bcm5482_read_status,
>> + .read_status= bcm54xx_read_status,
>> .ack_interrupt = bcm_phy_ack_intr,
>> .config_intr= bcm_phy_config_intr,
>> }, {
>> diff --git a/include/linux/brcmphy.h b/include/linux/brcmphy.h
>> index
Re: [PATCH v2] kconfig: Clear "written" flag to avoid data loss
On Sat, Aug 3, 2019 at 7:02 PM M. Vefa Bicakci wrote:
>
> Prior to this commit, starting nconfig, xconfig or gconfig, and saving
> the .config file more than once caused data loss, where a .config file
> that contained only comments would be written to disk starting from the
> second save operation.
>
> This bug manifests itself because the SYMBOL_WRITTEN flag is never
> cleared after the first call to conf_write, and subsequent calls to
> conf_write then skip all of the configuration symbols due to the
> SYMBOL_WRITTEN flag being set.
>
> This commit resolves this issue by clearing the SYMBOL_WRITTEN flag
> from all symbols before conf_write returns.
>
> Fixes: 8e2442a5f86e ("kconfig: fix missing choice values in auto.conf")
> Cc: linux-stable # 4.19+
> Signed-off-by: M. Vefa Bicakci
Applied to linux-kbuild/fixes.
Thanks.
--
Best Regards
Masahiro Yamada
[PATCH] staging: rtl8192u: Add NULL check post kzalloc
Collect returns status of kzalloc.
Signed-off-by: Hariprasad Kelam
---
drivers/staging/rtl8192u/r8192U_core.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8192U_core.c
b/drivers/staging/rtl8192u/r8192U_core.c
index fe1f279..3240442 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -2096,7 +2096,7 @@ static void rtl8192_SetWirelessMode(struct net_device
*dev, u8 wireless_mode)
}
/* init priv variables here. only non_zero value should be initialized here. */
-static void rtl8192_init_priv_variable(struct net_device *dev)
+static int rtl8192_init_priv_variable(struct net_device *dev)
{
struct r8192_priv *priv = ieee80211_priv(dev);
u8 i;
@@ -2223,6 +2223,8 @@ static void rtl8192_init_priv_variable(struct net_device
*dev)
priv->AcmControl = 0;
priv->pFirmware = kzalloc(sizeof(rt_firmware), GFP_KERNEL);
+ if (!priv->pFirmware)
+ return -ENOMEM;
/* rx related queue */
skb_queue_head_init(>rx_queue);
@@ -2236,6 +2238,8 @@ static void rtl8192_init_priv_variable(struct net_device
*dev)
for (i = 0; i < MAX_QUEUE_SIZE; i++)
skb_queue_head_init(>ieee80211->skb_drv_aggQ[i]);
priv->rf_set_chan = rtl8192_phy_SwChnl;
+
+ return 0;
}
/* init lock here */
@@ -2605,7 +2609,11 @@ static short rtl8192_init(struct net_device *dev)
memcpy(priv->txqueue_to_outpipemap, queuetopipe, 9);
}
#endif
- rtl8192_init_priv_variable(dev);
+ err = rtl8192_init_priv_variable(dev);
+ if (err) {
+ DMESG("init private variables failed");
+ return err;
+ }
rtl8192_init_priv_lock(priv);
rtl8192_init_priv_task(dev);
rtl8192_get_eeprom_size(dev);
--
2.7.4
Re: [PATCH] kconfig: ignore auto-generated file
On Sun, Aug 4, 2019 at 1:30 AM Matteo Croce wrote: > > On Sun, Jul 28, 2019 at 8:23 PM Matteo Croce wrote: > > > > scripts/kconfig/zconf.hash.c is autogenerated during the build, > > let's add it to the directory .gitignore. > > > > Signed-off-by: Matteo Croce > > > > Sorry, forgot to CC the maintainer and the relevant mailing list Probably, you built old version kernel. The latest one does not generate kernel/config_data.h See bb3290d91695bb1ae78ab86f18fb4d7ad8e5ebcc -- Best Regards Masahiro Yamada
Re: [PATCH] kernel: ignore auto-generated file
On Sun, Aug 4, 2019 at 1:33 AM Matteo Croce wrote: > > On Sun, Jul 28, 2019 at 8:20 PM Matteo Croce wrote: > > > > kernel/config_data.h is autogenerated during the build, let's add it to > > the directory .gitignore. > > > > Signed-off-by: Matteo Croce > > > > CCing people as `scripts/get_maintainer.pl kernel/.gitignore` suggests > Probably, you built old version kernel. The latest one does not generate kernel/config_data.h See 13610aa908dcfce77135bb799c0a10d0172da6ba -- Best Regards Masahiro Yamada
Re: [PATCH v2 1/2] media: ir-kbd-i2c: convert to i2c_new_dummy_device()
On Sat, Aug 03, 2019 at 01:17:49PM -0300, Mauro Carvalho Chehab wrote: > Em Tue, 30 Jul 2019 19:55:54 +0200 > Wolfram Sang escreveu: > > > Convert this driver to use the new i2c_new_dummy_device() call and bail > > out if the dummy device cannot be registered to make failure more > > visible to the user. > > > > Please don't do that. > > At first glance, devm_* sounds a good idea, but we had enough issues > using it on media system. > > I don't mind mind much if some SoC specific would use it, but doing > it on generic drivers is a very bad idea. We have removed almost all > devm_* calls from the media system. > > The problem with devm is that it the de-allocation routines aren't > called during device unbind. They happen a way later, only when the > device itself is physically removed, or the driver is removed. Yes, good point. > That caused lots of headaches to debug memory lifetime issues on > media. Indeed this becomes much more complex. Explicit freeing is much better. Thanks, Sean
[Patch v2] staging: rtl8192e: Make use kmemdup
As kmemdup API does kmalloc + memcpy . We can make use of it instead of
calling kmalloc and memcpy independetly.
Signed-off-by: Hariprasad Kelam
---
v2 - remove the netdev_info() uses for allocation failures
drivers/staging/rtl8192e/rtllib_softmac.c | 24 +++-
1 file changed, 7 insertions(+), 17 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtllib_softmac.c
b/drivers/staging/rtl8192e/rtllib_softmac.c
index e29e8d6..f2f7529 100644
--- a/drivers/staging/rtl8192e/rtllib_softmac.c
+++ b/drivers/staging/rtl8192e/rtllib_softmac.c
@@ -1382,15 +1382,10 @@ rtllib_association_req(struct rtllib_network *beacon,
ieee->assocreq_ies = NULL;
ies = &(hdr->info_element[0].id);
ieee->assocreq_ies_len = (skb->data + skb->len) - ies;
- ieee->assocreq_ies = kmalloc(ieee->assocreq_ies_len, GFP_ATOMIC);
- if (ieee->assocreq_ies)
- memcpy(ieee->assocreq_ies, ies, ieee->assocreq_ies_len);
- else {
- netdev_info(ieee->dev,
- "%s()Warning: can't alloc memory for
assocreq_ies\n",
- __func__);
+ ieee->assocreq_ies = kmemdup(ies, ieee->assocreq_ies_len, GFP_ATOMIC);
+ if (!ieee->assocreq_ies)
ieee->assocreq_ies_len = 0;
- }
+
return skb;
}
@@ -2259,17 +2254,12 @@ rtllib_rx_assoc_resp(struct rtllib_device *ieee, struct
sk_buff *skb,
ieee->assocresp_ies = NULL;
ies = &(assoc_resp->info_element[0].id);
ieee->assocresp_ies_len = (skb->data + skb->len) - ies;
- ieee->assocresp_ies = kmalloc(ieee->assocresp_ies_len,
+ ieee->assocresp_ies = kmemdup(ies,
+ ieee->assocresp_ies_len,
GFP_ATOMIC);
- if (ieee->assocresp_ies)
- memcpy(ieee->assocresp_ies, ies,
- ieee->assocresp_ies_len);
- else {
- netdev_info(ieee->dev,
- "%s()Warning: can't alloc memory
for assocresp_ies\n",
- __func__);
+ if (!ieee->assocresp_ies)
ieee->assocresp_ies_len = 0;
- }
+
rtllib_associate_complete(ieee);
} else {
/* aid could not been allocated */
--
2.7.4
Re: [PATCH] staging: rtl8192e: Make use kmemdup
On Sat, Aug 03, 2019 at 10:52:04AM -0700, Joe Perches wrote:
> On Sat, 2019-08-03 at 23:10 +0530, Hariprasad Kelam wrote:
> > As kmemdup API does kmalloc + memcpy . We can make use of it instead of
> > calling kmalloc and memcpy independetly.
> []
> > diff --git a/drivers/staging/rtl8192e/rtllib_softmac.c
> > b/drivers/staging/rtl8192e/rtllib_softmac.c
> []
> > @@ -1382,10 +1382,8 @@ rtllib_association_req(struct rtllib_network *beacon,
> > ieee->assocreq_ies = NULL;
> > ies = &(hdr->info_element[0].id);
> > ieee->assocreq_ies_len = (skb->data + skb->len) - ies;
> > - ieee->assocreq_ies = kmalloc(ieee->assocreq_ies_len, GFP_ATOMIC);
> > - if (ieee->assocreq_ies)
> > - memcpy(ieee->assocreq_ies, ies, ieee->assocreq_ies_len);
> > - else {
> > + ieee->assocreq_ies = kmemdup(ies, ieee->assocreq_ies_len, GFP_ATOMIC);
> > + if (!ieee->assocreq_ies) {
> > netdev_info(ieee->dev,
> > "%s()Warning: can't alloc memory for
> > assocreq_ies\n",
> > __func__);
> > @@ -2259,12 +2257,10 @@ rtllib_rx_assoc_resp(struct rtllib_device *ieee,
> > struct sk_buff *skb,
> > ieee->assocresp_ies = NULL;
> > ies = &(assoc_resp->info_element[0].id);
> > ieee->assocresp_ies_len = (skb->data + skb->len) - ies;
> > - ieee->assocresp_ies = kmalloc(ieee->assocresp_ies_len,
> > + ieee->assocresp_ies = kmemdup(ies,
> > + ieee->assocresp_ies_len,
> > GFP_ATOMIC);
> > - if (ieee->assocresp_ies)
> > - memcpy(ieee->assocresp_ies, ies,
> > - ieee->assocresp_ies_len);
> > - else {
> > + if (!ieee->assocresp_ies) {
> > netdev_info(ieee->dev,
> > "%s()Warning: can't alloc memory
> > for assocresp_ies\n",
> > __func__);
>
> Could also remove the netdev_info() uses for allocation failures.
> These are redundant as a dump_stack() is already done when OOM.
>
Sure will do.
Thanks,
Hariprasad k
Re: [PULL 0/1] xtensa fixes for v5.3
The pull request you sent on Sat, 3 Aug 2019 17:33:17 -0700: > git://github.com/jcmvbkbc/linux-xtensa.git tags/xtensa-20190803 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/d8778f13b73f1cde08be0ece18571dee495b92f1 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PATCH] KEYS: trusted: allow module init if TPM is inactive or deactivated
On Sat, 2019-08-03 at 17:44 +0300, Jarkko Sakkinen wrote: > On Fri, 2019-08-02 at 15:23 -0500, Tyler Hicks wrote: > > That wasn't the conclusion that I came to. I prefer Robert's proposed > > change to trusted.ko. > > > > How do you propose that this be fixed in eCryptfs? > > > > Removing encrypted_key support from eCryptfs is the only way that I can > > see to fix the bug in eCryptfs. That support has been there since 2011. > > I'm not sure of the number of users that would be broken by removing > > encrypted_key support. I don't think the number is high but I can't say > > that confidently. > > Looking at the documentation [1] it is stated that > > "Encrypted keys do not depend on a TPM, and are faster, as they use AES > for encryption/decryption." > > Why would you need to remove support for encrypted keys? Isn't it a > regression in encrypted keys to hard depend on trusted keys given > what the documentation says? "Encrypted" key are symmetric keys, which are encrypted/decrypted either by a "trusted" key or, for development purposes only, a "user" key. Mimi
Re: [PATCH] arm64: dts: rockchip: Add dts for Leez RK3399 P710 SBC
Hi Andy,
Am Samstag, 3. August 2019, 13:46:12 CEST schrieb Andy Yan:
> Leez P710 is a RK3399 based SBC, designed by Leez team
> from lenovo [0].
>
> Specification
> - Rockchip RK3399
> - 4/2GB LPDDR4
> - TF sd scard slot
> - eMMC
> - M.2 B-Key for 4G LTE
> - AP6256 for WiFi + BT
> - Gigabit ethernet
> - HDMI out
> - 40 pin header
> - TYPE-C Power supply
>
> [0] https://leez.lenovo.com
>
> Signed-off-by: Andy Yan
> ---
> .../devicetree/bindings/arm/rockchip.yaml | 5 +
> arch/arm64/boot/dts/rockchip/Makefile | 1 +
> .../boot/dts/rockchip/rk3399-leez-p710.dts| 635 ++
> 3 files changed, 641 insertions(+)
> create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts
>
> diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml
> b/Documentation/devicetree/bindings/arm/rockchip.yaml
> index 34865042f4e4..da9cd947abfa 100644
> --- a/Documentation/devicetree/bindings/arm/rockchip.yaml
> +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
> @@ -329,6 +329,11 @@ properties:
>- khadas,edge-v
>- const: rockchip,rk3399
>
> + - description: Leez RK3399 P710
> +items:
> + - const: leez,p710
Is "leez" really the vendor?
Part of me would assume something like
lenovo,leez-p710
So please clarify :-)
And also please make sure the decided vendor is part of the vendor-prefixes
binding in Documentation/devicestree/bindings/vendor-prefixes.yaml
> + - const: rockchip,rk3399
> +
>- description: mqmaker MiQi
> items:
>- const: mqmaker,miqi
> diff --git a/arch/arm64/boot/dts/rockchip/Makefile
> b/arch/arm64/boot/dts/rockchip/Makefile
> index daa2c78e22c3..1f18a9392d15 100644
> --- a/arch/arm64/boot/dts/rockchip/Makefile
> +++ b/arch/arm64/boot/dts/rockchip/Makefile
> @@ -20,6 +20,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-hugsun-x99.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-khadas-edge.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-khadas-edge-captain.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-khadas-edge-v.dtb
> +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-leez-p710.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopc-t4.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-m4.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-neo4.dtb
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts
> b/arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts
> new file mode 100644
> index ..b342f5e8692b
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts
> @@ -0,0 +1,635 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2019 Andy Yan
> + */
> +
> +/dts-v1/;
> +#include
> +#include
> +#include "rk3399.dtsi"
> +#include "rk3399-opp.dtsi"
> +
> +/ {
> + model = "Leez RK3399 P710";
> + compatible = "leez,p710", "rockchip,rk3399";
same comment as above, so maybe:
model = "Lenovo Leez RK3399 P710";
compatible = "lenovo,leez-p710", "rockchip,rk3399";
> +
> + chosen {
> + stdout-path = "serial2:150n8";
> + };
> +
> + clkin_gmac: external-gmac-clock {
> + compatible = "fixed-clock";
> + clock-frequency = <12500>;
> + clock-output-names = "clkin_gmac";
> + #clock-cells = <0>;
> + };
> +
> + sdio_pwrseq: sdio-pwrseq {
> + compatible = "mmc-pwrseq-simple";
> + clocks = < 1>;
> + clock-names = "ext_clock";
> + pinctrl-names = "default";
> + pinctrl-0 = <_enable_h>;
> + reset-gpios = < RK_PB2 GPIO_ACTIVE_LOW>;
> + };
> +
> + dc5v_adp: dc-5v {
> + compatible = "regulator-fixed";
> + regulator-name = "dc5v_adapter";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + };
> +
> + vcc5v0_sys: vcc-sys {
vcc5v0_sys: vcc5v0-sys ?
> + compatible = "regulator-fixed";
> + regulator-name = "vcc5v0_sys";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + vin-supply = <_adp>;
> + };
> +
> + vcc3v3_sys: vcc3v3-sys {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc3v3_sys";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + vin-supply = <_sys>;
> + };
> +
> + vcc5v0_host: vcc5v0-host-regulator {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpio = < RK_PA2 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_host_en>;
> +
[PULL 0/1] xtensa fixes for v5.3
Hi Linus, please pull the following fix for the Xtensa architecture. The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b: Linus 5.3-rc1 (2019-07-21 14:05:38 -0700) are available in the git repository at: git://github.com/jcmvbkbc/linux-xtensa.git tags/xtensa-20190803 for you to fetch changes up to e3cacb73e626d885b8cf24103fed0ae26518e3c4: xtensa: fix build for cores with coprocessors (2019-07-24 17:44:42 -0700) Xtensa fixes for v5.3: - fix build for xtensa cores with coprocessors that was broken by entry/return abstraction patch. Max Filippov (1): xtensa: fix build for cores with coprocessors arch/xtensa/kernel/coprocessor.S | 1 + 1 file changed, 1 insertion(+) -- Thanks. -- Max
[PATCH 1/2] Fix a NULL-ptr-deref bug in ath6kl_usb_alloc_urb_from_pipe
The `ar_usb` field of `ath6kl_usb_pipe_usb_pipe` objects
are initialized to point to the containing `ath6kl_usb` object
according to endpoint descriptors read from the device side, as shown
below in `ath6kl_usb_setup_pipe_resources`:
for (i = 0; i < iface_desc->desc.bNumEndpoints; ++i) {
endpoint = _desc->endpoint[i].desc;
// get the address from endpoint descriptor
pipe_num = ath6kl_usb_get_logical_pipe_num(ar_usb,
endpoint->bEndpointAddress,
);
..
// select the pipe object
pipe = _usb->pipes[pipe_num];
// initialize the ar_usb field
pipe->ar_usb = ar_usb;
}
The driver assumes that the addresses reported in endpoint
descriptors from device side to be complete. If a device is
malicious and does not report complete addresses, it may trigger
NULL-ptr-deref `ath6kl_usb_alloc_urb_from_pipe` and
`ath6kl_usb_free_urb_to_pipe`.
This patch fixes the bug by preventing potential NULL-ptr-deref.
Signed-off-by: Hui Peng
Reported-by: Hui Peng
Reported-by: Mathias Payer
---
drivers/net/wireless/ath/ath6kl/usb.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/net/wireless/ath/ath6kl/usb.c
b/drivers/net/wireless/ath/ath6kl/usb.c
index 4defb7a0330f..53b66e9434c9 100644
--- a/drivers/net/wireless/ath/ath6kl/usb.c
+++ b/drivers/net/wireless/ath/ath6kl/usb.c
@@ -132,6 +132,10 @@ ath6kl_usb_alloc_urb_from_pipe(struct ath6kl_usb_pipe
*pipe)
struct ath6kl_urb_context *urb_context = NULL;
unsigned long flags;
+ /* bail if this pipe is not initialized */
+ if (!pipe->ar_usb)
+ return NULL;
+
spin_lock_irqsave(>ar_usb->cs_lock, flags);
if (!list_empty(>urb_list_head)) {
urb_context =
@@ -150,6 +154,10 @@ static void ath6kl_usb_free_urb_to_pipe(struct
ath6kl_usb_pipe *pipe,
{
unsigned long flags;
+ /* bail if this pipe is not initialized */
+ if (!pipe->ar_usb)
+ return;
+
spin_lock_irqsave(>ar_usb->cs_lock, flags);
pipe->urb_cnt++;
--
2.22.0
Re: [PATCH V2 7/9] vhost: do not use RCU to synchronize MMU notifier with worker
On Sat, Aug 03, 2019 at 05:36:13PM -0400, Michael S. Tsirkin wrote:
> On Fri, Aug 02, 2019 at 02:24:18PM -0300, Jason Gunthorpe wrote:
> > On Fri, Aug 02, 2019 at 10:27:21AM -0400, Michael S. Tsirkin wrote:
> > > On Fri, Aug 02, 2019 at 09:46:13AM -0300, Jason Gunthorpe wrote:
> > > > On Fri, Aug 02, 2019 at 05:40:07PM +0800, Jason Wang wrote:
> > > > > > This must be a proper barrier, like a spinlock, mutex, or
> > > > > > synchronize_rcu.
> > > > >
> > > > >
> > > > > I start with synchronize_rcu() but both you and Michael raise some
> > > > > concern.
> > > >
> > > > I've also idly wondered if calling synchronize_rcu() under the various
> > > > mm locks is a deadlock situation.
> > > >
> > > > > Then I try spinlock and mutex:
> > > > >
> > > > > 1) spinlock: add lots of overhead on datapath, this leads 0
> > > > > performance
> > > > > improvement.
> > > >
> > > > I think the topic here is correctness not performance improvement
> > >
> > > The topic is whether we should revert
> > > commit 7f466032dc9 ("vhost: access vq metadata through kernel virtual
> > > address")
> > >
> > > or keep it in. The only reason to keep it is performance.
> >
> > Yikes, I'm not sure you can ever win against copy_from_user using
> > mmu_notifiers?
>
> Ever since copy_from_user started playing with flags (for SMAP) and
> added speculation barriers there's a chance we can win by accessing
> memory through the kernel address.
You think copy_to_user will be more expensive than the minimum two
atomics required to synchronize with another thread?
> > Also, why can't this just permanently GUP the pages? In fact, where
> > does it put_page them anyhow? Worrying that 7f466 adds a get_user page
> > but does not add a put_page??
You didn't answer this.. Why not just use GUP?
Jason
Re: [PATCH v7 07/20] clk: tegra: clk-periph: Add save and restore support
On 8/3/19 10:01 AM, Sowjanya Komatineni wrote:
On 8/3/19 3:33 AM, Dmitry Osipenko wrote:
03.08.2019 2:51, Sowjanya Komatineni пишет:
On 8/2/19 2:15 PM, Dmitry Osipenko wrote:
02.08.2019 23:32, Sowjanya Komatineni пишет:
On 8/2/19 1:17 PM, Dmitry Osipenko wrote:
02.08.2019 23:13, Dmitry Osipenko пишет:
02.08.2019 21:33, Sowjanya Komatineni пишет:
On 8/2/19 5:38 AM, Dmitry Osipenko wrote:
02.08.2019 2:49, Sowjanya Komatineni пишет:
On 8/1/19 4:19 PM, Sowjanya Komatineni wrote:
On 8/1/19 2:30 PM, Sowjanya Komatineni wrote:
On 8/1/19 1:54 PM, Dmitry Osipenko wrote:
01.08.2019 23:31, Sowjanya Komatineni пишет:
On 8/1/19 1:17 PM, Dmitry Osipenko wrote:
01.08.2019 22:42, Sowjanya Komatineni пишет:
On 8/1/19 12:00 PM, Dmitry Osipenko wrote:
01.08.2019 20:58, Sowjanya Komatineni пишет:
On 7/31/19 4:09 PM, Sowjanya Komatineni wrote:
On 7/31/19 3:44 AM, Dmitry Osipenko wrote:
31.07.2019 12:50, Dmitry Osipenko пишет:
31.07.2019 3:20, Sowjanya Komatineni пишет:
This patch implements save and restore context for
peripheral
fixed
clock ops, peripheral gate clock ops, sdmmc mux
clock
ops, and
peripheral clock ops.
During system suspend, core power goes off and
looses the
settings
of the Tegra CAR controller registers.
So during suspend entry clock and reset state of
peripherals is
saved
and on resume they are restored to have clocks
back to
same
rate and
state as before suspend.
Acked-by: Thierry Reding
Signed-off-by: Sowjanya Komatineni
---
drivers/clk/tegra/clk-periph-fixed.c | 33
drivers/clk/tegra/clk-periph-gate.c | 34
+
drivers/clk/tegra/clk-periph.c | 37
drivers/clk/tegra/clk-sdmmc-mux.c | 28
+++
drivers/clk/tegra/clk.h | 6 ++
5 files changed, 138 insertions(+)
diff --git a/drivers/clk/tegra/clk-periph-fixed.c
b/drivers/clk/tegra/clk-periph-fixed.c
index c088e7a280df..21b24530fa00 100644
--- a/drivers/clk/tegra/clk-periph-fixed.c
+++ b/drivers/clk/tegra/clk-periph-fixed.c
@@ -60,11 +60,44 @@
tegra_clk_periph_fixed_recalc_rate(struct
clk_hw *hw,
return (unsigned long)rate;
}
+static int
tegra_clk_periph_fixed_save_context(struct
clk_hw
*hw)
+{
+ struct tegra_clk_periph_fixed *fixed =
to_tegra_clk_periph_fixed(hw);
+ u32 mask = 1 << (fixed->num % 32);
+
+ fixed->enb_ctx = readl_relaxed(fixed->base +
fixed->regs->enb_reg) &
+ mask;
+ fixed->rst_ctx = readl_relaxed(fixed->base +
fixed->regs->rst_reg) &
+ mask;
+
+ return 0;
+}
+
+static void
tegra_clk_periph_fixed_restore_context(struct
clk_hw
*hw)
+{
+ struct tegra_clk_periph_fixed *fixed =
to_tegra_clk_periph_fixed(hw);
+ u32 mask = 1 << (fixed->num % 32);
+
+ if (fixed->enb_ctx)
+ writel_relaxed(mask, fixed->base +
fixed->regs->enb_set_reg);
+ else
+ writel_relaxed(mask, fixed->base +
fixed->regs->enb_clr_reg);
+
+ udelay(2);
+
+ if (!fixed->rst_ctx) {
+ udelay(5); /* reset propogation delay */
+ writel_relaxed(mask, fixed->base +
fixed->regs->rst_reg);
+ }
+}
+
static const struct clk_ops
tegra_clk_periph_fixed_ops
= {
.is_enabled =
tegra_clk_periph_fixed_is_enabled,
.enable =
tegra_clk_periph_fixed_enable,
.disable =
tegra_clk_periph_fixed_disable,
.recalc_rate =
tegra_clk_periph_fixed_recalc_rate,
+ .save_context =
tegra_clk_periph_fixed_save_context,
+ .restore_context =
tegra_clk_periph_fixed_restore_context,
};
struct clk
*tegra_clk_register_periph_fixed(const
char
*name,
diff --git a/drivers/clk/tegra/clk-periph-gate.c
b/drivers/clk/tegra/clk-periph-gate.c
index 4b31beefc9fc..6ba5b08e0787 100644
--- a/drivers/clk/tegra/clk-periph-gate.c
+++ b/drivers/clk/tegra/clk-periph-gate.c
@@ -25,6 +25,8 @@ static
DEFINE_SPINLOCK(periph_ref_lock);
#define read_rst(gate) \
readl_relaxed(gate->clk_base +
(gate->regs->rst_reg))
+#define write_rst_set(val, gate) \
+ writel_relaxed(val, gate->clk_base +
(gate->regs->rst_set_reg))
#define write_rst_clr(val, gate) \
writel_relaxed(val, gate->clk_base +
(gate->regs->rst_clr_reg))
@@ -110,10 +112,42 @@ static void
clk_periph_disable(struct
clk_hw *hw)
spin_unlock_irqrestore(_ref_lock, flags);
}
+static int
clk_periph_gate_save_context(struct
clk_hw
*hw)
+{
+ struct tegra_clk_periph_gate *gate =
to_clk_periph_gate(hw);
+
+ gate->clk_state_ctx = read_enb(gate) &
periph_clk_to_bit(gate);
+ gate->rst_state_ctx = read_rst(gate) &
periph_clk_to_bit(gate);
+
+ return 0;
+}
+
+static void clk_periph_gate_restore_context(struct
clk_hw
*hw)
+{
+ struct tegra_clk_periph_gate *gate =
to_clk_periph_gate(hw);
+
+ if (gate->clk_state_ctx)
+ write_enb_set(periph_clk_to_bit(gate), gate);
+ else
+ write_enb_clr(periph_clk_to_bit(gate), gate);
+
+ udelay(5);
+
+ if (!(gate->flags & TEGRA_PERIPH_NO_RESET) &&
+ !(gate->flags &
Re: [PATCH v6] PM / wakeup: show wakeup sources stats in sysfs
On Thu, Aug 1, 2019 at 3:10 PM Rafael J. Wysocki wrote: > > On Thu, Aug 1, 2019 at 11:45 PM Tri Vo wrote: > > > > On Thu, Aug 1, 2019 at 1:23 PM Stephen Boyd wrote: > > > > > > Quoting Tri Vo (2019-08-01 12:50:25) > > > > On Wed, Jul 31, 2019 at 4:45 PM Stephen Boyd > > > > wrote: > > > > > > > > > > Quoting Rafael J. Wysocki (2019-07-31 16:10:38) > > > > > > On Thu, Aug 1, 2019 at 12:59 AM Tri Vo wrote: > > > > > > > > > > > > > > > > > > > > > > > So why wouldn't something like this suffice: > > > > > > > > > > > > > > > > dev = device_create_with_groups(wakeup_class, parent, MKDEV(0, > > > > > > > > 0), ws, > > > > > > > > wakeup_source_groups, > > > > > > > > "wakeup:%s", ws->name); > > > > > > > > > > > > > > > > ? > > > > > > > > > > > > > > ws->name is inherited from the device name. IIUC device names are > > > > > > > not > > > > > > > guaranteed to be unique. So if different devices with the same > > > > > > > name > > > > > > > register wakeup sources, there is an error. > > > > > > > > > > > > OK > > > > > > > > > > > > So I guess the names are retained for backwards compatibility with > > > > > > existing user space that may be using them? > > > > > > > > > > > > That's kind of fair enough, but having two different identification > > > > > > schemes for wakeup sources will end up confusing. > > > > > > > > > > I understand your concern about the IDA now. Thanks for clarifying. > > > > > > > > > > How about we name the devices 'wakeupN' with the IDA when they're > > > > > registered with a non-NULL device pointer and then name them whatever > > > > > the name argument is when the device pointer is NULL. If we have this, > > > > > we should be able to drop the name attribute in sysfs and figure out > > > > > the > > > > > name either by looking at the device name in /sys/class/wakeup/ if it > > > > > isn't 'wakeupN', or follow the symlink to the device in /sys/devices/ > > > > > and look at the parent device name there. > > > > > > > > This makes it difficult for userspace to query the name a wakeup > > > > source, as it now has to first figure out if a wakeup source is > > > > associated with a device or not. The criteria for that is also > > > > awkward, userspase has to check if directory path contains "wakeupN", > > > > then it's a virtual wakeup source. > > > > > > I think you mean if it doesn't match wakeupN then it's a virtual wakeup > > > source? > > > > Yes > > > > > > > > > > > IMO it's cleaner to consistently have /sys/class/wakeup/wakeupN/name > > > > for every wakeup source. > > > > > > I don't find it awkward or difficult. Just know what the name of the > > > /sys/class/wakeup/ path is and then extract the name from there if it > > > doesn't match wakeupN, otherwise read the 'device' symlink and run it > > > through basename. > > > > The concern was that having both "id" and "name" around might be > > confusing. I don't think that making the presence of "name" > > conditional helps here. And we have to maintain additional logic in > > both kernel and userspace to support this. > > > > Also, say, userspace grabs a wakelock named "wakeup0". In the current > > patch, this results in a name collision and an error. Even assuming > > that userspace doesn't have ill intent, it still needs to be aware of > > "wakeupN" naming pattern to avoid this error condition. > > > > All wakeup sources in the /sys/class/wakeup/ are in the same namespace > > regardless of where they originate from, i.e. we have to either (1) > > inspect the name of a wakeup source and make sure it's unique before > > using it as a directory name OR (2) generate the directory name on > > behalf of whomever is registering a wakeup source, which I think is a > > much simpler solution. > > OK, whatever. > > Let's use the IDA as originally proposed and retain the names for > backwards compatibility only. > > Maybe just allocate the ID at the wakeup source object creation time > already (ISTR that you did that before attempting to create a virtual > device for the wakeup source). Yes, allocating the ID when creating the wakeup source object makes sense. However, kernel/power/wakelock.c allocates its wakeup sources manually. I imagine we don't want these IDs to be created in more than one place. Making wakelock.c only use wakeup_source_*() family of functions when dealing with wakeup sources might be a worthwhile change though. Then we won't have to worry about ID allocation in wakelock.c. WDYT? Also, it sounds like we all agree with "/sys/class/wakeup/wsN/" path and "/sys/class/wakeup/wsN/name" attribute for each wakeup source, right?
Re: [PATCH v3 2/2] mm,thp: Add experimental config option RO_EXEC_FILEMAP_HUGE_FAULT_THP
On 8/1/19 6:36 AM, Kirill A. Shutemov wrote:
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
-#define HPAGE_PMD_SHIFT PMD_SHIFT
-#define HPAGE_PMD_SIZE ((1UL) << HPAGE_PMD_SHIFT)
-#define HPAGE_PMD_MASK (~(HPAGE_PMD_SIZE - 1))
-
-#define HPAGE_PUD_SHIFT PUD_SHIFT
-#define HPAGE_PUD_SIZE ((1UL) << HPAGE_PUD_SHIFT)
-#define HPAGE_PUD_MASK (~(HPAGE_PUD_SIZE - 1))
+#define HPAGE_PMD_SHIFTPMD_SHIFT
+#define HPAGE_PMD_SIZE ((1UL) << HPAGE_PMD_SHIFT)
+#define HPAGE_PMD_OFFSET (HPAGE_PMD_SIZE - 1)
+#define HPAGE_PMD_MASK (~(HPAGE_PMD_OFFSET))
+
+#define HPAGE_PUD_SHIFTPUD_SHIFT
+#define HPAGE_PUD_SIZE ((1UL) << HPAGE_PUD_SHIFT)
+#define HPAGE_PUD_OFFSET (HPAGE_PUD_SIZE - 1)
+#define HPAGE_PUD_MASK (~(HPAGE_PUD_OFFSET))
OFFSET vs MASK semantics can be confusing without reading the definition.
We don't have anything similar for base page size, right (PAGE_OFFSET is
completely different thing :P)?
I came up with the OFFSET definitions, the MASK definitions already existed
in huge_mm.h, e.g.:
#define HPAGE_PUD_MASK (~(HPAGE_PUD_SIZE - 1))
Is there different terminology you'd prefer to see me use here to clarify
this?
+#ifdef CONFIG_RO_EXEC_FILEMAP_HUGE_FAULT_THP
+extern vm_fault_t filemap_huge_fault(struct vm_fault *vmf,
+ enum page_entry_size pe_size);
+#endif
+
No need for #ifdef here.
I wanted to avoid referencing an extern that wouldn't exist if the config
option wasn't set; I can remove it.
+
+#ifndefCONFIG_RO_EXEC_FILEMAP_HUGE_FAULT_THP
if (PageSwapBacked(page)) {
__mod_node_page_state(page_pgdat(page), NR_SHMEM, -nr);
if (PageTransHuge(page))
@@ -206,6 +208,13 @@ static void unaccount_page_cache_page(struct address_space
*mapping,
} else {
VM_BUG_ON_PAGE(PageTransHuge(page), page);
}
+#else
+ if (PageSwapBacked(page))
+ __mod_node_page_state(page_pgdat(page), NR_SHMEM, -nr);
+
+ if (PageTransHuge(page))
+ __dec_node_page_state(page, NR_SHMEM_THPS);
+#endif
Again, no need for #ifdef: the new definition should be fine for
everybody.
OK, I can do that; I didn't want to unnecessarily eliminate the
VM_BUG_ON_PAGE(PageTransHuge(page)) call for everyone given this
is CONFIG experimental code.
PageCompound() and PageTransCompound() are the same thing if THP is
enabled at compile time.
PageHuge() check here is looking out of place. I don't thing we can ever
will see hugetlb pages here.
What I'm trying to do is sanity check that what the cache contains is a THP
page. I added the PageHuge() check simply because PageTransCompound() is true
for both THP and hugetlbfs pages, and there's no routine that returns true JUST
for THP pages; perhaps there should be?
+* + the enbry is a page page with an order other than
Typo.
Thanks, fixed.
+*HPAGE_PMD_ORDER
If you see unexpected page order in page cache, something went horribly
wrong, right?
This routine's main function other than validation is to make sure the page
cache has not been polluted between when we go out to read the large page and
when the page is added to the cache (more on that coming up.) For example, the
way I was able to tell readahead() was polluting future possible THP mappings is
because after a buffered read I would typically see 52 (the readahead size)
PAGESIZE pages for the next 2M range in the page cache.
+* + the page's index is not what we expect it to be
Same here.
Same rationale.
+* + the page is not up-to-date
+* + the page is unlocked
Confused here.
These should never be true, but I wanted to double check for them anyway. I can
eliminate the checks if we are satisfied these states can "never" happen for a
cached page.
Do you expect caller to lock page before the check? If so, state it in the
comment for the function.
It's my understanding that pages in the page cache should be locked, so I wanted
to check for that.
This routine is validating entries we find in the page cache to see whether they
are conflicts or valid cached THP pages.
Wow. That's unreadable. Can we rewrite it something like (commenting each
check):
I can definitely break it down into multiple checks; it is a bit dense, thus the
comment but you're correct, it will read better if broken down more.
You also need to check that VMA alignment is suitable for huge pages.
See transhuge_vma_suitable().
I don't really care if the start of the VMA is suitable, just whether I can map
the current faulting page with a THP. As far as I know, there's nothing wrong
with mapping all the pages before the VMA hits a properly aligned bound with
PAGESIZE pages and then aligned chunks in the middle with THP.
+ if (unlikely(!(PageCompound(new_page {
How can it happen?
That check was
Re: [PATCH V2 7/9] vhost: do not use RCU to synchronize MMU notifier with worker
On Thu, Aug 01, 2019 at 04:06:13AM -0400, Jason Wang wrote:
> On 2019/8/1 上午2:29, Michael S. Tsirkin wrote:
> > On Wed, Jul 31, 2019 at 04:46:53AM -0400, Jason Wang wrote:
> >> We used to use RCU to synchronize MMU notifier with worker. This leads
> >> calling synchronize_rcu() in invalidate_range_start(). But on a busy
> >> system, there would be many factors that may slow down the
> >> synchronize_rcu() which makes it unsuitable to be called in MMU
> >> notifier.
> >>
> >> A solution is SRCU but its overhead is obvious with the expensive full
> >> memory barrier. Another choice is to use seqlock, but it doesn't
> >> provide a synchronization method between readers and writers. The last
> >> choice is to use vq mutex, but it need to deal with the worst case
> >> that MMU notifier must be blocked and wait for the finish of swap in.
> >>
> >> So this patch switches use a counter to track whether or not the map
> >> was used. The counter was increased when vq try to start or finish
> >> uses the map. This means, when it was even, we're sure there's no
> >> readers and MMU notifier is synchronized. When it was odd, it means
> >> there's a reader we need to wait it to be even again then we are
> >> synchronized. To avoid full memory barrier, store_release +
> >> load_acquire on the counter is used.
> >
> > Unfortunately this needs a lot of review and testing, so this can't make
> > rc2, and I don't think this is the kind of patch I can merge after rc3.
> > Subtle memory barrier tricks like this can introduce new bugs while they
> > are fixing old ones.
>
> I admit the patch is tricky. Some questions:
>
> - Do we must address the case of e.g swap in? If not, a simple
> vhost_work_flush() instead of synchronize_rcu() may work.
> - Having some hard thought, I think we can use seqlock, it looks
> to me smp_wmb() is in write_segcount_begin() is sufficient, we don't
> care vq->map read before smp_wmb(), and for the other we all have
> good data devendency so smp_wmb() in the write_seqbegin_end() is
> sufficient.
If we need an mb in the begin() we can switch to
dependent_ptr_mb. if you need me to fix it up
and repost, let me know.
Why isn't it a problem if the map is
accessed outside the lock?
> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> index db2c81cb1e90..6d9501303258 100644
> --- a/drivers/vhost/vhost.c
> +++ b/drivers/vhost/vhost.c
> @@ -363,39 +363,29 @@ static bool vhost_map_range_overlap(struct vhost_uaddr
> *uaddr,
>
> static void inline vhost_vq_access_map_begin(struct vhost_virtqueue *vq)
> {
> - int ref = READ_ONCE(vq->ref);
> -
> - smp_store_release(>ref, ref + 1);
> - /* Make sure ref counter is visible before accessing the map */
> - smp_load_acquire(>ref);
> + write_seqcount_begin(>seq);
> }
>
> static void inline vhost_vq_access_map_end(struct vhost_virtqueue *vq)
> {
> - int ref = READ_ONCE(vq->ref);
> -
> - /* Make sure vq access is done before increasing ref counter */
> - smp_store_release(>ref, ref + 1);
> + write_seqcount_end(>seq);
> }
>
> static void inline vhost_vq_sync_access(struct vhost_virtqueue *vq)
> {
> - int ref;
> + unsigned int ret;
>
> /* Make sure map change was done before checking ref counter */
> smp_mb();
> -
> - ref = READ_ONCE(vq->ref);
> - if (ref & 0x1) {
> - /* When ref change, we are sure no reader can see
> + ret = raw_read_seqcount(>seq);
> + if (ret & 0x1) {
> + /* When seq changes, we are sure no reader can see
>* previous map */
> - while (READ_ONCE(vq->ref) == ref) {
> - set_current_state(TASK_RUNNING);
> + while (raw_read_seqcount(>seq) == ret)
> schedule();
So why do we set state here? And should not we
check need_sched?
> - }
> }
> - /* Make sure ref counter was checked before any other
> - * operations that was dene on map. */
> + /* Make sure seq was checked before any other operations that
> + * was dene on map. */
> smp_mb();
> }
>
> @@ -691,7 +681,7 @@ void vhost_dev_init(struct vhost_dev *dev,
> vq->indirect = NULL;
> vq->heads = NULL;
> vq->dev = dev;
> - vq->ref = 0;
> + seqcount_init(>seq);
> mutex_init(>mutex);
> spin_lock_init(>mmu_lock);
> vhost_vq_reset(dev, vq);
> diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
> index 3d10da0ae511..1a705e181a84 100644
> --- a/drivers/vhost/vhost.h
> +++ b/drivers/vhost/vhost.h
> @@ -125,7 +125,7 @@ struct vhost_virtqueue {
>*/
> struct vhost_uaddr uaddrs[VHOST_NUM_ADDRS];
> #endif
> - int ref;
> + seqcount_t seq;
> const struct vhost_umem_node *meta_iotlb[VHOST_NUM_ADDRS];
>
> struct file *kick;
> --
> 2.18.1
>
> >
> >
> >
> >
> >
> >>
> >> Consider the read critical section is pretty
Re: [PATCH 4.19 21/32] vhost_net: fix possible infinite loop
Hi!
> This makes it possible to trigger a infinite while..continue loop
> through the co-opreation of two VMs like:
>
> 1) Malicious VM1 allocate 1 byte rx buffer and try to slow down the
>vhost process as much as possible e.g using indirect descriptors or
>other.
> 2) Malicious VM2 generate packets to VM1 as fast as possible
>
> Fixing this by checking against weight at the end of RX and TX
> loop. This also eliminate other similar cases when:
>
> - userspace is consuming the packets in the meanwhile
> - theoretical TOCTOU attack if guest moving avail index back and forth
> to hit the continue after vhost find guest just add new buffers
>
> This addresses CVE-2019-3900.
>
> @@ -551,7 +551,7 @@ static void handle_tx_copy(struct vhost_
> int err;
> int sent_pkts = 0;
>
> - for (;;) {
> + do {
> bool busyloop_intr = false;
>
> head = get_tx_bufs(net, nvq, , , , ,
> @@ -592,9 +592,7 @@ static void handle_tx_copy(struct vhost_
>err, len);
> if (++nvq->done_idx >= VHOST_NET_BATCH)
> vhost_net_signal_used(nvq);
> - if (vhost_exceeds_weight(vq, ++sent_pkts, total_len))
> - break;
> - }
> + } while (likely(!vhost_exceeds_weight(vq, ++sent_pkts, total_len)));
>
> vhost_net_signal_used(nvq);
> }
So this part does not really change anything, right?
> @@ -618,7 +616,7 @@ static void handle_tx_zerocopy(struct vh
> bool zcopy_used;
> int sent_pkts = 0;
>
> - for (;;) {
> + do {
> bool busyloop_intr;
>
> /* Release DMAs done buffers first */
> @@ -693,10 +691,7 @@ static void handle_tx_zerocopy(struct vh
> else
> vhost_zerocopy_signal_used(net, vq);
> vhost_net_tx_packet(net);
> - if (unlikely(vhost_exceeds_weight(vq, ++sent_pkts,
> - total_len)))
> - break;
> - }
> + } while (likely(!vhost_exceeds_weight(vq, ++sent_pkts, total_len)));
> }
>
> /* Expects to be always run from workqueue - which acts as
Neither does this. Equivalent code. Changelog says it fixes something
for the transmit so... is that intentional?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: [PATCH V2 7/9] vhost: do not use RCU to synchronize MMU notifier with worker
On Fri, Aug 02, 2019 at 02:24:18PM -0300, Jason Gunthorpe wrote:
> On Fri, Aug 02, 2019 at 10:27:21AM -0400, Michael S. Tsirkin wrote:
> > On Fri, Aug 02, 2019 at 09:46:13AM -0300, Jason Gunthorpe wrote:
> > > On Fri, Aug 02, 2019 at 05:40:07PM +0800, Jason Wang wrote:
> > > > > This must be a proper barrier, like a spinlock, mutex, or
> > > > > synchronize_rcu.
> > > >
> > > >
> > > > I start with synchronize_rcu() but both you and Michael raise some
> > > > concern.
> > >
> > > I've also idly wondered if calling synchronize_rcu() under the various
> > > mm locks is a deadlock situation.
> > >
> > > > Then I try spinlock and mutex:
> > > >
> > > > 1) spinlock: add lots of overhead on datapath, this leads 0 performance
> > > > improvement.
> > >
> > > I think the topic here is correctness not performance improvement
> >
> > The topic is whether we should revert
> > commit 7f466032dc9 ("vhost: access vq metadata through kernel virtual
> > address")
> >
> > or keep it in. The only reason to keep it is performance.
>
> Yikes, I'm not sure you can ever win against copy_from_user using
> mmu_notifiers?
Ever since copy_from_user started playing with flags (for SMAP) and
added speculation barriers there's a chance we can win by accessing
memory through the kernel address.
Another reason would be to access it from e.g. softirq
context. copy_from_user will only work if the
correct mmu is active.
> The synchronization requirements are likely always
> more expensive unless large and scattered copies are being done..
>
> The rcu is about the only simple approach that could be less
> expensive, and that gets back to the question if you can block an
> invalidate_start_range in synchronize_rcu or not..
>
> So, frankly, I'd revert it until someone could prove the rcu solution is
> OK..
I have it all disabled at compile time, so reverting isn't urgent
anymore. I'll wait a couple more days to decide what's cleanest.
> BTW, how do you get copy_from_user to work outside a syscall?
By switching to the correct mm.
>
> Also, why can't this just permanently GUP the pages? In fact, where
> does it put_page them anyhow? Worrying that 7f466 adds a get_user page
> but does not add a put_page??
>
> Jason
[PATCH] Fix lines greater than 80 characters
Fix checkpatch error for "line over 80 characters"
Signed-off-by: z3phyr
---
drivers/staging/pi433/pi433_if.h | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/pi433/pi433_if.h b/drivers/staging/pi433/pi433_if.h
index 9feb95c431cb..74b6e2513813 100644
--- a/drivers/staging/pi433/pi433_if.h
+++ b/drivers/staging/pi433/pi433_if.h
@@ -115,11 +115,14 @@ struct pi433_rx_cfg {
__u8bw_exponent;/* during AFC: 0x8b */
enum dagc dagc;
- /* packet format */
+/* packet format */
enum option_on_off enable_sync;
- enum option_on_off enable_length_byte; /* should be used in
combination with sync, only */
- enum address_filtering enable_address_filtering; /* operational with
sync, only */
- enum option_on_off enable_crc; /* only operational,
if sync on and fixed length or length byte is used */
+/* should be used in combination with sync, only */
+ enum option_on_off enable_length_byte;
+ /* operational with sync, only */
+ enum address_filtering enable_address_filtering;
+ /* only operational, if sync on and fixed length or length byte is used
*/
+ enum option_on_off enable_crc;
__u8sync_length;
__u8fixed_message_length;
@@ -132,10 +135,14 @@ struct pi433_rx_cfg {
#define PI433_IOC_MAGIC'r'
-#define PI433_IOC_RD_TX_CFG_IOR(PI433_IOC_MAGIC, PI433_TX_CFG_IOCTL_NR,
char[sizeof(struct pi433_tx_cfg)])
-#define PI433_IOC_WR_TX_CFG_IOW(PI433_IOC_MAGIC, PI433_TX_CFG_IOCTL_NR,
char[sizeof(struct pi433_tx_cfg)])
+#define PI433_IOC_RD_TX_CFG_IOR(PI433_IOC_MAGIC, PI433_TX_CFG_IOCTL_NR,\
+char[sizeof(struct pi433_tx_cfg)])
+#define PI433_IOC_WR_TX_CFG_IOW(PI433_IOC_MAGIC, PI433_TX_CFG_IOCTL_NR,\
+char[sizeof(struct pi433_tx_cfg)])
-#define PI433_IOC_RD_RX_CFG_IOR(PI433_IOC_MAGIC, PI433_RX_CFG_IOCTL_NR,
char[sizeof(struct pi433_rx_cfg)])
-#define PI433_IOC_WR_RX_CFG_IOW(PI433_IOC_MAGIC, PI433_RX_CFG_IOCTL_NR,
char[sizeof(struct pi433_rx_cfg)])
+#define PI433_IOC_RD_RX_CFG_IOR(PI433_IOC_MAGIC, PI433_RX_CFG_IOCTL_NR,\
+char[sizeof(struct pi433_rx_cfg)])
+#define PI433_IOC_WR_RX_CFG_IOW(PI433_IOC_MAGIC, PI433_RX_CFG_IOCTL_NR,\
+char[sizeof(struct pi433_rx_cfg)])
#endif /* PI433_H */
--
2.22.0
Re: [PATCH 4.19 17/32] iommu/vt-d: Dont queue_iova() if there is no flush queue
Hi!
> --- a/drivers/iommu/intel-iommu.c
> +++ b/drivers/iommu/intel-iommu.c
> @@ -3721,7 +3721,7 @@ static void intel_unmap(struct device *d
>
> freelist = domain_unmap(domain, start_pfn, last_pfn);
>
> - if (intel_iommu_strict) {
> + if (intel_iommu_strict || !has_iova_flush_queue(>iovad)) {
> iommu_flush_iotlb_psi(iommu, domain, start_pfn,
> nrpages, !freelist, 0);
> /* free iova */
> --- a/drivers/iommu/iova.c
> +++ b/drivers/iommu/iova.c
> @@ -65,9 +65,14 @@ init_iova_domain(struct iova_domain *iov
> }
> EXPORT_SYMBOL_GPL(init_iova_domain);
>
> +bool has_iova_flush_queue(struct iova_domain *iovad)
> +{
> + return !!iovad->fq;
Should this be READ_ONCE()?
> @@ -100,13 +106,17 @@ int init_iova_flush_queue(struct iova_do
> for_each_possible_cpu(cpu) {
> struct iova_fq *fq;
>
> - fq = per_cpu_ptr(iovad->fq, cpu);
> + fq = per_cpu_ptr(queue, cpu);
> fq->head = 0;
> fq->tail = 0;
>
> spin_lock_init(>lock);
> }
>
> + smp_wmb();
> +
> + iovad->fq = queue;
> +
Could we have a comment why the barrier is needed, and perhaps there
should be oposing smp_rmb() somewhere? Does this need to be
WRITE_ONCE() as it is racing against reader?
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: [GIT PULL] xfs: cleanups for 5.3-rc3
On Sat, Aug 03, 2019 at 10:46:38AM -0700, Linus Torvalds wrote: > On Sat, Aug 3, 2019 at 9:33 AM Darrick J. Wong wrote: > > > > Here are a couple more bug fixes that trickled in since -rc1. It's > > survived the usual xfstests runs and merges cleanly with this morning's > > master. Please let me know if anything strange happens. > > Hmm. This was tagged, but not signed like your usual tags are. > > I've pulled it (I don't _require_ signed tags from kernel.org), but > would generally be much happier if I saw the signing too... D'oh. Sorry, I forgot to git tag -a. :( /me rummages around to see if there's a way to configure git to sign always... --D > Thanks, > > Linus
Re: [PATCH 09/20] ext4: Initialize timestamps limits
On Sat, Aug 3, 2019 at 6:03 PM Theodore Y. Ts'o wrote: > > On Sat, Aug 03, 2019 at 11:30:22AM +0200, Arnd Bergmann wrote: > > > > I see in the ext4 code that we always try to expand i_extra_size > > to s_want_extra_isize in ext4_mark_inode_dirty(), and that > > s_want_extra_isize is always at least s_min_extra_isize, so > > we constantly try to expand the inode to fit. > > Yes, we *try*. But we may not succeed. There may actually be a > problem here if the cause is due to there simply is no space in the > external xattr block, so we might try and try every time we try to > modify that inode, and it would be a performance mess. If it's due to > there being no room in the current transaction, then it's highly > likely it will succeed the next time. > > > Did older versions of ext4 or ext3 ignore s_min_extra_isize > > when creating inodes despite > > EXT4_FEATURE_RO_COMPAT_EXTRA_ISIZE, > > or is there another possibility I'm missing? > > s_min_extra_isize could get changed in order to make room for some new > file system feature --- such as extended timestamps. Ok, that explains it. I assumed s_min_extra_isize was meant to not be modifiable, and did not find a way to change it using the kernel or tune2fs, but now I can see that debugfs can set it. > If you want to pretend that file systems never get upgraded, then life > is much simpler. The general approach is that for less-sophisticated > customers (e.g., most people running enterprise distros) file system > upgrades are not a thing. But for sophisticated users, we do try to > make thing work for people who are aware of the risks / caveats / > rough edges. Google won't have been able to upgrade thousands and > thousands of servers in data centers all over the world if we limited > ourselves to Red Hat's support restrictions. Backup / reformat / > restore really isn't a practical rollout strategy for many exabytes of > file systems. > > It sounds like your safety checks / warnings are mostly targeted at > low-information customers, no? Yes, that seems like a reasonable compromise: just warn based on s_min_extra_isize, and assume that anyone who used debugfs to set s_min_extra_isize to a higher value from an ext3 file system during the migration to ext4 was aware of the risks already. That leaves the question of what we should set the s_time_gran and s_time_max to on a superblock with s_min_extra_isize<16 and s_want_extra_isize>=16. If we base it on s_min_extra_isize, we never try to set a timestamp later than 2038 and so will never fail, but anyone with a grandfathered s_min_extra_isize from ext3 won't be able to set extended timestamps on any files any more. Based on s_want_extra_isize we would keep the current behavior, but could add a custom warning in the ext4 code about the small s_min_extra_isize indicating a theoretical problem. Arnd
Re: [PATCH] cpuidle-haltpoll: Enable kvm guest polling when dedicated physical CPUs are available
On Thu, Aug 01, 2019 at 06:54:49PM +0200, Paolo Bonzini wrote: > On 01/08/19 18:51, Rafael J. Wysocki wrote: > > On 8/1/2019 9:06 AM, Wanpeng Li wrote: > >> From: Wanpeng Li > >> > >> The downside of guest side polling is that polling is performed even > >> with other runnable tasks in the host. However, even if poll in kvm > >> can aware whether or not other runnable tasks in the same pCPU, it > >> can still incur extra overhead in over-subscribe scenario. Now we can > >> just enable guest polling when dedicated pCPUs are available. > >> > >> Cc: Rafael J. Wysocki > >> Cc: Paolo Bonzini > >> Cc: Radim Krčmář > >> Cc: Marcelo Tosatti > >> Signed-off-by: Wanpeng Li > > > > Paolo, Marcelo, any comments? > > Yes, it's a good idea. > > Acked-by: Paolo Bonzini > > Paolo I think KVM_HINTS_REALTIME is being abused somewhat. It has no clear meaning and used in different locations for different purposes. For example, i think that using pv queued spinlocks and haltpoll is a desired scenario, which the patch below disallows. Wanpeng Li, currently the driver does not autoload. So polling in the guest has to be enabled manually. Isnt that sufficient?
Re: [PULL REQUEST] i2c for 5.3
The pull request you sent on Sat, 3 Aug 2019 21:02:06 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git > i2c/for-current-fixed has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/cf6c8aef16cc0cd15e91a930befd8e312d5703f5 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
[PATCH v6 2/3][v4.9.y] infiniband: fix race condition between infiniband mlx4, mlx5 driver and core dumping
This patch is the extension of following upstream commit to fix
the race condition between get_task_mm() and core dumping
for IB->mlx4 and IB->mlx5 drivers:
commit 04f5866e41fb ("coredump: fix race condition between
mmget_not_zero()/get_task_mm() and core dumping")'
Thanks to Jason for pointing this.
Signed-off-by: Ajay Kaher
Reviewed-by: Jason Gunthorpe
---
drivers/infiniband/hw/mlx4/main.c | 4 +++-
drivers/infiniband/hw/mlx5/main.c | 3 +++
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/mlx4/main.c
b/drivers/infiniband/hw/mlx4/main.c
index 8d59a59..7ccf722 100644
--- a/drivers/infiniband/hw/mlx4/main.c
+++ b/drivers/infiniband/hw/mlx4/main.c
@@ -1172,6 +1172,8 @@ static void mlx4_ib_disassociate_ucontext(struct
ib_ucontext *ibcontext)
* mlx4_ib_vma_close().
*/
down_write(_mm->mmap_sem);
+ if (!mmget_still_valid(owning_mm))
+ goto skip_mm;
for (i = 0; i < HW_BAR_COUNT; i++) {
vma = context->hw_bar_info[i].vma;
if (!vma)
@@ -1190,7 +1192,7 @@ static void mlx4_ib_disassociate_ucontext(struct
ib_ucontext *ibcontext)
/* context going to be destroyed, should not access ops any
more */
context->hw_bar_info[i].vma->vm_ops = NULL;
}
-
+skip_mm:
up_write(_mm->mmap_sem);
mmput(owning_mm);
put_task_struct(owning_process);
diff --git a/drivers/infiniband/hw/mlx5/main.c
b/drivers/infiniband/hw/mlx5/main.c
index b1daf5c..f94df0e 100644
--- a/drivers/infiniband/hw/mlx5/main.c
+++ b/drivers/infiniband/hw/mlx5/main.c
@@ -1307,6 +1307,8 @@ static void mlx5_ib_disassociate_ucontext(struct
ib_ucontext *ibcontext)
* mlx5_ib_vma_close.
*/
down_write(_mm->mmap_sem);
+ if (!mmget_still_valid(owning_mm))
+ goto skip_mm;
list_for_each_entry_safe(vma_private, n, >vma_private_list,
list) {
vma = vma_private->vma;
@@ -1321,6 +1323,7 @@ static void mlx5_ib_disassociate_ucontext(struct
ib_ucontext *ibcontext)
list_del(_private->list);
kfree(vma_private);
}
+skip_mm:
up_write(_mm->mmap_sem);
mmput(owning_mm);
put_task_struct(owning_process);
--
2.7.4
[PATCH v6 0/3] [v4.9.y] coredump: fix race condition between mmget_not_zero()/get_task_mm() and core dumping
coredump: fix race condition between mmget_not_zero()/get_task_mm() and core dumping [PATCH v5 1/3]: Backporting of commit 04f5866e41fb70690e28397487d8bd8eea7d712a upstream. [PATCH v5 2/3]: Extension of commit 04f5866e41fb to fix the race condition between get_task_mm() and core dumping for IB->mlx4 and IB->mlx5 drivers. [PATCH v5 3/3] Backporting of commit 59ea6d06cfa9247b586a695c21f94afa7183af74 upstream. [diff from v5]: - Recreated [PATCH v6 1/3], to solve patch apply error.
[PATCH v6 1/3] [v4.9.y] coredump: fix race condition between mmget_not_zero()/get_task_mm() and core dumping
From: Andrea Arcangeli
commit 04f5866e41fb70690e28397487d8bd8eea7d712a upstream.
The core dumping code has always run without holding the mmap_sem for
writing, despite that is the only way to ensure that the entire vma
layout will not change from under it. Only using some signal
serialization on the processes belonging to the mm is not nearly enough.
This was pointed out earlier. For example in Hugh's post from Jul 2017:
https://lkml.kernel.org/r/alpine.LSU.2.11.1707191716030.2055@eggly.anvils
"Not strictly relevant here, but a related note: I was very surprised
to discover, only quite recently, how handle_mm_fault() may be called
without down_read(mmap_sem) - when core dumping. That seems a
misguided optimization to me, which would also be nice to correct"
In particular because the growsdown and growsup can move the
vm_start/vm_end the various loops the core dump does around the vma will
not be consistent if page faults can happen concurrently.
Pretty much all users calling mmget_not_zero()/get_task_mm() and then
taking the mmap_sem had the potential to introduce unexpected side
effects in the core dumping code.
Adding mmap_sem for writing around the ->core_dump invocation is a
viable long term fix, but it requires removing all copy user and page
faults and to replace them with get_dump_page() for all binary formats
which is not suitable as a short term fix.
For the time being this solution manually covers the places that can
confuse the core dump either by altering the vma layout or the vma flags
while it runs. Once ->core_dump runs under mmap_sem for writing the
function mmget_still_valid() can be dropped.
Allowing mmap_sem protected sections to run in parallel with the
coredump provides some minor parallelism advantage to the swapoff code
(which seems to be safe enough by never mangling any vma field and can
keep doing swapins in parallel to the core dumping) and to some other
corner case.
In order to facilitate the backporting I added "Fixes: 86039bd3b4e6"
however the side effect of this same race condition in /proc/pid/mem
should be reproducible since before 2.6.12-rc2 so I couldn't add any
other "Fixes:" because there's no hash beyond the git genesis commit.
Because find_extend_vma() is the only location outside of the process
context that could modify the "mm" structures under mmap_sem for
reading, by adding the mmget_still_valid() check to it, all other cases
that take the mmap_sem for reading don't need the new check after
mmget_not_zero()/get_task_mm(). The expand_stack() in page fault
context also doesn't need the new check, because all tasks under core
dumping are frozen.
Link: http://lkml.kernel.org/r/20190325224949.11068-1-aarca...@redhat.com
Fixes: 86039bd3b4e6 ("userfaultfd: add new syscall to provide memory
externalization")
Signed-off-by: Andrea Arcangeli
Reported-by: Jann Horn
Suggested-by: Oleg Nesterov
Acked-by: Peter Xu
Reviewed-by: Mike Rapoport
Reviewed-by: Oleg Nesterov
Reviewed-by: Jann Horn
Acked-by: Jason Gunthorpe
Acked-by: Michal Hocko
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
[aka...@vmware.com: stable 4.9 backport
- handle binder_update_page_range - mho...@suse.com]
Signed-off-by: Ajay Kaher
---
drivers/android/binder.c | 6 ++
fs/proc/task_mmu.c | 18 ++
fs/userfaultfd.c | 9 +
include/linux/mm.h | 20
mm/mmap.c| 6 +-
5 files changed, 58 insertions(+), 1 deletion(-)
diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index 29632a6..8056759 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -581,6 +581,12 @@ static int binder_update_page_range(struct binder_proc
*proc, int allocate,
if (mm) {
down_write(>mmap_sem);
+ if (!mmget_still_valid(mm)) {
+ if (allocate == 0)
+ goto free_range;
+ goto err_no_vma;
+ }
+
vma = proc->vma;
if (vma && mm != proc->vma_vm_mm) {
pr_err("%d: vma mm and task mm mismatch\n",
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 5138e78..4b207b1 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -1057,6 +1057,24 @@ static ssize_t clear_refs_write(struct file *file, const
char __user *buf,
count = -EINTR;
goto out_mm;
}
+ /*
+* Avoid to modify vma->vm_flags
+* without locked ops while the
+* coredump reads the vm_flags.
+*/
+ if (!mmget_still_valid(mm)) {
+ /*
+
[PATCH v6 3/3] [v4.9.y] coredump: fix race condition between collapse_huge_page() and core dumping
From: Andrea Arcangeli
coredump: fix race condition between collapse_huge_page() and core dumping
commit 59ea6d06cfa9247b586a695c21f94afa7183af74 upstream.
When fixing the race conditions between the coredump and the mmap_sem
holders outside the context of the process, we focused on
mmget_not_zero()/get_task_mm() callers in 04f5866e41fb70 ("coredump: fix
race condition between mmget_not_zero()/get_task_mm() and core
dumping"), but those aren't the only cases where the mmap_sem can be
taken outside of the context of the process as Michal Hocko noticed
while backporting that commit to older -stable kernels.
If mmgrab() is called in the context of the process, but then the
mm_count reference is transferred outside the context of the process,
that can also be a problem if the mmap_sem has to be taken for writing
through that mm_count reference.
khugepaged registration calls mmgrab() in the context of the process,
but the mmap_sem for writing is taken later in the context of the
khugepaged kernel thread.
collapse_huge_page() after taking the mmap_sem for writing doesn't
modify any vma, so it's not obvious that it could cause a problem to the
coredump, but it happens to modify the pmd in a way that breaks an
invariant that pmd_trans_huge_lock() relies upon. collapse_huge_page()
needs the mmap_sem for writing just to block concurrent page faults that
call pmd_trans_huge_lock().
Specifically the invariant that "!pmd_trans_huge()" cannot become a
"pmd_trans_huge()" doesn't hold while collapse_huge_page() runs.
The coredump will call __get_user_pages() without mmap_sem for reading,
which eventually can invoke a lockless page fault which will need a
functional pmd_trans_huge_lock().
So collapse_huge_page() needs to use mmget_still_valid() to check it's
not running concurrently with the coredump... as long as the coredump
can invoke page faults without holding the mmap_sem for reading.
This has "Fixes: khugepaged" to facilitate backporting, but in my view
it's more a bug in the coredump code that will eventually have to be
rewritten to stop invoking page faults without the mmap_sem for reading.
So the long term plan is still to drop all mmget_still_valid().
Link: http://lkml.kernel.org/r/20190607161558.32104-1-aarca...@redhat.com
Fixes: ba76149f47d8 ("thp: khugepaged")
Signed-off-by: Andrea Arcangeli
Reported-by: Michal Hocko
Acked-by: Michal Hocko
Acked-by: Kirill A. Shutemov
Cc: Oleg Nesterov
Cc: Jann Horn
Cc: Hugh Dickins
Cc: Mike Rapoport
Cc: Mike Kravetz
Cc: Peter Xu
Cc: Jason Gunthorpe
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
[Ajay: Just adjusted to apply on v4.9]
Signed-off-by: Ajay Kaher
---
include/linux/mm.h | 4
mm/khugepaged.c| 3 +++
2 files changed, 7 insertions(+)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index c239984..8852158 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1194,6 +1194,10 @@ void unmap_vmas(struct mmu_gather *tlb, struct
vm_area_struct *start_vma,
* followed by taking the mmap_sem for writing before modifying the
* vmas or anything the coredump pretends not to change from under it.
*
+ * It also has to be called when mmgrab() is used in the context of
+ * the process, but then the mm_count refcount is transferred outside
+ * the context of the process to run down_write() on that pinned mm.
+ *
* NOTE: find_extend_vma() called from GUP context is the only place
* that can modify the "mm" (notably the vm_start/end) under mmap_sem
* for reading and outside the context of the process, so it is also
diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index e0cfc3a..8217ee5 100644
--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -1004,6 +1004,9 @@ static void collapse_huge_page(struct mm_struct *mm,
* handled by the anon_vma lock + PG_lock.
*/
down_write(>mmap_sem);
+ result = SCAN_ANY_PROCESS;
+ if (!mmget_still_valid(mm))
+ goto out;
result = hugepage_vma_revalidate(mm, address, );
if (result)
goto out;
--
2.7.4
Re: [PATCH tip/core/rcu 03/11] rcu/nocb: Provide separate no-CBs grace-period kthreads
On Sat, Aug 03, 2019 at 01:41:27PM -0400, Joel Fernandes wrote: > On Thu, Aug 01, 2019 at 03:50:20PM -0700, Paul E. McKenney wrote: > > Currently, there is one no-CBs rcuo kthread per CPU, and these kthreads > > are divided into groups. The first rcuo kthread to come online in a > > given group is that group's leader, and the leader both waits for grace > > periods and invokes its CPU's callbacks. The non-leader rcuo kthreads > > only invoke callbacks. > > > > This works well in the real-time/embedded environments for which it was > > intended because such environments tend not to generate all that many > > callbacks. However, given huge floods of callbacks, it is possible for > > the leader kthread to be stuck invoking callbacks while its followers > > wait helplessly while their callbacks pile up. This is a good recipe > > for an OOM, and rcutorture's new callback-flood capability does generate > > such OOMs. > > > > One strategy would be to wait until such OOMs start happening in > > production, but similar OOMs have in fact happened starting in 2018. > > It would therefore be wise to take a more proactive approach. > > I haven't looked much into nocbs/nohz_full stuff (yet). In particular, I did > not even know that the rcuo threads do grace period life-cycle management and > waiting, I thought only the RCU GP threads did :-/. however, it seems this is > a completely separate grace-period management state machine outside of the > RCU GP thread right? No, the rcuo kthreads interact with the main RCU GP kthread, initiating new grace periods when needed and being awakened as needed by the RCU GP kthread. > I was wondering for this patch, could we also just have the rcuo > leader handle both callback execution and waking other non-leader threads at > the same time? So like, execute few callbacks, then do the wake up of the > non-leaders to execute their callbacks, the get back to executing their own > callbacks, etc. That way we don't need a separate rcuog thread to wait for > grace period, would that not work? I did look into that, but it was more complex and also didn't foster sharing of rcu_do_batch(), which used to only be for non-offloaded callbacks but now does both. Besides which, invoking callbacks would degrade the rcuog kthread's response to new callbacks and the like. > If you don't mind could you share with me a kvm.sh command (which has config, > boot parameters etc) that can produce the OOM without this patch? I'd > like to take a closer look at it. Here you go: tools/testing/selftests/rcutorture/bin/kvm.sh --cpus 8 --duration 120 --configs TREE04 If you add "--memory 1G" in mainline, the OOMs go away. Or at least decrease substantially in probability. > Is there also a short answer for my the RCU GP thread cannot do the job of > these new rcuog threads? First, the code is more complicated when you do it that way (and yes, I did actually write it out in pen on paper). Second, if the CPU corresponding to the combined grace-period/callback kthread is doing the call_rcu() flooding, you are between a rock and a hard place. On the one hand, you want that kthread to do nothing but invoke callbacks so as to have half a chance of keeping up, and on the other hand you need it to check state frequently so as to react in a timely fashion to a CPU corresponding to one of its callback kthreads starting a second callback flood. Introducing rcug grace-period-only kthreads means that you get the best of both worlds. Plus last year's flavor consolidation decreased the number of rcuo kthreads from either 2N or 3N to N, so increasing it to only (N + sqrt(N)) should be just fine. Though I would expect that there will be at least some screaming and shouting. ;-) Thanx, Paul > thanks a lot, > > - Joel > > > > This commit therefore features per-CPU rcuo kthreads that do nothing > > but invoke callbacks. Instead of having one of these kthreads act as > > leader, each group has a separate rcog kthread that handles grace periods > > for its group. Because these rcuog kthreads do not invoke callbacks, > > callback floods on one CPU no longer block callbacks from reaching the > > rcuc callback-invocation kthreads on other CPUs. > > > > This change does introduce additional kthreads, however: > > > > 1. The number of additional kthreads is about the square root of > > the number of CPUs, so that a 4096-CPU system would have only > > about 64 additional kthreads. Note that recent changes > > decreased the number of rcuo kthreads by a factor of two > > (CONFIG_PREEMPT=n) or even three (CONFIG_PREEMPT=y), so > > this still represents a significant improvement on most systems. > > > > 2. The leading "rcuo" of the rcuog kthreads should allow existing > > scripting to affinity these additional kthreads as needed, the > > same as for the rcuop and rcuos kthreads. (There are no longer > > any rcuob
[PULL REQUEST] i2c for 5.3
Linus, here is a set of drivers fixes for the I2C subsystem. Please pull. Thanks, Wolfram The following changes since commit 609488bc979f99f805f34e9a32c1e3b71179d10b: Linux 5.3-rc2 (2019-07-28 12:47:02 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-current-fixed for you to fetch changes up to 8eb9a2dff019055e4ff307bb7f8c64a7a20e79c8: i2c: s3c2410: Mark expected switch fall-through (2019-08-01 22:24:16 +0200) Gustavo A. R. Silva (1): i2c: s3c2410: Mark expected switch fall-through Jean Delvare (1): eeprom: at24: make spd world-readable again Micha?? Miros??aw (2): i2c: at91: disable TXRDY interrupt after sending data i2c: at91: fix clk_offset for sama5d2 Rayagonda Kokatanur (1): i2c: iproc: Fix i2c master read more than 63 bytes Wolfram Sang (1): Merge tag 'at24-v5.3-rc3-fixes-for-wolfram' of git://git.kernel.org/.../brgl/linux into i2c/for-current with much appreciated quality assurance from Kees Cook (1): (Rev.) i2c: s3c2410: Mark expected switch fall-through Raag Jadav (1): (Test) i2c: at91: disable TXRDY interrupt after sending data Ray Jui (1): (Rev.) i2c: iproc: Fix i2c master read more than 63 bytes drivers/i2c/busses/i2c-at91-core.c | 2 +- drivers/i2c/busses/i2c-at91-master.c | 9 + drivers/i2c/busses/i2c-bcm-iproc.c | 10 ++ drivers/i2c/busses/i2c-s3c2410.c | 1 + drivers/misc/eeprom/at24.c | 2 +- 5 files changed, 14 insertions(+), 10 deletions(-) signature.asc Description: PGP signature
Re: [PATCH 6/6] arm64: dts: meson-g12b-khadas-vim3: add initial device-tree
On Wed, Jul 31, 2019 at 2:44 PM Neil Armstrong wrote:
[...]
> + memory@0 {
> + device_type = "memory";
> + reg = <0x0 0x0 0x0 0x4000>;
nit-pick: we typically use the memory size used in the board size with
the lowest amount of RAM - 2GiB in this case. so I would change it to
0x8000
[...]
> + leds {
> + compatible = "gpio-leds";
> +
> + white {
> + label = "vim3:white";
downstream sources use label="sys_led"
should we call it vim3:white:sys?
Re: [PATCH] linux/bits.h: Add compile time sanity check of GENMASK inputs
On Sat, Aug 03, 2019 at 12:12:46PM +0900, Masahiro Yamada wrote: > On Sat, Aug 3, 2019 at 12:03 PM Masahiro Yamada > wrote: > > > > > BTW, v2 is already inconsistent. > > If you wanted GENMASK_INPUT_CHECK() to return 'unsigned long',, > > you would have to cast (low) > (high) as well: > > > >(unsigned long)((low) > (high)), UL(0 > > > > This is totally redundant, and weird. > > I take back this comment. > You added (unsigned long) to the beginning of this macro. > So, the type is consistent, but I believe all casts should be removed. Maybe you're right. BUILD_BUG_ON_ZERO returns size_t regardless of inputs. I was worried that on some platform, size_t would be larger than unsigned long (as far as I could see, the standard does not give any guarantees), and thus all of a sudden GENMASK would be 8 bytes instead of 4, but perhaps that is not a problem?
Re: [PATCH v2 2/4] clk: meson: add g12a cpu dynamic divider driver
On Wed, Jul 31, 2019 at 10:41 AM Neil Armstrong wrote: > > Add a clock driver for the cpu dynamic divider, this divider needs > to have a flag set before setting the divider value then removed > while writing the new value to the register. > > This drivers implements this behavior and will be used essentially > on the Amlogic G12A and G12B SoCs for cpu clock trees. > > Signed-off-by: Neil Armstrong Reviewed-by: Martin Blumenstingl personally I would add: Suggested-by: Jerome Brunet
Re: [PATCH v2 4/6] arm64: dts: meson: sei510: Add minimal thermal zone
Hi Guillaume,
On Wed, Jul 31, 2019 at 5:36 PM Guillaume La Roque
wrote:
>
> Add minimal thermal zone for DDR and CPU sensor
so high DDR (controller?) temperatures will throttle Mali and high PLL
temperatures will throttle the CPU?
to get things started I'm fine with this, but I think it should be
mentioned here
> Signed-off-by: Guillaume La Roque
> ---
> .../boot/dts/amlogic/meson-g12a-sei510.dts| 56 +++
> 1 file changed, 56 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-g12a-sei510.dts
> b/arch/arm64/boot/dts/amlogic/meson-g12a-sei510.dts
> index 979449968a5f..2c16a2cba0a3 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-g12a-sei510.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-g12a-sei510.dts
> @@ -10,6 +10,7 @@
> #include
> #include
> #include
> +#include
>
> / {
> compatible = "seirobotics,sei510", "amlogic,g12a";
> @@ -33,6 +34,53 @@
> ethernet0 =
> };
>
> + thermal-zones {
> + cpu-thermal {
> + polling-delay = <1000>;
> + polling-delay-passive = <100>;
> + thermal-sensors = <_temp>;
> +
> + trips {
> + cpu_critical: cpu-critical {
> + temperature = <11>; /*
> millicelsius */
> + hysteresis = <2000>; /* millicelsius
> */
> + type = "critical";
> + };
> + };
> +
> + cooling-maps {
> + map {
> + trip = <_critical>;
> + cooling-device = <
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> +<
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> +<
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> +<
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> + };
> + };
> + };
> +
> + ddr-thermal {
> + polling-delay = <1000>;
> + polling-delay-passive = <100>;
> + thermal-sensors = <_temp>;
> +
> + trips {
> + ddr_critical: ddr-critical {
> + temperature = <11>; /*
> millicelsius */
> + hysteresis = <2000>; /* millicelsius
> */
> + type = "critical";
> + };
> + };
> +
> + cooling-maps {
> + map {
> + trip = <_critical>;
> + cooling-device = <
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> + };
> + };
> + };
> + };
> +
> mono_dac: audio-codec-0 {
> compatible = "maxim,max98357a";
> #sound-dai-cells = <0>;
> @@ -321,6 +369,7 @@
> operating-points-v2 = <_opp_table>;
> clocks = < CLKID_CPU_CLK>;
> clock-latency = <5>;
> + #cooling-cells = <2>;
> };
>
> {
> @@ -328,6 +377,7 @@
> operating-points-v2 = <_opp_table>;
> clocks = < CLKID_CPU_CLK>;
> clock-latency = <5>;
> + #cooling-cells = <2>;
> };
>
> {
> @@ -335,6 +385,7 @@
> operating-points-v2 = <_opp_table>;
> clocks = < CLKID_CPU_CLK>;
> clock-latency = <5>;
> + #cooling-cells = <2>;
> };
>
> {
> @@ -342,6 +393,7 @@
> operating-points-v2 = <_opp_table>;
> clocks = < CLKID_CPU_CLK>;
> clock-latency = <5>;
> + #cooling-cells = <2>;
> };
>
> _vdac_port {
> @@ -368,6 +420,10 @@
> status = "okay";
> };
>
> + {
> + #cooling-cells = <2>;
> +};
is there something device-specific in this patch? I'm wondering
whether we can move all of this go g12a.dtsi to simplify maintenance
in the future
Martin
Re: [PATCH v2 2/6] thermal: amlogic: Add thermal driver to support G12 SoCs
Hi Guillaume,
(I still don't have any experience with the thermal framework, so
below are some general comments)
On Wed, Jul 31, 2019 at 5:36 PM Guillaume La Roque
wrote:
I would add a patch description here:
"
Amlogic G12A and G12B SoCs integrate two thermal sensors with the same design.
One is located close to the DDR (controller?) and the other one is
located close to the PLLs (between the CPU and GPU).
The calibration data for each of the thermal sensors instance is
stored in a different location within the AO region.
Implement reading the temperature from each thermal sensor.
The IP block has more functionality, which may be added to this driver
in the future:
- reading up to 16 stored temperature samples
- chip reset when the temperature exceeds a configurable threshold
- up to four interrupts when the temperature has risen above a
configurable threshold
- up to four interrupts when the temperature has fallen below a
configurable threshold
"
> Signed-off-by: Guillaume La Roque
> ---
> drivers/thermal/Kconfig | 11 +
> drivers/thermal/Makefile | 1 +
> drivers/thermal/amlogic_thermal.c | 332 ++
> 3 files changed, 344 insertions(+)
> create mode 100644 drivers/thermal/amlogic_thermal.c
>
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 9966364a6deb..0f31bb4bc372 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -348,6 +348,17 @@ config MTK_THERMAL
> Enable this option if you want to have support for thermal
> management
> controller present in Mediatek SoCs
>
> +config AMLOGIC_THERMAL
we typically use "MESON" in the Kconfig symbols:
$ grep -c AMLOGIC .config
1
$ grep -c MESON .config
33
I also wonder if we should add G12 or G12A so we don't conflict with
upcoming thermal sensors with a different design (assuming that this
will be a thing).
for example we already have three different USB2 PHY drivers
[...]
> +/*
> + * Calculate a temperature value from a temperature code.
> + * The unit of the temperature is degree Celsius.
is it really degree Celsius or millicelsius?
> + */
> +static int code_to_temp(struct amlogic_thermal *pdata, int temp_code)
PREFIX_thermal_code_to_millicelsius?
[...]
> +static int amlogic_thermal_enable(struct amlogic_thermal *data)
> +{
> + clk_prepare_enable(data->clk);
no clock error handling?
> + regmap_update_bits(data->regmap, TSENSOR_CFG_REG1,
> + TSENSOR_CFG_REG1_ENABLE, TSENSOR_CFG_REG1_ENABLE);
> +
> + return 0;
> +}
> +
> +static int amlogic_thermal_disable(struct amlogic_thermal *data)
> +{
> + regmap_update_bits(data->regmap, TSENSOR_CFG_REG1,
> + TSENSOR_CFG_REG1_ENABLE, 0);
> + clk_disable(data->clk);
either clk_disable_unprepare here or use only clk_enable in
amlogic_thermal_enable and move prepare/unprepare somewhere else
> +
> + return 0;
> +}
> +
> +static int amlogic_thermal_get_temp(void *data, int *temp)
> +{
> + unsigned int tvalue;
> + struct amlogic_thermal *pdata = data;
> +
> + if (!data)
> + return -EINVAL;
> +
> + regmap_read(pdata->regmap, TSENSOR_STAT0, );
> + *temp = code_to_temp(pdata,
> +tvalue & TSENSOR_READ_TEMP_MASK);
maybe simply move the implementation from code_to_temp here?
[...]
> +static const struct amlogic_thermal_data amlogic_thermal_g12_cpu_param = {
> + .u_efuse_off = 0x128,
> + .soc = _thermal_g12,
based on the variable name I expected this to be an enum of some sort.
I would have expected it to be called calibration_parameters or
similar to match the explanation in the driver description
(no need to change it if you prefer it like this, I just want to make
you aware of this)
> + .regmap_config = _thermal_regmap_config_g12,
if regmap_config is always the same you may also pass it directly to
devm_regmap_init_mmio
> +};
> +
> +static const struct amlogic_thermal_data amlogic_thermal_g12_ddr_param = {
> + .u_efuse_off = 0xF0,
I believe we use lower-case hex everywhere else
[...]
> +static const struct of_device_id of_amlogic_thermal_match[] = {
> + {
> + .compatible = "amlogic,g12-ddr-thermal",
> + .data = _thermal_g12_ddr_param,
> + },
> + {
> + .compatible = "amlogic,g12-cpu-thermal",
> + .data = _thermal_g12_cpu_param,
> + },
> + { /* end */ }
other drivers use "sentinel", but personally I have no preference here
[...]
> + pdata->tzd = devm_thermal_zone_of_sensor_register
> + (>dev,
> +0,
> +pdata,
> +_thermal_ops);
I believe the opening brace has to go onto the same line as the function name
[...]
> + ret = amlogic_thermal_enable(pdata);
> + if (ret)
> +
Re: [GIT pull] perf/urgent for 5.3-rc3
The pull request you sent on Sat, 03 Aug 2019 16:36:53 -: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > perf-urgent-for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/8b7fd679427c571c34f61d9eafed3562c52424ae Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT pull] timers/urgent for 5.3-rc3
The pull request you sent on Sat, 03 Aug 2019 16:36:53 -: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > timers-urgent-for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/0432a0a066b05361b6d4d26522233c3c76c9e5da Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT pull] irq/urgent for 5.3-rc3
The pull request you sent on Sat, 03 Aug 2019 16:36:53 -: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq-urgent-for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/af42e7450f4b174a0a3f7611791ba73109997171 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] xfs: cleanups for 5.3-rc3
The pull request you sent on Sat, 3 Aug 2019 09:33:12 -0700: > git://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git tags/xfs-5.3-fixes-1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/e12b243de76dcc24a904a48a2efda94fdc4cdf07 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: Possible mem cgroup bug in kernels between 4.18.0 and 5.3-rc1.
> On Aug 3, 2019, at 10:41 AM, Masoud Sharbiani wrote:
>
>
>
>> On Aug 3, 2019, at 8:51 AM, Tetsuo Handa
>> wrote:
>>
>> Masoud, will you try this patch?
>
> Gladly.
> It looks like it is working (and OOMing properly).
>
>
>>
>> By the way, is /sys/fs/cgroup/memory/leaker/memory.usage_in_bytes remains
>> non-zero
>> despite /sys/fs/cgroup/memory/leaker/tasks became empty due to memcg OOM
>> killer expected?
>> Deleting big-data-file.bin after memcg OOM killer reduces some, but still
>> remains
>> non-zero.
>
> Yes. I had not noticed that:
>
> [ 1114.190477] oom_reaper: reaped process 1942 (leaker), now anon-rss:0kB,
> file-
> rss:0kB, shmem-rss:0kB
> ./test-script.sh: line 16: 1942 Killed ./leaker -p 10240 -c
> 10
>
> [root@localhost laleaker]# cat
> /sys/fs/cgroup/memory/leaker/memory.usage_in_bytes
> 3194880
> [root@localhost laleaker]# cat
> /sys/fs/cgroup/memory/leaker/memory.limit_in_bytes
> 536870912
> [root@localhost laleaker]# rm -f big-data-file.bin
> [root@localhost laleaker]# cat
> /sys/fs/cgroup/memory/leaker/memory.usage_in_bytes
> 2838528
>
> Thanks!
> Masoud
>
> PS: Tried hand-back-porting it to 4.19-y and it didn’t work. I think there
> are other patches between 4.19.0 and 5.3 that could be necessary…
>
Please ignore this last part. It works on 4.19-y branch as well.
Masoud
>
>>
>>
>> From 2f92c70f390f42185c6e2abb8dda98b1b7d02fa9 Mon Sep 17 00:00:00 2001
>> From: Tetsuo Handa
>> Date: Sun, 4 Aug 2019 00:41:30 +0900
>> Subject: [PATCH] memcg, oom: don't require __GFP_FS when invoking memcg OOM
>> killer
>>
>> Masoud Sharbiani noticed that commit 29ef680ae7c21110 ("memcg, oom: move
>> out_of_memory back to the charge path") broke memcg OOM called from
>> __xfs_filemap_fault() path. It turned out that try_chage() is retrying
>> forever without making forward progress because mem_cgroup_oom(GFP_NOFS)
>> cannot invoke the OOM killer due to commit 3da88fb3bacfaa33 ("mm, oom:
>> move GFP_NOFS check to out_of_memory"). Regarding memcg OOM, we need to
>> bypass GFP_NOFS check in order to guarantee forward progress.
>>
>> Signed-off-by: Tetsuo Handa
>> Reported-by: Masoud Sharbiani
>> Bisected-by: Masoud Sharbiani
>> Fixes: 29ef680ae7c21110 ("memcg, oom: move out_of_memory back to the charge
>> path")
>> ---
>> mm/oom_kill.c | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
>> index eda2e2a..26804ab 100644
>> --- a/mm/oom_kill.c
>> +++ b/mm/oom_kill.c
>> @@ -1068,9 +1068,10 @@ bool out_of_memory(struct oom_control *oc)
>> * The OOM killer does not compensate for IO-less reclaim.
>> * pagefault_out_of_memory lost its gfp context so we have to
>> * make sure exclude 0 mask - all other users should have at least
>> - * ___GFP_DIRECT_RECLAIM to get here.
>> + * ___GFP_DIRECT_RECLAIM to get here. But mem_cgroup_oom() has to
>> + * invoke the OOM killer even if it is a GFP_NOFS allocation.
>> */
>> -if (oc->gfp_mask && !(oc->gfp_mask & __GFP_FS))
>> +if (oc->gfp_mask && !(oc->gfp_mask & __GFP_FS) && !is_memcg_oom(oc))
>> return true;
>>
>> /*
>> --
>> 1.8.3.1
>>
>>
>
Re: [PATCH v3] net/socket: fix GCC8+ Wpacked-not-aligned warnings
From: Qian Cai
Date: Tue, 30 Jul 2019 11:30:33 -0400
> There are a lot of those warnings with GCC8+ 64-bit,
...
> This is because the commit 20c9c825b12f ("[SCTP] Fix SCTP socket options
> to work with 32-bit apps on 64-bit kernels.") added "packed, aligned(4)"
> GCC attributes to some structures but one of the members, i.e, "struct
> sockaddr_storage" in those structures has the attribute,
> "aligned(__alignof__ (struct sockaddr *)" which is 8-byte on 64-bit
> systems, so the commit overwrites the designed alignments for
> "sockaddr_storage".
>
> To fix this, "struct sockaddr_storage" needs to be aligned to 4-byte as
> it is only used in those packed sctp structure which is part of UAPI,
> and "struct __kernel_sockaddr_storage" is used in some other
> places of UAPI that need not to change alignments in order to not
> breaking userspace.
>
> Use an implicit alignment for "struct __kernel_sockaddr_storage" so it
> can keep the same alignments as a member in both packed and un-packed
> structures without breaking UAPI.
>
> Suggested-by: David Laight
> Signed-off-by: Qian Cai
Ok, this just changes how the alignment is declared from using the
aligned attribute to using a union member which requires the same
alignment.
Applied.
Re: [PATCH] net: sctp: Rename fallthrough label to unhandled
On Fri, 2019-08-02 at 16:19 -0700, David Miller wrote: > From: Joe Perches > Date: Fri, 02 Aug 2019 10:47:34 -0700 > > > On Wed, 2019-07-31 at 08:16 -0400, Neil Horman wrote: > >> On Wed, Jul 31, 2019 at 04:32:43AM -0700, Joe Perches wrote: > >> > On Wed, 2019-07-31 at 07:19 -0400, Neil Horman wrote: > >> > > On Tue, Jul 30, 2019 at 10:04:37PM -0700, Joe Perches wrote: > >> > > > fallthrough may become a pseudo reserved keyword so this only use of > >> > > > fallthrough is better renamed to allow it. > > > > Can you or any other maintainer apply this patch > > or ack it so David Miller can apply it? > > I, like others, don't like the lack of __ in the keyword. It's kind of > rediculous the problems it creates to pollute the global namespace like > that and yes also inconsistent with other shorthands for builtins. Rejected? I think that's inappropriate. As coded, it's nothing like a fallthrough and the rename to unhandled is more descriptive.
Re: [PATCH v2 3/6] arm64: dts: amlogic: g12: add temperature sensor
Hi Guillaume,
On Wed, Jul 31, 2019 at 5:36 PM Guillaume La Roque
wrote:
>
> Add cpu and ddr temperature sensors for G12 Socs
>
> Signed-off-by: Guillaume La Roque
with the nit-pick below addressed:
Reviewed-by: Martin Blumenstingl
> ---
> .../boot/dts/amlogic/meson-g12-common.dtsi| 22 +++
> 1 file changed, 22 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
> b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
> index 06e186ca41e3..7f862a3490fb 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
> @@ -1353,6 +1353,28 @@
> };
> };
>
> + cpu_temp: temperature-sensor@34800 {
> + compatible = "amlogic,g12-cpu-thermal",
> +"amlogic,g12-thermal";
> + reg = <0x0 0x34800 0x0 0x50>;
> + interrupts = IRQ_TYPE_EDGE_RISING>;
> + clocks = < CLKID_TS>;
> + status = "okay";
I believe nodes are enabled automatically if they don't have a status property
> + #thermal-sensor-cells = <0>;
> + amlogic,ao-secure = <_AO>;
> + };
> +
> + ddr_temp: temperature-sensor@34c00 {
> + compatible = "amlogic,g12-ddr-thermal",
> +"amlogic,g12-thermal";
> + reg = <0x0 0x34c00 0x0 0x50>;
> + interrupts = IRQ_TYPE_EDGE_RISING>;
> + clocks = < CLKID_TS>;
> + status = "okay";
same here
Martin
Re: [PATCH] staging: rtl8192e: Make use kmemdup
On Sat, 2019-08-03 at 23:10 +0530, Hariprasad Kelam wrote:
> As kmemdup API does kmalloc + memcpy . We can make use of it instead of
> calling kmalloc and memcpy independetly.
[]
> diff --git a/drivers/staging/rtl8192e/rtllib_softmac.c
> b/drivers/staging/rtl8192e/rtllib_softmac.c
[]
> @@ -1382,10 +1382,8 @@ rtllib_association_req(struct rtllib_network *beacon,
> ieee->assocreq_ies = NULL;
> ies = &(hdr->info_element[0].id);
> ieee->assocreq_ies_len = (skb->data + skb->len) - ies;
> - ieee->assocreq_ies = kmalloc(ieee->assocreq_ies_len, GFP_ATOMIC);
> - if (ieee->assocreq_ies)
> - memcpy(ieee->assocreq_ies, ies, ieee->assocreq_ies_len);
> - else {
> + ieee->assocreq_ies = kmemdup(ies, ieee->assocreq_ies_len, GFP_ATOMIC);
> + if (!ieee->assocreq_ies) {
> netdev_info(ieee->dev,
> "%s()Warning: can't alloc memory for
> assocreq_ies\n",
> __func__);
> @@ -2259,12 +2257,10 @@ rtllib_rx_assoc_resp(struct rtllib_device *ieee,
> struct sk_buff *skb,
> ieee->assocresp_ies = NULL;
> ies = &(assoc_resp->info_element[0].id);
> ieee->assocresp_ies_len = (skb->data + skb->len) - ies;
> - ieee->assocresp_ies = kmalloc(ieee->assocresp_ies_len,
> + ieee->assocresp_ies = kmemdup(ies,
> + ieee->assocresp_ies_len,
> GFP_ATOMIC);
> - if (ieee->assocresp_ies)
> - memcpy(ieee->assocresp_ies, ies,
> -ieee->assocresp_ies_len);
> - else {
> + if (!ieee->assocresp_ies) {
> netdev_info(ieee->dev,
> "%s()Warning: can't alloc memory
> for assocresp_ies\n",
> __func__);
Could also remove the netdev_info() uses for allocation failures.
These are redundant as a dump_stack() is already done when OOM.
Re: [GIT PULL] xfs: cleanups for 5.3-rc3
On Sat, Aug 3, 2019 at 9:33 AM Darrick J. Wong wrote: > > Here are a couple more bug fixes that trickled in since -rc1. It's > survived the usual xfstests runs and merges cleanly with this morning's > master. Please let me know if anything strange happens. Hmm. This was tagged, but not signed like your usual tags are. I've pulled it (I don't _require_ signed tags from kernel.org), but would generally be much happier if I saw the signing too... Thanks, Linus
Re: [GIT PULL] RISC-V updates for v5.3-rc3
The pull request you sent on Sat, 3 Aug 2019 07:22:25 -0700 (PDT): > git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git > tags/riscv/for-v5.3-rc3 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/616725492ec7519643d5638de02a92a28200d03f Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] SELinux fixes for v5.3 (#2)
The pull request you sent on Thu, 1 Aug 2019 19:01:52 -0400: > git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux.git > tags/selinux-pr-20190801 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/4f1a6ef1df6f952fc9f22f34d51a6c3d3c4fbe23 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: Possible mem cgroup bug in kernels between 4.18.0 and 5.3-rc1.
> On Aug 3, 2019, at 8:51 AM, Tetsuo Handa
> wrote:
>
> Masoud, will you try this patch?
Gladly.
It looks like it is working (and OOMing properly).
>
> By the way, is /sys/fs/cgroup/memory/leaker/memory.usage_in_bytes remains
> non-zero
> despite /sys/fs/cgroup/memory/leaker/tasks became empty due to memcg OOM
> killer expected?
> Deleting big-data-file.bin after memcg OOM killer reduces some, but still
> remains
> non-zero.
Yes. I had not noticed that:
[ 1114.190477] oom_reaper: reaped process 1942 (leaker), now anon-rss:0kB, file-
rss:0kB, shmem-rss:0kB
./test-script.sh: line 16: 1942 Killed ./leaker -p 10240 -c
10
[root@localhost laleaker]# cat
/sys/fs/cgroup/memory/leaker/memory.usage_in_bytes
3194880
[root@localhost laleaker]# cat
/sys/fs/cgroup/memory/leaker/memory.limit_in_bytes
536870912
[root@localhost laleaker]# rm -f big-data-file.bin
[root@localhost laleaker]# cat
/sys/fs/cgroup/memory/leaker/memory.usage_in_bytes
2838528
Thanks!
Masoud
PS: Tried hand-back-porting it to 4.19-y and it didn’t work. I think there are
other patches between 4.19.0 and 5.3 that could be necessary…
>
>
> From 2f92c70f390f42185c6e2abb8dda98b1b7d02fa9 Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa
> Date: Sun, 4 Aug 2019 00:41:30 +0900
> Subject: [PATCH] memcg, oom: don't require __GFP_FS when invoking memcg OOM
> killer
>
> Masoud Sharbiani noticed that commit 29ef680ae7c21110 ("memcg, oom: move
> out_of_memory back to the charge path") broke memcg OOM called from
> __xfs_filemap_fault() path. It turned out that try_chage() is retrying
> forever without making forward progress because mem_cgroup_oom(GFP_NOFS)
> cannot invoke the OOM killer due to commit 3da88fb3bacfaa33 ("mm, oom:
> move GFP_NOFS check to out_of_memory"). Regarding memcg OOM, we need to
> bypass GFP_NOFS check in order to guarantee forward progress.
>
> Signed-off-by: Tetsuo Handa
> Reported-by: Masoud Sharbiani
> Bisected-by: Masoud Sharbiani
> Fixes: 29ef680ae7c21110 ("memcg, oom: move out_of_memory back to the charge
> path")
> ---
> mm/oom_kill.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> index eda2e2a..26804ab 100644
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -1068,9 +1068,10 @@ bool out_of_memory(struct oom_control *oc)
>* The OOM killer does not compensate for IO-less reclaim.
>* pagefault_out_of_memory lost its gfp context so we have to
>* make sure exclude 0 mask - all other users should have at least
> - * ___GFP_DIRECT_RECLAIM to get here.
> + * ___GFP_DIRECT_RECLAIM to get here. But mem_cgroup_oom() has to
> + * invoke the OOM killer even if it is a GFP_NOFS allocation.
>*/
> - if (oc->gfp_mask && !(oc->gfp_mask & __GFP_FS))
> + if (oc->gfp_mask && !(oc->gfp_mask & __GFP_FS) && !is_memcg_oom(oc))
> return true;
>
> /*
> --
> 1.8.3.1
>
>
Re: [PATCH tip/core/rcu 03/11] rcu/nocb: Provide separate no-CBs grace-period kthreads
On Thu, Aug 01, 2019 at 03:50:20PM -0700, Paul E. McKenney wrote:
> Currently, there is one no-CBs rcuo kthread per CPU, and these kthreads
> are divided into groups. The first rcuo kthread to come online in a
> given group is that group's leader, and the leader both waits for grace
> periods and invokes its CPU's callbacks. The non-leader rcuo kthreads
> only invoke callbacks.
>
> This works well in the real-time/embedded environments for which it was
> intended because such environments tend not to generate all that many
> callbacks. However, given huge floods of callbacks, it is possible for
> the leader kthread to be stuck invoking callbacks while its followers
> wait helplessly while their callbacks pile up. This is a good recipe
> for an OOM, and rcutorture's new callback-flood capability does generate
> such OOMs.
>
> One strategy would be to wait until such OOMs start happening in
> production, but similar OOMs have in fact happened starting in 2018.
> It would therefore be wise to take a more proactive approach.
I haven't looked much into nocbs/nohz_full stuff (yet). In particular, I did
not even know that the rcuo threads do grace period life-cycle management and
waiting, I thought only the RCU GP threads did :-/. however, it seems this is
a completely separate grace-period management state machine outside of the
RCU GP thread right?
I was wondering for this patch, could we also just have the rcuo
leader handle both callback execution and waking other non-leader threads at
the same time? So like, execute few callbacks, then do the wake up of the
non-leaders to execute their callbacks, the get back to executing their own
callbacks, etc. That way we don't need a separate rcuog thread to wait for
grace period, would that not work?
If you don't mind could you share with me a kvm.sh command (which has config,
boot parameters etc) that can produce the OOM without this patch? I'd
like to take a closer look at it.
Is there also a short answer for my the RCU GP thread cannot do the job of
these new rcuog threads?
thanks a lot,
- Joel
> This commit therefore features per-CPU rcuo kthreads that do nothing
> but invoke callbacks. Instead of having one of these kthreads act as
> leader, each group has a separate rcog kthread that handles grace periods
> for its group. Because these rcuog kthreads do not invoke callbacks,
> callback floods on one CPU no longer block callbacks from reaching the
> rcuc callback-invocation kthreads on other CPUs.
>
> This change does introduce additional kthreads, however:
>
> 1.The number of additional kthreads is about the square root of
> the number of CPUs, so that a 4096-CPU system would have only
> about 64 additional kthreads. Note that recent changes
> decreased the number of rcuo kthreads by a factor of two
> (CONFIG_PREEMPT=n) or even three (CONFIG_PREEMPT=y), so
> this still represents a significant improvement on most systems.
>
> 2.The leading "rcuo" of the rcuog kthreads should allow existing
> scripting to affinity these additional kthreads as needed, the
> same as for the rcuop and rcuos kthreads. (There are no longer
> any rcuob kthreads.)
>
> 3.A state-machine approach was considered and rejected. Although
> this would allow the rcuo kthreads to continue their dual
> leader/follower roles, it complicates callback invocation
> and makes it more difficult to consolidate rcuo callback
> invocation with existing softirq callback invocation.
>
> The introduction of rcuog kthreads should thus be acceptable.
>
> Signed-off-by: Paul E. McKenney
> ---
> kernel/rcu/tree.h| 6 +-
> kernel/rcu/tree_plugin.h | 115 +++
> 2 files changed, 61 insertions(+), 60 deletions(-)
>
> diff --git a/kernel/rcu/tree.h b/kernel/rcu/tree.h
> index 32b3348d3a4d..dc3c53cb9608 100644
> --- a/kernel/rcu/tree.h
> +++ b/kernel/rcu/tree.h
> @@ -200,8 +200,8 @@ struct rcu_data {
> atomic_long_t nocb_q_count_lazy; /* invocation (all stages). */
> struct rcu_head *nocb_cb_head; /* CBs ready to invoke. */
> struct rcu_head **nocb_cb_tail;
> - struct swait_queue_head nocb_wq; /* For nocb kthreads to sleep on. */
> - struct task_struct *nocb_cb_kthread;
> + struct swait_queue_head nocb_cb_wq; /* For nocb kthreads to sleep on. */
> + struct task_struct *nocb_gp_kthread;
> raw_spinlock_t nocb_lock; /* Guard following pair of fields. */
> int nocb_defer_wakeup; /* Defer wakeup of nocb_kthread. */
> struct timer_list nocb_timer; /* Enforce finite deferral. */
> @@ -211,6 +211,8 @@ struct rcu_data {
> /* CBs waiting for GP. */
> struct rcu_head **nocb_gp_tail;
> bool nocb_gp_sleep; /* Is the nocb GP thread asleep? */
> + struct swait_queue_head nocb_gp_wq; /* For nocb kthreads to sleep on. */
> + struct
[PATCH] staging: rtl8192e: Make use kmemdup
As kmemdup API does kmalloc + memcpy . We can make use of it instead of
calling kmalloc and memcpy independetly.
Signed-off-by: Hariprasad Kelam
---
drivers/staging/rtl8192e/rtllib_softmac.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtllib_softmac.c
b/drivers/staging/rtl8192e/rtllib_softmac.c
index e29e8d6..9b8b301 100644
--- a/drivers/staging/rtl8192e/rtllib_softmac.c
+++ b/drivers/staging/rtl8192e/rtllib_softmac.c
@@ -1382,10 +1382,8 @@ rtllib_association_req(struct rtllib_network *beacon,
ieee->assocreq_ies = NULL;
ies = &(hdr->info_element[0].id);
ieee->assocreq_ies_len = (skb->data + skb->len) - ies;
- ieee->assocreq_ies = kmalloc(ieee->assocreq_ies_len, GFP_ATOMIC);
- if (ieee->assocreq_ies)
- memcpy(ieee->assocreq_ies, ies, ieee->assocreq_ies_len);
- else {
+ ieee->assocreq_ies = kmemdup(ies, ieee->assocreq_ies_len, GFP_ATOMIC);
+ if (!ieee->assocreq_ies) {
netdev_info(ieee->dev,
"%s()Warning: can't alloc memory for
assocreq_ies\n",
__func__);
@@ -2259,12 +2257,10 @@ rtllib_rx_assoc_resp(struct rtllib_device *ieee, struct
sk_buff *skb,
ieee->assocresp_ies = NULL;
ies = &(assoc_resp->info_element[0].id);
ieee->assocresp_ies_len = (skb->data + skb->len) - ies;
- ieee->assocresp_ies = kmalloc(ieee->assocresp_ies_len,
+ ieee->assocresp_ies = kmemdup(ies,
+ ieee->assocresp_ies_len,
GFP_ATOMIC);
- if (ieee->assocresp_ies)
- memcpy(ieee->assocresp_ies, ies,
- ieee->assocresp_ies_len);
- else {
+ if (!ieee->assocresp_ies) {
netdev_info(ieee->dev,
"%s()Warning: can't alloc memory
for assocresp_ies\n",
__func__);
--
2.7.4
Re: [PATCH 3/5] MIPS: lantiq: add an irq_domain and irq_chip for EBU
Hi Marc,
On Sat, Aug 3, 2019 at 11:12 AM Marc Zyngier wrote:
>
> Hi Martin,
>
> On Thu, 01 Aug 2019 18:42:42 +0100,
> Martin Blumenstingl wrote:
>
> [...]
>
> > > > +static void ltq_ebu_irq_handler(struct irq_desc *desc)
> > > > +{
> > > > + struct irq_domain *domain = irq_desc_get_handler_data(desc);
> > > > + struct irq_chip *irqchip = irq_desc_get_chip(desc);
> > > > +
> > > > + chained_irq_enter(irqchip, desc);
> > > > +
> > > > + generic_handle_irq(irq_find_mapping(domain, 0));
> > >
> > > Having an irqdomain for a single interrupt is a bit over the top... Is
> > > that for the convenience of the DT infrastructure?
> > yes, I did it to get DT support
> > please let me know if there's a "better" way (preferably with another
> > driver as example)
>
> To be honest, the chained handler is what troubles me the most. You
> normally would use such a construct if you had a multiplexer. In your
> case, you have a 1:1 relationship between input and output. It is just
> that this irqchip allows the trigger to be adapted, which normally
> calls for a hierarchical implementation.
>
> In your case, with only a single interrupt, it doesn't matter much
> though.
I see, thank you for the explanation
can you name a driver for a hierarchical irqchip driver that you
consider "clean" which I could use as reference?
I am considering to still convert it to a hierarchical irqchip driver
to keep it consistent with at least two more upcoming Lantiq irqchip
drivers (which both seem to be similar use-cases as this one, they
just provide more than one interrupt):
- there's a PCI legacy interrupt controller in the PCIe controller's
app registers. it takes 4 parent interrupts and provides
PCI_INT{A,B,C,D}. the interrupts need to be enabled and ACK'ed in the
PCIe app registers as well as in the parent interrupt controller
- the EIU (External Interrupt Unit) in my own words is the GPIO
interrupt controller. it takes up to 6 parent interrupts and provides
one interrupt for each "EXIN GPIO". setting the IRQ type and ACK need
to happen through the EIU registers as well as the parent interrupt
controller
my initial thought is that it's best to follow one programming model
(which based on your suggestion would be a hierarchical irqchip) for
all three IRQ controllers
> >
> > [...]
> > > > + irq_create_mapping(domain, 0);
> > >
> > > Why do you need to perform this eagerly? I'd expect this interrupt to
> > > be mapped when it is actually claimed by a driver.
> > I don't remember why I added it, it may be left-over from copying from
> > another driver
> > in v2 I'll try to drop it
> >
> > > > +
> > > > + irq_set_chained_handler_and_data(irq, ltq_ebu_irq_handler,
> > > > domain);
> > >
> > > And there is no HW initialisation whatsoever? I'd expect, at the very
> > > least, the sole interrupt to be configured as disabled/masked.
> > I can add that. is there any "best practice" on what I should
> > initialize (just disable it or also set a "default" mode like
> > LEVEL_LOW)?
>
> Whichever default state makes sense. What you want to avoid is to boot
> the kernel with a screaming interrupt because some firmware has left
> it enabled.
noted, thank you
Martin
Re: [PATCH v7 07/20] clk: tegra: clk-periph: Add save and restore support
On 8/3/19 3:33 AM, Dmitry Osipenko wrote:
03.08.2019 2:51, Sowjanya Komatineni пишет:
On 8/2/19 2:15 PM, Dmitry Osipenko wrote:
02.08.2019 23:32, Sowjanya Komatineni пишет:
On 8/2/19 1:17 PM, Dmitry Osipenko wrote:
02.08.2019 23:13, Dmitry Osipenko пишет:
02.08.2019 21:33, Sowjanya Komatineni пишет:
On 8/2/19 5:38 AM, Dmitry Osipenko wrote:
02.08.2019 2:49, Sowjanya Komatineni пишет:
On 8/1/19 4:19 PM, Sowjanya Komatineni wrote:
On 8/1/19 2:30 PM, Sowjanya Komatineni wrote:
On 8/1/19 1:54 PM, Dmitry Osipenko wrote:
01.08.2019 23:31, Sowjanya Komatineni пишет:
On 8/1/19 1:17 PM, Dmitry Osipenko wrote:
01.08.2019 22:42, Sowjanya Komatineni пишет:
On 8/1/19 12:00 PM, Dmitry Osipenko wrote:
01.08.2019 20:58, Sowjanya Komatineni пишет:
On 7/31/19 4:09 PM, Sowjanya Komatineni wrote:
On 7/31/19 3:44 AM, Dmitry Osipenko wrote:
31.07.2019 12:50, Dmitry Osipenko пишет:
31.07.2019 3:20, Sowjanya Komatineni пишет:
This patch implements save and restore context for
peripheral
fixed
clock ops, peripheral gate clock ops, sdmmc mux clock
ops, and
peripheral clock ops.
During system suspend, core power goes off and
looses the
settings
of the Tegra CAR controller registers.
So during suspend entry clock and reset state of
peripherals is
saved
and on resume they are restored to have clocks back to
same
rate and
state as before suspend.
Acked-by: Thierry Reding
Signed-off-by: Sowjanya Komatineni
---
drivers/clk/tegra/clk-periph-fixed.c | 33
drivers/clk/tegra/clk-periph-gate.c | 34
+
drivers/clk/tegra/clk-periph.c | 37
drivers/clk/tegra/clk-sdmmc-mux.c | 28
+++
drivers/clk/tegra/clk.h | 6 ++
5 files changed, 138 insertions(+)
diff --git a/drivers/clk/tegra/clk-periph-fixed.c
b/drivers/clk/tegra/clk-periph-fixed.c
index c088e7a280df..21b24530fa00 100644
--- a/drivers/clk/tegra/clk-periph-fixed.c
+++ b/drivers/clk/tegra/clk-periph-fixed.c
@@ -60,11 +60,44 @@
tegra_clk_periph_fixed_recalc_rate(struct
clk_hw *hw,
return (unsigned long)rate;
}
+static int
tegra_clk_periph_fixed_save_context(struct
clk_hw
*hw)
+{
+ struct tegra_clk_periph_fixed *fixed =
to_tegra_clk_periph_fixed(hw);
+ u32 mask = 1 << (fixed->num % 32);
+
+ fixed->enb_ctx = readl_relaxed(fixed->base +
fixed->regs->enb_reg) &
+ mask;
+ fixed->rst_ctx = readl_relaxed(fixed->base +
fixed->regs->rst_reg) &
+ mask;
+
+ return 0;
+}
+
+static void
tegra_clk_periph_fixed_restore_context(struct
clk_hw
*hw)
+{
+ struct tegra_clk_periph_fixed *fixed =
to_tegra_clk_periph_fixed(hw);
+ u32 mask = 1 << (fixed->num % 32);
+
+ if (fixed->enb_ctx)
+ writel_relaxed(mask, fixed->base +
fixed->regs->enb_set_reg);
+ else
+ writel_relaxed(mask, fixed->base +
fixed->regs->enb_clr_reg);
+
+ udelay(2);
+
+ if (!fixed->rst_ctx) {
+ udelay(5); /* reset propogation delay */
+ writel_relaxed(mask, fixed->base +
fixed->regs->rst_reg);
+ }
+}
+
static const struct clk_ops
tegra_clk_periph_fixed_ops
= {
.is_enabled =
tegra_clk_periph_fixed_is_enabled,
.enable = tegra_clk_periph_fixed_enable,
.disable = tegra_clk_periph_fixed_disable,
.recalc_rate =
tegra_clk_periph_fixed_recalc_rate,
+ .save_context =
tegra_clk_periph_fixed_save_context,
+ .restore_context =
tegra_clk_periph_fixed_restore_context,
};
struct clk
*tegra_clk_register_periph_fixed(const
char
*name,
diff --git a/drivers/clk/tegra/clk-periph-gate.c
b/drivers/clk/tegra/clk-periph-gate.c
index 4b31beefc9fc..6ba5b08e0787 100644
--- a/drivers/clk/tegra/clk-periph-gate.c
+++ b/drivers/clk/tegra/clk-periph-gate.c
@@ -25,6 +25,8 @@ static
DEFINE_SPINLOCK(periph_ref_lock);
#define read_rst(gate) \
readl_relaxed(gate->clk_base +
(gate->regs->rst_reg))
+#define write_rst_set(val, gate) \
+ writel_relaxed(val, gate->clk_base +
(gate->regs->rst_set_reg))
#define write_rst_clr(val, gate) \
writel_relaxed(val, gate->clk_base +
(gate->regs->rst_clr_reg))
@@ -110,10 +112,42 @@ static void
clk_periph_disable(struct
clk_hw *hw)
spin_unlock_irqrestore(_ref_lock, flags);
}
+static int clk_periph_gate_save_context(struct
clk_hw
*hw)
+{
+ struct tegra_clk_periph_gate *gate =
to_clk_periph_gate(hw);
+
+ gate->clk_state_ctx = read_enb(gate) &
periph_clk_to_bit(gate);
+ gate->rst_state_ctx = read_rst(gate) &
periph_clk_to_bit(gate);
+
+ return 0;
+}
+
+static void clk_periph_gate_restore_context(struct
clk_hw
*hw)
+{
+ struct tegra_clk_periph_gate *gate =
to_clk_periph_gate(hw);
+
+ if (gate->clk_state_ctx)
+ write_enb_set(periph_clk_to_bit(gate), gate);
+ else
+ write_enb_clr(periph_clk_to_bit(gate), gate);
+
+ udelay(5);
+
+
Re: [PATCH net-next] netfilter: conntrack: use shared sysctl constants
On Tue, Jul 23, 2019 at 03:23:03AM +0200, Matteo Croce wrote:
> Use shared sysctl variables for zero and one constants, as in commit
> eec4844fae7c ("proc/sysctl: add shared variables for range check")
Applied, thanks.
[GIT pull] perf/urgent for 5.3-rc3
Linus,
please pull the latest perf-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
perf-urgent-for-linus
up to: b3c303be4c35: Merge tag 'perf-urgent-for-mingo-5.3-20190729' of
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent
A set of updates for perf tools and documentation:
tools:
perf header:
- Prevent a division by zero
- Deal with an uninitialized warning proper
libbpf:
- Fix the missiong __WORDSIZE definition for musl & al
UAPI headers:
- Synchronize kernel headers
Documentation:
- Fix the memory units for perf.data size
Thanks,
tglx
-->
Andrii Nakryiko (1):
libbpf: fix missing __WORDSIZE definition
Arnaldo Carvalho de Melo (8):
tools include UAPI: Sync x86's syscalls_64.tbl and generic unistd.h to
pick up clone3 and pidfd_open
tools headers UAPI: Update tools's copy of kvm.h headers
tools headers UAPI: Update tools's copy of mman.h headers
tools headers UAPI: Update tools's copy of drm.h headers
tools perf beauty: Fix usbdevfs_ioctl table generator to handle _IOC()
tools headers UAPI: Sync usbdevice_fs.h with the kernels to get new ioctl
tools headers UAPI: Sync sched.h with the kernel
tools headers UAPI: Sync if_link.h with the kernel
Numfor Mbiziwo-Tiapo (1):
perf header: Fix use of unitialized value warning
Vince Weaver (2):
perf header: Fix divide by zero error if f_header.attr_size==0
perf tools: Fix perf.data documentation units for memory size
tools/arch/arm/include/uapi/asm/kvm.h | 12 ++
tools/arch/arm64/include/uapi/asm/kvm.h| 10 +
tools/arch/powerpc/include/uapi/asm/mman.h | 4 -
tools/arch/sparc/include/uapi/asm/mman.h | 4 -
tools/arch/x86/include/uapi/asm/kvm.h | 22 ++-
tools/arch/x86/include/uapi/asm/vmx.h | 1 -
tools/include/uapi/asm-generic/mman-common.h | 15 +-
tools/include/uapi/asm-generic/mman.h | 10 +-
tools/include/uapi/asm-generic/unistd.h| 8 +-
tools/include/uapi/drm/drm.h | 1 +
tools/include/uapi/drm/i915_drm.h | 209 -
tools/include/uapi/linux/if_link.h | 5 +
tools/include/uapi/linux/kvm.h | 3 +
tools/include/uapi/linux/sched.h | 30 ++-
tools/include/uapi/linux/usbdevice_fs.h| 26 +++
tools/lib/bpf/hashmap.h| 5 +
tools/perf/Documentation/perf.data-file-format.txt | 2 +-
tools/perf/arch/x86/entry/syscalls/syscall_64.tbl | 2 +
tools/perf/trace/beauty/usbdevfs_ioctl.sh | 9 +-
tools/perf/util/header.c | 9 +-
20 files changed, 352 insertions(+), 35 deletions(-)
diff --git a/tools/arch/arm/include/uapi/asm/kvm.h
b/tools/arch/arm/include/uapi/asm/kvm.h
index 4602464ebdfb..a4217c1a5d01 100644
--- a/tools/arch/arm/include/uapi/asm/kvm.h
+++ b/tools/arch/arm/include/uapi/asm/kvm.h
@@ -214,6 +214,18 @@ struct kvm_vcpu_events {
#define KVM_REG_ARM_FW_REG(r) (KVM_REG_ARM | KVM_REG_SIZE_U64 | \
KVM_REG_ARM_FW | ((r) & 0x))
#define KVM_REG_ARM_PSCI_VERSION KVM_REG_ARM_FW_REG(0)
+#define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1KVM_REG_ARM_FW_REG(1)
+ /* Higher values mean better protection. */
+#define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_AVAIL 0
+#define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_AVAIL 1
+#define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_REQUIRED 2
+#define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2KVM_REG_ARM_FW_REG(2)
+ /* Higher values mean better protection. */
+#define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL 0
+#define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_UNKNOWN1
+#define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_AVAIL 2
+#define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED 3
+#define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED(1U << 4)
/* Device Control API: ARM VGIC */
#define KVM_DEV_ARM_VGIC_GRP_ADDR 0
diff --git a/tools/arch/arm64/include/uapi/asm/kvm.h
b/tools/arch/arm64/include/uapi/asm/kvm.h
index d819a3e8b552..9a507716ae2f 100644
--- a/tools/arch/arm64/include/uapi/asm/kvm.h
+++ b/tools/arch/arm64/include/uapi/asm/kvm.h
@@ -229,6 +229,16 @@ struct kvm_vcpu_events {
#define KVM_REG_ARM_FW_REG(r) (KVM_REG_ARM64 | KVM_REG_SIZE_U64 | \
KVM_REG_ARM_FW | ((r) & 0x))
#define KVM_REG_ARM_PSCI_VERSION KVM_REG_ARM_FW_REG(0)
+#define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1KVM_REG_ARM_FW_REG(1)
+#define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_AVAIL 0
+#define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_AVAIL 1
+#define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_REQUIRED 2
+#define
[GIT pull] irq/urgent for 5.3-rc3
Linus,
please pull the latest irq-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
irq-urgent-for-linus
up to: a5dbba8f443e: Merge tag 'irqchip-fixes-5.3' of
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/urgent
A small bunch of fixes from the irqchip department:
- Fix a couple of UAF on error paths (RZA1, GICv3 ITS)
- Fix iMX GPCv2 trigger setting
- Add missing of_node_put() on error path in MBIGEN
- Add another bunch of /* fall-through */ to silence warnings
Thanks,
tglx
-->
Anders Roxell (1):
irqchip/gic-v3: Mark expected switch fall-through
Lucas Stach (1):
irqchip/irq-imx-gpcv2: Forward irq type to parent
Nianyao Tang (1):
irqchip/gic-v3-its: Free unused vpt_page when alloc vpe table fail
Nishka Dasgupta (1):
irqchip/irq-mbigen: Add of_node_put() before return
Wen Yang (1):
irqchip/renesas-rza1: Fix an use-after-free in rza1_irqc_probe()
drivers/irqchip/irq-gic-v3-its.c | 2 +-
drivers/irqchip/irq-gic-v3.c | 4
drivers/irqchip/irq-imx-gpcv2.c | 1 +
drivers/irqchip/irq-mbigen.c | 9 +++--
4 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 730fbe0e2a9d..1b5c3672aea2 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -3010,7 +3010,7 @@ static int its_vpe_init(struct its_vpe *vpe)
if (!its_alloc_vpe_table(vpe_id)) {
its_vpe_id_free(vpe_id);
- its_free_pending_table(vpe->vpt_page);
+ its_free_pending_table(vpt_page);
return -ENOMEM;
}
diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index 9bca4896fa6f..96d927f0f91a 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -771,8 +771,10 @@ static void gic_cpu_sys_reg_init(void)
case 7:
write_gicreg(0, ICC_AP0R3_EL1);
write_gicreg(0, ICC_AP0R2_EL1);
+ /* Fall through */
case 6:
write_gicreg(0, ICC_AP0R1_EL1);
+ /* Fall through */
case 5:
case 4:
write_gicreg(0, ICC_AP0R0_EL1);
@@ -786,8 +788,10 @@ static void gic_cpu_sys_reg_init(void)
case 7:
write_gicreg(0, ICC_AP1R3_EL1);
write_gicreg(0, ICC_AP1R2_EL1);
+ /* Fall through */
case 6:
write_gicreg(0, ICC_AP1R1_EL1);
+ /* Fall through */
case 5:
case 4:
write_gicreg(0, ICC_AP1R0_EL1);
diff --git a/drivers/irqchip/irq-imx-gpcv2.c b/drivers/irqchip/irq-imx-gpcv2.c
index bf2237ac5d09..4f74c15c4755 100644
--- a/drivers/irqchip/irq-imx-gpcv2.c
+++ b/drivers/irqchip/irq-imx-gpcv2.c
@@ -131,6 +131,7 @@ static struct irq_chip gpcv2_irqchip_data_chip = {
.irq_unmask = imx_gpcv2_irq_unmask,
.irq_set_wake = imx_gpcv2_irq_set_wake,
.irq_retrigger = irq_chip_retrigger_hierarchy,
+ .irq_set_type = irq_chip_set_type_parent,
#ifdef CONFIG_SMP
.irq_set_affinity = irq_chip_set_affinity_parent,
#endif
diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
index 3dd28382d5f5..3f09f658e8e2 100644
--- a/drivers/irqchip/irq-mbigen.c
+++ b/drivers/irqchip/irq-mbigen.c
@@ -241,12 +241,15 @@ static int mbigen_of_create_domain(struct platform_device
*pdev,
parent = platform_bus_type.dev_root;
child = of_platform_device_create(np, NULL, parent);
- if (!child)
+ if (!child) {
+ of_node_put(np);
return -ENOMEM;
+ }
if (of_property_read_u32(child->dev.of_node, "num-pins",
_pins) < 0) {
dev_err(>dev, "No num-pins property\n");
+ of_node_put(np);
return -EINVAL;
}
@@ -254,8 +257,10 @@ static int mbigen_of_create_domain(struct platform_device
*pdev,
mbigen_write_msg,
_domain_ops,
mgn_chip);
- if (!domain)
+ if (!domain) {
+ of_node_put(np);
return -ENOMEM;
+ }
}
return 0;
[GIT pull] timers/urgent for 5.3-rc3
Linus,
please pull the latest timers-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
timers-urgent-for-linus
up to: 33a58980ff3c: arm64: compat: vdso: Use legacy syscalls as fallback
A series of commits to deal with the regression caused by the generic VDSO
implementation. The usage of clock_gettime64() for 32bit compat fallback
syscalls, caused seccomp filters to kill innocent processes because they
only allow clock_gettime().
Handle the compat syscalls with clock_gettime() as before, which is not a
functional problem for the VDSO as the legacy compat application interface
is not y2038 safe anyway. It's just extra fallback code which needs to be
implemented on every architecture. It's opt in for now so that it does not
break the compile of already converted architectures in linux-next. Once
these are fixed, the #ifdeffery goes away.
So much for trying to be smart and reuse code...
Thanks,
tglx
-->
Thomas Gleixner (5):
lib/vdso/32: Remove inconsistent NULL pointer checks
lib/vdso: Move fallback invocation to the callers
lib/vdso/32: Provide legacy syscall fallbacks
x86/vdso/32: Use 32bit syscall fallback
arm64: compat: vdso: Use legacy syscalls as fallback
arch/arm64/include/asm/vdso/compat_gettimeofday.h | 40
arch/x86/include/asm/vdso/gettimeofday.h | 36 +++
lib/vdso/gettimeofday.c | 79 ++-
3 files changed, 123 insertions(+), 32 deletions(-)
diff --git a/arch/arm64/include/asm/vdso/compat_gettimeofday.h
b/arch/arm64/include/asm/vdso/compat_gettimeofday.h
index f4812777f5c5..c50ee1b7d5cd 100644
--- a/arch/arm64/include/asm/vdso/compat_gettimeofday.h
+++ b/arch/arm64/include/asm/vdso/compat_gettimeofday.h
@@ -16,6 +16,8 @@
#define VDSO_HAS_CLOCK_GETRES 1
+#define VDSO_HAS_32BIT_FALLBACK1
+
static __always_inline
int gettimeofday_fallback(struct __kernel_old_timeval *_tv,
struct timezone *_tz)
@@ -51,6 +53,23 @@ long clock_gettime_fallback(clockid_t _clkid, struct
__kernel_timespec *_ts)
return ret;
}
+static __always_inline
+long clock_gettime32_fallback(clockid_t _clkid, struct old_timespec32 *_ts)
+{
+ register struct old_timespec32 *ts asm("r1") = _ts;
+ register clockid_t clkid asm("r0") = _clkid;
+ register long ret asm ("r0");
+ register long nr asm("r7") = __NR_compat_clock_gettime;
+
+ asm volatile(
+ " swi #0\n"
+ : "=r" (ret)
+ : "r" (clkid), "r" (ts), "r" (nr)
+ : "memory");
+
+ return ret;
+}
+
static __always_inline
int clock_getres_fallback(clockid_t _clkid, struct __kernel_timespec *_ts)
{
@@ -72,6 +91,27 @@ int clock_getres_fallback(clockid_t _clkid, struct
__kernel_timespec *_ts)
return ret;
}
+static __always_inline
+int clock_getres32_fallback(clockid_t _clkid, struct old_timespec32 *_ts)
+{
+ register struct old_timespec32 *ts asm("r1") = _ts;
+ register clockid_t clkid asm("r0") = _clkid;
+ register long ret asm ("r0");
+ register long nr asm("r7") = __NR_compat_clock_getres;
+
+ /* The checks below are required for ABI consistency with arm */
+ if ((_clkid >= MAX_CLOCKS) && (_ts == NULL))
+ return -EINVAL;
+
+ asm volatile(
+ " swi #0\n"
+ : "=r" (ret)
+ : "r" (clkid), "r" (ts), "r" (nr)
+ : "memory");
+
+ return ret;
+}
+
static __always_inline u64 __arch_get_hw_counter(s32 clock_mode)
{
u64 res;
diff --git a/arch/x86/include/asm/vdso/gettimeofday.h
b/arch/x86/include/asm/vdso/gettimeofday.h
index ae91429129a6..ba71a63cdac4 100644
--- a/arch/x86/include/asm/vdso/gettimeofday.h
+++ b/arch/x86/include/asm/vdso/gettimeofday.h
@@ -96,6 +96,8 @@ long clock_getres_fallback(clockid_t _clkid, struct
__kernel_timespec *_ts)
#else
+#define VDSO_HAS_32BIT_FALLBACK1
+
static __always_inline
long clock_gettime_fallback(clockid_t _clkid, struct __kernel_timespec *_ts)
{
@@ -113,6 +115,23 @@ long clock_gettime_fallback(clockid_t _clkid, struct
__kernel_timespec *_ts)
return ret;
}
+static __always_inline
+long clock_gettime32_fallback(clockid_t _clkid, struct old_timespec32 *_ts)
+{
+ long ret;
+
+ asm (
+ "mov %%ebx, %%edx \n"
+ "mov %[clock], %%ebx \n"
+ "call __kernel_vsyscall \n"
+ "mov %%edx, %%ebx \n"
+ : "=a" (ret), "=m" (*_ts)
+ : "0" (__NR_clock_gettime), [clock] "g" (_clkid), "c" (_ts)
+ : "edx");
+
+ return ret;
+}
+
static __always_inline
long gettimeofday_fallback(struct __kernel_old_timeval *_tv,
struct timezone *_tz)
@@ -148,6 +167,23 @@ clock_getres_fallback(clockid_t _clkid, struct
__kernel_timespec *_ts)
return ret;
}
+static __always_inline
+long
Re: [PATCH net-next] netfilter: conntrack: use shared sysctl constants
On Tue, Jul 23, 2019 at 3:23 AM Matteo Croce wrote:
>
> Use shared sysctl variables for zero and one constants, as in commit
> eec4844fae7c ("proc/sysctl: add shared variables for range check")
>
> Fixes: 8f14c99c7eda ("netfilter: conntrack: limit sysctl setting for boolean
> options")
> Signed-off-by: Matteo Croce
>
followup, can anyone review it?
Thanks,
--
Matteo Croce
per aspera ad upstream
Re: [PATCH] kernel: ignore auto-generated file
On Sun, Jul 28, 2019 at 8:20 PM Matteo Croce wrote: > > kernel/config_data.h is autogenerated during the build, let's add it to > the directory .gitignore. > > Signed-off-by: Matteo Croce > CCing people as `scripts/get_maintainer.pl kernel/.gitignore` suggests -- Matteo Croce per aspera ad upstream
[GIT PULL] xfs: cleanups for 5.3-rc3
Hi Linus, Here are a couple more bug fixes that trickled in since -rc1. It's survived the usual xfstests runs and merges cleanly with this morning's master. Please let me know if anything strange happens. --D The following changes since commit 609488bc979f99f805f34e9a32c1e3b71179d10b: Linux 5.3-rc2 (2019-07-28 12:47:02 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git tags/xfs-5.3-fixes-1 for you to fetch changes up to afa1d96d1430c2138c545fb76e6dcb21222098d4: xfs: Fix possible null-pointer dereferences in xchk_da_btree_block_check_sibling() (2019-07-30 11:28:20 -0700) Changes since last update: - Avoid leaking kernel stack contents to userspace. - Fix a potential null pointer dereference in the dabtree scrub code. Darrick J. Wong (1): xfs: fix stack contents leakage in the v1 inumber ioctls Jia-Ju Bai (1): xfs: Fix possible null-pointer dereferences in xchk_da_btree_block_check_sibling() fs/xfs/scrub/dabtree.c | 6 +- fs/xfs/xfs_itable.c| 3 +++ 2 files changed, 8 insertions(+), 1 deletion(-)
Re: [PATCH] kconfig: ignore auto-generated file
On Sun, Jul 28, 2019 at 8:23 PM Matteo Croce wrote: > > scripts/kconfig/zconf.hash.c is autogenerated during the build, > let's add it to the directory .gitignore. > > Signed-off-by: Matteo Croce > Sorry, forgot to CC the maintainer and the relevant mailing list -- Matteo Croce per aspera ad upstream
Re: [PATCH v2 1/2] media: ir-kbd-i2c: convert to i2c_new_dummy_device()
Em Tue, 30 Jul 2019 19:55:54 +0200
Wolfram Sang escreveu:
> Convert this driver to use the new i2c_new_dummy_device() call and bail
> out if the dummy device cannot be registered to make failure more
> visible to the user.
>
Please don't do that.
At first glance, devm_* sounds a good idea, but we had enough issues
using it on media system.
I don't mind mind much if some SoC specific would use it, but doing
it on generic drivers is a very bad idea. We have removed almost all
devm_* calls from the media system.
The problem with devm is that it the de-allocation routines aren't
called during device unbind. They happen a way later, only when the
device itself is physically removed, or the driver is removed.
That caused lots of headaches to debug memory lifetime issues on
media.
> Signed-off-by: Wolfram Sang
> ---
>
> Change since v1:
>
> * reworded commit message because there was no NULL ptr access
>
> drivers/media/i2c/ir-kbd-i2c.c | 13 +
> 1 file changed, 5 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/media/i2c/ir-kbd-i2c.c b/drivers/media/i2c/ir-kbd-i2c.c
> index 876d7587a1da..f46717052efc 100644
> --- a/drivers/media/i2c/ir-kbd-i2c.c
> +++ b/drivers/media/i2c/ir-kbd-i2c.c
> @@ -885,9 +885,12 @@ static int ir_probe(struct i2c_client *client, const
> struct i2c_device_id *id)
> INIT_DELAYED_WORK(>work, ir_work);
>
> if (probe_tx) {
> - ir->tx_c = i2c_new_dummy(client->adapter, 0x70);
> - if (!ir->tx_c) {
> + ir->tx_c = devm_i2c_new_dummy_device(>dev,
> + client->adapter, 0x70);
> + if (IS_ERR(ir->tx_c)) {
> dev_err(>dev, "failed to setup tx i2c address");
> + err = PTR_ERR(ir->tx_c);
> + goto err_out_free;
> } else if (!zilog_init(ir)) {
> ir->carrier = 38000;
> ir->duty_cycle = 40;
> @@ -904,9 +907,6 @@ static int ir_probe(struct i2c_client *client, const
> struct i2c_device_id *id)
> return 0;
>
> err_out_free:
> - if (ir->tx_c)
> - i2c_unregister_device(ir->tx_c);
> -
> /* Only frees rc if it were allocated internally */
> rc_free_device(rc);
> return err;
> @@ -919,9 +919,6 @@ static int ir_remove(struct i2c_client *client)
> /* kill outstanding polls */
> cancel_delayed_work_sync(>work);
>
> - if (ir->tx_c)
> - i2c_unregister_device(ir->tx_c);
> -
> /* unregister device */
> rc_unregister_device(ir->rc);
>
Thanks,
Mauro
Re: [PATCH 2/4] bdi: Add bdi->id
On Sat, Aug 03, 2019 at 08:53:49AM -0700, Tejun Heo wrote: > Hey, Matthew. > > On Sat, Aug 03, 2019 at 08:39:08AM -0700, Matthew Wilcox wrote: > > On Sat, Aug 03, 2019 at 07:01:53AM -0700, Tejun Heo wrote: > > > There currently is no way to universally identify and lookup a bdi > > > without holding a reference and pointer to it. This patch adds an > > > non-recycling bdi->id and implements bdi_get_by_id() which looks up > > > bdis by their ids. This will be used by memcg foreign inode flushing. > > > > > > I left bdi_list alone for simplicity and because while rb_tree does > > > support rcu assignment it doesn't seem to guarantee lossless walk when > > > walk is racing aginst tree rebalance operations. > > > > This would seem like the perfect use for an allocating xarray. That > > does guarantee lossless walk under the RCU lock. You could get rid of the > > bdi_list too. > > It definitely came to mind but there's a bunch of downsides to > recycling IDs or using radix tree for non-compacting allocations. Ah, I wasn't sure what would happen if you recycled an ID. I agree, the radix tree is pretty horrid for monotonically increasing IDs. I'm still working on the maple tree to replace it, but that's going slower than I would like, so I can't in good conscience ask you to wait for it to be ready.
Re: [PATCH] ARM: imx: Drop imx_anatop_init()
On Wed, Jul 31, 2019 at 11:01:31AM -0700, Andrey Smirnov wrote:
> With commit b5bbe2235361 ("usb: phy: mxs: Disable external charger
> detect in mxs_phy_hw_init()") in tree all of the necessary charger
> setup is done by the USB PHY driver which covers all of the affected
> i.MX6 SoCs.
>
> NOTE: Imx_anatop_init() was also called for i.MX7D, but looking at its
> datasheet it appears to have a different USB PHY IP block, so
> executing i.MX6 charger disable configuration seems unnecessary.
>
> Signed-off-by: Andrey Smirnov
> Cc: Chris Healy
> Cc: Shawn Guo
> Cc: Fabio Estevam
> Cc: Peter Chen
> Cc: linux-...@nxp.com
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
Applied, thanks.
Re: [PATCH 09/20] ext4: Initialize timestamps limits
On Sat, Aug 03, 2019 at 11:30:22AM +0200, Arnd Bergmann wrote: > > I see in the ext4 code that we always try to expand i_extra_size > to s_want_extra_isize in ext4_mark_inode_dirty(), and that > s_want_extra_isize is always at least s_min_extra_isize, so > we constantly try to expand the inode to fit. Yes, we *try*. But we may not succeed. There may actually be a problem here if the cause is due to there simply is no space in the external xattr block, so we might try and try every time we try to modify that inode, and it would be a performance mess. If it's due to there being no room in the current transaction, then it's highly likely it will succeed the next time. > Did older versions of ext4 or ext3 ignore s_min_extra_isize > when creating inodes despite > EXT4_FEATURE_RO_COMPAT_EXTRA_ISIZE, > or is there another possibility I'm missing? s_min_extra_isize could get changed in order to make room for some new file system feature --- such as extended timestamps. That's how we might take an old ext3 file system with an inode size > 128, and try to evacuate space for extended timestamps, on a best efforts basis. And since it's best efforts is why Red Hat refuses to support that case. It'll work 99.9% of the time, but they don't want to deal with the 0.01% cases showing up at their help desk. If you want to pretend that file systems never get upgraded, then life is much simpler. The general approach is that for less-sophisticated customers (e.g., most people running enterprise distros) file system upgrades are not a thing. But for sophisticated users, we do try to make thing work for people who are aware of the risks / caveats / rough edges. Google won't have been able to upgrade thousands and thousands of servers in data centers all over the world if we limited ourselves to Red Hat's support restrictions. Backup / reformat / restore really isn't a practical rollout strategy for many exabytes of file systems. It sounds like your safety checks / warnings are mostly targeted at low-information customers, no? - Ted
Re: [PATCH 5.2 00/20] 5.2.6-stable review
On 8/2/19 2:39 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 5.2.6 release. There are 20 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun 04 Aug 2019 09:19:34 AM UTC. Anything received after that time might be too late. Build results: total: 159 pass: 159 fail: 0 Qemu test results: total: 364 pass: 364 fail: 0 Guenter
Re: [PATCH 4.19 00/32] 4.19.64-stable review
On 8/2/19 2:39 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.19.64 release. There are 32 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun 04 Aug 2019 09:19:34 AM UTC. Anything received after that time might be too late. Build results: total: 156 pass: 156 fail: 0 Qemu test results: total: 364 pass: 364 fail: 0 Guenter
Re: [PATCH 4.14 00/25] 4.14.136-stable review
On 8/2/19 2:39 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.14.136 release. There are 25 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun 04 Aug 2019 09:19:34 AM UTC. Anything received after that time might be too late. Build results: total: 172 pass: 172 fail: 0 Qemu test results: total: 346 pass: 346 fail: 0 Guenter
Re: [PATCH 4.9 000/223] 4.9.187-stable review
On 8/2/19 2:33 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.9.187 release. There are 223 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun 04 Aug 2019 09:19:34 AM UTC. Anything received after that time might be too late. Build results: total: 172 pass: 172 fail: 0 Qemu test results: total: 333 pass: 333 fail: 0 Guenter
Re: [PATCH 4.4 000/158] 4.4.187-stable review
On 8/2/19 2:27 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.4.187 release. There are 158 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun 04 Aug 2019 09:19:34 AM UTC. Anything received after that time might be too late. Build results: total: 170 pass: 170 fail: 0 Qemu test results: total: 301 pass: 301 fail: 0 Guenter
Re: [PATCH 2/4] bdi: Add bdi->id
Hey, Matthew. On Sat, Aug 03, 2019 at 08:39:08AM -0700, Matthew Wilcox wrote: > On Sat, Aug 03, 2019 at 07:01:53AM -0700, Tejun Heo wrote: > > There currently is no way to universally identify and lookup a bdi > > without holding a reference and pointer to it. This patch adds an > > non-recycling bdi->id and implements bdi_get_by_id() which looks up > > bdis by their ids. This will be used by memcg foreign inode flushing. > > > > I left bdi_list alone for simplicity and because while rb_tree does > > support rcu assignment it doesn't seem to guarantee lossless walk when > > walk is racing aginst tree rebalance operations. > > This would seem like the perfect use for an allocating xarray. That > does guarantee lossless walk under the RCU lock. You could get rid of the > bdi_list too. It definitely came to mind but there's a bunch of downsides to recycling IDs or using radix tree for non-compacting allocations. Thanks. -- tejun
Re: [PATCH v3] ARM: dts: vf610-bk4: Fix qspi node description
On Wed, Jul 31, 2019 at 04:11:51PM +0200, Lukasz Majewski wrote:
> Before this change the device tree description of qspi node for
> second memory on BK4 board was wrong (applicable to old, removed
> fsl-quadspi.c driver).
>
> As a result this memory was not recognized correctly when used
> with the new spi-fsl-qspi.c driver.
>
> From the dt-bindings:
>
> "Required SPI slave node properties:
> - reg: There are two buses (A and B) with two chip selects each.
> This encodes to which bus and CS the flash is connected:
> <0>: Bus A, CS 0
> <1>: Bus A, CS 1
> <2>: Bus B, CS 0
> <3>: Bus B, CS 1"
>
> According to above with new driver the second SPI-NOR memory shall
> have reg=<2> as it is connected to Bus B, CS 0.
>
> Fixes: a67d2c52a82f ("ARM: dts: Add support for Liebherr's BK4 device (vf610
> based)")
> Suggested-by: Fabio Estevam
> Signed-off-by: Lukasz Majewski
> Reviewed-by: Fabio Estevam
Applied, thanks.
Re: Possible mem cgroup bug in kernels between 4.18.0 and 5.3-rc1.
Masoud, will you try this patch?
By the way, is /sys/fs/cgroup/memory/leaker/memory.usage_in_bytes remains
non-zero
despite /sys/fs/cgroup/memory/leaker/tasks became empty due to memcg OOM killer
expected?
Deleting big-data-file.bin after memcg OOM killer reduces some, but still
remains
non-zero.
>From 2f92c70f390f42185c6e2abb8dda98b1b7d02fa9 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Sun, 4 Aug 2019 00:41:30 +0900
Subject: [PATCH] memcg, oom: don't require __GFP_FS when invoking memcg OOM
killer
Masoud Sharbiani noticed that commit 29ef680ae7c21110 ("memcg, oom: move
out_of_memory back to the charge path") broke memcg OOM called from
__xfs_filemap_fault() path. It turned out that try_chage() is retrying
forever without making forward progress because mem_cgroup_oom(GFP_NOFS)
cannot invoke the OOM killer due to commit 3da88fb3bacfaa33 ("mm, oom:
move GFP_NOFS check to out_of_memory"). Regarding memcg OOM, we need to
bypass GFP_NOFS check in order to guarantee forward progress.
Signed-off-by: Tetsuo Handa
Reported-by: Masoud Sharbiani
Bisected-by: Masoud Sharbiani
Fixes: 29ef680ae7c21110 ("memcg, oom: move out_of_memory back to the charge
path")
---
mm/oom_kill.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index eda2e2a..26804ab 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -1068,9 +1068,10 @@ bool out_of_memory(struct oom_control *oc)
* The OOM killer does not compensate for IO-less reclaim.
* pagefault_out_of_memory lost its gfp context so we have to
* make sure exclude 0 mask - all other users should have at least
-* ___GFP_DIRECT_RECLAIM to get here.
+* ___GFP_DIRECT_RECLAIM to get here. But mem_cgroup_oom() has to
+* invoke the OOM killer even if it is a GFP_NOFS allocation.
*/
- if (oc->gfp_mask && !(oc->gfp_mask & __GFP_FS))
+ if (oc->gfp_mask && !(oc->gfp_mask & __GFP_FS) && !is_memcg_oom(oc))
return true;
/*
--
1.8.3.1
Re: [PATCH v3 2/2] ARM: dts: imx6ul-kontron-n6310: Add Kontron i.MX6UL N6310 SoM and boards
On Mon, Jul 29, 2019 at 07:20:07PM +0200, Krzysztof Kozlowski wrote: > Add support for i.MX6UL modules from Kontron Electronics GmbH (before > acquisition: Exceet Electronics) and evalkit boards based on it: > > 1. N6310 SOM: i.MX6 UL System-on-Module, a 25x25 mm solderable module >(LGA pads and pin castellations) with 256 MB RAM, 1 MB NOR-Flash, >256 MB NAND and other interfaces, > 2. N6310 S: evalkit, w/wo eMMC, without display, > 3. N6310 S 43: evalkit with 4.3" display, > 4. N6310 S 50: evalkit with 5.0" display. > > This includes device nodes for unsupported displays (Admatec > T043C004800272T2A and T070P133T0S301). Do not include unsupported devices. > > The work is based on Exceet/Kontron source code (GPLv2) with numerous > changes: > 1. Reorganize files, > 2. Rename Exceet -> Kontron, > 3. Rename models/compatibles to match newest Kontron product naming, > 4. Fix coding style errors and adjust to device tree coding guidelines, > 5. Fix DTC warnings, > 6. Extend compatibles so eval boards inherit the SoM compatible, > 7. Use defines instead of GPIO and interrupt flag values, > 8. Use proper vendor compatible for Macronix SPI NOR, > 9. Sort nodes alphabetically. > > Signed-off-by: Krzysztof Kozlowski > > --- > > Changes since v2, after Fabio's review: > 1. Add "imx6ul" compatible to board name (that's what I understood from >review), > 2. Add vendor/device prefix to eeprom and document the compatible, > 3. Use "admatecde" as vendor compatible to avoid confusion with Admatec >AG in Switzerland (also making LCD panels), > 4. Use generic names for nodes, > 5. Use IRQ_TYPE_LEVEL_LOW, > 6. Move iomux to the end of files, > 7. Remove regulators node (include regulators in top level), > 8. Remove cpu clock-frequency, > 9. Other minor fixes pointed by Fabio. > > Changes since v1, after Frieder's review: > 1. Remove unneeded license notes, > 2. Add Kontron copyright (2018), > 3. Rename the files/models/compatibles to new naming - N6310, > 4. Remove unneeded CPU operating points override, > 5. Switch regulator nodes into simple children nodes without addresses >(so not simple bus), > 6. Use proper vendor compatible for Macronix SPI NOR. > --- > .../devicetree/bindings/arm/fsl.yaml | 4 + > .../devicetree/bindings/eeprom/at25.txt | 1 + Please make them two separate patches. > arch/arm/boot/dts/Makefile| 3 + > .../boot/dts/imx6ul-kontron-n6310-s-43.dts| 119 + > .../boot/dts/imx6ul-kontron-n6310-s-50.dts| 119 + Are they identical except the display node? Please manage to save duplicated data. > arch/arm/boot/dts/imx6ul-kontron-n6310-s.dts | 420 ++ > .../boot/dts/imx6ul-kontron-n6310-som.dtsi| 134 ++ > 7 files changed, 800 insertions(+) > create mode 100644 arch/arm/boot/dts/imx6ul-kontron-n6310-s-43.dts > create mode 100644 arch/arm/boot/dts/imx6ul-kontron-n6310-s-50.dts > create mode 100644 arch/arm/boot/dts/imx6ul-kontron-n6310-s.dts > create mode 100644 arch/arm/boot/dts/imx6ul-kontron-n6310-som.dtsi > > diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml > b/Documentation/devicetree/bindings/arm/fsl.yaml > index 7294ac36f4c0..6a6c09d67dea 100644 > --- a/Documentation/devicetree/bindings/arm/fsl.yaml > +++ b/Documentation/devicetree/bindings/arm/fsl.yaml > @@ -161,6 +161,10 @@ properties: > items: >- enum: >- fsl,imx6ul-14x14-evk # i.MX6 UltraLite 14x14 EVK Board > + - kontron,imx6ul-n6310-som # Kontron N6310 SOM > + - kontron,imx6ul-n6310-s# Kontron N6310 S Board > + - kontron,imx6ul-n6310-s-43 # Kontron N6310 S 43 Board > + - kontron,imx6ul-n6310-s-50 # Kontron N6310 S 50 Board >- const: fsl,imx6ul > >- description: i.MX6ULL based Boards > diff --git a/Documentation/devicetree/bindings/eeprom/at25.txt > b/Documentation/devicetree/bindings/eeprom/at25.txt > index b3bde97dc199..42577dd113dd 100644 > --- a/Documentation/devicetree/bindings/eeprom/at25.txt > +++ b/Documentation/devicetree/bindings/eeprom/at25.txt > @@ -3,6 +3,7 @@ EEPROMs (SPI) compatible with Atmel at25. > Required properties: > - compatible : Should be ",", and generic value "atmel,at25". >Example "," values: > +"anvo,anv32e61w" > "microchip,25lc040" > "st,m95m02" > "st,m95256" > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile > index 9159fa2cea90..28b6cb3454a3 100644 > --- a/arch/arm/boot/dts/Makefile > +++ b/arch/arm/boot/dts/Makefile > @@ -569,6 +569,9 @@ dtb-$(CONFIG_SOC_IMX6UL) += \ > imx6ul-geam.dtb \ > imx6ul-isiot-emmc.dtb \ > imx6ul-isiot-nand.dtb \ > + imx6ul-kontron-n6310-s.dtb \ > + imx6ul-kontron-n6310-s-43.dtb \ > + imx6ul-kontron-n6310-s-50.dtb \ > imx6ul-liteboard.dtb \ > imx6ul-opos6uldev.dtb \ > imx6ul-pico-hobbit.dtb \ > diff --git
Re: [PATCH] arm64: defconfig: CONFIG_DRM_ETNAVIV=m
On Fri, Aug 02, 2019 at 02:20:28PM +0200, Christian Gmeiner wrote: > For imx8 we want to enable etnaviv, let's enable it > in defconfig, it will be useful to have it enabled for KernelCI > boot and runtime testing. > > Signed-off-by: Christian Gmeiner Applied, thanks.
Re: Device to write to all (serial) consoles
On Sat, Aug 03, 2019 at 03:55:37PM +0200, Greg Kroah-Hartman wrote: > On Sat, Aug 03, 2019 at 03:23:23PM +0200, Adam Borowski wrote: > > On Fri, Aug 02, 2019 at 09:59:06PM +0200, Paul Menzel wrote: > > > Because the cable is always connected to the port on the back side, and > > > sometimes the port in the front has ID 0, and the one in the back 1, and > > > other times vice versa. We do not want to track that, and it would be > > > convenient to just write to both ports. > > > > Sounds like an XY problem then: what you want is not writing to all ports, > > but to have the port assignments stable (see also: disk device reordering). > > You can get that information from the symlinks in /dev/serial/ which > udev creates. Doesn't seem to work for me, for any ttyS0 ttyS1 ttySAC1 device: Box one, PCIe card + one USB dongle: 07:00.0 Serial controller: MosChip Semiconductor Technology Ltd. MCS9922 PCIe Multi-I/O Controller 07:00.1 Serial controller: MosChip Semiconductor Technology Ltd. MCS9922 PCIe Multi-I/O Controller Bus 003 Device 004: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0 /dev/serial/by-path/pci-:0b:00.3-usb-0:4:1.0-port0 Only ttyUSB0 is there. Box two, on-board + one USB dongle: [3.404340] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled [3.431287] 00:01: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A Bus 001 Device 002: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP2102/CP2109 UART Bridge Controller [CP210x family] /dev/serial/by-id/usb-Silicon_Labs_CP2104_USB_to_UART_Bridge_Controller_00DB1604-if00-port0 /dev/serial/by-path/pci-:00:14.0-usb-0:1:1.0-port0 Box three: RockPro64, euler + USB dongle, kernel 4.4. Box four: Pine64, euler. Box five: Odroid-U2, something GPIOish (ttySAC1), kernel 5.0. Most are running kernel 5.2, Debian unstable. And indeed, in /lib/udev/rules.d/60-serial.rules : # /dev/serial/by-path/, /dev/serial/by-id/ for USB devices KERNEL!="ttyUSB[0-9]*|ttyACM[0-9]*", GOTO="serial_end" Like me, Paul is using ttyS0 for server-side. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢰⠒⠀⣿⡁ 10 people enter a bar: 1 who understands binary, ⢿⡄⠘⠷⠚⠋⠀ 1 who doesn't, D who prefer to write it as hex, ⠈⠳⣄ and 1 who narrowly avoided an off-by-one error.
Re: [PATCH] ARM: dts: imx25-pdk: native-mode is part of display-timings
On Mon, Jul 29, 2019 at 04:23:16PM +0200, Martin Kaiser wrote: > Move the native-mode property inside the display-timings node. > > According to > Documentation/devicetree/bindings/display/panel/display-timing.txt. > native-mode is a property of the display-timings node. > > If it's located outside of display-timings, the native-mode setting is > ignored and the first display timing is used (which is a problem only if > someone adds another display timing). > > Signed-off-by: Martin Kaiser Applied, thanks.
Re: [PATCH v3] clk: imx8mq: Mark AHB clock as critical
On Tue, Jul 30, 2019 at 10:22:55AM +0300, Abel Vesa wrote:
> Initially, the TMU_ROOT clock was marked as critical, which automatically
> made the AHB clock to stay always on. Since the TMU_ROOT clock is not
> marked as critical anymore, following commit:
>
> 431bdd1df48e ("clk: imx8mq: Remove CLK_IS_CRITICAL flag for
> IMX8MQ_CLK_TMU_ROOT")
The commit ID is not stable before the commit actually lands mainline.
I could possibly rebase the branch.
>
> all the clocks that derive from ipg_root clock (and implicitly ahb clock)
> would also have to enable, along with their own gate, the AHB clock.
>
> But considering that AHB is actually a bus that has to be always on, we mark
> it as critical in the clock provider driver and then all the clocks that
> derive from it can be controlled through the dedicated per IP gate which
> follows after the ipg_root clock.
>
> Signed-off-by: Abel Vesa
> Tested-by: Daniel Baluta
> Fixes: 431bdd1df48e ("clk: imx8mq: Remove CLK_IS_CRITICAL flag for
> IMX8MQ_CLK_TMU_ROOT")
Dropped commit ID above and Fixes tag here, and applied the patch.
Thanks for the fixing.
Shawn
Re: [PATCH][net-next][V2] net/mlx5: remove self-assignment on esw->dev
On Sat, Aug 3, 2019 at 7:54 PM Colin King wrote:
>
> From: Colin Ian King
>
> There is a self assignment of esw->dev to itself, clean this up by
> removing it. Also make dev a const pointer.
>
> Addresses-Coverity: ("Self assignment")
> Fixes: 6cedde451399 ("net/mlx5: E-Switch, Verify support QoS element type")
> Signed-off-by: Colin Ian King
> ---
>
> V2: make dev const
>
> ---
> drivers/net/ethernet/mellanox/mlx5/core/eswitch.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
> b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
> index f4ace5f8e884..de0894b695e3 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
> @@ -1413,7 +1413,7 @@ static int esw_vport_egress_config(struct mlx5_eswitch
> *esw,
>
> static bool element_type_supported(struct mlx5_eswitch *esw, int type)
> {
> - struct mlx5_core_dev *dev = esw->dev = esw->dev;
> + const struct mlx5_core_dev *dev = esw->dev;
>
> switch (type) {
> case SCHEDULING_CONTEXT_ELEMENT_TYPE_TSAR:
> --
> 2.20.1
>
Reviewed-by: Parav Pandit
RE: [PATCH V3 2/2] cpufreq: intel_pstate: Implement ->resolve_freq()
On 2019.08.02 02:28 Rafael J. Wysocki wrote: > On Friday, August 2, 2019 11:17:55 AM CEST Rafael J. Wysocki wrote: >> On Fri, Aug 2, 2019 at 7:44 AM Viresh Kumar wrote: >>> >>> Intel pstate driver exposes min_perf_pct and max_perf_pct sysfs files, >>> which can be used to force a limit on the min/max P state of the driver. >>> Though these files eventually control the min/max frequencies that the >>> CPUs will run at, they don't make a change to policy->min/max values. >> >> That's correct. >> >>> When the values of these files are changed (in passive mode of the >>> driver), it leads to calling ->limits() callback of the cpufreq >>> governors, like schedutil. On a call to it the governors shall >>> forcefully update the frequency to come within the limits. >> >> OK, so the problem is that it is a bug to invoke the governor's ->limits() >> callback without updating policy->min/max, because that's what >> "limits" mean to the governors. >> >> Fair enough. > > AFAICS this can be addressed by adding PM QoS freq limits requests of each > CPU to > intel_pstate in the passive mode such that changing min_perf_pct or > max_perf_pct > will cause these requests to be updated. All governors for the intel_cpufreq (intel_pstate in passive mode) CPU frequency scaling driver are broken with respect to this issue, not just the schedutil governor. My initial escalation had been focused on acpi-cpufreq/schedutil and intel_cpufreq/schedutil, as they were both broken, and both fixed by my initially submitted reversion. What can I say, I missed that other intel_cpufreq governors were also involved. I tested all of them: conservative ondemand userspace powersave performance schedutil Note that no other governor uses resolve_freq(). ... Doug
Re: [PATCH] arm64: dts: imx8mq-evk: Unbypass audio_pll1
On Sun, Jul 28, 2019 at 05:08:17PM +0300, Daniel Baluta wrote: > Making audio_pll1 parent of audio_pll1_bypass, will allow > setting rates multiple of 8000 for children. > > After unbypass clk hierarchy looks like this: > * osc_25m >* audio_pll1 > * audio_pll1_bypass >* audio_pll1_out > * sai2 >* sai2_root_clk > > Signed-off-by: Daniel Baluta Applied, thanks.
Re: [PATCH] ARM: dts: imx: Cleanup style around assignment operator
On Sat, Jul 27, 2019 at 04:26:40PM +0200, Krzysztof Kozlowski wrote: > Use a space before and after assignment operator to have consistent > style. > > Signed-off-by: Krzysztof Kozlowski Applied, thanks.
Re: please revert "drm/msm: Use the correct dma_sync calls in msm_gem"
On Fri, Aug 2, 2019 at 11:19 PM Christoph Hellwig wrote:
>
> On Fri, Aug 02, 2019 at 03:06:10PM -0700, Rob Clark wrote:
> > Sorry, this is just a temporary band-aid for v5.3 to get things
> > working again. Yes, I realize it is a complete hack.
>
> My main problem is here that you badly hack a around a problem without
> talking to the relevant maintainers, and by abusing even more internal
> APIs. As said get_dma_ops isn't really for driver use (although we
> have a few that use it for not quite as bad reason we are trying to get
> rid off). And as also said your abuse of the DMA API will blow up
> with dma-debug use quite badly. You might also corrupt the dma_address
> in the scatterlist in ways that aren't intended - as the call to
> dma_map_sg will allocate new iova space you are getting different
> results from whatever you expect to actually get from your iommu API
> usage. This might or might no matter in the end, but you really should
> consult the maintainers first.
>
> > The root problem is that I'm using the DMA API in the first place. I
> > don't actually use the DMA API to map buffers, for various reasons,
> > but instead manage the iommu_domain directly.
>
> Yes, and this has been going on for years, without any obvious attempt
> to address it at the API level before..
99% of my time goes to mesa and r/e, so having the argument about
dealing w/ cache directly simply wasn't a big enough fire to deal with
until now, unfortunately.
(Admittedly, there is room here for someone with more bandwidth to
take on drm/msm maintainer role.. but someone needs to do it. Sean
has been pitching in on the display side more recently, which has been
a big help.)
> > Because arm/arm64 cache ops are not exported to modules, so currently
> > I need to abuse the DMA API for cache operations (really just to clean
> > pages if I need to mmap them uncached/writecombine). Originally I was
> > doing that w/ dma_{map,unmap}_sg. But to avoid debug splats I
> > switched that to dma_sync_sg (see
> > 0036bc73ccbe7e600a3468bf8e8879b122252274). But now it seems the
> > dma-direct ops are unhappy w/ dma_sync without a dma_map (AFAICT).
>
> Russell has been very strict about not exporting the cache ops, and all
> for the right reasons. Cache maintainance for not dma coherent devices
> is hard, and without a proper API that has arch input for even which
> calls are used for cache flushing chances of bugs are extremely high.
>
> I see two proper ways out of this mess: either we actually make msm
> use the DMA API, so I'd be curious of what is missing that forces you
> to use the low-level iommu API. Or we need to enhance the iommu API
> with a similar ownership concepts as the DMA API. Which probably is
> a good thing even if we move msm over to the DMA API.
There are a few reasons we need to manage the GPU's address space
directly, most of which are stalled on some iommu changes, that I wish
I had more time to push for. In particular, we need to move to
per-context pagetables (so each GL context has it's own GPU address
space). Once we get there, we'd also like to enable SVM/SVA so GPU
can share address space with the userspace process (which requires
stall/resume and iommu fault handler to run in a context that can
sleep).
Fitting that into the DMA API doesn't really make sense to me.
I'm not entirely sure that fitting cache maintenance into the IOMMU
makes a huge amount of sense either, since the issue is really about
the CPU cache. And I doubt the GPU is going to fit into a nice policy
of page ownership. There are a number of cases where both CPU and GPU
are accessing the same buffers, and unmapping/remapping to iommu is
either not possible (because GPU is actively accessing another part of
the buffer) or prohibitive from a performance standpoint.
As far as cache maintenance being hard, I'm not really sure I buy
that.. at least not for arm64. (And probably not even w/ the limited
# of armv7 cores that can be paired with drm/msm.)
> > (On some generations of hw, the iommu is attached to the device node
> > that maps to the drm device, which is passed to dma_map/dma_sync. On
> > other generations the iommu is attached to a sub-device. Changing
> > this would break dtb compatibility.. so for now I need to handle both
> > iommu-ops and direct-ops cases.)
>
> Or you always call call on a struct device that has the iommu, that
> is match on the generic, and pick a different device. That would in
> many ways seem preferably over the current hack, even if that also is
> just a horribly band-aid.
I suppose picking a device w/ iommu would *mostly* work, except for
a2xx (which has no IOMMU, but has it's own internal GPUMMU instead..
so there is no device with iommu ops)
We could perhaps, based on compatible, set a flag to use either
dma_sync_* or dma_map_* which would avoid using get_dma_ops() (but
otherwise doesn't seem like much of an improvement, I guess)
BR,
-R
Re: [PATCH] KEYS: trusted: allow module init if TPM is inactive or deactivated
On Fri, 2019-08-02 at 15:23 -0500, Tyler Hicks wrote: > That wasn't the conclusion that I came to. I prefer Robert's proposed > change to trusted.ko. > > How do you propose that this be fixed in eCryptfs? > > Removing encrypted_key support from eCryptfs is the only way that I can > see to fix the bug in eCryptfs. That support has been there since 2011. > I'm not sure of the number of users that would be broken by removing > encrypted_key support. I don't think the number is high but I can't say > that confidently. Looking at the documentation [1] it is stated that "Encrypted keys do not depend on a TPM, and are faster, as they use AES for encryption/decryption." Why would you need to remove support for encrypted keys? Isn't it a regression in encrypted keys to hard depend on trusted keys given what the documentation says? > Roberto, what was your use case when you added encrypted_key support to > eCryptfs back then? Are you aware of any users of eCryptfs + > encrypted_keys? > > Jarkko, removing a long-standing feature is potentially more disruptive > to users than adding a workaround to trusted.ko which already requires a > similar workaround. I don't think that I agree with you on the proper > fix here. There is nothing to disagree or agree. I just try to get the picture since ecryptfs is relatively alien to me. [1] https://www.kernel.org/doc/html/v4.13/security/keys/trusted-encrypted.html /Jarkko
[GIT PULL] RISC-V updates for v5.3-rc3
Linus, The following changes since commit 609488bc979f99f805f34e9a32c1e3b71179d10b: Linux 5.3-rc2 (2019-07-28 12:47:02 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git tags/riscv/for-v5.3-rc3 for you to fetch changes up to b7edabfe843805b7ab8a91396b0782042a289308: riscv: defconfig: align RV64 defconfig to the output of "make savedefconfig" (2019-07-31 12:26:10 -0700) RISC-V updates for v5.3-rc3 Three minor RISC-V-related changes for v5.3-rc3: - Add build ID to VDSO builds to avoid a double-free in perf when libelf isn't used - Align the RV64 defconfig to the output of "make savedefconfig" so subsequent defconfig patches don't get out of hand - Drop a superfluous DT property from the FU540 SoC DT data (since it must be already set in board data that includes it) Mao Han (1): riscv: Fix perf record without libelf support Paul Walmsley (2): riscv: dts: fu540-c000: drop "timebase-frequency" riscv: defconfig: align RV64 defconfig to the output of "make savedefconfig" arch/riscv/boot/dts/sifive/fu540-c000.dtsi | 1 - arch/riscv/configs/defconfig | 10 +- arch/riscv/kernel/vdso/Makefile| 2 +- 3 files changed, 6 insertions(+), 7 deletions(-)
Re: memory leak in pty_common_install
On 02. 08. 19, 8:23, Jiri Slaby wrote: > On 30. 07. 19, 17:08, syzbot wrote: >> Hello, >> >> syzbot found the following crash on: >> >> HEAD commit: 6789f873 Merge tag 'pm-5.3-rc2' of >> git://git.kernel.org/pu.. >> git tree: upstream >> console output: https://syzkaller.appspot.com/x/log.txt?x=1696897c60 >> kernel config: https://syzkaller.appspot.com/x/.config?x=339b6a6b3640d115 >> dashboard link: >> https://syzkaller.appspot.com/bug?extid=bdebcbf44250d75bdd82 >> compiler: gcc (GCC) 9.0.0 20181231 (experimental) >> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=153d754460 >> >> IMPORTANT: if you fix the bug, please add the following tag to the commit: >> Reported-by: syzbot+bdebcbf44250d75bd...@syzkaller.appspotmail.com >> >> BUG: memory leak >> unreferenced object 0x88810d84d400 (size 512): >> comm "syz-executor.5", pid 7522, jiffies 4294954305 (age 14.260s) >> hex dump (first 32 bytes): >> 50 d4 84 0d 81 88 ff ff e0 ff ff ff 0f 00 00 00 P... >> 10 d4 84 0d 81 88 ff ff 10 d4 84 0d 81 88 ff ff >> backtrace: >> [<3d61da44>] kmemleak_alloc_recursive >> include/linux/kmemleak.h:43 [inline] >> [<3d61da44>] slab_post_alloc_hook mm/slab.h:522 [inline] >> [<3d61da44>] slab_alloc mm/slab.c:3319 [inline] >> [<3d61da44>] kmem_cache_alloc_trace+0x145/0x2c0 mm/slab.c:3548 >> [] kmalloc include/linux/slab.h:552 [inline] >> [ ] pty_common_install+0x4e/0x2b0 >> drivers/tty/pty.c:391 > > So this is tty_port for o_tty. > > ... > >> BUG: memory leakx >> unreferenced object 0x88810e639800 (size 1024): >> comm "syz-executor.5", pid 7522, jiffies 4294954305 (age 14.260s) >> hex dump (first 32 bytes): >> 01 54 00 00 01 00 00 00 00 00 00 00 00 00 00 00 .T.. >> 00 83 fa 19 82 88 ff ff a0 7f 9b 83 ff ff ff ff >> backtrace: >> [<3d61da44>] kmemleak_alloc_recursive >> include/linux/kmemleak.h:43 [inline] >> [<3d61da44>] slab_post_alloc_hook mm/slab.h:522 [inline] >> [<3d61da44>] slab_alloc mm/slab.c:3319 [inline] >> [<3d61da44>] kmem_cache_alloc_trace+0x145/0x2c0 mm/slab.c:3548 >> [<1cfffc30>] kmalloc include/linux/slab.h:552 [inline] >> [<1cfffc30>] kzalloc include/linux/slab.h:748 [inline] >> [<1cfffc30>] alloc_tty_struct+0x3f/0x290 >> drivers/tty/tty_io.c:2981 >> [<1946a70c>] pty_common_install+0xac/0x2b0 >> drivers/tty/pty.c:399 > > And this is o_tty proper. So we leak whole o_tty under some > circumstances... Trying to reproduce. And I failed. Looking into the code, I also can't find the scenario. One virtually possible could be hangup_work being cancelled while release_one_tty was scheduled on it. But I see this nowhere. A C reproducer would help. > BTW the reproducer says: > ioctl$TCSETS(r0, 0x40045431, ...) > > But 0x40045431 is TIOCSPTLCK, not TCSETS. > > thanks,-- js suse labs
Re: [PATCH] platform/x86: silead_dmi: Add touchscreen platform data for the Chuwi Surbook Mini tablet.
Hi,
On 03-08-19 16:12, Giang Le wrote:
Hmm, could have used a somewhat more verbose commit message above
the Signed-off-by line, but I guess there is not that much to write
about this patch.
Signed-off-by: Giang Le
Patch looks good to me:
Reviewed-by: Hans de Goede
Regards,
Hans
---
drivers/platform/x86/touchscreen_dmi.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/platform/x86/touchscreen_dmi.c
b/drivers/platform/x86/touchscreen_dmi.c
index 4370e4add83a..72535b0268eb 100644
--- a/drivers/platform/x86/touchscreen_dmi.c
+++ b/drivers/platform/x86/touchscreen_dmi.c
@@ -136,6 +136,22 @@ static const struct ts_dmi_data chuwi_vi10_data = {
.properties = chuwi_vi10_props,
};
+static const struct property_entry chuwi_surbook_mini_props[] = {
+ PROPERTY_ENTRY_U32("touchscreen-min-x", 88),
+ PROPERTY_ENTRY_U32("touchscreen-min-y", 13),
+ PROPERTY_ENTRY_U32("touchscreen-size-x", 2040),
+ PROPERTY_ENTRY_U32("touchscreen-size-y", 1524),
+ PROPERTY_ENTRY_STRING("firmware-name", "gsl1680-chuwi-surbook-mini.fw"),
+ PROPERTY_ENTRY_U32("silead,max-fingers", 10),
+ PROPERTY_ENTRY_BOOL("touchscreen-inverted-y"),
+ { }
+};
+
+static const struct ts_dmi_data chuwi_surbook_mini_data = {
+ .acpi_name = "MSSL1680:00",
+ .properties = chuwi_surbook_mini_props,
+};
+
static const struct property_entry connect_tablet9_props[] = {
PROPERTY_ENTRY_U32("touchscreen-min-x", 9),
PROPERTY_ENTRY_U32("touchscreen-min-y", 10),
@@ -646,6 +662,14 @@ static const struct dmi_system_id touchscreen_dmi_table[]
= {
DMI_MATCH(DMI_PRODUCT_NAME, "S165"),
},
},
+ {
+ /* Chuwi Surbook Mini (CWI540) */
+ .driver_data = (void *)_surbook_mini_data,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Hampoo"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "C3W6_AP108_4G"),
+ },
+ },
{
/* Connect Tablet 9 */
.driver_data = (void *)_tablet9_data,
Re: [PATCH 4/8] thunderbolt: Do not fail adding switch if some port is not implemented
On Fri, Jul 05, 2019 at 12:57:56PM +0300, Mika Westerberg wrote: > There are two ways to mark a port as unimplemented. Typical way is to > return port type as TB_TYPE_INACTIVE when its config space is read. > Alternatively if the port is not physically present (such as ports 10 > and 11 in ICL) reading from port config space returns > TB_CFG_ERROR_INVALID_CONFIG_SPACE instead. Currently the driver bails > out from adding the switch if it receives any error during port > inititialization which is wrong. > > Handle this properly and just leave the port as TB_TYPE_INACTIVE before > continuing to the next port. Your patch may also cause this snippet in eeprom.c to become obsolete: /* Port 5 is inaccessible on this gen 1 controller */ if (sw->config.device_id == PCI_DEVICE_ID_INTEL_LIGHT_RIDGE) sw->ports[5].disabled = true; To verify this hypothesis, one needs to comment out the call to tb_drom_copy_efi() as well as the above-quoted snippet and boot on a Mac with Light Ridge. The driver should hit an error without your patch and it may work correctly with your patch. Thanks, Lukas
[PATCH] i2c: stm32: Use the correct style for SPDX License Identifier
This patch corrects the SPDX License Identifier style in header file related to STM32 Driver for I2C hardware bus support. For C header files Documentation/process/license-rules.rst mandates C-like comments (opposed to C source files where C++ style should be used) Changes made by using a script provided by Joe Perches here: https://lkml.org/lkml/2019/2/7/46 Suggested-by: Joe Perches Signed-off-by: Nishad Kamdar --- drivers/i2c/busses/i2c-stm32.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-stm32.h b/drivers/i2c/busses/i2c-stm32.h index 868755f82f88..2c21893905a3 100644 --- a/drivers/i2c/busses/i2c-stm32.h +++ b/drivers/i2c/busses/i2c-stm32.h @@ -1,4 +1,4 @@ -// SPDX-License-Identifier: GPL-2.0 +/* SPDX-License-Identifier: GPL-2.0 */ /* * i2c-stm32.h * -- 2.17.1
[PATCH] platform/x86: silead_dmi: Add touchscreen platform data for the Chuwi Surbook Mini tablet.
Signed-off-by: Giang Le
---
drivers/platform/x86/touchscreen_dmi.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/platform/x86/touchscreen_dmi.c
b/drivers/platform/x86/touchscreen_dmi.c
index 4370e4add83a..72535b0268eb 100644
--- a/drivers/platform/x86/touchscreen_dmi.c
+++ b/drivers/platform/x86/touchscreen_dmi.c
@@ -136,6 +136,22 @@ static const struct ts_dmi_data chuwi_vi10_data = {
.properties = chuwi_vi10_props,
};
+static const struct property_entry chuwi_surbook_mini_props[] = {
+ PROPERTY_ENTRY_U32("touchscreen-min-x", 88),
+ PROPERTY_ENTRY_U32("touchscreen-min-y", 13),
+ PROPERTY_ENTRY_U32("touchscreen-size-x", 2040),
+ PROPERTY_ENTRY_U32("touchscreen-size-y", 1524),
+ PROPERTY_ENTRY_STRING("firmware-name", "gsl1680-chuwi-surbook-mini.fw"),
+ PROPERTY_ENTRY_U32("silead,max-fingers", 10),
+ PROPERTY_ENTRY_BOOL("touchscreen-inverted-y"),
+ { }
+};
+
+static const struct ts_dmi_data chuwi_surbook_mini_data = {
+ .acpi_name = "MSSL1680:00",
+ .properties = chuwi_surbook_mini_props,
+};
+
static const struct property_entry connect_tablet9_props[] = {
PROPERTY_ENTRY_U32("touchscreen-min-x", 9),
PROPERTY_ENTRY_U32("touchscreen-min-y", 10),
@@ -646,6 +662,14 @@ static const struct dmi_system_id touchscreen_dmi_table[]
= {
DMI_MATCH(DMI_PRODUCT_NAME, "S165"),
},
},
+ {
+ /* Chuwi Surbook Mini (CWI540) */
+ .driver_data = (void *)_surbook_mini_data,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Hampoo"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "C3W6_AP108_4G"),
+ },
+ },
{
/* Connect Tablet 9 */
.driver_data = (void *)_tablet9_data,
--
2.22.0
Re: Device to write to all (serial) consoles
On Sat, Aug 03, 2019 at 03:23:23PM +0200, Adam Borowski wrote: > On Fri, Aug 02, 2019 at 09:59:06PM +0200, Paul Menzel wrote: > > On 02.08.19 18:02, Greg Kroah-Hartman wrote: > > > On Fri, Aug 02, 2019 at 03:23:08PM +0200, Paul Menzel wrote: > > > > On a lot of devices, like servers, you have more than one serial > > > > console, > > > > and you do not always know, how they are numbered. Therefore, we start a > > > > console on ttyS0 and ttyS1. > > > > Because the cable is always connected to the port on the back side, and > > sometimes the port in the front has ID 0, and the one in the back 1, and > > other times vice versa. We do not want to track that, and it would be > > convenient to just write to both ports. > > Sounds like an XY problem then: what you want is not writing to all ports, > but to have the port assignments stable (see also: disk device reordering). You can get that information from the symlinks in /dev/serial/ which udev creates.
Re: [PATCH net-next v3] net: phy: broadcom: add 1000Base-X support for BCM54616S
Hi Tao,
On Sat, 3 Aug 2019 at 00:56, Tao Ren wrote:
>
> genphy_read_status() cannot report correct link speed when BCM54616S PHY
> is configured in RGMII->1000Base-KX mode (for example, on Facebook CMM
> BMC platform), and it is because speed-related fields in MII registers
> are assigned different meanings in 1000X register set. Actually there
> is no speed field in 1000X register set because link speed is always
> 1000 Mb/s.
>
> The patch adds "probe" callback to detect PHY's operation mode based on
> INTERF_SEL[1:0] pins and 1000X/100FX selection bit in SerDES 100-FX
> Control register. Besides, link speed is manually set to 1000 Mb/s in
> "read_status" callback if PHY-switch link is 1000Base-X.
>
> Signed-off-by: Tao Ren
> ---
> Changes in v3:
> - rename bcm5482_read_status to bcm54xx_read_status so the callback can
> be shared by BCM5482 and BCM54616S.
> Changes in v2:
> - Auto-detect PHY operation mode instead of passing DT node.
> - move PHY mode auto-detect logic from config_init to probe callback.
> - only set speed (not including duplex) in read_status callback.
> - update patch description with more background to avoid confusion.
> - patch #1 in the series ("net: phy: broadcom: set features explicitly
> for BCM54616") is dropped: the fix should go to get_features callback
> which may potentially depend on this patch.
>
> drivers/net/phy/broadcom.c | 41 +-
> include/linux/brcmphy.h| 10 --
> 2 files changed, 44 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
> index 937d0059e8ac..ecad8a201a09 100644
> --- a/drivers/net/phy/broadcom.c
> +++ b/drivers/net/phy/broadcom.c
> @@ -383,9 +383,9 @@ static int bcm5482_config_init(struct phy_device *phydev)
> /*
> * Select 1000BASE-X register set (primary SerDes)
> */
> - reg = bcm_phy_read_shadow(phydev, BCM5482_SHD_MODE);
> - bcm_phy_write_shadow(phydev, BCM5482_SHD_MODE,
> -reg | BCM5482_SHD_MODE_1000BX);
> + reg = bcm_phy_read_shadow(phydev, BCM54XX_SHD_MODE);
> + bcm_phy_write_shadow(phydev, BCM54XX_SHD_MODE,
> +reg | BCM54XX_SHD_MODE_1000BX);
>
> /*
> * LED1=ACTIVITYLED, LED3=LINKSPD[2]
> @@ -409,7 +409,7 @@ static int bcm5482_config_init(struct phy_device *phydev)
> return err;
> }
>
> -static int bcm5482_read_status(struct phy_device *phydev)
> +static int bcm54xx_read_status(struct phy_device *phydev)
> {
> int err;
>
> @@ -464,6 +464,35 @@ static int bcm54616s_config_aneg(struct phy_device
> *phydev)
> return ret;
> }
>
> +static int bcm54616s_probe(struct phy_device *phydev)
> +{
> + int val, intf_sel;
> +
> + val = bcm_phy_read_shadow(phydev, BCM54XX_SHD_MODE);
> + if (val < 0)
> + return val;
> +
> + /* The PHY is strapped in RGMII to fiber mode when INTERF_SEL[1:0]
> +* is 01b.
> +*/
> + intf_sel = (val & BCM54XX_SHD_INTF_SEL_MASK) >> 1;
> + if (intf_sel == 1) {
> + val = bcm_phy_read_shadow(phydev, BCM54616S_SHD_100FX_CTRL);
> + if (val < 0)
> + return val;
> +
> + /* Bit 0 of the SerDes 100-FX Control register, when set
> +* to 1, sets the MII/RGMII -> 100BASE-FX configuration.
> +* When this bit is set to 0, it sets the GMII/RGMII ->
> +* 1000BASE-X configuration.
> +*/
> + if (!(val & BCM54616S_100FX_MODE))
> + phydev->dev_flags |= PHY_BCM_FLAGS_MODE_1000BX;
> + }
> +
> + return 0;
> +}
> +
> static int brcm_phy_setbits(struct phy_device *phydev, int reg, int set)
> {
> int val;
> @@ -655,6 +684,8 @@ static struct phy_driver broadcom_drivers[] = {
> .config_aneg= bcm54616s_config_aneg,
> .ack_interrupt = bcm_phy_ack_intr,
> .config_intr= bcm_phy_config_intr,
> + .read_status= bcm54xx_read_status,
> + .probe = bcm54616s_probe,
> }, {
> .phy_id = PHY_ID_BCM5464,
> .phy_id_mask= 0xfff0,
> @@ -689,7 +720,7 @@ static struct phy_driver broadcom_drivers[] = {
> .name = "Broadcom BCM5482",
> /* PHY_GBIT_FEATURES */
> .config_init= bcm5482_config_init,
> - .read_status= bcm5482_read_status,
> + .read_status= bcm54xx_read_status,
> .ack_interrupt = bcm_phy_ack_intr,
> .config_intr= bcm_phy_config_intr,
> }, {
> diff --git a/include/linux/brcmphy.h b/include/linux/brcmphy.h
> index 6db2d9a6e503..b475e7f20d28 100644
> --- a/include/linux/brcmphy.h
> +++ b/include/linux/brcmphy.h
> @@ -200,9 +200,15 @@
> #define BCM5482_SHD_SSD0x14/* 10100: Secondary
[PATCH] gpiolib: Take MUX usage into account
From: Stefan Wahren
The user space like gpioinfo only see the GPIO usage but not the
MUX usage (e.g. I2C or SPI usage) of a pin. As a user we want to know which
pin is free/safe to use. So take the MUX usage of strict pinmux controllers
into account to get a more realistic view for ioctl GPIO_GET_LINEINFO_IOCTL.
Signed-off-by: Stefan Wahren
Tested-By: Ramon Fried
Signed-off-by: Ramon Fried
---
Sending Stefan's RFC as patch, as I tested it and it seems to work,
additionally, an accompanying fix was made by me to gpiolibd to fix a
display error of the actual result:
https://patchwork.ozlabs.org/patch/1139923/
drivers/gpio/gpiolib.c | 3 ++-
drivers/pinctrl/core.c | 23 +++
drivers/pinctrl/pinmux.c | 18 ++
drivers/pinctrl/pinmux.h | 7 +++
include/linux/pinctrl/consumer.h | 6 ++
5 files changed, 56 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index e013d417a936..2fd9eee0b98c 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1082,7 +1082,8 @@ static long gpio_ioctl(struct file *filp, unsigned int
cmd, unsigned long arg)
test_bit(FLAG_IS_HOGGED, >flags) ||
test_bit(FLAG_USED_AS_IRQ, >flags) ||
test_bit(FLAG_EXPORT, >flags) ||
- test_bit(FLAG_SYSFS, >flags))
+ test_bit(FLAG_SYSFS, >flags) ||
+ pinctrl_gpio_is_in_use(chip->base + lineinfo.line_offset))
lineinfo.flags |= GPIOLINE_FLAG_KERNEL;
if (test_bit(FLAG_IS_OUT, >flags))
lineinfo.flags |= GPIOLINE_FLAG_IS_OUT;
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index a64849a9d1b0..0dd00c175eed 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -759,6 +759,29 @@ int pinctrl_get_group_selector(struct pinctrl_dev *pctldev,
return -EINVAL;
}
+bool pinctrl_gpio_is_in_use(unsigned gpio)
+{
+ struct pinctrl_dev *pctldev;
+ struct pinctrl_gpio_range *range;
+ bool result;
+ int pin;
+
+ if (pinctrl_get_device_gpio_range(gpio, , ))
+ return false;
+
+ mutex_lock(>mutex);
+
+ /* Convert to the pin controllers number space */
+ pin = gpio_to_pin(range, gpio);
+
+ result = pinmux_is_in_use(pctldev, pin);
+
+ mutex_unlock(>mutex);
+
+ return result;
+}
+EXPORT_SYMBOL_GPL(pinctrl_gpio_is_in_use);
+
/**
* pinctrl_gpio_request() - request a single pin to be used as GPIO
* @gpio: the GPIO pin number from the GPIO subsystem number space
diff --git a/drivers/pinctrl/pinmux.c b/drivers/pinctrl/pinmux.c
index 020e54f843f9..02d2751a4884 100644
--- a/drivers/pinctrl/pinmux.c
+++ b/drivers/pinctrl/pinmux.c
@@ -70,6 +70,24 @@ int pinmux_validate_map(const struct pinctrl_map *map, int i)
return 0;
}
+bool pinmux_is_in_use(struct pinctrl_dev *pctldev, unsigned pin)
+{
+ struct pin_desc *desc = pin_desc_get(pctldev, pin);
+ const struct pinmux_ops *ops = pctldev->desc->pmxops;
+
+ if (!desc) {
+ dev_err(pctldev->dev,
+ "pin %u is not registered so it cannot be requested\n",
+ pin);
+ return false;
+ }
+
+ if (ops->strict && desc->mux_usecount)
+ return true;
+
+ return ops->strict && !!desc->gpio_owner;
+}
+
/**
* pin_request() - request a single pin to be muxed in, typically for GPIO
* @pin: the pin number in the global pin space
diff --git a/drivers/pinctrl/pinmux.h b/drivers/pinctrl/pinmux.h
index 794cb3a003ff..24ae61136803 100644
--- a/drivers/pinctrl/pinmux.h
+++ b/drivers/pinctrl/pinmux.h
@@ -15,6 +15,8 @@ int pinmux_check_ops(struct pinctrl_dev *pctldev);
int pinmux_validate_map(const struct pinctrl_map *map, int i);
+bool pinmux_is_in_use(struct pinctrl_dev *pctldev, unsigned pin);
+
int pinmux_request_gpio(struct pinctrl_dev *pctldev,
struct pinctrl_gpio_range *range,
unsigned pin, unsigned gpio);
@@ -42,6 +44,11 @@ static inline int pinmux_validate_map(const struct
pinctrl_map *map, int i)
return 0;
}
+static inline bool pinmux_is_in_use(struct pinctrl_dev *pctldev, unsigned pin)
+{
+ return false;
+}
+
static inline int pinmux_request_gpio(struct pinctrl_dev *pctldev,
struct pinctrl_gpio_range *range,
unsigned pin, unsigned gpio)
diff --git a/include/linux/pinctrl/consumer.h b/include/linux/pinctrl/consumer.h
index 86720a5a384f..d26826b057a1 100644
--- a/include/linux/pinctrl/consumer.h
+++ b/include/linux/pinctrl/consumer.h
@@ -24,6 +24,7 @@ struct device;
#ifdef CONFIG_PINCTRL
/* External interface to pin control */
+extern bool pinctrl_gpio_is_in_use(unsigned gpio);
extern int pinctrl_gpio_request(unsigned gpio);
extern void pinctrl_gpio_free(unsigned gpio);
Re: Device to write to all (serial) consoles
On Fri, Aug 02, 2019 at 09:59:06PM +0200, Paul Menzel wrote: > On 02.08.19 18:02, Greg Kroah-Hartman wrote: > > On Fri, Aug 02, 2019 at 03:23:08PM +0200, Paul Menzel wrote: > > > On a lot of devices, like servers, you have more than one serial console, > > > and you do not always know, how they are numbered. Therefore, we start a > > > console on ttyS0 and ttyS1. > > Because the cable is always connected to the port on the back side, and > sometimes the port in the front has ID 0, and the one in the back 1, and > other times vice versa. We do not want to track that, and it would be > convenient to just write to both ports. Sounds like an XY problem then: what you want is not writing to all ports, but to have the port assignments stable (see also: disk device reordering). Meow! -- ⢀⣴⠾⠻⢶⣦⠀ Latin: meow 4 characters, 4 columns, 4 bytes ⣾⠁⢠⠒⠀⣿⡁ Greek: μεου 4 characters, 4 columns, 8 bytes ⢿⡄⠘⠷⠚⠋ Runes: ᛗᛖᛟᚹ 4 characters, 4 columns, 12 bytes ⠈⠳⣄ Chinese: 喵 1 character, 2 columns, 3 bytes <-- best!
Re: [PATCH 1/9] clk: actions: Don't reference clk_init_data after registration
On Wed, Jul 31, 2019 at 12:35:09PM -0700, Stephen Boyd wrote:
> A future patch is going to change semantics of clk_register() so that
> clk_hw::init is guaranteed to be NULL after a clk is registered. Avoid
> referencing this member here so that we don't run into NULL pointer
> exceptions.
>
> Cc: Manivannan Sadhasivam
> Signed-off-by: Stephen Boyd
Acked-by: Manivannan Sadhasivam
Thanks,
Mani
> ---
>
> Please ack so I can take this through clk tree
>
> drivers/clk/actions/owl-common.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/actions/owl-common.c
> b/drivers/clk/actions/owl-common.c
> index 32dd29e0a37e..71b683c4e643 100644
> --- a/drivers/clk/actions/owl-common.c
> +++ b/drivers/clk/actions/owl-common.c
> @@ -68,6 +68,7 @@ int owl_clk_probe(struct device *dev, struct
> clk_hw_onecell_data *hw_clks)
> struct clk_hw *hw;
>
> for (i = 0; i < hw_clks->num; i++) {
> + const char *name = hw->init->name;
>
> hw = hw_clks->hws[i];
>
> @@ -77,7 +78,7 @@ int owl_clk_probe(struct device *dev, struct
> clk_hw_onecell_data *hw_clks)
> ret = devm_clk_hw_register(dev, hw);
> if (ret) {
> dev_err(dev, "Couldn't register clock %d - %s\n",
> - i, hw->init->name);
> + i, name);
> return ret;
> }
> }
> --
> Sent by a computer through tubes
>
[PATCH v1 0/3] net: hisilicon: Fix a few problems with hip04_eth
During the use of the hip04_eth driver, several problems were found, which solved the hip04_tx_reclaim reentry problem, fixed the problem that hip04_mac_start_xmit never returns NETDEV_TX_BUSY and the dma_map_single failed on the arm64 platform. Jiangfeng Xiao (3): net: hisilicon: make hip04_tx_reclaim non-reentrant net: hisilicon: fix hip04-xmit never return TX_BUSY net: hisilicon: Fix dma_map_single failed on arm64 drivers/net/ethernet/hisilicon/hip04_eth.c | 28 1 file changed, 16 insertions(+), 12 deletions(-) -- 1.8.5.6
[PATCH v1 2/3] net: hisilicon: fix hip04-xmit never return TX_BUSY
TX_DESC_NUM is 256, in tx_count, the maximum value of
mod(TX_DESC_NUM - 1) is 254, the variable "count" in
the hip04_mac_start_xmit function is never equal to
(TX_DESC_NUM - 1), so hip04_mac_start_xmit never
return NETDEV_TX_BUSY.
tx_count is modified to mod(TX_DESC_NUM) so that
the maximum value of tx_count can reach
(TX_DESC_NUM - 1), then hip04_mac_start_xmit can reurn
NETDEV_TX_BUSY.
Signed-off-by: Jiangfeng Xiao
---
drivers/net/ethernet/hisilicon/hip04_eth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hip04_eth.c
b/drivers/net/ethernet/hisilicon/hip04_eth.c
index 1e1b154..d775b98 100644
--- a/drivers/net/ethernet/hisilicon/hip04_eth.c
+++ b/drivers/net/ethernet/hisilicon/hip04_eth.c
@@ -248,7 +248,7 @@ struct hip04_priv {
static inline unsigned int tx_count(unsigned int head, unsigned int tail)
{
- return (head - tail) % (TX_DESC_NUM - 1);
+ return (head - tail) % TX_DESC_NUM;
}
static void hip04_config_port(struct net_device *ndev, u32 speed, u32 duplex)
--
1.8.5.6
[PATCH v1 3/3] net: hisilicon: Fix dma_map_single failed on arm64
On the arm64 platform, executing "ifconfig eth0 up" will fail,
returning "ifconfig: SIOCSIFFLAGS: Input/output error."
ndev->dev is not initialized, dma_map_single->get_dma_ops->
dummy_dma_ops->__dummy_map_page will return DMA_ERROR_CODE
directly, so when we use dma_map_single, the first parameter
is to use the device of platform_device.
Signed-off-by: Jiangfeng Xiao
---
drivers/net/ethernet/hisilicon/hip04_eth.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hip04_eth.c
b/drivers/net/ethernet/hisilicon/hip04_eth.c
index d775b98..c841674 100644
--- a/drivers/net/ethernet/hisilicon/hip04_eth.c
+++ b/drivers/net/ethernet/hisilicon/hip04_eth.c
@@ -220,6 +220,7 @@ struct hip04_priv {
unsigned int reg_inten;
struct napi_struct napi;
+ struct device *dev;
struct net_device *ndev;
struct tx_desc *tx_desc;
@@ -465,7 +466,7 @@ static int hip04_tx_reclaim(struct net_device *ndev, bool
force)
}
if (priv->tx_phys[tx_tail]) {
- dma_unmap_single(>dev, priv->tx_phys[tx_tail],
+ dma_unmap_single(priv->dev, priv->tx_phys[tx_tail],
priv->tx_skb[tx_tail]->len,
DMA_TO_DEVICE);
priv->tx_phys[tx_tail] = 0;
@@ -516,8 +517,8 @@ static void hip04_start_tx_timer(struct hip04_priv *priv)
return NETDEV_TX_BUSY;
}
- phys = dma_map_single(>dev, skb->data, skb->len, DMA_TO_DEVICE);
- if (dma_mapping_error(>dev, phys)) {
+ phys = dma_map_single(priv->dev, skb->data, skb->len, DMA_TO_DEVICE);
+ if (dma_mapping_error(priv->dev, phys)) {
dev_kfree_skb(skb);
return NETDEV_TX_OK;
}
@@ -596,7 +597,7 @@ static int hip04_rx_poll(struct napi_struct *napi, int
budget)
goto refill;
}
- dma_unmap_single(>dev, priv->rx_phys[priv->rx_head],
+ dma_unmap_single(priv->dev, priv->rx_phys[priv->rx_head],
RX_BUF_SIZE, DMA_FROM_DEVICE);
priv->rx_phys[priv->rx_head] = 0;
@@ -625,9 +626,9 @@ static int hip04_rx_poll(struct napi_struct *napi, int
budget)
buf = netdev_alloc_frag(priv->rx_buf_size);
if (!buf)
goto done;
- phys = dma_map_single(>dev, buf,
+ phys = dma_map_single(priv->dev, buf,
RX_BUF_SIZE, DMA_FROM_DEVICE);
- if (dma_mapping_error(>dev, phys))
+ if (dma_mapping_error(priv->dev, phys))
goto done;
priv->rx_buf[priv->rx_head] = buf;
priv->rx_phys[priv->rx_head] = phys;
@@ -730,9 +731,9 @@ static int hip04_mac_open(struct net_device *ndev)
for (i = 0; i < RX_DESC_NUM; i++) {
dma_addr_t phys;
- phys = dma_map_single(>dev, priv->rx_buf[i],
+ phys = dma_map_single(priv->dev, priv->rx_buf[i],
RX_BUF_SIZE, DMA_FROM_DEVICE);
- if (dma_mapping_error(>dev, phys))
+ if (dma_mapping_error(priv->dev, phys))
return -EIO;
priv->rx_phys[i] = phys;
@@ -766,7 +767,7 @@ static int hip04_mac_stop(struct net_device *ndev)
for (i = 0; i < RX_DESC_NUM; i++) {
if (priv->rx_phys[i]) {
- dma_unmap_single(>dev, priv->rx_phys[i],
+ dma_unmap_single(priv->dev, priv->rx_phys[i],
RX_BUF_SIZE, DMA_FROM_DEVICE);
priv->rx_phys[i] = 0;
}
@@ -909,6 +910,7 @@ static int hip04_mac_probe(struct platform_device *pdev)
return -ENOMEM;
priv = netdev_priv(ndev);
+ priv->dev = d;
priv->ndev = ndev;
platform_set_drvdata(pdev, ndev);
SET_NETDEV_DEV(ndev, >dev);
--
1.8.5.6
[PATCH v1 1/3] net: hisilicon: make hip04_tx_reclaim non-reentrant
If hip04_tx_reclaim is interrupted while it is running
and then __napi_schedule continues to execute
hip04_rx_poll->hip04_tx_reclaim, reentrancy occurs
and oops is generated. So you need to mask the interrupt
during the hip04_tx_reclaim run.
The kernel oops exception stack is as follows:
Unable to handle kernel NULL pointer dereference
at virtual address 0050
pgd = c0003000
[0050] *pgd=8000a04003, *pmd=
Internal error: Oops: 206 [#1] SMP ARM
Modules linked in: hip04_eth mtdblock mtd_blkdevs mtd
ohci_platform ehci_platform ohci_hcd ehci_hcd
vfat fat sd_mod usb_storage scsi_mod usbcore usb_common
CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O4.4.185 #1
Hardware name: Hisilicon A15
task: c0a250e0 task.stack: c0a0
PC is at hip04_tx_reclaim+0xe0/0x17c [hip04_eth]
LR is at hip04_tx_reclaim+0x30/0x17c [hip04_eth]
pc : []lr : []psr: 600e0313
sp : c0a01d88 ip : fp : c0601f9c
r10: r9 : c3482380 r8 : 0001
r7 : r6 : 00e1 r5 : c3482000 r4 : 000c
r3 : f2209800 r2 : r1 : r0 :
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 32c5387d Table: 03d28c80 DAC:
Process swapper/0 (pid: 0, stack limit = 0xc0a00190)
Stack: (0xc0a01d88 to 0xc0a02000)
[] (hip04_tx_reclaim [hip04_eth]) from []
(hip04_rx_poll+0x88/0x368
[hip04_eth])
[] (hip04_rx_poll [hip04_eth]) from []
(net_rx_action+0x114/0x34c)
[] (net_rx_action) from [] (__do_softirq+0x218/0x318)
[] (__do_softirq) from [] (irq_exit+0x88/0xac)
[] (irq_exit) from [] (msa_irq_exit+0x11c/0x1d4)
[] (msa_irq_exit) from [] (__handle_domain_irq+0x110/0x148)
[] (__handle_domain_irq) from [] (gic_handle_irq+0xd4/0x118)
[] (gic_handle_irq) from [] (__irq_svc+0x40/0x58)
Exception stack(0xc0a01f30 to 0xc0a01f78)
1f20: c0ae8b40
1f40: 0002 e000 c0601f9c c0a2257c c0a22440 c0831a38
1f60: c0a01ec4 c0a01f80 c0203714 c0203718 600e0213
[] (__irq_svc) from [] (arch_cpu_idle+0x20/0x3c)
[] (arch_cpu_idle) from [] (cpu_startup_entry+0x244/0x29c)
[] (cpu_startup_entry) from [] (rest_init+0xc8/0x10c)
[] (rest_init) from [] (start_kernel+0x468/0x514)
Code: a40599e5 016086e2 018088e2 7660efe6 (503090e5)
---[ end trace 1db21d6d09c49d74 ]---
Kernel panic - not syncing: Fatal exception in interrupt
CPU3: stopping
CPU: 3 PID: 0 Comm: swapper/3 Tainted: G DO4.4.185 #1
Signed-off-by: Jiangfeng Xiao
---
drivers/net/ethernet/hisilicon/hip04_eth.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hip04_eth.c
b/drivers/net/ethernet/hisilicon/hip04_eth.c
index d604528..1e1b154 100644
--- a/drivers/net/ethernet/hisilicon/hip04_eth.c
+++ b/drivers/net/ethernet/hisilicon/hip04_eth.c
@@ -585,6 +585,9 @@ static int hip04_rx_poll(struct napi_struct *napi, int
budget)
u16 len;
u32 err;
+ /* clean up tx descriptors */
+ tx_remaining = hip04_tx_reclaim(ndev, false);
+
while (cnt && !last) {
buf = priv->rx_buf[priv->rx_head];
skb = build_skb(buf, priv->rx_buf_size);
@@ -645,8 +648,7 @@ static int hip04_rx_poll(struct napi_struct *napi, int
budget)
}
napi_complete_done(napi, rx);
done:
- /* clean up tx descriptors and start a new timer if necessary */
- tx_remaining = hip04_tx_reclaim(ndev, false);
+ /* start a new timer if necessary */
if (rx < budget && tx_remaining)
hip04_start_tx_timer(priv);
--
1.8.5.6
