January 2009 - Darwin-kernel

Re: problems with hfs_truncatefs() / HFS_RESIZE_VOLUME
by Shantonu Sen 23 Jan '09

23 Jan '09

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com _______________________________________________ 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 see http://developer.apple.com/technotes/tn2006/tn2166.html#SECPARTITIONINGPOLI… diskutil resizeVolume <resp. volume device> limits ENOSPC 'hfs_extendfs(): not enough space on device' EINVAL 'hfs_truncatefs(): invalid size' uiNewSize you certainly get a ENOSPC message somewhere, bad sample you are using - yoda Cheers! On Thu, Jan 22, 2009 at 8:16 AM, Michael Alfred Schmidt < michael.alfred.schmidt(a)utimaco.de > wrote: > > Hi, > > I'm trying to shrink an HFS+ partition, just as 'diskutil resizeVolume...' > does. However, I'm facing problems implementing the HFS_RESIZE_VOLUME > command via fsctl(), as proposed by Amit Singh on p. 1572 of 'Mac OS X > Internals'. > > My code looks as follows: > > int iRet = 0; > > u_int32_t uiBlockSize; > u_int64_t uiBlockCount, uiCurrentSize, uiNewSize; > > struct statfs StatFS; > > // only works if device mounted > iRet = statfs ("/etc/", &StatFS); > if (iRet < 0) > { > perror ("statfs failed with"); > > return; > } > > uiBlockSize = StatFS.f_bsize; > uiBlockCount = StatFS.f_blocks; > > > printf ("block size:\t %u\n", uiBlockSize); > printf ("block count:\t %llu\n", uiBlockCount); > > > uiCurrentSize = uiBlockSize * uiBlockCount; > printf ("partition size:\t %llu\n\n", uiBlockSize * uiBlockCount); > > uiNewSize = uiCurrentSize; // only test here!!! > printf ("new volume size: %llu, hex: %llX\n", uiNewSize, uiNewSize); > > > iRet = fsctl ("/", HFS_RESIZE_VOLUME, &uiNewSize, 0); > if (iRet < 0) > { > perror ("fsctl failed with"); > > return; > } > > > fsctl() fails with either 'hfs_extendfs(): not enough space on device' or > 'hfs_truncatefs(): invalid size', even if the new size equals the old size > (as in the code sample above). It looks like the &uiNewSize input parameter > is fully ignored, as other "new sizes" show the same unpredictable results. > On the kernel side, the respective code resides in bsd/hfs/hfs_readwrite.c. > >From looking at that code, I cannot see any obvious mistake in my code. I'm > wondering whether there is any thunking (pointer conversion) problem with > the pointer to u_int64_t in the transition from userland to kernel. > > My target system is Mac OS X 10.5.x (Intel), compiled with XCode 3.1 with > default build settings. > > > I'm grateful for any idea on what's wrong with my code! > Thanks in advance! > > Michael > > > _______________________________________________ > 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/openspecies%40gmail.com > > This email sent to openspecies(a)gmail.com > -- -mmw

1 0

Re: problems with hfs_truncatefs() / HFS_RESIZE_VOLUME
by Michael Alfred Schmidt 23 Jan '09

