08:59 <krzk> vkoul: that failure was reported many times on next...

08:59 <krzk> the commit should be dropped

09:00 <krzk> vkoul: ok, not many times, two times: 5th and 8th of November build failure of your tree

09:01 <krzk> If the patch owner does not respond to such failure report (I guess here on purpose because the patchset was described as non-mergeable via subsystems), I think you should consider dropping the patch.

10:49 <arnd> prabhakarlad, robher, krzk, geertu: I'm merging pull requests right now and came across https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git/commit/?h=renesas-arm-dt-for-v6.2-tag2&id=eafbed2a4556f90792338630ab6ddf7b2e492e8d

10:50 <arnd> IIRC there are some cases where an interrupt controller requires an #address-cells property, so I wonder if this one should be fixed by changing the the binding rather than the dts

10:57 <prabhakarlad> arnd: can you provide any example pointers please. I had a quick look at bindings/pinctrl folder which are interrupt controllers but don't have address-cells for child nodes.

10:58 <krzk> arnd: I think it's only in case if some other nodes are interrup nexuses with interrupt-map. Then the parent and nexus should have the address-cells.

11:00 <arnd> Right, so https://www.devicetree.org/open-firmware/practice/imap/imap0_9d.html describes it, but interrupt-map is mainly used for legacy PCI IntX interrupts, so if this one is not connected to PCI, it's probably not needed

11:00 <krzk> I don't remember any other cases.

11:00 <krzk> arnd: yes

12:33 <arnd> tagr: regarding your updated pull requests: I already have a bunch of things on top of the original PR. I can of course redo it all as I have not pushed it out, but it would be easier to leave it if the only change is the fixes line. how important is this to you?

12:35 <arnd> I have not pulled the memory driver branch yet

12:47 <lag> Anyone know of a tool, similar to `pahole` that would be useful to examine the stack-frame of a given function within a compiled *.o file?

12:48 <lag> Trying to debug -Wframe-larger-than warnings when the size of the used stack is not evident by simply reading the code

12:50 <lag> Should I assume that 'static const's, declared and assigned *outside* of a function, but used *inside* said function get shoved into that function's stack frame?

12:52 <lag> No, that can't be right - else that would blow the frame-larger-than limit several fold in my working example [wp512_process_buffer()]

12:55 <arnd> lag: ndesaulniers' https://github.com/ClangBuiltLinux/frame-larger-than might help

13:00 <bjdooks> lag: unlikely, it is much more likely to be something inside the function itself

13:08 <lag> arnd: I am working with ndesaulniers on this already :)

13:09 <lag> bjdooks: Right, but I'm missing it

13:10 <bjdooks> lag: is this code public?

13:10 <lag> bjdooks: arnd: ndesaulniers did say that in some cases KASAN was inflating use

13:10 <lag> bjdooks: No idea - is the Linux kernel public? =;-D

13:10 <lag> bjdooks: Let me grab you a link

13:10 <bjdooks> some of our work is debugging whatevre bat-crazy stuff our suppliers have made

13:11 <lag> bjdooks: https://github.com/torvalds/linux/blob/master/crypto/wp512.c#L782

13:11 <lag> bjdooks: I know Ben, I'm just pulling your leg

13:12 <lag> bjdooks: BTW, I moved to to your neck of the woods recently - fancy a beer? :)

13:13 <bjdooks> lag: the start of that is easily 256 bytes of frame from the 4x8xsizeof(u64)

13:13 <lag> bjdooks: Right, so where does the other 900-odd Bytes come from?

13:14 <arnd> lag: I've looked at similar cases before, compiler optimizations tend to clash with crypto algorithms because those are written to be impossible to optimize yet look to the compiler like it should be possible. The compiler then runs out of registers trying to fold it all together

13:14 <lag> arnd: So what do we do? Turn down the warning for that file / subsystem?

13:14 <arnd> lag: if you look at the asm file generated by 'make crypto/wp512.s', you should see a lot of 'spilled variable' annotations

13:16 <arnd> lag: no, the warning is for a real problem, which causes both very slow code that is meant to be optimized, and an actual risk for stack overflow. In some of these cases it may overflow immediately when the function stack frame grows to tens of kb

13:16 <arnd> sometimes it helps to turn off a specific optimization flag that causes the compiler to make a mess

13:16 <bjdooks> lag: yep, but i'm going to be away from end of this week until late decmber

13:17 <arnd> CFLAGS_wp512.o := $(call cc-option,-fno-schedule-insns) # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79149

13:17 <arnd> this is from the last time this happened

13:17 <lag> (without looking) is that current?

13:18 <arnd> lag: what compile and version do you use, and which flags are enabled?

13:18 <lag> arnd: Lots

13:18 <arnd> the workaround was from 2017, see 7d6e91050267 ("crypto: improve gcc optimization flags for serpent and wp512")

13:19 <lag> arnd: https://pastebin.ubuntu.com/p/t2cZF3KtQV/

13:19 <lag> arnd: Line 30 is the build I'm looking at ("arm allmodconfig clang-13") -- fail (12 errors - 14 warnings)

