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 35285C6FD1F for ; Sat, 30 Mar 2024 13:21:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A57AA6B0083; Sat, 30 Mar 2024 09:21:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A07F66B0087; Sat, 30 Mar 2024 09:21:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8CEFC6B0088; Sat, 30 Mar 2024 09:21:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 6EFB86B0083 for ; Sat, 30 Mar 2024 09:21:40 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id F3AE91C05D6 for ; Sat, 30 Mar 2024 13:21:39 +0000 (UTC) X-FDA: 81953767518.22.BD6BDCE Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf13.hostedemail.com (Postfix) with ESMTP id 090332000E for ; Sat, 30 Mar 2024 13:21:37 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=hJj+IRau; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf13.hostedemail.com: domain of bhe@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=bhe@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711804898; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=wnvnhMuSGBykpK5jfG/3fZk4ulDz//mFCyfnQdVS0v4=; b=bs60Cb13Ym9ko62afBaxf3sjuzMPmYMJVASRM8PrytUydvy6l4KLBS1WnvnPQRJhVyOBW7 1JuCBxX870T/UIX/fyvTOC8IYLQqaFTlT2BOGqry2iyp+rOwPjTNJ/2mjIOrXoyQxVemym p1/hdmLUEArmEsTZv1oAOicGyvHpewk= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=hJj+IRau; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf13.hostedemail.com: domain of bhe@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=bhe@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711804898; a=rsa-sha256; cv=none; b=KpMRsodvfPFBlUz/sTD1tFKbI3xECSdXpA55WKRD6wkkqQWHpjaPLNg4ctWTinGHex/r7W OILe34Ctt07COM/+ZZIvwNTjVoel/pSwwCxs15Swdzx/tIHJBG3jjI00EvzeMaY9PXFR6g bMAHMn2oJdT5Xg70kw7s2ReRgn14eLw= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1711804897; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=wnvnhMuSGBykpK5jfG/3fZk4ulDz//mFCyfnQdVS0v4=; b=hJj+IRauDLV/xK30NdpwD/P7SkuyIrHKQ5WxXkfbokfVnDzuHuGEsSoSHmV49Ihb6s3P6U h9AVJZngc7cgzwjwFAfMBS3aFDjb+DJ3zFgg2Ccemqfthx3FPuBEJ2F15GXml0MVbsKzEW unQfWCnFpWvxNMyA3WjbBV/Qvum+6FE= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-622-0Q0k-nFKMZiDJ1ixXK3iJA-1; Sat, 30 Mar 2024 09:21:35 -0400 X-MC-Unique: 0Q0k-nFKMZiDJ1ixXK3iJA-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 6D839101A552; Sat, 30 Mar 2024 13:21:34 +0000 (UTC) Received: from localhost (unknown [10.72.116.12]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1C6041C060D0; Sat, 30 Mar 2024 13:21:32 +0000 (UTC) Date: Sat, 30 Mar 2024 21:21:25 +0800 From: Baoquan He To: Uladzislau Rezki Cc: linux-mm@kvack.org, Andrew Morton , LKML , Lorenzo Stoakes , Christoph Hellwig , Matthew Wilcox , Dave Chinner , Oleksiy Avramchenko , Jens Axboe , Omar Sandoval Subject: Re: [PATCH 1/1] mm: vmalloc: Fix lockdep warning Message-ID: References: <20240328140330.4747-1-urezki@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.7 X-Rspamd-Queue-Id: 090332000E X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: iy7hpkg56quqcj683ff68ckqytwet7su X-HE-Tag: 1711804897-891249 X-HE-Meta: U2FsdGVkX19s3Cz8bgrgMWRcteJgCAXnZqIsYcCwfmiFPAnehRGBv8cZC7G4AwSQLFuJ37sterJrgFbs9advo5VRzieUoSjcbW0UQvmrFWBSGiWoIeZOzXm7d1l8oUs5/k5kUWclm7S3Q3+XlB48SVoyK3n17wBqr2isbzD8hZ6xBooL0PCoaKCnO/eKtaJMVEIcVOgrQWp3KEzKm95h18mbFhs3jIX0Lv6Uj1h/7nFNR8N1/a0GlHXwgFXtSVCbqP0DGZWikgX6lCbicW6w0Xn3KjsWFrh94F9Clk3giTzOTKjWvJiFZK4H3OIQ9gfPLgoVfUgwpYgk0i8ugxCG9IgMDF1WBptrj5mlQG6iE7VXpEG7FtWGmAok2a5ZhtzFbyWCliEgQ0zkaTbWSZPsBle6w4WB5JfTySkcdnd93p1prnYZFmYXB1A3VeHtDyWIlY9TxhYyoDGqteacGCJ/FeqUkdMyNhseChRlAXfyYhjQps4usF+eVcau5djAnrLPUvuu65ve3IR+cH+D1xtJnrgVVDyWJ634Rw+P3SldPmOOTPsOFk5ha2qPPHPmQLuQ406h2Mzks68nnk+9K2CJcPdSlNTK2nCnkZbLQkDj2jefFqHN2iJeqCM9+BGe+Qxc4zxPwTzMyhnmLwTlXeoUBKvuM0xrTA8TPTYxCLrH59h6mBRddNftmJo/OY7dFyiKRW1Bjdc5AWza8H+sRVFw+tPnOBiV557AvLf9+8/xiRO1NVsmDQ+8FN93kRJ6lGpqB2yibvWyrdTci4G8J+jz2cl4Lru/3iBw0PIUim58bVEN2Fpo+3c3g5Gh7HPeMeKJP/2+nRY5psf/Rv5c+3mgz8n2Tt+VauZnkRPlyqafGG9CulwFecDLl5S8PC0XHbxTWvA4ekj+E37AdEAjD+uMmsVGgM0c9NOnPFRktc0XPzrsC2+0eGTvxnexhYPO4OVlqYXaWuiL+qkouMJJUtf wGx3FGyj WggJltrzk/+6uidhGPo0zkkiC3xrvfXZ1i1FiWZpVr059emBUY8Ud0Eyv6UJUjvkVcS8QxR0aPgc4TRw71oyw7xaus+cJuSy6taHxCWcXpWug6tf7c8MQDY1lVALrgPDANuBecEXgKmVEd3HzF8cbO/oqGKzhdasEu4X848TPvf7Op8ynZNS87w7JtU4/o2u7H1xrIx5ImXM2AUjm7/yEGmltwmSJHcsn4jHQfgK6AvHRnlwdqJr96thdy7jY0WLqfQMH 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: List-Subscribe: List-Unsubscribe: On 03/30/24 at 01:55pm, Uladzislau Rezki wrote: > On Fri, Mar 29, 2024 at 03:44:40PM +0800, Baoquan He wrote: > > On 03/28/24 at 03:03pm, Uladzislau Rezki (Sony) wrote: ......snip > > How about below change about va_start_lowest? Personal preference, not > > strong opinion. > > > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > > index 9b1a41e12d70..bd6a66c54ad2 100644 > > --- a/mm/vmalloc.c > > +++ b/mm/vmalloc.c > > @@ -1046,19 +1046,19 @@ __find_vmap_area_exceed_addr(unsigned long addr, struct rb_root *root) > > static struct vmap_node * > > find_vmap_area_exceed_addr_lock(unsigned long addr, struct vmap_area **va) > > { > > - unsigned long va_start_lowest; > > + unsigned long va_start_lowest = ULONG_MAX; > > struct vmap_node *vn; > > int i; > > > > repeat: > > - for (i = 0, va_start_lowest = 0; i < nr_vmap_nodes; i++) { > > + for (i = 0; i < nr_vmap_nodes; i++) { > > vn = &vmap_nodes[i]; > > > > spin_lock(&vn->busy.lock); > > *va = __find_vmap_area_exceed_addr(addr, &vn->busy.root); > > > > if (*va) > > - if (!va_start_lowest || (*va)->va_start < va_start_lowest) > > + if ((*va)->va_start < va_start_lowest) > > va_start_lowest = (*va)->va_start; > > spin_unlock(&vn->busy.lock); > > } > > @@ -1069,7 +1069,7 @@ find_vmap_area_exceed_addr_lock(unsigned long addr, struct vmap_area **va) > > * been removed concurrently thus we need to proceed > > * with next one what is a rare case. > > */ > > - if (va_start_lowest) { > > + if (va_start_lowest != ULONG_MAX) { > > vn = addr_to_node(va_start_lowest); > > > > spin_lock(&vn->busy.lock); > > > > > To me it looks as incomplete. The "va_start_lowest" should be initialized > when repeat. Otherwise we can end up with an infinite repeating because > va_start_lowest != ULONG_MAX. You are right. Anyway, it's just a suggestion from a different code style, please feel free to adjust it in or leave the patch as is. > > > > } > > > > > > - return va_node; > > > -} > > > - > > > -static struct vmap_area *__find_vmap_area(unsigned long addr, struct rb_root *root) > > > -{ > > > - struct rb_node *n = root->rb_node; > > > + /* > > > + * Check if found VA exists, it might it is gone away. > > ~~~~ grammer mistake? > > > + * In this case we repeat the search because a VA has > > > + * been removed concurrently thus we need to proceed > > > + * with next one what is a rare case. > > ~~~~ typo, which? > > > + */ > > > + if (va_start_lowest) { > > > + vn = addr_to_node(va_start_lowest); > > > > > > - addr = (unsigned long)kasan_reset_tag((void *)addr); > > > + spin_lock(&vn->busy.lock); > > > + *va = __find_vmap_area(va_start_lowest, &vn->busy.root); > > > > > > - while (n) { > > > - struct vmap_area *va; > > > + if (*va) > > > + return vn; > > > > > > - va = rb_entry(n, struct vmap_area, rb_node); > > > - if (addr < va->va_start) > > > - n = n->rb_left; > > > - else if (addr >= va->va_end) > > > - n = n->rb_right; > > > - else > > > - return va; > > > + spin_unlock(&vn->busy.lock); > > > + goto repeat; > > > } > > > > Other than above nickpick concerns, this looks good to me. > > > > Reviewed-by: Baoquan He > > > Thank you! > > -- > Uladzislau Rezki >