public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Takashi Sakamoto <o-takashi@sakamocchi.jp>
To: linux1394-devel@lists.sourceforge.net
Cc: dingiso.kernel@gmail.com, linux-kernel@vger.kernel.org,
	shuangpeng.kernel@gmail.com
Subject: Re: [PATCH 0/7] firewire: core: separate iso_resource paths
Date: Thu, 30 Apr 2026 22:05:30 +0900	[thread overview]
Message-ID: <20260430130530.GA209193@sakamocchi.jp> (raw)
In-Reply-To: <20260429093449.160545-1-o-takashi@sakamocchi.jp>

On Wed, Apr 29, 2026 at 06:34:41PM +0900, Takashi Sakamoto wrote:
> Hi,
> 
> (Repost since lkml was excluded.)
> 
> Dingisoul has reported that a case where the reference count of a
> client structure is leaked when handling iso_resource in cdev layer[1].
> Fixing the bug immediately s difficult due to the complexity of
> per-client resource lifetime.
> 
> As a first step toward addressing this issue, this patchset refactors the
> existing code for isochronous resource operation. Userspace application
> can allocate and deallocate isochronous resources on IEEE 1394 bus in two
> ways:
>  * FW_CDEV_IOC_[DE]ALLOCATE_ISO_RESOURCE
>  * FW_CDEV_IOC_[DE]ALLOCATE_ISO_RESOURCE_ONCE
> 
> With the former, the application delegates the maintenance of the
> allocated isochronous resources to kernel and obtain a handle for the
> client resource. With the latter, the application should maintain
> isochronous resources every time receiving bus reset event, without
> relying on a handle.
> 
> Currently, both  operations are handled by the same code, although they
> differ in terms of client resource management.
> 
> This patchset separates these two paths. As a result, it becomes clear
> that the reported issue only affects client resource allocated via the
> former method. While the actual bug fix is deferred, this refactoring
> lays the groundwork for it.
> 
> [1] https://sourceforge.net/p/linux1394/mailman/linux1394-devel/thread/20260404110936.GA282614%40sakamocchi.jp/#msg59317811
> 
> Takashi Sakamoto (7):
>   firewire: core: code refactoring for early return at client resource
>     allocation
>   firewire: core: code refactoring to queue work item for iso_resource
>   firewire: core: code refactoring for helper function to fill
>     iso_resource parameters
>   firewire: core: split functions for iso_resource once operation
>   firewire: core: code cleanup to remove old implementations for once
>     operation
>   firewire: core: append _auto suffix for non-once iso resource
>     operations
>   firewire: core: code cleanup for iso resource auto creation
> 
>  drivers/firewire/core-cdev.c | 285 +++++++++++++++++++++--------------
>  1 file changed, 176 insertions(+), 109 deletions(-)

Applied to for-next branch.


Regards

Takashi Sakamoto

      parent reply	other threads:[~2026-04-30 13:05 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-29  9:34 [PATCH 0/7] firewire: core: separate iso_resource paths Takashi Sakamoto
2026-04-29  9:34 ` [PATCH 1/7] firewire: core: code refactoring for early return at client resource allocation Takashi Sakamoto
2026-04-29  9:34 ` [PATCH 2/7] firewire: core: code refactoring to queue work item for iso_resource Takashi Sakamoto
2026-04-29  9:34 ` [PATCH 3/7] firewire: core: code refactoring for helper function to fill iso_resource parameters Takashi Sakamoto
2026-04-29  9:34 ` [PATCH 4/7] firewire: core: split functions for iso_resource once operation Takashi Sakamoto
2026-04-29  9:34 ` [PATCH 5/7] firewire: core: code cleanup to remove old implementations for " Takashi Sakamoto
2026-04-29  9:34 ` [PATCH 6/7] firewire: core: append _auto suffix for non-once iso resource operations Takashi Sakamoto
2026-04-29  9:34 ` [PATCH 7/7] firewire: core: code cleanup for iso resource auto creation Takashi Sakamoto
2026-04-30 13:05 ` Takashi Sakamoto [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260430130530.GA209193@sakamocchi.jp \
    --to=o-takashi@sakamocchi.jp \
    --cc=dingiso.kernel@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux1394-devel@lists.sourceforge.net \
    --cc=shuangpeng.kernel@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox