All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hyesoo Yu <hyesoo.yu@samsung.com>
To: Hyeonggon Yoo <42.hyeyoo@gmail.com>
Cc: janghyuck.kim@samsung.com, Christoph Lameter <cl@linux.com>,
	Pekka Enberg <penberg@kernel.org>,
	David Rientjes <rientjes@google.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Vlastimil Babka <vbabka@suse.cz>,
	Roman Gushchin <roman.gushchin@linux.dev>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Chengming Zhou <chengming.zhou@linux.dev>
Subject: Re: [PATCH] mm: slub: Print the broken data before restoring slub.
Date: Wed, 22 Jan 2025 14:27:36 +0900	[thread overview]
Message-ID: <20250122052736.GA1498496@tiffany> (raw)
In-Reply-To: <CAB=+i9QWK2ZyuUfiLq7HhsxXNzf0gOo5uQ5zBzn8d0b5m-S7eA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2632 bytes --]

On Tue, Jan 21, 2025 at 10:35:58PM +0900, Hyeonggon Yoo wrote:
> On Mon, Jan 20, 2025 at 5:31 PM Hyesoo Yu <hyesoo.yu@samsung.com> wrote:
> 
> Let's add Chengming, the author of the commit, to Cc,
> as he might have some opinions about it.
> 
> > Previously, the restore occured after printing the object in slub.
> > After commit 47d911b ("slab: make check_object() more consistent"),
> 
> at least 12 characters of the commit hash should be used to refer to a commit.
> Documentation/process/submitting-patches.rst states that:
>     You should also be sure to use at least the first twelve
> characters of the SHA-1 ID.
>     The kernel repository holds a lot of objects, making collisions
> with shorter IDs a real
>     possibility. Bear in mind that, even if there is no collision with
> your six-character ID
>     now, that condition may change five years from now.
>

Thanks for pointing out the mistake.

> > the bytes are printed after the restore. This information about the bytes
> > before the restore is highly valuable for debugging purpose.
> > For instance, in a event of cache issue, it displays byte patterns
> > by breaking them down into 64-bytes units. Without this information,
> > we can only speculate on how it was broken. Hence the corrupted regions
> > are printed prior to the restoration process.
> 
> Probably this should be considered for -stable releases. What do you think?
> [1] https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
> 

Thank you for the advice. I will add Cc:stable@vger.kernel.org in the next version.

> > diff --git a/mm/slub.c b/mm/slub.c
> > index c2151c9fee22..48cefc969480 100644
> > --- a/mm/slub.c
> > +++ b/mm/slub.c
> > @@ -1207,6 +1207,7 @@ check_bytes_and_report(struct kmem_cache *s, struct slab *slab,
> >                                         fault[0], value);
> >
> >  skip_bug_print:
> > +       print_section(KERN_ERR, "Corrupt  ", fault, end - fault);
> 
> I don't think it's supposed to report an error here, per the name of
> the label "skip_bug_print".
> 

It is good point. I will move print_section above the skip_bug_print label.

> Maybe move print_trailer() and add_taint() back to
> check_bytes_and_report(), and report an error
> only once and skip reporting if it's already reported?
> 
> Best,
> Hyeonggon
> 

By passing a new parameter to the check_bytes_and_report(),
It could be implemented. Would it be better to add a new boolean
parameter to that function ? Or do you have any other ideas ?

Thanks,
Hyesoo.

> >         restore_bytes(s, what, value, fault, end);
> >         return 0;
> >  }
> > --
> > 2.48.0
> >
> 

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



      parent reply	other threads:[~2025-01-22  5:29 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20250120083144epcas2p369584af764b617c3d2cb2a0568a45d6c@epcas2p3.samsung.com>
2025-01-20  8:30 ` [PATCH] mm: slub: Print the broken data before restoring slub Hyesoo Yu
2025-01-21 13:35   ` Hyeonggon Yoo
2025-01-22  3:25     ` Chengming Zhou
2025-01-22  5:42       ` Hyesoo Yu
2025-01-22  5:27     ` Hyesoo Yu [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250122052736.GA1498496@tiffany \
    --to=hyesoo.yu@samsung.com \
    --cc=42.hyeyoo@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=chengming.zhou@linux.dev \
    --cc=cl@linux.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=janghyuck.kim@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=penberg@kernel.org \
    --cc=rientjes@google.com \
    --cc=roman.gushchin@linux.dev \
    --cc=vbabka@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.