Bug#754420: NULL pointer dereference in set_nfsv4_acl_one()
See my report of the same bug(*) in Ubuntu at https://bugs.launchpad.net/debian/+source/linux/+bug/1348670 (*) identification based on a comparison of the stack traces and on the fact that it is a regression introduced in 3.2.60. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140726083621.ga23...@hanuman.astro.su.se
Bug#708070: enable x32 support for the amd64 kernels
On Fri, 25 Jul 2014, Robert de Bath wrote:
On Fri, 25 Jul 2014, Ben Hutchings wrote:
I had an idea how to unblock this, and finally got round to trying it,
and it seems to work. That is, we build in x32 support but require a
run-time parameter to enable. So, please try the attached patch
(against the sid branch), adding "syscall.x32=y" to the kernel command
line.
Okay,
With the flag set the kernel boots happily and runs gcc-mx32 executables.
With the flag off ...
First (simple) thing; with the patch in the kernel tree there is no
configuration to default the x32 switch to on. Thinking ahead to when
this may be well tested, I think it'd be nice if there were a .config
option to default this patch to enabling the x32 syscalls and have a
kernel command line option to disable them in "special cases".
More importantly ... this is rather ugly; I think you're going to get
complaints when ld.so segfaults.
You may want to reinstate the ENOEXEC error for the 'wrong sort' of executables.
# strace ./x
execve("./x", ["./x"], [/* 17 vars */]) = 0
[ Process PID=12286 runs in x32 mode. ]
brk(0) = -1 ENOSYS (Function not implemented)
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOSYS (Function not implemented)
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1
ENOSYS (Function not implemented)
writev(2, [{"./x", 3}, {": ", 2}, {"error while loading shared libra"..., 36}, {": ", 2}, {"", 0}, {"", 0},
{"cannot create cache for search p"..., 35}, {": ", 2}, {"Cannot allocate memory", 22}, {"\n", 1}], 10) = -1 ENOSYS (Function not
implemented)
exit_group(127) = ?
<... exit_group resumed> _exit returned!
) = ?
_exit(127) = ?
<... _exit resumed> _exit returned!
) = ?
--- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} ---
+++ killed by SIGSEGV +++
Segmentation fault
#
--
Rob. (Robert de Bath )
Re: Bug#708070: enable x32 support for the amd64 kernels
On Sat, 2014-07-26 at 10:52 +0100, Robert de Bath wrote:
> On Fri, 25 Jul 2014, Robert de Bath wrote:
>
> > On Fri, 25 Jul 2014, Ben Hutchings wrote:
> >
> >> I had an idea how to unblock this, and finally got round to trying it,
> >> and it seems to work. That is, we build in x32 support but require a
> >> run-time parameter to enable. So, please try the attached patch
> >> (against the sid branch), adding "syscall.x32=y" to the kernel command
> >> line.
> Okay,
> With the flag set the kernel boots happily and runs gcc-mx32 executables.
>
> With the flag off ...
> First (simple) thing; with the patch in the kernel tree there is no
> configuration to default the x32 switch to on. Thinking ahead to when
> this may be well tested, I think it'd be nice if there were a .config
> option to default this patch to enabling the x32 syscalls and have a
> kernel command line option to disable them in "special cases".
>
> More importantly ... this is rather ugly; I think you're going to get
> complaints when ld.so segfaults.
>
> You may want to reinstate the ENOEXEC error for the 'wrong sort' of
> executables.
[...]
What do you mean, reinstate? This is the same behaviour you get at
present. Well, here's a new version that might do that.
Ben.
--
Ben Hutchings
73.46% of all statistics are made up.
Index: linux/debian/changelog
===
--- linux/debian/changelog (revision 21631)
+++ linux/debian/changelog (working copy)
@@ -1,3 +1,11 @@
+linux (3.14.13-2+x32) UNRELEASED; urgency=medium
+
+ [ Ben Hutchings ]
+ * [amd64] Enable X86_X32 (Closes: #708070)
+ * [amd64] syscall: Make x32 syscall support conditional on a kernel parameter
+
+ -- Ben Hutchings Fri, 25 Jul 2014 01:48:06 +0100
+
linux (3.14.13-2) unstable; urgency=medium
[ Aurelien Jarno ]
Index: linux/debian/config/kernelarch-x86/config-arch-64
===
--- linux/debian/config/kernelarch-x86/config-arch-64 (revision 21631)
+++ linux/debian/config/kernelarch-x86/config-arch-64 (working copy)
@@ -15,7 +15,7 @@
CONFIG_NUMA_EMU=y
CONFIG_PCI_MMCONFIG=y
CONFIG_ISA_DMA_API=y
-# CONFIG_X86_X32 is not set
+CONFIG_X86_X32=y
##
## file: arch/x86/Kconfig.cpu
Index: linux/debian/patches/bugfix/x86/x86-reject-x32-executables-if-x32-abi-not-supported.patch
===
--- linux/debian/patches/bugfix/x86/x86-reject-x32-executables-if-x32-abi-not-supported.patch (revision 0)
+++ linux/debian/patches/bugfix/x86/x86-reject-x32-executables-if-x32-abi-not-supported.patch (working copy)
@@ -0,0 +1,18 @@
+From: Ben Hutchings
+Date: Sat, 26 Jul 2014 15:03:11 +0100
+Subject: x86: Reject x32 executables if x32 ABI not supported
+
+--- a/arch/x86/include/asm/elf.h
b/arch/x86/include/asm/elf.h
+@@ -155,8 +155,9 @@ do { \
+ #define elf_check_arch(x) \
+ ((x)->e_machine == EM_X86_64)
+
+-#define compat_elf_check_arch(x) \
+- (elf_check_arch_ia32(x) || (x)->e_machine == EM_X86_64)
++#define compat_elf_check_arch(x) \
++ (elf_check_arch_ia32(x) || \
++ (IS_ENABLED(CONFIG_X86_X32_ABI) && (x)->e_machine == EM_X86_64))
+
+ #if __USER32_DS != __USER_DS
+ # error "The following code assumes __USER32_DS == __USER_DS"
Index: linux/debian/patches/features/x86/x86-syscall-make-x32-syscall-support-conditional.patch
===
--- linux/debian/patches/features/x86/x86-syscall-make-x32-syscall-support-conditional.patch (revision 0)
+++ linux/debian/patches/features/x86/x86-syscall-make-x32-syscall-support-conditional.patch (working copy)
@@ -0,0 +1,164 @@
+From: Ben Hutchings
+Date: Fri, 25 Jul 2014 01:16:15 +0100
+Subject: x86/syscall: Make x32 syscall support conditional on a kernel parameter
+Bug-Debian: https://bugs.debian.org/708070
+
+Enabling x32 in the standard amd64 kernel would increase its attack
+surface while provide no benefit to the vast majority of its users.
+No-one seems interested in regularly checking for vulnerabilities
+specific to x32 (at least no-one with a white hat).
+
+Still, adding another flavour just to turn on x32 seems wasteful. And
+the only difference on syscall entry is whether we mask the x32 flag
+out of the syscall number before range-checking it.
+
+So replace the mask (andl) instruction with a nop and add a kernel
+parameter "syscall.x32" which allows it to be turned back on again.
+
+Change the comparison instruction to cmpq because the upper 32 bits
+may or may not be cleared by the previous instruction.
+
+--- a/arch/x86/kernel/entry_64.S
b/arch/x86/kernel/entry_64.S
+@@ -618,12 +618,14 @@ GLOBAL(system_call_after_swapgs)
+ testl $_TIF_WORK_SYSCALL_ENTRY,TI_flags+THREAD_INFO(%rsp,RIP-ARGOFFSET)
+ jnz tracesys
+ system_call_fastpath:
+-#if __SYSCALL_MASK == ~0
+- cmpq $__NR_syscall_max,%rax
+-#else
+- andl $__SYSCALL_MASK,%eax
+- cmpl $__NR_syscall_max,%eax
++#if __SYSCALL_
Bug#756134: linux: French debconf templates translation
Source: linux
Version: 3.14.13-2
Severity: wishlist
Tags: l10n patch
Hi,
Please find attached the French debconf templates translation, proofread
by the debian-l10n-french mailing list contributors.
This file should be put as debian/po/fr.po in your package build tree.
Regards
David
-- System Information:
Debian Release: jessie/sid
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500,
'unstable'), (500, 'testing'), (500, 'stable'), (100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16-rc6-amd64 (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
# Translation of linux debconf templates to French
# Copyright (C) 2010, 2011, 2014 Debian French l10n team
# This file is distributed under the same license as the linux package.
#
# David Prévot , 2010, 2011, 2014.
msgid ""
msgstr ""
"Project-Id-Version: linux 3.14.13-2\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2014-07-20 22:37+0200\n"
"PO-Revision-Date: 2014-07-26 11:59-0400\n"
"Last-Translator: David Prévot \n"
"Language-Team: French \n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Lokalize 1.5\n"
"Plural-Forms: nplurals=2; plural=(n > 1);\n"
#. Type: boolean
#. Description
#: ../image.plain.templates.in:2001
msgid "Abort installation after depmod error?"
msgstr "Abandonner l'installation après l'erreur de depmod ?"
#. Type: boolean
#. Description
#: ../image.plain.templates.in:2001
msgid ""
"The 'depmod' command exited with the exit code ${exit_value} "
"(${SIGNAL}${CORE})."
msgstr ""
"La commande depmod s’est terminée avec le code de retour ${exit_value} "
"(${SIGNAL} ${CORE})."
#. Type: boolean
#. Description
#: ../image.plain.templates.in:2001
msgid ""
"Since this image uses initrd, the ${modules_base}/@abiname@@localversion@/"
"modules.dep file will not be deleted, even though it may be invalid."
msgstr ""
"Puisque cette image du noyau utilise initrd, le fichier ${modules_base}/"
"@abiname@@localversion@/modules.dep ne sera pas effacé, mais il peut ne pas "
"être valable."
#. Type: boolean
#. Description
#: ../image.plain.templates.in:2001
msgid ""
"You should abort the installation and fix the errors in depmod, or "
"regenerate the initrd image with a known good modules.dep file. If you don't "
"abort the installation, there is a danger that the system will fail to boot."
msgstr ""
"Vous devriez abandonner l’installation et corriger les erreurs de dépendance "
"entre les modules du noyau (depmod), ou créer une nouvelle image initrd avec "
"un fichier modules.dep valable. Si vous n’annulez pas l’installation, le "
"système risque de ne pas redémarrer correctement."
#. Type: boolean
#. Description
#: ../image.plain.templates.in:3001
msgid "Abort kernel removal?"
msgstr "Abandonner la suppression du noyau ?"
#. Type: boolean
#. Description
#: ../image.plain.templates.in:3001
msgid ""
"You are running a kernel (version ${running}) and attempting to remove the "
"same version."
msgstr ""
"Le noyau actuellement utilisé (version ${running}) est en train d'être "
"supprimé."
#. Type: boolean
#. Description
#: ../image.plain.templates.in:3001
msgid ""
"This can make the system unbootable as it will remove /boot/vmlinuz-"
"${running} and all modules under the directory /lib/modules/${running}. This "
"can only be fixed with a copy of the kernel image and the corresponding "
"modules."
msgstr ""
"Le système risque de ne plus pouvoir démarrer car /boot/vmlinuz-${running} "
"sera enlevé ainsi que tous les modules du répertoire /lib/modules/"
"${running}. Cela peut seulement être réparé avec une copie de l'image du "
"noyau et des modules correspondants."
#. Type: boolean
#. Description
#: ../image.plain.templates.in:3001
msgid ""
"It is highly recommended to abort the kernel removal unless you are prepared "
"to fix the system after removal."
msgstr ""
"Interrompre la suppression du noyau est fortement recommandé à moins d’être "
"ensuite capable de réparer le système."
#. Type: note
#. Description
#: ../image.plain.templates.in:4001
msgid "Boot loader configuration must be updated to load initramfs"
msgstr ""
"La configuration du chargeur de démarrage doit être mise à jour pour charger "
"le système de fichiers initial en mémoire"
#. Type: note
#. Description
#: ../image.plain.templates.in:4001
#| msgid ""
#| "This kernel package will build an \"initramfs\" file (/boot/initrd.img-"
#| "@abiname@) for the system's boot loader to use in addition to the kernel "
#| "itself. This method, formerly unsupported on MIPS, enables a more "
#| "flexible boot process, and future kernel versions may require a "
#| "corresponding initrd.img to boot."
msgid ""
"This kernel package will build an \"initramfs\" file (/boot/initrd.img-"
"@abiname@@localversion@) for the system's boot loader to use in addition to "
"the
Bug#747922: kernel hang during boot on s390x in a virtual machine under z/VM when logged on to a terminal
I have been working with upstream on this. Upstream has sent me a patch, which I have applied and tested, and it seems to fix the problem. Here is a link to the patch: http://users.wowway.com/~zlinuxman/119-3215-hangs.diff This patch is not yet official, but an official patch should be submitted to kernel.org soon, if it hasn't been already. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/108995111.135436.1406396813691.javamail.r...@md01.wow.synacor.com
Re: Random panic in load_balance() with 3.16-rc
Hi Michel, On 25/07/14 02:25, Michel Dänzer wrote: > Attached is fair.s from Debian gcc 4.8.3-5. Does that look better? I'm > going to try reproducing the problem with a kernel built by that now. It looks like gcc-4.9 Debian package version 4.9.1-2 available in sid/jessie may have already fixed this (though Debian's buildd systems may not have been updated with it yet). If you are able to test with that version and let us know, that would be wonderful. Thank you, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53d3ed27.7080...@pyro.eu.org
Bug#756145: linux-image-3.14-1-amd64: btrfs fails to remove missing drive, add new, ...
Package: src:linux Version: 3.14.12-1 Severity: important Dear Maintainer, Running an up-to-date Jessie system. I had a failing drive in a btrfs raid 10 array (6 drives), I physically removed the drive and added a replacement. Mounting degraded works, but I'm unable to remove the 'missing' device or add the new. The kernel starts throwing stacktraces about blocked/hung tasks. No btrfs related disk activity is seen at that time. The traces also appear in /var/log/kern.log, as shown below. Best regards, Steven Jul 26 19:58:33 pc-steven kernel: [ 157.472159] BTRFS: device label dataarray devid 9 transid 953814 /dev/sdh Jul 26 19:58:33 pc-steven kernel: [ 157.484591] BTRFS info (device sdc): allowing degraded mounts Jul 26 19:58:33 pc-steven kernel: [ 157.484617] BTRFS info (device sdc): disk space caching is enabled Jul 26 19:59:14 pc-steven kernel: [ 198.658728] BTRFS info (device sdc): relocating block group 31270579011584 flags 65 Jul 26 20:01:56 pc-steven kernel: [ 360.187850] INFO: task btrfs- transacti:3203 blocked for more than 120 seconds. Jul 26 20:01:56 pc-steven kernel: [ 360.187934] Tainted: G O 3.14-1-amd64 #1 Jul 26 20:01:56 pc-steven kernel: [ 360.187988] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Jul 26 20:01:56 pc-steven kernel: [ 360.188070] btrfs-transacti D 880214ac9a88 0 3203 2 0x Jul 26 20:01:56 pc-steven kernel: [ 360.188076] 880214ac9670 0046 00014380 8800a4dbbfd8 Jul 26 20:01:56 pc-steven kernel: [ 360.188079] 00014380 880214ac9670 88009e21de50 8802151dc1e8 Jul 26 20:01:56 pc-steven kernel: [ 360.188083] 8802151dc1e8 88009e21cb00 Jul 26 20:01:56 pc-steven kernel: [ 360.188084] Call Trace: Jul 26 20:01:56 pc-steven kernel: [ 360.188149] [] ? wait_current_trans.isra.21+0x97/0xf0 [btrfs] Jul 26 20:01:56 pc-steven kernel: [ 360.188159] [] ? prepare_to_wait_event+0xf0/0xf0 Jul 26 20:01:56 pc-steven kernel: [ 360.188186] [] ? start_transaction+0x278/0x550 [btrfs] Jul 26 20:01:56 pc-steven kernel: [ 360.188213] [] ? transaction_kthread+0x73/0x240 [btrfs] Jul 26 20:01:56 pc-steven kernel: [ 360.188236] [] ? btrfs_cleanup_transaction+0x510/0x510 [btrfs] Jul 26 20:01:56 pc-steven kernel: [ 360.188243] [] ? kthread+0xb8/0xd0 Jul 26 20:01:56 pc-steven kernel: [ 360.188247] [] ? kthread_create_on_node+0x170/0x170 Jul 26 20:01:56 pc-steven kernel: [ 360.188252] [] ? ret_from_fork+0x7c/0xb0 Jul 26 20:01:56 pc-steven kernel: [ 360.188255] [] ? kthread_create_on_node+0x170/0x170 Jul 26 20:01:56 pc-steven kernel: [ 360.188259] INFO: task btrfs:3205 blocked for more than 120 seconds. Jul 26 20:01:56 pc-steven kernel: [ 360.188260] Tainted: G O 3.14-1-amd64 #1 Jul 26 20:01:56 pc-steven kernel: [ 360.188261] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Jul 26 20:01:56 pc-steven kernel: [ 360.188267] btrfs D 8801efe42f38 0 3205 3132 0x Jul 26 20:01:56 pc-steven kernel: [ 360.188271] 8801efe42b20 0086 00014380 8800a4dbdfd8 Jul 26 20:01:56 pc-steven kernel: [ 360.188274] 00014380 8801efe42b20 88021fa14c10 88021fdcde08 Jul 26 20:01:56 pc-steven kernel: [ 360.188277] 0002 8111f380 8800a4dbd740 8800a4dbd828 Jul 26 20:01:56 pc-steven kernel: [ 360.188278] Call Trace: Jul 26 20:01:56 pc-steven kernel: [ 360.188284] [] ? wait_on_page_read+0x60/0x60 Jul 26 20:01:56 pc-steven kernel: [ 360.188290] [] ? io_schedule+0x94/0x130 Jul 26 20:01:56 pc-steven kernel: [ 360.188293] [] ? sleep_on_page+0x5/0x10 Jul 26 20:01:56 pc-steven kernel: [ 360.188298] [] ? __wait_on_bit+0x54/0x80 Jul 26 20:01:56 pc-steven kernel: [ 360.188302] [] ? wait_on_page_bit+0x7f/0x90 Jul 26 20:01:56 pc-steven kernel: [ 360.188307] [] ? autoremove_wake_function+0x30/0x30 Jul 26 20:01:56 pc-steven kernel: [ 360.188312] [] ? pagevec_lookup_tag+0x18/0x20 Jul 26 20:01:56 pc-steven kernel: [ 360.188316] [] ? filemap_fdatawait_range+0xd0/0x160 Jul 26 20:01:56 pc-steven kernel: [ 360.188346] [] ? btrfs_wait_ordered_range+0x65/0x120 [btrfs] Jul 26 20:01:56 pc-steven kernel: [ 360.188373] [] ? __btrfs_write_out_cache+0x6fe/0x8f0 [btrfs] Jul 26 20:01:56 pc-steven kernel: [ 360.188399] [] ? btrfs_write_out_cache+0x99/0xd0 [btrfs] Jul 26 20:01:56 pc-steven kernel: [ 360.188424] [] ? btrfs_write_dirty_block_groups+0x58e/0x680 [btrfs] Jul 26 20:01:56 pc-steven kernel: [ 360.188444] [] ? commit_cowonly_roots+0x14b/0x202 [btrfs] Jul 26 20:01:56 pc-steven kernel: [ 360.188469] [] ? btrfs_commit_transaction+0x42a/0x990 [btrfs] Jul 26 20:01:56 pc-steven kernel: [ 360.188491] [] ? start_transaction+0x8b/0x550 [btrfs] Jul 26 20:01:56 pc-steven kernel: [ 360.188517] [] ? prepare_to_relocate+0xef/0x1b0 [btrfs] Jul 26 20:01:56 pc-steven kernel: [ 360.188540] [] ? relocate_block_group+0x
Re: Random panic in load_balance() with 3.16-rc
On Fri, Jul 25, 2014 at 11:29 AM, Linus Torvalds wrote: > > I'm sure it's possible, but it sounds potentially complicated. Hmm. The bugzilla entry just taught me a new gcc flag: "-fcompare-debug". That apparently makes gcc compile things twice, once with debugging and once without, and verify that the result is the same. And you can enable it for the whole kernel build with just a simple export GCC_COMPARE_DEBUG=1 before doing the build. It actually results in a failure for me even on my standard small localized kernel build, even with gcc-4.8.3. I get a compare failure for (at least) fs/ext4/inode.c. That's a bit worrisome. I haven't actually checked if the code generation differs in significant ways yet.. Linus -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/ca+55afyhu4gwk6astuogh3efpshkgy1s5zc4p7f01dwrydd...@mail.gmail.com
Re: Random panic in load_balance() with 3.16-rc
On Sat, Jul 26, 2014 at 11:28 AM, Linus Torvalds wrote: > > That's a bit worrisome. I haven't actually checked if the code > generation differs in significant ways yet.. Nope. Just three instructions that got re-ordered from ABC to CAB in a way that makes no difference. But just the knowledge that "-g" affects code generation is nasty. And with "allmodconfig" my build fails almost immediately (failures on at least arch/x86/kernel/process_64.c, kernel/exit.c and mm/vmalloc.c in that case. I was too lazy to check what the differences were). Does anybody have current gcc build and can verify that current gcc tip passes the kernel compile with that export GCC_COMPARE_DEBUG=1 thing? Linus -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/ca+55afxaxpqydjv-snu6giy3ekcu_sy1wof1nannptbtf9r...@mail.gmail.com
Bug#756147: scsi-common-modules-3.2.0-4-amd64-di: cannot PXE install on VMware
Package: scsi-common-modules-3.2.0-4-amd64-di Severity: important Tags: d-i Dear Maintainer, * What led up to the situation? installing on vmware by way of PXE using netboot initrd * What exactly did you do (or not do) that was effective (or ineffective)? creating a local repo cloning the ISO, with the addition of the scsi-common-modules * What was the outcome of this action? installation was successful * What outcome did you expect instead? -- System Information: Debian Release: 7.5 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140726184632.11445.98129.report...@repo-v01.dev.ord1.stabletransit.com
Re: Random panic in load_balance() with 3.16-rc
On Sat, Jul 26, 2014 at 09:35:57PM +0200, Markus Trippelsdorf wrote: > > But fortunately the workaround for the new inode.c bug is the same as > for the original bug: -fno-var-tracking-assignments. > > It would make sense to enabled it unconditionally for all debug > configurations for now. What's the downside of enabling this unconditionally on a compiler with the bug fixed? I assume a certain amount of optimization will lost, but is it significant/measurable? - Ted -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140726195503.gj6...@thunk.org
Re: Random panic in load_balance() with 3.16-rc
On 2014.07.26 at 11:39 -0700, Linus Torvalds wrote: > On Sat, Jul 26, 2014 at 11:28 AM, Linus Torvalds > wrote: > > > > That's a bit worrisome. I haven't actually checked if the code > > generation differs in significant ways yet.. > > Nope. Just three instructions that got re-ordered from ABC to CAB in a > way that makes no difference. But just the knowledge that "-g" affects > code generation is nasty. And with "allmodconfig" my build fails > almost immediately (failures on at least arch/x86/kernel/process_64.c, > kernel/exit.c and mm/vmalloc.c in that case. I was too lazy to check > what the differences were). > > Does anybody have current gcc build and can verify that current gcc > tip passes the kernel compile with that > > export GCC_COMPARE_DEBUG=1 > > thing? The fs/ext4/inode.c issue is a variant of the gcc bug and isn't fixed yet. I will open a bug report. The kernel/exit.c issue is already fixed, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61801 for a reduced testcase. But fortunately the workaround for the new inode.c bug is the same as for the original bug: -fno-var-tracking-assignments. It would make sense to enabled it unconditionally for all debug configurations for now. -- Markus -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140726193557.GA21842@x4
Bug#708070: enable x32 support for the amd64 kernels
On Sat, 26 Jul 2014, Ben Hutchings wrote:
On Sat, 2014-07-26 at 10:52 +0100, Robert de Bath wrote:
On Fri, 25 Jul 2014, Robert de Bath wrote:
On Fri, 25 Jul 2014, Ben Hutchings wrote:
What do you mean, reinstate? This is the same behaviour you get at
present. Well, here's a new version that might do that.
I was sure ... hmmm, segfault? ... Oh I see.
I'd copied the (static) exe to a wheezy (3.2 kernel) machine; that's
where it gives a 'cannot execute' error. I suppose that means it's an
upstream 'bug'.
Okay, the new patch is good for me. I've again tried it with the flag
both ways. It runs the executables correctly when the flag is set and
gives a reasonably nice (and quite specific) error when it's not. ("Exec
format error")
I also have a i386 userspace running happily.
I'd say it's good to go.
Ben.
--
Ben Hutchings
73.46% of all statistics are made up.
--
Rob. (Robert de Bath )
Bug#756145: regression in Linux kernel when using btrfs
Hi, This all works properly when booting from a previous kernel. 3.13.10 (according to uname -a). Best regards, Steven -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAMDu+mN+w0dFuUXz2MU7NfwbJ0KsURqrFJYbg3UR=2txhlb...@mail.gmail.com
Re: Random panic in load_balance() with 3.16-rc
On Sat, Jul 26, 2014 at 12:35 PM, Markus Trippelsdorf wrote: > > But fortunately the workaround for the new inode.c bug is the same as > for the original bug: -fno-var-tracking-assignments. > > It would make sense to enabled it unconditionally for all debug > configurations for now. So how is code generation affected - if at all? Does the whole "var-tracking-assignments" thing *only* matter for debug information? Also, when was it introduced as an option? Can we just unconditionally enable it, or do we need to be careful about gcc versions? I'd *like* a debug kernel to not differ significantly from a non-debug kernel. Most sane kernel developers (where "sane" is "me" by definition) do not tend to use debug kernels, because the debug overhead is absolutely disgustingly enormous at build time. But if we then have most users using distro kernels that had debug info enabled, it would be sad if code generation differences are huge. So I'd prefer to just unconditionally add that "-fno-var-tracking-assignments" to the build. I just tested it on one file (fs/dcache.c) and it made no difference at all for my non-debug build. Is this expected? Because if the only effect of "-fno-var-tracking-assignments" is potentially slightly worse debug information for variables, I'll enable it in a jiffy if it fixes this code generation bug. But I'd like to get that confirmed. Finally, for CONFIG_DEBUG_INFO_REDUCED, we already use "-fno-var-tracking". Is that a stronger version that also disables "var-tracking-assignments"? Also, Michel - can you try this patch if you still have your gcc-4.9.0 install, and send me the resulting fair.s file again? Linus Makefile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Makefile b/Makefile index 6b2774145d66..5147f3f23504 100644 --- a/Makefile +++ b/Makefile @@ -688,6 +688,8 @@ KBUILD_CFLAGS += -fomit-frame-pointer endif endif +KBUILD_CFLAGS += $(call cc-option, -fno-var-tracking-assignments) + ifdef CONFIG_DEBUG_INFO KBUILD_CFLAGS += -g KBUILD_AFLAGS += -Wa,-gdwarf-2
Re: Random panic in load_balance() with 3.16-rc
On Sat, Jul 26, 2014 at 12:56 PM, Linus Torvalds wrote: > > Also, Michel - can you try this patch if you still have your > gcc-4.9.0 install, and send me the resulting fair.s file again? Hmm. The good news is that with that patch, the GCC_COMPARE_DEBUG build succeeds. At least for my small local config. So I think that's the answer for now, although I'll wait to hear about any possible non-debug downsides.. Linus -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CA+55aFzLR9+ocixniVBUV=TjDzbWF6w+7b8rE=p42lthmpx...@mail.gmail.com
Re: Random panic in load_balance() with 3.16-rc
On 2014.07.26 at 12:56 -0700, Linus Torvalds wrote: > On Sat, Jul 26, 2014 at 12:35 PM, Markus Trippelsdorf > wrote: > > > > But fortunately the workaround for the new inode.c bug is the same as > > for the original bug: -fno-var-tracking-assignments. > > > > It would make sense to enabled it unconditionally for all debug > > configurations for now. > > So how is code generation affected - if at all? Does the whole > "var-tracking-assignments" thing *only* matter for debug information? Yes. It should only affect the quality of the debugging information. If code generation is affected it is a compiler bug. > Also, when was it introduced as an option? Can we just unconditionally > enable it, or do we need to be careful about gcc versions? Git blame says it was introduced: Wed Sep 2 02:42:21 2009. > I'd *like* a debug kernel to not differ significantly from a non-debug > kernel. Most sane kernel developers (where "sane" is "me" by > definition) do not tend to use debug kernels, because the debug > overhead is absolutely disgustingly enormous at build time. But if we > then have most users using distro kernels that had debug info enabled, > it would be sad if code generation differences are huge. > > So I'd prefer to just unconditionally add that > "-fno-var-tracking-assignments" to the build. > > I just tested it on one file (fs/dcache.c) and it made no difference > at all for my non-debug build. Is this expected? Yes. The option only affects -g builds. > Because if the only effect of "-fno-var-tracking-assignments" is > potentially slightly worse debug information for variables, I'll > enable it in a jiffy if it fixes this code generation bug. But I'd > like to get that confirmed. > > Finally, for CONFIG_DEBUG_INFO_REDUCED, we already use > "-fno-var-tracking". Is that a stronger version that also disables > "var-tracking-assignments"? Yes. So, the option should only be enabled for debugging builds. Something like the following should be sufficient: diff --git a/Makefile b/Makefile index 6b2774145d66..037b78d0f407 100644 --- a/Makefile +++ b/Makefile @@ -689,7 +689,7 @@ endif endif ifdef CONFIG_DEBUG_INFO -KBUILD_CFLAGS += -g +KBUILD_CFLAGS += -g -fno-var-tracking-assignments KBUILD_AFLAGS += -Wa,-gdwarf-2 endif -- Markus -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140726201914.GB21842@x4
Re: Random panic in load_balance() with 3.16-rc
On 2014.07.26 at 15:55 -0400, Theodore Ts'o wrote: > On Sat, Jul 26, 2014 at 09:35:57PM +0200, Markus Trippelsdorf wrote: > > > > But fortunately the workaround for the new inode.c bug is the same as > > for the original bug: -fno-var-tracking-assignments. > > > > It would make sense to enabled it unconditionally for all debug > > configurations for now. > > What's the downside of enabling this unconditionally on a compiler > with the bug fixed? I assume a certain amount of optimization will > lost, but is it significant/measurable? Only the quality of the debug info would suffer a bit. -- Markus -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140726202055.GC21842@x4
Re: Random panic in load_balance() with 3.16-rc
On Sat, Jul 26, 2014 at 1:19 PM, Markus Trippelsdorf wrote: > > Yes. The option only affects -g builds. Ok, good. I'll wait a bit to hopefully get confirmation from Michel's setup, but this does seem to be the solution. > So, the option should only be enabled for debugging builds. Something > like the following should be sufficient: Actually, I prefer my patch that did it with cc-option checking, and does it unconditionally. Because if we do it even for non-debug builds - where it ostensibly shouldn't matter - we then have that GCC_COMPARE_DEBUG thing working regardless of configuration. Linus -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/ca+55afych8b4kuc66_+wr8em+kp7-hj9utdtplih661xf8y...@mail.gmail.com
Re: Random panic in load_balance() with 3.16-rc
On Sat, Jul 26, 2014 at 10:20:55PM +0200, Markus Trippelsdorf wrote: > On 2014.07.26 at 15:55 -0400, Theodore Ts'o wrote: > > On Sat, Jul 26, 2014 at 09:35:57PM +0200, Markus Trippelsdorf wrote: > > > > > > But fortunately the workaround for the new inode.c bug is the same as > > > for the original bug: -fno-var-tracking-assignments. > > > > > > It would make sense to enabled it unconditionally for all debug > > > configurations for now. > > > > What's the downside of enabling this unconditionally on a compiler > > with the bug fixed? I assume a certain amount of optimization will > > lost, but is it significant/measurable? > > Only the quality of the debug info would suffer a bit. Which for various tools that use kernel's debug info is a significant difference. So adding the option even for fixed gcc is undesirable (and, tracking gcc version numbers only is not enough, I guess most of the distro gccs will backport the fix soon). This PR is the first -fcompare-debug wrong-code in the last few years I remember. There are -fcompare-debug failures from time to time, but usually they are just that either there is insignificant code change or no change at all, just changes in the text dump files -fcompare-debug uses to check whether there might be code differences or not. GCC's stated goal is that -g should not affect code generation, so we treat all such differences as bugs, but most of the time they aren't breaking anything. Jakub -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140726220842.gi2...@laptop.redhat.com
Bug#752881: Verified bugfix against kernel v3.2
Please find attached a patch against mainline kernel v3.2 which works.
I git bisected the bug down to the exact revision that caused the
problem and then
modified a revert of that change compiles against the wheezy kernel
and it verified that
it avoids the problem.
The change relates to failing scanning block drives related to whether
they are partition-able or
removable. I intend to try and dig into exactly which part of the
change causes the problems
and produce a more refined patch over the next week or two.
I verified the bug occurs exactly after this change :
d27769ec3df1a8de9ca450d2dcd72d1ab259ba32 is the first bad commit
commit d27769ec3df1a8de9ca450d2dcd72d1ab259ba32
Author: Tejun Heo
Date: Tue Aug 23 20:01:04 2011 +0200
block: add GENHD_FL_NO_PART_SCAN
There are cases where suppressing partition scan is useful - e.g. for
lo devices and pseudo SATA devices which advertise to be a disk but
get upset on partition scan (some port multiplier control devices show
such behavior).
This patch adds GENHD_FL_NO_PART_SCAN which suppresses partition scan
regardless of the number of possible partitions. disk_partitionable()
is renamed to disk_part_scan_enabled() as suppressing partition scan
doesn't imply the device can't be partitioned using
BLKPG_ADD/DEL_PARTITION calls from userland. show_partition() now
directly tests disk_max_parts() to maintain backward-compatibility.
-v2: Updated to make it clear that only partition scan is suppressed
not partitioning itself as suggested by Kay Sievers.
Signed-off-by: Tejun Heo
Cc: Kay Sievers
Signed-off-by: Jens Axboe
:04 04 05decd4a5722a2a030f7ae6c45f8d87830e08535
a442a00c3630f2077a40fb73b8d42d9dffe7c088 M block
:04 04 b310f91da334e2c0ee045dbec568e546b1088f3c
f83dbd8ae782e8abcffb701dab31ad52cd5e3d4c M fs
:04 04 aa8618099f709f83f86b6b6cabc56bf14578538b
81e14f1a38d9af64148236b31c0f23350608ba8c M include
git bisect start
# bad: [8a9c594422ecad912d6470888acdee9a1236ad68]
drivers/block/loop.c: emit uevent on auto release
git bisect bad 8a9c594422ecad912d6470888acdee9a1236ad68
# good: [02f8c6aee8df3cdc935e9bdd4f2d020306035dbe] Linux 3.0
git bisect good 02f8c6aee8df3cdc935e9bdd4f2d020306035dbe
# good: [0003230e8200699860f0b10af524dc47bf8aecad] Merge branch
'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6
git bisect good 0003230e8200699860f0b10af524dc47bf8aecad
# good: [206d440f64030b6425841bf7cb38e26a5ea0c382] xfs: Fix build
breakage in xfs_iops.c when CONFIG_FS_POSIX_ACL is not set
git bisect good 206d440f64030b6425841bf7cb38e26a5ea0c382
# skip: [c11abbbaa3252875c5740a6880b9a1a6f1e2a870] Merge branch
'slub/lockless' of
git://git.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6
git bisect skip c11abbbaa3252875c5740a6880b9a1a6f1e2a870
# good: [322a8b034003c0d46d39af85bf24fee27b902f48] Linux 3.1-rc1
git bisect good 322a8b034003c0d46d39af85bf24fee27b902f48
# good: [5eedf5415cd57f8db8642a5db4cf8e5507390030] nbd: replace some
printk with dev_warn() and dev_info()
git bisect good 5eedf5415cd57f8db8642a5db4cf8e5507390030
# bad: [e8b177cedc39b092e423b8cbc687dbf096a1de47] Merge branch
'for-3.2/core' into for-3.2/drivers
git bisect bad e8b177cedc39b092e423b8cbc687dbf096a1de47
# good: [dfaa2ef68e80c378e610e3c8c536f1c239e8d3ef] loop: add discard
support for loop devices
git bisect good dfaa2ef68e80c378e610e3c8c536f1c239e8d3ef
# bad: [d27769ec3df1a8de9ca450d2dcd72d1ab259ba32] block: add
GENHD_FL_NO_PART_SCAN
git bisect bad d27769ec3df1a8de9ca450d2dcd72d1ab259ba32
git diff d27769ec3df1a8de9ca450d2dcd72d1ab259ba32~
d27769ec3df1a8de9ca450d2dcd72d1ab259ba32
diff --git a/block/genhd.c b/block/genhd.c
index 5cb51c5..2429ecb 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -536,7 +536,7 @@ void register_disk(struct gendisk *disk)
disk->slave_dir = kobject_create_and_add("slaves", &ddev->kobj);
/* No minors to use for partitions */
- if (!disk_partitionable(disk))
+ if (!disk_part_scan_enabled(disk))
goto exit;
/* No such device (e.g., media were just removed) */
@@ -841,7 +841,7 @@ static int show_partition(struct seq_file *seqf, void *v)
char buf[BDEVNAME_SIZE];
/* Don't show non-partitionable removeable devices or empty devices */
- if (!get_capacity(sgp) || (!disk_partitionable(sgp) &&
+ if (!get_capacity(sgp) || (!disk_max_parts(sgp) &&
(sgp->flags & GENHD_FL_REMOVABLE)))
return 0;
if (sgp->flags & GENHD_FL_SUPPRESS_PARTITION_INFO)
diff --git a/block/ioctl.c b/block/ioctl.c
index 1124cd2..5c74efc 100644
--- a/block/ioctl.c
+++ b/block/ioctl.c
@@ -101,7 +101,7 @@ static int blkdev_reread_part(struct block_device *bdev)
struct gendisk *disk = bdev->bd_disk;
int res;
- if (!disk_partitionable(disk) || bdev != bdev->bd_contains)
+ if (!disk_part_scan_enabled(disk) || bdev !=
Re: Bug#708070: enable x32 support for the amd64 kernels
On Sat, 2014-07-26 at 21:05 +0100, Robert de Bath wrote:
> On Sat, 26 Jul 2014, Ben Hutchings wrote:
>
> > On Sat, 2014-07-26 at 10:52 +0100, Robert de Bath wrote:
> >> On Fri, 25 Jul 2014, Robert de Bath wrote:
> >>
> >>> On Fri, 25 Jul 2014, Ben Hutchings wrote:
> >>>
> > What do you mean, reinstate? This is the same behaviour you get at
> > present. Well, here's a new version that might do that.
> I was sure ... hmmm, segfault? ... Oh I see.
>
> I'd copied the (static) exe to a wheezy (3.2 kernel) machine; that's
> where it gives a 'cannot execute' error.
Linux 3.2 predates addition of x32 support.
> I suppose that means it's an upstream 'bug'.
Yes, I would say so.
> Okay, the new patch is good for me. I've again tried it with the flag
> both ways. It runs the executables correctly when the flag is set and
> gives a reasonably nice (and quite specific) error when it's not. ("Exec
> format error")
>
> I also have a i386 userspace running happily.
>
> I'd say it's good to go.
Great!
But I should maybe add the config option you suggested, so people can
build custom kernels from Debian source that won't need this parameter.
Ben.
--
Ben Hutchings
The generation of random numbers is too important to be left to chance.
- Robert Coveyou
signature.asc
Description: This is a digitally signed message part
Bug#708070: [PATCH] x86: Reject x32 executables if x32 ABI not supported
It is currently possible to execve() an x32 executable on an x86_64
kernel that has only ia32 compat enabled. However all its syscalls
will fail, even _exit(). This usually causes it to segfault.
Change the ELF compat architecture check so that x32 executables are
rejected if we don't support the x32 ABI.
Signed-off-by: Ben Hutchings
---
arch/x86/include/asm/elf.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/elf.h b/arch/x86/include/asm/elf.h
index 1a055c8..ca3347a 100644
--- a/arch/x86/include/asm/elf.h
+++ b/arch/x86/include/asm/elf.h
@@ -160,8 +160,9 @@ do {\
#define elf_check_arch(x) \
((x)->e_machine == EM_X86_64)
-#define compat_elf_check_arch(x) \
- (elf_check_arch_ia32(x) || (x)->e_machine == EM_X86_64)
+#define compat_elf_check_arch(x) \
+ (elf_check_arch_ia32(x) || \
+(IS_ENABLED(CONFIG_X86_X32_ABI) && (x)->e_machine == EM_X86_64))
#if __USER32_DS != __USER_DS
# error "The following code assumes __USER32_DS == __USER_DS"
--
Ben Hutchings
The generation of random numbers is too important to be left to chance.
- Robert Coveyou
signature.asc
Description: This is a digitally signed message part
Bug#756170: nfs-kernel-server: nfs man page lists incorrect info for timeo option
Package: nfs-kernel-server Severity: normal Dear Maintainer, I believe that the man page for nfs is incorrect. i have been using soft mounts with a timeo=40. the info on the man page says this value is in tenths of a second. i believe that it is actually in seconds. please fix the man page to refelct the working value. -- System Information: Debian Release: 7.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140727032119.3611.41432.reportbug@7-14
Bug#756171: nfs-kernel-server: nfs timeo option incorrectly documented to be in tenths of a second
Package: nfs-kernel-server Severity: normal Dear Maintainer, i have been testing nfs on my wheezy system. everything is working ok, but i am using a soft mount with a timeo=40. I believe that in the man file, timeo is documented to be in tenths of a second. however i believe that the actual value is in seconds. please fix the man page. -- System Information: Debian Release: 7.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140727031202.3346.94804.reportbug@7-14
