Received: by 2002:a05:6358:489b:b0:bb:da1:e618 with SMTP id x27csp218634rwn; Wed, 7 Sep 2022 15:28:22 -0700 (PDT) X-Google-Smtp-Source: AA6agR7TZ8mxU0kIk0LhMPAaKbocXoB49QPKV+TU4mfHiBqCuR0C85JUV31ATOSJHg+zXH+ENJQd X-Received: by 2002:a63:1cd:0:b0:430:6b9b:df37 with SMTP id 196-20020a6301cd000000b004306b9bdf37mr5456724pgb.154.1662589702317; Wed, 07 Sep 2022 15:28:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1662589702; cv=none; d=google.com; s=arc-20160816; b=IWGkGtfV6ABrTFMmbgArcK9BtigFIQY++0TZO0S3i7bZF7UWDe2frKVm8Rxk555FBj +bjTX79e3Fq7eusMsFqmFOAyAP3ByrQldDWNpL/RDxntqweKgZxwye8LdFyty3MCJM/m XmCIjFDiKOrz/OzDWLizvol/nS5+Pfg4/ki8OHj9CczOrm6R5O546oiFdNr6ozjo/qBb PMtI2/oxnpsVbvfzLXe+tEZFt/YTLAbUy4fBckocNa65e7Cgwk9YXgJDO780WKDsHbia s1OE/3cJ/67NnvvEROJKbkULsktqdAqZKxBjfDkSRj4N5PB7Rs2ZMr9bUjvAnwQhOhug V4VA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:subject:mime-version:user-agent:message-id :in-reply-to:date:references:cc:to:from; bh=AGINkZL+lF5PIIZW7EIMwq4cztvqTt50JVqF5bv6xHQ=; b=auZ00uBw/iuvNFVx1ri87ms066vQb/TFmTUBuyHfk+NGhDbykvkj7juMrTbZssYfjy mupdap0MGKVwltOOAd6CV40lrKUCtOPL0Sj4by3fnXWkGthoPqz5GzHZGuTcQonc2rOe UIDToSrPn81HWA3WOdIqdnMhj6+6C2Lgwu5nUMR7pbsiOe/SjiA3ZVudt6+2OeZjEier eQ5WGXPnIwZl8hgqhX1l8noFFePxx+amvCCaLzZ1kIoKpzqXdxFz1T8WyHUCyL1O5mDk ghWl3oLbLmtp7it+X6Kgn1QJ3JZWxfc/v12yE47Xj54sn1u/o2IFb/SnBV0MDIq/vUJA OV0g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=xmission.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id mu3-20020a17090b388300b001fd7ced8960si385037pjb.92.2022.09.07.15.28.10; Wed, 07 Sep 2022 15:28:22 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=xmission.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230380AbiIGWBV (ORCPT + 99 others); Wed, 7 Sep 2022 18:01:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34920 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229577AbiIGWBS (ORCPT ); Wed, 7 Sep 2022 18:01:18 -0400 Received: from out03.mta.xmission.com (out03.mta.xmission.com [166.70.13.233]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 15C8F895DE; Wed, 7 Sep 2022 15:01:17 -0700 (PDT) Received: from in01.mta.xmission.com ([166.70.13.51]:32958) by out03.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1oW36e-0064Jr-Ba; Wed, 07 Sep 2022 16:01:12 -0600 Received: from ip68-110-29-46.om.om.cox.net ([68.110.29.46]:53706 helo=email.froward.int.ebiederm.org.xmission.com) by in01.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1oW36d-0092tB-7e; Wed, 07 Sep 2022 16:01:11 -0600 From: "Eric W. Biederman" To: Oleg Nesterov Cc: Oleksandr Natalenko , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-fsdevel@vger.kernel.org, Jonathan Corbet , Alexander Viro , Andrew Morton , Huang Ying , "Jason A . Donenfeld" , Will Deacon , "Guilherme G . Piccoli" , Laurent Dufour , Stephen Kitt , Rob Herring , Joel Savitz , Kees Cook , Xiaoming Ni , Luis Chamberlain , Renaud =?utf-8?Q?M=C3=A9trich?= , Grzegorz Halat , Qi Guo References: <20220903064330.20772-1-oleksandr@redhat.com> <87r10ob0st.fsf@email.froward.int.ebiederm.org> <5599808.DvuYhMxLoT@redhat.com> <20220907173438.GA15992@redhat.com> Date: Wed, 07 Sep 2022 17:00:43 -0500 In-Reply-To: <20220907173438.GA15992@redhat.com> (Oleg Nesterov's message of "Wed, 7 Sep 2022 19:34:40 +0200") Message-ID: <877d2ec0ac.fsf@email.froward.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1oW36d-0092tB-7e;;;mid=<877d2ec0ac.fsf@email.froward.int.ebiederm.org>;;;hst=in01.mta.xmission.com;;;ip=68.110.29.46;;;frm=ebiederm@xmission.com;;;spf=softfail X-XM-AID: U2FsdGVkX1/MTX45R8okRsDE3mI928lifjqE1i+i1fQ= X-SA-Exim-Connect-IP: 68.110.29.46 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-DCC: XMission; sa07 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: **;Oleg Nesterov X-Spam-Relay-Country: X-Spam-Timing: total 548 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 11 (2.1%), b_tie_ro: 10 (1.8%), parse: 1.47 (0.3%), extract_message_metadata: 4.3 (0.8%), get_uri_detail_list: 1.70 (0.3%), tests_pri_-1000: 7 (1.3%), tests_pri_-950: 1.74 (0.3%), tests_pri_-900: 1.48 (0.3%), tests_pri_-90: 143 (26.1%), check_bayes: 141 (25.7%), b_tokenize: 13 (2.4%), b_tok_get_all: 9 (1.7%), b_comp_prob: 3.9 (0.7%), b_tok_touch_all: 110 (20.1%), b_finish: 0.96 (0.2%), tests_pri_0: 354 (64.6%), check_dkim_signature: 0.49 (0.1%), check_dkim_adsp: 2.8 (0.5%), poll_dns_idle: 0.97 (0.2%), tests_pri_10: 2.2 (0.4%), tests_pri_500: 9 (1.6%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH] core_pattern: add CPU specifier X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Oleg Nesterov writes: > On 09/07, Oleksandr Natalenko wrote: >> >> The advantage of having CPU recorded in the file name is that >> in case of multiple cores one can summarise them with a simple >> ls+grep without invoking a fully-featured debugger to find out >> whether the segfaults happened on the same CPU. > > Besides, if you only need to gather the statistics about the faulting > CPU(s), you do not even need to actually dump the the core. For example, > something like > > #!/usr/bin/sh > > echo $* >> path/to/coredump-stat.txt > > and > echo '| path-to-script-above %C' >/proc/sys/kernel/core_pattern > > can help. So I am confused. I thought someone had modified print_fatal_signal to print this information. Looking at the code now I don't see it, but perhaps that is in linux-next somewhere. That would seem to be the really obvious place to put this and much closer to the original fault so we ware more likely to record the cpu on which things actually happened on. If we don't care about the core dump just getting the information in syslog where it can be analyzed seems like the thing to do. For a developers box putting it in core pattern makes sense, isn't a hinderance to use. For anyone else's box the information needs to come out in a way that allows automated tools to look for a pattern. Requiring someone to take an extra step to print the information seems a hinderance to automated tools doing the looking. Eric