Re: linux-next failing build due to missing cubictcp_state symbol

Re: linux-next failing build due to missing cubictcp_state symbol

[Yonghong Song]

On 4/23/21 6:05 AM, Michal Suchánek wrote:
> Hello,
> 
> I see this build error in linux-next (config attached).
> 
> [ 4939s]   LD      vmlinux
> [ 4959s]   BTFIDS  vmlinux
> [ 4959s] FAILED unresolved symbol cubictcp_state
> [ 4960s] make[1]: ***
> [/home/abuild/rpmbuild/BUILD/kernel-vanilla-5.12~rc8.next.20210422/linux-5.12-rc8-next-20210422/Makefile:1277:
> vmlinux] Error 255
> [ 4960s] make: *** [../Makefile:222: __sub-make] Error 2

Looks like you have DYNAMIC_FTRACE config option enabled already.
Could you try a later version of pahole?

Re: linux-next failing build due to missing cubictcp_state symbol

[Michal Suchánek]

On Fri, Apr 23, 2021 at 07:41:29AM -0700, Yonghong Song wrote:
> 
> 
> On 4/23/21 6:05 AM, Michal Suchánek wrote:
> > Hello,
> > 
> > I see this build error in linux-next (config attached).
> > 
> > [ 4939s]   LD      vmlinux
> > [ 4959s]   BTFIDS  vmlinux
> > [ 4959s] FAILED unresolved symbol cubictcp_state
> > [ 4960s] make[1]: ***
> > [/home/abuild/rpmbuild/BUILD/kernel-vanilla-5.12~rc8.next.20210422/linux-5.12-rc8-next-20210422/Makefile:1277:
> > vmlinux] Error 255
> > [ 4960s] make: *** [../Makefile:222: __sub-make] Error 2
> 
> Looks like you have DYNAMIC_FTRACE config option enabled already.
> Could you try a later version of pahole?

Is this requireent new?

I have pahole 1.20, and master does build without problems.

If newer version is needed can a check be added?

Thanks

Michal

Re: linux-next failing build due to missing cubictcp_state symbol

[Michal Suchánek]

On Fri, Apr 23, 2021 at 07:55:28PM +0200, Michal Suchánek wrote:
> On Fri, Apr 23, 2021 at 07:41:29AM -0700, Yonghong Song wrote:
> > 
> > 
> > On 4/23/21 6:05 AM, Michal Suchánek wrote:
> > > Hello,
> > > 
> > > I see this build error in linux-next (config attached).
> > > 
> > > [ 4939s]   LD      vmlinux
> > > [ 4959s]   BTFIDS  vmlinux
> > > [ 4959s] FAILED unresolved symbol cubictcp_state
> > > [ 4960s] make[1]: ***
> > > [/home/abuild/rpmbuild/BUILD/kernel-vanilla-5.12~rc8.next.20210422/linux-5.12-rc8-next-20210422/Makefile:1277:
> > > vmlinux] Error 255
> > > [ 4960s] make: *** [../Makefile:222: __sub-make] Error 2
> > 
> > Looks like you have DYNAMIC_FTRACE config option enabled already.
> > Could you try a later version of pahole?
> 
> Is this requireent new?
> 
> I have pahole 1.20, and master does build without problems.
> 
> If newer version is needed can a check be added?

With dwarves 1.21 some architectures are fixed and some report other
missing symbol. Definitely an improvenent.

I see some new type support was added so it makes sense if that type is
used the new dwarves are needed.

Thanks

Michal

Re: linux-next failing build due to missing cubictcp_state symbol

[Michal Suchánek]

[-- Attachment #1: Type: text/plain, Size: 1582 bytes --]

On Sun, Apr 25, 2021 at 01:15:45PM +0200, Michal Suchánek wrote:
> On Fri, Apr 23, 2021 at 07:55:28PM +0200, Michal Suchánek wrote:
> > On Fri, Apr 23, 2021 at 07:41:29AM -0700, Yonghong Song wrote:
> > > 
> > > 
> > > On 4/23/21 6:05 AM, Michal Suchánek wrote:
> > > > Hello,
> > > > 
> > > > I see this build error in linux-next (config attached).
> > > > 
> > > > [ 4939s]   LD      vmlinux
> > > > [ 4959s]   BTFIDS  vmlinux
> > > > [ 4959s] FAILED unresolved symbol cubictcp_state
> > > > [ 4960s] make[1]: ***
> > > > [/home/abuild/rpmbuild/BUILD/kernel-vanilla-5.12~rc8.next.20210422/linux-5.12-rc8-next-20210422/Makefile:1277:
> > > > vmlinux] Error 255
> > > > [ 4960s] make: *** [../Makefile:222: __sub-make] Error 2
> > > 
> > > Looks like you have DYNAMIC_FTRACE config option enabled already.
> > > Could you try a later version of pahole?
> > 
> > Is this requireent new?
> > 
> > I have pahole 1.20, and master does build without problems.
> > 
> > If newer version is needed can a check be added?
> 
> With dwarves 1.21 some architectures are fixed and some report other
> missing symbol. Definitely an improvenent.
> 
> I see some new type support was added so it makes sense if that type is
> used the new dwarves are needed.

Ok, here is the current failure with dwarves 1.21 on 5.12:

[ 2548s]   LD      vmlinux
[ 2557s]   BTFIDS  vmlinux
[ 2557s] FAILED unresolved symbol vfs_truncate
[ 2558s] make[1]: ***
[/home/abuild/rpmbuild/BUILD/kernel-kvmsmall-5.12.0/linux-5.12/Makefile:1213:
vmlinux] Error 255

Any idea where this one is coming from?

Thanks

Michal

[-- Attachment #2: kvmsmall --]
[-- Type: text/plain, Size: 11904 bytes --]

# CONFIG_AD525X_DPOT is not set
# CONFIG_AGP is not set
# CONFIG_ALIM7101_WDT is not set
# CONFIG_ALTERA_MSGDMA is not set
# CONFIG_ALTERA_STAPL is not set
# CONFIG_AMD_PHY is not set
# CONFIG_AQUANTIA_PHY is not set
# CONFIG_ATA is not set
# CONFIG_AUXDISPLAY is not set
# CONFIG_AX88796B_PHY is not set
# CONFIG_BACKLIGHT_CLASS_DEVICE is not set
# CONFIG_BCM7XXX_PHY is not set
# CONFIG_BCM87XX_PHY is not set
# CONFIG_BCMA is not set
# CONFIG_BCM_KONA_USB2_PHY is not set
# CONFIG_BE2ISCSI is not set
# CONFIG_BLK_DEV_PCIESSD_MTIP32XX is not set
# CONFIG_BROADCOM_PHY is not set
# CONFIG_BT is not set
# CONFIG_C2PORT is not set
# CONFIG_CAIF is not set
# CONFIG_CB710_CORE is not set
# CONFIG_CICADA_PHY is not set
# CONFIG_CRYPTO_DEV_ATMEL_ECC is not set
# CONFIG_CRYPTO_DEV_ATMEL_SHA204A is not set
# CONFIG_DAVICOM_PHY is not set
# CONFIG_DP83822_PHY is not set
# CONFIG_DP83848_PHY is not set
# CONFIG_DP83867_PHY is not set
# CONFIG_DP83TC811_PHY is not set
# CONFIG_DRM is not set
# CONFIG_DS1682 is not set
# CONFIG_DW_DMAC_PCI is not set
# CONFIG_DW_EDMA is not set
# CONFIG_DW_EDMA_PCIE is not set
# CONFIG_EHEA is not set
# CONFIG_EXTCON is not set
# CONFIG_FB is not set
# CONFIG_FIREWIRE is not set
# CONFIG_FPGA is not set
# CONFIG_FSI is not set
# CONFIG_FUSION is not set
# CONFIG_GNSS is not set
# CONFIG_GPIO_BT8XX is not set
# CONFIG_GVE is not set
# CONFIG_HABANA_AI is not set
# CONFIG_HMC6352 is not set
# CONFIG_HP_ILO is not set
# CONFIG_HSI is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_HWMON is not set
CONFIG_I2C=m
# CONFIG_I2C_ALGOPCA is not set
# CONFIG_I2C_ALGOPCF is not set
# CONFIG_I2C_CHARDEV is not set
# CONFIG_I2C_HELPER_AUTO is not set
# CONFIG_I2C_MUX is not set
# CONFIG_I2C_NVIDIA_GPU is not set
# CONFIG_I2C_SMBUS is not set
# CONFIG_I2C_STUB is not set
# CONFIG_I2C_TAOS_EVM is not set
# CONFIG_I3C is not set
# CONFIG_IBM_EMAC is not set
# CONFIG_IBM_EMAC_EMAC4 is not set
# CONFIG_IBM_EMAC_RGMII is not set
# CONFIG_IBM_EMAC_TAH is not set
# CONFIG_IBM_EMAC_ZMII is not set
# CONFIG_ICPLUS_PHY is not set
# CONFIG_ICS932S401 is not set
# CONFIG_IEEE802154_DRIVERS is not set
# CONFIG_INFINIBAND is not set
# CONFIG_INPUT is not set
# CONFIG_INTEL_IDMA64 is not set
# CONFIG_INTEL_XWAY_PHY is not set
# CONFIG_IPACK_BUS is not set
# CONFIG_ISDN is not set
# CONFIG_ISL29020 is not set
# CONFIG_LCD_CLASS_DEVICE is not set
CONFIG_LOCALVERSION="-kvmsmall"
# CONFIG_LPC_ICH is not set
# CONFIG_LPC_SCH is not set
# CONFIG_LSI_ET1011C_PHY is not set
# CONFIG_LXT_PHY is not set
# CONFIG_MACINTOSH_DRIVERS is not set
# CONFIG_MARVELL_10G_PHY is not set
# CONFIG_MARVELL_PHY is not set
# CONFIG_MDIO_BCM_UNIMAC is not set
# CONFIG_MDIO_MSCC_MIIM is not set
# CONFIG_MEDIA_SUPPORT is not set
# CONFIG_MEGARAID_SAS is not set
# CONFIG_MEMSTICK_JMICRON_38X is not set
# CONFIG_MEMSTICK_R592 is not set
# CONFIG_MEMSTICK_TIFM_MS is not set
# CONFIG_MFD_DA9062 is not set
# CONFIG_MFD_KEMPLD is not set
# CONFIG_MFD_LM3533 is not set
# CONFIG_MFD_LP3943 is not set
# CONFIG_MFD_MADERA is not set
# CONFIG_MFD_MAX77650 is not set
# CONFIG_MFD_MAX8907 is not set
# CONFIG_MFD_STMFX is not set
# CONFIG_MFD_TI_AM335X_TSCADC is not set
# CONFIG_MFD_TI_LMU is not set
# CONFIG_MFD_TQMX86 is not set
# CONFIG_MFD_VX855 is not set
# CONFIG_MFD_WL1273_CORE is not set
# CONFIG_MICREL_PHY is not set
# CONFIG_MICROCHIP_PHY is not set
# CONFIG_MICROCHIP_T1_PHY is not set
# CONFIG_MICROSEMI_PHY is not set
CONFIG_MII=m
# CONFIG_MISC_ALCOR_PCI is not set
# CONFIG_MISC_RTSX is not set
# CONFIG_MISC_RTSX_PCI is not set
# CONFIG_MSPRO_BLOCK is not set
# CONFIG_MS_BLOCK is not set
# CONFIG_MTD is not set
# CONFIG_MUX_MMIO is not set
# CONFIG_NATIONAL_PHY is not set
# CONFIG_NET_DSA is not set
# CONFIG_NET_PTP_CLASSIFY is not set
# CONFIG_NET_SWITCHDEV is not set
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_NET_VENDOR_ADAPTEC is not set
# CONFIG_NET_VENDOR_AGERE is not set
# CONFIG_NET_VENDOR_ALACRITECH is not set
# CONFIG_NET_VENDOR_ALTEON is not set
# CONFIG_NET_VENDOR_AMAZON is not set
# CONFIG_NET_VENDOR_AMD is not set
# CONFIG_NET_VENDOR_AQUANTIA is not set
# CONFIG_NET_VENDOR_ARC is not set
# CONFIG_NET_VENDOR_ATHEROS is not set
# CONFIG_NET_VENDOR_BROADCOM is not set
# CONFIG_NET_VENDOR_BROCADE is not set
# CONFIG_NET_VENDOR_CADENCE is not set
# CONFIG_NET_VENDOR_CAVIUM is not set
# CONFIG_NET_VENDOR_CHELSIO is not set
# CONFIG_NET_VENDOR_CISCO is not set
# CONFIG_NET_VENDOR_CORTINA is not set
# CONFIG_NET_VENDOR_DEC is not set
# CONFIG_NET_VENDOR_DLINK is not set
# CONFIG_NET_VENDOR_EMULEX is not set
# CONFIG_NET_VENDOR_EZCHIP is not set
# CONFIG_NET_VENDOR_HUAWEI is not set
# CONFIG_NET_VENDOR_INTEL is not set
# CONFIG_NET_VENDOR_MARVELL is not set
# CONFIG_NET_VENDOR_MELLANOX is not set
# CONFIG_NET_VENDOR_MICREL is not set
# CONFIG_NET_VENDOR_MICROSEMI is not set
# CONFIG_NET_VENDOR_MYRI is not set
# CONFIG_NET_VENDOR_NATSEMI is not set
# CONFIG_NET_VENDOR_NETERION is not set
# CONFIG_NET_VENDOR_NETRONOME is not set
# CONFIG_NET_VENDOR_NI is not set
# CONFIG_NET_VENDOR_NVIDIA is not set
# CONFIG_NET_VENDOR_OKI is not set
# CONFIG_NET_VENDOR_PACKET_ENGINES is not set
# CONFIG_NET_VENDOR_QLOGIC is not set
# CONFIG_NET_VENDOR_QUALCOMM is not set
# CONFIG_NET_VENDOR_RDC is not set
# CONFIG_NET_VENDOR_REALTEK is not set
# CONFIG_NET_VENDOR_RENESAS is not set
# CONFIG_NET_VENDOR_ROCKER is not set
# CONFIG_NET_VENDOR_SAMSUNG is not set
# CONFIG_NET_VENDOR_SEEQ is not set
# CONFIG_NET_VENDOR_SILAN is not set
# CONFIG_NET_VENDOR_SIS is not set
# CONFIG_NET_VENDOR_SMSC is not set
# CONFIG_NET_VENDOR_SOCIONEXT is not set
# CONFIG_NET_VENDOR_SOLARFLARE is not set
# CONFIG_NET_VENDOR_STMICRO is not set
# CONFIG_NET_VENDOR_SUN is not set
# CONFIG_NET_VENDOR_SYNOPSYS is not set
# CONFIG_NET_VENDOR_TEHUTI is not set
# CONFIG_NET_VENDOR_TI is not set
# CONFIG_NET_VENDOR_TOSHIBA is not set
# CONFIG_NET_VENDOR_VIA is not set
# CONFIG_NET_VENDOR_WIZNET is not set
# CONFIG_NET_VENDOR_XILINX is not set
# CONFIG_NEW_LEDS is not set
# CONFIG_NFC is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_CODEPAGE_437 is not set
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_ISO8859_1 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_MAC_CELTIC is not set
# CONFIG_NLS_MAC_CENTEURO is not set
# CONFIG_NLS_MAC_CROATIAN is not set
# CONFIG_NLS_MAC_CYRILLIC is not set
# CONFIG_NLS_MAC_GAELIC is not set
# CONFIG_NLS_MAC_GREEK is not set
# CONFIG_NLS_MAC_ICELAND is not set
# CONFIG_NLS_MAC_INUIT is not set
# CONFIG_NLS_MAC_ROMAN is not set
# CONFIG_NLS_MAC_ROMANIAN is not set
# CONFIG_NLS_MAC_TURKISH is not set
# CONFIG_PARPORT is not set
# CONFIG_PCIE_XILINX is not set
# CONFIG_PHANTOM is not set
# CONFIG_PHY_CADENCE_DPHY is not set
# CONFIG_PHY_CADENCE_SIERRA is not set
# CONFIG_PHY_FSL_IMX8MQ_USB is not set
# CONFIG_PHY_MIXEL_MIPI_DPHY is not set
# CONFIG_PINCTRL is not set
# CONFIG_PLDMFW is not set
# CONFIG_POWER_SUPPLY is not set
# CONFIG_PPC_MAPLE is not set
# CONFIG_PPC_PMAC is not set
# CONFIG_PPC_POWERNV is not set
# CONFIG_PPC_PS3 is not set
# CONFIG_PPS_CLIENT_GPIO is not set
# CONFIG_PPS_CLIENT_LDISC is not set
# CONFIG_PTP_1588_CLOCK is not set
# CONFIG_PWM is not set
# CONFIG_QSEMI_PHY is not set
# CONFIG_RAPIDIO is not set
# CONFIG_REALTEK_PHY is not set
# CONFIG_REGULATOR is not set
# CONFIG_RENESAS_PHY is not set
# CONFIG_RFKILL is not set
# CONFIG_ROCKCHIP_PHY is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_RTC_DRV_ABB5ZES3 is not set
# CONFIG_RTC_DRV_ABEOZ9 is not set
# CONFIG_RTC_DRV_ABX80X is not set
# CONFIG_RTC_DRV_CADENCE is not set
# CONFIG_RTC_DRV_DS1307 is not set
# CONFIG_RTC_DRV_DS1374 is not set
# CONFIG_RTC_DRV_DS1672 is not set
# CONFIG_RTC_DRV_DS1742 is not set
# CONFIG_RTC_DRV_DS3232 is not set
# CONFIG_RTC_DRV_FM3130 is not set
# CONFIG_RTC_DRV_HYM8563 is not set
# CONFIG_RTC_DRV_ISL1208 is not set
# CONFIG_RTC_DRV_M41T80 is not set
# CONFIG_RTC_DRV_MAX6900 is not set
# CONFIG_RTC_DRV_PCF2127 is not set
# CONFIG_RTC_DRV_PCF85063 is not set
# CONFIG_RTC_DRV_PCF8523 is not set
# CONFIG_RTC_DRV_PCF85363 is not set
# CONFIG_RTC_DRV_PCF8563 is not set
# CONFIG_RTC_DRV_PCF8583 is not set
# CONFIG_RTC_DRV_RS5C372 is not set
# CONFIG_RTC_DRV_RV3028 is not set
# CONFIG_RTC_DRV_RV8803 is not set
# CONFIG_RTC_DRV_RX8010 is not set
# CONFIG_RTC_DRV_S35390A is not set
# CONFIG_RTC_DRV_SD3078 is not set
# CONFIG_RTC_DRV_X1205 is not set
CONFIG_RTC_I2C_AND_SPI=m
# CONFIG_RTS5208 is not set
# CONFIG_SCSI_3W_SAS is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC94XX is not set
# CONFIG_SCSI_AM53C974 is not set
# CONFIG_SCSI_ARCMSR is not set
# CONFIG_SCSI_BFA_FC is not set
# CONFIG_SCSI_BNX2X_FCOE is not set
# CONFIG_SCSI_BNX2_ISCSI is not set
# CONFIG_SCSI_CHELSIO_FCOE is not set
# CONFIG_SCSI_CXGB3_ISCSI is not set
# CONFIG_SCSI_CXGB4_ISCSI is not set
# CONFIG_SCSI_ESAS2R is not set
# CONFIG_SCSI_FDOMAIN_PCI is not set
# CONFIG_SCSI_LPFC is not set
# CONFIG_SCSI_MPT2SAS is not set
# CONFIG_SCSI_MPT3SAS is not set
# CONFIG_SCSI_MVSAS is not set
# CONFIG_SCSI_MVUMI is not set
# CONFIG_SCSI_MYRB is not set
# CONFIG_SCSI_PM8001 is not set
# CONFIG_SCSI_PMCRAID is not set
# CONFIG_SCSI_QLA_FC is not set
# CONFIG_SCSI_QLA_ISCSI is not set
# CONFIG_SCSI_SMARTPQI is not set
# CONFIG_SCSI_SNIC is not set
# CONFIG_SCSI_STEX is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_UFSHCD is not set
# CONFIG_SCSI_WD719X is not set
# CONFIG_SENSORS_APDS990X is not set
# CONFIG_SENSORS_BH1770 is not set
# CONFIG_SENSORS_TSL2550 is not set
# CONFIG_SERIAL_8250_DW is not set
# CONFIG_SERIAL_8250_EXAR is not set
# CONFIG_SERIAL_8250_FINTEK is not set
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
# CONFIG_SERIAL_ALTERA_UART is not set
# CONFIG_SERIAL_ICOM is not set
# CONFIG_SERIAL_JSM is not set
# CONFIG_SERIAL_RP2 is not set
# CONFIG_SERIAL_SC16IS7XX_I2C is not set
# CONFIG_SERIAL_XILINX_PS_UART is not set
# CONFIG_SERIO is not set
# CONFIG_SMSC_PHY is not set
# CONFIG_SOUND is not set
# CONFIG_SPI is not set
# CONFIG_SPMI is not set
# CONFIG_SSB is not set
# CONFIG_STAGING_MEDIA is not set
# CONFIG_STE10XP is not set
# CONFIG_TCG_ATMEL is not set
# CONFIG_TCG_TIS is not set
# CONFIG_TCG_TIS_I2C_ATMEL is not set
# CONFIG_TCG_TIS_I2C_INFINEON is not set
# CONFIG_TCG_TIS_I2C_NUVOTON is not set
# CONFIG_TCG_TIS_ST33ZP24_I2C is not set
# CONFIG_TERANETICS_PHY is not set
# CONFIG_TIFM_CORE is not set
# CONFIG_TPS6507X is not set
# CONFIG_USB_SUPPORT is not set
# CONFIG_VGASTATE is not set
# CONFIG_VITESSE_PHY is not set
# CONFIG_VT is not set
# CONFIG_W1 is not set
# CONFIG_WIMAX is not set
# CONFIG_WIRELESS is not set
# CONFIG_WLAN is not set
# CONFIG_XILLYBUS is not set
# CONFIG_XIL_AXIS_FIFO is not set
# CONFIG_ZIIRAVE_WATCHDOG is not set
CONFIG_MODULES=y
CONFIG_MODULE_SIG=y
# CONFIG_SUSE_KERNEL_SUPPORTED is not set

Re: linux-next failing build due to missing cubictcp_state symbol

[Michal Suchánek]

[-- Attachment #1: Type: text/plain, Size: 1769 bytes --]

On Mon, Apr 26, 2021 at 01:32:15PM +0200, Michal Suchánek wrote:
> On Sun, Apr 25, 2021 at 01:15:45PM +0200, Michal Suchánek wrote:
> > On Fri, Apr 23, 2021 at 07:55:28PM +0200, Michal Suchánek wrote:
> > > On Fri, Apr 23, 2021 at 07:41:29AM -0700, Yonghong Song wrote:
> > > > 
> > > > 
> > > > On 4/23/21 6:05 AM, Michal Suchánek wrote:
> > > > > Hello,
> > > > > 
> > > > > I see this build error in linux-next (config attached).
> > > > > 
> > > > > [ 4939s]   LD      vmlinux
> > > > > [ 4959s]   BTFIDS  vmlinux
> > > > > [ 4959s] FAILED unresolved symbol cubictcp_state
> > > > > [ 4960s] make[1]: ***
> > > > > [/home/abuild/rpmbuild/BUILD/kernel-vanilla-5.12~rc8.next.20210422/linux-5.12-rc8-next-20210422/Makefile:1277:
> > > > > vmlinux] Error 255
> > > > > [ 4960s] make: *** [../Makefile:222: __sub-make] Error 2
> > > > 
> > > > Looks like you have DYNAMIC_FTRACE config option enabled already.
> > > > Could you try a later version of pahole?
> > > 
> > > Is this requireent new?
> > > 
> > > I have pahole 1.20, and master does build without problems.
> > > 
> > > If newer version is needed can a check be added?
> > 
> > With dwarves 1.21 some architectures are fixed and some report other
> > missing symbol. Definitely an improvenent.
> > 
> > I see some new type support was added so it makes sense if that type is
> > used the new dwarves are needed.
> 
> Ok, here is the current failure with dwarves 1.21 on 5.12:
> 
> [ 2548s]   LD      vmlinux
> [ 2557s]   BTFIDS  vmlinux
> [ 2557s] FAILED unresolved symbol vfs_truncate
> [ 2558s] make[1]: ***
> [/home/abuild/rpmbuild/BUILD/kernel-kvmsmall-5.12.0/linux-5.12/Makefile:1213:
> vmlinux] Error 255
> 
> Any idea where this one is coming from?
Attaching a complete config
> 
> Thanks
> 
> Michal

[-- Attachment #2: vanilla --]
[-- Type: text/plain, Size: 68 bytes --]

CONFIG_LOCALVERSION="-vanilla"
CONFIG_MODULES=y
CONFIG_MODULE_SIG=y

Re: linux-next failing build due to missing cubictcp_state symbol

[Yonghong Song]

On 4/26/21 5:14 AM, Michal Suchánek wrote:
> On Mon, Apr 26, 2021 at 02:12:20PM +0200, Michal Suchánek wrote:
>> On Mon, Apr 26, 2021 at 01:32:15PM +0200, Michal Suchánek wrote:
>>> On Sun, Apr 25, 2021 at 01:15:45PM +0200, Michal Suchánek wrote:
>>>> On Fri, Apr 23, 2021 at 07:55:28PM +0200, Michal Suchánek wrote:
>>>>> On Fri, Apr 23, 2021 at 07:41:29AM -0700, Yonghong Song wrote:
>>>>>>
>>>>>>
>>>>>> On 4/23/21 6:05 AM, Michal Suchánek wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> I see this build error in linux-next (config attached).
>>>>>>>
>>>>>>> [ 4939s]   LD      vmlinux
>>>>>>> [ 4959s]   BTFIDS  vmlinux
>>>>>>> [ 4959s] FAILED unresolved symbol cubictcp_state
>>>>>>> [ 4960s] make[1]: ***
>>>>>>> [/home/abuild/rpmbuild/BUILD/kernel-vanilla-5.12~rc8.next.20210422/linux-5.12-rc8-next-20210422/Makefile:1277:
>>>>>>> vmlinux] Error 255
>>>>>>> [ 4960s] make: *** [../Makefile:222: __sub-make] Error 2
>>>>>>
>>>>>> Looks like you have DYNAMIC_FTRACE config option enabled already.
>>>>>> Could you try a later version of pahole?
>>>>>
>>>>> Is this requireent new?
>>>>>
>>>>> I have pahole 1.20, and master does build without problems.
>>>>>
>>>>> If newer version is needed can a check be added?
>>>>
>>>> With dwarves 1.21 some architectures are fixed and some report other
>>>> missing symbol. Definitely an improvenent.
>>>>
>>>> I see some new type support was added so it makes sense if that type is
>>>> used the new dwarves are needed.
>>>
>>> Ok, here is the current failure with dwarves 1.21 on 5.12:
>>>
>>> [ 2548s]   LD      vmlinux
>>> [ 2557s]   BTFIDS  vmlinux
>>> [ 2557s] FAILED unresolved symbol vfs_truncate
>>> [ 2558s] make[1]: ***
>>> [/home/abuild/rpmbuild/BUILD/kernel-kvmsmall-5.12.0/linux-5.12/Makefile:1213:
>>> vmlinux] Error 255

This is PPC64, from attached config:
   CONFIG_PPC64=y
I don't have environment to cross-compile for PPC64.
Jiri, could you take a look? Thanks!

>>>
>>> Any idea where this one is coming from?
>> Attaching a complete config
>>>
>>> Thanks
>>>
>>> Michal

Re: linux-next failing build due to missing cubictcp_state symbol

[Jiri Olsa]

On Mon, Apr 26, 2021 at 08:41:49AM -0700, Yonghong Song wrote:
> 
> 
> On 4/26/21 5:14 AM, Michal Suchánek wrote:
> > On Mon, Apr 26, 2021 at 02:12:20PM +0200, Michal Suchánek wrote:
> > > On Mon, Apr 26, 2021 at 01:32:15PM +0200, Michal Suchánek wrote:
> > > > On Sun, Apr 25, 2021 at 01:15:45PM +0200, Michal Suchánek wrote:
> > > > > On Fri, Apr 23, 2021 at 07:55:28PM +0200, Michal Suchánek wrote:
> > > > > > On Fri, Apr 23, 2021 at 07:41:29AM -0700, Yonghong Song wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > On 4/23/21 6:05 AM, Michal Suchánek wrote:
> > > > > > > > Hello,
> > > > > > > > 
> > > > > > > > I see this build error in linux-next (config attached).
> > > > > > > > 
> > > > > > > > [ 4939s]   LD      vmlinux
> > > > > > > > [ 4959s]   BTFIDS  vmlinux
> > > > > > > > [ 4959s] FAILED unresolved symbol cubictcp_state
> > > > > > > > [ 4960s] make[1]: ***
> > > > > > > > [/home/abuild/rpmbuild/BUILD/kernel-vanilla-5.12~rc8.next.20210422/linux-5.12-rc8-next-20210422/Makefile:1277:
> > > > > > > > vmlinux] Error 255
> > > > > > > > [ 4960s] make: *** [../Makefile:222: __sub-make] Error 2

this one was reported by Jesper and was fixed by upgrading pahole
that contains the new function generation fixes (v1.19)

> > > > > > > 
> > > > > > > Looks like you have DYNAMIC_FTRACE config option enabled already.
> > > > > > > Could you try a later version of pahole?
> > > > > > 
> > > > > > Is this requireent new?
> > > > > > 
> > > > > > I have pahole 1.20, and master does build without problems.
> > > > > > 
> > > > > > If newer version is needed can a check be added?
> > > > > 
> > > > > With dwarves 1.21 some architectures are fixed and some report other
> > > > > missing symbol. Definitely an improvenent.
> > > > > 
> > > > > I see some new type support was added so it makes sense if that type is
> > > > > used the new dwarves are needed.
> > > > 
> > > > Ok, here is the current failure with dwarves 1.21 on 5.12:
> > > > 
> > > > [ 2548s]   LD      vmlinux
> > > > [ 2557s]   BTFIDS  vmlinux
> > > > [ 2557s] FAILED unresolved symbol vfs_truncate
> > > > [ 2558s] make[1]: ***
> > > > [/home/abuild/rpmbuild/BUILD/kernel-kvmsmall-5.12.0/linux-5.12/Makefile:1213:
> > > > vmlinux] Error 255
> 
> This is PPC64, from attached config:
>   CONFIG_PPC64=y
> I don't have environment to cross-compile for PPC64.
> Jiri, could you take a look? Thanks!

looks like vfs_truncate did not get into BTF data,
I'll try to reproduce

jirka

Re: linux-next failing build due to missing cubictcp_state symbol

[Jiri Olsa]

On Mon, Apr 26, 2021 at 06:03:19PM +0200, Jiri Olsa wrote:
> On Mon, Apr 26, 2021 at 08:41:49AM -0700, Yonghong Song wrote:
> > 
> > 
> > On 4/26/21 5:14 AM, Michal Suchánek wrote:
> > > On Mon, Apr 26, 2021 at 02:12:20PM +0200, Michal Suchánek wrote:
> > > > On Mon, Apr 26, 2021 at 01:32:15PM +0200, Michal Suchánek wrote:
> > > > > On Sun, Apr 25, 2021 at 01:15:45PM +0200, Michal Suchánek wrote:
> > > > > > On Fri, Apr 23, 2021 at 07:55:28PM +0200, Michal Suchánek wrote:
> > > > > > > On Fri, Apr 23, 2021 at 07:41:29AM -0700, Yonghong Song wrote:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > On 4/23/21 6:05 AM, Michal Suchánek wrote:
> > > > > > > > > Hello,
> > > > > > > > > 
> > > > > > > > > I see this build error in linux-next (config attached).
> > > > > > > > > 
> > > > > > > > > [ 4939s]   LD      vmlinux
> > > > > > > > > [ 4959s]   BTFIDS  vmlinux
> > > > > > > > > [ 4959s] FAILED unresolved symbol cubictcp_state
> > > > > > > > > [ 4960s] make[1]: ***
> > > > > > > > > [/home/abuild/rpmbuild/BUILD/kernel-vanilla-5.12~rc8.next.20210422/linux-5.12-rc8-next-20210422/Makefile:1277:
> > > > > > > > > vmlinux] Error 255
> > > > > > > > > [ 4960s] make: *** [../Makefile:222: __sub-make] Error 2
> 
> this one was reported by Jesper and was fixed by upgrading pahole
> that contains the new function generation fixes (v1.19)
> 
> > > > > > > > 
> > > > > > > > Looks like you have DYNAMIC_FTRACE config option enabled already.
> > > > > > > > Could you try a later version of pahole?
> > > > > > > 
> > > > > > > Is this requireent new?
> > > > > > > 
> > > > > > > I have pahole 1.20, and master does build without problems.
> > > > > > > 
> > > > > > > If newer version is needed can a check be added?
> > > > > > 
> > > > > > With dwarves 1.21 some architectures are fixed and some report other
> > > > > > missing symbol. Definitely an improvenent.
> > > > > > 
> > > > > > I see some new type support was added so it makes sense if that type is
> > > > > > used the new dwarves are needed.
> > > > > 
> > > > > Ok, here is the current failure with dwarves 1.21 on 5.12:
> > > > > 
> > > > > [ 2548s]   LD      vmlinux
> > > > > [ 2557s]   BTFIDS  vmlinux
> > > > > [ 2557s] FAILED unresolved symbol vfs_truncate
> > > > > [ 2558s] make[1]: ***
> > > > > [/home/abuild/rpmbuild/BUILD/kernel-kvmsmall-5.12.0/linux-5.12/Makefile:1213:
> > > > > vmlinux] Error 255
> > 
> > This is PPC64, from attached config:
> >   CONFIG_PPC64=y
> > I don't have environment to cross-compile for PPC64.
> > Jiri, could you take a look? Thanks!
> 
> looks like vfs_truncate did not get into BTF data,
> I'll try to reproduce

I can't reproduce the problem, in both cross build and native ppc,
but the .config attached does not see complete, could you pelase
resend?

thanks,
jirka

Re: linux-next failing build due to missing cubictcp_state symbol

[Michal Suchánek]

On Mon, Apr 26, 2021 at 09:16:36PM +0200, Jiri Olsa wrote:
> On Mon, Apr 26, 2021 at 06:03:19PM +0200, Jiri Olsa wrote:
> > On Mon, Apr 26, 2021 at 08:41:49AM -0700, Yonghong Song wrote:
> > > 
> > > 
> > > On 4/26/21 5:14 AM, Michal Suchánek wrote:
> > > > On Mon, Apr 26, 2021 at 02:12:20PM +0200, Michal Suchánek wrote:
> > > > > On Mon, Apr 26, 2021 at 01:32:15PM +0200, Michal Suchánek wrote:
> > > > > > On Sun, Apr 25, 2021 at 01:15:45PM +0200, Michal Suchánek wrote:
> > > > > > > On Fri, Apr 23, 2021 at 07:55:28PM +0200, Michal Suchánek wrote:
> > > > > > > > On Fri, Apr 23, 2021 at 07:41:29AM -0700, Yonghong Song wrote:
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > On 4/23/21 6:05 AM, Michal Suchánek wrote:
> > > > > > > > > > Hello,
> > > > > > > > > > 
> > > > > > > > > > I see this build error in linux-next (config attached).
> > > > > > > > > > 
> > > > > > > > > > [ 4939s]   LD      vmlinux
> > > > > > > > > > [ 4959s]   BTFIDS  vmlinux
> > > > > > > > > > [ 4959s] FAILED unresolved symbol cubictcp_state
> > > > > > > > > > [ 4960s] make[1]: ***
> > > > > > > > > > [/home/abuild/rpmbuild/BUILD/kernel-vanilla-5.12~rc8.next.20210422/linux-5.12-rc8-next-20210422/Makefile:1277:
> > > > > > > > > > vmlinux] Error 255
> > > > > > > > > > [ 4960s] make: *** [../Makefile:222: __sub-make] Error 2
> > 
> > this one was reported by Jesper and was fixed by upgrading pahole
> > that contains the new function generation fixes (v1.19)
> > 
> > > > > > > > > 
> > > > > > > > > Looks like you have DYNAMIC_FTRACE config option enabled already.
> > > > > > > > > Could you try a later version of pahole?
> > > > > > > > 
> > > > > > > > Is this requireent new?
> > > > > > > > 
> > > > > > > > I have pahole 1.20, and master does build without problems.
> > > > > > > > 
> > > > > > > > If newer version is needed can a check be added?
> > > > > > > 
> > > > > > > With dwarves 1.21 some architectures are fixed and some report other
> > > > > > > missing symbol. Definitely an improvenent.
> > > > > > > 
> > > > > > > I see some new type support was added so it makes sense if that type is
> > > > > > > used the new dwarves are needed.
> > > > > > 
> > > > > > Ok, here is the current failure with dwarves 1.21 on 5.12:
> > > > > > 
> > > > > > [ 2548s]   LD      vmlinux
> > > > > > [ 2557s]   BTFIDS  vmlinux
> > > > > > [ 2557s] FAILED unresolved symbol vfs_truncate
> > > > > > [ 2558s] make[1]: ***
> > > > > > [/home/abuild/rpmbuild/BUILD/kernel-kvmsmall-5.12.0/linux-5.12/Makefile:1213:
> > > > > > vmlinux] Error 255
> > > 
> > > This is PPC64, from attached config:
> > >   CONFIG_PPC64=y
> > > I don't have environment to cross-compile for PPC64.
> > > Jiri, could you take a look? Thanks!
> > 
> > looks like vfs_truncate did not get into BTF data,
> > I'll try to reproduce
> 
> I can't reproduce the problem, in both cross build and native ppc,
> but the .config attached does not see complete, could you pelase
> resend?

I can't reproduce outside of the build service either. There is probably
some other tool missing that is commonly available and there is no check
for it.

Thanks

Michal

Re: linux-next failing build due to missing cubictcp_state symbol

[Michal Suchánek]

CC another Jiri

On Tue, Apr 27, 2021 at 02:12:37PM +0200, Michal Suchánek wrote:
> On Mon, Apr 26, 2021 at 09:16:36PM +0200, Jiri Olsa wrote:
> > On Mon, Apr 26, 2021 at 06:03:19PM +0200, Jiri Olsa wrote:
> > > On Mon, Apr 26, 2021 at 08:41:49AM -0700, Yonghong Song wrote:
> > > > 
> > > > 
> > > > On 4/26/21 5:14 AM, Michal Suchánek wrote:
> > > > > On Mon, Apr 26, 2021 at 02:12:20PM +0200, Michal Suchánek wrote:
> > > > > > On Mon, Apr 26, 2021 at 01:32:15PM +0200, Michal Suchánek wrote:
> > > > > > > On Sun, Apr 25, 2021 at 01:15:45PM +0200, Michal Suchánek wrote:
> > > > > > > > On Fri, Apr 23, 2021 at 07:55:28PM +0200, Michal Suchánek wrote:
> > > > > > > > > On Fri, Apr 23, 2021 at 07:41:29AM -0700, Yonghong Song wrote:
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > On 4/23/21 6:05 AM, Michal Suchánek wrote:
> > > > > > > > > > > Hello,
> > > > > > > > > > > 
> > > > > > > > > > > I see this build error in linux-next (config attached).
> > > > > > > > > > > 
> > > > > > > > > > > [ 4939s]   LD      vmlinux
> > > > > > > > > > > [ 4959s]   BTFIDS  vmlinux
> > > > > > > > > > > [ 4959s] FAILED unresolved symbol cubictcp_state
> > > > > > > > > > > [ 4960s] make[1]: ***
> > > > > > > > > > > [/home/abuild/rpmbuild/BUILD/kernel-vanilla-5.12~rc8.next.20210422/linux-5.12-rc8-next-20210422/Makefile:1277:
> > > > > > > > > > > vmlinux] Error 255
> > > > > > > > > > > [ 4960s] make: *** [../Makefile:222: __sub-make] Error 2
> > > 
> > > this one was reported by Jesper and was fixed by upgrading pahole
> > > that contains the new function generation fixes (v1.19)
> > > 
> > > > > > > > > > 
> > > > > > > > > > Looks like you have DYNAMIC_FTRACE config option enabled already.
> > > > > > > > > > Could you try a later version of pahole?
> > > > > > > > > 
> > > > > > > > > Is this requireent new?
> > > > > > > > > 
> > > > > > > > > I have pahole 1.20, and master does build without problems.
> > > > > > > > > 
> > > > > > > > > If newer version is needed can a check be added?
> > > > > > > > 
> > > > > > > > With dwarves 1.21 some architectures are fixed and some report other
> > > > > > > > missing symbol. Definitely an improvenent.
> > > > > > > > 
> > > > > > > > I see some new type support was added so it makes sense if that type is
> > > > > > > > used the new dwarves are needed.
> > > > > > > 
> > > > > > > Ok, here is the current failure with dwarves 1.21 on 5.12:
> > > > > > > 
> > > > > > > [ 2548s]   LD      vmlinux
> > > > > > > [ 2557s]   BTFIDS  vmlinux
> > > > > > > [ 2557s] FAILED unresolved symbol vfs_truncate
> > > > > > > [ 2558s] make[1]: ***
> > > > > > > [/home/abuild/rpmbuild/BUILD/kernel-kvmsmall-5.12.0/linux-5.12/Makefile:1213:
> > > > > > > vmlinux] Error 255
> > > > 
> > > > This is PPC64, from attached config:
> > > >   CONFIG_PPC64=y
> > > > I don't have environment to cross-compile for PPC64.
> > > > Jiri, could you take a look? Thanks!
> > > 
> > > looks like vfs_truncate did not get into BTF data,
> > > I'll try to reproduce
> > 
> > I can't reproduce the problem, in both cross build and native ppc,
> > but the .config attached does not see complete, could you pelase
> > resend?
> 
> I can't reproduce outside of the build service either. There is probably
> some other tool missing that is commonly available and there is no check
> for it.

Looks like pahole or some library are miscompiled on ppc64.

Using the native ppc64 tools is broken and using cross-tools works.

Thanks

Michal

Re: linux-next failing build due to missing cubictcp_state symbol

[Jiri Slaby]

On 30. 04. 21, 19:47, Michal Suchánek wrote:
> CC another Jiri
> 
> On Tue, Apr 27, 2021 at 02:12:37PM +0200, Michal Suchánek wrote:
>> On Mon, Apr 26, 2021 at 09:16:36PM +0200, Jiri Olsa wrote:
>>> On Mon, Apr 26, 2021 at 06:03:19PM +0200, Jiri Olsa wrote:
>>>> On Mon, Apr 26, 2021 at 08:41:49AM -0700, Yonghong Song wrote:
>>>>>
>>>>>
>>>>> On 4/26/21 5:14 AM, Michal Suchánek wrote:
>>>>>> On Mon, Apr 26, 2021 at 02:12:20PM +0200, Michal Suchánek wrote:
>>>>>>> On Mon, Apr 26, 2021 at 01:32:15PM +0200, Michal Suchánek wrote:
>>>>>>>> On Sun, Apr 25, 2021 at 01:15:45PM +0200, Michal Suchánek wrote:
>>>>>>>>> On Fri, Apr 23, 2021 at 07:55:28PM +0200, Michal Suchánek wrote:
>>>>>>>>>> On Fri, Apr 23, 2021 at 07:41:29AM -0700, Yonghong Song wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 4/23/21 6:05 AM, Michal Suchánek wrote:
>>>>>>>>>>>> Hello,
>>>>>>>>>>>>
>>>>>>>>>>>> I see this build error in linux-next (config attached).
>>>>>>>>>>>>
>>>>>>>>>>>> [ 4939s]   LD      vmlinux
>>>>>>>>>>>> [ 4959s]   BTFIDS  vmlinux
>>>>>>>>>>>> [ 4959s] FAILED unresolved symbol cubictcp_state
>>>>>>>>>>>> [ 4960s] make[1]: ***
>>>>>>>>>>>> [/home/abuild/rpmbuild/BUILD/kernel-vanilla-5.12~rc8.next.20210422/linux-5.12-rc8-next-20210422/Makefile:1277:
>>>>>>>>>>>> vmlinux] Error 255
>>>>>>>>>>>> [ 4960s] make: *** [../Makefile:222: __sub-make] Error 2
>>>>
>>>> this one was reported by Jesper and was fixed by upgrading pahole
>>>> that contains the new function generation fixes (v1.19)
>>>>
>>>>>>>>>>>
>>>>>>>>>>> Looks like you have DYNAMIC_FTRACE config option enabled already.
>>>>>>>>>>> Could you try a later version of pahole?
>>>>>>>>>>
>>>>>>>>>> Is this requireent new?
>>>>>>>>>>
>>>>>>>>>> I have pahole 1.20, and master does build without problems.
>>>>>>>>>>
>>>>>>>>>> If newer version is needed can a check be added?
>>>>>>>>>
>>>>>>>>> With dwarves 1.21 some architectures are fixed and some report other
>>>>>>>>> missing symbol. Definitely an improvenent.
>>>>>>>>>
>>>>>>>>> I see some new type support was added so it makes sense if that type is
>>>>>>>>> used the new dwarves are needed.
>>>>>>>>
>>>>>>>> Ok, here is the current failure with dwarves 1.21 on 5.12:
>>>>>>>>
>>>>>>>> [ 2548s]   LD      vmlinux
>>>>>>>> [ 2557s]   BTFIDS  vmlinux
>>>>>>>> [ 2557s] FAILED unresolved symbol vfs_truncate
>>>>>>>> [ 2558s] make[1]: ***
>>>>>>>> [/home/abuild/rpmbuild/BUILD/kernel-kvmsmall-5.12.0/linux-5.12/Makefile:1213:
>>>>>>>> vmlinux] Error 255
>>>>>
>>>>> This is PPC64, from attached config:
>>>>>    CONFIG_PPC64=y
>>>>> I don't have environment to cross-compile for PPC64.
>>>>> Jiri, could you take a look? Thanks!
>>>>
>>>> looks like vfs_truncate did not get into BTF data,
>>>> I'll try to reproduce

_None_ of the functions are generated by pahole -J from debuginfo on 
ppc64. debuginfo appears to be correct. Neither pahole -J fs/open.o 
works correctly. collect_functions in dwarves seems to be defunct on 
ppc64... "functions" array is bogus (so find_function -- the bsearch -- 
fails). I didn't have more time to continue debugging. This is where I 
stopped.

regards,
-- 
js
suse labs

Re: linux-next failing build due to missing cubictcp_state symbol

[Michal Suchánek]

On Sat, May 01, 2021 at 08:45:50AM +0200, Jiri Slaby wrote:
> On 30. 04. 21, 19:47, Michal Suchánek wrote:
> > CC another Jiri
> > 
> > On Tue, Apr 27, 2021 at 02:12:37PM +0200, Michal Suchánek wrote:
> > > On Mon, Apr 26, 2021 at 09:16:36PM +0200, Jiri Olsa wrote:
> > > > On Mon, Apr 26, 2021 at 06:03:19PM +0200, Jiri Olsa wrote:
> > > > > On Mon, Apr 26, 2021 at 08:41:49AM -0700, Yonghong Song wrote:
> > > > > > 
> > > > > > 
> > > > > > On 4/26/21 5:14 AM, Michal Suchánek wrote:
> > > > > > > On Mon, Apr 26, 2021 at 02:12:20PM +0200, Michal Suchánek wrote:
> > > > > > > > On Mon, Apr 26, 2021 at 01:32:15PM +0200, Michal Suchánek wrote:
> > > > > > > > > On Sun, Apr 25, 2021 at 01:15:45PM +0200, Michal Suchánek wrote:
> > > > > > > > > > On Fri, Apr 23, 2021 at 07:55:28PM +0200, Michal Suchánek wrote:
> > > > > > > > > > > On Fri, Apr 23, 2021 at 07:41:29AM -0700, Yonghong Song wrote:
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > On 4/23/21 6:05 AM, Michal Suchánek wrote:
> > > > > > > > > > > > > Hello,
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I see this build error in linux-next (config attached).
> > > > > > > > > > > > > 
> > > > > > > > > > > > > [ 4939s]   LD      vmlinux
> > > > > > > > > > > > > [ 4959s]   BTFIDS  vmlinux
> > > > > > > > > > > > > [ 4959s] FAILED unresolved symbol cubictcp_state
> > > > > > > > > > > > > [ 4960s] make[1]: ***
> > > > > > > > > > > > > [/home/abuild/rpmbuild/BUILD/kernel-vanilla-5.12~rc8.next.20210422/linux-5.12-rc8-next-20210422/Makefile:1277:
> > > > > > > > > > > > > vmlinux] Error 255
> > > > > > > > > > > > > [ 4960s] make: *** [../Makefile:222: __sub-make] Error 2
> > > > > 
> > > > > this one was reported by Jesper and was fixed by upgrading pahole
> > > > > that contains the new function generation fixes (v1.19)
> > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > Looks like you have DYNAMIC_FTRACE config option enabled already.
> > > > > > > > > > > > Could you try a later version of pahole?
> > > > > > > > > > > 
> > > > > > > > > > > Is this requireent new?
> > > > > > > > > > > 
> > > > > > > > > > > I have pahole 1.20, and master does build without problems.
> > > > > > > > > > > 
> > > > > > > > > > > If newer version is needed can a check be added?
> > > > > > > > > > 
> > > > > > > > > > With dwarves 1.21 some architectures are fixed and some report other
> > > > > > > > > > missing symbol. Definitely an improvenent.
> > > > > > > > > > 
> > > > > > > > > > I see some new type support was added so it makes sense if that type is
> > > > > > > > > > used the new dwarves are needed.
> > > > > > > > > 
> > > > > > > > > Ok, here is the current failure with dwarves 1.21 on 5.12:
> > > > > > > > > 
> > > > > > > > > [ 2548s]   LD      vmlinux
> > > > > > > > > [ 2557s]   BTFIDS  vmlinux
> > > > > > > > > [ 2557s] FAILED unresolved symbol vfs_truncate
> > > > > > > > > [ 2558s] make[1]: ***
> > > > > > > > > [/home/abuild/rpmbuild/BUILD/kernel-kvmsmall-5.12.0/linux-5.12/Makefile:1213:
> > > > > > > > > vmlinux] Error 255
> > > > > > 
> > > > > > This is PPC64, from attached config:
> > > > > >    CONFIG_PPC64=y
> > > > > > I don't have environment to cross-compile for PPC64.
> > > > > > Jiri, could you take a look? Thanks!
> > > > > 
> > > > > looks like vfs_truncate did not get into BTF data,
> > > > > I'll try to reproduce
> 
> _None_ of the functions are generated by pahole -J from debuginfo on ppc64.
> debuginfo appears to be correct. Neither pahole -J fs/open.o works
> correctly. collect_functions in dwarves seems to be defunct on ppc64...
> "functions" array is bogus (so find_function -- the bsearch -- fails). I
> didn't have more time to continue debugging. This is where I stopped.

A workaround is to apply
https://lore.kernel.org/linuxppc-dev/20200428112517.1402927-1-npiggin@gmail.com/
and build as ABI v2

Thanks

Michal

Re: linux-next failing build due to missing cubictcp_state symbol

[Jiri Slaby]

On 01. 05. 21, 8:45, Jiri Slaby wrote:
> On 30. 04. 21, 19:47, Michal Suchánek wrote:
>> CC another Jiri
>>
>> On Tue, Apr 27, 2021 at 02:12:37PM +0200, Michal Suchánek wrote:
>>> On Mon, Apr 26, 2021 at 09:16:36PM +0200, Jiri Olsa wrote:
>>>> On Mon, Apr 26, 2021 at 06:03:19PM +0200, Jiri Olsa wrote:
>>>>> On Mon, Apr 26, 2021 at 08:41:49AM -0700, Yonghong Song wrote:
>>>>>>
>>>>>>
>>>>>> On 4/26/21 5:14 AM, Michal Suchánek wrote:
>>>>>>> On Mon, Apr 26, 2021 at 02:12:20PM +0200, Michal Suchánek wrote:
>>>>>>>> On Mon, Apr 26, 2021 at 01:32:15PM +0200, Michal Suchánek wrote:
>>>>>>>>> On Sun, Apr 25, 2021 at 01:15:45PM +0200, Michal Suchánek wrote:
>>>>>>>>>> On Fri, Apr 23, 2021 at 07:55:28PM +0200, Michal Suchánek wrote:
>>>>>>>>>>> On Fri, Apr 23, 2021 at 07:41:29AM -0700, Yonghong Song wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 4/23/21 6:05 AM, Michal Suchánek wrote:
>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I see this build error in linux-next (config attached).
>>>>>>>>>>>>>
>>>>>>>>>>>>> [ 4939s]   LD      vmlinux
>>>>>>>>>>>>> [ 4959s]   BTFIDS  vmlinux
>>>>>>>>>>>>> [ 4959s] FAILED unresolved symbol cubictcp_state
>>>>>>>>>>>>> [ 4960s] make[1]: ***
>>>>>>>>>>>>> [/home/abuild/rpmbuild/BUILD/kernel-vanilla-5.12~rc8.next.20210422/linux-5.12-rc8-next-20210422/Makefile:1277: 
>>>>>>>>>>>>>
>>>>>>>>>>>>> vmlinux] Error 255
>>>>>>>>>>>>> [ 4960s] make: *** [../Makefile:222: __sub-make] Error 2
>>>>>
>>>>> this one was reported by Jesper and was fixed by upgrading pahole
>>>>> that contains the new function generation fixes (v1.19)
>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Looks like you have DYNAMIC_FTRACE config option enabled 
>>>>>>>>>>>> already.
>>>>>>>>>>>> Could you try a later version of pahole?
>>>>>>>>>>>
>>>>>>>>>>> Is this requireent new?
>>>>>>>>>>>
>>>>>>>>>>> I have pahole 1.20, and master does build without problems.
>>>>>>>>>>>
>>>>>>>>>>> If newer version is needed can a check be added?
>>>>>>>>>>
>>>>>>>>>> With dwarves 1.21 some architectures are fixed and some report 
>>>>>>>>>> other
>>>>>>>>>> missing symbol. Definitely an improvenent.
>>>>>>>>>>
>>>>>>>>>> I see some new type support was added so it makes sense if 
>>>>>>>>>> that type is
>>>>>>>>>> used the new dwarves are needed.
>>>>>>>>>
>>>>>>>>> Ok, here is the current failure with dwarves 1.21 on 5.12:
>>>>>>>>>
>>>>>>>>> [ 2548s]   LD      vmlinux
>>>>>>>>> [ 2557s]   BTFIDS  vmlinux
>>>>>>>>> [ 2557s] FAILED unresolved symbol vfs_truncate
>>>>>>>>> [ 2558s] make[1]: ***
>>>>>>>>> [/home/abuild/rpmbuild/BUILD/kernel-kvmsmall-5.12.0/linux-5.12/Makefile:1213: 
>>>>>>>>>
>>>>>>>>> vmlinux] Error 255
>>>>>>
>>>>>> This is PPC64, from attached config:
>>>>>>    CONFIG_PPC64=y
>>>>>> I don't have environment to cross-compile for PPC64.
>>>>>> Jiri, could you take a look? Thanks!
>>>>>
>>>>> looks like vfs_truncate did not get into BTF data,
>>>>> I'll try to reproduce
> 
> _None_ of the functions are generated by pahole -J from debuginfo on 
> ppc64. debuginfo appears to be correct. Neither pahole -J fs/open.o 
> works correctly. collect_functions in dwarves seems to be defunct on 
> ppc64... "functions" array is bogus (so find_function -- the bsearch -- 
> fails).

It's not that bogus. I forgot an asterisk:
> #0  find_function (btfe=0x100269f80, name=0x10024631c "stream_open") at /usr/src/debug/dwarves-1.21-1.1.ppc64/btf_encoder.c:350
> (gdb) p (*functions)@84
> $5 = {{name = 0x7ffff68e0922 ".__se_compat_sys_ftruncate", addr = 75232, size = 72, sh_addr = 65536, generated = false}, {
>     name = 0x7ffff68e019e ".__se_compat_sys_open", addr = 80592, size = 216, sh_addr = 65536, generated = false}, {
>     name = 0x7ffff68e0076 ".__se_compat_sys_openat", addr = 80816, size = 232, sh_addr = 65536, generated = false}, {
>     name = 0x7ffff68e0908 ".__se_compat_sys_truncate", addr = 74304, size = 100, sh_addr = 65536, generated = false}, {
...
>     name = 0x7ffff68e0808 ".stream_open", addr = 65824, size = 72, sh_addr = 65536, generated = false}, {
...
>     name = 0x7ffff68e0751 ".vfs_truncate", addr = 73392, size = 544, sh_addr = 65536, generated = false}}

The dot makes the difference, of course. The question is why is it 
there? I keep looking into it. Only if someone has an immediate idea...

thanks,
-- 
js
suse labs

Re: linux-next failing build due to missing cubictcp_state symbol

[Michal Suchánek]

On Mon, May 03, 2021 at 08:11:50AM +0200, Jiri Slaby wrote:
> On 01. 05. 21, 8:45, Jiri Slaby wrote:
> > On 30. 04. 21, 19:47, Michal Suchánek wrote:
> > > CC another Jiri
> > > 
> > > On Tue, Apr 27, 2021 at 02:12:37PM +0200, Michal Suchánek wrote:
> > > > On Mon, Apr 26, 2021 at 09:16:36PM +0200, Jiri Olsa wrote:
> > > > > On Mon, Apr 26, 2021 at 06:03:19PM +0200, Jiri Olsa wrote:
> > > > > > On Mon, Apr 26, 2021 at 08:41:49AM -0700, Yonghong Song wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > On 4/26/21 5:14 AM, Michal Suchánek wrote:
> > > > > > > > On Mon, Apr 26, 2021 at 02:12:20PM +0200, Michal Suchánek wrote:
> > > > > > > > > On Mon, Apr 26, 2021 at 01:32:15PM +0200, Michal Suchánek wrote:
> > > > > > > > > > On Sun, Apr 25, 2021 at 01:15:45PM +0200, Michal Suchánek wrote:
> > > > > > > > > > > On Fri, Apr 23, 2021 at 07:55:28PM +0200, Michal Suchánek wrote:
> > > > > > > > > > > > On Fri, Apr 23, 2021 at 07:41:29AM -0700, Yonghong Song wrote:
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > On 4/23/21 6:05 AM, Michal Suchánek wrote:
> > > > > > > > > > > > > > Hello,
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > I see this build error in linux-next (config attached).
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > [ 4939s]   LD      vmlinux
> > > > > > > > > > > > > > [ 4959s]   BTFIDS  vmlinux
> > > > > > > > > > > > > > [ 4959s] FAILED unresolved symbol cubictcp_state
> > > > > > > > > > > > > > [ 4960s] make[1]: ***
> > > > > > > > > > > > > > [/home/abuild/rpmbuild/BUILD/kernel-vanilla-5.12~rc8.next.20210422/linux-5.12-rc8-next-20210422/Makefile:1277:
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > vmlinux] Error 255
> > > > > > > > > > > > > > [ 4960s] make: *** [../Makefile:222: __sub-make] Error 2
> > > > > > 
> > > > > > this one was reported by Jesper and was fixed by upgrading pahole
> > > > > > that contains the new function generation fixes (v1.19)
> > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Looks like you have
> > > > > > > > > > > > > DYNAMIC_FTRACE config option
> > > > > > > > > > > > > enabled already.
> > > > > > > > > > > > > Could you try a later version of pahole?
> > > > > > > > > > > > 
> > > > > > > > > > > > Is this requireent new?
> > > > > > > > > > > > 
> > > > > > > > > > > > I have pahole 1.20, and master does build without problems.
> > > > > > > > > > > > 
> > > > > > > > > > > > If newer version is needed can a check be added?
> > > > > > > > > > > 
> > > > > > > > > > > With dwarves 1.21 some architectures
> > > > > > > > > > > are fixed and some report other
> > > > > > > > > > > missing symbol. Definitely an improvenent.
> > > > > > > > > > > 
> > > > > > > > > > > I see some new type support was
> > > > > > > > > > > added so it makes sense if that type
> > > > > > > > > > > is
> > > > > > > > > > > used the new dwarves are needed.
> > > > > > > > > > 
> > > > > > > > > > Ok, here is the current failure with dwarves 1.21 on 5.12:
> > > > > > > > > > 
> > > > > > > > > > [ 2548s]   LD      vmlinux
> > > > > > > > > > [ 2557s]   BTFIDS  vmlinux
> > > > > > > > > > [ 2557s] FAILED unresolved symbol vfs_truncate
> > > > > > > > > > [ 2558s] make[1]: ***
> > > > > > > > > > [/home/abuild/rpmbuild/BUILD/kernel-kvmsmall-5.12.0/linux-5.12/Makefile:1213:
> > > > > > > > > > 
> > > > > > > > > > vmlinux] Error 255
> > > > > > > 
> > > > > > > This is PPC64, from attached config:
> > > > > > >    CONFIG_PPC64=y
> > > > > > > I don't have environment to cross-compile for PPC64.
> > > > > > > Jiri, could you take a look? Thanks!
> > > > > > 
> > > > > > looks like vfs_truncate did not get into BTF data,
> > > > > > I'll try to reproduce
> > 
> > _None_ of the functions are generated by pahole -J from debuginfo on
> > ppc64. debuginfo appears to be correct. Neither pahole -J fs/open.o
> > works correctly. collect_functions in dwarves seems to be defunct on
> > ppc64... "functions" array is bogus (so find_function -- the bsearch --
> > fails).
> 
> It's not that bogus. I forgot an asterisk:
> > #0  find_function (btfe=0x100269f80, name=0x10024631c "stream_open") at /usr/src/debug/dwarves-1.21-1.1.ppc64/btf_encoder.c:350
> > (gdb) p (*functions)@84
> > $5 = {{name = 0x7ffff68e0922 ".__se_compat_sys_ftruncate", addr = 75232, size = 72, sh_addr = 65536, generated = false}, {
> >     name = 0x7ffff68e019e ".__se_compat_sys_open", addr = 80592, size = 216, sh_addr = 65536, generated = false}, {
> >     name = 0x7ffff68e0076 ".__se_compat_sys_openat", addr = 80816, size = 232, sh_addr = 65536, generated = false}, {
> >     name = 0x7ffff68e0908 ".__se_compat_sys_truncate", addr = 74304, size = 100, sh_addr = 65536, generated = false}, {
> ...
> >     name = 0x7ffff68e0808 ".stream_open", addr = 65824, size = 72, sh_addr = 65536, generated = false}, {
> ...
> >     name = 0x7ffff68e0751 ".vfs_truncate", addr = 73392, size = 544, sh_addr = 65536, generated = false}}
> 
> The dot makes the difference, of course. The question is why is it there? I
> keep looking into it. Only if someone has an immediate idea...

Thanks for looking into it. That's probably expected. I vaguely recall
there is a mocro for adding a dot to assembly symbols depending on the
ABI.

Thanks

Michal

Re: linux-next failing build due to missing cubictcp_state symbol

[Jiri Slaby]

On 03. 05. 21, 8:11, Jiri Slaby wrote:
>>>>>> looks like vfs_truncate did not get into BTF data,
>>>>>> I'll try to reproduce
>>
>> _None_ of the functions are generated by pahole -J from debuginfo on 
>> ppc64. debuginfo appears to be correct. Neither pahole -J fs/open.o 
>> works correctly. collect_functions in dwarves seems to be defunct on 
>> ppc64... "functions" array is bogus (so find_function -- the bsearch 
>> -- fails).
> 
> It's not that bogus. I forgot an asterisk:
>> #0  find_function (btfe=0x100269f80, name=0x10024631c "stream_open") 
>> at /usr/src/debug/dwarves-1.21-1.1.ppc64/btf_encoder.c:350
>> (gdb) p (*functions)@84
>> $5 = {{name = 0x7ffff68e0922 ".__se_compat_sys_ftruncate", addr = 
>> 75232, size = 72, sh_addr = 65536, generated = false}, {
>>     name = 0x7ffff68e019e ".__se_compat_sys_open", addr = 80592, size 
>> = 216, sh_addr = 65536, generated = false}, {
>>     name = 0x7ffff68e0076 ".__se_compat_sys_openat", addr = 80816, 
>> size = 232, sh_addr = 65536, generated = false}, {
>>     name = 0x7ffff68e0908 ".__se_compat_sys_truncate", addr = 74304, 
>> size = 100, sh_addr = 65536, generated = false}, {
> ...
>>     name = 0x7ffff68e0808 ".stream_open", addr = 65824, size = 72, 
>> sh_addr = 65536, generated = false}, {
> ...
>>     name = 0x7ffff68e0751 ".vfs_truncate", addr = 73392, size = 544, 
>> sh_addr = 65536, generated = false}}
> 
> The dot makes the difference, of course. The question is why is it 
> there? I keep looking into it. Only if someone has an immediate idea...

Well, .vfs_truncate is in .text (and contains an ._mcount call). And 
vfs_truncate is in .opd (w/o an ._mcount call). Since setup_functions 
excludes all functions without the ._mcount call, is_ftrace_func later 
returns false for such functions and they are filtered before the BTF 
processing.

Technically, get_vmlinux_addrs looks at a list of functions between 
__start_mcount_loc and __stop_mcount_loc and considers only the listed.

I don't know what the correct fix is (exclude .opd functions from the 
filter?). Neither why cross compiler doesn't fail, nor why ebi v2 avoids 
this too.

regards,
-- 
js

Re: linux-next failing build due to missing cubictcp_state symbol

[Jiri Slaby]

[-- Attachment #1: Type: text/plain, Size: 2383 bytes --]

CCing pahole people.

On 03. 05. 21, 9:59, Jiri Slaby wrote:
> On 03. 05. 21, 8:11, Jiri Slaby wrote:
>>>>>>> looks like vfs_truncate did not get into BTF data,
>>>>>>> I'll try to reproduce
>>>
>>> _None_ of the functions are generated by pahole -J from debuginfo on 
>>> ppc64. debuginfo appears to be correct. Neither pahole -J fs/open.o 
>>> works correctly. collect_functions in dwarves seems to be defunct on 
>>> ppc64... "functions" array is bogus (so find_function -- the bsearch 
>>> -- fails).
>>
>> It's not that bogus. I forgot an asterisk:
>>> #0  find_function (btfe=0x100269f80, name=0x10024631c "stream_open") 
>>> at /usr/src/debug/dwarves-1.21-1.1.ppc64/btf_encoder.c:350
>>> (gdb) p (*functions)@84
>>> $5 = {{name = 0x7ffff68e0922 ".__se_compat_sys_ftruncate", addr = 
>>> 75232, size = 72, sh_addr = 65536, generated = false}, {
>>>     name = 0x7ffff68e019e ".__se_compat_sys_open", addr = 80592, size 
>>> = 216, sh_addr = 65536, generated = false}, {
>>>     name = 0x7ffff68e0076 ".__se_compat_sys_openat", addr = 80816, 
>>> size = 232, sh_addr = 65536, generated = false}, {
>>>     name = 0x7ffff68e0908 ".__se_compat_sys_truncate", addr = 74304, 
>>> size = 100, sh_addr = 65536, generated = false}, {
>> ...
>>>     name = 0x7ffff68e0808 ".stream_open", addr = 65824, size = 72, 
>>> sh_addr = 65536, generated = false}, {
>> ...
>>>     name = 0x7ffff68e0751 ".vfs_truncate", addr = 73392, size = 544, 
>>> sh_addr = 65536, generated = false}}
>>
>> The dot makes the difference, of course. The question is why is it 
>> there? I keep looking into it. Only if someone has an immediate idea...
> 
> Well, .vfs_truncate is in .text (and contains an ._mcount call). And 
> vfs_truncate is in .opd (w/o an ._mcount call). Since setup_functions 
> excludes all functions without the ._mcount call, is_ftrace_func later 
> returns false for such functions and they are filtered before the BTF 
> processing.
> 
> Technically, get_vmlinux_addrs looks at a list of functions between 
> __start_mcount_loc and __stop_mcount_loc and considers only the listed.
> 
> I don't know what the correct fix is (exclude .opd functions from the 
> filter?). Neither why cross compiler doesn't fail, nor why ebi v2 avoids 
> this too.

Attaching a patch for pahole which fixes the issue, but I have no idea 
whether it is the right fix at all.

> regards,-- 
js
suse labs

[-- Attachment #2: ppc64-opd-fix.patch --]
[-- Type: text/x-patch, Size: 1686 bytes --]

From: Jiri Slaby <jslaby@suse.cz>
Subject: ppc64: .opd section fix
Patch-mainline: submitted 2021/05/03

Functions in the .opd section should be considered valid too. Otherwise,
pahole cannot produce a .BTF section from vmlinux and kernel build
fails on ppc64.
---
 btf_encoder.c |   18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)

--- a/btf_encoder.c
+++ b/btf_encoder.c
@@ -31,6 +31,8 @@ struct funcs_layout {
 	unsigned long mcount_start;
 	unsigned long mcount_stop;
 	unsigned long mcount_sec_idx;
+	unsigned long opd_start;
+	unsigned long opd_stop;
 };
 
 struct elf_function {
@@ -271,11 +273,24 @@ static int is_ftrace_func(struct elf_fun
 	return start <= addrs[r] && addrs[r] < end;
 }
 
+static int is_opd_func(struct elf_function *func, struct funcs_layout *fl)
+{
+	return fl->opd_start <= func->addr && func->addr < fl->opd_stop;
+}
+
 static int setup_functions(struct btf_elf *btfe, struct funcs_layout *fl)
 {
 	__u64 *addrs, count, i;
 	int functions_valid = 0;
 	bool kmod = false;
+	GElf_Shdr shdr;
+	Elf_Scn *sec;
+
+	sec = elf_section_by_name(btfe->elf, &btfe->ehdr, &shdr, ".opd", NULL);
+	if (sec) {
+		fl->opd_start = shdr.sh_addr;
+		fl->opd_stop = shdr.sh_addr + shdr.sh_size;
+	}
 
 	/*
 	 * Check if we are processing vmlinux image and
@@ -322,7 +337,8 @@ static int setup_functions(struct btf_el
 			func->addr += func->sh_addr;
 
 		/* Make sure function is within ftrace addresses. */
-		if (is_ftrace_func(func, addrs, count)) {
+		if (is_opd_func(func, fl) ||
+				is_ftrace_func(func, addrs, count)) {
 			/*
 			 * We iterate over sorted array, so we can easily skip
 			 * not valid item and move following valid field into

Re: linux-next failing build due to missing cubictcp_state symbol

[Jiri Olsa]

On Mon, May 03, 2021 at 10:59:44AM +0200, Jiri Slaby wrote:
> CCing pahole people.
> 
> On 03. 05. 21, 9:59, Jiri Slaby wrote:
> > On 03. 05. 21, 8:11, Jiri Slaby wrote:
> > > > > > > > looks like vfs_truncate did not get into BTF data,
> > > > > > > > I'll try to reproduce
> > > > 
> > > > _None_ of the functions are generated by pahole -J from
> > > > debuginfo on ppc64. debuginfo appears to be correct. Neither
> > > > pahole -J fs/open.o works correctly. collect_functions in
> > > > dwarves seems to be defunct on ppc64... "functions" array is
> > > > bogus (so find_function -- the bsearch -- fails).
> > > 
> > > It's not that bogus. I forgot an asterisk:
> > > > #0  find_function (btfe=0x100269f80, name=0x10024631c
> > > > "stream_open") at
> > > > /usr/src/debug/dwarves-1.21-1.1.ppc64/btf_encoder.c:350
> > > > (gdb) p (*functions)@84
> > > > $5 = {{name = 0x7ffff68e0922 ".__se_compat_sys_ftruncate", addr
> > > > = 75232, size = 72, sh_addr = 65536, generated = false}, {
> > > >     name = 0x7ffff68e019e ".__se_compat_sys_open", addr = 80592,
> > > > size = 216, sh_addr = 65536, generated = false}, {
> > > >     name = 0x7ffff68e0076 ".__se_compat_sys_openat", addr =
> > > > 80816, size = 232, sh_addr = 65536, generated = false}, {
> > > >     name = 0x7ffff68e0908 ".__se_compat_sys_truncate", addr =
> > > > 74304, size = 100, sh_addr = 65536, generated = false}, {
> > > ...
> > > >     name = 0x7ffff68e0808 ".stream_open", addr = 65824, size =
> > > > 72, sh_addr = 65536, generated = false}, {
> > > ...
> > > >     name = 0x7ffff68e0751 ".vfs_truncate", addr = 73392, size =
> > > > 544, sh_addr = 65536, generated = false}}
> > > 
> > > The dot makes the difference, of course. The question is why is it
> > > there? I keep looking into it. Only if someone has an immediate
> > > idea...
> > 
> > Well, .vfs_truncate is in .text (and contains an ._mcount call). And
> > vfs_truncate is in .opd (w/o an ._mcount call). Since setup_functions
> > excludes all functions without the ._mcount call, is_ftrace_func later
> > returns false for such functions and they are filtered before the BTF
> > processing.
> > 
> > Technically, get_vmlinux_addrs looks at a list of functions between
> > __start_mcount_loc and __stop_mcount_loc and considers only the listed.
> > 
> > I don't know what the correct fix is (exclude .opd functions from the
> > filter?). Neither why cross compiler doesn't fail, nor why ebi v2 avoids
> > this too.
> 
> Attaching a patch for pahole which fixes the issue, but I have no idea
> whether it is the right fix at all.

hi,
we're considering to disable ftrace filter completely,
I guess that would solve this issue for ppc as well

  https://lore.kernel.org/bpf/20210501001653.x3b4rk4vk4iqv3n7@kafai-mbp.dhcp.thefacebook.com/

jirka

> 
> > regards,--
> js
> suse labs

> From: Jiri Slaby <jslaby@suse.cz>
> Subject: ppc64: .opd section fix
> Patch-mainline: submitted 2021/05/03
> 
> Functions in the .opd section should be considered valid too. Otherwise,
> pahole cannot produce a .BTF section from vmlinux and kernel build
> fails on ppc64.
> ---
>  btf_encoder.c |   18 +++++++++++++++++-
>  1 file changed, 17 insertions(+), 1 deletion(-)
> 
> --- a/btf_encoder.c
> +++ b/btf_encoder.c
> @@ -31,6 +31,8 @@ struct funcs_layout {
>  	unsigned long mcount_start;
>  	unsigned long mcount_stop;
>  	unsigned long mcount_sec_idx;
> +	unsigned long opd_start;
> +	unsigned long opd_stop;
>  };
>  
>  struct elf_function {
> @@ -271,11 +273,24 @@ static int is_ftrace_func(struct elf_fun
>  	return start <= addrs[r] && addrs[r] < end;
>  }
>  
> +static int is_opd_func(struct elf_function *func, struct funcs_layout *fl)
> +{
> +	return fl->opd_start <= func->addr && func->addr < fl->opd_stop;
> +}
> +
>  static int setup_functions(struct btf_elf *btfe, struct funcs_layout *fl)
>  {
>  	__u64 *addrs, count, i;
>  	int functions_valid = 0;
>  	bool kmod = false;
> +	GElf_Shdr shdr;
> +	Elf_Scn *sec;
> +
> +	sec = elf_section_by_name(btfe->elf, &btfe->ehdr, &shdr, ".opd", NULL);
> +	if (sec) {
> +		fl->opd_start = shdr.sh_addr;
> +		fl->opd_stop = shdr.sh_addr + shdr.sh_size;
> +	}
>  
>  	/*
>  	 * Check if we are processing vmlinux image and
> @@ -322,7 +337,8 @@ static int setup_functions(struct btf_el
>  			func->addr += func->sh_addr;
>  
>  		/* Make sure function is within ftrace addresses. */
> -		if (is_ftrace_func(func, addrs, count)) {
> +		if (is_opd_func(func, fl) ||
> +				is_ftrace_func(func, addrs, count)) {
>  			/*
>  			 * We iterate over sorted array, so we can easily skip
>  			 * not valid item and move following valid field into

Re: linux-next failing build due to missing cubictcp_state symbol

[Michal Suchánek]

On Mon, May 03, 2021 at 12:08:02PM +0200, Jiri Olsa wrote:
> On Mon, May 03, 2021 at 10:59:44AM +0200, Jiri Slaby wrote:
> > CCing pahole people.
> > 
> > On 03. 05. 21, 9:59, Jiri Slaby wrote:
> > > On 03. 05. 21, 8:11, Jiri Slaby wrote:
> > > > > > > > > looks like vfs_truncate did not get into BTF data,
> > > > > > > > > I'll try to reproduce
> > > > > 
> > > > > _None_ of the functions are generated by pahole -J from
> > > > > debuginfo on ppc64. debuginfo appears to be correct. Neither
> > > > > pahole -J fs/open.o works correctly. collect_functions in
> > > > > dwarves seems to be defunct on ppc64... "functions" array is
> > > > > bogus (so find_function -- the bsearch -- fails).
> > > > 
> > > > It's not that bogus. I forgot an asterisk:
> > > > > #0  find_function (btfe=0x100269f80, name=0x10024631c
> > > > > "stream_open") at
> > > > > /usr/src/debug/dwarves-1.21-1.1.ppc64/btf_encoder.c:350
> > > > > (gdb) p (*functions)@84
> > > > > $5 = {{name = 0x7ffff68e0922 ".__se_compat_sys_ftruncate", addr
> > > > > = 75232, size = 72, sh_addr = 65536, generated = false}, {
> > > > >     name = 0x7ffff68e019e ".__se_compat_sys_open", addr = 80592,
> > > > > size = 216, sh_addr = 65536, generated = false}, {
> > > > >     name = 0x7ffff68e0076 ".__se_compat_sys_openat", addr =
> > > > > 80816, size = 232, sh_addr = 65536, generated = false}, {
> > > > >     name = 0x7ffff68e0908 ".__se_compat_sys_truncate", addr =
> > > > > 74304, size = 100, sh_addr = 65536, generated = false}, {
> > > > ...
> > > > >     name = 0x7ffff68e0808 ".stream_open", addr = 65824, size =
> > > > > 72, sh_addr = 65536, generated = false}, {
> > > > ...
> > > > >     name = 0x7ffff68e0751 ".vfs_truncate", addr = 73392, size =
> > > > > 544, sh_addr = 65536, generated = false}}
> > > > 
> > > > The dot makes the difference, of course. The question is why is it
> > > > there? I keep looking into it. Only if someone has an immediate
> > > > idea...
> > > 
> > > Well, .vfs_truncate is in .text (and contains an ._mcount call). And
> > > vfs_truncate is in .opd (w/o an ._mcount call). Since setup_functions
> > > excludes all functions without the ._mcount call, is_ftrace_func later
> > > returns false for such functions and they are filtered before the BTF
> > > processing.
> > > 
> > > Technically, get_vmlinux_addrs looks at a list of functions between
> > > __start_mcount_loc and __stop_mcount_loc and considers only the listed.
> > > 
> > > I don't know what the correct fix is (exclude .opd functions from the
> > > filter?). Neither why cross compiler doesn't fail, nor why ebi v2 avoids
> > > this too.
> > 
> > Attaching a patch for pahole which fixes the issue, but I have no idea
> > whether it is the right fix at all.
> 
> hi,
> we're considering to disable ftrace filter completely,
> I guess that would solve this issue for ppc as well
> 
>   https://lore.kernel.org/bpf/20210501001653.x3b4rk4vk4iqv3n7@kafai-mbp.dhcp.thefacebook.com/
> 
Just disabling the ftrace filter in pahole does not seem to fix it.

Is there some other place where it should be disabled?

Thanks

Michal

Re: linux-next failing build due to missing cubictcp_state symbol

[Michal Suchánek]

On Mon, May 03, 2021 at 06:46:56PM +0200, Michal Suchánek wrote:
> On Mon, May 03, 2021 at 12:08:02PM +0200, Jiri Olsa wrote:
> > On Mon, May 03, 2021 at 10:59:44AM +0200, Jiri Slaby wrote:
> > > CCing pahole people.
> > > 
> > > On 03. 05. 21, 9:59, Jiri Slaby wrote:
> > > > On 03. 05. 21, 8:11, Jiri Slaby wrote:
> > > > > > > > > > looks like vfs_truncate did not get into BTF data,
> > > > > > > > > > I'll try to reproduce
> > > > > > 
> > > > > > _None_ of the functions are generated by pahole -J from
> > > > > > debuginfo on ppc64. debuginfo appears to be correct. Neither
> > > > > > pahole -J fs/open.o works correctly. collect_functions in
> > > > > > dwarves seems to be defunct on ppc64... "functions" array is
> > > > > > bogus (so find_function -- the bsearch -- fails).
> > > > > 
> > > > > It's not that bogus. I forgot an asterisk:
> > > > > > #0  find_function (btfe=0x100269f80, name=0x10024631c
> > > > > > "stream_open") at
> > > > > > /usr/src/debug/dwarves-1.21-1.1.ppc64/btf_encoder.c:350
> > > > > > (gdb) p (*functions)@84
> > > > > > $5 = {{name = 0x7ffff68e0922 ".__se_compat_sys_ftruncate", addr
> > > > > > = 75232, size = 72, sh_addr = 65536, generated = false}, {
> > > > > >     name = 0x7ffff68e019e ".__se_compat_sys_open", addr = 80592,
> > > > > > size = 216, sh_addr = 65536, generated = false}, {
> > > > > >     name = 0x7ffff68e0076 ".__se_compat_sys_openat", addr =
> > > > > > 80816, size = 232, sh_addr = 65536, generated = false}, {
> > > > > >     name = 0x7ffff68e0908 ".__se_compat_sys_truncate", addr =
> > > > > > 74304, size = 100, sh_addr = 65536, generated = false}, {
> > > > > ...
> > > > > >     name = 0x7ffff68e0808 ".stream_open", addr = 65824, size =
> > > > > > 72, sh_addr = 65536, generated = false}, {
> > > > > ...
> > > > > >     name = 0x7ffff68e0751 ".vfs_truncate", addr = 73392, size =
> > > > > > 544, sh_addr = 65536, generated = false}}
> > > > > 
> > > > > The dot makes the difference, of course. The question is why is it
> > > > > there? I keep looking into it. Only if someone has an immediate
> > > > > idea...
> > > > 
> > > > Well, .vfs_truncate is in .text (and contains an ._mcount call). And
> > > > vfs_truncate is in .opd (w/o an ._mcount call). Since setup_functions
> > > > excludes all functions without the ._mcount call, is_ftrace_func later
> > > > returns false for such functions and they are filtered before the BTF
> > > > processing.
> > > > 
> > > > Technically, get_vmlinux_addrs looks at a list of functions between
> > > > __start_mcount_loc and __stop_mcount_loc and considers only the listed.
> > > > 
> > > > I don't know what the correct fix is (exclude .opd functions from the
> > > > filter?). Neither why cross compiler doesn't fail, nor why ebi v2 avoids
> > > > this too.
> > > 
> > > Attaching a patch for pahole which fixes the issue, but I have no idea
> > > whether it is the right fix at all.
> > 
> > hi,
> > we're considering to disable ftrace filter completely,
> > I guess that would solve this issue for ppc as well
> > 
> >   https://lore.kernel.org/bpf/20210501001653.x3b4rk4vk4iqv3n7@kafai-mbp.dhcp.thefacebook.com/
> > 
> Just disabling the ftrace filter in pahole does not seem to fix it.
> 
> Is there some other place where it should be disabled?

Nevermind, purging the system dwarves resolved the problem. Although
kbuild detects pahole as /usr/local/bin/pahole the system binaries or
libraries are still used for something.

Thanks

Michal

Re: linux-next failing build due to missing cubictcp_state symbol

[Jiri Slaby]

[-- Attachment #1: Type: text/plain, Size: 2829 bytes --]

On 03. 05. 21, 12:08, Jiri Olsa wrote:
> On Mon, May 03, 2021 at 10:59:44AM +0200, Jiri Slaby wrote:
>> CCing pahole people.
>>
>> On 03. 05. 21, 9:59, Jiri Slaby wrote:
>>> On 03. 05. 21, 8:11, Jiri Slaby wrote:
>>>>>>>>> looks like vfs_truncate did not get into BTF data,
>>>>>>>>> I'll try to reproduce
>>>>>
>>>>> _None_ of the functions are generated by pahole -J from
>>>>> debuginfo on ppc64. debuginfo appears to be correct. Neither
>>>>> pahole -J fs/open.o works correctly. collect_functions in
>>>>> dwarves seems to be defunct on ppc64... "functions" array is
>>>>> bogus (so find_function -- the bsearch -- fails).
>>>>
>>>> It's not that bogus. I forgot an asterisk:
>>>>> #0  find_function (btfe=0x100269f80, name=0x10024631c
>>>>> "stream_open") at
>>>>> /usr/src/debug/dwarves-1.21-1.1.ppc64/btf_encoder.c:350
>>>>> (gdb) p (*functions)@84
>>>>> $5 = {{name = 0x7ffff68e0922 ".__se_compat_sys_ftruncate", addr
>>>>> = 75232, size = 72, sh_addr = 65536, generated = false}, {
>>>>>      name = 0x7ffff68e019e ".__se_compat_sys_open", addr = 80592,
>>>>> size = 216, sh_addr = 65536, generated = false}, {
>>>>>      name = 0x7ffff68e0076 ".__se_compat_sys_openat", addr =
>>>>> 80816, size = 232, sh_addr = 65536, generated = false}, {
>>>>>      name = 0x7ffff68e0908 ".__se_compat_sys_truncate", addr =
>>>>> 74304, size = 100, sh_addr = 65536, generated = false}, {
>>>> ...
>>>>>      name = 0x7ffff68e0808 ".stream_open", addr = 65824, size =
>>>>> 72, sh_addr = 65536, generated = false}, {
>>>> ...
>>>>>      name = 0x7ffff68e0751 ".vfs_truncate", addr = 73392, size =
>>>>> 544, sh_addr = 65536, generated = false}}
>>>>
>>>> The dot makes the difference, of course. The question is why is it
>>>> there? I keep looking into it. Only if someone has an immediate
>>>> idea...
>>>
>>> Well, .vfs_truncate is in .text (and contains an ._mcount call). And
>>> vfs_truncate is in .opd (w/o an ._mcount call). Since setup_functions
>>> excludes all functions without the ._mcount call, is_ftrace_func later
>>> returns false for such functions and they are filtered before the BTF
>>> processing.
>>>
>>> Technically, get_vmlinux_addrs looks at a list of functions between
>>> __start_mcount_loc and __stop_mcount_loc and considers only the listed.
>>>
>>> I don't know what the correct fix is (exclude .opd functions from the
>>> filter?). Neither why cross compiler doesn't fail, nor why ebi v2 avoids
>>> this too.
>>
>> Attaching a patch for pahole which fixes the issue, but I have no idea
>> whether it is the right fix at all.
> 
> hi,
> we're considering to disable ftrace filter completely,
> I guess that would solve this issue for ppc as well
> 
>    https://lore.kernel.org/bpf/20210501001653.x3b4rk4vk4iqv3n7@kafai-mbp.dhcp.thefacebook.com/

Right, the attached patch fixes it for me too.

-- 
js

[-- Attachment #2: 0001-remove-ftrace-filter.patch --]
[-- Type: text/x-patch, Size: 9077 bytes --]

From b0128f1ec6a234c5b40c40d73d55708d34f1a428 Mon Sep 17 00:00:00 2001
From: Jiri Slaby <jslaby@suse.cz>
Date: Tue, 4 May 2021 08:09:50 +0200
Subject: [PATCH] remove ftrace filter

Functions in the .opd section on ppc64 are currently ignored as they
don't contain mcount calls -- they are excluded by the ftrace filter.
Therefore, pahole cannot produce a .BTF section from vmlinux and kernel
build fails on ppc64.

Remove the ftrace filter completely as was discussed:
 https://lore.kernel.org/bpf/20210501001653.x3b4rk4vk4iqv3n7@kafai-mbp.dhcp.thefacebook.com/
 https://lore.kernel.org/bpf/YI%2FLgjLxo9VCN%2Fd+@krava/
---
 btf_encoder.c | 272 +-------------------------------------------------
 1 file changed, 5 insertions(+), 267 deletions(-)

diff --git a/btf_encoder.c b/btf_encoder.c
index 80e896961d4e..ba83bb088efa 100644
--- a/btf_encoder.c
+++ b/btf_encoder.c
@@ -27,17 +27,8 @@
  */
 #define KSYM_NAME_LEN 128
 
-struct funcs_layout {
-	unsigned long mcount_start;
-	unsigned long mcount_stop;
-	unsigned long mcount_sec_idx;
-};
-
 struct elf_function {
 	const char	*name;
-	unsigned long	 addr;
-	unsigned long	 size;
-	unsigned long	 sh_addr;
 	bool		 generated;
 };
 
@@ -98,250 +89,11 @@ static int collect_function(struct btf_elf *btfe, GElf_Sym *sym,
 	}
 
 	functions[functions_cnt].name = name;
-	functions[functions_cnt].addr = elf_sym__value(sym);
-	functions[functions_cnt].size = elf_sym__size(sym);
-	functions[functions_cnt].sh_addr = sh.sh_addr;
 	functions[functions_cnt].generated = false;
 	functions_cnt++;
 	return 0;
 }
 
-static int addrs_cmp(const void *_a, const void *_b)
-{
-	const __u64 *a = _a;
-	const __u64 *b = _b;
-
-	if (*a == *b)
-		return 0;
-	return *a < *b ? -1 : 1;
-}
-
-static int get_vmlinux_addrs(struct btf_elf *btfe, struct funcs_layout *fl,
-			     __u64 **paddrs, __u64 *pcount)
-{
-	__u64 *addrs, count, offset;
-	unsigned int addr_size, i;
-	Elf_Data *data;
-	GElf_Shdr shdr;
-	Elf_Scn *sec;
-
-	/* Initialize for the sake of all error paths below. */
-	*paddrs = NULL;
-	*pcount = 0;
-
-	if (!fl->mcount_start || !fl->mcount_stop)
-		return 0;
-
-	/*
-	 * Find mcount addressed marked by __start_mcount_loc
-	 * and __stop_mcount_loc symbols and load them into
-	 * sorted array.
-	 */
-	sec = elf_getscn(btfe->elf, fl->mcount_sec_idx);
-	if (!sec || !gelf_getshdr(sec, &shdr)) {
-		fprintf(stderr, "Failed to get section(%lu) header.\n",
-			fl->mcount_sec_idx);
-		return -1;
-	}
-
-	/* Get address size from processed file's ELF class. */
-	addr_size = gelf_getclass(btfe->elf) == ELFCLASS32 ? 4 : 8;
-
-	offset = fl->mcount_start - shdr.sh_addr;
-	count  = (fl->mcount_stop - fl->mcount_start) / addr_size;
-
-	data = elf_getdata(sec, 0);
-	if (!data) {
-		fprintf(stderr, "Failed to get section(%lu) data.\n",
-			fl->mcount_sec_idx);
-		return -1;
-	}
-
-	addrs = malloc(count * sizeof(addrs[0]));
-	if (!addrs) {
-		fprintf(stderr, "Failed to allocate memory for ftrace addresses.\n");
-		return -1;
-	}
-
-	if (addr_size == sizeof(__u64)) {
-		memcpy(addrs, data->d_buf + offset, count * addr_size);
-	} else {
-		for (i = 0; i < count; i++)
-			addrs[i] = (__u64) *((__u32 *) (data->d_buf + offset + i * addr_size));
-	}
-
-	*paddrs = addrs;
-	*pcount = count;
-	return 0;
-}
-
-static int
-get_kmod_addrs(struct btf_elf *btfe, __u64 **paddrs, __u64 *pcount)
-{
-	__u64 *addrs, count;
-	unsigned int addr_size, i;
-	GElf_Shdr shdr_mcount;
-	Elf_Data *data;
-	Elf_Scn *sec;
-
-	/* Initialize for the sake of all error paths below. */
-	*paddrs = NULL;
-	*pcount = 0;
-
-	/* get __mcount_loc */
-	sec = elf_section_by_name(btfe->elf, &btfe->ehdr, &shdr_mcount,
-				  "__mcount_loc", NULL);
-	if (!sec) {
-		if (btf_elf__verbose) {
-			printf("%s: '%s' doesn't have __mcount_loc section\n", __func__,
-			       btfe->filename);
-		}
-		return 0;
-	}
-
-	data = elf_getdata(sec, NULL);
-	if (!data) {
-		fprintf(stderr, "Failed to data for __mcount_loc section.\n");
-		return -1;
-	}
-
-	/* Get address size from processed file's ELF class. */
-	addr_size = gelf_getclass(btfe->elf) == ELFCLASS32 ? 4 : 8;
-
-	count = data->d_size / addr_size;
-
-	addrs = malloc(count * sizeof(addrs[0]));
-	if (!addrs) {
-		fprintf(stderr, "Failed to allocate memory for ftrace addresses.\n");
-		return -1;
-	}
-
-	if (addr_size == sizeof(__u64)) {
-		memcpy(addrs, data->d_buf, count * addr_size);
-	} else {
-		for (i = 0; i < count; i++)
-			addrs[i] = (__u64) *((__u32 *) (data->d_buf + i * addr_size));
-	}
-
-	/*
-	 * We get Elf object from dwfl_module_getelf function,
-	 * which performs all possible relocations, including
-	 * __mcount_loc section.
-	 *
-	 * So addrs array now contains relocated values, which
-	 * we need take into account when we compare them to
-	 * functions values, see comment in setup_functions
-	 * function.
-	 */
-	*paddrs = addrs;
-	*pcount = count;
-	return 0;
-}
-
-static int is_ftrace_func(struct elf_function *func, __u64 *addrs, __u64 count)
-{
-	__u64 start = func->addr;
-	__u64 addr, end = func->addr + func->size;
-
-	/*
-	 * The invariant here is addr[r] that is the smallest address
-	 * that is >= than function start addr. Except the corner case
-	 * where there is no such r, but for that we have a final check
-	 * in the return.
-	 */
-	size_t l = 0, r = count - 1, m;
-
-	/* make sure we don't use invalid r */
-	if (count == 0)
-		return false;
-
-	while (l < r) {
-		m = l + (r - l) / 2;
-		addr = addrs[m];
-
-		if (addr >= start) {
-			/* we satisfy invariant, so tighten r */
-			r = m;
-		} else {
-			/* m is not good enough as l, maybe m + 1 will be */
-			l = m + 1;
-		}
-	}
-
-	return start <= addrs[r] && addrs[r] < end;
-}
-
-static int setup_functions(struct btf_elf *btfe, struct funcs_layout *fl)
-{
-	__u64 *addrs, count, i;
-	int functions_valid = 0;
-	bool kmod = false;
-
-	/*
-	 * Check if we are processing vmlinux image and
-	 * get mcount data if it's detected.
-	 */
-	if (get_vmlinux_addrs(btfe, fl, &addrs, &count))
-		return -1;
-
-	/*
-	 * Check if we are processing kernel module and
-	 * get mcount data if it's detected.
-	 */
-	if (!addrs) {
-		if (get_kmod_addrs(btfe, &addrs, &count))
-			return -1;
-		kmod = true;
-	}
-
-	if (!addrs) {
-		if (btf_elf__verbose)
-			printf("ftrace symbols not detected, falling back to DWARF data\n");
-		delete_functions();
-		return 0;
-	}
-
-	qsort(addrs, count, sizeof(addrs[0]), addrs_cmp);
-	qsort(functions, functions_cnt, sizeof(functions[0]), functions_cmp);
-
-	/*
-	 * Let's got through all collected functions and filter
-	 * out those that are not in ftrace.
-	 */
-	for (i = 0; i < functions_cnt; i++) {
-		struct elf_function *func = &functions[i];
-		/*
-		 * For vmlinux image both addrs[x] and functions[x]::addr
-		 * values are final address and are comparable.
-		 *
-		 * For kernel module addrs[x] is final address, but
-		 * functions[x]::addr is relative address within section
-		 * and needs to be relocated by adding sh_addr.
-		 */
-		if (kmod)
-			func->addr += func->sh_addr;
-
-		/* Make sure function is within ftrace addresses. */
-		if (is_ftrace_func(func, addrs, count)) {
-			/*
-			 * We iterate over sorted array, so we can easily skip
-			 * not valid item and move following valid field into
-			 * its place, and still keep the 'new' array sorted.
-			 */
-			if (i != functions_valid)
-				functions[functions_valid] = functions[i];
-			functions_valid++;
-		}
-	}
-
-	functions_cnt = functions_valid;
-	free(addrs);
-
-	if (btf_elf__verbose)
-		printf("Found %d functions!\n", functions_cnt);
-	return 0;
-}
-
 static struct elf_function *find_function(const struct btf_elf *btfe,
 					  const char *name)
 {
@@ -620,23 +372,8 @@ static int collect_percpu_var(struct btf_elf *btfe, GElf_Sym *sym,
 	return 0;
 }
 
-static void collect_symbol(GElf_Sym *sym, struct funcs_layout *fl,
-			   size_t sym_sec_idx)
-{
-	if (!fl->mcount_start &&
-	    !strcmp("__start_mcount_loc", elf_sym__name(sym, btfe->symtab))) {
-		fl->mcount_start = sym->st_value;
-		fl->mcount_sec_idx = sym_sec_idx;
-	}
-
-	if (!fl->mcount_stop &&
-	    !strcmp("__stop_mcount_loc", elf_sym__name(sym, btfe->symtab)))
-		fl->mcount_stop = sym->st_value;
-}
-
 static int collect_symbols(struct btf_elf *btfe, bool collect_percpu_vars)
 {
-	struct funcs_layout fl = { };
 	Elf32_Word sym_sec_idx;
 	uint32_t core_id;
 	GElf_Sym sym;
@@ -650,7 +387,6 @@ static int collect_symbols(struct btf_elf *btfe, bool collect_percpu_vars)
 			return -1;
 		if (collect_function(btfe, &sym, sym_sec_idx))
 			return -1;
-		collect_symbol(&sym, &fl, sym_sec_idx);
 	}
 
 	if (collect_percpu_vars) {
@@ -661,9 +397,11 @@ static int collect_symbols(struct btf_elf *btfe, bool collect_percpu_vars)
 			printf("Found %d per-CPU variables!\n", percpu_var_cnt);
 	}
 
-	if (functions_cnt && setup_functions(btfe, &fl)) {
-		fprintf(stderr, "Failed to filter DWARF functions\n");
-		return -1;
+	if (functions_cnt) {
+		qsort(functions, functions_cnt, sizeof(functions[0]), functions_cmp);
+
+		if (btf_elf__verbose)
+			printf("Found %d functions!\n", functions_cnt);
 	}
 
 	return 0;
-- 
2.31.1

Re: linux-next failing build due to missing cubictcp_state symbol

[Jiri Slaby]

On 05. 05. 21, 15:56, Michal Suchánek wrote:
> On Mon, Apr 26, 2021 at 09:16:36PM +0200, Jiri Olsa wrote:
>> On Mon, Apr 26, 2021 at 06:03:19PM +0200, Jiri Olsa wrote:
>>> On Mon, Apr 26, 2021 at 08:41:49AM -0700, Yonghong Song wrote:
>>>>
>>>>
>>>> On 4/26/21 5:14 AM, Michal Suchánek wrote:
>>>>> On Mon, Apr 26, 2021 at 02:12:20PM +0200, Michal Suchánek wrote:
>>>>>> On Mon, Apr 26, 2021 at 01:32:15PM +0200, Michal Suchánek wrote:
>>>>>>> On Sun, Apr 25, 2021 at 01:15:45PM +0200, Michal Suchánek wrote:
>>>>>>>> On Fri, Apr 23, 2021 at 07:55:28PM +0200, Michal Suchánek wrote:
>>>>>>>>> On Fri, Apr 23, 2021 at 07:41:29AM -0700, Yonghong Song wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 4/23/21 6:05 AM, Michal Suchánek wrote:
>>>>>>>>>>> Hello,
>>>>>>>>>>>
>>>>>>>>>>> I see this build error in linux-next (config attached).
>>>>>>>>>>>
>>>>>>>>>>> [ 4939s]   LD      vmlinux
>>>>>>>>>>> [ 4959s]   BTFIDS  vmlinux
>>>>>>>>>>> [ 4959s] FAILED unresolved symbol cubictcp_state
>>>>>>>>>>> [ 4960s] make[1]: ***
>>>>>>>>>>> [/home/abuild/rpmbuild/BUILD/kernel-vanilla-5.12~rc8.next.20210422/linux-5.12-rc8-next-20210422/Makefile:1277:
>>>>>>>>>>> vmlinux] Error 255
>>>>>>>>>>> [ 4960s] make: *** [../Makefile:222: __sub-make] Error 2
>>>
>>> this one was reported by Jesper and was fixed by upgrading pahole
>>> that contains the new function generation fixes (v1.19)
> 
> It needs pahole 1.21 here, 1.19 was not sufficient. Even then it
> regressed again after 5.12 on arm64:

Could you try against devel:tools? I've removed the ftrace filter from 
dwarves there (sr#890247 to factory).

>    LD      vmlinux
> ld: warning: -z relro ignored
>    BTFIDS  vmlinux
> FAILED unresolved symbol cubictcp_state
> make[1]: *** [/home/abuild/rpmbuild/BUILD/kernel-vanilla-5.12.0.13670.g5e321ded302d/linux-5.12-13670-g5e321ded302d/Makefile:1196: vmlinux] Error 255
> make: *** [../Makefile:215: __sub-make] Error 2
> 
> Any idea what might be wrong with arm64?


-- 
js
suse labs

Re: linux-next failing build due to missing cubictcp_state symbol

[Martin KaFai Lau]

On Thu, May 06, 2021 at 06:31:57AM +0200, Jiri Slaby wrote:
> On 05. 05. 21, 15:56, Michal Suchánek wrote:
> > On Mon, Apr 26, 2021 at 09:16:36PM +0200, Jiri Olsa wrote:
> > > On Mon, Apr 26, 2021 at 06:03:19PM +0200, Jiri Olsa wrote:
> > > > On Mon, Apr 26, 2021 at 08:41:49AM -0700, Yonghong Song wrote:
> > > > > 
> > > > > 
> > > > > On 4/26/21 5:14 AM, Michal Suchánek wrote:
> > > > > > On Mon, Apr 26, 2021 at 02:12:20PM +0200, Michal Suchánek wrote:
> > > > > > > On Mon, Apr 26, 2021 at 01:32:15PM +0200, Michal Suchánek wrote:
> > > > > > > > On Sun, Apr 25, 2021 at 01:15:45PM +0200, Michal Suchánek wrote:
> > > > > > > > > On Fri, Apr 23, 2021 at 07:55:28PM +0200, Michal Suchánek wrote:
> > > > > > > > > > On Fri, Apr 23, 2021 at 07:41:29AM -0700, Yonghong Song wrote:
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > On 4/23/21 6:05 AM, Michal Suchánek wrote:
> > > > > > > > > > > > Hello,
> > > > > > > > > > > > 
> > > > > > > > > > > > I see this build error in linux-next (config attached).
> > > > > > > > > > > > 
> > > > > > > > > > > > [ 4939s]   LD      vmlinux
> > > > > > > > > > > > [ 4959s]   BTFIDS  vmlinux
> > > > > > > > > > > > [ 4959s] FAILED unresolved symbol cubictcp_state
> > > > > > > > > > > > [ 4960s] make[1]: ***
> > > > > > > > > > > > [/home/abuild/rpmbuild/BUILD/kernel-vanilla-5.12~rc8.next.20210422/linux-5.12-rc8-next-20210422/Makefile:1277:
> > > > > > > > > > > > vmlinux] Error 255
> > > > > > > > > > > > [ 4960s] make: *** [../Makefile:222: __sub-make] Error 2
> > > > 
> > > > this one was reported by Jesper and was fixed by upgrading pahole
> > > > that contains the new function generation fixes (v1.19)
> > 
> > It needs pahole 1.21 here, 1.19 was not sufficient. Even then it
> > regressed again after 5.12 on arm64:
> 
> Could you try against devel:tools? I've removed the ftrace filter from
> dwarves there (sr#890247 to factory).
> 
> >    LD      vmlinux
> > ld: warning: -z relro ignored
> >    BTFIDS  vmlinux
> > FAILED unresolved symbol cubictcp_state
> > make[1]: *** [/home/abuild/rpmbuild/BUILD/kernel-vanilla-5.12.0.13670.g5e321ded302d/linux-5.12-13670-g5e321ded302d/Makefile:1196: vmlinux] Error 255
> > make: *** [../Makefile:215: __sub-make] Error 2
> > 
> > Any idea what might be wrong with arm64?
Can you also try this pahole patch which removes the ftrace filter:
https://lore.kernel.org/dwarves/20210506015824.2335125-1-kafai@fb.com/

I have just cross compiled with aarch64-linux-gcc together with the
above pahole patch.

Re: linux-next failing build due to missing cubictcp_state symbol

[Martin KaFai Lau]

On Tue, May 04, 2021 at 08:41:47AM +0200, Jiri Slaby wrote:
> On 03. 05. 21, 12:08, Jiri Olsa wrote:
> > On Mon, May 03, 2021 at 10:59:44AM +0200, Jiri Slaby wrote:
> > > CCing pahole people.
> > > 
> > > On 03. 05. 21, 9:59, Jiri Slaby wrote:
> > > > On 03. 05. 21, 8:11, Jiri Slaby wrote:
> > > > > > > > > > looks like vfs_truncate did not get into BTF data,
> > > > > > > > > > I'll try to reproduce
> > > > > > 
> > > > > > _None_ of the functions are generated by pahole -J from
> > > > > > debuginfo on ppc64. debuginfo appears to be correct. Neither
> > > > > > pahole -J fs/open.o works correctly. collect_functions in
> > > > > > dwarves seems to be defunct on ppc64... "functions" array is
> > > > > > bogus (so find_function -- the bsearch -- fails).
> > > > > 
> > > > > It's not that bogus. I forgot an asterisk:
> > > > > > #0  find_function (btfe=0x100269f80, name=0x10024631c
> > > > > > "stream_open") at
> > > > > > /usr/src/debug/dwarves-1.21-1.1.ppc64/btf_encoder.c:350
> > > > > > (gdb) p (*functions)@84
> > > > > > $5 = {{name = 0x7ffff68e0922 ".__se_compat_sys_ftruncate", addr
> > > > > > = 75232, size = 72, sh_addr = 65536, generated = false}, {
> > > > > >      name = 0x7ffff68e019e ".__se_compat_sys_open", addr = 80592,
> > > > > > size = 216, sh_addr = 65536, generated = false}, {
> > > > > >      name = 0x7ffff68e0076 ".__se_compat_sys_openat", addr =
> > > > > > 80816, size = 232, sh_addr = 65536, generated = false}, {
> > > > > >      name = 0x7ffff68e0908 ".__se_compat_sys_truncate", addr =
> > > > > > 74304, size = 100, sh_addr = 65536, generated = false}, {
> > > > > ...
> > > > > >      name = 0x7ffff68e0808 ".stream_open", addr = 65824, size =
> > > > > > 72, sh_addr = 65536, generated = false}, {
> > > > > ...
> > > > > >      name = 0x7ffff68e0751 ".vfs_truncate", addr = 73392, size =
> > > > > > 544, sh_addr = 65536, generated = false}}
> > > > > 
> > > > > The dot makes the difference, of course. The question is why is it
> > > > > there? I keep looking into it. Only if someone has an immediate
> > > > > idea...
> > > > 
> > > > Well, .vfs_truncate is in .text (and contains an ._mcount call). And
> > > > vfs_truncate is in .opd (w/o an ._mcount call). Since setup_functions
> > > > excludes all functions without the ._mcount call, is_ftrace_func later
> > > > returns false for such functions and they are filtered before the BTF
> > > > processing.
> > > > 
> > > > Technically, get_vmlinux_addrs looks at a list of functions between
> > > > __start_mcount_loc and __stop_mcount_loc and considers only the listed.
> > > > 
> > > > I don't know what the correct fix is (exclude .opd functions from the
> > > > filter?). Neither why cross compiler doesn't fail, nor why ebi v2 avoids
> > > > this too.
> > > 
> > > Attaching a patch for pahole which fixes the issue, but I have no idea
> > > whether it is the right fix at all.
> > 
> > hi,
> > we're considering to disable ftrace filter completely,
> > I guess that would solve this issue for ppc as well
> > 
> >    https://lore.kernel.org/bpf/20210501001653.x3b4rk4vk4iqv3n7@kafai-mbp.dhcp.thefacebook.com/
> 
> Right, the attached patch fixes it for me too.
Ah, I just noticed the attachment while replying an earlier message in
this thread.

Please feel free to add SOB to mine or
repost yours and toss mine.  Either way works for me.

Re: linux-next failing build due to missing cubictcp_state symbol

[Jiri Slaby]

On 06. 05. 21, 6:31, Jiri Slaby wrote:
>>>> this one was reported by Jesper and was fixed by upgrading pahole
>>>> that contains the new function generation fixes (v1.19)
>>
>> It needs pahole 1.21 here, 1.19 was not sufficient. Even then it
>> regressed again after 5.12 on arm64:
> 
> Could you try against devel:tools? I've removed the ftrace filter from 
> dwarves there (sr#890247 to factory).

Yes, works for me.

>>    LD      vmlinux
>> ld: warning: -z relro ignored
>>    BTFIDS  vmlinux
>> FAILED unresolved symbol cubictcp_state
>> make[1]: *** 
>> [/home/abuild/rpmbuild/BUILD/kernel-vanilla-5.12.0.13670.g5e321ded302d/linux-5.12-13670-g5e321ded302d/Makefile:1196: 
>> vmlinux] Error 255
>> make: *** [../Makefile:215: __sub-make] Error 2


-- 
js

Re: linux-next failing build due to missing cubictcp_state symbol

[Michal Suchánek]

On Thu, May 06, 2021 at 07:54:27AM +0200, Jiri Slaby wrote:
> On 06. 05. 21, 6:31, Jiri Slaby wrote:
> > > > > this one was reported by Jesper and was fixed by upgrading pahole
> > > > > that contains the new function generation fixes (v1.19)
> > > 
> > > It needs pahole 1.21 here, 1.19 was not sufficient. Even then it
> > > regressed again after 5.12 on arm64:
> > 
> > Could you try against devel:tools? I've removed the ftrace filter from
> > dwarves there (sr#890247 to factory).
> 
> Yes, works for me.
Yes, that fixes the problem with 5.13 rc

Thanks

Michal

Re: linux-next failing build due to missing cubictcp_state symbol

[Jiri Olsa]

On Wed, May 05, 2021 at 10:31:52PM -0700, Martin KaFai Lau wrote:
> On Tue, May 04, 2021 at 08:41:47AM +0200, Jiri Slaby wrote:
> > On 03. 05. 21, 12:08, Jiri Olsa wrote:
> > > On Mon, May 03, 2021 at 10:59:44AM +0200, Jiri Slaby wrote:
> > > > CCing pahole people.
> > > > 
> > > > On 03. 05. 21, 9:59, Jiri Slaby wrote:
> > > > > On 03. 05. 21, 8:11, Jiri Slaby wrote:
> > > > > > > > > > > looks like vfs_truncate did not get into BTF data,
> > > > > > > > > > > I'll try to reproduce
> > > > > > > 
> > > > > > > _None_ of the functions are generated by pahole -J from
> > > > > > > debuginfo on ppc64. debuginfo appears to be correct. Neither
> > > > > > > pahole -J fs/open.o works correctly. collect_functions in
> > > > > > > dwarves seems to be defunct on ppc64... "functions" array is
> > > > > > > bogus (so find_function -- the bsearch -- fails).
> > > > > > 
> > > > > > It's not that bogus. I forgot an asterisk:
> > > > > > > #0  find_function (btfe=0x100269f80, name=0x10024631c
> > > > > > > "stream_open") at
> > > > > > > /usr/src/debug/dwarves-1.21-1.1.ppc64/btf_encoder.c:350
> > > > > > > (gdb) p (*functions)@84
> > > > > > > $5 = {{name = 0x7ffff68e0922 ".__se_compat_sys_ftruncate", addr
> > > > > > > = 75232, size = 72, sh_addr = 65536, generated = false}, {
> > > > > > >      name = 0x7ffff68e019e ".__se_compat_sys_open", addr = 80592,
> > > > > > > size = 216, sh_addr = 65536, generated = false}, {
> > > > > > >      name = 0x7ffff68e0076 ".__se_compat_sys_openat", addr =
> > > > > > > 80816, size = 232, sh_addr = 65536, generated = false}, {
> > > > > > >      name = 0x7ffff68e0908 ".__se_compat_sys_truncate", addr =
> > > > > > > 74304, size = 100, sh_addr = 65536, generated = false}, {
> > > > > > ...
> > > > > > >      name = 0x7ffff68e0808 ".stream_open", addr = 65824, size =
> > > > > > > 72, sh_addr = 65536, generated = false}, {
> > > > > > ...
> > > > > > >      name = 0x7ffff68e0751 ".vfs_truncate", addr = 73392, size =
> > > > > > > 544, sh_addr = 65536, generated = false}}
> > > > > > 
> > > > > > The dot makes the difference, of course. The question is why is it
> > > > > > there? I keep looking into it. Only if someone has an immediate
> > > > > > idea...
> > > > > 
> > > > > Well, .vfs_truncate is in .text (and contains an ._mcount call). And
> > > > > vfs_truncate is in .opd (w/o an ._mcount call). Since setup_functions
> > > > > excludes all functions without the ._mcount call, is_ftrace_func later
> > > > > returns false for such functions and they are filtered before the BTF
> > > > > processing.
> > > > > 
> > > > > Technically, get_vmlinux_addrs looks at a list of functions between
> > > > > __start_mcount_loc and __stop_mcount_loc and considers only the listed.
> > > > > 
> > > > > I don't know what the correct fix is (exclude .opd functions from the
> > > > > filter?). Neither why cross compiler doesn't fail, nor why ebi v2 avoids
> > > > > this too.
> > > > 
> > > > Attaching a patch for pahole which fixes the issue, but I have no idea
> > > > whether it is the right fix at all.
> > > 
> > > hi,
> > > we're considering to disable ftrace filter completely,
> > > I guess that would solve this issue for ppc as well
> > > 
> > >    https://lore.kernel.org/bpf/20210501001653.x3b4rk4vk4iqv3n7@kafai-mbp.dhcp.thefacebook.com/
> > 
> > Right, the attached patch fixes it for me too.
> Ah, I just noticed the attachment while replying an earlier message in
> this thread.
> 
> Please feel free to add SOB to mine or
> repost yours and toss mine.  Either way works for me.
> 

I think this patch is missing the same removal I just commented
on your patch.. either way is ok for me

jirka

Re: linux-next failing build due to missing cubictcp_state symbol

[Florian Weimer]

* Jiri Slaby:

> The dot makes the difference, of course. The question is why is it
> there? I keep looking into it. Only if someone has an immediate
> idea...

We see the failure on aarch64 as well, with 8404c9fbc84b741
(from Linus' tree).

As far as I can tell, the core issue is that BTF_ID is applied to a
symbol which is defined as static on the C side (and even in a different
translation unit, but this aspect doesn't really matter).  The compiler
can and will change symbol names, calling conventions and data layout
for static functions/variables, so this is never going to work reliably.
It is possible to inhibit these optimizations by using __attribute__
((used)).  But I'm pretty sure that BTF generation fails to work
properly if there are symbol name collisions, so I think it's better to
drop the static and rely on duplicate symbol checks from the linker
(which of course does not happen for C entities declared static).

Thanks,
Florian