[PATCH] ktest: take submenu into account
grub-reboot selects the submenu's first menuentry (title is "1>0") rather than
ktest's
menuentry (title is "2") by mistake.
===
$ sudo cat /boot/grub/grub.cfg | grep -E "^menuentry|^submenu"
...
menuentry 'Ubuntu' --class ubuntu --class gnu-linux --class gnu --class os
$menuentry_id_option '...' {
...
submenu 'Advanced options for Ubuntu' $menuentry_id_option '...' {
...
menuentry 'ktest' {
...
===
Correct it by taking submenu entries into account in get_grub2_index().
Signed-off-by: Satoru Takeuchi
---
tools/testing/ktest/ktest.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/ktest/ktest.pl b/tools/testing/ktest/ktest.pl
index 0c8b61f..6cf135a 100755
--- a/tools/testing/ktest/ktest.pl
+++ b/tools/testing/ktest/ktest.pl
@@ -1821,7 +1821,7 @@ sub get_grub2_index {
$grub_number++;
$found = 1;
last;
- } elsif (/^menuentry\s/) {
+ } elsif (/^menuentry\s|^submenu\s/) {
$grub_number++;
}
}
--
2.7.4
[PATCH] brd: prevent overflow caused by too large rd_size parameter
The max value of rd_size parameter is ULONG_MAX from the following commit.
Commit 366f4aea649a65c3735d91b4409d84c771811290 ("brd: Switch rd_size
to unsigned long")
However, this parameter * 1024 will be set as inode->i_size corresponding
to brd devices and it's a signed value. To prevent overflow, this parameter
should be equal to or smaller than the max value of sector_t >> 11, 10 bits
are for 1024 and 1 bit is for sign bit.
Signed-off-by: Satoru Takeuchi
---
drivers/block/brd.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/block/brd.c b/drivers/block/brd.c
index 104b71c..2b00e7d 100644
--- a/drivers/block/brd.c
+++ b/drivers/block/brd.c
@@ -546,6 +546,14 @@ static int __init brd_init(void)
* dynamically.
*/
+ /*
+* rd_size * 1024 will be set as its inode->i_size and it's a signed
+* value. So rd_size should be equal to or smaller than the max value
+* of sector_t >> 11, 10 bits are for 1024 and 1 bit is for sign bit.
+*/
+ if (rd_size >> (sizeof(sector_t) * 8 - 11))
+ return -EINVAL;
+
if (register_blkdev(RAMDISK_MAJOR, "ramdisk"))
return -EIO;
--
2.7.4
Re: [FYI] GCC segfaults under heavy multithreaded compilation with AMD Ryzen
2017-08-11 19:07 GMT+09:00 Borislav Petkov : > On Wed, Jul 26, 2017 at 06:54:01AM +0900, Satoru Takeuchi wrote: >> # I'm a LKML subscriber, but not a x86 list subscriber >> >> I found the following new linux kernel bugzilla about Ryzen related problem. >> Since many developers don't check this bugzilla and I've also >> encountered this problem, >> I decided to introduce this problem here. >> >> https://bugzilla.kernel.org/show_bug.cgi?id=196481: >> > I am running Ubuntu and installed the mainline kernel from the mainline >> > PPA. >> > It seems like the Ryzen processor has some bug that leads to gcc crashing >> > when compiling a very large program under heavy load. This is easily >> > reproduced >> > in my system using the script from >> > >> > https://github.com/suaefar/ryzen-test >> > >> > (It assumes that you are running Ubuntu, maybe Debian also works. Just >> > clone it and run the > script kill_ryzen.sh. It downloads the gcc 7.1 code >> > and start multiple compilations of it. If any >> > compilations fails its warns the user giving the time to detect failure). >> > >> > There is already a bug report about this in the FreeBSD bugzilla >> > (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399#c89). >> > There is also a thread on the subject in AMD community forum >> > (https://community.amd.com/thread/215773?start=300&tstart=0) >> > and Phoronix >> > (https://www.phoronix.com/forums/forum/hardware/processors-memory/955368-some-ryzen-linux-users-are-facing-issues-with-heavy-compilation-loads). > > Apparently, you can RMA your CPU: > > https://www.phoronix.com/scan.php?page=news_item&px=Ryzen-Segv-Response > Sorry for late reply and thank you for letting me know. I've already RMA'ed my CPU and the new one works fine. I have one more Ryzen which I got for investigating this problem and I'll RMA it soon. Regards, Satoru > -- > Regards/Gruss, > Boris. > > ECO tip #101: Trim your mails when you reply. > --
[FYI] GCC segfaults under heavy multithreaded compilation with AMD Ryzen
# I'm a LKML subscriber, but not a x86 list subscriber I found the following new linux kernel bugzilla about Ryzen related problem. Since many developers don't check this bugzilla and I've also encountered this problem, I decided to introduce this problem here. https://bugzilla.kernel.org/show_bug.cgi?id=196481: > I am running Ubuntu and installed the mainline kernel from the mainline PPA. > It seems like the Ryzen processor has some bug that leads to gcc crashing > when compiling a very large program under heavy load. This is easily > reproduced > in my system using the script from > > https://github.com/suaefar/ryzen-test > > (It assumes that you are running Ubuntu, maybe Debian also works. Just clone > it and run the > script kill_ryzen.sh. It downloads the gcc 7.1 code and > start multiple compilations of it. If any > compilations fails its warns the user giving the time to detect failure). > > There is already a bug report about this in the FreeBSD bugzilla > (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399#c89). > There is also a thread on the subject in AMD community forum > (https://community.amd.com/thread/215773?start=300&tstart=0) > and Phoronix > (https://www.phoronix.com/forums/forum/hardware/processors-memory/955368-some-ryzen-linux-users-are-facing-issues-with-heavy-compilation-loads). > > This is probably a processor bug. But I thought that I should try to call the > attention of > the kernel developers to this issue as it may be possible to workaround it in > the kernel. > > Obs: If I disable SMT in BIOS the problem gets much better moving from > failures > after a couple of minute to one failure in 3 to 4 hours) What I want here is that this problem is known by many people, especially by x86 experts, asking the hint to find the root cause, and making the reliable workaround patch. Summary of this problem from my point of view: - gcc sometimes fails with SEGV at random - at least part of this problem is caused by running instructions at "RIP - 0x40" - tens of people encountered this problem - probably it is a hardware problem: many OSes WSL, NetBSD, and FreeBSD encountered the very similar problem. In addition, this problem happens with ECC memory and memtest86 clean memory - the root cause is not found yet. AMD have seemed to try to find it for several months, but there have been no update from AMD yet - There are workaround patch in FreeBSD, but it's not sure that it's a reliable one since the root cause is not sure Fore more detail, please refer to the links at the above mentioned bugzilla. Regards, Satoru
Re: [BUG] x86: failed to boot a kernel on a Ryzen machine
At Fri, 28 Apr 2017 15:34:06 +0200, Paolo Bonzini wrote: > > > > On 27/04/2017 02:42, Satoru Takeuchi wrote: > > At Wed, 26 Apr 2017 18:58:27 +0200, > >> On 26/04/2017 13:47, Satoru Takeuchi wrote: > >>> OK, here it is. > >> > >> It looks like the cause is that AMD has removed TBM instructions > >> compared to e.g. Piledriver, so libvirt resorts to a much older base > >> model (thanks to Dave Gilbert for sorting through the list of feature > >> bits). > > ... and the libvirt people also told me that: > > - a more recent QEMU would have enabled CPU leaf 0xD, making it possible > to use AVX inside the guest. > > - a more recent libvirt would have used Opteron_G5 as a base instead of > Opteron_G3. Oh, thank you for letting me know! Satoru > > Thanks, > > Paolo > > >> Can you please run this script: > >> > >> http://libvirt.org/git/?p=libvirt.git;a=blob_plain;f=tests/cputestdata/cpu-gather.sh;h=83963557ec4075d351be09e17994ac5300bc5d1f;hb=HEAD > >> > >> and send the output? > > > > > > OK. Here is the result. > > > > ``` > > # bash tests-cputestdata-cpu-gather.sh > > model name : AMD Ryzen 7 1800X Eight-Core Processor > > CPU: > >0x 0x00: eax=0x000d ebx=0x68747541 ecx=0x444d4163 > > edx=0x69746e65 > >0x0001 0x00: eax=0x00800f11 ebx=0x09100800 ecx=0x7ed8320b > > edx=0x178bfbff > >0x0002 0x00: eax=0x ebx=0x ecx=0x > > edx=0x > >0x0003 0x00: eax=0x ebx=0x ecx=0x > > edx=0x > >0x0005 0x00: eax=0x0040 ebx=0x0040 ecx=0x0003 > > edx=0x > >0x0006 0x00: eax=0x0004 ebx=0x ecx=0x0001 > > edx=0x > >0x0007 0x00: eax=0x ebx=0x209c01a9 ecx=0x > > edx=0x > >0x0008 0x00: eax=0x ebx=0x ecx=0x > > edx=0x > >0x0009 0x00: eax=0x ebx=0x ecx=0x > > edx=0x > >0x000a 0x00: eax=0x ebx=0x ecx=0x > > edx=0x > >0x000c 0x00: eax=0x ebx=0x ecx=0x > > edx=0x > >0x000d 0x00: eax=0x0007 ebx=0x0340 ecx=0x0340 > > edx=0x > >0x000d 0x01: eax=0x000f ebx=0x0340 ecx=0x > > edx=0x > >0x000d 0x02: eax=0x0100 ebx=0x0240 ecx=0x > > edx=0x > >0x000d 0x03: eax=0x ebx=0x ecx=0x > > edx=0x > >0x8000 0x00: eax=0x801f ebx=0x68747541 ecx=0x444d4163 > > edx=0x69746e65 > >0x8001 0x00: eax=0x00800f11 ebx=0x2000 ecx=0x35c233ff > > edx=0x2fd3fbff > >0x8002 0x00: eax=0x20444d41 ebx=0x657a7952 ecx=0x2037206e > > edx=0x30303831 > >0x8003 0x00: eax=0x69452058 ebx=0x2d746867 ecx=0x65726f43 > > edx=0x6f725020 > >0x8004 0x00: eax=0x73736563 ebx=0x2020726f ecx=0x20202020 > > edx=0x00202020 > >0x8005 0x00: eax=0xff40ff40 ebx=0xff40ff40 ecx=0x20080140 > > edx=0x40040140 > >0x8006 0x00: eax=0x26006400 ebx=0x66006400 ecx=0x02006140 > > edx=0x00808140 > >0x8007 0x00: eax=0x ebx=0x001b ecx=0x > > edx=0x6599 > >0x8008 0x00: eax=0x3030 ebx=0x0007 ecx=0x400f > > edx=0x > >0x8009 0x00: eax=0x ebx=0x ecx=0x > > edx=0x > >0x800a 0x00: eax=0x0001 ebx=0x8000 ecx=0x > > edx=0x0001bcff > >0x800b 0x00: eax=0x ebx=0x ecx=0x > > edx=0x > >0x800c 0x00: eax=0x ebx=0x ecx=0x > > edx=0x > >0x800d 0x00: eax=0x ebx=0x ecx=0x > > edx=0x > >0x800e 0x00: eax=0x ebx=0x ecx=0x > > edx=0x > >0x800f 0x00: eax=0x ebx=0x ecx=0x > > edx=0x > >0x8010 0x00: eax=0x ebx=0x ecx=0x > > edx=0x > >0x8011 0x00: eax=0x ebx=0x ecx=0x > > edx=0x > >0x8012 0x00: eax=0x ebx=0x ecx=0x > > edx=0x > >0x8013 0x00: eax=0x ebx=0x ecx=0x > > edx=0x > >0x8014 0x00: eax=0x ebx=0x ecx=0x
Re: [BUG] x86: failed to boot a kernel on a Ryzen machine
At Wed, 26 Apr 2017 18:58:27 +0200, Paolo Bonzini wrote: > > > > On 26/04/2017 13:47, Satoru Takeuchi wrote: > > OK, here it is. > > It looks like the cause is that AMD has removed TBM instructions > compared to e.g. Piledriver, so libvirt resorts to a much older base > model (thanks to Dave Gilbert for sorting through the list of feature bits). > > Can you please run this script: > > http://libvirt.org/git/?p=libvirt.git;a=blob_plain;f=tests/cputestdata/cpu-gather.sh;h=83963557ec4075d351be09e17994ac5300bc5d1f;hb=HEAD > > and send the output? OK. Here is the result. ``` # bash tests-cputestdata-cpu-gather.sh model name : AMD Ryzen 7 1800X Eight-Core Processor CPU: 0x 0x00: eax=0x000d ebx=0x68747541 ecx=0x444d4163 edx=0x69746e65 0x0001 0x00: eax=0x00800f11 ebx=0x09100800 ecx=0x7ed8320b edx=0x178bfbff 0x0002 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x0003 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x0005 0x00: eax=0x0040 ebx=0x0040 ecx=0x0003 edx=0x 0x0006 0x00: eax=0x0004 ebx=0x ecx=0x0001 edx=0x 0x0007 0x00: eax=0x ebx=0x209c01a9 ecx=0x edx=0x 0x0008 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x0009 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x000a 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x000c 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x000d 0x00: eax=0x0007 ebx=0x0340 ecx=0x0340 edx=0x 0x000d 0x01: eax=0x000f ebx=0x0340 ecx=0x edx=0x 0x000d 0x02: eax=0x0100 ebx=0x0240 ecx=0x edx=0x 0x000d 0x03: eax=0x ebx=0x ecx=0x edx=0x 0x8000 0x00: eax=0x801f ebx=0x68747541 ecx=0x444d4163 edx=0x69746e65 0x8001 0x00: eax=0x00800f11 ebx=0x2000 ecx=0x35c233ff edx=0x2fd3fbff 0x8002 0x00: eax=0x20444d41 ebx=0x657a7952 ecx=0x2037206e edx=0x30303831 0x8003 0x00: eax=0x69452058 ebx=0x2d746867 ecx=0x65726f43 edx=0x6f725020 0x8004 0x00: eax=0x73736563 ebx=0x2020726f ecx=0x20202020 edx=0x00202020 0x8005 0x00: eax=0xff40ff40 ebx=0xff40ff40 ecx=0x20080140 edx=0x40040140 0x8006 0x00: eax=0x26006400 ebx=0x66006400 ecx=0x02006140 edx=0x00808140 0x8007 0x00: eax=0x ebx=0x001b ecx=0x edx=0x6599 0x8008 0x00: eax=0x3030 ebx=0x0007 ecx=0x400f edx=0x 0x8009 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x800a 0x00: eax=0x0001 ebx=0x8000 ecx=0x edx=0x0001bcff 0x800b 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x800c 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x800d 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x800e 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x800f 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x8010 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x8011 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x8012 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x8013 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x8014 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x8015 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x8016 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x8017 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x8018 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x8019 0x00: eax=0xf040f040 ebx=0x ecx=0x edx=0x 0x801a 0x00: eax=0x0003 ebx=0x ecx=0x edx=0x 0x801b 0x00: eax=0x03ff ebx=0x ecx=0x edx=0x 0x801c 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x801d 0x00: eax=0x4121 ebx=0x01c0003f ecx=0x003f edx=0x 0x801e 0x00: eax=0x0009 ebx=0x0104 ecx=0x edx=0x 0x801f 0x00: eax=0x0007 ebx=0x016f ecx=0x000f edx=0x 0x8086 0x00: eax=0x ebx=0x ecx=0x edx=0x 0xc000 0x00: eax=0x ebx=0x ecx=0x edx=0x warning: host doesn't support requested feature: CPUID.8001H:EDX [bit 0] warning: host doesn't support requested feature: CPUID.8001H:EDX [bit 1] warning: host doesn't support requested feature: CPUID.8001H:EDX [bit 2] warning: host doesn't support requested feature: CPUID.8001H:EDX [bit 3] warning
Re: [BUG] x86: failed to boot a kernel on a Ryzen machine
At Tue, 25 Apr 2017 23:58:50 +0900, Masami Hiramatsu wrote: > > Hello, > > 2017-04-24 22:09 GMT+09:00 Satoru Takeuchi : > > At Mon, 24 Apr 2017 14:48:46 +0200, > > Borislav Petkov wrote: > >> > >> On Mon, Apr 24, 2017 at 09:39:12PM +0900, Satoru Takeuchi wrote: > >> > I used the following auto-test tool (its backend is ktest). > >> > > >> > https://github.com/satoru-takeuchi/elkdat > >> > > >> > This problem can be reproduced by the following command on Ubuntu 16.04. > >> > > >> > ``` > >> > $ sudo apt-get install git vagrant libvirt-bin libvirt-dev > >> > kernel-package qemu-kvm libssl-dev libncurses5-dev > >> > >> Can you minimize that reproducer? I.e, can you dump only the qemu > >> command line options from this setup? > >> > >> They're enough to be able to start a guest with your config without me > >> having to install all that other stuff. > > > > OK. Is it sufficient information? > > > > ``` > > qemu-system-x86_64 -enable-kvm -name elkdat_ktest -S -machine > > pc-i440fx-xenial,accel=kvm,usb=off -cpu > > Opteron_G3,+smap,+adx,+rdseed,+bmi2,+smep,+avx2,+bmi1,+fsgsbase,+perfctr_nb,+perfctr_core,+topoext,+tce,+wdt,+skinit,+osvw, > +3dnowprefetch,+cr8legacy,+extapic,+cmp_legacy,+pdpe1gb,+fxsr_opt,+mmxext,+rdrand,+f16c,+avx,+osxsave,+xsave,+aes,+movbe,+sse4.2,+sse4.1,+fma,+ssse3,+pclmuldq,+ht, > +vme -m 512 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid > 12de0e96-5d01-4ab0-b0b3-165f5560 -no-user-config -nodefaults -chardev > socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-elkdat_ktest/monitor.sock,server,nowait > -mon chardev=charmonitor,id=monitor,mode=control -rtc > base=utc -no-shutdown -boot strict=on -device > piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive > file=/var/lib/libvirt/images/ > elkdat_ktest.img,format=qcow2,if=none,id=drive-virtio-disk0 -device > virtio-blk-pci,scsi=off,bus=pci.0,addr=0x3,drive=drive-virtio-disk0,id=virtio- > disk0,bootindex=1 -netdev tap,fd=26,id=h > > ostnet0,vhost=on,vhostfd=28 -device > > virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:e4:6f:3e,bus=pci.0,addr=0x5 > > -chardev > pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -vnc > 127.0.0.1:0 -k en-us -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device > virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on > > ``` > > I also could reproduce this with Fedora 25 on Core i7-4770S, > with below options. > > "-cpu > Opteron_G3,+smap,+adx,+rdseed,+bmi2,+smep,+avx2,+bmi1,+fsgsbase,+perfctr_nb,+perfctr_core,+topoext,+tce,+wdt,+skinit,+osvw,+3dnowprefetch,+cr8legacy,+extapic,+cmp_legacy,+pdpe1gb,+fxsr_opt,+mmxext,+rdrand,+f16c,+avx,+osxsave,+xsave,+aes,+movbe,+sse4.2,+sse4.1,+fma,+ssse3,+pclmuldq,+vme > -M pc -enable-kvm -M pc -enable-kvm " > > And a quick investigation showed that this crash happened when I > replaced the "Opteron_G3" with "Opteron_G2", "Opteron_G1", "Westmere" > and "Nehalem" (I didn't check older than that). But I didn't see the > crash when I specify "Opteron_G4" or "Opteron_G5", or newer than > "SandyBridge". > > So, I guess this maybe caused by the combinations of cpu model and > flags which must not exist, maybe qemu changes available instruction > set based on cpu model, but linux checks only cpu feature flag. Yeah, probably so. I succeeded to boot my own kernel with "Opteron_G5" model and disabling "fma4", "tbm", and "xop" which Ryzen doesn't support. As Paolo said in other mail, The boot also succeeded with "host-passthrough" mode rather than "host-model". I'll wait for adding "Ryzen (or Zen?)" model to qemu. Regards, Satoru > > Thank you, > > -- > Masami Hiramatsu
Re: [BUG] x86: failed to boot a kernel on a Ryzen machine
At Wed, 26 Apr 2017 09:48:22 +0200, Paolo Bonzini wrote: > > > > On 25/04/2017 11:36, Borislav Petkov wrote: > > Looking at CR4: 003006f0, it doesn't have OSXSAVE set. I.e., bit > > 18. And when that bit is not set, VMOVDQA raises an #UD. > > > > And for some reason qemu doesn't like it even if you request that bit with > > +osxsave: > > > > warning: host doesn't support requested feature: CPUID.01H:ECX.osxsave [bit > > 27] > > > > Even though the corresponding bit in CPUID on the host is set: > > > > 0x0001: EAX=0x00800f00, EBX=0x40200800, ECX=0x7ed8320b, EDX=0x178bfbff > >^ > > Paolo, any thoughts? > > The OSXSAVE CPUID bit is not set by QEMU, it is set by the OS itself > (indirectly) when it sets CR4.OSXSAVE. QEMU says it's not available > (probably) because the Opteron_G3 CPU model does not have the 0xD CPUID > leaf. > > I think you're using libvirt's "host-model" CPU model. That model needs > QEMU/libvirt support for each host CPU family, and in general it often > gives rise to bugs such as the one you're reporting, Yes, I used "host-model". > > Change it to host-passthrough, I changed it as you said and my own kernel succeeded to boot, thank you! > and please send us the output of/proc/cpuinfo so we can add support for Ryzen > in "host-model". OK, here it is. ``` $ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 23 model : 1 model name : AMD Ryzen 7 1800X Eight-Core Processor stepping: 1 microcode : 0x800111c cpu MHz : 2200.000 cache size : 512 KB physical id : 0 siblings: 16 core id : 0 cpu cores : 8 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf eagerfpu pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_l2 mwaitx hw_pstate vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt sha_ni xsaveopt xsavec xgetbv1 xsaves clzero irperf arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic overflow_recov succor smca bugs: fxsave_leak sysret_ss_attrs null_seg bogomips: 7186.66 TLB size: 2560 4K pages clflush size: 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm hwpstate eff_freq_ro [13] [14] processor : 1 vendor_id : AuthenticAMD cpu family : 23 model : 1 model name : AMD Ryzen 7 1800X Eight-Core Processor stepping: 1 microcode : 0x800111c cpu MHz : 2200.000 cache size : 512 KB physical id : 0 siblings: 16 core id : 0 cpu cores : 8 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf eagerfpu pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_l2 mwaitx hw_pstate vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt sha_ni xsaveopt xsavec xgetbv1 xsaves clzero irperf arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic overflow_recov succor smca bugs: fxsave_leak sysret_ss_attrs null_seg bogomips: 7186.66 TLB size: 2560 4K pages clflush size: 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm hwpstate eff_freq_ro [13] [14] processor : 2 vendor_id : AuthenticAMD cpu family : 23 model : 1 model name : AMD Ryzen 7 1800X Eight-Core Processor stepping: 1 microcode : 0x800111c cpu MHz : 2200.000 cache size : 512 KB physical id : 0 siblings: 16 core id : 1 cpu cores : 8 apicid : 2 initial apicid : 2 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_
Re: [BUG] x86: failed to boot a kernel on a Ryzen machine
At Mon, 24 Apr 2017 14:48:46 +0200, Borislav Petkov wrote: > > On Mon, Apr 24, 2017 at 09:39:12PM +0900, Satoru Takeuchi wrote: > > I used the following auto-test tool (its backend is ktest). > > > > https://github.com/satoru-takeuchi/elkdat > > > > This problem can be reproduced by the following command on Ubuntu 16.04. > > > > ``` > > $ sudo apt-get install git vagrant libvirt-bin libvirt-dev kernel-package > > qemu-kvm libssl-dev libncurses5-dev > > Can you minimize that reproducer? I.e, can you dump only the qemu > command line options from this setup? > > They're enough to be able to start a guest with your config without me > having to install all that other stuff. OK. Is it sufficient information? ``` qemu-system-x86_64 -enable-kvm -name elkdat_ktest -S -machine pc-i440fx-xenial,accel=kvm,usb=off -cpu Opteron_G3,+smap,+adx,+rdseed,+bmi2,+smep,+avx2,+bmi1,+fsgsbase,+perfctr_nb,+perfctr_core,+topoext,+tce,+wdt,+skinit,+osvw,+3dnowprefetch,+cr8legacy,+extapic,+cmp_legacy,+pdpe1gb,+fxsr_opt,+mmxext,+rdrand,+f16c,+avx,+osxsave,+xsave,+aes,+movbe,+sse4.2,+sse4.1,+fma,+ssse3,+pclmuldq,+ht,+vme -m 512 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid 12de0e96-5d01-4ab0-b0b3-165f5560 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-elkdat_ktest/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/lib/libvirt/images/elkdat_ktest.img,format=qcow2,if=none,id=drive-virtio-disk0 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x3,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=26,id=h ostnet0,vhost=on,vhostfd=28 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:e4:6f:3e,bus=pci.0,addr=0x5 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -vnc 127.0.0.1:0 -k en-us -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on ``` Thanks, Satoru > > Thanks. > > -- > Regards/Gruss, > Boris. > > Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [BUG] x86: failed to boot a kernel on a Ryzen machine
At Mon, 24 Apr 2017 13:07:53 +0200,
Borislav Petkov wrote:
>
> On Mon, Apr 24, 2017 at 03:58:05PM +0900, Satoru Takeuchi wrote:
> > Recently I bought a new Ryzen machine. When I tried to test v4.11-rc8 on
> > it, it failed to boot
> > with the following panic log.
> >
> > ```
> > ...
> > [0.227720] raid6: sse2x1 gen() 7985 MB/s
> > [0.295709] raid6: sse2x1 xor() 8181 MB/s
> > [0.363706] raid6: sse2x2 gen() 17531 MB/s
> > [0.431699] raid6: sse2x2 xor() 11098 MB/s
> > [0.499693] raid6: sse2x4 gen() 18509 MB/s
> > [0.567688] raid6: sse2x4 xor() 10177 MB/s
> > [0.571692] invalid opcode: [#1] SMP
> > [0.572312] Modules linked in:
> > [0.572822] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.11.0-rc8-ktest #1
> > [0.573734] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> > Ubuntu-1.8.2-1ubuntu1 04/01/2014
> ^^
>
> Next time your report a bug, say it is a guest on the *very* first line
> of your report.
I'm very sorry.
>
> Now, how do you start your guest exactly? Full cmdline pls.
I used the following auto-test tool (its backend is ktest).
https://github.com/satoru-takeuchi/elkdat
This problem can be reproduced by the following command on Ubuntu 16.04.
```
$ sudo apt-get install git vagrant libvirt-bin libvirt-dev kernel-package
qemu-kvm libssl-dev libncurses5-dev
...
$ sudo usermod -aG libvirt
```
Log out and back in here.
```
$ sudo sed -i'' "s/Specification.all = nil/Specification.reset/"
/usr/lib/ruby/vendor_ruby/vagrant/bundler.rb # See
https://github.com/vagrant-libvirt/vagrant-libvirt/issues/575 for more details
about this patching
$ vagrant plugin install vagrant-libvirt
$ git clone https://github.com/satoru-takeuchi/elkdat.git
...
$ cp -r /path/to/linux/source elkdat/linux
$ cd elkdat
$ ./init # start guest
...
$ pushd linux
...
$ git checkout v4.11-rc8
...
$ popd
...
$ ./test boot# build and boot v4.11-rc8
... # kernel panic happens here
```
The core of the starting guest process of above mentioned tools is as follows.
1. Add the vagrant box for the guest VM
```
$ vagrant box add elastic/ubuntu-16.04-x86_64 --provider libvirt
...
```
2. Start the VM with the following Vagrantfile.
```
$ cd elkdat
$ vagrant up
```
The summary of Vagrantfile is here.
```
Vagrant.configure("2") do |config|
...
config.vm.define :ktest do |vm|
vm.vm.box = "elastic/ubuntu-16.04-x86_64"
vm.vm.synced_folder './', '/vagrant', type: 'rsync'
vm.vm.provider :libvirt do |domain|
domain.cpus = 2
end
end
...
end
```
Thanks,
Satoru
>
> --
> Regards/Gruss,
> Boris.
>
> Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [BUG] x86: failed to boot a kernel on a Ryzen machine
At Mon, 24 Apr 2017 15:58:05 +0900,
Satoru Takeuchi wrote:
>
> [1 ]
> Recently I bought a new Ryzen machine. When I tried to test v4.11-rc8 on it,
> it failed to boot
> with the following panic log.
>
> ```
> ...
> [0.227720] raid6: sse2x1 gen() 7985 MB/s
> [0.295709] raid6: sse2x1 xor() 8181 MB/s
> [0.363706] raid6: sse2x2 gen() 17531 MB/s
> [0.431699] raid6: sse2x2 xor() 11098 MB/s
> [0.499693] raid6: sse2x4 gen() 18509 MB/s
> [0.567688] raid6: sse2x4 xor() 10177 MB/s
> [0.571692] invalid opcode: [#1] SMP
> [0.572312] Modules linked in:
> [0.572822] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.11.0-rc8-ktest #1
> [0.573734] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> Ubuntu-1.8.2-1ubuntu1 04/01/2014
> [0.575040] task: 8f791e1c task.stack: 9c72c00d
> [0.575865] RIP: 0010:raid6_avx21_gen_syndrome+0x3d/0x120
> [0.576634] RSP: 0018:9c72c00d3d70 EFLAGS: 00010246
> [0.577376] RAX: RBX: 9c72c00d3dc0 RCX:
> fffedb97
> [0.578327] RDX: RSI: 1000 RDI:
> 0012
> [0.579283] RBP: 9c72c00d3da0 R08: R09:
> 00cd
> [0.580243] R10: fffedb86 R11: a617008d R12:
> 1000
> [0.581211] R13: 8f791e39e000 R14: 8f791e39f000 R15:
> 0012
> [0.582163] FS: () GS:8f791fc0()
> knlGS:
> [0.583324] CS: 0010 DS: ES: CR0: 80050033
> [0.584128] CR2: CR3: 1be09000 CR4:
> 003006f0
> [0.585078] Call Trace:
> [0.594952] raid6_select_algo+0x116/0x30b
> [0.595592] ? libcrc32c_mod_init+0x2b/0x2b
> [0.596240] do_one_initcall+0x53/0x1a0
> [0.596843] ? parse_args+0x2cf/0x490
> [0.597421] kernel_init_freeable+0x182/0x21c
> [0.598077] ? rest_init+0x80/0x80
> [0.598626] kernel_init+0xe/0x100
> [0.599175] ret_from_fork+0x2c/0x40
> [0.599741] Code: 55 41 54 53 48 89 d3 48 8d 14 c5 00 00 00 00 41 89 ff 49
> 89 f4 48 83 ec 08 4c 8b 2c c3 4c 8b 74 13 08 48 89 55 d0 e8 53 ed a9 ff
> fd 6f 05 2b 2d 4e 00 c5 e5 ef db 4d 85 e4 48 8b 55 d0 0f 84
> [0.602215] RIP: raid6_avx21_gen_syndrome+0x3d/0x120 RSP: 9c72c00d3d70
> [0.603154] ---[ end trace 17ee01f86b8fc548 ]---
> [0.603850] Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x000b
> [0.603850]
> [0.605276] ---[ end Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x000b
> ...
> ```
>
> This panic occured at lib/raid6/avx2.c#raid6_avx21_gen_syndrome() and this
> function consists of many AVX instructions.
>
> lib/raid6/avx2.c:
> ```
> /*
> * Plain AVX2 implementation
> */
> static void raid6_avx21_gen_syndrome(int disks, size_t bytes, void **ptrs)
> {
> u8 **dptr = (u8 **)ptrs;
> u8 *p, *q;
> int d, z, z0;
>
> z0 = disks - 3; /* Highest data disk */
> p = dptr[z0+1]; /* XOR parity */
> q = dptr[z0+2]; /* RS syndrome */
>
> kernel_fpu_begin();
>
> asm volatile("vmovdqa %0,%%ymm0" : : "m" (raid6_avx2_constants.x1d[0]));
> asm volatile("vpxor %ymm3,%ymm3,%ymm3");/* Zero temp */
>
> for (d = 0; d < bytes; d += 32) {
> asm volatile("prefetchnta %0" : : "m" (dptr[z0][d]));
> asm volatile("vmovdqa %0,%%ymm2" : : "m" (dptr[z0][d]));/* P[0]
> */
> asm volatile("prefetchnta %0" : : "m" (dptr[z0-1][d]));
> asm volatile("vmovdqa %ymm2,%ymm4");/* Q[0] */
> asm volatile("vmovdqa %0,%%ymm6" : : "m" (dptr[z0-1][d]));
> for (z = z0-2; z >= 0; z--) {
> asm volatile("prefetchnta %0" : : "m" (dptr[z][d]));
> asm volatile("vpcmpgtb %ymm4,%ymm3,%ymm5");
> asm volatile("vpaddb %ymm4,%ymm4,%ymm4");
> asm volatile("vpand %ymm0,%ymm5,%ymm5");
> asm volatile("vpxor %ymm5,%ymm4,%ymm4");
> asm volatile("vpxor %ymm6,%ymm2,%ymm2");
> asm volatile("vpxor %ymm6,%ymm4,%ymm4");
> asm volatile("vmovdqa %0,%%ymm6" : : "m" (dptr[z][d]));
> }
> asm volatile("vpcmpgtb %ymm4,%ymm3,%ymm5");
> asm volatile("vp
[BUG] x86: failed to boot a kernel on a Ryzen machine
Recently I bought a new Ryzen machine. When I tried to test v4.11-rc8 on it, it
failed to boot
with the following panic log.
```
...
[0.227720] raid6: sse2x1 gen() 7985 MB/s
[0.295709] raid6: sse2x1 xor() 8181 MB/s
[0.363706] raid6: sse2x2 gen() 17531 MB/s
[0.431699] raid6: sse2x2 xor() 11098 MB/s
[0.499693] raid6: sse2x4 gen() 18509 MB/s
[0.567688] raid6: sse2x4 xor() 10177 MB/s
[0.571692] invalid opcode: [#1] SMP
[0.572312] Modules linked in:
[0.572822] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.11.0-rc8-ktest #1
[0.573734] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
Ubuntu-1.8.2-1ubuntu1 04/01/2014
[0.575040] task: 8f791e1c task.stack: 9c72c00d
[0.575865] RIP: 0010:raid6_avx21_gen_syndrome+0x3d/0x120
[0.576634] RSP: 0018:9c72c00d3d70 EFLAGS: 00010246
[0.577376] RAX: RBX: 9c72c00d3dc0 RCX: fffedb97
[0.578327] RDX: RSI: 1000 RDI: 0012
[0.579283] RBP: 9c72c00d3da0 R08: R09: 00cd
[0.580243] R10: fffedb86 R11: a617008d R12: 1000
[0.581211] R13: 8f791e39e000 R14: 8f791e39f000 R15: 0012
[0.582163] FS: () GS:8f791fc0()
knlGS:
[0.583324] CS: 0010 DS: ES: CR0: 80050033
[0.584128] CR2: CR3: 1be09000 CR4: 003006f0
[0.585078] Call Trace:
[0.594952] raid6_select_algo+0x116/0x30b
[0.595592] ? libcrc32c_mod_init+0x2b/0x2b
[0.596240] do_one_initcall+0x53/0x1a0
[0.596843] ? parse_args+0x2cf/0x490
[0.597421] kernel_init_freeable+0x182/0x21c
[0.598077] ? rest_init+0x80/0x80
[0.598626] kernel_init+0xe/0x100
[0.599175] ret_from_fork+0x2c/0x40
[0.599741] Code: 55 41 54 53 48 89 d3 48 8d 14 c5 00 00 00 00 41 89 ff 49
89 f4 48 83 ec 08 4c 8b 2c c3 4c 8b 74 13 08 48 89 55 d0 e8 53 ed a9 ff fd
6f 05 2b 2d 4e 00 c5 e5 ef db 4d 85 e4 48 8b 55 d0 0f 84
[0.602215] RIP: raid6_avx21_gen_syndrome+0x3d/0x120 RSP: 9c72c00d3d70
[0.603154] ---[ end trace 17ee01f86b8fc548 ]---
[0.603850] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x000b
[0.603850]
[0.605276] ---[ end Kernel panic - not syncing: Attempted to kill init!
exitcode=0x000b
...
```
This panic occured at lib/raid6/avx2.c#raid6_avx21_gen_syndrome() and this
function consists of many AVX instructions.
lib/raid6/avx2.c:
```
/*
* Plain AVX2 implementation
*/
static void raid6_avx21_gen_syndrome(int disks, size_t bytes, void **ptrs)
{
u8 **dptr = (u8 **)ptrs;
u8 *p, *q;
int d, z, z0;
z0 = disks - 3; /* Highest data disk */
p = dptr[z0+1]; /* XOR parity */
q = dptr[z0+2]; /* RS syndrome */
kernel_fpu_begin();
asm volatile("vmovdqa %0,%%ymm0" : : "m" (raid6_avx2_constants.x1d[0]));
asm volatile("vpxor %ymm3,%ymm3,%ymm3");/* Zero temp */
for (d = 0; d < bytes; d += 32) {
asm volatile("prefetchnta %0" : : "m" (dptr[z0][d]));
asm volatile("vmovdqa %0,%%ymm2" : : "m" (dptr[z0][d]));/* P[0]
*/
asm volatile("prefetchnta %0" : : "m" (dptr[z0-1][d]));
asm volatile("vmovdqa %ymm2,%ymm4");/* Q[0] */
asm volatile("vmovdqa %0,%%ymm6" : : "m" (dptr[z0-1][d]));
for (z = z0-2; z >= 0; z--) {
asm volatile("prefetchnta %0" : : "m" (dptr[z][d]));
asm volatile("vpcmpgtb %ymm4,%ymm3,%ymm5");
asm volatile("vpaddb %ymm4,%ymm4,%ymm4");
asm volatile("vpand %ymm0,%ymm5,%ymm5");
asm volatile("vpxor %ymm5,%ymm4,%ymm4");
asm volatile("vpxor %ymm6,%ymm2,%ymm2");
asm volatile("vpxor %ymm6,%ymm4,%ymm4");
asm volatile("vmovdqa %0,%%ymm6" : : "m" (dptr[z][d]));
}
asm volatile("vpcmpgtb %ymm4,%ymm3,%ymm5");
asm volatile("vpaddb %ymm4,%ymm4,%ymm4");
asm volatile("vpand %ymm0,%ymm5,%ymm5");
asm volatile("vpxor %ymm5,%ymm4,%ymm4");
asm volatile("vpxor %ymm6,%ymm2,%ymm2");
asm volatile("vpxor %ymm6,%ymm4,%ymm4");
asm volatile("vmovntdq %%ymm2,%0" : "=m" (p[d]));
asm volatile("vpxor %ymm2,%ymm2,%ymm2");
asm volatile("vmovntdq %%ymm4,%0" : "=m" (q[d]));
asm volatile("vpxor %ymm4,%ymm4,%ymm4");
}
asm volatile("sfence" : : : "memory");
kernel_fpu_end();
}
```
This problem can be bypassed by the following patch.
```
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 2d44933..b589097 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefi
Linux kernel statistics from the other perspective than existing ones
I wrote an article about linux kernel statistics by analyzing linux kernel source code. Although there are many such the articles, most of them mainly focus on who develops linux kernel. However, this article doesn't care about that at all. It focuses on the following things instead. - Which subsystems the kernel consists of? - Which type of drivers are the main contents in the whole drivers code? - Whether the newly added drivers code are mainly for new drivers or for existing ones? - What are the characteristics of both rc kernels and stable kernels? Please take a look at it. https://github.com/satoru-takeuchi/linux-kernel-statistics/blob/master/README.md Thanks, Satoru
[PATCH] cgroup: change the limit of CGROUP_SUBSYS_COUNT depending on the size of the corresponding bitmasks
The limit of CGROUP_SUBSYS_COUNT is hardcoded to 16. This value comes from the size of the corresponding bitmasks, u16. It's better to change this limit depending on the size of the corresponding bitmasks because of the following reasons. - to avoid setting the wrong limit when the size of the corresponding bitmasks are changed - to make the meaning of this limit clear Signed-off-by: Satoru Takeuchi --- kernel/cgroup/cgroup.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c index 4885132..576b184 100644 --- a/kernel/cgroup/cgroup.c +++ b/kernel/cgroup/cgroup.c @@ -4490,7 +4490,8 @@ int __init cgroup_init(void) struct cgroup_subsys *ss; int ssid; - BUILD_BUG_ON(CGROUP_SUBSYS_COUNT > 16); + BUILD_BUG_ON(CGROUP_SUBSYS_COUNT > (sizeof(cgroup_disable_mask) * __CHAR_BIT__)); + BUG_ON(percpu_init_rwsem(&cgroup_threadgroup_rwsem)); BUG_ON(cgroup_init_cftypes(NULL, cgroup_base_files)); BUG_ON(cgroup_init_cftypes(NULL, cgroup1_base_files)); -- 2.7.4
[ANNOUNCE] elkdat: an easy linux kernel development and test tool
elkdat is a tool to ease linux kernel development/test. It automatically setups linux kernel source repository and a VM for linux kernel development and test. In addition, It runs the following kinds of tests automatically just by one command. - build, install, boot you own kernel - run your own tests on your own kernel - test the all patches in a patchset - find a problematic commit with bisect NOTE: Actually these features are achieved by ktest. elkdat is just a ktest's wrapper. Special thanks to Steven Rostedt! Here are some examples. * Boot your own kernel ``` $ ./test boot ``` * Run your own test on your own kernel ``` $ ./test test /path/to/your/own/test ``` * Test whether all patches in your patcheset are bootable or not one by one ``` $ ./test patchcheck boot ``` * Find which commit introduces an un-bootable bug by bysect ``` ./test bisect boot ``` For more information, please refer to the following URL. https://github.com/satoru-takeuchi/elkdat Thanks, Satoru
[PATCH] mm: remove unnecessary description about a non-exist gfp flag
Since __GFP_NOACCOUNT is removed by the following commit,
its description is not necessary.
commit 20b5c3039863 ("Revert 'gfp: add __GFP_NOACCOUNT'")
Signed-off-by: Satoru Takeuchi
---
include/linux/gfp.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index af1f2b2..7c76a6e 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -101,8 +101,6 @@ struct vm_area_struct;
*
* __GFP_NOMEMALLOC is used to explicitly forbid access to emergency reserves.
* This takes precedence over the __GFP_MEMALLOC flag if both are set.
- *
- * __GFP_NOACCOUNT ignores the accounting for kmemcg limit enforcement.
*/
#define __GFP_ATOMIC ((__force gfp_t)___GFP_ATOMIC)
#define __GFP_HIGH ((__force gfp_t)___GFP_HIGH)
--
2.5.0
Re: [PATCH 3.12 00/78] 3.12.36-stable review
At Fri, 9 Jan 2015 09:59:10 -0800, Guenter Roeck wrote: > > On Fri, Jan 09, 2015 at 11:30:32AM +0100, Jiri Slaby wrote: > > This is the start of the stable review cycle for the 3.12.36 release. > > There are 78 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Tue Jan 13 11:29:45 CET 2015. > > Anything received after that time might be too late. > > > Build results: > total: 135 pass: 135 fail: 0 > Qemu tests: > total: 27 pass: 27 fail: 0 > > Details are available at http://server.roeck-us.net:8010/builders. > > Guenter Plus, this kernel passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.18 00/84] 3.18.2-stable review
At Tue, 6 Jan 2015 17:49:03 -0800, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.18.2 release. > There are 84 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Fri Jan 9 01:40:07 UTC 2015. > Anything received after that time might be too late. All 3.10.64-rc1, 3.14.28-rc1, 3.17.8-rc1, and 3.18.2-rc1 passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.18.2-rc1.gz > and the diffstat can be found below. > > thanks, > > greg k-h > > - > Pseudo-Shortlog of commits: > > Greg Kroah-Hartman > Linux 3.18.2-rc1 > > Filipe Manana > Btrfs: fix fs corruption on transaction abort if device supports discard > > Josef Bacik > Btrfs: make sure logged extents complete in the current transaction V3 > > Josef Bacik > Btrfs: do not move em to modified list when unpinning > > David Sterba > btrfs: fix wrong accounting of raid1 data profile in statfs > > Josef Bacik > Btrfs: make sure we wait on logged extents when fsycning two subvols > > Michael Halcrow > eCryptfs: Remove buggy and unnecessary write in file name decode routine > > Tyler Hicks > eCryptfs: Force RO mount when encrypted view is enabled > > Jan Kara > udf: Check component length before reading it > > Jan Kara > udf: Verify symlink size before loading it > > Jan Kara > udf: Verify i_size when loading inode > > Jan Kara > udf: Check path length when reading symlink > > Oleg Nesterov > exit: pidns: alloc_pid() leaks pid_namespace if child_reaper is exiting > > Joonsoo Kim > mm/CMA: fix boot regression due to physical address of high_memory > > Jan Kara > ncpfs: return proper error from NCP_IOC_SETROOT ioctl > > Rabin Vincent > crypto: af_alg - fix backlog handling > > Richard Guy Briggs > audit: restore AUDIT_LOGINUID unset ABI > > Paul Moore > audit: don't attempt to lookup PIDs when changing PID filtering audit > rules > > Richard Guy Briggs > audit: use supplied gfp_mask from audit_buffer in > kauditd_send_multicast_skb > > Eric W. Biederman > userns: Unbreak the unprivileged remount tests > > Eric W. Biederman > userns: Allow setting gid_maps without privilege when setgroups is > disabled > > Eric W. Biederman > userns: Add a knob to disable setgroups on a per user namespace basis > > Eric W. Biederman > userns: Rename id_map_mutex to userns_state_mutex > > Eric W. Biederman > userns: Only allow the creator of the userns unprivileged mappings > > Eric W. Biederman > userns: Check euid no fsuid when establishing an unprivileged uid mapping > > Eric W. Biederman > userns: Don't allow unprivileged creation of gid mappings > > Eric W. Biederman > userns: Don't allow setgroups until a gid mapping has been setablished > > Eric W. Biederman > userns: Document what the invariant required for safe unprivileged > mappings. > > Eric W. Biederman > groups: Consolidate the setgroups permission checks > > Eric W. Biederman > umount: Disallow unprivileged mount force > > Eric W. Biederman > mnt: Update unprivileged remount test > > Eric W. Biederman > mnt: Implicitly add MNT_NODEV on remount when it was implicitly added by > mount > > Luis Henriques > thermal: Fix error path in thermal_init() > > Eric W. Biederman > mnt: Fix a memory stomp in umount > > Johannes Berg > mac80211: free management frame keys when removing station > > Andreas Müller > mac80211: fix multicast LED blinking and counter > > Jes Sorensen > mac80211: avoid using uninitialized stack data > > Felix Fietkau > mac80211: copy chandef from AP vif to VLANs > > Takashi Iwai > KEYS: Fix stale key registration
Re: [PATCH] btrfs: clear bio reference after submit_one_bio()
Hi Naota, On 2015/01/06 1:01, Naohiro Aota wrote: > After submit_one_bio(), `bio' can go away. However submit_extent_page() > leave `bio' referable if submit_one_bio() failed (e.g. -ENOMEM on OOM). > It will cause invalid paging request when submit_extent_page() is called > next time. > > I reproduced ENOMEM case with the following script (need > CONFIG_FAIL_PAGE_ALLOC, and CONFIG_FAULT_INJECTION_DEBUG_FS). I confirmed that this problem reproduce with 3.19-rc3 and not reproduce with 3.19-rc3 with your patch. Tested-by: Satoru Takeuchi Thank you for reporting this problem with the reproducer and fixing it too. NOTE: I used v3.19-rc3's tools/testing/fault-injection/failcmd.sh for the following "./failcmd.sh". >./failcmd.sh -p $percent -t $times -i $interval \ >--ignore-gfp-highmem=N --ignore-gfp-wait=N --min-order=0 \ >-- \ >cat $directory/file > /dev/null * 3.19-rc1 + your patch === # ./run 512+0 records in 512+0 records out # === * 3.19-rc3 === # ./run 512+0 records in 512+0 records out [ 188.433726] run (776): drop_caches: 1 [ 188.682372] FAULT_INJECTION: forcing a failure. name fail_page_alloc, interval 100, probability 111000, space 0, times 3 [ 188.689986] CPU: 0 PID: 954 Comm: cat Not tainted 3.19.0-rc3-ktest #1 [ 188.693834] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 [ 188.698466] 0064 88007b343618 816e5563 88007fc0fc78 [ 188.702730] 81c655c0 88007b343638 813851b5 0010 [ 188.707043] 0002 88007b343768 81188126 88007b3435a8 [ 188.711283] Call Trace: [ 188.712620] [] dump_stack+0x45/0x57 [ 188.715330] [] should_fail+0x135/0x140 [ 188.718218] [] __alloc_pages_nodemask+0xd6/0xb30 [ 188.721567] [] ? blk_rq_map_sg+0x35/0x170 [ 188.724558] [] ? virtio_queue_rq+0x145/0x2b0 [virtio_blk] [ 188.728191] [] ? btrfs_submit_compressed_read+0xcf/0x4d0 [btrfs] [ 188.732079] [] ? kmem_cache_alloc+0x1cb/0x230 [ 188.735153] [] ? mempool_alloc_slab+0x15/0x20 [ 188.738188] [] alloc_pages_current+0x9a/0x120 [ 188.741153] [] btrfs_submit_compressed_read+0x1a9/0x4d0 [btrfs] [ 188.744835] [] btrfs_submit_bio_hook+0x1c1/0x1d0 [btrfs] [ 188.748225] [] ? lookup_extent_mapping+0x13/0x20 [btrfs] [ 188.751547] [] ? btrfs_get_extent+0x98/0xad0 [btrfs] [ 188.754656] [] submit_one_bio+0x67/0xa0 [btrfs] [ 188.757554] [] submit_extent_page.isra.35+0xd7/0x1c0 [btrfs] [ 188.760981] [] __do_readpage+0x31d/0x7b0 [btrfs] [ 188.763920] [] ? btrfs_create_repair_bio+0x110/0x110 [btrfs] [ 188.767382] [] ? btrfs_submit_direct+0x7b0/0x7b0 [btrfs] [ 188.770671] [] ? btrfs_lookup_ordered_range+0x13d/0x180 [btrfs] [ 188.774366] [] __extent_readpages.constprop.42+0x2ba/0x2d0 [btrfs] [ 188.778031] [] ? btrfs_submit_direct+0x7b0/0x7b0 [btrfs] [ 188.781241] [] extent_readpages+0x169/0x1b0 [btrfs] [ 188.784322] [] ? btrfs_submit_direct+0x7b0/0x7b0 [btrfs] [ 188.789014] [] btrfs_readpages+0x1f/0x30 [btrfs] [ 188.792028] [] __do_page_cache_readahead+0x18c/0x1f0 [ 188.795078] [] ondemand_readahead+0xdf/0x260 [ 188.797702] [] ? btrfs_congested_fn+0x5f/0xa0 [btrfs] [ 188.800718] [] page_cache_async_readahead+0x71/0xa0 [ 188.803650] [] generic_file_read_iter+0x40f/0x5e0 [ 188.806480] [] new_sync_read+0x7e/0xb0 [ 188.808832] [] __vfs_read+0x18/0x50 [ 188.811068] [] vfs_read+0x8a/0x140 [ 188.813298] [] SyS_read+0x46/0xb0 [ 188.815486] [] ? __audit_syscall_exit+0x1f6/0x2a0 [ 188.818293] [] system_call_fastpath+0x12/0x17 [ 188.821005] BUG: unable to handle kernel paging request at 0001000c [ 188.821984] IP: [] submit_one_bio+0x43/0xa0 [btrfs] [ 188.821984] PGD 7bad3067 PUD 0 [ 188.821984] Oops: [#1] SMP [ 188.821984] Modules linked in: ip6table_filter ip6_tables ebtable_nat ebtables bnep bluetooth rfkill btrfs xor raid6_pq microcode 8139too serio_raw virtio_balloon 8139cp mii nfsd auth_rpcgss nfs_acl lockd grace sunrpc virtio_blk ata_generic pata_acpi [ 188.821984] CPU: 1 PID: 954 Comm: cat Not tainted 3.19.0-rc3-ktest #1 [ 188.821984] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 [ 188.821984] task: 880037665220 ti: 88007b34 task.ti: 88007b34 [ 188.821984] RIP: 0010:[] [] submit_one_bio+0x43/0xa0 [btrfs] [ 188.821984] RSP: 0018:88007b3438c8 EFLAGS: 00010202 [ 188.821984] RAX: RBX: 88007c282ba8 RCX: 00010001 [ 188.821984] RDX: RSI: fff4 RDI: [ 188.821984] RBP: 88007b3438d8 R08: ea0001e33100 R
Re: [PATCH 3.2 00/27] 3.2.66-rc1 review
At Mon, 29 Dec 2014 02:11:30 +0100, Ben Hutchings wrote: > > This is the start of the stable review cycle for the 3.2.66 release. > There are 27 patches in this series, which will be posted as responses > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed Dec 31 12:00:00 UTC 2014. > Anything received after that time might be too late. This kernel passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru > > A combined patch relative to 3.2.65 will be posted as an additional > response to this. A shortlog and diffstat can be found below. > > Ben. > > - > > Al Viro (2): > deal with deadlock in d_walk() > [ca5358ef75fc69fee5322a38a340f5739d997c10] > move d_rcu from overlapping d_child to overlapping d_alias > [946e51f2bf37f1656916eb75bd0742ba33983c28] > > Anatol Pomozov (1): > ext4: make orphan functions be no-op in no-journal mode > [c9b92530a723ac5ef8e352885a1862b18f31b2f5] > > Andy Lutomirski (2): > x86, kvm: Clear paravirt_enabled on KVM guests for espfix32's benefit > [29fa6825463c97e5157284db80107d1bfac5d77b] > x86/tls: Validate TLS entries to protect espfix > [41bdc78544b8a93a9c6814b8bbbfef966272abbe] > > Ard Biesheuvel (1): > crypto: ghash-clmulni-intel - use C implementation for setkey() > [8ceee72808d1ae3fb191284afc2257a2be964725] > > Ben Hutchings (2): > drivers/net, ipv6: Select IPv6 fragment idents for virtio UFO packets > [5188cd44c55db3e92cd9e77a40b5baa7ed4340f7] > drivers/net: macvtap and tun depend on INET > [de11b0e8c569b96c2cf6a811e3805b7aeef498a3] > > Dan Carpenter (1): > [media] ttusb-dec: buffer overflow in ioctl > [f2e323ec96077642d397bb1c355def536d489d16] > > Daniel Borkmann (3): > net: sctp: fix NULL pointer dereference in af->from_addr_param on > malformed packet > [e40607cbe270a9e8360907cb1e62ddf0736e4864] > net: sctp: fix memory leak in auth key management > [4184b2a79a7612a9272ce20d639934584a1f3786] > net: sctp: use MAX_HEADER for headroom reserve in output path > [9772b54c55266ce80c639a80aa68eeb908f8ecf5] > > Daniel Vetter (1): > drm/i915: Unlock panel even when LVDS is disabled > [b0616c5306b342ceca07044dbc4f917d95c4f825] > > David Herrmann (1): > drm: fix DRM_IOCTL_MODE_GETFB handle-leak > [101b96f32956ee99bf1468afaf572b88cda9f88b] > > Devin Ryles (1): > AHCI: Add DeviceIDs for Sunrise Point-LP SATA controller > [249cd0a187ed4ef1d0af7f74362cc2791ec5581b] > > Dmitry Torokhov (1): > sata_fsl: fix error handling of irq_of_parse_and_map > [aad0b624129709c94c2e19e583b6053520353fa8] > > Eric Dumazet (2): > tcp: md5: do not use alloc_percpu() > [349ce993ac706869d553a1816426d3a4bfda02b1] > tcp: md5: remove spinlock usage in fast path > [71cea17ed39fdf1c0634f530ddc6a2c2fc601c2b] > > Grygorii Strashko (1): > i2c: davinci: generate STP always when NACK is received > [9ea359f7314132cbcb5a502d2d8ef095be1f45e4] > > Hugh Dickins (1): > mm: fix swapoff hang after page migration and fork > [2022b4d18a491a578218ce7a4eca8666db895a73] > > Jan Kara (1): > udf: Avoid infinite loop when processing indirect ICBs > [c03aa9f6e1f938618e6db2e23afef0574efeeb65] > > Jiri Pirko (1): > ipv4: fix nexthop attlen check in fib_nh_match > [f76936d07c4eeb36d8dbb64ebd30ab46ff85d9f7] > > Martin Schwidefsky (1): > s390,time: revert direct ktime path for s390 clockevent device > [8adbf78ec4839c1dc4ff20c9a1f332a7bc99e6e6] > > Nadav Amit (1): > KVM: x86: Don't report guest userspace emulation error to userspace > [a2b9e6c1a35afcc0973acb72e591c714e78885ff] > > Paolo Bonzini (1): > x86: kvm: use alternatives for VMCALL vs. VMMCALL if kernel text is > read-only > [c1118b3602c2329671ad5ec8bdf8e374323d6343] > > Tejun Heo (1): > ahci: disable MSI on SAMSUNG 0
Re: [PATCH 3.12 000/197] 3.12.31-stable review
Hi Jiri,
At Fri, 17 Oct 2014 10:11:30 +0200,
Jiri Slaby wrote:
>
> This is the start of the stable review cycle for the 3.12.31 release.
> There are 197 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Tue Oct 21 10:08:49 CEST 2014.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
>
> http://kernel.org/pub/linux/kernel/people/jirislaby/stable-review/patch-3.12.31-rc1.xz
> and the diffstat can be found below.
This kernel passed my test.
- Test Cases:
- Build this kernel.
- Boot this kernel.
- Build the latest mainline kernel with this kernel.
- Test Tool:
https://github.com/satoru-takeuchi/test-linux-stable
- Test Result (kernel .config, ktest config and test log):
http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz
- Build Environment:
- OS: Debian Jessy x86_64
- CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4
- memory: 8GB
- Test Target Environment:
- Debian Jessy x86_64 (KVM guest on the Build Environment)
- # of vCPU: 2
- memory: 2GB
Thanks,
Satoru
>
> thanks,
> js
>
> ===
>
>
> Al Viro (1):
> don't bugger nd->seq on set_root_rcu() from follow_dotdot_rcu()
>
> Alan Douglas (1):
> xtensa: fix address checks in dma_{alloc,free}_coherent
>
> Alan Stern (1):
> USB: EHCI: unlink QHs even after the controller has stopped
>
> Alex Deucher (8):
> drm/radeon/dpm: set the thermal type properly for special configs
> drm/radeon: add connector quirk for fujitsu board
> drm/radeon: don't reset dma on NI/SI init
> drm/radeon: don't reset sdma on CIK init
> drm/radeon: don't reset dma on r6xx-evergreen init
> drm/radeon/cik: use a separate counter for CP init timeout
> vgaswitcheroo: add vga_switcheroo_fini_domain_pm_ops
> drm/nouveau/runpm: fix module unload
>
> Alex Gartrell (1):
> ipvs: Maintain all DSCP and ECN bits for ipv6 tun forwarding
>
> Andreas Bomholtz (1):
> USB: cp210x: add support for Seluxit USB dongle
>
> Andreas Rohner (1):
> nilfs2: fix data loss with mmap()
>
> Andrew Hunter (1):
> jiffies: Fix timeval conversion to jiffies
>
> Andrey Vagin (2):
> fsnotify/fdinfo: use named constants instead of hardcoded values
> fs/notify: don't show f_handle if exportfs_encode_inode_fh failed
>
> Andy Shevchenko (2):
> dmaengine: dw: introduce dwc_dostart_first_queued() helper
> dmaengine: dw: don't perform DMA when dmaengine_submit is called
>
> Anssi Hannula (1):
> dm cache: fix race causing dirty blocks to be marked as clean
>
> Anton Altaparmakov (1):
> Fix nasty 32-bit overflow bug in buffer i/o code.
>
> Arnd Bergmann (1):
> staging/lustre: disable virtual block device for 64K pages
>
> Aurelien Jarno (1):
> MIPS: ZBOOT: add missing include
>
> Benjamin Tissoires (1):
> HID: logitech-dj: prevent false errors to be shown
>
> Bjørn Mork (2):
> USB: sierra: avoid CDC class functions on "68A3" devices
> USB: sierra: add 1199:68AA device ID
>
> Brennan Ashton (1):
> USB: option: add VIA Telecom CDS7 chipset device id
>
> Bryan O'Donoghue (1):
> serial: 8250: Add Quark X1000 to 8250_pci.c
>
> Chen-Yu Tsai (1):
> i2c: mv64xxx: continue probe when clock-frequency is missing
>
> Chris Wilson (1):
> drm/i915: Flush the PTEs after updating them before suspend
>
> Christian Borntraeger (1):
> KVM: s390/mm: try a cow on read only pages for key ops
>
> Clemens Ladisch (2):
> ALSA: core: fix buffer overflow in snd_info_get_line()
> ALSA: pcm: fix fifo_size frame calculation
>
> Cong Wang (1):
> perf: Fix a race condition in perf_remove_from_context()
>
> Dan Carpenter (2):
> NFC: microread: Potential overflows in microread_target_discovered()
> partitions: aix.c: off by one bug
>
> Daniel Borkmann (1):
> netlink: reset network header before passing to taps
>
> Daniel Vetter (1):
> drm/i915: Fix EIO/wedged handling in gem fault handler
>
> Dave Martin (1):
> ARM: 7897/1: kexec: Use the right ISA for relocate_new_kernel
>
> David Jeffery (1):
> nfs: Don't busy-wait on SIGKILL in __nfs_iocounter_wait
>
> David Rientjes (1):
> mm, slab: initialize object alignment on cache creation
>
> Denis CIOCCA (1):
> iio:magnetometer: bugfix magnetometers gain values
>
> Dmitry Torokhov (2):
> Input: synaptics - add support for ForcePads
> Input: atkbd - do not try 'deactivate' keyboard on any LG laptops
>
> El
Re: [PATCH 3.17 00/25] 3.17.1-stable review
At Tue, 14 Oct 2014 05:26:07 +0200, Greg Kroah-Hartman wrote: > > On Tue, Oct 14, 2014 at 04:39:11AM +0200, Greg Kroah-Hartman wrote: > > On Mon, Oct 13, 2014 at 08:19:56AM -0700, Guenter Roeck wrote: > > > On 10/12/2014 07:24 PM, Greg Kroah-Hartman wrote: > > > >This is the start of the stable review cycle for the 3.17.1 release. > > > >There are 25 patches in this series, all will be posted as a response > > > >to this one. If anyone has any issues with these being applied, please > > > >let me know. > > > > > > > >Responses should be made by Wed Oct 15 02:24:45 UTC 2014. > > > >Anything received after that time might be too late. > > > > > > > > > > Build results: > > > total: 134 pass: 134 fail: 0 > > > > > > Qemu test results: > > > total: 30 pass: 30 fail: 0 > > > > > > Details are available at http://server.roeck-us.net:8010/builders. > > > > Thanks for testing all 3 of these and letting me know. > > All 4, sorry... Those 4 kernels also passd my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.16 00/26] 3.16.5-stable review
At Tue, 7 Oct 2014 21:48:04 -0700, Greg Kroah-Hartman wrote: > > On Tue, Oct 07, 2014 at 07:47:13PM -0700, Guenter Roeck wrote: > > On 10/07/2014 04:19 PM, Greg Kroah-Hartman wrote: > > >This is the start of the stable review cycle for the 3.16.5 release. > > >There are 26 patches in this series, all will be posted as a response > > >to this one. If anyone has any issues with these being applied, please > > >let me know. > > > > > >Responses should be made by Thu Oct 9 23:18:40 UTC 2014. > > >Anything received after that time might be too late. > > > > > > > Build results: > > total: 136 pass: 136 fail: 0 > > Qemu tests: > > total: 30 pass: 30 fail: 0 > > > > Details are available at http://server.roeck-us.net:8010/builders. > > Wonderful, thanks for testing all 3 of these and letting me know. Plus, all these kernels passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.16 000/357] 3.16.4-stable review
At Fri, 3 Oct 2014 14:26:26 -0700, Greg Kroah-Hartman wrote: > > - > Note: This is a big stable release. Mostly my fault for being on the > road last week, combined with an unusually large number of patches being > tagged for the stable tree. Anyway, I've caught up with all pending > patches before 3.17-rc7, so if you have marked something for the stable > tree that I have not applied, or emailed the stable@v.k.o list asking > for a patch, that is not here, please let me know. > - > > This is the start of the stable review cycle for the 3.16.4 release. > There are 357 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun Oct 5 21:28:42 UTC 2014. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.16.4-rc1.gz > and the diffstat can be found below. Al 3.16.4-rc1, 3.14.20-rc1, and 3.10.56-rc1 passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru > > thanks, > > greg k-h > > - > Pseudo-Shortlog of commits: > > Greg Kroah-Hartman > Linux 3.16.4-rc1 > > Stephen Boyd > clk: qcom: Fix PLL rate configurations > > Stephen Boyd > clk: qcom: mdp_lut_clk is a child of mdp_src > > Stephen Boyd > clk: qcom: Fix MN frequency tables, parent map, and jpegd > > Arnd Bergmann > staging/lustre: disable virtual block device for 64K pages > > Theodore Ts'o > ext4: avoid trying to kfree an ERR_PTR pointer > > Theodore Ts'o > ext4: propagate errors up to ext4_find_entry()'s callers > > Gu Zheng > aio: block exit_aio() until all context requests are completed > > Suman Tripathi > ahci_xgene: Removing NCQ support from the APM X-Gene SoC AHCI SATA Host > Controller driver. > > Nishanth Menon > clk: ti: divider: Provide error check for incoming parameters in set_rate > > Tero Kristo > clk: prevent erronous parsing of children during rate change > > Nishanth Menon > clk: ti: dra7-atl: Provide error check for incoming parameters in set_rate > > Viresh Kumar > cpufreq: update 'cpufreq_suspended' after stopping governors > > Dan Carpenter > partitions: aix.c: off by one bug > > Andy Shevchenko > dmaengine: dw: don't perform DMA when dmaengine_submit is called > > Andy Shevchenko > dmaengine: dw: introduce dwc_dostart_first_queued() helper > > Ulf Hansson > mmc: mmci: Reverse IRQ handling for the arm_variant > > Pablo Neira Ayuso > netfilter: nf_tables: don't update chain with unset counters > > Julian Anastasov > ipvs: fix ipv6 hook registration for local replies > > Daniel Borkmann > netfilter: x_tables: allow to use default cgroup match > > Alex Gartrell > ipvs: Maintain all DSCP and ECN bits for ipv6 tun forwarding > > Eric Dumazet > netfilter: xt_hashlimit: perform garbage collection from process context > > NeilBrown > md/raid1: intialise start_next_window for READ case to avoid hang > > NeilBrown > md/raid1: fix_read_error should act on all non-faulty devices. > > NeilBrown > md/raid1: count resync requests in nr_pending. > > NeilBrown > md/raid1: update next_resync under resync_lock. > > NeilBrown > md/raid1: Don't use next_resync to determine how far resync has progressed > > NeilBrown > md/raid1: make sure resync waits for conflicting writes to complete. > > NeilBrown > md/raid1: be more cautious where we read-balance during resync. > > NeilBrown > md/raid1: clean up request counts properly in close_sync() > > Zhaowei Yuan > media: vb2: fix plane index sanity check in vb2_plane_cookie() > > Hans Verkuil > media: vb2: fix vb2 state check when start_streaming fails > > Hans Verkuil > media: videobuf2-dma-sg: fix for wrong GFP mask to > sg_al
Re: [PATCH 3.12 00/96] 3.12.30-stable review
At Wed, 1 Oct 2014 10:57:39 +0200, Jiri Slaby wrote: > > This is the start of the stable review cycle for the 3.12.30 release. > There are 96 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > This one is special. First, it is rounded (30). Second, most of the > patches are performance improvements. They are coming from SUSE > Enterprise Linux and all are backed by proper testing and performance > measurements. All this patchset was prepared and sent by Mel Gorman > with a support of other patchers from SUSE. Thanks to all of them. > > As this is special, I am gicing a whole week for responses. So > responses should be made by Wed Oct 8 09:12:02 CEST 2014. Anything > received after that time might be too late. > > The whole patch series can be found in one patch at: > > http://kernel.org/pub/linux/kernel/people/jirislaby/stable-review/patch-3.12.30-rc1.xz > and the diffstat can be found below. > > thanks, > js This kernel passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru > > === > > > Al Viro (1): > callers of iov_copy_from_user_atomic() don't need pagecache_disable() > > Bob Liu (2): > mm: thp: cleanup: mv alloc_hugepage to better place > mm: thp: khugepaged: add policy for finding target node > > Christoph Lameter (1): > vmscan: reclaim_clean_pages_from_list() must use mod_zone_page_state() > > Damien Ramonda (1): > readahead: fix sequential read cache miss detection > > Dan Streetman (4): > swap: change swap_info singly-linked list to list_head > lib/plist: add helper functions > lib/plist: add plist_requeue > swap: change swap_list_head to plist, add swap_avail_head > > Dave Chinner (1): > fs/superblock: unregister sb shrinker before ->kill_sb() > > David Rientjes (9): > mm, compaction: avoid isolating pinned pages > mm, compaction: determine isolation mode only once > mm, compaction: ignore pageblock skip when manually invoking > compaction > mm, migration: add destination page freeing callback > mm, compaction: return failed migration target pages back to freelist > mm, compaction: add per-zone migration pfn cache for async compaction > mm, compaction: embed migration mode in compact_control > mm, compaction: terminate async compaction when rescheduling > mm, thp: only collapse hugepages to nodes with affinity for > zone_reclaim_mode > > Davidlohr Bueso (1): > mm: per-thread vma caching > > Fabian Frederick (1): > mm/readahead.c: inline ra_submit > > Han Pingtian (1): > mm: prevent setting of a value less than 0 to min_free_kbytes > > Heesub Shin (1): > mm/compaction: clean up unused code lines > > Hugh Dickins (4): > mm: fix bad rss-counter if remap_file_pages raced migration > mm: fix direct reclaim writeback regression > shmem: fix init_page_accessed use to stop !PageLRU bug > mm/memory.c: use entry = ACCESS_ONCE(*pte) in handle_pte_fault() > > Jens Axboe (1): > mm/filemap.c: avoid always dirtying mapping->flags on O_DIRECT > > Jerome Marchand (2): > mm: make copy_pte_range static again > memcg, vmscan: Fix forced scan of anonymous pages > > Jianyu Zhan (1): > mm/swap.c: clean up *lru_cache_add* functions > > Johannes Weiner (5): > lib: radix-tree: add radix_tree_delete_item() > mm: shmem: save one radix tree lookup when truncating swapped pages > mm: filemap: move radix tree hole searching here > mm + fs: prepare for non-page entries in page cache radix trees > mm: madvise: fix MADV_WILLNEED on shmem swapouts > > Joonsoo Kim (7): > slab: correct pfmemalloc check > mm/compaction: disallow high-order page for migration target > mm/compaction: do not call suitable_migration_target() on every page > mm/compaction: change the timing to check to drop the spinlock > mm/compaction: check pageblock suitability once per pageblock > mm/compaction: clean-up code on success of ballon isolation > vmalloc: use rcu list iterator to reduce vmap_area_lock contention > > KOSAKI Motohiro (2): > mm: get rid of
[RFC] ktest doc: Automated test of linux kernel by using ktest v1.1.3
Hi, I revised ktest documentation. v1.1.2->v1.1.3: Support not only debian/jessy, but also CentOS7 as target system http://www.slideshare.net/satorutakeuchi18/kernel-auto-testbyktest It's not the ktest reference guild, but the quick learning guild of ktest especially focuses on some important features. After reading this document, you'll be able to do the following work automatically. - test all patches of your patchset, and - bisect to find the problematic commit I believe it saves plenty of your time. Feel free to ask me if you have any comments/questions. Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.12 000/142] 3.12.29-stable review
At Fri, 26 Sep 2014 08:45:36 -0700, Guenter Roeck wrote: > > On Fri, Sep 26, 2014 at 11:45:33AM +0200, Jiri Slaby wrote: > > This is the start of the stable review cycle for the 3.12.29 release. > > There are 142 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Tue Sep 30 11:45:24 CEST 2014. > > Anything received after that time might be too late. > > > > Hi Jiri, > > Build results: > total: 135 pass: 135 fail: 0 > > Qemu test results: > total: 21 pass: 21 fail: 0 > > Both obviously look good, however my tree doesn't match your review request. > It includes 245 patches instead of just 142. > > Looks like your tree is a bit ahead of time, so I guess that is ok. > Is there a way for me to avoid this when pulling in your pending changes ? > So far I pull the changes from the stable-3.12-queue branch in your > repository at kernel.org. > > Thanks, > Guenter Plus, this kernel passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.4 00/45] 3.4.104-rc1 review
Hi Li,
At Tue, 23 Sep 2014 10:27:39 +0800,
Zefan Li wrote:
>
> From: Zefan Li
>
> This is the start of the stable review cycle for the 3.4.104 release.
> There are 45 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Thu Sep 25 02:03:31 UTC 2014.
> Anything received after that time might be too late.
This kernel passed my test.
- Test Cases:
- Build this kernel.
- Boot this kernel.
- Build the latest mainline kernel with this kernel.
- Test Tool:
https://github.com/satoru-takeuchi/test-linux-stable
- Test Result (kernel .config, ktest config and test log):
http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz
- Build Environment:
- OS: Debian Jessy x86_64
- CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4
- memory: 8GB
- Test Target Environment:
- Debian Jessy x86_64 (KVM guest on the Build Environment)
- # of vCPU: 2
- memory: 2GB
Thanks,
Satoru
>
> A combined patch relative to 3.4.103 will be posted as an additional
> response to this. A shortlog and diffstat can be found below.
>
> thanks,
>
> Zefan Li
>
>
>
> Aaro Koskinen (1):
> MIPS: OCTEON: make get_system_type() thread-safe
>
> Alan Douglas (1):
> xtensa: fix address checks in dma_{alloc,free}_coherent
>
> Andi Kleen (1):
> slab/mempolicy: always use local policy from interrupt context
>
> Anton Blanchard (1):
> ibmveth: Fix endian issues with rx_no_buffer statistic
>
> Arjun Sreedharan (1):
> pata_scc: propagate return value of scc_wait_after_reset
>
> Benjamin Tissoires (1):
> HID: logitech-dj: prevent false errors to be shown
>
> Brennan Ashton (1):
> USB: option: add VIA Telecom CDS7 chipset device id
>
> Daniel Mack (1):
> ASoC: pxa-ssp: drop SNDRV_PCM_FMTBIT_S24_LE
>
> Dave Chiluk (1):
> stable_kernel_rules: Add pointer to netdev-FAQ for network patches
>
> Fengguang Wu (1):
> unicore32: select generic atomic64_t support
>
> Florian Fainelli (1):
> MIPS: perf: Fix build error caused by unused
> counters_per_cpu_to_total()
>
> Greg KH (1):
> USB: serial: pl2303: add device id for ztek device
>
> Guan Xuetao (2):
> UniCore32-bugfix: Remove definitions in asm/bug.h to solve difference
> between native and cross compiler
> UniCore32-bugfix: fix mismatch return value of __xchg_bad_pointer
>
> Hans de Goede (1):
> xhci: Treat not finding the event_seg on COMP_STOP the same as
> COMP_STOP_INVAL
>
> Huang Rui (1):
> usb: xhci: amd chipset also needs short TX quirk
>
> James Forshaw (1):
> USB: whiteheat: Added bounds checking for bulk command response
>
> Jan Kara (2):
> isofs: Fix unbounded recursion when processing relocated directories
> ext2: Fix fs corruption in ext2_get_xip_mem()
>
> Jaša Bartelj (1):
> USB: ftdi_sio: Added PID for new ekey device
>
> Jiri Kosina (4):
> HID: fix a couple of off-by-ones
> HID: logitech: perform bounds checking on device_id early enough
> HID: magicmouse: sanity check report size in raw_event() callback
> HID: picolcd: sanity check report size in raw_event() callback
>
> Joerg Roedel (1):
> iommu/amd: Fix cleanup_domain for mass device removal
>
> Johan Hovold (3):
> USB: ftdi_sio: add Basic Micro ATOM Nano USB2Serial PID
> USB: serial: fix potential stack buffer overflow
> USB: serial: fix potential heap buffer overflow
>
> Mark Einon (1):
> staging: et131x: Fix errors caused by phydev->addr accesses before
> initialisation
>
> Mark Rutland (2):
> ARM: 8128/1: abort: don't clear the exclusive monitors
> ARM: 8129/1: errata: work around Cortex-A15 erratum 830321 using
> dummy strex
>
> Max Filippov (3):
> xtensa: replace IOCTL code definitions with constants
> xtensa: fix TLBTEMP_BASE_2 region handling in fast_second_level_miss
> xtensa: fix a6 and a7 handling in fast_syscall_xtensa
>
> Michael Cree (2):
> alpha: Fix fall-out from disintegrating asm/system.h
> alpha: add io{read,write}{16,32}be functions
>
> Michael S. Tsirkin (1):
> kvm: iommu: fix the third parameter of kvm_iommu_put_pages
> (CVE-2014-3601)
>
> NeilBrown (1):
> md/raid6: avoid data corruption during recovery of double-degraded
> RAID6
>
> Paul Gortmaker (1):
> 8250_pci: fix warnings in backport of Broadcom TruManage support
>
> Pavel Shilovsky (1):
> CIFS: Fix wrong directory attributes after rename
>
> Ralf Baechle (1):
> MIPS: Fix accessing to per-cpu data when flushing the cache
>
> Stefan Kristiansson
Re: [PATCH 3.16 000/158] 3.16.3-stable review
At Mon, 15 Sep 2014 12:23:59 -0700, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.16.3 release. > There are 158 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed Sep 17 19:25:26 UTC 2014. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.16.3-rc1.gz > and the diffstat can be found below. All 3.10.55-rc1, 3.14.19-rc1, and 3.6.3-rc1 passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru > > thanks, > > greg k-h > > - > Pseudo-Shortlog of commits: > > Greg Kroah-Hartman > Linux 3.16.3-rc1 > > David Howells > KEYS: Fix termination condition in assoc array garbage collection > > David Howells > KEYS: Fix use-after-free in assoc_array_gc() > > Pavel Shilovsky > CIFS: Fix SMB2 readdir error handling > > Linus Torvalds > vfs: fix bad hashing of dentries > > Mario Kleiner > drm/nouveau: Bump version from 1.1.1 to 1.1.2 > > Mario Kleiner > drm/nouveau: Dis/Enable vblank irqs during suspend/resume. > > Bart Van Assche > IB/srp: Fix deadlock between host removal and multipathd > > Jeff Moyer > dm table: propagate QUEUE_FLAG_NO_SG_MERGE > > Tejun Heo > blkcg: don't call into policy draining if root_blkg is already gone > > Roger Quadros > mtd: nand: omap: Fix 1-bit Hamming code scheme, omap_calculate_ecc() > > Kevin Hao > mtd/ftl: fix the double free of the buffers allocated in build_maps() > > Pavel Shilovsky > CIFS: Fix wrong restart readdir for SMB1 > > Pavel Shilovsky > CIFS: Fix wrong filename length for SMB2 > > Pavel Shilovsky > CIFS: Fix directory rename error > > Pavel Shilovsky > CIFS: Fix wrong directory attributes after rename > > Steve French > CIFS: Possible null ptr deref in SMB2_tcon > > Pavel Shilovsky > CIFS: Fix async reading on reconnects > > Pavel Shilovsky > CIFS: Fix STATUS_CANNOT_DELETE error mapping for SMB2 > > Ilya Dryomov > libceph: do not hard code max auth ticket len > > Ilya Dryomov > libceph: add process_one_ticket() helper > > Sage Weil > libceph: gracefully handle large reply messages from the mon > > Ilya Dryomov > libceph: set last_piece in ceph_msg_data_pages_cursor_init() correctly > > Chris Mason > xfs: don't zero partial page cache pages during O_DIRECT write > > Dave Chinner > xfs: don't zero partial page cache pages during O_DIRECT writes > > Dave Chinner > xfs: don't dirty buffers beyond EOF > > Dave Chinner > xfs: quotacheck leaves dquot buffers without verifiers > > Dave Chinner > xfs: ensure verifiers are attached to recovered buffers > > Doug Ledford > RDMA/uapi: Include socket.h in rdma_user_cm.h > > Steve Wise > RDMA/iwcm: Use a default listen backlog if needed > > NeilBrown > md/raid10: Fix memory leak when raid10 reshape completes. > > NeilBrown > md/raid10: fix memory leak when reshaping a RAID10. > > NeilBrown > md/raid6: avoid data corruption during recovery of double-degraded RAID6 > > NeilBrown > md/raid5: avoid livelock caused by non-aligned writes. > > NeilBrown > md/raid1,raid10: always abort recover on write error. > > Al Viro > fix copy_tree() regression > > Ilya Dryomov > rbd: rework rbd_request_fn() > > Al Viro > __generic_file_write_iter(): fix handling of sync error after DIO > > Vignesh Raman > Bluetooth: Avoid use of session socket after the session gets freed > > Johan Hedberg > Bluetooth: Fix using uninitialized variable when pairing > > Vladimir Davydov > Bluetooth: never linger on process exit > > Johan Hedberg > Bluetooth: Fix tracking local SSP authentication requirement > > Marcel Holtmann > B
Re: [PATCH 3.2 000/131] 3.2.63-rc1 review
At Thu, 11 Sep 2014 06:30:06 -0700, Guenter Roeck wrote: > > On 09/11/2014 05:32 AM, Ben Hutchings wrote: > > This is the start of the stable review cycle for the 3.2.63 release. > > There are 131 patches in this series, which will be posted as responses > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Sat Sep 13 12:32:13 UTC 2014. > > Anything received after that time might be too late. > > > > Build results: > total: 111 pass: 106 fail: 5 > Failed builds: > microblaze:mmu_defconfig > microblaze:nommu_defconfig > mips:allmodconfig > xtensa:defconfig > xtensa:allmodconfig > > Qemu test results: > total: 18 pass: 17 fail: 1 > Failed tests: > microblaze:microblaze_defconfig > > Results are as expected and an improvement over previous releases, > where sparc64:allmodconfig used to fail as well. The failing qemu > test was added to the list of tests only recently and is a known > problem. > > Guenter Plus, this kernel passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ktest: add ability to skip during BISECT_MANUAL
Hi Chris,
Sorry for late reply.
2014-08-28 3:26 GMT+09:00 Chris J Arges :
> When doing a manual bisect, a build can fail or a test can be inconclusive.
> In these cases it would be helpful to be able to skip the test entirely.
>
> Signed-off-by: Chris J Arges
It look good to me.
Reviewed-by: Satoru Takeuchi
Thanks,
Satoru
>
> ---
> tools/testing/ktest/ktest.pl | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/tools/testing/ktest/ktest.pl b/tools/testing/ktest/ktest.pl
> index 55ab700..72010f4 100755
> --- a/tools/testing/ktest/ktest.pl
> +++ b/tools/testing/ktest/ktest.pl
> @@ -2336,15 +2336,17 @@ sub success {
>
> sub answer_bisect {
> for (;;) {
> - doprint "Pass or fail? [p/f]";
> + doprint "Pass, fail, or skip? [p/f/s]";
> my $ans = ;
> chomp $ans;
> if ($ans eq "p" || $ans eq "P") {
> return 1;
> } elsif ($ans eq "f" || $ans eq "F") {
> return 0;
> + } elsif ($ans eq "s" || $ans eq "S") {
> + return -1;
> } else {
> - print "Please answer 'P' or 'F'\n";
> + print "Please answer 'p', 'f', or 's'\n";
> }
> }
> }
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.16 00/17] 3.16.1-stable review
At Sat, 9 Aug 2014 08:49:16 -0700, Greg Kroah-Hartman wrote: > > On Sat, Aug 09, 2014 at 08:43:01AM -0600, Shuah Khan wrote: > > On 08/08/2014 03:35 PM, Greg Kroah-Hartman wrote: > > >This is the start of the stable review cycle for the 3.16.1 release. > > >There are 17 patches in this series, all will be posted as a response > > >to this one. If anyone has any issues with these being applied, please > > >let me know. > > > > > >Responses should be made by Sun Aug 10 21:34:49 UTC 2014. > > >Anything received after that time might be too late. > > > > > >The whole patch series can be found in one patch at: > > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.16.1-rc1.gz > > >and the diffstat can be found below. > > > > > >thanks, > > > > > >greg k-h > > > > > > > Compiled and booted on my test system. No dmesg regressions. > > Thanks for testing all of these and letting me know. > > greg k-h All 3.16.1-rc1, 3.15.10-rc1, 3.14.17-rc1, 3.10.53-rc1, and 3.4.103-rc1 passed my test. # Five stable-rc kernels! It's the largest number I've ever tested at a one time :-) - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.2 00/94] 3.2.62-rc1 review
At Mon, 4 Aug 2014 10:55:44 -0700, Guenter Roeck wrote: > > On Mon, Aug 04, 2014 at 05:48:31PM +0100, Ben Hutchings wrote: > > This is the start of the stable review cycle for the 3.2.62 release. > > There are 94 patches in this series, which will be posted as responses > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Wed Aug 06 17:00:00 UTC 2014. > > Anything received after that time might be too late. > > > Build results: > total: 111 pass: 105 fail: 6 > Failed builds: > microblaze:mmu_defconfig > microblaze:nommu_defconfig > mips:allmodconfig > sparc64:allmodconfig > xtensa:defconfig > xtensa:allmodconfig > > Qemu tests all passed. > > This is a significant improvement over the previous versions, where we used > to see up to 10 build failures. The previously failing builds for unicore32 > and score now pass, as well as alpha:allmodconfig. > > Note that I rearranged arm builds to improve test coverage. > > Details are available at http://server.roeck-us.net:8010/builders. > > Guenter This kernel passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.15 00/42] 3.15.9-stable review
At Tue, 5 Aug 2014 16:27:04 -0700, Greg Kroah-Hartman wrote: > > On Tue, Aug 05, 2014 at 05:07:00PM -0600, Shuah Khan wrote: > > On 08/05/2014 12:13 PM, Greg Kroah-Hartman wrote: > > >This is the start of the stable review cycle for the 3.15.9 release. > > >There are 42 patches in this series, all will be posted as a response > > >to this one. If anyone has any issues with these being applied, please > > >let me know. > > > > > >Responses should be made by Thu Aug 7 18:13:05 UTC 2014. > > >Anything received after that time might be too late. > > > > > >The whole patch series can be found in one patch at: > > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.15.9-rc1.gz > > >and the diffstat can be found below. > > > > > >thanks, > > > > > >greg k-h > > > > > > > Compiled and booted on my test system. No dmesg regressions > > compared to previous 3.15.8 > > Thanks for testing all of these and letting me know. > > greg k-h All 3.15.9-rc1, 3.14.16-rc1, 3.10.52-rc1, and 3.4.102-rc1 passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.12 00/94] 3.12.26-stable review
At Wed, 30 Jul 2014 12:22:27 -0700, Guenter Roeck wrote: > > On Wed, Jul 30, 2014 at 02:15:03PM +0200, Jiri Slaby wrote: > > This is the start of the stable review cycle for the 3.12.26 release. > > There are 94 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Fri Aug 1 14:11:10 CEST 2014. > > Anything received after that time might be too late. > > > Build results: > total: 139 pass: 139 fail: 0 > > Qemu tests all passed. > > Details are available at http://server.roeck-us.net:8010/builders. > > Guenter This kernel passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.15 00/37] 3.15.8-stable review
At Tue, 29 Jul 2014 18:48:36 -0700, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.15.8 release. > There are 37 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Fri Aug 1 01:48:13 UTC 2014. > Anything received after that time might be too late. All 3.15.8-rc1, 3.14.15-rc1, 3.10.51-rc1, and 3.4.101-rc1 passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.15.8-rc1.gz > and the diffstat can be found below. > > thanks, > > greg k-h > > - > Pseudo-Shortlog of commits: > > Greg Kroah-Hartman > Linux 3.15.8-rc1 > > Guenter Roeck > platform_get_irq: Revert to platform_get_resource if of_irq_get fails > > Johannes Berg > nl80211: move set_qos_map command into split state > > Konstantin Khlebnikov > mm: do not call do_fault_around for non-linear fault > > Amit Shah > hwrng: virtio - ensure reads happen after successful probe > > Linus Torvalds > Fix gcc-4.9.0 miscompilation of load_balance() in scheduler > > Naoya Horiguchi > mm: hugetlb: fix copy_hugetlb_page_range() > > Jerome Glisse > drm/radeon: fix cut and paste issue for hawaii. > > Christian König > drm/radeon: fix irq ring buffer overflow handling > > Sven Wegener > x86_32, entry: Store badsys error code in %eax > > Vasily Averin > fs: umount on symlink leaks mnt count > > Randy Dunlap > parport: fix menu breakage > > Guenter Roeck > hwmon: (smsc47m192) Fix temperature limit and vrm write operations > > John David Anglin > parisc: Remove SA_RESTORER define > > Maxime COQUELIN > pinctrl: st: Fix irqmux handler > > Andrew Gallagher > fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT > > Miklos Szeredi > fuse: s_time_gran fix > > Silesh C V > coredump: fix the setting of PF_DUMPCORE > > Dmitry Torokhov > Input: fix defuzzing logic > > Hans de Goede > Input: synaptics - add min/max quirk for pnp-id LEN2002 (Edge E531) > > Mikulas Patocka > slab_common: fix the check for duplicate slab names > > Tyrel Datwyler > powerpc/pseries: dynamically added OF nodes need to call of_node_init > > Minchan Kim > zram: avoid lockdep splat by revalidate_disk > > Tony Luck > tracing: Fix wraparound problems in "uptime" trace clock > > Tejun Heo > blkcg: don't call into policy draining if root_blkg is already gone > > Romain Degez > ahci: add support for the Promise FastTrak TX8660 SATA HBA (ahci mode) > > Martin Schwidefsky > s390/ptrace: fix PSW mask check > > Tejun Heo > libata: introduce ata_host->n_tags to avoid oops on SAS controllers > > Kevin Hao > libata: support the ata host which implements a queue depth less than 32 > > Christoph Hellwig > block: don't assume last put of shared tags is for the host > > Mikulas Patocka > block: provide compat ioctl for BLKZEROOUT > > Max Filippov > xtensa: fix sysmem reservation at the end of existing block > > Christoph Hellwig > nfs: only show Posix ACLs in listxattr if actually present > > Antti Palosaari > media: tda10071: force modulation to QPSK on DVB-S > > Hans Verkuil > media: hdpvr: fix two audio bugs > > Antti Palosaari > media: af9035: override tuner id when bad value set into eeprom > > Rickard Strandqvist > media: media: v4l2-core: v4l2-dv-timings.c: Cleaning up code wrong value > used in aspect ratio > > Arnd Bergmann > media: staging: tighten omap4iss dependencies > > > - > > Diffstat: > > Makefile | 6 +++-- > arch/parisc/include/uapi/asm/signal.h | 2 -- > arch/powerpc/platforms/pseries/dlpar.c| 1 + > arch/powerpc/platforms/pseries/reconfig.c | 1 +
Re: [PATCH 3.15 000/109] 3.15.7-stable review
At Sat, 26 Jul 2014 12:01:22 -0700, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.15.7 release. > There are 109 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Mon Jul 28 19:02:07 UTC 2014. > Anything received after that time might be too late. All 3.15.7-rc1, 3.14.14-rc1, 3.10.50-rc1, and 3.4.100-rc1 passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.15.7-rc1.gz > and the diffstat can be found below. > > thanks, > > greg k-h > > - > Pseudo-Shortlog of commits: > > Greg Kroah-Hartman > Linux 3.15.7-rc1 > > Anton Kolesov > ARC: Implement ptrace(PTRACE_GET_THREAD_AREA) > > Linus Torvalds > Don't trigger congestion wait on dirty-but-not-writeout pages > > Emmanuel Grumbach > iwlwifi: mvm: disable CTS to Self > > Marek Vasut > ARM: dts: imx: Add alias for ethernet controller > > Sebastian Andrzej Siewior > gpio: dwapb: drop irq_setup_generic_chip() > > Benjamin LaHaise > aio: protect reqs_available updates from changes in interrupt handlers > > Or Gerlitz > IB/mlx5: Enable "block multicast loopback" for kernel consumers > > Michael Brown > x86/efi: Include a .bss section within the PE/COFF headers > > Mateusz Guzik > sched: Fix possible divide by zero in avg_atom() calculation > > Peter Zijlstra > locking/mutex: Disable optimistic spinning on some architectures > > Takashi Iwai > PM / sleep: Fix request_firmware() error at resume > > Steve Wise > RDMA/cxgb4: Initialize the device status page > > Mike Snitzer > dm cache metadata: do not allow the data block size to change > > Mike Snitzer > dm thin metadata: do not allow the data block size to change > > Ted Juan > mtd: devices: elm: fix elm_context_save() and elm_context_restore() > functions > > Hannes Frederic Sowa > random: check for increase of entropy_count because of signed conversion > > Viresh Kumar > cpufreq: move policy kobj to policy->cpu at resume > > Peter Zijlstra > x86, tsc: Fix cpufreq lockup > > Amit Shah > hwrng: fetch randomness only after device init > > John Stultz > alarmtimer: Fix bug where relative alarm timers were treated as absolute > > Dave Airlie > Revert "drm/i915: reverse dp link param selection, prefer fast over wide > again" > > Alex Deucher > drm/radeon: avoid leaking edid data > > Jason Wang > drm/qxl: return IRQ_NONE if it was not our irq > > Alex Deucher > drm/radeon: set default bl level to something reasonable > > Tomasz Figa > irqchip: gic: Fix core ID calculation when topology is read from DT > > Suravee Suthikulpanit > irqchip: gic: Add binding probe for ARM GIC400 > > Matthias Brugger > irqchip: gic: Add support for cortex a7 compatible string > > Martin Lau > ring-buffer: Fix polling on trace_pipe > > Amitkumar Karwar > mwifiex: fix Tx timeout issue > > HATAYAMA Daisuke > perf/x86/intel: ignore CondChgd bit to avoid false NMI handling > > Jiri Olsa > perf: Do not allow optimized switch for non-cloned events > > Zoltan Kiss > xen-netback: Fix pointer incrementation to avoid incorrect logging > > Zoltan Kiss > xen-netback: Fix releasing header slot on error path > > Zoltan Kiss > xen-netback: Fix releasing frag_list skbs in error path > > Zoltan Kiss > xen-netback: Fix handling frag_list on grant op error path > > Eric Dumazet > ipv4: fix buffer overflow in ip_options_compile() > > Ben Hutchings > dns_resolver: Null-terminate the right string > > Manuel Schölling > dns_resolver: assure that dns_query() result is null-terminated > > Christoph Schulz > net: ppp: don't call sk_chk_filter twice
Re: [PATCH 3.12 000/170] 3.12.25-stable review
At Fri, 18 Jul 2014 06:47:32 -0700, Guenter Roeck wrote: > > On 07/18/2014 05:16 AM, Jiri Slaby wrote: > > On 07/18/2014 02:12 PM, Jiri Slaby wrote: > >> This is the start of the stable review cycle for the 3.12.25 release. > >> There are 170 patches in this series, all will be posted as a response > >> to this one. If anyone has any issues with these being applied, please > >> let me know. > >> > >> Responses should be made by Sun Jul 20 12:11:21 2014 > > > > Oh, this should have been two *workdays*, i.e. the deadline is Jul 22. > > > > Build results: > total: 137 pass: 137 fail: 0 > > Qemu tests all passed. > > Details are available at http://server.roeck-us.net:8010/builders. > > Guenter > Plus, it passed my test too. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.15 00/84] 3.15.6-stable review
At Wed, 16 Jul 2014 18:50:45 -0700, Greg Kroah-Hartman wrote: > > On Wed, Jul 16, 2014 at 05:12:28PM -0700, Guenter Roeck wrote: > > On 07/16/2014 04:09 PM, Greg Kroah-Hartman wrote: > > >On Tue, Jul 15, 2014 at 04:16:57PM -0700, Greg Kroah-Hartman wrote: > > >>This is the start of the stable review cycle for the 3.15.6 release. > > >>There are 84 patches in this series, all will be posted as a response > > >>to this one. If anyone has any issues with these being applied, please > > >>let me know. > > >> > > >>Responses should be made by Thu Jul 17 23:17:00 UTC 2014. > > >>Anything received after that time might be too late. > > >> > > >>The whole patch series can be found in one patch at: > > >> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.15.6-rc1.gz > > >>and the diffstat can be found below. > > > > > >Due to some problems with Xen, I've removed a bunch of patches from this > > >series (and the 3.4, 3.10, and 3.14 series) and done a -rc2 release with > > >the updated set: > > > > > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.15.6-rc2.gz > > > > > > > Build and qemu test for all releases is still fine. > > Great, thanks for letting me know. > > greg k-h All -rc2es passed my test too. Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.15 00/84] 3.15.6-stable review
At Tue, 15 Jul 2014 21:28:16 -0700, Guenter Roeck wrote: > > On 07/15/2014 04:16 PM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.15.6 release. > > There are 84 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Thu Jul 17 23:17:00 UTC 2014. > > Anything received after that time might be too late. > > > > Build results: > total: 139 pass: 139 fail: 0 > > Qemu tests all passed. > > Another set of perfect results. > > Details are available at http://server.roeck-us.net:8010/builders. All 3.15.6-rc1, 3.14.13-rc1, 3.10.49-rc1, and 3.4.99-rc1 passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. # "selftests" is not added to this list yet. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Btrfs: use BUG_ON
Hi Himangi,
(2014/07/09 7:21), Himangi Saraogi wrote:
Use BUG_ON(x) rather than if(x) BUG();
The semantic patch that fixes this problem is as follows:
//
@@ identifier x; @@
-if (x) BUG();
+BUG_ON(x);
//
Strictly speaking, BUG_ON() is "if (unlikely(x)) BUG".
Anyway, I consider that put this condition in unlikely()
in this case is good.
BTW, there are many "if BUG()" case under fs/btrfs.
How about fix all of them?
===
$ grep -rnH -B 1 "BUG()" fs/btrfs | grep -A 1 'if.*('
fs/btrfs/inode.c-6318- } else if (create && PageUptodate(page)) {
fs/btrfs/inode.c:6319: BUG();
--
fs/btrfs/volumes.c-2626-else if (ret)
fs/btrfs/volumes.c:2627:BUG(); # <- your patch
fixes it.
--
fs/btrfs/volumes.c-3092-if (ret == 0)
fs/btrfs/volumes.c:3093:BUG(); /* FIXME break ? */
--
fs/btrfs/raid56.c-2048- if (rbio->faila == -1) {
fs/btrfs/raid56.c:2049: BUG();
===
Thanks,
Satoru
Signed-off-by: Himangi Saraogi
Acked-by: Julia Lawall
---
fs/btrfs/volumes.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 6104676..63e746e 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -2623,8 +2623,8 @@ again:
found_key.offset);
if (ret == -ENOSPC)
failed++;
- else if (ret)
- BUG();
+ else
+ BUG_ON(ret);
}
if (found_key.offset == 0)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.2 000/125] 3.2.61-rc1 review
At Tue, 08 Jul 2014 18:27:37 -0700, Guenter Roeck wrote: > > On 07/08/2014 12:01 PM, Ben Hutchings wrote: > > This is the start of the stable review cycle for the 3.2.61 release. > > There are 125 patches in this series, which will be posted as responses > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Thu Jul 10 19:01:49 UTC 2014. > > Anything received after that time might be too late. > > > > Build results: > total: 109 pass: 71 fail: 38 > Failed builds: > alpha:allmodconfig > arm:defconfig > arm:imx_v4_v5_defconfig > arm:mxs_defconfig > arm:dove_defconfig > arm:kirkwood_defconfig > arm:omap2plus_defconfig > arm:tegra_defconfig > arm:u8500_defconfig > arm:at91sam9rl_defconfig > arm:pxa910_defconfig > arm:mackerel_defconfig > arm:ixp4xx_defconfig > arm:vexpress_defconfig > arm:msm_defconfig > arm:at91rm9200_defconfig > arm:at91sam9263_defconfig > arm:at91sam9g45_defconfig > arm:assabet_defconfig > i386:defconfig > i386:allyesconfig > i386:allmodconfig > m32r:defconfig > microblaze:mmu_defconfig > microblaze:nommu_defconfig > mips:defconfig > mips:allmodconfig > mips:bcm47xx_defconfig > mips:bcm63xx_defconfig > mips:ar7_defconfig > mips:fuloong2e_defconfig > mips:malta_defconfig > score:defconfig > sparc64:allmodconfig > um:defconfig > unicore32:defconfig > xtensa:defconfig > xtensa:allmodconfig > > Qemu images fail to build for mips, mips64, and x86. > > Build error seems to be always the same. > > lib/nlattr.c: In function 'nla_parse': > lib/nlattr.c:201:3: error: dereferencing pointer to incomplete type > make[1]: *** [lib/nlattr.o] Error 1 > > Culprit is bfc5184b69 (netlink: rate-limit leftover bytes warning > and print process name). In 3.2, it is necessary to include > explicitly to get the definition of 'struct task_struct'. > > Details are available at http://server.roeck-us.net:8010/builders. > > Guenter > This kernel passed my test. I didn't hit the problem which Guenter reported since I only test x86_64 arch. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.15 000/122] 3.15.5-stable review
At Tue, 08 Jul 2014 06:26:21 -0700, Guenter Roeck wrote: > > On 07/07/2014 04:56 PM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.15.5 release. > > There are 122 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Wed Jul 9 23:57:10 UTC 2014. > > Anything received after that time might be too late. > > > > > Build results: > total: 139 pass: 136 fail: 3 > Failed builds: > powerpc:allmodconfig (binutils 2.23) > powerpc:allmodconfig (binutils 2.24) > unicore32:defconfig > > Qemu tests all passed. > > Results are as expected. > > Details are available at http://server.roeck-us.net:8010/builders. > > For the unicore32 build to pass in this release, the following > additional patches would be needed. > > 73fa540618 drivers/rtc/rtc-puv3.c: remove "&dev->" for typo issue > c863810cef drivers/rtc/rtc-puv3.c: use dev_dbg() instead of dev_debug() for > typo issue > > A workaround patch to address the powerpc build failures is pending. > I'll send you a note after it is available if Ben doesn't Cc: stable. 3.15.5-rc1, 3.14.12-rc1, 3.10.48-rc1, and 3.4.98-rc1 passed my test. Build errors in 3.14.11 and 3.10.11-rc1 disappeared. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru > > Guenter > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.14 00/59] 3.14.11-stable review
At Sat, 5 Jul 2014 12:10:58 -0700, Greg Kroah-Hartman wrote: > > On Sat, Jul 05, 2014 at 02:56:55PM +0200, Takashi Iwai wrote: > > At Sat, 05 Jul 2014 18:21:04 +0900, > > Satoru Takeuchi wrote: > > > > > > Hi Greg, > > > > > > Add Takashi Iwai to this thread. > > > > > > At Sat, 05 Jul 2014 16:00:41 +0900, > > > Satoru Takeuchi wrote: > > > > > > > > At Fri, 04 Jul 2014 22:45:42 -0700, > > > > Guenter Roeck wrote: > > > > > > > > > > On 07/04/2014 03:18 PM, Greg Kroah-Hartman wrote: > > > > > > This is the start of the stable review cycle for the 3.14.11 > > > > > > release. > > > > > > There are 59 patches in this series, all will be posted as a > > > > > > response > > > > > > to this one. If anyone has any issues with these being applied, > > > > > > please > > > > > > let me know. > > > > > > > > > > > > Responses should be made by Sun Jul 6 22:15:27 UTC 2014. > > > > > > Anything received after that time might be too late. > > > > > > > > > > > > > > > > Build results: > > > > > total: 144 pass: 130 skipped: 4 fail: 10 > > > > > Failed builds: > > > > > alpha:allmodconfig > > > > > i386:allyesconfig > > > > > i386:allmodconfig > > > > > powerpc:allmodconfig (binutils 2.23) > > > > > powerpc:allmodconfig (binutils 2.24) > > > > > sparc64:allmodconfig > > > > > unicore32:defconfig > > > > > x86_64:allyesconfig > > > > > x86_64:allmodconfig > > > > > xtensa:allmodconfig > > > > > > > > > > Qemu test for x86 failed. > > > > > > > > > > Build error is the same as seen with 3.14. > > > > > > > > > > sound/pci/hda/patch_sigmatel.c: In function 'stac92hd95_fixup_hp_led': > > > > > sound/pci/hda/patch_sigmatel.c:4143:3: error: implicit declaration of > > > > > function 'codec_dbg' [-Werror=implicit-function-declaration] > > > > > > > > This kernel failed to build with the following error. Probably the root > > > > cause is the same as Guenter. I'm now bisecting to find the problematic > > > > patch... > > > > > > The following patch caused the boot failure of both this kernel and > > > 3.10.47-rc1. > > > > > > alsa-hda-adjust-speaker-hpf-and-add-led-support-for-hp-spectre-13.patch: > > > === > > > From 8b3dfdaf0c25a584cb31d04d2574115cf2d422ab Mon Sep 17 00:00:00 2001 > > > From: Takashi Iwai > > > Date: Tue, 24 Jun 2014 13:55:25 +0200 > > > Subject: ALSA: hda - Adjust speaker HPF and add LED support for HP > > > Spectre 13 > > > > > > From: Takashi Iwai > > > > > > commit 8b3dfdaf0c25a584cb31d04d2574115cf2d422ab upstream. > > > > > > HP Spectre 13 has the IDT 92HD95 codec, and BIOS seems to set the > > > default high-pass filter in some "safer" range, which results in the > > > very soft tone from the built-in speakers in contrast to Windows. > > > Also, the mute LED control is missing, since 92HD95 codec still has no > > > HP-specific fixups for GPIO setups. > > > > > > This patch adds these missing features: the HPF is adjusted by the > > > vendor-specific verb, and the LED is set up from a DMI string (but > > > with the default polarity = 0 assumption due to the incomplete BIOS on > > > the given machine). > > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=74841 > > > Signed-off-by: Takashi Iwai > > > Signed-off-by: Greg Kroah-Hartman > > > ... > > > === > > > > > > This patch uses codec_dbg(), however, this macro is intrdocuded by the > > > following patch and it's not applied to these stable-tree yet. > > > > > > === > > > ommit 4e76a8833fac8dc1735aa5be7d1b3c92c65e209e > > > Author: Takashi Iwai > > > Date: Tue
Re: [PATCH 3.14 00/59] 3.14.11-stable review
Hi Greg, Add Takashi Iwai to this thread. At Sat, 05 Jul 2014 16:00:41 +0900, Satoru Takeuchi wrote: > > At Fri, 04 Jul 2014 22:45:42 -0700, > Guenter Roeck wrote: > > > > On 07/04/2014 03:18 PM, Greg Kroah-Hartman wrote: > > > This is the start of the stable review cycle for the 3.14.11 release. > > > There are 59 patches in this series, all will be posted as a response > > > to this one. If anyone has any issues with these being applied, please > > > let me know. > > > > > > Responses should be made by Sun Jul 6 22:15:27 UTC 2014. > > > Anything received after that time might be too late. > > > > > > > Build results: > > total: 144 pass: 130 skipped: 4 fail: 10 > > Failed builds: > > alpha:allmodconfig > > i386:allyesconfig > > i386:allmodconfig > > powerpc:allmodconfig (binutils 2.23) > > powerpc:allmodconfig (binutils 2.24) > > sparc64:allmodconfig > > unicore32:defconfig > > x86_64:allyesconfig > > x86_64:allmodconfig > > xtensa:allmodconfig > > > > Qemu test for x86 failed. > > > > Build error is the same as seen with 3.14. > > > > sound/pci/hda/patch_sigmatel.c: In function 'stac92hd95_fixup_hp_led': > > sound/pci/hda/patch_sigmatel.c:4143:3: error: implicit declaration of > > function 'codec_dbg' [-Werror=implicit-function-declaration] > > This kernel failed to build with the following error. Probably the root > cause is the same as Guenter. I'm now bisecting to find the problematic > patch... The following patch caused the boot failure of both this kernel and 3.10.47-rc1. alsa-hda-adjust-speaker-hpf-and-add-led-support-for-hp-spectre-13.patch: === >From 8b3dfdaf0c25a584cb31d04d2574115cf2d422ab Mon Sep 17 00:00:00 2001 From: Takashi Iwai Date: Tue, 24 Jun 2014 13:55:25 +0200 Subject: ALSA: hda - Adjust speaker HPF and add LED support for HP Spectre 13 From: Takashi Iwai commit 8b3dfdaf0c25a584cb31d04d2574115cf2d422ab upstream. HP Spectre 13 has the IDT 92HD95 codec, and BIOS seems to set the default high-pass filter in some "safer" range, which results in the very soft tone from the built-in speakers in contrast to Windows. Also, the mute LED control is missing, since 92HD95 codec still has no HP-specific fixups for GPIO setups. This patch adds these missing features: the HPF is adjusted by the vendor-specific verb, and the LED is set up from a DMI string (but with the default polarity = 0 assumption due to the incomplete BIOS on the given machine). Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=74841 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman ... === This patch uses codec_dbg(), however, this macro is intrdocuded by the following patch and it's not applied to these stable-tree yet. === ommit 4e76a8833fac8dc1735aa5be7d1b3c92c65e209e Author: Takashi Iwai Date: Tue Feb 25 12:21:03 2014 +0100 ALSA: hda - Replace with standard printk Use dev_err() and co for messages from HD-audio controller and codec drivers. The codec drivers are mostly bound with codec objects, so some helper macros, codec_err(), codec_info(), etc, are provided. They merely wrap the corresponding dev_xxx(). There are a few places still calling snd_printk() and its variants as they are called without the codec or device context. Signed-off-by: Takashi Iwai ... === Unfortunately I failed to apply this patch to 3.14.11-rc1 with the following error log. === $ git apply ~/src/test-linux-stable/extra_patch.txt error: patch failed: sound/pci/hda/hda_intel.c:897 error: sound/pci/hda/hda_intel.c: patch does not apply error: sound/pci/hda/hda_sysfs.c: No such file or directory === I'm not sure whether we should drop this patch or should apply extra patches to remove this build failure. Any idea? Thanks, Satoru > > === > ... > home/sat/src/test-linux-stable/linux-stable/sound/pci/hda/patch_sigmatel.c:4143:3: > error: implicit declaration of function ‘codec_dbg’ > [-Werror=implicit-function-declaration] >codec_dbg(codec, "mute LED gpio %d polarity %d\n", >^ > LD [M] sound/pci/echoaudio/snd-indigoio.o > LD [M] sound/pci/echoaudio/snd-
Re: [PATCH 3.10 00/46] 3.10.47-stable review
At Fri, 04 Jul 2014 22:43:40 -0700, Guenter Roeck wrote: > > On 07/04/2014 03:19 PM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.10.47 release. > > There are 46 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Sun Jul 6 22:15:52 UTC 2014. > > Anything received after that time might be too late. > > > > Build results: > total: 144 pass: 125 skipped: 6 fail: 13 > Failed builds: > alpha:allmodconfig > i386:defconfig > i386:allyesconfig > i386:allmodconfig > powerpc:allmodconfig (binutils 2.23) > powerpc:allmodconfig (binutils 2.24) > score:defconfig > sparc64:allmodconfig > unicore32:defconfig > x86_64:defconfig > x86_64:allyesconfig > x86_64:allmodconfig > xtensa:allmodconfig > > Qemu test for x86 failed with a build error. > > This is not as expected. New build error is always the same as far as I can > see: > > sound/pci/hda/patch_sigmatel.c: In function 'stac92hd95_fixup_hp_led': > sound/pci/hda/patch_sigmatel.c:3578:3: error: implicit declaration of > function 'codec_dbg' [-Werror=implicit-function-declaration] Failed with the following log. It's also the same as Guenter's problem. Probably both 3.14.11-rc1 and 3.10.11-rc1 hit the same problem. === ... /home/sat/src/test-linux-stable/linux-stable/sound/pci/hda/patch_sigmatel.c: In function ‘stac92hd95_fixup_hp_led’: /home/sat/src/test-linux-stable/linux-stable/sound/pci/hda/patch_sigmatel.c:3578:3: error: implicit declaration of function ‘codec_dbg’ [-Werror=implicit-function-declaration] codec_dbg(codec, "mute LED gpio %d polarity %d\n", ^ ... CC net/ipv6/icmp.o cc1: some warnings being treated as errors /home/sat/src/test-linux-stable/linux-stable/scripts/Makefile.build:308: recipe for target 'sound/pci/hda/patch_sigmatel.o' failed make[4]: *** [sound/pci/hda/patch_sigmatel.o] Error 1 /home/sat/src/test-linux-stable/linux-stable/scripts/Makefile.build:455: recipe for target 'sound/pci/hda' failed make[3]: *** [sound/pci/hda] Error 2 /home/sat/src/test-linux-stable/linux-stable/scripts/Makefile.build:455: recipe for target 'sound/pci' failed make[2]: *** [sound/pci] Error 2 /home/sat/src/test-linux-stable/linux-stable/Makefile:795: recipe for target 'sound' failed make[1]: *** [sound] Error 2 ... LD net/built-in.o Makefile:130: recipe for target 'sub-make' failed make: *** [sub-make] Error 2 FAILED! CRITICAL FAILURE... failed build ======= - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru > > Guenter > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.14 00/59] 3.14.11-stable review
At Fri, 04 Jul 2014 22:45:42 -0700, Guenter Roeck wrote: > > On 07/04/2014 03:18 PM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.14.11 release. > > There are 59 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Sun Jul 6 22:15:27 UTC 2014. > > Anything received after that time might be too late. > > > > Build results: > total: 144 pass: 130 skipped: 4 fail: 10 > Failed builds: > alpha:allmodconfig > i386:allyesconfig > i386:allmodconfig > powerpc:allmodconfig (binutils 2.23) > powerpc:allmodconfig (binutils 2.24) > sparc64:allmodconfig > unicore32:defconfig > x86_64:allyesconfig > x86_64:allmodconfig > xtensa:allmodconfig > > Qemu test for x86 failed. > > Build error is the same as seen with 3.14. > > sound/pci/hda/patch_sigmatel.c: In function 'stac92hd95_fixup_hp_led': > sound/pci/hda/patch_sigmatel.c:4143:3: error: implicit declaration of > function 'codec_dbg' [-Werror=implicit-function-declaration] This kernel failed to build with the following error. Probably the root cause is the same as Guenter. I'm now bisecting to find the problematic patch... === ... home/sat/src/test-linux-stable/linux-stable/sound/pci/hda/patch_sigmatel.c:4143:3: error: implicit declaration of function ‘codec_dbg’ [-Werror=implicit-function-declaration] codec_dbg(codec, "mute LED gpio %d polarity %d\n", ^ LD [M] sound/pci/echoaudio/snd-indigoio.o LD [M] sound/pci/echoaudio/snd-indigodj.o LD [M] sound/pci/echoaudio/snd-indigoiox.o LD [M] sound/pci/echoaudio/snd-indigodjx.o CC [M] sound/pci/hda/patch_via.o LD sound/pci/ice1712/built-in.o CC [M] sound/pci/ice1712/ice1712.o cc1: some warnings being treated as errors /home/sat/src/test-linux-stable/linux-stable/scripts/Makefile.build:308: recipe for target 'sound/pci/hda/patch_sigmatel.o' failed make[4]: *** [sound/pci/hda/patch_sigmatel.o] Error 1 ... CC drivers/iommu/irq_remapping.o /home/sat/src/test-linux-stable/linux-stable/scripts/Makefile.build:455: recipe for target 'sound/pci/hda' failed make[3]: *** [sound/pci/hda] Error 2 ... /home/sat/src/test-linux-stable/linux-stable/scripts/Makefile.build:455: recipe for target 'sound/pci' failed make[2]: *** [sound/pci] Error 2 /home/sat/src/test-linux-stable/linux-stable/Makefile:841: recipe for target 'sound' failed make[1]: *** [sound] Error 2 ... Makefile:133: recipe for target 'sub-make' failed make: *** [sub-make] Error 2 FAILED! CRITICAL FAILURE... failed build ... ======= - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru > > Guenter > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.4 00/19] 3.4.97-stable review
At Fri, 04 Jul 2014 22:39:01 -0700, Guenter Roeck wrote: > > On 07/04/2014 03:15 PM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.4.97 release. > > There are 19 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Sun Jul 6 22:14:29 UTC 2014. > > Anything received after that time might be too late. > > > > Build results: > total: 137 pass: 111 skipped: 20 fail: 6 > Failed builds: > alpha:allmodconfig > arm:spear6xx_defconfig > score:defconfig > sparc64:allmodconfig > unicore32:defconfig > xtensa:allmodconfi > > Qemu tests all passed. > > Results are as expected. > > Details are available at http://server.roeck-us.net:8010/builders. This kernel passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Satoru > > Guenter > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.15 00/66] 3.15.4-stable review
At Fri, 04 Jul 2014 22:48:02 -0700, Guenter Roeck wrote: > > On 07/04/2014 03:13 PM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.15.4 release. > > There are 66 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Sun Jul 6 22:13:57 UTC 2014. > > Anything received after that time might be too late. > > > > Build results: > total: 144 pass: 136 skipped: 5 fail: 3 > Failed builds: > powerpc:allmodconfig (binutils 2.23) > powerpc:allmodconfig (binutils 2.24) > unicore32:defconfig > > Qemu tests all passed. > > Results are as expected. > > Details are available at http://server.roeck-us.net:8010/builders. > > On a side note, would be great if you can update the master branch > of -stable at some point. It is still at -rc2. This kernel passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Satoru > > Thanks, > Guenter > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] FS/BTRFS: replace count*size kzalloc by kcalloc
(2014/07/02 9:01), David Sterba wrote: On Wed, Jun 25, 2014 at 08:35:43PM +0200, Fabian Frederick wrote: kcalloc manages count*sizeof overflow. Cc: Chris Mason Cc: Josef Bacik Cc: linux-bt...@vger.kernel.org Signed-off-by: Fabian Frederick Reviewed-by: David Sterba Reviewed-by: Satoru Takeuchi -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.12 000/181] 3.12.24-stable review
At Mon, 30 Jun 2014 13:51:22 +0200, Jiri Slaby wrote: > > This is the start of the stable review cycle for the 3.12.24 release. > There are 181 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed Jul 2 11:49:58 2014 > Anything received after that time might be too late. This kernel passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.15 000/139] 3.15.3-stable review
At Sat, 28 Jun 2014 15:32:53 -0700, Guenter Roeck wrote: > > On 06/28/2014 10:46 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.15.3 release. > > There are 139 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Mon Jun 30 17:45:39 UTC 2014. > > Anything received after that time might be too late. > > > > Build results: > total: 144 pass: 136 skipped: 5 fail: 3 > Failed builds: > powerpc:allmodconfig > powerpc:allmodconfig > unicore32:defconfig > > Qemu tests all passed. > > Results are as expected. Details are available at > http://server.roeck-us.net:8010/builders. > > Guenter > 3.15.3-rc1, 3.14.10-rc1, 3.10.46-r1, and 3.4.96-rc1 passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.15 00/61] 3.15.2-stable review
At Tue, 24 Jun 2014 13:50:54 -0600, Shuah Khan wrote: > > On 06/24/2014 09:50 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.15.2 release. > > There are 61 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Thu Jun 26 15:49:36 UTC 2014. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.15.2-rc1.gz > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > Compiled and booted on my test system. No dmesg regressions. All 3.15.2-rc1, 3.14.9-rc1, 3.10.45-rc1, and 3.4.95-rc1 passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Satoru > > -- Shuah > > -- > Shuah Khan > Senior Linux Kernel Developer - Open Source Group > Samsung Research America(Silicon Valley) > shuah...@samsung.com | (970) 672-0658 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.12 000/111] 3.12.23-stable review
Hi Jiri,
At Mon, 23 Jun 2014 10:32:06 +0200,
Jiri Slaby wrote:
>
> This is the start of the stable review cycle for the 3.12.23 release.
> There are 111 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed Jun 25 08:31:21 2014
> Anything received after that time might be too late.
This kernel passed my test.
- Test Cases:
- Build this kernel.
- Boot this kernel.
- Build the latest mainline kernel with this kernel.
- Test Tool:
https://github.com/satoru-takeuchi/test-linux-stable
- Test Result (kernel .config, ktest config and test log):
http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz
- Build Environment:
- OS: Debian Jessy x86_64
- CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4
- memory: 8GB
- Test Target Environment:
- Debian Jessy x86_64 (KVM guest on the Build Environment)
- # of vCPU: 2
- memory: 2GB
Thanks,
Satoru
>
> The whole patch series can be found in one patch at:
>
> http://kernel.org/pub/linux/kernel/people/jirislaby/stable-review/patch-3.12.23-rc1.xz
> and the diffstat can be found below.
>
> thanks,
> js
>
> ===
>
>
> Alan Stern (1):
> USB: Avoid runtime suspend loops for HCDs that can't handle
> suspend/resume
>
> Alessandro Miceli (2):
> rtl28xxu: add [1b80:d39d] Sveon STV20
> rtl28xxu: add [1b80:d3af] Sveon STV27
>
> Alex Deucher (1):
> drm/radeon: handle non-VGA class pci devices with ATRM
>
> Alexei Starovoitov (2):
> net: filter: fix typo in sparc BPF JIT
> net: filter: fix sparc32 typo
>
> Alexej Starschenko (1):
> USB: serial: option: add support for Novatel E371 PCIe card
>
> Andreas Schrägle (1):
> ahci: add PCI ID for Marvell 88SE91A0 SATA Controller
>
> Andrey Ryabinin (2):
> ARM: 8051/1: put_user: fix possible data corruption in put_user
> mm: rmap: fix use-after-free in __put_anon_vma
>
> Andy Lutomirski (2):
> fs,userns: Change inode_capable to capable_wrt_inode_uidgid
> auditsc: audit_krule mask accesses need bounds checking
>
> Antti Palosaari (1):
> [media] rtl28xxu: add 15f4:0131 Astrometa DVB-T2
>
> Ben Dooks (1):
> sh_eth: use RNC mode for packet reception
>
> Ben Hutchings (2):
> Staging: speakup: Move pasting into a work item
> Staging: speakup: Update __speakup_paste_selection() tty (ab)usage to
> match vt
>
> Ben Skeggs (1):
> drm/gf119-/disp: fix nasty bug which can clobber SOR0's clock setup
>
> Bibek Basu (1):
> cpufreq: remove race while accessing cur_policy
>
> Bjørn Mork (2):
> usb: cdc-wdm: export cdc-wdm uapi header
> net: qmi_wwan: add Olivetti Olicard modems
>
> Boris BREZILLON (2):
> rtc: rtc-at91rm9200: fix infinite wait for ACKUPD irq
> ARM: at91: fix at91_sysirq_mask_rtc for sam9x5 SoCs
>
> Brian Healy (1):
> rtl28xxu: add 1b80:d395 Peak DVB-T USB
>
> Chris Wilson (1):
> drm/i915: Only copy back the modified fields to userspace from
> execbuffer
>
> Christian König (2):
> drm/radeon: also try GART for CPU accessed buffers
> drm/radeon: avoid crash if VM command submission isn't available
>
> Cong Wang (1):
> vxlan: use dev->needed_headroom instead of dev->hard_header_len
>
> Dan Carpenter (1):
> qlcnic: info leak in qlcnic_dcb_peer_app_info()
>
> Daniel Vetter (1):
> drm/i915: restrict vt-d stolen memory workaround to pre-gen8
>
> David Woodhouse (1):
> iommu/vt-d: Fix missing IOTLB flush in intel_iommu_unmap()
>
> Denis Turischev (1):
> xhci: Switch only Intel Lynx Point-LP ports to EHCI on shutdown.
>
> Dmitry Kasatkin (1):
> ima: introduce ima_kernel_read()
>
> Dmitry Popov (1):
> ipip, sit: fix ipv4_{update_pmtu,redirect} calls
>
> Emil Goode (1):
> ARM: imx: fix error handling in ipu device registration
>
> Eric Dumazet (3):
> net: fix inet_getid() and ipv6_select_ident() bugs
> net: force a list_del() in unregister_netdevice_many()
> ipv4: fix a race in ip4_datagram_release_cb()
>
> Eric W. Biederman (6):
> netlink: Rename netlink_capable netlink_allowed
> net: Move the permission check in sock_diag_put_filterinfo to
> packet_diag_dump
> net: Add variants of capable for use on on sockets
> net: Add variants of capable for use on netlink messages
> net: Use netlink_ns_capable to verify the permisions of netlink
> messages
> netlink: Only check file credentials for implicit destinations
>
> George McCollister (1):
> USB: ftdi_sio: add NovaTech OrionLXm product ID
>
> Greg Kroah-Hartman (1):
> USB:
Re: [PATCH v4] lib: add size unit t/p/e to memparse
Hi Gui, (2014/06/18 7:21), David Rientjes wrote: On Fri, 13 Jun 2014, Gui Hecheng wrote: For modern filesystems such as btrfs, t/p/e size level operations are common. add size unit t/p/e parsing to memparse Signed-off-by: Gui Hecheng Acked-by: David Rientjes It looks good to me. Reviewed-by: Satoru Takeuchi Thanks, Satoru Sorry, didn't do this before. Good luck with the simple_strto*() work! -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.15 00/12] 3.15.1-stable review
At Fri, 13 Jun 2014 08:16:02 -0700, Guenter Roeck wrote: > > On 06/12/2014 04:21 PM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.15.1 release. > > There are 12 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Sat Jun 14 23:20:28 UTC 2014. > > Anything received after that time might be too late. > > > > Build results: > total: 143 pass: 135 skipped: 5 fail: 3 > Failed builds: > powerpc:allmodconfig (binutils 2.23) > powerpc:allmodconfig (binutils 2.24) > unicore32:defconfig > > Qemu tests all passed. > > Results are as expected. > Details are available at http://server.roeck-us.net:8010/builders. 3.15.1-rc1, 3.14.8-rc1, 3.10.44-rc1, and 3.4.94-rc1 passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru > > Guenter > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.14 00/78] 3.14.7-stable review
Hi Greg, At Mon, 9 Jun 2014 15:47:40 -0700, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.14.7 release. > There are 78 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed Jun 11 22:47:49 UTC 2014. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.14.7-rc1.gz > and the diffstat can be found below. 3.14.7-rc1, 3.10.43-rc1, and 3.4.93-rc1 passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru > > thanks, > > greg k-h > > - > Pseudo-Shortlog of commits: > > Greg Kroah-Hartman > Linux 3.14.7-rc1 > > David Woodhouse > iommu/vt-d: Fix missing IOTLB flush in intel_iommu_unmap() > > Michael Welling > gpio: mcp23s08: Bug fix of SPI device tree registration. > > Imre Deak > drm/i915: dp: fix order of dp aux i2c device cleanup > > Imre Deak > drm/i915: add unregister callback to connector > > Denys Fedoryshchenko > netfilter: nfnetlink: Fix use after free when it fails to process batch > > Sergey Popovich > netfilter: Fix potential use after free in ip6_route_me_harder() > > Nicholas Bellinger > target: Fix alua_access_state attribute OOPs for un-configured devices > > Roland Dreier > iscsi-target: Fix wrong buffer / buffer overrun in > iscsi_change_param_value() > > Nicholas Bellinger > iser-target: Add missing target_put_sess_cmd for ImmedateData failure > > Andrey Ryabinin > mm: rmap: fix use-after-free in __put_anon_vma > > Naoya Horiguchi > mm: add !pte_present() check on existing hugetlb_entry callbacks > > Doug Smythies > intel_pstate: Improve initial busy calculation > > Dirk Brandewie > intel_pstate: add sample time scaling > > Dirk Brandewie > intel_pstate: Correct rounding in busy calculation > > Dirk Brandewie > intel_pstate: Remove C0 tracking > > Dirk Brandewie > intel_pstate: remove unneeded sample buffers > > Sebastian Ott > percpu-refcount: fix usage of this_cpu_ops > > Alan Stern > USB: Avoid runtime suspend loops for HCDs that can't handle suspend/resume > > Mathias Nyman > usb: pci-quirks: Prevent Sony VAIO t-series from switching usb ports > > Johan Hovold > USB: io_ti: fix firmware download on big-endian machines (part 2) > > Alexej Starschenko > USB: serial: option: add support for Novatel E371 PCIe card > > Greg Kroah-Hartman > USB: cdc-wdm: properly include types.h > > Bjørn Mork > usb: cdc-wdm: export cdc-wdm uapi header > > George McCollister > USB: ftdi_sio: add NovaTech OrionLXm product ID > > Takashi Iwai > ALSA: hda/realtek - Fix COEF widget NID for ALC260 replacer fixup > > Ronan Marquet > ALSA: hda/realtek - Correction of fixup codes for PB V7900 laptop > > Takashi Iwai > ALSA: hda/analog - Fix silent output on ASUS A8JN > > Samuel Ortiz > Bluetooth: Fix L2CAP LE debugfs entries permissions > > Sean MacLennan > staging: r8192e_pci: fix htons error > > Ben Hutchings > Staging: speakup: Update __speakup_paste_selection() tty (ab)usage to > match vt > > Ian Abbott > staging: comedi: ni_daq_700: add mux settling delay > > Ben Hutchings > Staging: speakup: Move pasting into a work item > > Mathias Nyman > xhci: delete endpoints from bandwidth list before freeing whole device > > NeilBrown > md: always set MD_RECOVERY_INTR when interrupting a reshape thread. > > NeilBrown > md: always set MD_RECOVERY_INTR when aborting a reshape or other "resync". > > Richard Weinberger > sched: Fix sched_policy < 0 comparison > > Martin K. Petersen > libata: Blacklist queued trim for Crucial M500 > > Christian König > drm/radeon: use the CP DMA on CIK > > Alex Deucher > drm/radeon/dpm: resume
Re: [PATCH 3.2 00/92] 3.2.60-rc1 review
Hi Ben, At Sat, 07 Jun 2014 18:00:37 +0100, Ben Hutchings wrote: > > On Sat, 2014-06-07 at 09:33 -0700, Guenter Roeck wrote: > > On Sat, Jun 07, 2014 at 02:26:28AM +0100, Ben Hutchings wrote: > > > This is the start of the stable review cycle for the 3.2.60 release. > > > There are 92 patches in this series, which will be posted as responses > > > to this one. If anyone has any issues with these being applied, please > > > let me know. > > > > > > Responses should be made by Mon Jun 09 01:26:28 UTC 2014. > > > Anything received after that time might be too late. > > > > > Build restults: > > total: 133 pass: 98 skipped: 25 fail: 10 > > > > Qem tests all passed. > > > > No unexpected build failures; results are as expected. > > > > Details are available at http://server.roeck-us.net:8010/builders. Although it's too late, I tell you that it passd my test just FYI. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru > > Thanks. > > Ben. > > -- > Ben Hutchings > Knowledge is power. France is bacon. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.12 000/146] 3.12.22-stable review
Hi Jiri,
At Mon, 9 Jun 2014 10:50:59 +0200,
Jiri Slaby wrote:
>
> This is the start of the stable review cycle for the 3.12.22 release.
> There are 146 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed Jun 11 08:50:21 2014
> Anything received after that time might be too late.
This kernel passed my test.
- Test Cases:
- Build this kernel.
- Boot this kernel.
- Build the latest mainline kernel with this kernel.
- Test Tool:
https://github.com/satoru-takeuchi/test-linux-stable
- Test Result (kernel .config, ktest config and test log):
http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz
- Build Environment:
- OS: Debian Jessy x86_64
- CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4
- memory: 8GB
- Test Target Environment:
- Debian Jessy x86_64 (KVM guest on the Build Environment)
- # of vCPU: 2
- memory: 2GB
Thanks,
Satoru
>
> The whole patch series can be found in one patch at:
>
> http://kernel.org/pub/linux/kernel/people/jirislaby/stable-review/patch-3.12.22-rc1.xz
> and the diffstat can be found below.
>
> thanks,
> js
>
> ===
>
>
> Aaron Lu (1):
> ACPI / video: Fix initial level validity test
>
> Alan Stern (1):
> USB: OHCI: fix problem with global suspend on ATI controllers
>
> Alex Deucher (6):
> drm/radeon: disable mclk dpm on R7 260X
> drm/radeon: add support for newer mc ucode on SI (v2)
> drm/radeon/si: make sure mc ucode is loaded before checking the size
> drm/radeon: fix ATPX detection on non-VGA GPUs
> drm/radeon/pm: don't walk the crtc list before it has been initialized
> (v2)
> drm/radeon: fix count in cik_sdma_ring_test()
>
> Alex Williamson (1):
> iommu/amd: Fix interrupt remapping for aliased devices
>
> Andy Grover (1):
> target: Don't allow setting WC emulation if device doesn't support
>
> Andy Shevchenko (1):
> dmaengine: dw: went back to plain {request,free}_irq() calls
>
> Anssi Hannula (1):
> ALSA: hda - hdmi: Set converter channel count even without sink
>
> Anthony Iliopoulos (1):
> x86, mm, hugetlb: Add missing TLB page invalidation for hugetlb_cow()
>
> Antti Palosaari (1):
> media: fc2580: fix tuning failure on 32-bit arch
>
> Aristeu Rozanski (2):
> device_cgroup: rework device access check and exception checking
> device_cgroup: check if exception removal is allowed
>
> Arnd Bergmann (1):
> genirq: Provide irq_force_affinity fallback for non-SMP
>
> Atilla Filiz (1):
> iio:imu:mpu6050: Fixed segfault in Invensens MPU driver due to null
> dereference
>
> Bartlomiej Zolnierkiewicz (1):
> pata_at91: fix ata_host_activate() failure handling
>
> Ben Hutchings (1):
> rtl8192cu: Fix unbalanced irq enable in error path of
> rtl92cu_hw_init()
>
> Bjørn Mork (1):
> usb: qcserial: add a number of Dell devices
>
> Charles Keepax (1):
> ASoC: wm8962: Update register CLASS_D_CONTROL_1 to be non-volatile
>
> Chen Yucong (1):
> hwpoison, hugetlb: lock_page/unlock_page does not match for handling a
> free hugepage
>
> Chris Wilson (1):
> drm/i915: Fix unsafe loop iteration over vma whilst unbinding them
>
> Christian König (2):
> drm/radeon/uvd: use lower clocks on old UVD to boot v2
> drm/radeon: use pflip irq on R600+ v2
>
> Christoph Hellwig (1):
> posix_acl: handle NULL ACL in posix_acl_equiv_mode
>
> Chunwei Chen (1):
> libceph: fix corruption when using page_count 0 page in rbd
>
> Clemens Ladisch (1):
> ALSA: usb-audio: work around corrupted TEAC UD-H01 feedback data
>
> Corey Minyard (1):
> ipmi: Reset the KCS timeout when starting error recovery
>
> Daeseok Youn (1):
> workqueue: fix bugs in wq_update_unbound_numa() failure path
>
> Dan Carpenter (1):
> clk: vexpress: NULL dereference on error path
>
> Daniel Vetter (2):
> drm/i915: Don't check gmch state on inherited configs
> drm/i915: Disable self-refresh for untiled fbs on i915gm
>
> Daniele Forsi (2):
> usb: storage: shuttle_usbat: fix discs being detected twice
> USB: Nokia 5300 should be treated as unusual dev
>
> David Rientjes (1):
> mm, oom: prefer thread group leaders for display purposes
>
> Du, Wenkai (1):
> i2c: designware: Mask all interrupts during i2c controller enable
>
> Edward Lin (1):
> ACPI: blacklist win8 OSI for Dell Inspiron 7737
>
> Egbert Eich (1):
> drm/i915: Break encoder->crtc link separately in intel_sanitize_crtc()
>
> Eliad Peller (1):
> cfg80211: free sme on
Re: [PATCH 3.14 000/228] 3.14.6-stable review
Hi Greg, At Fri, 6 Jun 2014 00:53:10 -0700, Guenter Roeck wrote: > > On Thu, Jun 05, 2014 at 04:20:08PM -0700, Greg Kroah-Hartman wrote: > > On Wed, Jun 04, 2014 at 04:20:29PM -0700, Greg Kroah-Hartman wrote: > > > This is the start of the stable review cycle for the 3.14.6 release. > > > There are 228 patches in this series, all will be posted as a response > > > to this one. If anyone has any issues with these being applied, please > > > let me know. > > > > > > Responses should be made by Fri Jun 6 23:23:11 UTC 2014. > > > Anything received after that time might be too late. > > > > > > The whole patch series can be found in one patch at: > > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.14.6-rc1.gz > > > and the diffstat can be found below. > > > > I've updated the stable tree with the futex patches as lots of people > > have been asking me about them, so here is a -rc2 with them > > incorporated: > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.14.6-rc1.gz "s/-rc1/-rc2/" ? I used the following one. https://www.kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.14.6-rc2.xz > > > > Build and qemu tests are still ok. Same applies to 3.4 and 3.10. 3.14.6-rc2, 3.10.42-rc1, and 3.4.92-rc1 passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.4 0/9] 3.4.91-stable review
At Sat, 17 May 2014 08:44:45 -0700, Guenter Roeck wrote: > > On 05/16/2014 03:55 PM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.4.91 release. > > There are 9 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Sun May 18 22:54:50 UTC 2014. > > Anything received after that time might be too late. > > > > Build results: > total: 134 pass: 109 skipped: 18 fail: 7 > > Qemu tests all passed. > > There are two new build failures, powerpc:ppc64e_defconfig and > powerpc:chroma_defconfig. > Those are not due to source code changes, but due to added builds. > Failures are seen if the images are built with binutils 2.24, and are caused > by a > changed assembler ABI. A patch to fix the problem has been submitted but is > not yet > upstream. > > Detailed results are available at http://server.roeck-us.net:8010/builders. > powerpc builds with binutils 2.24 are shown as 'powerpc_24' architecture. > > Guenter > This kernel passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.14 00/23] 3.14.1-stable review
At Fri, 11 Apr 2014 17:46:55 -0600, Shuah Khan wrote: > > On 04/11/2014 10:11 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.14.1 release. > > There are 23 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Sun Apr 13 16:11:46 UTC 2014. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.14.1-rc1.gz > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > Compiled and booted on my test systems. No dmesg regressions. All 3.10.37-rc1, 3.13.10-rc1, and 3.14.1-rc1 passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.4 000/134] 3.4.87-stable review
At Thu, 10 Apr 2014 13:56:29 -0600, Shuah Khan wrote: > > On 04/09/2014 09:21 PM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.4.87 release. > > There are 134 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Sat Apr 12 03:22:28 UTC 2014. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.87-rc1.gz > > and the diffstat can be found below. > > > > Compiled and booted on my test systems. No dmesg regressions. This kernel passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.2 000/200] 3.2.56-rc1 review
At Sun, 30 Mar 2014 17:49:46 -0700, Guenter Roeck wrote: > > On Mon, Mar 31, 2014 at 12:23:34AM +0100, Ben Hutchings wrote: > > This is the start of the stable review cycle for the 3.2.56 release. > > There are 200 patches in this series, which will be posted as responses > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Wed Apr 02 00:00:00 UTC 2014. > > Anything received after that time might be too late. > > > Build results: > total: 116 pass: 87 skipped: 22 fail: 7 > > Qemu tests all passed. Results are as expected. > > Details are available at http://server.roeck-us.net:8010/builders. > > Guenter This kernel passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.13 00/46] 3.13.8-stable review
At Fri, 28 Mar 2014 18:12:12 -0700, Guenter Roeck wrote: > > On 03/28/2014 10:31 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.13.8 release. > > There are 46 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Sun Mar 30 17:31:14 UTC 2014. > > Anything received after that time might be too late. > > > > Build results: > total: 126 pass: 120 skipped: 4 fail: 2 > > qemu tests all passed. > > Builds powerpc:mpc85xx_defconfig and powerpc:mpc85xx_smp_defconfig > are still failing. Upstream (-rc8) still has the same problem. > Results are therefore as expected. > > Details are available at http://server.roeck-us.net:8010/builders. > > Guenter 3.4.85-rc1, 3.10.35-rc1, and 3.13.8-rc1 passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] hung_task : check the value of "sysctl_hung_task_timeout_sec"
Hi Liu,
At Wed, 26 Mar 2014 15:56:58 +0800,
Liu hua wrote:
>
> 于 2014/3/26 0:25, Satoru Takeuchi 写道:
> > At Tue, 25 Mar 2014 16:58:58 +0800,
> > Liu hua wrote:
> >>
> >> 于 2014/3/24 4:50, Satoru Takeuchi 写道:
> >>> At Sun, 23 Mar 2014 15:54:04 +0800,
> >>> Liu Hua wrote:
> >>>>
> >>>> As sysctl_hung_task_timeout_sec is unsigned long, when this value is
> >>>> larger then LONG_MAX/HZ, the function schedule_timeout_interruptible in
> >>>> watchdog will return immediately without sleep and with print :
> >>>>
> >>>> [ 205.452934] schedule_timeout: wrong timeout value ff83
> >>>>
> >>>> and then the funtion watchdog will call schedule_timeout_interruptible
> >>>> again
> >>>> and again. The screen will be filled with
> >>>> "schedule_timeout: wrong timeout value ff83"
> >>>>
> >>>> This patch does some check and correction in timeout_jiffies, to let the
> >>>> function schedule_timeout_interruptible allways get the valid parameter.
> >>>>
> >>>> Cc:
> >>>> Signed-off-by: Liu Hua
> >>>> ---
> >>>> kernel/hung_task.c | 8 ++--
> >>>> 1 file changed, 6 insertions(+), 2 deletions(-)
> >>>>
> >>>> diff --git a/kernel/hung_task.c b/kernel/hung_task.c
> >>>> index 6df6149..f992286 100644
> >>>> --- a/kernel/hung_task.c
> >>>> +++ b/kernel/hung_task.c
> >>>> @@ -174,8 +174,12 @@ static void
> >>>> check_hung_uninterruptible_tasks(unsigned long timeout)
> >>>>
> >>>> static unsigned long timeout_jiffies(unsigned long timeout)
> >>>> {
> >>>> -/* timeout of 0 will disable the watchdog */
> >>>> -return timeout ? timeout * HZ : MAX_SCHEDULE_TIMEOUT;
> >>>> +/* timeout of 0 or >= LONG_MAX/HZ will disable the watchdog */
> >>>> +if ((timeout == 0) || (timeout > MAX_SCHEDULE_TIMEOUT))
> >>>
> >>> You should check whether sysctl_hung_task_timeout_sec >
> >>> MAX_SCHEDULE_TIMEOUT/HZ
> >>> or not when setting this parameter instead. Then this check ins't
> >>> necessary here.
> >>>
> >>> # Just FYI, MAX_SCHEDULE_TIMEOUT should be MAX_SCHEDULE_TIMEOUT/HZ here.
> >>>
> >>> Thanks,
> >>> Satoru
> >>
> >> Yes, how about this :
> >
> > I confirmed the followings.
> >
> > - 3.14-rc8: system hunged up with "hung_task_timeout_secs > LONG_MAX/HZ".
> > - 3.14-rc8 with your patch: works fine. I can't set the above mentioned
> > value any more.
> >
> > Writing possible values (0..LONG_MAX/HZ) in Documentation/sysctl/kernel.txt
> > make this patch better.
> >
> > Thanks,
> > Satoru
>
> Thanks to you attention and suggestion. I remade this patch as following.
> Is it appropriate to be reposted with tag "PATCH v3"
>
> Subject: [PATCH v3] hung_task : check the value of
> "sysctl_hung_task_timeout_sec"
It looks good to me.
Thanks,
Satoru
>
> As sysctl_hung_task_timeout_sec is unsigned long, when this value is
> larger then LONG_MAX/HZ, the function schedule_timeout_interruptible in
> watchdog will return immediately without sleep and with print :
>
> [ 205.452934] schedule_timeout: wrong timeout value ff83
>
> and then the funtion watchdog will call schedule_timeout_interruptible
> again and again. The screen will be filled with
> "schedule_timeout: wrong timeout value ff83"
>
> This patch does some check and correction in sysctl, to let the
> function schedule_timeout_interruptible allways get the valid parameter.
>
> Signed-off-by: Liu Hua
> Tested-by: Satoru Takeuchi
> ---
> Documentation/sysctl/kernel.txt | 1 +
> kernel/sysctl.c | 6 ++
> 2 files changed, 7 insertions(+)
>
> diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
> index e55124e..855d9b3 100644
> --- a/Documentation/sysctl/kernel.txt
> +++ b/Documentation/sysctl/kernel.txt
> @@ -317,6 +317,7 @@ for more than this value report a warning.
> This file shows up if CONFIG_DETECT_HUNG_TASK is enabled.
>
> 0: means infinite timeout - no checking done.
> +Possible values to set are in range {0..LONG_MAX/HZ}.
>
> ===
Re: [PATCH v2] hung_task : check the value of "sysctl_hung_task_timeout_sec"
At Tue, 25 Mar 2014 16:58:58 +0800,
Liu hua wrote:
>
> 于 2014/3/24 4:50, Satoru Takeuchi 写道:
> > At Sun, 23 Mar 2014 15:54:04 +0800,
> > Liu Hua wrote:
> >>
> >> As sysctl_hung_task_timeout_sec is unsigned long, when this value is
> >> larger then LONG_MAX/HZ, the function schedule_timeout_interruptible in
> >> watchdog will return immediately without sleep and with print :
> >>
> >> [ 205.452934] schedule_timeout: wrong timeout value ff83
> >>
> >> and then the funtion watchdog will call schedule_timeout_interruptible
> >> again
> >> and again. The screen will be filled with
> >>"schedule_timeout: wrong timeout value ff83"
> >>
> >> This patch does some check and correction in timeout_jiffies, to let the
> >> function schedule_timeout_interruptible allways get the valid parameter.
> >>
> >> Cc:
> >> Signed-off-by: Liu Hua
> >> ---
> >> kernel/hung_task.c | 8 ++--
> >> 1 file changed, 6 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/kernel/hung_task.c b/kernel/hung_task.c
> >> index 6df6149..f992286 100644
> >> --- a/kernel/hung_task.c
> >> +++ b/kernel/hung_task.c
> >> @@ -174,8 +174,12 @@ static void check_hung_uninterruptible_tasks(unsigned
> >> long timeout)
> >>
> >> static unsigned long timeout_jiffies(unsigned long timeout)
> >> {
> >> - /* timeout of 0 will disable the watchdog */
> >> - return timeout ? timeout * HZ : MAX_SCHEDULE_TIMEOUT;
> >> + /* timeout of 0 or >= LONG_MAX/HZ will disable the watchdog */
> >> + if ((timeout == 0) || (timeout > MAX_SCHEDULE_TIMEOUT))
> >
> > You should check whether sysctl_hung_task_timeout_sec >
> > MAX_SCHEDULE_TIMEOUT/HZ
> > or not when setting this parameter instead. Then this check ins't necessary
> > here.
> >
> > # Just FYI, MAX_SCHEDULE_TIMEOUT should be MAX_SCHEDULE_TIMEOUT/HZ here.
> >
> > Thanks,
> > Satoru
>
> Yes, how about this :
I confirmed the followings.
- 3.14-rc8: system hunged up with "hung_task_timeout_secs > LONG_MAX/HZ".
- 3.14-rc8 with your patch: works fine. I can't set the above mentioned value
any more.
Writing possible values (0..LONG_MAX/HZ) in Documentation/sysctl/kernel.txt
make this patch better.
Thanks,
Satoru
>
> diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> index 49e13e1..aae21e8 100644
> --- a/kernel/sysctl.c
> +++ b/kernel/sysctl.c
> @@ -144,6 +144,11 @@ static int min_percpu_pagelist_fract = 8;
> static int ngroups_max = NGROUPS_MAX;
> static const int cap_last_cap = CAP_LAST_CAP;
>
> +/*this is needed for proc_doulongvec_minmax of sysctl_hung_task_timeout_secs
> */
> +#ifdef CONFIG_DETECT_HUNG_TASK
> +static unsigned long hung_task_timeout_max = (LONG_MAX/HZ);
> +#endif
> +
> #ifdef CONFIG_INOTIFY_USER
> #include
> #endif
> @@ -995,6 +1000,7 @@ static struct ctl_table kern_table[] = {
> .maxlen = sizeof(unsigned long),
> .mode = 0644,
> .proc_handler = proc_dohung_task_timeout_secs,
> + .extra2 = &hung_task_timeout_max,
> },
> {
> .procname = "hung_task_warnings",
> --
> 1.9.0
>
> Thanks
> Liu Hua
>
>
>
> >
> >> + return MAX_SCHEDULE_TIMEOUT;
> >> +
> >> + return (timeout * HZ) < MAX_SCHEDULE_TIMEOUT ?
> >> + timeout * HZ : MAX_SCHEDULE_TIMEOUT;
> >> }
> >>
> >> /*
> >> --
> >> 1.9.0
> >>
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe stable" in
> >> the body of a message to majord...@vger.kernel.org
> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
> > .
> >
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] hung_task : check the value of "sysctl_hung_task_timeout_sec"
At Sun, 23 Mar 2014 15:54:04 +0800,
Liu Hua wrote:
>
> As sysctl_hung_task_timeout_sec is unsigned long, when this value is
> larger then LONG_MAX/HZ, the function schedule_timeout_interruptible in
> watchdog will return immediately without sleep and with print :
>
> [ 205.452934] schedule_timeout: wrong timeout value ff83
>
> and then the funtion watchdog will call schedule_timeout_interruptible again
> and again. The screen will be filled with
> "schedule_timeout: wrong timeout value ff83"
>
> This patch does some check and correction in timeout_jiffies, to let the
> function schedule_timeout_interruptible allways get the valid parameter.
>
> Cc:
> Signed-off-by: Liu Hua
> ---
> kernel/hung_task.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/hung_task.c b/kernel/hung_task.c
> index 6df6149..f992286 100644
> --- a/kernel/hung_task.c
> +++ b/kernel/hung_task.c
> @@ -174,8 +174,12 @@ static void check_hung_uninterruptible_tasks(unsigned
> long timeout)
>
> static unsigned long timeout_jiffies(unsigned long timeout)
> {
> - /* timeout of 0 will disable the watchdog */
> - return timeout ? timeout * HZ : MAX_SCHEDULE_TIMEOUT;
> + /* timeout of 0 or >= LONG_MAX/HZ will disable the watchdog */
> + if ((timeout == 0) || (timeout > MAX_SCHEDULE_TIMEOUT))
You should check whether sysctl_hung_task_timeout_sec > MAX_SCHEDULE_TIMEOUT/HZ
or not when setting this parameter instead. Then this check ins't necessary
here.
# Just FYI, MAX_SCHEDULE_TIMEOUT should be MAX_SCHEDULE_TIMEOUT/HZ here.
Thanks,
Satoru
> + return MAX_SCHEDULE_TIMEOUT;
> +
> + return (timeout * HZ) < MAX_SCHEDULE_TIMEOUT ?
> + timeout * HZ : MAX_SCHEDULE_TIMEOUT;
> }
>
> /*
> --
> 1.9.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe stable" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.13 000/149] 3.13.7-stable review
Hi Greg, At Thu, 20 Mar 2014 17:02:43 -0700, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.13.7 release. > There are 149 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun Mar 23 00:03:54 UTC 2014. > Anything received after that time might be too late. 3.4.84-rc1, 3.10.34-rc1, and 3.13.7-rc1 passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] ktest doc: Automated test of linux kernel by using ktest
At Thu, 20 Mar 2014 11:55:02 -0400, Steven Rostedt wrote: > > On Sat, 15 Mar 2014 16:22:49 +0900 > Satoru Takeuchi wrote: > > > Hi, > > > > I wrote a ktest document and published it. > > > > http://www.slideshare.net/satorutakeuchi18/kernel-auto-testbyktest > > > > It's not the ktest reference guild, but the quick learning guild of ktest > > especially focuses on some important features. > > > > After reading this document, you'll be able to do the following work > > automatically. > > > > - test all patches of your patchset, and > > - bisect to find the problematic commit > > > > I believe it saves plenty of your time. > > > > Feel free to ask me if you have any comments/questions. > > > > Looks nice. Thanks for sharing. You're welcome! Satoru > > -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC] ktest doc: Automated test of linux kernel by using ktest
Hi, I wrote a ktest document and published it. http://www.slideshare.net/satorutakeuchi18/kernel-auto-testbyktest It's not the ktest reference guild, but the quick learning guild of ktest especially focuses on some important features. After reading this document, you'll be able to do the following work automatically. - test all patches of your patchset, and - bisect to find the problematic commit I believe it saves plenty of your time. Feel free to ask me if you have any comments/questions. Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] ktest: remove the misleading $buildonly and introduce $laststep.
At Tue, 11 Mar 2014 20:43:40 +0900,
Satoru Takeuchi wrote:
>
> At Mon, 10 Mar 2014 12:13:00 -0400,
> Steven Rostedt wrote:
> >
> > On Sun, 09 Mar 2014 23:36:49 +0900
> > Satoru Takeuchi wrote:
> >
> > > From: Satoru Takeuchi
> > >
> > > Each test of ktest consists of the following steps.
> > >
> > > build -> install -> boot -> run user defined tests.
> > >
> > > $buildonly means not whether the test is build onlyor not. Actually
> > > this variable mean the last step of the test as follows.
> > >
> > > 0: boot or more
> > > 1: build
> > > 2: install
> > >
> > > AS you can see, these are random numeric literals. In addition,
> > > there is no explanation about them.
> > >
> > > To improve readability, introduce $laststep instead of $buildonly.
> > > This variable means the last step of the test as follows.
> > >
> > > STEP_BUILD (=0):build
> > > STEP_INSTALL (=1): install
> > > STEP_BOOT_OR_MORE (=2): boot or more
> >
> > Nice clean up. But there's some bugs in this patch.
> >
> >
> > > @@ -649,26 +651,20 @@ sub set_value {
> > >
> > > my $prvalue = process_variables($rvalue);
> > >
> > > -if ($buildonly && $lvalue =~ /^TEST_TYPE(\[.*\])?$/ && $prvalue ne
> > > "build") {
> > > - # Note if a test is something other than build, then we
> > > - # will need other manditory options.
> > > - if ($prvalue ne "install") {
> > > - # for bisect, we need to check BISECT_TYPE
> > > - if ($prvalue ne "bisect") {
> > > - $buildonly = 0;
> >
> > When prvalue ne "bisect" we set it to boot or more.
> >
> > > +if ($laststep <= STEP_INSTALL) {
> > > + if ($lvalue =~ /^TEST_TYPE(\[.*\])?$/ && $prvalue ne "build") {
> > > + # Note if a test is something other than build, then we
> > > + # will need other manditory options.
> > > + if ($prvalue eq "install") {
> > > + # install still limits some manditory options.
> > > + $laststep = STEP_INSTALL;
> > > + } elsif ($prvalue ne "bisect") {
> > > + # for bisect, we need to check BISECT_TYPE
> > > + $laststep = STEP_BUILD;
> >
> > Here you set it back to build.
> >
> > > }
> > > - } else {
> > > - # install still limits some manditory options.
> > > - $buildonly = 2;
> > > - }
> > > -}
> > > -
> > > -if ($buildonly && $lvalue =~ /^BISECT_TYPE(\[.*\])?$/ && $prvalue ne
> > > "build") {
> > > - if ($prvalue ne "install") {
> > > - $buildonly = 0;
> > > - } else {
> > > - # install still limits some manditory options.
> > > - $buildonly = 2;
> > > + } elsif ($lvalue =~ /^BISECT_TYPE(\[.*\])?$/ &&
> > > +$prvalue ne "build") {
> > > + $laststep = ($prvalue eq "install") ? STEP_INSTALL : STEP_BUILD;
> >
> > Here too.
> >
> > In fact, with this patch, we never set to boot or more.
>
> Sorry, my code review and test are insufficient.
>
> >
> > Also, you can make it even cleaner, by having the outer if condition be:
> >
> > if ($laststep <= STEP_INSTALL && $prvalue ne "build")
> >
> > And remove the prvalue check from the inner conditions.
>
> Thank you fo your comment.
>
> >
> > Just send a fix of this patch, I have already pulled in the other two.
>
> Thanks, I'll do.
>
> > I just need to test them for a bit before I push them to my kernel.org
> > repo. I don't actually have a test suite for ktest. My testing is that
> > I use ktest on a daily basis, and I just use the latest devel ktest for
> > my daily activities. If something breaks, I usually notice, unless it's
> > affects something I haven't done recently (like a bisect).
>
> I'll make and send my testsuite later. I considers that
> tools/testing/ktest/example is suitable to place it.
Sorry, actually tools/testing/ktest/tests.
.../examples/ is for examples for configs file as written in examples/README.
Thanks,
Satoru
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] ktest: remove the misleading $buildonly and introduce $laststep.
At Mon, 10 Mar 2014 12:13:00 -0400,
Steven Rostedt wrote:
>
> On Sun, 09 Mar 2014 23:36:49 +0900
> Satoru Takeuchi wrote:
>
> > From: Satoru Takeuchi
> >
> > Each test of ktest consists of the following steps.
> >
> > build -> install -> boot -> run user defined tests.
> >
> > $buildonly means not whether the test is build onlyor not. Actually
> > this variable mean the last step of the test as follows.
> >
> > 0: boot or more
> > 1: build
> > 2: install
> >
> > AS you can see, these are random numeric literals. In addition,
> > there is no explanation about them.
> >
> > To improve readability, introduce $laststep instead of $buildonly.
> > This variable means the last step of the test as follows.
> >
> > STEP_BUILD (=0):build
> > STEP_INSTALL (=1): install
> > STEP_BOOT_OR_MORE (=2): boot or more
>
> Nice clean up. But there's some bugs in this patch.
>
>
> > @@ -649,26 +651,20 @@ sub set_value {
> >
> > my $prvalue = process_variables($rvalue);
> >
> > -if ($buildonly && $lvalue =~ /^TEST_TYPE(\[.*\])?$/ && $prvalue ne
> > "build") {
> > - # Note if a test is something other than build, then we
> > - # will need other manditory options.
> > - if ($prvalue ne "install") {
> > - # for bisect, we need to check BISECT_TYPE
> > - if ($prvalue ne "bisect") {
> > - $buildonly = 0;
>
> When prvalue ne "bisect" we set it to boot or more.
>
> > +if ($laststep <= STEP_INSTALL) {
> > + if ($lvalue =~ /^TEST_TYPE(\[.*\])?$/ && $prvalue ne "build") {
> > + # Note if a test is something other than build, then we
> > + # will need other manditory options.
> > + if ($prvalue eq "install") {
> > + # install still limits some manditory options.
> > + $laststep = STEP_INSTALL;
> > + } elsif ($prvalue ne "bisect") {
> > + # for bisect, we need to check BISECT_TYPE
> > + $laststep = STEP_BUILD;
>
> Here you set it back to build.
>
> > }
> > - } else {
> > - # install still limits some manditory options.
> > - $buildonly = 2;
> > - }
> > -}
> > -
> > -if ($buildonly && $lvalue =~ /^BISECT_TYPE(\[.*\])?$/ && $prvalue ne
> > "build") {
> > - if ($prvalue ne "install") {
> > - $buildonly = 0;
> > - } else {
> > - # install still limits some manditory options.
> > - $buildonly = 2;
> > + } elsif ($lvalue =~ /^BISECT_TYPE(\[.*\])?$/ &&
> > + $prvalue ne "build") {
> > + $laststep = ($prvalue eq "install") ? STEP_INSTALL : STEP_BUILD;
>
> Here too.
>
> In fact, with this patch, we never set to boot or more.
Sorry, my code review and test are insufficient.
>
> Also, you can make it even cleaner, by having the outer if condition be:
>
> if ($laststep <= STEP_INSTALL && $prvalue ne "build")
>
> And remove the prvalue check from the inner conditions.
Thank you fo your comment.
>
> Just send a fix of this patch, I have already pulled in the other two.
Thanks, I'll do.
> I just need to test them for a bit before I push them to my kernel.org
> repo. I don't actually have a test suite for ktest. My testing is that
> I use ktest on a daily basis, and I just use the latest devel ktest for
> my daily activities. If something breaks, I usually notice, unless it's
> affects something I haven't done recently (like a bisect).
I'll make and send my testsuite later. I considers that
tools/testing/ktest/example is suitable to place it.
Thanks,
Satoru
>
> Thanks,
>
> -- Steve
>
> > }
> > }
> >
> > @@ -4045,7 +4041,7 @@ for (my $i = 1; $i <= $opt{"NUM_TESTS"}; $i++) {
> > $dmesg = "$tmpdir/dmesg-$machine";
> > $output_config = "$outputdir/.config";
> >
> > -if (!$buildonly) {
> > +if ($laststep >= STEP_BOOT_OR_MORE) {
> > $target = "$ssh_user\@$machine";
> > if ($reboot_type eq "grub") {
> > dodie "GRUB_MENU not defined" if (!defined($grub_menu));
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] ktest: remove the misleading $buildonly and introduce $laststep.
From: Satoru Takeuchi
Each test of ktest consists of the following steps.
build -> install -> boot -> run user defined tests.
$buildonly means not whether the test is build onlyor not. Actually
this variable mean the last step of the test as follows.
0: boot or more
1: build
2: install
AS you can see, these are random numeric literals. In addition,
there is no explanation about them.
To improve readability, introduce $laststep instead of $buildonly.
This variable means the last step of the test as follows.
STEP_BUILD (=0):build
STEP_INSTALL (=1): install
STEP_BOOT_OR_MORE (=2): boot or more
Signed-off-by: Satoru Takeuchi
Cc: Steven Rostedt
---
tools/testing/ktest/ktest.pl | 70 +---
1 file changed, 33 insertions(+), 37 deletions(-)
diff --git a/tools/testing/ktest/ktest.pl b/tools/testing/ktest/ktest.pl
index c34f0de..ec82487 100755
--- a/tools/testing/ktest/ktest.pl
+++ b/tools/testing/ktest/ktest.pl
@@ -196,9 +196,14 @@ my $patchcheck_type;
my $patchcheck_start;
my $patchcheck_end;
-# set when a test is something other that just building or install
-# which would require more options.
-my $buildonly = 1;
+# Each test of ktest consists of the following steps.
+use constant {
+STEP_BUILD => 0,
+STEP_INSTALL => 1,
+STEP_BOOT_OR_MORE => 2,
+};
+# The last step of test.
+my $laststep = STEP_BUILD;
# tell build not to worry about warnings, even when WARNINGS_FILE is set
my $warnings_ok = 0;
@@ -553,30 +558,27 @@ sub get_mandatory_config {
}
sub get_mandatory_configs {
+# Options required for build step.
get_mandatory_config("MACHINE");
get_mandatory_config("BUILD_DIR");
get_mandatory_config("OUTPUT_DIR");
+get_mandatory_config("LOCALVERSION");
if ($newconfig) {
get_mandatory_config("BUILD_OPTIONS");
}
+return if ($laststep == STEP_BUILD);
-# options required for other than just building a kernel
-if (!$buildonly) {
- get_mandatory_config("POWER_CYCLE");
- get_mandatory_config("CONSOLE");
-}
+# Options required for install step.
+get_mandatory_config("SSH_USER");
+get_mandatory_config("BUILD_TARGET");
+get_mandatory_config("TARGET_IMAGE");
-# options required for install and more
-if ($buildonly != 1) {
- get_mandatory_config("SSH_USER");
- get_mandatory_config("BUILD_TARGET");
- get_mandatory_config("TARGET_IMAGE");
-}
-
-get_mandatory_config("LOCALVERSION");
+return if ($laststep == STEP_INSTALL);
-return if ($buildonly);
+# Options required for boot step.
+get_mandatory_config("POWER_CYCLE");
+get_mandatory_config("CONSOLE");
my $rtype = $opt{"REBOOT_TYPE"};
@@ -649,26 +651,20 @@ sub set_value {
my $prvalue = process_variables($rvalue);
-if ($buildonly && $lvalue =~ /^TEST_TYPE(\[.*\])?$/ && $prvalue ne
"build") {
- # Note if a test is something other than build, then we
- # will need other manditory options.
- if ($prvalue ne "install") {
- # for bisect, we need to check BISECT_TYPE
- if ($prvalue ne "bisect") {
- $buildonly = 0;
+if ($laststep <= STEP_INSTALL) {
+ if ($lvalue =~ /^TEST_TYPE(\[.*\])?$/ && $prvalue ne "build") {
+ # Note if a test is something other than build, then we
+ # will need other manditory options.
+ if ($prvalue eq "install") {
+ # install still limits some manditory options.
+ $laststep = STEP_INSTALL;
+ } elsif ($prvalue ne "bisect") {
+ # for bisect, we need to check BISECT_TYPE
+ $laststep = STEP_BUILD;
}
- } else {
- # install still limits some manditory options.
- $buildonly = 2;
- }
-}
-
-if ($buildonly && $lvalue =~ /^BISECT_TYPE(\[.*\])?$/ && $prvalue ne
"build") {
- if ($prvalue ne "install") {
- $buildonly = 0;
- } else {
- # install still limits some manditory options.
- $buildonly = 2;
+ } elsif ($lvalue =~ /^BISECT_TYPE(\[.*\])?$/ &&
+ $prvalue ne "build") {
+ $laststep = ($prvalue eq "install") ? STEP_INSTALL : STEP_BUILD;
}
}
@@ -4045,7 +4041,7 @@ for (my $i = 1; $i <= $opt{"NUM_TESTS"}; $i++) {
$dmesg = "$tmpdir/dmesg-$machine";
$output_config = "$outputdir/.config";
-if (!$buildonly) {
+if ($laststep >= STEP_BOOT_OR_MORE) {
$target = "$ssh_user\@$machine";
if ($reboot_type eq "grub") {
dodie "GRUB_MENU not defined" if (!defined($grub_menu));
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] ktest: Some cleanup for improving readability
From: Satoru Takeuchi
Some cleanup for improving readability as follows.
- Initialize $ktest_config at its definition.
- Put parentheses around the `config-file' argument in the usage message
because it's a optional one.
- Rename get_ktest_config{,s} to more descriptive get_mandatory_config{,s}.
Signed-off-by: Satoru Takeuchi
Cc: Steven Rostedt
---
tools/testing/ktest/ktest.pl | 42 --
1 file changed, 20 insertions(+), 22 deletions(-)
diff --git a/tools/testing/ktest/ktest.pl b/tools/testing/ktest/ktest.pl
index f731ef6..c34f0de 100755
--- a/tools/testing/ktest/ktest.pl
+++ b/tools/testing/ktest/ktest.pl
@@ -72,7 +72,7 @@ my %default = (
"IGNORE_UNUSED"=> 0,
);
-my $ktest_config;
+my $ktest_config = "ktest.conf";
my $version;
my $have_version = 0;
my $machine;
@@ -521,7 +521,7 @@ sub read_ync {
return read_prompt 1, $prompt;
}
-sub get_ktest_config {
+sub get_mandatory_config {
my ($config) = @_;
my $ans;
@@ -552,29 +552,29 @@ sub get_ktest_config {
}
}
-sub get_ktest_configs {
-get_ktest_config("MACHINE");
-get_ktest_config("BUILD_DIR");
-get_ktest_config("OUTPUT_DIR");
+sub get_mandatory_configs {
+get_mandatory_config("MACHINE");
+get_mandatory_config("BUILD_DIR");
+get_mandatory_config("OUTPUT_DIR");
if ($newconfig) {
- get_ktest_config("BUILD_OPTIONS");
+ get_mandatory_config("BUILD_OPTIONS");
}
# options required for other than just building a kernel
if (!$buildonly) {
- get_ktest_config("POWER_CYCLE");
- get_ktest_config("CONSOLE");
+ get_mandatory_config("POWER_CYCLE");
+ get_mandatory_config("CONSOLE");
}
# options required for install and more
if ($buildonly != 1) {
- get_ktest_config("SSH_USER");
- get_ktest_config("BUILD_TARGET");
- get_ktest_config("TARGET_IMAGE");
+ get_mandatory_config("SSH_USER");
+ get_mandatory_config("BUILD_TARGET");
+ get_mandatory_config("TARGET_IMAGE");
}
-get_ktest_config("LOCALVERSION");
+get_mandatory_config("LOCALVERSION");
return if ($buildonly);
@@ -582,7 +582,7 @@ sub get_ktest_configs {
if (!defined($rtype)) {
if (!defined($opt{"GRUB_MENU"})) {
- get_ktest_config("REBOOT_TYPE");
+ get_mandatory_config("REBOOT_TYPE");
$rtype = $entered_configs{"REBOOT_TYPE"};
} else {
$rtype = "grub";
@@ -590,16 +590,16 @@ sub get_ktest_configs {
}
if ($rtype eq "grub") {
- get_ktest_config("GRUB_MENU");
+ get_mandatory_config("GRUB_MENU");
}
if ($rtype eq "grub2") {
- get_ktest_config("GRUB_MENU");
- get_ktest_config("GRUB_FILE");
+ get_mandatory_config("GRUB_MENU");
+ get_mandatory_config("GRUB_FILE");
}
if ($rtype eq "syslinux") {
- get_ktest_config("SYSLINUX_LABEL");
+ get_mandatory_config("SYSLINUX_LABEL");
}
}
@@ -1089,7 +1089,7 @@ sub read_config {
$test_case = __read_config $config, \$test_num;
# make sure we have all mandatory configs
-get_ktest_configs;
+get_mandatory_configs;
# was a test specified?
if (!$test_case) {
@@ -3858,7 +3858,7 @@ sub make_warnings_file {
success $i;
}
-$#ARGV < 1 or die "ktest.pl version: $VERSION\n usage: ktest.pl
config-file\n";
+$#ARGV < 1 or die "ktest.pl version: $VERSION\n usage: ktest.pl
[config-file]\n";
if ($#ARGV == 0) {
$ktest_config = $ARGV[0];
@@ -3868,8 +3868,6 @@ if ($#ARGV == 0) {
exit 0;
}
}
-} else {
-$ktest_config = "ktest.conf";
}
if (! -f $ktest_config) {
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] ktest: add 2nd parameter of run_command() to set the redirect target file
From: Satoru Takeuchi
If we'd like to set the redirect target file of run_command(),
we should define $redirect before this function and should undef it after
this function. Since it's user-unfriendly, add 2nd parameter of
run_command() for this purpose.
Signed-off-by: Satoru Takeuchi
Cc: Steven Rostedt
---
tools/testing/ktest/ktest.pl | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/tools/testing/ktest/ktest.pl b/tools/testing/ktest/ktest.pl
index 4063156..f731ef6 100755
--- a/tools/testing/ktest/ktest.pl
+++ b/tools/testing/ktest/ktest.pl
@@ -149,7 +149,6 @@ my $bisect_ret_abort;
my $bisect_ret_default;
my $in_patchcheck = 0;
my $run_test;
-my $redirect;
my $buildlog;
my $testlog;
my $dmesg;
@@ -1529,7 +1528,7 @@ sub fail {
}
sub run_command {
-my ($command) = @_;
+my ($command, $redirect) = @_;
my $dolog = 0;
my $dord = 0;
my $pid;
@@ -2265,9 +2264,7 @@ sub build {
# Run old config regardless, to enforce min configurations
make_oldconfig;
-$redirect = "$buildlog";
-my $build_ret = run_command "$make $build_options";
-undef $redirect;
+my $build_ret = run_command "$make $build_options", $buildlog;
if (defined($post_build)) {
# Because a post build may change the kernel version
@@ -2360,9 +2357,7 @@ sub child_run_test {
$poweroff_on_error = 0;
$die_on_failure = 1;
-$redirect = "$testlog";
-run_command $run_test or $failed = 1;
-undef $redirect;
+run_command $run_test, $testlog or $failed = 1;
exit $failed;
}
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.4 00/99] 3.4.83-stable review
At Sat, 08 Mar 2014 09:10:00 -0800, Guenter Roeck wrote: > > On 03/08/2014 08:18 AM, Greg Kroah-Hartman wrote: > > On Sat, Mar 08, 2014 at 06:35:52AM -0800, Guenter Roeck wrote: > >> On 03/08/2014 01:47 AM, Satoru Takeuchi wrote: > >>> At Fri, 7 Mar 2014 17:06:56 -0800, > >>> Greg Kroah-Hartman wrote: > >>>> > >>>> This is the start of the stable review cycle for the 3.4.83 release. > >>>> There are 99 patches in this series, all will be posted as a response > >>>> to this one. If anyone has any issues with these being applied, please > >>>> let me know. > >>>> > >>>> Responses should be made by Mon Mar 10 01:05:53 UTC 2014. > >>>> Anything received after that time might be too late. > >>> > >>> This kernel passed my test. > >>> > >> > >> Same here. > >> > >> Built results: > >>total: 119 pass: 97 skipped: 18 fail: 4 > >> > >> qemu tests all passed. > >> > >> Details are available at http://server.roeck-us.net:8010/builders. > > > > Thanks to both of you for testing this, much appreciated. > > > > You are welcome. > > Can you possibly add me to the cc: of your introductory e-mail > announcing new stable releases ? Sometimes it seems to get lost > and isn't available on any of the 'common' archives (this one > did not make it to lkml, for example, and many of the individual > mails didn't make it into the stable mailing list at gmane). Me too. Thanks, Satoru > > Thanks, > Guenter > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.4 00/99] 3.4.83-stable review
At Fri, 7 Mar 2014 17:06:56 -0800, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.4.83 release. > There are 99 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Mon Mar 10 01:05:53 UTC 2014. > Anything received after that time might be too late. This kernel passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] ktest: add 2nd parameter of run_command() to set the redirect target file
At Fri, 7 Mar 2014 19:43:28 -0500, Steven Rostedt wrote: > > On Sat, 08 Mar 2014 09:12:31 +0900 > Satoru Takeuchi wrote: > > > Hi Steven, > > > > At Sun, 02 Mar 2014 21:20:31 +0900, > > Satoru Takeuchi wrote: > > > > > > From: Satoru Takeuchi > > > > > > If we'd like to set the redirect target file of run_command(), > > > we should define $redirect before calling this function and should undef > > > it > > > after calling this function. Since it's user-unfriendly, add 2nd > > > parameter of > > > run_command() for this purpose. > > > > > > Signed-off-by: Satoru Takeuchi > > > Cc: Steven Rostedt > > > > Could you tell whether this patch will be applied? Although you told me > > that you > > won't apply the following patch, I didn't hear about this patch. > > Ah, I was thinking this one was needed for the next patch, so I didn't > apply it. The two patches don't depend on earch other. > > > > > > [PATCH 2/2] ktest: run make mrproper not only for OUTPUT_DIR but also for > > > BUILD_DIR to avoid build failure > > > > I make this question since I'll send next patch set this weekend and want to > > know whether I can make patch on the top of this patch. > > You can add this one again. I haven't really reviewed it, but if other > patches depend on it, include it as well. Include it anyway if you want > me to review it. OK, I'll resend patch 1/2 at the next post of my patchset. Thanks, Satoru > > Thanks, > > -- Steve > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] ktest: add 2nd parameter of run_command() to set the redirect target file
Hi Steven,
At Sun, 02 Mar 2014 21:20:31 +0900,
Satoru Takeuchi wrote:
>
> From: Satoru Takeuchi
>
> If we'd like to set the redirect target file of run_command(),
> we should define $redirect before calling this function and should undef it
> after calling this function. Since it's user-unfriendly, add 2nd parameter of
> run_command() for this purpose.
>
> Signed-off-by: Satoru Takeuchi
> Cc: Steven Rostedt
Could you tell whether this patch will be applied? Although you told me that you
won't apply the following patch, I didn't hear about this patch.
> [PATCH 2/2] ktest: run make mrproper not only for OUTPUT_DIR but also for
> BUILD_DIR to avoid build failure
I make this question since I'll send next patch set this weekend and want to
know whether I can make patch on the top of this patch.
Thanks,
Satoru
> ---
> tools/testing/ktest/ktest.pl | 11 +++
> 1 file changed, 3 insertions(+), 8 deletions(-)
>
> diff --git a/tools/testing/ktest/ktest.pl b/tools/testing/ktest/ktest.pl
> index 4063156..f731ef6 100755
> --- a/tools/testing/ktest/ktest.pl
> +++ b/tools/testing/ktest/ktest.pl
> @@ -149,7 +149,6 @@ my $bisect_ret_abort;
> my $bisect_ret_default;
> my $in_patchcheck = 0;
> my $run_test;
> -my $redirect;
> my $buildlog;
> my $testlog;
> my $dmesg;
> @@ -1529,7 +1528,7 @@ sub fail {
> }
>
> sub run_command {
> -my ($command) = @_;
> +my ($command, $redirect) = @_;
> my $dolog = 0;
> my $dord = 0;
> my $pid;
> @@ -2265,9 +2264,7 @@ sub build {
> # Run old config regardless, to enforce min configurations
> make_oldconfig;
>
> -$redirect = "$buildlog";
> -my $build_ret = run_command "$make $build_options";
> -undef $redirect;
> +my $build_ret = run_command "$make $build_options", $buildlog;
>
> if (defined($post_build)) {
> # Because a post build may change the kernel version
> @@ -2360,9 +2357,7 @@ sub child_run_test {
> $poweroff_on_error = 0;
> $die_on_failure = 1;
>
> -$redirect = "$testlog";
> -run_command $run_test or $failed = 1;
> -undef $redirect;
> +run_command $run_test, $testlog or $failed = 1;
>
> exit $failed;
> }
> --
> 1.8.5.3
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.13 000/172] 3.13.6-stable review
At Tue, 4 Mar 2014 12:01:24 -0800, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.13.6 release. > There are 172 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Mar 6 20:02:29 UTC 2014. > Anything received after that time might be too late. 3.10.33-rc1 and 3.13.6-rc1 passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] ktest: run make mrproper not only for OUTPUT_DIR but also for BUILD_DIR to avoid build failure
At Sun, 2 Mar 2014 08:29:16 -0500,
Steven Rostedt wrote:
>
> On Sun, 02 Mar 2014 21:23:36 +0900
> Satoru Takeuchi wrote:
>
> > From: Satoru Takeuchi
> >
> > Build failure hapens with the following log if BUILD_DIR is dirty.
>
> If you want to do make mrproper in the BUILD_DIR, add the command to
> PRE_BUILD or something. I have TAGS in my BUILD_DIRs and this will
> remove them for me. I can't accept this change.
>
> I've noticed that there's a bug in the Linux make system that causes
> the O=.. builds to fail because somehow the source directory got dirty.
> We need to figure out what that bug is.
I see. So what I should fix is kbuild system.
Thanks,
Satoru
>
> Thanks,
>
> -- Steve
>
>
> >
> > ===
> > ...
> > RUNNING TEST 1 of 1 with option build olddefconfig
> >
> > make O=/home/sat/ktest/output mrproper ... CLEAN arch/x86/tools
> > CLEAN scripts/basic
> > CLEAN scripts/kconfig
> > CLEAN include/config include/generated arch/x86/include/generated
> > CLEAN .config.old include/generated/uapi/linux/version.h
> > SUCCESS
> > ...
> > make O=/home/sat/ktest/output -j8 ... GEN
> > /home/sat/ktest/output/Makefile
> > ...
> > Using /home/sat/src/test-linux-stable/linux-stable as source for kernel
> > /home/sat/src/test-linux-stable/linux-stable is not clean, please run
> > 'make mrproper'
> > in the '/home/sat/src/test-linux-stable/linux-stable' directory.
> > make[1]: *** [prepare3] Error 1
> > make[1]: *** Waiting for unfinished jobs
> > HOSTLD arch/x86/tools/relocs
> > make[1]: *** wait: No child processes. Stop.
> > make: *** [sub-make] Error 2
> > FAILED!
> > CRITICAL FAILURE... failed build
> > ===
> >
> > To avoid this problem, it's necessary to run make mrproper not only
> > for OUTPUT_DIR, but also for BUILD_DIR.
> >
> > Signed-off-by: Satoru Takeuchi
> > Cc: Steven Rostedt
> >
> > ---
> > tools/testing/ktest/ktest.pl | 16 +---
> > 1 file changed, 9 insertions(+), 7 deletions(-)
> >
> > diff --git a/tools/testing/ktest/ktest.pl b/tools/testing/ktest/ktest.pl
> > index f731ef6..1169b2a 100755
> > --- a/tools/testing/ktest/ktest.pl
> > +++ b/tools/testing/ktest/ktest.pl
> > @@ -120,6 +120,7 @@ my $syslinux;
> > my $syslinux_path;
> > my $syslinux_label;
> > my $target;
> > +my $makecmd;
> > my $make;
> > my $pre_install;
> > my $post_install;
> > @@ -2198,6 +2199,11 @@ sub load_force_config {
> > close IN;
> > }
> >
> > +sub mrproper {
> > +run_command "$makecmd mrproper" or dodie "make mrproper for $builddir";
> > +run_command "$make mrproper" or dodie "make mrproper for $outputdir";
> > +}
> > +
> > sub build {
> > my ($type) = @_;
> >
> > @@ -2235,17 +2241,13 @@ sub build {
> > if (!$noclean) {
> > run_command "mv $output_config $outputdir/config_temp" or
> > dodie "moving .config";
> > -
> > - run_command "$make mrproper" or dodie "make mrproper";
> > -
> > + mrproper;
> > run_command "mv $outputdir/config_temp $output_config" or
> > dodie "moving config_temp";
> > }
> > -
> > } elsif (!$noclean) {
> > unlink "$output_config";
> > - run_command "$make mrproper" or
> > - dodie "make mrproper";
> > + mrproper;
> > }
> >
> > # add something to distinguish this build
> > @@ -3996,7 +3998,7 @@ for (my $i = 1; $i <= $opt{"NUM_TESTS"}; $i++) {
> >
> > undef %force_config;
> >
> > -my $makecmd = set_test_option("MAKE_CMD", $i);
> > +$makecmd = set_test_option("MAKE_CMD", $i);
> >
> > $outputdir = set_test_option("OUTPUT_DIR", $i);
> > $builddir = set_test_option("BUILD_DIR", $i);
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] ktest: run make mrproper not only for OUTPUT_DIR but also for BUILD_DIR to avoid build failure
From: Satoru Takeuchi
Build failure hapens with the following log if BUILD_DIR is dirty.
===
...
RUNNING TEST 1 of 1 with option build olddefconfig
make O=/home/sat/ktest/output mrproper ... CLEAN arch/x86/tools
CLEAN scripts/basic
CLEAN scripts/kconfig
CLEAN include/config include/generated arch/x86/include/generated
CLEAN .config.old include/generated/uapi/linux/version.h
SUCCESS
...
make O=/home/sat/ktest/output -j8 ... GEN /home/sat/ktest/output/Makefile
...
Using /home/sat/src/test-linux-stable/linux-stable as source for kernel
/home/sat/src/test-linux-stable/linux-stable is not clean, please run 'make
mrproper'
in the '/home/sat/src/test-linux-stable/linux-stable' directory.
make[1]: *** [prepare3] Error 1
make[1]: *** Waiting for unfinished jobs
HOSTLD arch/x86/tools/relocs
make[1]: *** wait: No child processes. Stop.
make: *** [sub-make] Error 2
FAILED!
CRITICAL FAILURE... failed build
===
To avoid this problem, it's necessary to run make mrproper not only
for OUTPUT_DIR, but also for BUILD_DIR.
Signed-off-by: Satoru Takeuchi
Cc: Steven Rostedt
---
tools/testing/ktest/ktest.pl | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/tools/testing/ktest/ktest.pl b/tools/testing/ktest/ktest.pl
index f731ef6..1169b2a 100755
--- a/tools/testing/ktest/ktest.pl
+++ b/tools/testing/ktest/ktest.pl
@@ -120,6 +120,7 @@ my $syslinux;
my $syslinux_path;
my $syslinux_label;
my $target;
+my $makecmd;
my $make;
my $pre_install;
my $post_install;
@@ -2198,6 +2199,11 @@ sub load_force_config {
close IN;
}
+sub mrproper {
+run_command "$makecmd mrproper" or dodie "make mrproper for $builddir";
+run_command "$make mrproper" or dodie "make mrproper for $outputdir";
+}
+
sub build {
my ($type) = @_;
@@ -2235,17 +2241,13 @@ sub build {
if (!$noclean) {
run_command "mv $output_config $outputdir/config_temp" or
dodie "moving .config";
-
- run_command "$make mrproper" or dodie "make mrproper";
-
+ mrproper;
run_command "mv $outputdir/config_temp $output_config" or
dodie "moving config_temp";
}
-
} elsif (!$noclean) {
unlink "$output_config";
- run_command "$make mrproper" or
- dodie "make mrproper";
+ mrproper;
}
# add something to distinguish this build
@@ -3996,7 +3998,7 @@ for (my $i = 1; $i <= $opt{"NUM_TESTS"}; $i++) {
undef %force_config;
-my $makecmd = set_test_option("MAKE_CMD", $i);
+$makecmd = set_test_option("MAKE_CMD", $i);
$outputdir = set_test_option("OUTPUT_DIR", $i);
$builddir = set_test_option("BUILD_DIR", $i);
--
1.8.5.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] ktest: add 2nd parameter of run_command() to set the redirect target file
From: Satoru Takeuchi
If we'd like to set the redirect target file of run_command(),
we should define $redirect before calling this function and should undef it
after calling this function. Since it's user-unfriendly, add 2nd parameter of
run_command() for this purpose.
Signed-off-by: Satoru Takeuchi
Cc: Steven Rostedt
---
tools/testing/ktest/ktest.pl | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/tools/testing/ktest/ktest.pl b/tools/testing/ktest/ktest.pl
index 4063156..f731ef6 100755
--- a/tools/testing/ktest/ktest.pl
+++ b/tools/testing/ktest/ktest.pl
@@ -149,7 +149,6 @@ my $bisect_ret_abort;
my $bisect_ret_default;
my $in_patchcheck = 0;
my $run_test;
-my $redirect;
my $buildlog;
my $testlog;
my $dmesg;
@@ -1529,7 +1528,7 @@ sub fail {
}
sub run_command {
-my ($command) = @_;
+my ($command, $redirect) = @_;
my $dolog = 0;
my $dord = 0;
my $pid;
@@ -2265,9 +2264,7 @@ sub build {
# Run old config regardless, to enforce min configurations
make_oldconfig;
-$redirect = "$buildlog";
-my $build_ret = run_command "$make $build_options";
-undef $redirect;
+my $build_ret = run_command "$make $build_options", $buildlog;
if (defined($post_build)) {
# Because a post build may change the kernel version
@@ -2360,9 +2357,7 @@ sub child_run_test {
$poweroff_on_error = 0;
$die_on_failure = 1;
-$redirect = "$testlog";
-run_command $run_test or $failed = 1;
-undef $redirect;
+run_command $run_test, $testlog or $failed = 1;
exit $failed;
}
--
1.8.5.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ktest: Set CLOSE_CONSOLE_SIGNAL in the kvm.conf
At Tue, 25 Feb 2014 21:21:18 -0500,
MUNEDA Takahiro wrote:
>
> On Mon, 24 Feb 2014 09:30:39 -0500,
> Steven Rostedt wrote:
>
> > On Sun, 23 Feb 2014 10:19:28 +0900
> > Satoru Takeuchi wrote:
> >
> >> From: Satoru Takeuchi
> >>
> >> As mentioned at commit 5a5d8e48449, we can't terminate 'virsh console'
> >> with the default signal(INT). So it's better to set CLOSE_CONSOLE_SIGNAL
> >> in the kvm.conf.
> >>
> >> Signed-off-by: Satoru Takeuchi
> >> Cc: Steven Rostedt
> >> ---
> >> tools/testing/ktest/examples/kvm.conf | 4
> >> 1 file changed, 4 insertions(+)
> >>
> >> diff --git a/tools/testing/ktest/examples/kvm.conf
> >> b/tools/testing/ktest/examples/kvm.conf
> >> index 831c7c5..40356f7 100644
> >> --- a/tools/testing/ktest/examples/kvm.conf
> >> +++ b/tools/testing/ktest/examples/kvm.conf
> >> @@ -10,6 +10,10 @@ MACHINE = Guest
> >> # Use virsh to read the serial console of the guest
> >> CONSOLE = virsh console ${MACHINE}
> >>
> >> +# Use SIGILL to terminate virsh console. We can't kill virsh console
> >> +# by the default signal, SIGINT.
> >> +CLOSE_CONSOLE_SIGNAL = KILL
> >> +
> >
> > Thanks, I'll add this to my 3.15 queue.
>
> Hmm, it seems that we need a following patch as well.
> Or, please merge with the orignal patch.
>
> Thanks,
> Takahiro
>
> ==
> From a1c7b948c47a6ea7b74225bf5698fdfb7199726a Mon Sep 17 00:00:00 2001
> From: MUNEDA Takahiro
> Date: Tue, 25 Feb 2014 15:32:35 -0500
> Subject: [PATCH] ktest: Fixes a trivial typo
>
> Signed-off-by: MUNEDA Takahiro
> Cc: Satoru Takeuchi
> Cc: Steven Rostedt
>
> ---
> tools/testing/ktest/examples/kvm.conf | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/testing/ktest/examples/kvm.conf
> b/tools/testing/ktest/examples/kvm.conf
> index 40356f7..fbc134f 100644
> --- a/tools/testing/ktest/examples/kvm.conf
> +++ b/tools/testing/ktest/examples/kvm.conf
> @@ -10,7 +10,7 @@ MACHINE = Guest
> # Use virsh to read the serial console of the guest
> CONSOLE = virsh console ${MACHINE}
> -# Use SIGILL to terminate virsh console. We can't kill virsh console
> +# Use SIGKILL to terminate virsh console. We can't kill virsh console
Oops, it's a completely the different signal. Thanks Takahiro.
Satoru
> # by the default signal, SIGINT.
> CLOSE_CONSOLE_SIGNAL = KILL
> --
> 1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ktest: Set CLOSE_CONSOLE_SIGNAL in the kvm.conf
From: Satoru Takeuchi
As mentioned at commit 5a5d8e48449, we can't terminate 'virsh console'
with the default signal(INT). So it's better to set CLOSE_CONSOLE_SIGNAL
in the kvm.conf.
Signed-off-by: Satoru Takeuchi
Cc: Steven Rostedt
---
tools/testing/ktest/examples/kvm.conf | 4
1 file changed, 4 insertions(+)
diff --git a/tools/testing/ktest/examples/kvm.conf
b/tools/testing/ktest/examples/kvm.conf
index 831c7c5..40356f7 100644
--- a/tools/testing/ktest/examples/kvm.conf
+++ b/tools/testing/ktest/examples/kvm.conf
@@ -10,6 +10,10 @@ MACHINE = Guest
# Use virsh to read the serial console of the guest
CONSOLE = virsh console ${MACHINE}
+# Use SIGILL to terminate virsh console. We can't kill virsh console
+# by the default signal, SIGINT.
+CLOSE_CONSOLE_SIGNAL = KILL
+
#*#
# This part is the same as test.conf #
#*#
--
1.8.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.13 00/99] 3.13.5-stable review
At Thu, 20 Feb 2014 15:51:55 -0800, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.13.5 release. > There are 99 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sat Feb 22 23:51:00 UTC 2014. > Anything received after that time might be too late. All 3.4.82-rc1, 3.10.32-rc1, 3.12.13-rc1, and 3.13.5-rc1 passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru Takeuchi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.13 00/40] 3.13.4-stable review
Hi Greg, At Tue, 18 Feb 2014 14:47:01 -0800, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.13.4 release. > There are 40 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Feb 20 22:44:22 UTC 2014. > Anything received after that time might be too late. All 3.13.4-rc1, 3.12.12-rc1, 3.10.31-rc1, and 3.4.81-rc1 passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.4 00/12] 3.4.78-stable review
At Sat, 25 Jan 2014 19:05:03 -0800, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.4.78 release. > There are 12 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Tue Jan 28 03:04:41 UTC 2014. > Anything received after that time might be too late. This kernel passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.12 00/27] 3.12.9-stable review
At Thu, 23 Jan 2014 11:06:37 -0800,
Greg Kroah-Hartman wrote:
>
> This is the start of the stable review cycle for the 3.12.9 release.
> There are 27 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat Jan 25 19:06:36 UTC 2014.
> Anything received after that time might be too late.
I reviewed the following patches and they look good to me.
> Geert Uytterhoeven
> mm: Make {,set}page_address() static inline if WANT_PAGE_VIRTUAL
...
> Eric W. Biederman
> vfs: In d_path don't call d_dname on a mount point
This kernel also passed my test.
- Test Cases:
- Build this kernel.
- Boot this kernel.
- Build the latest mainline kernel with this kernel.
- Test Tool:
https://github.com/satoru-takeuchi/test-linux-stable
- Test Result (kernel .config, ktest config and test log):
http://satoru-takeuchi.org/test-linux-stable/results/-.xz
- Build Environment:
- OS: Debian Jessy x86_64
- CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4
- memory: 8GB
- Test Target Environment:
- Debian Jessy x86_64 (KVM guest on the Build Environment)
- # of vCPU: 2
- memory: 2GB
Thanks,
Satoru
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.10 00/23] 3.10.28-stable review
At Thu, 23 Jan 2014 10:39:33 -0800,
Greg Kroah-Hartman wrote:
>
> This is the start of the stable review cycle for the 3.10.28 release.
> There are 23 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat Jan 25 18:38:43 UTC 2014.
> Anything received after that time might be too late.
I reviewed the following patches and they look good to me.
> Geert Uytterhoeven
> mm: Make {,set}page_address() static inline if WANT_PAGE_VIRTUAL
...
> Eric W. Biederman
> vfs: In d_path don't call d_dname on a mount point
> Jianguo Wu
> mm/memory-failure.c: recheck PageHuge() after hugetlb page migrate
> successfully
This kernel also passed my test.
- Test Cases:
- Build this kernel.
- Boot this kernel.
- Build the latest mainline kernel with this kernel.
- Test Tool:
https://github.com/satoru-takeuchi/test-linux-stable
- Test Result (kernel .config, ktest config and test log):
http://satoru-takeuchi.org/test-linux-stable/results/-.xz
- Build Environment:
- OS: Debian Jessy x86_64
- CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4
- memory: 8GB
- Test Target Environment:
- Debian Jessy x86_64 (KVM guest on the Build Environment)
- # of vCPU: 2
- memory: 2GB
Thanks,
Satoru
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.12 00/77] 3.12.8-stable review
At Mon, 13 Jan 2014 16:27:21 -0800, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.12.8 release. > There are 77 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Jan 16 00:27:35 UTC 2014. > Anything received after that time might be too late. 3.4.77-rc1, 3.10.27-rc1, and 3.12.8-rc1 passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.12 000/118] 3.12.6-stable review
At Wed, 18 Dec 2013 13:10:37 -0800, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.12.6 release. > There are 118 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Fri Dec 20 21:12:03 UTC 2013. > Anything received after that time might be too late. All 3.4.75-rc1, 3.10.25-rc1, and 3.12.6-rc1 can be built and boot without any problem. Building a kernel with these kernels also works fine. - test tool: https://github.com/satoru-takeuchi/test-linux-stable - test results(kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/- - Build Machine: debian jessy x86_64 CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 memory: 8GB - Test machine: debian jessy x86_64(KVM guest on the Build Machine) vCPU: x2 memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.12 00/62] 3.12.5-stable review
At Tue, 10 Dec 2013 00:00:31 -0800, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.12.5 release. > There are 62 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Dec 12 08:00:42 UTC 2013. > Anything received after that time might be too late. This kernel can be built and boot without any problem. Building a kernel with this kernel also works fine. - test tool: https://github.com/satoru-takeuchi/test-linux-stable - test results(kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/3.12.5-rc1-2013-12-12_00:24:11+09:00 - Build Machine: debian jessy x86_64 CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 memory: 8GB - Test machine: debian jessy x86_64(KVM guest on the Build Machine) vCPU: x2 memory: 2GB I reviewed the following patches and it looks good to me. ... > Tom Gundersen > Input: mousedev - allow disabling even without CONFIG_EXPERT > > Tom Gundersen > Input: allow deselecting serio drivers even without CONFIG_EXPERT ... > H. Peter Anvin > x86-64, build: Always pass in -mno-sse ... > Konrad Rzeszutek Wilk > cpuidle: Check for dev before deregistering it. Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.10 00/52] 3.10.24-stable review
At Tue, 10 Dec 2013 00:00:33 -0800,
Greg Kroah-Hartman wrote:
>
> This is the start of the stable review cycle for the 3.10.24 release.
> There are 52 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Thu Dec 12 07:59:40 UTC 2013.
> Anything received after that time might be too late.
This kernel can be built and boot without any problem.
Building a kernel with this kernel also works fine.
- test tool:
https://github.com/satoru-takeuchi/test-linux-stable
- test results(kernel .config, ktest config and test log):
http://satoru-takeuchi.org/test-linux-stable/results/3.10.24-rc1-2013-12-12_00:08:47+09:00
- Build Machine: debian jessy x86_64
CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4
memory: 8GB
- Test machine: debian jessy x86_64(KVM guest on the Build Machine)
vCPU: x2
memory: 2GB
I reviewed the following patches and it looks good to me.
> Tom Gundersen
> Input: mousedev - allow disabling even without CONFIG_EXPERT
>
> Tom Gundersen
> Input: allow deselecting serio drivers even without CONFIG_EXPERT
...
> H. Peter Anvin
> x86-64, build: Always pass in -mno-sse
> can: sja1000: fix {pre,post}_irq() handling and IRQ handler return value
Thanks,
Satoru
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.4 00/25] 3.4.74-stable review
At Tue, 10 Dec 2013 00:00:08 -0800, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.4.74 release. > There are 25 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Dec 12 07:59:15 UTC 2013. > Anything received after that time might be too late. This kernel can be built and boot without any problem. Building a kernel with this kernel also works fine. - test tool: https://github.com/satoru-takeuchi/test-linux-stable - test results(kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/3.4.74-rc1-2013-12-11_23:52:06+09:00 - Build Machine: debian jessy x86_64 CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 memory: 8GB - Test machine: debian jessy x86_64(KVM guest on the Build Machine) vCPU: x2 memory: 2GB I reviewed the following patches and it looks good to me. > Tom Gundersen > Input: mousedev - allow disabling even without CONFIG_EXPERT > > Tom Gundersen > Input: allow deselecting serio drivers even without CONFIG_EXPERT Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.4 00/32] 3.4.73-stable review
At Fri, 6 Dec 2013 13:52:10 -0800, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.4.73 release. > There are 32 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun Dec 8 21:49:13 UTC 2013. > Anything received after that time might be too late. All 3.4.73-rc1, 3.10.23-rc1, and 3.12.4-rc1 can be built and boot without any problem. Building kernels with these kernels also work fine. - [NEW] test tool: https://github.com/satoru-takeuchi/test-linux-stable - [NEW] test results(kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/- - Build Machine: debian jessy x86_64 CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 memory: 8GB - Test machine: debian jessy x86_64(KVM guest on the Build Machine) vCPU: x2 memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.12 000/212] 3.12.3-stable review
At Mon, 2 Dec 2013 11:13:11 -0800, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.12.3 release. > There are 212 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed Dec 4 19:11:18 UTC 2013. > Anything received after that time might be too late. This kernel can be built and boot without any problem. Building a kernel with this kernel also works fine. - Build Machine: debian jessy x86_64 CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 memory: 8GB - Test machine: debian jessy x86_64(KVM guest on the Build Machine) vCPU: x2 memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.10 000/173] 3.10.22-stable review
At Mon, 2 Dec 2013 11:09:43 -0800, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.10.22 release. > There are 173 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed Dec 4 19:10:16 UTC 2013. > Anything received after that time might be too late. This kernel can be built and boot without any problem. Building a kernel with this kernel also works fine. - Build Machine: debian jessy x86_64 CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 memory: 8GB - Test machine: debian jessy x86_64(KVM guest on the Build Machine) vCPU: x2 memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.4 00/60] 3.4.72-stable review
At Mon, 2 Dec 2013 11:05:41 -0800, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.4.72 release. > There are 60 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed Dec 4 19:01:45 UTC 2013. > Anything received after that time might be too late. This kernel can be built and boot without any problem. Building a kernel with this kernel also works fine. - Build Machine: debian jessy x86_64 CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 memory: 8GB - Test machine: debian jessy x86_64(KVM guest on the Build Machine) vCPU: x2 memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
