* [PATCH] of: Add OF_DMA_DEFAULT_COHERENT & select it on powerpc @ 2020-01-26 11:52 ` Michael Ellerman 0 siblings, 0 replies; 37+ messages in thread From: Michael Ellerman @ 2020-01-26 11:52 UTC (permalink / raw) To: robh+dt Cc: devicetree, linux-kernel, hch, ulf.hansson, chzigotzky, linuxppc-dev There's an OF helper called of_dma_is_coherent(), which checks if a device has a "dma-coherent" property to see if the device is coherent for DMA. But on some platforms devices are coherent by default, and on some platforms it's not possible to update existing device trees to add the "dma-coherent" property. So add a Kconfig symbol to allow arch code to tell of_dma_is_coherent() that devices are coherent by default, regardless of the presence of the property. Select that symbol on powerpc when NOT_COHERENT_CACHE is not set, ie. when the system has a coherent cache. Fixes: 92ea637edea3 ("of: introduce of_dma_is_coherent() helper") Cc: stable@vger.kernel.org # v3.16+ Reported-by: Christian Zigotzky <chzigotzky@xenosoft.de> Tested-by: Christian Zigotzky <chzigotzky@xenosoft.de> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> --- arch/powerpc/Kconfig | 1 + drivers/of/Kconfig | 4 ++++ drivers/of/address.c | 6 +++++- 3 files changed, 10 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 1ec34e16ed65..19f5aa8ac9a3 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -238,6 +238,7 @@ config PPC select NEED_DMA_MAP_STATE if PPC64 || NOT_COHERENT_CACHE select NEED_SG_DMA_LENGTH select OF + select OF_DMA_DEFAULT_COHERENT if !NOT_COHERENT_CACHE select OF_EARLY_FLATTREE select OLD_SIGACTION if PPC32 select OLD_SIGSUSPEND diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig index 37c2ccbefecd..d91618641be6 100644 --- a/drivers/of/Kconfig +++ b/drivers/of/Kconfig @@ -103,4 +103,8 @@ config OF_OVERLAY config OF_NUMA bool +config OF_DMA_DEFAULT_COHERENT + # arches should select this if DMA is coherent by default for OF devices + bool + endif # OF diff --git a/drivers/of/address.c b/drivers/of/address.c index 99c1b8058559..e8a39c3ec4d4 100644 --- a/drivers/of/address.c +++ b/drivers/of/address.c @@ -995,12 +995,16 @@ int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *siz * @np: device node * * It returns true if "dma-coherent" property was found - * for this device in DT. + * for this device in the DT, or if DMA is coherent by + * default for OF devices on the current platform. */ bool of_dma_is_coherent(struct device_node *np) { struct device_node *node = of_node_get(np); + if (IS_ENABLED(CONFIG_OF_DMA_DEFAULT_COHERENT)) + return true; + while (node) { if (of_property_read_bool(node, "dma-coherent")) { of_node_put(node); -- 2.21.1 ^ permalink raw reply related [flat|nested] 37+ messages in thread
* [PATCH] of: Add OF_DMA_DEFAULT_COHERENT & select it on powerpc @ 2020-01-26 11:52 ` Michael Ellerman 0 siblings, 0 replies; 37+ messages in thread From: Michael Ellerman @ 2020-01-26 11:52 UTC (permalink / raw) To: robh+dt Cc: devicetree, ulf.hansson, linux-kernel, linuxppc-dev, chzigotzky, hch There's an OF helper called of_dma_is_coherent(), which checks if a device has a "dma-coherent" property to see if the device is coherent for DMA. But on some platforms devices are coherent by default, and on some platforms it's not possible to update existing device trees to add the "dma-coherent" property. So add a Kconfig symbol to allow arch code to tell of_dma_is_coherent() that devices are coherent by default, regardless of the presence of the property. Select that symbol on powerpc when NOT_COHERENT_CACHE is not set, ie. when the system has a coherent cache. Fixes: 92ea637edea3 ("of: introduce of_dma_is_coherent() helper") Cc: stable@vger.kernel.org # v3.16+ Reported-by: Christian Zigotzky <chzigotzky@xenosoft.de> Tested-by: Christian Zigotzky <chzigotzky@xenosoft.de> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> --- arch/powerpc/Kconfig | 1 + drivers/of/Kconfig | 4 ++++ drivers/of/address.c | 6 +++++- 3 files changed, 10 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 1ec34e16ed65..19f5aa8ac9a3 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -238,6 +238,7 @@ config PPC select NEED_DMA_MAP_STATE if PPC64 || NOT_COHERENT_CACHE select NEED_SG_DMA_LENGTH select OF + select OF_DMA_DEFAULT_COHERENT if !NOT_COHERENT_CACHE select OF_EARLY_FLATTREE select OLD_SIGACTION if PPC32 select OLD_SIGSUSPEND diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig index 37c2ccbefecd..d91618641be6 100644 --- a/drivers/of/Kconfig +++ b/drivers/of/Kconfig @@ -103,4 +103,8 @@ config OF_OVERLAY config OF_NUMA bool +config OF_DMA_DEFAULT_COHERENT + # arches should select this if DMA is coherent by default for OF devices + bool + endif # OF diff --git a/drivers/of/address.c b/drivers/of/address.c index 99c1b8058559..e8a39c3ec4d4 100644 --- a/drivers/of/address.c +++ b/drivers/of/address.c @@ -995,12 +995,16 @@ int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *siz * @np: device node * * It returns true if "dma-coherent" property was found - * for this device in DT. + * for this device in the DT, or if DMA is coherent by + * default for OF devices on the current platform. */ bool of_dma_is_coherent(struct device_node *np) { struct device_node *node = of_node_get(np); + if (IS_ENABLED(CONFIG_OF_DMA_DEFAULT_COHERENT)) + return true; + while (node) { if (of_property_read_bool(node, "dma-coherent")) { of_node_put(node); -- 2.21.1 ^ permalink raw reply related [flat|nested] 37+ messages in thread
* Re: [PATCH] of: Add OF_DMA_DEFAULT_COHERENT & select it on powerpc 2020-01-26 11:52 ` Michael Ellerman @ 2020-01-27 7:22 ` Ulf Hansson -1 siblings, 0 replies; 37+ messages in thread From: Ulf Hansson @ 2020-01-27 7:22 UTC (permalink / raw) To: Michael Ellerman Cc: Rob Herring, DTML, Linux Kernel Mailing List, Christoph Hellwig, Christian Zigotzky, linuxppc-dev On Sun, 26 Jan 2020 at 12:53, Michael Ellerman <mpe@ellerman.id.au> wrote: > > There's an OF helper called of_dma_is_coherent(), which checks if a > device has a "dma-coherent" property to see if the device is coherent > for DMA. > > But on some platforms devices are coherent by default, and on some > platforms it's not possible to update existing device trees to add the > "dma-coherent" property. > > So add a Kconfig symbol to allow arch code to tell > of_dma_is_coherent() that devices are coherent by default, regardless > of the presence of the property. > > Select that symbol on powerpc when NOT_COHERENT_CACHE is not set, ie. > when the system has a coherent cache. > > Fixes: 92ea637edea3 ("of: introduce of_dma_is_coherent() helper") > Cc: stable@vger.kernel.org # v3.16+ > Reported-by: Christian Zigotzky <chzigotzky@xenosoft.de> > Tested-by: Christian Zigotzky <chzigotzky@xenosoft.de> > Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Thanks Michael for helping out fixing and this! The patch looks good to me. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Kind regards Uffe > --- > arch/powerpc/Kconfig | 1 + > drivers/of/Kconfig | 4 ++++ > drivers/of/address.c | 6 +++++- > 3 files changed, 10 insertions(+), 1 deletion(-) > > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig > index 1ec34e16ed65..19f5aa8ac9a3 100644 > --- a/arch/powerpc/Kconfig > +++ b/arch/powerpc/Kconfig > @@ -238,6 +238,7 @@ config PPC > select NEED_DMA_MAP_STATE if PPC64 || NOT_COHERENT_CACHE > select NEED_SG_DMA_LENGTH > select OF > + select OF_DMA_DEFAULT_COHERENT if !NOT_COHERENT_CACHE > select OF_EARLY_FLATTREE > select OLD_SIGACTION if PPC32 > select OLD_SIGSUSPEND > diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig > index 37c2ccbefecd..d91618641be6 100644 > --- a/drivers/of/Kconfig > +++ b/drivers/of/Kconfig > @@ -103,4 +103,8 @@ config OF_OVERLAY > config OF_NUMA > bool > > +config OF_DMA_DEFAULT_COHERENT > + # arches should select this if DMA is coherent by default for OF devices > + bool > + > endif # OF > diff --git a/drivers/of/address.c b/drivers/of/address.c > index 99c1b8058559..e8a39c3ec4d4 100644 > --- a/drivers/of/address.c > +++ b/drivers/of/address.c > @@ -995,12 +995,16 @@ int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *siz > * @np: device node > * > * It returns true if "dma-coherent" property was found > - * for this device in DT. > + * for this device in the DT, or if DMA is coherent by > + * default for OF devices on the current platform. > */ > bool of_dma_is_coherent(struct device_node *np) > { > struct device_node *node = of_node_get(np); > > + if (IS_ENABLED(CONFIG_OF_DMA_DEFAULT_COHERENT)) > + return true; > + > while (node) { > if (of_property_read_bool(node, "dma-coherent")) { > of_node_put(node); > -- > 2.21.1 > ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH] of: Add OF_DMA_DEFAULT_COHERENT & select it on powerpc @ 2020-01-27 7:22 ` Ulf Hansson 0 siblings, 0 replies; 37+ messages in thread From: Ulf Hansson @ 2020-01-27 7:22 UTC (permalink / raw) To: Michael Ellerman Cc: DTML, Linux Kernel Mailing List, linuxppc-dev, Rob Herring, Christian Zigotzky, Christoph Hellwig On Sun, 26 Jan 2020 at 12:53, Michael Ellerman <mpe@ellerman.id.au> wrote: > > There's an OF helper called of_dma_is_coherent(), which checks if a > device has a "dma-coherent" property to see if the device is coherent > for DMA. > > But on some platforms devices are coherent by default, and on some > platforms it's not possible to update existing device trees to add the > "dma-coherent" property. > > So add a Kconfig symbol to allow arch code to tell > of_dma_is_coherent() that devices are coherent by default, regardless > of the presence of the property. > > Select that symbol on powerpc when NOT_COHERENT_CACHE is not set, ie. > when the system has a coherent cache. > > Fixes: 92ea637edea3 ("of: introduce of_dma_is_coherent() helper") > Cc: stable@vger.kernel.org # v3.16+ > Reported-by: Christian Zigotzky <chzigotzky@xenosoft.de> > Tested-by: Christian Zigotzky <chzigotzky@xenosoft.de> > Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Thanks Michael for helping out fixing and this! The patch looks good to me. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Kind regards Uffe > --- > arch/powerpc/Kconfig | 1 + > drivers/of/Kconfig | 4 ++++ > drivers/of/address.c | 6 +++++- > 3 files changed, 10 insertions(+), 1 deletion(-) > > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig > index 1ec34e16ed65..19f5aa8ac9a3 100644 > --- a/arch/powerpc/Kconfig > +++ b/arch/powerpc/Kconfig > @@ -238,6 +238,7 @@ config PPC > select NEED_DMA_MAP_STATE if PPC64 || NOT_COHERENT_CACHE > select NEED_SG_DMA_LENGTH > select OF > + select OF_DMA_DEFAULT_COHERENT if !NOT_COHERENT_CACHE > select OF_EARLY_FLATTREE > select OLD_SIGACTION if PPC32 > select OLD_SIGSUSPEND > diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig > index 37c2ccbefecd..d91618641be6 100644 > --- a/drivers/of/Kconfig > +++ b/drivers/of/Kconfig > @@ -103,4 +103,8 @@ config OF_OVERLAY > config OF_NUMA > bool > > +config OF_DMA_DEFAULT_COHERENT > + # arches should select this if DMA is coherent by default for OF devices > + bool > + > endif # OF > diff --git a/drivers/of/address.c b/drivers/of/address.c > index 99c1b8058559..e8a39c3ec4d4 100644 > --- a/drivers/of/address.c > +++ b/drivers/of/address.c > @@ -995,12 +995,16 @@ int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *siz > * @np: device node > * > * It returns true if "dma-coherent" property was found > - * for this device in DT. > + * for this device in the DT, or if DMA is coherent by > + * default for OF devices on the current platform. > */ > bool of_dma_is_coherent(struct device_node *np) > { > struct device_node *node = of_node_get(np); > > + if (IS_ENABLED(CONFIG_OF_DMA_DEFAULT_COHERENT)) > + return true; > + > while (node) { > if (of_property_read_bool(node, "dma-coherent")) { > of_node_put(node); > -- > 2.21.1 > ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH] of: Add OF_DMA_DEFAULT_COHERENT & select it on powerpc 2020-01-27 7:22 ` Ulf Hansson @ 2020-01-31 10:40 ` Michael Ellerman -1 siblings, 0 replies; 37+ messages in thread From: Michael Ellerman @ 2020-01-31 10:40 UTC (permalink / raw) To: Ulf Hansson Cc: Rob Herring, DTML, Linux Kernel Mailing List, Christoph Hellwig, Christian Zigotzky, linuxppc-dev Ulf Hansson <ulf.hansson@linaro.org> writes: > On Sun, 26 Jan 2020 at 12:53, Michael Ellerman <mpe@ellerman.id.au> wrote: >> There's an OF helper called of_dma_is_coherent(), which checks if a >> device has a "dma-coherent" property to see if the device is coherent >> for DMA. >> >> But on some platforms devices are coherent by default, and on some >> platforms it's not possible to update existing device trees to add the >> "dma-coherent" property. >> >> So add a Kconfig symbol to allow arch code to tell >> of_dma_is_coherent() that devices are coherent by default, regardless >> of the presence of the property. >> >> Select that symbol on powerpc when NOT_COHERENT_CACHE is not set, ie. >> when the system has a coherent cache. >> >> Fixes: 92ea637edea3 ("of: introduce of_dma_is_coherent() helper") >> Cc: stable@vger.kernel.org # v3.16+ >> Reported-by: Christian Zigotzky <chzigotzky@xenosoft.de> >> Tested-by: Christian Zigotzky <chzigotzky@xenosoft.de> >> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> > > Thanks Michael for helping out fixing and this! The patch looks good to me. > > Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Thanks for the review. cheers ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH] of: Add OF_DMA_DEFAULT_COHERENT & select it on powerpc @ 2020-01-31 10:40 ` Michael Ellerman 0 siblings, 0 replies; 37+ messages in thread From: Michael Ellerman @ 2020-01-31 10:40 UTC (permalink / raw) To: Ulf Hansson Cc: DTML, Linux Kernel Mailing List, linuxppc-dev, Rob Herring, Christian Zigotzky, Christoph Hellwig Ulf Hansson <ulf.hansson@linaro.org> writes: > On Sun, 26 Jan 2020 at 12:53, Michael Ellerman <mpe@ellerman.id.au> wrote: >> There's an OF helper called of_dma_is_coherent(), which checks if a >> device has a "dma-coherent" property to see if the device is coherent >> for DMA. >> >> But on some platforms devices are coherent by default, and on some >> platforms it's not possible to update existing device trees to add the >> "dma-coherent" property. >> >> So add a Kconfig symbol to allow arch code to tell >> of_dma_is_coherent() that devices are coherent by default, regardless >> of the presence of the property. >> >> Select that symbol on powerpc when NOT_COHERENT_CACHE is not set, ie. >> when the system has a coherent cache. >> >> Fixes: 92ea637edea3 ("of: introduce of_dma_is_coherent() helper") >> Cc: stable@vger.kernel.org # v3.16+ >> Reported-by: Christian Zigotzky <chzigotzky@xenosoft.de> >> Tested-by: Christian Zigotzky <chzigotzky@xenosoft.de> >> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> > > Thanks Michael for helping out fixing and this! The patch looks good to me. > > Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Thanks for the review. cheers ^ permalink raw reply [flat|nested] 37+ messages in thread
* Latest Git kernel: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device 2020-01-27 7:22 ` Ulf Hansson @ 2020-02-02 0:08 ` Christian Zigotzky -1 siblings, 0 replies; 37+ messages in thread From: Christian Zigotzky @ 2020-02-02 0:08 UTC (permalink / raw) To: Michael Ellerman Cc: Darren Stevens, DTML, Linux Kernel Mailing List, Christoph Hellwig, linuxppc-dev, R.T.Dickinson, contact Hello, We regularly compile and test Linux kernels every day during the merge window. Since Thuesday we have very high CPU loads because of the avahi daemon on our desktop Linux systems (Ubuntu, Debian etc). Error message: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device Could you please test the latest Git kernel? It is possible to deactivate the avahi daemon with the following lines in the file "/etc/avahi/avahi-daemon.conf": use-ipv4=no use-ipv6=no But this is only a temporary solution. Thanks, Christian ^ permalink raw reply [flat|nested] 37+ messages in thread
* Latest Git kernel: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device @ 2020-02-02 0:08 ` Christian Zigotzky 0 siblings, 0 replies; 37+ messages in thread From: Christian Zigotzky @ 2020-02-02 0:08 UTC (permalink / raw) To: Michael Ellerman Cc: DTML, Darren Stevens, Linux Kernel Mailing List, linuxppc-dev, contact, R.T.Dickinson, Christoph Hellwig Hello, We regularly compile and test Linux kernels every day during the merge window. Since Thuesday we have very high CPU loads because of the avahi daemon on our desktop Linux systems (Ubuntu, Debian etc). Error message: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device Could you please test the latest Git kernel? It is possible to deactivate the avahi daemon with the following lines in the file "/etc/avahi/avahi-daemon.conf": use-ipv4=no use-ipv6=no But this is only a temporary solution. Thanks, Christian ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Latest Git kernel: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device 2020-02-02 0:08 ` Christian Zigotzky @ 2020-02-02 4:37 ` Randy Dunlap -1 siblings, 0 replies; 37+ messages in thread From: Randy Dunlap @ 2020-02-02 4:37 UTC (permalink / raw) To: Christian Zigotzky, Michael Ellerman Cc: Darren Stevens, DTML, Linux Kernel Mailing List, Christoph Hellwig, linuxppc-dev, R.T.Dickinson, contact, netdev [might be network related, so adding netdev mailing list] On 2/1/20 4:08 PM, Christian Zigotzky wrote: > Hello, > > We regularly compile and test Linux kernels every day during the merge window. Since Thuesday we have very high CPU loads because of the avahi daemon on our desktop Linux systems (Ubuntu, Debian etc). > > Error message: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device > > Could you please test the latest Git kernel? > > It is possible to deactivate the avahi daemon with the following lines in the file "/etc/avahi/avahi-daemon.conf": > > use-ipv4=no > use-ipv6=no > > But this is only a temporary solution. > > Thanks, > Christian -- ~Randy ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Latest Git kernel: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device @ 2020-02-02 4:37 ` Randy Dunlap 0 siblings, 0 replies; 37+ messages in thread From: Randy Dunlap @ 2020-02-02 4:37 UTC (permalink / raw) To: Christian Zigotzky, Michael Ellerman Cc: DTML, Darren Stevens, netdev, Linux Kernel Mailing List, linuxppc-dev, contact, R.T.Dickinson, Christoph Hellwig [might be network related, so adding netdev mailing list] On 2/1/20 4:08 PM, Christian Zigotzky wrote: > Hello, > > We regularly compile and test Linux kernels every day during the merge window. Since Thuesday we have very high CPU loads because of the avahi daemon on our desktop Linux systems (Ubuntu, Debian etc). > > Error message: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device > > Could you please test the latest Git kernel? > > It is possible to deactivate the avahi daemon with the following lines in the file "/etc/avahi/avahi-daemon.conf": > > use-ipv4=no > use-ipv6=no > > But this is only a temporary solution. > > Thanks, > Christian -- ~Randy ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Latest Git kernel: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device 2020-02-02 0:08 ` Christian Zigotzky (?) (?) @ 2020-02-02 8:19 ` Christophe Leroy 2020-02-02 15:02 ` Christian Zigotzky -1 siblings, 1 reply; 37+ messages in thread From: Christophe Leroy @ 2020-02-02 8:19 UTC (permalink / raw) To: Christian Zigotzky, Michael Ellerman Cc: DTML, Darren Stevens, Linux Kernel Mailing List, linuxppc-dev, contact, R.T.Dickinson, Christoph Hellwig Hello, Le 02/02/2020 à 01:08, Christian Zigotzky a écrit : > Hello, > > We regularly compile and test Linux kernels every day during the merge > window. Since Thuesday we have very high CPU loads because of the avahi > daemon on our desktop Linux systems (Ubuntu, Debian etc). > > Error message: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device Do you know which ioctl, on which device ? Can you take a trace of running avahi-daemon with 'strace' ? Can you bisect ? Christophe ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Latest Git kernel: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device 2020-02-02 8:19 ` Christophe Leroy @ 2020-02-02 15:02 ` Christian Zigotzky 2020-02-03 17:53 ` Jakub Kicinski 0 siblings, 1 reply; 37+ messages in thread From: Christian Zigotzky @ 2020-02-02 15:02 UTC (permalink / raw) To: Christophe Leroy, Michael Ellerman, DTML, Darren Stevens, Linux Kernel Mailing List, linuxppc-dev, contact, R.T.Dickinson, Christoph Hellwig, mad skateman, netdev [-- Attachment #1: Type: text/plain, Size: 1866 bytes --] On 02 February 2020 at 09:19 am, Christophe Leroy wrote: > Hello, > > Le 02/02/2020 à 01:08, Christian Zigotzky a écrit : >> Hello, >> >> We regularly compile and test Linux kernels every day during the >> merge window. Since Thuesday we have very high CPU loads because of >> the avahi daemon on our desktop Linux systems (Ubuntu, Debian etc). >> >> Error message: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for >> device > > Do you know which ioctl, on which device ? > Can you take a trace of running avahi-daemon with 'strace' ? > > Can you bisect ? > > Christophe Hi Christophe, Hi All, I figured out that the avahi-daemon has a problem with the IPv6 address of a network interface since the Git kernel from Thursday. (Log attached) This generates high CPU usage because the avahi-daemon tries to access the IPv6 address again and again and thereby it produces a lot of log messages. We figured out that the networking updates aren't responsible for this issue because we created a test kernel on Wednesday. The issue is somewhere in the commits from Wednesday night to Thursday (CET). Please compile the latest Git kernel and test it with a desktop linux distribution for example Ubuntu. In my point of view there are many desktop machines affected. Many server systems don't use the avahi daemon so they aren't affected. It's possible to deactivate the access to the IPv6 address with the following line in the file "/etc/avahi/avahi-daemon.conf": use-ipv6=no After a reboot the CPU usage is normal again. This is only a temporary solution. Unfortunately I don't have the time for bisecting next week. I have a lot of other work to do. In my point of view it is very important that you also compile the latest Git kernels. Then you will see the issue and then you have a better possibility to fix the issue. Thanks, Christian [-- Attachment #2: avahi_log --] [-- Type: text/plain, Size: 8831 bytes --] Kernel 5.5.0: journalctl | grep -i avahi Feb 02 13:57:05 DC1 systemd[1]: Listening on Avahi mDNS/DNS-SD Stack Activation Socket. Feb 02 13:57:05 DC1 systemd[1]: Starting Avahi mDNS/DNS-SD Stack... Feb 02 13:57:05 DC1 avahi-daemon[4314]: Found user 'avahi' (UID 112) and group 'avahi' (GID 122). Feb 02 13:57:05 DC1 avahi-daemon[4314]: Successfully dropped root privileges. Feb 02 13:57:05 DC1 avahi-daemon[4314]: avahi-daemon 0.6.32-rc starting up. Feb 02 13:57:06 DC1 systemd[1]: Started Avahi DNS Configuration Daemon. Feb 02 13:57:06 DC1 avahi-daemon[4314]: Successfully called chroot(). Feb 02 13:57:06 DC1 avahi-daemon[4314]: Successfully dropped remaining capabilities. Feb 02 13:57:06 DC1 avahi-daemon[4314]: No service file found in /etc/avahi/services. Feb 02 13:57:06 DC1 avahi-daemon[4314]: Network interface enumeration completed. Feb 02 13:57:06 DC1 avahi-daemon[4314]: Server startup complete. Host name is DC1.local. Local service cookie is 3202921551. Feb 02 13:57:06 DC1 avahi-daemon[4314]: Failed to parse address 'localhost', ignoring. Feb 02 13:57:06 DC1 avahi-dnsconfd[4487]: Successfully connected to Avahi daemon. Feb 02 13:57:06 DC1 systemd[1]: Started Avahi mDNS/DNS-SD Stack. Feb 02 13:57:07 DC1 root[4749]: /etc/dhcp/dhclient-enter-hooks.d/avahi-autoipd returned non-zero exit status 1 Feb 02 13:57:07 DC1 avahi-daemon[4314]: Joining mDNS multicast group on interface enP4096p4s4.IPv4 with address 192.168.178.47. Feb 02 13:57:07 DC1 avahi-daemon[4314]: New relevant interface enP4096p4s4.IPv4 for mDNS. Feb 02 13:57:07 DC1 avahi-daemon[4314]: Registering new address record for 192.168.178.47 on enP4096p4s4.IPv4. Feb 02 13:57:09 DC1 avahi-daemon[4314]: Joining mDNS multicast group on interface enP4096p4s4.IPv6 with address fe80::250:fcff:fecb:5181. Feb 02 13:57:09 DC1 avahi-daemon[4314]: New relevant interface enP4096p4s4.IPv6 for mDNS. Feb 02 13:57:09 DC1 avahi-daemon[4314]: Registering new address record for fe80::250:fcff:fecb:5181 on enP4096p4s4.*. Feb 02 13:57:10 DC1 avahi-daemon[4314]: Leaving mDNS multicast group on interface enP4096p4s4.IPv6 with address fe80::250:fcff:fecb:5181. Feb 02 13:57:10 DC1 avahi-daemon[4314]: Joining mDNS multicast group on interface enP4096p4s4.IPv6 with address 2a02:8109:89c0:ebfc:250:fcff:fecb:5181. Feb 02 13:57:10 DC1 avahi-daemon[4314]: Registering new address record for 2a02:8109:89c0:ebfc:250:fcff:fecb:5181 on enP4096p4s4.*. Feb 02 13:57:10 DC1 avahi-daemon[4314]: Withdrawing address record for fe80::250:fcff:fecb:5181 on enP4096p4s4. ------ Latest Git kernel (5.6): journalctl | grep -i avahi Feb 02 14:04:04 DC1 systemd[1]: Listening on Avahi mDNS/DNS-SD Stack Activation Socket. Feb 02 14:04:05 DC1 systemd[1]: Started Avahi DNS Configuration Daemon. Feb 02 14:04:05 DC1 systemd[1]: Starting Avahi mDNS/DNS-SD Stack... Feb 02 14:04:05 DC1 avahi-daemon[4573]: Found user 'avahi' (UID 112) and group 'avahi' (GID 122). Feb 02 14:04:05 DC1 avahi-daemon[4573]: Successfully dropped root privileges. Feb 02 14:04:05 DC1 avahi-daemon[4573]: avahi-daemon 0.6.32-rc starting up. Feb 02 14:04:05 DC1 avahi-daemon[4573]: Successfully called chroot(). Feb 02 14:04:05 DC1 avahi-daemon[4573]: Successfully dropped remaining capabilities. Feb 02 14:04:05 DC1 avahi-daemon[4573]: No service file found in /etc/avahi/services. Feb 02 14:04:05 DC1 avahi-daemon[4573]: Network interface enumeration completed. Feb 02 14:04:05 DC1 avahi-daemon[4573]: Server startup complete. Host name is DC1.local. Local service cookie is 285370789. Feb 02 14:04:05 DC1 avahi-daemon[4573]: Failed to parse address 'localhost', ignoring. Feb 02 14:04:05 DC1 avahi-dnsconfd[4425]: Successfully connected to Avahi daemon. Feb 02 14:04:05 DC1 root[4642]: /etc/dhcp/dhclient-enter-hooks.d/avahi-autoipd returned non-zero exit status 1 Feb 02 14:04:06 DC1 systemd[1]: Started Avahi mDNS/DNS-SD Stack. Feb 02 14:04:06 DC1 avahi-daemon[4573]: Joining mDNS multicast group on interface enP4096p4s4.IPv4 with address 192.168.178.47. Feb 02 14:04:06 DC1 avahi-daemon[4573]: New relevant interface enP4096p4s4.IPv4 for mDNS. Feb 02 14:04:06 DC1 avahi-daemon[4573]: Registering new address record for 192.168.178.47 on enP4096p4s4.IPv4. Feb 02 14:04:08 DC1 avahi-daemon[4573]: Joining mDNS multicast group on interface enP4096p4s4.IPv6 with address fe80::250:fcff:fecb:5181. Feb 02 14:04:08 DC1 avahi-daemon[4573]: New relevant interface enP4096p4s4.IPv6 for mDNS. Feb 02 14:04:08 DC1 avahi-daemon[4573]: Registering new address record for fe80::250:fcff:fecb:5181 on enP4096p4s4.*. Feb 02 14:04:08 DC1 avahi-daemon[4573]: ioctl(): Inappropriate ioctl for device Feb 02 14:04:08 DC1 avahi-daemon[4573]: ioctl(): Inappropriate ioctl for device Feb 02 14:04:08 DC1 avahi-daemon[4573]: ioctl(): Inappropriate ioctl for device Feb 02 14:04:08 DC1 avahi-daemon[4573]: ioctl(): Inappropriate ioctl for device ... Feb 02 14:04:08 DC1 avahi-daemon[4573]: ioctl(): Inappropriate ioctl for device Feb 02 14:04:08 DC1 avahi-daemon[4573]: ioctl(): Inappropriate ioctl for device Feb 02 14:04:08 DC1 avahi-daemon[4573]: ioctl(): Inappropriate ioctl for device Feb 02 14:04:08 DC1 avahi-daemon[4573]: ioctl(): Inappropriate ioctl for device Feb 02 14:04:08 DC1 avahi-daemon[4573]: ioctl(): Inappropriate ioctl for device Feb 02 14:04:08 DC1 avahi-daemon[4573]: ioctl(): Inappropriate ioctl for device Feb 02 14:04:08 DC1 avahi-daemon[4573]: ioctl(): Inappropriate ioctl for device Feb 02 14:04:08 DC1 avahi-daemon[4573]: ioctl(): Inappropriate ioctl for device Feb 02 14:04:08 DC1 avahi-daemon[4573]: ioctl(): Inappropriate ioctl for device Feb 02 14:04:08 DC1 avahi-daemon[4573]: ioctl(): Inappropriate ioctl for device Feb 02 14:04:08 DC1 avahi-daemon[4573]: ioctl(): Inappropriate ioctl for device Feb 02 14:04:08 DC1 avahi-daemon[4573]: ioctl(): Inappropriate ioctl for device Feb 02 14:04:08 DC1 avahi-daemon[4573]: ioctl(): Inappropriate ioctl for device Feb 02 14:04:09 DC1 avahi-daemon[4573]: Leaving mDNS multicast group on interface enP4096p4s4.IPv6 with address fe80::250:fcff:fecb:5181. Feb 02 14:04:09 DC1 avahi-daemon[4573]: Joining mDNS multicast group on interface enP4096p4s4.IPv6 with address 2a02:8109:89c0:ebfc:250:fcff:fecb:5181. Feb 02 14:04:09 DC1 avahi-daemon[4573]: Registering new address record for 2a02:8109:89c0:ebfc:250:fcff:fecb:5181 on enP4096p4s4.*. Feb 02 14:04:09 DC1 avahi-daemon[4573]: Withdrawing address record for fe80::250:fcff:fecb:5181 on enP4096p4s4. Feb 02 14:04:28 DC1 avahi-daemon[4573]: ioctl(): Inappropriate ioctl for device Feb 02 14:04:28 DC1 avahi-daemon[4573]: ioctl(): Inappropriate ioctl for device Feb 02 14:04:28 DC1 avahi-daemon[4573]: ioctl(): Inappropriate ioctl for device Feb 02 14:04:28 DC1 avahi-daemon[4573]: ioctl(): Inappropriate ioctl for device Feb 02 14:04:28 DC1 avahi-daemon[4573]: ioctl(): Inappropriate ioctl for device Feb 02 14:04:28 DC1 avahi-daemon[4573]: ioctl(): Inappropriate ioctl for device ... Feb 02 14:04:29 DC1 avahi-daemon[4573]: ioctl(): Inappropriate ioctl for device Feb 02 14:04:29 DC1 avahi-daemon[4573]: ioctl(): Inappropriate ioctl for device Feb 02 14:04:29 DC1 avahi-daemon[4573]: ioctl(): Inappropriate ioctl for device Feb 02 14:04:35 DC1 systemd-journald[2489]: Suppressed 513915 messages from /system.slice/avahi-daemon.service Feb 02 14:04:35 DC1 avahi-daemon[4573]: ioctl(): Inappropriate ioctl for device Feb 02 14:04:35 DC1 avahi-daemon[4573]: ioctl(): Inappropriate ioctl for device Feb 02 14:04:35 DC1 avahi-daemon[4573]: ioctl(): Inappropriate ioctl for device ------ Latest Git kernel (5.6): systemctl status avahi-daemon ● avahi-daemon.service - Avahi mDNS/DNS-SD Stack Loaded: loaded (/lib/systemd/system/avahi-daemon.service; enabled; vendor preset: enabled) Active: active (running) since Sun 2020-02-02 14:04:06 CET; 11min ago Main PID: 4573 (avahi-daemon) Status: "avahi-daemon 0.6.32-rc starting up." CGroup: /system.slice/avahi-daemon.service ├─4573 avahi-daemon: running [DC1.local] └─4581 avahi-daemon: chroot helper Feb 02 14:15:34 DC1 avahi-daemon[4573]: ioctl(): Inappropriate ioctl for device Feb 02 14:15:34 DC1 avahi-daemon[4573]: ioctl(): Inappropriate ioctl for device Feb 02 14:15:34 DC1 avahi-daemon[4573]: ioctl(): Inappropriate ioctl for device Feb 02 14:15:34 DC1 avahi-daemon[4573]: ioctl(): Inappropriate ioctl for device Feb 02 14:15:34 DC1 avahi-daemon[4573]: ioctl(): Inappropriate ioctl for device Feb 02 14:15:34 DC1 avahi-daemon[4573]: ioctl(): Inappropriate ioctl for device Feb 02 14:15:34 DC1 avahi-daemon[4573]: ioctl(): Inappropriate ioctl for device Feb 02 14:15:34 DC1 avahi-daemon[4573]: ioctl(): Inappropriate ioctl for device Feb 02 14:15:34 DC1 avahi-daemon[4573]: ioctl(): Inappropriate ioctl for device Feb 02 14:15:34 DC1 avahi-daemon[4573]: ioctl(): Inappropriate ioctl for device ------ ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Latest Git kernel: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device 2020-02-02 15:02 ` Christian Zigotzky @ 2020-02-03 17:53 ` Jakub Kicinski 0 siblings, 0 replies; 37+ messages in thread From: Jakub Kicinski @ 2020-02-03 17:53 UTC (permalink / raw) To: Christian Zigotzky Cc: Christophe Leroy, Michael Ellerman, DTML, Darren Stevens, Linux Kernel Mailing List, linuxppc-dev, contact, R.T.Dickinson, Christoph Hellwig, mad skateman, netdev On Sun, 2 Feb 2020 16:02:18 +0100, Christian Zigotzky wrote: > On 02 February 2020 at 09:19 am, Christophe Leroy wrote: > > Hello, > > > > Le 02/02/2020 à 01:08, Christian Zigotzky a écrit : > >> Hello, > >> > >> We regularly compile and test Linux kernels every day during the > >> merge window. Since Thuesday we have very high CPU loads because of > >> the avahi daemon on our desktop Linux systems (Ubuntu, Debian etc). > >> > >> Error message: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for > >> device > > > > Do you know which ioctl, on which device ? > > Can you take a trace of running avahi-daemon with 'strace' ? > > > > Can you bisect ? > > > > Christophe > Hi Christophe, > Hi All, > > I figured out that the avahi-daemon has a problem with the IPv6 address > of a network interface since the Git kernel from Thursday. (Log attached) > This generates high CPU usage because the avahi-daemon tries to access > the IPv6 address again and again and thereby it produces a lot of log > messages. > > We figured out that the networking updates aren't responsible for this > issue because we created a test kernel on Wednesday. The issue is > somewhere in the commits from Wednesday night to Thursday (CET). FWIW Thursday is when the latest networking pull came in, so could well be networking related.. > Please compile the latest Git kernel and test it with a desktop linux > distribution for example Ubuntu. In my point of view there are many > desktop machines affected. Many server systems don't use the avahi > daemon so they aren't affected. > > It's possible to deactivate the access to the IPv6 address with the > following line in the file "/etc/avahi/avahi-daemon.conf": > > use-ipv6=no > > After a reboot the CPU usage is normal again. This is only a temporary > solution. > > Unfortunately I don't have the time for bisecting next week. I have a > lot of other work to do. In my point of view it is very important that > you also compile the latest Git kernels. Then you will see the issue and > then you have a better possibility to fix the issue. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Latest Git kernel: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device @ 2020-02-03 17:53 ` Jakub Kicinski 0 siblings, 0 replies; 37+ messages in thread From: Jakub Kicinski @ 2020-02-03 17:53 UTC (permalink / raw) To: Christian Zigotzky Cc: DTML, Darren Stevens, mad skateman, Linux Kernel Mailing List, linuxppc-dev, contact, R.T.Dickinson, netdev, Christoph Hellwig On Sun, 2 Feb 2020 16:02:18 +0100, Christian Zigotzky wrote: > On 02 February 2020 at 09:19 am, Christophe Leroy wrote: > > Hello, > > > > Le 02/02/2020 à 01:08, Christian Zigotzky a écrit : > >> Hello, > >> > >> We regularly compile and test Linux kernels every day during the > >> merge window. Since Thuesday we have very high CPU loads because of > >> the avahi daemon on our desktop Linux systems (Ubuntu, Debian etc). > >> > >> Error message: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for > >> device > > > > Do you know which ioctl, on which device ? > > Can you take a trace of running avahi-daemon with 'strace' ? > > > > Can you bisect ? > > > > Christophe > Hi Christophe, > Hi All, > > I figured out that the avahi-daemon has a problem with the IPv6 address > of a network interface since the Git kernel from Thursday. (Log attached) > This generates high CPU usage because the avahi-daemon tries to access > the IPv6 address again and again and thereby it produces a lot of log > messages. > > We figured out that the networking updates aren't responsible for this > issue because we created a test kernel on Wednesday. The issue is > somewhere in the commits from Wednesday night to Thursday (CET). FWIW Thursday is when the latest networking pull came in, so could well be networking related.. > Please compile the latest Git kernel and test it with a desktop linux > distribution for example Ubuntu. In my point of view there are many > desktop machines affected. Many server systems don't use the avahi > daemon so they aren't affected. > > It's possible to deactivate the access to the IPv6 address with the > following line in the file "/etc/avahi/avahi-daemon.conf": > > use-ipv6=no > > After a reboot the CPU usage is normal again. This is only a temporary > solution. > > Unfortunately I don't have the time for bisecting next week. I have a > lot of other work to do. In my point of view it is very important that > you also compile the latest Git kernels. Then you will see the issue and > then you have a better possibility to fix the issue. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Latest Git kernel: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device 2020-02-03 17:53 ` Jakub Kicinski @ 2020-02-05 13:03 ` Christian Zigotzky -1 siblings, 0 replies; 37+ messages in thread From: Christian Zigotzky @ 2020-02-05 13:03 UTC (permalink / raw) To: Jakub Kicinski Cc: Christophe Leroy, Michael Ellerman, DTML, Darren Stevens, Linux Kernel Mailing List, linuxppc-dev, contact, R.T.Dickinson, Christoph Hellwig, mad skateman, netdev On 03 February 2020 at 6:53 pm, Jakub Kicinski wrote: > On Sun, 2 Feb 2020 16:02:18 +0100, Christian Zigotzky wrote: >> On 02 February 2020 at 09:19 am, Christophe Leroy wrote: >>> Hello, >>> >>> Le 02/02/2020 à 01:08, Christian Zigotzky a écrit : >>>> Hello, >>>> >>>> We regularly compile and test Linux kernels every day during the >>>> merge window. Since Thursday we have very high CPU loads because of >>>> the avahi daemon on our desktop Linux systems (Ubuntu, Debian etc). >>>> >>>> Error message: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for >>>> device >>> Do you know which ioctl, on which device ? >>> Can you take a trace of running avahi-daemon with 'strace' ? >>> >>> Can you bisect ? >>> >>> Christophe >> Hi Christophe, >> Hi All, >> >> I figured out that the avahi-daemon has a problem with the IPv6 address >> of a network interface since the Git kernel from Thursday. (Log attached) >> This generates high CPU usage because the avahi-daemon tries to access >> the IPv6 address again and again and thereby it produces a lot of log >> messages. >> >> We figured out that the networking updates aren't responsible for this >> issue because we created a test kernel on Wednesday. The issue is >> somewhere in the commits from Wednesday night to Thursday (CET). > FWIW Thursday is when the latest networking pull came in, so could well > be networking related.. > >> Please compile the latest Git kernel and test it with a desktop linux >> distribution for example Ubuntu. In my point of view there are many >> desktop machines affected. Many server systems don't use the avahi >> daemon so they aren't affected. >> >> It's possible to deactivate the access to the IPv6 address with the >> following line in the file "/etc/avahi/avahi-daemon.conf": >> >> use-ipv6=no >> >> After a reboot the CPU usage is normal again. This is only a temporary >> solution. >> >> Unfortunately I don't have the time for bisecting next week. I have a >> lot of other work to do. In my point of view it is very important that >> you also compile the latest Git kernels. Then you will see the issue and >> then you have a better possibility to fix the issue. Hi All, The issue still exist in the latest Git kernel. It's a PowerPC issue. I compiled the latest Git kernel on a PC today and there aren't any issues with the avahi daemon. Another Power Mac user reported the same issue on his G5. I tested with the AmigaOne X1000 and X5000 in the last days. I bisected today but I think the result isn't correct because it founds the other problem with ordering of PCSCSI definition in esp_rev enum. I don't know how to bisect if there is another issue at the same time. Maybe "git bisect skip"? 2086faae3c55a652cfbd369e18ecdb703aacc493 is the first bad commit commit 2086faae3c55a652cfbd369e18ecdb703aacc493 Author: Kars de Jong <jongk@linux-m68k.org> Date: Tue Nov 19 21:20:20 2019 +0100 scsi: esp_scsi: Correct ordering of PCSCSI definition in esp_rev enum The order of the definitions in the esp_rev enum is important. The values are used in comparisons for chip features. Add a comment to the enum explaining this. Also, the actual values for the enum fields are irrelevant, so remove the explicit values (suggested by Geert Uytterhoeven). This makes adding a new field in the middle of the enum easier. Finally, move the PCSCSI definition to the right place in the enum. In its previous location, at the end of the enum, the wrong values are written to the CONFIG3 register when used with FAST-SCSI targets. Link: https://lore.kernel.org/r/20191119202021.28720-2-jongk@linux-m68k.org Signed-off-by: Kars de Jong <jongk@linux-m68k.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> :040000 040000 cdc128596e33fb60406b5de9b17b79623c187c1a 48ceab06439f95285e8b30181e75f9a68c25fcb5 M drivers Cheers, Christian ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Latest Git kernel: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device @ 2020-02-05 13:03 ` Christian Zigotzky 0 siblings, 0 replies; 37+ messages in thread From: Christian Zigotzky @ 2020-02-05 13:03 UTC (permalink / raw) To: Jakub Kicinski Cc: DTML, Darren Stevens, mad skateman, Linux Kernel Mailing List, linuxppc-dev, contact, R.T.Dickinson, netdev, Christoph Hellwig On 03 February 2020 at 6:53 pm, Jakub Kicinski wrote: > On Sun, 2 Feb 2020 16:02:18 +0100, Christian Zigotzky wrote: >> On 02 February 2020 at 09:19 am, Christophe Leroy wrote: >>> Hello, >>> >>> Le 02/02/2020 à 01:08, Christian Zigotzky a écrit : >>>> Hello, >>>> >>>> We regularly compile and test Linux kernels every day during the >>>> merge window. Since Thursday we have very high CPU loads because of >>>> the avahi daemon on our desktop Linux systems (Ubuntu, Debian etc). >>>> >>>> Error message: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for >>>> device >>> Do you know which ioctl, on which device ? >>> Can you take a trace of running avahi-daemon with 'strace' ? >>> >>> Can you bisect ? >>> >>> Christophe >> Hi Christophe, >> Hi All, >> >> I figured out that the avahi-daemon has a problem with the IPv6 address >> of a network interface since the Git kernel from Thursday. (Log attached) >> This generates high CPU usage because the avahi-daemon tries to access >> the IPv6 address again and again and thereby it produces a lot of log >> messages. >> >> We figured out that the networking updates aren't responsible for this >> issue because we created a test kernel on Wednesday. The issue is >> somewhere in the commits from Wednesday night to Thursday (CET). > FWIW Thursday is when the latest networking pull came in, so could well > be networking related.. > >> Please compile the latest Git kernel and test it with a desktop linux >> distribution for example Ubuntu. In my point of view there are many >> desktop machines affected. Many server systems don't use the avahi >> daemon so they aren't affected. >> >> It's possible to deactivate the access to the IPv6 address with the >> following line in the file "/etc/avahi/avahi-daemon.conf": >> >> use-ipv6=no >> >> After a reboot the CPU usage is normal again. This is only a temporary >> solution. >> >> Unfortunately I don't have the time for bisecting next week. I have a >> lot of other work to do. In my point of view it is very important that >> you also compile the latest Git kernels. Then you will see the issue and >> then you have a better possibility to fix the issue. Hi All, The issue still exist in the latest Git kernel. It's a PowerPC issue. I compiled the latest Git kernel on a PC today and there aren't any issues with the avahi daemon. Another Power Mac user reported the same issue on his G5. I tested with the AmigaOne X1000 and X5000 in the last days. I bisected today but I think the result isn't correct because it founds the other problem with ordering of PCSCSI definition in esp_rev enum. I don't know how to bisect if there is another issue at the same time. Maybe "git bisect skip"? 2086faae3c55a652cfbd369e18ecdb703aacc493 is the first bad commit commit 2086faae3c55a652cfbd369e18ecdb703aacc493 Author: Kars de Jong <jongk@linux-m68k.org> Date: Tue Nov 19 21:20:20 2019 +0100 scsi: esp_scsi: Correct ordering of PCSCSI definition in esp_rev enum The order of the definitions in the esp_rev enum is important. The values are used in comparisons for chip features. Add a comment to the enum explaining this. Also, the actual values for the enum fields are irrelevant, so remove the explicit values (suggested by Geert Uytterhoeven). This makes adding a new field in the middle of the enum easier. Finally, move the PCSCSI definition to the right place in the enum. In its previous location, at the end of the enum, the wrong values are written to the CONFIG3 register when used with FAST-SCSI targets. Link: https://lore.kernel.org/r/20191119202021.28720-2-jongk@linux-m68k.org Signed-off-by: Kars de Jong <jongk@linux-m68k.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> :040000 040000 cdc128596e33fb60406b5de9b17b79623c187c1a 48ceab06439f95285e8b30181e75f9a68c25fcb5 M drivers Cheers, Christian ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Latest Git kernel: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device 2020-02-03 17:53 ` Jakub Kicinski (?) (?) @ 2020-02-05 14:36 ` Christian Zigotzky 2020-02-06 4:35 ` Michael Ellerman -1 siblings, 1 reply; 37+ messages in thread From: Christian Zigotzky @ 2020-02-05 14:36 UTC (permalink / raw) To: Jakub Kicinski Cc: DTML, Darren Stevens, mad skateman, Linux Kernel Mailing List, linuxppc-dev, contact, R.T.Dickinson, netdev, Christoph Hellwig [-- Attachment #1: Type: text/plain, Size: 1851 bytes --] Kernel 5.5 PowerPC is also affected. — Christian Christian Zigotzky wrote: Hi All, The issue with the avahi-daemon still exist in the latest Git kernel. It's a PowerPC issue. I compiled the latest Git kernel on a PC today and there aren't any issues with the avahi daemon. Another Power Mac user reported the same issue on his G5. I tested with the AmigaOne X1000 and X5000 in the last days. I bisected today but I think the result isn't correct because it found the other problem with ordering of PCSCSI definition in esp_rev enum. I don't know how to bisect if there is another issue at the same time. Maybe "git bisect skip"? 2086faae3c55a652cfbd369e18ecdb703aacc493 is the first bad commit commit 2086faae3c55a652cfbd369e18ecdb703aacc493 Author: Kars de Jong <jongk@linux-m68k.org> Date: Tue Nov 19 21:20:20 2019 +0100 scsi: esp_scsi: Correct ordering of PCSCSI definition in esp_rev enum The order of the definitions in the esp_rev enum is important. The values are used in comparisons for chip features. Add a comment to the enum explaining this. Also, the actual values for the enum fields are irrelevant, so remove the explicit values (suggested by Geert Uytterhoeven). This makes adding a new field in the middle of the enum easier. Finally, move the PCSCSI definition to the right place in the enum. In its previous location, at the end of the enum, the wrong values are written to the CONFIG3 register when used with FAST-SCSI targets. Link: https://lore.kernel.org/r/20191119202021.28720-2-jongk@linux-m68k.org Signed-off-by: Kars de Jong <jongk@linux-m68k.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> :040000 040000 cdc128596e33fb60406b5de9b17b79623c187c1a 48ceab06439f95285e8b30181e75f9a68c25fcb5 M drivers [-- Attachment #2: Type: text/html, Size: 6587 bytes --] ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Latest Git kernel: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device 2020-02-05 14:36 ` Christian Zigotzky @ 2020-02-06 4:35 ` Michael Ellerman 0 siblings, 0 replies; 37+ messages in thread From: Michael Ellerman @ 2020-02-06 4:35 UTC (permalink / raw) To: Christian Zigotzky, Jakub Kicinski Cc: Christophe Leroy, DTML, Darren Stevens, Linux Kernel Mailing List, linuxppc-dev, contact, R.T.Dickinson, Christoph Hellwig, mad skateman, netdev Christian Zigotzky <chzigotzky@xenosoft.de> writes: > Kernel 5.5 PowerPC is also affected. I don't know what you mean by that. What sha are you talking about? I have a system with avahi running and everything's fine. # grep use- /etc/avahi/avahi-daemon.conf use-ipv4=yes use-ipv6=yes # systemctl status -l --no-pager avahi-daemon ● avahi-daemon.service - Avahi mDNS/DNS-SD Stack Loaded: loaded (/lib/systemd/system/avahi-daemon.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2020-02-06 14:55:34 AEDT; 38min ago Main PID: 1884 (avahi-daemon) Status: "avahi-daemon 0.7 starting up." CGroup: /system.slice/avahi-daemon.service ├─1884 avahi-daemon: running [mpe-ubuntu-le.local] └─1888 avahi-daemon: chroot helper Feb 06 14:55:34 mpe-ubuntu-le avahi-daemon[1884]: Registering new address record for fe80::5054:ff:fe66:2a19 on eth0.*. Feb 06 14:55:34 mpe-ubuntu-le avahi-daemon[1884]: Registering new address record for 10.61.141.81 on eth0.IPv4. Feb 06 14:55:34 mpe-ubuntu-le avahi-daemon[1884]: Registering new address record for ::1 on lo.*. Feb 06 14:55:34 mpe-ubuntu-le avahi-daemon[1884]: Registering new address record for 127.0.0.1 on lo.IPv4. Feb 06 14:55:34 mpe-ubuntu-le systemd[1]: Started Avahi mDNS/DNS-SD Stack. Feb 06 14:55:35 mpe-ubuntu-le avahi-daemon[1884]: Server startup complete. Host name is mpe-ubuntu-le.local. Local service cookie is 3972418141. Feb 06 14:55:38 mpe-ubuntu-le avahi-daemon[1884]: Leaving mDNS multicast group on interface eth0.IPv6 with address fe80::5054:ff:fe66:2a19. Feb 06 14:55:38 mpe-ubuntu-le avahi-daemon[1884]: Joining mDNS multicast group on interface eth0.IPv6 with address fd69:d75f:b8b5:61:5054:ff:fe66:2a19. Feb 06 14:55:38 mpe-ubuntu-le avahi-daemon[1884]: Registering new address record for fd69:d75f:b8b5:61:5054:ff:fe66:2a19 on eth0.*. Feb 06 14:55:38 mpe-ubuntu-le avahi-daemon[1884]: Withdrawing address record for fe80::5054:ff:fe66:2a19 on eth0. # uname -r 5.5.0-gcc-8.2.0 The key question is what ioctl is it complaining about. You should be able to find that via strace. cheers > Christian Zigotzky wrote: > > Hi All, > > The issue with the avahi-daemon still exist in the latest Git kernel. It's a PowerPC issue. I compiled the latest Git kernel on a PC today and there aren't any issues with the avahi daemon. Another Power Mac user reported the same issue on his G5. I tested with the AmigaOne X1000 and X5000 in the last days. > > I bisected today but I think the result isn't correct because it found the other problem with ordering of PCSCSI definition in esp_rev enum. I don't know how to bisect if there is another issue at the same time. Maybe "git bisect skip"? > > 2086faae3c55a652cfbd369e18ecdb703aacc493 is the first bad commit > commit 2086faae3c55a652cfbd369e18ecdb703aacc493 > Author: Kars de Jong <jongk@linux-m68k.org> > Date: Tue Nov 19 21:20:20 2019 +0100 > > scsi: esp_scsi: Correct ordering of PCSCSI definition in esp_rev enum > > The order of the definitions in the esp_rev enum is important. The values > are used in comparisons for chip features. > > Add a comment to the enum explaining this. > > Also, the actual values for the enum fields are irrelevant, so remove the > explicit values (suggested by Geert Uytterhoeven). This makes adding a new > field in the middle of the enum easier. > > Finally, move the PCSCSI definition to the right place in the enum. In its > previous location, at the end of the enum, the wrong values are written to > the CONFIG3 register when used with FAST-SCSI targets. > > Link: https://lore.kernel.org/r/20191119202021.28720-2-jongk@linux-m68k.org > Signed-off-by: Kars de Jong <jongk@linux-m68k.org> > Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> > > :040000 040000 cdc128596e33fb60406b5de9b17b79623c187c1a 48ceab06439f95285e8b30181e75f9a68c25fcb5 M drivers ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Latest Git kernel: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device @ 2020-02-06 4:35 ` Michael Ellerman 0 siblings, 0 replies; 37+ messages in thread From: Michael Ellerman @ 2020-02-06 4:35 UTC (permalink / raw) To: Christian Zigotzky, Jakub Kicinski Cc: DTML, Darren Stevens, mad skateman, netdev, Linux Kernel Mailing List, linuxppc-dev, contact, R.T.Dickinson, Christoph Hellwig Christian Zigotzky <chzigotzky@xenosoft.de> writes: > Kernel 5.5 PowerPC is also affected. I don't know what you mean by that. What sha are you talking about? I have a system with avahi running and everything's fine. # grep use- /etc/avahi/avahi-daemon.conf use-ipv4=yes use-ipv6=yes # systemctl status -l --no-pager avahi-daemon ● avahi-daemon.service - Avahi mDNS/DNS-SD Stack Loaded: loaded (/lib/systemd/system/avahi-daemon.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2020-02-06 14:55:34 AEDT; 38min ago Main PID: 1884 (avahi-daemon) Status: "avahi-daemon 0.7 starting up." CGroup: /system.slice/avahi-daemon.service ├─1884 avahi-daemon: running [mpe-ubuntu-le.local] └─1888 avahi-daemon: chroot helper Feb 06 14:55:34 mpe-ubuntu-le avahi-daemon[1884]: Registering new address record for fe80::5054:ff:fe66:2a19 on eth0.*. Feb 06 14:55:34 mpe-ubuntu-le avahi-daemon[1884]: Registering new address record for 10.61.141.81 on eth0.IPv4. Feb 06 14:55:34 mpe-ubuntu-le avahi-daemon[1884]: Registering new address record for ::1 on lo.*. Feb 06 14:55:34 mpe-ubuntu-le avahi-daemon[1884]: Registering new address record for 127.0.0.1 on lo.IPv4. Feb 06 14:55:34 mpe-ubuntu-le systemd[1]: Started Avahi mDNS/DNS-SD Stack. Feb 06 14:55:35 mpe-ubuntu-le avahi-daemon[1884]: Server startup complete. Host name is mpe-ubuntu-le.local. Local service cookie is 3972418141. Feb 06 14:55:38 mpe-ubuntu-le avahi-daemon[1884]: Leaving mDNS multicast group on interface eth0.IPv6 with address fe80::5054:ff:fe66:2a19. Feb 06 14:55:38 mpe-ubuntu-le avahi-daemon[1884]: Joining mDNS multicast group on interface eth0.IPv6 with address fd69:d75f:b8b5:61:5054:ff:fe66:2a19. Feb 06 14:55:38 mpe-ubuntu-le avahi-daemon[1884]: Registering new address record for fd69:d75f:b8b5:61:5054:ff:fe66:2a19 on eth0.*. Feb 06 14:55:38 mpe-ubuntu-le avahi-daemon[1884]: Withdrawing address record for fe80::5054:ff:fe66:2a19 on eth0. # uname -r 5.5.0-gcc-8.2.0 The key question is what ioctl is it complaining about. You should be able to find that via strace. cheers > Christian Zigotzky wrote: > > Hi All, > > The issue with the avahi-daemon still exist in the latest Git kernel. It's a PowerPC issue. I compiled the latest Git kernel on a PC today and there aren't any issues with the avahi daemon. Another Power Mac user reported the same issue on his G5. I tested with the AmigaOne X1000 and X5000 in the last days. > > I bisected today but I think the result isn't correct because it found the other problem with ordering of PCSCSI definition in esp_rev enum. I don't know how to bisect if there is another issue at the same time. Maybe "git bisect skip"? > > 2086faae3c55a652cfbd369e18ecdb703aacc493 is the first bad commit > commit 2086faae3c55a652cfbd369e18ecdb703aacc493 > Author: Kars de Jong <jongk@linux-m68k.org> > Date: Tue Nov 19 21:20:20 2019 +0100 > > scsi: esp_scsi: Correct ordering of PCSCSI definition in esp_rev enum > > The order of the definitions in the esp_rev enum is important. The values > are used in comparisons for chip features. > > Add a comment to the enum explaining this. > > Also, the actual values for the enum fields are irrelevant, so remove the > explicit values (suggested by Geert Uytterhoeven). This makes adding a new > field in the middle of the enum easier. > > Finally, move the PCSCSI definition to the right place in the enum. In its > previous location, at the end of the enum, the wrong values are written to > the CONFIG3 register when used with FAST-SCSI targets. > > Link: https://lore.kernel.org/r/20191119202021.28720-2-jongk@linux-m68k.org > Signed-off-by: Kars de Jong <jongk@linux-m68k.org> > Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> > > :040000 040000 cdc128596e33fb60406b5de9b17b79623c187c1a 48ceab06439f95285e8b30181e75f9a68c25fcb5 M drivers ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Latest Git kernel: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device 2020-02-06 4:35 ` Michael Ellerman @ 2020-02-06 14:28 ` Christian Zigotzky -1 siblings, 0 replies; 37+ messages in thread From: Christian Zigotzky @ 2020-02-06 14:28 UTC (permalink / raw) To: Michael Ellerman, Jakub Kicinski Cc: Christophe Leroy, DTML, Darren Stevens, Linux Kernel Mailing List, linuxppc-dev, contact, R.T.Dickinson, Christoph Hellwig, mad skateman, netdev On 06 February 2020 at 05:35 am, Michael Ellerman wrote: > Christian Zigotzky <chzigotzky@xenosoft.de> writes: >> Kernel 5.5 PowerPC is also affected. > I don't know what you mean by that. What sha are you talking about? > > I have a system with avahi running and everything's fine. > > # grep use- /etc/avahi/avahi-daemon.conf > use-ipv4=yes > use-ipv6=yes > > # systemctl status -l --no-pager avahi-daemon > ● avahi-daemon.service - Avahi mDNS/DNS-SD Stack > Loaded: loaded (/lib/systemd/system/avahi-daemon.service; enabled; vendor preset: enabled) > Active: active (running) since Thu 2020-02-06 14:55:34 AEDT; 38min ago > Main PID: 1884 (avahi-daemon) > Status: "avahi-daemon 0.7 starting up." > CGroup: /system.slice/avahi-daemon.service > ├─1884 avahi-daemon: running [mpe-ubuntu-le.local] > └─1888 avahi-daemon: chroot helper > > Feb 06 14:55:34 mpe-ubuntu-le avahi-daemon[1884]: Registering new address record for fe80::5054:ff:fe66:2a19 on eth0.*. > Feb 06 14:55:34 mpe-ubuntu-le avahi-daemon[1884]: Registering new address record for 10.61.141.81 on eth0.IPv4. > Feb 06 14:55:34 mpe-ubuntu-le avahi-daemon[1884]: Registering new address record for ::1 on lo.*. > Feb 06 14:55:34 mpe-ubuntu-le avahi-daemon[1884]: Registering new address record for 127.0.0.1 on lo.IPv4. > Feb 06 14:55:34 mpe-ubuntu-le systemd[1]: Started Avahi mDNS/DNS-SD Stack. > Feb 06 14:55:35 mpe-ubuntu-le avahi-daemon[1884]: Server startup complete. Host name is mpe-ubuntu-le.local. Local service cookie is 3972418141. > Feb 06 14:55:38 mpe-ubuntu-le avahi-daemon[1884]: Leaving mDNS multicast group on interface eth0.IPv6 with address fe80::5054:ff:fe66:2a19. > Feb 06 14:55:38 mpe-ubuntu-le avahi-daemon[1884]: Joining mDNS multicast group on interface eth0.IPv6 with address fd69:d75f:b8b5:61:5054:ff:fe66:2a19. > Feb 06 14:55:38 mpe-ubuntu-le avahi-daemon[1884]: Registering new address record for fd69:d75f:b8b5:61:5054:ff:fe66:2a19 on eth0.*. > Feb 06 14:55:38 mpe-ubuntu-le avahi-daemon[1884]: Withdrawing address record for fe80::5054:ff:fe66:2a19 on eth0. > > # uname -r > 5.5.0-gcc-8.2.0 > > > The key question is what ioctl is it complaining about. You should be > able to find that via strace. > > cheers > Hello Michael, Sorry it isn't true that the kernel 5.5 is also affected. A Power Mac G5 user told me that but this isn't correct. I compiled and tested the stable kernel 5.5.1 and 5.5.2 today and both kernels don't have the issue with the avahi daemon. Could you please also test the latest Git kernel? strace /usr/sbin/avahi-daemon ... poll([{fd=4, events=POLLIN}, {fd=16, events=POLLIN}, {fd=15, events=POLLIN}, {fd=14, events=POLLIN}, {fd=13, events=POLLIN}, {fd=12, events=POLLIN}, {fd=11, events=POLLIN}, {fd=10, events=POLLIN}, {fd=9, events=POLLIN}, {fd=8, events=POLLIN}, {fd=6, events=POLLIN}], 11, 65) = 2 ([{fd=12, revents=POLLIN}, {fd=9, revents=POLLIN}]) ioctl(12, FIONREAD, 0xffba6f24) = -1 ENOTTY (Inappropriate ioctl for device) write(2, "ioctl(): Inappropriate ioctl for"..., 39ioctl(): Inappropriate ioctl for device) = 39 write(2, "\n", 1 ) = 1 ... Thanks, Christian ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Latest Git kernel: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device @ 2020-02-06 14:28 ` Christian Zigotzky 0 siblings, 0 replies; 37+ messages in thread From: Christian Zigotzky @ 2020-02-06 14:28 UTC (permalink / raw) To: Michael Ellerman, Jakub Kicinski Cc: DTML, Darren Stevens, mad skateman, netdev, Linux Kernel Mailing List, linuxppc-dev, contact, R.T.Dickinson, Christoph Hellwig On 06 February 2020 at 05:35 am, Michael Ellerman wrote: > Christian Zigotzky <chzigotzky@xenosoft.de> writes: >> Kernel 5.5 PowerPC is also affected. > I don't know what you mean by that. What sha are you talking about? > > I have a system with avahi running and everything's fine. > > # grep use- /etc/avahi/avahi-daemon.conf > use-ipv4=yes > use-ipv6=yes > > # systemctl status -l --no-pager avahi-daemon > ● avahi-daemon.service - Avahi mDNS/DNS-SD Stack > Loaded: loaded (/lib/systemd/system/avahi-daemon.service; enabled; vendor preset: enabled) > Active: active (running) since Thu 2020-02-06 14:55:34 AEDT; 38min ago > Main PID: 1884 (avahi-daemon) > Status: "avahi-daemon 0.7 starting up." > CGroup: /system.slice/avahi-daemon.service > ├─1884 avahi-daemon: running [mpe-ubuntu-le.local] > └─1888 avahi-daemon: chroot helper > > Feb 06 14:55:34 mpe-ubuntu-le avahi-daemon[1884]: Registering new address record for fe80::5054:ff:fe66:2a19 on eth0.*. > Feb 06 14:55:34 mpe-ubuntu-le avahi-daemon[1884]: Registering new address record for 10.61.141.81 on eth0.IPv4. > Feb 06 14:55:34 mpe-ubuntu-le avahi-daemon[1884]: Registering new address record for ::1 on lo.*. > Feb 06 14:55:34 mpe-ubuntu-le avahi-daemon[1884]: Registering new address record for 127.0.0.1 on lo.IPv4. > Feb 06 14:55:34 mpe-ubuntu-le systemd[1]: Started Avahi mDNS/DNS-SD Stack. > Feb 06 14:55:35 mpe-ubuntu-le avahi-daemon[1884]: Server startup complete. Host name is mpe-ubuntu-le.local. Local service cookie is 3972418141. > Feb 06 14:55:38 mpe-ubuntu-le avahi-daemon[1884]: Leaving mDNS multicast group on interface eth0.IPv6 with address fe80::5054:ff:fe66:2a19. > Feb 06 14:55:38 mpe-ubuntu-le avahi-daemon[1884]: Joining mDNS multicast group on interface eth0.IPv6 with address fd69:d75f:b8b5:61:5054:ff:fe66:2a19. > Feb 06 14:55:38 mpe-ubuntu-le avahi-daemon[1884]: Registering new address record for fd69:d75f:b8b5:61:5054:ff:fe66:2a19 on eth0.*. > Feb 06 14:55:38 mpe-ubuntu-le avahi-daemon[1884]: Withdrawing address record for fe80::5054:ff:fe66:2a19 on eth0. > > # uname -r > 5.5.0-gcc-8.2.0 > > > The key question is what ioctl is it complaining about. You should be > able to find that via strace. > > cheers > Hello Michael, Sorry it isn't true that the kernel 5.5 is also affected. A Power Mac G5 user told me that but this isn't correct. I compiled and tested the stable kernel 5.5.1 and 5.5.2 today and both kernels don't have the issue with the avahi daemon. Could you please also test the latest Git kernel? strace /usr/sbin/avahi-daemon ... poll([{fd=4, events=POLLIN}, {fd=16, events=POLLIN}, {fd=15, events=POLLIN}, {fd=14, events=POLLIN}, {fd=13, events=POLLIN}, {fd=12, events=POLLIN}, {fd=11, events=POLLIN}, {fd=10, events=POLLIN}, {fd=9, events=POLLIN}, {fd=8, events=POLLIN}, {fd=6, events=POLLIN}], 11, 65) = 2 ([{fd=12, revents=POLLIN}, {fd=9, revents=POLLIN}]) ioctl(12, FIONREAD, 0xffba6f24) = -1 ENOTTY (Inappropriate ioctl for device) write(2, "ioctl(): Inappropriate ioctl for"..., 39ioctl(): Inappropriate ioctl for device) = 39 write(2, "\n", 1 ) = 1 ... Thanks, Christian ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Latest Git kernel: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device 2020-02-06 14:28 ` Christian Zigotzky @ 2020-02-08 12:36 ` Michael Ellerman -1 siblings, 0 replies; 37+ messages in thread From: Michael Ellerman @ 2020-02-08 12:36 UTC (permalink / raw) To: Christian Zigotzky, Jakub Kicinski Cc: Christophe Leroy, DTML, Darren Stevens, Linux Kernel Mailing List, linuxppc-dev, contact, R.T.Dickinson, Christoph Hellwig, mad skateman, netdev Christian Zigotzky <chzigotzky@xenosoft.de> writes: > On 06 February 2020 at 05:35 am, Michael Ellerman wrote: >> Christian Zigotzky <chzigotzky@xenosoft.de> writes: >>> Kernel 5.5 PowerPC is also affected. >> I don't know what you mean by that. What sha are you talking about? >> >> I have a system with avahi running and everything's fine. >> >> # grep use- /etc/avahi/avahi-daemon.conf >> use-ipv4=yes >> use-ipv6=yes >> >> # systemctl status -l --no-pager avahi-daemon >> ● avahi-daemon.service - Avahi mDNS/DNS-SD Stack >> Loaded: loaded (/lib/systemd/system/avahi-daemon.service; enabled; vendor preset: enabled) >> Active: active (running) since Thu 2020-02-06 14:55:34 AEDT; 38min ago >> Main PID: 1884 (avahi-daemon) >> Status: "avahi-daemon 0.7 starting up." >> CGroup: /system.slice/avahi-daemon.service >> ├─1884 avahi-daemon: running [mpe-ubuntu-le.local] >> └─1888 avahi-daemon: chroot helper >> >> Feb 06 14:55:34 mpe-ubuntu-le avahi-daemon[1884]: Registering new address record for fe80::5054:ff:fe66:2a19 on eth0.*. >> Feb 06 14:55:34 mpe-ubuntu-le avahi-daemon[1884]: Registering new address record for 10.61.141.81 on eth0.IPv4. >> Feb 06 14:55:34 mpe-ubuntu-le avahi-daemon[1884]: Registering new address record for ::1 on lo.*. >> Feb 06 14:55:34 mpe-ubuntu-le avahi-daemon[1884]: Registering new address record for 127.0.0.1 on lo.IPv4. >> Feb 06 14:55:34 mpe-ubuntu-le systemd[1]: Started Avahi mDNS/DNS-SD Stack. >> Feb 06 14:55:35 mpe-ubuntu-le avahi-daemon[1884]: Server startup complete. Host name is mpe-ubuntu-le.local. Local service cookie is 3972418141. >> Feb 06 14:55:38 mpe-ubuntu-le avahi-daemon[1884]: Leaving mDNS multicast group on interface eth0.IPv6 with address fe80::5054:ff:fe66:2a19. >> Feb 06 14:55:38 mpe-ubuntu-le avahi-daemon[1884]: Joining mDNS multicast group on interface eth0.IPv6 with address fd69:d75f:b8b5:61:5054:ff:fe66:2a19. >> Feb 06 14:55:38 mpe-ubuntu-le avahi-daemon[1884]: Registering new address record for fd69:d75f:b8b5:61:5054:ff:fe66:2a19 on eth0.*. >> Feb 06 14:55:38 mpe-ubuntu-le avahi-daemon[1884]: Withdrawing address record for fe80::5054:ff:fe66:2a19 on eth0. >> >> # uname -r >> 5.5.0-gcc-8.2.0 >> >> >> The key question is what ioctl is it complaining about. You should be >> able to find that via strace. >> >> cheers >> > Hello Michael, > > Sorry it isn't true that the kernel 5.5 is also affected. A Power Mac G5 > user told me that but this isn't correct. I compiled and tested the > stable kernel 5.5.1 and 5.5.2 today and both kernels don't have the > issue with the avahi daemon. OK good to know. > Could you please also test the latest Git kernel? That's literally all I ever do. The problem here is you didn't tell me you were running a big endian distro, which uses compat mode. In hindsight I should have thought of that. Now that I know that, I can reproduce the bug: Feb 08 23:31:12 mpe-ubuntu-be avahi-daemon[24819]: ioctl(): Inappropriate ioctl for device Feb 08 23:31:12 mpe-ubuntu-be avahi-daemon[24819]: ioctl(): Inappropriate ioctl for device Feb 08 23:31:12 mpe-ubuntu-be avahi-daemon[24819]: ioctl(): Inappropriate ioctl for device Feb 08 23:31:12 mpe-ubuntu-be avahi-daemon[24819]: ioctl(): Inappropriate ioctl for device But it seems you've already identified the problem commit, thanks for bisecting. I'm sure Arnd will be able to fix it now that you've identified the problematic commit. cheers > strace /usr/sbin/avahi-daemon > > ... > poll([{fd=4, events=POLLIN}, {fd=16, events=POLLIN}, {fd=15, > events=POLLIN}, {fd=14, events=POLLIN}, {fd=13, events=POLLIN}, {fd=12, > events=POLLIN}, {fd=11, events=POLLIN}, {fd=10, events=POLLIN}, {fd=9, > events=POLLIN}, {fd=8, events=POLLIN}, {fd=6, events=POLLIN}], 11, 65) = > 2 ([{fd=12, revents=POLLIN}, {fd=9, revents=POLLIN}]) > ioctl(12, FIONREAD, 0xffba6f24) = -1 ENOTTY (Inappropriate ioctl > for device) > write(2, "ioctl(): Inappropriate ioctl for"..., 39ioctl(): Inappropriate > ioctl for device) = 39 > write(2, "\n", 1 > ) = 1 > ... > > Thanks, > Christian ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Latest Git kernel: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device @ 2020-02-08 12:36 ` Michael Ellerman 0 siblings, 0 replies; 37+ messages in thread From: Michael Ellerman @ 2020-02-08 12:36 UTC (permalink / raw) To: Christian Zigotzky, Jakub Kicinski Cc: DTML, Darren Stevens, mad skateman, netdev, Linux Kernel Mailing List, linuxppc-dev, contact, R.T.Dickinson, Christoph Hellwig Christian Zigotzky <chzigotzky@xenosoft.de> writes: > On 06 February 2020 at 05:35 am, Michael Ellerman wrote: >> Christian Zigotzky <chzigotzky@xenosoft.de> writes: >>> Kernel 5.5 PowerPC is also affected. >> I don't know what you mean by that. What sha are you talking about? >> >> I have a system with avahi running and everything's fine. >> >> # grep use- /etc/avahi/avahi-daemon.conf >> use-ipv4=yes >> use-ipv6=yes >> >> # systemctl status -l --no-pager avahi-daemon >> ● avahi-daemon.service - Avahi mDNS/DNS-SD Stack >> Loaded: loaded (/lib/systemd/system/avahi-daemon.service; enabled; vendor preset: enabled) >> Active: active (running) since Thu 2020-02-06 14:55:34 AEDT; 38min ago >> Main PID: 1884 (avahi-daemon) >> Status: "avahi-daemon 0.7 starting up." >> CGroup: /system.slice/avahi-daemon.service >> ├─1884 avahi-daemon: running [mpe-ubuntu-le.local] >> └─1888 avahi-daemon: chroot helper >> >> Feb 06 14:55:34 mpe-ubuntu-le avahi-daemon[1884]: Registering new address record for fe80::5054:ff:fe66:2a19 on eth0.*. >> Feb 06 14:55:34 mpe-ubuntu-le avahi-daemon[1884]: Registering new address record for 10.61.141.81 on eth0.IPv4. >> Feb 06 14:55:34 mpe-ubuntu-le avahi-daemon[1884]: Registering new address record for ::1 on lo.*. >> Feb 06 14:55:34 mpe-ubuntu-le avahi-daemon[1884]: Registering new address record for 127.0.0.1 on lo.IPv4. >> Feb 06 14:55:34 mpe-ubuntu-le systemd[1]: Started Avahi mDNS/DNS-SD Stack. >> Feb 06 14:55:35 mpe-ubuntu-le avahi-daemon[1884]: Server startup complete. Host name is mpe-ubuntu-le.local. Local service cookie is 3972418141. >> Feb 06 14:55:38 mpe-ubuntu-le avahi-daemon[1884]: Leaving mDNS multicast group on interface eth0.IPv6 with address fe80::5054:ff:fe66:2a19. >> Feb 06 14:55:38 mpe-ubuntu-le avahi-daemon[1884]: Joining mDNS multicast group on interface eth0.IPv6 with address fd69:d75f:b8b5:61:5054:ff:fe66:2a19. >> Feb 06 14:55:38 mpe-ubuntu-le avahi-daemon[1884]: Registering new address record for fd69:d75f:b8b5:61:5054:ff:fe66:2a19 on eth0.*. >> Feb 06 14:55:38 mpe-ubuntu-le avahi-daemon[1884]: Withdrawing address record for fe80::5054:ff:fe66:2a19 on eth0. >> >> # uname -r >> 5.5.0-gcc-8.2.0 >> >> >> The key question is what ioctl is it complaining about. You should be >> able to find that via strace. >> >> cheers >> > Hello Michael, > > Sorry it isn't true that the kernel 5.5 is also affected. A Power Mac G5 > user told me that but this isn't correct. I compiled and tested the > stable kernel 5.5.1 and 5.5.2 today and both kernels don't have the > issue with the avahi daemon. OK good to know. > Could you please also test the latest Git kernel? That's literally all I ever do. The problem here is you didn't tell me you were running a big endian distro, which uses compat mode. In hindsight I should have thought of that. Now that I know that, I can reproduce the bug: Feb 08 23:31:12 mpe-ubuntu-be avahi-daemon[24819]: ioctl(): Inappropriate ioctl for device Feb 08 23:31:12 mpe-ubuntu-be avahi-daemon[24819]: ioctl(): Inappropriate ioctl for device Feb 08 23:31:12 mpe-ubuntu-be avahi-daemon[24819]: ioctl(): Inappropriate ioctl for device Feb 08 23:31:12 mpe-ubuntu-be avahi-daemon[24819]: ioctl(): Inappropriate ioctl for device But it seems you've already identified the problem commit, thanks for bisecting. I'm sure Arnd will be able to fix it now that you've identified the problematic commit. cheers > strace /usr/sbin/avahi-daemon > > ... > poll([{fd=4, events=POLLIN}, {fd=16, events=POLLIN}, {fd=15, > events=POLLIN}, {fd=14, events=POLLIN}, {fd=13, events=POLLIN}, {fd=12, > events=POLLIN}, {fd=11, events=POLLIN}, {fd=10, events=POLLIN}, {fd=9, > events=POLLIN}, {fd=8, events=POLLIN}, {fd=6, events=POLLIN}], 11, 65) = > 2 ([{fd=12, revents=POLLIN}, {fd=9, revents=POLLIN}]) > ioctl(12, FIONREAD, 0xffba6f24) = -1 ENOTTY (Inappropriate ioctl > for device) > write(2, "ioctl(): Inappropriate ioctl for"..., 39ioctl(): Inappropriate > ioctl for device) = 39 > write(2, "\n", 1 > ) = 1 > ... > > Thanks, > Christian ^ permalink raw reply [flat|nested] 37+ messages in thread
* Latest Git kernel: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device 2020-02-06 4:35 ` Michael Ellerman @ 2020-02-07 14:34 ` Christian Zigotzky -1 siblings, 0 replies; 37+ messages in thread From: Christian Zigotzky @ 2020-02-07 14:34 UTC (permalink / raw) To: arnd Cc: Michael Ellerman, Jakub Kicinski, Christophe Leroy, DTML, Darren Stevens, Linux Kernel Mailing List, linuxppc-dev, contact, R.T.Dickinson, Christoph Hellwig, mad skateman, netdev, Christian Zigotzky [-- Attachment #1: Type: text/plain, Size: 3295 bytes --] Hello Arnd, We regularly compile and test Linux kernels every day during the merge window. Since Thursday last week we have very high CPU usage because of the avahi daemon on our desktop Linux systems (Ubuntu, Debian etc). The avahi daemon produces a lot of the following log message. This generates high CPU usage. Error message: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device strace /usr/sbin/avahi-daemon: poll([{fd=4, events=POLLIN}, {fd=16, events=POLLIN}, {fd=15, events=POLLIN}, {fd=14, events=POLLIN}, {fd=13, events=POLLIN}, {fd=12, events=POLLIN}, {fd=11, events=POLLIN}, {fd=10, events=POLLIN}, {fd=9, events=POLLIN}, {fd=8, events=POLLIN}, {fd=6, events=POLLIN}], 11, 65) = 2 ([{fd=12, revents=POLLIN}, {fd=9, revents=POLLIN}]) ioctl(12, FIONREAD, 0xffba6f24) = -1 ENOTTY (Inappropriate ioctl for device) write(2, "ioctl(): Inappropriate ioctl for"..., 39ioctl(): Inappropriate ioctl for device) = 39 write(2, "\n", 1 ) = 1 ---------------------- I bisected the latest kernel source code today. Result: 77b9040195dea3fcddf19e136c9e99a501351778 is the first bad commit commit 77b9040195dea3fcddf19e136c9e99a501351778 Author: Arnd Bergmann <arnd@arndb.de> Date: Wed Nov 27 21:25:36 2019 +0100 compat_ioctl: simplify the implementation Now that both native and compat ioctl syscalls are in the same file, a couple of simplifications can be made, bringing the implementation closer together: - do_vfs_ioctl(), ioctl_preallocate(), and compat_ioctl_preallocate() can become static, allowing the compiler to optimize better - slightly update the coding style for consistency between the functions. - rather than listing each command in two switch statements for the compat case, just call a single function that has all the common commands. As a side-effect, FS_IOC_RESVSP/FS_IOC_RESVSP64 are now available to x86 compat tasks, along with FS_IOC_RESVSP_32/FS_IOC_RESVSP64_32. This is harmless for i386 emulation, and can be considered a bugfix for x32 emulation, which never supported these in the past. Reviewed-by: Ben Hutchings <ben.hutchings@codethink.co.uk> Signed-off-by: Arnd Bergmann <arnd@arndb.de> :040000 040000 5c4b62f4d1bfe643d3bbf9d9a3b50ee50ae0f159 5ca610e3197df96adfcae4f94fceeb496756609b M fs :040000 040000 086f2e2ac49384988733cbb706243943748c4ce7 b906926e53dfa2e8927629e77a0708dda6f49d31 M include ---------------------- Link to the first bad commit: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=77b9040195dea3fcddf19e136c9e99a501351778 I was able to revert the first bad commit. git revert 77b9040195dea3fcddf19e136c9e99a501351778 [master a91dcf9dc14c] Revert "compat_ioctl: simplify the implementation" 4 files changed, 105 insertions(+), 64 deletions(-) After that the avahi daemon works without any problems again. I created a patch today. (attached) It is also possible to deactivate the avahi daemon with the following lines in the file "/etc/avahi/avahi-daemon.conf": use-ipv4=no use-ipv6=no Could you please check your commit? Thanks, Christian [-- Attachment #2: compat_ioctl-v1.patch --] [-- Type: text/x-patch, Size: 9092 bytes --] diff -rupN a/fs/internal.h b/fs/internal.h --- a/fs/internal.h 2020-02-07 13:20:46.294317088 +0100 +++ b/fs/internal.h 2020-02-07 13:16:06.731416797 +0100 @@ -182,6 +182,12 @@ extern void mnt_pin_kill(struct mount *m */ extern const struct dentry_operations ns_dentry_operations; +/* + * fs/ioctl.c + */ +extern int do_vfs_ioctl(struct file *file, unsigned int fd, unsigned int cmd, + unsigned long arg); + /* direct-io.c: */ int sb_init_dio_done_wq(struct super_block *sb); diff -rupN a/fs/ioctl.c b/fs/ioctl.c --- a/fs/ioctl.c 2020-02-07 13:20:46.294317088 +0100 +++ b/fs/ioctl.c 2020-02-07 13:16:06.331418365 +0100 @@ -467,7 +467,7 @@ EXPORT_SYMBOL(generic_block_fiemap); * Only the l_start, l_len and l_whence fields of the 'struct space_resv' * are used here, rest are ignored. */ -static int ioctl_preallocate(struct file *filp, int mode, void __user *argp) +int ioctl_preallocate(struct file *filp, int mode, void __user *argp) { struct inode *inode = file_inode(filp); struct space_resv sr; @@ -495,8 +495,8 @@ static int ioctl_preallocate(struct file /* on ia32 l_start is on a 32-bit boundary */ #if defined CONFIG_COMPAT && defined(CONFIG_X86_64) /* just account for different alignment */ -static int compat_ioctl_preallocate(struct file *file, int mode, - struct space_resv_32 __user *argp) +int compat_ioctl_preallocate(struct file *file, int mode, + struct space_resv_32 __user *argp) { struct inode *inode = file_inode(file); struct space_resv_32 sr; @@ -521,9 +521,11 @@ static int compat_ioctl_preallocate(stru } #endif -static int file_ioctl(struct file *filp, unsigned int cmd, int __user *p) +static int file_ioctl(struct file *filp, unsigned int cmd, + unsigned long arg) { struct inode *inode = file_inode(filp); + int __user *p = (int __user *)arg; switch (cmd) { case FIBMAP: @@ -540,7 +542,7 @@ static int file_ioctl(struct file *filp, return ioctl_preallocate(filp, FALLOC_FL_ZERO_RANGE, p); } - return -ENOIOCTLCMD; + return vfs_ioctl(filp, cmd, arg); } static int ioctl_fionbio(struct file *filp, int __user *argp) @@ -659,48 +661,53 @@ out: } /* + * When you add any new common ioctls to the switches above and below + * please update compat_sys_ioctl() too. + * * do_vfs_ioctl() is not for drivers and not intended to be EXPORT_SYMBOL()'d. * It's just a simple helper for sys_ioctl and compat_sys_ioctl. - * - * When you add any new common ioctls to the switches above and below, - * please ensure they have compatible arguments in compat mode. */ -static int do_vfs_ioctl(struct file *filp, unsigned int fd, - unsigned int cmd, unsigned long arg) +int do_vfs_ioctl(struct file *filp, unsigned int fd, unsigned int cmd, + unsigned long arg) { + int error = 0; void __user *argp = (void __user *)arg; struct inode *inode = file_inode(filp); switch (cmd) { case FIOCLEX: set_close_on_exec(fd, 1); - return 0; + break; case FIONCLEX: set_close_on_exec(fd, 0); - return 0; + break; case FIONBIO: - return ioctl_fionbio(filp, argp); + error = ioctl_fionbio(filp, argp); + break; case FIOASYNC: - return ioctl_fioasync(fd, filp, argp); + error = ioctl_fioasync(fd, filp, argp); + break; case FIOQSIZE: if (S_ISDIR(inode->i_mode) || S_ISREG(inode->i_mode) || S_ISLNK(inode->i_mode)) { loff_t res = inode_get_bytes(inode); - return copy_to_user(argp, &res, sizeof(res)) ? - -EFAULT : 0; - } - - return -ENOTTY; + error = copy_to_user(argp, &res, sizeof(res)) ? + -EFAULT : 0; + } else + error = -ENOTTY; + break; case FIFREEZE: - return ioctl_fsfreeze(filp); + error = ioctl_fsfreeze(filp); + break; case FITHAW: - return ioctl_fsthaw(filp); + error = ioctl_fsthaw(filp); + break; case FS_IOC_FIEMAP: return ioctl_fiemap(filp, argp); @@ -709,7 +716,6 @@ static int do_vfs_ioctl(struct file *fil /* anon_bdev filesystems may not have a block size */ if (!inode->i_sb->s_blocksize) return -EINVAL; - return put_user(inode->i_sb->s_blocksize, (int __user *)argp); case FICLONE: @@ -723,30 +729,24 @@ static int do_vfs_ioctl(struct file *fil default: if (S_ISREG(inode->i_mode)) - return file_ioctl(filp, cmd, argp); + error = file_ioctl(filp, cmd, arg); + else + error = vfs_ioctl(filp, cmd, arg); break; } - - return -ENOIOCTLCMD; + return error; } int ksys_ioctl(unsigned int fd, unsigned int cmd, unsigned long arg) { - struct fd f = fdget(fd); int error; + struct fd f = fdget(fd); if (!f.file) return -EBADF; - error = security_file_ioctl(f.file, cmd, arg); - if (error) - goto out; - - error = do_vfs_ioctl(f.file, fd, cmd, arg); - if (error == -ENOIOCTLCMD) - error = vfs_ioctl(f.file, cmd, arg); - -out: + if (!error) + error = do_vfs_ioctl(f.file, fd, cmd, arg); fdput(f); return error; } @@ -790,63 +790,92 @@ long compat_ptr_ioctl(struct file *file, EXPORT_SYMBOL(compat_ptr_ioctl); COMPAT_SYSCALL_DEFINE3(ioctl, unsigned int, fd, unsigned int, cmd, - compat_ulong_t, arg) + compat_ulong_t, arg32) { + unsigned long arg = arg32; struct fd f = fdget(fd); - int error; - + int error = -EBADF; if (!f.file) - return -EBADF; + goto out; /* RED-PEN how should LSM module know it's handling 32bit? */ error = security_file_ioctl(f.file, cmd, arg); if (error) - goto out; + goto out_fput; switch (cmd) { - /* FICLONE takes an int argument, so don't use compat_ptr() */ + /* these are never seen by ->ioctl(), no argument or int argument */ + case FIOCLEX: + case FIONCLEX: + case FIFREEZE: + case FITHAW: case FICLONE: - error = ioctl_file_clone(f.file, arg, 0, 0, 0); - break; - -#if defined(CONFIG_X86_64) + goto do_ioctl; + /* these are never seen by ->ioctl(), pointer argument */ + case FIONBIO: + case FIOASYNC: + case FIOQSIZE: + case FS_IOC_FIEMAP: + case FIGETBSZ: + case FICLONERANGE: + case FIDEDUPERANGE: + goto found_handler; + /* + * The next group is the stuff handled inside file_ioctl(). + * For regular files these never reach ->ioctl(); for + * devices, sockets, etc. they do and one (FIONREAD) is + * even accepted in some cases. In all those cases + * argument has the same type, so we can handle these + * here, shunting them towards do_vfs_ioctl(). + * ->compat_ioctl() will never see any of those. + */ + /* pointer argument, never actually handled by ->ioctl() */ + case FIBMAP: + goto found_handler; + /* handled by some ->ioctl(); always a pointer to int */ + case FIONREAD: + goto found_handler; /* these get messy on amd64 due to alignment differences */ +#if defined(CONFIG_X86_64) case FS_IOC_RESVSP_32: case FS_IOC_RESVSP64_32: error = compat_ioctl_preallocate(f.file, 0, compat_ptr(arg)); - break; + goto out_fput; case FS_IOC_UNRESVSP_32: case FS_IOC_UNRESVSP64_32: error = compat_ioctl_preallocate(f.file, FALLOC_FL_PUNCH_HOLE, compat_ptr(arg)); - break; + goto out_fput; case FS_IOC_ZERO_RANGE_32: error = compat_ioctl_preallocate(f.file, FALLOC_FL_ZERO_RANGE, compat_ptr(arg)); - break; + goto out_fput; +#else + case FS_IOC_RESVSP: + case FS_IOC_RESVSP64: + case FS_IOC_UNRESVSP: + case FS_IOC_UNRESVSP64: + case FS_IOC_ZERO_RANGE: + goto found_handler; #endif - /* - * everything else in do_vfs_ioctl() takes either a compatible - * pointer argument or no argument -- call it with a modified - * argument. - */ default: - error = do_vfs_ioctl(f.file, fd, cmd, - (unsigned long)compat_ptr(arg)); - if (error != -ENOIOCTLCMD) - break; - - if (f.file->f_op->compat_ioctl) + if (f.file->f_op->compat_ioctl) { error = f.file->f_op->compat_ioctl(f.file, cmd, arg); - if (error == -ENOIOCTLCMD) - error = -ENOTTY; - break; + if (error != -ENOIOCTLCMD) + goto out_fput; + } + error = -ENOTTY; + goto out_fput; } - out: + found_handler: + arg = (unsigned long)compat_ptr(arg); + do_ioctl: + error = do_vfs_ioctl(f.file, fd, cmd, arg); + out_fput: fdput(f); - + out: return error; } #endif diff -rupN a/include/linux/falloc.h b/include/linux/falloc.h --- a/include/linux/falloc.h 2020-02-07 13:20:46.382316741 +0100 +++ b/include/linux/falloc.h 2020-02-07 13:16:06.331418365 +0100 @@ -51,6 +51,8 @@ struct space_resv_32 { #define FS_IOC_UNRESVSP64_32 _IOW ('X', 43, struct space_resv_32) #define FS_IOC_ZERO_RANGE_32 _IOW ('X', 57, struct space_resv_32) +int compat_ioctl_preallocate(struct file *, int, struct space_resv_32 __user *); + #endif #endif /* _FALLOC_H_ */ diff -rupN a/include/linux/fs.h b/include/linux/fs.h --- a/include/linux/fs.h 2020-02-07 13:20:46.382316741 +0100 +++ b/include/linux/fs.h 2020-02-07 13:16:06.731416797 +0100 @@ -2563,6 +2563,10 @@ extern int finish_open(struct file *file int (*open)(struct inode *, struct file *)); extern int finish_no_open(struct file *file, struct dentry *dentry); +/* fs/ioctl.c */ + +extern int ioctl_preallocate(struct file *filp, int mode, void __user *argp); + /* fs/dcache.c */ extern void __init vfs_caches_init_early(void); extern void __init vfs_caches_init(void); ^ permalink raw reply [flat|nested] 37+ messages in thread
* Latest Git kernel: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device @ 2020-02-07 14:34 ` Christian Zigotzky 0 siblings, 0 replies; 37+ messages in thread From: Christian Zigotzky @ 2020-02-07 14:34 UTC (permalink / raw) To: arnd Cc: DTML, Darren Stevens, mad skateman, Linux Kernel Mailing List, linuxppc-dev, contact, R.T.Dickinson, netdev, Jakub Kicinski, Christoph Hellwig, Christian Zigotzky [-- Attachment #1: Type: text/plain, Size: 3295 bytes --] Hello Arnd, We regularly compile and test Linux kernels every day during the merge window. Since Thursday last week we have very high CPU usage because of the avahi daemon on our desktop Linux systems (Ubuntu, Debian etc). The avahi daemon produces a lot of the following log message. This generates high CPU usage. Error message: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device strace /usr/sbin/avahi-daemon: poll([{fd=4, events=POLLIN}, {fd=16, events=POLLIN}, {fd=15, events=POLLIN}, {fd=14, events=POLLIN}, {fd=13, events=POLLIN}, {fd=12, events=POLLIN}, {fd=11, events=POLLIN}, {fd=10, events=POLLIN}, {fd=9, events=POLLIN}, {fd=8, events=POLLIN}, {fd=6, events=POLLIN}], 11, 65) = 2 ([{fd=12, revents=POLLIN}, {fd=9, revents=POLLIN}]) ioctl(12, FIONREAD, 0xffba6f24) = -1 ENOTTY (Inappropriate ioctl for device) write(2, "ioctl(): Inappropriate ioctl for"..., 39ioctl(): Inappropriate ioctl for device) = 39 write(2, "\n", 1 ) = 1 ---------------------- I bisected the latest kernel source code today. Result: 77b9040195dea3fcddf19e136c9e99a501351778 is the first bad commit commit 77b9040195dea3fcddf19e136c9e99a501351778 Author: Arnd Bergmann <arnd@arndb.de> Date: Wed Nov 27 21:25:36 2019 +0100 compat_ioctl: simplify the implementation Now that both native and compat ioctl syscalls are in the same file, a couple of simplifications can be made, bringing the implementation closer together: - do_vfs_ioctl(), ioctl_preallocate(), and compat_ioctl_preallocate() can become static, allowing the compiler to optimize better - slightly update the coding style for consistency between the functions. - rather than listing each command in two switch statements for the compat case, just call a single function that has all the common commands. As a side-effect, FS_IOC_RESVSP/FS_IOC_RESVSP64 are now available to x86 compat tasks, along with FS_IOC_RESVSP_32/FS_IOC_RESVSP64_32. This is harmless for i386 emulation, and can be considered a bugfix for x32 emulation, which never supported these in the past. Reviewed-by: Ben Hutchings <ben.hutchings@codethink.co.uk> Signed-off-by: Arnd Bergmann <arnd@arndb.de> :040000 040000 5c4b62f4d1bfe643d3bbf9d9a3b50ee50ae0f159 5ca610e3197df96adfcae4f94fceeb496756609b M fs :040000 040000 086f2e2ac49384988733cbb706243943748c4ce7 b906926e53dfa2e8927629e77a0708dda6f49d31 M include ---------------------- Link to the first bad commit: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=77b9040195dea3fcddf19e136c9e99a501351778 I was able to revert the first bad commit. git revert 77b9040195dea3fcddf19e136c9e99a501351778 [master a91dcf9dc14c] Revert "compat_ioctl: simplify the implementation" 4 files changed, 105 insertions(+), 64 deletions(-) After that the avahi daemon works without any problems again. I created a patch today. (attached) It is also possible to deactivate the avahi daemon with the following lines in the file "/etc/avahi/avahi-daemon.conf": use-ipv4=no use-ipv6=no Could you please check your commit? Thanks, Christian [-- Attachment #2: compat_ioctl-v1.patch --] [-- Type: text/x-patch, Size: 9092 bytes --] diff -rupN a/fs/internal.h b/fs/internal.h --- a/fs/internal.h 2020-02-07 13:20:46.294317088 +0100 +++ b/fs/internal.h 2020-02-07 13:16:06.731416797 +0100 @@ -182,6 +182,12 @@ extern void mnt_pin_kill(struct mount *m */ extern const struct dentry_operations ns_dentry_operations; +/* + * fs/ioctl.c + */ +extern int do_vfs_ioctl(struct file *file, unsigned int fd, unsigned int cmd, + unsigned long arg); + /* direct-io.c: */ int sb_init_dio_done_wq(struct super_block *sb); diff -rupN a/fs/ioctl.c b/fs/ioctl.c --- a/fs/ioctl.c 2020-02-07 13:20:46.294317088 +0100 +++ b/fs/ioctl.c 2020-02-07 13:16:06.331418365 +0100 @@ -467,7 +467,7 @@ EXPORT_SYMBOL(generic_block_fiemap); * Only the l_start, l_len and l_whence fields of the 'struct space_resv' * are used here, rest are ignored. */ -static int ioctl_preallocate(struct file *filp, int mode, void __user *argp) +int ioctl_preallocate(struct file *filp, int mode, void __user *argp) { struct inode *inode = file_inode(filp); struct space_resv sr; @@ -495,8 +495,8 @@ static int ioctl_preallocate(struct file /* on ia32 l_start is on a 32-bit boundary */ #if defined CONFIG_COMPAT && defined(CONFIG_X86_64) /* just account for different alignment */ -static int compat_ioctl_preallocate(struct file *file, int mode, - struct space_resv_32 __user *argp) +int compat_ioctl_preallocate(struct file *file, int mode, + struct space_resv_32 __user *argp) { struct inode *inode = file_inode(file); struct space_resv_32 sr; @@ -521,9 +521,11 @@ static int compat_ioctl_preallocate(stru } #endif -static int file_ioctl(struct file *filp, unsigned int cmd, int __user *p) +static int file_ioctl(struct file *filp, unsigned int cmd, + unsigned long arg) { struct inode *inode = file_inode(filp); + int __user *p = (int __user *)arg; switch (cmd) { case FIBMAP: @@ -540,7 +542,7 @@ static int file_ioctl(struct file *filp, return ioctl_preallocate(filp, FALLOC_FL_ZERO_RANGE, p); } - return -ENOIOCTLCMD; + return vfs_ioctl(filp, cmd, arg); } static int ioctl_fionbio(struct file *filp, int __user *argp) @@ -659,48 +661,53 @@ out: } /* + * When you add any new common ioctls to the switches above and below + * please update compat_sys_ioctl() too. + * * do_vfs_ioctl() is not for drivers and not intended to be EXPORT_SYMBOL()'d. * It's just a simple helper for sys_ioctl and compat_sys_ioctl. - * - * When you add any new common ioctls to the switches above and below, - * please ensure they have compatible arguments in compat mode. */ -static int do_vfs_ioctl(struct file *filp, unsigned int fd, - unsigned int cmd, unsigned long arg) +int do_vfs_ioctl(struct file *filp, unsigned int fd, unsigned int cmd, + unsigned long arg) { + int error = 0; void __user *argp = (void __user *)arg; struct inode *inode = file_inode(filp); switch (cmd) { case FIOCLEX: set_close_on_exec(fd, 1); - return 0; + break; case FIONCLEX: set_close_on_exec(fd, 0); - return 0; + break; case FIONBIO: - return ioctl_fionbio(filp, argp); + error = ioctl_fionbio(filp, argp); + break; case FIOASYNC: - return ioctl_fioasync(fd, filp, argp); + error = ioctl_fioasync(fd, filp, argp); + break; case FIOQSIZE: if (S_ISDIR(inode->i_mode) || S_ISREG(inode->i_mode) || S_ISLNK(inode->i_mode)) { loff_t res = inode_get_bytes(inode); - return copy_to_user(argp, &res, sizeof(res)) ? - -EFAULT : 0; - } - - return -ENOTTY; + error = copy_to_user(argp, &res, sizeof(res)) ? + -EFAULT : 0; + } else + error = -ENOTTY; + break; case FIFREEZE: - return ioctl_fsfreeze(filp); + error = ioctl_fsfreeze(filp); + break; case FITHAW: - return ioctl_fsthaw(filp); + error = ioctl_fsthaw(filp); + break; case FS_IOC_FIEMAP: return ioctl_fiemap(filp, argp); @@ -709,7 +716,6 @@ static int do_vfs_ioctl(struct file *fil /* anon_bdev filesystems may not have a block size */ if (!inode->i_sb->s_blocksize) return -EINVAL; - return put_user(inode->i_sb->s_blocksize, (int __user *)argp); case FICLONE: @@ -723,30 +729,24 @@ static int do_vfs_ioctl(struct file *fil default: if (S_ISREG(inode->i_mode)) - return file_ioctl(filp, cmd, argp); + error = file_ioctl(filp, cmd, arg); + else + error = vfs_ioctl(filp, cmd, arg); break; } - - return -ENOIOCTLCMD; + return error; } int ksys_ioctl(unsigned int fd, unsigned int cmd, unsigned long arg) { - struct fd f = fdget(fd); int error; + struct fd f = fdget(fd); if (!f.file) return -EBADF; - error = security_file_ioctl(f.file, cmd, arg); - if (error) - goto out; - - error = do_vfs_ioctl(f.file, fd, cmd, arg); - if (error == -ENOIOCTLCMD) - error = vfs_ioctl(f.file, cmd, arg); - -out: + if (!error) + error = do_vfs_ioctl(f.file, fd, cmd, arg); fdput(f); return error; } @@ -790,63 +790,92 @@ long compat_ptr_ioctl(struct file *file, EXPORT_SYMBOL(compat_ptr_ioctl); COMPAT_SYSCALL_DEFINE3(ioctl, unsigned int, fd, unsigned int, cmd, - compat_ulong_t, arg) + compat_ulong_t, arg32) { + unsigned long arg = arg32; struct fd f = fdget(fd); - int error; - + int error = -EBADF; if (!f.file) - return -EBADF; + goto out; /* RED-PEN how should LSM module know it's handling 32bit? */ error = security_file_ioctl(f.file, cmd, arg); if (error) - goto out; + goto out_fput; switch (cmd) { - /* FICLONE takes an int argument, so don't use compat_ptr() */ + /* these are never seen by ->ioctl(), no argument or int argument */ + case FIOCLEX: + case FIONCLEX: + case FIFREEZE: + case FITHAW: case FICLONE: - error = ioctl_file_clone(f.file, arg, 0, 0, 0); - break; - -#if defined(CONFIG_X86_64) + goto do_ioctl; + /* these are never seen by ->ioctl(), pointer argument */ + case FIONBIO: + case FIOASYNC: + case FIOQSIZE: + case FS_IOC_FIEMAP: + case FIGETBSZ: + case FICLONERANGE: + case FIDEDUPERANGE: + goto found_handler; + /* + * The next group is the stuff handled inside file_ioctl(). + * For regular files these never reach ->ioctl(); for + * devices, sockets, etc. they do and one (FIONREAD) is + * even accepted in some cases. In all those cases + * argument has the same type, so we can handle these + * here, shunting them towards do_vfs_ioctl(). + * ->compat_ioctl() will never see any of those. + */ + /* pointer argument, never actually handled by ->ioctl() */ + case FIBMAP: + goto found_handler; + /* handled by some ->ioctl(); always a pointer to int */ + case FIONREAD: + goto found_handler; /* these get messy on amd64 due to alignment differences */ +#if defined(CONFIG_X86_64) case FS_IOC_RESVSP_32: case FS_IOC_RESVSP64_32: error = compat_ioctl_preallocate(f.file, 0, compat_ptr(arg)); - break; + goto out_fput; case FS_IOC_UNRESVSP_32: case FS_IOC_UNRESVSP64_32: error = compat_ioctl_preallocate(f.file, FALLOC_FL_PUNCH_HOLE, compat_ptr(arg)); - break; + goto out_fput; case FS_IOC_ZERO_RANGE_32: error = compat_ioctl_preallocate(f.file, FALLOC_FL_ZERO_RANGE, compat_ptr(arg)); - break; + goto out_fput; +#else + case FS_IOC_RESVSP: + case FS_IOC_RESVSP64: + case FS_IOC_UNRESVSP: + case FS_IOC_UNRESVSP64: + case FS_IOC_ZERO_RANGE: + goto found_handler; #endif - /* - * everything else in do_vfs_ioctl() takes either a compatible - * pointer argument or no argument -- call it with a modified - * argument. - */ default: - error = do_vfs_ioctl(f.file, fd, cmd, - (unsigned long)compat_ptr(arg)); - if (error != -ENOIOCTLCMD) - break; - - if (f.file->f_op->compat_ioctl) + if (f.file->f_op->compat_ioctl) { error = f.file->f_op->compat_ioctl(f.file, cmd, arg); - if (error == -ENOIOCTLCMD) - error = -ENOTTY; - break; + if (error != -ENOIOCTLCMD) + goto out_fput; + } + error = -ENOTTY; + goto out_fput; } - out: + found_handler: + arg = (unsigned long)compat_ptr(arg); + do_ioctl: + error = do_vfs_ioctl(f.file, fd, cmd, arg); + out_fput: fdput(f); - + out: return error; } #endif diff -rupN a/include/linux/falloc.h b/include/linux/falloc.h --- a/include/linux/falloc.h 2020-02-07 13:20:46.382316741 +0100 +++ b/include/linux/falloc.h 2020-02-07 13:16:06.331418365 +0100 @@ -51,6 +51,8 @@ struct space_resv_32 { #define FS_IOC_UNRESVSP64_32 _IOW ('X', 43, struct space_resv_32) #define FS_IOC_ZERO_RANGE_32 _IOW ('X', 57, struct space_resv_32) +int compat_ioctl_preallocate(struct file *, int, struct space_resv_32 __user *); + #endif #endif /* _FALLOC_H_ */ diff -rupN a/include/linux/fs.h b/include/linux/fs.h --- a/include/linux/fs.h 2020-02-07 13:20:46.382316741 +0100 +++ b/include/linux/fs.h 2020-02-07 13:16:06.731416797 +0100 @@ -2563,6 +2563,10 @@ extern int finish_open(struct file *file int (*open)(struct inode *, struct file *)); extern int finish_no_open(struct file *file, struct dentry *dentry); +/* fs/ioctl.c */ + +extern int ioctl_preallocate(struct file *filp, int mode, void __user *argp); + /* fs/dcache.c */ extern void __init vfs_caches_init_early(void); extern void __init vfs_caches_init(void); ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Latest Git kernel: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device 2020-02-07 14:34 ` Christian Zigotzky @ 2020-02-07 17:08 ` Arnd Bergmann -1 siblings, 0 replies; 37+ messages in thread From: Arnd Bergmann @ 2020-02-07 17:08 UTC (permalink / raw) To: Christian Zigotzky Cc: Michael Ellerman, Jakub Kicinski, Christophe Leroy, DTML, Darren Stevens, Linux Kernel Mailing List, linuxppc-dev, contact, R.T.Dickinson, Christoph Hellwig, mad skateman, netdev, Christian Zigotzky On Fri, Feb 7, 2020 at 3:34 PM Christian Zigotzky <chzigotzky@xenosoft.de> wrote: > > Hello Arnd, > > We regularly compile and test Linux kernels every day during the merge > window. Since Thursday last week we have very high CPU usage because of > the avahi daemon on our desktop Linux systems (Ubuntu, Debian etc). The > avahi daemon produces a lot of the following log message. This generates > high CPU usage. > > Error message: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device > > strace /usr/sbin/avahi-daemon: > Thanks a lot for the detailed analysis, with this I immediately saw what went wrong in my original commit and I sent you a fix. Please test to ensure that this correctly addresses the problem. Arnd ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Latest Git kernel: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device @ 2020-02-07 17:08 ` Arnd Bergmann 0 siblings, 0 replies; 37+ messages in thread From: Arnd Bergmann @ 2020-02-07 17:08 UTC (permalink / raw) To: Christian Zigotzky Cc: DTML, Darren Stevens, mad skateman, Linux Kernel Mailing List, linuxppc-dev, contact, R.T.Dickinson, netdev, Jakub Kicinski, Christoph Hellwig, Christian Zigotzky On Fri, Feb 7, 2020 at 3:34 PM Christian Zigotzky <chzigotzky@xenosoft.de> wrote: > > Hello Arnd, > > We regularly compile and test Linux kernels every day during the merge > window. Since Thursday last week we have very high CPU usage because of > the avahi daemon on our desktop Linux systems (Ubuntu, Debian etc). The > avahi daemon produces a lot of the following log message. This generates > high CPU usage. > > Error message: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device > > strace /usr/sbin/avahi-daemon: > Thanks a lot for the detailed analysis, with this I immediately saw what went wrong in my original commit and I sent you a fix. Please test to ensure that this correctly addresses the problem. Arnd ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Latest Git kernel: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device 2020-02-07 17:08 ` Arnd Bergmann @ 2020-02-08 6:59 ` Christian Zigotzky -1 siblings, 0 replies; 37+ messages in thread From: Christian Zigotzky @ 2020-02-08 6:59 UTC (permalink / raw) To: Arnd Bergmann Cc: Michael Ellerman, Jakub Kicinski, Christophe Leroy, DTML, Darren Stevens, Linux Kernel Mailing List, linuxppc-dev, contact, R.T.Dickinson, Christoph Hellwig, mad skateman, netdev, Christian Zigotzky > On 7. Feb 2020, at 18:08, Arnd Bergmann <arnd@arndb.de> wrote: > > On Fri, Feb 7, 2020 at 3:34 PM Christian Zigotzky > <chzigotzky@xenosoft.de> wrote: >> >> Hello Arnd, >> >> We regularly compile and test Linux kernels every day during the merge >> window. Since Thursday last week we have very high CPU usage because of >> the avahi daemon on our desktop Linux systems (Ubuntu, Debian etc). The >> avahi daemon produces a lot of the following log message. This generates >> high CPU usage. >> >> Error message: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device >> >> strace /usr/sbin/avahi-daemon: >> > > Thanks a lot for the detailed analysis, with this I immediately saw > what went wrong in my > original commit and I sent you a fix. Please test to ensure that this > correctly addresses > the problem. > > Arnd Hi Arnd, Thanks a lot for your patch! I will test it as soon as possible. Cheers, Christian ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Latest Git kernel: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device @ 2020-02-08 6:59 ` Christian Zigotzky 0 siblings, 0 replies; 37+ messages in thread From: Christian Zigotzky @ 2020-02-08 6:59 UTC (permalink / raw) To: Arnd Bergmann Cc: DTML, Darren Stevens, mad skateman, Linux Kernel Mailing List, linuxppc-dev, contact, R.T.Dickinson, netdev, Jakub Kicinski, Christoph Hellwig, Christian Zigotzky > On 7. Feb 2020, at 18:08, Arnd Bergmann <arnd@arndb.de> wrote: > > On Fri, Feb 7, 2020 at 3:34 PM Christian Zigotzky > <chzigotzky@xenosoft.de> wrote: >> >> Hello Arnd, >> >> We regularly compile and test Linux kernels every day during the merge >> window. Since Thursday last week we have very high CPU usage because of >> the avahi daemon on our desktop Linux systems (Ubuntu, Debian etc). The >> avahi daemon produces a lot of the following log message. This generates >> high CPU usage. >> >> Error message: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device >> >> strace /usr/sbin/avahi-daemon: >> > > Thanks a lot for the detailed analysis, with this I immediately saw > what went wrong in my > original commit and I sent you a fix. Please test to ensure that this > correctly addresses > the problem. > > Arnd Hi Arnd, Thanks a lot for your patch! I will test it as soon as possible. Cheers, Christian ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Latest Git kernel: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device 2020-02-08 6:59 ` Christian Zigotzky @ 2020-02-08 16:08 ` Christian Zigotzky -1 siblings, 0 replies; 37+ messages in thread From: Christian Zigotzky @ 2020-02-08 16:08 UTC (permalink / raw) To: Arnd Bergmann Cc: Michael Ellerman, Jakub Kicinski, Christophe Leroy, DTML, Darren Stevens, Linux Kernel Mailing List, linuxppc-dev, contact, R.T.Dickinson, Christoph Hellwig, mad skateman, netdev, Christian Zigotzky On 08 February 2020 at 07:59 am, Christian Zigotzky wrote: > >> On 7. Feb 2020, at 18:08, Arnd Bergmann <arnd@arndb.de> wrote: >> >> On Fri, Feb 7, 2020 at 3:34 PM Christian Zigotzky >> <chzigotzky@xenosoft.de> wrote: >>> Hello Arnd, >>> >>> We regularly compile and test Linux kernels every day during the merge >>> window. Since Thursday last week we have very high CPU usage because of >>> the avahi daemon on our desktop Linux systems (Ubuntu, Debian etc). The >>> avahi daemon produces a lot of the following log message. This generates >>> high CPU usage. >>> >>> Error message: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device >>> >>> strace /usr/sbin/avahi-daemon: >>> >> Thanks a lot for the detailed analysis, with this I immediately saw >> what went wrong in my >> original commit and I sent you a fix. Please test to ensure that this >> correctly addresses >> the problem. >> >> Arnd > Hi Arnd, > > Thanks a lot for your patch! I will test it as soon as possible. > > Cheers, > Christian Hi Arnd, I successfully compiled the latest Git kernel with your patch today. The avahi daemon works fine now. That means your patch has solved the avahi issue. Thanks for your patch and have a nice weekend! Cheers, Christian ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Latest Git kernel: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device @ 2020-02-08 16:08 ` Christian Zigotzky 0 siblings, 0 replies; 37+ messages in thread From: Christian Zigotzky @ 2020-02-08 16:08 UTC (permalink / raw) To: Arnd Bergmann Cc: DTML, Darren Stevens, mad skateman, Linux Kernel Mailing List, linuxppc-dev, contact, R.T.Dickinson, netdev, Jakub Kicinski, Christoph Hellwig, Christian Zigotzky On 08 February 2020 at 07:59 am, Christian Zigotzky wrote: > >> On 7. Feb 2020, at 18:08, Arnd Bergmann <arnd@arndb.de> wrote: >> >> On Fri, Feb 7, 2020 at 3:34 PM Christian Zigotzky >> <chzigotzky@xenosoft.de> wrote: >>> Hello Arnd, >>> >>> We regularly compile and test Linux kernels every day during the merge >>> window. Since Thursday last week we have very high CPU usage because of >>> the avahi daemon on our desktop Linux systems (Ubuntu, Debian etc). The >>> avahi daemon produces a lot of the following log message. This generates >>> high CPU usage. >>> >>> Error message: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device >>> >>> strace /usr/sbin/avahi-daemon: >>> >> Thanks a lot for the detailed analysis, with this I immediately saw >> what went wrong in my >> original commit and I sent you a fix. Please test to ensure that this >> correctly addresses >> the problem. >> >> Arnd > Hi Arnd, > > Thanks a lot for your patch! I will test it as soon as possible. > > Cheers, > Christian Hi Arnd, I successfully compiled the latest Git kernel with your patch today. The avahi daemon works fine now. That means your patch has solved the avahi issue. Thanks for your patch and have a nice weekend! Cheers, Christian ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH] of: Add OF_DMA_DEFAULT_COHERENT & select it on powerpc 2020-01-26 11:52 ` Michael Ellerman @ 2020-01-27 17:30 ` Frank Rowand -1 siblings, 0 replies; 37+ messages in thread From: Frank Rowand @ 2020-01-27 17:30 UTC (permalink / raw) To: Michael Ellerman, robh+dt Cc: devicetree, linux-kernel, hch, ulf.hansson, chzigotzky, linuxppc-dev + Frank (me) On 1/26/20 5:52 AM, Michael Ellerman wrote: > There's an OF helper called of_dma_is_coherent(), which checks if a > device has a "dma-coherent" property to see if the device is coherent > for DMA. > > But on some platforms devices are coherent by default, and on some > platforms it's not possible to update existing device trees to add the > "dma-coherent" property. > > So add a Kconfig symbol to allow arch code to tell > of_dma_is_coherent() that devices are coherent by default, regardless > of the presence of the property. > > Select that symbol on powerpc when NOT_COHERENT_CACHE is not set, ie. > when the system has a coherent cache. > > Fixes: 92ea637edea3 ("of: introduce of_dma_is_coherent() helper") > Cc: stable@vger.kernel.org # v3.16+ > Reported-by: Christian Zigotzky <chzigotzky@xenosoft.de> > Tested-by: Christian Zigotzky <chzigotzky@xenosoft.de> > Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> > --- > arch/powerpc/Kconfig | 1 + > drivers/of/Kconfig | 4 ++++ > drivers/of/address.c | 6 +++++- > 3 files changed, 10 insertions(+), 1 deletion(-) > > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig > index 1ec34e16ed65..19f5aa8ac9a3 100644 > --- a/arch/powerpc/Kconfig > +++ b/arch/powerpc/Kconfig > @@ -238,6 +238,7 @@ config PPC > select NEED_DMA_MAP_STATE if PPC64 || NOT_COHERENT_CACHE > select NEED_SG_DMA_LENGTH > select OF > + select OF_DMA_DEFAULT_COHERENT if !NOT_COHERENT_CACHE > select OF_EARLY_FLATTREE > select OLD_SIGACTION if PPC32 > select OLD_SIGSUSPEND > diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig > index 37c2ccbefecd..d91618641be6 100644 > --- a/drivers/of/Kconfig > +++ b/drivers/of/Kconfig > @@ -103,4 +103,8 @@ config OF_OVERLAY > config OF_NUMA > bool > > +config OF_DMA_DEFAULT_COHERENT > + # arches should select this if DMA is coherent by default for OF devices > + bool > + > endif # OF > diff --git a/drivers/of/address.c b/drivers/of/address.c > index 99c1b8058559..e8a39c3ec4d4 100644 > --- a/drivers/of/address.c > +++ b/drivers/of/address.c > @@ -995,12 +995,16 @@ int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *siz > * @np: device node > * > * It returns true if "dma-coherent" property was found > - * for this device in DT. > + * for this device in the DT, or if DMA is coherent by > + * default for OF devices on the current platform. > */ > bool of_dma_is_coherent(struct device_node *np) > { > struct device_node *node = of_node_get(np); > > + if (IS_ENABLED(CONFIG_OF_DMA_DEFAULT_COHERENT)) > + return true; > + > while (node) { > if (of_property_read_bool(node, "dma-coherent")) { > of_node_put(node); > ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH] of: Add OF_DMA_DEFAULT_COHERENT & select it on powerpc @ 2020-01-27 17:30 ` Frank Rowand 0 siblings, 0 replies; 37+ messages in thread From: Frank Rowand @ 2020-01-27 17:30 UTC (permalink / raw) To: Michael Ellerman, robh+dt Cc: devicetree, ulf.hansson, linux-kernel, linuxppc-dev, chzigotzky, hch + Frank (me) On 1/26/20 5:52 AM, Michael Ellerman wrote: > There's an OF helper called of_dma_is_coherent(), which checks if a > device has a "dma-coherent" property to see if the device is coherent > for DMA. > > But on some platforms devices are coherent by default, and on some > platforms it's not possible to update existing device trees to add the > "dma-coherent" property. > > So add a Kconfig symbol to allow arch code to tell > of_dma_is_coherent() that devices are coherent by default, regardless > of the presence of the property. > > Select that symbol on powerpc when NOT_COHERENT_CACHE is not set, ie. > when the system has a coherent cache. > > Fixes: 92ea637edea3 ("of: introduce of_dma_is_coherent() helper") > Cc: stable@vger.kernel.org # v3.16+ > Reported-by: Christian Zigotzky <chzigotzky@xenosoft.de> > Tested-by: Christian Zigotzky <chzigotzky@xenosoft.de> > Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> > --- > arch/powerpc/Kconfig | 1 + > drivers/of/Kconfig | 4 ++++ > drivers/of/address.c | 6 +++++- > 3 files changed, 10 insertions(+), 1 deletion(-) > > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig > index 1ec34e16ed65..19f5aa8ac9a3 100644 > --- a/arch/powerpc/Kconfig > +++ b/arch/powerpc/Kconfig > @@ -238,6 +238,7 @@ config PPC > select NEED_DMA_MAP_STATE if PPC64 || NOT_COHERENT_CACHE > select NEED_SG_DMA_LENGTH > select OF > + select OF_DMA_DEFAULT_COHERENT if !NOT_COHERENT_CACHE > select OF_EARLY_FLATTREE > select OLD_SIGACTION if PPC32 > select OLD_SIGSUSPEND > diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig > index 37c2ccbefecd..d91618641be6 100644 > --- a/drivers/of/Kconfig > +++ b/drivers/of/Kconfig > @@ -103,4 +103,8 @@ config OF_OVERLAY > config OF_NUMA > bool > > +config OF_DMA_DEFAULT_COHERENT > + # arches should select this if DMA is coherent by default for OF devices > + bool > + > endif # OF > diff --git a/drivers/of/address.c b/drivers/of/address.c > index 99c1b8058559..e8a39c3ec4d4 100644 > --- a/drivers/of/address.c > +++ b/drivers/of/address.c > @@ -995,12 +995,16 @@ int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *siz > * @np: device node > * > * It returns true if "dma-coherent" property was found > - * for this device in DT. > + * for this device in the DT, or if DMA is coherent by > + * default for OF devices on the current platform. > */ > bool of_dma_is_coherent(struct device_node *np) > { > struct device_node *node = of_node_get(np); > > + if (IS_ENABLED(CONFIG_OF_DMA_DEFAULT_COHERENT)) > + return true; > + > while (node) { > if (of_property_read_bool(node, "dma-coherent")) { > of_node_put(node); > ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH] of: Add OF_DMA_DEFAULT_COHERENT & select it on powerpc 2020-01-26 11:52 ` Michael Ellerman @ 2020-01-28 14:26 ` Rob Herring -1 siblings, 0 replies; 37+ messages in thread From: Rob Herring @ 2020-01-28 14:26 UTC (permalink / raw) To: Michael Ellerman Cc: robh+dt, devicetree, linux-kernel, hch, ulf.hansson, chzigotzky, linuxppc-dev On Sun, 26 Jan 2020 22:52:47 +1100, Michael Ellerman wrote: > There's an OF helper called of_dma_is_coherent(), which checks if a > device has a "dma-coherent" property to see if the device is coherent > for DMA. > > But on some platforms devices are coherent by default, and on some > platforms it's not possible to update existing device trees to add the > "dma-coherent" property. > > So add a Kconfig symbol to allow arch code to tell > of_dma_is_coherent() that devices are coherent by default, regardless > of the presence of the property. > > Select that symbol on powerpc when NOT_COHERENT_CACHE is not set, ie. > when the system has a coherent cache. > > Fixes: 92ea637edea3 ("of: introduce of_dma_is_coherent() helper") > Cc: stable@vger.kernel.org # v3.16+ > Reported-by: Christian Zigotzky <chzigotzky@xenosoft.de> > Tested-by: Christian Zigotzky <chzigotzky@xenosoft.de> > Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> > --- > arch/powerpc/Kconfig | 1 + > drivers/of/Kconfig | 4 ++++ > drivers/of/address.c | 6 +++++- > 3 files changed, 10 insertions(+), 1 deletion(-) > Applied, thanks. Rob ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH] of: Add OF_DMA_DEFAULT_COHERENT & select it on powerpc @ 2020-01-28 14:26 ` Rob Herring 0 siblings, 0 replies; 37+ messages in thread From: Rob Herring @ 2020-01-28 14:26 UTC (permalink / raw) To: Michael Ellerman Cc: devicetree, ulf.hansson, linux-kernel, linuxppc-dev, robh+dt, chzigotzky, hch On Sun, 26 Jan 2020 22:52:47 +1100, Michael Ellerman wrote: > There's an OF helper called of_dma_is_coherent(), which checks if a > device has a "dma-coherent" property to see if the device is coherent > for DMA. > > But on some platforms devices are coherent by default, and on some > platforms it's not possible to update existing device trees to add the > "dma-coherent" property. > > So add a Kconfig symbol to allow arch code to tell > of_dma_is_coherent() that devices are coherent by default, regardless > of the presence of the property. > > Select that symbol on powerpc when NOT_COHERENT_CACHE is not set, ie. > when the system has a coherent cache. > > Fixes: 92ea637edea3 ("of: introduce of_dma_is_coherent() helper") > Cc: stable@vger.kernel.org # v3.16+ > Reported-by: Christian Zigotzky <chzigotzky@xenosoft.de> > Tested-by: Christian Zigotzky <chzigotzky@xenosoft.de> > Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> > --- > arch/powerpc/Kconfig | 1 + > drivers/of/Kconfig | 4 ++++ > drivers/of/address.c | 6 +++++- > 3 files changed, 10 insertions(+), 1 deletion(-) > Applied, thanks. Rob ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH] of: Add OF_DMA_DEFAULT_COHERENT & select it on powerpc 2020-01-28 14:26 ` Rob Herring @ 2020-01-31 10:40 ` Michael Ellerman -1 siblings, 0 replies; 37+ messages in thread From: Michael Ellerman @ 2020-01-31 10:40 UTC (permalink / raw) To: Rob Herring Cc: robh+dt, devicetree, linux-kernel, hch, ulf.hansson, chzigotzky, linuxppc-dev Rob Herring <robh@kernel.org> writes: > On Sun, 26 Jan 2020 22:52:47 +1100, Michael Ellerman wrote: >> There's an OF helper called of_dma_is_coherent(), which checks if a >> device has a "dma-coherent" property to see if the device is coherent >> for DMA. >> >> But on some platforms devices are coherent by default, and on some >> platforms it's not possible to update existing device trees to add the >> "dma-coherent" property. >> >> So add a Kconfig symbol to allow arch code to tell >> of_dma_is_coherent() that devices are coherent by default, regardless >> of the presence of the property. >> >> Select that symbol on powerpc when NOT_COHERENT_CACHE is not set, ie. >> when the system has a coherent cache. >> >> Fixes: 92ea637edea3 ("of: introduce of_dma_is_coherent() helper") >> Cc: stable@vger.kernel.org # v3.16+ >> Reported-by: Christian Zigotzky <chzigotzky@xenosoft.de> >> Tested-by: Christian Zigotzky <chzigotzky@xenosoft.de> >> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> >> --- >> arch/powerpc/Kconfig | 1 + >> drivers/of/Kconfig | 4 ++++ >> drivers/of/address.c | 6 +++++- >> 3 files changed, 10 insertions(+), 1 deletion(-) >> > > Applied, thanks. Thanks. cheers ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH] of: Add OF_DMA_DEFAULT_COHERENT & select it on powerpc @ 2020-01-31 10:40 ` Michael Ellerman 0 siblings, 0 replies; 37+ messages in thread From: Michael Ellerman @ 2020-01-31 10:40 UTC (permalink / raw) To: Rob Herring Cc: devicetree, ulf.hansson, linux-kernel, linuxppc-dev, robh+dt, chzigotzky, hch Rob Herring <robh@kernel.org> writes: > On Sun, 26 Jan 2020 22:52:47 +1100, Michael Ellerman wrote: >> There's an OF helper called of_dma_is_coherent(), which checks if a >> device has a "dma-coherent" property to see if the device is coherent >> for DMA. >> >> But on some platforms devices are coherent by default, and on some >> platforms it's not possible to update existing device trees to add the >> "dma-coherent" property. >> >> So add a Kconfig symbol to allow arch code to tell >> of_dma_is_coherent() that devices are coherent by default, regardless >> of the presence of the property. >> >> Select that symbol on powerpc when NOT_COHERENT_CACHE is not set, ie. >> when the system has a coherent cache. >> >> Fixes: 92ea637edea3 ("of: introduce of_dma_is_coherent() helper") >> Cc: stable@vger.kernel.org # v3.16+ >> Reported-by: Christian Zigotzky <chzigotzky@xenosoft.de> >> Tested-by: Christian Zigotzky <chzigotzky@xenosoft.de> >> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> >> --- >> arch/powerpc/Kconfig | 1 + >> drivers/of/Kconfig | 4 ++++ >> drivers/of/address.c | 6 +++++- >> 3 files changed, 10 insertions(+), 1 deletion(-) >> > > Applied, thanks. Thanks. cheers ^ permalink raw reply [flat|nested] 37+ messages in thread
end of thread, other threads:[~2020-02-08 16:11 UTC | newest] Thread overview: 37+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-01-26 11:52 [PATCH] of: Add OF_DMA_DEFAULT_COHERENT & select it on powerpc Michael Ellerman 2020-01-26 11:52 ` Michael Ellerman 2020-01-27 7:22 ` Ulf Hansson 2020-01-27 7:22 ` Ulf Hansson 2020-01-31 10:40 ` Michael Ellerman 2020-01-31 10:40 ` Michael Ellerman 2020-02-02 0:08 ` Latest Git kernel: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device Christian Zigotzky 2020-02-02 0:08 ` Christian Zigotzky 2020-02-02 4:37 ` Randy Dunlap 2020-02-02 4:37 ` Randy Dunlap 2020-02-02 8:19 ` Christophe Leroy 2020-02-02 15:02 ` Christian Zigotzky 2020-02-03 17:53 ` Jakub Kicinski 2020-02-03 17:53 ` Jakub Kicinski 2020-02-05 13:03 ` Christian Zigotzky 2020-02-05 13:03 ` Christian Zigotzky 2020-02-05 14:36 ` Christian Zigotzky 2020-02-06 4:35 ` Michael Ellerman 2020-02-06 4:35 ` Michael Ellerman 2020-02-06 14:28 ` Christian Zigotzky 2020-02-06 14:28 ` Christian Zigotzky 2020-02-08 12:36 ` Michael Ellerman 2020-02-08 12:36 ` Michael Ellerman 2020-02-07 14:34 ` Christian Zigotzky 2020-02-07 14:34 ` Christian Zigotzky 2020-02-07 17:08 ` Arnd Bergmann 2020-02-07 17:08 ` Arnd Bergmann 2020-02-08 6:59 ` Christian Zigotzky 2020-02-08 6:59 ` Christian Zigotzky 2020-02-08 16:08 ` Christian Zigotzky 2020-02-08 16:08 ` Christian Zigotzky 2020-01-27 17:30 ` [PATCH] of: Add OF_DMA_DEFAULT_COHERENT & select it on powerpc Frank Rowand 2020-01-27 17:30 ` Frank Rowand 2020-01-28 14:26 ` Rob Herring 2020-01-28 14:26 ` Rob Herring 2020-01-31 10:40 ` Michael Ellerman 2020-01-31 10:40 ` Michael Ellerman
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.