23 Jan '09

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com _______________________________________________ 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 see http://developer.apple.com/technotes/tn2006/tn2166.html#SECPARTITIONINGPOLI… diskutil resizeVolume <resp. volume device> limits ENOSPC 'hfs_extendfs(): not enough space on device' EINVAL 'hfs_truncatefs(): invalid size' uiNewSize you certainly get a ENOSPC message somewhere, bad sample you are using - yoda Cheers! On Thu, Jan 22, 2009 at 8:16 AM, Michael Alfred Schmidt < michael.alfred.schmidt(a)utimaco.de > wrote: > > Hi, > > I'm trying to shrink an HFS+ partition, just as 'diskutil resizeVolume...' > does. However, I'm facing problems implementing the HFS_RESIZE_VOLUME > command via fsctl(), as proposed by Amit Singh on p. 1572 of 'Mac OS X > Internals'. > > My code looks as follows: > > int iRet = 0; > > u_int32_t uiBlockSize; > u_int64_t uiBlockCount, uiCurrentSize, uiNewSize; > > struct statfs StatFS; > > // only works if device mounted > iRet = statfs ("/etc/", &StatFS); > if (iRet < 0) > { > perror ("statfs failed with"); > > return; > } > > uiBlockSize = StatFS.f_bsize; > uiBlockCount = StatFS.f_blocks; > > > printf ("block size:\t %u\n", uiBlockSize); > printf ("block count:\t %llu\n", uiBlockCount); > > > uiCurrentSize = uiBlockSize * uiBlockCount; > printf ("partition size:\t %llu\n\n", uiBlockSize * uiBlockCount); > > uiNewSize = uiCurrentSize; // only test here!!! > printf ("new volume size: %llu, hex: %llX\n", uiNewSize, uiNewSize); > > > iRet = fsctl ("/", HFS_RESIZE_VOLUME, &uiNewSize, 0); > if (iRet < 0) > { > perror ("fsctl failed with"); > > return; > } > > > fsctl() fails with either 'hfs_extendfs(): not enough space on device' or > 'hfs_truncatefs(): invalid size', even if the new size equals the old size > (as in the code sample above). It looks like the &uiNewSize input parameter > is fully ignored, as other "new sizes" show the same unpredictable results. > On the kernel side, the respective code resides in bsd/hfs/hfs_readwrite.c. > >From looking at that code, I cannot see any obvious mistake in my code. I'm > wondering whether there is any thunking (pointer conversion) problem with > the pointer to u_int64_t in the transition from userland to kernel. > > My target system is Mac OS X 10.5.x (Intel), compiled with XCode 3.1 with > default build settings. > > > I'm grateful for any idea on what's wrong with my code! > Thanks in advance! > > Michael > > > _______________________________________________ > 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/openspecies%40gmail.com > > This email sent to openspecies(a)gmail.com > -- -mmw

1 0

Re: problems with hfs_truncatefs() / HFS_RESIZE_VOLUME
by Shantonu Sen 22 Jan '09

22 Jan '09

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com _______________________________________________ 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 ENOSPC 'hfs_extendfs(): not enough space on device' EINVAL 'hfs_truncatefs(): invalid size' uiNewSize you certainly get a ENOSPC message somewhere, bad sample you are using - yoda Cheers! On Thu, Jan 22, 2009 at 8:16 AM, Michael Alfred Schmidt <michael.alfred.schmidt(a)utimaco.de> wrote: > > Hi, > > I'm trying to shrink an HFS+ partition, just as 'diskutil resizeVolume...' > does. However, I'm facing problems implementing the HFS_RESIZE_VOLUME > command via fsctl(), as proposed by Amit Singh on p. 1572 of 'Mac OS X > Internals'. > > My code looks as follows: > > int iRet = 0; > > u_int32_t uiBlockSize; > u_int64_t uiBlockCount, uiCurrentSize, uiNewSize; > > struct statfs StatFS; > > // only works if device mounted > iRet = statfs ("/etc/", &StatFS); > if (iRet < 0) > { > perror ("statfs failed with"); > > return; > } > > uiBlockSize = StatFS.f_bsize; > uiBlockCount = StatFS.f_blocks; > > > printf ("block size:\t %u\n", uiBlockSize); > printf ("block count:\t %llu\n", uiBlockCount); > > > uiCurrentSize = uiBlockSize * uiBlockCount; > printf ("partition size:\t %llu\n\n", uiBlockSize * uiBlockCount); > > uiNewSize = uiCurrentSize; // only test here!!! > printf ("new volume size: %llu, hex: %llX\n", uiNewSize, uiNewSize); > > > iRet = fsctl ("/", HFS_RESIZE_VOLUME, &uiNewSize, 0); > if (iRet < 0) > { > perror ("fsctl failed with"); > > return; > } > > > fsctl() fails with either 'hfs_extendfs(): not enough space on device' or > 'hfs_truncatefs(): invalid size', even if the new size equals the old size > (as in the code sample above). It looks like the &uiNewSize input parameter > is fully ignored, as other "new sizes" show the same unpredictable results. > On the kernel side, the respective code resides in bsd/hfs/hfs_readwrite.c. > >From looking at that code, I cannot see any obvious mistake in my code. I'm > wondering whether there is any thunking (pointer conversion) problem with > the pointer to u_int64_t in the transition from userland to kernel. > > My target system is Mac OS X 10.5.x (Intel), compiled with XCode 3.1 with > default build settings. > > > I'm grateful for any idea on what's wrong with my code! > Thanks in advance! > > Michael > > > _______________________________________________ > 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/openspecies%40gmail.com > > This email sent to openspecies(a)gmail.com > -- -mmw

