[PATCH] sched/fair: Prevent a division by 0 in scale_rt_capacity()
... since total = sched_avg_period() + delta can yield 0x1, which results in a division by 0, given that div_u64() takes a u32 divisor. Use div64_u64() instead. divide error: [#1] SMP CPU: 7 PID: 0 Comm: swapper/7 Not tainted 4.9.58 #1 Hardware name: ... task: 8800a24e2800 task.stack: c974c000 RIP: 0010:[] [] update_group_capacity+0x16e/0x1c0 RSP: 0018:8800a74e3c18 EFLAGS: 00010246 RAX: 00445ced RBX: 0007 RCX: 024d RDX: RSI: RDI: 000160c0 RBP: 8800a74e3c38 R08: 8800a17d5ac0 R09: 8800a74e R10: R11: R12: 8800a297e400 R13: 8800a17d5ac0 R14: R15: 8800a17d5ac0 FS: () GS:8800a74e() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 006f3580 CR3: 01607000 CR4: 007426e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 PKRU: 5554 Stack: 8800a17d5180 8800a74e3e00 8800a17d5a01 8800a74e3c68 8800a74e3d90 810d37e6 fff8 002300010c40 0040 8800a17d5ad8 Call Trace: [162553.008569] [] find_busiest_group+0xe6/0x950 [] load_balance+0x188/0xa70 [] ? update_rq_clock.part.88+0x13/0x30 [] rebalance_domains+0x210/0x290 [] run_rebalance_domains+0x1b0/0x1d0 [] __do_softirq+0x89/0x2b0 [] irq_exit+0xab/0xb0 [] smp_reschedule_interrupt+0x2e/0x30 [] reschedule_interrupt+0x84/0x90 [162553.008603] [] ? cpuidle_enter_state+0x12f/0x2c0 [] cpuidle_enter+0x12/0x20 [] cpu_startup_entry+0x1a2/0x1f0 [] start_secondary+0x12d/0x140 Code: 0f 00 4c 8b 96 48 09 00 00 48 8b 86 40 09 00 00 48 8b b6 b0 08 00 00 48 d1 ea 4c 29 d6 41 ba 00 00 00 00 49 0f 48 f2 01 d6 31 d2 <48> f7 f6 ba 00 04 00 00 48 29 c2 48 3d ff 03 00 00 b8 01 00 00 RIP [] update_group_capacity+0x16e/0x1c0 RSP Cc: Ingo Molnar Cc: Peter Zijlstra Cc: linux-kernel@vger.kernel.org Signed-off-by: Filippo Sironi --- kernel/sched/fair.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 4037e19bbca2..04b6f847a241 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -7517,7 +7517,7 @@ static unsigned long scale_rt_capacity(int cpu) total = sched_avg_period() + delta; - used = div_u64(avg, total); + used = div64_u64(avg, total); if (likely(used < SCHED_CAPACITY_SCALE)) return SCHED_CAPACITY_SCALE - used; -- 2.7.4
Re: [PATCH v2] mm: terminate shrink_slab loop if signal is pending
Suren Baghdasaryan wrote: > On Fri, Dec 8, 2017 at 6:03 AM, Tetsuo Handa > wrote: > >> > >> This change checks for pending > >> > >> fatal signals inside shrink_slab loop and if one is detected > >> > >> terminates this loop early. > >> > > > >> > > This changelog doesn't really address my previous review feedback, I am > >> > > afraid. You should mention more details about problems you are seeing > >> > > and what causes them. > > The problem I'm facing is that a SIGKILL sent from user space to kill > the least important process is delayed enough for OOM-killer to get a > chance to kill something else, possibly a more important process. Here > "important" is from user's point of view. So the delay in SIGKILL > delivery effectively causes extra kills. Traces indicate that this > delay happens when process being killed is in direct reclaim and > shrinkers (before I fixed them) were the biggest cause for the delay. Sending SIGKILL from userspace is not releasing memory fast enough to prevent the OOM killer from invoking? Yes, under memory pressure, even an attempt to send SIGKILL from userspace could be delayed due to e.g. page fault. Unless it is memcg OOM, you could try OOM notifier callback for checking whether there are SIGKILL pending processes and wait for timeout if any. This situation resembles timeout-based OOM killing discussion, where the OOM killer is enabled again (based on an assumption that the OOM victim got stuck due to OOM lockup) after some timeout from previous OOM-killing. And since we did not merge timeout-based approach, there is no timestamp field for remembering when the SIGKILL was delivered. Therefore, an attempt to wait for timeout would become messy. Regardless of whether you try OOM notifier callback, I think that adding __GFP_KILLABLE and allow bailing out without calling out_of_memory() and warn_alloc() will help terminating killed processes faster. I think that majority of memory allocation requests can give up upon SIGKILL. Important allocation requests which should not give up upon SIGKILL (e.g. committing to filesystem metadata and storage) can be offloaded to kernel threads. > > >> > > If we have a shrinker which takes considerable > >> > > amount of time them we should be addressing that. If that is not > >> > > possible then it should be documented at least. > > I already submitted patches for couple shrinkers. Problem became less > pronounced and less frequent but the retry loop Tetsuo mentioned still > visibly delays the delivery. The worst case I've seen after fixing > shrinkers is 43ms. You meant "delays the termination (of the killed process)" rather than "delays the delivery (of SIGKILL)", didn't you? > > I agree that making waits/loops killable is generally good. But be sure to > > be > > prepared for the worst case. For example, start __GFP_KILLABLE from "best > > effort" > > basis (i.e. no guarantee that the allocating thread will leave the page > > allocator > > slowpath immediately) and check for fatal_signal_pending() only if > > __GFP_KILLABLE is set. That is, > > > > + /* > > +* We are about to die and free our memory. > > +* Stop shrinking which might delay signal handling. > > +*/ > > + if (unlikely((gfp_mask & __GFP_KILLABLE) && > > fatal_signal_pending(current))) > > + break; > > > > at shrink_slab() etc. and > > > > + if ((gfp_mask & __GFP_KILLABLE) && > > fatal_signal_pending(current)) > > + goto nopage; > > > > at __alloc_pages_slowpath(). > > I was thinking about something similar and will experiment to see if > this solves the problem and if it has any side effects. Anyone sees > any obvious problems with this approach? > It is Michal who thinks that "killability for a particular allocation request sounds like a hack" ( http://lkml.kernel.org/r/201606112335.hbg09891.olfjoftvmoq...@i-love.sakura.ne.jp ). I'm willing to give up memory allocations from functions which are called by system calls if SIGKILL is pending. Thus, it should be time to try __GFP_KILLABLE.
Re: [PATCH 0/2 v2] mtd: onenand: samsung: Simplify code and fix leaks in error handling paths
On Sat, 9 Dec 2017 08:24:03 +0100 Christophe JAILLET wrote: > The first patch converts 's3c_onenand_probe()' to devm_ functions. > This fixes a leak in one path (line 872). > This also free_irq which was not handled at all. (I hope I'm correct :) ) > > The 2nd patch is about an un-handled error code which looks spurious. > Not sure if I'm right. > > > While compile-testing it, I had to tweak the code because I don't have any > cross-compiler. Oh come on! It's really not that complicated to install an arm toolchain and cross compile the kernel. > I commented the line "#include " and the compilation > succeeded. So maybe, this include is also useless. Yep, it's not surprising, the driver is really in a poor state. I also noticed that buffers allocated with kmalloc are flagged as __iomem regions, which is obviously wrong. And I fear we'll find plenty of other issues if we dig a bit more. > I've left it as-is, though. Can be fixed in another patch. > > > Theses patches have been compile-tested-only. > > > Christophe JAILLET (2): > mtd: onenand: samsung: use devm_ function to simplify code and fix > some leaks > mtd: onenand: samsung: return an error if > 'mtd_device_parse_register()' fails > > drivers/mtd/onenand/samsung.c | 169 > +- > 1 file changed, 34 insertions(+), 135 deletions(-) >
Re: [PATCH v4 2/5] MIPS: Loongson64: lemote-2f move ec_kb3310b.h to include dir and clean up
Dea Jiaxun, On Sat, Dec 9, 2017 at 7:49 AM, Jiaxun Yang wrote: > To operate EC from platform driver, this head file need able to be include > from anywhere. This patch just move ec_kb3310b.h to include dir and > clean up ec_kb3310b.h. > > Signed-off-by: Jiaxun Yang > --- > arch/mips/include/asm/mach-loongson64/ec_kb3310b.h | 170 +++ > arch/mips/loongson64/lemote-2f/ec_kb3310b.c| 2 +- > arch/mips/loongson64/lemote-2f/ec_kb3310b.h| 188 > - > arch/mips/loongson64/lemote-2f/pm.c| 4 +- > arch/mips/loongson64/lemote-2f/reset.c | 4 +- > 5 files changed, 175 insertions(+), 193 deletions(-) > create mode 100644 arch/mips/include/asm/mach-loongson64/ec_kb3310b.h > delete mode 100644 arch/mips/loongson64/lemote-2f/ec_kb3310b.h > > diff --git a/arch/mips/include/asm/mach-loongson64/ec_kb3310b.h > b/arch/mips/include/asm/mach-loongson64/ec_kb3310b.h > new file mode 100644 > index ..2e8690532ea5 > --- /dev/null > +++ b/arch/mips/include/asm/mach-loongson64/ec_kb3310b.h > @@ -0,0 +1,170 @@ > +/* > + * KB3310B Embedded Controller > + * > + * Copyright (C) 2008 Lemote Inc. > + * Author: liujl , 2008-03-14 > + * Copyright (C) 2009 Lemote Inc. > + * Author: Wu Zhangjin > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; either version 2 of the License, or > + * (at your option) any later version. > + */ Have you considered using the new SPDX ids instead of this fine but long license boilerplate? That would be very gentle of you if you did! You can check Thomas documentation patches, as well as Linus comments on the topic. -- Cordially Philippe Ombredanne
Re: [PATCH 1/2 v2] mtd: onenand: samsung: use devm_ function to simplify code and fix some leaks
On Sat, 9 Dec 2017 08:24:04 +0100
Christophe JAILLET wrote:
> Convert all error handling code in 's3c_onenand_probe()' to
> resource-managed alternatives in order to simplify code.
>
> This fixes a resource leak if 'platform_get_resource()' fails at line 872.
>
> The 'request_irq()' at line 971 was also un-balanced. It is now
> resource-managed.
>
> Signed-off-by: Christophe JAILLET
> ---
> Compile tested-only
>
> v2: use devm_ioremap_resource()
> ---
> drivers/mtd/onenand/samsung.c | 164
> --
> 1 file changed, 29 insertions(+), 135 deletions(-)
>
> diff --git a/drivers/mtd/onenand/samsung.c b/drivers/mtd/onenand/samsung.c
> index af0ac1a7bf8f..2e562c224060 100644
> --- a/drivers/mtd/onenand/samsung.c
> +++ b/drivers/mtd/onenand/samsung.c
> @@ -129,16 +129,13 @@ struct s3c_onenand {
> struct platform_device *pdev;
> enum soc_type type;
> void __iomem*base;
> - struct resource *base_res;
> void __iomem*ahb_addr;
> - struct resource *ahb_res;
> int bootram_command;
> void __iomem*page_buf;
> void __iomem*oob_buf;
> unsigned int(*mem_addr)(int fba, int fpa, int fsa);
> unsigned int(*cmd_map)(unsigned int type, unsigned int val);
> void __iomem*dma_addr;
> - struct resource *dma_res;
> unsigned long phys_base;
> struct completion complete;
> };
> @@ -851,15 +848,13 @@ static int s3c_onenand_probe(struct platform_device
> *pdev)
> /* No need to check pdata. the platform data is optional */
>
> size = sizeof(struct mtd_info) + sizeof(struct onenand_chip);
> - mtd = kzalloc(size, GFP_KERNEL);
> + mtd = devm_kzalloc(&pdev->dev, size, GFP_KERNEL);
> if (!mtd)
> return -ENOMEM;
>
> - onenand = kzalloc(sizeof(struct s3c_onenand), GFP_KERNEL);
> - if (!onenand) {
> - err = -ENOMEM;
> - goto onenand_fail;
> - }
> + onenand = devm_kzalloc(&pdev->dev, sizeof(struct s3c_onenand),
> GFP_KERNEL);
> + if (!onenand)
> + return -ENOMEM;
>
> this = (struct onenand_chip *) &mtd[1];
> mtd->priv = this;
> @@ -870,26 +865,10 @@ static int s3c_onenand_probe(struct platform_device
> *pdev)
> s3c_onenand_setup(mtd);
>
> r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - if (!r) {
> - dev_err(&pdev->dev, "no memory resource defined\n");
> - return -ENOENT;
> - goto ahb_resource_failed;
> - }
> + onenand->base = devm_ioremap_resource(&pdev->dev, r);
> + if (IS_ERR(onenand->base))
> + return PTR_ERR(onenand->base);
>
> - onenand->base_res = request_mem_region(r->start, resource_size(r),
> -pdev->name);
> - if (!onenand->base_res) {
> - dev_err(&pdev->dev, "failed to request memory resource\n");
> - err = -EBUSY;
> - goto resource_failed;
> - }
> -
> - onenand->base = ioremap(r->start, resource_size(r));
> - if (!onenand->base) {
> - dev_err(&pdev->dev, "failed to map memory resource\n");
> - err = -EFAULT;
> - goto ioremap_failed;
> - }
> /* Set onenand_chip also */
> this->base = onenand->base;
>
> @@ -898,40 +877,20 @@ static int s3c_onenand_probe(struct platform_device
> *pdev)
>
> if (onenand->type != TYPE_S5PC110) {
> r = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> - if (!r) {
> - dev_err(&pdev->dev, "no buffer memory resource
> defined\n");
> - err = -ENOENT;
> - goto ahb_resource_failed;
> - }
> -
> - onenand->ahb_res = request_mem_region(r->start,
> resource_size(r),
> - pdev->name);
> - if (!onenand->ahb_res) {
> - dev_err(&pdev->dev, "failed to request buffer memory
> resource\n");
> - err = -EBUSY;
> - goto ahb_resource_failed;
> - }
> -
> - onenand->ahb_addr = ioremap(r->start, resource_size(r));
> - if (!onenand->ahb_addr) {
> - dev_err(&pdev->dev, "failed to map buffer memory
> resource\n");
> - err = -EINVAL;
> - goto ahb_ioremap_failed;
> - }
> + onenand->ahb_addr = devm_ioremap_resource(&pdev->dev, r);
> + if (IS_ERR(onenand->ahb_addr))
> + return PTR_ERR(onenand->ahb_addr);
>
> /* Allocate 4KiB BufferRAM */
> - onenand->page_buf = kzalloc(SZ_4K, GFP_KERNEL);
> - if (!onenand->page_buf) {
> - err = -ENOMEM;
> - goto page_buf_fail;
> - }
> + onenand->page_buf = devm_kzalloc(&pdev->dev, SZ_4K
[PATCH 0/7] Add USB remote wakeup driver
These patches introduce the SSUSB and SPM glue layer driver which is used to support usb remote wakeup. Usually the glue layer is put into a system controller, such as PERICFG module. The old way to support usb wakeup is put into SSUSB controller drivers, including xhci-mtk driver and mtu3 driver, but there are some problems: 1. can't disdinguish the relation between glue layer and SSUSB IP when SoCs supports multi SSUSB IPs; 2. duplicated code for wakeup are put into both xhci-mtk and mtu3 drivers; 3. the glue layer may vary on different SoCs with SSUSB IP, and will make SSUSB controller drivers complicated; In order to resolve these problems, it's useful to make the glue layer transparent by extracting a seperated driver, meanwhile to reduce the duplicated code and simplify SSUSB controller drivers. Changes from v1: * Introduce USB remote wakeup driver * Use the new way to support remote wakeup for SSUSB controller drivers * Add binding document for USB remote wakeup driver * Update binding documents of SSUSB controller drivers * Update DTS of MT8173 platform Chunfeng Yun (7): soc: mediatek: Add USB wakeup driver dt-bindings: soc: mediatek: add bindings document for USB wakeup usb: xhci-mtk: use APIs of mtu_wakeup to support remote wakeup usb: mtu3: use APIs of mtu_wakeup to support remote wakeup dt-bindings: usb: mtk-xhci: add USB wakeup properties dt-bindings: usb: mtu3: add USB wakeup properties arm64: dts: mt8173: add uwk node and remove unused usb property .../bindings/soc/mediatek/usb-wakeup.txt | 77 +++ .../devicetree/bindings/usb/mediatek,mtk-xhci.txt | 15 +- .../devicetree/bindings/usb/mediatek,mtu3.txt | 14 +- arch/arm64/boot/dts/mediatek/mt8173-evb.dts| 28 +- arch/arm64/boot/dts/mediatek/mt8173.dtsi | 16 +- drivers/soc/mediatek/Kconfig | 8 + drivers/soc/mediatek/Makefile | 1 + drivers/soc/mediatek/mtk-usb-wakeup.c | 519 + drivers/usb/host/xhci-mtk.c| 39 +- drivers/usb/host/xhci-mtk.h| 2 + drivers/usb/mtu3/mtu3.h| 2 + drivers/usb/mtu3/mtu3_host.c | 39 +- include/dt-bindings/soc/mediatek,usb-wakeup.h | 15 + include/linux/soc/mediatek/usb-wakeup.h| 88 14 files changed, 803 insertions(+), 60 deletions(-) create mode 100644 Documentation/devicetree/bindings/soc/mediatek/usb-wakeup.txt create mode 100644 drivers/soc/mediatek/mtk-usb-wakeup.c create mode 100644 include/dt-bindings/soc/mediatek,usb-wakeup.h create mode 100644 include/linux/soc/mediatek/usb-wakeup.h -- 1.9.1
[PATCH 6/7] dt-bindings: usb: mtu3: add USB wakeup properties
Modify the properties of usb wakeup, and use the new way of mtu_wakeup which is extracted from SSUSB controller dirver as a new driver. Signed-off-by: Chunfeng Yun --- Documentation/devicetree/bindings/usb/mediatek,mtu3.txt | 14 +++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt b/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt index b2271d8..2ed546d 100644 --- a/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt +++ b/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt @@ -42,9 +42,17 @@ Optional properties: - enable-manual-drd : supports manual dual-role switch via debugfs; usually used when receptacle is TYPE-A and also wants to support dual-role mode. - - mediatek,enable-wakeup : supports ip sleep wakeup used by host mode - - mediatek,syscon-wakeup : phandle to syscon used to access USB wakeup - control register, it depends on "mediatek,enable-wakeup". + - mediatek,uwks : a phandle to USB-Wakeup node to control the type of wakeup, + it's used to replace the old way which is realized by the property of + "mediatek,wakeup-wakeup" and "mediatek,syscon-wakeup", + see: Documentation/devicetree/bindings/soc/mediatek/usb-wakeup.txt + - wakeup-source : Decides if the new way of USB wakeup is supported or + not, it depends on "mediatek,uwks" property. + - mediatek,enable-wakeup : (deprecated) supports ip sleep wakeup used by + host mode, only supports mt8173 platform, use the property of + "mediatek,uwks" instead on other SoCs. + - mediatek,syscon-wakeup : (deprecated) phandle to syscon used to access + USB wakeup control register, it depends on "mediatek,enable-wakeup". - mediatek,u3p-dis-msk : mask to disable u3ports, bit0 for u3port0, bit1 for u3port1, ... etc; -- 1.9.1
[PATCH 7/7] arm64: dts: mt8173: add uwk node and remove unused usb property
Add uwk node for new way of usb remote wakeup instead of old one,
and modify some usb properties according binding documents
of mediatek,mtu3.txt and mediatek,mtk-xhci.txt
Signed-off-by: Chunfeng Yun
---
arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 28 ++--
arch/arm64/boot/dts/mediatek/mt8173.dtsi| 16 +---
2 files changed, 23 insertions(+), 21 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
index 1c3634f..08a323b 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
@@ -14,6 +14,7 @@
/dts-v1/;
#include
+#include
#include "mt8173.dtsi"
/ {
@@ -68,6 +69,20 @@
gpio = <&pio 9 GPIO_ACTIVE_HIGH>;
enable-active-high;
};
+
+ usb_wakeup: uwk@0 {
+ compatible = "mediatek,mt8173-uwk","mediatek,usb-wk-v1";
+ mediatek,wkc = <&pericfg>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ status = "okay";
+
+ usb_wk0: uwk@400 {
+ reg = <0x400 0x8>;
+ #mediatek,uwk-cells = <1>;
+ status = "okay";
+ };
+ };
};
&cec {
@@ -268,12 +283,6 @@
};
};
- usb_id_pins_ground: usb_iddig_pull_down {
- pins_iddig {
- pinmux = ;
- bias-pull-down;
- };
- };
};
&pwm0 {
@@ -501,15 +510,14 @@
};
&ssusb {
+ mediatek,uwks = <&usb_wk0 MTU_WK_IP_SLEEP>;
vusb33-supply = <&mt6397_vusb_reg>;
vbus-supply = <&usb_p0_vbus>;
extcon = <&extcon_usb>;
dr_mode = "otg";
- mediatek,enable-wakeup;
- pinctrl-names = "default", "id_float", "id_ground";
+ wakeup-source;
+ pinctrl-names = "default";
pinctrl-0 = <&usb_id_pins_float>;
- pinctrl-1 = <&usb_id_pins_float>;
- pinctrl-2 = <&usb_id_pins_ground>;
status = "okay";
};
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 26396ef..818ead7 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -722,7 +722,7 @@
};
ssusb: usb@11271000 {
- compatible = "mediatek,mt8173-mtu3";
+ compatible = "mediatek,mt8173-mtu3", "mediatek,mtu3";
reg = <0 0x11271000 0 0x3000>,
<0 0x11280700 0 0x0100>;
reg-names = "mac", "ippc";
@@ -731,22 +731,16 @@
<&u3port0 PHY_TYPE_USB3>,
<&u2port1 PHY_TYPE_USB2>;
power-domains = <&scpsys MT8173_POWER_DOMAIN_USB>;
- clocks = <&topckgen CLK_TOP_USB30_SEL>,
-<&clk26m>,
-<&pericfg CLK_PERI_USB0>,
-<&pericfg CLK_PERI_USB1>;
- clock-names = "sys_ck",
- "ref_ck",
- "wakeup_deb_p0",
- "wakeup_deb_p1";
- mediatek,syscon-wakeup = <&pericfg>;
+ clocks = <&topckgen CLK_TOP_USB30_SEL>, <&clk26m>;
+ clock-names = "sys_ck", "ref_ck";
#address-cells = <2>;
#size-cells = <2>;
ranges;
status = "disabled";
usb_host: xhci@1127 {
- compatible = "mediatek,mt8173-xhci";
+ compatible = "mediatek,mt8173-xhci",
+"mediatek,mtk-xhci";
reg = <0 0x1127 0 0x1000>;
reg-names = "mac";
interrupts = ;
--
1.9.1
[PATCH 1/7] soc: mediatek: Add USB wakeup driver
This driver is used to support usb wakeup which is controlled by
the glue layer between SSUSB and SPM. Usually the glue layer is put
into a system controller, such as pericfg module, which is
represented by a syscon node in DTS.
Due to the glue layer may vary on different SoCs, it's useful to
extract a separated driver to simplify usb controller drivers.
Signed-off-by: Chunfeng Yun
---
drivers/soc/mediatek/Kconfig | 8 +
drivers/soc/mediatek/Makefile | 1 +
drivers/soc/mediatek/mtk-usb-wakeup.c | 519 ++
include/dt-bindings/soc/mediatek,usb-wakeup.h | 15 +
include/linux/soc/mediatek/usb-wakeup.h | 88 +
5 files changed, 631 insertions(+)
create mode 100644 drivers/soc/mediatek/mtk-usb-wakeup.c
create mode 100644 include/dt-bindings/soc/mediatek,usb-wakeup.h
create mode 100644 include/linux/soc/mediatek/usb-wakeup.h
diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
index a7d0667..30cd226 100644
--- a/drivers/soc/mediatek/Kconfig
+++ b/drivers/soc/mediatek/Kconfig
@@ -31,4 +31,12 @@ config MTK_SCPSYS
Say yes here to add support for the MediaTek SCPSYS power domain
driver.
+config MTK_UWK
+ bool "MediaTek USB Wakeup Support"
+ select REGMAP
+ help
+ Say yes here to add support for the MediaTek SSUSB-SPM glue layer
+ which supports some different type of USB wakeup, such as IP-SLEEP,
+ LINESTATE, IDDIG etc, and it can support multi SSUSB controllers.
+
endmenu
diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
index 12998b0..66fbb54f 100644
--- a/drivers/soc/mediatek/Makefile
+++ b/drivers/soc/mediatek/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o
obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o
obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o
+obj-$(CONFIG_MTK_UWK) += mtk-usb-wakeup.o
diff --git a/drivers/soc/mediatek/mtk-usb-wakeup.c
b/drivers/soc/mediatek/mtk-usb-wakeup.c
new file mode 100644
index 000..16539a6
--- /dev/null
+++ b/drivers/soc/mediatek/mtk-usb-wakeup.c
@@ -0,0 +1,519 @@
+/*
+ * Copyright (c) 2017 MediaTek Inc.
+ * Author: Chunfeng Yun
+ *
+ * SPDX-License-Identifier: GPL-2.0
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* mt8173, mt8176 etc */
+#define PERI_WK_CTRL1 0x4
+#define WC1_IS_C(x)(((x) & 0xf) << 26) /* cycle debounce */
+#define WC1_IS_EN BIT(25)
+#define WC1_IS_P BIT(6) /* polarity for ip sleep */
+
+/* mt2712 etc */
+#define PERI_SSUSB_SPM_CTRL0x0
+#define SSC_LINE_STATE_CHG GENMASK(11, 8)
+#define SSC_LINE_STATE_EN GENMASK(6, 5)
+#define SSC_IP_SLEEP_ENBIT(4)
+#define SSC_SPM_INT_EN BIT(1)
+
+enum mtk_uwk_vers {
+ MTK_UWK_V1 = 1,
+ MTK_UWK_V2,
+};
+
+struct mtk_uwk_pdata {
+ enum mtk_uwk_vers vers;
+};
+
+/**
+ * @reg_base: register offset within a syscon @wkc (e.g. pericfg module)
+ * @type: the types of wakeup, such as IP-SLEEP, LINE-STATE etc
+ */
+struct mtk_uwk_instance {
+ struct mtu_wakeup uwk;
+ u32 reg_base;
+ u32 reg_len;
+ u32 type;
+};
+
+struct mtk_uwk {
+ struct device *dev;
+ struct regmap *wkc;
+ const struct mtk_uwk_pdata *data;
+ struct mtk_uwk_instance **inst;
+ int num_inst;
+};
+
+static LIST_HEAD(of_uwk_providers);
+static DEFINE_MUTEX(of_uwk_mutex);
+
+static struct mtu_wakeup_provider *of_uwk_provider_add(struct device *dev,
+ struct mtu_wakeup *(*of_xlate)(struct device *dev,
+ struct of_phandle_args *args))
+{
+ struct mtu_wakeup_provider *provider;
+
+ provider = kzalloc(sizeof(*provider), GFP_KERNEL);
+ if (!provider)
+ return ERR_PTR(-ENOMEM);
+
+ provider->dev = dev;
+ provider->of_node = of_node_get(dev->of_node);
+ provider->of_xlate = of_xlate;
+
+ mutex_lock(&of_uwk_mutex);
+ list_add_tail(&provider->list, &of_uwk_providers);
+ mutex_unlock(&of_uwk_mutex);
+
+ return provider;
+}
+
+static void of_uwk_provider_del(struct device_node *np)
+{
+ struct mtu_wakeup_provider *provider;
+
+ mutex_lock(&of_uwk_mutex);
+ list_for_each_entry(provider, &of_uwk_providers, list) {
+ if (provider->of_node == np) {
+ list_del(&provider->list);
+ of_node_put(provider->of_node);
+ kfree(provider);
+ break;
+ }
+ }
+ mutex_unlock(&of_uwk_mutex);
+}
+
+static struct mtu_wakeup *of_uwk_get_from_provider(
+ struct of_phandle_args *args)
+{
+ struct mtu_wakeup_provider *provider;
+ struct device_node *child_np;
+ struct mtu_wakeup *uwk;
+
+ mutex_lock(&of_uwk_mutex);
+ list_for_each_entry(provider, &of_uwk_providers, list) {
+ for_each_child_of_node(provider->of_no
[PATCH 5/7] dt-bindings: usb: mtk-xhci: add USB wakeup properties
Modify the properties of usb wakeup, and use the new way of mtu_wakeup which is extracted from SSUSB controller dirver as a new one. Signed-off-by: Chunfeng Yun --- .../devicetree/bindings/usb/mediatek,mtk-xhci.txt | 15 +++ 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt index 3059596..88984d8 100644 --- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt +++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt @@ -35,10 +35,17 @@ Required properties: - phys : a list of phandle + phy specifier pairs Optional properties: - - mediatek,wakeup-src : 1: ip sleep wakeup mode; 2: line state wakeup - mode; - - mediatek,syscon-wakeup : phandle to syscon used to access USB wakeup - control register, it depends on "mediatek,wakeup-src". + - mediatek,uwks : a phandle to USB-Wakeup node to control the type of + wakeup, it's used to replace the old way which is realized by the + property of "mediatek,wakeup-src" and "mediatek,syscon-wakeup", + see: Documentation/devicetree/bindings/soc/mediatek/usb-wakeup.txt + - wakeup-source : Decides if the new way of USB wakeup is supported or + not, it depends on "mediatek,uwks" property. + - mediatek,wakeup-src : (deprecated) 1: ip sleep wakeup mode; 2: line + state wakeup mode; only supports mt8173 platform, use the property + of "mediatek,uwks" instead on other SoCs. + - mediatek,syscon-wakeup : (deprecated) phandle to syscon used to access + USB wakeup control register, depends on "mediatek,wakeup-src". - mediatek,u3p-dis-msk : mask to disable u3ports, bit0 for u3port0, bit1 for u3port1, ... etc; - vbus-supply : reference to the VBUS regulator; -- 1.9.1
[PATCH 2/7] dt-bindings: soc: mediatek: add bindings document for USB wakeup
This adds bindings document for the SSUSB-SPM glue layer driver found
in MediaTek SoCs which is used to support usb remote wakeup.
Signed-off-by: Chunfeng Yun
---
.../bindings/soc/mediatek/usb-wakeup.txt | 77 ++
1 file changed, 77 insertions(+)
create mode 100644
Documentation/devicetree/bindings/soc/mediatek/usb-wakeup.txt
diff --git a/Documentation/devicetree/bindings/soc/mediatek/usb-wakeup.txt
b/Documentation/devicetree/bindings/soc/mediatek/usb-wakeup.txt
new file mode 100644
index 000..313d927
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/mediatek/usb-wakeup.txt
@@ -0,0 +1,77 @@
+MediaTek USB Wakeup binding
+-
+
+The SSUSB-SPM glue layer is used to control some signals of USB
+wakeup, such as IP-SLEEP, LINE-STATE, IDDIG etc, which are mutually
+exclusive.
+
+Required properties (controller (parent) node):
+- compatible: Should be one of:
+ - "mediatek,-uwk","mediatek,usb-wk-v1"
+ soc-model is the name of SoC, supports one of:
+ - mt8173, mt8176
+ - "mediatek,-uwk","mediatek,usb-wk-v2"
+ soc-model is the name of SoC, supports one of:
+ - mt2712
+
+- mediatek,wkc: must contain a syscon phandle, such as pericfg controller
+- #address-cells : should be '1'
+- #size-cells : should be '1'
+
+Required nodes: a sub-node is required for each glue layer provided for
+ each SSUSB IP. Address range information including the usual 'reg'
+ property is used inside these nodes to describe the controller's
+ topology.
+
+Required properties (glue layer (child) node):
+- reg: address and length of the register set within the syscon which is
+ assigned to @mediatek,wkc.
+- #mediatek,uwk-cells: should be 1 (see the second example), cell after
+ glue layer phandle is wakeup type from:
+ - MTU_WK_IP_SLEEP
+ - MTU_WK_LINE_STATE
+ The wakeup types defined in
+ - include/dt-bindings/soc/mediatek,usb-wakeup.h
+
+
+Example:
+
+usb_wakeup: uwk@0 {
+ compatible = "mediatek,mt2712-uwk","mediatek,usb-wk-v2";
+ mediatek,wkc = <&pericfg>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ status = "okay";
+
+ usb_wk0: uwk@510 {
+ reg = <0x510 0x4>;
+ #mediatek,uwk-cells = <1>;
+ status = "okay";
+ };
+
+ usb_wk1: uwk@514 {
+ reg = <0x514 0x4>;
+ #mediatek,uwk-cells = <1>;
+ status = "okay";
+ };
+};
+
+
+Specifying wakeup control of devices
+-
+
+Device nodes should specify the configuration required in their
+"mediatek,uwks" property, containing a phandle to the glue layer
+node and a wakeup type, because each USB controller has just one
+glue layer for wakeup, so only one phandle is supported;
+
+Example:
+
+#include
+
+usb_host1: xhci@112c {
+ ...
+ mediatek,uwks = <&usb_wk2 MTU_WK_IP_SLEEP>;
+ ...
+};
+
--
1.9.1
[PATCH 3/7] usb: xhci-mtk: use APIs of mtu_wakeup to support remote wakeup
On some platforms, there are two xHCI IPs, but the old way of
usb wakeup doesn't support it, so use the new APIs of mtu_wakeup
to support it.
Signed-off-by: Chunfeng Yun
---
drivers/usb/host/xhci-mtk.c | 39 +++
drivers/usb/host/xhci-mtk.h | 2 ++
2 files changed, 25 insertions(+), 16 deletions(-)
diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index b62a1d2..3176a10 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include "xhci.h"
#include "xhci-mtk.h"
@@ -366,7 +367,9 @@ static void usb_wakeup_line_state_dis(struct xhci_hcd_mtk
*mtk)
static void usb_wakeup_enable(struct xhci_hcd_mtk *mtk)
{
- if (mtk->wakeup_src == SSUSB_WK_IP_SLEEP)
+ if (mtk->wakeup)
+ mtu_wakeup_enable(mtk->uwk);
+ else if (mtk->wakeup_src == SSUSB_WK_IP_SLEEP)
usb_wakeup_ip_sleep_en(mtk);
else if (mtk->wakeup_src == SSUSB_WK_LINE_STATE)
usb_wakeup_line_state_en(mtk);
@@ -374,7 +377,9 @@ static void usb_wakeup_enable(struct xhci_hcd_mtk *mtk)
static void usb_wakeup_disable(struct xhci_hcd_mtk *mtk)
{
- if (mtk->wakeup_src == SSUSB_WK_IP_SLEEP)
+ if (mtk->wakeup)
+ mtu_wakeup_disable(mtk->uwk);
+ else if (mtk->wakeup_src == SSUSB_WK_IP_SLEEP)
usb_wakeup_ip_sleep_dis(mtk);
else if (mtk->wakeup_src == SSUSB_WK_LINE_STATE)
usb_wakeup_line_state_dis(mtk);
@@ -383,24 +388,26 @@ static void usb_wakeup_disable(struct xhci_hcd_mtk *mtk)
static int usb_wakeup_of_property_parse(struct xhci_hcd_mtk *mtk,
struct device_node *dn)
{
- struct device *dev = mtk->dev;
+ /* try the new way first */
+ mtk->wakeup = of_property_read_bool(dn, "wakeup-source");
+ if (mtk->wakeup) {
+ mtk->uwk = devm_of_uwk_get_by_index(mtk->dev, dn, 0);
+ if (IS_ERR(mtk->uwk))
+ dev_err(mtk->dev, "fail to get uwk\n");
+
+ return PTR_ERR_OR_ZERO(mtk->uwk);
+ }
- /*
- * wakeup function is optional, so it is not an error if this property
- * does not exist, and in such case, no need to get relative
- * properties anymore.
- */
+ /* wakeup function is optional (deprecated, use the new way instead) */
of_property_read_u32(dn, "mediatek,wakeup-src", &mtk->wakeup_src);
- if (!mtk->wakeup_src)
- return 0;
-
- mtk->pericfg = syscon_regmap_lookup_by_phandle(dn,
+ if (mtk->wakeup_src) {
+ mtk->pericfg = syscon_regmap_lookup_by_phandle(dn,
"mediatek,syscon-wakeup");
- if (IS_ERR(mtk->pericfg)) {
- dev_err(dev, "fail to get pericfg regs\n");
- return PTR_ERR(mtk->pericfg);
+ if (IS_ERR(mtk->pericfg)) {
+ dev_err(mtk->dev, "fail to get pericfg regs\n");
+ return PTR_ERR(mtk->pericfg);
+ }
}
-
return 0;
}
diff --git a/drivers/usb/host/xhci-mtk.h b/drivers/usb/host/xhci-mtk.h
index 6b74ce5..95bd6ca 100644
--- a/drivers/usb/host/xhci-mtk.h
+++ b/drivers/usb/host/xhci-mtk.h
@@ -124,6 +124,8 @@ struct xhci_hcd_mtk {
int num_phys;
int wakeup_src;
bool lpm_support;
+ struct mtu_wakeup *uwk;
+ bool wakeup;
};
static inline struct xhci_hcd_mtk *hcd_to_mtk(struct usb_hcd *hcd)
--
1.9.1
[PATCH 4/7] usb: mtu3: use APIs of mtu_wakeup to support remote wakeup
On some platforms, there are two SSUSB IPs, but the old way of
usb wakeup doesn't support it, so use the new APIs of mtu_wakeup
to support it.
Signed-off-by: Chunfeng Yun
---
drivers/usb/mtu3/mtu3.h | 2 ++
drivers/usb/mtu3/mtu3_host.c | 39 +++
2 files changed, 25 insertions(+), 16 deletions(-)
diff --git a/drivers/usb/mtu3/mtu3.h b/drivers/usb/mtu3/mtu3.h
index 3c888d9..9f3eb79 100644
--- a/drivers/usb/mtu3/mtu3.h
+++ b/drivers/usb/mtu3/mtu3.h
@@ -255,6 +255,8 @@ struct ssusb_mtk {
/* usb wakeup for host mode */
bool wakeup_en;
struct regmap *pericfg;
+ struct mtu_wakeup *uwk;
+ bool new_wakeup;
};
/**
diff --git a/drivers/usb/mtu3/mtu3_host.c b/drivers/usb/mtu3/mtu3_host.c
index 7e948c0..f769b65 100644
--- a/drivers/usb/mtu3/mtu3_host.c
+++ b/drivers/usb/mtu3/mtu3_host.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include "mtu3.h"
#include "mtu3_dr.h"
@@ -56,24 +57,26 @@ static void ssusb_wakeup_ip_sleep_dis(struct ssusb_mtk
*ssusb)
int ssusb_wakeup_of_property_parse(struct ssusb_mtk *ssusb,
struct device_node *dn)
{
- struct device *dev = ssusb->dev;
+ /* try the new way first */
+ ssusb->new_wakeup = of_property_read_bool(dn, "wakeup-source");
+ if (ssusb->new_wakeup) {
+ ssusb->uwk = devm_of_uwk_get_by_index(ssusb->dev, dn, 0);
+ if (IS_ERR(ssusb->uwk))
+ dev_err(ssusb->dev, "fail to get mtu_wakeup\n");
+
+ return PTR_ERR_OR_ZERO(ssusb->uwk);
+ }
- /*
-* Wakeup function is optional, so it is not an error if this property
-* does not exist, and in such case, no need to get relative
-* properties anymore.
-*/
+ /* Wakeup function is optional. (deprecated, use the new way instead) */
ssusb->wakeup_en = of_property_read_bool(dn, "mediatek,enable-wakeup");
- if (!ssusb->wakeup_en)
- return 0;
-
- ssusb->pericfg = syscon_regmap_lookup_by_phandle(dn,
+ if (ssusb->wakeup_en) {
+ ssusb->pericfg = syscon_regmap_lookup_by_phandle(dn,
"mediatek,syscon-wakeup");
- if (IS_ERR(ssusb->pericfg)) {
- dev_err(dev, "fail to get pericfg regs\n");
- return PTR_ERR(ssusb->pericfg);
+ if (IS_ERR(ssusb->pericfg)) {
+ dev_err(ssusb->dev, "fail to get pericfg regs\n");
+ return PTR_ERR(ssusb->pericfg);
+ }
}
-
return 0;
}
@@ -235,7 +238,9 @@ void ssusb_host_exit(struct ssusb_mtk *ssusb)
int ssusb_wakeup_enable(struct ssusb_mtk *ssusb)
{
- if (ssusb->wakeup_en)
+ if (ssusb->new_wakeup)
+ mtu_wakeup_enable(ssusb->uwk);
+ else if (ssusb->wakeup_en)
ssusb_wakeup_ip_sleep_en(ssusb);
return 0;
@@ -243,6 +248,8 @@ int ssusb_wakeup_enable(struct ssusb_mtk *ssusb)
void ssusb_wakeup_disable(struct ssusb_mtk *ssusb)
{
- if (ssusb->wakeup_en)
+ if (ssusb->new_wakeup)
+ mtu_wakeup_disable(ssusb->uwk);
+ else if (ssusb->wakeup_en)
ssusb_wakeup_ip_sleep_dis(ssusb);
}
--
1.9.1
Re: [PATCH 0/2] of: overlay: Crash fix and improvement
Hi Frank,
On Sat, Dec 9, 2017 at 7:01 AM, Frank Rowand wrote:
> On 12/08/17 05:13, Geert Uytterhoeven wrote:
>> This patch series fixes memory corruption when applying overlays.
>> I first noticed this when using OF configfs. After lots of failed
>> debugging attempts, I bisected it to "of: overlay: add per overlay sysfs
>> attributes", which is not upstream. But that was a red herring: that
>> commit enlarged struct fragment to exactly 64-bytes, which just made it
>> more likely to cause random corruption when writing beyond the end of an
>> array of fragment structures. With the smaller structure size before,
>> such writes usually ended up in the unused holes between allocated
>> blocks, causing no harm.
>>
>> The first patch is the real fix, and applies to both v4.15-rc2 and Rob's
>> for-next branch.
>> The second patch is a small improvement, and applies to Rob's for-next
>> branch only.
>
> Overlay FDT files should not have invalid contents. But they inevitably
> will, so the code has to handle those cases. Thanks for finding this
> problem and making the code better!
Sure, people can throw anything at it ;-)
In my case, I'm wondering if the dtbo was actually invalid?
Simplification of the decompiled dtbo:
/dts-v1/;
/ {
fragment-name {
target-path = [2f 00];
__overlay__ {
node-name {
compatible = "foo,bar";
gpios = <0x 0x0 0x0>;
};
};
};
__fixups__ {
bank0 = "/fragment-name/__overlay__/node-name:gpios:0";
};
};
So it has __fixup__, but no __symbols__, which looks totally valid to me.
> For the full series:
>
> Reviewed-by: Frank Rowand
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2] thinkpad_acpi: Support the battery wear control
Hi! In newer series (I can't find it at the moment, sorry) you return "NOT_CHARGING" status when not charging because of wear control. Maybe we should have separate status "not charging due to wear control"? 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: RFC(v2): Audit Kernel Container IDs
On 12/10/2017 18:33, Casey Schaufler wrote: > On 10/12/2017 7:14 AM, Richard Guy Briggs wrote: >> Containers are a userspace concept. The kernel knows nothing of them. >> >> The Linux audit system needs a way to be able to track the container >> provenance of events and actions. Audit needs the kernel's help to do >> this. >> >> Since the concept of a container is entirely a userspace concept, a >> registration from the userspace container orchestration system initiates >> this. This will define a point in time and a set of resources >> associated with a particular container with an audit container ID. >> >> The registration is a pseudo filesystem (proc, since PID tree already >> exists) write of a u8[16] UUID representing the container ID to a file >> representing a process that will become the first process in a new >> container. This write might place restrictions on mount namespaces >> required to define a container, or at least careful checking of >> namespaces in the kernel to verify permissions of the orchestrator so it >> can't change its own container ID. A bind mount of nsfs may be >> necessary in the container orchestrator's mntNS. >> Note: Use a 128-bit scalar rather than a string to make compares faster >> and simpler. >> >> Require a new CAP_CONTAINER_ADMIN to be able to carry out the >> registration. > > Hang on. If containers are a user space concept, how can > you want CAP_CONTAINER_ANYTHING? If there's not such thing as > a container, how can you be asking for a capability to manage > them? > >> At that time, record the target container's user-supplied >> container identifier along with the target container's first process >> (which may become the target container's "init" process) process ID >> (referenced from the initial PID namespace), all namespace IDs (in the >> form of a nsfs device number and inode number tuple) in a new auxilliary >> record AUDIT_CONTAINER with a qualifying op=$action field. Here is an idea to avoid privilege problems or the need for a new capability: make it automatic. What makes a container a container seems to be the use of at least a namespace. What about automatically create and assign an ID to a process when it enters a namespace different than one of its parent process? This delegates the (permission) responsibility to the use of namespaces (e.g. /proc/sys/user/max_* limit). One interesting side effect of this approach would be to be able to identify which processes are in the same set of namespaces, even if not spawn from the container but entered after its creation (i.e. using setns), by creating container IDs as a (deterministic) checksum from the /proc/self/ns/* IDs. Since the concern is to identify a container, I think the ability to audit the switch from one container ID to another is enough. I don't think we need nested IDs. As a side note, you may want to take a look at the Linux-VServer's XID. Regards, Mickaël signature.asc Description: OpenPGP digital signature
Re: [PATCH v2] thinkpad_acpi: Support the battery wear control
On 09/12/2017, Pavel Machek wrote: > In newer series (I can't find it at the moment, sorry) The new series is a 3-patch patchset that obsoletes this patch. It is in the testing stage and will be pushed to the mailing lists and maintainers in a few days. > Maybe we should have separate status "not charging due to wear > control"? No, because the ACPI battery driver is a extension to the generic power supply driver, that does not understand the battery wear control. Also, Rafael specifically noted NOT to include any thinkpad_acpi-specific behavior to the generic drivers. That behavior you are describing can be implemented in the userspace. Thanks for the time! Ognjen
Re: Linux 4.15-rc2: Regression in resume from ACPI S3
On Tue 2017-12-05 01:25:55, Rafael J. Wysocki wrote: > On Monday, December 4, 2017 11:41:06 PM CET Rafael J. Wysocki wrote: > > On Monday, December 4, 2017 11:38:54 PM CET Thomas Gleixner wrote: > > > On Mon, 4 Dec 2017, Linus Torvalds wrote: > > > > > > > On Mon, Dec 4, 2017 at 2:25 PM, Rafael J. Wysocki > > > > wrote: > > > > > > > > > > So far, resume from suspend-to-RAM (ACPI S3) is broken on all of the > > > > > systems I have tested, so it is probably safe to assume it to be > > > > > broken everywhere. > > > > > > > > Oh, it's definitely not broken everywhere, because I use it myself, > > > > and was traveling last week due to my mom's bday. > > > > > > > > HOWEVER. > > > > > > > > Some of the x86 work seems to have broken it for some configurations. > > > > In particular, do you have a big "everything enabled" kernel config - > > > > particularly lockdep and irqflags tracing enabled? > > > > > > > > Andy has a patch, but it hasn't made it to me yet (probably because > > > > the x86 people are very busy with the kaiser work): > > > > This definitely fixes the problem at least on one of the affected machines. > > I can confirm that the Andy's patch fixes it on all systems that had this > issue here. I believe I have the issue here, too (-next on thinkpad x60). Which patch is expected to fix it? Let me try recent -next... 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] thinkpad_acpi: Support the battery wear control
On Sat 2017-12-09 11:29:51, Ognjen Galić wrote: > On 09/12/2017, Pavel Machek wrote: > > In newer series (I can't find it at the moment, sorry) > > The new series is a 3-patch patchset that obsoletes this > patch. It is in the testing stage and will be pushed to > the mailing lists and maintainers in a few days. > > > Maybe we should have separate status "not charging due to wear > > control"? > > No, because the ACPI battery driver is a extension to the generic > power supply driver, that does not understand the battery wear control. > Also, Rafael specifically noted NOT to include any thinkpad_acpi-specific > behavior to the generic drivers. Yeah, what I'm saying is that maybe we need to extend generic power supply driver. On small devices, we usually have enough control over hardware to be able to implement "wear control" in kernel. Nokia N900 is an example. "Wear control" is certainly not thinkpad-specific concept. 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 V4 01/11] Documentation: Add license-rules.rst to describe how to properly identify file licenses
Thomas, On Mon, Dec 4, 2017 at 10:19 PM, Thomas Gleixner wrote: [...] > +The common way of expressing the license of a source file is to add the > +matching boiler plate text into the top comment of the file. Due to I would likely go with boilerplate instead. Unless you are talking about the real flat thing [1][2] of course! [1] http://www.virtualmuseum.ca/Exhibitions/Railway/en/ag/lg16.jpg [2] http://whynameitthat.blogspot.be/2013/10/boiler-plate.html > +formatting, typos etc. these "boiler plates" are hard to validate for > +tools which are used in the context of license compliance. Same as above, "boilerplates" might be better. > + > +An alternative to boilerplate text is the use of Software Package Data And that's the correct way to go IMHO, so going boilerplate all the way makes sense. I shall add that while they --the boilerplates-- may be a source of unexpected excitement for first-year law students, each time someone sends a patch with these, there is a kitten that dies somewhere. And we all love kitten, do we? Thank you for using some of your precious real time writing this doc. Jonathan, As an English Major, does this make sense to you? (using boilerplate as a single word, not the kitten thing) -- Cordially Philippe Ombredanne
Re: [PATCH v2] thinkpad_acpi: Support the battery wear control
On 09/12/2017, Pavel Machek wrote: > Yeah, what I'm saying is that maybe we need to extend generic power > supply driver. I don't know about that, you would have to ask the maintainers if that is appropriate. Thanks for the time! Ognjen
Re: [patch V4 00/11] LICENSES: Add documentation and initial License files
Thomas, On Mon, Dec 4, 2017 at 10:19 PM, Thomas Gleixner wrote: > This is the 4th version of the licensing rules documentation. > > Changes since v3: > > - Addressed the review comments > > - Replaced the GPL-2.0 license text with the one from the kernel COPYING >file and added the nice explanation from Philippe to the changelog. > > - Picked up Reviewed-by tags > > Thanks to everyone who provided input! > > Thanks, > > tglx > With the comments I sent separately about "boiler plates" vs. boilerplate and the proposed "parens" doc updates for the quirk spotted by eagle-eyed Heiko, my Reviewed-by still stands for the whole patch set. Reviewed-by: Philippe Ombredanne -- Cordially Philippe Ombredanne
[PATCH v2 1/2] staging: rtl8712: Cleanup checkpatch issue WARNING:LONG_LINE
Cleanup below checkpatch issue:
WARNING:LONG_LINE: line over 80 characters
1000: FILE: rtl871x_security.c:1000:
+static void construct_ctr_preload(u8 *ctr_preload, sint a4_exists, sint
qc_exists,
Signed-off-by: Neil Singh
---
drivers/staging/rtl8712/rtl871x_security.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8712/rtl871x_security.c
b/drivers/staging/rtl8712/rtl871x_security.c
index 56d36f6..77a5f5d 100644
--- a/drivers/staging/rtl8712/rtl871x_security.c
+++ b/drivers/staging/rtl8712/rtl871x_security.c
@@ -997,7 +997,8 @@ static void construct_mic_header2(u8 *mic_header2, u8
*mpdu, sint a4_exists,
/* Builds the last MIC header block from*/
/* header fields. */
//
-static void construct_ctr_preload(u8 *ctr_preload, sint a4_exists, sint
qc_exists,
+static void construct_ctr_preload(u8 *ctr_preload,
+ sint a4_exists, sint qc_exists,
u8 *mpdu, u8 *pn_vector, sint c)
{
sint i;
--
2.1.4
[PATCH v2 0/2] staging: rtl8712: Cleanup codestyle
Cleanup some codestyle issues identified by checkpatch. Changes since v1: - Split single patch into multiple Neil Singh (2): staging: rtl8712: Cleanup checkpatch issue WARNING:LONG_LINE staging: rtl8712: Cleanup checkpatch issues CODE_INDENT and LEADING_SPACE drivers/staging/rtl8712/rtl871x_security.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) -- 2.1.4
[PATCH v2 2/2] staging: rtl8712: Cleanup checkpatch issues CODE_INDENT and LEADING_SPACE
Cleanup below checkpatch issues:
ERROR:CODE_INDENT: code indent should use tabs where possible
1409: FILE: rtl871x_security.c:1409:
+from_timer(padapter, t, securitypriv.tkip_timer);$
WARNING:LEADING_SPACE: please, no spaces at the start of a line
1409: FILE: rtl871x_security.c:1409:
+from_timer(padapter, t, securitypriv.tkip_timer);$
Signed-off-by: Neil Singh
---
drivers/staging/rtl8712/rtl871x_security.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8712/rtl871x_security.c
b/drivers/staging/rtl8712/rtl871x_security.c
index 77a5f5d..2fd49c0 100644
--- a/drivers/staging/rtl8712/rtl871x_security.c
+++ b/drivers/staging/rtl8712/rtl871x_security.c
@@ -1406,7 +1406,7 @@ u32 r8712_aes_decrypt(struct _adapter *padapter, u8
*precvframe)
void r8712_use_tkipkey_handler(struct timer_list *t)
{
struct _adapter *padapter =
-from_timer(padapter, t, securitypriv.tkip_timer);
+ from_timer(padapter, t, securitypriv.tkip_timer);
padapter->securitypriv.busetkipkey = true;
}
--
2.1.4
Re: kernel BUG at net/core/skbuff.c:LINE! (2)
On Fri, Dec 8, 2017 at 4:45 PM, Xin Long wrote:
> On Fri, Dec 8, 2017 at 4:16 PM, syzbot
>
> wrote:
>> syzkaller has found reproducer for the following crash on
>> 82bcf1def3b5f1251177ad47c44f7e17af039b4b
>> git://git.cmpxchg.org/linux-mmots.git/master
>> compiler: gcc (GCC) 7.1.1 20170620
>> .config is attached
>> Raw console output is attached.
>>
>> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
>> for information about syzkaller reproducers
>>
>>
>> skbuff: skb_over_panic: text:10b86b8d len:196 put:20
>> head:3b477e60 data:0e85441e tail:0xd4 end:0xc0 dev:lo
>> [ cut here ]
>> kernel BUG at net/core/skbuff.c:104!
>> invalid opcode: [#1] SMP KASAN
>> Dumping ftrace buffer:
>>(ftrace buffer empty)
>> Modules linked in:
>> CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.15.0-rc2-mm1+ #39
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> Google 01/01/2011
>> RIP: 0010:skb_panic+0x15c/0x1f0 net/core/skbuff.c:100
>> RSP: 0018:8801db307508 EFLAGS: 00010286
>> RAX: 0082 RBX: 8801c517e840 RCX:
>> RDX: 0082 RSI: 11003b660e61 RDI: ed003b660e95
>> RBP: 8801db307570 R08: 11003b660e23 R09:
>> R10: R11: R12: 85bd4020
>> R13: 84754ed2 R14: 0014 R15: 8801c4e26540
>> FS: () GS:8801db30() knlGS:
>> CS: 0010 DS: ES: CR0: 80050033
>> CR2: 00463610 CR3: 0001c6698000 CR4: 001406e0
>> DR0: DR1: DR2:
>> DR3: DR6: fffe0ff0 DR7: 0400
>> Call Trace:
>>
>> skb_over_panic net/core/skbuff.c:109 [inline]
>> skb_put+0x181/0x1c0 net/core/skbuff.c:1694
>> add_grhead.isra.24+0x42/0x3b0 net/ipv6/mcast.c:1695
>> add_grec+0xa55/0x1060 net/ipv6/mcast.c:1817
>> mld_send_cr net/ipv6/mcast.c:1903 [inline]
>> mld_ifc_timer_expire+0x4d2/0x770 net/ipv6/mcast.c:2448
>> call_timer_fn+0x23b/0x840 kernel/time/timer.c:1320
>> expire_timers kernel/time/timer.c:1357 [inline]
>> __run_timers+0x7e1/0xb60 kernel/time/timer.c:1660
>> run_timer_softirq+0x4c/0xb0 kernel/time/timer.c:1686
>> __do_softirq+0x29d/0xbb2 kernel/softirq.c:285
>> invoke_softirq kernel/softirq.c:365 [inline]
>> irq_exit+0x1d3/0x210 kernel/softirq.c:405
>> exiting_irq arch/x86/include/asm/apic.h:540 [inline]
>> smp_apic_timer_interrupt+0x16b/0x700 arch/x86/kernel/apic/apic.c:1052
>> apic_timer_interrupt+0xa9/0xb0 arch/x86/entry/entry_64.S:920
>>
>> RIP: 0010:native_safe_halt+0x6/0x10 arch/x86/include/asm/irqflags.h:54
>> RSP: 0018:8801d9f97da8 EFLAGS: 0282 ORIG_RAX: ff11
>> RAX: dc00 RBX: 11003b3f2fb8 RCX:
>> RDX: 10c59734 RSI: 0001 RDI: 862cb9a0
>> RBP: 8801d9f97da8 R08: R09:
>> R10: R11: R12: 0001
>> R13: 8801d9f97e60 R14: 869eb920 R15:
>> arch_safe_halt arch/x86/include/asm/paravirt.h:93 [inline]
>> default_idle+0xbf/0x430 arch/x86/kernel/process.c:355
>> arch_cpu_idle+0xa/0x10 arch/x86/kernel/process.c:346
>> default_idle_call+0x36/0x90 kernel/sched/idle.c:98
>> cpuidle_idle_call kernel/sched/idle.c:156 [inline]
>> do_idle+0x24a/0x3b0 kernel/sched/idle.c:246
>> cpu_startup_entry+0x18/0x20 kernel/sched/idle.c:351
>> start_secondary+0x330/0x460 arch/x86/kernel/smpboot.c:277
>> secondary_startup_64+0xa5/0xb0 arch/x86/kernel/head_64.S:237
>> Code: 03 0f b6 04 01 84 c0 74 04 3c 03 7e 20 8b 4b 78 41 57 48 c7 c7 a0 38
>> bd 85 52 56 4c 89 ea 41 50 4c 89 e6 45 89 f0 e8 0c b6 3d fd <0f> 0b 4c 89 4d
>> b8 4c 89 45 c0 48 89 75 c8 48 89 55 d0 e8 7d 93
>> RIP: skb_panic+0x15c/0x1f0 net/core/skbuff.c:100 RSP: 8801db307508
>> ---[ end trace 941a8a0f633e271f ]---
>>
> This isn't a sctp problem, but mld's, seems when lo's mtu became 0,
> it allocs a skb without enough space in add_grec():
> if (AVAILABLE(skb) < sizeof(*psrc) +
> first*sizeof(struct mld2_grec)) {
> if (truncate && !first)
> break; /* truncate these */
> if (pgr)
> pgr->grec_nsrcs = htons(scount);
> if (skb)
> mld_sendpack(skb);
> skb = mld_newpack(idev, dev->mtu); <---
>
> I will check this for sure later on both igmp and mld.
Fix:
--- a/net/ipv6/mcast.c
+++ b/net/ipv6/mcast.c
@@ -1766,8 +1766,8 @@ static struct sk_buff *add_grec(struct sk_buff
*skb, struct ifmcaddr6 *pmc,
if (isquery)
psf->sf_gsresp = 0;
- if (AVAILABLE(skb) < sizeof(*psrc) +
- first*sizeof(struct mld2_grec)) {
+ if (AVAIL
Re: KASAN: slab-out-of-bounds Read in sctp_send_reset_streams
On Sat, Dec 9, 2017 at 6:40 PM, syzbot wrote: > Hello, > > syzkaller hit the following crash on > 328b4ed93b69a6f2083d52f31a240a09e5de386a > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console output is attached. > C reproducer is attached > syzkaller reproducer is attached. See https://goo.gl/kgGztJ > for information about syzkaller reproducers > > > == > BUG: KASAN: slab-out-of-bounds in sctp_send_reset_streams+0xadf/0xc10 > net/sctp/stream.c:314 > Read of size 2 at addr 8801d8a6c048 by task syzkaller104411/3085 > > CPU: 0 PID: 3085 Comm: syzkaller104411 Not tainted 4.15.0-rc2+ #119 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > Call Trace: > __dump_stack lib/dump_stack.c:17 [inline] > dump_stack+0x194/0x257 lib/dump_stack.c:53 > print_address_description+0x73/0x250 mm/kasan/report.c:252 > kasan_report_error mm/kasan/report.c:351 [inline] > kasan_report+0x25b/0x340 mm/kasan/report.c:409 > __asan_report_load2_noabort+0x14/0x20 mm/kasan/report.c:428 > sctp_send_reset_streams+0xadf/0xc10 net/sctp/stream.c:314 > sctp_setsockopt_reset_streams net/sctp/socket.c:3905 [inline] > sctp_setsockopt+0x70d/0x5d50 net/sctp/socket.c:4195 > compat_sock_common_setsockopt+0x104/0x140 net/core/sock.c:2981 > C_SYSC_setsockopt net/compat.c:403 [inline] > compat_SyS_setsockopt+0x17c/0x410 net/compat.c:386 > do_syscall_32_irqs_on arch/x86/entry/common.c:327 [inline] > do_fast_syscall_32+0x3ee/0xf9d arch/x86/entry/common.c:389 > entry_SYSENTER_compat+0x51/0x60 arch/x86/entry/entry_64_compat.S:125 > RIP: 0023:0xf7f1bc79 > RSP: 002b:ff9893bc EFLAGS: 0282 ORIG_RAX: 016e > RAX: ffda RBX: 0005 RCX: 0084 > RDX: 0077 RSI: 2018b000 RDI: 0008 > RBP: 001c R08: R09: > R10: R11: R12: > R13: R14: R15: > > Allocated by task 3085: > save_stack+0x43/0xd0 mm/kasan/kasan.c:447 > set_track mm/kasan/kasan.c:459 [inline] > kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551 > __do_kmalloc mm/slab.c:3711 [inline] > __kmalloc_track_caller+0x15e/0x760 mm/slab.c:3726 > memdup_user+0x2c/0x90 mm/util.c:164 > sctp_setsockopt_reset_streams net/sctp/socket.c:3897 [inline] > sctp_setsockopt+0x6a6/0x5d50 net/sctp/socket.c:4195 > compat_sock_common_setsockopt+0x104/0x140 net/core/sock.c:2981 > C_SYSC_setsockopt net/compat.c:403 [inline] > compat_SyS_setsockopt+0x17c/0x410 net/compat.c:386 > do_syscall_32_irqs_on arch/x86/entry/common.c:327 [inline] > do_fast_syscall_32+0x3ee/0xf9d arch/x86/entry/common.c:389 > entry_SYSENTER_compat+0x51/0x60 arch/x86/entry/entry_64_compat.S:125 > > Freed by task 16: > save_stack+0x43/0xd0 mm/kasan/kasan.c:447 > set_track mm/kasan/kasan.c:459 [inline] > kasan_slab_free+0x71/0xc0 mm/kasan/kasan.c:524 > __cache_free mm/slab.c:3491 [inline] > kfree+0xca/0x250 mm/slab.c:3806 > selinux_cred_free+0x48/0x70 security/selinux/hooks.c:3814 > security_cred_free+0x48/0x80 security/security.c:995 > put_cred_rcu+0x106/0x400 kernel/cred.c:117 > __rcu_reclaim kernel/rcu/rcu.h:195 [inline] > rcu_do_batch kernel/rcu/tree.c:2758 [inline] > invoke_rcu_callbacks kernel/rcu/tree.c:3012 [inline] > __rcu_process_callbacks kernel/rcu/tree.c:2979 [inline] > rcu_process_callbacks+0xd74/0x17d0 kernel/rcu/tree.c:2996 > __do_softirq+0x29d/0xbb2 kernel/softirq.c:285 > > The buggy address belongs to the object at 8801d8a6c040 > which belongs to the cache kmalloc-32 of size 32 > The buggy address is located 8 bytes inside of > 32-byte region [8801d8a6c040, 8801d8a6c060) > The buggy address belongs to the page: > page:6b05592a count:1 mapcount:0 mapping:1ca7267d > index:0x8801d8a6cfc1 > flags: 0x2fffc000100(slab) > raw: 02fffc000100 8801d8a6c000 8801d8a6cfc1 0001003f > raw: ea000762f920 ea00076133e0 8801db0001c0 > page dumped because: kasan: bad access detected > > Memory state around the buggy address: > 8801d8a6bf00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc > 8801d8a6bf80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >> >> 8801d8a6c000: fb fb fb fb fc fc fc fc 00 fc fc fc fc fc fc fc > > ^ > 8801d8a6c080: fb fb fb fb fc fc fc fc 00 00 00 00 fc fc fc fc > 8801d8a6c100: fb fb fb fb fc fc fc fc fb fb fb fb fc fc fc fc > == > > > --- > This bug is generated by a dumb bot. It may contain errors. > See https://goo.gl/tpsmEJ for details. > Direct all questions to syzkal...@googlegroups.com. > Please credit me with: Reported-by: syzbot > > syzbot will keep track
Re: KASAN: stack-out-of-bounds Read in write_mmio
2017-12-09 17:15 GMT+08:00 syzbot : > syzkaller has found reproducer for the following crash on > ad4dac17f9d563b9e34aab78a34293b10993e9b5 > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console output is attached. > C reproducer is attached > syzkaller reproducer is attached. See https://goo.gl/kgGztJ > for information about syzkaller reproducers > > > kvm: KVM_SET_TSS_ADDR need to be called before entering vcpu > == > BUG: KASAN: stack-out-of-bounds in write_mmio+0x560/0x600 > arch/x86/kvm/x86.c:4669 > Read of size 8 at addr 8801c4587220 by task syzkaller601256/3159 > > CPU: 1 PID: 3159 Comm: syzkaller601256 Not tainted 4.15.0-rc2-next-20171208+ > #63 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > Call Trace: > __dump_stack lib/dump_stack.c:17 [inline] > dump_stack+0x194/0x257 lib/dump_stack.c:53 > print_address_description+0x73/0x250 mm/kasan/report.c:252 > kasan_report_error mm/kasan/report.c:351 [inline] > kasan_report+0x25b/0x340 mm/kasan/report.c:409 > __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:430 > write_mmio+0x560/0x600 arch/x86/kvm/x86.c:4669 > emulator_read_write_onepage+0x45a/0xea0 arch/x86/kvm/x86.c:4739 > emulator_read_write+0xe7/0x540 arch/x86/kvm/x86.c:4788 > emulator_write_emulated arch/x86/kvm/x86.c:4825 [inline] > emulator_fix_hypercall+0x14d/0x1b0 arch/x86/kvm/x86.c:6349 > em_hypercall+0x5d/0x120 arch/x86/kvm/emulate.c:3705 > x86_emulate_insn+0x55d/0x3c20 arch/x86/kvm/emulate.c:5498 > x86_emulate_instruction+0x411/0x1ad0 arch/x86/kvm/x86.c:5756 > emulate_instruction arch/x86/include/asm/kvm_host.h:1177 [inline] > handle_exception+0x3d5/0xa20 arch/x86/kvm/vmx.c:5921 > vmx_handle_exit+0x25d/0x1ce0 arch/x86/kvm/vmx.c:8887 > vcpu_enter_guest arch/x86/kvm/x86.c:7068 [inline] > vcpu_run arch/x86/kvm/x86.c:7130 [inline] > kvm_arch_vcpu_ioctl_run+0x1836/0x5be0 arch/x86/kvm/x86.c:7300 > kvm_vcpu_ioctl+0x64c/0x1010 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2555 > vfs_ioctl fs/ioctl.c:46 [inline] > do_vfs_ioctl+0x1b1/0x1530 fs/ioctl.c:686 > SYSC_ioctl fs/ioctl.c:701 [inline] > SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692 > entry_SYSCALL_64_fastpath+0x1f/0x96 > RIP: 0033:0x4435c9 > RSP: 002b:7fffdf34ced8 EFLAGS: 0202 ORIG_RAX: 0010 > RAX: ffda RBX: 205b3000 RCX: 004435c9 > RDX: RSI: ae80 RDI: 0005 > RBP: 000b R08: R09: 0002 > R10: 0012 R11: 0202 R12: 205b7e00 > R13: 205b6e00 R14: 205b7a00 R15: 205b3000 > > The buggy address belongs to the page: > page:2e827842 count:0 mapcount:0 mapping: (null) index:0x0 > flags: 0x2fffc00() > raw: 02fffc00 > raw: 00010001 > page dumped because: kasan: bad access detected > > Memory state around the buggy address: > 8801c4587100: f2 f2 f2 f2 00 f2 f2 f2 f3 f3 f3 f3 00 00 00 00 > 8801c4587180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> >> 8801c4587200: f1 f1 f1 f1 03 f2 f2 f2 f3 f3 f3 f3 00 00 00 00 > >^ > 8801c4587280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 8801c4587300: 00 f1 f1 f1 f1 02 f2 f2 f2 f2 f2 f2 f2 00 f2 f2 > == > This issue seems to be as same as previous pop issue. I will have a look. -- Best regards Tianyu Lan
Re: Linux 4.15-rc2: Regression in resume from ACPI S3
On Sat 2017-12-09 11:33:25, Pavel Machek wrote: > On Tue 2017-12-05 01:25:55, Rafael J. Wysocki wrote: > > On Monday, December 4, 2017 11:41:06 PM CET Rafael J. Wysocki wrote: > > > On Monday, December 4, 2017 11:38:54 PM CET Thomas Gleixner wrote: > > > > On Mon, 4 Dec 2017, Linus Torvalds wrote: > > > > > > > > > On Mon, Dec 4, 2017 at 2:25 PM, Rafael J. Wysocki > > > > > wrote: > > > > > > > > > > > > So far, resume from suspend-to-RAM (ACPI S3) is broken on all of the > > > > > > systems I have tested, so it is probably safe to assume it to be > > > > > > broken everywhere. > > > > > > > > > > Oh, it's definitely not broken everywhere, because I use it myself, > > > > > and was traveling last week due to my mom's bday. > > > > > > > > > > HOWEVER. > > > > > > > > > > Some of the x86 work seems to have broken it for some configurations. > > > > > In particular, do you have a big "everything enabled" kernel config - > > > > > particularly lockdep and irqflags tracing enabled? > > > > > > > > > > Andy has a patch, but it hasn't made it to me yet (probably because > > > > > the x86 people are very busy with the kaiser work): > > > > > > This definitely fixes the problem at least on one of the affected > > > machines. > > > > I can confirm that the Andy's patch fixes it on all systems that had this > > issue here. > > I believe I have the issue here, too (-next on thinkpad x60). Which > patch is expected to fix it? Let me try recent -next... Still there AFAICT. 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] doc: convert printk-formats.txt to rst
On Fri, Dec 08, 2017 at 06:18:45PM -0800, Joe Perches wrote: > On Sat, 2017-12-09 at 12:27 +1100, Tobin C. Harding wrote: > > On Fri, Dec 08, 2017 at 01:22:37PM -0800, Joe Perches wrote: > > > > Outside of the documentation, what could be useful is for > > > someone to add a tool to verify %p extension to > > > the typeof address actually passed as an argument. > > > > This sounds interesting to work no. At first glance I have no idea how > > one would go about this. Some form of static analysis would be a good > > place to start, right? I'd like to allocate some cycles to this, any > > pointers most appreciated. > > A gcc-plugin would likely work best. > > There was some discussion about such a thing here: > http://www.openwall.com/lists/kernel-hardening/2017/02/14/38 > > I vaguely recall someone else doing a broader use tool > which I believe was not smatch, but my google-fu isn't > finding it. Yeah. Smatch has a check for this. Rasmus Villemoes wrote it. regards, dan carpenter
[PATCH v2] net: ethernet: arc: fix error handling in emac_rockchip_probe
If clk_set_rate() fails, we should disable clk before return.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Branislav Radocaj
---
Changes since v2:
* Improved inconsistent failure handling of clock rate setting
* For completeness of usecase, added arc_emac_probe error handling
---
drivers/net/ethernet/arc/emac_rockchip.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/arc/emac_rockchip.c
b/drivers/net/ethernet/arc/emac_rockchip.c
index e278e3d96ee0..16f9bee992fe 100644
--- a/drivers/net/ethernet/arc/emac_rockchip.c
+++ b/drivers/net/ethernet/arc/emac_rockchip.c
@@ -199,9 +199,11 @@ static int emac_rockchip_probe(struct platform_device
*pdev)
/* RMII interface needs always a rate of 50MHz */
err = clk_set_rate(priv->refclk, 5000);
- if (err)
+ if (err) {
dev_err(dev,
"failed to change reference clock rate (%d)\n", err);
+ goto out_regulator_disable;
+ }
if (priv->soc_data->need_div_macclk) {
priv->macclk = devm_clk_get(dev, "macclk");
@@ -220,19 +222,24 @@ static int emac_rockchip_probe(struct platform_device
*pdev)
/* RMII TX/RX needs always a rate of 25MHz */
err = clk_set_rate(priv->macclk, 2500);
- if (err)
+ if (err) {
dev_err(dev,
"failed to change mac clock rate (%d)\n", err);
+ goto out_clk_disable_macclk;
+ }
}
err = arc_emac_probe(ndev, interface);
if (err) {
dev_err(dev, "failed to probe arc emac (%d)\n", err);
- goto out_regulator_disable;
+ goto out_clk_disable_macclk;
}
return 0;
+out_clk_disable_macclk:
+ if (priv->soc_data->need_div_macclk)
+ clk_disable_unprepare(priv->macclk);
out_regulator_disable:
if (priv->regulator)
regulator_disable(priv->regulator);
--
2.11.0
[PATCH] Make "Memory Debugging" a menuconfig to ease disabling it all
No need to get into the submenu to disable all "Memory Debugging"-related config entries. This makes it easier to disable all "Memory Debugging" config options without entering the submenu. It will also enable one to see that en/dis-abled state from the outside menu. This is only intended to change menuconfig UI, not change the config dependencies. Signed-off-by: Vincent Legoll --- lib/Kconfig.debug | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 947d3e2ed5c2..5062f52dbeec 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -436,7 +436,10 @@ config DEBUG_KERNEL Say Y here if you are developing drivers or trying to debug and identify kernel problems. -menu "Memory Debugging" +menuconfig DEBUG_MEMORY + bool "Memory Debugging" + +if DEBUG_MEMORY source mm/Kconfig.debug @@ -731,7 +734,7 @@ config DEBUG_STACKOVERFLOW source "lib/Kconfig.kasan" -endmenu # "Memory Debugging" +endif # DEBUG_MEMORY config ARCH_HAS_KCOV bool -- 2.14.1
Re: KASAN: slab-out-of-bounds Read in sctp_send_reset_streams
On Sat, Dec 9, 2017 at 7:35 PM, Xin Long wrote: > On Sat, Dec 9, 2017 at 6:40 PM, syzbot > > wrote: >> Hello, >> >> syzkaller hit the following crash on >> 328b4ed93b69a6f2083d52f31a240a09e5de386a >> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master >> compiler: gcc (GCC) 7.1.1 20170620 >> .config is attached >> Raw console output is attached. >> C reproducer is attached >> syzkaller reproducer is attached. See https://goo.gl/kgGztJ >> for information about syzkaller reproducers >> >> >> == >> BUG: KASAN: slab-out-of-bounds in sctp_send_reset_streams+0xadf/0xc10 >> net/sctp/stream.c:314 >> Read of size 2 at addr 8801d8a6c048 by task syzkaller104411/3085 >> >> CPU: 0 PID: 3085 Comm: syzkaller104411 Not tainted 4.15.0-rc2+ #119 >> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS >> Google 01/01/2011 >> Call Trace: >> __dump_stack lib/dump_stack.c:17 [inline] >> dump_stack+0x194/0x257 lib/dump_stack.c:53 >> print_address_description+0x73/0x250 mm/kasan/report.c:252 >> kasan_report_error mm/kasan/report.c:351 [inline] >> kasan_report+0x25b/0x340 mm/kasan/report.c:409 >> __asan_report_load2_noabort+0x14/0x20 mm/kasan/report.c:428 >> sctp_send_reset_streams+0xadf/0xc10 net/sctp/stream.c:314 >> sctp_setsockopt_reset_streams net/sctp/socket.c:3905 [inline] >> sctp_setsockopt+0x70d/0x5d50 net/sctp/socket.c:4195 >> compat_sock_common_setsockopt+0x104/0x140 net/core/sock.c:2981 >> C_SYSC_setsockopt net/compat.c:403 [inline] >> compat_SyS_setsockopt+0x17c/0x410 net/compat.c:386 >> do_syscall_32_irqs_on arch/x86/entry/common.c:327 [inline] >> do_fast_syscall_32+0x3ee/0xf9d arch/x86/entry/common.c:389 >> entry_SYSENTER_compat+0x51/0x60 arch/x86/entry/entry_64_compat.S:125 >> RIP: 0023:0xf7f1bc79 >> RSP: 002b:ff9893bc EFLAGS: 0282 ORIG_RAX: 016e >> RAX: ffda RBX: 0005 RCX: 0084 >> RDX: 0077 RSI: 2018b000 RDI: 0008 >> RBP: 001c R08: R09: >> R10: R11: R12: >> R13: R14: R15: >> >> Allocated by task 3085: >> save_stack+0x43/0xd0 mm/kasan/kasan.c:447 >> set_track mm/kasan/kasan.c:459 [inline] >> kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551 >> __do_kmalloc mm/slab.c:3711 [inline] >> __kmalloc_track_caller+0x15e/0x760 mm/slab.c:3726 >> memdup_user+0x2c/0x90 mm/util.c:164 >> sctp_setsockopt_reset_streams net/sctp/socket.c:3897 [inline] >> sctp_setsockopt+0x6a6/0x5d50 net/sctp/socket.c:4195 >> compat_sock_common_setsockopt+0x104/0x140 net/core/sock.c:2981 >> C_SYSC_setsockopt net/compat.c:403 [inline] >> compat_SyS_setsockopt+0x17c/0x410 net/compat.c:386 >> do_syscall_32_irqs_on arch/x86/entry/common.c:327 [inline] >> do_fast_syscall_32+0x3ee/0xf9d arch/x86/entry/common.c:389 >> entry_SYSENTER_compat+0x51/0x60 arch/x86/entry/entry_64_compat.S:125 >> >> Freed by task 16: >> save_stack+0x43/0xd0 mm/kasan/kasan.c:447 >> set_track mm/kasan/kasan.c:459 [inline] >> kasan_slab_free+0x71/0xc0 mm/kasan/kasan.c:524 >> __cache_free mm/slab.c:3491 [inline] >> kfree+0xca/0x250 mm/slab.c:3806 >> selinux_cred_free+0x48/0x70 security/selinux/hooks.c:3814 >> security_cred_free+0x48/0x80 security/security.c:995 >> put_cred_rcu+0x106/0x400 kernel/cred.c:117 >> __rcu_reclaim kernel/rcu/rcu.h:195 [inline] >> rcu_do_batch kernel/rcu/tree.c:2758 [inline] >> invoke_rcu_callbacks kernel/rcu/tree.c:3012 [inline] >> __rcu_process_callbacks kernel/rcu/tree.c:2979 [inline] >> rcu_process_callbacks+0xd74/0x17d0 kernel/rcu/tree.c:2996 >> __do_softirq+0x29d/0xbb2 kernel/softirq.c:285 >> >> The buggy address belongs to the object at 8801d8a6c040 >> which belongs to the cache kmalloc-32 of size 32 >> The buggy address is located 8 bytes inside of >> 32-byte region [8801d8a6c040, 8801d8a6c060) >> The buggy address belongs to the page: >> page:6b05592a count:1 mapcount:0 mapping:1ca7267d >> index:0x8801d8a6cfc1 >> flags: 0x2fffc000100(slab) >> raw: 02fffc000100 8801d8a6c000 8801d8a6cfc1 0001003f >> raw: ea000762f920 ea00076133e0 8801db0001c0 >> page dumped because: kasan: bad access detected >> >> Memory state around the buggy address: >> 8801d8a6bf00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >> 8801d8a6bf80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >>> >>> 8801d8a6c000: fb fb fb fb fc fc fc fc 00 fc fc fc fc fc fc fc >> >> ^ >> 8801d8a6c080: fb fb fb fb fc fc fc fc 00 00 00 00 fc fc fc fc >> 8801d8a6c100: fb fb fb fb fc fc fc fc fb fb fb fb fc fc fc fc >> == >> >> >> --- >> This bug is generated by a dumb bot. It may contain errors. >> See htt
Re: [PATCH v1 2/2] drm/tinydrm: add driver for ST7735R panels
Den 29.11.2017 04.01, skrev David Lechner:
This adds a new driver for Sitronix ST7735R display panels.
This has been tested using an Adafruit 1.8" TFT.
Signed-off-by: David Lechner
---
diff --git a/drivers/gpu/drm/tinydrm/st7735r.c
b/drivers/gpu/drm/tinydrm/st7735r.c
+static struct drm_driver st7735r_driver = {
+ .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME |
+ DRIVER_ATOMIC,
+ .fops = &st7735r_fops,
+ TINYDRM_GEM_DRIVER_OPS,
+ .lastclose = tinydrm_lastclose,
I was reminded of this since it would have made it easy to turn off the
panel and see if it turned white. Adding this makes it possible to send
commands from userspace for testing:
.debugfs_init = mipi_dbi_debugfs_init,
If you do that you have to set this to NULL since it's not possible to
read from the controller in this panel:
mipi->read_commands = NULL;
Noralf.
Re: [PATCH] Make "Memory Debugging" a menuconfig to ease disabling it all
This patch introduces some Kconfig warnings: warning: (X86) selects HAVE_DEBUG_KMEMLEAK which has unmet direct dependencies (DEBUG_MEMORY) warning: (X86) selects HAVE_ARCH_KASAN which has unmet direct dependencies (DEBUG_MEMORY) warning: (X86) selects ARCH_HAS_DEBUG_VIRTUAL which has unmet direct dependencies (DEBUG_MEMORY) warning: (X86) selects HAVE_DEBUG_STACKOVERFLOW which has unmet direct dependencies (DEBUG_MEMORY) What would be the best way to fix that ? excluding those config options from the "if DEBUG_MEMORY" code block seems to alleviate the warnings, but is that OK to do ? Would moving them out of the if/endif block be acceptable ? Thanks -- Vincent Legoll
Re: [PATCH v2] mm: terminate shrink_slab loop if signal is pending
On 2017/12/09 6:02, David Rientjes wrote: > On Thu, 7 Dec 2017, Suren Baghdasaryan wrote: > >> Slab shrinkers can be quite time consuming and when signal >> is pending they can delay handling of the signal. If fatal >> signal is pending there is no point in shrinking that process >> since it will be killed anyway. This change checks for pending >> fatal signals inside shrink_slab loop and if one is detected >> terminates this loop early. >> > > I've proposed a similar patch in the past, but for a check on TIF_MEMDIE, > which would today be a tsk_is_oom_victim(current), since we had observed > lengthy stalls in reclaim that would have been prevented if the oom victim > had exited out, returned back to the page allocator, allocated with > ALLOC_NO_WATERMARKS, and proceeded to quickly exit. > > I'm not sure that all fatal_signal_pending() tasks should get the same > treatment, but I understand the point that the task is killed and should > free memory when it fully exits. How much memory is unknown. > We can use __GFP_KILLABLE. Unless there is performance impact for checking fatal_siganl_pending(), allowing only fatal_signal_pending() threads with __GFP_KILLABLE to bail out (without using memory reserves) should be safe.
Re: [PATCH] sched/isolation: Make NO_HZ_FULL select CPU_ISOLATION
2017-12-07 18:29 UTC+01:00, Paul E. McKenney : > On Thu, Dec 07, 2017 at 05:14:54PM +0100, Frederic Weisbecker wrote: >> 2017-12-04 18:16 UTC+01:00, Paul E. McKenney >> : >> > On Mon, Dec 04, 2017 at 04:53:15PM +0100, Frederic Weisbecker wrote: >> >> 2017-12-02 20:24 UTC+01:00, Paul E. McKenney >> >> I would prefer to keep it. It's useful for automated boot testing >> >> based on configs such as 0-day or -tip test machines. But I'm likely >> >> to migrate it to isolcpus implementation. Maybe something along the >> >> lines of CONFIG_CPU_ISOLATION_ALL. >> > >> > How about instead allowing something like "nohz_full=1-" specify that >> > all CPUs other than CPU 0 should be nohz_full CPUs? That would shrink >> > the code by eliminating CONFIG_NO_HZ_FULL_ALL while still allowing >> > easy automation of that particular scenario. >> > >> > (Right now, the boot code complains about "nohz_full=1-", which means >> > that whatever is generating the boot parameters needs to know how many >> > CPUs there really are, which as you say can be a pain.) >> >> Yes but automated boot testing is rather based on configs than boot >> options. It's much easier. I think that's how Wu Fengguang lab works, >> and -tip automated tests as well. > > So you have gotten bug reports from them? Because I see splats from > rcutorture testing rather frequently. This thing is in no way a subtle > low-probability bug. ;-) Nope I haven't got anything from them. So far you're the only reproducer I know :) >> >> >> Did you have any nohz_full= or isolcpus= boot options? >> >> > >> >> > Replacing CONFIG_NO_HZ_FULL_ALL=y with nohz_full=1-7 works, that >> >> > is CONFIG_NO_HZ_FULL=y, CONFIG_NO_HZ_FULL_ALL=n, and nohz_full=1-7 >> >> > on an eight-CPU test. >> >> > >> >> > But it is relatively easy to test. Running the rcutorture TREE04 >> >> > scenario on a four-socket x86 gets me RCU CPU stall warnings within >> >> > a few minutes more than half the time. ;-) >> >> >> >> Indeed I managed to trigger something. If it's the same thing I should >> >> be able to track down the root cause. >> >> >> >> [ 123.907557] ??? Writer stall state RTWS_STUTTER(8) g160 c160 f0x0 >> >> ->state 0x1 cpu 2 >> >> [ 123.915184] rcu_torture_wri S0 111 2 0x8008 >> >> [ 123.920673] Call Trace: >> >> [ 123.923096] ? __schedule+0x2bf/0xbb0 >> >> [ 123.926715] ? _raw_spin_unlock_irqrestore+0x59/0x70 >> >> [ 123.931657] schedule+0x3c/0x90 >> >> [ 123.934777] schedule_timeout+0x1e1/0x560 >> > >> > It might well be the same thing, as this schedule_timeout() does look >> > familiar. I have some diagnostic patches in -rcu, please see below >> > for the overall effect. >> >> I fear I can hit that even without any nohz_full CPU as well. > > Indeed, I do hit that with my TREE01 scenario, which does not set > CONFIG_NO_HZ_FULL. But it is much less frequent. The good news is that > I have finally figured out a way to extract information from this thing > without suppressing it. At the moment it appears to be a rather strange > deadlock involving CPU hotplug, timers, and RCU. > > But that is a completely different bug from the ones for which I have > the two patches in my tree. > > Anyway, I will keep those two patches because I cannot have the > corresponding bugs possibly hiding RCU bugs in my testing. If you > put some other fix in place, I will drop those two patches in favor of > your fix. Ok. I'm a bit troubled by this bug, I hate to push a fix for a bug I don't understand nor can reproduce. But having CONFIG_NO_HZ_FULL select CONFIG_CPU_ISOLATION is already a fix for sanity that I need to push. So I think I'm going to take your patch anyway and rewrite the changelog to take all that into account. Thanks Paul!
Re: [PATCH RESEND] CLK: ARC: Set initial pll output frequency specified in device tree
On Tue, 2017-11-14 at 15:46 -0800, sb...@codeaurora.org wrote:
> On 11/14, Alexey Brodkin wrote:
> > Hi Vladimir,
> >
> > On Tue, 2017-11-14 at 19:01 +0200, Vladimir Zapolskiy wrote:
> > > On 11/14/2017 02:20 PM, Eugeniy Paltsev wrote:
> > > >
> > > > Add option to set initial output frequency of plls via
> > > > "clock-frequency" property in pll's device tree node.
> > > > This frequency will be set while pll driver probed.
> > > >
> > > > The usage example is setting CPU clock frequency on boot
> > > > See discussion:
> > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.mail-2Darchive.com_linux-2Dsnps-2Darc-40lists.infradead.org_msg02689.html&d=DwICAg&c=
> > > > DPL6
> > > > _X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=vTFoSv1E8NyQC8nqe6pwvuTDxGvEefhAdGwAoABOrY4&s=sbmMnczdKP317bN973cZn2WcYF29k
> > > > VMLW
> > > > chYfhSGT2M&e=
> > > >
> > > > Signed-off-by: Eugeniy Paltsev
> > > > ---
> > > > .../bindings/clock/snps,hsdk-pll-clock.txt | 5
> > > > .../devicetree/bindings/clock/snps,pll-clock.txt | 5
> > > > drivers/clk/axs10x/pll_clock.c | 34
> > > > --
> > > > drivers/clk/clk-hsdk-pll.c | 34
> > > > --
> > > > 4 files changed, 74 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/clock/snps,hsdk-pll-clock.txt
> > > > b/Documentation/devicetree/bindings/clock/snps,hsdk-pll-clock.txt
> > > > index c56c755..5703059 100644
> > > > --- a/Documentation/devicetree/bindings/clock/snps,hsdk-pll-clock.txt
> > > > +++ b/Documentation/devicetree/bindings/clock/snps,hsdk-pll-clock.txt
> > > > @@ -13,6 +13,10 @@ Required properties:
> > > > - clocks: shall be the input parent clock phandle for the PLL.
> > > > - #clock-cells: from common clock binding; Should always be set to 0.
> > > >
> > > > +Optional properties:
> > > > +- clock-frequency: output frequency generated by pll in Hz which will
> > > > be set
> > > > +while probing. Should be a single cell.
> > > > +
> > > > Example:
> > > > input_clk: input-clk {
> > > > clock-frequency = <>;
> > > > @@ -25,4 +29,5 @@ Example:
> > > > reg = <0x00 0x10>;
> > > > #clock-cells = <0>;
> > > > clocks = <&input_clk>;
> > > > + clock-frequency = <10>;
> > > > };
> > > > diff --git a/Documentation/devicetree/bindings/clock/snps,pll-clock.txt
> > > > b/Documentation/devicetree/bindings/clock/snps,pll-clock.txt
> > > > index 11fe487..5908f99 100644
> > > > --- a/Documentation/devicetree/bindings/clock/snps,pll-clock.txt
> > > > +++ b/Documentation/devicetree/bindings/clock/snps,pll-clock.txt
> > > > @@ -13,6 +13,10 @@ registers and second for corresponding LOCK CGU
> > > > register.
> > > > - clocks: shall be the input parent clock phandle for the PLL.
> > > > - #clock-cells: from common clock binding; Should always be set to 0.
> > > >
> > > > +Optional properties:
> > > > +- clock-frequency: output frequency generated by pll in Hz which will
> > > > be set
> > > > +while probing. Should be a single cell.
> > > > +
> > > > Example:
> > > > input-clk: input-clk {
> > > > clock-frequency = <>;
> > > > @@ -25,4 +29,5 @@ Example:
> > > > reg = <0x80 0x10>, <0x100 0x10>;
> > > > #clock-cells = <0>;
> > > > clocks = <&input-clk>;
> > > > + clock-frequency = <1>;
> > > > };
> > >
> > > You may check Documentation/devicetree/bindings/clock/clock-bindings.txt
> > > about how to assign initial clock rates, in general 'clock-frequency'
> > > property is a property of clock consumers with two exceptions of simple
> > > clock sources, namely it is used in fixed clock and PWM clock bindings.
> >
> > I think that's what we agreed on with Rob Herring back in the day.
> > Have you checked this post of him on the topic?
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_pipermail_linux-2Dsnps-2Darc_2017-2DSeptember_002909.html&d=DwIDAw&c=DPL6_
> > X_6JkXFx7AXWqB0tg&r=ZlJN1MriPUTkBKCrPSx67GmaplEUGcAEk9yPtCLdUXI&m=X0W8p5fOjiyVhK1216Lktb5yH3ojTSZhdnQhEiIVj0k&s=yGJfHbjH2T75YeIJLB14_iDjfsKi1E5aaX
> > Yu3QJBUIk&e=
> >
> > Just FYI it all started from my question here:
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_pipermail_linux-2Dsnps-2Darc_2017-2DSeptember_002900.html&d=DwIDAw&c=DPL6_
> > X_6JkXFx7AXWqB0tg&r=ZlJN1MriPUTkBKCrPSx67GmaplEUGcAEk9yPtCLdUXI&m=X0W8p5fOjiyVhK1216Lktb5yH3ojTSZhdnQhEiIVj0k&s=Jkzt2G_J4aE9JfePPQ57ldnrFWeS57Rhfc
> > Mhun92oU0&e=
>
> Why can't we use assigned-clock-rates? That would basically call
> clk_set_rate() on the clk once it's added.
Thanks for the hint, assigned-clock-rates works for us.
--
Eugeniy Paltsev
[PATCH 0/4] ARC: Set initial core pll output frequency via DTS
Set initial core pll output frequency on HSDK and AXS103 via "assigned-clock-rates" property in device tree. It will be applied at the core pll driver probing. Eugeniy Paltsev (4): ARC: [plat-hsdk]: Set initial core pll output frequency ARC: [plat-hsdk]: Get rid of core pll frequency set in platform code ARC: [plat-axs103]: Set initial core pll output frequency ARC: [plat-axs103] refactor the quad core DT quirk code arch/arc/boot/dts/axc003.dtsi | 3 +++ arch/arc/boot/dts/axc003_idu.dtsi | 3 +++ arch/arc/boot/dts/hsdk.dts| 3 +++ arch/arc/plat-axs10x/axs10x.c | 18 - arch/arc/plat-hsdk/platform.c | 42 --- 5 files changed, 17 insertions(+), 52 deletions(-) -- 2.9.3
[PATCH 1/4] ARC: [plat-hsdk]: Set initial core pll output frequency
Set initial core pll output frequency specified in device tree to
1GHz. It will be applied at the core pll driver probing.
Signed-off-by: Eugeniy Paltsev
---
arch/arc/boot/dts/hsdk.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arc/boot/dts/hsdk.dts b/arch/arc/boot/dts/hsdk.dts
index 8f627c2..006aa3d 100644
--- a/arch/arc/boot/dts/hsdk.dts
+++ b/arch/arc/boot/dts/hsdk.dts
@@ -114,6 +114,14 @@
reg = <0x00 0x10>, <0x14B8 0x4>;
#clock-cells = <0>;
clocks = <&input_clk>;
+
+ /*
+* Set initial core pll output frequency to 1GHz.
+* It will be applied at the core pll driver probing
+* on early boot.
+*/
+ assigned-clocks = <&core_clk>;
+ assigned-clock-rates = <10>;
};
serial: serial@5000 {
--
2.9.3
[PATCH 2/4] ARC: [plat-hsdk]: Get rid of core pll frequency set in platform code
Get rid of core pll frequency set in platform code as we set it via
device tree using 'assigned-clock-rates' property.
Signed-off-by: Eugeniy Paltsev
---
arch/arc/plat-hsdk/platform.c | 42 --
1 file changed, 42 deletions(-)
diff --git a/arch/arc/plat-hsdk/platform.c b/arch/arc/plat-hsdk/platform.c
index fd0ae5e..2958aed 100644
--- a/arch/arc/plat-hsdk/platform.c
+++ b/arch/arc/plat-hsdk/platform.c
@@ -38,42 +38,6 @@ static void __init hsdk_init_per_cpu(unsigned int cpu)
#define CREG_PAE (CREG_BASE + 0x180)
#define CREG_PAE_UPDATE(CREG_BASE + 0x194)
-#define CREG_CORE_IF_CLK_DIV (CREG_BASE + 0x4B8)
-#define CREG_CORE_IF_CLK_DIV_2 0x1
-#define CGU_BASE ARC_PERIPHERAL_BASE
-#define CGU_PLL_STATUS (ARC_PERIPHERAL_BASE + 0x4)
-#define CGU_PLL_CTRL (ARC_PERIPHERAL_BASE + 0x0)
-#define CGU_PLL_STATUS_LOCKBIT(0)
-#define CGU_PLL_STATUS_ERR BIT(1)
-#define CGU_PLL_CTRL_1GHZ 0x3A10
-#define HSDK_PLL_LOCK_TIMEOUT 500
-
-#define HSDK_PLL_LOCKED() \
- !!(ioread32((void __iomem *) CGU_PLL_STATUS) & CGU_PLL_STATUS_LOCK)
-
-#define HSDK_PLL_ERR() \
- !!(ioread32((void __iomem *) CGU_PLL_STATUS) & CGU_PLL_STATUS_ERR)
-
-static void __init hsdk_set_cpu_freq_1ghz(void)
-{
- u32 timeout = HSDK_PLL_LOCK_TIMEOUT;
-
- /*
-* As we set cpu clock which exceeds 500MHz, the divider for the
interface
-* clock must be programmed to div-by-2.
-*/
- iowrite32(CREG_CORE_IF_CLK_DIV_2, (void __iomem *)
CREG_CORE_IF_CLK_DIV);
-
- /* Set cpu clock to 1GHz */
- iowrite32(CGU_PLL_CTRL_1GHZ, (void __iomem *) CGU_PLL_CTRL);
-
- while (!HSDK_PLL_LOCKED() && timeout--)
- cpu_relax();
-
- if (!HSDK_PLL_LOCKED() || HSDK_PLL_ERR())
- pr_err("Failed to setup CPU frequency to 1GHz!");
-}
-
#define SDIO_BASE (ARC_PERIPHERAL_BASE + 0xA000)
#define SDIO_UHS_REG_EXT (SDIO_BASE + 0x108)
#define SDIO_UHS_REG_EXT_DIV_2 (2 << 30)
@@ -98,12 +62,6 @@ static void __init hsdk_init_early(void)
* minimum possible div-by-2.
*/
iowrite32(SDIO_UHS_REG_EXT_DIV_2, (void __iomem *) SDIO_UHS_REG_EXT);
-
- /*
-* Setup CPU frequency to 1GHz.
-* TODO: remove it after smart hsdk pll driver will be introduced.
-*/
- hsdk_set_cpu_freq_1ghz();
}
static const char *hsdk_compat[] __initconst = {
--
2.9.3
[PATCH 3/4] ARC: [plat-axs103]: Set initial core pll output frequency
Set initial core pll output frequency specified in device tree to
100MHz for SMP configuration and 90MHz for UP configuration.
It will be applied at the core pll driver probing.
Update platform quirk for decreasing core frequency for quad core
configuration.
Signed-off-by: Eugeniy Paltsev
---
arch/arc/boot/dts/axc003.dtsi | 8
arch/arc/boot/dts/axc003_idu.dtsi | 8
arch/arc/plat-axs10x/axs10x.c | 8 ++--
3 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/arch/arc/boot/dts/axc003.dtsi b/arch/arc/boot/dts/axc003.dtsi
index 4e6e9f5..dc91c66 100644
--- a/arch/arc/boot/dts/axc003.dtsi
+++ b/arch/arc/boot/dts/axc003.dtsi
@@ -35,6 +35,14 @@
reg = <0x80 0x10>, <0x100 0x10>;
#clock-cells = <0>;
clocks = <&input_clk>;
+
+ /*
+* Set initial core pll output frequency to 90MHz.
+* It will be applied at the core pll driver probing
+* on early boot.
+*/
+ assigned-clocks = <&core_clk>;
+ assigned-clock-rates = <9000>;
};
core_intc: archs-intc@cpu {
diff --git a/arch/arc/boot/dts/axc003_idu.dtsi
b/arch/arc/boot/dts/axc003_idu.dtsi
index 63954a8..69ff4895 100644
--- a/arch/arc/boot/dts/axc003_idu.dtsi
+++ b/arch/arc/boot/dts/axc003_idu.dtsi
@@ -35,6 +35,14 @@
reg = <0x80 0x10>, <0x100 0x10>;
#clock-cells = <0>;
clocks = <&input_clk>;
+
+ /*
+* Set initial core pll output frequency to 100MHz.
+* It will be applied at the core pll driver probing
+* on early boot.
+*/
+ assigned-clocks = <&core_clk>;
+ assigned-clock-rates = <1>;
};
core_intc: archs-intc@cpu {
diff --git a/arch/arc/plat-axs10x/axs10x.c b/arch/arc/plat-axs10x/axs10x.c
index cf14ebc..28b3cb2 100644
--- a/arch/arc/plat-axs10x/axs10x.c
+++ b/arch/arc/plat-axs10x/axs10x.c
@@ -327,22 +327,18 @@ static void __init axs103_early_init(void)
unsigned int num_cores = (read_aux_reg(ARC_REG_MCIP_BCR) >> 16) & 0x3F;
if (num_cores > 2) {
u32 freq = 50, orig;
- /*
-* TODO: use cpu node "cpu-freq" param instead of
platform-specific
-* "/cpu_card/core_clk" as it works only if we use fixed-clock
for cpu.
-*/
int off = fdt_path_offset(initial_boot_params,
"/cpu_card/core_clk");
const struct fdt_property *prop;
prop = fdt_get_property(initial_boot_params, off,
- "clock-frequency", NULL);
+ "assigned-clock-rates", NULL);
orig = be32_to_cpu(*(u32*)(prop->data)) / 100;
/* Patching .dtb in-place with new core clock value */
if (freq != orig ) {
freq = cpu_to_be32(freq * 100);
fdt_setprop_inplace(initial_boot_params, off,
- "clock-frequency", &freq,
sizeof(freq));
+ "assigned-clock-rates", &freq,
sizeof(freq));
}
}
#endif
--
2.9.3
[PATCH 4/4] ARC: [plat-axs103] refactor the quad core DT quirk code
Refactor the quad core DT quirk code:
get rid of waste division and multiplication by 100 constant.
Signed-off-by: Eugeniy Paltsev
---
arch/arc/plat-axs10x/axs10x.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/arc/plat-axs10x/axs10x.c b/arch/arc/plat-axs10x/axs10x.c
index 28b3cb2..0ea2f86 100644
--- a/arch/arc/plat-axs10x/axs10x.c
+++ b/arch/arc/plat-axs10x/axs10x.c
@@ -324,19 +324,21 @@ static void __init axs103_early_init(void)
* Instead of duplicating defconfig/DT for SMP/QUAD, add a small hack
* of fudging the freq in DT
*/
+#define AXS103_QUAD_CORE_CPU_FREQ_HZ 5000
+
unsigned int num_cores = (read_aux_reg(ARC_REG_MCIP_BCR) >> 16) & 0x3F;
if (num_cores > 2) {
- u32 freq = 50, orig;
+ u32 freq;
int off = fdt_path_offset(initial_boot_params,
"/cpu_card/core_clk");
const struct fdt_property *prop;
prop = fdt_get_property(initial_boot_params, off,
"assigned-clock-rates", NULL);
- orig = be32_to_cpu(*(u32*)(prop->data)) / 100;
+ freq = be32_to_cpu(*(u32 *)(prop->data));
/* Patching .dtb in-place with new core clock value */
- if (freq != orig ) {
- freq = cpu_to_be32(freq * 100);
+ if (freq != AXS103_QUAD_CORE_CPU_FREQ_HZ) {
+ freq = cpu_to_be32(AXS103_QUAD_CORE_CPU_FREQ_HZ);
fdt_setprop_inplace(initial_boot_params, off,
"assigned-clock-rates", &freq,
sizeof(freq));
}
--
2.9.3
Re: [PATCH V3] ACPI / GED: unregister interrupts during shutdown
On Sat, Dec 9, 2017 at 2:54 AM, Sinan Kaya wrote:
> On 12/8/2017 8:54 AM, Rafael J. Wysocki wrote:
>>> static int ged_remove(struct platform_device *pdev)
>>> +{
>>> + struct acpi_ged_device *geddev = platform_get_drvdata(pdev);
>>>
>>> + ged_cleanup_irq(geddev);
>> Do you really need this duplication? You may as well call
>> ged_shutdown() from here.
>>
>> And the local variable is redundant too.
>>
>> I guess it would be better to just fold ged_cleanup_irq() into
>> ged_shutdown() and call that from ged_remove().
>>
>
> I originally tried to make these two APIs as common as possible and tried
> calling shutdown from remove. However, the calling convention of shutdown
> and remove are different.
Look at the code in your patch: ged_shutdown() does exactly the same
things as ged_remove(), except that ged_remove() returns 0 in addition
to that, so you can do it this way:
static int int ged_remove(struct platform_device *pdev)
{
ged_shutdown(pdev);
return 0;
}
Why wouldn't that work?
> Shutdown returns void; whereas, remove returns an integer. That's why, I
> created a common function and called from both places.
>
> I can probably make the calling parameter of ged_cleanup_irq() a pdev and
> get rid of the additional casting in these two different functions.
>
> Let me know if you have a better idea.
And with the above, you can fold your ged_cleanup_irq() into
ged_shutdown(), can't you?
Re: [PATCH] PM / sleep: Avoid excess pm_runtime_enable() calls in device_resume()
On Fri, Dec 8, 2017 at 9:25 PM, Bjorn Helgaas wrote: > On Thu, Dec 07, 2017 at 03:26:14AM +0100, Rafael J. Wysocki wrote: >> From: Rafael J. Wysocki >> >> Middle-layer code doing suspend-time optimizations for devices with >> the DPM_FLAG_SMART_SUSPEND flag set (currently, the PCI bus type and >> the ACPI PM domain) needs to make the core skip ->thaw_early and >> ->thaw callbacks for those devices in some cases and it sets the >> power.direct_complete flag for them for this purpose. >> >> However, it turns out that setting power.direct_complete outside of >> the PM core is a bad idea as it triggers an excessive invocation of >> pm_runtime_enable() in device_resume(). >> >> For this reason, provide a helper to clear power.is_late_suspended >> and power.is_suspended to be invoked by the middle-layer code in >> question instead of setting power.direct_complete and make that code >> call the new helper. >> >> Fixes: c4b65157aeef (PCI / PM: Take SMART_SUSPEND driver flag into account) >> Fixes: 05087360fd7a (ACPI / PM: Take SMART_SUSPEND driver flag into account) >> Signed-off-by: Rafael J. Wysocki > > Acked-by: Bjorn Helgaas > > I don't pretend to understand this (and I don't need to, so don't > waste your time explaining), but I trust you :) Thank you! :-)
[PATCH] ptp: make PTP a menuconfig to ease disabling it all
No need to get into the submenu to disable all PTP-related config entries. This makes it easier to disable all PTP config options without entering the submenu. It will also enable one to see that en/dis-abled state from the outside menu. This is only intended to change menuconfig UI, not change the config dependencies. Signed-off-by: Vincent Legoll --- drivers/ptp/Kconfig | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/ptp/Kconfig b/drivers/ptp/Kconfig index a21ad10d613c..d3f3a9f2b0b1 100644 --- a/drivers/ptp/Kconfig +++ b/drivers/ptp/Kconfig @@ -2,7 +2,10 @@ # PTP clock support configuration # -menu "PTP clock support" +menuconfig PTP_MENU + bool"PTP clock support" + +if PTP_MENU config PTP_1588_CLOCK tristate "PTP clock support" @@ -118,4 +121,4 @@ config PTP_1588_CLOCK_KVM To compile this driver as a module, choose M here: the module will be called ptp_kvm. -endmenu +endif # PTP_MENU -- 2.14.1
[PATCH] hyperv: make HYPERV a menuconfig to ease disabling it all
No need to get into the submenu to disable all HYPERV-related config entries. This makes it easier to disable all HYPERV config options without entering the submenu. It will also enable one to see that en/dis-abled state from the outside menu. This is only intended to change menuconfig UI, not change the config dependencies. Signed-off-by: Vincent Legoll --- drivers/hv/Kconfig | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig index 50b89ea0e60f..5804081d936d 100644 --- a/drivers/hv/Kconfig +++ b/drivers/hv/Kconfig @@ -1,4 +1,7 @@ -menu "Microsoft Hyper-V guest support" +menuconfig HYPERV_MENU + bool "Microsoft Hyper-V guest support" + +if HYPERV_MENU config HYPERV tristate "Microsoft Hyper-V client drivers" @@ -23,4 +26,4 @@ config HYPERV_BALLOON help Select this option to enable Hyper-V Balloon driver. -endmenu +endif # HYPERV_MENU -- 2.14.1
[PATCH net-next] libbpf: add function to setup XDP
Most of the code is taken from set_link_xdp_fd() in bpf_load.c and
slightly modified to be library compliant.
Signed-off-by: Eric Leblond
---
tools/lib/bpf/bpf.c| 108 -
tools/lib/bpf/libbpf.c | 2 +
tools/lib/bpf/libbpf.h | 4 ++
3 files changed, 112 insertions(+), 2 deletions(-)
diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
index 5128677e4117..bea173be66fc 100644
--- a/tools/lib/bpf/bpf.c
+++ b/tools/lib/bpf/bpf.c
@@ -25,6 +25,10 @@
#include
#include
#include "bpf.h"
+#include "libbpf.h"
+#include
+#include
+#include
/*
* When building perf, unistd.h is overridden. __NR_bpf is
@@ -46,8 +50,6 @@
# endif
#endif
-#define min(x, y) ((x) < (y) ? (x) : (y))
-
static inline __u64 ptr_to_u64(const void *ptr)
{
return (__u64) (unsigned long) ptr;
@@ -413,3 +415,105 @@ int bpf_obj_get_info_by_fd(int prog_fd, void *info, __u32
*info_len)
return err;
}
+
+int bpf_set_link_xdp_fd(int ifindex, int fd, __u32 flags)
+{
+ struct sockaddr_nl sa;
+ int sock, seq = 0, len, ret = -1;
+ char buf[4096];
+ struct nlattr *nla, *nla_xdp;
+ struct {
+ struct nlmsghdr nh;
+ struct ifinfomsg ifinfo;
+ char attrbuf[64];
+ } req;
+ struct nlmsghdr *nh;
+ struct nlmsgerr *err;
+
+ memset(&sa, 0, sizeof(sa));
+ sa.nl_family = AF_NETLINK;
+
+ sock = socket(AF_NETLINK, SOCK_RAW, NETLINK_ROUTE);
+ if (sock < 0) {
+ return -errno;
+ }
+
+ if (bind(sock, (struct sockaddr *)&sa, sizeof(sa)) < 0) {
+ ret = -errno;
+ goto cleanup;
+ }
+
+ memset(&req, 0, sizeof(req));
+ req.nh.nlmsg_len = NLMSG_LENGTH(sizeof(struct ifinfomsg));
+ req.nh.nlmsg_flags = NLM_F_REQUEST | NLM_F_ACK;
+ req.nh.nlmsg_type = RTM_SETLINK;
+ req.nh.nlmsg_pid = 0;
+ req.nh.nlmsg_seq = ++seq;
+ req.ifinfo.ifi_family = AF_UNSPEC;
+ req.ifinfo.ifi_index = ifindex;
+
+ /* started nested attribute for XDP */
+ nla = (struct nlattr *)(((char *)&req)
+ + NLMSG_ALIGN(req.nh.nlmsg_len));
+ nla->nla_type = NLA_F_NESTED | 43/*IFLA_XDP*/;
+ nla->nla_len = NLA_HDRLEN;
+
+ /* add XDP fd */
+ nla_xdp = (struct nlattr *)((char *)nla + nla->nla_len);
+ nla_xdp->nla_type = 1/*IFLA_XDP_FD*/;
+ nla_xdp->nla_len = NLA_HDRLEN + sizeof(int);
+ memcpy((char *)nla_xdp + NLA_HDRLEN, &fd, sizeof(fd));
+ nla->nla_len += nla_xdp->nla_len;
+
+ /* if user passed in any flags, add those too */
+ if (flags) {
+ nla_xdp = (struct nlattr *)((char *)nla + nla->nla_len);
+ nla_xdp->nla_type = 3/*IFLA_XDP_FLAGS*/;
+ nla_xdp->nla_len = NLA_HDRLEN + sizeof(flags);
+ memcpy((char *)nla_xdp + NLA_HDRLEN, &flags, sizeof(flags));
+ nla->nla_len += nla_xdp->nla_len;
+ }
+
+ req.nh.nlmsg_len += NLA_ALIGN(nla->nla_len);
+
+ if (send(sock, &req, req.nh.nlmsg_len, 0) < 0) {
+ ret = -errno;
+ goto cleanup;
+ }
+
+ len = recv(sock, buf, sizeof(buf), 0);
+ if (len < 0) {
+ ret = -errno;
+ goto cleanup;
+ }
+
+ for (nh = (struct nlmsghdr *)buf; NLMSG_OK(nh, len);
+nh = NLMSG_NEXT(nh, len)) {
+ if (nh->nlmsg_pid != getpid()) {
+ ret = -LIBBPF_ERRNO__WRNGPID;
+ goto cleanup;
+ }
+ if (nh->nlmsg_seq != seq) {
+ ret = -LIBBPF_ERRNO__INVSEQ;
+ goto cleanup;
+ }
+ switch (nh->nlmsg_type) {
+ case NLMSG_ERROR:
+ err = (struct nlmsgerr *)NLMSG_DATA(nh);
+ if (!err->error)
+ continue;
+ ret = err->error;
+ goto cleanup;
+ case NLMSG_DONE:
+ break;
+ default:
+ break;
+ }
+ }
+
+ ret = 0;
+
+cleanup:
+ close(sock);
+ return ret;
+}
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 5aa45f89da93..931e98c097a8 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -106,6 +106,8 @@ static const char *libbpf_strerror_table[NR_ERRNO] = {
[ERRCODE_OFFSET(PROG2BIG)] = "Program too big",
[ERRCODE_OFFSET(KVER)] = "Incorrect kernel version",
[ERRCODE_OFFSET(PROGTYPE)] = "Kernel doesn't support this program
type",
+ [ERRCODE_OFFSET(WRNGPID)] = "Wrong pid in netlink message",
+ [ERRCODE_OFFSET(INVSEQ)]= "Invalid netlink sequence",
};
int libbpf_strerror(int err, char *buf, size_t size)
diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bp
[PATCH] virtio: make VIRTIO a menuconfig to ease disabling it all
No need to get into the submenu to disable all VIRTIO-related config entries. This makes it easier to disable all VIRTIO config options without entering the submenu. It will also enable one to see that en/dis-abled state from the outside menu. This is only intended to change menuconfig UI, not change the config dependencies. Signed-off-by: Vincent Legoll --- drivers/virtio/Kconfig | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig index cff773f15b7e..d485a63a8233 100644 --- a/drivers/virtio/Kconfig +++ b/drivers/virtio/Kconfig @@ -5,7 +5,10 @@ config VIRTIO bus, such as CONFIG_VIRTIO_PCI, CONFIG_VIRTIO_MMIO, CONFIG_RPMSG or CONFIG_S390_GUEST. -menu "Virtio drivers" +menuconfig VIRTIO_MENU + bool "Virtio drivers" + +if VIRTIO_MENU config VIRTIO_PCI tristate "PCI driver for virtio devices" @@ -79,4 +82,4 @@ config VIRTIO_MMIO_CMDLINE_DEVICES If unsure, say 'N'. -endmenu +endif # VIRTIO_MENU -- 2.14.1
[PATCH] dt-bindings: chosen: Document linux,initrd-{start,end}
These properties have been in use for a very long time (at least since
2005), but were never documented in chosen.txt.
Signed-off-by: Jonathan Neuschäfer
---
Documentation/devicetree/bindings/chosen.txt | 15 +++
1 file changed, 15 insertions(+)
diff --git a/Documentation/devicetree/bindings/chosen.txt
b/Documentation/devicetree/bindings/chosen.txt
index e3b13ea7d2ae..45e79172a646 100644
--- a/Documentation/devicetree/bindings/chosen.txt
+++ b/Documentation/devicetree/bindings/chosen.txt
@@ -120,3 +120,18 @@ e.g.
While this property does not represent a real hardware, the address
and the size are expressed in #address-cells and #size-cells,
respectively, of the root node.
+
+linux,initrd-start and linux,initrd-end
+---
+
+These properties hold the physical start and end address of an initrd that's
+loaded by the bootloader. Note that linux,initrd-start is inclusive, but
+linux,initrd-end is exclusive.
+e.g.
+
+/ {
+ chosen {
+ linux,initrd-start = <0x8200>;
+ linux,initrd-end = <0x8280>;
+ };
+};
--
2.15.0
[PATCH] remoteproc: make REMOTEPROC a menuconfig to ease disabling it all
No need to get into the submenu to disable all related config entries. This makes it easier to disable all REMOTEPROC config options without entering the submenu. It will also enable one to see that en/dis-abled state from the outside menu. This is only intended to change menuconfig UI, not change the config dependencies. Signed-off-by: Vincent Legoll --- drivers/remoteproc/Kconfig | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig index b609e1d3654b..29341c7d836d 100644 --- a/drivers/remoteproc/Kconfig +++ b/drivers/remoteproc/Kconfig @@ -1,4 +1,7 @@ -menu "Remoteproc drivers" +menuconfig REMOTEPROC_MENU + bool "Remoteproc drivers" + +if REMOTEPROC_MENU config REMOTEPROC tristate "Support for Remote Processor subsystem" @@ -10,8 +13,6 @@ config REMOTEPROC Support for remote processors (such as DSP coprocessors). These are mainly used on embedded systems. -if REMOTEPROC - config IMX_REMOTEPROC tristate "IMX6/7 remoteproc support" depends on SOC_IMX6SX || SOC_IMX7D @@ -140,6 +141,5 @@ config ST_REMOTEPROC config ST_SLIM_REMOTEPROC tristate -endif # REMOTEPROC +endif # REMOTEPROC_MENU -endmenu -- 2.14.1
[PATCH] nvme: make NVME a menuconfig to ease disabling it all
No need to get into the submenu to disable all related config entries. This makes it easier to disable all NVME config options without entering the submenu. It will also enable one to see that en/dis-abled state from the outside menu. This is only intended to change menuconfig UI, not change the config dependencies. Signed-off-by: Vincent Legoll --- drivers/nvme/Kconfig | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/nvme/Kconfig b/drivers/nvme/Kconfig index 04008e0bbe81..aad33a0dfbce 100644 --- a/drivers/nvme/Kconfig +++ b/drivers/nvme/Kconfig @@ -1,6 +1,9 @@ -menu "NVME Support" +menuconfig NVME_MENU + bool "NVME Support" + +if NVME_MENU source "drivers/nvme/host/Kconfig" source "drivers/nvme/target/Kconfig" -endmenu +endif # NVME_MENU -- 2.14.1
[PATCH] efi: make EFI a menuconfig to ease disabling it all
No need to get into the submenu to disable all related config entries. This makes it easier to disable all EFI config options without entering the submenu. It will also enable one to see that en/dis-abled state from the outside menu. This is only intended to change menuconfig UI, not change the config dependencies. Signed-off-by: Vincent Legoll --- drivers/firmware/efi/Kconfig | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig index 2b4c39fdfa91..8727b1aa8ef6 100644 --- a/drivers/firmware/efi/Kconfig +++ b/drivers/firmware/efi/Kconfig @@ -1,6 +1,9 @@ -menu "EFI (Extensible Firmware Interface) Support" +menuconfig EFI_MENU + bool "EFI (Extensible Firmware Interface) Support" depends on EFI +if EFI_MENU + config EFI_VARS tristate "EFI Variable Support via sysfs" depends on EFI @@ -81,9 +84,6 @@ config EFI_PARAMS_FROM_FDT the EFI runtime support gets system table address, memory map address, and other parameters from the device tree. -config EFI_RUNTIME_WRAPPERS - bool - config EFI_ARMSTUB bool @@ -161,7 +161,10 @@ config RESET_ATTACK_MITIGATION still contains secrets in RAM, booting another OS and extracting the secrets. -endmenu +endif # EFI_MENU + +config EFI_RUNTIME_WRAPPERS + bool config UEFI_CPER bool -- 2.14.1
[PATCH 1/3] kbuild: add LEX and YACC variables
Allow users to use their favorite lexer / parser generators.
This is useful for me to test various flex and bison versions.
Signed-off-by: Masahiro Yamada
---
Makefile | 4 +++-
scripts/Makefile.lib | 4 ++--
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index c988e46..83209d6 100644
--- a/Makefile
+++ b/Makefile
@@ -377,6 +377,8 @@ NM = $(CROSS_COMPILE)nm
STRIP = $(CROSS_COMPILE)strip
OBJCOPY= $(CROSS_COMPILE)objcopy
OBJDUMP= $(CROSS_COMPILE)objdump
+LEX= flex
+YACC = bison
AWK= awk
GENKSYMS = scripts/genksyms/genksyms
INSTALLKERNEL := installkernel
@@ -428,7 +430,7 @@ GCC_PLUGINS_CFLAGS :=
export ARCH SRCARCH CONFIG_SHELL HOSTCC HOSTCFLAGS CROSS_COMPILE AS LD CC
export CPP AR NM STRIP OBJCOPY OBJDUMP HOSTLDFLAGS HOST_LOADLIBES
-export MAKE AWK GENKSYMS INSTALLKERNEL PERL PYTHON UTS_MACHINE
+export MAKE LEX YACC AWK GENKSYMS INSTALLKERNEL PERL PYTHON UTS_MACHINE
export HOSTCXX HOSTCXXFLAGS LDFLAGS_MODULE CHECK CHECKFLAGS
export KBUILD_CPPFLAGS NOSTDINC_FLAGS LINUXINCLUDE OBJCOPYFLAGS LDFLAGS
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 1ca4dcd..ee528e3 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -193,7 +193,7 @@ ifdef REGENERATE_PARSERS
LEX_PREFIX = $(if $(LEX_PREFIX_${baseprereq}),$(LEX_PREFIX_${baseprereq}),yy)
quiet_cmd_flex = LEX $@
- cmd_flex = flex -o$@ -L -P $(LEX_PREFIX) $<
+ cmd_flex = $(LEX) -o$@ -L -P $(LEX_PREFIX) $<
.PRECIOUS: $(src)/%.lex.c_shipped
$(src)/%.lex.c_shipped: $(src)/%.l
@@ -204,7 +204,7 @@ $(src)/%.lex.c_shipped: $(src)/%.l
YACC_PREFIX = $(if
$(YACC_PREFIX_${baseprereq}),$(YACC_PREFIX_${baseprereq}),yy)
quiet_cmd_bison = YACC$@
- cmd_bison = bison -o$@ -t -l -p $(YACC_PREFIX) $<
+ cmd_bison = $(YACC) -o$@ -t -l -p $(YACC_PREFIX) $<
.PRECIOUS: $(src)/%.tab.c_shipped
$(src)/%.tab.c_shipped: $(src)/%.y
--
2.7.4
[PATCH 3/3] kconfig: generate lexer and parser during build instead of shipping
zconf.lex.c is generated by flex, zconf.tab.c by bison. Instead of running flex and bison during the kernel building, we conventionally version-control those artifacts with _shipped suffix. It is tedious to manually regenerate them every time we change the real sources, zconf.l and zconf.y. Remove the _shipped files and switch over to build-time generation of the intermediate C files. Signed-off-by: Masahiro Yamada --- scripts/kconfig/Makefile|1 + scripts/kconfig/zconf.lex.c_shipped | 2473 --- scripts/kconfig/zconf.tab.c_shipped | 2471 -- 3 files changed, 1 insertion(+), 4944 deletions(-) delete mode 100644 scripts/kconfig/zconf.lex.c_shipped delete mode 100644 scripts/kconfig/zconf.tab.c_shipped diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile index 297c1bf..61cdc5e 100644 --- a/scripts/kconfig/Makefile +++ b/scripts/kconfig/Makefile @@ -191,6 +191,7 @@ gconf-objs := gconf.o zconf.tab.o hostprogs-y := conf nconf mconf kxgettext qconf gconf +targets+= zconf.tab.c zconf.lex.c clean-files:= qconf.moc .tmp_qtcheck .tmp_gtkcheck clean-files+= zconf.tab.c zconf.lex.c gconf.glade.h clean-files += config.pot linux.pot diff --git a/scripts/kconfig/zconf.lex.c_shipped b/scripts/kconfig/zconf.lex.c_shipped deleted file mode 100644 index 37fdf61..000 --- a/scripts/kconfig/zconf.lex.c_shipped +++ /dev/null @@ -1,2473 +0,0 @@ - -#line 3 "scripts/kconfig/zconf.lex.c_shipped" - -#define YY_INT_ALIGNED short int - -/* A lexical scanner generated by flex */ - -#define yy_create_buffer zconf_create_buffer -#define yy_delete_buffer zconf_delete_buffer -#define yy_flex_debug zconf_flex_debug -#define yy_init_buffer zconf_init_buffer -#define yy_flush_buffer zconf_flush_buffer -#define yy_load_buffer_state zconf_load_buffer_state -#define yy_switch_to_buffer zconf_switch_to_buffer -#define yyin zconfin -#define yyleng zconfleng -#define yylex zconflex -#define yylineno zconflineno -#define yyout zconfout -#define yyrestart zconfrestart -#define yytext zconftext -#define yywrap zconfwrap -#define yyalloc zconfalloc -#define yyrealloc zconfrealloc -#define yyfree zconffree - -#define FLEX_SCANNER -#define YY_FLEX_MAJOR_VERSION 2 -#define YY_FLEX_MINOR_VERSION 5 -#define YY_FLEX_SUBMINOR_VERSION 35 -#if YY_FLEX_SUBMINOR_VERSION > 0 -#define FLEX_BETA -#endif - -/* First, we deal with platform-specific or compiler-specific issues. */ - -/* begin standard C headers. */ -#include -#include -#include -#include - -/* end standard C headers. */ - -/* flex integer type definitions */ - -#ifndef FLEXINT_H -#define FLEXINT_H - -/* C99 systems have . Non-C99 systems may or may not. */ - -#if defined (__STDC_VERSION__) && __STDC_VERSION__ >= 199901L - -/* C99 says to define __STDC_LIMIT_MACROS before including stdint.h, - * if you want the limit (max/min) macros for int types. - */ -#ifndef __STDC_LIMIT_MACROS -#define __STDC_LIMIT_MACROS 1 -#endif - -#include -typedef int8_t flex_int8_t; -typedef uint8_t flex_uint8_t; -typedef int16_t flex_int16_t; -typedef uint16_t flex_uint16_t; -typedef int32_t flex_int32_t; -typedef uint32_t flex_uint32_t; -#else -typedef signed char flex_int8_t; -typedef short int flex_int16_t; -typedef int flex_int32_t; -typedef unsigned char flex_uint8_t; -typedef unsigned short int flex_uint16_t; -typedef unsigned int flex_uint32_t; - -/* Limits of integral types. */ -#ifndef INT8_MIN -#define INT8_MIN (-128) -#endif -#ifndef INT16_MIN -#define INT16_MIN (-32767-1) -#endif -#ifndef INT32_MIN -#define INT32_MIN (-2147483647-1) -#endif -#ifndef INT8_MAX -#define INT8_MAX (127) -#endif -#ifndef INT16_MAX -#define INT16_MAX (32767) -#endif -#ifndef INT32_MAX -#define INT32_MAX (2147483647) -#endif -#ifndef UINT8_MAX -#define UINT8_MAX (255U) -#endif -#ifndef UINT16_MAX -#define UINT16_MAX (65535U) -#endif -#ifndef UINT32_MAX -#define UINT32_MAX (4294967295U) -#endif - -#endif /* ! C99 */ - -#endif /* ! FLEXINT_H */ - -#ifdef __cplusplus - -/* The "const" storage-class-modifier is valid. */ -#define YY_USE_CONST - -#else /* ! __cplusplus */ - -/* C99 requires __STDC__ to be defined as 1. */ -#if defined (__STDC__) - -#define YY_USE_CONST - -#endif /* defined (__STDC__) */ -#endif /* ! __cplusplus */ - -#ifdef YY_USE_CONST -#define yyconst const -#else -#define yyconst -#endif - -/* Returned upon end-of-file. */ -#define YY_NULL 0 - -/* Promotes a possibly negative, possibly signed char to an unsigned - * integer for use as an array index. If the signed char is negative, - * we want to instead treat it as an 8-bit unsigned char, hence the - * double cast. - */ -#define YY_SC_TO_UI(c) ((unsigned int) (unsigned char) c) - -/* Enter a start condition. This macro really ought to take a parameter, - * but we do it the disgusting crufty way forced on u
[PATCH 0/3] kbuild,kconfig: generate lexer/parser C files instead of copying _shipped files
In Linux build system convention, pre-generated files are version- controlled with a "_shipped" suffix. During the kernel building, they are simply shipped (copied) removing the suffix. >From users' point of view, this approach can reduce external tool dependency for the kernel build, >From developers point of view, it is tedious to manually regenerate such artifacts. In fact, we see several patches to regenerate _shipped files. They are noise commits. When we update a *.y or *.l file, it would be better to update the corresponding _shipped file in the same commit, but it is painful. If you use a different version of flex/bison, it will produce lots of irrelevant diffs. We could update _shipped files after adding various changes to the real sources, but it is not very nice for a git-bisect'ability. In case of a problem, "git bisect" would point to the commit updating _shipped files, but the root cause would be in another commit that has changed the corresponding .l or .y files. Some months ago, I sent RFC patches to run flex, bison, and gperf during the build. https://lkml.org/lkml/2017/8/19/49 Basically Linus agreed this, but he found a problem in gperf, then use of gperf in kernel was removed. It took some months for me to come back. This time, I installed various versions of flex/bison on my machine, and tested them more carefully. My current motivation is in Kconfig. There are several Kconfig patches touching *.y and *.l (and Linus suggested another improvement for Kconfig) so I want to remove zconf.lex.c_shipped and zconf.tab.c_shipped now. Kconfig has no problem for this switch. dtc and genksyms will be taken care of later because both of them are having shift/reduce conflicts now. The ambiguous grammar in dtc has been fixed in upstream, but not reflected to kernel yet. We can proceed migration in sub-system base. Masahiro Yamada (3): kbuild: add LEX and YACC variables kbuild: prepare to remove C files pre-generated by flex and bison kconfig: generate lexer and parser during build instead of shipping Documentation/process/changes.rst | 25 + Makefile|4 +- scripts/Makefile.lib| 24 +- scripts/kconfig/Makefile|1 + scripts/kconfig/zconf.lex.c_shipped | 2473 --- scripts/kconfig/zconf.tab.c_shipped | 2471 -- 6 files changed, 48 insertions(+), 4950 deletions(-) delete mode 100644 scripts/kconfig/zconf.lex.c_shipped delete mode 100644 scripts/kconfig/zconf.tab.c_shipped -- 2.7.4
[PATCH 2/3] kbuild: prepare to remove C files pre-generated by flex and bison
In Linux build system convention, pre-generated files are version-
controlled with a "_shipped" suffix. During the kernel building,
they are simply shipped (copied) removing the suffix.
This approach can reduce external tool dependency for the kernel build,
but it is tedious to manually regenerate such artifacts from developers'
point of view. (We need to do "make REGENERATE_PARSERS=1" every time
we touch real source files such as *.l, *.y)
Some months ago, I sent out RFC patches to run flex, bison, and gperf
during the build.
In the review and test, Linus noticed gperf-3.1 had changed the lookup
function prototype. Then, the use of gperf in kernel was entirely
removed by commit bb3290d91695 ("Remove gperf usage from toolchain").
I tested several versions of flex and bison, and I was not hit by any
compatibility issue except a flaw in flex-2.6.3; if you generate lexer
for dtc and genksyms with flex-2.6.3, you will see "yywrap redefined"
warning. This was not intentional, but a bug fixed by flex-2.6.4.
Otherwise, flex and bison look fairly stable for a long time.
This commit prepares some build rules to start removing the _shipped
files. Also, document minimal requirement for flex and bison.
Rationale for the minimal version:
The -Wmissing-prototypes option of GCC reports "no previous prototype"
warnings for lexers generated by flex-2.5.34, so I chose 2.5.35 as the
required version for flex. Flex-2.5.35 was released in 2008. Bison
looked more stable. I did not see any problem with bison-2.0, released
in 2004. I did not test bison-1.x, but bison-2.0 should be old enough.
Tested flex versions:
2.5.35
2.5.36
2.5.37
2.5.39
2.6.0
2.6.1
2.6.2
2.6.3 (*)
2.6.4
(*) flex-2.6.3 causes "yywrap redefined" warning
Tested bison versions:
2.0
2.1
2.2
2.3
2.4
2.4.1
2.5.1
2.6
2.6.1
2.6.2
2.6.3
2.6.4
2.6.5
2.7
2.7.1
3.0
3.0.1
3.0.2
3.0.3
3.0.4
Signed-off-by: Masahiro Yamada
---
Documentation/process/changes.rst | 25 +
scripts/Makefile.lib | 20 +---
2 files changed, 42 insertions(+), 3 deletions(-)
diff --git a/Documentation/process/changes.rst
b/Documentation/process/changes.rst
index 560beae..fc9c7c3 100644
--- a/Documentation/process/changes.rst
+++ b/Documentation/process/changes.rst
@@ -32,6 +32,8 @@ you probably needn't concern yourself with isdn4k-utils.
GNU C 3.2 gcc --version
GNU make 3.81 make --version
binutils 2.20 ld -v
+flex 2.5.35 flex --version
+bison 2.0 bison --version
util-linux 2.10ofdformat --version
module-init-tools 0.9.10 depmod -V
e2fsprogs 1.41.4 e2fsck -V
@@ -79,6 +81,19 @@ The build system has, as of 4.13, switched to using thin
archives (`ar T`)
rather than incremental linking (`ld -r`) for built-in.o intermediate steps.
This requires binutils 2.20 or newer.
+Flex
+
+
+Since Linux 4.16, the build system generates lexical analisers
+during build. This requires flex 2.5.35 or later.
+
+
+Bison
+-
+
+Since Linux 4.16, the build system generates parsers
+during build. This requires bison 2.0 or later.
+
Perl
@@ -333,6 +348,16 @@ Binutils
-
+
+Bison
+-
+
+-
Assalamu`Alaikum.
Dear Sir/Madam. Assalamu`Alaikum. I am Dr mohammad ouattara, I have ($14.6 Million us dollars) to transfer into your account, I will send you more details about this deal and the procedures to follow when I receive a positive response from you, Have a great day, Dr mohammad ouattara.
[PATCH] Documentation: mono: Update links and s/CVS/Git/
The URLs in mono.rst redirect to pages on www.mono-project.com, so let's update them. I took the liberty to update the compilation instructions to the Linux-specific version, because readers of the kernel documentation will most likely use Linux. Signed-off-by: Jonathan Neuschäfer --- Documentation/admin-guide/mono.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/admin-guide/mono.rst b/Documentation/admin-guide/mono.rst index cdddc099af64..59e6d59f0ed9 100644 --- a/Documentation/admin-guide/mono.rst +++ b/Documentation/admin-guide/mono.rst @@ -9,14 +9,14 @@ This will allow you to execute Mono-based .NET binaries just like any other program after you have done the following: 1) You MUST FIRST install the Mono CLR support, either by downloading - a binary package, a source tarball or by installing from CVS. Binary + a binary package, a source tarball or by installing from Git. Binary packages for several distributions can be found at: - http://go-mono.com/download.html + http://www.mono-project.com/download/ Instructions for compiling Mono can be found at: - http://www.go-mono.com/compiling.html + http://www.mono-project.com/docs/compiling-mono/linux/ Once the Mono CLR support has been installed, just check that ``/usr/bin/mono`` (which could be located elsewhere, for example -- 2.15.0
[PATCH] lib/usercopy: fix sparse errors
CHECK lib/usercopy.c
lib/usercopy.c:26:13: warning: incorrect type in argument 1 (different address
spaces)
lib/usercopy.c:26:13:expected void const volatile [noderef]
*
lib/usercopy.c:26:13:got void *to
lib/usercopy.c:27:34: warning: incorrect type in argument 1 (different address
spaces)
lib/usercopy.c:27:34:expected void const volatile *p
lib/usercopy.c:27:34:got void const [noderef] *from
lib/usercopy.c:28:38: warning: incorrect type in argument 1 (different address
spaces)
lib/usercopy.c:28:38:expected void [noderef] *to
lib/usercopy.c:28:38:got void *to
lib/usercopy.c:28:42: warning: incorrect type in argument 2 (different address
spaces)
lib/usercopy.c:28:42:expected void const *from
lib/usercopy.c:28:42:got void const [noderef] *from
lib/usercopy.c:23:15: error: symbol '_copy_to_user' redeclared with different
type (originally declared at ./include/linux/uaccess.h:140) - incompatible
argument 1 (different address spaces)
CC lib/usercopy.o
Fixes: d597580d37377 ("generic ...copy_..._user primitives")
Signed-off-by: Christophe Leroy
---
lib/usercopy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/usercopy.c b/lib/usercopy.c
index 15e2e6f..3744b2a 100644
--- a/lib/usercopy.c
+++ b/lib/usercopy.c
@@ -20,7 +20,7 @@ EXPORT_SYMBOL(_copy_from_user);
#endif
#ifndef INLINE_COPY_TO_USER
-unsigned long _copy_to_user(void *to, const void __user *from, unsigned long n)
+unsigned long _copy_to_user(void __user *to, const void *from, unsigned long n)
{
might_fault();
if (likely(access_ok(VERIFY_WRITE, to, n))) {
--
2.2.2
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel
antivirus Avast.
https://www.avast.com/antivirus
[PATCH] make RUNTIME_TESTS a menuconfig to ease disabling it all
No need to get into the submenu to disable all related config entries. This makes it easier to disable all RUNTIME_TESTS config options without entering the submenu. It will also enable one to see that en/dis-abled state from the outside menu. This is only intended to change menuconfig UI, not change the config dependencies. Signed-off-by: Vincent Legoll --- lib/Kconfig.debug | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 947d3e2ed5c2..9436714254b7 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -1660,7 +1660,10 @@ config DMA_API_DEBUG If unsure, say N. -menu "Runtime Testing" +menuconfig RUNTIME_TESTING_MENU + bool "Runtime Testing" + +if RUNTIME_TESTING_MENU config LKDTM tristate "Linux Kernel Dump Test Tool Module" @@ -1948,7 +1951,7 @@ config TEST_DEBUG_VIRTUAL If unsure, say N. -endmenu # runtime tests +endif # RUNTIME_TESTING_MENU config MEMTEST bool "Memtest" -- 2.14.1
Re: [PATCH v3 net-next 4/4] bpftool: implement cgroup bpf operations
On 12/8/17 4:46 PM, Jakub Kicinski wrote:
>> +argc -= 2;
>> +argv = &argv[2];
>> +prog_fd = prog_parse_fd(&argc, &argv);
>> +if (prog_fd < 0)
>> +goto exit_cgroup;
>> +
>> +for (i = 0; i < argc; i++) {
>> +if (strcmp(argv[i], "allow_multi") == 0) {
>> +attach_flags |= BPF_F_ALLOW_MULTI;
>> +} else if (strcmp(argv[i], "allow_override") == 0) {
>> +attach_flags |= BPF_F_ALLOW_OVERRIDE;
>
> I don't feel about this strongly but as I said I was trying to follow
> iproute2's conventions, and it allows aliasing. So if you type "ip a"
> it will give you the first thing that starts with a, not necessarily
> alphabetically, more likely in order of usefulness or order in which
> things were added. IOW if "allow_" selects "allow_mutli" that's what I
> would actually expect it to do..
>
> Maybe others disagree?
The iproute2 syntax is very user friendly, and I agree with following
the conventions.
With respect to the attach flags, allow_y is a lot to type, but
having 'a .. allow_' mean one flag over the other is going to be
confusing. Perhaps dropping the 'allow_' prefix in favor of just 'multi'
and 'override' and doing prefix match on it? User commands do not need
to follow flag names precisely.
Re: [PATCH] kconfig: Remove menu_end_entry()
2017-10-05 11:36 GMT+09:00 Ulf Magnusson : > menu_end_entry() is empty and completely unused as far as I can tell: > > $ git log -G menu_end_entry --oneline > a02f057 [PATCH] kconfig: improve error handling in the parser > 1da177e Linux-2.6.12-rc2 > > Last one is the initial Git commit, where menu_end_entry() is empty as > well. I couldn't find anything that redefined it on Google either. > > It might be a debugging helper for setting a breakpoint after each > config, menuconfig, and comment is parsed. IMO it hurts more than it > helps in that case by making the parsing code look more complicated at a > glance than it really is, and I suspect it doesn't get used much. > > Tested by running the Kconfiglib test suite, which indirectly verifies > that the .config files generated by the C implementation for each > defconfig file in the kernel stays the same. > > Signed-off-by: Ulf Magnusson > --- Removing menu_end_entry() should be OK, but it is tedious to sync *.y and *_shipped. I'd like to apply v2 (https://patchwork.kernel.org/patch/9992029/) on top of my patch (https://patchwork.kernel.org/patch/10103743/) -- Best Regards Masahiro Yamada
[PATCH] make "RCU Debugging" a menuconfig to ease disabling it all
No need to get into the submenu to disable all related config entries. This makes it easier to disable all "RCU Debugging" config options without entering the submenu. It will also enable one to see that en/dis-abled state from the outside menu. This is only intended to change menuconfig UI, not change the config dependencies. Signed-off-by: Vincent Legoll --- kernel/rcu/Kconfig.debug | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/kernel/rcu/Kconfig.debug b/kernel/rcu/Kconfig.debug index 0ec7d1d33a14..f709bc50ac23 100644 --- a/kernel/rcu/Kconfig.debug +++ b/kernel/rcu/Kconfig.debug @@ -2,7 +2,10 @@ # RCU-related debugging configuration options # -menu "RCU Debugging" +menuconfig RCUDEBUG_MENU + bool "RCU Debugging" + +if RCUDEBUG_MENU config PROVE_RCU def_bool PROVE_LOCKING @@ -79,4 +82,4 @@ config RCU_EQS_DEBUG Say N here if you need ultimate kernel/user switch latencies Say Y if you are unsure -endmenu # "RCU Debugging" +endif # RCUDEBUG_MENU -- 2.14.1
Re: [PATCH net-next] libbpf: add function to setup XDP
On 12/9/17 7:43 AM, Eric Leblond wrote:
> + /* started nested attribute for XDP */
> + nla = (struct nlattr *)(((char *)&req)
> + + NLMSG_ALIGN(req.nh.nlmsg_len));
> + nla->nla_type = NLA_F_NESTED | 43/*IFLA_XDP*/;
as a part of the move into libbpf can the magic numbers be replaced by
the names directly and there as a comment?
There are more below.
> + nla->nla_len = NLA_HDRLEN;
> +
> + /* add XDP fd */
> + nla_xdp = (struct nlattr *)((char *)nla + nla->nla_len);
> + nla_xdp->nla_type = 1/*IFLA_XDP_FD*/;
> + nla_xdp->nla_len = NLA_HDRLEN + sizeof(int);
> + memcpy((char *)nla_xdp + NLA_HDRLEN, &fd, sizeof(fd));
> + nla->nla_len += nla_xdp->nla_len;
> +
> + /* if user passed in any flags, add those too */
> + if (flags) {
> + nla_xdp = (struct nlattr *)((char *)nla + nla->nla_len);
> + nla_xdp->nla_type = 3/*IFLA_XDP_FLAGS*/;
> + nla_xdp->nla_len = NLA_HDRLEN + sizeof(flags);
> + memcpy((char *)nla_xdp + NLA_HDRLEN, &flags, sizeof(flags));
> + nla->nla_len += nla_xdp->nla_len;
> + }
> +
Re: [PATCH] kconfig: fix relational operators for bool and tristate symbols
2017-12-07 0:40 GMT+09:00 Nicolas Pitre : > > Ping. > I see several kconfig patches queued up. Patches from Ulf Magnusson have been waiting for longer, so I will check them first, and I will come back to this as soon as possible. -- Best Regards Masahiro Yamada
[GIT PULL] KVM fixes for v4.15-rc3
Linus, The following changes since commit ae64f9bd1d3621b5e60d7363bc20afb46aede215: Linux 4.15-rc2 (2017-12-03 11:01:47 -0500) are available in the Git repository at: git://git.kernel.org/pub/scm/virt/kvm/kvm for-linus for you to fetch changes up to b1394e745b9453dcb5b0671c205b770e87dedb87: KVM: x86: fix APIC page invalidation (2017-12-06 16:10:34 +0100) KVM fixes for v4.15-rc3 ARM: * A number of issues in the vgic discovered using SMATCH * A bit one-off calculation in out stage base address mask (32-bit and 64-bit) * Fixes to single-step debugging instructions that trap for other reasons such as MMMIO aborts * Printing unavailable hyp mode as error * Potential spinlock deadlock in the vgic * Avoid calling vgic vcpu free more than once * Broken bit calculation for big endian systems s390: * SPDX tags * Fence storage key accesses from problem state * Make sure that irq_state.flags is not used in the future x86: * Intercept port 0x80 accesses to prevent host instability (CVE) * Use userspace FPU context for guest FPU (mainly an optimization that fixes a double use of kernel FPU) * Do not leak one page per module load * Flush APIC page address cache from MMU invalidation notifiers Alex Bennée (5): KVM: arm/arm64: debug: Introduce helper for single-step kvm: arm64: handle single-stepping trapped instructions kvm: arm64: handle single-step of userspace mmio instructions kvm: arm64: handle single-step during SError exceptions kvm: arm64: handle single-step of hyp emulated mmio instructions Andre Przywara (1): KVM: arm/arm64: VGIC: extend !vgic_is_initialized guard Andrew Honig (1): KVM: VMX: remove I/O port 0x80 bypass on Intel hosts Andrew Jones (1): KVM: arm/arm64: kvm_arch_destroy_vm cleanups Ard Biesheuvel (1): kvm: arm: don't treat unavailable HYP mode as an error Christian Borntraeger (1): KVM: s390: mark irq_state.flags as non-usable Christoffer Dall (3): KVM: arm/arm64: Don't enable/disable physical timer access on VHE KVM: arm/arm64: Avoid attempting to load timer vgic state without a vgic KVM: arm/arm64: Fix broken GICH_ELRSR big endian conversion Greg Kroah-Hartman (2): KVM: s390: add SPDX identifiers to the remaining files KVM: s390: Remove redundant license text Janosch Frank (1): KVM: s390: Fix skey emulation permission check Jim Mattson (1): KVM: VMX: fix page leak in hardware_setup() Kristina Martsenko (1): arm64: KVM: fix VTTBR_BADDR_MASK BUG_ON off-by-one Marc Zyngier (7): KVM: arm/arm64: vgic-irqfd: Fix MSI entry allocation KVM: arm/arm64: vgic: Preserve the revious read from the pending table KVM: arm/arm64: vgic-its: Preserve the revious read from the pending table KVM: arm/arm64: vgic-its: Check result of allocation before use KVM: arm/arm64: vgic-v4: Only perform an unmap for valid vLPIs arm: KVM: Fix VTTBR_BADDR_MASK BUG_ON off-by-one KVM: arm/arm64: Fix spinlock acquisition in vgic_set_owner Radim Krčmář (3): Merge tag 'kvm-arm-fixes-for-v4.15-1' of git://git.kernel.org/.../kvmarm/kvmarm Merge tag 'kvm-s390-master-4.15-1' of git://git.kernel.org/.../kvms390/linux KVM: x86: fix APIC page invalidation Rik van Riel (2): x86,kvm: move qemu/guest FPU switching out to vcpu_run x86,kvm: remove KVM emulator get_fpu / put_fpu Documentation/virtual/kvm/api.txt | 15 +++-- arch/arm/include/asm/kvm_arm.h | 3 +- arch/arm/include/asm/kvm_host.h| 5 +++ arch/arm64/include/asm/kvm_arm.h | 3 +- arch/arm64/include/asm/kvm_host.h | 1 + arch/arm64/kvm/debug.c | 21 + arch/arm64/kvm/handle_exit.c | 57 +- arch/arm64/kvm/hyp/switch.c| 37 +- arch/s390/kvm/Makefile | 5 +-- arch/s390/kvm/diag.c | 5 +-- arch/s390/kvm/gaccess.h| 5 +-- arch/s390/kvm/guestdbg.c | 5 +-- arch/s390/kvm/intercept.c | 5 +-- arch/s390/kvm/interrupt.c | 5 +-- arch/s390/kvm/irq.h| 5 +-- arch/s390/kvm/kvm-s390.c | 11 +++ arch/s390/kvm/kvm-s390.h | 5 +-- arch/s390/kvm/priv.c | 16 ++ arch/s390/kvm/sigp.c | 5 +-- arch/s390/kvm/vsie.c | 5 +-- arch/x86/include/asm/kvm_emulate.h | 2 -- arch/x86/include/asm/kvm_host.h| 16 ++ arch/x86/kvm/emulate.c | 24 --- arch/x86/kvm/vmx.c | 6 arch/x86/kvm/x86.c | 63 +++--- include/kvm/arm_arch_timer.h | 3 -- include/linux/kvm_host.h | 2 +- include/uapi/linux/kvm.h | 4 +-- virt/kvm/arm/arch_timer.c | 11 +++ virt
Re: [PATCH 2/3] kbuild: prepare to remove C files pre-generated by flex and bison
On 12/09/2017 08:02 AM, Masahiro Yamada wrote: > > Signed-off-by: Masahiro Yamada > --- > > Documentation/process/changes.rst | 25 + > scripts/Makefile.lib | 20 +--- > 2 files changed, 42 insertions(+), 3 deletions(-) > > diff --git a/Documentation/process/changes.rst > b/Documentation/process/changes.rst > index 560beae..fc9c7c3 100644 > --- a/Documentation/process/changes.rst > +++ b/Documentation/process/changes.rst > @@ -32,6 +32,8 @@ you probably needn't concern yourself with isdn4k-utils. > GNU C 3.2 gcc --version > GNU make 3.81 make --version > binutils 2.20 ld -v > +flex 2.5.35 flex --version > +bison 2.0 bison --version > util-linux 2.10ofdformat --version > module-init-tools 0.9.10 depmod -V > e2fsprogs 1.41.4 e2fsck -V > @@ -79,6 +81,19 @@ The build system has, as of 4.13, switched to using thin > archives (`ar T`) > rather than incremental linking (`ld -r`) for built-in.o intermediate steps. > This requires binutils 2.20 or newer. > > +Flex > + > + > +Since Linux 4.16, the build system generates lexical analisers analyzers or analysers > +during build. This requires flex 2.5.35 or later. thanks. -- ~Randy
Re: [PATCH 4.14 00/75] 4.14.5-stable review
On Fri, Dec 08, 2017 at 12:03:34PM -0800, Kevin Hilman wrote: > kernelci.org bot writes: > > > stable-rc/linux-4.14.y boot: 142 boots: 1 failed, 127 passed with 14 > > offline (v4.14.4-76-gf91a57b206e0) > > > > Full Boot Summary: > > https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.14.y/kernel/v4.14.4-76-gf91a57b206e0/ > > Full Build Summary: > > https://kernelci.org/build/stable-rc/branch/linux-4.14.y/kernel/v4.14.4-76-gf91a57b206e0/ > > > > Tree: stable-rc > > Branch: linux-4.14.y > > Git Describe: v4.14.4-76-gf91a57b206e0 > > Git Commit: f91a57b206e0ca82c4d3f13372c392e3b374e1ce > > Git URL: > > http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > Tested: 76 unique boards, 23 SoC families, 18 builds out of 189 > > > > Boot Regressions Detected: > > > > arm64: > > > > defconfig: > > meson-gxbb-p200: > > TL;DR; All is well. > > Re-ran this one and it's fine. Great, thanks for letting me know. greg k-h
Re: kernel BUG at net/core/skbuff.c:LINE! (2)
On Sat, 2017-12-09 at 19:23 +0800, Xin Long wrote:
> On Fri, Dec 8, 2017 at 4:45 PM, Xin Long
> wrote:
> > On Fri, Dec 8, 2017 at 4:16 PM, syzbot
> > > .com>
> > wrote:
> > > syzkaller has found reproducer for the following crash on
> > > 82bcf1def3b5f1251177ad47c44f7e17af039b4b
> > > git://git.cmpxchg.org/linux-mmots.git/master
> > > compiler: gcc (GCC) 7.1.1 20170620
> > > .config is attached
> > > Raw console output is attached.
> > >
> > > syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> > > for information about syzkaller reproducers
> > >
> > >
> > > skbuff: skb_over_panic: text:10b86b8d len:196 put:20
> > > head:3b477e60 data:0e85441e tail:0xd4 end:0xc0
> > > dev:lo
> > > [ cut here ]
> > > kernel BUG at net/core/skbuff.c:104!
> > > invalid opcode: [#1] SMP KASAN
> > > Dumping ftrace buffer:
> > > (ftrace buffer empty)
> > > Modules linked in:
> > > CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.15.0-rc2-mm1+ #39
> > > Hardware name: Google Google Compute Engine/Google Compute
> > > Engine, BIOS
> > > Google 01/01/2011
> > > RIP: 0010:skb_panic+0x15c/0x1f0 net/core/skbuff.c:100
> > > RSP: 0018:8801db307508 EFLAGS: 00010286
> > > RAX: 0082 RBX: 8801c517e840 RCX:
> > > RDX: 0082 RSI: 11003b660e61 RDI: ed003b660e95
> > > RBP: 8801db307570 R08: 11003b660e23 R09:
> > > R10: R11: R12: 85bd4020
> > > R13: 84754ed2 R14: 0014 R15: 8801c4e26540
> > > FS: () GS:8801db30()
> > > knlGS:
> > > CS: 0010 DS: ES: CR0: 80050033
> > > CR2: 00463610 CR3: 0001c6698000 CR4: 001406e0
> > > DR0: DR1: DR2:
> > > DR3: DR6: fffe0ff0 DR7: 0400
> > > Call Trace:
> > >
> > > skb_over_panic net/core/skbuff.c:109 [inline]
> > > skb_put+0x181/0x1c0 net/core/skbuff.c:1694
> > > add_grhead.isra.24+0x42/0x3b0 net/ipv6/mcast.c:1695
> > > add_grec+0xa55/0x1060 net/ipv6/mcast.c:1817
> > > mld_send_cr net/ipv6/mcast.c:1903 [inline]
> > > mld_ifc_timer_expire+0x4d2/0x770 net/ipv6/mcast.c:2448
> > > call_timer_fn+0x23b/0x840 kernel/time/timer.c:1320
> > > expire_timers kernel/time/timer.c:1357 [inline]
> > > __run_timers+0x7e1/0xb60 kernel/time/timer.c:1660
> > > run_timer_softirq+0x4c/0xb0 kernel/time/timer.c:1686
> > > __do_softirq+0x29d/0xbb2 kernel/softirq.c:285
> > > invoke_softirq kernel/softirq.c:365 [inline]
> > > irq_exit+0x1d3/0x210 kernel/softirq.c:405
> > > exiting_irq arch/x86/include/asm/apic.h:540 [inline]
> > > smp_apic_timer_interrupt+0x16b/0x700
> > > arch/x86/kernel/apic/apic.c:1052
> > > apic_timer_interrupt+0xa9/0xb0 arch/x86/entry/entry_64.S:920
> > >
> > > RIP: 0010:native_safe_halt+0x6/0x10
> > > arch/x86/include/asm/irqflags.h:54
> > > RSP: 0018:8801d9f97da8 EFLAGS: 0282 ORIG_RAX:
> > > ff11
> > > RAX: dc00 RBX: 11003b3f2fb8 RCX:
> > > RDX: 10c59734 RSI: 0001 RDI: 862cb9a0
> > > RBP: 8801d9f97da8 R08: R09:
> > > R10: R11: R12: 0001
> > > R13: 8801d9f97e60 R14: 869eb920 R15:
> > > arch_safe_halt arch/x86/include/asm/paravirt.h:93 [inline]
> > > default_idle+0xbf/0x430 arch/x86/kernel/process.c:355
> > > arch_cpu_idle+0xa/0x10 arch/x86/kernel/process.c:346
> > > default_idle_call+0x36/0x90 kernel/sched/idle.c:98
> > > cpuidle_idle_call kernel/sched/idle.c:156 [inline]
> > > do_idle+0x24a/0x3b0 kernel/sched/idle.c:246
> > > cpu_startup_entry+0x18/0x20 kernel/sched/idle.c:351
> > > start_secondary+0x330/0x460 arch/x86/kernel/smpboot.c:277
> > > secondary_startup_64+0xa5/0xb0 arch/x86/kernel/head_64.S:237
> > > Code: 03 0f b6 04 01 84 c0 74 04 3c 03 7e 20 8b 4b 78 41 57 48 c7
> > > c7 a0 38
> > > bd 85 52 56 4c 89 ea 41 50 4c 89 e6 45 89 f0 e8 0c b6 3d fd <0f>
> > > 0b 4c 89 4d
> > > b8 4c 89 45 c0 48 89 75 c8 48 89 55 d0 e8 7d 93
> > > RIP: skb_panic+0x15c/0x1f0 net/core/skbuff.c:100 RSP:
> > > 8801db307508
> > > ---[ end trace 941a8a0f633e271f ]---
> > >
> >
> > This isn't a sctp problem, but mld's, seems when lo's mtu became 0,
> > it allocs a skb without enough space in add_grec():
> > if (AVAILABLE(skb) < sizeof(*psrc) +
> > first*sizeof(struct mld2_grec)) {
> > if (truncate && !first)
> > break; /* truncate these */
> > if (pgr)
> > pgr->grec_nsrcs = htons(scount);
> > if (skb)
> > mld_sendpack(skb);
> > skb = mld_newpack(idev, dev->mtu); <---
> >
> > I will check this for sure
Re: [PATCH v4 72/73] xfs: Convert mru cache to XArray
On Sat, 2017-12-09 at 09:36 +1100, Dave Chinner wrote: > 1. Using lockdep_set_novalidate_class() for anything other > than device->mutex will throw checkpatch warnings. Nice. (*) [] > (*) checkpatch.pl is considered mostly harmful round here, too, > but that's another rant How so? > (**) the frequent occurrence of "core code/devs aren't held to the > same rules/standard as everyone else" is another rant I have stored > up for a rainy day. Yeah. I wouldn't mind reading that one... Rainy season is starting right about now here too.
Re: [PATCH 4.4 29/49] nfs: Dont take a reference on fl->fl_file for LOCK operation
On Fri, Dec 08, 2017 at 04:18:58AM +, Ben Hutchings wrote:
> On Thu, 2017-12-07 at 14:07 +0100, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch. If anyone has any objections, please let me know.
> >
> > --
> >
> > From: Benjamin Coddington
> >
> >
> > [ Upstream commit 4b09ec4b14a168bf2c687e1f598140c3c11e9222 ]
> >
> > I have reports of a crash that look like __fput() was called twice for
> > a NFSv4.0 file. It seems possible that the state manager could try to
> > reclaim a lock and take a reference on the fl->fl_file at the same time the
> > file is being released if, during the close(), a signal interrupts the wait
> > for outstanding IO while removing locks which then skips the removal
> > of that lock.
> >
> > Since 83bfff23e9ed ("nfs4: have do_vfs_lock take an inode pointer") has
> > removed the need to traverse fl->fl_file->f_inode in nfs4_lock_done(),
> > taking that reference is no longer necessary.
> [...]
>
> No objection to this in 4.4, but that other commit only went into 4.2
> so this fix doesn't look suitable for 3.18.
Good catch, now dropped, thanks.
greg k-h
Re: [PATCH 4.4 33/49] net: sctp: fix array overrun read on sctp_timer_tbl
On Fri, Dec 08, 2017 at 04:34:51AM +, Ben Hutchings wrote:
> On Thu, 2017-12-07 at 14:07 +0100, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch. If anyone has any objections, please let me
> > know.
> >
> > --
> >
> > From: Colin Ian King
> >
> >
> > [ Upstream commit 0e73fc9a56f22f2eec4d2b2910c649f7af67b74d ]
> >
> > The comparison on the timeout can lead to an array overrun
> > read on sctp_timer_tbl because of an off-by-one error. Fix
> > this by using < instead of <= and also compare to the array
> > size rather than SCTP_EVENT_TIMEOUT_MAX.
> >
> > Fixes CoverityScan CID#1397639 ("Out-of-bounds read")
>
> SCTP_EVENT_TIMEOUT_MAX is one less than the array size, so the bounds
> check using <= was correct. This is cleanup, not a bug fix.
Ah, I was wondering why no one caught this earlier for submission.
Coverity isn't the smartest tool at times :(
thanks,
greg k-h
Re: [PATCH 4.4 00/49] 4.4.105-stable review
On Fri, Dec 08, 2017 at 12:00:47PM -0800, Kevin Hilman wrote: > kernelci.org bot writes: > > > stable-rc/linux-4.4.y boot: 122 boots: 2 failed, 106 passed with 12 > > offline, 2 conflicts (v4.4.104-50-gffc1d3fcd46a) > > > > Full Boot Summary: > > https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.104-50-gffc1d3fcd46a/ > > Full Build Summary: > > https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.104-50-gffc1d3fcd46a/ > > > > Tree: stable-rc > > Branch: linux-4.4.y > > Git Describe: v4.4.104-50-gffc1d3fcd46a > > Git Commit: ffc1d3fcd46a59815958ce25e4e70da1a8a5799d > > Git URL: > > http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > Tested: 62 unique boards, 20 SoC families, 18 builds out of 182 > > > > Boot Regressions Detected: > > > > arm: > > > > exynos_defconfig: > > exynos5422-odroidxu3: > > lab-collabora: failing since 31 days (last pass: > > v4.4.95-21-g32458fcb7bd6 - first fail: v4.4.96-41-g336421367b9c) > > exynos5422-odroidxu3_rootfs:nfs: > > lab-collabora: failing since 23 days (last pass: > > v4.4.95-21-g32458fcb7bd6 - first fail: v4.4.97-57-g528c687b455d) > > TL;DR; All is well. > > These two are passing in another lab, so this is a board/lab setup issue > under. Guillaume (Cc'd) is investigating. I figured with a lab that was failing for that long, I didn't need to worry about it. thanks, greg k-h > Kevin
Re: [PATCH 4.4 38/49] xen-netfront: Improve error handling during initialization
On Fri, Dec 08, 2017 at 05:10:49AM +, Ben Hutchings wrote:
> On Thu, 2017-12-07 at 14:07 +0100, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch. If anyone has any objections, please let me
> > know.
> >
> > --
> >
> > From: Ross Lagerwall
> >
> >
> > [ Upstream commit e2e004acc7cbe3c531e752a270a74e95cde3ea48 ]
> [...]
> > @@ -1950,9 +1942,10 @@ abort_transaction_no_dev_fatal:
> > xenbus_transaction_end(xbt, 1);
> > destroy_ring:
> > xennet_disconnect_backend(info);
> > - kfree(info->queues);
> > - info->queues = NULL;
> > + xennet_destroy_queues(info);
> > out:
> > + unregister_netdev(info->netdev);
> > + xennet_free_netdev(info->netdev);
> > return err;
> > }
>
> This last bit of cleanup looks wrong. It was subsequently changed
> upstream by:
>
> 86b5672b1adb xen-netfront: avoid crashing on resume after a failure in
> talk_to_netback()
Good catch, but it's d86b5672b1ad ("xen-netfront: avoid crashing on
resume after a failure in talk_to_netback()")
:)
thanks,
greg k-h
Re: [PATCH] Make "Memory Debugging" a menuconfig to ease disabling it all
On 12/09/2017 04:40 AM, Vincent Legoll wrote: > This patch introduces some Kconfig warnings: > > warning: (X86) selects HAVE_DEBUG_KMEMLEAK which has unmet direct > dependencies (DEBUG_MEMORY) > warning: (X86) selects HAVE_ARCH_KASAN which has unmet direct > dependencies (DEBUG_MEMORY) > warning: (X86) selects ARCH_HAS_DEBUG_VIRTUAL which has unmet direct > dependencies (DEBUG_MEMORY) > warning: (X86) selects HAVE_DEBUG_STACKOVERFLOW which has unmet direct > dependencies (DEBUG_MEMORY) > > What would be the best way to fix that ? > > excluding those config options from the "if DEBUG_MEMORY" code > block seems to alleviate the warnings, but is that OK to do ? > > Would moving them out of the if/endif block be acceptable ? That sounds OK to me since none of them have prompts, i.e., they are not user visible, but they are indicators of what the arch supports. -- ~Randy
Re: [PATCH 4.4 20/49] usbip: tools: Install all headers needed for libusbip development
On Fri, Dec 08, 2017 at 03:56:40AM +, Ben Hutchings wrote:
> On Thu, 2017-12-07 at 14:07 +0100, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch. If anyone has any objections, please let me know.
> >
> > --
> >
> > From: Ben Hutchings
> >
> >
> > [ Upstream commit c15562c0dcb2c7f26e891923b784cf1926b8c833 ]
> >
> > usbip_host_driver.h now depends on several additional headers, which
> > need to be installed along with it.
> >
> > Fixes: 021aed845303 ("staging: usbip: userspace: migrate usbip_host_driver
> > ...")
> > Fixes: 3391ba0e2792 ("usbip: tools: Extract generic code to be shared with
> > ...")
> > Signed-off-by: Ben Hutchings
> > Acked-by: Shuah Khan
> > Signed-off-by: Greg Kroah-Hartman
> > Signed-off-by: Sasha Levin
> > Signed-off-by: Greg Kroah-Hartman
> > ---
> > tools/usb/usbip/Makefile.am |3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > --- a/tools/usb/usbip/Makefile.am
> > +++ b/tools/usb/usbip/Makefile.am
> > @@ -1,6 +1,7 @@
> > SUBDIRS := libsrc src
> > includedir = @includedir@/usbip
> > include_HEADERS := $(addprefix libsrc/, \
> > - usbip_common.h vhci_driver.h usbip_host_driver.h)
> > + usbip_common.h vhci_driver.h usbip_host_driver.h \
> > + list.h sysfs_utils.h usbip_host_common.h)
>
> usbip_host_common.h was added in 4.7 (by the second commit listed
> above), so for 4.4 and 3.18 it should not be added to this list.
Thanks, now dropped from those trees.
Many thanks for the great review.
greg k-h
Re: [PATCH v2 4/7] drm/rockchip: dw_hdmi: add inno hdmi phy ops
Hi Algea,
Am Samstag, 30. September 2017, 09:44:46 CET schrieb Algea Cao:
> Because some RK chips use inno hdmi phy, such as RK3328, we add
> inno hdmi phy ops.
>
> Signed-off-by: Algea Cao
> ---
> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 110
> +++-
> 1 file changed, 107 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> index 09c77f9..7658b2f 100644
> --- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> @@ -12,7 +12,7 @@
> #include
> #include
> #include
> -
> +#include
> #include
> #include
> #include
> @@ -26,6 +26,18 @@
> #define RK3288_HDMI_LCDC_SEL BIT(4)
> #define RK3399_GRF_SOC_CON20 0x6250
> #define RK3399_HDMI_LCDC_SEL BIT(6)
> +#define RK3328_GRF_SOC_CON2 0x0408
> +#define RK3328_DDC_MASK_EN ((3 << 10) | (3 << (10 + 16)))
> +#define RK3328_GRF_SOC_CON3 0x040c
> +#define RK3328_IO_CTRL_BY_HDMI (0xf000 | BIT(13) | BIT(12))
> +#define RK3328_GRF_SOC_CON4 0x0410
> +#define RK3328_IO_3V_DOMAIN (7 << (9 + 16))
> +#define RK3328_IO_5V_DOMAIN ((7 << 9) | (3 << (9 + 16)))
This is slightly confusing. (9+16) is obviously the write-enable-mask, so
shouldn't the write-enable-mask not at least cover the changed bits?
> +static enum drm_connector_status
> +inno_dw_hdmi_phy_read_hpd(struct dw_hdmi *dw_hdmi, void *data)
> +{
> + struct rockchip_hdmi *hdmi = (struct rockchip_hdmi *)data;
> + enum drm_connector_status status;
> +
> + status = dw_hdmi_phy_read_hpd(dw_hdmi, data);
> +
> + if (hdmi->dev_type == RK3228_HDMI)
> + return status;
There is no need to encode the functionality for both variants
(and possibly later ones) into one function.
As Neil said in his reply to patch2, we don't really want to carry
that dev_type property, so why don't you just define this as
rk3328_inno_phy_read_hpd and then use it like
static const struct dw_hdmi_phy_ops rk3228_dw_hdmi_phy_ops = {
.init = inno_dw_hdmi_phy_init,
.disable= inno_dw_hdmi_phy_disable,
.read_hpd = dw_hdmi_phy_read_hpd,
};
static const struct dw_hdmi_phy_ops rk3328_dw_hdmi_phy_ops = {
.init = inno_dw_hdmi_phy_init,
.disable= inno_dw_hdmi_phy_disable,
.read_hpd = rk3328_inno_phy_read_hpd,
};
> + if (status == connector_status_connected)
> + regmap_write(hdmi->regmap,
> + RK3328_GRF_SOC_CON4,
> + RK3328_IO_5V_DOMAIN);
> + else
> + regmap_write(hdmi->regmap,
> + RK3328_GRF_SOC_CON4,
> + RK3328_IO_3V_DOMAIN);
That should definitely get a comment explaining what this is doing and
why :-) . Especially as it seems related to the plug/unplug events.
According to the TRM, the hdmiphy IP block has its own interrupt. Can
you tell me if it is firing on hotplug events? Because I'm wondering if
these GRF settings wouldn't be better live in the hdmiphy driver
[if it gets an irq on plug/unplug], which in turn would make the phy
handling in dw_hdmi a lot easier.
> + return status;
> +}
> +
[...]
> @@ -361,7 +453,7 @@ static int dw_hdmi_rockchip_bind(struct device *dev,
> struct device *master,
> return -ENOMEM;
>
> match = of_match_node(dw_hdmi_rockchip_dt_ids, pdev->dev.of_node);
> - plat_data = match->data;
> + plat_data = (struct dw_hdmi_plat_data *)match->data;
> hdmi->dev = &pdev->dev;
> hdmi->chip_data = plat_data->phy_data;
> hdmi->dev_type = plat_data->dev_type;
> @@ -383,6 +475,18 @@ static int dw_hdmi_rockchip_bind(struct device *dev,
> struct device *master,
> return ret;
> }
>
> + if (hdmi->dev_type == RK3328_HDMI || hdmi->dev_type == RK3228_HDMI) {
> + hdmi->phy = devm_phy_get(dev, "hdmi_phy");
> + if (IS_ERR(hdmi->phy)) {
> + ret = PTR_ERR(hdmi->phy);
> + dev_err(dev, "failed to get phy: %d\n", ret);
> + return ret;
> + }
> + plat_data->phy_data = hdmi;
> + ret = inno_dw_hdmi_init(hdmi);
> + if (ret < 0)
> + return ret;
> + }
You could also just declare it optional in the binding, try to get the phy
via devm_phy_optional_get and if it's NULL just assume that it's the
regular internal phy as with previous socs. That way you can drop the
dev-type-check.
Aka, if a phy is defined we are pretty sure we want to use that one :-) .
Heiko
Re: [PATCH 4.4 13/49] usb: dwc2: Fix UDC state tracking
On Fri, Dec 08, 2017 at 03:37:17AM +, Ben Hutchings wrote:
> On Thu, 2017-12-07 at 14:07 +0100, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch. If anyone has any objections, please let me
> > know.
> >
> > --
> >
> > From: John Stultz
> >
> >
> > [ Upstream commit ce2b21a4e5ce042c0a42c9db8fa9e0f849427d5e ]
> >
> > It has been noticed that the dwc2 udc state reporting doesn't
> > seem to work (at least on HiKey boards). Where after the initial
> > setup, the sysfs /sys/class/udc/f72c.usb/state file would
> > report "configured" no matter the state of the OTG port.
> >
> > This patch adds a call so that we report to the UDC layer when
> > the gadget device is disconnected.
> >
> > This patch does depend on the previous patch ("usb: dwc2:
> > Improve gadget state disconnection handling") in this patch set
> > in order to properly work.
>
> Then you should add that (commit d2471d4a24df).
Ah, but that patch doesn't apply :(
So, I've dropped this one, and the one after this one (which depended on
this one), so all should be back to how things were.
Sasha, can you fix this up and submit all 3 for the 4.4, 4.9 and 4.14
trees sometime in the future?
thanks,
greg k-h
[PATCH] Change some filesystem menus into menuconfig to ease disabling it all
No need to get into the submenu to disable all related config entries. This makes it easier to disable all related config options without entering the submenu. It will also enable one to see that en/dis-abled state from the outside menu. This is only intended to change menuconfig UI, not change the config dependencies. Signed-off-by: Vincent Legoll --- fs/Kconfig | 21 +++-- 1 file changed, 15 insertions(+), 6 deletions(-) diff --git a/fs/Kconfig b/fs/Kconfig index 7aee6d699fd6..94ee1422e995 100644 --- a/fs/Kconfig +++ b/fs/Kconfig @@ -105,29 +105,38 @@ source "fs/autofs4/Kconfig" source "fs/fuse/Kconfig" source "fs/overlayfs/Kconfig" -menu "Caches" +menuconfig FS_CACHE_MENU + bool "Caches" + +if FS_CACHE_MENU source "fs/fscache/Kconfig" source "fs/cachefiles/Kconfig" -endmenu +endif # FS_CACHE_MENU if BLOCK -menu "CD-ROM/DVD Filesystems" +menuconfig FS_CDVD_MENU + bool "CD-ROM/DVD Filesystems" + +if FS_CDVD_MENU source "fs/isofs/Kconfig" source "fs/udf/Kconfig" -endmenu +endif # FS_CDVD_MENU endif # BLOCK if BLOCK -menu "DOS/FAT/NT Filesystems" +menuconfig FS_FAT_MENU + bool "DOS/FAT/NT Filesystems" + +if FS_FAT_MENU source "fs/fat/Kconfig" source "fs/ntfs/Kconfig" -endmenu +endif # FS_FAT_MENU endif # BLOCK menu "Pseudo filesystems" -- 2.14.1
Re: [PATCH 4.14 00/75] 4.14.5-stable review
On Sat, Dec 09, 2017 at 07:56:40AM +, Ivan Kozik wrote:
> On Sat, Dec 9, 2017 at 7:45 AM, Greg Kroah-Hartman
> wrote:
> > On Sat, Dec 09, 2017 at 03:34:24AM +, Ivan Kozik wrote:
> >> I saw no problems on 8 of 9 machines, but the last one had a problem
> >> because it used NVIDIA drivers (387); DKMS reported:
> >>
> >> FATAL: modpost: GPL-incompatible module nvidia-drm.ko uses GPL-only
> >> symbol 'ex_handler_refcount'
> >> //usr/src/linux-headers-4.14.0-11-common/scripts/Makefile.modpost:92:
> >> recipe for target '__modpost' failed
> >> make[3]: *** [__modpost] Error 1
> >
> > Is this a new issue? Does 4.14.4 have this issue?
>
> I believe it is a new issue, because I have a 4.14.4 build and an
> NVIDIA DKMS log for that 4.14.4 showing build success.
>
> > Odd, is 564c9cc84e2a ("locking/refcounts, x86/asm: Use unique .text
> > section for refcount exceptions") causing this?
>
> That was my guess too, but I did not verify.
That feels really wrong here, I'd like to get some confirmation before I
add this patch...
thanks,
greg k-h
Re: [PATCH v2] mmap.2: MAP_FIXED updated documentation
On Thu 2017-12-07 15:02:21, Michal Hocko wrote: > On Thu 07-12-17 13:58:05, Cyril Hrubis wrote: > > Hi! > > > >> (It does seem unfortunate that the man page cannot help the programmer > > > >> actually write correct code here. He or she is forced to read the > > > >> kernel > > > >> implementation, in order to figure out the true alignment rules. I was > > > >> hoping we could avoid that.) > > > > > > > > It would be nice if we had this information exported somehere so that we > > > > do not have to rely on per-architecture ifdefs. > > > > > > > > What about adding MapAligment or something similar to the /proc/meminfo? > > > > > > > > > > What's the use case you envision for that? I don't see how that would be > > > better than using SHMLBA, which is available at compiler time. Because > > > unless someone expects to be able to run an app that was compiled for > > > Arch X, on Arch Y (surely that's not requirement here?), I don't see how > > > the run-time check is any better. > > > > I guess that some kind of compile time constant in uapi headers will do > > as well, I'm really open to any solution that would expose this constant > > as some kind of official API. > > I am not sure this is really feasible. It is not only a simple alignment > thing. Look at ppc for example (slice_get_unmapped_area). Other > architectures might have even more complicated rules e.g. arm and its > cache_is_vipt_aliasing. Also this applies only on MAP_SHARED || file > backed mappings. > > I would really leave dogs sleeping... Trying to document all this in the > man page has chances to confuse more people than it has chances to help > those who already know all these nasty details. You don't have to provide all the details, but warning that there's arch- specific magic would be nice... Pavel (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: UDL's fbdev doesn't work for user-space apps
On Mon 2017-12-04 11:50:40, Jose Abreu wrote: > Hi Alexey, > > On 04-12-2017 11:32, Alexey Brodkin wrote: > > My first [probably incorrect] assumption is Xserver requires fbdev > > (/dev/fbX) > > and it cannot use DRI video card natively. Is that correct? > > > > > > Xserver can use DRI directly, you need to enable modesetting > driver in Xorg config or use the designated driver for your card > (if there is any). Still, dev/fb1 should work. Can be tested using dd, even :-) Best regards, Pavel > > e.g.: > > Section "Device" > Identifier "Card0" > Driver "modesetting" > Option "kmsdev" "/dev/dri/card0" > Option "SWcursor" "true" > BusID "PCI:X:X:X" > EndSection > > Best Regards, > Jose Miguel Abreu -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [PATCH] HID: elecom: rewrite report fixup for EX-G and future mice
On Thu, Dec 07, 2017 at 11:04:37AM +0100, Jiri Kosina wrote: > On Tue, 5 Dec 2017, Tomasz Kramkowski wrote: > > > On Mon, Dec 04, 2017 at 08:55:50PM +, Tomasz Kramkowski wrote: > > > +static void mouse_button_fixup(struct hid_device *hdev, > > > +__u8 *rdesc, unsigned int *rsize, > > > +int nbuttons) > > > > I've just remembered what has been bugging me yesterday when I was > > reviewing this patch. I had come to the realisation (and then > > subsequently forgotten) that this function should probably return __u8 * > > and also get assigned to rdesc on the other end. It seems to me that it > > makes most sense to allow for the possibility (although slim) of this > > function eventually being expanded to actually replace the report > > descriptor > > Sure, but you can extend the API of mouse_button_fixup() once such need > arises; no need to pass data pointers around without having actual use for > them. Alright, that's fine. Anything else to change before I send a v2? Also, would you like v2 in-reply-to the root of this thread or as its own thread? -- Tomasz Kramkowski | GPG: 40B037BA0A5B8680 | Web: https://the-tk.com/
Re: [PATCH v2] drivers: visorbus: move driver out of staging
On Fri, Dec 08, 2017 at 02:13:18PM -0800, Joe Perches wrote: > On Fri, 2017-12-08 at 21:55 +, Kershner, David A wrote: > > > -Original Message- > > > From: Joe Perches [mailto:j...@perches.com] > > > Sent: Friday, December 8, 2017 11:53 AM > > > To: Greg KH ; Kershner, David A > > > > > > Cc: jes.soren...@gmail.com; linux-kernel@vger.kernel.org; driverdev- > > > de...@linuxdriverproject.org; *S-Par-Maintainer > > > ; erik.arfvid...@gmail.com; > > > wadgaonkar...@gmail.com > > > Subject: Re: [PATCH v2] drivers: visorbus: move driver out of staging > > > > > > On Fri, 2017-12-08 at 16:39 +0100, Greg KH wrote: > > > > On Thu, Dec 07, 2017 at 12:11:07PM -0500, David Kershner wrote: > > > > > Move the visorbus driver out of staging > > > > (drivers/staging/unisys/visorbus) > > > > > and to drivers/visorbus. Modify the configuration and makefiles so > > > > they > > > > > now reference the new location. The s-Par header file visorbus.h that > > > > is > > > > > referenced by all s-Par drivers, is being moved into include/linux. > > > > > > Perhaps moving visorbus.h and visorbus_private.h to > > > drivers/visorbus would be better than adding more > > > relatively localized #include files to include/linux/ > > > > > > what about controlvmchannel? > > > > > > > The file visorbus.h is currently included by 4 drivers: visorbus and 3 > > other drivers that are staying in staging for now, but we plan to move out > > soon. > > OK. > > Where do you plan on moving the 3 other drivers? > > Today, these drivers (visorhba, visorinput, and visornic) > are all under the staging/unisys directory > > visorbus -> drivers/visorbus > visorhba -> ? > visorinput -> ? > visornic -> ? > > Perhaps all these, including visorbus, should be under virt/ > or perhaps visorbus should be under virt/ and the others > under drivers/virt/ They will move to the proper subsystem directory (storage, input, networking), when they are ready. thanks, greg k-h
[PATCH,v2] Make "Memory Debugging" a menuconfig to ease disabling it all
The v2 of the patch tries to do that, but the Kconfig.kasan modification is kind of infortunate, as it moves the HAVE_ARCH_KASAN config option out of that file. If this is not acceptable please advise on how I can achieve it. Thanks
[PATCH] Make "Memory Debugging" a menuconfig to ease disabling it all
No need to get into the submenu to disable all "Memory Debugging"-related config entries. This makes it easier to disable all "Memory Debugging" config options without entering the submenu. It will also enable one to see that en/dis-abled state from the outside menu. This is only intended to change menuconfig UI, not change the config dependencies. Changes since v1: Move some invisible config options ouit of the if/endif DEBUG_MEMORY block to alleviate the warnings: "selects XXX which has unmet direct dependencies" This moves the HAVE_ARCH_KASAN out of Kconfig.kasan Signed-off-by: Vincent Legoll --- lib/Kconfig.debug | 28 +--- lib/Kconfig.kasan | 3 --- 2 files changed, 17 insertions(+), 14 deletions(-) diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 947d3e2ed5c2..19ca76e7b9ed 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -436,7 +436,10 @@ config DEBUG_KERNEL Say Y here if you are developing drivers or trying to debug and identify kernel problems. -menu "Memory Debugging" +menuconfig DEBUG_MEMORY + bool "Memory Debugging" + +if DEBUG_MEMORY source mm/Kconfig.debug @@ -539,9 +542,6 @@ config SLUB_STATS out which slabs are relevant to a particular load. Try running: slabinfo -DA -config HAVE_DEBUG_KMEMLEAK - bool - config DEBUG_KMEMLEAK bool "Kernel memory leak detector" depends on DEBUG_KERNEL && HAVE_DEBUG_KMEMLEAK @@ -636,9 +636,6 @@ config DEBUG_VM_PGFLAGS If unsure, say N. -config ARCH_HAS_DEBUG_VIRTUAL - bool - config DEBUG_VIRTUAL bool "Debug VM translations" depends on DEBUG_KERNEL && ARCH_HAS_DEBUG_VIRTUAL @@ -708,9 +705,6 @@ config DEBUG_HIGHMEM This option enables additional error checking for high memory systems. Disable for production systems. -config HAVE_DEBUG_STACKOVERFLOW - bool - config DEBUG_STACKOVERFLOW bool "Check for stack overflows" depends on DEBUG_KERNEL && HAVE_DEBUG_STACKOVERFLOW @@ -731,7 +725,19 @@ config DEBUG_STACKOVERFLOW source "lib/Kconfig.kasan" -endmenu # "Memory Debugging" +endif # DEBUG_MEMORY + +config HAVE_ARCH_KASAN + bool + +config ARCH_HAS_DEBUG_VIRTUAL + bool + +config HAVE_DEBUG_KMEMLEAK + bool + +config HAVE_DEBUG_STACKOVERFLOW + bool config ARCH_HAS_KCOV bool diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan index bd38aab05929..2396d5116e20 100644 --- a/lib/Kconfig.kasan +++ b/lib/Kconfig.kasan @@ -1,6 +1,3 @@ -config HAVE_ARCH_KASAN - bool - if HAVE_ARCH_KASAN config KASAN -- 2.14.1
Re: [PATCH 4.14 00/75] 4.14.5-stable review
Den 09.12.2017 kl. 19:13, skrev Greg Kroah-Hartman:
On Sat, Dec 09, 2017 at 07:56:40AM +, Ivan Kozik wrote:
On Sat, Dec 9, 2017 at 7:45 AM, Greg Kroah-Hartman
wrote:
On Sat, Dec 09, 2017 at 03:34:24AM +, Ivan Kozik wrote:
I saw no problems on 8 of 9 machines, but the last one had a problem
because it used NVIDIA drivers (387); DKMS reported:
FATAL: modpost: GPL-incompatible module nvidia-drm.ko uses GPL-only
symbol 'ex_handler_refcount'
//usr/src/linux-headers-4.14.0-11-common/scripts/Makefile.modpost:92:
recipe for target '__modpost' failed
make[3]: *** [__modpost] Error 1
Is this a new issue? Does 4.14.4 have this issue?
I believe it is a new issue, because I have a 4.14.4 build and an
NVIDIA DKMS log for that 4.14.4 showing build success.
Odd, is 564c9cc84e2a ("locking/refcounts, x86/asm: Use unique .text
section for refcount exceptions") causing this?
That was my guess too, but I did not verify.
That feels really wrong here, I'd like to get some confirmation before I
add this patch...
It's needed.
The reason you hit in 4.14.5 queue is because of:
[PATCH 4.14 64/75] locking/refcounts, x86/asm: Enable
CONFIG_ARCH_HAS_REFCOUNT
From foo@baz Wed Dec 6 18:04:41 CET 2017
From: Kees Cook
Date: Sat, 2 Sep 2017 13:09:46 -0700
Subject: locking/refcounts, x86/asm: Enable CONFIG_ARCH_HAS_REFCOUNT
that does this:
- select ARCH_HAS_REFCOUNTif BROKEN
+ select ARCH_HAS_REFCOUNT
So it exposes previously hidden code
--
Thomas
Re: [PATCH net-next] libbpf: add function to setup XDP
On Sat, Dec 09, 2017 at 09:34:46AM -0700, David Ahern wrote: > On 12/9/17 7:43 AM, Eric Leblond wrote: > > + /* started nested attribute for XDP */ > > + nla = (struct nlattr *)(((char *)&req) > > + + NLMSG_ALIGN(req.nh.nlmsg_len)); > > + nla->nla_type = NLA_F_NESTED | 43/*IFLA_XDP*/; > > as a part of the move into libbpf can the magic numbers be replaced by > the names directly and there as a comment? In general it would be nice to use names instead of numbers, but it's much bigger change then this patch, since it would require copying and syncing a bunch of headers into tools/ which may not be such a good idea in the end. Only removal of min() looks a bit suspicious to me. Eric, is it because it now comes from some header?
[GIT PULL] Btrfs fixes for 4.15-rc3
Hi, this update contains a few fixes (error handling, quota leak, FUA vs nobarrier mount option). There's one one worth mentioning separately - an off-by-one fix that leads to overwriting first byte of an adjacent page with 0, out of bounds of the memory allocated by an ioctl. This is under a privileged part of the ioctl, can be triggerd in some subvolume layouts. After the last tags and branches mess [1], let me note that the pull url is pointed to the signed tag. There are no merge conflics. Please pull, thanks. [1] https://lkml.org/lkml/2017/11/29/952 The following changes since commit ea37d5998b50a72b9045ba60a132eeb20e1c4230: Btrfs: incremental send, fix wrong unlink path after renaming file (2017-11-28 17:15:30 +0100) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git for-4.15-rc3-tag for you to fetch changes up to c8bcbfbd239ed60a6562964b58034ac8a25f4c31: btrfs: Fix possible off-by-one in btrfs_search_path_in_tree (2017-12-07 00:35:15 +0100) Jeff Mahoney (2): btrfs: handle errors while updating refcounts in update_ref_for_cow btrfs: fix missing error return in btrfs_drop_snapshot Justin Maggard (1): btrfs: Fix quota reservation leak on preallocated files Nikolay Borisov (1): btrfs: Fix possible off-by-one in btrfs_search_path_in_tree Omar Sandoval (1): Btrfs: disable FUA if mounted with nobarrier fs/btrfs/ctree.c | 18 -- fs/btrfs/disk-io.c | 12 +--- fs/btrfs/extent-tree.c | 1 + fs/btrfs/inode.c | 2 ++ fs/btrfs/ioctl.c | 2 +- 5 files changed, 21 insertions(+), 14 deletions(-)
[PATCH 0/3] tty/serial/ioc3: Adjustments for three function implementations
From: Markus Elfring Date: Sat, 9 Dec 2017 19:00:19 +0100 Three update suggestions were taken into account from static source code analysis. Markus Elfring (3): Delete error messages for a failed memory allocation in ioc3uart_probe() Improve size determinations in ioc3uart_probe() Adjust two function calls together with a variable assignment drivers/tty/serial/ioc3_serial.c | 22 +- 1 file changed, 9 insertions(+), 13 deletions(-) -- 2.15.1
[PATCH 3/3] staging: pi433: Remove unnecessary #ifdef DEBUG around dev_dbg
dev_dbg() already depends on DEBUG.
Signed-off-by: Simon Sandström
---
drivers/staging/pi433/rf69.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/staging/pi433/rf69.c b/drivers/staging/pi433/rf69.c
index 04a74423c325..6e38e6a515a4 100644
--- a/drivers/staging/pi433/rf69.c
+++ b/drivers/staging/pi433/rf69.c
@@ -767,9 +767,7 @@ int rf69_read_fifo (struct spi_device *spi, u8 *buffer,
unsigned int size)
int retval;
if (size > FIFO_SIZE) {
-#ifdef DEBUG
dev_dbg(&spi->dev, "read fifo: passed in buffer bigger then
internal buffer\n");
-#endif
return -EMSGSIZE;
}
@@ -801,9 +799,7 @@ int rf69_write_fifo(struct spi_device *spi, u8 *buffer,
unsigned int size)
u8 local_buffer[FIFO_SIZE + 1];
if (size > FIFO_SIZE) {
-#ifdef DEBUG
dev_dbg(&spi->dev, "read fifo: passed in buffer bigger then
internal buffer\n");
-#endif
return -EMSGSIZE;
}
--
2.11.0
[PATCH 1/3] staging: pi433: Remove indentation on #ifdef blocks
ifdef blocks should not increase indentation level.
Signed-off-by: Simon Sandström
---
drivers/staging/pi433/rf69.c | 314 +--
1 file changed, 153 insertions(+), 161 deletions(-)
diff --git a/drivers/staging/pi433/rf69.c b/drivers/staging/pi433/rf69.c
index 8b6d68f10e8a..39920240c05c 100644
--- a/drivers/staging/pi433/rf69.c
+++ b/drivers/staging/pi433/rf69.c
@@ -64,9 +64,9 @@ static inline int rf69_read_mod_write(struct spi_device *spi,
u8 reg, u8 mask, u
int rf69_set_mode(struct spi_device *spi, enum mode mode)
{
- #ifdef DEBUG
- dev_dbg(&spi->dev, "set: mode");
- #endif
+#ifdef DEBUG
+ dev_dbg(&spi->dev, "set: mode");
+#endif
switch (mode) {
case transmit:return rf69_read_mod_write(spi, REG_OPMODE,
MASK_OPMODE_MODE, OPMODE_MODE_TRANSMIT);
@@ -91,9 +91,9 @@ int rf69_set_data_mode(struct spi_device *spi, u8 data_mode)
int rf69_set_modulation(struct spi_device *spi, enum modulation modulation)
{
- #ifdef DEBUG
- dev_dbg(&spi->dev, "set: modulation");
- #endif
+#ifdef DEBUG
+ dev_dbg(&spi->dev, "set: modulation");
+#endif
switch (modulation) {
case OOK: return rf69_read_mod_write(spi, REG_DATAMODUL,
MASK_DATAMODUL_MODULATION_TYPE, DATAMODUL_MODULATION_TYPE_OOK);
@@ -108,9 +108,9 @@ enum modulation rf69_get_modulation(struct spi_device *spi)
{
u8 currentValue;
- #ifdef DEBUG
- dev_dbg(&spi->dev, "get: mode");
- #endif
+#ifdef DEBUG
+ dev_dbg(&spi->dev, "get: mode");
+#endif
currentValue = rf69_read_reg(spi, REG_DATAMODUL);
@@ -124,9 +124,9 @@ enum modulation rf69_get_modulation(struct spi_device *spi)
int rf69_set_modulation_shaping(struct spi_device *spi,
enum mod_shaping mod_shaping)
{
- #ifdef DEBUG
- dev_dbg(&spi->dev, "set: mod shaping");
- #endif
+#ifdef DEBUG
+ dev_dbg(&spi->dev, "set: mod shaping");
+#endif
switch (rf69_get_modulation(spi)) {
case FSK:
@@ -162,9 +162,9 @@ int rf69_set_bit_rate(struct spi_device *spi, u16 bitRate)
u8 msb;
u8 lsb;
- #ifdef DEBUG
- dev_dbg(&spi->dev, "set: bit rate");
- #endif
+#ifdef DEBUG
+ dev_dbg(&spi->dev, "set: bit rate");
+#endif
// check input value
bitRate_min = F_OSC / 8388608; // 8388608 = 2^23;
@@ -199,9 +199,9 @@ int rf69_set_deviation(struct spi_device *spi, u32
deviation)
u8 lsb;
u64 factor = 100; // to improve precision of calculation
- #ifdef DEBUG
- dev_dbg(&spi->dev, "set: deviation");
- #endif
+#ifdef DEBUG
+ dev_dbg(&spi->dev, "set: deviation");
+#endif
// TODO: Dependency to bitrate
if (deviation < 600 || deviation > 50) {
@@ -248,9 +248,9 @@ int rf69_set_frequency(struct spi_device *spi, u32
frequency)
u8 lsb;
u64 factor = 100; // to improve precision of calculation
- #ifdef DEBUG
- dev_dbg(&spi->dev, "set: frequency");
- #endif
+#ifdef DEBUG
+ dev_dbg(&spi->dev, "set: frequency");
+#endif
// calculat f step
f_step = F_OSC * factor;
@@ -297,9 +297,9 @@ int rf69_disable_amplifier(struct spi_device *spi, u8
amplifier_mask)
int rf69_set_output_power_level(struct spi_device *spi, u8 powerLevel)
{
- #ifdef DEBUG
- dev_dbg(&spi->dev, "set: power level");
- #endif
+#ifdef DEBUG
+ dev_dbg(&spi->dev, "set: power level");
+#endif
// TODO: Dependency to PA0,1,2 setting
powerLevel += 18;
@@ -316,9 +316,9 @@ int rf69_set_output_power_level(struct spi_device *spi, u8
powerLevel)
int rf69_set_pa_ramp(struct spi_device *spi, enum paRamp paRamp)
{
- #ifdef DEBUG
- dev_dbg(&spi->dev, "set: pa ramp");
- #endif
+#ifdef DEBUG
+ dev_dbg(&spi->dev, "set: pa ramp");
+#endif
switch (paRamp) {
case ramp3400: return rf69_write_reg(spi, REG_PARAMP, PARAMP_3400);
@@ -345,9 +345,9 @@ int rf69_set_pa_ramp(struct spi_device *spi, enum paRamp
paRamp)
int rf69_set_antenna_impedance(struct spi_device *spi, enum antennaImpedance
antennaImpedance)
{
- #ifdef DEBUG
- dev_dbg(&spi->dev, "set: antenna impedance");
- #endif
+#ifdef DEBUG
+ dev_dbg(&spi->dev, "set: antenna impedance");
+#endif
switch (antennaImpedance) {
case fiftyOhm: return rf69_clear_bit(spi, REG_LNA, MASK_LNA_ZIN);
@@ -360,9 +360,9 @@ int rf69_set_antenna_impedance(struct spi_device *spi, enum
antennaImpedance ant
int rf69_set_lna_gain(struct spi_device *spi, enum lnaGain lnaGain)
{
- #ifdef DEBUG
- dev_dbg(&spi->dev, "set: lna gain");
- #endif
+#ifdef DEBUG
+ dev_dbg(&spi->dev, "set: lna gain");
+#endif
switch (lnaGain) {
case automatic: return rf69_read_mod_write(spi, REG_LNA,
MASK_LNA
[PATCH 0/3] staging: pi433: Refactor usage of dev_dbg and #ifdef DEBUG
These patches refactors the usage of dev_dbg and #ifdef DEBUG in rf69.c. All dev_dbg() calls that just prints the function name are removed, since we have ftrace. For all other calls the #ifdef DEBUG block around them are removed. There are still two more defines used in rf69.c: DEBUG_FIFO_ACCESS and DEBUG_VALUES. Perhaps they should be removed as well? - Simon --- Simon Sandström (3): staging: pi433: Remove indentation on #ifdef blocks staging: pi433: Remove function entry dev_dbg() staging: pi433: Remove unnecessary #ifdef DEBUG around dev_dbg drivers/staging/pi433/rf69.c | 232 ++- 1 file changed, 32 insertions(+), 200 deletions(-) -- 2.11.0
[PATCH 2/3] staging: pi433: Remove function entry dev_dbg()
ftrace can be used to trace function calls, so there is no need to use
dev_dbg() here.
Signed-off-by: Simon Sandström
---
drivers/staging/pi433/rf69.c | 156 ---
1 file changed, 156 deletions(-)
diff --git a/drivers/staging/pi433/rf69.c b/drivers/staging/pi433/rf69.c
index 39920240c05c..04a74423c325 100644
--- a/drivers/staging/pi433/rf69.c
+++ b/drivers/staging/pi433/rf69.c
@@ -64,10 +64,6 @@ static inline int rf69_read_mod_write(struct spi_device
*spi, u8 reg, u8 mask, u
int rf69_set_mode(struct spi_device *spi, enum mode mode)
{
-#ifdef DEBUG
- dev_dbg(&spi->dev, "set: mode");
-#endif
-
switch (mode) {
case transmit:return rf69_read_mod_write(spi, REG_OPMODE,
MASK_OPMODE_MODE, OPMODE_MODE_TRANSMIT);
case receive: return rf69_read_mod_write(spi, REG_OPMODE,
MASK_OPMODE_MODE, OPMODE_MODE_RECEIVE);
@@ -91,10 +87,6 @@ int rf69_set_data_mode(struct spi_device *spi, u8 data_mode)
int rf69_set_modulation(struct spi_device *spi, enum modulation modulation)
{
-#ifdef DEBUG
- dev_dbg(&spi->dev, "set: modulation");
-#endif
-
switch (modulation) {
case OOK: return rf69_read_mod_write(spi, REG_DATAMODUL,
MASK_DATAMODUL_MODULATION_TYPE, DATAMODUL_MODULATION_TYPE_OOK);
case FSK: return rf69_read_mod_write(spi, REG_DATAMODUL,
MASK_DATAMODUL_MODULATION_TYPE, DATAMODUL_MODULATION_TYPE_FSK);
@@ -108,10 +100,6 @@ enum modulation rf69_get_modulation(struct spi_device *spi)
{
u8 currentValue;
-#ifdef DEBUG
- dev_dbg(&spi->dev, "get: mode");
-#endif
-
currentValue = rf69_read_reg(spi, REG_DATAMODUL);
switch (currentValue & MASK_DATAMODUL_MODULATION_TYPE >> 3) { // TODO
improvement: change 3 to define
@@ -124,10 +112,6 @@ enum modulation rf69_get_modulation(struct spi_device *spi)
int rf69_set_modulation_shaping(struct spi_device *spi,
enum mod_shaping mod_shaping)
{
-#ifdef DEBUG
- dev_dbg(&spi->dev, "set: mod shaping");
-#endif
-
switch (rf69_get_modulation(spi)) {
case FSK:
switch (mod_shaping) {
@@ -162,10 +146,6 @@ int rf69_set_bit_rate(struct spi_device *spi, u16 bitRate)
u8 msb;
u8 lsb;
-#ifdef DEBUG
- dev_dbg(&spi->dev, "set: bit rate");
-#endif
-
// check input value
bitRate_min = F_OSC / 8388608; // 8388608 = 2^23;
if (bitRate < bitRate_min) {
@@ -199,10 +179,6 @@ int rf69_set_deviation(struct spi_device *spi, u32
deviation)
u8 lsb;
u64 factor = 100; // to improve precision of calculation
-#ifdef DEBUG
- dev_dbg(&spi->dev, "set: deviation");
-#endif
-
// TODO: Dependency to bitrate
if (deviation < 600 || deviation > 50) {
dev_dbg(&spi->dev, "set_deviation: illegal input param");
@@ -248,10 +224,6 @@ int rf69_set_frequency(struct spi_device *spi, u32
frequency)
u8 lsb;
u64 factor = 100; // to improve precision of calculation
-#ifdef DEBUG
- dev_dbg(&spi->dev, "set: frequency");
-#endif
-
// calculat f step
f_step = F_OSC * factor;
do_div(f_step, 524288); // 524288 = 2^19
@@ -297,10 +269,6 @@ int rf69_disable_amplifier(struct spi_device *spi, u8
amplifier_mask)
int rf69_set_output_power_level(struct spi_device *spi, u8 powerLevel)
{
-#ifdef DEBUG
- dev_dbg(&spi->dev, "set: power level");
-#endif
-
// TODO: Dependency to PA0,1,2 setting
powerLevel += 18;
@@ -316,10 +284,6 @@ int rf69_set_output_power_level(struct spi_device *spi, u8
powerLevel)
int rf69_set_pa_ramp(struct spi_device *spi, enum paRamp paRamp)
{
-#ifdef DEBUG
- dev_dbg(&spi->dev, "set: pa ramp");
-#endif
-
switch (paRamp) {
case ramp3400: return rf69_write_reg(spi, REG_PARAMP, PARAMP_3400);
case ramp2000: return rf69_write_reg(spi, REG_PARAMP, PARAMP_2000);
@@ -345,10 +309,6 @@ int rf69_set_pa_ramp(struct spi_device *spi, enum paRamp
paRamp)
int rf69_set_antenna_impedance(struct spi_device *spi, enum antennaImpedance
antennaImpedance)
{
-#ifdef DEBUG
- dev_dbg(&spi->dev, "set: antenna impedance");
-#endif
-
switch (antennaImpedance) {
case fiftyOhm: return rf69_clear_bit(spi, REG_LNA, MASK_LNA_ZIN);
case twohundretOhm: return rf69_set_bit(spi, REG_LNA, MASK_LNA_ZIN);
@@ -360,10 +320,6 @@ int rf69_set_antenna_impedance(struct spi_device *spi,
enum antennaImpedance ant
int rf69_set_lna_gain(struct spi_device *spi, enum lnaGain lnaGain)
{
-#ifdef DEBUG
- dev_dbg(&spi->dev, "set: lna gain");
-#endif
-
switch (lnaGain) {
case automatic: return rf69_read_mod_write(spi, REG_LNA,
MASK_LNA_GAIN, LNA_GAIN_AUTO);
case max:return rf69_read_mod_write(spi, REG_LNA,
MASK_LNA_GAIN, LNA_GAIN_MAX);
@@ -382,10 +338,6 @@ enum lnaGain rf69_get_lna_gain(struct spi_device *spi)
{
u8 currentValue;
-#ifdef DEBUG
- dev_db
[PATCH 1/3] serial: ioc3: Delete error messages for a failed memory allocation in ioc3uart_probe()
From: Markus Elfring
Date: Sat, 9 Dec 2017 18:34:36 +0100
Omit extra messages for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/tty/serial/ioc3_serial.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/tty/serial/ioc3_serial.c b/drivers/tty/serial/ioc3_serial.c
index d8a1cdd6a53d..0007c2d65028 100644
--- a/drivers/tty/serial/ioc3_serial.c
+++ b/drivers/tty/serial/ioc3_serial.c
@@ -2017,11 +2017,9 @@ ioc3uart_probe(struct ioc3_submodule *is, struct
ioc3_driver_data *idd)
DPRINT_CONFIG(("%s (0x%p, 0x%p)\n", __func__, is, idd));
card_ptr = kzalloc(sizeof(struct ioc3_card), GFP_KERNEL);
- if (!card_ptr) {
- printk(KERN_WARNING "ioc3_attach_one"
- ": unable to get memory for the IOC3\n");
+ if (!card_ptr)
return -ENOMEM;
- }
+
idd->data[is->id] = card_ptr;
Submodule_slot = is->id;
@@ -2038,8 +2036,6 @@ ioc3uart_probe(struct ioc3_submodule *is, struct
ioc3_driver_data *idd)
for (phys_port = 0; phys_port < PORTS_PER_CARD; phys_port++) {
port = kzalloc(sizeof(struct ioc3_port), GFP_KERNEL);
if (!port) {
- printk(KERN_WARNING
- "IOC3 serial memory not available for port\n");
ret = -ENOMEM;
goto out4;
}
--
2.15.1
[PATCH 2/3] serial: ioc3: Improve size determinations in ioc3uart_probe()
From: Markus Elfring
Date: Sat, 9 Dec 2017 18:38:13 +0100
Replace the specification of two data structures by pointer dereferences
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/tty/serial/ioc3_serial.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/ioc3_serial.c b/drivers/tty/serial/ioc3_serial.c
index 0007c2d65028..d211bb1407d3 100644
--- a/drivers/tty/serial/ioc3_serial.c
+++ b/drivers/tty/serial/ioc3_serial.c
@@ -2016,7 +2016,7 @@ ioc3uart_probe(struct ioc3_submodule *is, struct
ioc3_driver_data *idd)
DPRINT_CONFIG(("%s (0x%p, 0x%p)\n", __func__, is, idd));
- card_ptr = kzalloc(sizeof(struct ioc3_card), GFP_KERNEL);
+ card_ptr = kzalloc(sizeof(*card_ptr), GFP_KERNEL);
if (!card_ptr)
return -ENOMEM;
@@ -2034,7 +2034,7 @@ ioc3uart_probe(struct ioc3_submodule *is, struct
ioc3_driver_data *idd)
/* Create port structures for each port */
for (phys_port = 0; phys_port < PORTS_PER_CARD; phys_port++) {
- port = kzalloc(sizeof(struct ioc3_port), GFP_KERNEL);
+ port = kzalloc(sizeof(*port), GFP_KERNEL);
if (!port) {
ret = -ENOMEM;
goto out4;
--
2.15.1
[PATCH 3/3] serial: ioc3: Adjust two function calls together with a variable assignment
From: Markus Elfring
Date: Sat, 9 Dec 2017 18:48:57 +0100
The script "checkpatch.pl" pointed information out like the following.
ERROR: do not use assignment in if condition
Thus fix the affected source code places.
Signed-off-by: Markus Elfring
---
drivers/tty/serial/ioc3_serial.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/tty/serial/ioc3_serial.c b/drivers/tty/serial/ioc3_serial.c
index d211bb1407d3..0170d6f2bcdf 100644
--- a/drivers/tty/serial/ioc3_serial.c
+++ b/drivers/tty/serial/ioc3_serial.c
@@ -1540,8 +1540,8 @@ ioc3uart_intr_one(struct ioc3_submodule *is,
* hasn't been delivered to the cpu yet anyway, even
* though we see it as asserted when we read the sio_ir.
*/
- if ((sio_ir = PENDING(card_ptr, idd))
- & hooks->intr_rx_high) {
+ sio_ir = PENDING(card_ptr, idd);
+ if (sio_ir & hooks->intr_rx_high) {
if (port->ip_flags & READ_ABORTED) {
rx_high_rd_aborted++;
}
@@ -2162,10 +2162,10 @@ static struct ioc3_submodule ioc3uart_ops = {
*/
static int __init ioc3uart_init(void)
{
- int ret;
-
/* register with serial core */
- if ((ret = uart_register_driver(&ioc3_uart)) < 0) {
+ int ret = uart_register_driver(&ioc3_uart);
+
+ if (ret < 0) {
printk(KERN_WARNING
"%s: Couldn't register IOC3 uart serial driver\n",
__func__);
--
2.15.1
Re: [PATCH 3/3] staging: pi433: Remove unnecessary #ifdef DEBUG around dev_dbg
On Sat, 2017-12-09 at 19:02 +0100, Simon Sandström wrote:
> dev_dbg() already depends on DEBUG.
Not quite.
It depends on CONFIG_DYNAMIC_DEBUG or DEBUG
In any case, this patch is fine.
> Signed-off-by: Simon Sandström
> ---
> drivers/staging/pi433/rf69.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/staging/pi433/rf69.c b/drivers/staging/pi433/rf69.c
> index 04a74423c325..6e38e6a515a4 100644
> --- a/drivers/staging/pi433/rf69.c
> +++ b/drivers/staging/pi433/rf69.c
> @@ -767,9 +767,7 @@ int rf69_read_fifo (struct spi_device *spi, u8 *buffer,
> unsigned int size)
> int retval;
>
> if (size > FIFO_SIZE) {
> -#ifdef DEBUG
> dev_dbg(&spi->dev, "read fifo: passed in buffer bigger then
> internal buffer\n");
> -#endif
> return -EMSGSIZE;
> }
>
> @@ -801,9 +799,7 @@ int rf69_write_fifo(struct spi_device *spi, u8 *buffer,
> unsigned int size)
> u8 local_buffer[FIFO_SIZE + 1];
>
> if (size > FIFO_SIZE) {
> -#ifdef DEBUG
> dev_dbg(&spi->dev, "read fifo: passed in buffer bigger then
> internal buffer\n");
> -#endif
> return -EMSGSIZE;
> }
>
Re: [PATCH] sched/isolation: Make NO_HZ_FULL select CPU_ISOLATION
On Sat, Dec 09, 2017 at 02:09:07PM +0100, Frederic Weisbecker wrote: > 2017-12-07 18:29 UTC+01:00, Paul E. McKenney : > > On Thu, Dec 07, 2017 at 05:14:54PM +0100, Frederic Weisbecker wrote: > >> 2017-12-04 18:16 UTC+01:00, Paul E. McKenney > >> : > >> > On Mon, Dec 04, 2017 at 04:53:15PM +0100, Frederic Weisbecker wrote: > >> >> 2017-12-02 20:24 UTC+01:00, Paul E. McKenney > >> >> I would prefer to keep it. It's useful for automated boot testing > >> >> based on configs such as 0-day or -tip test machines. But I'm likely > >> >> to migrate it to isolcpus implementation. Maybe something along the > >> >> lines of CONFIG_CPU_ISOLATION_ALL. > >> > > >> > How about instead allowing something like "nohz_full=1-" specify that > >> > all CPUs other than CPU 0 should be nohz_full CPUs? That would shrink > >> > the code by eliminating CONFIG_NO_HZ_FULL_ALL while still allowing > >> > easy automation of that particular scenario. > >> > > >> > (Right now, the boot code complains about "nohz_full=1-", which means > >> > that whatever is generating the boot parameters needs to know how many > >> > CPUs there really are, which as you say can be a pain.) > >> > >> Yes but automated boot testing is rather based on configs than boot > >> options. It's much easier. I think that's how Wu Fengguang lab works, > >> and -tip automated tests as well. > > > > So you have gotten bug reports from them? Because I see splats from > > rcutorture testing rather frequently. This thing is in no way a subtle > > low-probability bug. ;-) > > Nope I haven't got anything from them. So far you're the only > reproducer I know :) > > >> >> >> Did you have any nohz_full= or isolcpus= boot options? > >> >> > > >> >> > Replacing CONFIG_NO_HZ_FULL_ALL=y with nohz_full=1-7 works, that > >> >> > is CONFIG_NO_HZ_FULL=y, CONFIG_NO_HZ_FULL_ALL=n, and nohz_full=1-7 > >> >> > on an eight-CPU test. > >> >> > > >> >> > But it is relatively easy to test. Running the rcutorture TREE04 > >> >> > scenario on a four-socket x86 gets me RCU CPU stall warnings within > >> >> > a few minutes more than half the time. ;-) > >> >> > >> >> Indeed I managed to trigger something. If it's the same thing I should > >> >> be able to track down the root cause. > >> >> > >> >> [ 123.907557] ??? Writer stall state RTWS_STUTTER(8) g160 c160 f0x0 > >> >> ->state 0x1 cpu 2 > >> >> [ 123.915184] rcu_torture_wri S0 111 2 0x8008 > >> >> [ 123.920673] Call Trace: > >> >> [ 123.923096] ? __schedule+0x2bf/0xbb0 > >> >> [ 123.926715] ? _raw_spin_unlock_irqrestore+0x59/0x70 > >> >> [ 123.931657] schedule+0x3c/0x90 > >> >> [ 123.934777] schedule_timeout+0x1e1/0x560 > >> > > >> > It might well be the same thing, as this schedule_timeout() does look > >> > familiar. I have some diagnostic patches in -rcu, please see below > >> > for the overall effect. > >> > >> I fear I can hit that even without any nohz_full CPU as well. > > > > Indeed, I do hit that with my TREE01 scenario, which does not set > > CONFIG_NO_HZ_FULL. But it is much less frequent. The good news is that > > I have finally figured out a way to extract information from this thing > > without suppressing it. At the moment it appears to be a rather strange > > deadlock involving CPU hotplug, timers, and RCU. > > > > But that is a completely different bug from the ones for which I have > > the two patches in my tree. > > > > Anyway, I will keep those two patches because I cannot have the > > corresponding bugs possibly hiding RCU bugs in my testing. If you > > put some other fix in place, I will drop those two patches in favor of > > your fix. > > Ok. I'm a bit troubled by this bug, I hate to push a fix for a bug I > don't understand nor can reproduce. I would be happy to talk you through running the TREE04 rcutorture scenario, if you would like. I just verified that I can reproduce this on a single-socket four-core (8 hardware threads) x86 system running v4.15-rc1, so I would guess that you have access to hardware that can reproduce it. In the meantime, please feel free to take a look at the file tools/testing/selftests/rcutorture/doc/initrd.txt in the kernel source. This file tells how to create the initrd that rcutorture uses to avoid the need to maintain root partitions. Once you have that in place in tools/testing/selftests/rcutorture/initrd (as a expanded file tree, not any sort of archive) the reproducer is as follows, run from the top level of the kernel source tree: bash tools/testing/selftests/rcutorture/bin/kvm.sh --duration 5 --configs TREE04 This will output a bunch of rcutorture status/progress text, ending in something like the following: --- Sat Dec 9 09:49:26 PST 2017 Test summary: Results directory: /home/git/linux-2.6/tools/testing/selftests/rcutorture/res/2017.12.09-09:49:26 tools/testing/selftests/rcutorture/bin/kvm.sh --cpus 7 --duration 5 --configs TREE04 TREE04 --- 350 grace periods (1.16667 per second) WARNING: Assertion failure in /home/git/linux-2.
