Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230107080702.4907-1-hdanton@sina.com> <20230108222548.698721-1-kamatam@amazon.com>
 <20230108234917.5322-1-hdanton@sina.com> <CAJuCfpEWd6RtevMiUcv7RCH7rjadTMr7UYjJJiGw1ReNHtbJ0g@mail.gmail.com>
In-Reply-To: <CAJuCfpEWd6RtevMiUcv7RCH7rjadTMr7UYjJJiGw1ReNHtbJ0g@mail.gmail.com>
From:   Suren Baghdasaryan <surenb@google.com>
Date:   Mon, 9 Jan 2023 19:06:26 -0800
Message-ID: <CAJuCfpEL6FBOVr5UhvS4EjAicvQQijw0AULWnftRemgDE08kbw@mail.gmail.com>
Subject: Re: another use-after-free in ep_remove_wait_queue()
To:     Hillf Danton <hdanton@sina.com>
Cc:     Munehisa Kamata <kamatam@amazon.com>, hannes@cmpxchg.org,
        ebiggers@kernel.org, mengcc@amazon.com, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Mon, Jan 9, 2023 at 5:33 PM Suren Baghdasaryan <surenb@google.com> wrote:
>
> On Sun, Jan 8, 2023 at 3:49 PM Hillf Danton <hdanton@sina.com> wrote:
> >
> > On 8 Jan 2023 14:25:48 -0800 PM Munehisa Kamata <kamatam@amazon.com> wrote:
> > >
> > > That patch survived the repro in my original post, however, the waker
> > > (rmdir) was getting stuck until a file descriptor of the epoll instance or
> > > the pressure file got closed. So, if the following modified repro runs
> > > with the patch, the waker never returns (unless the sleeper gets killed)
> > > while holding cgroup_mutex. This doesn't seem to be what you expected to
> > > see with the patch, does it? Even wake_up_all() does not appear to empty
> > > the queue, but wake_up_pollfree() does.
> >
> > Thanks for your testing. And the debugging completes.
> >
> > Mind sending a patch with wake_up_pollfree() folded?
>
> I finally had some time to look into this issue. I don't think
> delaying destruction in psi_trigger_destroy() because there are still
> users of the trigger as Hillf suggested is a good way to go. Before
> [1] correct trigger destruction was handled using a
> psi_trigger.refcount. For some reason I thought it's not needed
> anymore when we placed one-trigger-per-file restriction in that patch,
> so I removed it. Obviously that was a wrong move, so I think the
> cleanest way would be to bring back the refcounting. That way the last
> user of the trigger (either psi_trigger_poll() or psi_fop_release())
> will free the trigger.
> I'll check once more to make sure I did not miss anything and if there
> are no objections, will post a fix.

Uh, I recalled now why refcounting was not helpful here. I'm making
the same mistake of thinking that poll_wait() blocks until the call to
wake_up() which is not the case. Let me think if there is anything
better than wake_up_pollfree() for this case.


>
> [1] https://lore.kernel.org/lkml/20220111232309.1786347-1-surenb@google.com/
>
> Thanks,
> Suren.
>
> >
> > Hillf