Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 27 Oct 2022 10:43:15 +0300
From:   Dan Carpenter <dan.carpenter@oracle.com>
To:     Liam Howlett <liam.howlett@oracle.com>
Cc:     Lukas Bulwahn <lukas.bulwahn@gmail.com>,
        Matthew Wilcox <willy@infradead.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>,
        "kernel-janitors@vger.kernel.org" <kernel-janitors@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "maple-tree@lists.infradead.org" <maple-tree@lists.infradead.org>
Subject: Re: [PATCH 0/1] Dead stores in maple-tree
Message-ID: <Y1o2k+2PTMJ2X9QA@kadam>
References: <20221026120029.12555-1-lukas.bulwahn@gmail.com>
 <20221026142259.mvcbtmj3kde5y25g@revolver>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20221026142259.mvcbtmj3kde5y25g@revolver>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?/gRPlDURX+Zt5uQCd+sR40TwjWt17kLWYD2JLsvapc2S3WEKkG7sbdQSz/L/?=
 =?us-ascii?Q?VeYuipXggS4v71u3rjW/cYuKWT3Rrrm2cypre/jRIN6lW5Nj2MdoJOkPGjV4?=
 =?us-ascii?Q?TW/SrLk7lgAs0vR50yvkVpwZQMlQz2BfIrSqWoltfpIfHT3fbERXhN1I4A7D?=
 =?us-ascii?Q?aJVi7Rnv8oXD5ZL7W5Cp6eLXVbuq9jgn7cabKFty9reLIk29F8DoEzkyzU6t?=
 =?us-ascii?Q?CP3gQnUX1utC6QAPInHny5mzO/2srtFXcVaqiBULMLOj7dhevWue2Rv23KOZ?=
 =?us-ascii?Q?uuEhX3yJrHYXUjcRJm9TTjOtzvuES4jkjblhkZxd5Qd0PnYJCsRA++Q5ku3K?=
 =?us-ascii?Q?m499sQc/BpHKdukfodmuUrL9GWQ5WDFQ4lK4hTufWXGMhHYotfh5L6+i6W/1?=
 =?us-ascii?Q?hEjkF1eG9wHHFv5UziRPsu7BDmjSu3YCVsTbFNeBT8Ip4TggWhr0367CaCAH?=
 =?us-ascii?Q?rwPPwBjdxGTwvthqy7xKO1h5rE7Au7iQI4LH+swedsX4TfttBB+aiHFE/mMH?=
 =?us-ascii?Q?74kuJWh0eylqpXUpifIFq262/F25J6PeE1o9NHokfXsIi8qZrPcSG6EECO3u?=
 =?us-ascii?Q?a2IgSjDaFvkYGYcjyzqYhHKx0RENLRlFY0HA5NdyoRk20j2ZXhifWj3OaC9s?=
 =?us-ascii?Q?OD+WVU/+F4EOwIClhbtApLz1tV+Mj1c6c4UOWg+fU8V55PuaNf45v8tIp6ek?=
 =?us-ascii?Q?glqEIDwhuSvpUuqaqIHqalInkQlLbzw0ozlbtHnbw0/VILr8/AFqRRO9Iqn2?=
 =?us-ascii?Q?60bllSaTCTpB/0ilOemGnqFoWjN7llCpcTUUHrw5RsoFM2ftHYxySlIWh11E?=
 =?us-ascii?Q?SsIoONoXZD1dBWq3Bt9W/XHBROmOvwf7DND70RyA8D3ghiN2ib48KxKeqFrI?=
 =?us-ascii?Q?juGJIt8D70YkmeTFJnDDXXbsy3BkE2+qRBAvFoV42dPmdEqELxXOX60/PXku?=
 =?us-ascii?Q?CMupPk3v7aJl7jvnP1NHGqTHhCSTHJtNkRfXq5we0lHJM63Q9gPN010qgWxm?=
 =?us-ascii?Q?9WzEqftii6OCZ/vSwqT9l83wAiTve+qCAvDgcx6Dn94vrO3S0rq38r0e/Qdt?=
 =?us-ascii?Q?S+O6OqRb6VEEeC6foPt8pk6BEaQZwqpFUdsSnMhzc6K0apFbOASIhpbuTFTG?=
 =?us-ascii?Q?BQAcVuR4z4G4/aOE+iZUjZfCwXnFipYyg4NiEn6nZ2tTZwN74gIRe3Hi0yKG?=
 =?us-ascii?Q?7mwRk3dDQU4InkNYWOjGXhsCUQ6FzZ270QJgiJjiiNJdpNHT+i0ixTL2KD8U?=
 =?us-ascii?Q?LF6E6sxNDW3Kfv5PqqjglRHrslPUCqrymCKVx+74FbrKphp6WQ1K6ID8JUwU?=
 =?us-ascii?Q?0JWIi/+tLRj1hToOJkwlJC5d9qHBjB6tNXe9RCM1Glt2df8CaBL5JZmuTr2r?=
 =?us-ascii?Q?b2mDFfZdePNnVW58D+gWg3T3eZmyfoLk8Df+3Cop2CbKOP4qw+h9w69bcZqq?=
 =?us-ascii?Q?vk7q3wVcICOh0e9GsyLQmMZCPi+X4N2RtkkxpXB5loHEnqbGugn75SaDFt2m?=
 =?us-ascii?Q?uGKa0GNjuaRqmO7yaj4OhWbHRjlbU8Nhi/2sOvNYRzFI7V5OVw06BeoFWika?=
 =?us-ascii?Q?NMjkUXXTcAq4nNi3P/tg8gbKjHC9c/5cSJOvHo176IU9JDIZlp1aBlnHuoQF?=
 =?us-ascii?Q?yg=3D=3D?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 631d752d-1d9e-423f-a343-08dab7eef017
