kernel October 2010

kernel@lists.fedoraproject.org

36 participants
15 discussions

WARNING: at drivers/char/tty_io.c:1325 tty_open+0x29c/0x49b()
by Michał Piotrowski 29 Nov '10

29 Nov '10

I hit this bug after upgrade from testing systemd repo [ 15.630389] WARNING: at drivers/char/tty_io.c:1325 tty_open+0x29c/0x49b() [ 15.630393] Hardware name: HP 550 [ 15.630396] Modules linked in: snd_hda_codec_analog iwlagn snd_hda_intel iwlcore snd_hda_codec snd_hwdep snd_seq uinput snd_seq_device hp_wmi btusb mac80211 snd_pcm cfg80211 bluetooth rfkill snd_timer joydev serio_raw wmi shpchp snd soundcore e1000e iTCO_wdt snd_page_alloc iTCO_vendor_support ipv6 i915 drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded: scsi_wait_scan] [ 15.630460] Pid: 123, comm: plymouthd Not tainted 2.6.36-1.fc15.x86_64 #1 [ 15.630464] Call Trace: [ 15.630472] [<ffffffff810511bc>] warn_slowpath_common+0x85/0x9d [ 15.630479] [<ffffffff810511ee>] warn_slowpath_null+0x1a/0x1c [ 15.630485] [<ffffffff812d3c3a>] tty_open+0x29c/0x49b [ 15.630493] [<ffffffff8112eb90>] chrdev_open+0x122/0x14b [ 15.630499] [<ffffffff8112ea6e>] ? chrdev_open+0x0/0x14b [ 15.630506] [<ffffffff8112963f>] __dentry_open+0x1c2/0x338 [ 15.630514] [<ffffffff8121316e>] ? devcgroup_inode_permission+0xea/0x117 [ 15.630521] [<ffffffff8112a4c0>] nameidata_to_filp+0x3f/0x50 [ 15.630527] [<ffffffff81136adc>] do_last+0x432/0x5af [ 15.630533] [<ffffffff81246491>] ? __raw_spin_lock_init+0x31/0x50 [ 15.630539] [<ffffffff81136e89>] do_filp_open+0x230/0x5e1 [ 15.630546] [<ffffffff81010588>] ? native_sched_clock+0x35/0x37 [ 15.630553] [<ffffffff8107275e>] ? local_clock+0x36/0x4d [ 15.630561] [<ffffffff8107ff01>] ? lock_release+0x19a/0x1a6 [ 15.630568] [<ffffffff81140e16>] ? alloc_fd+0x16a/0x17c [ 15.630574] [<ffffffff8112a531>] do_sys_open+0x60/0xfc [ 15.630582] [<ffffffff8149cb0d>] ? trace_hardirqs_on_thunk+0x3a/0x3f [ 15.630588] [<ffffffff8112a5ed>] sys_open+0x20/0x22 [ 15.630594] [<ffffffff81009cf2>] system_call_fastpath+0x16/0x1b [ 15.630599] ---[ end trace 740a8a695fc86592 ]--- [ 16.275231] init[1]: tmpwatch.service: main process exited, code=exited, status=203 [ 16.279501] init[1]: Unit tmpwatch.service entered failed state. [ 16.410415] ------------[ cut here ]------------ [ 16.410427] WARNING: at drivers/char/tty_io.c:1325 tty_open+0x29c/0x49b() [ 16.410431] Hardware name: HP 550 [ 16.410434] Modules linked in: snd_hda_codec_analog iwlagn snd_hda_intel iwlcore snd_hda_codec snd_hwdep snd_seq uinput snd_seq_device hp_wmi btusb mac80211 snd_pcm cfg80211 bluetooth rfkill snd_timer joydev serio_raw wmi shpchp snd soundcore e1000e iTCO_wdt snd_page_alloc iTCO_vendor_support ipv6 i915 drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded: scsi_wait_scan] [ 16.410499] Pid: 123, comm: plymouthd Tainted: G W 2.6.36-1.fc15.x86_64 #1 [ 16.410504] Call Trace: [ 16.410515] [<ffffffff810511bc>] warn_slowpath_common+0x85/0x9d [ 16.410522] [<ffffffff810511ee>] warn_slowpath_null+0x1a/0x1c [ 16.410528] [<ffffffff812d3c3a>] tty_open+0x29c/0x49b [ 16.410535] [<ffffffff8112eb90>] chrdev_open+0x122/0x14b [ 16.410542] [<ffffffff8112ea6e>] ? chrdev_open+0x0/0x14b [ 16.410549] [<ffffffff8112963f>] __dentry_open+0x1c2/0x338 [ 16.410557] [<ffffffff8121316e>] ? devcgroup_inode_permission+0xea/0x117 [ 16.410564] [<ffffffff8112a4c0>] nameidata_to_filp+0x3f/0x50 [ 16.410571] [<ffffffff81136adc>] do_last+0x432/0x5af [ 16.410577] [<ffffffff81246491>] ? __raw_spin_lock_init+0x31/0x50 [ 16.410583] [<ffffffff81136e89>] do_filp_open+0x230/0x5e1 [ 16.410590] [<ffffffff81010588>] ? native_sched_clock+0x35/0x37 [ 16.410598] [<ffffffff8107275e>] ? local_clock+0x36/0x4d [ 16.410605] [<ffffffff8107ff01>] ? lock_release+0x19a/0x1a6 [ 16.410612] [<ffffffff81140e16>] ? alloc_fd+0x16a/0x17c [ 16.410619] [<ffffffff8112a531>] do_sys_open+0x60/0xfc [ 16.410627] [<ffffffff8149cb0d>] ? trace_hardirqs_on_thunk+0x3a/0x3f [ 16.410633] [<ffffffff8112a5ed>] sys_open+0x20/0x22 [ 16.410639] [<ffffffff81009cf2>] system_call_fastpath+0x16/0x1b [ 16.410644] ---[ end trace 740a8a695fc86593 ]--- https://bugzilla.redhat.com/show_bug.cgi?id=630464 Regards, Michal

