Received-SPF: pass (google.com: domain of linux-kernel+bounces-149094-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Message-ID: <e33d0b65-fc0b-49ab-ba48-7a13327d88aa@talpey.com>
Date: Wed, 17 Apr 2024 14:59:50 -0400
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] cifs: Fix reacquisition of volume cookie on still-live
 connection
To: David Howells <dhowells@redhat.com>, Paulo Alcantara <pc@manguebit.com>
Cc: Steve French <sfrench@samba.org>, Shyam Prasad N <sprasad@microsoft.com>,
 linux-cifs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
 linux-kernel@vger.kernel.org
References: <1a94a15e6863d3844f0bcb58b7b1e17a@manguebit.com>
 <14e66691a65e3d05d3d8d50e74dfb366@manguebit.com>
 <3756406.1712244064@warthog.procyon.org.uk>
 <2713340.1713286722@warthog.procyon.org.uk>
 <277920.1713364693@warthog.procyon.org.uk>
Content-Language: en-US
From: Tom Talpey <tom@talpey.com>
In-Reply-To: <277920.1713364693@warthog.procyon.org.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?b2tmR3NrRUJyZ09XR0lwcXpST0pERGU0ZHNZK1VWcnpkNzVoaGdqV0IyNXBq?=
 =?utf-8?B?cXVrTHYvQmdVWWNUNEZoV2Jick95UlZJZDNZaFFkSitWc1VHRjBnVFpBWkt6?=
 =?utf-8?B?d0hOaFJmNC9Eemx6eGgzT1pkUWJiSmIwOG5XUzMwaGpFWFFkUTdEVEF2aktJ?=
 =?utf-8?B?cXdWaWFBTUZObTROWnFvTmZ5UUwwZmxVTWZpYXV2SmhKakE5TitONDVWTEV1?=
 =?utf-8?B?aVkxM3puMFRqdmVWU2d1NmlwWU84Si92UVFEcDByYkNJM1dvMW9uSWltSEVj?=
 =?utf-8?B?VDEyMzc1T21GbFF3eFJVSjJ3OHlrenZmOUFGa2NyS29xaDY5TDZXQTVVbHU0?=
 =?utf-8?B?bFh3TGw3NUJnUzlVb0NpTFhOT29hQkY4VzNnMjVnbFZxQTN4YW82ZTBtcW1n?=
 =?utf-8?B?YkhSSjNIaDhNZm5uN3I0TEh5TjJHVVVONk8yWlV3N3B0NlFkSEs0Ull2WVhq?=
 =?utf-8?B?bCs2aWpTM21aNThZVTFPbEVSWXJQUjVuWlBpVjdCWjI4RzJ0bFpIWjNaN2lU?=
 =?utf-8?B?dGMwMGRrRGlCQXdvOUpNNGxoczZGa29KeG9LUkxKRWdnVFVDWERkNVBic1lK?=
 =?utf-8?B?dm54QWNLQ09MeXNnWldvNzRIeVNmaDY0WlhuNkkrSkZFT0hML3FYVUJaSk0w?=
 =?utf-8?B?bjlGVkxqTDFleWhRYzFPUGhFNFhEL3pCYWdqaHhkL0xMRHpqRDFaa3hkQ1Zr?=
 =?utf-8?B?RG9TdUxzbnJvL2lITUNLeEdjcWtSZ2pkQVlVNnNlclBUL1JkT0MrSlNpdEVW?=
 =?utf-8?B?Y2ZFcnNGVm56TDRsSFFrWGpuUDFkRVp1Y3M0ZGpiNWlPeHJBdUhrNlBuTGRj?=
 =?utf-8?B?clZhYjRxVkczNnc4QWh4YW5OZGVVZXE2WWRrZFhaVnJaWk9oZXRTc3ZMNXZR?=
 =?utf-8?B?eVFOY2xJek1nanBuQXYvby9kemxMckFaSEZXVzdtZkFXTW92ZjAvSXkwSm04?=
 =?utf-8?B?UEI2NWsyWjc0YXkwVVltUk9ueEs3V1dkUytkQzNpcXI3cHczWHRNZTY1Qmtq?=
 =?utf-8?B?OEJKWTNUZHRXbDVvbVFsUHp6ck9semlHQThhVnlDYis5ZTRQemRjUlRHaVlJ?=
 =?utf-8?B?RmU4U0hpenNjbkpWekNXZnFpVUE3dFZSaXVUTVdiV3hPWXRaQkY4RGZCWjNT?=
 =?utf-8?B?c29pdVExdUx4WDRvQ0Fmc1ZLSWQzNU0zVmIrOE4zUTVvcmE3YStiYk1mTGhr?=
 =?utf-8?B?U0JLbERVRXVxejV4TGFtazlDQW0wQkZXRnJ4VHo2RERRUmJza09rOTNBVmtJ?=
 =?utf-8?B?bnNld29oL1FDOXZ4VDIrMzYwYnAvOGpoaW1SNW95YjVpMmNGaGJJTHp3WGFv?=
 =?utf-8?B?RytKK0xOcGdXNlE4VUhXMktvcVlNeG9PUjk0UEJ4bUFUVWkrdDRBYmVaM1NH?=
 =?utf-8?B?STU3c0Evb3RISVN2a0J3eldmWEZkaWZENkZXQjVCa3NlRVJHQjlKRlBRVlFx?=
 =?utf-8?B?STZHV2hBRDd0T0tjWkR0dHY4ZVVNTXozbFRMQmZNRjJMRFJNUzJrM2JvQVJ2?=
 =?utf-8?B?RDc1azZkNmorU1NyQWNmK0RoNWFaaW0vTnhNamM4THFrc0svVGE4Yk1ROCtY?=
 =?utf-8?B?Mi9QRFhRMG1tMkpqbDFWTlF6VEtGN1BETHdFOGtNR3pldzdLMjU3dFNaRFhY?=
 =?utf-8?B?SG1kVFhEWWxYU3NzWHQwWXBHM3pUc3BxNFM5azg0ZHlZZHpOQ211V1VBbXBQ?=
 =?utf-8?B?TnY0anAveEhJVm12bXdoa3RxUzU0Zmw5KzcyREtzdG1yR3p4T3lNM2J3MkJ6?=
 =?utf-8?B?cXhmYXV3ekV0QWVZWjdnZzJSR2xtTDkyVUkrMk95TUdsL29BWHZRbGZ2M3Ay?=
 =?utf-8?B?ZFlzd1ZRdCtZV2N3L0VOa3hLZUQxNy9na2docjhRQTlOU29qOVlxU2M4NHkv?=
 =?utf-8?B?YzBOT2R1MkZrRUcxRjJKdnhkQXZKNlBVL1V0blBYVmZxeDcwbEFsZHJWZnY2?=
 =?utf-8?B?SGFvZm5ZbzRUYXpvL2RhQmU1ckl2YnZDdWhISG5nRjN4d2Z2d0lKNmtsL28r?=
 =?utf-8?B?cVhQMlVRM3N3OGppSERvNDZoajhGcVhtZG04STNkZUJmNjNZbnBRdis5UEp0?=
 =?utf-8?B?ZkpNUzNKUjZVUWExdjVnOFV6azhvTWEzdU1TWDFPK1huWkthejZQbGNZb05Q?=
 =?utf-8?Q?0JuacblR4bqk2RBp3C5uYDAgs?=
