ACK/Cmnt: [PATCH 0/2] [focal:linux, focal:linux-azure] linux-azure CIFS DFS oops

[Tim Gardner]

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.
>>
>> [Impact]
>>
>> A Microsoft customer is reporting a kernel oops when attempting a DFS connection.
>>
>> [Fix]
>>
>> 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.
> Cheers,
> 
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.

rtg

-----------
Tim Gardner
Canonical, Inc