<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/fs/smb/client, branch v6.5</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>smb: client: fix null auth</title>
<updated>2023-08-16T05:26:07+00:00</updated>
<author>
<name>Scott Mayhew</name>
<email>smayhew@redhat.com</email>
</author>
<published>2023-08-16T05:23:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=270d73e6507f9c7fff43844d74f86365df000b36'/>
<id>270d73e6507f9c7fff43844d74f86365df000b36</id>
<content type='text'>
Commit abdb1742a312 removed code that clears ctx-&gt;username when sec=none, so attempting
to mount with '-o sec=none' now fails with -EACCES.  Fix it by adding that logic to the
parsing of the 'sec' option, as well as checking if the mount is using null auth before
setting the username when parsing the 'user' option.

Fixes: abdb1742a312 ("cifs: get rid of mount options string parsing")
Cc: stable@vger.kernel.org
Signed-off-by: Scott Mayhew &lt;smayhew@redhat.com&gt;
Reviewed-by: Paulo Alcantara (SUSE) &lt;pc@manguebit.com&gt;
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Commit abdb1742a312 removed code that clears ctx-&gt;username when sec=none, so attempting
to mount with '-o sec=none' now fails with -EACCES.  Fix it by adding that logic to the
parsing of the 'sec' option, as well as checking if the mount is using null auth before
setting the username when parsing the 'user' option.

Fixes: abdb1742a312 ("cifs: get rid of mount options string parsing")
Cc: stable@vger.kernel.org
Signed-off-by: Scott Mayhew &lt;smayhew@redhat.com&gt;
Reviewed-by: Paulo Alcantara (SUSE) &lt;pc@manguebit.com&gt;
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>smb3: display network namespace in debug information</title>
<updated>2023-08-14T13:41:29+00:00</updated>
<author>
<name>Steve French</name>
<email>stfrench@microsoft.com</email>
</author>
<published>2023-08-11T02:41:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=7b38f6ddc97bf572c3422d3175e8678dd95502fa'/>
<id>7b38f6ddc97bf572c3422d3175e8678dd95502fa</id>
<content type='text'>
We recently had problems where a network namespace was deleted
causing hard to debug reconnect problems.  To help deal with
configuration issues like this it is useful to dump the network
namespace to better debug what happened.

So add this to information displayed in /proc/fs/cifs/DebugData for
the server (and channels if mounted with multichannel). For example:

   Local Users To Server: 1 SecMode: 0x1 Req On Wire: 0 Net namespace: 4026531840

This can be easily compared with what is displayed for the
processes on the system. For example /proc/1/ns/net in this case
showed the same thing (see below), and we can see that the namespace
is still valid in this example.

   'net:[4026531840]'

Cc: stable@vger.kernel.org
Acked-by: Paulo Alcantara (SUSE) &lt;pc@manguebit.com&gt;
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We recently had problems where a network namespace was deleted
causing hard to debug reconnect problems.  To help deal with
configuration issues like this it is useful to dump the network
namespace to better debug what happened.

So add this to information displayed in /proc/fs/cifs/DebugData for
the server (and channels if mounted with multichannel). For example:

   Local Users To Server: 1 SecMode: 0x1 Req On Wire: 0 Net namespace: 4026531840

This can be easily compared with what is displayed for the
processes on the system. For example /proc/1/ns/net in this case
showed the same thing (see below), and we can see that the namespace
is still valid in this example.

   'net:[4026531840]'

Cc: stable@vger.kernel.org
Acked-by: Paulo Alcantara (SUSE) &lt;pc@manguebit.com&gt;
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cifs: Release folio lock on fscache read hit.</title>
<updated>2023-08-14T13:39:12+00:00</updated>
<author>
<name>Russell Harmon via samba-technical</name>
<email>samba-technical@lists.samba.org</email>
</author>
<published>2023-08-10T07:19:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=69513dd669e243928f7450893190915a88f84a2b'/>
<id>69513dd669e243928f7450893190915a88f84a2b</id>
<content type='text'>
Under the current code, when cifs_readpage_worker is called, the call
contract is that the callee should unlock the page. This is documented
in the read_folio section of Documentation/filesystems/vfs.rst as:

&gt; The filesystem should unlock the folio once the read has completed,
&gt; whether it was successful or not.

Without this change, when fscache is in use and cache hit occurs during
a read, the page lock is leaked, producing the following stack on
subsequent reads (via mmap) to the page:

$ cat /proc/3890/task/12864/stack
[&lt;0&gt;] folio_wait_bit_common+0x124/0x350
[&lt;0&gt;] filemap_read_folio+0xad/0xf0
[&lt;0&gt;] filemap_fault+0x8b1/0xab0
[&lt;0&gt;] __do_fault+0x39/0x150
[&lt;0&gt;] do_fault+0x25c/0x3e0
[&lt;0&gt;] __handle_mm_fault+0x6ca/0xc70
[&lt;0&gt;] handle_mm_fault+0xe9/0x350
[&lt;0&gt;] do_user_addr_fault+0x225/0x6c0
[&lt;0&gt;] exc_page_fault+0x84/0x1b0
[&lt;0&gt;] asm_exc_page_fault+0x27/0x30

This requires a reboot to resolve; it is a deadlock.

Note however that the call to cifs_readpage_from_fscache does mark the
page clean, but does not free the folio lock. This happens in
__cifs_readpage_from_fscache on success. Releasing the lock at that
point however is not appropriate as cifs_readahead also calls
cifs_readpage_from_fscache and *does* unconditionally release the lock
after its return. This change therefore effectively makes
cifs_readpage_worker work like cifs_readahead.

Signed-off-by: Russell Harmon &lt;russ@har.mn&gt;
Acked-by: Paulo Alcantara (SUSE) &lt;pc@manguebit.com&gt;
Reviewed-by: David Howells &lt;dhowells@redhat.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Under the current code, when cifs_readpage_worker is called, the call
contract is that the callee should unlock the page. This is documented
in the read_folio section of Documentation/filesystems/vfs.rst as:

&gt; The filesystem should unlock the folio once the read has completed,
&gt; whether it was successful or not.

Without this change, when fscache is in use and cache hit occurs during
a read, the page lock is leaked, producing the following stack on
subsequent reads (via mmap) to the page:

$ cat /proc/3890/task/12864/stack
[&lt;0&gt;] folio_wait_bit_common+0x124/0x350
[&lt;0&gt;] filemap_read_folio+0xad/0xf0
[&lt;0&gt;] filemap_fault+0x8b1/0xab0
[&lt;0&gt;] __do_fault+0x39/0x150
[&lt;0&gt;] do_fault+0x25c/0x3e0
[&lt;0&gt;] __handle_mm_fault+0x6ca/0xc70
[&lt;0&gt;] handle_mm_fault+0xe9/0x350
[&lt;0&gt;] do_user_addr_fault+0x225/0x6c0
[&lt;0&gt;] exc_page_fault+0x84/0x1b0
[&lt;0&gt;] asm_exc_page_fault+0x27/0x30

This requires a reboot to resolve; it is a deadlock.

Note however that the call to cifs_readpage_from_fscache does mark the
page clean, but does not free the folio lock. This happens in
__cifs_readpage_from_fscache on success. Releasing the lock at that
point however is not appropriate as cifs_readahead also calls
cifs_readpage_from_fscache and *does* unconditionally release the lock
after its return. This change therefore effectively makes
cifs_readpage_worker work like cifs_readahead.

Signed-off-by: Russell Harmon &lt;russ@har.mn&gt;
Acked-by: Paulo Alcantara (SUSE) &lt;pc@manguebit.com&gt;
Reviewed-by: David Howells &lt;dhowells@redhat.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cifs: fix potential oops in cifs_oplock_break</title>
<updated>2023-08-11T02:05:45+00:00</updated>
<author>
<name>Steve French</name>
<email>stfrench@microsoft.com</email>
</author>
<published>2023-08-10T20:34:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=e8f5f849ffce24490eb9449e98312b66c0dba76f'/>
<id>e8f5f849ffce24490eb9449e98312b66c0dba76f</id>
<content type='text'>
With deferred close we can have closes that race with lease breaks,
and so with the current checks for whether to send the lease response,
oplock_response(), this can mean that an unmount (kill_sb) can occur
just before we were checking if the tcon-&gt;ses is valid.  See below:

