Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934499AbcCPER0 (ORCPT ); Wed, 16 Mar 2016 00:17:26 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:56468 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750962AbcCPERX (ORCPT ); Wed, 16 Mar 2016 00:17:23 -0400 Date: Wed, 16 Mar 2016 04:17:18 +0000 From: Al Viro To: Mike Marciniszyn Cc: linux-rdma@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Linus Torvalds Subject: [WTF] utterly tasteless ABI in hfi1 (around ->write()/->write_iter()) Message-ID: <20160316041717.GJ17997@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1664 Lines: 30 Folks, we'd discussed that kind of crap already; why, in name of everything unholy, is that kind of garbage brought back in a new driver? Having both ->write() and ->write_iter() *AND* having entirely unrelated interpretation of user input on those two on the same device is bogus, with the capital Stop That Shit Right Now. As it is, write(fd, p, len) and writev(fd, &(struct iovec){p,len}, 1) are interpreted in absolutely unrelated ways. As in, entirely different set of commands. Moreover, aio IOCB_CMD_PWRITE matches writev(), not write(). What's going on? Sure, ipathfs is a precious snowflake with the same kind of braindamage. Back when it had been brought to your attention (along with the fact that this piece of idiocy happens to be a file on filesystem of your own, under your full control and no need whatsofuckingever to multiplex completely unrelated sets of commands on the same file with "was it write(2) or writev(2)?" used as a selector) the answer had been basically "it doesn't have to make sense, it's Special". Now it turns out that it has grown an equally special sibling. With the idiocy directly exposed as userland ABI. Could we please fix that thing before it's cast in stone? Take a look at drivers/staging/rdma/hfi1/file_ops.c in -next and compare hfi1_write_iter() with hfi1_file_write(). Folks, this ABI is too ugly to live, let alone to be allowed breeding. It's also brittle as hell - trivial massage around fs/read_write.c and fs/aio.c is quite capable of breaking that shit. Arguably, IOCB_CMD_PWRITE and IOCB_CMD_PWRITEV both triggering your writev() semantics is an example of just such breakage. Sigh...