mirror of
https://github.com/torvalds/linux.git
synced 2026-10-08 03:26:02 +02:00
ksmbd: fix durable handle v2 default timeout units (60 -> 60000)
When a client's Durable Handle Request V2 sets Timeout=0 ("let the
server choose"), fp->durable_timeout was set to 60. Every other use
of this field is in milliseconds: DURABLE_HANDLE_MAX_TIMEOUT (300000)
in smb2pdu.h, the nonzero branch immediately above
(min_t(unsigned int, dh_info.timeout, DURABLE_HANDLE_MAX_TIMEOUT),
where dh_info.timeout is the wire value and already milliseconds per
spec), and the scavenger in vfs_cache.c, which adds it directly to
jiffies_to_msecs(jiffies).
60 is off by 1000x: the handle becomes scavenger-eligible 60
milliseconds after close instead of 60 seconds. A client requesting
Timeout=0 is relying entirely on the server's default to cover the
gap between a dropped connection and its reconnect -- 60ms is not
enough time for even a fast network blip to be detected and
reconnected, so any real disruption loses the race and a subsequent
DH2C reconnect fails with a durable-handle lookup miss instead of
succeeding.
Assisted-by: Claude:claude-sonnet-5
Signed-off-by: Gael Blivet <gael.blivet@gmail.com>
Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
This commit is contained in:
parent
445b2244b6
commit
c1d7bbfc5e
|
|
@ -4186,10 +4186,17 @@ int smb2_open(struct ksmbd_work *work)
|
|||
min_t(unsigned int, dh_info.timeout,
|
||||
DURABLE_HANDLE_MAX_TIMEOUT);
|
||||
else
|
||||
fp->durable_timeout = 60;
|
||||
fp->durable_timeout = 60000;
|
||||
}
|
||||
}
|
||||
|
||||
/*
|
||||
* conn->is_aapl detection above (this function's create-context
|
||||
* parsing) is skipped on the reconnect path below, since a
|
||||
* reconnect always arrives on a fresh connection -- if the client
|
||||
* cares, it sends its own AAPL context on this same CREATE, which
|
||||
* this function's normal (non-reconnect) parsing already handles.
|
||||
*/
|
||||
reconnected_fp:
|
||||
rsp->StructureSize = cpu_to_le16(89);
|
||||
opinfo = opinfo_get(fp);
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user