I noticed that the two cgload calls are different: e2fs_cgload(bp->b_data, &fs->e2fs_gd[i * fs->e2fs_bsize / sizeof(struct ext2_gd)], fs->e2fs_bsize, 1 << fs->e2fs_group_desc_shift); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ int32_t sh = m_fs->e2fs_bsize >> m_fs->e2fs_group_desc_shift; e2fs_cgload(bp->b_data, &m_fs->e2fs_gd[i * sh], ^^^^^ m_fs->e2fs_bsize, m_fs->e2fs_group_desc_shift);
e2fs_cgsave(&fs->e2fs_gd[ i * fs->e2fs_bsize / sizeof(struct ext2_gd)], bp->b_data, fs->e2fs_bsize, fs->e2fs_group_desc_shift); shouldn't we consistently index as: &fs->e2fs_gd[i * fs->e2fs_bsize / sizeof(struct ext2_gd)] and pass the shift as: fs->e2fs_group_desc_shift ??? Thanks, christos > On Aug 26, 2023, at 7:43 PM, Vladimir 'phcoder' Serbinenko > <phco...@gmail.com> wrote: > > > > > Le dim. 27 août 2023, 00:48, Christos Zoulas <chris...@zoulas.com > <mailto:chris...@zoulas.com>> a écrit : > >> I took care of it. One I think was mine, one was yours :-) >> > > > Thank you a lot. I was diagnosing it but you were faster. I'll see what I can > do for userspace to remove old cgload/cgsave > >> >> christos >> >> >> >>> On Aug 26, 2023, at 8:52 AM, Christos Zoulas <chris...@zoulas.com >>> <mailto:chris...@zoulas.com>> wrote: >>> >>> >>> It could also be my fault because I refactored the code a bit. One of the >>> things that I changed >>> >>> that looked like a bug to me was adding a cast to e2fs_cgload(): >>> >>> memset((char *)optr + 32, 0, sizeof(*optr) - 32); >>> >>> >>> >>> since optr is struct ext2_gd *... >>> >>> >>> >>> christos >>> >>> >>> >>> >>> >>>> On Aug 26, 2023, at 7:46 AM, Vladimir 'phcoder' Serbinenko >>>> <phco...@gmail.com <mailto:phco...@gmail.com>> wrote: >>>> >>>> >>>> I'll have a look today or tomorrow >>>> >>>> >>>> Le sam. 26 août 2023, 12:06, Taylor R Campbell >>>> <campbell+netbsd-tech-k...@mumble.net >>>> <mailto:campbell%2bnetbsd-tech-k...@mumble.net>> a écrit : >>>> >>>>> > Date: Wed, 23 Aug 2023 04:54:34 +0200 >>>>> > From: "Vladimir 'phcoder' Serbinenko" <phco...@gmail.com >>>>> > <mailto:phco...@gmail.com>> >>>>> > >>>>> > This patch adds support for incompat_64bit on ext4 filesystem. This >>>>> > feature >>>>> > is enabled by default on new filesystems on Ubuntu and probably other >>>>> > distros >>>>> >>>>> Cool, thanks! christos@ committed this. >>>>> >>>>> It looks like it may have some issues, though -- a lot of ext2fs tests >>>>> are failing now. Can you please take a look at the failures? >>>>> >>>>> https://releng.netbsd.org/b5reports/i386/commits-2023.08.html#build-2023.08.26.05.47.53 >>>>> >>>>> Termination reason >>>>> >>>>> FAILED: create file: No space left on device >>>>> >>>>> Standard output stream >>>>> >>>>> [ 1.0000000] entropy: ready >>>>> [ 1.0200050] uid 0 on /mnt: out of inodes >>>>> >>>>> FYI, if you're running a new enough kernel already, you can run the >>>>> tests yourself by doing a distribution build and then doing >>>>> >>>>> # chroot /path/to/objdir/destdir.amd64 >>>>> (chroot)# (cd /dev && sh MAKEDEV all) >>>>> (chroot)# mount -t ptyfs ptyfs /dev/pts >>>>> (chroot)# mount -t tmpfs tmpfs /tmp >>>>> (chroot)# cd /usr/tests/fs/vfs >>>>> (chroot)# atf-run | atf-report >>>>> >>>>> You can also do build.sh release, install into a VM, and run the tests >>>>> the same way -- cd /usr/tests/fs/vfs && atf-run | atf-report. >>>>> >>>>> This also broke the build of bootloaders and the newfs_ext2fs userland >>>>> tool. I put in a stop-gap measure to restore the old definitions of >>>>> e2fs_cgload/cgsave outside the kernel, just to unbreak the build, but >>>>> it might be appropriate to make the new definitions available to >>>>> bootloaders and newfs_ext2fs too. >>>>> >>>>> (I haven't looked into technical details to see whether it is >>>>> appropriate. Probably newfs_ext2s should avoid creating file systems >>>>> this new feature for a while, but maybe have an option to do it so we >>>>> can exercise the code paths in tests.) >>>> >>>> <sanitizer.log> >>>> >>> >>> >>> >>> >>> >>> >> >> >> >> > > > > <sanitizer.log>
signature.asc
Description: Message signed with OpenPGP