* [Resend] 3.2-rc6+: Reported regressions from 3.0 and 3.1
@ 2011-12-20 23:54 ` Rafael J. Wysocki
0 siblings, 0 replies; 34+ messages in thread
From: Rafael J. Wysocki @ 2011-12-20 23:54 UTC (permalink / raw)
To: Kernel Testers List
Cc: LKML, Linus Torvalds, Maciej Rutecki, Andrew Morton,
Florian Mickler, davem-fT/PcQaiUtIeIZ0/mPfg9Q
[Evidently, vger has blocked the previous attempts to post this message
for some reason. I wonder why?]
This message contains a list of some regressions from 3.0 and 3.1
for which there are no fixes in the mainline known to the tracking team.
If any of them have been fixed already, please let us know.
If you know of any other unresolved regressions from 3.0 and 3.1, please let us
know either and we'll add them to the list. Also, please let us know if any of
the entries below are invalid.
The entries below are simplified and the statistics are not present due to the
continuing Bugzilla outage.
Subject : iwlagn is getting very shaky
Submitter : Norbert Preining <preining-DX+603jRYB8@public.gmane.org>
Date : 2011-10-19 6:01
Message-ID : 20111019060108.GA11588-DqSSrKF0TaySnEC3TeqHn5dqbFPxfnh/@public.gmane.org
References : http://marc.info/?l=linux-kernel&m=131914553920614&w=2
Subject : Regression: "irqpoll" hasn't been working for me since March 16 IRQ
Submitter : Edward Donovan <edward.donovan-mb/Bq7DTvoSsTnJN9+BGXg@public.gmane.org>
Date : 2011-10-19 22:09
Message-ID : CADdbW+HXdCPfJu2RTF6zz+ujCmiu_dmZwL2iScuF53p=AaZ1Uw@mail.gmail.com
References : http://marc.info/?l=linux-kernel&m=131914554220679&w=2
Subject : 3.1+ iwlwifi lockup
Submitter : Dave Jones <davej-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Date : 2011-10-31 14:34
Message-ID : 20111031143408.GA17152-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
References : http://marc.info/?l=linux-kernel&m=132007169420160&w=2
Subject : Linus GIT - INFO: possible circular locking dependency detected
Submitter : Miles Lane <miles.lane-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2011-11-03 15:57
Message-ID : CAHFgRy8S0xLfhZxTUOEH5A0PL_Fb79-0-gmbQ=9h2D-xMqt1hA@mail.gmail.com
References : http://marc.info/?l=linux-kernel&m=132033587908426&w=2
Subject : DMA-API check_sync errors with 3.2
Submitter : Josh Boyer <jwboyer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Date : 2011-11-08 17:31
Message-ID : 20111108173153.GE14216-8k7Gwy46GHkf7BdofF/totBPR1lH4CV8@public.gmane.org
References : http://marc.info/?l=linux-kernel&m=132077357608797&w=2
Subject : 3.2-rc1 doesn't boot on dual socket opteron without swap
Submitter : Niklas Schnelle <niklas-74wnUeZ+fLazQB+pC5nmwQ@public.gmane.org>
Date : 2011-11-10 20:09
Message-ID : 1320955769.1718.8.camel@jupiter
References : http://marc.info/?l=linux-kernel&m=132095583501767&w=2
Subject : Sparc-32 doesn't work in 3.1.
Submitter : Rob Landley <rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org>
Date : 2011-11-12 11:22
Message-ID : 4EBEAB5A.5020809-VoJi6FS/r0vR7s880joybQ@public.gmane.org
References : http://www.spinics.net/lists/kernel/msg1260383.html
Subject : WARNING: at fs/sysfs/sysfs.h:195 (during boot)
Submitter : Markus Trippelsdorf <markus-xp2qqqlHh3xzoYq+O6RWwA@public.gmane.org>
Date : 2011-11-13 19:24
Message-ID : 20111113192417.GA1659-tLCgZGx+iJ+kxVt8IV0GqQ@public.gmane.org
References : http://marc.info/?l=linux-kernel&m=132121231921932&w=2
Subject : max PWM is zero
Submitter : Marcos Paulo de Souza <marcos.mage-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2011-11-15 15:14
Message-ID : alpine.LNX.2.00.1111151301410.2693-4/PLUo9XfK9uYUHNOcvv8+TW4wlIGRCZ@public.gmane.org
References : http://marc.info/?l=linux-kernel&m=132137019330548&w=2
Subject : Oops on suspend with libertas SDIO (Linux 3.2-rc2)
Submitter : Sven Neumann <s.neumann-5g8ninUHluJWk0Htik3J/w@public.gmane.org>
Date : 2011-11-17 15:36
Message-ID : 1321544210.31090.6.camel@sven
References : http://marc.info/?l=linux-kernel&m=132154527715807&w=2
Subject : Impossible high cpu-time values for migration threads
Submitter : Markus Trippelsdorf <markus-xp2qqqlHh3xzoYq+O6RWwA@public.gmane.org>
Date : 2011-11-17 22:17
Message-ID : 20111117221731.GA9229-tLCgZGx+iJ+kxVt8IV0GqQ@public.gmane.org
References : http://marc.info/?l=linux-kernel&m=132156832124314&w=2
Subject : WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
Submitter : Markus Trippelsdorf <markus-xp2qqqlHh3xzoYq+O6RWwA@public.gmane.org>
Date : 2011-11-18 7:25
Message-ID : 20111118072519.GA1615-tLCgZGx+iJ+kxVt8IV0GqQ@public.gmane.org
References : http://marc.info/?l=linux-kernel&m=132160119031794&w=2
Subject : [REGRESSION] resume takes 10s longer due to e1b6eb3 (Bluetooth: Increase HCI reset timeout ...)
Submitter : Tomáš Janoušek <tomi-YoqI/XImC7s@public.gmane.org>
Date : 2011-11-18 18:40
Message-ID : 20111118184017.GA5052-YoqI/XImC7s@public.gmane.org
References : http://marc.info/?l=linux-kernel&m=132164169511416&w=2
Subject : [REGRESSION] sudden cpu hogging in kernel 3.2 rc-series
Submitter : "Nicolas Kalkhof" <nkalkhof-S0/GAf8tV78@public.gmane.org>
Date : 2011-11-18 20:33
Message-ID : 506786689.810044.1321648395265.JavaMail.fmail@mwmweb010
References : http://marc.info/?l=linux-kernel&m=132164909313594&w=2
Subject : Bisected regression: hang on i915 between 3.1.0-rc9 and 3.1.0
Submitter : Meelis Roos <mroos-Y27EyoLml9s@public.gmane.org>
Date : 2011-11-22 10:15
Message-ID : alpine.SOC.1.00.1111221207090.6490-ptEonEWSGqKptlylMvRsHA@public.gmane.org
References : http://marc.info/?l=linux-kernel&m=132195700023709&w=2
Subject : 3.2-rc2 regression: floppy driver breaks boot
Submitter : Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>
Date : 2011-11-22 11:14
Message-ID : 20111122111405.GA28215-I/5MKhXcvmPrBKCeMvbIDA@public.gmane.org
References : http://marc.info/?l=linux-kernel&m=132196052124801&w=2
Subject : [regression 3.1.0 -> 3.20rc] USB Oops
Submitter : Norbert Preining <preining-DX+603jRYB8@public.gmane.org>
Date : 2011-11-22 12:52
Message-ID : 20111122125256.GB32440-DqSSrKF0TaySnEC3TeqHn5dqbFPxfnh/@public.gmane.org
References : http://marc.info/?l=linux-kernel&m=132196644726900&w=2
Subject : Freezing of tasks failed after 20.01 seconds in kernel 3.2.0-rc2
Submitter : Belisko Marek <marek.belisko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2011-11-22 21:20
Message-ID :
CAAfyv36nxYq1EA2pcHi5WR1BdWYHp2sQTY1mMA4Q3JjcOG5RDw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
References : http://marc.info/?l=linux-kernel&m=132199691706100&w=2
Subject : 3.2.0-rc2+git: possible recursive locking detected in process
memory freeing
Submitter : Meelis Roos <mroos-Y27EyoLml9s@public.gmane.org>
Date : 2011-11-23 13:12
Message-ID : alpine.SOC.1.00.1111231311490.15939-ptEonEWSGqKptlylMvRsHA@public.gmane.org
References : http://lkml.org/lkml/2011/11/23/159
Subject : i915: 3.2 rc1/2 KMS regression
Submitter : Patrik Kullman <patrik.kullman-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2011-11-23 23:43
Message-ID : CAGPN=9THOv-
M4Td4haE94uDcsAjW3eGMG7ioLeu+p8xUOBPd7w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
References : http://marc.info/?l=linux-kernel&m=132209186403288&w=2
Subject : 3.2-rc2: regression after hibernate: lots of warnings, broken
system
Submitter : Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>
Date : 2011-11-24 15:40
Message-ID : 20111124154014.GA2153-I/5MKhXcvmPrBKCeMvbIDA@public.gmane.org
References : http://marc.info/?l=linux-kernel&m=132214929818015&w=2
Subject : [regression] WARNING: at drivers/block/floppy.c:2929
do_fd_request+0xb7/0xb9() in 3.2.0-rc2 and 3
Submitter : Ralf Hildebrandt <Ralf.Hildebrandt-jq1tPX9l7E6ELgA04lAiVw@public.gmane.org>
Date : 2011-11-25 10:34
Message-ID : 20111125103420.GO4581-jq1tPX9l7E6ELgA04lAiVw@public.gmane.org
References : http://marc.info/?l=linux-kernel&m=132221799501685&w=2
Subject : [BUG] 3.2-rcX radeon KMS system freeze
Submitter : Bob Tracy <rct-GsGdjl1a1FBK+8ot1e1MDQ@public.gmane.org>
Date : 2011-11-25 20:33
Message-ID : 20111125203351.GA3651-GsGdjl1a1FBK+8ot1e1MDQ@public.gmane.org
References : http://marc.info/?l=linux-kernel&m=132225331312019&w=2
Subject : 3.2-rc2 regression due to commit "USB: EHCI: fix HUB TT scheduling
issue with iso transfer" 811c926c538f7e8d3c08b630dd5844efd7e000f6
Submitter : Sander Eikelenboom <linux-6SM94LqRVpn6gRhOQ7JHfg@public.gmane.org>
Date : 2011-11-26 15:47
Message-ID : 1001209018.20111126164712-6SM94LqRVpn6gRhOQ7JHfg@public.gmane.org
References : http://marc.info/?l=linux-kernel&m=132232295425393&w=2
Subject : 3.2-rc3+: [drm:i915_hangcheck_elapsed] ERROR Hangcheck timer
elapsed... GPU hung
Submitter : Sergei Trofimovich <slyich-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2011-12-02 17:56
Message-ID : 20111202205601.115522b1-rUBWEpAk+NE@public.gmane.org
References : http://marc.info/?l=linux-kernel&m=132284845705156&w=2
Subject : [BUG] deadlock: jfs (3.2.0-rc4-00154-g8e8da02)
Submitter : Nico Schottelius <nico-linux-20111201-xuaVFQXs+5hIG4jRRZ66WA@public.gmane.org>
Date : 2011-12-06 10:05
Message-ID : 20111206100533.GB6161-xuaVFQXs+5hIG4jRRZ66WA@public.gmane.org
References : http://marc.info/?l=linux-kernel&m=132317917827825&w=2
Subject : [3.2-rc4] pcnet32: DMA-API: device driver tries to sync DMA
memory it has not allocated
Submitter : Tetsuo Handa <penguin-kernel-1yMVhJb1mP/7nzcFbJAaVXf5DAMn2ifp@public.gmane.org>
Date : 2011-12-09 3:40
Message-ID : 201112090340.pB93ek9i086855-etx+eQDEXHD7nzcFbJAaVXf5DAMn2ifp@public.gmane.org
References : http://marc.info/?l=linux-kernel&m=132340215706219&w=2
Subject : Enabling FCoE point-to-point mode triggers a deadlock
Submitter : Bart Van Assche <bvanassche-HInyCGIudOg@public.gmane.org>
Date : 2011-12-09 14:33
References : http://permalink.gmane.org/gmane.linux.scsi.open-fcoe.devel/11451
Subject : iwlagn unusable in 3.2.0rc4
Submitter : Dave Jones <davej-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Date : 2011-12-09 19:42
Message-ID : 20111209194208.GA15236-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
References : http://marc.info/?l=linux-kernel&m=132345984724433&w=2
Subject : DRM nouveau crash with 3.2.0-rc5
Submitter : "Berck E. Nash" <flyboy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2011-12-10 5:10
Message-ID : 4EE2E9BB.8060801-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
References : http://marc.info/?l=linux-kernel&m=132349393700419&w=2
Subject : Reiserfs.c bug in 3.2-rc5
Submitter : "Jorge Bastos" <mysql.jorge-lcG7AWEBJY0VhHzd4jOs4w@public.gmane.org>
Date : 2011-12-10 23:48
Message-ID : 43556.213.228.140.150.1323560920.squirrel-2RFepEojUI2VwbsBYQEljQ@public.gmane.orgpt
References : http://marc.info/?l=linux-kernel&m=132356156914296&w=2
Subject : [REGRESSION] 3.2.0-rc3 Bluetooth L2CAP Linux to Linux rfcomm
fails
Submitter : David Fries <david-CAZ2Ig26prheoWH0uzbU5w@public.gmane.org>
Date : 2011-12-11 5:16
Message-ID : 20111211051624.GA12050-6Mk49KDF3Zwuqz//ww0BS9HuzzzSOjJt@public.gmane.org
References : http://marc.info/?l=linux-kernel&m=132358071417198&w=2
Subject : recent regression: after resume the mouse and X is extremely slow
Submitter : Norbert Preining <preining-DX+603jRYB8@public.gmane.org>
Date : 2011-12-11 22:13
Message-ID : 20111211221303.GA8710-DqSSrKF0TaySnEC3TeqHn5dqbFPxfnh/@public.gmane.org
References : http://marc.info/?l=linux-kernel&m=132364169929740&w=2
Thanks!
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Resend] 3.2-rc6+: Reported regressions from 3.0 and 3.1
@ 2011-12-21 2:31 ` Linus Torvalds
0 siblings, 0 replies; 34+ messages in thread
From: Linus Torvalds @ 2011-12-21 2:31 UTC (permalink / raw)
To: Rafael J. Wysocki, Dave Kleikamp, jfs-discussion
Cc: Kernel Testers List, LKML, Maciej Rutecki, Andrew Morton,
Florian Mickler, davem
On Tue, Dec 20, 2011 at 3:54 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>
> Subject : Regression: "irqpoll" hasn't been working for me since March 16 IRQ
> Submitter : Edward Donovan <edward.donovan@numble.net>
> Date : 2011-10-19 22:09
> Message-ID : CADdbW+HXdCPfJu2RTF6zz+ujCmiu_dmZwL2iScuF53p=AaZ1Uw@mail.gmail.com
> References : http://marc.info/?l=linux-kernel&m=131914554220679&w=2
Edward fixed this in commit 52553ddffad76ccf192d4dd9ce88d5818f57f62a.
> Subject : Linus GIT - INFO: possible circular locking dependency detected
> Submitter : Miles Lane <miles.lane@gmail.com>
> Date : 2011-11-03 15:57
> Message-ID : CAHFgRy8S0xLfhZxTUOEH5A0PL_Fb79-0-gmbQ=9h2D-xMqt1hA@mail.gmail.com
> References : http://marc.info/?l=linux-kernel&m=132033587908426&w=2
I *think* this is fixed by the revert in commit 5e442a493fc5.
> Subject : Sparc-32 doesn't work in 3.1.
> Submitter : Rob Landley <rob@landley.net>
> Date : 2011-11-12 11:22
> Message-ID : 4EBEAB5A.5020809@landley.net
> References : http://www.spinics.net/lists/kernel/msg1260383.html
I'm pretty sure this is fixed by commit b1f44e13a525.
> Subject : WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
> Submitter : Markus Trippelsdorf <markus@trippelsdorf.de>
> Date : 2011-11-18 7:25
> Message-ID : 20111118072519.GA1615@x4.trippels.de
> References : http://marc.info/?l=linux-kernel&m=132160119031794&w=2
This is a combination one, I think. There's some kexec trouble with
DRI and Radeons, and there on PPC the SLUB case was done incorrectly.
The PPC case was fixed, the DRI/Radeon/kexec thing is pending for next
release, I'm afraid.
> Subject : Bisected regression: hang on i915 between 3.1.0-rc9 and 3.1.0
> Submitter : Meelis Roos <mroos@linux.ee>
> Date : 2011-11-22 10:15
> Message-ID : alpine.SOC.1.00.1111221207090.6490@math.ut.ee
> References : http://marc.info/?l=linux-kernel&m=132195700023709&w=2
This is i915 vs VT-d. It may be fixed in current -git, but basically
people should try to avoid using VT-d with i915, there seem to be
hardware bugs wrt the graphics semaphores and power management code.
> Subject : 3.2-rc2 regression: floppy driver breaks boot
> Submitter : Pavel Machek <pavel@ucw.cz>
> Date : 2011-11-22 11:14
> Message-ID : 20111122111405.GA28215@elf.ucw.cz
> References : http://marc.info/?l=linux-kernel&m=132196052124801&w=2
Hmm. I'd love to get more info. Turning off floppy support may work
around it, but I don't think we've actually seen the oops.
> Subject : i915: 3.2 rc1/2 KMS regression
> Submitter : Patrik Kullman <patrik.kullman@gmail.com>
> Date : 2011-11-23 23:43
> Message-ID : CAGPN=9THOv-
> M4Td4haE94uDcsAjW3eGMG7ioLeu+p8xUOBPd7w@mail.gmail.com
> References : http://marc.info/?l=linux-kernel&m=132209186403288&w=2
Fixed by commit ed4a51842a9d which reverted the problematic commit.
> Subject : [regression] WARNING: at drivers/block/floppy.c:2929
> do_fd_request+0xb7/0xb9() in 3.2.0-rc2 and 3
> Submitter : Ralf Hildebrandt <Ralf.Hildebrandt@charite.de>
> Date : 2011-11-25 10:34
> Message-ID : 20111125103420.GO4581@charite.de
> References : http://marc.info/?l=linux-kernel&m=132221799501685&w=2
This should be fixed by commit 4eabc941259f.
I wonder if that's related to the floppy issue above? Nothing really
changed in the floppy driver itself, so it should be something about
the block layer..
> Subject : 3.2-rc2 regression due to commit "USB: EHCI: fix HUB TT scheduling
> issue with iso transfer" 811c926c538f7e8d3c08b630dd5844efd7e000f6
> Submitter : Sander Eikelenboom <linux@eikelenboom.it>
> Date : 2011-11-26 15:47
> Message-ID : 1001209018.20111126164712@eikelenboom.it
> References : http://marc.info/?l=linux-kernel&m=132232295425393&w=2
Fixed by commit e3420901eba6.
> Subject : 3.2-rc3+: [drm:i915_hangcheck_elapsed] ERROR Hangcheck timer
> elapsed... GPU hung
> Submitter : Sergei Trofimovich <slyich@gmail.com>
> Date : 2011-12-02 17:56
> Message-ID : 20111202205601.115522b1@sf.home
> References : http://marc.info/?l=linux-kernel&m=132284845705156&w=2
I think this is the same i915 issue above, fixed by the same commit
ed4a51842a9d.
> Subject : [BUG] deadlock: jfs (3.2.0-rc4-00154-g8e8da02)
> Submitter : Nico Schottelius <nico-linux-20111201@schottelius.org>
> Date : 2011-12-06 10:05
> Message-ID : 20111206100533.GB6161@schottelius.org
> References : http://marc.info/?l=linux-kernel&m=132317917827825&w=2
That's an odd bug-report. I think Nico should try to cut-and-paste
more of the relevant problem..
It's all there in the attached xz-file, but I doubt anybody followed
up on it because it's so hidden..
Unpacked, and added Dave and jfs-discussion to the cc:
[ 6281.127353] =================================
[ 6281.127355] [ INFO: inconsistent lock state ]
[ 6281.127358] 3.2.0-rc4-00154-g8e8da02 #91
[ 6281.127360] ---------------------------------
[ 6281.127363] inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-W} usage.
[ 6281.127366] kswapd0/30 [HC0[0]:SC0[0]:HE1:SE1] takes:
[ 6281.127368] (&jfs_ip->rdwrlock#2){++++?+}, at:
[<ffffffffa01958d7>] jfs_get_block+0x57/0x220 [jfs]
[ 6281.127381] {RECLAIM_FS-ON-W} state was registered at:
[ 6281.127383] [<ffffffff810a2c71>] mark_held_locks+0x61/0x140
[ 6281.127392] [<ffffffff810a3401>] lockdep_trace_alloc+0x71/0xd0
[ 6281.127399] [<ffffffff8115daed>] kmem_cache_alloc+0x2d/0x170
[ 6281.127406] [<ffffffff8124d7d6>] radix_tree_preload+0x66/0xf0
[ 6281.127414] [<ffffffff81110e93>] add_to_page_cache_locked+0x73/0x170
[ 6281.127422] [<ffffffff81110fb1>] add_to_page_cache_lru+0x21/0x50
[ 6281.127428] [<ffffffff8111112a>] do_read_cache_page+0x6a/0x170
[ 6281.127434] [<ffffffff8111127c>] read_cache_page_async+0x1c/0x20
[ 6281.127441] [<ffffffff8111128e>] read_cache_page+0xe/0x20
[ 6281.127446] [<ffffffffa01ae406>] __get_metapage+0x1c6/0x5c0 [jfs]
[ 6281.127455] [<ffffffffa01a018a>] diWrite+0xea/0x7f0 [jfs]
[ 6281.127461] [<ffffffffa01b3b04>] txCommit+0x1d4/0xe40 [jfs]
[ 6281.127468] [<ffffffffa01982e3>] jfs_unlink+0x2a3/0x390 [jfs]
[ 6281.127474] [<ffffffff8118255f>] vfs_unlink+0x9f/0x110
[ 6281.127479] [<ffffffff8118277a>] do_unlinkat+0x1aa/0x1d0
[ 6281.127482] [<ffffffff81184236>] sys_unlink+0x16/0x20
[ 6281.127486] [<ffffffff8143e202>] system_call_fastpath+0x16/0x1b
[ 6281.127491] irq event stamp: 26965295
[ 6281.127493] hardirqs last enabled at (26965295):
[<ffffffff8111a3d5>] clear_page_dirty_for_io+0x105/0x130
[ 6281.127498] hardirqs last disabled at (26965294):
[<ffffffff8111a378>] clear_page_dirty_for_io+0xa8/0x130
[ 6281.127503] softirqs last enabled at (26964300):
[<ffffffff8106cda7>] __do_softirq+0x137/0x2a0
[ 6281.127508] softirqs last disabled at (26964283):
[<ffffffff814404fc>] call_softirq+0x1c/0x30
[ 6281.127513]
[ 6281.127514] other info that might help us debug this:
[ 6281.127516] Possible unsafe locking scenario:
[ 6281.127517]
[ 6281.127518] CPU0
[ 6281.127519] ----
[ 6281.127521] lock(&jfs_ip->rdwrlock);
[ 6281.127524] <Interrupt>
[ 6281.127525] lock(&jfs_ip->rdwrlock);
[ 6281.127528]
[ 6281.127529] *** DEADLOCK ***
[ 6281.127529]
[ 6281.127531] no locks held by kswapd0/30.
[ 6281.127533]
[ 6281.127533] stack backtrace:
[ 6281.127536] Pid: 30, comm: kswapd0 Tainted: G C
3.2.0-rc4-00154-g8e8da02 #91
[ 6281.127539] Call Trace:
[ 6281.127545] [<ffffffff8143374c>] print_usage_bug.part.34+0x285/0x294
[ 6281.127552] [<ffffffff8102494f>] ? save_stack_trace+0x2f/0x50
[ 6281.127559] [<ffffffff8109ffe0>] mark_lock+0x540/0x600
[ 6281.127564] [<ffffffff8109ef60>] ?
print_irq_inversion_bug.part.31+0x1f0/0x1f0
[ 6281.127568] [<ffffffff810a0677>] __lock_acquire+0x5d7/0x1d10
[ 6281.127573] [<ffffffff81118394>] ? free_pcppages_bulk+0x34/0x430
[ 6281.127580] [<ffffffffa01958d7>] ? jfs_get_block+0x57/0x220 [jfs]
[ 6281.127584] [<ffffffff810a23a2>] lock_acquire+0x92/0x160
[ 6281.127590] [<ffffffffa01958d7>] ? jfs_get_block+0x57/0x220 [jfs]
[ 6281.127595] [<ffffffff811a5253>] ? create_empty_buffers+0x53/0xe0
[ 6281.127600] [<ffffffff8108e77f>] down_write_nested+0x2f/0x60
[ 6281.127606] [<ffffffffa01958d7>] ? jfs_get_block+0x57/0x220 [jfs]
[ 6281.127612] [<ffffffffa01958d7>] jfs_get_block+0x57/0x220 [jfs]
[ 6281.127616] [<ffffffff8143d24b>] ? _raw_spin_unlock+0x2b/0x60
[ 6281.127620] [<ffffffff811a65d1>] __block_write_full_page+0x101/0x3a0
[ 6281.127625] [<ffffffff811a5fe0>] ? block_read_full_page+0x3d0/0x3d0
[ 6281.127631] [<ffffffffa0195880>] ? jfs_writepage+0x20/0x20 [jfs]
[ 6281.127637] [<ffffffff811a6954>] block_write_full_page_endio+0xe4/0x130
[ 6281.127642] [<ffffffff811a69b5>] block_write_full_page+0x15/0x20
[ 6281.127651] [<ffffffffa0195878>] jfs_writepage+0x18/0x20 [jfs]
[ 6281.127657] [<ffffffff8112427c>] shrink_page_list+0x56c/0x980
[ 6281.127662] [<ffffffff8111e596>] ? __pagevec_release+0x26/0x40
[ 6281.127666] [<ffffffff81124ac2>] shrink_inactive_list+0x152/0x4f0
[ 6281.127670] [<ffffffff8112563c>] shrink_zone+0x47c/0x5c0
[ 6281.127673] [<ffffffff81122fef>] ? shrink_slab+0x1ff/0x380
[ 6281.127678] [<ffffffff8143945b>] ? __schedule+0x35b/0xa30
[ 6281.127682] [<ffffffff811269c5>] balance_pgdat+0x4e5/0x6d0
[ 6281.127685] [<ffffffff81126d28>] kswapd+0x178/0x440
[ 6281.127691] [<ffffffff81089840>] ? __init_waitqueue_head+0x60/0x60
[ 6281.127695] [<ffffffff81126bb0>] ? balance_pgdat+0x6d0/0x6d0
[ 6281.127699] [<ffffffff81088e97>] kthread+0xa7/0xb0
[ 6281.127703] [<ffffffff810a2efd>] ? trace_hardirqs_on+0xd/0x10
[ 6281.127707] [<ffffffff81440404>] kernel_thread_helper+0x4/0x10
[ 6281.127711] [<ffffffff8143d838>] ? retint_restore_args+0x13/0x13
[ 6281.127715] [<ffffffff81088df0>] ? __init_kthread_worker+0x70/0x70
[ 6281.127719] [<ffffffff81440400>] ? gs_change+0x13/0x13
Hmm?
Linus
^ permalink raw reply [flat|nested] 34+ messages in thread* Re: [Resend] 3.2-rc6+: Reported regressions from 3.0 and 3.1
@ 2011-12-21 2:31 ` Linus Torvalds
0 siblings, 0 replies; 34+ messages in thread
From: Linus Torvalds @ 2011-12-21 2:31 UTC (permalink / raw)
To: Rafael J. Wysocki, Dave Kleikamp,
jfs-discussion-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
Cc: Kernel Testers List, LKML, Maciej Rutecki, Andrew Morton,
Florian Mickler, davem-fT/PcQaiUtIeIZ0/mPfg9Q
On Tue, Dec 20, 2011 at 3:54 PM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
>
> Subject : Regression: "irqpoll" hasn't been working for me since March 16 IRQ
> Submitter : Edward Donovan <edward.donovan-mb/Bq7DTvoSsTnJN9+BGXg@public.gmane.org>
> Date : 2011-10-19 22:09
> Message-ID : CADdbW+HXdCPfJu2RTF6zz+ujCmiu_dmZwL2iScuF53p=AaZ1Uw@mail.gmail.com
> References : http://marc.info/?l=linux-kernel&m=131914554220679&w=2
Edward fixed this in commit 52553ddffad76ccf192d4dd9ce88d5818f57f62a.
> Subject : Linus GIT - INFO: possible circular locking dependency detected
> Submitter : Miles Lane <miles.lane-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date : 2011-11-03 15:57
> Message-ID : CAHFgRy8S0xLfhZxTUOEH5A0PL_Fb79-0-gmbQ=9h2D-xMqt1hA@mail.gmail.com
> References : http://marc.info/?l=linux-kernel&m=132033587908426&w=2
I *think* this is fixed by the revert in commit 5e442a493fc5.
> Subject : Sparc-32 doesn't work in 3.1.
> Submitter : Rob Landley <rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org>
> Date : 2011-11-12 11:22
> Message-ID : 4EBEAB5A.5020809-VoJi6FS/r0vR7s880joybQ@public.gmane.org
> References : http://www.spinics.net/lists/kernel/msg1260383.html
I'm pretty sure this is fixed by commit b1f44e13a525.
> Subject : WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
> Submitter : Markus Trippelsdorf <markus-xp2qqqlHh3xzoYq+O6RWwA@public.gmane.org>
> Date : 2011-11-18 7:25
> Message-ID : 20111118072519.GA1615-tLCgZGx+iJ+kxVt8IV0GqQ@public.gmane.org
> References : http://marc.info/?l=linux-kernel&m=132160119031794&w=2
This is a combination one, I think. There's some kexec trouble with
DRI and Radeons, and there on PPC the SLUB case was done incorrectly.
The PPC case was fixed, the DRI/Radeon/kexec thing is pending for next
release, I'm afraid.
> Subject : Bisected regression: hang on i915 between 3.1.0-rc9 and 3.1.0
> Submitter : Meelis Roos <mroos-Y27EyoLml9s@public.gmane.org>
> Date : 2011-11-22 10:15
> Message-ID : alpine.SOC.1.00.1111221207090.6490-ptEonEWSGqKptlylMvRsHA@public.gmane.org
> References : http://marc.info/?l=linux-kernel&m=132195700023709&w=2
This is i915 vs VT-d. It may be fixed in current -git, but basically
people should try to avoid using VT-d with i915, there seem to be
hardware bugs wrt the graphics semaphores and power management code.
> Subject : 3.2-rc2 regression: floppy driver breaks boot
> Submitter : Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>
> Date : 2011-11-22 11:14
> Message-ID : 20111122111405.GA28215-I/5MKhXcvmPrBKCeMvbIDA@public.gmane.org
> References : http://marc.info/?l=linux-kernel&m=132196052124801&w=2
Hmm. I'd love to get more info. Turning off floppy support may work
around it, but I don't think we've actually seen the oops.
> Subject : i915: 3.2 rc1/2 KMS regression
> Submitter : Patrik Kullman <patrik.kullman-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date : 2011-11-23 23:43
> Message-ID : CAGPN=9THOv-
> M4Td4haE94uDcsAjW3eGMG7ioLeu+p8xUOBPd7w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
> References : http://marc.info/?l=linux-kernel&m=132209186403288&w=2
Fixed by commit ed4a51842a9d which reverted the problematic commit.
> Subject : [regression] WARNING: at drivers/block/floppy.c:2929
> do_fd_request+0xb7/0xb9() in 3.2.0-rc2 and 3
> Submitter : Ralf Hildebrandt <Ralf.Hildebrandt-jq1tPX9l7E6ELgA04lAiVw@public.gmane.org>
> Date : 2011-11-25 10:34
> Message-ID : 20111125103420.GO4581-jq1tPX9l7E6ELgA04lAiVw@public.gmane.org
> References : http://marc.info/?l=linux-kernel&m=132221799501685&w=2
This should be fixed by commit 4eabc941259f.
I wonder if that's related to the floppy issue above? Nothing really
changed in the floppy driver itself, so it should be something about
the block layer..
> Subject : 3.2-rc2 regression due to commit "USB: EHCI: fix HUB TT scheduling
> issue with iso transfer" 811c926c538f7e8d3c08b630dd5844efd7e000f6
> Submitter : Sander Eikelenboom <linux-6SM94LqRVpn6gRhOQ7JHfg@public.gmane.org>
> Date : 2011-11-26 15:47
> Message-ID : 1001209018.20111126164712-6SM94LqRVpn6gRhOQ7JHfg@public.gmane.org
> References : http://marc.info/?l=linux-kernel&m=132232295425393&w=2
Fixed by commit e3420901eba6.
> Subject : 3.2-rc3+: [drm:i915_hangcheck_elapsed] ERROR Hangcheck timer
> elapsed... GPU hung
> Submitter : Sergei Trofimovich <slyich-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date : 2011-12-02 17:56
> Message-ID : 20111202205601.115522b1-rUBWEpAk+NE@public.gmane.org
> References : http://marc.info/?l=linux-kernel&m=132284845705156&w=2
I think this is the same i915 issue above, fixed by the same commit
ed4a51842a9d.
> Subject : [BUG] deadlock: jfs (3.2.0-rc4-00154-g8e8da02)
> Submitter : Nico Schottelius <nico-linux-20111201-xuaVFQXs+5hIG4jRRZ66WA@public.gmane.org>
> Date : 2011-12-06 10:05
> Message-ID : 20111206100533.GB6161-xuaVFQXs+5hIG4jRRZ66WA@public.gmane.org
> References : http://marc.info/?l=linux-kernel&m=132317917827825&w=2
That's an odd bug-report. I think Nico should try to cut-and-paste
more of the relevant problem..
It's all there in the attached xz-file, but I doubt anybody followed
up on it because it's so hidden..
Unpacked, and added Dave and jfs-discussion to the cc:
[ 6281.127353] =================================
[ 6281.127355] [ INFO: inconsistent lock state ]
[ 6281.127358] 3.2.0-rc4-00154-g8e8da02 #91
[ 6281.127360] ---------------------------------
[ 6281.127363] inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-W} usage.
[ 6281.127366] kswapd0/30 [HC0[0]:SC0[0]:HE1:SE1] takes:
[ 6281.127368] (&jfs_ip->rdwrlock#2){++++?+}, at:
[<ffffffffa01958d7>] jfs_get_block+0x57/0x220 [jfs]
[ 6281.127381] {RECLAIM_FS-ON-W} state was registered at:
[ 6281.127383] [<ffffffff810a2c71>] mark_held_locks+0x61/0x140
[ 6281.127392] [<ffffffff810a3401>] lockdep_trace_alloc+0x71/0xd0
[ 6281.127399] [<ffffffff8115daed>] kmem_cache_alloc+0x2d/0x170
[ 6281.127406] [<ffffffff8124d7d6>] radix_tree_preload+0x66/0xf0
[ 6281.127414] [<ffffffff81110e93>] add_to_page_cache_locked+0x73/0x170
[ 6281.127422] [<ffffffff81110fb1>] add_to_page_cache_lru+0x21/0x50
[ 6281.127428] [<ffffffff8111112a>] do_read_cache_page+0x6a/0x170
[ 6281.127434] [<ffffffff8111127c>] read_cache_page_async+0x1c/0x20
[ 6281.127441] [<ffffffff8111128e>] read_cache_page+0xe/0x20
[ 6281.127446] [<ffffffffa01ae406>] __get_metapage+0x1c6/0x5c0 [jfs]
[ 6281.127455] [<ffffffffa01a018a>] diWrite+0xea/0x7f0 [jfs]
[ 6281.127461] [<ffffffffa01b3b04>] txCommit+0x1d4/0xe40 [jfs]
[ 6281.127468] [<ffffffffa01982e3>] jfs_unlink+0x2a3/0x390 [jfs]
[ 6281.127474] [<ffffffff8118255f>] vfs_unlink+0x9f/0x110
[ 6281.127479] [<ffffffff8118277a>] do_unlinkat+0x1aa/0x1d0
[ 6281.127482] [<ffffffff81184236>] sys_unlink+0x16/0x20
[ 6281.127486] [<ffffffff8143e202>] system_call_fastpath+0x16/0x1b
[ 6281.127491] irq event stamp: 26965295
[ 6281.127493] hardirqs last enabled at (26965295):
[<ffffffff8111a3d5>] clear_page_dirty_for_io+0x105/0x130
[ 6281.127498] hardirqs last disabled at (26965294):
[<ffffffff8111a378>] clear_page_dirty_for_io+0xa8/0x130
[ 6281.127503] softirqs last enabled at (26964300):
[<ffffffff8106cda7>] __do_softirq+0x137/0x2a0
[ 6281.127508] softirqs last disabled at (26964283):
[<ffffffff814404fc>] call_softirq+0x1c/0x30
[ 6281.127513]
[ 6281.127514] other info that might help us debug this:
[ 6281.127516] Possible unsafe locking scenario:
[ 6281.127517]
[ 6281.127518] CPU0
[ 6281.127519] ----
[ 6281.127521] lock(&jfs_ip->rdwrlock);
[ 6281.127524] <Interrupt>
[ 6281.127525] lock(&jfs_ip->rdwrlock);
[ 6281.127528]
[ 6281.127529] *** DEADLOCK ***
[ 6281.127529]
[ 6281.127531] no locks held by kswapd0/30.
[ 6281.127533]
[ 6281.127533] stack backtrace:
[ 6281.127536] Pid: 30, comm: kswapd0 Tainted: G C
3.2.0-rc4-00154-g8e8da02 #91
[ 6281.127539] Call Trace:
[ 6281.127545] [<ffffffff8143374c>] print_usage_bug.part.34+0x285/0x294
[ 6281.127552] [<ffffffff8102494f>] ? save_stack_trace+0x2f/0x50
[ 6281.127559] [<ffffffff8109ffe0>] mark_lock+0x540/0x600
[ 6281.127564] [<ffffffff8109ef60>] ?
print_irq_inversion_bug.part.31+0x1f0/0x1f0
[ 6281.127568] [<ffffffff810a0677>] __lock_acquire+0x5d7/0x1d10
[ 6281.127573] [<ffffffff81118394>] ? free_pcppages_bulk+0x34/0x430
[ 6281.127580] [<ffffffffa01958d7>] ? jfs_get_block+0x57/0x220 [jfs]
[ 6281.127584] [<ffffffff810a23a2>] lock_acquire+0x92/0x160
[ 6281.127590] [<ffffffffa01958d7>] ? jfs_get_block+0x57/0x220 [jfs]
[ 6281.127595] [<ffffffff811a5253>] ? create_empty_buffers+0x53/0xe0
[ 6281.127600] [<ffffffff8108e77f>] down_write_nested+0x2f/0x60
[ 6281.127606] [<ffffffffa01958d7>] ? jfs_get_block+0x57/0x220 [jfs]
[ 6281.127612] [<ffffffffa01958d7>] jfs_get_block+0x57/0x220 [jfs]
[ 6281.127616] [<ffffffff8143d24b>] ? _raw_spin_unlock+0x2b/0x60
[ 6281.127620] [<ffffffff811a65d1>] __block_write_full_page+0x101/0x3a0
[ 6281.127625] [<ffffffff811a5fe0>] ? block_read_full_page+0x3d0/0x3d0
[ 6281.127631] [<ffffffffa0195880>] ? jfs_writepage+0x20/0x20 [jfs]
[ 6281.127637] [<ffffffff811a6954>] block_write_full_page_endio+0xe4/0x130
[ 6281.127642] [<ffffffff811a69b5>] block_write_full_page+0x15/0x20
[ 6281.127651] [<ffffffffa0195878>] jfs_writepage+0x18/0x20 [jfs]
[ 6281.127657] [<ffffffff8112427c>] shrink_page_list+0x56c/0x980
[ 6281.127662] [<ffffffff8111e596>] ? __pagevec_release+0x26/0x40
[ 6281.127666] [<ffffffff81124ac2>] shrink_inactive_list+0x152/0x4f0
[ 6281.127670] [<ffffffff8112563c>] shrink_zone+0x47c/0x5c0
[ 6281.127673] [<ffffffff81122fef>] ? shrink_slab+0x1ff/0x380
[ 6281.127678] [<ffffffff8143945b>] ? __schedule+0x35b/0xa30
[ 6281.127682] [<ffffffff811269c5>] balance_pgdat+0x4e5/0x6d0
[ 6281.127685] [<ffffffff81126d28>] kswapd+0x178/0x440
[ 6281.127691] [<ffffffff81089840>] ? __init_waitqueue_head+0x60/0x60
[ 6281.127695] [<ffffffff81126bb0>] ? balance_pgdat+0x6d0/0x6d0
[ 6281.127699] [<ffffffff81088e97>] kthread+0xa7/0xb0
[ 6281.127703] [<ffffffff810a2efd>] ? trace_hardirqs_on+0xd/0x10
[ 6281.127707] [<ffffffff81440404>] kernel_thread_helper+0x4/0x10
[ 6281.127711] [<ffffffff8143d838>] ? retint_restore_args+0x13/0x13
[ 6281.127715] [<ffffffff81088df0>] ? __init_kthread_worker+0x70/0x70
[ 6281.127719] [<ffffffff81440400>] ? gs_change+0x13/0x13
Hmm?
Linus
^ permalink raw reply [flat|nested] 34+ messages in thread* Re: [Resend] 3.2-rc6+: Reported regressions from 3.0 and 3.1
@ 2011-12-21 4:23 ` Dave Kleikamp
0 siblings, 0 replies; 34+ messages in thread
From: Dave Kleikamp @ 2011-12-21 4:23 UTC (permalink / raw)
To: Linus Torvalds
Cc: Rafael J. Wysocki, Dave Kleikamp, jfs-discussion,
Kernel Testers List, LKML, Maciej Rutecki, Andrew Morton,
Florian Mickler, davem
On 12/20/2011 08:31 PM, Linus Torvalds wrote:
> On Tue, Dec 20, 2011 at 3:54 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>> Subject : [BUG] deadlock: jfs (3.2.0-rc4-00154-g8e8da02)
>> Submitter : Nico Schottelius <nico-linux-20111201@schottelius.org>
>> Date : 2011-12-06 10:05
>> Message-ID : 20111206100533.GB6161@schottelius.org
>> References : http://marc.info/?l=linux-kernel&m=132317917827825&w=2
>
> That's an odd bug-report. I think Nico should try to cut-and-paste
> more of the relevant problem..
>
> It's all there in the attached xz-file, but I doubt anybody followed
> up on it because it's so hidden..
>
> Unpacked, and added Dave and jfs-discussion to the cc:
>
> [ 6281.127353] =================================
> [ 6281.127355] [ INFO: inconsistent lock state ]
> [ 6281.127358] 3.2.0-rc4-00154-g8e8da02 #91
> [ 6281.127360] ---------------------------------
> [ 6281.127363] inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-W} usage.
> [ 6281.127366] kswapd0/30 [HC0[0]:SC0[0]:HE1:SE1] takes:
> [ 6281.127368] (&jfs_ip->rdwrlock#2){++++?+}, at:
> [<ffffffffa01958d7>] jfs_get_block+0x57/0x220 [jfs]
> [ 6281.127381] {RECLAIM_FS-ON-W} state was registered at:
> [ 6281.127383] [<ffffffff810a2c71>] mark_held_locks+0x61/0x140
> [ 6281.127392] [<ffffffff810a3401>] lockdep_trace_alloc+0x71/0xd0
> [ 6281.127399] [<ffffffff8115daed>] kmem_cache_alloc+0x2d/0x170
> [ 6281.127406] [<ffffffff8124d7d6>] radix_tree_preload+0x66/0xf0
> [ 6281.127414] [<ffffffff81110e93>] add_to_page_cache_locked+0x73/0x170
> [ 6281.127422] [<ffffffff81110fb1>] add_to_page_cache_lru+0x21/0x50
> [ 6281.127428] [<ffffffff8111112a>] do_read_cache_page+0x6a/0x170
> [ 6281.127434] [<ffffffff8111127c>] read_cache_page_async+0x1c/0x20
> [ 6281.127441] [<ffffffff8111128e>] read_cache_page+0xe/0x20
> [ 6281.127446] [<ffffffffa01ae406>] __get_metapage+0x1c6/0x5c0 [jfs]
> [ 6281.127455] [<ffffffffa01a018a>] diWrite+0xea/0x7f0 [jfs]
> [ 6281.127461] [<ffffffffa01b3b04>] txCommit+0x1d4/0xe40 [jfs]
> [ 6281.127468] [<ffffffffa01982e3>] jfs_unlink+0x2a3/0x390 [jfs]
> [ 6281.127474] [<ffffffff8118255f>] vfs_unlink+0x9f/0x110
> [ 6281.127479] [<ffffffff8118277a>] do_unlinkat+0x1aa/0x1d0
> [ 6281.127482] [<ffffffff81184236>] sys_unlink+0x16/0x20
> [ 6281.127486] [<ffffffff8143e202>] system_call_fastpath+0x16/0x1b
> [ 6281.127491] irq event stamp: 26965295
> [ 6281.127493] hardirqs last enabled at (26965295):
> [<ffffffff8111a3d5>] clear_page_dirty_for_io+0x105/0x130
> [ 6281.127498] hardirqs last disabled at (26965294):
> [<ffffffff8111a378>] clear_page_dirty_for_io+0xa8/0x130
> [ 6281.127503] softirqs last enabled at (26964300):
> [<ffffffff8106cda7>] __do_softirq+0x137/0x2a0
> [ 6281.127508] softirqs last disabled at (26964283):
> [<ffffffff814404fc>] call_softirq+0x1c/0x30
> [ 6281.127513]
> [ 6281.127514] other info that might help us debug this:
> [ 6281.127516] Possible unsafe locking scenario:
> [ 6281.127517]
> [ 6281.127518] CPU0
> [ 6281.127519] ----
> [ 6281.127521] lock(&jfs_ip->rdwrlock);
> [ 6281.127524] <Interrupt>
> [ 6281.127525] lock(&jfs_ip->rdwrlock);
> [ 6281.127528]
> [ 6281.127529] *** DEADLOCK ***
> [ 6281.127529]
> [ 6281.127531] no locks held by kswapd0/30.
> [ 6281.127533]
> [ 6281.127533] stack backtrace:
> [ 6281.127536] Pid: 30, comm: kswapd0 Tainted: G C
> 3.2.0-rc4-00154-g8e8da02 #91
> [ 6281.127539] Call Trace:
> [ 6281.127545] [<ffffffff8143374c>] print_usage_bug.part.34+0x285/0x294
> [ 6281.127552] [<ffffffff8102494f>] ? save_stack_trace+0x2f/0x50
> [ 6281.127559] [<ffffffff8109ffe0>] mark_lock+0x540/0x600
> [ 6281.127564] [<ffffffff8109ef60>] ?
> print_irq_inversion_bug.part.31+0x1f0/0x1f0
> [ 6281.127568] [<ffffffff810a0677>] __lock_acquire+0x5d7/0x1d10
> [ 6281.127573] [<ffffffff81118394>] ? free_pcppages_bulk+0x34/0x430
> [ 6281.127580] [<ffffffffa01958d7>] ? jfs_get_block+0x57/0x220 [jfs]
> [ 6281.127584] [<ffffffff810a23a2>] lock_acquire+0x92/0x160
> [ 6281.127590] [<ffffffffa01958d7>] ? jfs_get_block+0x57/0x220 [jfs]
> [ 6281.127595] [<ffffffff811a5253>] ? create_empty_buffers+0x53/0xe0
> [ 6281.127600] [<ffffffff8108e77f>] down_write_nested+0x2f/0x60
> [ 6281.127606] [<ffffffffa01958d7>] ? jfs_get_block+0x57/0x220 [jfs]
> [ 6281.127612] [<ffffffffa01958d7>] jfs_get_block+0x57/0x220 [jfs]
> [ 6281.127616] [<ffffffff8143d24b>] ? _raw_spin_unlock+0x2b/0x60
> [ 6281.127620] [<ffffffff811a65d1>] __block_write_full_page+0x101/0x3a0
> [ 6281.127625] [<ffffffff811a5fe0>] ? block_read_full_page+0x3d0/0x3d0
> [ 6281.127631] [<ffffffffa0195880>] ? jfs_writepage+0x20/0x20 [jfs]
> [ 6281.127637] [<ffffffff811a6954>] block_write_full_page_endio+0xe4/0x130
> [ 6281.127642] [<ffffffff811a69b5>] block_write_full_page+0x15/0x20
> [ 6281.127651] [<ffffffffa0195878>] jfs_writepage+0x18/0x20 [jfs]
> [ 6281.127657] [<ffffffff8112427c>] shrink_page_list+0x56c/0x980
> [ 6281.127662] [<ffffffff8111e596>] ? __pagevec_release+0x26/0x40
> [ 6281.127666] [<ffffffff81124ac2>] shrink_inactive_list+0x152/0x4f0
> [ 6281.127670] [<ffffffff8112563c>] shrink_zone+0x47c/0x5c0
> [ 6281.127673] [<ffffffff81122fef>] ? shrink_slab+0x1ff/0x380
> [ 6281.127678] [<ffffffff8143945b>] ? __schedule+0x35b/0xa30
> [ 6281.127682] [<ffffffff811269c5>] balance_pgdat+0x4e5/0x6d0
> [ 6281.127685] [<ffffffff81126d28>] kswapd+0x178/0x440
> [ 6281.127691] [<ffffffff81089840>] ? __init_waitqueue_head+0x60/0x60
> [ 6281.127695] [<ffffffff81126bb0>] ? balance_pgdat+0x6d0/0x6d0
> [ 6281.127699] [<ffffffff81088e97>] kthread+0xa7/0xb0
> [ 6281.127703] [<ffffffff810a2efd>] ? trace_hardirqs_on+0xd/0x10
> [ 6281.127707] [<ffffffff81440404>] kernel_thread_helper+0x4/0x10
> [ 6281.127711] [<ffffffff8143d838>] ? retint_restore_args+0x13/0x13
> [ 6281.127715] [<ffffffff81088df0>] ? __init_kthread_worker+0x70/0x70
> [ 6281.127719] [<ffffffff81440400>] ? gs_change+0x13/0x13
>
> Hmm?
>
> Linus
I don't think this is a regression. It's been seen before, but the
patch never got submitted, or was lost somewhere. I believe this
will fix it.
vfs: __read_cache_page should use gfp argument rather than GFP_KERNEL
lockdep reports a deadlock in jfs because a special inode's rw semaphore
is taken recursively. The mapping's gfp mask is GFP_NOFS, but is not used
when __read_cache_page() calls add_to_page_cache_lru().
Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
diff --git a/mm/filemap.c b/mm/filemap.c
index c106d3b..c9ea3df 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -1828,7 +1828,7 @@ repeat:
page = __page_cache_alloc(gfp | __GFP_COLD);
if (!page)
return ERR_PTR(-ENOMEM);
- err = add_to_page_cache_lru(page, mapping, index, GFP_KERNEL);
+ err = add_to_page_cache_lru(page, mapping, index, gfp);
if (unlikely(err)) {
page_cache_release(page);
if (err == -EEXIST)
^ permalink raw reply related [flat|nested] 34+ messages in thread* Re: [Resend] 3.2-rc6+: Reported regressions from 3.0 and 3.1
@ 2011-12-21 4:23 ` Dave Kleikamp
0 siblings, 0 replies; 34+ messages in thread
From: Dave Kleikamp @ 2011-12-21 4:23 UTC (permalink / raw)
To: Linus Torvalds
Cc: Rafael J. Wysocki, Dave Kleikamp,
jfs-discussion-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
Kernel Testers List, LKML, Maciej Rutecki, Andrew Morton,
Florian Mickler, davem-fT/PcQaiUtIeIZ0/mPfg9Q
On 12/20/2011 08:31 PM, Linus Torvalds wrote:
> On Tue, Dec 20, 2011 at 3:54 PM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
>> Subject : [BUG] deadlock: jfs (3.2.0-rc4-00154-g8e8da02)
>> Submitter : Nico Schottelius <nico-linux-20111201-xuaVFQXs+5hIG4jRRZ66WA@public.gmane.org>
>> Date : 2011-12-06 10:05
>> Message-ID : 20111206100533.GB6161-xuaVFQXs+5hIG4jRRZ66WA@public.gmane.org
>> References : http://marc.info/?l=linux-kernel&m=132317917827825&w=2
>
> That's an odd bug-report. I think Nico should try to cut-and-paste
> more of the relevant problem..
>
> It's all there in the attached xz-file, but I doubt anybody followed
> up on it because it's so hidden..
>
> Unpacked, and added Dave and jfs-discussion to the cc:
>
> [ 6281.127353] =================================
> [ 6281.127355] [ INFO: inconsistent lock state ]
> [ 6281.127358] 3.2.0-rc4-00154-g8e8da02 #91
> [ 6281.127360] ---------------------------------
> [ 6281.127363] inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-W} usage.
> [ 6281.127366] kswapd0/30 [HC0[0]:SC0[0]:HE1:SE1] takes:
> [ 6281.127368] (&jfs_ip->rdwrlock#2){++++?+}, at:
> [<ffffffffa01958d7>] jfs_get_block+0x57/0x220 [jfs]
> [ 6281.127381] {RECLAIM_FS-ON-W} state was registered at:
> [ 6281.127383] [<ffffffff810a2c71>] mark_held_locks+0x61/0x140
> [ 6281.127392] [<ffffffff810a3401>] lockdep_trace_alloc+0x71/0xd0
> [ 6281.127399] [<ffffffff8115daed>] kmem_cache_alloc+0x2d/0x170
> [ 6281.127406] [<ffffffff8124d7d6>] radix_tree_preload+0x66/0xf0
> [ 6281.127414] [<ffffffff81110e93>] add_to_page_cache_locked+0x73/0x170
> [ 6281.127422] [<ffffffff81110fb1>] add_to_page_cache_lru+0x21/0x50
> [ 6281.127428] [<ffffffff8111112a>] do_read_cache_page+0x6a/0x170
> [ 6281.127434] [<ffffffff8111127c>] read_cache_page_async+0x1c/0x20
> [ 6281.127441] [<ffffffff8111128e>] read_cache_page+0xe/0x20
> [ 6281.127446] [<ffffffffa01ae406>] __get_metapage+0x1c6/0x5c0 [jfs]
> [ 6281.127455] [<ffffffffa01a018a>] diWrite+0xea/0x7f0 [jfs]
> [ 6281.127461] [<ffffffffa01b3b04>] txCommit+0x1d4/0xe40 [jfs]
> [ 6281.127468] [<ffffffffa01982e3>] jfs_unlink+0x2a3/0x390 [jfs]
> [ 6281.127474] [<ffffffff8118255f>] vfs_unlink+0x9f/0x110
> [ 6281.127479] [<ffffffff8118277a>] do_unlinkat+0x1aa/0x1d0
> [ 6281.127482] [<ffffffff81184236>] sys_unlink+0x16/0x20
> [ 6281.127486] [<ffffffff8143e202>] system_call_fastpath+0x16/0x1b
> [ 6281.127491] irq event stamp: 26965295
> [ 6281.127493] hardirqs last enabled at (26965295):
> [<ffffffff8111a3d5>] clear_page_dirty_for_io+0x105/0x130
> [ 6281.127498] hardirqs last disabled at (26965294):
> [<ffffffff8111a378>] clear_page_dirty_for_io+0xa8/0x130
> [ 6281.127503] softirqs last enabled at (26964300):
> [<ffffffff8106cda7>] __do_softirq+0x137/0x2a0
> [ 6281.127508] softirqs last disabled at (26964283):
> [<ffffffff814404fc>] call_softirq+0x1c/0x30
> [ 6281.127513]
> [ 6281.127514] other info that might help us debug this:
> [ 6281.127516] Possible unsafe locking scenario:
> [ 6281.127517]
> [ 6281.127518] CPU0
> [ 6281.127519] ----
> [ 6281.127521] lock(&jfs_ip->rdwrlock);
> [ 6281.127524] <Interrupt>
> [ 6281.127525] lock(&jfs_ip->rdwrlock);
> [ 6281.127528]
> [ 6281.127529] *** DEADLOCK ***
> [ 6281.127529]
> [ 6281.127531] no locks held by kswapd0/30.
> [ 6281.127533]
> [ 6281.127533] stack backtrace:
> [ 6281.127536] Pid: 30, comm: kswapd0 Tainted: G C
> 3.2.0-rc4-00154-g8e8da02 #91
> [ 6281.127539] Call Trace:
> [ 6281.127545] [<ffffffff8143374c>] print_usage_bug.part.34+0x285/0x294
> [ 6281.127552] [<ffffffff8102494f>] ? save_stack_trace+0x2f/0x50
> [ 6281.127559] [<ffffffff8109ffe0>] mark_lock+0x540/0x600
> [ 6281.127564] [<ffffffff8109ef60>] ?
> print_irq_inversion_bug.part.31+0x1f0/0x1f0
> [ 6281.127568] [<ffffffff810a0677>] __lock_acquire+0x5d7/0x1d10
> [ 6281.127573] [<ffffffff81118394>] ? free_pcppages_bulk+0x34/0x430
> [ 6281.127580] [<ffffffffa01958d7>] ? jfs_get_block+0x57/0x220 [jfs]
> [ 6281.127584] [<ffffffff810a23a2>] lock_acquire+0x92/0x160
> [ 6281.127590] [<ffffffffa01958d7>] ? jfs_get_block+0x57/0x220 [jfs]
> [ 6281.127595] [<ffffffff811a5253>] ? create_empty_buffers+0x53/0xe0
> [ 6281.127600] [<ffffffff8108e77f>] down_write_nested+0x2f/0x60
> [ 6281.127606] [<ffffffffa01958d7>] ? jfs_get_block+0x57/0x220 [jfs]
> [ 6281.127612] [<ffffffffa01958d7>] jfs_get_block+0x57/0x220 [jfs]
> [ 6281.127616] [<ffffffff8143d24b>] ? _raw_spin_unlock+0x2b/0x60
> [ 6281.127620] [<ffffffff811a65d1>] __block_write_full_page+0x101/0x3a0
> [ 6281.127625] [<ffffffff811a5fe0>] ? block_read_full_page+0x3d0/0x3d0
> [ 6281.127631] [<ffffffffa0195880>] ? jfs_writepage+0x20/0x20 [jfs]
> [ 6281.127637] [<ffffffff811a6954>] block_write_full_page_endio+0xe4/0x130
> [ 6281.127642] [<ffffffff811a69b5>] block_write_full_page+0x15/0x20
> [ 6281.127651] [<ffffffffa0195878>] jfs_writepage+0x18/0x20 [jfs]
> [ 6281.127657] [<ffffffff8112427c>] shrink_page_list+0x56c/0x980
> [ 6281.127662] [<ffffffff8111e596>] ? __pagevec_release+0x26/0x40
> [ 6281.127666] [<ffffffff81124ac2>] shrink_inactive_list+0x152/0x4f0
> [ 6281.127670] [<ffffffff8112563c>] shrink_zone+0x47c/0x5c0
> [ 6281.127673] [<ffffffff81122fef>] ? shrink_slab+0x1ff/0x380
> [ 6281.127678] [<ffffffff8143945b>] ? __schedule+0x35b/0xa30
> [ 6281.127682] [<ffffffff811269c5>] balance_pgdat+0x4e5/0x6d0
> [ 6281.127685] [<ffffffff81126d28>] kswapd+0x178/0x440
> [ 6281.127691] [<ffffffff81089840>] ? __init_waitqueue_head+0x60/0x60
> [ 6281.127695] [<ffffffff81126bb0>] ? balance_pgdat+0x6d0/0x6d0
> [ 6281.127699] [<ffffffff81088e97>] kthread+0xa7/0xb0
> [ 6281.127703] [<ffffffff810a2efd>] ? trace_hardirqs_on+0xd/0x10
> [ 6281.127707] [<ffffffff81440404>] kernel_thread_helper+0x4/0x10
> [ 6281.127711] [<ffffffff8143d838>] ? retint_restore_args+0x13/0x13
> [ 6281.127715] [<ffffffff81088df0>] ? __init_kthread_worker+0x70/0x70
> [ 6281.127719] [<ffffffff81440400>] ? gs_change+0x13/0x13
>
> Hmm?
>
> Linus
I don't think this is a regression. It's been seen before, but the
patch never got submitted, or was lost somewhere. I believe this
will fix it.
vfs: __read_cache_page should use gfp argument rather than GFP_KERNEL
lockdep reports a deadlock in jfs because a special inode's rw semaphore
is taken recursively. The mapping's gfp mask is GFP_NOFS, but is not used
when __read_cache_page() calls add_to_page_cache_lru().
Signed-off-by: Dave Kleikamp <dave.kleikamp-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
diff --git a/mm/filemap.c b/mm/filemap.c
index c106d3b..c9ea3df 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -1828,7 +1828,7 @@ repeat:
page = __page_cache_alloc(gfp | __GFP_COLD);
if (!page)
return ERR_PTR(-ENOMEM);
- err = add_to_page_cache_lru(page, mapping, index, GFP_KERNEL);
+ err = add_to_page_cache_lru(page, mapping, index, gfp);
if (unlikely(err)) {
page_cache_release(page);
if (err == -EEXIST)
^ permalink raw reply related [flat|nested] 34+ messages in thread* Re: [Resend] 3.2-rc6+: Reported regressions from 3.0 and 3.1
2011-12-21 4:23 ` Dave Kleikamp
(?)
@ 2011-12-21 4:44 ` Linus Torvalds
-1 siblings, 0 replies; 34+ messages in thread
From: Linus Torvalds @ 2011-12-21 4:44 UTC (permalink / raw)
To: Dave Kleikamp
Cc: Rafael J. Wysocki, Dave Kleikamp, jfs-discussion,
Kernel Testers List, LKML, Maciej Rutecki, Andrew Morton,
Florian Mickler, davem, Hugh Dickins, Al Viro, linux-mm
On Tue, Dec 20, 2011 at 8:23 PM, Dave Kleikamp <dave.kleikamp@oracle.com> wrote:
>
> I don't think this is a regression. It's been seen before, but the
> patch never got submitted, or was lost somewhere. I believe this
> will fix it.
Hmm. This patch looks obviously correct. But it looks *so* obviously
correct that it just makes me suspicious - this is not new or seldom
used code, it's been this way for ages and used all the time. That
line literally goes back to 2007, commit eb2be189317d0. And it looks
like even before that we had a GFP_KERNEL for the add_to_page_cache()
case and that goes back to before the git history. So this is
*ancient*.
Maybe almost nobody uses __read_cache_page() with a non-GFP_KERNEL gfp
and as a result we've not noticed.
Or maybe there is some crazy reason why it calls "add_to_page_cache()"
with GFP_KERNEL.
Adding the usual suspects for mm/filemap.c to the cc line (Andrew is
already cc'd, but Al and Hugh should comment).
Ack's, people? Is it really as obvious as it looks, and we've just had
this bug forever?
Linus
--- snip snip ---
> vfs: __read_cache_page should use gfp argument rather than GFP_KERNEL
>
> lockdep reports a deadlock in jfs because a special inode's rw semaphore
> is taken recursively. The mapping's gfp mask is GFP_NOFS, but is not used
> when __read_cache_page() calls add_to_page_cache_lru().
>
> Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
>
> diff --git a/mm/filemap.c b/mm/filemap.c
> index c106d3b..c9ea3df 100644
> --- a/mm/filemap.c
> +++ b/mm/filemap.c
> @@ -1828,7 +1828,7 @@ repeat:
> page = __page_cache_alloc(gfp | __GFP_COLD);
> if (!page)
> return ERR_PTR(-ENOMEM);
> - err = add_to_page_cache_lru(page, mapping, index, GFP_KERNEL);
> + err = add_to_page_cache_lru(page, mapping, index, gfp);
> if (unlikely(err)) {
> page_cache_release(page);
> if (err == -EEXIST)
^ permalink raw reply [flat|nested] 34+ messages in thread* Re: [Resend] 3.2-rc6+: Reported regressions from 3.0 and 3.1
@ 2011-12-21 4:44 ` Linus Torvalds
0 siblings, 0 replies; 34+ messages in thread
From: Linus Torvalds @ 2011-12-21 4:44 UTC (permalink / raw)
To: Dave Kleikamp
Cc: Rafael J. Wysocki, Dave Kleikamp,
jfs-discussion-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
Kernel Testers List, LKML, Maciej Rutecki, Andrew Morton,
Florian Mickler, davem-fT/PcQaiUtIeIZ0/mPfg9Q, Hugh Dickins,
Al Viro, linux-mm-Bw31MaZKKs3YtjvyW6yDsg
On Tue, Dec 20, 2011 at 8:23 PM, Dave Kleikamp <dave.kleikamp-QHcLZuEGTsthl2p70BpVqQ@public.gmane.orgm> wrote:
>
> I don't think this is a regression. It's been seen before, but the
> patch never got submitted, or was lost somewhere. I believe this
> will fix it.
Hmm. This patch looks obviously correct. But it looks *so* obviously
correct that it just makes me suspicious - this is not new or seldom
used code, it's been this way for ages and used all the time. That
line literally goes back to 2007, commit eb2be189317d0. And it looks
like even before that we had a GFP_KERNEL for the add_to_page_cache()
case and that goes back to before the git history. So this is
*ancient*.
Maybe almost nobody uses __read_cache_page() with a non-GFP_KERNEL gfp
and as a result we've not noticed.
Or maybe there is some crazy reason why it calls "add_to_page_cache()"
with GFP_KERNEL.
Adding the usual suspects for mm/filemap.c to the cc line (Andrew is
already cc'd, but Al and Hugh should comment).
Ack's, people? Is it really as obvious as it looks, and we've just had
this bug forever?
Linus
--- snip snip ---
> vfs: __read_cache_page should use gfp argument rather than GFP_KERNEL
>
> lockdep reports a deadlock in jfs because a special inode's rw semaphore
> is taken recursively. The mapping's gfp mask is GFP_NOFS, but is not used
> when __read_cache_page() calls add_to_page_cache_lru().
>
> Signed-off-by: Dave Kleikamp <dave.kleikamp-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
>
> diff --git a/mm/filemap.c b/mm/filemap.c
> index c106d3b..c9ea3df 100644
> --- a/mm/filemap.c
> +++ b/mm/filemap.c
> @@ -1828,7 +1828,7 @@ repeat:
> page = __page_cache_alloc(gfp | __GFP_COLD);
> if (!page)
> return ERR_PTR(-ENOMEM);
> - err = add_to_page_cache_lru(page, mapping, index, GFP_KERNEL);
> + err = add_to_page_cache_lru(page, mapping, index, gfp);
> if (unlikely(err)) {
> page_cache_release(page);
> if (err == -EEXIST)
^ permalink raw reply [flat|nested] 34+ messages in thread* Re: [Resend] 3.2-rc6+: Reported regressions from 3.0 and 3.1
@ 2011-12-21 4:44 ` Linus Torvalds
0 siblings, 0 replies; 34+ messages in thread
From: Linus Torvalds @ 2011-12-21 4:44 UTC (permalink / raw)
To: Dave Kleikamp
Cc: Rafael J. Wysocki, Dave Kleikamp, jfs-discussion,
Kernel Testers List, LKML, Maciej Rutecki, Andrew Morton,
Florian Mickler, davem, Hugh Dickins, Al Viro, linux-mm
On Tue, Dec 20, 2011 at 8:23 PM, Dave Kleikamp <dave.kleikamp@oracle.com> wrote:
>
> I don't think this is a regression. It's been seen before, but the
> patch never got submitted, or was lost somewhere. I believe this
> will fix it.
Hmm. This patch looks obviously correct. But it looks *so* obviously
correct that it just makes me suspicious - this is not new or seldom
used code, it's been this way for ages and used all the time. That
line literally goes back to 2007, commit eb2be189317d0. And it looks
like even before that we had a GFP_KERNEL for the add_to_page_cache()
case and that goes back to before the git history. So this is
*ancient*.
Maybe almost nobody uses __read_cache_page() with a non-GFP_KERNEL gfp
and as a result we've not noticed.
Or maybe there is some crazy reason why it calls "add_to_page_cache()"
with GFP_KERNEL.
Adding the usual suspects for mm/filemap.c to the cc line (Andrew is
already cc'd, but Al and Hugh should comment).
Ack's, people? Is it really as obvious as it looks, and we've just had
this bug forever?
Linus
--- snip snip ---
> vfs: __read_cache_page should use gfp argument rather than GFP_KERNEL
>
> lockdep reports a deadlock in jfs because a special inode's rw semaphore
> is taken recursively. The mapping's gfp mask is GFP_NOFS, but is not used
> when __read_cache_page() calls add_to_page_cache_lru().
>
> Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
>
> diff --git a/mm/filemap.c b/mm/filemap.c
> index c106d3b..c9ea3df 100644
> --- a/mm/filemap.c
> +++ b/mm/filemap.c
> @@ -1828,7 +1828,7 @@ repeat:
> page = __page_cache_alloc(gfp | __GFP_COLD);
> if (!page)
> return ERR_PTR(-ENOMEM);
> - err = add_to_page_cache_lru(page, mapping, index, GFP_KERNEL);
> + err = add_to_page_cache_lru(page, mapping, index, gfp);
> if (unlikely(err)) {
> page_cache_release(page);
> if (err == -EEXIST)
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 34+ messages in thread* Re: [Resend] 3.2-rc6+: Reported regressions from 3.0 and 3.1
2011-12-21 4:44 ` Linus Torvalds
(?)
(?)
@ 2011-12-21 6:15 ` Hugh Dickins
2011-12-21 7:10 ` Al Viro
2011-12-21 17:05 ` Dave Kleikamp
-1 siblings, 2 replies; 34+ messages in thread
From: Hugh Dickins @ 2011-12-21 6:15 UTC (permalink / raw)
To: Linus Torvalds
Cc: Dave Kleikamp, Rafael J. Wysocki, Dave Kleikamp, jfs-discussion,
Kernel Testers List, LKML, Maciej Rutecki, Andrew Morton,
Florian Mickler, davem, Al Viro, linux-mm
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2927 bytes --]
On Tue, 20 Dec 2011, Linus Torvalds wrote:
> On Tue, Dec 20, 2011 at 8:23 PM, Dave Kleikamp <dave.kleikamp@oracle.com> wrote:
> >
> > I don't think this is a regression. It's been seen before, but the
> > patch never got submitted, or was lost somewhere. I believe this
> > will fix it.
>
> Hmm. This patch looks obviously correct. But it looks *so* obviously
> correct that it just makes me suspicious - this is not new or seldom
> used code, it's been this way for ages and used all the time. That
> line literally goes back to 2007, commit eb2be189317d0. And it looks
> like even before that we had a GFP_KERNEL for the add_to_page_cache()
> case and that goes back to before the git history. So this is
> *ancient*.
>
> Maybe almost nobody uses __read_cache_page() with a non-GFP_KERNEL gfp
> and as a result we've not noticed.
>
> Or maybe there is some crazy reason why it calls "add_to_page_cache()"
> with GFP_KERNEL.
>
> Adding the usual suspects for mm/filemap.c to the cc line (Andrew is
> already cc'd, but Al and Hugh should comment).
>
> Ack's, people? Is it really as obvious as it looks, and we've just had
> this bug forever?
Certainly
Acked-by: Hugh Dickins <hughd@google.com>
from me (and add_to_page_cache_locked does the masking of inappropriate
bits when passing on down, so no need to worry about that aspect).
I agree that it's odd that we've never noticed it before, but I don't
think the GFP_KERNEL there has any more significance than oversight.
Nick cleaned up some similar instances in filemap.c a few years back,
I guess ones he hit in testing, but this just got left over.
page_cache_read()'s GFP_KERNEL looks similarly worrying, but as it's
only called by filemap_fault(), I suppose it's actually okay.
Ooh, maybe you should also update that comment on GFP_KERNEL above
read_cache_page_gfp()...
Hugh
>
> Linus
>
> --- snip snip ---
> > vfs: __read_cache_page should use gfp argument rather than GFP_KERNEL
> >
> > lockdep reports a deadlock in jfs because a special inode's rw semaphore
> > is taken recursively. The mapping's gfp mask is GFP_NOFS, but is not used
> > when __read_cache_page() calls add_to_page_cache_lru().
> >
> > Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
> >
> > diff --git a/mm/filemap.c b/mm/filemap.c
> > index c106d3b..c9ea3df 100644
> > --- a/mm/filemap.c
> > +++ b/mm/filemap.c
> > @@ -1828,7 +1828,7 @@ repeat:
> > page = __page_cache_alloc(gfp | __GFP_COLD);
> > if (!page)
> > return ERR_PTR(-ENOMEM);
> > - err = add_to_page_cache_lru(page, mapping, index, GFP_KERNEL);
> > + err = add_to_page_cache_lru(page, mapping, index, gfp);
> > if (unlikely(err)) {
> > page_cache_release(page);
> > if (err == -EEXIST)
^ permalink raw reply [flat|nested] 34+ messages in thread* Re: [Resend] 3.2-rc6+: Reported regressions from 3.0 and 3.1
2011-12-21 6:15 ` Hugh Dickins
2011-12-21 7:10 ` Al Viro
@ 2011-12-21 7:10 ` Al Viro
1 sibling, 0 replies; 34+ messages in thread
From: Al Viro @ 2011-12-21 7:10 UTC (permalink / raw)
To: Hugh Dickins
Cc: Linus Torvalds, Dave Kleikamp, Rafael J. Wysocki, Dave Kleikamp,
jfs-discussion, Kernel Testers List, LKML, Maciej Rutecki,
Andrew Morton, Florian Mickler, davem, linux-mm
On Tue, Dec 20, 2011 at 10:15:00PM -0800, Hugh Dickins wrote:
> Acked-by: Hugh Dickins <hughd@google.com>
>
> from me (and add_to_page_cache_locked does the masking of inappropriate
> bits when passing on down, so no need to worry about that aspect).
I was grepping for possibilities of that hitting us right now... OK,
rigth you are.
Acked-by: Al Viro <viro@zeniv.linux.org.uk>
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Resend] 3.2-rc6+: Reported regressions from 3.0 and 3.1
@ 2011-12-21 7:10 ` Al Viro
0 siblings, 0 replies; 34+ messages in thread
From: Al Viro @ 2011-12-21 7:10 UTC (permalink / raw)
To: Hugh Dickins
Cc: Linus Torvalds, Dave Kleikamp, Rafael J. Wysocki, Dave Kleikamp,
jfs-discussion-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
Kernel Testers List, LKML, Maciej Rutecki, Andrew Morton,
Florian Mickler, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg
On Tue, Dec 20, 2011 at 10:15:00PM -0800, Hugh Dickins wrote:
> Acked-by: Hugh Dickins <hughd-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
>
> from me (and add_to_page_cache_locked does the masking of inappropriate
> bits when passing on down, so no need to worry about that aspect).
I was grepping for possibilities of that hitting us right now... OK,
rigth you are.
Acked-by: Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Resend] 3.2-rc6+: Reported regressions from 3.0 and 3.1
@ 2011-12-21 7:10 ` Al Viro
0 siblings, 0 replies; 34+ messages in thread
From: Al Viro @ 2011-12-21 7:10 UTC (permalink / raw)
To: Hugh Dickins
Cc: Linus Torvalds, Dave Kleikamp, Rafael J. Wysocki, Dave Kleikamp,
jfs-discussion, Kernel Testers List, LKML, Maciej Rutecki,
Andrew Morton, Florian Mickler, davem, linux-mm
On Tue, Dec 20, 2011 at 10:15:00PM -0800, Hugh Dickins wrote:
> Acked-by: Hugh Dickins <hughd@google.com>
>
> from me (and add_to_page_cache_locked does the masking of inappropriate
> bits when passing on down, so no need to worry about that aspect).
I was grepping for possibilities of that hitting us right now... OK,
rigth you are.
Acked-by: Al Viro <viro@zeniv.linux.org.uk>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v2] vfs: __read_cache_page should use gfp argument rather than GFP_KERNEL
2011-12-21 6:15 ` Hugh Dickins
@ 2011-12-21 17:05 ` Dave Kleikamp
2011-12-21 17:05 ` Dave Kleikamp
1 sibling, 0 replies; 34+ messages in thread
From: Dave Kleikamp @ 2011-12-21 17:05 UTC (permalink / raw)
To: Hugh Dickins
Cc: Linus Torvalds, Rafael J. Wysocki, jfs-discussion,
Kernel Testers List, LKML, Maciej Rutecki, Andrew Morton,
Florian Mickler, davem, Al Viro, linux-mm
[ updated to remove now-obsolete comment in read_cache_page_gfp()]
lockdep reports a deadlock in jfs because a special inode's rw semaphore
is taken recursively. The mapping's gfp mask is GFP_NOFS, but is not used
when __read_cache_page() calls add_to_page_cache_lru().
Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
Acked-by: Hugh Dickins <hughd@google.com>
Acked-by: Al Viro <viro@zeniv.linux.org.uk>
diff --git a/mm/filemap.c b/mm/filemap.c
index c106d3b..5f0a3c9 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -1828,7 +1828,7 @@ repeat:
page = __page_cache_alloc(gfp | __GFP_COLD);
if (!page)
return ERR_PTR(-ENOMEM);
- err = add_to_page_cache_lru(page, mapping, index, GFP_KERNEL);
+ err = add_to_page_cache_lru(page, mapping, index, gfp);
if (unlikely(err)) {
page_cache_release(page);
if (err == -EEXIST)
@@ -1925,10 +1925,7 @@ static struct page *wait_on_page_read(struct page *page)
* @gfp: the page allocator flags to use if allocating
*
* This is the same as "read_mapping_page(mapping, index, NULL)", but with
- * any new page allocations done using the specified allocation flags. Note
- * that the Radix tree operations will still use GFP_KERNEL, so you can't
- * expect to do this atomically or anything like that - but you can pass in
- * other page requirements.
+ * any new page allocations done using the specified allocation flags.
*
* If the page does not get brought uptodate, return -EIO.
*/
^ permalink raw reply related [flat|nested] 34+ messages in thread* [PATCH v2] vfs: __read_cache_page should use gfp argument rather than GFP_KERNEL
@ 2011-12-21 17:05 ` Dave Kleikamp
0 siblings, 0 replies; 34+ messages in thread
From: Dave Kleikamp @ 2011-12-21 17:05 UTC (permalink / raw)
To: Hugh Dickins
Cc: Linus Torvalds, Rafael J. Wysocki, jfs-discussion,
Kernel Testers List, LKML, Maciej Rutecki, Andrew Morton,
Florian Mickler, davem, Al Viro, linux-mm
[ updated to remove now-obsolete comment in read_cache_page_gfp()]
lockdep reports a deadlock in jfs because a special inode's rw semaphore
is taken recursively. The mapping's gfp mask is GFP_NOFS, but is not used
when __read_cache_page() calls add_to_page_cache_lru().
Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
Acked-by: Hugh Dickins <hughd@google.com>
Acked-by: Al Viro <viro@zeniv.linux.org.uk>
diff --git a/mm/filemap.c b/mm/filemap.c
index c106d3b..5f0a3c9 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -1828,7 +1828,7 @@ repeat:
page = __page_cache_alloc(gfp | __GFP_COLD);
if (!page)
return ERR_PTR(-ENOMEM);
- err = add_to_page_cache_lru(page, mapping, index, GFP_KERNEL);
+ err = add_to_page_cache_lru(page, mapping, index, gfp);
if (unlikely(err)) {
page_cache_release(page);
if (err == -EEXIST)
@@ -1925,10 +1925,7 @@ static struct page *wait_on_page_read(struct page *page)
* @gfp: the page allocator flags to use if allocating
*
* This is the same as "read_mapping_page(mapping, index, NULL)", but with
- * any new page allocations done using the specified allocation flags. Note
- * that the Radix tree operations will still use GFP_KERNEL, so you can't
- * expect to do this atomically or anything like that - but you can pass in
- * other page requirements.
+ * any new page allocations done using the specified allocation flags.
*
* If the page does not get brought uptodate, return -EIO.
*/
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related [flat|nested] 34+ messages in thread* Re: [PATCH v2] vfs: __read_cache_page should use gfp argument rather than GFP_KERNEL
2011-12-21 17:05 ` Dave Kleikamp
(?)
@ 2011-12-21 20:28 ` Andrew Morton
-1 siblings, 0 replies; 34+ messages in thread
From: Andrew Morton @ 2011-12-21 20:28 UTC (permalink / raw)
To: Dave Kleikamp
Cc: Hugh Dickins, Linus Torvalds, Rafael J. Wysocki, jfs-discussion,
Kernel Testers List, LKML, Maciej Rutecki, Florian Mickler,
davem, Al Viro, linux-mm
On Wed, 21 Dec 2011 11:05:48 -0600
Dave Kleikamp <dave.kleikamp@oracle.com> wrote:
> [ updated to remove now-obsolete comment in read_cache_page_gfp()]
>
> lockdep reports a deadlock in jfs because a special inode's rw semaphore
> is taken recursively. The mapping's gfp mask is GFP_NOFS, but is not used
> when __read_cache_page() calls add_to_page_cache_lru().
Well hang on, it's not just a lockdep splat. The kernel actually will
deadlock if we reenter JFS via this GFP_KERNEL allocation attempt, yes?
Was that GFP_NOFS allocation recently added to JFS? If not then we
should backport this deadlock fix into -stable, no?
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v2] vfs: __read_cache_page should use gfp argument rather than GFP_KERNEL
@ 2011-12-21 20:28 ` Andrew Morton
0 siblings, 0 replies; 34+ messages in thread
From: Andrew Morton @ 2011-12-21 20:28 UTC (permalink / raw)
To: Dave Kleikamp
Cc: Hugh Dickins, Linus Torvalds, Rafael J. Wysocki,
jfs-discussion-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
Kernel Testers List, LKML, Maciej Rutecki, Florian Mickler,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, Al Viro,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg
On Wed, 21 Dec 2011 11:05:48 -0600
Dave Kleikamp <dave.kleikamp-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> wrote:
> [ updated to remove now-obsolete comment in read_cache_page_gfp()]
>
> lockdep reports a deadlock in jfs because a special inode's rw semaphore
> is taken recursively. The mapping's gfp mask is GFP_NOFS, but is not used
> when __read_cache_page() calls add_to_page_cache_lru().
Well hang on, it's not just a lockdep splat. The kernel actually will
deadlock if we reenter JFS via this GFP_KERNEL allocation attempt, yes?
Was that GFP_NOFS allocation recently added to JFS? If not then we
should backport this deadlock fix into -stable, no?
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v2] vfs: __read_cache_page should use gfp argument rather than GFP_KERNEL
@ 2011-12-21 20:28 ` Andrew Morton
0 siblings, 0 replies; 34+ messages in thread
From: Andrew Morton @ 2011-12-21 20:28 UTC (permalink / raw)
To: Dave Kleikamp
Cc: Hugh Dickins, Linus Torvalds, Rafael J. Wysocki, jfs-discussion,
Kernel Testers List, LKML, Maciej Rutecki, Florian Mickler,
davem, Al Viro, linux-mm
On Wed, 21 Dec 2011 11:05:48 -0600
Dave Kleikamp <dave.kleikamp@oracle.com> wrote:
> [ updated to remove now-obsolete comment in read_cache_page_gfp()]
>
> lockdep reports a deadlock in jfs because a special inode's rw semaphore
> is taken recursively. The mapping's gfp mask is GFP_NOFS, but is not used
> when __read_cache_page() calls add_to_page_cache_lru().
Well hang on, it's not just a lockdep splat. The kernel actually will
deadlock if we reenter JFS via this GFP_KERNEL allocation attempt, yes?
Was that GFP_NOFS allocation recently added to JFS? If not then we
should backport this deadlock fix into -stable, no?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v2] vfs: __read_cache_page should use gfp argument rather than GFP_KERNEL
2011-12-21 20:28 ` Andrew Morton
@ 2011-12-21 20:53 ` Dave Kleikamp
-1 siblings, 0 replies; 34+ messages in thread
From: Dave Kleikamp @ 2011-12-21 20:53 UTC (permalink / raw)
To: Andrew Morton
Cc: Hugh Dickins, Linus Torvalds, Rafael J. Wysocki, jfs-discussion,
Kernel Testers List, LKML, Maciej Rutecki, Florian Mickler,
davem, Al Viro, linux-mm
On 12/21/2011 02:28 PM, Andrew Morton wrote:
> On Wed, 21 Dec 2011 11:05:48 -0600
> Dave Kleikamp <dave.kleikamp@oracle.com> wrote:
>
>> [ updated to remove now-obsolete comment in read_cache_page_gfp()]
>>
>> lockdep reports a deadlock in jfs because a special inode's rw semaphore
>> is taken recursively. The mapping's gfp mask is GFP_NOFS, but is not used
>> when __read_cache_page() calls add_to_page_cache_lru().
>
> Well hang on, it's not just a lockdep splat. The kernel actually will
> deadlock if we reenter JFS via this GFP_KERNEL allocation attempt, yes?
Yes, it could result in a real deadlock.
> Was that GFP_NOFS allocation recently added to JFS? If not then we
> should backport this deadlock fix into -stable, no?
Yes, that would make sense.
Shaggy
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v2] vfs: __read_cache_page should use gfp argument rather than GFP_KERNEL
@ 2011-12-21 20:53 ` Dave Kleikamp
0 siblings, 0 replies; 34+ messages in thread
From: Dave Kleikamp @ 2011-12-21 20:53 UTC (permalink / raw)
To: Andrew Morton
Cc: Hugh Dickins, Linus Torvalds, Rafael J. Wysocki, jfs-discussion,
Kernel Testers List, LKML, Maciej Rutecki, Florian Mickler,
davem, Al Viro, linux-mm
On 12/21/2011 02:28 PM, Andrew Morton wrote:
> On Wed, 21 Dec 2011 11:05:48 -0600
> Dave Kleikamp <dave.kleikamp@oracle.com> wrote:
>
>> [ updated to remove now-obsolete comment in read_cache_page_gfp()]
>>
>> lockdep reports a deadlock in jfs because a special inode's rw semaphore
>> is taken recursively. The mapping's gfp mask is GFP_NOFS, but is not used
>> when __read_cache_page() calls add_to_page_cache_lru().
>
> Well hang on, it's not just a lockdep splat. The kernel actually will
> deadlock if we reenter JFS via this GFP_KERNEL allocation attempt, yes?
Yes, it could result in a real deadlock.
> Was that GFP_NOFS allocation recently added to JFS? If not then we
> should backport this deadlock fix into -stable, no?
Yes, that would make sense.
Shaggy
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Resend] 3.2-rc6+: Reported regressions from 3.0 and 3.1
@ 2011-12-21 4:50 ` David Miller
0 siblings, 0 replies; 34+ messages in thread
From: David Miller @ 2011-12-21 4:50 UTC (permalink / raw)
To: torvalds
Cc: rjw, shaggy, jfs-discussion, kernel-testers, linux-kernel,
maciej.rutecki, akpm, florian
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Tue, 20 Dec 2011 18:31:15 -0800
> On Tue, Dec 20, 2011 at 3:54 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>>
>> Subject : Sparc-32 doesn't work in 3.1.
>> Submitter : Rob Landley <rob@landley.net>
>> Date : 2011-11-12 11:22
>> Message-ID : 4EBEAB5A.5020809@landley.net
>> References : http://www.spinics.net/lists/kernel/msg1260383.html
>
> I'm pretty sure this is fixed by commit b1f44e13a525.
It is.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Resend] 3.2-rc6+: Reported regressions from 3.0 and 3.1
@ 2011-12-21 4:50 ` David Miller
0 siblings, 0 replies; 34+ messages in thread
From: David Miller @ 2011-12-21 4:50 UTC (permalink / raw)
To: torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b
Cc: rjw-KKrjLPT3xs0, shaggy-DgEjT+Ai2ygdnm+yROfE0A,
jfs-discussion-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
kernel-testers-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
maciej.rutecki-Re5JQEeQqe8AvxtiuMwx3w,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
florian-sVu6HhrpSfRAfugRpC6u6w
From: Linus Torvalds <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Date: Tue, 20 Dec 2011 18:31:15 -0800
> On Tue, Dec 20, 2011 at 3:54 PM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
>>
>> Subject : Sparc-32 doesn't work in 3.1.
>> Submitter : Rob Landley <rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org>
>> Date : 2011-11-12 11:22
>> Message-ID : 4EBEAB5A.5020809-VoJi6FS/r0vR7s880joybQ@public.gmane.org
>> References : http://www.spinics.net/lists/kernel/msg1260383.html
>
> I'm pretty sure this is fixed by commit b1f44e13a525.
It is.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Resend] 3.2-rc6+: Reported regressions from 3.0 and 3.1
@ 2011-12-21 16:32 ` Nick Bowler
0 siblings, 0 replies; 34+ messages in thread
From: Nick Bowler @ 2011-12-21 16:32 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Kernel Testers List, LKML, Linus Torvalds, Maciej Rutecki,
Andrew Morton, Florian Mickler, davem
On 2011-12-21 00:54 +0100, Rafael J. Wysocki wrote:
> This message contains a list of some regressions from 3.0 and 3.1 for
> which there are no fixes in the mainline known to the tracking team.
> If any of them have been fixed already, please let us know.
>
> If you know of any other unresolved regressions from 3.0 and 3.1,
> please let us know either and we'll add them to the list. Also,
> please let us know if any of the entries below are invalid.
i915 HDMI log spam, reported against -rc1:
http://permalink.gmane.org/gmane.linux.kernel/1212638
remains present in mainline. The latest patches (afaik) were posted
earlier this month:
Subject: Intel HDMI ELD fixes v2
http://permalink.gmane.org/gmane.linux.kernel/1226920
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Resend] 3.2-rc6+: Reported regressions from 3.0 and 3.1
@ 2011-12-21 16:32 ` Nick Bowler
0 siblings, 0 replies; 34+ messages in thread
From: Nick Bowler @ 2011-12-21 16:32 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Kernel Testers List, LKML, Linus Torvalds, Maciej Rutecki,
Andrew Morton, Florian Mickler, davem-fT/PcQaiUtIeIZ0/mPfg9Q
On 2011-12-21 00:54 +0100, Rafael J. Wysocki wrote:
> This message contains a list of some regressions from 3.0 and 3.1 for
> which there are no fixes in the mainline known to the tracking team.
> If any of them have been fixed already, please let us know.
>
> If you know of any other unresolved regressions from 3.0 and 3.1,
> please let us know either and we'll add them to the list. Also,
> please let us know if any of the entries below are invalid.
i915 HDMI log spam, reported against -rc1:
http://permalink.gmane.org/gmane.linux.kernel/1212638
remains present in mainline. The latest patches (afaik) were posted
earlier this month:
Subject: Intel HDMI ELD fixes v2
http://permalink.gmane.org/gmane.linux.kernel/1226920
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Resend] 3.2-rc6+: Reported regressions from 3.0 and 3.1
@ 2011-12-21 17:51 ` Keith Packard
0 siblings, 0 replies; 34+ messages in thread
From: Keith Packard @ 2011-12-21 17:51 UTC (permalink / raw)
To: Nick Bowler, Rafael J. Wysocki
Cc: Kernel Testers List, LKML, Linus Torvalds, Maciej Rutecki,
Andrew Morton, Florian Mickler, davem
[-- Attachment #1: Type: text/plain, Size: 348 bytes --]
On Wed, 21 Dec 2011 11:32:13 -0500, Nick Bowler <nbowler@elliptictech.com> wrote:
> Subject: Intel HDMI ELD fixes v2
> http://permalink.gmane.org/gmane.linux.kernel/1226920
Dave and I didn't think the log spam warranted pulling these patches in
past the merge window. They're pending 3.3 at this point.
--
keith.packard@intel.com
[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Resend] 3.2-rc6+: Reported regressions from 3.0 and 3.1
@ 2011-12-21 17:51 ` Keith Packard
0 siblings, 0 replies; 34+ messages in thread
From: Keith Packard @ 2011-12-21 17:51 UTC (permalink / raw)
To: Nick Bowler, Rafael J. Wysocki
Cc: Kernel Testers List, LKML, Linus Torvalds, Maciej Rutecki,
Andrew Morton, Florian Mickler, davem-fT/PcQaiUtIeIZ0/mPfg9Q
[-- Attachment #1: Type: text/plain, Size: 401 bytes --]
On Wed, 21 Dec 2011 11:32:13 -0500, Nick Bowler <nbowler-7BP4RkwGw0uXmMXjJBpWqg@public.gmane.org> wrote:
> Subject: Intel HDMI ELD fixes v2
> http://permalink.gmane.org/gmane.linux.kernel/1226920
Dave and I didn't think the log spam warranted pulling these patches in
past the merge window. They're pending 3.3 at this point.
--
keith.packard-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org
[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Resend] 3.2-rc6+: Reported regressions from 3.0 and 3.1
@ 2011-12-21 21:01 ` Jan Kara
0 siblings, 0 replies; 34+ messages in thread
From: Jan Kara @ 2011-12-21 21:01 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Kernel Testers List, LKML, Linus Torvalds, Maciej Rutecki,
Andrew Morton, Florian Mickler, davem
On Wed 21-12-11 00:54:46, Rafael J. Wysocki wrote:
> Subject : Reiserfs.c bug in 3.2-rc5
> Submitter : "Jorge Bastos" <mysql.jorge@decimal.pt>
> Date : 2011-12-10 23:48
> Message-ID : 43556.213.228.140.150.1323560920.squirrel@webmail.decimal.pt
> References : http://marc.info/?l=linux-kernel&m=132356156914296&w=2
Well, it's not clear this is a regression. Also I didn't get any reply
from the reporter for a week so I'm inclined to declare it ENORESPONSE...
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Resend] 3.2-rc6+: Reported regressions from 3.0 and 3.1
@ 2011-12-21 21:01 ` Jan Kara
0 siblings, 0 replies; 34+ messages in thread
From: Jan Kara @ 2011-12-21 21:01 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Kernel Testers List, LKML, Linus Torvalds, Maciej Rutecki,
Andrew Morton, Florian Mickler, davem-fT/PcQaiUtIeIZ0/mPfg9Q
On Wed 21-12-11 00:54:46, Rafael J. Wysocki wrote:
> Subject : Reiserfs.c bug in 3.2-rc5
> Submitter : "Jorge Bastos" <mysql.jorge-lcG7AWEBJY0VhHzd4jOs4w@public.gmane.org>
> Date : 2011-12-10 23:48
> Message-ID : 43556.213.228.140.150.1323560920.squirrel-2RFepEojUI2VwbsBYQEljRWEfN3iM6zj@public.gmane.org
> References : http://marc.info/?l=linux-kernel&m=132356156914296&w=2
Well, it's not clear this is a regression. Also I didn't get any reply
from the reporter for a week so I'm inclined to declare it ENORESPONSE...
Honza
--
Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>
SUSE Labs, CR
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Resend] 3.2-rc6+: Reported regressions from 3.0 and 3.1
@ 2011-12-22 10:58 ` Srivatsa S. Bhat
0 siblings, 0 replies; 34+ messages in thread
From: Srivatsa S. Bhat @ 2011-12-22 10:58 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Kernel Testers List, LKML, Linus Torvalds, Maciej Rutecki,
Andrew Morton, Florian Mickler, davem, Belisko Marek,
Jeff Layton, awilliam, Tejun Heo
On 12/21/2011 05:24 AM, Rafael J. Wysocki wrote:
> [Evidently, vger has blocked the previous attempts to post this message
> for some reason. I wonder why?]
>
> This message contains a list of some regressions from 3.0 and 3.1
> for which there are no fixes in the mainline known to the tracking team.
> If any of them have been fixed already, please let us know.
>
> If you know of any other unresolved regressions from 3.0 and 3.1, please let us
> know either and we'll add them to the list. Also, please let us know if any of
> the entries below are invalid.
>
> The entries below are simplified and the statistics are not present due to the
> continuing Bugzilla outage.
>
[...]
>
> Subject : Freezing of tasks failed after 20.01 seconds in kernel 3.2.0-rc2
> Submitter : Belisko Marek <marek.belisko@gmail.com>
> Date : 2011-11-22 21:20
> Message-ID :
> CAAfyv36nxYq1EA2pcHi5WR1BdWYHp2sQTY1mMA4Q3JjcOG5RDw@mail.gmail.com
> References : http://marc.info/?l=linux-kernel&m=132199691706100&w=2
>
>
I believe we already have a fix for this, but not yet in mainline:
http://thread.gmane.org/gmane.linux.nfs/45336
Regards,
Srivatsa S. Bhat
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Resend] 3.2-rc6+: Reported regressions from 3.0 and 3.1
@ 2011-12-22 10:58 ` Srivatsa S. Bhat
0 siblings, 0 replies; 34+ messages in thread
From: Srivatsa S. Bhat @ 2011-12-22 10:58 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Kernel Testers List, LKML, Linus Torvalds, Maciej Rutecki,
Andrew Morton, Florian Mickler, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
Belisko Marek, Jeff Layton, awilliam-H+wXaHxf7aLQT0dZR+AlfA,
Tejun Heo
On 12/21/2011 05:24 AM, Rafael J. Wysocki wrote:
> [Evidently, vger has blocked the previous attempts to post this message
> for some reason. I wonder why?]
>
> This message contains a list of some regressions from 3.0 and 3.1
> for which there are no fixes in the mainline known to the tracking team.
> If any of them have been fixed already, please let us know.
>
> If you know of any other unresolved regressions from 3.0 and 3.1, please let us
> know either and we'll add them to the list. Also, please let us know if any of
> the entries below are invalid.
>
> The entries below are simplified and the statistics are not present due to the
> continuing Bugzilla outage.
>
[...]
>
> Subject : Freezing of tasks failed after 20.01 seconds in kernel 3.2.0-rc2
> Submitter : Belisko Marek <marek.belisko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date : 2011-11-22 21:20
> Message-ID :
> CAAfyv36nxYq1EA2pcHi5WR1BdWYHp2sQTY1mMA4Q3JjcOG5RDw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
> References : http://marc.info/?l=linux-kernel&m=132199691706100&w=2
>
>
I believe we already have a fix for this, but not yet in mainline:
http://thread.gmane.org/gmane.linux.nfs/45336
Regards,
Srivatsa S. Bhat
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Resend] 3.2-rc6+: Reported regressions from 3.0 and 3.1
@ 2011-12-22 11:27 ` Jeff Layton
0 siblings, 0 replies; 34+ messages in thread
From: Jeff Layton @ 2011-12-22 11:27 UTC (permalink / raw)
To: Srivatsa S. Bhat
Cc: Rafael J. Wysocki, Kernel Testers List, LKML, Linus Torvalds,
Maciej Rutecki, Andrew Morton, Florian Mickler, davem,
Belisko Marek, awilliam, Tejun Heo
On Thu, 22 Dec 2011 16:28:19 +0530
"Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com> wrote:
> On 12/21/2011 05:24 AM, Rafael J. Wysocki wrote:
>
> > [Evidently, vger has blocked the previous attempts to post this message
> > for some reason. I wonder why?]
> >
> > This message contains a list of some regressions from 3.0 and 3.1
> > for which there are no fixes in the mainline known to the tracking team.
> > If any of them have been fixed already, please let us know.
> >
> > If you know of any other unresolved regressions from 3.0 and 3.1, please let us
> > know either and we'll add them to the list. Also, please let us know if any of
> > the entries below are invalid.
> >
> > The entries below are simplified and the statistics are not present due to the
> > continuing Bugzilla outage.
> >
>
> [...]
>
> >
> > Subject : Freezing of tasks failed after 20.01 seconds in kernel 3.2.0-rc2
> > Submitter : Belisko Marek <marek.belisko@gmail.com>
> > Date : 2011-11-22 21:20
> > Message-ID :
> > CAAfyv36nxYq1EA2pcHi5WR1BdWYHp2sQTY1mMA4Q3JjcOG5RDw@mail.gmail.com
> > References : http://marc.info/?l=linux-kernel&m=132199691706100&w=2
> >
> >
>
>
> I believe we already have a fix for this, but not yet in mainline:
> http://thread.gmane.org/gmane.linux.nfs/45336
>
I don't believe this is a regression at all. As far as I know, It's
always been the case that these sleeps weren't freezable. I even have
a similar bug open for RHEL6 which has a 2.6.32-based kernel...
If people are seeing this more now, then it might be some subtle
difference in timing or differences in what userspace is doing at the
time the freezer runs.
In any case, the final fix didn't make 3.2, but should go in early for
3.3.
--
Jeff Layton <jlayton@redhat.com>
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Resend] 3.2-rc6+: Reported regressions from 3.0 and 3.1
@ 2011-12-22 11:27 ` Jeff Layton
0 siblings, 0 replies; 34+ messages in thread
From: Jeff Layton @ 2011-12-22 11:27 UTC (permalink / raw)
To: Srivatsa S. Bhat
Cc: Rafael J. Wysocki, Kernel Testers List, LKML, Linus Torvalds,
Maciej Rutecki, Andrew Morton, Florian Mickler,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, Belisko Marek,
awilliam-H+wXaHxf7aLQT0dZR+AlfA, Tejun Heo
On Thu, 22 Dec 2011 16:28:19 +0530
"Srivatsa S. Bhat" <srivatsa.bhat-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> wrote:
> On 12/21/2011 05:24 AM, Rafael J. Wysocki wrote:
>
> > [Evidently, vger has blocked the previous attempts to post this message
> > for some reason. I wonder why?]
> >
> > This message contains a list of some regressions from 3.0 and 3.1
> > for which there are no fixes in the mainline known to the tracking team.
> > If any of them have been fixed already, please let us know.
> >
> > If you know of any other unresolved regressions from 3.0 and 3.1, please let us
> > know either and we'll add them to the list. Also, please let us know if any of
> > the entries below are invalid.
> >
> > The entries below are simplified and the statistics are not present due to the
> > continuing Bugzilla outage.
> >
>
> [...]
>
> >
> > Subject : Freezing of tasks failed after 20.01 seconds in kernel 3.2.0-rc2
> > Submitter : Belisko Marek <marek.belisko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Date : 2011-11-22 21:20
> > Message-ID :
> > CAAfyv36nxYq1EA2pcHi5WR1BdWYHp2sQTY1mMA4Q3JjcOG5RDw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
> > References : http://marc.info/?l=linux-kernel&m=132199691706100&w=2
> >
> >
>
>
> I believe we already have a fix for this, but not yet in mainline:
> http://thread.gmane.org/gmane.linux.nfs/45336
>
I don't believe this is a regression at all. As far as I know, It's
always been the case that these sleeps weren't freezable. I even have
a similar bug open for RHEL6 which has a 2.6.32-based kernel...
If people are seeing this more now, then it might be some subtle
difference in timing or differences in what userspace is doing at the
time the freezer runs.
In any case, the final fix didn't make 3.2, but should go in early for
3.3.
--
Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Resend] 3.2-rc6+: Reported regressions from 3.0 and 3.1
@ 2011-12-22 11:15 ` Srivatsa S. Bhat
0 siblings, 0 replies; 34+ messages in thread
From: Srivatsa S. Bhat @ 2011-12-22 11:15 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Kernel Testers List, LKML, Linus Torvalds, Maciej Rutecki,
Andrew Morton, Florian Mickler, davem, pavel, Chris Ball,
manuel.lauss, Udo Steinberg
On 12/21/2011 05:24 AM, Rafael J. Wysocki wrote:
> [Evidently, vger has blocked the previous attempts to post this message
> for some reason. I wonder why?]
>
> This message contains a list of some regressions from 3.0 and 3.1
> for which there are no fixes in the mainline known to the tracking team.
> If any of them have been fixed already, please let us know.
>
> If you know of any other unresolved regressions from 3.0 and 3.1, please let us
> know either and we'll add them to the list. Also, please let us know if any of
> the entries below are invalid.
>
> The entries below are simplified and the statistics are not present due to the
> continuing Bugzilla outage.
>
>
> Subject : 3.2-rc2: regression after hibernate: lots of warnings, broken
> system
> Submitter : Pavel Machek <pavel@ucw.cz>
> Date : 2011-11-24 15:40
> Message-ID : 20111124154014.GA2153@elf.ucw.cz
> References : http://marc.info/?l=linux-kernel&m=132214929818015&w=2
>
This one looks a bit similar to the one reported at
http://thread.gmane.org/gmane.linux.kernel/1230509/ which is fixed by
commit 29495aa04a30c21565243c5b9c028510446d242c.
Regards,
Srivatsa S. Bhat
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Resend] 3.2-rc6+: Reported regressions from 3.0 and 3.1
@ 2011-12-22 11:15 ` Srivatsa S. Bhat
0 siblings, 0 replies; 34+ messages in thread
From: Srivatsa S. Bhat @ 2011-12-22 11:15 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Kernel Testers List, LKML, Linus Torvalds, Maciej Rutecki,
Andrew Morton, Florian Mickler, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
pavel-+ZI9xUNit7I, Chris Ball,
manuel.lauss-gM/Ye1E23mwN+BqQ9rBEUg, Udo Steinberg
On 12/21/2011 05:24 AM, Rafael J. Wysocki wrote:
> [Evidently, vger has blocked the previous attempts to post this message
> for some reason. I wonder why?]
>
> This message contains a list of some regressions from 3.0 and 3.1
> for which there are no fixes in the mainline known to the tracking team.
> If any of them have been fixed already, please let us know.
>
> If you know of any other unresolved regressions from 3.0 and 3.1, please let us
> know either and we'll add them to the list. Also, please let us know if any of
> the entries below are invalid.
>
> The entries below are simplified and the statistics are not present due to the
> continuing Bugzilla outage.
>
>
> Subject : 3.2-rc2: regression after hibernate: lots of warnings, broken
> system
> Submitter : Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>
> Date : 2011-11-24 15:40
> Message-ID : 20111124154014.GA2153-I/5MKhXcvmPrBKCeMvbIDA@public.gmane.org
> References : http://marc.info/?l=linux-kernel&m=132214929818015&w=2
>
This one looks a bit similar to the one reported at
http://thread.gmane.org/gmane.linux.kernel/1230509/ which is fixed by
commit 29495aa04a30c21565243c5b9c028510446d242c.
Regards,
Srivatsa S. Bhat
^ permalink raw reply [flat|nested] 34+ messages in thread