[PATCH v2] riscv: Return -EFAULT if copy_{to,from}_user() failed in signal.c
copy_{to,from}_user() returns the amount left to copy, it should return
-EFAULT error code if copy {to,from} user failed, just like the return
value is an error code when {put,get}_user() failed, this is to make the
return value consistent, no function change.
Signed-off-by: Tiezhu Yang
---
arch/riscv/kernel/signal.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/riscv/kernel/signal.c b/arch/riscv/kernel/signal.c
index 65942b3..c76d877 100644
--- a/arch/riscv/kernel/signal.c
+++ b/arch/riscv/kernel/signal.c
@@ -39,7 +39,7 @@ static long restore_fp_state(struct pt_regs *regs,
err = __copy_from_user(>thread.fstate, state, sizeof(*state));
if (unlikely(err))
- return err;
+ return -EFAULT;
fstate_restore(current, regs);
@@ -67,7 +67,7 @@ static long save_fp_state(struct pt_regs *regs,
fstate_save(current, regs);
err = __copy_to_user(state, >thread.fstate, sizeof(*state));
if (unlikely(err))
- return err;
+ return -EFAULT;
/* We support no other extension state at this time. */
for (i = 0; i < ARRAY_SIZE(sc_fpregs->q.reserved); i++) {
@@ -87,8 +87,12 @@ static long restore_sigcontext(struct pt_regs *regs,
struct sigcontext __user *sc)
{
long err;
+
/* sc_regs is structured the same as the start of pt_regs */
err = __copy_from_user(regs, >sc_regs, sizeof(sc->sc_regs));
+ if (unlikely(err))
+ return -EFAULT;
+
/* Restore the floating-point state. */
if (has_fpu)
err |= restore_fp_state(regs, >sc_fpregs);
@@ -140,8 +144,12 @@ static long setup_sigcontext(struct rt_sigframe __user
*frame,
{
struct sigcontext __user *sc = >uc.uc_mcontext;
long err;
+
/* sc_regs is structured the same as the start of pt_regs */
err = __copy_to_user(>sc_regs, regs, sizeof(sc->sc_regs));
+ if (unlikely(err))
+ return -EFAULT;
+
/* Save the floating-point state. */
if (has_fpu)
err |= save_fp_state(regs, >sc_fpregs);
--
2.1.0
Re: [RFC v3] scripts: kernel-doc: fix typedef support for struct/union parsing
On 6/3/21 11:55 am, Lukas Bulwahn wrote:
> On Sat, Mar 6, 2021 at 5:35 AM Matthew Wilcox wrote:
>>
>> On Thu, Feb 25, 2021 at 08:20:33PM +0530, Aditya Srivastava wrote:
>>> +++ b/scripts/kernel-doc
>>> @@ -1201,12 +1201,23 @@ sub dump_union($$) {
>>> sub dump_struct($$) {
>>> my $x = shift;
>>> my $file = shift;
>>> +my $decl_type;
>>> +my $members;
>>> +my $type = qr{struct|union};
>>> +# For capturing struct/union definition body, i.e.
>>> "{members*}qualifiers*"
>>> +my $definition_body =
>>> qr{\{(.*)\}(?:\s*(?:__packed|__aligned|cacheline_aligned_in_smp|cacheline_aligned|__attribute__\s*\(\([a-z0-9,_\s\(\)]*\)\)))*};
>>> -if ($x =~
>>> /(struct|union)\s+(\w+)\s*\{(.*)\}(\s*(__packed|__aligned|cacheline_aligned_in_smp|cacheline_aligned|__attribute__\s*\(\([a-z0-9,_\s\(\)]*\)\)))*/)
>>> {
>>> - my $decl_type = $1;
>>> +if ($x =~ /($type)\s+(\w+)\s*$definition_body/) {
>>> + $decl_type = $1;
>>> $declaration_name = $2;
>>> - my $members = $3;
>>> + $members = $3;
>>> +} elsif ($x =~ /typedef\s+($type)\s*$definition_body\s*(\w+)\s*;/) {
>>> + $decl_type = $1;
>>> + $declaration_name = $3;
>>> + $members = $2;
>>> +}
>>
>> In the same spirit as dump_function, would something like this work?
>>
>
> I agree. That might be a suitable clean-up to keep the code for
> functions and struct/union parsing similar in style/spirit.
>
> Aditya, would you like to create a patch for that?
>
Sure Lukas.
I have a doubt though, Can't we use a single expression separated by
"|" here, instead of multiple lines? i.e.,
$x =~
s/__packed|__aligned|cacheline_aligned_in_smp|cacheline_aligned|__attribute__\s*\(\([a-z0-9,_\s\(\)]*\)\)\s*//;
Probably we could do something similar for dump_function, i.e.,
-$prototype =~ s/^static +//;
-$prototype =~ s/^extern +//;
-$prototype =~ s/^asmlinkage +//;
-$prototype =~ s/^inline +//;
-$prototype =~ s/^__inline__ +//;
-$prototype =~ s/^__inline +//;
-$prototype =~ s/^__always_inline +//;
-$prototype =~ s/^noinline +//;
+$prototype =~
s/^(?:static|extern|asmlinkage|__?inline__?|__always_inline|noinline) +//;
And so on for other regexps.
What do you think?
Thanks
Aditya
[syzbot] bpf-next boot error: WARNING in kvm_wait
Hello, syzbot found the following issue on: HEAD commit:d01b59c9 bpf: Add bpf_skb_adjust_room flag BPF_F_ADJ_ROOM_.. git tree: bpf-next console output: https://syzkaller.appspot.com/x/log.txt?x=1592bd66d0 kernel config: https://syzkaller.appspot.com/x/.config?x=66df2ca4f2dd3022 dashboard link: https://syzkaller.appspot.com/bug?extid=72d60f48cda58f46375a IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+72d60f48cda58f463...@syzkaller.appspotmail.com [ cut here ] raw_local_irq_restore() called with IRQs enabled WARNING: CPU: 0 PID: 4813 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x1d/0x20 kernel/locking/irqflag-debug.c:10 Modules linked in: CPU: 0 PID: 4813 Comm: systemd-cryptse Not tainted 5.11.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:warn_bogus_irq_restore+0x1d/0x20 kernel/locking/irqflag-debug.c:10 Code: bf ff cc cc cc cc cc cc cc cc cc cc cc 80 3d ca 72 b1 04 00 74 01 c3 48 c7 c7 40 a2 6b 89 c6 05 b9 72 b1 04 01 e8 b8 37 bf ff <0f> 0b c3 48 39 77 10 0f 84 97 00 00 00 66 f7 47 22 f0 ff 74 4b 48 RSP: 0018:c900012dfc40 EFLAGS: 00010282 RAX: RBX: 8be287a0 RCX: RDX: 88802383 RSI: 815b6895 RDI: f5200025bf7a RBP: 0200 R08: R09: 0001 R10: 815af76e R11: R12: 0003 R13: fbfff17c50f4 R14: 0001 R15: 8880b9c35f40 FS: () GS:8880b9c0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f1b759e04b0 CR3: 0bc8e000 CR4: 001506f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: kvm_wait arch/x86/kernel/kvm.c:860 [inline] kvm_wait+0xc9/0xe0 arch/x86/kernel/kvm.c:837 pv_wait arch/x86/include/asm/paravirt.h:564 [inline] pv_wait_head_or_lock kernel/locking/qspinlock_paravirt.h:470 [inline] __pv_queued_spin_lock_slowpath+0x8b8/0xb40 kernel/locking/qspinlock.c:508 pv_queued_spin_lock_slowpath arch/x86/include/asm/paravirt.h:554 [inline] queued_spin_lock_slowpath arch/x86/include/asm/qspinlock.h:51 [inline] queued_spin_lock include/asm-generic/qspinlock.h:85 [inline] do_raw_spin_lock+0x200/0x2b0 kernel/locking/spinlock_debug.c:113 spin_lock include/linux/spinlock.h:354 [inline] check_stack_usage kernel/exit.c:715 [inline] do_exit+0x1d6a/0x2ae0 kernel/exit.c:868 do_group_exit+0x125/0x310 kernel/exit.c:922 __do_sys_exit_group kernel/exit.c:933 [inline] __se_sys_exit_group kernel/exit.c:931 [inline] __x64_sys_exit_group+0x3a/0x50 kernel/exit.c:931 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fed7b5d0618 Code: Unable to access opcode bytes at RIP 0x7fed7b5d05ee. RSP: 002b:7fff094428a8 EFLAGS: 0246 ORIG_RAX: 00e7 RAX: ffda RBX: RCX: 7fed7b5d0618 RDX: RSI: 003c RDI: RBP: 7fed7b8ad8e0 R08: 00e7 R09: fee8 R10: 7fed79a8b158 R11: 0246 R12: 7fed7b8ad8e0 R13: 7fed7b8b2c20 R14: R15: --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
[syzbot] net boot error: WARNING in kvm_wait
Hello, syzbot found the following issue on: HEAD commit:ad5d07f4 cipso,calipso: resolve a number of problems with .. git tree: net console output: https://syzkaller.appspot.com/x/log.txt?x=12aca7cad0 kernel config: https://syzkaller.appspot.com/x/.config?x=402784bff477e1ac dashboard link: https://syzkaller.appspot.com/bug?extid=9e58a3a510889fa4af50 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+9e58a3a510889fa4a...@syzkaller.appspotmail.com [ cut here ] raw_local_irq_restore() called with IRQs enabled WARNING: CPU: 0 PID: 4788 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x1d/0x20 kernel/locking/irqflag-debug.c:10 Modules linked in: CPU: 0 PID: 4788 Comm: systemd-cryptse Not tainted 5.11.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:warn_bogus_irq_restore+0x1d/0x20 kernel/locking/irqflag-debug.c:10 Code: be ff cc cc cc cc cc cc cc cc cc cc cc 80 3d 1e 61 b0 04 00 74 01 c3 48 c7 c7 a0 8e 6b 89 c6 05 0d 61 b0 04 01 e8 57 da be ff <0f> 0b c3 48 39 77 10 0f 84 97 00 00 00 66 f7 47 22 f0 ff 74 4b 48 RSP: 0018:c9edfc40 EFLAGS: 00010282 RAX: RBX: 8be28b80 RCX: RDX: 888023441bc0 RSI: 815bea35 RDI: f520001dbf7a RBP: 0200 R08: R09: 0001 R10: 815b77be R11: R12: 0003 R13: fbfff17c5170 R14: 0001 R15: 8880b9c35f40 FS: () GS:8880b9c0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f95c090fab4 CR3: 0bc8e000 CR4: 001506f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: kvm_wait arch/x86/kernel/kvm.c:860 [inline] kvm_wait+0xc9/0xe0 arch/x86/kernel/kvm.c:837 pv_wait arch/x86/include/asm/paravirt.h:564 [inline] pv_wait_head_or_lock kernel/locking/qspinlock_paravirt.h:470 [inline] __pv_queued_spin_lock_slowpath+0x8b8/0xb40 kernel/locking/qspinlock.c:508 pv_queued_spin_lock_slowpath arch/x86/include/asm/paravirt.h:554 [inline] queued_spin_lock_slowpath arch/x86/include/asm/qspinlock.h:51 [inline] queued_spin_lock include/asm-generic/qspinlock.h:85 [inline] do_raw_spin_lock+0x200/0x2b0 kernel/locking/spinlock_debug.c:113 spin_lock include/linux/spinlock.h:354 [inline] check_stack_usage kernel/exit.c:715 [inline] do_exit+0x1d6a/0x2ae0 kernel/exit.c:868 do_group_exit+0x125/0x310 kernel/exit.c:922 __do_sys_exit_group kernel/exit.c:933 [inline] __se_sys_exit_group kernel/exit.c:931 [inline] __x64_sys_exit_group+0x3a/0x50 kernel/exit.c:931 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f95c1fe8618 Code: Unable to access opcode bytes at RIP 0x7f95c1fe85ee. RSP: 002b:7fff576bc048 EFLAGS: 0246 ORIG_RAX: 00e7 RAX: ffda RBX: RCX: 7f95c1fe8618 RDX: RSI: 003c RDI: RBP: 7f95c22c58e0 R08: 00e7 R09: fee8 R10: 7f95c04a3158 R11: 0246 R12: 7f95c22c58e0 R13: 7f95c22cac20 R14: R15: --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
Re: [PATCH v3 7/7] MIPS: Loongson64: Add a Loongson-2k default config file
On 03/06/2021 10:36 AM, Qing Zhang wrote: Add default config for 2K1000. Signed-off-by: Jiaxun Yang Signed-off-by: Qing Zhang Tested-by: Ming Wang Thanks, Ming
Re: [PATCH v3 6/7] dt-bindings: interrupt-controller: Add Loongson-2K1000 LIOINTC
On 03/06/2021 10:36 AM, Qing Zhang wrote: Add liointc-2.0 properties support, so update the maxItems and description. Signed-off-by: Jiaxun Yang Signed-off-by: Qing Zhang Tested-by: Ming Wang Thanks, Ming
Re: [PATCH v3 5/7] irqchip/loongson-liointc: irqchip add 2.0 version
On 03/06/2021 10:36 AM, Qing Zhang wrote: Add IO interrupt controller support for Loongson 2k1000, different from the 3a series is that 2K1000 has 64 interrupt sources, 0-31 correspond to the device tree liointc0 device node, and the other correspond to liointc1 node. Signed-off-by: Jiaxun Yang Signed-off-by: Qing Zhang Tested-by: Ming Wang Thanks, Ming
Re: [PATCH v3 4/7] MIPS: Loongson64: Add 2K1000 early_printk_port
On 03/06/2021 10:36 AM, Qing Zhang wrote: Distinguish between 3A series CPU and 2K1000 CPU UART0. Signed-off-by: Jiaxun Yang Signed-off-by: Qing Zhang Tested-by: Ming Wang Thanks, Ming
Re: [PATCH v3 3/7] MIPS: Loongson64: Add support for the 2K1000 to get cpu_clock_freq
On 03/06/2021 10:36 AM, Qing Zhang wrote: Get the fixed-clock from the CPU0 node of the device tree. Signed-off-by: Jiaxun Yang Signed-off-by: Qing Zhang Tested-by: Ming Wang Thanks, Ming
Re: [PATCH v3 2/7] MIPS: Loongson64: Distinguish firmware dependencies DTB/LEFI
On 03/06/2021 10:36 AM, Qing Zhang wrote: Add DTB boot support, only support LS2K1000 processor for now, determine whether to use the built-in DTB or the DTB from the firmware by checking the range of CKSEG0 and XKPHYS.loongson_fw _interface will be used in the future. Signed-off-by: Jiaxun Yang Signed-off-by: Qing Zhang Tested-by: Ming Wang Thanks, Ming
Re: [PATCH v3 1/7] MIPS: Loongson64: DeviceTree for 2K1000
On 03/06/2021 10:36 AM, Qing Zhang wrote: Add DeviceTree files for Loongson 2K1000 processor,currently only supports single-core boot. Signed-off-by: Jiaxun Yang Signed-off-by: Qing Zhang Tested-by: Ming Wang Thanks, Ming
Re: [PATCH v9 2/6] dt: bindings: add mt7621-clk device tree binding documentation
Hi Rob,
On Fri, Mar 5, 2021 at 11:47 PM Rob Herring wrote:
[snip]
> > +
> > + ralink,sysctl:
> > +$ref: /schemas/types.yaml#/definitions/phandle
> > +description:
> > + phandle of syscon used to control system registers
> > +
> > + ralink,memctl:
> > +$ref: /schemas/types.yaml#/definitions/phandle
> > +description:
> > + phandle of syscon used to control memory registers
>
> I assume one of these phandles are the main registers for the clocks?
> Make this a child node and drop that phandle.
The 'ralink,sysctl' phandle is to read bootstrap register to be able
to derive xtal and a clk gate register for the peripherals.
The 'ralink,memctl' phandle is to read the cpu clock frequency from
the memory controller.
So there is not "main registers". I already put this as a child node
in v4 and I was told to get rid of child nodes. I need this as a
regmap to other DT node registers (sysctl, and memctl) to be able to
use the driver without specific architecture operations and properly
enable for COMPILE_TEST without dirty Makefile arch flags. Both sysctl
and memctl has no other child nodes, and I think that's why I was told
to avoid child nodes at the end. I explained here [0] current sysctl
and memctl in the mt7621 device tree and my view of the need for this
two syscons:
[0]: https://lkml.org/lkml/2021/1/2/9
So to avoid to send again "a previous version" on this patch, please
guide me in the correct thing to do. Stephen, Rob, I will be really
happy with your help :)
Best regards,
Sergio Paracuellos
>
> > +
> > + clock-output-names:
> > +maxItems: 8
> > +
> > +required:
> > + - compatible
> > + - '#clock-cells'
> > + - ralink,sysctl
> > + - ralink,memctl
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > +#include
> > +
> > +pll {
> > + compatible = "mediatek,mt7621-clk";
> > + #clock-cells = <1>;
> > + ralink,sysctl = <>;
> > + ralink,memctl = <>;
> > + clock-output-names = "xtal", "cpu", "bus",
> > + "50m", "125m", "150m",
> > + "250m", "270m";
> > +};
> > --
> > 2.25.1
> >
[PATCH] csky: fix typos
From: Junlin Yang
fixes three typos found by codespell.
Signed-off-by: Junlin Yang
---
arch/csky/include/asm/asid.h| 2 +-
arch/csky/include/asm/barrier.h | 2 +-
arch/csky/include/asm/vdso.h| 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/csky/include/asm/asid.h b/arch/csky/include/asm/asid.h
index ac08b0f..6ff205a 100644
--- a/arch/csky/include/asm/asid.h
+++ b/arch/csky/include/asm/asid.h
@@ -37,7 +37,7 @@ void asid_new_context(struct asid_info *info, atomic64_t
*pasid,
* Check the ASID is still valid for the context. If not generate a new ASID.
*
* @pasid: Pointer to the current ASID batch
- * @cpu: current CPU ID. Must have been acquired throught get_cpu()
+ * @cpu: current CPU ID. Must have been acquired through get_cpu()
*/
static inline void asid_check_context(struct asid_info *info,
atomic64_t *pasid, unsigned int cpu,
diff --git a/arch/csky/include/asm/barrier.h b/arch/csky/include/asm/barrier.h
index 84fc600c..f4045dd 100644
--- a/arch/csky/include/asm/barrier.h
+++ b/arch/csky/include/asm/barrier.h
@@ -64,7 +64,7 @@
/*
* sync:completion barrier, all sync.xx instructions
- * guarantee the last response recieved by bus transaction
+ * guarantee the last response received by bus transaction
* made by ld/st instructions before sync.s
* sync.s: inherit from sync, but also shareable to other cores
* sync.i: inherit from sync, but also flush cpu pipeline
diff --git a/arch/csky/include/asm/vdso.h b/arch/csky/include/asm/vdso.h
index eb5142f..bdce581 100644
--- a/arch/csky/include/asm/vdso.h
+++ b/arch/csky/include/asm/vdso.h
@@ -16,7 +16,7 @@ struct vdso_data {
* offset of 0, but since the linker must support setting weak undefined
* symbols to the absolute address 0 it also happens to support other low
* addresses even when the code model suggests those low addresses would not
- * otherwise be availiable.
+ * otherwise be available.
*/
#define VDSO_SYMBOL(base, name)
\
({
\
--
1.9.1
[PATCH] x86/traps: remove duplicate include in traps.c
From: Zhang Yunkai 'proto.h' included in 'traps.c' is duplicated. Signed-off-by: Zhang Yunkai --- arch/x86/kernel/traps.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c index 7f5aec758f0e..cb9b675dc003 100644 --- a/arch/x86/kernel/traps.c +++ b/arch/x86/kernel/traps.c @@ -61,14 +61,13 @@ #include #include #include +#include #ifdef CONFIG_X86_64 #include -#include #else #include #include -#include #endif DECLARE_BITMAP(system_vectors, NR_VECTORS); -- 2.25.1
Re: Linux 5.12-rc1
On Mon, Mar 1, 2021 at 10:34 PM Linus Torvalds wrote: > > On Mon, Mar 1, 2021 at 12:35 AM Sedat Dilek wrote: > > > > I wondered why there was approx. for 6 days no commits and got an > > answer from an LWN posting "5.12 Merge window delayed". > > Unsure, if there was a posting to LKML? > > There was no posting to lkml because lkml doesn't take html emails, > and I only had mobile data (and not even that for the first 24 hours > or so - even cell towers were down). > > I did send updates to several top-level maintainers and to the > us...@kernel.org mailing list, so a lot of people knew about it, but > they in turn probably only ended up mentioning it on a need-to-know > basis. As you mention, LWN did have a mention of it, but you'd have to > find it. > > In normal times I would have just taken a laptop to the nearest > Starbucks and worked that way, but not in the pandemic. Plus the local > highway was actually shut down for three days because of downed trees > on the road (this was not a Texas-style electricity generation problem > - it was literally thousands of trees falling all over. We had one > miss our house by a couple of meters). > > Two weeks later, and the roadways are still littered with trees and > tons of branches everywhere you drive. > > And I didn't have a generator because our local power lines are > actually buried, and we very seldom lose electricity. But when all the > feeder lines are down because trees fell over, and it takes a week > first for the tree crews to clear the roads and then the electric > crews to replace literally miles of electric cable, it doesn't really > help all that much that the local lines are buried and all in good > working order ;) > > > Anyway, if you are not able to make your work someone else should jump > > in like Greg did once. > > It was an option, it didn't seem worth it. > > And part of _that_ was that it looked like "ok, a couple of days", and > then it just kept being "one more day" for several days. > > A lot of people lost power for just a day or two. > > The area I live in probably wasn't a huge priority, because it's > somewhat sparsely populated, and nice and wooded. > > Which is really nice most of the time. It's not quite so nice when you > can hear the trees keep falling around you, and you know you have a > few really big ones right next to the house.. ;^p > Based on / Freely adapted from Goethe: I answer just when it suits me! I can hardly imagine your feelings and/or emotions as I was NOT in such a situation. I remember "Blackout Münsterland - Münsterländer Schneechaos 2005" [1] seen on German TV. 150km (approx. 92 miles) from my new home-town. To make a story short: Be proud you made a merge-window happen in real 14 -6 = 8 days. That is amazing, really! There exist emergency plans - especially for pandemic situations - here in Germany. For me it looks like no one cares - including the responsibles. Exceptional circumstances or you might say "CHAOS". Sometimes having no plan is good - but never forget your focus or targets. I wanted to hear from you: Next time in such an exceptional situation I/we will do ... And hey yah: Linux v5.12-rc2 on a Saturday Morning @ 06-Mar-2021. Congrats! - Sedat - [1] https://www.youtube.com/watch?v=jfKeGHqrip8
[PATCH] x86/smpboot: remove duplicate include in smpboot.c
From: Zhang Yunkai 'cpu_device_id.h' and 'intel_family.h' included in 'smpboot.c' is duplicated. It is also included in the 80th line. Signed-off-by: Zhang Yunkai --- arch/x86/kernel/smpboot.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c index 02813a7f3a7c..ec4bf691fe28 100644 --- a/arch/x86/kernel/smpboot.c +++ b/arch/x86/kernel/smpboot.c @@ -1865,9 +1865,6 @@ static bool slv_set_max_freq_ratio(u64 *base_freq, u64 *turbo_freq) return true; } -#include -#include - #define X86_MATCH(model) \ X86_MATCH_VENDOR_FAM_MODEL_FEATURE(INTEL, 6,\ INTEL_FAM6_##model, X86_FEATURE_APERFMPERF, NULL) -- 2.25.1
Reply: Re: [PATCH v5] drm/loongson: Add DRM Driver for Loongson 7A1000 bridge chip
+void ls7a_mm_wreg_locked(struct loongson_device *ldev, u32 offset,
u32 val)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(ldev-mmio_lock, flags);
+ writel(val, ldev-mmio + offset);
+ spin_unlock_irqrestore(ldev-mmio_lock, flags);
+}
Why lock and disable irq? To workaround the hw issue from the first
revision of LS7A? If so, I suggest to remove the workaround. Because:
1, mmio r/w will be used in irq context; 2, newer revision of LS7A
doesn't need workaround.
Yes,the lock is to workaround the hw issue,I have decided to remove the lock.
+
+ /* DC IO */
+ ldev-io = (void *)TO_UNCAC(LS7A_CHIPCFG_REG_BASE);
TO_UNCAC() is a MIPS-specific macro, I think ioremap() is better.
OK.I have switched to ioremap, and the test passed.
+#define LS7A_CHIPCFG_REG_BASE (0x1001)
+#define PCI_DEVICE_ID_LOONGSON_DC 0x7a06
+#define PCI_DEVICE_ID_LOONGSON_GPU 0x7a15
They are already defined in include/linux/pci_ids.h.
In include/linux/pci_ids.h only defined PCI_VENDOR_ID_LOONGSON.
--
Loongson LiChenyang
Re: [xhci] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
On Fri, Mar 5, 2021 at 8:54 PM Sedat Dilek wrote: > > On Fri, Mar 5, 2021 at 8:47 PM Alan Stern wrote: > > > > On Fri, Mar 05, 2021 at 08:41:40PM +0100, Sedat Dilek wrote: > > > On Fri, Mar 5, 2021 at 8:30 PM Alan Stern > > > wrote: > > > > > > Okay, that indicates the ATA commands are being sent not by the kernel > > > > but by some program. I'm not sure how you can easily find out which > > > > program; probably the best thing to do is turn them off one by one until > > > > you find the one responsible. > > > > > > > > > > I can hardly imagine which user-space tools other than powertop can > > > interfere here. > > > Any ideas? > > > > No. Especially since I have no idea what programs are running on your > > computer. > > > > Are we talking about things like gvfs - udisks - fuse etc.? > All running via systemd here. > > Here I am using KDE/Plasma as DE. > Unsure if this runs apps in the background. > > AFAICS I have not seen xhci-resets with Debian-Kernel 5.10.19-1. > No, with Debian-Kernel 5.10.19-1 there are no xhci-resets: root# cat /proc/version Linux version 5.10.0-4-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.19-1 (2021-03-02) root# LC_ALL=C dmesg -T | grep xhci | grep reset [ empty ] But I see there is already a quirk enabled and matches my ASmedia USB 3.0 controller (as I have *no* usb-storage-quirks enabled): root# LC_ALL=C dmesg -T | grep -i quirks | egrep '174c|55aa' [Sat Mar 6 06:52:41 2021] usb-storage 4-1:1.0: Quirks match for vid 174c pid 55aa: 40 For the sake of completeness my latest /etc/modules-load.d/usb-storage.conf: # Add quirks for USB Mass Storage devices # # Link: https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html # # usb-storage quirks kernel-parameters and options explained: # [1] Usage: usb-storage.quirks= # [2] VendorID (VID) and ProductID (PID): # ASMedia M1042 USB-3.0 controller: VID: 174c PID: 55aa # [3] Flags: # t = NO_ATA_1X (don't allow ATA(12) and ATA(16) commands, uas only); # u = IGNORE_UAS (don't bind to the uas driver); # [4] Example: usb-storage.quirks=174c:55aa:t # # DEBUG: echo '174c:55aa:t' > /sys/module/usb_storage/parameters/quirks # # XXX: Commented - xhci-resets NOT caused by the Linux-kernel (check user-space) #options usb-storage quirks=174c:55aa:t - EOF - Thanks Alan for all the hints and tips in the topic "usb-storage and quirks" and your patience. - Sedat -
Re: [RFC] scripts: kernel-doc: fix attribute capture in function parsing
On Fri, Mar 5, 2021 at 8:38 PM Aditya wrote:
>
> On 6/3/21 12:13 am, Matthew Wilcox wrote:
> > On Fri, Mar 05, 2021 at 11:50:00PM +0530, Aditya Srivastava wrote:
> >> Provide a simple fix by adding "__attribute_const__" in the corresponding
> >> regex expression.
> >>
> >> A quick evaluation by running 'kernel-doc -none' on kernel-tree reveals
> >> that no additional warning or error has been added or removed by the fix.
> >
> > I'm no perlmonger, but why isn't this simply:
> >
> > +++ b/scripts/kernel-doc
> > @@ -1753,6 +1753,7 @@ sub dump_function($$) {
> > $prototype =~ s/^__inline +//;
> > $prototype =~ s/^__always_inline +//;
> > $prototype =~ s/^noinline +//;
> > +$prototype =~ s/__attribute_const__ +//;
> > $prototype =~ s/__init +//;
> > $prototype =~ s/__init_or_module +//;
> > $prototype =~ s/__meminit +//;
> >
> > (completely untested)
> >
> >> +++ b/scripts/kernel-doc
> >> @@ -1753,6 +1753,7 @@ sub dump_function($$) {
> >> my $prototype = shift;
> >> my $file = shift;
> >> my $noret = 0;
> >> +my $attribute_const = qr{__attribute_const__};
> >>
> >> print_lineno($new_start_line);
> >>
> >> @@ -1808,7 +1809,7 @@ sub dump_function($$) {
> >> $prototype =~ m/^(\w+)\s+([a-zA-Z0-9_~:]+)\s*\(([^\(]*)\)/ ||
> >> $prototype =~ m/^(\w+\s*\*+)\s*([a-zA-Z0-9_~:]+)\s*\(([^\(]*)\)/ ||
> >> $prototype =~ m/^(\w+\s+\w+)\s+([a-zA-Z0-9_~:]+)\s*\(([^\(]*)\)/ ||
> >> -$prototype =~
> >> m/^(\w+\s+\w+\s*\*+)\s*([a-zA-Z0-9_~:]+)\s*\(([^\(]*)\)/ ||
> >> +$prototype =~
> >> m/^(\w+\s+\w+\s*\*+$attribute_const?)\s*([a-zA-Z0-9_~:]+)\s*\(([^\(]*)\)/
> >> ||
> >> $prototype =~
> >> m/^(\w+\s+\w+\s+\w+)\s+([a-zA-Z0-9_~:]+)\s*\(([^\(]*)\)/ ||
> >> $prototype =~
> >> m/^(\w+\s+\w+\s+\w+\s*\*+)\s*([a-zA-Z0-9_~:]+)\s*\(([^\(]*)\)/ ||
> >> $prototype =~ m/^()([a-zA-Z0-9_~:]+)\s*\(([^\{]*)\)/ ||
>
> Hi Matthew
> You are correct, it should be placed there. I was considering it as a
> return type instead.
> I'll send a modified v2 with the changes.
>
Aditya, I also ran:
git ls-files | xargs ./scripts/kernel-doc -none 2>&1 | tee kernel-doc-output
cat kernel-doc-output | grep "cannot understand function prototype:" |
sed 's/[^:].*:[0-9]*: \(.*\)$/\1/' | sort
and I found another instance of failed parsing function prototypes in
mm/percpu.c:2671:
struct pcpu_alloc_info * __flatten pcpu_build_alloc_info(size_t
reserved_size, size_t dyn_size, size_t atom_size,
pcpu_fc_cpu_distance_fn_t cpu_distance_fn)
Could you address that one in your patch as well?
Lukas
[PATCH] Staging: android: ashmem: fixed a struct without const
Fixed a struct without const
Signed-off-by: nabil5352
---
drivers/staging/android/ashmem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/android/ashmem.c b/drivers/staging/android/ashmem.c
index d66a64e42273..7854fd410efa 100644
--- a/drivers/staging/android/ashmem.c
+++ b/drivers/staging/android/ashmem.c
@@ -376,7 +376,7 @@ ashmem_vmfile_get_unmapped_area(struct file *file, unsigned
long addr,
static int ashmem_mmap(struct file *file, struct vm_area_struct *vma)
{
- static struct file_operations vmfile_fops;
+ static const struct file_operations vmfile_fops;
struct ashmem_area *asma = file->private_data;
int ret = 0;
--
2.25.1
Re: [PATCH 5.10 000/102] 5.10.21-rc1 review
On 2021/3/5 20:20, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 5.10.21 release. There are 102 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun, 07 Mar 2021 12:08:39 +. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.21-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y and the diffstat can be found below. thanks, greg k-h Our test CI monitored the 5.10.21-rc1, and compile failure on arm64: Kernel repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Branch: linux-5.10.y Arch: arm64/x86 Version: 5.10.21-rc1+ Commit: 80aaabbaf433294d1f075981fa3785d7f4b55159 Compiler: gcc version 7.3.0 (GCC) arm64 (compile failure) Kernel build failed, error log: kernel/rcu/tree.c:683:2: error: implicit declaration of function ‘IRQ_WORK_INIT’; did you mean ‘QSTR_INIT’? [-Werror=implicit-function-declaration] IRQ_WORK_INIT(late_wakeup_func); ^ QSTR_INIT kernel/rcu/tree.c:683:2: error: invalid initializer x86 (No kernel failures) Testcase Result Summary: total_num: 4716 succeed_num: 4714 failed_num: 2 timeout_num: 0 Tested-by: Hulk Robot
Re: [RFC v3] scripts: kernel-doc: fix typedef support for struct/union parsing
On Sat, Mar 6, 2021 at 5:35 AM Matthew Wilcox wrote:
>
> On Thu, Feb 25, 2021 at 08:20:33PM +0530, Aditya Srivastava wrote:
> > +++ b/scripts/kernel-doc
> > @@ -1201,12 +1201,23 @@ sub dump_union($$) {
> > sub dump_struct($$) {
> > my $x = shift;
> > my $file = shift;
> > +my $decl_type;
> > +my $members;
> > +my $type = qr{struct|union};
> > +# For capturing struct/union definition body, i.e.
> > "{members*}qualifiers*"
> > +my $definition_body =
> > qr{\{(.*)\}(?:\s*(?:__packed|__aligned|cacheline_aligned_in_smp|cacheline_aligned|__attribute__\s*\(\([a-z0-9,_\s\(\)]*\)\)))*};
> > -if ($x =~
> > /(struct|union)\s+(\w+)\s*\{(.*)\}(\s*(__packed|__aligned|cacheline_aligned_in_smp|cacheline_aligned|__attribute__\s*\(\([a-z0-9,_\s\(\)]*\)\)))*/)
> > {
> > - my $decl_type = $1;
> > +if ($x =~ /($type)\s+(\w+)\s*$definition_body/) {
> > + $decl_type = $1;
> > $declaration_name = $2;
> > - my $members = $3;
> > + $members = $3;
> > +} elsif ($x =~ /typedef\s+($type)\s*$definition_body\s*(\w+)\s*;/) {
> > + $decl_type = $1;
> > + $declaration_name = $3;
> > + $members = $2;
> > +}
>
> In the same spirit as dump_function, would something like this work?
>
I agree. That might be a suitable clean-up to keep the code for
functions and struct/union parsing similar in style/spirit.
Aditya, would you like to create a patch for that?
Lukas
An Update on Your Card Delivery
Hello, This is to officially inform you that (ATM Card number:5199 1107 2037 2066) has been accredited in your favor. Your Personal Identification Number is 5199. The ATM Card Value is US$10,000,000.00.You are advised to contact me with the following information: Name, Address,Mobile No, Age and Occupation Thank You. Send all information directly to my Private E-mail: drjohninfo342...@gmail.com Thank you God Blessed, DR JOHN OBU CHAIRMAN PAYMENT APPROVAL FROM OFFICE OF THE PRESIDENT AND INTERNATIONAL REMITTANCE DEPARTMENT
Re: [PATCH 6/6] firmware: qcom_scm: Only compile legacy calls on ARM
Quoting Elliot Berman (2021-03-05 10:18:09)
> On 3/3/2021 10:14 PM, Stephen Boyd wrote:
> > Quoting Elliot Berman (2021-03-03 19:35:08)
> >>
> >> On 2/23/2021 1:45 PM, Stephen Boyd wrote:
> >>> These scm calls are never used outside of legacy ARMv7 based platforms.
> >>> That's because PSCI, mandated on arm64, implements them for modern SoCs
> >>> via the PSCI spec. Let's move them to the legacy file and only compile
> >>> the legacy file into the kernel when CONFIG_ARM=y. Otherwise provide
> >>> stubs and fail the calls. This saves a little bit of space in an
> >>> arm64 allmodconfig >
> >>>$ ./scripts/bloat-o-meter vmlinux.before vmlinux.after
> >>>add/remove: 0/8 grow/shrink: 5/7 up/down: 509/-4405 (-3896)
> >>>Function old new delta
> >>>__qcom_scm_set_dload_mode.constprop 312 452+140
> >>>qcom_scm_qsmmu500_wait_safe_toggle 288 416+128
> >>>qcom_scm_io_writel 288 408+120
> >>>qcom_scm_io_readl376 492+116
> >>>__param_str_download_mode 23 28 +5
> >>>__warned43274326 -1
> >>>qcom_iommu_init 272 268 -4
> >>>e843419@0b3f_00010432_324 8 - -8
> >>>qcom_scm_call228 208 -20
> >>>CSWTCH 59255877 -48
> >>>_sub_I_65535_1163100 163040 -60
> >>>_sub_D_65535_0163100 163040 -60
> >>>qcom_scm_wb 64 - -64
> >>>qcom_scm_lock320 160-160
> >>>qcom_scm_call_atomic 212 --212
> >>>qcom_scm_cpu_power_down 308 --308
> >>>scm_legacy_call_atomic 520 --520
> >>>qcom_scm_set_warm_boot_addr 720 --720
> >>>qcom_scm_set_cold_boot_addr 728 --728
> >>>scm_legacy_call 1492 - -1492
> >>>Total: Before=66737642, After=66733746, chg -0.01%
> >>>
> >>> Commit 9a434cee773a ("firmware: qcom_scm: Dynamically support SMCCC and
> >>> legacy conventions") didn't mention any motivating factors for keeping
> >>> the legacy code around on arm64 kernels, i.e. presumably that commit
> >>> wasn't trying to support these legacy APIs on arm64 kernels.
> >>
> >> There are arm targets which support SMCCC convention and use some of
> >> these removed functions. Can these functions be kept in qcom-scm.c and
> >> wrapped with #if IS_ENABLED(CONFIG_ARM)?
> >>
> >
> > It can be wrapped in qcom-scm.c, but why? It's all the same object file
> > so I'm lost why it matters. I suppose it would make it so the struct
> > doesn't have to be moved around and declared in the header? Any other
> > reason? I moved it to the legacy file so that it was very obvious that
> > the API wasn't to be used except for "legacy" platforms that don't use
> > PSCI.
> >
>
> There are "legacy" arm platforms that use the SMCCC (scm_smc_call) and
> use the qcom_scm_set_{warm,cold}_boot_addr and qcom_scm_cpu_power_down
> functions.
Ah ok. Weird, but I get it. Amazing that SMCCC was adopted there but
PSCI wasn't!
>
> > +desc.args[0] = flags;
> > +desc.args[1] = virt_to_phys(entry);
> > +
> > +return scm_legacy_call_atomic(NULL, , NULL);
> > +}
> > +EXPORT_SYMBOL(qcom_scm_set_cold_boot_addr);
>
> This should still be qcom_scm_call.
You mean s/scm_legacy_call_atomic/qcom_scm_call/ right?
I don't really want to resend the rest of the patches if this last one
is the only one that needs an update. This was a semi-RFC anyway so
maybe it's fine if the first 5 patches get merged and then I can resend
this one? Otherwise I will resend this again next week or so with less
diff for this patch.
[PATCH 2/2] kbuild: move $(strip ) to suffix-search definition
Move $(strip ...) to the callee from the callers of suffix-search. It shortens the code slightly. Adding a space after a comma will not be a matter. I also dropped parentheses from single character variables. Signed-off-by: Masahiro Yamada --- scripts/Makefile.lib | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index e60be0bddda2..4c0f952da84f 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -45,16 +45,16 @@ obj-y := $(filter-out %/, $(obj-y)) endif # Expand $(foo-objs) $(foo-y) by calling $(call suffix-search,foo.o,-objs -y) -suffix-search = $(foreach s,$(2),$($(1:.o=$s))) +suffix-search = $(strip $(foreach s, $2, $($(1:.o=$s # If $(foo-objs), $(foo-y), $(foo-m), or $(foo-) exists, foo.o is a composite object -multi-search = $(sort $(foreach m,$(1), $(if $(strip $(call suffix-search,$(m),$(2) -)), $(m +multi-search = $(sort $(foreach m, $1, $(if $(call suffix-search, $m, $2 -), $m))) multi-obj-y := $(call multi-search,$(obj-y),-objs -y) multi-obj-m := $(call multi-search,$(obj-m),-objs -y -m) multi-obj-ym := $(multi-obj-y) $(multi-obj-m) # Replace multi-part objects by their individual parts, # including built-in.a from subdirectories -real-search = $(foreach m,$(1), $(if $(strip $(call suffix-search,$(m),$(2) -)),$(call suffix-search,$(m),$(2)),$(m))) +real-search = $(foreach m, $1, $(if $(call suffix-search, $m, $2 -), $(call suffix-search, $m, $2), $m)) real-obj-y := $(call real-search, $(obj-y),-objs -y) real-obj-m := $(call real-search, $(obj-m),-objs -y -m) -- 2.27.0
[PATCH 1/2] kbuild: rename multi-used-* to multi-obj-*
I think multi-obj-* is clearer, and more consisten with real-obj-*. Rename as follows: multi-used-y -> multi-obj-y multi-used-m -> multi-obj-m multi-used-> multi-obj-ym Signed-off-by: Masahiro Yamada --- scripts/Makefile.build | 6 +++--- scripts/Makefile.lib | 10 +- 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/scripts/Makefile.build b/scripts/Makefile.build index 1b6094a13034..56cf8eb475cf 100644 --- a/scripts/Makefile.build +++ b/scripts/Makefile.build @@ -444,11 +444,11 @@ quiet_cmd_link_multi-m = LD [M] $@ cmd_link_multi-m = $(LD) $(ld_flags) -r -o $@ $(filter %.o,$^) endif -$(multi-used-m): FORCE +$(multi-obj-m): FORCE $(call if_changed,link_multi-m) -$(call multi_depend, $(multi-used-m), .o, -objs -y -m) +$(call multi_depend, $(multi-obj-m), .o, -objs -y -m) -targets += $(multi-used-m) +targets += $(multi-obj-m) targets := $(filter-out $(PHONY), $(targets)) # Add intermediate targets: diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index eee59184de64..e60be0bddda2 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -48,9 +48,9 @@ endif suffix-search = $(foreach s,$(2),$($(1:.o=$s))) # If $(foo-objs), $(foo-y), $(foo-m), or $(foo-) exists, foo.o is a composite object multi-search = $(sort $(foreach m,$(1), $(if $(strip $(call suffix-search,$(m),$(2) -)), $(m -multi-used-y := $(call multi-search,$(obj-y),-objs -y) -multi-used-m := $(call multi-search,$(obj-m),-objs -y -m) -multi-used := $(multi-used-y) $(multi-used-m) +multi-obj-y := $(call multi-search,$(obj-y),-objs -y) +multi-obj-m := $(call multi-search,$(obj-m),-objs -y -m) +multi-obj-ym := $(multi-obj-y) $(multi-obj-m) # Replace multi-part objects by their individual parts, # including built-in.a from subdirectories @@ -92,12 +92,12 @@ obj-m := $(addprefix $(obj)/,$(obj-m)) lib-y := $(addprefix $(obj)/,$(lib-y)) real-obj-y := $(addprefix $(obj)/,$(real-obj-y)) real-obj-m := $(addprefix $(obj)/,$(real-obj-m)) -multi-used-m := $(addprefix $(obj)/,$(multi-used-m)) +multi-obj-m:= $(addprefix $(obj)/, $(multi-obj-m)) subdir-ym := $(addprefix $(obj)/,$(subdir-ym)) # Finds the multi-part object the current object will be linked into. # If the object belongs to two or more multi-part objects, list them all. -modname-multi = $(sort $(foreach m,$(multi-used),\ +modname-multi = $(sort $(foreach m,$(multi-obj-ym),\ $(if $(filter $*.o, $($(m:.o=-objs)) $($(m:.o=-y)) $($(m:.o=-m))),$(m:.o= __modname = $(if $(modname-multi),$(modname-multi),$(basetarget)) -- 2.27.0
Re: [PATCH V9 2/4] kbuild: Add generic rule to apply fdtoverlay
On Wed, Mar 3, 2021 at 1:36 PM Viresh Kumar wrote: > > From: Rob Herring > > Add a generic rule to apply fdtoverlay in Makefile.lib, so every > platform doesn't need to carry the complex rule. > > The platform's Makefile only needs to have this now: > > DTC_FLAGS_foo_base += -@ > foo-dtbs := foo_base.dtb foo_overlay1.dtbo foo_overlay2.dtbo > dtb-y := foo.dtb > > We don't want to run schema checks on foo.dtb (as foo.dts doesn't exist) > and the Makefile is updated accordingly. > > Signed-off-by: Rob Herring > Co-developed-by: Viresh Kumar > Signed-off-by: Viresh Kumar > --- > scripts/Makefile.lib | 24 ++-- > 1 file changed, 22 insertions(+), 2 deletions(-) > > diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib > index a2658242d956..c430fbb36763 100644 > --- a/scripts/Makefile.lib > +++ b/scripts/Makefile.lib > @@ -58,6 +58,10 @@ real-search = $(foreach m,$(1), $(if $(strip $(call > suffix-search,$(m),$(2) -)), > real-obj-y := $(call real-search, $(obj-y),-objs -y) > real-obj-m := $(call real-search, $(obj-m),-objs -y -m) > > +# List all dtbs to be generated by fdtoverlay > +overlay-y := $(foreach m,$(dtb-y), $(if $(strip $($(m:.dtb=-dtbs))),$(m),)) > +overlay-$(CONFIG_OF_ALL_DTBS) += $(foreach m,$(dtb-), $(if $(strip > $($(m:.dtb=-dtbs))),$(m),)) This does not benefit from 1/4. Squashing the following will shorten the code. diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index e12633f4057d..44a1652ddcd7 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -58,10 +58,6 @@ real-search = $(foreach m,$(1), $(if $(strip $(call suffix-search,$(m),$(2) -)), real-obj-y := $(call real-search, $(obj-y),-objs -y) real-obj-m := $(call real-search, $(obj-m),-objs -y -m) -# List all dtbs to be generated by fdtoverlay -overlay-y := $(foreach m,$(dtb-y), $(if $(strip $($(m:.dtb=-dtbs))),$(m),)) -overlay-$(CONFIG_OF_ALL_DTBS) += $(foreach m,$(dtb-), $(if $(strip $($(m:.dtb=-dtbs))),$(m),)) - always-y += $(always-m) # hostprogs-always-y += foo @@ -75,13 +71,16 @@ always-y += $(hostprogs-always-y) $(hostprogs-always-m) userprogs += $(userprogs-always-y) $(userprogs-always-m) always-y += $(userprogs-always-y) $(userprogs-always-m) +# If CONFIG_OF_ALL_DTBS is enabled, all DT blobs are built +dtb-$(CONFIG_OF_ALL_DTBS) += $(dtb-) + +# List all dtbs to be generated by fdtoverlay +overlay-y := $(foreach m,$(dtb-y), $(if $(strip $($(m:.dtb=-dtbs))),$(m),)) + # DTB # Add base dtb and overlay dtbo dtb-y += $(foreach m,$(overlay-y), $($(m:.dtb=-dtbs))) -# If CONFIG_OF_ALL_DTBS is enabled, all DT blobs are built -dtb-$(CONFIG_OF_ALL_DTBS) += $(dtb-) - always-y += $(dtb-y) ifneq ($(CHECK_DTBS),) -- Best Regards Masahiro Yamada
Re: [External] Re: [PATCH v2 2/5] mm: memcontrol: make page_memcg{_rcu} only applicable for non-kmem page
On Sat, Mar 6, 2021 at 3:00 AM Roman Gushchin wrote:
>
> On Wed, Mar 03, 2021 at 01:59:14PM +0800, Muchun Song wrote:
> > We want to reuse the obj_cgroup APIs to charge the kmem pages when
> > If we do that, we should store an object cgroup pointer to
> > page->memcg_data for the kmem pages.
> >
> > Finally, page->memcg_data can have 3 different meanings.
> >
> > 1) For the slab pages, page->memcg_data points to an object cgroups
> > vector.
> >
> > 2) For the kmem pages (exclude the slab pages), page->memcg_data
> > points to an object cgroup.
> >
> > 3) For the user pages (e.g. the LRU pages), page->memcg_data points
> > to a memory cgroup.
> >
> > Currently we always get the memory cgroup associated with a page via
> > page_memcg() or page_memcg_rcu(). page_memcg_check() is special, it
> > has to be used in cases when it's not known if a page has an
> > associated memory cgroup pointer or an object cgroups vector. Because
> > the page->memcg_data of the kmem page is not pointing to a memory
> > cgroup in the later patch, the page_memcg() and page_memcg_rcu()
> > cannot be applicable for the kmem pages. In this patch, make
> > page_memcg() and page_memcg_rcu() no longer apply to the kmem pages.
> > We do not change the behavior of the page_memcg_check(), it is also
> > applicable for the kmem pages.
> >
> > In the end, there are 3 helpers to get the memcg associated with a page.
> > Usage is as follows.
> >
> > 1) Get the memory cgroup associated with a non-kmem page (e.g. the LRU
> > pages).
> >
> > - page_memcg()
> > - page_memcg_rcu()
> >
> > 2) Get the memory cgroup associated with a page. It has to be used in
> > cases when it's not known if a page has an associated memory cgroup
> > pointer or an object cgroups vector. Returns NULL for slab pages or
> > uncharged pages. Otherwise, returns memory cgroup for charged pages
> > (e.g. the kmem pages, the LRU pages).
> >
> > - page_memcg_check()
> >
> > In some place, we use page_memcg() to check whether the page is charged.
> > Now introduce page_memcg_charged() helper to do that.
> >
> > This is a preparation for reparenting the kmem pages.
> >
> > Signed-off-by: Muchun Song
>
> This patch also looks good to me, but, please, make it safe for adding
> new memcg_data flags. E.g. if someone will add a new flag with a completely
> new meaning, it shouldn't break the code.
I'm not thoughtful enough. Will do that in the next version.
Thanks for your suggestions.
>
> I'll ack it after another look at the final version, but overall it
> looks good.
>
> Thanks!
>
> > ---
> > include/linux/memcontrol.h | 36
> > mm/memcontrol.c| 23 +--
> > mm/page_alloc.c| 4 ++--
> > 3 files changed, 43 insertions(+), 20 deletions(-)
> >
> > diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> > index e6dc793d587d..049b80246cbf 100644
> > --- a/include/linux/memcontrol.h
> > +++ b/include/linux/memcontrol.h
> > @@ -358,14 +358,26 @@ enum page_memcg_data_flags {
> >
> > #define MEMCG_DATA_FLAGS_MASK (__NR_MEMCG_DATA_FLAGS - 1)
> >
> > +/* Return true for charged page, otherwise false. */
> > +static inline bool page_memcg_charged(struct page *page)
> > +{
> > + unsigned long memcg_data = page->memcg_data;
> > +
> > + VM_BUG_ON_PAGE(PageSlab(page), page);
> > + VM_BUG_ON_PAGE(memcg_data & MEMCG_DATA_OBJCGS, page);
> > +
> > + return !!memcg_data;
> > +}
> > +
> > /*
> > - * page_memcg - get the memory cgroup associated with a page
> > + * page_memcg - get the memory cgroup associated with a non-kmem page
> > * @page: a pointer to the page struct
> > *
> > * Returns a pointer to the memory cgroup associated with the page,
> > * or NULL. This function assumes that the page is known to have a
> > * proper memory cgroup pointer. It's not safe to call this function
> > - * against some type of pages, e.g. slab pages or ex-slab pages.
> > + * against some type of pages, e.g. slab pages, kmem pages or ex-slab
> > + * pages.
> > *
> > * Any of the following ensures page and memcg binding stability:
> > * - the page lock
> > @@ -378,27 +390,30 @@ static inline struct mem_cgroup *page_memcg(struct
> > page *page)
> > unsigned long memcg_data = page->memcg_data;
> >
> > VM_BUG_ON_PAGE(PageSlab(page), page);
> > - VM_BUG_ON_PAGE(memcg_data & MEMCG_DATA_OBJCGS, page);
> > + VM_BUG_ON_PAGE(memcg_data & MEMCG_DATA_FLAGS_MASK, page);
> >
> > - return (struct mem_cgroup *)(memcg_data & ~MEMCG_DATA_FLAGS_MASK);
> > + return (struct mem_cgroup *)memcg_data;
> > }
> >
> > /*
> > - * page_memcg_rcu - locklessly get the memory cgroup associated with a page
> > + * page_memcg_rcu - locklessly get the memory cgroup associated with a
> > non-kmem page
> > * @page: a pointer to the page struct
> > *
> > * Returns a pointer to the memory cgroup associated with the
Re: [PATCH v3] mm/vmalloc: randomize vmalloc() allocations
On 6.3.2021 3.13, Andrew Morton wrote: On Mon, 15 Feb 2021 22:26:34 +0200 Topi Miettinen wrote: Memory mappings inside kernel allocated with vmalloc() are in predictable order and packed tightly toward the low addresses, except for per-cpu areas which start from top of the vmalloc area. With new kernel boot parameter 'randomize_vmalloc=1', the entire area is used randomly to make the allocations less predictable and harder to guess for attackers. Also module and BPF code locations get randomized (within their dedicated and rather small area though) and if CONFIG_VMAP_STACK is enabled, also kernel thread stack locations. On 32 bit systems this may cause problems due to increased VM fragmentation if the address space gets crowded. On all systems, it will reduce performance and increase memory and cache usage due to less efficient use of page tables and inability to merge adjacent VMAs with compatible attributes. On x86_64 with 5 level page tables, in the worst case, additional page table entries of up to 4 pages are created for each mapping, so with small mappings there's considerable penalty. ... How useful is this expected to be? What sort of attack scenarios will this help to defend against? Since there's a clear trade-off between best performance and additional address space randomization, this will not be useful for those who prefer performance. That's also why this is not the default but has to be enabled with a boot parameter. For those who are willing to pay the price for additional hardening, the purpose is to make attacks against KASLR (similar to TagBleed [1]) more difficult since the targeted memory locations may reside anywhere in the 32 TB vmalloc region and knowing one address does not reveal the others. [1] https://download.vusec.net/papers/tagbleed_eurosp20.pdf -Topi
[PATCH 1/1] RISC-V: correct enum sbi_ext_rfence_fid
The constants in enum sbi_ext_rfence_fid should match the SBI
specification. See
https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc#78-function-listing
| Function Name | FID | EID
| sbi_remote_fence_i | 0 | 0x52464E43
| sbi_remote_sfence_vma | 1 | 0x52464E43
| sbi_remote_sfence_vma_asid | 2 | 0x52464E43
| sbi_remote_hfence_gvma_vmid | 3 | 0x52464E43
| sbi_remote_hfence_gvma | 4 | 0x52464E43
| sbi_remote_hfence_vvma_asid | 5 | 0x52464E43
| sbi_remote_hfence_vvma | 6 | 0x52464E43
Fixes: ecbacc2a3efd ("RISC-V: Add SBI v0.2 extension definitions")
Reported-by: Sean Anderson
Signed-off-by: Heinrich Schuchardt
---
arch/riscv/include/asm/sbi.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/riscv/include/asm/sbi.h b/arch/riscv/include/asm/sbi.h
index 99895d9c3bdd..d7027411dde8 100644
--- a/arch/riscv/include/asm/sbi.h
+++ b/arch/riscv/include/asm/sbi.h
@@ -51,10 +51,10 @@ enum sbi_ext_rfence_fid {
SBI_EXT_RFENCE_REMOTE_FENCE_I = 0,
SBI_EXT_RFENCE_REMOTE_SFENCE_VMA,
SBI_EXT_RFENCE_REMOTE_SFENCE_VMA_ASID,
- SBI_EXT_RFENCE_REMOTE_HFENCE_GVMA,
SBI_EXT_RFENCE_REMOTE_HFENCE_GVMA_VMID,
- SBI_EXT_RFENCE_REMOTE_HFENCE_VVMA,
+ SBI_EXT_RFENCE_REMOTE_HFENCE_GVMA,
SBI_EXT_RFENCE_REMOTE_HFENCE_VVMA_ASID,
+ SBI_EXT_RFENCE_REMOTE_HFENCE_VVMA,
};
enum sbi_ext_hsm_fid {
--
2.30.1
Re: [PATCH 5.10 000/102] 5.10.21-rc1 review
On 3/5/2021 4:20 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 5.10.21 release. > There are 102 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun, 07 Mar 2021 12:08:39 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.21-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.10.y > and the diffstat can be found below. > > thanks, On ARCH_BRCMSTB, using 32-bit and 64-bit ARM kernels: Tested-by: Florian Fainelli -- Florian
Re: [External] Re: [PATCH v2 1/5] mm: memcontrol: introduce obj_cgroup_{un}charge_page
On Sat, Mar 6, 2021 at 2:56 AM Roman Gushchin wrote:
>
> On Wed, Mar 03, 2021 at 01:59:13PM +0800, Muchun Song wrote:
> > We know that the unit of slab object charging is bytes, the unit of
> > kmem page charging is PAGE_SIZE. If we want to reuse obj_cgroup APIs
> > to charge the kmem pages, we should pass PAGE_SIZE (as third parameter)
> > to obj_cgroup_charge(). Because the size is already PAGE_SIZE, we can
> > skip touch the objcg stock. And obj_cgroup_{un}charge_page() are
> > introduced to charge in units of page level.
> >
> > In the later patch, we also can reuse those two helpers to charge or
> > uncharge a number of kernel pages to a object cgroup. This is just
> > a code movement without any functional changes.
> >
> > Signed-off-by: Muchun Song
>
> This patch looks good to me, even as a standalone refactoring.
> Please, rename obj_cgroup_charge_page() to obj_cgroup_charge_pages()
> and the same with uncharge. It's because _page suffix usually means
> we're dealing with a physical page (e.g. struct page * as an argument),
> here it's not the case.
Make sense.
>
> Please, add my Acked-by: Roman Gushchin
> after the renaming.
Will do. Thanks for your review.
>
> Thank you!
>
> > ---
> > mm/memcontrol.c | 46 +++---
> > 1 file changed, 31 insertions(+), 15 deletions(-)
> >
> > diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> > index 845eec01ef9d..faae16def127 100644
> > --- a/mm/memcontrol.c
> > +++ b/mm/memcontrol.c
> > @@ -3056,6 +3056,34 @@ static void memcg_free_cache_id(int id)
> > ida_simple_remove(_cache_ida, id);
> > }
> >
> > +static inline void obj_cgroup_uncharge_page(struct obj_cgroup *objcg,
> > + unsigned int nr_pages)
> > +{
> > + rcu_read_lock();
> > + __memcg_kmem_uncharge(obj_cgroup_memcg(objcg), nr_pages);
> > + rcu_read_unlock();
> > +}
> > +
> > +static int obj_cgroup_charge_page(struct obj_cgroup *objcg, gfp_t gfp,
> > + unsigned int nr_pages)
> > +{
> > + struct mem_cgroup *memcg;
> > + int ret;
> > +
> > + rcu_read_lock();
> > +retry:
> > + memcg = obj_cgroup_memcg(objcg);
> > + if (unlikely(!css_tryget(>css)))
> > + goto retry;
> > + rcu_read_unlock();
> > +
> > + ret = __memcg_kmem_charge(memcg, gfp, nr_pages);
> > +
> > + css_put(>css);
> > +
> > + return ret;
> > +}
> > +
> > /**
> > * __memcg_kmem_charge: charge a number of kernel pages to a memcg
> > * @memcg: memory cgroup to charge
> > @@ -3180,11 +3208,8 @@ static void drain_obj_stock(struct memcg_stock_pcp
> > *stock)
> > unsigned int nr_pages = stock->nr_bytes >> PAGE_SHIFT;
> > unsigned int nr_bytes = stock->nr_bytes & (PAGE_SIZE - 1);
> >
> > - if (nr_pages) {
> > - rcu_read_lock();
> > - __memcg_kmem_uncharge(obj_cgroup_memcg(old),
> > nr_pages);
> > - rcu_read_unlock();
> > - }
> > + if (nr_pages)
> > + obj_cgroup_uncharge_page(old, nr_pages);
> >
> > /*
> >* The leftover is flushed to the centralized per-memcg value.
> > @@ -3242,7 +3267,6 @@ static void refill_obj_stock(struct obj_cgroup
> > *objcg, unsigned int nr_bytes)
> >
> > int obj_cgroup_charge(struct obj_cgroup *objcg, gfp_t gfp, size_t size)
> > {
> > - struct mem_cgroup *memcg;
> > unsigned int nr_pages, nr_bytes;
> > int ret;
> >
> > @@ -3259,24 +3283,16 @@ int obj_cgroup_charge(struct obj_cgroup *objcg,
> > gfp_t gfp, size_t size)
> >* refill_obj_stock(), called from this function or
> >* independently later.
> >*/
> > - rcu_read_lock();
> > -retry:
> > - memcg = obj_cgroup_memcg(objcg);
> > - if (unlikely(!css_tryget(>css)))
> > - goto retry;
> > - rcu_read_unlock();
> > -
> > nr_pages = size >> PAGE_SHIFT;
> > nr_bytes = size & (PAGE_SIZE - 1);
> >
> > if (nr_bytes)
> > nr_pages += 1;
> >
> > - ret = __memcg_kmem_charge(memcg, gfp, nr_pages);
> > + ret = obj_cgroup_charge_page(objcg, gfp, nr_pages);
> > if (!ret && nr_bytes)
> > refill_obj_stock(objcg, PAGE_SIZE - nr_bytes);
> >
> > - css_put(>css);
> > return ret;
> > }
> >
> > --
> > 2.11.0
> >
Re: [PATCH 5.4 00/72] 5.4.103-rc1 review
On 3/5/2021 4:21 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 5.4.103 release. > There are 72 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun, 07 Mar 2021 12:08:39 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.103-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.4.y > and the diffstat can be found below. > > thanks, > > greg k-h > On ARCH_BRCMSTB, using 32-bit and 64-bit ARM kernels: Tested-by: Florian Fainelli -- Florian
Re: [PATCH] arch: mips: bcm63xx: Spello fix in the file clk.c
On 3/4/2021 6:05 PM, Bhaskar Chowdhury wrote: > > > s/revelant/relevant/ > > Signed-off-by: Bhaskar Chowdhury Acked-by: Florian Fainelli Previous changes to this file/directory usually used MIPS: BCM63XX: as a subject prefix, maybe Thomas can fix it up while applying for consistency. Thanks -- Florian
Re: [PATCH 4.9 00/41] 4.9.260-rc1 review
On 3/5/2021 4:22 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.260 release. > There are 41 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun, 07 Mar 2021 12:08:39 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.260-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.9.y > and the diffstat can be found below. > > thanks, On ARCH_BRCMSTB, using 32-bit and 64-bit ARM kernels: Tested-by: Florian Fainelli -- Florian
Re: [PATCH RESEND][next] hwmon: (max6621) Fix fall-through warnings for Clang
Hi Guenter, On Fri, Mar 05, 2021 at 07:18:47PM -0800, Guenter Roeck wrote: > On Fri, Mar 05, 2021 at 03:52:58AM -0600, Gustavo A. R. Silva wrote: > > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning > > by explicitly adding a break statement instead of letting the code fall > > through to the next case. > > > > Link: https://github.com/KSPP/linux/issues/115 > > Acked-by: Guenter Roeck > > Signed-off-by: Gustavo A. R. Silva > > --- > > I Acked those, thus assuming that they would be applied through some > other tree. If that is not the case, you'll need to let me know. The > resend only means to me that whatever tree was supposed to pick it up > did not do it, but it doesn't result in any action from my side. This was not directed at you, in particular. I'm resending this for the cosideration of whomever is in charge of this code. If this is not taken or ignored once again, I will consider adding this to my own tree. Thanks -- Gustavo > > drivers/hwmon/max6621.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/hwmon/max6621.c b/drivers/hwmon/max6621.c > > index 367855d5edae..7821132e17fa 100644 > > --- a/drivers/hwmon/max6621.c > > +++ b/drivers/hwmon/max6621.c > > @@ -156,7 +156,7 @@ max6621_is_visible(const void *data, enum > > hwmon_sensor_types type, u32 attr, > > default: > > break; > > } > > - > > + break; > > default: > > break; > > } > > -- > > 2.27.0 > >
RE: [PATCH V3 4/5] dt-bindings: mmc: fsl-imx-esdhc: add clock bindings
> From: Rob Herring > Sent: Friday, March 5, 2021 10:14 PM > > On Fri, Mar 5, 2021 at 8:09 AM Aisheng Dong > wrote: > > > > Hi Rob, > > > > > From: Peng Fan (OSS) > > > Sent: Thursday, February 25, 2021 11:10 AM > > > > > > From: Peng Fan > > > > > > Add clock bindings for fsl-imx-esdhc yaml > > > > > > Signed-off-by: Peng Fan > > > --- > > > .../devicetree/bindings/mmc/fsl-imx-esdhc.yaml| 11 > +++ > > > 1 file changed, 11 insertions(+) > > > > > > diff --git > > > a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml > > > b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml > > > index a7fbd8cc1e38..369471814496 100644 > > > --- a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml > > > +++ b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml > > > @@ -103,6 +103,17 @@ properties: > > >Only eMMC HS400 mode need to take care of this property. > > > default: 0 > > > > > > + clocks: > > > +maxItems: 3 > > > +description: > > > + Handle clocks for the sdhc controller. > > > + > > > + clock-names: > > > +items: > > > + - const: ipg > > > + - const: ahb > > > + - const: per > > > > One question: > > The side effect of this patch is that it imposes a forced order of clk > > names In DT which actually was not needed. > > > > Do we really have to do that? > > Yes. > > > Or any other better approach to allow a random order to match the DT > > usage better? > > Why do you need random order? > Thanks for the feedback. I thought the DT itself supports the random order of strings/names in a property and the OF API in kernel can also handle the random name order properly. That means DT binding don't enforce the order of names when people writing DTS. e.g. Order1: clock-names = "ipg", "per", "ahb" can function the same as: Order2: clock-names = "ipg", "ahb", "per"; However, the schema in this patch enforced the name order which caused dt binding check fail. https://lore.kernel.org/linux-arm-kernel/cal_jsqkaouknvlvu-vnedvg0shxpy56wxhcqv38+ro2k961...@mail.gmail.com/#t And this seems like a common issue in kernel DT because DT supports random name order before. If we have to fix it, should we need fix them all in kernel? And finally, If all the names property are fixed by dt schema definition, the driver may also work without it by using index. > We can not enforce the order, but we only do that when there's multiple > optional entries. Understood, probably this is the simplest way to do a accurate DT schema checking. Regards Aisheng > > Rob
[PATCH v1] checkpatch: exclude four preprocessor sub-expressions from MACRO_ARG_REUSE
__must_be_array, offsetof, sizeof_field and __stringify are all
preprocessor macros and do not evaluate their arguments. As such, it
is safe not to warn when arguments are being reused in those four
sub-expressions.
Exclude those so that they can pass checkpatch.
Signed-off-by: Vincent Mailhol
---
scripts/checkpatch.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index df8b23dc1eb0..25ee4fd5b118 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -5736,7 +5736,7 @@ sub process {
next if ($arg =~ /\.\.\./);
next if ($arg =~ /^type$/i);
my $tmp_stmt = $define_stmt;
- $tmp_stmt =~
s/\b(sizeof|typeof|__typeof__|__builtin\w+|typecheck\s*\(\s*$Type\s*,|\#+)\s*\(*\s*$arg\s*\)*\b//g;
+ $tmp_stmt =~
s/\b(__must_be_array|offsetof|sizeof|sizeof_field|__stringify|typeof|__typeof__|__builtin\w+|typecheck\s*\(\s*$Type\s*,|\#+)\s*\(*\s*$arg\s*\)*\b//g;
$tmp_stmt =~ s/\#+\s*$arg\b//g;
$tmp_stmt =~ s/\b$arg\s*\#\#//g;
my $use_cnt = () = $tmp_stmt =~ /\b$arg\b/g;
--
2.26.2
Re: [RFC PATCH v3 3/3] blk-mq: Lockout tagset iterator when exiting elevator
On 3/5/21 7:14 AM, John Garry wrote:
> diff --git a/block/blk-mq-tag.c b/block/blk-mq-tag.c
> index 7ff1b20d58e7..5950fee490e8 100644
> --- a/block/blk-mq-tag.c
> +++ b/block/blk-mq-tag.c
> @@ -358,11 +358,16 @@ void blk_mq_tagset_busy_iter(struct blk_mq_tag_set
> *tagset,
> {
> int i;
>
> + if (!atomic_inc_not_zero(>iter_usage_counter))
> + return;
> +
> for (i = 0; i < tagset->nr_hw_queues; i++) {
> if (tagset->tags && tagset->tags[i])
> __blk_mq_all_tag_iter(tagset->tags[i], fn, priv,
> BT_TAG_ITER_STARTED);
> }
> +
> + atomic_dec(>iter_usage_counter);
> }
> EXPORT_SYMBOL(blk_mq_tagset_busy_iter);
This changes the behavior of blk_mq_tagset_busy_iter(). What will e.g.
happen if the mtip driver calls blk_mq_tagset_busy_iter(>tags,
mtip_abort_cmd, dd) concurrently with another blk_mq_tagset_busy_iter()
call and if that causes all mtip_abort_cmd() calls to be skipped?
> + while (atomic_cmpxchg(>iter_usage_counter, 1, 0) != 1);
Isn't it recommended to call cpu_relax() inside busy-waiting loops?
> blk_mq_sched_free_requests(q);
> __elevator_exit(q, e);
>
> + atomic_set(>iter_usage_counter, 1);
Can it happen that the above atomic_set() call happens while a
blk_mq_tagset_busy_iter() call is in progress? Should that atomic_set()
call perhaps be changed into an atomic_inc() call?
Thanks,
Bart.
Re: [RFC v3] scripts: kernel-doc: fix typedef support for struct/union parsing
On Thu, Feb 25, 2021 at 08:20:33PM +0530, Aditya Srivastava wrote:
> +++ b/scripts/kernel-doc
> @@ -1201,12 +1201,23 @@ sub dump_union($$) {
> sub dump_struct($$) {
> my $x = shift;
> my $file = shift;
> +my $decl_type;
> +my $members;
> +my $type = qr{struct|union};
> +# For capturing struct/union definition body, i.e.
> "{members*}qualifiers*"
> +my $definition_body =
> qr{\{(.*)\}(?:\s*(?:__packed|__aligned|cacheline_aligned_in_smp|cacheline_aligned|__attribute__\s*\(\([a-z0-9,_\s\(\)]*\)\)))*};
> -if ($x =~
> /(struct|union)\s+(\w+)\s*\{(.*)\}(\s*(__packed|__aligned|cacheline_aligned_in_smp|cacheline_aligned|__attribute__\s*\(\([a-z0-9,_\s\(\)]*\)\)))*/)
> {
> - my $decl_type = $1;
> +if ($x =~ /($type)\s+(\w+)\s*$definition_body/) {
> + $decl_type = $1;
> $declaration_name = $2;
> - my $members = $3;
> + $members = $3;
> +} elsif ($x =~ /typedef\s+($type)\s*$definition_body\s*(\w+)\s*;/) {
> + $decl_type = $1;
> + $declaration_name = $3;
> + $members = $2;
> +}
In the same spirit as dump_function, would something like this work?
-if ($x =~
/(struct|union)\s+(\w+)\s*\{(.*)\}(\s*(__packed|__aligned|cacheline_aligned_in_smp|cacheline_aligned|__attribute__\s*\(\([a-z0-9,_\s\(\)]*\)\)))*/)
{
+$x =~ s/__packed +//;
+$x =~ s/__aligned +//;
+$x =~ s/cacheline_aligned_in_smp +//;
+$x =~ s/cacheline_aligned +//;
+$x =~ s/__attribute__\s*\(\([a-z0-9,_\s\(\)]*\)\)//;
+
+if ($x =~ /(struct|union)\s+(\w+)\s*\{(.*)\}(\s*)*/) {
Re: [RFC PATCH v3 2/3] blk-mq: Freeze and quiesce all queues for tagset in elevator_exit()
On 3/5/21 7:14 AM, John Garry wrote:
> diff --git a/block/blk.h b/block/blk.h
> index 3b53e44b967e..1a948bfd91e4 100644
> --- a/block/blk.h
> +++ b/block/blk.h
> @@ -201,10 +201,29 @@ void elv_unregister_queue(struct request_queue *q);
> static inline void elevator_exit(struct request_queue *q,
> struct elevator_queue *e)
> {
> + struct blk_mq_tag_set *set = q->tag_set;
> + struct request_queue *tmp;
> +
> lockdep_assert_held(>sysfs_lock);
>
> + mutex_lock(>tag_list_lock);
> + list_for_each_entry(tmp, >tag_list, tag_set_list) {
> + if (tmp == q)
> + continue;
> + blk_mq_freeze_queue(tmp);
> + blk_mq_quiesce_queue(tmp);
> + }
> +
> blk_mq_sched_free_requests(q);
> __elevator_exit(q, e);
> +
> + list_for_each_entry(tmp, >tag_list, tag_set_list) {
> + if (tmp == q)
> + continue;
> + blk_mq_unquiesce_queue(tmp);
> + blk_mq_unfreeze_queue(tmp);
> + }
> + mutex_unlock(>tag_list_lock);
> }
This patch introduces nesting of tag_list_lock inside sysfs_lock. The
latter is per request queue while the former can be shared across
multiple request queues. Has it been analyzed whether this is safe?
Thanks,
Bart.
Re: [PATCH net-next v2 3/3] net: phy: broadcom: Allow BCM54210E to configure APD
On 3/4/2021 5:08 PM, Vladimir Oltean wrote: > On Tue, Mar 02, 2021 at 07:37:34PM -0800, Florian Fainelli wrote: >> Took a while but for the 54210E reference board here are the numbers, >> your mileage will vary depending on the supplies, regulator efficiency >> and PCB design around the PHY obviously: >> >> BMCR.PDOWN: 86.12 mW >> auto-power down: 77.84 mW > > Quite curious that the APD power is lower than the normal BMCR.PDOWN > value. As far as my understanding goes, when in APD mode, the PHY even > wakes up from time to time to send pulses to the link partner? Auto-power down kicks in when the cable is disconnected. There is another IDDQ mode that supports energy detection though I am unsure of when it would be useful for most Linux enabled systems. > >> auto-power-down, DLL disabled: 30.83 mW > > The jump from simple APD to APD with DLL disabled is pretty big. > Correct me if I'm wrong, but there's an intermediary step which was not > measured, where the CLK125 is disabled but the internal DLL (Delay > Locked Loop?) is still enabled. I think powering off the internal DLL > also implies powering off the CLK125 pin, at least that's how the PHY > driver treats things at the moment. But we don't know if the huge > reduction in power is due just to CLK125 or the DLL (it's more likely > it's due to both, in equal amounts). Agree, I do not have the break down though. > > Anyway, it's great to have some results which tell us exactly what is > worthwhile and what isn't. In other news, I've added the BCM5464 to the > list of PHYs with APD and I didn't see any issues thus far. > >> IDDQ-low power: 9.85 mW (requires a RESETn toggle) >> IDDQ with soft recovery: 10.75 mW >> >> Interestingly, the 50212E that I am using requires writing the PDOWN bit >> and only that bit (not a RMW) in order to get in a correct state, both >> LEDs keep flashing when that happens, fixes coming. >> >> When net-next opens back up I will submit patches to support IDDQ with >> soft recovery since that is clearly much better than the standard power >> down and it does not require a RESETn toggle. > > Iddq must be the quiescent supply current, isn't it (but in that case, > I'm a bit confused to not see a value in mA)? Is it an actual operating > mode (I don't see anything about that mentioned in the BCM5464 sheet) > and if it is, what is there exactly to support? You would put the PHY in IDDQ with soft recovery (or ultra low power) when you are administratively bringing down the network interface (and its PHY), or when suspending to a low power state where Wake-on-LAN is not enabled. -- Florian
Re: [PATCH] csky: fix typos
Thx,
Looks good to me, Signed-off-by.
On Sat, Mar 6, 2021 at 11:23 AM angkery wrote:
>
> From: Junlin Yang
>
> fixes three typos found by codespell.
>
> Signed-off-by: Junlin Yang
> ---
> arch/csky/include/asm/asid.h| 2 +-
> arch/csky/include/asm/barrier.h | 2 +-
> arch/csky/include/asm/vdso.h| 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/csky/include/asm/asid.h b/arch/csky/include/asm/asid.h
> index ac08b0f..6ff205a 100644
> --- a/arch/csky/include/asm/asid.h
> +++ b/arch/csky/include/asm/asid.h
> @@ -37,7 +37,7 @@ void asid_new_context(struct asid_info *info, atomic64_t
> *pasid,
> * Check the ASID is still valid for the context. If not generate a new ASID.
> *
> * @pasid: Pointer to the current ASID batch
> - * @cpu: current CPU ID. Must have been acquired throught get_cpu()
> + * @cpu: current CPU ID. Must have been acquired through get_cpu()
> */
> static inline void asid_check_context(struct asid_info *info,
> atomic64_t *pasid, unsigned int cpu,
> diff --git a/arch/csky/include/asm/barrier.h b/arch/csky/include/asm/barrier.h
> index 84fc600c..f4045dd 100644
> --- a/arch/csky/include/asm/barrier.h
> +++ b/arch/csky/include/asm/barrier.h
> @@ -64,7 +64,7 @@
>
> /*
> * sync:completion barrier, all sync.xx instructions
> - * guarantee the last response recieved by bus transaction
> + * guarantee the last response received by bus transaction
> * made by ld/st instructions before sync.s
> * sync.s: inherit from sync, but also shareable to other cores
> * sync.i: inherit from sync, but also flush cpu pipeline
> diff --git a/arch/csky/include/asm/vdso.h b/arch/csky/include/asm/vdso.h
> index eb5142f..bdce581 100644
> --- a/arch/csky/include/asm/vdso.h
> +++ b/arch/csky/include/asm/vdso.h
> @@ -16,7 +16,7 @@ struct vdso_data {
> * offset of 0, but since the linker must support setting weak undefined
> * symbols to the absolute address 0 it also happens to support other low
> * addresses even when the code model suggests those low addresses would not
> - * otherwise be availiable.
> + * otherwise be available.
> */
> #define VDSO_SYMBOL(base, name)
> \
> ({
> \
> --
> 1.9.1
>
>
--
Best Regards
Guo Ren
ML: https://lore.kernel.org/linux-csky/
[PATCH v2] erofs: fix bio->bi_max_vecs behavior change
From: Gao Xiang
Martin reported an issue that directory read could be hung on the
latest -rc kernel with some certain image. The root cause is that
commit baa2c7c97153 ("block: set .bi_max_vecs as actual allocated
vector number") changes .bi_max_vecs behavior. bio->bi_max_vecs
is set as actual allocated vector number rather than the requested
number now.
Let's avoid using .bi_max_vecs completely instead.
Reported-by: Martin DEVERA
Signed-off-by: Gao Xiang
---
change since v1:
- since bio->bi_max_vecs doesn't record extent blocks anymore,
introduce a remaining extent block to avoid extent excess.
fs/erofs/data.c | 28 +++-
1 file changed, 11 insertions(+), 17 deletions(-)
diff --git a/fs/erofs/data.c b/fs/erofs/data.c
index f88851c5c250..1249e74b3bf0 100644
--- a/fs/erofs/data.c
+++ b/fs/erofs/data.c
@@ -129,6 +129,7 @@ static inline struct bio *erofs_read_raw_page(struct bio
*bio,
struct page *page,
erofs_off_t *last_block,
unsigned int nblocks,
+ unsigned int *eblks,
bool ra)
{
struct inode *const inode = mapping->host;
@@ -145,8 +146,7 @@ static inline struct bio *erofs_read_raw_page(struct bio
*bio,
/* note that for readpage case, bio also equals to NULL */
if (bio &&
- /* not continuous */
- *last_block + 1 != current_block) {
+ (*last_block + 1 != current_block || !*eblks)) {
submit_bio_retry:
submit_bio(bio);
bio = NULL;
@@ -216,7 +216,8 @@ static inline struct bio *erofs_read_raw_page(struct bio
*bio,
if (nblocks > DIV_ROUND_UP(map.m_plen, PAGE_SIZE))
nblocks = DIV_ROUND_UP(map.m_plen, PAGE_SIZE);
- bio = bio_alloc(GFP_NOIO, bio_max_segs(nblocks));
+ *eblks = bio_max_segs(nblocks);
+ bio = bio_alloc(GFP_NOIO, *eblks);
bio->bi_end_io = erofs_readendio;
bio_set_dev(bio, sb->s_bdev);
@@ -229,16 +230,8 @@ static inline struct bio *erofs_read_raw_page(struct bio
*bio,
/* out of the extent or bio is full */
if (err < PAGE_SIZE)
goto submit_bio_retry;
-
+ --*eblks;
*last_block = current_block;
-
- /* shift in advance in case of it followed by too many gaps */
- if (bio->bi_iter.bi_size >= bio->bi_max_vecs * PAGE_SIZE) {
- /* err should reassign to 0 after submitting */
- err = 0;
- goto submit_bio_out;
- }
-
return bio;
err_out:
@@ -252,7 +245,6 @@ static inline struct bio *erofs_read_raw_page(struct bio
*bio,
/* if updated manually, continuous pages has a gap */
if (bio)
-submit_bio_out:
submit_bio(bio);
return err ? ERR_PTR(err) : NULL;
}
@@ -264,23 +256,26 @@ static inline struct bio *erofs_read_raw_page(struct bio
*bio,
static int erofs_raw_access_readpage(struct file *file, struct page *page)
{
erofs_off_t last_block;
+ unsigned int eblks;
struct bio *bio;
trace_erofs_readpage(page, true);
bio = erofs_read_raw_page(NULL, page->mapping,
- page, _block, 1, false);
+ page, _block, 1, , false);
if (IS_ERR(bio))
return PTR_ERR(bio);
- DBG_BUGON(bio); /* since we have only one bio -- must be NULL */
+ if (bio)
+ submit_bio(bio);
return 0;
}
static void erofs_raw_access_readahead(struct readahead_control *rac)
{
erofs_off_t last_block;
+ unsigned int eblks;
struct bio *bio = NULL;
struct page *page;
@@ -291,7 +286,7 @@ static void erofs_raw_access_readahead(struct
readahead_control *rac)
prefetchw(>flags);
bio = erofs_read_raw_page(bio, rac->mapping, page, _block,
- readahead_count(rac), true);
+ readahead_count(rac), , true);
/* all the page errors are ignored when readahead */
if (IS_ERR(bio)) {
@@ -305,7 +300,6 @@ static void erofs_raw_access_readahead(struct
readahead_control *rac)
put_page(page);
}
- /* the rare case (end in gaps) */
if (bio)
submit_bio(bio);
}
--
2.20.1
Re: [PATCH] arm64: dts: add support for the Pixel 2 XL
On Fri 05 Mar 15:35 CST 2021, Caleb Connolly wrote:
Please add "qcom: " to $subject as well.
> Add a minimal devicetree capable of booting on the Pixel 2 XL MSM8998
> device.
>
> It's currently possible to boot the device into postmarketOS with USB
> networking, however the display panel depends on Display Stream
> Compression which is not yet supported in the kernel.
>
> The bootloader also requires that the dtbo partition contains a device
> tree overlay with a particular id which has to be overlayed onto the
> existing dtb. It's possible to use a specially crafted dtbo partition to
> workaround this, more information is available here:
>
> https://gitlab.com/calebccff/dtbo-google-wahoo-mainline
>
So it's not possible to just erase the dto, like on most other devices?
> Signed-off-by: Caleb Connolly
> ---
> It's possible to get wifi working by running Bjorns diag-router in the
> background, without this the wifi firmware crashes every 10 seconds or
> so. This is the same issue encountered on the OnePlus 5.
>
> arch/arm64/boot/dts/qcom/Makefile | 1 +
> .../boot/dts/qcom/msm8998-google-taimen.dts | 14 +
> .../boot/dts/qcom/msm8998-google-wahoo.dtsi | 391 ++
> 3 files changed, 406 insertions(+)
> create mode 100644 arch/arm64/boot/dts/qcom/msm8998-google-taimen.dts
> create mode 100644 arch/arm64/boot/dts/qcom/msm8998-google-wahoo.dtsi
>
> diff --git a/arch/arm64/boot/dts/qcom/Makefile
> b/arch/arm64/boot/dts/qcom/Makefile
> index 5113fac80b7a..d942d3ec3928 100644
> --- a/arch/arm64/boot/dts/qcom/Makefile
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -16,6 +16,7 @@ dtb-$(CONFIG_ARCH_QCOM) +=
> msm8994-msft-lumia-cityman.dtb
> dtb-$(CONFIG_ARCH_QCOM) += msm8994-sony-xperia-kitakami-sumire.dtb
> dtb-$(CONFIG_ARCH_QCOM) += msm8996-mtp.dtb
> dtb-$(CONFIG_ARCH_QCOM) += msm8998-asus-novago-tp370ql.dtb
> +dtb-$(CONFIG_ARCH_QCOM) += msm8998-google-taimen.dtb
> dtb-$(CONFIG_ARCH_QCOM) += msm8998-hp-envy-x2.dtb
> dtb-$(CONFIG_ARCH_QCOM) += msm8998-lenovo-miix-630.dtb
> dtb-$(CONFIG_ARCH_QCOM) += msm8998-mtp.dtb
> diff --git a/arch/arm64/boot/dts/qcom/msm8998-google-taimen.dts
> b/arch/arm64/boot/dts/qcom/msm8998-google-taimen.dts
> new file mode 100644
> index ..ffaaafe14037
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/msm8998-google-taimen.dts
> @@ -0,0 +1,14 @@
> +// SPDX-License-Identifier: GPL-2.0-only
Would you be willing to release these as BSD-3-Clause instead?
> +/*
> + * Copyright (c) 2020, Caleb Connolly
> + */
> +
> +/dts-v1/;
> +
> +#include "msm8998-google-wahoo.dtsi"
> +
> +/ {
> + model = "Google Pixel 2 XL";
> + compatible = "google,taimen", "google,wahoo", "qcom,msm8998",
> "qcom,msm8998-mtp";
> + qcom,msm-id = <0x124 0x20001>;
> +};
> diff --git a/arch/arm64/boot/dts/qcom/msm8998-google-wahoo.dtsi
> b/arch/arm64/boot/dts/qcom/msm8998-google-wahoo.dtsi
> new file mode 100644
> index ..0c221ead2df7
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/msm8998-google-wahoo.dtsi
> @@ -0,0 +1,391 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/* Copyright (c) 2020 Caleb Connolly */
> +
> +#include "msm8998.dtsi"
> +#include "pm8998.dtsi"
> +#include "pmi8998.dtsi"
> +#include "pm8005.dtsi"
> +
> +/delete-node/ _mem;
> +/delete-node/ _mem;
> +/delete-node/ _mem;
> +/delete-node/ _mem;
> +
> +/ {
> + aliases {
> + };
> +
> + chosen {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + /* Add "earlycon" intended to be used in combination with UART
> serial console */
> + bootargs = "clk_ignore_unused earlycon
> console=ttyGS0,115200";// loglevel=10 drm.debug=15 debug";
Please drop earlycon from this list (user should be able to add it if
they care later?) and use stdout-path to set the console, like we do on
other devices.
> + };
> +
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + mpss_mem: memory@8cc0 {
> + reg = <0 0x8cc0 0 0x780>;
> + no-map;
> + };
> +
> + venus_mem: memory@9440 {
> + reg = <0 0x9440 0 0x50>;
> + no-map;
> + };
> +
> + mba_mem: memory@9410 {
> + reg = <0 0x9490 0 0x20>;
> + no-map;
> + };
> +
> + slpi_mem: memory@94b0 {
> + reg = <0 0x94b0 0 0x70>;
> + no-map;
> + };
> +
> + ramoops: ramoops@a181 {
> + compatible = "ramoops";
> + reg = <0 0xa181 0 0x20>;
> + record-size = <0x2>;
> + console-size = <0x10>;
> + pmsg-size = <0x8>;
> +
Re: [PATCH v2] eeprom/optoe: driver to read/write SFP/QSFP/CMIS EEPROMS
> I am proposing acceptance of a commonly used implementation for accessing > SFPs because the one used by the netdev/netlink community does not fit the > architecture of the white box NOS/switch community. Please could you expand on this. I've given suggests as to how the new netlink KAPI could be used for this use case, without being attached to a netdev. And you have said nothing about why it cannot be made to work. You cannot argue the architecture does not fit without actually saying why it does not fit. Andrew
[PATCH] erofs: fix bio->bi_max_vecs behavior change
From: Gao Xiang
Martin reported an issue that directory read could be hung on the
latest -rc kernel with some certain image. The root cause is that
commit baa2c7c97153 ("block: set .bi_max_vecs as actual allocated
vector number") changes .bi_max_vecs behavior. bio->bi_max_vecs
is set as actual allocated vector number rather than the requested
number now.
Let's avoid using .bi_max_vecs completely instead.
Reported-by: Martin DEVERA
Signed-off-by: Gao Xiang
---
Hi Chao,
Could you take some time on reviewing this patchset in advance?
I'd like to upstream this regression fix asap since it has noticable
impact on 5.12-rc kernel.
Thanks,
Gao Xiang
fs/erofs/data.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/fs/erofs/data.c b/fs/erofs/data.c
index f88851c5c250..fa25d0eab5de 100644
--- a/fs/erofs/data.c
+++ b/fs/erofs/data.c
@@ -231,14 +231,6 @@ static inline struct bio *erofs_read_raw_page(struct bio
*bio,
goto submit_bio_retry;
*last_block = current_block;
-
- /* shift in advance in case of it followed by too many gaps */
- if (bio->bi_iter.bi_size >= bio->bi_max_vecs * PAGE_SIZE) {
- /* err should reassign to 0 after submitting */
- err = 0;
- goto submit_bio_out;
- }
-
return bio;
err_out:
@@ -252,7 +244,6 @@ static inline struct bio *erofs_read_raw_page(struct bio
*bio,
/* if updated manually, continuous pages has a gap */
if (bio)
-submit_bio_out:
submit_bio(bio);
return err ? ERR_PTR(err) : NULL;
}
@@ -274,7 +265,8 @@ static int erofs_raw_access_readpage(struct file *file,
struct page *page)
if (IS_ERR(bio))
return PTR_ERR(bio);
- DBG_BUGON(bio); /* since we have only one bio -- must be NULL */
+ if (bio)
+ submit_bio(bio);
return 0;
}
@@ -305,7 +297,6 @@ static void erofs_raw_access_readahead(struct
readahead_control *rac)
put_page(page);
}
- /* the rare case (end in gaps) */
if (bio)
submit_bio(bio);
}
--
2.20.1
[PATCH v2 4/4] khugepaged: fix wrong result value for trace_mm_collapse_huge_page_isolate()
In writable and !referenced case, the result value should be
SCAN_LACK_REFERENCED_PAGE for trace_mm_collapse_huge_page_isolate()
instead of default 0 (SCAN_FAIL) here.
Fixes: 7d2eba0557c1 ("mm: add tracepoint for scanning pages")
Signed-off-by: Miaohe Lin
Acked-by: Kirill A. Shutemov
---
mm/khugepaged.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index e886a8618c33..adf677246d86 100644
--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -716,17 +716,17 @@ static int __collapse_huge_page_isolate(struct
vm_area_struct *vma,
if (pte_write(pteval))
writable = true;
}
- if (likely(writable)) {
- if (likely(referenced)) {
- result = SCAN_SUCCEED;
- trace_mm_collapse_huge_page_isolate(page, none_or_zero,
- referenced,
writable, result);
- return 1;
- }
- } else {
+
+ if (unlikely(!writable)) {
result = SCAN_PAGE_RO;
+ } else if (unlikely(!referenced)) {
+ result = SCAN_LACK_REFERENCED_PAGE;
+ } else {
+ result = SCAN_SUCCEED;
+ trace_mm_collapse_huge_page_isolate(page, none_or_zero,
+ referenced, writable,
result);
+ return 1;
}
-
out:
release_pte_pages(pte, _pte, compound_pagelist);
trace_mm_collapse_huge_page_isolate(page, none_or_zero,
--
2.19.1
[PATCH v2 2/4] khugepaged: reuse the smp_wmb() inside __SetPageUptodate()
smp_wmb() is needed to avoid the copy_huge_page writes to become visible after the set_pmd_at() write here. But we can reuse the smp_wmb() inside __SetPageUptodate() to remove this redundant one. Signed-off-by: Miaohe Lin Acked-by: Kirill A. Shutemov --- mm/khugepaged.c | 13 ++--- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/mm/khugepaged.c b/mm/khugepaged.c index d43812c5ce16..287e7ecf978c 100644 --- a/mm/khugepaged.c +++ b/mm/khugepaged.c @@ -1183,19 +1183,18 @@ static void collapse_huge_page(struct mm_struct *mm, __collapse_huge_page_copy(pte, new_page, vma, address, pte_ptl, _pagelist); pte_unmap(pte); + /* +* spin_lock() below is not the equivalent of smp_wmb(), but +* the smp_wmb() inside __SetPageUptodate() can be reused to +* avoid the copy_huge_page writes to become visible after +* the set_pmd_at() write. +*/ __SetPageUptodate(new_page); pgtable = pmd_pgtable(_pmd); _pmd = mk_huge_pmd(new_page, vma->vm_page_prot); _pmd = maybe_pmd_mkwrite(pmd_mkdirty(_pmd), vma); - /* -* spin_lock() below is not the equivalent of smp_wmb(), so -* this is needed to avoid the copy_huge_page writes to become -* visible after the set_pmd_at() write. -*/ - smp_wmb(); - spin_lock(pmd_ptl); BUG_ON(!pmd_none(*pmd)); page_add_new_anon_rmap(new_page, vma, address, true); -- 2.19.1
[PATCH v2 3/4] khugepaged: use helper khugepaged_test_exit() in __khugepaged_enter()
Commit 4d45e75a9955 ("mm: remove the now-unnecessary mmget_still_valid()
hack") have made khugepaged_test_exit() suitable for check mm->mm_users
against 0. Use this helper here.
Signed-off-by: Miaohe Lin
Acked-by: Kirill A. Shutemov
---
mm/khugepaged.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index 287e7ecf978c..e886a8618c33 100644
--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -481,7 +481,7 @@ int __khugepaged_enter(struct mm_struct *mm)
return -ENOMEM;
/* __khugepaged_exit() must not run from under us */
- VM_BUG_ON_MM(atomic_read(>mm_users) == 0, mm);
+ VM_BUG_ON_MM(khugepaged_test_exit(mm), mm);
if (unlikely(test_and_set_bit(MMF_VM_HUGEPAGE, >flags))) {
free_mm_slot(mm_slot);
return 0;
--
2.19.1
[PATCH v2 0/4] Cleanup and fixup for khugepaged
Hi all, This series contains cleanups to remove unneeded return value, use helper function and so on. And there is one fix to correct the wrong result value for trace_mm_collapse_huge_page_isolate(). More details can be found in the respective changelogs. Thanks! v1->v2: drop patch "khugepaged: remove unnecessary mem_cgroup_uncharge() in collapse_[file|huge_page]" collect Acked-by Miaohe Lin (4): khugepaged: remove unneeded return value of khugepaged_collapse_pte_mapped_thps() khugepaged: reuse the smp_wmb() inside __SetPageUptodate() khugepaged: use helper khugepaged_test_exit() in __khugepaged_enter() khugepaged: fix wrong result value for trace_mm_collapse_huge_page_isolate() mm/khugepaged.c | 43 --- 1 file changed, 20 insertions(+), 23 deletions(-) -- 2.19.1
[PATCH v2 1/4] khugepaged: remove unneeded return value of khugepaged_collapse_pte_mapped_thps()
The return value of khugepaged_collapse_pte_mapped_thps() is never checked
since it's introduced. We should remove such unneeded return value.
Signed-off-by: Miaohe Lin
Acked-by: Kirill A. Shutemov
---
mm/khugepaged.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index a7d6cb912b05..d43812c5ce16 100644
--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -1533,16 +1533,16 @@ void collapse_pte_mapped_thp(struct mm_struct *mm,
unsigned long addr)
goto drop_hpage;
}
-static int khugepaged_collapse_pte_mapped_thps(struct mm_slot *mm_slot)
+static void khugepaged_collapse_pte_mapped_thps(struct mm_slot *mm_slot)
{
struct mm_struct *mm = mm_slot->mm;
int i;
if (likely(mm_slot->nr_pte_mapped_thp == 0))
- return 0;
+ return;
if (!mmap_write_trylock(mm))
- return -EBUSY;
+ return;
if (unlikely(khugepaged_test_exit(mm)))
goto out;
@@ -1553,7 +1553,6 @@ static int khugepaged_collapse_pte_mapped_thps(struct
mm_slot *mm_slot)
out:
mm_slot->nr_pte_mapped_thp = 0;
mmap_write_unlock(mm);
- return 0;
}
static void retract_page_tables(struct address_space *mapping, pgoff_t pgoff)
@@ -2057,9 +2056,8 @@ static void khugepaged_scan_file(struct mm_struct *mm,
BUILD_BUG();
}
-static int khugepaged_collapse_pte_mapped_thps(struct mm_slot *mm_slot)
+static void khugepaged_collapse_pte_mapped_thps(struct mm_slot *mm_slot)
{
- return 0;
}
#endif
--
2.19.1
Re: [PATCH 5.10 000/102] 5.10.21-rc1 review
On Fri, Mar 05, 2021 at 01:20:19PM +0100, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 5.10.21 release. > There are 102 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun, 07 Mar 2021 12:08:39 +. > Anything received after that time might be too late. > Building arm:realview-pb-a8:realview_defconfig:realview_pb:mem512:arm-realview-pba8:initrd ... failed Error log: kernel/rcu/tree.c:683:2: error: implicit declaration of function 'IRQ_WORK_INIT' Guenter
Re: [PATCH v3 5/7] irqchip/loongson-liointc: irqchip add 2.0 version
On 03/06/2021 11:06 AM, Huacai Chen wrote: Hi, Qing, On Sat, Mar 6, 2021 at 10:36 AM Qing Zhang wrote: Add IO interrupt controller support for Loongson 2k1000, different from the 3a series is that 2K1000 has 64 interrupt sources, 0-31 correspond to the device tree liointc0 device node, and the other correspond to liointc1 node. Use the formal name (Loongson-2K1000, Loongson-3A series), please. Hi, Huacai Thank you very much for your reply. I will modify the submission information, Use the formal name (Loongson-2K1000, Loongson-3A series) in v4, Before that, I will wait for other people's opinions about this series. Thanks, Qing Huacai
Re: [PATCH 5.4 00/72] 5.4.103-rc1 review
On Fri, Mar 05, 2021 at 01:21:02PM +0100, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 5.4.103 release. > There are 72 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun, 07 Mar 2021 12:08:39 +. > Anything received after that time might be too late. > Building arm:realview-pb-a8:realview_defconfig:realview_pb:mem512:arm-realview-pba8:initrd ... failed Error log: kernel/rcu/tree.c:617:2: error: implicit declaration of function 'IRQ_WORK_INIT'; did you mean 'IRQ_WORK_BUSY'? [-Werror=implicit-function-declaration] 617 | IRQ_WORK_INIT(late_wakeup_func); | ^ | IRQ_WORK_BUSY Guenter
Re: [PATCH v1 4/4] hwmon: acpi_power_meter: Get rid of ACPICA message printing
On Fri, Mar 05, 2021 at 07:43:54PM +0100, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Use acpi_evaluation_failure_warn() introduced previously instead of
> the ACPICA-specific ACPI_EXCEPTION() macro to log warning messages
> regarding ACPI object evaluation failures and use dev_err() instead
> of ACPI_EXCEPTION() to log _PMC package parsing failures, which is
> consistent with the other messages printed by the code in question.
>
> Next, drop the ACPI_MODULE_NAME() definition only used by the ACPICA
> message printing macro.
>
> Signed-off-by: Rafael J. Wysocki
Acked-by: Guenter Roeck
> ---
> drivers/hwmon/acpi_power_meter.c | 29 +++--
> 1 file changed, 19 insertions(+), 10 deletions(-)
>
> Index: linux-pm/drivers/hwmon/acpi_power_meter.c
> ===
> --- linux-pm.orig/drivers/hwmon/acpi_power_meter.c
> +++ linux-pm/drivers/hwmon/acpi_power_meter.c
> @@ -20,7 +20,6 @@
> #include
>
> #define ACPI_POWER_METER_NAME"power_meter"
> -ACPI_MODULE_NAME(ACPI_POWER_METER_NAME);
> #define ACPI_POWER_METER_DEVICE_NAME "Power Meter"
> #define ACPI_POWER_METER_CLASS "pwr_meter_resource"
>
> @@ -114,7 +113,8 @@ static int update_avg_interval(struct ac
> status = acpi_evaluate_integer(resource->acpi_dev->handle, "_GAI",
> NULL, );
> if (ACPI_FAILURE(status)) {
> - ACPI_EXCEPTION((AE_INFO, status, "Evaluating _GAI"));
> + acpi_evaluation_failure_warn(resource->acpi_dev->handle, "_GAI",
> + status);
> return -ENODEV;
> }
>
> @@ -166,7 +166,8 @@ static ssize_t set_avg_interval(struct d
> mutex_unlock(>lock);
>
> if (ACPI_FAILURE(status)) {
> - ACPI_EXCEPTION((AE_INFO, status, "Evaluating _PAI"));
> + acpi_evaluation_failure_warn(resource->acpi_dev->handle, "_PAI",
> + status);
> return -EINVAL;
> }
>
> @@ -186,7 +187,8 @@ static int update_cap(struct acpi_power_
> status = acpi_evaluate_integer(resource->acpi_dev->handle, "_GHL",
> NULL, );
> if (ACPI_FAILURE(status)) {
> - ACPI_EXCEPTION((AE_INFO, status, "Evaluating _GHL"));
> + acpi_evaluation_failure_warn(resource->acpi_dev->handle, "_GHL",
> + status);
> return -ENODEV;
> }
>
> @@ -237,7 +239,8 @@ static ssize_t set_cap(struct device *de
> mutex_unlock(>lock);
>
> if (ACPI_FAILURE(status)) {
> - ACPI_EXCEPTION((AE_INFO, status, "Evaluating _SHL"));
> + acpi_evaluation_failure_warn(resource->acpi_dev->handle, "_SHL",
> + status);
> return -EINVAL;
> }
>
> @@ -270,7 +273,8 @@ static int set_acpi_trip(struct acpi_pow
> status = acpi_evaluate_integer(resource->acpi_dev->handle, "_PTP",
> , );
> if (ACPI_FAILURE(status)) {
> - ACPI_EXCEPTION((AE_INFO, status, "Evaluating _PTP"));
> + acpi_evaluation_failure_warn(resource->acpi_dev->handle, "_PTP",
> + status);
> return -EINVAL;
> }
>
> @@ -322,7 +326,8 @@ static int update_meter(struct acpi_powe
> status = acpi_evaluate_integer(resource->acpi_dev->handle, "_PMM",
> NULL, );
> if (ACPI_FAILURE(status)) {
> - ACPI_EXCEPTION((AE_INFO, status, "Evaluating _PMM"));
> + acpi_evaluation_failure_warn(resource->acpi_dev->handle, "_PMM",
> + status);
> return -ENODEV;
> }
>
> @@ -549,7 +554,8 @@ static int read_domain_devices(struct ac
> status = acpi_evaluate_object(resource->acpi_dev->handle, "_PMD", NULL,
> );
> if (ACPI_FAILURE(status)) {
> - ACPI_EXCEPTION((AE_INFO, status, "Evaluating _PMD"));
> + acpi_evaluation_failure_warn(resource->acpi_dev->handle, "_PMD",
> + status);
> return -ENODEV;
> }
>
> @@ -745,7 +751,8 @@ static int read_capabilities(struct acpi
> status = acpi_evaluate_object(resource->acpi_dev->handle, "_PMC", NULL,
> );
> if (ACPI_FAILURE(status)) {
> - ACPI_EXCEPTION((AE_INFO, status, "Evaluating _PMC"));
> + acpi_evaluation_failure_warn(resource->acpi_dev->handle, "_PMC",
> + status);
> return -ENODEV;
> }
>
> @@ -765,7 +772,9 @@ static int read_capabilities(struct acpi
>
> status = acpi_extract_package(pss, , );
> if (ACPI_FAILURE(status)) {
> -
Re: [PATCH RESEND][next] hwmon: (max6621) Fix fall-through warnings for Clang
On Fri, Mar 05, 2021 at 03:52:58AM -0600, Gustavo A. R. Silva wrote: > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning > by explicitly adding a break statement instead of letting the code fall > through to the next case. > > Link: https://github.com/KSPP/linux/issues/115 > Acked-by: Guenter Roeck > Signed-off-by: Gustavo A. R. Silva > --- I Acked those, thus assuming that they would be applied through some other tree. If that is not the case, you'll need to let me know. The resend only means to me that whatever tree was supposed to pick it up did not do it, but it doesn't result in any action from my side. Guenter > drivers/hwmon/max6621.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/hwmon/max6621.c b/drivers/hwmon/max6621.c > index 367855d5edae..7821132e17fa 100644 > --- a/drivers/hwmon/max6621.c > +++ b/drivers/hwmon/max6621.c > @@ -156,7 +156,7 @@ max6621_is_visible(const void *data, enum > hwmon_sensor_types type, u32 attr, > default: > break; > } > - > + break; > default: > break; > } > -- > 2.27.0 >
Re: [PATCH 1/2] MIPS: Loongson64: Remove unused sysconf members
On 03/05/2021 10:32 AM, Jiaxun Yang wrote: 在 2021/3/4 下午7:00, Qing Zhang 写道: We don't need them anymore, They are uniform on all Loongson64 systems and have been fixed in DeviceTree.loongson3_platform_init is replaced with DTS + driver. Signed-off-by: Jiaxun Yang Signed-off-by: Qing Zhang Acked-by: Jiaxun Yang Hmm, why it comes with my sign-off? I assue it's my patch somewhere off the tree? Hi, Jiaxun Thank you very much for your reply. Yes, it is like this.out of tree provides good ideas, and clean up others by the way. Thanks, Qing Thanks. - Jiaxun
Re: [PATCH 4/5] khugepaged: remove unnecessary mem_cgroup_uncharge() in collapse_[file|huge_page]
On 2021/3/6 1:38, Kirill A. Shutemov wrote:
> On Thu, Mar 04, 2021 at 07:30:12AM -0500, Miaohe Lin wrote:
>> Since commit 7ae88534cdd9 ("mm: move mem_cgroup_uncharge out of
>> __page_cache_release()"), the mem_cgroup will be uncharged when hpage is
>> freed. Uncharge mem_cgroup here is harmless but it looks confusing and
>> buggy: if mem_cgroup charge failed, we will call mem_cgroup_uncharge()
>> uncorrectly in error path because hpage is not IS_ERR_OR_NULL().
>>
>> Signed-off-by: Miaohe Lin
>
> Hm. I'm not sure about this patch.
>
> For !NUMA the page will get allocated and freed very early: in
> khugepaged_do_scan() and with the change mem_cgroup_charge() may get
> called twice for two different mm_structs.
Many thanks for point it out.
> > Is it safe?
I'am sorry I missed the !NUMA case! :(
In !NUMA case, hpage may not be freed in the khugepaged_do_scan() while loop.
Thus mem_cgroup_charge()
may get called twice for two different mm_structs. In fact,
mem_cgroup_uncharge() may also get called
twice __but__ it's safe to do this.
The imbalance of mem_cgroup_charge() and mem_cgroup_uncharge() looks buggy and
weird __but__ it's safe
to call mem_cgroup_uncharge() many times with or without a successful
mem_cgroup_charge() call.
So I would drop this patch.
>
Thanks again.
[PATCH net-next v2 5/6] net: qualcomm: rmnet: don't use C bit-fields in rmnet checksum trailer
Replace the use of C bit-fields in the rmnet_map_dl_csum_trailer
structure with a single one-byte field, using constant field masks
to encode or get at embedded values.
Signed-off-by: Alex Elder
Reviewed-by: Bjorn Andersson
---
.../ethernet/qualcomm/rmnet/rmnet_map_data.c| 2 +-
include/linux/if_rmnet.h| 17 +++--
2 files changed, 8 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c
b/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c
index 3291f252d81b0..29d485b868a65 100644
--- a/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c
+++ b/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c
@@ -365,7 +365,7 @@ int rmnet_map_checksum_downlink_packet(struct sk_buff *skb,
u16 len)
csum_trailer = (struct rmnet_map_dl_csum_trailer *)(skb->data + len);
- if (!csum_trailer->valid) {
+ if (!u8_get_bits(csum_trailer->flags, MAP_CSUM_DL_VALID_FMASK)) {
priv->stats.csum_valid_unset++;
return -EINVAL;
}
diff --git a/include/linux/if_rmnet.h b/include/linux/if_rmnet.h
index 4824c6328a82c..1fbb7531238b6 100644
--- a/include/linux/if_rmnet.h
+++ b/include/linux/if_rmnet.h
@@ -19,21 +19,18 @@ struct rmnet_map_header {
#define MAP_PAD_LEN_FMASK GENMASK(5, 0)
struct rmnet_map_dl_csum_trailer {
- u8 reserved1;
-#if defined(__LITTLE_ENDIAN_BITFIELD)
- u8 valid:1;
- u8 reserved2:7;
-#elif defined (__BIG_ENDIAN_BITFIELD)
- u8 reserved2:7;
- u8 valid:1;
-#else
-#error "Please fix "
-#endif
+ u8 reserved1;
+ u8 flags; /* MAP_CSUM_DL_*_FMASK */
__be16 csum_start_offset;
__be16 csum_length;
__be16 csum_value;
} __aligned(1);
+/* rmnet_map_dl_csum_trailer flags field:
+ * VALID: 1 = checksum and length valid; 0 = ignore them
+ */
+#define MAP_CSUM_DL_VALID_FMASKGENMASK(0, 0)
+
struct rmnet_map_ul_csum_header {
__be16 csum_start_offset;
#if defined(__LITTLE_ENDIAN_BITFIELD)
--
2.27.0
[PATCH net-next v2 4/6] net: qualcomm: rmnet: use field masks instead of C bit-fields
The actual layout of bits defined in C bit-fields (e.g. int foo : 3)
is implementation-defined. Structures defined in
address this by specifying all bit-fields twice, to cover two
possible layouts.
I think this pattern is repetitive and noisy, and I find the whole
notion of compiler "bitfield endianness" to be non-intuitive.
Stop using C bit-fields for the command/data flag and the pad length
fields in the rmnet_map structure. Instead, define a single-byte
flags field, and use the functions defined in ,
along with field mask constants to extract or assign values within
that field.
Signed-off-by: Alex Elder
Reviewed-by: Bjorn Andersson
---
.../ethernet/qualcomm/rmnet/rmnet_handlers.c | 5 ++--
.../ethernet/qualcomm/rmnet/rmnet_map_data.c | 4 +++-
include/linux/if_rmnet.h | 23 ---
3 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c
b/drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c
index 2a6b2a609884c..30f8e2f02696b 100644
--- a/drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c
+++ b/drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c
@@ -4,6 +4,7 @@
* RMNET Data ingress/egress handler
*/
+#include
#include
#include
#include
@@ -61,7 +62,7 @@ __rmnet_map_ingress_handler(struct sk_buff *skb,
u16 len, pad;
u8 mux_id;
- if (map_header->cd_bit) {
+ if (u8_get_bits(map_header->flags, MAP_CMD_FMASK)) {
/* Packet contains a MAP command (not data) */
if (port->data_format & RMNET_FLAGS_INGRESS_MAP_COMMANDS)
return rmnet_map_command(skb, port);
@@ -70,7 +71,7 @@ __rmnet_map_ingress_handler(struct sk_buff *skb,
}
mux_id = map_header->mux_id;
- pad = map_header->pad_len;
+ pad = u8_get_bits(map_header->flags, MAP_PAD_LEN_FMASK);
len = ntohs(map_header->pkt_len) - pad;
if (mux_id >= RMNET_MAX_LOGICAL_EP)
diff --git a/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c
b/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c
index fd55269c2ce3c..3291f252d81b0 100644
--- a/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c
+++ b/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c
@@ -4,6 +4,7 @@
* RMNET Data MAP protocol
*/
+#include
#include
#include
#include
@@ -299,7 +300,8 @@ struct rmnet_map_header *rmnet_map_add_map_header(struct
sk_buff *skb,
done:
map_header->pkt_len = htons(map_datalen + padding);
- map_header->pad_len = padding & 0x3F;
+ /* This is a data packet, so the CMD bit is 0 */
+ map_header->flags = u8_encode_bits(padding, MAP_PAD_LEN_FMASK);
return map_header;
}
diff --git a/include/linux/if_rmnet.h b/include/linux/if_rmnet.h
index 8c7845baf3837..4824c6328a82c 100644
--- a/include/linux/if_rmnet.h
+++ b/include/linux/if_rmnet.h
@@ -6,21 +6,18 @@
#define _LINUX_IF_RMNET_H_
struct rmnet_map_header {
-#if defined(__LITTLE_ENDIAN_BITFIELD)
- u8 pad_len:6;
- u8 reserved_bit:1;
- u8 cd_bit:1;
-#elif defined (__BIG_ENDIAN_BITFIELD)
- u8 cd_bit:1;
- u8 reserved_bit:1;
- u8 pad_len:6;
-#else
-#error "Please fix "
-#endif
- u8 mux_id;
- __be16 pkt_len;
+ u8 flags; /* MAP_*_FMASK */
+ u8 mux_id;
+ __be16 pkt_len; /* Length of packet, including pad */
} __aligned(1);
+/* rmnet_map_header flags field:
+ * CMD: 1 = packet contains a MAP command; 0 = packet contains data
+ * PAD_LEN: number of pad bytes following packet data
+ */
+#define MAP_CMD_FMASK GENMASK(7, 7)
+#define MAP_PAD_LEN_FMASK GENMASK(5, 0)
+
struct rmnet_map_dl_csum_trailer {
u8 reserved1;
#if defined(__LITTLE_ENDIAN_BITFIELD)
--
2.27.0
[PATCH net-next v2 3/6] net: qualcomm: rmnet: kill RMNET_MAP_GET_*() accessor macros
The following macros, defined in "rmnet_map.h", assume a socket
buffer is provided as an argument without any real indication this
is the case.
RMNET_MAP_GET_MUX_ID()
RMNET_MAP_GET_CD_BIT()
RMNET_MAP_GET_PAD()
RMNET_MAP_GET_CMD_START()
RMNET_MAP_GET_LENGTH()
What they hide is pretty trivial accessing of fields in a structure,
and it's much clearer to see this if we do these accesses directly.
So rather than using these accessor macros, assign a local
variable of the map header pointer type to the socket buffer data
pointer, and derereference that pointer variable.
In "rmnet_map_data.c", use sizeof(object) rather than sizeof(type)
in one spot. Also, there's no need to byte swap 0; it's all zeros
irrespective of endianness.
Signed-off-by: Alex Elder
Reviewed-by: Bjorn Andersson
---
drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c | 10 ++
drivers/net/ethernet/qualcomm/rmnet/rmnet_map.h | 12
.../net/ethernet/qualcomm/rmnet/rmnet_map_command.c | 11 ---
drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c | 4 ++--
4 files changed, 16 insertions(+), 21 deletions(-)
diff --git a/drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c
b/drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c
index 3d00b32323084..2a6b2a609884c 100644
--- a/drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c
+++ b/drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c
@@ -56,20 +56,22 @@ static void
__rmnet_map_ingress_handler(struct sk_buff *skb,
struct rmnet_port *port)
{
+ struct rmnet_map_header *map_header = (void *)skb->data;
struct rmnet_endpoint *ep;
u16 len, pad;
u8 mux_id;
- if (RMNET_MAP_GET_CD_BIT(skb)) {
+ if (map_header->cd_bit) {
+ /* Packet contains a MAP command (not data) */
if (port->data_format & RMNET_FLAGS_INGRESS_MAP_COMMANDS)
return rmnet_map_command(skb, port);
goto free_skb;
}
- mux_id = RMNET_MAP_GET_MUX_ID(skb);
- pad = RMNET_MAP_GET_PAD(skb);
- len = RMNET_MAP_GET_LENGTH(skb) - pad;
+ mux_id = map_header->mux_id;
+ pad = map_header->pad_len;
+ len = ntohs(map_header->pkt_len) - pad;
if (mux_id >= RMNET_MAX_LOGICAL_EP)
goto free_skb;
diff --git a/drivers/net/ethernet/qualcomm/rmnet/rmnet_map.h
b/drivers/net/ethernet/qualcomm/rmnet/rmnet_map.h
index 576501db2a0bc..2aea153f42473 100644
--- a/drivers/net/ethernet/qualcomm/rmnet/rmnet_map.h
+++ b/drivers/net/ethernet/qualcomm/rmnet/rmnet_map.h
@@ -32,18 +32,6 @@ enum rmnet_map_commands {
RMNET_MAP_COMMAND_ENUM_LENGTH
};
-#define RMNET_MAP_GET_MUX_ID(Y) (((struct rmnet_map_header *) \
-(Y)->data)->mux_id)
-#define RMNET_MAP_GET_CD_BIT(Y) (((struct rmnet_map_header *) \
- (Y)->data)->cd_bit)
-#define RMNET_MAP_GET_PAD(Y) (((struct rmnet_map_header *) \
- (Y)->data)->pad_len)
-#define RMNET_MAP_GET_CMD_START(Y) ((struct rmnet_map_control_command *) \
- ((Y)->data + \
- sizeof(struct rmnet_map_header)))
-#define RMNET_MAP_GET_LENGTH(Y) (ntohs(((struct rmnet_map_header *) \
- (Y)->data)->pkt_len))
-
#define RMNET_MAP_COMMAND_REQUEST 0
#define RMNET_MAP_COMMAND_ACK 1
#define RMNET_MAP_COMMAND_UNSUPPORTED 2
diff --git a/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_command.c
b/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_command.c
index beaee49621287..add0f5ade2e61 100644
--- a/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_command.c
+++ b/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_command.c
@@ -12,12 +12,13 @@ static u8 rmnet_map_do_flow_control(struct sk_buff *skb,
struct rmnet_port *port,
int enable)
{
+ struct rmnet_map_header *map_header = (void *)skb->data;
struct rmnet_endpoint *ep;
struct net_device *vnd;
u8 mux_id;
int r;
- mux_id = RMNET_MAP_GET_MUX_ID(skb);
+ mux_id = map_header->mux_id;
if (mux_id >= RMNET_MAX_LOGICAL_EP) {
kfree_skb(skb);
@@ -49,6 +50,7 @@ static void rmnet_map_send_ack(struct sk_buff *skb,
unsigned char type,
struct rmnet_port *port)
{
+ struct rmnet_map_header *map_header = (void *)skb->data;
struct rmnet_map_control_command *cmd;
struct net_device *dev = skb->dev;
@@ -58,7 +60,8 @@ static void rmnet_map_send_ack(struct sk_buff *skb,
skb->protocol = htons(ETH_P_MAP);
- cmd = RMNET_MAP_GET_CMD_START(skb);
+ /* Command data immediately follows the MAP header */
+ cmd = (struct rmnet_map_control_command *)(map_header + 1);
cmd->cmd_type = type & 0x03;
[PATCH net-next v2 6/6] net: qualcomm: rmnet: don't use C bit-fields in rmnet checksum header
Replace the use of C bit-fields in the rmnet_map_ul_csum_header
structure with a single two-byte (big endian) structure member,
and use field masks to encode or get values within it.
Previously rmnet_map_ipv4_ul_csum_header() would update values in
the host byte-order fields, and then forcibly fix their byte order
using a combination of byte order operations and types.
Instead, just compute the value that needs to go into the new
structure member and save it with a simple byte-order conversion.
Make similar simplifications in rmnet_map_ipv6_ul_csum_header().
Finally, in rmnet_map_checksum_uplink_packet() a set of assignments
zeroes every field in the upload checksum header. Replace that with
a single memset() operation.
Signed-off-by: Alex Elder
Reported-by: kernel test robot
---
v2: Fixed to use u16_encode_bits() instead of be16_encode_bits().
.../ethernet/qualcomm/rmnet/rmnet_map_data.c | 34 ++-
include/linux/if_rmnet.h | 21 ++--
2 files changed, 21 insertions(+), 34 deletions(-)
diff --git a/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c
b/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c
index 29d485b868a65..b76ad48da7325 100644
--- a/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c
+++ b/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c
@@ -198,23 +198,19 @@ rmnet_map_ipv4_ul_csum_header(void *iphdr,
struct rmnet_map_ul_csum_header *ul_header,
struct sk_buff *skb)
{
- __be16 *hdr = (__be16 *)ul_header;
struct iphdr *ip4h = iphdr;
u16 offset;
+ u16 val;
offset = skb_transport_header(skb) - (unsigned char *)iphdr;
ul_header->csum_start_offset = htons(offset);
- ul_header->csum_insert_offset = skb->csum_offset;
- ul_header->csum_enabled = 1;
+ val = u16_encode_bits(1, MAP_CSUM_UL_ENABLED_FMASK);
if (ip4h->protocol == IPPROTO_UDP)
- ul_header->udp_ind = 1;
- else
- ul_header->udp_ind = 0;
+ val |= u16_encode_bits(1, MAP_CSUM_UL_UDP_FMASK);
+ val |= u16_encode_bits(skb->csum_offset, MAP_CSUM_UL_OFFSET_FMASK);
- /* Changing remaining fields to network order */
- hdr++;
- *hdr = htons((__force u16)*hdr);
+ ul_header->csum_info = htons(val);
skb->ip_summed = CHECKSUM_NONE;
@@ -241,24 +237,19 @@ rmnet_map_ipv6_ul_csum_header(void *ip6hdr,
struct rmnet_map_ul_csum_header *ul_header,
struct sk_buff *skb)
{
- __be16 *hdr = (__be16 *)ul_header;
struct ipv6hdr *ip6h = ip6hdr;
u16 offset;
+ u16 val;
offset = skb_transport_header(skb) - (unsigned char *)ip6hdr;
ul_header->csum_start_offset = htons(offset);
- ul_header->csum_insert_offset = skb->csum_offset;
- ul_header->csum_enabled = 1;
-
+ val = u16_encode_bits(1, MAP_CSUM_UL_ENABLED_FMASK);
if (ip6h->nexthdr == IPPROTO_UDP)
- ul_header->udp_ind = 1;
- else
- ul_header->udp_ind = 0;
+ val |= u16_encode_bits(1, MAP_CSUM_UL_UDP_FMASK);
+ val |= u16_encode_bits(skb->csum_offset, MAP_CSUM_UL_OFFSET_FMASK);
- /* Changing remaining fields to network order */
- hdr++;
- *hdr = htons((__force u16)*hdr);
+ ul_header->csum_info = htons(val);
skb->ip_summed = CHECKSUM_NONE;
@@ -425,10 +416,7 @@ void rmnet_map_checksum_uplink_packet(struct sk_buff *skb,
}
sw_csum:
- ul_header->csum_start_offset = 0;
- ul_header->csum_insert_offset = 0;
- ul_header->csum_enabled = 0;
- ul_header->udp_ind = 0;
+ memset(ul_header, 0, sizeof(*ul_header));
priv->stats.csum_sw++;
}
diff --git a/include/linux/if_rmnet.h b/include/linux/if_rmnet.h
index 1fbb7531238b6..9ff09a2bcf9e1 100644
--- a/include/linux/if_rmnet.h
+++ b/include/linux/if_rmnet.h
@@ -33,17 +33,16 @@ struct rmnet_map_dl_csum_trailer {
struct rmnet_map_ul_csum_header {
__be16 csum_start_offset;
-#if defined(__LITTLE_ENDIAN_BITFIELD)
- u16 csum_insert_offset:14;
- u16 udp_ind:1;
- u16 csum_enabled:1;
-#elif defined (__BIG_ENDIAN_BITFIELD)
- u16 csum_enabled:1;
- u16 udp_ind:1;
- u16 csum_insert_offset:14;
-#else
-#error "Please fix "
-#endif
+ __be16 csum_info; /* MAP_CSUM_UL_*_FMASK */
} __aligned(1);
+/* csum_info field:
+ * OFFSET:where (offset in bytes) to insert computed checksum
+ * UDP: 1 = UDP checksum (zero checkum means no checksum)
+ * ENABLED: 1 = checksum computation requested
+ */
+#define MAP_CSUM_UL_OFFSET_FMASK GENMASK(13, 0)
+#define MAP_CSUM_UL_UDP_FMASK GENMASK(14, 14)
+#define MAP_CSUM_UL_ENABLED_FMASK GENMASK(15, 15)
+
#endif /* !(_LINUX_IF_RMNET_H_) */
--
2.27.0
[PATCH net-next v2 2/6] net: qualcomm: rmnet: simplify some byte order logic
In rmnet_map_ipv4_ul_csum_header() and rmnet_map_ipv6_ul_csum_header()
the offset within a packet at which checksumming should commence is
calculated. This calculation involves byte swapping and a forced type
conversion that makes it hard to understand.
Simplify this by computing the offset in host byte order, then
converting the result when assigning it into the header field.
Signed-off-by: Alex Elder
Reviewed-by: Bjorn Andersson
---
.../ethernet/qualcomm/rmnet/rmnet_map_data.c | 22 ++-
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c
b/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c
index 21d38167f9618..bd1aa11c9ce59 100644
--- a/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c
+++ b/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c
@@ -197,12 +197,13 @@ rmnet_map_ipv4_ul_csum_header(void *iphdr,
struct rmnet_map_ul_csum_header *ul_header,
struct sk_buff *skb)
{
- struct iphdr *ip4h = (struct iphdr *)iphdr;
- __be16 *hdr = (__be16 *)ul_header, offset;
+ __be16 *hdr = (__be16 *)ul_header;
+ struct iphdr *ip4h = iphdr;
+ u16 offset;
+
+ offset = skb_transport_header(skb) - (unsigned char *)iphdr;
+ ul_header->csum_start_offset = htons(offset);
- offset = htons((__force u16)(skb_transport_header(skb) -
-(unsigned char *)iphdr));
- ul_header->csum_start_offset = offset;
ul_header->csum_insert_offset = skb->csum_offset;
ul_header->csum_enabled = 1;
if (ip4h->protocol == IPPROTO_UDP)
@@ -239,12 +240,13 @@ rmnet_map_ipv6_ul_csum_header(void *ip6hdr,
struct rmnet_map_ul_csum_header *ul_header,
struct sk_buff *skb)
{
- struct ipv6hdr *ip6h = (struct ipv6hdr *)ip6hdr;
- __be16 *hdr = (__be16 *)ul_header, offset;
+ __be16 *hdr = (__be16 *)ul_header;
+ struct ipv6hdr *ip6h = ip6hdr;
+ u16 offset;
+
+ offset = skb_transport_header(skb) - (unsigned char *)ip6hdr;
+ ul_header->csum_start_offset = htons(offset);
- offset = htons((__force u16)(skb_transport_header(skb) -
-(unsigned char *)ip6hdr));
- ul_header->csum_start_offset = offset;
ul_header->csum_insert_offset = skb->csum_offset;
ul_header->csum_enabled = 1;
--
2.27.0
[PATCH net-next v2 0/6] net: qualcomm: rmnet: stop using C bit-fields
Version 2 of this series fixes the code in the final patch that encoded the RMNet checksum offload header inserted for outgoing packets. It was erroneously using be16_encode_bits() to generate the value to be written into the header, where it should have been using u16_encode_bits(). Bjorn noticed this, as did the Intel kernel test robot. This version of these patches has been tested as follows: - ICMP (ping) and TCP (wget), and UDP (iperf) packet transfer in both directions over an RMNet link (using IPA, with IPv4 only). This used QMAPv4, with checksum offload in both directions enabled (and aggregation enabled for inbound data). Inbound checksum values were verified good (for TCP and UDP). I presume the TX checksum was acceptable but did nothing special to confirm that. Checksum verification was enabled with: ethtool -K rmnet_data0 tx on rx on - Format of the new and old structures were compared, bit by bit, after assigning various values to the fields using both the old and new structure definitions (and access methods). - The patches were all run through sparse. No new errors are reported. (A "no newline at end of file" warning is reported for "rmnet_vnd.c"; and ip_fast_csum() defined in ARM64 "checksum.h" produces a warning.) I've added Reviewed-by from Bjorn to the first five patches, and Reported-by from the kernel test robot on the last one Below is description that was sent with version 1. -Alex This series converts data structures defined in so they use integral field values with bitfield masks rather than rely on C bit-fields. I first proposed doing something like this long ago when my confusion about this code (and the memory layout it was supposed to represent) led me to believe it was erroneous: https://lore.kernel.org/netdev/20190520135354.18628-1-el...@linaro.org/ It came up again recently, when Sharath Chandra Vurukala proposed a new structure in "if_rmnet.h", again using C bit-fields. I asked whether the new structure could use field masks, and Jakub requested that this be done. https://lore.kernel.org/netdev/1613079324-20166-1-git-send-email-shara...@codeaurora.org/ I volunteered to convert the existing RMNet code to use bitfield masks, and that is what I'm doing here. The first three patches are more or less preparation work for the last three. - The first marks two fields in an existing structure explicitly big endian. They are unused by current code, so this should have no impact. - The second simplifies some code that computes the value of a field in a header in a somewhat obfuscated way. - The third eliminates some trivial accessor macros, open-coding them instead. I believe the accessors actually do more harm than good. - The last three convert the structures defined in "if_rmnet.h" so they are defined only with integral fields, each having well-defined byte order. Where sub-fields are needed, field masks are defined so they can be encoded or extracted using functions like be16_get_bits() or u8_encode_bits(), defined in . The three structures converted are, in order: rmnet_map_header, rmnet_map_dl_csum_trailer, and rmnet_map_ul_csum_header. -Alex Alex Elder (6): net: qualcomm: rmnet: mark trailer field endianness net: qualcomm: rmnet: simplify some byte order logic net: qualcomm: rmnet: kill RMNET_MAP_GET_*() accessor macros net: qualcomm: rmnet: use field masks instead of C bit-fields net: qualcomm: rmnet: don't use C bit-fields in rmnet checksum trailer net: qualcomm: rmnet: don't use C bit-fields in rmnet checksum header .../ethernet/qualcomm/rmnet/rmnet_handlers.c | 11 ++-- .../net/ethernet/qualcomm/rmnet/rmnet_map.h | 12 .../qualcomm/rmnet/rmnet_map_command.c| 11 +++- .../ethernet/qualcomm/rmnet/rmnet_map_data.c | 60 - include/linux/if_rmnet.h | 65 +-- 5 files changed, 70 insertions(+), 89 deletions(-) -- 2.27.0
[PATCH net-next v2 1/6] net: qualcomm: rmnet: mark trailer field endianness
The fields in the checksum trailer structure used for QMAP protocol
RX packets are all big-endian format, so define them that way.
It turns out these fields are never actually used by the RMNet code.
The start offset is always assumed to be zero, and the length is
taken from the other packet headers. So making these fields
explicitly big endian has no effect on the behavior of the code.
Signed-off-by: Alex Elder
Reviewed-by: Bjorn Andersson
---
include/linux/if_rmnet.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/if_rmnet.h b/include/linux/if_rmnet.h
index 9661416a9bb47..8c7845baf3837 100644
--- a/include/linux/if_rmnet.h
+++ b/include/linux/if_rmnet.h
@@ -32,8 +32,8 @@ struct rmnet_map_dl_csum_trailer {
#else
#error "Please fix "
#endif
- u16 csum_start_offset;
- u16 csum_length;
+ __be16 csum_start_offset;
+ __be16 csum_length;
__be16 csum_value;
} __aligned(1);
--
2.27.0
Re: [PATCH 2/2] MIPS: Loongson64: Move loongson_system_configuration to loongson.h
On 03/05/2021 06:01 PM, Philippe Mathieu-Daudé wrote: Hi, On Thu, Mar 4, 2021 at 5:35 PM Qing Zhang wrote: The purpose of separating loongson_system_configuration from boot_param.h is to keep the other structure consistent with the firmware. This is supposed to be a trivial patch, but the description actually confuses me. Why is the move out of "boot_param.h" keeping it consistent with fw? Hi, PhilippeMathieu-Daudé Thank you for your reply. The boot_param.h file must be consistent in the kernel and the firmware pmon/cmds/bootparam.h In env.c, the loongson_system_configuration structure member gets the value passed to the firmware. eg: struct boot_params *boot_p; loongson_sysconf.restart_addr = boot_p->reset_system.ResetWarm; loongson_sysconf.poweroff_addr = boot_p->reset_system.Shutdown; loongson_sysconf.suspend_addr = boot_p->reset_system.DoSuspend; The boot_params structure is consistent with the firmware, The loongson_system_configuration is filled in the kernel, and there is no such structure in pmon-loongson3, it is actually defined in the kernel. So, remove its definition from boot_param.h. Thanks, Qing
Re: [PATCH v3 5/7] irqchip/loongson-liointc: irqchip add 2.0 version
Hi, Qing,
On Sat, Mar 6, 2021 at 10:36 AM Qing Zhang wrote:
>
> Add IO interrupt controller support for Loongson 2k1000, different
> from the 3a series is that 2K1000 has 64 interrupt sources, 0-31
> correspond to the device tree liointc0 device node, and the other
> correspond to liointc1 node.
Use the formal name (Loongson-2K1000, Loongson-3A series), please.
Huacai
>
> Signed-off-by: Jiaxun Yang
> Signed-off-by: Qing Zhang
> ---
>
> v2-v3: No change
>
> drivers/irqchip/irq-loongson-liointc.c | 55 +-
> 1 file changed, 46 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/irqchip/irq-loongson-liointc.c
> b/drivers/irqchip/irq-loongson-liointc.c
> index 09b91b81851c..1c3c80f7f9f5 100644
> --- a/drivers/irqchip/irq-loongson-liointc.c
> +++ b/drivers/irqchip/irq-loongson-liointc.c
> @@ -20,6 +20,7 @@
>
> #define LIOINTC_CHIP_IRQ 32
> #define LIOINTC_NUM_PARENT 4
> +#define LIOINTC_NUM_CORES 4
>
> #define LIOINTC_INTC_CHIP_START0x20
>
> @@ -42,6 +43,7 @@ struct liointc_handler_data {
> struct liointc_priv {
> struct irq_chip_generic *gc;
> struct liointc_handler_data handler[LIOINTC_NUM_PARENT];
> + void __iomem*core_isr[LIOINTC_NUM_CORES];
> u8 map_cache[LIOINTC_CHIP_IRQ];
> boolhas_lpc_irq_errata;
> };
> @@ -51,11 +53,12 @@ static void liointc_chained_handle_irq(struct irq_desc
> *desc)
> struct liointc_handler_data *handler =
> irq_desc_get_handler_data(desc);
> struct irq_chip *chip = irq_desc_get_chip(desc);
> struct irq_chip_generic *gc = handler->priv->gc;
> + int core = get_ebase_cpunum() % LIOINTC_NUM_CORES;
> u32 pending;
>
> chained_irq_enter(chip, desc);
>
> - pending = readl(gc->reg_base + LIOINTC_REG_INTC_STATUS);
> + pending = readl(handler->priv->core_isr[core]);
>
> if (!pending) {
> /* Always blame LPC IRQ if we have that bug */
> @@ -141,6 +144,15 @@ static void liointc_resume(struct irq_chip_generic *gc)
> }
>
> static const char * const parent_names[] = {"int0", "int1", "int2", "int3"};
> +static const char * const core_reg_names[] = {"isr0", "isr1", "isr2",
> "isr3"};
> +
> +static void __iomem *liointc_get_reg_byname(struct device_node *node,
> + const char *name)
> +{
> + int index = of_property_match_string(node, "reg-names", name);
> +
> + return of_iomap(node, index);
> +}
>
> static int __init liointc_of_init(struct device_node *node,
> struct device_node *parent)
> @@ -159,10 +171,28 @@ static int __init liointc_of_init(struct device_node
> *node,
> if (!priv)
> return -ENOMEM;
>
> - base = of_iomap(node, 0);
> - if (!base) {
> - err = -ENODEV;
> - goto out_free_priv;
> + if (of_device_is_compatible(node, "loongson,liointc-2.0")) {
> + base = liointc_get_reg_byname(node, "main");
> + if (!base) {
> + err = -ENODEV;
> + goto out_free_priv;
> + }
> + for (i = 0; i < LIOINTC_NUM_CORES; i++) {
> + priv->core_isr[i] =
> + liointc_get_reg_byname(node,
> core_reg_names[i]);
> + }
> + if (!priv->core_isr[0]) {
> + err = -ENODEV;
> + goto out_iounmap_base;
> + }
> + } else {
> + base = of_iomap(node, 0);
> + if (!base) {
> + err = -ENODEV;
> + goto out_free_priv;
> + }
> + for (i = 0; i < LIOINTC_NUM_CORES; i++)
> + priv->core_isr[i] = base + LIOINTC_REG_INTC_STATUS;
> }
>
> for (i = 0; i < LIOINTC_NUM_PARENT; i++) {
> @@ -172,7 +202,7 @@ static int __init liointc_of_init(struct device_node
> *node,
> }
> if (!have_parent) {
> err = -ENODEV;
> - goto out_iounmap;
> + goto out_iounmap_isr;
> }
>
> sz = of_property_read_variable_u32_array(node,
> @@ -183,7 +213,7 @@ static int __init liointc_of_init(struct device_node
> *node,
> if (sz < 4) {
> pr_err("loongson-liointc: No parent_int_map\n");
> err = -ENODEV;
> - goto out_iounmap;
> + goto out_iounmap_isr;
> }
>
> for (i = 0; i < LIOINTC_NUM_PARENT; i++)
> @@ -195,7 +225,7 @@ static int __init liointc_of_init(struct device_node
> *node,
> if (!domain) {
> pr_err("loongson-liointc: cannot add IRQ domain\n");
> err = -EINVAL;
> - goto out_iounmap;
> + goto out_iounmap_isr;
> }
>
> err =
Re: [PATCH v3 4/8] perf cs-etm: Fix bitmap for option
Hi Arnaldo, On Fri, Mar 05, 2021 at 02:29:44PM -0300, Arnaldo Carvalho de Melo wrote: > Em Tue, Feb 09, 2021 at 09:58:55AM +0800, Leo Yan escreveu: > > On Mon, Feb 08, 2021 at 01:46:41PM -0700, Mathieu Poirier wrote: > > > On Sat, Feb 06, 2021 at 11:08:29PM +0800, Leo Yan wrote: > > > > From: Suzuki K Poulose > > > > > > > > When set option with macros ETM_OPT_CTXTID and ETM_OPT_TS, it wrongly > > > > takes these two values (14 and 28 prespectively) as bit masks, but > > > > actually both are the offset for bits. But this doesn't lead to > > > > further failure due to the AND logic operation will be always true for > > > > ETM_OPT_CTXTID / ETM_OPT_TS. > > > > > > > > This patch defines new independent macros (rather than using the > > > > "config" bits) for requesting the "contextid" and "timestamp" for > > > > cs_etm_set_option(). > > > > > > > > [leoy: Extract the change as a separate patch for easier review] > > > > > > This should go just above your name - see below. > > I fixed this up and added this patch to my perf/urgent branch, for > v5.12, since the kernel bits are upstream and this is a fix. Yeah, it makes sense to pick this patch into perf/urgent branch since it's a fixing patch. Actually, this patch has been merged into the tmp.perf/core branch [1], after you move it to the perf/urgent branch, I can confirm all other patches for perf tool in this series have been merged into the tmp.perf/core branch. Thanks, Leo [1] https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git/commit/?h=tmp.perf/core=8c559e8d68630d64d932bada633705f6551427df
Re: [PATCH v10 1/2] scsi: ufs: Enable power management for wlun
On 3/4/2021 7:35 AM, Adrian Hunter wrote:
On 3/03/21 12:52 am, Asutosh Das wrote:
During runtime-suspend of ufs host, the scsi devices are
already suspended and so are the queues associated with them.
But the ufs host sends SSU to wlun during its runtime-suspend.
During the process blk_queue_enter checks if the queue is not in
suspended state. If so, it waits for the queue to resume, and never
comes out of it.
The commit
(d55d15a33: scsi: block: Do not accept any requests while suspended)
adds the check if the queue is in suspended state in blk_queue_enter().
Call trace:
__switch_to+0x174/0x2c4
__schedule+0x478/0x764
schedule+0x9c/0xe0
blk_queue_enter+0x158/0x228
blk_mq_alloc_request+0x40/0xa4
blk_get_request+0x2c/0x70
__scsi_execute+0x60/0x1c4
ufshcd_set_dev_pwr_mode+0x124/0x1e4
ufshcd_suspend+0x208/0x83c
ufshcd_runtime_suspend+0x40/0x154
ufshcd_pltfrm_runtime_suspend+0x14/0x20
pm_generic_runtime_suspend+0x28/0x3c
__rpm_callback+0x80/0x2a4
rpm_suspend+0x308/0x614
rpm_idle+0x158/0x228
pm_runtime_work+0x84/0xac
process_one_work+0x1f0/0x470
worker_thread+0x26c/0x4c8
kthread+0x13c/0x320
ret_from_fork+0x10/0x18
Fix this by registering ufs device wlun as a scsi driver and
registering it for block runtime-pm. Also make this as a
supplier for all other luns. That way, this device wlun
suspends after all the consumers and resumes after
hba resumes.
Co-developed-by: Can Guo
Signed-off-by: Can Guo
Signed-off-by: Asutosh Das
It looks good, but still a few further comments below.
Also, do you think ufshcd_err_handling_prepare()/unprepare()
need changes? And ufshcd_recover_pm_error()?
And maybe ufshcd_auto_hibern8_update() when it is called from ufs_sysfs.c?
Hi Adrian
Sure, I'll fix it in the next version.
Now during my testing I see a weird issue sometimes (1 in 7).
Scenario - bootups
Issue:
The supplier 'ufs_device_wlun 0:0:0:49488' goes into runtime suspend
even when one/more of its consumers are in RPM_ACTIVE state.
*Log:
[ 10.056379][ T206] sd 0:0:0:1: [sdb] Synchronizing SCSI cache
[ 10.062497][ T113] sd 0:0:0:5: [sdf] Synchronizing SCSI cache
[ 10.356600][ T32] sd 0:0:0:7: [sdh] Synchronizing SCSI cache
[ 10.362944][ T174] sd 0:0:0:3: [sdd] Synchronizing SCSI cache
[ 10.696627][ T83] sd 0:0:0:2: [sdc] Synchronizing SCSI cache
[ 10.704562][ T170] sd 0:0:0:6: [sdg] Synchronizing SCSI cache
[ 10.980602][T5] sd 0:0:0:0: [sda] Synchronizing SCSI cache
/** Printing all the consumer nodes of supplier **/
[ 10.987327][T5] ufs_device_wlun 0:0:0:49488: usage-count @
suspend: 0 <-- this is the usage_count
[ 10.994440][T5] ufs_rpmb_wlun 0:0:0:49476: PM state - 2
[ 11.000402][T5] scsi 0:0:0:49456: PM state - 2
[ 11.005453][T5] sd 0:0:0:0: PM state - 2
[ 11.009958][T5] sd 0:0:0:1: PM state - 2
[ 11.014469][T5] sd 0:0:0:2: PM state - 2
[ 11.019072][T5] sd 0:0:0:3: PM state - 2
[ 11.023595][T5] sd 0:0:0:4: PM state - 0 << RPM_ACTIVE
[ 11.353298][T5] sd 0:0:0:5: PM state - 2
[ 11.357726][T5] sd 0:0:0:6: PM state - 2
[ 11.362155][T5] sd 0:0:0:7: PM state - 2
[ 11.366584][T5] ufshcd-qcom 1d84000.ufshc: __ufshcd_wl_suspend - 8709
[ 11.374366][T5] ufs_device_wlun 0:0:0:49488: __ufshcd_wl_suspend
- (0) has rpm_active flags
[ 11.383376][T5] ufs_device_wlun 0:0:0:49488:
ufshcd_wl_runtime_suspend <-- Supplier suspends fine.
[ 12.977318][ T174] sd 0:0:0:4: [sde] Synchronizing SCSI cache
And the the suspend of sde is stuck now:
schedule+0x9c/0xe0
schedule_timeout+0x40/0x128
io_schedule_timeout+0x44/0x68
wait_for_common_io+0x7c/0x100
wait_for_completion_io+0x14/0x20
blk_execute_rq+0x90/0xcc
__scsi_execute+0x104/0x1c4
sd_sync_cache+0xf8/0x2a0
sd_suspend_common+0x74/0x11c
sd_suspend_runtime+0x14/0x20
scsi_runtime_suspend+0x64/0x94
__rpm_callback+0x80/0x2a4
rpm_suspend+0x308/0x614
pm_runtime_work+0x98/0xa8
I added 'DL_FLAG_RPM_ACTIVE' while creating links.
if (hba->sdev_ufs_device) {
link = device_link_add(>sdev_gendev,
>sdev_ufs_device->sdev_gendev,
DL_FLAG_PM_RUNTIME|DL_FLAG_RPM_ACTIVE);
I didn't expect this to resolve the issue anyway and it didn't.
Another interesting point here is when I resume any of the above
suspended consumers, it all goes back to normal, which is kind of
expected. I tried resuming the consumer and the supplier is resumed and
the supplier is suspended when all the consumers are suspended.
Any pointers on this issue please?
@Bart/@Alan - Do you've any pointers please?
Thanks,
AsutoshD
---
drivers/scsi/ufs/cdns-pltfrm.c | 2 +
drivers/scsi/ufs/tc-dwc-g210-pci.c | 2 +
drivers/scsi/ufs/ufs-exynos.c | 2 +
drivers/scsi/ufs/ufs-hisi.c| 2 +
drivers/scsi/ufs/ufs-mediatek.c| 2 +
drivers/scsi/ufs/ufs-qcom.c| 2 +
drivers/scsi/ufs/ufs_bsg.c | 6 +-
drivers/scsi/ufs/ufshcd-pci.c | 32
Re: [RFC PATCH v3 1/3] blk-mq: Clean up references to old requests when freeing rqs
On Fri, Mar 5, 2021 at 7:20 AM John Garry wrote: > > It has been reported many times that a use-after-free can be intermittently > found when iterating busy requests: > > - > https://lore.kernel.org/linux-block/8376443a-ec1b-0cef-8244-ed584b96f...@huawei.com/ > - > https://lore.kernel.org/linux-block/5c3ac5af-ed81-11e4-fee3-f92175f14...@acm.org/T/#m6c1ac11540522716f645d004e2a5a13c9f218908 > - > https://lore.kernel.org/linux-block/04e2f9e8-79fa-f1cb-ab23-4a15bf3f6...@kernel.dk/ > > The issue is that when we switch scheduler or change queue depth, there may > be references in the driver tagset to the stale requests. > > As a solution, clean up any references to those requests in the driver > tagset. This is done with a cmpxchg to make safe any race with setting the > driver tagset request from another queue. I noticed this crash recently when running blktests on a "debug" config on a 4.15 based kernel (it would always crash), and backporting this change fixes it. (testing on linus's latest tree also confirmed the fix, with the same config). I realize I'm late to the conversation, but appreciate the investigation and fixes :) smime.p7s Description: S/MIME Cryptographic Signature
Re: [PATCH] kbuild: rebuild GCC plugins when the compiler is upgraded
On Sat, Mar 06, 2021 at 11:18:31AM +0900, Masahiro Yamada wrote: > On Sat, Mar 6, 2021 at 10:28 AM Josh Poimboeuf wrote: > > > > On Thu, Mar 04, 2021 at 08:25:00PM -0600, Josh Poimboeuf wrote: > > > On Thu, Mar 04, 2021 at 03:37:14PM -0800, Linus Torvalds wrote: > > > > On Thu, Mar 4, 2021 at 3:20 PM Kees Cook wrote: > > > > > > > > > > This seems fine to me, but I want to make sure Josh has somewhere to > > > > > actually go with this. Josh, does this get you any closer? > > > > > > No, this doesn't seem to help me at all. > > > > > > > > It sounds like the plugins need to move to another location for > > > > > packaged kernels? > > > > > > > > Well, it might be worth extending the stuff that gets installed with > > > > /lib/modules// with enough information and > > > > infrastruvcture to then build any external modules. > > > > > > The gcc plugins live in scripts/, which get installed by "make > > > modules_install" already. So the plugins' source and makefiles are in > > > /lib/modules//build/scripts/gcc-plugins. > > > > > > So everything needed for building the plugins is already there. We just > > > need the kernel makefiles to rebuild the plugins locally, when building > > > an external module. > > > > This seems to work with very limited testing... Based on top of > > Masahiro's recent patch: > > > > > > https://lkml.kernel.org/r/cak7lnarhotnz3gavhgnyb4n-wyuboxc10a6zurh1odghxwd...@mail.gmail.com > > Is this a bad coding contest? > > I am not asking you to add ugly ifeq or whatever > hacks to say "this worked for me". > > Please feel free to do this in the fedora kernel, > but do not send it to upstream. > > Sorry, I really do not want to see hacks like this any more. Geez, that's a bit harsh. I never claimed to be a brilliant makefile coder. Do you have any constructive feedback for improving the patch? > Remember, how badly objtool was integrated in the build system, > and you even blocked me from fixing that. I have no idea what you're talking about, nor how it would be relevant to this patch. -- Josh
Re: [PATCH 0/5] Cleanup and fixup for khugepaged
On 2021/3/6 1:40, Kirill A. Shutemov wrote: > On Thu, Mar 04, 2021 at 07:30:08AM -0500, Miaohe Lin wrote: >> Hi all, >> This series contains cleanups to remove unneeded return value, use >> helper function and so on. And there is one fix to correct the wrong >> result value for trace_mm_collapse_huge_page_isolate(). >> >> More details can be found in the respective changelogs. Thanks! >> >> Miaohe Lin (5): >> khugepaged: remove unneeded return value of >> khugepaged_collapse_pte_mapped_thps() >> khugepaged: reuse the smp_wmb() inside __SetPageUptodate() >> khugepaged: use helper khugepaged_test_exit() in __khugepaged_enter() >> khugepaged: remove unnecessary mem_cgroup_uncharge() in >> collapse_[file|huge_page] >> khugepaged: fix wrong result value for >> trace_mm_collapse_huge_page_isolate() >> >> mm/khugepaged.c | 47 --- >> 1 file changed, 20 insertions(+), 27 deletions(-) > > Apart from patch 4/5, looks fine. For the rest, you can use: > > Acked-by: Kirill A. Shutemov Many thanks for review and ack! :) >
[PATCH] bcache: reduce redundant code in bch_cached_dev_run()
In bch_cached_dev_run(), free(env[1])|free(env[2])|free(buf)
show up three times. This patch introduce out tag in
which free(env[1])|free(env[2])|free(buf) are only called
one time. If we need to call free() when errors occur,
we can set error code to ret, and then goto out tag directly.
Signed-off-by: Zhiqiang Liu
---
drivers/md/bcache/super.c | 25 -
1 file changed, 12 insertions(+), 13 deletions(-)
diff --git a/drivers/md/bcache/super.c b/drivers/md/bcache/super.c
index 71691f32959b..1a8748050087 100644
--- a/drivers/md/bcache/super.c
+++ b/drivers/md/bcache/super.c
@@ -1052,6 +1052,7 @@ static int cached_dev_status_update(void *arg)
int bch_cached_dev_run(struct cached_dev *dc)
{
+ int ret = 0;
struct bcache_device *d = >disk;
char *buf = kmemdup_nul(dc->sb.label, SB_LABEL_SIZE, GFP_KERNEL);
char *env[] = {
@@ -1064,19 +1065,15 @@ int bch_cached_dev_run(struct cached_dev *dc)
if (dc->io_disable) {
pr_err("I/O disabled on cached dev %s\n",
dc->backing_dev_name);
- kfree(env[1]);
- kfree(env[2]);
- kfree(buf);
- return -EIO;
+ ret = -EIO;
+ goto out;
}
if (atomic_xchg(>running, 1)) {
- kfree(env[1]);
- kfree(env[2]);
- kfree(buf);
pr_info("cached dev %s is running already\n",
dc->backing_dev_name);
- return -EBUSY;
+ ret = -EBUSY;
+ goto out;
}
if (!d->c &&
@@ -1097,15 +1094,13 @@ int bch_cached_dev_run(struct cached_dev *dc)
* only class / kset properties are persistent
*/
kobject_uevent_env(_to_dev(d->disk)->kobj, KOBJ_CHANGE, env);
- kfree(env[1]);
- kfree(env[2]);
- kfree(buf);
if (sysfs_create_link(>kobj, _to_dev(d->disk)->kobj, "dev") ||
sysfs_create_link(_to_dev(d->disk)->kobj,
>kobj, "bcache")) {
pr_err("Couldn't create bcache dev <-> disk sysfs symlinks\n");
- return -ENOMEM;
+ ret = -ENOMEM;
+ goto out;
}
dc->status_update_thread = kthread_run(cached_dev_status_update,
@@ -1114,7 +1109,11 @@ int bch_cached_dev_run(struct cached_dev *dc)
pr_warn("failed to create bcache_status_update kthread,
continue to run without monitoring backing device status\n");
}
- return 0;
+out:
+ kfree(env[1]);
+ kfree(env[2]);
+ kfree(buf);
+ return ret;
}
/*
--
2.19.1
[PATCH v3 7/7] MIPS: Loongson64: Add a Loongson-2k default config file
Add default config for 2K1000. Signed-off-by: Jiaxun Yang Signed-off-by: Qing Zhang --- v2-v3: No change arch/mips/configs/loongson2k_defconfig | 353 + 1 file changed, 353 insertions(+) create mode 100644 arch/mips/configs/loongson2k_defconfig diff --git a/arch/mips/configs/loongson2k_defconfig b/arch/mips/configs/loongson2k_defconfig new file mode 100644 index ..e948ca487e2d --- /dev/null +++ b/arch/mips/configs/loongson2k_defconfig @@ -0,0 +1,353 @@ +# CONFIG_LOCALVERSION_AUTO is not set +CONFIG_KERNEL_LZMA=y +CONFIG_SYSVIPC=y +CONFIG_POSIX_MQUEUE=y +CONFIG_AUDIT=y +CONFIG_NO_HZ=y +CONFIG_HIGH_RES_TIMERS=y +CONFIG_PREEMPT=y +CONFIG_BSD_PROCESS_ACCT=y +CONFIG_BSD_PROCESS_ACCT_V3=y +CONFIG_TASKSTATS=y +CONFIG_TASK_DELAY_ACCT=y +CONFIG_TASK_XACCT=y +CONFIG_TASK_IO_ACCOUNTING=y +CONFIG_MEMCG=y +CONFIG_BLK_CGROUP=y +CONFIG_SCHED_AUTOGROUP=y +CONFIG_SYSFS_DEPRECATED=y +CONFIG_RELAY=y +CONFIG_BLK_DEV_INITRD=y +CONFIG_EMBEDDED=y +CONFIG_MACH_LOONGSON64=y +# CONFIG_CPU_LOONGSON3_CPUCFG_EMULATION is not set +CONFIG_HZ_256=y +CONFIG_MIPS32_O32=y +CONFIG_MIPS32_N32=y +CONFIG_MODULES=y +CONFIG_MODULE_FORCE_LOAD=y +CONFIG_MODULE_UNLOAD=y +CONFIG_MODULE_FORCE_UNLOAD=y +CONFIG_MODVERSIONS=y +CONFIG_PARTITION_ADVANCED=y +CONFIG_MQ_IOSCHED_DEADLINE=m +CONFIG_IOSCHED_BFQ=y +CONFIG_BFQ_GROUP_IOSCHED=y +CONFIG_BINFMT_MISC=m +CONFIG_KSM=y +CONFIG_NET=y +CONFIG_PACKET=y +CONFIG_UNIX=y +CONFIG_XFRM_USER=y +CONFIG_NET_KEY=y +CONFIG_INET=y +CONFIG_IP_MULTICAST=y +CONFIG_IP_ADVANCED_ROUTER=y +CONFIG_IP_MULTIPLE_TABLES=y +CONFIG_IP_ROUTE_MULTIPATH=y +CONFIG_IP_ROUTE_VERBOSE=y +CONFIG_NETFILTER=y +CONFIG_NETFILTER_NETLINK_LOG=m +CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m +CONFIG_NETFILTER_XT_TARGET_MARK=m +CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m +CONFIG_NETFILTER_XT_MATCH_COMMENT=m +CONFIG_NETFILTER_XT_MATCH_DCCP=m +CONFIG_NETFILTER_XT_MATCH_ESP=m +CONFIG_NETFILTER_XT_MATCH_LENGTH=m +CONFIG_NETFILTER_XT_MATCH_LIMIT=m +CONFIG_NETFILTER_XT_MATCH_MAC=m +CONFIG_NETFILTER_XT_MATCH_MARK=m +CONFIG_NETFILTER_XT_MATCH_MULTIPORT=m +CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m +CONFIG_NETFILTER_XT_MATCH_QUOTA=m +CONFIG_NETFILTER_XT_MATCH_REALM=m +CONFIG_NETFILTER_XT_MATCH_STATISTIC=m +CONFIG_NETFILTER_XT_MATCH_STRING=m +CONFIG_NETFILTER_XT_MATCH_TCPMSS=m +CONFIG_IP_VS=m +CONFIG_IP_NF_IPTABLES=m +CONFIG_IP_NF_MATCH_AH=m +CONFIG_IP_NF_MATCH_ECN=m +CONFIG_IP_NF_MATCH_TTL=m +CONFIG_IP_NF_FILTER=m +CONFIG_IP_NF_TARGET_REJECT=m +CONFIG_IP_NF_MANGLE=m +CONFIG_IP_NF_TARGET_ECN=m +CONFIG_IP_NF_TARGET_TTL=m +CONFIG_IP_NF_RAW=m +CONFIG_IP_NF_ARPTABLES=m +CONFIG_IP_NF_ARPFILTER=m +CONFIG_IP_NF_ARP_MANGLE=m +CONFIG_IP_SCTP=m +CONFIG_L2TP=m +CONFIG_BRIDGE=m +CONFIG_CFG80211=m +CONFIG_CFG80211_WEXT=y +CONFIG_MAC80211=m +CONFIG_RFKILL=m +CONFIG_RFKILL_INPUT=y +CONFIG_PCIEPORTBUS=y +CONFIG_HOTPLUG_PCI_PCIE=y +CONFIG_PCIEASPM_PERFORMANCE=y +CONFIG_HOTPLUG_PCI=y +CONFIG_DEVTMPFS=y +CONFIG_DEVTMPFS_MOUNT=y +CONFIG_MTD=m +CONFIG_BLK_DEV_LOOP=y +CONFIG_BLK_DEV_CRYPTOLOOP=y +CONFIG_BLK_DEV_RAM=y +CONFIG_BLK_DEV_RAM_SIZE=8192 +CONFIG_RAID_ATTRS=m +CONFIG_BLK_DEV_SD=y +CONFIG_BLK_DEV_SR=y +CONFIG_CHR_DEV_SG=y +CONFIG_CHR_DEV_SCH=m +CONFIG_SCSI_CONSTANTS=y +CONFIG_SCSI_LOGGING=y +CONFIG_SCSI_SPI_ATTRS=m +CONFIG_SCSI_FC_ATTRS=m +CONFIG_ISCSI_TCP=m +CONFIG_MEGARAID_NEWGEN=y +CONFIG_MEGARAID_MM=y +CONFIG_MEGARAID_MAILBOX=y +CONFIG_MEGARAID_LEGACY=y +CONFIG_MEGARAID_SAS=y +CONFIG_ATA=y +CONFIG_SATA_AHCI=y +CONFIG_PATA_ATIIXP=y +CONFIG_MD=y +CONFIG_BLK_DEV_MD=m +CONFIG_MD_LINEAR=m +CONFIG_MD_RAID0=m +CONFIG_MD_RAID1=m +CONFIG_MD_RAID10=m +CONFIG_MD_RAID456=m +CONFIG_MD_MULTIPATH=m +CONFIG_BLK_DEV_DM=m +CONFIG_DM_CRYPT=m +CONFIG_DM_SNAPSHOT=m +CONFIG_DM_MIRROR=m +CONFIG_DM_ZERO=m +CONFIG_TARGET_CORE=m +CONFIG_TCM_IBLOCK=m +CONFIG_TCM_FILEIO=m +CONFIG_TCM_PSCSI=m +CONFIG_LOOPBACK_TARGET=m +CONFIG_ISCSI_TARGET=m +CONFIG_NETDEVICES=y +CONFIG_TUN=m +# CONFIG_NET_VENDOR_3COM is not set +# CONFIG_NET_VENDOR_ADAPTEC is not set +# CONFIG_NET_VENDOR_ALTEON is not set +# CONFIG_NET_VENDOR_AMD is not set +# CONFIG_NET_VENDOR_ARC is not set +# CONFIG_NET_VENDOR_ATHEROS is not set +# CONFIG_NET_VENDOR_BROADCOM is not set +# CONFIG_NET_VENDOR_BROCADE is not set +# CONFIG_NET_VENDOR_CHELSIO is not set +# CONFIG_NET_VENDOR_CIRRUS is not set +# CONFIG_NET_VENDOR_CISCO is not set +# CONFIG_NET_VENDOR_DEC is not set +# CONFIG_NET_VENDOR_DLINK is not set +# CONFIG_NET_VENDOR_EMULEX is not set +# CONFIG_NET_VENDOR_I825XX is not set +CONFIG_E1000=y +CONFIG_E1000E=y +CONFIG_IGB=y +CONFIG_IXGB=y +CONFIG_IXGBE=y +# CONFIG_NET_VENDOR_MARVELL is not set +# CONFIG_NET_VENDOR_MELLANOX is not set +# CONFIG_NET_VENDOR_MICREL is not set +# CONFIG_NET_VENDOR_MICROCHIP is not set +# CONFIG_NET_VENDOR_MICROSEMI is not set +# CONFIG_NET_VENDOR_MYRI is not set +# CONFIG_NET_VENDOR_NATSEMI is not set +# CONFIG_NET_VENDOR_NETERION is not set +# CONFIG_NET_VENDOR_NETRONOME is not set +# CONFIG_NET_VENDOR_NI is not set +# CONFIG_NET_VENDOR_NVIDIA is not set +# CONFIG_NET_VENDOR_OKI is
[PATCH v3 4/7] MIPS: Loongson64: Add 2K1000 early_printk_port
Distinguish between 3A series CPU and 2K1000 CPU UART0. Signed-off-by: Jiaxun Yang Signed-off-by: Qing Zhang --- v2-v3: No change arch/mips/loongson64/init.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/mips/loongson64/init.c b/arch/mips/loongson64/init.c index ed280b73bf89..d5a1eddb8202 100644 --- a/arch/mips/loongson64/init.c +++ b/arch/mips/loongson64/init.c @@ -120,7 +120,10 @@ void __init prom_init(void) #endif /* Hardcode to CPU UART 0 */ - setup_8250_early_printk_port(TO_UNCAC(LOONGSON_REG_BASE + 0x1e0), 0, 1024); + if ((read_c0_prid() & PRID_IMP_MASK) == PRID_IMP_LOONGSON_64R) + setup_8250_early_printk_port(TO_UNCAC(LOONGSON_REG_BASE), 0, 1024); + else + setup_8250_early_printk_port(TO_UNCAC(LOONGSON_REG_BASE + 0x1e0), 0, 1024); register_smp_ops(_smp_ops); board_nmi_handler_setup = mips_nmi_setup; -- 2.20.1
[PATCH v3 3/7] MIPS: Loongson64: Add support for the 2K1000 to get cpu_clock_freq
Get the fixed-clock from the CPU0 node of the device tree.
Signed-off-by: Jiaxun Yang
Signed-off-by: Qing Zhang
---
v2-v3: Add error process
arch/mips/loongson64/time.c | 20
1 file changed, 20 insertions(+)
diff --git a/arch/mips/loongson64/time.c b/arch/mips/loongson64/time.c
index 91e842b58365..84f01424c8c0 100644
--- a/arch/mips/loongson64/time.c
+++ b/arch/mips/loongson64/time.c
@@ -11,9 +11,29 @@
#include
#include
+#include
+#include
void __init plat_time_init(void)
{
+ struct clk *clk = NULL;
+ struct device_node *np;
+
+ if (loongson_sysconf.fw_interface != LOONGSON_LEFI) {
+ of_clk_init(NULL);
+
+ np = of_get_cpu_node(0, NULL);
+ if (!np)
+ pr_err("Failed to get CPU node\n");
+
+ clk = of_clk_get(np, 0);
+ if (IS_ERR(clk))
+ pr_err("Failed to get CPU clock: %ld\n", PTR_ERR(clk));
+
+ cpu_clock_freq = clk_get_rate(clk);
+ clk_put(clk);
+ }
+
/* setup mips r4k timer */
mips_hpt_frequency = cpu_clock_freq / 2;
--
2.20.1
[PATCH v3 5/7] irqchip/loongson-liointc: irqchip add 2.0 version
Add IO interrupt controller support for Loongson 2k1000, different
from the 3a series is that 2K1000 has 64 interrupt sources, 0-31
correspond to the device tree liointc0 device node, and the other
correspond to liointc1 node.
Signed-off-by: Jiaxun Yang
Signed-off-by: Qing Zhang
---
v2-v3: No change
drivers/irqchip/irq-loongson-liointc.c | 55 +-
1 file changed, 46 insertions(+), 9 deletions(-)
diff --git a/drivers/irqchip/irq-loongson-liointc.c
b/drivers/irqchip/irq-loongson-liointc.c
index 09b91b81851c..1c3c80f7f9f5 100644
--- a/drivers/irqchip/irq-loongson-liointc.c
+++ b/drivers/irqchip/irq-loongson-liointc.c
@@ -20,6 +20,7 @@
#define LIOINTC_CHIP_IRQ 32
#define LIOINTC_NUM_PARENT 4
+#define LIOINTC_NUM_CORES 4
#define LIOINTC_INTC_CHIP_START0x20
@@ -42,6 +43,7 @@ struct liointc_handler_data {
struct liointc_priv {
struct irq_chip_generic *gc;
struct liointc_handler_data handler[LIOINTC_NUM_PARENT];
+ void __iomem*core_isr[LIOINTC_NUM_CORES];
u8 map_cache[LIOINTC_CHIP_IRQ];
boolhas_lpc_irq_errata;
};
@@ -51,11 +53,12 @@ static void liointc_chained_handle_irq(struct irq_desc
*desc)
struct liointc_handler_data *handler = irq_desc_get_handler_data(desc);
struct irq_chip *chip = irq_desc_get_chip(desc);
struct irq_chip_generic *gc = handler->priv->gc;
+ int core = get_ebase_cpunum() % LIOINTC_NUM_CORES;
u32 pending;
chained_irq_enter(chip, desc);
- pending = readl(gc->reg_base + LIOINTC_REG_INTC_STATUS);
+ pending = readl(handler->priv->core_isr[core]);
if (!pending) {
/* Always blame LPC IRQ if we have that bug */
@@ -141,6 +144,15 @@ static void liointc_resume(struct irq_chip_generic *gc)
}
static const char * const parent_names[] = {"int0", "int1", "int2", "int3"};
+static const char * const core_reg_names[] = {"isr0", "isr1", "isr2", "isr3"};
+
+static void __iomem *liointc_get_reg_byname(struct device_node *node,
+ const char *name)
+{
+ int index = of_property_match_string(node, "reg-names", name);
+
+ return of_iomap(node, index);
+}
static int __init liointc_of_init(struct device_node *node,
struct device_node *parent)
@@ -159,10 +171,28 @@ static int __init liointc_of_init(struct device_node
*node,
if (!priv)
return -ENOMEM;
- base = of_iomap(node, 0);
- if (!base) {
- err = -ENODEV;
- goto out_free_priv;
+ if (of_device_is_compatible(node, "loongson,liointc-2.0")) {
+ base = liointc_get_reg_byname(node, "main");
+ if (!base) {
+ err = -ENODEV;
+ goto out_free_priv;
+ }
+ for (i = 0; i < LIOINTC_NUM_CORES; i++) {
+ priv->core_isr[i] =
+ liointc_get_reg_byname(node, core_reg_names[i]);
+ }
+ if (!priv->core_isr[0]) {
+ err = -ENODEV;
+ goto out_iounmap_base;
+ }
+ } else {
+ base = of_iomap(node, 0);
+ if (!base) {
+ err = -ENODEV;
+ goto out_free_priv;
+ }
+ for (i = 0; i < LIOINTC_NUM_CORES; i++)
+ priv->core_isr[i] = base + LIOINTC_REG_INTC_STATUS;
}
for (i = 0; i < LIOINTC_NUM_PARENT; i++) {
@@ -172,7 +202,7 @@ static int __init liointc_of_init(struct device_node *node,
}
if (!have_parent) {
err = -ENODEV;
- goto out_iounmap;
+ goto out_iounmap_isr;
}
sz = of_property_read_variable_u32_array(node,
@@ -183,7 +213,7 @@ static int __init liointc_of_init(struct device_node *node,
if (sz < 4) {
pr_err("loongson-liointc: No parent_int_map\n");
err = -ENODEV;
- goto out_iounmap;
+ goto out_iounmap_isr;
}
for (i = 0; i < LIOINTC_NUM_PARENT; i++)
@@ -195,7 +225,7 @@ static int __init liointc_of_init(struct device_node *node,
if (!domain) {
pr_err("loongson-liointc: cannot add IRQ domain\n");
err = -EINVAL;
- goto out_iounmap;
+ goto out_iounmap_isr;
}
err = irq_alloc_domain_generic_chips(domain, 32, 1,
@@ -260,7 +290,13 @@ static int __init liointc_of_init(struct device_node *node,
out_free_domain:
irq_domain_remove(domain);
-out_iounmap:
+out_iounmap_isr:
+ for (i = 0; i < LIOINTC_NUM_CORES; i++) {
+ if (!priv->core_isr[i])
+ continue;
+ iounmap(priv->core_isr[i]);
+
[PATCH v3 6/7] dt-bindings: interrupt-controller: Add Loongson-2K1000 LIOINTC
Add liointc-2.0 properties support, so update the maxItems and description. Signed-off-by: Jiaxun Yang Signed-off-by: Qing Zhang --- v2-v3: Fix warnings/errors abount running 'make dt_binding_check' .../bindings/interrupt-controller/loongson,liointc.yaml| 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.yaml b/Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.yaml index f38e0113f360..5280cf60a9a7 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.yaml @@ -10,9 +10,9 @@ maintainers: - Jiaxun Yang description: | - This interrupt controller is found in the Loongson-3 family of chips as the primary - package interrupt controller which can route local I/O interrupt to interrupt lines - of cores. + This interrupt controller is found in the Loongson-3 family of chips and + Loongson-2K1000 chip, as the primary package interrupt controller which + can route local I/O interrupt to interrupt lines of cores. allOf: - $ref: /schemas/interrupt-controller.yaml# @@ -22,6 +22,7 @@ properties: oneOf: - const: loongson,liointc-1.0 - const: loongson,liointc-1.0a + - const: loongson,liointc-2.0 reg: maxItems: 1 -- 2.20.1
[PATCH v3 2/7] MIPS: Loongson64: Distinguish firmware dependencies DTB/LEFI
Add DTB boot support, only support LS2K1000 processor for now,
determine whether to use the built-in DTB or the DTB from the
firmware by checking the range of CKSEG0 and XKPHYS.loongson_fw
_interface will be used in the future.
Signed-off-by: Jiaxun Yang
Signed-off-by: Qing Zhang
---
v2-v3: No change
.../include/asm/mach-loongson64/boot_param.h | 6 ++
arch/mips/include/asm/mach-loongson64/loongson.h | 3 ++-
arch/mips/loongson64/env.c | 13 -
arch/mips/loongson64/init.c | 16 ++--
4 files changed, 34 insertions(+), 4 deletions(-)
diff --git a/arch/mips/include/asm/mach-loongson64/boot_param.h
b/arch/mips/include/asm/mach-loongson64/boot_param.h
index 4592841b6b0c..53c29a305ff0 100644
--- a/arch/mips/include/asm/mach-loongson64/boot_param.h
+++ b/arch/mips/include/asm/mach-loongson64/boot_param.h
@@ -198,7 +198,13 @@ enum loongson_bridge_type {
VIRTUAL = 3
};
+enum loongson_fw_interface {
+ LOONGSON_LEFI = 0,
+ LOONGSON_DTB = 1,
+};
+
struct loongson_system_configuration {
+ enum loongson_fw_interface fw_interface;
u32 nr_cpus;
u32 nr_nodes;
int cores_per_node;
diff --git a/arch/mips/include/asm/mach-loongson64/loongson.h
b/arch/mips/include/asm/mach-loongson64/loongson.h
index ac1c20e172a2..3f885fa26ba6 100644
--- a/arch/mips/include/asm/mach-loongson64/loongson.h
+++ b/arch/mips/include/asm/mach-loongson64/loongson.h
@@ -23,7 +23,8 @@ extern u32 memsize, highmemsize;
extern const struct plat_smp_ops loongson3_smp_ops;
/* loongson-specific command line, env and memory initialization */
-extern void __init prom_init_env(void);
+extern void __init prom_dtb_init_env(void);
+extern void __init prom_lefi_init_env(void);
extern void __init szmem(unsigned int node);
extern void *loongson_fdt_blob;
diff --git a/arch/mips/loongson64/env.c b/arch/mips/loongson64/env.c
index 51a5d050a94c..e7d3a06175e3 100644
--- a/arch/mips/loongson64/env.c
+++ b/arch/mips/loongson64/env.c
@@ -43,7 +43,18 @@ const char *get_system_type(void)
return "Generic Loongson64 System";
}
-void __init prom_init_env(void)
+
+void __init prom_dtb_init_env(void)
+{
+ if ((fw_arg2 < CKSEG0 || fw_arg2 > CKSEG1)
+ && (fw_arg2 < XKPHYS || fw_arg2 > XKSEG))
+
+ loongson_fdt_blob = __dtb_loongson64_2core_2k1000_begin;
+ else
+ loongson_fdt_blob = (void *)fw_arg2;
+}
+
+void __init prom_lefi_init_env(void)
{
struct boot_params *boot_p;
struct loongson_params *loongson_p;
diff --git a/arch/mips/loongson64/init.c b/arch/mips/loongson64/init.c
index cfa788bca871..ed280b73bf89 100644
--- a/arch/mips/loongson64/init.c
+++ b/arch/mips/loongson64/init.c
@@ -52,6 +52,10 @@ void __init szmem(unsigned int node)
static unsigned long num_physpages;
u64 node_id, node_psize, start_pfn, end_pfn, mem_start, mem_size;
+ /* Otherwise come from DTB */
+ if (loongson_sysconf.fw_interface != LOONGSON_LEFI)
+ return;
+
/* Parse memory information and activate */
for (i = 0; i < loongson_memmap->nr_map; i++) {
node_id = loongson_memmap->map[i].node_id;
@@ -94,12 +98,20 @@ static void __init prom_init_memory(void)
void __init prom_init(void)
{
fw_init_cmdline();
- prom_init_env();
+
+ if (fw_arg2 == 0 || (fdt_magic(fw_arg2) == FDT_MAGIC)) {
+ loongson_sysconf.fw_interface = LOONGSON_DTB;
+ prom_dtb_init_env();
+ } else {
+ loongson_sysconf.fw_interface = LOONGSON_LEFI;
+ prom_lefi_init_env();
+ }
/* init base address of io space */
set_io_port_base(PCI_IOBASE);
- loongson_sysconf.early_config();
+ if (loongson_sysconf.early_config)
+ loongson_sysconf.early_config();
#ifdef CONFIG_NUMA
prom_init_numa_memory();
--
2.20.1
[PATCH v3 0/7] Add basic support for Loongson-2K1000
These patches support single-core DTS boot to the serial port login interface, which can be operated using conventional commands. I have successfully tested it on the Loongson 2K1000 machine. pmon: http://cgit.loongnix.org/cgit/pmon-loongson3/ Qing Zhang (7): MIPS: Loongson64: DeviceTree for 2K1000 MIPS: Loongson64: Distinguish firmware dependencies DTB/LEFI MIPS: Loongson64: Add support for the 2K1000 to get cpu_clock_freq MIPS: Loongson64: Add 2K1000 early_printk_port irqchip/loongson-liointc: irqchip add 2.0 version dt-bindings: interrupt-controller: Add Loongson-2K1000 LIOINTC MIPS: Loongson64: Add a Loongson-2k default config file .../loongson,liointc.yaml | 7 +- arch/mips/boot/dts/loongson/Makefile | 1 + .../boot/dts/loongson/loongson64-2k1000.dtsi | 243 .../dts/loongson/loongson64_2core_2k1000.dts | 10 + arch/mips/configs/loongson2k_defconfig| 353 ++ .../include/asm/mach-loongson64/boot_param.h | 6 + .../asm/mach-loongson64/builtin_dtbs.h| 1 + .../include/asm/mach-loongson64/loongson.h| 3 +- arch/mips/loongson64/env.c| 13 +- arch/mips/loongson64/init.c | 21 +- arch/mips/loongson64/time.c | 20 + drivers/irqchip/irq-loongson-liointc.c| 55 ++- 12 files changed, 716 insertions(+), 17 deletions(-) create mode 100644 arch/mips/boot/dts/loongson/loongson64-2k1000.dtsi create mode 100644 arch/mips/boot/dts/loongson/loongson64_2core_2k1000.dts create mode 100644 arch/mips/configs/loongson2k_defconfig -- 2.20.1
[PATCH v3 1/7] MIPS: Loongson64: DeviceTree for 2K1000
Add DeviceTree files for Loongson 2K1000 processor,currently only
supports single-core boot.
Signed-off-by: Jiaxun Yang
Signed-off-by: Qing Zhang
---
v2-v3: No changes
arch/mips/boot/dts/loongson/Makefile | 1 +
.../boot/dts/loongson/loongson64-2k1000.dtsi | 243 ++
.../dts/loongson/loongson64_2core_2k1000.dts | 10 +
.../asm/mach-loongson64/builtin_dtbs.h| 1 +
4 files changed, 255 insertions(+)
create mode 100644 arch/mips/boot/dts/loongson/loongson64-2k1000.dtsi
create mode 100644 arch/mips/boot/dts/loongson/loongson64_2core_2k1000.dts
diff --git a/arch/mips/boot/dts/loongson/Makefile
b/arch/mips/boot/dts/loongson/Makefile
index 8fd0efb37423..72267bfda9b4 100644
--- a/arch/mips/boot/dts/loongson/Makefile
+++ b/arch/mips/boot/dts/loongson/Makefile
@@ -1,4 +1,5 @@
# SPDX_License_Identifier: GPL_2.0
+dtb-$(CONFIG_MACH_LOONGSON64) += loongson64_2core_2k1000.dtb
dtb-$(CONFIG_MACH_LOONGSON64) += loongson64c_4core_ls7a.dtb
dtb-$(CONFIG_MACH_LOONGSON64) += loongson64c_4core_rs780e.dtb
dtb-$(CONFIG_MACH_LOONGSON64) += loongson64c_8core_rs780e.dtb
diff --git a/arch/mips/boot/dts/loongson/loongson64-2k1000.dtsi
b/arch/mips/boot/dts/loongson/loongson64-2k1000.dtsi
new file mode 100644
index ..fd0e99bfe57b
--- /dev/null
+++ b/arch/mips/boot/dts/loongson/loongson64-2k1000.dtsi
@@ -0,0 +1,243 @@
+// SPDX-License-Identifier: GPL-3.0
+
+/dts-v1/;
+
+#include
+
+/ {
+ compatible = "loongson,loongson2k1000";
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "loongson,gs264";
+ reg = <0x0>;
+ #clock-cells = <1>;
+ clocks = <_clk>;
+ };
+ };
+
+ memory {
+ compatible = "memory";
+ device_type = "memory";
+ reg = <0x 0x0020 0x 0x0ee0>, /* 238 MB
at 2 MB */
+ <0x 0x2000 0x 0x1f00>, /* 496
MB at 512 MB */
+ <0x0001 0x1000 0x0001 0xb000>; /* 6912
MB at 4352MB */
+ };
+
+ cpu_clk: cpu_clk {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <8>;
+ };
+
+ cpuintc: interrupt-controller {
+ #address-cells = <0>;
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ compatible = "mti,cpu-interrupt-controller";
+ };
+
+ package0: bus@1000 {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges = <0 0x1000 0 0x1000 0 0x1000 /* ioports */
+ 0 0x4000 0 0x4000 0 0x4000
+ 0xfe 0x 0xfe 0x 0 0x4000>;
+
+ liointc0: interrupt-controller@1fe11400 {
+ compatible = "loongson,liointc-2.0";
+ reg = <0 0x1fe11400 0 0x40>,
+ <0 0x1fe11040 0 0x8>,
+ <0 0x1fe11140 0 0x8>;
+ reg-names = "main", "isr0", "isr1";
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ interrupt-parent = <>;
+ interrupts = <2>;
+ interrupt-names = "int0";
+
+ loongson,parent_int_map = <0x>, /* int0 */
+ <0x>, /* int1 */
+ <0x>, /* int2 */
+ <0x>; /* int3 */
+ };
+
+ liointc1: interrupt-controller@1fe11440 {
+ compatible = "loongson,liointc-2.0";
+ reg = <0 0x1fe11440 0 0x40>,
+ <0 0x1fe11048 0 0x8>,
+ <0 0x1fe11148 0 0x8>;
+ reg-names = "main", "isr0", "isr1";
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ interrupt-parent = <>;
+ interrupts = <3>;
+ interrupt-names = "int1";
+
+ loongson,parent_int_map = <0x>, /* int0 */
+ <0x>, /* int1 */
+ <0x>, /* int2 */
+ <0x>; /* int3 */
+ };
+
+ uart0: serial@1fe0 {
+ compatible = "ns16550a";
+ reg = <0
RE: [PATCH v2] eeprom/optoe: driver to read/write SFP/QSFP/CMIS EEPROMS
On Fri, 5 Mar 2021 2:55 PM -0800 Jakub Kicinski wrote: > On Fri, 5 Mar 2021 11:07:08 -0800 Don Bollinger wrote: > > Acknowledging your objections, I nonetheless request that optoe be > > accepted into upstream as an eeprom driver in drivers/misc/eeprom. It > > is a legitimate driver, with a legitimate user community, which > > deserves the benefits of being managed as a legitimate part of the linux > kernel. > > It's in the best interest of the community to standardize on how we expect > things to operate. You're free to do whatever you want in your proprietary > systems but please don't expect us to accept a parallel, in now way superior > method of accessing SFPs. These are not proprietary systems. The Network Operating Systems that use optoe are open source projects, Linux based, available on github, and contributing to the Linux source (see for example https://github.com/Azure/SONiC). The switches that these NOSs run on are open spec systems (https://www.opencompute.org/wiki/Networking/SpecsAndDesigns). The fact that they use the SDK from the switch silicon vendor should not mean they are banished from the Linux community. I am proposing acceptance of a commonly used implementation for accessing SFPs because the one used by the netdev/netlink community does not fit the architecture of the white box NOS/switch community. I am not trying to pick sides, I am trying to make optoe available to both communities, to improve EEPROM access for both of them. Don
[PATCH v3 0/7] Add basic support for Loongson-2K1000
These patches support single-core DTS boot to the serial port login interface, which can be operated using conventional commands. I have successfully tested it on the Loongson 2K1000 machine. pmon: http://cgit.loongnix.org/cgit/pmon-loongson3/ Qing Zhang (7): MIPS: Loongson64: DeviceTree for 2K1000 MIPS: Loongson64: Distinguish firmware dependencies DTB/LEFI MIPS: Loongson64: Add support for the 2K1000 to get cpu_clock_freq MIPS: Loongson64: Add 2K1000 early_printk_port irqchip/loongson-liointc: irqchip add 2.0 version dt-bindings: interrupt-controller: Add Loongson-2K1000 LIOINTC MIPS: Loongson64: Add a Loongson-2k default config file .../loongson,liointc.yaml | 7 +- arch/mips/boot/dts/loongson/Makefile | 1 + .../boot/dts/loongson/loongson64-2k1000.dtsi | 243 .../dts/loongson/loongson64_2core_2k1000.dts | 10 + arch/mips/configs/loongson2k_defconfig| 353 ++ .../include/asm/mach-loongson64/boot_param.h | 6 + .../asm/mach-loongson64/builtin_dtbs.h| 1 + .../include/asm/mach-loongson64/loongson.h| 3 +- arch/mips/loongson64/env.c| 13 +- arch/mips/loongson64/init.c | 21 +- arch/mips/loongson64/time.c | 20 + drivers/irqchip/irq-loongson-liointc.c| 55 ++- 12 files changed, 716 insertions(+), 17 deletions(-) create mode 100644 arch/mips/boot/dts/loongson/loongson64-2k1000.dtsi create mode 100644 arch/mips/boot/dts/loongson/loongson64_2core_2k1000.dts create mode 100644 arch/mips/configs/loongson2k_defconfig -- 2.20.1
[PATCH 1/2] zram: fix crashes due to use of cpu hotplug multistate
The zram driver makes use of cpu hotplug multistate support,
whereby it associates a zram compression stream per CPU. To
support CPU hotplug multistate a callback enabled to allow
the driver to do what it needs when a CPU hotplugs.
It is however currently possible to end up removing the
zram driver callback prior to removing the zram compression
streams per CPU. This would leave these compression streams
hanging.
We need to fix ordering for driver load / removal, zram
device additions, in light of the driver's use of cpu
hotplug multistate. Since the zram driver exposes many
sysfs attribute which can also muck with the comrpession
streams this also means we can hit page faults today easily.
Fix all this by providing an zram initialization boolean
protected the shared in the driver zram_index_mutex,
which we can use to annotate when sysfs attributes are
safe to use or not -- once the driver is properly initialized.
When the driver is going down we also are sure to not let
userspace muck with attributes which may affect zram cpu
compression streams.
This also fixes a series of possible memory leaks. The
crashes and memory leaks can easily be caused by issuing
the zram02.sh script from the LTP project [0] in a loop
in two separate windows:
cd testcases/kernel/device-drivers/zram
while true; do PATH=$PATH:$PWD:$PWD/../../../lib/ ./zram02.sh; done
You end up with a splat as follows:
kernel: zram: Removed device: zram0
kernel: zram: Added device: zram0
kernel: zram0: detected capacity change from 0 to 209715200
kernel: Adding 104857596k swap on /dev/zram0. Priority:-2 extents:1
across:104857596k SSFS
kernel: zram0: detected capacitky change from 209715200 to 0
kernel: zram0: detected capacity change from 0 to 209715200
kernel: [ cut here ]
kernel: Error: Removing state 63 which has instances left.
kernel: WARNING: CPU: 7 PID: 70457 at kernel/cpu.c:2069
__cpuhp_remove_state_cpuslocked+0xf9/0x100
kernel: Modules linked in: zram(E-) zsmalloc(E)
kernel: CPU: 7 PID: 70457 Comm: rmmod Tainted: GE
5.12.0-rc1-next-20210304 #3
kernel: Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2
04/01/2014
kernel: RIP: 0010:__cpuhp_remove_state_cpuslocked+0xf9/0x100
kernel: Code:
kernel: RSP: 0018:a800c139be98 EFLAGS: 00010282
kernel: RAX: RBX: 9083db58 RCX: 9609f7dd86d8
kernel: RDX: ffd8 RSI: 0027 RDI: 9609f7dd86d0
kernel: RBP: i R08: R09: a800c139bcb8
kernel: R10: a800c139bcb0 R11: 908bea40 R12: 003f
kernel: R13: 09d8 R14: R15:
kernel: FS: 7f1b075a7540() GS:9609f7dc()
knlGS:
kernel: CS: 0010 DS: ES CR0: 80050033
kernel: CR2: 7f1b07610490 CR3: 0001bd04e000 CR4: 00350ee0
kernel: Call Trace:
kernel: __cpuhp_remove_state+0x2e/0x80
kernel: __do_sys_delete_module+0x190/0x2a0
kernel: do_syscall_64+0x33/0x80
kernel: entry_SYSCALL_64_after_hwframe+0x44/0xae
The "Error: Removing state 63 which has instances left" refers
to the zram per CPU compression streams still left.
[0] https://github.com/linux-test-project/ltp.git
Signed-off-by: Luis Chamberlain
---
drivers/block/zram/zram_drv.c | 63 ++-
1 file changed, 55 insertions(+), 8 deletions(-)
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index a711a2e2a794..63b6119cee93 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -44,6 +44,8 @@ static DEFINE_MUTEX(zram_index_mutex);
static int zram_major;
static const char *default_compressor = CONFIG_ZRAM_DEF_COMP;
+bool zram_up;
+
/* Module params (documentation at end) */
static unsigned int num_devices = 1;
/*
@@ -1699,6 +1701,7 @@ static void zram_reset_device(struct zram *zram)
comp = zram->comp;
disksize = zram->disksize;
zram->disksize = 0;
+ zram->comp = NULL;
set_capacity_and_notify(zram->disk, 0);
part_stat_set_all(zram->disk->part0, 0);
@@ -1719,9 +1722,18 @@ static ssize_t disksize_store(struct device *dev,
struct zram *zram = dev_to_zram(dev);
int err;
+ mutex_lock(_index_mutex);
+
+ if (!zram_up) {
+ err = -ENODEV;
+ goto out;
+ }
+
disksize = memparse(buf, NULL);
- if (!disksize)
- return -EINVAL;
+ if (!disksize) {
+ err = -EINVAL;
+ goto out;
+ }
down_write(>init_lock);
if (init_done(zram)) {
@@ -1749,12 +1761,16 @@ static ssize_t disksize_store(struct device *dev,
set_capacity_and_notify(zram->disk, zram->disksize >> SECTOR_SHIFT);
up_write(>init_lock);
+ mutex_unlock(_index_mutex);
+
return len;
out_free_meta:
zram_meta_free(zram, disksize);
out_unlock:
[PATCH 0/2] zram: fix few ltp zram02.sh crashes
LTP's zram02.sh script can be used to crah your kernel pretty badly. cd testcases/kernel/device-drivers/zram while true; do PATH=$PATH:$PWD:$PWD/../../../lib/ ./zram02.sh; done This won't do much, however if you run this in two separate windows you'll see the kernel become unhappy quite fast. The crux of this issue was mishandling of cpu hotplug multistate on the zram driver in consideration for driver unload. However there was still another long lasting bug present: races with sysfs attributes and driver unload. This series fixes these issues. [0] https://github.com/linux-test-project/ltp.git Luis Chamberlain (2): zram: fix crashes due to use of cpu hotplug multistate zram: fix races of sysfs attribute removal and usage drivers/block/zram/zram_drv.c | 82 +++ 1 file changed, 74 insertions(+), 8 deletions(-) -- 2.30.1
[PATCH 2/2] zram: fix races of sysfs attribute removal and usage
When we have sysfs attributes which muck with the driver
heavily we me end up with situations where the core
kernel driver removal call races with usage of a sysfs
attribute. The can happen when for instance a lock is
used on the sysfs attribute which is also used for
driver removal.
To fix this we just *try* to get a refcount to the
module prior to mucking with a sysfs attribute. If this
fails we just give up right away. Ideally we'd want
a generic solution, however this requires a bit more
work. If we tried to generalize this on the block layer
the closest we get is the disk->fops->owner, however
zram is an example driver where the disk->fops is
actually even changed *after* module load, and so the
original disk->fops->owner can be dynamic. In zram's
case the fops->owner is the same, however we have no
semantics to ensure this is the case for all block
drivers.
Using these two lines in two separate terminals can easily
reproduce this hang:
Loop 1 on one terminal:
while true;
do modprobe zram;
modprobe -r zram;
done
Loop 2 on a second terminal:
while true; do
echo 1024 > /sys/block/zram0/disksize;
echo 1 > /sys/block/zram0/reset;
done
The splat which follows is comes up without this patch.
INFO: task bash:888 blocked for more than 120 seconds.
Tainted: GE 5.12.0-rc1-next-20210304+ #4
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:bashstate:D stack:0 pid: 888 ppid: 887 flags:0x0004
Call Trace:
__schedule+0x2e4/0x900
schedule+0x46/0xb0
schedule_preempt_disabled+0xa/0x10
__mutex_lock.constprop.0+0x2c3/0x490
? _kstrtoull+0x35/0xd0
reset_store+0x6c/0x160 [zram]
kernfs_fop_write_iter+0x124/0x1b0
new_sync_write+0x11c/0x1b0
vfs_write+0x1c2/0x260
ksys_write+0x5f/0xe0
do_syscall_64+0x33/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f34f2c3df33
RSP: 002b:7ffe751df6e8 EFLAGS: 0246 ORIG_RAX: 0001
RAX: ffda RBX: 0002 RCX: 7f34f2c3df33
RDX: 0002 RSI: 561ccb06ec10 RDI: 0001
RBP: 561ccb06ec10 R08: 000a R09: 0001
R10: 561ccb157590 R11: 0246 R12: 0002
R13: 7f34f2d0e6a0 R14: 0002 R15: 7f34f2d0e8a0
INFO: task modprobe:1104 can't die for more than 120 seconds.
task:modprobestate:D stack:0 pid: 1104 ppid: 916 flags:0x4004
Call Trace:
__schedule+0x2e4/0x900
schedule+0x46/0xb0
__kernfs_remove.part.0+0x228/0x2b0
? finish_wait+0x80/0x80
kernfs_remove_by_name_ns+0x50/0x90
remove_files+0x2b/0x60
sysfs_remove_group+0x38/0x80
sysfs_remove_groups+0x29/0x40
device_remove_attrs+0x4a/0x80
device_del+0x183/0x3e0
? mutex_lock+0xe/0x30
del_gendisk+0x27a/0x2d0
zram_remove+0x8a/0xb0 [zram]
? hot_remove_store+0xf0/0xf0 [zram]
zram_remove_cb+0xd/0x10 [zram]
idr_for_each+0x5e/0xd0
destroy_devices+0x39/0x6f [zram]
__do_sys_delete_module+0x190/0x2a0
do_syscall_64+0x33/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f32adf727d7
RSP: 002b:7ffc08bb38a8 EFLAGS: 0206 ORIG_RAX: 00b0
RAX: ffda RBX: 55eea23cbb10 RCX: 7f32adf727d7
RDX: RSI: 0800 RDI: 55eea23cbb78
RBP: 55eea23cbb10 R08: R09:
R10: 7f32adfe5ac0 R11: 0206 R12: 55eea23cbb78
R13: R14: R15: 55eea23cbc20
Signed-off-by: Luis Chamberlain
---
drivers/block/zram/zram_drv.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 63b6119cee93..ce54f4bf5a5b 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -1722,6 +1722,9 @@ static ssize_t disksize_store(struct device *dev,
struct zram *zram = dev_to_zram(dev);
int err;
+ if (!try_module_get(THIS_MODULE))
+ return -ENODEV;
+
mutex_lock(_index_mutex);
if (!zram_up) {
@@ -1762,6 +1765,7 @@ static ssize_t disksize_store(struct device *dev,
up_write(>init_lock);
mutex_unlock(_index_mutex);
+ module_put(THIS_MODULE);
return len;
@@ -1771,6 +1775,7 @@ static ssize_t disksize_store(struct device *dev,
up_write(>init_lock);
out:
mutex_unlock(_index_mutex);
+ module_put(THIS_MODULE);
return err;
}
@@ -1786,6 +1791,9 @@ static ssize_t reset_store(struct device *dev,
if (ret)
return ret;
+ if (!try_module_get(THIS_MODULE))
+ return -ENODEV;
+
mutex_lock(_index_mutex);
if (!zram_up) {
@@ -1823,6 +1831,7 @@ static ssize_t reset_store(struct device *dev,
out:
mutex_unlock(_index_mutex);
+ module_put(THIS_MODULE);
return len;
}
@@ -2043,13 +2052,19 @@ static ssize_t hot_add_show(struct class *class,
{
int ret;
+
Re: [PATCH] kbuild: rebuild GCC plugins when the compiler is upgraded
On Sat, Mar 6, 2021 at 10:28 AM Josh Poimboeuf wrote: > > On Thu, Mar 04, 2021 at 08:25:00PM -0600, Josh Poimboeuf wrote: > > On Thu, Mar 04, 2021 at 03:37:14PM -0800, Linus Torvalds wrote: > > > On Thu, Mar 4, 2021 at 3:20 PM Kees Cook wrote: > > > > > > > > This seems fine to me, but I want to make sure Josh has somewhere to > > > > actually go with this. Josh, does this get you any closer? > > > > No, this doesn't seem to help me at all. > > > > > > It sounds like the plugins need to move to another location for > > > > packaged kernels? > > > > > > Well, it might be worth extending the stuff that gets installed with > > > /lib/modules// with enough information and > > > infrastruvcture to then build any external modules. > > > > The gcc plugins live in scripts/, which get installed by "make > > modules_install" already. So the plugins' source and makefiles are in > > /lib/modules//build/scripts/gcc-plugins. > > > > So everything needed for building the plugins is already there. We just > > need the kernel makefiles to rebuild the plugins locally, when building > > an external module. > > This seems to work with very limited testing... Based on top of > Masahiro's recent patch: > > > https://lkml.kernel.org/r/cak7lnarhotnz3gavhgnyb4n-wyuboxc10a6zurh1odghxwd...@mail.gmail.com Is this a bad coding contest? I am not asking you to add ugly ifeq or whatever hacks to say "this worked for me". Please feel free to do this in the fedora kernel, but do not send it to upstream. Sorry, I really do not want to see hacks like this any more. Remember, how badly objtool was integrated in the build system, and you even blocked me from fixing that. > From: Josh Poimboeuf > Subject: [PATCH] gcc-plugins: Rebuild plugins in external module directory > > When building external kernel modules, the build system doesn't require > the GCC version to match the version used to build the original kernel. > > In fact, most distros release the compiler and the kernel in separate > packages, with separate release cadences. So it's not uncommon for > mismatches to occur. > > But with GCC plugins enabled, that's no longer allowed: > > cc1: error: incompatible gcc/plugin versions > cc1: error: failed to initialize plugin > ./scripts/gcc-plugins/structleak_plugin.so > > That error comes from the plugin's call to > plugin_default_version_check(), which strictly enforces the GCC version. > The strict check makes sense, because there's nothing to prevent the GCC > plugin ABI from changing, and it often does. > > Since plugins are tightly tied to the compiler version, just rebuild > them locally in the external module directory, and then use the local > version in the external module build. > > Reported-by: Ondrej Mosnacek > Signed-off-by: Josh Poimboeuf > --- > Makefile | 1 + > scripts/Makefile.gcc-plugins | 2 +- > scripts/gcc-plugins/Makefile | 8 ++-- > 3 files changed, 8 insertions(+), 3 deletions(-) > > diff --git a/Makefile b/Makefile > index bc208886fcce..90c6656de224 100644 > --- a/Makefile > +++ b/Makefile > @@ -1784,6 +1784,7 @@ prepare: > echo " The kernel was built by: "$(CONFIG_CC_VERSION_TEXT); \ > echo " You are using: $(CC_VERSION_TEXT)"; \ > fi > + $(Q)$(MAKE) $(build)=scripts/gcc-plugins > > PHONY += help > help: > diff --git a/scripts/Makefile.gcc-plugins b/scripts/Makefile.gcc-plugins > index 952e46876329..be4303678942 100644 > --- a/scripts/Makefile.gcc-plugins > +++ b/scripts/Makefile.gcc-plugins > @@ -48,7 +48,7 @@ export DISABLE_ARM_SSP_PER_TASK_PLUGIN > > # All the plugin CFLAGS are collected here in case a build target needs to > # filter them out of the KBUILD_CFLAGS. > -GCC_PLUGINS_CFLAGS := $(strip $(addprefix > -fplugin=$(objtree)/scripts/gcc-plugins/, $(gcc-plugin-y)) > $(gcc-plugin-cflags-y)) > +GCC_PLUGINS_CFLAGS := $(strip $(addprefix -fplugin=$(if > $(KBUILD_EXTMOD),$(KBUILD_EXTMOD),$(objtree))/scripts/gcc-plugins/, > $(gcc-plugin-y)) $(gcc-plugin-cflags-y)) > # The sancov_plugin.so is included via CFLAGS_KCOV, so it is removed here. > GCC_PLUGINS_CFLAGS := $(filter-out %/sancov_plugin.so, $(GCC_PLUGINS_CFLAGS)) > export GCC_PLUGINS_CFLAGS > diff --git a/scripts/gcc-plugins/Makefile b/scripts/gcc-plugins/Makefile > index b5487cce69e8..9f8e2ef3ab56 100644 > --- a/scripts/gcc-plugins/Makefile > +++ b/scripts/gcc-plugins/Makefile > @@ -1,10 +1,14 @@ > # SPDX-License-Identifier: GPL-2.0 > > -$(obj)/randomize_layout_plugin.so: $(objtree)/$(obj)/randomize_layout_seed.h > +ifneq ($(KBUILD_EXTMOD),) > +override obj := $(KBUILD_EXTMOD)/$(obj) > +endif > + > +$(obj)/randomize_layout_plugin.so: $(objtree)/$(src)/randomize_layout_seed.h > quiet_cmd_create_randomize_layout_seed = GENSEED $@ > cmd_create_randomize_layout_seed = \ >$(CONFIG_SHELL) $(srctree)/$(src)/gen-random-seed.sh $@ > $(objtree)/include/generated/randomize_layout_hash.h > -$(objtree)/$(obj)/randomize_layout_seed.h:
[PATCH] arm64: defconfig: Enable Qualcomm SM8350 TLMM and GCC
Enable the Qualcomm SM8350 TLMM pinctrl and GCC clock drivers. They need to be builtin to ensure that the UART is allowed to probe before user space needs a console. Signed-off-by: Bjorn Andersson --- arch/arm64/configs/defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index d612f633b771..029edddb50df 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -510,6 +510,7 @@ CONFIG_PINCTRL_SC7180=y CONFIG_PINCTRL_SDM845=y CONFIG_PINCTRL_SM8150=y CONFIG_PINCTRL_SM8250=y +CONFIG_PINCTRL_SM8350=y CONFIG_PINCTRL_LPASS_LPI=m CONFIG_GPIO_ALTERA=m CONFIG_GPIO_DAVINCI=y @@ -957,6 +958,7 @@ CONFIG_SDM_VIDEOCC_845=y CONFIG_SDM_DISPCC_845=y CONFIG_SM_GCC_8150=y CONFIG_SM_GCC_8250=y +CONFIG_SM_GCC_8350=y CONFIG_SM_GPUCC_8150=y CONFIG_SM_GPUCC_8250=y CONFIG_SM_DISPCC_8250=y -- 2.29.2
[PATCH] arm64: dts: qcom: Introduce SM8350 HDK
Add initial DTS for the Snapdragon 888 Mobile Hardware Development Kit,
aka SM8350 HDK. This initial version describes debug UART, UFS storage,
the three USB connectors and remoteprocs.
Signed-off-by: Bjorn Andersson
---
arch/arm64/boot/dts/qcom/Makefile | 1 +
arch/arm64/boot/dts/qcom/sm8350-hdk.dts | 315
2 files changed, 316 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/sm8350-hdk.dts
diff --git a/arch/arm64/boot/dts/qcom/Makefile
b/arch/arm64/boot/dts/qcom/Makefile
index 549a7a2151d4..aa40ff8bf025 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -59,4 +59,5 @@ dtb-$(CONFIG_ARCH_QCOM) += sm8150-hdk.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sm8150-mtp.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sm8250-hdk.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sm8250-mtp.dtb
+dtb-$(CONFIG_ARCH_QCOM)+= sm8350-hdk.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sm8350-mtp.dtb
diff --git a/arch/arm64/boot/dts/qcom/sm8350-hdk.dts
b/arch/arm64/boot/dts/qcom/sm8350-hdk.dts
new file mode 100644
index ..ab79d77fadf4
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sm8350-hdk.dts
@@ -0,0 +1,315 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2020-2021, Linaro Limited
+ */
+
+/dts-v1/;
+
+#include
+#include
+#include "sm8350.dtsi"
+
+/ {
+ model = "Qualcomm Technologies, Inc. SM8350 HDK";
+ compatible = "qcom,sm8350-hdk", "qcom,sm8350";
+
+ aliases {
+ serial0 =
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ vph_pwr: vph-pwr-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vph_pwr";
+ regulator-min-microvolt = <370>;
+ regulator-max-microvolt = <370>;
+
+ regulator-always-on;
+ regulator-boot-on;
+ };
+};
+
+ {
+ status = "okay";
+ firmware-name = "qcom/sm8350/adsp.mbn";
+};
+
+_rsc {
+ pm8350-rpmh-regulators {
+ compatible = "qcom,pm8350-rpmh-regulators";
+ qcom,pmic-id = "b";
+
+ vdd-s1-supply = <_pwr>;
+ vdd-s2-supply = <_pwr>;
+ vdd-s3-supply = <_pwr>;
+ vdd-s4-supply = <_pwr>;
+ vdd-s5-supply = <_pwr>;
+ vdd-s6-supply = <_pwr>;
+ vdd-s7-supply = <_pwr>;
+ vdd-s8-supply = <_pwr>;
+ vdd-s9-supply = <_pwr>;
+ vdd-s10-supply = <_pwr>;
+ vdd-s11-supply = <_pwr>;
+ vdd-s12-supply = <_pwr>;
+
+ vdd-l1-l4-supply = <_s11b_0p95>;
+ vdd-l2-l7-supply = <_bob>;
+ vdd-l3-l5-supply = <_bob>;
+ vdd-l6-l9-l10-supply = <_s11b_0p95>;
+
+ vreg_s10b_1p8: smps10 {
+ regulator-name = "vreg_s10b_1p8";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-initial-mode = ;
+ };
+
+ vreg_s11b_0p95: smps11 {
+ regulator-name = "vreg_s11b_0p95";
+ regulator-min-microvolt = <952000>;
+ regulator-max-microvolt = <952000>;
+ regulator-initial-mode = ;
+ };
+
+ vreg_s12b_1p25: smps12 {
+ regulator-name = "vreg_s12b_1p25";
+ regulator-min-microvolt = <1256000>;
+ regulator-max-microvolt = <1256000>;
+ regulator-initial-mode = ;
+ };
+
+ vreg_l1b_0p88: ldo1 {
+ regulator-name = "vreg_l1b_0p88";
+ regulator-min-microvolt = <912000>;
+ regulator-max-microvolt = <92>;
+ regulator-initial-mode = ;
+ };
+
+ vreg_l2b_3p07: ldo2 {
+ regulator-name = "vreg_l2b_3p07";
+ regulator-min-microvolt = <3072000>;
+ regulator-max-microvolt = <3072000>;
+ regulator-initial-mode = ;
+ };
+
+ vreg_l3b_0p9: ldo3 {
+ regulator-name = "vreg_l3b_0p9";
+ regulator-min-microvolt = <904000>;
+ regulator-max-microvolt = <904000>;
+ regulator-initial-mode = ;
+ };
+
+ vreg_l5b_0p88: ldo5 {
+ regulator-name = "vreg_l5b_0p88";
+ regulator-min-microvolt = <88>;
+ regulator-max-microvolt = <888000>;
+ regulator-initial-mode = ;
+ };
+
+ vreg_l6b_1p2: ldo6 {
+ regulator-name = "vreg_l6b_1p2";
+
[PATCH v4 07/14] KVM: SVM: Condition sev_enabled and sev_es_enabled on CONFIG_KVM_AMD_SEV=y
Define sev_enabled and sev_es_enabled as 'false' and explicitly #ifdef
out all of sev_hardware_setup() if CONFIG_KVM_AMD_SEV=n. This kills
three birds at once:
- Makes sev_enabled and sev_es_enabled off by default if
CONFIG_KVM_AMD_SEV=n. Previously, they could be on by default if
CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT=y, regardless of KVM SEV
support.
- Hides the sev and sev_es modules params when CONFIG_KVM_AMD_SEV=n.
- Resolves a false positive -Wnonnull in __sev_recycle_asids() that is
currently masked by the equivalent IS_ENABLED(CONFIG_KVM_AMD_SEV)
check in svm_sev_enabled(), which will be dropped in a future patch.
Reviewed by: Tom Lendacky
Reviewed-by: Brijesh Singh
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/svm/sev.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index d6f069271e75..4b46bcd0efc5 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -28,6 +28,7 @@
#define __ex(x) __kvm_handle_fault_on_reboot(x)
+#ifdef CONFIG_KVM_AMD_SEV
/* enable/disable SEV support */
static bool sev_enabled = IS_ENABLED(CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT);
module_param_named(sev, sev_enabled, bool, 0444);
@@ -35,6 +36,10 @@ module_param_named(sev, sev_enabled, bool, 0444);
/* enable/disable SEV-ES support */
static bool sev_es_enabled =
IS_ENABLED(CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT);
module_param_named(sev_es, sev_es_enabled, bool, 0444);
+#else
+#define sev_enabled false
+#define sev_es_enabled false
+#endif /* CONFIG_KVM_AMD_SEV */
static u8 sev_enc_bit;
static int sev_flush_asids(void);
@@ -1328,11 +1333,12 @@ void sev_vm_destroy(struct kvm *kvm)
void __init sev_hardware_setup(void)
{
+#ifdef CONFIG_KVM_AMD_SEV
unsigned int eax, ebx, ecx, edx;
bool sev_es_supported = false;
bool sev_supported = false;
- if (!IS_ENABLED(CONFIG_KVM_AMD_SEV) || !sev_enabled)
+ if (!sev_enabled)
goto out;
/* Does the CPU support SEV? */
@@ -1387,6 +1393,7 @@ void __init sev_hardware_setup(void)
out:
sev_enabled = sev_supported;
sev_es_enabled = sev_es_supported;
+#endif
}
void sev_hardware_teardown(void)
--
2.30.1.766.gb4fecdf3b7-goog
IF YOU NEED LOAN FOR YOUR PROJECT
-- Hello, I have a client with Assets in excess of $20B.He is ready to provide up to $2B plus or minus for project funding on loan basis to any interested Party whose project must not be sited in prohibited Countries and prohibited businesses.We do not sponsor projects or enter into partnership, we only fund projects solemnly through loan system operatives.Only willing and able to provide the facility for anyone on a loan basis.If you are interested contact me, for we are capable of given you loan up to $500M for your project with good interest rate. With best regards, Hyung Lee
[PATCH v4 14/14] KVM: SVM: Skip SEV cache flush if no ASIDs have been used
Skip SEV's expensive WBINVD and DF_FLUSH if there are no SEV ASIDs
waiting to be reclaimed, e.g. if SEV was never used. This "fixes" an
issue where the DF_FLUSH fails during hardware teardown if the original
SEV_INIT failed. Ideally, SEV wouldn't be marked as enabled in KVM if
SEV_INIT fails, but that's a problem for another day.
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/svm/sev.c | 23 +++
1 file changed, 11 insertions(+), 12 deletions(-)
diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index 3bf04a697723..f8ebda7c365a 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -57,9 +57,14 @@ struct enc_region {
unsigned long size;
};
-static int sev_flush_asids(void)
+static int sev_flush_asids(int min_asid, int max_asid)
{
- int ret, error = 0;
+ int ret, pos, error = 0;
+
+ /* Check if there are any ASIDs to reclaim before performing a flush */
+ pos = find_next_bit(sev_reclaim_asid_bitmap, max_sev_asid, min_asid);
+ if (pos >= max_asid)
+ return -EBUSY;
/*
* DEACTIVATE will clear the WBINVD indicator causing DF_FLUSH to fail,
@@ -81,14 +86,7 @@ static int sev_flush_asids(void)
/* Must be called with the sev_bitmap_lock held */
static bool __sev_recycle_asids(int min_asid, int max_asid)
{
- int pos;
-
- /* Check if there are any ASIDs to reclaim before performing a flush */
- pos = find_next_bit(sev_reclaim_asid_bitmap, max_sev_asid, min_asid);
- if (pos >= max_asid)
- return false;
-
- if (sev_flush_asids())
+ if (sev_flush_asids(min_asid, max_asid))
return false;
/* The flush process will flush all reclaimable SEV and SEV-ES ASIDs */
@@ -1399,10 +1397,11 @@ void sev_hardware_teardown(void)
if (!sev_enabled)
return;
+ /* No need to take sev_bitmap_lock, all VMs have been destroyed. */
+ sev_flush_asids(0, max_sev_asid);
+
bitmap_free(sev_asid_bitmap);
bitmap_free(sev_reclaim_asid_bitmap);
-
- sev_flush_asids();
}
int sev_cpu_init(struct svm_cpu_data *sd)
--
2.30.1.766.gb4fecdf3b7-goog
[PATCH v4 06/14] KVM: SVM: Append "_enabled" to module-scoped SEV/SEV-ES control variables
Rename sev and sev_es to sev_enabled and sev_es_enabled respectively to
better align with other KVM terminology, and to avoid pseudo-shadowing
when the variables are moved to sev.c in a future patch ('sev' is often
used for local struct kvm_sev_info pointers).
No functional change intended.
Acked-by: Tom Lendacky
Reviewed-by: Brijesh Singh
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/svm/sev.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index 871e040aad16..d6f069271e75 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -29,12 +29,12 @@
#define __ex(x) __kvm_handle_fault_on_reboot(x)
/* enable/disable SEV support */
-static int sev = IS_ENABLED(CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT);
-module_param(sev, int, 0444);
+static bool sev_enabled = IS_ENABLED(CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT);
+module_param_named(sev, sev_enabled, bool, 0444);
/* enable/disable SEV-ES support */
-static int sev_es = IS_ENABLED(CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT);
-module_param(sev_es, int, 0444);
+static bool sev_es_enabled =
IS_ENABLED(CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT);
+module_param_named(sev_es, sev_es_enabled, bool, 0444);
static u8 sev_enc_bit;
static int sev_flush_asids(void);
@@ -214,7 +214,7 @@ static int sev_guest_init(struct kvm *kvm, struct
kvm_sev_cmd *argp)
static int sev_es_guest_init(struct kvm *kvm, struct kvm_sev_cmd *argp)
{
- if (!sev_es)
+ if (!sev_es_enabled)
return -ENOTTY;
to_kvm_svm(kvm)->sev_info.es_active = true;
@@ -1123,7 +1123,7 @@ int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
struct kvm_sev_cmd sev_cmd;
int r;
- if (!svm_sev_enabled() || !sev)
+ if (!svm_sev_enabled() || !sev_enabled)
return -ENOTTY;
if (!argp)
@@ -1332,7 +1332,7 @@ void __init sev_hardware_setup(void)
bool sev_es_supported = false;
bool sev_supported = false;
- if (!IS_ENABLED(CONFIG_KVM_AMD_SEV) || !sev)
+ if (!IS_ENABLED(CONFIG_KVM_AMD_SEV) || !sev_enabled)
goto out;
/* Does the CPU support SEV? */
@@ -1370,7 +1370,7 @@ void __init sev_hardware_setup(void)
sev_supported = true;
/* SEV-ES support requested? */
- if (!sev_es)
+ if (!sev_es_enabled)
goto out;
/* Does the CPU support SEV-ES? */
@@ -1385,8 +1385,8 @@ void __init sev_hardware_setup(void)
sev_es_supported = true;
out:
- sev = sev_supported;
- sev_es = sev_es_supported;
+ sev_enabled = sev_supported;
+ sev_es_enabled = sev_es_supported;
}
void sev_hardware_teardown(void)
--
2.30.1.766.gb4fecdf3b7-goog
[PATCH v4 08/14] KVM: SVM: Enable SEV/SEV-ES functionality by default (when supported)
Enable the 'sev' and 'sev_es' module params by default instead of having them conditioned on CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT. The extra Kconfig is pointless as KVM SEV/SEV-ES support is already controlled via CONFIG_KVM_AMD_SEV, and CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT has the unfortunate side effect of enabling all the SEV-ES _guest_ code due to it being dependent on CONFIG_AMD_MEM_ENCRYPT=y. Cc: Borislav Petkov Cc: Tom Lendacky Cc: Brijesh Singh Signed-off-by: Sean Christopherson --- arch/x86/kvm/svm/sev.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c index 4b46bcd0efc5..bed8fee6c549 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -30,11 +30,11 @@ #ifdef CONFIG_KVM_AMD_SEV /* enable/disable SEV support */ -static bool sev_enabled = IS_ENABLED(CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT); +static bool sev_enabled = true; module_param_named(sev, sev_enabled, bool, 0444); /* enable/disable SEV-ES support */ -static bool sev_es_enabled = IS_ENABLED(CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT); +static bool sev_es_enabled = true; module_param_named(sev_es, sev_es_enabled, bool, 0444); #else #define sev_enabled false -- 2.30.1.766.gb4fecdf3b7-goog
[PATCH v4 13/14] KVM: SVM: Remove an unnecessary prototype declaration of sev_flush_asids()
Remove the forward declaration of sev_flush_asids(), which is only a few lines above the function itself. No functional change intended. Reviewed by: Tom Lendacky Reviewed-by: Brijesh Singh Signed-off-by: Sean Christopherson --- arch/x86/kvm/svm/sev.c | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c index 9837fd753d88..3bf04a697723 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -42,7 +42,6 @@ module_param_named(sev_es, sev_es_enabled, bool, 0444); #endif /* CONFIG_KVM_AMD_SEV */ static u8 sev_enc_bit; -static int sev_flush_asids(void); static DECLARE_RWSEM(sev_deactivate_lock); static DEFINE_MUTEX(sev_bitmap_lock); unsigned int max_sev_asid; -- 2.30.1.766.gb4fecdf3b7-goog
[PATCH v4 11/14] KVM: SVM: Move SEV VMCB tracking allocation to sev.c
Move the allocation of the SEV VMCB array to sev.c to help pave the way
toward encapsulating SEV enabling wholly within sev.c.
No functional change intended.
Reviewed by: Tom Lendacky
Reviewed-by: Brijesh Singh
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/svm/sev.c | 12
arch/x86/kvm/svm/svm.c | 16
arch/x86/kvm/svm/svm.h | 1 +
3 files changed, 21 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index 63d4f624c742..4685be80f551 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -1406,6 +1406,18 @@ void sev_hardware_teardown(void)
sev_flush_asids();
}
+int sev_cpu_init(struct svm_cpu_data *sd)
+{
+ if (!svm_sev_enabled())
+ return 0;
+
+ sd->sev_vmcbs = kcalloc(max_sev_asid + 1, sizeof(void *), GFP_KERNEL);
+ if (!sd->sev_vmcbs)
+ return -ENOMEM;
+
+ return 0;
+}
+
/*
* Pages used by hardware to hold guest encrypted state must be flushed before
* returning them to the system.
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index 0fa6c409b484..51cea470d0bb 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -549,22 +549,22 @@ static void svm_cpu_uninit(int cpu)
static int svm_cpu_init(int cpu)
{
struct svm_cpu_data *sd;
+ int ret;
sd = kzalloc(sizeof(struct svm_cpu_data), GFP_KERNEL);
if (!sd)
return -ENOMEM;
sd->cpu = cpu;
sd->save_area = alloc_page(GFP_KERNEL);
- if (!sd->save_area)
+ if (!sd->save_area) {
+ ret = -ENOMEM;
goto free_cpu_data;
+ }
clear_page(page_address(sd->save_area));
- if (svm_sev_enabled()) {
- sd->sev_vmcbs = kcalloc(max_sev_asid + 1, sizeof(void *),
- GFP_KERNEL);
- if (!sd->sev_vmcbs)
- goto free_save_area;
- }
+ ret = sev_cpu_init(sd);
+ if (ret)
+ goto free_save_area;
per_cpu(svm_data, cpu) = sd;
@@ -574,7 +574,7 @@ static int svm_cpu_init(int cpu)
__free_page(sd->save_area);
free_cpu_data:
kfree(sd);
- return -ENOMEM;
+ return ret;
}
diff --git a/arch/x86/kvm/svm/svm.h b/arch/x86/kvm/svm/svm.h
index aec70f6cd243..0953251232c8 100644
--- a/arch/x86/kvm/svm/svm.h
+++ b/arch/x86/kvm/svm/svm.h
@@ -562,6 +562,7 @@ int svm_unregister_enc_region(struct kvm *kvm,
void pre_sev_run(struct vcpu_svm *svm, int cpu);
void __init sev_hardware_setup(void);
void sev_hardware_teardown(void);
+int sev_cpu_init(struct svm_cpu_data *sd);
void sev_free_vcpu(struct kvm_vcpu *vcpu);
int sev_handle_vmgexit(struct vcpu_svm *svm);
int sev_es_string_io(struct vcpu_svm *svm, int size, unsigned int port, int
in);
--
2.30.1.766.gb4fecdf3b7-goog
[PATCH v4 12/14] KVM: SVM: Drop redundant svm_sev_enabled() helper
Replace calls to svm_sev_enabled() with direct checks on sev_enabled, or
in the case of svm_mem_enc_op, simply drop the call to svm_sev_enabled().
This effectively replaces checks against a valid max_sev_asid with checks
against sev_enabled. sev_enabled is forced off by sev_hardware_setup()
if max_sev_asid is invalid, all call sites are guaranteed to run after
sev_hardware_setup(), and all of the checks care about SEV being fully
enabled (as opposed to intentionally handling the scenario where
max_sev_asid is valid but SEV enabling fails due to OOM).
Reviewed by: Tom Lendacky
Reviewed-by: Brijesh Singh
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/svm/sev.c | 6 +++---
arch/x86/kvm/svm/svm.h | 5 -
2 files changed, 3 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index 4685be80f551..9837fd753d88 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -1128,7 +1128,7 @@ int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
struct kvm_sev_cmd sev_cmd;
int r;
- if (!svm_sev_enabled() || !sev_enabled)
+ if (!sev_enabled)
return -ENOTTY;
if (!argp)
@@ -1397,7 +1397,7 @@ void __init sev_hardware_setup(void)
void sev_hardware_teardown(void)
{
- if (!svm_sev_enabled())
+ if (!sev_enabled)
return;
bitmap_free(sev_asid_bitmap);
@@ -1408,7 +1408,7 @@ void sev_hardware_teardown(void)
int sev_cpu_init(struct svm_cpu_data *sd)
{
- if (!svm_sev_enabled())
+ if (!sev_enabled)
return 0;
sd->sev_vmcbs = kcalloc(max_sev_asid + 1, sizeof(void *), GFP_KERNEL);
diff --git a/arch/x86/kvm/svm/svm.h b/arch/x86/kvm/svm/svm.h
index 0953251232c8..8a52cbc2dee7 100644
--- a/arch/x86/kvm/svm/svm.h
+++ b/arch/x86/kvm/svm/svm.h
@@ -548,11 +548,6 @@ void svm_vcpu_unblocking(struct kvm_vcpu *vcpu);
extern unsigned int max_sev_asid;
-static inline bool svm_sev_enabled(void)
-{
- return IS_ENABLED(CONFIG_KVM_AMD_SEV) ? max_sev_asid : 0;
-}
-
void sev_vm_destroy(struct kvm *kvm);
int svm_mem_enc_op(struct kvm *kvm, void __user *argp);
int svm_register_enc_region(struct kvm *kvm,
--
2.30.1.766.gb4fecdf3b7-goog
[PATCH v4 09/14] KVM: SVM: Unconditionally invoke sev_hardware_teardown()
Remove the redundant svm_sev_enabled() check when calling
sev_hardware_teardown(), the teardown helper itself does the check.
Removing the check from svm.c will eventually allow dropping
svm_sev_enabled() entirely.
No functional change intended.
Reviewed by: Tom Lendacky
Reviewed-by: Brijesh Singh
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/svm/svm.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index 6dd8bcf3e8fa..0fa6c409b484 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -883,8 +883,7 @@ static void svm_hardware_teardown(void)
{
int cpu;
- if (svm_sev_enabled())
- sev_hardware_teardown();
+ sev_hardware_teardown();
for_each_possible_cpu(cpu)
svm_cpu_uninit(cpu);
--
2.30.1.766.gb4fecdf3b7-goog
[PATCH v4 02/14] KVM: SVM: Free sev_asid_bitmap during init if SEV setup fails
Free sev_asid_bitmap if the reclaim bitmap allocation fails, othwerise
KVM will unnecessarily keep the bitmap when SEV is not fully enabled.
Freeing the page is also necessary to avoid introducing a bug when a
future patch eliminates svm_sev_enabled() in favor of using the global
'sev' flag directly. While sev_hardware_enabled() checks max_sev_asid,
which is true even if KVM setup fails, 'sev' will be true if and only
if KVM setup fully succeeds.
Fixes: 33af3a7ef9e6 ("KVM: SVM: Reduce WBINVD/DF_FLUSH invocations")
Cc: Tom Lendacky
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/svm/sev.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index 874ea309279f..5533f37ce50e 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -1349,8 +1349,11 @@ void __init sev_hardware_setup(void)
goto out;
sev_reclaim_asid_bitmap = bitmap_zalloc(max_sev_asid, GFP_KERNEL);
- if (!sev_reclaim_asid_bitmap)
+ if (!sev_reclaim_asid_bitmap) {
+ bitmap_free(sev_asid_bitmap);
+ sev_asid_bitmap = NULL;
goto out;
+ }
pr_info("SEV supported: %u ASIDs\n", max_sev_asid - min_sev_asid + 1);
sev_supported = true;
--
2.30.1.766.gb4fecdf3b7-goog
