On Mon, Dec 02, 2013 at 06:58:57PM -0800, Linus Torvalds wrote:
> In other words, it's unsafe to protect reference counts inside objects
> with anything but spinlocks and/or atomic refcounts. Or you have to
> have the lock *outside* the object you're protecting (which is often
> what you want for
Once more on this issue, because I've been unable to stop thinking
about it, and noticed that it's actually even subtler than I thought
initially.
On Mon, Dec 2, 2013 at 8:00 AM, Linus Torvalds
wrote:
>
> All our reference counting etc seems right, but we have one very
> subtle bug: on the
On Mon, Dec 02, 2013 at 08:00:38AM -0800, Linus Torvalds wrote:
> On Sat, Nov 30, 2013 at 1:08 PM, Linus Torvalds
> wrote:
> >
> > I still don't see what could be wrong with the pipe_inode_info thing,
> > but the fact that it's been so consistent in your traces does make me
> > suspect it really
* Al Viro wrote:
> On Mon, Dec 02, 2013 at 05:27:55PM +0100, Ingo Molnar wrote:
>
> > It's not like there should be many (any?) VFS operations where a pipe
> > is used via i_mutex and pipe->mutex in parallel, which would improve
> > scalability - so I don't see the scalability advantage.
On Mon, Dec 02, 2013 at 05:27:55PM +0100, Ingo Molnar wrote:
> It's not like there should be many (any?) VFS operations where a pipe
> is used via i_mutex and pipe->mutex in parallel, which would improve
> scalability - so I don't see the scalability advantage. (But I might
> be missing
* Linus Torvalds wrote:
> On Sat, Nov 30, 2013 at 1:08 PM, Linus Torvalds
> wrote:
> >
> > I still don't see what could be wrong with the pipe_inode_info thing,
> > but the fact that it's been so consistent in your traces does make me
> > suspect it really is *that* particular slab.
>
> I
On Sat, Nov 30, 2013 at 1:08 PM, Linus Torvalds
wrote:
>
> I still don't see what could be wrong with the pipe_inode_info thing,
> but the fact that it's been so consistent in your traces does make me
> suspect it really is *that* particular slab.
I think I finally found it.
I've spent waaayy
On Sat, Nov 30, 2013 at 1:08 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
I still don't see what could be wrong with the pipe_inode_info thing,
but the fact that it's been so consistent in your traces does make me
suspect it really is *that* particular slab.
I think I finally found
* Linus Torvalds torva...@linux-foundation.org wrote:
On Sat, Nov 30, 2013 at 1:08 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
I still don't see what could be wrong with the pipe_inode_info thing,
but the fact that it's been so consistent in your traces does make me
suspect
On Mon, Dec 02, 2013 at 05:27:55PM +0100, Ingo Molnar wrote:
It's not like there should be many (any?) VFS operations where a pipe
is used via i_mutex and pipe-mutex in parallel, which would improve
scalability - so I don't see the scalability advantage. (But I might
be missing something)
* Al Viro v...@zeniv.linux.org.uk wrote:
On Mon, Dec 02, 2013 at 05:27:55PM +0100, Ingo Molnar wrote:
It's not like there should be many (any?) VFS operations where a pipe
is used via i_mutex and pipe-mutex in parallel, which would improve
scalability - so I don't see the scalability
On Mon, Dec 02, 2013 at 08:00:38AM -0800, Linus Torvalds wrote:
On Sat, Nov 30, 2013 at 1:08 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
I still don't see what could be wrong with the pipe_inode_info thing,
but the fact that it's been so consistent in your traces does make me
Once more on this issue, because I've been unable to stop thinking
about it, and noticed that it's actually even subtler than I thought
initially.
On Mon, Dec 2, 2013 at 8:00 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
All our reference counting etc seems right, but we have one very
On Mon, Dec 02, 2013 at 06:58:57PM -0800, Linus Torvalds wrote:
In other words, it's unsafe to protect reference counts inside objects
with anything but spinlocks and/or atomic refcounts. Or you have to
have the lock *outside* the object you're protecting (which is often
what you want for
14 matches
Mail list logo
