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
| ||
|
Date: Wed, 13 Apr 2016 14:21:21 -0700 From: Eric Dumazet <eric.dumazet@...il.com> To: Stephen Hemminger <stephen@...workplumber.org> Cc: netdev <netdev@...r.kernel.org> Subject: Re: [PATCH iproute2] ss: 64bit inode numbers On Wed, 2016-04-13 at 13:55 -0700, Stephen Hemminger wrote: > On Tue, 12 Apr 2016 15:22:29 -0700 > Eric Dumazet <eric.dumazet@...il.com> wrote: > > > From: Eric Dumazet <edumazet@...gle.com> > > > > Lets prepare for a possibility to have 64bit inode numbers for sockets, > > even if the kernel currently enforces 32bit numbers. > > > > Presumably, if both kernel and userland are 64bit (no 32bit emulation), > > kernel could switch to 64bit inode numbers soon. > > > > Signed-off-by: Eric Dumazet <edumazet@...gle.com> > > Why not use ino_t rather than __u64 which is really intended for kernel/user abi. > Then make code generic on sizeof inode type Well, maybe because code dealing with ino_t is very often buggy ;) For example iproute2 makes the assumption an ino_t can be printed using %lu format. This does not work with a 32bit binary. static void bpf_info_loop(int *fds, struct bpf_map_aux *aux) { int i, tfd[BPF_MAP_ID_MAX]; printf("ver: %d\nobj: %s\ndev: %lu\nino: %lu\nmaps: %u\n", aux->uds_ver, aux->obj_name, aux->obj_st.st_dev, aux->obj_st.st_ino, aux->num_ent); ... No strong preference from my side.
Powered by blists - more mailing lists