1 0

Re: problems with hfs_truncatefs() / HFS_RESIZE_VOLUME
by Michael Alfred Schmidt 22 Jan '09

22 Jan '09

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com _______________________________________________ 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 ENOSPC 'hfs_extendfs(): not enough space on device' EINVAL 'hfs_truncatefs(): invalid size' uiNewSize you certainly get a ENOSPC message somewhere, bad sample you are using - yoda Cheers! On Thu, Jan 22, 2009 at 8:16 AM, Michael Alfred Schmidt <michael.alfred.schmidt(a)utimaco.de> wrote: > > Hi, > > I'm trying to shrink an HFS+ partition, just as 'diskutil resizeVolume...' > does. However, I'm facing problems implementing the HFS_RESIZE_VOLUME > command via fsctl(), as proposed by Amit Singh on p. 1572 of 'Mac OS X > Internals'. > > My code looks as follows: > > int iRet = 0; > > u_int32_t uiBlockSize; > u_int64_t uiBlockCount, uiCurrentSize, uiNewSize; > > struct statfs StatFS; > > // only works if device mounted > iRet = statfs ("/etc/", &StatFS); > if (iRet < 0) > { > perror ("statfs failed with"); > > return; > } > > uiBlockSize = StatFS.f_bsize; > uiBlockCount = StatFS.f_blocks; > > > printf ("block size:\t %u\n", uiBlockSize); > printf ("block count:\t %llu\n", uiBlockCount); > > > uiCurrentSize = uiBlockSize * uiBlockCount; > printf ("partition size:\t %llu\n\n", uiBlockSize * uiBlockCount); > > uiNewSize = uiCurrentSize; // only test here!!! > printf ("new volume size: %llu, hex: %llX\n", uiNewSize, uiNewSize); > > > iRet = fsctl ("/", HFS_RESIZE_VOLUME, &uiNewSize, 0); > if (iRet < 0) > { > perror ("fsctl failed with"); > > return; > } > > > fsctl() fails with either 'hfs_extendfs(): not enough space on device' or > 'hfs_truncatefs(): invalid size', even if the new size equals the old size > (as in the code sample above). It looks like the &uiNewSize input parameter > is fully ignored, as other "new sizes" show the same unpredictable results. > On the kernel side, the respective code resides in bsd/hfs/hfs_readwrite.c. > >From looking at that code, I cannot see any obvious mistake in my code. I'm > wondering whether there is any thunking (pointer conversion) problem with > the pointer to u_int64_t in the transition from userland to kernel. > > My target system is Mac OS X 10.5.x (Intel), compiled with XCode 3.1 with > default build settings. > > > I'm grateful for any idea on what's wrong with my code! > Thanks in advance! > > Michael > > > _______________________________________________ > 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/openspecies%40gmail.com > > This email sent to openspecies(a)gmail.com > -- -mmw

1 0

Re: problems with hfs_truncatefs() / HFS_RESIZE_VOLUME
by mm w 22 Jan '09

