On Wed, 13 Jul 2022 at 12:07, Christoph Lameter <cl@xxxxxxxxx> wrote: > > On Wed, 13 Jul 2022, Hyeonggon Yoo wrote: > > > > Why return 0 if there is an error and why bother the callers with these > > > checks. BUG()? > > > > I thought BUG should be used when there is no other solution. > > Spurios returns of 0 that the caller has to check for is a solution? It's never really been about the caller checking for 0, see below. > > > I guess this is an error since the order-0 page cannot come from slab > > > allocations. > > > > comment in ksize() says: > > "The caller must guarantee that objp points to a valid object > > previously allocated with either kmalloc() or kmem_cache_alloc()." > > > > It should not be used on order-0 page that is not allocated from slab. No? > > I guess we would need to check. Code could exist that does this. > > Getting a 0 size would be surprising too here. BUG()? Or WARN() and return > PAGE_SIZE. We shouldn't crash, so it should be WARN(), but also returning PAGE_SIZE is bad. The intuition behind returning 0 is to try and make the buggy code cause less harm to the rest of the kernel. >From [1]: > Similarly, if you are able to tell if the passed pointer is not a > valid object some other way, you can do something better - namely, > return 0. The intuition here is that the caller has a pointer to an > invalid object, and wants to use ksize() to determine its size, and > most likely access all those bytes. Arguably, at that point the kernel > is already in a degrading state. But we can try to not let things get > worse by having ksize() return 0, in the hopes that it will stop > corrupting more memory. It won't work in all cases, but should avoid > things like "s = ksize(obj); touch_all_bytes(obj, s)" where the size > bounds the memory accessed corrupting random memory. [1] https://lore.kernel.org/all/CANpmjNNYt9AG8RrGF0pq2dPbFc=vw2kaOnL2k5+8kfJeEMGuwg@xxxxxxxxxxxxxx/ Thanks, -- Marco
