April 2011 - Darwin-kernel - lists.apple.com

Re: Classify VNODE SCOPE actions for file operations
by Paul Nelson 07 Apr '11

07 Apr '11

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Apr 7, 2011, at 9:39 AM, Ken Hornstein wrote: >> >> 1. When I create a new file I get KAUTH_VNODE_ADD_FILE. Here vp is >> returned as the directory in which the file gets created and dvp is >> NULL. Is there a way for me to get the name of the newly created file. > > It would seem the answer is ... no. At least not via kauth. It looks like > it would require some changes internally; right now you would need to get > passed in the struct nameidata down, and vnode_authorize only takes two > vnodes as arguments. You could use vn_getpath (see vnode.h) but it does not ask the filesystem for names, so it can't handle hard link nodes, and might return an error. It is not that hard to use getattrlist inside a kernel. This is the best way to get the name of a vnode. Just fill out the vnop_getattr_args and call VNOP_GETATTRLIST. For example: given vp is the vnode pointer: struct vnop_getattr a; VATTR_INIT(&a); VATTR_WANTED(&a, va_name); // MAXPATHLEN is what vnode.h says to pass MALLOC( a.va_name, char *, MAXPATHLEN, M_TEMP, M_WAITOK); int res = VNOP_GETATTR( vp, &a, context); if( res == 0 ) { if( VATTR_IS_SUPPORTED(&a, va_name) ) printf("vp %p is %s\n", vp, a.va_name ? a.va_name : "//not available//"); else printf("filesystem does not support getting va_name\n"); } if( a.va_name ) FREE(a.va_name, M_TEMP); If you don't have a context, you can make one yourself using vfs_context_create(NULL), release with vfs_context_rele(context) This only returns the name of the vnode. If you want to build a path, you have to do that yourself, but be aware that hard links can be tricky. Look at Apple's source code for build_path in bsd/vfs/vfs_cache.c Using getattrlist stuff is MUCH easier inside the kernel than from user space since there is no packing and unpacking. VNOP_GETATTR has almost zero overhead, taking you right into the file system. The filesystem may not always cooperate however. Paul Nelson Thursby Software Systems, Inc. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Classify VNODE SCOPE actions for file operations
by Ken Hornstein 07 Apr '11

07 Apr '11

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com >Waiting for your response.. You know ... I find that for many things in this realm, you have to read the kernel sources yourself. >1. When I create a new file I get KAUTH_VNODE_ADD_FILE. Here vp is >returned as the directory in which the file gets created and dvp is >NULL. Is there a way for me to get the name of the newly created file. It would seem the answer is ... no. At least not via kauth. It looks like it would require some changes internally; right now you would need to get passed in the struct nameidata down, and vnode_authorize only takes two vnodes as arguments. >2. When I open a file I get the KAUTH_VNODE_READ_DATA action. I get the >same action when I read the file. Is is possible to identify when in >KAUTH_VNODE_READ_DATA, whether the event took place because of reading >the file or because of opening the file. I want to differentiate the >read operation from open operation as I need to do separate activities >in case of each event. I think, however, the answer to this one is "maybe". But it's not in vnode scope; I think what you want is KAUTH_FILEOP_OPEN. That's notificaton only, though; the return from that is ignored. You'll still get the KAUTH_VNODE_READ_DATA, though. --Ken _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Classify VNODE SCOPE actions for file operations
by sheetal phirke 07 Apr '11

07 Apr '11

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.in; s=s1024; t=1302167268; bh=KZ3UNuLyj4RuDOUqp5TTSSPvN/HIbZuaStKLfJpNxBo=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=5Gsva1O1XM8aYwoSBUv+UcWvkT0zYdWQfry3BvEL5Y6EbD3nEhueOVzRbg9phsOLHGtjJSezlIiyqqrMbVQHIWkErdgH7WUsMTcjkfxeF/29Q5+CYu34sXk8IFw/O74yEQBCGtgGQDauz/veen2jnOThCkHJZ2BBpEBf9Rk4LR0= Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=YtoDVBYvN5h/kQWA5NJwXyqDu/8tLk36QI3f4fURiDdg4ZbWFXxHkvHFZREAq1TsRRrHsI1UpG7hZuscFgfRkGxxYKUTYNl11QnIestEFHWU3j8ACAr/PIcdrAnof/DcosKwkRdeBA8KZyj23kzEPpBhDg12rOLez4adv1fDHDo=; _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Questions about upls, INACTIVATE, and PRECIOUS
by Ken Hornstein 07 Apr '11

