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

Re: ptrace / task_for_pid / pid_suspend
by Terry Lambert 08 Jul '10

08 Jul '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com - suspend dynamic_pager -- call malloc -- do stuff -- free - resume dynamic_pager ->The malloc call could stall indefinitely if the system needs to page -- Terry - Antoine On 2010-06-30, at 8:05 PM, Antoine Missout wrote: Hi Mike, Regards, Antoine On 2010-06-30, at 7:41 PM, Michael Smith wrote: Antoine, = Mike On Jun 30, 2010, at 2:12 PM, Antoine Missout wrote: Mike, There already is many dependency inversions on macos x. 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; } - Antoine On 2010-06-30, at 1:08 PM, Michael Smith wrote: Antoine, = Mike On Jun 30, 2010, at 7:59 AM, Antoine Missout wrote: Hi, So the questions are: 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 _______________________________________________ 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… _______________________________________________ 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 _______________________________________________ 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.… 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: 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. 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. 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. 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?) And suspend the dynamic_pager (as root), then start eating memory... The machine *will* deadlock. Likewise for other system critical processes. 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. 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. - 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 ?) 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 This email sent to antoine.missout(a)metakine.com This email sent to tlambert(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

process exits with bus error: forced to power-down reboot to fix filesystem
by Daniel Quinlan 07 Jul '10

07 Jul '10

