Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753422AbbDRNJr (ORCPT ); Sat, 18 Apr 2015 09:09:47 -0400 Received: from www262.sakura.ne.jp ([202.181.97.72]:36314 "EHLO www262.sakura.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752361AbbDRNJo (ORCPT ); Sat, 18 Apr 2015 09:09:44 -0400 To: tj@kernel.org Cc: davem@davemloft.net, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org Subject: Re: [PATCHSET] printk, netconsole: implement reliable netconsole From: Tetsuo Handa References: <20150417174522.GD16743@htj.duckdns.org> <201504180303.GAB26011.OLJFSMVFFOHtOQ@I-love.SAKURA.ne.jp> <20150417180732.GF16743@htj.duckdns.org> <201504180320.CFG26062.FtSJLOOQOFVFMH@I-love.SAKURA.ne.jp> <20150417182654.GG16743@htj.duckdns.org> In-Reply-To: <20150417182654.GG16743@htj.duckdns.org> Message-Id: <201504182209.FDC13506.FHFVOOQMJLFtSO@I-love.SAKURA.ne.jp> X-Mailer: Winbiff [Version 2.51 PL2] X-Accept-Language: ja,en,zh Date: Sat, 18 Apr 2015 22:09:35 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1661 Lines: 43 Tejun Heo wrote: > > If we can assume that scheduler is working, adding a kernel thread that > > does > > > > while (1) { > > read messages with metadata from /dev/kmsg > > send them using UDP network > > } > > > > might be easier than modifying netconsole module. > > But, I mean, if we are gonna do that in kernel, we better do it > properly where it belongs. What's up with "easier than modifying > netconsole module"? Why is netconsole special? And how would the > above be any less complex than a single timer function? What am I > missing? User space daemon is sometimes disturbed unexpectedly due to (a) SIGKILL by OOM-killer (b) spurious ptrace() by somebody (c) spurious signals such as SIGSTOP / SIGINT (d) stalls triggered by page faults under OOM condition (e) other problems such as scheduler being not working We have built-in protection for (a) named /proc/$pid/oom_score_adj , but we need to configure access control modules for protecting (b) and (c), and we don't have protection for (d). Thinking from OOM stall discussion, (d) is fatal when trying to obtain kernel messages under problematic condition. I thought that a kernel thread that does while (1) { read messages with metadata from /dev/kmsg send them using UDP network } is automatically protected from (a), (b), (c) and (d), and it could be implemented outside of netconsole module. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/