From owner-freebsd-net@FreeBSD.ORG Thu Apr 11 14:58:22 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 64F867C6 for ; Thu, 11 Apr 2013 14:58:22 +0000 (UTC) (envelope-from laurie_jennings_1977@yahoo.com) Received: from nm13-vm2.bullet.mail.ne1.yahoo.com (nm13-vm2.bullet.mail.ne1.yahoo.com [98.138.91.89]) by mx1.freebsd.org (Postfix) with ESMTP id 78829FAA for ; Thu, 11 Apr 2013 14:58:21 +0000 (UTC) Received: from [98.138.90.57] by nm13.bullet.mail.ne1.yahoo.com with NNFMP; 11 Apr 2013 14:58:15 -0000 Received: from [98.138.226.161] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 11 Apr 2013 14:58:15 -0000 Received: from [127.0.0.1] by omp1062.mail.ne1.yahoo.com with NNFMP; 11 Apr 2013 14:58:15 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 40162.61170.bm@omp1062.mail.ne1.yahoo.com Received: (qmail 43033 invoked by uid 60001); 11 Apr 2013 14:58:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1365692294; bh=eAG9z3fVE7tFDpVN2+m5NqWUWf5BvojkCFve1U9n+vc=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=0EaVu9K3NDdSeszRftH3CwJLgpZQy/Ethk/9na/FcnwfFveIhT+x7BhbLkNApRe8lVbzNtn6SNOcsp5zDs3dxwws/rTXMm0ONlBbfF866G7xG3hKJtO+aWp6xvjrV36hfpSrVXDOcrc+8jWMYZJ5Bpbq8POeJV39CTvBav3Wp/4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=wL19KokErFBYTq9RuAnux+aAcF612AC/sqR0T7h55TrlQ9btavPA0s8eEPMY/b8kXlHpf1QCpApQIxH34BqZj+TPCTum6vwkw5spC7FA5duOAL2AEu5n/XBL/T4mTTicbRqKtfwr1fa81Ld9ZCb8Tfi9UTmoIj9Wd2kUNvEG0uI=; X-YMail-OSG: u.kcfxcVM1krWEUuZrPhXgSt1OjJ4NtY05MWnqbGSqUQSZb IT_tGfuq3lO3zHsu1ZRVP.CcrenZXbpbxNpV8xHqVxbXz1GKVgLfGZGrPZ_a kQ.zzayokRpDX9suQBZ9NynXvzpWSpt5KlihoKVjLEgWgbLaqJyrTEqD57VF KhNM2mgeDYKVLEEyK8xBypO9KSQqS33mwOTjSy1sPCYMuZ13B6vT28XB4HV6 .8q7QjDtyxjiIjtzc7b90d7psWiwuBKBW1jakONBkGiI8MM8VRXHev5oRIxm A90vFAM.Lg9_dXJjVGszDVQAWxrwpMpUiHyuDDQRFibY.5cIzJjKsgdlu11n 4ZKUMemjEDkBjtVdtdEiB5WNwKU2vxIm.H9HrOQ_59fC75vEARcZKf37j_GS z2tjqyWI2oG7PZRkuqS_EfiBiNoyouh5IHpQ3wkN2UGUqhfTFVvDxgc3aBG1 DSeeNvJPr0YE- Received: from [98.203.118.124] by web125801.mail.ne1.yahoo.com via HTTP; Thu, 11 Apr 2013 07:58:14 PDT X-Rocket-MIMEInfo: 002.001, SW0gd29ya2luZyBvbiBhIHNpbXBsZSBwcm9qZWN0IHRoYXQgc2hhcmVzIGEgbWVtb3J5IHNlZ21lbnQgYmV0d2VlbiBhIHVzZXIgcHJvY2Vzc2FuZCBhIGtlcm5lbCBtb2R1bGUuIEknbSBoYXZpbmcgc29tZSBwcm9ibGVtcyB3aXRoIHNobV9tYXAgYW5kIHRoZXJlIGRvZXNuJ3Qgc2VlbSB0b8KgYmUgbXVjaCBpbmZvIG9uIGl0Lg0KSW0gbm90IHN1cmUgd2hhdCBoYXBwZW5lZCB0byB0aGUgbWVtb3J5IHdoZW4gdGhlIHVzZXIgcHJvY2VzcyB0aGF0IGNyZWF0ZXMgaXTCoHRlcm1pbmF0ZXMuIMKgSSBoYXZlIHMBMAEBAQE- X-Mailer: YahooMailClassic/15.1.7 YahooMailWebService/0.8.140.532 Message-ID: <1365692294.23098.YahooMailClassic@web125801.mail.ne1.yahoo.com> Date: Thu, 11 Apr 2013 07:58:14 -0700 (PDT) From: Laurie Jennings Subject: shm_map questions To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 14:58:22 -0000 Im working on a simple project that shares a memory segment between a user = processand a kernel module. I'm having some problems with shm_map and there= doesn't seem to=A0be much info on it. Im not sure what happened to the memory when the user process that creates = it=A0terminates. =A0I have some questions. 1) Does the kernel mapping keep the segment from being garbage collected wh= en the=A0use process that creates it terminated? I've experienced shm_unmap= () panic when tryingto unmap a segment scenario: =A0 User process Maps SegmentKernel maps it =A0with shm_map()User Process Termi= natesKernel tries to shm_unmap() and it panics. 2) Is there a way for the kernel process to know when the user process has = goneaway? A ref count? 3) Does a SHM_ANON segment persist as long as the kernel has it mapped, or = doesit get garbage collected when the creating user process terminates? 4) When using a named segment, can the kernel "reuse" a mapping for a new u= serprocess? Example: User process creates shm segment with path /fooKernel Maps shm segment with= shm_map()User process terminates.User process runs again, opening segment = /foo Does the kernel need to re-map, or is the original mapping valid? Thanks!Laurie From owner-freebsd-net@FreeBSD.ORG Thu Apr 11 19:00:39 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A9854D0A for ; Thu, 11 Apr 2013 19:00:39 +0000 (UTC) (envelope-from mattmiller1@gmail.com) Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) by mx1.freebsd.org (Postfix) with ESMTP id 72FAB1361 for ; Thu, 11 Apr 2013 19:00:39 +0000 (UTC) Received: by mail-qa0-f46.google.com with SMTP id j8so467759qah.5 for ; Thu, 11 Apr 2013 12:00:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:from:date:x-google-sender-auth :message-id:subject:to:content-type; bh=Ml3nZa9X4THOOGWN2CHzDSh0+U0pfve3aF1KpLOUeJY=; b=d7k4sdp0vUzTiv5Jbq3gKCVNWH90V1KMi6sJ/EWCIlljEclol9/wV4EJkYB/d3kOb7 e3OdkHOG5WCgjyDDTTWhGO59wIeV/+uu3q2A6jdutclgLBMPboKSNdftF/In+labp+DR 5dGYFinpJD+CsSsuDwAF505WjUj9ZiirAq2IFKrZAugCtQhDF1GTAg41sz4xQjqQux24 cCfNOi7MNpktHgKpAtEmZ2a6YqVLCGRALPStTsKr2HBHO6u//nlfvbwrJu/aOHL4JYlc MaJaoO6xgrz3AolLH828utUKsovSgXUouFJasfwUe7CqWYF/L/pY9Zb0XTXW2fJvYLff TY7w== X-Received: by 10.49.106.40 with SMTP id gr8mr8080767qeb.42.1365706833457; Thu, 11 Apr 2013 12:00:33 -0700 (PDT) MIME-Version: 1.0 Sender: mattmiller1@gmail.com Received: by 10.49.12.242 with HTTP; Thu, 11 Apr 2013 11:59:52 -0700 (PDT) From: Matt Miller Date: Thu, 11 Apr 2013 14:59:52 -0400 X-Google-Sender-Auth: aIVOnBjqgaW3W__v3ZLa6iIPmtg Message-ID: Subject: RFC 3042 Implementation To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 19:00:39 -0000 In some of our tests, we noticed some duplicate pure ACKs (not window updates), most of which the duplicates were coming from this tcp_output() call in tcp_do_segment() (line 2534): 2508 } else if (V_tcp_do_rfc3042) { 2509 cc_ack_received(tp, th, CC_DUPACK); 2510 u_long oldcwnd = tp->snd_cwnd; 2511 tcp_seq oldsndmax = tp->snd_max; 2512 u_int sent; 2513 2514 KASSERT(tp->t_dupacks == 1 || 2515 tp->t_dupacks == 2, 2516 ("%s: dupacks not 1 or 2", 2517 __func__)); 2518 if (tp->t_dupacks == 1) 2519 tp->snd_limited = 0; 2520 tp->snd_cwnd = 2521 (tp->snd_nxt - tp->snd_una) + 2522 (tp->t_dupacks - tp->snd_limited) * 2523 tp->t_maxseg; 2524 if ((thflags & TH_FIN) && 2525 (TCPS_HAVERCVDFIN(tp->t_state) == 0)) { 2526 /* 2527 * If its a fin we need to process 2528 * it to avoid a race where both 2529 * sides enter FIN-WAIT and send FIN|ACK 2530 * at the same time. 2531 */ 2532 break; 2533 } 2534 (void) tcp_output(tp); I added some instrumentation here to count how many time the following is zero prior to calling tcp_output(): so->so_snd.sb_cc - ((tp->snd_nxt - tp->snd_una) And, in our tests, it was like 97% of the time. It looks like the intent of the RFC is to only send one or two unsent data segments here, not pure ACKs. And this subsequent standard seems to clarify that new data should be available for transmission: http://tools.ietf.org/html/rfc5681 On the first and second duplicate ACKs received at a sender, a TCP SHOULD send a segment of previously unsent data per [RFC3042] provided that the receiver's advertised window allows, the total FlightSize would remain less than or equal to cwnd plus 2*SMSS, and that new data is available for transmission. So, this is a detailed way of asking: do we need a check here to make sure there is new data to send prior to calling tcp_output()? Thanks, Matt