Skip to content

bpf: fix raw_tp test run in preempt kernel #135

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.

Sign up for GitHub

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

Jump to bottom
Closed
wants to merge 1 commit into from
Closed

bpf: fix raw_tp test run in preempt kernel #135

wants to merge 1 commit into from

Conversation

kernel-patches-bot
Copy link

Pull request for series with
subject: bpf: fix raw_tp test run in preempt kernel
version: 2
url: https://patchwork.kernel.org/project/bpf/list/?series=357455

@kernel-patches-bot
Copy link
Author

Master branch: 963ec27
series: https://patchwork.kernel.org/project/bpf/list/?series=357455
version: 2

Pull request is NOT updated. Failed to apply https://patchwork.kernel.org/project/bpf/list/?series=357455
error message:

Cmd('git') failed due to: exit code(128)
  cmdline: git am -3
  stdout: 'Applying: bpf: fix raw_tp test run in preempt kernel
Using index info to reconstruct a base tree...
M	net/bpf/test_run.c
Patch failed at 0001 bpf: fix raw_tp test run in preempt kernel
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".'
  stderr: 'error: patch failed: net/bpf/test_run.c:293
error: net/bpf/test_run.c: patch does not apply
error: Did you hand edit your patch?
It does not apply to blobs recorded in its index.
hint: Use 'git am --show-current-patch' to see the failed patch'

conflict:

@kernel-patches-bot
Copy link
Author

At least one diff in series https://patchwork.kernel.org/project/bpf/list/?series=357455 irrelevant now. Closing PR.

@kernel-patches-bot kernel-patches-bot deleted the series/357421=>bpf-next branch October 7, 2020 01:45
kernel-patches-bot pushed a commit that referenced this pull request Mar 24, 2022
cifs: we do not need a spinlock around the tree access during umount
9a14b65 
Remove the spinlock around the tree traversal as we are calling possibly
sleeping functions.
We do not need a spinlock here as there will be no modifications to this
tree at this point.

This prevents warnings like this to occur in dmesg:
[  653.774996] BUG: sleeping function called from invalid context at kernel/loc\
king/mutex.c:280
[  653.775088] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1827, nam\
e: umount
[  653.775152] preempt_count: 1, expected: 0
[  653.775191] CPU: 0 PID: 1827 Comm: umount Tainted: G        W  OE     5.17.0\
-rc7-00006-g4eb628dd74df #135
[  653.775195] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-\
1.fc33 04/01/2014
[  653.775197] Call Trace:
[  653.775199]  <TASK>
[  653.775202]  dump_stack_lvl+0x34/0x44
[  653.775209]  __might_resched.cold+0x13f/0x172
[  653.775213]  mutex_lock+0x75/0xf0
[  653.775217]  ? __mutex_lock_slowpath+0x10/0x10
[  653.775220]  ? _raw_write_lock_irq+0xd0/0xd0
[  653.775224]  ? dput+0x6b/0x360
[  653.775228]  cifs_kill_sb+0xff/0x1d0 [cifs]
[  653.775285]  deactivate_locked_super+0x85/0x130
[  653.775289]  cleanup_mnt+0x32c/0x4d0
[  653.775292]  ? path_umount+0x228/0x380
[  653.775296]  task_work_run+0xd8/0x180
[  653.775301]  exit_to_user_mode_loop+0x152/0x160
[  653.775306]  exit_to_user_mode_prepare+0x89/0xd0
[  653.775315]  syscall_exit_to_user_mode+0x12/0x30
[  653.775322]  do_syscall_64+0x48/0x90
[  653.775326]  entry_SYSCALL_64_after_hwframe+0x44/0xae

Fixes: 187af6e98b44e5d8f25e1d41a92db138eb54416f ("cifs: fix handlecache and multiuser")
Reported-by: kernel test robot <[email protected]>
Cc: [email protected]
Signed-off-by: Ronnie Sahlberg <[email protected]>
Signed-off-by: Steve French <[email protected]>
kernel-patches-bot pushed a commit that referenced this pull request Dec 11, 2022
@dabros-jan @torvalds
char: tpm: Protect tpm_pm_suspend with locks
23393c6 
Currently tpm transactions are executed unconditionally in
tpm_pm_suspend() function, which may lead to races with other tpm
accessors in the system.