X-MS-Exchange-CrossTenant-AuthSource: CY4PR1001MB2358.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2022 07:43:28.6558
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: m1K28hQguFfANkTowP0ZT90jas+DemJhi1CRW/e8NZ97XxC7/IB134gTkE1Xcfme5ps1GnU3SdIL3G7R4BJwiPcAGcNSO2K8UF9/m6oOuHI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR10MB4846
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.545,FMLib:17.11.122.1
 definitions=2022-10-27_03,2022-10-26_01,2022-06-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 mlxscore=0 mlxlogscore=768
 spamscore=0 phishscore=0 bulkscore=0 malwarescore=0 suspectscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2210170000
 definitions=main-2210270043
X-Proofpoint-GUID: jmu-ySgYOcT0KfFZJqGyFaT_1RTNEVM7
X-Proofpoint-ORIG-GUID: jmu-ySgYOcT0KfFZJqGyFaT_1RTNEVM7
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,
        RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Oct 26, 2022 at 02:23:19PM +0000, Liam Howlett wrote:
> * Lukas Bulwahn <lukas.bulwahn@gmail.com> [221026 08:01]:
> > Dear maple-tree authors, dear Liam, dear Matthew,
> > 
> > there are some Dead Stores that clang-analyzer reports:
> > 
> > lib/maple_tree.c:2906:2: warning: Value stored to 'last' is never read [clang-analyzer-deadcode.DeadStores]
> > lib/maple_tree.c:2907:2: warning: Value stored to 'prev_min' is never read [clang-analyzer-deadcode.DeadStores]
> > 
> > I addressed these two cases, which were most obvious and clear to fix;
> > see patch of this one-element series.
> > 
> > Further, clang-analyzer reports more, which I did not address:
> > 
> > lib/maple_tree.c:332:2: warning: Value stored to 'node' is never read [clang-analyzer-deadcode.DeadStores]
> > lib/maple_tree.c:337:2: warning: Value stored to 'node' is never read [clang-analyzer-deadcode.DeadStores]
> > 
> > Unclear to me if the tool is wrong or right in its analysis here for the two functions above.
> 
> The tool is correct but these aren't going anywhere.  They are compiled
> out and are needed for the future.
> 

lib/maple_tree.c
   330  static inline void mte_set_full(const struct maple_enode *node)
   331  {
   332          node = (void *)((unsigned long)node & ~MAPLE_ENODE_NULL);
   333  }
   334  
   335  static inline void mte_clear_full(const struct maple_enode *node)
   336  {
   337          node = (void *)((unsigned long)node | MAPLE_ENODE_NULL);
   338  }

That code is really puzzling...  How far into the future before it starts
making sense?

regards,
dan carpenter