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 A8AE7C282EC for ; Tue, 11 Mar 2025 15:48:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 97B32280002; Tue, 11 Mar 2025 11:48:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 928A7280001; Tue, 11 Mar 2025 11:48:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7CA05280002; Tue, 11 Mar 2025 11:48:41 -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 5D89A280001 for ; Tue, 11 Mar 2025 11:48:41 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id AD694B0E07 for ; Tue, 11 Mar 2025 15:48:42 +0000 (UTC) X-FDA: 83209702884.01.13127B2 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf02.hostedemail.com (Postfix) with ESMTP id 39BFF80021 for ; Tue, 11 Mar 2025 15:48:40 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Z7pc926f; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf02.hostedemail.com: domain of toke@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=toke@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741708120; 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=TI3zCJ9NRFviJcoIbIJXFFpl1vVQozYvxr0hiItBHWg=; b=VXclfhTrOwaHkomwlxblsR8QZkQ5gc0N9SAr9cl3IEBXW22bQ1fJR7pJFeP984ixMOHdj2 70ZfUTemMFZSxrPoEBNnCEUh7dMxLIZ/qZ/538xKQ1MhHZE/PjFquUNkgoVKfA6zqhS795 1K8jg2uaPz2v884kaTMu9eAujo9euNs= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741708120; a=rsa-sha256; cv=none; b=If398GAlJEot0TknQo4GcGryqDRsp8NlDO6GIjLhKkZq17vyppdUtdOJnF06HekAK82GNn hb3lkDf5c7KlFpWn/5ib7jYb1xbmdBxnz3aqFUBuMTbiymvEvOhqgf7O2bQp+8wDsec++r BF7aLF12g7+Bj8B6o6YDImRT9Ovte28= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Z7pc926f; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf02.hostedemail.com: domain of toke@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=toke@redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1741708119; 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; bh=TI3zCJ9NRFviJcoIbIJXFFpl1vVQozYvxr0hiItBHWg=; b=Z7pc926fBtnlA1n+iHoTjW5I+9xy6dgkn9WmmHz0PIOaxBvgl2chjPNsbNx5an7+duUgE7 B8VsCSjrkOHrhHRwFJMk9TAKEceWoC3G6O9s5Aw7aT/gHT8ozw+VVCsc1Edo28mVxHin7P N+rsjNLOzgsPkjjXIpO9DJfL1r+JUWw= Received: from mail-ej1-f72.google.com (mail-ej1-f72.google.com [209.85.218.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-441-brfExe5NNDKKskomQJBPNw-1; Tue, 11 Mar 2025 11:48:38 -0400 X-MC-Unique: brfExe5NNDKKskomQJBPNw-1 X-Mimecast-MFC-AGG-ID: brfExe5NNDKKskomQJBPNw_1741708117 Received: by mail-ej1-f72.google.com with SMTP id a640c23a62f3a-ac297c79dabso245657966b.0 for ; Tue, 11 Mar 2025 08:48:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741708117; x=1742312917; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=TI3zCJ9NRFviJcoIbIJXFFpl1vVQozYvxr0hiItBHWg=; b=IbYUljpwQZETsc9uSJ+d68Ha9XsX3a4oH31CCHFgD33ICPd5f3yo4e46Y6ioBpwOpb US727UbDaMCTszIS++UREqIsO9YVaJqVc3vEscETSUc7L166+PVw7fHOR3R8FN1TWk4y VWVhDdt+aqaFqWhznxop3LMQEHOKFpzk5faRan+WC75eD+Dzq7hzPjUc79mZQNSaAmYi 0Xw9vmYu/otMieZNtTqw95izGczwZLHr7FcA/ztS53s/fpH9ZMHaOu7KdY66dpo68e+v qs16xY/cMPSLnVb181v9C3VmMOLORB2hIjPZvB0Z1tmTtvL4FPpbz+8cBd0S3d6zjvqP 0lkw== X-Forwarded-Encrypted: i=1; AJvYcCWjJ2GCKJW3jvK0ePzQrrE2lV5kSj3I5aIjWB8b0TlXl4Hsqa+UcIksObC6elJXtpMWfAQAvGr3GA==@kvack.org X-Gm-Message-State: AOJu0YzZGQclh0787anqdW78YB8kZQyfdWABhUXqdr6nMFVfDIMaqp2Q qyhFI7yaKua5L102pjVGIXxoWBQTxCmDi3KMeeecr8WrxoDo18fRZpMrDRaZjJ8Ip8kebLy1u59 ZXzcTs0VG9XAvDwY9Ke79Ff3R1r34FAGtwrkgVjmjaTZTfu/3 X-Gm-Gg: ASbGncseiA1YculPril2yIWMtRjGqfsrG1YRwzQhC9SKsu/wKW+A+e3dPB/rY0xdFje dCMNUa82HVtuDZvbWJ9kAIHzQCxjbjVHktoF+OABsSTOnULOww5JMyW+/HlVcqkv/Uwj7RpUXj2 MfyqQbgAA51EMXnIGXVF1vs2Cw5jNqW1F3EzzlQKAuz3OWEmTLVL++UxpupumnyhWfS/Qd0uzHs DLqqEhPZanYzVu/+zR/IWY+F99HfiR9krAghaKCzFLc3VewA+oI6UuI5GGdfNNmQ8RCGARYtrL6 0G3w2D2jVrz3lH35trdaIMiJvNQ26FmEUsKyeFIl X-Received: by 2002:a17:907:9691:b0:ac2:166f:42eb with SMTP id a640c23a62f3a-ac25259836dmr2319325866b.2.1741708117197; Tue, 11 Mar 2025 08:48:37 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHs46zu0NfmV4YgBYokcezaQrfRf8yzsXDxqxrzuVomrpkzeJiCbp8qTIOtJWLPLilraSMmoQ== X-Received: by 2002:a17:907:9691:b0:ac2:166f:42eb with SMTP id a640c23a62f3a-ac25259836dmr2319321266b.2.1741708116787; Tue, 11 Mar 2025 08:48:36 -0700 (PDT) Received: from alrua-x1.borgediget.toke.dk ([45.145.92.2]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ac29363d604sm430663766b.76.2025.03.11.08.48.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 Mar 2025 08:48:36 -0700 (PDT) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 238AD18FA5DF; Tue, 11 Mar 2025 16:48:35 +0100 (CET) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Mina Almasry Cc: Jesper Dangaard Brouer , Ilias Apalodimas , Andrew Morton , "David S. Miller" , Yunsheng Lin , Yonglong Liu , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , netdev@vger.kernel.org, linux-mm@kvack.org Subject: Re: [RFC PATCH net-next v2] page_pool: Track DMA-mapped pages and unmap them when destroying the pool In-Reply-To: References: <20250309124719.21285-1-toke@redhat.com> X-Clacks-Overhead: GNU Terry Pratchett Date: Tue, 11 Mar 2025 16:48:35 +0100 Message-ID: <87ikofin58.fsf@toke.dk> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: G7hte215M6tb0mDtdAj3_3MGYF0DDh8AwvUfmPYF4ZQ_1741708117 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Stat-Signature: dtscuprsf7w18suh7e6kmbdotbq1gzo1 X-Rspamd-Server: rspam05 X-Rspam-User: X-Rspamd-Queue-Id: 39BFF80021 X-HE-Tag: 1741708120-558613 X-HE-Meta: U2FsdGVkX1/Mj6SyvZCkKQSzovVl5BrQbCHg88LTpi0PsxMLSav5zBubjtOaI2S39vuWtU1DMFoQzZV//yk5u1PYFXfVTyp70fVriMHSvBoXT1wjNnFJNRDBaij2m4ZK1/1+SLKj4aRdJlnNPX4xd+L951HUBVe+JppB+MFYIU0dkKaW5ueIJ0MgGz6JAHF5HE7pdpl0Y1/OTkHondInhnwZhawX7A3MlvL9mIf8DijFX08kKphm8qz49k1TvhQjry/HhT58cVVI16pDJnAlxLOeGdt5/IwdrxMS1X81BvK581rpP7ayC3R2GbN0NNy67W05sZDKyuXP3ouwecRs+Ev7vf+f0pcHozfghqKo10DsUFx+TJqi4v6KA41ZzJ0kUouRmRH+TNR4yNZeQEGURqTpm2BKNKOUafI9/rdUTrZ4PNcfwGHjtIRPpFikZ7dN2uhqCx62ppNeejFAJMkoYKzIkJLoV8IjyMsUCYpB2bcjjoCMQWV6OCMg5rCQ+U581XCf0te7dxjFySfEtgKPjiS/moAjHPBaklHyTLSf32aLc76PWOOQZGSPOSEBEVE0nPAKBq7W1TNFS5sRtljGIo2HoSOwhGfe7+A0zKT8TvP0hLEvuyhS3VfHS/OoqXGtEDWnsER5rNdQ1eVcwED36w2JTgOPnhexIxMDeKn5mKxzrejtJjontjS2dKqfZuP/R5jQfxmRs9TWus4KtYQhbCF+Q49z2pZD9FWk9xZCLkQm+TZcnQRMzGZubrClK16f10XkjXqSoACZVQ0rvrDOHN4qZrNqtYmdtZ8OoTC8Pa6qggQNpY0I6zN3rHmPehQiRiR8Bul6DXXqKKi0eAkDaGViEQRqHPF0nDdhtYWgaz88RvQ562ukk2E25UeYYxPMbxhIXXsRIO/C5vdDqOO7Ixwqym6I/vRD07QBW3tkkx31hYKCqLIWJ34MqUPXbW5ECpku6o9HpvSxwdi/e9f RyQUfPj2 O/1QfAlkFXi2FdAfY6xd1Vp4pRUA/f5vII87nAJTv56ASaVe/gWYXDuyNspb0jGEnpWCVtfmtQX8VJiiu2YIfGCMQguTiRiJxFurAMtFB2q7whgk2LdCnkV+F3flo9d+eyc6SSwr8o4BeP06BAoNaxYDiZlxSlXIn7dCPMuulkM35XVmTKU0CpE0j8R00ZYz9ZdmKJDVLmfyuK0K8nBEPwf3IltJeFuOEGYPQgl8AmBcvErhWTxwJoqoirc75TgSV8XKxT8pc2OQwbffmawXxuf1fC6FOk3MG7uuW3iajWuKfIKzyCBDJtjl4U3re/3YUtDCs1ZYjq3cugLmx/410I6/Ll6sV/G95/C2ItsLzMCoJnMtwEEpsUDQOWmMmyumaW1PGpxEB4azUcoR3EAmR7SGdUvf4OfBA0Q44n2x6oL/XTpSdwgGoOxGyi4v0hDPsZevgvxuFeCKZAWKufpmcNj3iOJ33J9OLFOVJHVToAsrDWihmyjGl65kTkovGKlIslDWpqvhmDknUP3A= 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: Mina Almasry writes: > On Sun, Mar 9, 2025 at 5:50=E2=80=AFAM Toke H=C3=B8iland-J=C3=B8rgensen <= toke@redhat.com> wrote: >> >> When enabling DMA mapping in page_pool, pages are kept DMA mapped until >> they are released from the pool, to avoid the overhead of re-mapping the >> pages every time they are used. This causes problems when a device is >> torn down, because the page pool can't unmap the pages until they are >> returned to the pool. This causes resource leaks and/or crashes when >> there are pages still outstanding while the device is torn down, because >> page_pool will attempt an unmap of a non-existent DMA device on the >> subsequent page return. >> >> To fix this, implement a simple tracking of outstanding dma-mapped pages >> in page pool using an xarray. This was first suggested by Mina[0], and >> turns out to be fairly straight forward: We simply store pointers to >> pages directly in the xarray with xa_alloc() when they are first DMA >> mapped, and remove them from the array on unmap. Then, when a page pool >> is torn down, it can simply walk the xarray and unmap all pages still >> present there before returning, which also allows us to get rid of the >> get/put_device() calls in page_pool. Using xa_cmpxchg(), no additional >> synchronisation is needed, as a page will only ever be unmapped once. >> >> To avoid having to walk the entire xarray on unmap to find the page >> reference, we stash the ID assigned by xa_alloc() into the page >> structure itself, using the upper bits of the pp_magic field. This >> requires a couple of defines to avoid conflicting with the >> POINTER_POISON_DELTA define, but this is all evaluated at compile-time, >> so should not affect run-time performance. >> >> Since all the tracking is performed on DMA map/unmap, no additional code >> is needed in the fast path, meaning the performance overhead of this >> tracking is negligible. The extra memory needed to track the pages is >> neatly encapsulated inside xarray, which uses the 'struct xa_node' >> structure to track items. This structure is 576 bytes long, with slots >> for 64 items, meaning that a full node occurs only 9 bytes of overhead >> per slot it tracks (in practice, it probably won't be this efficient, >> but in any case it should be an acceptable overhead). >> >> [0] https://lore.kernel.org/all/CAHS8izPg7B5DwKfSuzz-iOop_YRbk3Sd6Y4rX7K= BG9DcVJcyWg@mail.gmail.com/ >> >> Fixes: ff7d6b27f894 ("page_pool: refurbish version of page_pool code") >> Reported-by: Yonglong Liu >> Suggested-by: Mina Almasry >> Reviewed-by: Jesper Dangaard Brouer >> Tested-by: Jesper Dangaard Brouer >> Signed-off-by: Toke H=C3=B8iland-J=C3=B8rgensen > > I only have nits and suggestions for improvement. With and without those: > > Reviewed-by: Mina Almasry Thanks! Fixed your nits and a couple of others and pushed here: https://git.kernel.org/toke/c/df6248a71f85 I'll subject it to some testing and submit a non-RFC version once I've verified that it works and doesn't introduce any new problems :) -Toke