You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by "Kian Karas (KK)" <kk...@thrane.eu> on 2025/02/10 17:58:36 UTC
Driver poll question
Hi community
I have a question related to the implementation of poll() in the kernel and drivers. I am implementing a driver with poll support (through file_operations::poll) and have observed that "teardown" of the pollfds is not performed if the task is killed (while task is blocked on a call to poll()). Is this intended behavior?
As file_operations::close is called it seems possible to find and remove the FD, but I cannot find any driver doing that. Since close is actually called on the driver, I would assume the intention is to clean up the driver, but I find it a little inconsistent that cleaning up the pollfds does not happen.
I am using the "flat" build configuration. The beavior may be different in "protected" builds?
Regards
Kian
Re: Driver poll question
Posted by "Kian Karas (KK)" <kk...@thrane.eu>.
I figured it out. The poll() implementation already supports this (see poll_cleanup()), but it was (implicit) disabled in my configuration:
CONFIG_TLS_NCLEANUP=0
Increasing it, solved the issue. The driver's poll "teardown" is then called before the driver's close function.
Thank you for your input Xiang.
Regards
Kian
________________________________
From: Xiang Xiao <xi...@gmail.com>
Sent: 12 February 2025 02:56
To: dev@nuttx.apache.org <de...@nuttx.apache.org>
Subject: Re: Driver poll question
How does the kernel know the killed thread is blocking in the driver's poll
method? Adding some flag in tcb_s for the special usage mayn't good.
BTW, there are many APIs that may block(e.g. write/read/send/recv), these
methods do not public callback to cancel the internal wait.
On Wed, Feb 12, 2025 at 4:10 AM Kian Karas (KK) <kk...@thrane.eu> wrote:
> Thank you for the reply Xiang and bringing the PRs to my attention.
>
> If I understand the PRs, they don't quite satisfy my concern. In my use
> case, an application is killed while blocked on a call to poll(). This
> results in a call (initiated by the kernel) to the driver's close callback
> (which is as expected). But why doesn't the kernel call the driver's poll
> callback first (before close), to do the teardown of the fds? This would
> result in the proper cleanup in the driver without requiring changes to any
> existing drivers.
>
> Regards
> Kian
> ________________________________
> From: Xiang Xiao <xi...@gmail.com>
> Sent: 11 February 2025 06:53
> To: dev@nuttx.apache.org <de...@nuttx.apache.org>
> Subject: Re: Driver poll question
>
> On Tue, Feb 11, 2025 at 2:00 AM Kian Karas (KK) <kk...@thrane.eu> wrote:
>
> > Hi community
> >
> > I have a question related to the implementation of poll() in the kernel
> > and drivers. I am implementing a driver with poll support (through
> > file_operations::poll) and have observed that "teardown" of the pollfds
> is
> > not performed if the task is killed (while task is blocked on a call to
> > poll()). Is this intended behavior?
> >
> >
> it's impossible to recover reliably before file reference count(
> https://github.com/apache/nuttx/pull/13296) is implemented.
>
>
> > As file_operations::close is called it seems possible to find and remove
> > the FD, but I cannot find any driver doing that.
>
>
> This patch was merged recently, that's why you can't find the driver handle
> close with active poll spreadly.
>
>
> > Since close is actually called on the driver, I would assume the
> intention
> > is to clean up the driver, but I find it a little inconsistent that
> > cleaning up the pollfds does not happen.
> >
> >
> Yes, https://github.com/apache/nuttx/pull/15809 is an example demo on how
> to handle close with the active poll correctly.
>
>
>
> > I am using the "flat" build configuration. The beavior may be different
> in
> > "protected" builds?
> >
> > Regards
> > Kian
> >
>
Re: Driver poll question
Posted by Xiang Xiao <xi...@gmail.com>.
How does the kernel know the killed thread is blocking in the driver's poll
method? Adding some flag in tcb_s for the special usage mayn't good.
BTW, there are many APIs that may block(e.g. write/read/send/recv), these
methods do not public callback to cancel the internal wait.
On Wed, Feb 12, 2025 at 4:10 AM Kian Karas (KK) <kk...@thrane.eu> wrote:
> Thank you for the reply Xiang and bringing the PRs to my attention.
>
> If I understand the PRs, they don't quite satisfy my concern. In my use
> case, an application is killed while blocked on a call to poll(). This
> results in a call (initiated by the kernel) to the driver's close callback
> (which is as expected). But why doesn't the kernel call the driver's poll
> callback first (before close), to do the teardown of the fds? This would
> result in the proper cleanup in the driver without requiring changes to any
> existing drivers.
>
> Regards
> Kian
> ________________________________
> From: Xiang Xiao <xi...@gmail.com>
> Sent: 11 February 2025 06:53
> To: dev@nuttx.apache.org <de...@nuttx.apache.org>
> Subject: Re: Driver poll question
>
> On Tue, Feb 11, 2025 at 2:00 AM Kian Karas (KK) <kk...@thrane.eu> wrote:
>
> > Hi community
> >
> > I have a question related to the implementation of poll() in the kernel
> > and drivers. I am implementing a driver with poll support (through
> > file_operations::poll) and have observed that "teardown" of the pollfds
> is
> > not performed if the task is killed (while task is blocked on a call to
> > poll()). Is this intended behavior?
> >
> >
> it's impossible to recover reliably before file reference count(
> https://github.com/apache/nuttx/pull/13296) is implemented.
>
>
> > As file_operations::close is called it seems possible to find and remove
> > the FD, but I cannot find any driver doing that.
>
>
> This patch was merged recently, that's why you can't find the driver handle
> close with active poll spreadly.
>
>
> > Since close is actually called on the driver, I would assume the
> intention
> > is to clean up the driver, but I find it a little inconsistent that
> > cleaning up the pollfds does not happen.
> >
> >
> Yes, https://github.com/apache/nuttx/pull/15809 is an example demo on how
> to handle close with the active poll correctly.
>
>
>
> > I am using the "flat" build configuration. The beavior may be different
> in
> > "protected" builds?
> >
> > Regards
> > Kian
> >
>
Re: Driver poll question
Posted by "Kian Karas (KK)" <kk...@thrane.eu>.
Thank you for the reply Xiang and bringing the PRs to my attention.
If I understand the PRs, they don't quite satisfy my concern. In my use case, an application is killed while blocked on a call to poll(). This results in a call (initiated by the kernel) to the driver's close callback (which is as expected). But why doesn't the kernel call the driver's poll callback first (before close), to do the teardown of the fds? This would result in the proper cleanup in the driver without requiring changes to any existing drivers.
Regards
Kian
________________________________
From: Xiang Xiao <xi...@gmail.com>
Sent: 11 February 2025 06:53
To: dev@nuttx.apache.org <de...@nuttx.apache.org>
Subject: Re: Driver poll question
On Tue, Feb 11, 2025 at 2:00 AM Kian Karas (KK) <kk...@thrane.eu> wrote:
> Hi community
>
> I have a question related to the implementation of poll() in the kernel
> and drivers. I am implementing a driver with poll support (through
> file_operations::poll) and have observed that "teardown" of the pollfds is
> not performed if the task is killed (while task is blocked on a call to
> poll()). Is this intended behavior?
>
>
it's impossible to recover reliably before file reference count(
https://github.com/apache/nuttx/pull/13296) is implemented.
> As file_operations::close is called it seems possible to find and remove
> the FD, but I cannot find any driver doing that.
This patch was merged recently, that's why you can't find the driver handle
close with active poll spreadly.
> Since close is actually called on the driver, I would assume the intention
> is to clean up the driver, but I find it a little inconsistent that
> cleaning up the pollfds does not happen.
>
>
Yes, https://github.com/apache/nuttx/pull/15809 is an example demo on how
to handle close with the active poll correctly.
> I am using the "flat" build configuration. The beavior may be different in
> "protected" builds?
>
> Regards
> Kian
>
Re: Driver poll question
Posted by Xiang Xiao <xi...@gmail.com>.
On Tue, Feb 11, 2025 at 2:00 AM Kian Karas (KK) <kk...@thrane.eu> wrote:
> Hi community
>
> I have a question related to the implementation of poll() in the kernel
> and drivers. I am implementing a driver with poll support (through
> file_operations::poll) and have observed that "teardown" of the pollfds is
> not performed if the task is killed (while task is blocked on a call to
> poll()). Is this intended behavior?
>
>
it's impossible to recover reliably before file reference count(
https://github.com/apache/nuttx/pull/13296) is implemented.
> As file_operations::close is called it seems possible to find and remove
> the FD, but I cannot find any driver doing that.
This patch was merged recently, that's why you can't find the driver handle
close with active poll spreadly.
> Since close is actually called on the driver, I would assume the intention
> is to clean up the driver, but I find it a little inconsistent that
> cleaning up the pollfds does not happen.
>
>
Yes, https://github.com/apache/nuttx/pull/15809 is an example demo on how
to handle close with the active poll correctly.
> I am using the "flat" build configuration. The beavior may be different in
> "protected" builds?
>
> Regards
> Kian
>