07 Apr '11

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com I've been (probably foolishly) working on and off on porting an already- existing network filesystem to Darwin. I'm fairly far along, and I'm now at the point of handling data caching. Before anyone says anything ... yes, I've read Singh's book, and I've read the appropriate Apple documentation. They're both okay ... as starting points. They really don't go into the detail that I need at this point; what I've been using has been the NFS sources included in MacOS X as a guide. Fine, okay, that's what I expect when I get to this level, and I can deal with that. I am having a bit of uncertainty when it comes to the exact handling of UPLs. As I understand it (based on the NFS sources) a rough sequence of what I need to do so data caching is integrated properly with UBC is as follows: - Make sure the size of my vnode is set correctly with ubc_setsize() - Create some metadata to keep track of individual buffer status (dirty, whatever else) - When I need to "lock" a page within the UBC for a particular vnode, create a UPL with ubc_create_upl(). - When I need to read/write the data, I map it into the kernel's memory with ubc_upl_map() (I'm only doing this for reading right now). - After I'm done copying my data, I can remove the mapping with ubc_upl_unmap(). - When I'm done completely, I commit the UPL using ubc_upl_commit(). - I can then use cluster_copy_ubc_data() to copy the data to userspace (if I have the data already cached, I can just do this step). So the things I am not quite clear on ... - The semantics of PRECIOUS. Okay, the limited documentation on this says that the pages that are marked precious are assumed to be the only copy and that they always have to be returned to the memory manager when they need to be evicted, even when not dirty. The NFS code always makes sure that all pages that it is buffering are initially marked as precious. But then when an NFS buffer is released, if (for example) the buffer has just been used for reading then the precious flag is cleared by the UPL_COMMIT_CLEAR_PRECIOUS flag. To me this means that if the VM system wants to evict a page due to memory pressure it can do so without letting NFS know via a VNOP_PAGEOUT() call. It may be that this doesn't matter for NFS; from what I see if nfs can't copy data from the UBC using cluster_copy_ubc_data() it just starts transferring it from the server. So, am I right in my understanding that if I mark a page as precious, I will always get a VNOP_PAGEOUT() for it? Does marking a page as precious have any other side effects that I should be aware of? I see from the kernel sources that in most places there is a test for a page being dirty or precious at the same time, so I am guessing their semantics are close. - What exactly does UPL_COMMIT_INACTIVATE do? The documentation in ubc_subr.c says "Clear each pages reference bit; the page will not be accessed". The NFS code does this for all released buffers. I know this clears the "reference" flag in the page, but I'm not clear on what exactly this _means_; should I always use this flag when I commit a UPL? - If I get notification from the fileserver that pages I have cached are no longer valid, how should I tell the UBC that? (Presume that we're already doing the appropriate locking so no dirty client-side data will be lost). ubc_msync() with UBC_INVALIDATE? Thanks for any help you can give me, --Ken _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Calling completion method
by Rakesh Singhal 01 Apr '11

01 Apr '11

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=pePCR98tNV5/WV0wjSUvZVOy4Ca6+Q6lFbvgYfnlF18=; b=PzbI9T3Ffb+pur9ZQshkvokKmD9D3K3tgKoP5T85H+bP/LSNeckIkAlH8DQQmi3GVD p4uzJv2vwE8tsipqmcILbnYLX9fMnjt9k7eb6u0izW7eMkMWJzSmOvHHIfX1i5OeF4ZC sTx2go5hg3cobTXsvfy/kuCTCEu1rS6YYqvu4= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=DhbdlNfxFF20y/kpMh064v5IRfkCIxV2fqLn/0cR/wAf78KVW1BHxHl8MN5Woucny2 Ar7QOXUS9Ei03dXX7XUdzqHqYneMLbuJA9fmp6PG0lPt9Ey+JcS/zqph9u+z2syjzqTU W3fBAqNGUCXw7urVUo5Sp4JQp+Ikz0whPopxs= _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0