Specifically, the hw_random tpm driver makes use of tpm_get_random(),
and this function is called in a loop from a kthread, which means it's
not frozen alongside userspace, and so can race with the work done
during system suspend:

  tpm tpm0: tpm_transmit: tpm_recv: error -52
  tpm tpm0: invalid TPM_STS.x 0xff, dumping stack for forensics
  CPU: 0 PID: 1 Comm: init Not tainted 6.1.0-rc5+ #135
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-20220807_005459-localhost 04/01/2014
  Call Trace:
   tpm_tis_status.cold+0x19/0x20
   tpm_transmit+0x13b/0x390
   tpm_transmit_cmd+0x20/0x80
   tpm1_pm_suspend+0xa6/0x110
   tpm_pm_suspend+0x53/0x80
   __pnp_bus_suspend+0x35/0xe0
   __device_suspend+0x10f/0x350

Fix this by calling tpm_try_get_ops(), which itself is a wrapper around
tpm_chip_start(), but takes the appropriate mutex.

Signed-off-by: Jan Dabros <[email protected]>
Reported-by: Vlastimil Babka <[email protected]>
Tested-by: Jason A. Donenfeld <[email protected]>
Tested-by: Vlastimil Babka <[email protected]>
Link: https://lore.kernel.org/all/[email protected]/
Cc: [email protected]
Fixes: e891db1 ("tpm: turn on TPM on suspend for TPM 1.x")
[Jason: reworked commit message, added metadata]
Signed-off-by: Jason A. Donenfeld <[email protected]>
Reviewed-by: Jarkko Sakkinen <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
kernel-patches-bot pushed a commit that referenced this pull request Dec 20, 2022
@namhyung
selftests/bpf: Add perf_event_read_sample test cases
3ee2e7f 
It checks the perf event sample access with bpf_cast_to_kern_ctx().
It should access sample data only event->attr.sample_type allows.
Other fields might not be initialized.

  $ ./vmtest.sh ./test_progs -t perf_event_read_sample
  ...
  #135/1   perf_event_read_sample/perf_event_read_sample_ok:OK
  #135/2   perf_event_read_sample/perf_event_read_sample_invalid:OK
  #135     perf_event_read_sample:OK

Signed-off-by: Namhyung Kim <[email protected]>
kernel-patches-bot pushed a commit that referenced this pull request Dec 21, 2022
@namhyung
selftests/bpf: Add perf_event_read_sample test cases
52cfac2 
It checks the perf event sample access with bpf_cast_to_kern_ctx().
It should access sample data only event->attr.sample_type allows.
Other fields might not be initialized.

  $ ./vmtest.sh ./test_progs -t perf_event_read_sample
  ...
  #135/1   perf_event_read_sample/perf_event_read_sample_ok:OK
  #135/2   perf_event_read_sample/perf_event_read_sample_invalid:OK
  #135     perf_event_read_sample:OK

Signed-off-by: Namhyung Kim <[email protected]>
kernel-patches-bot pushed a commit that referenced this pull request Dec 21, 2022
@namhyung
selftests/bpf: Add perf_event_read_sample test cases
28aa0a8 
It checks the perf event sample access with bpf_cast_to_kern_ctx().
It should access sample data only event->attr.sample_type allows.
Other fields might not be initialized.

  $ ./vmtest.sh ./test_progs -t perf_event_read_sample
  ...
  #135/1   perf_event_read_sample/perf_event_read_sample_ok:OK
  #135/2   perf_event_read_sample/perf_event_read_sample_invalid:OK
  #135     perf_event_read_sample:OK

Signed-off-by: Namhyung Kim <[email protected]>
kernel-patches-bot pushed a commit that referenced this pull request Dec 21, 2022
@namhyung
selftests/bpf: Add perf_event_read_sample test cases
a632aa3 
It checks the perf event sample access with bpf_cast_to_kern_ctx().
It should access sample data only event->attr.sample_type allows.
Other fields might not be initialized.

  $ ./vmtest.sh ./test_progs -t perf_event_read_sample
  ...
  #135/1   perf_event_read_sample/perf_event_read_sample_ok:OK
  #135/2   perf_event_read_sample/perf_event_read_sample_invalid:OK
  #135     perf_event_read_sample:OK

