On 12/11/18 11:53 AM, Matthew Wilcox wrote:
> On Tue, Dec 11, 2018 at 11:46:53AM -0700, Jens Axboe wrote:
>> On 12/11/18 11:45 AM, Matthew Wilcox wrote:
>>> I think we need the rcu read lock here to prevent ctx from being freed
>>> under us by free_ioctx().
>>
>> Then that begs the question, how ab
On 12/11/18 11:46 AM, Jens Axboe wrote:
> On 12/11/18 11:45 AM, Matthew Wilcox wrote:
>> On Tue, Dec 11, 2018 at 11:41:55AM -0700, Jens Axboe wrote:
>>> On Wed, Nov 28, 2018 at 11:35 AM Matthew Wilcox wrote:
rcu_read_lock();
- table = rcu_dereference(mm->ioctx_table);
On Tue, Dec 11, 2018 at 11:46:53AM -0700, Jens Axboe wrote:
> On 12/11/18 11:45 AM, Matthew Wilcox wrote:
> > I think we need the rcu read lock here to prevent ctx from being freed
> > under us by free_ioctx().
>
> Then that begs the question, how about __xa_load() that is already called
> under R
On 12/11/18 11:51 AM, Matthew Wilcox wrote:
> On Tue, Dec 11, 2018 at 11:32:54AM -0700, Jens Axboe wrote:
>> Don't see any regressions. But if we're fiddling with it anyway, can't
>> we do something smarter? Make the fast path just index a table, and put
>> all the big hammers in setup/destroy. We'
On Tue, Dec 11, 2018 at 11:32:54AM -0700, Jens Axboe wrote:
> Don't see any regressions. But if we're fiddling with it anyway, can't
> we do something smarter? Make the fast path just index a table, and put
> all the big hammers in setup/destroy. We're spending a non-substantial
> amount of time do
On 12/11/18 11:45 AM, Matthew Wilcox wrote:
> On Tue, Dec 11, 2018 at 11:41:55AM -0700, Jens Axboe wrote:
>> On Wed, Nov 28, 2018 at 11:35 AM Matthew Wilcox wrote:
>>>
>>> rcu_read_lock();
>>> - table = rcu_dereference(mm->ioctx_table);
>>> -
>>> - if (!table || id >= table->nr
On Tue, Dec 11, 2018 at 11:41:55AM -0700, Jens Axboe wrote:
> On Wed, Nov 28, 2018 at 11:35 AM Matthew Wilcox wrote:
> >
> > rcu_read_lock();
> > - table = rcu_dereference(mm->ioctx_table);
> > -
> > - if (!table || id >= table->nr)
> > - goto out;
> > -
> > -
On Wed, Nov 28, 2018 at 11:35 AM Matthew Wilcox wrote:
> @@ -1026,24 +979,17 @@ static struct kioctx *lookup_ioctx(unsigned long
> ctx_id)
> struct aio_ring __user *ring = (void __user *)ctx_id;
> struct mm_struct *mm = current->mm;
> struct kioctx *ctx, *ret = NULL;
> -
On 12/11/18 11:09 AM, Jeff Moyer wrote:
> Jens Axboe writes:
>
>> On 12/11/18 11:02 AM, Jeff Moyer wrote:
>>> Matthew Wilcox writes:
>>>
On Tue, Dec 11, 2018 at 12:21:52PM -0500, Jeff Moyer wrote:
> I'm going to submit this version formally. If you're interested in
> converting the
On 12/11/18 11:32 AM, Jens Axboe wrote:
> On 12/11/18 11:05 AM, Jens Axboe wrote:
>> On 12/11/18 11:02 AM, Jeff Moyer wrote:
>>> Matthew Wilcox writes:
>>>
On Tue, Dec 11, 2018 at 12:21:52PM -0500, Jeff Moyer wrote:
> I'm going to submit this version formally. If you're interested in
>>>
On 12/11/18 11:05 AM, Jens Axboe wrote:
> On 12/11/18 11:02 AM, Jeff Moyer wrote:
>> Matthew Wilcox writes:
>>
>>> On Tue, Dec 11, 2018 at 12:21:52PM -0500, Jeff Moyer wrote:
I'm going to submit this version formally. If you're interested in
converting the ioctx_table to xarray, you can
Jens Axboe writes:
> On 12/11/18 11:02 AM, Jeff Moyer wrote:
>> Matthew Wilcox writes:
>>
>>> On Tue, Dec 11, 2018 at 12:21:52PM -0500, Jeff Moyer wrote:
I'm going to submit this version formally. If you're interested in
converting the ioctx_table to xarray, you can do that separatel
On 12/11/18 11:02 AM, Jeff Moyer wrote:
> Matthew Wilcox writes:
>
>> On Tue, Dec 11, 2018 at 12:21:52PM -0500, Jeff Moyer wrote:
>>> I'm going to submit this version formally. If you're interested in
>>> converting the ioctx_table to xarray, you can do that separately from a
>>> security fix.
Matthew Wilcox writes:
> On Tue, Dec 11, 2018 at 12:21:52PM -0500, Jeff Moyer wrote:
>> I'm going to submit this version formally. If you're interested in
>> converting the ioctx_table to xarray, you can do that separately from a
>> security fix. I would include a performance analysis with that
On Tue, Dec 11, 2018 at 12:21:52PM -0500, Jeff Moyer wrote:
> I'm going to submit this version formally. If you're interested in
> converting the ioctx_table to xarray, you can do that separately from a
> security fix. I would include a performance analysis with that patch,
> though. The idea of
Jeff Moyer writes:
> Jeff Moyer writes:
>
>> Matthew Wilcox writes:
>>
>>> This custom resizing array was vulnerable to a Spectre attack (speculating
>>> off the end of an array to a user-controlled offset). The XArray is
>>> not vulnerable to Spectre as it always masks its lookups to be withi
Jeff Moyer writes:
> Matthew Wilcox writes:
>
>> This custom resizing array was vulnerable to a Spectre attack (speculating
>> off the end of an array to a user-controlled offset). The XArray is
>> not vulnerable to Spectre as it always masks its lookups to be within
>> the bounds of the array.
Matthew Wilcox writes:
> This custom resizing array was vulnerable to a Spectre attack (speculating
> off the end of an array to a user-controlled offset). The XArray is
> not vulnerable to Spectre as it always masks its lookups to be within
> the bounds of the array.
I'm not a big fan of compl
ping
On Wed, Nov 28, 2018 at 10:35:31AM -0800, Matthew Wilcox wrote:
> This custom resizing array was vulnerable to a Spectre attack (speculating
> off the end of an array to a user-controlled offset). The XArray is
> not vulnerable to Spectre as it always masks its lookups to be within
> the bou
19 matches
Mail list logo
