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 X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BF23EC282D8 for ; Sat, 2 Feb 2019 02:29:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7B46A20869 for ; Sat, 2 Feb 2019 02:29:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=omnibond-com.20150623.gappssmtp.com header.i=@omnibond-com.20150623.gappssmtp.com header.b="zzimq6zx" 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 Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org 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 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; 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