Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752918AbdCNRPo (ORCPT ); Tue, 14 Mar 2017 13:15:44 -0400 Received: from mail-pf0-f177.google.com ([209.85.192.177]:34292 "EHLO mail-pf0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751672AbdCNRPm (ORCPT ); Tue, 14 Mar 2017 13:15:42 -0400 MIME-Version: 1.0 In-Reply-To: <69679f30-e502-d2cf-8dee-4ee88f64f887@virtuozzo.com> References: <20170302134851.101218-1-andreyknvl@google.com> <20170302134851.101218-7-andreyknvl@google.com> <2bbe7bdc-8842-8ec0-4b5a-6a8dce39216d@virtuozzo.com> <576aeb81-9408-13fa-041d-a6bd1e2cf895@virtuozzo.com> <69679f30-e502-d2cf-8dee-4ee88f64f887@virtuozzo.com> From: Andrey Konovalov Date: Tue, 14 Mar 2017 18:15:40 +0100 Message-ID: Subject: Re: [PATCH v2 6/9] kasan: improve slab object description To: Andrey Ryabinin Cc: Alexander Potapenko , Dmitry Vyukov , kasan-dev , Linux Memory Management List , LKML Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2478 Lines: 65 On Thu, Mar 9, 2017 at 1:56 PM, Andrey Ryabinin wrote: > On 03/06/2017 08:16 PM, Andrey Konovalov wrote: > >>> >>> What about >>> >>> Object at ffff880068388540 belongs to cache kmalloc-128 of size 128 >>> Accessed address is 123 bytes inside of [ffff880068388540, ffff8800683885c0) >>> >>> ? >> >> Another alternative: >> >> Accessed address is 123 bytes inside of [ffff880068388540, ffff8800683885c0) >> Object belongs to cache kmalloc-128 of size 128 >> > > Is it something wrong with just printing offset at the end as I suggested earlier? > It's more compact and also more clear IMO. This is what you suggested: Object at ffff880068388540, in cache kmalloc-128 size: 128 accessed at offset 123 After minor reworking of punctuation, etc, we get: Object at ffff880068388540, in cache kmalloc-128 of size 128, accessed at offset 123 It's good, but I still don't like two things: 1. The line is quite long. Over 84 characters in this example, but might be longer for different cache names. The solution would be to split it into two lines. 2. The access might be within the object (for example use-after-free), or outside the object (slab-out-of-bounds). In this case just saying "accessed at offset X" might be confusing, since the offset might be from the start of the object, or might be from the end. The solution would be to specifically describe this. Out of all options above this one I like the most: >> Accessed address is 123 bytes inside of [ffff880068388540, ffff8800683885c0) >> Object belongs to cache kmalloc-128 of size 128 as: 1. It specifies whether the offset is inside or outside the object. 2. The lines are not too long (the first one is 76 chars). 3. Accounts for larger cache names (the second line has some spare space). 4. Shows exact addresses of start and end of the object (it's possible to calculate the end address using the start and the size, but it's nicer to have it already calculated and shown). Thanks! > > -- > You received this message because you are subscribed to the Google Groups "kasan-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an email to kasan-dev+unsubscribe@googlegroups.com. > To post to this group, send email to kasan-dev@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/msgid/kasan-dev/69679f30-e502-d2cf-8dee-4ee88f64f887%40virtuozzo.com. > For more options, visit https://groups.google.com/d/optout.