1. 12 Jun, 2013 4 commits
  2. 11 Jun, 2013 7 commits
    • Patrick McHardy's avatar
      netlink: fix error propagation in netlink_mmap() · 7cdbac71
      Patrick McHardy authored
      Return the error if something went wrong instead of unconditionally
      returning 0.
      Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7cdbac71
    • Daniel Borkmann's avatar
      net: sctp: fix NULL pointer dereference in socket destruction · 1abd165e
      Daniel Borkmann authored
      While stress testing sctp sockets, I hit the following panic:
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
      IP: [<ffffffffa0490c4e>] sctp_endpoint_free+0xe/0x40 [sctp]
      PGD 7cead067 PUD 7ce76067 PMD 0
      Oops: 0000 [#1] SMP
      Modules linked in: sctp(F) libcrc32c(F) [...]
      CPU: 7 PID: 2950 Comm: acc Tainted: GF            3.10.0-rc2+ #1
      Hardware name: Dell Inc. PowerEdge T410/0H19HD, BIOS 1.6.3 02/01/2011
      task: ffff88007ce0e0c0 ti: ffff88007b568000 task.ti: ffff88007b568000
      RIP: 0010:[<ffffffffa0490c4e>]  [<ffffffffa0490c4e>] sctp_endpoint_free+0xe/0x40 [sctp]
      RSP: 0018:ffff88007b569e08  EFLAGS: 00010292
      RAX: 0000000000000000 RBX: ffff88007db78a00 RCX: dead000000200200
      RDX: ffffffffa049fdb0 RSI: ffff8800379baf38 RDI: 0000000000000000
      RBP: ffff88007b569e18 R08: ffff88007c230da0 R09: 0000000000000001
      R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
      R13: ffff880077990d00 R14: 0000000000000084 R15: ffff88007db78a00
      FS:  00007fc18ab61700(0000) GS:ffff88007fc60000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: 0000000000000020 CR3: 000000007cf9d000 CR4: 00000000000007e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Stack:
       ffff88007b569e38 ffff88007db78a00 ffff88007b569e38 ffffffffa049fded
       ffffffff81abf0c0 ffff88007db78a00 ffff88007b569e58 ffffffff8145b60e
       0000000000000000 0000000000000000 ffff88007b569eb8 ffffffff814df36e
      Call Trace:
       [<ffffffffa049fded>] sctp_destroy_sock+0x3d/0x80 [sctp]
       [<ffffffff8145b60e>] sk_common_release+0x1e/0xf0
       [<ffffffff814df36e>] inet_create+0x2ae/0x350
       [<ffffffff81455a6f>] __sock_create+0x11f/0x240
       [<ffffffff81455bf0>] sock_create+0x30/0x40
       [<ffffffff8145696c>] SyS_socket+0x4c/0xc0
       [<ffffffff815403be>] ? do_page_fault+0xe/0x10
       [<ffffffff8153cb32>] ? page_fault+0x22/0x30
       [<ffffffff81544e02>] system_call_fastpath+0x16/0x1b
      Code: 0c c9 c3 66 2e 0f 1f 84 00 00 00 00 00 e8 fb fe ff ff c9 c3 66 0f
            1f 84 00 00 00 00 00 55 48 89 e5 53 48 83 ec 08 66 66 66 66 90 <48>
            8b 47 20 48 89 fb c6 47 1c 01 c6 40 12 07 e8 9e 68 01 00 48
      RIP  [<ffffffffa0490c4e>] sctp_endpoint_free+0xe/0x40 [sctp]
       RSP <ffff88007b569e08>
      CR2: 0000000000000020
      ---[ end trace e0d71ec1108c1dd9 ]---
      
      I did not hit this with the lksctp-tools functional tests, but with a
      small, multi-threaded test program, that heavily allocates, binds,
      listens and waits in accept on sctp sockets, and then randomly kills
      some of them (no need for an actual client in this case to hit this).
      Then, again, allocating, binding, etc, and then killing child processes.
      
      This panic then only occurs when ``echo 1 > /proc/sys/net/sctp/auth_enable''
      is set. The cause for that is actually very simple: in sctp_endpoint_init()
      we enter the path of sctp_auth_init_hmacs(). There, we try to allocate
      our crypto transforms through crypto_alloc_hash(). In our scenario,
      it then can happen that crypto_alloc_hash() fails with -EINTR from
      crypto_larval_wait(), thus we bail out and release the socket via
      sk_common_release(), sctp_destroy_sock() and hit the NULL pointer
      dereference as soon as we try to access members in the endpoint during
      sctp_endpoint_free(), since endpoint at that time is still NULL. Now,
      if we have that case, we do not need to do any cleanup work and just
      leave the destruction handler.
      Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Acked-by: default avatarVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1abd165e
    • Michael S. Tsirkin's avatar
      vhost: fix ubuf_info cleanup · 288cfe78
      Michael S. Tsirkin authored
      vhost_net_clear_ubuf_info didn't clear ubuf_info
      after kfree, this could trigger double free.
      Fix this and simplify this code to make it more robust: make sure
      ubuf info is always freed through vhost_net_clear_ubuf_info.
      Reported-by: default avatarTommi Rantala <tt.rantala@gmail.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      288cfe78
    • Michael S. Tsirkin's avatar
      vhost: check owner before we overwrite ubuf_info · 05c05351
      Michael S. Tsirkin authored
      If device has an owner, we shouldn't touch ubuf_info
      since it might be in use.
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      05c05351
    • Bjørn Mork's avatar
      qmi_wwan/cdc_ether: let qmi_wwan handle the Huawei E1820 · c2020be3
      Bjørn Mork authored
      Another QMI speaking Qualcomm based device, which should be
      driven by qmi_wwan, while cdc_ether should ignore it.
      
      Like on other Huawei devices, the wwan function can appear
      either as a single vendor specific interface or as a CDC ECM
      class function using separate control and data interfaces.
      The ECM control interface protocol is 0xff, likely in an
      attempt to indicate that vendor specific management is
      required.
      
      In addition to the near standard CDC class, Huawei also add
      vendor specific AT management commands to their firmwares.
      This is probably an attempt to support non-Windows systems
      using standard class drivers.  Unfortunately, this part of
      the firmware is often buggy.  Linux is much better off using
      whatever native vendor specific management protocol the
      device offers, and Windows uses, whenever possible. This
      means QMI in the case of Qualcomm based devices.
      
      The E1820 has been verified to work fine with QMI.
      
      Matching on interface number is necessary to distiguish the
      wwan function from serial functions in the single interface
      mode, as both function types will have class/subclass/function
      set to ff/ff/ff.
      
      The control interface number does not change in CDC ECM mode,
      so the interface number matching rule is sufficient to handle
      both modes.  The cdc_ether blacklist entry is only relevant in
      CDC ECM mode, but using a similar interface number based rule
      helps document this as a transfer from one driver to another.
      
      Other Huawei 02/06/ff devices are left with the cdc_ether driver
      because we do not know whether they are based on Qualcomm chips.
      The Huawei specific AT command management is known to be somewhat
      hardware independent, and their usage of these class codes may
      also be independent of the modem hardware.
      Reported-by: default avatarGraham Inggs <graham.inggs@uct.ac.za>
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c2020be3
    • Sergei Shtylyov's avatar
      sh_eth: fix result of sh_eth_check_reset() on timeout · 9f8c4265
      Sergei Shtylyov authored
      When  the first loop in sh_eth_check_reset() runs to its end, 'cnt' is 0, so the
      following check for 'cnt < 0' fails to catch the timeout.  Fix the  condition in
      this check, so that the timeout  is actually reported.
      While at it, fix the grammar in the failure message...
      Signed-off-by: default avatarSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9f8c4265
    • Sebastian Siewior's avatar
      net/ti davinci_mdio: don't hold a spin lock while calling pm_runtime · 2786aae7
      Sebastian Siewior authored
      was playing with suspend and run into this:
      
      |BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:891
      |in_atomic(): 1, irqs_disabled(): 0, pid: 1963, name: bash
      |6 locks held by bash/1963:
      |CPU: 0 PID: 1963 Comm: bash Not tainted 3.10.0-rc4+ #50
      |[<c0014fdc>] (unwind_backtrace+0x0/0xf8) from [<c0011da4>] (show_stack+0x10/0x14)
      |[<c0011da4>] (show_stack+0x10/0x14) from [<c02e8680>] (__pm_runtime_idle+0xa4/0xac)
      |[<c02e8680>] (__pm_runtime_idle+0xa4/0xac) from [<c0341158>] (davinci_mdio_suspend+0x6c/0x9c)
      |[<c0341158>] (davinci_mdio_suspend+0x6c/0x9c) from [<c02e0628>] (platform_pm_suspend+0x2c/0x54)
      |[<c02e0628>] (platform_pm_suspend+0x2c/0x54) from [<c02e52bc>] (dpm_run_callback.isra.3+0x2c/0x64)
      |[<c02e52bc>] (dpm_run_callback.isra.3+0x2c/0x64) from [<c02e57e4>] (__device_suspend+0x100/0x22c)
      |[<c02e57e4>] (__device_suspend+0x100/0x22c) from [<c02e67e8>] (dpm_suspend+0x68/0x230)
      |[<c02e67e8>] (dpm_suspend+0x68/0x230) from [<c0072a20>] (suspend_devices_and_enter+0x68/0x350)
      |[<c0072a20>] (suspend_devices_and_enter+0x68/0x350) from [<c0072f18>] (pm_suspend+0x210/0x24c)
      |[<c0072f18>] (pm_suspend+0x210/0x24c) from [<c0071c74>] (state_store+0x6c/0xbc)
      |[<c0071c74>] (state_store+0x6c/0xbc) from [<c02714dc>] (kobj_attr_store+0x14/0x20)
      |[<c02714dc>] (kobj_attr_store+0x14/0x20) from [<c01341a0>] (sysfs_write_file+0x16c/0x19c)
      |[<c01341a0>] (sysfs_write_file+0x16c/0x19c) from [<c00ddfe4>] (vfs_write+0xb4/0x190)
      |[<c00ddfe4>] (vfs_write+0xb4/0x190) from [<c00de3a4>] (SyS_write+0x3c/0x70)
      |[<c00de3a4>] (SyS_write+0x3c/0x70) from [<c000e2c0>] (ret_fast_syscall+0x0/0x48)
      
      I don't see a reason why the pm_runtime call must be under the lock.
      Further I don't understand why this is a spinlock and not mutex.
      
      Cc: Mugunthan V N <mugunthanvnm@ti.com>
      Signed-off-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Acked-by: default avatarMugunthan V N <mugunthanvnm@ti.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2786aae7
  3. 10 Jun, 2013 5 commits
  4. 07 Jun, 2013 2 commits
  5. 06 Jun, 2013 16 commits
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net · 1612e111
      Linus Torvalds authored
      Pull networking fix from David Miller:
       "This is a quick one commit pull request to cure the regression
        introduced by the MSG_CMSG_COMPAT change."
      
      (Background: commit 1be374a0 completely broke 32-bit COMPAT handling
      by not only disallowing MSG_CMSG_COMPAT from user APIs, but clearing it
      in our own internal use too!)
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net:
        net: Unbreak compat_sys_{send,recv}msg
      1612e111
    • Linus Torvalds's avatar
      Merge tag 'staging-3.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging · e2b02e25
      Linus Torvalds authored
      Pull staging driver fixes from Greg Kroah-Hartman:
       "Here are some staging and IIO driver fixes for the 3.10-rc5 release.
      
        All of them are tiny, and fix a number of reported issues (build and
        runtime)"
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      * tag 'staging-3.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
        iio:inkern: Fix typo/bug in convert raw to processed.
        iio: frequency: ad4350: Fix bug / typo in mask
        inkern: iio_device_put after incorrect return/goto
        staging: alarm-dev: information leak in alarm_compat_ioctl()
        iio:callback buffer: free the scan_mask
        staging: alarm-dev: information leak in alarm_ioctl()
        drivers: staging: zcache: fix compile error
        staging: dwc2: fix value of dma_mask
      e2b02e25
    • Linus Torvalds's avatar
      Merge tag 'tty-3.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty · 3b285cb2
      Linus Torvalds authored
      Pull tty/serial driver fixes from Greg Kroah-Hartman:
       "Here are some small bugfixes, and one revert, of serial driver issues
        that have been reported"
      
      * tag 'tty-3.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
        Revert "serial: 8250: Make SERIAL_8250_RUNTIME_UARTS work correctly"
        serial: samsung: enable clock before clearing pending interrupts during init
        serial/imx: disable hardware flow control at startup
      3b285cb2
    • Linus Torvalds's avatar
      Merge tag 'usb-3.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb · c6d6b9d1
      Linus Torvalds authored
      Pull USB fixes from Greg Kroah-Hartman:
       "Here are a number of USB bugfixes and new device ids for the 3.10-rc5
        tree.
      
        Nothing major here, a number of new device ids (and movement from the
        option to the zte_ev driver of a number of ids that we had previously
        gotten wrong, some xhci bugfixes, some usb-serial driver fixes that
        were recently found, some host controller fixes / reverts, and a
        variety of smaller other things"
      
      * tag 'usb-3.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (29 commits)
        USB: option,zte_ev: move most ZTE CDMA devices to zte_ev
        USB: option: blacklist network interface on Huawei E1820
        USB: whiteheat: fix broken port configuration
        USB: serial: fix TIOCMIWAIT return value
        USB: mos7720: fix hardware flow control
        USB: keyspan: remove unused endpoint-array access
        USB: keyspan: fix bogus array index
        USB: zte_ev: fix broken open
        USB: serial: Add Option GTM681W to qcserial device table.
        USB: Serial: cypress_M8: Enable FRWD Dongle hidcom device
        USB: EHCI: fix regression related to qh_refresh()
        usbfs: Increase arbitrary limit for USB 3 isopkt length
        USB: zte_ev: fix control-message timeouts
        USB: mos7720: fix message timeouts
        USB: iuu_phoenix: fix bulk-message timeout
        USB: ark3116: fix control-message timeout
        USB: mos7840: fix DMA to stack
        USB: mos7720: fix DMA to stack
        USB: visor: fix initialisation of Treo/Kyocera devices
        USB: serial: fix Treo/Kyocera interrrupt-in urb context
        ...
      c6d6b9d1
    • Linus Torvalds's avatar
      Merge tag 'pci-v3.10-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci · c51aa6db
      Linus Torvalds authored
      Pull PCI fixes from Bjorn Helgaas:
       "This fixes a crash when booting a 32-bit kernel via the EFI boot stub.
      
        PCI ROM from EFI
            x86/PCI: Map PCI setup data with ioremap() so it can be in highmem"
      
      * tag 'pci-v3.10-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci:
        x86/PCI: Map PCI setup data with ioremap() so it can be in highmem
      c51aa6db
    • Linus Torvalds's avatar
      Merge tag 'for-linus-v3.10-rc5' of git://oss.sgi.com/xfs/xfs · e6395b68
      Linus Torvalds authored
      Pull more xfs updates from Ben Myers:
       "Here are several fixes for filesystems with CRC support turned on:
        fixes for quota, remote attributes, and recovery.  There is also some
        feature work related to CRCs: the implementation of CRCs for the inode
        unlinked lists, disabling noattr2/attr2 options when appropriate, and
        bumping the maximum number of ACLs.
      
        I would have preferred to defer this last category of items to 3.11.
        This would require setting a feature bit for the on-disk changes, so
        there is some pressure to get these in 3.10.  I believe this
        represents the end of the CRC related queue.
      
         - Rework of dquot CRCs
         - Fix for remote attribute invalidation of a leaf
         - Fix ordering of transaction replay in recovery
         - Implement CRCs for inode unlinked list
         - Disable noattr2/attr2 mount options when CRCs are enabled
         - Bump the limitation of ACL entries for v5 superblocks"
      
      * tag 'for-linus-v3.10-rc5' of git://oss.sgi.com/xfs/xfs:
        xfs: increase number of ACL entries for V5 superblocks
        xfs: disable noattr2/attr2 mount options for CRC enabled filesystems
        xfs: inode unlinked list needs to recalculate the inode CRC
        xfs: fix log recovery transaction item reordering
        xfs: fix remote attribute invalidation for a leaf
        xfs: rework dquot CRCs
      e6395b68
    • Andy Lutomirski's avatar
      net: Unbreak compat_sys_{send,recv}msg · a7526eb5
      Andy Lutomirski authored
      I broke them in this commit:
      
          commit 1be374a0
          Author: Andy Lutomirski <luto@amacapital.net>
          Date:   Wed May 22 14:07:44 2013 -0700
      
              net: Block MSG_CMSG_COMPAT in send(m)msg and recv(m)msg
      
      This patch adds __sys_sendmsg and __sys_sendmsg as common helpers that accept
      MSG_CMSG_COMPAT and blocks MSG_CMSG_COMPAT at the syscall entrypoints.  It
      also reverts some unnecessary checks in sys_socketcall.
      
      Apparently I was suffering from underscore blindness the first time around.
      Signed-off-by: default avatarAndy Lutomirski <luto@amacapital.net>
      Tested-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a7526eb5
    • Dan Williams's avatar
      USB: option,zte_ev: move most ZTE CDMA devices to zte_ev · 73228a05
      Dan Williams authored
      Per some ZTE Linux drivers I found for the AC2716, the following patch
      moves most ZTE CDMA devices from option to zte_ev.  The blacklist stuff
      that option does is not required with zte_ev, because it doesn't
      implement any of the send_setup hooks which the blacklist suppressed.
      
      I did not move the 2718 over because I could not find any ZTE Linux
      drivers for that device, nor even any Windows drivers.
      Signed-off-by: default avatarDan Williams <dcbw@redhat.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      73228a05
    • Bjørn Mork's avatar
      USB: option: blacklist network interface on Huawei E1820 · b8a24e62
      Bjørn Mork authored
      The mode used by Windows for the Huawei E1820 will use the
      same ff/ff/ff class codes for both serial and network
      functions.
      Reported-by: default avatarGraham Inggs <graham.inggs@uct.ac.za>
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b8a24e62
    • Johan Hovold's avatar
      USB: whiteheat: fix broken port configuration · 9eecf22d
      Johan Hovold authored
      When configuring the port (e.g. set_termios) the port minor number
      rather than the port number was used in the request (and they only
      coincide for minor number 0).
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJohan Hovold <jhovold@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9eecf22d
    • Dave Chinner's avatar
      xfs: increase number of ACL entries for V5 superblocks · 0a8aa193
      Dave Chinner authored
      The limit of 25 ACL entries is arbitrary, but baked into the on-disk
      format.  For version 5 superblocks, increase it to the maximum nuber
      of ACLs that can fit into a single xattr.
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
      Reviewed-by: default avatarMark Tinguely <tinuguely@sgi.com>
      Signed-off-by: default avatarBen Myers <bpm@sgi.com>
      
      (cherry picked from commit 5c87d4bc)
      0a8aa193
    • Dave Chinner's avatar
      xfs: disable noattr2/attr2 mount options for CRC enabled filesystems · f763fd44
      Dave Chinner authored
      attr2 format is always enabled for v5 superblock filesystems, so the
      mount options to enable or disable it need to be cause mount errors.
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
      Signed-off-by: default avatarBen Myers <bpm@sgi.com>
      
      (cherry picked from commit d3eaace8)
      f763fd44
    • Dave Chinner's avatar
      xfs: inode unlinked list needs to recalculate the inode CRC · ad868afd
      Dave Chinner authored
      The inode unlinked list manipulations operate directly on the inode
      buffer, and so bypass the inode CRC calculation mechanisms. Hence an
      inode on the unlinked list has an invalid CRC. Fix this by
      recalculating the CRC whenever we modify an unlinked list pointer in
      an inode, ncluding during log recovery. This is trivial to do and
      results in  unlinked list operations always leaving a consistent
      inode in the buffer.
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarMark Tinguely <tinguely@sgi.com>
      Signed-off-by: default avatarBen Myers <bpm@sgi.com>
      
      (cherry picked from commit 0a32c26e)
      ad868afd
    • Dave Chinner's avatar
      xfs: fix log recovery transaction item reordering · 75406170
      Dave Chinner authored
      There are several constraints that inode allocation and unlink
      logging impose on log recovery. These all stem from the fact that
      inode alloc/unlink are logged in buffers, but all other inode
      changes are logged in inode items. Hence there are ordering
      constraints that recovery must follow to ensure the correct result
      occurs.
      
      As it turns out, this ordering has been working mostly by chance
      than good management. The existing code moves all buffers except
      cancelled buffers to the head of the list, and everything else to
      the tail of the list. The problem with this is that is interleaves
      inode items with the buffer cancellation items, and hence whether
      the inode item in an cancelled buffer gets replayed is essentially
      left to chance.
      
      Further, this ordering causes problems for log recovery when inode
      CRCs are enabled. It typically replays the inode unlink buffer long before
      it replays the inode core changes, and so the CRC recorded in an
      unlink buffer is going to be invalid and hence any attempt to
      validate the inode in the buffer is going to fail. Hence we really
      need to enforce the ordering that the inode alloc/unlink code has
      expected log recovery to have since inode chunk de-allocation was
      introduced back in 2003...
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarMark Tinguely <tinguely@sgi.com>
      Signed-off-by: default avatarBen Myers <bpm@sgi.com>
      
      (cherry picked from commit a775ad77)
      75406170
    • Dave Chinner's avatar
      xfs: fix remote attribute invalidation for a leaf · ea929536
      Dave Chinner authored
      When invalidating an attribute leaf block block, there might be
      remote attributes that it points to. With the recent rework of the
      remote attribute format, we have to make sure we calculate the
      length of the attribute correctly. We aren't doing that in
      xfs_attr3_leaf_inactive(), so fix it.
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
      Reviewed-by: default avatarMark Tinguely <tinuguely@sgi.com>
      Signed-off-by: default avatarBen Myers <bpm@sgi.com>
      
      (cherry picked from commit 59913f14)
      ea929536
    • Dave Chinner's avatar
      xfs: rework dquot CRCs · bb9b8e86
      Dave Chinner authored
      Calculating dquot CRCs when the backing buffer is written back just
      doesn't work reliably. There are several places which manipulate
      dquots directly in the buffers, and they don't calculate CRCs
      appropriately, nor do they always set the buffer up to calculate
      CRCs appropriately.
      
      Firstly, if we log a dquot buffer (e.g. during allocation) it gets
      logged without valid CRC, and so on recovery we end up with a dquot
      that is not valid.
      
      Secondly, if we recover/repair a dquot, we don't have a verifier
      attached to the buffer and hence CRCs are not calculated on the way
      down to disk.
      
      Thirdly, calculating the CRC after we've changed the contents means
      that if we re-read the dquot from the buffer, we cannot verify the
      contents of the dquot are valid, as the CRC is invalid.
      
      So, to avoid all the dquot CRC errors that are being detected by the
      read verifier, change to using the same model as for inodes. That
      is, dquot CRCs are calculated and written to the backing buffer at
      the time the dquot is flushed to the backing buffer. If we modify
      the dquot directly in the backing buffer, calculate the CRC
      immediately after the modification is complete. Hence the dquot in
      the on-disk buffer should always have a valid CRC.
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
      Reviewed-by: default avatarBen Myers <bpm@sgi.com>
      Signed-off-by: default avatarBen Myers <bpm@sgi.com>
      
      (cherry picked from commit 6fcdc59d)
      bb9b8e86
  6. 05 Jun, 2013 6 commits