kernel January 2010

kernel@lists.fedoraproject.org

19 participants
18 discussions

RFE: vhost net backport in fc13
by Michael S. Tsirkin 18 Apr '10

18 Apr '10

All, What is needed to backport vhost net accelerator to make it avaiable in fc13? The following patches from net-next (git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6.git) should apply to fedora kernel without changes, and are fairly non-intrusive: 05c2828c72c4eabf62376adfe27bd24797621f62 tun: export underlying socket 5da779c34ccff5e1e617892b6c8bd8260fb1f04c mm: export use_mm/unuse_mm to modules 3a4d5c94e959359ece6d6b55045c3f046677f55c vhost_net: a kernel-level virtio server This module is required for vhost net feature. Feature page here: https://fedoraproject.org/wiki/Features/VHostNet -- MST

2 2

ppc32 selinux mprotect diff.
by Dave Jones 31 Mar '10

31 Mar '10

We've carried this diff in Fedora for a few years now.. --- linux-2.6.26.noarch/security/selinux/hooks.c~ 2008-09-25 14:11:17.000000000 -0400 +++ linux-2.6.26.noarch/security/selinux/hooks.c 2008-09-25 14:12:17.000000000 -0400 @@ -3018,7 +3018,6 @@ static int file_map_prot_check(struct fi const struct cred *cred = current_cred(); int rc = 0; -#ifndef CONFIG_PPC32 if ((prot & PROT_EXEC) && (!file || (!shared && (prot & PROT_WRITE)))) { /* * We are making executable an anonymous mapping or a @@ -3029,7 +3028,6 @@ static int file_map_prot_check(struct fi if (rc) goto error; } -#endif if (file) { /* read access is always possible with a mapping */ @@ -3024,7 +3022,6 @@ static int selinux_file_mprotect(struct if (selinux_checkreqprot) prot = reqprot; -#ifndef CONFIG_PPC32 if ((prot & PROT_EXEC) && !(vma->vm_flags & VM_EXEC)) { rc = 0; if (vma->vm_start >= vma->vm_mm->start_brk && @@ -3049,7 +3046,6 @@ static int selinux_file_mprotect(struct if (rc) return rc; } -#endif return file_map_prot_check(vma->vm_file, prot, vma->vm_flags&VM_SHARED); } This needs a fixed toolchain, and a userspace rebuild to work. For these reasons, it's had difficulty getting upstream. Fedora has a new enough toolchain, and has been rebuilt, so we don't need the ifdefs. Other distros don't/haven't, and this patch would break them if pushed upstream. Could we do something like the (untested) diff below instead, which might be more palatable to upstream, allowing us to stop carrying it ? Dave diff --git a/security/selinux/Kconfig b/security/selinux/Kconfig index bca1b74..83a9675 100644 --- a/security/selinux/Kconfig +++ b/security/selinux/Kconfig @@ -131,3 +131,10 @@ config SECURITY_SELINUX_POLICYDB_VERSION_MAX_VALUE installed under /etc/selinux/$SELINUXTYPE/policy, where SELINUXTYPE is defined in your /etc/selinux/config. +config SELINUX_NEW_ENOUGH_TOOLCHAIN + bool "SELinux mprotect checks" + default n if PPC32 + help + This option requires a modern toolchain (FIXME: Version?) + and a userspace rebuild to work. + diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c index 9a2ee84..e805df7 100644 --- a/security/selinux/hooks.c +++ b/security/selinux/hooks.c @@ -3009,7 +3009,7 @@ static int file_map_prot_check(struct file *file, unsigned long prot, int shared const struct cred *cred = current_cred(); int rc = 0; -#ifndef CONFIG_PPC32 +#ifdef CONFIG_SELINUX_NEW_ENOUGH_TOOLCHAIN if ((prot & PROT_EXEC) && (!file || (!shared && (prot & PROT_WRITE)))) { /* * We are making executable an anonymous mapping or a @@ -3081,7 +3081,7 @@ static int selinux_file_mprotect(struct vm_area_struct *vma, if (selinux_checkreqprot) prot = reqprot; -#ifndef CONFIG_PPC32 +#ifdef CONFIG_SELINUX_NEW_ENOUGH_TOOLCHAIN if ((prot & PROT_EXEC) && !(vma->vm_flags & VM_EXEC)) { int rc = 0; if (vma->vm_start >= vma->vm_mm->start_brk &&

2 3

Backporting virtio-console patches for F13 VirtioSerial feature
by Amit Shah 07 Feb '10

