1. 23 May, 2011 5 commits
    • Josef Bacik's avatar
      Btrfs: fix how we do space reservation for truncate · fcb80c2a
      Josef Bacik authored
      The ceph guys keep running into problems where we have space reserved in our
      orphan block rsv when freeing it up.  This is because they tend to do snapshots
      alot, so their truncates tend to use a bunch of space, so when we go to do
      things like update the inode we have to steal reservation space in order to make
      the reservation happen.  This happens because truncate can use as much space as
      it freaking feels like, but we still have to hold space for removing the orphan
      item and updating the inode, which will definitely always happen.  So in order
      to fix this we need to split all of the reservation stuf up.  So with this patch
      we have
      
      1) The orphan block reserve which only holds the space for deleting our orphan
      item when everything is over.
      
      2) The truncate block reserve which gets allocated and used specifically for the
      space that the truncate will use on a per truncate basis.
      
      3) The transaction will always have 1 item's worth of data reserved so we can
      update the inode normally.
      
      Hopefully this will make the ceph problem go away.  Thanks,
      Signed-off-by: default avatarJosef Bacik <josef@redhat.com>
      fcb80c2a
    • Josef Bacik's avatar
      Btrfs: kill trans_mutex · a4abeea4
      Josef Bacik authored
      We use trans_mutex for lots of things, here's a basic list
      
      1) To serialize trans_handles joining the currently running transaction
      2) To make sure that no new trans handles are started while we are committing
      3) To protect the dead_roots list and the transaction lists
      
      Really the serializing trans_handles joining is not too hard, and can really get
      bogged down in acquiring a reference to the transaction.  So replace the
      trans_mutex with a trans_lock spinlock and use it to do the following
      
      1) Protect fs_info->running_transaction.  All trans handles have to do is check
      this, and then take a reference of the transaction and keep on going.
      2) Protect the fs_info->trans_list.  This doesn't get used too much, basically
      it just holds the current transactions, which will usually just be the currently
      committing transaction and the currently running transaction at most.
      3) Protect the dead roots list.  This is only ever processed by splicing the
      list so this is relatively simple.
      4) Protect the fs_info->reloc_ctl stuff.  This is very lightweight and was using
      the trans_mutex before, so this is a pretty straightforward change.
      5) Protect fs_info->no_trans_join.  Because we don't hold the trans_lock over
      the entirety of the commit we need to have a way to block new people from
      creating a new transaction while we're doing our work.  So we set no_trans_join
      and in join_transaction we test to see if that is set, and if it is we do a
      wait_on_commit.
      6) Make the transaction use count atomic so we don't need to take locks to
      modify it when we're dropping references.
      7) Add a commit_lock to the transaction to make sure multiple people trying to
      commit the same transaction don't race and commit at the same time.
      8) Make open_ioctl_trans an atomic so we don't have to take any locks for ioctl
      trans.
      
      I have tested this with xfstests, but obviously it is a pretty hairy change so
      lots of testing is greatly appreciated.  Thanks,
      Signed-off-by: default avatarJosef Bacik <josef@redhat.com>
      a4abeea4
    • Josef Bacik's avatar
      Btrfs: if we've already started a trans handle, use that one · 2a1eb461
      Josef Bacik authored
      We currently track trans handles in current->journal_info, but we don't actually
      use it.  This patch fixes it.  This will cover the case where we have multiple
      people starting transactions down the call chain.  This keeps us from having to
      allocate a new handle and all of that, we just increase the use count of the
      current handle, save the old block_rsv, and return.  I tested this with xfstests
      and it worked out fine.  Thanks,
      Signed-off-by: default avatarJosef Bacik <josef@redhat.com>
      2a1eb461
    • Josef Bacik's avatar
      Btrfs: take away the num_items argument from btrfs_join_transaction · 7a7eaa40
      Josef Bacik authored
      I keep forgetting that btrfs_join_transaction() just ignores the num_items
      argument, which leads me to sending pointless patches and looking stupid :).  So
      just kill the num_items argument from btrfs_join_transaction and
      btrfs_start_ioctl_transaction, since neither of them use it.  Thanks,
      Signed-off-by: default avatarJosef Bacik <josef@redhat.com>
      7a7eaa40
    • Josef Bacik's avatar
      Btrfs: make sure to use the delalloc reserve when filling delalloc · 74b21075
      Josef Bacik authored
      In the prealloc filling code and compressed code we don't set trans->block_rsv
      to the delalloc block reserve properly, which is going to make us use metadata
      from the wrong pool, this patch fixes that.  Thanks,
      Signed-off-by: default avatarJosef Bacik <josef@redhat.com>
      74b21075
  2. 19 May, 2011 1 commit
  3. 18 May, 2011 22 commits
  4. 17 May, 2011 10 commits
    • Jeff Layton's avatar
      cifs: fix cifsConvertToUCS() for the mapchars case · 11379b5e
      Jeff Layton authored
      As Metze pointed out, commit 84cdf74e broke mapchars option:
      
          Commit "cifs: fix unaligned accesses in cifsConvertToUCS"
          (84cdf74e) does multiple steps
          in just one commit (moving the function and changing it without
          testing).
      
          put_unaligned_le16(temp, &target[j]); is never called for any
          codepoint the goes via the 'default' switch statement. As a result
          we put just zero (or maybe uninitialized) bytes into the target
          buffer.
      
      His proposed patch looks correct, but doesn't apply to the current head
      of the tree. This patch should also fix it.
      
      Cc: <stable@kernel.org> # .38.x: 581ade4d: cifs: clean up various nits in unicode routines (try #2)
      Reported-by: default avatarStefan Metzmacher <metze@samba.org>
      Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      Signed-off-by: default avatarSteve French <sfrench@us.ibm.com>
      11379b5e
    • Jeff Layton's avatar
      cifs: add fallback in is_path_accessible for old servers · 221d1d79
      Jeff Layton authored
      The is_path_accessible check uses a QPathInfo call, which isn't
      supported by ancient win9x era servers. Fall back to an older
      SMBQueryInfo call if it fails with the magic error codes.
      
      Cc: stable@kernel.org
      Reported-and-Tested-by: default avatarSandro Bonazzola <sandro.bonazzola@gmail.com>
      Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      Signed-off-by: default avatarSteve French <sfrench@us.ibm.com>
      221d1d79
    • Linus Torvalds's avatar
      Merge branch 'timers-fixes-for-linus' of... · a085963a
      Linus Torvalds authored
      Merge branch 'timers-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
      
      * 'timers-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
        tick: Clear broadcast active bit when switching to oneshot
        rtc: mc13xxx: Don't call rtc_device_register while holding lock
        rtc: rp5c01: Initialize drvdata before registering device
        rtc: pcap: Initialize drvdata before registering device
        rtc: msm6242: Initialize drvdata before registering device
        rtc: max8998: Initialize drvdata before registering device
        rtc: max8925: Initialize drvdata before registering device
        rtc: m41t80: Initialize clientdata before registering device
        rtc: ds1286: Initialize drvdata before registering device
        rtc: ep93xx: Initialize drvdata before registering device
        rtc: davinci: Initialize drvdata before registering device
        rtc: mxc: Initialize drvdata before registering device
        clocksource: Install completely before selecting
      a085963a
    • Borislav Petkov's avatar
      x86, AMD: Fix ARAT feature setting again · 14fb57dc
      Borislav Petkov authored
      Trying to enable the local APIC timer on early K8 revisions
      uncovers a number of other issues with it, in conjunction with
      the C1E enter path on AMD. Fixing those causes much more churn
      and troubles than the benefit of using that timer brings so
      don't enable it on K8 at all, falling back to the original
      functionality the kernel had wrt to that.
      Reported-and-bisected-by: default avatarNick Bowler <nbowler@elliptictech.com>
      Cc: Boris Ostrovsky <Boris.Ostrovsky@amd.com>
      Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
      Cc: Greg Kroah-Hartman <greg@kroah.com>
      Cc: Hans Rosenfeld <hans.rosenfeld@amd.com>
      Cc: Nick Bowler <nbowler@elliptictech.com>
      Cc: Joerg-Volker-Peetz <jvpeetz@web.de>
      Signed-off-by: default avatarBorislav Petkov <borislav.petkov@amd.com>
      Link: http://lkml.kernel.org/r/1305636919-31165-3-git-send-email-bp@amd64.orgSigned-off-by: default avatarIngo Molnar <mingo@elte.hu>
      14fb57dc
    • Borislav Petkov's avatar
      Revert "x86, AMD: Fix APIC timer erratum 400 affecting K8 Rev.A-E processors" · 328935e6
      Borislav Petkov authored
      This reverts commit e20a2d20, as it crashes
      certain boxes with specific AMD CPU models.
      
      Moving the lower endpoint of the Erratum 400 check to accomodate
      earlier K8 revisions (A-E) opens a can of worms which is simply
      not worth to fix properly by tweaking the errata checking
      framework:
      
      * missing IntPenging MSR on revisions < CG cause #GP:
      
      http://marc.info/?l=linux-kernel&m=130541471818831
      
      * makes earlier revisions use the LAPIC timer instead of the C1E
      idle routine which switches to HPET, thus not waking up in
      deeper C-states:
      
      http://lkml.org/lkml/2011/4/24/20
      
      Therefore, leave the original boundary starting with K8-revF.
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      328935e6
    • Jens Axboe's avatar
      scsi: remove performance regression due to async queue run · 9937a5e2
      Jens Axboe authored
      Commit c21e6beb removed our queue request_fn re-enter
      protection, and defaulted to always running the queues from
      kblockd to be safe. This was a known potential slow down,
      but should be safe.
      
      Unfortunately this is causing big performance regressions for
      some, so we need to improve this logic. Looking into the details
      of the re-enter, the real issue is on requeue of requests.
      
      Requeue of requests upon seeing a BUSY condition from the device
      ends up re-running the queue, causing traces like this:
      
      scsi_request_fn()
              scsi_dispatch_cmd()
                      scsi_queue_insert()
                              __scsi_queue_insert()
                                      scsi_run_queue()
      					scsi_request_fn()
      						...
      
      potentially causing the issue we want to avoid. So special
      case the requeue re-run of the queue, but improve it to offload
      the entire run of local queue and starved queue from a single
      workqueue callback. This is a lot better than potentially
      kicking off a workqueue run for each device seen.
      
      This also fixes the issue of the local device going into recursion,
      since the above mentioned commit never moved that queue run out
      of line.
      Signed-off-by: default avatarJens Axboe <jaxboe@fusionio.com>
      9937a5e2
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6 · c1d10d18
      Linus Torvalds authored
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6:
        net: Change netdev_fix_features messages loglevel
        vmxnet3: Fix inconsistent LRO state after initialization
        sfc: Fix oops in register dump after mapping change
        IPVS: fix netns if reading ip_vs_* procfs entries
        bridge: fix forwarding of IPv6
      c1d10d18
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc · 477de0de
      Linus Torvalds authored
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc:
        Revert "mmc: fix a race between card-detect rescan and clock-gate work instances"
      477de0de
    • Randy Dunlap's avatar
      mm: fix kernel-doc warning in page_alloc.c · b5e6ab58
      Randy Dunlap authored
      Fix new kernel-doc warning in mm/page_alloc.c:
      
        Warning(mm/page_alloc.c:2370): No description found for parameter 'nid'
      Signed-off-by: default avatarRandy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b5e6ab58
    • Yinghai Lu's avatar
      PCI: Clear bridge resource flags if requested size is 0 · 93d2175d
      Yinghai Lu authored
      During pci remove/rescan testing found:
      
        pci 0000:c0:03.0: PCI bridge to [bus c4-c9]
        pci 0000:c0:03.0:   bridge window [io  0x1000-0x0fff]
        pci 0000:c0:03.0:   bridge window [mem 0xf0000000-0xf00fffff]
        pci 0000:c0:03.0:   bridge window [mem 0xfc180000000-0xfc197ffffff 64bit pref]
        pci 0000:c0:03.0: device not available (can't reserve [io  0x1000-0x0fff])
        pci 0000:c0:03.0: Error enabling bridge (-22), continuing
        pci 0000:c0:03.0: enabling bus mastering
        pci 0000:c0:03.0: setting latency timer to 64
        pcieport 0000:c0:03.0: device not available (can't reserve [io  0x1000-0x0fff])
        pcieport: probe of 0000:c0:03.0 failed with error -22
      
      This bug was caused by commit c8adf9a3 ("PCI: pre-allocate
      additional resources to devices only after successful allocation of
      essential resources.")
      
      After that commit, pci_hotplug_io_size is changed to additional_io_size
      from minium size.  So it will not go through resource_size(res) != 0
      path, and will not be reset.
      
      The root cause is: pci_bridge_check_ranges will set RESOURCE_IO flag for
      pci bridge, and later if children do not need IO resource.  those bridge
      resources will not need to be allocated.  but flags is still there.
      that will confuse the the pci_enable_bridges later.
      
      related code:
      
         static void assign_requested_resources_sorted(struct resource_list *head,
                                          struct resource_list_x *fail_head)
         {
                 struct resource *res;
                 struct resource_list *list;
                 int idx;
      
                 for (list = head->next; list; list = list->next) {
                         res = list->res;
                         idx = res - &list->dev->resource[0];
                         if (resource_size(res) && pci_assign_resource(list->dev, idx)) {
         ...
                                 reset_resource(res);
                         }
                 }
         }
      
      At last, We have to clear the flags in pbus_size_mem/io when requested
      size == 0 and !add_head.  becasue this case it will not go through
      adjust_resources_sorted().
      
      Just make size1 = size0 when !add_head. it will make flags get cleared.
      
      At the same time when requested size == 0, add_size != 0, will still
      have in head and add_list.  because we do not clear the flags for it.
      
      After this, we will get right result:
      
        pci 0000:c0:03.0: PCI bridge to [bus c4-c9]
        pci 0000:c0:03.0:   bridge window [io  disabled]
        pci 0000:c0:03.0:   bridge window [mem 0xf0000000-0xf00fffff]
        pci 0000:c0:03.0:   bridge window [mem 0xfc180000000-0xfc197ffffff 64bit pref]
        pci 0000:c0:03.0: enabling bus mastering
        pci 0000:c0:03.0: setting latency timer to 64
        pcieport 0000:c0:03.0: setting latency timer to 64
        pcieport 0000:c0:03.0: irq 160 for MSI/MSI-X
        pcieport 0000:c0:03.0: Signaling PME through PCIe PME interrupt
        pci 0000:c4:00.0: Signaling PME through PCIe PME interrupt
        pcie_pme 0000:c0:03.0:pcie01: service driver pcie_pme loaded
        aer 0000:c0:03.0:pcie02: service driver aer loaded
        pciehp 0000:c0:03.0:pcie04: Hotplug Controller:
      
      v3: more simple fix. also fix one typo in pbus_size_mem
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      Reviewed-by: default avatarRam Pai <linuxram@us.ibm.com>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      93d2175d
  5. 16 May, 2011 2 commits
    • Thomas Gleixner's avatar
      tick: Clear broadcast active bit when switching to oneshot · 07f4beb0
      Thomas Gleixner authored
      The first cpu which switches from periodic to oneshot mode switches
      also the broadcast device into oneshot mode. The broadcast device
      serves as a backup for per cpu timers which stop in deeper
      C-states. To avoid starvation of the cpus which might be in idle and
      depend on broadcast mode it marks the other cpus as broadcast active
      and sets the brodcast expiry value of those cpus to the next tick.
      
      The oneshot mode broadcast bit for the other cpus is sticky and gets
      only cleared when those cpus exit idle. If a cpu was not idle while
      the bit got set in consequence the bit prevents that the broadcast
      device is armed on behalf of that cpu when it enters idle for the
      first time after it switched to oneshot mode.
      
      In most cases that goes unnoticed as one of the other cpus has usually
      a timer pending which keeps the broadcast device armed with a short
      timeout. Now if the only cpu which has a short timer active has the
      bit set then the broadcast device will not be armed on behalf of that
      cpu and will fire way after the expected timer expiry. In the case of
      Christians bug report it took ~145 seconds which is about half of the
      wrap around time of HPET (the limit for that device) due to the fact
      that all other cpus had no timers armed which expired before the 145
      seconds timeframe.
      
      The solution is simply to clear the broadcast active bit
      unconditionally when a cpu switches to oneshot mode after the first
      cpu switched the broadcast device over. It's not idle at that point
      otherwise it would not be executing that code.
      
      [ I fundamentally hate that broadcast crap. Why the heck thought some
        folks that when going into deep idle it's a brilliant concept to
        switch off the last device which brings the cpu back from that
        state? ]
      
      Thanks to Christian for providing all the valuable debug information!
      Reported-and-tested-by: default avatarChristian Hoffmann <email@christianhoffmann.info>
      Cc: John Stultz <johnstul@us.ibm.com>
      Link: http://lkml.kernel.org/r/%3Calpine.LFD.2.02.1105161105170.3078%40ionos%3E
      Cc: stable@kernel.org
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      07f4beb0
    • Michał Mirosław's avatar
      net: Change netdev_fix_features messages loglevel · 6f404e44
      Michał Mirosław authored
      Those reduced to DEBUG can possibly be triggered by unprivileged processes
      and are nothing exceptional. Illegal checksum combinations can only be
      caused by driver bug, so promote those messages to WARN.
      
      Since GSO without SG will now only cause DEBUG message from
      netdev_fix_features(), remove the workaround from register_netdevice().
      Signed-off-by: default avatarMichał Mirosław <mirq-linux@rere.qmqm.pl>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6f404e44