2.6.27-rc6-git2: Reported regressions from 2.6.26

2.6.27-rc6-git2: Reported regressions from 2.6.26

[Rafael J. Wysocki]

This message contains a list of some regressions from 2.6.26, for which there
are no fixes in the mainline I know of.  If any of them have been fixed already,
please let me know.

If you know of any other unresolved regressions from 2.6.26, please let me know
either and I'll add them to the list.  Also, please let me know if any of the
entries below are invalid.

Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.


Listed regressions statistics:

  Date          Total  Pending  Unresolved
  ----------------------------------------
  2008-09-12      163       51          38
  2008-09-07      150       43          33
  2008-08-30      135       48          36
  2008-08-23      122       48          40
  2008-08-16      103       47          37
  2008-08-10       80       52          31
  2008-08-02       47       31          20


Unresolved regressions
----------------------

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11559
Subject		: 2.6.27-rc6: nohz + s2ram = need to press keys to get progress
Submitter	: Pavel Machek <pavel@suse.cz>
Date		: 2008-09-12 8:31 (1 days old)
References	: http://marc.info/?l=linux-kernel&m=122121384705262&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11557
Subject		: Controlling backlight on thinkpad x60
Submitter	: Pavel Machek <pavel@suse.cz>
Date		: 2008-09-08 15:10 (5 days old)
References	: http://marc.info/?l=linux-kernel&m=122088987319698&w=4
Handled-By	: Matthew Garrett <mjg59@srcf.ucam.org>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11554
Subject		: Partition check considered as error is breaking mounting in 2.6.27
Submitter	: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
Date		: 2008-09-12 16:56 (1 days old)
References	: http://marc.info/?l=linux-kernel&m=122123862519434&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11553
Subject		: Strange looking line from "ps aux"
Submitter	: Rogério Brito <rbrito@ime.usp.br>
Date		: 2008-09-11 17:43 (2 days old)
References	: http://marc.info/?l=linux-kernel&m=122115506018275&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11552
Subject		: Disabling IRQ #23
Submitter	: Justin Mattock <justinmattock@gmail.com>
Date		: 2008-09-09 19:08 (4 days old)
References	: http://marc.info/?l=linux-kernel&m=122098735230906&w=4
		  http://marc.info/?l=linux-kernel&m=122107367715361&w=4
