From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f196.google.com ([209.85.192.196]:36796 "EHLO mail-pf0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751600AbdARIXg (ORCPT ); Wed, 18 Jan 2017 03:23:36 -0500 Subject: Re: utimensat EACCES vs. EPERM in 4.8+ To: Miklos Szeredi , Cyril Hrubis References: <18a5b416-ad6a-e679-d993-af7ffa0dcc10@redhat.com> <280513509.810300.1484639500985.JavaMail.zimbra@redhat.com> <20170117075702.GB10417@rei.lan> Cc: mtk.manpages@gmail.com, Jan Stancek , linux-fsdevel , viro , guaneryu@gmail.com, ltp@lists.linux.it, Linux API , Dave Chinner From: "Michael Kerrisk (man-pages)" Message-ID: Date: Wed, 18 Jan 2017 21:23:19 +1300 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Hi Miklos, On 01/17/2017 10:39 PM, Miklos Szeredi wrote: > On Tue, Jan 17, 2017 at 8:57 AM, Cyril Hrubis wrote: >> Hi! >>>> Jan, thanks for spotting this. >>> >>> Credit goes to Cyril. As for LTP-20170116 (released yesterday) we went >>> with current documented behavior - few failures are expected on 4.8+. >> >> Actually credit goes to SUSE QAM that caught the change on kernel >> update :-). > > And while this makes for a nice discussion, it is almost completely > irrelevant in real life, since the only thing broken by this change > will be test suites (in other words immutable files are rare as hen's > teeth). While I agree that the chances of breakage may be quite small (though I certainly won't be so bold as to assert that only test suites will get broken), your comment misses the important metapoint: changes like this should not just be getting waved through the gate without some analysis along the lines of what I did. "Consistency" and an (incorrect) assertion that "In most cases, EPERM is returned on immutable inode" just don't cut it, when it comes to making changes of this sort. > If you find that this change actually breaks something other than a > test suite, then yes, please lets revert it. No. That is not a strategy. I already said it, but I'll say it again: sometimes these reports only arrive many months or even years later. And then we can end up with fiascoes such as F_SETOWN/F_SETOWN_EX. (Essentially: F_SETOWN got subtly changed, and by the time people realized the breakage had occurred it was *years* late. Too late to revert... So, then we got F_SETOWN_EX to allow us what F_SETOWN used to do. See fcntl(2).) > Otherwise there's not > much point (distros can revert it for themselves if they want be > paranoid). Also not a strategy; distros don't want to carry such junk patches. All of this said, I still don't know whether reverting the patch is warranted... Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/