On Thu, Dec 05, 2013 at 03:00:33PM -0800, Paul E. McKenney wrote:
The question is: Is it safe to have a call_rcu() without any additional
rate limiting
on user triggerable code path?
That would be a good way to allow users to run your system out of memory,
especially on
On Thu, Nov 28, 2013 at 10:55:06AM +0200, Gleb Natapov wrote:
On Wed, Nov 27, 2013 at 09:06:36AM -0800, Paul E. McKenney wrote:
On Wed, Nov 27, 2013 at 10:00:09AM +0200, Gleb Natapov wrote:
On Tue, Nov 26, 2013 at 11:35:06AM -0800, Paul E. McKenney wrote:
On Tue, Nov 26, 2013 at
On Wed, Nov 27, 2013 at 09:06:36AM -0800, Paul E. McKenney wrote:
On Wed, Nov 27, 2013 at 10:00:09AM +0200, Gleb Natapov wrote:
On Tue, Nov 26, 2013 at 11:35:06AM -0800, Paul E. McKenney wrote:
On Tue, Nov 26, 2013 at 06:24:13PM +0200, Michael S. Tsirkin wrote:
On Wed, Sep 12, 2012 at
On Tue, Nov 26, 2013 at 11:35:06AM -0800, Paul E. McKenney wrote:
On Tue, Nov 26, 2013 at 06:24:13PM +0200, Michael S. Tsirkin wrote:
On Wed, Sep 12, 2012 at 08:13:54AM -0700, Paul E. McKenney wrote:
On Wed, Sep 12, 2012 at 03:44:26PM +0300, Gleb Natapov wrote:
On Wed, Sep 12, 2012 at
On Wed, Nov 27, 2013 at 10:00:09AM +0200, Gleb Natapov wrote:
On Tue, Nov 26, 2013 at 11:35:06AM -0800, Paul E. McKenney wrote:
On Tue, Nov 26, 2013 at 06:24:13PM +0200, Michael S. Tsirkin wrote:
On Wed, Sep 12, 2012 at 08:13:54AM -0700, Paul E. McKenney wrote:
On Wed, Sep 12, 2012 at
On Wed, Sep 12, 2012 at 08:13:54AM -0700, Paul E. McKenney wrote:
On Wed, Sep 12, 2012 at 03:44:26PM +0300, Gleb Natapov wrote:
On Wed, Sep 12, 2012 at 03:36:57PM +0300, Avi Kivity wrote:
On 09/12/2012 03:34 PM, Gleb Natapov wrote:
On Wed, Sep 12, 2012 at 10:45:22AM +0300, Avi Kivity
On Tue, Nov 26, 2013 at 06:24:13PM +0200, Michael S. Tsirkin wrote:
On Wed, Sep 12, 2012 at 08:13:54AM -0700, Paul E. McKenney wrote:
On Wed, Sep 12, 2012 at 03:44:26PM +0300, Gleb Natapov wrote:
On Wed, Sep 12, 2012 at 03:36:57PM +0300, Avi Kivity wrote:
On 09/12/2012 03:34 PM, Gleb
On Tue, Nov 26, 2013 at 06:24:13PM +0200, Michael S. Tsirkin wrote:
On Wed, Sep 12, 2012 at 08:13:54AM -0700, Paul E. McKenney wrote:
On Wed, Sep 12, 2012 at 03:44:26PM +0300, Gleb Natapov wrote:
On Wed, Sep 12, 2012 at 03:36:57PM +0300, Avi Kivity wrote:
On 09/12/2012 03:34 PM, Gleb
On 09/12/2012 01:39 AM, Michael S. Tsirkin wrote:
On Tue, Sep 11, 2012 at 11:04:59PM +0300, Avi Kivity wrote:
On 09/11/2012 08:13 PM, Paul E. McKenney wrote:
Is there a risk of DOS if RCU is delayed while
lots of memory is queued up in this way?
If yes is this a generic problem with
On 09/12/2012 04:03 AM, Paul E. McKenney wrote:
Paul, I'd like to check something with you here:
this function can be triggered by userspace,
any number of times; we allocate
a 2K chunk of memory that is later freed by
kfree_rcu.
Is there a risk of DOS if RCU is delayed while
On Tue, Sep 11, 2012 at 10:13:00AM -0700, Paul E. McKenney wrote:
On Tue, Sep 11, 2012 at 05:10:23PM +0300, Michael S. Tsirkin wrote:
On Tue, Sep 11, 2012 at 04:02:25PM +0300, Gleb Natapov wrote:
Most interrupt are delivered to only one vcpu. Use pre-build tables to
find interrupt
On Wed, Sep 12, 2012 at 10:45:22AM +0300, Avi Kivity wrote:
On 09/12/2012 04:03 AM, Paul E. McKenney wrote:
Paul, I'd like to check something with you here:
this function can be triggered by userspace,
any number of times; we allocate
a 2K chunk of memory that is later freed by
On Wed, Sep 12, 2012 at 03:36:57PM +0300, Avi Kivity wrote:
On 09/12/2012 03:34 PM, Gleb Natapov wrote:
On Wed, Sep 12, 2012 at 10:45:22AM +0300, Avi Kivity wrote:
On 09/12/2012 04:03 AM, Paul E. McKenney wrote:
Paul, I'd like to check something with you here:
this function can be
On Wed, Sep 12, 2012 at 03:44:26PM +0300, Gleb Natapov wrote:
On Wed, Sep 12, 2012 at 03:36:57PM +0300, Avi Kivity wrote:
On 09/12/2012 03:34 PM, Gleb Natapov wrote:
On Wed, Sep 12, 2012 at 10:45:22AM +0300, Avi Kivity wrote:
On 09/12/2012 04:03 AM, Paul E. McKenney wrote:
Paul, I'd
Most interrupt are delivered to only one vcpu. Use pre-build tables to
find interrupt destination instead of looping through all vcpus. In case
of logical mode loop only through vcpus in a logical cluster irq is sent
to.
Signed-off-by: Gleb Natapov g...@redhat.com
---
Changelog:
- v1-v2
*
On 09/11/2012 04:02 PM, Gleb Natapov wrote:
Most interrupt are delivered to only one vcpu. Use pre-build tables to
find interrupt destination instead of looping through all vcpus. In case
of logical mode loop only through vcpus in a logical cluster irq is sent
to.
* fix rcu issues
On Tue, Sep 11, 2012 at 04:26:17PM +0300, Avi Kivity wrote:
On 09/11/2012 04:02 PM, Gleb Natapov wrote:
Most interrupt are delivered to only one vcpu. Use pre-build tables to
find interrupt destination instead of looping through all vcpus. In case
of logical mode loop only through vcpus in
On Tue, Sep 11, 2012 at 04:02:25PM +0300, Gleb Natapov wrote:
Most interrupt are delivered to only one vcpu. Use pre-build tables to
find interrupt destination instead of looping through all vcpus. In case
of logical mode loop only through vcpus in a logical cluster irq is sent
to.
On Tue, Sep 11, 2012 at 04:26:17PM +0300, Avi Kivity wrote:
On 09/11/2012 04:02 PM, Gleb Natapov wrote:
Most interrupt are delivered to only one vcpu. Use pre-build tables to
find interrupt destination instead of looping through all vcpus. In case
of logical mode loop only through vcpus in
On 09/11/2012 05:46 PM, Gleb Natapov wrote:
On Tue, Sep 11, 2012 at 04:26:17PM +0300, Avi Kivity wrote:
On 09/11/2012 04:02 PM, Gleb Natapov wrote:
Most interrupt are delivered to only one vcpu. Use pre-build tables to
find interrupt destination instead of looping through all vcpus. In case
On Tue, Sep 11, 2012 at 05:10:23PM +0300, Michael S. Tsirkin wrote:
On Tue, Sep 11, 2012 at 04:02:25PM +0300, Gleb Natapov wrote:
Most interrupt are delivered to only one vcpu. Use pre-build tables to
find interrupt destination instead of looping through all vcpus. In case
of logical mode
On 09/11/2012 08:13 PM, Paul E. McKenney wrote:
Is there a risk of DOS if RCU is delayed while
lots of memory is queued up in this way?
If yes is this a generic problem with kfree_rcu
that should be addressed in core kernel?
There is indeed a risk. The kfree_rcu() implementation cannot
On Tue, Sep 11, 2012 at 10:13:00AM -0700, Paul E. McKenney wrote:
On Tue, Sep 11, 2012 at 05:10:23PM +0300, Michael S. Tsirkin wrote:
On Tue, Sep 11, 2012 at 04:02:25PM +0300, Gleb Natapov wrote:
Most interrupt are delivered to only one vcpu. Use pre-build tables to
find interrupt
On Tue, Sep 11, 2012 at 11:04:59PM +0300, Avi Kivity wrote:
On 09/11/2012 08:13 PM, Paul E. McKenney wrote:
Is there a risk of DOS if RCU is delayed while
lots of memory is queued up in this way?
If yes is this a generic problem with kfree_rcu
that should be addressed in core kernel?
On Wed, Sep 12, 2012 at 01:33:37AM +0300, Michael S. Tsirkin wrote:
On Tue, Sep 11, 2012 at 10:13:00AM -0700, Paul E. McKenney wrote:
On Tue, Sep 11, 2012 at 05:10:23PM +0300, Michael S. Tsirkin wrote:
On Tue, Sep 11, 2012 at 04:02:25PM +0300, Gleb Natapov wrote:
Most interrupt are
25 matches
Mail list logo
