On Wed, Apr 2, 2025 at 10:08 PM Kent Overstreet <[email protected]> wrote: > > On Wed, Apr 02, 2025 at 10:03:10PM +0530, Bharadwaj Raju wrote: > > On Wed, Apr 2, 2025 at 9:47 PM Kent Overstreet > > <[email protected]> wrote: > > If you're feeling particularly adventurous - print_string_as_lines() is > a hack, I think we should be able to do something more robust by > skipping printk (that's where the 1k limit comes from) and calling > something lower level - that will require digging into the printk > codepath and finding lower level we can call.
I tried looking into the printk codepath, namely vprintk_emit -> vprintk_store. It doesn't seem like there's a convenient single lower-level entrypoint we could call which just avoids the 1k limit, rather there's a lot of internal code mixed with the truncation that we'd have to just copy if we want printk behavior. I don't think that's a reasonable option for us. > I also just noticed that print_string_as_lines() needs to check for > being passed a NULL pointer - in case the printbuf memory allocation > fails. Want to get that one too? >From what I'm seeing __bch2_print_string_as_lines already checks for the lines pointer being NULL. The only unchecked pointer is prefix, which I don't think needs to be checked since it will be something constant from kern_levels.h, not something which could be NULL.