Signed-off-by: Namhyung Kim <[email protected]>
kernel-patches-bot pushed a commit that referenced this pull request Dec 21, 2022
@namhyung
selftests/bpf: Add perf_event_read_sample test cases
3627745 
It checks the perf event sample access with bpf_cast_to_kern_ctx().
It should access sample data only event->attr.sample_type allows.
Other fields might not be initialized.

  $ ./vmtest.sh ./test_progs -t perf_event_read_sample
  ...
  #135/1   perf_event_read_sample/perf_event_read_sample_ok:OK
  #135/2   perf_event_read_sample/perf_event_read_sample_invalid:OK
  #135     perf_event_read_sample:OK

Signed-off-by: Namhyung Kim <[email protected]>
kernel-patches-bot pushed a commit that referenced this pull request Dec 21, 2022
@namhyung
selftests/bpf: Add perf_event_read_sample test cases
3312d8b 
It checks the perf event sample access with bpf_cast_to_kern_ctx().
It should access sample data only event->attr.sample_type allows.
Other fields might not be initialized.

  $ ./vmtest.sh ./test_progs -t perf_event_read_sample
  ...
  #135/1   perf_event_read_sample/perf_event_read_sample_ok:OK
  #135/2   perf_event_read_sample/perf_event_read_sample_invalid:OK
  #135     perf_event_read_sample:OK

Signed-off-by: Namhyung Kim <[email protected]>
kernel-patches-daemon-bpf bot pushed a commit that referenced this pull request Aug 17, 2023
@pv @Vudentz
Bluetooth: ISO: do not emit new LE Create CIS if previous is pending
7f74563 
LE Create CIS command shall not be sent before all CIS Established
events from its previous invocation have been processed. Currently it is
sent via hci_sync but that only waits for the first event, but there can
be multiple.

Make it wait for all events, and simplify the CIS creation as follows:

Add new flag HCI_CONN_CREATE_CIS, which is set if Create CIS has been
sent for the connection but it is not yet completed.

Make BT_CONNECT state to mean the connection wants Create CIS.

On events after which new Create CIS may need to be sent, send it if
possible and some connections need it. These events are:
hci_connect_cis, iso_connect_cfm, hci_cs_le_create_cis,
hci_le_cis_estabilished_evt.

The Create CIS status/completion events shall queue new Create CIS only
if at least one of the connections transitions away from BT_CONNECT, so
that we don't loop if controller is sending bogus events.

This fixes sending multiple CIS Create for the same CIS in the
"ISO AC 6(i) - Success" BlueZ test case:

< HCI Command: LE Create Co.. (0x08|0x0064) plen 9  #129 [hci0]
        Number of CIS: 2
        CIS Handle: 257
        ACL Handle: 42
        CIS Handle: 258
        ACL Handle: 42
> HCI Event: Command Status (0x0f) plen 4           #130 [hci0]
      LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1
        Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 29           #131 [hci0]
      LE Connected Isochronous Stream Established (0x19)
        Status: Success (0x00)
        Connection Handle: 257
        ...
< HCI Command: LE Setup Is.. (0x08|0x006e) plen 13  #132 [hci0]
        ...
> HCI Event: Command Complete (0x0e) plen 6         #133 [hci0]
      LE Setup Isochronous Data Path (0x08|0x006e) ncmd 1
        ...
< HCI Command: LE Create Co.. (0x08|0x0064) plen 5  #134 [hci0]
        Number of CIS: 1
        CIS Handle: 258
        ACL Handle: 42
> HCI Event: Command Status (0x0f) plen 4           #135 [hci0]
      LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1
        Status: ACL Connection Already Exists (0x0b)
> HCI Event: LE Meta Event (0x3e) plen 29           #136 [hci0]
      LE Connected Isochronous Stream Established (0x19)
        Status: Success (0x00)
        Connection Handle: 258
        ...

