Processed: Re: Bug#857790: sun4i_ss broken on Cubieboard (Allwinner A10)

2017-03-14 Thread Debian Bug Tracking System 
Processing control commands:

> tag -1 moreinfo
Bug #857790 [src:linux] sun4i_ss broken on Cubieboard (Allwinner A10)
Added tag(s) moreinfo.

-- 
857790: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857790
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#857790: sun4i_ss broken on Cubieboard (Allwinner A10)

2017-03-14 Thread Ben Hutchings 
Control: tag -1 moreinfo

On Wed, 2017-03-15 at 01:58 +0100, Marco d'Itri wrote:
> Package: src:linux
> Version: 4.9.13-1
> Severity: normal
> 
> Upgrading from 4.4.0-1 to 4.9.0-2 broke Kerberos security for NFS, at 
> least as a server.
> 
> kernel: CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d
> kernel: OF: fdt:Machine model: Cubietech Cubieboard
> 
> Unless I blacklist the sun4i_ss module then mounting the exported file
> system will not work and the kernel will log:
> 
> kernel: alg: skcipher: Test 1 failed (invalid result) on encryption for 
> cts(cbc-aes-sun4i-ss)
> kernel: : 4b 10 75 fc 2f 14 1b 6a 27 35 37 33 d1 b7 70 05
> kernel: 0010: 97
> 
> http://sunxi.org/Cryptographic_Hardware_Accelerators says that CTS mode 
> is not even implemented on A10 CPUS.

So far as I can see, the hardware is being used in CBC mode and then
CTS is implemented generically in software on top of that.

The sun4i_ss driver hasn't changed much since 4.4, but the CTS
implementation did have one big change:

commit 0605c41cc53ca13775d202de0de33864a46162ba
Author: Herbert Xu 
Date:   Tue Jul 12 13:17:48 2016 +0800

crypto: cts - Convert to skcipher

This patch converts cts over to the skcipher interface.  It also
optimises the implementation to use one CBC operation for all but
the last block, which is then processed separately.

So I think that might now be triggering a bug in the sun4i_ss driver's
AES CBC mode implementation.

You could try reverting that (patch attached) to verify that this is
what happened.  Obviously that won't be a proper solution though.

Ben.

-- 
Ben Hutchings
It's easier to fight for one's principles than to live up to them.
reverted:
--- b/crypto/cts.c
+++ a/crypto/cts.c
@@ -40,7 +40,7 @@
  * rfc3962 includes errata information in its Appendix A.
  */
 
+#include 
-#include 
 #include 
 #include 
 #include 
@@ -51,364 +51,289 @@
 #include 
 
 struct crypto_cts_ctx {
+	struct crypto_blkcipher *child;
-	struct crypto_skcipher *child;
 };
 
+static int crypto_cts_setkey(struct crypto_tfm *parent, const u8 *key,
+			 unsigned int keylen)
-struct crypto_cts_reqctx {
-	struct scatterlist sg[2];
-	unsigned offset;
-	struct skcipher_request subreq;
-};
-
-static inline u8 *crypto_cts_reqctx_space(struct skcipher_request *req)
 {
+	struct crypto_cts_ctx *ctx = crypto_tfm_ctx(parent);
+	struct crypto_blkcipher *child = ctx->child;
+	int err;
-	struct crypto_cts_reqctx *rctx = skcipher_request_ctx(req);
-	struct crypto_skcipher *tfm = crypto_skcipher_reqtfm(req);
-	struct crypto_cts_ctx *ctx = crypto_skcipher_ctx(tfm);
-	struct crypto_skcipher *child = ctx->child;
 
+	crypto_blkcipher_clear_flags(child, CRYPTO_TFM_REQ_MASK);
+	crypto_blkcipher_set_flags(child, crypto_tfm_get_flags(parent) &
+   CRYPTO_TFM_REQ_MASK);
+	err = crypto_blkcipher_setkey(child, key, keylen);
+	crypto_tfm_set_flags(parent, crypto_blkcipher_get_flags(child) &
+ CRYPTO_TFM_RES_MASK);
+	return err;
-	return PTR_ALIGN((u8 *)(rctx + 1) + crypto_skcipher_reqsize(child),
-			 crypto_skcipher_alignmask(tfm) + 1);
 }
 
