On 1/21/25 3:32 AM, Hyesoo Yu wrote: > On Tue, Jan 21, 2025 at 10:48:08AM +0900, Hyeonggon Yoo wrote: >> >> >> On 1/21/2025 9:54 AM, Hyesoo Yu wrote: >>> On Tue, Jan 21, 2025 at 12:41:01AM +0900, Hyeonggon Yoo wrote: >>>> On Mon, Jan 20, 2025 at 5:30 PM Hyesoo Yu <hyesoo.yu@xxxxxxxxxxx> wrote: >>> >>> Thanks for response. >>> >>> Using warn() instead of panic, is a great idea. >>> Thanks for pointing out what I missed. >> >> Just for clarification, I think changing the common error reporting >> logic (like, slab_bug()) to use WARN() will be preferable to inserting >> new WARN()s at random points, which is what this patch does now. >> >> Best, >> Hyeonggon >> > > Thanks you for clarification. > > Actually, I considered adding BUG_ON() to slab_bug. However if we add BUG_ON() to slab_bug, > it will prevent many meaningful error log from being printed subsequently. > As you know, slab_bug is the log that usually is printed at the biginning of a bug > in the slab. As a result, it would be difficult to figure out the problems based on > the logs during our large-scale test-bed. > > Similary, even if I use WARN() in slab_bug, we won't be able to obtain the logs > when panic_on_warn is enabled. I don't think it is useful to include WARN in slab_bug. > > Instead, I will implement a solution where WARN is only used in slab_fix before > slab object is restored. If I add it to slab_fix, I think warning is suppressed on > kunit test by slab_add_kunit_errors handling. Right, makes sense to only do the WARN() after printing the debugging logs. Thanks. > Thanks, > Regards. > >