site_archiver(a)lists.apple.com Delivered-To: Darwin-kernel(a)lists.apple.com 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. The normal first time start up mode is to create the large file by opening it, seeking to the end and writing a null byte, closing it, and then memory mapping the file. This approach has worked on Solaris and Linux without any problem, and often works on Macs as well. However, on mac's it can result in a bus error at some indeterminant point, as the process tries to write somewhere in the file. Oftentimes, this leaves the process in an exiting state, and the filesystem in a screwed up state: if you try to read the output file with another process, (e.g. cat), that process will also get locked into an uninterruptible state -- that is, control-C and control-Z have no apparent effect. (I've also seen `tail buffer` fail with a segmentation error!). Attempts to remove the file also lock up. Furthermore, the machine cannot be rebooted as it gets lost during the shutdown with the twirling display on an otherwise blank screen. You have to hold down the power button for 10 seconds to power down. On the reboot, sometimes the extra partition where I'm running the process will fail to mount. Disk Utility doesn't find anything wrong with it and succeeds in mounting it, though. On the other hand, changes to files during this period may vanish during the reboot, suggesting (I guess) that the journaling is fouled up. This message from the console following the reboot supports that idea: 7/6/10 4:52:33 PM fseventsd[58] event logs in /t/.fseventsd out of sync with volume. destroying old logs. (88483 1 88990) 7/6/10 4:52:33 PM fseventsd[58] log dir: /t/.fseventsd getting new uuid: 07C194F2-FDD3-4375-92F2-E33863DA9140 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. I've written a small, pretty simple, example program which emulates the operational program which is failing. It regularly fails while writing to the file. The filesystem problem doesn't always happen. This program starts several threads which sequentially write to the buffer, using a mutex to force just one thread at a time. In this example, I started eight threads and am using a 6 Gigabyte buffer. The bus error appears when the pointer is almost 1/3 of the way through the buffer. You can see in this case that attempts to print past this point using gdb also crash gdb. % gdb simple (gdb) run -n 8 Starting program: /opt/antelope/dev-64/bin/simple -n 8 Reading symbols for shared libraries +. done creating file diskbuffer with size 6000.00 Mbytes creating thread #0 creating thread #1 creating thread #2 Starting writer #0 with packet size 512 creating thread #3 Starting writer #2 with packet size 514 Starting writer #1 with packet size 513 creating thread #4 Starting writer #3 with packet size 515 creating thread #5 Starting writer #4 with packet size 516 creating thread #6 Starting writer #5 with packet size 517 creating thread #7 Starting writer #6 with packet size 518 Starting writer #7 with packet size 519 Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: 10 at address: 0x0000000165c0b000 [Switching to process 687] 0x00007fffffe00daf in __memcpy () (gdb) p BeginPtr $1 = 0x100200000 "\n### Thread #0 0 0x0\n" (gdb) p Ptr $2 = 0x165c0af03 "\n### Thread #0 413481 0x65a0af03\n" (gdb) p EndPtr $3 = 0x265c0bc00 "" (gdb) p Ptr-BeginPtr $4 = 1705029379 (gdb) p Ptr+512 Bus error A second time: % gdb simple (gdb) run Starting program: /opt/antelope/dev-64/bin/simple Reading symbols for shared libraries +. done creating file diskbuffer with size 6000.00 Mbytes creating thread #0 creating thread #1 Starting writer #1 with packet size 513 Starting writer #0 with packet size 512 Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: 10 at address: 0x0000000165c0b000 [Switching to process 943] 0x00007fffffe00aa2 in __memcpy () (gdb) where #0 0x00007fffffe00aa2 in __memcpy () #1 0x0000000100001551 in __inline_memcpy_chk (__dest=0x165c0afdb, __src=0x265f00000, __len=512) at _string.h:58 #2 0x00000001000014ea in write_packet (mythread=0, my_packet=0x265f00000 "\n### Thread #0 1663436 0x65a0afdb\n", nbytes=512) at simple.c:105 #3 0x0000000100001707 in writer (varg=0x0) at simple.c:127 #4 0x00007fff838cb456 in _pthread_start () #5 0x00007fff838cb309 in thread_start () (gdb) p BeginPtr $1 = 0x100200000 "\n### Thread #0 0 0x0\n" (gdb) p Ptr Bus error Trying to look at disk buffer with less: % less diskbuffer . . . less(1018) malloc: *** mmap(size=18446744071562067968) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug less(1018) malloc: *** mmap(size=18446744071562067968) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug less attempting to read diskbuffer. 53644 less danq 100.0 1 408 KB Intel (64 bit) 17.4 MB 596 KB In one instance, the simple program got stuck attempting to unlink the diskbuffer created by the previous execution. Here's a report created automatically: Library/Logs/DiagnosticReports/simple_2010-07-06-171154_windom.crash Process: simple [451] Path: /opt/antelope/dev-64/bin/simple Identifier: simple Version: ??? (???) Code Type: X86-64 (Native) Parent Process: tcsh [186] Date/Time: 2010-07-06 17:11:37.931 -0600 OS Version: Mac OS X 10.6.4 (10F569) Report Version: 6 Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Codes: 0x000000000000000a, 0x0000000165c0b000 Crashed Thread: 2 Thread 0: Dispatch queue: com.apple.main-thread 0 libSystem.B.dylib 0x00007fff838cceb6 __semwait_signal + 10 1 libSystem.B.dylib 0x00007fff838f3a36 pthread_join + 844 2 simple 0x00000001000019f0 main + 720 (simple.c:186) 3 simple 0x0000000100000fb4 start + 52 Thread 1: 0 libSystem.B.dylib 0x00007fff83892342 semaphore_wait_signal_trap + 10 1 libSystem.B.dylib 0x00007fff8389788d pthread_mutex_lock + 469 2 simple 0x00000001000016f0 writer + 400 (simple.c:127) 3 libSystem.B.dylib 0x00007fff838cb456 _pthread_start + 331 4 libSystem.B.dylib 0x00007fff838cb309 thread_start + 13 Thread 2 Crashed: 0 libSystem.B.dylib 0x00007fffffe00af7 __memcpy + 855 1 simple 0x0000000100001551 _inline_memcpy_chk + 65 (_string.h:58) 2 simple 0x00000001000014ea write_packet + 282 (simple.c:106) 3 simple 0x0000000100001707 writer + 423 (simple.c:127) 4 libSystem.B.dylib 0x00007fff838cb456 _pthread_start + 331 5 libSystem.B.dylib 0x00007fff838cb309 thread_start + 13 Thread 2 crashed with X86 Thread State (64-bit): rax: 0x00007fffffe00ab9 rbx: 0x0000000265c8d000 rcx: 0xfffffffffffffe40 rdx: 0x000000000000003b rdi: 0x0000000165c0b1c0 rsi: 0x0000000265e001c6 rbp: 0x0000000265c8cdf0 rsp: 0x0000000265c8cdf0 r8: 0x00007fffffe0082c r9: 0x0000000000000000 r10: 0x0000000100001be8 r11: 0x0000000165c0affa r12: 0x0000000000000000 r13: 0x0000000000001003 r14: 0x0000000100001560 r15: 0x0000000000000001 rip: 0x00007fffffe00af7 rfl: 0x0000000000010212 cr2: 0x0000000165c0b000 Binary Images: 0x100000000 - 0x100001fff +simple ??? (???) <6BBCC819-B4C8-1FDA-691C-E737A8E26468> /opt/antelope/dev-64/bin/simple 0x7fff5fc00000 - 0x7fff5fc3bdef dyld 132.1 (???) <B536F2F1-9DF1-3B6C-1C2C-9075EA219A06> /usr/lib/dyld 0x7fff83891000 - 0x7fff83a51fef libSystem.B.dylib 125.2.0 (compatibility 1.0.0) <95E02DD0-ADEA-745B-E7FA-ABA064E4658C> /usr/lib/libSystem.B.dylib 0x7fff86b14000 - 0x7fff86b18ff7 libmathCommon.A.dylib 315.0.0 (compatibility 1.0.0) <95718673-FEEE-B6ED-B127-BCDBDB60D4E5> /usr/lib/system/libmathCommon.A.dylib 0x7fffffe00000 - 0x7fffffe01fff libSystem.B.dylib ??? (???) <95E02DD0-ADEA-745B-E7FA-ABA064E4658C> /usr/lib/libSystem.B.dylib Similar behavior has been observed on various machines, but the current one is an older intel Mac Pro, running the latest released OS: Model Name: Mac Pro Model Identifier: MacPro3,1 Processor Name: Quad-Core Intel Xeon Processor Speed: 2.8 GHz Number Of Processors: 2 Total Number Of Cores: 8 L2 Cache (per processor): 12 MB Memory: 12 GB Bus Speed: 1.6 GHz Boot ROM Version: MP31.006C.B05 SMC Version (system): 1.25f4 Serial Number (system): G8806310XYL Hardware UUID: 5150670E-61A1-5491-97F1-AF8F88B1AFAE % uname -a Darwin windom 10.4.0 Darwin Kernel Version 10.4.0: Fri Apr 23 18:28:53 PDT 2010; root:xnu-1504.7.4~1/RELEASE_I386 i386 I'm using the latest xcode 3.2.3, but the same behavior has been seen with the previous version. Here's the program and makefile: % cat makefile simple : simple.o FORCE clang -o simple -g simple.o -m64 dsymutil simple FORCE: % cat simple.c #include <errno.h> #include <fcntl.h> #include <math.h> #include <pthread.h> #include <stddef.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <synch.h> #include <sys/mman.h> #include <sys/param.h> #include <sys/stat.h> #include <sys/types.h> #include <unistd.h> char *BeginPtr, *EndPtr, *Ptr ; long BufSize = 6000000000 ; long PktSize = 512 ; static void usage (void) { fprintf(stderr, "Usage: %s [-P pktsiz] [-s size]\n", "simple" ) ; exit(1) ; } double mbytes ( long nbytes ) { return (nbytes/1.0e6) ; } int mkfile ( char *name, unsigned long nbytes ) { int fd ; int zero = 0 ; if ( (fd = open ( name, O_CREAT | O_RDWR | O_TRUNC, 0664 )) < 0 ) { fprintf( stderr, "Can't create new file '%s'\n", name ) ; return -1 ; } if ( lseek (fd, nbytes-1, SEEK_SET) != (nbytes-1) ) { fprintf( stderr, "Failed to seek to end of new file '%s'\n", name ) ; return -1 ; } if ( write ( fd, &zero, 1 ) != 1 ) { fprintf( stderr, "Failed to write byte at end of new file '%s'\n", name ) ; return -1 ; } if ( truncate ( name, nbytes ) ) { fprintf( stderr, "Can't truncate file '%s' to length %ld\n", name, nbytes ) ; return -1 ; } return 0 ; } long wmapfile (char *filename, char **mmap_datap) { int fd ; struct stat statbuf; char *mmap_data; long retcode = 0 ; fd = open (filename, O_RDWR); if (fd < 0) { fprintf( stderr, "Couldn't open %s\n", filename); retcode = -1 ; } else if (fstat (fd, &statbuf)) { fprintf( stderr, "fstat failed for '%s'\n", filename); retcode = -1 ; } else if (statbuf.st_size == 0) { fprintf( stderr, "'%s' is empty\n", filename); retcode = -1 ; } else { mmap_data = mmap (NULL, statbuf.st_size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0L); close (fd); if (mmap_data == (char *) -1) { fprintf( stderr, "Can't map file %s\n", filename); retcode = -1 ; } else { *mmap_datap = mmap_data; retcode = statbuf.st_size ; } } return retcode ; } void write_packet( long mythread, char *my_packet, long nbytes) { if ( EndPtr - Ptr < nbytes ) { Ptr = BeginPtr ; } sprintf(my_packet+25, " %p\n", Ptr-BeginPtr) ; memcpy(Ptr, my_packet, nbytes ) ; Ptr += nbytes ; } void * writer(void *varg) { static pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER ; long mythread = (long) varg ; long i, my_pktsize ; long cnt = 0 ; char *my_packet = 0 ; my_pktsize = PktSize + mythread ; my_packet = (char *) malloc(my_pktsize) ; sprintf(my_packet, "\n### Thread #%02ld ", mythread) ; for (i=strlen(my_packet) ; i<my_pktsize ; i++ ) { my_packet[i] = ' ' ; // mythread*1000 + i ; } fprintf(stderr, "Starting writer #%ld with packet size %ld\n", mythread, my_pktsize) ; for (;;) { sprintf(my_packet+14, " %10ld", cnt++) ; pthread_mutex_lock ( &lock) ; write_packet(mythread, my_packet, my_pktsize) ; pthread_mutex_unlock( &lock) ; } return (void *) 0 ; } int main (int argc, char **argv) { int c, verbose = 0, errflg = 0; long i, nthreads=2 ; pthread_t child_thread; char *filename = "diskbuffer" ; void *status ; while ((c = getopt (argc, argv, "n:s:S:vV")) != -1) { switch (c) { case 'n': nthreads = atol(optarg) ; break; case 's': BufSize = atol(optarg) ; break; case 'S': PktSize = atol(optarg) ; break; case 'v': verbose++ ; break; } } if (errflg) usage (); unlink(filename) ; fprintf(stderr, "creating file %s with size %.2f Mbytes\n", filename, mbytes(BufSize) ) ; if ( mkfile ( filename, BufSize) ) { fprintf(stderr, "Can't create file %s of %.2f Mbytes\n", filename, mbytes(BufSize)) ; exit(1) ; } BufSize = wmapfile ( filename, &BeginPtr ) ; Ptr = BeginPtr ; EndPtr = BeginPtr + BufSize ; for (i=0 ; i<nthreads ; i++) { fprintf (stderr, "creating thread #%ld\n", i ) ; if ( pthread_create (&child_thread, 0, writer, (void *) i )) { fprintf ( stderr, "failed to create client thread\n" ) ; exit(1) ; } } pthread_join (child_thread, &status ) ; fprintf (stderr, "Quitting\n" ) ; return 0; } _______________________________________________ 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: Supporting non-blocking sends in a socket filter NKE
by Bogdan Harjoc 07 Jul '10