13:20 <arnd> ok, so maybe clang needs a similar workaround to gcc

13:20 <arnd> the optimzation flags all have different names and different behavior of course, but it may be a case where they run into the same fundamental issue

13:21 <lag> arnd: Okay, let me speak to Nick, see what he can suggest

13:22 <lag> arnd: bjdooks: Thanks for your input

13:23 <bjdooks> there's nothing that jumps out, sounds like a weird compiler issue

13:23 <arnd> lag: my guess would be d539fee9f825 ("ARM: 9253/1: ubsan: select ARCH_HAS_UBSAN_SANITIZE_ALL")

13:23 <arnd> I think we had similar problems the last time someone tried turning that on

13:23 <arnd> does it happen if you disable CONFIG_UBSAN_SANITIZE_ALL?

13:23 <lag> arnd: I can try

13:25 <lag> arnd: Doesn't look like it's enabled

13:26 <lag> arnd: At least not explicitly (no mention in .config)

13:26 <lag> CONFIG_UBSAN=y

13:26 <lag> CONFIG_CC_HAS_UBSAN_BOUNDS=y

13:26 <lag> CONFIG_UBSAN_BOUNDS=y

13:26 <lag> CONFIG_CC_HAS_UBSAN_ARRAY_BOUNDS=y

13:26 <lag> CONFIG_UBSAN_ARRAY_BOUNDS=y

13:26 <lag> CONFIG_UBSAN_SHIFT=y

13:26 <lag> CONFIG_UBSAN_UNREACHABLE=y

13:26 <lag> CONFIG_UBSAN_BOOL=y

13:26 <lag> CONFIG_UBSAN_ENUM=y

13:26 <lag> CONFIG_TEST_UBSAN=m

13:27 <arnd> ok, is this a release kernel then? The SANITIZE_ALL stuff only just went into linux-next, so on other kernels it must be something else

13:28 <lag> arnd: Stock v6.0

13:28 <arnd> ok

13:29 <arnd> so KASAN_STACK is also disabled because of CONFIG_CC_IS_CLANG, right?

13:29 <lag> arnd: Correct

13:33 <arnd> lag: so what I've done in the past to debug issues like this is to bisect through the command line. Build it with "make V=1 crypto/wp512.o" on both allmodconfig (which produces the warning and defconfig (which should not), and then compare all the command line flags, the theory being that exactly one of the flags makes the difference. Then run the compiler command manually to build the file with a mix of the two sets of parameters

13:49 <lag> arnd: That sounds like fun!

14:09 <geertu> arnd: IIRC, we used to get warnings if the #address-cells was missing in an interrupt-controller, while most(?) interrupts controllers don't use/need it at all. Exception is GIV with v2m subnodes

14:19 <maz> v2m is an MSI controller, for which the #address-cell means a lot.

14:40 <arnd> tmlind: is "[GIT PULL] Regulator changes for am335x-pcm-953" for 6.1 or for 6.2?

14:50 <tmlind> arnd: does not seem too urgent to me, up to you to merge whenever suitable :)

14:50 <arnd> ok

14:58 <arnd> tmlind: I've put it into the fixes branch for 6.1 now

15:03 <tmlind> arnd: ok thanks

15:45 <tagr> arnd: I was going to send an updated PR for three branches because I noticed a Fixes: reference mismatch earlier today

15:45 <tagr> I had sent out a mail, but you might have missed it

15:46 <tagr> maybe not worth it now that you already pulled because the Fixes: tag is for a patch that precedes the fix by 2 commits in the branch

15:47 <tagr> so the reference is only marginally useful and in retrospect it might have been better to just squash the fix into the original patch

15:47 <tagr> that's exactly what I would've done for the updated PR

15:49 <arnd> tagr: I think the email bot was a bit confusing today, the version I pushed out should not have anything that depends on your dt-bindings branch

15:50 <arnd> I ended up redoing the soc/dt branch leaving out the three I had pulled earlier, and I did not merge the one for the drivers branch

15:51 <arnd> tagr: if you check my for-next branch, you should see what is missing, please resend everything I haven't already pulled

15:52 <tagr> arnd: great, will do

15:58 <tagr> arnd: oh, I see that PR 8/8 is the only one that has an actual link to the merge commit, and that's the only one that I see in your for-next branch

15:58 <tagr> sorry, I completely misinterpreted the output

15:58 <tagr> I'll resend 1-7 then

16:53 <ajb-linaro> does anyone know who admins storage.kernelci.org? is it a linaro bod or someone else in the community?

18:15 <mwalle> did someone already found out what's wrong with next-20221121? looks like most arm64 doesn't boot

18:24 <robmur01> mwalle: possibly https://lore.kernel.org/linux-arm-kernel/Y3pS5fdZ3MdLZ00t@dev-arch.thelio-3990X/ ?

18:34 <mwalle> robmur01: thanks, let me try it

19:28 <mwalle> robmur01: yep, reverting that commit will fix the issue