Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp1976202pxu; Sun, 6 Dec 2020 14:14:02 -0800 (PST) X-Google-Smtp-Source: ABdhPJyhRWh3yWJfw5bCW1ZK6LrUbIVO/9VqdLn2nS4OJihG1cIhtnxhz4K3/SYGrz6kT2PMSylZ X-Received: by 2002:a17:906:b306:: with SMTP id n6mr16066782ejz.473.1607292842266; Sun, 06 Dec 2020 14:14:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607292842; cv=none; d=google.com; s=arc-20160816; b=OUv3Gner5w4rIuAtcg/dwyQoPoy3UkPojLhuTuGZtWXmc0S1F6qNWhFyoqI1Axbot4 F/0GyPNhG+33hPYOjl13o8p9KMo8sTFxeHhHZCBD2/L7jmVDkIMyRMmi2jetOadHfpO6 q5uoXR2MeP0DYX0HIuWybloO/XBFoAO2+SZIhS3QkwFubFIKeyIY43MoYZzaMGhR2RRx 2x38zELDbCGcGD/1c0duaUWPpGGVNfRrOH+SCC8qZFJjGxfy61tbJOhcpEY96rUNrk7P upi1RV15/HPoLBzJc6USwftvcwJGeAKE391/zNHIsHcM49tR49rfZaD/eUp7JYK4Y1l+ EhoQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:dkim-signature:dkim-signature:from; bh=/+5wYSmV7lcFkyHHYfNCMDI0svv2RfxibRXE5myZbPQ=; b=cF4IiLrsNBFTKrZW/FATdZaBqpMpuWBxf8Y09BvoXP+hoWapwIUofjkIYMqmJP75N9 Q+3rf6N0jycNlV6zv+604EQ24CxAu+jCIrt+2/b6L/qGjiRUptls53aoZIu+/9PvSNHW boAXdtbY59TDecflSFWMOdlUzRepa+JsgHJwqkMvjpOxfHKWkLFcw6cuQ0vRIdKK0cMz Mp8CteJYNk/cdXvOlxMAfYb+RGQMk6FshQFLOqnZY+pyjxW7RfIxnV8jeemEftoWJUVZ Nan9VruailZ/A1euqvkFA7mroKXS+6dAsCvBbR9AMXX5j2fwb4y/OoKUoTXqakNonyya 3zXQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=hREXxPH6; dkim=neutral (no key) header.i=@linutronix.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k29si710364edk.367.2020.12.06.14.13.39; Sun, 06 Dec 2020 14:14:02 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=hREXxPH6; dkim=neutral (no key) header.i=@linutronix.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728220AbgLFWJi (ORCPT + 99 others); Sun, 6 Dec 2020 17:09:38 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58716 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727427AbgLFWJi (ORCPT ); Sun, 6 Dec 2020 17:09:38 -0500 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 00A17C0613D0 for ; Sun, 6 Dec 2020 14:08:57 -0800 (PST) From: John Ogness DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1607292536; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=/+5wYSmV7lcFkyHHYfNCMDI0svv2RfxibRXE5myZbPQ=; b=hREXxPH6oM7hgGxINGBFegI0MIfKOmwrWyaq6qqWpAErqjSJ9r9Bhf4peecr5haY0610dH CW4izLItPaP1+qB89s5qY7ZOjW4im8mPVGdnANJmjE5qgnLq+tKPQn5oBZ+qhaB0MqBR2v ZnJtQT6Aq0VEJl0/1RsuzDTqJU3u6LXJJuOD+YUpCgjxSF73DvREPunVYZXMIstB9KSUY/ CjRTdF8arjbm4C+UF3cMoer/IdxLz0dnxbLDs2OCG8b+3JDBx8t1gunjkTXA4it91bYoGk qMjp01lOlBXyY96beh1VCxHwZOrMBDD5VpuEXW0oJ+mynA02ymKnLywPsJV3aw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1607292536; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=/+5wYSmV7lcFkyHHYfNCMDI0svv2RfxibRXE5myZbPQ=; b=7ulJcchhbjtSAHwGyhfXOGYvg2XpcwlcIRUCPZqs+ZO+HNNj7j62yp/X3DAzdGb5LsnpW2 yhlW9XoHszjPMVAQ== To: Sergey Senozhatsky , Petr Mladek Cc: Sergey Senozhatsky , Sergey Senozhatsky , Steven Rostedt , Linus Torvalds , Greg Kroah-Hartman , Thomas Gleixner , linux-kernel@vger.kernel.org Subject: Re: recursion handling: Re: [PATCH next v2 3/3] printk: remove logbuf_lock, add syslog_lock In-Reply-To: References: <20201201205341.3871-1-john.ogness@linutronix.de> <20201201205341.3871-4-john.ogness@linutronix.de> Date: Sun, 06 Dec 2020 23:14:56 +0106 Message-ID: <87pn3mmvt3.fsf@jogness.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020-12-05, Sergey Senozhatsky wrote: >> We should allow at least some level of recursion. Otherwise, we would >> not see warnings printed from vsprintf code. > > One level of recursion seems reasonable on one hand, but on the other > hand I also wonder if we can get useful info from recursion levels 2 > and higher. Would be great to maybe list possible scenarios. vsprintf() > still call re-enter printk() -- WARN_ONCE()-s in the code -- external > format specifiers handlers also can. Would we need to let two levels of > recursion printk->vsprintf->printk->???->printk or one is just enough? > > It also would make sense to add the lost messages counter to per-CPU > recursion counter struct, to count the number of times we bailout > of printk due to recursion limit. So that we'll at least have > "%d recursive printk messages lost" hints. We do not need such a counter to be per-cpu. A global atomic_long_t would suffice. Although I am not sure if that should be separate from the @fail member of the ringbuffer. > Overall... > I wonder where does the "limit printk recursion" come from? printk_safe > doesn't impose any strict limits (print_context is limited, but still) > and we've been running it for years now; have we ever seen any reports > of printk recursion overflows? The printk code is undergoing some major changes and we have already had bugs slip into the merge window. IMHO the additional code to track the recursion does not add significant complexity or runtime overhead. I would prefer to keep it until we are finished with this major rework. John Ogness