linux_4.8.11-1_multi.changes is NEW
binary:affs-modules-4.8.0-2-4kc-malta-di is NEW. binary:affs-modules-4.8.0-2-5kc-malta-di is NEW. binary:affs-modules-4.8.0-2-loongson-3-di is NEW. binary:affs-modules-4.8.0-2-octeon-di is NEW. binary:ata-modules-4.8.0-2-4kc-malta-di is NEW. binary:ata-modules-4.8.0-2-5kc-malta-di is NEW. binary:ata-modules-4.8.0-2-loongson-3-di is NEW. binary:btrfs-modules-4.8.0-2-4kc-malta-di is NEW. binary:btrfs-modules-4.8.0-2-5kc-malta-di is NEW. binary:btrfs-modules-4.8.0-2-loongson-3-di is NEW. binary:btrfs-modules-4.8.0-2-marvell-di is NEW. binary:btrfs-modules-4.8.0-2-octeon-di is NEW. binary:btrfs-modules-4.8.0-2-versatile-di is NEW. binary:cdrom-core-modules-4.8.0-2-4kc-malta-di is NEW. binary:cdrom-core-modules-4.8.0-2-5kc-malta-di is NEW. binary:cdrom-core-modules-4.8.0-2-loongson-3-di is NEW. binary:cdrom-core-modules-4.8.0-2-marvell-di is NEW. binary:cdrom-core-modules-4.8.0-2-octeon-di is NEW. binary:cdrom-core-modules-4.8.0-2-versatile-di is NEW. binary:crc-modules-4.8.0-2-4kc-malta-di is NEW. binary:crc-modules-4.8.0-2-5kc-malta-di is NEW. binary:crc-modules-4.8.0-2-loongson-3-di is NEW. binary:crc-modules-4.8.0-2-marvell-di is NEW. binary:crc-modules-4.8.0-2-octeon-di is NEW. binary:crc-modules-4.8.0-2-versatile-di is NEW. binary:crypto-dm-modules-4.8.0-2-4kc-malta-di is NEW. binary:crypto-dm-modules-4.8.0-2-5kc-malta-di is NEW. binary:crypto-dm-modules-4.8.0-2-loongson-3-di is NEW. binary:crypto-dm-modules-4.8.0-2-marvell-di is NEW. binary:crypto-dm-modules-4.8.0-2-octeon-di is NEW. binary:crypto-dm-modules-4.8.0-2-versatile-di is NEW. binary:crypto-modules-4.8.0-2-4kc-malta-di is NEW. binary:crypto-modules-4.8.0-2-5kc-malta-di is NEW. binary:crypto-modules-4.8.0-2-loongson-3-di is NEW. binary:crypto-modules-4.8.0-2-marvell-di is NEW. binary:crypto-modules-4.8.0-2-octeon-di is NEW. binary:crypto-modules-4.8.0-2-versatile-di is NEW. binary:event-modules-4.8.0-2-4kc-malta-di is NEW. binary:event-modules-4.8.0-2-5kc-malta-di is NEW. binary:event-modules-4.8.0-2-loongson-3-di is NEW. binary:event-modules-4.8.0-2-marvell-di is NEW. binary:event-modules-4.8.0-2-octeon-di is NEW. binary:ext4-modules-4.8.0-2-4kc-malta-di is NEW. binary:ext4-modules-4.8.0-2-5kc-malta-di is NEW. binary:ext4-modules-4.8.0-2-loongson-3-di is NEW. binary:ext4-modules-4.8.0-2-marvell-di is NEW. binary:ext4-modules-4.8.0-2-octeon-di is NEW. binary:ext4-modules-4.8.0-2-versatile-di is NEW. binary:fat-modules-4.8.0-2-4kc-malta-di is NEW. binary:fat-modules-4.8.0-2-5kc-malta-di is NEW. binary:fat-modules-4.8.0-2-loongson-3-di is NEW. binary:fat-modules-4.8.0-2-marvell-di is NEW. binary:fat-modules-4.8.0-2-octeon-di is NEW. binary:fat-modules-4.8.0-2-versatile-di is NEW. binary:fb-modules-4.8.0-2-loongson-3-di is NEW. binary:fb-modules-4.8.0-2-marvell-di is NEW. binary:firewire-core-modules-4.8.0-2-loongson-3-di is NEW. binary:fuse-modules-4.8.0-2-4kc-malta-di is NEW. binary:fuse-modules-4.8.0-2-5kc-malta-di is NEW. binary:fuse-modules-4.8.0-2-loongson-3-di is NEW. binary:fuse-modules-4.8.0-2-marvell-di is NEW. binary:fuse-modules-4.8.0-2-octeon-di is NEW. binary:fuse-modules-4.8.0-2-versatile-di is NEW. binary:hfs-modules-4.8.0-2-4kc-malta-di is NEW. binary:hfs-modules-4.8.0-2-5kc-malta-di is NEW. binary:hfs-modules-4.8.0-2-loongson-3-di is NEW. binary:hfs-modules-4.8.0-2-octeon-di is NEW. binary:i2c-modules-4.8.0-2-4kc-malta-di is NEW. binary:i2c-modules-4.8.0-2-5kc-malta-di is NEW. binary:input-modules-4.8.0-2-4kc-malta-di is NEW. binary:input-modules-4.8.0-2-5kc-malta-di is NEW. binary:input-modules-4.8.0-2-loongson-3-di is NEW. binary:input-modules-4.8.0-2-marvell-di is NEW. binary:input-modules-4.8.0-2-octeon-di is NEW. binary:ipv6-modules-4.8.0-2-marvell-di is NEW. binary:isofs-modules-4.8.0-2-4kc-malta-di is NEW. binary:isofs-modules-4.8.0-2-5kc-malta-di is NEW. binary:isofs-modules-4.8.0-2-loongson-3-di is NEW. binary:isofs-modules-4.8.0-2-marvell-di is NEW. binary:isofs-modules-4.8.0-2-octeon-di is NEW. binary:isofs-modules-4.8.0-2-versatile-di is NEW. binary:jffs2-modules-4.8.0-2-marvell-di is NEW. binary:jfs-modules-4.8.0-2-4kc-malta-di is NEW. binary:jfs-modules-4.8.0-2-5kc-malta-di is NEW. binary:jfs-modules-4.8.0-2-loongson-3-di is NEW. binary:jfs-modules-4.8.0-2-marvell-di is NEW. binary:jfs-modules-4.8.0-2-octeon-di is NEW. binary:kernel-image-4.8.0-2-4kc-malta-di is NEW. binary:kernel-image-4.8.0-2-5kc-malta-di is NEW. binary:kernel-image-4.8.0-2-loongson-3-di is NEW. binary:kernel-image-4.8.0-2-marvell-di is NEW. binary:kernel-image-4.8.0-2-octeon-di is NEW. binary:kernel-image-4.8.0-2-versatile-di is NEW. binary:leds-modules-4.8.0-2-marvell-di is NEW. binary:linux-headers-4.8.0-2-4kc-malta is NEW. binary:linux-headers-4.8.0-2-5kc-malta is NEW. binary:linux-headers-4.8.0-2-686 is NEW. binary:linux-headers-4.8.0-2-686-pae is NEW. binary:linux-headers-4.8.0-2-all is NEW. binary:linux-headers-4.8.0-2-all-amd64 is NEW. binary:linux-headers-4.8.0-2-all-arm64 is NEW. binary:linux-headers-4.8.0-2-all-armel is NEW. binary:linux
Processing of linux_4.8.11-1_multi.changes
linux_4.8.11-1_multi.changes uploaded successfully to localhost along with the files: linux_4.8.11-1.dsc linux_4.8.11.orig.tar.xz linux_4.8.11-1.debian.tar.xz linux-doc-4.8_4.8.11-1_all.deb linux-manual-4.8_4.8.11-1_all.deb linux-source-4.8_4.8.11-1_all.deb linux-support-4.8.0-2_4.8.11-1_all.deb Greetings, Your Debian queue daemon (running on host usper.debian.org)
Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm
Thanks for this; I've applied it to the master branch for Debian. After comparing all the symbols potentially exported from assembly with those declared in asm-prototypes.h, I found that cmpxchg8b_emu is missing. This is only defined when building for 486 so it doesn't affect Debian, but you may want to add that if you resubmit this upstream. Ben. -- Ben Hutchings friends: People who know you well, but like you anyway. signature.asc Description: This is a digitally signed message part
Processed: tagging 846492, bug 846492 is forwarded to https://bugs.freedesktop.org/show_bug.cgi?id=93782
Processing commands for cont...@bugs.debian.org: > tags 846492 + upstream Bug #846492 [src:linux] linux-image-4.8.0-1-686-pae: frequently crash during boot Added tag(s) upstream. > forwarded 846492 https://bugs.freedesktop.org/show_bug.cgi?id=93782 Bug #846492 [src:linux] linux-image-4.8.0-1-686-pae: frequently crash during boot Set Bug forwarded-to-address to 'https://bugs.freedesktop.org/show_bug.cgi?id=93782'. > thanks Stopping processing here. Please contact me if you need assistance. -- 846492: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846492 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Uploading linux (4.8.11-1)
Hi We intend to upload linux version 4.8.11-1 to unstable over this weekend. The upload incorporates the upstream stable updates 4.8.8, 4.8.9, 4.8.10 and 4.8.11 with various bugfixes and fixed vulnerabilities (CVE-2015-1350 CVE-2016-6213 CVE-2016-8645 CVE-2016-8650 CVE-2016-9083 CVE-2016-9084 CVE-2016-9555), and the following additional changes: * [arm64] Enable more drivers for X-Gene (Really closes: #840061): - DMA: Enable XGENE_DMA as module - EDAC: Enable EDAC and EDAC_MM_EDAC, EDAC_XGENE as modules * [x86] video: Disable X86_SYSFB, FB_SIMPLE (Closes: #822575) There is though an ABI change needed. Regards, Salvatore signature.asc Description: PGP signature
Bug#846513: marked as done (linux-libc-dev possibly needs dependency on corresponding linux-image)
Your message dated Thu, 01 Dec 2016 19:46:58 + with message-id <1480621618.16599.103.ca...@decadent.org.uk> and subject line Re: Bug#846513: linux-libc-dev possibly needs dependency on corresponding linux-image has caused the Debian Bug report #846513, regarding linux-libc-dev possibly needs dependency on corresponding linux-image to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 846513: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846513 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: linux-libc-dev Version: 4.7.6-1 Severity: normal Dear Maintainer, === I'm running linux-image-4.7.0-1-686-pae which is pinned to version 4.7.6-1 (see below). However, linux-libc-dev can be upgraded to version 4.8.7-1 without also upgrading the linux image, as linux-libc-dev does not depend on it. It would seem this could cause inconsistencies with binaries built on the 4.7.6-1 image but using the headers for 4.8.7-1. Should linux-libc-dev depend on the linux image it corresponds to? => apt-cache policy | sort | grep linux ... linux-headers-4.7.0-1-686-pae -> 4.7.6-1 with priority 1001 linux-headers-4.7.0-1-common -> 4.7.6-1 with priority 1001 linux-headers-686-pae -> 4.7+75 with priority 1001 ... linux-image-4.7.0-1-686-pae -> 4.7.6-1 with priority 1001 linux-image-686-pae -> 4.7+75 with priority 1001 linux-kbuild-4.7 -> 4.7.6-1 with priority 1001 linux-libc-dev -> 4.7.6-1 with priority 1001 => apt-cache policy linux-libc-dev linux-libc-dev: Installed: 4.7.6-1 Candidate: 4.7.6-1 Version table: 4.8.7-1 500 500 http://debian.lcs.mit.edu/debian testing/main i386 Packages *** 4.7.6-1 1001 500 http://snapshot.debian.org/archive/debian/20161017 testing/main i386 Packages 500 copy:/usr3/Installs/DEB ./ Packages 100 /var/lib/dpkg/status 4.7.5-1 500 500 http://snapshot.debian.org/archive/debian/20161005 testing/main i386 Packages === -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 4.7.0-1-686-pae (SMP w/6 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) -- no debconf information --- End Message --- --- Begin Message --- On Thu, 2016-12-01 at 13:53 -0500, js wrote: > Package: linux-libc-dev > Version: 4.7.6-1 > Severity: normal > > Dear Maintainer, > > = > == > > I'm running linux-image-4.7.0-1-686-pae which is pinned to version > 4.7.6-1 (see below). > > However, linux-libc-dev can be upgraded to version 4.8.7-1 without > also upgrading > the linux image, as linux-libc-dev does not depend on it. > > It would seem this could cause inconsistencies with binaries built on > the 4.7.6-1 image > but using the headers for 4.8.7-1. linux-libc-dev defines the kernel's userland API (and ABI), which is intended to always be backward-compatible. So there should be no inconsistency. What could happen is that a program's build-time feature tests detect a kernel feature that won't be available at run-time. But that would already be a bug in that program, since there's nothing that forces users of packages from testing to run the kernel version in testing. > Should linux-libc-dev depend on the linux image it corresponds to? There is no requirement that the kernel is installed within the same system (chroot installations, containers and some paravirtualised environments don't). Nor is there a requirement that a Debian system runs on oen of Debian's packaged kernels. Besides, if a particular kernel version is installed, that doesn't mean that it's running. So when a package does depend on a particular minimum kernel version, it can't use package relations to ensure that - it has to use a run- time test. The same is true for kernel features that are optional. Ben. -- Ben Hutchings A free society is one where it is safe to be unpopular. - Adlai Stevenson signature.asc Description: This is a digitally signed message part --- End Message ---
Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm
On Thu, Dec 01, 2016 at 05:06:11PM +0100, Greg Kroah-Hartman wrote: > On Thu, Dec 01, 2016 at 10:40:59AM -0500, Don Zickus wrote: > > Unfortunately, there are various drivers that will never go upstream > > > > - paid storage drivers that provide bells and whistles on top of inbox > > driver > > That's because the developer doesn't want them upstream, that's their > fault, nothing we can do about them. > > > - old drivers/fs that application has been relying on for a long time but > > company doesn't have resources to migrate to current technology. > > That's what drivers/staging/ is for, I'll take anything that builds (and > sometimes stuff that doesn't build) as long as people are actually using > it. So send the stuff that is in this category on to me and that will > reduce your burden a _lot_. Hi Greg, I will forward this offer to the right folks and see who we can get to bite. :-) Thanks! Cheers, Don
Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm
On Thu, Dec 1, 2016 at 5:58 AM, Arnd Bergmann wrote: > > WARNING: EXPORT symbol "mcount" [arch/x86/entry/built-in.ko] version > generation failed, symbol will not be versioned. > WARNING: EXPORT symbol "mcount" [arch/x86/built-in.ko] version generation > failed, symbol will not be versioned. > WARNING: EXPORT symbol "cmpxchg8b_emu" [vmlinux] version generation failed, > symbol will not be versioned. > WARNING: EXPORT symbol "empty_zero_page" [vmlinux] version generation failed, > symbol will not be versioned. > WARNING: EXPORT symbol "mcount" [vmlinux] version generation failed, symbol > will not be versioned. > WARNING: EXPORT symbol "cmpxchg8b_emu" [vmlinux] version generation failed, > symbol will not be versioned. > WARNING: EXPORT symbol "empty_zero_page" [vmlinux] version generation failed, > symbol will not be versioned. > WARNING: EXPORT symbol "mcount" [vmlinux] version generation failed, symbol > will not be versioned. > > Out of 12 randconfig builds that had CONFIG_MODVERSIONS enabled, all 12 > had this problem, though not always with all the symbols. Well, the good news is that pretty fundamentally, if it's just the asm symbls, those really don't have ABI's that change (or if they change, it's such a fundamental change that everything else will likely have changed too and we don't need to worry about one asm symbol crc - the change will be caught by other symbols). So I think the whole "we don't really care" approach should work fine. The "let's make every symbol always be versioned" may just be too much pain for no real gain. Linus
Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm
On 2016-12-01 14:58, Arnd Bergmann wrote: > On Tuesday, November 29, 2016 9:14:46 AM CET Linus Torvalds wrote: >> On Tue, Nov 29, 2016 at 9:10 AM, Linus Torvalds >> wrote: >>> >>> So quite frankly, I don't want to make our kernel sources worse due to >>> broken shit tools getting something wrong that we shouldn't even care >>> about. >> >> And yes, I'm on binutils 2.26 (with no issues), so it could be that >> it's 2.27 that triggers this. >> >> We could make the pr_warn_once() mention "broken binutils?" so that >> people know why the warning happens. > > I've tried to get to the bottom of this, but couldn't find anything > related to the toolchain version. I've tried binutils 2.23, 2.24, 2.26 > and 2.27, and also gcc-7.0, gcc-5.4.1 and gcc-4.9.3, but with today's > linux-next, I always get > > WARNING: EXPORT symbol "mcount" [arch/x86/entry/built-in.ko] version > generation failed, symbol will not be versioned. > WARNING: EXPORT symbol "mcount" [arch/x86/built-in.ko] version generation > failed, symbol will not be versioned. > WARNING: EXPORT symbol "cmpxchg8b_emu" [vmlinux] version generation failed, > symbol will not be versioned. > WARNING: EXPORT symbol "empty_zero_page" [vmlinux] version generation failed, > symbol will not be versioned. > WARNING: EXPORT symbol "mcount" [vmlinux] version generation failed, symbol > will not be versioned. > WARNING: EXPORT symbol "cmpxchg8b_emu" [vmlinux] version generation failed, > symbol will not be versioned. > WARNING: EXPORT symbol "empty_zero_page" [vmlinux] version generation failed, > symbol will not be versioned. > WARNING: EXPORT symbol "mcount" [vmlinux] version generation failed, symbol > will not be versioned. > > Out of 12 randconfig builds that had CONFIG_MODVERSIONS enabled, all 12 > had this problem, though not always with all the symbols. That we are not generating modversions for the asm exports is a known problem, independent of the toolchain. The problem with some toolchains (presumably, because that's the next thing to blame if the source and the .config is identical) is that the CRCs do not appear as 0 in the ___kcrctab/___kcrctab_gpl section. Michal
Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm
On 2016-12-01 05:13, Don Zickus wrote: > Sorry for chiming in late, but yes RHEL is a big user of MODVERSIONS for our > kabi protection work. Despite our best intentions we still have lots of > partners and customers that provide value-add out-of-tree drivers to their > customers. These module builders requested we have a mechanism to allow > rolling modules forward for each of our minor RHEL updates without breaking > their drivers. FWIW, in SLES we use CONFIG_MODVERSION for pretty much the same reasons you listed. We also enable it in openSUSE, but there it's not as crucial. Michal
Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm
On Thu, Dec 01, 2016 at 10:40:59AM -0500, Don Zickus wrote: > Unfortunately, there are various drivers that will never go upstream > > - paid storage drivers that provide bells and whistles on top of inbox > driver That's because the developer doesn't want them upstream, that's their fault, nothing we can do about them. > - old drivers/fs that application has been relying on for a long time but > company doesn't have resources to migrate to current technology. That's what drivers/staging/ is for, I'll take anything that builds (and sometimes stuff that doesn't build) as long as people are actually using it. So send the stuff that is in this category on to me and that will reduce your burden a _lot_. thanks, greg k-h
Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm
On 2016-12-01 04:39, Nicholas Piggin wrote: > On Thu, 01 Dec 2016 02:35:54 + > Ben Hutchings wrote: >> As I understand it, genksyms incorporates the definitions of a >> function's parameter and return types - not just their names - and all >> the types they refer to, recursively. So a structure size change >> should change the version of all functions where the function and its >> caller pass that structure between them, however indirectly. It finds >> such indirect ABI breakage for me fairly regularly, though of course I >> don't know that it finds everything. > > It is only the type name. > > Not only that but even if you did extend it further to structure type > arrangement then you still have to deal with other structures followed > via pointers. Or (rarer but not unheard of): > > - changes to structures without changes of the types of their members > - changes to arguments without changes of their type This is already covered by genksyms. Try make V=1 with CONFIG_MODVERSIONS=y and add the -D option to one of the genksyms command. I wanted to paste the expanded signature for register_filesystem() as an example, but vger would probably drop the mail for being too big :). > - changes to semantics of functions > - data structures derived in ways other than exported symbols, e.g., > fixed register for `current` on some archs Right, this is something that genksyms has no idea about. Michal
Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm
On Thu, Dec 01, 2016 at 10:20:39AM -0500, Don Zickus wrote: > > - provide the memory allocation (instead of having the driver staticly > allocate) > - provide functions to retrieve various internal data (instead of having the > driver do direct referencing to deep internal elements) > - cut down on some static inlines (and use accessory functions instead), > etc. > > Those types of changes allow the OOT driver to be more ignorant of kernel > changes and struct modifications. All that is counter to what we really want to have: a well integrated kernel that moves forward together so that we can see and improve the whole situation. No need to make things worse just to help leeches. Get your damn drivers upstream ASAP and let's stop this discussion..
Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm
On Thu, Dec 01, 2016 at 07:26:09AM -0800, Christoph Hellwig wrote: > On Thu, Dec 01, 2016 at 10:20:39AM -0500, Don Zickus wrote: > > > > - provide the memory allocation (instead of having the driver staticly > > allocate) > > - provide functions to retrieve various internal data (instead of having the > > driver do direct referencing to deep internal elements) > > - cut down on some static inlines (and use accessory functions instead), > > etc. > > > > Those types of changes allow the OOT driver to be more ignorant of kernel > > changes and struct modifications. > > All that is counter to what we really want to have: a well integrated > kernel that moves forward together so that we can see and improve the > whole situation. No need to make things worse just to help leeches. > Get your damn drivers upstream ASAP and let's stop this discussion.. I understand and won't disagree with you. :-) Unfortunately, there are various drivers that will never go upstream - paid storage drivers that provide bells and whistles on top of inbox driver - old drivers/fs that application has been relying on for a long time but company doesn't have resources to migrate to current technology. We have been trying over the years to do what we can to move customers in the right direction. It is just a slow process, sadly. Cheers, Don
Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm
Nicholas Piggin a écrit: [...] > On Thu, 1 Dec 2016 11:48:09 +0100 > Stanislav Kozina wrote: > >> On 12/01/2016 05:13 AM, Don Zickus wrote: >> >> ... >> >> > I think GregKH pointed to one such tool, libabigail? We are working on >> > others too. >> >> I should mention one of the others here: >> https://github.com/skozina/kabi-dw [...] > Now this seems much better for distro ABI checking. Right, Incidentally, Fedora does distro-wide ABI verfication for userspace libraries updates in a given stable distribution. You can look at an example of output of the libabigail-based tool that compares a new version of an ELF library to it's latest stable version: https://taskotron.fedoraproject.org/artifacts/all/a55cbac8-ab64-11e6-94e0-525400120b80/task_output/curl-7.51.0-2.fc25.log The results of those ABI comparison can browsed at https://taskotron.fedoraproject.org/resultsdb/results?testcase_name=dist.abicheck. Of course, you can run the comparison yourself by using a libabigail-based tool like https://sourceware.org/libabigail/manual/abipkgdiff.html which takes .deb and .rpm packages. We are currently working on making libabigail-based tools understand Linux kernel specifities so that we can run that kind of analysis on Kernel updates too. Ideally, when this is done, you should be able to just use abipkgdiff on two Linux Kernel packages and get the same kind of output. > The next question is, do they need any kernel support for rare cases > where they do have to break the ABI of an export? Simple rename of the > function with a _v2 postfix might be enough. We could retain some per > symbol versioning in the kernel if needed, but how much would it > actually help? As a reviewer of the ABI change report emitted by the tool, if what you want is to say "I reviewed that ABI change and it's OK, so please do not show it to me next time", then you can feed the tool with a "suppression specification". It's a text file in the INI syntax in which you can specify the kind of change you want the tool to suppress from its output: https://sourceware.org/libabigail/manual/libabigail-concepts.html. So I don't think you need to do anything to the source code of the Kernel in the cases where you need to change the ABI. Just tell the tool about that change. Cheers, -- Dodji
Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm
On Thu, Dec 01, 2016 at 03:32:15PM +1100, Nicholas Piggin wrote: > > Anyway, MODVERSIONS is our way of protecting our kabi for the last 10 years. > > It isn't perfect and we have fixed the genksyms tool over the years, but so > > far it mostly works fine. > > Okay. It would be good to get all the distros in on this. > > What I want to do is work out exactly what it is that modversions is > giving you. > > We know it's fairly nasty code to maintain and it does not detect ABI > changes very well. But it's not such a burden that we can't maintain > it if there are good reasons to keep it. Hi Nick, I won't disagree with you there. :-) modversions is a pretty heavy handed approach that basically says if all the symbols and types haven't changed for a given EXPORT_SYMBOL (recursively checked), then there is a high degree of confidence the OOT driver will not only load, but run correctly. The question is how to provide a similar guarantee if a different way? We have plenty of customers with 10 year old drivers, where the expertise has long left the company. The engineers still around, recompile and make tweaks to get things working on the latest RHEL. Verify it passes testing and release it. Then they hope to not touch it again for a few years until the next RHEL comes along. Scary, huh? :-) Common examples, filesystems and storage drivers. There is no way that I see to provide a 100% guarantee, but if we do enough checks, we should be able to have a high degree of confidence the driver won't blow up. On the flip side, easy things in the kernel to do is: - provide the memory allocation (instead of having the driver staticly allocate) - provide functions to retrieve various internal data (instead of having the driver do direct referencing to deep internal elements) - cut down on some static inlines (and use accessory functions instead), etc. Those types of changes allow the OOT driver to be more ignorant of kernel changes and struct modifications. Look to Stanislav's responses for his ideas on new tooling. Thanks for helping! Cheers, Don > > > I am not sure what 'control vermagic' is, but it sounds like a string check, > > which won't protect against the boatload of backports we do to structs, > > enums, and functions. > > Basically vermagic is the string all modules and the kernel get, which > must match in order to load modules. If you have modversions disabled, > then vermagic includes the kernel version. If modversions is enabled, > then vermagic does not include the kernel version but the CRCs have to > also match. > > Controlling it explicitly is just a couple of lines where a distro can > control it (so they can update their kernel version without breaking). > It's not meant to solve everything, just the first one. > > > Currently we are exploring various ways to get smarter here. The genksyms > > tool has its limitations and handling kabi hacks in RHEL is getting > > tiresome. > > > > I think GregKH pointed to one such tool, libabigail? We are working on > > others too. > > > > > > Circling back to enabling MODVERSIONS in Fedora, that was to start the > > process of syncing Fedora with RHEL stuff in preparation for smarter tools. > > > > > > If you take away MODVERSIONS, that would put a damper in our work, but > > easily carried privately (much like MODSIGNING for 8 years until it went > > upstream :-) ). > > I don't think that's necessary. A feature requirement for a distro is just > as valid as any other user of upstream. I don't want to hinder any distro, > I'm just still not quite seeing the big picture of exactly what functionality > you need from the kernel. > > Thanks, > Nick
Bug#804079: [Xen-devel] Kernel panic on Xen virtualisation in Debian
Thursday, December 1, 2016, 2:59:36 PM, you wrote: > On 01.12.2016 14:26, Wei Liu wrote: >> This is still the same kernel log that was sent some time ago. >> So, if you have built Xen with debug=y, could you try to set Xen log >> level to the highest and capture "xl dmesg" when guest crashes? > It's not the guest that crashes, it's dom0. So when the host crashes, > I'm not able to issue any commands anymore. >> But I think this is increasingly likely to be a Linux kernel issue >> because you've tried multiple versions of xen. Maybe it is time to try >> different versions of Dom0 kernels (sorry if you've tried that, I can't >> remember all the details over so many moons). > Yes, indeed I have tried different kernels, but I can't remember details > as well... ;/ Hi Ingo, Have you tried without enabling "ndisc" (QoS) and "ipv6" ? They are both present in your log and i assume you are using a bridged network config ? You wouldn't be the first to stumble over a more generic kernel network bug while using Xen, due to less well tested combinations. So it's worth testing if plain ipv4 and no QoS works. -- Sander
Bug#804079: [Xen-devel] Kernel panic on Xen virtualisation in Debian
On 01.12.2016 14:26, Wei Liu wrote: This is still the same kernel log that was sent some time ago. So, if you have built Xen with debug=y, could you try to set Xen log level to the highest and capture "xl dmesg" when guest crashes? It's not the guest that crashes, it's dom0. So when the host crashes, I'm not able to issue any commands anymore. But I think this is increasingly likely to be a Linux kernel issue because you've tried multiple versions of xen. Maybe it is time to try different versions of Dom0 kernels (sorry if you've tried that, I can't remember all the details over so many moons). Yes, indeed I have tried different kernels, but I can't remember details as well... ;/ -- Ciao... //http://blog.windfluechter.net Ingo \X/ XMPP: i...@jabber.windfluechter.net gpg pubkey: http://www.juergensmann.de/ij_public_key.asc
Bug#846492: linux-image-4.8.0-1-686-pae: frequently crash during boot
Package: src:linux Version: 4.8.7-1 Severity: important Dear Maintainer, after upgrading our Acer Extensa 5220 to linux version 4.8.5-1 and 4.8.7-1 it frequently crash during boot (if it does not crash is completly usable). This is the relevant kernel log: Dec 1 12:52:59 computer kernel: [ 126.720016] [ cut here ] Dec 1 12:52:59 computer kernel: [ 126.720029] WARNING: CPU: 0 PID: 1052 at /build/linux-m9DhPu/linux-4.8.7/drivers/gpu/drm/drm_irq.c:1224 drm_wait_one_vblank+0x191/0x1a0 [drm] Dec 1 12:52:59 computer kernel: [ 126.720030] vblank wait timed out on crtc 1 Dec 1 12:52:59 computer kernel: [ 126.720031] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache uinput snd_hrtimer snd_seq snd_seq_device iTCO_wdt iTCO_vendor_support acer_wmi sparse_keymap arc4 b43 pcspkr joydev i2c_i801 tifm_7xx1 bcma tifm_core serio_raw i2c_smbus yenta_socket mac80211 pcmcia_rsrc sg snd_hda_codec_hdmi lpc_ich mfd_core snd_hda_codec_realtek cfg80211 snd_hda_codec_generic rfkill snd_hda_intel rng_core nsc_ircc snd_hda_codec snd_hda_core snd_hwdep ac snd_pcm irda battery evdev crc_ccitt snd_timer snd soundcore acpi_cpufreq tpm_tis shpchp tpm_tis_core tpm coretemp loop firewire_sbp2 parport_pc ppdev sunrpc lp parport ip_tables x_tables autofs4 ext4 crc16 jbd2 crc32c_generic fscrypto ecb xts lrw gf128mul ablk_helper cryptd aes_i586 mbcache sr_mod cdrom sd_mod ata_generic hid_generic usbhid hid psmouse i915 ahci libahci ata_piix libata sdhci_pci sdhci tg3 firewire_ohci ssb mmc_core ptp scsi_mod firewire_core crc_itu_t pcmcia pcmcia_core pps_core libphy ehci_pci i2c_algo_bit drm_kms_helper uhci_hcd ehci_hcd drm usbcore video thermal wmi usb_common button Dec 1 12:52:59 computer kernel: [ 126.720100] CPU: 0 PID: 1052 Comm: Xorg Tainted: GW 4.8.0-1-686-pae #1 Debian 4.8.7-1 Dec 1 12:52:59 computer kernel: [ 126.720101] Hardware name: Acer Extensa 5220 /Columbia , BIOS V1.34 04/15/2008 Dec 1 12:52:59 computer kernel: [ 126.720103] 0286 2386994e f6927a4c de2f1c7c f6927a60 de06d9ba f84393b4 Dec 1 12:52:59 computer kernel: [ 126.720107] f6927a80 041c f8439000 04c8 f84115b1 04c8 0009 f84115b1 Dec 1 12:52:59 computer kernel: [ 126.720111] f6238000 0001 f6927a6c de06da26 0009 f6927a60 Dec 1 12:52:59 computer kernel: [ 126.720114] Call Trace: Dec 1 12:52:59 computer kernel: [ 126.720120] [] ? dump_stack+0x55/0x79 Dec 1 12:52:59 computer kernel: [ 126.720123] [] ? __warn+0xea/0x110 Dec 1 12:52:59 computer kernel: [ 126.720130] [] ? drm_wait_one_vblank+0x191/0x1a0 [drm] Dec 1 12:52:59 computer kernel: [ 126.720136] [] ? drm_wait_one_vblank+0x191/0x1a0 [drm] Dec 1 12:52:59 computer kernel: [ 126.720138] [] ? warn_slowpath_fmt+0x46/0x60 Dec 1 12:52:59 computer kernel: [ 126.720144] [] ? drm_wait_one_vblank+0x191/0x1a0 [drm] Dec 1 12:52:59 computer kernel: [ 126.720148] [] ? wake_atomic_t_function+0x70/0x70 Dec 1 12:52:59 computer kernel: [ 126.720174] [] ? intel_pre_plane_update+0x1a0/0x1b0 [i915] Dec 1 12:52:59 computer kernel: [ 126.720193] [] ? intel_atomic_commit_tail+0x150/0xf90 [i915] Dec 1 12:52:59 computer kernel: [ 126.720212] [] ? intel_fbc_choose_crtc+0x23/0x1e0 [i915] Dec 1 12:52:59 computer kernel: [ 126.720218] [] ? drm_atomic_helper_setup_commit+0x2a4/0x2f0 [drm_kms_helper] Dec 1 12:52:59 computer kernel: [ 126.720221] [] ? drm_atomic_helper_setup_commit+0x2a4/0x2f0 [drm_kms_helper] Dec 1 12:52:59 computer kernel: [ 126.720225] [] ? drm_atomic_helper_prepare_planes+0x3d/0xc0 [drm_kms_helper] Dec 1 12:52:59 computer kernel: [ 126.720244] [] ? intel_atomic_commit+0x3de/0x500 [i915] Dec 1 12:52:59 computer kernel: [ 126.720251] [] ? drm_atomic_check_only+0x19b/0x690 [drm] Dec 1 12:52:59 computer kernel: [ 126.720269] [] ? gen2_write16+0x140/0x140 [i915] Dec 1 12:52:59 computer kernel: [ 126.720276] [] ? drm_atomic_commit+0x32/0x60 [drm] Dec 1 12:52:59 computer kernel: [ 126.720294] [] ? intel_release_load_detect_pipe+0x22/0xb0 [i915] Dec 1 12:52:59 computer kernel: [ 126.720297] [] ? wake_atomic_t_function+0x70/0x70 Dec 1 12:52:59 computer kernel: [ 126.720314] [] ? intel_tv_detect+0x326/0x680 [i915] Dec 1 12:52:59 computer kernel: [ 126.720320] [] ? drm_helper_probe_single_connector_modes+0x248/0x500 [drm_kms_helper] Dec 1 12:52:59 computer kernel: [ 126.720327] [] ? get_properties+0xad/0x100 [drm] Dec 1 12:52:59 computer kernel: [ 126.720334] [] ? _object_find+0x5c/0xc0 [drm] Dec 1 12:52:59 computer kernel: [ 126.720341] [] ? drm_mode_getconnector+0x285/0x2f0 [drm] Dec 1 12:52:59 computer kernel: [ 126.720349] [] ? drm_mode_getcrtc+0x140/0x140 [drm] Dec 1 12:52:59 computer kernel: [ 126.720355] [] ? drm_ioctl+0x1ab/0x490 [drm] Dec 1 12:52:59 computer kernel: [ 126.720362] [] ? drm_mode_getcrtc+0x140/0x140 [drm] Dec 1 12:52:59 computer kernel: [ 126.720365]
Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm
On Tuesday, November 29, 2016 9:14:46 AM CET Linus Torvalds wrote: > On Tue, Nov 29, 2016 at 9:10 AM, Linus Torvalds > wrote: > > > > So quite frankly, I don't want to make our kernel sources worse due to > > broken shit tools getting something wrong that we shouldn't even care > > about. > > And yes, I'm on binutils 2.26 (with no issues), so it could be that > it's 2.27 that triggers this. > > We could make the pr_warn_once() mention "broken binutils?" so that > people know why the warning happens. I've tried to get to the bottom of this, but couldn't find anything related to the toolchain version. I've tried binutils 2.23, 2.24, 2.26 and 2.27, and also gcc-7.0, gcc-5.4.1 and gcc-4.9.3, but with today's linux-next, I always get WARNING: EXPORT symbol "mcount" [arch/x86/entry/built-in.ko] version generation failed, symbol will not be versioned. WARNING: EXPORT symbol "mcount" [arch/x86/built-in.ko] version generation failed, symbol will not be versioned. WARNING: EXPORT symbol "cmpxchg8b_emu" [vmlinux] version generation failed, symbol will not be versioned. WARNING: EXPORT symbol "empty_zero_page" [vmlinux] version generation failed, symbol will not be versioned. WARNING: EXPORT symbol "mcount" [vmlinux] version generation failed, symbol will not be versioned. WARNING: EXPORT symbol "cmpxchg8b_emu" [vmlinux] version generation failed, symbol will not be versioned. WARNING: EXPORT symbol "empty_zero_page" [vmlinux] version generation failed, symbol will not be versioned. WARNING: EXPORT symbol "mcount" [vmlinux] version generation failed, symbol will not be versioned. Out of 12 randconfig builds that had CONFIG_MODVERSIONS enabled, all 12 had this problem, though not always with all the symbols. Arnd
Bug#804079: [Xen-devel] Kernel panic on Xen virtualisation in Debian
On Thu, Dec 01, 2016 at 02:59:36PM +0100, Ingo Jürgensmann wrote: > On 01.12.2016 14:26, Wei Liu wrote: > > >This is still the same kernel log that was sent some time ago. > >So, if you have built Xen with debug=y, could you try to set Xen log > >level to the highest and capture "xl dmesg" when guest crashes? > > It's not the guest that crashes, it's dom0. So when the host crashes, I'm > not able to issue any commands anymore. > Oh, sorry for speaking non-sense. In that case you will need to setup a serial console to capture output on the fly. Wei.
Bug#846488: linux-signed: broken Built-Using fields
Package: linux-signed
Version: 3.2
Severity: important
Hi,
Your packages includes broken Built-Using fields, e.g.:
Package: linux-image-4.8.0-1-amd64
Source: linux-signed (3.2)
Built-Using: linux (4.8.7-1)
That should have been: linux (= 4.8.7-1)
See Debian Policy 7.8:
A Built-Using field must list the corresponding source package for any
such binary package incorporated during the build [56], including an
"exactly equal" ("=") version relation on the version that was used to
build that binary package[57].
Cheers,
Emilio
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (800, 'unstable'), (700, 'experimental'), (650, 'testing'), (500,
'unstable-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf
Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Bug#804079: [Xen-devel] Kernel panic on Xen virtualisation in Debian
On Tue, Nov 29, 2016 at 09:20:55PM +0100, Ingo Jürgensmann wrote: > Am 29.11.2016 um 10:08 schrieb Wei Liu : > >> http://paste.debian.net/895464/ > > Entry not found -- maybe it expired... Sorry. > > Here it is: > This is still the same kernel log that was sent some time ago. So, if you have built Xen with debug=y, could you try to set Xen log level to the highest and capture "xl dmesg" when guest crashes? But I think this is increasingly likely to be a Linux kernel issue because you've tried multiple versions of xen. Maybe it is time to try different versions of Dom0 kernels (sorry if you've tried that, I can't remember all the details over so many moons). Wei.
Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm
On Thu, 1 Dec 2016 12:33:02 +0100 Stanislav Kozina wrote: > On 12/01/2016 12:09 PM, Nicholas Piggin wrote: > > On Thu, 1 Dec 2016 11:48:09 +0100 > > Stanislav Kozina wrote: > > > >> On 12/01/2016 05:13 AM, Don Zickus wrote: > >> > >> ... > >> > >>> I think GregKH pointed to one such tool, libabigail? We are working on > >>> others too. > >> I should mention one of the others here: > >> https://github.com/skozina/kabi-dw > >> > >> It's quite comparable to libabigail in the way it works, the main > >> differences are: > >>- written in pure C > >>- depends only on elf-utils and flex/yacc > >>- it's much simpler (4k LOC) > >>- stores the type information in the text files and compares those > >> instead of directly comparing two sets of DWARF data > > Now this seems much better for distro ABI checking. > > > > The next question is, do they need any kernel support for rare cases > > where they do have to break the ABI of an export? Simple rename of the > > function with a _v2 postfix might be enough. We could retain some per > > symbol versioning in the kernel if needed, but how much would it > > actually help? > > The biggest pain point AFAICT is to identify what types (functions, > structs, enums, ...) should be considered a part of the stable ABI. Sure. This is something an automated checker can't solve completely. Any changes would have to be considered in terms of their impact to the ABI. It's not just data but also instruction changes involved. This is policy that should not be mandated by the kernel. Which is why I'm in favor of using tools like this and just providing mechanism so distros can implement their own polices. > And > the problem with modversions is that it pulls in just everything which > gets (accidentally?) #included in the source file. I think that's SRCVERSION which is something else. But modversions has problems too. > The actual ABI maintenance is a different problem, but there are many > possible approaches, the _v2 suffix being one of them. Would be good to get a consensus on that too. Thanks, Nick
Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm
On 12/01/2016 12:09 PM, Nicholas Piggin wrote: On Thu, 1 Dec 2016 11:48:09 +0100 Stanislav Kozina wrote: On 12/01/2016 05:13 AM, Don Zickus wrote: ... I think GregKH pointed to one such tool, libabigail? We are working on others too. I should mention one of the others here: https://github.com/skozina/kabi-dw It's quite comparable to libabigail in the way it works, the main differences are: - written in pure C - depends only on elf-utils and flex/yacc - it's much simpler (4k LOC) - stores the type information in the text files and compares those instead of directly comparing two sets of DWARF data Now this seems much better for distro ABI checking. The next question is, do they need any kernel support for rare cases where they do have to break the ABI of an export? Simple rename of the function with a _v2 postfix might be enough. We could retain some per symbol versioning in the kernel if needed, but how much would it actually help? The biggest pain point AFAICT is to identify what types (functions, structs, enums, ...) should be considered a part of the stable ABI. And the problem with modversions is that it pulls in just everything which gets (accidentally?) #included in the source file. The actual ABI maintenance is a different problem, but there are many possible approaches, the _v2 suffix being one of them. Regards, -Stanislav
Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm
On Thu, 1 Dec 2016 11:48:09 +0100 Stanislav Kozina wrote: > On 12/01/2016 05:13 AM, Don Zickus wrote: > > ... > > > I think GregKH pointed to one such tool, libabigail? We are working on > > others too. > > I should mention one of the others here: > https://github.com/skozina/kabi-dw > > It's quite comparable to libabigail in the way it works, the main > differences are: > - written in pure C > - depends only on elf-utils and flex/yacc > - it's much simpler (4k LOC) > - stores the type information in the text files and compares those > instead of directly comparing two sets of DWARF data Now this seems much better for distro ABI checking. The next question is, do they need any kernel support for rare cases where they do have to break the ABI of an export? Simple rename of the function with a _v2 postfix might be enough. We could retain some per symbol versioning in the kernel if needed, but how much would it actually help? Thanks, Nick
Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm
On 12/01/2016 05:13 AM, Don Zickus wrote: ... I think GregKH pointed to one such tool, libabigail? We are working on others too. I should mention one of the others here: https://github.com/skozina/kabi-dw It's quite comparable to libabigail in the way it works, the main differences are: - written in pure C - depends only on elf-utils and flex/yacc - it's much simpler (4k LOC) - stores the type information in the text files and compares those instead of directly comparing two sets of DWARF data Regards, -Stanislav