X-OriginatorOrg: talpey.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4c8ab250-5da6-4f93-7b28-08dc5f1090b4
X-MS-Exchange-CrossTenant-AuthSource: CH0PR01MB7170.prod.exchangelabs.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Apr 2024 18:59:53.2800
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 2b2dcae7-2555-4add-bc80-48756da031d5
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: ZYPI4yhb2OplAO/E3r6sNX8IR+9OAaIewlCZjNuj83jsNOJw+MS0B8vLGwZaiBA2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW6PR01MB8368

On 4/17/2024 10:38 AM, David Howells wrote:
> Paulo Alcantara <pc@manguebit.com> wrote:
> 
>> Consider the following example where a tcon is reused from different
>> CIFS superblocks:
>>
>>    mount.cifs //srv/share /mnt/1 -o ${opts} # new super, new tcon
>>    mount.cifs //srv/share/dir /mnt/2 -o ${opts} # new super, reused tcon
>>
>> So, /mnt/1/dir/foo and /mnt/2/foo will lead to different inodes.
>>
>> The two mounts are accessing the same tcon (\\srv\share) but the new
>> superblock was created because the prefix path "\dir" didn't match in
>> cifs_match_super().  Trust me, that's a very common scenario.
> 
> Why does it need to lead to a different superblock, assuming ${opts} is the

The tcon is a property of the SMB3 session, it's not shared nor is
it necessarily created at mount time.

Tom.

> same in both cases?  Can we not do as NFS does and share the superblock,
> walking during the mount process through the directory prefix to the root
> object?
> 
> In other words, why does:
> 
>      mount.cifs //srv/share /mnt/1 -o ${opts}
>      mount.cifs //srv/share/dir /mnt/2 -o ${opts}
> 
> give you a different result to:
> 
>      mount.cifs //srv/share /mnt/1 -o ${opts}
>      mount --bind /mnt/1/dir /mnt/2
> 
> David
> 
> 
>