22 Jan '09

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:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=JgEj9xXIpwBjvDALLcHMDMTMhiVHwZaHCe3VQhR8nFc=; b=IjjTzyf/C3WqJyNo8MKqimC4rsCwXxoLzkoxRUIf+2Eh1DoK/2rIyXzcvyDvari1aW Ne5EooS94FJVa7GG+YZ4OrZqlGNOjtn3aPodtS9Gd3DtrxSqa4oEKjvVNU56vmUahYD/ ipU6gehZYwN/4xUflxpJB/5b9wEgqRrz9dCgM= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=xJEWKdBV3Fv1/y9iPz2wi52PQDQqTIAu8Dxswpm34QnXbsLEH7ueGSptD/L7QIbBmG 0zr0ZRHP/eODDR3tIeqcQM+DraR1rFSnyOKg/bK2KANBscGUAbrq4jieD+1EN/VJkI2L u2VY/STTuL2JVdtu2xFdGPvuX19OhMHWfjw7U= you certainly get a ENOSPC message somewhere, bad sample you are using - yoda Cheers! On Thu, Jan 22, 2009 at 8:16 AM, Michael Alfred Schmidt <michael.alfred.schmidt(a)utimaco.de> wrote: > > Hi, > > I'm trying to shrink an HFS+ partition, just as 'diskutil resizeVolume...' > does. However, I'm facing problems implementing the HFS_RESIZE_VOLUME > command via fsctl(), as proposed by Amit Singh on p. 1572 of 'Mac OS X > Internals'. > > My code looks as follows: > > int iRet = 0; > > u_int32_t uiBlockSize; > u_int64_t uiBlockCount, uiCurrentSize, uiNewSize; > > struct statfs StatFS; > > // only works if device mounted > iRet = statfs ("/etc/", &StatFS); > if (iRet < 0) > { > perror ("statfs failed with"); > > return; > } > > uiBlockSize = StatFS.f_bsize; > uiBlockCount = StatFS.f_blocks; > > > printf ("block size:\t %u\n", uiBlockSize); > printf ("block count:\t %llu\n", uiBlockCount); > > > uiCurrentSize = uiBlockSize * uiBlockCount; > printf ("partition size:\t %llu\n\n", uiBlockSize * uiBlockCount); > > uiNewSize = uiCurrentSize; // only test here!!! > printf ("new volume size: %llu, hex: %llX\n", uiNewSize, uiNewSize); > > > iRet = fsctl ("/", HFS_RESIZE_VOLUME, &uiNewSize, 0); > if (iRet < 0) > { > perror ("fsctl failed with"); > > return; > } > > > fsctl() fails with either 'hfs_extendfs(): not enough space on device' or > 'hfs_truncatefs(): invalid size', even if the new size equals the old size > (as in the code sample above). It looks like the &uiNewSize input parameter > is fully ignored, as other "new sizes" show the same unpredictable results. > On the kernel side, the respective code resides in bsd/hfs/hfs_readwrite.c. > >From looking at that code, I cannot see any obvious mistake in my code. I'm > wondering whether there is any thunking (pointer conversion) problem with > the pointer to u_int64_t in the transition from userland to kernel. > > My target system is Mac OS X 10.5.x (Intel), compiled with XCode 3.1 with > default build settings. > > > I'm grateful for any idea on what's wrong with my code! > Thanks in advance! > > Michael > > > _______________________________________________ > 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/openspecies%40gmail.com > > This email sent to openspecies(a)gmail.com > -- -mmw _______________________________________________ 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

problems with hfs_truncatefs() / HFS_RESIZE_VOLUME
by Michael Alfred Schmidt 22 Jan '09

22 Jan '09

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com _______________________________________________ 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 'diskutil resizeVolume...' HFS_RESIZE_VOLUME fsctl() int iRet = 0; u_int32_t uiBlockSize; u_int64_t uiBlockCount, uiCurrentSize, uiNewSize; struct statfs StatFS; // only works if device mounted iRet = statfs ( "/etc/" , &StatFS); if (iRet < 0) { perror ( "statfs failed with" ); return; } uiBlockSize = StatFS.f_bsize; uiBlockCount = StatFS.f_blocks; printf ( "block size:\t %u\n" , uiBlockSize); printf ( "block count:\t %llu\n" , uiBlockCount); uiCurrentSize = uiBlockSize * uiBlockCount; printf ( "partition size:\t %llu\n\n" , uiBlockSize * uiBlockCount); uiNewSize = uiCurrentSize; // only test here!!! printf ( "new volume size: %llu, hex: %llX\n" , uiNewSize, uiNewSize); iRet = fsctl ( "/" , HFS_RESIZE_VOLUME, &uiNewSize, 0); if (iRet < 0) { perror ( "fsctl failed with" ); return; } fsctl() 'hfs_extendfs(): not enough space on device' 'hfs_truncatefs(): invalid size' &uiNewSize bsd/hfs/hfs_readwrite.c u_int64_t

1 0

Re: KAUTH_FILEOP_EXEC & KAUTH_VNODE_EXECUTE freeze
by Terry Lambert 22 Jan '09

