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 7A8143A4524 for ; Fri, 22 May 2026 13:27:13 +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=1779456434; cv=none; b=SyL0qT0FK1Pwt1WNMcg2DsT2QQncY+nqKCBojR8mTW5AT6AJGs63eY1pyOHYGXhaqkZDfd0dvQ/0ydnl/oKsqmjqxm5lXiM+Y7LFm9uOoBFTKJbzQ9rpyroAq3hJ4483Vw6UDn/ZIDLqpd6ztAA0LKjKtSpxtKQj7XObToyvH9w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779456434; c=relaxed/simple; bh=Sq7yzhS8eWrwCRD+K9NaXQvJxLeTjrAYEGGlCKbo62k=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=nKMh2A1U/qlX4mHBXMf2DnIzD4+Yt8Xynb/F+ZCq0a2axjE2Hgti6OsDA6prjNTWX1fFaCjIOaW1xywHbGbKRfiGg8GN88taxCtGPEeZAxYvz/couNPWro3mopiOH9vONAoFTZ7NKNTY4xy5lkcca+Bvv56Ujb8Y+PlOhQeN0Rs= 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=MDWy9g21; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=1D/mylN8; 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="MDWy9g21"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="1D/mylN8" Date: Fri, 22 May 2026 15:27:09 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1779456430; 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=Lge6mqqEC5sbbqe8c5OhMvqHT9iCsIYIlDVbs42tDsw=; b=MDWy9g21f6mXoxBC0BHZmA53CsqXP5TSNxSXmqLI3Sj09DQkkqVMXtQAeeVJeUAoowlNkS glgXZAY0bKfgRnbSjlMwAvR22ZIcURH0OjgR9TLgjoxBk2/xrQULDo5HCSc8MdwZDLBLGE 56u+G32UtRdMAsmQZY1iRdqvc6YmM4N1AA2f89/At5IvQ11FqpoEv9QVCddqFEKuHYLo+5 e2WIWf+eAPYUKt2ZMro8UzQp/aTU007R5IKzd/SqWVHtEhxEJEwLWRcArPhV3AzDy0LARY jYMzz7rb3V5e3LRVBDS/CAhslec/P8gmqObFD2uDxUZP5oHZc173V/J6pMZ9Jg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1779456430; 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=Lge6mqqEC5sbbqe8c5OhMvqHT9iCsIYIlDVbs42tDsw=; b=1D/mylN8HE38bZ4l1Or1tezBq9pwiKDEVIF/QApBwHroDt2FNOF7YR4r+0aI4mHcipJD18 85tg5kANO5QsPTBQ== From: Sebastian Andrzej Siewior To: Tetsuo Handa Cc: Alexander Potapenko , Dmitry Vyukov , kasan-dev , LKML , Alan Stern , Andrew Morton , Andrey Konovalov , Andrey Konovalov , Clark Williams , Greg Kroah-Hartman , Marco Elver Subject: Re: [PATCH v4] kcov: move kcov_remote_data to task_struct and remove local_lock Message-ID: <20260522132709.PHTrk7UJ@linutronix.de> References: <1956540a-e458-4a44-854b-11ff07cb1072@I-love.SAKURA.ne.jp> <20260521083848.UF_zf4xK@linutronix.de> <20260521181450.Ax-chxOE@linutronix.de> <88c3951e-f733-4733-ab81-4feeb5de6b51@I-love.SAKURA.ne.jp> <7aff4d71-a6a0-4898-9491-2a3973e9d0cc@I-love.SAKURA.ne.jp> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <7aff4d71-a6a0-4898-9491-2a3973e9d0cc@I-love.SAKURA.ne.jp> On 2026-05-22 20:10:47 [+0900], Tetsuo Handa wrote: > --- a/kernel/kcov.c > +++ b/kernel/kcov.c > @@ -86,21 +86,8 @@ struct kcov_remote { > > static DEFINE_SPINLOCK(kcov_remote_lock); > static DEFINE_HASHTABLE(kcov_remote_map, 4); > -static struct list_head kcov_remote_areas = LIST_HEAD_INIT(kcov_remote_areas); > - > -struct kcov_percpu_data { > - void *irq_area; > - local_lock_t lock; > - > - unsigned int saved_mode; > - unsigned int saved_size; > - void *saved_area; > - struct kcov *saved_kcov; > - int saved_sequence; > -}; > - > -static DEFINE_PER_CPU(struct kcov_percpu_data, kcov_percpu_data) = { > - .lock = INIT_LOCAL_LOCK(lock), > +static struct list_head kcov_remote_areas[2] = { > + LIST_HEAD_INIT(kcov_remote_areas[0]), LIST_HEAD_INIT(kcov_remote_areas[1]) > }; > > /* Must be called with kcov_remote_lock locked. */ > @@ -136,8 +123,9 @@ static struct kcov_remote_area *kcov_remote_area_get(unsigned int size) > { > struct kcov_remote_area *area; > struct list_head *pos; > + struct list_head *list = &kcov_remote_areas[size == CONFIG_KCOV_IRQ_AREA_SIZE]; This gets probably the job done but the two lists and check condition looks a bit hackish. The size is not really important, it is user-sized buffer vs softirq-buffer. Having an explicit might not be bad. > @@ -1119,14 +1083,19 @@ static void __init selftest(void) > > static int __init kcov_init(void) > { > - int cpu; > + int cpu = num_possible_cpus(); > > - for_each_possible_cpu(cpu) { > - void *area = vmalloc_node(CONFIG_KCOV_IRQ_AREA_SIZE * > - sizeof(unsigned long), cpu_to_node(cpu)); > - if (!area) > - return -ENOMEM; > - per_cpu_ptr(&kcov_percpu_data, cpu)->irq_area = area; > +#ifdef CONFIG_PREEMPT_RT > + /* Allocate some extra buffers in order to prepare for softirq preemption. */ > + cpu = cpu >= 4 ? cpu * 2 : cpu + 4; > +#endif Maybe IS_ENABLED(). This assumes that we have twice as many tasks in softirq context as we have CPUs. Is probably good enough. Are the sizes somehow important? Any reason why there should not be a "sane" lower size and then fallback to the user-buffer if it runs out of softirqs buffers? The user may request multiple sized buffers via KCOV_REMOTE_ENABLE, are they cleaned up? The question would could the softirq use the user sized buffers if any. > + while (cpu--) { > + void *area = vmalloc(CONFIG_KCOV_IRQ_AREA_SIZE * sizeof(unsigned long)); > + unsigned long flags; > + > + spin_lock_irqsave(&kcov_remote_lock, flags); > + kcov_remote_area_put(area, CONFIG_KCOV_IRQ_AREA_SIZE); > + spin_unlock_irqrestore(&kcov_remote_lock, flags); > } > > /* Sebastian