login
Search
This message contains a list of some regressions from 2.6.26, for which there are no fixes in the mainline I know of. If any of them have been fixed already, please let me know. If you know of any other unresolved regressions from 2.6.26, please let me know either and I'll add them to the list. Also, please let me know if any of the entries below are invalid. Each entry from the list will be sent additionally in an automatic reply to this message with CCs to the people involved in reporting and handling the issue. Listed regressions statistics: Date Total Pending Unresolved ---------------------------------------- 2008-09-12 163 51 38 2008-09-07 150 43 33 2008-08-30 135 48 36 2008-08-23 122 48 40 2008-08-16 103 47 37 2008-08-10 80 52 31 2008-08-02 47 31 20 Unresolved regressions ---------------------- Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11559 Subject : 2.6.27-rc6: nohz + s2ram = need to press keys to get progress Submitter : Pavel Machek <pavel@suse.cz> Date : 2008-09-12 8:31 (1 days old) References : http://marc.info/?l=linux-kernel&m=122121384705262&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11557 Subject : Controlling backlight on thinkpad x60 Submitter : Pavel Machek <pavel@suse.cz> Date : 2008-09-08 15:10 (5 days old) References : http://marc.info/?l=linux-kernel&m=122088987319698&w=4 Handled-By : Matthew Garrett <mjg59@srcf.ucam.org> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11554 Subject : Partition check considered as error is breaking mounting in 2.6.27 Submitter : Herton Ronaldo Krzesinski <herton@mandriva.com.br> Date : 2008-09-12 16:56 (1 days old) References : http://marc.info/?l=linux-kernel&m=122123862519434&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11553 Subject : Strange looking line ...
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11207 Subject : VolanoMark regression with 2.6.27-rc1 Submitter : Zhang, Yanmin <yanmin_zhang@linux.intel.com> Date : 2008-07-31 3:20 (44 days old) References : http://marc.info/?l=linux-kernel&m=121747464114335&w=4 Handled-By : Zhang, Yanmin <yanmin_zhang@linux.intel.com> Peter Zijlstra <a.p.zijlstra@chello.nl> Dhaval Giani <dhaval@linux.vnet.ibm.com> Miao Xie <miaox@cn.fujitsu.com> --
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11224 Subject : Only three cores found on quad-core machine. Submitter : Dave Jones <davej@redhat.com> Date : 2008-08-01 18:15 (43 days old) References : http://marc.info/?l=linux-kernel&m=121761475224719&w=4 --
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11210 Subject : libata badness Submitter : Kumar Gala <galak@kernel.crashing.org> Date : 2008-07-31 18:53 (44 days old) References : http://marc.info/?l=linux-ide&m=121753059307310&w=4 Handled-By : Kumar Gala <galak@kernel.crashing.org> --
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11220 Subject : Screen stays black after resume Submitter : Nico Schottelius <nico@schottelius.org> Date : 2008-07-31 21:05 (44 days old) References : http://marc.info/?l=linux-kernel&m=121753882422899&w=4 --
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11215 Subject : INFO: possible recursive locking detected ps2_command Submitter : Zdenek Kabelac <zdenek.kabelac@gmail.com> Date : 2008-07-31 9:41 (44 days old) References : http://marc.info/?l=linux-kernel&m=121749737011637&w=4 Handled-By : Peter Zijlstra <a.p.zijlstra@chello.nl> --
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11230 Subject : Kconfig no longer outputs a .config with freshly updated defconfigs Submitter : Josh Boyer <jwboyer@linux.vnet.ibm.com> Date : 2008-08-02 16:03 (42 days old) References : http://marc.info/?l=linux-kernel&m=121769306319391&w=4 --
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11237 Subject : corrupt PMD after resume Submitter : Alan Jenkins <alan-jenkins@tuffmail.co.uk> Date : 2008-08-02 9:51 (42 days old) References : http://marc.info/?l=linux-kernel&m=121767073424952&w=4 Handled-By : Hugh Dickins <hugh@veritas.com> Jeremy Fitzhardinge <jeremy@goop.org> Patch : http://marc.info/?l=linux-kernel&m=122001615314700&w=2 --
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11264 Subject : Invalid op opcode in kernel/workqueue Submitter : Jean-Luc Coulon <jean.luc.coulon@gmail.com> Date : 2008-08-07 04:18 (37 days old) --
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11271 Subject : BUG: fealnx in 2.6.27-rc1 Submitter : Jaswinder Singh <jaswinderlinux@gmail.com> Date : 2008-08-05 14:58 (39 days old) References : http://marc.info/?l=linux-netdev&m=121794762016830&w=4 http://lkml.org/lkml/2008/8/10/98 Handled-By : Francois Romieu <romieu@fr.zoreil.com> --
Hello all,
I am sorry for delay.
Now I am testing for same problem with 2.6.27-rc6.:
1. On different MYSON Technology Inc SURECOM EP-320X-S 100/10M
Ethernet PCI Adapters
2. On different Linux PCs
3. With different Ethernet switches which supports 100 Mb
4. With different CAT 5 ethernet cables which supports 100 Mb
5. Also checking old patches on fealnx as per Jeff.
And it seems, I am getting following error, with few ethernet switches
and cables and when I switch ethernet cables :
"NETDEV WATCHDOG: eth0 (fealnx): transmit timed out
eth0: Transmit timed out, status 00000000, resetting..."
Now I am trying to confirm that problem is coming from ethernet
switches and cables.
I am also facing one more Issue :
With same 100 Mb ethernet switch and cable my another NIC run at 100
Mb/s and full duplex but MYSON Technology Inc SURECOM EP-320X-S
100/10M runs on 10 Mb/s and half duplex.
I debug fealnx it says : PHYType 1 duplex_mode : 2 line_speed : 2
crvalue : 0xe40e61 bcrvalue : 0x10 imrvalue : 0x46c flags : 0x1
So it is saying duplex_mode : 2 (full duplex) and line_speed = 2
(100M) then why I am getting 10MB half duplex ?
#lspci -vv
02:02.0 Ethernet controller: MYSON Technology Inc SURECOM EP-320X-S
100/10M Ethernet PCI Adapter
Subsystem: MYSON Technology Inc SURECOM EP-320X-S 100/10M
Ethernet PCI Adapter
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
Latency: 32 (8000ns min, 16000ns max), Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 17
Region 0: I/O ports at b800 [size=256]
Region 1: Memory at ff9ffc00 (32-bit, non-prefetchable) [size=1K]
Expansion ROM at 50000000 [disabled] [size=64K]
Capabilities: [88] Power Management version 2
Flags: PMEClk- DSI- D1+ D2- AuxCurrent=375mA
PME(D0-,D1+,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: ...This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11276 Subject : build error: CONFIG_OPTIMIZE_INLINING=y causes gcc 4.2 to do stupid things Submitter : Randy Dunlap <randy.dunlap@oracle.com> Date : 2008-08-06 17:18 (38 days old) References : http://marc.info/?l=linux-kernel&m=121804329014332&w=4 http://lkml.org/lkml/2008/7/22/353 Handled-By : Bjorn Helgaas <bjorn.helgaas@hp.com> Patch : http://lkml.org/lkml/2008/7/22/364 --
Yes, I still see this build error. What would it take to have Bjorn's patch merged into mainline? -- ~Randy Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA http://linuxplumbersconf.org/ --
Well, send a request to Andrew I think (with the patch appended). Thanks, Rafael --
Thanks for pointing out the fix that should have been obvious, Dave. That's a much better solution than sprinkling #ifdef CONFIG_PNP through drivers. Rafael, in case you missed the checkin, it's commit ef3d7714f6b75b51825ad0384b5ce48358427e50 Bjorn --
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11272 Subject : BUG: parport_serial in 2.6.27-rc1 for NetMos Technology PCI 9835 Submitter : Jaswinder Singh <jaswinderlinux@gmail.com> Date : 2008-08-05 15:12 (39 days old) References : http://marc.info/?l=linux-kernel&m=121794900319776&w=4 --
Hello all, I am sorry for delay. I have tested parport_pc and also tried with pcmcia_cs, only thing I get is disappointment. So I give up :-( Now I switched to usbserial. usbserial drivers are working great !! Now I do not want to use parport_pc and pcmcia_cs atleast for 2 years, I hope in 2 years this will be solved ;) In the mean time, If you think my problem is solved just ping to me I will test and let you know the results. Thank you for all your support and help. Jaswinder Singh. --
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 -&gt; 2.6.28 Submitter : Christoph Lameter <cl@linux-foundation.org> Date : 2008-08-11 18:36 (33 days old) References : http://marc.info/?l=linux-kernel&m=121847986119495&w=4 --
tbench 2.6.27-rc6 2760 MB/sec 2.6.22 3235.47 MB/sec diff on the .config files for each (took .22 config and did a make oldconfig) --- /boot/config-2.6.22.1-4U4JUMP1.12 2008-01-22 08:06:38.000000000 -0600 +++ .config 2008-09-12 16:33:52.000000000 -0500 @@ -1,55 +1,89 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.22.1-4U4JUMP1.12 -# Mon Jan 21 16:05:52 2008 +# Linux kernel version: 2.6.27-rc6 +# Fri Sep 12 16:33:52 2008 # +# CONFIG_64BIT is not set CONFIG_X86_32=y +# CONFIG_X86_64 is not set +CONFIG_X86=y +CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig" +# CONFIG_GENERIC_LOCKBREAK is not set CONFIG_GENERIC_TIME=y +CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y -CONFIG_SEMAPHORE_SLEEPERS=y -CONFIG_X86=y +CONFIG_HAVE_LATENCYTOP_SUPPORT=y +CONFIG_FAST_CMPXCHG_LOCAL=y CONFIG_MMU=y CONFIG_ZONE_DMA=y -CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y +# CONFIG_GENERIC_GPIO is not set CONFIG_ARCH_MAY_HAVE_PC_FDC=y -CONFIG_DMI=y +# CONFIG_RWSEM_GENERIC_SPINLOCK is not set +CONFIG_RWSEM_XCHGADD_ALGORITHM=y +# CONFIG_ARCH_HAS_ILOG2_U32 is not set +# CONFIG_ARCH_HAS_ILOG2_U64 is not set +CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y +CONFIG_GENERIC_CALIBRATE_DELAY=y +# CONFIG_GENERIC_TIME_VSYSCALL is not set +CONFIG_ARCH_HAS_CPU_RELAX=y +CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y +CONFIG_HAVE_SETUP_PER_CPU_AREA=y +# CONFIG_HAVE_CPUMASK_OF_CPU_MAP is not set +CONFIG_ARCH_HIBERNATION_POSSIBLE=y +CONFIG_ARCH_SUSPEND_POSSIBLE=y +# CONFIG_ZONE_DMA32 is not set +CONFIG_ARCH_POPULATES_NODE_MAP=y +# CONFIG_AUDIT_ARCH is not ...
Numbers from my Q6600 Aldi supermarket box (hm, your box is from different shelf) tbench -t 60 4 localhost followed by 4 60s netperf TCP_RR pairs, each pair jabbering on a separate port and affine to a separate CPU. Configs are as close as I can make them, all kernels built and tested today by identical userland. 2.6.22.19 Throughput 1136.02 MB/sec 4 procs 16384 87380 1 1 60.01 94179.12 16384 87380 1 1 60.01 88780.61 16384 87380 1 1 60.01 91057.72 16384 87380 1 1 60.01 94242.16 2.6.22.19-cfs-v24.1 (identical config) Throughput 1126.79 MB/sec 4 procs 16384 87380 1 1 60.00 88809.14 16384 87380 1 1 60.00 89971.25 16384 87380 1 1 60.01 89452.91 16384 87380 1 1 60.01 89478.63 2.6.23.17 Throughput 1073.2 MB/sec 4 procs 16384 87380 1 1 60.00 83635.61 16384 87380 1 1 60.00 82754.36 16384 87380 1 1 60.00 84594.59 16384 87380 1 1 60.00 82995.81 2.6.23.17-cfs-v24.1 (identical config) Throughput 1145.28 MB/sec 4 procs 16384 87380 1 1 60.00 90278.55 16384 87380 1 1 60.01 90579.31 16384 87380 1 1 60.01 89412.14 16384 87380 1 1 60.00 90270.97 2.6.24.7 Throughput 1119.28 MB/sec 4 procs 16384 87380 1 1 60.00 84092.78 16384 87380 1 1 60.00 84120.68 16384 87380 1 1 60.00 84076.73 16384 87380 1 1 60.00 83995.07 2.6.25.17 Throughput 1113.82 MB/sec 4 procs 16384 87380 1 1 60.00 84629.98 16384 87380 1 1 60.00 84776.38 16384 87380 1 1 60.00 84356.49 16384 87380 1 1 60.00 84469.71 2.6.26.5 Throughput 1095.26 MB/sec 4 procs 16384 87380 1 1 60.00 84481.11 16384 87380 1 1 60.00 84604.38 16384 87380 ...
P.S. fwiw, scheduler difference between these two kernels is practically nill. --
<snip... sigh> goes back to current real .27 config Throughput 1022.52 MB/sec 4 procs 16384 87380 1 1 60.00 75941.95 16384 87380 1 1 60.01 76002.46 16384 87380 1 1 60.01 76367.55 16384 87380 1 1 60.00 76188.66 ... demodularizes seriously over-configured network Throughput 750.175 MB/sec 4 procs 16384 87380 1 1 60.00 49270.35 16384 87380 1 1 60.01 49233.86 16384 87380 1 1 60.00 49265.72 16384 87380 1 1 60.00 49227.00 Very un-good thing to try. Stupid thing too? -Mike --
Apparently stupid for netfilter. Uninteresting to this thread I suppose, so disregard. -Mike --
My box is an 8p with recent quad core processors. 8G, 32bit Linux. --
Don't hold your breath, but after putting my network config of a very severe diet, I'm starting to see something resembling sensible results. -Mike --
Turns off all netfilter options except tables, etc. Since 2.6.22.19-cfs-v24.1 and 2.6.23.17-cfs-v24.1 schedulers are identical, and these are essentially identical with 2.6.24.7, what I read from numbers below is that cfs in 2.6.23 was somewhat less than wonderful for either netperf or tbench, Something happened somewhere other than the scheduler at 23->24 which cost us some performance, and another something happened at 26->27. I'll likely go looking again.. and likely regret it again ;-) Math ain't free is part of it, though apparently not much. For me, tbench regression 22->27 is ~10%, and netperf regression is ~16%. Data: 2.6.22.19 Throughput 1250.73 MB/sec 4 procs 1.00 16384 87380 1 1 60.01 111272.55 1.00 16384 87380 1 1 60.00 104689.58 16384 87380 1 1 60.00 110733.05 16384 87380 1 1 60.00 110748.88 2.6.22.19-cfs-v24.1 Throughput 1204.14 MB/sec 4 procs .962 16384 87380 1 1 60.01 101799.85 .929 16384 87380 1 1 60.01 101659.41 16384 87380 1 1 60.01 101628.78 16384 87380 1 1 60.01 101700.53 wakeup granularity = 0 (make scheduler as preempt happy as 2.6.22 is) Throughput 1213.21 MB/sec 4 procs .970 16384 87380 1 1 60.01 108569.27 .992 16384 87380 1 1 60.01 108541.04 16384 87380 1 1 60.00 108579.63 16384 87380 1 1 60.01 108519.09 2.6.23.17 Throughput 1192.49 MB/sec 4 procs .953 16384 87380 1 1 60.00 91124.67 .866 16384 87380 1 1 60.00 93124.38 16384 87380 1 1 60.01 92249.69 16384 87380 1 1 60.01 91103.12 wakeup granularity = 0 Throughput 1200.46 MB/sec 4 procs .959 16384 87380 1 1 60.01 95987.66 .866 16384 87380 1 1 60.01 ...
Bisecting 26->27 yet again turned up a repeatable downturn in netperf throughput. There is no difference at this point with tbench. Bisect says first bad commit is 847106f, a security merge. Post bisection sanity checkouts say... v2.6.26-21-g2069f45 16384 87380 1 1 60.00 98435.13 16384 87380 1 1 60.01 99259.90 16384 87380 1 1 60.01 99325.61 16384 87380 1 1 60.00 99039.84 v2.6.26-343-g847106f 16384 87380 1 1 60.00 94764.59 16384 87380 1 1 60.00 94909.89 16384 87380 1 1 60.00 94858.63 16384 87380 1 1 60.00 94801.12 ...every time. I knew I'd regret doing this. -Mike --
I assume that c142bda458a gave a good results as well... One additional sanity check could be to rebase security 6f0f0fd4963 on top of the c142bda458a and then see if bisection among those security commits on top yields to the the same result... Though I doubt it can change much because there was not that much relevant non-security things in the merge in question. -- i. --
I'm not a master of git-foo, so that is not an option. However, a dinky
bisection c142bda4..847106f very clearly says...
marge:..kernel/linux-2.6.27.git # git bisect bad
6f0f0fd496333777d53daff21a4e3b28c4d03a6d is first bad commit
commit 6f0f0fd496333777d53daff21a4e3b28c4d03a6d
Author: James Morris <jmorris@namei.org>
Date: Thu Jul 10 17:02:07 2008 +0900
security: remove register_security hook
The register security hook is no longer required, as the capability
module is always registered. LSMs wishing to stack capability as
a secondary module should do so explicitly.
Signed-off-by: James Morris <jmorris@namei.org>
Acked-by: Stephen Smalley <sds@tycho.nsa.gov>
git bisect start
# good: [c142bda458a9c81097238800e1bd8eeeea09913d] Merge branch 'drm-reorg' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6
git bisect good c142bda458a9c81097238800e1bd8eeeea09913d
# bad: [847106ff628805e1a0aa91e7f53381f3fdfcd839] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6
git bisect bad 847106ff628805e1a0aa91e7f53381f3fdfcd839
# good: [cea78dc4ca044e9666e8f5d797ec50ab85253e49] SELinux: fix off by 1 reference of class_to_string in context_struct_compute_av
git bisect good cea78dc4ca044e9666e8f5d797ec50ab85253e49
# good: [65fc7668006b537f7ae8451990c0ed9ec882544e] security: fix return of void-valued expressions
git bisect good 65fc7668006b537f7ae8451990c0ed9ec882544e
# good: [b478a9f9889c81e88077d1495daadee64c0af541] security: remove unused sb_get_mnt_opts hook
git bisect good b478a9f9889c81e88077d1495daadee64c0af541
# good: [93cbace7a058bce7f99319ef6ceff4b78cf45051] security: remove dummy module fix
git bisect good 93cbace7a058bce7f99319ef6ceff4b78cf45051
# bad: [6f0f0fd496333777d53daff21a4e3b28c4d03a6d] security: remove register_security hook
git bisect bad 6f0f0fd496333777d53daff21a4e3b28c4d03a6d
--
Which is high grade horse-pookey. -Mike --
perhaps re-test commit 6f0f0fd49 and its parent commit, 93cbace7a0. It looks like a potentially bogus bisection result, but _maybe_ it has relevance: changes the size of "struct security_operations", which could have alignment and layout effects on all sorts of kernel variables, kmalloc sizes, etc. Ingo --
This may well be a mythical creature infestation for all I know ;-), but it's address is somewhere in the 2069f45..847106f block, 316 commits, none of which look like they should be the least bit interesting to netperf. I reverted this particular commit in 27.git, got the expected result. Looks like I'll keep poking at it, can't seem to resist. Grr. -Mike --
are you sure it's 2069f45..847106f? Filtering out the likely-uninteresting commits: git log --pretty=format:"%h: %s" 2069f45..847106f | grep -viE \ 'block|alsa|pcmcia|sound|Merge|iosched|blk|DAC960|scsi|s390|paride|pktcdvd|filter|cdrom|drm' gives us: 7daf705: Start using the new '%pS' infrastructure to print symbols 6f0f0fd: security: remove register_security hook 93cbace: security: remove dummy module fix 5915eb5: security: remove dummy module b478a9f: security: remove unused sb_get_mnt_opts hook 32502b8: splice: fix generic_file_splice_read() race with page invalidation 8b3d356: ramfs: enable splice write a144ff0: xen: Avoid allocations causing swap activity on the resume path which really only leaves that security commit your bisection fingered. Which _slightly_ raises its likelyhood of being implicated. Structure size changes can move two formerly far-apart netperf-relevant symbols on the same cacheline, which can start cache ping-pong-ing badly. It wouldnt be the first such incident - alignment changes impacting macro benchmarks. (and it's hard to find it as the thing that changes alignment/size/sharedness might be something totally unrelated) It's still a bit too early to say this for sure though ... Ingo --
Yeah, as sure as I can be. I've built both (et al) kernels several times, and it has repeated every time. Would be nice if someone would try to confirm/deny though. For my little quad, I do.. #!/bin/sh echo 0 > /proc/sys/kernel/sched_wakeup_granularity_ns netserver -p 12865 netserver -p 12866 netserver -p 12867 netserver -p 12868 netperf -p 12865 -t TCP_RR -l 60 -H 127.0.0.1 -T 0,0 -- -r 1,1& netperf -p 12866 -t TCP_RR -l 60 -H 127.0.0.1 -T 1,1 -- -r 1,1& netperf -p 12867 -t TCP_RR -l 60 -H 127.0.0.1 -T 2,2 -- -r 1,1& netperf -p 12868 -t TCP_RR -l 60 -H 127.0.0.1 -T 3,3 -- -r 1,1& wait I sure hope it's something like ping-pong, it's driving me NUTS. -Mike --
How about dividing the problem to smaller blocks then by restoring parts of the change... -- i. --
Well, what I've done is check out the "bad" tree, reverted every darn commit between there and the "good" tree, and then reverted the reverts so I have a nice merge-free line and don't have to remember to think backward. (probably sounds silly to git-foo masters) I'll try bisecting that in the a.m. and see what happens. -Mike --
On Wed, 17 Sep 2008, Mike Galbraith wrote: > On Wed, 2008-09-17 at 16:36 +0300, Ilpo J
It bisected to 1c9ce52. Reverting that in 27.git had the expected
result, nada. Full bisection/test log below - you can jump straight to
post run sanity checks. I'm torn between building a straight line tree
from v2.6.26 through git.today and bisecting that sucker, or exorcising
netperf from my box and swearing a sacred oath to never download the
damned thing again. Nuking netperf is most attractive option.
1e65e841bb5584136ed6047c55cf77532afbbb55 is first bad commit
commit 1e65e841bb5584136ed6047c55cf77532afbbb55
Author: Mike Galbraith <efault@gmx.de>
Date: Wed Sep 17 14:55:50 2008 +0200
Revert "Revert "block: export "ro" attribute""
git bisect start
# good: [7804ad865f7d0cd9bdc51da601772ce4d2e252ca] Revert "[ALSA] soc - tlv320aic3x - revisit clock setup"
git bisect good 7804ad865f7d0cd9bdc51da601772ce4d2e252ca
# bad: [2846693a63a34ac6d582dd55a7e00605b49b1cec] Revert "Revert "[S390] sclp_tty: Fix scheduling while atomic bug.""
git bisect bad 2846693a63a34ac6d582dd55a7e00605b49b1cec
# bad: [70477f86f63640be2dd1d8968aeb47870a5c21c6] Revert "Revert "xen/blkfront: Make sure we don't use bounce buffers, we don't need them.""
git bisect bad 70477f86f63640be2dd1d8968aeb47870a5c21c6
# good: [7c6ccb520424939deff0a50f3fae621c6477dbbe] Revert "Revert "ALSA: hda - Add bdl_pos_adj option""
git bisect good 7c6ccb520424939deff0a50f3fae621c6477dbbe
# good: [66036beae94f043f99044e285935486126a9c4bd] Revert "Revert "pcmcia: fix Alchemy warnings""
git bisect good 66036beae94f043f99044e285935486126a9c4bd
# good: [6b7b5ef18871c8f7c15eedc6eb53270eaf8bc613] Revert "Revert "ALSA: hda - Added SSID for 'Fujitsu Siemens Amilo M1451G' laptop""
git bisect good 6b7b5ef18871c8f7c15eedc6eb53270eaf8bc613
# good: [024905ea4b2d1ab5d6b845ba84ddfc0857fb2d2a] Revert "Revert "ALSA: hda - Add MacBook 3.1 support""
git bisect good 024905ea4b2d1ab5d6b845ba84ddfc0857fb2d2a
# good: [4bbe3501e06eddaa4900894efa519f1167cb8624] Revert "Revert "as-iosched: properly protect ioc_gone and ioc count""
git bisect ...BTW, the reason it's revert revert is that I reverse bisected the revert tree yesterday, and it emitted the same darn result. I immediately said "yeah right, ya screwed up", and created the revert revert tree to make sure I couldn't fumble negation. -Mike --
gcc compiling something slightly differently would be a nice theory but it sort of breaks down now as this commit touches only one .c file... In the past when I did some static inline .h -> .c uninline sizing tests I noticed that some changes happened also in places which should have been quite much unrelated. Though all the changes were minor anyway (in the places I did look), e.g., routed the conditional paths slightly differently and added one xor clear reg. -- i. --
Could you please try following patch ? [PATCH] security_ops moved to read_mostly section "struct security_operations *security_ops" should be moved to read_mostly section in order to NOT let it share a cache line with higly modified variables. Signed-off-by: Eric Dumazet <dada1@cosmosbay.com> diff --git a/security/security.c b/security/security.c index 3a4b4f5..0b13d65 100644 --- a/security/security.c +++ b/security/security.c @@ -24,7 +24,7 @@ static __initdata char chosen_lsm[SECURITY_NAME_MAX + 1]; extern struct security_operations default_security_ops; extern void security_fixup_ops(struct security_operations *ops); -struct security_operations *security_ops; /* Initialized to NULL */ +struct security_operations *security_ops __read_mostly;e /* amount of vm to protect from userspace access */ unsigned long mmap_min_addr = CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR; --
v2.6.26-974-g2846693 (tip of revert reverts tree, == 847106f) 16384 87380 1 1 60.00 94350.45 16384 87380 1 1 60.01 95857.25 16384 87380 1 1 60.00 95334.84 16384 87380 1 1 60.00 95052.11 v2.6.26-659-g7804ad8 (first commit prior, == 2069f45) 16384 87380 1 1 60.00 98630.64 16384 87380 1 1 60.00 98653.14 16384 87380 1 1 60.00 99162.65 16384 87380 1 1 60.00 98652.38 v2.6.26-974-g2846693 patched 16384 87380 1 1 60.00 95877.41 16384 87380 1 1 60.00 95810.27 16384 87380 1 1 60.00 95530.03 16384 87380 1 1 60.00 94968.12 (poo, "it" didn't die) --
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11335 Subject : 2.6.27-rc2-git5 BUG: unable to handle kernel paging request Submitter : Randy Dunlap <randy.dunlap@oracle.com> Date : 2008-08-12 4:18 (32 days old) References : http://marc.info/?l=linux-kernel&m=121851477201960&w=4 http://lkml.org/lkml/2008/8/16/274 Handled-By : Hugh Dickins <hugh@veritas.com> --
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11336 Subject : 2.6.27-rc2:stall while mounting root fs Submitter : Torsten Kaiser <just.for.lkml@googlemail.com> Date : 2008-08-12 12:37 (32 days old) References : http://marc.info/?l=linux-kernel&m=121854484015909&w=4 Handled-By : Thomas Gleixner <tglx@linutronix.de> Patch : http://bugzilla.kernel.org/attachment.cgi?id=17622 --
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11340 Subject : LTP overnight run resulted in unusable box Submitter : Alexey Dobriyan <adobriyan@gmail.com> Date : 2008-08-13 9:24 (31 days old) References : http://marc.info/?l=linux-kernel&m=121861951902949&w=4 --
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11343 Subject : SATA Cold Boot Problems with 2.6.27-rc[23] on nVidia 680i Submitter : Manny Maxwell <mannymax@mannymax.net> Date : 2008-08-14 4:16 (30 days old) References : http://marc.info/?l=linux-kernel&m=121868782917600&w=4 --
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11380 Subject : lockdep warning: cpu_add_remove_lock at:cpu_maps_update_begin+0x14/0x16 Submitter : Ingo Molnar <mingo@elte.hu> Date : 2008-08-20 6:44 (24 days old) References : http://marc.info/?l=linux-kernel&m=121921480931970&w=4 --
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11358 Subject : net: forcedeth call restore mac addr in nv_shutdown path Submitter : Yinghai Lu <yhlu.kernel@gmail.com> Date : 2008-08-17 3:30 (27 days old) References : http://marc.info/?l=linux-kernel&m=121894389018584&w=4 Handled-By : Yinghai Lu <yhlu.kernel@gmail.com> Patch : http://marc.info/?l=linux-kernel&m=121894389018584&w=4 --
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11357 Subject : Can not boot up with zd1211rw USB-Wlan Stick Submitter : uwe <kender@freenet.de> Date : 2008-08-16 14:17 (28 days old) --
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11404 Subject : BUG: in 2.6.23-rc3-git7 in do_cciss_intr Submitter : rdunlap <randy.dunlap@oracle.com> Date : 2008-08-21 5:52 (23 days old) References : http://marc.info/?l=linux-kernel&m=121929819616273&w=4 http://marc.info/?l=linux-kernel&m=121932889105368&w=4 Handled-By : Miller, Mike (OS Dev) <Mike.Miller@hp.com> James Bottomley <James.Bottomley@hansenpartnership.com> --
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11382 Subject : e1000e: 2.6.27-rc1 corrupts EEPROM/NVM Submitter : David Vrabel <david.vrabel@csr.com> Date : 2008-08-08 10:47 (36 days old) References : http://marc.info/?l=linux-kernel&m=121819267211679&w=4 Handled-By : Christopher Li <chrisl@vmware.com> Patch : http://marc.info/?l=linux-mm-commits&m=122038324200305&w=4 --
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11398 Subject : hda_intel: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj. Submitter : Frans Pop <elendil@planet.nl> Date : 2008-08-21 17:17 (23 days old) --
At Sat, 13 Sep 2008 09:37:51 +0200, Yeah, the driver wasn't changed about this. Basically it's a warning message that CPU usage got higher due to somehow wrongly behaving hardware. The driver behavior itself didn't do anything wrong. That is, if the driver didn't show it, you Of course, it would be ideal if we can add a perfect workaround for it, but right now, I have no idea what to do better. So, I don't think it's worth to keeping this open as a regression. thanks, Takashi --
I've closed the bug. Thanks, Rafael --
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11407 Subject : suspend: unable to handle kernel paging request Submitter : Vegard Nossum <vegard.nossum@gmail.com> Date : 2008-08-21 17:28 (23 days old) References : http://marc.info/?l=linux-kernel&m=121933974928881&w=4 Handled-By : Rafael J. Wysocki <rjw@sisk.pl> Pekka Enberg <penberg@cs.helsinki.fi> Pavel Machek <pavel@suse.cz> --
I'm sorry for not replying sooner. This is current status: Problem was never resolved. I tried to bisect, but I only ran into other problems with either config not being supported for my machine prior to certain date while trying to find a good bisection point. It's been a while now, so I don't remember everything exactly, but I may try to reproduce it tomorrow on the latest -git and see what comes up. Will report back as soon as I have more info. Thanks, Vegard -- "The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it disguises that the error is the programmer's own creation." -- E. W. Dijkstra, EWD1036 --
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11439 Subject : [2.6.27-rc4-git4] compilation warnings Submitter : Rufus &amp; Azrael <rufus-azrael@numericable.fr> Date : 2008-08-26 9:37 (18 days old) References : http://marc.info/?l=linux-kernel&m=121974353815440&w=4 Handled-By : Greg KH <gregkh@suse.de> Patch : http://marc.info/?l=linux-kernel&m=121976424221858&w=4 --
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11442 Subject : btusb hibernation/suspend breakage in current -git Submitter : Rafael J. Wysocki <rjw@sisk.pl> Date : 2008-08-25 11:37 (19 days old) References : http://marc.info/?l=linux-bluetooth&m=121966402012074&w=4 Handled-By : Oliver Neukum <oliver@neukum.org> Patch : http://marc.info/?l=linux-bluetooth&m=121967226027323&w=4 --
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11459 Subject : kernel crash after wifi connection established Submitter : Alexey Kuznetsov <ak@axet.ru> Date : 2008-08-30 03:08 (14 days old) --
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11463 Subject : sshd hangs on close Submitter : Matthias Urlichs <matthias@urlichs.de> Date : 2008-08-30 9:18 (14 days old) References : http://marc.info/?l=linux-kernel&m=122008800512864&w=4 --
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11465 Subject : Linux-2.6.27-rc5, drm errors in log Submitter : Gene Heskett <gene.heskett@verizon.net> Date : 2008-08-30 18:52 (14 days old) References : http://marc.info/?l=linux-kernel&m=122012238925775&w=4 Handled-By : Dave Airlie <airlied@gmail.com> --
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11471 Subject : GPE storm detected, kernel freezes Submitter : George Gibbs <Vash63@gmail.com> Date : 2008-08-31 22:00 (13 days old) Handled-By : Zhang Rui <rui.zhang@intel.com> --
this has already been fixed in -rc6. please refer to http://bugzilla.kernel.org/show_bug.cgi?id=11471#c22 so I think this should be removed from the list. thanks, rui --
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11476 Subject : failure to associate after resume from suspend to ram Submitter : Michael S. Tsirkin <m.s.tsirkin@gmail.com> Date : 2008-09-01 13:33 (12 days old) References : http://marc.info/?l=linux-kernel&m=122028529415108&w=4 Handled-By : Zhu Yi <yi.zhu@intel.com> Dan Williams <dcbw@redhat.com> Jouni Malinen <j@w1.fi> --
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11500 Subject : /proc/net bug related to selinux Submitter : Andrew Morton <akpm@linux-foundation.org> Date : 2008-09-04 17:45 (9 days old) References : http://marc.info/?l=linux-kernel&m=122055041313270&w=4 --
I think this might be a regression caused by namespace changes which we addressed in SELinux policy. Which distro version & policy version is this seen with? - James -- James Morris <jmorris@namei.org> --
On Sat, 13 Sep 2008 08:14:10 +1000 (EST) FC5 on x86_32 and FC6 on x86_64. --
By which I mean, this was caused by a non-SELinux change to the upstream As mentioned in the bugzilla, any related avc messages would be useful. -- James Morris <jmorris@namei.org> --
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 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 ...
Well, it seems no one else is testing selinux ... --
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 --
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
--
On Mon, 15 Sep 2008 09:05:26 -0400 Running `ls -l /proc/net' on the FC6 machine produces: akpm2:/home/akpm# /sbin/ausearch -i -m AVC -sv no 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. --
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 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 --
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 --
On Wed, 17 Sep 2008 14:39:45 -0700 It's back up-thread somewhere. umm... On Mon, 15 Sep 2008 09:05:26 -0400 --
On Wed, 17 Sep 2008 17:24:36 -0400 That only true if the 2.6.25+ kernel.org kernel is 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 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? --
Well, there is also the issue of distro specific "special sauce" patches which might cause different behavior from the kernel.org kernel, but It is somewhat comforting to know that we can call what we do a "trade", Okay, so we suck because broke something in 2.6.25 that went undetected because current SELinux policies happen to be compatible with the 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 --
On Wed, 17 Sep 2008 18:12:59 -0400 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 --
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 --
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, 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 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 --
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 -- Stephen Smalley National Security Agency --
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 --
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 Unresolved; presently has a single label for all nodes. See https://bugzilla.redhat.com/show_bug.cgi?id=228902 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 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 --
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 --
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=... 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 --
From: Paul Moore <paul.moore@hp.com> No, we tend to call this breaking things instead. --
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.
--
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11485 Subject : 2.6.27-rc xen pvops regression? Submitter : Bernhard Schmidt <berni@birkenwald.de> Date : 2008-08-31 17:18 (13 days old) References : http://marc.info/?l=linux-kernel&m=122020367015025&w=4 Handled-By : Alex Nixon <alex.nixon@citrix.com> Jeremy Fitzhardinge <jeremy@goop.org> --
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11501 Subject : Failed to open destination file: Permission deniedihex2fw Submitter : Andrew Morton <akpm@linux-foundation.org> Date : 2008-09-04 18:34 (9 days old) References : http://marc.info/?l=linux-kernel&m=122055342419068&w=4 --
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11505 Subject : oltp ~10% regression with 2.6.27-rc5 on stoakley machine Submitter : Lin Ming <ming.m.lin@intel.com> Date : 2008-09-04 7:06 (9 days old) References : http://marc.info/?l=linux-kernel&m=122051202202373&w=4 http://marc.info/?t=122089704700005&r=1&w=4 Handled-By : Peter Zijlstra <a.p.zijlstra@chello.nl> Gregory Haskins <ghaskins@novell.com> Ingo Molnar <mingo@elte.hu> --
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11506 Subject : oops during unmount - ext3? (2.6.27-rc5) Submitter : Marcin Slusarz <marcin.slusarz@gmail.com> Date : 2008-09-04 19:14 (9 days old) References : http://marc.info/?l=linux-kernel&m=122055573123449&w=4 --
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11507 Subject : usb: sometimes dead keyboard after boot Submitter : Frans Pop <elendil@planet.nl> Date : 2008-08-26 21:03 (18 days old) References : http://marc.info/?l=linux-kernel&m=121977815018224&w=2 Handled-By : Alan Stern <stern@rowland.harvard.edu> Patch : http://www.spinics.net/lists/linux-usb/msg09735.html --
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11512 Subject : sort-of regression due to "kconfig: speed up all*config + randconfig" Submitter : Alexey Dobriyan <adobriyan@gmail.com> Date : 2008-09-05 22:50 (8 days old) References : http://marc.info/?l=linux-kernel&m=122065498013858&w=4 --
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11516 Subject : severe performance degradation on x86_64 going from 2.6.26-rc9 -&gt; 2.6.27-rc5 Submitter : Jason Vas Dias <jason.vas.dias@gmail.com> Date : 2008-09-07 13:59 (6 days old) --
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11549 Subject : 2.6.27-rc5 acpi: EC Storm error message on bootup Submitter : <jmerkey@wolfmountaingroup.com> Date : 2008-09-02 21:27 (11 days old) References : http://marc.info/?l=linux-kernel&m=122039255517586&w=4 Handled-By : Alexey Starikovskiy <astarikovskiy@suse.de> Patch : http://marc.info/?l=linux-kernel&m=122098180019264&w=4 --
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11548 Subject : kernel BUG at drivers/pci/intel-iommu.c:1373! Submitter : Chris Mason <chris.mason@oracle.com> Date : 2008-09-08 14:26 (5 days old) References : http://marc.info/?l=linux-kernel&m=122088566310440&w=4 --
This is still a bug, but I haven't tried this workload on 2.6.26, so I'm not sure it is a regression. Unfortunately, I won't be able to test it again until after the plumber's conference. -chris --
That's fine. In case it turns out to be a regression, it's better to list it for now IMO. :-) Thanks, Rafael --
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11547 Subject : build issue #565 for v2.6.27-rc5 : undefined reference to `ei_interrupt' in hp-plus.c Submitter : Toralf Förster <toralf.foerster@gmx.de> Date : 2008-09-07 13:19 (6 days old) References : http://marc.info/?l=linux-kernel&m=122079361508022&w=4 Handled-By : Randy.Dunlap <rdunlap@xenotime.net> Patch : http://marc.info/?l=linux-next&m=122038632306156&w=2 --
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11552 Subject : Disabling IRQ #23 Submitter : Justin Mattock <justinmattock@gmail.com> Date : 2008-09-09 19:08 (4 days old) References : http://marc.info/?l=linux-kernel&m=122098735230906&w=4 http://marc.info/?l=linux-kernel&m=122107367715361&w=4 Handled-By : Yinghai Lu <yhlu.kernel@gmail.com> --
yeah I think it would be a good idea. something to do with ehci_hcd, i.g. if I blacklist ehci_hcd Disabling IRQ#23 message doesnt seem to be showing up. -- Justin P. Mattock --
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11550 Subject : pnp: Huge number of "io resource overlap" messages Submitter : Frans Pop <elendil@planet.nl> Date : 2008-09-09 10:50 (4 days old) References : http://marc.info/?l=linux-kernel&m=122095745403793&w=4 Handled-By : Rene Herman <rene.herman@keyaccess.nl> Bjorn Helgaas <bjorn.helgaas@hp.com> Patch : http://marc.info/?l=linux-kernel&m=122098498125536&w=4 --
It should be. The patch listed should be good as far as I'm concerned but needs to be pushed by Bjorn as PnP mainatainer. Generally speaking 0 wouldn't be a _very_ necesarily invalid value it seems so it's maybe not very nice. If someone wants a changelog though, this should do: === PNP: avoid checking unitialized BARs for conflicts Avoid checking a PCI BAR for conflicts if the BIOS left it unitialized. Reported-by: Frans Pop <elendil@planet.nl> Signed-off-by: Rene Herman <rene.herman@gmail.com> === (Frans: Tested-by?) Rene. --
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11551 Subject : Semi-repeatable hard lockup on 2.6.27-rc6 Submitter : Steven Noonan <steven@uplinklabs.net> Date : 2008-09-10 18:07 (3 days old) References : http://marc.info/?l=linux-kernel&m=122107007407994&w=4 --
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11553 Subject : Strange looking line from "ps aux" Submitter : Rogério Brito <rbrito@ime.usp.br> Date : 2008-09-11 17:43 (2 days old) References : http://marc.info/?l=linux-kernel&m=122115506018275&w=4 --
Isn't this another instance of <http://bugzilla.kernel.org/show_bug.cgi?id=11209>? If you can try 2.6.27-rc6, that should fix it. Alan --
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11554 Subject : Partition check considered as error is breaking mounting in 2.6.27 Submitter : Herton Ronaldo Krzesinski <herton@mandriva.com.br> Date : 2008-09-12 16:56 (1 days old) References : http://marc.info/?l=linux-kernel&m=122123862519434&w=4 --
Fixed now with commit 8d99f83b9478768d3a8d7d1bcd9bd182c75a0447 -- []'s Herton --
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11556 Subject : e100: PCI wake-up handling rework causes "Error clearing wake event" Submitter : Frans Pop <elendil@planet.nl> Date : 2008-09-09 6:12 (4 days old) References : http://marc.info/?l=linux-netdev&m=122094080712131&w=4 Handled-By : Rafael J. Wysocki <rjw@sisk.pl> Patch : http://marc.info/?l=linux-kernel&m=122096638020191&w=4 --
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11557 Subject : Controlling backlight on thinkpad x60 Submitter : Pavel Machek <pavel@suse.cz> Date : 2008-09-08 15:10 (5 days old) References : http://marc.info/?l=linux-kernel&m=122088987319698&w=4 Handled-By : Matthew Garrett <mjg59@srcf.ucam.org> --
I don't think this is a regression. The correct way to drive this hardware has always been through the ACPI video driver. The fact that thinkpad-acpi would also attempt to drive it was a bug. -- Matthew Garrett | mjg59@srcf.ucam.org --
I'm pretty sure thinkpad-acpi is older then ACPI-video. So yes, I believe this is a regression, but it may be pretty old one. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11559 Subject : 2.6.27-rc6: nohz + s2ram = need to press keys to get progress Submitter : Pavel Machek <pavel@suse.cz> Date : 2008-09-12 8:31 (1 days old) References : http://marc.info/?l=linux-kernel&m=122121384705262&w=4 --