4 14

upstream exec-shield git tree
by Kees Cook 10 Nov '10

10 Nov '10

Hi, On Wed, Jul 14, 2010 at 01:16:03AM -0700, Roland McGrath wrote: > git://git.kernel.org/pub/scm/linux/kernel/git/frob/linux-2.6-roland.git > > Two branches: > > fedora/x86-nx-emulation > fedora/32bit-mmap-exec-randomization I'm in the process of trying to aim Debian at these as well (and I'm about to start the rebase of this for the next Ubuntu release), but it seems they're not up to date. I see that the brk fix and boot parameter changes I sent are mentioned[1] in the Fedora kernel: 2110 * Fri Sep 03 2010 Dave Jones <davej(a)redhat.com> 2.6.36-0.16.rc3.git0 2111 - exec-randomization: brk away from exec rand area (Kees Cook) 2112 2113 * Fri Sep 03 2010 Dave Jones <davej(a)redhat.com> 2114 - Remove the execshield boot parameter. 2115 Based on a patch from Kees Cook These seem to be [2] and [3], but I'd like to try to keep the main git branches up to date so there is a single place to coordinate. Roland, do you have a moment to get these committed to the main "upstream" branches? Thanks! -Kees [1] http://pkgs.fedoraproject.org/gitweb/?p=kernel.git;a=shortlog;h=refs/heads/… [2] http://pkgs.fedoraproject.org/gitweb/?p=kernel.git;a=commitdiff;h=55f50f1d1… [3] http://pkgs.fedoraproject.org/gitweb/?p=kernel.git;a=commitdiff;h=fff25a2ad… For this one, I'm not sure why the git view shows Dave as the author when I'm in the signed-off, but that's a whole other problem. :) -- Kees Cook Ubuntu Security Team

