From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 026BF63BC for ; Thu, 6 Apr 2023 13:17:59 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 1EAB11FD76; Thu, 6 Apr 2023 13:17:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1680787078; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=AfC7CMPXeeRMiPKxLyM3C13TOXBtHVBske2Zh3FAELY=; b=jz4wQSjNwiTLPukTzWuoOY3ua0xRuJciJdXDRsbi9kNotTXtegJTpyHUDpAW9erXwGzNSk L66Rjygnz+Y0LaU/6wU43bNPjQHz2TW/EaraJ+U93a4phnG5AJO1if1ZP/6bUr2Ty5mYxa ryQmHMtNROJKsQ4cbTv4G7wkrnRp8Xo= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1680787078; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=AfC7CMPXeeRMiPKxLyM3C13TOXBtHVBske2Zh3FAELY=; b=GJxuSPA7soPWU8u482+5aSlrmq9WnEviWybvmmcG3PJJ+HGT5looaU/dsNoaWo+bPAErlP tTEGOP+6eIo8UzAw== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 37D64133E5; Thu, 6 Apr 2023 13:17:57 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id vmNhCoXGLmTWBQAAMHmgww (envelope-from ); Thu, 06 Apr 2023 13:17:57 +0000 Date: Thu, 6 Apr 2023 15:17:55 +0200 From: Petr Vorel To: Arnd Bergmann Cc: Naresh Kamboju , open list , LTP List , llvm@lists.linux.dev, chrubis , Nathan Chancellor , Anders Roxell , Daniel =?iso-8859-2?Q?D=EDaz?= , Benjamin Copeland , Tudor Cretu Subject: Re: LTP: list of failures on 32bit and compat mode Message-ID: <20230406131755.GA1608262@pevik> Reply-To: Petr Vorel References: <96b67ae8-98dd-40fe-9dde-302e09d12551@app.fastmail.com> <20230406105646.GB1545779@pevik> <7234b8ab-db5c-4f4a-bb9e-ddef9f1a50d3@app.fastmail.com> <20230406124812.GA1589248@pevik> <3c2ba6f9-bea1-4510-8fbb-6521fab74a9d@app.fastmail.com> Precedence: bulk X-Mailing-List: llvm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3c2ba6f9-bea1-4510-8fbb-6521fab74a9d@app.fastmail.com> > On Thu, Apr 6, 2023, at 14:48, Petr Vorel wrote: > >> On Thu, Apr 6, 2023, at 12:56, Petr Vorel wrote: > >> Ah, I see. This must be the padding code then, not the time64 > >> conversion: > >> +int recvmmsg(int fd, struct mmsghdr *msgvec, unsigned int vlen, unsigned int flags, struct timespec *timeout) > >> +{ > >> +#if LONG_MAX > INT_MAX > >> + struct mmsghdr *mh = msgvec; > >> + unsigned int i; > >> + for (i = vlen; i; i--, mh++) > >> + mh->msg_hdr.__pad1 = mh->msg_hdr.__pad2 = 0; > >> +#endif > > I suppose this is a suggestion for fix in LTP. I'd expect is should go into > > testcases/kernel/syscalls/sendmmsg/sendmmsg_var.h into static inline int > > sys_recvmmsg(...) > > But that at least on glibc 64bit compilation does not see __pad1 member: > > ../sendmmsg/sendmmsg_var.h: In function ‘sys_recvmmsg’: > > ../sendmmsg/sendmmsg_var.h:47:28: error: ‘struct msghdr’ has no member > > named ‘__pad1’ > > 47 | mh->msg_hdr.__pad1 = mh->msg_hdr.__pad2 = 0; > > | ^ > Sorry, I should have been clearer, the snippet I cited is > from the musl sources, and the __pad access is what causes the > segfault. The fix is to catch the fault on ltp, same as for the > time64 conversions. Thanks! I've just searched in musl as well, because it didn't make sense to me it'd be a code for LTP. "to catch the fault on ltp" I wonder if it's not actually musl bug. Kind regards, Petr > Arnd