07 Feb '10

Hello, For the VirtioSerial F13 feature, a few patches need to be backported from the linux-next tree. Rusty has put them up in his local queue and they'll be pushed to Linus for 2.6.34. The patches are 42de322 virtio: console: statically initialize virtio_cons ddb20f0 hvc_console: make the ops pointer const. 14f5b2b virtio: console: We support only one device at a time 502d56a virtio: console: port encapsulation bd035b3 virtio: console: encapsulate buffer information in a struct db5f217 virtio: console: ensure add_inbuf can work for multiple ports as well 8bd5af9 virtio: console: introduce a get_inbuf helper to fetch bufs from in_vq 44ee715 virtio: console: use vdev->priv to avoid accessing global var. 982892b virtio: console: don't assume a single console port. fadef8b virtio: console: remove global var 1d6770b virtio: console: struct ports for multiple ports per device. 468f638 virtio: console: ensure console size is updated on hvc open 9f6d918 virtio: console: Separate out console-specific data into a separate struct 07efa05 virtio: console: Separate out console init into a new function 6191b29 virtio: console: Separate out find_vqs operation into a different function bfd9f44 virtio: console: Introduce function to hand off data from host to readers e5b54b53 virtio: console: Introduce a send_buf function for a common path for sending data to host 8d5e5a7 virtio: console: Add a new MULTIPORT feature, support for generic ports 5966ef0 virtio: console: Prepare for writing to / reading from userspace buffers 2e62003 virtio: console: Associate each port with a char device 4954379 virtio: console: Add file operations to ports for open/read/write/poll 606ac80 virtio: console: Ensure only one process can have a port open at a time c888962 virtio: console: Register with sysfs and create a 'name' attribute for ports 42eefd8 virtio: console: Remove cached data on port close 7c0ba1b virtio: console: Handle port hot-plug 9fe551d virtio: Add ability to detach unused buffers from vrings d201dd5 virtio: console: Add ability to hot-unplug ports 0f015e0 virtio: console: Add debugfs files for each port to expose debug info b431126 virtio: console: show error message if hvc_alloc fails for console ports from today's linux-next tree. The changes are confined to the drivers/virtio_console.c file (and a few other drivers/char/hvc* files) which haven't seen changes since 2.6.32, so these patches should apply as-is to the feodra tree. A patch that was merged in the 2.6.33 cycle also is needed: c0cefeb hvc_console: Export (GPL'ed) hvc_remove I can send these patches out as a patch series if that's easier for review. Feature Page https://fedoraproject.org/wiki/Features/VirtioSerial More info http://www.linux-kvm.org/page/VMchannel_Requirements Amit -- http://log.amitshah.net/

2 7

[Fwd: SECURITY: selinux, fix update_rlimit_cpu parameter] (fwd)
by James Morris 04 Feb '10

04 Feb '10

Please consider for 2.6.32.y and Fedora. -------- Forwarded Message -------- From: Linux Kernel Mailing List <linux-kernel(a)vger.kernel.org> To: git-commits-head(a)vger.kernel.org Subject: SECURITY: selinux, fix update_rlimit_cpu parameter Date: Mon, 4 Jan 2010 20:59:14 GMT Gitweb: http://git.kernel.org/linus/17740d89785aeb4143770923d67c293849414710 Commit: 17740d89785aeb4143770923d67c293849414710 Parent: 45d28b097280a78893ce25a5d0db41e6a2717853 Author: Jiri Slaby <jirislaby(a)gmail.com> AuthorDate: Fri Aug 28 10:47:16 2009 +0200 Committer: Jiri Slaby <jslaby(a)suse.cz> CommitDate: Mon Jan 4 11:27:18 2010 +0100 SECURITY: selinux, fix update_rlimit_cpu parameter Don't pass current RLIMIT_RTTIME to update_rlimit_cpu() in selinux_bprm_committing_creds, since update_rlimit_cpu expects RLIMIT_CPU limit. Use proper rlim[RLIMIT_CPU].rlim_cur instead to fix that. Signed-off-by: Jiri Slaby <jirislaby(a)gmail.com> Acked-by: James Morris <jmorris(a)namei.org> Cc: Stephen Smalley <sds(a)tycho.nsa.gov> Cc: Eric Paris <eparis(a)parisplace.org> Cc: David Howells <dhowells(a)redhat.com> --- security/selinux/hooks.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c index 7a374c2..9a2ee84 100644 --- a/security/selinux/hooks.c +++ b/security/selinux/hooks.c @@ -2365,7 +2365,7 @@ static void selinux_bprm_committing_creds(struct linux_binprm *bprm) initrlim = init_task.signal->rlim + i; rlim->rlim_cur = min(rlim->rlim_max, initrlim->rlim_cur); } - update_rlimit_cpu(rlim->rlim_cur); + update_rlimit_cpu(current->signal->rlim[RLIMIT_CPU].rlim_cur); } } -- To unsubscribe from this list: send the line "unsubscribe git-commits-head" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Stephen Smalley National Security Agency

2 1

F12 panic in bio_integrity_free
by Chuck Anderson 03 Feb '10

03 Feb '10

I have a new Dell OptiPlex 960 with a fresh Fedora 12 install, fully updated, that crashes while doing a dd from /dev/zero to an aes-xts-plain LUKS mapping. memtest86+ shows no errors after a single complete pass. From a serial console I was able to capture the backtrace(s). Anyone have suggestions on how to debug this further? Thanks. BUG: unable to handle kernel paging request at 0000000081000024 IP: [<ffffffff811247f5>] bio_integrity_free+0x3d/0x7b PGD 0 Oops: 0000 [#1] SMP last sysfs file: /sys/kernel/mm/ksm/run CPU 3 Modules linked in: ipt_MASQUERADE iptable_nat nf_nat bridge stp llc sunrpc xt_physdev ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 kvm_intel kvm uinput snd_hda_codec_analog snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device tg3 snd_pcm snd_timer snd iTCO_wdt iTCO_vendor_support e1000e i2c_i801 ppdev soundcore snd_page_alloc shpchp serio_raw parport_pc wmi parport dcdbas cryptd aes_x86_64 aes_generic xts gf128mul dm_crypt raid1 usb_storage dm_multipath ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded: speedstep_lib] Pid: 0, comm: swapper Not tainted 2.6.31.12-174.2.3.fc12.x86_64 #1 OptiPlex 960 RIP: 0010:[<ffffffff811247f5>] [<ffffffff811247f5>] bio_integrity_free+0x3d/0x7b RSP: 0018:ffff88002808ea80 EFLAGS: 00010202 RAX: ffff880138fa7d30 RBX: 0000000081000000 RCX: 0000000000aa0049 RDX: 0000000000000001 RSI: ffff88022c80a0c0 RDI: ffff880138fa7cc0 RBP: ffff88002808eaa0 R08: 0000000000000000 R09: 0000000000000004 R10: 0000000000000000 R11: ffffea00050118b8 R12: ffff880138fa7cc0 R13: ffff88022c80a0c0 R14: ffff88022c963800 R15: ffff880138fb3aa0 FS: 0000000000000000(0000) GS:ffff88002808b000(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: 0000000081000024 CR3: 0000000001001000 CR4: 00000000000426e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process swapper (pid: 0, threadinfo ffff88022f780000, task ffff88022f759780) Stack: ffff88002808eab0 ffff880138fa7cc0 ffff88022c80a0c0 ffff880138ef5900 <0> ffff88002808eac0 ffffffff81120023 0000000000000000 ffff880138fa7cc0 <0> ffff88002808ead0 ffffffff81345b85 ffff88002808eae0 ffffffff8111e801 Call Trace: <IRQ> [<ffffffff81120023>] bio_free+0x46/0x69 [<ffffffff81345b85>] dm_bio_destructor+0x12/0x14 [<ffffffff8111e801>] bio_put+0x2d/0x2f [<ffffffff81345f5d>] clone_endio+0x9f/0xb5 [<ffffffff8111e6d6>] bio_endio+0x2b/0x2d [<ffffffffa005f681>] crypt_dec_pending+0x52/0x79 [dm_crypt] [<ffffffffa005f855>] crypt_endio+0x9c/0xa5 [dm_crypt] [<ffffffff8111e6d6>] bio_endio+0x2b/0x2d [<ffffffff81345da4>] dec_pending+0x13d/0x15c [<ffffffff81345f67>] clone_endio+0xa9/0xb5 [<ffffffff8111e6d6>] bio_endio+0x2b/0x2d [<ffffffffa005904f>] raid_end_bio_io+0x37/0x88 [raid1] [<ffffffffa005a279>] raid1_end_write_request+0x1f3/0x20f [raid1] [<ffffffff8102d079>] ? hpet_msi_next_event+0x14/0x16 [<ffffffff8111e6d6>] bio_endio+0x2b/0x2d [<ffffffff811e9177>] req_bio_endio+0x9f/0xbe [<ffffffff811e9322>] blk_update_request+0x18c/0x32a [<ffffffff812d9ee0>] ? ata_scsi_qc_complete+0x349/0x358 [<ffffffff811e94e0>] blk_update_bidi_request+0x20/0x59 [<ffffffff811eae51>] blk_end_bidi_request+0x1f/0x5d [<ffffffff811eaecb>] blk_end_request+0x10/0x12 [<ffffffff812c07ca>] scsi_io_completion+0x1a5/0x416 [<ffffffff812b9c10>] scsi_finish_command+0xf5/0xfe [<ffffffff812c0b61>] scsi_softirq_done+0x111/0x11a [<ffffffff811f14a3>] blk_done_softirq+0x7b/0x8b [<ffffffff81057630>] __do_softirq+0xdd/0x1ad [<ffffffff81026966>] ? apic_write+0x16/0x18 [<ffffffff81012eac>] call_softirq+0x1c/0x30 [<ffffffff810143fb>] do_softirq+0x47/0x8d [<ffffffff81057342>] irq_exit+0x44/0x86 [<ffffffff814215d5>] do_IRQ+0xa5/0xbc [<ffffffff810126d3>] ret_from_intr+0x0/0x11 <EOI> [<ffffffff8101907f>] ? mwait_idle+0x91/0xae [<ffffffff8101907f>] ? mwait_idle+0x91/0xae [<ffffffff81019021>] ? mwait_idle+0x33/0xae [<ffffffff8141fc39>] ? atomic_notifier_call_chain+0x13/0x15 [<ffffffff81010bb8>] ? enter_idle+0x25/0x27 [<ffffffff81010c60>] ? cpu_idle+0xa6/0xe9 [<ffffffff8141717e>] ? start_secondary+0x1f3/0x234 Code: 48 8b 5f 60 49 89 fc 49 89 f5 48 85 db 75 04 0f 0b eb fe 48 f7 47 18 10 04 00 00 75 0e 48 8b 7b 10 48 85 ff 74 05 e8 6b ef fc ff <8b> 43 24 66 83 f8 06 75 1d 49 8b 75 18 48 89 df e8 09 eb f9 ff RIP [<ffffffff811247f5>] bio_integrity_free+0x3d/0x7b RSP <ffff88002808ea80> CR2: 0000000081000024 ---[ end trace ecd6d65d595c0086 ]--- Kernel panic - not syncing: Fatal exception in interrupt Pid: 0, comm: swapper Tainted: G D 2.6.31.12-174.2.3.fc12.x86_64 #1 Call Trace: <IRQ> [<ffffffff8141b41c>] panic+0x7a/0x12c [<ffffffff8141e66d>] oops_end+0xb2/0xc2 [<ffffffff8103456d>] no_context+0x1f6/0x205 [<ffffffff810c4a1b>] ? list_add+0x11/0x13 [<ffffffff8103471f>] __bad_area_nosemaphore+0x1a3/0x1c9 [<ffffffff8120a737>] ? __percpu_counter_add+0x47/0x64 [<ffffffff81200132>] ? percpu_counter_add.clone.0+0x14/0x16 [<ffffffff81034758>] bad_area_nosemaphore+0x13/0x15 [<ffffffff8141fa6a>] do_page_fault+0x14a/0x299 [<ffffffff8141db35>] page_fault+0x25/0x30 [<ffffffff811247f5>] ? bio_integrity_free+0x3d/0x7b [<ffffffff81120023>] bio_free+0x46/0x69 [<ffffffff81345b85>] dm_bio_destructor+0x12/0x14 [<ffffffff8111e801>] bio_put+0x2d/0x2f [<ffffffff81345f5d>] clone_endio+0x9f/0xb5 [<ffffffff8111e6d6>] bio_endio+0x2b/0x2d [<ffffffffa005f681>] crypt_dec_pending+0x52/0x79 [dm_crypt] [<ffffffffa005f855>] crypt_endio+0x9c/0xa5 [dm_crypt] [<ffffffff8111e6d6>] bio_endio+0x2b/0x2d [<ffffffff81345da4>] dec_pending+0x13d/0x15c [<ffffffff81345f67>] clone_endio+0xa9/0xb5 [<ffffffff8111e6d6>] bio_endio+0x2b/0x2d [<ffffffffa005904f>] raid_end_bio_io+0x37/0x88 [raid1] [<ffffffffa005a279>] raid1_end_write_request+0x1f3/0x20f [raid1] [<ffffffff8102d079>] ? hpet_msi_next_event+0x14/0x16 [<ffffffff8111e6d6>] bio_endio+0x2b/0x2d [<ffffffff811e9177>] req_bio_endio+0x9f/0xbe [<ffffffff811e9322>] blk_update_request+0x18c/0x32a [<ffffffff812d9ee0>] ? ata_scsi_qc_complete+0x349/0x358 [<ffffffff811e94e0>] blk_update_bidi_request+0x20/0x59 [<ffffffff811eae51>] blk_end_bidi_request+0x1f/0x5d [<ffffffff811eaecb>] blk_end_request+0x10/0x12 [<ffffffff812c07ca>] scsi_io_completion+0x1a5/0x416 [<ffffffff812b9c10>] scsi_finish_command+0xf5/0xfe [<ffffffff812c0b61>] scsi_softirq_done+0x111/0x11a [<ffffffff811f14a3>] blk_done_softirq+0x7b/0x8b [<ffffffff81057630>] __do_softirq+0xdd/0x1ad [<ffffffff81026966>] ? apic_write+0x16/0x18 [<ffffffff81012eac>] call_softirq+0x1c/0x30 [<ffffffff810143fb>] do_softirq+0x47/0x8d [<ffffffff81057342>] irq_exit+0x44/0x86 [<ffffffff814215d5>] do_IRQ+0xa5/0xbc [<ffffffff810126d3>] ret_from_intr+0x0/0x11 <EOI> [<ffffffff8101907f>] ? mwait_idle+0x91/0xae [<ffffffff8101907f>] ? mwait_idle+0x91/0xae [<ffffffff81019021>] ? mwait_idle+0x33/0xae [<ffffffff8141fc39>] ? atomic_notifier_call_chain+0x13/0x15 [<ffffffff81010bb8>] ? enter_idle+0x25/0x27 [<ffffffff81010c60>] ? cpu_idle+0xa6/0xe9 [<ffffffff8141717e>] ? start_secondary+0x1f3/0x234

1 2

[Fwd: SUMMARY: KVM+nf_conntrack_htable_size]
by Jon Masters 03 Feb '10

03 Feb '10

The disabling of netfilter on bridges is not really "solving" this problem. The problem is that the hashing code needs fixing. Until that changes, whenever libvirtd plays with namespaces (as it does), we run the risk of falling over as we play with the size of the hashtables. Jon.

3 6

[Fwd: Re: debug: nt_conntrack and KVM crash]
by Jon Masters 29 Jan '10

29 Jan '10

1 0

[Fwd: Re: PROBLEM: reproducible crash KVM+nf_conntrack all recent 2.6 kernels]
by Jon Masters 28 Jan '10

28 Jan '10

3 3

kernel-devel missing include/generated
by Roland McGrath 27 Jan '10

27 Jan '10

As of kernel-devel-2.6.33-0.20.rc5.git0.fc13.x86_64 you cannot build any modules against it. AFAICT it is due to missing include/generated so that this would fix it. But it makes me wonder, why don't we just copy all of include/ instead of this list of subdirectories? Thanks, Roland --- kernel.spec 27 Jan 2010 11:29:18 -0800 1.1906 +++ kernel.spec 27 Jan 2010 11:31:42 -0800 @@ -1527,7 +1527,7 @@ hwcap 0 nosegneg" fi mkdir -p $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/include cd include - cp -a acpi config crypto keys linux math-emu media mtd net pcmcia rdma rxrpc scsi sound trace video drm asm-generic $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/include + cp -a acpi config crypto generated keys linux math-emu media mtd net pcmcia rdma rxrpc scsi sound trace video drm asm-generic $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/include pushd $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/include ln -s arch/%{asmarch}/include/asm asm popd

2 2

F-12 2.6.32.5 kernel and ATI card == fail
by Hans de Goede 26 Jan '10

26 Jan '10

Hi, I'm not sure where to report this, but I thought this was something important to report, because AFAIK there are plans to make 2.6.32.5 move to F-12 updates-testing. Today I compiled my own F-12 2.6.32.5 kernel from pkg-CVS, as I was working on rebasing the gspca driver in there to the latest upstream (as a lot of really good to have fixes and new hardware support has accumulated upstream). When rebooting into my kernel (stock pkg-cvs + rebased gspca, which at that time did not even load as no webcam was plugged in), X failed to start (segfault). After upgrading all xorg + libdrm + mesa packages to rawhide this was fixed. Regards, Hans

1 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel January 2010