* [PATCH -next] mtd: rawnand: ingenic: Make jz4725b_ooblayout_ops static
From: Yue Haibing @ 2019-04-10 14:00 UTC (permalink / raw)
To: bbrezillon, miquel.raynal, richard, dwmw2, computersforpeace,
marek.vasut, paul
Cc: linux-kernel, linux-mtd, YueHaibing
From: YueHaibing <yuehaibing@huawei.com>
Fix sparse warning:
drivers/mtd/nand/raw/ingenic/ingenic_nand.c:140:32: warning:
symbol 'jz4725b_ooblayout_ops' was not declared. Should it be static?
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/mtd/nand/raw/ingenic/ingenic_nand.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/raw/ingenic/ingenic_nand.c b/drivers/mtd/nand/raw/ingenic/ingenic_nand.c
index ad0c905..d7b7c0f 100644
--- a/drivers/mtd/nand/raw/ingenic/ingenic_nand.c
+++ b/drivers/mtd/nand/raw/ingenic/ingenic_nand.c
@@ -137,7 +137,7 @@ static int jz4725b_ooblayout_free(struct mtd_info *mtd, int section,
return 0;
}
-const struct mtd_ooblayout_ops jz4725b_ooblayout_ops = {
+static const struct mtd_ooblayout_ops jz4725b_ooblayout_ops = {
.ecc = jz4725b_ooblayout_ecc,
.free = jz4725b_ooblayout_free,
};
--
2.7.4
^ permalink raw reply related
* [Buildroot] [PATCH] package/samba4: security bump to version 4.9.6
From: Thomas Petazzoni @ 2019-04-10 14:00 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20190408104952.19872-1-peter@korsgaard.com>
On Mon, 8 Apr 2019 12:49:52 +0200
Peter Korsgaard <peter@korsgaard.com> wrote:
> Fixes the following security vulnerabilities:
>
> - CVE-2019-3870:
> During the provision of a new Active Directory DC, some files in the private/
> directory are created world-writable.
> https://www.samba.org/samba/security/CVE-2019-3870.html
>
> - CVE-2019-3880:
> Authenticated users with write permission can trigger a symlink traversal to
> write or detect files outside the Samba share.
> https://www.samba.org/samba/security/CVE-2019-3880.html
>
> For more details, see the release notes:
> https://www.samba.org/samba/history/samba-4.9.6.html
>
> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
> ---
> package/samba4/samba4.hash | 4 ++--
> package/samba4/samba4.mk | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
Applied to master, thanks.
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH] ARM: dts: stm32: add ltdc pins muxing on stm32mp157
From: Alexandre Torgue @ 2019-04-10 14:00 UTC (permalink / raw)
To: Yannick Fertré, Maxime Coquelin, Rob Herring, Mark Rutland,
linux-stm32, linux-arm-kernel, devicetree, linux-kernel,
Benjamin Gaignard, Philippe Cornu
In-Reply-To: <1553862515-6005-1-git-send-email-yannick.fertre@st.com>
Hi Yannick
On 3/29/19 1:28 PM, Yannick Fertré wrote:
> Add ltdc pins muxing on stm32mp157.
>
> Signed-off-by: Yannick Fertré <yannick.fertre@st.com>
> ---
> arch/arm/boot/dts/stm32mp157-pinctrl.dtsi | 138 ++++++++++++++++++++++++++++++
> 1 file changed, 138 insertions(+)
>
> diff --git a/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi b/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi
> index 9104896..da4b411 100644
> --- a/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi
> +++ b/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi
> @@ -233,6 +233,144 @@
>
Applied on stm32-next.
Thanks.
Alex
^ permalink raw reply
* Re: [PATCH v2 3/3] rcar-csi2: Move setting of Field Detection Control Register
From: Hans Verkuil @ 2019-04-10 13:59 UTC (permalink / raw)
To: Niklas Söderlund, Laurent Pinchart, linux-media
Cc: linux-renesas-soc, Ulrich Hecht, Kieran Bingham
In-Reply-To: <20190308235702.27057-4-niklas.soderlund+renesas@ragnatech.se>
On 3/9/19 12:57 AM, Niklas Söderlund wrote:
> Latest datasheet (rev 1.50) clarifies that the FLD register should be
> set after LINKCNT.
>
> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> Reviewed-by: Ulrich Hecht <uli+renesas@fpond.eu>
> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
> ---
> drivers/media/platform/rcar-vin/rcar-csi2.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-csi2.c b/drivers/media/platform/rcar-vin/rcar-csi2.c
> index 07d5c8c66b7cd382..077e0d344b395b54 100644
> --- a/drivers/media/platform/rcar-vin/rcar-csi2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-csi2.c
> @@ -529,7 +529,6 @@ static int rcsi2_start_receiver(struct rcar_csi2 *priv)
> rcsi2_write(priv, PHTC_REG, 0);
>
> /* Configure */
> - rcsi2_write(priv, FLD_REG, fld);
> rcsi2_write(priv, VCDT_REG, vcdt);
> if (vcdt2)
> rcsi2_write(priv, VCDT2_REG, vcdt2);
> @@ -560,6 +559,7 @@ static int rcsi2_start_receiver(struct rcar_csi2 *priv)
> rcsi2_write(priv, PHYCNT_REG, phycnt);
> rcsi2_write(priv, LINKCNT_REG, LINKCNT_MONITOR_EN |
> LINKCNT_REG_MONI_PACT_EN | LINKCNT_ICLK_NONSTOP);
> + rcsi2_write(priv, FLD_REG, fld);
> rcsi2_write(priv, PHYCNT_REG, phycnt | PHYCNT_SHUTDOWNZ);
> rcsi2_write(priv, PHYCNT_REG, phycnt | PHYCNT_SHUTDOWNZ | PHYCNT_RSTZ);
>
>
This patch doesn't apply because the fld variable no longer exists.
I think the fix is easy, but I prefer it if you rebase and repost this patch.
I've merged the others, so it's just this patch that's the problem.
Regards,
Hans
^ permalink raw reply
* [U-Boot] UBIFS mount bug when mounting from multiple MTD partitions
From: Heiko Schocher @ 2019-04-10 13:59 UTC (permalink / raw)
To: u-boot
In-Reply-To: <b1f0420c-9ec2-1333-c99d-72ed150ce616@kontron.de>
Hello Frieder,
Am 10.04.2019 um 15:31 schrieb Schrempf Frieder:
> Hi Heiko,
>
> On 10.04.19 14:44, Heiko Schocher wrote:
>> Hello Frieder,
>>
>> Am 10.04.2019 um 12:49 schrieb Schrempf Frieder:
>>> Hi,
>>>
>>> I have a customer who has a NAND device with two MTD partitions and
>>> each > of the partitions contains one UBI volume with a UBIFS filesystem.
>>
>> Bad idea ... why?
>>
>> You may loose lifetime of the board, as UBI cannot use PEBs between the
>> 2 MTD partitions on the nand ... better you would have one big MTD
>> Partition
>> with n ubi volumes in it ...
>>
>> But ... okay... this must work also.
>
> Yeah, I only recently learned about the disadvantages of this setup.
> Maybe we can change it in the future, but for now they are using
> separate partitions.
Ok.
>>> Now U-Boot can mount the UBIFS from the first partition just fine, but
>>> if the UBIFS from the second partition is mounted afterwards this fails
>>> in some cases.
>>
>> :-(
>>
>>> I can reproduce the error and tracked it down to uboot_ubifs_mount() in
>>> fs/ubifs/super.c. If this function is run for the second mount, the
>>> struct ubifs_fs_type is reused and it contains a list fs_supers, that
>>> still holds one entry for the first mount.
>>
>> Sure?
>>
>> fs_supers in struct file_system_type seems used only in none
>> U-Boot code...
>
> Right, I had a closer look and fs_supers seems to be unused indeed, but
> somehow it causes corruption in my case. When I apply 5a08cfee3967
> (ubifs: remove useless code) the problem disappears.
Ah, 5a08cfee3967 is in mainline ... good ;-)
> Without this patch there still is hlist_add_head(&s->s_instances,
> &type->fs_supers) and this line somehow seems to cause the error.
>
> I applied this debug diff:
>
> --- a/fs/ubifs/super.c
> +++ b/fs/ubifs/super.c
> @@ -2428,7 +2428,15 @@ retry:
> #else
> strncpy(s->s_id, type->name, sizeof(s->s_id));
> #endif
> + printf("%s:%d: ubi_num: %d, vol_id: %d\n",
> + __func__, __LINE__,
> + ((struct ubifs_info *)s->s_fs_info)->vi.ubi_num,
> + ((struct ubifs_info *)s->s_fs_info)->vi.vol_id);
> hlist_add_head(&s->s_instances, &type->fs_supers);
> + printf("%s:%d: ubi_num: %d, vol_id: %d\n",
> + __func__, __LINE__,
> + ((struct ubifs_info *)s->s_fs_info)->vi.ubi_num,
> + ((struct ubifs_info *)s->s_fs_info)->vi.vol_id);
> #ifndef __UBOOT__
> spin_unlock(&sb_lock);
> get_filesystem(type);
>
> And I'm getting this for the first mount:
>
> sget:2431: ubi_num: 0, vol_id: 0
> sget:2433: ubi_num: 0, vol_id: 0
>
> And this for the second mount:
>
> sget:2431: ubi_num: 0, vol_id: 0
> sget:2433: ubi_num: -1678121552, vol_id: -1678120656
Hmm...
>>> I guess, that if the second mount would happen on a volume that is on
>>> the same MTD partition as the first volume, than this will work. The
>>> second entry is added to ubifs_fs_type.fs_supers.
>>
>> I cannot see this from looking into code ... so hard to say, but
>> I only looked into mainline code ...
>
> Yeah, I was probably wrong with these first wild guesses...
;-)
>>> In my case however, the second entry being added to
>>> ubifs_fs_type.fs_supers is invalid and causes the mount error.
>>>
>>> Reinitializing the list in uboot_ubifs_mount() before each mount, solves
>>> the problem, but I guess that it will cause failures in other setups,
>>> where there are actually multiple volumes on one MTD device.
>>>
>>> So how can I solve this properly? Do we need one instance of struct
>>> ubifs_fs_type for each MTD device?
>>
>> Hmm.. without digging into it, it is difficult to say...
>>
>>> I tested this on an old version (2017.03), but looking at the current
>>> code, it looks like the same problem applies to current mainline.
>>
>> Is there any chance to try it with current mainline ?
>
> The problem is a bit strange and this what I'm actually worried about.
> It is persistent in a certain environment: U-Boot loaded from SPI NOR,
> environment set to certain values, data written to UBIFS partition in
> Linux and then power-cut.
>
> If one of these conditions changes, the error usually disappears, for
> example if I use the exact same setup, but load the Bootloader from MMC
> or RAM. Or if no write access with power-cut happens.
>
> So I wonder if there's some memory corruption somewhere else. Though,
> the error happens always at the same place. Debug prints or other code
> changes have no influence.
>
> I really would like to understand what's going on so I can make sure
> that 5a08cfee3967 actually solves the real issue or just hides it.
Please keep me informed ... I try to reproduce it here on a hw I
have access to, but need some "free" time ...
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: hs at denx.de
^ permalink raw reply
* Re: [PATCH] of: use correct function prototype for of_overlay_fdt_apply()
From: Rob Herring @ 2019-04-10 13:59 UTC (permalink / raw)
To: Chris Packham; +Cc: frowand.list, Hamish Martin, devicetree, linux-kernel
In-Reply-To: <20190322002342.24831-1-chris.packham@alliedtelesis.co.nz>
On Fri, Mar 22, 2019 at 01:23:41PM +1300, Chris Packham wrote:
> When CONFIG_OF_OVERLAY is not enabled the fallback stub for
> of_overlay_fdt_apply() does not match the prototype for the case when
> CONFIG_OF_OVERLAY is enabled. Update the stub to use the correct
> function prototype.
>
> Fixes: commit 39a751a4cb7e ("of: change overlay apply input data from unflattened to FDT")
> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
> ---
> include/linux/of.h | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Applied.
Rob
^ permalink raw reply
* Re: [PATCH v1 1/4] platform/x86: intel_pmc_ipc: Use BIT() macro
From: Andy Shevchenko @ 2019-04-10 13:59 UTC (permalink / raw)
To: sathyanarayanan kuppuswamy
Cc: Darren Hart, platform-driver-x86, Zha Qipeng, junxiao.chang,
linux-kernel
In-Reply-To: <20190409173939.GY9224@smile.fi.intel.com>
On Tue, Apr 09, 2019 at 08:39:39PM +0300, Andy Shevchenko wrote:
> On Tue, Apr 09, 2019 at 10:07:35AM -0700, sathyanarayanan kuppuswamy wrote:
> > On 4/9/19 4:25 AM, Andy Shevchenko wrote:
> > > Use BIT() and BIT_MASK() macros for definitions.
> > Looks good to me.
>
> Thanks!
If you have no further comments, can you provide your tag here?
>
> > > /* PMC register bit definitions */
> > > /* PMC_CFG_REG bit masks */
> > > -#define PMC_CFG_NO_REBOOT_MASK (1 << 4)
> > > +#define PMC_CFG_NO_REBOOT_MASK BIT_MASK(4)
> > > #define PMC_CFG_NO_REBOOT_EN (1 << 4)
> > > #define PMC_CFG_NO_REBOOT_DIS (0 << 4)
> > Do we need 0 << 4 ?
>
> Yes, to explicitly show that this is a value for NO_REBOOT masked bit(s)
> (single bit in this case).
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] mtd: nand: Fix build error while CONFIG_MTD_NAND_ECC_SW_BCH is set to module
From: Boris Brezillon @ 2019-04-10 13:58 UTC (permalink / raw)
To: Yue Haibing
Cc: bbrezillon, richard, linux-kernel, marek.vasut, paul.burton,
linux-mtd, miquel.raynal, computersforpeace
In-Reply-To: <20190410153920.68267a1a@collabora.com>
On Wed, 10 Apr 2019 15:39:28 +0200
Boris Brezillon <boris.brezillon@collabora.com> wrote:
> On Wed, 10 Apr 2019 21:07:47 +0800
> Yue Haibing <yuehaibing@huawei.com> wrote:
>
> > From: YueHaibing <yuehaibing@huawei.com>
> >
> > Fix gcc build error while CONFIG_MTD_NAND_ECC_SW_BCH
> > is set to module:
> >
> > drivers/mtd/nand/raw/nand_base.o: In function `nand_cleanup':
> > (.text+0xef6): undefined reference to `nand_bch_free'
> > drivers/mtd/nand/raw/nand_base.o: In function `nand_scan_tail':
> > nand_base.c:(.text+0xa101): undefined reference to `nand_bch_calculate_ecc'
> > nand_base.c:(.text+0xa120): undefined reference to `nand_bch_correct_data'
> > nand_base.c:(.text+0xa269): undefined reference to `nand_bch_init'
> >
> > CONFIG_MTD_NAND_ECC_SW_BCH should not be set to M,
> > because MTD_RAW_NAND need it while linked.
> >
> > Reported-by: Hulk Robot <hulkci@huawei.com>
> > Fixes: 193bd4002644 ("mtd: nand: add software BCH ECC support"
>
> Nope, it's not this one that introduced the regression.
>
>
>
> > Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> > ---
> > drivers/mtd/nand/raw/Kconfig | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
> > index 615d738..0500c42 100644
> > --- a/drivers/mtd/nand/raw/Kconfig
> > +++ b/drivers/mtd/nand/raw/Kconfig
> > @@ -22,7 +22,7 @@ menuconfig MTD_RAW_NAND
> > if MTD_RAW_NAND
> >
> > config MTD_NAND_ECC_SW_BCH
> > - tristate "Support software BCH ECC"
> > + bool "Support software BCH ECC"
> > select BCH
> > default n
> > help
>
> Should be fixed with the following diff squashed into:
>
> 51ef1d0b2095 ("mtd: nand: Clarify Kconfig entry for software BCH ECC algorithm")
>
> --->8---
> diff --git a/include/linux/mtd/nand_bch.h b/include/linux/mtd/nand_bch.h
> index b8106651f807..06ce2b655c13 100644
> --- a/include/linux/mtd/nand_bch.h
> +++ b/include/linux/mtd/nand_bch.h
> @@ -15,7 +15,7 @@ struct mtd_info;
> struct nand_chip;
> struct nand_bch_control;
>
> -#if defined(CONFIG_MTD_NAND_ECC_BCH)
> +#if defined(CONFIG_MTD_NAND_ECC_SW_BCH)
>
> static inline int mtd_nand_has_bch(void) { return 1; }
>
> @@ -39,7 +39,7 @@ struct nand_bch_control *nand_bch_init(struct mtd_info *mtd);
> */
> void nand_bch_free(struct nand_bch_control *nbc);
>
> -#else /* !CONFIG_MTD_NAND_ECC_BCH */
> +#else /* !CONFIG_MTD_NAND_ECC_SW_BCH */
>
> static inline int mtd_nand_has_bch(void) { return 0; }
>
> @@ -64,6 +64,6 @@ static inline struct nand_bch_control *nand_bch_init(struct mtd_info *mtd)
>
> static inline void nand_bch_free(struct nand_bch_control *nbc) {}
>
> -#endif /* CONFIG_MTD_NAND_ECC_BCH */
> +#endif /* CONFIG_MTD_NAND_ECC_SW_BCH */
>
> #endif /* __MTD_NAND_BCH_H__ */
Sorry, I didn't look at the right branch, this part of the code was
correct, but we still have a problem to express the RAW_NAND(y) ->
SW_BCH(y) dependency.
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: [PATCH] mtd: nand: Fix build error while CONFIG_MTD_NAND_ECC_SW_BCH is set to module
From: Boris Brezillon @ 2019-04-10 13:58 UTC (permalink / raw)
To: Yue Haibing
Cc: miquel.raynal, richard, computersforpeace, marek.vasut,
paul.burton, bbrezillon, linux-kernel, linux-mtd
In-Reply-To: <20190410153920.68267a1a@collabora.com>
On Wed, 10 Apr 2019 15:39:28 +0200
Boris Brezillon <boris.brezillon@collabora.com> wrote:
> On Wed, 10 Apr 2019 21:07:47 +0800
> Yue Haibing <yuehaibing@huawei.com> wrote:
>
> > From: YueHaibing <yuehaibing@huawei.com>
> >
> > Fix gcc build error while CONFIG_MTD_NAND_ECC_SW_BCH
> > is set to module:
> >
> > drivers/mtd/nand/raw/nand_base.o: In function `nand_cleanup':
> > (.text+0xef6): undefined reference to `nand_bch_free'
> > drivers/mtd/nand/raw/nand_base.o: In function `nand_scan_tail':
> > nand_base.c:(.text+0xa101): undefined reference to `nand_bch_calculate_ecc'
> > nand_base.c:(.text+0xa120): undefined reference to `nand_bch_correct_data'
> > nand_base.c:(.text+0xa269): undefined reference to `nand_bch_init'
> >
> > CONFIG_MTD_NAND_ECC_SW_BCH should not be set to M,
> > because MTD_RAW_NAND need it while linked.
> >
> > Reported-by: Hulk Robot <hulkci@huawei.com>
> > Fixes: 193bd4002644 ("mtd: nand: add software BCH ECC support"
>
> Nope, it's not this one that introduced the regression.
>
>
>
> > Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> > ---
> > drivers/mtd/nand/raw/Kconfig | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
> > index 615d738..0500c42 100644
> > --- a/drivers/mtd/nand/raw/Kconfig
> > +++ b/drivers/mtd/nand/raw/Kconfig
> > @@ -22,7 +22,7 @@ menuconfig MTD_RAW_NAND
> > if MTD_RAW_NAND
> >
> > config MTD_NAND_ECC_SW_BCH
> > - tristate "Support software BCH ECC"
> > + bool "Support software BCH ECC"
> > select BCH
> > default n
> > help
>
> Should be fixed with the following diff squashed into:
>
> 51ef1d0b2095 ("mtd: nand: Clarify Kconfig entry for software BCH ECC algorithm")
>
> --->8---
> diff --git a/include/linux/mtd/nand_bch.h b/include/linux/mtd/nand_bch.h
> index b8106651f807..06ce2b655c13 100644
> --- a/include/linux/mtd/nand_bch.h
> +++ b/include/linux/mtd/nand_bch.h
> @@ -15,7 +15,7 @@ struct mtd_info;
> struct nand_chip;
> struct nand_bch_control;
>
> -#if defined(CONFIG_MTD_NAND_ECC_BCH)
> +#if defined(CONFIG_MTD_NAND_ECC_SW_BCH)
>
> static inline int mtd_nand_has_bch(void) { return 1; }
>
> @@ -39,7 +39,7 @@ struct nand_bch_control *nand_bch_init(struct mtd_info *mtd);
> */
> void nand_bch_free(struct nand_bch_control *nbc);
>
> -#else /* !CONFIG_MTD_NAND_ECC_BCH */
> +#else /* !CONFIG_MTD_NAND_ECC_SW_BCH */
>
> static inline int mtd_nand_has_bch(void) { return 0; }
>
> @@ -64,6 +64,6 @@ static inline struct nand_bch_control *nand_bch_init(struct mtd_info *mtd)
>
> static inline void nand_bch_free(struct nand_bch_control *nbc) {}
>
> -#endif /* CONFIG_MTD_NAND_ECC_BCH */
> +#endif /* CONFIG_MTD_NAND_ECC_SW_BCH */
>
> #endif /* __MTD_NAND_BCH_H__ */
Sorry, I didn't look at the right branch, this part of the code was
correct, but we still have a problem to express the RAW_NAND(y) ->
SW_BCH(y) dependency.
^ permalink raw reply
* Re: [PATCH 2/2] perf/x86/intel: Add Tremont core PMU support
From: Liang, Kan @ 2019-04-10 13:58 UTC (permalink / raw)
To: Peter Zijlstra
Cc: mingo, linux-kernel, tglx, acme, jolsa, eranian,
alexander.shishkin, ak
In-Reply-To: <20190410075138.GX11158@hirez.programming.kicks-ass.net>
On 4/10/2019 3:51 AM, Peter Zijlstra wrote:
> On Tue, Apr 09, 2019 at 06:10:00PM -0700, kan.liang@linux.intel.com wrote:
>
>> The generic purpose counter 0 and fixed counter 0 have less skid.
>> Force :ppp events on generic purpose counter 0.
>> Force instruction:ppp always on fixed counter 0.
>
>> +static struct event_constraint *
>> +tnt_get_event_constraints(struct cpu_hw_events *cpuc, int idx,
>> + struct perf_event *event)
>> +{
>> + struct event_constraint *c;
>> +
>> + /*
>> + * :ppp means to do reduced skid PEBS,
>> + * which is available at PMC0 and fixed counter 0.
>> + */
>> + if (event->attr.precise_ip == 3) {
>> + /* Force instruction:ppp in Fixed counter 0 */
>> + if (event->hw.config == X86_CONFIG(.event=0xc0))
>> + return &fixed_counter0_constraint;
>> +
>> + return &counter0_constraint;
>
> I'm confused, 0xc0 is the architectural 'instructions' event, surely we
> can program that on pmc0 too?
>
> Did we want a fixed0_counter0_constraint for that?
>
Yes, I will send out V2 shortly to fix it.
Thanks,
Kan
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] migration: Fix handling fd protocol
From: Dr. David Alan Gilbert @ 2019-04-10 13:57 UTC (permalink / raw)
To: Yury Kotov, armbru, berrange; +Cc: qemu-devel, yc-core, Juan Quintela
In-Reply-To: <20190410092652.22616-1-yury-kotov@yandex-team.ru>
* Yury Kotov (yury-kotov@yandex-team.ru) wrote:
> Currently such case is possible for incoming:
> QMP: add-fd (fdset = 0, fd of some file):
> adds fd to fdset 0 and returns QEMU's fd (e.g. 33)
> QMP: migrate-incoming (uri = "fd:33"): fd is stored in QIOChannel *ioc
> ...
> Incoming migration completes and unrefs ioc -> close(33)
> QMP: remove-fd (fdset = 0, fd = 33):
> removes fd from fdset 0 and qemu_close() -> close(33) => double close
Well spotted! That would very rarely cause a problem, but is a race.
> For outgoing migration the case is the same but getfd instead of add-fd.
> Fix it by duping client's fd.
>
> Signed-off-by: Yury Kotov <yury-kotov@yandex-team.ru>
Note your patch hit a problem building on windows; I don't think we have
a qemu_dup for windows.
However, I think this problem is wider than just migration.
For example, I see that dump.c also uses monitor_get_fd, and it's
dump_cleanup also does a close on the fd. So I guess it hits the same
problem?
Also, qmp.c in qmp_add_client does a close on the fd in some error cases
(I've not followed the normal case).
So perhaps all the users of monitor_get_fd are hitting this problem.
Should we be doing the dup in monitor_get_fd?
Dave
> ---
> migration/fd.c | 39 +++++++++++++++++++++++++++++++--------
> migration/trace-events | 4 ++--
> 2 files changed, 33 insertions(+), 10 deletions(-)
>
> diff --git a/migration/fd.c b/migration/fd.c
> index a7c13df4ad..c9ff07ac41 100644
> --- a/migration/fd.c
> +++ b/migration/fd.c
> @@ -15,6 +15,7 @@
> */
>
> #include "qemu/osdep.h"
> +#include "qapi/error.h"
> #include "channel.h"
> #include "fd.h"
> #include "migration.h"
> @@ -26,15 +27,27 @@
> void fd_start_outgoing_migration(MigrationState *s, const char *fdname, Error **errp)
> {
> QIOChannel *ioc;
> - int fd = monitor_get_fd(cur_mon, fdname, errp);
> + int fd, dup_fd;
> +
> + fd = monitor_get_fd(cur_mon, fdname, errp);
> if (fd == -1) {
> return;
> }
>
> - trace_migration_fd_outgoing(fd);
> - ioc = qio_channel_new_fd(fd, errp);
> + /* fd is previously created by qmp command 'getfd',
> + * so client is responsible to close it. Dup it to save original value from
> + * QIOChannel's destructor */
> + dup_fd = qemu_dup(fd);
> + if (dup_fd == -1) {
> + error_setg(errp, "Cannot dup fd %s: %s (%d)", fdname, strerror(errno),
> + errno);
> + return;
> + }
> +
> + trace_migration_fd_outgoing(fd, dup_fd);
> + ioc = qio_channel_new_fd(dup_fd, errp);
> if (!ioc) {
> - close(fd);
> + close(dup_fd);
> return;
> }
>
> @@ -55,14 +68,24 @@ static gboolean fd_accept_incoming_migration(QIOChannel *ioc,
> void fd_start_incoming_migration(const char *infd, Error **errp)
> {
> QIOChannel *ioc;
> - int fd;
> + int fd, dup_fd;
>
> fd = strtol(infd, NULL, 0);
> - trace_migration_fd_incoming(fd);
>
> - ioc = qio_channel_new_fd(fd, errp);
> + /* fd is previously created by qmp command 'add-fd' or something else,
> + * so client is responsible to close it. Dup it to save original value from
> + * QIOChannel's destructor */
> + dup_fd = qemu_dup(fd);
> + if (dup_fd == -1) {
> + error_setg(errp, "Cannot dup fd %d: %s (%d)", fd, strerror(errno),
> + errno);
> + return;
> + }
> +
> + trace_migration_fd_incoming(fd, dup_fd);
> + ioc = qio_channel_new_fd(dup_fd, errp);
> if (!ioc) {
> - close(fd);
> + close(dup_fd);
> return;
> }
>
> diff --git a/migration/trace-events b/migration/trace-events
> index de2e136e57..d2d30a6b3c 100644
> --- a/migration/trace-events
> +++ b/migration/trace-events
> @@ -258,8 +258,8 @@ migration_exec_outgoing(const char *cmd) "cmd=%s"
> migration_exec_incoming(const char *cmd) "cmd=%s"
>
> # fd.c
> -migration_fd_outgoing(int fd) "fd=%d"
> -migration_fd_incoming(int fd) "fd=%d"
> +migration_fd_outgoing(int fd, int dup_fd) "fd=%d dup_fd=%d"
> +migration_fd_incoming(int fd, int dup_fd) "fd=%d dup_fd=%d"
>
> # socket.c
> migration_socket_incoming_accepted(void) ""
> --
> 2.21.0
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
^ permalink raw reply
* [Buildroot] [git commit] package/samba4: security bump to version 4.9.6
From: Thomas Petazzoni @ 2019-04-10 13:58 UTC (permalink / raw)
To: buildroot
commit: https://git.buildroot.net/buildroot/commit/?id=8a662ae308586e60ae65114750a014b52b5969e0
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Fixes the following security vulnerabilities:
- CVE-2019-3870:
During the provision of a new Active Directory DC, some files in the private/
directory are created world-writable.
https://www.samba.org/samba/security/CVE-2019-3870.html
- CVE-2019-3880:
Authenticated users with write permission can trigger a symlink traversal to
write or detect files outside the Samba share.
https://www.samba.org/samba/security/CVE-2019-3880.html
For more details, see the release notes:
https://www.samba.org/samba/history/samba-4.9.6.html
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
---
package/samba4/samba4.hash | 4 ++--
package/samba4/samba4.mk | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/package/samba4/samba4.hash b/package/samba4/samba4.hash
index 70cea4809b..7762456cfd 100644
--- a/package/samba4/samba4.hash
+++ b/package/samba4/samba4.hash
@@ -1,4 +1,4 @@
# Locally calculated after checking pgp signature
-# https://download.samba.org/pub/samba/stable/samba-4.9.5.tar.asc
-sha256 078956d2d98e22011265afd4b7221efe4861067dcba4a031583b01f34d423700 samba-4.9.5.tar.gz
+# https://download.samba.org/pub/samba/stable/samba-4.9.6.tar.asc
+sha256 c9205a651a83d69e200fec9dd65e9fa360f0c75ab3275b3dcb74e5cbaec60807 samba-4.9.6.tar.gz
sha256 8ceb4b9ee5adedde47b31e975c1d90c73ad27b6b165a1dcd80c7c545eb65b903 COPYING
diff --git a/package/samba4/samba4.mk b/package/samba4/samba4.mk
index 9b226a0e05..3f16b5be4a 100644
--- a/package/samba4/samba4.mk
+++ b/package/samba4/samba4.mk
@@ -4,7 +4,7 @@
#
################################################################################
-SAMBA4_VERSION = 4.9.5
+SAMBA4_VERSION = 4.9.6
SAMBA4_SITE = https://download.samba.org/pub/samba/stable
SAMBA4_SOURCE = samba-$(SAMBA4_VERSION).tar.gz
SAMBA4_INSTALL_STAGING = YES
^ permalink raw reply related
* Re: [PATCH] ci: Tune config
From: Jan Kiszka @ 2019-04-10 13:58 UTC (permalink / raw)
To: Roman Stratiienko; +Cc: Xenomai
In-Reply-To: <CAODwZ7ut3DGL9fq4yEFNMygUWJvXjW0xdGof7CvTAKFU0TJr4w@mail.gmail.com>
On 10.04.19 10:42, Roman Stratiienko wrote:
> I did measurements after clearing cache 'ccache -C'
>
> I assume that 600mb in current statistic is due to multiple build of different
> source dependencies due to enabled DEBUG INFO config. Old cache should be
> invalidated and cleaned automatically as size goes up to the limit.
>
Indeed, things piled up.
We can keep the lower limit for now and see how this evolve.
Jan
>
> ср, 10 апр. 2019 г., 08:34 Jan Kiszka <jan.kiszka@siemens.com
> <mailto:jan.kiszka@siemens.com>>:
>
> On 09.04.19 22:47, Roman Stratiienko wrote:
> >
> > I have similar issue some time ago on another project, but due to lack of
> time
> > and low priority it was unsolved.
> > And you've found the root cause and it is great, thanks!.
>
> At least it looks like as the rebuild no only takes 15 minutes.
>
> >
> > I did some measurements of ccache size, and results is following:
> > - 4.14 arm64 - cache size - 232.7 MB
> > - 4.19 arm - cache size - 246.4 MB
> > - Others are even less.
> >
> > So I suggest to left it 400MB, thus not to use too much disk space of
> travis's
> > servers.
>
> Look at the statistics you added to our build:
>
> 4.14 arm64: 601.6 MB
> 4.19 arm: 557.7 MB
> 4.14 x86: 292.5 MB
>
> If you cap the size, ccache may drop artifacts during the build, then refill,
> but may stay below the limit at the end. Still, the cache will be incomplete.
>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux
>
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
^ permalink raw reply
* Re: [PATCH] ARM: dts: stm32: add I2C sleep pins muxing on stm32mp157
From: Alexandre Torgue @ 2019-04-10 13:56 UTC (permalink / raw)
To: Yannick Fertré, Maxime Coquelin, Rob Herring, Mark Rutland,
linux-stm32, linux-arm-kernel, devicetree, linux-kernel,
Benjamin Gaignard, Philippe Cornu, Fabrice Gasnier
In-Reply-To: <1553856500-31009-1-git-send-email-yannick.fertre@st.com>
Hi Yannick
On 3/29/19 11:48 AM, Yannick Fertré wrote:
> Add I2C sleep pins muxing for low power mode.
>
> Signed-off-by: Pierre-Yves MORDRET <pierre-yves.mordret@st.com>
> Signed-off-by: Yannick Fertré <yannick.fertre@st.com>
> ---
> arch/arm/boot/dts/stm32mp157-pinctrl.dtsi | 29 +++++++++++++++++++++++++++++
> 1 file changed, 29 insertions(+)
>
> diff --git a/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi b/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi
> index 9104896..b04899f 100644
> --- a/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi
> +++ b/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi
> @@ -213,6 +213,13 @@
> };
>
Applied on stm32-next.
Thanks.
Alex
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [Xen-devel] x86 guest EOI timer issues / questions
From: Jan Beulich @ 2019-04-10 13:57 UTC (permalink / raw)
To: xen-devel; +Cc: Andrew Cooper, Wei Liu, Roger Pau Monne
All,
Andrew's observation mentioned in "[PATCH v2] x86/smt: Support for
enabling/disabling SMT at runtime" and some discussions we've already
had with him made me look into how exactly the EOI timer works. I
think there are a number of quirks. I'll enumerate all questions I've run
into below. At the end of the mail is a patch carrying out some of the
adjustments implied by a subset of these questions, plus the addition
of some debugging code. It is perhaps worthwhile to note that the
printk()-s irq_guest_eoi_timer_fn() both were observed to trigger
prior to making the non-debugging code changes. With the patch in
its current shape, I've seen trigger (every once in a while) only the
printk() added to __do_IRQ_guest().
- Why does the timer not get stopped in desc_guest_eoi() when
->in_flight is zero?
- Why does irq_guest_eoi_timer_fn() not re-arm the timer when
->in_flight is still non-zero after all the decrements? Can this case
happen at all, considering that the only increment in
__do_IRQ_guest() happens under the same desc lock? (If it can
happen, I think it would be against the purpose of 37eb6d05fe,
as this would mean the IRQ can then remain un-acked for an
indefinite period of time, unless something else re-armed the
timer.)
- Why does irq_guest_eoi_timer_fn() issue ->end() / set_eoi_ready()
even when no decrement of any ->in_flight was done at all? Neither
for ACKTYPE_UNMASK nor for ACKTYPE_EOI this looks to be fully
race free.
- Wouldn't __do_IRQ_guest() better stop the timer early on?
- Wouldn't __do_IRQ_guest() better avoid re-programming the timer
if no ->in_flight increment was done (which I would have thought
shouldn't happen anyway, but which I've observed in practice)? Of
course this would mean the timer may only be stopped when the
first increment occurs.
- What about the timer triggering while __do_IRQ_guest() is active
(holding the desc lock)? This looks to result in immediate expiry of
the EOI deferral for the current interrupt instance (and I've
observed this in practice, luckily with no other visible bad effects).
- Is it okay for fixup_eoi() to fiddle with action->cpu_eoi_map
without holding the desc lock? (I guess being in stop-machine /
SMP-boot context makes this acceptable.)
Commits of interest:
f3922f4084 x86: Support CPU hotplug offline
37eb6d05fe x86: Automatically EOI guest-bound interrupts if guest takes too long
Other notes / observations:
- irq_guest_eoi_timer_fn() should not need to re-acquire the lock
after on_selected_cpus()
- irq_guest_eoi_timer_fn() should not need to use irqsave/irqrestore
spin lock/unlock (plain irq ones should suffice in a timer handler)
- irq_guest_eoi_timer_fn() could ASSERT(action->ack_type !=
ACKTYPE_NONE) instead of having such a conditional
- fixup_eoi() may better avoid setting all peoi[].ready and instead
pass a "force" boolean to flush_ready_eoi()
Thoughts / opinions appreciated,
Jan
--- unstable.orig/xen/arch/x86/irq.c
+++ unstable/xen/arch/x86/irq.c
@@ -1103,7 +1103,7 @@ static void set_eoi_ready(void *data);
static void irq_guest_eoi_timer_fn(void *data)
{
struct irq_desc *desc = data;
- unsigned int irq = desc - irq_desc;
+ unsigned int irq = desc - irq_desc, done = 0;
irq_guest_action_t *action;
cpumask_t cpu_eoi_map;
unsigned long flags;
@@ -1115,6 +1115,16 @@ static void irq_guest_eoi_timer_fn(void
action = (irq_guest_action_t *)desc->action;
+ if ( action->eoi_timer.status >= TIMER_STATUS_in_heap )
+{//temp
+ static unsigned long cnt, thr;
+ if(++cnt > thr) {
+ thr |= cnt;
+ printk("IRQ%u: i=%u a=%d n=%u\n", irq, action->in_flight, action->ack_type, action->nr_guests);
+ }
+ goto out;
+}
+
if ( action->ack_type != ACKTYPE_NONE )
{
unsigned int i;
@@ -1122,11 +1132,29 @@ static void irq_guest_eoi_timer_fn(void
{
struct domain *d = action->guest[i];
unsigned int pirq = domain_irq_to_pirq(d, irq);
+
if ( test_and_clear_bool(pirq_info(d, pirq)->masked) )
- action->in_flight--;
+ ++done;
}
+ action->in_flight -= done;
}
+{//temp
+ static unsigned long done_cnt, done_thr;
+ static unsigned long infl_cnt, infl_thr;
+ bool log = false;
+ if(action->in_flight && ++infl_cnt > infl_thr) {
+ infl_thr |= infl_cnt;
+ log = true;
+ } else if(!done && ++done_cnt > done_thr) {
+ done_thr |= done_cnt;
+ log = true;
+ }
+ if(log)
+ printk("IRQ%u: d=%u i=%u a=%d n=%u (%06lx,%06lx)\n", irq, done, action->in_flight,
+ action->ack_type, action->nr_guests, done_cnt, infl_cnt);
+}
+//todo Instead of the below, assert that ->in_flight is zero and bail if done is zero?
if ( action->in_flight != 0 )
goto out;
@@ -1156,6 +1184,7 @@ static void __do_IRQ_guest(int irq)
int i, sp;
struct pending_eoi *peoi = this_cpu(pending_eoi);
unsigned int vector = (u8)get_irq_regs()->entry_vector;
+unsigned done = 0;//temp
if ( unlikely(action->nr_guests == 0) )
{
@@ -1167,6 +1196,9 @@ static void __do_IRQ_guest(int irq)
return;
}
+ if ( action->ack_type != ACKTYPE_NONE )
+ stop_timer(&action->eoi_timer);
+
if ( action->ack_type == ACKTYPE_EOI )
{
sp = pending_eoi_sp(peoi);
@@ -1187,6 +1219,7 @@ static void __do_IRQ_guest(int irq)
pirq = pirq_info(d, domain_irq_to_pirq(d, irq));
if ( (action->ack_type != ACKTYPE_NONE) &&
!test_and_set_bool(pirq->masked) )
+++done,//temp
action->in_flight++;
if ( !is_hvm_domain(d) || !hvm_do_IRQ_dpci(d, pirq) )
send_guest_pirq(d, pirq);
@@ -1194,10 +1227,16 @@ static void __do_IRQ_guest(int irq)
if ( action->ack_type != ACKTYPE_NONE )
{
- stop_timer(&action->eoi_timer);
migrate_timer(&action->eoi_timer, smp_processor_id());
set_timer(&action->eoi_timer, NOW() + MILLISECS(1));
}
+if(!done) {//temp
+ static unsigned long cnt, thr;
+ if(++cnt > thr) {
+ thr |= cnt;
+ printk("IRQ%d: d=0 n=%u i=%u a=%d\n", irq, action->nr_guests, action->in_flight, action->ack_type);
+ }
+}
}
/*
@@ -1457,6 +1496,8 @@ void desc_guest_eoi(struct irq_desc *des
return;
}
+ stop_timer(&action->eoi_timer);
+
if ( action->ack_type == ACKTYPE_UNMASK )
{
ASSERT(cpumask_empty(action->cpu_eoi_map));
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH 1/2] perf/x86/intel: Support adaptive PEBS for fixed counters
From: Liang, Kan @ 2019-04-10 13:57 UTC (permalink / raw)
To: Peter Zijlstra
Cc: mingo, linux-kernel, tglx, acme, jolsa, eranian,
alexander.shishkin, ak
In-Reply-To: <20190410074139.GW11158@hirez.programming.kicks-ass.net>
On 4/10/2019 3:41 AM, Peter Zijlstra wrote:
> On Tue, Apr 09, 2019 at 06:09:59PM -0700, kan.liang@linux.intel.com wrote:
>> From: Kan Liang <kan.liang@linux.intel.com>
>>
>> Fixed counters can also generate adaptive PEBS record, if the
>> corresponding bit in IA32_FIXED_CTR_CTRL is set.
>> Otherwise, only basic record is generated.
>>
>> Unconditionally set the bit when PEBS is enabled on fixed counters.
>> Let MSR_PEBS_CFG decide which format of PEBS record should be generated.
>> There is no harmful to leave the bit set.
>
> I'll merge this back into:
>
> Subject: perf/x86/intel: Support adaptive PEBSv4
>
> such that this bug never existed, ok?
Yes, please.
Thanks,
Kan
>
>>
>> Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
>> ---
>> arch/x86/events/intel/core.c | 5 +++++
>> arch/x86/include/asm/perf_event.h | 1 +
>> 2 files changed, 6 insertions(+)
>>
>> diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
>> index 56df0f6..f34d92b 100644
>> --- a/arch/x86/events/intel/core.c
>> +++ b/arch/x86/events/intel/core.c
>> @@ -2174,6 +2174,11 @@ static void intel_pmu_enable_fixed(struct perf_event *event)
>> bits <<= (idx * 4);
>> mask = 0xfULL << (idx * 4);
>>
>> + if (x86_pmu.intel_cap.pebs_baseline && event->attr.precise_ip) {
>> + bits |= ICL_FIXED_0_ADAPTIVE << (idx * 4);
>> + mask |= ICL_FIXED_0_ADAPTIVE << (idx * 4);
>> + }
>> +
>> rdmsrl(hwc->config_base, ctrl_val);
>> ctrl_val &= ~mask;
>> ctrl_val |= bits;
>> diff --git a/arch/x86/include/asm/perf_event.h b/arch/x86/include/asm/perf_event.h
>> index dcb8bac..ce0dc88 100644
>> --- a/arch/x86/include/asm/perf_event.h
>> +++ b/arch/x86/include/asm/perf_event.h
>> @@ -33,6 +33,7 @@
>> #define HSW_IN_TX (1ULL << 32)
>> #define HSW_IN_TX_CHECKPOINTED (1ULL << 33)
>> #define ICL_EVENTSEL_ADAPTIVE (1ULL << 34)
>> +#define ICL_FIXED_0_ADAPTIVE (1ULL << 32)
>>
>> #define AMD64_EVENTSEL_INT_CORE_ENABLE (1ULL << 36)
>> #define AMD64_EVENTSEL_GUESTONLY (1ULL << 40)
>> --
>> 2.7.4
>>
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] migration: Fix handling fd protocol
From: Dr. David Alan Gilbert @ 2019-04-10 13:57 UTC (permalink / raw)
To: Yury Kotov, armbru, berrange; +Cc: Juan Quintela, yc-core, qemu-devel
In-Reply-To: <20190410092652.22616-1-yury-kotov@yandex-team.ru>
* Yury Kotov (yury-kotov@yandex-team.ru) wrote:
> Currently such case is possible for incoming:
> QMP: add-fd (fdset = 0, fd of some file):
> adds fd to fdset 0 and returns QEMU's fd (e.g. 33)
> QMP: migrate-incoming (uri = "fd:33"): fd is stored in QIOChannel *ioc
> ...
> Incoming migration completes and unrefs ioc -> close(33)
> QMP: remove-fd (fdset = 0, fd = 33):
> removes fd from fdset 0 and qemu_close() -> close(33) => double close
Well spotted! That would very rarely cause a problem, but is a race.
> For outgoing migration the case is the same but getfd instead of add-fd.
> Fix it by duping client's fd.
>
> Signed-off-by: Yury Kotov <yury-kotov@yandex-team.ru>
Note your patch hit a problem building on windows; I don't think we have
a qemu_dup for windows.
However, I think this problem is wider than just migration.
For example, I see that dump.c also uses monitor_get_fd, and it's
dump_cleanup also does a close on the fd. So I guess it hits the same
problem?
Also, qmp.c in qmp_add_client does a close on the fd in some error cases
(I've not followed the normal case).
So perhaps all the users of monitor_get_fd are hitting this problem.
Should we be doing the dup in monitor_get_fd?
Dave
> ---
> migration/fd.c | 39 +++++++++++++++++++++++++++++++--------
> migration/trace-events | 4 ++--
> 2 files changed, 33 insertions(+), 10 deletions(-)
>
> diff --git a/migration/fd.c b/migration/fd.c
> index a7c13df4ad..c9ff07ac41 100644
> --- a/migration/fd.c
> +++ b/migration/fd.c
> @@ -15,6 +15,7 @@
> */
>
> #include "qemu/osdep.h"
> +#include "qapi/error.h"
> #include "channel.h"
> #include "fd.h"
> #include "migration.h"
> @@ -26,15 +27,27 @@
> void fd_start_outgoing_migration(MigrationState *s, const char *fdname, Error **errp)
> {
> QIOChannel *ioc;
> - int fd = monitor_get_fd(cur_mon, fdname, errp);
> + int fd, dup_fd;
> +
> + fd = monitor_get_fd(cur_mon, fdname, errp);
> if (fd == -1) {
> return;
> }
>
> - trace_migration_fd_outgoing(fd);
> - ioc = qio_channel_new_fd(fd, errp);
> + /* fd is previously created by qmp command 'getfd',
> + * so client is responsible to close it. Dup it to save original value from
> + * QIOChannel's destructor */
> + dup_fd = qemu_dup(fd);
> + if (dup_fd == -1) {
> + error_setg(errp, "Cannot dup fd %s: %s (%d)", fdname, strerror(errno),
> + errno);
> + return;
> + }
> +
> + trace_migration_fd_outgoing(fd, dup_fd);
> + ioc = qio_channel_new_fd(dup_fd, errp);
> if (!ioc) {
> - close(fd);
> + close(dup_fd);
> return;
> }
>
> @@ -55,14 +68,24 @@ static gboolean fd_accept_incoming_migration(QIOChannel *ioc,
> void fd_start_incoming_migration(const char *infd, Error **errp)
> {
> QIOChannel *ioc;
> - int fd;
> + int fd, dup_fd;
>
> fd = strtol(infd, NULL, 0);
> - trace_migration_fd_incoming(fd);
>
> - ioc = qio_channel_new_fd(fd, errp);
> + /* fd is previously created by qmp command 'add-fd' or something else,
> + * so client is responsible to close it. Dup it to save original value from
> + * QIOChannel's destructor */
> + dup_fd = qemu_dup(fd);
> + if (dup_fd == -1) {
> + error_setg(errp, "Cannot dup fd %d: %s (%d)", fd, strerror(errno),
> + errno);
> + return;
> + }
> +
> + trace_migration_fd_incoming(fd, dup_fd);
> + ioc = qio_channel_new_fd(dup_fd, errp);
> if (!ioc) {
> - close(fd);
> + close(dup_fd);
> return;
> }
>
> diff --git a/migration/trace-events b/migration/trace-events
> index de2e136e57..d2d30a6b3c 100644
> --- a/migration/trace-events
> +++ b/migration/trace-events
> @@ -258,8 +258,8 @@ migration_exec_outgoing(const char *cmd) "cmd=%s"
> migration_exec_incoming(const char *cmd) "cmd=%s"
>
> # fd.c
> -migration_fd_outgoing(int fd) "fd=%d"
> -migration_fd_incoming(int fd) "fd=%d"
> +migration_fd_outgoing(int fd, int dup_fd) "fd=%d dup_fd=%d"
> +migration_fd_incoming(int fd, int dup_fd) "fd=%d dup_fd=%d"
>
> # socket.c
> migration_socket_incoming_accepted(void) ""
> --
> 2.21.0
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
^ permalink raw reply
* x86 guest EOI timer issues / questions
From: Jan Beulich @ 2019-04-10 13:57 UTC (permalink / raw)
To: xen-devel; +Cc: Andrew Cooper, Wei Liu, Roger Pau Monne
All,
Andrew's observation mentioned in "[PATCH v2] x86/smt: Support for
enabling/disabling SMT at runtime" and some discussions we've already
had with him made me look into how exactly the EOI timer works. I
think there are a number of quirks. I'll enumerate all questions I've run
into below. At the end of the mail is a patch carrying out some of the
adjustments implied by a subset of these questions, plus the addition
of some debugging code. It is perhaps worthwhile to note that the
printk()-s irq_guest_eoi_timer_fn() both were observed to trigger
prior to making the non-debugging code changes. With the patch in
its current shape, I've seen trigger (every once in a while) only the
printk() added to __do_IRQ_guest().
- Why does the timer not get stopped in desc_guest_eoi() when
->in_flight is zero?
- Why does irq_guest_eoi_timer_fn() not re-arm the timer when
->in_flight is still non-zero after all the decrements? Can this case
happen at all, considering that the only increment in
__do_IRQ_guest() happens under the same desc lock? (If it can
happen, I think it would be against the purpose of 37eb6d05fe,
as this would mean the IRQ can then remain un-acked for an
indefinite period of time, unless something else re-armed the
timer.)
- Why does irq_guest_eoi_timer_fn() issue ->end() / set_eoi_ready()
even when no decrement of any ->in_flight was done at all? Neither
for ACKTYPE_UNMASK nor for ACKTYPE_EOI this looks to be fully
race free.
- Wouldn't __do_IRQ_guest() better stop the timer early on?
- Wouldn't __do_IRQ_guest() better avoid re-programming the timer
if no ->in_flight increment was done (which I would have thought
shouldn't happen anyway, but which I've observed in practice)? Of
course this would mean the timer may only be stopped when the
first increment occurs.
- What about the timer triggering while __do_IRQ_guest() is active
(holding the desc lock)? This looks to result in immediate expiry of
the EOI deferral for the current interrupt instance (and I've
observed this in practice, luckily with no other visible bad effects).
- Is it okay for fixup_eoi() to fiddle with action->cpu_eoi_map
without holding the desc lock? (I guess being in stop-machine /
SMP-boot context makes this acceptable.)
Commits of interest:
f3922f4084 x86: Support CPU hotplug offline
37eb6d05fe x86: Automatically EOI guest-bound interrupts if guest takes too long
Other notes / observations:
- irq_guest_eoi_timer_fn() should not need to re-acquire the lock
after on_selected_cpus()
- irq_guest_eoi_timer_fn() should not need to use irqsave/irqrestore
spin lock/unlock (plain irq ones should suffice in a timer handler)
- irq_guest_eoi_timer_fn() could ASSERT(action->ack_type !=
ACKTYPE_NONE) instead of having such a conditional
- fixup_eoi() may better avoid setting all peoi[].ready and instead
pass a "force" boolean to flush_ready_eoi()
Thoughts / opinions appreciated,
Jan
--- unstable.orig/xen/arch/x86/irq.c
+++ unstable/xen/arch/x86/irq.c
@@ -1103,7 +1103,7 @@ static void set_eoi_ready(void *data);
static void irq_guest_eoi_timer_fn(void *data)
{
struct irq_desc *desc = data;
- unsigned int irq = desc - irq_desc;
+ unsigned int irq = desc - irq_desc, done = 0;
irq_guest_action_t *action;
cpumask_t cpu_eoi_map;
unsigned long flags;
@@ -1115,6 +1115,16 @@ static void irq_guest_eoi_timer_fn(void
action = (irq_guest_action_t *)desc->action;
+ if ( action->eoi_timer.status >= TIMER_STATUS_in_heap )
+{//temp
+ static unsigned long cnt, thr;
+ if(++cnt > thr) {
+ thr |= cnt;
+ printk("IRQ%u: i=%u a=%d n=%u\n", irq, action->in_flight, action->ack_type, action->nr_guests);
+ }
+ goto out;
+}
+
if ( action->ack_type != ACKTYPE_NONE )
{
unsigned int i;
@@ -1122,11 +1132,29 @@ static void irq_guest_eoi_timer_fn(void
{
struct domain *d = action->guest[i];
unsigned int pirq = domain_irq_to_pirq(d, irq);
+
if ( test_and_clear_bool(pirq_info(d, pirq)->masked) )
- action->in_flight--;
+ ++done;
}
+ action->in_flight -= done;
}
+{//temp
+ static unsigned long done_cnt, done_thr;
+ static unsigned long infl_cnt, infl_thr;
+ bool log = false;
+ if(action->in_flight && ++infl_cnt > infl_thr) {
+ infl_thr |= infl_cnt;
+ log = true;
+ } else if(!done && ++done_cnt > done_thr) {
+ done_thr |= done_cnt;
+ log = true;
+ }
+ if(log)
+ printk("IRQ%u: d=%u i=%u a=%d n=%u (%06lx,%06lx)\n", irq, done, action->in_flight,
+ action->ack_type, action->nr_guests, done_cnt, infl_cnt);
+}
+//todo Instead of the below, assert that ->in_flight is zero and bail if done is zero?
if ( action->in_flight != 0 )
goto out;
@@ -1156,6 +1184,7 @@ static void __do_IRQ_guest(int irq)
int i, sp;
struct pending_eoi *peoi = this_cpu(pending_eoi);
unsigned int vector = (u8)get_irq_regs()->entry_vector;
+unsigned done = 0;//temp
if ( unlikely(action->nr_guests == 0) )
{
@@ -1167,6 +1196,9 @@ static void __do_IRQ_guest(int irq)
return;
}
+ if ( action->ack_type != ACKTYPE_NONE )
+ stop_timer(&action->eoi_timer);
+
if ( action->ack_type == ACKTYPE_EOI )
{
sp = pending_eoi_sp(peoi);
@@ -1187,6 +1219,7 @@ static void __do_IRQ_guest(int irq)
pirq = pirq_info(d, domain_irq_to_pirq(d, irq));
if ( (action->ack_type != ACKTYPE_NONE) &&
!test_and_set_bool(pirq->masked) )
+++done,//temp
action->in_flight++;
if ( !is_hvm_domain(d) || !hvm_do_IRQ_dpci(d, pirq) )
send_guest_pirq(d, pirq);
@@ -1194,10 +1227,16 @@ static void __do_IRQ_guest(int irq)
if ( action->ack_type != ACKTYPE_NONE )
{
- stop_timer(&action->eoi_timer);
migrate_timer(&action->eoi_timer, smp_processor_id());
set_timer(&action->eoi_timer, NOW() + MILLISECS(1));
}
+if(!done) {//temp
+ static unsigned long cnt, thr;
+ if(++cnt > thr) {
+ thr |= cnt;
+ printk("IRQ%d: d=0 n=%u i=%u a=%d\n", irq, action->nr_guests, action->in_flight, action->ack_type);
+ }
+}
}
/*
@@ -1457,6 +1496,8 @@ void desc_guest_eoi(struct irq_desc *des
return;
}
+ stop_timer(&action->eoi_timer);
+
if ( action->ack_type == ACKTYPE_UNMASK )
{
ASSERT(cpumask_empty(action->cpu_eoi_map));
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH 1/1] of: reserved_mem: fix reserve memory leak
From: Rob Herring @ 2019-04-10 13:56 UTC (permalink / raw)
To: pierre Kuo; +Cc: Frank Rowand, devicetree, linux-kernel
In-Reply-To: <20190219074500.16454-1-vichy.kuo@gmail.com>
On Tue, Feb 19, 2019 at 03:45:00PM +0800, pierre Kuo wrote:
> The __reserved_mem_init_node will call region specific reserved memory
> init codes, but once all compatibled init codes failed, the memory region
> will left in memory.reserved and cause leakage.
>
> Take cma reserve memory DTS for example, if user declare 1MB size,
> which is not align to (PAGE_SIZE << max(MAX_ORDER - 1,
> pageblock_order)), rmem_cma_setup will return -EINVAL.
> Meanwhile, rmem_dma_setup will also return -EINVAL since "reusable"
> property is not set. If finally there is no reserved memory init pick up
> this memory, kernel will left the 1MB leak in memory.reserved.
>
> This patch will remove this kind of memory from memory.reserved, only
> when __reserved_mem_init_node return neither 0 nor -ENOENT.
>
> Signed-off-by: pierre Kuo <vichy.kuo@gmail.com>
> ---
> drivers/of/of_reserved_mem.c | 22 +++++++++++++++++-----
> 1 file changed, 17 insertions(+), 5 deletions(-)
As no one else seems to have any comments, I've applied it.
Rob
^ permalink raw reply
* Re: [PATCH] ARM: dts: stm32: add I2C sleep pins muxing on stm32mp157
From: Alexandre Torgue @ 2019-04-10 13:56 UTC (permalink / raw)
To: Yannick Fertré, Maxime Coquelin, Rob Herring, Mark Rutland,
linux-stm32, linux-arm-kernel, devicetree, linux-kernel,
Benjamin Gaignard, Philippe Cornu, Fabrice Gasnier
In-Reply-To: <1553856500-31009-1-git-send-email-yannick.fertre@st.com>
Hi Yannick
On 3/29/19 11:48 AM, Yannick Fertré wrote:
> Add I2C sleep pins muxing for low power mode.
>
> Signed-off-by: Pierre-Yves MORDRET <pierre-yves.mordret@st.com>
> Signed-off-by: Yannick Fertré <yannick.fertre@st.com>
> ---
> arch/arm/boot/dts/stm32mp157-pinctrl.dtsi | 29 +++++++++++++++++++++++++++++
> 1 file changed, 29 insertions(+)
>
> diff --git a/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi b/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi
> index 9104896..b04899f 100644
> --- a/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi
> +++ b/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi
> @@ -213,6 +213,13 @@
> };
>
Applied on stm32-next.
Thanks.
Alex
^ permalink raw reply
* Re: [PATCH] test-lib: whitelist GIT_TR2_* in the environment
From: Jeff Hostetler @ 2019-04-10 13:56 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason, git
Cc: Junio C Hamano, Jeff Hostetler
In-Reply-To: <20190330075119.13156-1-avarab@gmail.com>
On 3/30/2019 3:51 AM, Ævar Arnfjörð Bjarmason wrote:
> Add GIT_TR2_* to the whitelist of environment variables that we don't
> clear when running the test suite.
>
> This allows us to use the test suite to produce trace2 test data,
> which is handy to e.g. write consumers that collate the trace data
> itself.
>
> One caveat here is that we produce trace output for not *just* the
> tests, but also e.g. from this line in test-lib.sh:
>
> # It appears that people try to run tests without building...
> "${GIT_TEST_INSTALLED:-$GIT_BUILD_DIR}/git$X" >/dev/null
> [...]
>
> I consider this not just OK but a feature. Let's log *all* the git
> commands we're going to execute, not just those within
> test_expect_*().
>
> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
> ---
> t/test-lib.sh | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/t/test-lib.sh b/t/test-lib.sh
> index 562c57e685..f6318c54c9 100644
> --- a/t/test-lib.sh
> +++ b/t/test-lib.sh
> @@ -379,6 +379,7 @@ unset VISUAL EMAIL LANGUAGE COLUMNS $("$PERL_PATH" -e '
> my @env = keys %ENV;
> my $ok = join("|", qw(
> TRACE
> + TR2_
> DEBUG
> TEST
> .*_TEST
>
I could go either way on this one. It would be nice to have
telemetry for all of the commands run by the suite (and especially
for perf tests) for our developer analysis purposes. But if your
settings have you route that data to a DB, your DBA might not be
happy with you....
Jeff
^ permalink raw reply
* Re: deadlock in XFS
From: Eric Sandeen @ 2019-04-10 13:55 UTC (permalink / raw)
To: Ming Li, darrick.wong, linux-xfs
In-Reply-To: <49c750b2-b856-14b3-0f94-183fba5a753b@shannon-data.com>
On 4/10/19 7:43 AM, Ming Li wrote:
> hi Eric,
>
> Thanks for your reply, do you know this change started from which version? or where can i find the changes list about XFS`s all versions?
>
The change was
commit 6bdcf26ade8825ffcdc692338e715cd7ed0820d8
Author: Christoph Hellwig <hch@lst.de>
Date: Fri Nov 3 10:34:46 2017 -0700
xfs: use a b+tree for the in-core extent list
and related patches which went into 4.15.
$ git describe --contains 6bdcf26ade8825ffcdc692338e715cd7ed0820d8
xfs-4.15-merge-1~27
the master changelog for xfs is in git history for the kernel.
-Eric
> Ming Li
>
>
> On 2019/4/10 12:17, Eric Sandeen wrote:
>> On 4/9/19 8:49 PM, Ming Li wrote:
>>> hi,
>>> It is my great honor writing to you.I`m a driver engineer from china, I have a problem when I`m testing xfs iops on Intel P4510 2.0T. xfs deadlocks in my testcase. messages as this:
>>>
>>> kworker/23:75(11126) possible memory allocation deadlock size 4194320 in kmem_alloc (mode:0x250) (this memory allocation need more than 4M memory from once kmalloc, I think it will failure always.)
>> This is a known deficiency in older kernels, because xfs requires contiguous
>> memory for extent management. If a file is highly fragmented, you may run
>> into this. It's fixed upstream in newer kernels with a different extent
>> management infrastructure.
>>
>> Best thing to do on an older kernel is to work around it by using something like
>> an extent size hint to minimize fragmentation.
>>
>> -Eric
>>
>>
>>
>>
>>> or like this:
>>>
>>> Apr 8 06:10:33 r720_1 kernel: XFS: kworker/3:129(7679) possible memory allocation deadlock size 2316352 in kmem_alloc (mode:0x250)
>>> Apr 8 06:10:33 r720_1 kernel: [292720.008492] XFS: kworker/2:30(7476) possible memory allocation deadlock size 2221840 in kmem_alloc (mode:0x250)
>>> Apr 8 06:10:33 r720_1 kernel: XFS: kworker/2:30(7476) possible memory allocation deadlock size 2221840 in kmem_alloc (mode:0x250)
>>> Apr 8 06:10:34 r720_1 kernel: [292720.168489] XFS: kworker/2:80(7554) possible memory allocation deadlock size 2208848 in kmem_alloc (mode:0x250)
>>> Apr 8 06:10:34 r720_1 kernel: XFS: kworker/2:80(7554) possible memory allocation deadlock size 2208848 in kmem_alloc (mode:0x250)
>>> Apr 8 06:10:34 r720_1 kernel: [292720.308505] XFS: kworker/2:1(6884) possible memory allocation deadlock size 2367680 in kmem_alloc (mode:0x250)
>>> Apr 8 06:10:34 r720_1 kernel: XFS: kworker/2:1(6884) possible memory allocation deadlock size 2367680 in kmem_alloc (mode:0x250)
>>> Apr 8 06:10:34 r720_1 kernel: [292720.728593] XFS: kworker/7:22(7098) possible memory allocation deadlock size 2228800 in kmem_alloc (mode:0x250)
>>> Apr 8 06:10:34 r720_1 kernel: XFS: kworker/7:22(7098) possible memory allocation deadlock size 2228800 in kmem_alloc (mode:0x250)
>>> Apr 8 06:10:34 r720_1 kernel: [292720.828529] XFS: kworker/7:95(7512) possible memory allocation deadlock size 2097728 in kmem_alloc (mode:0x250)
>>> Apr 8 06:10:34 r720_1 kernel: XFS: kworker/7:95(7512) possible memory allocation deadlock size 2097728 in kmem_alloc (mode:0x250)
>>> Apr 8 06:10:35 r720_1 kernel: [292721.428557] XFS: kworker/5:1(7134) possible memory allocation deadlock size 2097184 in kmem_alloc (mode:0x250)
>>> Apr 8 06:10:35 r720_1 kernel: XFS: kworker/5:1(7134) possible memory allocation deadlock size 2097184 in kmem_alloc (mode:0x250)
>>> Apr 8 06:10:35 r720_1 kernel: [292721.468569] XFS: kworker/4:235(7923) possible memory allocation deadlock size 2097168 in kmem_alloc (mode:0x250)
>>> Apr 8 06:10:35 r720_1 kernel: XFS: kworker/4:235(7923) possible memory allocation deadlock size 2097168 in kmem_alloc (mode:0x250)
>>> Apr 8 06:10:35 r720_1 kernel: [292721.588576] XFS: kworker/3:129(7679) possible memory allocation deadlock size 2316352 in kmem_alloc (mode:0x250)
>>> Apr 8 06:10:35 r720_1 kernel: XFS: kworker/3:129(7679) possible memory allocation deadlock size 2316352 in kmem_alloc (mode:0x250)
>>> Apr 8 06:10:35 r720_1 kernel: [292722.008652] XFS: kworker/2:30(7476) possible memory allocation deadlock size 2221840 in kmem_alloc (mode:0x250)
>>>
>>> (although xfs need memory less than 4M, but it still deadlocks.)
>>>
>>> And, I catched CallTrace:
>>> Call Trace:
>>> [<ffffffff8613a282>] dump_stack+0x19/0x1b
>>> [<ffffffffc055bcb7>] kmem_realloc+0x127/0x140 [xfs]
>>> [<ffffffffc052e1b2>] xfs_iext_realloc_indirect+0x22/0x40 [xfs]
>>> [<ffffffffc052e9bf>] xfs_iext_irec_new+0x3f/0x170 [xfs]
>>> [<ffffffffc052ec6a>] xfs_iext_add_indirect_multi+0x17a/0x2d0 [xfs]
>>> [<ffffffffc052efd1>] xfs_iext_add+0x211/0x2c0 [xfs]
>>> [<ffffffffc052f6f8>] xfs_iext_insert+0x58/0xf0 [xfs]
>>> [<ffffffffc0508bcd>] ? xfs_bmap_add_extent_unwritten_real+0x38d/0x18f0 [xfs]
>>> [<ffffffffc0508bcd>] xfs_bmap_add_extent_unwritten_real+0x38d/0x18f0 [xfs]
>>> [<ffffffffc050a246>] xfs_bmapi_convert_unwritten+0x116/0x1c0 [xfs]
>>> [<ffffffffc050f2e9>] xfs_bmapi_write+0x269/0xab0 [xfs]
>>> [<ffffffffc054aeb7>] xfs_iomap_write_unwritten+0x117/0x300 [xfs]
>>> [<ffffffffc0535f63>] xfs_end_io_direct_write+0x133/0x170 [xfs]
>>> [<ffffffff85c6e465>] dio_complete+0x125/0x2a0
>>> [<ffffffff85c6e761>] dio_aio_complete_work+0x21/0x30
>>> [<ffffffff85ab952f>] process_one_work+0x17f/0x440
>>> [<ffffffff85aba5c6>] worker_thread+0x126/0x3c0
>>> [<ffffffff85aba4a0>] ? manage_workers.isra.25+0x2a0/0x2a0
>>> [<ffffffff85ac1341>] kthread+0xd1/0xe0
>>> [<ffffffff85ac1270>] ? insert_kthread_work+0x40/0x40
>>> [<ffffffff8614caf7>] ret_from_fork_nospec_begin+0x21/0x21
>>> [<ffffffff85ac1270>] ? insert_kthread_work+0x40/0x40
>>>
>>>
>>> my test platform is:
>>> Architecture: x86_64
>>> CPU op-mode(s): 32-bit, 64-bit
>>> Byte Order: Little Endian
>>> CPU(s): 8
>>> On-line CPU(s) list: 0-7
>>> Thread(s) per core: 1
>>> Core(s) per socket: 4
>>> Socket(s): 2
>>> NUMA node(s): 2
>>> Vendor ID: GenuineIntel
>>> CPU family: 6
>>> Model: 62
>>> Model name: Intel(R) Xeon(R) CPU E5-2609 v2 @ 2.50GHz
>>> Stepping: 4
>>> CPU MHz: 1199.951
>>> BogoMIPS: 5005.23
>>> Virtualization: VT-x
>>> L1d cache: 32K
>>> L1i cache: 32K
>>> L2 cache: 256K
>>> L3 cache: 10240K
>>> NUMA node0 CPU(s): 0,2,4,6
>>> NUMA node1 CPU(s): 1,3,5,7
>>>
>>>
>>> memory size is(this problem is still in the server that has 256G memory, so i think it is not about memory size and swap is truned off):
>>> total used free shared buff/cache available
>>> Mem: 23 10 12 0 0 12
>>> Swap: 15 0 15
>>>
>>> system:
>>> centos 7.3.1611
>>>
>>> kernel:
>>> 3.10.0-957.10.1.el7.x86_64
>>>
>>> test step(fio version: 2.2.9):
>>> 1. mkfs.xfs /dev/nvme0n1
>>> 2. mount /dev/nvme0n1 /nvme0n1
>>> 3. fio --ioengine=libaio --randrepeat=0 --norandommap --thread --direct=1 --group_reporting --time_based --random_generator=tausworthe --runtime=7200 --output=20190409-174239+0800/fsiops/log/fsiops_xfs_randwrite_iops.log --directory=/nvme0n1 --size=190679M --bs=4k --name=xfs_randwrite_iops --rw=randwrite --numjobs=8 --iodepth=32
>>>
>>> xfs will deadlocks when running about 1 hours and 45 minutes, and i must cold restart my server.
>>>
>>> And i found a patch in community, it is:
>>> https://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs.git/commit/?id=b3f03bac8132207a20286d5602eda64500c19724
>>>
>>> it have been merged since kernel 3.14, and i`m sure that this patch is not in 3.10.0-957.10.1.el7.x86_64.
>>> So, I use 3.14 to do my test, and this appearance was not appeared in 3.14.
>>>
>>> I don`t know about architecture of XFS, so i`m not sure whether they have relevant. Because i think the deadlock was in xfs_iext_realloc_indirect(), but the patch fixed about xfs_dir2_block_to_sf(). But the true is this problem don`t appear in kernel 3.14 anymore, so i think this problem have been fixed completely in 3.14.but i don`t know which patch fixed it.
>>>
>>> So, Would you tell me whether this patch is root cause, or which patch fixed it.
>>>
>>> Thank you for your attention to this matter.
>>>
>>> Best regards
>>>
>>>
>>> Ming.Li
>>>
>>>
>>>
>>>
>
^ permalink raw reply
* Re: [PATCH] ARM: dts: stm32: add power supply of otm8009a on stm32mp157c-dk2
From: Alexandre Torgue @ 2019-04-10 13:54 UTC (permalink / raw)
To: Yannick Fertré, Maxime Coquelin, Rob Herring, Mark Rutland,
linux-stm32, linux-arm-kernel, devicetree, linux-kernel,
Benjamin Gaignard, Philippe Cornu
In-Reply-To: <1553854406-28992-1-git-send-email-yannick.fertre@st.com>
Hi Yannick
On 3/29/19 11:13 AM, Yannick Fertré wrote:
> This patch adds a new property (power-supply) to panel otm8009a (orisetech)
> on stm32mp157c-dk2 & regulator v3v3 which is always set on until the
> implementation of regulator driver.
>
> Signed-off-by: Yannick Fertré <yannick.fertre@st.com>
> ---
> arch/arm/boot/dts/stm32mp157c-dk2.dts | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/stm32mp157c-dk2.dts b/arch/arm/boot/dts/stm32mp157c-dk2.dts
> index 363aeb9..20ea601 100644
> --- a/arch/arm/boot/dts/stm32mp157c-dk2.dts
> +++ b/arch/arm/boot/dts/stm32mp157c-dk2.dts
> @@ -50,6 +50,7 @@
> compatible = "orisetech,otm8009a";
> reg = <0>;
> reset-gpios = <&gpioe 4 GPIO_ACTIVE_LOW>;
> + power-supply = <&v3v3>;
> status = "okay";
>
> port {
>
Applied on stm32-next. I just updated the commit message as regulator
fixed hook is no more used due to stpmic1 merge.
Thanks.
Alex
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] MIPS: eBPF: Make ebpf_to_mips_reg() static
From: Yue Haibing @ 2019-04-10 13:49 UTC (permalink / raw)
To: paul.burton, ralf, jhogan, ast, daniel, kafai, songliubraving,
yhs
Cc: linux-kernel, linux-mips, netdev, bpf, YueHaibing
From: YueHaibing <yuehaibing@huawei.com>
Fix sparse warning:
arch/mips/net/ebpf_jit.c:196:5: warning:
symbol 'ebpf_to_mips_reg' was not declared. Should it be static?
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
arch/mips/net/ebpf_jit.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/mips/net/ebpf_jit.c b/arch/mips/net/ebpf_jit.c
index 3548a69..dfd5a4b 100644
--- a/arch/mips/net/ebpf_jit.c
+++ b/arch/mips/net/ebpf_jit.c
@@ -193,8 +193,9 @@ enum which_ebpf_reg {
* separate frame pointer, so BPF_REG_10 relative accesses are
* adjusted to be $sp relative.
*/
-int ebpf_to_mips_reg(struct jit_ctx *ctx, const struct bpf_insn *insn,
- enum which_ebpf_reg w)
+static int ebpf_to_mips_reg(struct jit_ctx *ctx,
+ const struct bpf_insn *insn,
+ enum which_ebpf_reg w)
{
int ebpf_reg = (w == src_reg || w == src_reg_no_fp) ?
insn->src_reg : insn->dst_reg;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 12/12] [PROBABLY WRONG] s390: void '0' constraint in inline assembly
From: Martin Schwidefsky @ 2019-04-10 13:55 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Heiko Carstens, clang-built-linux, Nick Desaulniers,
Nathan Chancellor, linux-s390, Vasily Gorbik, linux-kernel
In-Reply-To: <20190408212648.2407234-12-arnd@arndb.de>
On Mon, 8 Apr 2019 23:26:25 +0200
Arnd Bergmann <arnd@arndb.de> wrote:
> clang does not understand the contraint "0" in the CALL_ON_STACK()
> macro:
>
> ../arch/s390/mm/maccess.c:117:10: error: invalid input constraint '0' in asm
> return CALL_ON_STACK(_memcpy_real, S390_lowcore.nodat_stack,
> ^
> ../arch/s390/include/asm/processor.h:292:20: note: expanded from macro 'CALL_ON_STACK'
> [_fn] "X" (fn) CALL_FMT_##nr : CALL_CLOBBER_##nr); \
> ^
> <scratch space>:207:1: note: expanded from here
> CALL_FMT_3
> ^
> ../arch/s390/include/asm/processor.h:267:20: note: expanded from macro 'CALL_FMT_3'
> #define CALL_FMT_3 CALL_FMT_2, "d" (r4)
> ^
> ../arch/s390/include/asm/processor.h:266:20: note: expanded from macro 'CALL_FMT_2'
> #define CALL_FMT_2 CALL_FMT_1, "d" (r3)
> ^
> ../arch/s390/include/asm/processor.h:265:32: note: expanded from macro 'CALL_FMT_1'
> #define CALL_FMT_1 CALL_FMT_0, "0" (r2)
> ^
>
> I don't know what the correct fix here would be, changing it to "d" made
> it build, since clang does understand this one.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> arch/s390/include/asm/processor.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/s390/include/asm/processor.h b/arch/s390/include/asm/processor.h
> index 700c650ffd4f..84c59c99668a 100644
> --- a/arch/s390/include/asm/processor.h
> +++ b/arch/s390/include/asm/processor.h
> @@ -262,7 +262,7 @@ static __no_kasan_or_inline unsigned short stap(void)
> register unsigned long r4 asm("6") = (unsigned long)(arg5)
>
> #define CALL_FMT_0
> -#define CALL_FMT_1 CALL_FMT_0, "0" (r2)
> +#define CALL_FMT_1 CALL_FMT_0, "d" (r2)
> #define CALL_FMT_2 CALL_FMT_1, "d" (r3)
> #define CALL_FMT_3 CALL_FMT_2, "d" (r4)
> #define CALL_FMT_4 CALL_FMT_3, "d" (r5)
This is (slightly) wrong. %r2 is used as the input register for the first argument
and the result value for the call. With your patch you force the compiler to load
the first argument in two registers. One solution would be to CALL_FMT1 as
#define CALL_FMT1 CALL_FMT_0
It still is not optimal though as for CALL_FMT_0 the "+&d" (r2) indicates an
input but CALL_ARGS_0 does not initialize r2.
I am thinking about the following patch to cover all cases:
--
From 91a4abbec91a9f26f84f7386f2c0f96de669b0eb Mon Sep 17 00:00:00 2001
From: Martin Schwidefsky <schwidefsky@de.ibm.com>
Date: Wed, 10 Apr 2019 15:48:43 +0200
Subject: [PATCH] s390: fine-tune stack switch helper
The CALL_ON_STACK helper currently does not work with clang and for
calls without arguments it does not initialize r2 although the contraint
is "+&d". Rework the CALL_FMT_x and the CALL_ON_STACK macros to work
with clang and produce optimal code in all cases.
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
---
arch/s390/include/asm/processor.h | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/s390/include/asm/processor.h b/arch/s390/include/asm/processor.h
index 81038ab357ce..0ee022247580 100644
--- a/arch/s390/include/asm/processor.h
+++ b/arch/s390/include/asm/processor.h
@@ -261,12 +261,12 @@ static __no_kasan_or_inline unsigned short stap(void)
CALL_ARGS_4(arg1, arg2, arg3, arg4); \
register unsigned long r4 asm("6") = (unsigned long)(arg5)
-#define CALL_FMT_0
-#define CALL_FMT_1 CALL_FMT_0, "0" (r2)
-#define CALL_FMT_2 CALL_FMT_1, "d" (r3)
-#define CALL_FMT_3 CALL_FMT_2, "d" (r4)
-#define CALL_FMT_4 CALL_FMT_3, "d" (r5)
-#define CALL_FMT_5 CALL_FMT_4, "d" (r6)
+#define CALL_FMT_0 "=&d" (r2) :
+#define CALL_FMT_1 "+&d" (r2) :
+#define CALL_FMT_2 CALL_FMT_1 "d" (r3),
+#define CALL_FMT_3 CALL_FMT_2 "d" (r4),
+#define CALL_FMT_4 CALL_FMT_3 "d" (r5),
+#define CALL_FMT_5 CALL_FMT_4 "d" (r6),
#define CALL_CLOBBER_5 "0", "1", "14", "cc", "memory"
#define CALL_CLOBBER_4 CALL_CLOBBER_5
@@ -286,10 +286,10 @@ static __no_kasan_or_inline unsigned short stap(void)
" stg %[_prev],%[_bc](15)\n" \
" brasl 14,%[_fn]\n" \
" la 15,0(%[_prev])\n" \
- : "+&d" (r2), [_prev] "=&a" (prev) \
- : [_stack] "a" (stack), \
+ : [_prev] "=&a" (prev), CALL_FMT_##nr \
+ [_stack] "a" (stack), \
[_bc] "i" (offsetof(struct stack_frame, back_chain)), \
- [_fn] "X" (fn) CALL_FMT_##nr : CALL_CLOBBER_##nr); \
+ [_fn] "X" (fn) : CALL_CLOBBER_##nr); \
r2; \
})
--
2.16.4
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.