5 15

Re: [Bug 225969] Merge Review: kernel
by Dave Jones 28 Oct '10

28 Oct '10

Spot went through this bug that has been around forever, and wrote up some review comments. I cleaned up some of the low hanging fruit, but there's still a few that I'm uncertain on. input welcomed. > kernel.x86_64: E: shared-lib-without-dependency-information > /lib/modules/2.6.36-1.fc15.x86_64/vdso/vdso32-syscall.so > kernel.x86_64: E: shared-lib-without-dependency-information > /lib/modules/2.6.36-1.fc15.x86_64/vdso/vdso.so > kernel.x86_64: E: shared-lib-without-dependency-information > /lib/modules/2.6.36-1.fc15.x86_64/vdso/vdso32-int80.so > kernel.x86_64: E: missing-PT_GNU_STACK-section > /lib/modules/2.6.36-1.fc15.x86_64/vdso/vdso32-syscall.so > kernel.x86_64: E: missing-PT_GNU_STACK-section > /lib/modules/2.6.36-1.fc15.x86_64/vdso/vdso.so > kernel.x86_64: E: missing-PT_GNU_STACK-section > /lib/modules/2.6.36-1.fc15.x86_64/vdso/vdso32-int80.so > > (I don't begin to claim that I understand what's happening here, but I suspect > that these vdso files server a specific purpose and that these warnings do not > apply to them.) I'm going to assume this is to be expected, as they aren't 'real' libraries. Roland ? > kernel.x86_64: W: no-documentation > > (At a minimum, COPYING should be present as %doc with the GPLv2 terms.) I'm not sure this makes sense when we have a kernel-doc package. Though I note we don't have COPYING in there either. > kernel.x86_64: W: dangling-relative-symlink > /lib/modules/2.6.36-1.fc15.x86_64/build > ../../../usr/src/kernels/2.6.36-1.fc15.x86_64 > > (It seems odd that /lib/modules/2.6.36-1.fc15.x86_64/build is packaged in > kernel, but the symlink it points to is in kernel-devel. Is there a reason that > the /lib/modules/2.6.36-1.fc15.x86_64/build ownership isn't in kernel-devel?) We flip-flopped on this a few years ago. It used to be that way iirc, but I'm not recalling the exact reasoning for why it changed. > kernel.x86_64: W: non-conffile-in-etc > /etc/ld.so.conf.d/kernel-2.6.36-1.fc15.x86_64.conf > > (Should this be marked as %config(noreplace)?) it's versioned, so no ? I think ? > kernel-devel.x86_64: W: no-documentation > (There are documentation files included in kernel-devel, they are not marked as > %doc though. Recognizing that the kernel-devel file list is autogenerated, I > can't see a good way to accomplish this file marking, so I propose that this is > safe to ignore.) ack. > kernel-devel.x86_64: E: zero-length > /usr/src/kernels/2.6.36-1.fc15.x86_64/include/config/fb/via.h > [ ... repeated for several hundred empty kernel .h files ... ] > > (I assume that all of these zero length header files are kernel header files > which are not intended to be exposed/exported to userspace. Perhaps it makes > sense to iterate through the buildroot at the end of install and delete all of > the zero length header files? Might speed up the -devel transaction.) Something in the tree could be #include'ing them, but I don't see anything from a quick grep. Not sure about this. (They're autogenerated, and their content varies depending on CONFIG options being set). > kernel-devel.x86_64: E: non-executable-script > /usr/src/kernels/2.6.36-1.fc15.x86_64/scripts/rt-tester/rt-tester.py 0644L > /usr/bin/python > kernel-devel.x86_64: E: non-executable-script > /usr/src/kernels/2.6.36-1.fc15.x86_64/scripts/headers_install.pl 0644L > /usr/bin/perl > kernel-devel.x86_64: E: non-executable-script > /usr/src/kernels/2.6.36-1.fc15.x86_64/scripts/gcc-x86_32-has-stack-protector.sh > 0644L /bin/sh > kernel-devel.x86_64: E: non-executable-script > /usr/src/kernels/2.6.36-1.fc15.x86_64/scripts/gfp-translate 0644L /bin/bash > kernel-devel.x86_64: E: non-executable-script > /usr/src/kernels/2.6.36-1.fc15.x86_64/scripts/kconfig/lxdialog/check-lxdialog.sh > 0644L /bin/sh > kernel-devel.x86_64: E: non-executable-script > /usr/src/kernels/2.6.36-1.fc15.x86_64/scripts/export_report.pl 0644L > /usr/bin/perl > kernel-devel.x86_64: E: non-executable-script > /usr/src/kernels/2.6.36-1.fc15.x86_64/scripts/mksysmap 0644L /bin/sh > kernel-devel.x86_64: E: non-executable-script > /usr/src/kernels/2.6.36-1.fc15.x86_64/scripts/package/builddeb 0644L /bin/sh > kernel-devel.x86_64: E: non-executable-script > /usr/src/kernels/2.6.36-1.fc15.x86_64/scripts/gen_initramfs_list.sh 0644L > /bin/bash > kernel-devel.x86_64: E: non-executable-script > /usr/src/kernels/2.6.36-1.fc15.x86_64/scripts/bootgraph.pl 0644L /usr/bin/perl > kernel-devel.x86_64: E: non-executable-script > /usr/src/kernels/2.6.36-1.fc15.x86_64/scripts/tracing/draw_functrace.py 0644L > /usr/bin/python > kernel-devel.x86_64: E: non-executable-script > /usr/src/kernels/2.6.36-1.fc15.x86_64/scripts/headers_check.pl 0644L > /usr/bin/perl > kernel-devel.x86_64: E: non-executable-script > /usr/src/kernels/2.6.36-1.fc15.x86_64/scripts/selinux/install_policy.sh 0644L > /bin/sh > kernel-devel.x86_64: E: non-executable-script > /usr/src/kernels/2.6.36-1.fc15.x86_64/scripts/gcc-version.sh 0644L /bin/sh > kernel-devel.x86_64: E: non-executable-script > /usr/src/kernels/2.6.36-1.fc15.x86_64/scripts/profile2linkerlist.pl 0644L > /usr/bin/perl > kernel-devel.x86_64: E: non-executable-script > /usr/src/kernels/2.6.36-1.fc15.x86_64/scripts/kconfig/streamline_config.pl > 0644L /usr/bin/perl > kernel-devel.x86_64: E: non-executable-script > /usr/src/kernels/2.6.36-1.fc15.x86_64/scripts/markup_oops.pl 0644L > /usr/bin/perl > kernel-devel.x86_64: E: non-executable-script > /usr/src/kernels/2.6.36-1.fc15.x86_64/scripts/mkmakefile 0644L /bin/sh > kernel-devel.x86_64: E: non-executable-script > /usr/src/kernels/2.6.36-1.fc15.x86_64/scripts/package/buildtar 0644L /bin/sh > kernel-devel.x86_64: E: non-executable-script > /usr/src/kernels/2.6.36-1.fc15.x86_64/scripts/gcc-x86_64-has-stack-protector.sh > 0644L /bin/sh > > (These script files are being packaged, but probably set to chmod -x to prevent > kernel-devel from picking up dependencies. This list of files should be > reviewed to see whether they should remain in kernel-devel or be deleted from > the buildroot at the end of %install. If any of these files are useful and are > kept in kernel-devel, they should be set executable so proper dependencies are > found for these scripts by RPM.) I think we can probably just kill all of these. everything else on spots list I committed already. Dave

