Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp2763214pxb; Tue, 21 Sep 2021 07:11:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyvazP+TEcs/1Ei33q/X4Uqprc7Ht+OMH17Nbc/IUt72+UBxaJI71iTDddgjyNcTztUNCN3 X-Received: by 2002:a17:906:f8d4:: with SMTP id lh20mr35839948ejb.382.1632233464648; Tue, 21 Sep 2021 07:11:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632233464; cv=none; d=google.com; s=arc-20160816; b=j/Ys6/L24UgSHGcvZaFAKl0MZAISq/8Ez6J316A3vR/FTLBjPLFmAc5ujIvDk40TI8 3GlLjAT/duPhnL6n0+k9EgWHKOk7+IHxL948mVptYgQKb4dQuZ6fWtGst/GlUBeowd6L 90usQ9wxtPpV5Qgkv/WVNkqNTRk7lKccxhLWJwEYpBvdGZksQ2f1Qhp6XI//C69tQ5Cr pTjz1P1SbtQfGIGh9emfFxpfqWaf4/Y+IVLe1l+5sE1OwLvWoZOFkD+1eTVeWUKgJ9xm +UqTUKyo1MXFVqrwDr1ihBDrYLoJOxgzqY7Lk33etVTL3n82QubApRrHjQF5/tJ/80iz fDGw== 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=E557MN5H/z8gMR1F1UOzgrMHbd/CGDwH5EaTlthnE2Q=; b=sTp/b8zrOd4Rt62y0ezAFfmO0LuyCrm5RQenAxrImXsXTrAntZ8m0673IKiENdYMoE AZMufcds/cbiE5uFQ2R1pQEPkeCpLdWKlUZXQQqnUvK2A4shFrAHoghgM5JgznRBalbf 6FLikOl4AcpAqsQkE8aLE7QZxL+KOrR+6qNiFtMKwRW2LUUi2fkn1EfP8juhWC1FNczu 8OsJGNdyDRqUBj1Z+hVao1TSEJseEYheZXlskwMFIlkhUrJAx9PyloB+gfMmwYSke9n9 W4gV+vCgEMU00YiAGZcjPEeO1l3M6VKw2W0XsrZCTiG6uBYzAUHUJYEney8ZNp8fAEcr bkOw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=v7PwXdhS; dkim=neutral (no key) header.i=@suse.de header.b="PKvj/vdO"; 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 y24si20611956edl.58.2021.09.21.07.10.36; Tue, 21 Sep 2021 07:11:04 -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=v7PwXdhS; dkim=neutral (no key) header.i=@suse.de header.b="PKvj/vdO"; 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 S233505AbhIUOHK (ORCPT + 99 others); Tue, 21 Sep 2021 10:07:10 -0400 Received: from smtp-out2.suse.de ([195.135.220.29]:40638 "EHLO smtp-out2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233448AbhIUOHJ (ORCPT ); Tue, 21 Sep 2021 10:07:09 -0400 Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id A1EFF2014A; Tue, 21 Sep 2021 14:05:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1632233139; 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=E557MN5H/z8gMR1F1UOzgrMHbd/CGDwH5EaTlthnE2Q=; b=v7PwXdhSncGdSn0M9Iq8A3YFGWARdPt3gbuo815jkU+soPK31djxrG92ITY9NNfKHraOal rA0KcBFdcdl+5Y1KKvi4EktFSrFglCPD3Fb2n9F4GBSa7dAmN4068mz/iwksfh1R8oErRg 3GNQHficINR3MCbjv/JZLme3g1KsVzk= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1632233139; 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=E557MN5H/z8gMR1F1UOzgrMHbd/CGDwH5EaTlthnE2Q=; b=PKvj/vdOw6eDti9HjiU84sIJYlLtvn8+PLaYrxEPOXszzqowYIXPaJNymb5oe/3evCNwNm kVstYJmGCMCSJDBQ== 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 DCD40A3B84; Tue, 21 Sep 2021 14:05:38 +0000 (UTC) References: <20210921130127.24131-1-rpalethorpe@suse.com> 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: Date: Tue, 21 Sep 2021 15:05:38 +0100 Message-ID: <87o88mkor1.fsf@suse.de> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. -- Thank you, Richard.