From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-vs1-f48.google.com (mail-vs1-f48.google.com [209.85.217.48]) (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 B2CCB3254B2 for ; Tue, 24 Mar 2026 16:25:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.217.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774369546; cv=none; b=tD+a3EUuZmYmI47r8tZqB4tNmSwWzyDXnoNlqq0h+MkIxM6XkdHrfibKKfwlhPjaJe05Wp1iZyg59+bwWWwrvsclI/Q+rAEnU8Pf8foYvcvT0sXG0za0MjtjeLA2SQW6p50CkaYA+JDAPysJ2vBTuTUdHku+UvzNDcIcLjNzq3I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774369546; c=relaxed/simple; bh=umbu5XMNlyJcsqFhcPDOZdhpLU852xUtSMJl2tqDjdo=; h=Date:From:To:CC:Subject:In-Reply-To:References:Message-ID: MIME-Version:Content-Type; b=rg/oHqlHI7ij2FLR/GGcWhw2iI1NYCnZaCkE7KGikVn2DlE4wHiVmPsC5SjI/ZuKVjLCgcTWQB7MP2eXccR0gACknx7b97+llqfLG02zjuY1M0n1LD7N8xTSUUqBHtvGRSV/m8fIuUZINypGPlu89yTDQj9mbJYI+OfLPe1xdbY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=OArtkWVE; arc=none smtp.client-ip=209.85.217.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="OArtkWVE" Received: by mail-vs1-f48.google.com with SMTP id ada2fe7eead31-60328744770so192037137.2 for ; Tue, 24 Mar 2026 09:25:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774369544; x=1774974344; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:references :in-reply-to:user-agent:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to; bh=SF+35iAoaWQoSu8dn10Qg0Pl0nyBBvu5CxHeL1mOI2w=; b=OArtkWVE2fcTBnc5d3KXcQbHKT4waM1EurjfQLEoG/so2OAXI0xgTPGs0WC3rM5V31 JURpU9Eqx4wt2yTu+OTjMa9M6PliYVs7+WE9SInJxSJhWHUm8URiMyBnGAce6qlNu2ov g8EENWL5yM1hJHJfNmL7odJPAZDBIvH7oaPJL+C+30BJKSUe67MSxzFQ3HN8xpCHuTa2 20LRjlyj08QK68BA5hWlUiPpB+uNKRr5vP6bpqTiNmasroFOqATKFI1gM8HVtM434XqF NdGG2gKYvzV5sCjMGr1XZuiTMkl/rGdXTPiJsUm21UXcC8s6CacBa5Nzd74GVC/6WA5o FUDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774369544; x=1774974344; h=content-transfer-encoding:mime-version:message-id:references :in-reply-to:user-agent:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=SF+35iAoaWQoSu8dn10Qg0Pl0nyBBvu5CxHeL1mOI2w=; b=mNH6gvJzWDiwIN3MEmRJ7ZMKYiDqhmpnf9iGYyKn1j8eLEDf6wl56TPZ4Cy1aTkk/d HcPc/RI/smyY1zELkEzpftE9Nfw69PuXbRmN7kyUYaSHfUkck5Pf5g+FDSEXmjY9T969 fIZhD2++c4KC5efBCMpef5paKW/GzfzYpVlFJp3FqCGtRgt11Xztjrdp9cfY/F1M4jgk 1WswbqEdQx+F9RYgvG/nVSos0BRRNSzqYaqTI1IGhP0id6ycHPW/C4rns3FdLx6A4tIr Rk5MRF1EA1VtBw6kCTUVWW/ZS67VUJ4WiCNL8sONTRnFyFbuy/qaZyp/7LZnI4PM+iSP o0HA== X-Gm-Message-State: AOJu0YyBKyGhdEGS3bccSwkekrPx/K0oMOgGRFh9rlB6ZD6ahyLgCbOP Rxk+24MLcN46D5H4tReaeXga0wtEW7qJNqYVILOKXDMcpnu5EreAZpfF X-Gm-Gg: ATEYQzz83jQVbUuy9qoN44tBU0KRQ5w1dKRI/OX7/nG+FItO/NDzzTvvqpH83MgRWvH 7Cqwfsr3obLmrFbp6qkLyFYbtSVchhlHA8L2LcueIE6zDhxavFGzshYvaqIqFgu00AgEaN7b+KI cJjO5NeKNDu7kxH2KU0kr6KEju67icl+mSw8ir8JRUGqCYx+62NyuMarqdUn3t3gFqJyhyw5zV5 icx4Rv4l+Ml31eOvTw6HNIXLSkpQeoOtYCLrXWoHpvUR4FfJXFbe1EDaFCMMEivCZBr5ZLWSzlU IKms5qsEKUqkgoa+duQxBmL8JE9SPpaxh59meP98zgEnP34T88Dua649uM0f73zhc0eYnIV9JQv 36r8A9NO+gsWLWIf2TQdlwCVET9uttnxa5G1gv2dmKFZt1Rey90AZ9tIz5w5XR1n7TMkQR4z5cU pzoMWRqWEa+ivp2e/9d4wZOLGLFdVxo8lnXhA= X-Received: by 2002:a05:6102:41aa:b0:5ff:ed38:187a with SMTP id ada2fe7eead31-60378fd6a1cmr304420137.5.1774369544431; Tue, 24 Mar 2026 09:25:44 -0700 (PDT) Received: from ehlo.thunderbird.net ([191.58.103.69]) by smtp.gmail.com with ESMTPSA id a1e0cc1a2514c-95136bb0901sm12732964241.4.2026.03.24.09.25.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 24 Mar 2026 09:25:43 -0700 (PDT) Date: Tue, 24 Mar 2026 13:25:39 -0300 From: Arnaldo Melo To: Linus Torvalds CC: linux-kernel@vger.kernel.org Subject: Re: [GIT PULL] perf tools fixes for v7.0: 2nd batch User-Agent: Thunderbird for Android In-Reply-To: <1DCCF693-8FF4-4567-B0BB-41F00B0B4606@gmail.com> References: <20260323105725.1882966-1-acme@kernel.org> <1DCCF693-8FF4-4567-B0BB-41F00B0B4606@gmail.com> Message-ID: 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-Transfer-Encoding: quoted-printable On March 24, 2026 1:17:18 PM GMT-03:00, Arnaldo Melo wrote: > > >On March 24, 2026 1:12:08 PM GMT-03:00, Linus Torvalds wrote: >>On Mon, 23 Mar 2026 at 03:57, Arnaldo Carvalho de Melo wrote: >>> >>> tools arch x86: Sync the msr-index=2Eh copy with the kernel sour= ces >>> tools headers UAPI: Sync linux/kvm=2Eh with the kernel sources >>> tools headers UAPI: Sync x86's asm/kvm=2Eh with the kernel sourc= es >>> tools headers: Synchronize linux/build_bug=2Eh with the kernel s= ources >> >>So I think we need to come up with some solution to *not* do this all, >>because honestly, it's getting hugely annoying=2E >> >>And it's not annoying due to the unnecessary diffs per se, but because >>this tool header sync then causes 'objtool' - which also uses some of >>those headers - to be rebuilt, and then that causes *everything* to be >>rebuilt=2E >> >>Just because the perf tree decided it needed to sync headers for >>unexplained reasons=2E >> >>The docs say "this works surprisingly well"=2E That *used* to be the >>case=2E But with objtool also being affected, it really does *not* work >>well at all=2E >> >>And no, the tools cannot use the kernel headers directly=2E That >>*really* didn't work well, and required synchronizing kernel changes >>with tooling changes, and was just a pain=2E >> >>So the "header copies" solved a real problem, but we need to figure >>out something better=2E >> >>And honestly, the "something better" may be to just remove the >>mindless check for "headers aren't 100% sync"=2E >> >>Because 99% of the time nobody cares=2E This time, for example, the >>header changes in question were comments and stuff that was inside a >>__KERNEL__ guard=2E >> >>So how about just at least as a first step trying to remove the >>warning that is actively detrimental, and only do header syncs when >>there is a *real* reason for them? > >Yeah, I agree, annoying, I'll work on making this opt-in, i=2Ee=2E no war= nings by default, a new target to check if drift happened=2E=20 Also maybe this is something for Sashiko or some other AI agent, to automa= te/suggest/do the sync when it makes sense and not just out of making it is= in sync no matter what=2E - Arnaldo Sry, the previous reply didn't make it to lkml :-/