Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp2839554pxb; Tue, 21 Sep 2021 08:45:36 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy4Oyy/ed6sO2jEE8LdPaPqW7R64DyGmUnPUFNxq1oXW4iXV7uZdSOMCnLrf5nJIq9gejEw X-Received: by 2002:a92:d2c7:: with SMTP id w7mr21594594ilg.71.1632239136411; Tue, 21 Sep 2021 08:45:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632239136; cv=none; d=google.com; s=arc-20160816; b=sErxIzoMb+RAkLG098J5qHlA+s1BQeuwzNtEc16eo4RlG4ZWCXkJf8fU6GB/MDMGGu TYs0LUysEpOUHJGaGA7bJ+oQKOmqwDoCq+KqZtfAKIXAwTSG3AEqff+ZJqqL27YUTihS WoWLM/YxjnGZ4H9adcgCGeufQ9+R2/UID53l9tm6IGM9ZC0YPHuGtxeoXBUL4BWBKzZ7 bomVMq3xzvx2WzO/Q5oyF2SzIlWn8Z5m3dKJk8lXHtCvo2QWeMX1iGjFEWdzd3QAYIiK 0pn3PDt8awn658f6HOQjXKoNPQk/OeuyTGu+9iQBK7KfRiUbVNmLJ1jOm5cxNfMFtuuj 7QaQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:in-reply-to :reply-to:subject:cc:to:from:user-agent:references:dkim-signature :dkim-signature; bh=g8TCxuVhcJ0aOSOQszQs+SEKF8ruKKtOdrYv4ag1Tu8=; b=RasxD5Kp5/RNNSH07oZ9UA8VNSS/pv/N71Tc6mYBxsVKxm2hMBusZrbojEVpZ+joYB YaefSv/D84NFpDElL0m0K6D0HIHvbRWiWTmaN5+wylet1NZk4l6sevNEg4dkbIF1tcRV 7533tLGVHSxN9JeaOaljo9q0gYEyX99UV95MomP+Ls3X7u3SehttMegVPnViO6Yt4zQZ lMTCKOLbyVOxuzmiK/khFAZGUKdCkgDCL6d7EjG1dYJG424rzoUcNXHQwPFDB+M7k57N Xw9c7nctnO0WuTNoZpQhJkwvsc2oNweoQz43pxFJLrIJyXR2fiaBqdlgzXwrPg2YbMPo zFAQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=Ogah1pgv; dkim=neutral (no key) header.i=@suse.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p16si17246251iov.22.2021.09.21.08.45.21; Tue, 21 Sep 2021 08:45:36 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=Ogah1pgv; dkim=neutral (no key) header.i=@suse.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234133AbhIUPph (ORCPT + 99 others); Tue, 21 Sep 2021 11:45:37 -0400 Received: from smtp-out2.suse.de ([195.135.220.29]:39708 "EHLO smtp-out2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234089AbhIUPpd (ORCPT ); Tue, 21 Sep 2021 11:45:33 -0400 Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id A198220174; Tue, 21 Sep 2021 15:44:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1632239042; h=from:from:reply-to:reply-to:date:date:message-id:message-id:to:to: cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=g8TCxuVhcJ0aOSOQszQs+SEKF8ruKKtOdrYv4ag1Tu8=; b=Ogah1pgvl8xk9ZPw7BQKtCsghSnYRj7fAWKgMNEBUbfn3klyk3xf36fVD0tlLKc+ep8H/r Q6SxRHExcdk9dZdXbzuUeP9hhJDye2lHovxdp0OlVUG6l3xnjJ8kLQffzpw1RxWV+wOKen rHvcVifx3pU6V5CcKm3hZeX4+KG0h60= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1632239042; h=from:from:reply-to:reply-to:date:date:message-id:message-id:to:to: cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=g8TCxuVhcJ0aOSOQszQs+SEKF8ruKKtOdrYv4ag1Tu8=; b=lM6PcshEOVQ3rTh1uzm0KxL1ZnkG+SChIzwxT9vGN1dzMX6Mb+bBPADb3rVgmVp0pKHov2 aNneKdfQrP1P1MCQ== Received: from g78 (unknown [10.163.24.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id C6D53A3B88; Tue, 21 Sep 2021 15:44:01 +0000 (UTC) References: <20210921130127.24131-1-rpalethorpe@suse.com> <87o88mkor1.fsf@suse.de> User-agent: mu4e 1.4.15; emacs 27.2 From: Richard Palethorpe To: Arnd Bergmann Cc: Linux FS-devel Mailing List , Linux API , linux-aio , "y2038 Mailman List" , Andy Lutomirski , Thomas Gleixner , Ingo Molnar , Borislav Petkov , the arch/x86 maintainers , "H. Peter Anvin" , Deepa Dinamani , Linux Kernel Mailing List , LTP List Subject: Re: [PATCH] aio: Wire up compat_sys_io_pgetevents_time64 for x86 Reply-To: rpalethorpe@suse.de In-reply-to: <87o88mkor1.fsf@suse.de> Date: Tue, 21 Sep 2021 16:44:01 +0100 Message-ID: <87lf3qkk72.fsf@suse.de> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Richard Palethorpe writes: > Hello Arnd, > > Arnd Bergmann writes: > >> On Tue, Sep 21, 2021 at 3:01 PM Richard Palethorpe wrote: >>> >>> The LTP test io_pgetevents02 fails in 32bit compat mode because an >>> nr_max of -1 appears to be treated as a large positive integer. This >>> causes pgetevents_time64 to return an event. The test expects the call >>> to fail and errno to be set to EINVAL. >>> >>> Using the compat syscall fixes the issue. >>> >>> Fixes: 7a35397f8c06 ("io_pgetevents: use __kernel_timespec") >>> Signed-off-by: Richard Palethorpe >> >> Thanks a lot for finding this, indeed there is definitely a mistake that >> this function is defined and not used, but I don't yet see how it would >> get to the specific failure you report. >> >> Between the two implementations, I can see a difference in the >> handling of the signal mask, but that should only affect architectures >> with incompatible compat_sigset_t, i.e. big-endian or >> _COMPAT_NSIG_WORDS!=_NSIG_WORDS, and the latter is >> never true for currently supported architectures. On x86, there is >> no difference in the sigset at all. >> >> The negative 'nr' and 'min_nr' arguments that you list as causing >> the problem /should/ be converted by the magic >> SYSCALL_DEFINE6() definition. If this is currently broken, I would >> expect other syscalls to be affected as well. > > That is what I thought, but I couldn't think of another explanation for > it. > >> >> Have you tried reproducing this on non-x86 architectures? If I >> misremembered how the compat conversion in SYSCALL_DEFINE6() >> works, then all architectures that support CONFIG_COMPAT have >> to be fixed. >> >> Arnd > > No, but I suppose I can try it on ARM or PowerPC. I suppose printing the > arguments would be a good idea too. It appears it really is failing to sign extend the s32 to s64. I added the following printks modified fs/aio.c @@ -2054,6 +2054,7 @@ static long do_io_getevents(aio_context_t ctx_id, long ret = -EINVAL; if (likely(ioctx)) { + printk("comparing %ld <= %ld\n", min_nr, nr); if (likely(min_nr <= nr && min_nr >= 0)) ret = read_events(ioctx, min_nr, nr, events, until); percpu_ref_put(&ioctx->users); @@ -2114,6 +2115,8 @@ SYSCALL_DEFINE6(io_pgetevents, bool interrupted; int ret; + printk("io_pgetevents(%lx, %ld, %ld, ...)\n", ctx_id, min_nr, nr); + if (timeout && unlikely(get_timespec64(&ts, timeout))) return -EFAULT; Then the output is: [ 11.252268] io_pgetevents(f7f19000, 4294967295, 1, ...) [ 11.252401] comparing 4294967295 <= 1 io_pgetevents02.c:114: TPASS: invalid min_nr: io_pgetevents() failed as expected: EINVAL (22) [ 11.252610] io_pgetevents(f7f19000, 1, 4294967295, ...) [ 11.252748] comparing 1 <= 4294967295 io_pgetevents02.c:103: TFAIL: invalid max_nr: io_pgetevents() passed unexpectedly -- Thank you, Richard.