- Jan 09, 2016
-
-
NeilBrown authored
We need information about exports when crossing mountpoints during lookup or NFSv4 readdir. If we don't already have that information cached, we may have to ask (and wait for) rpc.mountd. In both cases we currently hold the i_mutex on the parent of the directory we're asking rpc.mountd about. We've seen situations where rpc.mountd performs some operation on that directory that tries to take the i_mutex again, resulting in deadlock. With some care, we may be able to avoid that in rpc.mountd. But it seems better just to avoid holding a mutex while waiting on userspace. It appears that lookup_one_len is pretty much the only operation that needs the i_mutex. So we could just drop the i_mutex elsewhere and do something like mutex_lock() lookup_one_len() mutex_unlock() In many cases though the lookup would have been cached and not required the i_mutex, so it's more efficient to create a lookup_one_len() variant that only takes the i_mutex when necessary. Signed-off-by:
NeilBrown <neilb@suse.de> Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
DengChao authored
The affs code uses "time_t" and "get_seconds()". This will cause problems on 32-bit architectures in 2038 when time_t overflows. This patch replaces them with "time64_t" and "ktime_get_real_seconds()". This patch introduces expensive 64-bit divsion in "secs_to_datestamp()", considering this function is not called so often, the cost should be acceptable. Reviewed-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
DengChao <chao.deng@linaro.org> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
Sasha Levin authored
We may sleep inside a the lock, so use a mutex rather than spinlock. Signed-off-by:
Sasha Levin <sasha.levin@oracle.com> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
Eric Dumazet authored
User can pass an arbitrary large buffer to getdents(). It is typically a 32KB buffer used by libc scandir() implementation. When scanning /proc/{pid}/fd, we can hold cpu way too long, so add a cond_resched() to be kind with other tasks. We've seen latencies of more than 50ms on real workloads. Signed-off-by:Eric Dumazet <edumazet@google.com> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
Julia Lawall authored
The logfs_block_ops structures are never modified, so declare them as const. Done with the help of Coccinelle. Signed-off-by:
Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
Stanislav Kinsburskiy authored
With packetized mode for pipes, it's not possible to set O_DIRECT on pipe file via sys_fcntl, because of unsupported sanity checks. Ability to set this flag will be used by CRIU to migrate packetized pipes. v2: Fixed typos and mode variable to check. Signed-off-by:
Stanislav Kinsburskiy <skinsbursky@virtuozzo.com> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
Abhi Das authored
During testing, I discovered that __generic_file_splice_read() returns 0 (EOF) when aops->readpage fails with AOP_TRUNCATED_PAGE on the first page of a single/multi-page splice read operation. This EOF return code causes the userspace test to (correctly) report a zero-length read error when it was expecting otherwise. The current strategy of returning a partial non-zero read when ->readpage returns AOP_TRUNCATED_PAGE works only when the failed page is not the first of the lot being processed. This patch attempts to retry lookup and call ->readpage again on pages that had previously failed with AOP_TRUNCATED_PAGE. With this patch, my tests pass and I haven't noticed any unwanted side effects. This version removes the thrice-retry loop and instead indefinitely retries lookups on AOP_TRUNCATED_PAGE errors from ->readpage. This behavior is now similar to do_generic_file_read(). Signed-off-by:
Abhi Das <adas@redhat.com> Reviewed-by:
Jan Kara <jack@suse.cz> Cc: Bob Peterson <rpeterso@redhat.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
Richard Weinberger authored
... instead of open coding it. Signed-off-by:
Richard Weinberger <richard@nod.at> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Acked-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Signed-off-by:Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
-
Jann Horn authored
This replaces all code in fs/compat_ioctl.c that translated ioctl arguments into a in-kernel structure, then performed do_ioctl under set_fs(KERNEL_DS), with code that allocates data on the user stack and can call the VFS ioctl handler under USER_DS. This is done as a hardening measure because the caller does not know what kind of ioctl handler will be invoked, only that no corresponding compat_ioctl handler exists and what the ioctl command number is. The accidental invocation of an unlocked_ioctl handler that unexpectedly calls copy_to_user could be a severe security issue. Signed-off-by:
Jann Horn <jann@thejh.net> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Signed-off-by:Al Viro <viro@zeniv.linux.org.uk>
-
Jann Horn authored
In code in fs/compat_ioctl.c that translates ioctl arguments into a in-kernel structure, then performs sys_ioctl, possibly under set_fs(KERNEL_DS), this commit changes the sys_ioctl calls to do_ioctl calls. do_ioctl is a new function that does the same thing as sys_ioctl, but doesn't look up the fd again. This change is made to avoid (potential) security issues because of ioctl handlers that accept one of the ioctl commands I2C_FUNCS, VIDEO_GET_EVENT, MTIOCPOS, MTIOCGET, TIOCGSERIAL, TIOCSSERIAL, RTC_IRQP_READ, RTC_EPOCH_READ. This can happen for multiple reasons: - The ioctl command number could be reused. - The ioctl handler might not check the full ioctl command. This is e.g. true for drm_ioctl. - The ioctl handler is very special, e.g. cuse_file_ioctl The real issue is that set_fs(KERNEL_DS) is used here, but that's fixed in a separate commit "compat_ioctl: don't call do_ioctl under set_fs(KERNEL_DS)". This change mitigates potential security issues by preventing a race that permits invocation of unlocked_ioctl handlers under KERNEL_DS through compat code even if a corresponding compat_ioctl handler exists. So far, no way has been identified to use this to damage kernel memory without having CAP_SYS_ADMIN in the init ns (with the capability, doing reads/writes at arbitrary kernel addresses should be easy through CUSE's ioctl handler with FUSE_IOCTL_UNRESTRICTED set). [AV: two missed sys_ioctl() taken care of] Signed-off-by:
Jann Horn <jann@thejh.net> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
- Jan 07, 2016
-
-
Dmitry Monakhov authored
Signed-off-by:
Dmitry Monakhov <dmonakhov@openvz.org> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
Dmitry Monakhov authored
This allow to directly print block_device name. Currently one should use bdevname() with temporal char buffer. This is very ineffective because bloat stack usage for deep IO call-traces Example: %pg -> sda, sda1 or loop0p1 [AV: fixed a minor braino - position updates should not be dependent upon having reached the of buffer] Signed-off-by:
Dmitry Monakhov <dmonakhov@openvz.org> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
Dmitry Monakhov authored
gendisk with part==0 is obviously gendisk->disk_name. Signed-off-by:
Dmitry Monakhov <dmonakhov@openvz.org> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
- Jan 06, 2016
-
-
Mateusz Guzik authored
Number of fds is already known based on passed list. No functional changes. Signed-off-by:
Mateusz Guzik <mguzik@redhat.com> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Signed-off-by:Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Signed-off-by:Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Signed-off-by:Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
[folded a fix by Dan Carpenter] Signed-off-by:Al Viro <viro@zeniv.linux.org.uk>
-
- Jan 04, 2016
-
-
Al Viro authored
Signed-off-by:Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Signed-off-by:Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
... rather than play with __get_free_pages() (and figuring out the allocation order, etc.) Signed-off-by:Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
get_zeroed_page does alloc_page and returns page_address of the result; subsequent virt_to_page will recover the page, but since the caller needs both page and its page_address() anyway, why bother going through that wrapper at all? Signed-off-by:Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Signed-off-by:Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Signed-off-by:Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
... so virt_to_phys(p) & (PAGE_SIZE - 1) is a very odd way to spell offset_in_page(p). Signed-off-by:Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Signed-off-by:Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Signed-off-by:Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Signed-off-by:Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
let it just return NULL, pointer to kernel copy or ERR_PTR(). Signed-off-by:Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Signed-off-by:Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
When __get_user64() had been removed, its helper (__get_user64_nocheck) got missed. Signed-off-by:Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
they hadn't been used in last 15 years... Signed-off-by:Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Signed-off-by:Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Signed-off-by:Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
all we do to buffer is strncmp()... Signed-off-by:Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
again, it only parses the contents of the copied buffer, so get_zeroed_page() might as well had been kmalloc(), which makes it open-coded memdup_user_nul() Signed-off-by:Al Viro <viro@zeniv.linux.org.uk>
-