linux-next stats (Was: Linux 3.13-rc1 is out)
On Fri, 22 Nov 2013 12:36:37 -0800 Linus Torvalds wrote: > > Talking about mistakes... I suspect it was a mistake to have that > extra week before the merge window opened, and I probably should just > have done a 3.12-rc8 instead. Because the linux-next statistics look > suspicious, and we had extra stuff show up there not just in that > first week. Clearly people took that "let's have an extra week of > merge window" and extrapolated it a bit too much. Oh, well. Live and > learn. As usual, the executive friendly graph is at http://neuling.org/linux-next-size.html :-) (No merge commits counted, next-20131105 was the linux-next based on v3.12) Commits in v3.13-rc1 (relative to v3.12): 10518 (v3.12-rc11:9474) Commits in next-20131105: 9029 (next-20130903: 8891) Commits with the same SHA1:7979 ( 7991) Commits with the same patch_id: 621 (1) (472) Commits with the same subject line: 70 (1) ( 70) (1) not counting those in the lines above. So commits in -rc1 that were in next-20131105: 867082.4% (8533 90.1%) Commits in -rc1 that were not in next-20131105: 184817.6% ( 9419.9%) So worse than last time, probably because of the 1 week delay. [Aside: if I use next-2013 as a base (when Linus' starting doing merges in earnest), the stats look like this: Commits in next-2013: 9906 Commits with the same SHA1:9156 Commits with the same patch_id: 354 (1) Commits with the same subject line: 41 (1) So commits in -rc1 that were in next-2013: 955190.8% Commits in -rc1 that were not in next-20131105: 967 9.2% So, much more in line with previous releases. ] Some breakdown of the list of extra commits (relative to next-20131105) in -rc1: Top ten first word of commit summary: 337 drm 115 btrfs 83 perf 68 alsa 50 asoc 49 arm 46 net 31 powerpc 27 netfilter 27 acpi Top ten authors: 66 Ben Skeggs 63 Takashi Iwai 63 Al Viro 46 Alex Deucher 39 Ben Widawsky 33 Josef Bacik 31 Johannes Berg 29 J. Bruce Fields 29 Dan Carpenter 27 Peter Zijlstra Top ten commiters: 195 David S. Miller 117 Chris Mason 95 Daniel Vetter 94 Al Viro 86 Ben Skeggs 82 Arnaldo Carvalho de Melo 74 Alex Deucher 69 Takashi Iwai 53 Dave Airlie 52 Mark Brown There are also 358 commits in next-20131105 that didn't make it into v3.13-rc1. Top ten first word of commit summary: 51 arm 40 crypto 21 block 11 x86 11 ocfs2 11 dm 10 ceph 10 bluetooth 9 iov_iter 9 9p Top ten authors: 27 Kent Overstreet 22 Dave Kleikamp 19 Andrew Morton 9 Zach Brown 9 Denis Carikli 8 Geyslan G. Bem 7 Sachin Kamat 7 Kees Cook 7 Alex Porosanu 6 Yan, Zheng Some of Andrew's patches are fixes for other patches in his tree (and have been merged into those). Top ten commiters: 93 Stephen Rothwell 48 Herbert Xu 33 Dave Kleikamp 30 Jens Axboe 27 Shawn Guo 17 Kukjin Kim 11 Mauro Carvalho Chehab 10 Jason Wessel 9 Sage Weil 9 Eric Van Hensbergen Those commits by me are from the quilt series (mainly Andrew's mmotm tree). -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpzfrMCF2C0m.pgp Description: PGP signature
linux-next stats (Was: Linux 3.13-rc1 is out)
On Fri, 22 Nov 2013 12:36:37 -0800 Linus Torvalds torva...@linux-foundation.org wrote: Talking about mistakes... I suspect it was a mistake to have that extra week before the merge window opened, and I probably should just have done a 3.12-rc8 instead. Because the linux-next statistics look suspicious, and we had extra stuff show up there not just in that first week. Clearly people took that let's have an extra week of merge window and extrapolated it a bit too much. Oh, well. Live and learn. As usual, the executive friendly graph is at http://neuling.org/linux-next-size.html :-) (No merge commits counted, next-20131105 was the linux-next based on v3.12) Commits in v3.13-rc1 (relative to v3.12): 10518 (v3.12-rc11:9474) Commits in next-20131105: 9029 (next-20130903: 8891) Commits with the same SHA1:7979 ( 7991) Commits with the same patch_id: 621 (1) (472) Commits with the same subject line: 70 (1) ( 70) (1) not counting those in the lines above. So commits in -rc1 that were in next-20131105: 867082.4% (8533 90.1%) Commits in -rc1 that were not in next-20131105: 184817.6% ( 9419.9%) So worse than last time, probably because of the 1 week delay. [Aside: if I use next-2013 as a base (when Linus' starting doing merges in earnest), the stats look like this: Commits in next-2013: 9906 Commits with the same SHA1:9156 Commits with the same patch_id: 354 (1) Commits with the same subject line: 41 (1) So commits in -rc1 that were in next-2013: 955190.8% Commits in -rc1 that were not in next-20131105: 967 9.2% So, much more in line with previous releases. ] Some breakdown of the list of extra commits (relative to next-20131105) in -rc1: Top ten first word of commit summary: 337 drm 115 btrfs 83 perf 68 alsa 50 asoc 49 arm 46 net 31 powerpc 27 netfilter 27 acpi Top ten authors: 66 Ben Skeggs bske...@redhat.com 63 Takashi Iwai ti...@suse.de 63 Al Viro v...@zeniv.linux.org.uk 46 Alex Deucher alexander.deuc...@amd.com 39 Ben Widawsky benjamin.widaw...@intel.com 33 Josef Bacik jba...@fusionio.com 31 Johannes Berg johannes.b...@intel.com 29 J. Bruce Fields bfie...@redhat.com 29 Dan Carpenter dan.carpen...@oracle.com 27 Peter Zijlstra pet...@infradead.org Top ten commiters: 195 David S. Miller da...@davemloft.net 117 Chris Mason chris.ma...@fusionio.com 95 Daniel Vetter daniel.vet...@ffwll.ch 94 Al Viro v...@zeniv.linux.org.uk 86 Ben Skeggs bske...@redhat.com 82 Arnaldo Carvalho de Melo a...@redhat.com 74 Alex Deucher alexander.deuc...@amd.com 69 Takashi Iwai ti...@suse.de 53 Dave Airlie airl...@redhat.com 52 Mark Brown broo...@linaro.org There are also 358 commits in next-20131105 that didn't make it into v3.13-rc1. Top ten first word of commit summary: 51 arm 40 crypto 21 block 11 x86 11 ocfs2 11 dm 10 ceph 10 bluetooth 9 iov_iter 9 9p Top ten authors: 27 Kent Overstreet k...@daterainc.com 22 Dave Kleikamp dave.kleik...@oracle.com 19 Andrew Morton a...@linux-foundation.org 9 Zach Brown z...@zabbo.net 9 Denis Carikli de...@eukrea.com 8 Geyslan G. Bem geys...@gmail.com 7 Sachin Kamat sachin.ka...@linaro.org 7 Kees Cook keesc...@chromium.org 7 Alex Porosanu alexandru.poros...@freescale.com 6 Yan, Zheng zheng.z@intel.com Some of Andrew's patches are fixes for other patches in his tree (and have been merged into those). Top ten commiters: 93 Stephen Rothwell s...@canb.auug.org.au 48 Herbert Xu herb...@gondor.apana.org.au 33 Dave Kleikamp dave.kleik...@oracle.com 30 Jens Axboe ax...@kernel.dk 27 Shawn Guo shawn@linaro.org 17 Kukjin Kim kgene@samsung.com 11 Mauro Carvalho Chehab m.che...@samsung.com 10 Jason Wessel jason.wes...@windriver.com 9 Sage Weil s...@inktank.com 9 Eric Van Hensbergen eri...@gmail.com Those commits by me are from the quilt series (mainly Andrew's mmotm tree). -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpzfrMCF2C0m.pgp Description: PGP signature
Re: Linux 3.13-rc1 is out
James Cloos jhcloos.com> writes:
>
> This combination:
>
> # CONFIG_SYSTEM_TRUSTED_KEYRING is not set
> CONFIG_TRUSTED_KEYS=m
>
> (acquired by oldconfig and N to system keyring)
>
> fails with:
>
> Pass 2
> CC [M] crypto/asymmetric_keys/x509_rsakey-asn1.o
> CC [M] crypto/asymmetric_keys/x509_cert_parser.o
> CC [M] crypto/asymmetric_keys/x509_public_key.o
> crypto/asymmetric_keys/x509_public_key.c: In
function ‘x509_key_preparse’:
> crypto/asymmetric_keys/x509_public_key.c:237:35:
error: ‘system_trusted_keyring’
> undeclared (first use in this function)
>ret = x509_validate_trust(cert, system_trusted_keyring);
>^
> crypto/asymmetric_keys/x509_public_key.c:237:35: note: each undeclared
identifier is reported
> only once for each function it appears in
> make[2]: *** [crypto/asymmetric_keys/x509_public_key.o] Error 1
> make[1]: *** [crypto/asymmetric_keys] Error 2
> make: *** [crypto] Error 2
>
> Perhaps include/keys/system_keyring.h should have a definition for
> system_trusted_keyring in the #ifndef CONFIG_SYSTEM_TRUSTED_KEYRING
> case (which may entail just removing the #ifdef).
>
> Commits b56e5a17b6b9acd1 and 09fbc47373826d67 are relevant.
>
> -JimC
I have same problem too.
Using following band-aid patch (though I'm not sure it's correct), build
is ok;
--- a/security/integrity/digsig.c
+++ b/security/integrity/digsig.c
@@ -67,6 +67,7 @@ int integrity_digsig_verify(const unsigned int id, const
char *sig, int siglen,
return -EOPNOTSUPP;
}
+#ifdef CONFIG_INTEGRITY_ASYMMETRIC_KEYS
int integrity_init_keyring(const unsigned int id)
{
const struct cred *cred = current_cred();
@@ -84,3 +85,4 @@ int integrity_init_keyring(const unsigned int id)
keyring_name[id], PTR_ERR(keyring[id]));
return 0;
}
+#endif
But, I encounter another build issue;
CC crypto/asymmetric_keys/x509_public_key.o
crypto/asymmetric_keys/x509_public_key.c: In function
‘x509_key_preparse’:
crypto/asymmetric_keys/x509_public_key.c:237:35: error:
‘system_trusted_keyring’ undeclared (first use in this function)
ret = x509_validate_trust(cert, system_trusted_keyring);
^
crypto/asymmetric_keys/x509_public_key.c:237:35: note: each undeclared
identifier is reported only once for each function it appears in
make[2]: *** [crypto/asymmetric_keys/x509_public_key.o] Error 1
make[1]: *** [crypto/asymmetric_keys] Error 2
make: *** [crypto] Error 2
Looks like it's caused by following combination...
# CONFIG_SYSTEM_TRUSTED_KEYRING is not set
CONFIG_X509_CERTIFICATE_PARSER=y
Jongman Heo
--
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: Linux 3.13-rc1 is out
This combination: # CONFIG_SYSTEM_TRUSTED_KEYRING is not set CONFIG_TRUSTED_KEYS=m (acquired by oldconfig and N to system keyring) fails with: Pass 2 CC [M] crypto/asymmetric_keys/x509_rsakey-asn1.o CC [M] crypto/asymmetric_keys/x509_cert_parser.o CC [M] crypto/asymmetric_keys/x509_public_key.o crypto/asymmetric_keys/x509_public_key.c: In function ‘x509_key_preparse’: crypto/asymmetric_keys/x509_public_key.c:237:35: error: ‘system_trusted_keyring’ undeclared (first use in this function) ret = x509_validate_trust(cert, system_trusted_keyring); ^ crypto/asymmetric_keys/x509_public_key.c:237:35: note: each undeclared identifier is reported only once for each function it appears in make[2]: *** [crypto/asymmetric_keys/x509_public_key.o] Error 1 make[1]: *** [crypto/asymmetric_keys] Error 2 make: *** [crypto] Error 2 Perhaps include/keys/system_keyring.h should have a definition for system_trusted_keyring in the #ifndef CONFIG_SYSTEM_TRUSTED_KEYRING case (which may entail just removing the #ifdef). Commits b56e5a17b6b9acd1 and 09fbc47373826d67 are relevant. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 -- 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: Linux 3.13-rc1 is out
On Fri, Nov 22, 2013 at 4:43 PM, Matthew Garrett wrote: > > I'd sent a pull yesterday (http://lkml.org/lkml/2013/11/21/599 ) which > may have missed your cutoff, but it seems worth checking. No, it didn't miss my cutoff, and it wasn't even eaten by the gmail spam filters, but it *had* missed my normal pattern for checking that I had merged all git pull requests, which is why I had overlooked it. Pulled now (going through the allmodconfig build test before being pushed out shortly). Btw, the reason it missed my normal check is that I search for "in:inbox git pull" as a sanity check that I don't have anything pending. Now, *most* of the time I tend to catch things regardless just by virtue of reading email carefully, but when I'm busy it definitely helps if your email matches that pattern. The easiest (and most common) way to do that is to have the subject line be something like [GIT PULL] sound fixes #2 for 3.13-rc1 but there are other patterns. For example, David Miller tends to have instead a subject line like [GIT] Networking and then "Please pull" in the body of the email. So the "in:inbox git pull" thing basically catches pretty much everybody. Except for you... You use David Miller's subject line, but you don't have the "please pull" part, so your email missed my "did I pull everything that I had pending" check. For very similar reasons, for people sending me a patch, it really *really* helps if there's a "[patch]" (possibly with a n/m number pattern) in the subject line.. Or make sure you send me a git diff, because I also tend to search for the string "diff --git". Of course, the main person who sends me patches is Andrew Morton, so I mostly just search for "from:akpm" :) Linus -- 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: Linux 3.13-rc1 is out
On 11/22/2013 01:36 PM, Linus Torvalds wrote: So you had an extra week to prepare your pull requests, and if you were planning on sending it in the last two days thinking I'd close the merge window on Sunday as usual, I can only laugh derisively in your general direction, and call you bad names. Because I'm not interested in your excuses. I did warn people about this in the 3.12 release notes. As it was, there were a few people who cut it fairly close today. You know who you are. If there are pull requests I missed (due to getting caught in spam filters, or not matching my normal search patterns), and you think you sent your pull request in time but it got overlooked, ping me - because I don't have anything pending I know about, but mistakes happen. Talking about mistakes... I suspect it was a mistake to have that extra week before the merge window opened, and I probably should just have done a 3.12-rc8 instead. Because the linux-next statistics look suspicious, and we had extra stuff show up there not just in that first week. Clearly people took that "let's have an extra week of merge window" and extrapolated it a bit too much. Oh, well. Live and learn. Anyway, other than that small oddity, this was a fairly normal merge window. By patch size we had a pretty usual ~55% drivers, 18% architecture code, 9% network updates, and the rest is spread out (fs, headers, tools, documentation). Featurewise, the big ones are likely the nftables and the multi-queue block layer stuff, but depending on your interests you might find all the incremental updates to various areas interesting. There are some odd ones in there (LE mode Powerpc support..) Go forth and test, and start sending me regression fixes. And really, if you didn't send me your pull request in time, don't whine about it. Because nobody likes a whiner. 3.13-rc1 fails to boot on Samsung Series 9. 3.12.1 is fine and the last mainline kernel that worked on it was from Nov 14th. It failed to mount /boot and after doing a manually mounting it, it came up and didn't detect USB mouse. Looking at the dmesg differences in dmesg, looks like usb probe fails on USB mouse. I will start a bisect and let you know what I find. dmesg 3.13-rc1: 63.637083] PM: Adding info for usb:2-1:1.0 [ 63.637128] driver: '2-1': driver_bound: bound to device 'usb' [ 63.637136] bus: 'usb': really_probe: bound device 2-1 to driver usb [ 123.660457] usb 2-1: USB disconnect, device number 3 [ 123.660505] bus: 'usb': remove device 2-1:1.0 [ 123.660508] PM: Removing info for usb:2-1:1.0 [ 123.661718] bus: 'usb': remove device 2-1 [ 123.661724] PM: Removing info for usb:2-1 [ 125.143833] usb 2-1: new low-speed USB device number 4 using xhci_hcd [ 125.190924] usb 2-1: New USB device found, idVendor=17ef, idProduct=6019 [ 125.190928] usb 2-1: New USB device strings: Mfr=0, Product=2, SerialNumber=0 [ 125.190930] usb 2-1: Product: Lenovo Optical USB Mouse [ 125.191042] bus: 'usb': add device 2-1 [ 125.191054] PM: Adding info for usb:2-1 [ 125.191081] bus: 'usb': driver_probe_device: matched device 2-1 with driver usb [ 125.191084] bus: 'usb': really_probe: probing driver usb with device 2-1 [ 125.191097] usb 2-1: ep 0x81 - rounding interval to 64 microframes, ep desc says 80 microframes [ 125.201952] bus: 'usb': add device 2-1:1.0 [ 125.201959] PM: Adding info for usb:2-1:1.0 [ 125.202010] driver: '2-1': driver_bound: bound to device 'usb' [ 125.202019] bus: 'usb': really_probe: bound device 2-1 to driver usb dmesg 3.12.1: [5.562700] bus: 'usb': add driver usbhid [5.562790] bus: 'usb': driver_probe_device: matched device 2-1:1.0 with driv er usbhid [5.562794] bus: 'usb': really_probe: probing driver usbhid with device 2-1:1 .0 [5.575965] driver: '2-1:1.0': driver_bound: bound to device 'usbhid' [5.575971] bus: 'usb': really_probe: bound device 2-1:1.0 to driver usbhid [5.575998] usbcore: registered new interface driver usbhid [5.576000] usbhid: USB HID core driver [5.601326] input: Lenovo Optical USB Mouse as /devices/pci:00/:00:1c.4/:03:00.0/usb2/2-1/2-1:1.0/input/input6 [5.601796] hid-generic 0003:17EF:6019.0001: input,hidraw0: USB HID v1.11 Mouse [Lenovo Optical USB Mouse] on usb-:03:00.0-1/input0 [5.670722] bus: 'usb': add driver btusb [5.670736] bus: 'usb': driver_probe_device: matched device 1-1.5:1.0 with driver btusb [5.670739] bus: 'usb': really_probe: probing driver btusb with device 1-1.5:1.0 -- 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: Linux 3.13-rc1 is out
Hi Linus, I'd sent a pull yesterday (http://lkml.org/lkml/2013/11/21/599 ) which may have missed your cutoff, but it seems worth checking. -- Matthew Garrett | mj...@srcf.ucam.org -- 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/
Linux 3.13-rc1 is out
So you had an extra week to prepare your pull requests, and if you were planning on sending it in the last two days thinking I'd close the merge window on Sunday as usual, I can only laugh derisively in your general direction, and call you bad names. Because I'm not interested in your excuses. I did warn people about this in the 3.12 release notes. As it was, there were a few people who cut it fairly close today. You know who you are. If there are pull requests I missed (due to getting caught in spam filters, or not matching my normal search patterns), and you think you sent your pull request in time but it got overlooked, ping me - because I don't have anything pending I know about, but mistakes happen. Talking about mistakes... I suspect it was a mistake to have that extra week before the merge window opened, and I probably should just have done a 3.12-rc8 instead. Because the linux-next statistics look suspicious, and we had extra stuff show up there not just in that first week. Clearly people took that "let's have an extra week of merge window" and extrapolated it a bit too much. Oh, well. Live and learn. Anyway, other than that small oddity, this was a fairly normal merge window. By patch size we had a pretty usual ~55% drivers, 18% architecture code, 9% network updates, and the rest is spread out (fs, headers, tools, documentation). Featurewise, the big ones are likely the nftables and the multi-queue block layer stuff, but depending on your interests you might find all the incremental updates to various areas interesting. There are some odd ones in there (LE mode Powerpc support..) Go forth and test, and start sending me regression fixes. And really, if you didn't send me your pull request in time, don't whine about it. Because nobody likes a whiner. Shortlog of merges appended. The real shortlog is much too big to be readable, as always for rc1. Linus --- Al Viro (3): vfs updates VFS fixes vfs bits and pieces Andrew Morton (3): first patch-bomb patches patches Anton Vorontsov (1): battery updates Artem Bityutskiy (2): ubifs changes UBI changes Ben Myers (2): xfs update second xfs update Benjamin Herrenschmidt (3): powerpc updates powerpc LE updates third set of powerpc updates Benjamin LaHaise (1): aio fixes Bjorn Helgaas (2): PCI changes PCI updates Borislav Petkov (1): EDAC updates Brian Norris (1): MTD changes Bruce Fields (2): nfsd changes nfsd bugfixes Bryan Wu (1): LED subsystem changes Catalin Marinas (1): ARM64 update Chris Ball (1): MMC updates Chris Mason (2): btrfs fixes btrfs fixes Dave Airlie (3): drm updates drm regression fix DRM fixes David Miller (7): networking fixes networking updates sparc update IDE updates sparc fixes networking fixes networking fixes David Teigland (1): dlm fix Dmitry Torokhov (1): input updates Eric Paris (1): audit updates Geert Uytterhoeven (1): m68k updates Gleb Natapov (1): KVM fixes Greg KH (5): USB driver update char/misc patches driver core / sysfs patches tty/serial driver updates staging driver update Guenter Roeck (3): h8300 platform removal hwmon updates hwmon fixes Hans-Christian Egtvedt (1): AVR32 updates Helge Deller (2): parisc update parisc fixes Ingo Molnar (30): RCU updates IRQ changes leftover IRQ fixes perf updates scheduler changes timer changes x86/apic fix x86 user access changes x86 boot changes x86 build changes x86 cleanups x86 cpu changes x86 EFI changes x86/hyperv changes x86/intel-mid changes x86 iommu changes x86 RAS changes x86 mm fixlet x86 platform fixlet x86 reboot changes x86 uaccess changes x86 UV debug changes x86/trace changes core locking changes scheduler fixes two x86 fixes perf updates perf fixes irq cleanups x86 fix Jaegeuk Kim (1): f2fs updates James Bottomley (1): first round of SCSI updates James Hogan (1): metag architecture changes James Morris (1): security subsystem updates Jan Kara (1): ext[23], udf and quota fixes Jean Delvare (1): hwmon fixes and updates Jens Axboe (4): block IO core updates block driver updates second round of block driver updates block IO fixes Jiri Kosina (2): trivial tree updates HID updates Joerg Roedel (1): IOMMU updates Jonas Bonn (1): OpenRISC updates Konrad Rzeszutek Wilk (1): Xen updates Linus Walleij (2): pin control updates GPIO changes Mark Brown (3): regmap updates regulator updates spi updates Mark Salter (1): Kconfig cleanups Martin Schwidefsky (2): s390 updates second set of s390 patches Matt Turner (1): alpha updates Mauro Carvalho Chehab (3): EDAC driver updates media updates media build fixes Michal Marek (3): kbuild changes kconfig changes misc kbuild changes Michal Simek (1): microblaze updates Mike Snitzer (1): device mapper changes Mike Turquette (1): clock framework
Linux 3.13-rc1 is out
So you had an extra week to prepare your pull requests, and if you were planning on sending it in the last two days thinking I'd close the merge window on Sunday as usual, I can only laugh derisively in your general direction, and call you bad names. Because I'm not interested in your excuses. I did warn people about this in the 3.12 release notes. As it was, there were a few people who cut it fairly close today. You know who you are. If there are pull requests I missed (due to getting caught in spam filters, or not matching my normal search patterns), and you think you sent your pull request in time but it got overlooked, ping me - because I don't have anything pending I know about, but mistakes happen. Talking about mistakes... I suspect it was a mistake to have that extra week before the merge window opened, and I probably should just have done a 3.12-rc8 instead. Because the linux-next statistics look suspicious, and we had extra stuff show up there not just in that first week. Clearly people took that let's have an extra week of merge window and extrapolated it a bit too much. Oh, well. Live and learn. Anyway, other than that small oddity, this was a fairly normal merge window. By patch size we had a pretty usual ~55% drivers, 18% architecture code, 9% network updates, and the rest is spread out (fs, headers, tools, documentation). Featurewise, the big ones are likely the nftables and the multi-queue block layer stuff, but depending on your interests you might find all the incremental updates to various areas interesting. There are some odd ones in there (LE mode Powerpc support..) Go forth and test, and start sending me regression fixes. And really, if you didn't send me your pull request in time, don't whine about it. Because nobody likes a whiner. Shortlog of merges appended. The real shortlog is much too big to be readable, as always for rc1. Linus --- Al Viro (3): vfs updates VFS fixes vfs bits and pieces Andrew Morton (3): first patch-bomb patches patches Anton Vorontsov (1): battery updates Artem Bityutskiy (2): ubifs changes UBI changes Ben Myers (2): xfs update second xfs update Benjamin Herrenschmidt (3): powerpc updates powerpc LE updates third set of powerpc updates Benjamin LaHaise (1): aio fixes Bjorn Helgaas (2): PCI changes PCI updates Borislav Petkov (1): EDAC updates Brian Norris (1): MTD changes Bruce Fields (2): nfsd changes nfsd bugfixes Bryan Wu (1): LED subsystem changes Catalin Marinas (1): ARM64 update Chris Ball (1): MMC updates Chris Mason (2): btrfs fixes btrfs fixes Dave Airlie (3): drm updates drm regression fix DRM fixes David Miller (7): networking fixes networking updates sparc update IDE updates sparc fixes networking fixes networking fixes David Teigland (1): dlm fix Dmitry Torokhov (1): input updates Eric Paris (1): audit updates Geert Uytterhoeven (1): m68k updates Gleb Natapov (1): KVM fixes Greg KH (5): USB driver update char/misc patches driver core / sysfs patches tty/serial driver updates staging driver update Guenter Roeck (3): h8300 platform removal hwmon updates hwmon fixes Hans-Christian Egtvedt (1): AVR32 updates Helge Deller (2): parisc update parisc fixes Ingo Molnar (30): RCU updates IRQ changes leftover IRQ fixes perf updates scheduler changes timer changes x86/apic fix x86 user access changes x86 boot changes x86 build changes x86 cleanups x86 cpu changes x86 EFI changes x86/hyperv changes x86/intel-mid changes x86 iommu changes x86 RAS changes x86 mm fixlet x86 platform fixlet x86 reboot changes x86 uaccess changes x86 UV debug changes x86/trace changes core locking changes scheduler fixes two x86 fixes perf updates perf fixes irq cleanups x86 fix Jaegeuk Kim (1): f2fs updates James Bottomley (1): first round of SCSI updates James Hogan (1): metag architecture changes James Morris (1): security subsystem updates Jan Kara (1): ext[23], udf and quota fixes Jean Delvare (1): hwmon fixes and updates Jens Axboe (4): block IO core updates block driver updates second round of block driver updates block IO fixes Jiri Kosina (2): trivial tree updates HID updates Joerg Roedel (1): IOMMU updates Jonas Bonn (1): OpenRISC updates Konrad Rzeszutek Wilk (1): Xen updates Linus Walleij (2): pin control updates GPIO changes Mark Brown (3): regmap updates regulator updates spi updates Mark Salter (1): Kconfig cleanups Martin Schwidefsky (2): s390 updates second set of s390 patches Matt Turner (1): alpha updates Mauro Carvalho Chehab (3): EDAC driver updates media updates media build fixes Michal Marek (3): kbuild changes kconfig changes misc kbuild changes Michal Simek (1): microblaze updates Mike Snitzer (1): device mapper changes Mike Turquette (1): clock framework changes
Re: Linux 3.13-rc1 is out
Hi Linus, I'd sent a pull yesterday (http://lkml.org/lkml/2013/11/21/599 ) which may have missed your cutoff, but it seems worth checking. -- Matthew Garrett | mj...@srcf.ucam.org -- 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: Linux 3.13-rc1 is out
On 11/22/2013 01:36 PM, Linus Torvalds wrote: So you had an extra week to prepare your pull requests, and if you were planning on sending it in the last two days thinking I'd close the merge window on Sunday as usual, I can only laugh derisively in your general direction, and call you bad names. Because I'm not interested in your excuses. I did warn people about this in the 3.12 release notes. As it was, there were a few people who cut it fairly close today. You know who you are. If there are pull requests I missed (due to getting caught in spam filters, or not matching my normal search patterns), and you think you sent your pull request in time but it got overlooked, ping me - because I don't have anything pending I know about, but mistakes happen. Talking about mistakes... I suspect it was a mistake to have that extra week before the merge window opened, and I probably should just have done a 3.12-rc8 instead. Because the linux-next statistics look suspicious, and we had extra stuff show up there not just in that first week. Clearly people took that let's have an extra week of merge window and extrapolated it a bit too much. Oh, well. Live and learn. Anyway, other than that small oddity, this was a fairly normal merge window. By patch size we had a pretty usual ~55% drivers, 18% architecture code, 9% network updates, and the rest is spread out (fs, headers, tools, documentation). Featurewise, the big ones are likely the nftables and the multi-queue block layer stuff, but depending on your interests you might find all the incremental updates to various areas interesting. There are some odd ones in there (LE mode Powerpc support..) Go forth and test, and start sending me regression fixes. And really, if you didn't send me your pull request in time, don't whine about it. Because nobody likes a whiner. 3.13-rc1 fails to boot on Samsung Series 9. 3.12.1 is fine and the last mainline kernel that worked on it was from Nov 14th. It failed to mount /boot and after doing a manually mounting it, it came up and didn't detect USB mouse. Looking at the dmesg differences in dmesg, looks like usb probe fails on USB mouse. I will start a bisect and let you know what I find. dmesg 3.13-rc1: 63.637083] PM: Adding info for usb:2-1:1.0 [ 63.637128] driver: '2-1': driver_bound: bound to device 'usb' [ 63.637136] bus: 'usb': really_probe: bound device 2-1 to driver usb [ 123.660457] usb 2-1: USB disconnect, device number 3 [ 123.660505] bus: 'usb': remove device 2-1:1.0 [ 123.660508] PM: Removing info for usb:2-1:1.0 [ 123.661718] bus: 'usb': remove device 2-1 [ 123.661724] PM: Removing info for usb:2-1 [ 125.143833] usb 2-1: new low-speed USB device number 4 using xhci_hcd [ 125.190924] usb 2-1: New USB device found, idVendor=17ef, idProduct=6019 [ 125.190928] usb 2-1: New USB device strings: Mfr=0, Product=2, SerialNumber=0 [ 125.190930] usb 2-1: Product: Lenovo Optical USB Mouse [ 125.191042] bus: 'usb': add device 2-1 [ 125.191054] PM: Adding info for usb:2-1 [ 125.191081] bus: 'usb': driver_probe_device: matched device 2-1 with driver usb [ 125.191084] bus: 'usb': really_probe: probing driver usb with device 2-1 [ 125.191097] usb 2-1: ep 0x81 - rounding interval to 64 microframes, ep desc says 80 microframes [ 125.201952] bus: 'usb': add device 2-1:1.0 [ 125.201959] PM: Adding info for usb:2-1:1.0 [ 125.202010] driver: '2-1': driver_bound: bound to device 'usb' [ 125.202019] bus: 'usb': really_probe: bound device 2-1 to driver usb dmesg 3.12.1: [5.562700] bus: 'usb': add driver usbhid [5.562790] bus: 'usb': driver_probe_device: matched device 2-1:1.0 with driv er usbhid [5.562794] bus: 'usb': really_probe: probing driver usbhid with device 2-1:1 .0 [5.575965] driver: '2-1:1.0': driver_bound: bound to device 'usbhid' [5.575971] bus: 'usb': really_probe: bound device 2-1:1.0 to driver usbhid [5.575998] usbcore: registered new interface driver usbhid [5.576000] usbhid: USB HID core driver [5.601326] input: Lenovo Optical USB Mouse as /devices/pci:00/:00:1c.4/:03:00.0/usb2/2-1/2-1:1.0/input/input6 [5.601796] hid-generic 0003:17EF:6019.0001: input,hidraw0: USB HID v1.11 Mouse [Lenovo Optical USB Mouse] on usb-:03:00.0-1/input0 [5.670722] bus: 'usb': add driver btusb [5.670736] bus: 'usb': driver_probe_device: matched device 1-1.5:1.0 with driver btusb [5.670739] bus: 'usb': really_probe: probing driver btusb with device 1-1.5:1.0 -- 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: Linux 3.13-rc1 is out
On Fri, Nov 22, 2013 at 4:43 PM, Matthew Garrett mj...@srcf.ucam.org wrote: I'd sent a pull yesterday (http://lkml.org/lkml/2013/11/21/599 ) which may have missed your cutoff, but it seems worth checking. No, it didn't miss my cutoff, and it wasn't even eaten by the gmail spam filters, but it *had* missed my normal pattern for checking that I had merged all git pull requests, which is why I had overlooked it. Pulled now (going through the allmodconfig build test before being pushed out shortly). Btw, the reason it missed my normal check is that I search for in:inbox git pull as a sanity check that I don't have anything pending. Now, *most* of the time I tend to catch things regardless just by virtue of reading email carefully, but when I'm busy it definitely helps if your email matches that pattern. The easiest (and most common) way to do that is to have the subject line be something like [GIT PULL] sound fixes #2 for 3.13-rc1 but there are other patterns. For example, David Miller tends to have instead a subject line like [GIT] Networking and then Please pull in the body of the email. So the in:inbox git pull thing basically catches pretty much everybody. Except for you... You use David Miller's subject line, but you don't have the please pull part, so your email missed my did I pull everything that I had pending check. For very similar reasons, for people sending me a patch, it really *really* helps if there's a [patch] (possibly with a n/m number pattern) in the subject line.. Or make sure you send me a git diff, because I also tend to search for the string diff --git. Of course, the main person who sends me patches is Andrew Morton, so I mostly just search for from:akpm :) Linus -- 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: Linux 3.13-rc1 is out
This combination: # CONFIG_SYSTEM_TRUSTED_KEYRING is not set CONFIG_TRUSTED_KEYS=m (acquired by oldconfig and N to system keyring) fails with: Pass 2 CC [M] crypto/asymmetric_keys/x509_rsakey-asn1.o CC [M] crypto/asymmetric_keys/x509_cert_parser.o CC [M] crypto/asymmetric_keys/x509_public_key.o crypto/asymmetric_keys/x509_public_key.c: In function ‘x509_key_preparse’: crypto/asymmetric_keys/x509_public_key.c:237:35: error: ‘system_trusted_keyring’ undeclared (first use in this function) ret = x509_validate_trust(cert, system_trusted_keyring); ^ crypto/asymmetric_keys/x509_public_key.c:237:35: note: each undeclared identifier is reported only once for each function it appears in make[2]: *** [crypto/asymmetric_keys/x509_public_key.o] Error 1 make[1]: *** [crypto/asymmetric_keys] Error 2 make: *** [crypto] Error 2 Perhaps include/keys/system_keyring.h should have a definition for system_trusted_keyring in the #ifndef CONFIG_SYSTEM_TRUSTED_KEYRING case (which may entail just removing the #ifdef). Commits b56e5a17b6b9acd1 and 09fbc47373826d67 are relevant. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6 -- 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: Linux 3.13-rc1 is out
James Cloos cloos at jhcloos.com writes:
This combination:
# CONFIG_SYSTEM_TRUSTED_KEYRING is not set
CONFIG_TRUSTED_KEYS=m
(acquired by oldconfig and N to system keyring)
fails with:
Pass 2
CC [M] crypto/asymmetric_keys/x509_rsakey-asn1.o
CC [M] crypto/asymmetric_keys/x509_cert_parser.o
CC [M] crypto/asymmetric_keys/x509_public_key.o
crypto/asymmetric_keys/x509_public_key.c: In
function ‘x509_key_preparse’:
crypto/asymmetric_keys/x509_public_key.c:237:35:
error: ‘system_trusted_keyring’
undeclared (first use in this function)
ret = x509_validate_trust(cert, system_trusted_keyring);
^
crypto/asymmetric_keys/x509_public_key.c:237:35: note: each undeclared
identifier is reported
only once for each function it appears in
make[2]: *** [crypto/asymmetric_keys/x509_public_key.o] Error 1
make[1]: *** [crypto/asymmetric_keys] Error 2
make: *** [crypto] Error 2
Perhaps include/keys/system_keyring.h should have a definition for
system_trusted_keyring in the #ifndef CONFIG_SYSTEM_TRUSTED_KEYRING
case (which may entail just removing the #ifdef).
Commits b56e5a17b6b9acd1 and 09fbc47373826d67 are relevant.
-JimC
I have same problem too.
Using following band-aid patch (though I'm not sure it's correct), build
is ok;
--- a/security/integrity/digsig.c
+++ b/security/integrity/digsig.c
@@ -67,6 +67,7 @@ int integrity_digsig_verify(const unsigned int id, const
char *sig, int siglen,
return -EOPNOTSUPP;
}
+#ifdef CONFIG_INTEGRITY_ASYMMETRIC_KEYS
int integrity_init_keyring(const unsigned int id)
{
const struct cred *cred = current_cred();
@@ -84,3 +85,4 @@ int integrity_init_keyring(const unsigned int id)
keyring_name[id], PTR_ERR(keyring[id]));
return 0;
}
+#endif
But, I encounter another build issue;
CC crypto/asymmetric_keys/x509_public_key.o
crypto/asymmetric_keys/x509_public_key.c: In function
‘x509_key_preparse’:
crypto/asymmetric_keys/x509_public_key.c:237:35: error:
‘system_trusted_keyring’ undeclared (first use in this function)
ret = x509_validate_trust(cert, system_trusted_keyring);
^
crypto/asymmetric_keys/x509_public_key.c:237:35: note: each undeclared
identifier is reported only once for each function it appears in
make[2]: *** [crypto/asymmetric_keys/x509_public_key.o] Error 1
make[1]: *** [crypto/asymmetric_keys] Error 2
make: *** [crypto] Error 2
Looks like it's caused by following combination...
# CONFIG_SYSTEM_TRUSTED_KEYRING is not set
CONFIG_X509_CERTIFICATE_PARSER=y
Jongman Heo
--
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/
