Re: [PATCH] dma-debug: fix debug_dma_assert_idle(), use rcu_read_lock()
On Fri, 14 Aug 2020, Linus Torvalds wrote: > On Thu, Aug 13, 2020 at 10:42 PM Christoph Hellwig wrote: > > > > The whole thing predates my involvement with the code, but I defintively > > think the patch from Hugh is a major improvement. But I would also > > have no problem with just removing it entirely. > > I decided to just do both, since neither you nor Dan seemed to really object. > > I applied Hugh's RCU read locking patch as a clear improvement, and > then I did a second patch that just removed this function entirely. > That sounds a bit odd, perhaps, but in case people decide to resurrect > the debugging code, I didn't want us to lose sight of Hugh's > improvement just because I then decided that we might as well go one > step further and just remove it entirely. That's ideal, thanks - exactly the sequence I was hoping for. (Another shortcoming in debug_dma_assert_idle(), that I hadn't wanted to distract us by mentioning, is that it assumed that the mapping is contained within one small page, whereas I believe one or more of the DMA mapping functions take a size_t argument, that could in theory span small pages - I guess more plausible inside a compound page; yet it looked like only an initial entry would be put into the radix-tree.) > > And the only real reason I care is that this whole COW and page lock > thing has showed up lately, and I like removing code. > > I'm _very_ tempted to just apply my COW simplification patch that gets > rid of all the complex try-to-share cases entirely (and would also > obviate the whole forced-cow patch). I suspect it would effectively > remove almost all of the [un[lock_page() bottlenecks entirely, but > that code has decades of history and I suspect it's a bit too drastic > wrt KSM and the swap cache pages. Yes, you're right to hold back. I'd been looking there too (but backed off while speeding up the fork was causing the "Hugh load" to "fail": it's the exit that now wants speeding up, to please that test). I think it could well avoid getting into page locking when mapcount is quickly seen to be high (> 1? > 2? > bigger? I never did the logic), but the page locking becomes important when mapcount looks low, yet swap might be involved. We used to rely on page count there, and on trylock_page() only; but there was at least one user whose app went wrong when occasionally we COWed the page, just because something else momentarily took a reference to it, or locked it. Around 2006, bug report from 2004: I did look up the history a week ago, but was interrupted before taking notes. > > It would be lovely if the main source of page locking would really be > about just IO, but the page lock has also become the thing that > serializes almost everything related to page state. Which is why you > find it in contexts that are really not IO-related at all (not just > COW - page migration is the other one that has shown up a lot under > "heavy CPU loads" without really necessarily any IO component to it). > > Linus
Re: [PATCH] x86: work around clang IAS bug referencing __force_order
On Fri, Aug 14, 2020 at 3:57 PM Nick Desaulniers wrote: > > On Fri, Aug 14, 2020 at 2:19 PM Sedat Dilek wrote: > > > > On Fri, Aug 14, 2020 at 7:29 PM Sedat Dilek wrote: > > > > > > Thanks for the proposal. > > > > > > I have adapted it to fit my patchset against Linux v5.8. > > > > > > Both Debian's GCC-10 and a snapshot version of LLVM toolchain > > > v11.0.0-rc1+ seems to be OK. > > > > > > > Yupp, OK. > > > > I was able to boot FreeDOS 1.2 VM in VirtualBox GUI. > > Hi Sedat, > Apologies, but it's not clear to me precisely which patch you tested. > Can you please confirm whether you tested: > 1. Arnd's patch that started this thread. > 2. My proposed diff adding -fno-addrsig to CFLAGS_powernow-k6.o. > 3. My proposed diff removing __force_order from the kernel. > > I'm hoping you were referring to testing 3., but it's not clear to me. Ah, sorry, I missed your comment on github: https://github.com/ClangBuiltLinux/linux/issues/1120#issuecomment-674282107 Ok, I will look at more disassembly next week and hopefully have a patch ready, with your tested by tag. -- Thanks, ~Nick Desaulniers
[PATCH] lib/string.c: implement stpcpy
LLVM implemented a recent "libcall optimization" that lowers calls to
`sprintf(dest, "%s", str)` where the return value is used to
`stpcpy(dest, str) - dest`. This generally avoids the machinery involved
in parsing format strings.
`stpcpy` is just like `strcpy` except:
1. it returns the pointer to the new tail of `dest`. This allows you to
chain multiple calls to `stpcpy` in one statement.
2. it requires the parameters not to overlap. Calling `sprintf` with
overlapping arguments was clarified in ISO C99 and POSIX.1-2001 to be
undefined behavior.
`stpcpy` was first standardized in POSIX.1-2008.
Implement this so that we don't observe linkage failures due to missing
symbol definitions for `stpcpy`.
Similar to last year's fire drill with:
commit 5f074f3e192f ("lib/string.c: implement a basic bcmp")
This optimization was introduced into clang-12.
Cc: sta...@vger.kernel.org
Link: https://bugs.llvm.org/show_bug.cgi?id=47162
Link: https://github.com/ClangBuiltLinux/linux/issues/1126
Link: https://man7.org/linux/man-pages/man3/stpcpy.3.html
Link: https://pubs.opengroup.org/onlinepubs/9699919799/functions/stpcpy.html
Link: https://reviews.llvm.org/D85963
Reported-by: Sami Tolvanen
Signed-off-by: Nick Desaulniers
---
include/linux/string.h | 3 +++
lib/string.c | 23 +++
2 files changed, 26 insertions(+)
diff --git a/include/linux/string.h b/include/linux/string.h
index b1f3894a0a3e..e570b9b10f50 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -31,6 +31,9 @@ size_t strlcpy(char *, const char *, size_t);
#ifndef __HAVE_ARCH_STRSCPY
ssize_t strscpy(char *, const char *, size_t);
#endif
+#ifndef __HAVE_ARCH_STPCPY
+extern char *stpcpy(char *__restrict, const char *__restrict__);
+#endif
/* Wraps calls to strscpy()/memset(), no arch specific code required */
ssize_t strscpy_pad(char *dest, const char *src, size_t count);
diff --git a/lib/string.c b/lib/string.c
index 6012c385fb31..81bc4d62c256 100644
--- a/lib/string.c
+++ b/lib/string.c
@@ -272,6 +272,29 @@ ssize_t strscpy_pad(char *dest, const char *src, size_t
count)
}
EXPORT_SYMBOL(strscpy_pad);
+#ifndef __HAVE_ARCH_STPCPY
+/**
+ * stpcpy - copy a string from src to dest returning a pointer to the new end
+ * of dest, including src's NULL terminator. May overrun dest.
+ * @dest: pointer to end of string being copied into. Must be large enough
+ *to receive copy.
+ * @src: pointer to the beginning of string being copied from. Must not overlap
+ * dest.
+ *
+ * stpcpy differs from strcpy in two key ways:
+ * 1. inputs must not overlap.
+ * 2. return value is the new NULL terminated character. (for strcpy, the
+ *return value is a pointer to src.
+ */
+#undef stpcpy
+char *stpcpy(char *__restrict__ dest, const char *__restrict__ src)
+{
+ while ((*dest++ = *src++) != '\0')
+ /* nothing */;
+ return dest;
+}
+#endif
+
#ifndef __HAVE_ARCH_STRCAT
/**
* strcat - Append one %NUL-terminated string to another
--
2.28.0.220.ged08abb693-goog
linux-next: Fixes tag needs some work in the memblock tree
Hi all,
In commit
520580d537a1 ("arch/ia64: Restore arch-specific pgd_offset_k implementation")
Fixes tag
Fixes: 974b9b2c68 ("mm: consolidate pte_index() and pte_offset_*()
definitions")
has these problem(s):
- SHA1 should be at least 12 digits long
Can be fixed by setting core.abbrev to 12 (or more) or (for git v2.11
or later) just making sure it is not set (or set to "auto").
--
Cheers,
Stephen Rothwell
pgp61z5rJPSCl.pgp
Description: OpenPGP digital signature
Re: POC: Alternative solution: Re: [PATCH 0/4] printk: reimplement LOG_CONT handling
On Fri, 2020-08-14 at 15:46 -0700, Linus Torvalds wrote:
> On Thu, Aug 13, 2020 at 4:54 AM Sergey Senozhatsky
> wrote:
> > I think what Linus said a long time ago was that the initial purpose of
> > pr_cont was
> >
> > pr_info("Initialize feature foo...");
> > if (init_feature_foo() == 0)
> > pr_cont("ok\n");
> > else
> > pr_cont("not ok\n");
> >
> > And if init_feature_foo() crashes the kernel then the first printk()
> > form panic() will flush the cont buffer.
>
> Right.
>
> This is why I think any discussion that says "people should buffer
> their lines themselves and we should get rid if pr_cont()" is
> fundamentally broken.
>
> Don't go down that hole. I won't take it. It's wrong.
I don't think it's wrong per se.
It's reasonable to avoid pr_cont when appropriate.
Trivial buffering, or adding and using YA vsprintf
extension can avoid unnecessary message interleaving.
For instance, I just sent this patch to allow removal
of print_vma_addr and its use of pr_cont.
https://lore.kernel.org/lkml/09f11651f0e913e159b955ac447cd8cadf36cb0d.ca...@perches.com/
This is similar to the dump_flags_names removal back
in commit edf14cdbf9a0 ("mm, printk: introduce new format
string for flags")
> The fact is, pr_cont() goes back to the original kernel. No, it wasn't
> pr_cont() back then, and no, there were no actual explicit markers for
> "this is a continuation" at all, it was all just "the last printk
> didn't have a newline, so we continue where we left off".
>
> We've added pr_cont (and KERN_CONT) since then, and I realize that a
> lot of people hate the complexity it introduces, but it's a
> fundamental complexity that you have to live with.
>
> If you can't live with pr_cont(), you shouldn't be working on
> printk(), and find some other area of the kernel that you _can_ live
> with.
>
> It really is that simple.
>
Re: [PATCH] selftests: rtnetlink: load fou module for kci_test_encap_fou()
From: Po-Hsu Lin Date: Thu, 13 Aug 2020 12:44:22 +0800 > diff --git a/tools/testing/selftests/net/config > b/tools/testing/selftests/net/config > index 3b42c06b..96d2763 100644 > --- a/tools/testing/selftests/net/config > +++ b/tools/testing/selftests/net/config > @@ -31,3 +31,4 @@ CONFIG_NET_SCH_ETF=m > CONFIG_NET_SCH_NETEM=y > CONFIG_TEST_BLACKHOLE_DEV=m > CONFIG_KALLSYMS=y > +CONFIG_NET_FOU You need to assign it a value, not just add it to the file by itself.
Re: [RFC-PATCH 1/2] mm: Add __GFP_NO_LOCKS flag
On Sat, Aug 15, 2020 at 01:14:53AM +0200, Thomas Gleixner wrote: > Paul, > > On Fri, Aug 14 2020 at 11:01, Paul E. McKenney wrote: > > On Fri, Aug 14, 2020 at 04:06:04PM +0200, Michal Hocko wrote: > >> > > > Vlastimil raised same question earlier, i answered, but let me > >> > > > answer again: > >> > > > > >> > > > It is hard to achieve because the logic does not stick to certain > >> > > > static test > >> > > > case, i.e. it depends on how heavily kfree_rcu(single/double) are > >> > > > used. Based > >> > > > on that, "how heavily" - number of pages are formed, until the > >> > > > drain/reclaimer > >> > > > thread frees them. > >> > > > >> > > How many pages are talking about - ball park? 100s, 1000s? > >> > > >> > Under normal operation, a couple of pages per CPU, which would make > >> > preallocation entirely reasonable. Except that if someone does something > >> > that floods RCU callbacks (close(open) in a tight userspace loop, for but > >> > one example), then 2000 per CPU might not be enough, which on a 64-CPU > >> > system comes to about 500MB. This is beyond excessive for preallocation > >> > on the systems I am familiar with. > >> > > >> > And the flooding case is where you most want the reclamation to be > >> > efficient, and thus where you want the pages. > > As we now established that taking zone lock is impossible at all > independent of raw/non-raw ordering and independent of RT/PREEMPT > configs, can we just take a step back and look at the problem from > scratch again? Can't hurt! (Famous last words...) > As a matter of fact I assume^Wdeclare that removing struct rcu_head which > provides a fallback is not an option at all. I know that you want to, > but it wont work ever. Dream on, but as we agreed on recently there is > this thing called reality which ruins everything. For call_rcu(), agreed. For kfree_rcu(), we know what the callback is going to do, plus single-argument kfree_rcu() can only be invoked from sleepable context. (If you want to kfree_rcu() from non-sleepable context, that will cost you an rcu_head in the data structure being freed.) So if the single-argument kfree_rcu() case gets hit with a memory-allocation failure, it can fall back to waiting for a grace period and doing the free. Of course, grace-period waits have horrible latency, but under OOM life is hard. If this becomes a problem in non-OOM situations due to the lockless caches becoming empty, we will have to allocate memory if needed before acquiring the lock with the usual backout logic. Doing that means that we can let the allocator acquire locks and maybe even do a little bit of blocking, so that the inline grace-period-wait would only happen if the system was well and truly OOMed. > For normal operations a couple of pages which can be preallocated are > enough. What you are concerned of is the case where you run out of > pointer storage space. Agreed. > There are two reasons why that can happen: > > 1) RCU call flooding > 2) RCU not being able to run and mop up the backlog > > #1 is observable by looking at the remaining storage space and the RCU >call frequency > > #2 is uninteresting because it's caused by RCU being stalled / delayed >e.g. by a runaway of some sorts or a plain RCU usage bug. > >Allocating more memory in that case does not solve or improve anything. Yes, #2 is instead RCU CPU stall warning territory. If this becomes a problem, one approach is to skip the page-of-pointers allocation if the grace period is more than (say) one second old. If the grace period never completes, OOM is unavoidable, but this is a way of putting it off for a bit. > So the interesting case is #1. Which means we need to look at the > potential sources of the flooding: > > 1) User space via syscalls, e.g. open/close > 2) Kernel thread > 3) Softirq > 4) Device interrupt > 5) System interrupts, deep atomic context, NMI ... > > #1 trivial fix is to force switching to an high prio thread or a soft >interrupt which does the allocation > > #2 Similar to #1 unless that thread loops with interrupts, softirqs or >preemption disabled. If that's the case then running out of RCU >storage space is the least of your worries. > > #3 Similar to #2. The obvious candidates (e.g. NET) for monopolizing a >CPU have loop limits in place already. If there is a bug which fails >to care about the limit, why would RCU care and allocate more memory? > > #4 Similar to #3. If the interrupt handler loops forever or if the >interrupt is a runaway which prevents task/softirq processing then >RCU free performance is the least of your worries. > > #5 Clearly a bug and making RCU accomodate for that is beyond silly. > > So if call_rcu() detects that the remaining storage space for pointers > goes below the critical point or if it observes high frequency calls > then it simply should force a soft interrupt which does the allocation. Unless
Re: [RFC-PATCH 1/2] mm: Add __GFP_NO_LOCKS flag
On Fri, Aug 14 2020 at 23:52, Peter Zijlstra wrote: > On Fri, Aug 14, 2020 at 01:41:40PM -0700, Paul E. McKenney wrote: >> > And that enforces the GFP_NOLOCK allocation mode or some other solution >> > unless you make a new rule that calling call_rcu() is forbidden while >> > holding zone lock or any other lock which might be nested inside the >> > GFP_NOWAIT zone::lock held region. >> >> Again, you are correct. Maybe the forecasted weekend heat will cause >> my brain to hallucinate a better solution, but in the meantime, the >> GFP_NOLOCK approach looks good from this end. > > So I hate __GFP_NO_LOCKS for a whole number of reasons: > > - it should be called __GFP_LOCKLESS if anything > - it sprinkles a bunch of ugly branches around the allocator fast path > - it only works for order==0 > > Combined I really odn't think this should be a GFP flag. How about a > special purpose allocation function, something like so.. No. No. No. It's not requried at all after the context got set straight and my brain started working again. There is no need to provide such a thing which tries to "optimize" unfixable problems and as a consequence makes other people use it for the completely wrong reasons all over the place. We have plenty of that stuff already. No need for more ... Thanks, tglx
BUG: corrupted list in bt_accept_unlink
Hello, syzbot found the following issue on: HEAD commit:a1d21081 Merge git://git.kernel.org/pub/scm/linux/kernel/g.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=11c7789190 kernel config: https://syzkaller.appspot.com/x/.config?x=9c89856ae5fc8b6 dashboard link: https://syzkaller.appspot.com/bug?extid=7f4d3ecf4d3480301722 compiler: gcc (GCC) 10.1.0-syz 20200507 userspace arch: i386 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1180847a90 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+7f4d3ecf4d3480301...@syzkaller.appspotmail.com list_del corruption. prev->next should be 8880913ab4b8, but was 8880890c54b8 [ cut here ] kernel BUG at lib/list_debug.c:51! invalid opcode: [#1] PREEMPT SMP KASAN CPU: 1 PID: 17 Comm: kworker/1:0 Not tainted 5.8.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: events l2cap_chan_timeout RIP: 0010:__list_del_entry_valid.cold+0xf/0x55 lib/list_debug.c:51 Code: e8 5a ab bf fd 0f 0b 48 89 f1 48 c7 c7 40 ff 93 88 4c 89 e6 e8 46 ab bf fd 0f 0b 48 89 ee 48 c7 c7 e0 00 94 88 e8 35 ab bf fd <0f> 0b 4c 89 ea 48 89 ee 48 c7 c7 20 00 94 88 e8 21 ab bf fd 0f 0b RSP: 0018:c9d8fb18 EFLAGS: 00010282 RAX: 0054 RBX: 8880913ab4b8 RCX: RDX: 8880a968a480 RSI: 815dbc57 RDI: f520001b1f55 RBP: 8880913ab4b8 R08: 0054 R09: 8880ae7318e7 R10: R11: 000c3a18 R12: 8880890c54b8 R13: 88809914f4b8 R14: 88809914f000 R15: 0008 FS: () GS:8880ae70() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 081570f0 CR3: a6dc2000 CR4: 001506e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: __list_del_entry include/linux/list.h:132 [inline] list_del_init include/linux/list.h:204 [inline] bt_accept_unlink+0x26/0x280 net/bluetooth/af_bluetooth.c:187 l2cap_sock_teardown_cb+0x197/0x400 net/bluetooth/l2cap_sock.c:1544 l2cap_chan_del+0xad/0x1300 net/bluetooth/l2cap_core.c:618 l2cap_chan_close+0x118/0xb10 net/bluetooth/l2cap_core.c:823 l2cap_chan_timeout+0x173/0x450 net/bluetooth/l2cap_core.c:436 process_one_work+0x94c/0x1670 kernel/workqueue.c:2269 worker_thread+0x64c/0x1120 kernel/workqueue.c:2415 kthread+0x3b5/0x4a0 kernel/kthread.c:292 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294 Modules linked in: ---[ end trace ea2f8b77c156d63d ]--- RIP: 0010:__list_del_entry_valid.cold+0xf/0x55 lib/list_debug.c:51 Code: e8 5a ab bf fd 0f 0b 48 89 f1 48 c7 c7 40 ff 93 88 4c 89 e6 e8 46 ab bf fd 0f 0b 48 89 ee 48 c7 c7 e0 00 94 88 e8 35 ab bf fd <0f> 0b 4c 89 ea 48 89 ee 48 c7 c7 20 00 94 88 e8 21 ab bf fd 0f 0b RSP: 0018:c9d8fb18 EFLAGS: 00010282 RAX: 0054 RBX: 8880913ab4b8 RCX: RDX: 8880a968a480 RSI: 815dbc57 RDI: f520001b1f55 RBP: 8880913ab4b8 R08: 0054 R09: 8880ae7318e7 R10: R11: 000c3a18 R12: 8880890c54b8 R13: 88809914f4b8 R14: 88809914f000 R15: 0008 FS: () GS:8880ae70() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 080f0b38 CR3: 09a8d000 CR4: 001506e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 --- 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 can test patches for this issue, for details see: https://goo.gl/tpsmEJ#testing-patches
Re: [RFC-PATCH 1/2] mm: Add __GFP_NO_LOCKS flag
On Fri, Aug 14, 2020 at 11:52:06PM +0200, Peter Zijlstra wrote:
> On Fri, Aug 14, 2020 at 01:41:40PM -0700, Paul E. McKenney wrote:
> > > And that enforces the GFP_NOLOCK allocation mode or some other solution
> > > unless you make a new rule that calling call_rcu() is forbidden while
> > > holding zone lock or any other lock which might be nested inside the
> > > GFP_NOWAIT zone::lock held region.
> >
> > Again, you are correct. Maybe the forecasted weekend heat will cause
> > my brain to hallucinate a better solution, but in the meantime, the
> > GFP_NOLOCK approach looks good from this end.
>
> So I hate __GFP_NO_LOCKS for a whole number of reasons:
>
> - it should be called __GFP_LOCKLESS if anything
> - it sprinkles a bunch of ugly branches around the allocator fast path
> - it only works for order==0
>
> Combined I really odn't think this should be a GFP flag. How about a
> special purpose allocation function, something like so..
This looks entirely reasonable to me!
Thanx, Paul
> ---
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 901a21f61d68..cdec9c99fba7 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -4875,6 +4875,47 @@ __alloc_pages_nodemask(gfp_t gfp_mask, unsigned int
> order, int preferred_nid,
> }
> EXPORT_SYMBOL(__alloc_pages_nodemask);
>
> +struct page *__rmqueue_lockless(struct zone *zone, struct per_cpu_pages *pcp)
> +{
> + struct list_head *list;
> + struct page *page;
> + int migratetype;
> +
> + for (migratetype = 0; migratetype < MIGRATE_PCPTYPES; migratetype++) {
> + list = >list[migratetype];
> + page = list_first_entry_or_null(list, struct page, lru);
> + if (page && check_new_pcp(page)) {
> + list_del(>lru);
> + pcp->count--;
> + return page;
> + }
> + }
> +
> + return NULL;
> +}
> +
> +struct page *__alloc_page_lockless(void)
> +{
> + struct zonelist *zonelist = node_zonelist(numa_node_id(), GFP_KERNEL);
> + struct per_cpu_pages *pcp;
> + struct page *page = NULL;
> + unsigned long flags;
> + struct zoneref *z;
> + struct zone *zone;
> +
> + for_each_zone_zonelist(zone, z, zonelist, ZONE_NORMAL) {
> + local_irq_save(flags);
> + pcp = _cpu_ptr(zone->pageset)->pcp;
> + page = __rmqueue_lockless(zone, pcp);
> + local_irq_restore(flags);
> +
> + if (page)
> + break;
> + }
> +
> + return page;
> +}
> +
> /*
> * Common helper functions. Never use with __GFP_HIGHMEM because the returned
> * address cannot represent highmem pages. Use alloc_pages and then kmap if
Re: [PATCH] x86/hotplug: Silence APIC only after all irq's are migrated
On 8/14/20 2:38 PM, Ashok Raj wrote:
> When offlining CPU's, fixup_irqs() migrates all interrupts away from the
CPUs,
> outgoing CPU to an online CPU. Its always possible the device sent an
It's
> interrupt to the previous CPU destination. Pending interrupt bit in IRR in
> lapic identifies such interrupts. apic_soft_disable() will not capture any
LAPIC
> new interrupts in IRR. This causes interrupts from device to be lost during
> cpu offline. The issue was found when explicitly setting MSI affinity to a
CPU
> CPU and immediately offlining it. It was simple to recreate with a USB
> ethernet device and doing I/O to it while the CPU is offlined. Lost
> interrupts happen even when Interrupt Remapping is enabled.
>
> Current code does apic_soft_disable() before migrating interrupts.
>
> native_cpu_disable()
> {
> ...
> apic_soft_disable();
> cpu_disable_common();
> --> fixup_irqs(); // Too late to capture anything in IRR.
> }
>
> Just fliping the above call sequence seems to hit the IRR checks
flipping
> and the lost interrupt is fixed for both legacy MSI and when
> interrupt remapping is enabled.
>
>
> Fixes: 60dcaad5736f ("x86/hotplug: Silence APIC and NMI when CPU is dead")
> Link: https://lore.kernel.org/lkml/875zdarr4h@nanos.tec.linutronix.de/
> Signed-off-by: Ashok Raj
>
> To: linux-kernel@vger.kernel.org
> To: Thomas Gleixner
> Cc: Sukumar Ghorai
> Cc: Srikanth Nandamuri
> Cc: Evan Green
> Cc: Mathias Nyman
> Cc: Bjorn Helgaas
> Cc: sta...@vger.kernel.org
> ---
> arch/x86/kernel/smpboot.c | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
> index ffbd9a3d78d8..278cc9f92f2f 100644
> --- a/arch/x86/kernel/smpboot.c
> +++ b/arch/x86/kernel/smpboot.c
> @@ -1603,13 +1603,20 @@ int native_cpu_disable(void)
> if (ret)
> return ret;
>
> + cpu_disable_common();
> /*
>* Disable the local APIC. Otherwise IPI broadcasts will reach
>* it. It still responds normally to INIT, NMI, SMI, and SIPI
> - * messages.
> + * messages. Its important to do apic_soft_disable() after
It's
> + * fixup_irqs(), because fixup_irqs() called from cpu_disable_common()
> + * depends on IRR being set. After apic_soft_disable() CPU preserves
> + * currently set IRR/ISR but new interrupts will not set IRR.
> + * This causes interrupts sent to outgoing cpu before completion
CPU
> + * of irq migration to be lost. Check SDM Vol 3 "10.4.7.2 Local
IRQ
> + * APIC State after It Has been Software Disabled" section for more
> + * details.
>*/
> apic_soft_disable();
> - cpu_disable_common();
>
> return 0;
> }
>
thanks.
--
~Randy
Re: [PATCH v10 3/5] drm/msm/dp: add support for DP PLL driver
On 2020-08-14 10:05, Dmitry Baryshkov wrote:
On 12/08/2020 07:42, Tanmay Shah wrote:
From: Chandan Uddaraju
Add the needed DP PLL specific files to support
display port interface on msm targets.
[skipped]
diff --git a/drivers/gpu/drm/msm/dp/dp_pll_private.h
b/drivers/gpu/drm/msm/dp/dp_pll_private.h
new file mode 100644
index ..475ba6ed59ab
--- /dev/null
+++ b/drivers/gpu/drm/msm/dp/dp_pll_private.h
@@ -0,0 +1,98 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2016-2020, The Linux Foundation. All rights
reserved.
+ */
+
+#ifndef __DP_PLL_10NM_H
+#define __DP_PLL_10NM_H
+
+#include "dp_pll.h"
+#include "dp_reg.h"
+
+#define DP_VCO_HSCLK_RATE_1620MHZDIV1000162UL
+#define DP_VCO_HSCLK_RATE_2700MHZDIV1000270UL
+#define DP_VCO_HSCLK_RATE_5400MHZDIV1000540UL
+#define DP_VCO_HSCLK_RATE_8100MHZDIV1000810UL
+
+#define NUM_DP_CLOCKS_MAX6
+
+#define DP_PHY_PLL_POLL_SLEEP_US500
+#define DP_PHY_PLL_POLL_TIMEOUT_US1
+
+#define DP_VCO_RATE_8100MHZDIV1000810UL
+#define DP_VCO_RATE_9720MHZDIV1000972UL
+#define DP_VCO_RATE_10800MHZDIV10001080UL
+
+struct dp_pll_vco_clk {
+struct clk_hw hw;
+unsigned longrate;/* current vco rate */
+u64min_rate;/* min vco rate */
+u64max_rate;/* max vco rate */
+void*priv;
+};
+
+struct dp_pll_db {
This struct should probably go into dp_pll_10nm.c. dp_pll_7nm.c, for
example, will use slightly different structure.
Sure, it sounds good. I will give it try. Thanks!
+struct msm_dp_pll *base;
+
+int id;
+struct platform_device *pdev;
+
+/* private clocks: */
+bool fixed_factor_clk[NUM_DP_CLOCKS_MAX];
+struct clk_hw *hws[NUM_DP_CLOCKS_MAX];
Then these two fields can use exact number of clocks rather than
NUM_DP_CLOCKS_MAX.
I didn't get this. I think NUM_DP_CLOCKS_MAX is doing same?
+u32 num_hws;
+
+/* lane and orientation settings */
+u8 lane_cnt;
+u8 orientation;
+
+/* COM PHY settings */
+u32 hsclk_sel;
+u32 dec_start_mode0;
+u32 div_frac_start1_mode0;
+u32 div_frac_start2_mode0;
+u32 div_frac_start3_mode0;
+u32 integloop_gain0_mode0;
+u32 integloop_gain1_mode0;
+u32 vco_tune_map;
+u32 lock_cmp1_mode0;
+u32 lock_cmp2_mode0;
+u32 lock_cmp3_mode0;
+u32 lock_cmp_en;
+
+/* PHY vco divider */
+u32 phy_vco_div;
+/*
+ * Certain pll's needs to update the same vco rate after resume
in
+ * suspend/resume scenario. Cached the vco rate for such plls.
+ */
+unsigned longvco_cached_rate;
+u32cached_cfg0;
+u32cached_cfg1;
+u32cached_outdiv;
+
+uint32_t index;
+};
+
+static inline struct dp_pll_vco_clk *to_dp_vco_hw(struct clk_hw *hw)
+{
+return container_of(hw, struct dp_pll_vco_clk, hw);
+}
+
+#define to_msm_dp_pll(vco) ((struct msm_dp_pll *)vco->priv)
+
+#define to_dp_pll_db(x)((struct dp_pll_db *)x->priv)
+
+int dp_vco_set_rate_10nm(struct clk_hw *hw, unsigned long rate,
+unsigned long parent_rate);
+unsigned long dp_vco_recalc_rate_10nm(struct clk_hw *hw,
+unsigned long parent_rate);
+long dp_vco_round_rate_10nm(struct clk_hw *hw, unsigned long rate,
+unsigned long *parent_rate);
+int dp_vco_prepare_10nm(struct clk_hw *hw);
+void dp_vco_unprepare_10nm(struct clk_hw *hw);
+
+int msm_dp_pll_10nm_init(struct msm_dp_pll *dp_pll, int id);
+void msm_dp_pll_10nm_deinit(struct msm_dp_pll *dp_pll);
These functions don't seem to be used outside of dp_pll_10nm. What
about making them static?
I can't declare static to "init" and "deinit" as they are exported to
dp_pll.c.
Rest of them I can move to dp_pll_10nm and then define static.
Re: [RFC/RFT PATCH 6/6] riscv: Add numa support for riscv64 platform
On 8/14/20 2:47 PM, Atish Patra wrote: > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig > index 7b5905529146..4bd67f94aaac 100644 > --- a/arch/riscv/Kconfig > +++ b/arch/riscv/Kconfig > @@ -137,7 +137,7 @@ config PAGE_OFFSET > default 0xffe0 if 64BIT && MAXPHYSMEM_128GB > > config ARCH_FLATMEM_ENABLE > - def_bool y > + def_bool !NUMA > > config ARCH_SPARSEMEM_ENABLE > def_bool y > @@ -295,6 +295,35 @@ config TUNE_GENERIC > > endchoice > > +# Common NUMA Features > +config NUMA > + bool "Numa Memory Allocation and Scheduler Support" NUMA > + select GENERIC_ARCH_NUMA > + select OF_NUMA > + select ARCH_SUPPORTS_NUMA_BALANCING > + help > + Enable NUMA (Non-Uniform Memory Access) support. > + > + The kernel will try to allocate memory used by a CPU on the > + local memory of the CPU and add some more NUMA awareness to the > kernel. > + > +config NODES_SHIFT > + int "Maximum NUMA Nodes (as a power of 2)" > + range 1 10 > + default "2" > + depends on NEED_MULTIPLE_NODES > + help > + Specify the maximum number of NUMA Nodes available on the target > + system. Increases memory reserved to accommodate various tables. > + > +config USE_PERCPU_NUMA_NODE_ID > + def_bool y > + depends on NUMA > + > +config NEED_PER_CPU_EMBED_FIRST_CHUNK > + def_bool y > + depends on NUMA > + > config RISCV_ISA_C > bool "Emit compressed instructions when building Linux" > default y thanks. -- ~Randy
Re: [GIT pull] irq/urgent for v5.9-rc1
On Fri, Aug 14 2020 at 14:14, Linus Torvalds wrote: > On Fri, Aug 14, 2020 at 9:00 AM Thomas Gleixner wrote: >> >> Two fixes in the core interrupt code which ensure that all error exits >> unlock the descriptor lock. > > No diffstat? > > I've pulled it, but please check what went wrong.. Duh, incomplete restore of environment after replacing the worn out SSD. Fixed. Thanks, tglx
Re: [RFC/RFT PATCH 1/6] numa: Move numa implementation to common code
On 8/14/20 2:47 PM, Atish Patra wrote: > diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig > index 8d7001712062..73c2151de194 100644 > --- a/drivers/base/Kconfig > +++ b/drivers/base/Kconfig > @@ -210,4 +210,10 @@ config GENERIC_ARCH_TOPOLOGY > appropriate scaling, sysfs interface for reading capacity values at > runtime. > > +config GENERIC_ARCH_NUMA > + bool > + help > + Enable support for generic numa implementation. Currently, RISC-V NUMA > + and ARM64 uses it. use it. > + > endmenu thanks. -- ~Randy
Re: [RFC-PATCH 1/2] mm: Add __GFP_NO_LOCKS flag
Paul, On Fri, Aug 14 2020 at 11:01, Paul E. McKenney wrote: > On Fri, Aug 14, 2020 at 04:06:04PM +0200, Michal Hocko wrote: >> > > > Vlastimil raised same question earlier, i answered, but let me answer >> > > > again: >> > > > >> > > > It is hard to achieve because the logic does not stick to certain >> > > > static test >> > > > case, i.e. it depends on how heavily kfree_rcu(single/double) are >> > > > used. Based >> > > > on that, "how heavily" - number of pages are formed, until the >> > > > drain/reclaimer >> > > > thread frees them. >> > > >> > > How many pages are talking about - ball park? 100s, 1000s? >> > >> > Under normal operation, a couple of pages per CPU, which would make >> > preallocation entirely reasonable. Except that if someone does something >> > that floods RCU callbacks (close(open) in a tight userspace loop, for but >> > one example), then 2000 per CPU might not be enough, which on a 64-CPU >> > system comes to about 500MB. This is beyond excessive for preallocation >> > on the systems I am familiar with. >> > >> > And the flooding case is where you most want the reclamation to be >> > efficient, and thus where you want the pages. As we now established that taking zone lock is impossible at all independent of raw/non-raw ordering and independent of RT/PREEMPT configs, can we just take a step back and look at the problem from scratch again? As a matter of fact I assume^Wdeclare that removing struct rcu_head which provides a fallback is not an option at all. I know that you want to, but it wont work ever. Dream on, but as we agreed on recently there is this thing called reality which ruins everything. For normal operations a couple of pages which can be preallocated are enough. What you are concerned of is the case where you run out of pointer storage space. There are two reasons why that can happen: 1) RCU call flooding 2) RCU not being able to run and mop up the backlog #1 is observable by looking at the remaining storage space and the RCU call frequency #2 is uninteresting because it's caused by RCU being stalled / delayed e.g. by a runaway of some sorts or a plain RCU usage bug. Allocating more memory in that case does not solve or improve anything. So the interesting case is #1. Which means we need to look at the potential sources of the flooding: 1) User space via syscalls, e.g. open/close 2) Kernel thread 3) Softirq 4) Device interrupt 5) System interrupts, deep atomic context, NMI ... #1 trivial fix is to force switching to an high prio thread or a soft interrupt which does the allocation #2 Similar to #1 unless that thread loops with interrupts, softirqs or preemption disabled. If that's the case then running out of RCU storage space is the least of your worries. #3 Similar to #2. The obvious candidates (e.g. NET) for monopolizing a CPU have loop limits in place already. If there is a bug which fails to care about the limit, why would RCU care and allocate more memory? #4 Similar to #3. If the interrupt handler loops forever or if the interrupt is a runaway which prevents task/softirq processing then RCU free performance is the least of your worries. #5 Clearly a bug and making RCU accomodate for that is beyond silly. So if call_rcu() detects that the remaining storage space for pointers goes below the critical point or if it observes high frequency calls then it simply should force a soft interrupt which does the allocation. Allocating from softirq context obviously without holding the raw lock which is used inside call_rcu() is safe on all configurations. If call_rcu() is forced to use the fallback for a few calls until this happens then that's not the end of the world. It is not going to be a problem ever for the most obvious issue #1, user space madness, because that case cannot delay the softirq processing unless there is a kernel bug which makes again RCU free performance irrelevant. So this will cure the problem for the most interesting case #1 and handle all sane variants of the other possible flooding sources. The other insane reasons do not justify any attempt to increase RCU performance at all. Watching the remaining storage space is good enough IMO. It clearly covers #1 and for all others the occasional fallback wont hurt. If it really matters for any case > #1 then doing a frequency based prediction is a straight forward optimization. As usual I might be missing something, but as this is the second day with reasonable temperatures here that would be caused by my ignorance and not be excusable by brain usage outside of specified temperature range. Thanks, tglx
Protecting usb_set_interface() against device removal
Hi all, over time, there have been a number of reports of crashes in usb_ifnum_to_if(), called from usb_hcd_alloc_bandwidth, which is in turn called from usb_set_interface(). Examples are [1] [2] [3]. A typical backtrace is: <3>[ 3489.445468] intel_sst_acpi 808622A8:00: sst: Busy wait failed, cant send this msg <6>[ 3490.507273] usb 1-4: USB disconnect, device number 3 <1>[ 3490.516670] BUG: unable to handle kernel NULL pointer dereference at <6>[ 3490.516680] PGD 0 P4D 0 <4>[ 3490.516687] Oops: [#1] PREEMPT SMP PTI <4>[ 3490.516693] CPU: 0 PID: 5633 Comm: V4L2CaptureThre Not tainted 4.19.113-08536-g5d29ca36db06 #1 <4>[ 3490.516696] Hardware name: GOOGLE Edgar, BIOS Google_Edgar.7287.167.156 03/25/2019 <4>[ 3490.516706] RIP: 0010:usb_ifnum_to_if+0x29/0x40 <4>[ 3490.516710] Code: ee 0f 1f 44 00 00 55 48 89 e5 48 8b 8f f8 03 00 00 48 85 c9 74 27 44 0f b6 41 04 4d 85 c0 74 1d 31 ff 48 8b 84 f9 98 00 00 00 <48> 8b 10 0f b6 52 02 39 f2 74 0a 48 ff c7 4c 39 c7 72 e5 31 c0 5d <4>[ 3490.516714] RSP: 0018:a46f42a47a80 EFLAGS: 00010246 <4>[ 3490.516718] RAX: RBX: RCX: 904a396c9000 <4>[ 3490.516721] RDX: 904a39641320 RSI: 0001 RDI: <4>[ 3490.516724] RBP: a46f42a47a80 R08: 0002 R09: <4>[ 3490.516727] R10: 9975 R11: 0009 R12: <4>[ 3490.516731] R13: 904a396b3800 R14: 904a39e88000 R15: <4>[ 3490.516735] FS: 7f396448e700() GS:904a3ba0() knlGS: <4>[ 3490.516738] CS: 0010 DS: ES: CR0: 80050033 <4>[ 3490.516742] CR2: CR3: 00016cb46000 CR4: 001006f0 <4>[ 3490.516745] Call Trace: <4>[ 3490.516756] usb_hcd_alloc_bandwidth+0x1ee/0x30f <4>[ 3490.516762] usb_set_interface+0x1a3/0x2b7 <4>[ 3490.516773] uvc_video_start_transfer+0x29b/0x4b8 [uvcvideo] <4>[ 3490.516781] uvc_video_start_streaming+0x91/0xdd [uvcvideo] <4>[ 3490.516787] uvc_start_streaming+0x28/0x5d [uvcvideo] <4>[ 3490.516795] vb2_start_streaming+0x61/0x143 [videobuf2_common] <4>[ 3490.516801] vb2_core_streamon+0xf7/0x10f [videobuf2_common] <4>[ 3490.516807] uvc_queue_streamon+0x2e/0x41 [uvcvideo] <4>[ 3490.516814] uvc_ioctl_streamon+0x42/0x5c [uvcvideo] <4>[ 3490.516820] __video_do_ioctl+0x33d/0x42a <4>[ 3490.516826] video_usercopy+0x34e/0x5ff <4>[ 3490.516831] ? video_ioctl2+0x16/0x16 <4>[ 3490.516837] v4l2_ioctl+0x46/0x53 <4>[ 3490.516843] do_vfs_ioctl+0x50a/0x76f <4>[ 3490.516848] ksys_ioctl+0x58/0x83 <4>[ 3490.516853] __x64_sys_ioctl+0x1a/0x1e <4>[ 3490.516858] do_syscall_64+0x54/0xde I have been able to reproduce the problem on a Chromebook by strategically placing msleep() calls into usb_set_interface() and usb_disable_device(). Ultimately, the problem boils down to lack of protection against device removal in usb_set_interface() [and/or possibly other callers of usb_ifnum_to_if()]. Sequence of events is roughly as follows: - usb_set_interface() is called and proceeds to some point, possibly to mutex_lock(hcd->bandwidth_mutex); - Device removal event is detected, and usb_disable_device() is called - usb_disable_device() starts removing actconfig data. It has removed and cleared dev->actconfig->interface[i], but not dev->actconfig - usb_set_interface() calls usb_hcd_alloc_bandwidth(), which calls usb_ifnum_to_if() - In usb_ifnum_to_if(), dev->actconfig is not NULL, but dev->actconfig->interface[i] is NULL - crash Question is what we can do about this. Checking if dev->state != USB_STATE_NOTATTACHED in usb_ifnum_to_if() might be a possible approach, but strictly speaking it would still be racy since there is still no lock against device removal. I have not tried calling usb_lock_device() in usb_set_interface() - would that possibly be an option ? Thanks, Guenter --- [1] https://crbug.com/1078293 [2] https://www.spinics.net/lists/linux-usb/msg162583.html [3] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1827452
Re: [GIT PULL] pwm: Changes for v5.9-rc1
The pull request you sent on Fri, 14 Aug 2020 15:03:32 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm.git > tags/pwm/for-5.9-rc1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/fded09198826b2998242ed2e1a16527849884d3f Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] final round of SCSI updates for the 5.8+ merge window
The pull request you sent on Fri, 14 Aug 2020 09:39:36 -0700: > git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-misc has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/c9c9735c46f589b9877b7fc00c89ef1b61a31e18 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] sound fixes for 5.9-rc1
The pull request you sent on Fri, 14 Aug 2020 09:54:26 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git > tags/sound-fix-5.9-rc1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/87bd8c2b93ae899ecd90a5e0550cdae4260cc4ca Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: BUG: unable to handle kernel paging request in free_block (5)
syzbot suspects this issue was fixed by commit: commit 1378817486d6860f6a927f573491afe65287abf1 Author: Eric Dumazet Date: Thu May 21 18:29:58 2020 + tipc: block BH before using dst_cache bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1537694a90 start commit: e6986423 socket: fix compat SO_RCVTIMEO_NEW/SO_SNDTIMEO_NEW git tree: net kernel config: https://syzkaller.appspot.com/x/.config?x=4fb64439e07a1ec0 dashboard link: https://syzkaller.appspot.com/bug?extid=438a5abd4f53adb1c073 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12adddbf20 If the result looks correct, please mark the issue as fixed by replying with: #syz fix: tipc: block BH before using dst_cache For information about bisection process see: https://goo.gl/tpsmEJ#bisection
Re: [PATCH] x86: work around clang IAS bug referencing __force_order
On Fri, Aug 14, 2020 at 2:19 PM Sedat Dilek wrote:
>
> On Fri, Aug 14, 2020 at 7:29 PM Sedat Dilek wrote:
> >
> > Thanks for the proposal.
> >
> > I have adapted it to fit my patchset against Linux v5.8.
> >
> > Both Debian's GCC-10 and a snapshot version of LLVM toolchain
> > v11.0.0-rc1+ seems to be OK.
> >
>
> Yupp, OK.
>
> I was able to boot FreeDOS 1.2 VM in VirtualBox GUI.
Hi Sedat,
Apologies, but it's not clear to me precisely which patch you tested.
Can you please confirm whether you tested:
1. Arnd's patch that started this thread.
2. My proposed diff adding -fno-addrsig to CFLAGS_powernow-k6.o.
3. My proposed diff removing __force_order from the kernel.
I'm hoping you were referring to testing 3., but it's not clear to me.
I've been comparing the full disassemblies of vmlinux images when
built with Clang with 3 applied (they're no different, which is a
pleasant surprise, I didn't think kernel builds woulds would be fully
deterministic given the sheer amount of source). I still need to
check the compressed vmlinux image, and various .ko's (XEN) that use
these read/write_cr[0,1,2,4]() functions, and then check them again
when built with GCC. I'm falling behind a little trying to get our MC
organized for plumbers, as well as the end of intern season and
beginning of bi-annual "performance review" ("not stack ranking" I'm
told) at work. If I don't find any differences, or if I do but don't
find them to be meaningful, I hope to push a more formal patch (rather
than just a diff) maybe next week. I'll include my findings either
way; if it was 3 that you tested, I'll include your tested by tag when
sending. Otherwise maybe you can help us test the more formal patch
next week?
--
Thanks,
~Nick Desaulniers
[PATCH] of/fdt: Remove duplicate check in early_init_dt_scan_memory()
When the value of the first reg is not NULL, there will be
two repeated checks. So modify it.
Signed-off-by: Qi Zheng
---
drivers/of/fdt.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 4602e467ca8b..f54412c00642 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -1002,10 +1002,11 @@ int __init early_init_dt_scan_memory(unsigned long
node, const char *uname,
return 0;
reg = of_get_flat_dt_prop(node, "linux,usable-memory", );
- if (reg == NULL)
+ if (reg == NULL) {
reg = of_get_flat_dt_prop(node, "reg", );
- if (reg == NULL)
- return 0;
+ if (reg == NULL)
+ return 0;
+ }
endp = reg + (l / sizeof(__be32));
hotpluggable = of_get_flat_dt_prop(node, "hotpluggable", NULL);
--
2.25.1
Question on 5.4.55 merge into 5.4-rt
When merging 5.4.55 into 5.4-rt I hit the following conflict:
static void flush_backlog(struct work_struct *work)
{
struct sk_buff *skb, *tmp;
struct softnet_data *sd;
local_bh_disable();
sd = this_cpu_ptr(_data);
local_irq_disable();
rps_lock(sd);
skb_queue_walk_safe(>input_pkt_queue, skb, tmp) {
if (skb->dev->reg_state == NETREG_UNREGISTERING) {
__skb_unlink(skb, >input_pkt_queue);
<<< HEAD
__skb_queue_tail(>tofree_queue, skb);
===
dev_kfree_skb_irq(skb);
>>> v5.4.55
input_queue_head_incr(sd);
}
}
The diff of 5.4.54 -> 5.4.55 of this code is:
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5229,7 +5229,7 @@ static void flush_backlog(struct work_struct *work)
skb_queue_walk_safe(>input_pkt_queue, skb, tmp) {
if (skb->dev->reg_state == NETREG_UNREGISTERING) {
__skb_unlink(skb, >input_pkt_queue);
- kfree_skb(skb);
+ dev_kfree_skb_irq(skb);
input_queue_head_incr(sd);
}
}
>From upstream commit:
7df5cb75cfb8a ("dev: Defer free of skbs in flush_backlog")
According to that commit, it looks like kfree_skb() shouldn't be called
with irqs disabled (yeah for RT!). It now calls dev_kfree_skb_irq()
which puts the skb on the softnet_data.completion_queue, and raises the
NET_TX_SOFTIRQ to do the freeing.
This is similar to what v5.4-rt does, which a diff of 5.4.54 -> v5.4-rt:
@@ -5229,7 +5234,7 @@ static void flush_backlog(struct work_struct *work)
skb_queue_walk_safe(>input_pkt_queue, skb, tmp) {
if (skb->dev->reg_state == NETREG_UNREGISTERING) {
__skb_unlink(skb, >input_pkt_queue);
- kfree_skb(skb);
+ __skb_queue_tail(>tofree_queue, skb);
input_queue_head_incr(sd);
}
}
@@ -5239,11 +5244,14 @@ static void flush_backlog(struct work_struct *work)
skb_queue_walk_safe(>process_queue, skb, tmp) {
if (skb->dev->reg_state == NETREG_UNREGISTERING) {
__skb_unlink(skb, >process_queue);
- kfree_skb(skb);
+ __skb_queue_tail(>tofree_queue, skb);
input_queue_head_incr(sd);
}
}
+ if (!skb_queue_empty(>tofree_queue))
+ raise_softirq_irqoff(NET_RX_SOFTIRQ);
local_bh_enable();
+
}
Where we are doing something slightly different. Placing the skb on the
sd->tofree_queue and raising NET_RX_SOFTIQ instead.
Now that the vanilla stable 5.4 kernel doesn't call kfree_skb() from
irqs_disabled, can I safely revert this entire change?
Is it safe to call kfree_skb() from local_bh_disable()?
I'm assuming it is, but just want to clarify. I'll be continuing
merging latest stable (with this revert), but please yell if you think
it will break?
Thanks!
-- Steve
Re: [PATCH] acpi/nfit: Use kobj_to_dev() instead
On Fri, 2020-08-14 at 17:28 +0200, Rafael J. Wysocki wrote:
> On Thu, Aug 13, 2020 at 4:54 AM Wang Qing wrote:
> > Use kobj_to_dev() instead of container_of()
> >
> > Signed-off-by: Wang Qing
>
> LGTM
>
> Dan, any objections?
Looks good to me - you can add:
Acked-by: Vishal Verma
>
> > ---
> > drivers/acpi/nfit/core.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
> > index fa4500f..3bb350b
> > --- a/drivers/acpi/nfit/core.c
> > +++ b/drivers/acpi/nfit/core.c
> > @@ -1382,7 +1382,7 @@ static bool ars_supported(struct nvdimm_bus
> > *nvdimm_bus)
> >
> > static umode_t nfit_visible(struct kobject *kobj, struct attribute *a, int
> > n)
> > {
> > - struct device *dev = container_of(kobj, struct device, kobj);
> > + struct device *dev = kobj_to_dev(kobj);
> > struct nvdimm_bus *nvdimm_bus = to_nvdimm_bus(dev);
> >
> > if (a == _attr_scrub.attr && !ars_supported(nvdimm_bus))
> > @@ -1667,7 +1667,7 @@ static struct attribute *acpi_nfit_dimm_attributes[]
> > = {
> > static umode_t acpi_nfit_dimm_attr_visible(struct kobject *kobj,
> > struct attribute *a, int n)
> > {
> > - struct device *dev = container_of(kobj, struct device, kobj);
> > + struct device *dev = kobj_to_dev(kobj);
> > struct nvdimm *nvdimm = to_nvdimm(dev);
> > struct nfit_mem *nfit_mem = nvdimm_provider_data(nvdimm);
> >
> > --
> > 2.7.4
> >
Re: [PATCH v4 1/5] of_address: Add bus type match for pci ranges parser
On Fri, Aug 14, 2020 at 12:21 PM Marc Zyngier wrote:
>
> Hi all,
>
> On 2020-07-28 16:36, Jiaxun Yang wrote:
> > So the parser can be used to parse range property of ISA bus.
> >
> > As they're all using PCI-like method of range property, there is no
> > need
> > start a new parser.
> >
> > Signed-off-by: Jiaxun Yang
> > Reviewed-by: Rob Herring
>
> This patch, although it looks correct, breaks the RK3399-based
> systems, as they miss the (now required) 'device_type = "pci";'
> property.
Required since 1990 something...
> We can fix the in-tree DT, but that's not really an option
> if someone relies on the DT being provided by the firmware
> (I for one definitely do).
Perhaps time to pay attention to schema errors:
arch/arm64/boot/dts/rockchip/rk3399-sapphire-excavator.dt.yaml:
pcie@f800: 'device_type' is a required property
(I thought dtc would also catch this, but there we look for
device_type and then do PCI checks like node name. I guess we needed
to check for either device_type or the node name...)
> I came up with the following hack, which solves the issue for
> me. Definitely not my finest hour, but I really need this box
> to keep going. I will post a patch fixing the DT separately.
>
> Thanks,
>
> M.
>
> From ceef5fd9c4d2005eb577505c68868ebe527c098f Mon Sep 17 00:00:00 2001
> From: Marc Zyngier
> Date: Fri, 14 Aug 2020 19:10:12 +0100
> Subject: [PATCH] of: address: Workaround broken DTs missing the
> 'device_type =
> "pci"' property
>
> Recent changes to the PCI bus parsing made it mandatory for
> device trees nodes describing a PCI controller to have the
> 'device_type = "pci"' property for the node to be matched.
>
> Although this is compliant with the specification, it breaks
> existing device-trees that have been working fine for years
> (the Rockchip rk3399-based systems being a prime example of
> such breakage).
>
> In order to paper over the blunder, let's also match nodes
> that have the "linux,pci-domain" property, as they are
> pretty likely to be PCI nodes. This fixes the issue for
> systems such as the above platforms.
>
> Fixes: 2f96593ecc37 ("of_address: Add bus type match for pci ranges
> parser")
> Signed-off-by: Marc Zyngier
> ---
> drivers/of/address.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 590493e04b01..712e03781a2a 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -134,9 +134,12 @@ static int of_bus_pci_match(struct device_node *np)
> * "pciex" is PCI Express
> * "vci" is for the /chaos bridge on 1st-gen PCI powermacs
> * "ht" is hypertransport
> +* "linux,pci-domain" is a workaround for broken device trees
> +* lacking the required "device_type" property.
I would suggest looking for 'pci' or 'pcie' node name instead.
You should remove linux,pci-domain from rk3399 as it is pointless when
there's a single PCI host bridge.
The other option is fixup the live tree with of_add_property() in the
Rockchip PCI driver. Less likely to impact anyone else.
> */
> return of_node_is_type(np, "pci") || of_node_is_type(np, "pciex") ||
> - of_node_is_type(np, "vci") || of_node_is_type(np, "ht");
> + of_node_is_type(np, "vci") || of_node_is_type(np, "ht") ||
> + of_find_property(np, "linux,pci-domain", NULL);
> }
>
> static void of_bus_pci_count_cells(struct device_node *np,
> --
> 2.27.0
>
>
> --
> Jazz is not dead. It just smells funny...
[PATCH] ARM: dts: stm32: add display controller node to stm32h743
The stm32h743 has a display controller. This commit adds it to the
device tree.
Signed-off-by: Tobias Schramm
---
arch/arm/boot/dts/stm32h743.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/stm32h743.dtsi b/arch/arm/boot/dts/stm32h743.dtsi
index 7c612db9efcf..7febe19e780d 100644
--- a/arch/arm/boot/dts/stm32h743.dtsi
+++ b/arch/arm/boot/dts/stm32h743.dtsi
@@ -334,6 +334,16 @@ usbotg_fs: usb@4008 {
status = "disabled";
};
+ ltdc: display-controller@50001000 {
+ compatible = "st,stm32-ltdc";
+ reg = <0x50001000 0x200>;
+ interrupts = <88>, <89>;
+ resets = < STM32H7_APB3_RESET(LTDC)>;
+ clocks = < LTDC_CK>;
+ clock-names = "lcd";
+ status = "disabled";
+ };
+
mdma1: dma-controller@5200 {
compatible = "st,stm32h7-mdma";
reg = <0x5200 0x1000>;
--
2.28.0
Re: [PATCH v3 00/21] x86/kaslr: Cleanup and small bugfixes
On Fri, Jul 31, 2020 at 04:33:35PM -0700, Kees Cook wrote: > On Fri, Jul 31, 2020 at 11:21:46AM +0200, Ingo Molnar wrote: > > > > * Arvind Sankar wrote: > > > > > On Tue, Jul 28, 2020 at 06:57:01PM -0400, Arvind Sankar wrote: > > > > v2->v3: > > > > - Fix the first patch: command line size should be strlen + 1 to account > > > > for terminating NUL. Avoid calling add_identity_map if cmdline was > > > > NULL, though it should do nothing in that case anyway. > > > > > > Hi Ingo, I noticed that WIP.x86/kaslr and x86/kaslr both have the v2 > > > version of the first patch. That has a bug in the cmd_line_size > > > calculation (missing the +1). > > > > Indeed, well spotted. I rebased the affected 4 patches in x86/kaslr > > and used the opportunity to add Kees's Reviewed-by to the first 4 > > patches as well. > > > > I've zapped tip:x86/kaslr for now and put the whole series into > > tip:WIP.x86/kaslr, will move it into tip:x86/kaslr for a v5.9 merge > > once Kees is happy with the latest version. > > > > Kees, AFAICS your type truncation and patch split-up review > > suggestions were resolved in v3? > > I need to double-check, but I think so. I'm hoping to get to that on > Monday. My orphan section series work took MUCH longer than I thought it > was going to. :P > > -- > Kees Cook Hey Kees, did you get a chance to review? Thanks.
Re: POC: Alternative solution: Re: [PATCH 0/4] printk: reimplement LOG_CONT handling
On Thu, Aug 13, 2020 at 4:54 AM Sergey Senozhatsky
wrote:
>
> I think what Linus said a long time ago was that the initial purpose of
> pr_cont was
>
> pr_info("Initialize feature foo...");
> if (init_feature_foo() == 0)
> pr_cont("ok\n");
> else
> pr_cont("not ok\n");
>
> And if init_feature_foo() crashes the kernel then the first printk()
> form panic() will flush the cont buffer.
Right.
This is why I think any discussion that says "people should buffer
their lines themselves and we should get rid if pr_cont()" is
fundamentally broken.
Don't go down that hole. I won't take it. It's wrong.
The fact is, pr_cont() goes back to the original kernel. No, it wasn't
pr_cont() back then, and no, there were no actual explicit markers for
"this is a continuation" at all, it was all just "the last printk
didn't have a newline, so we continue where we left off".
We've added pr_cont (and KERN_CONT) since then, and I realize that a
lot of people hate the complexity it introduces, but it's a
fundamental complexity that you have to live with.
If you can't live with pr_cont(), you shouldn't be working on
printk(), and find some other area of the kernel that you _can_ live
with.
It really is that simple.
Linus
Re: [PATCH v2] riscv: Setup exception vector for nommu platform
On Thu, 13 Aug 2020 01:49:44 PDT (-0700), a...@brainfault.org wrote:
On Thu, Aug 13, 2020 at 9:10 AM Qiu Wenbo wrote:
Exception vector is missing on nommu platform and that is an issue.
This patch is tested in Sipeed Maix Bit Dev Board.
Fixes: 79b1feba5455 ("RISC-V: Setup exception vector early")
Suggested-by: Anup Patel
Suggested-by: Atish Patra
Signed-off-by: Qiu Wenbo
---
arch/riscv/kernel/head.S | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/arch/riscv/kernel/head.S b/arch/riscv/kernel/head.S
index d0c5c316e9bb..0a4e81b8dc79 100644
--- a/arch/riscv/kernel/head.S
+++ b/arch/riscv/kernel/head.S
@@ -77,16 +77,10 @@ relocate:
csrw CSR_SATP, a0
.align 2
1:
- /* Set trap vector to exception handler */
- la a0, handle_exception
+ /* Set trap vector to spin forever to help debug */
+ la a0, .Lsecondary_park
csrw CSR_TVEC, a0
- /*
-* Set sup0 scratch register to 0, indicating to exception vector that
-* we are presently executing in kernel.
-*/
- csrw CSR_SCRATCH, zero
-
/* Reload the global pointer */
.option push
.option norelax
@@ -144,9 +138,23 @@ secondary_start_common:
la a0, swapper_pg_dir
call relocate
#endif
+ call setup_trap_vector
tail smp_callin
#endif /* CONFIG_SMP */
+.align 2
+setup_trap_vector:
+ /* Set trap vector to exception handler */
+ la a0, handle_exception
+ csrw CSR_TVEC, a0
+
+ /*
+* Set sup0 scratch register to 0, indicating to exception vector that
+* we are presently executing in kernel.
+*/
+ csrw CSR_SCRATCH, zero
+ ret
+
.Lsecondary_park:
/* We lack SMP support or have too many harts, so park this hart */
wfi
@@ -240,6 +248,7 @@ clear_bss_done:
call relocate
#endif /* CONFIG_MMU */
+ call setup_trap_vector
/* Restore C environment */
la tp, init_task
sw zero, TASK_TI_CPU(tp)
--
2.28.0
Looks good to me.
Reviewed-by: Anup Patel
Regards,
Anup
Thanks, this is on fixes.
Re: [PATCH v3] i2c: iproc: fix race between client unreg and isr
On 8/12/2020 1:06 PM, Wolfram Sang wrote:
> On Mon, Aug 10, 2020 at 05:42:40PM -0700, Dhananjay Phadke wrote:
>> When i2c client unregisters, synchronize irq before setting
>> iproc_i2c->slave to NULL.
>>
>> (1) disable_irq()
>> (2) Mask event enable bits in control reg
>> (3) Erase slave address (avoid further writes to rx fifo)
>> (4) Flush tx and rx FIFOs
>> (5) Clear pending event (interrupt) bits in status reg
>> (6) enable_irq()
>> (7) Set client pointer to NULL
>>
>> Unable to handle kernel NULL pointer dereference at virtual address
>> 0318
>>
>> [ 371.020421] pc : bcm_iproc_i2c_isr+0x530/0x11f0
>> [ 371.025098] lr : __handle_irq_event_percpu+0x6c/0x170
>> [ 371.030309] sp : 800010003e40
>> [ 371.033727] x29: 800010003e40 x28: 0060
>> [ 371.039206] x27: 800010ca9de0 x26: 800010f895df
>> [ 371.044686] x25: 800010f1 x24: 0008f7ff3600
>> [ 371.050165] x23: 0003 x22: 0160
>> [ 371.055645] x21: 800010f1 x20: 0160
>> [ 371.061124] x19: 0008f726f080 x18:
>> [ 371.066603] x17: x16:
>> [ 371.072082] x15: x14:
>> [ 371.077561] x13: x12: 0001
>> [ 371.083040] x11: x10: 0040
>> [ 371.088519] x9 : 800010f317c8 x8 : 800010f317c0
>> [ 371.093999] x7 : 0008f805b3b0 x6 :
>> [ 371.099478] x5 : 0008f7ff36a4 x4 : 8008ee43d000
>> [ 371.104957] x3 : x2 : 8000107d64c0
>> [ 371.110436] x1 : c0af x0 :
>>
>> [ 371.115916] Call trace:
>> [ 371.118439] bcm_iproc_i2c_isr+0x530/0x11f0
>> [ 371.122754] __handle_irq_event_percpu+0x6c/0x170
>> [ 371.127606] handle_irq_event_percpu+0x34/0x88
>> [ 371.132189] handle_irq_event+0x40/0x120
>> [ 371.136234] handle_fasteoi_irq+0xcc/0x1a0
>> [ 371.140459] generic_handle_irq+0x24/0x38
>> [ 371.144594] __handle_domain_irq+0x60/0xb8
>> [ 371.148820] gic_handle_irq+0xc0/0x158
>> [ 371.152687] el1_irq+0xb8/0x140
>> [ 371.155927] arch_cpu_idle+0x10/0x18
>> [ 371.159615] do_idle+0x204/0x290
>> [ 371.162943] cpu_startup_entry+0x24/0x60
>> [ 371.166990] rest_init+0xb0/0xbc
>> [ 371.170322] arch_call_rest_init+0xc/0x14
>> [ 371.174458] start_kernel+0x404/0x430
>>
>> Fixes: c245d94ed106 ("i2c: iproc: Add multi byte read-write support for
>> slave mode")
>>
>> Signed-off-by: Dhananjay Phadke
>
> Applied to for-next (i.e. 5.9), thanks!
>
> BTW my code checkers found this (unrelated to this patch):
>
> ===
> CPPCHECK
> drivers/i2c/busses/i2c-bcm-iproc.c:723:14: warning: Shifting signed 32-bit
> value by 31 bits is undefined behaviour [shiftTooManyBitsSigned]
> val |= 1 << M_TX_WR_STATUS_SHIFT;
> ^
> drivers/i2c/busses/i2c-bcm-iproc.c:741:19: warning: Shifting signed 32-bit
> value by 31 bits is undefined behaviour [shiftTooManyBitsSigned]
> val = addr | (1 << M_TX_WR_STATUS_SHIFT);
> ^
> ===
>
> Use the BIT macro here.
>
Thanks, Wolfram. I just sent out a separate patch to address that.
Re: [PATCH] dma-debug: fix debug_dma_assert_idle(), use rcu_read_lock()
On Thu, Aug 13, 2020 at 10:42 PM Christoph Hellwig wrote: > > The whole thing predates my involvement with the code, but I defintively > think the patch from Hugh is a major improvement. But I would also > have no problem with just removing it entirely. I decided to just do both, since neither you nor Dan seemed to really object. I applied Hugh's RCU read locking patch as a clear improvement, and then I did a second patch that just removed this function entirely. That sounds a bit odd, perhaps, but in case people decide to resurrect the debugging code, I didn't want us to lose sight of Hugh's improvement just because I then decided that we might as well go one step further and just remove it entirely. And the only real reason I care is that this whole COW and page lock thing has showed up lately, and I like removing code. I'm _very_ tempted to just apply my COW simplification patch that gets rid of all the complex try-to-share cases entirely (and would also obviate the whole forced-cow patch). I suspect it would effectively remove almost all of the [un[lock_page() bottlenecks entirely, but that code has decades of history and I suspect it's a bit too drastic wrt KSM and the swap cache pages. It would be lovely if the main source of page locking would really be about just IO, but the page lock has also become the thing that serializes almost everything related to page state. Which is why you find it in contexts that are really not IO-related at all (not just COW - page migration is the other one that has shown up a lot under "heavy CPU loads" without really necessarily any IO component to it). Linus
[PATCH] i2c: iproc: Fix checkpatch warnings by using 'BIT' macro
Fix additional checkpatch warnings in the iProc I2C driver by using 'BIT' marcro. Reported-by: Wolfram Sang Signed-off-by: Ray Jui --- drivers/i2c/busses/i2c-bcm-iproc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/i2c/busses/i2c-bcm-iproc.c b/drivers/i2c/busses/i2c-bcm-iproc.c index 688e92818821..d8295b1c379d 100644 --- a/drivers/i2c/busses/i2c-bcm-iproc.c +++ b/drivers/i2c/busses/i2c-bcm-iproc.c @@ -720,7 +720,7 @@ static int bcm_iproc_i2c_xfer_internal(struct bcm_iproc_i2c_dev *iproc_i2c, /* mark the last byte */ if (!process_call && (i == msg->len - 1)) - val |= 1 << M_TX_WR_STATUS_SHIFT; + val |= BIT(M_TX_WR_STATUS_SHIFT); iproc_i2c_wr_reg(iproc_i2c, M_TX_OFFSET, val); } @@ -738,7 +738,7 @@ static int bcm_iproc_i2c_xfer_internal(struct bcm_iproc_i2c_dev *iproc_i2c, */ addr = i2c_8bit_addr_from_msg(msg); /* mark it the last byte out */ - val = addr | (1 << M_TX_WR_STATUS_SHIFT); + val = addr | BIT(M_TX_WR_STATUS_SHIFT); iproc_i2c_wr_reg(iproc_i2c, M_TX_OFFSET, val); } -- 2.17.1
Re: [PATCH v3 3/7] riscv: Fixup kprobes handler couldn't change pc
On Mon, 13 Jul 2020 16:39:18 PDT (-0700), guo...@kernel.org wrote: From: Guo Ren The "Changing Execution Path" section in the Documentation/kprobes.txt said: Since kprobes can probe into a running kernel code, it can change the register set, including instruction pointer. Signed-off-by: Guo Ren Cc: Masami Hiramatsu Cc: Palmer Dabbelt --- arch/riscv/kernel/mcount-dyn.S | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/riscv/kernel/mcount-dyn.S b/arch/riscv/kernel/mcount-dyn.S index 35a6ed7..4b58b54 100644 --- a/arch/riscv/kernel/mcount-dyn.S +++ b/arch/riscv/kernel/mcount-dyn.S @@ -123,6 +123,7 @@ ENDPROC(ftrace_caller) sd ra, (PT_SIZE_ON_STACK+8)(sp) addis0, sp, (PT_SIZE_ON_STACK+16) + sd ra, PT_EPC(sp) sd x1, PT_RA(sp) sd x2, PT_SP(sp) sd x3, PT_GP(sp) So that's definately not going to be EPC any more. I'm not sure that field is sanely named, though, as it's really just the PC when it comes to other ptrace stuff. @@ -157,6 +158,7 @@ ENDPROC(ftrace_caller) .endm .macro RESTORE_ALL + ld ra, PT_EPC(sp) ld x1, PT_RA(sp) x1 is ra, so loading it twice doesn't seem reasonable. ld x2, PT_SP(sp) ld x3, PT_GP(sp) @@ -190,7 +192,6 @@ ENDPROC(ftrace_caller) ld x31, PT_T6(sp) ld s0, (PT_SIZE_ON_STACK)(sp) - ld ra, (PT_SIZE_ON_STACK+8)(sp) addisp, sp, (PT_SIZE_ON_STACK+16) .endm If you're dropping the load you should drop the store above as well. In general this seems kind of mixed up, both before and after this patch.
[PATCH] ARM: dts: stm32: add resets property to spi device nodes on stm32h743
The stm32 spi driver tries to determine the fifo size of spi devices
dynamically. However, if the spi was already configured by the bootloader
the fifo size check can become an endless loop, because the driver
expects the spi to be in its initial "after device reset" state. The
driver does already support resetting the spi device at probe, thus this
patch adds only the required device tree properties
Signed-off-by: Tobias Schramm
---
arch/arm/boot/dts/stm32h743.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/stm32h743.dtsi b/arch/arm/boot/dts/stm32h743.dtsi
index 9dd58974bf8d..7c612db9efcf 100644
--- a/arch/arm/boot/dts/stm32h743.dtsi
+++ b/arch/arm/boot/dts/stm32h743.dtsi
@@ -110,6 +110,7 @@ spi2: spi@40003800 {
compatible = "st,stm32h7-spi";
reg = <0x40003800 0x400>;
interrupts = <36>;
+ resets = < STM32H7_APB1L_RESET(SPI2)>;
clocks = < SPI2_CK>;
status = "disabled";
@@ -121,6 +122,7 @@ spi3: spi@40003c00 {
compatible = "st,stm32h7-spi";
reg = <0x40003c00 0x400>;
interrupts = <51>;
+ resets = < STM32H7_APB1L_RESET(SPI3)>;
clocks = < SPI3_CK>;
status = "disabled";
};
@@ -207,6 +209,7 @@ spi1: spi@40013000 {
compatible = "st,stm32h7-spi";
reg = <0x40013000 0x400>;
interrupts = <35>;
+ resets = < STM32H7_APB2_RESET(SPI1)>;
clocks = < SPI1_CK>;
status = "disabled";
};
@@ -217,6 +220,7 @@ spi4: spi@40013400 {
compatible = "st,stm32h7-spi";
reg = <0x40013400 0x400>;
interrupts = <84>;
+ resets = < STM32H7_APB2_RESET(SPI4)>;
clocks = < SPI4_CK>;
status = "disabled";
};
@@ -227,6 +231,7 @@ spi5: spi@40015000 {
compatible = "st,stm32h7-spi";
reg = <0x40015000 0x400>;
interrupts = <85>;
+ resets = < STM32H7_APB2_RESET(SPI5)>;
clocks = < SPI5_CK>;
status = "disabled";
};
@@ -372,6 +377,7 @@ spi6: spi@58001400 {
compatible = "st,stm32h7-spi";
reg = <0x58001400 0x400>;
interrupts = <86>;
+ resets = < STM32H7_APB4_RESET(SPI6)>;
clocks = < SPI6_CK>;
status = "disabled";
};
--
2.28.0
Re: [PATCH v3 4/7] riscv: Add kprobes supported
On Mon, 13 Jul 2020 16:39:19 PDT (-0700), guo...@kernel.org wrote:
From: Guo Ren
This patch enables "kprobe & kretprobe" to work with ftrace
interface. It utilized software breakpoint as single-step
mechanism.
Some instructions which can't be single-step executed must be
simulated in kernel execution slot, such as: branch, jal, auipc,
la ...
Some instructions should be rejected for probing and we use a
blacklist to filter, such as: ecall, ebreak, ...
We use ebreak & c.ebreak to replace origin instruction and the
kprobe handler prepares an executable memory slot for out-of-line
execution with a copy of the original instruction being probed.
In execution slot we add ebreak behind original instruction to
simulate a single-setp mechanism.
The patch is based on packi's work [1] and csky's work [2].
- The kprobes_trampoline.S is all from packi's patch
- The single-step mechanism is new designed for riscv without hw
single-step trap
- The simulation codes are from csky
- Frankly, all codes refer to other archs' implementation
[1] https://lore.kernel.org/linux-riscv/20181113195804.22825-1...@packi.ch/
[2]
https://lore.kernel.org/linux-csky/20200403044150.20562-9-guo...@kernel.org/
Signed-off-by: Guo Ren
Co-Developed-by: Patrick Stählin
Acked-by: Masami Hiramatsu
Tested-by: Zong Li
Reviewed-by: Pekka Enberg
Cc: Patrick Stählin
Cc: Palmer Dabbelt
Cc: Björn Töpel
---
arch/riscv/Kconfig| 2 +
arch/riscv/include/asm/kprobes.h | 40 +++
arch/riscv/include/asm/probes.h | 24 ++
arch/riscv/kernel/Makefile| 1 +
arch/riscv/kernel/probes/Makefile | 4 +
arch/riscv/kernel/probes/decode-insn.c| 48 +++
arch/riscv/kernel/probes/decode-insn.h| 18 +
arch/riscv/kernel/probes/kprobes.c| 471 ++
arch/riscv/kernel/probes/kprobes_trampoline.S | 93 +
arch/riscv/kernel/probes/simulate-insn.c | 85 +
arch/riscv/kernel/probes/simulate-insn.h | 47 +++
arch/riscv/kernel/traps.c | 9 +
arch/riscv/mm/fault.c | 4 +
13 files changed, 846 insertions(+)
create mode 100644 arch/riscv/include/asm/probes.h
create mode 100644 arch/riscv/kernel/probes/Makefile
create mode 100644 arch/riscv/kernel/probes/decode-insn.c
create mode 100644 arch/riscv/kernel/probes/decode-insn.h
create mode 100644 arch/riscv/kernel/probes/kprobes.c
create mode 100644 arch/riscv/kernel/probes/kprobes_trampoline.S
create mode 100644 arch/riscv/kernel/probes/simulate-insn.c
create mode 100644 arch/riscv/kernel/probes/simulate-insn.h
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index e70449a..b86b2a2 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -59,6 +59,8 @@ config RISCV
select HAVE_EBPF_JIT if MMU
select HAVE_FUTEX_CMPXCHG if FUTEX
select HAVE_GENERIC_VDSO if MMU && 64BIT
+ select HAVE_KPROBES
+ select HAVE_KRETPROBES
select HAVE_PCI
select HAVE_PERF_EVENTS
select HAVE_PERF_REGS
diff --git a/arch/riscv/include/asm/kprobes.h b/arch/riscv/include/asm/kprobes.h
index 56a98ea3..4647d38 100644
--- a/arch/riscv/include/asm/kprobes.h
+++ b/arch/riscv/include/asm/kprobes.h
@@ -11,4 +11,44 @@
#include
+#ifdef CONFIG_KPROBES
+#include
+#include
+#include
+
+#define __ARCH_WANT_KPROBES_INSN_SLOT
+#define MAX_INSN_SIZE 2
+
+#define flush_insn_slot(p) do { } while (0)
+#define kretprobe_blacklist_size 0
+
+#include
+
+struct prev_kprobe {
+ struct kprobe *kp;
+ unsigned int status;
+};
+
+/* Single step context for kprobe */
+struct kprobe_step_ctx {
+ unsigned long ss_pending;
+ unsigned long match_addr;
+};
+
+/* per-cpu kprobe control block */
+struct kprobe_ctlblk {
+ unsigned int kprobe_status;
+ unsigned long saved_status;
+ struct prev_kprobe prev_kprobe;
+ struct kprobe_step_ctx ss_ctx;
+};
+
+void arch_remove_kprobe(struct kprobe *p);
+int kprobe_fault_handler(struct pt_regs *regs, unsigned int trapnr);
+bool kprobe_breakpoint_handler(struct pt_regs *regs);
+bool kprobe_single_step_handler(struct pt_regs *regs);
+void kretprobe_trampoline(void);
+void __kprobes *trampoline_probe_handler(struct pt_regs *regs);
+
+#endif /* CONFIG_KPROBES */
#endif /* _ASM_RISCV_KPROBES_H */
diff --git a/arch/riscv/include/asm/probes.h b/arch/riscv/include/asm/probes.h
new file mode 100644
index ..a787e6d
--- /dev/null
+++ b/arch/riscv/include/asm/probes.h
@@ -0,0 +1,24 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef _ASM_RISCV_PROBES_H
+#define _ASM_RISCV_PROBES_H
+
+typedef u32 probe_opcode_t;
+typedef bool (probes_handler_t) (u32 opcode, unsigned long addr, struct
pt_regs *);
+
+/* architecture specific copy of original instruction */
+struct arch_probe_insn {
+ probe_opcode_t *insn;
+ probes_handler_t *handler;
+ /* restore address
Re: [PATCH 1/2][next] scripts/gdb: add utils.read_ulong()
On Fri, Aug 14, 2020 at 2:25 PM John Ogness wrote: > > Add a function for reading unsigned long values, which vary in size > depending on the architecture. > > Signed-off-by: John Ogness Reviewed-by: Nick Desaulniers /me wonders if there's any non-ILP32 or LP64 ARCH='s supported by the kernel. > --- > > based on next-20200814 > > scripts/gdb/linux/utils.py | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/scripts/gdb/linux/utils.py b/scripts/gdb/linux/utils.py > index ea94221dbd39..ff7c1799d588 100644 > --- a/scripts/gdb/linux/utils.py > +++ b/scripts/gdb/linux/utils.py > @@ -123,6 +123,13 @@ def read_u64(buffer, offset): > return read_u32(buffer, offset + 4) + (read_u32(buffer, offset) << > 32) > > > +def read_ulong(buffer, offset): > +if get_long_type().sizeof == 8: > +return read_u64(buffer, offset) > +else: > +return read_u32(buffer, offset) > + > + > target_arch = None > > > -- > 2.20.1 > -- Thanks, ~Nick Desaulniers
[ANNOUNCE] 5.4.54-rt33
Dear RT Folks,
I'm pleased to announce the 5.4.54-rt33 stable release.
You can get this release via the git tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git
branch: v5.4-rt
Head SHA1: 8b0dbd94090c0b782f374bb645a93517b6b8d887
Or to build 5.4.54-rt33 directly, the following patches should be applied:
http://www.kernel.org/pub/linux/kernel/v5.x/linux-5.4.tar.xz
http://www.kernel.org/pub/linux/kernel/v5.x/patch-5.4.54.xz
http://www.kernel.org/pub/linux/kernel/projects/rt/5.4/patch-5.4.54-rt33.patch.xz
You can also build from 5.4.54-rt32 by applying the incremental patch:
http://www.kernel.org/pub/linux/kernel/projects/rt/5.4/incr/patch-5.4.54-rt32-rt33.patch.xz
Enjoy,
-- Steve
Changes from v5.4.54-rt32:
---
Ahmed S. Darwish (1):
net: phy: fixed_phy: Remove unused seqcount
Matt Fleming (1):
signal: Prevent double-free of user struct
Sebastian Andrzej Siewior (3):
workqueue: Sync with upstream
Bluetooth: Acquire sk_lock.slock without disabling interrupts
rwsem: Provide down_read_non_owner() and up_read_non_owner() for -RT
Steven Rostedt (VMware) (1):
Linux 5.4.54-rt33
drivers/net/phy/fixed_phy.c | 28 +++-
include/linux/swait.h | 14 --
kernel/locking/rwsem.c | 8
kernel/signal.c | 4 ++--
kernel/workqueue.c | 28 +++-
localversion-rt | 2 +-
net/bluetooth/rfcomm/sock.c | 7 ++-
7 files changed, 39 insertions(+), 52 deletions(-)
---
diff --git a/drivers/net/phy/fixed_phy.c b/drivers/net/phy/fixed_phy.c
index 4190f9ed5313..9ed715e9be40 100644
--- a/drivers/net/phy/fixed_phy.c
+++ b/drivers/net/phy/fixed_phy.c
@@ -19,7 +19,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -34,7 +33,6 @@ struct fixed_mdio_bus {
struct fixed_phy {
int addr;
struct phy_device *phydev;
- seqcount_t seqcount;
struct fixed_phy_status status;
bool no_carrier;
int (*link_update)(struct net_device *, struct fixed_phy_status *);
@@ -80,19 +78,17 @@ static int fixed_mdio_read(struct mii_bus *bus, int
phy_addr, int reg_num)
list_for_each_entry(fp, >phys, node) {
if (fp->addr == phy_addr) {
struct fixed_phy_status state;
- int s;
-
- do {
- s = read_seqcount_begin(>seqcount);
- fp->status.link = !fp->no_carrier;
- /* Issue callback if user registered it. */
- if (fp->link_update)
-
fp->link_update(fp->phydev->attached_dev,
- >status);
- /* Check the GPIO for change in status */
- fixed_phy_update(fp);
- state = fp->status;
- } while (read_seqcount_retry(>seqcount, s));
+
+ fp->status.link = !fp->no_carrier;
+
+ /* Issue callback if user registered it. */
+ if (fp->link_update)
+ fp->link_update(fp->phydev->attached_dev,
+ >status);
+
+ /* Check the GPIO for change in status */
+ fixed_phy_update(fp);
+ state = fp->status;
return swphy_read_reg(reg_num, );
}
@@ -150,8 +146,6 @@ static int fixed_phy_add_gpiod(unsigned int irq, int
phy_addr,
if (!fp)
return -ENOMEM;
- seqcount_init(>seqcount);
-
if (irq != PHY_POLL)
fmb->mii_bus->irq[phy_addr] = irq;
diff --git a/include/linux/swait.h b/include/linux/swait.h
index 21ae66cd41d3..f426a0661aa0 100644
--- a/include/linux/swait.h
+++ b/include/linux/swait.h
@@ -299,18 +299,4 @@ do {
\
__ret; \
})
-#define __swait_event_lock_irq(wq, condition, lock, cmd) \
- ___swait_event(wq, condition, TASK_UNINTERRUPTIBLE, 0, \
- raw_spin_unlock_irq(); \
- cmd; \
- schedule(); \
- raw_spin_lock_irq())
-
-#define swait_event_lock_irq(wq_head, condition, lock) \
- do {\
- if (condition) \
- break; \
-
Re: [PATCH 0/2][next] update gdb scripts for lockless printk ringbuffer
On Fri, Aug 14, 2020 at 2:25 PM John Ogness wrote: > > Hi, > > When we brought in the new lockless printk ringbuffer, we overlooked the gdb > scripts. Here are a set of patches to implement gdb support for the new > ringbuffer. > > John Ogness (2): > scripts/gdb: add utils.read_ulong() > scripts/gdb: update for lockless printk ringbuffer Thanks John! For the series: Tested-by: Nick Desaulniers > > Documentation/admin-guide/kdump/gdbmacros.txt | 153 -- > scripts/gdb/linux/dmesg.py| 139 +++- > scripts/gdb/linux/utils.py| 7 + > 3 files changed, 216 insertions(+), 83 deletions(-) > > -- > 2.20.1 > -- Thanks, ~Nick Desaulniers
[PATCH] bluetooth: Set ext scan response only when it exists
Only set extended scan response only when it exists. Otherwise, clear the scan response data. Per the core spec v5.2, Vol 4, Part E, 7.8.55 If the advertising set is non-scannable and the Host uses this command other than to discard existing data, the Controller shall return the error code Invalid HCI Command Parameters (0x12). On WCN3991, the controller correctly responds with Invalid Parameters when this is sent. That error causes __hci_req_hci_power_on to fail with -EINVAL and LE devices can't connect because background scanning isn't configured. Here is an hci trace of where this issue occurs during power on: < HCI Command: LE Set Extended Advertising Parameters (0x08|0x0036) plen 25 Handle: 0x00 Properties: 0x0010 Use legacy advertising PDUs: ADV_NONCONN_IND Min advertising interval: 181.250 msec (0x0122) Max advertising interval: 181.250 msec (0x0122) Channel map: 37, 38, 39 (0x07) Own address type: Random (0x01) Peer address type: Public (0x00) Peer address: 00:00:00:00:00:00 (OUI 00-00-00) Filter policy: Allow Scan Request from Any, Allow Connect... TX power: 127 dbm (0x7f) Primary PHY: LE 1M (0x01) Secondary max skip: 0x00 Secondary PHY: LE 1M (0x01) SID: 0x00 Scan request notifications: Disabled (0x00) > HCI Event: Command Complete (0x0e) plen 5 LE Set Extended Advertising Parameters (0x08|0x0036) ncmd 1 Status: Success (0x00) TX power (selected): 9 dbm (0x09) < HCI Command: LE Set Advertising Set Random Address (0x08|0x0035) plen 7 Advertising handle: 0x00 Advertising random address: 08:FD:55:ED:22:28 (OUI 08-FD-55) > HCI Event: Command Complete (0x0e) plen 4 LE Set Advertising Set Random Address (0x08|0x0035) ncmd Status: Success (0x00) < HCI Command: LE Set Extended Scan Response Data (0x08|0x0038) plen 35 Handle: 0x00 Operation: Complete scan response data (0x03) Fragment preference: Minimize fragmentation (0x01) Data length: 0x0d Name (short): Chromebook > HCI Event: Command Complete (0x0e) plen 4 LE Set Extended Scan Response Data (0x08|0x0038) ncmd 1 Status: Invalid HCI Command Parameters (0x12) Signed-off-by: Abhishek Pandit-Subedi Reviewed-by: Daniel Winkler --- net/bluetooth/hci_request.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/net/bluetooth/hci_request.c b/net/bluetooth/hci_request.c index e0269192f2e536..e17bc8a1c66ddd 100644 --- a/net/bluetooth/hci_request.c +++ b/net/bluetooth/hci_request.c @@ -1533,11 +1533,14 @@ void __hci_req_update_scan_rsp_data(struct hci_request *req, u8 instance) memset(, 0, sizeof(cp)); - if (instance) + /* Extended scan response data doesn't allow a response to be +* set if the instance isn't scannable. +*/ + if (get_adv_instance_scan_rsp_len(hdev, instance)) len = create_instance_scan_rsp_data(hdev, instance, cp.data); else - len = create_default_scan_rsp_data(hdev, cp.data); + len = 0; if (hdev->scan_rsp_data_len == len && !memcmp(cp.data, hdev->scan_rsp_data, len)) -- 2.28.0.220.ged08abb693-goog
Re: [PATCH] mm : update ra->ra_pages if it's NOT equal to bdi->ra_pages
On Fri, Aug 14, 2020 at 04:19:29AM +0100, Matthew Wilcox wrote: > On Fri, Aug 14, 2020 at 10:45:37AM +0800, Zhaoyang Huang wrote: > > On Fri, Aug 14, 2020 at 10:33 AM Andrew Morton > > wrote: > > > > > > On Fri, 14 Aug 2020 10:20:11 +0800 Zhaoyang Huang > > > wrote: > > > > > > > On Fri, Aug 14, 2020 at 10:07 AM Matthew Wilcox > > > > wrote: > > > > > > > > > > On Fri, Aug 14, 2020 at 02:43:55AM +0100, Matthew Wilcox wrote: > > > > > > On Fri, Aug 14, 2020 at 09:30:11AM +0800, Zhaoyang Huang wrote: > > > > > > > file->f_ra->ra_pages will remain the initialized value since it > > > > > > > opend, which may > > > > > > > be NOT equal to bdi->ra_pages as the latter one is updated > > > > > > > somehow(etc, > > > > > > > echo xxx > /sys/block/dm/queue/read_ahead_kb).So sync > > > > > > > ra->ra_pages to the > > > > > > > updated value when sync read. > > > > > > > > > > > > It still ignores the work done by shrink_readahead_size_eio() > > > > > > and fadvise(POSIX_FADV_SEQUENTIAL). > > > > > > > > > > ... by the way, if you're trying to update one particular file's > > > > > readahead > > > > > state, you can just call fadvise(POSIX_FADV_NORMAL) on it. > > > > > > > > > > If you want to update every open file's ra_pages by writing to sysfs, > > > > > then just no. We don't do that. > > > > No, What I want to fix is the file within one process's context keeps > > > > using the initialized value when it is opened and not sync with new > > > > value when bdi->ra_pages changes. > > > > > > So you're saying that > > > > > > echo xxx > /sys/block/dm/queue/read_ahead_kb > > > > > > does not affect presently-open files, and you believe that it should do > > > so? > > > > > > I guess that could be a reasonable thing to want - it's reasonable for > > > a user to expect that writing to a global tunable will take immediate > > > global effect. I guess. > > > > > > But as Matthew says, it would help if you were to explain why this is > > > needed. In full detail. What operational problems is the present > > > implementation causing? > > The real scenario is some system(like android) will turbo read during > > startup via expanding the readahead window and then set it back to > > normal(128kb as usual). However, some files in the system process > > context will keep to be opened since it is opened up and has no chance > > to sync with the updated value as it is almost impossible to change > > the files attached to the inode(processes are unaware of these > > things). we have to fix it from a kernel perspective. > > OK, this is a much more useful description of the problem, thank you! It's not the first time we brought up the issue. https://patchwork.kernel.org/patch/10866161/ Hopefully, we have some solution at this time. > > I can think of two possibilities here. One is that maybe our readahead > heuristics just don't work on modern phone hardware. Perhaps we need > to ramp up more aggressively by default. > > The other is that maybe it really is just a "boost at startup" kind > of situation and so we should support _that_. Some interface where > we can set a ra_boost, and then do: > > if (ra_boost) > newsize *= 2; > > in get_init_ra_size(). With kernel boot paramter, it sounds good idea to me.
Re: [PATCH 1/2] [-next] mmc: host: msm: Add optional full power cycle property.
As I mentioned in the next email, please ignore this patch. The whole idea is incorrect and does not solve the problem. Konrad
[PATCH] khugepaged: adjust VM_BUG_ON_MM() in __khugepaged_enter()
syzbot crashes on the VM_BUG_ON_MM(khugepaged_test_exit(mm), mm) in
__khugepaged_enter(): yes, when one thread is about to dump core, has set
core_state, and is waiting for others, another might do something calling
__khugepaged_enter(), which now crashes because I lumped the core_state
test (known as "mmget_still_valid") into khugepaged_test_exit(). I still
think it's best to lump them together, so just in this exceptional case,
check mm->mm_users directly instead of khugepaged_test_exit().
Reported-by: syzbot
Fixes: bbe98f9cadff ("khugepaged: khugepaged_test_exit() check
mmget_still_valid()")
Signed-off-by: Hugh Dickins
Cc: sta...@vger.kernel.org # v4.8+
---
mm/khugepaged.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- v5.9-rc/mm/khugepaged.c 2020-08-12 19:46:50.867196579 -0700
+++ linux/mm/khugepaged.c 2020-08-14 14:24:32.739457309 -0700
@@ -466,7 +466,7 @@ int __khugepaged_enter(struct mm_struct
return -ENOMEM;
/* __khugepaged_exit() must not run from under us */
- VM_BUG_ON_MM(khugepaged_test_exit(mm), mm);
+ VM_BUG_ON_MM(atomic_read(>mm_users) == 0, mm);
if (unlikely(test_and_set_bit(MMF_VM_HUGEPAGE, >flags))) {
free_mm_slot(mm_slot);
return 0;
I created a service that shows addition/removal of functions by Git tag
Greetings! My service takes each tag of a repo and runs ctags on it. Then it diffs each version with the next, and presents it in a neat timeline. The code for the indexer and server is available on GitHub (linked in the site). You may see it at the following URL: https://sourcedigger.io/ I think this complements the Elixir cross referencer, and may be useful for devs working on older versions. Any feedback is appreciated. Have a great day, - David
[GIT PULL] Please pull NFS client updates for Linux 5.9
Hi Linus, The following changes since commit c1326210477ecc06c53221f0005c64419aba30d6: nfs,nfsd: NFSv4.2 extended attribute protocol definitions (2020-07-13 17:20:49 -0400) are available in the Git repository at: git://git.linux-nfs.org/projects/trondmy/linux-nfs.git tags/nfs-for-5.9-1 for you to fetch changes up to 563c53e73b8b6ec842828736f77e633f7b0911e9: NFS: Fix flexfiles read failover (2020-08-12 11:20:29 -0400) Cheers Trond NFS client updates for Linux 5.9 Highlights include: Stable fixes: - pNFS: Don't return layout segments that are being used for I/O - pNFS: Don't move layout segments off the active list when being used for I/O Features: - NFS: Add support for user xattrs through the NFSv4.2 protocol - NFS: Allow applications to speed up readdir+statx() using AT_STATX_DONT_SYNC - NFSv4.0 allow nconnect for v4.0 Bugfixes and cleanups: - nfs: ensure correct writeback errors are returned on close() - nfs: nfs_file_write() should check for writeback errors - nfs: Fix getxattr kernel panic and memory overflow - NFS: Fix the pNFS/flexfiles mirrored read failover code - SUNRPC: dont update timeout value on connection reset - freezer: Add unsafe versions of freezable_schedule_timeout_interruptible for NFS - sunrpc: destroy rpc_inode_cachep after unregister_filesystem Colin Ian King (1): NFS: remove redundant initialization of variable result Dan Aloni (1): sunrpc: destroy rpc_inode_cachep after unregister_filesystem Frank van der Linden (13): nfs: add client side only definitions for user xattrs NFSv4.2: define limits and sizes for user xattr handling NFSv4.2: query the server for extended attribute support NFSv4.2: add client side XDR handling for extended attributes nfs: define nfs_access_get_cached function NFSv4.2: query the extended attribute access bits nfs: modify update_changeattr to deal with regular files nfs: define and use the NFS_INO_INVALID_XATTR flag nfs: make the buf_to_pages_noslab function available to the nfs code NFSv4.2: add the extended attribute proc functions. NFSv4.2: hook in the user extended attribute handlers NFSv4.2: add client side xattr caching. NFSv4.2: xattr cache: get rid of cache discard work queue He Zhe (1): freezer: Add unsafe versions of freezable_schedule_timeout_interruptible for NFS Jeffrey Mitchell (1): nfs: Fix getxattr kernel panic and memory overflow Olga Kornievskaia (2): NFSv4.0 allow nconnect for v4.0 SUNRPC dont update timeout value on connection reset Randy Dunlap (1): fs: nfs: delete repeated words in comments Scott Mayhew (2): nfs: ensure correct writeback errors are returned on close() nfs: nfs_file_write() should check for writeback errors Trond Myklebust (11): NFS: Allow applications to speed up readdir+statx() using AT_STATX_DONT_SYNC pNFS/flexfiles: Clean up redundant calls to pnfs_put_lseg() pNFS/flexfiles: The mirror count could depend on the layout segment range Merge commit 'c1326210477ecc06c53221f0005c64419aba30d6' from nfsd/linux-next Merge branch 'xattr-devel' NFS: Report the stateid + status in trace_nfs4_layoutreturn_on_close() NFS: Add tracepoints for layouterror and layoutstats. NFS: Add layout segment info to pnfs read/write/commit tracepoints NFS: Don't move layouts to plh_return_segs list while in use NFS: Don't return layout segments that are in use NFS: Fix flexfiles read failover Xu Wang (1): rpc_pipefs: convert comma to semicolon fs/nfs/Makefile|2 +- fs/nfs/blocklayout/rpc_pipefs.c|2 +- fs/nfs/client.c| 22 +- fs/nfs/dir.c | 24 +- fs/nfs/direct.c|2 +- fs/nfs/file.c | 17 +- fs/nfs/flexfilelayout/flexfilelayout.c | 64 +- fs/nfs/fs_context.c|2 +- fs/nfs/inode.c | 20 +- fs/nfs/nfs42.h | 24 + fs/nfs/nfs42proc.c | 258 +++- fs/nfs/nfs42xattr.c| 1056 fs/nfs/nfs42xdr.c | 438 + fs/nfs/nfs4_fs.h | 35 ++ fs/nfs/nfs4client.c| 33 +- fs/nfs/nfs4file.c |5 +- fs/nfs/nfs4proc.c | 241 +++- fs/nfs/nfs4super.c | 10 + fs/nfs/nfs4trace.h | 46 +- fs/nfs/nfs4xdr.c | 39 +- fs/nfs/nfstrace.h |3 +- fs/nfs/pnfs.c | 52 +- fs/nfs/pnfs.h |2 +- include/linux/freezer.h| 14 +
Re: [RFC-PATCH 1/2] mm: Add __GFP_NO_LOCKS flag
On Fri, Aug 14, 2020 at 01:41:40PM -0700, Paul E. McKenney wrote:
> > And that enforces the GFP_NOLOCK allocation mode or some other solution
> > unless you make a new rule that calling call_rcu() is forbidden while
> > holding zone lock or any other lock which might be nested inside the
> > GFP_NOWAIT zone::lock held region.
>
> Again, you are correct. Maybe the forecasted weekend heat will cause
> my brain to hallucinate a better solution, but in the meantime, the
> GFP_NOLOCK approach looks good from this end.
So I hate __GFP_NO_LOCKS for a whole number of reasons:
- it should be called __GFP_LOCKLESS if anything
- it sprinkles a bunch of ugly branches around the allocator fast path
- it only works for order==0
Combined I really odn't think this should be a GFP flag. How about a
special purpose allocation function, something like so..
---
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 901a21f61d68..cdec9c99fba7 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -4875,6 +4875,47 @@ __alloc_pages_nodemask(gfp_t gfp_mask, unsigned int
order, int preferred_nid,
}
EXPORT_SYMBOL(__alloc_pages_nodemask);
+struct page *__rmqueue_lockless(struct zone *zone, struct per_cpu_pages *pcp)
+{
+ struct list_head *list;
+ struct page *page;
+ int migratetype;
+
+ for (migratetype = 0; migratetype < MIGRATE_PCPTYPES; migratetype++) {
+ list = >list[migratetype];
+ page = list_first_entry_or_null(list, struct page, lru);
+ if (page && check_new_pcp(page)) {
+ list_del(>lru);
+ pcp->count--;
+ return page;
+ }
+ }
+
+ return NULL;
+}
+
+struct page *__alloc_page_lockless(void)
+{
+ struct zonelist *zonelist = node_zonelist(numa_node_id(), GFP_KERNEL);
+ struct per_cpu_pages *pcp;
+ struct page *page = NULL;
+ unsigned long flags;
+ struct zoneref *z;
+ struct zone *zone;
+
+ for_each_zone_zonelist(zone, z, zonelist, ZONE_NORMAL) {
+ local_irq_save(flags);
+ pcp = _cpu_ptr(zone->pageset)->pcp;
+ page = __rmqueue_lockless(zone, pcp);
+ local_irq_restore(flags);
+
+ if (page)
+ break;
+ }
+
+ return page;
+}
+
/*
* Common helper functions. Never use with __GFP_HIGHMEM because the returned
* address cannot represent highmem pages. Use alloc_pages and then kmap if
Re: [GIT pull] irq/urgent for v5.9-rc1
The pull request you sent on Fri, 14 Aug 2020 15:58:31 -: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > irq-urgent-2020-08-14 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/1d229a65b419cf51a9921d73907f1998a0e14daa Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] OpenRISC updates for v5.9
The pull request you sent on Sat, 15 Aug 2020 05:47:59 +0900: > git://github.com/openrisc/linux.git tags/for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/e1d74fbe50c46253de519e772c5c2f431b2b837d Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT pull] timers/core for v5.9-rc1
The pull request you sent on Fri, 14 Aug 2020 15:58:33 -: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > timers-core-2020-08-14 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/b6b178e38f40f34842b719a8786d346d4cfec5dc Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT pull] timers/urgent for v5.9-rc1
The pull request you sent on Fri, 14 Aug 2020 15:58:34 -: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > timers-urgent-2020-08-14 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/b923f1247b72fc100b87792fd2129d026bb10e66 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
[RFC/RFT PATCH 6/6] riscv: Add numa support for riscv64 platform
Use the generic numa implementation to add NUMA support for RISC-V.
This is based on Greentime's patch[1] but modified to use generic NUMA
implementation and few more fixes.
[1] https://lkml.org/lkml/2020/1/10/233
Co-developed-by: Greentime Hu
Signed-off-by: Greentime Hu
Signed-off-by: Atish Patra
---
arch/riscv/Kconfig | 31 ++-
arch/riscv/include/asm/mmzone.h | 13 +
arch/riscv/include/asm/numa.h | 8
arch/riscv/include/asm/pci.h| 10 ++
arch/riscv/kernel/setup.c | 10 --
arch/riscv/kernel/smpboot.c | 12 +++-
arch/riscv/mm/init.c| 4 +++-
7 files changed, 83 insertions(+), 5 deletions(-)
create mode 100644 arch/riscv/include/asm/mmzone.h
create mode 100644 arch/riscv/include/asm/numa.h
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 7b5905529146..4bd67f94aaac 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -137,7 +137,7 @@ config PAGE_OFFSET
default 0xffe0 if 64BIT && MAXPHYSMEM_128GB
config ARCH_FLATMEM_ENABLE
- def_bool y
+ def_bool !NUMA
config ARCH_SPARSEMEM_ENABLE
def_bool y
@@ -295,6 +295,35 @@ config TUNE_GENERIC
endchoice
+# Common NUMA Features
+config NUMA
+ bool "Numa Memory Allocation and Scheduler Support"
+ select GENERIC_ARCH_NUMA
+ select OF_NUMA
+ select ARCH_SUPPORTS_NUMA_BALANCING
+ help
+ Enable NUMA (Non-Uniform Memory Access) support.
+
+ The kernel will try to allocate memory used by a CPU on the
+ local memory of the CPU and add some more NUMA awareness to the
kernel.
+
+config NODES_SHIFT
+ int "Maximum NUMA Nodes (as a power of 2)"
+ range 1 10
+ default "2"
+ depends on NEED_MULTIPLE_NODES
+ help
+ Specify the maximum number of NUMA Nodes available on the target
+ system. Increases memory reserved to accommodate various tables.
+
+config USE_PERCPU_NUMA_NODE_ID
+ def_bool y
+ depends on NUMA
+
+config NEED_PER_CPU_EMBED_FIRST_CHUNK
+ def_bool y
+ depends on NUMA
+
config RISCV_ISA_C
bool "Emit compressed instructions when building Linux"
default y
diff --git a/arch/riscv/include/asm/mmzone.h b/arch/riscv/include/asm/mmzone.h
new file mode 100644
index ..fa17e01d9ab2
--- /dev/null
+++ b/arch/riscv/include/asm/mmzone.h
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __ASM_MMZONE_H
+#define __ASM_MMZONE_H
+
+#ifdef CONFIG_NUMA
+
+#include
+
+extern struct pglist_data *node_data[];
+#define NODE_DATA(nid) (node_data[(nid)])
+
+#endif /* CONFIG_NUMA */
+#endif /* __ASM_MMZONE_H */
diff --git a/arch/riscv/include/asm/numa.h b/arch/riscv/include/asm/numa.h
new file mode 100644
index ..8c8cf4297cc3
--- /dev/null
+++ b/arch/riscv/include/asm/numa.h
@@ -0,0 +1,8 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __ASM_NUMA_H
+#define __ASM_NUMA_H
+
+#include
+#include
+
+#endif /* __ASM_NUMA_H */
diff --git a/arch/riscv/include/asm/pci.h b/arch/riscv/include/asm/pci.h
index 1c473a1bd986..d6a0e59638c0 100644
--- a/arch/riscv/include/asm/pci.h
+++ b/arch/riscv/include/asm/pci.h
@@ -32,6 +32,16 @@ static inline int pci_proc_domain(struct pci_bus *bus)
/* always show the domain in /proc */
return 1;
}
+
+#ifdef CONFIG_NUMA
+int pcibus_to_node(struct pci_bus *bus);
+#ifndef cpumask_of_pcibus
+#define cpumask_of_pcibus(bus) (pcibus_to_node(bus) == -1 ?\
+cpu_all_mask : \
+cpumask_of_node(pcibus_to_node(bus)))
+#endif
+#endif /* CONFIG_NUMA */
+
#endif /* CONFIG_PCI */
#endif /* _ASM_RISCV_PCI_H */
diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
index 32bb5a1bea05..1533ee5c6e56 100644
--- a/arch/riscv/kernel/setup.c
+++ b/arch/riscv/kernel/setup.c
@@ -104,13 +104,19 @@ void __init setup_arch(char **cmdline_p)
static int __init topology_init(void)
{
- int i;
+ int i, ret;
+
+ for_each_online_node(i)
+ register_one_node(i);
for_each_possible_cpu(i) {
struct cpu *cpu = _cpu(cpu_devices, i);
cpu->hotpluggable = cpu_has_hotplug(i);
- register_cpu(cpu, i);
+ ret = register_cpu(cpu, i);
+ if (unlikely(ret))
+ pr_warn("Warning: %s: register_cpu %d failed (%d)\n",
+ __func__, i, ret);
}
return 0;
diff --git a/arch/riscv/kernel/smpboot.c b/arch/riscv/kernel/smpboot.c
index 356825a57551..4e9bdb6230de 100644
--- a/arch/riscv/kernel/smpboot.c
+++ b/arch/riscv/kernel/smpboot.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -46,13 +47,18 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
{
int cpuid;
int ret;
+
[RFC/RFT PATCH 5/6] riscv: Add support pte_protnone and pmd_protnone if CONFIG_NUMA_BALANCING
From: Greentime Hu
These two functions are used to distinguish between PROT_NONENUMA
protections and hinting fault protections.
Signed-off-by: Greentime Hu
---
arch/riscv/include/asm/pgtable.h | 20
1 file changed, 20 insertions(+)
diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h
index 515b42f98d34..2751110675e6 100644
--- a/arch/riscv/include/asm/pgtable.h
+++ b/arch/riscv/include/asm/pgtable.h
@@ -183,6 +183,11 @@ static inline unsigned long pmd_page_vaddr(pmd_t pmd)
return (unsigned long)pfn_to_virt(pmd_val(pmd) >> _PAGE_PFN_SHIFT);
}
+static inline pte_t pmd_pte(pmd_t pmd)
+{
+ return __pte(pmd_val(pmd));
+}
+
/* Yields the page frame number (PFN) of a page table entry */
static inline unsigned long pte_pfn(pte_t pte)
{
@@ -286,6 +291,21 @@ static inline pte_t pte_mkhuge(pte_t pte)
return pte;
}
+#ifdef CONFIG_NUMA_BALANCING
+/*
+ * See the comment in include/asm-generic/pgtable.h
+ */
+static inline int pte_protnone(pte_t pte)
+{
+ return (pte_val(pte) & (_PAGE_PRESENT | _PAGE_PROT_NONE)) ==
_PAGE_PROT_NONE;
+}
+
+static inline int pmd_protnone(pmd_t pmd)
+{
+ return pte_protnone(pmd_pte(pmd));
+}
+#endif
+
/* Modify page protection bits */
static inline pte_t pte_modify(pte_t pte, pgprot_t newprot)
{
--
2.24.0
[RFC/RFT PATCH 3/6] arm64, numa: Move pcibus_to_node definition to generic numa code
pcibus_to_node is used only when numa is enabled and does not depend
on ISA. Thus, it can be moved the generic numa implementation.
Signed-off-by: Atish Patra
---
arch/arm64/kernel/pci.c | 10 --
drivers/base/arch_numa.c | 11 +++
2 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
index 1006ed2d7c60..07c122946c11 100644
--- a/arch/arm64/kernel/pci.c
+++ b/arch/arm64/kernel/pci.c
@@ -54,16 +54,6 @@ int raw_pci_write(unsigned int domain, unsigned int bus,
return b->ops->write(b, devfn, reg, len, val);
}
-#ifdef CONFIG_NUMA
-
-int pcibus_to_node(struct pci_bus *bus)
-{
- return dev_to_node(>dev);
-}
-EXPORT_SYMBOL(pcibus_to_node);
-
-#endif
-
#ifdef CONFIG_ACPI
struct acpi_pci_generic_root_info {
diff --git a/drivers/base/arch_numa.c b/drivers/base/arch_numa.c
index 83341c807240..4ab1b20a615d 100644
--- a/drivers/base/arch_numa.c
+++ b/drivers/base/arch_numa.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#ifdef CONFIG_ARM64
@@ -60,6 +61,16 @@ EXPORT_SYMBOL(cpumask_of_node);
#endif
+#ifdef CONFIG_PCI
+
+int pcibus_to_node(struct pci_bus *bus)
+{
+ return dev_to_node(>dev);
+}
+EXPORT_SYMBOL(pcibus_to_node);
+
+#endif
+
static void numa_update_cpu(unsigned int cpu, bool remove)
{
int nid = cpu_to_node(cpu);
--
2.24.0
[RFC/RFT PATCH 4/6] riscv: Separate memory init from paging init
Currently, we perform some memory init functions in paging init. But,
that will be an issue for NUMA support where DT needs to be flattened
before numa initialization and memblock_present can only be called
after numa initialization.
Move memory initialization related functions to a separate function.
Signed-off-by: Atish Patra
---
arch/riscv/include/asm/pgtable.h | 1 +
arch/riscv/kernel/setup.c| 2 ++
arch/riscv/mm/init.c | 6 +-
3 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h
index eaea1f717010..515b42f98d34 100644
--- a/arch/riscv/include/asm/pgtable.h
+++ b/arch/riscv/include/asm/pgtable.h
@@ -466,6 +466,7 @@ static inline void __kernel_map_pages(struct page *page,
int numpages, int enabl
extern void *dtb_early_va;
void setup_bootmem(void);
void paging_init(void);
+void misc_mem_init(void);
#define FIRST_USER_ADDRESS 0
diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
index f04373be54a6..32bb5a1bea05 100644
--- a/arch/riscv/kernel/setup.c
+++ b/arch/riscv/kernel/setup.c
@@ -79,6 +79,8 @@ void __init setup_arch(char **cmdline_p)
#else
unflatten_device_tree();
#endif
+ misc_mem_init();
+
clint_init_boot_cpu();
#ifdef CONFIG_SWIOTLB
diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
index 787c75f751a5..b8905ae2bbe7 100644
--- a/arch/riscv/mm/init.c
+++ b/arch/riscv/mm/init.c
@@ -570,8 +570,12 @@ static void __init resource_init(void)
void __init paging_init(void)
{
setup_vm_final();
- sparse_init();
setup_zero_page();
+}
+
+void __init misc_mem_init(void)
+{
+ sparse_init();
zone_sizes_init();
resource_init();
}
--
2.24.0
[RFC/RFT PATCH 0/6] Unify NUMA implementation between ARM64 & RISC-V
This series attempts to move the ARM64 numa implementation to common code so that RISC-V can leverage that as well instead of reimplementing it again. RISC-V specific bits are based on initial work done by Greentime Hu [1] but modified to reuse the common implementation to avoid duplication. [1] https://lkml.org/lkml/2020/1/10/233 This series has been tested on qemu with numa enabled for both RISC-V & ARM64. It would be great if somebody can test it on numa capable ARM64 hardware platforms. This patch series doesn't modify the maintainers list for the common code (arch_numa) as I am not sure if somebody from ARM64 community or Greg should take up the maintainership. Ganapatrao was the original author of the arm64 version. I would be happy to update that in the next revision once it is decided. # numactl --hardware available: 2 nodes (0-1) node 0 cpus: 0 1 2 3 node 0 size: 486 MB node 0 free: 470 MB node 1 cpus: 4 5 6 7 node 1 size: 424 MB node 1 free: 408 MB node distances: node 0 1 0: 10 20 1: 20 10 # numactl -show policy: default preferred node: current physcpubind: 0 1 2 3 4 5 6 7 cpubind: 0 1 nodebind: 0 1 membind: 0 1 For RISC-V, the following qemu series is a pre-requisite to test the patches in Qemu. https://patchwork.kernel.org/project/qemu-devel/list/?series=303313 The patches are also available at https://github.com/atishp04/linux/tree/5.10_numa_unified There may be some minor conflicts with Mike's cleanup series [2] depending on the order in which these two series are being accepted. I can rebase on top his series if required. [2] https://lkml.org/lkml/2020/7/28/39 Atish Patra (5): numa: Move numa implementation to common code arm64, numa: Change the numa init function name to be generic arm64, numa: Move pcibus_to_node definition to generic numa code riscv: Separate memory init from paging init riscv: Add numa support for riscv64 platform Greentime Hu (1): riscv: Add support pte_protnone and pmd_protnone if CONFIG_NUMA_BALANCING arch/arm64/Kconfig| 1 + arch/arm64/include/asm/numa.h | 45 +--- arch/arm64/kernel/pci.c | 10 arch/arm64/mm/Makefile| 1 - arch/arm64/mm/init.c | 4 +- arch/riscv/Kconfig| 31 ++- arch/riscv/include/asm/mmzone.h | 13 + arch/riscv/include/asm/numa.h | 8 +++ arch/riscv/include/asm/pci.h | 10 arch/riscv/include/asm/pgtable.h | 21 arch/riscv/kernel/setup.c | 12 - arch/riscv/kernel/smpboot.c | 12 - arch/riscv/mm/init.c | 10 +++- drivers/base/Kconfig | 6 +++ drivers/base/Makefile | 1 + .../mm/numa.c => drivers/base/arch_numa.c | 19 ++- include/asm-generic/numa.h| 51 +++ 17 files changed, 190 insertions(+), 65 deletions(-) create mode 100644 arch/riscv/include/asm/mmzone.h create mode 100644 arch/riscv/include/asm/numa.h rename arch/arm64/mm/numa.c => drivers/base/arch_numa.c (97%) create mode 100644 include/asm-generic/numa.h -- 2.24.0
[RFC/RFT PATCH 1/6] numa: Move numa implementation to common code
ARM64 numa implementation is generic enough that RISC-V can reuse that
implementation with very minor cosmetic changes. This will help both
ARM64 and RISC-V in terms of maintanace and feature improvement
Move the numa implementation code to common directory so that both ISAs
can reuse this. This doesn't introduce any function changes for ARM64.
Signed-off-by: Atish Patra
---
arch/arm64/Kconfig| 1 +
arch/arm64/include/asm/numa.h | 45 +---
arch/arm64/mm/Makefile| 1 -
drivers/base/Kconfig | 6 +++
drivers/base/Makefile | 1 +
.../mm/numa.c => drivers/base/arch_numa.c | 0
include/asm-generic/numa.h| 51 +++
7 files changed, 60 insertions(+), 45 deletions(-)
rename arch/arm64/mm/numa.c => drivers/base/arch_numa.c (100%)
create mode 100644 include/asm-generic/numa.h
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 6d232837cbee..955a0cf75b16 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -960,6 +960,7 @@ config HOTPLUG_CPU
# Common NUMA Features
config NUMA
bool "NUMA Memory Allocation and Scheduler Support"
+ select GENERIC_ARCH_NUMA
select ACPI_NUMA if ACPI
select OF_NUMA
help
diff --git a/arch/arm64/include/asm/numa.h b/arch/arm64/include/asm/numa.h
index 626ad01e83bf..8c8cf4297cc3 100644
--- a/arch/arm64/include/asm/numa.h
+++ b/arch/arm64/include/asm/numa.h
@@ -3,49 +3,6 @@
#define __ASM_NUMA_H
#include
-
-#ifdef CONFIG_NUMA
-
-#define NR_NODE_MEMBLKS(MAX_NUMNODES * 2)
-
-int __node_distance(int from, int to);
-#define node_distance(a, b) __node_distance(a, b)
-
-extern nodemask_t numa_nodes_parsed __initdata;
-
-extern bool numa_off;
-
-/* Mappings between node number and cpus on that node. */
-extern cpumask_var_t node_to_cpumask_map[MAX_NUMNODES];
-void numa_clear_node(unsigned int cpu);
-
-#ifdef CONFIG_DEBUG_PER_CPU_MAPS
-const struct cpumask *cpumask_of_node(int node);
-#else
-/* Returns a pointer to the cpumask of CPUs on Node 'node'. */
-static inline const struct cpumask *cpumask_of_node(int node)
-{
- return node_to_cpumask_map[node];
-}
-#endif
-
-void __init arm64_numa_init(void);
-int __init numa_add_memblk(int nodeid, u64 start, u64 end);
-void __init numa_set_distance(int from, int to, int distance);
-void __init numa_free_distance(void);
-void __init early_map_cpu_to_node(unsigned int cpu, int nid);
-void numa_store_cpu_info(unsigned int cpu);
-void numa_add_cpu(unsigned int cpu);
-void numa_remove_cpu(unsigned int cpu);
-
-#else /* CONFIG_NUMA */
-
-static inline void numa_store_cpu_info(unsigned int cpu) { }
-static inline void numa_add_cpu(unsigned int cpu) { }
-static inline void numa_remove_cpu(unsigned int cpu) { }
-static inline void arm64_numa_init(void) { }
-static inline void early_map_cpu_to_node(unsigned int cpu, int nid) { }
-
-#endif /* CONFIG_NUMA */
+#include
#endif /* __ASM_NUMA_H */
diff --git a/arch/arm64/mm/Makefile b/arch/arm64/mm/Makefile
index d91030f0ffee..928c308b044b 100644
--- a/arch/arm64/mm/Makefile
+++ b/arch/arm64/mm/Makefile
@@ -6,7 +6,6 @@ obj-y := dma-mapping.o extable.o
fault.o init.o \
obj-$(CONFIG_HUGETLB_PAGE) += hugetlbpage.o
obj-$(CONFIG_PTDUMP_CORE) += dump.o
obj-$(CONFIG_PTDUMP_DEBUGFS) += ptdump_debugfs.o
-obj-$(CONFIG_NUMA) += numa.o
obj-$(CONFIG_DEBUG_VIRTUAL)+= physaddr.o
KASAN_SANITIZE_physaddr.o += n
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 8d7001712062..73c2151de194 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -210,4 +210,10 @@ config GENERIC_ARCH_TOPOLOGY
appropriate scaling, sysfs interface for reading capacity values at
runtime.
+config GENERIC_ARCH_NUMA
+ bool
+ help
+ Enable support for generic numa implementation. Currently, RISC-V
+ and ARM64 uses it.
+
endmenu
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index 157452080f3d..c3d02c644222 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_PINCTRL) += pinctrl.o
obj-$(CONFIG_DEV_COREDUMP) += devcoredump.o
obj-$(CONFIG_GENERIC_MSI_IRQ_DOMAIN) += platform-msi.o
obj-$(CONFIG_GENERIC_ARCH_TOPOLOGY) += arch_topology.o
+obj-$(CONFIG_GENERIC_ARCH_NUMA) += arch_numa.o
obj-y += test/
diff --git a/arch/arm64/mm/numa.c b/drivers/base/arch_numa.c
similarity index 100%
rename from arch/arm64/mm/numa.c
rename to drivers/base/arch_numa.c
diff --git a/include/asm-generic/numa.h b/include/asm-generic/numa.h
new file mode 100644
index ..0635c0724b7c
--- /dev/null
+++ b/include/asm-generic/numa.h
@@ -0,0 +1,51 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __ASM_GENERIC_NUMA_H
+#define __ASM_GENERIC_NUMA_H
+
+#ifdef CONFIG_NUMA
+
+#define NR_NODE_MEMBLKS
[RFC/RFT PATCH 2/6] arm64, numa: Change the numa init function name to be generic
As we are using generic numa implementation code, modify the init function
name to indicate that generic implementation.
Signed-off-by: Atish Patra
---
arch/arm64/mm/init.c | 4 ++--
drivers/base/arch_numa.c | 8 ++--
include/asm-generic/numa.h | 4 ++--
3 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 481d22c32a2e..93b660229e1d 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -418,10 +418,10 @@ void __init bootmem_init(void)
max_pfn = max_low_pfn = max;
min_low_pfn = min;
- arm64_numa_init();
+ arch_numa_init();
/*
-* must be done after arm64_numa_init() which calls numa_init() to
+* must be done after arch_numa_init() which calls numa_init() to
* initialize node_online_map that gets used in hugetlb_cma_reserve()
* while allocating required CMA size across online nodes.
*/
diff --git a/drivers/base/arch_numa.c b/drivers/base/arch_numa.c
index 73f8b49d485c..83341c807240 100644
--- a/drivers/base/arch_numa.c
+++ b/drivers/base/arch_numa.c
@@ -13,7 +13,9 @@
#include
#include
+#ifdef CONFIG_ARM64
#include
+#endif
#include
struct pglist_data *node_data[MAX_NUMNODES] __read_mostly;
@@ -445,16 +447,18 @@ static int __init dummy_numa_init(void)
}
/**
- * arm64_numa_init() - Initialize NUMA
+ * arch_numa_init() - Initialize NUMA
*
* Try each configured NUMA initialization method until one succeeds. The
* last fallback is dummy single node config encomapssing whole memory.
*/
-void __init arm64_numa_init(void)
+void __init arch_numa_init(void)
{
if (!numa_off) {
+#ifdef CONFIG_ARM64
if (!acpi_disabled && !numa_init(arm64_acpi_numa_init))
return;
+#endif
if (acpi_disabled && !numa_init(of_numa_init))
return;
}
diff --git a/include/asm-generic/numa.h b/include/asm-generic/numa.h
index 0635c0724b7c..309eca8c0b5d 100644
--- a/include/asm-generic/numa.h
+++ b/include/asm-generic/numa.h
@@ -27,7 +27,7 @@ static inline const struct cpumask *cpumask_of_node(int node)
}
#endif
-void __init arm64_numa_init(void);
+void __init arch_numa_init(void);
int __init numa_add_memblk(int nodeid, u64 start, u64 end);
void __init numa_set_distance(int from, int to, int distance);
void __init numa_free_distance(void);
@@ -41,7 +41,7 @@ void numa_remove_cpu(unsigned int cpu);
static inline void numa_store_cpu_info(unsigned int cpu) { }
static inline void numa_add_cpu(unsigned int cpu) { }
static inline void numa_remove_cpu(unsigned int cpu) { }
-static inline void arm64_numa_init(void) { }
+static inline void arch_numa_init(void) { }
static inline void early_map_cpu_to_node(unsigned int cpu, int nid) { }
#endif /* CONFIG_NUMA */
--
2.24.0
[PATCH] x86/hotplug: Silence APIC only after all irq's are migrated
When offlining CPU's, fixup_irqs() migrates all interrupts away from the
outgoing CPU to an online CPU. Its always possible the device sent an
interrupt to the previous CPU destination. Pending interrupt bit in IRR in
lapic identifies such interrupts. apic_soft_disable() will not capture any
new interrupts in IRR. This causes interrupts from device to be lost during
cpu offline. The issue was found when explicitly setting MSI affinity to a
CPU and immediately offlining it. It was simple to recreate with a USB
ethernet device and doing I/O to it while the CPU is offlined. Lost
interrupts happen even when Interrupt Remapping is enabled.
Current code does apic_soft_disable() before migrating interrupts.
native_cpu_disable()
{
...
apic_soft_disable();
cpu_disable_common();
--> fixup_irqs(); // Too late to capture anything in IRR.
}
Just fliping the above call sequence seems to hit the IRR checks
and the lost interrupt is fixed for both legacy MSI and when
interrupt remapping is enabled.
Fixes: 60dcaad5736f ("x86/hotplug: Silence APIC and NMI when CPU is dead")
Link: https://lore.kernel.org/lkml/875zdarr4h@nanos.tec.linutronix.de/
Signed-off-by: Ashok Raj
To: linux-kernel@vger.kernel.org
To: Thomas Gleixner
Cc: Sukumar Ghorai
Cc: Srikanth Nandamuri
Cc: Evan Green
Cc: Mathias Nyman
Cc: Bjorn Helgaas
Cc: sta...@vger.kernel.org
---
arch/x86/kernel/smpboot.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index ffbd9a3d78d8..278cc9f92f2f 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -1603,13 +1603,20 @@ int native_cpu_disable(void)
if (ret)
return ret;
+ cpu_disable_common();
/*
* Disable the local APIC. Otherwise IPI broadcasts will reach
* it. It still responds normally to INIT, NMI, SMI, and SIPI
-* messages.
+* messages. Its important to do apic_soft_disable() after
+* fixup_irqs(), because fixup_irqs() called from cpu_disable_common()
+* depends on IRR being set. After apic_soft_disable() CPU preserves
+* currently set IRR/ISR but new interrupts will not set IRR.
+* This causes interrupts sent to outgoing cpu before completion
+* of irq migration to be lost. Check SDM Vol 3 "10.4.7.2 Local
+* APIC State after It Has been Software Disabled" section for more
+* details.
*/
apic_soft_disable();
- cpu_disable_common();
return 0;
}
--
2.13.6
Re: [PATCH v2] dynamic debug: allow printing to trace event
On 8/14/20 1:15 PM, Steven Rostedt wrote:
> On Fri, 14 Aug 2020 15:31:51 +0200
> Vincent Whitchurch wrote:
>> index aa9ff9e1c0b3..f599ed21ecc5 100644
>> --- a/include/linux/dynamic_debug.h
>> +++ b/include/linux/dynamic_debug.h
>> @@ -27,13 +27,16 @@ struct _ddebug {
>> * writes commands to /dynamic_debug/control
>> */
>> #define _DPRINTK_FLAGS_NONE 0
>> -#define _DPRINTK_FLAGS_PRINT(1<<0) /* printk() a message using the
>> format */
>> +#define _DPRINTK_FLAGS_PRINTK (1<<0) /* printk() a message using the
>> format */
>
> The above looks like a cleanup unrelated to this patch, and probably
> should be on its own.
I read it as we used to have this one thing called 'print', which really meant
printk, but now that we also have the ability to output to the trace buffer,
what does 'print' mean now? So I read it as being part of this change.
>
>> #define _DPRINTK_FLAGS_INCL_MODNAME (1<<1)
>> #define _DPRINTK_FLAGS_INCL_FUNCNAME(1<<2)
>> #define _DPRINTK_FLAGS_INCL_LINENO (1<<3)
>> #define _DPRINTK_FLAGS_INCL_TID (1<<4)
>> +#define _DPRINTK_FLAGS_TRACE(1<<5)
>> +#define _DPRINTK_FLAGS_PRINT(_DPRINTK_FLAGS_PRINTK | \
>> + _DPRINTK_FLAGS_TRACE)
Is _DPRINTK_FLAGS_PRINT actually used anywhere? Looks to me like
it can be removed.
This is a feature I've wanted for dynamic debug for a while. Thanks for
implementing it!
Dynamic can be enabled on the command line in order to print things early
in boot (I think ftrace can as well), I want to make sure that there are
no ordering issues here? And things wouldn't blow up if we enable printing
to the ftrace buffer early on via dyanmic debug?
Thanks,
-Jason
[PATCH][next] docs: vmcoreinfo: add lockless printk ringbuffer vmcoreinfo
With the introduction of the lockless printk ringbuffer, the
VMCOREINFO relating to the kernel log buffer was changed. Update the
documentation to match those changes.
Fixes: ("printk: use the lockless ringbuffer")
Signed-off-by: John Ogness
Reported-by: Nick Desaulniers
---
based on next-20200814
.../admin-guide/kdump/vmcoreinfo.rst | 131 ++
1 file changed, 102 insertions(+), 29 deletions(-)
diff --git a/Documentation/admin-guide/kdump/vmcoreinfo.rst
b/Documentation/admin-guide/kdump/vmcoreinfo.rst
index 2baad0bfb09d..eb116905c31c 100644
--- a/Documentation/admin-guide/kdump/vmcoreinfo.rst
+++ b/Documentation/admin-guide/kdump/vmcoreinfo.rst
@@ -189,50 +189,123 @@ from this.
Free areas descriptor. User-space tools use this value to iterate the
free_area ranges. MAX_ORDER is used by the zone buddy allocator.
-log_first_idx
+prb
+---
+
+A pointer to the printk ringbuffer (struct printk_ringbuffer). This
+may be pointing to the static boot ringbuffer or the dynamically
+allocated ringbuffer, depending on when the the core dump occurred.
+Used by user-space tools to read the active kernel log buffer.
+
+printk_rb_static
+
+
+A pointer to the static boot printk ringbuffer. If @prb has a
+different value, this is useful for viewing the initial boot messages,
+which may have been overwritten in the dynamically allocated
+ringbuffer.
+
+clear_seq
+-
+
+The sequence number of the printk() record after the last clear
+command. It indicates the first record after the last
+SYSLOG_ACTION_CLEAR, like issued by 'dmesg -c'. Used by user-space
+tools to dump a subset of the dmesg log.
+
+printk_ringbuffer
+-
+
+The size of a printk_ringbuffer structure. This structure contains all
+information required for accessing the various components of the
+kernel log buffer.
+
+(printk_ringbuffer, desc_ring|text_data_ring|dict_data_ring|fail)
+-
+
+Offsets for the various components of the printk ringbuffer. Used by
+user-space tools to view the kernel log buffer without requiring the
+declaration of the structure.
+
+prb_desc_ring
-
-Index of the first record stored in the buffer log_buf. Used by
-user-space tools to read the strings in the log_buf.
+The size of the prb_desc_ring structure. This structure contains
+information about the set of record descriptors.
-log_buf
+(prb_desc_ring, count_bits|descs|head_id|tail_id)
+-
+
+Offsets for the fields describing the set of record descriptors. Used
+by user-space tools to be able to traverse the descriptors without
+requiring the declaration of the structure.
+
+prb_desc
+
+
+The size of the prb_desc structure. This structure contains
+information about a single record descriptor.
+
+(prb_desc, info|state_var|text_blk_lpos|dict_blk_lpos)
+--
+
+Offsets for the fields describing a record descriptors. Used by
+user-space tools to be able to read descriptors without requiring
+the declaration of the structure.
+
+prb_data_blk_lpos
+-
+
+The size of the prb_data_blk_lpos structure. This structure contains
+information about where the text or dictionary data (data block) is
+located within the respective data ring.
+
+(prb_data_blk_lpos, begin|next)
+---
-Console output is written to the ring buffer log_buf at index
-log_first_idx. Used to get the kernel log.
+Offsets for the fields describing the location of a data block. Used
+by user-space tools to be able to locate data blocks without
+requiring the declaration of the structure.
-log_buf_len
+printk_info
---
-log_buf's length.
+The size of the printk_info structure. This structure contains all
+the meta-data for a record.
-clear_idx
--
+(printk_info, seq|ts_nsec|text_len|dict_len|caller_id)
+--
-The index that the next printk() record to read after the last clear
-command. It indicates the first record after the last SYSLOG_ACTION
-_CLEAR, like issued by 'dmesg -c'. Used by user-space tools to dump
-the dmesg log.
+Offsets for the fields providing the meta-data for a record. Used by
+user-space tools to be able to read the information without requiring
+the declaration of the structure.
-log_next_idx
-
+prb_data_ring
+-
-The index of the next record to store in the buffer log_buf. Used to
-compute the index of the current buffer position.
+The size of the prb_data_ring structure. This structure contains
+information about a set of data blocks.
-printk_log
---
+(prb_data_ring, size_bits|data|head_lpos|tail_lpos)
+---
-The size of a structure printk_log. Used to compute the size of
-messages, and extract dmesg log. It encapsulates header i
[PATCH 0/2][next] update gdb scripts for lockless printk ringbuffer
Hi, When we brought in the new lockless printk ringbuffer, we overlooked the gdb scripts. Here are a set of patches to implement gdb support for the new ringbuffer. John Ogness (2): scripts/gdb: add utils.read_ulong() scripts/gdb: update for lockless printk ringbuffer Documentation/admin-guide/kdump/gdbmacros.txt | 153 -- scripts/gdb/linux/dmesg.py| 139 +++- scripts/gdb/linux/utils.py| 7 + 3 files changed, 216 insertions(+), 83 deletions(-) -- 2.20.1
[PATCH 1/2][next] scripts/gdb: add utils.read_ulong()
Add a function for reading unsigned long values, which vary in size depending on the architecture. Signed-off-by: John Ogness --- based on next-20200814 scripts/gdb/linux/utils.py | 7 +++ 1 file changed, 7 insertions(+) diff --git a/scripts/gdb/linux/utils.py b/scripts/gdb/linux/utils.py index ea94221dbd39..ff7c1799d588 100644 --- a/scripts/gdb/linux/utils.py +++ b/scripts/gdb/linux/utils.py @@ -123,6 +123,13 @@ def read_u64(buffer, offset): return read_u32(buffer, offset + 4) + (read_u32(buffer, offset) << 32) +def read_ulong(buffer, offset): +if get_long_type().sizeof == 8: +return read_u64(buffer, offset) +else: +return read_u32(buffer, offset) + + target_arch = None -- 2.20.1
[PATCH 2/2][next] scripts/gdb: update for lockless printk ringbuffer
With the introduction of the lockless printk ringbuffer, the data
structure for the kernel log buffer was changed. Update the gdb
scripts to be able to parse/print the new log buffer structure.
Fixes: ("printk: use the lockless ringbuffer")
Signed-off-by: John Ogness
Reported-by: Nick Desaulniers
---
based on next-20200814
Documentation/admin-guide/kdump/gdbmacros.txt | 153 --
scripts/gdb/linux/dmesg.py| 139 +++-
2 files changed, 209 insertions(+), 83 deletions(-)
diff --git a/Documentation/admin-guide/kdump/gdbmacros.txt
b/Documentation/admin-guide/kdump/gdbmacros.txt
index 220d0a80ca2c..6025534c6c14 100644
--- a/Documentation/admin-guide/kdump/gdbmacros.txt
+++ b/Documentation/admin-guide/kdump/gdbmacros.txt
@@ -170,57 +170,111 @@ document trapinfo
address the kernel panicked.
end
-define dump_log_idx
- set $idx = $arg0
+define dump_record
+ set var $desc = $arg0
if ($argc > 1)
- set $prev_flags = $arg1
+ set var $prev_flags = $arg1
else
- set $prev_flags = 0
+ set var $prev_flags = 0
end
- set $msg = ((struct printk_log *) (log_buf + $idx))
- set $prefix = 1
- set $newline = 1
- set $log = log_buf + $idx + sizeof(*$msg)
-
- # prev & LOG_CONT && !(msg->flags & LOG_PREIX)
- if (($prev_flags & 8) && !($msg->flags & 4))
- set $prefix = 0
+
+ set var $info = &$desc->info
+ set var $prefix = 1
+ set var $newline = 1
+
+ set var $begin = $desc->text_blk_lpos.begin % (1U <<
prb->text_data_ring.size_bits)
+ set var $next = $desc->text_blk_lpos.next % (1U <<
prb->text_data_ring.size_bits)
+
+ # handle data-less record
+ if ($begin & 1)
+ set var $text_len = 0
+ set var $log = ""
+ else
+ # handle wrapping data block
+ if ($begin > $next)
+ set var $begin = 0
+ end
+
+ # skip over descriptor id
+ set var $begin = $begin + sizeof(long)
+
+ # handle truncated message
+ if ($next - $begin < $info->text_len)
+ set var $text_len = $next - $begin
+ else
+ set var $text_len = $info->text_len
+ end
+
+ set var $log = >text_data_ring.data[$begin]
+ end
+
+ # prev & LOG_CONT && !(info->flags & LOG_PREIX)
+ if (($prev_flags & 8) && !($info->flags & 4))
+ set var $prefix = 0
end
- # msg->flags & LOG_CONT
- if ($msg->flags & 8)
+ # info->flags & LOG_CONT
+ if ($info->flags & 8)
# (prev & LOG_CONT && !(prev & LOG_NEWLINE))
if (($prev_flags & 8) && !($prev_flags & 2))
- set $prefix = 0
+ set var $prefix = 0
end
- # (!(msg->flags & LOG_NEWLINE))
- if (!($msg->flags & 2))
- set $newline = 0
+ # (!(info->flags & LOG_NEWLINE))
+ if (!($info->flags & 2))
+ set var $newline = 0
end
end
if ($prefix)
- printf "[%5lu.%06lu] ", $msg->ts_nsec / 10,
$msg->ts_nsec % 10
+ printf "[%5lu.%06lu] ", $info->ts_nsec / 10,
$info->ts_nsec % 10
end
- if ($msg->text_len != 0)
- eval "printf \"%%%d.%ds\", $log", $msg->text_len, $msg->text_len
+ if ($text_len)
+ eval "printf \"%%%d.%ds\", $log", $text_len, $text_len
end
if ($newline)
printf "\n"
end
- if ($msg->dict_len > 0)
- set $dict = $log + $msg->text_len
- set $idx = 0
- set $line = 1
- while ($idx < $msg->dict_len)
+
+ # handle dictionary data
+
+ set var $begin = $desc->dict_blk_lpos.begin % (1U <<
prb->dict_data_ring.size_bits)
+ set var $next = $desc->dict_blk_lpos.next % (1U <<
prb->dict_data_ring.size_bits)
+
+ # handle data-less record
+ if ($begin & 1)
+ set var $dict_len = 0
+ set var $dict = ""
+ else
+ # handle wrapping data block
+ if ($begin > $next)
+ set var $begin = 0
+ end
+
+ # skip over descriptor id
+ set var $begin = $begin + sizeof(long)
+
+
Re: [GIT pull] timers/core for v5.9-rc1
On Fri, Aug 14, 2020 at 9:00 AM Thomas Gleixner wrote: > > please pull the latest timers/core branch from: .. again no diffstat. I think you've borked your scripts. Linus
Re: [RFC PATCH 2/3] mm: Drop use of test_and_set_skip in favor of just setting skip
On Fri, Aug 14, 2020 at 7:24 AM Alexander Duyck wrote: > > On Fri, Aug 14, 2020 at 12:19 AM Alex Shi wrote: > > > > > > > > 在 2020/8/13 下午12:02, Alexander Duyck 写道: > > > > > > Since we have dropped the late abort case we can drop the code that was > > > clearing the LRU flag and calling page_put since the abort case will now > > > not be holding a reference to a page. > > > > > > Signed-off-by: Alexander Duyck > > > > seems the case-lru-file-mmap-read case drop about 3% on this patch in a > > rough testing. > > on my 80 core machine. > > I'm not sure how it could have that much impact on the performance > since the total effect would just be dropping what should be a > redundant test since we tested the skip bit before we took the LRU > bit, so we shouldn't need to test it again after. > > I finally got my test setup working last night. I'll have to do some > testing in my environment and I can start trying to see what is going > on. So I ran the case-lru-file-mmap-read a few times and I don't see how it is supposed to be testing the compaction code. It doesn't seem like compaction is running at least on my system as a result of the test script. I wonder if testing this code wouldn't be better done using something like thpscale from the mmtests(https://github.com/gormanm/mmtests)? It seems past changes to the compaction code were tested using that, and the config script for the test explains that it is designed specifically to stress the compaction code. I have the test up and running now and hope to collect results over the weekend. There is one change I will probably make to this patch and that is to place the new code that is setting skip_updated where the old code was calling test_and_set_skip_bit. By doing that we can avoid extra checks and it should help to reduce possible collisions when setting the skip bit in the pageblock flags. Thanks. - Alex
Re: [Freedreno] [PATCH v10 2/5] drm/msm/dp: add displayPort driver support
On 2020-08-14 10:56, Tanmay Shah wrote:
On 2020-08-14 10:12, Dmitry Baryshkov wrote:
Hello,
On 12/08/2020 07:42, Tanmay Shah wrote:
From: Chandan Uddaraju
[skipped]
+ } else if ((dp_parser_check_prefix("ctrl", clk_name) ||
+ dp_parser_check_prefix("stream", clk_name)) &&
+ ctrl_clk_index < ctrl_clk_count) {
+ struct dss_clk *clk =
+ _power->clk_config[ctrl_clk_index];
+ strlcpy(clk->clk_name, clk_name, sizeof(clk->clk_name));
+ ctrl_clk_index++;
+
+ if (!strncmp(clk_name, "ctrl_link",
+ strlen("ctrl_link")) ||
+ !strncmp(clk_name, "stream_pixel",
+ strlen("ctrl_pixel")))
This should be "stream_pixel", I believe. I don't like macros, but
most probably it would help here. Also function/brace alignment could
be better (sorry, it really hides the issue here).
Thanks for reviews and good catch!! I completely missed it when I
renamed "ctrl_pixel".
Use of "stream_pixel" is very limited. So, instead of macros direct
name is used.
Fixing function and brace alignment sounds good idea insted.
Actually I will reuse dp_parser_check_prefix utility. It's already doing
same Job.
+ clk->type = DSS_CLK_PCLK;
+ else
+ clk->type = DSS_CLK_AHB;
+ }
+ }
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT pull] irq/urgent for v5.9-rc1
On Fri, Aug 14, 2020 at 9:00 AM Thomas Gleixner wrote: > > Two fixes in the core interrupt code which ensure that all error exits > unlock the descriptor lock. No diffstat? I've pulled it, but please check what went wrong.. Linus
Re: [PATCH RFC 0/2] Break heap spraying needed for exploiting use-after-free
On 13.08.2020 18:19, Alexander Popov wrote: > Hello everyone! Requesting for your comments. > > Use-after-free vulnerabilities in the Linux kernel are very popular for > exploitation. A few examples: > > https://googleprojectzero.blogspot.com/2018/09/a-cache-invalidation-bug-in-linux.html > > https://googleprojectzero.blogspot.com/2019/11/bad-binder-android-in-wild-exploit.html?m=1 > https://a13xp0p0v.github.io/2020/02/15/CVE-2019-18683.html > > Use-after-free exploits usually employ heap spraying technique. > Generally it aims to put controlled bytes at a predetermined memory > location on the heap. Heap spraying for exploiting use-after-free in > the Linux kernel relies on the fact that on kmalloc(), the slab allocator > returns the address of the memory that was recently freed. So allocating > a kernel object with the same size and controlled contents allows > overwriting the vulnerable freed object. > > I've found an easy way to break heap spraying for use-after-free > exploitation. I simply extracted slab freelist quarantine from KASAN > functionality and called it CONFIG_SLAB_QUARANTINE. Please see patch 1. > > If this feature is enabled, freed allocations are stored in the quarantine > and can't be instantly reallocated and overwritten by the exploit > performing heap spraying. > > In patch 2 you can see the lkdtm test showing how CONFIG_SLAB_QUARANTINE > prevents immediate reallocation of a freed heap object. > > I tested this patch series both for CONFIG_SLUB and CONFIG_SLAB. > > CONFIG_SLAB_QUARANTINE disabled: > # echo HEAP_SPRAY > /sys/kernel/debug/provoke-crash/DIRECT > lkdtm: Performing direct entry HEAP_SPRAY > lkdtm: Performing heap spraying... > lkdtm: attempt 0: spray alloc addr f8699c7d vs freed addr > f8699c7d > lkdtm: freed addr is reallocated! > lkdtm: FAIL! Heap spraying succeed :( > > CONFIG_SLAB_QUARANTINE enabled: > # echo HEAP_SPRAY > /sys/kernel/debug/provoke-crash/DIRECT > lkdtm: Performing direct entry HEAP_SPRAY > lkdtm: Performing heap spraying... > lkdtm: attempt 0: spray alloc addr 9cafb63f vs freed addr > 173cce94 > lkdtm: attempt 1: spray alloc addr 3096911f vs freed addr > 173cce94 > lkdtm: attempt 2: spray alloc addr da60d755 vs freed addr > 173cce94 > lkdtm: attempt 3: spray alloc addr 0b415070 vs freed addr > 173cce94 > ... > lkdtm: attempt 126: spray alloc addr e80ef807 vs freed addr > 173cce94 > lkdtm: attempt 127: spray alloc addr 398fe535 vs freed addr > 173cce94 > lkdtm: OK! Heap spraying hasn't succeed :) > > I did a brief performance evaluation of this feature. > > 1. Memory consumption. KASAN quarantine uses 1/32 of the memory. > CONFIG_SLAB_QUARANTINE disabled: > # free -m > totalusedfree shared buff/cache > available > Mem: 1987 391862 10 86 > 1907 > Swap: 0 0 0 > CONFIG_SLAB_QUARANTINE enabled: > # free -m > totalusedfree shared buff/cache > available > Mem: 1987 1401760 10 87 > 1805 > Swap: 0 0 0 > > 2. Performance penalty. I used `hackbench -s 256 -l 200 -g 15 -f 25 -P`. > CONFIG_SLAB_QUARANTINE disabled (x86_64, CONFIG_SLUB): > Times: 3.088, 3.103, 3.068, 3.103, 3.107 > Mean: 3.0938 > Standard deviation: 0.0144 > CONFIG_SLAB_QUARANTINE enabled (x86_64, CONFIG_SLUB): > Times: 3.303, 3.329, 3.356, 3.314, 3.292 > Mean: 3.3188 (+7.3%) > Standard deviation: 0.0223 > > I would appreciate your feedback! While waiting for the feedback on these RFC patches, I compiled a list of topics for further research: - Possible ways to overwrite a quarantined heap object by making a large amount of allocations (with/without freeing them) - How init_on_free=1 affects heap spraying on a system with the heap quarantine - How releasing batches of quarantine objects right away affects heap spraying reliability - Heap spraying on multi-core systems with the heap quarantine - More precise performance evaluation - Possible ways to improve the security properties and performance results (KASAN quarantine has some interesting settings) Best regards, Alexander > Alexander Popov (2): > mm: Extract SLAB_QUARANTINE from KASAN > lkdtm: Add heap spraying test > > drivers/misc/lkdtm/core.c | 1 + > drivers/misc/lkdtm/heap.c | 40 ++ > drivers/misc/lkdtm/lkdtm.h | 1 + > include/linux/kasan.h | 107 - > include/linux/slab_def.h | 2 +- > include/linux/slub_def.h | 2 +- > init/Kconfig | 11 > mm/Makefile| 3 +- > mm/kasan/Makefile | 2 + > mm/kasan/kasan.h | 75 +- >
Re: [PATCH v3] kunit: added lockdep support
On Fri, Aug 14, 2020 at 3:58 PM Peter Zijlstra wrote:
>
> On Fri, Aug 14, 2020 at 08:55:27PM +, Uriel Guajardo wrote:
> > +
> > +void kunit_check_lockdep(struct kunit *test, struct kunit_lockdep
> > *lockdep) {
> > + int saved_preempt_count = lockdep->preempt_count;
> > + bool saved_debug_locks = lockdep->debug_locks;
> > +
> > + if (DEBUG_LOCKS_WARN_ON(preempt_count() != saved_preempt_count))
> > + preempt_count_set(saved_preempt_count);
> > +
> > +#ifdef CONFIG_TRACE_IRQFLAGS
> > + if (softirq_count())
> > + current->softirqs_enabled = 0;
> > + else
> > + current->softirqs_enabled = 1;
> > +#endif
>
> This block is pointless. The only way to get softirq tracing out of sync
> is an unbalanced local_bh_disable(), but then the above preempt_count()
> test will trigger and kill IRQ tracing.
Ahh I see. Thank you.
>
> > +
> > + if (saved_debug_locks && !debug_locks) {
> > + kunit_set_failure(test);
> > + kunit_warn(test, "Dynamic analysis tool failure from
> > LOCKDEP.");
> > + kunit_warn(test, "Further tests will have LOCKDEP disabled.");
> > + }
> > +}
Re: [PATCH v3] kunit: added lockdep support
On Fri, Aug 14, 2020 at 08:55:27PM +, Uriel Guajardo wrote:
> +
> +void kunit_check_lockdep(struct kunit *test, struct kunit_lockdep *lockdep) {
> + int saved_preempt_count = lockdep->preempt_count;
> + bool saved_debug_locks = lockdep->debug_locks;
> +
> + if (DEBUG_LOCKS_WARN_ON(preempt_count() != saved_preempt_count))
> + preempt_count_set(saved_preempt_count);
> +
> +#ifdef CONFIG_TRACE_IRQFLAGS
> + if (softirq_count())
> + current->softirqs_enabled = 0;
> + else
> + current->softirqs_enabled = 1;
> +#endif
This block is pointless. The only way to get softirq tracing out of sync
is an unbalanced local_bh_disable(), but then the above preempt_count()
test will trigger and kill IRQ tracing.
> +
> + if (saved_debug_locks && !debug_locks) {
> + kunit_set_failure(test);
> + kunit_warn(test, "Dynamic analysis tool failure from LOCKDEP.");
> + kunit_warn(test, "Further tests will have LOCKDEP disabled.");
> + }
> +}
Re: [PATCH] net: qrtr: fix usage of idr in port assignment to socket
From: Necip Fazil Yildiran
Date: Fri, 14 Aug 2020 10:10:00 +
> diff --git a/net/qrtr/qrtr.c b/net/qrtr/qrtr.c
> index b4c0db0b7d31..52d0707df776 100644
> --- a/net/qrtr/qrtr.c
> +++ b/net/qrtr/qrtr.c
> @@ -693,22 +693,24 @@ static void qrtr_port_remove(struct qrtr_sock *ipc)
> static int qrtr_port_assign(struct qrtr_sock *ipc, int *port)
> {
> int rc;
> + u32 min_port;
Please use reverse christmas tree ordering for local variables.
[PATCH v3] kunit: added lockdep support
From: Uriel Guajardo
KUnit will fail tests upon observing a lockdep failure. Because lockdep
turns itself off after its first failure, only fail the first test and
warn users to not expect any future failures from lockdep.
Similar to lib/locking-selftest [1], we check if the status of
debug_locks has changed after the execution of a test case. However, we
do not reset lockdep afterwards.
Like the locking selftests, we also fix possible preemption count
corruption from lock bugs.
Depends on kunit: support failure from dynamic analysis tools [2]
[1] https://elixir.bootlin.com/linux/v5.7.12/source/lib/locking-selftest.c#L1137
[2]
https://lore.kernel.org/linux-kselftest/20200806174326.3577537-1-urielguajard...@gmail.com/
Signed-off-by: Uriel Guajardo
---
v3 changes:
- Moved lockdep checking to own file [Alan]
- Fail if preemption count changes during test [Peter]
v2 changes:
- Removed lockdep_reset [Peter]
- Added warning to users about lockdep shutting off
---
include/kunit/kunit-lockdep.h | 38 +++
lib/kunit/Makefile| 2 ++
lib/kunit/kunit-lockdep.c | 37 ++
lib/kunit/test.c | 7 ++-
4 files changed, 83 insertions(+), 1 deletion(-)
create mode 100644 include/kunit/kunit-lockdep.h
create mode 100644 lib/kunit/kunit-lockdep.c
diff --git a/include/kunit/kunit-lockdep.h b/include/kunit/kunit-lockdep.h
new file mode 100644
index ..9cb8b931a9c6
--- /dev/null
+++ b/include/kunit/kunit-lockdep.h
@@ -0,0 +1,38 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Lockdep integration into KUnit tests
+ *
+ * Copyright (C) 2020, Google LLC.
+ * Author: Uriel Guajardo
+ */
+#ifndef _KUNIT_LOCKDEP_H
+#define _KUNIT_LOCKDEP_H
+
+#include
+
+struct kunit_lockdep {
+ int preempt_count;
+ bool debug_locks;
+};
+
+#if IS_ENABLED(CONFIG_LOCKDEP)
+
+void kunit_init_lockdep(struct kunit *test, struct kunit_lockdep *lockdep);
+
+void kunit_check_lockdep(struct kunit *test, struct kunit_lockdep *lockdep);
+
+#else
+
+static inline void kunit_init_lockdep(struct kunit *test,
+ struct kunit_lockdep *lockdep)
+{
+}
+
+static inline void kunit_check_lockdep(struct kunit *test,
+ struct kunit_lockdep *lockdep)
+{
+}
+
+#endif
+
+#endif /* _KUNIT_LOCKDEP_H */
diff --git a/lib/kunit/Makefile b/lib/kunit/Makefile
index 724b94311ca3..084806cea994 100644
--- a/lib/kunit/Makefile
+++ b/lib/kunit/Makefile
@@ -5,6 +5,8 @@ kunit-objs += test.o \
assert.o \
try-catch.o
+obj-$(CONFIG_LOCKDEP) += kunit-lockdep.o
+
ifeq ($(CONFIG_KUNIT_DEBUGFS),y)
kunit-objs += debugfs.o
endif
diff --git a/lib/kunit/kunit-lockdep.c b/lib/kunit/kunit-lockdep.c
new file mode 100644
index ..cc8c1baf25cd
--- /dev/null
+++ b/lib/kunit/kunit-lockdep.c
@@ -0,0 +1,37 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Lockdep integration into KUnit tests
+ *
+ * Copyright (C) 2020, Google LLC.
+ * Author: Uriel Guajardo
+ */
+
+#include
+#include
+#include
+
+void kunit_init_lockdep(struct kunit *test, struct kunit_lockdep *lockdep) {
+ lockdep->debug_locks = debug_locks;
+ lockdep->preempt_count = preempt_count();
+}
+
+void kunit_check_lockdep(struct kunit *test, struct kunit_lockdep *lockdep) {
+ int saved_preempt_count = lockdep->preempt_count;
+ bool saved_debug_locks = lockdep->debug_locks;
+
+ if (DEBUG_LOCKS_WARN_ON(preempt_count() != saved_preempt_count))
+ preempt_count_set(saved_preempt_count);
+
+#ifdef CONFIG_TRACE_IRQFLAGS
+ if (softirq_count())
+ current->softirqs_enabled = 0;
+ else
+ current->softirqs_enabled = 1;
+#endif
+
+ if (saved_debug_locks && !debug_locks) {
+ kunit_set_failure(test);
+ kunit_warn(test, "Dynamic analysis tool failure from LOCKDEP.");
+ kunit_warn(test, "Further tests will have LOCKDEP disabled.");
+ }
+}
diff --git a/lib/kunit/test.c b/lib/kunit/test.c
index d8189d827368..7f0af0465e6f 100644
--- a/lib/kunit/test.c
+++ b/lib/kunit/test.c
@@ -7,6 +7,7 @@
*/
#include
+#include
#include
#include
#include
@@ -290,6 +291,9 @@ static void kunit_try_run_case(void *data)
struct kunit_suite *suite = ctx->suite;
struct kunit_case *test_case = ctx->test_case;
+ struct kunit_lockdep lockdep;
+ kunit_init_lockdep(test, );
+
current->kunit_test = test;
/*
@@ -298,7 +302,8 @@ static void kunit_try_run_case(void *data)
* thread will resume control and handle any necessary clean up.
*/
kunit_run_case_internal(test, suite, test_case);
- /* This line may never be reached. */
+ /* These lines may never be reached. */
+ kunit_check_lockdep(test,
[GIT PULL] OpenRISC updates for v5.9
Hi Linus, Please consider for pull: The following changes since commit bcf876870b95592b52519ed4aafcf9d95999bc9c: Linux 5.8 (2020-08-02 14:21:45 -0700) are available in the Git repository at: git://github.com/openrisc/linux.git tags/for-linus for you to fetch changes up to 55b2662ec665cc8b592809a011fe807b05370ab8: openrisc: uaccess: Add user address space check to access_ok (2020-08-09 07:57:21 +0900) OpenRISC updates for 5.9 A few patches all over the place during this cycle, mostly bug and sparse warning fixes for OpenRISC, but a few enhancements too. Note, there are 2 non OpenRISC specific fixups. Non OpenRISC fixes: - In init we need to align the init_task correctly to fix an issue with MUTEX_FLAGS, reviewed by Peter Z. No one picked this up so I kept it on my tree. - In asm-generic/io.h I fixed up some sparse warnings, OK'd by Arnd. Arnd asked to merge it via my tree. OpenRISC fixes: - Many fixes for OpenRISC sprase warnings. - Add support OpenRISC SMP tlb flushing rather than always flushing the entire TLB on every CPU. - Fix bug when dumping stack via /proc/xxx/stack of user threads. Luc Van Oostenryck (1): openrisc: fix __user in raw_copy_to_user()'s prototype Stafford Horne (11): init: Align init_task to avoid conflict with MUTEX_FLAGS openrisc: Add support for external initrd images openrisc: Fix oops caused when dumping stack openrisc: Implement proper SMP tlb flushing asm-generic/io.h: Fix sparse warnings on big-endian architectures openrisc: io: Fixup defines and move include to the end openrisc: uaccess: Fix sparse address space warnings openrisc: uaccess: Use static inline function in access_ok openrisc: uaccess: Remove unused macro __addr_ok openrisc: signal: Fix sparse address space warnings openrisc: uaccess: Add user address space check to access_ok arch/openrisc/include/asm/io.h | 9 +++- arch/openrisc/include/asm/uaccess.h | 23 +- arch/openrisc/kernel/setup.c| 8 ++-- arch/openrisc/kernel/signal.c | 14 +++--- arch/openrisc/kernel/smp.c | 85 + arch/openrisc/kernel/stacktrace.c | 18 +++- arch/openrisc/kernel/vmlinux.lds.S | 12 -- arch/openrisc/mm/tlb.c | 17 +--- include/asm-generic/io.h| 16 +++ init/init_task.c| 1 + 10 files changed, 145 insertions(+), 58 deletions(-)
Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.9-2 tag
The pull request you sent on Fri, 14 Aug 2020 22:56:04 +1000: > https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git > tags/powerpc-5.9-2 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/7fca4dee610dffbe119714231cac0d59496bc193 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] xen: branch for v5.9-rc1b
The pull request you sent on Fri, 14 Aug 2020 15:39:39 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git > for-linus-5.9-rc1b-tag has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/0520058d0578c2924b1571c16281f873cb4a3d2b Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [RFC-PATCH 1/2] mm: Add __GFP_NO_LOCKS flag
On Fri, Aug 14, 2020 at 09:33:47PM +0200, Thomas Gleixner wrote: > On Fri, Aug 14 2020 at 11:02, Paul E. McKenney wrote: > > On Fri, Aug 14, 2020 at 07:49:24PM +0200, Peter Zijlstra wrote: > >> On Fri, Aug 14, 2020 at 09:11:06AM -0700, Paul E. McKenney wrote: > >> > Just to make sure we are talking about the same thing, please see below > >> > for an untested patch that illustrates how I was interpreting your words. > >> > Was this what you had in mind? > >> > >> No, definitely not. > >> > >> Also, since we used to be able to use call_rcu() _everywhere_, including > >> under zone->lock, how's that working with you calling the > >> page-allocating from it? > > > > Indeed, that is exactly the problem we are trying to solve. > > Wait a moment. Why are we discussing RT induced raw non raw lock > ordering at all? Because we like to argue? (Sorry, couldn't resist.) > Whatever kernel you variant you look at this is not working: > > lock(zone) call_rcu() lock(zone) > > It's a simple recursive dead lock, nothing else. You are of course absolutely correct. > And that enforces the GFP_NOLOCK allocation mode or some other solution > unless you make a new rule that calling call_rcu() is forbidden while > holding zone lock or any other lock which might be nested inside the > GFP_NOWAIT zone::lock held region. Again, you are correct. Maybe the forecasted weekend heat will cause my brain to hallucinate a better solution, but in the meantime, the GFP_NOLOCK approach looks good from this end. Thanx, Paul
Re: [GIT PULL] Crypto Fixes for 5.9
The pull request you sent on Fri, 14 Aug 2020 23:18:18 +1000: > git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/d9361cb285281563adada9b16708b12053bd6531 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [PATCH] regulator: Add support for RT4801 Display Bias regulator driver
On Fri, 14 Aug 2020 13:59:33 +0800, cy_huang wrote: > From: ChiYuan Huang > > Adds support for the RT4801 DSV. It has two regulators (DSVP/DSVN) with an I2C > interface. DSVP/DSVN can provide the display panel module for the > positive/negative > voltage range from (+/-)4V to (+/-)6V. > --- > .../regulator/richtek,rt4801-regulator.yaml| 80 > drivers/regulator/Kconfig | 7 + > drivers/regulator/Makefile | 1 + > drivers/regulator/rt4801-regulator.c | 223 > + > 4 files changed, 311 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/regulator/richtek,rt4801-regulator.yaml > create mode 100644 drivers/regulator/rt4801-regulator.c > My bot found errors running 'make dt_binding_check' on your patch: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/regulator/richtek,rt4801-regulator.yaml: additionalProperties: ['enable-gpios'] is not of type 'object', 'boolean' /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/regulator/richtek,rt4801-regulator.yaml: additionalProperties: ['enable-gpios'] is not valid under any of the given schemas (Possible causes of the failure): /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/regulator/richtek,rt4801-regulator.yaml: additionalProperties: ['enable-gpios'] is not of type 'object' make[1]: *** [Documentation/devicetree/bindings/Makefile:19: Documentation/devicetree/bindings/regulator/richtek,rt4801-regulator.example.dts] Error 1 make[1]: *** Waiting for unfinished jobs /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/regulator/richtek,rt4801-regulator.yaml: ignoring, error in schema: additionalProperties warning: no schema found in file: ./Documentation/devicetree/bindings/regulator/richtek,rt4801-regulator.yaml make: *** [Makefile:1334: dt_binding_check] Error 2 See https://patchwork.ozlabs.org/patch/1344633 If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure dt-schema is up to date: pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade Please check and re-submit.
Re: [GIT PULL] Hyper-V fixes for 5.9-rc1
The pull request you sent on Fri, 14 Aug 2020 10:07:51 +: > ssh://g...@gitolite.kernel.org/pub/scm/linux/kernel/git/hyperv/linux.git > tags/hyperv-fixes-signed has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/cd94257d7a8103acf136e4bd46e3d0ad698a6f3d Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [PATCH 2/2] regulator: rt4801: Add DT binding documentation
On Fri, 14 Aug 2020 23:27:04 +0800, cy_huang wrote: > From: ChiYuan Huang > > Add a devicetree binding documentation for the rt4801 regulator driver. > > Signed-off-by: ChiYuan Huang > --- > .../regulator/richtek,rt4801-regulator.yaml| 80 > ++ > 1 file changed, 80 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/regulator/richtek,rt4801-regulator.yaml > My bot found errors running 'make dt_binding_check' on your patch: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/regulator/richtek,rt4801-regulator.yaml: additionalProperties: ['enable-gpios'] is not of type 'object', 'boolean' /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/regulator/richtek,rt4801-regulator.yaml: additionalProperties: ['enable-gpios'] is not valid under any of the given schemas (Possible causes of the failure): /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/regulator/richtek,rt4801-regulator.yaml: additionalProperties: ['enable-gpios'] is not of type 'object' make[1]: *** [Documentation/devicetree/bindings/Makefile:19: Documentation/devicetree/bindings/regulator/richtek,rt4801-regulator.example.dts] Error 1 make[1]: *** Waiting for unfinished jobs make: *** [Makefile:1334: dt_binding_check] Error 2 See https://patchwork.ozlabs.org/patch/1345081 If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure dt-schema is up to date: pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade Please check and re-submit.
Re: [PATCH v5 1/2] dt-bindings: dma: Add bindings for intel LGM SOC
On Fri, Aug 14, 2020 at 01:26:09PM +0800, Amireddy Mallikarjuna reddy wrote: > Add DT bindings YAML schema for DMA controller driver > of Lightning Mountain(LGM) SoC. > > Signed-off-by: Amireddy Mallikarjuna reddy > > --- > v1: > - Initial version. > > v2: > - Fix bot errors. > > v3: > - No change. > > v4: > - Address Thomas langer comments > - use node name pattern as dma-controller as in common binding. > - Remove "_" (underscore) in instance name. > - Remove "port-" and "chan-" in attribute name for both 'dma-ports' & > 'dma-channels' child nodes. > > v5: > - Moved some of the attributes in 'dma-ports' & 'dma-channels' child nodes to > dma client/consumer side as cells in 'dmas' properties. > --- > .../devicetree/bindings/dma/intel,ldma.yaml| 319 > + > 1 file changed, 319 insertions(+) > create mode 100644 Documentation/devicetree/bindings/dma/intel,ldma.yaml > > diff --git a/Documentation/devicetree/bindings/dma/intel,ldma.yaml > b/Documentation/devicetree/bindings/dma/intel,ldma.yaml > new file mode 100644 > index ..9beaf191a6de > --- /dev/null > +++ b/Documentation/devicetree/bindings/dma/intel,ldma.yaml > @@ -0,0 +1,319 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/dma/intel,ldma.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Lightning Mountain centralized low speed DMA and high speed DMA > controllers. > + > +maintainers: > + - chuanhua@intel.com > + - mallikarjunax.re...@intel.com > + > +allOf: > + - $ref: "dma-controller.yaml#" > + > +properties: > + $nodename: > + pattern: "^dma-controller(@.*)?$" > + > + "#dma-cells": > + const: 1 Example says 3. > + > + compatible: > + anyOf: > + - const: intel,lgm-cdma > + - const: intel,lgm-dma2tx > + - const: intel,lgm-dma1rx > + - const: intel,lgm-dma1tx > + - const: intel,lgm-dma0tx > + - const: intel,lgm-dma3 > + - const: intel,lgm-toe-dma30 > + - const: intel,lgm-toe-dma31 'anyOf' doesn't make sense here. This should be a single 'enum'. > + > + reg: > + maxItems: 1 > + > + clocks: > + maxItems: 1 > + > + resets: > + maxItems: 1 > + > + interrupts: > + maxItems: 1 > + > + intel,dma-poll-cnt: > + $ref: /schemas/types.yaml#definitions/uint32 > + description: > + DMA descriptor polling counter. It may need fine tune according > + to the system application scenario. > + > + intel,dma-byte-en: > + type: boolean > + description: > + DMA byte enable is only valid for DMA write(RX). > + Byte enable(1) means DMA write will be based on the number of dwords > + instead of the whole burst. > + > + intel,dma-drb: > +type: boolean > +description: > + DMA descriptor read back to make sure data and desc synchronization. > + > + intel,dma-burst: > +$ref: /schemas/types.yaml#definitions/uint32 > +description: > + Specifiy the DMA burst size(in dwords), the valid value will be 8, > 16, 32. > + Default is 16 for data path dma, 32 is for memcopy DMA. > + > + intel,dma-polling-cnt: > +$ref: /schemas/types.yaml#definitions/uint32 > +description: > + DMA descriptor polling counter. It may need fine tune according to > + the system application scenario. > + > + intel,dma-desc-in-sram: > +type: boolean > +description: > + DMA descritpors in SRAM or not. Some old controllers descriptors > + can be in DRAM or SRAM. The new ones are all in SRAM. > + > + intel,dma-orrc: > +$ref: /schemas/types.yaml#definitions/uint32 > +description: > + DMA outstanding read counter. The maximum value is 16, and it may > + need fine tune according to the system application scenarios. > + > + intel,dma-dburst-wr: > +type: boolean > +description: > + Enable RX dynamic burst write. It only applies to RX DMA and memcopy > DMA. > + > + > + dma-ports: > +type: object > +description: > + This sub-node must contain a sub-node for each DMA port. > +properties: > + '#address-cells': > +const: 1 > + '#size-cells': > +const: 0 > + > +patternProperties: > + "^dma-ports@[0-9]+$": > + type: object > + > + properties: > +reg: > + items: > +- enum: [0, 1, 2, 3, 4, 5] > + description: > + Which port this node refers to. > + > +intel,name: > + $ref: /schemas/types.yaml#definitions/string-array > + description: > + Port name of each DMA port. No other DMA controller needs this, why do you? > + > +intel,chans: > + $ref: /schemas/types.yaml#/definitions/uint32-array > + description: > + The channels included on this port. Format is channel start > + number and how many channels on this port. Why does this need to be in DT?
Re: [PATCH v4 7/7] irqchip: qcom-pdc: Reset all pdc interrupts during init
Quoting Maulik Shah (2020-08-13 00:30:44) > Hi, > > On 8/12/2020 3:01 AM, Stephen Boyd wrote: > > Quoting Maulik Shah (2020-08-10 04:21:00) > >> Clear previous kernel's configuration during init by resetting > >> interrupts in enable bank to zero. > > Can you please add some more information here about why we're not > > clearing all the pdc irqs and only the ones that are listed in DT? > sure. > > Is > > that because the pdc is shared between exception levels of the CPU and > > so some irqs shouldn't be used? Does the DT binding need to change to > > only list the hwirqs that are usable by the OS instead of the ones that > > are usable for the entire system? The binding doesn't mention this at > > all so I am just guessing here. > > The IRQs specified in qcom,pdc-ranges property in DT are the only ones > that can be used in the current OS for the PDC. > > So instead of setting entire register to zero (each reg supports 32 > interrupts enable bit) only clearing the ones that can be used. > Ok. Is something wrong with setting all the register bits to 0? Is there something else in those registers that shouldn't be touched? Please add these details to the commit message.
Re: [PATCH 43/44] dt: document HiSilicon SPMI controller and mfd/regulator properties
On Wed, 12 Aug 2020 17:56:53 +0200, Mauro Carvalho Chehab wrote: > Add documentation for the properties needed by the HiSilicon > 6421v600 driver, and by the SPMI controller used to access > the chipset. > > Signed-off-by: Mauro Carvalho Chehab > --- > .../mfd/hisilicon,hi6421-spmi-pmic.yaml | 182 ++ > .../spmi/hisilicon,hisi-spmi-controller.yaml | 54 ++ > 2 files changed, 236 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml > create mode 100644 > Documentation/devicetree/bindings/spmi/hisilicon,hisi-spmi-controller.yaml > My bot found errors running 'make dt_binding_check' on your patch: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/spmi/hisilicon,hisi-spmi-controller.example.dt.yaml: example-0: spmi@fff24000:reg:0: [0, 4294066176, 0, 4096] is too long See https://patchwork.ozlabs.org/patch/1343770 If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure dt-schema is up to date: pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade Please check and re-submit.
Re: [RFC][PATCH v2 2/2] dma-heap: Add a system-uncached heap
On Fri, Aug 14, 2020 at 9:15 AM Ezequiel Garcia wrote: > Thanks for the patch. > > On Fri, 14 Aug 2020 at 03:25, John Stultz wrote: > > > > This adds a heap that allocates non-contiguous buffers that are > > marked as writecombined, so they are not cached by the CPU. > > > > What's the rationale for exposing the memory > attribute as a new heap, instead of just introducing flags? > > I guess this calls for some guidelines on what situations > call for a separate heap, and when it's just a modifier flag. YES! :) A big part of this patch is to start a discussion and feel out what properties of heaps are generic enough to be flags, and what aspects are unique enough to deserve having their own heap implementation. ION used the ION_FLAG_CACHED bit for this and considered it a generic property (though by default all buffers were uncached). This seemed to cause enough friction in reviews that we dropped it and used cachable buffers for the initial DMA BUF heaps. Further, I want to make sure we avoid the custom flag abuse that ION saw, especially with vendor heaps. So I think having each unique behavior being a separate heap is a reasonable stance. That said, we added the (currently unused) heap-flags field to the interface as there may be some attributes or modalities that are truly generic across heaps. So if we want to add an UNCACHED flag instead, I'm open to that.. however I want to make sure it has clear general meaning so that its behavior is consistent across all heaps and architectures (or produces an error if it's not supported). thanks -john
Re: [PATCH] mm : sync ra->ra_pages with bdi->ra_pages
On Fri, 14 Aug 2020 17:03:44 +0800 Zhaoyang Huang wrote: > Some system(like android) will turbo read during startup via expanding the > readahead window and then set it back to normal(128kb as usual). However, some > files in the system process context will keep to be opened since it is opened > up and has no chance to sync with the updated value as it is almost impossible > to change the files attached to the inode(processes are unaware of these > things) How about making VM_READAHEAD_PAGES a variable? Provide a kernel boot parameter to alter the default setting. Userspace can then restore the usual value later in boot?
Re: [PATCH v1 1/2] Bluetooth: btusb: define HCI packet sizes of USB Alts
Hi Joseph,
On Thu, Aug 13, 2020 at 1:42 AM Joseph Hwang wrote:
>
> It is desirable to define the HCI packet payload sizes of
> USB alternate settings so that they can be exposed to user
> space.
>
> Reviewed-by: Alain Michaud
> Reviewed-by: Abhishek Pandit-Subedi
> Signed-off-by: Joseph Hwang
> ---
>
> drivers/bluetooth/btusb.c| 43
> include/net/bluetooth/hci_core.h | 1 +
> 2 files changed, 33 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> index 8d2608ddfd0875..df7cadf6385868 100644
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -459,6 +459,22 @@ static const struct dmi_system_id
> btusb_needs_reset_resume_table[] = {
> #define BTUSB_WAKEUP_DISABLE 14
> #define BTUSB_USE_ALT1_FOR_WBS 15
>
> +/* Per core spec 5, vol 4, part B, table 2.1,
> + * list the hci packet payload sizes for various ALT settings.
> + * This is used to set the packet length for the wideband speech.
> + * If a controller does not probe its usb alt setting, the default
> + * value will be 0. Any clients at upper layers should interpret it
> + * as a default value and set a proper packet length accordingly.
> + *
> + * To calculate the HCI packet payload length:
> + * for alternate settings 1 - 5:
> + * hci_packet_size = suggested_max_packet_size * 3 (packets) -
> + * 3 (HCI header octets)
> + * for alternate setting 6:
> + * hci_packet_size = suggested_max_packet_size - 3 (HCI header octets)
> + */
> +static const int hci_packet_size_usb_alt[] = { 0, 24, 48, 72, 96, 144, 60 };
> +
> struct btusb_data {
> struct hci_dev *hdev;
> struct usb_device*udev;
> @@ -3958,6 +3974,15 @@ static int btusb_probe(struct usb_interface *intf,
> hdev->notify = btusb_notify;
> hdev->prevent_wake = btusb_prevent_wake;
>
> + if (id->driver_info & BTUSB_AMP) {
> + /* AMP controllers do not support SCO packets */
> + data->isoc = NULL;
> + } else {
> + /* Interface orders are hardcoded in the specification */
> + data->isoc = usb_ifnum_to_if(data->udev, ifnum_base + 1);
> + data->isoc_ifnum = ifnum_base + 1;
> + }
> +
> #ifdef CONFIG_PM
> err = btusb_config_oob_wake(hdev);
> if (err)
> @@ -4021,6 +4046,10 @@ static int btusb_probe(struct usb_interface *intf,
> hdev->set_diag = btintel_set_diag;
> hdev->set_bdaddr = btintel_set_bdaddr;
> hdev->cmd_timeout = btusb_intel_cmd_timeout;
> +
> + if (btusb_find_altsetting(data, 6))
> + hdev->sco_pkt_len = hci_packet_size_usb_alt[6];
> +
> set_bit(HCI_QUIRK_STRICT_DUPLICATE_FILTER, >quirks);
> set_bit(HCI_QUIRK_SIMULTANEOUS_DISCOVERY, >quirks);
> set_bit(HCI_QUIRK_NON_PERSISTENT_DIAG, >quirks);
> @@ -4062,15 +4091,6 @@ static int btusb_probe(struct usb_interface *intf,
> btusb_check_needs_reset_resume(intf);
> }
>
> - if (id->driver_info & BTUSB_AMP) {
> - /* AMP controllers do not support SCO packets */
> - data->isoc = NULL;
> - } else {
> - /* Interface orders are hardcoded in the specification */
> - data->isoc = usb_ifnum_to_if(data->udev, ifnum_base + 1);
> - data->isoc_ifnum = ifnum_base + 1;
> - }
> -
> if (IS_ENABLED(CONFIG_BT_HCIBTUSB_RTL) &&
> (id->driver_info & BTUSB_REALTEK)) {
> hdev->setup = btrtl_setup_realtek;
> @@ -4082,9 +4102,10 @@ static int btusb_probe(struct usb_interface *intf,
> * (DEVICE_REMOTE_WAKEUP)
> */
> set_bit(BTUSB_WAKEUP_DISABLE, >flags);
> - if (btusb_find_altsetting(data, 1))
> + if (btusb_find_altsetting(data, 1)) {
> set_bit(BTUSB_USE_ALT1_FOR_WBS, >flags);
> - else
> + hdev->sco_pkt_len = hci_packet_size_usb_alt[1];
> + } else
> bt_dev_err(hdev, "Device does not support ALT setting
> 1");
> }
>
> diff --git a/include/net/bluetooth/hci_core.h
> b/include/net/bluetooth/hci_core.h
> index 8caac20556b499..0624496328fc09 100644
> --- a/include/net/bluetooth/hci_core.h
> +++ b/include/net/bluetooth/hci_core.h
> @@ -417,6 +417,7 @@ struct hci_dev {
> unsigned intacl_pkts;
> unsigned intsco_pkts;
> unsigned intle_pkts;
> + unsigned intsco_pkt_len;
Id use sco_mtu to so the following check actually does what it intended to do:
https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/tree/net/bluetooth/sco.c#n283
Right now it seems we are using the buffer length as MTU but I think
we should actually use the packet length if it is lower than the
buffer
Re: [RFC][PATCH v2 2/2] dma-heap: Add a system-uncached heap
On Fri, Aug 14, 2020 at 2:17 AM Daniel Vetter wrote: > > On Fri, Aug 14, 2020 at 06:24:58AM +, John Stultz wrote: > > This adds a heap that allocates non-contiguous buffers that are > > marked as writecombined, so they are not cached by the CPU. > > > > This is useful, as most graphics buffers are usually not touched > > by the CPU or only written into once by the CPU. So when mapping > > the buffer over and over between devices, we can skip the CPU > > syncing, which saves a lot of cache management overhead, greatly > > improving performance. > > > > For folk using ION, there was a ION_FLAG_CACHED flag, which > > signaled if the returned buffer should be CPU cacheable or not. > > With DMA-BUF heaps, we have no such flag, and by default the > > current heaps (system and cma) produce CPU cachable buffers. > > So for folks transitioning from ION to DMA-BUF Heaps, this fills > > in some of that missing functionality. > > > > This does have a few "ugly" bits that were required to get > > the buffer properly flushed out initially which I'd like to > > improve. So feedback would be very welcome! > > > > Many thanks to Liam Mark for his help to get this working. > > > > Cc: Sumit Semwal > > Cc: Andrew F. Davis > > Cc: Benjamin Gaignard > > Cc: Liam Mark > > Cc: Laura Abbott > > Cc: Brian Starkey > > Cc: Hridya Valsaraju > > Cc: Robin Murphy > > Cc: linux-me...@vger.kernel.org > > Cc: dri-de...@lists.freedesktop.org > > Signed-off-by: John Stultz > > --- > > v2: > > * Fix build issue on sh reported-by: kernel test robot > > * Rework to use for_each_sgtable_sg(), dma_map_sgtable(), and > > for_each_sg_page() along with numerous other cleanups suggested > > by Robin Murphy > > Mildly annoying me, but where's the userspace for this? Do we have a > gralloc somewhere that works with open driver stacks and uses this? So this is still early RFC, but I've added support to the HiKey960 gralloc, and have pending patches (following DRM rules) I pushed here: https://android-review.googlesource.com/c/device/linaro/hikey/+/1399519 And avoiding the cache syncing overhead improves performance nicely on that board. There is also work in progress to change the codec2 implementation in AOSP (which uses ion directly), to move over to DMA BUF heaps and as it used the !ION_FLAG_CACHED case there this heap would be useful to match ION's functionality. The latest patches for that are here: https://android-review.googlesource.com/c/platform/frameworks/av/+/1360640 (though I'm expecting a deeper rework on those) thanks -john
[PATCH] gpio: stp-xway: automatically drive GPHY leds on ar10 and grx390
Ar10 (xr300) has 3 and grx390 (xrx330) has 4 built-in GPHY. PHY LEDs are
connected via STP. STP is a peripheral controller used to drive external
shift register cascades. The hardware is able to allow the GPHY to drive
some GPIO of the cascade automatically.This patch allows for this on ar10
and grx390.
Tested on D-Link DWR-966 with OpenWRT.
Signed-off-by: Aleksander Jan Bajkowski
---
drivers/gpio/gpio-stp-xway.c | 54
1 file changed, 48 insertions(+), 6 deletions(-)
diff --git a/drivers/gpio/gpio-stp-xway.c b/drivers/gpio/gpio-stp-xway.c
index 9e23a5ae8108..0ce1543426a4 100644
--- a/drivers/gpio/gpio-stp-xway.c
+++ b/drivers/gpio/gpio-stp-xway.c
@@ -41,7 +41,10 @@
#define XWAY_STP_4HZ BIT(23)
#define XWAY_STP_8HZ BIT(24)
#define XWAY_STP_10HZ (BIT(24) | BIT(23))
-#define XWAY_STP_SPEED_MASK(0xf << 23)
+#define XWAY_STP_SPEED_MASK(BIT(23) | BIT(24) | BIT(25) | BIT(26) |
BIT(27))
+
+#define XWAY_STP_FPIS_VALUEBIT(21)
+#define XWAY_STP_FPIS_MASK (BIT(20) | BIT(21))
/* clock source for automatic update */
#define XWAY_STP_UPD_FPI BIT(31)
@@ -54,7 +57,9 @@
/* 2 groups of 3 bits can be driven by the phys */
#define XWAY_STP_PHY_MASK 0x7
#define XWAY_STP_PHY1_SHIFT27
-#define XWAY_STP_PHY2_SHIFT15
+#define XWAY_STP_PHY2_SHIFT3
+#define XWAY_STP_PHY3_SHIFT6
+#define XWAY_STP_PHY4_SHIFT15
/* STP has 3 groups of 8 bits */
#define XWAY_STP_GROUP0BIT(0)
@@ -80,6 +85,8 @@ struct xway_stp {
u8 dsl; /* the 2 LSBs can be driven by the dsl core */
u8 phy1;/* 3 bits can be driven by phy1 */
u8 phy2;/* 3 bits can be driven by phy2 */
+ u8 phy3;/* 3 bits can be driven by phy3 */
+ u8 phy4;/* 3 bits can be driven by phy4 */
u8 reserved;/* mask out the hw driven bits in gpio_request */
};
@@ -114,7 +121,8 @@ static void xway_stp_set(struct gpio_chip *gc, unsigned
gpio, int val)
else
chip->shadow &= ~BIT(gpio);
xway_stp_w32(chip->virt, chip->shadow, XWAY_STP_CPU0);
- xway_stp_w32_mask(chip->virt, 0, XWAY_STP_CON_SWU, XWAY_STP_CON0);
+ if (!chip->reserved)
+ xway_stp_w32_mask(chip->virt, 0, XWAY_STP_CON_SWU,
XWAY_STP_CON0);
}
/**
@@ -188,16 +196,37 @@ static void xway_stp_hw_init(struct xway_stp *chip)
chip->phy2 << XWAY_STP_PHY2_SHIFT,
XWAY_STP_CON1);
+ if (of_machine_is_compatible("lantiq,grx390")
+ || of_machine_is_compatible("lantiq,ar10")) {
+ xway_stp_w32_mask(chip->virt,
+ XWAY_STP_PHY_MASK << XWAY_STP_PHY3_SHIFT,
+ chip->phy3 << XWAY_STP_PHY3_SHIFT,
+ XWAY_STP_CON1);
+ }
+
+ if (of_machine_is_compatible("lantiq,grx390")) {
+ xway_stp_w32_mask(chip->virt,
+ XWAY_STP_PHY_MASK << XWAY_STP_PHY4_SHIFT,
+ chip->phy4 << XWAY_STP_PHY4_SHIFT,
+ XWAY_STP_CON1);
+ }
+
/* mask out the hw driven bits in gpio_request */
- chip->reserved = (chip->phy2 << 5) | (chip->phy1 << 2) | chip->dsl;
+ chip->reserved = (chip->phy4 << 11) | (chip->phy3 << 8) | (chip->phy2
<< 5)
+ | (chip->phy1 << 2) | chip->dsl;
/*
* if we have pins that are driven by hw, we need to tell the stp what
* clock to use as a timer.
*/
- if (chip->reserved)
+ if (chip->reserved) {
xway_stp_w32_mask(chip->virt, XWAY_STP_UPD_MASK,
XWAY_STP_UPD_FPI, XWAY_STP_CON1);
+ xway_stp_w32_mask(chip->virt, XWAY_STP_SPEED_MASK,
+ XWAY_STP_10HZ, XWAY_STP_CON1);
+ xway_stp_w32_mask(chip->virt, XWAY_STP_FPIS_MASK,
+ XWAY_STP_FPIS_VALUE, XWAY_STP_CON1);
+ }
}
static int xway_stp_probe(struct platform_device *pdev)
@@ -242,13 +271,26 @@ static int xway_stp_probe(struct platform_device *pdev)
/* find out which gpios are controlled by the phys */
if (of_machine_is_compatible("lantiq,ar9") ||
of_machine_is_compatible("lantiq,gr9") ||
- of_machine_is_compatible("lantiq,vr9")) {
+ of_machine_is_compatible("lantiq,vr9") ||
+ of_machine_is_compatible("lantiq,ar10") ||
+ of_machine_is_compatible("lantiq,grx390")) {
if (!of_property_read_u32(pdev->dev.of_node, "lantiq,phy1",
))
chip->phy1 = phy & XWAY_STP_PHY_MASK;
if (!of_property_read_u32(pdev->dev.of_node, "lantiq,phy2",
))
chip->phy2 = phy & XWAY_STP_PHY_MASK;
}
+ if (of_machine_is_compatible("lantiq,ar10") ||
+
Re: [PATCH v1 2/2] Bluetooth: sco: expose WBS packet length in socket option
Hi Joseph,
On Thu, Aug 13, 2020 at 1:42 AM Joseph Hwang wrote:
>
> It is desirable to expose the wideband speech packet length via
> a socket option to the user space so that the user space can set
> the value correctly in configuring the sco connection.
>
> Reviewed-by: Alain Michaud
> Reviewed-by: Abhishek Pandit-Subedi
> Signed-off-by: Joseph Hwang
> ---
>
> include/net/bluetooth/bluetooth.h | 2 ++
> net/bluetooth/sco.c | 8
> 2 files changed, 10 insertions(+)
>
> diff --git a/include/net/bluetooth/bluetooth.h
> b/include/net/bluetooth/bluetooth.h
> index 9125effbf4483d..922cc03143def4 100644
> --- a/include/net/bluetooth/bluetooth.h
> +++ b/include/net/bluetooth/bluetooth.h
> @@ -153,6 +153,8 @@ struct bt_voice {
>
> #define BT_SCM_PKT_STATUS 0x03
>
> +#define BT_SCO_PKT_LEN 17
> +
> __printf(1, 2)
> void bt_info(const char *fmt, ...);
> __printf(1, 2)
> diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c
> index dcf7f96ff417e6..97e4e7c7b8cf62 100644
> --- a/net/bluetooth/sco.c
> +++ b/net/bluetooth/sco.c
> @@ -67,6 +67,7 @@ struct sco_pinfo {
> __u32 flags;
> __u16 setting;
> __u8cmsg_mask;
> + __u32 pkt_len;
> struct sco_conn *conn;
> };
>
> @@ -267,6 +268,8 @@ static int sco_connect(struct sock *sk)
> sco_sock_set_timer(sk, sk->sk_sndtimeo);
> }
>
> + sco_pi(sk)->pkt_len = hdev->sco_pkt_len;
> +
> done:
> hci_dev_unlock(hdev);
> hci_dev_put(hdev);
> @@ -1001,6 +1004,11 @@ static int sco_sock_getsockopt(struct socket *sock,
> int level, int optname,
> err = -EFAULT;
> break;
>
> + case BT_SCO_PKT_LEN:
> + if (put_user(sco_pi(sk)->pkt_len, (u32 __user *)optval))
> + err = -EFAULT;
> + break;
Couldn't we expose this via BT_SNDMTU/BT_RCVMTU?
> default:
> err = -ENOPROTOOPT;
> break;
> --
> 2.28.0.236.gb10cc79966-goog
>
--
Luiz Augusto von Dentz
Re: fs/ocfs2/suballoc.c:2430:2-8: preceding lock on line 2413
On Fri, 14 Aug 2020, Thomas Gleixner wrote: > Julia, > > On Fri, Aug 14 2020 at 21:00, Julia Lawall wrote: > > On Fri, 14 Aug 2020, Thomas Gleixner wrote: > >> That's clearly a false positive. Is there anything what can be done to > >> help that cocci script here? > > > > I have a better version that needs to get pushed. > > > > But normally these pass through me. Did you get it directly from kbuild? > > Yes, because I touched the affected lines last :) Actually, that's not the point. Normally, I get all the reports on this case, and then I forward them if they look ok. If I forwarded something incorrect, then sorry about that. If the policy has changed for this rule to be sending the reports out directlty to the recipients, then I think it should be changed back. There are a lot of real bugs with lock usage, but there are alot of false positives too. Specifically, the rule looks for the case with identical if tests, but only when the branches are identical too. Kbuild people, can this be adjusted? Or have I misunderstood the situation? thanks, julia
Re: [PATCH][V2] of/address: check for invalid range.cpu_addr
On Thu, Aug 13, 2020 at 5:43 AM Colin King wrote:
>
> From: Colin Ian King
>
> Currently invalid CPU addresses are not being sanity checked resulting in
> SATA setup failure on a SynQuacer SC2A11 development machine. The original
> check was removed by and earlier commit, so add a sanity check back in
> to avoid this regression.
>
> Fixes: 7a8b64d17e35 ("of/address: use range parser for of_dma_get_range")
> Signed-off-by: Colin Ian King
> ---
> drivers/of/address.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 590493e04b01..6ffbf7b99e92 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -985,6 +985,10 @@ int of_dma_get_range(struct device_node *np, u64
> *dma_addr, u64 *paddr, u64 *siz
> /* Don't error out as we'd break some existing DTs */
> continue;
> }
> + if (range.cpu_addr == OF_BAD_ADDR) {
> + pr_err("Translation of CPU address failed on node
> (%pOF)\n", node);
> + continue;
> + }
> dma_offset = range.cpu_addr - range.bus_addr;
>
> /* Take lower and upper limits */
> --
>
> V2: print message using pr_err and don't print range.cpu_addr as it's always
> going to be OF_BAD_ADDR so the information is pointless.
Shouldn't we print the bus_addr like the original message did?
Otherwise, we don't really know what entry is problematic.
Rob
[PATCH v2 1/1] Drivers: hv: vmbus: Add parsing of VMbus interrupt in ACPI DSDT
On ARM64, Hyper-V now specifies the interrupt to be used by VMbus
in the ACPI DSDT. This information is not used on x86 because the
interrupt vector must be hardcoded. But update the generic
VMbus driver to do the parsing and pass the information to the
architecture specific code that sets up the Linux IRQ. Update
consumers of the interrupt to get it from an architecture specific
function.
Signed-off-by: Michael Kelley
---
Changes in v2:
* Added comment to hv_setup_vmbus_irq() explaining that
the irq argument is ignored on x86/x64. A separate patch
set is coming soon for ARM64 where the implementation of
hv_setup_vmbus_irq() will use the 'irq' argument. [Wei Liu]
---
arch/x86/include/asm/mshyperv.h | 1 +
arch/x86/kernel/cpu/mshyperv.c | 7 ++-
drivers/hv/hv.c | 2 +-
drivers/hv/vmbus_drv.c | 30 +++---
include/asm-generic/mshyperv.h | 4 +++-
5 files changed, 38 insertions(+), 6 deletions(-)
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index 4f77b8f..ffc2899 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -54,6 +54,7 @@ typedef int (*hyperv_fill_flush_list_func)(
#define hv_enable_vdso_clocksource() \
vclocks_set_used(VDSO_CLOCKMODE_HVCLOCK);
#define hv_get_raw_timer() rdtsc_ordered()
+#define hv_get_vector() HYPERVISOR_CALLBACK_VECTOR
/*
* Reference to pv_ops must be inline so objtool
diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index 3112544..9264c3f 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -55,9 +55,14 @@
set_irq_regs(old_regs);
}
-void hv_setup_vmbus_irq(void (*handler)(void))
+int hv_setup_vmbus_irq(int irq, void (*handler)(void))
{
+ /*
+* The 'irq' argument is ignored on x86/x64 because a hard-coded
+* interrupt vector is used for Hyper-V interrupts.
+*/
vmbus_handler = handler;
+ return 0;
}
void hv_remove_vmbus_irq(void)
diff --git a/drivers/hv/hv.c b/drivers/hv/hv.c
index da69338..2bd44fd 100644
--- a/drivers/hv/hv.c
+++ b/drivers/hv/hv.c
@@ -180,7 +180,7 @@ void hv_synic_enable_regs(unsigned int cpu)
/* Setup the shared SINT. */
hv_get_synint_state(VMBUS_MESSAGE_SINT, shared_sint.as_uint64);
- shared_sint.vector = HYPERVISOR_CALLBACK_VECTOR;
+ shared_sint.vector = hv_get_vector();
shared_sint.masked = false;
shared_sint.auto_eoi = hv_recommend_using_aeoi();
hv_set_synint_state(VMBUS_MESSAGE_SINT, shared_sint.as_uint64);
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 910b6e9..3f6a42a 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -48,6 +48,10 @@ struct vmbus_dynid {
static void *hv_panic_page;
+/* Values parsed from ACPI DSDT */
+static int vmbus_irq;
+int vmbus_interrupt;
+
/*
* Boolean to control whether to report panic messages over Hyper-V.
*
@@ -1347,7 +1351,7 @@ static void vmbus_isr(void)
tasklet_schedule(_cpu->msg_dpc);
}
- add_interrupt_randomness(HYPERVISOR_CALLBACK_VECTOR, 0);
+ add_interrupt_randomness(hv_get_vector(), 0);
}
/*
@@ -1430,7 +1434,9 @@ static int vmbus_bus_init(void)
if (ret)
return ret;
- hv_setup_vmbus_irq(vmbus_isr);
+ ret = hv_setup_vmbus_irq(vmbus_irq, vmbus_isr);
+ if (ret)
+ goto err_setup;
ret = hv_synic_alloc();
if (ret)
@@ -1505,7 +1511,7 @@ static int vmbus_bus_init(void)
hv_synic_free();
err_alloc:
hv_remove_vmbus_irq();
-
+err_setup:
bus_unregister(_bus);
unregister_sysctl_table(hv_ctl_table_hdr);
hv_ctl_table_hdr = NULL;
@@ -2070,6 +2076,7 @@ static acpi_status vmbus_walk_resources(struct
acpi_resource *res, void *ctx)
struct resource *new_res;
struct resource **old_res = _mmio;
struct resource **prev_res = NULL;
+ struct resource r;
switch (res->type) {
@@ -2088,6 +2095,23 @@ static acpi_status vmbus_walk_resources(struct
acpi_resource *res, void *ctx)
end = res->data.address64.address.maximum;
break;
+ /*
+* The IRQ information is needed only on ARM64, which Hyper-V
+* sets up in the extended format. IRQ information is present
+* on x86/x64 in the non-extended format but it is not used by
+* Linux. So don't bother checking for the non-extended format.
+*/
+ case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:
+ if (!acpi_dev_resource_interrupt(res, 0, )) {
+ pr_err("Unable to parse Hyper-V ACPI interrupt\n");
+ return AE_ERROR;
+ }
+ /* ARM64 INTID for VMbus */
+ vmbus_interrupt = res->data.extended_irq.interrupts[0];
+ /* Linux IRQ number */
+ vmbus_irq =
Re: fs/ocfs2/suballoc.c:2430:2-8: preceding lock on line 2413
Julia, On Fri, Aug 14 2020 at 21:00, Julia Lawall wrote: > On Fri, 14 Aug 2020, Thomas Gleixner wrote: >> That's clearly a false positive. Is there anything what can be done to >> help that cocci script here? > > I have a better version that needs to get pushed. > > But normally these pass through me. Did you get it directly from kbuild? Yes, because I touched the affected lines last :) Thanks, tglx
[GIT PULL] Devicetree fixes for v5.9
Linus, Please pull these 2 DT schema clean-ups. I'm doing them in the merge window to avoid possible conflicts. Rob The following changes since commit 7c2a69f610e64c8dec6a06a66e721f4ce1dd783a: Merge tag 'ceph-for-5.9-rc1' of git://github.com/ceph/ceph-client (2020-08-12 12:51:31 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git tags/devicetree-fixes-for-5.9 for you to fetch changes up to 5f0b06da5cde3f0a613308b89f0afea678559fdf: dt-bindings: Remove more cases of 'allOf' containing a '$ref' (2020-08-14 09:28:52 -0600) Devicetree fixes for v5.9: Another round of 'allOf' removals and whitespace clean-ups of schemas. Rob Herring (2): dt-bindings: Whitespace clean-ups in schema files dt-bindings: Remove more cases of 'allOf' containing a '$ref' .../devicetree/bindings/arm/arm,integrator.yaml| 6 +- .../devicetree/bindings/arm/arm,realview.yaml | 66 +++ .../devicetree/bindings/arm/arm,vexpress-juno.yaml | 12 +-- .../devicetree/bindings/arm/bcm/brcm,bcm11351.yaml | 2 +- .../devicetree/bindings/arm/bcm/brcm,bcm21664.yaml | 2 +- .../devicetree/bindings/arm/bcm/brcm,bcm23550.yaml | 2 +- .../devicetree/bindings/arm/bcm/brcm,cygnus.yaml | 20 ++--- .../devicetree/bindings/arm/bcm/brcm,hr2.yaml | 2 +- .../devicetree/bindings/arm/bcm/brcm,ns2.yaml | 4 +- .../devicetree/bindings/arm/bcm/brcm,nsp.yaml | 14 ++-- .../devicetree/bindings/arm/bcm/brcm,stingray.yaml | 6 +- .../bindings/arm/bcm/brcm,vulcan-soc.yaml | 4 +- .../devicetree/bindings/arm/coresight-cti.yaml | 20 ++--- Documentation/devicetree/bindings/arm/cpus.yaml| 4 +- Documentation/devicetree/bindings/arm/fsl.yaml | 13 +-- .../devicetree/bindings/arm/intel,keembay.yaml | 2 +- .../bindings/arm/mediatek/mediatek,pericfg.yaml| 30 +++ .../devicetree/bindings/bus/baikal,bt1-apb.yaml| 2 +- .../devicetree/bindings/bus/baikal,bt1-axi.yaml| 2 +- .../devicetree/bindings/clock/idt,versaclock5.yaml | 8 +- .../devicetree/bindings/clock/ingenic,cgu.yaml | 16 ++-- .../devicetree/bindings/clock/qcom,mmcc.yaml | 2 +- .../bindings/clock/renesas,cpg-clocks.yaml | 16 ++-- .../bindings/clock/sprd,sc9863a-clk.yaml | 2 +- .../bindings/display/brcm,bcm2835-hdmi.yaml| 3 +- .../bindings/display/bridge/nwl-dsi.yaml | 15 ++-- .../bindings/display/bridge/renesas,lvds.yaml | 18 ++-- .../bindings/display/bridge/simple-bridge.yaml | 18 ++-- .../bindings/display/dsi-controller.yaml | 10 +-- .../bindings/display/ilitek,ili9486.yaml | 4 +- .../devicetree/bindings/display/ingenic,ipu.yaml | 8 +- .../devicetree/bindings/display/ingenic,lcd.yaml | 10 +-- .../devicetree/bindings/display/msm/gmu.yaml | 38 - .../display/panel/asus,z00t-tm5p5-nt35596.yaml | 4 +- .../bindings/display/panel/boe,tv101wum-nl6.yaml | 12 +-- .../bindings/display/panel/elida,kd35t133.yaml | 4 +- .../display/panel/feixin,k101-im2ba02.yaml | 6 +- .../bindings/display/panel/ilitek,ili9322.yaml | 3 +- .../bindings/display/panel/ilitek,ili9881c.yaml| 3 +- .../display/panel/leadtek,ltk050h3146w.yaml| 4 +- .../display/panel/leadtek,ltk500hd1829.yaml| 4 +- .../bindings/display/panel/novatek,nt35510.yaml| 4 +- .../bindings/display/panel/panel-dsi-cm.yaml | 8 +- .../bindings/display/panel/panel-timing.yaml | 20 ++--- .../bindings/display/panel/raydium,rm68200.yaml| 4 +- .../display/panel/samsung,s6e88a0-ams452ef01.yaml | 4 +- .../bindings/display/panel/visionox,rm69299.yaml | 2 +- .../devicetree/bindings/display/st,stm32-dsi.yaml | 3 +- .../bindings/display/ti/ti,j721e-dss.yaml | 2 +- Documentation/devicetree/bindings/dsp/fsl,dsp.yaml | 4 +- .../devicetree/bindings/example-schema.yaml| 4 +- .../devicetree/bindings/fsi/ibm,fsi2spi.yaml | 2 +- .../bindings/gpio/brcm,xgs-iproc-gpio.yaml | 6 +- .../bindings/gpio/renesas,rcar-gpio.yaml | 58 ++--- .../devicetree/bindings/gpu/vivante,gc.yaml| 3 +- .../bindings/hwmon/adi,axi-fan-control.yaml| 2 +- Documentation/devicetree/bindings/i2c/i2c-imx.yaml | 32 Documentation/devicetree/bindings/i2c/i2c-pxa.yaml | 4 +- .../devicetree/bindings/iio/adc/adi,ad7606.yaml| 8 +- .../devicetree/bindings/iio/adc/maxim,max1238.yaml | 2 +- .../bindings/iio/adc/qcom,spmi-vadc.yaml | 22 +++-- .../bindings/iio/adc/rockchip-saradc.yaml | 8 +- .../bindings/iio/amplifiers/adi,hmc425a.yaml | 4 +- .../bindings/iio/chemical/atlas,sensor.yaml| 4 +- .../devicetree/bindings/iio/dac/adi,ad5770r.yaml | 60 +++---
Re: [PATCH] x86/fsgsbase/64: Fix NULL deref in 86_fsgsbase_read_task
On Fri, Aug 14, 2020 at 9:03 PM Andy Lutomirski wrote:
> > On Aug 14, 2020, at 11:16 AM, Eric Dumazet wrote:
> >
> > syzbot found its way in 86_fsgsbase_read_task() [1]
> >
> > Fix is to make sure ldt pointer is not NULL
>
> Acked-by: Andy Lutomirski
>
> Maybe add something like this to the changelog:
>
> This can happen if ptrace() or sigreturn() pokes an LDT selector into FS or
> GS for a task with no LDT and something tries to read the base before a
> return to usermode notices the bad selector and fixes it.
>
> I’ll see if I can whip up a test case too.
This is the reproducer I used to test this on 4.20.17:
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define SEL_LDT 0x4
#define USER_RPL 0x3
#define LDT_SELECTOR(idx) (((idx)<<3) | SEL_LDT | USER_RPL)
int main(void) {
pid_t child = fork();
if (child == -1) err(1, "fork");
if (child == 0) {
prctl(PR_SET_PDEATHSIG, SIGKILL);
while (1) pause();
}
if (ptrace(PTRACE_ATTACH, child, NULL, NULL)) err(1, "PTRACE_ATTACH");
int status;
if (waitpid(child, , __WALL) != child) err(1, "waitpid");
if (ptrace( PTRACE_POKEUSER, child, (void*)offsetof(struct
user_regs_struct, fs), (void*)LDT_SELECTOR(0) ))
err(1, "PTRACE_POKEUSER");
errno = 0;
unsigned long val = ptrace( PTRACE_PEEKUSER, child,
(void*)offsetof(struct user_regs_struct, fs_base), NULL );
printf("PTRACE_PEEKUSER returns user_regs_struct.fs_base = 0x%lx
(%m)\n", val);
}
Re: [RFC-PATCH 1/2] mm: Add __GFP_NO_LOCKS flag
On Fri, Aug 14 2020 at 11:02, Paul E. McKenney wrote: > On Fri, Aug 14, 2020 at 07:49:24PM +0200, Peter Zijlstra wrote: >> On Fri, Aug 14, 2020 at 09:11:06AM -0700, Paul E. McKenney wrote: >> > Just to make sure we are talking about the same thing, please see below >> > for an untested patch that illustrates how I was interpreting your words. >> > Was this what you had in mind? >> >> No, definitely not. >> >> Also, since we used to be able to use call_rcu() _everywhere_, including >> under zone->lock, how's that working with you calling the >> page-allocating from it? > > Indeed, that is exactly the problem we are trying to solve. Wait a moment. Why are we discussing RT induced raw non raw lock ordering at all? Whatever kernel you variant you look at this is not working: lock(zone) call_rcu() lock(zone) It's a simple recursive dead lock, nothing else. And that enforces the GFP_NOLOCK allocation mode or some other solution unless you make a new rule that calling call_rcu() is forbidden while holding zone lock or any other lock which might be nested inside the GFP_NOWAIT zone::lock held region. Thanks, tglx
Re: linux-next: new build warnings after binutils update
On Fri, Aug 14, 2020 at 12:22:06PM +0200, Ingo Molnar wrote: > > [0] > > https://lore.kernel.org/lkml/20200731202738.2577854-6-nived...@alum.mit.edu/ > > It all looked good to me but was a bit late for v5.9, will pick up > after -rc1. Excellent! Thank you. I'll base the orphan series on x86/boot now. Once I send a v6 (there are a few more things to tweak), can you carry that in -tip as well (it includes arm and arm64 as well, all of which depend on several asm-generic patches). Or would you prefer I carry the tree separately? -- Kees Cook
Re: [PATCH v4 07/20] gpiolib: cdev: support GPIO_V2_GET_LINE_IOCTL and GPIO_V2_LINE_GET_VALUES_IOCTL
On Fri, Aug 14, 2020 at 5:04 AM Kent Gibson wrote:
>
> Add support for requesting lines using the GPIO_V2_GET_LINE_IOCTL, and
> returning their current values using GPIO_V2_LINE_GET_VALUES_IOCTL.
>
> Signed-off-by: Kent Gibson
> ---
Hi Kent,
not many comments here, just a couple minor details below.
>
> The struct line implementation is based on the v1 struct linehandle
> implementation.
>
> The line_ioctl() is a simple wrapper around line_get_values() here, but
> will be extended with other ioctls in subsequent patches.
>
> Changes for v4:
> - fix handling of mask in line_get_values
>
> drivers/gpio/gpiolib-cdev.c | 413
> 1 file changed, 413 insertions(+)
>
> diff --git a/drivers/gpio/gpiolib-cdev.c b/drivers/gpio/gpiolib-cdev.c
> index 8b012879fe3f..8671e04ff989 100644
> --- a/drivers/gpio/gpiolib-cdev.c
> +++ b/drivers/gpio/gpiolib-cdev.c
> @@ -1,7 +1,9 @@
> // SPDX-License-Identifier: GPL-2.0
>
> #include
> +#include
> #include
> +#include
> #include
> #include
> #include
> @@ -34,6 +36,7 @@
> * GPIO line handle management
> */
>
> +#ifdef CONFIG_GPIO_CDEV_V1
> /**
> * struct linehandle_state - contains the state of a userspace handle
> * @gdev: the GPIO device the handle pertains to
> @@ -376,6 +379,390 @@ static int linehandle_create(struct gpio_device *gdev,
> void __user *ip)
> linehandle_free(lh);
> return ret;
> }
> +#endif /* CONFIG_GPIO_CDEV_V1 */
> +
> +/**
> + * struct line - contains the state of a userspace line request
> + * @gdev: the GPIO device the line request pertains to
> + * @label: consumer label used to tag descriptors
> + * @num_descs: the number of descriptors held in the descs array
> + * @descs: the GPIO descriptors held by this line request, with @num_descs
> + * elements.
> + */
> +struct line {
How about line_request, line_request_data or line_req_ctx? Something
more intuitive than struct line that doesn't even refer to a single
line. Same for relevant functions below.
> + struct gpio_device *gdev;
> + const char *label;
> + u32 num_descs;
> + struct gpio_desc *descs[];
> +};
> +
> +#define GPIO_V2_LINE_BIAS_FLAGS \
> + (GPIO_V2_LINE_FLAG_BIAS_PULL_UP | \
> +GPIO_V2_LINE_FLAG_BIAS_PULL_DOWN | \
> +GPIO_V2_LINE_FLAG_BIAS_DISABLED)
> +
> +#define GPIO_V2_LINE_DIRECTION_FLAGS \
> + (GPIO_V2_LINE_FLAG_INPUT | \
> +GPIO_V2_LINE_FLAG_OUTPUT)
> +
> +#define GPIO_V2_LINE_DRIVE_FLAGS \
> + (GPIO_V2_LINE_FLAG_OPEN_DRAIN | \
> +GPIO_V2_LINE_FLAG_OPEN_SOURCE)
> +
> +#define GPIO_V2_LINE_VALID_FLAGS \
> + (GPIO_V2_LINE_FLAG_ACTIVE_LOW | \
> +GPIO_V2_LINE_DIRECTION_FLAGS | \
> +GPIO_V2_LINE_DRIVE_FLAGS | \
> +GPIO_V2_LINE_BIAS_FLAGS)
> +
> +static u64 gpio_v2_line_config_flags(struct gpio_v2_line_config *lc,
> +int line_idx)
> +{
> + int i;
> + u64 mask = BIT_ULL(line_idx);
> +
> + for (i = 0; i < lc->num_attrs; i++) {
> + if ((lc->attrs[i].attr.id == GPIO_V2_LINE_ATTR_ID_FLAGS) &&
> + (lc->attrs[i].mask & mask))
> + return lc->attrs[i].attr.flags;
> + }
> + return lc->flags;
> +}
> +
> +static int gpio_v2_line_config_output_value(struct gpio_v2_line_config *lc,
> + int line_idx)
> +{
> + int i;
> + u64 mask = BIT_ULL(line_idx);
> +
> + for (i = 0; i < lc->num_attrs; i++) {
> + if ((lc->attrs[i].attr.id ==
> GPIO_V2_LINE_ATTR_ID_OUTPUT_VALUES) &&
> + (lc->attrs[i].mask & mask))
> + return !!(lc->attrs[i].attr.values & mask);
> + }
> + return 0;
> +}
> +
> +static int gpio_v2_line_flags_validate(u64 flags)
> +{
> + /* Return an error if an unknown flag is set */
> + if (flags & ~GPIO_V2_LINE_VALID_FLAGS)
> + return -EINVAL;
> +
> + /*
> +* Do not allow both INPUT & OUTPUT flags to be set as they are
> +* contradictory.
> +*/
> + if ((flags & GPIO_V2_LINE_FLAG_INPUT) &&
> + (flags & GPIO_V2_LINE_FLAG_OUTPUT))
> + return -EINVAL;
> +
> + /*
> +* Do not allow OPEN_SOURCE & OPEN_DRAIN flags in a single request. If
> +* the hardware actually supports enabling both at the same time the
> +* electrical result would be disastrous.
> +*/
> + if ((flags & GPIO_V2_LINE_FLAG_OPEN_DRAIN) &&
> + (flags & GPIO_V2_LINE_FLAG_OPEN_SOURCE))
> + return -EINVAL;
> +
> + /* Drive requires explicit output direction. */
> + if ((flags & GPIO_V2_LINE_DRIVE_FLAGS) &&
> + !(flags & GPIO_V2_LINE_FLAG_OUTPUT))
> + return -EINVAL;
> +
> + /* Bias requies explicit direction. */
s/requies/requires/
> + if ((flags & GPIO_V2_LINE_BIAS_FLAGS) &&
> + !(flags &
Re: [PATCH] Add power/gpu_frequency tracepoint.
Hi Chris, please see my comments inline. On Fri, Aug 14, 2020 at 8:22 AM Chris Wilson wrote: > > Quoting Peiyong Lin (2020-08-13 22:03:57) > > Historically there is no common trace event for GPU frequency, in > > downstream Android each different hardware vendor implements their own > > way to expose GPU frequency, for example as a debugfs node. This patch > > standardize it as a common trace event in upstream linux kernel to help > > the ecosystem have a common implementation across hardware vendors. > > Toolings in the Linux ecosystem will benefit from this especially in the > > downstream Android, where this information is critical to graphics > > developers. > > > > Signed-off-by: Peiyong Lin > > --- > > drivers/gpu/Makefile| 1 + > > drivers/gpu/trace/Kconfig | 3 +++ > > drivers/gpu/trace/Makefile | 1 + > > drivers/gpu/trace/trace_gpu_frequency.c | 13 + > > include/trace/events/power.h| 26 + > > 5 files changed, 44 insertions(+) > > create mode 100644 drivers/gpu/trace/trace_gpu_frequency.c > > > > diff --git a/drivers/gpu/Makefile b/drivers/gpu/Makefile > > index 835c88318cec..f289a47eb031 100644 > > --- a/drivers/gpu/Makefile > > +++ b/drivers/gpu/Makefile > > @@ -6,3 +6,4 @@ obj-$(CONFIG_TEGRA_HOST1X) += host1x/ > > obj-y += drm/ vga/ > > obj-$(CONFIG_IMX_IPUV3_CORE) += ipu-v3/ > > obj-$(CONFIG_TRACE_GPU_MEM)+= trace/ > > +obj-$(CONFIG_TRACE_GPU_FREQUENCY) += trace/ > > diff --git a/drivers/gpu/trace/Kconfig b/drivers/gpu/trace/Kconfig > > index c24e9edd022e..ac4aec8d5845 100644 > > --- a/drivers/gpu/trace/Kconfig > > +++ b/drivers/gpu/trace/Kconfig > > @@ -2,3 +2,6 @@ > > > > config TRACE_GPU_MEM > > bool > > + > > +config TRACE_GPU_FREQUENCY > > + bool > > diff --git a/drivers/gpu/trace/Makefile b/drivers/gpu/trace/Makefile > > index b70fbdc5847f..2b7ae69327d6 100644 > > --- a/drivers/gpu/trace/Makefile > > +++ b/drivers/gpu/trace/Makefile > > @@ -1,3 +1,4 @@ > > # SPDX-License-Identifier: GPL-2.0 > > > > obj-$(CONFIG_TRACE_GPU_MEM) += trace_gpu_mem.o > > +obj-$(CONFIG_TRACE_GPU_FREQUENCY) += trace_gpu_frequency.o > > diff --git a/drivers/gpu/trace/trace_gpu_frequency.c > > b/drivers/gpu/trace/trace_gpu_frequency.c > > new file mode 100644 > > index ..f5af5800b52d > > --- /dev/null > > +++ b/drivers/gpu/trace/trace_gpu_frequency.c > > @@ -0,0 +1,13 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* > > + * GPU frequency trace points > > + * > > + * Copyright (C) 2020 Google, Inc. > > + */ > > + > > +#include > > + > > +#define CREATE_TRACE_POINTS > > +#include > > + > > +EXPORT_TRACEPOINT_SYMBOL(gpu_frequency); > > diff --git a/include/trace/events/power.h b/include/trace/events/power.h > > index af5018aa9517..befc0157131e 100644 > > --- a/include/trace/events/power.h > > +++ b/include/trace/events/power.h > > @@ -500,6 +500,32 @@ DEFINE_EVENT(dev_pm_qos_request, > > dev_pm_qos_remove_request, > > > > TP_ARGS(name, type, new_value) > > ); > > + > > +/** > > + * gpu_frequency - Reports frequency changes in GPU clock domains > > + * @state: New frequency (in KHz) > > + * @gpu_id: GPU clock domain > > + */ > > +TRACE_EVENT(gpu_frequency, > > + > > + TP_PROTO(unsigned int state, unsigned int gpu_id), > > + > > + TP_ARGS(state, gpu_id), > > + > > + TP_STRUCT__entry( > > + __field(unsigned int, state) > > + __field(unsigned int, gpu_id) > > What is a gpu-id and how are we supposed to create one? gpu_id is the id for per GPU clock domain, it should be created for per GPU clock domain. It's not necessarily tied to a physical GPU. > > 'state' is quite non-descript, and since this is not an event template > you could be a little more specific. > > So when should this tracepoint fire? For the frequency change we request, > or the frequency change of the black box of the pcu? If an implementation implements this, the GPU frequency tracepoint should be fired whenever there's a frequency change. That is to say, when gpu goes from idle to active or vice versa, or when the gpu frequency goes up and down. > > We have found that a tracepoint is not a useful monitor of the actual GPU > frequencies, for that we use provide sampling via perf-events. > -Chris
Re: [RFC PATCH] vsprintf: Add %pv extension replacement for print_vma_addr
On Fri, 2020-08-14 at 14:38 -0400, Steven Rostedt wrote:
> On Fri, 14 Aug 2020 10:53:03 -0700
> Joe Perches wrote:
> I'm fine with all his, but I feel more comfortable if this patch
> created a single copy of the code. Perhaps add:
[]
> diff --git a/mm/memory.c b/mm/memory.c
[]
> @@ -4771,32 +4771,7 @@ EXPORT_SYMBOL_GPL(access_process_vm);
> */
> void print_vma_addr(char *prefix, unsigned long ip)
> {
> - struct mm_struct *mm = current->mm;
> - struct vm_area_struct *vma;
> -
> - /*
> - * we might be running from an atomic context so we cannot sleep
> - */
> - if (!mmap_read_trylock(mm))
> - return;
> -
> - vma = find_vma(mm, ip);
> - if (vma && vma->vm_file) {
> - struct file *f = vma->vm_file;
> - char *buf = (char *)__get_free_page(GFP_NOWAIT);
> - if (buf) {
> - char *p;
> -
> - p = file_path(f, buf, PAGE_SIZE);
> - if (IS_ERR(p))
> - p = "?";
> - printk("%s%s[%lx+%lx]", prefix, kbasename(p),
> - vma->vm_start,
> - vma->vm_end - vma->vm_start);
> - free_page((unsigned long)buf);
> - }
> - }
> - mmap_read_unlock(mm);
> + printk("%s%pv", prefix, ip);
> }
I'd just convert all of them and remove this function instead.
Something like (uncompiled/untested):
---
arch/arc/kernel/troubleshoot.c | 2 +-
arch/arm64/kernel/traps.c | 16 +++--
arch/csky/kernel/traps.c | 11 -
arch/mips/mm/fault.c | 14 +--
arch/parisc/mm/fault.c | 15 +---
arch/powerpc/kernel/traps.c| 8 ++-
arch/riscv/kernel/traps.c | 11 -
arch/s390/mm/fault.c | 7 +++---
arch/sparc/mm/fault_32.c | 8 ++-
arch/sparc/mm/fault_64.c | 8 ++-
arch/um/kernel/trap.c | 13 ---
arch/x86/kernel/signal.c | 6 ++---
arch/x86/kernel/traps.c| 6 ++---
arch/x86/mm/fault.c| 53 +++---
include/linux/mm.h | 7 --
mm/memory.c| 33 --
16 files changed, 74 insertions(+), 144 deletions(-)
diff --git a/arch/arc/kernel/troubleshoot.c b/arch/arc/kernel/troubleshoot.c
index 28e8bf04b253..26ecd59f0057 100644
--- a/arch/arc/kernel/troubleshoot.c
+++ b/arch/arc/kernel/troubleshoot.c
@@ -86,7 +86,7 @@ static void show_faulting_vma(unsigned long address)
struct vm_area_struct *vma;
struct mm_struct *active_mm = current->active_mm;
- /* can't use print_vma_addr() yet as it doesn't check for
+ /* can't use %pv yet as it doesn't check for
* non-inclusive vma
*/
mmap_read_lock(active_mm);
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 13ebd5ca2070..294ed81f67d8 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -224,13 +224,15 @@ static void arm64_show_signal(int signo, const char *str)
!__ratelimit())
return;
- pr_info("%s[%d]: unhandled exception: ", tsk->comm, task_pid_nr(tsk));
- if (esr)
- pr_cont("%s, ESR 0x%08x, ", esr_get_class_string(esr), esr);
-
- pr_cont("%s", str);
- print_vma_addr(KERN_CONT " in ", regs->pc);
- pr_cont("\n");
+ if (esr) {
+ pr_info("%s[%d]: unhandled exception: %s, ESR 0x%08x, %s in
%pv\n",
+ tsk->comm, task_pid_nr(tsk),
+ esr_get_class_string(esr), esr,
+ str, (void *)regs->pc);
+ } else {
+ pr_info("%s[%d]: unhandled exception: %s in %pv\n",
+ tsk->comm, task_pid_nr(tsk), str, (void *)regs->pc);
+ }
__show_regs(regs);
}
diff --git a/arch/csky/kernel/traps.c b/arch/csky/kernel/traps.c
index 959a917c989d..bdf1577237df 100644
--- a/arch/csky/kernel/traps.c
+++ b/arch/csky/kernel/traps.c
@@ -118,12 +118,11 @@ void do_trap(struct pt_regs *regs, int signo, int code,
unsigned long addr)
{
struct task_struct *tsk = current;
- if (show_unhandled_signals && unhandled_signal(tsk, signo)
- && printk_ratelimit()) {
- pr_info("%s[%d]: unhandled signal %d code 0x%x at 0x%08lx",
- tsk->comm, task_pid_nr(tsk), signo, code, addr);
- print_vma_addr(KERN_CONT " in ", instruction_pointer(regs));
- pr_cont("\n");
+ if (show_unhandled_signals && unhandled_signal(tsk, signo) &&
+ printk_ratelimit()) {
+ pr_info("%s[%d]: unhandled signal %d code 0x%x at 0x%08lx in
%pv\n",
+ tsk->comm, task_pid_nr(tsk), signo, code, addr,
+ (void *)instruction_pointer(regs));
show_regs(regs);
}
diff --git
