-
Notifications
You must be signed in to change notification settings - Fork 149
bpf: fix "unresolved symbol" build error with resolve_btfids #143
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Master branch: 963ec27 |
Master branch: ea7da1d |
a036439
to
2f2bf53
Compare
Master branch: f4d385e |
2f2bf53
to
a6b4f6d
Compare
Master branch: f4d385e |
a6b4f6d
to
92dfc9b
Compare
Michal reported a build failure likes below: BTFIDS vmlinux FAILED unresolved symbol tcp_timewait_sock make[1]: *** [/.../linux-5.9-rc7/Makefile:1176: vmlinux] Error 255 This error can be triggered when config has CONFIG_NET enabled but CONFIG_INET disabled. In this case, there is no user of structs inet_timewait_sock and tcp_timewait_sock and hence vmlinux BTF types are not generated for these two structures. To fix the problem, omit the above two types for BTF_SOCK_TYPE_xxx macro if CONFIG_INET is not defined. Fixes: fce557b ("bpf: Make btf_sock_ids global") Reported-by: Michal Kubecek <[email protected]> Signed-off-by: Yonghong Song <[email protected]> Acked-by: Andrii Nakryiko <[email protected]>
Master branch: 3effc06 |
92dfc9b
to
959e437
Compare
At least one diff in series https://patchwork.kernel.org/project/bpf/list/?series=357951 irrelevant now. Closing PR. |
Since limited tracking device per condition, this feature is to support tracking multiple devices concurrently. When a pattern monitor detects the device, this feature issues an address monitor for tracking that device. Let pattern monitor can keep monitor new devices. This feature adds an address filter when receiving a LE monitor device event which monitor handle is for a pattern, and the controller started monitoring the device. And this feature also has cancelled the monitor advertisement from address filters when receiving a LE monitor device event when the controller stopped monitoring the device specified by an address and monitor handle. Below is an example to know the feature adds the address filter. //Add MSFT pattern monitor < HCI Command: Vendor (0x3f|0x00f0) plen 14 #142 [hci0] 55.552420 03 b8 a4 03 ff 01 01 06 09 05 5f 52 45 46 .........._REF > HCI Event: Command Complete (0x0e) plen 6 #143 [hci0] 55.653960 Vendor (0x3f|0x00f0) ncmd 2 Status: Success (0x00) 03 00 //Got event from the pattern monitor > HCI Event: Vendor (0xff) plen 18 #148 [hci0] 58.384953 23 79 54 33 77 88 97 68 02 00 fb c1 29 eb 27 b8 #yT3w..h....).'. 00 01 .. //Add MSFT address monitor (Sample address: B8:27:EB:29:C1:FB) < HCI Command: Vendor (0x3f|0x00f0) plen 13 #149 [hci0] 58.385067 03 b8 a4 03 ff 04 00 fb c1 29 eb 27 b8 .........).'. //Report to userspace about found device (ADV Monitor Device Found) @ MGMT Event: Unknown (0x002f) plen 38 {0x0003} [hci0] 58.680042 01 00 fb c1 29 eb 27 b8 01 ce 00 00 00 00 16 00 ....).'......... 0a 09 4b 45 59 42 44 5f 52 45 46 02 01 06 03 19 ..KEYBD_REF..... c1 03 03 03 12 18 ...... //Got event from address monitor > HCI Event: Vendor (0xff) plen 18 #152 [hci0] 58.672956 23 79 54 33 77 88 97 68 02 00 fb c1 29 eb 27 b8 #yT3w..h....).'. 01 01 Signed-off-by: Alex Lu <[email protected]> Signed-off-by: Hilda Wu <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]>
Recently, when running './test_progs -j', I occasionally hit the following errors: test_lwt_redirect:PASS:pthread_create 0 nsec test_lwt_redirect_run:FAIL:netns_create unexpected error: 256 (errno 0) #142/2 lwt_redirect/lwt_redirect_normal_nomac:FAIL #142 lwt_redirect:FAIL test_lwt_reroute:PASS:pthread_create 0 nsec test_lwt_reroute_run:FAIL:netns_create unexpected error: 256 (errno 0) test_lwt_reroute:PASS:pthread_join 0 nsec #143/2 lwt_reroute/lwt_reroute_qdisc_dropped:FAIL #143 lwt_reroute:FAIL The netns_create() definition looks like below: #define NETNS "ns_lwt" static inline int netns_create(void) { return system("ip netns add " NETNS); } One possibility is that both lwt_redirect and lwt_reroute create netns with the same name "ns_lwt" which may cause conflict. I tried the following example: $ sudo ip netns add abc $ echo $? 0 $ sudo ip netns add abc Cannot create namespace file "/var/run/netns/abc": File exists $ echo $? 1 $ The return code for above netns_create() is 256. The internet search suggests that the return value for 'ip netns add ns_lwt' is 1, which matches the above 'sudo ip netns add abc' example. This patch tried to use different netns names for two tests to avoid 'ip netns add <name>' failure. I ran './test_progs -j' 10 times and all succeeded with lwt_redirect/lwt_reroute tests. Signed-off-by: Yonghong Song <[email protected]>
Recently, when running './test_progs -j', I occasionally hit the following errors: test_lwt_redirect:PASS:pthread_create 0 nsec test_lwt_redirect_run:FAIL:netns_create unexpected error: 256 (errno 0) #142/2 lwt_redirect/lwt_redirect_normal_nomac:FAIL #142 lwt_redirect:FAIL test_lwt_reroute:PASS:pthread_create 0 nsec test_lwt_reroute_run:FAIL:netns_create unexpected error: 256 (errno 0) test_lwt_reroute:PASS:pthread_join 0 nsec #143/2 lwt_reroute/lwt_reroute_qdisc_dropped:FAIL #143 lwt_reroute:FAIL The netns_create() definition looks like below: #define NETNS "ns_lwt" static inline int netns_create(void) { return system("ip netns add " NETNS); } One possibility is that both lwt_redirect and lwt_reroute create netns with the same name "ns_lwt" which may cause conflict. I tried the following example: $ sudo ip netns add abc $ echo $? 0 $ sudo ip netns add abc Cannot create namespace file "/var/run/netns/abc": File exists $ echo $? 1 $ The return code for above netns_create() is 256. The internet search suggests that the return value for 'ip netns add ns_lwt' is 1, which matches the above 'sudo ip netns add abc' example. This patch tried to use different netns names for two tests to avoid 'ip netns add <name>' failure. I ran './test_progs -j' 10 times and all succeeded with lwt_redirect/lwt_reroute tests. Signed-off-by: Yonghong Song <[email protected]> Tested-by: Eduard Zingerman <[email protected]>
Recently, when running './test_progs -j', I occasionally hit the following errors: test_lwt_redirect:PASS:pthread_create 0 nsec test_lwt_redirect_run:FAIL:netns_create unexpected error: 256 (errno 0) #142/2 lwt_redirect/lwt_redirect_normal_nomac:FAIL #142 lwt_redirect:FAIL test_lwt_reroute:PASS:pthread_create 0 nsec test_lwt_reroute_run:FAIL:netns_create unexpected error: 256 (errno 0) test_lwt_reroute:PASS:pthread_join 0 nsec #143/2 lwt_reroute/lwt_reroute_qdisc_dropped:FAIL #143 lwt_reroute:FAIL The netns_create() definition looks like below: #define NETNS "ns_lwt" static inline int netns_create(void) { return system("ip netns add " NETNS); } One possibility is that both lwt_redirect and lwt_reroute create netns with the same name "ns_lwt" which may cause conflict. I tried the following example: $ sudo ip netns add abc $ echo $? 0 $ sudo ip netns add abc Cannot create namespace file "/var/run/netns/abc": File exists $ echo $? 1 $ The return code for above netns_create() is 256. The internet search suggests that the return value for 'ip netns add ns_lwt' is 1, which matches the above 'sudo ip netns add abc' example. This patch tried to use different netns names for two tests to avoid 'ip netns add <name>' failure. I ran './test_progs -j' 10 times and all succeeded with lwt_redirect/lwt_reroute tests. Signed-off-by: Yonghong Song <[email protected]> Tested-by: Eduard Zingerman <[email protected]>
Recently, when running './test_progs -j', I occasionally hit the following errors: test_lwt_redirect:PASS:pthread_create 0 nsec test_lwt_redirect_run:FAIL:netns_create unexpected error: 256 (errno 0) #142/2 lwt_redirect/lwt_redirect_normal_nomac:FAIL #142 lwt_redirect:FAIL test_lwt_reroute:PASS:pthread_create 0 nsec test_lwt_reroute_run:FAIL:netns_create unexpected error: 256 (errno 0) test_lwt_reroute:PASS:pthread_join 0 nsec #143/2 lwt_reroute/lwt_reroute_qdisc_dropped:FAIL #143 lwt_reroute:FAIL The netns_create() definition looks like below: #define NETNS "ns_lwt" static inline int netns_create(void) { return system("ip netns add " NETNS); } One possibility is that both lwt_redirect and lwt_reroute create netns with the same name "ns_lwt" which may cause conflict. I tried the following example: $ sudo ip netns add abc $ echo $? 0 $ sudo ip netns add abc Cannot create namespace file "/var/run/netns/abc": File exists $ echo $? 1 $ The return code for above netns_create() is 256. The internet search suggests that the return value for 'ip netns add ns_lwt' is 1, which matches the above 'sudo ip netns add abc' example. This patch tried to use different netns names for two tests to avoid 'ip netns add <name>' failure. I ran './test_progs -j' 10 times and all succeeded with lwt_redirect/lwt_reroute tests. Signed-off-by: Yonghong Song <[email protected]> Tested-by: Eduard Zingerman <[email protected]>
Recently, when running './test_progs -j', I occasionally hit the following errors: test_lwt_redirect:PASS:pthread_create 0 nsec test_lwt_redirect_run:FAIL:netns_create unexpected error: 256 (errno 0) #142/2 lwt_redirect/lwt_redirect_normal_nomac:FAIL #142 lwt_redirect:FAIL test_lwt_reroute:PASS:pthread_create 0 nsec test_lwt_reroute_run:FAIL:netns_create unexpected error: 256 (errno 0) test_lwt_reroute:PASS:pthread_join 0 nsec #143/2 lwt_reroute/lwt_reroute_qdisc_dropped:FAIL #143 lwt_reroute:FAIL The netns_create() definition looks like below: #define NETNS "ns_lwt" static inline int netns_create(void) { return system("ip netns add " NETNS); } One possibility is that both lwt_redirect and lwt_reroute create netns with the same name "ns_lwt" which may cause conflict. I tried the following example: $ sudo ip netns add abc $ echo $? 0 $ sudo ip netns add abc Cannot create namespace file "/var/run/netns/abc": File exists $ echo $? 1 $ The return code for above netns_create() is 256. The internet search suggests that the return value for 'ip netns add ns_lwt' is 1, which matches the above 'sudo ip netns add abc' example. This patch tried to use different netns names for two tests to avoid 'ip netns add <name>' failure. I ran './test_progs -j' 10 times and all succeeded with lwt_redirect/lwt_reroute tests. Signed-off-by: Yonghong Song <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Tested-by: Eduard Zingerman <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
iwl4965 fails upon resume from hibernation on my laptop. The reason seems to be a stale interrupt which isn't being cleared out before interrupts are enabled. We end up with a race beween the resume trying to bring things back up, and the restart work (queued form the interrupt handler) trying to bring things down. Eventually the whole thing blows up. Fix the problem by clearing out any stale interrupts before interrupts get enabled during resume. Here's a debug log of the indicent: [ 12.042589] ieee80211 phy0: il_isr ISR inta 0x00000080, enabled 0xaa00008b, fh 0x00000000 [ 12.042625] ieee80211 phy0: il4965_irq_tasklet inta 0x00000080, enabled 0x00000000, fh 0x00000000 [ 12.042651] iwl4965 0000:10:00.0: RF_KILL bit toggled to enable radio. [ 12.042653] iwl4965 0000:10:00.0: On demand firmware reload [ 12.042690] ieee80211 phy0: il4965_irq_tasklet End inta 0x00000000, enabled 0xaa00008b, fh 0x00000000, flags 0x00000282 [ 12.052207] ieee80211 phy0: il4965_mac_start enter [ 12.052212] ieee80211 phy0: il_prep_station Add STA to driver ID 31: ff:ff:ff:ff:ff:ff [ 12.052244] ieee80211 phy0: il4965_set_hw_ready hardware ready [ 12.052324] ieee80211 phy0: il_apm_init Init card's basic functions [ 12.052348] ieee80211 phy0: il_apm_init L1 Enabled; Disabling L0S [ 12.055727] ieee80211 phy0: il4965_load_bsm Begin load bsm [ 12.056140] ieee80211 phy0: il4965_verify_bsm Begin verify bsm [ 12.058642] ieee80211 phy0: il4965_verify_bsm BSM bootstrap uCode image OK [ 12.058721] ieee80211 phy0: il4965_load_bsm BSM write complete, poll 1 iterations [ 12.058734] ieee80211 phy0: __il4965_up iwl4965 is coming up [ 12.058737] ieee80211 phy0: il4965_mac_start Start UP work done. [ 12.058757] ieee80211 phy0: __il4965_down iwl4965 is going down [ 12.058761] ieee80211 phy0: il_scan_cancel_timeout Scan cancel timeout [ 12.058762] ieee80211 phy0: il_do_scan_abort Not performing scan to abort [ 12.058765] ieee80211 phy0: il_clear_ucode_stations Clearing ucode stations in driver [ 12.058767] ieee80211 phy0: il_clear_ucode_stations No active stations found to be cleared [ 12.058819] ieee80211 phy0: _il_apm_stop Stop card, put in low power state [ 12.058827] ieee80211 phy0: _il_apm_stop_master stop master [ 12.058864] ieee80211 phy0: il4965_clear_free_frames 0 frames on pre-allocated heap on clear. [ 12.058869] ieee80211 phy0: Hardware restart was requested [ 16.132299] iwl4965 0000:10:00.0: START_ALIVE timeout after 4000ms. [ 16.132303] ------------[ cut here ]------------ [ 16.132304] Hardware became unavailable upon resume. This could be a software issue prior to suspend or a hardware issue. [ 16.132338] WARNING: CPU: 0 PID: 181 at net/mac80211/util.c:1826 ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132390] Modules linked in: ctr ccm sch_fq_codel xt_tcpudp xt_multiport xt_state iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv4 ip_tables x_tables binfmt_misc joydev mousedev btusb btrtl btintel btbcm bluetooth ecdh_generic ecc iTCO_wdt i2c_dev iwl4965 iwlegacy coretemp snd_hda_codec_analog pcspkr psmouse mac80211 snd_hda_codec_generic libarc4 sdhci_pci cqhci sha256_generic sdhci libsha256 firewire_ohci snd_hda_intel snd_intel_dspcfg mmc_core snd_hda_codec snd_hwdep firewire_core led_class iosf_mbi snd_hda_core uhci_hcd lpc_ich crc_itu_t cfg80211 ehci_pci ehci_hcd snd_pcm usbcore mfd_core rfkill snd_timer snd usb_common soundcore video parport_pc parport intel_agp wmi intel_gtt backlight e1000e agpgart evdev [ 16.132456] CPU: 0 UID: 0 PID: 181 Comm: kworker/u8:6 Not tainted 6.11.0-cl+ kernel-patches#143 [ 16.132460] Hardware name: Hewlett-Packard HP Compaq 6910p/30BE, BIOS 68MCU Ver. F.19 07/06/2010 [ 16.132463] Workqueue: async async_run_entry_fn [ 16.132469] RIP: 0010:ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132501] Code: da 02 00 00 c6 83 ad 05 00 00 00 48 89 df e8 98 1b fc ff 85 c0 41 89 c7 0f 84 e9 02 00 00 48 c7 c7 a0 e6 48 a0 e8 d1 77 c4 e0 <0f> 0b eb 2d 84 c0 0f 85 8b 01 00 00 c6 87 ad 05 00 00 00 e8 69 1b [ 16.132504] RSP: 0018:ffffc9000029fcf0 EFLAGS: 00010282 [ 16.132507] RAX: 0000000000000000 RBX: ffff8880072008e0 RCX: 0000000000000001 [ 16.132509] RDX: ffffffff81f21a18 RSI: 0000000000000086 RDI: 0000000000000001 [ 16.132510] RBP: ffff8880072003c0 R08: 0000000000000000 R09: 0000000000000003 [ 16.132512] R10: 0000000000000000 R11: ffff88807e5b0000 R12: 0000000000000001 [ 16.132514] R13: 0000000000000000 R14: 0000000000000000 R15: 00000000ffffff92 [ 16.132515] FS: 0000000000000000(0000) GS:ffff88807c200000(0000) knlGS:0000000000000000 [ 16.132517] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 16.132519] CR2: 000055dd43786c08 CR3: 000000000978f000 CR4: 00000000000006f0 [ 16.132521] Call Trace: [ 16.132525] <TASK> [ 16.132526] ? __warn+0x77/0x120 [ 16.132532] ? ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132564] ? report_bug+0x15c/0x190 [ 16.132568] ? handle_bug+0x36/0x70 [ 16.132571] ? exc_invalid_op+0x13/0x60 [ 16.132573] ? asm_exc_invalid_op+0x16/0x20 [ 16.132579] ? ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132611] ? snd_hdac_bus_init_cmd_io+0x24/0x200 [snd_hda_core] [ 16.132617] ? pick_eevdf+0x133/0x1c0 [ 16.132622] ? check_preempt_wakeup_fair+0x70/0x90 [ 16.132626] ? wakeup_preempt+0x4a/0x60 [ 16.132628] ? ttwu_do_activate.isra.0+0x5a/0x190 [ 16.132632] wiphy_resume+0x79/0x1a0 [cfg80211] [ 16.132675] ? wiphy_suspend+0x2a0/0x2a0 [cfg80211] [ 16.132697] dpm_run_callback+0x75/0x1b0 [ 16.132703] device_resume+0x97/0x200 [ 16.132707] async_resume+0x14/0x20 [ 16.132711] async_run_entry_fn+0x1b/0xa0 [ 16.132714] process_one_work+0x13d/0x350 [ 16.132718] worker_thread+0x2be/0x3d0 [ 16.132722] ? cancel_delayed_work_sync+0x70/0x70 [ 16.132725] kthread+0xc0/0xf0 [ 16.132729] ? kthread_park+0x80/0x80 [ 16.132732] ret_from_fork+0x28/0x40 [ 16.132735] ? kthread_park+0x80/0x80 [ 16.132738] ret_from_fork_asm+0x11/0x20 [ 16.132741] </TASK> [ 16.132742] ---[ end trace 0000000000000000 ]--- [ 16.132930] ------------[ cut here ]------------ [ 16.132932] WARNING: CPU: 0 PID: 181 at net/mac80211/driver-ops.c:41 drv_stop+0xe7/0xf0 [mac80211] [ 16.132957] Modules linked in: ctr ccm sch_fq_codel xt_tcpudp xt_multiport xt_state iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv4 ip_tables x_tables binfmt_misc joydev mousedev btusb btrtl btintel btbcm bluetooth ecdh_generic ecc iTCO_wdt i2c_dev iwl4965 iwlegacy coretemp snd_hda_codec_analog pcspkr psmouse mac80211 snd_hda_codec_generic libarc4 sdhci_pci cqhci sha256_generic sdhci libsha256 firewire_ohci snd_hda_intel snd_intel_dspcfg mmc_core snd_hda_codec snd_hwdep firewire_core led_class iosf_mbi snd_hda_core uhci_hcd lpc_ich crc_itu_t cfg80211 ehci_pci ehci_hcd snd_pcm usbcore mfd_core rfkill snd_timer snd usb_common soundcore video parport_pc parport intel_agp wmi intel_gtt backlight e1000e agpgart evdev [ 16.133014] CPU: 0 UID: 0 PID: 181 Comm: kworker/u8:6 Tainted: G W 6.11.0-cl+ kernel-patches#143 [ 16.133018] Tainted: [W]=WARN [ 16.133019] Hardware name: Hewlett-Packard HP Compaq 6910p/30BE, BIOS 68MCU Ver. F.19 07/06/2010 [ 16.133021] Workqueue: async async_run_entry_fn [ 16.133025] RIP: 0010:drv_stop+0xe7/0xf0 [mac80211] [ 16.133048] Code: 48 85 c0 74 0e 48 8b 78 08 89 ea 48 89 de e8 e0 87 04 00 65 ff 0d d1 de c4 5f 0f 85 42 ff ff ff e8 be 52 c2 e0 e9 38 ff ff ff <0f> 0b 5b 5d c3 0f 1f 40 00 41 54 49 89 fc 55 53 48 89 f3 2e 2e 2e [ 16.133050] RSP: 0018:ffffc9000029fc50 EFLAGS: 00010246 [ 16.133053] RAX: 0000000000000000 RBX: ffff8880072008e0 RCX: ffff88800377f6c0 [ 16.133054] RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff8880072008e0 [ 16.133056] RBP: 0000000000000000 R08: ffffffff81f238d8 R09: 0000000000000000 [ 16.133058] R10: ffff8880080520f0 R11: 0000000000000000 R12: ffff888008051c60 [ 16.133060] R13: ffff8880072008e0 R14: 0000000000000000 R15: ffff8880072011d8 [ 16.133061] FS: 0000000000000000(0000) GS:ffff88807c200000(0000) knlGS:0000000000000000 [ 16.133063] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 16.133065] CR2: 000055dd43786c08 CR3: 000000000978f000 CR4: 00000000000006f0 [ 16.133067] Call Trace: [ 16.133069] <TASK> [ 16.133070] ? __warn+0x77/0x120 [ 16.133075] ? drv_stop+0xe7/0xf0 [mac80211] [ 16.133098] ? report_bug+0x15c/0x190 [ 16.133100] ? handle_bug+0x36/0x70 [ 16.133103] ? exc_invalid_op+0x13/0x60 [ 16.133105] ? asm_exc_invalid_op+0x16/0x20 [ 16.133109] ? drv_stop+0xe7/0xf0 [mac80211] [ 16.133132] ieee80211_do_stop+0x55a/0x810 [mac80211] [ 16.133161] ? fq_codel_reset+0xa5/0xc0 [sch_fq_codel] [ 16.133164] ieee80211_stop+0x4f/0x180 [mac80211] [ 16.133192] __dev_close_many+0xa2/0x120 [ 16.133195] dev_close_many+0x90/0x150 [ 16.133198] dev_close+0x5d/0x80 [ 16.133200] cfg80211_shutdown_all_interfaces+0x40/0xe0 [cfg80211] [ 16.133223] wiphy_resume+0xb2/0x1a0 [cfg80211] [ 16.133247] ? wiphy_suspend+0x2a0/0x2a0 [cfg80211] [ 16.133269] dpm_run_callback+0x75/0x1b0 [ 16.133273] device_resume+0x97/0x200 [ 16.133277] async_resume+0x14/0x20 [ 16.133280] async_run_entry_fn+0x1b/0xa0 [ 16.133283] process_one_work+0x13d/0x350 [ 16.133287] worker_thread+0x2be/0x3d0 [ 16.133290] ? cancel_delayed_work_sync+0x70/0x70 [ 16.133294] kthread+0xc0/0xf0 [ 16.133296] ? kthread_park+0x80/0x80 [ 16.133299] ret_from_fork+0x28/0x40 [ 16.133302] ? kthread_park+0x80/0x80 [ 16.133304] ret_from_fork_asm+0x11/0x20 [ 16.133307] </TASK> [ 16.133308] ---[ end trace 0000000000000000 ]--- [ 16.133335] ieee80211 phy0: PM: dpm_run_callback(): wiphy_resume [cfg80211] returns -110 [ 16.133360] ieee80211 phy0: PM: failed to restore async: error -110 Cc: [email protected] Cc: Stanislaw Gruszka <[email protected]> Cc: Kalle Valo <[email protected]> Cc: [email protected] Signed-off-by: Ville Syrjälä <[email protected]> Acked-by: Stanislaw Gruszka <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://patch.msgid.link/[email protected]
cd tools/testing/selftests/bpf ./test_progs -t irq kernel-patches#143/29 irq/in_interrupt:OK kernel-patches#143 irq:OK Summary: 1/34 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Leon Hwang <[email protected]>
cd tools/testing/selftests/bpf ./test_progs -t irq kernel-patches#143/29 irq/in_interrupt:OK kernel-patches#143 irq:OK Summary: 1/34 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Leon Hwang <[email protected]>
cd tools/testing/selftests/bpf ./test_progs -t irq kernel-patches#143/29 irq/in_interrupt:OK kernel-patches#143 irq:OK Summary: 1/34 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Leon Hwang <[email protected]>
cd tools/testing/selftests/bpf ./test_progs -t irq #143/29 irq/in_interrupt:OK #143 irq:OK Summary: 1/34 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Leon Hwang <[email protected]>
cd tools/testing/selftests/bpf ./test_progs -t irq #143/29 irq/in_interrupt:OK #143 irq:OK Summary: 1/34 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Leon Hwang <[email protected]>
cd tools/testing/selftests/bpf ./test_progs -t irq #143/29 irq/in_interrupt:OK #143 irq:OK Summary: 1/34 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Leon Hwang <[email protected]>
cd tools/testing/selftests/bpf ./test_progs -t irq #143/29 irq/in_interrupt:OK #143 irq:OK Summary: 1/34 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Leon Hwang <[email protected]>
cd tools/testing/selftests/bpf ./test_progs -t irq kernel-patches#143/29 irq/in_interrupt:OK kernel-patches#143 irq:OK Summary: 1/34 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Leon Hwang <[email protected]>
cd tools/testing/selftests/bpf ./test_progs -t irq kernel-patches#143/29 irq/in_interrupt:OK kernel-patches#143 irq:OK Summary: 1/34 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Leon Hwang <[email protected]>
cd tools/testing/selftests/bpf ./test_progs -t irq #143/29 irq/in_interrupt:OK #143 irq:OK Summary: 1/34 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Leon Hwang <[email protected]>
This test currently fails on armhf: verify_success:PASS:skel 0 nsec verify_success:PASS:bpf_object__find_program_by_name 0 nsec verify_success:PASS:kfunc_call_test4 0 nsec verify_success:FAIL:retval unexpected retval: actual 4294966063 != expected -1234 kernel-patches#143/11 kfunc_call/kfunc_call_test4:FAIL The problem can be traced to using 'long' as a 64-bit type in bpf_testmod function bpf_kfunc_call_test4(), to force 64-bit signed arithmetic, which breaks down on 32-bit systems. Fix by explicitly using 's64' rather than long. Signed-off-by: Tony Ambardar <[email protected]>
This test currently fails on armhf: verify_success:PASS:skel 0 nsec verify_success:PASS:bpf_object__find_program_by_name 0 nsec verify_success:PASS:kfunc_call_test4 0 nsec verify_success:FAIL:retval unexpected retval: actual 4294966063 != expected -1234 kernel-patches#143/11 kfunc_call/kfunc_call_test4:FAIL The problem can be traced to using 'long' as a 64-bit type in bpf_testmod function bpf_kfunc_call_test4(), to force 64-bit signed arithmetic, which breaks down on 32-bit systems. Fix by explicitly using 's64' rather than long. Signed-off-by: Tony Ambardar <[email protected]>
Pull request for series with
subject: bpf: fix "unresolved symbol" build error with resolve_btfids
version: 1
url: https://patchwork.kernel.org/project/bpf/list/?series=357951