Thread Pool memory ownership

[Mathew Heard]

Thank you,

I understand and it makes sense.

Do you have any advice for how third party modules could acheive the same?
The blocked field might be safe to use within other phases but it's
difficult to fully verify.

I'm no longer using that module (having found an alternative) but I'm
willing to push an issue to them in the spirit of oss.


Perhaps a comment in the nginx developer docs regarding the correct way to
get memory for a thread pool task would be a good idea? It seems like a
common problem for which there is limited examples for reference.

Thanks again for your help Maxim

- Mathew




On Wed, 31 May 2023, 12:15 pm Maxim Dounin, <mdounin at mdounin.ru> wrote:

> Hello!
>
> On Wed, May 31, 2023 at 01:26:35AM +1000, Mathew Heard wrote:
>
> > I've been going through the threadpool code for native modules in an
> > attempt to fix a third party module with what appears to be a
> > use-after free error looking for inspiration.
> >
> > I thought I would see a strategy to prevent thread pool tasks that are
> > in the queue for processing being freed when the request / connection
> > their memory is allocated from is cleared but I'm not.
> >
> > For example there does not for example appear to be any protection
> > against linux sendfile tasks from reading memory allocated from the
> > ngx_connection_t if the connection is closed while the task is in the
> > task queue.
> >
> > Is this correct? Is this a bug?
>
> As long as there is a thread task or an AIO request scheduled, the
> request is expected to be blocked with r->blocked, so it won't be
> freed.
>
> For sendfile in threads, this is done by
> ngx_http_copy_thread_handler() (in
> src/http/ngx_http_copy_filter_module.c), which is called by
> ngx_linux_sendfile_thread() as file->file->thread_handler() when a
> sendfile task is queued.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20230601/0e8d30a7/attachment.htm>