July 2010 - Darwin-kernel - lists.apple.com

Re: accessing interface name in ifnet list
by Ryan Hankins 13 Jul '10

13 Jul '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 _______________________________________________ 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/rqh%40small-tree.com This email sent to rqh(a)small-tree.com -- Ryan Hankins Software Engineer Small Tree Communications www.small-tree.com rqh(a)small-tree.com +1 651 209-6509 x303 _______________________________________________ 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: Need to gain access to unexported symbols
by Shantonu Sen 13 Jul '10

13 Jul '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com What version of Mac OS X are you targeting, and what architecture? If you build your own kernel, you can add whatever symbols you like to the exports list. Just to be sure, you're aware of <http://opensource.apple.com/source/xnu/xnu-1504.7.4/bsd/net/pf.c> right? Shantonu On Jul 13, 2010, at 9:09 AM, Platon Fomichev wrote: > Good day, everyone > > Our team is porting OpenBSD PF filter to OS X and the progress so far is good. However we're battling with lots of 'hidden' symbols we need access to. Yes we know this is kernel tied stuff, but the project is supposed to be kernel-tied as closely as possible, so this is OK. We need access to some functions like in_pcblookup* funcs and some primitive ones like _boottime_sec(). > > The question is simple - we can't link against these functions like _boottime_sec() because they are not exported from Kernel and kextload complains. Can you suggest me the way to workaround this - I just always can't copy-paste parts of the kernel (like I do now!) to implement some funcs. Yes, I understand this is hack, but for now we need a prototype to show to the customer - if it will be successfull I hope they will try to push Apple to help us, but without workaround my hands are tight. > > Let's start with simple - very simple func _boottime_sec() - it's not exported - how can I still link with it? > > Thanks in advance. > > Platon Fomichev > > > > > _______________________________________________ > 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/ssen%40apple.com > > This email sent to ssen(a)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

1 0

accessing interface name in ifnet list
by mogambo 13 Jul '10

13 Jul '10

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:received:date:message-id :subject:from:to:content-type; bh=HdTDJefFmGLeQrIGqdOX9lPKwtrj08n6Vmps7XJTJbM=; b=R6sD3SGopg2iutdJPEecPEfl/wk44g7S3FOLCmZU3iL2kvv4ZgcVvVnje9HddEBwbc jzvcaTr/LVgn9B50HbOYO2aOebE9Bbp9nx52Rpr2ODnjnwrN9A8H5q6xgkGR5CIi+Z4i QZavUObYnAWJz1TeSB8p+TQpHCh3RJ1MiV/cQ= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=hDA01bj9MtdbgpApO/XClkYS0Wa41DM84Kl1Oyo/CBvvUxJMtr1DeSZ4kY5WClnsIW HrXC1VKtWqaV3EP9skHWV77kHWxa6mfnhBHL+FrH/A29C+r41bV42fcDbZ7H+ANaPxgi a0yQC6Dp5aGM5F0kO+sarnIeJVi7cFPGRxAcU= _______________________________________________ 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: Need to gain access to unexported symbols
by Ken Hornstein 13 Jul '10

13 Jul '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com >Let's start with simple - very simple func _boottime_sec() - it's not >exported - how can I still link with it? I can't help you with in_pcblookup, but regarding boottime_sec(); are you sure you have to have THAT exact function? Or could you live with something that does the exact same thing? For example, you can call sysctls directly from kexts, and the kern.boottime sysctl returns the value of boottime_sec. If you're asking how to link arbitrary function <X>, where <X> is not exported, well, you have (as far as I can tell) two options: - Hope that it's available in something like the Unsupported kext, or - you lose. I will note that there is already a supported framework to plug in something like a network or interface filter; I'd try to use that as much as possible. --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

Need to gain access to unexported symbols
by Platon Fomichev 13 Jul '10

