On Tue, Aug 27, 2024 at 10:45:17AM +0800, Hongbo Li wrote:
> The helper str_false_true is introduced to reback "false/true"
> string literal. We can simplify this format by str_false_true.
This seems unnecessarily verbose & complex. How about:
dprintk("%s: link support=%s\n", __func__, s
On Thu, Oct 26, 2023 at 10:54:26AM -0700, Kees Cook wrote:
> > > do_soemthing(seq_buf_cstr(s));
> >
> > Do we really need to call it _cstr? Why not just have seq_buf_str() ?
> >
> > I mean, this is C, do we need to state that in the name too?
>
> I'm fine either way. I did that just to make th
On Fri, Oct 27, 2023 at 06:54:51AM +0200, Christoph Hellwig wrote:
> > Instead, we can just return s->buffer direction after terminating it
> > in refactored seq_buf_terminate(), now known as seq_buf_str():
> >
> > do_soemthing(seq_buf_str(s));
>
> Looks good. Btw, one typical do_something w
On Mon, Jan 15, 2024 at 04:40:36PM +, Sam James wrote:
> m...@horotw.com writes:
> > Hey, I read that ASLR is currently (since kernel >=5.18) broken for
> > 32bit libs and reduced in effectiveness for 64bit libs... (the issue
> > only arises if a lib is over 2MB).
> > I confirmed this for mysel
On Mon, Jan 15, 2024 at 07:21:19PM +0100, m...@horotw.com wrote:
> Am 15.01.2024 17:52, schrieb Matthew Wilcox:
> > On Mon, Jan 15, 2024 at 04:40:36PM +, Sam James wrote:
> > > m...@horotw.com writes:
> > > > Hey, I read that ASLR is currently (since kernel &g
On Wed, Mar 20, 2024 at 11:30:13AM +0800, Jiangfeng Xiao wrote:
> The checkpatch.pl script reports the "WARNING: printk() should
> include KERN_ facility level" warning.
>
> That's why I changed printk to pr_warn.
> I should change printk to printk(KERN_DEFAULT).
No, you should ignore checkpatch.
On Thu, Apr 04, 2024 at 02:12:15PM -0700, Kees Cook wrote:
> Since __counted_by(handle_bytes) was added to struct file_handle, we need
> to explicitly set it in the one place it wasn't yet happening prior to
> accessing the flex array "f_handle". For robustness also check for a
> negative value for
On Thu, Apr 25, 2024 at 04:45:51PM -0400, Kent Overstreet wrote:
> On Thu, Apr 25, 2024 at 01:08:50PM -0700, Kees Cook wrote:
> > The /proc/allocinfo file exposes a tremendous about of information about
> > kernel build details, memory allocations (obviously), and potentially
> > even image layout
On Thu, Apr 25, 2024 at 08:58:34PM -0400, Kent Overstreet wrote:
> On Thu, Apr 25, 2024 at 05:43:33PM -0700, Kees Cook wrote:
> > All this said, I'm still not excited about any of these files living
> > in /proc at all -- we were supposed to use /sys for this kind of thing,
> > but its interface wa
On Fri, May 17, 2024 at 12:29:06AM +, Justin Stitt wrote:
> When running syzkaller with the newly reintroduced signed integer
> overflow sanitizer we encounter this report:
why do you keep saying it's unintentional? it's clearly intended.
On Fri, May 17, 2024 at 02:26:47AM +0100, Al Viro wrote:
> On Fri, May 17, 2024 at 02:13:22AM +0100, Matthew Wilcox wrote:
> > On Fri, May 17, 2024 at 12:29:06AM +, Justin Stitt wrote:
> > > When running syzkaller with the newly reintroduced signed integer
> > > over
On Wed, May 08, 2024 at 11:11:35PM -0700, Kees Cook wrote:
> Or even just simple math between u8s:
>
> while (xas->xa_offset == 255) {
> xas->xa_offset = xas->xa_node->offset - 1;
>
> Is it expecting to wrap (truncate)? How is it distinguished from
> the "num
On Mon, Nov 25, 2024 at 08:20:21PM +, jef...@chromium.org wrote:
> +/*
> + * Kernel cmdline override for CONFIG_SEAL_SYSTEM_MAPPINGS
> + */
> +enum seal_system_mappings_type {
> + SEAL_SYSTEM_MAPPINGS_DISABLED,
> + SEAL_SYSTEM_MAPPINGS_ENABLED
> +};
> +
> +static enum seal_system_mappin
On Sat, Nov 16, 2024 at 09:52:44PM -0800, Kees Cook wrote:
> GCC 15's -Warray-bounds reports:
>
> In function 'page_fixed_fake_head',
> inlined from '_compound_head' at ../include/linux/page-flags.h:251:24,
> inlined from '__dump_page' at ../mm/debug.c:123:11:
> ../include/asm-generic/rwon
On Tue, Dec 03, 2024 at 10:31:59AM +0800, Ze Zuo wrote:
> The commit 0aef499f3172 ("mm/usercopy: Detect vmalloc overruns") introduced
> vmalloc check for usercopy. However, in subsystems like networking, when
> memory allocated using vmalloc or vmap is subsequently copied using
> functions like cop
On Tue, Dec 03, 2024 at 08:02:26PM +0100, Uladzislau Rezki wrote:
I think there are a few other things we can try here.
First, if the copy is small (and I still don't have an answer to that
...), we can skip the vmalloc lookup if the copy doesn't cross a page
boundary.
Second, we could try stori
On Wed, Dec 04, 2024 at 09:51:07AM +0100, Uladzislau Rezki wrote:
> I think, when i have more free cycles, i will check it from performance
> point of view. Because i do not know how much a maple tree is efficient
> when it comes to lookups, insert and removing.
Maple tree has a fanout of around 8
On Mon, Dec 16, 2024 at 02:45:15PM -0800, Kees Cook wrote:
> Since we have already allocated "len + 1" space for event->name, make sure
> that name->name cannot ever accidentally cause a copy overflow by calling
> strscpy() instead of the unbounded strcpy() routine. This assists in
> the ongoing ef
On Sun, Nov 17, 2024 at 08:46:45PM -0800, Kees Cook wrote:
> On Mon, Nov 18, 2024 at 04:10:52AM +0000, Matthew Wilcox wrote:
> > folio_test_large() does not touch page[1]. Look:
>
> It does, though. :( It's via the PageTail(), which calls page_is_fake_head():
Oh.
On Thu, Jan 23, 2025 at 04:50:46PM -0500, enh wrote:
> yeah, at this point i should (a) drag in +cferris who may have actual
> experience of this and (b) admit that iirc i've never personally seen
> _evidence_ of this, just claims. most famously in the chrome source...
> if you `grep -r /proc/.*/ma
On Mon, Jan 27, 2025 at 04:55:58PM +0200, Jani Nikula wrote:
> You could have static const within functions too. You get the rodata
> protection and function local scope, best of both worlds?
timer_active is on the stack, so it can't be static const.
Does this really need to be cc'd to such a wid
On Mon, Jan 13, 2025 at 01:26:59PM -0800, Jeff Xu wrote:
> This patch is intended for ChromeOS and Android and is
> feature-complete from their perspective.
"I have everything I need from the Google point of view, so I will push
this feature into upstream".
No, thanks.
ve it from the seq_buf to the tracing code.
We should go further with this patch series, including using seq_buf
within vsprintf, but if we can't get over this hurdle first, I'm not
going to waste my time on this again.
Matthew Wilcox (Oracle) (1):
trace: Move readpos from seq_b
then.
Signed-off-by: Matthew Wilcox (Oracle)
---
include/linux/seq_buf.h | 5 +
include/linux/trace_seq.h | 2 ++
kernel/trace/trace.c | 10 +-
kernel/trace/trace_seq.c | 6 +-
lib/seq_buf.c | 13 +
5 files changed, 18 insertions(+), 18
then.
Signed-off-by: Matthew Wilcox (Oracle)
---
include/linux/seq_buf.h | 5 +
include/linux/trace_seq.h | 2 ++
kernel/trace/trace.c | 10 +-
kernel/trace/trace_seq.c | 6 +-
lib/seq_buf.c | 13 +
5 files changed, 18 insertions(+), 18
ve it from the seq_buf to the tracing code.
We should go further with this patch series, including using seq_buf
within vsprintf, but if we can't get over this hurdle first, I'm not
going to waste my time on this again.
v2:
- Add linux-trace-ker...@vger.kernel.org
- Fix kernel-doc
then.
Signed-off-by: Matthew Wilcox (Oracle)
---
include/linux/seq_buf.h | 5 +
include/linux/trace_seq.h | 2 ++
kernel/trace/trace.c | 10 +-
kernel/trace/trace_seq.c | 6 +-
lib/seq_buf.c | 22 ++
5 files changed, 23 insertions(+), 22
While powerpc doesn't use the seq_buf readpos, it did explicitly
initialise it for no good reason.
Fixes: d0ed46b60396 ("tracing: Move readpos from seq_buf to trace_seq")
Signed-off-by: Matthew Wilcox (Oracle)
---
arch/powerpc/kernel/setup-common.c | 1 -
1 file changed, 1 de
28 matches
Mail list logo