+static int cts_cbc_encrypt(struct crypto_cts_ctx *ctx,
+			   struct blkcipher_desc *desc,
+			   struct scatterlist *dst,
+			   struct scatterlist *src,
+			   unsigned int offset,
+			   unsigned int nbytes)
-static int crypto_cts_setkey(struct crypto_skcipher *parent, const u8 *key,
-			 unsigned int keylen)
 {
+	int bsize = crypto_blkcipher_blocksize(desc->tfm);
+	u8 tmp[bsize], tmp2[bsize];
+	struct blkcipher_desc lcldesc;
+	struct scatterlist sgsrc[1], sgdst[1];
+	int lastn = nbytes - bsize;
+	u8 iv[bsize];
+	u8 s[bsize * 2], d[bsize * 2];
-	struct crypto_cts_ctx *ctx = crypto_skcipher_ctx(parent);
-	struct crypto_skcipher *child = ctx->child;
 	int err;
 
+	if (lastn < 0)
+		return -EINVAL;
-	crypto_skcipher_clear_flags(child, CRYPTO_TFM_REQ_MASK);
-	crypto_skcipher_set_flags(child, crypto_skcipher_get_flags(parent) &
-	 CRYPTO_TFM_REQ_MASK);
-	err = crypto_skcipher_setkey(child, key, keylen);
-	crypto_skcipher_set_flags(parent, crypto_skcipher_get_flags(child) &
-	  CRYPTO_TFM_RES_MASK);
-	return err;
-}
 
+	sg_init_table(sgsrc, 1);
+	sg_init_table(sgdst, 1);
-static void cts_cbc_crypt_done(struct crypto_async_request *areq, int err)
-{
-	struct skcipher_request *req = areq->data;
 
+	memset(s, 0, sizeof(s));
+	scatterwalk_map_and_copy(s, src, offset, nbytes, 0);
-	if (err == -EINPROGRESS)
-		return;
 
+	memcpy(iv, desc->info, bsize);
-	skcipher_request_complete(req, err);
-}
 
