Skip to content

Conversation

@mozesslackware
Copy link

No description provided.

bjorn-helgaas and others added 30 commits February 15, 2017 11:56
* pci/host-exynos:
  PCI: exynos: Refactor to make it easier to support other SoCs
  PCI: exynos: Remove duplicated code
  PCI: exynos: Use the bitops BIT() macro to build bitmasks
  PCI: exynos: Remove unnecessary local variables
  PCI: exynos: Replace the *_blk/*_phy/*_elb accessors
  PCI: exynos: Rename all pointer names from "exynos_pcie" to "ep"
* pci/host-hisi:
  PCI: generic: Call pci_fixup_irqs() only on ARM
  PCI: Disable MSI for HiSilicon Hip06/Hip07 Root Ports
  PCI: hisi: Rename config space accessors to remove "acpi"
  PCI: hisi: Add DT almost-ECAM support for Hip06/Hip07 host controllers
  PCI: hisi: Use of_device_get_match_data() to simplify probe
* pci/host-hv:
  PCI: hv: Fix wslot_to_devfn() to fix warnings on device removal
The buffered write failure handling code in
xfs_file_iomap_end_delalloc() has a couple minor problems. First, if
written == 0, start_fsb is not rounded down and it fails to kill off a
delalloc block if the start offset is block unaligned. This results in a
lingering delalloc block and broken delalloc block accounting detected
at unmount time. Fix this by rounding down start_fsb in the unlikely
event that written == 0.

Second, it is possible for a failed overwrite of a delalloc extent to
leave dirty pagecache around over a hole in the file. This is because is
possible to hit ->iomap_end() on write failure before the iomap code has
attempted to allocate pagecache, and thus has no need to clean it up. If
the targeted delalloc extent was successfully written by a previous
write, however, then it does still have dirty pages when ->iomap_end()
punches out the underlying blocks. This ultimately results in writeback
over a hole. To fix this problem, unconditionally punch out the
pagecache from XFS before the associated delalloc range.

Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
A debug mode write failure mechanism was introduced to XFS in commit
801cc4e ("xfs: debug mode forced buffered write failure") to
facilitate targeted testing of delalloc indirect reservation management
from userspace. This code was subsequently rendered ineffective by the
move to iomap based buffered writes in commit 68a9f5e ("xfs:
implement iomap based buffered write path"). This likely went unnoticed
because the associated userspace code had not made it into xfstests.

Resurrect this mechanism to facilitate effective indlen reservation
testing from xfstests. The move to iomap based buffered writes relocated
the hook this mechanism needs to return write failure from XFS to
generic code. The failure trigger must remain in XFS. Given that
limitation, convert this from a write failure mechanism to one that
simply drops writes without returning failure to userspace. Rename all
"fail_writes" references to "drop_writes" to illustrate the point. This
is more hacky than preferred, but still triggers the XFS error handling
behavior required to drive the indlen tests. This is only available in
DEBUG mode and for testing purposes only.

Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
When a delalloc extent is created, it can be merged with pre-existing,
contiguous, delalloc extents. When this occurs,
xfs_bmap_add_extent_hole_delay() merges the extents along with the
associated indirect block reservations. The expectation here is that the
combined worst case indlen reservation is always less than or equal to
the indlen reservation for the individual extents.

This is not always the case, however, as existing extents can less than
the expected indlen reservation if the extent was previously split due
to a hole punch. If a new extent merges with such an extent, the total
indlen requirement may be larger than the sum of the indlen reservations
held by both extents.

xfs_bmap_add_extent_hole_delay() assumes that the worst case indlen
reservation is always available and assigns it to the merged extent
without consideration for the indlen held by the pre-existing extent. As
a result, the subsequent xfs_mod_fdblocks() call can attempt an
unintentional allocation rather than a free (indicated by an ASSERT()
failure). Further, if the allocation happens to fail in this context,
the failure goes unhandled and creates a filesystem wide block
accounting inconsistency.

Fix xfs_bmap_add_extent_hole_delay() to function as designed. Cap the
indlen reservation assigned to the merged extent to the sum of the
indlen reservations held by each of the individual extents.

Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Certain workoads that punch holes into speculative preallocation can
cause delalloc indirect reservation splits when the delalloc extent is
split in two. If further splits occur, an already short-handed extent
can be split into two in a manner that leaves zero indirect blocks for
one of the two new extents. This occurs because the shortage is large
enough that the xfs_bmap_split_indlen() algorithm completely drains the
requested indlen of one of the extents before it honors the existing
reservation.

This ultimately results in a warning from xfs_bmap_del_extent(). This
has been observed during file copies of large, sparse files using 'cp
--sparse=always.'

To avoid this problem, update xfs_bmap_split_indlen() to explicitly
apply the reservation shortage fairly between both extents. This smooths
out the overall indlen shortage and defers the situation where we end up
with a delalloc extent with zero indlen reservation to extreme
circumstances.

Reported-by: Patrick Dung <mpatdung@gmail.com>
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Fix an uninitialize variable.

Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
The length is now passed by reference, so the assertion has to be updated
to match the other changes, as pointed out by this W=1 warning:

fs/xfs/xfs_extent_busy.c: In function 'xfs_extent_busy_trim':
fs/xfs/xfs_extent_busy.c:356:13: error: ordered comparison of pointer with integer zero [-Werror=extra]

Fixes: ebf5587 ("xfs: improve handling of busy extents in the low-level allocator")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Replace all occurrences of sprintf with scnprintf in coresight driver for
consistency. scnprintf is also a safer alternative to sprintf.

Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
cntr_val_show function does not print the intended information. It is only
printing the latest counter value. Fix this.

Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
md still need bio clone(not the fast version) for behind write,
and it is more efficient to use bio_clone_bioset_partial().

The idea is simple and just copy the bvecs range specified from
parameters.

Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: Shaohua Li <shli@fb.com>
The current behaviour is to fall back to allocate
bio from 'fs_bio_set', that isn't a correct way
because it might cause deadlock.

So this patch simply return failure if mddev->bio_set
can't be created.

Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: Shaohua Li <shli@fb.com>
Write behind need to replace pages in bio's bvecs, and we have
to clone a fresh bio with new bvec table, so use the introduced
bio_clone_bioset_partial() for it.

For other bio_clone_mddev() cases, we will use fast clone since
they don't need to touch bvec table.

Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: Shaohua Li <shli@fb.com>
mddev is never NULL and neither is ->bio_set, so
remove the check.

Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: Shaohua Li <shli@fb.com>
Firstly bio_clone_mddev() is used in raid normal I/O and isn't
in resync I/O path.

Secondly all the direct access to bvec table in raid happens on
resync I/O except for write behind of raid1, in which we still
use bio_clone() for allocating new bvec table.

So this patch replaces bio_clone() with bio_clone_fast()
in bio_clone_mddev().

Also kill bio_clone_mddev() and call bio_clone_fast() directly, as
suggested by Christoph Hellwig.

Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: Shaohua Li <shli@fb.com>
Like for Sunrise Point, the total stream number of Lewisburg's
input and output stream exceeds 15 (GCAP is 0x9701), which will
cause some streams do not work because of the overflow on
SDxCTL.STRM field if using the legacy stream tag allocation method.

Fixes: 5cf92c8 ("ALSA: hda - Add Intel Lewisburg device IDs Audio")
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
It seems that newer Intel chipsets have more than 15 I/O streams (total).
This patch forces the separate stream tags, when this hardware is detected
to avoid SDxCTL.STRM field overflow and an unexpected behaviour.

Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
* v4.10/fixes:
  ARM64: dts: meson-gx: Add firmware reserved memory zones
  ARM64: dts: meson-gxbb-odroidc2: fix GbE tx link breakage
  ARM64: dts: meson-gxbb-odroidc2: Disable SCPI DVFS
Waiman-Long and others added 24 commits February 16, 2017 15:10
On a large SMP system with many CPUs, the global pool_lock may become a
performance bottleneck as all the CPUs that need to allocate or free debug
objects have to take the lock.  That can sometimes cause soft lockups
like:

 NMI watchdog: BUG: soft lockup - CPU#35 stuck for 22s! [rcuos/1:21]
 ...
 RIP: 0010:[<ffffffff817c216b>]  [<ffffffff817c216b>]
	_raw_spin_unlock_irqrestore+0x3b/0x60
 ...
 Call Trace:
  [<ffffffff813f40d1>] free_object+0x81/0xb0
  [<ffffffff813f4f33>] debug_check_no_obj_freed+0x193/0x220
  [<ffffffff81101a59>] ? trace_hardirqs_on_caller+0xf9/0x1c0
  [<ffffffff81284996>] ? file_free_rcu+0x36/0x60
  [<ffffffff81251712>] kmem_cache_free+0xd2/0x380
  [<ffffffff81284960>] ? fput+0x90/0x90
  [<ffffffff81284996>] file_free_rcu+0x36/0x60
  [<ffffffff81124c23>] rcu_nocb_kthread+0x1b3/0x550
  [<ffffffff81124b71>] ? rcu_nocb_kthread+0x101/0x550
  [<ffffffff81124a70>] ? sync_exp_work_done.constprop.63+0x50/0x50
  [<ffffffff810c59d1>] kthread+0x101/0x120
  [<ffffffff81101a59>] ? trace_hardirqs_on_caller+0xf9/0x1c0
  [<ffffffff817c2d32>] ret_from_fork+0x22/0x50

To reduce the amount of contention on the pool_lock, the actual
kmem_cache_free() of the debug objects will be delayed if the pool_lock is
busy.  This will temporarily increase the amount of free objects available
at the free pool when the system is busy.  As a result, the number of
kmem_cache allocation and freeing should be reduced.

This patch also groups the freeing of debug objects in a batch of 4 to
reduce the total number of lock/unlock cycles.

Link: http://lkml.kernel.org/r/1483647425-4135-4-git-send-email-longman@redhat.com
Signed-off-by: Waiman Long <longman@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "Du Changbin" <changbin.du@intel.com>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Jan Stancek <jstancek@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
For dwmac-sun8i, some actions must be done for enabling attached PHY.
Thoses actions must be done after stmmac_probe_config_dt() and
at start of stmmac_init_phy().

The best way to handle that is to add an optional init_phy() function.

Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
Thoses symbol will be needed for the dwmac-sun8i ethernet driver.
For letting it to be build as module, they need to be exported.

Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
Instead of ading more ifthen login for adding a new mac_device_info
setup function, it is easier to add a function pointer to the function
needed.

Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
This patch adds documentation for Device-Tree bindings for the
Allwinner dwmac-sun8i driver.

Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
The dwmac-sun8i is a heavy hacked version of stmmac hardware by
allwinner.
In fact the only common part is the descriptor management and the first
register function.

Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
This patch add the dt node for the syscon register present on the
Allwinner H3.

Only two register are present in this syscon and the only one useful is
the one dedicated to EMAC clock.

Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
The dwmac-sun8i is an ethernet MAC hardware that support 10/100/1000
speed.

This patch enable the dwmac-sun8i on the Allwinner H3 SoC Device-tree.
The SoC H3 have an internal PHY, so optionals syscon and ephy are set.

Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
This patch add pinctrl node for dwmac-sun8i on H3.

Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
The dwmac-sun8i hardware is present on the Banana Pi M2+
It uses an external PHY rtl8211e via RGMII.

This patch create the needed regulator, emac and phy nodes.

Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
The dwmac-sun8i hardware is present on the Orange PI PC.
It uses the internal PHY.

This patch create the needed emac node.

Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
The dwmac-sun8i hardware is present on the Orange PI 2.
It uses the internal PHY.

This patch create the needed emac node.

Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
The dwmac-sun8i hardware is present on the Orange PI One.
It uses the internal PHY.

This patch create the needed emac node.

Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
The dwmac-sun8i hardware is present on the Orange PI plus.
It uses an external PHY rtl8211e via RGMII.

This patch create the needed regulator, emac and phy nodes.

Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
On the Orange Pi PC Plus, the polarity of the LEDs on the RJ45 Ethernet
port were changed from active low to active high.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
This patch add the dt node for the syscon register present on the
Allwinner A64.

Only two register are present in this syscon and the only one useful is
the one dedicated to EMAC clock.

Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
The dwmac-sun8i is an Ethernet MAC that supports 10/100/1000 Mbit
connections. It is very similar to the device found in the Allwinner
H3, but lacks the internal 100 Mbit PHY and its associated control
bits.
This adds the necessary bits to the Allwinner A64 SoC .dtsi, but keeps
it disabled at this level.

Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
The dwmac-sun8i hardware is present on the pine64
It uses an external PHY via RMII.

Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
The dwmac-sun8i hardware is present on the pine64 plus.
It uses an external PHY rtl8211e via RGMII.

Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
The dwmac-sun8i  hardware is present on the BananaPi M64.
It uses an external PHY rtl8211e via RGMII.

Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
Enable the dwmac-sun8i driver in the sunxi default configuration

Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
Enable the dwmac-sun8i driver in the multi_v7 default configuration

Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
@KernelPRBot
Copy link

Hi @mozesslackware!

Thanks for your contribution to the Linux kernel!

Linux kernel development happens on mailing lists, rather than on GitHub - this GitHub repository is a read-only mirror that isn't used for accepting contributions. So that your change can become part of Linux, please email it to us as a patch.

Sending patches isn't quite as simple as sending a pull request, but fortunately it is a well documented process.

Here's what to do:

  • Format your contribution according to kernel requirements
  • Decide who to send your contribution to
  • Set up your system to send your contribution as an email
  • Send your contribution and wait for feedback

How do I format my contribution?

The Linux kernel community is notoriously picky about how contributions are formatted and sent. Fortunately, they have documented their expectations.

Firstly, all contributions need to be formatted as patches. A patch is a plain text document showing the change you want to make to the code, and documenting why it is a good idea.

You can create patches with git format-patch.

Secondly, patches need 'commit messages', which is the human-friendly documentation explaining what the change is and why it's necessary.

Thirdly, changes have some technical requirements. There is a Linux kernel coding style, and there are licensing requirements you need to comply with.

Both of these are documented in the Submitting Patches documentation that is part of the kernel.

Note that you will almost certainly have to modify your existing git commits to satisfy these requirements. Don't worry: there are many guides on the internet for doing this.

Who do I send my contribution to?

The Linux kernel is composed of a number of subsystems. These subsystems are maintained by different people, and have different mailing lists where they discuss proposed changes.

If you don't already know what subsystem your change belongs to, the get_maintainer.pl script in the kernel source can help you.

get_maintainer.pl will take the patch or patches you created in the previous step, and tell you who is responsible for them, and what mailing lists are used. You can also take a look at the MAINTAINERS file by hand.

Make sure that your list of recipients includes a mailing list. If you can't find a more specific mailing list, then LKML - the Linux Kernel Mailing List - is the place to send your patches.

It's not usually necessary to subscribe to the mailing list before you send the patches, but if you're interested in kernel development, subscribing to a subsystem mailing list is a good idea. (At this point, you probably don't need to subscribe to LKML - it is a very high traffic list with about a thousand messages per day, which is often not useful for beginners.)

How do I send my contribution?

Use git send-email, which will ensure that your patches are formatted in the standard manner. In order to use git send-email, you'll need to configure git to use your SMTP email server.

For more information about using git send-email, look at the Git documentation or type git help send-email. There are a number of useful guides and tutorials about git send-email that can be found on the internet.

How do I get help if I'm stuck?

Firstly, don't get discouraged! There are an enormous number of resources on the internet, and many kernel developers who would like to see you succeed.

Many issues - especially about how to use certain tools - can be resolved by using your favourite internet search engine.

If you can't find an answer, there are a few places you can turn:

  • Kernel Newbies - this website contains a lot of useful resources for new kernel developers.
  • If you'd like a step-by-step, challenge-based introduction to kernel development, the Eudyptula Challenge would be an excellent start.
  • The kernel documentation - see also the Documentation directory in the kernel tree.

If you get really, really stuck, you could try the owners of this bot, @daxtens and @ajdlinux. Please be aware that we do have full-time jobs, so we are almost certainly the slowest way to get answers!

I sent my patch - now what?

You wait.

You can check that your email has been received by checking the mailing list archives for the mailing list you sent your patch to. Messages may not be received instantly, so be patient. Kernel developers are generally very busy people, so it may take a few weeks before your patch is looked at.

Then, you keep waiting. Three things may happen:

  • You might get a response to your email. Often these will be comments, which may require you to make changes to your patch, or explain why your way is the best way. You should respond to these comments, and you may need to submit another revision of your patch to address the issues raised.
  • Your patch might be merged into the subsystem tree. Code that becomes part of Linux isn't merged into the main repository straight away - it first goes into the subsystem tree, which is managed by the subsystem maintainer. It is then batched up with a number of other changes sent to Linus for inclusion. (This process is described in some detail in the kernel development process guide).
  • Your patch might be ignored completely. This happens sometimes - don't take it personally. Here's what to do:
    • Wait a bit more - patches often take several weeks to get a response; more if they were sent at a busy time.
    • Kernel developers often silently ignore patches that break the rules. Check for obvious violations of the the Submitting Patches guidelines, the style guidelines, and any other documentation you can find about your subsystem. Check that you're sending your patch to the right place.
    • Try again later. When you resend it, don't add angry commentary, as that will get your patch ignored. It might also get you silently blacklisted.

Further information

Happy hacking!

This message was posted by a bot - if you have any questions or suggestions, please talk to my owners, @ajdlinux and @daxtens, or raise an issue at https://github.com/ajdlinux/KernelPRBot.

@montjoie montjoie deleted the stmmac-sun8i-wip-next-20170216 branch March 13, 2017 09:46
ojeda added a commit to ojeda/linux that referenced this pull request Jun 29, 2021
rust: require mutable references when initialising sync primitives.
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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.