From owner-freebsd-arch@freebsd.org Wed Jun 27 06:53:26 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A327B100A521; Wed, 27 Jun 2018 06:53:26 +0000 (UTC) (envelope-from pratiy0100@gmail.com) Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com [209.85.208.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 276C197878; Wed, 27 Jun 2018 06:53:26 +0000 (UTC) (envelope-from pratiy0100@gmail.com) Received: by mail-ed1-f46.google.com with SMTP id l23-v6so2411630edq.0; Tue, 26 Jun 2018 23:53:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=/dYAofooBNKaAYt8uPkt8XXQKDobjzOLNBe7CQXixn4=; b=uKFhYp6Ds1PWX+mWBvTGu0F+CVtpMerCJXWC0Sl9JlKVIeXoOjV1EL+AeUddv1f6k6 GMtfhATwZdOrD9gkNkSZI8kyZhC0Jj2z2Lq8ww9q7U3aT7nZjNXT/nhv8CvXgRRYQS2g oAuHJHe3FoFPWqMJ4euFQGKPBG16sK/AsEQjRfLyRkspS5mCms7tqAmoVVBMyEse0Vez 8M1Pljrdck23eibmFLGTOAd+lq5Nv3u6APhYCqWVeZTiSGQo+wRuMOcTW6TtuuruMe9p wQTKAMX1TN3fwJuVb4dWt4sbg4I4cUuVjjv2D0Y0zCestF/a6aWrp7pVX2P3SRCK0k7z /Hhw== X-Gm-Message-State: APt69E1NOEpn+KsgYetGeAf2Np/1t99E1lCvWpesgT0H01rraYzuifZU 5tVB4ktevdZn+T2jYYd3tjBS4PvY X-Google-Smtp-Source: AAOMgpftmax7ut9E+pOn4R/nHidfJhC6Cl60DntstbPpZkdBwLg6IRe7L/1kulFIsganrDClYBwhlQ== X-Received: by 2002:a50:8ad5:: with SMTP id k21-v6mr4476772edk.36.1530082399580; Tue, 26 Jun 2018 23:53:19 -0700 (PDT) Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com. [209.85.208.46]) by smtp.gmail.com with ESMTPSA id l37-v6sm1669154edc.49.2018.06.26.23.53.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Jun 2018 23:53:19 -0700 (PDT) Received: by mail-ed1-f46.google.com with SMTP id g12-v6so2403075edi.9; Tue, 26 Jun 2018 23:53:19 -0700 (PDT) X-Received: by 2002:a50:b16f:: with SMTP id l44-v6mr4403117edd.306.1530082399305; Tue, 26 Jun 2018 23:53:19 -0700 (PDT) MIME-Version: 1.0 From: Pratyush Yadav Date: Wed, 27 Jun 2018 12:22:42 +0530 X-Gmail-Original-Message-ID: Message-ID: Subject: Can bus_dmamap_unload() be called before the load completes? To: freebsd-hackers@freebsd.org Cc: freebsd-arch@freebsd.org, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Edward Napierala , Akshay Jaggi Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 06:53:26 -0000 Hi everyone, I am currently working on an alternate bus_dma(9) implementation for use with the Xen drivers [0]. I have a question regarding how the bus_dma(9) interface is expected to be used: If the load is deferred because of a shortage of resources, is it "legal" to call unload before the load completes? In my implementation, if unload is called while the load is waiting for resources, it would result in a segmentation fault and leak memory. Do I need to handle that possibility, or is it ok to assume that unload won't be called before the load completes? Regards, Pratyush Yadav [0] https://wiki.freebsd.org/SummerOfCode2018Projects/ImportXenbus_dmaFromOpenBSD