linux-kernel - [glibc] preadv/pwritev question

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 31 May 2016 23:04:54 +0300
From:	Yury Norov <ynorov@...iumnetworks.com>
To:	<cmetcalf@...lanox.com>
CC:	<cmetcalf@...era.com>, <arnd@...db.de>, <catalin.marinas@....com>,
	<linux-kernel@...r.kernel.org>, <libc-alpha@...rceware.org>,
	<pinskia@...il.com>
Subject: [glibc] preadv/pwritev question

Hi Chris,

In path a63c7fa18a (Add sysdeps/unix/sysv/linux/generic/.) you add
this:
+++ b/sysdeps/unix/sysv/linux/generic/wordsize-32/preadv.c

[...]

+static ssize_t
+do_preadv (int fd, const struct iovec *vector, int count, off_t
offset)
+{
+  assert (sizeof (offset) == 4);
+  return INLINE_SYSCALL (preadv, __ALIGNMENT_COUNT (5, 6), fd,
+                         vector, count, __ALIGNMENT_ARG
+                         __LONG_LONG_PAIR (offset >> 31, offset));
+}
+

And this is the code that is picked up if I choose wordsize-32 for my
AARCH64/ILP32. So I have questions.

1. What is the assert for? We agreed that all new ABIs will be 64-bit
off_t only.

I fixed it internally like this:
+#ifndef __OFF_T_MATCHES_OFF64_T
        assert (sizeof (offset) == 4);
+#endif

There is a bunch of similar assertions in glibc.

2. This one looks weird:
__LONG_LONG_PAIR (offset >> 31, offset))
Why 31-bit offset? And why you don't mask 2nd argument?
Later in your patch I see this:
+static ssize_t
+do_preadv64 (int fd, const struct iovec *vector, int count, off64_t
offset)

+{
+  return INLINE_SYSCALL (preadv, __ALIGNMENT_COUNT (5, 6), fd,
+                         vector, count, __ALIGNMENT_ARG
+                         __LONG_LONG_PAIR ((off_t) (offset >> 32),
+                                           (off_t) (offset & 0xffffffff)));
+}

And it looks correct to me. If 1st version is correct as well, I think
it should be commented.

Yury.