07 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=R3FTGXP/7RirvmIo1R0az0+l+1YmC5d6ch/ldZS9pgE=; b=NM4AKWTPZ9B3JweMPj9rToTIU3pfzCK7c+dOqieAJ1KcQz3LcwYQSGbA/YKz1bDejw 37t6I5iHCiz55RPahpm73ZUsmJ+hzRCmAL6MlqbvbmJjqJAc+qOkFg1egxioD6tGoMHM rBafGlAYjzLB2Y5hf7ck5zVrAddSM+j7S0tvc= 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=bx4DHSVs+oJLa+vHNbHSgsYJSNzBo7gNd1pZs1+03/lnD9oEiJFvzQS1FmzKeUHVO7 3SO3KdgD/wkv2oU0NgZmXrCz7BxGByIvGJjIQdVypR6x4fEyg4UkQX8UNRNQqWEqDS0H dBfzyWVt0iLS1Xx2qnjBUqIlS48ALsLyt9VbI= Not an authoritative answer, but: Anything else except zero and EJUSTRETURN that you return in sf_data_in_func gets interpreted as "drop the data" from what I understand. Userspace won't receive the error. If the KPI allowed this, you could manipulate the sb_hiwat field in the "struct socket" when your NKE is busy, which would make the window shrink to zero, which is possibly what you want. But there is no such KPI (yet). See [1] for a clean way to do this. But you need a userspace daemon and additional loopback connections will show up in netstat. Hope this helps, Bogdan [1] http://lists.apple.com/archives/darwin-kernel/2007/Mar/msg00081.html On Mon, Jul 5, 2010 at 9:30 PM, Ryan Weedon <ryan.weedon(a)mobidia.com> wrote: > I have an NKE that uses a socket filter to intercept TCP data sent by > applications. > > I am trying to figure out how to deal with the case where an application > sets a socket to be non-blocking, and then sends data faster than the NKE > can handle it. The filter can just return EAGAIN/EWOULDBLOCK at this point, > but I don’t know how to signal at some point later the socket is again > available for writing. Is this possible? > > > > Regards, > > Ryan Weedon > > > > _______________________________________________ > 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/harjoc%40gmail.com > > This email sent to harjoc(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