13 Jul '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Good day, everyone Thanks in advance. Platon Fomichev _______________________________________________ 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.… Our team is porting OpenBSD PF filter to OS X and the progress so far is good. However we're battling with lots of 'hidden' symbols we need access to. Yes we know this is kernel tied stuff, but the project is supposed to be kernel-tied as closely as possible, so this is OK. We need access to some functions like in_pcblookup* funcs and some primitive ones like _boottime_sec(). The question is simple - we can't link against these functions like _boottime_sec() because they are not exported from Kernel and kextload complains. Can you suggest me the way to workaround this - I just always can't copy-paste parts of the kernel (like I do now!) to implement some funcs. Yes, I understand this is hack, but for now we need a prototype to show to the customer - if it will be successfull I hope they will try to push Apple to help us, but without workaround my hands are tight. Let's start with simple - very simple func _boottime_sec() - it's not exported - how can I still link with it? This email sent to site_archiver(a)lists.apple.com

1 0

Re: Library Kexts
by Michael Smith 13 Jul '10

13 Jul '10

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

1 0

Library Kexts
by Duane Murphy 12 Jul '10

12 Jul '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I am trying to create a library kext. This library kext is created from two other static libraries, each compiled for a different architecture: i386 and x86_64. The libraries cannot be combined into a common build target because they have different files and settings depending on the the target architecture. In particular there are assembly files involved. The problem is that the libraries are not being included in their entirety in the library kext. Only referenced symbols and dependencies are included. It seems like stripping, but I think it's just basic dependency inclusion. Is there someway to just get the entirety of both libraries linked and combined into the one library kext? The projects targets dependencies looks like: Library kext library_kext_module_start library_kext_module_stop libtarget_i386 <files> libtarget_x86_64 <files> If I access symbols from the library kext (for example in library_kext_module_start), those symbols will be included. But I'd just like the entire library to be included. Thank you for your help, ...Duane -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 10.0.2 (Build 13) Charset: US-ASCII wsBVAwUBTDtfYUrg9acQ4r2CAQglyQgAxpnYf7+nLbWY3ndWZK/+i/Plk3KKhfmE W/ZFDG7yXGAmUj8CgfSyf959smZ+5ybypl3y63wMP99X33FksmQsc0qQFB7cUfla WXX7E/dyA/u2XZHsBDu6sGsK5yNdIxuwyY1RoP72iw6B72WqxFajDw8ItLsqgOwJ wK+q/2iSDwU0Jfvwc4pHPolMcPyW180j4tvQYdAvLP7zJ2AXXBR0nE+y9bYIc8gc 18KeQZ4gQX9xHLA4alVGLH1tebCdzXcU8hi03oxzbFGW7iD2rfJPtTS4YCAQXqWM 6xTvb9kXBzCHLqoFJjvJtFMuqF+SscabfqMUBDgTgFDBKR4XxpomgQ== =pXAr -----END PGP SIGNATURE----- _______________________________________________ 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: process exits with bus error: forced to power-down reboot to fix filesystem
by James Peach 09 Jul '10

