Re: CVS commit: src
hi, doesn't it leak a page for x86 redzone? YAMAMOTO Takashi Module Name: src Committed By: rmind Date: Wed Oct 21 21:12:07 UTC 2009 Modified Files: src/bin/ps: keyword.c print.c ps.1 src/external/bsd/top/dist/machine: m_netbsd.c src/lib/libkvm: kvm_proc.c src/share/man/man9: uvm.9 src/sys/arch/acorn26/acorn26: pmap.c vm_machdep.c src/sys/arch/alpha/alpha: db_trace.c pmap.c vm_machdep.c src/sys/arch/amd64/amd64: db_trace.c src/sys/arch/amiga/amiga: pmap.c src/sys/arch/amiga/include: cpu.h src/sys/arch/arc: TODO src/sys/arch/arm/arm: db_trace.c syscall.c src/sys/arch/arm/arm32: pmap.c vm_machdep.c src/sys/arch/atari/atari: pmap.c src/sys/arch/atari/include: cpu.h src/sys/arch/cesfic/include: cpu.h src/sys/arch/evbmips/conf: std.gdium src/sys/arch/hp300/include: cpu.h src/sys/arch/hppa/hppa: db_trace.c pmap.c vm_machdep.c src/sys/arch/i386/i386: db_trace.c process_machdep.c src/sys/arch/ia64/ia64: pmap.c vm_machdep.c src/sys/arch/luna68k/include: cpu.h src/sys/arch/m68k/m68k: db_trace.c pmap_motorola.c src/sys/arch/mac68k/include: cpu.h src/sys/arch/mips/include: cpu.h types.h src/sys/arch/mips/mips: db_trace.c mipsX_subr.S pmap.c vm_machdep.c src/sys/arch/mvme68k/include: cpu.h src/sys/arch/news68k/include: cpu.h src/sys/arch/next68k/include: cpu.h src/sys/arch/powerpc/ibm4xx: pmap.c trap.c src/sys/arch/powerpc/include: cpu.h src/sys/arch/powerpc/include/oea: pmap.h src/sys/arch/powerpc/oea: pmap.c src/sys/arch/powerpc/powerpc: db_trace.c process_machdep.c src/sys/arch/sh3/include: cpu.h pmap.h types.h src/sys/arch/sh3/sh3: process_machdep.c src/sys/arch/sparc/include: cpu.h pmap.h src/sys/arch/sparc/sparc: db_trace.c pmap.c src/sys/arch/sparc64/conf: NONPLUS64 src/sys/arch/sparc64/include: cpu.h src/sys/arch/sparc64/sparc64: db_trace.c machdep.c pmap.c src/sys/arch/sun2/sun2: pmap.c src/sys/arch/sun3/sun3: pmap.c src/sys/arch/sun3/sun3x: pmap.c src/sys/arch/sun68k/include: cpu.h src/sys/arch/usermode/include: cpu.h src/sys/arch/usermode/usermode: pmap.c src/sys/arch/vax/include: pmap.h src/sys/arch/vax/vax: machdep.c pmap.c src/sys/arch/x68k/include: cpu.h src/sys/arch/x86/x86: pmap.c syscall.c vm_machdep.c src/sys/compat/linux/arch/i386: linux_ptrace.c src/sys/compat/linux/arch/powerpc: linux_ptrace.c src/sys/compat/mach: mach_thread.c src/sys/compat/sa: compat_sa.c src/sys/conf: std src/sys/dev/i2o: iop.c src/sys/dev/ic: dpt.c rrunner.c src/sys/dev/scsipi: cd.c ch.c if_se.c scsiconf.c scsipi_base.c scsipiconf.h sd.c ss_mustek.c ss_scanjet.c st.c st_atapi.c st_scsi.c src/sys/dev/usb: umass_scsipi.c src/sys/kern: core_elf32.c init_sysctl.c kern_condvar.c kern_fork.c kern_kthread.c kern_lwp.c kern_proc.c kern_runq.c kern_sleepq.c kern_synch.c kern_turnstile.c subr_percpu.c subr_workqueue.c sys_aio.c sys_lwp.c sys_process.c sys_select.c src/sys/miscfs/genfs: genfs_io.c src/sys/miscfs/procfs: procfs_ctl.c procfs_status.c src/sys/nfs: nfs_syscalls.c nfs_vnops.c src/sys/rump/librump/rumpkern: vm.c src/sys/sys: lwp.h sleepq.h syncobj.h vmmeter.h src/sys/uvm: files.uvm uvm.h uvm_amap.c uvm_aobj.c uvm_extern.h uvm_glue.c uvm_init.c uvm_meter.c uvm_pdaemon.c uvm_pmap.h uvm_stat.c uvm_swap.c src/usr.bin/systat: pigs.c ps.c systat.1 vmstat.c src/usr.bin/vmstat: vmstat.1 vmstat.c Log Message: Remove uarea swap-out functionality: - Addresses the issue described in PR/38828. - Some simplification in threading and sleepq subsystems. - Eliminates pmap_collect() and, as a side note, allows pmap optimisations. - Eliminates XS_CTL_DATA_ONSTACK in scsipi code. - Avoids few scans on LWP list and thus potentially long holds of proc_lock. - Cuts ~1.5k lines of code. Reduces amd64 kernel size by ~4k. - Removes __SWAP_BROKEN cases. Tested on x86, mips, acorn32 (thanks mpumford) and partly tested on acorn26 (thanks to bjh21). Discussed on tech-kern, reviewed by ad. To generate a diff of this commit: cvs rdiff -u -r1.52 -r1.53 src/bin/ps/keyword.c cvs rdiff -u -r1.111 -r1.112 src/bin/ps/print.c cvs rdiff -u -r1.89 -r1.90 src/bin/ps/ps.1 cvs rdiff -u -r1.10 -r1.11 src/external/bsd/top/dist/machine/m_netbsd.c cvs rdiff -u -r1.83 -r1.84 src/lib/libkvm/kvm_proc.c cvs rdiff -u -r1.98 -r1.99 src/share/man/man9/uvm.9 cvs rdiff -u -r1.28 -r1.29 src/sys/arch/acorn26/acorn26/pmap.c cvs rdiff -u -r1.21 -r1.22 src/sys/arch/acorn26/acorn26/vm_machdep.c cvs rdiff -u -r1.24 -r1.25 src/sys/arch/alpha/alpha/db_trace.c cvs rdiff -u -r1.243 -r1.244
Re: CVS commit: src/external/cddl/osnet/dist/uts/common/fs/zfs
On Wed, Oct 28, 2009 at 11:44:51PM +, Adam Hamsik wrote: Module Name: src Committed By: haad Date: Wed Oct 28 23:44:51 UTC 2009 Modified Files: src/external/cddl/osnet/dist/uts/common/fs/zfs: zfs_vnops.c zfs_znode.c Log Message: Add workaround about zfs vnode reclaiming deadlock by checking if we don't ehld ZFS_MUTEX_OBJ already. If we can lock OBJ_MUTEX deffer execution of zfs_zinactive to taskq. Code was inspired by FreeBSD zfs_freebsd_reclaim. This doesn't sound right at all ... If the 'If we can lock OBJ_MUTEX' test is a try_mutex_enter() then it may fail because another lwp owns it ... I hope it is only the checkin comment that is inverted! David -- David Laight: da...@l8s.co.uk
Re: CVS commit: src/external/cddl/osnet/dist/uts/common/fs/zfs
On Oct,Thursday 29 2009, at 8:15 PM, David Laight wrote: On Wed, Oct 28, 2009 at 11:44:51PM +, Adam Hamsik wrote: Module Name:src Committed By: haad Date: Wed Oct 28 23:44:51 UTC 2009 Modified Files: src/external/cddl/osnet/dist/uts/common/fs/zfs: zfs_vnops.c zfs_znode.c Log Message: Add workaround about zfs vnode reclaiming deadlock by checking if we don't ehld ZFS_MUTEX_OBJ already. If we can lock OBJ_MUTEX deffer execution of zfs_zinactive to taskq. Code was inspired by FreeBSD zfs_freebsd_reclaim. This doesn't sound right at all ... If the 'If we can lock OBJ_MUTEX' test is a try_mutex_enter() then it may fail because another lwp owns it ... I hope it is only the checkin comment that is inverted! There are 3 option which can happen 1) Our lwp already holds mutex 2) mutex is not held at all 3) Another LWP holds it In case 1 we can call reclaim vnode, in case 2 we lock it with try_mutex_enter and reclaim it and in case 3 we use taskq for reclaiming of vnode. Regards Adam.
Re: CVS commit: src/external/cddl/osnet/dist/uts/common/fs/zfs
On Thu, Oct 29, 2009 at 11:58:32PM +0100, Adam Hamsik wrote: On Oct,Thursday 29 2009, at 8:15 PM, David Laight wrote: On Wed, Oct 28, 2009 at 11:44:51PM +, Adam Hamsik wrote: Module Name:src Committed By: haad Date: Wed Oct 28 23:44:51 UTC 2009 Modified Files: src/external/cddl/osnet/dist/uts/common/fs/zfs: zfs_vnops.c zfs_znode.c Log Message: Add workaround about zfs vnode reclaiming deadlock by checking if we don't ehld ZFS_MUTEX_OBJ already. If we can lock OBJ_MUTEX deffer execution of zfs_zinactive to taskq. Code was inspired by FreeBSD zfs_freebsd_reclaim. This doesn't sound right at all ... If the 'If we can lock OBJ_MUTEX' test is a try_mutex_enter() then it may fail because another lwp owns it ... I hope it is only the checkin comment that is inverted! There are 3 option which can happen 1) Our lwp already holds mutex 2) mutex is not held at all 3) Another LWP holds it In case 1 we can call reclaim vnode, in case 2 we lock it with try_mutex_enter and reclaim it and in case 3 we use taskq for reclaiming of vnode. This is reclaiming in response to someone trying to get a cleaned vnode, correct? If so, we should just change the reclaim API and return something like EBUSY. If it's just cleaning to clean, then having a taskq do it is fine. Where you able to look at the repository at macosforge.org before it shut down? I think that would show a take at solving similar issues. Take care, Bill pgpKqLrLUhuOJ.pgp Description: PGP signature
Re: CVS commit: src/external/cddl/osnet/dist/uts/common/fs/zfs
On Oct 29, 2009, at 4:25 PM, Bill Stouder-Studenmund wrote: Where you able to look at the repository at macosforge.org before it shut down? I think that would show a take at solving similar issues. Note that the XNU vnode lifecycle, referencing, and locking implementation is significantly different from ours. -- thorpej
Re: CVS commit: src/sys/dev/pci
Any issues with pulling this up for 5.1? cheers mark On Fri, 11 Sep 2009, Christos Zoulas wrote: Module Name: src Committed By: christos Date: Fri Sep 11 01:28:20 UTC 2009 Modified Files: src/sys/dev/pci: if_iwn.c if_iwnreg.h if_iwnvar.h pcireg.h Log Message: Add support for the 5100 and newer firmware. Tested also with the 4900. Thanks to everyone for helping and testing.
Re: CVS commit: src/sys/ufs/lfs
On Thu, Oct 29, 2009 at 01:10:32PM -0400, Christos Zoulas wrote: Modified Files: src/sys/ufs/lfs: lfs.h lfs_vnops.c Log Message: PR/42246: NAKAJIMA Yoshihiro: provide COMPAT_50 for LFS Is this pull-up fodder? --chris
Re: CVS commit: src/sys/ufs/lfs
In article 20091030002209.gh1...@irregular-apocalypse.k.bsd.de, Christoph Badura b...@bsd.de wrote: On Thu, Oct 29, 2009 at 01:10:32PM -0400, Christos Zoulas wrote: Modified Files: src/sys/ufs/lfs: lfs.h lfs_vnops.c Log Message: PR/42246: NAKAJIMA Yoshihiro: provide COMPAT_50 for LFS Is this pull-up fodder? No, 5.0 does not need COMPAT_50. christos