Fixes: c09b80b ("Bluetooth: hci_conn: Fix not waiting for HCI_EVT_LE_CIS_ESTABLISHED")
Signed-off-by: Pauli Virtanen <[email protected]>
Signed-off-by: Luiz Augusto von Dentz <[email protected]>
kernel-patches-daemon-bpf bot pushed a commit that referenced this pull request Dec 19, 2023
@kuba-moo
net: Remove acked SYN flag from packet in the transmit queue correctly
f99cd56 
syzkaller report:

 kernel BUG at net/core/skbuff.c:3452!
 invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.7.0-rc4-00009-gbee0e7762ad2-dirty #135
 RIP: 0010:skb_copy_and_csum_bits (net/core/skbuff.c:3452)
 Call Trace:
 icmp_glue_bits (net/ipv4/icmp.c:357)
 __ip_append_data.isra.0 (net/ipv4/ip_output.c:1165)
 ip_append_data (net/ipv4/ip_output.c:1362 net/ipv4/ip_output.c:1341)
 icmp_push_reply (net/ipv4/icmp.c:370)
 __icmp_send (./include/net/route.h:252 net/ipv4/icmp.c:772)
 ip_fragment.constprop.0 (./include/linux/skbuff.h:1234 net/ipv4/ip_output.c:592 net/ipv4/ip_output.c:577)
 __ip_finish_output (net/ipv4/ip_output.c:311 net/ipv4/ip_output.c:295)
 ip_output (net/ipv4/ip_output.c:427)
 __ip_queue_xmit (net/ipv4/ip_output.c:535)
 __tcp_transmit_skb (net/ipv4/tcp_output.c:1462)
 __tcp_retransmit_skb (net/ipv4/tcp_output.c:3387)
 tcp_retransmit_skb (net/ipv4/tcp_output.c:3404)
 tcp_retransmit_timer (net/ipv4/tcp_timer.c:604)
 tcp_write_timer (./include/linux/spinlock.h:391 net/ipv4/tcp_timer.c:716)

The panic issue was trigered by tcp simultaneous initiation.
The initiation process is as follows:

      TCP A                                            TCP B

  1.  CLOSED                                           CLOSED

  2.  SYN-SENT     --> <SEQ=100><CTL=SYN>              ...

  3.  SYN-RECEIVED <-- <SEQ=300><CTL=SYN>              <-- SYN-SENT

  4.               ... <SEQ=100><CTL=SYN>              --> SYN-RECEIVED

  5.  SYN-RECEIVED --> <SEQ=100><ACK=301><CTL=SYN,ACK> ...

  // TCP B: not send challenge ack for ack limit or packet loss
  // TCP A: close
	tcp_close
	   tcp_send_fin
              if (!tskb && tcp_under_memory_pressure(sk))
                  tskb = skb_rb_last(&sk->tcp_rtx_queue); //pick SYN_ACK packet
           TCP_SKB_CB(tskb)->tcp_flags |= TCPHDR_FIN;  // set FIN flag

  6.  FIN_WAIT_1  --> <SEQ=100><ACK=301><END_SEQ=102><CTL=SYN,FIN,ACK> ...

  // TCP B: send challenge ack to SYN_FIN_ACK

  7.               ... <SEQ=301><ACK=101><CTL=ACK>   <-- SYN-RECEIVED //challenge ack

  // TCP A:  <SND.UNA=101>

  8.  FIN_WAIT_1 --> <SEQ=101><ACK=301><END_SEQ=102><CTL=SYN,FIN,ACK> ... // retransmit panic

	__tcp_retransmit_skb  //skb->len=0
	    tcp_trim_head
		len = tp->snd_una - TCP_SKB_CB(skb)->seq // len=101-100
		    __pskb_trim_head
			skb->data_len -= len // skb->len=-1, wrap around
	    ... ...
	    ip_fragment
		icmp_glue_bits //BUG_ON

If we use tcp_trim_head() to remove acked SYN from packet that contains data
or other flags, skb->len will be incorrectly decremented. We can remove SYN
flag that has been acked from rtx_queue earlier than tcp_trim_head(), which
can fix the problem mentioned above.

Fixes: 1da177e ("Linux-2.6.12-rc2")
Co-developed-by: Eric Dumazet <[email protected]>
Signed-off-by: Eric Dumazet <[email protected]>
Signed-off-by: Dong Chenchen <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
accepted bpf-next V2
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
1 participant
@kernel-patches-bot