[Fri Aug  4 04:12:50 2023] RIP: 0010:cifs_oplock_break+0x1f7/0x5b0 [cifs]
[Fri Aug  4 04:12:50 2023] Code: 7d a8 48 8b 7d c0 c0 e9 02 48 89 45 b8 41 89 cf e8 3e f5 ff ff 4c 89 f7 41 83 e7 01 e8 82 b3 03 f2 49 8b 45 50 48 85 c0 74 5e &lt;48&gt; 83 78 60 00 74 57 45 84 ff 75 52 48 8b 43 98 48 83 eb 68 48 39
[Fri Aug  4 04:12:50 2023] RSP: 0018:ffffb30607ddbdf8 EFLAGS: 00010206
[Fri Aug  4 04:12:50 2023] RAX: 632d223d32612022 RBX: ffff97136944b1e0 RCX: 0000000080100009
[Fri Aug  4 04:12:50 2023] RDX: 0000000000000001 RSI: 0000000080100009 RDI: ffff97136944b188
[Fri Aug  4 04:12:50 2023] RBP: ffffb30607ddbe58 R08: 0000000000000001 R09: ffffffffc08e0900
[Fri Aug  4 04:12:50 2023] R10: 0000000000000001 R11: 000000000000000f R12: ffff97136944b138
[Fri Aug  4 04:12:50 2023] R13: ffff97149147c000 R14: ffff97136944b188 R15: 0000000000000000
[Fri Aug  4 04:12:50 2023] FS:  0000000000000000(0000) GS:ffff9714f7c00000(0000) knlGS:0000000000000000
[Fri Aug  4 04:12:50 2023] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[Fri Aug  4 04:12:50 2023] CR2: 00007fd8de9c7590 CR3: 000000011228e000 CR4: 0000000000350ef0
[Fri Aug  4 04:12:50 2023] Call Trace:
[Fri Aug  4 04:12:50 2023]  &lt;TASK&gt;
[Fri Aug  4 04:12:50 2023]  process_one_work+0x225/0x3d0
[Fri Aug  4 04:12:50 2023]  worker_thread+0x4d/0x3e0
[Fri Aug  4 04:12:50 2023]  ? process_one_work+0x3d0/0x3d0
[Fri Aug  4 04:12:50 2023]  kthread+0x12a/0x150
[Fri Aug  4 04:12:50 2023]  ? set_kthread_struct+0x50/0x50
[Fri Aug  4 04:12:50 2023]  ret_from_fork+0x22/0x30
[Fri Aug  4 04:12:50 2023]  &lt;/TASK&gt;

To fix this change the ordering of the checks before sending the oplock_response
to first check if the openFileList is empty.

Fixes: da787d5b7498 ("SMB3: Do not send lease break acknowledgment if all file handles have been closed")
Suggested-by: Bharath SM &lt;bharathsm@microsoft.com&gt;
Reviewed-by: Bharath SM &lt;bharathsm@microsoft.com&gt;
Reviewed-by: Shyam Prasad N &lt;sprasad@microsoft.com&gt;
Signed-off-by: Paulo Alcantara (SUSE) &lt;pc@manguebit.com&gt;
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
With deferred close we can have closes that race with lease breaks,
and so with the current checks for whether to send the lease response,
oplock_response(), this can mean that an unmount (kill_sb) can occur
just before we were checking if the tcon-&gt;ses is valid.  See below:

[Fri Aug  4 04:12:50 2023] RIP: 0010:cifs_oplock_break+0x1f7/0x5b0 [cifs]
[Fri Aug  4 04:12:50 2023] Code: 7d a8 48 8b 7d c0 c0 e9 02 48 89 45 b8 41 89 cf e8 3e f5 ff ff 4c 89 f7 41 83 e7 01 e8 82 b3 03 f2 49 8b 45 50 48 85 c0 74 5e &lt;48&gt; 83 78 60 00 74 57 45 84 ff 75 52 48 8b 43 98 48 83 eb 68 48 39
[Fri Aug  4 04:12:50 2023] RSP: 0018:ffffb30607ddbdf8 EFLAGS: 00010206
[Fri Aug  4 04:12:50 2023] RAX: 632d223d32612022 RBX: ffff97136944b1e0 RCX: 0000000080100009
[Fri Aug  4 04:12:50 2023] RDX: 0000000000000001 RSI: 0000000080100009 RDI: ffff97136944b188
[Fri Aug  4 04:12:50 2023] RBP: ffffb30607ddbe58 R08: 0000000000000001 R09: ffffffffc08e0900
[Fri Aug  4 04:12:50 2023] R10: 0000000000000001 R11: 000000000000000f R12: ffff97136944b138
[Fri Aug  4 04:12:50 2023] R13: ffff97149147c000 R14: ffff97136944b188 R15: 0000000000000000
[Fri Aug  4 04:12:50 2023] FS:  0000000000000000(0000) GS:ffff9714f7c00000(0000) knlGS:0000000000000000
[Fri Aug  4 04:12:50 2023] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[Fri Aug  4 04:12:50 2023] CR2: 00007fd8de9c7590 CR3: 000000011228e000 CR4: 0000000000350ef0
[Fri Aug  4 04:12:50 2023] Call Trace:
[Fri Aug  4 04:12:50 2023]  &lt;TASK&gt;
[Fri Aug  4 04:12:50 2023]  process_one_work+0x225/0x3d0
[Fri Aug  4 04:12:50 2023]  worker_thread+0x4d/0x3e0
[Fri Aug  4 04:12:50 2023]  ? process_one_work+0x3d0/0x3d0
[Fri Aug  4 04:12:50 2023]  kthread+0x12a/0x150
[Fri Aug  4 04:12:50 2023]  ? set_kthread_struct+0x50/0x50
[Fri Aug  4 04:12:50 2023]  ret_from_fork+0x22/0x30
[Fri Aug  4 04:12:50 2023]  &lt;/TASK&gt;

