Re: [PATCH 1/2] lockdep: improve current->(hard|soft)irqs_enabled synchronisation with actual irq state
Excerpts from Alexey Kardashevskiy's message of July 24, 2020 2:16 pm:
>
>
> On 23/07/2020 23:11, Nicholas Piggin wrote:
>> Excerpts from Peter Zijlstra's message of July 23, 2020 9:40 pm:
>>> On Thu, Jul 23, 2020 at 08:56:14PM +1000, Nicholas Piggin wrote:
>>>
diff --git a/arch/powerpc/include/asm/hw_irq.h
b/arch/powerpc/include/asm/hw_irq.h
index 3a0db7b0b46e..35060be09073 100644
--- a/arch/powerpc/include/asm/hw_irq.h
+++ b/arch/powerpc/include/asm/hw_irq.h
@@ -200,17 +200,14 @@ static inline bool arch_irqs_disabled(void)
#define powerpc_local_irq_pmu_save(flags) \
do { \
raw_local_irq_pmu_save(flags); \
- trace_hardirqs_off(); \
+ if (!raw_irqs_disabled_flags(flags))\
+ trace_hardirqs_off(); \
} while(0)
#define powerpc_local_irq_pmu_restore(flags) \
do {\
- if (raw_irqs_disabled_flags(flags)) { \
- raw_local_irq_pmu_restore(flags); \
- trace_hardirqs_off(); \
- } else {\
+ if (!raw_irqs_disabled_flags(flags))\
trace_hardirqs_on();\
- raw_local_irq_pmu_restore(flags); \
- } \
+ raw_local_irq_pmu_restore(flags); \
} while(0)
>>>
>>> You shouldn't be calling lockdep from NMI context!
>>
>> After this patch it doesn't.
>>
>> trace_hardirqs_on/off implementation appears to expect to be called in NMI
>> context though, for some reason.
>>
>>> That is, I recently
>>> added suport for that on x86:
>>>
>>> https://lkml.kernel.org/r/20200623083721.155449...@infradead.org
>>> https://lkml.kernel.org/r/20200623083721.216740...@infradead.org
>>>
>>> But you need to be very careful on how you order things, as you can see
>>> the above relies on preempt_count() already having been incremented with
>>> NMI_MASK.
>>
>> Hmm. My patch seems simpler.
>
> And your patches fix my error while Peter's do not:
>
>
> IRQs not enabled as expected
> WARNING: CPU: 0 PID: 1377 at /home/aik/p/kernel/kernel/softirq.c:169
> __local_bh_enable_ip+0x118/0x190
I think they would have needed some powerpc bits as well. But I don't
see a reason we can't merge my patches, at least they fix this case and
don't seem to make things worse in any way.
Thanks,
Nick
[PATCH 1/2] arm64: dts: ti: k3-j721e-main: Add PCIe device tree nodes
Add PCIe device tree node (both RC and EP) for the four
PCIe instances here.
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 218 ++
arch/arm64/boot/dts/ti/k3-j721e.dtsi | 5 +-
2 files changed, 222 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
index d14060207f00..2090fcf667a3 100644
--- a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
@@ -28,6 +28,26 @@
#size-cells = <1>;
ranges = <0x0 0x0 0x0010 0x1c000>;
+ pcie0_ctrl: pcie-ctrl@4070 {
+ compatible = "syscon";
+ reg = <0x4070 0x4>;
+ };
+
+ pcie1_ctrl: pcie-ctrl@4074 {
+ compatible = "syscon";
+ reg = <0x4074 0x4>;
+ };
+
+ pcie2_ctrl: pcie-ctrl@4078 {
+ compatible = "syscon";
+ reg = <0x4078 0x4>;
+ };
+
+ pcie3_ctrl: pcie-ctrl@407c {
+ compatible = "syscon";
+ reg = <0x407c 0x4>;
+ };
+
serdes_ln_ctrl: serdes-ln-ctrl@4080 {
compatible = "mmio-mux";
reg = <0x4080 0x50>;
@@ -552,6 +572,204 @@
};
};
+ pcie0_rc: pcie@290 {
+ compatible = "ti,j721e-pcie-host";
+ reg = <0x00 0x0290 0x00 0x1000>,
+ <0x00 0x02907000 0x00 0x400>,
+ <0x00 0x0d00 0x00 0x0080>,
+ <0x00 0x1000 0x00 0x1000>;
+ reg-names = "intd_cfg", "user_cfg", "reg", "cfg";
+ interrupt-names = "link_state";
+ interrupts = ;
+ device_type = "pci";
+ ti,syscon-pcie-ctrl = <_ctrl>;
+ max-link-speed = <3>;
+ num-lanes = <2>;
+ power-domains = <_pds 239 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <_clks 239 1>;
+ clock-names = "fck";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ bus-range = <0x0 0xf>;
+ vendor-id = <0x104c>;
+ device-id = <0xb00d>;
+ msi-map = <0x0 _its 0x0 0x1>;
+ dma-coherent;
+ ranges = <0x0100 0x0 0x10001000 0x0 0x10001000 0x0
0x001>,
+<0x0200 0x0 0x10011000 0x0 0x10011000 0x0
0x7fef000>;
+ dma-ranges = <0x0200 0x0 0x0 0x0 0x0 0x1 0x0>;
+ };
+
+ pcie0_ep: pcie-ep@290 {
+ compatible = "ti,j721e-pcie-ep";
+ reg = <0x00 0x0290 0x00 0x1000>,
+ <0x00 0x02907000 0x00 0x400>,
+ <0x00 0x0d00 0x00 0x0080>,
+ <0x00 0x1000 0x00 0x0800>;
+ reg-names = "intd_cfg", "user_cfg", "reg", "mem";
+ interrupt-names = "link_state";
+ interrupts = ;
+ ti,syscon-pcie-ctrl = <_ctrl>;
+ max-link-speed = <3>;
+ num-lanes = <2>;
+ power-domains = <_pds 239 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <_clks 239 1>;
+ clock-names = "fck";
+ cdns,max-outbound-regions = <16>;
+ max-functions = /bits/ 8 <6>;
+ max-virtual-functions = /bits/ 16 <4 4 4 4 0 0>;
+ dma-coherent;
+ };
+
+ pcie1_rc: pcie@291 {
+ compatible = "ti,j721e-pcie-host";
+ reg = <0x00 0x0291 0x00 0x1000>,
+ <0x00 0x02917000 0x00 0x400>,
+ <0x00 0x0d80 0x00 0x0080>,
+ <0x00 0x1800 0x00 0x1000>;
+ reg-names = "intd_cfg", "user_cfg", "reg", "cfg";
+ interrupt-names = "link_state";
+ interrupts = ;
+ device_type = "pci";
+ ti,syscon-pcie-ctrl = <_ctrl>;
+ max-link-speed = <3>;
+ num-lanes = <2>;
+ power-domains = <_pds 240 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <_clks 240 1>;
+ clock-names = "fck";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ bus-range = <0x0 0xf>;
+ vendor-id = <0x104c>;
+ device-id = <0xb00d>;
+ msi-map = <0x0 _its 0x1 0x1>;
+ dma-coherent;
+ ranges = <0x0100 0x0 0x18001000 0x0 0x18001000 0x0
0x001>,
+<0x0200 0x0 0x18011000 0x0 0x18011000 0x0
0x7fef000>;
+ dma-ranges = <0x0200 0x0 0x0 0x0 0x0 0x1 0x0>;
+ };
+
+ pcie1_ep: pcie-ep@291 {
+
[PATCH 2/2] arm64: dts: ti: k3-j721e-common-proc-board: Configure the PCIe instances
J721E Common Processor Board has PCIe connectors for the 1st three PCIe
instances. Configure the three PCIe instances in RC mode and disable the
4th PCIe instance.
Signed-off-by: Kishon Vijay Abraham I
---
.../dts/ti/k3-j721e-common-proc-board.dts | 80 +++
1 file changed, 80 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts
b/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts
index 8bc1e6ecc50e..29be88811132 100644
--- a/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts
+++ b/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts
@@ -651,3 +651,83 @@
status = "okay";
};
+
+ {
+ serdes0_pcie_link: link@0 {
+ reg = <0>;
+ cdns,num-lanes = <1>;
+ #phy-cells = <0>;
+ cdns,phy-type = ;
+ resets = <_wiz0 1>;
+ };
+};
+
+ {
+ serdes1_pcie_link: link@0 {
+ reg = <0>;
+ cdns,num-lanes = <2>;
+ #phy-cells = <0>;
+ cdns,phy-type = ;
+ resets = <_wiz1 1>, <_wiz1 2>;
+ };
+};
+
+ {
+ serdes2_pcie_link: link@0 {
+ reg = <0>;
+ cdns,num-lanes = <2>;
+ #phy-cells = <0>;
+ cdns,phy-type = ;
+ resets = <_wiz2 1>, <_wiz2 2>;
+ };
+};
+
+_rc {
+ reset-gpios = < 6 GPIO_ACTIVE_HIGH>;
+ phys = <_pcie_link>;
+ phy-names = "pcie-phy";
+ num-lanes = <1>;
+};
+
+_rc {
+ reset-gpios = < 2 GPIO_ACTIVE_HIGH>;
+ phys = <_pcie_link>;
+ phy-names = "pcie-phy";
+ num-lanes = <2>;
+};
+
+_rc {
+ reset-gpios = < 20 GPIO_ACTIVE_HIGH>;
+ phys = <_pcie_link>;
+ phy-names = "pcie-phy";
+ num-lanes = <2>;
+};
+
+_ep {
+ phys = <_pcie_link>;
+ phy-names = "pcie-phy";
+ num-lanes = <1>;
+ status = "disabled";
+};
+
+_ep {
+ phys = <_pcie_link>;
+ phy-names = "pcie-phy";
+ num-lanes = <2>;
+ status = "disabled";
+};
+
+_ep {
+ phys = <_pcie_link>;
+ phy-names = "pcie-phy";
+ num-lanes = <2>;
+ status = "disabled";
+};
+
+_rc {
+ status = "disabled";
+};
+
+_ep {
+ status = "disabled";
+};
--
2.17.1
[PATCH 0/2] Add DT to get PCIe working in J721E SoC
Series adds device tree of I2C and PCIe DT nodes to get PCIe working in both RC mode and EP mode in J721E. The PCIe support patch series is queued in Lorenzo's branch [1] This patch series is rebased to Tero's ti-k3-next branch [2] [1] -> https://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/pci.git/log/?h=pci/cadence [2] -> https://git.kernel.org/pub/scm/linux/kernel/git/kristo/linux.git/log/?h=ti-k3-next Kishon Vijay Abraham I (2): arm64: dts: ti: k3-j721e-main: Add PCIe device tree nodes arm64: dts: ti: k3-j721e-common-proc-board: Configure the PCIe instances .../dts/ti/k3-j721e-common-proc-board.dts | 80 +++ arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 218 ++ arch/arm64/boot/dts/ti/k3-j721e.dtsi | 5 +- 3 files changed, 302 insertions(+), 1 deletion(-) -- 2.17.1
Re: [PATCHv3 00/19] perf metric: Add support to reuse metric
On 7/21/20 12:46 AM, Jiri Olsa wrote:
> On Mon, Jul 20, 2020 at 02:32:40PM +0530, kajoljain wrote:
>>
>>
>> On 7/20/20 1:49 PM, Jiri Olsa wrote:
>>> On Mon, Jul 20, 2020 at 01:39:24PM +0530, kajoljain wrote:
>>>
>>> SNIP
>>>
This is with your perf/metric branch:
command# ./perf stat -M PowerBUS_Frequency -C 0 -I 1000
assertion failed at util/metricgroup.c:709
# time counts unit events
1.54545 7,807,505 hv_24x7/pm_pb_cyc,chip=0/ #
2.0 GHz PowerBUS_Frequency_0
1.54545 7,807,485 hv_24x7/pm_pb_cyc,chip=1/
2.000232761 7,807,500 hv_24x7/pm_pb_cyc,chip=0/ #
2.0 GHz PowerBUS_Frequency_0
2.000232761 7,807,478 hv_24x7/pm_pb_cyc,chip=1/
3.000363762 7,799,665 hv_24x7/pm_pb_cyc,chip=0/ #
1.9 GHz PowerBUS_Frequency_0
3.000363762 7,807,502 hv_24x7/pm_pb_cyc,chip=1/
^C 3.259418599 2,022,150 hv_24x7/pm_pb_cyc,chip=0/ #
0.5 GHz PowerBUS_Frequency_0
3.259418599 2,022,164 hv_24x7/pm_pb_cyc,chip=1/
Performance counter stats for 'CPU(s) 0':
25,436,820 hv_24x7/pm_pb_cyc,chip=0/ # 6.4 GHz
PowerBUS_Frequency_0
25,444,629 hv_24x7/pm_pb_cyc,chip=1/
3.259505529 seconds time elapsed
>>>
>>> I found the bug, we are not adding runtime metrics as standalone ones,
>>> but as referenced metrics.. will fix and try to add test for that
>>>
>>> as for testing.. do I need some special ppc server to have support for
>>> this?
>>
>> Hi jiri,
>> We need power9 lpar machine and need to make sure `CONFIG_HV_PERF_CTRS`
>> is
>> enabled.
>
> could you please try with following patch on top?
Hi Jiri,
The change looks good to me. I tried with adding this patch on top of
your perf/metric branch. It did resolve the issue of not printing
all chips data. And now I can see proper values for hv-24x7 metric events.
I was also trying by adding new metric using the feature added in this patchset
with something like this:
diff --git a/tools/perf/pmu-events/arch/powerpc/power9/nest_metrics.json
b/tools/perf/pmu-events/arch/powerpc/power9/nest_metrics.json
index 8383a37647ad..dfe4bd63b587 100644
--- a/tools/perf/pmu-events/arch/powerpc/power9/nest_metrics.json
+++ b/tools/perf/pmu-events/arch/powerpc/power9/nest_metrics.json
@@ -16,6 +16,11 @@
"MetricName": "PowerBUS_Frequency",
"ScaleUnit": "2.5e-7GHz"
},
+{
+ "MetricExpr": "Memory_WR_BW_Chip + Memory_RD_BW_Chip",
+"MetricName": "Total_Memory_BW",
+"ScaleUnit": "1.6e-2MB"
+},
I guess as we have dependency on '?' symbol, I am not able to see all chips
data for Total_Memory_BW.
I am not sure if Its expected behavior?
This is what I am getting:
[root@ltc-zz189-lp4 perf]# ./perf stat --metric-only -M
Total_Memory_BW,Memory_WR_BW_Chip,Memory_RD_BW_Chip -I 1000 -C 0
# time MB Total_Memory_BW MB Memory_RD_BW_Chip_1 MB
Memory_WR_BW_Chip_1 MB Memory_WR_BW_Chip_0 MB Memory_RD_BW_Chip_0
1.67388 36.4 0.2
36.3 65.0 72.1
2.000374276 36.2 0.3
35.9 65.4 77.9
3.000543202 36.3 0.3
36.0 68.7 81.2
4.000702855 36.3 0.3
36.0 70.9 93.3
5.000856837 36.0 0.2
35.8 67.4 81.5
^C 5.367865273 13.2 0.1
13.1 23.5 28.3
Performance counter stats for 'CPU(s) 0':
194.4 1.3193.1
361.0434.3
5.368039176 seconds time elapsed
We can only get single chip data's sum in Total_Memory_BW. Please let me know
if I am missing something.
Thanks,
Kajol Jain
>
> thanks,
> jirka
>
>
> ---
> diff --git a/tools/perf/util/metricgroup.c b/tools/perf/util/metricgroup.c
> index 6f179b9903a0..03aa4bd4a38b 100644
> --- a/tools/perf/util/metricgroup.c
> +++ b/tools/perf/util/metricgroup.c
> @@ -820,11 +820,11 @@ static int add_metric(struct list_head *metric_list,
> struct expr_id *parent,
> struct expr_ids *ids);
>
> -static int
Re: [PATCH V17 3/3] Input: new da7280 haptic driver
On 7/23/20 10:47 PM, Roy Im wrote: > OK, thanks for your comments. To be clearer, I would like to update as below > if you agree > > depends on INPUT && I2C > ... > The haptics can be controlled by PWM or GPIO > with I2C communication. Yes, that sounds good. Thanks. -- ~Randy
RE: [PATCH V17 3/3] Input: new da7280 haptic driver
Friday, July 24, 2020 11:57 AM, Randy Dunlap wrote > On 7/23/20 6:54 PM, Roy Im wrote: > > On Fri, July 24, 2020 5:51 AM, Randy Dunlap wrote > >> On 7/23/20 8:01 AM, Roy Im wrote: > >>> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig > >>> index 362e8a0..06dc5a3 100644 > >>> --- a/drivers/input/misc/Kconfig > >>> +++ b/drivers/input/misc/Kconfig > >>> @@ -869,4 +869,17 @@ config INPUT_STPMIC1_ONKEY > >>> To compile this driver as a module, choose M here: the > >>> module will be called stpmic1_onkey. > >>> > >>> +config INPUT_DA7280_HAPTICS > >>> + tristate "Dialog Semiconductor DA7280 haptics support" > >>> + depends on INPUT && I2C > >>> + select INPUT_FF_MEMLESS > >>> + select REGMAP_I2C > >>> + help > >>> + Say Y to enable support for the Dialog DA7280 haptics driver. > >>> + The haptics can be controlled by I2C communication, > >>> + or by PWM input, or by GPI. > >> > >> Is thatGPIO. > >> ? > > The Haptics can be working by GPI(if see from the haptic device), but from > > the Host it is GPO. Do you think the GPIO is > correct? > > To me it needs to represent what services/interfaces/facilities are used by > this driver that are provided by the Linux kernel. > If it uses Linux GPIO services, then it should say GPIO -- although I don't > see it using any Linux GPIO services. OK, let me change to GPIO. > > >> > >> Can the haptics be controlled only by PWM or only by GPI(O)? > >> > >> Just curious: why is I2C required to build the driver if a user is only > >> controlling the device by PWM or GPI? > > > > I2C is required to control registers and it can be triggered by I2C or PWM > > or GPI(controlled by host outside this driver), > so PWM and GPI are optional. > > With your comments, I think it's better to remove below lines(//remove) to > > avoid confusion and add PWM as below if > you agree. > > // remove > > The haptics can be controlled by I2C communication, > > or by PWM input, or by GPI. > > // update, adding || PWM > > depends on (INPUT && I2C) || PWM > > Since provides stubs for when CONFIG_PWM is not enabled, it > appears that "depends on PWM" is not > required. > > I'll leave it up to you. I was just trying to understand better. > It may be that no changes are needed. OK, thanks for your comments. To be clearer, I would like to update as below if you agree depends on INPUT && I2C ... The haptics can be controlled by PWM or GPIO with I2C communication. > > > thanks. > -- > ~Randy Kind regards, Roy
Re: [PATCH v2 1/3] mm/shuffle: don't move pages between zones and don't read garbage memmaps
On Thu, Jul 23, 2020 at 08:08:46PM -0700, Andrew Morton wrote: >On Tue, 23 Jun 2020 17:30:18 +0800 Wei Yang > wrote: > >> On Tue, Jun 23, 2020 at 09:55:43AM +0200, David Hildenbrand wrote: >> >On 23.06.20 09:39, David Hildenbrand wrote: >> >>> Hmm.. I thought this is the behavior for early section, while it looks >> >>> current >> >>> code doesn't work like this: >> >>> >> >>>if (section_is_early && memmap) >> >>>free_map_bootmem(memmap); >> >>>else >> >>> depopulate_section_memmap(pfn, nr_pages, altmap); >> >>> >> >>> section_is_early is always "true" for early section, while memmap is >> >>> not-NULL >> >>> only when sub-section map is empty. >> >>> >> >>> If my understanding is correct, when we remove a sub-section in early >> >>> section, >> >>> the code would call depopulate_section_memmap(), which in turn free >> >>> related >> >>> memmap. By removing the memmap, the return value from >> >>> pfn_to_online_page() is >> >>> not a valid one. >> >> >> >> I think you're right, and pfn_valid() would also return true, as it is >> >> an early section. This looks broken. >> >> >> >>> >> >>> Maybe we want to write the code like this: >> >>> >> >>>if (section_is_early) >> >>>if (memmap) >> >>>free_map_bootmem(memmap); >> >>>else >> >>> depopulate_section_memmap(pfn, nr_pages, altmap); >> >>> >> >> >> >> I guess that should be the way to go >> >> >> >> @Dan, I think what Wei proposes here is correct, right? Or how does it >> >> work in the VMEMMAP case with early sections? >> >> >> > >> >Especially, if you would re-hot-add, section_activate() would assume >> >there is a memmap, it must not be removed. >> > >> >> You are right here. I didn't notice it. >> >> >@Wei, can you send a patch? >> > >> >> Sure, let me prepare for it. > >Still awaiting this, and the v3 patch was identical to this v2 patch. > >It's tagged for -stable, so there's some urgency. Should we just go >ahead with the decently-tested v2? This message is to me right? I thought the fix patch is merged, the patch link may be https://lkml.org/lkml/2020/6/23/380. If I missed something, just let me know. -- Wei Yang Help you, Help me
INFO: rcu detected stall in rtnl_newlink
Hello, syzbot found the following issue on: HEAD commit:e6827d1a cxgb4: add missing release on skb in uld_send() git tree: net console output: https://syzkaller.appspot.com/x/log.txt?x=17a227b490 kernel config: https://syzkaller.appspot.com/x/.config?x=dddbcb5a9f4192db dashboard link: https://syzkaller.appspot.com/bug?extid=d46d08c4209a3a86ccc5 compiler: gcc (GCC) 10.1.0-syz 20200507 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15a3822890 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1302e4c490 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+d46d08c4209a3a86c...@syzkaller.appspotmail.com rcu: INFO: rcu_preempt self-detected stall on CPU rcu:1-: (10491 ticks this GP) idle=5d2/1/0x4000 softirq=10100/10100 fqs=5226 (t=10500 jiffies g=8229 q=552) NMI backtrace for cpu 1 CPU: 1 PID: 6812 Comm: syz-executor138 Not tainted 5.8.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x18f/0x20d lib/dump_stack.c:118 nmi_cpu_backtrace.cold+0x70/0xb1 lib/nmi_backtrace.c:101 nmi_trigger_cpumask_backtrace+0x1b3/0x223 lib/nmi_backtrace.c:62 trigger_single_cpu_backtrace include/linux/nmi.h:164 [inline] rcu_dump_cpu_stacks+0x194/0x1cf kernel/rcu/tree_stall.h:320 print_cpu_stall kernel/rcu/tree_stall.h:553 [inline] check_cpu_stall kernel/rcu/tree_stall.h:627 [inline] rcu_pending kernel/rcu/tree.c:3489 [inline] rcu_sched_clock_irq.cold+0x5b3/0xccc kernel/rcu/tree.c:2504 update_process_times+0x25/0x60 kernel/time/timer.c:1726 tick_sched_handle+0x9b/0x180 kernel/time/tick-sched.c:176 tick_sched_timer+0x108/0x290 kernel/time/tick-sched.c:1320 __run_hrtimer kernel/time/hrtimer.c:1520 [inline] __hrtimer_run_queues+0x1d5/0xfc0 kernel/time/hrtimer.c:1584 hrtimer_interrupt+0x32a/0x930 kernel/time/hrtimer.c:1646 local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1080 [inline] __sysvec_apic_timer_interrupt+0x142/0x5e0 arch/x86/kernel/apic/apic.c:1097 asm_call_on_stack+0xf/0x20 arch/x86/entry/entry_64.S:711 __run_on_irqstack arch/x86/include/asm/irq_stack.h:22 [inline] run_on_irqstack_cond arch/x86/include/asm/irq_stack.h:48 [inline] sysvec_apic_timer_interrupt+0xe0/0x120 arch/x86/kernel/apic/apic.c:1091 asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:587 RIP: 0010:should_resched arch/x86/include/asm/preempt.h:102 [inline] RIP: 0010:__local_bh_enable_ip+0x189/0x250 kernel/softirq.c:196 Code: 89 48 ba 00 00 00 00 00 fc ff df 48 c1 e8 03 80 3c 10 00 0f 85 c4 00 00 00 48 83 3d 60 5a 6e 08 00 74 7b fb 66 0f 1f 44 00 00 <65> 8b 05 80 78 bb 7e 85 c0 74 6b 5b 5d 41 5c c3 80 3d a3 6a 63 09 RSP: 0018:c90001816d80 EFLAGS: 0286 RAX: 11369c12 RBX: 0201 RCX: 0002 RDX: dc00 RSI: RDI: 81468609 RBP: 87cdbce5 R08: R09: R10: 0001 R11: R12: 8880a9298400 R13: 0001 R14: 0034 R15: dc00 spin_unlock_bh include/linux/spinlock.h:398 [inline] batadv_tt_local_purge+0x285/0x370 net/batman-adv/translation-table.c:1446 batadv_tt_local_resize_to_mtu+0x8e/0x130 net/batman-adv/translation-table.c:4197 batadv_hardif_activate_interface.part.0.cold+0x14c/0x1ba net/batman-adv/hard-interface.c:653 batadv_hardif_activate_interface net/batman-adv/hard-interface.c:800 [inline] batadv_hardif_enable_interface+0xa7d/0xb10 net/batman-adv/hard-interface.c:792 batadv_softif_slave_add+0x92/0x150 net/batman-adv/soft-interface.c:892 do_set_master+0x1c8/0x220 net/core/rtnetlink.c:2476 do_setlink+0x903/0x35c0 net/core/rtnetlink.c:2611 __rtnl_newlink+0xc21/0x1750 net/core/rtnetlink.c:3272 rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3398 rtnetlink_rcv_msg+0x44e/0xad0 net/core/rtnetlink.c:5461 netlink_rcv_skb+0x15a/0x430 net/netlink/af_netlink.c:2469 netlink_unicast_kernel net/netlink/af_netlink.c:1303 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1329 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1918 sock_sendmsg_nosec net/socket.c:652 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:672 sys_sendmsg+0x6e8/0x810 net/socket.c:2352 ___sys_sendmsg+0xf3/0x170 net/socket.c:2406 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2439 do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:384 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x4437d9 Code: Bad RIP value. RSP: 002b:7ffdfad85898 EFLAGS: 0246 ORIG_RAX: 002e RAX: ffda RBX: 0003 RCX: 004437d9 RDX: RSI: 2140 RDI: 0004 RBP: 7ffdfad858a0 R08: 01bb R09: 01bb R10: 01bb R11: 0246 R12: 7ffdfad858b0 R13: R14: R15: ---
Re: [PATCH v5 10/10] bus: mhi: core: Introduce sysfs entries for MHI
On Thu, Jul 23, 2020 at 03:36:42PM -0700, Bhaumik Bhatt wrote:
> Introduce sysfs entries to enable userspace clients the ability to read
> the serial number and the OEM PK Hash values obtained from BHI. OEMs
> need to read these device-specific hardware information values through
> userspace for factory testing purposes and cannot be exposed via degbufs
> as it may remain disabled for performance reasons. Also, update the
> documentation for ABI to include these entries.
>
> Signed-off-by: Bhaumik Bhatt
> ---
> Documentation/ABI/stable/sysfs-bus-mhi | 25
> MAINTAINERS| 1 +
> drivers/bus/mhi/core/init.c| 53
> ++
> 3 files changed, 79 insertions(+)
> create mode 100644 Documentation/ABI/stable/sysfs-bus-mhi
>
> diff --git a/Documentation/ABI/stable/sysfs-bus-mhi
> b/Documentation/ABI/stable/sysfs-bus-mhi
> new file mode 100644
> index 000..a4e4bd2
> --- /dev/null
> +++ b/Documentation/ABI/stable/sysfs-bus-mhi
> @@ -0,0 +1,25 @@
> +What:/sys/bus/mhi/devices/.../serialnumber
> +Date:July 2020
> +KernelVersion: 5.8
> +Contact: Bhaumik Bhatt
> +Description:
> + The file holds the serial number of the client device obtained
> + using a BHI (Boot Host Interface) register read after at least
> + one attempt to power up the device has been done. If read
> + without having the device power on at least once, the file will
> + read all 0's.
> +Users: Any userspace application or clients interested in the
> device
> + hardware information.
Please align all the fields onto a single starting point. Have a look at other
ABI documentation like, Documentation/ABI/stable/sysfs-bus-vmbus.
> +
> +What:/sys/bus/mhi/devices/.../oem_pk_hash
> +Date:July 2020
> +KernelVersion: 5.8
> +Contact: Bhaumik Bhatt
> +Description:
> + The file holds the OEM PK Hash value of the endpoint device
> + obtained using a BHI (Boot Host Interface) register read after
> + at least one attempt to power up the device has been done. If
> + read without having the device power on at least once, the file
> + will read all 0's.
> +Users: Any userspace application or clients interested in the
> device
> + hardware information.
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e64e5db..5e49316 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11018,6 +11018,7 @@ M:Hemant Kumar
> L: linux-arm-...@vger.kernel.org
> S: Maintained
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/mani/mhi.git
> +F: Documentation/ABI/stable/sysfs-bus-mhi
> F: Documentation/mhi/
> F: drivers/bus/mhi/
> F: include/linux/mhi.h
> diff --git a/drivers/bus/mhi/core/init.c b/drivers/bus/mhi/core/init.c
> index d2c0f6e..a7b0d76 100644
> --- a/drivers/bus/mhi/core/init.c
> +++ b/drivers/bus/mhi/core/init.c
> @@ -76,6 +76,56 @@ const char *to_mhi_pm_state_str(enum mhi_pm_state state)
> return mhi_pm_state_str[index];
> }
>
> +static ssize_t serial_number_show(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
We haven't followed this before but it is good to align the function parameters
with respect to '('.
> +{
> + struct mhi_device *mhi_dev = to_mhi_device(dev);
> + struct mhi_controller *mhi_cntrl = mhi_dev->mhi_cntrl;
> +
> + return snprintf(buf, PAGE_SIZE, "Serial Number: %u\n",
> + mhi_cntrl->serial_number);
We need to think about what happens if the mhi_cntrl structure is not zero
initialized by the controller driver. All throughout the stack we assume that
the mhi_cntrl struct is zero initialized but things can go awry if it was not
the case!
There was one API in the downstream (mhi_alloc_controller()) for this purpose
but I removed it since we ended up with just a kzalloc(). Does it make sense to
introduce it now?
Thanks,
Mani
> +}
> +static DEVICE_ATTR_RO(serial_number);
> +
> +static ssize_t oem_pk_hash_show(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + struct mhi_device *mhi_dev = to_mhi_device(dev);
> + struct mhi_controller *mhi_cntrl = mhi_dev->mhi_cntrl;
> + int i, cnt = 0;
> +
> + for (i = 0; i < ARRAY_SIZE(mhi_cntrl->oem_pk_hash); i++)
> + cnt += snprintf(buf + cnt, PAGE_SIZE - cnt,
> + "OEMPKHASH[%d]: 0x%x\n", i,
> + mhi_cntrl->oem_pk_hash[i]);
> +
> + return cnt;
> +}
> +static DEVICE_ATTR_RO(oem_pk_hash);
> +
> +static struct attribute *mhi_sysfs_attrs[] = {
> + _attr_serial_number.attr,
> + _attr_oem_pk_hash.attr,
> + NULL,
> +};
> +
> +static const struct attribute_group
Re: [PATCH v9 2/7] dt-bindings: pinctrl: add bindings for MediaTek MT6779 SoC
On Thu, 2020-07-23 at 09:51 -0600, Rob Herring wrote: > On Thu, 23 Jul 2020 19:19:52 +0800, Hanks Chen wrote: > > From: Andy Teng > > > > Add devicetree bindings for MediaTek MT6779 pinctrl driver. > > > > Reviewed-by: Rob Herring > > Signed-off-by: Andy Teng > > Signed-off-by: Hanks Chen > > --- > > .../pinctrl/mediatek,mt6779-pinctrl.yaml | 197 ++ > > 1 file changed, 197 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/pinctrl/mediatek,mt6779-pinctrl.yaml > > > > > My bot found errors running 'make dt_binding_check' on your patch: > > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/pinctrl/mediatek,mt6779-pinctrl.example.dt.yaml: > example-0: pinctrl@10005000:reg:0: [0, 268455936, 0, 4096] is too long > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/pinctrl/mediatek,mt6779-pinctrl.example.dt.yaml: > example-0: pinctrl@10005000:reg:1: [0, 297926656, 0, 4096] is too long > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/pinctrl/mediatek,mt6779-pinctrl.example.dt.yaml: > example-0: pinctrl@10005000:reg:2: [0, 298909696, 0, 4096] is too long > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/pinctrl/mediatek,mt6779-pinctrl.example.dt.yaml: > example-0: pinctrl@10005000:reg:3: [0, 300023808, 0, 4096] is too long > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/pinctrl/mediatek,mt6779-pinctrl.example.dt.yaml: > example-0: pinctrl@10005000:reg:4: [0, 300351488, 0, 4096] is too long > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/pinctrl/mediatek,mt6779-pinctrl.example.dt.yaml: > example-0: pinctrl@10005000:reg:5: [0, 300548096, 0, 4096] is too long > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/pinctrl/mediatek,mt6779-pinctrl.example.dt.yaml: > example-0: pinctrl@10005000:reg:6: [0, 301072384, 0, 4096] is too long > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/pinctrl/mediatek,mt6779-pinctrl.example.dt.yaml: > example-0: pinctrl@10005000:reg:7: [0, 301137920, 0, 4096] is too long > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/pinctrl/mediatek,mt6779-pinctrl.example.dt.yaml: > example-0: pinctrl@10005000:reg:8: [0, 268480512, 0, 4096] is too long > > > See > https://urldefense.com/v3/__https://patchwork.ozlabs.org/patch/1334743__;!!CTRNKA9wMg0ARbw!xVq21s-Vaw3If1-Q8EWJEDBBIUp0j30PIaGQWDyhCftbcOgFrjRqZMNHoHgOXksD3g$ > > > If you already ran 'make dt_binding_check' and didn't see the above > error(s), then make sure dt-schema is up to date: > > pip3 install git+https://github.com/devicetree-org/dt-schema.git@master > --upgrade > > Please check and re-submit. > Hi Rob, It's my fault I could reproduce the error log after dt-schema updates to the latest version. I'll fix it in next version. Thanks! Hanks Chen
Re: [Softirq] a76eadba0d: WARNING:at_net/mac80211/rx.c:#ieee80211_rx_napi[mac80211]
On Thu, Jul 23, 2020 at 10:35 PM Thomas Gleixner wrote:
>
> jun qian writes:
> > On Thu, Jul 23, 2020 at 6:58 PM Thomas Gleixner wrote:
> >> That drops everything which has not yet been processed and the above
> >> warning is due to this.
> >>
> > wow, I made a mistake, thank you for finding the cause of the problem
> > so quickly.
> >
> > How about the following code. we need to clear the corresponding
> > pending bit at the
> > right time Instead of all the pending bits cleared in the start.
> >
> > pending = softirq_pending();
> >
> > while ((softirq_bit = ffs(pending))) {
> >
> > pending >>= softirq_bit;
> >
> > set_softirq_pending(pending); //Only clear the corresponding
> > bit which will be processed.
>
> How is that supposed to be correct. pending has been shifted
> right. Something like this should work:
>
> h++;
> pending >>= softirq_bit;
>
> if (timeout()) {
> /*
> * Ensure that the remaining pending bits
> * are handled.
> */
> or_softirq_pending(pending << (vec_nr + 1));
> break;
> }
> }
>
> Thanks,
>
> tglx
>
I have two questions that need to be discussed.
1. If the __do_sofrirq() is executed in the ksoftirqd, we may not need
to check the timeout in the loop.
2. Both the invoke_softirq() and run_ksoftirqd() will execute
__do_sofirq, they all execute the same code，
when it is in the ksoftirqd, Do we need to wake up ksoftirqd in
the process context according to
max_restart and MAX_SOFTIRQ_TIME. In my opinion, If we use a flag
to distinguish where
__do_softirq() is called from, we can do what is most suitable
for __do_softirq based on this flag.
Re: [PATCH] tty: Add MOXA NPort Real TTY Driver
Hi "Johnson, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on tty/tty-testing] [also build test WARNING on v5.8-rc6 next-20200723] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Johnson-CH-Chen/tty-Add-MOXA-NPort-Real-TTY-Driver/20200714-142712 base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tty-testing config: mips-randconfig-s032-20200723 (attached as .config) compiler: mipsel-linux-gcc (GCC) 9.3.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # apt-get install sparse # sparse version: v0.6.2-93-g4c6cbe55-dirty # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=mips If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot sparse warnings: (new ones prefixed by >>) drivers/tty/npreal2.c:1107:26: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void [noderef] __user *to @@ got struct serial_struct *retinfo @@ drivers/tty/npreal2.c:1107:26: sparse: expected void [noderef] __user *to drivers/tty/npreal2.c:1107:26: sparse: got struct serial_struct *retinfo drivers/tty/npreal2.c:1122:56: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void const [noderef] __user *from @@ got struct serial_struct *new_info @@ drivers/tty/npreal2.c:1122:56: sparse: expected void const [noderef] __user *from drivers/tty/npreal2.c:1122:56: sparse: got struct serial_struct *new_info drivers/tty/npreal2.c:1149:57: sparse: sparse: Using plain integer as NULL pointer drivers/tty/npreal2.c:1186:9: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected unsigned int [noderef] __user *__pu_addr @@ got unsigned int *value @@ drivers/tty/npreal2.c:1186:9: sparse: expected unsigned int [noderef] __user *__pu_addr drivers/tty/npreal2.c:1186:9: sparse: got unsigned int *value drivers/tty/npreal2.c:1624:38: sparse: sparse: Using plain integer as NULL pointer drivers/tty/npreal2.c:1897:34: sparse: sparse: Using plain integer as NULL pointer drivers/tty/npreal2.c:1914:21: sparse: sparse: Using plain integer as NULL pointer drivers/tty/npreal2.c:1984:46: sparse: sparse: Using plain integer as NULL pointer drivers/tty/npreal2.c:2261:17: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected unsigned long [noderef] __user *__pu_addr @@ got unsigned long * @@ drivers/tty/npreal2.c:2261:17: sparse: expected unsigned long [noderef] __user *__pu_addr drivers/tty/npreal2.c:2261:17: sparse: got unsigned long * >> drivers/tty/npreal2.c:2265:17: sparse: sparse: incorrect type in initializer >> (different address spaces) @@ expected unsigned long const [noderef] >> __user *__gu_ptr @@ got unsigned long * @@ >> drivers/tty/npreal2.c:2265:17: sparse: expected unsigned long const >> [noderef] __user *__gu_ptr drivers/tty/npreal2.c:2265:17: sparse: got unsigned long * drivers/tty/npreal2.c:2319:21: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected int [noderef] __user *__pu_addr @@ got int * @@ drivers/tty/npreal2.c:2319:21: sparse: expected int [noderef] __user *__pu_addr drivers/tty/npreal2.c:2319:21: sparse: got int * drivers/tty/npreal2.c:2319:62: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected int [noderef] __user *__pu_addr @@ got int * @@ drivers/tty/npreal2.c:2319:62: sparse: expected int [noderef] __user *__pu_addr drivers/tty/npreal2.c:2319:62: sparse: got int * drivers/tty/npreal2.c:2320:25: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected int [noderef] __user *__pu_addr @@ got int * @@ drivers/tty/npreal2.c:2320:25: sparse: expected int [noderef] __user *__pu_addr drivers/tty/npreal2.c:2320:25: sparse: got int * drivers/tty/npreal2.c:2321:25: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected int [noderef] __user *__pu_addr @@ got int * @@ drivers/tty/npreal2.c:2321:25: sparse: expected int [noderef] __user *__pu_addr drivers/tty/npreal2.c:2321:25: sparse: got int * drivers/tty/npreal2.c:2322:25: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected int [noderef] __user *__pu_addr @@ got int * @@
Re: [PATCH v2 0/3] ARM: dts: aspeed: fixup wedge40 device tree
On Thu, 23 Jul 2020 at 23:05, wrote: > > From: Tao Ren > > The patch series update several devices' settings in Facebook Wedge40 > device tree. > > Patch #1 disables a few i2c controllers as they are not being used at > present. > > Patch #2 enables adc device for voltage monitoring. > > Patch #3 enables pwm_tacho device for fan control and monitoring. > > Tao Ren (3): > ARM: dts: aspeed: wedge40: disable a few i2c controllers > ARM: dts: aspeed: wedge40: enable adc device > ARM: dts: aspeed: wedge40: enable pwm_tacho device I have merged this series into the aspeed dt-for-5.9 branch. Cheers, Joel > > .../boot/dts/aspeed-bmc-facebook-wedge40.dts | 42 +++ > 1 file changed, 34 insertions(+), 8 deletions(-) > > -- > 2.17.1 >
Re: [PATCH v5 bpf-next 5/5] selftests/bpf: add get_stackid_cannot_attach
On Thu, Jul 23, 2020 at 11:06:48AM -0700, Song Liu wrote:
> + pmu_fd = syscall(__NR_perf_event_open, , -1 /* pid */,
> + 0 /* cpu 0 */, -1 /* group id */,
> + 0 /* flags */);
> + if (pmu_fd < 0 && errno == ENOENT) {
> + printf("%s:SKIP:cannot open PERF_COUNT_HW_CPU_CYCLES with
> precise_ip > 0\n",
> +__func__);
> + test__skip();
> + goto cleanup;
> + }
That wasn't enough in my test VM.
I've changed it to be: (errno == ENOENT || errno == EOPNOTSUPP)
and applied the set.
Thanks
Re: [PATCH v2] ARM: dts: aspeed: cmm: fixup i2c tree
On Thu, 23 Jul 2020 at 23:08, wrote: > > From: Tao Ren > > Create all the i2c switches in device tree and use aliases to assign > child channels with consistent bus numbers. > > Besides, "i2c-mux-idle-disconnect" is set for all the i2c switches to > avoid potential conflicts when multiple devices (beind the switches) > use the same device address. > > Signed-off-by: Tao Ren Reviewed-by: Joel Stanley I have merged this patch into the aspeed dt-for-5.9 branch. Cheers, Joel > --- > Changes in v2: >- Nothing changed. Resending the patch just in case the previous > email was not delivered. > > arch/arm/boot/dts/aspeed-bmc-facebook-cmm.dts | 1231 - > 1 file changed, 1228 insertions(+), 3 deletions(-) > > diff --git a/arch/arm/boot/dts/aspeed-bmc-facebook-cmm.dts > b/arch/arm/boot/dts/aspeed-bmc-facebook-cmm.dts > index 016bbcb99bb6..7bc7df7ed428 100644 > --- a/arch/arm/boot/dts/aspeed-bmc-facebook-cmm.dts > +++ b/arch/arm/boot/dts/aspeed-bmc-facebook-cmm.dts > @@ -19,8 +19,8 @@ > serial3 = > > /* > -* Hardcode the bus number of i2c switches' channels to > -* avoid breaking the legacy applications. > +* PCA9548 (1-0077) provides 8 channels for connecting to > +* 4 Line Cards and 4 Fabric Cards. > */ > i2c16 = > i2c17 = > @@ -30,6 +30,11 @@ > i2c21 = > i2c22 = > i2c23 = > + > + /* > +* PCA9548 (2-0071) provides 8 channels for connecting to > +* Power Distribution Board. > +*/ > i2c24 = > i2c25 = > i2c26 = > @@ -38,6 +43,11 @@ > i2c29 = > i2c30 = > i2c31 = > + > + /* > +* PCA9548 (8-0077) provides 8 channels and the first 4 > +* channels are connecting to 4 Fan Control Boards. > +*/ > i2c32 = > i2c33 = > i2c34 = > @@ -46,6 +56,226 @@ > i2c37 = > i2c38 = > i2c39 = > + > + /* > +* 2 PCA9548 (18-0070 & 18-0073), 16 channels connecting > +* to Line Card #1. > +*/ > + i2c40 = > + i2c41 = > + i2c42 = > + i2c43 = > + i2c44 = > + i2c45 = > + i2c46 = > + i2c47 = > + i2c48 = > + i2c49 = > + i2c50 = > + i2c51 = > + i2c52 = > + i2c53 = > + i2c54 = > + i2c55 = > + > + /* > +* 2 PCA9548 (19-0070 & 19-0073), 16 channels connecting > +* to Line Card #2. > +*/ > + i2c56 = > + i2c57 = > + i2c58 = > + i2c59 = > + i2c60 = > + i2c61 = > + i2c62 = > + i2c63 = > + i2c64 = > + i2c65 = > + i2c66 = > + i2c67 = > + i2c68 = > + i2c69 = > + i2c70 = > + i2c71 = > + > + /* > +* 2 PCA9548 (20-0070 & 20-0073), 16 channels connecting > +* to Line Card #3. > +*/ > + i2c72 = > + i2c73 = > + i2c74 = > + i2c75 = > + i2c76 = > + i2c77 = > + i2c78 = > + i2c79 = > + i2c80 = > + i2c81 = > + i2c82 = > + i2c83 = > + i2c84 = > + i2c85 = > + i2c86 = > + i2c87 = > + > + /* > +* 2 PCA9548 (21-0070 & 21-0073), 16 channels connecting > +* to Line Card #4. > +*/ > + i2c88 = > + i2c89 = > + i2c90 = > + i2c91 = > + i2c92 = > + i2c93 = > + i2c94 = > + i2c95 = > + i2c96 = > + i2c97 = > + i2c98 = > + i2c99 = > + i2c100 = > + i2c101 = > + i2c102 = > + i2c103 = > + > + /* > +* 2 PCA9548 (16-0070 & 16-0073), 16 channels connecting > +* to Fabric Card #1. > +*/ > + i2c104 = > + i2c105 = > + i2c106 = > + i2c107 = > + i2c108 = > + i2c109 = > + i2c110 = > +
Re: [PATCH bpf-next v6 1/7] bpf: Renames to prepare for generalizing sk_storage.
On Thu, Jul 23, 2020 at 01:50:26PM +0200, KP Singh wrote: > From: KP Singh > > A purely mechanical change to split the renaming from the actual > generalization. > > Flags/consts: > > SK_STORAGE_CREATE_FLAG_MASK BPF_LOCAL_STORAGE_CREATE_FLAG_MASK > BPF_SK_STORAGE_CACHE_SIZE BPF_LOCAL_STORAGE_CACHE_SIZE > MAX_VALUE_SIZE BPF_LOCAL_STORAGE_MAX_VALUE_SIZE > > Structs: > > bucket bpf_local_storage_map_bucket > bpf_sk_storage_map bpf_local_storage_map > bpf_sk_storage_data bpf_local_storage_data > bpf_sk_storage_elem bpf_local_storage_elem > bpf_sk_storage bpf_local_storage > selem_linked_to_sk selem_linked_to_storage > selem_alloc bpf_selem_alloc > > The "sk" member in bpf_local_storage is also updated to "owner" > in preparation for changing the type to void * in a subsequent patch. > > Functions: > > __selem_unlink_sk bpf_selem_unlink_storage > __selem_link_sk bpf_selem_link_storage > selem_unlink_sk __bpf_selem_unlink_storage > sk_storage_update bpf_local_storage_update > __sk_storage_lookup bpf_local_storage_lookup > bpf_sk_storage_map_free bpf_local_storage_map_free > bpf_sk_storage_map_allocbpf_local_storage_map_alloc > bpf_sk_storage_map_alloc_check bpf_local_storage_map_alloc_check > bpf_sk_storage_map_check_btfbpf_local_storage_map_check_btf Thanks for separating this mechanical name change in a separate patch. It is much easier to follow. This patch looks good. A minor thought is, when I look at unlink_map() and unlink_storage(), it keeps me looking back for the lock situation. I think the main reason is the bpf_selem_unlink_map() is locked but bpf_selem_unlink_storage() is unlocked now. May be: bpf_selem_unlink_map() => bpf_selem_unlink_map_locked() bpf_selem_link_map()=> bpf_selem_link_map_locked() __bpf_selem_unlink_storage()=> bpf_selem_unlink_storage_locked() bpf_link_storage() means unlocked bpf_unlink_storage() means unlocked. I think it could be one follow-up patch later instead of interrupting multiple patches in this set for this minor thing. For now, lets continue with this and remember default is nolock for storage. I will continue tomorrow.
Re: [PATCH v2] af_key: pfkey_dump needs parameter validation
On Wed, Jul 22, 2020 at 04:00:53AM -0700, Mark Salyzyn wrote:
> In pfkey_dump() dplen and splen can both be specified to access the
> xfrm_address_t structure out of bounds in__xfrm_state_filter_match()
> when it calls addr_match() with the indexes. Return EINVAL if either
> are out of range.
>
> Signed-off-by: Mark Salyzyn
> Cc: net...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: kernel-t...@android.com
> Cc: Steffen Klassert
> Cc: Herbert Xu
> Cc: "David S. Miller"
> Cc: Jakub Kicinski
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Applied, thanks a lot!
Re: [PATCH v5 08/10] bus: mhi: core: Use counters to track MHI device state transitions
On Thu, Jul 23, 2020 at 03:36:40PM -0700, Bhaumik Bhatt wrote: > Use counters to track MHI device state transitions such as those > to M0, M2, or M3 states. This helps in better debug by allowing > the user to see the number of transitions to a certain state when > queried using the states debugfs entry. > > Signed-off-by: Bhaumik Bhatt This patch should come before the debugfs patch. Also the header addition should be here. Thanks, Mani > --- > drivers/bus/mhi/core/pm.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/bus/mhi/core/pm.c b/drivers/bus/mhi/core/pm.c > index 27bb471..ce4d969 100644 > --- a/drivers/bus/mhi/core/pm.c > +++ b/drivers/bus/mhi/core/pm.c > @@ -256,6 +256,7 @@ int mhi_pm_m0_transition(struct mhi_controller *mhi_cntrl) > dev_err(dev, "Unable to transition to M0 state\n"); > return -EIO; > } > + mhi_cntrl->M0++; > > /* Wake up the device */ > read_lock_bh(_cntrl->pm_lock); > @@ -326,6 +327,8 @@ void mhi_pm_m1_transition(struct mhi_controller > *mhi_cntrl) > mhi_cntrl->dev_state = MHI_STATE_M2; > > write_unlock_irq(_cntrl->pm_lock); > + > + mhi_cntrl->M2++; > wake_up_all(_cntrl->state_event); > > /* If there are any pending resources, exit M2 immediately */ > @@ -362,6 +365,7 @@ int mhi_pm_m3_transition(struct mhi_controller *mhi_cntrl) > return -EIO; > } > > + mhi_cntrl->M3++; > wake_up_all(_cntrl->state_event); > > return 0; > -- > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, > a Linux Foundation Collaborative Project >
RE: [PATCH 1/2] platform/x86: Add Intel Input Output Manager (IOM) driver
Hi Greg,
> Subject: Re: [PATCH 1/2] platform/x86: Add Intel Input Output Manager (IOM)
> driver
...
> > > > +struct intel_iom {
> > > > + struct device *dev;
> > > > + void __iomem *regbar;
> > > > +};
> > > > +
> > > > +static struct intel_iom iom_dev;
> > >
> > > Why just one? Why is this static?
> > >
> >
> > There is just one IOM device in the system.
>
> For today, yes, no need to force yourself to have to change this in the
> future.
> Just use a normal per-instance variable instead please, if you really need it.
>
Ack
> > > > +
> > > > + /* Prevent this driver from being unloaded while in use */
> > > > + if (!try_module_get(dev->driver->owner)) {
> > >
> > > Why are you poking around in a random device's driver's owner?
> > >
> > > That's not ok. And probably totally racy.
> > >
> > > Handle module reference counts properly, not like this.
> > >
> >
> > Ack. Will use THIS_MODULE here.
>
> No, that is not the answer, and is always wrong to use :(
>
This should not matter anymore, as I find reference counting may not be needed.
> > > And why does it even matter that you incremented the module
> > > reference count? What is that "protecting" you from?
> > >
> >
> > To prevent this driver from being unloaded, while it is being used.
>
> Why does that matter? Shouldn't normal reference counting and
> dependancies be all that you need?
>
I find just dependencies are enough to prevent the driver from being unloaded.
With Intel PMC USB mux control driver, not using
intel_iom_get()/intel_iom_put(),
just invoking intel_iom_port_status() is enough for rmmod to report failure
(citing the use by intel_pmc_mux) in unloading the IOM driver.
> > > > + put_device(iom_dev.dev);
> > > > + return ERR_PTR(-EBUSY);
> > > > + }
> > > > +
> > > > + return _dev;
> > > > +}
> > > > +EXPORT_SYMBOL_GPL(intel_iom_get);
> > >
> > > Who calls this function?
> > >
> >
> > Intel PMC USB mux control driver, in this case.
> > The callers are expected to call intel_iom_get() before using the
> > intel_iom_port_status(), after which intel_iom_put() can be called to
> > release the IOM device instance.
>
> Why not just have a single call if all this driver does is support one thing.
> The
> reference counting shouldn't be needed at all, right?
>
Ack. That looks to be the case, based on my findings.
> > > > +/**
> > > > + * intel_iom_put() - Put IOM device instance
> > > > + * @iom: IOM device instance
> > > > + *
> > > > + * This function releases the IOM device instance created using
> > > > + * intel_iom_get() and allows the driver to be unloaded.
> > > > + *
> > > > + * Call intel_iom_put() to release the instance.
> > > > + */
> > > > +void intel_iom_put(struct intel_iom *iom) {
> > > > + if (!iom)
> > > > + return;
> > > > +
> > > > + module_put(iom->dev->driver->owner);
> > >
> > > And if the device doesn't have a driver? boom :(
> > >
> > > Don't do this.
> > >
> >
> > Ack. Will use THIS_MODULE here.
>
> Again, no, that will be even more incorrect.
>
This shouldn't be relevant anymore.
> > > > + put_device(iom->dev);
> > > > +}
> > > > +EXPORT_SYMBOL_GPL(intel_iom_put);
> > > > +
> > > > +/**
> > > > + * intel_iom_port_status() - Get status bits for the Type-C port
> > > > + * @iom: IOM device instance
> > > > + * @port: Type-C port number
> > > > + * @status: pointer to receive the status bits
> > > > + *
> > > > + * Returns 0 on success, error otherwise.
> > > > + */
> > > > +int intel_iom_port_status(struct intel_iom *iom, u8 port, u32
> > > > +*status) {
> > > > + void __iomem *reg;
> > > > +
> > > > + if (!iom)
> > > > + return -ENODEV;
> > > > +
> > > > + if (!status || (port > IOM_MAX_PORTS - 1))
> > > > + return -EINVAL;
> > > > +
> > > > + reg = iom->regbar + IOM_PORT_STATUS_OFFSET + IOM_REG_LEN *
> > > port;
> > > > +
> > > > + *status = ioread32(reg);
> > > > +
> > > > + return 0;
> > > > +}
> > > > +EXPORT_SYMBOL_GPL(intel_iom_port_status);
> > >
> > > So the whole driver is here just to read, directly from memory, a
> > > single
> > > 32 bit value?
> >
> > Yes.
>
> Ok, then this whole driver could be about 90% smaller and more obvious.
> Don't add the reference counting, the static variables and all the other stuff
> just to get a 32bit number.
>
Ack
Re: [PATCH] rtlwifi: btcoex: remove redundant initialization of variables ant_num and single_ant_path
On Thu, 2020-07-23 at 17:32 +0100, Colin King wrote:
> From: Colin Ian King
>
> The variables ant_num and single_ant_path are being initialized with a
> value that is never read and are being updated later with a new value.
> The initializations are redundant and can be removed.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King
Acked-by: Ping-Ke Shih
Thank you
> ---
> drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
> b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
> index a4940a3842de..4949f99844b5 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
> @@ -1318,7 +1318,7 @@ bool exhalbtc_bind_bt_coex_withadapter(void *adapter)
> {
> struct rtl_priv *rtlpriv = adapter;
> struct btc_coexist *btcoexist = rtl_btc_coexist(rtlpriv);
> - u8 ant_num = 2, chip_type, single_ant_path = 0;
> + u8 ant_num, chip_type, single_ant_path;
>
> if (!btcoexist)
> return false;
[PATCH v5 3/6] arch/x86: Implement text_alloc() and text_free()
Implement text_alloc() and text_free() with with the vmalloc API. These can
be used to allocate pages for trampoline code without relying on the module
loader code.
Cc: linux...@kvack.org
Cc: Masami Hiramatsu
Cc: Andi Kleen
Suggested-by: Peter Zijlstra
Signed-off-by: Jarkko Sakkinen
---
arch/x86/Kconfig | 3 +++
arch/x86/kernel/Makefile | 1 +
arch/x86/kernel/text_alloc.c | 41
3 files changed, 45 insertions(+)
create mode 100644 arch/x86/kernel/text_alloc.c
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 0dea7fdd7a00..a4ee5d1300f6 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2035,6 +2035,9 @@ config KEXEC_FILE
config ARCH_HAS_KEXEC_PURGATORY
def_bool KEXEC_FILE
+config ARCH_HAS_TEXT_ALLOC
+ def_bool y
+
config KEXEC_SIG
bool "Verify kernel signature during kexec_file_load() syscall"
depends on KEXEC_FILE
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index e77261db2391..fa1415424ae3 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -68,6 +68,7 @@ obj-y += tsc.o tsc_msr.o io_delay.o rtc.o
obj-y += pci-iommu_table.o
obj-y += resource.o
obj-y += irqflags.o
+obj-y += text_alloc.o
obj-y += process.o
obj-y += fpu/
diff --git a/arch/x86/kernel/text_alloc.c b/arch/x86/kernel/text_alloc.c
new file mode 100644
index ..f31c2d82c258
--- /dev/null
+++ b/arch/x86/kernel/text_alloc.c
@@ -0,0 +1,41 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Kernel module help for x86.
+ * Copyright (C) 2001 Rusty Russell.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+void *text_alloc(unsigned long size)
+{
+ void *p;
+
+ if (PAGE_ALIGN(size) > MODULES_LEN)
+ return NULL;
+
+ p = __vmalloc_node_range(size, MODULE_ALIGN, MODULES_VADDR, MODULES_END,
+GFP_KERNEL, PAGE_KERNEL, 0, NUMA_NO_NODE,
+__builtin_return_address(0));
+
+ if (p && (kasan_module_alloc(p, size) < 0)) {
+ vfree(p);
+ return NULL;
+ }
+
+ return p;
+}
+
+void text_free(void *region)
+{
+ /*
+* This memory may be RO, and freeing RO memory in an interrupt is not
+* supported by vmalloc.
+*/
+ lockdep_assert_irqs_enabled();
+
+ vfree(region);
+}
--
2.25.1
[PATCH v5 5/6] kprobes: Use text_alloc() and text_free()
Use text_alloc() and text_free() instead of module_alloc() and
module_memfree() when an arch provides them.
Cc: linux...@kvack.org
Cc: Andi Kleen
Cc: Masami Hiramatsu
Cc: Peter Zijlstra
Signed-off-by: Jarkko Sakkinen
---
kernel/kprobes.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index 4e46d96d4e16..611fcda9f6bf 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
#define KPROBE_HASH_BITS 6
#define KPROBE_TABLE_SIZE (1 << KPROBE_HASH_BITS)
@@ -111,12 +112,20 @@ enum kprobe_slot_state {
void __weak *alloc_insn_page(void)
{
+#ifdef CONFIG_ARCH_HAS_TEXT_ALLOC
+ return text_alloc(PAGE_SIZE);
+#else
return module_alloc(PAGE_SIZE);
+#endif
}
void __weak free_insn_page(void *page)
{
+#ifdef CONFIG_ARCH_HAS_TEXT_ALLOC
+ text_free(page);
+#else
module_memfree(page);
+#endif
}
struct kprobe_insn_cache kprobe_insn_slots = {
--
2.25.1
[PATCH v5 4/6] arch/x86: kprobes: Use text_alloc() and text_free()
Use text_alloc() and text_free() to implement alloc_insn_page() and
free_insn_page().
Cc: linux...@kvack.org
Cc: Andi Kleen
Cc: Masami Hiramatsu
Cc: Peter Zijlstra
Signed-off-by: Jarkko Sakkinen Im
---
arch/x86/kernel/kprobes/core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c
index ada39ddbc922..9e57452b3a51 100644
--- a/arch/x86/kernel/kprobes/core.c
+++ b/arch/x86/kernel/kprobes/core.c
@@ -423,7 +423,7 @@ void *alloc_insn_page(void)
{
void *page;
- page = module_alloc(PAGE_SIZE);
+ page = text_alloc(PAGE_SIZE);
if (!page)
return NULL;
@@ -446,7 +446,7 @@ void *alloc_insn_page(void)
/* Recover page to RW mode before releasing it */
void free_insn_page(void *page)
{
- module_memfree(page);
+ text_free(page);
}
static int arch_copy_kprobe(struct kprobe *p)
--
2.25.1
[PATCH v5 6/6] kprobes: Remove CONFIG_MODULES dependency
Remove CONFIG_MODULES dependency by flagging out the dependent code. This
allows to use kprobes in a kernel without support for loadable modules,
which is an useful feature for test kernels and embedded kernels.
Cc: linux...@kvack.org
Cc: Andi Kleen
Cc: Masami Hiramatsu
Cc: Peter Zijlstra
Signed-off-by: Jarkko Sakkinen
---
arch/Kconfig| 2 +-
include/linux/module.h | 14 +--
kernel/kprobes.c| 48 +++--
kernel/trace/trace_kprobe.c | 16 +++--
4 files changed, 52 insertions(+), 28 deletions(-)
diff --git a/arch/Kconfig b/arch/Kconfig
index 8cc35dc556c7..e3d6b6868ccb 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -61,7 +61,7 @@ config OPROFILE_NMI_TIMER
config KPROBES
bool "Kprobes"
- depends on MODULES
+ depends on MODULES || ARCH_HAS_TEXT_ALLOC
depends on HAVE_KPROBES
select KALLSYMS
help
diff --git a/include/linux/module.h b/include/linux/module.h
index 8850b9692b8f..22c646cff6bd 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -290,6 +290,13 @@ extern typeof(name) __mod_##type##__##name##_device_table
\
struct notifier_block;
+enum module_state {
+ MODULE_STATE_LIVE, /* Normal state. */
+ MODULE_STATE_COMING,/* Full formed, running module_init. */
+ MODULE_STATE_GOING, /* Going away. */
+ MODULE_STATE_UNFORMED, /* Still setting it up. */
+};
+
#ifdef CONFIG_MODULES
extern int modules_disabled; /* for sysctl */
@@ -305,13 +312,6 @@ struct module_use {
struct module *source, *target;
};
-enum module_state {
- MODULE_STATE_LIVE, /* Normal state. */
- MODULE_STATE_COMING,/* Full formed, running module_init. */
- MODULE_STATE_GOING, /* Going away. */
- MODULE_STATE_UNFORMED, /* Still setting it up. */
-};
-
struct mod_tree_node {
struct module *mod;
struct latch_tree_node node;
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index 611fcda9f6bf..bb2e3070481a 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -1617,6 +1617,7 @@ static int check_kprobe_address_safe(struct kprobe *p,
goto out;
}
+#ifdef CONFIG_MODULES
/*
* If the module freed .init.text, we couldn't insert
* kprobes in there.
@@ -1627,6 +1628,7 @@ static int check_kprobe_address_safe(struct kprobe *p,
*probed_mod = NULL;
ret = -ENOENT;
}
+#endif
}
out:
preempt_enable();
@@ -2223,24 +2225,6 @@ int kprobe_add_area_blacklist(unsigned long start,
unsigned long end)
return 0;
}
-/* Remove all symbols in given area from kprobe blacklist */
-static void kprobe_remove_area_blacklist(unsigned long start, unsigned long
end)
-{
- struct kprobe_blacklist_entry *ent, *n;
-
- list_for_each_entry_safe(ent, n, _blacklist, list) {
- if (ent->start_addr < start || ent->start_addr >= end)
- continue;
- list_del(>list);
- kfree(ent);
- }
-}
-
-static void kprobe_remove_ksym_blacklist(unsigned long entry)
-{
- kprobe_remove_area_blacklist(entry, entry + 1);
-}
-
int __init __weak arch_populate_kprobe_blacklist(void)
{
return 0;
@@ -2283,6 +2267,25 @@ static int __init populate_kprobe_blacklist(unsigned
long *start,
return ret ? : arch_populate_kprobe_blacklist();
}
+#ifdef CONFIG_MODULES
+/* Remove all symbols in given area from kprobe blacklist */
+static void kprobe_remove_area_blacklist(unsigned long start, unsigned long
end)
+{
+ struct kprobe_blacklist_entry *ent, *n;
+
+ list_for_each_entry_safe(ent, n, _blacklist, list) {
+ if (ent->start_addr < start || ent->start_addr >= end)
+ continue;
+ list_del(>list);
+ kfree(ent);
+ }
+}
+
+static void kprobe_remove_ksym_blacklist(unsigned long entry)
+{
+ kprobe_remove_area_blacklist(entry, entry + 1);
+}
+
static void add_module_kprobe_blacklist(struct module *mod)
{
unsigned long start, end;
@@ -2328,6 +2331,15 @@ static void remove_module_kprobe_blacklist(struct module
*mod)
kprobe_remove_area_blacklist(start, end);
}
}
+#else
+static void add_module_kprobe_blacklist(struct module *mod)
+{
+}
+
+static void remove_module_kprobe_blacklist(struct module *mod)
+{
+}
+#endif /* CONFIG_MODULES */
/* Module notifier call back, checking kprobes on the module */
static int kprobes_module_callback(struct notifier_block *nb,
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index 710ec6a6aa8f..881c998d0162 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -103,8 +103,9 @@ static nokprobe_inline bool trace_kprobe_has_gone(struct
trace_kprobe *tk)
return
[PATCH v5 2/6] vmalloc: Add text_alloc() and text_free()
Introduce functions for allocating memory for dynamic trampolines, such as kprobes. An arch can promote the availability of these functions with CONFIG_ARCH_HAS_TEXT_ALLOC. Cc: linux...@kvack.org Cc: Andi Kleen Cc: Masami Hiramatsu Suggested-by: Peter Zijlstra Signed-off-by: Jarkko Sakkinen --- include/linux/vmalloc.h | 17 + 1 file changed, 17 insertions(+) diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h index 0221f852a7e1..6c151a0ac02a 100644 --- a/include/linux/vmalloc.h +++ b/include/linux/vmalloc.h @@ -249,4 +249,21 @@ pcpu_free_vm_areas(struct vm_struct **vms, int nr_vms) int register_vmap_purge_notifier(struct notifier_block *nb); int unregister_vmap_purge_notifier(struct notifier_block *nb); +/* + * These functions can be optionally implemented by an arch in order to + * provide specialized functions for allocating trampoline code. + */ + +#ifdef CONFIG_ARCH_HAS_TEXT_ALLOC +/* + * Allocate memory to be used for trampoline code. + */ +void *text_alloc(unsigned long size); + +/* + * Free memory returned from text_alloc(). + */ +void text_free(void *region); +#endif /* CONFIG_ARCH_HAS_TEXT_ALLOC */ + #endif /* _LINUX_VMALLOC_H */ -- 2.25.1
[PATCH v5 3/6] arch/x86: Implement text_alloc() and text_free()
Implement text_alloc() and text_free() with with the vmalloc API. These can
be used to allocate pages for trampoline code without relying on the module
loader code.
Cc: linux...@kvack.org
Cc: Masami Hiramatsu
Cc: Andi Kleen
Suggested-by: Peter Zijlstra
Signed-off-by: Jarkko Sakkinen
---
arch/x86/Kconfig | 3 +++
arch/x86/kernel/Makefile | 1 +
arch/x86/kernel/text_alloc.c | 41
3 files changed, 45 insertions(+)
create mode 100644 arch/x86/kernel/text_alloc.c
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 0dea7fdd7a00..a4ee5d1300f6 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2035,6 +2035,9 @@ config KEXEC_FILE
config ARCH_HAS_KEXEC_PURGATORY
def_bool KEXEC_FILE
+config ARCH_HAS_TEXT_ALLOC
+ def_bool y
+
config KEXEC_SIG
bool "Verify kernel signature during kexec_file_load() syscall"
depends on KEXEC_FILE
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index e77261db2391..fa1415424ae3 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -68,6 +68,7 @@ obj-y += tsc.o tsc_msr.o io_delay.o rtc.o
obj-y += pci-iommu_table.o
obj-y += resource.o
obj-y += irqflags.o
+obj-y += text_alloc.o
obj-y += process.o
obj-y += fpu/
diff --git a/arch/x86/kernel/text_alloc.c b/arch/x86/kernel/text_alloc.c
new file mode 100644
index ..f31c2d82c258
--- /dev/null
+++ b/arch/x86/kernel/text_alloc.c
@@ -0,0 +1,41 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Kernel module help for x86.
+ * Copyright (C) 2001 Rusty Russell.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+void *text_alloc(unsigned long size)
+{
+ void *p;
+
+ if (PAGE_ALIGN(size) > MODULES_LEN)
+ return NULL;
+
+ p = __vmalloc_node_range(size, MODULE_ALIGN, MODULES_VADDR, MODULES_END,
+GFP_KERNEL, PAGE_KERNEL, 0, NUMA_NO_NODE,
+__builtin_return_address(0));
+
+ if (p && (kasan_module_alloc(p, size) < 0)) {
+ vfree(p);
+ return NULL;
+ }
+
+ return p;
+}
+
+void text_free(void *region)
+{
+ /*
+* This memory may be RO, and freeing RO memory in an interrupt is not
+* supported by vmalloc.
+*/
+ lockdep_assert_irqs_enabled();
+
+ vfree(region);
+}
--
2.25.1
[PATCH v5 1/6] kprobes: Remove dependency to the module_mutex
Add lock_modules() and unlock_modules() wrappers for acquiring module_mutex
in order to remove the compile time dependency to it.
Cc: linux...@kvack.org
Cc: Andi Kleen
Cc: Peter Zijlstra
Suggested-by: Masami Hiramatsu
Signed-off-by: Jarkko Sakkinen
---
include/linux/module.h | 18 ++
kernel/kprobes.c| 4 ++--
kernel/trace/trace_kprobe.c | 4 ++--
3 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/include/linux/module.h b/include/linux/module.h
index 2e6670860d27..8850b9692b8f 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -705,6 +705,16 @@ static inline bool is_livepatch_module(struct module *mod)
bool is_module_sig_enforced(void);
void set_module_sig_enforced(void);
+static inline void lock_modules(void)
+{
+ mutex_lock(_mutex);
+}
+
+static inline void unlock_modules(void)
+{
+ mutex_unlock(_mutex);
+}
+
#else /* !CONFIG_MODULES... */
static inline struct module *__module_address(unsigned long addr)
@@ -852,6 +862,14 @@ void *dereference_module_function_descriptor(struct module
*mod, void *ptr)
return ptr;
}
+static inline void lock_modules(void)
+{
+}
+
+static inline void unlock_modules(void)
+{
+}
+
#endif /* CONFIG_MODULES */
#ifdef CONFIG_SYSFS
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index 2e97febeef77..4e46d96d4e16 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -564,7 +564,7 @@ static void kprobe_optimizer(struct work_struct *work)
cpus_read_lock();
mutex_lock(_mutex);
/* Lock modules while optimizing kprobes */
- mutex_lock(_mutex);
+ lock_modules();
/*
* Step 1: Unoptimize kprobes and collect cleaned (unused and disarmed)
@@ -589,7 +589,7 @@ static void kprobe_optimizer(struct work_struct *work)
/* Step 4: Free cleaned kprobes after quiesence period */
do_free_cleaned_kprobes();
- mutex_unlock(_mutex);
+ unlock_modules();
mutex_unlock(_mutex);
cpus_read_unlock();
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index aefb6065b508..710ec6a6aa8f 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -122,9 +122,9 @@ static nokprobe_inline bool
trace_kprobe_module_exist(struct trace_kprobe *tk)
if (!p)
return true;
*p = '\0';
- mutex_lock(_mutex);
+ lock_modules();
ret = !!find_module(tk->symbol);
- mutex_unlock(_mutex);
+ unlock_modules();
*p = ':';
return ret;
--
2.25.1
[PATCH v5 2/6] vmalloc: Add text_alloc() and text_free()
Introduce functions for allocating memory for dynamic trampolines, such as kprobes. An arch can promote the availability of these functions with CONFIG_ARCH_HAS_TEXT_ALLOC. Cc: linux...@kvack.org Cc: Andi Kleen Cc: Masami Hiramatsu Suggested-by: Peter Zijlstra Signed-off-by: Jarkko Sakkinen --- include/linux/vmalloc.h | 17 + 1 file changed, 17 insertions(+) diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h index 0221f852a7e1..6c151a0ac02a 100644 --- a/include/linux/vmalloc.h +++ b/include/linux/vmalloc.h @@ -249,4 +249,21 @@ pcpu_free_vm_areas(struct vm_struct **vms, int nr_vms) int register_vmap_purge_notifier(struct notifier_block *nb); int unregister_vmap_purge_notifier(struct notifier_block *nb); +/* + * These functions can be optionally implemented by an arch in order to + * provide specialized functions for allocating trampoline code. + */ + +#ifdef CONFIG_ARCH_HAS_TEXT_ALLOC +/* + * Allocate memory to be used for trampoline code. + */ +void *text_alloc(unsigned long size); + +/* + * Free memory returned from text_alloc(). + */ +void text_free(void *region); +#endif /* CONFIG_ARCH_HAS_TEXT_ALLOC */ + #endif /* _LINUX_VMALLOC_H */ -- 2.25.1
[PATCH v5 0/6] arch/x86: kprobes: Remove MODULES dependency
Remove MODULES dependency by migrating from module_alloc() to the new text_alloc() API. Essentially these changes provide preliminaries for allowing to compile a static kernel with a proper tracing support. The same API can be used later on in other sites that allocate space for trampolines, and trivially scaled to other arch's. An arch can inform with CONFIG_ARCH_HAS_TEXT_ALLOC that it's providing implementation for text_alloc(). Cc: linux...@kvack.org Cc: Andi Kleen Cc: Masami Hiramatsu Cc: Peter Zijlstra v4: * Squash lock_modules() patches into one. * Remove fallback versions of text_alloc() and text_free(). Instead, use ARCH_HAS_TEXT_ALLOC at site when required. * Use lockdep_assert_irqs_enabled() in text_free() instead of WARN_ON(in_interrupt()). v3: * Make text_alloc() API disjoint. * Remove all the possible extra clutter not absolutely required and split into more logical pieces. Jarkko Sakkinen (6): kprobes: Remove dependency to the module_mutex vmalloc: Add text_alloc() and text_free() arch/x86: Implement text_alloc() and text_free() arch/x86: kprobes: Use text_alloc() and text_free() kprobes: Use text_alloc() and text_free() kprobes: Remove CONFIG_MODULES dependency arch/Kconfig | 2 +- arch/x86/Kconfig | 3 ++ arch/x86/kernel/Makefile | 1 + arch/x86/kernel/kprobes/core.c | 4 +-- arch/x86/kernel/text_alloc.c | 41 +++ include/linux/module.h | 32 ++ include/linux/vmalloc.h| 17 ++ kernel/kprobes.c | 61 +++--- kernel/trace/trace_kprobe.c| 20 --- 9 files changed, 147 insertions(+), 34 deletions(-) create mode 100644 arch/x86/kernel/text_alloc.c -- 2.25.1
[PATCH v5 1/6] kprobes: Remove dependency to the module_mutex
Add lock_modules() and unlock_modules() wrappers for acquiring module_mutex
in order to remove the compile time dependency to it.
Cc: linux...@kvack.org
Cc: Andi Kleen
Cc: Peter Zijlstra
Suggested-by: Masami Hiramatsu
Signed-off-by: Jarkko Sakkinen
---
include/linux/module.h | 18 ++
kernel/kprobes.c| 4 ++--
kernel/trace/trace_kprobe.c | 4 ++--
3 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/include/linux/module.h b/include/linux/module.h
index 2e6670860d27..8850b9692b8f 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -705,6 +705,16 @@ static inline bool is_livepatch_module(struct module *mod)
bool is_module_sig_enforced(void);
void set_module_sig_enforced(void);
+static inline void lock_modules(void)
+{
+ mutex_lock(_mutex);
+}
+
+static inline void unlock_modules(void)
+{
+ mutex_unlock(_mutex);
+}
+
#else /* !CONFIG_MODULES... */
static inline struct module *__module_address(unsigned long addr)
@@ -852,6 +862,14 @@ void *dereference_module_function_descriptor(struct module
*mod, void *ptr)
return ptr;
}
+static inline void lock_modules(void)
+{
+}
+
+static inline void unlock_modules(void)
+{
+}
+
#endif /* CONFIG_MODULES */
#ifdef CONFIG_SYSFS
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index 2e97febeef77..4e46d96d4e16 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -564,7 +564,7 @@ static void kprobe_optimizer(struct work_struct *work)
cpus_read_lock();
mutex_lock(_mutex);
/* Lock modules while optimizing kprobes */
- mutex_lock(_mutex);
+ lock_modules();
/*
* Step 1: Unoptimize kprobes and collect cleaned (unused and disarmed)
@@ -589,7 +589,7 @@ static void kprobe_optimizer(struct work_struct *work)
/* Step 4: Free cleaned kprobes after quiesence period */
do_free_cleaned_kprobes();
- mutex_unlock(_mutex);
+ unlock_modules();
mutex_unlock(_mutex);
cpus_read_unlock();
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index aefb6065b508..710ec6a6aa8f 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -122,9 +122,9 @@ static nokprobe_inline bool
trace_kprobe_module_exist(struct trace_kprobe *tk)
if (!p)
return true;
*p = '\0';
- mutex_lock(_mutex);
+ lock_modules();
ret = !!find_module(tk->symbol);
- mutex_unlock(_mutex);
+ unlock_modules();
*p = ':';
return ret;
--
2.25.1
[PATCH v5 0/6] arch/x86: kprobes: Remove MODULES dependency
Remove MODULES dependency by migrating from module_alloc() to the new text_alloc() API. Essentially these changes provide preliminaries for allowing to compile a static kernel with a proper tracing support. The same API can be used later on in other sites that allocate space for trampolines, and trivially scaled to other arch's. An arch can inform with CONFIG_ARCH_HAS_TEXT_ALLOC that it's providing implementation for text_alloc(). Cc: linux...@kvack.org Cc: Andi Kleen Cc: Masami Hiramatsu Cc: Peter Zijlstra v4: * Squash lock_modules() patches into one. * Remove fallback versions of text_alloc() and text_free(). Instead, use ARCH_HAS_TEXT_ALLOC at site when required. * Use lockdep_assert_irqs_enabled() in text_free() instead of WARN_ON(in_interrupt()). v3: * Make text_alloc() API disjoint. * Remove all the possible extra clutter not absolutely required and split into more logical pieces. Jarkko Sakkinen (6): kprobes: Remove dependency to the module_mutex vmalloc: Add text_alloc() and text_free() arch/x86: Implement text_alloc() and text_free() arch/x86: kprobes: Use text_alloc() and text_free() kprobes: Use text_alloc() and text_free() kprobes: Remove CONFIG_MODULES dependency arch/Kconfig | 2 +- arch/x86/Kconfig | 3 ++ arch/x86/kernel/Makefile | 1 + arch/x86/kernel/kprobes/core.c | 4 +-- arch/x86/kernel/text_alloc.c | 41 +++ include/linux/module.h | 32 ++ include/linux/vmalloc.h| 17 ++ kernel/kprobes.c | 61 +++--- kernel/trace/trace_kprobe.c| 20 --- 9 files changed, 147 insertions(+), 34 deletions(-) create mode 100644 arch/x86/kernel/text_alloc.c -- 2.25.1
Re: [PATCH v10 00/26] Control-flow Enforcement: Shadow Stack
On Thu, Jul 23, 2020 at 11:41:55AM -0700, Dave Hansen wrote:
> On 7/23/20 9:56 AM, Sean Christopherson wrote:
> > On Thu, Jul 23, 2020 at 09:41:37AM -0700, Dave Hansen wrote:
> >> On 7/23/20 9:25 AM, Sean Christopherson wrote:
> >>> How would people feel about taking the above two patches (02 and 03 in the
> >>> series) through the KVM tree to enable KVM virtualization of CET before
> >>> the
> >>> kernel itself gains CET support? I.e. add the MSR and feature bits, along
> >>> with the XSAVES context switching. The feature definitons could use "" to
> >>> suppress displaying them in /proc/cpuinfo to avoid falsely advertising CET
> >>> to userspace.
> >>>
> >>> AIUI, there are ABI issues that need to be sorted out, and that is likely
> >>> going to drag on for some time.
> >>>
> >>> Is this a "hell no" sort of idea, or something that would be feasible if
> >>> we
> >>> can show that there are no negative impacts to the kernel?
> >> Negative impacts like bloating every task->fpu with XSAVE state that
> >> will never get used? ;)
> > Gah, should have qualified that with "meaningful or measurable negative
> > impacts". E.g. the extra 40 bytes for CET XSAVE state seems like it would
> > be acceptable overhead, but noticeably increasing the latency of XSAVES
> > and/or XRSTORS would not be acceptable.
>
> It's 40 bytes, but it's 40 bytes of just pure, unadulterated waste. It
> would have no *chance* of being used. It's also quite precisely
Well, technically the guest would be using that space :-).
> measurable on a given system:
>
> cat /proc/slabinfo | grep task_struct | awk '{print $3 * 40}'
>
> I don't expect it would do *much* to XSAVE/XRSTOR. There's probably an
> extra conditional and jump in the ucode, but that's probably in the
> noise. I assume that all the CET state has functioning init and
> modified trackers and we don't do anything to spoil their state. It
> would be good to check that in practice, though it probably isn't the
> end of the world either way. We've had some bugs in the past where we
> accidentally took things out of their init state.
>
> It will make signal entry/return slower since we use a plain XSAVE
> without the init optimization. But, that's just a single cacheline on
> average and some 0's to write. Probably not noticeable, including the
> 40 bytes of extra userspace signal stack space.
>
> I think that puts me in the "mildly annoyed" camp more than "hell no",
> but "mildly annoyed" is pretty much my resting state, so it doesn't
> really move the needle. :)
>
> Why the urgency, though?
>
> https://windows-internals.com/cet-on-windows/
>
> ?
No urgency, it'd simply be one less KVM feature for us to be carrying and
refreshing. And as a sort of general question, I was curious if folks
would be open to merging KVM support before kernel.
[git pull] drm fixes for 5.8-rc7
Quiet fixes, I may have a single regression fix follow up to this for nouveau, but it might be next week, Ben was testing it a bit more . Otherwise two amdgpu fixes, one lima and one sun4i. Dave. drm-fixes-2020-07-24: drm fixes for 5.6-rc7 amdgpu: - Fix crash when overclocking VegaM - Fix possible crash when editing dpm levels sun4i: - Fix inverted HPD result; fixes an earlier fix lima: - fix timeout during reset The following changes since commit ba47d845d715a010f7b51f6f89bae32845e6acb7: Linux 5.8-rc6 (2020-07-19 15:41:18 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-07-24 for you to fetch changes up to d8904ca9d338cdaa67e3bd06d7a7d418e426648c: Merge tag 'amd-drm-fixes-5.8-2020-07-22' of git://people.freedesktop.org/~agd5f/linux into drm-fixes (2020-07-23 14:06:16 +1000) drm fixes for 5.6-rc7 amdgpu: - Fix crash when overclocking VegaM - Fix possible crash when editing dpm levels sun4i: - Fix inverted HPD result; fixes an earlier fix lima: - fix timeout during reset Chen-Yu Tsai (1): drm: sun4i: hdmi: Fix inverted HPD result Dave Airlie (2): Merge tag 'drm-misc-fixes-2020-07-22' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Merge tag 'amd-drm-fixes-5.8-2020-07-22' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Paweł Gronowski (1): drm/amdgpu: Fix NULL dereference in dpm sysfs handlers Qiang Yu (1): drm/lima: fix wait pp reset timeout Qiu Wenbo (1): drm/amd/powerplay: fix a crash when overclocking Vega M drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 9 +++-- drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c | 10 ++ drivers/gpu/drm/lima/lima_pp.c | 2 ++ drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 2 +- 4 files changed, 12 insertions(+), 11 deletions(-)
[PATCH] rtc: ds1307: provide an indication that the watchdog has fired
There's not much feedback when the ds1388 watchdog fires. Generally it yanks on the reset line and the board reboots. To provide some feedback indicate that the watchdog has fired in the past. This should help distinguish a watchdog triggered reset from a power interruption. Signed-off-by: Chris Packham --- drivers/rtc/rtc-ds1307.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c index 49702942bb08..431b1a50c483 100644 --- a/drivers/rtc/rtc-ds1307.c +++ b/drivers/rtc/rtc-ds1307.c @@ -868,6 +868,14 @@ static int ds1388_wdt_start(struct watchdog_device *wdt_dev) struct ds1307 *ds1307 = watchdog_get_drvdata(wdt_dev); u8 regs[2]; int ret; + int val; + + ret = regmap_read(ds1307->regmap, DS1388_REG_FLAG, ); + if (ret) + return ret; + + if (val & DS1388_BIT_WF) + dev_notice(ds1307->dev, "detected watchdog alarm flag\n"); ret = regmap_update_bits(ds1307->regmap, DS1388_REG_FLAG, DS1388_BIT_WF, 0); -- 2.27.0
Re: [PATCH v10 00/26] Control-flow Enforcement: Shadow Stack
On Thu, Jul 23, 2020 at 08:40:33PM -0700, Yu-cheng Yu wrote:
> On Thu, 2020-07-23 at 11:41 -0700, Dave Hansen wrote:
> > On 7/23/20 9:56 AM, Sean Christopherson wrote:
> > > On Thu, Jul 23, 2020 at 09:41:37AM -0700, Dave Hansen wrote:
> > > > On 7/23/20 9:25 AM, Sean Christopherson wrote:
> > > > > How would people feel about taking the above two patches (02 and 03
> > > > > in the
> > > > > series) through the KVM tree to enable KVM virtualization of CET
> > > > > before the
> > > > > kernel itself gains CET support? I.e. add the MSR and feature bits,
> > > > > along
> > > > > with the XSAVES context switching. The feature definitons could use
> > > > > "" to
> > > > > suppress displaying them in /proc/cpuinfo to avoid falsely
> > > > > advertising CET
> > > > > to userspace.
> > > > >
> > > > > AIUI, there are ABI issues that need to be sorted out, and that is
> > > > > likely
> > > > > going to drag on for some time.
> > > > >
> > > > > Is this a "hell no" sort of idea, or something that would be feasible
> > > > > if we
> > > > > can show that there are no negative impacts to the kernel?
> > > > Negative impacts like bloating every task->fpu with XSAVE state that
> > > > will never get used? ;)
> > > Gah, should have qualified that with "meaningful or measurable negative
> > > impacts". E.g. the extra 40 bytes for CET XSAVE state seems like it would
> > > be acceptable overhead, but noticeably increasing the latency of XSAVES
> > > and/or XRSTORS would not be acceptable.
> >
> > It's 40 bytes, but it's 40 bytes of just pure, unadulterated waste. It
> > would have no *chance* of being used. It's also quite precisely
> > measurable on a given system:
> >
> > cat /proc/slabinfo | grep task_struct | awk '{print $3 * 40}'
>
> If there is value in getting these two patches merged first, we can move
> XFEATURE_MASK_CET_USER to XFEATURE_MASK_SUPERVISOR_UNSUPPORTED for now, until
> CET is eventually merged. That way, there is no space wasted.
Merging them as disabled wouldn't help, KVM needs the features enabled so
that context switching the guest state works as expected.
Re: [PATCH] drivers: isdn: capi: Fix data-race bug
On Thu, Jul 23, 2020 at 03:11:58PM -0700, David Miller wrote: > From: madhuparnabhowmi...@gmail.com > Date: Wed, 22 Jul 2020 22:53:29 +0530 > > > From: Madhuparna Bhowmik > > > > In capi_init(), after register_chrdev() the file operation callbacks > > can be called. However capinc_tty_init() is called later. > > Since capiminors and capinc_tty_driver are initialized in > > capinc_tty_init(), their initialization can race with their usage > > in various callbacks like in capi_release(). > > > > Therefore, call capinc_tty_init() before register_chrdev to avoid > > such race conditions. > > > > Found by Linux Driver Verification project (linuxtesting.org). > > > > Signed-off-by: Madhuparna Bhowmik > > I agree with Arnd that this just exchanges one set of problems for > another. Thanks Arnd and David, for reviewing the patch. Do you have any suggestions on how to fix this correctly? Regards, Madhuparna
drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:1225:18: sparse: sparse: incorrect type in assignment (different base types)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: f37e99aca03f63aa3f2bd13ceaf769455d12c4b0
commit: 4647e021193d638d3c87d1f1b9a5f7f7a48f36a3 net: stmmac: selftests: Add
selftest for L3/L4 Filters
date: 11 months ago
config: powerpc-randconfig-s032-20200723 (attached as .config)
compiler: powerpc-linux-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.2-93-g4c6cbe55-dirty
git checkout 4647e021193d638d3c87d1f1b9a5f7f7a48f36a3
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=powerpc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:991:27: sparse:
sparse: incorrect type in assignment (different base types) @@ expected
restricted __be32 [usertype] mask @@ got int @@
drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:991:27: sparse:
expected restricted __be32 [usertype] mask
drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:991:27: sparse:
got int
>> drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:1225:18: sparse:
>> sparse: incorrect type in assignment (different base types) @@ expected
>> restricted __be32 [addressable] [usertype] src @@ got unsigned int
>> [usertype] src_mask @@
drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:1225:18: sparse:
expected restricted __be32 [addressable] [usertype] src
drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:1225:18: sparse:
got unsigned int [usertype] src_mask
>> drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:1226:18: sparse:
>> sparse: incorrect type in assignment (different base types) @@ expected
>> restricted __be32 [addressable] [usertype] dst @@ got unsigned int
>> [usertype] dst_mask @@
drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:1226:18: sparse:
expected restricted __be32 [addressable] [usertype] dst
drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:1226:18: sparse:
got unsigned int [usertype] dst_mask
>> drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:1352:24: sparse:
>> sparse: incorrect type in assignment (different base types) @@ expected
>> restricted __be16 [addressable] [usertype] src @@ got unsigned int
>> [usertype] src_mask @@
drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:1352:24: sparse:
expected restricted __be16 [addressable] [usertype] src
drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:1352:24: sparse:
got unsigned int [usertype] src_mask
>> drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:1353:24: sparse:
>> sparse: incorrect type in assignment (different base types) @@ expected
>> restricted __be16 [addressable] [usertype] dst @@ got unsigned int
>> [usertype] dst_mask @@
drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:1353:24: sparse:
expected restricted __be16 [addressable] [usertype] dst
drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:1353:24: sparse:
got unsigned int [usertype] dst_mask
vim +1225 drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
1170
1171 #ifdef CONFIG_NET_CLS_ACT
1172 static int __stmmac_test_l3filt(struct stmmac_priv *priv, u32 dst, u32
src,
1173 u32 dst_mask, u32 src_mask)
1174 {
1175 struct flow_dissector_key_ipv4_addrs key, mask;
1176 unsigned long dummy_cookie = 0xdeadbeef;
1177 struct stmmac_packet_attrs attr = { };
1178 struct flow_dissector *dissector;
1179 struct flow_cls_offload *cls;
1180 struct flow_rule *rule;
1181 int ret;
1182
1183 if (!tc_can_offload(priv->dev))
1184 return -EOPNOTSUPP;
1185 if (!priv->dma_cap.l3l4fnum)
1186 return -EOPNOTSUPP;
1187 if (priv->rss.enable) {
1188 struct stmmac_rss rss = { .enable = false, };
1189
1190 stmmac_rss_configure(priv, priv->hw, ,
1191 priv->plat->rx_queues_to_use);
1192 }
1193
1194 dissector = kzalloc(sizeof(*dissector), GFP_KERNEL);
1195 if (!dissector) {
1196 ret = -ENOMEM;
1197 goto cleanup_rss;
1198 }
1199
1200 dissector->used_keys |= (1 << FLOW_DISSECTOR_KEY_IPV4_ADDRS);
1201 dissector->offset[FLOW
Re: kernel BUG at mm/vmalloc.c:LINE! (2)
Hi Andrew, On Thu, 23 Jul 2020 19:50:29 -0700 Andrew Morton wrote: > > On Wed, 22 Jul 2020 16:46:50 +0200 Uladzislau Rezki wrote: > > All a bit mysterious. I think it's best that we revert this from > linux-next until we hear from Ingo. I queued a patch - I expect > Stephen will see and grab it, thanks. In the end I actually did the revert (of the revert) in the merge of the tip tree (so that -next will bisect better if necessary). So you will not need the revert in your quilt series after today. -- Cheers, Stephen Rothwell pgphlGkoXLAUT.pgp Description: OpenPGP digital signature
Re: [PATCH] drm: bridge: adv7511: Add missing bridge type
On 24-07-20, 04:30, Laurent Pinchart wrote: > Hi Vinod, > > Thank you for the patch. > > On Thu, Jul 23, 2020 at 04:15:23PM +0530, Vinod Koul wrote: > > Add bridge type as DRM_MODE_CONNECTOR_HDMIA > > > > Signed-off-by: Vinod Koul > > This has already been submitted: > https://lore.kernel.org/dri-devel/20200720124228.12552-1-laurentiu.pa...@oss.nxp.com/ OKay lets drop this one then -- ~Vinod
Re: [PATCH] drm/bridge/adv7511: set the bridge type properly
On 22-07-20, 15:15, Laurent Pinchart wrote: > Hi Laurentiu, > > Thank you for the patch. > > On Mon, Jul 20, 2020 at 03:42:27PM +0300, Laurentiu Palcu wrote: > > From: Laurentiu Palcu > > > > After the drm_bridge_connector_init() helper function has been added, the > > ADV > > driver has been changed accordingly. However, the 'type' field of the bridge > > structure was left unset, which makes the helper function always return > > -EINVAL. > > > > Signed-off-by: Laurentiu Palcu > > Reviewed-by: Laurent Pinchart Thanks Laurent for pointing me to this. Reviewed-by: Vinod Koul I have tested this on DragonBoard 410c: Tested-by: Vinod Koul -- ~Vinod
drivers/irqchip/irq-bcm7038-l1.c:312:13: error: implicit declaration of function 'cpu_logical_map'
Hi Justin,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: d15be546031cf65a0fc34879beca02fd90fe7ac7
commit: 6468fc18b00685c82408f40e9569c0d3527862b8 irqchip/irq-bcm7038-l1: Add PM
support
date: 9 months ago
config: mips-randconfig-r033-20200724 (attached as .config)
compiler: mipsel-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 6468fc18b00685c82408f40e9569c0d3527862b8
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=mips
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
drivers/irqchip/irq-bcm7038-l1.c: In function 'bcm7038_l1_suspend':
>> drivers/irqchip/irq-bcm7038-l1.c:312:13: error: implicit declaration of
>> function 'cpu_logical_map' [-Werror=implicit-function-declaration]
312 | boot_cpu = cpu_logical_map(0);
| ^~~
drivers/irqchip/irq-bcm7038-l1.c: At top level:
drivers/irqchip/irq-bcm7038-l1.c:393:12: warning: no previous prototype for
'bcm7038_l1_of_init' [-Wmissing-prototypes]
393 | int __init bcm7038_l1_of_init(struct device_node *dn,
|^~
cc1: some warnings being treated as errors
vim +/cpu_logical_map +312 drivers/irqchip/irq-bcm7038-l1.c
305
306 static int bcm7038_l1_suspend(void)
307 {
308 struct bcm7038_l1_chip *intc;
309 int boot_cpu, word;
310
311 /* Wakeup interrupt should only come from the boot cpu */
> 312 boot_cpu = cpu_logical_map(0);
313
314 list_for_each_entry(intc, _l1_intcs_list, list) {
315 for (word = 0; word < intc->n_words; word++) {
316 l1_writel(~intc->wake_mask[word],
317 intc->cpus[boot_cpu]->map_base +
reg_mask_set(intc, word));
318 l1_writel(intc->wake_mask[word],
319 intc->cpus[boot_cpu]->map_base +
reg_mask_clr(intc, word));
320 }
321 }
322
323 return 0;
324 }
325
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
RE: linux-next: build failure after merge of the scsi-mkp tree
> >> ERROR: modpost: "exynos_ufs_dump_info" [drivers/scsi/ufs/ufs-exynos.ko] > undefined! > >> ERROR: modpost: "exynos_ufs_init_dbg" [drivers/scsi/ufs/ufs-exynos.ko] > undefined! > >> ERROR: modpost: "exynos_ufs_cmd_log_start" [drivers/scsi/ufs/ufs- > exynos.ko] undefined! > > *sigh* sorry about that. I did verify yesterday's exynos build fix with > COMPILE_TEST but it looks like I didn't have the new driver debugging > option enabled. > > Kiwoong/Alim: Please fix! > > -- > Martin K. PetersenOracle Linux Engineering Hi, Martin. Sorry for responding lately. I'll post a patch to fix soon. Thanks. Kiwoong Kim
Re: [PATCH v2 1/2] dt-bindings: display: panel: Add bindings for Tianma nt36672a panel
Hi Rob,
Thanks for the review!
On Thu, 23 Jul 2020 at 23:25, Rob Herring wrote:
>
> On Wed, Jul 22, 2020 at 11:28:15AM +0530, Sumit Semwal wrote:
> > The nt36672a panel from Tianma is a FHD+ panel with a resolution of
> > 1080x2246
> > and 6.18 inches size. It is found in some of the Poco F1 phones.
> >
> > Signed-off-by: Sumit Semwal
> > Change-Id: I401dfbfe23ff2d806c956002f45e349cb9688c16
>
> You know better...
Yes - Sorry :( - will correct.
>
> > ---
> > v2: remove ports node, making port@0 directly under panel@0 node.
> > ---
> > .../display/panel/tianma,nt36672a.yaml| 104 ++
> > 1 file changed, 104 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
> > b/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
> > new file mode 100644
> > index ..cb1799fbbd32
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
> > @@ -0,0 +1,104 @@
> > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/panel/tianma,nt36672a.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Tianma model NT36672A DSI Panel display driver
> > +
> > +maintainers:
> > + - Sumit Semwal
> > +
> > +description: |
> > + The nt36672a panel from Tianma is a FHD+ LCD display panel with a
> > resolution
> > + of 1080x2246. It is a video mode DSI panel.
> > +
> > +allOf:
> > + - $ref: panel-common.yaml#
> > +
> > +properties:
> > + compatible:
> > +const: tianma,nt36672a
> > +
> > + reg:
> > +description: DSI virtual channel of the peripheral
> > +
> > + reset-gpios:
> > +description: phandle of gpio for reset line - This should be 8mA, gpio
> > + can be configured using mux, pinctrl, pinctrl-names (active high)
> > +
> > + vddio-supply:
> > +description: phandle of the regulator that provides the supply voltage
> > + Power IC supply
> > +
> > + vddpos-supply:
> > +description: phandle of the positive boost supply regulator
> > +
> > + vddneg-supply:
> > +description: phandle of the negative boost supply regulator
> > +
> > + pinctrl-names:
> > +description: Pinctrl for panel active and suspend
> > +
> > + pinctrl-0:
> > +description: Active pinctrls
> > +
> > + pinctrl-1:
> > +description: Suspend pinctrls
> > +
> > + port@0:
>
> Just 'port' as there can only be 1 in this case.
>
> You can do just: 'port: true' as panel-common.yaml already has a
> definition.
Ok, let me try that and send out v3.
>
> > +type: object
> > +description: DSI input port driven by master DSI
> > +properties:
> > + reg:
> > +const: 0
> > +
> > +required:
> > + - reg
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - vddi0-supply
> > + - vddpos-supply
> > + - vddneg-supply
> > + - reset-gpios
> > + - pinctrl-names
> > + - pinctrl-0
> > + - pinctrl-1
> > + - port@0
> > +
> > +unevaluatedProperties: false
> > +
> > +examples:
> > + - |+
> > +#include
> > +dsi0 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + panel@0 {
> > +compatible = "tianma,nt36672a";
> > +reg = <0>;
> > +vddi0-supply = <_l14a_1p88>;
> > +vddpos-supply = <>;
> > +vddneg-supply = <>;
> > +
> > +reset-gpios = < 6 GPIO_ACTIVE_HIGH>;
> > +
> > +pinctrl-names = "panel_active", "panel_suspend";
> > +pinctrl-0 = <_dsi_active>;
> > +pinctrl-1 = <_dsi_suspend>;
> > +
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +port@0 {
> > + reg = <0>;
> > + tianma_nt36672a_in_0: endpoint {
> > +remote-endpoint = <_out>;
> > + };
> > +};
> > + };
> > +};
> > +
> > +...
> > --
> > 2.27.0
> >
>
Best,
Sumit.
Re: [PATCH 1/2] lockdep: improve current->(hard|soft)irqs_enabled synchronisation with actual irq state
On 23/07/2020 23:11, Nicholas Piggin wrote:
> Excerpts from Peter Zijlstra's message of July 23, 2020 9:40 pm:
>> On Thu, Jul 23, 2020 at 08:56:14PM +1000, Nicholas Piggin wrote:
>>
>>> diff --git a/arch/powerpc/include/asm/hw_irq.h
>>> b/arch/powerpc/include/asm/hw_irq.h
>>> index 3a0db7b0b46e..35060be09073 100644
>>> --- a/arch/powerpc/include/asm/hw_irq.h
>>> +++ b/arch/powerpc/include/asm/hw_irq.h
>>> @@ -200,17 +200,14 @@ static inline bool arch_irqs_disabled(void)
>>> #define powerpc_local_irq_pmu_save(flags) \
>>> do { \
>>> raw_local_irq_pmu_save(flags); \
>>> - trace_hardirqs_off(); \
>>> + if (!raw_irqs_disabled_flags(flags))\
>>> + trace_hardirqs_off(); \
>>> } while(0)
>>> #define powerpc_local_irq_pmu_restore(flags) \
>>> do {\
>>> - if (raw_irqs_disabled_flags(flags)) { \
>>> - raw_local_irq_pmu_restore(flags); \
>>> - trace_hardirqs_off(); \
>>> - } else {\
>>> + if (!raw_irqs_disabled_flags(flags))\
>>> trace_hardirqs_on();\
>>> - raw_local_irq_pmu_restore(flags); \
>>> - } \
>>> + raw_local_irq_pmu_restore(flags); \
>>> } while(0)
>>
>> You shouldn't be calling lockdep from NMI context!
>
> After this patch it doesn't.
>
> trace_hardirqs_on/off implementation appears to expect to be called in NMI
> context though, for some reason.
>
>> That is, I recently
>> added suport for that on x86:
>>
>> https://lkml.kernel.org/r/20200623083721.155449...@infradead.org
>> https://lkml.kernel.org/r/20200623083721.216740...@infradead.org
>>
>> But you need to be very careful on how you order things, as you can see
>> the above relies on preempt_count() already having been incremented with
>> NMI_MASK.
>
> Hmm. My patch seems simpler.
And your patches fix my error while Peter's do not:
IRQs not enabled as expected
WARNING: CPU: 0 PID: 1377 at /home/aik/p/kernel/kernel/softirq.c:169
__local_bh_enable_ip+0x118/0x190
>
> I don't know this stuff very well, I don't really understand what your patch
> enables for x86 but at least it shouldn't be incompatible with this one
> AFAIKS.
>
> Thanks,
> Nick
>
--
Alexey
[PATCH v8 net-next] net: hyperv: dump TX indirection table to ethtool regs
An imbalanced TX indirection table causes netvsc to have low
performance. This table is created and managed during runtime. To help
better diagnose performance issues caused by imbalanced tables, it needs
make TX indirection tables visible.
Because TX indirection table is driver specified information, so
display it via ethtool register dump.
Signed-off-by: Chi Song
---
v8: fix corrupt patch file
v7: move to ethtool register dump
v6: update names to be more precise, remove useless assignment
v5: update variable orders
v4: use a separated group to organize tx_indirection better, change
location of attributes init/exit to netvsc_drv_init/exit
drivers/net/hyperv/netvsc_drv.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index 6267f706e8ee..3288221726ea 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -1934,6 +1934,23 @@ static int netvsc_set_features(struct net_device *ndev,
return ret;
}
+static int netvsc_get_regs_len(struct net_device *netdev)
+{
+ return VRSS_SEND_TAB_SIZE * sizeof(u32);
+}
+
+static void netvsc_get_regs(struct net_device *netdev,
+ struct ethtool_regs *regs, void *p)
+{
+ struct net_device_context *ndc = netdev_priv(netdev);
+ u32 *regs_buff = p;
+
+ /* increase the version, if buffer format is changed. */
+ regs->version = 1;
+
+ memcpy(regs_buff, ndc->tx_table, VRSS_SEND_TAB_SIZE * sizeof(u32));
+}
+
static u32 netvsc_get_msglevel(struct net_device *ndev)
{
struct net_device_context *ndev_ctx = netdev_priv(ndev);
@@ -1950,6 +1967,8 @@ static void netvsc_set_msglevel(struct net_device *ndev,
u32 val)
static const struct ethtool_ops ethtool_ops = {
.get_drvinfo= netvsc_get_drvinfo,
+ .get_regs_len = netvsc_get_regs_len,
+ .get_regs = netvsc_get_regs,
.get_msglevel = netvsc_get_msglevel,
.set_msglevel = netvsc_set_msglevel,
.get_link = ethtool_op_get_link,
--
2.25.1
Re: drivers/irqchip/irq-bcm7038-l1.c:312:13: error: implicit declaration of function 'cpu_logical_map'
On 7/23/2020 9:07 PM, kernel test robot wrote: > Hi Justin, > > FYI, the error/warning still remains. > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head: d15be546031cf65a0fc34879beca02fd90fe7ac7 > commit: 6468fc18b00685c82408f40e9569c0d3527862b8 irqchip/irq-bcm7038-l1: Add > PM support > date: 9 months ago > config: mips-randconfig-r033-20200724 (attached as .config) > compiler: mipsel-linux-gcc (GCC) 9.3.0 > reproduce (this is a W=1 build): > wget > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O > ~/bin/make.cross > chmod +x ~/bin/make.cross > git checkout 6468fc18b00685c82408f40e9569c0d3527862b8 > # save the attached .config to linux build tree > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross > ARCH=mips > > If you fix the issue, kindly add following tag as appropriate > Reported-by: kernel test robot > > All errors (new ones prefixed by >>): > >drivers/irqchip/irq-bcm7038-l1.c: In function 'bcm7038_l1_suspend': >>> drivers/irqchip/irq-bcm7038-l1.c:312:13: error: implicit declaration of >>> function 'cpu_logical_map' [-Werror=implicit-function-declaration] > 312 | boot_cpu = cpu_logical_map(0); > | ^~~ >drivers/irqchip/irq-bcm7038-l1.c: At top level: >drivers/irqchip/irq-bcm7038-l1.c:393:12: warning: no previous prototype > for 'bcm7038_l1_of_init' [-Wmissing-prototypes] > 393 | int __init bcm7038_l1_of_init(struct device_node *dn, > |^~ >cc1: some warnings being treated as errors > > vim +/cpu_logical_map +312 drivers/irqchip/irq-bcm7038-l1.c Ah this needs to be guarded with CONFIG_SMP which this failing .config did not enable, I will submit a fix for that first thing in the morning. -- Florian
Re: [PATCH V2 2/3] gpio: xilinx: Add interrupt support
Hi Srinivas,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on gpio/for-next]
[also build test ERROR on linus/master v5.8-rc6 next-20200723]
[cannot apply to xlnx/master]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Srinivas-Neeli/gpio-xilinx-Update-on-xilinx-gpio-driver/20200723-220826
base: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git
for-next
config: x86_64-randconfig-a003-20200723 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-14) 9.3.0
reproduce (this is a W=1 build):
# save the attached .config to linux build tree
make W=1 ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
drivers/gpio/gpio-xilinx.c: In function 'xgpio_xlate':
>> drivers/gpio/gpio-xilinx.c:325:8: error: 'struct gpio_chip' has no member
>> named 'of_gpio_n_cells'
325 | if (gc->of_gpio_n_cells < 2) {
|^~
In file included from arch/x86/include/asm/bug.h:92,
from include/linux/bug.h:5,
from include/linux/thread_info.h:12,
from arch/x86/include/asm/preempt.h:7,
from include/linux/preempt.h:78,
from include/linux/spinlock.h:51,
from include/linux/seqlock.h:36,
from include/linux/time.h:6,
from include/linux/stat.h:19,
from include/linux/module.h:13,
from drivers/gpio/gpio-xilinx.c:11:
drivers/gpio/gpio-xilinx.c:330:39: error: 'struct gpio_chip' has no member
named 'of_gpio_n_cells'
330 | if (WARN_ON(gpiospec->args_count < gc->of_gpio_n_cells))
| ^~
include/asm-generic/bug.h:118:25: note: in definition of macro 'WARN_ON'
118 | int __ret_warn_on = !!(condition);\
| ^
drivers/gpio/gpio-xilinx.c: In function 'xgpio_probe':
drivers/gpio/gpio-xilinx.c:638:10: error: 'struct gpio_chip' has no member
named 'of_gpio_n_cells'
638 | chip->gc.of_gpio_n_cells = cells;
| ^
>> drivers/gpio/gpio-xilinx.c:639:10: error: 'struct gpio_chip' has no member
>> named 'of_xlate'
639 | chip->gc.of_xlate = xgpio_xlate;
| ^
vim +325 drivers/gpio/gpio-xilinx.c
312
313 /**
314 * xgpio_xlate - Translate gpio_spec to the GPIO number and flags
315 * @gc: Pointer to gpio_chip device structure.
316 * @gpiospec: gpio specifier as found in the device tree
317 * @flags: A flags pointer based on binding
318 *
319 * Return:
320 * irq number otherwise -EINVAL
321 */
322 static int xgpio_xlate(struct gpio_chip *gc,
323 const struct of_phandle_args *gpiospec, u32
*flags)
324 {
> 325 if (gc->of_gpio_n_cells < 2) {
326 WARN_ON(1);
327 return -EINVAL;
328 }
329
330 if (WARN_ON(gpiospec->args_count < gc->of_gpio_n_cells))
331 return -EINVAL;
332
333 if (gpiospec->args[0] >= gc->ngpio)
334 return -EINVAL;
335
336 if (flags)
337 *flags = gpiospec->args[1];
338
339 return gpiospec->args[0];
340 }
341
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH v5 07/10] bus: mhi: core: Introduce debugfs entries for MHI
Hi Bhaumik,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.8-rc6 next-20200723]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Bhaumik-Bhatt/Introduce-features-and-debugfs-sysfs-entries-for-MHI/20200724-063954
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
d15be546031cf65a0fc34879beca02fd90fe7ac7
config: csky-allyesconfig (attached as .config)
compiler: csky-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=csky
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
drivers/bus/mhi/core/debugfs.c: In function 'mhi_debugfs_events_show':
>> drivers/bus/mhi/core/debugfs.c:73:51: warning: cast from pointer to integer
>> of different size [-Wpointer-to-int-cast]
73 | seq_printf(m, " local rp: 0x%llx db: 0x%llx\n", (u64)ring->rp,
| ^
>> drivers/bus/mhi/core/debugfs.c:73:45: warning: format '%llx' expects
>> argument of type 'long long unsigned int', but argument 4 has type
>> 'dma_addr_t' {aka 'unsigned int'} [-Wformat=]
73 | seq_printf(m, " local rp: 0x%llx db: 0x%llx\n", (u64)ring->rp,
| ~~~^
| |
| long long unsigned int
| %x
74 | mhi_event->db_cfg.db_val);
|
||
|dma_addr_t {aka unsigned int}
drivers/bus/mhi/core/debugfs.c: In function 'mhi_debugfs_channels_show':
drivers/bus/mhi/core/debugfs.c:121:7: warning: cast from pointer to integer
of different size [-Wpointer-to-int-cast]
121 | (u64)ring->rp, (u64)ring->wp,
| ^
drivers/bus/mhi/core/debugfs.c:121:22: warning: cast from pointer to integer
of different size [-Wpointer-to-int-cast]
121 | (u64)ring->rp, (u64)ring->wp,
| ^
drivers/bus/mhi/core/debugfs.c:120:62: warning: format '%llx' expects
argument of type 'long long unsigned int', but argument 5 has type 'dma_addr_t'
{aka 'unsigned int'} [-Wformat=]
120 | seq_printf(m, " local rp: 0x%llx local wp: 0x%llx db: 0x%llx\n",
| ~~~^
| |
| long
long unsigned int
| %x
121 | (u64)ring->rp, (u64)ring->wp,
122 | mhi_chan->db_cfg.db_val);
| ~~~
| |
| dma_addr_t {aka unsigned int}
vim +73 drivers/bus/mhi/core/debugfs.c
36
37 static int mhi_debugfs_events_show(struct seq_file *m, void *d)
38 {
39 struct mhi_controller *mhi_cntrl = m->private;
40 struct mhi_event *mhi_event;
41 struct mhi_event_ctxt *er_ctxt;
42 int i;
43
44 if (!mhi_is_active(mhi_cntrl)) {
45 seq_puts(m, "Device not ready\n");
46 return -ENODEV;
47 }
48
49 er_ctxt = mhi_cntrl->mhi_ctxt->er_ctxt;
50 mhi_event = mhi_cntrl->mhi_event;
51 for (i = 0; i < mhi_cntrl->total_ev_rings;
52 i++, er_ctxt++,
mhi_event++) {
53 struct mhi_ring *ring = _event->ring;
54
55 if (mhi_event->offload_ev) {
56 seq_printf(m, "Index: %d is an offload event
ring\n",
57 i);
58 continue;
59 }
60
61 seq_printf(m, "Index: %d intmod count: %lu time: %lu",
62 i, (er_ctxt->intmod & EV_CTX_INTMODC_MASK) >>
63 EV_CTX_INTMODC_SHIFT,
64
[PATCH 2/2] libnvdimm/security: ensure sysfs poll thread woke up and fetch updated attr
commit 7d988097c546 ("acpi/nfit, libnvdimm/security: Add security DSM overwrite
support")
adds a sysfs_notify_dirent() to wake up userspace poll thread when the
"overwrite"
operation has completed. But the notification is issued before the internal
dimm security state and flags have been updated, so the userspace poll thread
wakes up and fetches the not-yet-updated attr and falls back to sleep, forever.
But if user from another terminal issue "ndctl wait-overwrite nmemX" again,
the command returns instantly.
Cc: Dave Jiang
Cc: Dan Williams
Fixes: 7d988097c546 ("acpi/nfit, libnvdimm/security: Add security DSM overwrite
support")
Signed-off-by: Jane Chu
---
drivers/nvdimm/security.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/nvdimm/security.c b/drivers/nvdimm/security.c
index 8f3971c..4b80150 100644
--- a/drivers/nvdimm/security.c
+++ b/drivers/nvdimm/security.c
@@ -450,14 +450,19 @@ void __nvdimm_security_overwrite_query(struct nvdimm
*nvdimm)
else
dev_dbg(>dev, "overwrite completed\n");
- if (nvdimm->sec.overwrite_state)
- sysfs_notify_dirent(nvdimm->sec.overwrite_state);
+ /*
+* Mark the overwrite work done and update dimm security flags,
+* then send a sysfs event notification to wake up userspace
+* poll threads to picked up the changed state.
+*/
nvdimm->sec.overwrite_tmo = 0;
clear_bit(NDD_SECURITY_OVERWRITE, >flags);
clear_bit(NDD_WORK_PENDING, >flags);
- put_device(>dev);
nvdimm->sec.flags = nvdimm_security_flags(nvdimm, NVDIMM_USER);
nvdimm->sec.ext_flags = nvdimm_security_flags(nvdimm, NVDIMM_MASTER);
+ if (nvdimm->sec.overwrite_state)
+ sysfs_notify_dirent(nvdimm->sec.overwrite_state);
+ put_device(>dev);
}
void nvdimm_security_overwrite_query(struct work_struct *work)
--
1.8.3.1
[PATCH 1/2] libnvdimm/security: 'security' attr never show 'overwrite' state
Since
commit d78c620a2e82 ("libnvdimm/security: Introduce a 'frozen' attribute"),
when issue
then immediately check the 'security' attribute,
unlocked
Actually the attribute stays 'unlocked' through out the entire overwrite
operation, never changed. That's because 'nvdimm->sec.flags' is a bitmap
that has both bits set indicating 'overwrite' and 'unlocked'.
But security_show() checks the mutually exclusive bits before it checks
the 'overwrite' bit at last. The order should be reversed.
The commit also has a typo: in one occasion, 'nvdimm->sec.ext_state'
assignment is replaced with 'nvdimm->sec.flags' assignment for
the NVDIMM_MASTER type.
Cc: Dan Williams
Fixes: d78c620a2e82 ("libnvdimm/security: Introduce a 'frozen' attribute")
Signed-off-by: Jane Chu
---
drivers/nvdimm/dimm_devs.c | 4 ++--
drivers/nvdimm/security.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/nvdimm/dimm_devs.c b/drivers/nvdimm/dimm_devs.c
index b7b77e8..5d72026 100644
--- a/drivers/nvdimm/dimm_devs.c
+++ b/drivers/nvdimm/dimm_devs.c
@@ -363,14 +363,14 @@ __weak ssize_t security_show(struct device *dev,
{
struct nvdimm *nvdimm = to_nvdimm(dev);
+ if (test_bit(NVDIMM_SECURITY_OVERWRITE, >sec.flags))
+ return sprintf(buf, "overwrite\n");
if (test_bit(NVDIMM_SECURITY_DISABLED, >sec.flags))
return sprintf(buf, "disabled\n");
if (test_bit(NVDIMM_SECURITY_UNLOCKED, >sec.flags))
return sprintf(buf, "unlocked\n");
if (test_bit(NVDIMM_SECURITY_LOCKED, >sec.flags))
return sprintf(buf, "locked\n");
- if (test_bit(NVDIMM_SECURITY_OVERWRITE, >sec.flags))
- return sprintf(buf, "overwrite\n");
return -ENOTTY;
}
diff --git a/drivers/nvdimm/security.c b/drivers/nvdimm/security.c
index 4cef69b..8f3971c 100644
--- a/drivers/nvdimm/security.c
+++ b/drivers/nvdimm/security.c
@@ -457,7 +457,7 @@ void __nvdimm_security_overwrite_query(struct nvdimm
*nvdimm)
clear_bit(NDD_WORK_PENDING, >flags);
put_device(>dev);
nvdimm->sec.flags = nvdimm_security_flags(nvdimm, NVDIMM_USER);
- nvdimm->sec.flags = nvdimm_security_flags(nvdimm, NVDIMM_MASTER);
+ nvdimm->sec.ext_flags = nvdimm_security_flags(nvdimm, NVDIMM_MASTER);
}
void nvdimm_security_overwrite_query(struct work_struct *work)
--
1.8.3.1
cc1: error: '-mloongson-mmi' must be used with '-mhard-float'
Hi Thomas, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: d15be546031cf65a0fc34879beca02fd90fe7ac7 commit: 26bff9eb49201aeb4e1b32d698c191831a39f5d4 MIPS: Only include the platform file needed date: 2 months ago config: mips-randconfig-c003-20200723 (attached as .config) compiler: mips64el-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 26bff9eb49201aeb4e1b32d698c191831a39f5d4 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=mips If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): >> cc1: error: '-mloongson-mmi' must be used with '-mhard-float' >> cc1: error: '-mloongson-mmi' must be used with '-mhard-float' make[2]: *** [scripts/Makefile.build:100: kernel/bounds.s] Error 1 make[2]: Target 'missing-syscalls' not remade because of errors. make[1]: *** [arch/mips/Makefile:394: archprepare] Error 2 make[1]: Target 'prepare' not remade because of errors. make: *** [Makefile:180: sub-make] Error 2 make: Target 'prepare' not remade because of errors. --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
drivers/watchdog/ar7_wdt.c:193:29: sparse: sparse: incorrect type in initializer (different address spaces)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: d15be546031cf65a0fc34879beca02fd90fe7ac7 commit: 670d0a4b10704667765f7d18f7592993d02783aa sparse: use identifiers to define address spaces date: 5 weeks ago config: mips-randconfig-s032-20200723 (attached as .config) compiler: mipsel-linux-gcc (GCC) 9.3.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # apt-get install sparse # sparse version: v0.6.2-93-g4c6cbe55-dirty git checkout 670d0a4b10704667765f7d18f7592993d02783aa # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=mips If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot sparse warnings: (new ones prefixed by >>) >> drivers/watchdog/ar7_wdt.c:193:29: sparse: sparse: incorrect type in >> initializer (different address spaces) @@ expected char const [noderef] >> __user *__gu_ptr @@ got char const * @@ >> drivers/watchdog/ar7_wdt.c:193:29: sparse: expected char const [noderef] >> __user *__gu_ptr drivers/watchdog/ar7_wdt.c:193:29: sparse: got char const * >> drivers/watchdog/ar7_wdt.c:216:35: sparse: sparse: incorrect type in >> argument 1 (different address spaces) @@ expected void [noderef] __user >> *to @@ got struct watchdog_info * @@ >> drivers/watchdog/ar7_wdt.c:216:35: sparse: expected void [noderef] >> __user *to drivers/watchdog/ar7_wdt.c:216:35: sparse: got struct watchdog_info * >> drivers/watchdog/ar7_wdt.c:222:21: sparse: sparse: incorrect type in >> initializer (different address spaces) @@ expected int [noderef] __user >> *__pu_addr @@ got int * @@ >> drivers/watchdog/ar7_wdt.c:222:21: sparse: expected int [noderef] __user >> *__pu_addr drivers/watchdog/ar7_wdt.c:222:21: sparse: got int * >> drivers/watchdog/ar7_wdt.c:229:21: sparse: sparse: incorrect type in >> initializer (different address spaces) @@ expected int const [noderef] >> __user *__gu_ptr @@ got int * @@ >> drivers/watchdog/ar7_wdt.c:229:21: sparse: expected int const [noderef] >> __user *__gu_ptr drivers/watchdog/ar7_wdt.c:229:21: sparse: got int * drivers/watchdog/ar7_wdt.c:241:21: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected int [noderef] __user *__pu_addr @@ got int * @@ drivers/watchdog/ar7_wdt.c:241:21: sparse: expected int [noderef] __user *__pu_addr drivers/watchdog/ar7_wdt.c:241:21: sparse: got int * drivers/watchdog/ar7_wdt.c:251:27: sparse: sparse: incorrect type in initializer (incompatible argument 2 (different address spaces)) @@ expected int ( *write )( ... ) @@ got int ( * )( ... ) @@ drivers/watchdog/ar7_wdt.c:251:27: sparse: expected int ( *write )( ... ) drivers/watchdog/ar7_wdt.c:251:27: sparse: got int ( * )( ... ) >> drivers/watchdog/ar7_wdt.c:271:17: sparse: sparse: incorrect type in >> assignment (different address spaces) @@ expected struct ar7_wdt *static >> [toplevel] ar7_wdt @@ got void [noderef] __iomem * @@ drivers/watchdog/ar7_wdt.c:271:17: sparse: expected struct ar7_wdt *static [toplevel] ar7_wdt >> drivers/watchdog/ar7_wdt.c:271:17: sparse: got void [noderef] __iomem * drivers/watchdog/ar7_wdt.c: note: in included file (through arch/mips/include/asm/mmiowb.h, include/linux/spinlock.h, include/linux/seqlock.h, ...): arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/in
[PATCH V2 0/3] Add wakeup support over UART RX
Changes in V2: - As per Matthias's comment added wakeup support for all the UARTs of SC7180. - Added sleep state in sc7180-idp.dts file. - Modify the if check in set_mctrl API in serial driver to avoid making RFR high during suspend. Hi Greg, These patches are based on qcom tree. Please ack the serial driver patch to land via qcom-tree. Thanks, Satya Priya satya priya (3): arm64: dts: sc7180: Add wakeup support over UART RX arm64: dts: qcom: sc7180: Add sleep pin ctrl for BT uart tty: serial: qcom_geni_serial: Fix the UART wakeup issue arch/arm64/boot/dts/qcom/sc7180-idp.dts | 42 -- arch/arm64/boot/dts/qcom/sc7180.dtsi| 98 - drivers/tty/serial/qcom_geni_serial.c | 2 +- 3 files changed, 121 insertions(+), 21 deletions(-) -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
[PATCH V2 3/3] tty: serial: qcom_geni_serial: Fix the UART wakeup issue
As a part of system suspend we call uart_port_suspend from the Serial driver, which calls set_mctrl passing mctrl as NULL. This makes RFR high(NOT_READY) during suspend. Due to this BT SoC is not able to send wakeup bytes to UART during suspend. Included if check for non-suspend case to keep RFR low during suspend. Signed-off-by: satya priya --- Changes in V2: - This patch fixes the UART flow control issue during suspend. Newly added in V2. drivers/tty/serial/qcom_geni_serial.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/serial/qcom_geni_serial.c b/drivers/tty/serial/qcom_geni_serial.c index 07b7b6b..7108dfc 100644 --- a/drivers/tty/serial/qcom_geni_serial.c +++ b/drivers/tty/serial/qcom_geni_serial.c @@ -242,7 +242,7 @@ static void qcom_geni_serial_set_mctrl(struct uart_port *uport, if (mctrl & TIOCM_LOOP) port->loopback = RX_TX_CTS_RTS_SORTED; - if (!(mctrl & TIOCM_RTS)) + if ((!(mctrl & TIOCM_RTS)) && (!(uport->suspended))) uart_manual_rfr = UART_MANUAL_RFR_EN | UART_RFR_NOT_READY; writel(uart_manual_rfr, uport->membase + SE_UART_MANUAL_RFR); } -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
[PATCH V2 1/3] arm64: dts: sc7180: Add wakeup support over UART RX
Add the necessary pinctrl and interrupts to make UART wakeup capable. Signed-off-by: satya priya --- Changes in V2: - As per Matthias's comment added wakeup support for all the UARTs of SC7180. arch/arm64/boot/dts/qcom/sc7180.dtsi | 98 ++-- 1 file changed, 84 insertions(+), 14 deletions(-) diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi b/arch/arm64/boot/dts/qcom/sc7180.dtsi index 16df08d..044a4d0 100644 --- a/arch/arm64/boot/dts/qcom/sc7180.dtsi +++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi @@ -787,9 +787,11 @@ reg = <0 0x0088 0 0x4000>; clock-names = "se"; clocks = < GCC_QUPV3_WRAP0_S0_CLK>; - pinctrl-names = "default"; + pinctrl-names = "default", "sleep"; pinctrl-0 = <_uart0_default>; - interrupts = ; + pinctrl-1 = <_uart0_sleep>; + interrupts-extended = < GIC_SPI 601 IRQ_TYPE_LEVEL_HIGH>, + < 37 IRQ_TYPE_EDGE_FALLING>; power-domains = < SC7180_CX>; operating-points-v2 = <_opp_table>; interconnects = <_virt MASTER_QUP_CORE_0 _virt SLAVE_QUP_CORE_0>, @@ -839,9 +841,11 @@ reg = <0 0x00884000 0 0x4000>; clock-names = "se"; clocks = < GCC_QUPV3_WRAP0_S1_CLK>; - pinctrl-names = "default"; + pinctrl-names = "default", "sleep"; pinctrl-0 = <_uart1_default>; - interrupts = ; + pinctrl-1 = <_uart1_sleep>; + interrupts-extended = < GIC_SPI 602 IRQ_TYPE_LEVEL_HIGH>, + < 3 IRQ_TYPE_EDGE_FALLING>; power-domains = < SC7180_CX>; operating-points-v2 = <_opp_table>; interconnects = <_virt MASTER_QUP_CORE_0 _virt SLAVE_QUP_CORE_0>, @@ -925,9 +929,11 @@ reg = <0 0x0088c000 0 0x4000>; clock-names = "se"; clocks = < GCC_QUPV3_WRAP0_S3_CLK>; - pinctrl-names = "default"; + pinctrl-names = "default", "sleep"; pinctrl-0 = <_uart3_default>; - interrupts = ; + pinctrl-1 = <_uart3_sleep>; + interrupts-extended = < GIC_SPI 604 IRQ_TYPE_LEVEL_HIGH>, + < 41 IRQ_TYPE_EDGE_FALLING>; power-domains = < SC7180_CX>; operating-points-v2 = <_opp_table>; interconnects = <_virt MASTER_QUP_CORE_0 _virt SLAVE_QUP_CORE_0>, @@ -1011,9 +1017,11 @@ reg = <0 0x00894000 0 0x4000>; clock-names = "se"; clocks = < GCC_QUPV3_WRAP0_S5_CLK>; - pinctrl-names = "default"; + pinctrl-names = "default", "sleep"; pinctrl-0 = <_uart5_default>; - interrupts = ; + pinctrl-1 = <_uart5_sleep>; + interrupts-extended = < GIC_SPI 606 IRQ_TYPE_LEVEL_HIGH>, + < 28 IRQ_TYPE_EDGE_FALLING>; power-domains = < SC7180_CX>; operating-points-v2 = <_opp_table>; interconnects = <_virt MASTER_QUP_CORE_0 _virt SLAVE_QUP_CORE_0>, @@ -1078,9 +1086,11 @@ reg = <0 0x00a8 0 0x4000>; clock-names = "se"; clocks = < GCC_QUPV3_WRAP1_S0_CLK>; - pinctrl-names = "default"; + pinctrl-names = "default", "sleep"; pinctrl-0 = <_uart6_default>; - interrupts = ; + pinctrl-1 = <_uart6_sleep>; + interrupts-extended = < GIC_SPI 353 IRQ_TYPE_LEVEL_HIGH>, + < 62 IRQ_TYPE_EDGE_FALLING>; power-domains = < SC7180_CX>; operating-points-v2 = <_opp_table>;
[PATCH V2 2/3] arm64: dts: qcom: sc7180: Add sleep pin ctrl for BT uart
Add sleep pin ctrl for BT uart, and also change the bias
configuration to match Bluetooth module.
Signed-off-by: satya priya
---
Changes in V2:
- This patch adds sleep state for BT UART. Newly added in V2.
arch/arm64/boot/dts/qcom/sc7180-idp.dts | 42 -
1 file changed, 36 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7180-idp.dts
b/arch/arm64/boot/dts/qcom/sc7180-idp.dts
index 26cc491..bc919f2 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-idp.dts
+++ b/arch/arm64/boot/dts/qcom/sc7180-idp.dts
@@ -469,20 +469,50 @@
_uart3_default {
pinconf-cts {
- /*
-* Configure a pull-down on 38 (CTS) to match the pull of
-* the Bluetooth module.
-*/
+ /* Configure no pull on 38 (CTS) to match Bluetooth module */
pins = "gpio38";
+ bias-disable;
+ };
+
+ pinconf-rts {
+ /* We'll drive 39 (RTS), so configure pull-down */
+ pins = "gpio39";
+ drive-strength = <2>;
bias-pull-down;
+ };
+
+ pinconf-tx {
+ /* We'll drive 40 (TX), so no pull */
+ pins = "gpio40";
+ drive-strength = <2>;
+ bias-disable;
output-high;
};
+ pinconf-rx {
+ /*
+* Configure a pull-up on 41 (RX). This is needed to avoid
+* garbage data when the TX pin of the Bluetooth module is
+* in tri-state (module powered off or not driving the
+* signal yet).
+*/
+ pins = "gpio41";
+ bias-pull-up;
+ };
+};
+
+_uart3_sleep {
+ pinconf-cts {
+ /* Configure no-pull on 38 (CTS) to match Bluetooth module */
+ pins = "gpio38";
+ bias-disable;
+ };
+
pinconf-rts {
- /* We'll drive 39 (RTS), so no pull */
+ /* We'll drive 39 (RTS), so configure pull-down */
pins = "gpio39";
drive-strength = <2>;
- bias-disable;
+ bias-pull-down;
};
pinconf-tx {
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH] arm64: dts: sc7180: Add wakeup support over UART RX
Hi Matthias,
On 2020-04-27 22:26, Matthias Kaehlcke wrote:
Hi,
On Mon, Apr 27, 2020 at 11:57:24AM +0530, satya priya wrote:
Add the necessary pinctrl and interrupts to make UART
wakeup capable.
Signed-off-by: satya priya
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index 4216b57..3a49603 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -637,9 +637,12 @@
reg = <0 0x0088c000 0 0x4000>;
clock-names = "se";
clocks = < GCC_QUPV3_WRAP0_S3_CLK>;
- pinctrl-names = "default";
+ pinctrl-names = "default", "sleep";
pinctrl-0 = <_uart3_default>;
- interrupts = ;
+ pinctrl-1 = <_uart3_default>;
Why is the 'sleep' configuration needed if it's the same as 'default'?
Sleep configuration is needed to make sure correct pinctrl setting is
done for RX.
When we register wakeup interrupt, function select is changed to 0 or
GPIO, and after that when state on is called, down the line it is
checking the current state, if it's same as previous state(default), it
won't do any thing and returns 0. Thus the pinctrl setting for RX
remains with "GPIO" function select causing transfer failures.
int pinctrl_select_state(struct pinctrl *p, struct pinctrl_state *state)
{
if (p->state == state)
return 0;
return pinctrl_commit_state(p, state);
}
EXPORT_SYMBOL_GPL(pinctrl_select_state);
However, in V2 we have added sleep state separately to make wakeup
feature work properly.
+ interrupts-extended =
+ < GIC_SPI 604 IRQ_TYPE_LEVEL_HIGH>,
+ < 41 0>;
status = "disabled";
};
This patch only adds wakeup support for uart3, which seems an arbitrary
choice at SoC level. Either it should do it for all UARTs of the
SC7180,
or in the .dtsi of devices that use UART3 and need it to be wakeup
capable.
Ok. Added wakeup support to all the UARTs of SC7180 in V2.
Thanks,
Satya Priya
[PATCH] ARM: OMAP2+: Fix an IS_ERR() vs NULL check in _get_pwrdm()
The of_clk_get() function returns error pointers, it never returns NULL.
Fixes: 4ea3711aece4 ("ARM: OMAP2+: omap-iommu.c conversion to ti-sysc")
Signed-off-by: Jing Xiangfeng
---
arch/arm/mach-omap2/omap-iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index 54aff33e55e6..bfa5e1b8dba7 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -74,7 +74,7 @@ static struct powerdomain *_get_pwrdm(struct device *dev)
return pwrdm;
clk = of_clk_get(dev->of_node->parent, 0);
- if (!clk) {
+ if (IS_ERR(clk)) {
dev_err(dev, "no fck found\n");
return NULL;
}
--
2.17.1
Re: [fsnotify] c738fbabb0: will-it-scale.per_process_ops -9.5% regression
On Fri, Jul 24, 2020 at 5:45 AM Rong Chen wrote:
>
>
>
> On 7/21/20 11:59 PM, Amir Goldstein wrote:
> > On Tue, Jul 21, 2020 at 3:15 AM kernel test robot
> > wrote:
> >> Greeting,
> >>
> >> FYI, we noticed a -9.5% regression of will-it-scale.per_process_ops due to
> >> commit:
> >>
> >>
> >> commit: c738fbabb0ff62d0f9a9572e56e65d05a1b34c6a ("fsnotify: fold
> >> fsnotify() call into fsnotify_parent()")
> > Strange, that's a pretty dumb patch moving some inlined code from one
> > function to
> > another (assuming there are no fsnotify marks in this test).
> >
> > Unless I am missing something the only thing that changes slightly is
> > an extra d_inode(file->f_path.dentry) deference.
> > I can get rid of it.
> >
> > Is it possible to ask for a re-test with fix patch (attached)?
>
> Hi Amir,
>
> We failed to apply this patch, could you tell us the base commit or the
> base branch?
>
Hi Rong,
The patch is applied on top of the reported offending commit:
c738fbabb0ff62d0f9a9572e56e65d05a1b34c6a ("fsnotify: fold fsnotify()
call into fsnotify_parent()")
I pushed it to my github:
https://github.com/amir73il/linux/commits/for_lkp
Thanks,
Amir.
Re: [RFC PATCH] mm: silence soft lockups from unlock_page
On Thu, Jul 23, 2020 at 5:47 PM Linus Torvalds
wrote:
>
> On Thu, Jul 23, 2020 at 5:07 PM Hugh Dickins wrote:
> >
> > I say that for full disclosure, so you don't wrack your brains
> > too much, when it may still turn out to be a screwup on my part.
>
> Sounds unlikely.
>
> If that patch applied even reasonably closely, I don't see how you'd
> see a list corruption that wasn't due to the patch.
>
> You'd have had to use the wrong spinlock by mistake due to munging it,
> or something crazy like that.
>
> The main list-handling change is
>
> (a) open-coding of that finish_wait()
>
> (b) slightly different heuristics for removal in the wakeup function
>
> where (a) was because my original version of finishing the wait needed
> to do that return code checking.
>
> So a normal "finish_wait()" just does
>
> list_del_init(>entry);
>
> where-as my open-coded one replaced that with
>
> if (!list_empty(>entry)) {
> list_del(>entry);
> ret = -EINTR;
> }
>
> and apart from that "set return to -EINTR because nobody woke us up",
> it also uses just a regular "list_del()" rather than a
> "list_del_init()". That causes the next/prev field to be poisoned
> rather than re-initialized. But that second change was because the
> list entry is on the stack, and we're not touching it any more and are
> about to return, so I removed the "init" part.
>
> Anyway, (a) really looks harmless. Unless the poisoning now triggers
> some racy debug test that had been hidden by the "init". Hmm.
>
> In contrast, (b) means that the likely access patterns of irqs
> removing the wait entry from the list might be very different from
> before. The old "autoremove" semantics would only remove the entry
> from the list when try_to_wake_up() actually woke things up. Now, a
> successful bit state _always_ removes it, which was kind of the point.
> But it might cause very different list handling patterns.
>
> All the actual list handling looks "obviously safe" because it's
> protected by the spinlock, though...
>
> If you do get oopses with the new patch too, try to send me a copy,
> and maybe I'll stare at exactly where it happens register contents and
> go "aah".
This new version is doing much better: many hours to go, but all
machines have got beyond the danger point where yesterday's version
was crashing - phew!
Hugh
Re: [PATCH v10 00/26] Control-flow Enforcement: Shadow Stack
On Thu, 2020-07-23 at 11:41 -0700, Dave Hansen wrote:
> On 7/23/20 9:56 AM, Sean Christopherson wrote:
> > On Thu, Jul 23, 2020 at 09:41:37AM -0700, Dave Hansen wrote:
> > > On 7/23/20 9:25 AM, Sean Christopherson wrote:
> > > > How would people feel about taking the above two patches (02 and 03 in
> > > > the
> > > > series) through the KVM tree to enable KVM virtualization of CET before
> > > > the
> > > > kernel itself gains CET support? I.e. add the MSR and feature bits,
> > > > along
> > > > with the XSAVES context switching. The feature definitons could use ""
> > > > to
> > > > suppress displaying them in /proc/cpuinfo to avoid falsely advertising
> > > > CET
> > > > to userspace.
> > > >
> > > > AIUI, there are ABI issues that need to be sorted out, and that is
> > > > likely
> > > > going to drag on for some time.
> > > >
> > > > Is this a "hell no" sort of idea, or something that would be feasible
> > > > if we
> > > > can show that there are no negative impacts to the kernel?
> > > Negative impacts like bloating every task->fpu with XSAVE state that
> > > will never get used? ;)
> > Gah, should have qualified that with "meaningful or measurable negative
> > impacts". E.g. the extra 40 bytes for CET XSAVE state seems like it would
> > be acceptable overhead, but noticeably increasing the latency of XSAVES
> > and/or XRSTORS would not be acceptable.
>
> It's 40 bytes, but it's 40 bytes of just pure, unadulterated waste. It
> would have no *chance* of being used. It's also quite precisely
> measurable on a given system:
>
> cat /proc/slabinfo | grep task_struct | awk '{print $3 * 40}'
If there is value in getting these two patches merged first, we can move
XFEATURE_MASK_CET_USER to XFEATURE_MASK_SUPERVISOR_UNSUPPORTED for now, until
CET is eventually merged. That way, there is no space wasted.
Yu-cheng
答复: 答复: 答复: [PATCH] arm64: mm: free unused memmap for sparse memory model that define VMEMMAP
-邮件原件- 发件人: Mike Rapoport [mailto:r...@linux.ibm.com] 发送时间: 2020年7月23日 21:19 收件人: Catalin Marinas 抄送: liwei (CM) ; w...@kernel.org; Xiaqing (A) ; Chenfeng (puck) ; butao ; fengbaopeng ; nsaenzjulie...@suse.de; steve.cap...@arm.com; Song Bao Hua (Barry Song) ; linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org; sujunfei ; zhaojiapeng 主题: Re: 答复: 答复: [PATCH] arm64: mm: free unused memmap for sparse memory model that define VMEMMAP On Thu, Jul 23, 2020 at 12:29:26PM +0100, Catalin Marinas wrote: > On Wed, Jul 22, 2020 at 01:40:34PM +, liwei (CM) wrote: > > Catalin Marinas wrote: > > > On Wed, Jul 22, 2020 at 08:41:17AM +, liwei (CM) wrote: > > > > Mike Rapoport wrote: > > > > > On Tue, Jul 21, 2020 at 03:32:03PM +0800, Wei Li wrote: > > > > > > For the memory hole, sparse memory model that define > > > > > > SPARSEMEM_VMEMMAP do not free the reserved memory for the > > > > > > page map, this patch do it. > > > > > > > > > > Are there numbers showing how much memory is actually freed? > > > > > > > > > > The freeing of empty memmap would become rather complex with > > > > > these changes, do the memory savings justify it? > > > > > > > > In the sparse memory model, the size of a section is 1 GB > > > > (SECTION_SIZE_BITS 30) by default. > > > > > > Can we reduce SECTION_SIZE_BITS instead? Say 26? > > > > Yes, you are right, reduce SECTION_SIZE_BITS to 26 can save almost > > the same memory as the patch. > > > > 1) However, it is not clear whether changing the section size has > > any other impact. > > Well, we should analyse this. > > > 2) Just like the flat memory model and the sparse memory model that > > does not define VMEMMAP, both of them have their own ways to free > > unused memmap. I think we've given a similar way for sparse memory > > define VMEMMAP. > > I think we did it for flatmem initially (on arm32) and added support > for sparsemem later on, so free_unused_memmap() had to cope with > sparse sections. On arm64 we introduced vmemmap support and didn't > bother with the freeing at all because of the added complexity of the > vmemmap page tables. > > I wonder whether we should just disallow flatmem and non-vmemmap > sparsemem on arm64. Is there any value in keeping them around? FLATMEM is useful for UMA systems with a single memory bank, so probably it's worth keeping it for low end machines. Non-vmemmap sparsemem is essentially disable in arch/arm64/Kconfig, so for NUMA configurations SPARSEMEM_VMEMMAP is the only choice. > > 3) This explicit free unused memmap method does reduce unnecessary > > memory waste for users who do not notice the section size > > modification. > > But if we changed SECTION_SIZE_BITS in the mainline kernel, then we > wouldn't need additional code to free the unused memmap. Moreover if we reduce SECTION_SIZE_BITS, we can drop free_unused_memmap() and since the arm64 memory map for sparse will not differ from other arches we can drop custom pfn_valid() as well. Hi, Mike & Catalin Let's think and discuss together about the impact of directly reducing the section size： 1) Currently, the memory of PC or Mobile devices are increasing. If the section size is reduced, the consumption of the section structure will also increase. 2) If the section size is too small, memory hotplug may be affected. Hotplug add or remove a memblock means that you need to online or offline many sections. In this case, software consumption may increase. Currently, the page map is wasted when the default section size is used. In some cases, the waste is serious. Please help to check whether the section size reduction has other impacts and whether it meets the long-term evolution. Thanks. > -- > Catalin -- Sincerely yours, Mike.
Re: [PATCH 1/2] lockdep: improve current->(hard|soft)irqs_enabled synchronisation with actual irq state
Hi Nicholas, I love your patch! Perhaps something to improve: [auto build test WARNING on linux/master] [also build test WARNING on powerpc/next linus/master v5.8-rc6 next-20200723] [cannot apply to tip/locking/core] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Nicholas-Piggin/lockdep-improve-current-hard-soft-irqs_enabled-synchronisation-with-actual-irq-state/20200723-185938 base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 9ebcfadb0610322ac537dd7aa5d9cbc2b2894c68 config: i386-randconfig-s001-20200723 (attached as .config) compiler: gcc-9 (Debian 9.3.0-14) 9.3.0 reproduce: # apt-get install sparse # sparse version: v0.6.2-93-g4c6cbe55-dirty # save the attached .config to linux build tree make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=i386 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot sparse warnings: (new ones prefixed by >>) kernel/locking/spinlock.c:149:17: sparse: sparse: context imbalance in '_raw_spin_lock' - wrong count at exit kernel/locking/spinlock.c: note: in included file (through include/linux/preempt.h): >> arch/x86/include/asm/preempt.h:79:9: sparse: sparse: context imbalance in >> '_raw_spin_lock_irqsave' - wrong count at exit >> arch/x86/include/asm/preempt.h:79:9: sparse: sparse: context imbalance in >> '_raw_spin_lock_irq' - wrong count at exit kernel/locking/spinlock.c:173:17: sparse: sparse: context imbalance in '_raw_spin_lock_bh' - wrong count at exit kernel/locking/spinlock.c:181:17: sparse: sparse: context imbalance in '_raw_spin_unlock' - unexpected unlock kernel/locking/spinlock.c:189:17: sparse: sparse: context imbalance in '_raw_spin_unlock_irqrestore' - unexpected unlock kernel/locking/spinlock.c:197:17: sparse: sparse: context imbalance in '_raw_spin_unlock_irq' - unexpected unlock kernel/locking/spinlock.c:205:17: sparse: sparse: context imbalance in '_raw_spin_unlock_bh' - unexpected unlock kernel/locking/spinlock.c:221:17: sparse: sparse: context imbalance in '_raw_read_lock' - wrong count at exit >> arch/x86/include/asm/preempt.h:79:9: sparse: sparse: context imbalance in >> '_raw_read_lock_irqsave' - wrong count at exit >> arch/x86/include/asm/preempt.h:79:9: sparse: sparse: context imbalance in >> '_raw_read_lock_irq' - wrong count at exit kernel/locking/spinlock.c:245:17: sparse: sparse: context imbalance in '_raw_read_lock_bh' - wrong count at exit kernel/locking/spinlock.c:253:17: sparse: sparse: context imbalance in '_raw_read_unlock' - unexpected unlock kernel/locking/spinlock.c:261:17: sparse: sparse: context imbalance in '_raw_read_unlock_irqrestore' - unexpected unlock kernel/locking/spinlock.c:269:17: sparse: sparse: context imbalance in '_raw_read_unlock_irq' - unexpected unlock kernel/locking/spinlock.c:277:17: sparse: sparse: context imbalance in '_raw_read_unlock_bh' - unexpected unlock kernel/locking/spinlock.c:293:17: sparse: sparse: context imbalance in '_raw_write_lock' - wrong count at exit >> arch/x86/include/asm/preempt.h:79:9: sparse: sparse: context imbalance in >> '_raw_write_lock_irqsave' - wrong count at exit >> arch/x86/include/asm/preempt.h:79:9: sparse: sparse: context imbalance in >> '_raw_write_lock_irq' - wrong count at exit kernel/locking/spinlock.c:317:17: sparse: sparse: context imbalance in '_raw_write_lock_bh' - wrong count at exit kernel/locking/spinlock.c:325:17: sparse: sparse: context imbalance in '_raw_write_unlock' - unexpected unlock kernel/locking/spinlock.c:333:17: sparse: sparse: context imbalance in '_raw_write_unlock_irqrestore' - unexpected unlock kernel/locking/spinlock.c:341:17: sparse: sparse: context imbalance in '_raw_write_unlock_irq' - unexpected unlock kernel/locking/spinlock.c:349:17: sparse: sparse: context imbalance in '_raw_write_unlock_bh' - unexpected unlock kernel/locking/spinlock.c:358:17: sparse: sparse: context imbalance in '_raw_spin_lock_nested' - wrong count at exit >> arch/x86/include/asm/preempt.h:79:9: sparse: sparse: context imbalance in >> '_raw_spin_lock_irqsave_nested' - wrong count at exit kernel/locking/spinlock.c:380:17: sparse: sparse: context imbalance in '_raw_spin_lock_nest_lock' - wrong count at exit -- kernel/trace/ring_buffer.c:699:32: sparse: sparse: incorrect type in return expression (different base types) @@ expected restricted __poll_t @@ got int @@ kernel/trace/ring_buffer.c:699:32: sparse: expected restricted __poll_t kernel/trace/ring_buffer.c:699:32: sparse: got int kernel/trace/ring_buffer.c: note: in included file (through include/linux/irqflags.h,
Re: [PATCH v2 0/4] Modularization of DFL private feature drivers
On Thu, Jul 23, 2020 at 08:03:52PM -0700, Randy Dunlap wrote: > On 7/23/20 7:09 PM, Xu Yilun wrote: > > This patchset makes it possible to develop independent driver modules > > for DFL private features. It also helps to leverage existing kernel > > drivers to enable some IP blocks in DFL. > > > > Patch #1: An improvement of feature id definition. The feature id will be > > used > > as the key field for dfl device/driver matching. > > Patch #2: Release the dfl mmio regions after enumeration, so that private > > feature drivers could request mmio region in their own drivers. > > Patch #3: Introduce the dfl bus, then dfl devices could be supported by > > independent dfl drivers. > > Patch #4: An example of the dfl driver for N3000 nios private feature. > > > > Hi, > What is "nios"? Is that explained or described anywhere? It is the NIOS2 soft processor mostly used in the FPGA. I see the there is an arch/nios2 folder in kernel. On Intel PAC N3000 card, the embedded NIOS2 core in FPGA does some Board initialization work (Mostly the configuration of ethernet retimer) on reboot. And the dfl-n3000-nios private feature in DFL is actually the handshake interfaces for host to communicate with the NIOS2 core, about what parameters to use, when the configuration is finished ... Thanks, Yilun > > > > > Main changes from v1: > > - Add the new Patch #1, to improve the feature id definition. > > - Change the dfl bus uevent format. > > - Change the dfl device's sysfs name format. > > - refactor dfl_dev_add() > > - Add the Patch #4 as an example of the dfl driver. > > - A lot of minor fixes for comments from Hao and Tom. > > thanks. > -- > ~Randy
Re: [PATCH 1/2] ALSA: hda/realtek: Fix headset mic on Loongson platform
On 07/20/2020 09:58 AM, Kaige Li wrote:
On 07/17/2020 02:57 PM, Takashi Iwai wrote:
On Fri, 17 Jul 2020 04:51:31 +0200,
Kaige Li wrote:
Add pin quirks to enable use of the headset mic on Loongson platform.
Signed-off-by: Kaige Li
@@ -7654,6 +7663,7 @@ static const struct snd_pci_quirk
alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x17aa, 0x3bf8, "Quanta FL1",
ALC269_FIXUP_PCM_44K),
SND_PCI_QUIRK(0x17aa, 0x9e54, "LENOVO NB",
ALC269_FIXUP_LENOVO_EAPD),
SND_PCI_QUIRK(0x19e5, 0x3204, "Huawei MACH-WX9",
ALC256_FIXUP_HUAWEI_MACH_WX9_PINS),
+SND_PCI_QUIRK(0x10ec, 0x0269, "Loongson HDA",
ALC269_FIXUP_LOONGSON_HDA),
This is basically Realtek ALC269 codec itself, so putting this here
may hit with many other machines.
Doesn't it has any proper PCI or codec SSID? The lack of them usually
means a bug of BIOS.
Ok, I will have a look. If there is any progress, I will reply to you
again.
Sorry for that, there is no proper PCI or codec SSID. We have fixed this
by writing the firmware. So this patch is useless.
Thank you for your time!
Kaige
Thank you!
Kaige
thanks,
Takashi
Re: [RFC PATCH] usb: dwc3: fix maximum_speed check for usb2.0-only core
Hi,
Thinh Nguyen wrote:
> Hi,
>
> Chunfeng Yun wrote:
>> The maximum_speed will be USB_SPEED_SUPER_PLUS, but the
>> maximum_speed check for usb2.0-only core doesn't consider it,
>> so fix it, and move the ckeck into dwc3_check_params().
>>
>> Signed-off-by: Chunfeng Yun
>> ---
>> Note:
>>
>> When I look at the code, find that this may be a problem, but no
>> platform to test it.
>> ---
>>drivers/usb/dwc3/core.c | 14 +++---
>>1 file changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>> index 25c686a7..ffd5ab3 100644
>> --- a/drivers/usb/dwc3/core.c
>> +++ b/drivers/usb/dwc3/core.c
>> @@ -930,13 +930,6 @@ static int dwc3_core_init(struct dwc3 *dwc)
>> */
>> dwc3_writel(dwc->regs, DWC3_GUID, LINUX_VERSION_CODE);
>>
>> -/* Handle USB2.0-only core configuration */
>> -if (DWC3_GHWPARAMS3_SSPHY_IFC(dwc->hwparams.hwparams3) ==
>> -DWC3_GHWPARAMS3_SSPHY_IFC_DIS) {
>> -if (dwc->maximum_speed == USB_SPEED_SUPER)
>> -dwc->maximum_speed = USB_SPEED_HIGH;
>> -}
>> -
>> ret = dwc3_phy_setup(dwc);
>> if (ret)
>> goto err0;
>> @@ -1426,6 +1419,13 @@ static void dwc3_check_params(struct dwc3 *dwc)
>>
>> break;
>> }
>> +
>> +/* Handle USB2.0-only core configuration */
>> +if (DWC3_GHWPARAMS3_SSPHY_IFC(dwc->hwparams.hwparams3) ==
>> +DWC3_GHWPARAMS3_SSPHY_IFC_DIS) {
>> +if (dwc->maximum_speed > USB_SPEED_HIGH)
>> +dwc->maximum_speed = USB_SPEED_HIGH;
>> +}
>>}
>>
>>static int dwc3_probe(struct platform_device *pdev)
> Actually, the dwc->maximum_speed captures the maximum speed device
> property value. It maybe be set based on the phy's capability if there's
> no property specifying it (i.e. maximum_speed is USB_SPEED_UNKNOWN).
>
> So, this code should be removed. The fix should be in the check of
> dwc3_check_params(). If maximum_speed = USB_SPEED_UNKNOWN and the phy's
> capability is only up to highspeed, then set the maximum_speed to
> highspeed only.
>
Are you going into update and resend this patch? If not I can create one
and add your "Reported-by"
BR,
Thinh
Re: [PATCH v2] mm/page_alloc: fix memalloc_nocma_{save/restore} APIs
2020년 7월 24일 (금) 오후 12:14, Andrew Morton 님이 작성:
>
> On Fri, 24 Jul 2020 12:04:02 +0900 Joonsoo Kim wrote:
>
> > 2020년 7월 24일 (금) 오전 11:36, Andrew Morton 님이 작성:
> > >
> > > On Fri, 24 Jul 2020 11:23:52 +0900 Joonsoo Kim wrote:
> > >
> > > > > > Second, clearing __GFP_MOVABLE in current_gfp_context() has a side
> > > > > > effect
> > > > > > to exclude the memory on the ZONE_MOVABLE for allocation target.
> > > > >
> > > > > More whoops.
> > > > >
> > > > > Could we please have a description of the end-user-visible effects of
> > > > > this change? Very much needed when proposing a -stable backport, I
> > > > > think.
> > > >
> > > > In fact, there is no noticeable end-user-visible effect since the
> > > > fallback would
> > > > cover the problematic case. It's mentioned in the commit description.
> > > > Perhap,
> > > > performance would be improved due to reduced retry and more available
> > > > memory
> > > > (we can use ZONE_MOVABLE with this patch) but it would be neglectable.
> > > >
> > > > > d7fefcc8de9147c is over a year old. Why did we only just discover
> > > > > this? This makes one wonder how serious those end-user-visible
> > > > > effects
> > > > > are?
> > > >
> > > > As mentioned above, there is no visible problem to the end-user.
> > >
> > > OK, thanks. In that case, I don't believe that a stable backport is
> > > appropriate?
> > >
> > > (Documentation/process/stable-kernel-rules.rst)
> >
> > Thanks for the pointer!
> >
> > Hmm... I'm not sure the correct way to handle this patch. I thought that
> > memalloc_nocma_{save,restore} is an API that is callable from the module.
> > If it is true, it's better to regard this patch as the stable candidate
> > since
> > out-of-tree modules could use it without the fallback and it would cause
> > a problem. But, yes, there is no visible problem to the end-user, at least,
> > within the mainline so it is possibly not a stable candidate.
> >
> > Please share your opinion about this situation.
>
> We tend not to care much about out-of-tree modules. I don't think a
> theoretical concern for out-of-tree code justifies risking the
> stability of -stable kernels.
Okay. It's appreciated if you remove the stable tag. Or, I will send it again
without the stable tag.
Thanks.
arch/powerpc/platforms/82xx/mpc8272_ads.c:163:9: sparse: sparse: incorrect type in argument 1 (different base types)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: d15be546031cf65a0fc34879beca02fd90fe7ac7 commit: 670d0a4b10704667765f7d18f7592993d02783aa sparse: use identifiers to define address spaces date: 5 weeks ago config: powerpc-randconfig-s032-20200723 (attached as .config) compiler: powerpc-linux-gcc (GCC) 9.3.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # apt-get install sparse # sparse version: v0.6.2-93-g4c6cbe55-dirty git checkout 670d0a4b10704667765f7d18f7592993d02783aa # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=powerpc If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot sparse warnings: (new ones prefixed by >>) >> arch/powerpc/platforms/82xx/mpc8272_ads.c:163:9: sparse: sparse: incorrect >> type in argument 1 (different base types) @@ expected unsigned int >> volatile [noderef] [usertype] __iomem *addr @@ got restricted __be32 >> [noderef] [usertype] __iomem * @@ >> arch/powerpc/platforms/82xx/mpc8272_ads.c:163:9: sparse: expected >> unsigned int volatile [noderef] [usertype] __iomem *addr >> arch/powerpc/platforms/82xx/mpc8272_ads.c:163:9: sparse: got restricted >> __be32 [noderef] [usertype] __iomem * >> arch/powerpc/platforms/82xx/mpc8272_ads.c:163:9: sparse: sparse: incorrect >> type in argument 1 (different base types) @@ expected unsigned int const >> volatile [noderef] [usertype] __iomem *addr @@ got restricted __be32 >> [noderef] [usertype] __iomem * @@ >> arch/powerpc/platforms/82xx/mpc8272_ads.c:163:9: sparse: expected >> unsigned int const volatile [noderef] [usertype] __iomem *addr >> arch/powerpc/platforms/82xx/mpc8272_ads.c:163:9: sparse: got restricted >> __be32 [noderef] [usertype] __iomem * arch/powerpc/platforms/82xx/mpc8272_ads.c:164:9: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int volatile [noderef] [usertype] __iomem *addr @@ got restricted __be32 [noderef] [usertype] __iomem * @@ arch/powerpc/platforms/82xx/mpc8272_ads.c:164:9: sparse: expected unsigned int volatile [noderef] [usertype] __iomem *addr arch/powerpc/platforms/82xx/mpc8272_ads.c:164:9: sparse: got restricted __be32 [noderef] [usertype] __iomem * arch/powerpc/platforms/82xx/mpc8272_ads.c:164:9: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int const volatile [noderef] [usertype] __iomem *addr @@ got restricted __be32 [noderef] [usertype] __iomem * @@ arch/powerpc/platforms/82xx/mpc8272_ads.c:164:9: sparse: expected unsigned int const volatile [noderef] [usertype] __iomem *addr arch/powerpc/platforms/82xx/mpc8272_ads.c:164:9: sparse: got restricted __be32 [noderef] [usertype] __iomem * arch/powerpc/platforms/82xx/mpc8272_ads.c:166:9: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int volatile [noderef] [usertype] __iomem *addr @@ got restricted __be32 [noderef] [usertype] __iomem * @@ arch/powerpc/platforms/82xx/mpc8272_ads.c:166:9: sparse: expected unsigned int volatile [noderef] [usertype] __iomem *addr arch/powerpc/platforms/82xx/mpc8272_ads.c:166:9: sparse: got restricted __be32 [noderef] [usertype] __iomem * arch/powerpc/platforms/82xx/mpc8272_ads.c:166:9: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int const volatile [noderef] [usertype] __iomem *addr @@ got restricted __be32 [noderef] [usertype] __iomem * @@ arch/powerpc/platforms/82xx/mpc8272_ads.c:166:9: sparse: expected unsigned int const volatile [noderef] [usertype] __iomem *addr arch/powerpc/platforms/82xx/mpc8272_ads.c:166:9: sparse: got restricted __be32 [noderef] [usertype] __iomem * arch/powerpc/platforms/82xx/mpc8272_ads.c:167:9: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int volatile [noderef] [usertype] __iomem *addr @@ got restricted __be32 [noderef] [usertype] __iomem * @@ arch/powerpc/platforms/82xx/mpc8272_ads.c:167:9: sparse: expected unsigned int volatile [noderef] [usertype] __iomem *addr arch/powerpc/platforms/82xx/mpc8272_ads.c:167:9: sparse: got restricted __be32 [noderef] [usertype] __iomem * arch/powerpc/platforms/82xx/mpc8272_ads.c:167:9: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int const volatile [noderef] [usertype] __iomem *addr @@ got restricted __be32 [noderef] [usertype] __iomem * @@ arch/powerpc/pla
Re: [PATCH 2/2] lockdep: warn on redundant or incorrect irq state changes
Hi Nicholas,
I love your patch! Yet something to improve:
[auto build test ERROR on linux/master]
[also build test ERROR on powerpc/next linus/master v5.8-rc6]
[cannot apply to tip/locking/core next-20200723]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Nicholas-Piggin/lockdep-improve-current-hard-soft-irqs_enabled-synchronisation-with-actual-irq-state/20200723-185938
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
9ebcfadb0610322ac537dd7aa5d9cbc2b2894c68
config: x86_64-randconfig-a002-20200723 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-14) 9.3.0
reproduce (this is a W=1 build):
# save the attached .config to linux build tree
make W=1 ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
kernel/locking/lockdep.c: In function 'lockdep_init':
>> kernel/locking/lockdep.c:5673:9: error: 'struct task_struct' has no member
>> named 'hardirqs_enabled'
5673 | current->hardirqs_enabled = 1;
| ^~
>> kernel/locking/lockdep.c:5674:9: error: 'struct task_struct' has no member
>> named 'softirqs_enabled'
5674 | current->softirqs_enabled = 1;
| ^~
In file included from kernel/locking/lockdep.c:60:
At top level:
kernel/locking/lockdep_internals.h:64:28: warning: 'LOCKF_USED_IN_IRQ_READ'
defined but not used [-Wunused-const-variable=]
64 | static const unsigned long LOCKF_USED_IN_IRQ_READ =
|^~
In file included from kernel/locking/lockdep.c:60:
kernel/locking/lockdep_internals.h:58:28: warning: 'LOCKF_ENABLED_IRQ_READ'
defined but not used [-Wunused-const-variable=]
58 | static const unsigned long LOCKF_ENABLED_IRQ_READ =
|^~
In file included from kernel/locking/lockdep.c:60:
kernel/locking/lockdep_internals.h:52:28: warning: 'LOCKF_USED_IN_IRQ'
defined but not used [-Wunused-const-variable=]
52 | static const unsigned long LOCKF_USED_IN_IRQ =
|^
In file included from kernel/locking/lockdep.c:60:
kernel/locking/lockdep_internals.h:46:28: warning: 'LOCKF_ENABLED_IRQ'
defined but not used [-Wunused-const-variable=]
46 | static const unsigned long LOCKF_ENABLED_IRQ =
|^
vim +5673 kernel/locking/lockdep.c
5667
5668 printk(" per task-struct memory footprint: %zu bytes\n",
5669 sizeof(((struct task_struct *)NULL)->held_locks));
5670
5671 WARN_ON(irqs_disabled());
5672
> 5673 current->hardirqs_enabled = 1;
> 5674 current->softirqs_enabled = 1;
5675 }
5676
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH V7 12/14] perf, tools, stat: Support new per thread TopDown metrics
> + if (topdown_metric_attrs[0] && str) {`
> + if (!stat_config.interval) {
> + fprintf(stat_config.output,
> + "Topdown accuracy may decreases when
> measuring long period.\n"
> + "Please print the result regularly,
> e.g. -I1000\n");
Can you disable this warning when --metrics-only is used? In this case it
doesn't matter
because the error is proportional to the percentage accuracy and should be
invisible.
You can only see a difference when looking at the expanded counts.
-andi
Re: INFO: rcu detected stall in netlink_sendmsg (4)
syzbot has bisected this issue to:
commit 5a781ccbd19e4664babcbe4b4ead7aa2b9283d22
Author: Vinicius Costa Gomes
Date: Sat Sep 29 00:59:43 2018 +
tc: Add support for configuring the taprio scheduler
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=16d46e1b10
start commit: 7cc2a8ea Merge tag 'block-5.8-2020-07-01' of git://git.ker..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=11d46e1b10
kernel config: https://syzkaller.appspot.com/x/.config?x=7be693511b29b338
dashboard link: https://syzkaller.appspot.com/bug?extid=0fb70e87d8e0ac278fe9
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1023588f10
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1647a88f10
Reported-by: syzbot+0fb70e87d8e0ac278...@syzkaller.appspotmail.com
Fixes: 5a781ccbd19e ("tc: Add support for configuring the taprio scheduler")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
[PATCH] tracing/uprobe: Remove dead code in trace_uprobe_register()
In the function trace_uprobe_register(), the statement "return 0;" out of switch case is dead code, remove it. Signed-off-by: Peng Fan --- kernel/trace/trace_uprobe.c | 1 - 1 file changed, 1 deletion(-) diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c index fdd47f9..f4286c9 100644 --- a/kernel/trace/trace_uprobe.c +++ b/kernel/trace/trace_uprobe.c @@ -1456,7 +1456,6 @@ trace_uprobe_register(struct trace_event_call *event, enum trace_reg type, default: return 0; } - return 0; } static int uprobe_dispatcher(struct uprobe_consumer *con, struct pt_regs *regs) -- 2.1.0
Re: [PATCH for 5.9 1/3] futex: introduce FUTEX_SWAP operation
On Thu, Jul 23, 2020 at 8:00 PM Waiman Long wrote: > > On 7/23/20 8:25 PM, Peter Oskolkov wrote: > > On Thu, Jul 23, 2020 at 4:28 AM Peter Zijlstra wrote: > > > > Thanks a lot for your comments, Peter! My answers below. > > > >> On Wed, Jul 22, 2020 at 04:45:36PM -0700, Peter Oskolkov wrote: > >>> This patchset is the first step to open-source this work. As explained > >>> in the linked pdf and video, SwitchTo API has three core operations: wait, > >>> resume, and swap (=switch). So this patchset adds a FUTEX_SWAP operation > >>> that, in addition to FUTEX_WAIT and FUTEX_WAKE, will provide a foundation > >>> on top of which user-space threading libraries can be built. > >> The PDF and video can go pound sand; you get to fully explain things > >> here. > > Will do. Should I expand the cover letter or the commit message? (I'll > > probably > > split the first patch into two in the latter case). > > You should put it mostly in the commit message which will be part of the > git log history. The cover letter, on the other hand, is not part of the > git log. Ack. (Networking/David Miller usually includes the cover letter in the git log, so this is context dependent, I guess). > > > > > >> What worries me is how FUTEX_SWAP would interact with the future > >> FUTEX_LOCK / FUTEX_UNLOCK. When we implement pthread_mutex with those, > >> there's very few WAIT/WAKE left. > > [+cc Waiman Long] > > > > I've looked through the latest FUTEX_LOCK patchset I could find ( > > https://lore.kernel.org/patchwork/cover/772643/ and related), and it seems > > that FUTEX_SWAP and FUTEX_LOCK/FUTEX_UNLOCK patchsets > > address the same issue (slow wakeups) but for different use cases: > > > > FUTEX_LOCK/FUTEX_UNLOCK uses spinning and lock stealing to > > improve futex wake/wait performance in high contention situations; > > FUTEX_SWAP is designed to be used for fast context switching with > > _no_ contention by design: the waker that is going to sleep, and the wakee > > are using different futexes; the userspace will have a futex per > > thread/task, > > and when needed the thread/task will either simply sleep on its futex, > > or context switch (=FUTEX_SWAP) into a different thread/task. > > I agree that it is a different use case. I just hope that you keep the > possible future extension to support FUTEX_LOCK/UNLOCK in mind so that > they won't conflict with each other. Ack. Will do. :) Thanks, Peter > > Cheers, > Longman >
drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:975:27: sparse: sparse: incorrect type in assignment (different base types)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: d15be546031cf65a0fc34879beca02fd90fe7ac7
commit: ccfc639a94f25eb8639e8ffbecad2f6b60d22eb1 net: stmmac: selftests: Add a
selftest for Flexible RX Parser
date: 12 months ago
config: powerpc-randconfig-s032-20200723 (attached as .config)
compiler: powerpc-linux-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.2-93-g4c6cbe55-dirty
git checkout ccfc639a94f25eb8639e8ffbecad2f6b60d22eb1
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=powerpc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
>> drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:975:27: sparse:
>> sparse: incorrect type in assignment (different base types) @@ expected
>> restricted __be32 [usertype] mask @@ got int @@
drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:975:27: sparse:
expected restricted __be32 [usertype] mask
drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:975:27: sparse:
got int
vim +975 drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
916
917 #ifdef CONFIG_NET_CLS_ACT
918 static int stmmac_test_rxp(struct stmmac_priv *priv)
919 {
920 unsigned char addr[ETH_ALEN] = {0xde, 0xad, 0xbe, 0xef, 0x00,
0x00};
921 struct tc_cls_u32_offload cls_u32 = { };
922 struct stmmac_packet_attrs attr = { };
923 struct tc_action **actions, *act;
924 struct tc_u32_sel *sel;
925 struct tcf_exts *exts;
926 int ret, i, nk = 1;
927
928 if (!tc_can_offload(priv->dev))
929 return -EOPNOTSUPP;
930 if (!priv->dma_cap.frpsel)
931 return -EOPNOTSUPP;
932
933 sel = kzalloc(sizeof(*sel) + nk * sizeof(struct tc_u32_key),
GFP_KERNEL);
934 if (!sel)
935 return -ENOMEM;
936
937 exts = kzalloc(sizeof(*exts), GFP_KERNEL);
938 if (!exts) {
939 ret = -ENOMEM;
940 goto cleanup_sel;
941 }
942
943 actions = kzalloc(nk * sizeof(*actions), GFP_KERNEL);
944 if (!actions) {
945 ret = -ENOMEM;
946 goto cleanup_exts;
947 }
948
949 act = kzalloc(nk * sizeof(*act), GFP_KERNEL);
950 if (!act) {
951 ret = -ENOMEM;
952 goto cleanup_actions;
953 }
954
955 cls_u32.command = TC_CLSU32_NEW_KNODE;
956 cls_u32.common.chain_index = 0;
957 cls_u32.common.protocol = htons(ETH_P_ALL);
958 cls_u32.knode.exts = exts;
959 cls_u32.knode.sel = sel;
960 cls_u32.knode.handle = 0x123;
961
962 exts->nr_actions = nk;
963 exts->actions = actions;
964 for (i = 0; i < nk; i++) {
965 struct tcf_gact *gact = to_gact([i]);
966
967 actions[i] = [i];
968 gact->tcf_action = TC_ACT_SHOT;
969 }
970
971 sel->nkeys = nk;
972 sel->offshift = 0;
973 sel->keys[0].off = 6;
974 sel->keys[0].val = htonl(0xdeadbeef);
> 975 sel->keys[0].mask = ~0x0;
976
977 ret = stmmac_tc_setup_cls_u32(priv, priv, _u32);
978 if (ret)
979 goto cleanup_act;
980
981 attr.dst = priv->dev->dev_addr;
982 attr.src = addr;
983
984 ret = __stmmac_test_loopback(priv, );
985 ret = !ret; /* Shall NOT receive packet */
986
987 cls_u32.command = TC_CLSU32_DELETE_KNODE;
988 stmmac_tc_setup_cls_u32(priv, priv, _u32);
989
990 cleanup_act:
991 kfree(act);
992 cleanup_actions:
993 kfree(actions);
994 cleanup_exts:
995 kfree(exts);
996 cleanup_sel:
997 kfree(sel);
998 return ret;
999 }
1000 #else
1001 static int stmmac_test_rxp(struct stmmac_priv *priv)
1002 {
1003 return -EOPNOTSUPP;
1004 }
1005 #endif
1006
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH v2] mm/page_alloc: fix memalloc_nocma_{save/restore} APIs
On Fri, 24 Jul 2020 12:04:02 +0900 Joonsoo Kim wrote:
> 2020년 7월 24일 (금) 오전 11:36, Andrew Morton 님이 작성:
> >
> > On Fri, 24 Jul 2020 11:23:52 +0900 Joonsoo Kim wrote:
> >
> > > > > Second, clearing __GFP_MOVABLE in current_gfp_context() has a side
> > > > > effect
> > > > > to exclude the memory on the ZONE_MOVABLE for allocation target.
> > > >
> > > > More whoops.
> > > >
> > > > Could we please have a description of the end-user-visible effects of
> > > > this change? Very much needed when proposing a -stable backport, I
> > > > think.
> > >
> > > In fact, there is no noticeable end-user-visible effect since the
> > > fallback would
> > > cover the problematic case. It's mentioned in the commit description.
> > > Perhap,
> > > performance would be improved due to reduced retry and more available
> > > memory
> > > (we can use ZONE_MOVABLE with this patch) but it would be neglectable.
> > >
> > > > d7fefcc8de9147c is over a year old. Why did we only just discover
> > > > this? This makes one wonder how serious those end-user-visible effects
> > > > are?
> > >
> > > As mentioned above, there is no visible problem to the end-user.
> >
> > OK, thanks. In that case, I don't believe that a stable backport is
> > appropriate?
> >
> > (Documentation/process/stable-kernel-rules.rst)
>
> Thanks for the pointer!
>
> Hmm... I'm not sure the correct way to handle this patch. I thought that
> memalloc_nocma_{save,restore} is an API that is callable from the module.
> If it is true, it's better to regard this patch as the stable candidate since
> out-of-tree modules could use it without the fallback and it would cause
> a problem. But, yes, there is no visible problem to the end-user, at least,
> within the mainline so it is possibly not a stable candidate.
>
> Please share your opinion about this situation.
We tend not to care much about out-of-tree modules. I don't think a
theoretical concern for out-of-tree code justifies risking the
stability of -stable kernels.
Re: kernel BUG at mm/vmalloc.c:LINE! (2)
Hi Andrew, On Thu, 23 Jul 2020 19:50:29 -0700 Andrew Morton wrote: > > All a bit mysterious. I think it's best that we revert this from > linux-next until we hear from Ingo. I queued a patch - I expect > Stephen will see and grab it, thanks. Wiil do. -- Cheers, Stephen Rothwell pgpLGs7XQbI2k.pgp Description: OpenPGP digital signature
linux-next: manual merge of the crypto tree with the jc_docs tree
Hi all,
Today's linux-next merge of the crypto tree got a conflict in:
Documentation/crypto/api-intro.rst
between commit:
5846551bb147 ("docs: crypto: convert api-intro.txt to ReST format")
from the jc_docs tree and commit:
9332a9e73918 ("crypto: Replace HTTP links with HTTPS ones")
from the crypto tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc Documentation/crypto/api-intro.rst
index bcff47d42189,40137f93e04f..
--- a/Documentation/crypto/api-intro.rst
+++ b/Documentation/crypto/api-intro.rst
@@@ -159,31 -146,31 +159,31 @@@ Credit
The following people provided invaluable feedback during the development
of the API:
- Alexey Kuznetzov
- Rusty Russell
- Herbert Valerio Riedel
- Jeff Garzik
- Michael Richardson
- Andrew Morton
- Ingo Oeser
- Christoph Hellwig
+ - Alexey Kuznetzov
+ - Rusty Russell
+ - Herbert Valerio Riedel
+ - Jeff Garzik
+ - Michael Richardson
+ - Andrew Morton
+ - Ingo Oeser
+ - Christoph Hellwig
Portions of this API were derived from the following projects:
-
+
Kerneli Cryptoapi (http://www.kerneli.org/)
-Alexander Kjeldaas
-Herbert Valerio Riedel
-Kyle McMartin
-Jean-Luc Cooke
-David Bryson
-Clemens Fruhwirth
-Tobias Ringstrom
-Harald Welte
+ - Alexander Kjeldaas
+ - Herbert Valerio Riedel
+ - Kyle McMartin
+ - Jean-Luc Cooke
+ - David Bryson
+ - Clemens Fruhwirth
+ - Tobias Ringstrom
+ - Harald Welte
and;
-
+
- Nettle (http://www.lysator.liu.se/~nisse/nettle/)
+ Nettle (https://www.lysator.liu.se/~nisse/nettle/)
-Niels Möller
+ - Niels Möller
Original developers of the crypto algorithms:
pgpmUT9lwkq3p.pgp
Description: OpenPGP digital signature
Re: [PATCH v2 1/3] mm/shuffle: don't move pages between zones and don't read garbage memmaps
On Tue, 23 Jun 2020 17:30:18 +0800 Wei Yang wrote: > On Tue, Jun 23, 2020 at 09:55:43AM +0200, David Hildenbrand wrote: > >On 23.06.20 09:39, David Hildenbrand wrote: > >>> Hmm.. I thought this is the behavior for early section, while it looks > >>> current > >>> code doesn't work like this: > >>> > >>>if (section_is_early && memmap) > >>>free_map_bootmem(memmap); > >>>else > >>> depopulate_section_memmap(pfn, nr_pages, altmap); > >>> > >>> section_is_early is always "true" for early section, while memmap is > >>> not-NULL > >>> only when sub-section map is empty. > >>> > >>> If my understanding is correct, when we remove a sub-section in early > >>> section, > >>> the code would call depopulate_section_memmap(), which in turn free > >>> related > >>> memmap. By removing the memmap, the return value from > >>> pfn_to_online_page() is > >>> not a valid one. > >> > >> I think you're right, and pfn_valid() would also return true, as it is > >> an early section. This looks broken. > >> > >>> > >>> Maybe we want to write the code like this: > >>> > >>>if (section_is_early) > >>>if (memmap) > >>>free_map_bootmem(memmap); > >>>else > >>> depopulate_section_memmap(pfn, nr_pages, altmap); > >>> > >> > >> I guess that should be the way to go > >> > >> @Dan, I think what Wei proposes here is correct, right? Or how does it > >> work in the VMEMMAP case with early sections? > >> > > > >Especially, if you would re-hot-add, section_activate() would assume > >there is a memmap, it must not be removed. > > > > You are right here. I didn't notice it. > > >@Wei, can you send a patch? > > > > Sure, let me prepare for it. Still awaiting this, and the v3 patch was identical to this v2 patch. It's tagged for -stable, so there's some urgency. Should we just go ahead with the decently-tested v2?
Re: [PATCH -next] arm64: Export __cpu_logical_map
+maillist
On 2020/7/24 11:04, Kefeng Wang wrote:
ERROR: modpost: "__cpu_logical_map" [drivers/cpufreq/tegra194-cpufreq.ko]
undefined!
ARM64 tegra194-cpufreq driver use cpu_logical_map, export
__cpu_logical_map to fix build issue.
Reported-by: Hulk Robot
Signed-off-by: Kefeng Wang
---
arch/arm64/kernel/setup.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index c793276ec7ad9..3aea05fbb9998 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -275,6 +275,7 @@ static int __init reserve_memblock_reserved_regions(void)
arch_initcall(reserve_memblock_reserved_regions);
u64 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = INVALID_HWID };
+EXPORT_SYMBOL(__cpu_logical_map);
void __init setup_arch(char **cmdline_p)
{
Re: [PATCH v2] mm/page_alloc: fix memalloc_nocma_{save/restore} APIs
2020년 7월 24일 (금) 오전 11:36, Andrew Morton 님이 작성:
>
> On Fri, 24 Jul 2020 11:23:52 +0900 Joonsoo Kim wrote:
>
> > > > Second, clearing __GFP_MOVABLE in current_gfp_context() has a side
> > > > effect
> > > > to exclude the memory on the ZONE_MOVABLE for allocation target.
> > >
> > > More whoops.
> > >
> > > Could we please have a description of the end-user-visible effects of
> > > this change? Very much needed when proposing a -stable backport, I think.
> >
> > In fact, there is no noticeable end-user-visible effect since the fallback
> > would
> > cover the problematic case. It's mentioned in the commit description.
> > Perhap,
> > performance would be improved due to reduced retry and more available memory
> > (we can use ZONE_MOVABLE with this patch) but it would be neglectable.
> >
> > > d7fefcc8de9147c is over a year old. Why did we only just discover
> > > this? This makes one wonder how serious those end-user-visible effects
> > > are?
> >
> > As mentioned above, there is no visible problem to the end-user.
>
> OK, thanks. In that case, I don't believe that a stable backport is
> appropriate?
>
> (Documentation/process/stable-kernel-rules.rst)
Thanks for the pointer!
Hmm... I'm not sure the correct way to handle this patch. I thought that
memalloc_nocma_{save,restore} is an API that is callable from the module.
If it is true, it's better to regard this patch as the stable candidate since
out-of-tree modules could use it without the fallback and it would cause
a problem. But, yes, there is no visible problem to the end-user, at least,
within the mainline so it is possibly not a stable candidate.
Please share your opinion about this situation.
Thanks.
Re: [PATCH v2 0/4] Modularization of DFL private feature drivers
On 7/23/20 7:09 PM, Xu Yilun wrote: > This patchset makes it possible to develop independent driver modules > for DFL private features. It also helps to leverage existing kernel > drivers to enable some IP blocks in DFL. > > Patch #1: An improvement of feature id definition. The feature id will be used > as the key field for dfl device/driver matching. > Patch #2: Release the dfl mmio regions after enumeration, so that private > feature drivers could request mmio region in their own drivers. > Patch #3: Introduce the dfl bus, then dfl devices could be supported by > independent dfl drivers. > Patch #4: An example of the dfl driver for N3000 nios private feature. > Hi, What is "nios"? Is that explained or described anywhere? > > Main changes from v1: > - Add the new Patch #1, to improve the feature id definition. > - Change the dfl bus uevent format. > - Change the dfl device's sysfs name format. > - refactor dfl_dev_add() > - Add the Patch #4 as an example of the dfl driver. > - A lot of minor fixes for comments from Hao and Tom. thanks. -- ~Randy
Re: [PATCH for 5.9 1/3] futex: introduce FUTEX_SWAP operation
On 7/23/20 8:25 PM, Peter Oskolkov wrote: On Thu, Jul 23, 2020 at 4:28 AM Peter Zijlstra wrote: Thanks a lot for your comments, Peter! My answers below. On Wed, Jul 22, 2020 at 04:45:36PM -0700, Peter Oskolkov wrote: This patchset is the first step to open-source this work. As explained in the linked pdf and video, SwitchTo API has three core operations: wait, resume, and swap (=switch). So this patchset adds a FUTEX_SWAP operation that, in addition to FUTEX_WAIT and FUTEX_WAKE, will provide a foundation on top of which user-space threading libraries can be built. The PDF and video can go pound sand; you get to fully explain things here. Will do. Should I expand the cover letter or the commit message? (I'll probably split the first patch into two in the latter case). You should put it mostly in the commit message which will be part of the git log history. The cover letter, on the other hand, is not part of the git log. What worries me is how FUTEX_SWAP would interact with the future FUTEX_LOCK / FUTEX_UNLOCK. When we implement pthread_mutex with those, there's very few WAIT/WAKE left. [+cc Waiman Long] I've looked through the latest FUTEX_LOCK patchset I could find ( https://lore.kernel.org/patchwork/cover/772643/ and related), and it seems that FUTEX_SWAP and FUTEX_LOCK/FUTEX_UNLOCK patchsets address the same issue (slow wakeups) but for different use cases: FUTEX_LOCK/FUTEX_UNLOCK uses spinning and lock stealing to improve futex wake/wait performance in high contention situations; FUTEX_SWAP is designed to be used for fast context switching with _no_ contention by design: the waker that is going to sleep, and the wakee are using different futexes; the userspace will have a futex per thread/task, and when needed the thread/task will either simply sleep on its futex, or context switch (=FUTEX_SWAP) into a different thread/task. I agree that it is a different use case. I just hope that you keep the possible future extension to support FUTEX_LOCK/UNLOCK in mind so that they won't conflict with each other. Cheers, Longman
Re: [EXT] Re: [PATCH v4 00/13] "Task_isolation" mode
On Thu, 2020-07-23 at 23:44 +0200, Thomas Gleixner wrote: > External Email > > --- > --- > Alex Belits writes: > > On Thu, 2020-07-23 at 17:49 +0200, Peter Zijlstra wrote: > > > 'What does noinstr mean? and why do we have it" -- don't dare > > > touch > > > the > > > entry code until you can answer that. > > > > noinstr disables instrumentation, so there would not be calls and > > dependencies on other parts of the kernel when it's not yet safe to > > call them. Relevant functions already have it, and I add an inline > > call > > to perform flags update and synchronization. Unless something else > > is > > involved, those operations are safe, so I am not adding anything > > that > > can break those. > > Sure. > > 1) That inline function can be put out of line by the compiler and > placed into the regular text section which makes it subject to > instrumentation > > 2) That inline function invokes local_irq_save() which is subject to > instrumentation _before_ the entry state for the instrumentation > mechanisms is established. > > 3) That inline function invokes sync_core() before important state > has > been established, which is especially interesting in NMI like > exceptions. > > As you clearly documented why all of the above is safe and does not > cause any problems, it's just me and Peter being silly, right? > > Try again. I don't think, accusations and mockery are really necessary here. I am trying to do the right thing here. In particular, I am trying to port the code that was developed on platforms that have not yet implemented those useful instrumentation safety features of x86 arch support. For most of the development time I had to figure out, where the synchronization can be safely inserted into kernel entry code on three platforms and tens of interrupt controller drivers, with some of those presenting unusual exceptions (forgive me the pun) from platform- wide conventions. I really appreciate the work you did cleaning up kernel entry procedures, my 5.6 version of this patch had to follow a much more complex and I would say, convoluted entry handling on x86, and now I don't have to do that, thanks to you. Unfortunately, most of my mental effort recently had to be spent on three things: 1. (small): finding a way to safely enable events and synchronize state on kernel entry, so it will not have a race condition between isolation-breaking kernel entry and an event that was disabled while the task was isolated. 2. (big): trying to derive any useful rules applicable to kernel entry in various architectures, finding that there is very little consistency across architectures, and whatever exists, can be broken by interrupt controller drivers that don't all follow the same rules as the rest of the platform. 3. (medium): introducing calls to synchronization on all kernel entry procedures, in places where it is guaranteed to not normally yet have done any calls to parts of the kernel that may be affected by "stale" state, and do it in a manner as consistent and generalized as possible. The current state of kernel entry handling on arm and arm64 architectures has significant differences from x86 and from each other. There is also a matter of interrupt controllers. As can be seen in interrupt controller-specific patch, I had to accommodate some variety of custom interrupt entry code. What can not be seen, is that I had to check that all other interrupt controller drivers and architecture- specific entry procedures, and find that they _do_ follow some understandable rules -- unfortunately architecture-specific and not documented in any manner. I have no valid reasons for complaining about it. I could not expect that authors of all kernel entry procedures would have any foreknowledge that someone at some point may have a reason to establish any kind of synchronization point for CPU cores. And this is why I had to do my research by manually drawing call trees and sequences, separately for every entry on every supported architecture, and across two or three versions of kernel, as those were changing along the way. The result of this may be not a "design" per se, but an understanding of how things are implemented, and what rules are being followed, so I could add my code in a manner consistent with what is done, and document the whole thing. Then there will be some written rules to check for, when anything of this kind will be necessary again (say, with TLB, but considering how much now is done in userspace, possibly to accommodate more exotic CPU features that may have state messed up by userspace). I am afraid, this task, kernel entry documentation, would take me some time, and I did not want to delay my task isolation patch for this reason. As I followed whatever rules I have determined to be applicable, I have produced code that introduces hooks in multiple seemingly unrelated to each other places.
[PATCH 1/3] ext4: reorganize if statement of, ext4_mb_release_context()
Reorganize the if statement of ext4_mb_release_context(), make it
easier to read.
Signed-off-by: Chunguang Xu
---
fs/ext4/mballoc.c | 27 +--
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
index c0a331e..4f21f34 100644
--- a/fs/ext4/mballoc.c
+++ b/fs/ext4/mballoc.c
@@ -4564,20 +4564,19 @@ static int ext4_mb_release_context(struct
ext4_allocation_context *ac)
pa->pa_free -= ac->ac_b_ex.fe_len;
pa->pa_len -= ac->ac_b_ex.fe_len;
spin_unlock(>pa_lock);
- }
- }
- if (pa) {
- /*
- * We want to add the pa to the right bucket.
- * Remove it from the list and while adding
- * make sure the list to which we are adding
- * doesn't grow big.
- */
- if ((pa->pa_type == MB_GROUP_PA) && likely(pa->pa_free)) {
- spin_lock(pa->pa_obj_lock);
- list_del_rcu(>pa_inode_list);
- spin_unlock(pa->pa_obj_lock);
- ext4_mb_add_n_trim(ac);
+
+ /*
+ * We want to add the pa to the right bucket.
+ * Remove it from the list and while adding
+ * make sure the list to which we are adding
+ * doesn't grow big.
+ */
+ if (likely(pa->pa_free)) {
+ spin_lock(pa->pa_obj_lock);
+ list_del_rcu(>pa_inode_list);
+ spin_unlock(pa->pa_obj_lock);
+ ext4_mb_add_n_trim(ac);
+ }
}
ext4_mb_put_pa(ac, ac->ac_sb, pa);
}
--
1.8.3.1
[PATCH 3/3] ext4: add needed paramter to, ext4_mb_discard_preallocations trace
Add the needed value to ext4_mb_discard_preallocations trace, so
we can more easily observe the requested number of trim.
Signed-off-by: Chunguang Xu
---
include/trace/events/ext4.h | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/include/trace/events/ext4.h b/include/trace/events/ext4.h
index cc41d69..61736d8 100644
--- a/include/trace/events/ext4.h
+++ b/include/trace/events/ext4.h
@@ -746,24 +746,26 @@
);
TRACE_EVENT(ext4_discard_preallocations,
- TP_PROTO(struct inode *inode),
+ TP_PROTO(struct inode *inode, unsigned int needed),
- TP_ARGS(inode),
+ TP_ARGS(inode, needed),
TP_STRUCT__entry(
- __field( dev_t, dev )
- __field( ino_t, ino )
+ __field( dev_t, dev )
+ __field( ino_t, ino )
+ __field( unsigned int, needed )
),
TP_fast_assign(
__entry->dev = inode->i_sb->s_dev;
__entry->ino = inode->i_ino;
+ __entry->needed = needed;
),
- TP_printk("dev %d,%d ino %lu",
+ TP_printk("dev %d,%d ino %lu needed %u",
MAJOR(__entry->dev), MINOR(__entry->dev),
- (unsigned long) __entry->ino)
+ (unsigned long) __entry->ino, __entry->needed)
);
TRACE_EVENT(ext4_mb_discard_preallocations,
--
1.8.3.1
[PATCH 2/3] ext4: limit the length of per-inode prealloc list
In the scenario of writing sparse files, the Per-inode prealloc list may
be very long, resulting in high overhead for ext4_mb_use_preallocated().
To circumvent this problem, we limit the maximum length of per-inode
prealloc list to 512 and allow users to modify it.
Signed-off-by: Chunguang Xu
---
fs/ext4/ext4.h | 3 ++-
fs/ext4/extents.c | 10 -
fs/ext4/file.c | 2 +-
fs/ext4/indirect.c | 2 +-
fs/ext4/inode.c | 6 +++---
fs/ext4/ioctl.c | 2 +-
fs/ext4/mballoc.c | 57 +++
fs/ext4/mballoc.h | 4
fs/ext4/move_extent.c | 4 ++--
fs/ext4/super.c | 2 +-
fs/ext4/sysfs.c | 2 ++
11 files changed, 75 insertions(+), 19 deletions(-)
diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
index 42f5060..68e0ebe 100644
--- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
@@ -1501,6 +1501,7 @@ struct ext4_sb_info {
unsigned int s_mb_stats;
unsigned int s_mb_order2_reqs;
unsigned int s_mb_group_prealloc;
+ unsigned int s_mb_max_inode_prealloc;
unsigned int s_max_dir_size_kb;
/* where last allocation was done - for stream allocation */
unsigned long s_mb_last_group;
@@ -2651,7 +2652,7 @@ extern int ext4_init_inode_table(struct super_block *sb,
extern ext4_fsblk_t ext4_mb_new_blocks(handle_t *,
struct ext4_allocation_request *, int *);
extern int ext4_mb_reserve_blocks(struct super_block *, int);
-extern void ext4_discard_preallocations(struct inode *);
+extern void ext4_discard_preallocations(struct inode *, unsigned int);
extern int __init ext4_init_mballoc(void);
extern void ext4_exit_mballoc(void);
extern void ext4_free_blocks(handle_t *handle, struct inode *inode,
diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index 221f240..a40f928 100644
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -100,7 +100,7 @@ static int ext4_ext_trunc_restart_fn(struct inode *inode,
int *dropped)
* i_mutex. So we can safely drop the i_data_sem here.
*/
BUG_ON(EXT4_JOURNAL(inode) == NULL);
- ext4_discard_preallocations(inode);
+ ext4_discard_preallocations(inode, 0);
up_write(_I(inode)->i_data_sem);
*dropped = 1;
return 0;
@@ -4272,7 +4272,7 @@ int ext4_ext_map_blocks(handle_t *handle, struct inode
*inode,
* not a good idea to call discard here directly,
* but otherwise we'd need to call it every free().
*/
- ext4_discard_preallocations(inode);
+ ext4_discard_preallocations(inode, 0);
if (flags & EXT4_GET_BLOCKS_DELALLOC_RESERVE)
fb_flags = EXT4_FREE_BLOCKS_NO_QUOT_UPDATE;
ext4_free_blocks(handle, inode, NULL, newblock,
@@ -5299,7 +5299,7 @@ static int ext4_collapse_range(struct inode *inode,
loff_t offset, loff_t len)
}
down_write(_I(inode)->i_data_sem);
- ext4_discard_preallocations(inode);
+ ext4_discard_preallocations(inode, 0);
ret = ext4_es_remove_extent(inode, punch_start,
EXT_MAX_BLOCKS - punch_start);
@@ -5313,7 +5313,7 @@ static int ext4_collapse_range(struct inode *inode,
loff_t offset, loff_t len)
up_write(_I(inode)->i_data_sem);
goto out_stop;
}
- ext4_discard_preallocations(inode);
+ ext4_discard_preallocations(inode, 0);
ret = ext4_ext_shift_extents(inode, handle, punch_stop,
punch_stop - punch_start, SHIFT_LEFT);
@@ -5445,7 +5445,7 @@ static int ext4_insert_range(struct inode *inode, loff_t
offset, loff_t len)
goto out_stop;
down_write(_I(inode)->i_data_sem);
- ext4_discard_preallocations(inode);
+ ext4_discard_preallocations(inode, 0);
path = ext4_find_extent(inode, offset_lblk, NULL, 0);
if (IS_ERR(path)) {
diff --git a/fs/ext4/file.c b/fs/ext4/file.c
index 2a01e31..e3ab8ea 100644
--- a/fs/ext4/file.c
+++ b/fs/ext4/file.c
@@ -148,7 +148,7 @@ static int ext4_release_file(struct inode *inode, struct
file *filp)
!EXT4_I(inode)->i_reserved_data_blocks)
{
down_write(_I(inode)->i_data_sem);
- ext4_discard_preallocations(inode);
+ ext4_discard_preallocations(inode, 0);
up_write(_I(inode)->i_data_sem);
}
if (is_dx(inode) && filp->private_data)
diff --git a/fs/ext4/indirect.c b/fs/ext4/indirect.c
index be2b66e..ec6b930 100644
--- a/fs/ext4/indirect.c
+++ b/fs/ext4/indirect.c
@@ -696,7 +696,7 @@ static int ext4_ind_trunc_restart_fn(handle_t *handle,
struct inode *inode,
* i_mutex. So we can safely drop the i_data_sem here.
*/
BUG_ON(EXT4_JOURNAL(inode) == NULL);
- ext4_discard_preallocations(inode);
+ ext4_discard_preallocations(inode, 0);
up_write(_I(inode)->i_data_sem);
*dropped = 1;
return 0;
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 10dd470..bb9e1cd 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -383,7 +383,7 @@ void ext4_da_update_reserve_space(struct inode
Re: [PATCH V17 3/3] Input: new da7280 haptic driver
On 7/23/20 6:54 PM, Roy Im wrote: > On Fri, July 24, 2020 5:51 AM, Randy Dunlap wrote >> On 7/23/20 8:01 AM, Roy Im wrote: >>> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig >>> index 362e8a0..06dc5a3 100644 >>> --- a/drivers/input/misc/Kconfig >>> +++ b/drivers/input/misc/Kconfig >>> @@ -869,4 +869,17 @@ config INPUT_STPMIC1_ONKEY >>> To compile this driver as a module, choose M here: the >>> module will be called stpmic1_onkey. >>> >>> +config INPUT_DA7280_HAPTICS >>> + tristate "Dialog Semiconductor DA7280 haptics support" >>> + depends on INPUT && I2C >>> + select INPUT_FF_MEMLESS >>> + select REGMAP_I2C >>> + help >>> + Say Y to enable support for the Dialog DA7280 haptics driver. >>> + The haptics can be controlled by I2C communication, >>> + or by PWM input, or by GPI. >> >>Is thatGPIO. >> ? > The Haptics can be working by GPI(if see from the haptic device), but from > the Host it is GPO. Do you think the GPIO is correct? To me it needs to represent what services/interfaces/facilities are used by this driver that are provided by the Linux kernel. If it uses Linux GPIO services, then it should say GPIO -- although I don't see it using any Linux GPIO services. >> >> Can the haptics be controlled only by PWM or only by GPI(O)? >> >> Just curious: why is I2C required to build the driver if a user is only >> controlling the device by PWM or GPI? > > I2C is required to control registers and it can be triggered by I2C or PWM or > GPI(controlled by host outside this driver), so PWM and GPI are optional. > With your comments, I think it's better to remove below lines(//remove) to > avoid confusion and add PWM as below if you agree. > // remove > The haptics can be controlled by I2C communication, > or by PWM input, or by GPI. > // update, adding || PWM > depends on (INPUT && I2C) || PWM Since provides stubs for when CONFIG_PWM is not enabled, it appears that "depends on PWM" is not required. I'll leave it up to you. I was just trying to understand better. It may be that no changes are needed. thanks. -- ~Randy
Re: [PATCH v5 4/4] dt-bindings: timer: Add CLINT bindings
On Thu, Jul 23, 2020 at 10:38 PM Rob Herring wrote:
>
> On Thu, Jul 23, 2020 at 07:54:09PM +0530, Anup Patel wrote:
> > We add DT bindings documentation for CLINT device.
> >
> > Signed-off-by: Anup Patel
> > Reviewed-by: Palmer Dabbelt
> > Tested-by: Emil Renner Berhing
> > ---
> > .../bindings/timer/sifive,clint.yaml | 58 +++
> > 1 file changed, 58 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/timer/sifive,clint.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/timer/sifive,clint.yaml
> > b/Documentation/devicetree/bindings/timer/sifive,clint.yaml
> > new file mode 100644
> > index ..8ad115611860
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/timer/sifive,clint.yaml
> > @@ -0,0 +1,58 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/timer/sifive,clint.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: SiFive Core Local Interruptor
> > +
> > +maintainers:
> > + - Palmer Dabbelt
> > + - Anup Patel
> > +
> > +description:
> > + SiFive (and other RISC-V) SOCs include an implementation of the SiFive
> > + Core Local Interruptor (CLINT) for M-mode timer and M-mode
> > inter-processor
> > + interrupts. It directly connects to the timer and inter-processor
> > interrupt
> > + lines of various HARTs (or CPUs) so RISC-V per-HART (or per-CPU) local
> > + interrupt controller is the parent interrupt controller for CLINT device.
> > + The clock frequency of CLINT is specified via "timebase-frequency" DT
> > + property of "/cpus" DT node. The "timebase-frequency" DT property is
> > + described in Documentation/devicetree/bindings/riscv/cpus.yaml
> > +
> > +properties:
> > + compatible:
> > +items:
> > + - const: sifive,clint0
> > + - const: sifive,fu540-c000-clint
>
> Wrong order. Most specific goes first.
Okay, will update.
>
> > +
> > +description:
> > + Should be "sifive,-clint" and "sifive,clint".
> > + Supported compatible strings are -
> > + "sifive,fu540-c000-clint" for the SiFive CLINT v0 as integrated
> > + onto the SiFive FU540 chip, and "sifive,clint0" for the SiFive
> > + CLINT v0 IP block with no chip integration tweaks.
> > + Please refer to sifive-blocks-ip-versioning.txt for details
> > +
> > + reg:
> > +maxItems: 1
> > +
> > + interrupts-extended:
> > +minItems: 1
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - interrupts-extended
>
> Add:
>
> additionalProperties: false
Okay, will add.
>
> > +
> > +examples:
> > + - |
> > +clint@200 {
>
> timer@...
Okay, will rename.
>
> > + compatible = "sifive,clint0", "sifive,fu540-c000-clint";
> > + interrupts-extended = < 3 7
> > + 3 7
> > + 3 7
> > + 3 7>;
> > + reg = <0x200 0x400>;
>
> 64MB of register space? Doesn't matter much for 64-bit, but would waste
> lots of virtual space (low mem) on 32-bit.
This is a typo. The register space size is 64KB not 64MB. I will update.
>
> > +};
> > +...
> > --
> > 2.25.1
> >
Regards,
Anup
Re: kernel BUG at mm/vmalloc.c:LINE! (2)
On Wed, 22 Jul 2020 16:46:50 +0200 Uladzislau Rezki wrote: > > > I can check further, but it can be it was not correctly reverted, > > > because everything should work just fine even with the revert, > > > though i i do not understand a reason of reverting. > > > > Vlad, how sure are you about this? We also start to trigger this now on > > linux-next, but the reverting patch surely looks like doggy without any > > useful > > information in the commit description. > > > Hello, Andrew, Qian. > > I am not aware of reason of the revert, though i tried to get through Ingo. > I can send out a patch that fixes the revert. Another option to drop the > revert, but it is up to Andrew and Ingo. > > Andrew, could you please comment on? All a bit mysterious. I think it's best that we revert this from linux-next until we hear from Ingo. I queued a patch - I expect Stephen will see and grab it, thanks.
include/asm-generic/qspinlock.h:94:9: sparse: sparse: context imbalance in 'rcu_nocb_unlock' - unexpected unlock
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: d15be546031cf65a0fc34879beca02fd90fe7ac7
commit: 5d6742b37727e111f4755155e59c5319cf5caa7b rcu/nocb: Use rcu_segcblist
for no-CBs CPUs
date: 12 months ago
config: sparc64-randconfig-s031-20200723 (attached as .config)
compiler: sparc64-linux-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.2-93-g4c6cbe55-dirty
git checkout 5d6742b37727e111f4755155e59c5319cf5caa7b
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=sparc64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
kernel/rcu/tree.c:1124:13: sparse: sparse: context imbalance in
'rcu_start_this_gp' - different lock contexts for basic block
kernel/rcu/tree.c:1520:9: sparse: sparse: context imbalance in 'rcu_gp_init'
- different lock contexts for basic block
kernel/rcu/tree.c:2226:9: sparse: sparse: context imbalance in
'force_qs_rnp' - different lock contexts for basic block
kernel/rcu/tree.c: note: in included file (through
arch/sparc/include/asm/qspinlock.h, arch/sparc/include/asm/spinlock_64.h,
arch/sparc/include/asm/spinlock.h, ...):
include/asm-generic/qspinlock.h:94:9: sparse: sparse: context imbalance in
'rcu_force_quiescent_state' - unexpected unlock
kernel/rcu/tree.c: note: in included file:
kernel/rcu/tree_exp.h:193:9: sparse: sparse: context imbalance in
'__rcu_report_exp_rnp' - different lock contexts for basic block
kernel/rcu/tree.c: note: in included file:
kernel/rcu/tree_plugin.h:1503:9: sparse: sparse: context imbalance in
'rcu_nocb_lock' - wrong count at exit
kernel/rcu/tree.c: note: in included file (through
arch/sparc/include/asm/qspinlock.h, arch/sparc/include/asm/spinlock_64.h,
arch/sparc/include/asm/spinlock.h, ...):
>> include/asm-generic/qspinlock.h:94:9: sparse: sparse: context imbalance in
>> 'rcu_nocb_unlock' - unexpected unlock
kernel/rcu/tree.c: note: in included file:
kernel/rcu/tree_plugin.h:1530:17: sparse: sparse: context imbalance in
'rcu_nocb_unlock_irqrestore' - unexpected unlock
kernel/rcu/tree_plugin.h:1611:13: sparse: sparse: context imbalance in
'__call_rcu_nocb_wake' - wrong count at exit
vim +/rcu_nocb_unlock +94 include/asm-generic/qspinlock.h
a33fda35e3a7655 Waiman Long 2015-04-24 83
a33fda35e3a7655 Waiman Long 2015-04-24 84 #ifndef queued_spin_unlock
a33fda35e3a7655 Waiman Long 2015-04-24 85 /**
a33fda35e3a7655 Waiman Long 2015-04-24 86 * queued_spin_unlock - release a
queued spinlock
a33fda35e3a7655 Waiman Long 2015-04-24 87 * @lock : Pointer to queued
spinlock structure
a33fda35e3a7655 Waiman Long 2015-04-24 88 */
a33fda35e3a7655 Waiman Long 2015-04-24 89 static __always_inline void
queued_spin_unlock(struct qspinlock *lock)
a33fda35e3a7655 Waiman Long 2015-04-24 90 {
a33fda35e3a7655 Waiman Long 2015-04-24 91 /*
ca50e426f96c905 Pan Xinhui 2016-06-03 92 * unlock() needs release
semantics:
a33fda35e3a7655 Waiman Long 2015-04-24 93 */
626e5fbc1435890 Will Deacon 2018-04-26 @94
smp_store_release(>locked, 0);
a33fda35e3a7655 Waiman Long 2015-04-24 95 }
a33fda35e3a7655 Waiman Long 2015-04-24 96 #endif
a33fda35e3a7655 Waiman Long 2015-04-24 97
:: The code at line 94 was first introduced by commit
:: 626e5fbc14358901ddaa90ce510e0fbeab310432 locking/qspinlock: Use
smp_store_release() in queued_spin_unlock()
:: TO: Will Deacon
:: CC: Ingo Molnar
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [fsnotify] c738fbabb0: will-it-scale.per_process_ops -9.5% regression
On 7/21/20 11:59 PM, Amir Goldstein wrote:
On Tue, Jul 21, 2020 at 3:15 AM kernel test robot wrote:
Greeting,
FYI, we noticed a -9.5% regression of will-it-scale.per_process_ops due to
commit:
commit: c738fbabb0ff62d0f9a9572e56e65d05a1b34c6a ("fsnotify: fold fsnotify() call
into fsnotify_parent()")
Strange, that's a pretty dumb patch moving some inlined code from one
function to
another (assuming there are no fsnotify marks in this test).
Unless I am missing something the only thing that changes slightly is
an extra d_inode(file->f_path.dentry) deference.
I can get rid of it.
Is it possible to ask for a re-test with fix patch (attached)?
Hi Amir,
We failed to apply this patch, could you tell us the base commit or the
base branch?
Best Regards,
Rong Chen
arch/x86/kvm/lapic.c:255:15: sparse: struct kvm_apic_map __rcu COPYING CREDITS Documentation Kbuild Kconfig LICENSES MAINTAINERS Makefile README arch block certs crypto drivers fs include init ipc ker
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: d15be546031cf65a0fc34879beca02fd90fe7ac7 commit: 670d0a4b10704667765f7d18f7592993d02783aa sparse: use identifiers to define address spaces date: 5 weeks ago config: i386-randconfig-s002-20200724 (attached as .config) compiler: gcc-9 (Debian 9.3.0-14) 9.3.0 reproduce: # apt-get install sparse # sparse version: v0.6.2-93-g4c6cbe55-dirty git checkout 670d0a4b10704667765f7d18f7592993d02783aa # save the attached .config to linux build tree make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=i386 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot sparse warnings: (new ones prefixed by >>) arch/x86/kvm/lapic.c:255:15: sparse: sparse: incompatible types in comparison expression (different address spaces): >> arch/x86/kvm/lapic.c:255:15: sparse:struct kvm_apic_map [noderef] __rcu * arch/x86/kvm/lapic.c:255:15: sparse:struct kvm_apic_map * arch/x86/kvm/lapic.c:257:9: sparse: sparse: incompatible types in comparison expression (different address spaces): arch/x86/kvm/lapic.c:257:9: sparse:struct kvm_apic_map [noderef] __rcu * arch/x86/kvm/lapic.c:257:9: sparse:struct kvm_apic_map * arch/x86/kvm/lapic.c:615:15: sparse: sparse: incompatible types in comparison expression (different address spaces): arch/x86/kvm/lapic.c:615:15: sparse:struct kvm_apic_map [noderef] __rcu * arch/x86/kvm/lapic.c:615:15: sparse:struct kvm_apic_map * arch/x86/kvm/lapic.c:972:15: sparse: sparse: incompatible types in comparison expression (different address spaces): arch/x86/kvm/lapic.c:972:15: sparse:struct kvm_apic_map [noderef] __rcu * arch/x86/kvm/lapic.c:972:15: sparse:struct kvm_apic_map * arch/x86/kvm/lapic.c:1014:15: sparse: sparse: incompatible types in comparison expression (different address spaces): arch/x86/kvm/lapic.c:1014:15: sparse:struct kvm_apic_map [noderef] __rcu * arch/x86/kvm/lapic.c:1014:15: sparse:struct kvm_apic_map * arch/x86/kvm/lapic.c:1151:15: sparse: sparse: incompatible types in comparison expression (different address spaces): arch/x86/kvm/lapic.c:1151:15: sparse:struct kvm_apic_map [noderef] __rcu * arch/x86/kvm/lapic.c:1151:15: sparse:struct kvm_apic_map * -- arch/x86/kvm/pmu.c:190:18: sparse: sparse: incompatible types in comparison expression (different address spaces): >> arch/x86/kvm/pmu.c:190:18: sparse:struct kvm_pmu_event_filter [noderef] >> __rcu * arch/x86/kvm/pmu.c:190:18: sparse:struct kvm_pmu_event_filter * arch/x86/kvm/pmu.c:251:18: sparse: sparse: incompatible types in comparison expression (different address spaces): arch/x86/kvm/pmu.c:251:18: sparse:struct kvm_pmu_event_filter [noderef] __rcu * arch/x86/kvm/pmu.c:251:18: sparse:struct kvm_pmu_event_filter * arch/x86/kvm/pmu.c:511:18: sparse: sparse: incompatible types in comparison expression (different address spaces): arch/x86/kvm/pmu.c:511:18: sparse:struct kvm_pmu_event_filter [noderef] __rcu * arch/x86/kvm/pmu.c:511:18: sparse:struct kvm_pmu_event_filter * arch/x86/kvm/pmu.c:511:18: sparse: sparse: incompatible types in comparison expression (different address spaces): arch/x86/kvm/pmu.c:511:18: sparse:struct kvm_pmu_event_filter [noderef] __rcu * arch/x86/kvm/pmu.c:511:18: sparse:struct kvm_pmu_event_filter * -- >> arch/x86/kvm/x86.c:2667:38: sparse: sparse: incorrect type in argument 1 >> (different address spaces) @@ expected void const [noderef] __user * @@ >>got unsigned char [usertype] * @@ >> arch/x86/kvm/x86.c:2667:38: sparse: expected void const [noderef] __user >> * arch/x86/kvm/x86.c:2667:38: sparse: got unsigned char [usertype] * arch/x86/kvm/x86.c:7630:15: sparse: sparse: incompatible types in comparison expression (different address spaces): >> arch/x86/kvm/x86.c:7630:15: sparse:struct kvm_apic_map [noderef] __rcu * arch/x86/kvm/x86.c:7630:15: sparse:struct kvm_apic_map * arch/x86/kvm/x86.c:10004:16: sparse: sparse: incompatible types in comparison expression (different address spaces): arch/x86/kvm/x86.c:10004:16: sparse:struct kvm_apic_map [noderef] __rcu * arch/x86/kvm/x86.c:10004:16: sparse:struct kvm_apic_map * arch/x86/kvm/x86.c:10005:15: sparse: sparse: incompatible types in comparison expression (different address spaces): >> arch/x86/kvm/x86.c:10005:15: sparse:struct kvm_pmu_event_filter >> [noderef] __rcu * arch/x86/kvm/x86.c:10005:15: sparse:struct kvm_pmu_event_filter * arch/x86/kvm/x86.c: note: in included file (through include/linux/notifier.h, include/linux/memory_hotplug.h, include/linux/mmzone.h, ...): include/linux/srcu.h:179:9: sparse: sparse: context imbalance in 'vcpu_enter_guest' - unexpected unlock vim +255 arch/x86/kvm/lapic.c 3b5a5ffa928a3f8 Radim
Re: [PATCH v3 1/1] PCI/ATS: Check PRI supported on the PF device when SRIOV is enabled
On 7/24/20 6:37 AM, Ashok Raj wrote:
PASID and PRI capabilities are only enumerated in PF devices. VF devices
do not enumerate these capabilites. IOMMU drivers also need to enumerate
them before enabling features in the IOMMU. Extending the same support as
PASID feature discovery (pci_pasid_features) for PRI.
Fixes: b16d0cb9e2fc ("iommu/vt-d: Always enable PASID/PRI PCI capabilities before
ATS")
Signed-off-by: Ashok Raj
To: Bjorn Helgaas
To: Joerg Roedel
To: Lu Baolu
Reviewed-by: Lu Baolu
Best regards,
baolu
Cc: sta...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Ashok Raj
Cc: io...@lists.linux-foundation.org
---
v3: Added Fixes tag
v2: Fixed build failure reported from lkp when CONFIG_PRI=n
drivers/iommu/intel/iommu.c | 2 +-
drivers/pci/ats.c | 13 +
include/linux/pci-ats.h | 4
3 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index d759e7234e98..276452f5e6a7 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -2560,7 +2560,7 @@ static struct dmar_domain
*dmar_insert_one_dev_info(struct intel_iommu *iommu,
}
if (info->ats_supported && ecap_prs(iommu->ecap) &&
- pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_PRI))
+ pci_pri_supported(pdev))
info->pri_supported = 1;
}
}
diff --git a/drivers/pci/ats.c b/drivers/pci/ats.c
index b761c1f72f67..2e6cf0c700f7 100644
--- a/drivers/pci/ats.c
+++ b/drivers/pci/ats.c
@@ -325,6 +325,19 @@ int pci_prg_resp_pasid_required(struct pci_dev *pdev)
return pdev->pasid_required;
}
+
+/**
+ * pci_pri_supported - Check if PRI is supported.
+ * @pdev: PCI device structure
+ *
+ * Returns true if PRI capability is present, false otherwise.
+ */
+bool pci_pri_supported(struct pci_dev *pdev)
+{
+ /* VFs share the PF PRI configuration */
+ return !!(pci_physfn(pdev)->pri_cap);
+}
+EXPORT_SYMBOL_GPL(pci_pri_supported);
#endif /* CONFIG_PCI_PRI */
#ifdef CONFIG_PCI_PASID
diff --git a/include/linux/pci-ats.h b/include/linux/pci-ats.h
index f75c307f346d..df54cd5b15db 100644
--- a/include/linux/pci-ats.h
+++ b/include/linux/pci-ats.h
@@ -28,6 +28,10 @@ int pci_enable_pri(struct pci_dev *pdev, u32 reqs);
void pci_disable_pri(struct pci_dev *pdev);
int pci_reset_pri(struct pci_dev *pdev);
int pci_prg_resp_pasid_required(struct pci_dev *pdev);
+bool pci_pri_supported(struct pci_dev *pdev);
+#else
+static inline bool pci_pri_supported(struct pci_dev *pdev)
+{ return false; }
#endif /* CONFIG_PCI_PRI */
#ifdef CONFIG_PCI_PASID
Re: [PATCH v2] mm/page_alloc: fix memalloc_nocma_{save/restore} APIs
On Fri, 24 Jul 2020 11:23:52 +0900 Joonsoo Kim wrote: > > > Second, clearing __GFP_MOVABLE in current_gfp_context() has a side effect > > > to exclude the memory on the ZONE_MOVABLE for allocation target. > > > > More whoops. > > > > Could we please have a description of the end-user-visible effects of > > this change? Very much needed when proposing a -stable backport, I think. > > In fact, there is no noticeable end-user-visible effect since the fallback > would > cover the problematic case. It's mentioned in the commit description. Perhap, > performance would be improved due to reduced retry and more available memory > (we can use ZONE_MOVABLE with this patch) but it would be neglectable. > > > d7fefcc8de9147c is over a year old. Why did we only just discover > > this? This makes one wonder how serious those end-user-visible effects > > are? > > As mentioned above, there is no visible problem to the end-user. OK, thanks. In that case, I don't believe that a stable backport is appropriate? (Documentation/process/stable-kernel-rules.rst)
Re: [RFC PATCH 11/16] sched: migration changes for core scheduling(Internet mail)
Hi,
> On Jul 24, 2020, at 10:05 AM, Li, Aubrey wrote:
>
> On 2020/7/24 9:26, benbjiang(蒋彪) wrote:
>> Hi,
>>
>>> On Jul 24, 2020, at 7:43 AM, Aubrey Li wrote:
>>>
>>> On Thu, Jul 23, 2020 at 4:28 PM benbjiang(蒋彪) wrote:
Hi,
> On Jul 23, 2020, at 4:06 PM, Li, Aubrey wrote:
>
> On 2020/7/23 15:47, benbjiang(蒋彪) wrote:
>> Hi,
>>
>>> On Jul 23, 2020, at 1:39 PM, Li, Aubrey
>>> wrote:
>>>
>>> On 2020/7/23 12:23, benbjiang(蒋彪) wrote:
Hi,
> On Jul 23, 2020, at 11:35 AM, Li, Aubrey
> wrote:
>
> On 2020/7/23 10:42, benbjiang(蒋彪) wrote:
>> Hi,
>>
>>> On Jul 23, 2020, at 9:57 AM, Li, Aubrey
>>> wrote:
>>>
>>> On 2020/7/22 22:32, benbjiang(蒋彪) wrote:
Hi,
> On Jul 22, 2020, at 8:13 PM, Li, Aubrey
> wrote:
>
> On 2020/7/22 16:54, benbjiang(蒋彪) wrote:
>> Hi, Aubrey,
>>
>>> On Jul 1, 2020, at 5:32 AM, Vineeth Remanan Pillai
>>> wrote:
>>>
>>> From: Aubrey Li
>>>
>>> - Don't migrate if there is a cookie mismatch
>>> Load balance tries to move task from busiest CPU to the
>>> destination CPU. When core scheduling is enabled, if the
>>> task's cookie does not match with the destination CPU's
>>> core cookie, this task will be skipped by this CPU. This
>>> mitigates the forced idle time on the destination CPU.
>>>
>>> - Select cookie matched idle CPU
>>> In the fast path of task wakeup, select the first cookie matched
>>> idle CPU instead of the first idle CPU.
>>>
>>> - Find cookie matched idlest CPU
>>> In the slow path of task wakeup, find the idlest CPU whose core
>>> cookie matches with task's cookie
>>>
>>> - Don't migrate task if cookie not match
>>> For the NUMA load balance, don't migrate task to the CPU whose
>>> core cookie does not match with task's cookie
>>>
>>> Signed-off-by: Aubrey Li
>>> Signed-off-by: Tim Chen
>>> Signed-off-by: Vineeth Remanan Pillai
>>> ---
>>> kernel/sched/fair.c | 64
>>>
>>> kernel/sched/sched.h | 29
>>> 2 files changed, 88 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>>> index d16939766361..33dc4bf01817 100644
>>> --- a/kernel/sched/fair.c
>>> +++ b/kernel/sched/fair.c
>>> @@ -2051,6 +2051,15 @@ static void task_numa_find_cpu(struct
>>> task_numa_env *env,
>>> if (!cpumask_test_cpu(cpu, env->p->cpus_ptr))
>>> continue;
>>>
>>> +#ifdef CONFIG_SCHED_CORE
>>> + /*
>>> +* Skip this cpu if source task's cookie does not
>>> match
>>> +* with CPU's core cookie.
>>> +*/
>>> + if (!sched_core_cookie_match(cpu_rq(cpu), env->p))
>>> + continue;
>>> +#endif
>>> +
>>> env->dst_cpu = cpu;
>>> if (task_numa_compare(env, taskimp, groupimp,
>>> maymove))
>>> break;
>>> @@ -5963,11 +5972,17 @@ find_idlest_group_cpu(struct
>>> sched_group *group, struct task_struct *p, int this
>>>
>>> /* Traverse only the allowed CPUs */
>>> for_each_cpu_and(i, sched_group_span(group), p->cpus_ptr) {
>>> + struct rq *rq = cpu_rq(i);
>>> +
>>> +#ifdef CONFIG_SCHED_CORE
>>> + if (!sched_core_cookie_match(rq, p))
>>> + continue;
>>> +#endif
>>> +
>>> if (sched_idle_cpu(i))
>>> return i;
>>>
>>> if (available_idle_cpu(i)) {
>>> - struct rq *rq = cpu_rq(i);
>>> struct cpuidle_state *idle =
>>> idle_get_state(rq);
>>> if (idle && idle->exit_latency <
>>> min_exit_latency) {
>>> /*
>>> @@ -6224,8 +6239,18 @@ static int select_idle_cpu(struct
>>> task_struct *p, struct sched_domain *sd, int t
>>> for_each_cpu_wrap(cpu, cpus, target) {
>>> if (!--nr)
linux-next: manual merge of the net-next tree with the net tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
drivers/net/geneve.c
between commit:
32818c075c54 ("geneve: fix an uninitialized value in geneve_changelink()")
from the net tree and commit:
9e06e8596bc8 ("geneve: move all configuration under struct geneve_config")
from the net-next tree.
I fixed it up (the latter removed the code moved by the former) and can
carry the fix as necessary. This is now fixed as far as linux-next is
concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging. You may
also want to consider cooperating with the maintainer of the
conflicting tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgpOS1GnCZIik.pgp
Description: OpenPGP digital signature
Re: [PATCH 1/2] lockdep: improve current->(hard|soft)irqs_enabled synchronisation with actual irq state
Hi Nicholas,
I love your patch! Yet something to improve:
[auto build test ERROR on linux/master]
[also build test ERROR on powerpc/next linus/master v5.8-rc6 next-20200723]
[cannot apply to tip/locking/core]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Nicholas-Piggin/lockdep-improve-current-hard-soft-irqs_enabled-synchronisation-with-actual-irq-state/20200723-185938
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
9ebcfadb0610322ac537dd7aa5d9cbc2b2894c68
config: nds32-allyesconfig (attached as .config)
compiler: nds32le-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=nds32
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
In file included from include/asm-generic/bitops.h:14,
from ./arch/nds32/include/generated/asm/bitops.h:1,
from include/linux/bitops.h:29,
from include/linux/kernel.h:12,
from include/linux/list.h:9,
from include/linux/rculist.h:10,
from include/linux/pid.h:5,
from include/linux/sched.h:14,
from arch/nds32/kernel/asm-offsets.c:4:
include/linux/spinlock_api_smp.h: In function '__raw_spin_lock_irq':
>> include/linux/irqflags.h:158:31: error: implicit declaration of function
>> 'arch_irqs_disabled'; did you mean 'raw_irqs_disabled'?
>> [-Werror=implicit-function-declaration]
158 | #define raw_irqs_disabled() (arch_irqs_disabled())
| ^~
include/linux/irqflags.h:174:23: note: in expansion of macro
'raw_irqs_disabled'
174 | bool was_disabled = raw_irqs_disabled(); \
| ^
include/linux/spinlock_api_smp.h:126:2: note: in expansion of macro
'local_irq_disable'
126 | local_irq_disable();
| ^
cc1: some warnings being treated as errors
make[2]: *** [scripts/Makefile.build:114: arch/nds32/kernel/asm-offsets.s]
Error 1
make[2]: Target '__build' not remade because of errors.
make[1]: *** [Makefile:1175: prepare0] Error 2
make[1]: Target 'prepare' not remade because of errors.
make: *** [Makefile:185: __sub-make] Error 2
make: Target 'prepare' not remade because of errors.
vim +158 include/linux/irqflags.h
81d68a96a398448 Steven Rostedt 2008-05-12 132
df9ee29270c11db David Howells 2010-10-07 133 /*
df9ee29270c11db David Howells 2010-10-07 134 * Wrap the arch provided IRQ
routines to provide appropriate checks.
df9ee29270c11db David Howells 2010-10-07 135 */
df9ee29270c11db David Howells 2010-10-07 136 #define raw_local_irq_disable()
arch_local_irq_disable()
df9ee29270c11db David Howells 2010-10-07 137 #define raw_local_irq_enable()
arch_local_irq_enable()
df9ee29270c11db David Howells 2010-10-07 138 #define
raw_local_irq_save(flags) \
df9ee29270c11db David Howells 2010-10-07 139 do {
\
df9ee29270c11db David Howells 2010-10-07 140
typecheck(unsigned long, flags);\
df9ee29270c11db David Howells 2010-10-07 141 flags =
arch_local_irq_save(); \
df9ee29270c11db David Howells 2010-10-07 142 } while (0)
df9ee29270c11db David Howells 2010-10-07 143 #define
raw_local_irq_restore(flags)\
df9ee29270c11db David Howells 2010-10-07 144 do {
\
df9ee29270c11db David Howells 2010-10-07 145
typecheck(unsigned long, flags);\
df9ee29270c11db David Howells 2010-10-07 146
arch_local_irq_restore(flags); \
df9ee29270c11db David Howells 2010-10-07 147 } while (0)
df9ee29270c11db David Howells 2010-10-07 148 #define
raw_local_save_flags(flags) \
df9ee29270c11db David Howells 2010-10-07 149 do {
\
df9ee29270c11db David Howells 2010-10-07 150
typecheck(unsigned long, flags);\
df9ee29270c11db David Howells 2010-10-07 151 flags =
arch_local_save_flags();\
df9ee29270c11db David Howells 2010-10-07 152 } while (0)
df9ee29270c11db David Howells 2010-10-07 153 #define
raw_irqs_disabled_flags(flags)
Re: [PATCH v2] mm/page_alloc: fix memalloc_nocma_{save/restore} APIs
2020년 7월 24일 (금) 오전 10:08, Andrew Morton 님이 작성:
>
> On Thu, 23 Jul 2020 10:49:02 +0900 js1...@gmail.com wrote:
>
> > From: Joonsoo Kim
> >
> > Currently, memalloc_nocma_{save/restore} API that prevents CMA area
> > in page allocation is implemented by using current_gfp_context(). However,
> > there are two problems of this implementation.
> >
> > First, this doesn't work for allocation fastpath. In the fastpath,
> > original gfp_mask is used since current_gfp_context() is introduced in
> > order to control reclaim and it is on slowpath. So, CMA area can be
> > allocated through the allocation fastpath even if
> > memalloc_nocma_{save/restore} APIs are used.
>
> Whoops.
>
> > Currently, there is just
> > one user for these APIs and it has a fallback method to prevent actual
> > problem.
>
> Shouldn't the patch remove the fallback method?
It's not just the fallback but it also has its own functionality. So,
we should not remove it.
> > Second, clearing __GFP_MOVABLE in current_gfp_context() has a side effect
> > to exclude the memory on the ZONE_MOVABLE for allocation target.
>
> More whoops.
>
> Could we please have a description of the end-user-visible effects of
> this change? Very much needed when proposing a -stable backport, I think.
In fact, there is no noticeable end-user-visible effect since the fallback would
cover the problematic case. It's mentioned in the commit description. Perhap,
performance would be improved due to reduced retry and more available memory
(we can use ZONE_MOVABLE with this patch) but it would be neglectable.
> d7fefcc8de9147c is over a year old. Why did we only just discover
> this? This makes one wonder how serious those end-user-visible effects
> are?
As mentioned above, there is no visible problem to the end-user.
Thanks.
linux-next: manual merge of the net-next tree with the net tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
drivers/net/ethernet/freescale/enetc/enetc_pf.c
between commit:
26cb7085c898 ("enetc: Remove the mdio bus on PF probe bailout")
from the net tree and commits:
07095c025ac2 ("net: enetc: Use DT protocol information to set up the ports")
c6dd6488acd1 ("enetc: Remove the imdio bus on PF probe bailout")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
pgpGaO2F3xwqO.pgp
Description: OpenPGP digital signature
