On Tue, May 13, 2025 at 11:41 AM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Tue, 13 May 2025 10:26:45 +0800 Jason Xing <kerneljasonxing@xxxxxxxxx> wrote: > > > > > > > Maybe we don't need to check !chan either. Can it be NULL here? > > > > It depends on how users call this. If users call this without > > initialization of chan, relay_dump() can avoid the crash. It works > > like kfree() which prevents the NULL object from being freed. > > hm, OK. Generally, I don't think that kernel code should be very > tolerant of bugs in the caller. If the caller passes us bad stuff then > that's the caller's fault and the caller should be fixed. If the > client code responds to bad input with a nice solid oops, then great! > The caller will get fixed. I learned. Thanks. I will skip the check for that. > > > BTW, should I merge this commit [1] into the series in V2 so that you > > can easily review? > > > > [1]: https://lore.kernel.org/all/20250507134225.63248-1-kerneljasonxing@xxxxxxxxx/ > > That seems unrelated to this work so it seems inappropriate to combine > the two. This series is built on top of [1]. > > I skipped [1] because I'm waiting for overall clarity on what's > happening with relay[fs]. Do you refer to this thread[2]? Well, that conversation/reply made me feel lost. I believe you've already seen that. If so, it seems we're working on the dead code together.... [2]: https://lore.kernel.org/all/70293376-71b0-4b9d-b3c1-224b640f470b@xxxxxxxxx/ Thanks, Jason