To fix this change the ordering of the checks before sending the oplock_response
to first check if the openFileList is empty.

Fixes: da787d5b7498 ("SMB3: Do not send lease break acknowledgment if all file handles have been closed")
Suggested-by: Bharath SM &lt;bharathsm@microsoft.com&gt;
Reviewed-by: Bharath SM &lt;bharathsm@microsoft.com&gt;
Reviewed-by: Shyam Prasad N &lt;sprasad@microsoft.com&gt;
Signed-off-by: Paulo Alcantara (SUSE) &lt;pc@manguebit.com&gt;
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>smb: client: fix dfs link mount against w2k8</title>
<updated>2023-08-02T18:36:12+00:00</updated>
<author>
<name>Paulo Alcantara</name>
<email>pc@manguebit.com</email>
</author>
<published>2023-08-02T16:43:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=11260c3d608b59231f4c228147a795ab21a10b33'/>
<id>11260c3d608b59231f4c228147a795ab21a10b33</id>
<content type='text'>
Customer reported that they couldn't mount their DFS link that was
seen by the client as a DFS interlink -- special form of DFS link
where its single target may point to a different DFS namespace -- and
it turned out that it was just a regular DFS link where its referral
header flags missed the StorageServers bit thus making the client
think it couldn't tree connect to target directly without requiring
further referrals.

When the DFS link referral header flags misses the StoraServers bit
and its target doesn't respond to any referrals, then tree connect to
it.

Fixes: a1c0d00572fc ("cifs: share dfs connections and supers")
Cc: stable@vger.kernel.org
Signed-off-by: Paulo Alcantara (SUSE) &lt;pc@manguebit.com&gt;
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Customer reported that they couldn't mount their DFS link that was
seen by the client as a DFS interlink -- special form of DFS link
where its single target may point to a different DFS namespace -- and
it turned out that it was just a regular DFS link where its referral
header flags missed the StorageServers bit thus making the client
think it couldn't tree connect to target directly without requiring
further referrals.

When the DFS link referral header flags misses the StoraServers bit
and its target doesn't respond to any referrals, then tree connect to
it.

Fixes: a1c0d00572fc ("cifs: share dfs connections and supers")
Cc: stable@vger.kernel.org
Signed-off-by: Paulo Alcantara (SUSE) &lt;pc@manguebit.com&gt;
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cifs: add missing return value check for cifs_sb_tlink</title>
<updated>2023-07-26T20:41:27+00:00</updated>
<author>
<name>Shyam Prasad N</name>
<email>sprasad@microsoft.com</email>
</author>
<published>2023-07-26T17:02:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=a171eb5cac427fa8d084eaf5e47fbe4c0f1e279f'/>
<id>a171eb5cac427fa8d084eaf5e47fbe4c0f1e279f</id>
<content type='text'>
Whenever a tlink is obtained by cifs_sb_tlink, we need
to check that the tlink returned is not an error.
It was missing with the last change here.

Fixes: b3edef6b9cd0 ("cifs: allow dumping keys for directories too")
Reported-by: Dan Carpenter &lt;dan.carpenter@linaro.org&gt;
Signed-off-by: Shyam Prasad N &lt;sprasad@microsoft.com&gt;
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Whenever a tlink is obtained by cifs_sb_tlink, we need
to check that the tlink returned is not an error.
It was missing with the last change here.

Fixes: b3edef6b9cd0 ("cifs: allow dumping keys for directories too")
Reported-by: Dan Carpenter &lt;dan.carpenter@linaro.org&gt;
Signed-off-by: Shyam Prasad N &lt;sprasad@microsoft.com&gt;
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>smb3: do not set NTLMSSP_VERSION flag for negotiate not auth request</title>
<updated>2023-07-25T06:16:05+00:00</updated>
<author>
<name>Steve French</name>
<email>stfrench@microsoft.com</email>
</author>
<published>2023-07-25T06:05:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=19826558210b9102a7d4681c91784d137d60d71b'/>
<id>19826558210b9102a7d4681c91784d137d60d71b</id>
<content type='text'>
The NTLMSSP_NEGOTIATE_VERSION flag only needs to be sent during
the NTLMSSP NEGOTIATE (not the AUTH) request, so filter it out for
NTLMSSP AUTH requests. See MS-NLMP 2.2.1.3

