- 15 Jun, 2018 4 commits
-
-
Ben Noordhuis authored
Signed-off-by:
Ben Noordhuis <info@bnoordhuis.nl> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
Christoph Hellwig authored
The ->poll_mask() operation has a mask of events that the caller is interested in, but not all implementations might take it into account. Mask the return value to only the requested events, similar to what the poll and epoll code does. Reported-by:
Avi Kivity <avi@scylladb.com> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Avi Kivity authored
The ->poll_mask() operation has a mask of events that the caller is interested in, but we're returning all events regardless. Change to return only the events the caller is interested in. This fixes aio IO_CMD_POLL returning immediately when called with POLLIN on an eventfd, since an eventfd is almost always ready for a write. Signed-off-by:
-
Avi Kivity authored
io_pgetevents() will not change the signal mask. Mark it const to make it clear and to reduce the need for casts in user code. Reviewed-by:
-
- 04 Jun, 2018 2 commits
-
-
Adam Manzanares authored
Previously the value was ignored. Signed-off-by:
Adam Manzanares <adam.manzanares@wdc.com> Signed-off-by:
-
Adam Manzanares authored
Previously, the ioprio_check_cap function was only defined when CONFIG_BLOCK was set. Make this relationship explicit and add a stub for !CONFIG_BLOCK. Signed-off-by:
-
- 31 May, 2018 5 commits
-
-
Adam Manzanares authored
Now that kiocb has an ioprio field copy this over to the bio when it is created from the kiocb during direct IO. Signed-off-by:
Jeff Moyer <jmoyer@redhat.com> Reviewed-by:
-
Adam Manzanares authored
Now that kiocb has an ioprio field copy this over to the bio when it is created from the kiocb. Signed-off-by:
-
Adam Manzanares authored
This is the per-I/O equivalent of the ioprio_set system call. When IOCB_FLAG_IOPRIO is set on the iocb aio_flags field, then we set the newly added kiocb ki_ioprio field to the value in the iocb aio_reqprio field. This patch depends on block: add ioprio_check_cap function. Signed-off-by:
-
Adam Manzanares authored
In order to avoid kiocb bloat for per command iopriority support, rw_hint is converted from enum to a u16. Added a guard around ki_hint assignment. Signed-off-by:
-
Adam Manzanares authored
Aio per command iopriority support introduces a second interface between userland and the kernel capable of passing iopriority. The aio interface also needs the ability to verify that the submitting context has sufficient privileges to submit IOPRIO_RT commands. This patch creates the ioprio_check_cap function to be used by the ioprio_set system call and also by the aio interface. Signed-off-by:
-
- 30 May, 2018 6 commits
-
-
Al Viro authored
as it is, the logics in native io_submit(2) is "if asked for more than LONG_MAX/sizeof(pointer) iocbs to submit, don't bother with more than LONG_MAX/sizeof(pointer)" (i.e. 512M requests on 32bit and 1E requests on 64bit) while compat io_submit(2) goes with "stop after the first PAGE_SIZE/sizeof(pointer) iocbs", i.e. 1K or so. Which is * inconsistent * *way* too much in native case * possibly too little in compat one and * wrong anyway, since the natural point where we ought to stop bothering is ctx->nr_events Reviewed-by:
-
Al Viro authored
get rid of insane "copy array of 32bit pointers into an array of native ones" glue. Reviewed-by:
-
Al Viro authored
Reviewed-by:
-
Al Viro authored
The logics for 'avail' is * not past the tail of cyclic buffer * no more than asked * not past the end of buffer * not past the end of a page Unobfuscate the last part. Signed-off-by: -
Al Viro authored
... so just make them return 0 when caller does not need to destroy iocb Reviewed-by:
-
Al Viro authored
We really want iocb out of io_cancel(2) reach before we start tearing it down. Signed-off-by:
-
- 28 May, 2018 1 commit
-
-
Christoph Hellwig authored
Looks like this got lost in a merge. Signed-off-by:
-
- 26 May, 2018 22 commits
-
-
Christoph Hellwig authored
The big change is that random_read_wait and random_write_wait are merged into a single waitqueue that uses keyed wakeups. Because wait_event_* doesn't know about that this will lead to occassional spurious wakeups in _random_read and add_hwgenerator_randomness, but wait_event_* is designed to handle these and were are not in a a hot path there. Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Reviewed-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Christoph Hellwig authored
Signed-off-by: -
Christoph Hellwig authored
Signed-off-by: -
Christoph Hellwig authored
Signed-off-by: -
Christoph Hellwig authored
Signed-off-by: -
Christoph Hellwig authored
Signed-off-by: -
Christoph Hellwig authored
Signed-off-by: -
Christoph Hellwig authored
Signed-off-by: -
Christoph Hellwig authored
Signed-off-by: -
Christoph Hellwig authored
Signed-off-by: -
Christoph Hellwig authored
Signed-off-by: -
Christoph Hellwig authored
Signed-off-by: -
Christoph Hellwig authored
Signed-off-by: -
Christoph Hellwig authored
Signed-off-by: -
Christoph Hellwig authored
Signed-off-by: -
Christoph Hellwig authored
Signed-off-by: -
Christoph Hellwig authored
Signed-off-by:
-
Christoph Hellwig authored
Signed-off-by: -
Christoph Hellwig authored
Signed-off-by: -
Christoph Hellwig authored
Now that sock_poll handles a NULL ->poll or ->poll_mask there is no need for a stub. Signed-off-by: -
Christoph Hellwig authored
The socket file operations still implement ->poll until all protocols are switched over. Signed-off-by: -
Christoph Hellwig authored
Factor out two busy poll related helpers for late reuse, and remove a command that isn't very helpful, especially with the __poll_t annotations in place. Signed-off-by:
-
