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 71924C5AE59 for ; Thu, 5 Jun 2025 06:08:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 146F96B05AD; Thu, 5 Jun 2025 02:08:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0F7E56B05AE; Thu, 5 Jun 2025 02:08:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 00D776B05AF; Thu, 5 Jun 2025 02:08:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id D563A6B05AD for ; Thu, 5 Jun 2025 02:08:32 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 573B4C19D2 for ; Thu, 5 Jun 2025 06:08:32 +0000 (UTC) X-FDA: 83520317664.03.9E58656 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf03.hostedemail.com (Postfix) with ESMTP id E7AA520006 for ; Thu, 5 Jun 2025 06:08:29 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=i+oYi2zU; spf=pass (imf03.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=quarantine) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1749103710; 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=C2vSmJ6SVwQptQL8RpnG9tD7le9Q4uMxXrPnxOmuMhY=; b=KlS4GVi+xXubDAfsFg/Tdpsr5njk37Uv5Ehi5/6dqzDWuu80VZdo4JTmyA45lC9Wijpwjy rgqQOtwNqY+f7eNc/DLDdzfEM4UAleYjMdrrOoRUMQhHq+eFVH78bdlaOVgDn7qflOhn0R j06+jtMeIMGHDiOY2xcWEkFA0d36KfU= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=i+oYi2zU; spf=pass (imf03.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=quarantine) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749103710; a=rsa-sha256; cv=none; b=X1iwTWWaW30aJXq9C+g98UKrINeWS7GEu74kItzTroj7AWzz1MoO+gTgk+WUPDV9wqbaFp 0gRRE/bzWb8UzXkjsY/ArUXzLAljnE4Y5OsId1qERgJZsiHp0p2w4YbHq9896dK4JxlPCO lDU1tt0Yn97OManuXJLlycuBiuuafuk= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1749103709; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=C2vSmJ6SVwQptQL8RpnG9tD7le9Q4uMxXrPnxOmuMhY=; b=i+oYi2zU7ZDcBxVCGzscdgcrWmC/6ir/lxVVmu4Cmmd/vIcrenSqw8scD0Xlkjd7mjhBfM wK78mpkb3WdAmZEWqBwJrso6f2o1KXtYtm4s94qqNg9zxalqbvFh79R5GP3MrOhMJ6MFeL KDgPBWcjeuVybKSF800dR5+rI0C3rVk= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-275-W7-oYEF-MVK4Yw9NwkVD-w-1; Thu, 05 Jun 2025 02:08:28 -0400 X-MC-Unique: W7-oYEF-MVK4Yw9NwkVD-w-1 X-Mimecast-MFC-AGG-ID: W7-oYEF-MVK4Yw9NwkVD-w_1749103707 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-442e0e6eb84so3267805e9.0 for ; Wed, 04 Jun 2025 23:08:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749103707; x=1749708507; h=content-transfer-encoding:in-reply-to:organization:autocrypt :content-language:from:references:cc:to:subject:user-agent :mime-version:date:message-id:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=C2vSmJ6SVwQptQL8RpnG9tD7le9Q4uMxXrPnxOmuMhY=; b=RfvR/3Mr2zjbdZTC8QsWYhVhBCC1vl2qOcIF1xQegN8qkIlfReaX9mV8jpkKAOmkC5 XV0YUwAyDbFvTHiPbVrKqmTI2adx4SyHA7PEEWamOKG1ZuWuOLSGZmFKRDs/HOgeHULr UGkXfMTo1BfvcsB78yrct72YtMYz2VwaD+qFxoggUQPSrkGBKoftwzlXjbxW61QlPEGT qAzaY6e6isGE29pSJzl2Hada3JIKeJbCKKY0z+CHkmBEfZiOKIAECLO90aZbiSfpVcbS zigl+VOISeRiBsX06O8HAvmmvdsvm5VmKuqAeE+uBqd+7J4EkOP7VzS5kGn8E40EwJkV 708Q== X-Gm-Message-State: AOJu0Yydc9AZi/WR0yLdpS4dA6gCbiH/TTiO1ZVJs5T1tTaF9NHI9BWx doDOZm6RFbxqKF5JsDyNj4F4xUvxbV5MnFHvtVJnp1XR4aGRKeHRNCGB/ko+c3u3QvQ4h+UYXcB 9n9a0nDISESJiT3cehOxsg3UcwT9xMnh3DUkK3NYS+7F7HRaNsJwU X-Gm-Gg: ASbGncux5ViREk/gWK1B4URYap/smie3OnEa0YUEnvAnW/URrwZ8EO492E8jIRj8MyP U624ri5UGNmn9yr5cVotrQ1Bh7B4pY5dG55TeVdSkNiRvd9vuOPOmjJlPwidkF+LoVfUoQl6Ewe 5pXFMi9PWEGn1O28lNZT5G8pkx4zvzflkXU0OWw9fUo9/1PMWfg0dXoURRHh6V+AWE96Cc7ok8u JWQCHhC05l4YiADwagjlc6CYOWytTaXqNPpMgaJ/KmCVx2Bffx2f4gU9B6Qr5p8ZvEqiPrIAG9t Owx/nM2UhhK9Pg3Fm7hOyT8yOrNwkmaguPvfwcuPrz5x3Op0A2H1BA== X-Received: by 2002:adf:a199:0:b0:3a5:2923:8006 with SMTP id ffacd0b85a97d-3a529238091mr658705f8f.25.1749103706770; Wed, 04 Jun 2025 23:08:26 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGaRqZBcrBEbzp9Fj3P1o2raF7MjsFUmUAj05+n6Rw0I/Fw2RYCKHcZTTLBoyG3oN0dCtYa/A== X-Received: by 2002:adf:a199:0:b0:3a5:2923:8006 with SMTP id ffacd0b85a97d-3a529238091mr658688f8f.25.1749103706377; Wed, 04 Jun 2025 23:08:26 -0700 (PDT) Received: from [192.168.3.141] (p4fe0f5ef.dip0.t-ipconnect.de. [79.224.245.239]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3a4efe73eadsm23211131f8f.41.2025.06.04.23.08.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Jun 2025 23:08:25 -0700 (PDT) Message-ID: Date: Thu, 5 Jun 2025 08:08:24 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1] mm/gup: remove (VM_)BUG_ONs To: Vlastimil Babka , John Hubbard , linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, Andrew Morton , Lorenzo Stoakes , "Liam R. Howlett" , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Jason Gunthorpe , Peter Xu References: <20250604140544.688711-1-david@redhat.com> From: David Hildenbrand Autocrypt: addr=david@redhat.com; keydata= xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzSREYXZpZCBIaWxk ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT7CwZgEEwEIAEICGwMGCwkIBwMCBhUIAgkKCwQW AgMBAh4BAheAAhkBFiEEG9nKrXNcTDpGDfzKTd4Q9wD/g1oFAl8Ox4kFCRKpKXgACgkQTd4Q 9wD/g1oHcA//a6Tj7SBNjFNM1iNhWUo1lxAja0lpSodSnB2g4FCZ4R61SBR4l/psBL73xktp rDHrx4aSpwkRP6Epu6mLvhlfjmkRG4OynJ5HG1gfv7RJJfnUdUM1z5kdS8JBrOhMJS2c/gPf wv1TGRq2XdMPnfY2o0CxRqpcLkx4vBODvJGl2mQyJF/gPepdDfcT8/PY9BJ7FL6Hrq1gnAo4 3Iv9qV0JiT2wmZciNyYQhmA1V6dyTRiQ4YAc31zOo2IM+xisPzeSHgw3ONY/XhYvfZ9r7W1l pNQdc2G+o4Di9NPFHQQhDw3YTRR1opJaTlRDzxYxzU6ZnUUBghxt9cwUWTpfCktkMZiPSDGd KgQBjnweV2jw9UOTxjb4LXqDjmSNkjDdQUOU69jGMUXgihvo4zhYcMX8F5gWdRtMR7DzW/YE BgVcyxNkMIXoY1aYj6npHYiNQesQlqjU6azjbH70/SXKM5tNRplgW8TNprMDuntdvV9wNkFs 9TyM02V5aWxFfI42+aivc4KEw69SE9KXwC7FSf5wXzuTot97N9Phj/Z3+jx443jo2NR34XgF 89cct7wJMjOF7bBefo0fPPZQuIma0Zym71cP61OP/i11ahNye6HGKfxGCOcs5wW9kRQEk8P9 M/k2wt3mt/fCQnuP/mWutNPt95w9wSsUyATLmtNrwccz63XOwU0EVcufkQEQAOfX3n0g0fZz Bgm/S2zF/kxQKCEKP8ID+Vz8sy2GpDvveBq4H2Y34XWsT1zLJdvqPI4af4ZSMxuerWjXbVWb T6d4odQIG0fKx4F8NccDqbgHeZRNajXeeJ3R7gAzvWvQNLz4piHrO/B4tf8svmRBL0ZB5P5A 2uhdwLU3NZuK22zpNn4is87BPWF8HhY0L5fafgDMOqnf4guJVJPYNPhUFzXUbPqOKOkL8ojk CXxkOFHAbjstSK5Ca3fKquY3rdX3DNo+EL7FvAiw1mUtS+5GeYE+RMnDCsVFm/C7kY8c2d0G NWkB9pJM5+mnIoFNxy7YBcldYATVeOHoY4LyaUWNnAvFYWp08dHWfZo9WCiJMuTfgtH9tc75 7QanMVdPt6fDK8UUXIBLQ2TWr/sQKE9xtFuEmoQGlE1l6bGaDnnMLcYu+Asp3kDT0w4zYGsx 5r6XQVRH4+5N6eHZiaeYtFOujp5n+pjBaQK7wUUjDilPQ5QMzIuCL4YjVoylWiBNknvQWBXS lQCWmavOT9sttGQXdPCC5ynI+1ymZC1ORZKANLnRAb0NH/UCzcsstw2TAkFnMEbo9Zu9w7Kv AxBQXWeXhJI9XQssfrf4Gusdqx8nPEpfOqCtbbwJMATbHyqLt7/oz/5deGuwxgb65pWIzufa N7eop7uh+6bezi+rugUI+w6DABEBAAHCwXwEGAEIACYCGwwWIQQb2cqtc1xMOkYN/MpN3hD3 AP+DWgUCXw7HsgUJEqkpoQAKCRBN3hD3AP+DWrrpD/4qS3dyVRxDcDHIlmguXjC1Q5tZTwNB boaBTPHSy/Nksu0eY7x6HfQJ3xajVH32Ms6t1trDQmPx2iP5+7iDsb7OKAb5eOS8h+BEBDeq 3ecsQDv0fFJOA9ag5O3LLNk+3x3q7e0uo06XMaY7UHS341ozXUUI7wC7iKfoUTv03iO9El5f XpNMx/YrIMduZ2+nd9Di7o5+KIwlb2mAB9sTNHdMrXesX8eBL6T9b+MZJk+mZuPxKNVfEQMQ a5SxUEADIPQTPNvBewdeI80yeOCrN+Zzwy/Mrx9EPeu59Y5vSJOx/z6OUImD/GhX7Xvkt3kq Er5KTrJz3++B6SH9pum9PuoE/k+nntJkNMmQpR4MCBaV/J9gIOPGodDKnjdng+mXliF3Ptu6 3oxc2RCyGzTlxyMwuc2U5Q7KtUNTdDe8T0uE+9b8BLMVQDDfJjqY0VVqSUwImzTDLX9S4g/8 kC4HRcclk8hpyhY2jKGluZO0awwTIMgVEzmTyBphDg/Gx7dZU1Xf8HFuE+UZ5UDHDTnwgv7E th6RC9+WrhDNspZ9fJjKWRbveQgUFCpe1sa77LAw+XFrKmBHXp9ZVIe90RMe2tRL06BGiRZr jPrnvUsUUsjRoRNJjKKA/REq+sAnhkNPPZ/NNMjaZ5b8Tovi8C0tmxiCHaQYqj7G2rgnT0kt WNyWQQ== Organization: Red Hat In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 5zqfIElssTIwaP6wbNoiWko3HIoY4VAhLnZwHkJrz1U_1749103707 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspam-User: X-Stat-Signature: ca9p9yeh3tw6nm55sc664j3ggijcpbp6 X-Rspamd-Queue-Id: E7AA520006 X-Rspamd-Server: rspam11 X-HE-Tag: 1749103709-880419 X-HE-Meta: U2FsdGVkX1+sx4VY4NxmkjWNJi6bJwYlmm/u//3Fw5/mTXb09euYcM/pElznY4VEVjddGkcBYIuuHTPLlr8FCCDdl8wKFeUyndbrJPIVpNbgiCq0ZWb+w6/mRsjCdZXInU8p+rBDLQdAYixheBu/7kIUPUnKinwSK/NC/5CsZaV9JYVkkhT0f7gkyuYEleTTj8EKMCDoV1TBpp71bfudTbFyzj2HhMZ3L8yRnf2eH70UwbsdskEj9UEvZHytiIB26/6nJTU6RuuuctsNeKdVsSD5rGA4Ji/pG+Xb1WrN753R3ysew16cmt+AQzIcWrJ6UYN+dE85JozM85prfYRXh+jFMFYBkTfOEedNDK5hTeYhmcIAq9kEeSvGP25GrgtUqGESfG6+OH8dhuBRLFk5Nd7DxX9zomIiSCSUxUzApZE/0dqCg+okhUnPpCzw61si8QB/nnYXX4gKcTmjXTWb3O41hanYlIEHNrKkXO7oL9nVrH1uNPvhGk7wCQgrSLhOgAkN2pgPcd3zlavfq090q79slbQH0OJN7AIK6VXu01ldO2yuLVVHIHIw6Wri8JgLkXEJvGbUgXmaxevtpV8V5KjsiDCX9tiNSCJ6TweOoOJU7vsv6Sc4s5knV59KFh3hKAlKboZUIf707QRvFkmh/kM9MeVEWnW88wNPL3054+ME8tKLzxVK0hJPLQjL4r2+fuz1W7wYgEiW0/mnLTeFHz5sjgAPSKxK9NqsppXw2WxzJSVfCKn0yBxnjtDuHBsy05h/ur45Ozfu0B9PCsoIIBbgxIggTPhDjIOPwFUtSaFo4yHINqk7clRydMnnPCsf2a9Tce7/2IcdyRPV2bTk0zrIlvRvqPGiVCwxP8AGaE+9pmuq/nk4C1y9We/3JmYcLbkPD6+2hr/jyo1cHEL3Q5T1JlxnzlfVBU6mOqtq4KV4FzfhFXajv8uPTIX7y/veiQK91euQQ0E5AXtcGBK QvSUKvIf OSUtTBQV3DBTpm2gV/6TKwZVTn4Lv9/kxUZIQf4RUZ6OOB+c+y+2VO2+JM21ulaaOV77r4/orB9RG95hVSyJFNnIL9H6Bhib8Qr50TaGKW2XuusYCkKSB+YTmMUfFGpGK1PtncqKO+0a3ve1gDzx6VVSQrTyuMmXkGKdgOYy/COU2gMYkuEOXEt/0phbehxJk+8KlUDOev+zGs3dut0DR+GQKQxwMNnBNrp4P4ssgg0R7BLpUySOUvlA0b+UzMy8hDpFNZZ1BfPQcOmymdCVjEyFQ6nisPRV5Qlw+9IF2nae/1ErYwhSHsNWFvNJaoFa3G/PCcfJ3PUUQE78RBtrDAdCzgoPmbmkGfytPrClZV+nUBaxbzzRat6gQDRCqN5k1z5IkdJOAIk3nJxqtoAhPZCkZgLpfL2iR4rai5DwAbEZWPYGDrgat8gNToP251Sks6AFECT7SVNbZu0hdnG4O/8qcPowbKzqZAB8VP15dmpkhX3yNbb6o+LIaL6nBtj5TIqvuDl4WtEwhAr1C3auu7vQmSlf8CjaIhlX8 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 05.06.25 07:37, Vlastimil Babka wrote: > On 6/5/25 03:07, John Hubbard wrote: >> On 6/4/25 7:05 AM, David Hildenbrand wrote: >>> Especially once we hit one of the assertions in >>> sanity_check_pinned_pages(), observing follow-up assertions failing >>> in other code can give good clues about what went wrong, so use >>> VM_WARN_ON_ONCE instead. >>> >>> While at it, let's just convert all VM_BUG_ON to VM_WARN_ON_ONCE as >>> well. Add one comment for the pfn_valid() check. >> >> It would be a nice touch to add Linus' notes here, with the BUG() history >> and all. It answers a FAQ about BUG vs. WARN* that is really nice >> to have in the commit log. > > Perhaps then rather put it somewhere appropriate in Documentation/process/ > than a random commit log? I mean, I documented most of that already in coding-style.rst. :) The full BUG history is not in there, but not sure if that is really required if ... we're not supposed to use it. Is there anything important missing? commit 1cfd9d7e43d5a1cf739d1420b10b1e65feb02f88 Author: David Hildenbrand Date: Fri Sep 23 13:34:24 2022 +0200 coding-style.rst: document BUG() and WARN() rules ("do not crash the kernel") Linus notes [1] that the introduction of new code that uses VM_BUG_ON() is just as bad as BUG_ON(), because it will crash the kernel on distributions that enable CONFIG_DEBUG_VM (like Fedora): VM_BUG_ON() has the exact same semantics as BUG_ON. It is literally no different, the only difference is "we can make the code smaller because these are less important". [2] This resulted in a more generic discussion about usage of BUG() and friends. While there might be corner cases that still deserve a BUG_ON(), most BUG_ON() cases should simply use WARN_ON_ONCE() and implement a recovery path if reasonable: The only possible case where BUG_ON can validly be used is "I have some fundamental data corruption and cannot possibly return an error". [2] As a very good approximation is the general rule: "absolutely no new BUG_ON() calls _ever_" [2] ... not even if something really shouldn't ever happen and is merely for documenting that an invariant always has to hold. However, there are sill exceptions where BUG_ON() may be used: If you have a "this is major internal corruption, there's no way we can continue", then BUG_ON() is appropriate. [3] There is only one good BUG_ON(): Now, that said, there is one very valid sub-form of BUG_ON(): BUILD_BUG_ON() is absolutely 100% fine. [2] While WARN will also crash the machine with panic_on_warn set, that's exactly to be expected: So we have two very different cases: the "virtual machine with good logging where a dead machine is fine" - use 'panic_on_warn'. And the actual real hardware with real drivers, running real loads by users. [4] The basic idea is that warnings will similarly get reported by users and be found during testing. However, in contrast to a BUG(), there is a way to actually influence the expected behavior (e.g., panic_on_warn) and to eventually keep the machine alive to extract some debug info. Ingo notes that not all WARN_ON_ONCE cases need recovery. If we don't ever expect this code to trigger in any case, recovery code is not really helpful. I'd prefer to keep all these warnings 'simple' - i.e. no attempted recovery & control flow, unless we ever expect these to trigger. [5] There have been different rules floating around that were never properly documented. Let's try to clarify. [1] https://lkml.kernel.org/r/CAHk-=wiEAH+ojSpAgx_Ep=NKPWHU8AdO3V56BXcCsU97oYJ1EA@mail.gmail.com [2] https://lore.kernel.org/r/CAHk-=wg40EAZofO16Eviaj7mfqDhZ2gVEbvfsMf6gYzspRjYvw@mail.gmail.com [3] https://lkml.kernel.org/r/CAHk-=wit-DmhMfQErY29JSPjFgebx_Ld+pnerc4J2Ag990WwAA@mail.gmail.com [4] https://lore.kernel.org/r/CAHk-=wgF7K2gSSpy=m_=K3Nov4zaceUX9puQf1TjkTJLA2XC_g@mail.gmail.com [5] https://lore.kernel.org/r/YwIW+mVeZoTOxn%2F4@gmail.com -- Cheers, David / dhildenb