22 Jan '09

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com = Mike -- Terry -- Terry _______________________________________________ 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.… On Jan 21, 2009, at 12:43 PM, Liviu Andron wrote: On Wed, Jan 21, 2009 at 9:05 AM, Terry Lambert <tlambert(a)apple.com> wrote: On Jan 20, 2009, at 3:51 PM, Liviu Andron <liviu.andron.work(a)gmail.com> wrote: On Sat, Jan 17, 2009 at 8:35 PM, Michael Smith <drivers(a)mu.org> wrote: The most likely cause of this problem is a deadlock; have you looked at what the vnode you're auth'ing is? Have you looked at what your process is doing? The vnode is the executable, of course: the one implied in KAUTH_FILEOP_EXEC & KAUTH_VNODE_EXECUTE. CommandLineUtility is the result of the "Standard tool" wizard in XCode (it prints a "Hello world" message). 35 is EWOULDBLOCK. You gave it a small timeout and your user space process failed to wakeup on the wait channel before this timout expired, so you got EWOULDBLOCK. If you attach projects, attach them to the problem report, rather than mailing them to everyone. Well, I discovered the problem: I was doing a sysctl call ( sysctl(CTL_KERN, KERN_PROC, KERN_PROC_PID) ) between the reading of the packet from kernel and the setsockopt call that releases the msleep wait in kernel. Without the sysctl call it doesn't block on the KAUTH_FILEOP_EXEC & KAUTH_VNODE_EXECUTE accesses. Should I avoid other system calls beside sysctl (open, malloc and printf work, even if only open is a Section 2 man function) ? I didn't attach the code to the (some) bug report since the problem conditions changed. You don't want to have your user space daemon make any calls that take any locks that are already held by the code path in your kauth module. If you do, then you are pretty much guaranteed to deadlock. You basically want to have the answers to all possible questions your kauth module in the kernel is going to ask the user space portion in hand and ready to go before it asks. For anti-virus software that generally translates to having, for example, all of your virus patterns already loaded up and ready to go so when the kernel asks for one, you can respond immediately, without having to do explicit file I/O or anything. Effectively, this means that you need to be aware of the locks which are held when you hit a kauth hook you are hooking, and with that knowledge, know that you can't contend them with calls your daemon makes, or you will deadly-embrace deadlock. In this particular case, you are probably asking for a property of the process that your kernel module could already know the answer to and provide as input information to user space. In general, it's a bad idea to do things like making identity policy decisions based on information you have to retrieve. The sysctl() interface is guaranteed to be more problematic than most, since it was actualy never designed to be used how it's grown to be used. Effectively, it does non-leaf-node locking, including using the funnel, because historically people have abused terminal OID elements as a means of passing parameters down to proc handler functions. This is true for almost everything in KERN_PROC, and is also true of anything that operates by fsid. Some people also use oid elements for address parameters (really a problem, given that some processes are 64 bit, and OID elements are defined to be integer values). You can shoot your foot off other ways, of course, by making calls other than sysctl(); the most common method of hurting your foot when you build a two-part kauth kext + daemon like this is to forget to make your user space daemon immune to kauth callbacks: if you forget that, then your daemon makes a call which triggers a kauth request to your daemon which makes a call which triggers a request which ... This email sent to site_archiver(a)lists.apple.com

1 0

Re: Question regarding vnodes and memory mapped files
by Narayan Subramanian 22 Jan '09

22 Jan '09

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:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=xn5qDgHXSRADEZX7faVd9IDXm+lGroUe72OdnEoNqG0=; b=ZYxuJf8XrCjjY1bL8iFOG7pknu+/jpZ723ChaYGIqRsS/Y0dDVj3SWO5Trgt7p86U/ K031aZFmHpOWRYiq0X5KKRXP4yQMDVmclBoYcedM2LB0as06rdqf7kQdB5TTE6Hx60u+ qjLgcKRpPd+zm5NCDT17t/S5V+r3cqRuBoz6M= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=AaRJ3gQPphPaW981POz55mYwqYYTbJDeKE1jDXMta7OBbXhcpa7aFRp7Pt/US3mtus tzrOOSdyZO/oXJjuKpFHhFopPvl5AYCAA3MmTWn6NiKgCgU9oNksksDaHCZMlWnjNyTz t5YVy+EHOvFmpanaZocfxV6Mjlw6A4qffIjt4= _______________________________________________ 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: KAUTH_FILEOP_EXEC & KAUTH_VNODE_EXECUTE freeze
by Liviu Andron 21 Jan '09

