RE: [PATCH v2 31/39] docs: ABI: cleanup several ABI documents
Acked-by: Peter Chen For: Documentation/ABI/testing/usb-charger-uevent Peter
Re: [PATCH v2 20/39] docs: ABI: testing: make the files compatible with ReST output
Le 30/10/2020 à 08:40, Mauro Carvalho Chehab a écrit : Some files over there won't parse well by Sphinx. Fix them. Acked-by: Jonathan Cameron # for IIO Signed-off-by: Mauro Carvalho Chehab --- ... Documentation/ABI/testing/sysfs-class-cxl | 15 +- ... Documentation/ABI/testing/sysfs-class-ocxl| 3 + Patches 20, 28 and 31 look good for cxl and ocxl. Acked-by: Frederic Barrat Fred
Re: [PATCH v2 31/39] docs: ABI: cleanup several ABI documents
On Fri, 30 Oct 2020 at 01:41, Mauro Carvalho Chehab wrote: > > There are some ABI documents that, while they don't generate > any warnings, they have issues when parsed by get_abi.pl script > on its output result. > > Address them, in order to provide a clean output. > > Acked-by: Jonathan Cameron #for IIO > Reviewed-by: Tom Rix # for fpga-manager > Reviewed-By: Kajol Jain # for > sysfs-bus-event_source-devices-hv_gpci and > sysfs-bus-event_source-devices-hv_24x7 > Acked-by: Oded Gabbay # for Habanalabs > Acked-by: Vaibhav Jain # for sysfs-bus-papr-pmem > Signed-off-by: Mauro Carvalho Chehab > --- > .../testing/sysfs-bus-coresight-devices-etb10 | 5 +- For the CoreSight part: Reviewed-by: Mathieu Poirier
Re: [patch V2 00/18] mm/highmem: Preemptible variant of kmap_atomic & friends
On Sat, Oct 31 2020 at 00:26, Thomas Gleixner wrote: > On Fri, Oct 30 2020 at 15:46, Linus Torvalds wrote: >> On Fri, Oct 30, 2020 at 3:26 PM Thomas Gleixner wrote: >> To me, your patch series has two big advantages: >> >> - more common code >> >> - kmap_local() becomes more of a no-op >> >> and the last thing we want is to expand on kmap. > > Happy to go with that. > > While trying to document the mess, I just stumbled over the abuse of > kmap_atomic_prot() in > > drivers/gpu/drm/ttm/ttm_bo_util.c: dst = kmap_atomic_prot(d, prot); > drivers/gpu/drm/ttm/ttm_bo_util.c: src = kmap_atomic_prot(s, prot); > drivers/gpu/drm/vmwgfx/vmwgfx_blit.c: > kmap_atomic_prot(d->dst_pages[dst_page], > drivers/gpu/drm/vmwgfx/vmwgfx_blit.c: > kmap_atomic_prot(d->src_pages[src_page], > > For !HIGHMEM kmap_atomic_prot() just ignores the 'prot' argument and > returns the page address. > > Moar patches to be written ... Sigh! Or not. This is actually correct by some definition of correct. For the non highmem case pgprot is set via the set_memory_*() functions and this just handles the highmem case. Comments are overrrated...
Re: [patch V2 00/18] mm/highmem: Preemptible variant of kmap_atomic & friends
On Fri, Oct 30 2020 at 15:46, Linus Torvalds wrote: > On Fri, Oct 30, 2020 at 3:26 PM Thomas Gleixner wrote: > To me, your patch series has two big advantages: > > - more common code > > - kmap_local() becomes more of a no-op > > and the last thing we want is to expand on kmap. Happy to go with that. While trying to document the mess, I just stumbled over the abuse of kmap_atomic_prot() in drivers/gpu/drm/ttm/ttm_bo_util.c: dst = kmap_atomic_prot(d, prot); drivers/gpu/drm/ttm/ttm_bo_util.c: src = kmap_atomic_prot(s, prot); drivers/gpu/drm/vmwgfx/vmwgfx_blit.c: kmap_atomic_prot(d->dst_pages[dst_page], drivers/gpu/drm/vmwgfx/vmwgfx_blit.c: kmap_atomic_prot(d->src_pages[src_page], For !HIGHMEM kmap_atomic_prot() just ignores the 'prot' argument and returns the page address. Moar patches to be written ... Sigh! Thanks, tglx
Re: [patch V2 00/18] mm/highmem: Preemptible variant of kmap_atomic & friends
On Fri, Oct 30, 2020 at 3:26 PM Thomas Gleixner wrote: > > While at it I might have a look at that debug request from Willy in the > other end of this thread. Any comment on that? > > https://lore.kernel.org/r/87k0v7mrrd@nanos.tec.linutronix.de I do think that it would be nice to have a debug mode, particularly since over the last few years we've really lost a lot of HIGHMEM coverage (to the point that I've wondered how worthwhile it really is to support at all any more - I think it's Arnd who argued that it's mainly some embedded ARM variants that will want it for the forseeable future). So I'm honestly somewhat torn. I think HIGHMEM is dying, and yes that argues for "non-HIGHMEM had better have some debug coverage", but at the same time I think it doesn't even really matter any more. At some point those embedded ARM platforms just aren't even interesting - they might as well use older kernels if they are the only thing really arguing for HIGHMEM at all. This is one reason why I'd like the new kmap_local() to be a no-op, and I'd prefer for it to have no other side effects - because I want to be ready to remove it entirely some day. And if we end up having some transition where people start rewriting "kmap_atomic()" to be "kmap_local() + explicit preemption disable", then I think that would be a good step on that whole "kmap will eventually go away" path. But I do *not* believe that we need to add _so_ much debug support that we'd catch Willy's "more than one page" case. And I absolutely do not believe for a second that we should start caring about compound pages. NO. kmap() is almost dead already, we're not making it worse. To me, your patch series has two big advantages: - more common code - kmap_local() becomes more of a no-op and the last thing we want is to expand on kmap. Linus
Re: [patch V2 00/18] mm/highmem: Preemptible variant of kmap_atomic & friends
On Fri, Oct 30 2020 at 13:28, Linus Torvalds wrote:
> On Fri, Oct 30, 2020 at 2:39 AM Thomas Gleixner wrote:
>>
>> But then we really should not name it kmap_local. 'local' suggests
>> locality, think local_irq*, local_bh* ... kmap_task would be more
>> accurate then.
>
> So the main reason I'd like to see it is because I think on a
> non-highmem machine, the new kmap should be a complete no-op. IOW,
> we'd make sure that there are no costs, no need to increment any
> "restrict migration" counts etc.
Fair enough.
> It's been a bit of a pain to have kmap_atomic() have magical side
> semantics that people might then depend on.
kmap_atomic() will still have the side semantics :)
> I think "local" could still work as a name, because it would have to
> be thread-local (and maybe we'd want a debug mode where that gets
> verified, as actual HIGHMEM machines are getting rare).
>
> I'd avoid "task", because that implies (to me, at least) that it
> wouldn't be good for interrupts etc that don't have a task context.
>
> I think the main issue is that it has to be released in the same
> context as it was created (ie no passing those things around to other
> contexts). I think "local" is fine for that, but I could imagine other
> names. The ones that come to mind are somewhat cumbersome, though
> ("shortterm" or "local_ctx" or something along those lines).
Yeah, not really intuitive either.
Let's stick with _local and add proper function documentation which
clearly says, that the side effect of non-migratability applies only for
the 32bit highmem case in order to make it work at all.
So code which needs CPU locality cannot rely on it and we have enough
debug stuff to catch something like:
kmap_local()
this_cpu_write()
kunmap_local()
Let me redo the pile.
While at it I might have a look at that debug request from Willy in the
other end of this thread. Any comment on that?
https://lore.kernel.org/r/87k0v7mrrd@nanos.tec.linutronix.de
Thanks,
tglx
[PATCH 05/11 v2] kprobes/ftrace: Add recursion protection to the ftrace callback
From: "Steven Rostedt (VMware)"
If a ftrace callback does not supply its own recursion protection and
does not set the RECURSION_SAFE flag in its ftrace_ops, then ftrace will
make a helper trampoline to do so before calling the callback instead of
just calling the callback directly.
The default for ftrace_ops is going to change. It will expect that handlers
provide their own recursion protection, unless its ftrace_ops states
otherwise.
Link: https://lkml.kernel.org/r/20201028115613.140212...@goodmis.org
Cc: Andrew Morton
Cc: Masami Hiramatsu
Cc: Guo Ren
Cc: "James E.J. Bottomley"
Cc: Helge Deller
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Heiko Carstens
Cc: Vasily Gorbik
Cc: Christian Borntraeger
Cc: Thomas Gleixner
Cc: Borislav Petkov
Cc: x...@kernel.org
Cc: "H. Peter Anvin"
Cc: "Naveen N. Rao"
Cc: Anil S Keshavamurthy
Cc: "David S. Miller"
Cc: linux-c...@vger.kernel.org
Cc: linux-par...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-s...@vger.kernel.org
Signed-off-by: Steven Rostedt (VMware)
---
arch/csky/kernel/probes/ftrace.c | 12 ++--
arch/parisc/kernel/ftrace.c | 13 +++--
arch/powerpc/kernel/kprobes-ftrace.c | 11 ++-
arch/s390/kernel/ftrace.c| 13 +++--
arch/x86/kernel/kprobes/ftrace.c | 12 ++--
5 files changed, 52 insertions(+), 9 deletions(-)
diff --git a/arch/csky/kernel/probes/ftrace.c b/arch/csky/kernel/probes/ftrace.c
index 5264763d05be..5eb2604fdf71 100644
--- a/arch/csky/kernel/probes/ftrace.c
+++ b/arch/csky/kernel/probes/ftrace.c
@@ -13,16 +13,21 @@ int arch_check_ftrace_location(struct kprobe *p)
void kprobe_ftrace_handler(unsigned long ip, unsigned long parent_ip,
struct ftrace_ops *ops, struct pt_regs *regs)
{
+ int bit;
bool lr_saver = false;
struct kprobe *p;
struct kprobe_ctlblk *kcb;
- /* Preempt is disabled by ftrace */
+ bit = ftrace_test_recursion_trylock();
+ if (bit < 0)
+ return;
+
+ preempt_disable_notrace();
p = get_kprobe((kprobe_opcode_t *)ip);
if (!p) {
p = get_kprobe((kprobe_opcode_t *)(ip - MCOUNT_INSN_SIZE));
if (unlikely(!p) || kprobe_disabled(p))
- return;
+ goto out;
lr_saver = true;
}
@@ -56,6 +61,9 @@ void kprobe_ftrace_handler(unsigned long ip, unsigned long
parent_ip,
*/
__this_cpu_write(current_kprobe, NULL);
}
+out:
+ preempt_enable_notrace();
+ ftrace_test_recursion_unlock(bit);
}
NOKPROBE_SYMBOL(kprobe_ftrace_handler);
diff --git a/arch/parisc/kernel/ftrace.c b/arch/parisc/kernel/ftrace.c
index 63e3ecb9da81..4b1fdf15662c 100644
--- a/arch/parisc/kernel/ftrace.c
+++ b/arch/parisc/kernel/ftrace.c
@@ -208,13 +208,19 @@ void kprobe_ftrace_handler(unsigned long ip, unsigned
long parent_ip,
{
struct kprobe_ctlblk *kcb;
struct kprobe *p = get_kprobe((kprobe_opcode_t *)ip);
+ int bit;
- if (unlikely(!p) || kprobe_disabled(p))
+ bit = ftrace_test_recursion_trylock();
+ if (bit < 0)
return;
+ preempt_disable_notrace();
+ if (unlikely(!p) || kprobe_disabled(p))
+ goto out;
+
if (kprobe_running()) {
kprobes_inc_nmissed_count(p);
- return;
+ goto out;
}
__this_cpu_write(current_kprobe, p);
@@ -235,6 +241,9 @@ void kprobe_ftrace_handler(unsigned long ip, unsigned long
parent_ip,
}
}
__this_cpu_write(current_kprobe, NULL);
+out:
+ preempt_enable_notrace();
+ ftrace_test_recursion_unlock(bit);
}
NOKPROBE_SYMBOL(kprobe_ftrace_handler);
diff --git a/arch/powerpc/kernel/kprobes-ftrace.c
b/arch/powerpc/kernel/kprobes-ftrace.c
index 972cb28174b2..5df8d50c65ae 100644
--- a/arch/powerpc/kernel/kprobes-ftrace.c
+++ b/arch/powerpc/kernel/kprobes-ftrace.c
@@ -18,10 +18,16 @@ void kprobe_ftrace_handler(unsigned long nip, unsigned long
parent_nip,
{
struct kprobe *p;
struct kprobe_ctlblk *kcb;
+ int bit;
+ bit = ftrace_test_recursion_trylock();
+ if (bit < 0)
+ return;
+
+ preempt_disable_notrace();
p = get_kprobe((kprobe_opcode_t *)nip);
if (unlikely(!p) || kprobe_disabled(p))
- return;
+ goto out;
kcb = get_kprobe_ctlblk();
if (kprobe_running()) {
@@ -52,6 +58,9 @@ void kprobe_ftrace_handler(unsigned long nip, unsigned long
parent_nip,
*/
__this_cpu_write(current_kprobe, NULL);
}
+out:
+ preempt_enable_notrace();
+ ftrace_test_recursion_unlock(bit);
}
NOKPROBE_SYMBOL(kprobe_ftrace_handler);
diff --git a/arch/s390/kernel/ftrace.c b/arch/s390/kernel/ftrace.c
index b388e87a08bf..88466d7fb6b2 100644
---
[PATCH 11/11 v2] ftrace: Add recording of functions that caused recursion
From: "Steven Rostedt (VMware)" This adds CONFIG_FTRACE_RECORD_RECURSION that will record to a file "recursed_functions" all the functions that caused recursion while a callback to the function tracer was running. Cc: Jonathan Corbet Cc: Guo Ren Cc: "James E.J. Bottomley" Cc: Helge Deller Cc: Michael Ellerman Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Heiko Carstens Cc: Vasily Gorbik Cc: Christian Borntraeger Cc: Thomas Gleixner Cc: Borislav Petkov Cc: x...@kernel.org Cc: "H. Peter Anvin" Cc: Kees Cook Cc: Anton Vorontsov Cc: Colin Cross Cc: Tony Luck Cc: Josh Poimboeuf Cc: Jiri Kosina Cc: Miroslav Benes Cc: Petr Mladek Cc: Joe Lawrence Cc: Kamalesh Babulal Cc: Mauro Carvalho Chehab Cc: Sebastian Andrzej Siewior Cc: linux-...@vger.kernel.org Cc: linux-ker...@vger.kernel.org Cc: linux-c...@vger.kernel.org Cc: linux-par...@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-s...@vger.kernel.org Cc: live-patch...@vger.kernel.org Signed-off-by: Steven Rostedt (VMware) --- Documentation/trace/ftrace-uses.rst | 6 +- arch/csky/kernel/probes/ftrace.c | 2 +- arch/parisc/kernel/ftrace.c | 2 +- arch/powerpc/kernel/kprobes-ftrace.c | 2 +- arch/s390/kernel/ftrace.c | 2 +- arch/x86/kernel/kprobes/ftrace.c | 2 +- fs/pstore/ftrace.c| 2 +- include/linux/trace_recursion.h | 32 +++- kernel/livepatch/patch.c | 2 +- kernel/trace/Kconfig | 25 +++ kernel/trace/Makefile | 1 + kernel/trace/ftrace.c | 4 +- kernel/trace/trace_event_perf.c | 2 +- kernel/trace/trace_functions.c| 2 +- kernel/trace/trace_output.c | 6 +- kernel/trace/trace_output.h | 1 + kernel/trace/trace_recursion_record.c | 220 ++ 17 files changed, 293 insertions(+), 20 deletions(-) create mode 100644 kernel/trace/trace_recursion_record.c diff --git a/Documentation/trace/ftrace-uses.rst b/Documentation/trace/ftrace-uses.rst index 86cd14b8e126..5981d5691745 100644 --- a/Documentation/trace/ftrace-uses.rst +++ b/Documentation/trace/ftrace-uses.rst @@ -118,7 +118,7 @@ can help in this regard. If you start your code with: int bit; - bit = ftrace_test_recursion_trylock(); + bit = ftrace_test_recursion_trylock(ip, parent_ip); if (bit < 0) return; @@ -130,7 +130,9 @@ The code in between will be safe to use, even if it ends up calling a function that the callback is tracing. Note, on success, ftrace_test_recursion_trylock() will disable preemption, and the ftrace_test_recursion_unlock() will enable it again (if it was previously -enabled). +enabled). The instruction pointer (ip) and its parent (parent_ip) is passed to +ftrace_test_recursion_trylock() to record where the recursion happened +(if CONFIG_FTRACE_RECORD_RECURSION is set). Alternatively, if the FTRACE_OPS_FL_RECURSION flag is set on the ftrace_ops (as explained below), then a helper trampoline will be used to test diff --git a/arch/csky/kernel/probes/ftrace.c b/arch/csky/kernel/probes/ftrace.c index 5eb2604fdf71..f30b179924ef 100644 --- a/arch/csky/kernel/probes/ftrace.c +++ b/arch/csky/kernel/probes/ftrace.c @@ -18,7 +18,7 @@ void kprobe_ftrace_handler(unsigned long ip, unsigned long parent_ip, struct kprobe *p; struct kprobe_ctlblk *kcb; - bit = ftrace_test_recursion_trylock(); + bit = ftrace_test_recursion_trylock(ip, parent_ip); if (bit < 0) return; diff --git a/arch/parisc/kernel/ftrace.c b/arch/parisc/kernel/ftrace.c index 4b1fdf15662c..8b0ed7c5a4ab 100644 --- a/arch/parisc/kernel/ftrace.c +++ b/arch/parisc/kernel/ftrace.c @@ -210,7 +210,7 @@ void kprobe_ftrace_handler(unsigned long ip, unsigned long parent_ip, struct kprobe *p = get_kprobe((kprobe_opcode_t *)ip); int bit; - bit = ftrace_test_recursion_trylock(); + bit = ftrace_test_recursion_trylock(ip, parent_ip); if (bit < 0) return; diff --git a/arch/powerpc/kernel/kprobes-ftrace.c b/arch/powerpc/kernel/kprobes-ftrace.c index 5df8d50c65ae..fdfee39938ea 100644 --- a/arch/powerpc/kernel/kprobes-ftrace.c +++ b/arch/powerpc/kernel/kprobes-ftrace.c @@ -20,7 +20,7 @@ void kprobe_ftrace_handler(unsigned long nip, unsigned long parent_nip, struct kprobe_ctlblk *kcb; int bit; - bit = ftrace_test_recursion_trylock(); + bit = ftrace_test_recursion_trylock(nip, parent_nip); if (bit < 0) return; diff --git a/arch/s390/kernel/ftrace.c b/arch/s390/kernel/ftrace.c index 88466d7fb6b2..a1556333d481 100644 --- a/arch/s390/kernel/ftrace.c +++ b/arch/s390/kernel/ftrace.c @@ -204,7 +204,7 @@ void kprobe_ftrace_handler(unsigned long ip, unsigned long parent_ip, struct kprobe *p = get_kprobe((kprobe_opcode_t *)ip); int bit; - bit =
Re: [patch V2 00/18] mm/highmem: Preemptible variant of kmap_atomic & friends
On Fri, Oct 30, 2020 at 2:39 AM Thomas Gleixner wrote:
>
> But then we really should not name it kmap_local. 'local' suggests
> locality, think local_irq*, local_bh* ... kmap_task would be more
> accurate then.
So the main reason I'd like to see it is because I think on a
non-highmem machine, the new kmap should be a complete no-op. IOW,
we'd make sure that there are no costs, no need to increment any
"restrict migration" counts etc.
It's been a bit of a pain to have kmap_atomic() have magical side
semantics that people might then depend on.
I think "local" could still work as a name, because it would have to
be thread-local (and maybe we'd want a debug mode where that gets
verified, as actual HIGHMEM machines are getting rare).
I'd avoid "task", because that implies (to me, at least) that it
wouldn't be good for interrupts etc that don't have a task context.
I think the main issue is that it has to be released in the same
context as it was created (ie no passing those things around to other
contexts). I think "local" is fine for that, but I could imagine other
names. The ones that come to mind are somewhat cumbersome, though
("shortterm" or "local_ctx" or something along those lines).
I dunno.
Linus
Re: [patch V2 00/18] mm/highmem: Preemptible variant of kmap_atomic & friends
On Fri, Oct 30 2020 at 13:06, Matthew Wilcox wrote: > On Thu, Oct 29, 2020 at 11:18:06PM +0100, Thomas Gleixner wrote: >> This series provides kmap_local.* iomap_local variants which only disable >> migration to keep the virtual mapping address stable accross preemption, >> but do neither disable pagefaults nor preemption. The new functions can be >> used in any context, but if used in atomic context the caller has to take >> care of eventually disabling pagefaults. > > Could I ask for a CONFIG_KMAP_DEBUG which aliases all the kmap variants > to vmap()? I think we currently have a problem in iov_iter on HIGHMEM > configs: For kmap() that would work, but for kmap_atomic() not so much when it is called in non-preemptible context because vmap() might sleep. > copy_page_to_iter() calls page_copy_sane() which checks: > > head = compound_head(page); > if (likely(n <= v && v <= page_size(head))) > return true; > > but then: > > void *kaddr = kmap_atomic(page); > size_t wanted = copy_to_iter(kaddr + offset, bytes, i); > kunmap_atomic(kaddr); > > so if offset to offset+bytes is larger than PAGE_SIZE, this is going to > work for lowmem pages and fail miserably for highmem pages. I suggest > vmap() because vmap has a PAGE_SIZE gap between each allocation. On 32bit highmem the kmap_atomic() case is easy: Double the number of mapping slots and only use every second one, which gives you a guard page between the maps. For 64bit we could do something ugly: Enable the highmem kmap_atomic() crud and enforce an alias mapping (at least on the architectures where this is reasonable). Then you get the same as for 32bit. > Alternatively if we could have a kmap_atomic_compound(), that would > be awesome, but probably not realistic to implement. I've more > or less resigned myself to having to map things one page at a time. That might be horribly awesome on 32bit :) Thanks, tglx
Re: [PATCH net-next 00/15] in_interrupt() cleanup, part 2
On Tue, 27 Oct 2020 23:54:39 +0100 Sebastian Andrzej Siewior wrote: > Folks, > > in the discussion about preempt count consistency across kernel > configurations: > > https://lore.kernel.org/r/20200914204209.256266...@linutronix.de/ > > Linus clearly requested that code in drivers and libraries which changes > behaviour based on execution context should either be split up so that > e.g. task context invocations and BH invocations have different interfaces > or if that's not possible the context information has to be provided by the > caller which knows in which context it is executing. > > This includes conditional locking, allocation mode (GFP_*) decisions and > avoidance of code paths which might sleep. > > In the long run, usage of 'preemptible, in_*irq etc.' should be banned from > driver code completely. > > This is part two addressing remaining drivers except for orinoco-usb. Freescale folks - can I get an ack for merging the last three patches into net-next?
[Bug 209733] Starting new KVM virtual machines on PPC64 starts to hang after box is up for a while
https://bugzilla.kernel.org/show_bug.cgi?id=209733 --- Comment #1 from Cameron (c...@neo-zeon.de) --- Still happens with 5.9.2. -- You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH] powerpc/32s: Setup the early hash table at all time.
# # Automatically generated file; DO NOT EDIT. # Linux/powerpc 5.10.0-rc1 Kernel Configuration # CONFIG_CC_VERSION_TEXT="gcc-4.9 (SUSE Linux) 4.9.3" CONFIG_CC_IS_GCC=y CONFIG_GCC_VERSION=40903 CONFIG_LD_VERSION=23501 CONFIG_CLANG_VERSION=0 CONFIG_CC_CAN_LINK=y CONFIG_CC_CAN_LINK_STATIC=y CONFIG_CC_HAS_ASM_GOTO=y CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_TABLE_SORT=y CONFIG_THREAD_INFO_IN_TASK=y # # General setup # CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_BUILD_SALT="" CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_XZ is not set CONFIG_DEFAULT_INIT="" CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y CONFIG_WATCH_QUEUE=y CONFIG_CROSS_MEMORY_ATTACH=y CONFIG_USELIB=y CONFIG_AUDIT=y CONFIG_HAVE_ARCH_AUDITSYSCALL=y CONFIG_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_SHOW_LEVEL=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y # CONFIG_GENERIC_IRQ_DEBUGFS is not set # end of IRQ subsystem CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y # end of Timers subsystem # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_VIRT_CPU_ACCOUNTING_NATIVE is not set # CONFIG_IRQ_TIME_ACCOUNTING is not set CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y CONFIG_PSI=y # CONFIG_PSI_DEFAULT_DISABLED is not set # end of CPU/Task time and stats accounting # # RCU Subsystem # CONFIG_TINY_RCU=y # CONFIG_RCU_EXPERT is not set CONFIG_SRCU=y CONFIG_TINY_SRCU=y CONFIG_TASKS_RCU_GENERIC=y CONFIG_TASKS_TRACE_RCU=y # end of RCU Subsystem CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_IKHEADERS is not set CONFIG_LOG_BUF_SHIFT=18 CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=13 # # Scheduler features # # end of Scheduler features CONFIG_CGROUPS=y CONFIG_PAGE_COUNTER=y CONFIG_MEMCG=y CONFIG_MEMCG_SWAP=y CONFIG_MEMCG_KMEM=y CONFIG_BLK_CGROUP=y CONFIG_CGROUP_WRITEBACK=y CONFIG_CGROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y CONFIG_CFS_BANDWIDTH=y CONFIG_RT_GROUP_SCHED=y CONFIG_CGROUP_PIDS=y # CONFIG_CGROUP_RDMA is not set CONFIG_CGROUP_FREEZER=y CONFIG_CGROUP_DEVICE=y CONFIG_CGROUP_CPUACCT=y # CONFIG_CGROUP_BPF is not set # CONFIG_CGROUP_DEBUG is not set CONFIG_SOCK_CGROUP_DATA=y CONFIG_NAMESPACES=y CONFIG_UTS_NS=y CONFIG_IPC_NS=y CONFIG_USER_NS=y CONFIG_PID_NS=y CONFIG_NET_NS=y # CONFIG_CHECKPOINT_RESTORE is not set CONFIG_SCHED_AUTOGROUP=y # CONFIG_SYSFS_DEPRECATED is not set CONFIG_RELAY=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_RD_GZIP=y CONFIG_RD_BZIP2=y CONFIG_RD_LZMA=y CONFIG_RD_XZ=y CONFIG_RD_LZO=y CONFIG_RD_LZ4=y CONFIG_RD_ZSTD=y CONFIG_BOOT_CONFIG=y # CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_HAVE_LD_DEAD_CODE_DATA_ELIMINATION=y # CONFIG_LD_DEAD_CODE_DATA_ELIMINATION is not set CONFIG_SYSCTL=y CONFIG_SYSCTL_EXCEPTION_TRACE=y CONFIG_BPF=y CONFIG_EXPERT=y CONFIG_MULTIUSER=y CONFIG_SGETMASK_SYSCALL=y CONFIG_SYSFS_SYSCALL=y CONFIG_FHANDLE=y CONFIG_POSIX_TIMERS=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_FUTEX_PI=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_IO_URING=y CONFIG_ADVISE_SYSCALLS=y CONFIG_MEMBARRIER=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_KALLSYMS_BASE_RELATIVE=y CONFIG_BPF_SYSCALL=y # CONFIG_BPF_PRELOAD is not set CONFIG_USERFAULTFD=y CONFIG_ARCH_HAS_MEMBARRIER_CALLBACKS=y CONFIG_ARCH_HAS_MEMBARRIER_SYNC_CORE=y CONFIG_RSEQ=y # CONFIG_DEBUG_RSEQ is not set # CONFIG_EMBEDDED is not set CONFIG_HAVE_PERF_EVENTS=y # CONFIG_PC104 is not set # # Kernel Performance Events And Counters # # CONFIG_PERF_EVENTS is not set # end of Kernel Performance Events And Counters CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y CONFIG_SLUB_MEMCG_SYSFS_ON=y # CONFIG_COMPAT_BRK is not set # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_SLAB_MERGE_DEFAULT=y # CONFIG_SLAB_FREELIST_RANDOM is not set # CONFIG_SLAB_FREELIST_HARDENED is not set # CONFIG_SHUFFLE_PAGE_ALLOCATOR is not set CONFIG_SYSTEM_DATA_VERIFICATION=y # CONFIG_PROFILING is not set # end of General setup CONFIG_PPC32=y # CONFIG_PPC64 is not set CONFIG_PPC_BOOK3S_32=y # # Processor support # CONFIG_PPC_BOOK3S_6xx=y # CONFIG_PPC_85xx is not set # CONFIG_PPC_8xx is not set # CONFIG_40x is not set # CONFIG_44x is not set # CONFIG_E200 is not set # CONFIG_GENERIC_CPU is not set # CONFIG_E300C2_CPU is not set #
Re: [patch V2 00/18] mm/highmem: Preemptible variant of kmap_atomic & friends
On Thu, Oct 29, 2020 at 11:18:06PM +0100, Thomas Gleixner wrote: > This series provides kmap_local.* iomap_local variants which only disable > migration to keep the virtual mapping address stable accross preemption, > but do neither disable pagefaults nor preemption. The new functions can be > used in any context, but if used in atomic context the caller has to take > care of eventually disabling pagefaults. Could I ask for a CONFIG_KMAP_DEBUG which aliases all the kmap variants to vmap()? I think we currently have a problem in iov_iter on HIGHMEM configs: copy_page_to_iter() calls page_copy_sane() which checks: head = compound_head(page); if (likely(n <= v && v <= page_size(head))) return true; but then: void *kaddr = kmap_atomic(page); size_t wanted = copy_to_iter(kaddr + offset, bytes, i); kunmap_atomic(kaddr); so if offset to offset+bytes is larger than PAGE_SIZE, this is going to work for lowmem pages and fail miserably for highmem pages. I suggest vmap() because vmap has a PAGE_SIZE gap between each allocation. Alternatively if we could have a kmap_atomic_compound(), that would be awesome, but probably not realistic to implement. I've more or less resigned myself to having to map things one page at a time.
Re: [PATCH] powerpc/32s: Setup the early hash table at all time.
Andreas Schwab a écrit : On Okt 30 2020, Michael Ellerman wrote: Andreas Schwab writes: On Okt 01 2020, Christophe Leroy wrote: At the time being, an early hash table is set up when CONFIG_KASAN is selected. There is nothing wrong with setting such an early hash table all the time, even if it is not used. This is a statically allocated 256 kB table which lies in the init data section. This makes the code simpler and may in the future allow to setup early IO mappings with fixmap instead of hard coding BATs. Put create_hpte() and flush_hash_pages() in the .ref.text section in order to avoid warning for the reference to early_hash[]. This reference is removed by MMU_init_hw_patch() before init memory is freed. This breaks booting on the iBook G4. Do you get an oops or anything? Nope, nothing at all. Under qemu it was working. Can you share your .config, or are you using one of the defconfig ? Christophe
Re: [PATCH 02/29] powerpc/rtas: prevent suspend-related sys_rtas use on LE
Andrew Donnellan writes: > On 30/10/20 12:17 pm, Nathan Lynch wrote: >> While drmgr has had work in some areas to make its RTAS syscall >> interactions endian-neutral, its code for performing partition >> migration via the syscall has never worked on LE. While it is able to >> complete ibm,suspend-me successfully, it crashes when attempting the >> subsequent ibm,update-nodes call. >> >> drmgr is the only known (or plausible) user of these ibm,suspend-me, >> ibm,update-nodes, and ibm,update-properties, so allow them only in >> big-endian configurations. > > And there's a zero chance that drmgr will ever be fixed on LE? It's always used the sysfs interface on LE, and the only way to provoke it to attempt the syscalls is by doing something like this before running the migration: # echo 0 > /tmp/fake_api_version # mount -o bind,ro /tmp/fake_api_version /sys/kernel/mobility/api_version So I'm not aware of any circumstance that would actually motivate someone to make it work on LE. I'd say it's more likely that drmgr will drop its support for using the syscall altogether.
Re: [PATCH v2 31/39] docs: ABI: cleanup several ABI documents
On Fri, Oct 30, 2020 at 8:41 AM Mauro Carvalho Chehab wrote: > > There are some ABI documents that, while they don't generate > any warnings, they have issues when parsed by get_abi.pl script > on its output result. > > Address them, in order to provide a clean output. > > Acked-by: Jonathan Cameron #for IIO > Reviewed-by: Tom Rix # for fpga-manager > Reviewed-By: Kajol Jain # for > sysfs-bus-event_source-devices-hv_gpci and > sysfs-bus-event_source-devices-hv_24x7 > Acked-by: Oded Gabbay # for Habanalabs > Acked-by: Vaibhav Jain # for sysfs-bus-papr-pmem > Signed-off-by: Mauro Carvalho Chehab > > [...] > > Documentation/ABI/testing/sysfs-bus-rbd | 37 ++- Acked-by: Ilya Dryomov # for rbd Thanks, Ilya
Re: [PATCH v2 20/39] docs: ABI: testing: make the files compatible with ReST output
Em Fri, 30 Oct 2020 10:19:12 +0100 Fabrice Gasnier escreveu: > Hi Mauro, > > [...] > > > > > +What: > > /sys/bus/iio/devices/iio:deviceX/in_count_quadrature_mode_available > > +KernelVersion: 4.12 > > +Contact: benjamin.gaign...@st.com > > +Description: > > + Reading returns the list possible quadrature modes. > > + > > +What: > > /sys/bus/iio/devices/iio:deviceX/in_count0_quadrature_mode > > +KernelVersion: 4.12 > > +Contact: benjamin.gaign...@st.com > > +Description: > > + Configure the device counter quadrature modes: > > + > > + channel_A: > > + Encoder A input servers as the count input and B as > > + the UP/DOWN direction control input. > > + > > + channel_B: > > + Encoder B input serves as the count input and A as > > + the UP/DOWN direction control input. > > + > > + quadrature: > > + Encoder A and B inputs are mixed to get direction > > + and count with a scale of 0.25. > > + > Hi Fabrice, > I just noticed that since Jonathan question in v1. > > Above ABI has been moved in the past as discussed in [1]. You can take a > look at: > b299d00 IIO: stm32: Remove quadrature related functions from trigger driver > > Could you please remove the above chunk ? > > With that, for the stm32 part: > Acked-by: Fabrice Gasnier Hmm... probably those were re-introduced due to a rebase. This series were originally written about 1,5 years ago. I'll drop those hunks. Thanks! Mauro
Re: [PATCH v2 20/39] docs: ABI: testing: make the files compatible with ReST output
On 10/30/20 8:40 AM, Mauro Carvalho Chehab wrote: > Some files over there won't parse well by Sphinx. > > Fix them. > > Acked-by: Jonathan Cameron # for IIO > Signed-off-by: Mauro Carvalho Chehab > --- > .../ABI/testing/configfs-spear-pcie-gadget| 36 +-- > Documentation/ABI/testing/configfs-usb-gadget | 83 +++--- > .../ABI/testing/configfs-usb-gadget-hid | 10 +- > .../ABI/testing/configfs-usb-gadget-rndis | 16 +- > .../ABI/testing/configfs-usb-gadget-uac1 | 18 +- > .../ABI/testing/configfs-usb-gadget-uvc | 220 +--- > Documentation/ABI/testing/debugfs-ec | 11 +- > Documentation/ABI/testing/debugfs-pktcdvd | 11 +- > Documentation/ABI/testing/dev-kmsg| 27 +- > Documentation/ABI/testing/evm | 17 +- > Documentation/ABI/testing/ima_policy | 30 ++- > Documentation/ABI/testing/procfs-diskstats| 40 +-- > Documentation/ABI/testing/sysfs-block | 38 +-- > Documentation/ABI/testing/sysfs-block-device | 2 + > Documentation/ABI/testing/sysfs-bus-acpi | 18 +- > .../sysfs-bus-event_source-devices-format | 3 +- > .../ABI/testing/sysfs-bus-i2c-devices-pca954x | 27 +- > Documentation/ABI/testing/sysfs-bus-iio | 11 + > .../sysfs-bus-iio-adc-envelope-detector | 5 +- > .../ABI/testing/sysfs-bus-iio-cros-ec | 2 +- > .../ABI/testing/sysfs-bus-iio-dfsdm-adc-stm32 | 8 +- > .../ABI/testing/sysfs-bus-iio-lptimer-stm32 | 29 ++- > .../sysfs-bus-iio-magnetometer-hmc5843| 19 +- > .../sysfs-bus-iio-temperature-max31856| 19 +- > .../ABI/testing/sysfs-bus-iio-timer-stm32 | 137 ++ > .../testing/sysfs-bus-intel_th-devices-msc| 4 + > Documentation/ABI/testing/sysfs-bus-nfit | 2 +- > .../testing/sysfs-bus-pci-devices-aer_stats | 119 + > Documentation/ABI/testing/sysfs-bus-rapidio | 23 +- > .../ABI/testing/sysfs-bus-thunderbolt | 40 +-- > Documentation/ABI/testing/sysfs-bus-usb | 30 ++- > .../testing/sysfs-bus-usb-devices-usbsevseg | 7 +- > Documentation/ABI/testing/sysfs-bus-vfio-mdev | 10 +- > Documentation/ABI/testing/sysfs-class-cxl | 15 +- > Documentation/ABI/testing/sysfs-class-led | 2 +- > .../testing/sysfs-class-led-driver-el15203000 | 229 - > .../ABI/testing/sysfs-class-led-driver-sc27xx | 4 +- > Documentation/ABI/testing/sysfs-class-mic | 52 ++-- > Documentation/ABI/testing/sysfs-class-ocxl| 3 + > Documentation/ABI/testing/sysfs-class-power | 73 +- > .../ABI/testing/sysfs-class-power-twl4030 | 33 +-- > Documentation/ABI/testing/sysfs-class-rc | 30 ++- > .../ABI/testing/sysfs-class-scsi_host | 7 +- > Documentation/ABI/testing/sysfs-class-typec | 12 +- > .../testing/sysfs-devices-platform-ACPI-TAD | 4 + > .../ABI/testing/sysfs-devices-platform-docg3 | 10 +- > .../sysfs-devices-platform-sh_mobile_lcdc_fb | 8 +- > .../ABI/testing/sysfs-devices-system-cpu | 99 +--- > .../ABI/testing/sysfs-devices-system-ibm-rtl | 6 +- > .../testing/sysfs-driver-bd9571mwv-regulator | 4 + > Documentation/ABI/testing/sysfs-driver-genwqe | 11 +- > .../testing/sysfs-driver-hid-logitech-lg4ff | 18 +- > .../ABI/testing/sysfs-driver-hid-wiimote | 11 +- > .../ABI/testing/sysfs-driver-samsung-laptop | 13 +- > .../ABI/testing/sysfs-driver-toshiba_acpi | 26 ++ > .../ABI/testing/sysfs-driver-toshiba_haps | 2 + > Documentation/ABI/testing/sysfs-driver-wacom | 4 +- > Documentation/ABI/testing/sysfs-firmware-acpi | 237 +- > .../ABI/testing/sysfs-firmware-dmi-entries| 50 ++-- > Documentation/ABI/testing/sysfs-firmware-gsmi | 2 +- > .../ABI/testing/sysfs-firmware-memmap | 16 +- > Documentation/ABI/testing/sysfs-fs-ext4 | 4 +- > .../ABI/testing/sysfs-hypervisor-xen | 13 +- > .../ABI/testing/sysfs-kernel-boot_params | 23 +- > .../ABI/testing/sysfs-kernel-mm-hugepages | 12 +- > .../ABI/testing/sysfs-platform-asus-laptop| 21 +- > .../ABI/testing/sysfs-platform-asus-wmi | 1 + > Documentation/ABI/testing/sysfs-platform-at91 | 10 +- > .../ABI/testing/sysfs-platform-eeepc-laptop | 14 +- > .../ABI/testing/sysfs-platform-ideapad-laptop | 9 +- > .../sysfs-platform-intel-wmi-thunderbolt | 1 + > .../ABI/testing/sysfs-platform-sst-atom | 13 +- > .../ABI/testing/sysfs-platform-usbip-vudc | 11 +- > Documentation/ABI/testing/sysfs-ptp | 2 +- > 74 files changed, 1322 insertions(+), 865 deletions(-) > Hi Mauro, [...] > > +What: > /sys/bus/iio/devices/iio:deviceX/in_count_quadrature_mode_available > +KernelVersion: 4.12 > +Contact: benjamin.gaign...@st.com > +Description: > + Reading returns the list possible quadrature modes. > + > +What: > /sys/bus/iio/devices/iio:deviceX/in_count0_quadrature_mode
Re: [PATCH v2 31/39] docs: ABI: cleanup several ABI documents
On 10/30/20 7:40 AM, Mauro Carvalho Chehab wrote: There are some ABI documents that, while they don't generate any warnings, they have issues when parsed by get_abi.pl script on its output result. Address them, in order to provide a clean output. Acked-by: Jonathan Cameron #for IIO Reviewed-by: Tom Rix # for fpga-manager Reviewed-By: Kajol Jain # for sysfs-bus-event_source-devices-hv_gpci and sysfs-bus-event_source-devices-hv_24x7 Acked-by: Oded Gabbay # for Habanalabs Acked-by: Vaibhav Jain # for sysfs-bus-papr-pmem Signed-off-by: Mauro Carvalho Chehab .../testing/sysfs-bus-coresight-devices-etb10 | 5 +- For the above, Acked-by: Suzuki K Poulose
RE: [PATCH v2 31/39] docs: ABI: cleanup several ABI documents
On 2020-10-30 8:40 AM, Mauro Carvalho Chehab wrote: > There are some ABI documents that, while they don't generate > any warnings, they have issues when parsed by get_abi.pl script > on its output result. > > Address them, in order to provide a clean output. > > Acked-by: Jonathan Cameron #for IIO > Reviewed-by: Tom Rix # for fpga-manager > Reviewed-By: Kajol Jain # for > sysfs-bus-event_source-devices-hv_gpci and > sysfs-bus-event_source-devices-hv_24x7 > Acked-by: Oded Gabbay # for Habanalabs > Acked-by: Vaibhav Jain # for sysfs-bus-papr-pmem > Signed-off-by: Mauro Carvalho Chehab > --- sysfs-bus-pci-devices-catpt changes LGTM, thanks. Acked-by: Cezary Rojewski # for catpt Regards, Czarek > Documentation/ABI/obsolete/sysfs-class-dax| 8 +- > .../ABI/obsolete/sysfs-driver-hid-roccat-pyra | 3 + > Documentation/ABI/removed/devfs | 1 + > Documentation/ABI/removed/raw1394 | 1 + > Documentation/ABI/removed/sysfs-class-rfkill | 2 +- > Documentation/ABI/removed/video1394 | 1 + > Documentation/ABI/stable/firewire-cdev| 63 ++--- > Documentation/ABI/stable/sysfs-acpi-pmprofile | 4 +- > Documentation/ABI/stable/sysfs-bus-w1 | 1 + > Documentation/ABI/stable/sysfs-class-tpm | 4 +- > Documentation/ABI/stable/sysfs-driver-speakup | 4 + > Documentation/ABI/testing/configfs-most | 135 +++ > .../ABI/testing/configfs-usb-gadget-ecm | 12 +- > .../ABI/testing/configfs-usb-gadget-eem | 10 +- > .../ABI/testing/configfs-usb-gadget-loopback | 6 +- > .../testing/configfs-usb-gadget-mass-storage | 18 +- > .../ABI/testing/configfs-usb-gadget-midi | 14 +- > .../ABI/testing/configfs-usb-gadget-printer | 6 +- > .../testing/configfs-usb-gadget-sourcesink| 18 +- > .../ABI/testing/configfs-usb-gadget-subset| 10 +- > .../ABI/testing/configfs-usb-gadget-uac2 | 14 +- > .../ABI/testing/configfs-usb-gadget-uvc | 2 +- > .../ABI/testing/debugfs-cec-error-inj | 2 +- > .../ABI/testing/debugfs-driver-habanalabs | 12 +- > .../ABI/testing/debugfs-pfo-nx-crypto | 28 +-- > Documentation/ABI/testing/debugfs-pktcdvd | 2 +- > .../ABI/testing/debugfs-turris-mox-rwtm | 10 +- > Documentation/ABI/testing/debugfs-wilco-ec| 21 +- > Documentation/ABI/testing/dell-smbios-wmi | 32 +-- > Documentation/ABI/testing/gpio-cdev | 13 +- > Documentation/ABI/testing/procfs-diskstats| 6 +- > Documentation/ABI/testing/procfs-smaps_rollup | 48 ++-- > Documentation/ABI/testing/pstore | 19 +- > Documentation/ABI/testing/sysfs-block-rnbd| 4 +- > Documentation/ABI/testing/sysfs-bus-acpi | 1 + > .../testing/sysfs-bus-coresight-devices-etb10 | 5 +- > Documentation/ABI/testing/sysfs-bus-css | 3 + > Documentation/ABI/testing/sysfs-bus-dfl | 2 + > .../sysfs-bus-event_source-devices-hv_24x7| 6 +- > .../sysfs-bus-event_source-devices-hv_gpci| 7 +- > Documentation/ABI/testing/sysfs-bus-fcoe | 68 -- > Documentation/ABI/testing/sysfs-bus-fsl-mc| 12 +- > .../ABI/testing/sysfs-bus-i2c-devices-fsa9480 | 26 +- > Documentation/ABI/testing/sysfs-bus-i3c | 2 + > Documentation/ABI/testing/sysfs-bus-iio | 19 +- > .../ABI/testing/sysfs-bus-iio-adc-hi8435 | 5 + > .../ABI/testing/sysfs-bus-iio-adc-stm32 | 3 + > .../ABI/testing/sysfs-bus-iio-distance-srf08 | 7 +- > .../testing/sysfs-bus-iio-frequency-ad9523| 2 + > .../testing/sysfs-bus-iio-frequency-adf4371 | 10 +- > .../ABI/testing/sysfs-bus-iio-health-afe440x | 12 +- > .../ABI/testing/sysfs-bus-iio-light-isl29018 | 6 +- > .../testing/sysfs-bus-intel_th-devices-gth| 11 +- > Documentation/ABI/testing/sysfs-bus-papr-pmem | 23 +- > Documentation/ABI/testing/sysfs-bus-pci | 22 +- > .../ABI/testing/sysfs-bus-pci-devices-catpt | 1 + > .../testing/sysfs-bus-pci-drivers-ehci_hcd| 4 +- > Documentation/ABI/testing/sysfs-bus-rbd | 37 ++- > Documentation/ABI/testing/sysfs-bus-siox | 3 + > .../ABI/testing/sysfs-bus-thunderbolt | 18 +- > Documentation/ABI/testing/sysfs-bus-usb | 2 + > .../sysfs-class-backlight-driver-lm3533 | 26 +- > Documentation/ABI/testing/sysfs-class-bdi | 1 - > .../ABI/testing/sysfs-class-chromeos | 15 +- > Documentation/ABI/testing/sysfs-class-cxl | 8 +- > Documentation/ABI/testing/sysfs-class-devlink | 30 ++- > Documentation/ABI/testing/sysfs-class-extcon | 34 +-- > .../ABI/testing/sysfs-class-fpga-manager | 5 +- > Documentation/ABI/testing/sysfs-class-gnss| 2 + > Documentation/ABI/testing/sysfs-class-led | 1 + > .../testing/sysfs-class-led-driver-el15203000 | 30 +-- > .../ABI/testing/sysfs-class-led-driver-lm3533 | 44 ++-- >
Re: [PATCH v2 19/39] docs: ABI: stable: make files ReST compatible
On 30/10/2020 07:40, Mauro Carvalho Chehab wrote: Several entries at the stable ABI files won't parse if we pass them directly to the ReST output. Adjust them, in order to allow adding their contents as-is at the stable ABI book. Signed-off-by: Mauro Carvalho Chehab --- Documentation/ABI/stable/firewire-cdev| 4 + Documentation/ABI/stable/sysfs-acpi-pmprofile | 22 +++-- Documentation/ABI/stable/sysfs-bus-firewire | 3 + Documentation/ABI/stable/sysfs-bus-nvmem | 19 ++-- for nvmem parts: Acked-by: Srinivas Kandagatla --srini Documentation/ABI/stable/sysfs-bus-usb| 6 +- .../ABI/stable/sysfs-class-backlight | 1 + .../ABI/stable/sysfs-class-infiniband | 93 +-- Documentation/ABI/stable/sysfs-class-rfkill | 13 ++- Documentation/ABI/stable/sysfs-class-tpm | 90 +- Documentation/ABI/stable/sysfs-devices| 5 +- Documentation/ABI/stable/sysfs-driver-ib_srp | 1 + .../ABI/stable/sysfs-firmware-efi-vars| 4 + .../ABI/stable/sysfs-firmware-opal-dump | 5 + .../ABI/stable/sysfs-firmware-opal-elog | 2 + Documentation/ABI/stable/sysfs-hypervisor-xen | 3 + Documentation/ABI/stable/vdso | 5 +- 16 files changed, 176 insertions(+), 100 deletions(-)
Re: [patch V2 00/18] mm/highmem: Preemptible variant of kmap_atomic & friends
On Fri, Oct 30 2020 at 08:25, Christoph Hellwig wrote: > On Thu, Oct 29, 2020 at 11:18:06PM +0100, Thomas Gleixner wrote: >> - Consolidating all kmap atomic implementations in generic code > > I think the consolidation is a winner no matter where we go next. Maybe > split it out in a prep series so we can get it in ASAP? Yes, patch 2-15 can just go without any dependency. The only thing which needs a bit of thought is naming. See the other reply to Linus. Thanks, tglx
Re: [patch V2 00/18] mm/highmem: Preemptible variant of kmap_atomic & friends
On Fri, Oct 30 2020 at 00:41, Thomas Gleixner wrote: > On Thu, Oct 29 2020 at 16:11, Linus Torvalds wrote: > No, you're not misreading it, but doing it conditionally would be a > complete semantical disaster. kmap_atomic*() also disables preemption > and pagefaults unconditionaly. If that wouldn't be the case then every > caller would have to have conditionals like 'if (CONFIG_HIGHMEM)' or > worse 'if (PageHighMem(page)'. > > Let's not go there. > > Migrate disable is a less horrible plague than preempt and pagefault > disable even if the scheduler people disagree due to the lack of theory > backing that up :) > > The charm of the new interface is that users still can rely on per > cpuness independent of being on a highmem plagued system. For non > highmem systems the extra migrate disable/enable is really a minor > nuissance. thinking about it some more after having sleep and coffee, we actually could hide the migrate disable in the actual highmem part. But then we really should not name it kmap_local. 'local' suggests locality, think local_irq*, local_bh* ... kmap_task would be more accurate then. Toughts? tglx
Re: [PATCH] powerpc/32s: Setup the early hash table at all time.
On Okt 30 2020, Michael Ellerman wrote: > Andreas Schwab writes: >> On Okt 01 2020, Christophe Leroy wrote: >> >>> At the time being, an early hash table is set up when >>> CONFIG_KASAN is selected. >>> >>> There is nothing wrong with setting such an early hash table >>> all the time, even if it is not used. This is a statically >>> allocated 256 kB table which lies in the init data section. >>> >>> This makes the code simpler and may in the future allow to >>> setup early IO mappings with fixmap instead of hard coding BATs. >>> >>> Put create_hpte() and flush_hash_pages() in the .ref.text section >>> in order to avoid warning for the reference to early_hash[]. This >>> reference is removed by MMU_init_hw_patch() before init memory is >>> freed. >> >> This breaks booting on the iBook G4. > > Do you get an oops or anything? Nope, nothing at all. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
[PATCH v2 19/39] docs: ABI: stable: make files ReST compatible
Several entries at the stable ABI files won't parse if we pass them directly to the ReST output. Adjust them, in order to allow adding their contents as-is at the stable ABI book. Signed-off-by: Mauro Carvalho Chehab --- Documentation/ABI/stable/firewire-cdev| 4 + Documentation/ABI/stable/sysfs-acpi-pmprofile | 22 +++-- Documentation/ABI/stable/sysfs-bus-firewire | 3 + Documentation/ABI/stable/sysfs-bus-nvmem | 19 ++-- Documentation/ABI/stable/sysfs-bus-usb| 6 +- .../ABI/stable/sysfs-class-backlight | 1 + .../ABI/stable/sysfs-class-infiniband | 93 +-- Documentation/ABI/stable/sysfs-class-rfkill | 13 ++- Documentation/ABI/stable/sysfs-class-tpm | 90 +- Documentation/ABI/stable/sysfs-devices| 5 +- Documentation/ABI/stable/sysfs-driver-ib_srp | 1 + .../ABI/stable/sysfs-firmware-efi-vars| 4 + .../ABI/stable/sysfs-firmware-opal-dump | 5 + .../ABI/stable/sysfs-firmware-opal-elog | 2 + Documentation/ABI/stable/sysfs-hypervisor-xen | 3 + Documentation/ABI/stable/vdso | 5 +- 16 files changed, 176 insertions(+), 100 deletions(-) diff --git a/Documentation/ABI/stable/firewire-cdev b/Documentation/ABI/stable/firewire-cdev index f72ed653878a..c9e8ff026154 100644 --- a/Documentation/ABI/stable/firewire-cdev +++ b/Documentation/ABI/stable/firewire-cdev @@ -14,12 +14,14 @@ Description: Each /dev/fw* is associated with one IEEE 1394 node, which can be remote or local nodes. Operations on a /dev/fw* file have different scope: + - The 1394 node which is associated with the file: - Asynchronous request transmission - Get the Configuration ROM - Query node ID - Query maximum speed of the path between this node and local node + - The 1394 bus (i.e. "card") to which the node is attached to: - Isochronous stream transmission and reception - Asynchronous stream transmission and reception @@ -31,6 +33,7 @@ Description: manager - Query cycle time - Bus reset initiation, bus reset event reception + - All 1394 buses: - Allocation of IEEE 1212 address ranges on the local link layers, reception of inbound requests to such @@ -43,6 +46,7 @@ Description: userland implement different access permission models, some operations are restricted to /dev/fw* files that are associated with a local node: + - Addition of descriptors or directories to the local nodes' Configuration ROM - PHY packet transmission and reception diff --git a/Documentation/ABI/stable/sysfs-acpi-pmprofile b/Documentation/ABI/stable/sysfs-acpi-pmprofile index 964c7a8afb26..fd97d22b677f 100644 --- a/Documentation/ABI/stable/sysfs-acpi-pmprofile +++ b/Documentation/ABI/stable/sysfs-acpi-pmprofile @@ -6,17 +6,21 @@ Description: The ACPI pm_profile sysfs interface exports the platform power management (and performance) requirement expectations as provided by BIOS. The integer value is directly passed as retrieved from the FADT ACPI table. -Values: For possible values see ACPI specification: + +Values:For possible values see ACPI specification: 5.2.9 Fixed ACPI Description Table (FADT) Field: Preferred_PM_Profile Currently these values are defined by spec: - 0 Unspecified - 1 Desktop - 2 Mobile - 3 Workstation - 4 Enterprise Server - 5 SOHO Server - 6 Appliance PC - 7 Performance Server + + == = + 0 Unspecified + 1 Desktop + 2 Mobile + 3 Workstation + 4 Enterprise Server + 5 SOHO Server + 6 Appliance PC + 7 Performance Server >7 Reserved + == = diff --git a/Documentation/ABI/stable/sysfs-bus-firewire b/Documentation/ABI/stable/sysfs-bus-firewire index 41e5a0cd1e3e..9ac9eddb82ef 100644 --- a/Documentation/ABI/stable/sysfs-bus-firewire +++ b/Documentation/ABI/stable/sysfs-bus-firewire @@ -47,6 +47,7 @@ Description: IEEE 1394 node device attribute. Read-only and immutable. Values:1: The sysfs entry represents a local node (a controller card). + 0: The sysfs entry represents a remote node. @@
Re: [patch V2 00/18] mm/highmem: Preemptible variant of kmap_atomic & friends
On Thu, Oct 29, 2020 at 11:18:06PM +0100, Thomas Gleixner wrote: > This is achieved by: ... > > - Consolidating all kmap atomic implementations in generic code ... > Though I wanted to share the current state of affairs before investigating > that further. If there is consensus in going forward with this, I'll have a > deeper look into this issue. I think the consolidation is a winner no matter where we go next. Maybe split it out in a prep series so we can get it in ASAP?
Re: [PATCH 20/33] docs: ABI: testing: make the files compatible with ReST output
Em Thu, 29 Oct 2020 14:49:12 + Jonathan Cameron escreveu: > On Wed, 28 Oct 2020 15:23:18 +0100 > Mauro Carvalho Chehab wrote: > > > From: Mauro Carvalho Chehab > > > > Some files over there won't parse well by Sphinx. > > > > Fix them. > > > > Signed-off-by: Mauro Carvalho Chehab > > Signed-off-by: Mauro Carvalho Chehab > > Query below... I'm going to guess a rebase issue? Yes. I sent this series about 1,5 years ago. On that time, it ended by not being merged, as there were too much docs patches floating around. The second SoB is not there on my tree. It was added by git send-email ;-) Anyway, fixed. Thanks, Mauro
Re: [PATCH 30/33] docs: ABI: cleanup several ABI documents
Mauro Carvalho Chehab writes: > There are some ABI documents that, while they don't generate > any warnings, they have issues when parsed by get_abi.pl script > on its output result. > > Address them, in order to provide a clean output. > > Signed-off-by: Mauro Carvalho Chehab > diff --git a/Documentation/ABI/testing/sysfs-bus-papr-pmem > b/Documentation/ABI/testing/sysfs-bus-papr-pmem > index c1a67275c43f..8316c33862a0 100644 > --- a/Documentation/ABI/testing/sysfs-bus-papr-pmem > +++ b/Documentation/ABI/testing/sysfs-bus-papr-pmem > @@ -11,19 +11,26 @@ Description: > at 'Documentation/powerpc/papr_hcalls.rst' . Below are > the flags reported in this sysfs file: > > - * "not_armed" : Indicates that NVDIMM contents will not > + * "not_armed" > + Indicates that NVDIMM contents will not > survive a power cycle. > - * "flush_fail" : Indicates that NVDIMM contents > + * "flush_fail" > + Indicates that NVDIMM contents > couldn't be flushed during last > shut-down event. > - * "restore_fail": Indicates that NVDIMM contents > + * "restore_fail" > + Indicates that NVDIMM contents > couldn't be restored during NVDIMM > initialization. > - * "encrypted" : NVDIMM contents are encrypted. > - * "smart_notify": There is health event for the NVDIMM. > - * "scrubbed": Indicating that contents of the > + * "encrypted" > + NVDIMM contents are encrypted. > + * "smart_notify" > + There is health event for the NVDIMM. > + * "scrubbed" > + Indicating that contents of the > NVDIMM have been scrubbed. > - * "locked" : Indicating that NVDIMM contents cant > + * "locked" > + Indicating that NVDIMM contents cant > be modified until next power cycle. > > What:/sys/bus/nd/devices/nmemX/papr/perf_stats > @@ -51,4 +58,4 @@ Description: > * "MedWDur " : Media Write Duration > * "CchRHCnt" : Cache Read Hit Count > * "CchWHCnt" : Cache Write Hit Count > - * "FastWCnt" : Fast Write Count > \ No newline at end of file > + * "FastWCnt" : Fast Write Count Thanks, I am fine with proposed changes to sysfs-bus-papr-pmem. Acked-by: Vaibhav Jain # for sysfs-bus-papr-pmem
Re: [PATCH] crypto: talitos - Fix return type of current_desc_hdr()
On Thu, Oct 08, 2020 at 09:34:56AM +, Christophe Leroy wrote:
> current_desc_hdr() returns a u32 but in fact this is a __be32,
> leading to a lot of sparse warnings.
>
> Change the return type to __be32 and ensure it is handled as
> sure by the caller.
>
> Fixes: 3e721aeb3df3 ("crypto: talitos - handle descriptor not found in error
> path")
> Signed-off-by: Christophe Leroy
> ---
> drivers/crypto/talitos.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: talitos - Endianess in current_desc_hdr()
On Thu, Oct 08, 2020 at 09:34:55AM +, Christophe Leroy wrote:
> current_desc_hdr() compares the value of the current descriptor
> with the next_desc member of the talitos_desc struct.
>
> While the current descriptor is obtained from in_be32() which
> return CPU ordered bytes, next_desc member is in big endian order.
>
> Convert the current descriptor into big endian before comparing it
> with next_desc.
>
> This fixes a sparse warning.
>
> Fixes: 37b5e8897eb5 ("crypto: talitos - chain in buffered data for ahash on
> SEC1")
> Signed-off-by: Christophe Leroy
> ---
> drivers/crypto/talitos.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
