2.6.27-rc5-git8: Reported regressions from 2.6.26

2.6.27-rc5-git8: 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-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=11512
Subject		: sort-of regression due to "kconfig: speed up all*config + randconfig"
Submitter	: Alexey Dobriyan <adobriyan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2008-09-05 22:50 (2 days old)
References	: http://marc.info/?l=linux-kernel&m=122065498013858&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11507
Subject		: usb: sometimes dead keyboard after boot
Submitter	: Frans Pop <elendil-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org>
Date		: 2008-08-26 21:03 (12 days old)
References	: http://marc.info/?l=linux-kernel&m=121977815018224&w=2


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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2008-09-04 19:14 (3 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-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Date		: 2008-09-04 7:06 (3 days old)
References	: http://marc.info/?l=linux-kernel&m=122051202202373&w=4
Handled-By	: Peter Zijlstra <a.p.zijlstra-/NLkJaSkS4VmR6Xm/wNWPw@public.gmane.org>
		  Gregory Haskins <ghaskins-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org>
		  Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11504
Subject		: reiserfs  BUG in 2.6.27-rc5
Submitter	: Randy Dunlap <randy.dunlap-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Date		: 2008-09-03 16:35 (4 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-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Date		: 2008-09-04 18:34 (3 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-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Date		: 2008-09-04 17:45 (3 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-wpePDvIxQxvMZTq/7ZfH4Q@public.gmane.org>
Date		: 2008-08-31 17:18 (7 days old)
References	: http://marc.info/?l=linux-kernel&m=122020367015025&w=4
Handled-By	: Alex Nixon <alex.nixon-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org>
		  Jeremy Fitzhardinge <jeremy-TSDbQ3PG+2Y@public.gmane.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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2008-09-01 13:33 (6 days old)
References	: http://marc.info/?l=linux-kernel&m=122028529415108&w=4
Handled-By	: Zhu Yi <yi.zhu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
		  Dan Williams <dcbw-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
		  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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2008-08-31 22:00 (7 days old)
Handled-By	: Zhang Rui <rui.zhang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>


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-H+0wwilmMs3R7s880joybQ@public.gmane.org>
Date		: 2008-08-30 18:52 (8 days old)
References	: http://marc.info/?l=linux-kernel&m=122012238925775&w=4
Handled-By	: Dave Airlie <airlied-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11463
Subject		: sshd hangs on close
Submitter	: Matthias Urlichs <matthias-+qxcz+fHsVSELgA04lAiVw@public.gmane.org>
Date		: 2008-08-30 9:18 (8 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-b7SOpcJQXxU@public.gmane.org>
Date		: 2008-08-30 03:08 (8 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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2008-08-21 17:28 (17 days old)
References	: http://marc.info/?l=linux-kernel&m=121933974928881&w=4
Handled-By	: Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org>
		  Pekka Enberg <penberg-bbCR+/B0CizivPeTLB3BmA@public.gmane.org>
		  Pavel Machek <pavel-AlSwsSmVLrQ@public.gmane.org>


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-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Date		: 2008-08-21 5:52 (17 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-VXdhtT5mjnY@public.gmane.org>
		  James Bottomley <James.Bottomley-JuX6DAaQMKPCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11403
Subject		: 2.6.27-rc2 USB suspend regression
Submitter	: Jeremy Fitzhardinge <jeremy-TSDbQ3PG+2Y@public.gmane.org>
Date		: 2008-08-20 20:48 (18 days old)
References	: http://marc.info/?l=linux-kernel&m=121926536103630&w=4
Handled-By	: Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org>


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-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org>
Date		: 2008-08-21 17:17 (17 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-X9Un+BFzKDI@public.gmane.org>
Date		: 2008-08-20 6:44 (18 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-KuiJ5kEpwI6ELgA04lAiVw@public.gmane.org>
Date		: 2008-08-16 14:17 (22 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-7UBucS1kxs3k1uMJSBkQmQ@public.gmane.org>
Date		: 2008-08-14 4:16 (24 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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2008-08-13 9:24 (25 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-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Date		: 2008-08-12 4:18 (26 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-DTz5qymZ9yRBDgjK7y7TUQ@public.gmane.org>


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-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Date		: 2008-08-11 18:36 (27 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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2008-08-05 15:12 (33 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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2008-08-05 14:58 (33 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-W8zweXLXuWQS+FvcfC7Uqw@public.gmane.org>


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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2008-08-07 04:18 (31 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-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Date		: 2008-08-02 16:03 (36 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-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Date		: 2008-08-01 18:15 (37 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-xuaVFQXs+5hIG4jRRZ66WA@public.gmane.org>
Date		: 2008-07-31 21:05 (38 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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2008-07-31 9:41 (38 days old)
References	: http://marc.info/?l=linux-kernel&m=121749737011637&w=4
Handled-By	: Peter Zijlstra <a.p.zijlstra-/NLkJaSkS4VmR6Xm/wNWPw@public.gmane.org>


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


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11209
Subject		: 2.6.27-rc1 process time accounting
Submitter	: Lukas Hejtmanek <xhejtman-8qz54MUs51PtwjQa/ONI9g@public.gmane.org>
Date		: 2008-07-31 10:43 (38 days old)
References	: http://marc.info/?l=linux-kernel&m=121750102917490&w=4
Handled-By	: Peter Zijlstra <a.p.zijlstra-/NLkJaSkS4VmR6Xm/wNWPw@public.gmane.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-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Date		: 2008-07-31 3:20 (38 days old)
References	: http://marc.info/?l=linux-kernel&m=121747464114335&w=4
Handled-By	: Zhang, Yanmin <yanmin_zhang-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
		  Peter Zijlstra <a.p.zijlstra-/NLkJaSkS4VmR6Xm/wNWPw@public.gmane.org>
		  Dhaval Giani <dhaval-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
		  Miao Xie <miaox-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>


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

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11511
Subject		: HPT374 detection crash with 74811f355f4f69a187fa74892dcf2a684b84ce99
Submitter	: Masoud Sharbiani <masouds-VSK0CvVmMoVQFI55V6+gNQ@public.gmane.org>
Date		: 2008-09-04 23:11 (3 days old)
References	: http://marc.info/?l=linux-kernel&m=122056994113818&w=4
Handled-By	: Masoud Sharbiani <masouds-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Patch		: http://marc.info/?l=linux-kernel&m=122072163527041&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11442
Subject		: btusb hibernation/suspend breakage in current -git
Submitter	: Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org>
Date		: 2008-08-25 11:37 (13 days old)
References	: http://marc.info/?l=linux-bluetooth&m=121966402012074&w=4
Handled-By	: Oliver Neukum <oliver-GvhC2dPhHPQdnm+yROfE0A@public.gmane.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-Bf/eaXMDFuuXqB7oj33eUg@public.gmane.org>
Date		: 2008-08-26 9:37 (12 days old)
References	: http://marc.info/?l=linux-kernel&m=121974353815440&w=4
Handled-By	: Greg KH <gregkh-l3A5Bk7waGM@public.gmane.org>
Patch		: http://marc.info/?l=linux-kernel&m=121976424221858&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11418
Subject		: Many soft lockups
Submitter	: Gu Rui <chaos.proton-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2008-08-24 13:06 (14 days old)
Handled-By	: Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
Patch		: http://bugzilla.kernel.org/attachment.cgi?id=17622&action=view


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-kQvG35nSl+M@public.gmane.org>
Date		: 2008-08-08 10:47 (30 days old)
References	: http://marc.info/?l=linux-kernel&m=121819267211679&w=4
Handled-By	: Christopher Li <chrisl-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2008-08-17 3:30 (21 days old)
References	: http://marc.info/?l=linux-kernel&m=121894389018584&w=4
Handled-By	: Yinghai Lu <yhlu.kernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
Date		: 2008-08-12 12:37 (26 days old)
References	: http://marc.info/?l=linux-kernel&m=121854484015909&w=4
Handled-By	: Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
Patch		: http://bugzilla.kernel.org/attachment.cgi?id=17622


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11334
Subject		: myri10ge: use ioremap_wc: compilation failure on ARM
Submitter	: Martin Michlmayr <tbm-R+vWnYXSFMfQT0dZR+AlfA@public.gmane.org>
Date		: 2008-08-10 11:25 (28 days old)
References	: http://marc.info/?l=linux-netdev&m=121836771727632&w=2
Handled-By	: Lennert Buytenhek <buytenh-OLH4Qvv75CYX/NnBR394Jw@public.gmane.org>
Patch		: http://bugzilla.kernel.org/show_bug.cgi?id=11334#c13


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-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
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-VXdhtT5mjnY@public.gmane.org>
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-cCz0Lq7MMjm9FHfhHBbuYA@public.gmane.org>
Date		: 2008-08-02 9:51 (36 days old)
References	: http://marc.info/?l=linux-kernel&m=121767073424952&w=4
Handled-By	: Hugh Dickins <hugh-DTz5qymZ9yRBDgjK7y7TUQ@public.gmane.org>
		  Jeremy Fitzhardinge <jeremy-TSDbQ3PG+2Y@public.gmane.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-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Date		: 2008-07-31 3:20 (38 days old)
References	: http://marc.info/?l=linux-kernel&m=121747464114335&w=4
Handled-By	: Zhang, Yanmin <yanmin_zhang-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
		  Peter Zijlstra <a.p.zijlstra-/NLkJaSkS4VmR6Xm/wNWPw@public.gmane.org>
		  Dhaval Giani <dhaval-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
		  Miao Xie <miaox-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>

[Bug #11209] 2.6.27-rc1 process time accounting

[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=11209
Subject		: 2.6.27-rc1 process time accounting
Submitter	: Lukas Hejtmanek <xhejtman-8qz54MUs51PtwjQa/ONI9g@public.gmane.org>
Date		: 2008-07-31 10:43 (38 days old)
References	: http://marc.info/?l=linux-kernel&m=121750102917490&w=4
Handled-By	: Peter Zijlstra <a.p.zijlstra-/NLkJaSkS4VmR6Xm/wNWPw@public.gmane.org>

[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-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
Date		: 2008-07-31 18:53 (38 days old)
References	: http://marc.info/?l=linux-ide&m=121753059307310&w=4
Handled-By	: Kumar Gala <galak-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>

[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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2008-07-31 9:41 (38 days old)
References	: http://marc.info/?l=linux-kernel&m=121749737011637&w=4
Handled-By	: Peter Zijlstra <a.p.zijlstra-/NLkJaSkS4VmR6Xm/wNWPw@public.gmane.org>

[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-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Date		: 2008-08-01 18:15 (37 days old)
References	: http://marc.info/?l=linux-kernel&m=121761475224719&w=4

[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-xuaVFQXs+5hIG4jRRZ66WA@public.gmane.org>
Date		: 2008-07-31 21:05 (38 days old)
References	: http://marc.info/?l=linux-kernel&m=121753882422899&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-cCz0Lq7MMjm9FHfhHBbuYA@public.gmane.org>
Date		: 2008-08-02 9:51 (36 days old)
References	: http://marc.info/?l=linux-kernel&m=121767073424952&w=4
Handled-By	: Hugh Dickins <hugh-DTz5qymZ9yRBDgjK7y7TUQ@public.gmane.org>
		  Jeremy Fitzhardinge <jeremy-TSDbQ3PG+2Y@public.gmane.org>
Patch		: http://marc.info/?l=linux-kernel&m=122001615314700&w=2

[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-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Date		: 2008-08-02 16:03 (36 days old)
References	: http://marc.info/?l=linux-kernel&m=121769306319391&w=4

[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-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
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-VXdhtT5mjnY@public.gmane.org>
Patch		: http://lkml.org/lkml/2008/7/22/364

[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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2008-08-07 04:18 (31 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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2008-08-05 14:58 (33 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-W8zweXLXuWQS+FvcfC7Uqw@public.gmane.org>

[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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2008-08-05 15:12 (33 days old)
References	: http://marc.info/?l=linux-kernel&m=121794900319776&w=4

[Bug #11334] myri10ge: use ioremap_wc: compilation failure on ARM

[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=11334
Subject		: myri10ge: use ioremap_wc: compilation failure on ARM
Submitter	: Martin Michlmayr <tbm-R+vWnYXSFMfQT0dZR+AlfA@public.gmane.org>
Date		: 2008-08-10 11:25 (28 days old)
References	: http://marc.info/?l=linux-netdev&m=121836771727632&w=2
Handled-By	: Lennert Buytenhek <buytenh-OLH4Qvv75CYX/NnBR394Jw@public.gmane.org>
Patch		: http://bugzilla.kernel.org/show_bug.cgi?id=11334#c13

[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-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Date		: 2008-08-11 18:36 (27 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-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Date		: 2008-08-12 4:18 (26 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-DTz5qymZ9yRBDgjK7y7TUQ@public.gmane.org>

[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-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
Date		: 2008-08-12 12:37 (26 days old)
References	: http://marc.info/?l=linux-kernel&m=121854484015909&w=4
Handled-By	: Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2008-08-13 9:24 (25 days old)
References	: http://marc.info/?l=linux-kernel&m=121861951902949&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-KuiJ5kEpwI6ELgA04lAiVw@public.gmane.org>
Date		: 2008-08-16 14:17 (22 days old)

[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-7UBucS1kxs3k1uMJSBkQmQ@public.gmane.org>
Date		: 2008-08-14 4:16 (24 days old)
References	: http://marc.info/?l=linux-kernel&m=121868782917600&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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2008-08-17 3:30 (21 days old)
References	: http://marc.info/?l=linux-kernel&m=121894389018584&w=4
Handled-By	: Yinghai Lu <yhlu.kernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Patch		: http://marc.info/?l=linux-kernel&m=121894389018584&w=4

[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-kQvG35nSl+M@public.gmane.org>
Date		: 2008-08-08 10:47 (30 days old)
References	: http://marc.info/?l=linux-kernel&m=121819267211679&w=4
Handled-By	: Christopher Li <chrisl-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
Patch		: http://marc.info/?l=linux-mm-commits&m=122038324200305&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-X9Un+BFzKDI@public.gmane.org>
Date		: 2008-08-20 6:44 (18 days old)
References	: http://marc.info/?l=linux-kernel&m=121921480931970&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-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org>
Date		: 2008-08-21 17:17 (17 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-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Date		: 2008-08-21 5:52 (17 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-VXdhtT5mjnY@public.gmane.org>
		  James Bottomley <James.Bottomley-JuX6DAaQMKPCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>

[Bug #11403] 2.6.27-rc2 USB suspend 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=11403
Subject		: 2.6.27-rc2 USB suspend regression
Submitter	: Jeremy Fitzhardinge <jeremy-TSDbQ3PG+2Y@public.gmane.org>
Date		: 2008-08-20 20:48 (18 days old)
References	: http://marc.info/?l=linux-kernel&m=121926536103630&w=4
Handled-By	: Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org>

[Bug #11418] Many soft lockups

[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=11418
Subject		: Many soft lockups
Submitter	: Gu Rui <chaos.proton-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2008-08-24 13:06 (14 days old)
Handled-By	: Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
Patch		: http://bugzilla.kernel.org/attachment.cgi?id=17622&action=view

[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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2008-08-21 17:28 (17 days old)
References	: http://marc.info/?l=linux-kernel&m=121933974928881&w=4
Handled-By	: Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org>
		  Pekka Enberg <penberg-bbCR+/B0CizivPeTLB3BmA@public.gmane.org>
		  Pavel Machek <pavel-AlSwsSmVLrQ@public.gmane.org>

[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-Bf/eaXMDFuuXqB7oj33eUg@public.gmane.org>
Date		: 2008-08-26 9:37 (12 days old)
References	: http://marc.info/?l=linux-kernel&m=121974353815440&w=4
Handled-By	: Greg KH <gregkh-l3A5Bk7waGM@public.gmane.org>
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-KKrjLPT3xs0@public.gmane.org>
Date		: 2008-08-25 11:37 (13 days old)
References	: http://marc.info/?l=linux-bluetooth&m=121966402012074&w=4
Handled-By	: Oliver Neukum <oliver-GvhC2dPhHPQdnm+yROfE0A@public.gmane.org>
Patch		: http://marc.info/?l=linux-bluetooth&m=121967226027323&w=4

[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-+qxcz+fHsVSELgA04lAiVw@public.gmane.org>
Date		: 2008-08-30 9:18 (8 days old)
References	: http://marc.info/?l=linux-kernel&m=122008800512864&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-b7SOpcJQXxU@public.gmane.org>
Date		: 2008-08-30 03:08 (8 days old)

[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-H+0wwilmMs3R7s880joybQ@public.gmane.org>
Date		: 2008-08-30 18:52 (8 days old)
References	: http://marc.info/?l=linux-kernel&m=122012238925775&w=4
Handled-By	: Dave Airlie <airlied-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

[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-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Date		: 2008-09-04 17:45 (3 days old)
References	: http://marc.info/?l=linux-kernel&m=122055041313270&w=4

[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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2008-08-31 22:00 (7 days old)
Handled-By	: Zhang Rui <rui.zhang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>

[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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2008-09-01 13:33 (6 days old)
References	: http://marc.info/?l=linux-kernel&m=122028529415108&w=4
Handled-By	: Zhu Yi <yi.zhu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
		  Dan Williams <dcbw-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
		  Jouni Malinen <j@w1.fi>

[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-wpePDvIxQxvMZTq/7ZfH4Q@public.gmane.org>
Date		: 2008-08-31 17:18 (7 days old)
References	: http://marc.info/?l=linux-kernel&m=122020367015025&w=4
Handled-By	: Alex Nixon <alex.nixon-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org>
		  Jeremy Fitzhardinge <jeremy-TSDbQ3PG+2Y@public.gmane.org>

[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-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Date		: 2008-09-04 7:06 (3 days old)
References	: http://marc.info/?l=linux-kernel&m=122051202202373&w=4
Handled-By	: Peter Zijlstra <a.p.zijlstra-/NLkJaSkS4VmR6Xm/wNWPw@public.gmane.org>
		  Gregory Haskins <ghaskins-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org>
		  Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.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-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Date		: 2008-09-04 18:34 (3 days old)
References	: http://marc.info/?l=linux-kernel&m=122055342419068&w=4

[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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2008-09-04 19:14 (3 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-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org>
Date		: 2008-08-26 21:03 (12 days old)
References	: http://marc.info/?l=linux-kernel&m=121977815018224&w=2

[Bug #11511] HPT374 detection crash with 74811f355f4f69a187fa74892dcf2a684b84ce99

[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=11511
Subject		: HPT374 detection crash with 74811f355f4f69a187fa74892dcf2a684b84ce99
Submitter	: Masoud Sharbiani <masouds-VSK0CvVmMoVQFI55V6+gNQ@public.gmane.org>
Date		: 2008-09-04 23:11 (3 days old)
References	: http://marc.info/?l=linux-kernel&m=122056994113818&w=4
Handled-By	: Masoud Sharbiani <masouds-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Patch		: http://marc.info/?l=linux-kernel&m=122072163527041&w=4

[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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2008-09-05 22:50 (2 days old)
References	: http://marc.info/?l=linux-kernel&m=122065498013858&w=4

Re: [Bug #11209] 2.6.27-rc1 process time accounting

[Peter Zijlstra]

On Sat, 2008-09-06 at 23:30 +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).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11209
> Subject		: 2.6.27-rc1 process time accounting
> Submitter	: Lukas Hejtmanek <xhejtman-8qz54MUs51PtwjQa/ONI9g@public.gmane.org>
> Date		: 2008-07-31 10:43 (38 days old)
> References	: http://marc.info/?l=linux-kernel&m=121750102917490&w=4
> Handled-By	: Peter Zijlstra <a.p.zijlstra-/NLkJaSkS4VmR6Xm/wNWPw@public.gmane.org>

Should be fixed in the latest -git

Re: [Bug #11334] myri10ge: use ioremap_wc: compilation failure on ARM

[Lennert Buytenhek]

On Sat, Sep 06, 2008 at 11:30:38PM +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).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11334
> Subject		: myri10ge: use ioremap_wc: compilation failure on ARM
> Submitter	: Martin Michlmayr <tbm-R+vWnYXSFMfQT0dZR+AlfA@public.gmane.org>
> Date		: 2008-08-10 11:25 (28 days old)
> References	: http://marc.info/?l=linux-netdev&m=121836771727632&w=2
> Handled-By	: Lennert Buytenhek <buytenh-OLH4Qvv75CYX/NnBR394Jw@public.gmane.org>
> Patch		: http://bugzilla.kernel.org/show_bug.cgi?id=11334#c13

Still relevant.  A patch to fix this has been submitted and should be in
the ARM tree, but it has not made its way upstream yet, and the original
submitter has not confirmed that it fixes the problem yet.

Re: [Bug #11209] 2.6.27-rc1 process time accounting

[Rafael J. Wysocki]

On Sunday, 7 of September 2008, Peter Zijlstra wrote:
> On Sat, 2008-09-06 at 23:30 +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).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11209
> > Subject		: 2.6.27-rc1 process time accounting
> > Submitter	: Lukas Hejtmanek <xhejtman-8qz54MUs51PtwjQa/ONI9g@public.gmane.org>
> > Date		: 2008-07-31 10:43 (38 days old)
> > References	: http://marc.info/?l=linux-kernel&m=121750102917490&w=4
> > Handled-By	: Peter Zijlstra <a.p.zijlstra-/NLkJaSkS4VmR6Xm/wNWPw@public.gmane.org>
> 
> Should be fixed in the latest -git

Thanks for the update.

Does any specific commit fix it or just a series of recent commits?

Rafael

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

[Greg KH]

On Sat, Sep 06, 2008 at 11:30:42PM +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).
> 
> 
> 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-Bf/eaXMDFuuXqB7oj33eUg@public.gmane.org>
> Date		: 2008-08-26 9:37 (12 days old)
> References	: http://marc.info/?l=linux-kernel&m=121974353815440&w=4
> Handled-By	: Greg KH <gregkh-l3A5Bk7waGM@public.gmane.org>
> Patch		: http://marc.info/?l=linux-kernel&m=121976424221858&w=4

Jesse, have you queued up this patch to send to Linus for 2.6.27?

thanks,

greg k-h

Re: [Bug #11209] 2.6.27-rc1 process time accounting

[Peter Zijlstra]

On Mon, 2008-09-08 at 00:02 +0200, Rafael J. Wysocki wrote:
> On Sunday, 7 of September 2008, Peter Zijlstra wrote:
> > On Sat, 2008-09-06 at 23:30 +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).
> > > 
> > > 
> > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11209
> > > Subject		: 2.6.27-rc1 process time accounting
> > > Submitter	: Lukas Hejtmanek <xhejtman-8qz54MUs51PtwjQa/ONI9g@public.gmane.org>
> > > Date		: 2008-07-31 10:43 (38 days old)
> > > References	: http://marc.info/?l=linux-kernel&m=121750102917490&w=4
> > > Handled-By	: Peter Zijlstra <a.p.zijlstra-/NLkJaSkS4VmR6Xm/wNWPw@public.gmane.org>
> > 
> > Should be fixed in the latest -git
> 
> Thanks for the update.
> 
> Does any specific commit fix it or just a series of recent commits?

commit 49048622eae698e5c4ae61f7e71200f265ccc529
Author: Balbir Singh <balbir-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Date:   Fri Sep 5 18:12:23 2008 +0200

    sched: fix process time monotonicity

    Spencer reported a problem where utime and stime were going negative despite
    the fixes in commit b27f03d4bdc145a09fb7b0c0e004b29f1ee555fa. The suspected
    reason for the problem is that signal_struct maintains it's own utime and
    stime (of exited tasks), these are not updated using the new task_utime()
    routine, hence sig->utime can go backwards and cause the same problem
    to occur (sig->utime, adds tsk->utime and not task_utime()). This patch
    fixes the problem

commit 56c7426b3951e4f35a71d695f1c982989399d6fd
Author: Peter Zijlstra <a.p.zijlstra-/NLkJaSkS4VmR6Xm/wNWPw@public.gmane.org>
Date:   Mon Sep 1 16:44:23 2008 +0200

    sched_clock: fix NOHZ interaction

    If HLT stops the TSC, we'll fail to account idle time, thereby inflating the
    actual process times. Fix this by re-calibrating the clock against GTOD when
    leaving nohz mode.

Re: [Bug #11334] myri10ge: use ioremap_wc: compilation failure on ARM

[Martin Michlmayr]

* Lennert Buytenhek <buytenh-OLH4Qvv75CYX/NnBR394Jw@public.gmane.org> [2008-09-07 17:59]:
> Still relevant.  A patch to fix this has been submitted and should be in
> the ARM tree, but it has not made its way upstream yet, and the original
> submitter has not confirmed that it fixes the problem yet.

Your patch fixes the compilation error I reported, thanks.
-- 
Martin Michlmayr
http://www.cyrius.com/

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

[Jesse Barnes]

On Sunday, September 07, 2008 9:44 pm Greg KH wrote:
> On Sat, Sep 06, 2008 at 11:30:42PM +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).
> >
> >
> > 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 (12 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
>
> Jesse, have you queued up this patch to send to Linus for 2.6.27?

Not yet; I'll include it in my next pull request though.

Thanks,
Jesse

Re: [Bug #11334] myri10ge: use ioremap_wc: compilation failure on ARM

[Lennert Buytenhek]

On Sat, Sep 06, 2008 at 11:30:38PM +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).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11334
> Subject		: myri10ge: use ioremap_wc: compilation failure on ARM
> Submitter	: Martin Michlmayr <tbm-R+vWnYXSFMfQT0dZR+AlfA@public.gmane.org>
> Date		: 2008-08-10 11:25 (28 days old)
> References	: http://marc.info/?l=linux-netdev&m=121836771727632&w=2
> Handled-By	: Lennert Buytenhek <buytenh-OLH4Qvv75CYX/NnBR394Jw@public.gmane.org>
> Patch		: http://bugzilla.kernel.org/show_bug.cgi?id=11334#c13

The patch to fix this is upstream now (in -rc6), as commit
1ad77a876da48331451698cc4172c90ab9b6372f.

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

[Frans Pop]

On Saturday 06 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=11507
> Subject	: usb: sometimes dead keyboard after boot
> Submitter	: Frans Pop <elendil-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org>
> Date		: 2008-08-26 21:03 (12 days old)
> References	: http://marc.info/?l=linux-kernel&m=121977815018224&w=2

Still there. Alan Stern has provided a patch for the issue:
http://www.spinics.net/lists/linux-usb/msg09735.html

I've just reported back the test results:
http://www.spinics.net/lists/linux-usb/msg09926.html

[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-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Date		: 2008-09-04 17:45 (9 days old)
References	: http://marc.info/?l=linux-kernel&m=122055041313270&w=4

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-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.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-gx6/JNMH7DfYtjvyW6yDsg@public.gmane.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-gx6/JNMH7DfYtjvyW6yDsg@public.gmane.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-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.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 #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-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.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-gx6/JNMH7DfYtjvyW6yDsg@public.gmane.org>

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

[Andrew Morton]

On Sat, 13 Sep 2008 10:15:43 +1000 (EST) James Morris <jmorris-gx6/JNMH7DfYtjvyW6yDsg@public.gmane.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-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.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 #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-gx6/JNMH7DfYtjvyW6yDsg@public.gmane.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-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.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 #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-gx6/JNMH7DfYtjvyW6yDsg@public.gmane.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-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.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-gx6/JNMH7DfYtjvyW6yDsg@public.gmane.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-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.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 #11500] /proc/net bug related to selinux

[Andrew Morton]

On Mon, 15 Sep 2008 09:05:26 -0400
Stephen Smalley <sds-+05T5uksL2qpZYMLLGbcSA@public.gmane.org> 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-gx6/JNMH7DfYtjvyW6yDsg@public.gmane.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-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.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-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> writes:

> On Mon, 15 Sep 2008 09:05:26 -0400
> Stephen Smalley <sds-+05T5uksL2qpZYMLLGbcSA@public.gmane.org> 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-GEFAQzZX7r8dnm+yROfE0A@public.gmane.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-+05T5uksL2qpZYMLLGbcSA@public.gmane.org>
>     
>     Changes from v1:
>     * Fixed a task_struct leak in get_proc_task_net, pointed out by Paul.
>     
>     Signed-off-by: Pavel Emelyanov <xemul-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
>     Acked-by: "Eric W. Biederman" <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
>     Signed-off-by: David S. Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>

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

[Andrew Morton]

On Wed, 17 Sep 2008 14:39:45 -0700
ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman) wrote:

> Paul Moore <paul.moore-VXdhtT5mjnY@public.gmane.org> 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-+05T5uksL2qpZYMLLGbcSA@public.gmane.org> 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-VXdhtT5mjnY@public.gmane.org>
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-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.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-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> writes:

> On Wed, 17 Sep 2008 18:12:59 -0400
> Paul Moore <paul.moore-VXdhtT5mjnY@public.gmane.org> 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 #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 #11500] /proc/net bug related to selinux

[david-gFPdbfVZQbY]

On Thu, 18 Sep 2008, Stephen Smalley wrote:

> On Thu, 2008-09-18 at 11:09 -0700, Eric W. Biederman wrote:
>> Stephen Smalley <sds-+05T5uksL2qpZYMLLGbcSA@public.gmane.org> 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-+05T5uksL2qpZYMLLGbcSA@public.gmane.org> 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