Small omission in NKE sample ?
by Bogdan Harjoc 07 Jul '10

07 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=vZti3kk9PJerx4nhK2KrvLArdaOTiMaYpGdsU/qP2jQ=; b=pjXgyaeTs+RLpKtfdM3uQdM8h6jbI9vOW0u5CuE4lejJHw3kYLsw+dSt6VhJLM1BFw 748LORZ2ULseVw4MbjhCoVFDEoeXhAlMh0G7Q+20G2DgPBpx0nfgOm9aKVceorUfaMVa T3+XSI6LcSamESmisKHeCDGOQpnn5tYZZ8W7o= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=dDoAkM+B4UXwwuC3wQ8YcWwRg6/fDqNRc068UDCWShdmsE+isFGiUVEDdEAp+GGwl2 b/qnapkkAM5dF4Q/QwC0ePLi4fW9PYvac284nN/v3HCE6UrzSju5hgPMEAp6yJgPzROE DByNaMRWS143+inGWpGa3ZjrrfzWUCLM3gYTU= Hello, Attached is a patch for what I think is a bug in the tcplognke sample, I would appreciate a reply if I missed something. While I'm here, I'd like to ask why mcache_alloc would ever get stuck in msleep (stack is below). This stack trace is how I ended up revisiting the sample code (that I'm using in my kext). Thanks, Bogdan 0x31a8b968 0x226e57 <thread_invoke+1213> 0x31a8b9e8 0x2270f6 <thread_block_reason+331> 0x31a8ba58 0x227184 <thread_block+33> 0x31a8ba78 0x221948 <lck_mtx_sleep+87> 0x31a8ba98 0x4867fc <_sleep+299> 0x31a8bb08 0x486eef <msleep+157> 0x31a8bb48 0x4a6732 <mbuf_slab_alloc+1251> 0x31a8bbb8 0x48ed52 <mcache_alloc_ext+426> 0x31a8bc28 0x48ee72 <mcache_alloc+39> 0x31a8bc58 0x4a812b <m_get+51> 0x31a8bc88 0x4aac61 <m_tag_alloc+57> 0x31a8bcb8 0x48c3b7 <mbuf_tag_allocate+188> 0x31a8bcf8 0x3203f64f <(my kext) + 0x164f> ... (OS X 10.6.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/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com tcplognke-always-set-tag-value.patch

1 0

Supporting non-blocking sends in a socket filter NKE
by Ryan Weedon 05 Jul '10

05 Jul '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Thread-index: AcsccCldLleTAkl0QEKRtCw4JqAuUA== Thread-topic: Supporting non-blocking sends in a socket filter NKE _______________________________________________ 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: ptrace / task_for_pid / pid_suspend
by Antoine Missout 01 Jul '10

01 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

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

01 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