Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp2449452pxj; Mon, 10 May 2021 03:18:53 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyPM1GTfOrkWkCQ7x5oXTV3OukqO0zbhzsvY4GQBDt3dgJj0Eip/2zU6IsKXyRh1d14wk12 X-Received: by 2002:a5d:87c4:: with SMTP id q4mr16541507ios.141.1620641933150; Mon, 10 May 2021 03:18:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620641933; cv=none; d=google.com; s=arc-20160816; b=MnObBem9qNGT2LNS45broHrpLcI+ocTz08vXBUDWIOoZTUb9Vn9qSylnJax7nTTWAB giuaascssqB6fVaEo7nqHCv6JQUq6zFm3nVlvrWh0MzZxBKm9kub6+A8aSCEavxVOQlG /Hg7Qsdd2L5Zk7zR0uJMJGi9c+IjvA/GJXhehmIywueHkToUXrKPTSFiC6zyhmwtw+KP PqrWzEqT797rX228jdmQJ1E+pn4RN7wzkRVqY8ueQnE7VjtEbUrbdHXYQuh+CJA032Ez oIDApd5HZWm/Z5iQzY+sxF5ZcK14ycAjPZaZQu1/xJ+grSz/VXxmuOTSMPgAmK7xOt9b H6XA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=3cweDVHmJDxzRO4VtKIboZgqH2LOMiawxyK36GGbPmY=; b=ri+xX0o1BfNVpMgMKFtQPvMQKynGhD+kCulf6Ymodr43PQqWCBKXwCEUBBvqOHwtGy kXHVhSyprNSUlqw1fsrQAxb2Fka3jnpXxp5aNkFY6fLrKeNhY2O67+wjDBCf1uFKeCdz Zj8L6gAoiqGgslSvqRm3gef8Ru1WZKn2Af2ytHIiG9BejYvRLY0LMW0GxU1mUX9JAAlR 5fpe9w5Isg3nLo0pJ2CSGAKFkpZfpcwZU48PN6juCtXOOLY/ej9bT60bAfQ35WKHhkxV Fm39ErIV7Vy/HX74CQpOK8HL1nvvx/hlWs58y6t6ogi8DY6nee7sKuTT3AnYVZv6bjDy Qq7g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b="o/bmQD9G"; 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=QUARANTINE sp=NONE dis=NONE) header.from=suse.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l2si16565872ios.47.2021.05.10.03.18.40; Mon, 10 May 2021 03:18:53 -0700 (PDT) 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=@suse.com header.s=susede1 header.b="o/bmQD9G"; 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=QUARANTINE sp=NONE dis=NONE) header.from=suse.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230342AbhEJKSV (ORCPT + 99 others); Mon, 10 May 2021 06:18:21 -0400 Received: from mx2.suse.de ([195.135.220.15]:32874 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230196AbhEJKSV (ORCPT ); Mon, 10 May 2021 06:18:21 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1620641836; h=from:from:reply-to: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=3cweDVHmJDxzRO4VtKIboZgqH2LOMiawxyK36GGbPmY=; b=o/bmQD9GUo7ODfdUF3UID6DnGaat3qXTIm88SkPjMHt5uVFvIlKajxhNWo77eysUmbOGdH 4Uirwfp48bc7+hqhwCq/VFMLZ0tfwdKxgjKFbPteGMwRDh/wCd1ZpiEzp+d9vR2xK2HZHr vSHo6gGnv8os6NQfGkCH70/GLeDRgSw= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id D5DFDADDB; Mon, 10 May 2021 10:17:15 +0000 (UTC) Date: Mon, 10 May 2021 12:17:15 +0200 From: Petr Mladek To: Sergey Senozhatsky Cc: Luo Jiaxing , sergey.senozhatsky@gmail.com, rostedt@goodmis.org, john.ogness@linutronix.de, linux-kernel@vger.kernel.org, linuxarm@huawei.com, bobo.shaobowang@huawei.com Subject: Re: [PATCH] printk: stop spining waiter when console resume to flush prb Message-ID: References: <1620288026-5373-1-git-send-email-luojiaxing@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon 2021-05-10 17:26:45, Sergey Senozhatsky wrote: > On (21/05/07 18:36), Petr Mladek wrote: > Well, the alternative patch set just gives everyone an API that selectively > downgrades printk() to pre-console_sem_owner age: when console_unlock() > would never handover the printing duty. It'll take no time until this > function will pop up somewhere where we don't want it to be used. > > E.g. > > rcu_read_lock(); > ... > console_unlock_preemptible(); > ... > rcu_read_unlock(); > > lockdep_assert_preemption_enabled() is not entirely reliable - it > depends on __lockdep_enabled, provided that system in question has > CONFIG_PROVE_LOCKING set. I understand the concern. I think that I would be able to sleep with this. I believe that such problems would be discovered soon. Also I doubt that it would spread that quickly. It is the same as with printk_deferred(). It is just a workaround for a problem that only few people are aware of. If it is still a concern, we could make it static and block any patches that would make it public. But it does not make sense to fight over this now. I am not sure that console_unlock_preemptible() is worth it after all. Luo has to prove that it might fix a real life problem. > It queues the work IF we have pending messages AND there are NO active > console_sem waiters spinning on consolse_sem waiting for us to handover > the printing duty. And IRQ shall write to consoles only N messages out > of possibly M pending messages (M > N). N, obviously, should be small, > e.g. 42 lines: if after 42 printed lines we didn't handover printing > to another context then - queue another IRQ work and iret. But it keeps > the console_owner mechanism enabled. I am sorry but I am not going to continue in this discussion. Many printk() designs have been discussed in the past and this is just repeating the same again and again. The current plan is to move console work to kthreads (separate preemptive context). Using IRQ is a complete opposite way. There is always the fight between getting the messages out as soon as possible and the risk of breaking the system (softlockups, deadlocks). The kthread approach reduces the risk of system breakage to a bare minimum. The price is that some messages might never reach console. There is finally a consensus to give it a try. If it fails, we might start looking for alternatives again. Best Regards, Petr