From patchwork Sat Feb 2 02:29:36 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mike Marshall X-Patchwork-Id: 10794053 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 6BF33922 for ; Sat, 2 Feb 2019 02:29:50 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 5020D32EC6 for ; Sat, 2 Feb 2019 02:29:50 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 4133232EC8; Sat, 2 Feb 2019 02:29:50 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 9FE6D32EC6 for ; Sat, 2 Feb 2019 02:29:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726545AbfBBC3s (ORCPT ); Fri, 1 Feb 2019 21:29:48 -0500 Received: from mail-yw1-f66.google.com ([209.85.161.66]:43140 "EHLO mail-yw1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726067AbfBBC3s (ORCPT ); Fri, 1 Feb 2019 21:29:48 -0500 Received: by mail-yw1-f66.google.com with SMTP id n21so3629704ywd.10 for ; Fri, 01 Feb 2019 18:29:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=omnibond-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=PZCDwafqOCWSayHQAPCaODNjWFIbEEW3MHirjbGGmVs=; b=zzimq6zxfU+VqzJ3D3rgBCqNLOMaaVIH6eJ/fgcTBtrBrg5Uj51Did6EBQzwknCcpY dFfrABTVfkfB+VjiYtuHGOE9EJu+4B8u2x9Wrkd3TU49KWwspuAnN7Pavv9b1LodLcqm a0FOgpLgIeHuc4g/Z3BmAPMGdlgS9rvpZtaEqPZF3VdgxZn7sFplnQ/5zR3Q7OTcgKdC Iqe85siBIvMYc85hRfk38likwoVNxrE8FtfjjbUr0R+3b5xZwbbliSfiGwuvCZe5AU3W /i+6WnYfJ4WuvtJcKwPtV9BFEteC2CnHRzLTIbWG9I/MhaZPHizvE4dDqfa6SEdkmG6+ o97A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=PZCDwafqOCWSayHQAPCaODNjWFIbEEW3MHirjbGGmVs=; b=J/3xPLGl7Kz++iCi3zPFhiPFXOTkkHtbx1+r0qZljrzzWQ75fLKhY01KllEYI4UKWT wevLX8InYEXwezBnTZvJ4a/J2NCq7NQdFMdnr7Qd5nONTpDBx7AXR+3kHbGKNMVKNprn +z3r18b1VQ8/LWEkLDy9G0NVu3HJe+O5Ptun2NcV1tuNJZ+pMgqIyBIGlKbCxQuTC+fK ReJy0+KShxm9tb6IZDM08+ULQljLTYIS+48o59Gb3+OWGjVe2txHmEiSu4Jpf3iLhfjC RIu2N59HIfYOvLx53BylhWJv19R4MJ3/zV3R1t99e55nvjdQlHYnY43Fsh5xblio3olX aPfQ== X-Gm-Message-State: AJcUukeQpCwD3K0vQ9b/oco0n8BrfRTJ+G2fMrfB7rJBmtNofc0Y9YpG O1EgRUkdvuHsDo17nLbqA3Fmfn2s2H8iAkRqEeAnzg== X-Google-Smtp-Source: ALg8bN4aT27P+ccFoUyxEsVW88TvR99zDZUUWacwP2sJNuGFushcBWX4iFUymSR804TBR6nlIapE5Po5afv5OZkyw+A= X-Received: by 2002:a81:5a86:: with SMTP id o128mr38255472ywb.205.1549074587448; Fri, 01 Feb 2019 18:29:47 -0800 (PST) MIME-Version: 1.0 From: Mike Marshall Date: Fri, 1 Feb 2019 21:29:36 -0500 Message-ID: Subject: side effect from "aio: don't zero entire aio_kiocb aio_get_req" To: Al Viro , Jens Axboe , linux-fsdevel , Mike Marshall , Christoph Hellwig , Martin Brandenburg Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP We've been working on our Orangefs page cache patch with blinders on, and last week I took our patch set which was based on 4.19-rc7 and applied it to 5.0-rc3. In the process I ran vanilla rc3, and rc3 plus an Orangefs related patch set that Christoph Hellwig sent in, through the suite of xfstests. It turns out that a patch from one of Jens Axboe's patch sets that came, I think, in the 5.0 merge window triggered a BUG_ON in Orangefs' file.c. The particular patch is "aio: don't zero entire aio_kiocb aio_get_req". This code is in Orangefs file.c in a couple of places: BUG_ON(iocb->private); Anywho... I can easily fix the Orangefs problem by removing the two BUG_ON statements, I've researched how they got there and they are vestigial, just the kind of thing that Linus hates :-). The bigger question is that maybe there is other code in other filesystems that checks iocb->private without failing in a way that is as obvious as BUG_ON. I don't see any upstream code with grep other than a few lines in ext4/inode.c that might be affected. As a test, I "fixed" the Orangefs problem with this: [hubcap@vm1 linux]# git diff INIT_LIST_HEAD(&req->ki_list); So, the real fix for Orangefs is getting rid of the two BUG_ON lines, and I'll do that, I just wanted to bring this up in case it matters to anyone else... -Mike diff --git a/fs/aio.c b/fs/aio.c index b906ff70c90f..2605a4b1a3c9 100644 --- a/fs/aio.c +++ b/fs/aio.c @@ -1020,6 +1020,7 @@ static inline struct aio_kiocb *aio_get_req(struct kioctx *ctx) if (unlikely(!req)) return NULL; + req->rw.private = NULL; percpu_ref_get(&ctx->reqs); req->ki_ctx = ctx;