From patchwork Mon Feb 22 21:22:57 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mike Marshall X-Patchwork-Id: 8383721 Return-Path: X-Original-To: patchwork-linux-fsdevel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 8B74CC0553 for ; Mon, 22 Feb 2016 21:23:03 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 8F1A52038E for ; Mon, 22 Feb 2016 21:23:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 49CF820304 for ; Mon, 22 Feb 2016 21:23:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755808AbcBVVW7 (ORCPT ); Mon, 22 Feb 2016 16:22:59 -0500 Received: from mail-lb0-f171.google.com ([209.85.217.171]:33889 "EHLO mail-lb0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755550AbcBVVW6 (ORCPT ); Mon, 22 Feb 2016 16:22:58 -0500 Received: by mail-lb0-f171.google.com with SMTP id of3so89818795lbc.1 for ; Mon, 22 Feb 2016 13:22:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=omnibond-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=u1s2SODLN8X1WWwpBCVJ8/YQskrKPclczxiJDRai2IQ=; b=18al4s+74Sp0z0w7kmtNiEgZ25Y6PLNcLRVszkwBHapQ12E5Au93ygbYPX7yJlGbn2 1cBvie0/fhtH3pt9NAXwSxpRDHTt/15rkodn7QVSz6pOfteKC0fd1umnCLmr8qUmtrL/ yfHw4jgc+/HSiyp1jvZMQmbdfoVnAMUE2ui4ZuBDqd6FatycClWZza8I2A0wWB82FME4 FU86+HKwLo22DT4qc/ModqayIdoUNC4RlyxZqs7rapu/quuXnz362eHFdrleZ/T8NBW5 VZGbZUU8TzYBriXgMnmxRAmcNMr2blRPO/lPjoFZLSSiFziHb1CiQMRqhpQLCWkXK3dq 7XFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=u1s2SODLN8X1WWwpBCVJ8/YQskrKPclczxiJDRai2IQ=; b=ZtrdUNOeYt898Uq9l/DbwDpCYXryHqNK3PdS4gWSKEUDTJSZGsDCjyIpbqzMAxNBFy CKF9lvTinwNU21uxTzFfs6AAniiGpSFEkSbE2yewvIb3RdzfSCYyjbBxlYpHIFH1RDp6 DsF4oB6PaFtNrNugg2gx8SOuTyjvPmMx/QeOUceHdcxLgNYFAf5E7PeRqPBm68DfL5HK WbXAjRw3WZ4IwIawvWomSAodZug1TIraQb8AUzIGOELzYSK1EyybKkkPqgw6XoJt1Quc d5aejUc3EcYflw5qDilWpzy6P4T6CclmFdc5BdRe9uSlFrCegAsXx3+heZGTSSmQ+KqH 8piA== X-Gm-Message-State: AG10YOQxO1wmSUGIBhzr06puB3AN/i7sZnQLhKgPh47bj5W5fvRbY2H+f2e4s4MA7piEqNxATKCDMORSjWxq7w== MIME-Version: 1.0 X-Received: by 10.112.137.228 with SMTP id ql4mr2175772lbb.49.1456176177306; Mon, 22 Feb 2016 13:22:57 -0800 (PST) Received: by 10.112.161.106 with HTTP; Mon, 22 Feb 2016 13:22:57 -0800 (PST) In-Reply-To: References: <20160218205206.GW17997@ZenIV.linux.org.uk> <20160219002539.GX17997@ZenIV.linux.org.uk> <20160219222221.GB17997@ZenIV.linux.org.uk> <20160220133651.GG17997@ZenIV.linux.org.uk> Date: Mon, 22 Feb 2016 16:22:57 -0500 Message-ID: Subject: Re: Orangefs ABI documentation From: Mike Marshall To: Al Viro Cc: Martin Brandenburg , Linus Torvalds , linux-fsdevel , Stephen Rothwell , Mike Marshall Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,T_DKIM_INVALID,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP I did this and the problem seems fixed: # git diff Of course, this has uncovered yet another reproducible problem: 710055 orangefs_unlink: called on PPTB1E4.TMP 710058 service_operation: orangefs_unlink ffff880014828000 right in here I think the rm is being processed in the server just as the client-core has died. 710534 wait_for_matching_downcall: operation purged ffff880014828000 710538 service_operation: orangefs_unlink ffff880014828000 710539 service_operation:client core is NOT in service right in here I think stuff starts working again and we're going to unsuccessfully try to process the rm again. 710646 wait_for_matching_downcall returned 0 for ffff880014828000 happy, because we got the matching downcall 710647 service_operation orangefs_unlink returning -2 for ffff880014828000 710648 orangefs_unlink: service_operation returned -2 sad, because we got ENOENT on second rm 710649 Releasing OP ffff880014828000 so... the userspace process (dbench in this case) thinks the rm failed, but it didn't. On Mon, Feb 22, 2016 at 11:20 AM, Mike Marshall wrote: > > Looks like I'd screwed up checking last time. > > Probably not that ... my branch did diverge over the course > of the few days that we were thrashing around in the kernel trying > to fix what I had broken two years ago in userspace. > > I can relate to why you were motivated to remove the thrashing > around from the git history, but your git-foo is much stronger > than mine. I wanted to try and get my branch back into line using > a methodology that I understand to keep from ending up like > this fellow: > > http://myweb.clemson.edu/~hubcap/harris.jpg > > I'm glad it worked out... my kernel.org for-next branch is updated now. > > so, I'll keep working the problem, using your d_drop idea first off... > I'll be back with more information, and hopefully even have it fixed, soon... > > -Mike > > On Sat, Feb 20, 2016 at 8:36 AM, Al Viro wrote: >> On Sat, Feb 20, 2016 at 07:14:26AM -0500, Mike Marshall wrote: >> >>> Your orangefs-untested branch has 5625087 commits. My "current" branch >>> has 5625087 commits. In each all of the commit signatures match, except >>> for the most recent 15 commits. The last 15 commits in my "current" >>> branch were made from your orangefs-untested branch with "git format-patch" >>> and applied to my "current" branch with "git am -s". "git log -p" shows that >>> my most recent 15 commits differ from your most recent 15 commits by >>> the addition of my "sign off" line. >> >> *blinks* >> *checks* >> >> OK, ignore what I asked, then. Looks like I'd screwed up checking last time. >> >>> I will absolutely update my kernel.org for-next branch with the procedure you >>> outlined, because you said so. >>> >>> I wish I understood it better, though... I can only guess at this point that >>> the procedure you outlined will do some desirable thing to git metadata...? >> >> None whatsoever, ignore it. --- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/fs/orangefs/namei.c b/fs/orangefs/namei.c index b3ae374..249bda5 100644 --- a/fs/orangefs/namei.c +++ b/fs/orangefs/namei.c @@ -61,6 +61,7 @@ static int orangefs_create(struct inode *dir, __func__, dentry->d_name.name); ret = PTR_ERR(inode); + d_drop(dentry); goto out; }