21 Jan '09

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:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=5uUqxbWKg3O4f/bsZ4Lbq9Qy3cQYgJDPwffj0LungxI=; b=urT5bZAX9Jvtcws+o8TLev4gbGjBZ7RVhVSl9Pg0v3zZ6GoBl3n+i5alwUzeOMJvNT JDh6sv6k4SN2hzw7CuLSrnKDUP5JeIIhxkjjpgNqE6N3dnf66QEGGCebwdxMa9RtZeVc FPoVVavAV6iDtPZiFk68vKum1u3npWaHK7hXQ= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=VxCQbRQERjWwF2QIKMtD8HBmnJAxPqQpArsm93BwJy/4Iy+7Mt5rPrXcumBQhphnWj GND/ax5yqogZATpyNbV5hAiFyrTiSVXHmBaPaIZaGBND4UbiUPqnzkuChTa4TTViu2mp jnifKHeWuCC8Up7wGH0jqTqcjSmXEYj3SYsW0= _______________________________________________ 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: Question regarding vnodes and memory mapped files
by mm w 21 Jan '09

21 Jan '09

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:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=FQiPQieVE/u9T3MQ9moPcfnGhfZ9zzqpH9LQSN3GEc8=; b=acFr+AyO2aN0yNZj1+uXaZFHn8CvnLbL21ZAxComkwScHyn9OMjqYJawXUzX+mM/KI ufNgHkzSSvevRKuDjXRCY6vjwbNCYKfkPqiPr+P4MrZ89/srDOqzM4cQN1l6udZpQ+4O rfgywik53FGNJwj6PE/yfX2kCzJywnpGnCtvc= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=krND0QXYb+nlMMUc4icobBSu5sWUrbNZ+K/gQz53pNX7g4XH0msTlZiQJGDcej/TSQ qh/YnIQx9IkIIyMvG+DiCx7sEYhoEjvDbr78BMqhoQJIqCGYzN9AwOj/rBkIbTvi0YhG ACt+9DrC6LMLpUJZ0gLuNoLlyLDNBQCoGZR+A= I think Narayan means by move "change path" aka for the end user aka file system representation address anyway it's a lot of confusion around here Narayan you are assuming that a file descriptor depends on the path :) thanks a "FS system" is not stocked by this, you should have make some tests before asking your question (open a fd move remove on the file system representation whatever you want and trace what exactly happens, it's enough easy to do) you should start to read some stuff of Kirk (Marshall Kirk McKusick ), who spent a lot of time to write interesting stuff, your questions doesn't only fit with macos, the disease is deeper Cheers! On Wed, Jan 21, 2009 at 8:39 AM, Michael Smith <drivers(a)mu.org> wrote: > > On Jan 21, 2009, at 1:21 AM, Narayan Subramanian wrote: > > My question here is: Do we not call close() on the executable files > descriptor after we mmap() them into the process address space (inside > dyld)? I am assuming that the vnode corresponding to the file descriptor > should get freed after the file descriptor gets closed (right?). > > No. > > (I mean isn't that the only way we can move around an (on disk) executable > file that being run by another process?). > > What do you mean by "move around"? > > If that is true, how is it that we are still able to trace the vnode that > represents the file that was mmap()ed, after its descriptor was close()d? > > The same way as before. > > Who caches this vnode, how and where? > > Who do you think? 8) > > If this vnode is still 'alive' how is one able to physically move the > executable file (mapped by the process) on disk? > > Again, what do you mean by "move"? > > If you would like to point me to some code in the kernel for some > explanation, that is welcome. I have the sources for 10.4.11 with me. > > Start with everything in xnu/bsd/vfs, xnu/bsd/kern and osfmk/vm. > > A couple of concepts worth considering: > > - What do you mean by "move"? > > - Why do you think that an open file handle is fundamentally different from > an address space map entry when it comes to referring to an open file? > > - Why do you (seem to) think that a file can only exist if it has a > reference in the filesystem namespace? > > = Mike > > _______________________________________________ > 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/openspecies%40gmail.com > > This email sent to openspecies(a)gmail.com > -- -mmw _______________________________________________ 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