* [dpdk-dev] [PATCH 0/2] fix segfault seen with performance-thread example @ 2019-07-15 15:39 Erik Gabriel Carrillo 2019-07-15 15:39 ` [dpdk-dev] [PATCH 1/2] timer: fix null pointer dereference Erik Gabriel Carrillo ` (2 more replies) 0 siblings, 3 replies; 9+ messages in thread From: Erik Gabriel Carrillo @ 2019-07-15 15:39 UTC (permalink / raw) To: thomas; +Cc: dev A crash occurs in the examples/performance-thread/l3fwd-thread when it calls into rte_timer_manage() from the LThread library it utilizes. This happens because the application omitted a call to rte_timer_subsystem_init(), which leaves a pointer set to null in the timer library. This pointer is dereferenced in a check for validity of a timer data object, resulting in the segfault. This series fixes the validity check in the timer library, and adds the missing call to rte_timer_subsystem_init in the application. Erik Gabriel Carrillo (2): timer: fix null pointer dereference examples/performance-thread: init timer subsystem examples/performance-thread/l3fwd-thread/main.c | 5 +++++ lib/librte_timer/rte_timer.c | 3 ++- 2 files changed, 7 insertions(+), 1 deletion(-) -- 2.6.4 ^ permalink raw reply [flat|nested] 9+ messages in thread
* [dpdk-dev] [PATCH 1/2] timer: fix null pointer dereference 2019-07-15 15:39 [dpdk-dev] [PATCH 0/2] fix segfault seen with performance-thread example Erik Gabriel Carrillo @ 2019-07-15 15:39 ` Erik Gabriel Carrillo 2019-07-15 15:48 ` Stephen Hemminger 2019-07-15 15:39 ` [dpdk-dev] [PATCH 2/2] examples/performance-thread: init timer subsystem Erik Gabriel Carrillo 2019-07-18 21:20 ` [dpdk-dev] [PATCH 0/2] fix segfault seen with performance-thread example Thomas Monjalon 2 siblings, 1 reply; 9+ messages in thread From: Erik Gabriel Carrillo @ 2019-07-15 15:39 UTC (permalink / raw) To: thomas; +Cc: dev, stable If the timer subsystem is not initialized before rte_timer_manage (for example) is invoked, a pointer to a shared hugepage memory region will still be null and dereferenced when it is checked for validity; handle this case. Fixes: c0749f7096c7 ("timer: allow management in shared memory") Cc: stable@dpdk.org Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com> --- lib/librte_timer/rte_timer.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lib/librte_timer/rte_timer.c b/lib/librte_timer/rte_timer.c index 71dffd2..bdcf05d 100644 --- a/lib/librte_timer/rte_timer.c +++ b/lib/librte_timer/rte_timer.c @@ -85,7 +85,8 @@ static struct rte_timer_data default_timer_data; static inline int timer_data_valid(uint32_t id) { - return !!(rte_timer_data_arr[id].internal_flags & FL_ALLOCATED); + return rte_timer_data_arr && + (rte_timer_data_arr[id].internal_flags & FL_ALLOCATED); } /* validate ID and retrieve timer data pointer, or return error value */ -- 2.6.4 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [dpdk-dev] [PATCH 1/2] timer: fix null pointer dereference 2019-07-15 15:39 ` [dpdk-dev] [PATCH 1/2] timer: fix null pointer dereference Erik Gabriel Carrillo @ 2019-07-15 15:48 ` Stephen Hemminger 2019-07-15 16:04 ` Carrillo, Erik G 0 siblings, 1 reply; 9+ messages in thread From: Stephen Hemminger @ 2019-07-15 15:48 UTC (permalink / raw) To: Erik Gabriel Carrillo; +Cc: thomas, dev, stable On Mon, 15 Jul 2019 10:39:31 -0500 Erik Gabriel Carrillo <erik.g.carrillo@intel.com> wrote: > If the timer subsystem is not initialized before rte_timer_manage (for > example) is invoked, a pointer to a shared hugepage memory region will > still be null and dereferenced when it is checked for validity; handle > this case. > > Fixes: c0749f7096c7 ("timer: allow management in shared memory") > Cc: stable@dpdk.org > > Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com> I have mixed feelings about this patch. Any calls to rte_timer before rte_timer_subsystem_init is not a valid usage. Better to kill the application. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [dpdk-dev] [PATCH 1/2] timer: fix null pointer dereference 2019-07-15 15:48 ` Stephen Hemminger @ 2019-07-15 16:04 ` Carrillo, Erik G 2019-07-15 19:48 ` Carrillo, Erik G 0 siblings, 1 reply; 9+ messages in thread From: Carrillo, Erik G @ 2019-07-15 16:04 UTC (permalink / raw) To: Stephen Hemminger; +Cc: thomas, dev, stable Hi Stephen, > -----Original Message----- > From: Stephen Hemminger <stephen@networkplumber.org> > Sent: Monday, July 15, 2019 10:49 AM > To: Carrillo, Erik G <erik.g.carrillo@intel.com> > Cc: thomas@monjalon.net; dev@dpdk.org; stable@dpdk.org > Subject: Re: [dpdk-dev] [PATCH 1/2] timer: fix null pointer dereference > > On Mon, 15 Jul 2019 10:39:31 -0500 > Erik Gabriel Carrillo <erik.g.carrillo@intel.com> wrote: > > > If the timer subsystem is not initialized before rte_timer_manage (for > > example) is invoked, a pointer to a shared hugepage memory region will > > still be null and dereferenced when it is checked for validity; handle > > this case. > > > > Fixes: c0749f7096c7 ("timer: allow management in shared memory") > > Cc: stable@dpdk.org > > > > Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com> > > I have mixed feelings about this patch. > Any calls to rte_timer before rte_timer_subsystem_init is not a valid usage. > Better to kill the application. Ok, that sounds like a better approach. I'll update the patch and resubmit. Thanks, Erik ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [dpdk-dev] [PATCH 1/2] timer: fix null pointer dereference 2019-07-15 16:04 ` Carrillo, Erik G @ 2019-07-15 19:48 ` Carrillo, Erik G 2019-07-16 8:31 ` Bruce Richardson 0 siblings, 1 reply; 9+ messages in thread From: Carrillo, Erik G @ 2019-07-15 19:48 UTC (permalink / raw) To: 'Stephen Hemminger' Cc: 'thomas@monjalon.net', 'dev@dpdk.org' > -----Original Message----- > From: Carrillo, Erik G > Sent: Monday, July 15, 2019 11:04 AM > To: Stephen Hemminger <stephen@networkplumber.org> > Cc: thomas@monjalon.net; dev@dpdk.org; stable@dpdk.org > Subject: RE: [dpdk-dev] [PATCH 1/2] timer: fix null pointer dereference > > Hi Stephen, > > > -----Original Message----- > > From: Stephen Hemminger <stephen@networkplumber.org> > > Sent: Monday, July 15, 2019 10:49 AM > > To: Carrillo, Erik G <erik.g.carrillo@intel.com> > > Cc: thomas@monjalon.net; dev@dpdk.org; stable@dpdk.org > > Subject: Re: [dpdk-dev] [PATCH 1/2] timer: fix null pointer > > dereference > > > > On Mon, 15 Jul 2019 10:39:31 -0500 > > Erik Gabriel Carrillo <erik.g.carrillo@intel.com> wrote: > > > > > If the timer subsystem is not initialized before rte_timer_manage > > > (for > > > example) is invoked, a pointer to a shared hugepage memory region > > > will still be null and dereferenced when it is checked for validity; > > > handle this case. > > > > > > Fixes: c0749f7096c7 ("timer: allow management in shared memory") > > > Cc: stable@dpdk.org > > > > > > Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com> > > > > I have mixed feelings about this patch. > > Any calls to rte_timer before rte_timer_subsystem_init is not a valid usage. > > Better to kill the application. > > Ok, that sounds like a better approach. I'll update the patch and resubmit. > I added a call to rte_exit() in the timer_data_valid() function for the case where the library is uninitialized, but checkpatches.sh issues the following warning: "Warning in /lib/librte_timer/rte_timer.c: Using rte_panic/rte_exit" According to the comments in the script, we should refrain from new additions of rte_panic() and rte_exit() in the lib subtree. In light of this, should we still proceed with this approach? It does seem like it would be useful. Thanks, Erik > Thanks, > Erik ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [dpdk-dev] [PATCH 1/2] timer: fix null pointer dereference 2019-07-15 19:48 ` Carrillo, Erik G @ 2019-07-16 8:31 ` Bruce Richardson 2019-07-16 14:58 ` Carrillo, Erik G 0 siblings, 1 reply; 9+ messages in thread From: Bruce Richardson @ 2019-07-16 8:31 UTC (permalink / raw) To: Carrillo, Erik G Cc: 'Stephen Hemminger', 'thomas@monjalon.net', 'dev@dpdk.org' On Mon, Jul 15, 2019 at 07:48:09PM +0000, Carrillo, Erik G wrote: > > -----Original Message----- > > From: Carrillo, Erik G > > Sent: Monday, July 15, 2019 11:04 AM > > To: Stephen Hemminger <stephen@networkplumber.org> > > Cc: thomas@monjalon.net; dev@dpdk.org; stable@dpdk.org > > Subject: RE: [dpdk-dev] [PATCH 1/2] timer: fix null pointer dereference > > > > Hi Stephen, > > > > > -----Original Message----- > > > From: Stephen Hemminger <stephen@networkplumber.org> > > > Sent: Monday, July 15, 2019 10:49 AM > > > To: Carrillo, Erik G <erik.g.carrillo@intel.com> > > > Cc: thomas@monjalon.net; dev@dpdk.org; stable@dpdk.org > > > Subject: Re: [dpdk-dev] [PATCH 1/2] timer: fix null pointer > > > dereference > > > > > > On Mon, 15 Jul 2019 10:39:31 -0500 > > > Erik Gabriel Carrillo <erik.g.carrillo@intel.com> wrote: > > > > > > > If the timer subsystem is not initialized before rte_timer_manage > > > > (for > > > > example) is invoked, a pointer to a shared hugepage memory region > > > > will still be null and dereferenced when it is checked for validity; > > > > handle this case. > > > > > > > > Fixes: c0749f7096c7 ("timer: allow management in shared memory") > > > > Cc: stable@dpdk.org > > > > > > > > Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com> > > > > > > I have mixed feelings about this patch. > > > Any calls to rte_timer before rte_timer_subsystem_init is not a valid usage. > > > Better to kill the application. > > > > Ok, that sounds like a better approach. I'll update the patch and resubmit. > > > > I added a call to rte_exit() in the timer_data_valid() function for the case where the library is uninitialized, but checkpatches.sh issues the following warning: > > "Warning in /lib/librte_timer/rte_timer.c: > Using rte_panic/rte_exit" > > According to the comments in the script, we should refrain from new additions of rte_panic() and rte_exit() in the lib subtree. In light of this, should we still proceed with this approach? It does seem like it would be useful. > I don't think we should ever put panics or exits in our library code, so I think the immediate choices are to either leave things as-is and allow app to crash for invalid use, or else catch the error and return a suitable error code to the user. I think I'd prefer the latter. However, given that the error condition is not having the timer subsystem initialized, is there the possibility of a third option to just go and initialize before continuing in the timer_manage() function? ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [dpdk-dev] [PATCH 1/2] timer: fix null pointer dereference 2019-07-16 8:31 ` Bruce Richardson @ 2019-07-16 14:58 ` Carrillo, Erik G 0 siblings, 0 replies; 9+ messages in thread From: Carrillo, Erik G @ 2019-07-16 14:58 UTC (permalink / raw) To: Richardson, Bruce Cc: 'Stephen Hemminger', 'thomas@monjalon.net', 'dev@dpdk.org' > -----Original Message----- > From: Bruce Richardson <bruce.richardson@intel.com> > Sent: Tuesday, July 16, 2019 3:31 AM > To: Carrillo, Erik G <erik.g.carrillo@intel.com> > Cc: 'Stephen Hemminger' <stephen@networkplumber.org>; > 'thomas@monjalon.net' <thomas@monjalon.net>; 'dev@dpdk.org' > <dev@dpdk.org> > Subject: Re: [dpdk-dev] [PATCH 1/2] timer: fix null pointer dereference > > On Mon, Jul 15, 2019 at 07:48:09PM +0000, Carrillo, Erik G wrote: > > > -----Original Message----- > > > From: Carrillo, Erik G > > > Sent: Monday, July 15, 2019 11:04 AM > > > To: Stephen Hemminger <stephen@networkplumber.org> > > > Cc: thomas@monjalon.net; dev@dpdk.org; stable@dpdk.org > > > Subject: RE: [dpdk-dev] [PATCH 1/2] timer: fix null pointer > > > dereference > > > > > > Hi Stephen, > > > > > > > -----Original Message----- > > > > From: Stephen Hemminger <stephen@networkplumber.org> > > > > Sent: Monday, July 15, 2019 10:49 AM > > > > To: Carrillo, Erik G <erik.g.carrillo@intel.com> > > > > Cc: thomas@monjalon.net; dev@dpdk.org; stable@dpdk.org > > > > Subject: Re: [dpdk-dev] [PATCH 1/2] timer: fix null pointer > > > > dereference > > > > > > > > On Mon, 15 Jul 2019 10:39:31 -0500 Erik Gabriel Carrillo > > > > <erik.g.carrillo@intel.com> wrote: > > > > > > > > > If the timer subsystem is not initialized before > > > > > rte_timer_manage (for > > > > > example) is invoked, a pointer to a shared hugepage memory > > > > > region will still be null and dereferenced when it is checked > > > > > for validity; handle this case. > > > > > > > > > > Fixes: c0749f7096c7 ("timer: allow management in shared memory") > > > > > Cc: stable@dpdk.org > > > > > > > > > > Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com> > > > > > > > > I have mixed feelings about this patch. > > > > Any calls to rte_timer before rte_timer_subsystem_init is not a valid > usage. > > > > Better to kill the application. > > > > > > Ok, that sounds like a better approach. I'll update the patch and > resubmit. > > > > > > > I added a call to rte_exit() in the timer_data_valid() function for the case > where the library is uninitialized, but checkpatches.sh issues the following > warning: > > > > "Warning in /lib/librte_timer/rte_timer.c: > > Using rte_panic/rte_exit" > > > > According to the comments in the script, we should refrain from new > additions of rte_panic() and rte_exit() in the lib subtree. In light of this, > should we still proceed with this approach? It does seem like it would be > useful. > > > > I don't think we should ever put panics or exits in our library code, so I think > the immediate choices are to either leave things as-is and allow app to crash > for invalid use, or else catch the error and return a suitable error code to the > user. I think I'd prefer the latter. > In that case, I'd like to keep the current patch out for consideration. It detects the error and enables the library APIs to return an error code to the user. > However, given that the error condition is not having the timer subsystem > initialized, is there the possibility of a third option to just go and initialize > before continuing in the timer_manage() function? It seems like this could work, but I'd like to hold off for more investigation. Thanks, Erik ^ permalink raw reply [flat|nested] 9+ messages in thread
* [dpdk-dev] [PATCH 2/2] examples/performance-thread: init timer subsystem 2019-07-15 15:39 [dpdk-dev] [PATCH 0/2] fix segfault seen with performance-thread example Erik Gabriel Carrillo 2019-07-15 15:39 ` [dpdk-dev] [PATCH 1/2] timer: fix null pointer dereference Erik Gabriel Carrillo @ 2019-07-15 15:39 ` Erik Gabriel Carrillo 2019-07-18 21:20 ` [dpdk-dev] [PATCH 0/2] fix segfault seen with performance-thread example Thomas Monjalon 2 siblings, 0 replies; 9+ messages in thread From: Erik Gabriel Carrillo @ 2019-07-15 15:39 UTC (permalink / raw) To: thomas; +Cc: dev, stable, ian.betts The timer subsystem should be initialized in the l3fwd-thread app before the L-thread subsystem can be used. Fixes: d48415e1fee3 ("examples/performance-thread: add l3fwd-thread app") Cc: stable@dpdk.org Cc: ian.betts@intel.com Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com> --- examples/performance-thread/l3fwd-thread/main.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/examples/performance-thread/l3fwd-thread/main.c b/examples/performance-thread/l3fwd-thread/main.c index dd46895..c4065e8 100644 --- a/examples/performance-thread/l3fwd-thread/main.c +++ b/examples/performance-thread/l3fwd-thread/main.c @@ -40,6 +40,7 @@ #include <rte_udp.h> #include <rte_string_fns.h> #include <rte_pause.h> +#include <rte_timer.h> #include <cmdline_parse.h> #include <cmdline_parse_etheraddr.h> @@ -3497,6 +3498,10 @@ main(int argc, char **argv) argc -= ret; argv += ret; + ret = rte_timer_subsystem_init(); + if (ret < 0) + rte_exit(EXIT_FAILURE, "Failed to initialize timer subystem\n"); + /* pre-init dst MACs for all ports to 02:00:00:00:00:xx */ for (portid = 0; portid < RTE_MAX_ETHPORTS; portid++) { dest_eth_addr[portid] = RTE_ETHER_LOCAL_ADMIN_ADDR + -- 2.6.4 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [dpdk-dev] [PATCH 0/2] fix segfault seen with performance-thread example 2019-07-15 15:39 [dpdk-dev] [PATCH 0/2] fix segfault seen with performance-thread example Erik Gabriel Carrillo 2019-07-15 15:39 ` [dpdk-dev] [PATCH 1/2] timer: fix null pointer dereference Erik Gabriel Carrillo 2019-07-15 15:39 ` [dpdk-dev] [PATCH 2/2] examples/performance-thread: init timer subsystem Erik Gabriel Carrillo @ 2019-07-18 21:20 ` Thomas Monjalon 2 siblings, 0 replies; 9+ messages in thread From: Thomas Monjalon @ 2019-07-18 21:20 UTC (permalink / raw) To: Erik Gabriel Carrillo; +Cc: dev 15/07/2019 17:39, Erik Gabriel Carrillo: > A crash occurs in the examples/performance-thread/l3fwd-thread when it calls > into rte_timer_manage() from the LThread library it utilizes. This happens > because the application omitted a call to rte_timer_subsystem_init(), which > leaves a pointer set to null in the timer library. This pointer is > dereferenced in a check for validity of a timer data object, resulting in > the segfault. This series fixes the validity check in the timer library, > and adds the missing call to rte_timer_subsystem_init in the application. > > Erik Gabriel Carrillo (2): > timer: fix null pointer dereference > examples/performance-thread: init timer subsystem Applied, thanks ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2019-07-18 21:20 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-07-15 15:39 [dpdk-dev] [PATCH 0/2] fix segfault seen with performance-thread example Erik Gabriel Carrillo 2019-07-15 15:39 ` [dpdk-dev] [PATCH 1/2] timer: fix null pointer dereference Erik Gabriel Carrillo 2019-07-15 15:48 ` Stephen Hemminger 2019-07-15 16:04 ` Carrillo, Erik G 2019-07-15 19:48 ` Carrillo, Erik G 2019-07-16 8:31 ` Bruce Richardson 2019-07-16 14:58 ` Carrillo, Erik G 2019-07-15 15:39 ` [dpdk-dev] [PATCH 2/2] examples/performance-thread: init timer subsystem Erik Gabriel Carrillo 2019-07-18 21:20 ` [dpdk-dev] [PATCH 0/2] fix segfault seen with performance-thread example Thomas Monjalon
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).