So last weekend, I thought I'd be releasing the final 5.17 today.
That was then, this is now. Last week was somewhat messy, mostly
because of embargoed patches we had pending with another variation of
spectre attacks. And while the patches were mostly fine, we had the
usual "because it was hidden, all our normal testing automation didn't
see it either".
And once the automation sees things, it tests all the insane
combinations that people don't tend to actually use or test in any
normal case, and so there was a (small) flurry of fixes for the fixes.
None of this was really surprising, but I naïvely thought I'd be able
to do the final release this weekend anyway.
And honestly, I considered it. I don't think we really have any
pending issues that would hold up a release, but on the other hand we
also really don't have any reason _not_ to give it another week with
all the proper automated testing. So that's what I'm doing, and as a
result we have an -rc8 release today instead of doing a final 5.17.
There's a number of non-spectre things in here too, of course. Among
other things, people finally chased down a couple of mislaid patches
that had been on the regression list, so hopefully we have those all
nailed down now too.
And obviously there's all the usual random fixes in here too. But
because of the spectre thing, about half of the -rc8 patch is
architecture updates.
That said, it's still a fairly _small_ half of the patch. It was not
one of the "big disaster" hw speculation things, it was mostly
extending existing mitigations and reporting.
Anyway, let's not keep the testing _just_ to automation - the more the
merrier, and real-life loads are always more interesting than what the
automation farms do. So please do give this last rc a quick try,
Linus
---
Akhil R (1):
gpio: tegra186: Add IRQ per bank for Tegra241
Aleksander Jan Bajkowski (1):
net: lantiq_xrx200: fix use after free bug
Alexey Khoroshilov (1):
mISDN: Fix memory leak in dsp_pipeline_build()
Andy Shevchenko (2):
gpiolib: acpi: Convert ACPI value of debounce to microseconds
gpio: sim: Declare gpio_sim_hog_config_item_ops static
AngeloGioacchino Del Regno (1):
soc: mediatek: mt8192-mmsys: Fix dither to dsi0 path's input sel
Anirudh Rayabharam (1):
vhost: fix hung thread due to erroneous iotlb entries
Arnaldo Carvalho de Melo (2):
tools kvm headers arm64: Update KVM headers from the kernel sources
tools headers cpufeatures: Sync with the kernel sources
Aswath Govindraju (1):
dt-bindings: phy: ti,tcan104x-can: Document mux-states property
Bartosz Golaszewski (1):
gpio: sim: fix a typo
Ben Ben-Ishay (1):
net/mlx5e: SHAMPO, reduce TIR indication
Biju Das (1):
spi: Fix invalid sgs value
Bjorn Andersson (1):
arm64: dts: qcom: sm8350: Correct UFS symbol clocks
Catalin Marinas (1):
arm64: Ensure execute-only permissions are not allowed without EPAN
Christophe JAILLET (2):
ice: Don't use GFP_KERNEL in atomic context
watch_queue: Use the bitmap API when applicable
Clément Léger (1):
net: phy: DP83822: clear MISR2 register to disable interrupts
Colin Foster (1):
net: phy: correct spelling error of media in documentation
Dan Carpenter (1):
staging: gdm724x: fix use after free in gdm_lte_rx()
Daniel Bristot de Oliveira (1):
tracing/osnoise: Do not unregister events twice
Daniel Palmer (1):
ARM: mstar: Select HAVE_ARM_ARCH_TIMER
Dave Ertman (1):
ice: Fix error with handling of bonding MTU
David Howells (10):
watch_queue: Fix filter limit check
watch_queue, pipe: Free watchqueue state after clearing pipe ring
watch_queue: Fix to release page in ->release()
watch_queue: Fix to always request a pow-of-2 pipe ring size
watch_queue: Fix the alloc bitmap size to reflect notes allocated
watch_queue: Free the alloc bitmap when the watch_queue is torn down
watch_queue: Fix lack of barrier/sync/lock between post and read
watch_queue: Make comment about setting ->defunct more accurate
afs: Fix potential thrashing in afs writeback
cachefiles: Fix volume coherency attribute
Dima Chumak (1):
net/mlx5: Fix offloading with ESWITCH_IPV4_TTL_MODIFY_ENABLE
Dmitry Torokhov (1):
HID: vivaldi: fix sysfs attributes leak
Duoming Zhou (1):
ax25: Fix NULL pointer dereference in ax25_kill_by_device
Emil Renner Berthing (1):
riscv: Fix auipc+jalr relocation range checks
Emmanuel Gil Peyrot (1):
ARM: fix build error when BPF_SYSCALL is disabled
Eric Dumazet (1):
sctp: fix kernel-infoleak for SCTP sockets
Fabio Estevam (1):
smsc95xx: Ignore -ENODEV errors when device is unplugged
Guillaume Nault (2):
selftests: pmtu.sh: Kill tcpdump processes launched by subshell.
selftests: pmtu.sh: Kill nettest processes launched in subshell.
Halil Pasic (1):
swiotlb: rework "fix info leak with DMA_FROM_DEVICE"
Hans de Goede (3):
staging: rtl8723bs: Fix access-point mode deadlock
staging: rtl8723bs: Improve the comment explaining the locking rules
Bluetooth: hci_core: Fix unbalanced unlock in set_device_flags()
Heiner Kallweit (2):
net: phy: meson-gxl: fix interrupt handling in forced mode
net: phy: meson-gxl: improve link-up behavior
Horatiu Vultur (1):
clk: lan966x: Fix linking error
Ivan Vecera (1):
ice: Fix race condition during interface enslave
Jacob Keller (2):
i40e: stop disabling VFs due to PF error responses
ice: stop disabling VFs due to PF error responses
James Morse (20):
arm64: entry.S: Add ventry overflow sanity checks
arm64: spectre: Rename spectre_v4_patch_fw_mitigation_conduit
KVM: arm64: Allow indirect vectors to be used without SPECTRE_V3A
arm64: entry: Make the trampoline cleanup optional
arm64: entry: Free up another register on kpti's tramp_exit path
arm64: entry: Move the trampoline data page before the text page
arm64: entry: Allow tramp_alias to access symbols after the 4K boundary
arm64: entry: Don't assume tramp_vectors is the start of the vectors
arm64: entry: Move trampoline macros out of ifdef'd section
arm64: entry: Make the kpti trampoline's kpti sequence optional
arm64: entry: Allow the trampoline text to occupy multiple pages
arm64: entry: Add non-kpti __bp_harden_el1_vectors for mitigations
arm64: entry: Add vectors that have the bhb mitigation sequences
arm64: entry: Add macro for reading symbol addresses from the trampoline
arm64: Add percpu vectors for EL1
arm64: proton-pack: Report Spectre-BHB vulnerabilities as part
of Spectre-v2
arm64: Mitigate spectre style branch history side channels
KVM: arm64: Allow SMCCC_ARCH_WORKAROUND_3 to be discovered and migrated
arm64: Use the clearbhb instruction in mitigations
arm64: proton-pack: Include unprivileged eBPF status in Spectre
v2 mitigation reporting
Jarkko Sakkinen (1):
x86/sgx: Free backing memory after faulting the enclave page
Jedrzej Jagielski (1):
ice: Fix curr_link_speed advertised speed
Jeff Layton (1):
fuse: move FUSE_SUPER_MAGIC definition to magic.h
Jeremy Linton (1):
net: bcmgenet: Don't claim WOL when its not available
Jernej Skrabec (1):
drm/sun4i: mixer: Fix P010 and P210 format numbers
Jia-Ju Bai (3):
HID: nintendo: check the return value of alloc_workqueue()
isdn: hfcpci: check the return value of dma_set_mask() in setup_hw()
net: qlogic: check the return value of dma_alloc_coherent() in
qed_vf_hw_prepare()
Jianglei Nie (1):
net: arc_emac: Fix use after free in arc_mdio_probe()
Jiapeng Chong (1):
ftrace: Fix some W=1 warnings in kernel doc comments
Jiasheng Jiang (2):
net: ethernet: ti: cpts: Handle error for clk_enable
net: ethernet: lpc_eth: Handle error for clk_enable
Jiri Kosina (1):
HID: elo: Revert USB reference counting
Jisheng Zhang (2):
MAINTAINERS: Update Jisheng's email address
riscv: alternative only works on !XIP_KERNEL
Joel Stanley (1):
ARM: dts: aspeed: Fix AST2600 quad spi group
Jon Hunter (1):
arm64: tegra: Disable ISO SMMU for Tegra194
Jonathan Marek (2):
arm64: dts: qcom: sm8450: enable GCC_USB3_0_CLKREF_EN for usb
arm64: dts: qcom: sm8450: fix apps_smmu interrupts
Josh Poimboeuf (3):
x86/speculation: Include unprivileged eBPF status in Spectre v2
mitigation reporting
x86/speculation: Warn about Spectre v2 LFENCE mitigation
x86/speculation: Warn about eIBRS + LFENCE + Unprivileged eBPF + SMT
Jouni Högander (1):
drm/i915/psr: Set "SF Partial Frame Enable" also on full update
Juergen Gross (12):
xen/xenbus: don't let xenbus_grant_ring() remove grants in error case
xen/grant-table: add gnttab_try_end_foreign_access()
xen/blkfront: don't use gnttab_query_foreign_access() for mapped status
xen/netfront: don't use gnttab_query_foreign_access() for mapped status
xen/scsifront: don't use gnttab_query_foreign_access() for mapped status
xen/gntalloc: don't use gnttab_query_foreign_access()
xen: remove gnttab_query_foreign_access()
xen/usb: don't use gnttab_end_foreign_access() in xenhcd_gnttab_done()
xen/9p: use alloc/free_pages_exact()
xen/pvcalls: use alloc/free_pages_exact()
xen/gnttab: fix gnttab_end_foreign_access() without page specified
xen/netfront: react properly to failing gnttab_end_foreign_access_ref()
Kai Lueke (1):
Revert "xfrm: state and policy should fail if XFRMA_IF_ID 0"
Kim Phillips (2):
x86/speculation: Use generic retpoline by default on AMD
x86/speculation: Update link to AMD speculation whitepaper
Krzysztof Kozlowski (1):
MAINTAINERS: update Krzysztof Kozlowski's email
Kuldeep Singh (1):
MAINTAINERS: Update git tree for Broadcom iProc SoCs
Li Huafei (1):
x86/traps: Mark do_int3() NOKPROBE_SYMBOL
Lina Wang (1):
xfrm: fix tunnel model fragmentation behavior
Linus Torvalds (2):
mm: gup: make fault_in_safe_writeable() use fixup_user_fault()
Linux 5.17-rc8
Lucas Zampieri (1):
HID: logitech-dj: add new lightspeed receiver id
Luiz Augusto von Dentz (1):
Bluetooth: hci_sync: Fix not processing all entries on cmd_sync_work
Marcelo Roberto Jimenez (1):
gpio: Revert regression in sysfs-gpio (gpiolib.c)
Mark Featherston (1):
gpio: ts4900: Do not set DAT and OE together
Maxime Ripard (1):
ARM: boot: dts: bcm2711: Fix HVS register range
Miaoqian Lin (3):
ethernet: Fix error handling in xemaclite_of_probe
net: marvell: prestera: Add missing of_node_put() in
prestera_switch_set_base_mac_addr
gianfar: ethtool: Fix refcount leak in gfar_get_ts_info
Michael Ellerman (1):
powerpc: Fix STACKTRACE=n build
Michael Hübner (1):
HID: Add support for open wheel and no attachment to T300
Michael S. Tsirkin (6):
virtio: unexport virtio_finalize_features
virtio: acknowledge all features before access
virtio: document virtio_reset_device
virtio_console: break out of buf poll on remove
virtio: drop default for virtio-mem
tools/virtio: handle fallout from folio work
Michal Maloszewski (2):
iavf: Fix handling of vlan strip virtual channel messages
iavf: Fix adopting new combined setting
Miklos Szeredi (2):
fuse: fix fileattr op failure
fuse: fix pipe buffer lifetime for direct_io
Minghao Chi (CGEL ZTE) (1):
net:mcf8390: Use platform_get_irq() to get the interrupt
Mohammad Kabat (1):
net/mlx5: Fix size field in bufferx_reg struct
Moshe Shemesh (1):
net/mlx5: Fix a race on command flush flow
Nathan Chancellor (2):
arm64: Do not include __READ_ONCE() block in assembly files
ARM: Do not use NOCROSSREFS directive with ld.lld
Nicolas Saenz Julienne (1):
tracing/osnoise: Force quiescent states while tracing
Nícolas F. R. A. Prado (1):
arm64: dts: mt8183: jacuzzi: Fix bus properties in anx's DSI endpoint
Pali Rohár (2):
arm64: dts: armada-3720-turris-mox: Add missing ethernet0 alias
arm64: dts: marvell: armada-37xx: Remap IO space to bus address 0x0
Paul Semel (1):
arm64: kasan: fix include error in MTE functions
Pavel Skripkin (2):
HID: hid-thrustmaster: fix OOB read in thrustmaster_interrupts
NFC: port100: fix use-after-free in port100_send_complete
Peter Zijlstra (3):
x86/speculation: Add eIBRS + Retpoline options
Documentation/hw-vuln: Update spectre doc
x86/module: Fix the paravirt vs alternative order
Peter Zijlstra (Intel) (1):
x86/speculation: Rename RETPOLINE_AMD to RETPOLINE_LFENCE
Randy Dunlap (1):
ARM: Spectre-BHB: provide empty stub for non-config
Rob Herring (1):
dt-bindings: mfd: Fix pinctrl node name warnings
Robert Foss (2):
dt-bindings: drm/bridge: anx7625: Revert DPI support
Revert "arm64: dts: mt8183: jacuzzi: Fix bus properties in anx's
DSI endpoint"
Robert Hancock (1):
net: macb: Fix lost RX packet wakeup race in NAPI receive
Roger Quadros (1):
mtd: rawnand: omap2: Actually prevent invalid configuration and
build error
Roi Dayan (1):
net/mlx5e: Lag, Only handle events from highest priority multipath entry
Rong Chen (1):
mmc: meson: Fix usage of meson_mmc_post_req()
Ross Philipson (2):
x86/boot: Fix memremap of setup_indirect structures
x86/boot: Add setup_indirect support in early_memremap_is_setup_data()
Russell King (Oracle) (9):
ARM: report Spectre v2 status through sysfs
ARM: early traps initialisation
ARM: use LOADADDR() to get load address of sections
ARM: Spectre-BHB workaround
net: dsa: mt7530: fix incorrect test in mt753x_phylink_validate()
ARM: include unprivileged BPF status in Spectre V2 reporting
ARM: fix co-processor register typo
ARM: fix build warning in proc-v7-bugs.c
ARM: fix Thumb2 regression with Spectre BHB
Sebastian Andrzej Siewior (1):
xdp: xdp_mem_allocator can be NULL in trace_mem_connect().
Shin'ichiro Kawasaki (1):
block: fix blk_mq_attempt_bio_merge and rq_qos_throttle protection
Si-Wei Liu (3):
vdpa: factor out vdpa_set_features_unlocked for vdpa internal use
vdpa/mlx5: should verify CTRL_VQ feature exists for MQ
vdpa/mlx5: add validation for VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET command
Stanislav Jakubek (1):
Revert "dt-bindings: arm: qcom: Document SDX65 platform and boards"
Steev Klimaszewski (1):
arm64: dts: qcom: c630: disable crypto due to serror
Stefano Garzarella (2):
vhost: remove avail_event arg from vhost_update_avail_event()
tools/virtio: fix virtio_test execution
Steffen Klassert (3):
esp: Fix possible buffer overflow in ESP transformation
esp: Fix BEET mode inter address family tunneling on GSO
net: Fix esp GSO on inter address family tunnels.
Taniya Das (2):
clk: qcom: gdsc: Add support to update GDSC transition delay
clk: qcom: dispcc: Update the transition delay for MDSS GDSC
Thierry Reding (1):
ARM: tegra: Move Nyan FHD panels to AUX bus
Thomas Zimmermann (1):
drm/panel: Select DRM_DP_HELPER for DRM_PANEL_EDP
Tom Rix (1):
qed: return status of qed_iov_get_link
Tung Nguyen (2):
tipc: fix kernel panic when enabling bearer
tipc: fix incorrect order of state message data sanity check
Ulf Hansson (1):
mmc: core: Restore (almost) the busy polling for MMC_SEND_OP_COND
Vladimir Oltean (1):
net: dsa: unlock the rtnl_mutex when dsa_master_setup() fails
Weiguo Li (2):
perf parse-events: Fix NULL check against wrong variable
perf bench: Fix NULL check against wrong variable
Xie Yongji (3):
vduse: Fix returning wrong type in vduse_domain_alloc_iova()
virtio-blk: Don't use MAX_DISCARD_SEGMENTS if max_discard_seg is zero
virtio-blk: Remove BUG_ON() in virtio_queue_rq()
Zhang Min (1):
vdpa: fix use-after-free on vp_vdpa_remove
Zhengjun Xing (1):
perf parse: Fix event parser error for hybrid systems
Zheyu Ma (1):
ethernet: sun: Free the coherent when failing in probing
Hi Linus,
I am the author of the "gpio: Revert regression..." patch.
On Mon, Mar 14, 2022 at 5:14 PM Linus Torvalds
<[email protected]> wrote:
>
> [ Adding more people to the cc, since this last change was triggered
> by earlier changes.
>
> On Mon, Mar 14, 2022 at 12:25 PM Guenter Roeck <[email protected]> wrote:
> >
> > Build results:
> > total: 155 pass: 155 fail: 0
> > Qemu test results:
> > total: 488 pass: 484 fail: 4
>
> Uhhuh. We got all the previous problems sorted out, but a new one instead.
>
> > This is a new problem. It bisects to commit fc328a7d1fcc ("gpio: Revert
> > regression in sysfs-gpio (gpiolib.c)"). The network connection fails
> > in the affected tests. Reverting the offending commit (ie reverting the
> > revert) fixes the problem.
>
> Hmm. Looking at the changes since 5.16, that commit fc328a7d1fcc looks
> somewhat suspicious.
>
> It claims to "revert" things, but the behavior it reverts goes
> basically all the way back to v5.7 (with one of the patches going into
> 5.10).
>
> And it clearly breaks things that used to work much more recently (ie
> this worked in rc7, but it was also the state in every release since
> 5.10).
>
> So unless somebody can find the _real_ issue here, I suspect very
> strongly that that "fix" that came in last week was just wrong.
>
> It is also very non-specific "Some GPIO lines have stopped working"
> with no pointer to actual reports.
The original message in which I posted the patch also had a small
report. I listed the board in which the problem appeared and a small
test script to show the error, which I have used to bisect the issue.
The whole thread is here, the test is in the first message:
https://lore.kernel.org/all/[email protected]/t/
> LinusW? Thierry? Bartoz? Anybody?
>
> Yes, there;s something bad going on here, but we can't randomly "fix"
> things in an rc8 that have worked for several releases by now.
The original patch just reverted the patch that introduced the problem
I found. But if the reversion introduces problems at this point, then
the sane thing to do is to revert the reversion.
At a certain point, I tried Thorsten's suggestion to add a gpio-ranges
property in a way similar to another patch, but the kernel went into
an EPROBE_DEFER deadlock. Thierry Reding made some comments about this
in the sequence.
Following Linus Walleij's suggestion, we are moving the code from the
sysfs interface to the character device. But in the meantime, we are
using this "revert patch" in a 5.10.80 kernel, so maybe someone could
point me to details of the network misbehaviour so that I can also
check it?
>
> Linus
Regards,
Marcelo.
On 3/14/22 17:45, Marcelo Roberto Jimenez wrote:
> Hi Linus,
>
> I am the author of the "gpio: Revert regression..." patch.
>
> On Mon, Mar 14, 2022 at 5:14 PM Linus Torvalds
> <[email protected]> wrote:
>>
>> [ Adding more people to the cc, since this last change was triggered
>> by earlier changes.
>>
>> On Mon, Mar 14, 2022 at 12:25 PM Guenter Roeck <[email protected]> wrote:
>>>
>>> Build results:
>>> total: 155 pass: 155 fail: 0
>>> Qemu test results:
>>> total: 488 pass: 484 fail: 4
>>
>> Uhhuh. We got all the previous problems sorted out, but a new one instead.
>>
>>> This is a new problem. It bisects to commit fc328a7d1fcc ("gpio: Revert
>>> regression in sysfs-gpio (gpiolib.c)"). The network connection fails
>>> in the affected tests. Reverting the offending commit (ie reverting the
>>> revert) fixes the problem.
>>
>> Hmm. Looking at the changes since 5.16, that commit fc328a7d1fcc looks
>> somewhat suspicious.
>>
>> It claims to "revert" things, but the behavior it reverts goes
>> basically all the way back to v5.7 (with one of the patches going into
>> 5.10).
>>
>> And it clearly breaks things that used to work much more recently (ie
>> this worked in rc7, but it was also the state in every release since
>> 5.10).
>>
>> So unless somebody can find the _real_ issue here, I suspect very
>> strongly that that "fix" that came in last week was just wrong.
>>
>> It is also very non-specific "Some GPIO lines have stopped working"
>> with no pointer to actual reports.
>
> The original message in which I posted the patch also had a small
> report. I listed the board in which the problem appeared and a small
> test script to show the error, which I have used to bisect the issue.
>
> The whole thread is here, the test is in the first message:
> https://lore.kernel.org/all/[email protected]/t/
>
>> LinusW? Thierry? Bartoz? Anybody?
>>
>> Yes, there;s something bad going on here, but we can't randomly "fix"
>> things in an rc8 that have worked for several releases by now.
>
> The original patch just reverted the patch that introduced the problem
> I found. But if the reversion introduces problems at this point, then
> the sane thing to do is to revert the reversion.
>
> At a certain point, I tried Thorsten's suggestion to add a gpio-ranges
> property in a way similar to another patch, but the kernel went into
> an EPROBE_DEFER deadlock. Thierry Reding made some comments about this
> in the sequence.
>
> Following Linus Walleij's suggestion, we are moving the code from the
> sysfs interface to the character device. But in the meantime, we are
> using this "revert patch" in a 5.10.80 kernel, so maybe someone could
> point me to details of the network misbehaviour so that I can also
> check it?
>
See https://kerneltests.org/builders/qemu-arm-master/builds/2030/steps/qemubuildcommand/logs/stdio
for logs.
There are two problem with your patch:
- The Ethernet interface on imx25's qemu emulation does not come online.
- The mmc does not come online (I just noticed this one)
Looking into the devicetree file, my guess is that the gpio
lines attached to the Ethernet PHY and the sdhci controller
don't report pin status changes. I did not try to confirm this,
though.
Your patch may work for you on top of v5.10.y, but it doesn't
work there for imx25 either.
Guenter
On Mon, Mar 14, 2022 at 5:45 PM Marcelo Roberto Jimenez
<[email protected]> wrote:
>
> At a certain point, I tried Thorsten's suggestion to add a gpio-ranges
> property in a way similar to another patch, but the kernel went into
> an EPROBE_DEFER deadlock. Thierry Reding made some comments about this
> in the sequence.
Hmm. The problem does sound like that particular driver doesn't use
the pin_ranges thing, so then the tests for an empty pin_ranges will
always be true.
The EPROBE_DEFER deadlock then sounds like something went wrong in the
gpio-ranges patch when you tried to fix it - but I don't actually find
that patch or that attempt, so I can't even guess at it.
This whole code pin_ranges code looks very odd:
gpiochip_add_pin{group}_range() seems to add the pin ranges properly,
but that actual gpiochip_add_pin_ranges() function does *not*.
It just expects that that the 'add_pin_ranges()' callback exists, and
if it doesn't, does nothing at all.
Which then makes those
if (list_empty(&gc->gpiodev->pin_ranges))
return 0;
tests very suspicious - because if some doesn't implement that
add_pin_ranges() callback, it looks like nothing at all ever gets
done, because nothing calls the function to actually add the pinrange.
And then that "list_empty()" test very much will trigger.
IOW, it looks like either a gpio controller has to implement that
'add_pin_ranges()' function (only tegra), or it needs to always add
the pin ranges at probe time.
Am I guessing right that the driver that you use does neither?
LinusW/Bartoz - this all really sounds strange to me. Maybe I'm
misreading the situation entirely. Should there be some sanity-test
that any gpio/pinctrl driver that uses gpiochip_generic_request()
would either have to have that add_pin_ranges() callback, or a
successful probe needs to always populate that 'gpiodev->pin_ranges'
list?
Or maybe I'm misreading the situation entirely. I don't know the code
- I'm just grepping for things and trying to make sense of how that
'->pin_ranges' list is supposed to work.
But for now, I think that patch has to be reverted.
Linus
Below is the list of build error/warning regressions/improvements in
v5.17-rc8[1] compared to v5.16[2].
Summarized:
- build errors: +8/-3
- build warnings: +23/-27
JFYI, when comparing v5.17-rc8[1] to v5.17-rc7[3], the summaries are:
- build errors: +0/-9
- build warnings: +0/-3
Note that there may be false regressions, as some logs are incomplete.
Still, they're build errors/warnings.
Happy fixing! ;-)
Thanks to the linux-next team for providing the build service.
[1] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/09688c0166e76ce2fb85e86b9d99be8b0084cdf9/ (96 out of 100 configs)
[2] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/df0cc57e057f18e44dac8e6c18aba47ab53202f9/ (98 out of 100 configs)
[3] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/ffb217a13a2eaf6d5bd974fc83036a53ca69f1e2/ (all 100 configs)
*** ERRORS ***
8 error regressions:
+ /kisskb/src/arch/sparc/mm/srmmu.c: error: cast between incompatible function types from 'void (*)(long unsigned int)' to 'void (*)(long unsigned int, long unsigned int, long unsigned int, long unsigned int, long unsigned int)' [-Werror=cast-function-type]: => 1639:13, 1756:13
+ /kisskb/src/arch/sparc/mm/srmmu.c: error: cast between incompatible function types from 'void (*)(struct mm_struct *)' to 'void (*)(long unsigned int, long unsigned int, long unsigned int, long unsigned int, long unsigned int)' [-Werror=cast-function-type]: => 1674:29, 1662:29
+ /kisskb/src/arch/sparc/mm/srmmu.c: error: cast between incompatible function types from 'void (*)(struct mm_struct *, long unsigned int)' to 'void (*)(long unsigned int, long unsigned int, long unsigned int, long unsigned int, long unsigned int)' [-Werror=cast-function-type]: => 1767:21
+ /kisskb/src/arch/sparc/mm/srmmu.c: error: cast between incompatible function types from 'void (*)(struct vm_area_struct *, long unsigned int)' to 'void (*)(long unsigned int, long unsigned int, long unsigned int, long unsigned int, long unsigned int)' [-Werror=cast-function-type]: => 1726:29, 1741:29
+ /kisskb/src/arch/sparc/mm/srmmu.c: error: cast between incompatible function types from 'void (*)(struct vm_area_struct *, long unsigned int, long unsigned int)' to 'void (*)(long unsigned int, long unsigned int, long unsigned int, long unsigned int, long unsigned int)' [-Werror=cast-function-type]: => 1711:29, 1694:29
+ /kisskb/src/arch/um/include/asm/processor-generic.h: error: called object is not a function or function pointer: => 103:18
+ /kisskb/src/drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c: error: control reaches end of non-void function [-Werror=return-type]: => 1560:1
+ error: arch/powerpc/kvm/book3s_64_entry.o: relocation truncated to fit: R_PPC64_REL14 (stub) against symbol `system_reset_common' defined in .text section in arch/powerpc/kernel/head_64.o: => (.text+0x3ec)
3 error improvements:
- /kisskb/src/crypto/blake2b_generic.c: error: the frame size of 2288 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]: 109:1 =>
- /kisskb/src/drivers/mtd/nand/raw/mpc5121_nfc.c: error: unused variable 'mtd' [-Werror=unused-variable]: 294:19 =>
- /kisskb/src/drivers/video/fbdev/riva/fbdev.c: error: passing argument 1 of 'iounmap' discards 'volatile' qualifier from pointer target type [-Werror=discarded-qualifiers]: 2095:11, 2062:11 =>
*** WARNINGS ***
23 warning regressions:
+ modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x14410): Section mismatch in reference from the variable qed_mfw_legacy_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: => N/A
+ modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x14428): Section mismatch in reference from the variable qed_mfw_legacy_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: => N/A
+ modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x14440): Section mismatch in reference from the variable qed_mfw_legacy_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: => N/A
+ modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x14458): Section mismatch in reference from the variable qed_mfw_legacy_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: => N/A
+ modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x14470): Section mismatch in reference from the variable qed_mfw_legacy_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: => N/A
+ modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x14488): Section mismatch in reference from the variable qed_mfw_legacy_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: => N/A
+ modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x144a0): Section mismatch in reference from the variable qed_mfw_legacy_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: => N/A
+ modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x144f0): Section mismatch in reference from the variable qed_mfw_ext_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: => N/A
+ modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x14508): Section mismatch in reference from the variable qed_mfw_ext_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: => N/A
+ modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x14520): Section mismatch in reference from the variable qed_mfw_ext_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: => N/A
+ modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x14538): Section mismatch in reference from the variable qed_mfw_ext_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: => N/A
+ modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x14550): Section mismatch in reference from the variable qed_mfw_ext_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: => N/A
+ modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x14568): Section mismatch in reference from the variable qed_mfw_ext_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: => N/A
+ modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x14580): Section mismatch in reference from the variable qed_mfw_ext_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: => N/A
+ modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x14598): Section mismatch in reference from the variable qed_mfw_ext_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: => N/A
+ modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x4790): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000: => N/A
+ modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x47a8): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000: => N/A
+ modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x47c0): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000: => N/A
+ modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x47d8): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000: => N/A
+ modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x47f0): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000: => N/A
+ modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x4808): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000: => N/A
+ modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x4820): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000: => N/A
+ modpost: WARNING: modpost: vmlinux.o(.text.unlikely+0x4530): Section mismatch in reference from the function __trace_event_discard_commit() to the variable .init.data:initcall_level_names: => N/A
27 warning improvements:
- arch/m68k/configs/multi_defconfig: warning: symbol value 'm' invalid for MCTP: 322 =>
- arch/m68k/configs/sun3_defconfig: warning: symbol value 'm' invalid for MCTP: 295 =>
- modpost: WARNING: modpost: EXPORT symbol "clear_page" [vmlinux] version ...: N/A =>
- modpost: WARNING: modpost: EXPORT symbol "copy_page" [vmlinux] version ...: N/A =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x136d0): Section mismatch in reference from the variable qed_mfw_legacy_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x136e8): Section mismatch in reference from the variable qed_mfw_legacy_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x13700): Section mismatch in reference from the variable qed_mfw_legacy_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x13718): Section mismatch in reference from the variable qed_mfw_legacy_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x13730): Section mismatch in reference from the variable qed_mfw_legacy_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x13748): Section mismatch in reference from the variable qed_mfw_legacy_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x13760): Section mismatch in reference from the variable qed_mfw_legacy_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x137b0): Section mismatch in reference from the variable qed_mfw_ext_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x137c8): Section mismatch in reference from the variable qed_mfw_ext_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x137e0): Section mismatch in reference from the variable qed_mfw_ext_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x137f8): Section mismatch in reference from the variable qed_mfw_ext_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x13810): Section mismatch in reference from the variable qed_mfw_ext_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x13828): Section mismatch in reference from the variable qed_mfw_ext_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x13840): Section mismatch in reference from the variable qed_mfw_ext_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x13858): Section mismatch in reference from the variable qed_mfw_ext_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x4610): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000: N/A =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x4628): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000: N/A =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x4640): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000: N/A =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x4658): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000: N/A =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x4670): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000: N/A =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x4688): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000: N/A =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x46a0): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000: N/A =>
- modpost: WARNING: modpost: vmlinux.o(.text.unlikely+0x45e4): Section mismatch in reference from the function __trace_event_discard_commit() to the variable .init.data:initcall_level_names: N/A =>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Tue, Mar 15, 2022 at 2:47 AM Linus Torvalds
<[email protected]> wrote:
>
> On Mon, Mar 14, 2022 at 5:45 PM Marcelo Roberto Jimenez
> <[email protected]> wrote:
> >
> > At a certain point, I tried Thorsten's suggestion to add a gpio-ranges
> > property in a way similar to another patch, but the kernel went into
> > an EPROBE_DEFER deadlock. Thierry Reding made some comments about this
> > in the sequence.
>
> Hmm. The problem does sound like that particular driver doesn't use
> the pin_ranges thing, so then the tests for an empty pin_ranges will
> always be true.
>
> The EPROBE_DEFER deadlock then sounds like something went wrong in the
> gpio-ranges patch when you tried to fix it - but I don't actually find
> that patch or that attempt, so I can't even guess at it.
>
> This whole code pin_ranges code looks very odd:
> gpiochip_add_pin{group}_range() seems to add the pin ranges properly,
> but that actual gpiochip_add_pin_ranges() function does *not*.
>
> It just expects that that the 'add_pin_ranges()' callback exists, and
> if it doesn't, does nothing at all.
>
> Which then makes those
>
> if (list_empty(&gc->gpiodev->pin_ranges))
> return 0;
>
> tests very suspicious - because if some doesn't implement that
> add_pin_ranges() callback, it looks like nothing at all ever gets
> done, because nothing calls the function to actually add the pinrange.
> And then that "list_empty()" test very much will trigger.
>
> IOW, it looks like either a gpio controller has to implement that
> 'add_pin_ranges()' function (only tegra), or it needs to always add
> the pin ranges at probe time.
>
> Am I guessing right that the driver that you use does neither?
>
There are more drivers than just tegra that implement add_pin_ranges()
but you're right, pinctrl-at91.c used by Marcelo does not.
> LinusW/Bartoz - this all really sounds strange to me. Maybe I'm
It's BartoSz actually. :)
> misreading the situation entirely. Should there be some sanity-test
> that any gpio/pinctrl driver that uses gpiochip_generic_request()
> would either have to have that add_pin_ranges() callback, or a
> successful probe needs to always populate that 'gpiodev->pin_ranges'
> list?
>
This sounds right to me but I need to spend some more time on this, I
didn't author the code in question.
> Or maybe I'm misreading the situation entirely. I don't know the code
> - I'm just grepping for things and trying to make sense of how that
> '->pin_ranges' list is supposed to work.
>
> But for now, I think that patch has to be reverted.
>
Sounds good, I'll send a revert and make another PR with fixes before v5.17.
Bartosz
> Linus
[ Adding more people to the cc, since this last change was triggered
by earlier changes.
On Mon, Mar 14, 2022 at 12:25 PM Guenter Roeck <[email protected]> wrote:
>
> Build results:
> total: 155 pass: 155 fail: 0
> Qemu test results:
> total: 488 pass: 484 fail: 4
Uhhuh. We got all the previous problems sorted out, but a new one instead.
> This is a new problem. It bisects to commit fc328a7d1fcc ("gpio: Revert
> regression in sysfs-gpio (gpiolib.c)"). The network connection fails
> in the affected tests. Reverting the offending commit (ie reverting the
> revert) fixes the problem.
Hmm. Looking at the changes since 5.16, that commit fc328a7d1fcc looks
somewhat suspicious.
It claims to "revert" things, but the behavior it reverts goes
basically all the way back to v5.7 (with one of the patches going into
5.10).
And it clearly breaks things that used to work much more recently (ie
this worked in rc7, but it was also the state in every release since
5.10).
So unless somebody can find the _real_ issue here, I suspect very
strongly that that "fix" that came in last week was just wrong.
It is also very non-specific "Some GPIO lines have stopped working"
with no pointer to actual reports.
LinusW? Thierry? Bartoz? Anybody?
Yes, there;s something bad going on here, but we can't randomly "fix"
things in an rc8 that have worked for several releases by now.
Linus
[CCing regressions list and Michael Walle]
FWIW, I was a bit surprised to see this, I had assumed the revert that
causing trouble (fc328a7d1fcc) would go in the next merge window. Seems
my regression tracking work did more harm then good here. :-/ Whatever:
On 15.03.22 02:47, Linus Torvalds wrote:
> On Mon, Mar 14, 2022 at 5:45 PM Marcelo Roberto Jimenez
> <[email protected]> wrote:
>>
>> At a certain point, I tried Thorsten's suggestion to add a gpio-ranges
>> property in a way similar to another patch, but the kernel went into
>> an EPROBE_DEFER deadlock. Thierry Reding made some comments about this
>> in the sequence.
>
> Hmm. The problem does sound like that particular driver doesn't use
> the pin_ranges thing, so then the tests for an empty pin_ranges will
> always be true.
>
> [...]
>
> IOW, it looks like either a gpio controller has to implement that
> 'add_pin_ranges()' function (only tegra), or it needs to always add
> the pin ranges at probe time.
>
> Am I guessing right that the driver that you use does neither?
>
> LinusW/Bartoz - this all really sounds strange to me. Maybe I'm
> misreading the situation entirely. Should there be some sanity-test
> that any gpio/pinctrl driver that uses gpiochip_generic_request()
> would either have to have that add_pin_ranges() callback, or a
> successful probe needs to always populate that 'gpiodev->pin_ranges'
> list?
>
> Or maybe I'm misreading the situation entirely. I don't know the code
> - I'm just grepping for things and trying to make sense of how that
> '->pin_ranges' list is supposed to work.
>
> But for now, I think that patch has to be reverted.
There is a another reason to do so: Michael Walle reported that the
revert is causing a regression for him:
https://lore.kernel.org/stable/[email protected]/
To quote:
```
> This breaks the pinctrl-microchip-sgpio driver as far as I can see.
>
> I tried to debug it and this is what I have discovered so far:
> (1) the sgpio driver will use the gpio_stub_drv for its child nodes.
> Looks like a workaround, see [1].
> (2) these will have an empty gpio range
> (3) with the changes of this patch, pinctrl_gpio_request() will now
> be called and will fail with -EPROBE_DEFER.
>
> I'm not exactly sure what to do here. Saravana Kannan once suggested
> to use devm_of_platform_populate() to probe the child nodes [2]. But
> I haven't found any other driver doing that.
>
> Also, I'm not sure if there are any other other driver which get
> broken by this. I.e. ones falling into the gpio_stub_drv category.
>
> [1] https://lore.kernel.org/lkml/[email protected]/
> [2] https://lore.kernel.org/lkml/CAGETcx9PiX==mLxB9PO8Myyk6u2vhPVwTMsA5NkD-ywH5xhusw@mail.gmail.com/
>
> -michael
>
> NB. this patch doesn't contain a Fixes tag. Was this on purpose?
```
Ciao, Thorsten
On Tue, Mar 15, 2022 at 9:43 AM Linus Torvalds
<[email protected]> wrote:
> [ Adding more people to the cc, since this last change was triggered
> by earlier changes.
>
> On Mon, Mar 14, 2022 at 12:25 PM Guenter Roeck <[email protected]> wrote:
> >
> > Build results:
> > total: 155 pass: 155 fail: 0
> > Qemu test results:
> > total: 488 pass: 484 fail: 4
>
> Uhhuh. We got all the previous problems sorted out, but a new one instead.
>
> > This is a new problem. It bisects to commit fc328a7d1fcc ("gpio: Revert
> > regression in sysfs-gpio (gpiolib.c)"). The network connection fails
> > in the affected tests. Reverting the offending commit (ie reverting the
> > revert) fixes the problem.
>
> Hmm. Looking at the changes since 5.16, that commit fc328a7d1fcc looks
> somewhat suspicious.
>
> It claims to "revert" things, but the behavior it reverts goes
> basically all the way back to v5.7 (with one of the patches going into
> 5.10).
>
> And it clearly breaks things that used to work much more recently (ie
> this worked in rc7, but it was also the state in every release since
> 5.10).
>
> So unless somebody can find the _real_ issue here, I suspect very
> strongly that that "fix" that came in last week was just wrong.
>
> It is also very non-specific "Some GPIO lines have stopped working"
> with no pointer to actual reports.
>
> LinusW? Thierry? Bartoz? Anybody?
>
> Yes, there;s something bad going on here, but we can't randomly "fix"
> things in an rc8 that have worked for several releases by now.
People really need to learn[1] to add proper Link tags to each and every
commit:
https://lore.kernel.org/all/[email protected]
The last mail in that thread is a regression report for the fix.
Note that this "fix" has only been in next-20220308 and later, so
more breakage may show up soon...
[1] https://www.kernel.org/doc/html/v5.6/maintainer/configure-git.html#creating-commit-links-to-lore-kernel-org
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Sun, Mar 13, 2022 at 01:43:59PM -0700, Linus Torvalds wrote:
> So last weekend, I thought I'd be releasing the final 5.17 today.
>
[ ... ]
> Anyway, let's not keep the testing _just_ to automation - the more the
> merrier, and real-life loads are always more interesting than what the
> automation farms do. So please do give this last rc a quick try,
>
Build results:
total: 155 pass: 155 fail: 0
Qemu test results:
total: 488 pass: 484 fail: 4
Failed tests:
arm:imx25-pdk:imx_v4_v5_defconfig:nonand:mem128:net,default:imx25-pdk:initrd
arm:imx25-pdk:imx_v4_v5_defconfig:nonand:sd:mem128:net,default:imx25-pdk:rootfs
arm:imx25-pdk:imx_v4_v5_defconfig:nonand:usb0:mem128:net,default:imx25-pdk:rootfs
arm:imx25-pdk:imx_v4_v5_defconfig:nonand:usb1:mem128:net,default:imx25-pdk:rootfs
This is a new problem. It bisects to commit fc328a7d1fcc ("gpio: Revert
regression in sysfs-gpio (gpiolib.c)"). The network connection fails
in the affected tests. Reverting the offending commit (ie reverting the
revert) fixes the problem.
Guenter
---
# bad: [09688c0166e76ce2fb85e86b9d99be8b0084cdf9] Linux 5.17-rc8
# good: [ea4424be16887a37735d6550cfd0611528dbe5d9] Merge tag 'mtd/fixes-for-5.17-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux
git bisect start 'HEAD' 'ea4424be1688'
# bad: [55b4083b44361d833c93216a619d3b4e6d03a0c9] Merge tag 'soc-fixes-5.17-3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
git bisect bad 55b4083b44361d833c93216a619d3b4e6d03a0c9
# good: [36168e387fa7d0f1fe0cd5cf76c8cea7aee714fa] ARM: Do not use NOCROSSREFS directive with ld.lld
git bisect good 36168e387fa7d0f1fe0cd5cf76c8cea7aee714fa
# bad: [1db333d9a51f3459fba1bcaa564d95befe79f0b3] Merge tag 'spi-fix-v5.17-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
git bisect bad 1db333d9a51f3459fba1bcaa564d95befe79f0b3
# good: [b5521fe9a9336caa1caa2db126f1d3ba1bc8303e] Merge tag 'xsa396-5.17-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip
git bisect good b5521fe9a9336caa1caa2db126f1d3ba1bc8303e
# bad: [55d01c98a88b346e217eaa931b32e7baea905c9a] gpio: sim: fix a typo
git bisect bad 55d01c98a88b346e217eaa931b32e7baea905c9a
# bad: [660c619b9d7ccd28648ee3766cdbe94ec7b27402] gpiolib: acpi: Convert ACPI value of debounce to microseconds
git bisect bad 660c619b9d7ccd28648ee3766cdbe94ec7b27402
# bad: [fc328a7d1fcce263db0b046917a66f3aa6e68719] gpio: Revert regression in sysfs-gpio (gpiolib.c)
git bisect bad fc328a7d1fcce263db0b046917a66f3aa6e68719
# good: [5f84e73f9a8f14b95115b0eb2080da6d9fa7a82e] gpio: tegra186: Add IRQ per bank for Tegra241
git bisect good 5f84e73f9a8f14b95115b0eb2080da6d9fa7a82e
# first bad commit: [fc328a7d1fcce263db0b046917a66f3aa6e68719] gpio: Revert regression in sysfs-gpio (gpiolib.c)