Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

lio_listio needs to use unique storage locations for the list argument #870

Closed
asomers opened this issue Mar 4, 2018 · 0 comments
Closed

lio_listio needs to use unique storage locations for the list argument #870

asomers opened this issue Mar 4, 2018 · 0 comments
Assignees
@asomers

Comments

@asomers
Copy link
Member

asomers commented Mar 4, 2018

When delivering notifications via kevent, the kernel treats the address of the list argument as a the ident of the event. Within the kernel, ident is treated as a unique identifier. So there can only be one event with a given ident value in the kernel at any one time. However, Nix's sys::aio::lio_listio allows the user to supply a temporary Vec as the list argument. If the user calls lio_listio several times in a row, each with the same value of list (but different contents), kevent may deliver too few notifications.

The most fool-proof solution will probably be to create a struct LioCb object that owns all of the AioCb objects, and also owns the list variable as a Vec. That will achieve two things:

  1. The LioCb object will be forced to outlive the kernel's knowledge of it, since it owns the individual AioCbs
  2. The list argument is guaranteed to be unique for all concurrent lio_listio calls, because Vec is stack-allocated and the LioCb object must outlive the kernel's knowledge of the event.

https://www.freebsd.org/cgi/man.cgi?lio_listio
@asomers asomers self-assigned this Mar 4, 2018
asomers added a commit to asomers/nix that referenced this issue Mar 5, 2018
@asomers
Change sys::aio::lio_listio to sys::aio::LioCb::listio
c7bd172 
The new LioCb structure allows us to control the exact arguments passed
to lio_listio, guaranteeing that each call gets a unique storage
location for the list argument.  This prevents clients from misusing
lio_listio in a way that causes events to get dropped from a kqueue

Fixes nix-rust#870
@asomers asomers mentioned this issue Mar 5, 2018
Merged
asomers added a commit to asomers/nix that referenced this issue Mar 5, 2018
@asomers
Change sys::aio::lio_listio to sys::aio::LioCb::listio
a11432e 
The new LioCb structure allows us to control the exact arguments passed
to lio_listio, guaranteeing that each call gets a unique storage
location for the list argument.  This prevents clients from misusing
lio_listio in a way that causes events to get dropped from a kqueue

Fixes nix-rust#870
asomers added a commit to asomers/nix that referenced this issue Mar 22, 2018
@asomers
Change sys::aio::lio_listio to sys::aio::LioCb::listio
4bdbf59 
The new LioCb structure allows us to control the exact arguments passed
to lio_listio, guaranteeing that each call gets a unique storage
location for the list argument.  This prevents clients from misusing
lio_listio in a way that causes events to get dropped from a kqueue

Fixes nix-rust#870
bors bot added a commit that referenced this issue Apr 7, 2018
@bors
Merge #872
31e901b 
872: Change sys::aio::lio_listio to sys::aio::LioCb::listio r=asomers a=asomers

The new LioCb structure allows us to control the exact arguments passed
to lio_listio, guaranteeing that each call gets a unique storage
location for the list argument.  This prevents clients from misusing
lio_listio in a way that causes events to get dropped from a kqueue

Fixes #870
@bors bors bot closed this as completed in #872 Apr 7, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@asomers asomers

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@asomers