On Fri, Apr 04, 2025 at 12:22:45PM +0530, Bharadwaj Raju wrote: > 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.
Yeah that does look a bit messy - and it doesn't exactly explain where the 1k limit comes in. > > 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. Yep, I should've checked the code before I said that :)
