-
Notifications
You must be signed in to change notification settings - Fork 58.5k
mips checksum error -- csum_tcpudp_nofold #385
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
Closed
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
If the input parameters as saddr = 0xc0a8fd60,daddr = 0xc0a8fda1,len = 80, proto = 17, sum =0x7eae049d. The correct result should be 1, but original function return 0.
|
Linus does not take PRs on here, see the rest of the PRs here and this: |
Mic92
pushed a commit
to Mic92/linux
that referenced
this pull request
Feb 4, 2019
lkl: Support json configuration and multiple interfaces
TheSven73
pushed a commit
to TheSven73/linux
that referenced
this pull request
Jun 22, 2021
Restore `rustdoc` section with the correct instruction
akiernan
pushed a commit
to zuma-array/linux
that referenced
this pull request
Nov 4, 2022
PD#150094: driver defect clean up: torvalds#32 torvalds#86 torvalds#90 torvalds#92 torvalds#97 torvalds#101 torvalds#103 torvalds#152 torvalds#155 torvalds#157~torvalds#158 torvalds#164 torvalds#167 torvalds#169~torvalds#179 torvalds#187~torvalds#191 torvalds#193~torvalds#199 torvalds#201~torvalds#210 torvalds#212~torvalds#213 torvalds#316~torvalds#319 torvalds#385 torvalds#572 torvalds#693~torvalds#694 torvalds#696~torvalds#697 Change-Id: I9669e5c0d717ee2287faf57a271ff27692039802 Signed-off-by: Guosong Zhou <guosong.zhou@amlogic.com>
yhamamachi
pushed a commit
to yhamamachi/linux-pcie-virtio-net
that referenced
this pull request
Sep 3, 2024
commit e2c8b87 moved modeset locking inside resume/suspend functions, but missed a code path only executed on lid close/open on older hardware. The result was a deadlock when closing and opening the lid without suspending on such hardware: ============================================= [ INFO: possible recursive locking detected ] 4.6.0-rc1 torvalds#385 Not tainted --------------------------------------------- kworker/0:3/88 is trying to acquire lock: (&dev->mode_config.mutex){+.+.+.}, at: [<ffffffffa063e6a4>] intel_display_resume+0x4a/0x12f [i915] but task is already holding lock: (&dev->mode_config.mutex){+.+.+.}, at: [<ffffffffa02d0d4f>] drm_modeset_lock_all+0x3e/0xa6 [drm] other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&dev->mode_config.mutex); lock(&dev->mode_config.mutex); *** DEADLOCK *** May be due to missing lock nesting notation 7 locks held by kworker/0:3/88: #0: ("kacpi_notify"){++++.+}, at: [<ffffffff81068dfc>] process_one_work+0x14a/0x50b #1: ((&dpc->work)#2){+.+.+.}, at: [<ffffffff81068dfc>] process_one_work+0x14a/0x50b #2: ((acpi_lid_notifier).rwsem){++++.+}, at: [<ffffffff8106f874>] __blocking_notifier_call_chain+0x34/0x65 #3: (&dev_priv->modeset_restore_lock){+.+.+.}, at: [<ffffffffa0664cf6>] intel_lid_notify+0x3c/0xd9 [i915] #4: (&dev->mode_config.mutex){+.+.+.}, at: [<ffffffffa02d0d4f>] drm_modeset_lock_all+0x3e/0xa6 [drm] #5: (crtc_ww_class_acquire){+.+.+.}, at: [<ffffffffa02d0d59>] drm_modeset_lock_all+0x48/0xa6 [drm] torvalds#6: (crtc_ww_class_mutex){+.+.+.}, at: [<ffffffffa02d0b2a>] modeset_lock+0x13c/0x1cd [drm] stack backtrace: CPU: 0 PID: 88 Comm: kworker/0:3 Not tainted 4.6.0-rc1 torvalds#385 Hardware name: LENOVO 2776LEG/2776LEG, BIOS 6EET55WW (3.15 ) 12/19/2011 Workqueue: kacpi_notify acpi_os_execute_deferred 0000000000000000 ffff88022fd5f990 ffffffff8124af06 ffffffff825b39c0 ffffffff825b39c0 ffff88022fd5fa60 ffffffff8108f547 ffff88022fd5fa70 000000008108e817 ffff880230236cc0 0000000000000000 ffffffff825b39c0 Call Trace: [<ffffffff8124af06>] dump_stack+0x67/0x90 [<ffffffff8108f547>] __lock_acquire+0xdb5/0xf71 [<ffffffff8108bd2c>] ? look_up_lock_class+0xbe/0x10a [<ffffffff8108fae2>] lock_acquire+0x137/0x1cb [<ffffffff8108fae2>] ? lock_acquire+0x137/0x1cb [<ffffffffa063e6a4>] ? intel_display_resume+0x4a/0x12f [i915] [<ffffffff8148202f>] mutex_lock_nested+0x7e/0x3a4 [<ffffffffa063e6a4>] ? intel_display_resume+0x4a/0x12f [i915] [<ffffffffa063e6a4>] ? intel_display_resume+0x4a/0x12f [i915] [<ffffffffa02d0b2a>] ? modeset_lock+0x13c/0x1cd [drm] [<ffffffffa063e6a4>] intel_display_resume+0x4a/0x12f [i915] [<ffffffffa063e6a4>] ? intel_display_resume+0x4a/0x12f [i915] [<ffffffffa02d0b2a>] ? modeset_lock+0x13c/0x1cd [drm] [<ffffffffa02d0b2a>] ? modeset_lock+0x13c/0x1cd [drm] [<ffffffffa02d0bf7>] ? drm_modeset_lock+0x17/0x24 [drm] [<ffffffffa02d0c8b>] ? drm_modeset_lock_all_ctx+0x87/0xa1 [drm] [<ffffffffa0664d6a>] intel_lid_notify+0xb0/0xd9 [i915] [<ffffffff8106f4c6>] notifier_call_chain+0x4a/0x6c [<ffffffff8106f88d>] __blocking_notifier_call_chain+0x4d/0x65 [<ffffffff8106f8b9>] blocking_notifier_call_chain+0x14/0x16 [<ffffffffa0011215>] acpi_lid_send_state+0x83/0xad [button] [<ffffffffa00112a6>] acpi_button_notify+0x41/0x132 [button] [<ffffffff812b07df>] acpi_device_notify+0x19/0x1b [<ffffffff812c8570>] acpi_ev_notify_dispatch+0x49/0x64 [<ffffffff812ab9fb>] acpi_os_execute_deferred+0x14/0x20 [<ffffffff81068f17>] process_one_work+0x265/0x50b [<ffffffff810696f5>] worker_thread+0x1fc/0x2dd [<ffffffff810694f9>] ? rescuer_thread+0x309/0x309 [<ffffffff810694f9>] ? rescuer_thread+0x309/0x309 [<ffffffff8106e2d6>] kthread+0xe0/0xe8 [<ffffffff8107bc47>] ? local_clock+0x19/0x22 [<ffffffff81484f42>] ret_from_fork+0x22/0x40 [<ffffffff8106e1f6>] ? kthread_create_on_node+0x1b5/0x1b5 Fixes: e2c8b87 ("drm/i915: Use atomic helpers for suspend, v2.") Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459328913-13719-1-git-send-email-bjorn@mork.no (cherry picked from commit 9f54d4b) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Nov 17, 2025
During OBEX Abort command, iOS may return an incomplete SDU packet which ends with the reply to the Abort command. During OBEX Abort command, iOS may return the L2CAP_SAR_END packet before the normal end of the SAR packets: < ACL Data TX: Handle 21 [2/8] flags 0x00 dlen 11 torvalds#194 [hci0] 14.923741 Channel: 3080 len 7 ctrl 0x060a [PSM 4101 mode Enhanced Retransmission (0x03)] {chan 0} I-frame: Unsegmented TxSeq 5 ReqSeq 6 0a 06 ff 00 03 47 84 .....G. ... > ACL Data RX: Handle 21 flags 0x01 dlen 458 torvalds#382 [hci0] 19.701854 Channel: 65 len 1006 ctrl 0x460e [PSM 4101 mode Enhanced Retransmission (0x03)] {chan 0} I-frame: Start (len 32767) TxSeq 7 ReqSeq 6 0e 46 ff 7f 90 7f ff 48 7f fc 43 48 41 52 53 45 .F.....H..CHARSE ... > ACL Data RX: Handle 21 flags 0x02 dlen 552 torvalds#383 [hci0] 19.701854 > ACL Data RX: Handle 21 flags 0x01 dlen 458 torvalds#384 [hci0] 19.755918 Channel: 65 len 1006 ctrl 0xc610 [PSM 4101 mode Enhanced Retransmission (0x03)] {chan 0} I-frame: Continuation TxSeq 8 ReqSeq 6 10 c6 6e 6f 73 61 69 72 65 73 64 65 73 69 67 6e ..nosairesdesign ... > ACL Data RX: Handle 21 flags 0x02 dlen 552 torvalds#385 [hci0] 19.775016 > ACL Data RX: Handle 21 flags 0x01 dlen 458 torvalds#386 [hci0] 19.775024 Channel: 65 len 1006 ctrl 0xc612 [PSM 4101 mode Enhanced Retransmission (0x03)] {chan 0} I-frame: Continuation TxSeq 9 ReqSeq 6 12 c6 69 63 6f 20 43 69 74 79 20 54 65 63 68 20 ..ico City Tech ... > ACL Data RX: Handle 21 flags 0x02 dlen 552 torvalds#387 [hci0] 19.775024 > ACL Data RX: Handle 21 flags 0x01 dlen 458 torvalds#388 [hci0] 19.821542 Channel: 65 len 1006 ctrl 0xc614 [PSM 4101 mode Enhanced Retransmission (0x03)] {chan 0} I-frame: Continuation TxSeq 10 ReqSeq 6 14 c6 6c 74 69 6e 67 20 50 61 72 74 6e 65 72 0d ..lting Partner. ... > ACL Data RX: Handle 21 flags 0x02 dlen 552 torvalds#389 [hci0] 19.821610 > ACL Data RX: Handle 21 flags 0x01 dlen 458 torvalds#390 [hci0] 19.821610 Channel: 65 len 1006 ctrl 0xc616 [PSM 4101 mode Enhanced Retransmission (0x03)] {chan 0} I-frame: Continuation TxSeq 11 ReqSeq 6 16 c6 6c 74 69 6e 67 2e 63 6f 6d 0d 0a 55 49 44 ..lting.com..UID ... > ACL Data RX: Handle 21 flags 0x02 dlen 11 torvalds#391 [hci0] 19.821610 Channel: 65 len 7 ctrl 0x8618 [PSM 4101 mode Enhanced Retransmission (0x03)] {chan 0} I-frame: End TxSeq 12 ReqSeq 6 18 86 a0 00 03 3e 5d .....>] < ACL Data TX: Handle 21 [1/8] flags 0x00 dlen 12 torvalds#392 [hci0] 19.822491 L2CAP: Disconnection Request (0x06) ident 10 len 4 Destination CID: 3080 Source CID: 65 In this case the re-assembled packet should be 32767 bytes as defined in Start packet (torvalds#382), i.e. 33 segmented packets, but the End packet is sent as the 6th packet. The l2cap_reassemble_sdu() function returns error -EINVAL if reassembled packet size != expected size, triggering the L2CAP disconnection, which disconnects the OBEX session, preventing further OBEX actions. Log this, discard previous segmented packet data and only send data from SAR End packet to upstream. Closes: bluez/bluetooth-next#17 Signed-off-by: Frédéric Danis <frederic.danis@collabora.com>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Nov 17, 2025
During OBEX Abort command, iOS may return an incomplete SDU packet which ends with the reply to the Abort command. During OBEX Abort command, iOS may return the L2CAP_SAR_END packet before the normal end of the SAR packets: < ACL Data TX: Handle 21 [2/8] flags 0x00 dlen 11 torvalds#194 [hci0] 14.923741 Channel: 3080 len 7 ctrl 0x060a [PSM 4101 mode Enhanced Retransmission (0x03)] {chan 0} I-frame: Unsegmented TxSeq 5 ReqSeq 6 0a 06 ff 00 03 47 84 .....G. ... > ACL Data RX: Handle 21 flags 0x01 dlen 458 torvalds#382 [hci0] 19.701854 Channel: 65 len 1006 ctrl 0x460e [PSM 4101 mode Enhanced Retransmission (0x03)] {chan 0} I-frame: Start (len 32767) TxSeq 7 ReqSeq 6 0e 46 ff 7f 90 7f ff 48 7f fc 43 48 41 52 53 45 .F.....H..CHARSE ... > ACL Data RX: Handle 21 flags 0x02 dlen 552 torvalds#383 [hci0] 19.701854 > ACL Data RX: Handle 21 flags 0x01 dlen 458 torvalds#384 [hci0] 19.755918 Channel: 65 len 1006 ctrl 0xc610 [PSM 4101 mode Enhanced Retransmission (0x03)] {chan 0} I-frame: Continuation TxSeq 8 ReqSeq 6 10 c6 6e 6f 73 61 69 72 65 73 64 65 73 69 67 6e ..nosairesdesign ... > ACL Data RX: Handle 21 flags 0x02 dlen 552 torvalds#385 [hci0] 19.775016 > ACL Data RX: Handle 21 flags 0x01 dlen 458 torvalds#386 [hci0] 19.775024 Channel: 65 len 1006 ctrl 0xc612 [PSM 4101 mode Enhanced Retransmission (0x03)] {chan 0} I-frame: Continuation TxSeq 9 ReqSeq 6 12 c6 69 63 6f 20 43 69 74 79 20 54 65 63 68 20 ..ico City Tech ... > ACL Data RX: Handle 21 flags 0x02 dlen 552 torvalds#387 [hci0] 19.775024 > ACL Data RX: Handle 21 flags 0x01 dlen 458 torvalds#388 [hci0] 19.821542 Channel: 65 len 1006 ctrl 0xc614 [PSM 4101 mode Enhanced Retransmission (0x03)] {chan 0} I-frame: Continuation TxSeq 10 ReqSeq 6 14 c6 6c 74 69 6e 67 20 50 61 72 74 6e 65 72 0d ..lting Partner. ... > ACL Data RX: Handle 21 flags 0x02 dlen 552 torvalds#389 [hci0] 19.821610 > ACL Data RX: Handle 21 flags 0x01 dlen 458 torvalds#390 [hci0] 19.821610 Channel: 65 len 1006 ctrl 0xc616 [PSM 4101 mode Enhanced Retransmission (0x03)] {chan 0} I-frame: Continuation TxSeq 11 ReqSeq 6 16 c6 6c 74 69 6e 67 2e 63 6f 6d 0d 0a 55 49 44 ..lting.com..UID ... > ACL Data RX: Handle 21 flags 0x02 dlen 11 torvalds#391 [hci0] 19.821610 Channel: 65 len 7 ctrl 0x8618 [PSM 4101 mode Enhanced Retransmission (0x03)] {chan 0} I-frame: End TxSeq 12 ReqSeq 6 18 86 a0 00 03 3e 5d .....>] < ACL Data TX: Handle 21 [1/8] flags 0x00 dlen 12 torvalds#392 [hci0] 19.822491 L2CAP: Disconnection Request (0x06) ident 10 len 4 Destination CID: 3080 Source CID: 65 In this case the re-assembled packet should be 32767 bytes as defined in Start packet (torvalds#382), i.e. 33 segmented packets, but the End packet is sent as the 6th packet. The l2cap_reassemble_sdu() function returns error -EINVAL if reassembled packet size != expected size, triggering the L2CAP disconnection, which disconnects the OBEX session, preventing further OBEX actions. Log this, discard previous segmented packet data and only send data from SAR End packet to upstream. Closes: bluez/bluetooth-next#17 Signed-off-by: Frédéric Danis <frederic.danis@collabora.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
If the input parameters as saddr = 0xc0a8fd60,daddr = 0xc0a8fda1,len = 80, proto = 17, sum =0x7eae049d.
The correct result should be 1, but original function return 0.