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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id CB6C6C004C0 for ; Mon, 23 Oct 2023 16:17:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 663C16B00EB; Mon, 23 Oct 2023 12:17:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6143F6B00EC; Mon, 23 Oct 2023 12:17:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 503A56B00ED; Mon, 23 Oct 2023 12:17:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 3F23A6B00EB for ; Mon, 23 Oct 2023 12:17:27 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id DE1868029E for ; Mon, 23 Oct 2023 16:17:26 +0000 (UTC) X-FDA: 81377231292.21.7786EF2 Received: from mail-pj1-f53.google.com (mail-pj1-f53.google.com [209.85.216.53]) by imf02.hostedemail.com (Postfix) with ESMTP id E7B8B80010 for ; Mon, 23 Oct 2023 16:17:24 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=hEXmV2wy; spf=pass (imf02.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.216.53 as permitted sender) smtp.mailfrom=andreyknvl@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1698077845; h=from:from:sender: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:dkim-signature; bh=C2cbWsLkEimzOV8VOGRLrBW3hA2WqDn8Mgiw4dAIqPI=; b=UheYNo3peynD5XKUmxq9/euNg/+K2x8mEI7A9CFWsIaGbkOWtBEDPJINWrFdGo2BUcGZFx oU01V4Yg1vq+JwER7W8X7VVkviV8/QVylesIGVgPuE0DuxwEgZXYr+b7hoK5pLioY0E4n1 EYUpON05u2liMqqxVPkQdGu4hSnl/zY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1698077845; a=rsa-sha256; cv=none; b=I/wTHM1XC9jQrhmI83gvFS9eqI/W8tutezwydUEHY5L5mUSjKPjH1mJIhIkbOD3sBVNHwm 2XyyTZnc9EwwuagQ5xOG8Od8nSGH/dSsm6mmg4MyPIBEzgednfKYVArFxWvElUvn7rFwWK 3Wu2E93NrOBW36LxFe2ecyQB7Rfjh7U= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=hEXmV2wy; spf=pass (imf02.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.216.53 as permitted sender) smtp.mailfrom=andreyknvl@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pj1-f53.google.com with SMTP id 98e67ed59e1d1-27d45f5658fso2747120a91.3 for ; Mon, 23 Oct 2023 09:17:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698077844; x=1698682644; darn=kvack.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=C2cbWsLkEimzOV8VOGRLrBW3hA2WqDn8Mgiw4dAIqPI=; b=hEXmV2wyKTT3d/XACnalKtCk8cJ8Q+BQtbdg7KNWyrVuYcpO3cMqKwuhQv8cJ60tYZ Ey5uaVINQ6oxsqE6BXvnwEffKb2s+SqOKom6d1J5MOY+L5Zcj7tfb7l3741U+nWN05JD 3i+4iBs2v2glgwxP4gCHh09N+R5gWJCnXU7izllQBEP45UvX2EXn3H8Bjf9sqzrwJYlp NhCvuRSa+AIIkDA86ApaHsb5xsH1mH69Y8wMeXLYJY4KiE+60KRHhK8Up7nt3ZpOF5+f AIukKaIbsE83gcpM8vPaeTuHuXf7UUDQvTDTtpMgfvWBmDkTUAEELAgYQTdAFqa4WnQh 1Yaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698077844; x=1698682644; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=C2cbWsLkEimzOV8VOGRLrBW3hA2WqDn8Mgiw4dAIqPI=; b=JAcMxM7aY0MuAHjAEzfNCeqq9XXxodk4qbD9Mha6t9FRy2OCUf3rqkbY5ZawoyS3i6 ILWG8RxOdeoN1rwxf7phCPdHf2Ar2fmmfn5U7h1cYAJrixq3jPvZtx2brT/0uoAy39Lx 3Z4LtXhHj7ubd7IWxBeG1JHKOPUvZN3so+zxBOSpHE/PdmdCXf8Qvzh22Q/7PTEDNZFH xW2NmtaCwdjS5rvCahW1Zc3nkNILFx7onXxZTb9bBdZvkcvSFMr5Dl8MEaqSoH/FfFEO yk5nQrib3sCUC57gu4J36pAZ4drUpMT8CARIiTk8flXLWu2KH2XBHcLupLflj0/Hc10j k0pA== X-Gm-Message-State: AOJu0YyOR38qNpb34HhNF8TMSYPkOyUeGU1p94jkOC4u7Plp03EdTaAc IAmhrk+7gLhNE26Uiyqvb56KtBQEEBicWWfyd20= X-Google-Smtp-Source: AGHT+IHmkmexFrpXT+y685LcLGsklhAo1rSt/kwMGisuvPhgKGqZBvXX7tnRoPriqrQzB8y1oac43NgDlIwm4SZr/d8= X-Received: by 2002:a17:90b:1098:b0:27d:54b9:c3d4 with SMTP id gj24-20020a17090b109800b0027d54b9c3d4mr9572424pjb.1.1698077843855; Mon, 23 Oct 2023 09:17:23 -0700 (PDT) MIME-Version: 1.0 References: <2a161c99c47a45f8e9f7a21a732c60f0cd674a66.1694625260.git.andreyknvl@google.com> In-Reply-To: From: Andrey Konovalov Date: Mon, 23 Oct 2023 18:17:12 +0200 Message-ID: Subject: Re: [PATCH v2 14/19] lib/stackdepot, kasan: add flags to __stack_depot_save and rename To: Alexander Potapenko Cc: andrey.konovalov@linux.dev, Marco Elver , Dmitry Vyukov , Vlastimil Babka , kasan-dev@googlegroups.com, Evgenii Stepanov , Oscar Salvador , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrey Konovalov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: E7B8B80010 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: obyj6p14mtr9pherowu9annb98ntokci X-HE-Tag: 1698077844-340234 X-HE-Meta: U2FsdGVkX1+2hxChizl4LiZfbz/e8GvTRqmPM/wydX9qQDzzpWe+wcbeTkQR9VwRWxcoBv6Q7HGAHAlDs2hN5qKQFBS+IH/nH++psb9C14w5OPDFiOEPOapapfmN9J6jRZ3HmQ+gSBacUSjtal+f0wex6fsBa8/T0chyWOHll4vG4VtF9fomAR1xSgI5yp5VTRUuIno1qPXttBoISkGxJhVwDuMCOGf5P69Tyoaq2MIQzmE3Kr3C2H0a7YwsYfgX6zH5b9M7SaQppqq8eYgY8YANnFR/0qlY1zkYd7QN+i3scjMOQo+10acJqLdJxp4qllA3XH+7SWPmT77qkITF5YeMz6y6En2noQHOKjqu77p2iNQyppDmoNyvCK4BoiuPru53pk2EdE8ergU45Xj4uZBEraD1U7PYSTAYg4P4co0JBJOchLra8IdI7HDuZEy3EzPLbCHCj+n4cQGAHYyGR7KIk7/oEpVJOYhRS0zyfiyQ+nvok7PiP7jfhz4XbxSclszqG/RgWFec0mPhKAtAJw95ispT9S6pDobTDFsUOLOWF/yy0tX+Qn/YTFT7/Z1ruONU0pPD0x1fzokkF/9+zDcc3zu/ENF062YhXm0PXQ9OlB88SL4G0R8mpYQ4yfvpzOAhbwnAb+D8I3OPohDyW7t9nalZOLIQpFxyfKTnfedIbs+TS1EZ7CgUf4PE/GeHGx62GFoRYvUo79LpfzUPtPHJF5+PeuY4u+iT8kslLfWdM2DZoaaz1GRDOlFSvYszBPuuiMOaAQvNJFuaPNJFFhq/NzFIzwU7uYp18KRD+Ea+tX7EwupOS94AFguBUgO70CePEZqF9GwV+oBU8z5MQTuTDbyeDnfZ6T6EBMprvLwk8taYaWCV1AkPwn03j+J/gQ/Zhix5FZ7xvKUp/JcW5jB3kijNSjCLl9E4Fr4VdQI8zrLuCBjZAg2SR5feW7mCdC1SDwpaJEAEk+ZVbUI NTrjjxV6 eAuB64pUQ6T3LEHwruPPqPkwNpRplG3QW0x6ViyN49ydIhTfPHHf5w0fgGLkDAbE8EqHYL3BwNqvVN4wDuRWN64hgCObmoX+DkK00rLvAyJxU5zijpo1/QJaqB3Ub59hHrg692Xr0tIlEiN2Pvsrt2eaBLcRbPjW/8pUh6jDsy2ktfCQBOeO4gAyZ98/nHwJdsLD+mnQ/3R6/R8Loa8C/YTynHwYOdS5PMtwVSCZwbtl9bKC/IkAF3MOVXVuAKbq1EHYUyjQy2sHxAkayuEqRlb2rdFN70U/2TsSmuSYc+COUN3/YL4gMfzO8ZgJ8ZEONzPNV5KL2g1wEwEynbmOEHR09WQCl7PS6rQ7PBYYHIxJ6ea4BTguzRJnq9+yOyKQHlzf/xdyUyCNndmt2g76oTwoDRk1DLn6VAcOZOADn1DF7LtDaEzvHZvTUQrsHKlCYoRsNQbR5MQkRGsE= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000103, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Mon, Oct 9, 2023 at 12:10=E2=80=AFPM Alexander Potapenko wrote: > > On Wed, Sep 13, 2023 at 7:17=E2=80=AFPM wrot= e: > > > > From: Andrey Konovalov > > > > Change the bool can_alloc argument of __stack_depot_save to a > > u32 argument that accepts a set of flags. > > > > The following patch will add another flag to stack_depot_save_flags > > besides the existing STACK_DEPOT_FLAG_CAN_ALLOC. > > > > Also rename the function to stack_depot_save_flags, as __stack_depot_sa= ve > > is a cryptic name, > > > > Signed-off-by: Andrey Konovalov > Reviewed-by: Alexander Potapenko > (assuming you'll address Marco's comment) > > ... > > > void kasan_record_aux_stack_noalloc(void *addr) > > { > > - return __kasan_record_aux_stack(addr, false); > > + return __kasan_record_aux_stack(addr, 0); > > Maybe make the intent to not allocate more explicit by declaring some > STACK_DEPOT_FLAG_CAN_NOT_ALLOC =3D 0? > (Leaving this up to you) The next patch adds another flag, so STACK_DEPOT_FLAG_CAN_NOT_ALLOC is probably not the best name. I could add something like STACK_DEPOT_FLAG_NONE, but I think this might create an impression that there's some kind of NONE flag that affects the behavior of stack_depot_save_flags in a special way. I think we can just keep the value as 0, as it seems what the kernel does in similar cases. E.g. for slab_flags_t, the kernel passes 0 to kmem_cache_create when there are no special flags required. Thanks!