Re: CVS commit: src/sys/kern
> On Wed, Aug 10, 2011 at 03:10:13AM +, YAMAMOTO Takashi wrote: > > > Log Message: > > > Fail namei immediately if searchdir is unlinked / has been rmdir'd. > > > Do this by checking if v_size == 0. Should fix PR 44658 (and PR 32661). > > > > why is this necessary? can't we just let VOP_LOOKUP fail? > > Not to fix PR 44658. it's better to fix the vn_isunder check instead of avoiding running it. IMO vn_isunder should return acutal error code (eg. ENOENT) rather than just a boolean so that callers can decide what to do. > > > the v_size == 0 check sounds wrong. does it work for eg. nfs? > > It apparently does break nullfs, so I've reverted it. > > Is there any way to check this correctly/safely above the filesystem? if "above the filesystem" means "without calling VOPs", i don't think there's a way. YAMAMOTO Takashi > > -- > David A. Holland > dholl...@netbsd.org
Re: CVS commit: src
hi, > Module Name: src > Committed By: manu > Date: Wed Aug 3 04:11:17 UTC 2011 > > Modified Files: > src/bin/cp: cp.c utils.c > src/bin/mv: mv.c > src/distrib/sets/lists/comp: mi > src/lib/libc/gen: Makefile.inc extattr.3 extattr.c > src/lib/libc/sys: extattr_get_file.2 > src/sys/sys: extattr.h > > Log Message: > Make cp -p and mv preverve extended attributes, and complain if they cannot. > > Also introduce library functions for copying extended attributes from one > file to another: > - extattr_copy_file, extattr_copy_fd, extattr_copy_link, with FreeBSD style, > where a namespace is to be supplied > - cpxattr, fcpxattr, lcpxattr, with Linux style, where all namespaces > accessible to the caller are copied, and the others are silently ignored. is extattr_namespace_access really necessary? uid-based priviledge check in userland is often a mistake. YAMAMOTO Takashi > > > To generate a diff of this commit: > cvs rdiff -u -r1.55 -r1.56 src/bin/cp/cp.c > cvs rdiff -u -r1.39 -r1.40 src/bin/cp/utils.c > cvs rdiff -u -r1.41 -r1.42 src/bin/mv/mv.c > cvs rdiff -u -r1.1651 -r1.1652 src/distrib/sets/lists/comp/mi > cvs rdiff -u -r1.178 -r1.179 src/lib/libc/gen/Makefile.inc > cvs rdiff -u -r1.3 -r1.4 src/lib/libc/gen/extattr.3 > cvs rdiff -u -r1.2 -r1.3 src/lib/libc/gen/extattr.c > cvs rdiff -u -r1.3 -r1.4 src/lib/libc/sys/extattr_get_file.2 > cvs rdiff -u -r1.6 -r1.7 src/sys/sys/extattr.h > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files.
Re: CVS commit: src
On Wed, Aug 10, 2011 at 08:59:48AM +, YAMAMOTO Takashi wrote: > is extattr_namespace_access really necessary? > uid-based priviledge check in userland is often a mistake. For now it duplicates the same simple access check as in kernel: system attributes are restricted to root. This is just a helper function, it is not exported. I immagine it could move to kernel when we introduce more namespaces with different acces semantics. But we are not there yet. -- Emmanuel Dreyfus m...@netbsd.org
Re: CVS commit: src/sys/arch
On 10 August 2011 13:39, Cherry G. Mathew wrote: > Module Name: src > Committed By: cherry > Date: Wed Aug 10 11:39:46 UTC 2011 > > Modified Files: > src/sys/arch/amd64/amd64: fpu.c machdep.c > src/sys/arch/i386/isa: npx.c > src/sys/arch/x86/x86: x86_machdep.c > src/sys/arch/xen/conf: files.xen > src/sys/arch/xen/include: intr.h > Added Files: > src/sys/arch/xen/x86: xen_ipi.c > > Log Message: > xen ipi infrastructure Hi, I'd appreciate feedback specifically for multiuser boot of i386/conf/XEN3* please, with this change in place. Many Thanks, -- ~Cherry
Re: CVS commit: src
hi, > On Wed, Aug 10, 2011 at 08:59:48AM +, YAMAMOTO Takashi wrote: >> is extattr_namespace_access really necessary? >> uid-based priviledge check in userland is often a mistake. > > For now it duplicates the same simple access check as in kernel: > system attributes are restricted to root. This is just a helper function, > it is not exported. I immagine it could move to kernel when we introduce > more namespaces with different acces semantics. But we are not there yet. what's wrong with just letting the kernel decide and handle EPERM? YAMAMOTO Takashi > > -- > Emmanuel Dreyfus > m...@netbsd.org
Re: CVS commit: src/sys/kern
On Wed, Aug 10, 2011 at 07:22:06AM +, YAMAMOTO Takashi wrote: > > > why is this necessary? can't we just let VOP_LOOKUP fail? > > > > Not to fix PR 44658. > > it's better to fix the vn_isunder check instead of avoiding running it. > IMO vn_isunder should return acutal error code (eg. ENOENT) rather > than just a boolean so that callers can decide what to do. For some reason I thought that had already been done and found to be inadequate. Not sure why I thought that, since it's obviously false. blah. > > > the v_size == 0 check sounds wrong. does it work for eg. nfs? > > > > It apparently does break nullfs, so I've reverted it. > > > > Is there any way to check this correctly/safely above the filesystem? > > if "above the filesystem" means "without calling VOPs", i don't think > there's a way. Yeah, that's what I'd thought, which is why checking the size looked promising. Oh well. -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/sys/uvm
[ moving to tech-kern ] hi, > y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote: >> > >> > Here is the updated patch after your changes: >> > >> > http://www.netbsd.org/~rmind/uvm_anon_freelst2.diff >> > >> > As you noted, uvm_anfree() can temporarily release the amap lock - that >> > can happen in amap_copy(). Patch closes the race by moving uvm_anfree >> > () further, and changes the semantics of the function, now called >> > uvm_anon_freelst(), to return with amap lock released (plus free anons >> > without lock held). >> >> the temporary release of the amap lock is only for O->A loan >> which you disabled, isn't it? > > Right, uvm_anon_locklaonpg() dance can happen only in O->A case. However, > having uvm_anfree() able to release the lock by its interface definition > is potentially defective. It is the main motivation why I want to slightly > rework the code into uvm_anon_freelst() which would always drop the lock > and move freeing of anons to the end point. Cleaner, less error prone. the committed change seems broken in case uvm_anon_dispose sets PG_RELEASED. in that case, uvm_anon_freelst should leave the anon as it will be freed by uvm_anon_release later. YAMAMOTO Takashi > > -- > Mindaugas
