[Resend] 3.2-rc6+: Reported regressions from 3.0 and 3.1

[Resend] 3.2-rc6+: Reported regressions from 3.0 and 3.1

[Rafael J. Wysocki]

[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!

Re: [Resend] 3.2-rc6+: Reported regressions from 3.0 and 3.1

[Linus Torvalds]

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

Re: [Resend] 3.2-rc6+: Reported regressions from 3.0 and 3.1

[Dave Kleikamp]

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)

Re: [Resend] 3.2-rc6+: Reported regressions from 3.0 and 3.1

[Linus Torvalds]

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)

Re: [Resend] 3.2-rc6+: Reported regressions from 3.0 and 3.1

[Hugh Dickins]

[-- 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)

Re: [Resend] 3.2-rc6+: Reported regressions from 3.0 and 3.1

[Al Viro]

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>

[PATCH v2] vfs: __read_cache_page should use gfp argument rather than GFP_KERNEL

[Dave Kleikamp]

[ 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>

Re: [PATCH v2] vfs: __read_cache_page should use gfp argument rather than GFP_KERNEL

[Andrew Morton]

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?

Re: [PATCH v2] vfs: __read_cache_page should use gfp argument rather than GFP_KERNEL

[Dave Kleikamp]

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>

Re: [Resend] 3.2-rc6+: Reported regressions from 3.0 and 3.1

[David Miller]

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.

Re: [Resend] 3.2-rc6+: Reported regressions from 3.0 and 3.1

[Nick Bowler]

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/)

Re: [Resend] 3.2-rc6+: Reported regressions from 3.0 and 3.1

[Keith Packard]

[-- 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 --]

Re: [Resend] 3.2-rc6+: Reported regressions from 3.0 and 3.1

[Jan Kara]

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

Re: [Resend] 3.2-rc6+: Reported regressions from 3.0 and 3.1

[Srivatsa S. Bhat]

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

Re: [Resend] 3.2-rc6+: Reported regressions from 3.0 and 3.1

[Jeff Layton]

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>

Re: [Resend] 3.2-rc6+: Reported regressions from 3.0 and 3.1

[Srivatsa S. Bhat]

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