7 12

F14: tpm prevents suspend
by Amit Shah 28 Oct '10

28 Oct '10

Hello, While trying out 2.6.35.6-46.fc14.x86_64 on an F13 userspace, suspend fails on an X200 laptop: https://bugzilla.redhat.com/show_bug.cgi?id=644842 Bryan O'Sullivan on the bug reports kernel-2.6.35.4-28.fc14.x86_64 works, and this is a recent regression. Amit -- http://log.amitshah.net/

3 3

Re: [kernel] more rpmlint: E: useless-provides kernel
by Roland McGrath 26 Oct '10

26 Oct '10

> more rpmlint: E: useless-provides kernel > > (This is coming from line 445: Provides: kernel = > %{rpmversion}-%{pkg_release}\. > I don't see any reason for this line, as rpm is autoproviding kernel = > %{version}-%{release} (and %{version} is being set to %{rpmversion} and > %{release} is being set to %{pkg_release}.) Really? rpm is autoproviding kernel = ... in a kernel-smp subpackage? That's what it's there for. Thanks, Roland

3 4

Re: ima: use of radix tree cache indexing == massive waste of memory?
by Christoph Hellwig 26 Oct '10

26 Oct '10

On Sat, Oct 16, 2010 at 02:10:29PM -0700, H. Peter Anvin wrote: > I'm confused ... what makes you think we are? This might have been an unintentional misconfiguration... I didn't mean to imply you enabled it intentionally. In fact it looks like the inode tracking in IMA is always on once it's compiled in, which totally defeats the purpose of doing it's on iternal inode tracking instead of bloating the inode what they originally proposed. IMA really needs a kernel parameter to only enabled this crap when people actually use it. And whoever turned it on in Fedora needs some serious wahcking.

13 27

Bug 590880 - Trackpad on Dell Inspiron E6410 not recognized
by Reinout van Schouwen 25 Oct '10

25 Oct '10

Dear Fedora kernel hackers, Could I ask for your attention for bug 590880 please? According to the comments, there is a working patch but it just has to be included in the Fedora kernel for testing. Thanks! -- Reinout van Schouwen http://vanschouwen.info/

2 1

Newly Joined fedora kernel team
by sagar dashora 21 Oct '10

21 Oct '10

Hi I am Sagar Dashora, 24 years of age, having 2 years of c/c++ development experience in my profession. I have joined fedora community recently and willing to work on c/ c++ programming assignments, great if something related to device drivers development. Please let me know whether there are any ongoing projects that I may work upon. ------- Sagar Dashora +919703680444

2 1

f14: xhci suspend/resume
by Kyle McMartin 18 Oct '10

18 Oct '10

Due to xHCI usb3.0 not supporting suspend/resume, and thus, actively preventing laptops from suspending, we disabled support for xHCI by default in the Fedora 14 release kernel. Of course, it would be ideal to backport the suspend/resume support for xhci_hcd from linux-next, and so I've done that. Can people with usb3.0 devices please test: http://kyle.fedorapeople.org/kernel/2.6.35.6-45.1.fc14-xhci/ and let me know if there's any regressions from the previous F-14 kernel, and whether they're able to suspend with xhci loaded (which should autoload.) Much appreciated! Kyle

1 0

Duplicate kernel-headers after upgrading to 2.6.35
by Ryad Ben-El-Kezadri 15 Oct '10

15 Oct '10

Hello everybody, I installed fc13 (Goddard 2.6.33 kernel). But I needed kernel 2.6.35 so I downloaded kernel-2.6.35.6-43.fc14.src on koji.fedoraproject.org followed the instructions on http://fedoraproject.org/wiki/Docs/CustomKerneland managed to make it works. However now when I run yum, I get the following warning "kernel-headers-2.6.35.6-43.fc13.i686 is a duplicate with kernel-headers-2.6.33.3-85.fc13.i686" I guess this is because the installation process ( http://fedoraproject.org/wiki/Docs/CustomKernel)<http://fedoraproject.org/wiki/Docs/CustomKernel> asked to download kernel-headers-2.6.35.6-43.fc13.i686. I will have to compile applications in userland that needs the new headers. Can I safely remove the old headers? Thanks Ryad

3 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel October 2010