09 Jul '10

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:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=BxhhgLk78Vad/ZZOMLprReYgyfkw6XiioZPqxeeK4lI=; b=R2Tau7oqOsUld76z575QhAtNL9atIMwAr28I86ccf0Kox/bvHL/kXuM5M2pc4pyDTG MRxjwqlucYL1PlFw73j0l3ABTBGcjxsBNK6Hn3umeb1dvAdWfW7qnHD3cJ9VkuDglZlM /uVhV7DwFJN4PBBScVds4XGFMtk3FVvxIen7o= 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=lGviymBaD08wODfVet4iDlcgkXhdYVku7osISlBYPiaY+uyKBmk4vtvr2ua3IEqUu9 zrR5oY996nz5QyKltci4TWX/EMQUTs4V1T4czVq9Z60Ft7+YsbEfNLn4TiuCg9mdkqhT 8pvEdeT/yFIhdeVAfkpHIDbNEW+DX1JV1D+LU= On 8 July 2010 14:35, Terry Lambert <tlambert(a)apple.com> wrote: > On Jul 7, 2010, at 12:37 PM, Daniel Quinlan wrote: >> >> I'm not certain this is the right list for this problem, but it seems to >> me to be a kernel problem of some sort. >> It's rather long, but I've tried to be comprehensive. I've also submitted >> this as a bug to the >> apple bug reporter. >> >> We have a problem with a ring buffer program which memory maps a large >> file. > > [ ... ] > >> We can evade the problem by initializing the buffer file before >> starting the ring buffer program, but this is operationally difficult >> -- and it hasn't been necessary on other platforms. >> >> The problem appears to be related to how quickly the ring buffer >> program is writing to the buffer file -- if it's slow enough and the >> buffer file is small enough, we typically don't see the problem. It >> seems to need multiple threads writing in the operational program. > > HFS does not support sparse files, so you are waiting for it to allocate > backing pages. On the other operating systems, the FS's you are using > apparent support sparse files, and therefore the backing pages are being > lazily allocated for the sparse file control structures, which are allocable > quickly. Some combination of fcntl(F_PREALLOCATE) and fsync(2) can probably be used to close the race condition. > Technically, you still have a race condition on those other machines, you > are just lucky that the order you start writing is the same as the order in > which the control structures are allocated. That is you win the race > because your use is such that the control structures themselves are in place > by the time you get to any region of the file governed by the control > structures in question. It would really be best on all platforms for you to > preallocate your file, or at least the control structures. > > On Mac OS X you can use UFS (if it's a very old Mac OS X) or UDF (if it's a > modern one) since both those filesystem types support sparse files. This is > still racy (as noted above), but you would be in the same boat as you are on > the other filesystems. > > PS: You do not get an aggregate performance win for using a sparse file. > You win on startup time, but what you win there, you lose in runtime, as > the operations are stalled waiting for backing store allocation whenever you > hit a file region that does not already have backing store pre-allocated. > If runtime performance is more important than startup performance, you may > want to take that into account and write a byte in the filesystem blocks on > block boundaries after allocating them on the other operating systems. > > PPS: I would minimally put an interlock there, such as opening the file > initially O_EXCL, to block the second process' open of the file to prevent > the file being used by the second process before it's ready, no matter what > else you do. > > -- 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/jorgar%40gmail.com > > This email sent to jorgar(a)gmail.com > -- James Peach | jorgar(a)gmail.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

1 0

Re: process exits with bus error: forced to power-down reboot to fix filesystem
by Terry Lambert 08 Jul '10

08 Jul '10

site_archiver(a)lists.apple.com Delivered-To: Darwin-kernel(a)lists.apple.com We have a problem with a ring buffer program which memory maps a large file. [ ... ] We can evade the problem by initializing the buffer file before starting the ring buffer program, but this is operationally difficult -- and it hasn't been necessary on other platforms. The problem appears to be related to how quickly the ring buffer program is writing to the buffer file -- if it's slow enough and the buffer file is small enough, we typically don't see the problem. It seems to need multiple threads writing in the operational program. -- 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 Jul 7, 2010, at 12:37 PM, Daniel Quinlan wrote: I'm not certain this is the right list for this problem, but it seems to me to be a kernel problem of some sort. It's rather long, but I've tried to be comprehensive. I've also submitted this as a bug to the apple bug reporter. HFS does not support sparse files, so you are waiting for it to allocate backing pages. On the other operating systems, the FS's you are using apparent support sparse files, and therefore the backing pages are being lazily allocated for the sparse file control structures, which are allocable quickly. Technically, you still have a race condition on those other machines, you are just lucky that the order you start writing is the same as the order in which the control structures are allocated. That is you win the race because your use is such that the control structures themselves are in place by the time you get to any region of the file governed by the control structures in question. It would really be best on all platforms for you to preallocate your file, or at least the control structures. On Mac OS X you can use UFS (if it's a very old Mac OS X) or UDF (if it's a modern one) since both those filesystem types support sparse files. This is still racy (as noted above), but you would be in the same boat as you are on the other filesystems. PS: You do not get an aggregate performance win for using a sparse file. You win on startup time, but what you win there, you lose in runtime, as the operations are stalled waiting for backing store allocation whenever you hit a file region that does not already have backing store pre-allocated. If runtime performance is more important than startup performance, you may want to take that into account and write a byte in the filesystem blocks on block boundaries after allocating them on the other operating systems. PPS: I would minimally put an interlock there, such as opening the file initially O_EXCL, to block the second process' open of the file to prevent the file being used by the second process before it's ready, no matter what else you do. This email sent to site_archiver(a)lists.apple.com

