From: Paulo Alcantara <pc@manguebit.com>
To: Tom Talpey <tom@talpey.com>,
Meetakshi Setiya <meetakshisetiyaoss@gmail.com>
Cc: sfrench@samba.org, sprasad@microsoft.com,
linux-cifs@vger.kernel.org, nspmangalore@gmail.com,
bharathsm.hsk@gmail.com, samba-technical@lists.samba.org,
Meetakshi Setiya <msetiya@microsoft.com>
Subject: Re: [PATCH 2/2] smb: client: retry compound request without reusing lease
Date: Thu, 04 Jan 2024 20:09:50 -0300 [thread overview]
Message-ID: <095d8821cbafdf3f13872f7e9d7125a0@manguebit.com> (raw)
In-Reply-To: <62eb08fb-b27f-4c95-ab29-ac838f24d70f@talpey.com>
Tom Talpey <tom@talpey.com> writes:
> On 1/3/2024 9:37 AM, Paulo Alcantara wrote:
>> A possible way to handle such case would be keeping a list of
>> pathname:lease_key pairs inside the inode, so in smb2_compound_op() you
>> could look up the lease key by using @dentry. I'm not sure if there's a
>> better way to handle it as I haven't looked into it further.
>
> A list would also allow for better handling of lease revocation.
It's also worth mentioning that we could also map the dentry directly to
lease key, so no need to store pathnames inside the inode.
> It seems to me this approach basically discards the original lease,
> putting the client's cached data at risk, no? And what happens if
> EINVAL comes back again, or the connection breaks? Is this a
> recoverable situation?
These are really good points and would need to be investigated before
coming up with an implementation.
next prev parent reply other threads:[~2024-01-04 23:10 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-29 14:35 [PATCH 1/2] smb: client: reuse file lease key in compound operations meetakshisetiyaoss
2023-12-29 14:35 ` [PATCH 2/2] smb: client: retry compound request without reusing lease meetakshisetiyaoss
2023-12-29 15:43 ` Paulo Alcantara
2024-01-03 4:35 ` Meetakshi Setiya
2024-01-03 14:37 ` Paulo Alcantara
2024-01-04 21:09 ` Tom Talpey
2024-01-04 23:09 ` Paulo Alcantara [this message]
2024-01-05 9:18 ` Shyam Prasad N
2024-01-05 9:39 ` Shyam Prasad N
2024-01-05 10:00 ` Stefan Metzmacher
2024-01-05 10:23 ` Shyam Prasad N
2024-01-05 10:38 ` Stefan Metzmacher
2024-01-05 10:58 ` Shyam Prasad N
2024-01-05 18:42 ` Steve French
2024-01-17 14:15 ` Meetakshi Setiya
2024-02-02 12:50 ` Meetakshi Setiya
2024-01-03 6:55 ` [PATCH 1/2] smb: client: reuse file lease key in compound operations kernel test robot
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=095d8821cbafdf3f13872f7e9d7125a0@manguebit.com \
--to=pc@manguebit.com \
--cc=bharathsm.hsk@gmail.com \
--cc=linux-cifs@vger.kernel.org \
--cc=meetakshisetiyaoss@gmail.com \
--cc=msetiya@microsoft.com \
--cc=nspmangalore@gmail.com \
--cc=samba-technical@lists.samba.org \
--cc=sfrench@samba.org \
--cc=sprasad@microsoft.com \
--cc=tom@talpey.com \
/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