search for: probe_kernel_address

On 02/09/2015 02:44 AM, Jeremy Fitzhardinge wrote: > On 02/06/2015 06:49 AM, Raghavendra K T wrote: [...] > >> Linus suggested that we should not do any writes to lock after unlock(), >> and we can move slowpath clearing to fastpath lock. > > Yep, that seems like a sound approach. Current approach seem to be working now. (though we could not avoid read). Related question:

On 02/09/2015 02:44 AM, Jeremy Fitzhardinge wrote: > On 02/06/2015 06:49 AM, Raghavendra K T wrote: [...] > >> Linus suggested that we should not do any writes to lock after unlock(), >> and we can move slowpath clearing to fastpath lock. > > Yep, that seems like a sound approach. Current approach seem to be working now. (though we could not avoid read). Related question:

...tra <peterz at infradead.org> wrote: > On Mon, Feb 09, 2015 at 03:04:22PM +0530, Raghavendra K T wrote: >> So we have 3 choices, >> 1. xadd >> 2. continue with current approach. >> 3. a read before unlock and also after that. > > For the truly paranoid we have probe_kernel_address(), suppose the lock > was in module space and the module just got unloaded under us. That's much too expensive. The xadd shouldn't be noticeably more expensive than the current "add_smp()". Yes, "lock xadd" used to be several cycles slower than just "lock add&q...

...tra <peterz at infradead.org> wrote: > On Mon, Feb 09, 2015 at 03:04:22PM +0530, Raghavendra K T wrote: >> So we have 3 choices, >> 1. xadd >> 2. continue with current approach. >> 3. a read before unlock and also after that. > > For the truly paranoid we have probe_kernel_address(), suppose the lock > was in module space and the module just got unloaded under us. That's much too expensive. The xadd shouldn't be noticeably more expensive than the current "add_smp()". Yes, "lock xadd" used to be several cycles slower than just "lock add&q...

On Mon, Feb 09, 2015 at 03:04:22PM +0530, Raghavendra K T wrote: > So we have 3 choices, > 1. xadd > 2. continue with current approach. > 3. a read before unlock and also after that. For the truly paranoid we have probe_kernel_address(), suppose the lock was in module space and the module just got unloaded under us.

...org> wrote: >> On Mon, Feb 09, 2015 at 03:04:22PM +0530, Raghavendra K T wrote: >>> So we have 3 choices, >>> 1. xadd >>> 2. continue with current approach. >>> 3. a read before unlock and also after that. >> >> For the truly paranoid we have probe_kernel_address(), suppose the lock >> was in module space and the module just got unloaded under us. > > That's much too expensive. > > The xadd shouldn't be noticeably more expensive than the current > "add_smp()". Yes, "lock xadd" used to be several cycles slower...

On Mon, Feb 09, 2015 at 03:04:22PM +0530, Raghavendra K T wrote: > So we have 3 choices, > 1. xadd > 2. continue with current approach. > 3. a read before unlock and also after that. For the truly paranoid we have probe_kernel_address(), suppose the lock was in module space and the module just got unloaded under us.

...org> wrote: >> On Mon, Feb 09, 2015 at 03:04:22PM +0530, Raghavendra K T wrote: >>> So we have 3 choices, >>> 1. xadd >>> 2. continue with current approach. >>> 3. a read before unlock and also after that. >> >> For the truly paranoid we have probe_kernel_address(), suppose the lock >> was in module space and the module just got unloaded under us. > > That's much too expensive. > > The xadd shouldn't be noticeably more expensive than the current > "add_smp()". Yes, "lock xadd" used to be several cycles slower...