Date: Thu, 11 Apr 2013 07:58:14 -0700 (PDT) From: Laurie Jennings <laurie_jennings_1977@yahoo.com> To: freebsd-net@freebsd.org Subject: shm_map questions Message-ID: <1365692294.23098.YahooMailClassic@web125801.mail.ne1.yahoo.com>
next in thread | raw e-mail | index | archive | help
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: <owner-freebsd-net@FreeBSD.ORG> 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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; Thu, 11 Apr 2013 19:00:39 +0000 (UTC) Received: by mail-qa0-f46.google.com with SMTP id j8so467759qah.5 for <freebsd-net@freebsd.org>; 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 <matt@matthewjmiller.net> Date: Thu, 11 Apr 2013 14:59:52 -0400 X-Google-Sender-Auth: aIVOnBjqgaW3W__v3ZLa6iIPmtg Message-ID: <CAFc6gu9ynWjeF0J+v_vYeHQNmArJdteH3AaTrHwa1bRVHYtQgg@mail.gmail.com> Subject: RFC 3042 Implementation To: FreeBSD Net <freebsd-net@freebsd.org> 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 <freebsd-net.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-net>, <mailto:freebsd-net-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>; List-Post: <mailto:freebsd-net@freebsd.org> List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>, <mailto:freebsd-net-request@freebsd.org?subject=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 <quote> 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. </quote> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1365692294.23098.YahooMailClassic>