IRC channel logs
2023-07-30.log
back to list of logs
<damo22>i implemented a callwheel structure for timeouts as per Costello and Varghese 1995, it boots but netdde freezes trying to bring up eth0 <damo22>in thread_timeout, there is assert(thread->timer.set == TELT_UNSET); why is it unset at the time it gets called? <solid_black>I saw you sent your version of the patch for dropping segments on x86_64 <luckyluke>they should work for all the 32/64 build combinations, w/o kdb and so on <solid_black>I've briefly skimmed them yesterday, will try to look in more detail today <solid_black>I'm fighting with glibc now, trying to figure out fcntl/fcntl64 flock/flock64 things, for the nth time :| <luckyluke>I wonder if we still need the V86 stuff even in 32-bit builds.. <solid_black>well it's not exactly Hurd-related, although the Hurd is involved in this too <solid_black>and there are F_GETLK (and SET/SETW) and F_GETLK64, and also the OFD versions <solid_black>and my understanding was that you're supposed to always use F_GETLK with struct flock and F_GETLK64 with struct flock64, no matter fcntl or fcntl64 <solid_black>whereas for OFD locks, there's a single command that use flock or flock64 depending on whether you call fcntl or fcntl64 <solid_black>but it's more complicated, for one thing because there's an old compat symbol in glibc that makes flock *not* convert OFD fcntl () to fcntl64 (), so in the test that uses that symbol, it should still be using flock64 with fcntl <solid_black>but there's something else wrong in my mental model of this too, because sysdeps/unix/sysv/linux/tst-o_path-locks.c calls fcntl64 (F_SETLK, &flock64) <solid_black>but in the Hurd port everything seems to be 64-bit, so that's easier <luckyluke>probably because we can start fresh :) so in the hurd do we have flock == flock64 on x86_64? <solid_black>it's still technically two different structures, but they're the same yeah <solid_black>whereas on i686-gnu I believe flock is also the same as flock64 <solid_black>I know there's been a huge ABI break many years ago in Hurd/glibc that was related to this, but I don't know whether it was fixing/chaning this specifically <solid_black>haha, no! I'm totally right, and the test is broken! <solid_black>fcntl64(0, F_GETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=1234, l_len=0, l_pid=5678}) = 0 <solid_black>whereas the code was setting l_len = 5678, l_pid = 0 <solid_black>so it is interpreting this as struct flock, not struct flock64 <luckyluke>maybe it uses a different version of flock/flock64 depending on compilatoin flags? <solid_black>that too it surely does (you'd be surprised how convoluted it is!), but it's still wrong to use flock64 with F_GETLK <solid_black>oh I also need to fork () for the locks to conflict becuase they're process-associated, uhh <solid_black>but yes, now I have confirmation from the actual Linux (and not just strace) that F_GETLK means flock even if used inside fcntl64 () <solid_black>they're doing fcntl64 (fd, F_SETLKW, &fl), fl is struct flock64 <gnu_srs>Hi. Any idea on how to run update-grub when installing a new version of grub from Linux with dpkg-deb -x ... Or how to create an updated grub.cfg? <gnu_srs>The problematic file is: /etc/grub.d/10_hurd