On February 19, 2025 11:04:18 PM PST, Thorsten Blum
wrote:
>On 20. Feb 2025, at 03:57, Kees Cook wrote:
>> On Wed, Feb 19, 2025 at 11:47:31PM +0100, Thorsten Blum wrote:
>>> strncpy() is deprecated for NUL-terminated destination buffers. Use
>>> strscpy_pad() instead and remove the manual NUL-
Hello Jared and Hanno!
On Sat, Feb 08, 2025 at 07:18:22AM -0800, Jared Finder wrote:
> Hi, I'm the original reporter of this regression (noticed because it
> impacted GNU Emacs) and I'm wondering if there's any traction on creating an
> updated patch? This thread appears to have stalled out. I hav
urn err;
---
base-commit: 87a132e73910e8689902aed7f2fc229d6908383b
change-id: 20250220-bpf-uninit-3323a4426da9
Best regards,
On 25/02/20 08:24PM, Pu Lehui wrote:
> On 2025/2/20 13:50, Ethan Carter Edwards wrote:
> > In most code paths variable move_kern_type_id remains uninitialized upon
> > return. By moving it to the goto, it is initialized in these code paths.
> > As well as others. Caught by Coverity.
> >
> > Closes
On 2025-02-20 15:04:43 [+0800], Oliver Sang wrote:
> hi, Sebastian,
Hi Oliver,
+ UBSAN & KASAN + STACK unwind people. The commit question is
e9d25b42bde5a ("x86: Use RCU in all users of __module_address().")
in -next.
> just FYI. we rebuild the kernel, and run the tests more times upon this
On Thu, 20 Feb 2025 at 16:57, Sebastian Andrzej Siewior
wrote:
[...]
> Now. Based on this:
> The RCU read section increased the runtime (on my hardware) for the test
> from 30 to 43 seconds which is roughly 43%.
> This is due to the lockdep annotation within rcu_read_lock() and
> unlock() which is
On 19/02/25 12:25, Dave Hansen wrote:
> On 2/19/25 07:13, Valentin Schneider wrote:
>>> Maybe I missed part of the discussion though. Is VMEMMAP your only
>>> concern? I would have guessed that the more generic vmalloc()
>>> functionality would be harder to pin down.
>> Urgh, that'll teach me to se
On 2/20/25 09:10, Valentin Schneider wrote:
>> The LDT and maybe the PEBS buffers are the only implicit supervisor
>> accesses to vmalloc()'d memory that I can think of. But those are both
>> handled specially and shouldn't ever get zapped while in use. The LDT
>> replacement has its own IPIs separ
On Wed, 2025-02-19 at 23:47 +0100, Thorsten Blum wrote:
> strncpy() is deprecated for NUL-terminated destination buffers. Use
> strscpy_pad() instead and remove the manual NUL-termination.
>
> Compile-tested only.
>
> Link:
> https://urldefense.com/v3/__https://github.com/KSPP/linux/issues/90__;
On Thu, 6 Feb 2025 15:07:07 +1030 Gustavo A. R. Silva wrote:>
> Here is another alternative for this. And similarly to the
> struct_group_tagged()
> change above, no struct members should be added before or after `struct
> mlx5e_umr_wqe_hdr hdr;` in `struct mlx5e_umr_wqe`:
Gustavo, could you su
On Thu, 2025-02-20 at 11:07 -0700, Allison Henderson wrote:
> On Wed, 2025-02-19 at 23:47 +0100, Thorsten Blum wrote:
> > strncpy() is deprecated for NUL-terminated destination buffers. Use
> > strscpy_pad() instead and remove the manual NUL-termination.
> >
> > Compile-tested only.
I went ahead
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski :
On Wed, 19 Feb 2025 16:32:54 +0200 you wrote:
> Remove the hidden assumption that options are allocated at the end of
> the struct, and teach the compiler about them using a flexible array.
>
> First patch is conver
On 20 Feb 10:26, Jakub Kicinski wrote:
On Thu, 6 Feb 2025 15:07:07 +1030 Gustavo A. R. Silva wrote:>
Here is another alternative for this. And similarly to the
struct_group_tagged()
change above, no struct members should be added before or after `struct
mlx5e_umr_wqe_hdr hdr;` in `struct mlx5e
13 matches
Mail list logo