re: CVS commit: src/lib/libc
> On Oct 16, 4:06pm, m...@eterna.com.au (matthew green) wrote: > -- Subject: re: CVS commit: src/lib/libc > > | > | >Module Name:src > | >Committed By: christos > | >Date: Sat Oct 15 23:00:02 UTC 2011 > | > > | >Modified Files: > | >... > | >src/lib/libc/gen: fstab.c fts.c getcap.c getgrent.c getttyent.c > | >getusershell.c initdir.c opendir.c syslog.c utmp.c utmpx.c > | >... > | > > | >close on exec fixes: > | >- open + fcntl -> open O_CLOEXEC > | >- configuration database file descriptors that can stay open are now > opened > | > fopen(db, "re") > | > > | > At least fts.c is used in libnbcompat, so this broke the tools build > | > on NetBSD 5 and probably lots of other systems. > | > | this should be fixed now. > > Thanks, but then shouldn't we also add: > > #if O_CLOEXEC == 0 > (void)fcntl(sp->fts_rfd, F_SETFD, FD_CLOEXEC); > #endif > > after the open? i don't understand why? .mrg.
Re: CVS commit: src/lib/libc
Date: Sun, 16 Oct 2011 16:06:57 +1100 From: matthew green >- open + fcntl -> open O_CLOEXEC > > At least fts.c is used in libnbcompat, so this broke the tools build > on NetBSD 5 and probably lots of other systems. this should be fixed now. Thanks, the tools build gets past that now.
re: CVS commit: src/lib/libc
On Oct 16, 4:06pm, m...@eterna.com.au (matthew green) wrote: -- Subject: re: CVS commit: src/lib/libc | | >Module Name:src | >Committed By: christos | >Date: Sat Oct 15 23:00:02 UTC 2011 | > | >Modified Files: | >... | >src/lib/libc/gen: fstab.c fts.c getcap.c getgrent.c getttyent.c | >getusershell.c initdir.c opendir.c syslog.c utmp.c utmpx.c | >... | > | >close on exec fixes: | >- open + fcntl -> open O_CLOEXEC | >- configuration database file descriptors that can stay open are now opened | > fopen(db, "re") | > | > At least fts.c is used in libnbcompat, so this broke the tools build | > on NetBSD 5 and probably lots of other systems. | | this should be fixed now. Thanks, but then shouldn't we also add: #if O_CLOEXEC == 0 (void)fcntl(sp->fts_rfd, F_SETFD, FD_CLOEXEC); #endif after the open? christos
re: CVS commit: src/lib/libc
>Module Name:src >Committed By: christos >Date: Sat Oct 15 23:00:02 UTC 2011 > >Modified Files: >... >src/lib/libc/gen: fstab.c fts.c getcap.c getgrent.c getttyent.c >getusershell.c initdir.c opendir.c syslog.c utmp.c utmpx.c >... > >close on exec fixes: >- open + fcntl -> open O_CLOEXEC >- configuration database file descriptors that can stay open are now opened > fopen(db, "re") > > At least fts.c is used in libnbcompat, so this broke the tools build > on NetBSD 5 and probably lots of other systems. this should be fixed now. .mrg.
Re: CVS commit: src/lib/libc
Module Name:src Committed By: christos Date: Sat Oct 15 23:00:02 UTC 2011 Modified Files: ... src/lib/libc/gen: fstab.c fts.c getcap.c getgrent.c getttyent.c getusershell.c initdir.c opendir.c syslog.c utmp.c utmpx.c ... close on exec fixes: - open + fcntl -> open O_CLOEXEC - configuration database file descriptors that can stay open are now opened fopen(db, "re") At least fts.c is used in libnbcompat, so this broke the tools build on NetBSD 5 and probably lots of other systems.
Re: CVS commit: src/sys
On Oct 15, 2011, at 3:30 AM, matthew green wrote: > >> Module Name: src >> Committed By:hannken >> Date:Fri Oct 14 09:23:31 UTC 2011 >> >> Modified Files: >> src/sys/compat/linux/common: linux_file.c linux_file64.c linux_ioctl.c >> linux_misc.c >> src/sys/compat/linux32/common: linux32_dirent.c >> src/sys/compat/ossaudio: ossaudio.c >> src/sys/compat/svr4: svr4_fcntl.c >> src/sys/compat/svr4_32: svr4_32_fcntl.c >> src/sys/dev: ccd.c cgd.c vnd.c >> src/sys/dev/dm: dm_target_linear.c dm_target_snapshot.c >> dm_target_stripe.c >> src/sys/dev/raidframe: rf_copyback.c rf_disks.c rf_reconstruct.c >> src/sys/kern: kern_verifiedexec.c vfs_mount.c vfs_syscalls.c >> vfs_vnops.c vnode_if.src >> src/sys/uvm: uvm_mmap.c >> >> Log Message: >> Change the vnode locking protocol of VOP_GETATTR() to request at least >> a shared lock. Make all calls outside of file systems respect it. >> >> The calls from file systems need review. >> >> No objections from tech-kern. > > does this require a kernel bump? if filesystem code needs to > change, even if API signatures haven't, i would say so? > > thanks. No, we don't check vnode locks for VOP_GETATTR() anywhere as its lock requirements were unspecified -- all changes are like + vn_lock(vp, LK_SHARED | LK_RETRY); error = VOP_GETATTR(vp, &va, cred); + VOP_UNLOCK(vp); -- Juergen Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
