From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3E7ED146017 for ; Wed, 12 Jun 2024 11:18:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718191107; cv=none; b=uwqo4r81RFlPsX4cwlrHcy7cKaUpL4M7yjN+o7qsasdWieQxxiAP0gPDUnQMWTcwE+TlQ+H7DolWRNsa6432RJwUuWKCISjsOiGHfAxmQXX36q3n421JivhPzcVRUG4qaE894fuGhpGuEFTqqyk0GTUNdIdlF8TtOZDLvbDqwLg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718191107; c=relaxed/simple; bh=PT6fOUf51ccBbvJb7+4E5fDv3MUsOjRKTM6YebMxFOA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=UXvLW1vN3eMgkEsYwYANpfBkNVhwKOJHmLARgSCdUyzueeCneZTZYuyQK6tLNZJ2NpsfvwcsNcMA1yeN9vnVu4ZwE25JFVbUggoL8E4aUqRQiy7UoSt1/hVn+ipzN+diXQh7cycWXyqmT2c7WyjnObk5I4uEpPgGZSSsVi9CTlY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=EGzRQKBj; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=zpRLi3zK; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="EGzRQKBj"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="zpRLi3zK" From: John Ogness DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1718191104; 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=9TfoN5fT9z1aWy6mZPAFxGaM3QQbIfdI9fl1+BkB0sA=; b=EGzRQKBjJvrI/FAVXDWKDfJecnRjDkJXRmXlXglaMqn51bf3npwvUEhoDkYIz4vzV3qjfG NxxF+tihkeElfCvIHVpImckIezkbdNRbBjW8ByDdYHeTm+4qP6c3i1sXlMYcwwwNdiQfMX 3LlCMUOrPTl1ZHO5XxD89PoiLleDuevbi3Ie0Ch1rGRUzz+zEypcndHTAo/LAcjLnfX74X TFiFlg2oLsmsxduqO4pi76zeFsxR6lsljPRRlX306mgjFSMYJg91XN27I4RvE6EMFLXW6t MoumbV2oOvpxuIKQGxHgSkoTHo8Cx2RyOtNBpP95Mw5p5ogxpRvfvgXzJLMqRw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1718191104; 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=9TfoN5fT9z1aWy6mZPAFxGaM3QQbIfdI9fl1+BkB0sA=; b=zpRLi3zKrmqyDy+5eOEbIHGxmZUgW0nB3FaJp4f9rzCyqpmXehUQFAfEgqUZDy62OeoK7K nUErFvIUj/WPm8CQ== To: Petr Mladek Cc: Sergey Senozhatsky , Steven Rostedt , Thomas Gleixner , linux-kernel@vger.kernel.org, Greg Kroah-Hartman Subject: Re: [PATCH printk v2 04/18] printk: nbcon: Introduce printing kthreads In-Reply-To: References: <20240603232453.33992-1-john.ogness@linutronix.de> <20240603232453.33992-5-john.ogness@linutronix.de> <87ed95j8yh.fsf@jogness.linutronix.de> <87sexipmrk.fsf@jogness.linutronix.de> Date: Wed, 12 Jun 2024 13:24:24 +0206 Message-ID: <87plsmpfy7.fsf@jogness.linutronix.de> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On 2024-06-12, Petr Mladek wrote: >> > After all, I would add two comments, like these: >> > >> > >> > /* >> > * Any access to the console device is serialized either by >> > * device_lock() or console context or both. >> > */ >> > kt = kthread_run(nbcon_kthread_func, con, "pr/%s%d", con->name, >> > con->index); >> > [...] >> > >> > /* >> > * Some users check con->kthread to decide whether to flush >> > * the messages directly using con->write_atomic(). But they >> > * do so only when the console is already in @console_list. >> > */ >> >> I do not understand how @console_list is related to racing between >> non-thread and thread. kthreads are not only created during >> registration. For example, they can be created much later when the last >> boot console unregisters. > > I had in mind two particular code paths: > > 1. The check of con->kthread in nbcon_device_release() before > calling __nbcon_atomic_flush_pending_con(). > > But it is called only when __uart_port_using_nbcon() returns true. > And it would fail when nbcon_kthread_create() is called because > > checks hlist_unhashed_lockless(&up->cons->node) > > would fail. Which checks of the console is in @console_list > > > 2. The following check in console_flush_all() > > if ((flags & CON_NBCON) && con->kthread) > continue; > > The result affects whether the legacy flush would call > nbcon_legacy_emit_next_record(). > > But this is called only for_each_console_srcu(con) > => it could not race with nbcon_kthread_create() > because this console is not in @console_list at this moment. > > By other words, I was curious whether some other code paths might > call con->write_atomic() while the kthread is already running. > > It is not that important because it would be safe anyway. > I was checking this before I realized that it would be safe. Yes, it must be safe because it can happen at any time. For example, when flushing after an emergency section. > Anyway, the information about that the console is not in @console_list > when we set con->kthread still looks useful. Except that it is not always true. If boot consoles are registered, the kthread is created later, after the console _is_ in @console_list. Setting con->kthread really has nothing to do with @console_list. > At minimum, the check would be racy if the console was on the list. The con->kthread check _is_ racey, but it doesn't matter. Perhaps you just want to make it clear that it is racey but it does not matter. How about: /* * Some users check con->kthread to decide whether to flush * the messages directly using con->write_atomic(). Although * racey, such a check for that purpose is safe because both * threaded and atomic printing are serialized by the * console context. */ con->kthread = kt; John