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 23F2AC54798 for ; Tue, 5 Mar 2024 15:50:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6990E6B0075; Tue, 5 Mar 2024 10:50:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 64AE56B007B; Tue, 5 Mar 2024 10:50:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4EA1D6B007E; Tue, 5 Mar 2024 10:50:08 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 3FB9A6B0075 for ; Tue, 5 Mar 2024 10:50:08 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 10B2CA1373 for ; Tue, 5 Mar 2024 15:50:08 +0000 (UTC) X-FDA: 81863421696.19.E9CCFA8 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf19.hostedemail.com (Postfix) with ESMTP id 3D94D1A001D for ; Tue, 5 Mar 2024 15:50:05 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="jFyVneW/"; spf=pass (imf19.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709653805; 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=zCIy443PV1bMExvsymG7IFjtByoanOECI8kV/uhdu4Q=; b=cPzuPGjTSOo5AyP/ocM3u/sOTzX8fnDWMmCQGv19RgTa+TDKVxINJDpDLD2uWLLkC8ds/x v2AezgXR2tCroQ1oKHCVuQO0DtESct++dUaDg7L5R48cB0dYkxs/ulJavzHLl5GYj/RB+z awszTfnqbma6CtrdLzV78Qeo1hXzyrY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709653805; a=rsa-sha256; cv=none; b=D7dE0GiYcv68XIabSNHL3zYVKbFoTRVaUWJPBZZZSKFBy6NjGUaQqTtoE8Y6xi/W1WFhSg SsWDLnT2TGCfey3wVBtqqt3BSP32XUZWxGRUVpkBkyBI0oaXVxHCq3INOkCspHzIL3OPoU SiGEOdzsinb/TK4o5da2JFKXQvUIRc4= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="jFyVneW/"; spf=pass (imf19.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1709653804; 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=zCIy443PV1bMExvsymG7IFjtByoanOECI8kV/uhdu4Q=; b=jFyVneW/I+RQ0GoFF8G4/ttMzhsnzQ3yxtcme1l5kgFIMNgv72ke+SqOiO4iA4CJAn7NIG AQEE/4KcHxsjtWlH52t+0h3xVYaJ7KYLr3BGZps6gutBcAi4tJE11reMsO+EOWHO6Y9K9b J5y+o+TnQee5POc8cW1Y14JjO8v/mZo= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-45-_drK917RN8K0OonDGp-QeQ-1; Tue, 05 Mar 2024 10:50:03 -0500 X-MC-Unique: _drK917RN8K0OonDGp-QeQ-1 Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-33d19951a9bso2298828f8f.0 for ; Tue, 05 Mar 2024 07:50:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709653802; x=1710258602; h=content-transfer-encoding:in-reply-to:organization:autocrypt:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=zCIy443PV1bMExvsymG7IFjtByoanOECI8kV/uhdu4Q=; b=AsbGoqczClumk3Ox2XZc8Q+dMtNs8kRdgg0gY5Z6oQ52LSDxhNoXgpraqYZfLlEJ2p BunrselblfSkUG/FuCDKB2/u06E1dBSZwWccAWXtqWZYCyJZo+ak83z2eLkD5d+gJi6y rB8VUEAGx+zO178xkOQjmQuWsDeAgMw2sohYxKGWSdDgvk80TbMaIqvjHoYmb0CRdyU7 nOsGghDCVLBdIjNtkFNPdWc9DKMBndWGMEjRS7QACGVPXGERpE39Z/Jlo9ls6u8DTfnz nlLrhdFnBFTi/qN/ZVcHLFjzmW2mJ2t5nCjC9jxFQLkX5oq52a93iwMkKq39gvtqSWoI Mppw== X-Gm-Message-State: AOJu0YyUUh+a7lSaqcfUqrMiortueGFh1dNHKYd7tfVIEJuisVH1GW/8 /iFNV/5wRr+xugSwaugy9nCwwHmHLi7i/zIqzF8dNm6ZXw34NtuqfQ5Kk9HLPwA+p3jGtop1zi8 WbG+2nrjpieOb/t5TvUtblwMshJEdMAoDMMDuxNdbEpeJlHNU X-Received: by 2002:adf:9dc4:0:b0:33e:1ee0:62ac with SMTP id q4-20020adf9dc4000000b0033e1ee062acmr8455510wre.5.1709653802061; Tue, 05 Mar 2024 07:50:02 -0800 (PST) X-Google-Smtp-Source: AGHT+IFmrb4M094kjpI+xCb6K9TxDuygeKpMipcdzxLgCU/VQBNhWcXn8spbARz+uJ/HiNVXNVb6kw== X-Received: by 2002:adf:9dc4:0:b0:33e:1ee0:62ac with SMTP id q4-20020adf9dc4000000b0033e1ee062acmr8455490wre.5.1709653801518; Tue, 05 Mar 2024 07:50:01 -0800 (PST) Received: from ?IPV6:2003:cb:c73c:8100:600:a1e5:da94:a13a? (p200300cbc73c81000600a1e5da94a13a.dip0.t-ipconnect.de. [2003:cb:c73c:8100:600:a1e5:da94:a13a]) by smtp.gmail.com with ESMTPSA id ch10-20020a5d5d0a000000b0033e26c81b11sm10380878wrb.92.2024.03.05.07.50.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Mar 2024 07:50:01 -0800 (PST) Message-ID: Date: Tue, 5 Mar 2024 16:50:00 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1] mm: swap: Fix race between free_swap_and_cache() and swapoff() To: Ryan Roberts , Andrew Morton , "Huang, Ying" Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org References: <20240305151349.3781428-1-ryan.roberts@arm.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: <20240305151349.3781428-1-ryan.roberts@arm.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Stat-Signature: a3dsrcuz9q9bnx7wfdnew6wctrjugbp3 X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 3D94D1A001D X-Rspam-User: X-HE-Tag: 1709653805-144442 X-HE-Meta: U2FsdGVkX19wSi/HF/DYv09+5EBI9zcQxBd3VdKIuUKl3LUJ3lrKM5GYY1AvPkBMD015DxMl965xsX7mkdwtg/U/DKZs4zCH5ZQs8SxUKQzNPFpDxm3Np2CQ16CrV9CyYVmben0TFsb3PohSzW1OzaYF66pWiThbABS8GqJR1uZPk4hcjA8G0+iYQxw/v5Id9U6rCicbj52DW+6TjVxU3voIAE/7if7TC0hJqHH1Ios4kq6ae/fXQ8RBZRq618Y3BntPTgWBxDlur8Xckmija2VimlIOxZzeTYbBhFJ0FGSJghb5VhjicWZSeuC4nVCcRpt79IK/bZYp6QLCLyzzxbTrKWa5wlO8kBBk6/JgtFlXGziomufH1H6pfRqijDlkt9qr6G0mhpFC7s2Y355HWEVPbKOkLVo5xEoz4A8PM+MAFA92UrRNv76ps/ZetKUIlMcL+rGdX8tpZfefkHt/Wg3vWGRDjqkmD0OmFJa6tuNguyf2rx30D9mMq3mvvp9pm76tvejrWUX1EtuACpQMwG1woI9+HhnKX6WZ/Ydu9Q54CnY3EEjrwGEp5E/sA9KJ4/IbWYgTAkzkwMPo7U0yb5tID6fz7g046sFAzsdvvNyRt06hBL9WKVMi0W7C0DMqWCWcBlzDgPI8hQT2Zbe+amZAIQX4bcHhT6hDlyvjtjOS31q0g2JJ2371cUbpaNg8TlR8GS1Is/7gGG7K98kY9aZeWKKwr23b8gzaj2iL1v1mkdxyvigsd8pvokks9N/QqDpbYl/P1+ZVJySF2r+VFFppRL7TVwAIMuFvWLGzVQU5lDjHywbaK8PP9NzWE6vR3jOCzW492yO3T0GqT6BVCV4Gx93rd5EnvoJD8XypKQ4kAYrNMn1OwurOiHyiJK6OvLUrylVwvs8NvhxJbeBjvuTq4cvRTmkWxxI59e10OnRHkYhM0Ux04ntTRsqCseu7Gojd/1gp3iQfsjDCA8y RaKmlH7R qjUKUzZqs9PNer8WPjA/M/FXe8HjnuA/5qKhUrh2qUG6m4sCcFpIAZev//9krTUdFetxOX4i5UdQ7C9TJIE6qC+qVcu6AY80kEL/Kc5m4amhslxtmGNqA3nNki9IjS0iZNJtrXWUag3ivaz2pK6GVyDPkiP9msqm/tdiPncxkl+DPhNwU5XSNf7NQJqQwjC/+nUGIkAEohZ+ebC4btT0/ThOdNr4D1RpEwYLy6nH8l3vIa6u5BcE+zbKDPxZjw8NeMZplrrrYLzd3+Yn48dFXDiFENpdNkCXsqdpiRh+kr1RnIA97AWK8ebksRIJzTYuNF914HzQrSJmnKM0B2smJmjrcGA0dYd7Z+Ht+gMBM9bF20zoH4wopcGpZjSf1HXPy0TMtdWd963YroGZFzhSQtobyu07Sz2phjdjOpExSvXTdvAnl1cFWSsHq75d/8D0Ptid5R9YWDYprTlUk7OaZchbSWBvabnkjFaalZTbp/l68Sx0OYo6SUzBgA5BNIY58ByNMbZdlfNL1ukBhCKl44hf77+VHjvF61sk9aLrqQifJxv499hI0jaFYW65DZ/Up7/AYRS9RVEMxkzKBKazxchQI8aanrmNniIJbYysbf8iRqeg= 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.03.24 16:13, Ryan Roberts wrote: > There was previously a theoretical window where swapoff() could run and > teardown a swap_info_struct while a call to free_swap_and_cache() was > running in another thread. This could cause, amongst other bad > possibilities, swap_page_trans_huge_swapped() (called by > free_swap_and_cache()) to access the freed memory for swap_map. > > This is a theoretical problem and I haven't been able to provoke it from > a test case. But there has been agreement based on code review that this > is possible (see link below). > > Fix it by using get_swap_device()/put_swap_device(), which will stall > swapoff(). There was an extra check in _swap_info_get() to confirm that > the swap entry was valid. This wasn't present in get_swap_device() so > I've added it. I couldn't find any existing get_swap_device() call sites > where this extra check would cause any false alarms. > > Details of how to provoke one possible issue (thanks to David Hilenbrand > for deriving this): Almost "s/Hilenbrand/Hildenbrand/" :) > > --8<----- > > __swap_entry_free() might be the last user and result in > "count == SWAP_HAS_CACHE". > > swapoff->try_to_unuse() will stop as soon as soon as si->inuse_pages==0. > > So the question is: could someone reclaim the folio and turn > si->inuse_pages==0, before we completed swap_page_trans_huge_swapped(). > > Imagine the following: 2 MiB folio in the swapcache. Only 2 subpages are > still references by swap entries. > > Process 1 still references subpage 0 via swap entry. > Process 2 still references subpage 1 via swap entry. > > Process 1 quits. Calls free_swap_and_cache(). > -> count == SWAP_HAS_CACHE > [then, preempted in the hypervisor etc.] > > Process 2 quits. Calls free_swap_and_cache(). > -> count == SWAP_HAS_CACHE > > Process 2 goes ahead, passes swap_page_trans_huge_swapped(), and calls > __try_to_reclaim_swap(). > > __try_to_reclaim_swap()->folio_free_swap()->delete_from_swap_cache()-> > put_swap_folio()->free_swap_slot()->swapcache_free_entries()-> > swap_entry_free()->swap_range_free()-> > ... > WRITE_ONCE(si->inuse_pages, si->inuse_pages - nr_entries); > > What stops swapoff to succeed after process 2 reclaimed the swap cache > but before process1 finished its call to swap_page_trans_huge_swapped()? > > --8<----- > > Fixes: 7c00bafee87c ("mm/swap: free swap slots in batch") > Closes: https://lore.kernel.org/linux-mm/65a66eb9-41f8-4790-8db2-0c70ea15979f@redhat.com/ > Cc: stable@vger.kernel.org > Signed-off-by: Ryan Roberts > --- > > Applies on top of v6.8-rc6 and mm-unstable (b38c34939fe4). > > Thanks, > Ryan > > mm/swapfile.c | 14 +++++++++++--- > 1 file changed, 11 insertions(+), 3 deletions(-) > > diff --git a/mm/swapfile.c b/mm/swapfile.c > index 2b3a2d85e350..f580e6abc674 100644 > --- a/mm/swapfile.c > +++ b/mm/swapfile.c > @@ -1281,7 +1281,9 @@ struct swap_info_struct *get_swap_device(swp_entry_t entry) > smp_rmb(); > offset = swp_offset(entry); > if (offset >= si->max) > - goto put_out; > + goto bad_offset; > + if (data_race(!si->swap_map[swp_offset(entry)])) > + goto bad_free; > > return si; > bad_nofile: > @@ -1289,9 +1291,14 @@ struct swap_info_struct *get_swap_device(swp_entry_t entry) > out: > return NULL; > put_out: > - pr_err("%s: %s%08lx\n", __func__, Bad_offset, entry.val); > percpu_ref_put(&si->users); > return NULL; > +bad_offset: > + pr_err("%s: %s%08lx\n", __func__, Bad_offset, entry.val); > + goto put_out; > +bad_free: > + pr_err("%s: %s%08lx\n", __func__, Unused_offset, entry.val); > + goto put_out; > } > > static unsigned char __swap_entry_free(struct swap_info_struct *p, > @@ -1609,13 +1616,14 @@ int free_swap_and_cache(swp_entry_t entry) > if (non_swap_entry(entry)) > return 1; > > - p = _swap_info_get(entry); > + p = get_swap_device(entry); > if (p) { > count = __swap_entry_free(p, entry); > if (count == SWAP_HAS_CACHE && > !swap_page_trans_huge_swapped(p, entry)) > __try_to_reclaim_swap(p, swp_offset(entry), > TTRS_UNMAPPED | TTRS_FULL); > + put_swap_device(p); > } > return p != NULL; > } > -- > 2.25.1 > LGTM Are you planning on sending a doc extension for get_swap_device()? -- Cheers, David / dhildenb