On Sun, Oct 08, 2017 at 10:13:57PM +0100, Al Viro wrote:
> On Sun, Oct 08, 2017 at 06:47:46PM +0300, Vladimir Davydov wrote:
> > On Sun, Oct 08, 2017 at 03:03:32AM +0100, Al Viro wrote:
> > > On Sun, Oct 08, 2017 at 01:56:08AM +0100, Al Viro wrote:
> > >
> > > > What's more, we need to be careful
On Sun, Oct 08, 2017 at 06:47:46PM +0300, Vladimir Davydov wrote:
> On Sun, Oct 08, 2017 at 03:03:32AM +0100, Al Viro wrote:
> > On Sun, Oct 08, 2017 at 01:56:08AM +0100, Al Viro wrote:
> >
> > > What's more, we need to be careful about resize vs. drain. Right now it's
> > > on list_lrus_mutex, b
On Sun, Oct 08, 2017 at 03:03:32AM +0100, Al Viro wrote:
> On Sun, Oct 08, 2017 at 01:56:08AM +0100, Al Viro wrote:
>
> > What's more, we need to be careful about resize vs. drain. Right now it's
> > on list_lrus_mutex, but if we drop that around actual resize of an
> > individual
> > list_lru,
On Sun, Oct 08, 2017 at 01:56:08AM +0100, Al Viro wrote:
> What's more, we need to be careful about resize vs. drain. Right now it's
> on list_lrus_mutex, but if we drop that around actual resize of an individual
> list_lru, we'll need something else. Would there be any problem if we
> took memc
On Sat, Oct 07, 2017 at 10:14:44PM +0100, Al Viro wrote:
> 1) coallocate struct list_lru and array of struct list_lru_node
> hanging off it. Turn all existing variables and struct members of that
> type into pointers. init would allocate and return a pointer, destroy
> would free (and leav
On Sat, Oct 07, 2017 at 06:06:51PM +0100, Al Viro wrote:
> On Sat, Oct 07, 2017 at 02:56:40PM +0300, Vladimir Davydov wrote:
> > Hello,
> >
> > On Fri, Oct 06, 2017 at 11:06:04AM +0200, Michal Hocko wrote:
> > > On Fri 06-10-17 16:59:18, Jia-Ju Bai wrote:
> > > > According to fs/super.c, the kerne
On Sat, Oct 07, 2017 at 02:56:40PM +0300, Vladimir Davydov wrote:
> Hello,
>
> On Fri, Oct 06, 2017 at 11:06:04AM +0200, Michal Hocko wrote:
> > On Fri 06-10-17 16:59:18, Jia-Ju Bai wrote:
> > > According to fs/super.c, the kernel may sleep under a spinlock.
> > > The function call path is:
> > >
Hello,
On Fri, Oct 06, 2017 at 11:06:04AM +0200, Michal Hocko wrote:
> On Fri 06-10-17 16:59:18, Jia-Ju Bai wrote:
> > According to fs/super.c, the kernel may sleep under a spinlock.
> > The function call path is:
> > put_super (acquire the spinlock)
> > __put_super
> > destroy_super
> >
On Fri, Oct 06, 2017 at 04:59:18PM +0800, Jia-Ju Bai wrote:
> According to fs/super.c, the kernel may sleep under a spinlock.
> The function call path is:
> put_super (acquire the spinlock)
> __put_super
> destroy_super
> list_lru_destroy
> list_lru_unregister
> mutex_
[CC Vladimir]
On Fri 06-10-17 16:59:18, Jia-Ju Bai wrote:
> According to fs/super.c, the kernel may sleep under a spinlock.
> The function call path is:
> put_super (acquire the spinlock)
> __put_super
> destroy_super
> list_lru_destroy
> list_lru_unregister
> mutex_l
According to fs/super.c, the kernel may sleep under a spinlock.
The function call path is:
put_super (acquire the spinlock)
__put_super
destroy_super
list_lru_destroy
list_lru_unregister
mutex_lock --> may sleep
memcg_get_cache_ids
down_read --> may
11 matches
Mail list logo
