On Thu, Mar 29, 2018 at 11:35:00PM +0100, Al Viro wrote:
> Uh-oh... What happens to existing users of kiocb_set_cancel_fn() now?
> AFAICS, those guys will *not* get aio_kiocb freed at all in case of
> io_cancel(2). Look: we mark them with AIO_IOCB_CANCELLED and
> call whatever ->ki_cancel() the
On Thu, Mar 29, 2018 at 11:35:00PM +0100, Al Viro wrote:
> Uh-oh... What happens to existing users of kiocb_set_cancel_fn() now?
> AFAICS, those guys will *not* get aio_kiocb freed at all in case of
> io_cancel(2). Look: we mark them with AIO_IOCB_CANCELLED and
> call whatever ->ki_cancel() the
On Thu, Mar 29, 2018 at 10:33:05PM +0200, Christoph Hellwig wrote:
> The upcoming aio poll support would like to be able to complete the
> iocb inline from the cancellation context, but that would cause a
> double lock of ctx_lock with the current locking scheme. Move the
> cancelation outside
On Thu, Mar 29, 2018 at 10:33:05PM +0200, Christoph Hellwig wrote:
> The upcoming aio poll support would like to be able to complete the
> iocb inline from the cancellation context, but that would cause a
> double lock of ctx_lock with the current locking scheme. Move the
> cancelation outside
The upcoming aio poll support would like to be able to complete the
iocb inline from the cancellation context, but that would cause a
double lock of ctx_lock with the current locking scheme. Move the
cancelation outside the context lock to avoid this reversal, which
suits the existing usb gadgets
The upcoming aio poll support would like to be able to complete the
iocb inline from the cancellation context, but that would cause a
double lock of ctx_lock with the current locking scheme. Move the
cancelation outside the context lock to avoid this reversal, which
suits the existing usb gadgets
On Thu, Mar 29, 2018 at 03:25:06PM +0100, Al Viro wrote:
> OK. Let's leave that alone for now. Re deferred cancels - AFAICS, we *must*
> remove the sucker from ctx->active_reqs before dropping ->ctx_lock.
>
> As it is, you are creating a io_cancel()/io_cancel() race leading to double
> fput().
On Thu, Mar 29, 2018 at 03:25:06PM +0100, Al Viro wrote:
> OK. Let's leave that alone for now. Re deferred cancels - AFAICS, we *must*
> remove the sucker from ctx->active_reqs before dropping ->ctx_lock.
>
> As it is, you are creating a io_cancel()/io_cancel() race leading to double
> fput().
On Thu, Mar 29, 2018 at 10:53:05AM +0200, Christoph Hellwig wrote:
> On Wed, Mar 28, 2018 at 05:35:26PM +0100, Al Viro wrote:
> > > ret = vfs_fsync(req->file, req->datasync);
> > > - fput(req->file);
> > > - aio_complete(container_of(req, struct aio_kiocb, fsync), ret, 0);
> > > + if
On Thu, Mar 29, 2018 at 10:53:05AM +0200, Christoph Hellwig wrote:
> On Wed, Mar 28, 2018 at 05:35:26PM +0100, Al Viro wrote:
> > > ret = vfs_fsync(req->file, req->datasync);
> > > - fput(req->file);
> > > - aio_complete(container_of(req, struct aio_kiocb, fsync), ret, 0);
> > > + if
On Wed, Mar 28, 2018 at 05:35:26PM +0100, Al Viro wrote:
> > ret = vfs_fsync(req->file, req->datasync);
> > - fput(req->file);
> > - aio_complete(container_of(req, struct aio_kiocb, fsync), ret, 0);
> > + if (aio_complete(iocb, ret, 0, 0))
> > + fput(file);
>
> IDGI.
>
On Wed, Mar 28, 2018 at 05:35:26PM +0100, Al Viro wrote:
> > ret = vfs_fsync(req->file, req->datasync);
> > - fput(req->file);
> > - aio_complete(container_of(req, struct aio_kiocb, fsync), ret, 0);
> > + if (aio_complete(iocb, ret, 0, 0))
> > + fput(file);
>
> IDGI.
>
On Wed, Mar 28, 2018 at 05:35:26PM +0100, Al Viro wrote:
> On Wed, Mar 28, 2018 at 09:29:03AM +0200, Christoph Hellwig wrote:
> > static void aio_fsync_work(struct work_struct *work)
> > {
> > struct fsync_iocb *req = container_of(work, struct fsync_iocb, work);
> > + struct aio_kiocb
On Wed, Mar 28, 2018 at 05:35:26PM +0100, Al Viro wrote:
> On Wed, Mar 28, 2018 at 09:29:03AM +0200, Christoph Hellwig wrote:
> > static void aio_fsync_work(struct work_struct *work)
> > {
> > struct fsync_iocb *req = container_of(work, struct fsync_iocb, work);
> > + struct aio_kiocb
On Wed, Mar 28, 2018 at 09:29:03AM +0200, Christoph Hellwig wrote:
> static void aio_fsync_work(struct work_struct *work)
> {
> struct fsync_iocb *req = container_of(work, struct fsync_iocb, work);
> + struct aio_kiocb *iocb = container_of(req, struct aio_kiocb, fsync);
> + struct
On Wed, Mar 28, 2018 at 09:29:03AM +0200, Christoph Hellwig wrote:
> static void aio_fsync_work(struct work_struct *work)
> {
> struct fsync_iocb *req = container_of(work, struct fsync_iocb, work);
> + struct aio_kiocb *iocb = container_of(req, struct aio_kiocb, fsync);
> + struct
The upcoming aio poll support would like to be able to complete the
iocb inline from the cancellation context, but that would cause
a lock order reversal. Add support for optionally moving the cancelation
outside the context lock to avoid this reversal.
To make this safe aio_complete needs to
The upcoming aio poll support would like to be able to complete the
iocb inline from the cancellation context, but that would cause
a lock order reversal. Add support for optionally moving the cancelation
outside the context lock to avoid this reversal.
To make this safe aio_complete needs to
18 matches
Mail list logo
