1. 14 Oct, 2011 1 commit
  2. 10 Oct, 2011 7 commits
    • Roland Dreier's avatar
      intel-iommu: Fix AB-BA lockdep report · 3e7abe25
      Roland Dreier authored
      When unbinding a device so that I could pass it through to a KVM VM, I
      got the lockdep report below.  It looks like a legitimate lock
      ordering problem:
      
       - domain_context_mapping_one() takes iommu->lock and calls
         iommu_support_dev_iotlb(), which takes device_domain_lock (inside
         iommu->lock).
      
       - domain_remove_one_dev_info() starts by taking device_domain_lock
         then takes iommu->lock inside it (near the end of the function).
      
      So this is the classic AB-BA deadlock.  It looks like a safe fix is to
      simply release device_domain_lock a bit earlier, since as far as I can
      tell, it doesn't protect any of the stuff accessed at the end of
      domain_remove_one_dev_info() anyway.
      
      BTW, the use of device_domain_lock looks a bit unsafe to me... it's
      at least not obvious to me why we aren't vulnerable to the race below:
      
        iommu_support_dev_iotlb()
                                                domain_remove_dev_info()
      
        lock device_domain_lock
          find info
        unlock device_domain_lock
      
                                                lock device_domain_lock
                                                  find same info
                                                unlock device_domain_lock
      
                                                free_devinfo_mem(info)
      
        do stuff with info after it's free
      
      However I don't understand the locking here well enough to know if
      this is a real problem, let alone what the best fix is.
      
      Anyway here's the full lockdep output that prompted all of this:
      
           =======================================================
           [ INFO: possible circular locking dependency detected ]
           2.6.39.1+ #1
           -------------------------------------------------------
           bash/13954 is trying to acquire lock:
            (&(&iommu->lock)->rlock){......}, at: [<ffffffff812f6421>] domain_remove_one_dev_info+0x121/0x230
      
           but task is already holding lock:
            (device_domain_lock){-.-...}, at: [<ffffffff812f6508>] domain_remove_one_dev_info+0x208/0x230
      
           which lock already depends on the new lock.
      
           the existing dependency chain (in reverse order) is:
      
           -> #1 (device_domain_lock){-.-...}:
                  [<ffffffff8109ca9d>] lock_acquire+0x9d/0x130
                  [<ffffffff81571475>] _raw_spin_lock_irqsave+0x55/0xa0
                  [<ffffffff812f8350>] domain_context_mapping_one+0x600/0x750
                  [<ffffffff812f84df>] domain_context_mapping+0x3f/0x120
                  [<ffffffff812f9175>] iommu_prepare_identity_map+0x1c5/0x1e0
                  [<ffffffff81ccf1ca>] intel_iommu_init+0x88e/0xb5e
                  [<ffffffff81cab204>] pci_iommu_init+0x16/0x41
                  [<ffffffff81002165>] do_one_initcall+0x45/0x190
                  [<ffffffff81ca3d3f>] kernel_init+0xe3/0x168
                  [<ffffffff8157ac24>] kernel_thread_helper+0x4/0x10
      
           -> #0 (&(&iommu->lock)->rlock){......}:
                  [<ffffffff8109bf3e>] __lock_acquire+0x195e/0x1e10
                  [<ffffffff8109ca9d>] lock_acquire+0x9d/0x130
                  [<ffffffff81571475>] _raw_spin_lock_irqsave+0x55/0xa0
                  [<ffffffff812f6421>] domain_remove_one_dev_info+0x121/0x230
                  [<ffffffff812f8b42>] device_notifier+0x72/0x90
                  [<ffffffff8157555c>] notifier_call_chain+0x8c/0xc0
                  [<ffffffff81089768>] __blocking_notifier_call_chain+0x78/0xb0
                  [<ffffffff810897b6>] blocking_notifier_call_chain+0x16/0x20
                  [<ffffffff81373a5c>] __device_release_driver+0xbc/0xe0
                  [<ffffffff81373ccf>] device_release_driver+0x2f/0x50
                  [<ffffffff81372ee3>] driver_unbind+0xa3/0xc0
                  [<ffffffff813724ac>] drv_attr_store+0x2c/0x30
                  [<ffffffff811e4506>] sysfs_write_file+0xe6/0x170
                  [<ffffffff8117569e>] vfs_write+0xce/0x190
                  [<ffffffff811759e4>] sys_write+0x54/0xa0
                  [<ffffffff81579a82>] system_call_fastpath+0x16/0x1b
      
           other info that might help us debug this:
      
           6 locks held by bash/13954:
            #0:  (&buffer->mutex){+.+.+.}, at: [<ffffffff811e4464>] sysfs_write_file+0x44/0x170
            #1:  (s_active#3){++++.+}, at: [<ffffffff811e44ed>] sysfs_write_file+0xcd/0x170
            #2:  (&__lockdep_no_validate__){+.+.+.}, at: [<ffffffff81372edb>] driver_unbind+0x9b/0xc0
            #3:  (&__lockdep_no_validate__){+.+.+.}, at: [<ffffffff81373cc7>] device_release_driver+0x27/0x50
            #4:  (&(&priv->bus_notifier)->rwsem){.+.+.+}, at: [<ffffffff8108974f>] __blocking_notifier_call_chain+0x5f/0xb0
            #5:  (device_domain_lock){-.-...}, at: [<ffffffff812f6508>] domain_remove_one_dev_info+0x208/0x230
      
           stack backtrace:
           Pid: 13954, comm: bash Not tainted 2.6.39.1+ #1
           Call Trace:
            [<ffffffff810993a7>] print_circular_bug+0xf7/0x100
            [<ffffffff8109bf3e>] __lock_acquire+0x195e/0x1e10
            [<ffffffff810972bd>] ? trace_hardirqs_off+0xd/0x10
            [<ffffffff8109d57d>] ? trace_hardirqs_on_caller+0x13d/0x180
            [<ffffffff8109ca9d>] lock_acquire+0x9d/0x130
            [<ffffffff812f6421>] ? domain_remove_one_dev_info+0x121/0x230
            [<ffffffff81571475>] _raw_spin_lock_irqsave+0x55/0xa0
            [<ffffffff812f6421>] ? domain_remove_one_dev_info+0x121/0x230
            [<ffffffff810972bd>] ? trace_hardirqs_off+0xd/0x10
            [<ffffffff812f6421>] domain_remove_one_dev_info+0x121/0x230
            [<ffffffff812f8b42>] device_notifier+0x72/0x90
            [<ffffffff8157555c>] notifier_call_chain+0x8c/0xc0
            [<ffffffff81089768>] __blocking_notifier_call_chain+0x78/0xb0
            [<ffffffff810897b6>] blocking_notifier_call_chain+0x16/0x20
            [<ffffffff81373a5c>] __device_release_driver+0xbc/0xe0
            [<ffffffff81373ccf>] device_release_driver+0x2f/0x50
            [<ffffffff81372ee3>] driver_unbind+0xa3/0xc0
            [<ffffffff813724ac>] drv_attr_store+0x2c/0x30
            [<ffffffff811e4506>] sysfs_write_file+0xe6/0x170
            [<ffffffff8117569e>] vfs_write+0xce/0x190
            [<ffffffff811759e4>] sys_write+0x54/0xa0
            [<ffffffff81579a82>] system_call_fastpath+0x16/0x1b
      Signed-off-by: default avatarRoland Dreier <roland@purestorage.com>
      Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      3e7abe25
    • Linus Torvalds's avatar
      Merge git://git.samba.org/sfrench/cifs-2.6 · 65112dcc
      Linus Torvalds authored
      * git://git.samba.org/sfrench/cifs-2.6:
        [CIFS] Fix first time message on mount, ntlmv2 upgrade delayed to 3.2
      65112dcc
    • Linus Torvalds's avatar
      Merge branch 'fixes' of git://git.linaro.org/people/arnd/arm-soc · bbf5e974
      Linus Torvalds authored
      * 'fixes' of git://git.linaro.org/people/arnd/arm-soc:
        ARM: mach-ux500: enable fix for ARM errata 754322
        ARM: OMAP: musb: Remove a redundant omap4430_phy_init call in usb_musb_init
        ARM: OMAP: Fix i2c init for twl4030
        ARM: OMAP4: MMC: fix power and audio issue, decouple USBC1 from MMC1
      bbf5e974
    • Marc Dietrich's avatar
      ARM: tegra: fix compilation error due to mach/hardware.h removal · 3faf12cd
      Marc Dietrich authored
      This fixes a compilation error in cpu-tegra.c which was introduced in
      dc8d966b ("ARM: convert PCI defines to variables") which removed the
      now obsolete mach/hardware.h from the mach-tegra subtree.
      Signed-off-by: default avatarMarc Dietrich <marvin24@gmx.de>
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3faf12cd
    • Linus Torvalds's avatar
      Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux · 84c86116
      Linus Torvalds authored
      * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
        drm/radeon/kms: use hardcoded dig encoder to transmitter mapping for DCE4.1
        drm/radeon/kms: fix dp_detect handling for DP bridge chips
        drm/radeon/kms: retry aux transactions if there are status flags
      84c86116
    • Olof Johansson's avatar
      MAINTAINERS: Update tegra maintainer information · 746fb63c
      Olof Johansson authored
      A couple of changes to the Tegra maintainership setup:
      
      I'm very glad to bring on Stephen Warren on board as a maintainer. The
      work he has done so far is excellent, and the fact that he works for
      Nvidia means he has long-term interest in the platform.
      
      Erik Gilling did an astounding amount of work on getting things up and
      running but has been a silent partner on the maintainership side for a
      while, and is stepping down. Thanks for your contributions so far, Erik.
      
      Finally, update the git URL since I'll take over running the main repo
      for a while.
      
      Overall maintainership model isn't changing much at this time: We'll all
      three review patches as appropriate, and one of us will collect the main
      repo (me at this time).
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      Cc: Erik Gilling <konkers@android.com>
      Acked-by: default avatarColin Cross <ccross@android.com>
      Acked-by: default avatarStephen Warren <swarren@nvidia.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      746fb63c
    • Linus Torvalds's avatar
      Merge branch 'upstream' of git://git.linux-mips.org/pub/scm/upstream-linus · a24d025a
      Linus Torvalds authored
      * 'upstream' of git://git.linux-mips.org/pub/scm/upstream-linus: (29 commits)
        MIPS: Call oops_enter, oops_exit in die
        staging/octeon: Software should check the checksum of no tcp/udp packets
        MIPS: Octeon: Enable C0_UserLocal probing.
        MIPS: No branches in delay slots for huge pages in handle_tlbl
        MIPS: Don't clobber CP0_STATUS value for CONFIG_MIPS_MT_SMTC
        MIPS: Octeon: Select CONFIG_HOLES_IN_ZONE
        MIPS: PM: Use struct syscore_ops instead of sysdevs for PM (v2)
        MIPS: Compat: Use 32-bit wrapper for compat_sys_futex.
        MIPS: Do not use EXTRA_CFLAGS
        MIPS: Alchemy: DB1200: Disable cascade IRQ in handler
        SERIAL: Lantiq: Set timeout in uart_port
        MIPS: Lantiq: Fix setting the PCI bus speed on AR9
        MIPS: Lantiq: Fix external interrupt sources
        MIPS: tlbex: Fix build error in R3000 code.
        MIPS: Alchemy: Include Au1100 in PM code.
        MIPS: Alchemy: Fix typo in MAC0 registration
        MIPS: MSP71xx: Fix build error.
        MIPS: Handle __put_user() sleeping.
        MIPS: Allow forced irq threading
        MIPS: i8259: Mark cascade interrupt non-threaded
        ...
      a24d025a
  3. 08 Oct, 2011 2 commits
  4. 07 Oct, 2011 1 commit
  5. 06 Oct, 2011 7 commits
    • Linus Torvalds's avatar
      Merge git://github.com/davem330/net · 3ee72ca9
      Linus Torvalds authored
      * git://github.com/davem330/net:
        net: fix typos in Documentation/networking/scaling.txt
        bridge: leave carrier on for empty bridge
        netfilter: Use proper rwlock init function
        tcp: properly update lost_cnt_hint during shifting
        tcp: properly handle md5sig_pool references
        macvlan/macvtap: Fix unicast between macvtap interfaces in bridge mode
      3ee72ca9
    • Paul Menzel's avatar
      x86/PCI: use host bridge _CRS info on ASUS M2V-MX SE · 29cf7a30
      Paul Menzel authored
      In summary, this DMI quirk uses the _CRS info by default for the ASUS
      M2V-MX SE by turning on `pci=use_crs` and is similar to the quirk
      added by commit 2491762c ("x86/PCI: use host bridge _CRS info on
      ASRock ALiveSATA2-GLAN") whose commit message should be read for further
      information.
      
      Since commit 3e3da00c ("x86/pci: AMD one chain system to use pci
      read out res") Linux gives the following oops:
      
          parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE]
          HDA Intel 0000:20:01.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
          HDA Intel 0000:20:01.0: setting latency timer to 64
          BUG: unable to handle kernel paging request at ffffc90011c08000
          IP: [<ffffffffa0578402>] azx_probe+0x3ad/0x86b [snd_hda_intel]
          PGD 13781a067 PUD 13781b067 PMD 1300ba067 PTE 800000fd00000173
          Oops: 0009 [#1] SMP
          last sysfs file: /sys/module/snd_pcm/initstate
          CPU 0
          Modules linked in: snd_hda_intel(+) snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event tpm_tis tpm snd_seq tpm_bios psmouse parport_pc snd_timer snd_seq_device parport processor evdev snd i2c_viapro thermal_sys amd64_edac_mod k8temp i2c_core soundcore shpchp pcspkr serio_raw asus_atk0110 pci_hotplug edac_core button snd_page_alloc edac_mce_amd ext3 jbd mbcache sha256_generic cryptd aes_x86_64 aes_generic cbc dm_crypt dm_mod raid1 md_mod usbhid hid sg sd_mod crc_t10dif sr_mod cdrom ata_generic uhci_hcd sata_via pata_via libata ehci_hcd usbcore scsi_mod via_rhine mii nls_base [last unloaded: scsi_wait_scan]
          Pid: 1153, comm: work_for_cpu Not tainted 2.6.37-1-amd64 #1 M2V-MX SE/System Product Name
          RIP: 0010:[<ffffffffa0578402>]  [<ffffffffa0578402>] azx_probe+0x3ad/0x86b [snd_hda_intel]
          RSP: 0018:ffff88013153fe50  EFLAGS: 00010286
          RAX: ffffc90011c08000 RBX: ffff88013029ec00 RCX: 0000000000000006
          RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246
          RBP: ffff88013341d000 R08: 0000000000000000 R09: 0000000000000040
          R10: 0000000000000286 R11: 0000000000003731 R12: ffff88013029c400
          R13: 0000000000000000 R14: 0000000000000000 R15: ffff88013341d090
          FS:  0000000000000000(0000) GS:ffff8800bfc00000(0000) knlGS:00000000f7610ab0
          CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
          CR2: ffffc90011c08000 CR3: 0000000132f57000 CR4: 00000000000006f0
          DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
          DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
          Process work_for_cpu (pid: 1153, threadinfo ffff88013153e000, task ffff8801303c86c0)
          Stack:
           0000000000000005 ffffffff8123ad65 00000000000136c0 ffff88013029c400
           ffff8801303c8998 ffff88013341d000 ffff88013341d090 ffff8801322d9dc8
           ffff88013341d208 0000000000000000 0000000000000000 ffffffff811ad232
          Call Trace:
           [<ffffffff8123ad65>] ? __pm_runtime_set_status+0x162/0x186
           [<ffffffff811ad232>] ? local_pci_probe+0x49/0x92
           [<ffffffff8105afc5>] ? do_work_for_cpu+0x0/0x1b
           [<ffffffff8105afc5>] ? do_work_for_cpu+0x0/0x1b
           [<ffffffff8105afd0>] ? do_work_for_cpu+0xb/0x1b
           [<ffffffff8105fd3f>] ? kthread+0x7a/0x82
           [<ffffffff8100a824>] ? kernel_thread_helper+0x4/0x10
           [<ffffffff8105fcc5>] ? kthread+0x0/0x82
           [<ffffffff8100a820>] ? kernel_thread_helper+0x0/0x10
          Code: f4 01 00 00 ef 31 f6 48 89 df e8 29 dd ff ff 85 c0 0f 88 2b 03 00 00 48 89 ef e8 b4 39 c3 e0 8b 7b 40 e8 fc 9d b1 e0 48 8b 43 38 <66> 8b 10 66 89 14 24 8b 43 14 83 e8 03 83 f8 01 77 32 31 d2 be
          RIP  [<ffffffffa0578402>] azx_probe+0x3ad/0x86b [snd_hda_intel]
           RSP <ffff88013153fe50>
          CR2: ffffc90011c08000
          ---[ end trace 8d1f3ebc136437fd ]---
      
      Trusting the ACPI _CRS information (`pci=use_crs`) fixes this problem.
      
          $ dmesg | grep -i crs # with the quirk
          PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
      
      The match has to be against the DMI board entries though since the vendor entries are not populated.
      
          DMI: System manufacturer System Product Name/M2V-MX SE, BIOS 0304    10/30/2007
      
      This quirk should be removed when `pci=use_crs` is enabled for machines
      from 2006 or earlier or some other solution is implemented.
      
      Using coreboot [1] with this board the problem does not exist but this
      quirk also does not affect it either. To be safe though the check is
      tightened to only take effect when the BIOS from American Megatrends is
      used.
      
              15:13 < ruik> but coreboot does not need that
              15:13 < ruik> because i have there only one root bus
              15:13 < ruik> the audio is behind a bridge
      
              $ sudo dmidecode
              BIOS Information
                      Vendor: American Megatrends Inc.
                      Version: 0304
                      Release Date: 10/30/2007
      
      [1] http://www.coreboot.org/
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=30552
      
      Cc: stable@kernel.org (2.6.34)
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: x86@kernel.org
      Signed-off-by: default avatarPaul Menzel <paulepanter@users.sourceforge.net>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      29cf7a30
    • Benjamin Poirier's avatar
      net: fix typos in Documentation/networking/scaling.txt · 186c6bbc
      Benjamin Poirier authored
      The second hunk fixes rps_sock_flow_table but has to re-wrap the paragraph.
      Signed-off-by: default avatarBenjamin Poirier <benjamin.poirier@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      186c6bbc
    • stephen hemminger's avatar
      bridge: leave carrier on for empty bridge · b64b73d7
      stephen hemminger authored
      This resolves a regression seen by some users of bridging.
      Some users use the bridge like a dummy device.
      They expect to be able to put an IPv6 address on the device
      with no ports attached. Although there are better ways of doing
      this, there is no reason to not allow it.
      
      Note: the bridge still will reflect the state of ports in the
      bridge if there are any added.
      Signed-off-by: default avatarStephen Hemminger <shemminger@vyatta.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b64b73d7
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of http://people.redhat.com/agk/git/linux-dm · 6367f177
      Linus Torvalds authored
      * 'for-linus' of http://people.redhat.com/agk/git/linux-dm:
        dm crypt: always disable discard_zeroes_data
        dm: raid fix write_mostly arg validation
        dm table: avoid crash if integrity profile changes
        dm: flakey fix corrupt_bio_byte error path
      6367f177
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://neil.brown.name/md · a7c56eba
      Linus Torvalds authored
      * 'for-linus' of git://neil.brown.name/md:
        md: Avoid waking up a thread after it has been freed.
      a7c56eba
    • Alex Deucher's avatar
      drm/radeon/kms: use hardcoded dig encoder to transmitter mapping for DCE4.1 · cb7cf419
      Alex Deucher authored
      The encoders are supposedly fully routeable, but changing the mapping
      doesn't always seem to take.  Using a hardcoded mapping is much more
      reliable.
      
      Fixes:
      https://bugs.freedesktop.org/show_bug.cgi?id=41366Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Tested-by: default avatarSimon Farnsworth <simon.farnsworth@onelan.co.uk>
      Cc: stable@kernel.org
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      cb7cf419
  6. 05 Oct, 2011 10 commits
  7. 04 Oct, 2011 12 commits