+	lcldesc.tfm = ctx->child;
+	lcldesc.info = iv;
+	lcldesc.flags = desc->flags;
-static int cts_cbc_encrypt(struct skcipher_request *req)
-{
-	struct crypto_cts_reqctx *rctx = skcipher_request_ctx(req);
-	struct crypto_skcipher *tfm = crypto_skcipher_reqtfm(req);
-	struct skcipher_request *subreq = >subreq;
-	int bsize = crypto_skcipher_blocksize(tfm);
-	u8 d[bsize * 2] __attribute__ ((aligned(__alignof__(u32;
-	struct

Bug#857790: sun4i_ss broken on Cubieboard (Allwinner A10)

2017-03-14 Thread Marco d'Itri 
Package: src:linux
Version: 4.9.13-1
Severity: normal

Upgrading from 4.4.0-1 to 4.9.0-2 broke Kerberos security for NFS, at 
least as a server.

kernel: CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d
kernel: OF: fdt:Machine model: Cubietech Cubieboard

Unless I blacklist the sun4i_ss module then mounting the exported file
system will not work and the kernel will log:

kernel: alg: skcipher: Test 1 failed (invalid result) on encryption for 
cts(cbc-aes-sun4i-ss)
kernel: : 4b 10 75 fc 2f 14 1b 6a 27 35 37 33 d1 b7 70 05
kernel: 0010: 97

http://sunxi.org/Cryptographic_Hardware_Accelerators says that CTS mode 
is not even implemented on A10 CPUS.

-- Package-specific info:
** Version:
Linux version 4.9.0-2-armmp (debian-kernel@lists.debian.org) (gcc version 6.3.0 
20170221 (Debian 6.3.0-8) ) #1 SMP Debian 4.9.13-1 (2017-02-27)

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Processed: found 857039 in 77

2017-03-14 Thread Debian Bug Tracking System 
Processing commands for cont...@bugs.debian.org:

> found 857039 77
Bug #857039 [src:linux-latest] linux-latest: xen-linux-system packages
Marked as found in versions linux-latest/77.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
857039: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857039
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: notfound 857039 in 77, found 857039 in 78

2017-03-14 Thread Debian Bug Tracking System 
Processing commands for cont...@bugs.debian.org:

> notfound 857039 77
Bug #857039 [src:linux-latest] linux-latest: xen-linux-system packages
No longer marked as found in versions linux-latest/77.
> found 857039 78
Bug #857039 [src:linux-latest] linux-latest: xen-linux-system packages
Marked as found in versions linux-latest/78.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
857039: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857039
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#841144: kernel BUG at /build/linux-Wgpe2M/linux-4.8.11/fs/ocfs2/alloc.c:1514!

2017-03-14 Thread Ian Campbell 
OCFS2 folks, any thoughts on this crash?

On Tue, 2017-01-17 at 02:12 +, Ben Hutchings wrote:
> On Mon, 2017-01-16 at 13:12 -0600, Russell Mosemann wrote:
> [...]
> > Jan 15 17:31:03 vhost032 kernel: [ cut here ]
> > Jan 15 17:31:03 vhost032 kernel: kernel BUG at 
> > /build/linux-Wgpe2M/linux-4.8.11/fs/ocfs2/alloc.c:1514!
> 
> This is:
> 
> static int ocfs2_grow_tree(handle_t *handle, struct ocfs2_extent_tree *et,
>    int *final_depth, struct buffer_head **last_eb_bh,
>    struct ocfs2_alloc_context *meta_ac)
> {
> ...
> BUG_ON(meta_ac == NULL);
> 
> > [...]
> > Jan 15 17:31:03 vhost032 kernel: Call Trace:
> > Jan 15 17:31:03 vhost032 kernel:  [] ? 
> > ocfs2_set_buffer_uptodate+0x35/0x4a0 [ocfs2]
> > Jan 15 17:31:03 vhost032 kernel:  [] ? 
> > __find_get_block+0xa7/0x110
> > Jan 15 17:31:03 vhost032 kernel:  [] ? 
> > ocfs2_split_and_insert+0x307/0x490 [ocfs2]
> > Jan 15 17:31:03 vhost032 kernel:  [] ? 
> > ocfs2_split_extent+0x3ee/0x560 [ocfs2]
> > Jan 15 17:31:03 vhost032 kernel:  [] ? 
> > ocfs2_change_extent_flag+0x273/0x450 [ocfs2]
> > Jan 15 17:31:03 vhost032 kernel:  [] ? 
> > ocfs2_mark_extent_written+0x110/0x1d0 [ocfs2]
> > Jan 15 17:31:03 vhost032 kernel:  [] ? 
> > ocfs2_dio_end_io_write+0x44d/0x600 [ocfs2]
> 
> meta_ac is passed down from ocfs2_dio_end_io_write(), which allocates
> it using ocfs2_lock_allocators()... but the latter only allocates it
> conditionally.  It seems like the condition is wrong somehow.

This still seems to be happening for this user with 4.9.13, looking at
"git log -p v4.9.13..origin/master -- fs/ocfs2" I wonder if
https://git.kernel.org/torvalds/c/3e10b793fc40dfdbe51762e0d084bd6f2c8acaaa
might be relevant?

The commit message mentions meta_ac not getting allocated and an extent
split vs refcount split differentiation and we have ocfs2_split_extent
in the trace. Slim reasoning I know, maybe someone who knows the code
could make a better determination.

As Ben said before the whole bug report can be found at https://bugs.de
bian.org/841144

Ian.

Bug#841144: kernel BUG at /home/zumbi/linux-4.9.13/fs/ocfs2/alloc.c:1514!

2017-03-14 Thread Russell Mosemann 

Package: src:linux
Version: 4.9.13-1~bpo8+1
Severity: important

Dear Maintainer,

   * What led up to the situation?
 
Mar 14 10:58:55 vhost012 kernel: [ cut here ]
Mar 14 10:58:55 vhost012 kernel: kernel BUG at 
/home/zumbi/linux-4.9.13/fs/ocfs2/alloc.c:1514!
Mar 14 10:58:55 vhost012 kernel: invalid opcode:  [#1] SMP
Mar 14 10:58:55 vhost012 kernel: Modules linked in: vhost_net vhost macvtap 
macvlan tun ocfs2 quota_tree hmac veth iptable_filter ip_tables x_tables nfsd 
auth_rpcgss nfs_acl nfs lockd grace fscache sunrpc ocfs2_dlmfs ocfs2_stack_o2cb 
ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs bridge stp llc bonding 
intel_rapl sb_edac edac_core x86_pkg_temp_thermal intel_powerclamp coretemp 
kvm_intel kvm irqbypass crct10dif_pclmul ast crc32_pclmul ttm drm_kms_helper 
iTCO_wdt ghash_clmulni_intel iTCO_vendor_support evdev mxm_wmi intel_cstate drm 
xhci_pci xhci_hcd intel_uncore ehci_pci igb ehci_hcd intel_rapl_perf e1000e 
pcspkr usbcore mei_me ptp dca usb_common pps_core i2c_algo_bit sg mei lpc_ich 
i2c_i801 shpchp i2c_smbus mfd_core ipmi_si fjes ipmi_msghandler acpi_pad wmi 
acpi_power_meter tpm_tis tpm_tis_core tpm button fuse
Mar 14 10:58:55 vhost012 kernel:  drbd lru_cache libcrc32c crc32c_generic 
autofs4 ext4 crc16 jbd2 fscrypto mbcache dm_mod md_mod sd_mod crc32c_intel ahci 
libahci aesni_intel libata aes_x86_64 glue_helper lrw gf128mul ablk_helper 
cryptd scsi_mod
Mar 14 10:58:55 vhost012 kernel: CPU: 5 PID: 12675 Comm: qemu-system-x86 Not 
tainted 4.9.0-0.bpo.2-amd64 #1 Debian 4.9.13-1~bpo8+1
Mar 14 10:58:55 vhost012 kernel: Hardware name: To Be Filled By O.E.M. To Be 
Filled By O.E.M./EPC612D4I, BIOS P2.10 03/31/2016
Mar 14 10:58:55 vhost012 kernel: task: 8a45b8339100 task.stack: 
b3c56570c000
Mar 14 10:58:55 vhost012 kernel: RIP: 0010:[]  
[] ocfs2_grow_tree+0x6f2/0x780 [ocfs2]
Mar 14 10:58:55 vhost012 kernel: RSP: 0018:b3c56570f618  EFLAGS: 00010246
Mar 14 10:58:55 vhost012 kernel: RAX:  RBX: 0002 
RCX: b3c56570f790
Mar 14 10:58:55 vhost012 kernel: RDX: b3c56570f6bc RSI: b3c56570f968 
RDI: 8a377c72dcf0
Mar 14 10:58:55 vhost012 kernel: RBP: b3c56570f678 R08:  
R09: 00197c94
Mar 14 10:58:55 vhost012 kernel: R10: 0099a870 R11: 8a378557d030 
R12: 0001
Mar 14 10:58:55 vhost012 kernel: R13: b3c56570f828 R14: 8a378443c0c0 
R15: 0002
Mar 14 10:58:55 vhost012 kernel: FS:  7f71cbfff700() 
GS:8a45bf34() knlGS:
Mar 14 10:58:55 vhost012 kernel: CS:  0010 DS:  ES:  CR0: 
80050033
Mar 14 10:58:55 vhost012 kernel: CR2: 080fb1d8 CR3: 0002063c8000 
CR4: 001426e0
Mar 14 10:58:55 vhost012 kernel: Stack:
Mar 14 10:58:55 vhost012 kernel:  b3c56570f728 b3c56570f728 
c0c790e5 8a35a33bba90
Mar 14 10:58:55 vhost012 kernel:  c0c7885f 8a3784caa450 
1cc27510 0002
Mar 14 10:58:55 vhost012 kernel:  0001 b3c56570f828 
b3c56570f968 8a378403c080
Mar 14 10:58:55 vhost012 kernel: Call Trace:
Mar 14 10:58:55 vhost012 kernel:  [] ? 
ocfs2_set_buffer_uptodate+0x35/0x4a0 [ocfs2]
Mar 14 10:58:55 vhost012 kernel:  [] ? 
ocfs2_buffer_cached.isra.6+0x7f/0x1a0 [ocfs2]
Mar 14 10:58:55 vhost012 kernel:  [] ? 
ocfs2_split_and_insert+0x307/0x490 [ocfs2]
Mar 14 10:58:55 vhost012 kernel:  [] ? 
ocfs2_split_extent+0x3ee/0x560 [ocfs2]
Mar 14 10:58:55 vhost012 kernel:  [] ? 
ocfs2_change_extent_flag+0x273/0x450 [ocfs2]
Mar 14 10:58:55 vhost012 kernel:  [] ? 
ocfs2_mark_extent_written+0x110/0x1d0 [ocfs2]
Mar 14 10:58:55 vhost012 kernel:  [] ? 
ocfs2_dio_end_io_write+0x44d/0x600 [ocfs2]
Mar 14 10:58:55 vhost012 kernel:  [] ? 
ocfs2_allocate_extend_trans+0x180/0x180 [ocfs2]
Mar 14 10:58:55 vhost012 kernel:  [] ? 
ocfs2_dio_end_io+0x3b/0x60 [ocfs2]
Mar 14 10:58:55 vhost012 kernel:  [] ? dio_complete+0x7e/0x190
Mar 14 10:58:55 vhost012 kernel:  [] ? 
do_blockdev_direct_IO+0x2168/0x2860
Mar 14 10:58:55 vhost012 kernel:  [] ? 
ocfs2_write_end_nolock+0x550/0x550 [ocfs2]
Mar 14 10:58:55 vhost012 kernel:  [] ? 
ocfs2_direct_IO+0x83/0x90 [ocfs2]
Mar 14 10:58:55 vhost012 kernel:  [] ? 
generic_file_direct_write+0xb3/0x180
Mar 14 10:58:55 vhost012 kernel:  [] ? 
__generic_file_write_iter+0xb6/0x1e0
Mar 14 10:58:55 vhost012 kernel:  [] ? 
ocfs2_file_write_iter+0x44e/0xae0 [ocfs2]
Mar 14 10:58:55 vhost012 kernel:  [] ? 
do_iter_readv_writev+0xb0/0x130
Mar 14 10:58:55 vhost012 kernel:  [] ? 
do_readv_writev+0x1ac/0x240
Mar 14 10:58:55 vhost012 kernel:  [] ? 
ocfs2_check_range_for_refcount+0x130/0x130 [ocfs2]
Mar 14 10:58:55 vhost012 kernel:  [] ? do_pwritev+0x8c/0xc0
Mar 14 10:58:55 vhost012 kernel:  [] ? 
system_call_fast_compare_end+0xc/0x9b
Mar 14 10:58:55 vhost012 kernel: Code: 24 28 48 c7 c1 64 f0 c9 c0 ba 1c 06 00 
00 48 c7 c6 d0 19 c9 c0 31 c0 44 89 4c 24 18 e8 18 f4 e9 ff 44 8b 4c 24 18 e9 
26 fc ff ff <0f> 0b 48 8b 04 24 48 83 38 00 75 6c f0

Bug#841144: kernel BUG at /home/zumbi/linux-4.9.13/fs/ocfs2/alloc.c:1514!

2017-03-14 Thread Russell Mosemann 

Package: src:linux
Version: 4.9.13-1~bpo8+1
Severity: important

Dear Maintainer,

   * What led up to the situation?
 
Mar 14 10:00:55 vhost032 kernel: [ cut here ]
Mar 14 10:00:55 vhost032 kernel: kernel BUG at 
/home/zumbi/linux-4.9.13/fs/ocfs2/alloc.c:1514!
Mar 14 10:00:55 vhost032 kernel: invalid opcode:  [#1] SMP
Mar 14 10:00:55 vhost032 kernel: Modules linked in: vhost_net vhost macvtap 
macvlan tun ocfs2 quota_tree hmac veth iptable_filter ip_tables x_tables nfsd 
auth_rpcgss nfs_acl nfs lockd grace fscache sunrpc ocfs2_dlmfs ocfs2_stack_o2cb 
ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs bridge stp llc bonding 
intel_rapl sb_edac edac_core x86_pkg_temp_thermal intel_powerclamp coretemp 
kvm_intel kvm ast irqbypass ttm crct10dif_pclmul crc32_pclmul drm_kms_helper 
ghash_clmulni_intel iTCO_wdt xhci_pci iTCO_vendor_support mxm_wmi evdev 
intel_cstate xhci_hcd drm e1000e ehci_pci intel_uncore igb ehci_hcd ipmi_si 
mei_me dca usbcore i2c_i801 pcspkr mei i2c_algo_bit lpc_ich ptp intel_rapl_perf 
sg usb_common shpchp pps_core i2c_smbus mfd_core fjes ipmi_msghandler wmi 
tpm_tis acpi_pad tpm_tis_core tpm acpi_power_meter button fuse
Mar 14 10:00:55 vhost032 kernel:  drbd lru_cache libcrc32c crc32c_generic 
autofs4 ext4 crc16 jbd2 fscrypto mbcache dm_mod md_mod sd_mod ahci crc32c_intel 
libahci libata aesni_intel aes_x86_64 glue_helper lrw gf128mul ablk_helper 
cryptd scsi_mod
Mar 14 10:00:55 vhost032 kernel: CPU: 5 PID: 32333 Comm: qemu-system-x86 Not 
tainted 4.9.0-0.bpo.2-amd64 #1 Debian 4.9.13-1~bpo8+1
Mar 14 10:00:55 vhost032 kernel: Hardware name: To Be Filled By O.E.M. To Be 
Filled By O.E.M./EPC612D4I, BIOS P2.10 03/31/2016
Mar 14 10:00:55 vhost032 kernel: task: 886e3d9190c0 task.stack: 
a9efe008c000
Mar 14 10:00:55 vhost032 kernel: RIP: 0010:[]  
[] ocfs2_grow_tree+0x6f2/0x780 [ocfs2]
Mar 14 10:00:55 vhost032 kernel: RSP: 0018:a9efe008f618  EFLAGS: 00010246
Mar 14 10:00:55 vhost032 kernel: RAX:  RBX: 003c 
RCX: a9efe008f790
Mar 14 10:00:55 vhost032 kernel: RDX: a9efe008f6bc RSI: a9efe008f968 
RDI: 887c731f6990
Mar 14 10:00:55 vhost032 kernel: RBP: a9efe008f678 R08:  
R09: 001f6f9c
Mar 14 10:00:55 vhost032 kernel: R10: 024feda0 R11: 886e4194d0c0 
R12: 0001
Mar 14 10:00:55 vhost032 kernel: R13: a9efe008f828 R14: 886e4194d0c0 
R15: 0001
Mar 14 10:00:55 vhost032 kernel: FS:  7fa9fd1f4700() 
GS:887c7f34() knlGS:
Mar 14 10:00:55 vhost032 kernel: CS:  0010 DS:  ES:  CR0: 
80050033
Mar 14 10:00:55 vhost032 kernel: CR2: 55ef99296360 CR3: 1e04f000 
CR4: 001426e0
Mar 14 10:00:55 vhost032 kernel: Stack:
Mar 14 10:00:55 vhost032 kernel:  a9efe008f728 a9efe008f728 
c0bc10e5 886d4201c800
Mar 14 10:00:55 vhost032 kernel:  c0bc085f 886e4bc8bc10 
7ba516ec 003c
Mar 14 10:00:55 vhost032 kernel:  0001 a9efe008f828 
a9efe008f968 886d4201c800
Mar 14 10:00:55 vhost032 kernel: Call Trace:
Mar 14 10:00:55 vhost032 kernel:  [] ? 
ocfs2_set_buffer_uptodate+0x35/0x4a0 [ocfs2]
Mar 14 10:00:55 vhost032 kernel:  [] ? 
ocfs2_buffer_cached.isra.6+0x7f/0x1a0 [ocfs2]
Mar 14 10:00:55 vhost032 kernel:  [] ? 
ocfs2_split_and_insert+0x307/0x490 [ocfs2]
Mar 14 10:00:55 vhost032 kernel:  [] ? 
ocfs2_split_extent+0x3ee/0x560 [ocfs2]
Mar 14 10:00:55 vhost032 kernel:  [] ? 
ocfs2_change_extent_flag+0x273/0x450 [ocfs2]
Mar 14 10:00:55 vhost032 kernel:  [] ? 
ocfs2_mark_extent_written+0x110/0x1d0 [ocfs2]
Mar 14 10:00:55 vhost032 kernel:  [] ? 
ocfs2_dio_end_io_write+0x44d/0x600 [ocfs2]
Mar 14 10:00:55 vhost032 kernel:  [] ? 
ocfs2_allocate_extend_trans+0x180/0x180 [ocfs2]
Mar 14 10:00:55 vhost032 kernel:  [] ? 
ocfs2_dio_end_io+0x3b/0x60 [ocfs2]
Mar 14 10:00:55 vhost032 kernel:  [] ? dio_complete+0x7e/0x190
Mar 14 10:00:55 vhost032 kernel:  [] ? 
do_blockdev_direct_IO+0x2168/0x2860
Mar 14 10:00:55 vhost032 kernel:  [] ? 
ocfs2_write_end_nolock+0x550/0x550 [ocfs2]
Mar 14 10:00:55 vhost032 kernel:  [] ? 
ocfs2_direct_IO+0x83/0x90 [ocfs2]
Mar 14 10:00:55 vhost032 kernel:  [] ? 
generic_file_direct_write+0xb3/0x180
Mar 14 10:00:55 vhost032 kernel:  [] ? 
__generic_file_write_iter+0xb6/0x1e0
Mar 14 10:00:55 vhost032 kernel:  [] ? 
ocfs2_file_write_iter+0x44e/0xae0 [ocfs2]
Mar 14 10:00:55 vhost032 kernel:  [] ? 
do_iter_readv_writev+0xb0/0x130
Mar 14 10:00:55 vhost032 kernel:  [] ? 
do_readv_writev+0x1ac/0x240
Mar 14 10:00:55 vhost032 kernel:  [] ? 
ocfs2_check_range_for_refcount+0x130/0x130 [ocfs2]
Mar 14 10:00:55 vhost032 kernel:  [] ? do_pwritev+0x8c/0xc0
Mar 14 10:00:55 vhost032 kernel:  [] ? 
system_call_fast_compare_end+0xc/0x9b
Mar 14 10:00:55 vhost032 kernel: Code: 24 28 48 c7 c1 64 70 be c0 ba 1c 06 00 
00 48 c7 c6 d0 99 bd c0 31 c0 44 89 4c 24 18 e8 18 94 de ff 44 8b 4c 24 18 e9 
26 fc ff ff <0f> 0b 48 8b 04 24 48 83 38 00 75 6c f0

Processed: tagging 846792

2017-03-14 Thread Debian Bug Tracking System 
Processing commands for cont...@bugs.debian.org:

> # 
> https://anonscm.debian.org/cgit/kernel/linux.git/commit/?id=11c12948995995f9d7674b17a8c6f107d083fff7
> tags 846792 + pending
Bug #846792 [src:linux] linux-image-4.8.0-1-amd64: ACPI : EC: EC started delay 
on boot
Added tag(s) pending.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
846792: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846792
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#857608: closed by Ben Hutchings <b...@decadent.org.uk> (Re: Bug#857608: linux-image-4.9.0-2-rt-amd64-unsigned: please build with CONFIG_LATENCYTOP)

2017-03-14 Thread Laurent Bonnaud 
> It adds an extra 4K (2K on 32-bit) to the task_struct for every task
> in the system.  This is not an acceptable cost.

OK, I understand that this can be a problem for systems without a lot of RAM.

> Sorry, you'll have to build a custom kernel to enable this feature.

No, problem!

Thanks anyway,

-- 
Laurent.