From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (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 588EE2D5410 for ; Wed, 14 Jan 2026 19:49:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768420171; cv=none; b=s37sTkMeQwU/Z41q1irO8ubAdgZ65mUiDrA05HBL9rGyVb/9QGn7xGPpUdfjzcZszm79kKGhFjLlBS2dHOtPdsI33t0DYgznczdOEz7mTH7jJnavj4aS2BFjGDwSt+NDKe+LQWHKmEJ2CsinD2zhvwxZ7abdAyYsvc80xqorNMQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768420171; c=relaxed/simple; bh=Rp7bygITWkl2iOdJog7E+DS3mMTJ+iHy+1jO1iAtU4c=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=hvTkftliV5ewScWIc1+UcSUHRue3oGXzLhA1upiI/WlE5n35qWCK52lyfbLPABT6ezqwIYtEhP3Yb0FpM4uamS9OHQ3L4fxt+253NzWNHOPLw1OBliRb08xYEznY2Ic8mqPUKN3HK6+IPrYEdeN1trof9mQSNaAjj0LNT3MpNI0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=R9vJPgfj; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=gIWhUG0k; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="R9vJPgfj"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="gIWhUG0k" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1768420168; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=u++Xz0cnjGkJEP63pY4RzjASIAxlnVi2WZSHFYYKOxA=; b=R9vJPgfjDmPiZPLZKLQtnr5tlXbKFR/CrhB8/YHxS5s3PkLSkzJnjpXkkkt/nUEF/l/M1U Nu/tD/8zzOGddANDP/kQyB3HjHxMUUZI1M6NSrHdCKRfVE5ww3YSdJKyxuTHE/ZT/sZEbf IJh6Mv2qrjG0Y8ZErAJbY8hFAeHK5z0= Received: from mail-vk1-f198.google.com (mail-vk1-f198.google.com [209.85.221.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-642-0O6xjvo_NqOhZNdUJ2Jrrg-1; Wed, 14 Jan 2026 14:49:24 -0500 X-MC-Unique: 0O6xjvo_NqOhZNdUJ2Jrrg-1 X-Mimecast-MFC-AGG-ID: 0O6xjvo_NqOhZNdUJ2Jrrg_1768420164 Received: by mail-vk1-f198.google.com with SMTP id 71dfb90a1353d-5635d204db6so191329e0c.0 for ; Wed, 14 Jan 2026 11:49:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1768420164; x=1769024964; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=u++Xz0cnjGkJEP63pY4RzjASIAxlnVi2WZSHFYYKOxA=; b=gIWhUG0kTrBVhIc9ABKZkGZx3ULfCmrQTZkQDVNz6LgBP6SdV3EAcDH0eUahzKK+Iz VwviTD6YhvhFuGd4UGpxftyO6HDX/yBpCnbYqHxSWS0tH5myg4JXWFRLpQPSWD22tCUU 6MUDDT0JyGF+fVnuC4844K21/t2TpyPQYzWp+aObCONcpmZdi1FhDbeH2VMVvYwBI5fQ loLwHDOwP7HtNitGiwcyw89ejnqx2KyX9snNARhTKZ70F0T3a28gVS4oTTV/vKBuxAQI T+Bf4XXoEo14aJpCOJaa71UZQVWc4lwc+zCnCfNp6Yiz2tchO2VvpWob9eCijLjOSvO/ BaWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768420164; x=1769024964; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=u++Xz0cnjGkJEP63pY4RzjASIAxlnVi2WZSHFYYKOxA=; b=wGA7ClbSONxD2ip69YK/1F/dcnLvwZyO6y+JLrOLa2nrfg3d6T7/O5cc+IOWmx5VsR YSHnSQkiO7mv1w0AxXQiCenrGkwjPjuSJoKKkCBqn8nMnGXdMHCnuRd2eLIxXmtfTtfx yjrxR/cx3aOP4kQ7LsoaJ5jE2RTwjgEu0Mv7Xn2NOQSmsFXUd2X0TNcNkurZLA/qiM/a 4sm1accTcI27dzx+aSWJKMqTbCfBCvo8kQwoDPhq6fvbpV+Q0aV1D+4oYqF//M7ZQ2bc eHoxGBWW4ODKV0jf2Q/FWIwxKW8XtiyfvUGjpDSuzM6Q2gCB2TOvizQ41ASZul8QhJxX SKAw== X-Forwarded-Encrypted: i=1; AJvYcCWDBAsY9GGzvRLTMvxbk0f3tQxnKKOS4Rz0VVtZQ5tiUv+kJUIyv+d/pwBzIMC0kX1+GyqoDbLw5x/3l8Y=@vger.kernel.org X-Gm-Message-State: AOJu0Yw2FheqnfqkL/PB3WBbSKHkLJrtx2KEmtYTP7QZEQdn7/NqBLIW qvuSfrOkjl0fxKzl5HfubsC+hYppYkotak4MHS8UzoFvCCK1kejvtGIJ+hlNqEg6BEKEr8fhpB7 CP/C+NhphOoOCayWeINlsCSceNZpBBCgr/ZeJtH+VTp3gG4Rr06cSR/Ke+58OWpQv9g== X-Gm-Gg: AY/fxX4mwH5T+X5cH33cUDnLZ0U0vPFe+0JJL5sO0aGmYkmMi1T3wmsg4ItOnXwh3dF qvRas6DGQUNn7/kAdOeNTPWl3fuFjIcXx8vw3FsxxM54fVIneDrZRFKo1+d5/h8bOzm4oPbk8BU n85s56H84f+nCWlplpC6lQHybmm0jhPI2rqVKycwYLiuvXi96+rupT/Q8PFlvqcsi/AHk29nrDR xry9D4COOCXO1lt+wok7aoyHkfn9peAn7mIrkgOwQVpzsOlbwmx4VexKdCoCIs737paa4JA0oh7 Acvig17k/DynR9fleCvMGDjvqX7XKRskAdS/qWpvjmJsymNJQ6oGed3UiMdIJlMnjUOcBTcMu5x y9nPqzZugRTWiAOxNG44GOsqVheQMrNwKo5SvrBx4+Q== X-Received: by 2002:a05:6122:c8d:b0:563:6012:53b4 with SMTP id 71dfb90a1353d-563a0a4882dmr1479702e0c.16.1768420163797; Wed, 14 Jan 2026 11:49:23 -0800 (PST) X-Received: by 2002:a05:6122:c8d:b0:563:6012:53b4 with SMTP id 71dfb90a1353d-563a0a4882dmr1479698e0c.16.1768420163404; Wed, 14 Jan 2026 11:49:23 -0800 (PST) Received: from crwood-thinkpadp16vgen1.minnmso.csb ([2601:447:cc81:56d0:ab94:b2cb:29a6:7ac0]) by smtp.gmail.com with ESMTPSA id 71dfb90a1353d-5633a20a183sm23841288e0c.9.2026.01.14.11.49.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Jan 2026 11:49:23 -0800 (PST) Message-ID: Subject: Re: [PATCH] tracing/osnoise: Fix OSN_WORKLOAD-related crash From: Crystal Wood To: Tomas Glozar , Steven Rostedt , Masami Hiramatsu Cc: Mathieu Desnoyers , John Kacur , Luis Goncalves , LKML , Linux Trace Kernel Date: Wed, 14 Jan 2026 13:49:17 -0600 In-Reply-To: <20260114123547.583859-1-tglozar@redhat.com> References: <20260114123547.583859-1-tglozar@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.56.2 (3.56.2-2.fc42) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Wed, 2026-01-14 at 13:35 +0100, Tomas Glozar wrote: > A kernel panic was observed in the timerlat tracer with the following > reproducer: >=20 > #!/bin/bash > while true; do > rtla timerlat hist -u -d 5s & PID=3D$! > sleep 2 > echo OSNOISE_WORKLOAD > /sys/kernel/tracing/osnoise/options > rtla timerlat hist -k -d 1s > done >=20 > The kernel first displays several WARN traces with the following pattern: >=20 > WARNING: CPU: 1 PID: 1822 at kernel/trace/trace_osnoise.c:1959 stop_kt= hread+0xb7/0xc0 The line number doesn't match up for me; is this the first or second WARN_ON in that function? > and finally a null pointer reference BUG: >=20 > BUG: kernel NULL pointer dereference, address: 0000000000000030 > ... > CPU: 1 UID: 0 PID: 2155 Comm: timerlatu/1 > ... > Call Trace: > ... > ? timerlat_fd_read+0xf2/0x370 > ? timerlat_fd_read+0xee/0x370 > vfs_read+0xe8/0x370 > ksys_read+0x6d/0xf0 > do_syscall_64+0x7d/0x160 > ... > entry_SYSCALL_64_after_hwframe+0x76/0x7e What's the actual fault location? And those ? lines in the call trace are "considered to be additional clues" rather than actual unwound frames; what was in the ... above them? > static int osnoise_options_open(struct inode *inode, struct file *file) > { > return seq_open(file, &osnoise_options_seq_ops); > @@ -2229,6 +2254,10 @@ static ssize_t osnoise_options_write(struct file *= filp, const char __user *ubuf, > if (option < 0) > return -EINVAL; > =20 > + retval =3D osnoise_validate_option(option, enable); > + if (retval !=3D 0) > + return retval; > + > /* > * trace_types_lock is taken to avoid concurrency on start/stop. > */ Shouldn't this be done under interface_lock to avoid concurrent timerlat_fd_open()? FWIW, your test script doesn't appear to cover the case of option setting racing with timerlat starting (due to the 2 second delay). Of course, this is complicated by stop_per_cpu_kthreads() happening before interface_lock is acquired. Do we know why that happens outside the lock? That might even be the actual cause of this bug. Though even in the non-race case, we might still want to return -EBUSY rather than just killing the thread (which might still have races since we don't wait for the user thread to die). -Crystal