From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm2-f12.google.com (mail-wm2-f12.google.com [74.125.225.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 875754E4C3A for ; Wed, 30 Sep 2026 12:49:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.225.140 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790772567; cv=none; b=Z9htvnzFl2nTq2/k5IXtzn0h/44SLxUrjV9xlUUKqJgQx9PlkEh/HirvlBikaqejOHy0CiQpxv1P4vMbvaUwIAJHyGGjMUs8QeGqkqDHo+M0i3X95DmNk4oPwtF5CRlXHAqFZaQvgSNzZsGWL7OUZ2QAJ9ohJgHAcU1S5mQBu+Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790772567; c=relaxed/simple; bh=TdyzSTHL7WYOVSGbZvbctK9FEuEdU7OX2Rp7WBlcsZU=; h=Message-ID:Date:MIME-Version:Subject:From:To:Cc:References: In-Reply-To:Content-Type; b=gn0soShgO6JGlnHnjRygwQQE5UQpcT1eAcQI4qsbVgKY2YsXRnLBBoZ5A18q5p66d2Hyj5r/RDYG0j9D5NPXDeYIYY7S3V1LlctptXNu8wnVKrUX9og918iFdd9GfN1K3skVTUZDHfFw4m0BzRuTKrTTXzHng8oBvjvuT0UYsLk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=E2krLUjP; arc=none smtp.client-ip=74.125.225.140 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="E2krLUjP" Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49ffde3cec6so22696675e9.3 for ; Wed, 30 Sep 2026 05:49:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790772554; x=1791377354; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to:content-type; bh=/dhWIKwIs8lapn2MMhEevzHPS2BYYvsR1AqGmdi+y+4=; b=E2krLUjPpvrjrc3xDD1ruwYeGrnztUDpB0EbXuqQ64ya+ghgwLzJB+1E5NNBi3dNmk ewgRuZ2yH28PCIEOpx8O5+lO4q6b7LiYehDLuET1lwy0FEs/jtsNRqUavw+Sm9UpWepO HFH3PDxavM68qWrzFfHptgwr0V/ux8XT8/IEzXHe/L1fwZSIFaTgSkv3seMwvR6eYmMh o4xgSUAIq1BWV8z5HbTekS6MAGp3aFxVP+7DLov7ntg9RGoIb/IwiFYaTTDU3biKzWZq yDB9TY9Rj4BnIA7cY177iiWNXZCg0b7gsuuRyq+8qlvtW9lcwTN748kT+6OZNQI2TXkU CduQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790772554; x=1791377354; h=content-transfer-encoding:content-type:in-reply-to:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=/dhWIKwIs8lapn2MMhEevzHPS2BYYvsR1AqGmdi+y+4=; b=NH8DD9mbj8pRxz8bYyTpkOHjrT0V4EdGVis7eSDve1n7M6z3Ld6Qlm8KqeYTi9yJl6 mNljDT1BgZr0aXlKJweuuFC8+FsTMyGhA5JApWIYaYC5vYDisKev97NNrYvOiXRWz8Ve ddwgmcnK29hksQs6oNSpjFqSlJXvfAByMT5FrOj2+E61gKy5uyvCI0pk+CPtFP9+qLcR /waUNAX/bBIRMeXlgtdnMWWct19XeX+h+3FVg6qj/2I2lx0WyAhXJ/Ovf/jZJuQ74FS3 lSqJF3LDXlsc0pbfIMGNZKqjM0mMcVh0dINRX2pVmm2/+FGi6FcbycjKdeqoE770n0iu Ojpg== X-Forwarded-Encrypted: i=1; AKwUvByq3uqKRUM/eiq37w+qrLcBYy3G+OnDAtmmfj7St7NZyRaCe5e6HkDAEJPNC1l83GlqOkidBQVQ3uGGU5k=@vger.kernel.org X-Gm-Message-State: AFuF++lNAgp3lQK54Zg9mYEvQ+NgSGmSwzXtrD5c27x7FWtJiuB6gTTz jwn6BDmCN/+gZrvYtsZ555aEd4IQyFSlJ7KbHqhfCelgizfMku25ney/EGhK6g== X-Gm-Gg: AYBFou0/xQ1K6D0LPBIx0lTTwYFphyYY5Kx8DU/7u7vSl72QSYk2DCdSY0sj++a6W73 OQyxjAWYABN7AWl0SE9xXR2I/geNYRo5D65B0yP5nl9FUFIVmSPF5iQ55G63OamSyrku4fktIAx skqHPXapL1/ifhd/AFD4FyR8Efjziq/BZkPbqK0Ie4ypWndBUM2Kh3ynXqhxcrnp/LRFXhd24DP kH/b010lNBKk2SSSZtBDoTKWzO7Yoqs/ifCWXZghNW2CnUJE0fC77/2yB9Fdye9HxCa0WHLTEA5 gym9Nqlbbe3TjLoWmQbK+L5+XHukimJFbG955F3La/gt1BoFCCbioVLUBNqWwgvDQssvZ4ijUsH h++mdS+7a8iP7E0bYyvKx9rsxDp1IMcv6RsQLXJOTCbtZxyF4S+m0+T7PeDojrPbhLwUw2e/1GC siVChU9CXuruE3Zegm2EgWWnq0UKWjVfFyaf2mVMgVj1Qx9SBHzSI04s528lrXkstM1GCLn4mhU ajQTgJGbleVR7zFZIKxeb/ZwdmkfIlpme9N8OFyWWJa+52Nu9diHjeEnr+gIFUcoYvVNrIBtqyj 8Ue6pfY9Y7ce1rKjFQDGt/L7yO7oQmI/7u0N X-Received: by 2002:a05:600d:864b:10b0:4a0:2dd:7573 with SMTP id 5b1f17b1804b1-4a01b12b666mr16604625e9.33.1790772554145; Wed, 30 Sep 2026 05:49:14 -0700 (PDT) Received: from [10.54.182.141] (82-132-212-25.dab.02.net. [82.132.212.25]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4a01cb8abc1sm3766935e9.0.2026.09.30.05.48.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 30 Sep 2026 05:48:57 -0700 (PDT) Message-ID: Date: Wed, 30 Sep 2026 13:48:49 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 01/13] dma-buf: introduce initial file I/O infrastructure From: Pavel Begunkov To: Matthew Brost Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, linux-nvme@lists.infradead.org, linux-fsdevel@vger.kernel.org, io-uring@vger.kernel.org, Christoph Hellwig , Sumit Semwal , =?UTF-8?Q?Christian_K=C3=B6nig?= , Keith Busch , Sagi Grimberg , Alexander Viro , Christian Brauner , Jan Kara , Andrew Morton , Jens Axboe , Nitesh Shetty , Kanchan Joshi , Anuj Gupta , Tushar Gohad , William Power , Phil Cayton , Alasdair Kergon , Mike Snitzer , Mikulas Patocka , Benjamin Marzinski , dm-devel@lists.linux.dev References: <5490ee42c4452fd4198b245ead20fcf7438c066e.1789997898.git.asml.silence@gmail.com> <447c04dd-6bfa-4c45-99e7-37d25a7ab539@gmail.com> Content-Language: en-US In-Reply-To: <447c04dd-6bfa-4c45-99e7-37d25a7ab539@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 9/30/26 11:08, Pavel Begunkov wrote: > On 9/30/26 04:00, Matthew Brost wrote: >> On Mon, Sep 21, 2026 at 02:38:45PM +0100, Pavel Begunkov wrote: > ...>> +struct dma_buf_io_map *dma_buf_io_create_map(struct dma_buf_io_ctx *ctx) >>> +{ >>> +    struct dma_buf *dmabuf = ctx->dmabuf; >>> +    struct dma_buf_io_map *map; >>> +    long ret; >>> + >>> +    guard(mutex)(&ctx->map_create_mutex); >>> + >>> +    scoped_guard(mutex, &ctx->map_mutex) { >>> +        if (ctx->maps_killed) >>> +            return ERR_PTR(-ENOENT); >>> +        /* recheck under the lock in case it has already been re-created */ >>> +        map = __dma_buf_io_get_map(ctx); >>> +        if (map) >>> +            return map; >>> +    } >>> + >>> +    dma_buf_io_wait_active_maps(ctx); >>> + >>> +    ret = dma_resv_lock_interruptible(dmabuf->resv, NULL); >>> +    if (ret) >>> +        return ERR_PTR(ret); >>> + >>> +    ret = dma_resv_wait_timeout(dmabuf->resv, DMA_RESV_USAGE_KERNEL, >>> +                    true, MAX_SCHEDULE_TIMEOUT); >>> +    if (ret <= 0) { >>> +        if (!ret) >>> +            ret = -EAGAIN; >>> +        dma_resv_unlock(dmabuf->resv); >>> +        return ERR_PTR(ret); >>> +    } >>> + >>> +    map = ctx->dev_ops->map(ctx); >> >> I'm playing around this code now. >> >> I think you need the dma_resv_wait_timeout after the 'map'? >> >> If a device doesn't support p2p ->map() will typically trigger an async >> migrate to system memory and data will be moving but the map is valid - >> Xe 100% does this, I checked AMDGPU and fairly confident it has the same >> async behavior. > > There is a wait right before because I read somewhere in dma-buf > comments that I need to do that, sounds a bit odd if I need to > wait on fences before and after. I can add it, just curious how > come that other dma_buf_map_attachment() callers don't need to do > that. Or maybe they wait somewhere else? I can't find it, so maybe it was the comment below and I mixed sth up back then. I'll move it after ->map(). * Note that for non-dynamic exporters the driver must guarantee that * that the memory is available for use and cleared of any old data by * the time this function returns. Drivers which pipeline their buffer * moves internally must wait for all moves and clears to complete. * Dynamic exporters do not need to follow this rule: For non-dynamic * importers the buffer is already pinned through @pin, which has the * same requirements. Dynamic importers otoh are required to obey the * dma_resv fences. * -- Pavel Begunkov