Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934523AbdC3SUD (ORCPT ); Thu, 30 Mar 2017 14:20:03 -0400 Received: from mail-it0-f43.google.com ([209.85.214.43]:36744 "EHLO mail-it0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934128AbdC3STz (ORCPT ); Thu, 30 Mar 2017 14:19:55 -0400 MIME-Version: 1.0 In-Reply-To: <20170330172159.GA24139@lst.de> References: <20170330163327.23920-1-hch@lst.de> <20170330172159.GA24139@lst.de> From: Linus Torvalds Date: Thu, 30 Mar 2017 11:19:53 -0700 X-Google-Sender-Auth: Wp_mRpPmKSbfwaAZSkv_BlT0Vnc Message-ID: Subject: Re: RFC: reject unknown open flags To: Christoph Hellwig Cc: Alexander Viro , Linux API , linux-fsdevel , Linux Kernel Mailing List , libc-alpha Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1176 Lines: 33 On Thu, Mar 30, 2017 at 10:21 AM, Christoph Hellwig wrote: > > Failure atomic file updates, aka O_ATOMIC: > > https://lwn.net/Articles/573092/ > > Currently the way to probe for it is a new ioctl to check if atomicy > is offered. This should work, but it's rather fragile.. So quite frankly, I'd much rather see that people who really want to check would instead just fd = open(... O_ATOMIC); if (fd < 0) .. regular error handling .. /* Did we actually get O_ATOMIC? */ if (!(O_ATOMIC & fnctl(fd, F_GETFL, NULL))) .. warn about lack of O_ATOMIC .. because I suspect that you will find users that might *want* atomic behavior, but in the absence of atomicity guarantees will want to still be able to do IO. The above kind of model seems much more straightforward, and has no backwards/forwards compatibility issues I can see. I'm assuming you'd also possible want to be able to use F_SETFL to set O_ATOMIC after the fact (independently of the open - I could see tools like "dd" growing an atomic flag and setting it on stdout), so the F_GETFL interface seems natural for that reason too. Linus