Received: by 10.213.65.68 with SMTP id h4csp1802848imn; Thu, 29 Mar 2018 11:18:44 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/0dqAJ23h2fjakP6bAM7k8Ai6fDEXuqdsTJBLgowJaLSSCENZjWAes7NcUgwrZynp1B8lE X-Received: by 2002:a17:902:64cf:: with SMTP id y15-v6mr9630468pli.49.1522347524617; Thu, 29 Mar 2018 11:18:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522347524; cv=none; d=google.com; s=arc-20160816; b=sDNBFqtK66aS9gL4Ko7ljnU3DuVKQHJz98fiIqTPYQ4aODH5ZrWPR2QZYGXMRGR0V0 TyPF/NQKCSL4Rpb9ng3QumVgOnGJfAauatyfxqCfL1yo34AcYWnLV9O48Ekm8VeQIQJK 0iITJ+4g8p9oDI9Z9+pfx1sJY0C9grIvWIL+Pz764GKigWamE9qDn62IOzDOVQiXgE2Q +Ao9htJYnfH429XJPaAmXmmhCwQgKXBOTzTg+KHv5zBNm6Ak9weEzDl83ehQUAuDNZtl w/TodkFweMlfFJe2AIQL68JUxThnynUX/MCkLcp5sxAuM8p74mcTFUGbqHE4flfaLjgI oizQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=SEomopbO/BjtLWjrWgD8SbRa6jI+6Y/t1mWATo9EXDQ=; b=NY15kNT8nG2xjaQPoVLoJv575ZTpsJ2yTqCbAJVI+X2AECntME4P3Ne2cvrfS719UQ OvAGrha35MVRnIZZe6H8H26M69vVtr0uYoG9cglHXcmpts72I3CQXPU6A9nu8k8y/SvP eEi3F1AGpE8GUmSk7FFo2jYKeFQU3PnOv80hvRsKRSTbg96/kv+0jvt8T7C+XCAqnLxl Z9s7GuQ5W/yq7nmQ0phbOSn6n0wzmRG/r863/RJeBYR/lIgSLL9xTiVoB6AbbHRwhOfH f2MvXlRUeAKbQCID5+48Eojhd3+zJWsAMcvdpptvK+Kcg31dEU6OPYAhPUfAqMXl+k5R 9MpA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@toxicpanda-com.20150623.gappssmtp.com header.s=20150623 header.b=XL9REcoj; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f10-v6si6362430pln.359.2018.03.29.11.18.30; Thu, 29 Mar 2018 11:18:44 -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=@toxicpanda-com.20150623.gappssmtp.com header.s=20150623 header.b=XL9REcoj; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754069AbeC2SRU (ORCPT + 99 others); Thu, 29 Mar 2018 14:17:20 -0400 Received: from mail-qk0-f178.google.com ([209.85.220.178]:42356 "EHLO mail-qk0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753545AbeC2SRP (ORCPT ); Thu, 29 Mar 2018 14:17:15 -0400 Received: by mail-qk0-f178.google.com with SMTP id b198so6891485qkg.9 for ; Thu, 29 Mar 2018 11:17:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=SEomopbO/BjtLWjrWgD8SbRa6jI+6Y/t1mWATo9EXDQ=; b=XL9REcoj1QLu9vD1Xgy8tVnL0c9ElnELeK4x+tQjp22m033en3jLPd55PsNBIZvrw/ csEyJZAELmm1qe/YnrcTm50aW0Lc0CiGiYxdNENe0WGcBPNS9EFJFUdTh5WrvbX+LlEs tWFW4p5SlejvVKyJQmpp/lriAyu2tfgHUq6i1HRUH4pYEa0T559DYSTEJcXWtHitCaSk MpFhI2wsTREkKIxxRvXKNX5Zqgf21n9ttAX0oxHTgVrHeGcNqZ/GF21OAvg+9nWcbI6F vod/AMv2cweYE/LBNjZ0tbZjePL2qAbh6gGK5RH314XCJnSdNlMM/ug6iZf1AS51cQ0R rovQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=SEomopbO/BjtLWjrWgD8SbRa6jI+6Y/t1mWATo9EXDQ=; b=JJF7aKs0uRKt6T/18a5XGDMfDeRdOJVk61Pc7p7QLwYj+exb5NZKIcELKe76VBCSdF MA2WgDSQE2NbvuwDAVU8iON55FwwUgzBzg5LyMqi9a5QVeYkrn2hYH16LR/elCrrkpok I46FZLdrwxpzfIu8zi+YfLeSe5F0K6kd8WTkvGj41XACcqlpYat/aq1UZcnUqloXfhGc p5D9E2CLL74u3LHtbN2ly7xQ2V4BVW431jlkf50XJI2TlJsCG0jDEPc51AcMVz1E99xV GzgXG7V22IKGjEGPkpXxl7jMg7qYUmeZC/XA2fZbjs0xcmUTwxSV8/6eRf384GDW8e3n A1ng== X-Gm-Message-State: ALQs6tAlyIlkOmgQztUya/U3vQPrShCQKK3Y6R/R9yVe/2EG9KFZCl62 nuvZffHAYgkABYlJcCcmZ9yJ1Q== X-Received: by 10.233.230.75 with SMTP id x11mr12287204qkl.316.1522347435054; Thu, 29 Mar 2018 11:17:15 -0700 (PDT) Received: from localhost (cpe-2606-A000-4381-1201-225-22FF-FEB3-E51A.dyn6.twc.com. [2606:a000:4381:1201:225:22ff:feb3:e51a]) by smtp.gmail.com with ESMTPSA id c25sm4740769qtn.9.2018.03.29.11.17.14 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 29 Mar 2018 11:17:14 -0700 (PDT) Date: Thu, 29 Mar 2018 14:17:13 -0400 From: Josef Bacik To: "Luis R. Rodriguez" Cc: Dave Chinner , Sasha Levin , Sasha Levin , "Darrick J. Wong" , Christoph Hellwig , xfs , "linux-kernel@vger.kernel.org List" , Greg Kroah-Hartman , Julia Lawall , Josh Triplett , Takashi Iwai , Michal Hocko , Joerg Roedel , Anna Schumaker , Josef Bacik , Tso Ted Subject: Re: [PATCH] xfs: always free inline data before resetting inode fork during ifree Message-ID: <20180329181712.ijbruc7rl2i3nh35@destiny> References: <20180323034145.GH4818@magnolia> <20180323170813.GD30543@wotan.suse.de> <20180323172620.GK4818@magnolia> <20180323182302.GB9190@wotan.suse.de> <20180325223357.GJ18129@dastard> <20180328033228.GA18129@dastard> <20180328193004.GB7561@sasha-vm> <20180328230535.GE18129@dastard> <20180329181223.GK30543@wotan.suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180329181223.GK30543@wotan.suse.de> User-Agent: NeoMutt/20170714 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 29, 2018 at 06:12:23PM +0000, Luis R. Rodriguez wrote: > On Thu, Mar 29, 2018 at 10:05:35AM +1100, Dave Chinner wrote: > > On Wed, Mar 28, 2018 at 07:30:06PM +0000, Sasha Levin wrote: > > > > > > This is actually something I want maintainers to dictate. What sort of > > > testing would make the XFS folks happy here? Right now I'm doing > > > "./check 'xfs/*'" with xfstests. Is it sufficient? Anything else you'd like to see? > > > > ... and you're doing it wrong. This is precisely why being able > > to discover /exactly/ what you are testing and being able to browse > > the test results so we can find out if tests passed when a user > > reports a bug on a stable kernel. > > > > The way you are running fstests skips more than half the test suite > > It also runs tests that are considered dangerous because they are > > likely to cause the test run to fail in some way (i.e. trigger an > > oops, hang the machine, leave a filesystem in an unmountable state, > > etc) and hence not complete a full pass. > > > > "./check -g auto" runs the full "expected to pass" regression test > > suite for all configured test configurations. (i.e. all config > > sections listed in the configs/.config file) > > ie, it would be safer to expect that an algorithmic auto-selection process for > fixes for stable kernels should have direct input and involvement from > subsystems for run-time testing and simply guessing or assuming won't suffice. > > The days of just compile testing should be way over by now, and we should > expect no less for stable kernels, *specially* if we start involving > automation. > > Would a way to *start* to address this long term for XFS or other filesystems > for auto-selection long-term be a topic worth covering / addressing at LSF/MM? > It would be cool to tie tests to commit numbers for things where we're making sure a oops/hang doesn't happen again, but honestly I'm not sure it's worth the effort. Maybe this is my upstream bias showing, but I only ever run xfstests against something relatively close to linus, so I'm not super worried about ./check -g auto eating my box. I expect that if I run auto that everything minus the few flakey tests are going to pass. Also TIL about configs/.config, that's pretty fucking cool. Thanks, Josef