From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f44.google.com (mail-ed1-f44.google.com [209.85.208.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CEE3828B4FD for ; Mon, 11 May 2026 15:04:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=209.85.208.44 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778511870; cv=pass; b=dpvNCZL8wuq9N6y8XkJjiEEajZnQEzNVW8GsHQ6qWX/FynURgBhUWq9pabS1xr37/kiAao/mhB94VHfj0fDLHPFwEe+j7wQrx+ZeRxwt2lExUXrGOZh4GJfCDg0IC9M4C8uXxw8d+KwKGuanVgZj2m+G9iTOWMbYsBBiWjIA/fo= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778511870; c=relaxed/simple; bh=fjqFc0BNhDw5mbgBHGwtX4HK+RfHN8UBHnr0DLZIHW4=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=BdhLGcLav4cMprcng9e1Q7KSeuGU7jGq223ZXk75Cl4hsDlkAM54mgxCF3Z01M1OfRx38kkaZUEG6XkfaP5n0CXhWdlsPSvkBZuuUIxQyLlBkWNveSpt6cyc22YDUMvqCrtkBQaYt/eL7RrFXfWiGVL0hIHW/1Nrxb3TRFrEjqE= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=KwU58Fo2; arc=pass smtp.client-ip=209.85.208.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="KwU58Fo2" Received: by mail-ed1-f44.google.com with SMTP id 4fb4d7f45d1cf-67c1eea6b4dso76a12.1 for ; Mon, 11 May 2026 08:04:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1778511867; cv=none; d=google.com; s=arc-20240605; b=dLatpoPig+Lnd2K7nCZxMjmIfo++OEuoEc33WMencPneZINfVTXNtLF0aQ4O9eyi27 BD2kxAZ7mhCJS2QNSHb1wbkPU5dlpAU5fGZUBshI58hPRcwl6MNGz2zzF3Q1r7RucUie trdwYdvrrV8+Asuw89aSzRT5elN+0rZlX9vWMWvEeylz6ootm+mEQ3sNCRUNnM+B+B+a 1+7q2G8kbvaYAs247MOVfRYesdY7tsgwpFrPUq8bW/Fx/wYLJ0fQxMk8Sv13w3YZVm+n Q9hDeNy9g/G7lz0qatap7eLBkX5NB5qFqRz/rYMH+94+lyE5DXnvzEdNcqaIoafuMn7g JVqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=liKl1xJRPHzddZaYu1RtDonn0tqRZWTn4IN1tfBXPW8=; fh=JzvplseTe5X7kfnIuespA8fg04cy02YW6obzq3/ZnIk=; b=GF5wYYe5PyNJbNerPad8itHXIRpcFBOQpSzgW7cnDZ6I3L4OYq72Qyi3u8HZ51gMrF b7IXZ4kOTF9nA2hfwAc/AiXDNWDa8ubkR1Bte+y6yagbV1eNgrNOA8SqvOVtn3Oz2aeq 33yWrxNuyQeOBV2vCmIk325ublJw8jRimb9L1eE/A4RBHuMn/ilgtOTDzHf0Pxyr14m6 CCaT+vAFZoQXY4bTIe3CLiU/IscvWiPtqTn8vkEwWQUQVshrYCQYOc/Zb7N1Y3mMcSvN tErmSTJDUtfBfDBRlIoSEqyNYfrxn+H6+4UEgrc5/Dl3sF2smnP8CFLlTPJuM1RQU95T DJAA==; darn=vger.kernel.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1778511867; x=1779116667; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=liKl1xJRPHzddZaYu1RtDonn0tqRZWTn4IN1tfBXPW8=; b=KwU58Fo2AjZGzZzZSCrEC9WiErRBjyTvOU2UF2mc4khpy1YoTgrnQe1VuNNu0bfFZ+ mCJDbunl3d0laqzmjH8LGLS6EhQRI33HTN1okrDXY7WFWX0nZ3zAz++YXkYFUUN7ddRH Hq37Ih92wwqPjbSFFk2D/BI442plNsp4fb/LHuXeQ6xTldyPjsobLXku3k4CC6BRWwpK m33EsBJra1XemzeeoZjcjVMwUK2MVE3LPY2g/nmVsSmVcbw6VkeRmDWMo9sNjMOQlxrN QoyOKgIt6bApSotGFUyKb5iZO7rwgiYDseewxOlpWXIvIVeuZUZ0C7QRwb0GcDC1K1VI GvAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778511867; x=1779116667; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=liKl1xJRPHzddZaYu1RtDonn0tqRZWTn4IN1tfBXPW8=; b=W09N3+UA8+h4+k18IwZlXDnZcb7waxyFqclajnI83Dn+WJPdcA4dqK4wkQsP4sQ5dv MXNMxlnHr99elXC5PkHpK7h8xjJjwylkdnQqckDZl/d2NSyDYRJs5p124MGuEOg6d55Y PaA8pkmKqeWHQdW4ikSUVDlJUwjPF9kGzzOktkg+uybilsJJRTqVQ5n9DGLOgUGUc2LM Tg2CRdAc9j7Rdez9o8KxI51gOpzTBNnu12YkbQ/BMUyRo97bGbZpxUsigf3c0pXcsC1x laYj5lfS5ZghEQ2da/GO2qcgmlYto4thzYON+IafsJyuc2HFpDPNtPOOdXW9lSqBk7aU 3SbA== X-Forwarded-Encrypted: i=1; AFNElJ9kZN+NuWcd62u7qCPO8URs95halrKaCpEdiN4CDrSpqtdv6DU2bKIOVCULPzgG63kmi5GyPEm0DMZZm8w=@vger.kernel.org X-Gm-Message-State: AOJu0YwULDB5PMD9HoBGkYE13GxqcqwPzh+2mGtycWpgHOZgW/r53dMG CbJczBKIzHNUYYhl/4WEQprhvwtu9rnV+o3G2zRVcQSBKOookGJAtxn6VYLU+B12ICbJrkDGkqX BfqzNXUj5jGgDIPMmY9/PNQzczUEcpTMpST9iAlND X-Gm-Gg: Acq92OHfymP7WbuR8C/xFa5efKxLTJdWS6jml4tGmFb0N2qZRu/5OaREUItdyrMqwTf WGa0lVwgHzpM0aMQ92XKYycxdQq6d6DqOuok2XIzFMNwXBPJuYo7pzKkQmiFbbhCU03vVGKOp+V T7NwRomUoKz7QNM9MC/Ezmm5sRLeu8C2PN0/EeLRh6hCYBcT0hY+1fDS5Q+cU2aTtZ0zi5mV6ry i3rn7b+D4hQeVWAKy8jt3jJ01+dgnNdMOh9UyqTwhYTGATmn9U40/xvMUSr9f73+kubYF9av3Zm xZen/M8y9mwDV80uUDOqeVnNZ/Kxy+s+XZO8G9rEeBWIOEbK X-Received: by 2002:aa7:c711:0:b0:67c:f3b6:5fef with SMTP id 4fb4d7f45d1cf-67f5a7710f1mr107035a12.6.1778511866581; Mon, 11 May 2026 08:04:26 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20260505-kcov-simultaneous-remote-v1-1-a670ba7cefd2@google.com> <20260508182358.8a7775b2bfe0211c87278484@linux-foundation.org> In-Reply-To: <20260508182358.8a7775b2bfe0211c87278484@linux-foundation.org> From: Jann Horn Date: Mon, 11 May 2026 17:03:49 +0200 X-Gm-Features: AVHnY4Il-V8anjdc8IfhUGYKDzDZv74Od3lDz9ksT0O9J-rHRh-Xw8D_A7gxncs Message-ID: Subject: Re: [PATCH resend] kcov: allow simultaneous KCOV_ENABLE/KCOV_REMOTE_ENABLE To: Andrew Morton Cc: Dmitry Vyukov , Andrey Konovalov , Alexander Potapenko , kasan-dev@googlegroups.com, Marco Elver , linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, May 9, 2026 at 3:24=E2=80=AFAM Andrew Morton wrote: > On Tue, 05 May 2026 11:00:46 +0200 Jann Horn wrote: > > Allow the same userspace thread to simultaneously collect normal covera= ge > > in syscall context (KCOV_ENABLE) and remote coverage of asynchronous wo= rk > > created by the thread (KCOV_REMOTE_ENABLE). > > With this, remote KCOV coverage becomes useful for generic fuzzing and = not > > just fuzzing of specific data injection interfaces. > > > > This requires that the task_struct::kcov_* fields are separated into on= es > > that are used by the task that generates coverage, and ones that are us= ed > > by the task that requested remote coverage. To split this up: > > > > - Split task_struct::kcov into kcov and kcov_remote. kcov_task_exit() = now > > has to clean up both separately. > > - Only use task_struct::kcov_mode on the task that generates coverage. > > - Only reset task_struct::kcov_handle on the task that requested remot= e > > coverage. > > > > After this change, fields used by the task that generates coverage are: > > > > - kcov_mode > > - kcov_size > > - kcov_area > > - kcov > > - kcov_sequence > > - kcov_softirq > > > > Fields used by the task that requested remote coverage are: > > > > - kcov_remote > > - kcov_handle > > Thanks, I queued this for testing while we await reviewer input. > > checkpatch asked: > > WARNING: Using vsprintf specifier '%px' potentially exposes the kernel me= mory layout, if you don't really need the address please consider using '%p= '. > #141: FILE: kernel/kcov.c:463: > + kcov_debug("t =3D %px, kcov->t =3D %px\n", t, kcov->t); Yep, I saw that when running checkpatch but decided to leave it this way. I didn't introduce that line, I just moved it around; and other parts of kcov use %px to identify the task as well, so changing just this spot to %p would be inconsistent. I guess I should have noted that below the patch... (And kcov_debug() maps to pr_debug(), so these things will not normally show up in the kernel log.) > and Sashiko found a femtobug: > https://sashiko.dev/#/patchset/20260505-kcov-simultaneous-remote-= v1-1-a670ba7cefd2@google.com Hm. In my view, this isn't different from the previous behavior - if the state is broken, WARN_ON() will print a warning and the function will bail out immediately without dropping references. I think if we hit a WARN_ON(), generally this means some state has been corrupted and/or programmer assumptions have been broken, and it doesn't really make sense to try to go for full correctness (dropping references properly and such) because the system is already in a state the programmer didn't consider. Instead, I think it's best to not touch the broken state, and prefer leaking memory rather than potentially making things worse by dropping references (which could make the situation worse and cause UAF or similar).