lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87imsiyzo3.fsf@linux.intel.com>
Date:   Thu, 04 Jul 2019 11:25:16 +0300
From:   Felipe Balbi <balbi@...nel.org>
To:     Pawel Laszczak <pawell@...ence.com>, Greg KH <greg@...ah.com>
Cc:     Stephen Rothwell <sfr@...b.auug.org.au>,
        Linux Next Mailing List <linux-next@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "linux-usb\@vger.kernel.org" <linux-usb@...r.kernel.org>,
        Roger Quadros <rogerq@...com>, Nishanth Menon <nm@...com>
Subject: RE: linux-next: build failure after merge of the usb and usb-gadget trees


Hi,

Pawel Laszczak <pawell@...ence.com> writes:

>>
>>Hi,
>>
>>On Thu, Jul 4, 2019 at 9:59 AM Greg KH <greg@...ah.com> wrote:
>>>
>>> On Thu, Jul 04, 2019 at 04:34:58PM +1000, Stephen Rothwell wrote:
>>> > Hi all,
>>> >
>>> > After merging the usb tree, today's linux-next build (arm
>>> > multi_v7_defconfig) failed like this:
>>> >
>>> > arm-linux-gnueabi-ld: drivers/usb/dwc3/trace.o: in function `trace_raw_output_dwc3_log_ctrl':
>>> > trace.c:(.text+0x119c): undefined reference to `usb_decode_ctrl'
>>> >
>>> > Caused by commit
>>> >
>>> >   3db1b636c07e ("usb:gadget Separated decoding functions from dwc3 driver.")
>>> >
>>> > I have used the usb tree from next-20190703 for today.
>>> >
>>> > This also occurs in the usb-gadget tree so I have used the version of
>>> > that from next-20190703 as well.
>>>
>>> Odd, I thought I pulled the usb-gadget tree into mine.  Felipe, can you
>>> take a look at this to see if I messed something up?
>>
>>This looks like it was caused by Pawel's patches.
>>
>>I'll try to reproduce here and see what's causing it.
>
> Problem is in my Patch. I reproduced it, but I don't understand why compiler 
> complains about usb_decode_ctrl. It's compiled into libcomposite.ko and
> declaration is in drivers/usb/gadget.h. 

That's because in multi_v7_defconfig dwc3 is built-in while libcomposite
is a module:

CONFIG_USB_DWC3=y
CONFIG_USB_LIBCOMPOSITE=m


I remember that when you were doing this work, I asked you to move
functions to usb/common. Why did you deviate from that suggestion? It's
clear that decoding a ctrl request can be used by peripheral and host
and we wouldn't have to deal with this problem if you had just followed
the suggestion.

Now we have to come up with a way to fix this that doesn't involve
reverting my part2 tag in its entirety because there are other important
things there.

This is what I get for trusting people to do their part. I couldn't even
compile test this since I don't have ARM compilers anymore (actually,
just installed to test). Your customer, however, uses ARM cores so I
would expect you to have at least compile tested this on ARM. How come
this wasn't verified by anybody at TI?

TI used to have automated testing for many of the important defconfigs,
is that completely gone? Are you guys relying entirely on linux-next?

Greg, if you prefer, please revert my part2 tag. If you do so, please
let me know so I can drop the tag and commits from my tree as well.

Pawel, please make sure this never happens again. It's pretty simple to
avoid this sort of thing. I'll keep ARM compiler installed for
build-testing as well.

-- 
balbi

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