Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp431182ybi; Tue, 2 Jul 2019 23:04:53 -0700 (PDT) X-Google-Smtp-Source: APXvYqywjUCJRl3rEgxK2IA/+BAbzb1uP1FO2vtT8VWG/j7xVtFvs0Cc+tpOCODgVvm/aC0qVTzl X-Received: by 2002:a63:1b23:: with SMTP id b35mr6382851pgb.128.1562133892845; Tue, 02 Jul 2019 23:04:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1562133892; cv=none; d=google.com; s=arc-20160816; b=Ld5V9CRQc6Nv32LGCMXXbI6EyY4FZRJTRqj9huZ3iR56+d5+WWfdp+Yw6OWrc5Bq7h /oW/mU0JeyjxXAZQ6ohkLACp7miBFuGgUGa2zd6BCKw6J1pFB/piDjaHPoezqV7pO8RF cNX4mNcfpgUNm9pF1kzxK43DbxW0xkq5htdJ8m0kYQVLNZDUjbwQToIEt/x09EweeHL8 8JgH0NgRHRyltVElWJSl/vtUgFUZj3OcT9kfjQAonXxgBlPC8NoD1KK0QHuZ/epPaXn8 bgIbYTxhqYZnCKZyN/wpWu9k8QPaeAM3vzJfs6UcKXCB663qv0/cYNviuceFeu+hIokA tybg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=YR83koGSfN8f4T21Djb6M4JozxiegfBiW4pc4sENEhU=; b=CiAyQGQb/K1qFtFM+NiU6X0S4DtaW5nOYEaydyw9j09i7LK73V3RPdPitTd0VX8wNF STpDWgpXLEq+TYcEvlLrjqaR60DPI6DwXT71EBFDgxG2a0dmh0zWy6mdk1Uz3upYulFg eKZhV2h13DGSKz2ogD+RLGNYu6HUuFlsJ2UKHiZEj2K6GtgFERJVpPimaGyFVjdV6bUm LUOO+2peOAFnoq7Rp+i81rU/LJq1Q7SshRuzfPOHL9OomIi/PIsrh5KbDWOvK3ttpuBD ONGBdYtQ+f6+C+PVt1SFKrxZkkI/HJ8zTGo16JFDiYAQAnoKtt/tK6/IusdGXQOoiLm0 9R5A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=PFhq5S64; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 72si1248773plc.415.2019.07.02.23.04.37; Tue, 02 Jul 2019 23:04:52 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=PFhq5S64; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727018AbfGCGDb (ORCPT + 99 others); Wed, 3 Jul 2019 02:03:31 -0400 Received: from mail-lj1-f194.google.com ([209.85.208.194]:35580 "EHLO mail-lj1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725927AbfGCGDb (ORCPT ); Wed, 3 Jul 2019 02:03:31 -0400 Received: by mail-lj1-f194.google.com with SMTP id x25so1050419ljh.2 for ; Tue, 02 Jul 2019 23:03:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YR83koGSfN8f4T21Djb6M4JozxiegfBiW4pc4sENEhU=; b=PFhq5S64bGYOvM9RVa2rbe3BMe23mBxegax68A5oboVVYkj9yac+DYKBsUV8TIxm82 dCGgip+iJTAtzeueMH8rXwQ45n2SYFC+AJILLZRa9Dtx/5PVB/eM9wPnNOm1KyaDPc5B WpCwcuNCvEEkNPlwFbk1fJwDnjI9sMF3ObMHbhpCS5nEdkC8ViFucYBJDVa7o8JsLEJu w30fTQ8+s+plIIDzeJmOF+FLYOHg3mjz3cKsMggoNq3CRop9fr8LgDofeAmZDUYJq/Zc K1IcZ1OxyF73JiC5QitC8o0m7qWFaaci8gL35lYByRCuUNfS0IorVlFmxBZz6UOfcPyx My2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YR83koGSfN8f4T21Djb6M4JozxiegfBiW4pc4sENEhU=; b=j4eDYrJkUd7A3op5wiGFnv5t3PMZHwKjp340xoSz+C9V1Tu20gOLHdsE4D+XPvT1Mg R9cwYXmjqpXREvUIAnZ/Bfyodp53kBAwlQtgvyVAJYDtSWC/ChZJgxc7aX4I1yVJniBx cCYI/1BwZc5wMbKd0sqGJpYP2qUzyqHRq6J3WvEbmstyrYl3X7OU6iXjJUHlVs8r6UrG aV+h6rx5KLU+A2IgzNlq5zhBPN7hP41wKWAly76c7+sLKh2t2G1FHynRbBhVwjj4LE38 5tZ6c8Ak6Z7aHhx4wcrTDAVhP5+NqrTpdPaYr+BQVWhzk8r7btzuiPasGlBYtMPEH+kz o3zg== X-Gm-Message-State: APjAAAWZbkn7zY0pdBeCZOgeUj02bmqOBXYbGKTVRbWScXsuQDmc4fs5 03nDtJy0X61fCBM/vAoZY+UVJ6/gj78js1ECvJg= X-Received: by 2002:a2e:80c8:: with SMTP id r8mr5360976ljg.168.1562133809409; Tue, 02 Jul 2019 23:03:29 -0700 (PDT) MIME-Version: 1.0 References: <20190701173042.221453-1-henryburns@google.com> In-Reply-To: From: Vitaly Wool Date: Wed, 3 Jul 2019 08:02:31 +0200 Message-ID: Subject: Re: [PATCH] mm/z3fold: Fix z3fold_buddy_slots use after free To: Henry Burns Cc: Andrew Morton , Vitaly Vul , Mike Rapoport , Xidong Wang , Shakeel Butt , Jonathan Adams , Linux-MM , LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 2, 2019 at 6:57 PM Henry Burns wrote: > > On Tue, Jul 2, 2019 at 12:45 AM Vitaly Wool wrote: > > > > Hi Henry, > > > > On Mon, Jul 1, 2019 at 8:31 PM Henry Burns wrote: > > > > > > Running z3fold stress testing with address sanitization > > > showed zhdr->slots was being used after it was freed. > > > > > > z3fold_free(z3fold_pool, handle) > > > free_handle(handle) > > > kmem_cache_free(pool->c_handle, zhdr->slots) > > > release_z3fold_page_locked_list(kref) > > > __release_z3fold_page(zhdr, true) > > > zhdr_to_pool(zhdr) > > > slots_to_pool(zhdr->slots) *BOOM* > > > > Thanks for looking into this. I'm not entirely sure I'm all for > > splitting free_handle() but let me think about it. > > > > > Instead we split free_handle into two functions, release_handle() > > > and free_slots(). We use release_handle() in place of free_handle(), > > > and use free_slots() to call kmem_cache_free() after > > > __release_z3fold_page() is done. > > > > A little less intrusive solution would be to move backlink to pool > > from slots back to z3fold_header. Looks like it was a bad idea from > > the start. > > > > Best regards, > > Vitaly > > We still want z3fold pages to be movable though. Wouldn't moving > the backink to the pool from slots to z3fold_header prevent us from > enabling migration? That is a valid point but we can just add back pool pointer to z3fold_header. The thing here is, there's another patch in the pipeline that allows for a better (inter-page) compaction and it will somewhat complicate things, because sometimes slots will have to be released after z3fold page is released (because they will hold a handle to another z3fold page). I would prefer that we just added back pool to z3fold_header and changed zhdr_to_pool to just return zhdr->pool, then had the compaction patch valid again, and then we could come back to size optimization. Best regards, Vitaly