This fixes a problem found by the gssntlmssp server.

Link: https://github.com/gssapi/gss-ntlmssp/issues/95
Fixes: 52d005337b2c ("smb3: send NTLMSSP version information")
Acked-by: Roy Shterman &lt;roy.shterman@gmail.com&gt;
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The NTLMSSP_NEGOTIATE_VERSION flag only needs to be sent during
the NTLMSSP NEGOTIATE (not the AUTH) request, so filter it out for
NTLMSSP AUTH requests. See MS-NLMP 2.2.1.3

This fixes a problem found by the gssntlmssp server.

Link: https://github.com/gssapi/gss-ntlmssp/issues/95
Fixes: 52d005337b2c ("smb3: send NTLMSSP version information")
Acked-by: Roy Shterman &lt;roy.shterman@gmail.com&gt;
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cifs: fix charset issue in reconnection</title>
<updated>2023-07-25T05:31:24+00:00</updated>
<author>
<name>Winston Wen</name>
<email>wentao@uniontech.com</email>
</author>
<published>2023-07-24T02:10:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=a43f95fdd39490f7b156fd126f1e90ec2d5553f1'/>
<id>a43f95fdd39490f7b156fd126f1e90ec2d5553f1</id>
<content type='text'>
We need to specify charset, like "iocharset=utf-8", in mount options for
Chinese path if the nls_default don't support it, such as iso8859-1, the
default value for CONFIG_NLS_DEFAULT.

But now in reconnection the nls_default is used, instead of the one we
specified and used in mount, and this can lead to mount failure.

Signed-off-by: Winston Wen &lt;wentao@uniontech.com&gt;
Reviewed-by: Paulo Alcantara &lt;pc@manguebit.com&gt;
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We need to specify charset, like "iocharset=utf-8", in mount options for
Chinese path if the nls_default don't support it, such as iso8859-1, the
default value for CONFIG_NLS_DEFAULT.

But now in reconnection the nls_default is used, instead of the one we
specified and used in mount, and this can lead to mount failure.

Signed-off-by: Winston Wen &lt;wentao@uniontech.com&gt;
Reviewed-by: Paulo Alcantara &lt;pc@manguebit.com&gt;
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cifs: update internal module version number for cifs.ko</title>
<updated>2023-07-22T19:43:13+00:00</updated>
<author>
<name>Steve French</name>
<email>stfrench@microsoft.com</email>
</author>
<published>2023-07-20T13:30:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=ba61a03af29a5f305cb301eb83b42578474508f7'/>
<id>ba61a03af29a5f305cb301eb83b42578474508f7</id>
<content type='text'>
From 2.43 to 2.44

Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
From 2.43 to 2.44

Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cifs: allow dumping keys for directories too</title>
<updated>2023-07-22T19:42:54+00:00</updated>
<author>
<name>Shyam Prasad N</name>
<email>sprasad@microsoft.com</email>
</author>
<published>2023-06-16T10:37:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=b3edef6b9cd0b8893a5649ab1fa8bce71045d139'/>
<id>b3edef6b9cd0b8893a5649ab1fa8bce71045d139</id>
<content type='text'>
Dumping the enc/dec keys is a session wide operation.
And it should not matter if the ioctl was run on
a regular file or a directory.

Currently, we obtain the tcon pointer from the
cifs file handle. But since there's no dir open call
in cifs, this is not populated for dirs.

This change allows dumping of session keys using ioctl
even for directories. To do this, we'll now get the
tcon pointer from the superblock, and not from the file
handle.

Signed-off-by: Shyam Prasad N &lt;sprasad@microsoft.com&gt;
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Dumping the enc/dec keys is a session wide operation.
And it should not matter if the ioctl was run on
a regular file or a directory.

Currently, we obtain the tcon pointer from the
cifs file handle. But since there's no dir open call
in cifs, this is not populated for dirs.

This change allows dumping of session keys using ioctl
even for directories. To do this, we'll now get the
tcon pointer from the superblock, and not from the file
handle.

Signed-off-by: Shyam Prasad N &lt;sprasad@microsoft.com&gt;
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
