ACK/Cmnt: [PATCH 0/2] [focal:linux, focal:linux-azure] linux-azure CIFS DFS oops
tim.gardner at canonical.com
Mon Jul 12 13:13:32 UTC 2021
On 7/12/21 7:03 AM, Guilherme Piccoli wrote:
> On Mon, Jul 12, 2021 at 9:20 AM Tim Gardner <tim.gardner at canonical.com> wrote:
>> BugLink: https://bugs.launchpad.net/bugs/1935833
>> Patch 1 is scaffolding that enables a clean cherry-pick of patch 2.
>> Even though this oops has only been reported against linux-azure, the mainline
>> kernel also has the CIFS DFS patches pending and should get these fixes. If applied
>> to mainline in time, then linux-azure will simply inherit.
>> A Microsoft customer is reporting a kernel oops when attempting a DFS connection.
>> a52930353eaf443489a350a135c5525a4acbbf56 cifs: handle empty list of targets in cifs_reconnect()
>> baf3f08ef4083b76ca67b143e135213a7f941879 cifs: get rid of unused parameter in reconn_setup_dfs_targets()
>> The addition of these 2 patches has been confirmed to prevent the oops.
>> [Test Case]
>> Mount a Windows DFS share
>> [Where problems could occur]
>> Mounts could continue to fail even though the kernel no longer crashes.
>> [Other Info]
>> SF: #00313885
> Thanks Tim! Patches look good to me:
> Acked-by: Guilherme G. Piccoli <gpiccoli at canonical.com>
> That said, I'm not sure "SF: #00313885" is a meaningful information to
> a public report, I'd suppress mentions to internal tooling, since
> they're not useful to any external parties.
Personally I think the Sales Force reference is useful, if for no other
reason then to note that there is a relationship between the LP report
and a SF case. Its not a secret that we use SF to deal with commercial
customers, plus there are a great many folks that _can_ access the SF
report. Of course, all of the relevant bug traffic is still conducted in
a public forum.
More information about the kernel-team