- 06 Feb, 2020 4 commits
-
-
Dan Carpenter authored
This frees "copy->nf_src" before and again after the goto. Fixes: ce0887ac ("NFSD add nfs4 inter ssc to nfsd4_copy") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Olga Kornievskaia <kolga@netapp.com> Signed-off-by:
J. Bruce Fields <bfields@redhat.com>
-
Trond Myklebust authored
Use the 'refcount_t' type instead of 'atomic_t' for improved refcounting safety. Signed-off-by:
Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by:
-
Trond Myklebust authored
Signed-off-by:
-
Trond Myklebust authored
perf does not know how to deal with a __builtin_bswap32() call, and complains. All other functions just store the xid etc in host endian form, so let's do that in the tracepoint for nfsd_file_acquire too. Signed-off-by:
-
- 22 Jan, 2020 16 commits
-
-
Trond Myklebust authored
When doing an unstable write, we need to ensure that we sample the write verifier before releasing the lock, and allowing a commit to the same file to proceed. Signed-off-by:
-
Trond Myklebust authored
When we have a successful commit, ensure we sample the commit verifier before releasing the lock. Signed-off-by:
-
Trond Myklebust authored
Signed-off-by:
-
Trond Myklebust authored
When we unhash the cache entry, we need to handle any pending upcalls by calling cache_fresh_unlocked(). Signed-off-by:
-
Trond Myklebust authored
Ensure that we can distinguish between synchronous CLONE and WRITE errors, and that we can assign them correctly. Signed-off-by:
-
Trond Myklebust authored
Needed in order to fix exclusion w.r.t. writes. Signed-off-by:
-
Trond Myklebust authored
We don't know if the error returned by the fsync() call is exclusive to the data written by the stable write, so play it safe. Signed-off-by:
-
Trond Myklebust authored
Strictly speaking, a stable write error needs to reflect the write + the commit of that write (and only that write). To ensure that we don't pick up the write errors from other writebacks, add a rw_semaphore to provide exclusion. Signed-off-by:
-
Trond Myklebust authored
Needed in order to fix stable writes. Signed-off-by:
-
Trond Myklebust authored
If nfsd_file_mark_find_or_create() keeps winning the race for the nfsd_file_fsnotify_group->mark_mutex against nfsd_file_mark_put() then it can soft lock up, since fsnotify_add_inode_mark() ends up always finding an existing entry. Signed-off-by:
-
Trond Myklebust authored
Don't call nfsd_file_gc() on every put of the reference in nfsd_file_put(). Instead, do it only when we're expecting the refcount to go to 1. Signed-off-by:
-
Trond Myklebust authored
Emsure we schedule the laundrette even if the struct file is carrying file errors. Signed-off-by:
-
Trond Myklebust authored
Signed-off-by:
-
Trond Myklebust authored
Ensure that if the filecache laundrette gets stuck, it only affects the knfsd instances of one container. The notifier callbacks can be called from various contexts so avoid using synchonous filesystem operations that might deadlock. Signed-off-by:
-
Trond Myklebust authored
Signed-off-by:
-
Trond Myklebust authored
If the lookup keeps finding a nfsd_file with an unhashed open file, then retry once only. Signed-off-by:
-
- 03 Jan, 2020 3 commits
-
-
zhengbin authored
Fixes coccicheck warning: fs/nfsd/nfssvc.c:394:2-14: WARNING: Assignment of 0/1 to bool variable fs/nfsd/nfssvc.c:407:2-14: WARNING: Assignment of 0/1 to bool variable fs/nfsd/nfssvc.c:422:2-14: WARNING: Assignment of 0/1 to bool variable Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
zhengbin <zhengbin13@huawei.com> Signed-off-by:
-
zhengbin authored
Fixes coccicheck warning: fs/nfsd/nfs4proc.c:235:1-18: WARNING: Assignment of 0/1 to bool variable fs/nfsd/nfs4proc.c:368:1-17: WARNING: Assignment of 0/1 to bool variable Reported-by:
-
zhengbin authored
Fixes coccicheck warning: fs/nfsd/vfs.c:1389:5-13: WARNING: Assignment of 0/1 to bool variable fs/nfsd/vfs.c:1398:5-13: WARNING: Assignment of 0/1 to bool variable fs/nfsd/vfs.c:1415:2-10: WARNING: Assignment of 0/1 to bool variable Reported-by:
-
- 20 Dec, 2019 3 commits
-
-
Arnd Bergmann authored
The function was removed a long time ago, but the declaration and a dummy implementation are still there, referencing the deprecated time_t type. Remove both. Fixes: f958a132 ("nfsd4: remove unnecessary lease-setting function") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Arnd Bergmann authored
gen_confirm() generates a unique identifier based on the current time. This overflows in year 2038, but that is harmless since it generally does not lead to duplicates, as long as the time has been initialized by a real-time clock or NTP. Using ktime_get_boottime_seconds() or ktime_get_seconds() would avoid the overflow, but it would be more likely to result in non-unique numbers. Signed-off-by:
-
Arnd Bergmann authored
A couple of time_t variables are only used to track the state of the lease time and its expiration. The code correctly uses the 'time_after()' macro to make this work on 32-bit architectures even beyond year 2038, but the get_seconds() function and the time_t type itself are deprecated as they behave inconsistently between 32-bit and 64-bit architectures and often lead to code that is not y2038 safe. As a minor issue, using get_seconds() leads to problems with concurrent settimeofday() or clock_settime() calls, in the worst case timeout never triggering after the time has been set backwards. Change nfsd to use time64_t and ktime_get_boottime_seconds() here. This is clearly excessive, as boottime by itself means we never go beyond 32 bits, but it does mean we handle this correctly and consistently without having to worry about corner cases and should be no more expensive than the previous implementation on 64-bit architectures. The max_cb_time() function gets changed in order to avoid an expensive 64-bit division operation, but as the lease time is at most one hour, there is no change in behavior. Also do the same for server-to-server copy expiration time. Signed-off-by:
-
- 19 Dec, 2019 12 commits
-
-
Arnd Bergmann authored
The nfsd4_blocked_lock->nbl_time timestamp is recorded in jiffies, but then compared to a CLOCK_REALTIME timestamp later on, which makes no sense. For consistency with the other timestamps, change this to use a time_t. This is a change in behavior, which may cause regressions, but the current code is not sensible. On a system with CONFIG_HZ=1000, the 'time_after((unsigned long)nbl->nbl_time, (unsigned long)cutoff))' check is false for roughly the first 18 days of uptime and then true for the next 49 days. Fixes: 7919d0a2 ("nfsd: add a LRU list for blocked locks") Signed-off-by:
-
Arnd Bergmann authored
The nfsd4_cb_layout_done() function takes a 'time_t' value, multiplied by NSEC_PER_SEC*2 to get a nanosecond value. This works fine on 64-bit architectures, but on 32-bit, any value over 1 second results in a signed integer overflow with unexpected results. Cast one input to a 64-bit type in order to produce the same result that we have on 64-bit architectures, regarless of the type of nfsd4_lease. Fixes: 6b9b2107 ("nfsd: give up on CB_LAYOUTRECALLs after two lease periods") Signed-off-by:
-
Arnd Bergmann authored
Change to time64_t and ktime_get_real_seconds() to make the logic work correctly on 32-bit architectures beyond 2038. Signed-off-by:
-
Arnd Bergmann authored
Guardtime handling in nfs3 differs between 32-bit and 64-bit architectures, and uses the deprecated time_t type. Change it to using time64_t, which behaves the same way on 64-bit and 32-bit architectures, treating the number as an unsigned 32-bit entity with a range of year 1970 to 2106 consistently, and avoiding the y2038 overflow. Signed-off-by:
-
Arnd Bergmann authored
The local boot time variable gets truncated to time_t at the moment, which can lead to slightly odd behavior on 32-bit architectures. Use ktime_get_real_seconds() instead of get_seconds() to always get a 64-bit result, and keep it that way wherever possible. It still gets truncated in a few places: - When assigning to cl_clientid.cl_boot, this is already documented and is only used as a unique identifier. - In clients_still_reclaiming(), the truncation is to 'unsigned long' in order to use the 'time_before() helper. Signed-off-by:
-
Arnd Bergmann authored
The values in encode_time_delta are always small and don't overflow the range of 'struct timespec', so changing it has no effect. Change it to timespec64 as a prerequisite for removing the timespec definition later. Signed-off-by:
-
Arnd Bergmann authored
The decode_time3 function behaves differently on 32-bit and 64-bit architectures: on the former, a 32-bit timestamp gets converted into an signed number and then into a timestamp between 1902 and 2038, while on the latter it is interpreted as unsigned in the range 1970-2106. Change all the remaining 'timespec' in nfsd to 'timespec64' to make the behavior the same, and use the current interpretation of the dominant 64-bit architectures. Signed-off-by:
-
Arnd Bergmann authored
The nii_time field gets truncated to 'time_t' on 32-bit architectures before printing. Remove the use of 'struct timespec' to product the correct output beyond 2038. Signed-off-by:
-
Arnd Bergmann authored
The delegation logic in nfsd uses the somewhat inefficient seconds_since_boot() function to record time intervals. Signed-off-by:
-
Aditya Pakki authored
The replay variable is set in the only caller of nfsd4_encode_replay. The assertion is unnecessary and the patch removes this check. Signed-off-by:
Aditya Pakki <pakki001@umn.edu> Signed-off-by:
-
Trond Myklebust authored
vfs_clone_file_range() can modify the metadata on the source file too, so we need to commit that to stable storage as well. Reported-by:
Dave Chinner <david@fromorbit.com> Signed-off-by:
-
zhengbin authored
Fixes coccicheck warning: fs/nfsd/nfs4state.c:3376:2-3: Unneeded semicolon Reported-by:
-
- 17 Dec, 2019 1 commit
-
-
Trond Myklebust authored
We must allow for the fact that iov_iter_write() could have returned a short write (e.g. if there was an ENOSPC issue). Fixes: d890be15 "nfsd: Add I/O trace points in the NFSv4 write path" Signed-off-by:
-
- 09 Dec, 2019 1 commit
-
-
J. Bruce Fields authored
With cross-server COPY we've introduced the possibility that the current or saved filehandle might not have fh_dentry/fh_export filled in, but we missed a place that assumed it was. I think this could be triggered by a compound like: PUTFH(foreign filehandle) GETATTR SAVEFH COPY First, check_if_stalefh_allowed sets no_verify on the first (PUTFH) op. Then op_func = nfsd4_putfh runs and leaves current_fh->fh_export NULL. need_wrongsec_check returns true, since this PUTFH has OP_IS_PUTFH_LIKE set and GETATTR does not have OP_HANDLES_WRONGSEC set. We should probably also consider tightening the checks in check_if_stalefh_allowed and double-checking that we don't assume the filehandle is verified elsewhere in the compound. But I think this fixes the immediate issue. Reported-by:
-
