Linux kernel -stable discussions
 help / color / mirror / Atom feed
From: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
To: Greg KH <gregkh@linuxfoundation.org>,
	Sherry Yang <sherry.yang@oracle.com>
Cc: Sasha Levin <sashal@kernel.org>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: [PATCH 5.15.y, 5.10.y] exfat: fix potential deadlock on __exfat_get_dentry_set
Date: Sun, 15 Dec 2024 03:11:16 +0530	[thread overview]
Message-ID: <4a77e8e8-ccf4-4149-9ccc-a33245df4759@oracle.com> (raw)
In-Reply-To: <2024121419-cupcake-fantasy-92dd@gregkh>

Hi Greg,

On 14/12/24 23:36, Greg KH wrote:
> On Sat, Dec 14, 2024 at 05:57:01PM +0000, Sherry Yang wrote:
>> Hi,
>>
>>> On Dec 14, 2024, at 6:26 AM, Sasha Levin <sashal@kernel.org> wrote:
>>>
>>> [ Sasha's backport helper bot ]
>>>
>>> Hi,
>>>
>>> The upstream commit SHA1 provided is correct: 89fc548767a2155231128cb98726d6d2ea1256c9
>>>
>>> WARNING: Author mismatch between patch and upstream commit:
>>> Backport author: Sherry Yang <sherry.yang@oracle.com>
>>> Commit author: Sungjong Seo <sj1557.seo@samsung.com>
>>>
>>>
>>> Status in newer kernel trees:
>>> 6.12.y | Present (exact SHA1)
>>> 6.6.y | Present (different SHA1: a7ac198f8dba)
>>> 6.1.y | Not found
>>> 5.15.y | Not found
>>
>> I didn’t backport the commit to linux-stable-6.1.y, because 6.1.y didn’t backport the culprit commit
>> a3ff29a95fde ("exfat: support dynamic allocate bh for exfat_entry_set_cache”), so not influenced.
>>
>> However, both linux-stable-5.15.y and linux-stable-5.10.y actually backported the culprit commit. So I’m trying to fix it on 5.15.y and 5.10.y.
>>
>> Let me know if you have more questions about it.
> 
> That's confusing, why doesn't 6.1.y have that commit?  Shouldn't we also
> add it there along with this one?
> 

https://lore.kernel.org/all/20230809103650.353831735@linuxfoundation.org/#t

Commit a3ff29a95fde ("exfat: support dynamic allocate bh for 
exfat_entry_set_cache”) which is present in 5.10.y and 5.15.y but not in 
6.1.y is added as a stable-dependency "Stable-dep-of: d42334578eba 
("exfat: check if filename entries exceeds max filename length") ", but 
this(d42334578eba - filename length check) is present in 6.1.y without 
commit a3ff29a95fde , so probably stable-dep-of is not accurate.

Given that now we already have a3ff29a95fde ("exfat: support dynamic 
allocate bh for exfat_entry_set_cache”) to 5.15.y and 5.10.y, I think we 
should add it and the fix to 6.1.y as well.

For 6.1.y here are the upstream commits: (Starting from 1 -- cleanly 
applies and builds fine, haven't done any exfat related testing though.)
1. a3ff29a95fde ("exfat: support dynamic allocate bh for 
exfat_entry_set_cache”)
2. commit: 89fc548767a2 ("exfat: fix potential deadlock on 
__exfat_get_dentry_set")

Let me know if you want me to send two patches instead, I can do that.

Thanks,
Harshit

> thanks,
> 
> greg k-h
> 


  reply	other threads:[~2024-12-14 21:41 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-13 23:57 [PATCH 5.15.y, 5.10.y] exfat: fix potential deadlock on __exfat_get_dentry_set Sherry Yang
2024-12-14 14:26 ` Sasha Levin
2024-12-14 17:57   ` Sherry Yang
2024-12-14 18:06     ` Greg KH
2024-12-14 21:41       ` Harshit Mogalapalli [this message]
2024-12-14 21:50         ` Greg KH

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=4a77e8e8-ccf4-4149-9ccc-a33245df4759@oracle.com \
    --to=harshit.m.mogalapalli@oracle.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=sashal@kernel.org \
    --cc=sherry.yang@oracle.com \
    --cc=stable@vger.kernel.org \
    /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