* [PATCH net] tipc: not enable tipc when ipv6 works as a module @ 2020-08-16 9:32 Xin Long 2020-08-16 18:29 ` Cong Wang 2020-08-17 4:05 ` David Miller 0 siblings, 2 replies; 18+ messages in thread From: Xin Long @ 2020-08-16 9:32 UTC (permalink / raw) To: network dev; +Cc: davem, Jon Maloy, Ying Xue, tipc-discussion, Randy Dunlap When using ipv6_dev_find() in one module, it requires ipv6 not to work as a module. Otherwise, this error occurs in build: undefined reference to `ipv6_dev_find'. So fix it by adding "depends on IPV6 || IPV6=n" to tipc/Kconfig, as it does in sctp/Kconfig. Fixes: 5a6f6f579178 ("tipc: set ub->ifindex for local ipv6 address") Reported-by: kernel test robot <lkp@intel.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Xin Long <lucien.xin@gmail.com> --- net/tipc/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/net/tipc/Kconfig b/net/tipc/Kconfig index 9dd7802..be1c400 100644 --- a/net/tipc/Kconfig +++ b/net/tipc/Kconfig @@ -6,6 +6,7 @@ menuconfig TIPC tristate "The TIPC Protocol" depends on INET + depends on IPV6 || IPV6=n help The Transparent Inter Process Communication (TIPC) protocol is specially designed for intra cluster communication. This protocol -- 2.1.0 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [PATCH net] tipc: not enable tipc when ipv6 works as a module 2020-08-16 9:32 [PATCH net] tipc: not enable tipc when ipv6 works as a module Xin Long @ 2020-08-16 18:29 ` Cong Wang 2020-08-17 6:49 ` Xin Long 2020-08-17 4:05 ` David Miller 1 sibling, 1 reply; 18+ messages in thread From: Cong Wang @ 2020-08-16 18:29 UTC (permalink / raw) To: Xin Long Cc: network dev, David Miller, Jon Maloy, Ying Xue, tipc-discussion, Randy Dunlap On Sun, Aug 16, 2020 at 4:54 AM Xin Long <lucien.xin@gmail.com> wrote: > > When using ipv6_dev_find() in one module, it requires ipv6 not to > work as a module. Otherwise, this error occurs in build: > > undefined reference to `ipv6_dev_find'. > > So fix it by adding "depends on IPV6 || IPV6=n" to tipc/Kconfig, > as it does in sctp/Kconfig. Or put it into struct ipv6_stub? ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH net] tipc: not enable tipc when ipv6 works as a module 2020-08-16 18:29 ` Cong Wang @ 2020-08-17 6:49 ` Xin Long 2020-08-17 18:31 ` Cong Wang 0 siblings, 1 reply; 18+ messages in thread From: Xin Long @ 2020-08-17 6:49 UTC (permalink / raw) To: Cong Wang Cc: network dev, David Miller, Jon Maloy, Ying Xue, tipc-discussion, Randy Dunlap On Mon, Aug 17, 2020 at 2:29 AM Cong Wang <xiyou.wangcong@gmail.com> wrote: > > On Sun, Aug 16, 2020 at 4:54 AM Xin Long <lucien.xin@gmail.com> wrote: > > > > When using ipv6_dev_find() in one module, it requires ipv6 not to > > work as a module. Otherwise, this error occurs in build: > > > > undefined reference to `ipv6_dev_find'. > > > > So fix it by adding "depends on IPV6 || IPV6=n" to tipc/Kconfig, > > as it does in sctp/Kconfig. > > Or put it into struct ipv6_stub? Hi Cong, That could be one way. We may do it when this new function becomes more common. By now, I think it's okay to make TIPC depend on IPV6 || IPV6=n. Thanks. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH net] tipc: not enable tipc when ipv6 works as a module 2020-08-17 6:49 ` Xin Long @ 2020-08-17 18:31 ` Cong Wang 2020-08-17 18:49 ` Randy Dunlap 0 siblings, 1 reply; 18+ messages in thread From: Cong Wang @ 2020-08-17 18:31 UTC (permalink / raw) To: Xin Long Cc: network dev, David Miller, Jon Maloy, Ying Xue, tipc-discussion, Randy Dunlap On Sun, Aug 16, 2020 at 11:37 PM Xin Long <lucien.xin@gmail.com> wrote: > > On Mon, Aug 17, 2020 at 2:29 AM Cong Wang <xiyou.wangcong@gmail.com> wrote: > > > > Or put it into struct ipv6_stub? > Hi Cong, > > That could be one way. We may do it when this new function becomes more common. > By now, I think it's okay to make TIPC depend on IPV6 || IPV6=n. I am not a fan of IPV6=m, but disallowing it for one symbol seems too harsh. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH net] tipc: not enable tipc when ipv6 works as a module 2020-08-17 18:31 ` Cong Wang @ 2020-08-17 18:49 ` Randy Dunlap 2020-08-17 18:55 ` Cong Wang 0 siblings, 1 reply; 18+ messages in thread From: Randy Dunlap @ 2020-08-17 18:49 UTC (permalink / raw) To: Cong Wang, Xin Long Cc: network dev, David Miller, Jon Maloy, Ying Xue, tipc-discussion On 8/17/20 11:31 AM, Cong Wang wrote: > On Sun, Aug 16, 2020 at 11:37 PM Xin Long <lucien.xin@gmail.com> wrote: >> >> On Mon, Aug 17, 2020 at 2:29 AM Cong Wang <xiyou.wangcong@gmail.com> wrote: >>> >>> Or put it into struct ipv6_stub? >> Hi Cong, >> >> That could be one way. We may do it when this new function becomes more common. >> By now, I think it's okay to make TIPC depend on IPV6 || IPV6=n. > > I am not a fan of IPV6=m, but disallowing it for one symbol seems > too harsh. Hi, Maybe I'm not following you, but this doesn't disallow IPV6=m. It just restricts how TIPC can be built, so that TIPC=y and IPV6=m cannot happen together, which causes a build error. -- ~Randy ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH net] tipc: not enable tipc when ipv6 works as a module 2020-08-17 18:49 ` Randy Dunlap @ 2020-08-17 18:55 ` Cong Wang 2020-08-17 19:00 ` Randy Dunlap 2020-08-17 21:34 ` David Miller 0 siblings, 2 replies; 18+ messages in thread From: Cong Wang @ 2020-08-17 18:55 UTC (permalink / raw) To: Randy Dunlap Cc: Xin Long, network dev, David Miller, Jon Maloy, Ying Xue, tipc-discussion On Mon, Aug 17, 2020 at 11:49 AM Randy Dunlap <rdunlap@infradead.org> wrote: > > On 8/17/20 11:31 AM, Cong Wang wrote: > > On Sun, Aug 16, 2020 at 11:37 PM Xin Long <lucien.xin@gmail.com> wrote: > >> > >> On Mon, Aug 17, 2020 at 2:29 AM Cong Wang <xiyou.wangcong@gmail.com> wrote: > >>> > >>> Or put it into struct ipv6_stub? > >> Hi Cong, > >> > >> That could be one way. We may do it when this new function becomes more common. > >> By now, I think it's okay to make TIPC depend on IPV6 || IPV6=n. > > > > I am not a fan of IPV6=m, but disallowing it for one symbol seems > > too harsh. > > Hi, > > Maybe I'm not following you, but this doesn't disallow IPV6=m. Well, by "disallowing IPV6=m" I meant "disallowing IPV6=m when enabling TIPC" for sure... Sorry that it misleads you to believe completely disallowing IPV6=m globally. > > It just restricts how TIPC can be built, so that > TIPC=y and IPV6=m cannot happen together, which causes > a build error. It also disallows TIPC=m and IPV6=m, right? In short, it disalows IPV6=m when TIPC is enabled. And this is exactly what I complain, as it looks too harsh. Thanks. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH net] tipc: not enable tipc when ipv6 works as a module 2020-08-17 18:55 ` Cong Wang @ 2020-08-17 19:00 ` Randy Dunlap 2020-08-17 19:26 ` Cong Wang 2020-08-17 21:34 ` David Miller 1 sibling, 1 reply; 18+ messages in thread From: Randy Dunlap @ 2020-08-17 19:00 UTC (permalink / raw) To: Cong Wang Cc: Xin Long, network dev, David Miller, Jon Maloy, Ying Xue, tipc-discussion On 8/17/20 11:55 AM, Cong Wang wrote: > On Mon, Aug 17, 2020 at 11:49 AM Randy Dunlap <rdunlap@infradead.org> wrote: >> >> On 8/17/20 11:31 AM, Cong Wang wrote: >>> On Sun, Aug 16, 2020 at 11:37 PM Xin Long <lucien.xin@gmail.com> wrote: >>>> >>>> On Mon, Aug 17, 2020 at 2:29 AM Cong Wang <xiyou.wangcong@gmail.com> wrote: >>>>> >>>>> Or put it into struct ipv6_stub? >>>> Hi Cong, >>>> >>>> That could be one way. We may do it when this new function becomes more common. >>>> By now, I think it's okay to make TIPC depend on IPV6 || IPV6=n. >>> >>> I am not a fan of IPV6=m, but disallowing it for one symbol seems >>> too harsh. >> >> Hi, >> >> Maybe I'm not following you, but this doesn't disallow IPV6=m. > > Well, by "disallowing IPV6=m" I meant "disallowing IPV6=m when > enabling TIPC" for sure... Sorry that it misleads you to believe > completely disallowing IPV6=m globally. > >> >> It just restricts how TIPC can be built, so that >> TIPC=y and IPV6=m cannot happen together, which causes >> a build error. > > It also disallows TIPC=m and IPV6=m, right? In short, it disalows > IPV6=m when TIPC is enabled. And this is exactly what I complain, > as it looks too harsh. I haven't tested that specifically, but that should work. This patch won't prevent that from working. We have loadable modules calling other loadable modules all over the kernel. -- ~Randy ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH net] tipc: not enable tipc when ipv6 works as a module 2020-08-17 19:00 ` Randy Dunlap @ 2020-08-17 19:26 ` Cong Wang 2020-08-17 19:55 ` Randy Dunlap 0 siblings, 1 reply; 18+ messages in thread From: Cong Wang @ 2020-08-17 19:26 UTC (permalink / raw) To: Randy Dunlap Cc: Xin Long, network dev, David Miller, Jon Maloy, Ying Xue, tipc-discussion On Mon, Aug 17, 2020 at 12:00 PM Randy Dunlap <rdunlap@infradead.org> wrote: > > On 8/17/20 11:55 AM, Cong Wang wrote: > > On Mon, Aug 17, 2020 at 11:49 AM Randy Dunlap <rdunlap@infradead.org> wrote: > >> > >> On 8/17/20 11:31 AM, Cong Wang wrote: > >>> On Sun, Aug 16, 2020 at 11:37 PM Xin Long <lucien.xin@gmail.com> wrote: > >>>> > >>>> On Mon, Aug 17, 2020 at 2:29 AM Cong Wang <xiyou.wangcong@gmail.com> wrote: > >>>>> > >>>>> Or put it into struct ipv6_stub? > >>>> Hi Cong, > >>>> > >>>> That could be one way. We may do it when this new function becomes more common. > >>>> By now, I think it's okay to make TIPC depend on IPV6 || IPV6=n. > >>> > >>> I am not a fan of IPV6=m, but disallowing it for one symbol seems > >>> too harsh. > >> > >> Hi, > >> > >> Maybe I'm not following you, but this doesn't disallow IPV6=m. > > > > Well, by "disallowing IPV6=m" I meant "disallowing IPV6=m when > > enabling TIPC" for sure... Sorry that it misleads you to believe > > completely disallowing IPV6=m globally. > > > >> > >> It just restricts how TIPC can be built, so that > >> TIPC=y and IPV6=m cannot happen together, which causes > >> a build error. > > > > It also disallows TIPC=m and IPV6=m, right? In short, it disalows > > IPV6=m when TIPC is enabled. And this is exactly what I complain, > > as it looks too harsh. > > I haven't tested that specifically, but that should work. > This patch won't prevent that from working. Please give it a try. I do not see how it allows IPV6=m and TIPC=m but disallows IPV6=m and TIPC=y. > > We have loadable modules calling other loadable modules > all over the kernel. True, we rely on request_module(). But I do not see TIPC calls request_module() to request IPV6 module to load "ipv6_dev_find". Thanks. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH net] tipc: not enable tipc when ipv6 works as a module 2020-08-17 19:26 ` Cong Wang @ 2020-08-17 19:55 ` Randy Dunlap 2020-08-17 20:29 ` Cong Wang 0 siblings, 1 reply; 18+ messages in thread From: Randy Dunlap @ 2020-08-17 19:55 UTC (permalink / raw) To: Cong Wang Cc: Xin Long, network dev, David Miller, Jon Maloy, Ying Xue, tipc-discussion On 8/17/20 12:26 PM, Cong Wang wrote: > On Mon, Aug 17, 2020 at 12:00 PM Randy Dunlap <rdunlap@infradead.org> wrote: >> >> On 8/17/20 11:55 AM, Cong Wang wrote: >>> On Mon, Aug 17, 2020 at 11:49 AM Randy Dunlap <rdunlap@infradead.org> wrote: >>>> >>>> On 8/17/20 11:31 AM, Cong Wang wrote: >>>>> On Sun, Aug 16, 2020 at 11:37 PM Xin Long <lucien.xin@gmail.com> wrote: >>>>>> >>>>>> On Mon, Aug 17, 2020 at 2:29 AM Cong Wang <xiyou.wangcong@gmail.com> wrote: >>>>>>> >>>>>>> Or put it into struct ipv6_stub? >>>>>> Hi Cong, >>>>>> >>>>>> That could be one way. We may do it when this new function becomes more common. >>>>>> By now, I think it's okay to make TIPC depend on IPV6 || IPV6=n. >>>>> >>>>> I am not a fan of IPV6=m, but disallowing it for one symbol seems >>>>> too harsh. >>>> >>>> Hi, >>>> >>>> Maybe I'm not following you, but this doesn't disallow IPV6=m. >>> >>> Well, by "disallowing IPV6=m" I meant "disallowing IPV6=m when >>> enabling TIPC" for sure... Sorry that it misleads you to believe >>> completely disallowing IPV6=m globally. >>> >>>> >>>> It just restricts how TIPC can be built, so that >>>> TIPC=y and IPV6=m cannot happen together, which causes >>>> a build error. >>> >>> It also disallows TIPC=m and IPV6=m, right? In short, it disalows >>> IPV6=m when TIPC is enabled. And this is exactly what I complain, >>> as it looks too harsh. >> >> I haven't tested that specifically, but that should work. >> This patch won't prevent that from working. > > Please give it a try. I do not see how it allows IPV6=m and TIPC=m > but disallows IPV6=m and TIPC=y. TIPC=m and IPV6=m builds just fine. Having tipc autoload ipv6 is a different problem. (IMO) This Kconfig entry: menuconfig TIPC tristate "The TIPC Protocol" depends on INET + depends on IPV6 || IPV6=n says: If IPV6=n, TIPC can be y/m/n. If IPV6=y/m, TIPC is limited to whatever IPV6 is set to. TIPC cannot be =y unless IPV6=y. >> We have loadable modules calling other loadable modules >> all over the kernel. > > True, we rely on request_module(). But I do not see TIPC calls > request_module() to request IPV6 module to load "ipv6_dev_find". -- ~Randy ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH net] tipc: not enable tipc when ipv6 works as a module 2020-08-17 19:55 ` Randy Dunlap @ 2020-08-17 20:29 ` Cong Wang 2020-08-17 20:43 ` Randy Dunlap 2020-08-17 21:37 ` David Miller 0 siblings, 2 replies; 18+ messages in thread From: Cong Wang @ 2020-08-17 20:29 UTC (permalink / raw) To: Randy Dunlap Cc: Xin Long, network dev, David Miller, Jon Maloy, Ying Xue, tipc-discussion On Mon, Aug 17, 2020 at 12:55 PM Randy Dunlap <rdunlap@infradead.org> wrote: > > TIPC=m and IPV6=m builds just fine. > > Having tipc autoload ipv6 is a different problem. (IMO) > > > This Kconfig entry: > menuconfig TIPC > tristate "The TIPC Protocol" > depends on INET > + depends on IPV6 || IPV6=n > > says: > If IPV6=n, TIPC can be y/m/n. > If IPV6=y/m, TIPC is limited to whatever IPV6 is set to. Hmm, nowadays we _do_ have IPV6=y on popular distros. So this means TIPC would have to be builtin after this patch?? Still sounds harsh, right? At least on my OpenSUSE I have CONFIG_IPV6=y and CONFIG_TIPC=m. > TIPC cannot be =y unless IPV6=y. Interesting, I never correctly understand that "depends on" behavior. But even if it builds, how could TIPC module find and load IPV6 module? Does IPV6 module automatically become its dependency now I think? Thanks. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH net] tipc: not enable tipc when ipv6 works as a module 2020-08-17 20:29 ` Cong Wang @ 2020-08-17 20:43 ` Randy Dunlap 2020-08-17 20:59 ` Cong Wang 2020-08-17 21:37 ` David Miller 1 sibling, 1 reply; 18+ messages in thread From: Randy Dunlap @ 2020-08-17 20:43 UTC (permalink / raw) To: Cong Wang Cc: Xin Long, network dev, David Miller, Jon Maloy, Ying Xue, tipc-discussion On 8/17/20 1:29 PM, Cong Wang wrote: > On Mon, Aug 17, 2020 at 12:55 PM Randy Dunlap <rdunlap@infradead.org> wrote: >> >> TIPC=m and IPV6=m builds just fine. >> >> Having tipc autoload ipv6 is a different problem. (IMO) >> >> >> This Kconfig entry: >> menuconfig TIPC >> tristate "The TIPC Protocol" >> depends on INET >> + depends on IPV6 || IPV6=n >> >> says: >> If IPV6=n, TIPC can be y/m/n. >> If IPV6=y/m, TIPC is limited to whatever IPV6 is set to. > > Hmm, nowadays we _do_ have IPV6=y on popular distros. > So this means TIPC would have to be builtin after this patch?? No, it does not mean that. We can still have IPV6=y and TIPC=m. Hm, maybe I should have said this instead: If IPV6=y/m, TIPC is limited _by_ whatever IPV6 is set to. (instead of _to_ ) Does that help any? The "limited" in Kconfig rules is a "less than or equal to" limit, where 'm' < 'y'. > Still sounds harsh, right? > > At least on my OpenSUSE I have CONFIG_IPV6=y and > CONFIG_TIPC=m. > >> TIPC cannot be =y unless IPV6=y. > > Interesting, I never correctly understand that "depends on" > behavior. > > But even if it builds, how could TIPC module find and load > IPV6 module? Does IPV6 module automatically become its > dependency now I think? Sorry, I don't know about this. -- ~Randy ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH net] tipc: not enable tipc when ipv6 works as a module 2020-08-17 20:43 ` Randy Dunlap @ 2020-08-17 20:59 ` Cong Wang 2020-08-17 21:39 ` David Miller 0 siblings, 1 reply; 18+ messages in thread From: Cong Wang @ 2020-08-17 20:59 UTC (permalink / raw) To: Randy Dunlap Cc: Xin Long, network dev, David Miller, Jon Maloy, Ying Xue, tipc-discussion On Mon, Aug 17, 2020 at 1:43 PM Randy Dunlap <rdunlap@infradead.org> wrote: > > On 8/17/20 1:29 PM, Cong Wang wrote: > > On Mon, Aug 17, 2020 at 12:55 PM Randy Dunlap <rdunlap@infradead.org> wrote: > >> > >> TIPC=m and IPV6=m builds just fine. > >> > >> Having tipc autoload ipv6 is a different problem. (IMO) > >> > >> > >> This Kconfig entry: > >> menuconfig TIPC > >> tristate "The TIPC Protocol" > >> depends on INET > >> + depends on IPV6 || IPV6=n > >> > >> says: > >> If IPV6=n, TIPC can be y/m/n. > >> If IPV6=y/m, TIPC is limited to whatever IPV6 is set to. > > > > Hmm, nowadays we _do_ have IPV6=y on popular distros. > > So this means TIPC would have to be builtin after this patch?? > > No, it does not mean that. We can still have IPV6=y and TIPC=m. > > Hm, maybe I should have said this instead: > > If IPV6=y/m, TIPC is limited _by_ whatever IPV6 is set to. > (instead of _to_ ) > > Does that help any? > > The "limited" in Kconfig rules is a "less than or equal to" > limit, where 'm' < 'y'. Yeah, this is more clear now. If so, that means all the symbols we have in ipv6_stub can be gone now, assuming module dependency is automatically solved when both are modules. Is this a new Kconfig feature? ipv6_stub was introduced for VXLAN, at that time I don't remember we have such kind of Kconfig rules, otherwise it would not be needed. I also glanced at Documentation/kbuild/kconfig-language.txt, I do not see such a rule, I guess the doc is not updated. > > Still sounds harsh, right? > > > > At least on my OpenSUSE I have CONFIG_IPV6=y and > > CONFIG_TIPC=m. > > > >> TIPC cannot be =y unless IPV6=y. > > > > Interesting, I never correctly understand that "depends on" > > behavior. > > > > But even if it builds, how could TIPC module find and load > > IPV6 module? Does IPV6 module automatically become its > > dependency now I think? > > Sorry, I don't know about this. You can check `modinfo tipc` output after compiling both as modules. (Sorry that I only have CONFIG_MODULES=n here.) Thanks. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH net] tipc: not enable tipc when ipv6 works as a module 2020-08-17 20:59 ` Cong Wang @ 2020-08-17 21:39 ` David Miller 2020-08-17 22:20 ` Cong Wang 0 siblings, 1 reply; 18+ messages in thread From: David Miller @ 2020-08-17 21:39 UTC (permalink / raw) To: xiyou.wangcong Cc: rdunlap, lucien.xin, netdev, jmaloy, ying.xue, tipc-discussion From: Cong Wang <xiyou.wangcong@gmail.com> Date: Mon, 17 Aug 2020 13:59:46 -0700 > Is this a new Kconfig feature? ipv6_stub was introduced for > VXLAN, at that time I don't remember we have such kind of > Kconfig rules, otherwise it would not be needed. The ipv6_stub exists in order to allow the troublesome "ipv6=m && feature_using_ipv6=y" combination. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH net] tipc: not enable tipc when ipv6 works as a module 2020-08-17 21:39 ` David Miller @ 2020-08-17 22:20 ` Cong Wang 2020-08-18 7:59 ` Xin Long 0 siblings, 1 reply; 18+ messages in thread From: Cong Wang @ 2020-08-17 22:20 UTC (permalink / raw) To: David Miller Cc: Randy Dunlap, lucien xin, Linux Kernel Network Developers, Jon Maloy, Ying Xue, tipc-discussion On Mon, Aug 17, 2020 at 2:39 PM David Miller <davem@davemloft.net> wrote: > > From: Cong Wang <xiyou.wangcong@gmail.com> > Date: Mon, 17 Aug 2020 13:59:46 -0700 > > > Is this a new Kconfig feature? ipv6_stub was introduced for > > VXLAN, at that time I don't remember we have such kind of > > Kconfig rules, otherwise it would not be needed. > > The ipv6_stub exists in order to allow the troublesome > "ipv6=m && feature_using_ipv6=y" combination. Hmm, so "IPV6=m && TIPC=y" is not a concern here as you pick this patch over adding a ipv6_stub? Thanks. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH net] tipc: not enable tipc when ipv6 works as a module 2020-08-17 22:20 ` Cong Wang @ 2020-08-18 7:59 ` Xin Long 0 siblings, 0 replies; 18+ messages in thread From: Xin Long @ 2020-08-18 7:59 UTC (permalink / raw) To: Cong Wang, Jon Maloy, Ying Xue Cc: David Miller, Randy Dunlap, Linux Kernel Network Developers, tipc-discussion On Tue, Aug 18, 2020 at 6:20 AM Cong Wang <xiyou.wangcong@gmail.com> wrote: > > On Mon, Aug 17, 2020 at 2:39 PM David Miller <davem@davemloft.net> wrote: > > > > From: Cong Wang <xiyou.wangcong@gmail.com> > > Date: Mon, 17 Aug 2020 13:59:46 -0700 > > > > > Is this a new Kconfig feature? ipv6_stub was introduced for > > > VXLAN, at that time I don't remember we have such kind of > > > Kconfig rules, otherwise it would not be needed. > > > > The ipv6_stub exists in order to allow the troublesome > > "ipv6=m && feature_using_ipv6=y" combination. For certain code, instead of IS_ENABLE(), use IS_REACHABLE(). > > Hmm, so "IPV6=m && TIPC=y" is not a concern here as you pick > this patch over adding a ipv6_stub? > This is more a question for TIPC users. Hi, Jon and Ying, Have you met any users having "IPV6=m && TIPC=y" in their kernels? ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH net] tipc: not enable tipc when ipv6 works as a module 2020-08-17 20:29 ` Cong Wang 2020-08-17 20:43 ` Randy Dunlap @ 2020-08-17 21:37 ` David Miller 1 sibling, 0 replies; 18+ messages in thread From: David Miller @ 2020-08-17 21:37 UTC (permalink / raw) To: xiyou.wangcong Cc: rdunlap, lucien.xin, netdev, jmaloy, ying.xue, tipc-discussion From: Cong Wang <xiyou.wangcong@gmail.com> Date: Mon, 17 Aug 2020 13:29:40 -0700 > On Mon, Aug 17, 2020 at 12:55 PM Randy Dunlap <rdunlap@infradead.org> wrote: >> >> TIPC=m and IPV6=m builds just fine. >> >> Having tipc autoload ipv6 is a different problem. (IMO) >> >> >> This Kconfig entry: >> menuconfig TIPC >> tristate "The TIPC Protocol" >> depends on INET >> + depends on IPV6 || IPV6=n >> >> says: >> If IPV6=n, TIPC can be y/m/n. >> If IPV6=y/m, TIPC is limited to whatever IPV6 is set to. > > Hmm, nowadays we _do_ have IPV6=y on popular distros. > So this means TIPC would have to be builtin after this patch?? Note the word "limited", ipv6=y allows y and m, ipv6=m (more limited) allows only m. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH net] tipc: not enable tipc when ipv6 works as a module 2020-08-17 18:55 ` Cong Wang 2020-08-17 19:00 ` Randy Dunlap @ 2020-08-17 21:34 ` David Miller 1 sibling, 0 replies; 18+ messages in thread From: David Miller @ 2020-08-17 21:34 UTC (permalink / raw) To: xiyou.wangcong Cc: rdunlap, lucien.xin, netdev, jmaloy, ying.xue, tipc-discussion From: Cong Wang <xiyou.wangcong@gmail.com> Date: Mon, 17 Aug 2020 11:55:55 -0700 > On Mon, Aug 17, 2020 at 11:49 AM Randy Dunlap <rdunlap@infradead.org> wrote: >> >> It just restricts how TIPC can be built, so that >> TIPC=y and IPV6=m cannot happen together, which causes >> a build error. > > It also disallows TIPC=m and IPV6=m, right? That combination is allowed. The whole "X || X=n" construct means X must be off or equal to the value of the Kconfig entry this dependency is for. Thus you'll see "depends IPV6 || IPV6=n" everywhere. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH net] tipc: not enable tipc when ipv6 works as a module 2020-08-16 9:32 [PATCH net] tipc: not enable tipc when ipv6 works as a module Xin Long 2020-08-16 18:29 ` Cong Wang @ 2020-08-17 4:05 ` David Miller 1 sibling, 0 replies; 18+ messages in thread From: David Miller @ 2020-08-17 4:05 UTC (permalink / raw) To: lucien.xin; +Cc: netdev, jmaloy, ying.xue, tipc-discussion, rdunlap From: Xin Long <lucien.xin@gmail.com> Date: Sun, 16 Aug 2020 17:32:03 +0800 > When using ipv6_dev_find() in one module, it requires ipv6 not to > work as a module. Otherwise, this error occurs in build: > > undefined reference to `ipv6_dev_find'. > > So fix it by adding "depends on IPV6 || IPV6=n" to tipc/Kconfig, > as it does in sctp/Kconfig. > > Fixes: 5a6f6f579178 ("tipc: set ub->ifindex for local ipv6 address") > Reported-by: kernel test robot <lkp@intel.com> > Acked-by: Randy Dunlap <rdunlap@infradead.org> > Signed-off-by: Xin Long <lucien.xin@gmail.com> Applied. ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2020-08-18 7:47 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-08-16 9:32 [PATCH net] tipc: not enable tipc when ipv6 works as a module Xin Long 2020-08-16 18:29 ` Cong Wang 2020-08-17 6:49 ` Xin Long 2020-08-17 18:31 ` Cong Wang 2020-08-17 18:49 ` Randy Dunlap 2020-08-17 18:55 ` Cong Wang 2020-08-17 19:00 ` Randy Dunlap 2020-08-17 19:26 ` Cong Wang 2020-08-17 19:55 ` Randy Dunlap 2020-08-17 20:29 ` Cong Wang 2020-08-17 20:43 ` Randy Dunlap 2020-08-17 20:59 ` Cong Wang 2020-08-17 21:39 ` David Miller 2020-08-17 22:20 ` Cong Wang 2020-08-18 7:59 ` Xin Long 2020-08-17 21:37 ` David Miller 2020-08-17 21:34 ` David Miller 2020-08-17 4:05 ` David Miller
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).