From: Jonas Oberhauser
> Sent: 07 October 2024 12:55
>
> Am 10/3/2024 um 3:23 PM schrieb Mathieu Desnoyers:
> > What _does_ work however are the following two approaches:
> >
> > 1) Perform the equality check on the original variables, creating
> > new versions (with OPTIMIZER_HIDE_VAR) of both va
From: Mathieu Desnoyers
> Sent: 04 October 2024 19:28
>
> Refer to ptr_eq() in the rcu_dereference() documentation.
>
> ptr_eq() is a mechanism that preserves address dependencies when
> comparing pointers, and should be favored when comparing a pointer
> obtained from rcu_dereference() against a
...
> What _does_ work however are the following two approaches:
>
> 1) Perform the equality check on the original variables, creating
> new versions (with OPTIMIZER_HIDE_VAR) of both variables for the
> rest of their use, therefore making sure the pointer dereference
> are not derived from versio
From: 'Alan Stern'
> Sent: 02 October 2024 15:15
>
> On Wed, Oct 02, 2024 at 08:13:15AM +, David Laight wrote:
> > From: 'Alan Stern'
> > > Sent: 01 October 2024 23:57
> > >
> > > On Tue, Oct 01, 2024 at 05:11:05PM +, D
From: 'Alan Stern'
> Sent: 01 October 2024 23:57
>
> On Tue, Oct 01, 2024 at 05:11:05PM +, David Laight wrote:
> > From: Alan Stern
> > > Sent: 30 September 2024 19:53
> > >
> > > On Mon, Sep 30, 2024 at 07:05:06PM +0200, Jonas Oberhauser wr
From: Alan Stern
> Sent: 30 September 2024 19:53
>
> On Mon, Sep 30, 2024 at 07:05:06PM +0200, Jonas Oberhauser wrote:
> >
> >
> > Am 9/30/2024 um 6:43 PM schrieb Alan Stern:
> > > On Mon, Sep 30, 2024 at 01:26:53PM +0200, Jonas Oberhauser wrote:
> > > >
> > > >
> > > > Am 9/28/2024 um 4:49 PM sch
...
> The checksums for the randomly-generated test cases were calculated
> using a reference implementation [1] and this test compares them against
> the values yielded by the kernel's implementation.
I'd just use a naïve implementation - doesn't really matter
if it is a bit slow.
Slow is relati
From: Vinicius Peixoto
> Sent: 23 September 2024 00:27
>
> Hi all,
>
> This patch was developed during a hackathon organized by LKCAMP [1],
> with the objective of writing KUnit tests, both to introduce people to
> the kernel development process and to learn about different subsystems
> (with the
From: Jakub Sitnicki
> Sent: 23 September 2024 15:56
>
> On Mon, Sep 23, 2024 at 01:08 PM GMT, David Laight wrote:
> > From: Tiago Lam
>
> [...]
>
> >> To limit its usage, a reverse socket lookup is performed to check if the
> >> configured egress s
From: Tiago Lam
> Sent: 20 September 2024 18:02
>
> This follows the same rationale provided for the ipv4 counterpart, where
> the sendmsg() path is also extended here to support the IPV6_ORIGDSTADDR
> ancillary message to be able to specify a source address/port. This
> allows users to configure
From: Peter Zijlstra
> Sent: 03 September 2024 08:57
>
> On Mon, Sep 02, 2024 at 08:59:48PM -0700, Josh Poimboeuf wrote:
> > Add an underscore between the "name" and the counter so tooling can
> > distinguish between the non-unique and unique portions of the symbol
> > name.
> >
> > This will come
From: Nicholas Piggin
> Sent: 15 July 2024 09:25
>
> On Sun Jul 14, 2024 at 6:27 PM AEST, Naveen N Rao wrote:
> > Function profile sequence on powerpc includes two instructions at the
> > beginning of each function:
> > mflrr0
> > bl ftrace_caller
> >
> > The call to ftrace_caller
From: Waiman Long
> Sent: 03 May 2024 23:14
>
>
> On 5/3/24 17:10, David Laight wrote:
> > From: Waiman Long
> >> Sent: 03 May 2024 17:00
> > ...
> >> David,
> >>
> >> Could you respin the series based on the latest upstream code?
From: Waiman Long
> Sent: 03 May 2024 17:00
...
> David,
>
> Could you respin the series based on the latest upstream code?
I've just reapplied the patches to 'master' and they all apply
cleanly and diffing the new patches to the old ones gives no differences.
So I think they should still apply.
From: Waiman Long
> Sent: 03 May 2024 17:00
> To: David Laight ; 'linux-kernel@vger.kernel.org'
> ker...@vger.kernel.org>; 'pet...@infradead.org'
> Cc: 'mi...@redhat.com' ; 'w...@kernel.org'
> ; 'boqun.f...@gmail.com'
>
From: Boqun Feng
> Sent: 02 January 2024 18:54
>
> On Sat, Dec 30, 2023 at 03:49:52PM +0000, David Laight wrote:
> [...]
> > But it looks odd that osq_unlock()'s fast path uses _release but the very
> > similar code in osq_wait_next() uses _acquire.
> >
>
&g
From: Ingo Molnar
> Sent: 02 January 2024 09:54
>
>
> * David Laight wrote:
>
> > per_cpu_ptr() indexes __per_cpu_offset[] with the cpu number.
> > This requires the cpu number be 64bit.
> > However the value is osq_lock() comes from a 32bit xchg() and there
&
From: Waiman Long
> Sent: 01 January 2024 04:14
...
> You really like micro-optimization.
They all add up :-)
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
t gcc knows the decrement has set the high bits to zero and doesn't
add a register-register move (or cltq) to zero/sign extend the value.
Not massive but saves two instructions.
Signed-off-by: David Laight
---
kernel/locking/osq_lock.c | 6 ++
1 file changed, 2 insertions(+), 4 deletion
condition that can leave it
non-NULL check with WARN_ON_ONCE() and NULL if set.
Note that without this check the fast path (adding at the list head)
doesn't need to to access the per-cpu osq_node at all.
Signed-off-by: David Laight
---
kernel/locking/osq_lock.c | 14 ++
1 file ch
sed for the
osq_wait_next() call in the unqueue path.
Normally this is exactly the value that the initial xchg() read
from lock->tail (used to obtain 'prev'), but can get updated
by concurrent unqueues.
Both the 'prev' and 'cpu' members of optimistic_spin_nod
cpu.
Instead save 'prev->cpu' in 'node->prev_cpu' and use that value instead.
Update in the osq_lock() 'unqueue' path when 'node->prev' is changed.
This is simpler than checking for 'node->prev' changing and caching
&#x
Since node->locked cannot be set before the assignment to prev->next
it is save to clear it in the slow path.
Signed-off-by: David Laight
---
kernel/locking/osq_lock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/locking/osq_lock.c b/kernel/locking/osq_lock.c
us got annoyed with it, and I'd spotted it as well.
I don't seem to be able to get gcc to convert __per_cpu_offset[cpu - 1]
to (__per_cpu_offset - 1)[cpu] (cpu is offset by one) but, in any case,
it would still need zero extending in the common case.
David Laight (5):
1) Defer clearing
From: Linus Torvalds
> Sent: 30 December 2023 20:59
>
> On Sat, 30 Dec 2023 at 12:41, Linus Torvalds
> wrote:
> >
> > UNTESTED patch to just do the "this_cpu_write()" parts attached.
> > Again, note how we do end up doing that this_cpu_ptr conversion later
> > anyway, but at least it's off the cr
From: Linus Torvalds
> Sent: 30 December 2023 20:41
>
> On Fri, 29 Dec 2023 at 12:57, David Laight wrote:
> >
> > this_cpu_ptr() is rather more expensive than raw_cpu_read() since
> > the latter can use an 'offset from register' (%gs for x86-84).
From: Waiman Long
> Sent: 31 December 2023 03:04
> The presence of debug_smp_processor_id in your compiled code is likely
> due to the setting of CONFIG_DEBUG_PREEMPT in your kernel config.
>
> #ifdef CONFIG_DEBUG_PREEMPT
> extern unsigned int debug_smp_processor_id(void);
> # define smp_p
From: Ingo Molnar
> Sent: 30 December 2023 20:38
>
> * David Laight wrote:
>
> > bool osq_lock(struct optimistic_spin_queue *lock)
> > {
> > - struct optimistic_spin_node *node = this_cpu_ptr(&osq_node);
> > + struct optimistic_spin_node *node = raw
From: Linus Torvalds
> Sent: 30 December 2023 19:41
>
> On Fri, 29 Dec 2023 at 12:52, David Laight wrote:
> >
> > David Laight (5):
> > Move the definition of optimistic_spin_node into osf_lock.c
> > Clarify osq_wait_next()
>
> I took these two as pre
From: Waiman Long
> Sent: 30 December 2023 15:57
>
> On 12/29/23 22:13, Waiman Long wrote:
> >
> > On 12/29/23 15:58, David Laight wrote:
> >> The vcpu_is_preempted() test stops osq_lock() spinning if a virtual
> >> cpu is no longer running.
> >&
From: Waiman Long
> Sent: 30 December 2023 03:20
>
> On 12/29/23 17:11, David Laight wrote:
> > osq_lock() starts by setting node->next to NULL and node->locked to 0.
> > Careful analysis shows that node->next is always NULL on entry.
> >
> > node->loc
From: Ingo Molnar
> Sent: 30 December 2023 11:09
>
>
> * Waiman Long wrote:
>
> > On 12/29/23 15:57, David Laight wrote:
> > > this_cpu_ptr() is rather more expensive than raw_cpu_read() since
> > > the latter can use an 'offset from register'
d can be set to zero just before that (along with the assignment
to node->prev).
Only initialise node->cpu once, after that use its value instead
of smp_processor_id() - which is probably a real function call.
Should reduce cache-line bouncing a little.
Signed-off-by: David Laight
---
R
d can be set to zero just before that (along with the assignment
to node->prev).
Only initialise node->cpu once, after that use its value instead
of smp_processor_id() - which is probably a real function call.
Should reduce cache-line bouncing a little.
Signed-off-by: David Laight
---
struct optimistic_spin_node is private to the implementation.
Move it into the C file to ensure nothing is accessing it.
Signed-off-by: David Laight
---
include/linux/osq_lock.h | 5 -
kernel/locking/osq_lock.c | 7 +++
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a
ions, so the fields
are initialised on the first osq_lock() call.
The last patch avoids the cache line reload calling vcpu_is_preempted()
by simply saving node->prev->cpu as node->prev_cpu and updating it when
node->prev changes.
This is simpler than the patch proposed by Waimon.
David L
cpu.
Instead save 'prev->cpu' in 'node->prev_cpu' and use that value instead.
Update in the osq_lock() 'unqueue' path when 'node->prev' is changed.
This is simpler than checking for 'node->prev' changing and caching
&#x
o effect on the generated code since gcc manages to
assume that 'prev != NULL' due to an earlier dereference.
Signed-off-by: David Laight
---
kernel/locking/osq_lock.c | 23 ++-
1 file changed, 10 insertions(+), 13 deletions(-)
diff --git a/kernel/locking/osq_lock.c
this_cpu_ptr() is rather more expensive than raw_cpu_read() since
the latter can use an 'offset from register' (%gs for x86-84).
Add a 'self' field to 'struct optimistic_spin_node' that can be
read with raw_cpu_read(), initialise on first call.
Signed-off-by: Dav
...
> diff --git a/include/linux/init.h b/include/linux/init.h
> index 3fa3f6241350..650311e4b215 100644
> --- a/include/linux/init.h
> +++ b/include/linux/init.h
> @@ -264,6 +264,7 @@ extern struct module __this_module;
> #define define_initcall(fn, __stub, __name, __sec) \
>
> I think 1kb units is perfectly fine (patch 15 changes to kb units). The
> interface says its to define the minimal size of the sub-buffer, not the
> actual size.
I didn't read that far through :-(
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
U
From: Steven Rostedt
> Sent: 20 December 2023 13:01
>
> On Wed, 20 Dec 2023 08:48:02 +0000
> David Laight wrote:
>
> > From: Steven Rostedt
> > > Sent: 19 December 2023 18:54
> > > From: "Tzvetomir Stoyanov (VMware)"
> > >
> &g
From: Steven Rostedt
> Sent: 19 December 2023 18:54
> From: "Tzvetomir Stoyanov (VMware)"
>
> Currently the size of one sub buffer page is global for all buffers and
> it is hard coded to one system page. In order to introduce configurable
> ring buffer sub page size, the internal logic should be
...
> My guess is that *most* 32-bit architectures do not have a 64-bit
> cmpxchg - not even the irq-safe one.
Does any sparc32 even have a 32-bit cmpxchg?
The original versions (which were definitely SMP capable)
only had a byte sized atomic exchange that always wrote 0xff.
Sparc32 does have 'lo
From: Clément Léger
> Sent: 14 September 2023 14:11
>
> enabler->uaddr can be aligned on 32 or 64 bits. If aligned on 32 bits,
> this will result in a misaligned access on 64 bits architectures since
> set_bit()/clear_bit() are expecting an unsigned long (aligned) pointer.
> On architecture that d
...
> Okay, can you please split the patch so they can be backported
> separately? Then I'll get them landed, etc.
Since the header with just the extra #endif is badly broken on C++
isn't it best to ensure they get back-ported together?
So one patch is probably better.
David
-
Registered
From: Dan Carpenter
> Sent: 20 April 2021 11:28
>
> On Sat, Apr 17, 2021 at 09:31:32PM +0000, David Laight wrote:
> > From: Mauro Carvalho Chehab
> > > Sent: 17 April 2021 19:56
> > >
> > > Em Sat, 17 Apr 2021 21:06:27 +0530
> > > Ashish
From: Geert Uytterhoeven
> Sent: 20 April 2021 08:40
>
> Hi Willy,
>
> On Sat, Apr 17, 2021 at 4:49 AM Matthew Wilcox wrote:
> > Replacement patch to fix compiler warning.
> >
> > 32-bit architectures which expect 8-byte alignment for 8-byte integers
> > and need 64-bit DMA addresses (arc, arm,
From: H. Peter Anvin
> Sent: 20 April 2021 00:03
>
> When compiling on a different machine than the runtime target,
> including but not limited to simulators, it is rather handy to be able
> to produce a bootable image. The scripts for that in x86 are
> relatively old, and assume a BIOS system.
I
From: Rasmus Villemoes
> Sent: 19 April 2021 09:40
>
> On 17/04/2021 00.28, Kees Cook wrote:
> > On Fri, Apr 16, 2021 at 03:06:17PM -0700, Andy Lutomirski wrote:
>
> >> The
> >> foo symbol would point to whatever magic is needed.
> >
> > No, the symbol points to the jump table entry. Direct calls
From: Andy Lutomirski
> Sent: 18 April 2021 01:12
..
> Slightly more complicated:
>
> struct opaque_symbol;
> extern struct opaque_symbol entry_SYSCALL_64;
>
> The opaque_symbol variant avoids any possible confusion over the weird
> status of arrays in C, and it's hard to misuse, since struct
> o
From: wangyanan (Y)
> Sent: 19 April 2021 07:40
>
> Hi Paolo,
>
> On 2021/4/17 21:23, Paolo Bonzini wrote:
> > On 30/03/21 10:08, Yanan Wang wrote:
> >> In addition to function of CLOCK_MONOTONIC, flag CLOCK_MONOTONIC_RAW can
> >> also shield possiable impact of NTP, which can provide more robust
From: Mauro Carvalho Chehab
> Sent: 17 April 2021 19:56
>
> Em Sat, 17 Apr 2021 21:06:27 +0530
> Ashish Kalra escreveu:
>
> > Upon running sparse, "warning: dubious: !x | !y" is brought to notice
> > for this file. Logical and bitwise OR are basically the same in this
> > context so it doesn't
From: Matthew Wilcox
> Sent: 17 April 2021 03:45
>
> Replacement patch to fix compiler warning.
...
> static inline dma_addr_t page_pool_get_dma_addr(struct page *page)
> {
> - return page->dma_addr;
> + dma_addr_t ret = page->dma_addr[0];
> + if (sizeof(dma_addr_t) > sizeof(unsigne
From: Matthew Wilcox (Oracle)
> Sent: 17 April 2021 00:07
>
> The net page_pool wants to use a magic value to identify page pool pages.
> The best place to put it is in the first word where it can be clearly a
> non-pointer value. That means shifting dma_addr up to alias with ->index,
> which me
From: Kees Cook
> Sent: 16 April 2021 23:28
>
> On Fri, Apr 16, 2021 at 03:06:17PM -0700, Andy Lutomirski wrote:
> > On Fri, Apr 16, 2021 at 3:03 PM Borislav Petkov wrote:
> > >
> > > On Fri, Apr 16, 2021 at 02:49:23PM -0700, Sami Tolvanen wrote:
> > > > __nocfi only disables CFI checking in a fu
From: Al Viro On Behalf Of Al Viro
> Sent: 16 April 2021 20:44
> On Fri, Apr 16, 2021 at 12:24:13PM -0700, Eric Dumazet wrote:
> > From: Eric Dumazet
> >
> > We have to loop only to copy u64 values.
> > After this first loop, we copy at most one u32, one u16 and one byte.
>
> Does it actually yi
From: Peter Zijlstra
> Sent: 17 April 2021 12:17
...
> > (i'd argue this is C being broken; promoting only as far as int, when
> > assigning to an unsigned long is Bad, but until/unless either GCC fixes
> > that or the language committee realises that being stuck in the 1970s
> > is Bad, people are
From: Mark Rutland
> Sent: 16 April 2021 14:35
..
> @@ -51,13 +48,7 @@ static inline void syscall_set_return_value(struct
> task_struct *task,
> struct pt_regs *regs,
> int error, long val)
> {
> - if (error)
From: Grygorii Strashko
> Sent: 16 April 2021 10:27
...
> Sry, for delayed reply.
>
> The TI platforms am3/4/5 (cpsw) and Keystone 2 (netcp) can do only 32bit DMA
> even in case of LPAE
> (dma-ranges are used).
> Originally, as I remember, CONFIG_ARCH_DMA_ADDR_T_64BIT has not been selected
> for
..
> The more you make it look like (Kernel) C, the easier it is for us C
> people to actually read. My eyes have been reading C for almost 30 years
> by now, they have a lexer built in the optical nerve; reading something
> that looks vaguely like C but is definitely not C is an utterly painful
>
From: Peter Zijlstra
> Sent: 16 April 2021 15:19
>
> On Fri, Apr 16, 2021 at 02:07:49PM +0100, Wedson Almeida Filho wrote:
> > On Fri, Apr 16, 2021 at 01:24:23PM +0200, Peter Zijlstra wrote:
>
> > > int perf_event_task_enable(void)
> > > {
> > > + DEFINE_MUTEX_GUARD(event_mutex, ¤t->perf_event_
From: Maciej W. Rozycki
> Sent: 16 April 2021 11:49
>
> On Thu, 15 Apr 2021, Joe Perches wrote:
>
> > In patch 2, vscnprintf should probably be used to make sure it's
> > 0 terminated.
>
> Why? C99 has this[1]:
>
> "The vsnprintf function is equivalent to snprintf, with the variable
> argumen
From: Matteo Croce
> Sent: 16 April 2021 23:44
...
> > A more interesting change would be something that generated:
> > unsigned int nr_frags = skb_shinfo(skb)->nr_frags;
> > for (i = 0; i < nr_frags; i++) {
> > since that will run faster for most loops.
> > But that is ~impossible
From: Matthew Wilcox
> Sent: 16 April 2021 16:28
>
> On Thu, Apr 15, 2021 at 08:08:32PM +0200, Jesper Dangaard Brouer wrote:
> > See below patch. Where I swap32 the dma address to satisfy
> > page->compound having bit zero cleared. (It is the simplest fix I could
> > come up with).
>
> I think t
From: Matthew Wilcox
> Sent: 15 April 2021 23:22
>
> On Thu, Apr 15, 2021 at 09:11:56PM +0000, David Laight wrote:
> > Isn't it possible to move the field down one long?
> > This might require an explicit zero - but this is not a common
> > code path - the extra w
From: Matthew Wilcox
> Sent: 15 April 2021 19:22
>
> On Thu, Apr 15, 2021 at 08:08:32PM +0200, Jesper Dangaard Brouer wrote:
> > +static inline
> > +dma_addr_t page_pool_dma_addr_read(dma_addr_t dma_addr)
> > +{
> > + /* Workaround for storing 64-bit DMA-addr on 32-bit machines in struct
> > +
From: Niklas Schnelle
> Sent: 15 April 2021 13:37
>
> Instead of relying on the fallback in asm-generic/io.h which sets
> PCI_IOBASE 0 if it is not defined set it explicitly.
>
> Link:
> https://lore.kernel.org/lkml/CAK8P3a3PK9zyeP4ymELtc2ZYnymECoACiigw9Za+pvSJpCk5=g...@mail.gmail.com/
> Signed-
...
> Besides just FP, 128-bit, etc, I remain concerned about just basic
> math operations. C has no way to describe the intent of integer
> overflow, so the kernel was left with the only "predictable" result:
> wrap around. Unfortunately, this is wrong in most cases, and we're left
> with entire c
From: Linus Torvalds
> Sent: 14 April 2021 21:22
>
> On Wed, Apr 14, 2021 at 1:10 PM Matthew Wilcox wrote:
> >
> > There's a philosophical point to be discussed here which you're skating
> > right over! Should rust-in-the-linux-kernel provide the same memory
> > allocation APIs as the rust-stand
From: Matthew Wilcox
> Sent: 14 April 2021 22:36
>
> On Wed, Apr 14, 2021 at 09:13:22PM +0200, Jesper Dangaard Brouer wrote:
> > (If others want to reproduce). First I could not reproduce on ARM32.
> > Then I found out that enabling CONFIG_XEN on ARCH=arm was needed to
> > cause the issue by enab
From: Oleg Nesterov
> Sent: 14 April 2021 17:56
>
> On 04/14, David Laight wrote:
> >
> > From: Oleg Nesterov
> > > Sent: 14 April 2021 16:08
> > >
> > > Add audit maintainers...
> > >
> > > On 04/14, He Zhe wrote:
> > > &
From: Oleg Nesterov
> Sent: 14 April 2021 16:08
>
> Add audit maintainers...
>
> On 04/14, He Zhe wrote:
> >
> > When 32-bit userspace application is running on 64-bit kernel, the 32-bit
> > syscall return code would be changed from u32 to u64 in regs_return_value
> > and then changed to s64. Hen
From: Eric Dumazet
> Sent: 14 April 2021 17:00
...
> > Repeated unsafe_get_user() calls are crying out for an optimisation.
> > You get something like:
> > failed = 0;
> > copy();
> > if (failed) goto error;
> > copy();
> > if (failed) goto error;
> > Where '
From: Peter Zijlstra
> Sent: 14 April 2021 13:56
>
> > I've tested it on csky SMP*4 hw (860) & riscv SMP*4 hw (c910) and it's okay.
>
> W00t :-)
>
> > Hope you can keep
> > typedef struct {
> > union {
> > atomic_t lock;
> > struct __raw_tickets {
> > #ifd
> Doing this fixes it:
>
> +++ b/include/linux/types.h
> @@ -140,7 +140,7 @@ typedef u64 blkcnt_t;
> * so they don't care about the size of the actual bus addresses.
> */
> #ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
> -typedef u64 dma_addr_t;
> +typedef u64 __attribute__((aligned(sizeof(void * d
From: He Zhe
> Sent: 14 April 2021 09:02
>
> When 32-bit userspace application is running on 64-bit kernel, the 32-bit
> syscall return code would be changed from u32 to u64 in regs_return_value
> and then changed to s64. Hence the negative return code recorded by audit
> would end up being a big
From: Segher Boessenkool
> Sent: 14 April 2021 16:19
...
> > Could the kernel use GCC builtin atomic functions instead ?
> >
> > https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html
>
> Certainly that should work fine for the simpler cases that the atomic
> operations are meant to pro
From: Tom Talpey
> Sent: 14 April 2021 15:16
>
> On 4/12/2021 6:48 PM, Jason Gunthorpe wrote:
> > On Mon, Apr 12, 2021 at 04:20:47PM -0400, Tom Talpey wrote:
> >
> >> So the issue is only in testing all the providers and platforms,
> >> to be sure this new behavior isn't tickling anything that wen
From: Niklas Schnelle
> Sent: 14 April 2021 13:35
>
> On Tue, 2021-04-13 at 14:12 +0000, David Laight wrote:
> > From: Arnd Bergmann
> > > Sent: 13 April 2021 14:40
> > >
> > > On Tue, Apr 13, 2021 at 3:06 PM David Laight
> > > wrote:
> >
From: Arjun Roy
> Sent: 13 April 2021 23:04
>
> On Tue, Apr 13, 2021 at 2:19 PM David Laight wrote:
> >
> > > If we're special-casing 64-bit architectures anyways - unrolling the
> > > 32B copy_from_user() for struct rseq_cs appears to be roughly 5-10%
>
> If we're special-casing 64-bit architectures anyways - unrolling the
> 32B copy_from_user() for struct rseq_cs appears to be roughly 5-10%
> savings on x86-64 when I measured it (well, in a microbenchmark, not
> in rseq_get_rseq_cs() directly). Perhaps that could be an additional
> avenue for imp
From: Thomas Bogendoerfer
> Sent: 13 April 2021 16:19
>
> On Tue, Apr 13, 2021 at 12:37:25PM +0000, David Laight wrote:
> > From: Thomas Bogendoerfer
> > > Sent: 13 April 2021 12:15
> > ...
> > > > The __access_ok() is noted with `Ensure that the ran
From: Mathieu Desnoyers
> Sent: 13 April 2021 15:22
...
> > David
> >
> >> So I suppose that if we're going to #ifdef this, we might as well do the
> >> whole thing.
> >>
> >> Mathieu; did I forget a reason why this cannot work?
>
> The only difference it brings on 32-bit is that the truncati
From: Arnd Bergmann
> Sent: 13 April 2021 14:40
>
> On Tue, Apr 13, 2021 at 3:06 PM David Laight wrote:
> >
> > From: Arnd Bergmann
> > > Sent: 13 April 2021 13:58
> > ...
> > > The remaining ones (csky, m68k, sparc32) need to be inspected
> >
From: Arnd Bergmann
> Sent: 13 April 2021 13:58
...
> The remaining ones (csky, m68k, sparc32) need to be inspected
> manually to see if they currently support PCI I/O space but in
> fact use address zero as the base (with large resources) or they
> should also turn the operations into a NOP.
I'd
From: Arnd Bergmann
> Sent: 13 April 2021 13:27
>
> On Tue, Apr 13, 2021 at 1:54 PM Niklas Schnelle
> wrote:
> >
> > When PCI_IOBASE is not defined, it is set to 0 such that it is ignored
> > in calls to the readX/writeX primitives. While mathematically obvious
> > this triggers clang's -Wnull-p
From: Thomas Bogendoerfer
> Sent: 13 April 2021 12:15
...
> > The __access_ok() is noted with `Ensure that the range [addr, addr+size)
> > is within the process's address space`. Does the range checked by
> > __access_ok() on MIPS is [addr, addr+size]. So if we want to use
> > access_ok(s, 1), sho
From: Catalin Marinas
> Sent: 13 April 2021 11:45
...
> This indeed needs some care. IIUC RISC-V has similar restrictions as arm
> here, no load/store instructions are allowed between LR and SC. You
> can't guarantee that the compiler won't spill some variable onto the
> stack.
You can probably ne
From: Peter Zijlstra
> Sent: 13 April 2021 10:10
>
> On Tue, Apr 13, 2021 at 12:36:57AM -0700, Eric Dumazet wrote:
> > From: Eric Dumazet
> >
> > Commit ec9c82e03a74 ("rseq: uapi: Declare rseq_cs field as union,
> > update includes") added regressions for our servers.
> >
> > Using copy_from_user
From: sakari.ai...@linux.intel.com
> Sent: 13 April 2021 10:56
>
> Hi David,
>
> On Tue, Apr 13, 2021 at 07:40:12AM +0000, David Laight wrote:
> > From: Mitali Borkar
> > > Sent: 12 April 2021 00:09
> > >
> > > This patch fixes the
From: Chris von Recklinghausen
> Sent: 12 April 2021 20:51
...
> > This is not about BIOS bugs. Hibernation is deep suspend/resume
> > grafted onto cold boot, and it is perfectly legal for the firmware to
> > present a different memory map to the OS after a cold boot. It is
> > Linux that decides t
From: Jinyang He
> Sent: 13 April 2021 02:16
>
> > On Mon, Apr 12, 2021 at 11:02:19AM +0800, Tiezhu Yang wrote:
> >> On 04/11/2021 07:04 PM, Jinyang He wrote:
> >>> Commit 04324f44cb69 ("MIPS: Remove get_fs/set_fs") brought a problem for
> >>> strnlen_user(). Jump out when checking access_ok() wit
From: Matthew Wilcox
> Sent: 12 April 2021 19:24
>
> On Sun, Apr 11, 2021 at 11:43:07AM +0200, Jesper Dangaard Brouer wrote:
> > Could you explain your intent here?
> > I worry about @index.
> >
> > As I mentioned in other thread[1] netstack use page_is_pfmemalloc()
> > (code copy-pasted below si
From: Matteo Croce
> Sent: 12 April 2021 01:38
>
> Introduce skb_for_each_frag, an helper macro to iterate over the SKB frags.
The real question is why, the change is:
- for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
+ skb_for_each_frag(skb, i) {
The existing code isn't complicat
From: Mitali Borkar
> Sent: 12 April 2021 00:09
>
> This patch fixes the warning identified by checkpatch.pl by replacing
> __attribute__aligned(size) with __aligned(size)
>
> Signed-off-by: Mitali Borkar
> ---
> .../staging/media/ipu3/include/intel-ipu3.h | 74 +--
> 1 file c
From: Arnd Bergmann
> Sent: 12 April 2021 12:26
>
> On Mon, Apr 12, 2021 at 12:54 PM David Laight wrote:
> > From: David Laight > Sent: 12 April 2021 10:37
> > ...
> > > I'm guessing that compat_pid_t is 16 bits?
> > > So the native 32bit version
From: David Laight
> Sent: 12 April 2021 10:37
...
> I'm guessing that compat_pid_t is 16 bits?
> So the native 32bit version has an unnamed 2 byte structure pad.
> The 'packed' removes this pad from the compat structure.
>
> AFAICT (apart from mips) the __ARCH_
From: Arnd Bergmann
> Sent: 12 April 2021 11:04
>
> On Mon, Apr 12, 2021 at 10:55 AM Christoph Hellwig wrote:
> >
> > Hi all,
> >
> > currently we deal with the slight differents in the various architecture
> > variants of the flock and flock64 stuctures in a very cruft way. This
> > series swit
From: Christoph Hellwig
> Sent: 12 April 2021 09:56
>
> Provide a single common definition for the compat_flock and
> compat_flock64 structures using the same tricks as for the native
> variants. An extra define is added for the packing required on x86.
>
...
> /*
> - * IA32 uses 4 byte alignme
1 - 100 of 1011 matches
Mail list logo
