From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A5E76C17444 for ; Mon, 11 Nov 2019 08:19:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7D3F7204EC for ; Mon, 11 Nov 2019 08:19:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="FwF58rCx" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726903AbfKKITz (ORCPT ); Mon, 11 Nov 2019 03:19:55 -0500 Received: from us-smtp-2.mimecast.com ([205.139.110.61]:44174 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726804AbfKKITx (ORCPT ); Mon, 11 Nov 2019 03:19:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1573460391; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Y+d9HgiQd/ROeqheIWevtzZ1281FA0vSMCBkopaTcHI=; b=FwF58rCxdF5GKETwfEzbwtY0BWIdJrh4iE8J2MBZTRJg9hvhBysz18IyM2z+pIBSeDwcUD nghUnYQY+6VPqOuw7CoppXStiQ2n+lSRH6UmnY/hFmytRuaMMeLjHDUVmCJWoDZhVlzCb8 iC6wsiznt0ALFb0IJcjRFirktUovEic= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-378-_0XAJepROSaUejme0jEEIQ-1; Mon, 11 Nov 2019 03:19:44 -0500 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 0CAFC107ACC4; Mon, 11 Nov 2019 08:19:42 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6BFE4100EBA6; Mon, 11 Nov 2019 08:19:41 +0000 (UTC) Received: from zmail17.collab.prod.int.phx2.redhat.com (zmail17.collab.prod.int.phx2.redhat.com [10.5.83.19]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id 9754118089C8; Mon, 11 Nov 2019 08:19:40 +0000 (UTC) Date: Mon, 11 Nov 2019 03:19:40 -0500 (EST) From: Jan Stancek To: "Darrick J. Wong" Cc: Naresh Kamboju , LTP List , Linux-Next Mailing List , linux-fsdevel@vger.kernel.org, chrubis , open list , Al Viro , Mark Brown , Arnd Bergmann , lkft-triage@lists.linaro.org, Christoph Hellwig , linux-ext4 , Theodore Ts'o Message-ID: <1751469294.11431533.1573460380206.JavaMail.zimbra@redhat.com> In-Reply-To: <20191111012614.GC6235@magnolia> References: <852514139.11036267.1573172443439.JavaMail.zimbra@redhat.com> <20191111012614.GC6235@magnolia> Subject: Re: LTP: diotest4.c:476: read to read-only space. returns 0: Success MIME-Version: 1.0 X-Originating-IP: [10.43.17.163, 10.4.195.18] Thread-Topic: diotest4.c:476: read to read-only space. returns 0: Success Thread-Index: OoFxfOUloBUkdPsY/du59GUryWTVqQ== X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-MC-Unique: _0XAJepROSaUejme0jEEIQ-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: linux-next-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-next@vger.kernel.org ----- Original Message ----- > I can't do a whole lot with a code snippet that lacks a proper SOB > header. I'll resend as a patch, maybe split it to 2 returns instead. > > diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c > > index 2f88d64c2a4d..8615b1f78389 100644 > > --- a/fs/iomap/direct-io.c > > +++ b/fs/iomap/direct-io.c > > @@ -318,7 +318,7 @@ iomap_dio_bio_actor(struct inode *inode, loff_t pos= , > > loff_t length, > > if (pad) > > iomap_dio_zero(dio, iomap, pos, fs_block_size - > > pad); > > } > > - return copied ? copied : ret; > > + return copied ? (loff_t) copied : ret; >=20 > I'm a little confused on this proposed fix -- why does casting size_t > (aka unsigned long) to loff_t (long long) on a 32-bit system change the > test outcome? Ternary operator has a return type and an attempt is made to convert each of operands to the type of the other. So, in this case "ret" appears to be converted to type of "copied" first. Both have size of 4 bytes on 32-bit x86: size_t copied =3D 0; int ret =3D -14; long long actor_ret =3D copied ? copied : ret; On x86_64: actor_ret =3D=3D -14; On x86 : actor_ret =3D=3D 4294967282 > Does this same diotest4 failure happen with XFS? I ask > because XFS has been using iomap for directio for ages. Yes, it fails on XFS too.