From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1F77BC433B4 for ; Sun, 2 May 2021 19:08:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E7501611B0 for ; Sun, 2 May 2021 19:08:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231801AbhEBTJ2 (ORCPT ); Sun, 2 May 2021 15:09:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50848 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230036AbhEBTJ2 (ORCPT ); Sun, 2 May 2021 15:09:28 -0400 Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7A8F1C06174A for ; Sun, 2 May 2021 12:08:36 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id 12so4899551lfq.13 for ; Sun, 02 May 2021 12:08:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=SIs9uTe9Pw65Rwj0eFe9uFITbVZp4r3OPiPsuStR0zA=; b=DBntENK19cpxww5h8xxfI8MfV8WB71ErCTIAjsOnRpaW2naaVUeUZMiWGsmYwX7cH5 /02ZG8rLNdhQLgReU+yilgFxjYzB8ahoePiXlz3Our0MdM/GS8Ky6PknExmkSn2iKiOB biDw34jXDHHJINRLF40lu+9EnLbmpvAYraAUc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=SIs9uTe9Pw65Rwj0eFe9uFITbVZp4r3OPiPsuStR0zA=; b=N6fJRb7Rq3E7L7kBEn/vLEYYbAexXfOL+TlfgSXj7UPNxByNxurLzNJ8slnyJV72QR d6Dt7i34B262Xy0Vpg3wZpZ55ZtU/TfR/HhzSzaVWfIO8hUhRDpbqsobfoFpA6s88sDB dLGZ0W8QQqxXF161E56HXct9jRZ1fTZIzAdS0EQhnXgU8y23LET26BUm5ja3Y4KLs3oK I3b2DFNi9BGzpUTMsp2Jxdl9R6GHqtxSKY9XgOAD/+Z+Ng4BY/wnHLP6DbENbQm5C7V9 VvcLdH61+G1dE279TSOq+3oZP6prUJw6Xeipa3pnEtanUeug4hzSbUQjTD3ySHdNCIzd 5nww== X-Gm-Message-State: AOAM531HtENFgJKdTtenFDAIuul0mAOiqJdwCyjQTqHHQMYTf2Z9zh9j EiKT2xgwJQQL9sJv9U+A5cRQoZarvPviQHPP X-Google-Smtp-Source: ABdhPJyGZ9OBGUpIj3RLYdzCz8gJq+eo9sQXDq928pjPac9a8wU/iMQ/dLSsO1hi6ZX/mLk/OzyUZQ== X-Received: by 2002:ac2:5098:: with SMTP id f24mr7232362lfm.243.1619982514657; Sun, 02 May 2021 12:08:34 -0700 (PDT) Received: from mail-lf1-f41.google.com (mail-lf1-f41.google.com. [209.85.167.41]) by smtp.gmail.com with ESMTPSA id t30sm793616ljd.98.2021.05.02.12.08.33 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 02 May 2021 12:08:33 -0700 (PDT) Received: by mail-lf1-f41.google.com with SMTP id 2so4953089lft.4 for ; Sun, 02 May 2021 12:08:33 -0700 (PDT) X-Received: by 2002:ac2:5f92:: with SMTP id r18mr10964654lfe.253.1619982513635; Sun, 02 May 2021 12:08:33 -0700 (PDT) MIME-Version: 1.0 References: <20210429225251.02b6386d21b69255b4f6c163@linux-foundation.org> <20210430060049.FrKVS3ZER%akpm@linux-foundation.org> <20210502110456.238c3e175d35e4a6ce8a6088@linux-foundation.org> In-Reply-To: <20210502110456.238c3e175d35e4a6ce8a6088@linux-foundation.org> From: Linus Torvalds Date: Sun, 2 May 2021 12:08:17 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [patch 148/178] kasan: detect false-positives in tests To: Andrew Morton Cc: Stephen Rothwell , Andrey Konovalov , Andrey Ryabinin , Dmitry Vyukov , Marco Elver , Alexander Potapenko , Linux-MM , mm-commits@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk Reply-To: linux-kernel@vger.kernel.org List-ID: X-Mailing-List: mm-commits@vger.kernel.org On Sun, May 2, 2021 at 11:04 AM Andrew Morton w= rote: > > Sorry, I fat-fingered a thing and used gcc-9, which disables CONFIG_KASAN= . My point is that linux-next would have caught it. And that commit _was_ in linux-next. But it was rebased literally just hours before being sent to me, and thus all the testing that it got was thrown away. > > Use the previous release as a base (ie in this case 5.12) > > Not a problem for the first batch of patches, but what base do I use for > the second and succeeding batches? Well, the first batch is usually the biggest and most core one, and in many ways the most important that it would have been a branch of its own, and be something that has actually been tested as-is in linux-next. Ad to succeeding batches.. Optimally if they don't have any dependencies on other trees or the first batch, they'd actually entirely independent of the first batch, and just a separate patch queue entirely, and tested as such in linux-next (and again on top of some previous base). But that kind of workflow would require you literally have multiple separate patch-queues that you test independently. That does sound like a good idea, but it also sounds very much like a "git topic branch" model, and I think quilt basically is a "single series" tool, not able to handle multiple independent series? I don't know quilt, and a quick google of "multiple independent quilt patch series" ended up at a web page by Andreas Gr=C3=BCnbacher that was so old that it was in Latin1 and doesn't even display properly on any modern browser. Which is a statement in itself, but whatever. I'd actually be perfectly ok with being told that subsequent patches be based on top of your previous patch series: I already create a branch called "akpm" for applying all your patches, and while right now it's a temporary branch that gets removed after I merge it, I could easily just keep it around - and then apply your next series on top of it. So the only issues would be the things that actually end up being dependent on other branches in linux-next: > Maybe 10% of the patches I carry are based on changes which are in > linux-next. These are the ones that you'd have to keep separate, in order to not rebase the patches that _aren't_ based on linux-next changes.. Again, I don't know how to do that with quilt (and iirc, you aren't actually using quilt, you're using your own extended version?) The quilt man-page does have some signs that there can be multiple series of patches (wording like "current series" vs "another series", and "Different series files can be used.."), but the actual quilt commands don't really show much sign of switching between different patch series. So I get the feeling that it's more of a "theoretically possible" thing rather than something that is actually supported by the tooling natively. Linus From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3BECDC433ED for ; Sun, 2 May 2021 19:08:39 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A6656611C0 for ; Sun, 2 May 2021 19:08:38 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A6656611C0 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 037906B0036; Sun, 2 May 2021 15:08:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F2AA16B006E; Sun, 2 May 2021 15:08:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DA47B6B0070; Sun, 2 May 2021 15:08:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0073.hostedemail.com [216.40.44.73]) by kanga.kvack.org (Postfix) with ESMTP id B68E76B0036 for ; Sun, 2 May 2021 15:08:37 -0400 (EDT) Received: from smtpin33.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 7170F180AD83E for ; Sun, 2 May 2021 19:08:37 +0000 (UTC) X-FDA: 78097227474.33.9868D64 Received: from mail-lj1-f175.google.com (mail-lj1-f175.google.com [209.85.208.175]) by imf01.hostedemail.com (Postfix) with ESMTP id A94C95001522 for ; Sun, 2 May 2021 19:08:26 +0000 (UTC) Received: by mail-lj1-f175.google.com with SMTP id b21so4284811ljf.11 for ; Sun, 02 May 2021 12:08:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=SIs9uTe9Pw65Rwj0eFe9uFITbVZp4r3OPiPsuStR0zA=; b=DBntENK19cpxww5h8xxfI8MfV8WB71ErCTIAjsOnRpaW2naaVUeUZMiWGsmYwX7cH5 /02ZG8rLNdhQLgReU+yilgFxjYzB8ahoePiXlz3Our0MdM/GS8Ky6PknExmkSn2iKiOB biDw34jXDHHJINRLF40lu+9EnLbmpvAYraAUc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=SIs9uTe9Pw65Rwj0eFe9uFITbVZp4r3OPiPsuStR0zA=; b=Z1tRtImkvYsAECE6qRBwugXugOWV+jQiodH92m49LWNA7ikE4TLkGdGvaL1lG+2EB0 g1et+moWCdPO6Wy40BNBs+YdU0M4lp+Mp+YS/2RXxoEheuACv+WZzzkZlAEdC7L9zuP+ +1NgfwwHzVtQqWsA6xDe9q0qZ0IgIePilb34TTCu8uSjOkOdqEnWmR1j6dBMoa9QpjP6 ebPHteT7rsTQR1nhtghVZ2L+KuTk3vXL5ISDWJundYfdXFuM16ajLyOthmCwfo8kUBZF nSaM+FW0Y6trIq/aevfCfaWWnn/ZlQfURByChPpmuc4HHXgmF4hbmHEdHhvFyBCdvTTg prqg== X-Gm-Message-State: AOAM531QaV3UjGVbCEivGwQcSt4IfTw6egHQz5f0QZKKipdOzlpvFfXd rsvqhatgbMEuC/POqR0yN9sRZY6DAbKne41g X-Google-Smtp-Source: ABdhPJxnhyYxejtUHSQNvZ0u4hTNB12KVpy5MheiI95NdKctg8EBi+Tg5UirRvFXGv+epk0KwDWdkA== X-Received: by 2002:a2e:b16f:: with SMTP id a15mr11527120ljm.2.1619982514910; Sun, 02 May 2021 12:08:34 -0700 (PDT) Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com. [209.85.167.47]) by smtp.gmail.com with ESMTPSA id t9sm915692lfc.136.2021.05.02.12.08.33 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 02 May 2021 12:08:34 -0700 (PDT) Received: by mail-lf1-f47.google.com with SMTP id n138so4960171lfa.3 for ; Sun, 02 May 2021 12:08:33 -0700 (PDT) X-Received: by 2002:ac2:5f92:: with SMTP id r18mr10964654lfe.253.1619982513635; Sun, 02 May 2021 12:08:33 -0700 (PDT) MIME-Version: 1.0 References: <20210429225251.02b6386d21b69255b4f6c163@linux-foundation.org> <20210430060049.FrKVS3ZER%akpm@linux-foundation.org> <20210502110456.238c3e175d35e4a6ce8a6088@linux-foundation.org> In-Reply-To: <20210502110456.238c3e175d35e4a6ce8a6088@linux-foundation.org> From: Linus Torvalds Date: Sun, 2 May 2021 12:08:17 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [patch 148/178] kasan: detect false-positives in tests To: Andrew Morton Cc: Stephen Rothwell , Andrey Konovalov , Andrey Ryabinin , Dmitry Vyukov , Marco Elver , Alexander Potapenko , Linux-MM , mm-commits@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: A94C95001522 X-Stat-Signature: mgh7g8gsupuwapw3hihkyexp8qf6568o Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=DBntENK1; spf=pass (imf01.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.175 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none Received-SPF: none (linuxfoundation.org>: No applicable sender policy available) receiver=imf01; identity=mailfrom; envelope-from=""; helo=mail-lj1-f175.google.com; client-ip=209.85.208.175 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1619982506-499173 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Sun, May 2, 2021 at 11:04 AM Andrew Morton w= rote: > > Sorry, I fat-fingered a thing and used gcc-9, which disables CONFIG_KASAN= . My point is that linux-next would have caught it. And that commit _was_ in linux-next. But it was rebased literally just hours before being sent to me, and thus all the testing that it got was thrown away. > > Use the previous release as a base (ie in this case 5.12) > > Not a problem for the first batch of patches, but what base do I use for > the second and succeeding batches? Well, the first batch is usually the biggest and most core one, and in many ways the most important that it would have been a branch of its own, and be something that has actually been tested as-is in linux-next. Ad to succeeding batches.. Optimally if they don't have any dependencies on other trees or the first batch, they'd actually entirely independent of the first batch, and just a separate patch queue entirely, and tested as such in linux-next (and again on top of some previous base). But that kind of workflow would require you literally have multiple separate patch-queues that you test independently. That does sound like a good idea, but it also sounds very much like a "git topic branch" model, and I think quilt basically is a "single series" tool, not able to handle multiple independent series? I don't know quilt, and a quick google of "multiple independent quilt patch series" ended up at a web page by Andreas Gr=C3=BCnbacher that was so old that it was in Latin1 and doesn't even display properly on any modern browser. Which is a statement in itself, but whatever. I'd actually be perfectly ok with being told that subsequent patches be based on top of your previous patch series: I already create a branch called "akpm" for applying all your patches, and while right now it's a temporary branch that gets removed after I merge it, I could easily just keep it around - and then apply your next series on top of it. So the only issues would be the things that actually end up being dependent on other branches in linux-next: > Maybe 10% of the patches I carry are based on changes which are in > linux-next. These are the ones that you'd have to keep separate, in order to not rebase the patches that _aren't_ based on linux-next changes.. Again, I don't know how to do that with quilt (and iirc, you aren't actually using quilt, you're using your own extended version?) The quilt man-page does have some signs that there can be multiple series of patches (wording like "current series" vs "another series", and "Different series files can be used.."), but the actual quilt commands don't really show much sign of switching between different patch series. So I get the feeling that it's more of a "theoretically possible" thing rather than something that is actually supported by the tooling natively. Linus