1 0

Re: ptrace / task_for_pid / pid_suspend
by Antoine Missout 08 Jul '10

08 Jul '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Hi Terry, Thanks for the information. We will requests APIs for what we need, but since we know there's no chance they'll be implemented by the end of August, we did not rely on that route. What we're doing is indeed currently unsupported. But it has been stable, we didn't have to change a thing from 10.5.8 to 10.6 to 10.6.4. More on that in a follow-up email off-list (I'll explain our design and what we need). As for DirectoryService, it's not technically a kernel deadlock, but as I said, you'll be hitting the power button quite soon... There is no issue with it afaik, I just took that as an example. For the deadlock avoidance: timeouts will do the trick as the kernel does with DS, but hitting timeouts makes for a sluggish system, so avoiding timeouts in addition (using early detection) is even better. - Antoine On 2010-07-08, at 5:15 AM, Terry Lambert wrote: > I really did not like the implications of what you are doing with regard to requiring lock-stepping a kernel version. It implies interposition of non-KPI kernel functions for which KPI was no provided, with a reason. If you need KPI for something, please file a bug report requesting it (with an explanation of your problem space), and if the request is reasonable, people will try to accommodate the request, if possible. With the expression of the problem space, however, you are more likely to get an explanation of how you should actually be trying to accomplish the goal that led you to request the KPI. > > > On Jul 1, 2010, at 12:43 PM, Antoine Missout wrote: >> A few notes about suspending processes. These two are (potential) deadlocks: >> >> - suspend dynamic_pager >> -- call malloc >> -- do stuff >> -- free >> - resume dynamic_pager >> ->The malloc call could stall indefinitely if the system needs to page > > Investigate Djikstra's "Banker's algorithm": <http://en.wikipedia.org/wiki/Banker's_algorithm> > > This is how most Apple code avoids deadlocks from call-outs to other code: be ready with the answer for any possible question you might be asked. > > >> - suspend DirectoryServices >> -- call getgroups or getpwent >> - resume DirectoryServices >> ->The call will stall forever as it is serviced by DirectoryServices (and the machine will become unusable pretty quickly as DirectoryServices is needed by almost anything). > > These calls are library functions which are handled by a user space IPC, and do not involve a kernel deadlock. > > It's true that the kernel also calls out to DirectoryServices for group membership questions in support of users in more than 16 groups. If DirectoryServices does not respond to an individual request within 30 seconds, then the kernel will revoke it's authority, fail the outstanding unanswered requests, and not forward additional requests to DS. If DS requests additional work from the kernel after that, it receives an EPERM from the system call, indicating that it has to reregister as the external group membership resolver. > > If there is actually an issue in the user space IPC, then you need to file a bug report, but this is not a kernel deadlock. > > >> Now it turns out Instruments does something like this: >> - get the task_t for our daemon through task_for_pid >> - suspend our daemon >> -- (inspect it's memory ?) >> -- call stat on the daemon executable path >> - resume our daemon >> -> this deadlocks the machine since we police file accesses through our daemon > > You are pretty clearly doing what I feared, above. If you are interposing via a mechanism other than kauth, your model is not supported. If so, request additional kauth KPI to support your model via supported interfaces (see above on "reasonableness"). > > The kauth interface in general is what is intended for this, and if you are doing the gating via kauth, you MUST be prepared to answer the question immediately, without additional system calls. If you require communication with other components, your other components MUST follow the same rule. If you require communication with system components, you MUST exempt them from your interposition, and ensure they follow the Banker's algorithm philosophy themselves (or don't use those services). > > If an AntiVirus vendor, for example, asks me how they should handle virus pattern files, I tell them to map them into the daemon process' address space so that access to the answer is via the paging path, and make their daemon immune to interposition via the paging path. This lets their patterns avoid being in wired memory, lets them have a user space component, and guarantees that they can give an answer to any kernel request. In addition, I tell them to follow the DirectoryServices model by having some way of timing out the authority of the daemon if the daemon becomes unresponsive. > > >> *** Actually, if you suspend a process you don't know, you basically cannot call any system call or mach rpc as you do not know if they rely on the process you just suspended. *** > > Correct. This is an (effectively) insolvable problem with the design of existing APIs (which can not be changed due to standards constraints or hardware limitations), and additionaly have the inability to establish a chain of trust for a request proxied through or from untrusted code in any case. > > When you start using general purpose frameworks, or third party libraries rom the daemon, frankly, all bets are off. There's no way to find a Hamiltonian cycle in the "Z made this request, but A is responsible for triggering this request because A messaged B which communicated with C via shared memory which used a socket to talk to C which ... Z", and therefore exempt the request on the basis of its origin. There are too many IPC mechanisms with unattributed sources to proxy identity through all of them, and you can not trust the code path to not alter the message payload in flight. > > >> Right now I just disabled any daemon communication while it is suspended (and log an error), but what I'm thinking of doing is to whitecard any pid that suspends our daemon so that they can hopefully resume it without getting blocked. This will stalls other processes that needs our daemon until the suspender is done with our daemon. >> >> Does that makes sense ? > > Generally, no (see above). Use a deadlock avoidance strategy rather than deadlock detection and (attempted, and therefore failure-prone) mitigation strategy. You will be much happier. > > -- Terry > >> >> - Antoine >> >> On 2010-06-30, at 8:05 PM, Antoine Missout wrote: >> >>> Hi Mike, >>> >>> They are stalls unless, as you say, what is required to restart them is being held up by what they serve. >>> >>> If you suspend taskgated, it becomes impossible to resume it as pid_resume will try to consult taskgated which is suspended. Deadlock... You can try it. So if any process suspend taskgated by mistake or for any reason, it will lead to big problems: I'm guessing something similar is at play here. >>> >>> The careful consideration of the upstream dependencies is the heart of the issue. And the reason why I'm trying to get more info on what Instruments/CHUD needs, as this is the only thing I could find at the moment that leads to a problem with our setup. I do not know why yet, but simply denying the task_for_pid fixes it for now. Of course I'll look deeper to find the root cause. >>> >>> We can simply trace everything until we find what is going on, but I just thought it would be faster to simply ask. >>> >>> In any case, we have several different ways to avoid the problem, one of which already in place, but I don't think it is the most elegant yet. >>> >>> Regards, >>> Antoine >>> >>> >>> >>> >>> On 2010-06-30, at 7:41 PM, Michael Smith wrote: >>> >>>> Antoine, >>>> >>>> Neither of these are inversions, as the userland components don't rely on the services they vend. There are several other similar service tasks in the system as well, all of which are maintained by Apple with careful consideration to their upstream dependencies. >>>> >>>> In addition, neither of your strawmen are deadlocks; both are simply stalls. The dynamic_pager example is just physical page starvation, and the taskgated example is just a stall waiting for service. >>>> >>>> If your architecture causes a deadlock, you need to fix it. If you're simply stalling service until the daemon is restarted, and what you're serving isn't required in order for the daemon to restart, then I don't see your problem. >>>> >>>> = Mike >>>> >>>> On Jun 30, 2010, at 2:12 PM, Antoine Missout wrote: >>>> >>>>> Mike, >>>>> >>>>> There already is many dependency inversions on macos x. >>>>> >>>>> I'm sure if you suspend the dynamic_pager process, the machine will eventually deadlock (actually, I tested it). >>>>> >>>>> Likewise, task_for_pid consults with taskgated (a user-space process), without any timeout (check osfmk/mach/task_access.defs), so if taskgated gets suspended, that will also block indefinitely. >>>>> >>>>> There are many other examples. Grep the xnu source code for KERNEL_USER... most of those calls do not have timeouts and will deadlock if the process servicing those rpc calls are suspended. >>>>> >>>>> So I'm guessing Instruments takes care not suspending the dynamic_pager, or taskgated ? Or it doesn't suspend them long enough to make a problem ? (race condition?) >>>>> >>>>> Actually, try this (requires 10.6.4): >>>>> #include <unistd.h> >>>>> #include <stdio.h> >>>>> int main(int argc, const char* argv[]) >>>>> { >>>>> if (argc != 3) >>>>> { >>>>> printf("./test 0 pid (for suspend)\n"); >>>>> printf("./test 1 pid (for resume)\n"); >>>>> return 2; >>>>> } >>>>> int sr = atoi(argv[1]); >>>>> int pid = atoi(argv[2]); >>>>> int r = syscall(430 + sr, pid); >>>>> if (sr) printf("pid_resume(%i) return %i\n", pid, r); >>>>> else printf("pid_suspend(%i) return %i\n", pid, r); >>>>> return 0; >>>>> } >>>>> >>>>> And suspend the dynamic_pager (as root), then start eating memory... The machine *will* deadlock. >>>>> Likewise for other system critical processes. >>>>> >>>>> - Antoine >>>>> >>>>> >>>>> >>>>> On 2010-06-30, at 1:08 PM, Michael Smith wrote: >>>>> >>>>>> >>>>>> Antoine, >>>>>> >>>>>> Your design is bad; you have introduced a dependency inversion and you need to come up with a way for the kernel to make forward progress without your daemon running. Even if it is "running", there is no guarantee that it can run (e.g. blocked on a pagefault) when you expect it to. >>>>>> >>>>>> Or at the very least, tell us what your product is so that we can avoid it. >>>>>> >>>>>> = Mike >>>>>> >>>>>> >>>>>> On Jun 30, 2010, at 7:59 AM, Antoine Missout wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> We have a kernel driver + user-space daemon for a new product. Once loaded & running, the daemon becomes crucial to the proper running of the kernel: more exactly, the daemon can be running or not, but must not freeze as the kernel will deadlock while waiting for an answer. >>>>>>> >>>>>>> The setup is now very stable, the only issue we've run lately was with Instruments, using Time Profile for all process: this would result in an immediate lockup of the machine. >>>>>>> >>>>>>> Reading a bit of documentation about this probing, it seems Instruments suspends all process to take statistics. >>>>>>> >>>>>>> Now to avoid this problem, we've taken step to disable ptrace(PT_DENY_ATTACH), task_for_pid for our daemon, and while we're at it, also pid_suspend introduced in 10.6.4. >>>>>>> >>>>>>> This now allows for Instruments to Time Profile the whole machine without lockup the machine. We would prefer to take less drastic steps to avoid this deadlock, but without knowing what exactly is Instruments doing using our task port, this is difficult. It still seems to gather stats for the daemon, but the addresses look like garbage. >>>>>>> >>>>>>> So the questions are: >>>>>>> >>>>>>> - what is Instruments (or DTTSecD ?) doing exactly ? >>>>>>> - is there a better way to make sure the daemon is never suspended in any way ? (or know it in advance ?) >>>>>>> >>>>>>> Thanks, >>>>>>> Antoine >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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/drivers%40mu.org >>>>>>> >>>>>>> This email sent to drivers(a)mu.org >>>>>> >>>>>> -- >>>>>> Excellence in any department can be attained only by the labor of a lifetime; it is not to be purchased at a lesser price -- Samuel Johnson >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> -- >>>> True terror is to wake up one morning and discover that your high school class is running the country. -- Kurt Vonnegut >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> _______________________________________________ >>> 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/antoine.missout%40meta… >>> >>> This email sent to antoine.missout(a)metakine.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/tlambert%40apple.com >> >> This email sent to tlambert(a)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

1 0