lsattr 32bit does not work on 64bit kernel (Inappropriate ioctl error)

This is not an e2fsprogs bug, but a bug in the kernel. The fix is in mainline as of v4.7, commit id: 4c63c2454eff996. It needs to be ported to the Ubuntu Trusted (and other Ubuntu LTS) kernels.

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1619918

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Rolf, can you collect the requested logs? I think this is pointless since it's pretty clear that there's a commit that just needs to be backported, but that's between use and the Ubuntu Kernel team to figure out. Or you can just use the upstream 4.7 kernel. :-)

Commit 02da2d72174c61988eb4456b53f405e3ebdebce4 merged in v4.7

https://lists.ubuntu.com/archives/kernel-team/2016-September/079897.html

Test kernel at http://people.canonical.com/~rtg/lsattr-lp1619918/

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-trusty' to 'verification-done-trusty'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-vivid' to 'verification-done-vivid'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-xenial' to 'verification-done-xenial'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

Thanks. This works well in trusty.

I think there might be a regression with this kernel. "sudo btrfs fi show" no longer works and only puts out "Btrfs v3.12"

Yes, regression from -96 to -97 verified on trusty.

This bug was fixed in the package linux - 4.4.0-42.62

---------------
linux (4.4.0-42.62) xenial; urgency=low

  * Fix GRO recursion overflow for tunneling protocols (LP: #1631287)
    - tunnels: Don't apply GRO to multiple layers of encapsulation.
    - gro: Allow tunnel stacking in the case of FOU/GUE

  * CVE-2016-7039
    - SAUCE: net: add recursion limit to GRO

linux (4.4.0-41.61) xenial; urgency=low

  [ Kamal Mostafa ]

  * Release Tracking Bug
    - LP: #1628204

  * nvme drive probe failure (LP: #1626894)
    - (fix) NVMe: Don't unmap controller registers on reset

linux (4.4.0-40.60) xenial; urgency=low

  [ Kamal Mostafa ]

  * Release Tracking Bug
    - LP: #1627074

  * Permission denied in CIFS with kernel 4.4.0-38 (LP: #1626112)
    - Fix memory leaks in cifs_do_mount()
    - Compare prepaths when comparing superblocks
    - SAUCE: Fix regression which breaks DFS mounting

  * Backlight does not change when adjust it higher than 50% after S3
    (LP: #1625932)
    - SAUCE: i915_bpo: drm/i915/backlight: setup and cache pwm alternate
      increment value
    - SAUCE: i915_bpo: drm/i915/backlight: setup backlight pwm alternate
      increment on backlight enable

linux (4.4.0-39.59) xenial; urgency=low

  [ Joseph Salisbury ]

  * Release Tracking Bug
    - LP: #1625303

  * thunder: chip errata w/ multiple CQEs for a TSO packet (LP: #1624569)
    - net: thunderx: Fix for issues with multiple CQEs posted for a TSO packet

  * thunder: faulty TSO padding (LP: #1623627)
    - net: thunderx: Fix for HW issue while padding TSO packet

  * CVE-2016-6828
    - tcp: fix use after free in tcp_xmit_retransmit_queue()

  * Sennheiser Officerunner - cannot get freq at ep 0x83 (LP: #1622763)
    - SAUCE: (no-up) ALSA: usb-audio: Add quirk for sennheiser officerunner

  * Backport E3 Skylake Support in ie31200_edac to Xenial (LP: #1619766)
    - EDAC, ie31200_edac: Add Skylake support

  * Ubuntu 16.04 - Full EEH Recovery Support for NVMe devices (LP: #1602724)
    - SAUCE: nvme: Don't suspend admin queue that wasn't created

  * ISST-LTE:pNV: system ben is hung during ST (nvme) (LP: #1620317)
    - blk-mq: Allow timeouts to run while queue is freezing
    - blk-mq: improve warning for running a queue on the wrong CPU
    - blk-mq: don't overwrite rq->mq_ctx

  * lsattr 32bit does not work on 64bit kernel (Inappropriate ioctl error)
    (LP: #1619918)
    - btrfs: bugfix: handle FS_IOC32_{GETFLAGS, SETFLAGS, GETVERSION} in
      btrfs_ioctl

  * radeon: monitor connected to onboard VGA doesn't work with Xenial
    (LP: #1600092)
    - drm/radeon/dp: add back special handling for NUTMEG

  * initramfs includes qle driver, but not firmware (LP: #1623187)
    - qed: add MODULE_FIRMWARE()

  * [Hyper-V] Rebase Hyper-V to 4.7.2 (stable) (LP: #1616677)
    - hv_netvsc: Implement support for VF drivers on Hyper-V
    - hv_netvsc: Fix the list processing for network change event
    - Drivers: hv: vmbus: Introduce functions for estimating room in the ring
      buffer
    - Drivers: hv: vmbus: Use READ_ONCE() to read variables that are volatile
    - Drivers: hv: vmbus: Export the vmbus_set_event() API
    - lcoking/barriers, arch: Use smp barriers...

This bug was fixed in the package linux - 3.19.0-71.79

---------------
linux (3.19.0-71.79) vivid; urgency=low

  * Fix GRO recursion overflow for tunneling protocols (LP: #1631287)
    - tunnels: Don't apply GRO to multiple layers of encapsulation.
    - gro: Allow tunnel stacking in the case of FOU/GUE

  * CVE-2016-7039
    - SAUCE: net: add recursion limit to GRO

linux (3.19.0-70.78) vivid; urgency=low

  [ Joseph Salisbury ]

  * Release Tracking Bug
    - LP: #1625788

  * CVE-2016-6136
    - audit: fix a double fetch in audit_log_single_execve_arg()

  * CVE-2016-6480
    - aacraid: Check size values after double-fetch from user

  * CVE-2016-6828
    - tcp: fix use after free in tcp_xmit_retransmit_queue()

  * lsattr 32bit does not work on 64bit kernel (Inappropriate ioctl error)
    (LP: #1619918)
    - btrfs: bugfix: handle FS_IOC32_{GETFLAGS, SETFLAGS, GETVERSION} in
      btrfs_ioctl

 -- Seth Forshee <email address hidden> Fri, 07 Oct 2016 20:11:52 -0500

This bug was fixed in the package linux - 3.13.0-98.145

---------------
linux (3.13.0-98.145) trusty; urgency=low

  * Fix GRO recursion overflow for tunneling protocols (LP: #1631287)
    - tunnels: Don't apply GRO to multiple layers of encapsulation.

  * CVE-2016-7039
    - SAUCE: net: add recursion limit to GRO

linux (3.13.0-97.144) trusty; urgency=low

  [ Joseph Salisbury ]

  * Release Tracking Bug
    - LP: #1626604

  * Altering use_tempaddr drops all IPv6 addresses (LP: #994931)
    - Revert "UBUNTU: SAUCE: (no-up) ipv6: Fix net.ipv6.conf.all.use_tempaddr
      sysctl"
    - Revert "UBUNTU: SAUCE: (no-up) ipv6: make the net.ipv6.conf.all.use_tempaddr
      sysctl propagate to interface settings"
    - neigh: convert parms to an array
    - neigh: wrap proc dointvec functions
    - neigh: use tbl->family to distinguish ipv4 from ipv6
    - neigh: restore old behaviour of default parms values
    - neigh: ipv6: respect default values set before an address is assigned to
      device

  * PCI quirk required for correct access to configuration space of NFP
    4000/6000 (LP: #1624267)
    - PCI: Support PCIe devices with short cfg_size
    - PCI: Add Netronome vendor and device IDs
    - PCI: Limit config space size for Netronome NFP6000 family
    - PCI: Add Netronome NFP4000 PF device ID
    - PCI: Limit config space size for Netronome NFP4000

  * CVE-2016-6136
    - audit: fix a double fetch in audit_log_single_execve_arg()

  * CVE-2016-6480
    - aacraid: Check size values after double-fetch from user

  * CVE-2016-6828
    - tcp: fix use after free in tcp_xmit_retransmit_queue()

  * IPv6 with LVS Performance issue in latest 3.13LTS kernels (LP: #1618299)
    - ipv6: remove prune parameter for fib6_clean_all
    - ipv6: remove rt6i_genid

  * lsattr 32bit does not work on 64bit kernel (Inappropriate ioctl error)
    (LP: #1619918)
    - btrfs: bugfix: handle FS_IOC32_{GETFLAGS, SETFLAGS, GETVERSION} in
      btrfs_ioctl

  * Miscellaneous upstream changes
    - powerpc/pseries: use pci_host_bridge.release_fn() to kfree(phb)

 -- Seth Forshee <email address hidden> Fri, 07 Oct 2016 20:08:32 -0500

Brad, how can you set this to verified and release when that introduces a pretty severe regression? OMG!!

The "I don't give a sh.."-attitude displayed here towards a regression is shocking. Why do I even bother to test?

The regression is apparently much more severe to obot. I can no longer take a snapshot of my btrfs filesystem.

$ sudo btrfs sub snapshot -r /mnt/LTS/@home/ /mnt/LTS/snapshots/home-daily-$(date +%F)
Create a readonly snapshot of '/mnt/LTS/@home/' in '/mnt/LTS/snapshots/home-daily-2016-10-31'
ERROR: cannot snapshot '/mnt/LTS/@home/' - Inappropriate ioctl for device

@rolf,

I apologize for this getting released. I/we care very much about regressions. I take full responsibility for this happening.

In the future if there is an issue in verifying a fix, changing the verification-needed-<series> tag to verification-failed-<series> would help.

We will get this addressed asap.

This appears to be the same error message you were getting when you originally opened the bug, is that correct? You are just now getting it with other btrfs operations now?

There may be some additional commits that are needed. I'll build a Xenial and Trusty test kernel for testing.

There is a Xenial test kernel with the original fix and a pick of commit c5868f8. Can you give this test kernel a test? It can be downloaded from:

http://kernel.ubuntu.com/~jsalisbury/lp1619918/xenial/

I'm in the process of building a Trusty test kernel as well and will post a link to it when it's ready.

I also built a Trusty test kernel. It can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1619918/trusty

Can you also give this one a test?

Did this issue start happening after an update/upgrade? Was there a prior kernel version where you were not having this particular problem?

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.9 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.9-rc3

Please ignore comment #24. Pasted in wrong bug.

Thank you for providing the test kernel. Unfortunately, it does not fix the regression. I installed the trusty kernel. I did not install the linux-tools-* packages as it would have uninstalled the trusty version of linux-tools-generic. I have the i386 version of that package installed but I run an amd64 kernel. Could that lead to problems?

Thanks for testing, Rolf. The error message from the regression appears to be the same error message you were getting when you originally opened the bug, is that correct? You are just now getting it with other btrfs operations, but the original bug is fixed?

Also, using the 32 bit tools package with a 64 bit kernel, should be fine.

One additional question. Are you only seeing this new regression on Trusty, or does it also happen on Xenial? Would it be possible for you to maybe test the Xenial and Yakkety kernels if it is unknown?

I apologize for the delayed response, I was travelling.

Yes, the error message is the same as for the original report. Then it was triggered by a call to lsattr, now by calling btrfs to create a snapshot. The released kernels do not have the originally reported problem with lsattr but regressed with the call to create a snapshot. I originally found a regression when calling "btrfs fi show" which one only emit a one-liner with the program version but not the requested version with information about the btrfs partitions.

I have not yet had the chance to test the xenial or yakkety kernels.

If possible, it would be great if you could test the xenial kernel posted in comment #22 as well as the Yakkety kernel, which is available from:

https://launchpad.net/~canonical-kernel-security-team/+archive/ubuntu/ppa/+build/11038082

I've downloaded the kernel from http://kernel.ubuntu.com/~jsalisbury/lp1619918/xenial/ and https://launchpad.net/~canonical-kernel-security-team/+archive/ubuntu/ppa/+build/11038082 now. Both kernels have the same problem/regression (verified with "sudo btrfs fi show /")

Can you see if this new regression is also occurring with the current mainline kernel:
http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.9-rc7/

Commit 4c63c2454eff996 fixes the original bug, but introduced a new bug. Testing mainline will tell us if the new bug is already fixed in mainline. If it is, we can perform a "Reverse" bisect to identify the commit the fixes the new bug. It will also tell us if the new bug still exists in mainline.

You know, it's getting to be somewhat annoying. I have very limited bandwidth here. Why don't you back out the patch already until a proper solution is found? I will happily continue to test but as you can see it does take me some time. The test case is pretty clear, why can you not be bothered to test yourself?

If we back out the patch, your original bug will return, correct? Was the original bug a regression? If it was, we can bisect to find the commit that caused the original bug and then back out that commit and commit 4c63c2454eff996.

The alternative is to perform the testing in comment #33, and see if the second bug introduced by commit 4c63c2454eff996 is fixed already. If it is not, we can relay this information upstream and contact the author of commit 4c63c2454eff996.

mainline amd64 kernel 4.9.0-040900rc7-generic #201611271731 does not have the problem with lsattr "btrfs fi show". It DOES have the problem with creating a btrfs snapshot.

The original bug is just an annoyance in my opinion and a cornercase as well. From what I can tell it makes it impossible to get extended attributes for any file, but only if you have a mixed i386/amd64 environment, run the amd64 kernel while having i386 e2fsprogs. The impact of that should be pretty low.

Not being able to take a snapshot on the other hand is a pretty hefty problem.

IOW, I think backing out the patch and reintroducing the original problem is better than keeping the regression the fix introduced to stick around.

adding to comment #36: mainline kernel 4.9.0-040900rc7-generic #201611271731 does

- not have the problem with lsattr
- not have the problem with "btrfs fi show"
- INDEED have the problem with snapshotting

I built a Xenial test kernel with commit 4c63c2454e reverted. The test kernel can be downloaded from:

http://kernel.ubuntu.com/~jsalisbury/lp1619918

Can you test this kernel and see if it resolves the snapshotting bug? It will probably re-introduce the original bug.

We can decide the next steps based on the test results.

Thanks in advance

Thank you for providing the kernel. Here are the (as expected results) results:

- lsattr bug is back
- "btrfs fi show" works
- snapshotting works

$ uname -a
Linux 1001P 4.4.0-53-generic #74~lp1619918Commit4c63c2454eReverted SMP Tue Dec 13 18:27:31 UT x86_64 x86_64 x86_64 GNU/Linux

Thanks for the testing feedback, Rolf. I will ping upstream and the patch Author to get feed back on the next steps. There may be another fix for the new bug, or we may just want to revert it.

In the meantime, can you test the current 4.10-rc2 mainline kernel, to confirm the new bug still exists there?

http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.10-rc2

Thanks

Hi Luke,

A kernel bug report was opened against Ubuntu [0]. This bug was fixed
by the following commit in v4.7-rc1:

commit 4c63c2454eff996c5e27991221106eb511f7db38

Author: Luke Dashjr <email address hidden>
Date: Thu Oct 29 08:22:21 2015 +0000

    btrfs: bugfix: handle FS_IOC32_{GETFLAGS,SETFLAGS,GETVERSION} in
btrfs_ioctl

However, this commit introduced a new regression. With this commit
applied, "btrfs fi show" no longer works and the btrfs snapshot
functionality breaks.

I was hoping to get your feedback, since you are the patch author. Do
you think gathering any additional data will help diagnose this issue,
or would it be best to submit a revert request?

Thanks,

Joe

[0] http://pad.lv/1619918

On Friday, January 06, 2017 5:22:34 PM Joseph Salisbury wrote:
> btrfs: bugfix: handle FS_IOC32_{GETFLAGS,SETFLAGS,GETVERSION} in
> btrfs_ioctl
>
> However, this commit introduced a new regression. With this commit
> applied, "btrfs fi show" no longer works and the btrfs snapshot
> functionality breaks.

I don't see how this is even possibly related. Furthermore, "btrfs fi show" as
well as snapshots seem to work just fine for me.

That being said, I've given up on running a 32-bit userspace, so I don't
really care if this bugfix gets reverted or not.

Luke

On 07.01.2017 01:38, Luke-Jr wrote:
> On Friday, January 06, 2017 5:22:34 PM Joseph Salisbury wrote:
>> btrfs: bugfix: handle FS_IOC32_{GETFLAGS,SETFLAGS,GETVERSION} in
>> btrfs_ioctl
>>
>> However, this commit introduced a new regression. With this commit
>> applied, "btrfs fi show" no longer works and the btrfs snapshot
>> functionality breaks.
> I don't see how this is even possibly related. Furthermore,
> "btrfs fi show" as well as snapshots seem to work just fine
> for me.

Maybe the relation isn't immediately obvious from code inspection alone, nonetheless it demonstrably is there. That commit is what introduced the described regression. Apparently, it's only present with an amd64 kernel and 32-bit userspace.

How many more times will I have to do silly tests with predictable results before this regression is finally fixed, Joseph? Just asking.

Hello,

Please consider reverting commit
4c63c2454eff996c5e27991221106eb511f7db38 in the next v4.x.y release. It
was included upstream as of v4.7-rc1 This commit introduced a
regression, described in the following bug:
http://bugs.launchpad.net/bugs/1619918

This new regression was discussed in the following thread:

https://lkml.org/lkml/2017/1/6/467

Sincerely,

Joseph Salisbury

On Thu, Feb 02, 2017 at 12:38:33PM -0500, Joseph Salisbury wrote:
> Hello,
>
> Please consider reverting commit
> 4c63c2454eff996c5e27991221106eb511f7db38 in the next v4.x.y release.

What release can I remove it from?

It isn't in 4.4.y, and 4.9.y doesn't make much sense, unless it's
reverted in Linus's tree already?

totally confused.

greg k-h

On 02/02/2017 01:23 PM, Greg KH wrote:
> On Thu, Feb 02, 2017 at 12:38:33PM -0500, Joseph Salisbury wrote:
>> Hello,
>>
>> Please consider reverting commit
>> 4c63c2454eff996c5e27991221106eb511f7db38 in the next v4.x.y release.
> What release can I remove it from?
>
> It isn't in 4.4.y, and 4.9.y doesn't make much sense, unless it's
> reverted in Linus's tree already?
>
> totally confused.
>
> greg k-h

Sorry, commit 4c63c2454eff996c5e27991221106eb511f7db38 was introduced in
mainline in v4.7-rc1. The request should be only for kernels newer than
4.7-rc1, so 4.9 and 4.10.

I assume it will come down to 4.9 once reverted in mainline.

I updated the subject.

Thanks,

Joe

On Thu, Feb 02, 2017 at 02:58:16PM -0500, Joseph Salisbury wrote:
> On 02/02/2017 01:23 PM, Greg KH wrote:
> > On Thu, Feb 02, 2017 at 12:38:33PM -0500, Joseph Salisbury wrote:
> >> Hello,
> >>
> >> Please consider reverting commit
> >> 4c63c2454eff996c5e27991221106eb511f7db38 in the next v4.x.y release.
> > What release can I remove it from?
> >
> > It isn't in 4.4.y, and 4.9.y doesn't make much sense, unless it's
> > reverted in Linus's tree already?
> >
> > totally confused.
> >
> > greg k-h
>
> Sorry, commit 4c63c2454eff996c5e27991221106eb511f7db38 was introduced in
> mainline in v4.7-rc1. The request should be only for kernels newer than
> 4.7-rc1, so 4.9 and 4.10.
>
> I assume it will come down to 4.9 once reverted in mainline.

Let me know when it is reverted, and what that revert commit is please.

thanks,

greg k-h

On 02/02/2017 03:57 PM, Greg KH wrote:
> On Thu, Feb 02, 2017 at 02:58:16PM -0500, Joseph Salisbury wrote:
>> On 02/02/2017 01:23 PM, Greg KH wrote:
>>> On Thu, Feb 02, 2017 at 12:38:33PM -0500, Joseph Salisbury wrote:
>>>> Hello,
>>>>
>>>> Please consider reverting commit
>>>> 4c63c2454eff996c5e27991221106eb511f7db38 in the next v4.x.y release.
>>> What release can I remove it from?
>>>
>>> It isn't in 4.4.y, and 4.9.y doesn't make much sense, unless it's
>>> reverted in Linus's tree already?
>>>
>>> totally confused.
>>>
>>> greg k-h
>> Sorry, commit 4c63c2454eff996c5e27991221106eb511f7db38 was introduced in
>> mainline in v4.7-rc1. The request should be only for kernels newer than
>> 4.7-rc1, so 4.9 and 4.10.
>>
>> I assume it will come down to 4.9 once reverted in mainline.
> Let me know when it is reverted, and what that revert commit is please.
>
> thanks,
>
> greg k-h

Will do.

Thanks again,

Joe

There should be a fix coming from upstream shortly:
https://lkml.org/lkml/2017/2/6/969

On 08.02.2017 04:29, Joseph Salisbury wrote:
> There should be a fix coming from upstream shortly:
> https://lkml.org/lkml/2017/2/6/969

Great! Thanks.

This fix from Jeff has landed in mainline and has been cc'd to stable:

commit 2a362249187a8d0f6d942d6e1d763d150a296f47
Author: Jeff Mahoney <email address hidden>
Date: Mon Feb 6 19:39:09 2017 -0500

    btrfs: fix btrfs_compat_ioctl failures on non-compat ioctls

I built a Xenial test kernel with this commit. Can you test this kernel and confirm it fixes the bug? It can be downloaded from:

http://bugs.launchpad.net/bugs/1619918/xenial

I'm happy to report that with the latest kernel from http://kernel.ubuntu.com/~jsalisbury/lp1619918/ the original issue with lsattr is fixed and there are no regressions with "btrfs fi show" or "btrfs sub snapshot".

Thanks for all the help and testing, Rolf! I'll submit an SRU request to have this patch in all Ubuntu releases.

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-trusty' to 'verification-done-trusty'. If the problem still exists, change the tag 'verification-needed-trusty' to 'verification-failed-trusty'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-xenial' to 'verification-done-xenial'. If the problem still exists, change the tag 'verification-needed-xenial' to 'verification-failed-xenial'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-yakkety' to 'verification-done-yakkety'. If the problem still exists, change the tag 'verification-needed-yakkety' to 'verification-failed-yakkety'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

Thank you for releasing the test kernels. I will likely need a bit more time for testing than the allotted five days as the internet in this part of the world is inadequate. Please confirm the extension.

Hello Rolf,

Our "Bug verification & Regression testing" slot for the current SRU cycle [1] is between 19-Mar - 31-Mar
So it would be great if we can have your help before 31-Mar

Thank you very much!!

[1] https://wiki.ubuntu.com/KernelTeam/Newsletter/2017-03-21

I'm happy to report that with kernel linux-image-3.13.0-114-generic:amd64 and e2fsprogs:i386 on trusty the original issue with lsattr is fixed and there are no regressions with "btrfs fi show" or "btrfs sub snapshot".

For verification of the other kernels, is it sufficient for me to install those kernels on my trusty system and do the tests?

Po-Hsu Lin, I understand the kernel team is busy, but frankly, I don't understand why I should be doing all the work when it wasn't me introducing the regression. There are clear steps provided in how to verify the problem and the fix. I don't think it should be beyond those who get paid for this kind of stuff and who no doubt will have more powerful resources and connectivity than me to do at least a test of their own from time to time.

@Po-Hsu So, I did the work, yet you didn't act on it in time. Great! Just confirms the impression of the Ubuntu kernel team I've had for a while.

found another similar bug 1678645

This bug was fixed in the package linux - 3.13.0-117.164

---------------
linux (3.13.0-117.164) trusty; urgency=low

  * linux: 3.13.0-117.164 -proposed tracker (LP: #1680733)

  * CVE-2017-6353
    - sctp: deny peeloff operation on asocs with threads sleeping on it

  * CVE-2017-5986
    - sctp: avoid BUG_ON on sctp_wait_for_sndbuf

  * Update ENA driver to 1.1.2 from net-next (LP: #1664312)
    - net: ena: Remove unnecessary pci_set_drvdata()
    - net: ena: Fix error return code in ena_device_init()
    - net: ena: change the return type of ena_set_push_mode() to be void.
    - net: ena: use setup_timer() and mod_timer()
    - net/ena: remove ntuple filter support from device feature list
    - net/ena: fix queues number calculation
    - net/ena: fix ethtool RSS flow configuration
    - net/ena: fix RSS default hash configuration
    - net/ena: fix NULL dereference when removing the driver after device reset
      failed
    - net/ena: refactor ena_get_stats64 to be atomic context safe
    - net/ena: fix potential access to freed memory during device reset
    - net/ena: use READ_ONCE to access completion descriptors
    - net/ena: reduce the severity of ena printouts
    - net/ena: change driver's default timeouts
    - net/ena: change condition for host attribute configuration
    - net/ena: update driver version to 1.1.2

  * [Xenial - 16.04 ]Bonding driver - stack corruption when trying to copy 20
    bytes to a sockaddr (LP: #1668042)
    - net/bonding: Enforce active-backup policy for IPoIB bonds

  * stress_smoke_test passing and exiting rc=9 (linux 4.9.0-12.13 ADT test
    failure with linux 4.9.0-12.13) (LP: #1658633)
    - ext4: lock the xattr block before checksuming it

  * vmxnet3 LRO IPv6 performance issues (stalling TCP) (LP: #1605494)
    - Driver: Vmxnet3: set CHECKSUM_UNNECESSARY for IPv6 packets

  * move aufs.ko from -extra to linux-image package (LP: #1673498)
    - [config] aufs.ko moved to linux-image package

  * lsattr 32bit does not work on 64bit kernel (Inappropriate ioctl error)
    (LP: #1619918)
    - btrfs: fix btrfs_compat_ioctl failures on non-compat ioctls

 -- Kleber Sacilotto de Souza <email address hidden> Thu, 06 Apr 2017 17:52:50 +0100

This bug was fixed in the package linux - 4.4.0-75.96

---------------
linux (4.4.0-75.96) xenial; urgency=low

  * linux: 4.4.0-75.96 -proposed tracker (LP: #1684441)

  * [Hyper-V] hv: util: move waiting for release to hv_utils_transport itself
    (LP: #1682561)
    - Drivers: hv: util: move waiting for release to hv_utils_transport itself

linux (4.4.0-74.95) xenial; urgency=low

  * linux: 4.4.0-74.95 -proposed tracker (LP: #1682041)

  * [Hyper-V] hv: vmbus: Raise retry/wait limits in vmbus_post_msg()
    (LP: #1681893)
    - Drivers: hv: vmbus: Raise retry/wait limits in vmbus_post_msg()

linux (4.4.0-73.94) xenial; urgency=low

  * linux: 4.4.0-73.94 -proposed tracker (LP: #1680416)

  * CVE-2017-6353
    - sctp: deny peeloff operation on asocs with threads sleeping on it

  * vfat: missing iso8859-1 charset (LP: #1677230)
    - [Config] NLS_ISO8859_1=y

  * Regression: KVM modules should be on main kernel package (LP: #1678099)
    - [Config] powerpc: Add kvm-hv and kvm-pr to the generic inclusion list

  * linux-lts-xenial 4.4.0-63.84~14.04.2 ADT test failure with linux-lts-xenial
    4.4.0-63.84~14.04.2 (LP: #1664912)
    - SAUCE: apparmor: fix link auditing failure due to, uninitialized var

  * regession tests failing after stackprofile test is run (LP: #1661030)
    - SAUCE: fix regression with domain change in complain mode

  * Permission denied and inconsistent behavior in complain mode with 'ip netns
    list' command (LP: #1648903)
    - SAUCE: fix regression with domain change in complain mode

  * unexpected errno=13 and disconnected path when trying to open /proc/1/ns/mnt
    from a unshared mount namespace (LP: #1656121)
    - SAUCE: apparmor: null profiles should inherit parent control flags

  * apparmor refcount leak of profile namespace when removing profiles
    (LP: #1660849)
    - SAUCE: apparmor: fix ns ref count link when removing profiles from policy

  * tor in lxd: apparmor="DENIED" operation="change_onexec"
    namespace="root//CONTAINERNAME_<var-lib-lxd>" profile="unconfined"
    name="system_tor" (LP: #1648143)
    - SAUCE: apparmor: Fix no_new_privs blocking change_onexec when using stacked
      namespaces

  * apparmor oops in bind_mnt when dev_path lookup fails (LP: #1660840)
    - SAUCE: apparmor: fix oops in bind_mnt when dev_path lookup fails

  * apparmor auditing denied access of special apparmor .null fi\ le
    (LP: #1660836)
    - SAUCE: apparmor: Don't audit denied access of special apparmor .null file

  * apparmor label leak when new label is unused (LP: #1660834)
    - SAUCE: apparmor: fix label leak when new label is unused

  * apparmor reference count bug in label_merge_insert() (LP: #1660833)
    - SAUCE: apparmor: fix reference count bug in label_merge_insert()

  * apparmor's raw_data file in securityfs is sometimes truncated (LP: #1638996)
    - SAUCE: apparmor: fix replacement race in reading rawdata

  * unix domain socket cross permission check failing with nested namespaces
    (LP: #1660832)
    - SAUCE: apparmor: fix cross ns perm of unix domain sockets

  * Xenial update to v4.4.59 stable release (LP: #1678960)
    - xfrm: policy: init locks early
    - virtio_balloon: init ...

This bug was fixed in the package linux - 4.8.0-49.52

---------------
linux (4.8.0-49.52) yakkety; urgency=low

  * linux: 4.8.0-49.52 -proposed tracker (LP: #1684427)

  * [Hyper-V] hv: util: move waiting for release to hv_utils_transport itself
    (LP: #1682561)
    - Drivers: hv: util: move waiting for release to hv_utils_transport itself

linux (4.8.0-48.51) yakkety; urgency=low

  * linux: 4.8.0-48.51 -proposed tracker (LP: #1682034)

  * [Hyper-V] hv: vmbus: Raise retry/wait limits in vmbus_post_msg()
    (LP: #1681893)
    - Drivers: hv: vmbus: Raise retry/wait limits in vmbus_post_msg()

linux (4.8.0-47.50) yakkety; urgency=low

  * linux: 4.8.0-47.50 -proposed tracker (LP: #1679678)

  * CVE-2017-6353
    - sctp: deny peeloff operation on asocs with threads sleeping on it

  * CVE-2017-5986
    - sctp: avoid BUG_ON on sctp_wait_for_sndbuf

  * vfat: missing iso8859-1 charset (LP: #1677230)
    - [Config] NLS_ISO8859_1=y

  * [Hyper-V] pci-hyperv: Use device serial number as PCI domain (LP: #1667527)
    - net/mlx4_core: Use cq quota in SRIOV when creating completion EQs

  * Regression: KVM modules should be on main kernel package (LP: #1678099)
    - [Config] powerpc: Add kvm-hv and kvm-pr to the generic inclusion list

  * linux-lts-xenial 4.4.0-63.84~14.04.2 ADT test failure with linux-lts-xenial
    4.4.0-63.84~14.04.2 (LP: #1664912)
    - SAUCE: apparmor: fix link auditing failure due to, uninitialized var

  * regession tests failing after stackprofile test is run (LP: #1661030)
    - SAUCE: fix regression with domain change in complain mode

  * Permission denied and inconsistent behavior in complain mode with 'ip netns
    list' command (LP: #1648903)
    - SAUCE: fix regression with domain change in complain mode

  * unexpected errno=13 and disconnected path when trying to open /proc/1/ns/mnt
    from a unshared mount namespace (LP: #1656121)
    - SAUCE: apparmor: null profiles should inherit parent control flags

  * apparmor refcount leak of profile namespace when removing profiles
    (LP: #1660849)
    - SAUCE: apparmor: fix ns ref count link when removing profiles from policy

  * tor in lxd: apparmor="DENIED" operation="change_onexec"
    namespace="root//CONTAINERNAME_<var-lib-lxd>" profile="unconfined"
    name="system_tor" (LP: #1648143)
    - SAUCE: apparmor: Fix no_new_privs blocking change_onexec when using stacked
      namespaces

  * apparmor oops in bind_mnt when dev_path lookup fails (LP: #1660840)
    - SAUCE: apparmor: fix oops in bind_mnt when dev_path lookup fails

  * apparmor auditing denied access of special apparmor .null fi\ le
    (LP: #1660836)
    - SAUCE: apparmor: Don't audit denied access of special apparmor .null file

  * apparmor label leak when new label is unused (LP: #1660834)
    - SAUCE: apparmor: fix label leak when new label is unused

  * apparmor reference count bug in label_merge_insert() (LP: #1660833)
    - SAUCE: apparmor: fix reference count bug in label_merge_insert()

  * apparmor's raw_data file in securityfs is sometimes truncated (LP: #1638996)
    - SAUCE: apparmor: fix replacement race in reading rawdata

  * unix domain socket cross permission check failing with n...