Handled-By	: Yinghai Lu <yhlu.kernel@gmail.com>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11551
Subject		: Semi-repeatable hard lockup on 2.6.27-rc6
Submitter	: Steven Noonan <steven@uplinklabs.net>
Date		: 2008-09-10 18:07 (3 days old)
References	: http://marc.info/?l=linux-kernel&m=122107007407994&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11548
Subject		: kernel BUG at drivers/pci/intel-iommu.c:1373!
Submitter	: Chris Mason <chris.mason@oracle.com>
Date		: 2008-09-08 14:26 (5 days old)
References	: http://marc.info/?l=linux-kernel&m=122088566310440&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11516
Subject		: severe performance degradation on x86_64 going from 2.6.26-rc9 -&gt; 2.6.27-rc5
Submitter	: Jason Vas Dias <jason.vas.dias@gmail.com>
Date		: 2008-09-07 13:59 (6 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11512
Subject		: sort-of regression due to "kconfig: speed up all*config + randconfig"
Submitter	: Alexey Dobriyan <adobriyan@gmail.com>
Date		: 2008-09-05 22:50 (8 days old)
References	: http://marc.info/?l=linux-kernel&m=122065498013858&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11506
Subject		: oops during unmount - ext3? (2.6.27-rc5)
Submitter	: Marcin Slusarz <marcin.slusarz@gmail.com>
Date		: 2008-09-04 19:14 (9 days old)
References	: http://marc.info/?l=linux-kernel&m=122055573123449&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11505
Subject		: oltp ~10% regression with 2.6.27-rc5 on stoakley machine
Submitter	: Lin Ming <ming.m.lin@intel.com>
Date		: 2008-09-04 7:06 (9 days old)
References	: http://marc.info/?l=linux-kernel&m=122051202202373&w=4
		  http://marc.info/?t=122089704700005&r=1&w=4
Handled-By	: Peter Zijlstra <a.p.zijlstra@chello.nl>
		  Gregory Haskins <ghaskins@novell.com>
		  Ingo Molnar <mingo@elte.hu>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11504
Subject		: reiserfs  BUG in 2.6.27-rc5
Submitter	: Randy Dunlap <randy.dunlap@oracle.com>
Date		: 2008-09-03 16:35 (10 days old)
References	: http://marc.info/?l=linux-kernel&m=122045982120138&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11501
Subject		: Failed to open destination file: Permission deniedihex2fw
Submitter	: Andrew Morton <akpm@linux-foundation.org>
Date		: 2008-09-04 18:34 (9 days old)
References	: http://marc.info/?l=linux-kernel&m=122055342419068&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11500
Subject		: /proc/net bug related to selinux
Submitter	: Andrew Morton <akpm@linux-foundation.org>
Date		: 2008-09-04 17:45 (9 days old)
References	: http://marc.info/?l=linux-kernel&m=122055041313270&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11485
Subject		: 2.6.27-rc xen pvops regression?
Submitter	: Bernhard Schmidt <berni@birkenwald.de>
Date		: 2008-08-31 17:18 (13 days old)
References	: http://marc.info/?l=linux-kernel&m=122020367015025&w=4
Handled-By	: Alex Nixon <alex.nixon@citrix.com>
		  Jeremy Fitzhardinge <jeremy@goop.org>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11476
Subject		: failure to associate after resume from suspend to ram
Submitter	: Michael S. Tsirkin <m.s.tsirkin@gmail.com>
Date		: 2008-09-01 13:33 (12 days old)
References	: http://marc.info/?l=linux-kernel&m=122028529415108&w=4
Handled-By	: Zhu Yi <yi.zhu@intel.com>
		  Dan Williams <dcbw@redhat.com>
		  Jouni Malinen <j@w1.fi>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11471
Subject		: GPE storm detected, kernel freezes
Submitter	: George Gibbs <Vash63@gmail.com>
Date		: 2008-08-31 22:00 (13 days old)
Handled-By	: Zhang Rui <rui.zhang@intel.com>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11465
Subject		: Linux-2.6.27-rc5, drm errors in log
Submitter	: Gene Heskett <gene.heskett@verizon.net>
Date		: 2008-08-30 18:52 (14 days old)
References	: http://marc.info/?l=linux-kernel&m=122012238925775&w=4
Handled-By	: Dave Airlie <airlied@gmail.com>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11463
Subject		: sshd hangs on close
Submitter	: Matthias Urlichs <matthias@urlichs.de>
Date		: 2008-08-30 9:18 (14 days old)
References	: http://marc.info/?l=linux-kernel&m=122008800512864&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11459
Subject		: kernel crash after wifi connection established
Submitter	: Alexey Kuznetsov <ak@axet.ru>
Date		: 2008-08-30 03:08 (14 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11407
Subject		: suspend: unable to handle kernel paging request
Submitter	: Vegard Nossum <vegard.nossum@gmail.com>
Date		: 2008-08-21 17:28 (23 days old)
References	: http://marc.info/?l=linux-kernel&m=121933974928881&w=4
Handled-By	: Rafael J. Wysocki <rjw@sisk.pl>
		  Pekka Enberg <penberg@cs.helsinki.fi>
		  Pavel Machek <pavel@suse.cz>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11404
Subject		: BUG: in 2.6.23-rc3-git7 in do_cciss_intr
Submitter	: rdunlap <randy.dunlap@oracle.com>
Date		: 2008-08-21 5:52 (23 days old)
References	: http://marc.info/?l=linux-kernel&m=121929819616273&w=4
		  http://marc.info/?l=linux-kernel&m=121932889105368&w=4
Handled-By	: Miller, Mike (OS Dev) <Mike.Miller@hp.com>
		  James Bottomley <James.Bottomley@hansenpartnership.com>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11398
Subject		: hda_intel: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj.
Submitter	: Frans Pop <elendil@planet.nl>
Date		: 2008-08-21 17:17 (23 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11380
Subject		: lockdep warning: cpu_add_remove_lock at:cpu_maps_update_begin+0x14/0x16
Submitter	: Ingo Molnar <mingo@elte.hu>
Date		: 2008-08-20 6:44 (24 days old)
References	: http://marc.info/?l=linux-kernel&m=121921480931970&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11357
Subject		: Can not boot up with zd1211rw USB-Wlan Stick
Submitter	: uwe <kender@freenet.de>
Date		: 2008-08-16 14:17 (28 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11343
Subject		: SATA Cold Boot Problems with 2.6.27-rc[23] on nVidia 680i
Submitter	: Manny Maxwell <mannymax@mannymax.net>
Date		: 2008-08-14 4:16 (30 days old)
References	: http://marc.info/?l=linux-kernel&m=121868782917600&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11340
Subject		: LTP overnight run resulted in unusable box
Submitter	: Alexey Dobriyan <adobriyan@gmail.com>
Date		: 2008-08-13 9:24 (31 days old)
References	: http://marc.info/?l=linux-kernel&m=121861951902949&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11335
Subject		: 2.6.27-rc2-git5 BUG: unable to handle kernel paging request
Submitter	: Randy Dunlap <randy.dunlap@oracle.com>
Date		: 2008-08-12 4:18 (32 days old)
References	: http://marc.info/?l=linux-kernel&m=121851477201960&w=4
		  http://lkml.org/lkml/2008/8/16/274
Handled-By	: Hugh Dickins <hugh@veritas.com>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11308
Subject		: tbench regression on each kernel release from 2.6.22 -&gt; 2.6.28
Submitter	: Christoph Lameter <cl@linux-foundation.org>
Date		: 2008-08-11 18:36 (33 days old)
References	: http://marc.info/?l=linux-kernel&m=121847986119495&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11272
Subject		: BUG: parport_serial in 2.6.27-rc1 for NetMos Technology PCI 9835
Submitter	: Jaswinder Singh <jaswinderlinux@gmail.com>
Date		: 2008-08-05 15:12 (39 days old)
References	: http://marc.info/?l=linux-kernel&m=121794900319776&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11271
Subject		: BUG: fealnx in 2.6.27-rc1
Submitter	: Jaswinder Singh <jaswinderlinux@gmail.com>
Date		: 2008-08-05 14:58 (39 days old)
References	: http://marc.info/?l=linux-netdev&m=121794762016830&w=4
		  http://lkml.org/lkml/2008/8/10/98
Handled-By	: Francois Romieu <romieu@fr.zoreil.com>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11264
Subject		: Invalid op opcode in kernel/workqueue
Submitter	: Jean-Luc Coulon <jean.luc.coulon@gmail.com>
Date		: 2008-08-07 04:18 (37 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11230
Subject		: Kconfig no longer outputs a .config with freshly updated defconfigs
Submitter	: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Date		: 2008-08-02 16:03 (42 days old)
References	: http://marc.info/?l=linux-kernel&m=121769306319391&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11224
Subject		: Only three cores found on quad-core machine.
Submitter	: Dave Jones <davej@redhat.com>
Date		: 2008-08-01 18:15 (43 days old)
References	: http://marc.info/?l=linux-kernel&m=121761475224719&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11220
Subject		: Screen stays black after resume
Submitter	: Nico Schottelius <nico@schottelius.org>
Date		: 2008-07-31 21:05 (44 days old)
References	: http://marc.info/?l=linux-kernel&m=121753882422899&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11215
Subject		: INFO: possible recursive locking detected ps2_command
Submitter	: Zdenek Kabelac <zdenek.kabelac@gmail.com>
Date		: 2008-07-31 9:41 (44 days old)
References	: http://marc.info/?l=linux-kernel&m=121749737011637&w=4
Handled-By	: Peter Zijlstra <a.p.zijlstra@chello.nl>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11210
Subject		: libata badness
Submitter	: Kumar Gala <galak@kernel.crashing.org>
Date		: 2008-07-31 18:53 (44 days old)
References	: http://marc.info/?l=linux-ide&m=121753059307310&w=4
Handled-By	: Kumar Gala <galak@kernel.crashing.org>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11207
Subject		: VolanoMark regression with 2.6.27-rc1
Submitter	: Zhang, Yanmin <yanmin_zhang@linux.intel.com>
Date		: 2008-07-31 3:20 (44 days old)
References	: http://marc.info/?l=linux-kernel&m=121747464114335&w=4
Handled-By	: Zhang, Yanmin <yanmin_zhang@linux.intel.com>
		  Peter Zijlstra <a.p.zijlstra@chello.nl>
		  Dhaval Giani <dhaval@linux.vnet.ibm.com>
		  Miao Xie <miaox@cn.fujitsu.com>


Regressions with patches
------------------------

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11556
Subject		: e100: PCI wake-up handling rework causes "Error clearing wake event"
Submitter	: Frans Pop <elendil@planet.nl>
Date		: 2008-09-09 6:12 (4 days old)
References	: http://marc.info/?l=linux-netdev&m=122094080712131&w=4
Handled-By	: Rafael J. Wysocki <rjw@sisk.pl>
Patch		: http://marc.info/?l=linux-kernel&m=122096638020191&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11555
Subject		: rmmod ide-cd_mod: tried to init an initialized  object, something is seriously wrong.
Submitter	: Mariusz Kozlowski <m.kozlowski@tuxland.pl>
Date		: 2008-07-16 2:22 (59 days old)
References	: http://marc.info/?l=linux-ide&m=122061839713526&w=4
Handled-By	: Jens Axboe <jens.axboe@oracle.com>
Patch		: http://marc.info/?l=linux-kernel&m=122095622602315&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11550
Subject		: pnp: Huge number of "io resource overlap" messages
Submitter	: Frans Pop <elendil@planet.nl>
Date		: 2008-09-09 10:50 (4 days old)
References	: http://marc.info/?l=linux-kernel&m=122095745403793&w=4
Handled-By	: Rene Herman <rene.herman@keyaccess.nl>
		  Bjorn Helgaas <bjorn.helgaas@hp.com>
Patch		: http://marc.info/?l=linux-kernel&m=122098498125536&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11549
Subject		: 2.6.27-rc5 acpi: EC Storm error message on bootup
Submitter	: <jmerkey@wolfmountaingroup.com>
Date		: 2008-09-02 21:27 (11 days old)
References	: http://marc.info/?l=linux-kernel&m=122039255517586&w=4
Handled-By	: Alexey Starikovskiy <astarikovskiy@suse.de>
Patch		: http://marc.info/?l=linux-kernel&m=122098180019264&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11547
Subject		: build issue #565 for v2.6.27-rc5 : undefined reference to `ei_interrupt' in hp-plus.c
Submitter	: Toralf Förster <toralf.foerster@gmx.de>
Date		: 2008-09-07 13:19 (6 days old)
References	: http://marc.info/?l=linux-kernel&m=122079361508022&w=4
Handled-By	: Randy.Dunlap <rdunlap@xenotime.net>
Patch		: http://marc.info/?l=linux-next&m=122038632306156&w=2


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11507
Subject		: usb: sometimes dead keyboard after boot
Submitter	: Frans Pop <elendil@planet.nl>
Date		: 2008-08-26 21:03 (18 days old)
References	: http://marc.info/?l=linux-kernel&m=121977815018224&w=2
Handled-By	: Alan Stern <stern@rowland.harvard.edu>
Patch		: http://www.spinics.net/lists/linux-usb/msg09735.html


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11442
Subject		: btusb hibernation/suspend breakage in current -git
Submitter	: Rafael J. Wysocki <rjw@sisk.pl>
Date		: 2008-08-25 11:37 (19 days old)
References	: http://marc.info/?l=linux-bluetooth&m=121966402012074&w=4
Handled-By	: Oliver Neukum <oliver@neukum.org>
Patch		: http://marc.info/?l=linux-bluetooth&m=121967226027323&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11439
Subject		: [2.6.27-rc4-git4] compilation warnings
Submitter	: Rufus &amp; Azrael <rufus-azrael@numericable.fr>
Date		: 2008-08-26 9:37 (18 days old)
References	: http://marc.info/?l=linux-kernel&m=121974353815440&w=4
Handled-By	: Greg KH <gregkh@suse.de>
Patch		: http://marc.info/?l=linux-kernel&m=121976424221858&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11382
Subject		: e1000e: 2.6.27-rc1 corrupts EEPROM/NVM
Submitter	: David Vrabel <david.vrabel@csr.com>
Date		: 2008-08-08 10:47 (36 days old)
References	: http://marc.info/?l=linux-kernel&m=121819267211679&w=4
Handled-By	: Christopher Li <chrisl@vmware.com>
Patch		: http://marc.info/?l=linux-mm-commits&m=122038324200305&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11358
Subject		: net: forcedeth call restore mac addr in nv_shutdown path
Submitter	: Yinghai Lu <yhlu.kernel@gmail.com>
Date		: 2008-08-17 3:30 (27 days old)
References	: http://marc.info/?l=linux-kernel&m=121894389018584&w=4
Handled-By	: Yinghai Lu <yhlu.kernel@gmail.com>
Patch		: http://marc.info/?l=linux-kernel&m=121894389018584&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11336
Subject		: 2.6.27-rc2:stall while mounting root fs
Submitter	: Torsten Kaiser <just.for.lkml@googlemail.com>
Date		: 2008-08-12 12:37 (32 days old)
References	: http://marc.info/?l=linux-kernel&m=121854484015909&w=4
Handled-By	: Thomas Gleixner <tglx@linutronix.de>
Patch		: http://bugzilla.kernel.org/attachment.cgi?id=17622


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11276
Subject		: build error: CONFIG_OPTIMIZE_INLINING=y causes gcc 4.2 to do stupid things
Submitter	: Randy Dunlap <randy.dunlap@oracle.com>
Date		: 2008-08-06 17:18 (38 days old)
References	: http://marc.info/?l=linux-kernel&m=121804329014332&w=4
		  http://lkml.org/lkml/2008/7/22/353
Handled-By	: Bjorn Helgaas <bjorn.helgaas@hp.com>
Patch		: http://lkml.org/lkml/2008/7/22/364


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11237
Subject		: corrupt PMD after resume
Submitter	: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Date		: 2008-08-02 9:51 (42 days old)
References	: http://marc.info/?l=linux-kernel&m=121767073424952&w=4
Handled-By	: Hugh Dickins <hugh@veritas.com>
		  Jeremy Fitzhardinge <jeremy@goop.org>
Patch		: http://marc.info/?l=linux-kernel&m=122001615314700&w=2


For details, please visit the bug entries and follow the links given in
references.

As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions from 2.6.26,
unresolved as well as resolved, at:

http://bugzilla.kernel.org/show_bug.cgi?id=11167

Please let me know if there are any Bugzilla entries that should be added to
the list in there.

Thanks,
Rafael

[Bug #11207] VolanoMark regression with 2.6.27-rc1

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11207
Subject		: VolanoMark regression with 2.6.27-rc1
Submitter	: Zhang, Yanmin <yanmin_zhang@linux.intel.com>
Date		: 2008-07-31 3:20 (44 days old)
References	: http://marc.info/?l=linux-kernel&m=121747464114335&w=4
Handled-By	: Zhang, Yanmin <yanmin_zhang@linux.intel.com>
		  Peter Zijlstra <a.p.zijlstra@chello.nl>
		  Dhaval Giani <dhaval@linux.vnet.ibm.com>
		  Miao Xie <miaox@cn.fujitsu.com>

[Bug #11210] libata badness

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11210
Subject		: libata badness
Submitter	: Kumar Gala <galak@kernel.crashing.org>
Date		: 2008-07-31 18:53 (44 days old)
References	: http://marc.info/?l=linux-ide&m=121753059307310&w=4
Handled-By	: Kumar Gala <galak@kernel.crashing.org>

[Bug #11220] Screen stays black after resume

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11220
Subject		: Screen stays black after resume
Submitter	: Nico Schottelius <nico@schottelius.org>
Date		: 2008-07-31 21:05 (44 days old)
References	: http://marc.info/?l=linux-kernel&m=121753882422899&w=4

[Bug #11215] INFO: possible recursive locking detected ps2_command

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11215
Subject		: INFO: possible recursive locking detected ps2_command
Submitter	: Zdenek Kabelac <zdenek.kabelac@gmail.com>
Date		: 2008-07-31 9:41 (44 days old)
References	: http://marc.info/?l=linux-kernel&m=121749737011637&w=4
Handled-By	: Peter Zijlstra <a.p.zijlstra@chello.nl>

[Bug #11224] Only three cores found on quad-core machine.

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11224
Subject		: Only three cores found on quad-core machine.
Submitter	: Dave Jones <davej@redhat.com>
Date		: 2008-08-01 18:15 (43 days old)
References	: http://marc.info/?l=linux-kernel&m=121761475224719&w=4

[Bug #11230] Kconfig no longer outputs a .config with freshly updated defconfigs

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11230
Subject		: Kconfig no longer outputs a .config with freshly updated defconfigs
Submitter	: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Date		: 2008-08-02 16:03 (42 days old)
References	: http://marc.info/?l=linux-kernel&m=121769306319391&w=4

[Bug #11237] corrupt PMD after resume

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11237
Subject		: corrupt PMD after resume
Submitter	: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Date		: 2008-08-02 9:51 (42 days old)
References	: http://marc.info/?l=linux-kernel&m=121767073424952&w=4
Handled-By	: Hugh Dickins <hugh@veritas.com>
		  Jeremy Fitzhardinge <jeremy@goop.org>
Patch		: http://marc.info/?l=linux-kernel&m=122001615314700&w=2

[Bug #11264] Invalid op opcode in kernel/workqueue

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11264
Subject		: Invalid op opcode in kernel/workqueue
Submitter	: Jean-Luc Coulon <jean.luc.coulon@gmail.com>
Date		: 2008-08-07 04:18 (37 days old)

[Bug #11271] BUG: fealnx in 2.6.27-rc1

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11271
Subject		: BUG: fealnx in 2.6.27-rc1
Submitter	: Jaswinder Singh <jaswinderlinux@gmail.com>
Date		: 2008-08-05 14:58 (39 days old)
References	: http://marc.info/?l=linux-netdev&m=121794762016830&w=4
		  http://lkml.org/lkml/2008/8/10/98
Handled-By	: Francois Romieu <romieu@fr.zoreil.com>

[Bug #11276] build error: CONFIG_OPTIMIZE_INLINING=y causes gcc 4.2 to do stupid things

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11276
Subject		: build error: CONFIG_OPTIMIZE_INLINING=y causes gcc 4.2 to do stupid things
Submitter	: Randy Dunlap <randy.dunlap@oracle.com>
Date		: 2008-08-06 17:18 (38 days old)
References	: http://marc.info/?l=linux-kernel&m=121804329014332&w=4
		  http://lkml.org/lkml/2008/7/22/353
Handled-By	: Bjorn Helgaas <bjorn.helgaas@hp.com>
Patch		: http://lkml.org/lkml/2008/7/22/364

[Bug #11272] BUG: parport_serial in 2.6.27-rc1 for NetMos Technology PCI 9835

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11272
Subject		: BUG: parport_serial in 2.6.27-rc1 for NetMos Technology PCI 9835
Submitter	: Jaswinder Singh <jaswinderlinux@gmail.com>
Date		: 2008-08-05 15:12 (39 days old)
References	: http://marc.info/?l=linux-kernel&m=121794900319776&w=4

[Bug #11308] tbench regression on each kernel release from 2.6.22 -> 2.6.28

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11308
Subject		: tbench regression on each kernel release from 2.6.22 -> 2.6.28
Submitter	: Christoph Lameter <cl@linux-foundation.org>
Date		: 2008-08-11 18:36 (33 days old)
References	: http://marc.info/?l=linux-kernel&m=121847986119495&w=4

[Bug #11335] 2.6.27-rc2-git5 BUG: unable to handle kernel paging request

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11335
Subject		: 2.6.27-rc2-git5 BUG: unable to handle kernel paging request
Submitter	: Randy Dunlap <randy.dunlap@oracle.com>
Date		: 2008-08-12 4:18 (32 days old)
References	: http://marc.info/?l=linux-kernel&m=121851477201960&w=4
		  http://lkml.org/lkml/2008/8/16/274
Handled-By	: Hugh Dickins <hugh@veritas.com>

[Bug #11336] 2.6.27-rc2:stall while mounting root fs

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11336
Subject		: 2.6.27-rc2:stall while mounting root fs
Submitter	: Torsten Kaiser <just.for.lkml@googlemail.com>
Date		: 2008-08-12 12:37 (32 days old)
References	: http://marc.info/?l=linux-kernel&m=121854484015909&w=4
Handled-By	: Thomas Gleixner <tglx@linutronix.de>
Patch		: http://bugzilla.kernel.org/attachment.cgi?id=17622

[Bug #11340] LTP overnight run resulted in unusable box

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11340
Subject		: LTP overnight run resulted in unusable box
Submitter	: Alexey Dobriyan <adobriyan@gmail.com>
Date		: 2008-08-13 9:24 (31 days old)
References	: http://marc.info/?l=linux-kernel&m=121861951902949&w=4

[Bug #11343] SATA Cold Boot Problems with 2.6.27-rc[23] on nVidia 680i

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11343
Subject		: SATA Cold Boot Problems with 2.6.27-rc[23] on nVidia 680i
Submitter	: Manny Maxwell <mannymax@mannymax.net>
Date		: 2008-08-14 4:16 (30 days old)
References	: http://marc.info/?l=linux-kernel&m=121868782917600&w=4

[Bug #11380] lockdep warning: cpu_add_remove_lock at:cpu_maps_update_begin+0x14/0x16

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11380
Subject		: lockdep warning: cpu_add_remove_lock at:cpu_maps_update_begin+0x14/0x16
Submitter	: Ingo Molnar <mingo@elte.hu>
Date		: 2008-08-20 6:44 (24 days old)
References	: http://marc.info/?l=linux-kernel&m=121921480931970&w=4

[Bug #11358] net: forcedeth call restore mac addr in nv_shutdown path

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11358
Subject		: net: forcedeth call restore mac addr in nv_shutdown path
Submitter	: Yinghai Lu <yhlu.kernel@gmail.com>
Date		: 2008-08-17 3:30 (27 days old)
References	: http://marc.info/?l=linux-kernel&m=121894389018584&w=4
Handled-By	: Yinghai Lu <yhlu.kernel@gmail.com>
Patch		: http://marc.info/?l=linux-kernel&m=121894389018584&w=4

[Bug #11357] Can not boot up with zd1211rw USB-Wlan Stick

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11357
Subject		: Can not boot up with zd1211rw USB-Wlan Stick
Submitter	: uwe <kender@freenet.de>
Date		: 2008-08-16 14:17 (28 days old)

[Bug #11404] BUG: in 2.6.23-rc3-git7 in do_cciss_intr

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11404
Subject		: BUG: in 2.6.23-rc3-git7 in do_cciss_intr
Submitter	: rdunlap <randy.dunlap@oracle.com>
Date		: 2008-08-21 5:52 (23 days old)
References	: http://marc.info/?l=linux-kernel&m=121929819616273&w=4
		  http://marc.info/?l=linux-kernel&m=121932889105368&w=4
Handled-By	: Miller, Mike (OS Dev) <Mike.Miller@hp.com>
		  James Bottomley <James.Bottomley@hansenpartnership.com>

[Bug #11382] e1000e: 2.6.27-rc1 corrupts EEPROM/NVM

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11382
Subject		: e1000e: 2.6.27-rc1 corrupts EEPROM/NVM
Submitter	: David Vrabel <david.vrabel@csr.com>
Date		: 2008-08-08 10:47 (36 days old)
References	: http://marc.info/?l=linux-kernel&m=121819267211679&w=4
Handled-By	: Christopher Li <chrisl@vmware.com>
Patch		: http://marc.info/?l=linux-mm-commits&m=122038324200305&w=4

[Bug #11398] hda_intel: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj.

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11398
Subject		: hda_intel: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj.
Submitter	: Frans Pop <elendil@planet.nl>
Date		: 2008-08-21 17:17 (23 days old)

[Bug #11407] suspend: unable to handle kernel paging request

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11407
Subject		: suspend: unable to handle kernel paging request
Submitter	: Vegard Nossum <vegard.nossum@gmail.com>
Date		: 2008-08-21 17:28 (23 days old)
References	: http://marc.info/?l=linux-kernel&m=121933974928881&w=4
Handled-By	: Rafael J. Wysocki <rjw@sisk.pl>
		  Pekka Enberg <penberg@cs.helsinki.fi>
		  Pavel Machek <pavel@suse.cz>

[Bug #11439] [2.6.27-rc4-git4] compilation warnings

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11439
Subject		: [2.6.27-rc4-git4] compilation warnings
Submitter	: Rufus &amp; Azrael <rufus-azrael@numericable.fr>
Date		: 2008-08-26 9:37 (18 days old)
References	: http://marc.info/?l=linux-kernel&m=121974353815440&w=4
Handled-By	: Greg KH <gregkh@suse.de>
Patch		: http://marc.info/?l=linux-kernel&m=121976424221858&w=4

[Bug #11442] btusb hibernation/suspend breakage in current -git

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11442
Subject		: btusb hibernation/suspend breakage in current -git
Submitter	: Rafael J. Wysocki <rjw@sisk.pl>
Date		: 2008-08-25 11:37 (19 days old)
References	: http://marc.info/?l=linux-bluetooth&m=121966402012074&w=4
Handled-By	: Oliver Neukum <oliver@neukum.org>
Patch		: http://marc.info/?l=linux-bluetooth&m=121967226027323&w=4

[Bug #11459] kernel crash after wifi connection established

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11459
Subject		: kernel crash after wifi connection established
Submitter	: Alexey Kuznetsov <ak@axet.ru>
Date		: 2008-08-30 03:08 (14 days old)

[Bug #11463] sshd hangs on close

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11463
Subject		: sshd hangs on close
Submitter	: Matthias Urlichs <matthias@urlichs.de>
Date		: 2008-08-30 9:18 (14 days old)
References	: http://marc.info/?l=linux-kernel&m=122008800512864&w=4

[Bug #11465] Linux-2.6.27-rc5, drm errors in log

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11465
Subject		: Linux-2.6.27-rc5, drm errors in log
Submitter	: Gene Heskett <gene.heskett@verizon.net>
Date		: 2008-08-30 18:52 (14 days old)
References	: http://marc.info/?l=linux-kernel&m=122012238925775&w=4
Handled-By	: Dave Airlie <airlied@gmail.com>

[Bug #11471] GPE storm detected, kernel freezes

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11471
Subject		: GPE storm detected, kernel freezes
Submitter	: George Gibbs <Vash63@gmail.com>
Date		: 2008-08-31 22:00 (13 days old)
Handled-By	: Zhang Rui <rui.zhang@intel.com>

[Bug #11476] failure to associate after resume from suspend to ram

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11476
Subject		: failure to associate after resume from suspend to ram
Submitter	: Michael S. Tsirkin <m.s.tsirkin@gmail.com>
Date		: 2008-09-01 13:33 (12 days old)
References	: http://marc.info/?l=linux-kernel&m=122028529415108&w=4
Handled-By	: Zhu Yi <yi.zhu@intel.com>
		  Dan Williams <dcbw@redhat.com>
		  Jouni Malinen <j@w1.fi>

[Bug #11500] /proc/net bug related to selinux

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11500
Subject		: /proc/net bug related to selinux
Submitter	: Andrew Morton <akpm@linux-foundation.org>
Date		: 2008-09-04 17:45 (9 days old)
References	: http://marc.info/?l=linux-kernel&m=122055041313270&w=4

[Bug #11485] 2.6.27-rc xen pvops regression?

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11485
Subject		: 2.6.27-rc xen pvops regression?
Submitter	: Bernhard Schmidt <berni@birkenwald.de>
Date		: 2008-08-31 17:18 (13 days old)
References	: http://marc.info/?l=linux-kernel&m=122020367015025&w=4
Handled-By	: Alex Nixon <alex.nixon@citrix.com>
		  Jeremy Fitzhardinge <jeremy@goop.org>

[Bug #11501] Failed to open destination file: Permission deniedihex2fw

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11501
Subject		: Failed to open destination file: Permission deniedihex2fw
Submitter	: Andrew Morton <akpm@linux-foundation.org>
Date		: 2008-09-04 18:34 (9 days old)
References	: http://marc.info/?l=linux-kernel&m=122055342419068&w=4

[Bug #11505] oltp ~10% regression with 2.6.27-rc5 on stoakley machine

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11505
Subject		: oltp ~10% regression with 2.6.27-rc5 on stoakley machine
Submitter	: Lin Ming <ming.m.lin@intel.com>
Date		: 2008-09-04 7:06 (9 days old)
References	: http://marc.info/?l=linux-kernel&m=122051202202373&w=4
		  http://marc.info/?t=122089704700005&r=1&w=4
Handled-By	: Peter Zijlstra <a.p.zijlstra@chello.nl>
		  Gregory Haskins <ghaskins@novell.com>
		  Ingo Molnar <mingo@elte.hu>

[Bug #11506] oops during unmount - ext3? (2.6.27-rc5)

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11506
Subject		: oops during unmount - ext3? (2.6.27-rc5)
Submitter	: Marcin Slusarz <marcin.slusarz@gmail.com>
Date		: 2008-09-04 19:14 (9 days old)
References	: http://marc.info/?l=linux-kernel&m=122055573123449&w=4

[Bug #11507] usb: sometimes dead keyboard after boot

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11507
Subject		: usb: sometimes dead keyboard after boot
Submitter	: Frans Pop <elendil@planet.nl>
Date		: 2008-08-26 21:03 (18 days old)
References	: http://marc.info/?l=linux-kernel&m=121977815018224&w=2
Handled-By	: Alan Stern <stern@rowland.harvard.edu>
Patch		: http://www.spinics.net/lists/linux-usb/msg09735.html

[Bug #11512] sort-of regression due to "kconfig: speed up all*config + randconfig"

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11512
Subject		: sort-of regression due to "kconfig: speed up all*config + randconfig"
Submitter	: Alexey Dobriyan <adobriyan@gmail.com>
Date		: 2008-09-05 22:50 (8 days old)
References	: http://marc.info/?l=linux-kernel&m=122065498013858&w=4

[Bug #11516] severe performance degradation on x86_64 going from 2.6.26-rc9 -> 2.6.27-rc5

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11516
Subject		: severe performance degradation on x86_64 going from 2.6.26-rc9 -> 2.6.27-rc5
Submitter	: Jason Vas Dias <jason.vas.dias@gmail.com>
Date		: 2008-09-07 13:59 (6 days old)

[Bug #11549] 2.6.27-rc5 acpi: EC Storm error message on bootup

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11549
Subject		: 2.6.27-rc5 acpi: EC Storm error message on bootup
Submitter	: <jmerkey@wolfmountaingroup.com>
Date		: 2008-09-02 21:27 (11 days old)
References	: http://marc.info/?l=linux-kernel&m=122039255517586&w=4
Handled-By	: Alexey Starikovskiy <astarikovskiy@suse.de>
Patch		: http://marc.info/?l=linux-kernel&m=122098180019264&w=4

[Bug #11548] kernel BUG at drivers/pci/intel-iommu.c:1373!

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11548
Subject		: kernel BUG at drivers/pci/intel-iommu.c:1373!
Submitter	: Chris Mason <chris.mason@oracle.com>
Date		: 2008-09-08 14:26 (5 days old)
References	: http://marc.info/?l=linux-kernel&m=122088566310440&w=4

[Bug #11547] build issue #565 for v2.6.27-rc5 : undefined reference to `ei_interrupt' in hp-plus.c

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11547
Subject		: build issue #565 for v2.6.27-rc5 : undefined reference to `ei_interrupt' in hp-plus.c
Submitter	: Toralf Förster <toralf.foerster@gmx.de>
Date		: 2008-09-07 13:19 (6 days old)
References	: http://marc.info/?l=linux-kernel&m=122079361508022&w=4
Handled-By	: Randy.Dunlap <rdunlap@xenotime.net>
Patch		: http://marc.info/?l=linux-next&m=122038632306156&w=2

[Bug #11552] Disabling IRQ #23

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11552
Subject		: Disabling IRQ #23
Submitter	: Justin Mattock <justinmattock@gmail.com>
Date		: 2008-09-09 19:08 (4 days old)
References	: http://marc.info/?l=linux-kernel&m=122098735230906&w=4
		  http://marc.info/?l=linux-kernel&m=122107367715361&w=4
Handled-By	: Yinghai Lu <yhlu.kernel@gmail.com>

[Bug #11551] Semi-repeatable hard lockup on 2.6.27-rc6

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11551
Subject		: Semi-repeatable hard lockup on 2.6.27-rc6
Submitter	: Steven Noonan <steven@uplinklabs.net>
Date		: 2008-09-10 18:07 (3 days old)
References	: http://marc.info/?l=linux-kernel&m=122107007407994&w=4

[Bug #11550] pnp: Huge number of "io resource overlap" messages

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11550
Subject		: pnp: Huge number of "io resource overlap" messages
Submitter	: Frans Pop <elendil@planet.nl>
Date		: 2008-09-09 10:50 (4 days old)
References	: http://marc.info/?l=linux-kernel&m=122095745403793&w=4
Handled-By	: Rene Herman <rene.herman@keyaccess.nl>
		  Bjorn Helgaas <bjorn.helgaas@hp.com>
Patch		: http://marc.info/?l=linux-kernel&m=122098498125536&w=4

[Bug #11553] Strange looking line from "ps aux"

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11553
Subject		: Strange looking line from "ps aux"
Submitter	: Rogério Brito <rbrito@ime.usp.br>
Date		: 2008-09-11 17:43 (2 days old)
References	: http://marc.info/?l=linux-kernel&m=122115506018275&w=4

[Bug #11554] Partition check considered as error is breaking mounting in 2.6.27

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11554
Subject		: Partition check considered as error is breaking mounting in 2.6.27
Submitter	: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
Date		: 2008-09-12 16:56 (1 days old)
References	: http://marc.info/?l=linux-kernel&m=122123862519434&w=4

[Bug #11556] e100: PCI wake-up handling rework causes "Error clearing wake event"

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11556
Subject		: e100: PCI wake-up handling rework causes "Error clearing wake event"
Submitter	: Frans Pop <elendil@planet.nl>
Date		: 2008-09-09 6:12 (4 days old)
References	: http://marc.info/?l=linux-netdev&m=122094080712131&w=4
Handled-By	: Rafael J. Wysocki <rjw@sisk.pl>
Patch		: http://marc.info/?l=linux-kernel&m=122096638020191&w=4

[Bug #11557] Controlling backlight on thinkpad x60

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11557
Subject		: Controlling backlight on thinkpad x60
Submitter	: Pavel Machek <pavel@suse.cz>
Date		: 2008-09-08 15:10 (5 days old)
References	: http://marc.info/?l=linux-kernel&m=122088987319698&w=4
Handled-By	: Matthew Garrett <mjg59@srcf.ucam.org>

[Bug #11559] 2.6.27-rc6: nohz + s2ram = need to press keys to get progress

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11559
Subject		: 2.6.27-rc6: nohz + s2ram = need to press keys to get progress
Submitter	: Pavel Machek <pavel@suse.cz>
Date		: 2008-09-12 8:31 (1 days old)
References	: http://marc.info/?l=linux-kernel&m=122121384705262&w=4

Re: [Bug #11276] build error: CONFIG_OPTIMIZE_INLINING=y causes gcc 4.2 to do stupid things

[Randy Dunlap]

Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.26.  Please verify if it still should be listed and let me know
> (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11276
> Subject		: build error: CONFIG_OPTIMIZE_INLINING=y causes gcc 4.2 to do stupid things
> Submitter	: Randy Dunlap <randy.dunlap@oracle.com>
> Date		: 2008-08-06 17:18 (38 days old)
> References	: http://marc.info/?l=linux-kernel&m=121804329014332&w=4
> 		  http://lkml.org/lkml/2008/7/22/353
> Handled-By	: Bjorn Helgaas <bjorn.helgaas@hp.com>
> Patch		: http://lkml.org/lkml/2008/7/22/364

Yes, I still see this build error.
What would it take to have Bjorn's patch merged into mainline?

-- 
~Randy
Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA
http://linuxplumbersconf.org/

Re: [Bug #11407] suspend: unable to handle kernel paging request

[Vegard Nossum]

On Fri, Sep 12, 2008 at 9:06 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.26.  Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=11407
> Subject         : suspend: unable to handle kernel paging request
> Submitter       : Vegard Nossum <vegard.nossum@gmail.com>
> Date            : 2008-08-21 17:28 (23 days old)
> References      : http://marc.info/?l=linux-kernel&m=121933974928881&w=4
> Handled-By      : Rafael J. Wysocki <rjw@sisk.pl>
>                  Pekka Enberg <penberg@cs.helsinki.fi>
>                  Pavel Machek <pavel@suse.cz>

I'm sorry for not replying sooner. This is current status: Problem was
never resolved. I tried to bisect, but I only ran into other problems
with either config not being supported for my machine prior to certain
date while trying to find a good bisection point. It's been a while
now, so I don't remember everything exactly, but I may try to
reproduce it tomorrow on the latest -git and see what comes up.

Will report back as soon as I have more info. Thanks,


Vegard

-- 
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
	-- E. W. Dijkstra, EWD1036

Re: [Bug #11548] kernel BUG at drivers/pci/intel-iommu.c:1373!

[Chris Mason]

On Fri, 2008-09-12 at 21:06 +0200, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.26.  Please verify if it still should be listed and let me know
> (either way).
> 

This is still a bug, but I haven't tried this workload on 2.6.26, so I'm
not sure it is a regression.  Unfortunately, I won't be able to test it
again until after the plumber's conference.

-chris

Re: [Bug #11276] build error: CONFIG_OPTIMIZE_INLINING=y causes gcc 4.2 to do stupid things

[Rafael J. Wysocki]

On Friday, 12 of September 2008, Randy Dunlap wrote:
> Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> > 
> > The following bug entry is on the current list of known regressions
> > from 2.6.26.  Please verify if it still should be listed and let me know
> > (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11276
> > Subject		: build error: CONFIG_OPTIMIZE_INLINING=y causes gcc 4.2 to do stupid things
> > Submitter	: Randy Dunlap <randy.dunlap@oracle.com>
> > Date		: 2008-08-06 17:18 (38 days old)
> > References	: http://marc.info/?l=linux-kernel&m=121804329014332&w=4
> > 		  http://lkml.org/lkml/2008/7/22/353
> > Handled-By	: Bjorn Helgaas <bjorn.helgaas@hp.com>
> > Patch		: http://lkml.org/lkml/2008/7/22/364
> 
> Yes, I still see this build error.
> What would it take to have Bjorn's patch merged into mainline?

Well, send a request to Andrew I think (with the patch appended).

Thanks,
Rafael

Re: [Bug #11548] kernel BUG at drivers/pci/intel-iommu.c:1373!

[Rafael J. Wysocki]

On Friday, 12 of September 2008, Chris Mason wrote:
> On Fri, 2008-09-12 at 21:06 +0200, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> > 
> > The following bug entry is on the current list of known regressions
> > from 2.6.26.  Please verify if it still should be listed and let me know
> > (either way).
> > 
> 
> This is still a bug, but I haven't tried this workload on 2.6.26, so I'm
> not sure it is a regression.  Unfortunately, I won't be able to test it
> again until after the plumber's conference.

That's fine.  In case it turns out to be a regression, it's better to list it
for now IMO. :-)

Thanks,
Rafael

Re: [Bug #11308] tbench regression on each kernel release from 2.6.22 -> 2.6.28

[Christoph Lameter]

Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.26.  Please verify if it still should be listed and let me know
> (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11308
> Subject		: tbench regression on each kernel release from 2.6.22 -> 2.6.28
> Submitter	: Christoph Lameter <cl@linux-foundation.org>
> Date		: 2008-08-11 18:36 (33 days old)
> References	: http://marc.info/?l=linux-kernel&m=121847986119495&w=4
> 
> 
> 

tbench

2.6.27-rc6	2760 MB/sec
2.6.22 		3235.47 MB/sec

diff on the .config files for each (took .22 config and did a make oldconfig)

--- /boot/config-2.6.22.1-4U4JUMP1.12	2008-01-22 08:06:38.000000000 -0600
+++ .config	2008-09-12 16:33:52.000000000 -0500
@@ -1,55 +1,89 @@
 #
 # Automatically generated make config: don't edit
-# Linux kernel version: 2.6.22.1-4U4JUMP1.12
-# Mon Jan 21 16:05:52 2008
+# Linux kernel version: 2.6.27-rc6
+# Fri Sep 12 16:33:52 2008
 #
+# CONFIG_64BIT is not set
 CONFIG_X86_32=y
+# CONFIG_X86_64 is not set
+CONFIG_X86=y
+CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
+# CONFIG_GENERIC_LOCKBREAK is not set
 CONFIG_GENERIC_TIME=y
+CONFIG_GENERIC_CMOS_UPDATE=y
 CONFIG_CLOCKSOURCE_WATCHDOG=y
 CONFIG_GENERIC_CLOCKEVENTS=y
 CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
 CONFIG_LOCKDEP_SUPPORT=y
 CONFIG_STACKTRACE_SUPPORT=y
-CONFIG_SEMAPHORE_SLEEPERS=y
-CONFIG_X86=y
+CONFIG_HAVE_LATENCYTOP_SUPPORT=y
+CONFIG_FAST_CMPXCHG_LOCAL=y
 CONFIG_MMU=y
 CONFIG_ZONE_DMA=y
-CONFIG_QUICKLIST=y
 CONFIG_GENERIC_ISA_DMA=y
 CONFIG_GENERIC_IOMAP=y
 CONFIG_GENERIC_BUG=y
 CONFIG_GENERIC_HWEIGHT=y
+# CONFIG_GENERIC_GPIO is not set
 CONFIG_ARCH_MAY_HAVE_PC_FDC=y
-CONFIG_DMI=y
+# CONFIG_RWSEM_GENERIC_SPINLOCK is not set
+CONFIG_RWSEM_XCHGADD_ALGORITHM=y
+# CONFIG_ARCH_HAS_ILOG2_U32 is not set
+# CONFIG_ARCH_HAS_ILOG2_U64 is not set
+CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y
+CONFIG_GENERIC_CALIBRATE_DELAY=y
+# CONFIG_GENERIC_TIME_VSYSCALL is not set
+CONFIG_ARCH_HAS_CPU_RELAX=y
+CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
+CONFIG_HAVE_SETUP_PER_CPU_AREA=y
+# CONFIG_HAVE_CPUMASK_OF_CPU_MAP is not set
+CONFIG_ARCH_HIBERNATION_POSSIBLE=y
+CONFIG_ARCH_SUSPEND_POSSIBLE=y
+# CONFIG_ZONE_DMA32 is not set
+CONFIG_ARCH_POPULATES_NODE_MAP=y
+# CONFIG_AUDIT_ARCH is not set
+CONFIG_ARCH_SUPPORTS_AOUT=y
+CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
+CONFIG_GENERIC_HARDIRQS=y
+CONFIG_GENERIC_IRQ_PROBE=y
+CONFIG_GENERIC_PENDING_IRQ=y
+CONFIG_X86_SMP=y
+CONFIG_X86_32_SMP=y
+CONFIG_X86_HT=y
+CONFIG_X86_BIOS_REBOOT=y
+CONFIG_X86_TRAMPOLINE=y
+CONFIG_KTIME_SCALAR=y
 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

 #
-# Code maturity level options
+# General setup
 #
 CONFIG_EXPERIMENTAL=y
 CONFIG_LOCK_KERNEL=y
 CONFIG_INIT_ENV_ARG_LIMIT=32
-
-#
-# General setup
-#
 CONFIG_LOCALVERSION=""
 CONFIG_LOCALVERSION_AUTO=y
 CONFIG_SWAP=y
 CONFIG_SYSVIPC=y
-# CONFIG_IPC_NS is not set
 CONFIG_SYSVIPC_SYSCTL=y
 CONFIG_POSIX_MQUEUE=y
 # CONFIG_BSD_PROCESS_ACCT is not set
 # CONFIG_TASKSTATS is not set
-# CONFIG_UTS_NS is not set
 # CONFIG_AUDIT is not set
 CONFIG_IKCONFIG=y
 CONFIG_IKCONFIG_PROC=y
 CONFIG_LOG_BUF_SHIFT=18
-# CONFIG_CPUSETS is not set
+# CONFIG_CGROUPS is not set
+CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
+# CONFIG_GROUP_SCHED is not set
 CONFIG_SYSFS_DEPRECATED=y
+CONFIG_SYSFS_DEPRECATED_V2=y
 # CONFIG_RELAY is not set
+CONFIG_NAMESPACES=y
+# CONFIG_UTS_NS is not set
+# CONFIG_IPC_NS is not set
+# CONFIG_USER_NS is not set
+# CONFIG_PID_NS is not set
 CONFIG_BLK_DEV_INITRD=y
 CONFIG_INITRAMFS_SOURCE=""
 CONFIG_CC_OPTIMIZE_FOR_SIZE=y
@@ -64,6 +98,8 @@
 CONFIG_PRINTK=y
 CONFIG_BUG=y
 CONFIG_ELF_CORE=y
+CONFIG_PCSPKR_PLATFORM=y
+CONFIG_COMPAT_BRK=y
 CONFIG_BASE_FULL=y
 CONFIG_FUTEX=y
 CONFIG_ANON_INODES=y
@@ -76,28 +112,40 @@
 CONFIG_SLAB=y
 # CONFIG_SLUB is not set
 # CONFIG_SLOB is not set
+CONFIG_PROFILING=y
+# CONFIG_MARKERS is not set
+CONFIG_OPROFILE=y
+CONFIG_HAVE_OPROFILE=y
+CONFIG_KPROBES=y
+CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
+CONFIG_KRETPROBES=y
+CONFIG_HAVE_IOREMAP_PROT=y
+CONFIG_HAVE_KPROBES=y
+CONFIG_HAVE_KRETPROBES=y
+# CONFIG_HAVE_ARCH_TRACEHOOK is not set
+# CONFIG_HAVE_DMA_ATTRS is not set
+CONFIG_USE_GENERIC_SMP_HELPERS=y
+# CONFIG_HAVE_CLK is not set
+CONFIG_PROC_PAGE_MONITOR=y
+CONFIG_HAVE_GENERIC_DMA_COHERENT=y
+CONFIG_SLABINFO=y
 CONFIG_RT_MUTEXES=y
 # CONFIG_TINY_SHMEM is not set
 CONFIG_BASE_SMALL=0
-
-#
-# Loadable module support
-#
 CONFIG_MODULES=y
+# CONFIG_MODULE_FORCE_LOAD is not set
 CONFIG_MODULE_UNLOAD=y
 CONFIG_MODULE_FORCE_UNLOAD=y
 # CONFIG_MODVERSIONS is not set
 # CONFIG_MODULE_SRCVERSION_ALL is not set
-# CONFIG_KMOD is not set
+CONFIG_KMOD=y
 CONFIG_STOP_MACHINE=y
-
-#
-# Block layer
-#
 CONFIG_BLOCK=y
 CONFIG_LBD=y
 # CONFIG_BLK_DEV_IO_TRACE is not set
 # CONFIG_LSF is not set
+# CONFIG_BLK_DEV_BSG is not set
+# CONFIG_BLK_DEV_INTEGRITY is not set

 #
 # IO Schedulers
@@ -111,6 +159,7 @@
 # CONFIG_DEFAULT_CFQ is not set
 # CONFIG_DEFAULT_NOOP is not set
 CONFIG_DEFAULT_IOSCHED="anticipatory"
+CONFIG_CLASSIC_RCU=y

 #
 # Processor type and features
@@ -118,17 +167,23 @@
 CONFIG_TICK_ONESHOT=y
 CONFIG_NO_HZ=y
 CONFIG_HIGH_RES_TIMERS=y
+CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
 CONFIG_SMP=y
+CONFIG_X86_FIND_SMP_CONFIG=y
+CONFIG_X86_MPPARSE=y
 # CONFIG_X86_PC is not set
 # CONFIG_X86_ELAN is not set
 # CONFIG_X86_VOYAGER is not set
+CONFIG_X86_GENERICARCH=y
 # CONFIG_X86_NUMAQ is not set
 # CONFIG_X86_SUMMIT is not set
-# CONFIG_X86_BIGSMP is not set
-# CONFIG_X86_VISWS is not set
-CONFIG_X86_GENERICARCH=y
 # CONFIG_X86_ES7000 is not set
-# CONFIG_PARAVIRT is not set
+# CONFIG_X86_BIGSMP is not set
+# CONFIG_X86_VSMP is not set
+# CONFIG_X86_RDC321X is not set
+CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
+# CONFIG_PARAVIRT_GUEST is not set
+# CONFIG_MEMTEST is not set
 CONFIG_X86_CYCLONE_TIMER=y
 # CONFIG_M386 is not set
 # CONFIG_M486 is not set
@@ -139,7 +194,6 @@
 # CONFIG_MPENTIUMII is not set
 # CONFIG_MPENTIUMIII is not set
 # CONFIG_MPENTIUMM is not set
-CONFIG_MCORE2=y
 # CONFIG_MPENTIUM4 is not set
 # CONFIG_MK6 is not set
 # CONFIG_MK7 is not set
@@ -154,33 +208,34 @@
 # CONFIG_MCYRIXIII is not set
 # CONFIG_MVIAC3_2 is not set
 # CONFIG_MVIAC7 is not set
+# CONFIG_MPSC is not set
+CONFIG_MCORE2=y
+# CONFIG_GENERIC_CPU is not set
 CONFIG_X86_GENERIC=y
+CONFIG_X86_CPU=y
 CONFIG_X86_CMPXCHG=y

Re: [Bug #11500] /proc/net bug related to selinux

[James Morris]

On Fri, 12 Sep 2008, Rafael J. Wysocki wrote:

> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.26.  Please verify if it still should be listed and let me know
> (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11500
> Subject		: /proc/net bug related to selinux
> Submitter	: Andrew Morton <akpm@linux-foundation.org>
> Date		: 2008-09-04 17:45 (9 days old)
> References	: http://marc.info/?l=linux-kernel&m=122055041313270&w=4

I think this might be a regression caused by namespace changes which we 
addressed in SELinux policy.  Which distro version & policy version is 
this seen with?


- James
-- 
James Morris
<jmorris@namei.org>

Re: [Bug #11500] /proc/net bug related to selinux

[Andrew Morton]

On Sat, 13 Sep 2008 08:14:10 +1000 (EST)
James Morris <jmorris@namei.org> wrote:

> On Fri, 12 Sep 2008, Rafael J. Wysocki wrote:
> 
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> > 
> > The following bug entry is on the current list of known regressions
> > from 2.6.26.  Please verify if it still should be listed and let me know
> > (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11500
> > Subject		: /proc/net bug related to selinux
> > Submitter	: Andrew Morton <akpm@linux-foundation.org>
> > Date		: 2008-09-04 17:45 (9 days old)
> > References	: http://marc.info/?l=linux-kernel&m=122055041313270&w=4
> 
> I think this might be a regression caused by namespace changes which we 
> addressed in SELinux policy.  Which distro version & policy version is 
> this seen with?
> 

FC5 on x86_32 and FC6 on x86_64.

Re: [Bug #11550] pnp: Huge number of "io resource overlap" messages

[Rene Herman]

On 12-09-08 21:06, Rafael J. Wysocki wrote:

> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.26.  Please verify if it still should be listed and let me know
> (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11550
> Subject		: pnp: Huge number of "io resource overlap" messages
> Submitter	: Frans Pop <elendil@planet.nl>
> Date		: 2008-09-09 10:50 (4 days old)
> References	: http://marc.info/?l=linux-kernel&m=122095745403793&w=4
> Handled-By	: Rene Herman <rene.herman@keyaccess.nl>
> 		  Bjorn Helgaas <bjorn.helgaas@hp.com>
> Patch		: http://marc.info/?l=linux-kernel&m=122098498125536&w=4

It should be. The patch listed should be good as far as I'm concerned 
but needs to be pushed by Bjorn as PnP mainatainer. Generally speaking 0 
wouldn't be a _very_ necesarily invalid value it seems so it's maybe not 
very nice.

If someone wants a changelog though, this should do:

===
PNP: avoid checking unitialized BARs for conflicts

Avoid checking a PCI BAR for conflicts if the BIOS left it unitialized.

Reported-by: Frans Pop <elendil@planet.nl>
Signed-off-by: Rene Herman <rene.herman@gmail.com>
===

(Frans: Tested-by?)

Rene.

Re: [Bug #11500] /proc/net bug related to selinux

[James Morris]

On Fri, 12 Sep 2008, Andrew Morton wrote:

> > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11500
> > > Subject		: /proc/net bug related to selinux
> > > Submitter	: Andrew Morton <akpm@linux-foundation.org>
> > > Date		: 2008-09-04 17:45 (9 days old)
> > > References	: http://marc.info/?l=linux-kernel&m=122055041313270&w=4
> > 
> > I think this might be a regression caused by namespace changes which we 

By which I mean, this was caused by a non-SELinux change to the upstream 
kernel many, many eons ago.

> > addressed in SELinux policy.  Which distro version & policy version is 
> > this seen with?
> > 
> 
> FC5 on x86_32 and FC6 on x86_64.

As mentioned in the bugzilla, any related avc messages would be useful.


-- 
James Morris
<jmorris@namei.org>

Re: [Bug #11552] Disabling IRQ #23

[Justin Mattock]

On Fri, Sep 12, 2008 at 12:06 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.26.  Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=11552
> Subject         : Disabling IRQ #23
> Submitter       : Justin Mattock <justinmattock@gmail.com>
> Date            : 2008-09-09 19:08 (4 days old)
> References      : http://marc.info/?l=linux-kernel&m=122098735230906&w=4
>                  http://marc.info/?l=linux-kernel&m=122107367715361&w=4
> Handled-By      : Yinghai Lu <yhlu.kernel@gmail.com>
>
>
>

yeah I think it would be a good idea.
something to do with ehci_hcd, i.g. if I blacklist
ehci_hcd  Disabling IRQ#23 message doesnt seem to be showing up.

-- 
Justin P. Mattock

Re: [Bug #11398] hda_intel: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj.

[Frans Pop]

On Friday 12 September 2008, Rafael J. Wysocki wrote:
> The following bug entry is on the current list of known regressions
> from 2.6.26.  Please verify if it still should be listed and let me
> know (either way).
>
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11398
> Subject	: hda_intel: IRQ timing workaround is activated for card #0.
> 		  Suggest a bigger bdl_pos_adj.

Still there.

Re: [Bug #11271] BUG: fealnx in 2.6.27-rc1

[Jaswinder Singh]

Hello all,

On Fri, Sep 12, 2008 at 3:06 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:

> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=11271
> Subject         : BUG: fealnx in 2.6.27-rc1
> Submitter       : Jaswinder Singh <jaswinderlinux@gmail.com>
> Date            : 2008-08-05 14:58 (39 days old)
> References      : http://marc.info/?l=linux-netdev&m=121794762016830&w=4
>                  http://lkml.org/lkml/2008/8/10/98

I am sorry for delay.

Now I am testing for same problem with  2.6.27-rc6.:
1. On different MYSON Technology Inc SURECOM EP-320X-S 100/10M
Ethernet PCI Adapters
2. On different Linux PCs
3. With different Ethernet switches which supports 100 Mb
4. With different CAT 5 ethernet cables which supports 100 Mb
5. Also checking old patches on fealnx as per Jeff.

And it seems, I am getting following error, with few ethernet switches
and cables and when I switch ethernet cables  :
"NETDEV WATCHDOG: eth0 (fealnx): transmit timed out
eth0: Transmit timed out, status 00000000, resetting..."

Now I am trying to confirm that problem is coming from ethernet
switches and cables.

I am also facing one more Issue :

With same 100 Mb ethernet switch and cable my another NIC run at 100
Mb/s and full duplex but MYSON Technology Inc SURECOM EP-320X-S
100/10M runs on 10 Mb/s and half duplex.

I debug fealnx it says : PHYType 1 duplex_mode : 2 line_speed : 2
crvalue : 0xe40e61 bcrvalue : 0x10 imrvalue : 0x46c flags : 0x1

So it is saying duplex_mode : 2 (full duplex) and line_speed = 2
(100M) then why I am getting 10MB half duplex ?

#lspci -vv
02:02.0 Ethernet controller: MYSON Technology Inc SURECOM EP-320X-S
100/10M Ethernet PCI Adapter
        Subsystem: MYSON Technology Inc SURECOM EP-320X-S 100/10M
Ethernet PCI Adapter
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 32 (8000ns min, 16000ns max), Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 17
        Region 0: I/O ports at b800 [size=256]
        Region 1: Memory at ff9ffc00 (32-bit, non-prefetchable) [size=1K]
        Expansion ROM at 50000000 [disabled] [size=64K]
        Capabilities: [88] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2- AuxCurrent=375mA
PME(D0-,D1+,D2-,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Kernel driver in use: fealnx

#/sbin/ethtool eth0
Settings for eth0:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
        Supports auto-negotiation: Yes
        Advertised link modes:  Not reported
        Advertised auto-negotiation: No
        Speed: 10Mb/s
        Duplex: Half
        Port: MII
        PHYAD: 32
        Transceiver: internal
        Auto-negotiation: off
        Current message level: 0x00000000 (0)
        Link detected: no

Thank you,

Jaswinder Singh.

Re: [Bug #11553] Strange looking line from "ps aux"

[Alan Jenkins]

Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.26.  Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11553
> Subject		: Strange looking line from "ps aux"
> Submitter	: Rogério Brito <rbrito@ime.usp.br>
> Date		: 2008-09-11 17:43 (2 days old)
> References	: http://marc.info/?l=linux-kernel&m=122115506018275&w=4
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-testers" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>   

Isn't this another instance of
<http://bugzilla.kernel.org/show_bug.cgi?id=11209>?

If you can try 2.6.27-rc6, that should fix it.

Alan

Re: [Bug #11308] tbench regression on each kernel release from 2.6.22 -> 2.6.28

[Mike Galbraith]

On Fri, 2008-09-12 at 17:05 -0500, Christoph Lameter wrote:
> Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> > 
> > The following bug entry is on the current list of known regressions
> > from 2.6.26.  Please verify if it still should be listed and let me know
> > (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11308
> > Subject		: tbench regression on each kernel release from 2.6.22 -> 2.6.28
> > Submitter	: Christoph Lameter <cl@linux-foundation.org>
> > Date		: 2008-08-11 18:36 (33 days old)
> > References	: http://marc.info/?l=linux-kernel&m=121847986119495&w=4
> > 
> > 
> > 
> 
> tbench
> 
> 2.6.27-rc6	2760 MB/sec
> 2.6.22 		3235.47 MB/sec

Numbers from my Q6600 Aldi supermarket box (hm, your box is from different shelf)

tbench -t 60 4 localhost followed by 4 60s netperf TCP_RR pairs, each pair
jabbering on a separate port and affine to a separate CPU.  Configs are
as close as I can make them, all kernels built and tested today by
identical userland.

2.6.22.19
Throughput 1136.02 MB/sec 4 procs

16384  87380  1        1       60.01    94179.12
16384  87380  1        1       60.01    88780.61
16384  87380  1        1       60.01    91057.72
16384  87380  1        1       60.01    94242.16

2.6.22.19-cfs-v24.1  (identical config)
Throughput 1126.79 MB/sec 4 procs

16384  87380  1        1       60.00    88809.14
16384  87380  1        1       60.00    89971.25
16384  87380  1        1       60.01    89452.91
16384  87380  1        1       60.01    89478.63

2.6.23.17
Throughput 1073.2 MB/sec 4 procs

16384  87380  1        1       60.00    83635.61
16384  87380  1        1       60.00    82754.36
16384  87380  1        1       60.00    84594.59
16384  87380  1        1       60.00    82995.81

2.6.23.17-cfs-v24.1  (identical config)
Throughput 1145.28 MB/sec 4 procs

16384  87380  1        1       60.00    90278.55
16384  87380  1        1       60.01    90579.31
16384  87380  1        1       60.01    89412.14
16384  87380  1        1       60.00    90270.97

2.6.24.7
Throughput 1119.28 MB/sec 4 procs

16384  87380  1        1       60.00    84092.78
16384  87380  1        1       60.00    84120.68
16384  87380  1        1       60.00    84076.73
16384  87380  1        1       60.00    83995.07

2.6.25.17
Throughput 1113.82 MB/sec 4 procs

16384  87380  1        1       60.00    84629.98
16384  87380  1        1       60.00    84776.38
16384  87380  1        1       60.00    84356.49
16384  87380  1        1       60.00    84469.71

2.6.26.5
Throughput 1095.26 MB/sec 4 procs

16384  87380  1        1       60.00    84481.11
16384  87380  1        1       60.00    84604.38
16384  87380  1        1       60.01    86526.84
16384  87380  1        1       60.01    84478.01

2.6.27-rc6
Throughput 1037.98 MB/sec 4 procs

16384  87380  1        1       60.00    80293.80
16384  87380  1        1       60.00    80266.60
16384  87380  1        1       60.00    80394.83
16384  87380  1        1       60.01    80397.27

I spent two weeks chasing various and sundry netperf numbers recently,
only learning in the process that netperf is _utterly immune_ to
bisection.  Tbench numbers don't look promising for bisection from here.

Note to quixotic self: destroy log immediately lest you be tempted.

	-Mike

Re: [Bug #11308] tbench regression on each kernel release from 2.6.22 -> 2.6.28

[Mike Galbraith]

On Sat, 2008-09-13 at 13:44 +0200, Mike Galbraith wrote:

> 2.6.23.17-cfs-v24.1  (identical config)
> Throughput 1145.28 MB/sec 4 procs
> 
> 16384  87380  1        1       60.00    90278.55
> 16384  87380  1        1       60.01    90579.31
> 16384  87380  1        1       60.01    89412.14
> 16384  87380  1        1       60.00    90270.97
> 
> 2.6.24.7
> Throughput 1119.28 MB/sec 4 procs
> 
> 16384  87380  1        1       60.00    84092.78
> 16384  87380  1        1       60.00    84120.68
> 16384  87380  1        1       60.00    84076.73
> 16384  87380  1        1       60.00    83995.07

P.S. fwiw, scheduler difference between these two kernels is practically
nill.

Re: [Bug #11557] Controlling backlight on thinkpad x60

[Matthew Garrett]

I don't think this is a regression. The correct way to drive this 
hardware has always been through the ACPI video driver. The fact that 
thinkpad-acpi would also attempt to drive it was a bug.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [Bug #11398] hda_intel: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj.

[Takashi Iwai]

At Sat, 13 Sep 2008 09:37:51 +0200,
Frans Pop wrote:
> 
> On Friday 12 September 2008, Rafael J. Wysocki wrote:
> > The following bug entry is on the current list of known regressions
> > from 2.6.26.  Please verify if it still should be listed and let me
> > know (either way).
> >
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11398
> > Subject	: hda_intel: IRQ timing workaround is activated for card #0.
> > 		  Suggest a bigger bdl_pos_adj.
> 
> Still there.

Yeah, the driver wasn't changed about this.

Basically it's a warning message that CPU usage got higher due to
somehow wrongly behaving hardware.  The driver behavior itself didn't
do anything wrong.  That is, if the driver didn't show it, you
wouldn't have noticed any change (or noticed improvements in some apps
:)

Of course, it would be ideal if we can add a perfect workaround for
it, but right now, I have no idea what to do better.  So, I don't
think it's worth to keeping this open as a regression.


thanks,

Takashi

Re: [Bug #11500] /proc/net bug related to selinux

[Andrew Morton]

On Sat, 13 Sep 2008 10:15:43 +1000 (EST) James Morris <jmorris@namei.org> wrote:

> On Fri, 12 Sep 2008, Andrew Morton wrote:
> 
> > > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11500
> > > > Subject		: /proc/net bug related to selinux
> > > > Submitter	: Andrew Morton <akpm@linux-foundation.org>
> > > > Date		: 2008-09-04 17:45 (9 days old)
> > > > References	: http://marc.info/?l=linux-kernel&m=122055041313270&w=4
> > > 
> > > I think this might be a regression caused by namespace changes which we 
> 
> By which I mean, this was caused by a non-SELinux change to the upstream 
> kernel many, many eons ago.

hm, seems that 2.6.24 is OK but 2.6.25 is not.  I must have missed the
bug when testing 2.6.25-based kernels.

I started a git bisection search but after half an hour I hit bad
bisection breakage: a complete machine hang in fib_rules_init().

> > > addressed in SELinux policy.  Which distro version & policy version is 
> > > this seen with?
> > > 
> > 
> > FC5 on x86_32 and FC6 on x86_64.
> 
> As mentioned in the bugzilla, any related avc messages would be useful.

2.6.25 dmesg: http://userweb.kernel.org/~akpm/dmesg-sony.txt
/var/log/messages: http://userweb.kernel.org/~akpm/messages-sony.txt

The latter includes this:

Sep 13 12:32:43 sony kernel: SELinux:  class key not defined in policy
Sep 13 12:32:43 sony kernel: SELinux:  class dccp_socket not defined in policy
Sep 13 12:32:43 sony kernel: SELinux:  class memprotect not defined in policy
Sep 13 12:32:43 sony kernel: SELinux:  class peer not defined in policy
Sep 13 12:32:43 sony kernel: SELinux:  class capability2 not defined in policy
Sep 13 12:32:43 sony kernel: SELinux:  permission open in class dir not defined in policy
Sep 13 12:32:43 sony kernel: SELinux:  permission open in class file not defined in policy
Sep 13 12:32:43 sony kernel: SELinux:  permission open in class chr_file not defined in policy
Sep 13 12:32:43 sony kernel: SELinux:  permission open in class blk_file not defined in policy
Sep 13 12:32:43 sony kernel: SELinux:  permission open in class fifo_file not defined in policy
Sep 13 12:32:43 sony kernel: SELinux:  permission dccp_recv in class node not defined in policy
Sep 13 12:32:43 sony kernel: SELinux:  permission dccp_send in class node not defined in policy
Sep 13 12:32:43 sony kernel: SELinux:  permission recvfrom in class node not defined in policy
Sep 13 12:32:43 sony kernel: SELinux:  permission sendto in class node not defined in policy
Sep 13 12:32:43 sony kernel: SELinux:  permission dccp_recv in class netif not defined in policy
Sep 13 12:32:43 sony kernel: SELinux:  permission dccp_send in class netif not defined in policy
Sep 13 12:32:43 sony kernel: SELinux:  permission ingress in class netif not defined in policy
Sep 13 12:32:43 sony kernel: SELinux:  permission egress in class netif not defined in policy
Sep 13 12:32:44 sony kernel: SELinux:  permission setkeycreate in class process not defined in policy
Sep 13 12:32:44 sony kernel: SELinux:  permission setsockcreate in class process not defined in policy
Sep 13 12:32:44 sony kernel: SELinux:  permission setfcap in class capability not defined in policy
Sep 13 12:32:44 sony kernel: SELinux:  permission polmatch in class association not defined in policy
Sep 13 12:32:44 sony kernel: SELinux:  permission flow_in in class packet not defined in policy
Sep 13 12:32:44 sony kernel: SELinux:  permission flow_out in class packet not defined in policy
Sep 13 12:32:44 sony kernel: SELinux:  permission forward_in in class packet not defined in policy
Sep 13 12:32:44 sony kernel: SELinux:  permission forward_out in class packet not defined in policy
Sep 13 12:32:44 sony kernel: SELinux: the above unknown classes and permissions will be denied
Sep 13 12:32:44 sony kernel: type=1403 audit(1221309118.644:3): policy loaded auid=4294967295 ses=4294967295
Sep 13 12:32:44 sony kernel: type=1400 audit(1221334321.726:4): avc:  denied  { audit_write } for  pid=400 comm="hwclock" capability=29 scontext=system_u:system_r:hwclock_t:s0 tcontext=system_u:system_r:hwclock_t:s0 tclass=capability


Why am I seeing this on two machines and two vanilla-installed distros
but nobody else is reporting it?

Re: [Bug #11554] Partition check considered as error is breaking mounting in 2.6.27

[Herton Ronaldo Krzesinski]

On Friday 12 September 2008 16:06:31 Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.26.  Please verify if it still should be listed and let me know
> (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11554
> Subject		: Partition check considered as error is breaking mounting in 2.6.27
> Submitter	: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
> Date		: 2008-09-12 16:56 (1 days old)
> References	: http://marc.info/?l=linux-kernel&m=122123862519434&w=4
> 

Fixed now with commit 8d99f83b9478768d3a8d7d1bcd9bd182c75a0447

--
[]'s
Herton

Re: [Bug #11308] tbench regression on each kernel release from 2.6.22 -> 2.6.28

[Mike Galbraith]

On Sat, 2008-09-13 at 13:44 +0200, Mike Galbraith wrote:

> 2.6.27-rc6
> Throughput 1037.98 MB/sec 4 procs
> 
> 16384  87380  1        1       60.00    80293.80
> 16384  87380  1        1       60.00    80266.60
> 16384  87380  1        1       60.00    80394.83
> 16384  87380  1        1       60.01    80397.27

<snip... sigh>

goes back to current real .27 config

Throughput 1022.52 MB/sec 4 procs

16384  87380  1        1       60.00    75941.95
16384  87380  1        1       60.01    76002.46
16384  87380  1        1       60.01    76367.55
16384  87380  1        1       60.00    76188.66

...

demodularizes seriously over-configured network

Throughput 750.175 MB/sec 4 procs

16384  87380  1        1       60.00    49270.35
16384  87380  1        1       60.01    49233.86
16384  87380  1        1       60.00    49265.72
16384  87380  1        1       60.00    49227.00

Very un-good thing to try.  Stupid thing too?

-Mike

Re: [Bug #11308] tbench regression on each kernel release from 2.6.22 -> 2.6.28

[Mike Galbraith]

On Sun, 2008-09-14 at 08:24 +0200, Mike Galbraith wrote:
> On Sat, 2008-09-13 at 13:44 +0200, Mike Galbraith wrote:
> 
> > 2.6.27-rc6
> > Throughput 1037.98 MB/sec 4 procs
> > 
> > 16384  87380  1        1       60.00    80293.80
> > 16384  87380  1        1       60.00    80266.60
> > 16384  87380  1        1       60.00    80394.83
> > 16384  87380  1        1       60.01    80397.27
> 
> <snip... sigh>
> 
> goes back to current real .27 config
> 
> Throughput 1022.52 MB/sec 4 procs
> 
> 16384  87380  1        1       60.00    75941.95
> 16384  87380  1        1       60.01    76002.46
> 16384  87380  1        1       60.01    76367.55
> 16384  87380  1        1       60.00    76188.66
> 
> ...
> 
> demodularizes seriously over-configured network
> 
> Throughput 750.175 MB/sec 4 procs
> 
> 16384  87380  1        1       60.00    49270.35
> 16384  87380  1        1       60.01    49233.86
> 16384  87380  1        1       60.00    49265.72
> 16384  87380  1        1       60.00    49227.00
> 
> Very un-good thing to try.  Stupid thing too?

Apparently stupid for netfilter.  Uninteresting to this thread I
suppose, so disregard.

	-Mike

Re: [Bug #11557] Controlling backlight on thinkpad x60

[Pavel Machek]

On Sat 2008-09-13 16:13:30, Matthew Garrett wrote:
> I don't think this is a regression. The correct way to drive this 
> hardware has always been through the ACPI video driver. The fact that 
> thinkpad-acpi would also attempt to drive it was a bug.

I'm pretty sure thinkpad-acpi is older then ACPI-video. So yes, I
believe this is a regression, but it may be pretty old one.

									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [Bug #11308] tbench regression on each kernel release from 2.6.22 -> 2.6.28

[Christoph Lameter]

Mike Galbraith wrote:
> Numbers from my Q6600 Aldi supermarket box (hm, your box is from different shelf)
>   
My box is an 8p with recent quad core processors. 8G, 32bit Linux.

Re: [Bug #11308] tbench regression on each kernel release from 2.6.22 -> 2.6.28

[Mike Galbraith]

On Sun, 2008-09-14 at 09:18 -0500, Christoph Lameter wrote:
> Mike Galbraith wrote:
> > Numbers from my Q6600 Aldi supermarket box (hm, your box is from different shelf)
> >   
> My box is an 8p with recent quad core processors. 8G, 32bit Linux.

Don't hold your breath, but after putting my network config of a very
severe diet, I'm starting to see something resembling sensible results.

	-Mike

Re: [Bug #11398] hda_intel: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj.

[Rafael J. Wysocki]

On Saturday, 13 of September 2008, Takashi Iwai wrote:
> At Sat, 13 Sep 2008 09:37:51 +0200,
> Frans Pop wrote:
> > 
> > On Friday 12 September 2008, Rafael J. Wysocki wrote:
> > > The following bug entry is on the current list of known regressions
> > > from 2.6.26.  Please verify if it still should be listed and let me
> > > know (either way).
> > >
> > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11398
> > > Subject	: hda_intel: IRQ timing workaround is activated for card #0.
> > > 		  Suggest a bigger bdl_pos_adj.
> > 
> > Still there.
> 
> Yeah, the driver wasn't changed about this.
> 
> Basically it's a warning message that CPU usage got higher due to
> somehow wrongly behaving hardware.  The driver behavior itself didn't
> do anything wrong.  That is, if the driver didn't show it, you
> wouldn't have noticed any change (or noticed improvements in some apps
> :)
> 
> Of course, it would be ideal if we can add a perfect workaround for
> it, but right now, I have no idea what to do better.  So, I don't
> think it's worth to keeping this open as a regression.

I've closed the bug.

Thanks,
Rafael

Re: [Bug #11500] /proc/net bug related to selinux

[Rafael J. Wysocki]

On Saturday, 13 of September 2008, Andrew Morton wrote:
> On Sat, 13 Sep 2008 10:15:43 +1000 (EST) James Morris <jmorris@namei.org> wrote:
> 
> > On Fri, 12 Sep 2008, Andrew Morton wrote:
> > 
> > > > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11500
> > > > > Subject		: /proc/net bug related to selinux
> > > > > Submitter	: Andrew Morton <akpm@linux-foundation.org>
> > > > > Date		: 2008-09-04 17:45 (9 days old)
> > > > > References	: http://marc.info/?l=linux-kernel&m=122055041313270&w=4
> > > > 
> > > > I think this might be a regression caused by namespace changes which we 
> > 
> > By which I mean, this was caused by a non-SELinux change to the upstream 
> > kernel many, many eons ago.
> 
> hm, seems that 2.6.24 is OK but 2.6.25 is not.  I must have missed the
> bug when testing 2.6.25-based kernels.
> 
> I started a git bisection search but after half an hour I hit bad
> bisection breakage: a complete machine hang in fib_rules_init().
> 
> > > > addressed in SELinux policy.  Which distro version & policy version is 
> > > > this seen with?
> > > > 
> > > 
> > > FC5 on x86_32 and FC6 on x86_64.
> > 
> > As mentioned in the bugzilla, any related avc messages would be useful.
> 
> 2.6.25 dmesg: http://userweb.kernel.org/~akpm/dmesg-sony.txt
> /var/log/messages: http://userweb.kernel.org/~akpm/messages-sony.txt
> 
> The latter includes this:
> 
> Sep 13 12:32:43 sony kernel: SELinux:  class key not defined in policy
> Sep 13 12:32:43 sony kernel: SELinux:  class dccp_socket not defined in policy
> Sep 13 12:32:43 sony kernel: SELinux:  class memprotect not defined in policy
> Sep 13 12:32:43 sony kernel: SELinux:  class peer not defined in policy
> Sep 13 12:32:43 sony kernel: SELinux:  class capability2 not defined in policy
> Sep 13 12:32:43 sony kernel: SELinux:  permission open in class dir not defined in policy
> Sep 13 12:32:43 sony kernel: SELinux:  permission open in class file not defined in policy
> Sep 13 12:32:43 sony kernel: SELinux:  permission open in class chr_file not defined in policy
> Sep 13 12:32:43 sony kernel: SELinux:  permission open in class blk_file not defined in policy
> Sep 13 12:32:43 sony kernel: SELinux:  permission open in class fifo_file not defined in policy
> Sep 13 12:32:43 sony kernel: SELinux:  permission dccp_recv in class node not defined in policy
> Sep 13 12:32:43 sony kernel: SELinux:  permission dccp_send in class node not defined in policy
> Sep 13 12:32:43 sony kernel: SELinux:  permission recvfrom in class node not defined in policy
> Sep 13 12:32:43 sony kernel: SELinux:  permission sendto in class node not defined in policy
> Sep 13 12:32:43 sony kernel: SELinux:  permission dccp_recv in class netif not defined in policy
> Sep 13 12:32:43 sony kernel: SELinux:  permission dccp_send in class netif not defined in policy
> Sep 13 12:32:43 sony kernel: SELinux:  permission ingress in class netif not defined in policy
> Sep 13 12:32:43 sony kernel: SELinux:  permission egress in class netif not defined in policy
> Sep 13 12:32:44 sony kernel: SELinux:  permission setkeycreate in class process not defined in policy
> Sep 13 12:32:44 sony kernel: SELinux:  permission setsockcreate in class process not defined in policy
> Sep 13 12:32:44 sony kernel: SELinux:  permission setfcap in class capability not defined in policy
> Sep 13 12:32:44 sony kernel: SELinux:  permission polmatch in class association not defined in policy
> Sep 13 12:32:44 sony kernel: SELinux:  permission flow_in in class packet not defined in policy
> Sep 13 12:32:44 sony kernel: SELinux:  permission flow_out in class packet not defined in policy
> Sep 13 12:32:44 sony kernel: SELinux:  permission forward_in in class packet not defined in policy
> Sep 13 12:32:44 sony kernel: SELinux:  permission forward_out in class packet not defined in policy
> Sep 13 12:32:44 sony kernel: SELinux: the above unknown classes and permissions will be denied
> Sep 13 12:32:44 sony kernel: type=1403 audit(1221309118.644:3): policy loaded auid=4294967295 ses=4294967295
> Sep 13 12:32:44 sony kernel: type=1400 audit(1221334321.726:4): avc:  denied  { audit_write } for  pid=400 comm="hwclock" capability=29 scontext=system_u:system_r:hwclock_t:s0 tcontext=system_u:system_r:hwclock_t:s0 tclass=capability
> 
> 
> Why am I seeing this on two machines and two vanilla-installed distros
> but nobody else is reporting it?

Well, it seems no one else is testing selinux ...

Re: [Bug #11554] Partition check considered as error is breaking mounting in 2.6.27

[Rafael J. Wysocki]

On Sunday, 14 of September 2008, Herton Ronaldo Krzesinski wrote:
> On Friday 12 September 2008 16:06:31 Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> > 
> > The following bug entry is on the current list of known regressions
> > from 2.6.26.  Please verify if it still should be listed and let me know
> > (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11554
> > Subject		: Partition check considered as error is breaking mounting in 2.6.27
> > Submitter	: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
> > Date		: 2008-09-12 16:56 (1 days old)
> > References	: http://marc.info/?l=linux-kernel&m=122123862519434&w=4
> > 
> 
> Fixed now with commit 8d99f83b9478768d3a8d7d1bcd9bd182c75a0447

Thanks, closed.

Rafael

Re: [Bug #11308] tbench regression on each kernel release from 2.6.22 -> 2.6.28

[Mike Galbraith]

On Sun, 2008-09-14 at 21:51 +0200, Mike Galbraith wrote:
> On Sun, 2008-09-14 at 09:18 -0500, Christoph Lameter wrote:
> > Mike Galbraith wrote:
> > > Numbers from my Q6600 Aldi supermarket box (hm, your box is from different shelf)
> > >   
> > My box is an 8p with recent quad core processors. 8G, 32bit Linux.
> 
> Don't hold your breath, but after putting my network config of a very
> severe diet, I'm starting to see something resembling sensible results.

Turns off all netfilter options except tables, etc.

Since 2.6.22.19-cfs-v24.1 and 2.6.23.17-cfs-v24.1 schedulers are
identical, and these are essentially identical with 2.6.24.7, what I
read from numbers below is that cfs in 2.6.23 was somewhat less than
wonderful for either netperf or tbench,  Something happened somewhere
other than the scheduler at 23->24 which cost us some performance, and
another something happened at 26->27.  I'll likely go looking again..
and likely regret it again ;-)

Math ain't free is part of it, though apparently not much.  For me,
tbench regression 22->27 is ~10%, and netperf regression is ~16%.

Data:

2.6.22.19

Throughput 1250.73 MB/sec 4 procs                  1.00

16384  87380  1        1       60.01    111272.55  1.00
16384  87380  1        1       60.00    104689.58
16384  87380  1        1       60.00    110733.05
16384  87380  1        1       60.00    110748.88

2.6.22.19-cfs-v24.1

Throughput 1204.14 MB/sec 4 procs                  .962

16384  87380  1        1       60.01    101799.85  .929
16384  87380  1        1       60.01    101659.41
16384  87380  1        1       60.01    101628.78
16384  87380  1        1       60.01    101700.53

wakeup granularity = 0 (make scheduler as preempt happy as 2.6.22 is)

Throughput 1213.21 MB/sec 4 procs                  .970

16384  87380  1        1       60.01    108569.27  .992
16384  87380  1        1       60.01    108541.04
16384  87380  1        1       60.00    108579.63
16384  87380  1        1       60.01    108519.09

2.6.23.17

Throughput 1192.49 MB/sec 4 procs                  .953

16384  87380  1        1       60.00    91124.67   .866
16384  87380  1        1       60.00    93124.38
16384  87380  1        1       60.01    92249.69
16384  87380  1        1       60.01    91103.12

wakeup granularity = 0

Throughput 1200.46 MB/sec 4 procs                  .959

16384  87380  1        1       60.01    95987.66   .866
16384  87380  1        1       60.01    92819.98
16384  87380  1        1       60.01    95454.00
16384  87380  1        1       60.01    94834.84

2.6.23.17-cfs-v24.1

Throughput 1242.47 MB/sec 4 procs                  .993

16384  87380  1        1       60.00    101728.34  .931
16384  87380  1        1       60.00    101930.23
16384  87380  1        1       60.00    101803.15
16384  87380  1        1       60.00    101908.29

wakeup granularity = 0

Throughput 1238.68 MB/sec 4 procs                  .990

16384  87380  1        1       60.01    105871.52  .969
16384  87380  1        1       60.01    105813.11
16384  87380  1        1       60.01    106106.31
16384  87380  1        1       60.01    106310.20

2.6.24.7

Throughput 1202.49 MB/sec 4 procs                  .961

16384  87380  1        1       60.00    94643.23   .868
16384  87380  1        1       60.00    94754.37
16384  87380  1        1       60.00    94909.77
16384  87380  1        1       60.00    95457.41

wakeup granularity = 0

Throughput 1204 MB/sec 4 procs                     .962

16384  87380  1        1       60.00    99599.27   .910
16384  87380  1        1       60.00    99439.95
16384  87380  1        1       60.00    99556.38
16384  87380  1        1       60.00    99500.45

2.6.25.17

Throughput 1220.47 MB/sec 4 procs                  .975

16384  87380  1        1       60.00    94641.06   .867
16384  87380  1        1       60.00    94864.87
16384  87380  1        1       60.01    95033.81
16384  87380  1        1       60.00    94863.49

wakeup granularity = 0

Throughput 1223.16 MB/sec 4 procs                  .977
16384  87380  1        1       60.00    101768.95  .930
16384  87380  1        1       60.00    101888.46
16384  87380  1        1       60.01    101608.21
16384  87380  1        1       60.01    101833.05

2.6.26.5

Throughput 1182.24 MB/sec 4 procs                  .945

16384  87380  1        1       60.00    93814.75   .854
16384  87380  1        1       60.00    94173.41
16384  87380  1        1       60.00    92925.24
16384  87380  1        1       60.00    93002.51

wakeup granularity = 0

Throughput 1183.47 MB/sec 4 procs                  .945

16384  87380  1        1       60.00    100837.12  .922
16384  87380  1        1       60.00    101230.12
16384  87380  1        1       60.00    100868.45
16384  87380  1        1       60.00    100491.41

2.6.27

Throughput 1088.17 MB/sec 4 procs                  .870

16384  87380  1        1       60.00    84225.59   .766
16384  87380  1        1       60.00    83362.65
16384  87380  1        1       60.00    84060.73
16384  87380  1        1       60.00    83462.72

wakeup granularity = 0

Throughput 1116.22 MB/sec 4 procs                  .892

16384  87380  1        1       60.00    92502.44   .841
16384  87380  1        1       60.01    92213.72
16384  87380  1        1       60.00    91445.86
16384  87380  1        1       60.00    91832.84

revert sched weight/asym changes, gran = 0

Throughput 1149.16 MB/sec 4 proc                   .918

16384  87380  1        1       60.00    94824.92   .868
16384  87380  1        1       60.01    94579.45
16384  87380  1        1       60.01    95284.94
16384  87380  1        1       60.01    95228.22

Weight/asym changes cost ~3%.  Mysql+oltp agrees.  Preempt happy loads
lose a bit, preempt haters gain a bit.  Performance shift.

Re: [Bug #11500] /proc/net bug related to selinux

[Stephen Smalley]

On Sat, 2008-09-13 at 12:37 -0700, Andrew Morton wrote:
> On Sat, 13 Sep 2008 10:15:43 +1000 (EST) James Morris <jmorris@namei.org> wrote:
> 
> > On Fri, 12 Sep 2008, Andrew Morton wrote:
> > 
> > > > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11500
> > > > > Subject		: /proc/net bug related to selinux
> > > > > Submitter	: Andrew Morton <akpm@linux-foundation.org>
> > > > > Date		: 2008-09-04 17:45 (9 days old)
> > > > > References	: http://marc.info/?l=linux-kernel&m=122055041313270&w=4
> > > > 
> > > > I think this might be a regression caused by namespace changes which we 
> > 
> > By which I mean, this was caused by a non-SELinux change to the upstream 
> > kernel many, many eons ago.
> 
> hm, seems that 2.6.24 is OK but 2.6.25 is not.  I must have missed the
> bug when testing 2.6.25-based kernels.
> 
> I started a git bisection search but after half an hour I hit bad
> bisection breakage: a complete machine hang in fib_rules_init().
> 
> > > > addressed in SELinux policy.  Which distro version & policy version is 
> > > > this seen with?
> > > > 
> > > 
> > > FC5 on x86_32 and FC6 on x86_64.
> > 
> > As mentioned in the bugzilla, any related avc messages would be useful.
> 
> 2.6.25 dmesg: http://userweb.kernel.org/~akpm/dmesg-sony.txt
> /var/log/messages: http://userweb.kernel.org/~akpm/messages-sony.txt
> 
> The latter includes this:
> 
> Sep 13 12:32:43 sony kernel: SELinux:  class key not defined in policy
> Sep 13 12:32:43 sony kernel: SELinux:  class dccp_socket not defined in policy
> Sep 13 12:32:43 sony kernel: SELinux:  class memprotect not defined in policy
> Sep 13 12:32:43 sony kernel: SELinux:  class peer not defined in policy
> Sep 13 12:32:43 sony kernel: SELinux:  class capability2 not defined in policy
> Sep 13 12:32:43 sony kernel: SELinux:  permission open in class dir not defined in policy
> Sep 13 12:32:43 sony kernel: SELinux:  permission open in class file not defined in policy
> Sep 13 12:32:43 sony kernel: SELinux:  permission open in class chr_file not defined in policy
> Sep 13 12:32:43 sony kernel: SELinux:  permission open in class blk_file not defined in policy
> Sep 13 12:32:43 sony kernel: SELinux:  permission open in class fifo_file not defined in policy
> Sep 13 12:32:43 sony kernel: SELinux:  permission dccp_recv in class node not defined in policy
> Sep 13 12:32:43 sony kernel: SELinux:  permission dccp_send in class node not defined in policy
> Sep 13 12:32:43 sony kernel: SELinux:  permission recvfrom in class node not defined in policy
> Sep 13 12:32:43 sony kernel: SELinux:  permission sendto in class node not defined in policy
> Sep 13 12:32:43 sony kernel: SELinux:  permission dccp_recv in class netif not defined in policy
> Sep 13 12:32:43 sony kernel: SELinux:  permission dccp_send in class netif not defined in policy
> Sep 13 12:32:43 sony kernel: SELinux:  permission ingress in class netif not defined in policy
> Sep 13 12:32:43 sony kernel: SELinux:  permission egress in class netif not defined in policy
> Sep 13 12:32:44 sony kernel: SELinux:  permission setkeycreate in class process not defined in policy
> Sep 13 12:32:44 sony kernel: SELinux:  permission setsockcreate in class process not defined in policy
> Sep 13 12:32:44 sony kernel: SELinux:  permission setfcap in class capability not defined in policy
> Sep 13 12:32:44 sony kernel: SELinux:  permission polmatch in class association not defined in policy
> Sep 13 12:32:44 sony kernel: SELinux:  permission flow_in in class packet not defined in policy
> Sep 13 12:32:44 sony kernel: SELinux:  permission flow_out in class packet not defined in policy
> Sep 13 12:32:44 sony kernel: SELinux:  permission forward_in in class packet not defined in policy
> Sep 13 12:32:44 sony kernel: SELinux:  permission forward_out in class packet not defined in policy
> Sep 13 12:32:44 sony kernel: SELinux: the above unknown classes and permissions will be denied
> Sep 13 12:32:44 sony kernel: type=1403 audit(1221309118.644:3): policy loaded auid=4294967295 ses=4294967295
> Sep 13 12:32:44 sony kernel: type=1400 audit(1221334321.726:4): avc:  denied  { audit_write } for  pid=400 comm="hwclock" capability=29 scontext=system_u:system_r:hwclock_t:s0 tcontext=system_u:system_r:hwclock_t:s0 tclass=capability
> 
> 
> Why am I seeing this on two machines and two vanilla-installed distros
> but nobody else is reporting it?

What we actually need to see is the output of:
/sbin/ausearch -i -m AVC -sv no

However, the most likely explanation is simply that when /proc/net was
changed from being a directory to being a symlink to /proc/self/net,
that introduced an additional permission check on accesses
of /proc/net/<whatever>, namely the read check on the symlink itself.
And since that check wasn't happening on /proc/net accesses with older
kernels, older policies didn't allow it.

As to why others haven't reported it, I expect that they have updated
their policies to newer ones that allow the necessary access.  The fact
that legacy distros wouldn't have such updated policies isn't surprising
- they don't push updates to those distros for new kernels.  FC5 and FC6
are both EOL'd, right?

In any event, we didn't change anything in SELinux - the change was
elsewhere (in the proc/net implementation).  Don't blame the messenger
please.

-- 
Stephen Smalley
National Security Agency

Re: [Bug #11500] /proc/net bug related to selinux

[Stephen Smalley]

On Mon, 2008-09-15 at 09:05 -0400, Stephen Smalley wrote:
> On Sat, 2008-09-13 at 12:37 -0700, Andrew Morton wrote:
> > On Sat, 13 Sep 2008 10:15:43 +1000 (EST) James Morris <jmorris@namei.org> wrote:
> > 
> > > On Fri, 12 Sep 2008, Andrew Morton wrote:
> > > 
> > > > > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11500
> > > > > > Subject		: /proc/net bug related to selinux
> > > > > > Submitter	: Andrew Morton <akpm@linux-foundation.org>
> > > > > > Date		: 2008-09-04 17:45 (9 days old)
> > > > > > References	: http://marc.info/?l=linux-kernel&m=122055041313270&w=4
> > > > > 
> > > > > I think this might be a regression caused by namespace changes which we 
> > > 
> > > By which I mean, this was caused by a non-SELinux change to the upstream 
> > > kernel many, many eons ago.
> > 
> > hm, seems that 2.6.24 is OK but 2.6.25 is not.  I must have missed the
> > bug when testing 2.6.25-based kernels.
> > 
> > I started a git bisection search but after half an hour I hit bad
> > bisection breakage: a complete machine hang in fib_rules_init().
> > 
> > > > > addressed in SELinux policy.  Which distro version & policy version is 
> > > > > this seen with?
> > > > > 
> > > > 
> > > > FC5 on x86_32 and FC6 on x86_64.
> > > 
> > > As mentioned in the bugzilla, any related avc messages would be useful.
> > 
> > 2.6.25 dmesg: http://userweb.kernel.org/~akpm/dmesg-sony.txt
> > /var/log/messages: http://userweb.kernel.org/~akpm/messages-sony.txt
> > 
> > The latter includes this:
> > 
> > Sep 13 12:32:43 sony kernel: SELinux:  class key not defined in policy
> > Sep 13 12:32:43 sony kernel: SELinux:  class dccp_socket not defined in policy
> > Sep 13 12:32:43 sony kernel: SELinux:  class memprotect not defined in policy
> > Sep 13 12:32:43 sony kernel: SELinux:  class peer not defined in policy
> > Sep 13 12:32:43 sony kernel: SELinux:  class capability2 not defined in policy
> > Sep 13 12:32:43 sony kernel: SELinux:  permission open in class dir not defined in policy
> > Sep 13 12:32:43 sony kernel: SELinux:  permission open in class file not defined in policy
> > Sep 13 12:32:43 sony kernel: SELinux:  permission open in class chr_file not defined in policy
> > Sep 13 12:32:43 sony kernel: SELinux:  permission open in class blk_file not defined in policy
> > Sep 13 12:32:43 sony kernel: SELinux:  permission open in class fifo_file not defined in policy
> > Sep 13 12:32:43 sony kernel: SELinux:  permission dccp_recv in class node not defined in policy
> > Sep 13 12:32:43 sony kernel: SELinux:  permission dccp_send in class node not defined in policy
> > Sep 13 12:32:43 sony kernel: SELinux:  permission recvfrom in class node not defined in policy
> > Sep 13 12:32:43 sony kernel: SELinux:  permission sendto in class node not defined in policy
> > Sep 13 12:32:43 sony kernel: SELinux:  permission dccp_recv in class netif not defined in policy
> > Sep 13 12:32:43 sony kernel: SELinux:  permission dccp_send in class netif not defined in policy
> > Sep 13 12:32:43 sony kernel: SELinux:  permission ingress in class netif not defined in policy
> > Sep 13 12:32:43 sony kernel: SELinux:  permission egress in class netif not defined in policy
> > Sep 13 12:32:44 sony kernel: SELinux:  permission setkeycreate in class process not defined in policy
> > Sep 13 12:32:44 sony kernel: SELinux:  permission setsockcreate in class process not defined in policy
> > Sep 13 12:32:44 sony kernel: SELinux:  permission setfcap in class capability not defined in policy
> > Sep 13 12:32:44 sony kernel: SELinux:  permission polmatch in class association not defined in policy
> > Sep 13 12:32:44 sony kernel: SELinux:  permission flow_in in class packet not defined in policy
> > Sep 13 12:32:44 sony kernel: SELinux:  permission flow_out in class packet not defined in policy
> > Sep 13 12:32:44 sony kernel: SELinux:  permission forward_in in class packet not defined in policy
> > Sep 13 12:32:44 sony kernel: SELinux:  permission forward_out in class packet not defined in policy
> > Sep 13 12:32:44 sony kernel: SELinux: the above unknown classes and permissions will be denied
> > Sep 13 12:32:44 sony kernel: type=1403 audit(1221309118.644:3): policy loaded auid=4294967295 ses=4294967295
> > Sep 13 12:32:44 sony kernel: type=1400 audit(1221334321.726:4): avc:  denied  { audit_write } for  pid=400 comm="hwclock" capability=29 scontext=system_u:system_r:hwclock_t:s0 tcontext=system_u:system_r:hwclock_t:s0 tclass=capability
> > 
> > 
> > Why am I seeing this on two machines and two vanilla-installed distros
> > but nobody else is reporting it?
> 
> What we actually need to see is the output of:
> /sbin/ausearch -i -m AVC -sv no
> 
> However, the most likely explanation is simply that when /proc/net was
> changed from being a directory to being a symlink to /proc/self/net,
> that introduced an additional permission check on accesses
> of /proc/net/<whatever>, namely the read check on the symlink itself.
> And since that check wasn't happening on /proc/net accesses with older
> kernels, older policies didn't allow it.
> 
> As to why others haven't reported it, I expect that they have updated
> their policies to newer ones that allow the necessary access.  The fact
> that legacy distros wouldn't have such updated policies isn't surprising
> - they don't push updates to those distros for new kernels.  FC5 and FC6
> are both EOL'd, right?
> 
> In any event, we didn't change anything in SELinux - the change was
> elsewhere (in the proc/net implementation).  Don't blame the messenger
> please.

BTW, if the explanation above is correct, then a user can allow this
permission in their own policy by creating a local policy module and
inserting it, ala:
$ cat fixprocnet.te
policy_module(fixprocnet, 1.0)
require {
        attribute domain;
        type proc_net_t;
}
# Allow all domains to read the /proc/net symlink.
allow domain proc_net_t:lnk_file read;

$ make -f /usr/share/selinux/devel/Makefile fixprocnet.pp
$ /usr/sbin/semodule -i fixprocnet.pp

Requires selinux-policy-devel to be installed.

-- 
Stephen Smalley
National Security Agency

Re: [Bug #11471] GPE storm detected, kernel freezes

[Zhang Rui]

On Sat, 2008-09-13 at 03:06 +0800, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.

> The following bug entry is on the current list of known regressions
> from 2.6.26.  Please verify if it still should be listed and let me
> know
> (either way).

> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=11471
> Subject         : GPE storm detected, kernel freezes
> Submitter       : George Gibbs <Vash63@gmail.com>
> Date            : 2008-08-31 22:00 (13 days old)
> Handled-By      : Zhang Rui <rui.zhang@intel.com>
> 
this has already been fixed in -rc6.
please refer to http://bugzilla.kernel.org/show_bug.cgi?id=11471#c22

so I think this should be removed from the list.

thanks,
rui

Re: [Bug #11308] tbench regression on each kernel release from 2.6.22 -> 2.6.28

[Mike Galbraith]

On Mon, 2008-09-15 at 12:44 +0200, Mike Galbraith wrote:
> On Sun, 2008-09-14 at 21:51 +0200, Mike Galbraith wrote:
> > On Sun, 2008-09-14 at 09:18 -0500, Christoph Lameter wrote:
> > > Mike Galbraith wrote:
> > > > Numbers from my Q6600 Aldi supermarket box (hm, your box is from different shelf)
> > > >   
> > > My box is an 8p with recent quad core processors. 8G, 32bit Linux.
> > 
> > Don't hold your breath, but after putting my network config of a very
> > severe diet, I'm starting to see something resembling sensible results.
> 
> Turns off all netfilter options except tables, etc.
> 
> Since 2.6.22.19-cfs-v24.1 and 2.6.23.17-cfs-v24.1 schedulers are
> identical, and these are essentially identical with 2.6.24.7, what I
> read from numbers below is that cfs in 2.6.23 was somewhat less than
> wonderful for either netperf or tbench,  Something happened somewhere
> other than the scheduler at 23->24 which cost us some performance, and
> another something happened at 26->27.  I'll likely go looking again..
> and likely regret it again ;-)

Bisecting 26->27 yet again turned up a repeatable downturn in netperf
throughput.  There is no difference at this point with tbench. 

Bisect says first bad commit is 847106f, a security merge.  Post
bisection sanity checkouts say...

v2.6.26-21-g2069f45
16384  87380  1        1       60.00    98435.13
16384  87380  1        1       60.01    99259.90
16384  87380  1        1       60.01    99325.61
16384  87380  1        1       60.00    99039.84

v2.6.26-343-g847106f
16384  87380  1        1       60.00    94764.59
16384  87380  1        1       60.00    94909.89
16384  87380  1        1       60.00    94858.63
16384  87380  1        1       60.00    94801.12

...every time.  I knew I'd regret doing this.

	-Mike

Re: [Bug #11308] tbench regression on each kernel release from 2.6.22 -> 2.6.28

[Ilpo Järvinen]

On Tue, 16 Sep 2008, Mike Galbraith wrote:

> On Mon, 2008-09-15 at 12:44 +0200, Mike Galbraith wrote:
> > On Sun, 2008-09-14 at 21:51 +0200, Mike Galbraith wrote:
> > 
> > Since 2.6.22.19-cfs-v24.1 and 2.6.23.17-cfs-v24.1 schedulers are
> > identical, and these are essentially identical with 2.6.24.7, what I
> > read from numbers below is that cfs in 2.6.23 was somewhat less than
> > wonderful for either netperf or tbench,  Something happened somewhere
> > other than the scheduler at 23->24 which cost us some performance, and
> > another something happened at 26->27.  I'll likely go looking again..
> > and likely regret it again ;-)
> 
> Bisecting 26->27 yet again turned up a repeatable downturn in netperf
> throughput.  There is no difference at this point with tbench. 
> 
> Bisect says first bad commit is 847106f, a security merge.  Post
> bisection sanity checkouts say...
> 
> v2.6.26-21-g2069f45
> 16384  87380  1        1       60.00    98435.13
> 16384  87380  1        1       60.01    99259.90
> 16384  87380  1        1       60.01    99325.61
> 16384  87380  1        1       60.00    99039.84
> 
> v2.6.26-343-g847106f
> 16384  87380  1        1       60.00    94764.59
> 16384  87380  1        1       60.00    94909.89
> 16384  87380  1        1       60.00    94858.63
> 16384  87380  1        1       60.00    94801.12
> 
> ...every time.  I knew I'd regret doing this.

I assume that c142bda458a gave a good results as well...

One additional sanity check could be to rebase security 6f0f0fd4963 on top 
of the c142bda458a and then see if bisection among those security commits 
on top yields to the the same result... Though I doubt it can change much 
because there was not that much relevant non-security things in the merge 
in question.

-- 
 i.

Re: [Bug #11272] BUG: parport_serial in 2.6.27-rc1 for NetMos Technology PCI 9835

[Jaswinder Singh]

Hello all,

I am sorry for delay.

On Sat, Sep 13, 2008 at 12:36 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>
> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=11272
> Subject         : BUG: parport_serial in 2.6.27-rc1 for NetMos Technology PCI 9835
> Submitter       : Jaswinder Singh <jaswinderlinux@gmail.com>
> Date            : 2008-08-05 15:12 (39 days old)
> References      : http://marc.info/?l=linux-kernel&m=121794900319776&w=4
>

I have tested parport_pc and also tried with pcmcia_cs, only thing I
get is disappointment. So I give up :-(

Now I switched to usbserial.
usbserial drivers are working great !!

Now I do not want to use parport_pc and pcmcia_cs atleast for 2 years,
I hope in 2 years this will be solved ;)

In the mean time, If you think my problem is solved just ping to me I
will test and let you know the results.

Thank you for all your support and help.

Jaswinder Singh.

Re: [Bug #11308] tbench regression on each kernel release from 2.6.22 -> 2.6.28

[Mike Galbraith]

On Tue, 2008-09-16 at 17:07 +0300, Ilpo Järvinen wrote:
> On Tue, 16 Sep 2008, Mike Galbraith wrote:
> 
> > On Mon, 2008-09-15 at 12:44 +0200, Mike Galbraith wrote:
> > > On Sun, 2008-09-14 at 21:51 +0200, Mike Galbraith wrote:
> > > 
> > > Since 2.6.22.19-cfs-v24.1 and 2.6.23.17-cfs-v24.1 schedulers are
> > > identical, and these are essentially identical with 2.6.24.7, what I
> > > read from numbers below is that cfs in 2.6.23 was somewhat less than
> > > wonderful for either netperf or tbench,  Something happened somewhere
> > > other than the scheduler at 23->24 which cost us some performance, and
> > > another something happened at 26->27.  I'll likely go looking again..
> > > and likely regret it again ;-)
> > 
> > Bisecting 26->27 yet again turned up a repeatable downturn in netperf
> > throughput.  There is no difference at this point with tbench. 
> > 
> > Bisect says first bad commit is 847106f, a security merge.  Post
> > bisection sanity checkouts say...
> > 
> > v2.6.26-21-g2069f45
> > 16384  87380  1        1       60.00    98435.13
> > 16384  87380  1        1       60.01    99259.90
> > 16384  87380  1        1       60.01    99325.61
> > 16384  87380  1        1       60.00    99039.84
> > 
> > v2.6.26-343-g847106f
> > 16384  87380  1        1       60.00    94764.59
> > 16384  87380  1        1       60.00    94909.89
> > 16384  87380  1        1       60.00    94858.63
> > 16384  87380  1        1       60.00    94801.12
> > 
> > ...every time.  I knew I'd regret doing this.
> 
> I assume that c142bda458a gave a good results as well...

Yes, just tried it.

> One additional sanity check could be to rebase security 6f0f0fd4963 on top 
> of the c142bda458a and then see if bisection among those security commits 
> on top yields to the the same result... Though I doubt it can change much 
> because there was not that much relevant non-security things in the merge 
> in question.

I'm not a master of git-foo, so that is not an option.  However, a dinky
bisection c142bda4..847106f very clearly says...

marge:..kernel/linux-2.6.27.git # git bisect bad
6f0f0fd496333777d53daff21a4e3b28c4d03a6d is first bad commit
commit 6f0f0fd496333777d53daff21a4e3b28c4d03a6d
Author: James Morris <jmorris@namei.org>
Date:   Thu Jul 10 17:02:07 2008 +0900

    security: remove register_security hook

    The register security hook is no longer required, as the capability
    module is always registered.  LSMs wishing to stack capability as
    a secondary module should do so explicitly.

    Signed-off-by: James Morris <jmorris@namei.org>
    Acked-by: Stephen Smalley <sds@tycho.nsa.gov>
    Acked-by: Greg Kroah-Hartman <gregkh@suse.de>

:040000 040000 0177ef46d305e51e27bfcc4350a40577f8ba8d3d 64b64c10a424df4539653a8ee34f1a2329300931 M      include
:040000 040000 e318891e514de674fd064f6bfad70d5633b1aff1 0dbb38d5aa7fc3e4b2e09dc65796ce7cd5faeb26 M      security

git bisect start
# good: [c142bda458a9c81097238800e1bd8eeeea09913d] Merge branch 'drm-reorg' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6
git bisect good c142bda458a9c81097238800e1bd8eeeea09913d
# bad: [847106ff628805e1a0aa91e7f53381f3fdfcd839] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6
git bisect bad 847106ff628805e1a0aa91e7f53381f3fdfcd839
# good: [cea78dc4ca044e9666e8f5d797ec50ab85253e49] SELinux: fix off by 1 reference of class_to_string in context_struct_compute_av
git bisect good cea78dc4ca044e9666e8f5d797ec50ab85253e49
# good: [65fc7668006b537f7ae8451990c0ed9ec882544e] security: fix return of void-valued expressions
git bisect good 65fc7668006b537f7ae8451990c0ed9ec882544e
# good: [b478a9f9889c81e88077d1495daadee64c0af541] security: remove unused sb_get_mnt_opts hook
git bisect good b478a9f9889c81e88077d1495daadee64c0af541
# good: [93cbace7a058bce7f99319ef6ceff4b78cf45051] security: remove dummy module fix
git bisect good 93cbace7a058bce7f99319ef6ceff4b78cf45051
# bad: [6f0f0fd496333777d53daff21a4e3b28c4d03a6d] security: remove register_security hook
git bisect bad 6f0f0fd496333777d53daff21a4e3b28c4d03a6d

Re: [Bug #11308] tbench regression on each kernel release from 2.6.22 -> 2.6.28

[Mike Galbraith]

On Wed, 2008-09-17 at 06:40 +0200, Mike Galbraith wrote:
> On Tue, 2008-09-16 at 17:07 +0300, Ilpo Järvinen wrote:

> > One additional sanity check could be to rebase security 6f0f0fd4963 on top 
> > of the c142bda458a and then see if bisection among those security commits 
> > on top yields to the the same result... Though I doubt it can change much 
> > because there was not that much relevant non-security things in the merge 
> > in question.
> 
> I'm not a master of git-foo, so that is not an option.  However, a dinky
> bisection c142bda4..847106f very clearly says...
> 
> marge:..kernel/linux-2.6.27.git # git bisect bad
> 6f0f0fd496333777d53daff21a4e3b28c4d03a6d is first bad commit
> commit 6f0f0fd496333777d53daff21a4e3b28c4d03a6d
> Author: James Morris <jmorris@namei.org>
> Date:   Thu Jul 10 17:02:07 2008 +0900
> 
>     security: remove register_security hook
> 
>     The register security hook is no longer required, as the capability
>     module is always registered.  LSMs wishing to stack capability as
>     a secondary module should do so explicitly.
> 
>     Signed-off-by: James Morris <jmorris@namei.org>
>     Acked-by: Stephen Smalley <sds@tycho.nsa.gov>
>     Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
> 
> :040000 040000 0177ef46d305e51e27bfcc4350a40577f8ba8d3d 64b64c10a424df4539653a8ee34f1a2329300931 M      include
> :040000 040000 e318891e514de674fd064f6bfad70d5633b1aff1 0dbb38d5aa7fc3e4b2e09dc65796ce7cd5faeb26 M      security

Which is high grade horse-pookey.

	-Mike

Re: [Bug #11308] tbench regression on each kernel release from 2.6.22 -> 2.6.28

[Ingo Molnar]

* Mike Galbraith <efault@gmx.de> wrote:

> On Wed, 2008-09-17 at 06:40 +0200, Mike Galbraith wrote:
> > On Tue, 2008-09-16 at 17:07 +0300, Ilpo Järvinen wrote:
> 
> > > One additional sanity check could be to rebase security 6f0f0fd4963 on top 
> > > of the c142bda458a and then see if bisection among those security commits 
> > > on top yields to the the same result... Though I doubt it can change much 
> > > because there was not that much relevant non-security things in the merge 
> > > in question.
> > 
> > I'm not a master of git-foo, so that is not an option.  However, a dinky
> > bisection c142bda4..847106f very clearly says...
> > 
> > marge:..kernel/linux-2.6.27.git # git bisect bad
> > 6f0f0fd496333777d53daff21a4e3b28c4d03a6d is first bad commit
> > commit 6f0f0fd496333777d53daff21a4e3b28c4d03a6d
> > Author: James Morris <jmorris@namei.org>
> > Date:   Thu Jul 10 17:02:07 2008 +0900
> > 
> >     security: remove register_security hook
> > 
> >     The register security hook is no longer required, as the capability
> >     module is always registered.  LSMs wishing to stack capability as
> >     a secondary module should do so explicitly.
> > 
> >     Signed-off-by: James Morris <jmorris@namei.org>
> >     Acked-by: Stephen Smalley <sds@tycho.nsa.gov>
> >     Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
> > 
> > :040000 040000 0177ef46d305e51e27bfcc4350a40577f8ba8d3d 64b64c10a424df4539653a8ee34f1a2329300931 M      include
> > :040000 040000 e318891e514de674fd064f6bfad70d5633b1aff1 0dbb38d5aa7fc3e4b2e09dc65796ce7cd5faeb26 M      security
> 
> Which is high grade horse-pookey.

perhaps re-test commit 6f0f0fd49 and its parent commit, 93cbace7a0.

It looks like a potentially bogus bisection result, but _maybe_ it has 
relevance: changes the size of "struct security_operations", which could 
have alignment and layout effects on all sorts of kernel variables, 
kmalloc sizes, etc.

	Ingo

Re: [Bug #11308] tbench regression on each kernel release from 2.6.22 -> 2.6.28

[Mike Galbraith]

On Wed, 2008-09-17 at 12:40 +0200, Ingo Molnar wrote:
> * Mike Galbraith <efault@gmx.de> wrote:
> 
> > On Wed, 2008-09-17 at 06:40 +0200, Mike Galbraith wrote:
> > > On Tue, 2008-09-16 at 17:07 +0300, Ilpo Järvinen wrote:
> > 
> > > > One additional sanity check could be to rebase security 6f0f0fd4963 on top 
> > > > of the c142bda458a and then see if bisection among those security commits 
> > > > on top yields to the the same result... Though I doubt it can change much 
> > > > because there was not that much relevant non-security things in the merge 
> > > > in question.
> > > 
> > > I'm not a master of git-foo, so that is not an option.  However, a dinky
> > > bisection c142bda4..847106f very clearly says...
> > > 
> > > marge:..kernel/linux-2.6.27.git # git bisect bad
> > > 6f0f0fd496333777d53daff21a4e3b28c4d03a6d is first bad commit
> > > commit 6f0f0fd496333777d53daff21a4e3b28c4d03a6d
> > > Author: James Morris <jmorris@namei.org>
> > > Date:   Thu Jul 10 17:02:07 2008 +0900
> > > 
> > >     security: remove register_security hook
> > > 
> > >     The register security hook is no longer required, as the capability
> > >     module is always registered.  LSMs wishing to stack capability as
> > >     a secondary module should do so explicitly.
> > > 
> > >     Signed-off-by: James Morris <jmorris@namei.org>
> > >     Acked-by: Stephen Smalley <sds@tycho.nsa.gov>
> > >     Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
> > > 
> > > :040000 040000 0177ef46d305e51e27bfcc4350a40577f8ba8d3d 64b64c10a424df4539653a8ee34f1a2329300931 M      include
> > > :040000 040000 e318891e514de674fd064f6bfad70d5633b1aff1 0dbb38d5aa7fc3e4b2e09dc65796ce7cd5faeb26 M      security
> > 
> > Which is high grade horse-pookey.
> 
> perhaps re-test commit 6f0f0fd49 and its parent commit, 93cbace7a0.

Will do.

> It looks like a potentially bogus bisection result, but _maybe_ it has 
> relevance: changes the size of "struct security_operations", which could 
> have alignment and layout effects on all sorts of kernel variables, 
> kmalloc sizes, etc.

This may well be a mythical creature infestation for all I know ;-), but
it's address is somewhere in the 2069f45..847106f block, 316 commits,
none of which look like they should be the least bit interesting to
netperf.  I reverted this particular commit in 27.git, got the expected
result.  Looks like I'll keep poking at it, can't seem to resist.  Grr.

	-Mike

Re: [Bug #11308] tbench regression on each kernel release from 2.6.22 -> 2.6.28

[Ingo Molnar]

* Mike Galbraith <efault@gmx.de> wrote:

> > It looks like a potentially bogus bisection result, but _maybe_ it 
> > has relevance: changes the size of "struct security_operations", 
> > which could have alignment and layout effects on all sorts of kernel 
> > variables, kmalloc sizes, etc.
> 
> This may well be a mythical creature infestation for all I know ;-), 
> but it's address is somewhere in the 2069f45..847106f block, 316 
> commits, none of which look like they should be the least bit 
> interesting to netperf.  I reverted this particular commit in 27.git, 
> got the expected result.  Looks like I'll keep poking at it, can't 
> seem to resist.  Grr.

are you sure it's 2069f45..847106f? Filtering out the 
likely-uninteresting commits:

git log --pretty=format:"%h: %s" 2069f45..847106f | grep -viE \
'block|alsa|pcmcia|sound|Merge|iosched|blk|DAC960|scsi|s390|paride|pktcdvd|filter|cdrom|drm'

gives us:

 7daf705: Start using the new '%pS' infrastructure to print symbols
 6f0f0fd: security: remove register_security hook
 93cbace: security: remove dummy module fix
 5915eb5: security: remove dummy module
 b478a9f: security: remove unused sb_get_mnt_opts hook
 32502b8: splice: fix generic_file_splice_read() race with page invalidation
 8b3d356: ramfs: enable splice write
 a144ff0: xen: Avoid allocations causing swap activity on the resume path

which really only leaves that security commit your bisection fingered. 
Which _slightly_ raises its likelyhood of being implicated. Structure 
size changes can move two formerly far-apart netperf-relevant symbols on 
the same cacheline, which can start cache ping-pong-ing badly.

It wouldnt be the first such incident - alignment changes impacting 
macro benchmarks. (and it's hard to find it as the thing that changes 
alignment/size/sharedness might be something totally unrelated)

It's still a bit too early to say this for sure though ...

	Ingo

Re: [Bug #11308] tbench regression on each kernel release from 2.6.22 -> 2.6.28

[Mike Galbraith]

On Wed, 2008-09-17 at 14:49 +0200, Ingo Molnar wrote:
> * Mike Galbraith <efault@gmx.de> wrote:
> 
> > > It looks like a potentially bogus bisection result, but _maybe_ it 
> > > has relevance: changes the size of "struct security_operations", 
> > > which could have alignment and layout effects on all sorts of kernel 
> > > variables, kmalloc sizes, etc.
> > 
> > This may well be a mythical creature infestation for all I know ;-), 
> > but it's address is somewhere in the 2069f45..847106f block, 316 
> > commits, none of which look like they should be the least bit 
> > interesting to netperf.  I reverted this particular commit in 27.git, 
> > got the expected result.  Looks like I'll keep poking at it, can't 
> > seem to resist.  Grr.
> 
> are you sure it's 2069f45..847106f? Filtering out the 
> likely-uninteresting commits:

Yeah, as sure as I can be.  I've built both (et al) kernels several
times, and it has repeated every time.  Would be nice if someone would
try to confirm/deny though.  For my little quad, I do..

#!/bin/sh

echo 0 > /proc/sys/kernel/sched_wakeup_granularity_ns 

netserver -p 12865
netserver -p 12866
netserver -p 12867
netserver -p 12868

netperf -p 12865 -t TCP_RR -l 60 -H 127.0.0.1 -T 0,0 -- -r 1,1&
netperf -p 12866 -t TCP_RR -l 60 -H 127.0.0.1 -T 1,1 -- -r 1,1&
netperf -p 12867 -t TCP_RR -l 60 -H 127.0.0.1 -T 2,2 -- -r 1,1&
netperf -p 12868 -t TCP_RR -l 60 -H 127.0.0.1 -T 3,3 -- -r 1,1&

wait
killall netserver


> git log --pretty=format:"%h: %s" 2069f45..847106f | grep -viE \
> 'block|alsa|pcmcia|sound|Merge|iosched|blk|DAC960|scsi|s390|paride|pktcdvd|filter|cdrom|drm'
> 
> gives us:
> 
>  7daf705: Start using the new '%pS' infrastructure to print symbols
>  6f0f0fd: security: remove register_security hook
>  93cbace: security: remove dummy module fix
>  5915eb5: security: remove dummy module
>  b478a9f: security: remove unused sb_get_mnt_opts hook
>  32502b8: splice: fix generic_file_splice_read() race with page invalidation
>  8b3d356: ramfs: enable splice write
>  a144ff0: xen: Avoid allocations causing swap activity on the resume path
> 
> which really only leaves that security commit your bisection fingered. 
> Which _slightly_ raises its likelyhood of being implicated. Structure 
> size changes can move two formerly far-apart netperf-relevant symbols on 
> the same cacheline, which can start cache ping-pong-ing badly.

I sure hope it's something like ping-pong, it's driving me NUTS.

	-Mike

Re: [Bug #11308] tbench regression on each kernel release from 2.6.22 -> 2.6.28

[Ilpo Järvinen]

On Wed, 17 Sep 2008, Mike Galbraith wrote:

> On Wed, 2008-09-17 at 14:49 +0200, Ingo Molnar wrote:
> 
> > git log --pretty=format:"%h: %s" 2069f45..847106f | grep -viE \
> > 'block|alsa|pcmcia|sound|Merge|iosched|blk|DAC960|scsi|s390|paride|pktcdvd|filter|cdrom|drm'
> > 
> > gives us:
> > 
> >  7daf705: Start using the new '%pS' infrastructure to print symbols
> >  6f0f0fd: security: remove register_security hook
> >  93cbace: security: remove dummy module fix
> >  5915eb5: security: remove dummy module
> >  b478a9f: security: remove unused sb_get_mnt_opts hook
> >  32502b8: splice: fix generic_file_splice_read() race with page invalidation
> >  8b3d356: ramfs: enable splice write
> >  a144ff0: xen: Avoid allocations causing swap activity on the resume path
> > 
> > which really only leaves that security commit your bisection fingered. 
> > Which _slightly_ raises its likelyhood of being implicated. Structure 
> > size changes can move two formerly far-apart netperf-relevant symbols on 
> > the same cacheline, which can start cache ping-pong-ing badly.
> 
> I sure hope it's something like ping-pong, it's driving me NUTS.

How about dividing the problem to smaller blocks then by restoring 
parts of the change...


-- 
 i.

Re: [Bug #11308] tbench regression on each kernel release from 2.6.22 -> 2.6.28

[Mike Galbraith]

On Wed, 2008-09-17 at 16:36 +0300, Ilpo Järvinen wrote:
> On Wed, 17 Sep 2008, Mike Galbraith wrote:
> 
> > On Wed, 2008-09-17 at 14:49 +0200, Ingo Molnar wrote:
> > 
> > > git log --pretty=format:"%h: %s" 2069f45..847106f | grep -viE \
> > > 'block|alsa|pcmcia|sound|Merge|iosched|blk|DAC960|scsi|s390|paride|pktcdvd|filter|cdrom|drm'
> > > 
> > > gives us:
> > > 
> > >  7daf705: Start using the new '%pS' infrastructure to print symbols
> > >  6f0f0fd: security: remove register_security hook
> > >  93cbace: security: remove dummy module fix
> > >  5915eb5: security: remove dummy module
> > >  b478a9f: security: remove unused sb_get_mnt_opts hook
> > >  32502b8: splice: fix generic_file_splice_read() race with page invalidation
> > >  8b3d356: ramfs: enable splice write
> > >  a144ff0: xen: Avoid allocations causing swap activity on the resume path
> > > 
> > > which really only leaves that security commit your bisection fingered. 
> > > Which _slightly_ raises its likelyhood of being implicated. Structure 
> > > size changes can move two formerly far-apart netperf-relevant symbols on 
> > > the same cacheline, which can start cache ping-pong-ing badly.
> > 
> > I sure hope it's something like ping-pong, it's driving me NUTS.
> 
> How about dividing the problem to smaller blocks then by restoring 
> parts of the change...

Well, what I've done is check out the "bad" tree, reverted every darn
commit between there and the "good" tree, and then reverted the reverts
so I have a nice merge-free line and don't have to remember to think
backward.  (probably sounds silly to git-foo masters)  I'll try
bisecting that in the a.m. and see what happens.

	-Mike

Re: [Bug #11276] build error: CONFIG_OPTIMIZE_INLINING=y causes gcc 4.2 to do stupid things

[Bjorn Helgaas]

On Friday 12 September 2008 03:19:17 pm Rafael J. Wysocki wrote:
> On Friday, 12 of September 2008, Randy Dunlap wrote:
> > Rafael J. Wysocki wrote:
> > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11276
> > > Subject		: build error: CONFIG_OPTIMIZE_INLINING=y causes gcc 4.2 to do stupid things
> > > Submitter	: Randy Dunlap <randy.dunlap@oracle.com>
> > > Date		: 2008-08-06 17:18 (38 days old)
> > > References	: http://marc.info/?l=linux-kernel&m=121804329014332&w=4
> > > 		  http://lkml.org/lkml/2008/7/22/353
> > > Handled-By	: Bjorn Helgaas <bjorn.helgaas@hp.com>
> > > Patch		: http://lkml.org/lkml/2008/7/22/364

Thanks for pointing out the fix that should have been obvious,
Dave.  That's a much better solution than sprinkling #ifdef
CONFIG_PNP through drivers.

Rafael, in case you missed the checkin, it's commit
ef3d7714f6b75b51825ad0384b5ce48358427e50

Bjorn

Re: [Bug #11308] tbench regression on each kernel release from 2.6.22 -> 2.6.28

[Eric Dumazet]

Mike Galbraith a écrit :
> On Wed, 2008-09-17 at 14:49 +0200, Ingo Molnar wrote:
>> * Mike Galbraith <efault@gmx.de> wrote:
>>
>>>> It looks like a potentially bogus bisection result, but _maybe_ it 
>>>> has relevance: changes the size of "struct security_operations", 
>>>> which could have alignment and layout effects on all sorts of kernel 
>>>> variables, kmalloc sizes, etc.
>>> This may well be a mythical creature infestation for all I know ;-), 
>>> but it's address is somewhere in the 2069f45..847106f block, 316 
>>> commits, none of which look like they should be the least bit 
>>> interesting to netperf.  I reverted this particular commit in 27.git, 
>>> got the expected result.  Looks like I'll keep poking at it, can't 
>>> seem to resist.  Grr.
>> are you sure it's 2069f45..847106f? Filtering out the 
>> likely-uninteresting commits:
> 
> Yeah, as sure as I can be.  I've built both (et al) kernels several
> times, and it has repeated every time.  Would be nice if someone would
> try to confirm/deny though.  For my little quad, I do..
> 
> #!/bin/sh
> 
> echo 0 > /proc/sys/kernel/sched_wakeup_granularity_ns 
> 
> netserver -p 12865
> netserver -p 12866
> netserver -p 12867
> netserver -p 12868
> 
> netperf -p 12865 -t TCP_RR -l 60 -H 127.0.0.1 -T 0,0 -- -r 1,1&
> netperf -p 12866 -t TCP_RR -l 60 -H 127.0.0.1 -T 1,1 -- -r 1,1&
> netperf -p 12867 -t TCP_RR -l 60 -H 127.0.0.1 -T 2,2 -- -r 1,1&
> netperf -p 12868 -t TCP_RR -l 60 -H 127.0.0.1 -T 3,3 -- -r 1,1&
> 
> wait
> killall netserver
> 
> 
>> git log --pretty=format:"%h: %s" 2069f45..847106f | grep -viE \
>> 'block|alsa|pcmcia|sound|Merge|iosched|blk|DAC960|scsi|s390|paride|pktcdvd|filter|cdrom|drm'
>>
>> gives us:
>>
>>  7daf705: Start using the new '%pS' infrastructure to print symbols
>>  6f0f0fd: security: remove register_security hook
>>  93cbace: security: remove dummy module fix
>>  5915eb5: security: remove dummy module
>>  b478a9f: security: remove unused sb_get_mnt_opts hook
>>  32502b8: splice: fix generic_file_splice_read() race with page invalidation
>>  8b3d356: ramfs: enable splice write
>>  a144ff0: xen: Avoid allocations causing swap activity on the resume path
>>
>> which really only leaves that security commit your bisection fingered. 
>> Which _slightly_ raises its likelyhood of being implicated. Structure 
>> size changes can move two formerly far-apart netperf-relevant symbols on 
>> the same cacheline, which can start cache ping-pong-ing badly.
> 
> I sure hope it's something like ping-pong, it's driving me NUTS.

Could you please try following patch ?

[PATCH] security_ops moved to read_mostly section

"struct security_operations *security_ops" should be moved to read_mostly 
section in order to NOT let it share a cache line with higly modified variables.

Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>

diff --git a/security/security.c b/security/security.c
index 3a4b4f5..0b13d65 100644
--- a/security/security.c
+++ b/security/security.c
@@ -24,7 +24,7 @@ static __initdata char chosen_lsm[SECURITY_NAME_MAX + 1];
 extern struct security_operations default_security_ops;
 extern void security_fixup_ops(struct security_operations *ops);
 
-struct security_operations *security_ops;	/* Initialized to NULL */
+struct security_operations *security_ops __read_mostly;e
 
 /* amount of vm to protect from userspace access */
 unsigned long mmap_min_addr = CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR;

Re: [Bug #11308] tbench regression on each kernel release from 2.6.22 -> 2.6.28

[Eric Dumazet]

Eric Dumazet a écrit :
> Mike Galbraith a écrit :

>> I sure hope it's something like ping-pong, it's driving me NUTS.
> 
> Could you please try following patch ?
> 
> [PATCH] security_ops moved to read_mostly section
> 
> "struct security_operations *security_ops" should be moved to 
> read_mostly section in order to NOT let it share a cache line with higly 
> modified variables.
> 
> Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
> 
> diff --git a/security/security.c b/security/security.c
> index 3a4b4f5..0b13d65 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -24,7 +24,7 @@ static __initdata char chosen_lsm[SECURITY_NAME_MAX + 1];
> extern struct security_operations default_security_ops;
> extern void security_fixup_ops(struct security_operations *ops);
> 
> -struct security_operations *security_ops;    /* Initialized to NULL */
> +struct security_operations *security_ops __read_mostly;e

Sorry for the extra 'e' at the end of this line, please remove it :)

> 
> /* amount of vm to protect from userspace access */
> unsigned long mmap_min_addr = CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR;
> 

Re: [Bug #11308] tbench regression on each kernel release from 2.6.22 -> 2.6.28

[Ilpo Järvinen]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2273 bytes --]

On Wed, 17 Sep 2008, Mike Galbraith wrote:

> On Wed, 2008-09-17 at 16:36 +0300, Ilpo Järvinen wrote:
> > On Wed, 17 Sep 2008, Mike Galbraith wrote:
> > 
> > > On Wed, 2008-09-17 at 14:49 +0200, Ingo Molnar wrote:
> > > 
> > > > git log --pretty=format:"%h: %s" 2069f45..847106f | grep -viE \
> > > > 'block|alsa|pcmcia|sound|Merge|iosched|blk|DAC960|scsi|s390|paride|pktcdvd|filter|cdrom|drm'
> > > > 
> > > > gives us:
> > > > 
> > > >  7daf705: Start using the new '%pS' infrastructure to print symbols
> > > >  6f0f0fd: security: remove register_security hook
> > > >  93cbace: security: remove dummy module fix
> > > >  5915eb5: security: remove dummy module
> > > >  b478a9f: security: remove unused sb_get_mnt_opts hook
> > > >  32502b8: splice: fix generic_file_splice_read() race with page invalidation
> > > >  8b3d356: ramfs: enable splice write
> > > >  a144ff0: xen: Avoid allocations causing swap activity on the resume path
> > > > 
> > > > which really only leaves that security commit your bisection fingered. 
> > > > Which _slightly_ raises its likelyhood of being implicated. Structure 
> > > > size changes can move two formerly far-apart netperf-relevant symbols on 
> > > > the same cacheline, which can start cache ping-pong-ing badly.
> > > 
> > > I sure hope it's something like ping-pong, it's driving me NUTS.
> > 
> > How about dividing the problem to smaller blocks then by restoring 
> > parts of the change...
> 
> Well, what I've done is check out the "bad" tree, reverted every darn
> commit between there and the "good" tree, and then reverted the reverts
> so I have a nice merge-free line and don't have to remember to think
> backward.  (probably sounds silly to git-foo masters)  I'll try
> bisecting that in the a.m. and see what happens.

This was my initial idea (which was mainly an error from my part as I 
misread some shaids and midunderstood that the first regressing would be 
the merge instead of the actual change), but in here I meant taking parts 
of the 6f0f0fd on top of 6f0f0fd^. The most easiest way to do that 
actually might be to do in fact the opposite, ie., but some of the 
datastructure/layout changes back on top of 6f0f0fd and see if the 
performance get restored (besides testing the Eric's patch).

-- 
 i.

Re: [Bug #11308] tbench regression on each kernel release from 2.6.22 -> 2.6.28

[Mike Galbraith]

On Wed, 2008-09-17 at 16:47 +0200, Eric Dumazet wrote:

> Could you please try following patch ?
> 
> [PATCH] security_ops moved to read_mostly section
> 
> "struct security_operations *security_ops" should be moved to read_mostly 
> section in order to NOT let it share a cache line with higly modified variables.

v2.6.26-974-g2846693 (tip of revert reverts tree, == 847106f)
16384  87380  1        1       60.00    94350.45
16384  87380  1        1       60.01    95857.25
16384  87380  1        1       60.00    95334.84
16384  87380  1        1       60.00    95052.11

v2.6.26-659-g7804ad8 (first commit prior, == 2069f45)
16384  87380  1        1       60.00    98630.64
16384  87380  1        1       60.00    98653.14
16384  87380  1        1       60.00    99162.65
16384  87380  1        1       60.00    98652.38

v2.6.26-974-g2846693 patched
16384  87380  1        1       60.00    95877.41
16384  87380  1        1       60.00    95810.27
16384  87380  1        1       60.00    95530.03
16384  87380  1        1       60.00    94968.12

(poo, "it" didn't die)

Re: [Bug #11500] /proc/net bug related to selinux

[Andrew Morton]

On Mon, 15 Sep 2008 09:05:26 -0400
Stephen Smalley <sds@tycho.nsa.gov> wrote:

> 
> On Sat, 2008-09-13 at 12:37 -0700, Andrew Morton wrote:
> > On Sat, 13 Sep 2008 10:15:43 +1000 (EST) James Morris <jmorris@namei.org> wrote:
> > 
> > > On Fri, 12 Sep 2008, Andrew Morton wrote:
> > > 
> > > > > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11500
> > > > > > Subject		: /proc/net bug related to selinux
> > > > > > Submitter	: Andrew Morton <akpm@linux-foundation.org>
> > > > > > Date		: 2008-09-04 17:45 (9 days old)
> > > > > > References	: http://marc.info/?l=linux-kernel&m=122055041313270&w=4
> > > > > 
> > > > > I think this might be a regression caused by namespace changes which we 
> > > 
> > > By which I mean, this was caused by a non-SELinux change to the upstream 
> > > kernel many, many eons ago.
> > 
> > hm, seems that 2.6.24 is OK but 2.6.25 is not.  I must have missed the
> > bug when testing 2.6.25-based kernels.
> > 
> > I started a git bisection search but after half an hour I hit bad
> > bisection breakage: a complete machine hang in fib_rules_init().
> > 
> > > > > addressed in SELinux policy.  Which distro version & policy version is 
> > > > > this seen with?
> > > > > 
> > > > 
> > > > FC5 on x86_32 and FC6 on x86_64.
> > > 
> > > As mentioned in the bugzilla, any related avc messages would be useful.
> > 
> > 2.6.25 dmesg: http://userweb.kernel.org/~akpm/dmesg-sony.txt
> > /var/log/messages: http://userweb.kernel.org/~akpm/messages-sony.txt
> > 
> > The latter includes this:
> > 
> > Sep 13 12:32:43 sony kernel: SELinux:  class key not defined in policy
> > Sep 13 12:32:43 sony kernel: SELinux:  class dccp_socket not defined in policy
> > Sep 13 12:32:43 sony kernel: SELinux:  class memprotect not defined in policy
> > Sep 13 12:32:43 sony kernel: SELinux:  class peer not defined in policy
> > Sep 13 12:32:43 sony kernel: SELinux:  class capability2 not defined in policy
> > Sep 13 12:32:43 sony kernel: SELinux:  permission open in class dir not defined in policy
> > Sep 13 12:32:43 sony kernel: SELinux:  permission open in class file not defined in policy
> > Sep 13 12:32:43 sony kernel: SELinux:  permission open in class chr_file not defined in policy
> > Sep 13 12:32:43 sony kernel: SELinux:  permission open in class blk_file not defined in policy
> > Sep 13 12:32:43 sony kernel: SELinux:  permission open in class fifo_file not defined in policy
> > Sep 13 12:32:43 sony kernel: SELinux:  permission dccp_recv in class node not defined in policy
> > Sep 13 12:32:43 sony kernel: SELinux:  permission dccp_send in class node not defined in policy
> > Sep 13 12:32:43 sony kernel: SELinux:  permission recvfrom in class node not defined in policy
> > Sep 13 12:32:43 sony kernel: SELinux:  permission sendto in class node not defined in policy
> > Sep 13 12:32:43 sony kernel: SELinux:  permission dccp_recv in class netif not defined in policy
> > Sep 13 12:32:43 sony kernel: SELinux:  permission dccp_send in class netif not defined in policy
> > Sep 13 12:32:43 sony kernel: SELinux:  permission ingress in class netif not defined in policy
> > Sep 13 12:32:43 sony kernel: SELinux:  permission egress in class netif not defined in policy
> > Sep 13 12:32:44 sony kernel: SELinux:  permission setkeycreate in class process not defined in policy
> > Sep 13 12:32:44 sony kernel: SELinux:  permission setsockcreate in class process not defined in policy
> > Sep 13 12:32:44 sony kernel: SELinux:  permission setfcap in class capability not defined in policy
> > Sep 13 12:32:44 sony kernel: SELinux:  permission polmatch in class association not defined in policy
> > Sep 13 12:32:44 sony kernel: SELinux:  permission flow_in in class packet not defined in policy
> > Sep 13 12:32:44 sony kernel: SELinux:  permission flow_out in class packet not defined in policy
> > Sep 13 12:32:44 sony kernel: SELinux:  permission forward_in in class packet not defined in policy
> > Sep 13 12:32:44 sony kernel: SELinux:  permission forward_out in class packet not defined in policy
> > Sep 13 12:32:44 sony kernel: SELinux: the above unknown classes and permissions will be denied
> > Sep 13 12:32:44 sony kernel: type=1403 audit(1221309118.644:3): policy loaded auid=4294967295 ses=4294967295
> > Sep 13 12:32:44 sony kernel: type=1400 audit(1221334321.726:4): avc:  denied  { audit_write } for  pid=400 comm="hwclock" capability=29 scontext=system_u:system_r:hwclock_t:s0 tcontext=system_u:system_r:hwclock_t:s0 tclass=capability
> > 
> > 
> > Why am I seeing this on two machines and two vanilla-installed distros
> > but nobody else is reporting it?

Running `ls -l /proc/net' on the FC6 machine produces:

[  132.591215] type=1400 audit(1221679672.590:10): avc:  denied  { getattr } for  pid=4389 comm="ls" path="/proc/net" dev=proc ino=4026531867 scontext=user_u:system_r:unconfined_t:s0 tcontext=system_u:object_r:proc_net_t:s0 tclass=lnk_file


> What we actually need to see is the output of:
> /sbin/ausearch -i -m AVC -sv no

akpm2:/home/akpm# /sbin/ausearch -i -m AVC -sv no 
<no matches>

> However, the most likely explanation is simply that when /proc/net was
> changed from being a directory to being a symlink to /proc/self/net,
> that introduced an additional permission check on accesses
> of /proc/net/<whatever>, namely the read check on the symlink itself.
> And since that check wasn't happening on /proc/net accesses with older
> kernels, older policies didn't allow it.
> 
> As to why others haven't reported it, I expect that they have updated
> their policies to newer ones that allow the necessary access.  The fact
> that legacy distros wouldn't have such updated policies isn't surprising
> - they don't push updates to those distros for new kernels.  FC5 and FC6
> are both EOL'd, right?
> 
> In any event, we didn't change anything in SELinux - the change was
> elsewhere (in the proc/net implementation).  Don't blame the messenger
> please.
> 

Vanilla FC5 broke and vanilla FC6 broke.  Did vanilla FC7, 8 or 9 break?

http://smolt.fedoraproject.org/static/stats/stats.html shows 11,000-odd
people running FC5 and FC6.  It would be incautious to assume that all
those people have updated their selinux rules.

And _requiring_ people to update their selinux rules to fix a
kernel-caused regression is a pretty big deal for some people, I
expect.

Then again, given that this regression has been out there since 2.6.25,
I guess not too many people are hurting from it.  But we suck.

Re: [Bug #11500] /proc/net bug related to selinux

[Paul Moore]

On Wednesday 17 September 2008 3:50:53 pm Andrew Morton wrote:
> On Mon, 15 Sep 2008 09:05:26 -0400
> Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > However, the most likely explanation is simply that when /proc/net
> > was changed from being a directory to being a symlink to
> > /proc/self/net, that introduced an additional permission check on
> > accesses of /proc/net/<whatever>, namely the read check on the
> > symlink itself. And since that check wasn't happening on /proc/net
> > accesses with older kernels, older policies didn't allow it.
> >
> > As to why others haven't reported it, I expect that they have
> > updated their policies to newer ones that allow the necessary
> > access.  The fact that legacy distros wouldn't have such updated
> > policies isn't surprising - they don't push updates to those
> > distros for new kernels.  FC5 and FC6 are both EOL'd, right?
> >
> > In any event, we didn't change anything in SELinux - the change was
> > elsewhere (in the proc/net implementation).  Don't blame the
> > messenger please.
>
> Vanilla FC5 broke and vanilla FC6 broke.  Did vanilla FC7, 8 or 9
> break?
>
> http://smolt.fedoraproject.org/static/stats/stats.html shows
> 11,000-odd people running FC5 and FC6.  It would be incautious to
> assume that all those people have updated their selinux rules.
>
> And _requiring_ people to update their selinux rules to fix a
> kernel-caused regression is a pretty big deal for some people, I
> expect.

Just so I'm clear on the context of the problem, it sounds like if a FC5 
(I'm limiting myself to FC5 for the moment) user upgraded to a recent 
(2.6.25+) kernel (non-distro supplied in the case of FC5) then they 
will run into problems unless they also upgrade their SELinux policy, 
yes?

If that is the case I'm not sure it is really that big of a deal.  Maybe 
I'm in the minority here, but in my mind once you step away from the 
distro supplied kernel (also applies to other packages, although those 
are arguably less critical) you should also bear the responsibility to 
make sure you upgrade/tweak/install whatever other bits need to be 
fixed.

> Then again, given that this regression has been out there since
> 2.6.25, I guess not too many people are hurting from it.  But we
> suck.

We suck?  Maybe, but some explanation about why we suck in this 
particular case would be helpful as far as I'm concerned.  I don't 
really care about identifying the guilty suckees, I'm more interested 
in finding out what happened to cause us to suck because of this.

-- 
paul moore
linux @ hp

Re: [Bug #11500] /proc/net bug related to selinux

[Eric W. Biederman]

Paul Moore <paul.moore@hp.com> writes:

> We suck?  Maybe, but some explanation about why we suck in this 
> particular case would be helpful as far as I'm concerned.  I don't 
> really care about identifying the guilty suckees, I'm more interested 
> in finding out what happened to cause us to suck because of this.

Agreed.  I believe we carefully gave selinux the same paths for /proc/net
that it had before so I don't know why this affects user space.

I know we had some selinux review when we made the change.

Eric

Re: [Bug #11500] /proc/net bug related to selinux

[Andrew Morton]

On Wed, 17 Sep 2008 17:24:36 -0400
Paul Moore <paul.moore@hp.com> wrote:

> On Wednesday 17 September 2008 3:50:53 pm Andrew Morton wrote:
> > On Mon, 15 Sep 2008 09:05:26 -0400
> > Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > > However, the most likely explanation is simply that when /proc/net
> > > was changed from being a directory to being a symlink to
> > > /proc/self/net, that introduced an additional permission check on
> > > accesses of /proc/net/<whatever>, namely the read check on the
> > > symlink itself. And since that check wasn't happening on /proc/net
> > > accesses with older kernels, older policies didn't allow it.
> > >
> > > As to why others haven't reported it, I expect that they have
> > > updated their policies to newer ones that allow the necessary
> > > access.  The fact that legacy distros wouldn't have such updated
> > > policies isn't surprising - they don't push updates to those
> > > distros for new kernels.  FC5 and FC6 are both EOL'd, right?
> > >
> > > In any event, we didn't change anything in SELinux - the change was
> > > elsewhere (in the proc/net implementation).  Don't blame the
> > > messenger please.
> >
> > Vanilla FC5 broke and vanilla FC6 broke.  Did vanilla FC7, 8 or 9
> > break?
> >
> > http://smolt.fedoraproject.org/static/stats/stats.html shows
> > 11,000-odd people running FC5 and FC6.  It would be incautious to
> > assume that all those people have updated their selinux rules.
> >
> > And _requiring_ people to update their selinux rules to fix a
> > kernel-caused regression is a pretty big deal for some people, I
> > expect.
> 
> Just so I'm clear on the context of the problem, it sounds like if a FC5 
> (I'm limiting myself to FC5 for the moment) user upgraded to a recent 
> (2.6.25+) kernel (non-distro supplied in the case of FC5) then they 
> will run into problems unless they also upgrade their SELinux policy, 
> yes?

That only true if the 2.6.25+ kernel.org kernel is
backward-incompatible with the distro kernel.

> If that is the case I'm not sure it is really that big of a deal.  Maybe 
> I'm in the minority here, but in my mind once you step away from the 
> distro supplied kernel (also applies to other packages, although those 
> are arguably less critical) you should also bear the responsibility to 
> make sure you upgrade/tweak/install whatever other bits need to be 
> fixed.

Nope.  Releasing a non-backward-compatible kernel.org kernel is a big
deal.

We'll do it sometimes, with long notice, much care and much deliberation.

We did it this time by sheer accident.  That's known in the trade as a
"bug".

> > Then again, given that this regression has been out there since
> > 2.6.25, I guess not too many people are hurting from it.  But we
> > suck.
> 
> We suck?  Maybe, but some explanation about why we suck in this 
> particular case would be helpful as far as I'm concerned.  I don't 
> really care about identifying the guilty suckees, I'm more interested 
> in finding out what happened to cause us to suck because of this.

Because we unintentionally and unknowingly released a kernel which is
not compatible with previous kernels without notifying any of our users
and without any consideration or planning.

Yes, often the consequences of the screwup are fairly small, but it's a
screwup nonetheless.



We don't even know the extent of the damage yet.  Which distros were
affected? With which versions of which userspace packages?

Re: [Bug #11500] /proc/net bug related to selinux

[Eric W. Biederman]

Andrew Morton <akpm@linux-foundation.org> writes:

> On Mon, 15 Sep 2008 09:05:26 -0400
> Stephen Smalley <sds@tycho.nsa.gov> wrote:

>> On Sat, 2008-09-13 at 12:37 -0700, Andrew Morton wrote:
>> However, the most likely explanation is simply that when /proc/net was
>> changed from being a directory to being a symlink to /proc/self/net,
>> that introduced an additional permission check on accesses
>> of /proc/net/<whatever>, namely the read check on the symlink itself.
>> And since that check wasn't happening on /proc/net accesses with older
>> kernels, older policies didn't allow it.

>> As to why others haven't reported it, I expect that they have updated
>> their policies to newer ones that allow the necessary access.  The fact
>> that legacy distros wouldn't have such updated policies isn't surprising
>> - they don't push updates to those distros for new kernels.  FC5 and FC6
>> are both EOL'd, right?
>> 
>> In any event, we didn't change anything in SELinux - the change was
>> elsewhere (in the proc/net implementation).  Don't blame the messenger
>> please.
>> 
>
> Vanilla FC5 broke and vanilla FC6 broke.  Did vanilla FC7, 8 or 9 break?
>
> http://smolt.fedoraproject.org/static/stats/stats.html shows 11,000-odd
> people running FC5 and FC6.  It would be incautious to assume that all
> those people have updated their selinux rules.
>
> And _requiring_ people to update their selinux rules to fix a
> kernel-caused regression is a pretty big deal for some people, I
> expect.

> Then again, given that this regression has been out there since 2.6.25,
> I guess not too many people are hurting from it.  But we suck.

Looking at this discussion closely from what I see selinux is designed
to work on the principle of least privilege.  If you make a user space
visible but compatible change, selinux will keep the system until
you update selinux.  Is selinux exposing too much to user space?
    
selinux was taken into consideration when the change was made.
The patch was even updated with feedback from Stephen Smiley.

> commit e9720acd728a46cb40daa52c99a979f7c4ff195c
> Author: Pavel Emelyanov <xemul@openvz.org>
> Date:   Fri Mar 7 11:08:40 2008 -0800
> 
>     [NET]: Make /proc/net a symlink on /proc/self/net (v3)
>     
>     Current /proc/net is done with so called "shadows", but current
>     implementation is broken and has little chances to get fixed.
>     
>     The problem is that dentries subtree of /proc/net directory has
>     fancy revalidation rules to make processes living in different
>     net namespaces see different entries in /proc/net subtree, but
>     currently, tasks see in the /proc/net subdir the contents of any
>     other namespace, depending on who opened the file first.
>     
>     The proposed fix is to turn /proc/net into a symlink, which points
>     to /proc/self/net, which in turn shows what previously was in
>     /proc/net - the network-related info, from the net namespace the
>     appropriate task lives in.
>     
>     # ls -l /proc/net
>     lrwxrwxrwx  1 root root 8 Mar  5 15:17 /proc/net -> self/net
>     
>     In other words - this behaves like /proc/mounts, but unlike
>     "mounts", "net" is not a file, but a directory.
>     
>     Changes from v2:
>     * Fixed discrepancy of /proc/net nlink count and selinux labeling
>       screwup pointed out by Stephen.
>     
>       To get the correct nlink count the ->getattr callback for /proc/net
>       is overridden to read one from the net->proc_net entry.
>     
>       To make selinux still work the net->proc_net entry is initialized
>       properly, i.e. with the "net" name and the proc_net parent.
>     
>     Selinux fixes are
>     Acked-by:  Stephen Smalley <sds@tycho.nsa.gov>
>     
>     Changes from v1:
>     * Fixed a task_struct leak in get_proc_task_net, pointed out by Paul.
>     
>     Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
>     Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
>     Signed-off-by: David S. Miller <davem@davemloft.net>

Re: [Bug #11500] /proc/net bug related to selinux

[Andrew Morton]

On Wed, 17 Sep 2008 14:39:45 -0700
ebiederm@xmission.com (Eric W. Biederman) wrote:

> Paul Moore <paul.moore@hp.com> writes:
> 
> > We suck?  Maybe, but some explanation about why we suck in this 
> > particular case would be helpful as far as I'm concerned.  I don't 
> > really care about identifying the guilty suckees, I'm more interested 
> > in finding out what happened to cause us to suck because of this.
> 
> Agreed.  I believe we carefully gave selinux the same paths for /proc/net
> that it had before so I don't know why this affects user space.
> 
> I know we had some selinux review when we made the change.
> 
> Eric

It's back up-thread somewhere.  umm...

On Mon, 15 Sep 2008 09:05:26 -0400
Stephen Smalley <sds@tycho.nsa.gov> wrote:

> However, the most likely explanation is simply that when /proc/net was
> changed from being a directory to being a symlink to /proc/self/net,
> that introduced an additional permission check on accesses
> of /proc/net/<whatever>, namely the read check on the symlink itself.
> And since that check wasn't happening on /proc/net accesses with older
> kernels, older policies didn't allow it.

Re: [Bug #11500] /proc/net bug related to selinux

[Paul Moore]

On Wednesday 17 September 2008 5:48:42 pm Andrew Morton wrote:
> On Wed, 17 Sep 2008 17:24:36 -0400
>
> Paul Moore <paul.moore@hp.com> wrote:
> > On Wednesday 17 September 2008 3:50:53 pm Andrew Morton wrote:
> > > On Mon, 15 Sep 2008 09:05:26 -0400
> > >
> > > Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > > > However, the most likely explanation is simply that when
> > > > /proc/net was changed from being a directory to being a symlink
> > > > to /proc/self/net, that introduced an additional permission
> > > > check on accesses of /proc/net/<whatever>, namely the read
> > > > check on the symlink itself. And since that check wasn't
> > > > happening on /proc/net accesses with older kernels, older
> > > > policies didn't allow it.
> > > >
> > > > As to why others haven't reported it, I expect that they have
> > > > updated their policies to newer ones that allow the necessary
> > > > access.  The fact that legacy distros wouldn't have such
> > > > updated policies isn't surprising - they don't push updates to
> > > > those distros for new kernels.  FC5 and FC6 are both EOL'd,
> > > > right?
> > > >
> > > > In any event, we didn't change anything in SELinux - the change
> > > > was elsewhere (in the proc/net implementation).  Don't blame
> > > > the messenger please.
> > >
> > > Vanilla FC5 broke and vanilla FC6 broke.  Did vanilla FC7, 8 or 9
> > > break?
> > >
> > > http://smolt.fedoraproject.org/static/stats/stats.html shows
> > > 11,000-odd people running FC5 and FC6.  It would be incautious to
> > > assume that all those people have updated their selinux rules.
> > >
> > > And _requiring_ people to update their selinux rules to fix a
> > > kernel-caused regression is a pretty big deal for some people, I
> > > expect.
> >
> > Just so I'm clear on the context of the problem, it sounds like if
> > a FC5 (I'm limiting myself to FC5 for the moment) user upgraded to
> > a recent (2.6.25+) kernel (non-distro supplied in the case of FC5)
> > then they will run into problems unless they also upgrade their
> > SELinux policy, yes?
>
> That only true if the 2.6.25+ kernel.org kernel is
> backward-incompatible with the distro kernel.

Yep, just wanted to make sure I was understanding the problem correctly.

> > If that is the case I'm not sure it is really that big of a deal. 
> > Maybe I'm in the minority here, but in my mind once you step away
> > from the distro supplied kernel (also applies to other packages,
> > although those are arguably less critical) you should also bear the
> > responsibility to make sure you upgrade/tweak/install whatever
> > other bits need to be fixed.
>
> Nope.  Releasing a non-backward-compatible kernel.org kernel is a big
> deal.

Well, there is also the issue of distro specific "special sauce" patches 
which might cause different behavior from the kernel.org kernel, but 
now we are starting to do down a rat hole ...

> We'll do it sometimes, with long notice, much care and much
> deliberation.
>
> We did it this time by sheer accident.  That's known in the trade as
> a "bug".

It is somewhat comforting to know that we can call what we do a "trade", 
further commentary on my part is best left to the imagination :)

> > > Then again, given that this regression has been out there since
> > > 2.6.25, I guess not too many people are hurting from it.  But we
> > > suck.
> >
> > We suck?  Maybe, but some explanation about why we suck in this
> > particular case would be helpful as far as I'm concerned.  I don't
> > really care about identifying the guilty suckees, I'm more
> > interested in finding out what happened to cause us to suck because
> > of this.
>
> Because we unintentionally and unknowingly released a kernel which is
> not compatible with previous kernels without notifying any of our
> users and without any consideration or planning.
>
> Yes, often the consequences of the screwup are fairly small, but it's
> a screwup nonetheless.

Okay, so we suck because broke something in 2.6.25 that went undetected 
because current SELinux policies happen to be compatible with the 
breakage.  Gotcha.

> We don't even know the extent of the damage yet.  Which distros were
> affected? With which versions of which userspace packages?

Can I assume that the "right" thing to do would be to find the problem 
and revert whatever change caused the issue, yes?  Or are we happy to 
wait and see since the fallout so far has been minimal?

-- 
paul moore
linux @ hp

Re: [Bug #11500] /proc/net bug related to selinux

[David Miller]

From: Paul Moore <paul.moore@hp.com>
Date: Wed, 17 Sep 2008 17:24:36 -0400

> If that is the case I'm not sure it is really that big of a deal.  Maybe 
> I'm in the minority here, but in my mind once you step away from the 
> distro supplied kernel (also applies to other packages, although those 
> are arguably less critical) you should also bear the responsibility to 
> make sure you upgrade/tweak/install whatever other bits need to be 
> fixed.

No, we tend to call this breaking things instead.

Re: [Bug #11500] /proc/net bug related to selinux

[Andrew Morton]

On Wed, 17 Sep 2008 18:12:59 -0400
Paul Moore <paul.moore@hp.com> wrote:

> > We don't even know the extent of the damage yet.  Which distros were
> > affected? With which versions of which userspace packages?
> 
> Can I assume that the "right" thing to do would be to find the problem 
> and revert whatever change caused the issue, yes?  Or are we happy to 
> wait and see since the fallout so far has been minimal?

I don't think a revert is justified after all this time.  afaik I'm the
first person to notice the problem, and it's been out there for
multiple months.

However it would be good if we could find some not-completely-stinky
way of making the old userspace work.

otoh, people who are shipping 2.6.25- and 2.6.26-based distros probably
wouldn't want such a patch in their kernels anyway.

Re: [Bug #11500] /proc/net bug related to selinux

[Eric W. Biederman]

Andrew Morton <akpm@linux-foundation.org> writes:

> We don't even know the extent of the damage yet.  Which distros were
> affected? With which versions of which userspace packages?

This seems to me to be an extremely fragile selinux user space policy.
In their code that derives security labels from path names.
Why don't we have AppArmor in the kernel again?

Further I don't see how we could have possibly have supported that user space
policy.  How can we apply a user space defined label required by the selinux
policy to a symlink that did not exist?

I expect cd /proc/self/net would work.  In your situation and you can
see /proc/self/net/dev.

Everything here sounds to me like that selinux policy is impossibly brittle.
And anything that is that brittle I have no intention in claiming is a bug
in proc.

Eric

Re: [Bug #11500] /proc/net bug related to selinux

[Eric W. Biederman]

Andrew Morton <akpm@linux-foundation.org> writes:

> On Wed, 17 Sep 2008 18:12:59 -0400
> Paul Moore <paul.moore@hp.com> wrote:
>
>> > We don't even know the extent of the damage yet.  Which distros were
>> > affected? With which versions of which userspace packages?
>> 
>> Can I assume that the "right" thing to do would be to find the problem 
>> and revert whatever change caused the issue, yes?  Or are we happy to 
>> wait and see since the fallout so far has been minimal?
>
> I don't think a revert is justified after all this time.  afaik I'm the
> first person to notice the problem, and it's been out there for
> multiple months.
>
> However it would be good if we could find some not-completely-stinky
> way of making the old userspace work.
>
> otoh, people who are shipping 2.6.25- and 2.6.26-based distros probably
> wouldn't want such a patch in their kernels anyway.

Disable selinux?

Get a selinux mystic to update that selinux policy.  I bet it is a one line
change to each the policy about /proc/net as a symlink.

Although I am puzzled why we don't get the same label as /proc/net as a directory
had.

Eric

Re: [Bug #11308] tbench regression on each kernel release from 2.6.22 -> 2.6.28

[Mike Galbraith]

On Wed, 2008-09-17 at 15:57 +0200, Mike Galbraith wrote:
> On Wed, 2008-09-17 at 16:36 +0300, Ilpo Järvinen wrote:
> > On Wed, 17 Sep 2008, Mike Galbraith wrote:
> > 
> > > On Wed, 2008-09-17 at 14:49 +0200, Ingo Molnar wrote:
> > > 
> > > > git log --pretty=format:"%h: %s" 2069f45..847106f | grep -viE \
> > > > 'block|alsa|pcmcia|sound|Merge|iosched|blk|DAC960|scsi|s390|paride|pktcdvd|filter|cdrom|drm'
> > > > 
> > > > gives us:
> > > > 
> > > >  7daf705: Start using the new '%pS' infrastructure to print symbols
> > > >  6f0f0fd: security: remove register_security hook
> > > >  93cbace: security: remove dummy module fix
> > > >  5915eb5: security: remove dummy module
> > > >  b478a9f: security: remove unused sb_get_mnt_opts hook
> > > >  32502b8: splice: fix generic_file_splice_read() race with page invalidation
> > > >  8b3d356: ramfs: enable splice write
> > > >  a144ff0: xen: Avoid allocations causing swap activity on the resume path
> > > > 
> > > > which really only leaves that security commit your bisection fingered. 
> > > > Which _slightly_ raises its likelyhood of being implicated. Structure 
> > > > size changes can move two formerly far-apart netperf-relevant symbols on 
> > > > the same cacheline, which can start cache ping-pong-ing badly.
> > > 
> > > I sure hope it's something like ping-pong, it's driving me NUTS.
> > 
> > How about dividing the problem to smaller blocks then by restoring 
> > parts of the change...
> 
> Well, what I've done is check out the "bad" tree, reverted every darn
> commit between there and the "good" tree, and then reverted the reverts
> so I have a nice merge-free line and don't have to remember to think
> backward.  (probably sounds silly to git-foo masters)  I'll try
> bisecting that in the a.m. and see what happens.

It bisected to 1c9ce52.  Reverting that in 27.git had the expected
result, nada.  Full bisection/test log below - you can jump straight to
post run sanity checks.  I'm torn between building a straight line tree
from v2.6.26 through git.today and bisecting that sucker, or exorcising
netperf from my box and swearing a sacred oath to never download the
damned thing again.  Nuking netperf is most attractive option.

1e65e841bb5584136ed6047c55cf77532afbbb55 is first bad commit
commit 1e65e841bb5584136ed6047c55cf77532afbbb55
Author: Mike Galbraith <efault@gmx.de>
Date:   Wed Sep 17 14:55:50 2008 +0200

    Revert "Revert "block: export "ro" attribute""

    This reverts commit 2c8803af5c1bf41200167f29349f7f1396683a51.

:040000 040000 08ca8ba7ff3f9506a5462b4122256356cae28ceb bef679485bc924ad1dc867858ebda1b68196b5a8 M      block


git bisect start
# good: [7804ad865f7d0cd9bdc51da601772ce4d2e252ca] Revert "[ALSA] soc - tlv320aic3x - revisit clock setup"
git bisect good 7804ad865f7d0cd9bdc51da601772ce4d2e252ca
# bad: [2846693a63a34ac6d582dd55a7e00605b49b1cec] Revert "Revert "[S390] sclp_tty: Fix scheduling while atomic bug.""
git bisect bad 2846693a63a34ac6d582dd55a7e00605b49b1cec
# bad: [70477f86f63640be2dd1d8968aeb47870a5c21c6] Revert "Revert "xen/blkfront: Make sure we don't use bounce buffers, we don't need them.""
git bisect bad 70477f86f63640be2dd1d8968aeb47870a5c21c6
# good: [7c6ccb520424939deff0a50f3fae621c6477dbbe] Revert "Revert "ALSA: hda - Add bdl_pos_adj option""
git bisect good 7c6ccb520424939deff0a50f3fae621c6477dbbe
# good: [66036beae94f043f99044e285935486126a9c4bd] Revert "Revert "pcmcia: fix Alchemy warnings""
git bisect good 66036beae94f043f99044e285935486126a9c4bd
# good: [6b7b5ef18871c8f7c15eedc6eb53270eaf8bc613] Revert "Revert "ALSA: hda - Added SSID for 'Fujitsu Siemens Amilo M1451G' laptop""
git bisect good 6b7b5ef18871c8f7c15eedc6eb53270eaf8bc613
# good: [024905ea4b2d1ab5d6b845ba84ddfc0857fb2d2a] Revert "Revert "ALSA: hda - Add MacBook 3.1 support""
git bisect good 024905ea4b2d1ab5d6b845ba84ddfc0857fb2d2a
# good: [4bbe3501e06eddaa4900894efa519f1167cb8624] Revert "Revert "as-iosched: properly protect ioc_gone and ioc count""
git bisect good 4bbe3501e06eddaa4900894efa519f1167cb8624
# good: [e124683c1cd5c73c494f9ea6cee8a71e68bb70ca] Revert "Revert "Added in user-injected messages into blk traces""
git bisect good e124683c1cd5c73c494f9ea6cee8a71e68bb70ca
# bad: [f148fae0bc009aa23122c5762368a1a16bb55b86] Revert "Revert "block: kill request_queue_t""
git bisect bad f148fae0bc009aa23122c5762368a1a16bb55b86
# bad: [1e65e841bb5584136ed6047c55cf77532afbbb55] Revert "Revert "block: export "ro" attribute""
git bisect bad 1e65e841bb5584136ed6047c55cf77532afbbb55


v2.6.26-974-g2846693 (847106f)
16384  87380  1        1       60.00    94350.45
16384  87380  1        1       60.01    95857.25
16384  87380  1        1       60.00    95334.84
16384  87380  1        1       60.00    95052.11

v2.6.26-659-g7804ad8 (2069f45)
16384  87380  1        1       60.00    98630.64
16384  87380  1        1       60.00    98653.14
16384  87380  1        1       60.00    99162.65
16384  87380  1        1       60.00    98652.38

v2.6.26-816-g70477f8 (call it bad)
16384  87380  1        1       60.00    95532.19
16384  87380  1        1       60.01    96211.39
16384  87380  1        1       60.01    96246.73
16384  87380  1        1       60.01    96286.40

v2.6.26-737-g7c6ccb5
16384  87380  1        1       60.00    98478.00
16384  87380  1        1       60.00    99221.33
16384  87380  1        1       60.00    98930.70
16384  87380  1        1       60.00    98958.73

v2.6.26-776-g66036be
16384  87380  1        1       60.00    97958.10
16384  87380  1        1       60.01    98683.80
16384  87380  1        1       60.01    98515.34
16384  87380  1        1       60.00    98396.11

v2.6.26-796-g6b7b5ef
16384  87380  1        1       60.00    99047.21
16384  87380  1        1       60.00    98095.23
16384  87380  1        1       60.00    99811.18
16384  87380  1        1       60.00    98651.32

v2.6.26-806-g024905e
16384  87380  1        1       60.00    98823.46
16384  87380  1        1       60.00    98959.11
16384  87380  1        1       60.00    98709.95
16384  87380  1        1       60.00    99042.13

v2.6.26-811-g4bbe350
16384  87380  1        1       60.00    98144.99
16384  87380  1        1       60.01    99023.30
16384  87380  1        1       60.01    98685.45
16384  87380  1        1       60.01    98606.18

v2.6.26-813-ge124683
16384  87380  1        1       60.00    98458.18
16384  87380  1        1       60.00    98163.92
16384  87380  1        1       60.00    98115.62
16384  87380  1        1       60.00    98633.62

v2.6.26-815-gf148fae
16384  87380  1        1       60.00    95649.91
16384  87380  1        1       60.00    96292.34
16384  87380  1        1       60.00    96043.82
16384  87380  1        1       60.00    96093.81

v2.6.26-814-g1e65e84
16384  87380  1        1       60.00    94906.81
16384  87380  1        1       60.00    95445.05
16384  87380  1        1       60.01    94698.68
16384  87380  1        1       60.00    94938.65

Post bisection checkouts
------------------------------------------------
v2.6.26-rc8-208-g02c6230
16384  87380  1        1       60.00    98392.94
16384  87380  1        1       60.00    98199.96
16384  87380  1        1       60.00    98534.27
16384  87380  1        1       60.00    98501.02

v2.6.26-rc8-209-g1c9ce52
16384  87380  1        1       60.00    97583.88
16384  87380  1        1       60.00    97326.23
16384  87380  1        1       60.00    97582.80
16384  87380  1        1       60.00    97568.63

v2.6.26-814-g1e65e84
16384  87380  1        1       60.00    94856.33
16384  87380  1        1       60.00    94594.03
16384  87380  1        1       60.00    94751.74
16384  87380  1        1       60.01    96825.28

v2.6.26-813-ge124683
16384  87380  1        1       60.00    97550.64
16384  87380  1        1       60.00    98024.28
16384  87380  1        1       60.00    98486.85
16384  87380  1        1       60.00    98493.41


marge:..git/linux-2.6 # git rev-list v2.6.26-813-ge124683..v2.6.26-814-g1e65e84
1e65e841bb5584136ed6047c55cf77532afbbb55
marge:..git/linux-2.6 # git show 1e65e841bb5584136ed6047c55cf77532afbbb55

commit 1e65e841bb5584136ed6047c55cf77532afbbb55
Author: Mike Galbraith <efault@gmx.de>
Date:   Wed Sep 17 14:55:50 2008 +0200

    Revert "Revert "block: export "ro" attribute""
    
    This reverts commit 2c8803af5c1bf41200167f29349f7f1396683a51.

diff --git a/block/genhd.c b/block/genhd.c
index b922d48..43e468e 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -400,6 +400,14 @@ static ssize_t disk_removable_show(struct device *dev,
 		       (disk->flags & GENHD_FL_REMOVABLE ? 1 : 0));
 }
 
+static ssize_t disk_ro_show(struct device *dev,
+				   struct device_attribute *attr, char *buf)
+{
+	struct gendisk *disk = dev_to_disk(dev);
+
+	return sprintf(buf, "%d\n", disk->policy ? 1 : 0);
+}
+
 static ssize_t disk_size_show(struct device *dev,
 			      struct device_attribute *attr, char *buf)
 {
@@ -472,6 +480,7 @@ static ssize_t disk_fail_store(struct device *dev,
 
 static DEVICE_ATTR(range, S_IRUGO, disk_range_show, NULL);
 static DEVICE_ATTR(removable, S_IRUGO, disk_removable_show, NULL);
+static DEVICE_ATTR(ro, S_IRUGO, disk_ro_show, NULL);
 static DEVICE_ATTR(size, S_IRUGO, disk_size_show, NULL);
 static DEVICE_ATTR(capability, S_IRUGO, disk_capability_show, NULL);
 static DEVICE_ATTR(stat, S_IRUGO, disk_stat_show, NULL);
@@ -483,6 +492,7 @@ static struct device_attribute dev_attr_fail =
 static struct attribute *disk_attrs[] = {
 	&dev_attr_range.attr,
 	&dev_attr_removable.attr,
+	&dev_attr_ro.attr,
 	&dev_attr_size.attr,
 	&dev_attr_capability.attr,
 	&dev_attr_stat.attr,

Re: [Bug #11308] tbench regression on each kernel release from 2.6.22 -> 2.6.28

[Mike Galbraith]

On Thu, 2008-09-18 at 09:12 +0200, Mike Galbraith wrote:

> 1e65e841bb5584136ed6047c55cf77532afbbb55 is first bad commit
> commit 1e65e841bb5584136ed6047c55cf77532afbbb55
> Author: Mike Galbraith <efault@gmx.de>
> Date:   Wed Sep 17 14:55:50 2008 +0200
> 
>     Revert "Revert "block: export "ro" attribute""
> 
>     This reverts commit 2c8803af5c1bf41200167f29349f7f1396683a51.

BTW, the reason it's revert revert is that I reverse bisected the revert
tree yesterday, and it emitted the same darn result.  I immediately said
"yeah right, ya screwed up", and created the revert revert tree to make
sure I couldn't fumble negation.

	-Mike

Re: [Bug #11308] tbench regression on each kernel release from 2.6.22 -> 2.6.28

[Ilpo Järvinen]

On Thu, 18 Sep 2008, Mike Galbraith wrote:

> On Thu, 2008-09-18 at 09:12 +0200, Mike Galbraith wrote:
> 
> > 1e65e841bb5584136ed6047c55cf77532afbbb55 is first bad commit
> > commit 1e65e841bb5584136ed6047c55cf77532afbbb55
> > Author: Mike Galbraith <efault@gmx.de>
> > Date:   Wed Sep 17 14:55:50 2008 +0200
> > 
> >     Revert "Revert "block: export "ro" attribute""
> > 
> >     This reverts commit 2c8803af5c1bf41200167f29349f7f1396683a51.
> 
> BTW, the reason it's revert revert is that I reverse bisected the revert
> tree yesterday, and it emitted the same darn result.  I immediately said
> "yeah right, ya screwed up", and created the revert revert tree to make
> sure I couldn't fumble negation.

:-)

gcc compiling something slightly differently would be a nice theory but 
it sort of breaks down now as this commit touches only one .c file...
In the past when I did some static inline .h -> .c uninline sizing tests
I noticed that some changes happened also in places which should have been 
quite much unrelated. Though all the changes were minor anyway (in the 
places I did look), e.g., routed the conditional paths slightly 
differently and added one xor clear reg.

-- 
 i.

Re: [Bug #11500] /proc/net bug related to selinux

[Stephen Smalley]

On Wed, 2008-09-17 at 15:32 -0700, Eric W. Biederman wrote:
> Andrew Morton <akpm@linux-foundation.org> writes:
> 
> > We don't even know the extent of the damage yet.  Which distros were
> > affected? With which versions of which userspace packages?
> 
> This seems to me to be an extremely fragile selinux user space policy.
> In their code that derives security labels from path names.
> Why don't we have AppArmor in the kernel again?

I think I explained that one before - in the case of /proc, the only
stable basis we have for deducing the security properties / protection
requirements for a given entry is its name, and its name can be reliably
constructed from the kernel's internal proc_dir_entry tree w/o any
ambiguity or potential for userspace manipulation (unlike the pathname
returned by d_path for a normal file).  I'd agree that it isn't optimal,
but it is what we have.

> Further I don't see how we could have possibly have supported that user space
> policy.  How can we apply a user space defined label required by the selinux
> policy to a symlink that did not exist?

I'm not blaming anyone here, or trying to argue that the /proc/net
changes should be reverted.  What happened here is that a kernel
interface (/proc/net) changed in a subtle way that had a side effect on
permission checking, and we tried to hide that change at the time (in
terms of ensuring that the new /proc/self/net tree would still be
labeled correctly), and we missed the fact that there would still be a
new check on the symlink read that wouldn't be covered by existing
policy.

> Everything here sounds to me like that selinux policy is impossibly brittle.
> And anything that is that brittle I have no intention in claiming is a bug
> in proc.

I'm not arguing that this is a bug in proc or in selinux for that
matter.

I do however think that the mantra that we can't require users to update
policy for kernel changes is unsupportable in general.  The precise set
of permission checks on a given operation is not set in stone and it is
not part of the kernel/userland interface/contract.  Policy isn't
"userspace"; it governs what userspace can do, and it has to adapt to
kernel changes.

Users who are willing/able to run the latest kernel on their own w/o
waiting for a coordinated update of kernel and policy from their
distribution ought to be able to create a local policy module - it isn't
rocket science, and they can always fall back on audit2allow if they
need to do so.

-- 
Stephen Smalley
National Security Agency

Re: [Bug #11500] /proc/net bug related to selinux

[Stephen Smalley]

On Thu, 2008-09-18 at 08:38 -0400, Stephen Smalley wrote:
> On Wed, 2008-09-17 at 15:32 -0700, Eric W. Biederman wrote:
> > Andrew Morton <akpm@linux-foundation.org> writes:
> > 
> > > We don't even know the extent of the damage yet.  Which distros were
> > > affected? With which versions of which userspace packages?
> > 
> > This seems to me to be an extremely fragile selinux user space policy.
> > In their code that derives security labels from path names.
> > Why don't we have AppArmor in the kernel again?
> 
> I think I explained that one before - in the case of /proc, the only
> stable basis we have for deducing the security properties / protection
> requirements for a given entry is its name, and its name can be reliably
> constructed from the kernel's internal proc_dir_entry tree w/o any
> ambiguity or potential for userspace manipulation (unlike the pathname
> returned by d_path for a normal file).  I'd agree that it isn't optimal,
> but it is what we have.
> 
> > Further I don't see how we could have possibly have supported that user space
> > policy.  How can we apply a user space defined label required by the selinux
> > policy to a symlink that did not exist?
> 
> I'm not blaming anyone here, or trying to argue that the /proc/net
> changes should be reverted.  What happened here is that a kernel
> interface (/proc/net) changed in a subtle way that had a side effect on
> permission checking, and we tried to hide that change at the time (in
> terms of ensuring that the new /proc/self/net tree would still be
> labeled correctly), and we missed the fact that there would still be a
> new check on the symlink read that wouldn't be covered by existing
> policy.
> 
> > Everything here sounds to me like that selinux policy is impossibly brittle.
> > And anything that is that brittle I have no intention in claiming is a bug
> > in proc.
> 
> I'm not arguing that this is a bug in proc or in selinux for that
> matter.
> 
> I do however think that the mantra that we can't require users to update
> policy for kernel changes is unsupportable in general.  The precise set
> of permission checks on a given operation is not set in stone and it is
> not part of the kernel/userland interface/contract.  Policy isn't
> "userspace"; it governs what userspace can do, and it has to adapt to
> kernel changes.

I should note here that for changes to SELinux, we have gone out of our
way to avoid such breakage to date through the introduction of
compatibility switches, policy flags to enable any new checks, etc
(albeit at a cost in complexity and ever creeping compatibility code).
But changes to the rest of the kernel can just as easily alter the set
of permission checks that get applied on a given operation, and I don't
think we are always going to be able to guarantee that new kernel + old
policy will Just Work. 

> Users who are willing/able to run the latest kernel on their own w/o
> waiting for a coordinated update of kernel and policy from their
> distribution ought to be able to create a local policy module - it isn't
> rocket science, and they can always fall back on audit2allow if they
> need to do so.

-- 
Stephen Smalley
National Security Agency

Re: [Bug #11500] /proc/net bug related to selinux

[Eric W. Biederman]

Stephen Smalley <sds@tycho.nsa.gov> writes:

> On Thu, 2008-09-18 at 08:38 -0400, Stephen Smalley wrote:
>> I do however think that the mantra that we can't require users to update
>> policy for kernel changes is unsupportable in general.  The precise set
>> of permission checks on a given operation is not set in stone and it is
>> not part of the kernel/userland interface/contract.  Policy isn't
>> "userspace"; it governs what userspace can do, and it has to adapt to
>> kernel changes.
>
> I should note here that for changes to SELinux, we have gone out of our
> way to avoid such breakage to date through the introduction of
> compatibility switches, policy flags to enable any new checks, etc
> (albeit at a cost in complexity and ever creeping compatibility code).
> But changes to the rest of the kernel can just as easily alter the set
> of permission checks that get applied on a given operation, and I don't
> think we are always going to be able to guarantee that new kernel + old
> policy will Just Work. 

I know of at least 2 more directories that I intend to turn into
symlinks into somewhere under /proc/self.  How do we keep from
breaking selinux policies when I do that?

For comparison how do we handle sysfs? 
How do we handle device nodes in tmpfs?
Ultimately do we want to implement xattrs and inotify on /proc?  
Or is there another way that would simplify maintenance?

Eric

Re: [Bug #11500] /proc/net bug related to selinux

[Stephen Smalley]

On Thu, 2008-09-18 at 11:09 -0700, Eric W. Biederman wrote:
> Stephen Smalley <sds@tycho.nsa.gov> writes:
> 
> > On Thu, 2008-09-18 at 08:38 -0400, Stephen Smalley wrote:
> >> I do however think that the mantra that we can't require users to update
> >> policy for kernel changes is unsupportable in general.  The precise set
> >> of permission checks on a given operation is not set in stone and it is
> >> not part of the kernel/userland interface/contract.  Policy isn't
> >> "userspace"; it governs what userspace can do, and it has to adapt to
> >> kernel changes.
> >
> > I should note here that for changes to SELinux, we have gone out of our
> > way to avoid such breakage to date through the introduction of
> > compatibility switches, policy flags to enable any new checks, etc
> > (albeit at a cost in complexity and ever creeping compatibility code).
> > But changes to the rest of the kernel can just as easily alter the set
> > of permission checks that get applied on a given operation, and I don't
> > think we are always going to be able to guarantee that new kernel + old
> > policy will Just Work. 
> 
> I know of at least 2 more directories that I intend to turn into
> symlinks into somewhere under /proc/self.  How do we keep from
> breaking selinux policies when I do that?

I suspect we could tweak the logic in selinux_proc_get_sid() to always
label all symlinks under /proc with the base proc_t type already used
for e.g. /proc/self, at which point existing policies would be ok.

> For comparison how do we handle sysfs?

Unresolved; presently has a single label for all nodes.
See https://bugzilla.redhat.com/show_bug.cgi?id=228902
for prior discussion of fine-grained labeling support for sysfs.

> How do we handle device nodes in tmpfs?

udev has selinux support - looks up the appropriate context in a
userland config file (file_contexts) via libselinux matchpathcon(3) and
sets it upon creation.  tmpfs has long supported getting/setting
security.* attributes.

> Ultimately do we want to implement xattrs and inotify on /proc?  
> Or is there another way that would simplify maintenance?

If proc supported setxattr, then I suppose early userspace could label
it instead of the kernel needing to determine a label internally.  But
not sure how we'd cleanly migrate to avoid breakage with old userspace.

-- 
Stephen Smalley
National Security Agency

Re: [Bug #11506] oops during unmount - ext3? (2.6.27-rc5)

[Marcin Slusarz]

On Fri, Sep 12, 2008 at 09:06:29PM +0200, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.26.  Please verify if it still should be listed and let me know
> (either way).

I didn't see it since I upgraded to -rc6. You can close it for now.

> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11506
> Subject		: oops during unmount - ext3? (2.6.27-rc5)
> Submitter	: Marcin Slusarz <marcin.slusarz@gmail.com>
> Date		: 2008-09-04 19:14 (9 days old)
> References	: http://marc.info/?l=linux-kernel&m=122055573123449&w=4
> 
> 

Marcin

Re: [Bug #11500] /proc/net bug related to selinux

[david]

On Thu, 18 Sep 2008, Stephen Smalley wrote:

> On Thu, 2008-09-18 at 11:09 -0700, Eric W. Biederman wrote:
>> Stephen Smalley <sds@tycho.nsa.gov> writes:
>>
>>> On Thu, 2008-09-18 at 08:38 -0400, Stephen Smalley wrote:
>>>> I do however think that the mantra that we can't require users to update
>>>> policy for kernel changes is unsupportable in general.  The precise set
>>>> of permission checks on a given operation is not set in stone and it is
>>>> not part of the kernel/userland interface/contract.  Policy isn't
>>>> "userspace"; it governs what userspace can do, and it has to adapt to
>>>> kernel changes.
>>>
>>> I should note here that for changes to SELinux, we have gone out of our
>>> way to avoid such breakage to date through the introduction of
>>> compatibility switches, policy flags to enable any new checks, etc
>>> (albeit at a cost in complexity and ever creeping compatibility code).
>>> But changes to the rest of the kernel can just as easily alter the set
>>> of permission checks that get applied on a given operation, and I don't
>>> think we are always going to be able to guarantee that new kernel + old
>>> policy will Just Work.
>>
>> I know of at least 2 more directories that I intend to turn into
>> symlinks into somewhere under /proc/self.  How do we keep from
>> breaking selinux policies when I do that?
>
> I suspect we could tweak the logic in selinux_proc_get_sid() to always
> label all symlinks under /proc with the base proc_t type already used
> for e.g. /proc/self, at which point existing policies would be ok.

so if proc is mounted anywhere other then /proc the selinux policy would 
do odd things?

David Lang

>> For comparison how do we handle sysfs?
>
> Unresolved; presently has a single label for all nodes.
> See https://bugzilla.redhat.com/show_bug.cgi?id=228902
> for prior discussion of fine-grained labeling support for sysfs.
>
>> How do we handle device nodes in tmpfs?
>
> udev has selinux support - looks up the appropriate context in a
> userland config file (file_contexts) via libselinux matchpathcon(3) and
> sets it upon creation.  tmpfs has long supported getting/setting
> security.* attributes.
>
>> Ultimately do we want to implement xattrs and inotify on /proc?
>> Or is there another way that would simplify maintenance?
>
> If proc supported setxattr, then I suppose early userspace could label
> it instead of the kernel needing to determine a label internally.  But
> not sure how we'd cleanly migrate to avoid breakage with old userspace.
>
>

Re: [Bug #11500] /proc/net bug related to selinux

[Stephen Smalley]

On Fri, 2008-09-19 at 09:58 -0700, david@lang.hm wrote:
> On Thu, 18 Sep 2008, Stephen Smalley wrote:
> 
> > On Thu, 2008-09-18 at 11:09 -0700, Eric W. Biederman wrote:
> >> Stephen Smalley <sds@tycho.nsa.gov> writes:
> >>
> >>> On Thu, 2008-09-18 at 08:38 -0400, Stephen Smalley wrote:
> >>>> I do however think that the mantra that we can't require users to update
> >>>> policy for kernel changes is unsupportable in general.  The precise set
> >>>> of permission checks on a given operation is not set in stone and it is
> >>>> not part of the kernel/userland interface/contract.  Policy isn't
> >>>> "userspace"; it governs what userspace can do, and it has to adapt to
> >>>> kernel changes.
> >>>
> >>> I should note here that for changes to SELinux, we have gone out of our
> >>> way to avoid such breakage to date through the introduction of
> >>> compatibility switches, policy flags to enable any new checks, etc
> >>> (albeit at a cost in complexity and ever creeping compatibility code).
> >>> But changes to the rest of the kernel can just as easily alter the set
> >>> of permission checks that get applied on a given operation, and I don't
> >>> think we are always going to be able to guarantee that new kernel + old
> >>> policy will Just Work.
> >>
> >> I know of at least 2 more directories that I intend to turn into
> >> symlinks into somewhere under /proc/self.  How do we keep from
> >> breaking selinux policies when I do that?
> >
> > I suspect we could tweak the logic in selinux_proc_get_sid() to always
> > label all symlinks under /proc with the base proc_t type already used
> > for e.g. /proc/self, at which point existing policies would be ok.
> 
> so if proc is mounted anywhere other then /proc the selinux policy would 
> do odd things?

No, the logic doesn't care where proc is mounted.  Only the name
relative to the root of proc is used.

-- 
Stephen Smalley
National Security Agency

Re: [Bug #11500] /proc/net bug related to selinux

[Stephen Smalley]

On Thu, 2008-09-18 at 14:34 -0400, Stephen Smalley wrote:
> On Thu, 2008-09-18 at 11:09 -0700, Eric W. Biederman wrote:
> > Stephen Smalley <sds@tycho.nsa.gov> writes:
> > 
> > > On Thu, 2008-09-18 at 08:38 -0400, Stephen Smalley wrote:
> > >> I do however think that the mantra that we can't require users to update
> > >> policy for kernel changes is unsupportable in general.  The precise set
> > >> of permission checks on a given operation is not set in stone and it is
> > >> not part of the kernel/userland interface/contract.  Policy isn't
> > >> "userspace"; it governs what userspace can do, and it has to adapt to
> > >> kernel changes.
> > >
> > > I should note here that for changes to SELinux, we have gone out of our
> > > way to avoid such breakage to date through the introduction of
> > > compatibility switches, policy flags to enable any new checks, etc
> > > (albeit at a cost in complexity and ever creeping compatibility code).
> > > But changes to the rest of the kernel can just as easily alter the set
> > > of permission checks that get applied on a given operation, and I don't
> > > think we are always going to be able to guarantee that new kernel + old
> > > policy will Just Work. 
> > 
> > I know of at least 2 more directories that I intend to turn into
> > symlinks into somewhere under /proc/self.  How do we keep from
> > breaking selinux policies when I do that?
> 
> I suspect we could tweak the logic in selinux_proc_get_sid() to always
> label all symlinks under /proc with the base proc_t type already used
> for e.g. /proc/self, at which point existing policies would be ok.

FWIW, a fix for this issue has been applied to:
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6#next

The particular commit can be viewed at:
http://git.kernel.org/?p=linux/kernel/git/jmorris/security-testing-2.6.git;a=commit;h=ea6b184f7d521a503ecab71feca6e4057562252b

This should address not only the /proc/net breakage but also any future
changes to turn existing directories into symlinks.

-- 
Stephen Smalley
National Security Agency

[Bug #11276] build error: CONFIG_OPTIMIZE_INLINING=y causes gcc 4.2 to do stupid things

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11276
Subject		: build error: CONFIG_OPTIMIZE_INLINING=y causes gcc 4.2 to do stupid things
Submitter	: Randy Dunlap <randy.dunlap@oracle.com>
Date		: 2008-08-06 17:18 (32 days old)
References	: http://marc.info/?l=linux-kernel&m=121804329014332&w=4
		  http://lkml.org/lkml/2008/7/22/353
Handled-By	: Bjorn Helgaas <bjorn.helgaas@hp.com>
Patch		: http://lkml.org/lkml/2008/7/22/364

[Bug #11276] build error: CONFIG_OPTIMIZE_INLINING=y causes gcc 4.2 to do stupid things

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11276
Subject		: build error: CONFIG_OPTIMIZE_INLINING=y causes gcc 4.2 to do stupid things
Submitter	: Randy Dunlap <randy.dunlap@oracle.com>
Date		: 2008-08-06 17:18 (25 days old)
References	: http://marc.info/?l=linux-kernel&m=121804329014332&w=4
		  http://lkml.org/lkml/2008/7/22/353
Handled-By	: Bjorn Helgaas <bjorn.helgaas@hp.com>
Patch		: http://lkml.org/lkml/2008/7/22/364

[Bug #11276] build error: CONFIG_OPTIMIZE_INLINING=y causes gcc 4.2 to do stupid things

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11276
Subject		: build error: CONFIG_OPTIMIZE_INLINING=y causes gcc 4.2 to do stupid things
Submitter	: Randy Dunlap <randy.dunlap@oracle.com>
Date		: 2008-08-06 17:18 (18 days old)
References	: http://marc.info/?l=linux-kernel&m=121804329014332&w=4
		  http://lkml.org/lkml/2008/7/22/353
Handled-By	: Bjorn Helgaas <bjorn.helgaas@hp.com>
Patch		: http://lkml.org/lkml/2008/7/22/364

[Bug #11276] build error: CONFIG_OPTIMIZE_INLINING=y causes gcc 4.2 to do stupid things

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11276
Subject		: build error: CONFIG_OPTIMIZE_INLINING=y causes gcc 4.2 to do stupid things
Submitter	: Randy Dunlap <randy.dunlap@oracle.com>
Date		: 2008-08-06 17:18 (11 days old)
References	: http://marc.info/?l=linux-kernel&m=121804329014332&w=4
		  http://lkml.org/lkml/2008/7/22/353
Handled-By	: Bjorn Helgaas <bjorn.helgaas@hp.com>
Patch		: http://lkml.org/lkml/2008/7/22/364

Re: [Bug #11276] build error: CONFIG_OPTIMIZE_INLINING=y causes gcc 4.2 to do stupid things

[Ingo Molnar]

* Bjorn Helgaas <bjorn.helgaas@hp.com> wrote:

> On Saturday 09 August 2008 04:43:51 pm Rafael J. Wysocki wrote:
> > The following bug entry is on the current list of known regressions
> > from 2.6.26.  Please verify if it still should be listed and let me know
> > (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11276
> > Subject		: build error: CONFIG_OPTIMIZE_INLINING=y causes gcc 4.2 to do stupid things
> > Submitter	: Randy Dunlap <randy.dunlap@oracle.com>
> > Date		: 2008-08-06 17:18 (4 days old)
> > References	: http://marc.info/?l=linux-kernel&m=121804329014332&w=4
> > 		  http://lkml.org/lkml/2008/7/22/353
> > Handled-By	: Bjorn Helgaas <bjorn.helgaas@hp.com>
> > Patch		: http://lkml.org/lkml/2008/7/22/364
> 
> Since I supplied a patch, I assume I don't need to do anything more. 
> Let me know if my assumption is incorrect.

correct - assuming drivers/telephony/ is maintained. Maybe Andrew could 
mark this patch as v2.6.27-must-have - to make sure it hits upstream in 
this cycle?

	Ingo

Re: [Bug #11276] build error: CONFIG_OPTIMIZE_INLINING=y causes gcc 4.2 to do stupid things

[Rafael J. Wysocki]

On Saturday, 16 of August 2008, Bjorn Helgaas wrote:
> On Saturday 09 August 2008 04:43:51 pm Rafael J. Wysocki wrote:
> > The following bug entry is on the current list of known regressions
> > from 2.6.26.  Please verify if it still should be listed and let me know
> > (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11276
> > Subject		: build error: CONFIG_OPTIMIZE_INLINING=y causes gcc 4.2 to do stupid things
> > Submitter	: Randy Dunlap <randy.dunlap@oracle.com>
> > Date		: 2008-08-06 17:18 (4 days old)
> > References	: http://marc.info/?l=linux-kernel&m=121804329014332&w=4
> > 		  http://lkml.org/lkml/2008/7/22/353
> > Handled-By	: Bjorn Helgaas <bjorn.helgaas@hp.com>
> > Patch		: http://lkml.org/lkml/2008/7/22/364
> 
> Since I supplied a patch, I assume I don't need to do anything more.
> Let me know if my assumption is incorrect.

You don't need to do anything more, but please let me know when the patch gets
into to Linus' tree (please ignore the subsequent "should it still be listed"
messages until that happens).

Thanks,
Rafael

Re: [Bug #11276] build error: CONFIG_OPTIMIZE_INLINING=y causes gcc 4.2 to do stupid things

[Bjorn Helgaas]

On Saturday 09 August 2008 04:43:51 pm Rafael J. Wysocki wrote:
> The following bug entry is on the current list of known regressions
> from 2.6.26.  Please verify if it still should be listed and let me know
> (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11276
> Subject		: build error: CONFIG_OPTIMIZE_INLINING=y causes gcc 4.2 to do stupid things
> Submitter	: Randy Dunlap <randy.dunlap@oracle.com>
> Date		: 2008-08-06 17:18 (4 days old)
> References	: http://marc.info/?l=linux-kernel&m=121804329014332&w=4
> 		  http://lkml.org/lkml/2008/7/22/353
> Handled-By	: Bjorn Helgaas <bjorn.helgaas@hp.com>
> Patch		: http://lkml.org/lkml/2008/7/22/364

Since I supplied a patch, I assume I don't need to do anything more.
Let me know if my assumption is incorrect.

Bjorn

[Bug #11276] build error: CONFIG_OPTIMIZE_INLINING=y causes gcc 4.2 to do stupid things

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.26.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11276
Subject		: build error: CONFIG_OPTIMIZE_INLINING=y causes gcc 4.2 to do stupid things
Submitter	: Randy Dunlap <randy.dunlap@oracle.com>
Date		: 2008-08-06 17:18 (4 days old)
References	: http://marc.info/?l=linux-kernel&m=121804329014332&w=4
		  http://lkml.org/lkml/2008/7/22/353
Handled-By	: Bjorn Helgaas <bjorn.helgaas@hp.com>
Patch		: http://lkml.org/lkml/2008/7/22/364