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
>
next prev parent 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