Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp716079imm; Fri, 14 Sep 2018 05:22:53 -0700 (PDT) X-Google-Smtp-Source: ANB0VdaWVMC7TsUQqxWMmM0ZbP8I6iFxe2nHKUrBO3kY12TAUyeWouEDZLycFafBf4doyemZH81x X-Received: by 2002:a17:902:b78a:: with SMTP id e10-v6mr12205977pls.79.1536927773171; Fri, 14 Sep 2018 05:22:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536927773; cv=none; d=google.com; s=arc-20160816; b=OL+S472VUdQvj2Kt7aNdLt3vrIkH/9lbfw1SWcjSALHlcOcVj3lf6apvlVRLQJT096 4nNdjhaV1syuryuIb0Wh+gKNu8h62YriHLxk/skPP87/1PUrRBg0eMV9r9HBOd9qVJ4o bBgW7td96l+34+Gwr+T63eKl5q+3bBdNuWB+n61b/QgSugCT2mViEUMLf8b1P8VKejRG oOs84rMXyYgAP1r1k2mau6BJlSnppcwwd0e/1Xu2GRfPhgz8UWP9oI1oYRNc+pen6rlS TxbDBsEgA1dMCFyP0LUb6v05SrHcEAuHxwjsh0D5cHvD6O/LNdciAsSw/xd2rONxdzx9 3dAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:date:from:dkim-signature; bh=8BtCLlaPXVPAksidMXtNOr3AjkgxWdSxBK9sAuoGCQo=; b=VjEYmm4JpXASLzBZJr3S0nOXNDukWmG3mGwbNJQRBiYR6pRnY8lAk2wrNgYT1gIeV9 +refu0o0TzRMIZzQOFZ2PED9IwT8vUJ2erFbIuXkTSqpzAX8IOLmzJKnimhGzHuq2heB sa0JG5M1gCGxQAG1Em67Q7zjWxAJoBEHpelpeQ9jendymTdtCJLdu13mkA+fy9heZAB6 zDQMcLs+eRCvaohyS5abH/Ajw+EsegCexGIcH0PtjGwmqSF0RuaFIkQuWwe6OqyCAKMH UsDa92G82aYq07FNOIH6qnD5FvDnd1677dT4NSg5oTJRaGMsXwRBuCuOUQQCWsMYz/Qh ahMg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=ov119v2C; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y13-v6si6403624pgp.560.2018.09.14.05.22.36; Fri, 14 Sep 2018 05:22:53 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=ov119v2C; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728020AbeINRgh (ORCPT + 99 others); Fri, 14 Sep 2018 13:36:37 -0400 Received: from mail-pf1-f195.google.com ([209.85.210.195]:45554 "EHLO mail-pf1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726872AbeINRgg (ORCPT ); Fri, 14 Sep 2018 13:36:36 -0400 Received: by mail-pf1-f195.google.com with SMTP id i26-v6so4224877pfo.12 for ; Fri, 14 Sep 2018 05:22:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:date:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=8BtCLlaPXVPAksidMXtNOr3AjkgxWdSxBK9sAuoGCQo=; b=ov119v2C0qIkUU2oVEaMY9x+FDwUKXDUNShij/wBPWxjb5eLiUfawQ2rQCJq9WyQ/Z d5HpekhUwP1WvVJIN7UAe6IN72/zTriinbhVob1zxdLfpiBZT02m0d1LcS0hweURYUsZ OwpW77rJ6tq9isrqvzODsxp7uSvqV6Eqzn6jqZ4eGczd9s1SBEQwxTBReYyHsxamhXoL dCqqv/CKD3tLp25Pi2EPgrrNJCpOH+wJ3PYYgeFXi8N1tcgMZmrlNthkBs5aECgfQm50 htFNA5EgZAF2O416Fhud4/OH1vZ4DNrGNFyByxu2T2Jw2T417hD2vtGXrhB8gmXmeJmu osjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=8BtCLlaPXVPAksidMXtNOr3AjkgxWdSxBK9sAuoGCQo=; b=nvkEaUGBzPnz6D0n8h78bgvdI2fxLKS3c7mxP5+srdKV2m8TrAteDDU/yCsKRwDJ8k G1+XtZ8ZiaoV0SuHAo66tnXWQyyE4TrKu2bkz6E734297sI0+nnK90Gf2NNMkZRuiX7a oJ4DrykYZHweFD0M6uwd8Y1uVO6TDIz3Sg2pwlITTUq12njWB4Xvb6FSmIALEOXtaz4e EA7dlbNmgE3QUzKsxdT0k0XipJflZ+dgZuQmB7QlMllfuW+wmlmxMKvwlbWkwv8DVGDH a4aTRsrdXYe2SZrnDUMUYgtOjyAAhBQWfQQpmgVm2/22mt2OKH5J8djRtkFM1JjA3tTF bLCw== X-Gm-Message-State: APzg51A06xkfPHy5xZhpTpwrjph4BHLuXDH7FPdgf4+YV4wEJ+N3fbFg R3dfOmKrmEgtkc6D62ZF2j0= X-Received: by 2002:a63:6c89:: with SMTP id h131-v6mr11541023pgc.237.1536927741662; Fri, 14 Sep 2018 05:22:21 -0700 (PDT) Received: from localhost ([121.137.63.184]) by smtp.gmail.com with ESMTPSA id w81-v6sm13910770pfk.92.2018.09.14.05.22.19 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 14 Sep 2018 05:22:20 -0700 (PDT) From: Sergey Senozhatsky X-Google-Original-From: Sergey Senozhatsky Date: Fri, 14 Sep 2018 21:22:17 +0900 To: Tetsuo Handa Cc: Sergey Senozhatsky , Sergey Senozhatsky , Petr Mladek , Steven Rostedt , Alexander Potapenko , Dmitriy Vyukov , kbuild test robot , syzkaller , LKML , Linus Torvalds , Andrew Morton Subject: Re: [PATCH] printk: inject caller information into the body of message Message-ID: <20180914122217.GA518@tigerII.localdomain> References: <20180912065307.GA606@jagdpanzerIV> <20180912120548.4280f04a@vmware.local.home> <20180913071204.GA604@jagdpanzerIV> <20180913122625.6ieyexpcmlc5z2it@pathway.suse.cz> <20180913142802.GB517@tigerII.localdomain> <20180914065728.GA515@jagdpanzerIV> <49d22738-17ad-410a-be0a-d27d76ba9f37@i-love.sakura.ne.jp> <20180914115028.GB20572@tigerII.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On (09/14/18 21:03), Tetsuo Handa wrote: > > 80 bytes is quite short for OOM, agreed. > > > >> static char oom_print_buf[1024]; > >> DEFINE_PR_LINE_BUF(level, oom_print_buf); > > > > Do I get it right that you suggest to drop the "size" param? > > No. I just forgot to add params. ;-) > > > Do OOM people agree on 1024 bytes stack usage? > > I won't allocate oom_print_buf on the stack. Since its usage is serialized > by oom_lock mutex, we don't need to allocate from stack. Since memory > allocation request might happen when stack is already tight, we should not > try to allocate much from stack. ... by "OOM people" I meant "MM people". "MM people" is a subset of "OOM people". OK, so I didn't notice the "static" part of the `oom_print_buf'. I need some rest, I guess. The "SMP-safe" comment becomes a bit tricky when pr_line is used with a static buffer. Either we need to require synchronization - umm... and document it - or to provide some means of synchronization in pr_line(). Let's think what pr_line API should do about it. Any thoughts? -ss