On 2014.04.04 at 18:11 -0700, Linus Torvalds wrote:
> On Fri, Apr 4, 2014 at 6:06 PM, Linus Torvalds
> wrote:
> >
> > Will report back soon when I've narrowed it down more.
>
> Ok, that may end up being harder than it looked. Commit
> a755180bab81c038a6989d7ab746c702f1b3ec03 doesn't boot for me a
On Fri, Apr 4, 2014 at 6:11 PM, Linus Torvalds
wrote:
>
> I'll try to pick kernels away from that, but that makes bisection much
> less effective.
Ok, I think I'm away from the broken region. The problem seems to be in between
good: 8e30e2b8ba0e ("cgroup: restructure locking and error handling i
On Fri, Apr 4, 2014 at 6:06 PM, Linus Torvalds
wrote:
>
> Will report back soon when I've narrowed it down more.
Ok, that may end up being harder than it looked. Commit
a755180bab81c038a6989d7ab746c702f1b3ec03 doesn't boot for me at all,
so apparently there are some really broken points in that w
On Thu, Apr 3, 2014 at 9:49 AM, Tejun Heo wrote:
>
> A lot updates for cgroup [...]
Btw, just a heads up to let you know: I'm in the middle of bisecting
why my machine no longer reboots cleanly, and while I'm a few boots
away from pinpointing it exactly, it has now drilled down to the point
that
On Fri, Apr 04, 2014 at 05:14:41PM +0800, Li Zefan wrote:
> [PATCH] cgroup: fix top cgroup refcnt leak
>
> As mount() and kill_sb() is not a one-to-one match, If we mount the same
> cgroupfs in serveral mount points, and then umount all of them, kill_sb()
> will be called only once.
>
> Try:
>
On Thu, Apr 03, 2014 at 01:02:45PM -0700, Linus Torvalds wrote:
> > The cgroup_root should be destroyed but it isn't, I think. We'd need
> > to bump cgroup_root's refcnt only when a new sb is created. It's
> > kinda ugly. Hmmm...
>
> Ok, so I guess we can use that "new_sb_created" thing, and I'
On 2014/4/4 3:43, Tejun Heo wrote:
> Hello,
>
> On Thu, Apr 03, 2014 at 12:01:23PM -0700, Linus Torvalds wrote:
>> [ Extending the participants list a bit ]
>>
>> On Thu, Apr 3, 2014 at 11:34 AM, Tejun Heo wrote:
>>> On the road so sending from phone. Iirc the param is necessary to
>>> distinguis
Tejun Heo writes:
> Hello,
>
> On Thu, Apr 03, 2014 at 12:01:23PM -0700, Linus Torvalds wrote:
>> [ Extending the participants list a bit ]
>>
> As for using specific type for ns tag, yeah, that'd be better
> regardless of this. The opaqueness is a bit extreme now.
(The opaqueness has alwasy b
On Thu, Apr 3, 2014 at 12:43 PM, Tejun Heo wrote:
>
> Ah, I remembered the other way around. We could leak cgroup_root
> reference, not the other way around. cgroup_mount() can be called
> multiple times for the same sb and we inc cgroup_root's ref each time
> but cgroup_kill_sb() only happens w
Hello,
On Thu, Apr 03, 2014 at 12:01:23PM -0700, Linus Torvalds wrote:
> [ Extending the participants list a bit ]
>
> On Thu, Apr 3, 2014 at 11:34 AM, Tejun Heo wrote:
> > On the road so sending from phone. Iirc the param is necessary to
> > distinguishe when a new sb is created so that it can
[ Extending the participants list a bit ]
On Thu, Apr 3, 2014 at 11:34 AM, Tejun Heo wrote:
> On the road so sending from phone. Iirc the param is necessary to
> distinguishe when a new sb is created so that it can be put properly later.
> I think cgroup is leaking super ref now and li was planni
On Thu, Apr 3, 2014 at 11:11 AM, Linus Torvalds
wrote:
>
> And the "bool *new_sb_created" argument really makes *zero* sense to
> kernfs_mount(). It was added to fix a namespace refcount leak, BUT
> kernfs_mount() DOES NOT TAKE A NAMESPACE PARAMETER!
Let me clarify that: the only reason I can see
On Thu, Apr 3, 2014 at 9:49 AM, Tejun Heo wrote:
>
> C3. fed95bab8d29 ("sysfs: fix namespace refcnt leak") added an
> argument to kernfs_mount() and was routed through driver-core-next
> after cgroup pulled the tree. cgroup's usage needs to be updated
> accordingly.
This one I find v
Hello, Linus.
A lot updates for cgroup.
* The biggest one is cgroup's conversion to kernfs. cgroup took after
the long abandoned vfs-entangled sysfs implementation and made it
even more convoluted over time. cgroup's internal objects were
fused with vfs objects which also brought in vfs l
14 matches
Mail list logo