- 01 Jun, 2013 10 commits
-
-
Bjorn Helgaas authored
The non-PAT resource probing code failed to set the type of the LBA bus_num resource (30aa80da "parisc/PCI: register busn_res for root buses" did the corresponding thing for the PAT case). This causes incorrect resource assignments and a non-working stifb framebuffer on most parisc machines. Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
Helge Deller <deller@gmx.de>
-
Helge Deller authored
Signed-off-by:
Helge Deller <deller@gmx.de>
-
Chen Gang authored
'boot_args' is an input args, and 'boot_command_line' has a fix length. So use strlcpy() instead of strcpy() to avoid memory overflow. Signed-off-by:
Chen Gang <gang.chen@asianux.com> Acked-by:
Kyle McMartin <kyle@mcmartin.ca> Signed-off-by:
Helge Deller <deller@gmx.de>
-
Paul Bolle authored
There's a Makefile line setting cflags for CONFIG_PA7100. But that Kconfig macro doesn't exist. There is a Kconfig symbol PA7000, which covers both PA7000 and PA7100 processors. So let's use the corresponding Kconfig macro. Signed-off-by:
Paul Bolle <pebolle@tiscali.nl> Signed-off-by:
Helge Deller <deller@gmx.de>
-
Helge Deller authored
With CONFIG_DISCONTIGMEM=y and multiple physical memory areas, cat /proc/kpageflags triggers this kernel bug: kernel BUG at arch/parisc/include/asm/mmzone.h:50! CPU: 2 PID: 7848 Comm: cat Tainted: G D W 3.10.0-rc3-64bit #44 IAOQ[0]: kpageflags_read0x128/0x238 IAOQ[1]: kpageflags_read0x12c/0x238 RP(r2): proc_reg_read0xbc/0x130 Backtrace: [<00000000402ca2d4>] proc_reg_read0xbc/0x130 [<0000000040235bcc>] vfs_read0xc4/0x1d0 [<0000000040235f0c>] SyS_read0x94/0xf0 [<0000000040105fc0>] syscall_exit0x0/0x14 kpageflags_read() walks through the whole memory, even if some memory areas are physically not available. So, we should better not BUG on an unavailable pfn in pfn_to_nid() but just return the expected value -1 or 0. Signed-off-by:
Helge Deller <deller@gmx.de>
-
Chen Gang authored
'path.bc[i]' can be asigned by PCI_SLOT() which can '> 10', so sizeof(6 * "%u:" + "%u" + '\0') may be 21. Since 'name' length is 20, it may be memory overflow. And 'path.bc[i]' is 'unsigned char' for printing, we can be sure the max length of 'name' must be less than 28. So simplify thinking, we can use 28 instead of 20 directly, and do not think of whether 'patchc.bc[i]' can '> 100'. Signed-off-by:
Chen Gang <gang.chen@asianux.com> Signed-off-by:
Helge Deller <deller@gmx.de>
-
git://git.linaro.org/people/mturquette/linuxLinus Torvalds authored
Pull clock subsystem fixes from Mike Turquette: "A mix of small fixes affecting mostly ARM platforms as well as a discrete clock expander chip. Most fixes are corrections to lousy clock data of one form or another." * tag 'clk-fixes-for-linus' of git://git.linaro.org/people/mturquette/linux: clk: mxs: Include clk mxs header file clk: vt8500: Fix unbalanced spinlock in vt8500_dclk_set_rate() clk: si5351: Set initial clkout rate when defined in platform data. clk: si5351: Fix clkout rate computation. clk: samsung: Add CLK_IGNORE_UNUSED flag for the sysreg clocks clk: ux500: clk-sysctrl: handle clocks with no parents clk: ux500: Provide device enumeration number suffix for SMSC911x
-
Linus Torvalds authored
Merge tag 'fbdev-for-3.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/plagnioj/linux-fbdev Pull fbdev fixes from Jean-Christophe PLAGNIOL-VILLARD: "This contains some small fixes - Atmel LCDC: fix blank the backlight on remove - ps3fb: fix compile warning - OMAPDSS: Fix crash with DT boot" * tag 'fbdev-for-3.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/plagnioj/linux-fbdev: atmel_lcdfb: blank the backlight on remove trivial: atmel_lcdfb: add missing error message OMAPDSS: Fix crash with DT boot fbdev/ps3fb: fix compile warning
-
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfsLinus Torvalds authored
Pull assorted fixes from Al Viro: "There'll be more - I'm trying to dig out from under the pile of mail (a couple of weeks of something flu-like ;-/) and there's several more things waiting for review; this is just the obvious stuff." * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: zoran: racy refcount handling in vm_ops ->open()/->close() befs_readdir(): do not increment ->f_pos if filldir tells us to stop hpfs: deadlock and race in directory lseek() qnx6: qnx6_readdir() has a braino in pos calculation fix buffer leak after "scsi: saner replacements for ->proc_info()" vfs: Fix invalid ida_remove() call
-
git://git.linux-nfs.org/projects/trondmy/linux-nfsLinus Torvalds authored
Pull two NFS client fixes from Trond Myklebust: - Fix a regression that broke NFS mounting using klibc and busybox - Stable fix to check access modes correctly on NFSv4 delegated open() * tag 'nfs-for-3.10-4' of git://git.linux-nfs.org/projects/trondmy/linux-nfs: NFS: Fix security flavor negotiation with legacy binary mounts NFSv4: Fix a thinko in nfs4_try_open_cached
-
- 31 May, 2013 23 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fsLinus Torvalds authored
Pull reiserfs fixes from Jan Kara: "Three reiserfs fixes. They fix real problems spotted by users so I hope they are ok even at this stage." * 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs: reiserfs: fix deadlock with nfs racing on create/lookup reiserfs: fix problems with chowning setuid file w/ xattrs reiserfs: fix spurious multiple-fill in reiserfs_readdir_dentry
-
git://oss.sgi.com/xfs/xfsLinus Torvalds authored
Pull xfs extended attribute fixes for CRCs from Ben Myers: "Here are several fixes that are relevant on CRC enabled XFS filesystems. They are followed by a rework of the remote attribute code so that each block of the attribute contains a header with a CRC. Previously there was a CRC header per extent in the remote attribute code, but this was untenable because it was not possible to know how many extents would be allocated for the attribute until after the allocation has completed, due to the fragmentation of free space. This became complicated because the size of the headers needs to be added to the length of the payload to get the overall length required for the allocation. With a header per block, things are less complicated at the cost of a little space. I would have preferred to defer this and the rest of the CRC queue to 3.11 to mitigate risk for existing non-crc users in 3.10. Doing so would require setting a feature bit for the on-disk changes, and so I have been pressured into sending this pull request by Eric Sandeen and David Chinner from Red Hat. I'll send another pull request or two with the rest of the CRC queue next week. - Remove assert on count of remote attribute CRC headers - Fix the number of blocks read in for remote attributes - Zero remote attribute tails properly - Fix mapping of remote attribute buffers to have correct length - initialize temp leaf properly in xfs_attr3_leaf_unbalance, and xfs_attr3_leaf_compact - Rework remote atttributes to have a header per block" * tag 'for-linus-v3.10-rc4-crc-xattr-fixes' of git://oss.sgi.com/xfs/xfs: xfs: rework remote attr CRCs xfs: fully initialise temp leaf in xfs_attr3_leaf_compact xfs: fully initialise temp leaf in xfs_attr3_leaf_unbalance xfs: correctly map remote attr buffers during removal xfs: remote attribute tail zeroing does too much xfs: remote attribute read too short xfs: remote attribute allocation may be contiguous
-
git://oss.sgi.com/xfs/xfsLinus Torvalds authored
Pull xfs fixes from Ben Myers: - Fix nested transactions in xfs_qm_scall_setqlim - Clear suid/sgid bits when we truncate with size update - Fix recovery for split buffers - Fix block count on remote symlinks - Add fsgeom flag for v5 superblock support - Disable XFS_IOC_SWAPEXT for CRC enabled filesystems - Fix dirv3 freespace block corruption * tag 'for-linus-v3.10-rc4' of git://oss.sgi.com/xfs/xfs: xfs: fix dir3 freespace block corruption xfs: disable swap extents ioctl on CRC enabled filesystems xfs: add fsgeom flag for v5 superblock support. xfs: fix incorrect remote symlink block count xfs: fix split buffer vector log recovery support xfs: kill suid/sgid through the truncate path. xfs: avoid nesting transactions in xfs_qm_scall_setqlim()
-
git://git.kernel.org/pub/scm/linux/kernel/git/ras/rasLinus Torvalds authored
Pull aer error logging fix from Tony Luck: "Can't call pci_get_domain_bus_and_slot() from interupt context" * tag 'please-pull-aertracefix' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras: aerdrv: Move cper_print_aer() call out of interrupt context
-
git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64Linus Torvalds authored
Pull arm64 fixes from Catalin Marinas: - Module compilation issues (symbol not exported). - Plug a hole where user space can bring the kernel down. * tag 'arm64-stable' of git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64: arm64: don't kill the kernel on a bad esr from el0 arm64: treat unhandled compat el0 traps as undef arm64: Do not report user faults for handled signals arm64: kernel: compiling issue, need 'EXPORT_SYMBOL(clear_page)'
-
Jeff Mahoney authored
Reiserfs is currently able to be deadlocked by having two NFS clients where one has removed and recreated a file and another is accessing the file with an open file handle. If one client deletes and recreates a file with timing such that the recreated file obtains the same [dirid, objectid] pair as the original file while another client accesses the file via file handle, the create and lookup can race and deadlock if the lookup manages to create the in-memory inode first. The create thread, in insert_inode_locked4, will hold the write lock while waiting on the other inode to be unlocked. The lookup thread, anywhere in the iget path, will release and reacquire the write lock while it schedules. If it needs to reacquire the lock while the create thread has it, it will never be able to make forward progress because it needs to reacquire the lock before ultimately unlocking the inode. This patch drops the write lock across the insert_inode_locked4 call so that the ordering of inode_wait -> write lock is retained. Since this would have been the case before the BKL push-down, this is safe. Signed-off-by:
Jeff Mahoney <jeffm@suse.com> Signed-off-by:
Jan Kara <jack@suse.cz>
-
Jeff Mahoney authored
reiserfs_chown_xattrs() takes the iattr struct passed into ->setattr and uses it to iterate over all the attrs associated with a file to change ownership of xattrs (and transfer quota associated with the xattr files). When the setuid bit is cleared during chown, ATTR_MODE and iattr->ia_mode are passed to all the xattrs as well. This means that the xattr directory will have S_IFREG added to its mode bits. This has been prevented in practice by a missing IS_PRIVATE check in reiserfs_acl_chmod, which caused a double-lock to occur while holding the write lock. Since the file system was completely locked up, the writeout of the corrupted mode never happened. This patch temporarily clears everything but ATTR_UID|ATTR_GID for the calls to reiserfs_setattr and adds the missing IS_PRIVATE check. Signed-off-by:
Jeff Mahoney <jeffm@suse.com> Signed-off-by:
Jan Kara <jack@suse.cz>
-
Jeff Mahoney authored
After sleeping for filldir(), we check to see if the file system has changed and research. The next_pos pointer is updated but its value isn't pushed into the key used for the search itself. As a result, the search returns the same item that the last cycle of the loop did and filldir() is called multiple times with the same data. The end result is that the buffer can contain the same name multiple times. This can be returned to userspace or used internally in the xattr code where it can manifest with the following warning: jdm-20004 reiserfs_delete_xattrs: Couldn't delete all xattrs (-2) reiserfs_for_each_xattr uses reiserfs_readdir_dentry to iterate over the xattr names and ends up trying to unlink the same name twice. The second attempt fails with -ENOENT and the error is returned. At some point I'll need to add support into reiserfsck to remove the orphaned directories left behind when this occurs. The fix is to push the value into the key before researching. Signed-off-by:
Jeff Mahoney <jeffm@suse.com> Signed-off-by:
Jan Kara <jack@suse.cz>
-
Al Viro authored
worse, we lock ->resource_lock too late when we are destroying the final clonal VMA; the check for lack of other mappings of the same opened file can race with mmap(). Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
Richard Genoud authored
When removing atmel_lcdfb module, the backlight is unregistered but not blanked. (only for CONFIG_BACKLIGHT_ATMEL_LCDC case). This can result in the screen going full white depending on how the PWM is wired. Signed-off-by:
Richard Genoud <richard.genoud@gmail.com> Signed-off-by:
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
-
Richard Genoud authored
When a too small framebuffer is given, the atmel_lcdfb_check_var silently fails. Adding an error message will save some head scratching. Signed-off-by:
Richard Genoud <richard.genoud@gmail.com> Signed-off-by:
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
-
Al Viro authored
Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
For one thing, there's an ABBA deadlock on hpfs fs-wide lock and i_mutex in hpfs_dir_lseek() - there's a lot of methods that grab the former with the caller already holding the latter, so it must take i_mutex first. For another, locking the damn thing, carefully validating the offset, then dropping locks and assigning the offset is obviously racy. Moreover, we _must_ do hpfs_add_pos(), or the machinery in dnode.c won't modify the sucker on B-tree surgeries. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
We want to mask lower 5 bits out, not leave only those and clear the rest... As it is, we end up always starting to read from the beginning of directory, no matter what the current position had been. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
Jan Beulich authored
That patch failed to set proc_scsi_fops' .release method. Signed-off-by:
Jan Beulich <jbeulich@suse.com> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
Takashi Iwai authored
When the group id of a shared mount is not allocated, the umount still tries to call mnt_release_group_id(), which eventually hits a kernel warning at ida_remove() spewing a message like: ida_remove called for id=0 which is not allocated. This patch fixes the bug simply checking the group id in the caller. Reported-by:
Cristian Rodríguez <crrodriguez@opensuse.org> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
Mark Rutland authored
Rather than completely killing the kernel if we receive an esr value we can't deal with in the el0 handlers, send the process a SIGILL and log the esr value in the hope that we can debug it. If we receive a bad esr from el1, we'll die() as before. Signed-off-by:
Mark Rutland <mark.rutland@arm.com> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Cc: stable@vger.kernel.org
-
Mark Rutland authored
Currently, if a compat process reads or writes from/to a disabled cp15/cp14 register, the trap is not handled by the el0_sync_compat handler, and the kernel will head to bad_mode, where it will die(), and oops(). For 64 bit processes, disabled system register accesses are currently treated as unhandled instructions. This patch modifies entry.S to treat these unhandled traps as undefined instructions, sending a SIGILL to userspace. This gives processes a chance to handle this and stop using inaccessible registers, and prevents further issues in the kernel as a result of the die(). Reported-by:
Johannes Jensen <Johannes.Jensen@arm.com> Signed-off-by:
Mark Rutland <mark.rutland@arm.com> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com>
-
git://people.freedesktop.org/~airlied/linuxLinus Torvalds authored
Pull drm fixes from Dave Airlie: "One qxl 32-bit warning fix, the rest is a bunch of radeon fixes from Alex for some issues we've been seeing." * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: drm/qxl: fix build warnings on 32-bit radeon: use max_bus_speed to activate gen2 speeds drm/radeon: narrow scope of Apple re-POST hack drm/radeon: don't check crtcs in card_posted() on cards without DCE drm/radeon: fix card_posted check for newer asics drm/radeon: fix typo in cu_per_sh on verde drm/radeon: UVD block on SUMO2 is the same as on SUMO
-
Dave Airlie authored
Just the usual printk related warnings. Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
Fabio Estevam authored
Fix the following sparse warnings: drivers/clk/mxs/clk-imx28.c:72:5: warning: symbol 'mxs_saif_clkmux_select' was not declared. Should it be static? drivers/clk/mxs/clk-imx28.c:156:12: warning: symbol 'mx28_clocks_init' was not declared. Should it be static? Signed-off-by:
Fabio Estevam <fabio.estevam@freescale.com> Acked-by:
Shawn Guo <shawn.guo@linaro.org> Signed-off-by:
Mike Turquette <mturquette@linaro.org> [mturquette@linaro.org: fixed $SUBJECT line]
-
git://linux-nfs.org/~bfields/linuxLinus Torvalds authored
Pull nfsd fixes from Bruce Fields: "A couple minor fixes for the (new to 3.10) gss-proxy code. And one regression from user-namespace changes. (XBMC clients were doing something admittedly weird--sending -1 gid's--but something that we used to allow.)" * 'for-3.10' of git://linux-nfs.org/~bfields/linux: svcrpc: fix failures to handle -1 uid's and gid's svcrpc: implement O_NONBLOCK behavior for use-gss-proxy svcauth_gss: fix error code in use_gss_proxy()
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 fixes from Peter Anvin: - Three EFI-related fixes - Two early memory initialization fixes - build fix for older binutils - fix for an eager FPU performance regression -- currently we don't allow the use of the FPU at interrupt time *at all* in eager mode, which is clearly wrong. * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86: Allow FPU to be used at interrupt time even with eagerfpu x86, crc32-pclmul: Fix build with older binutils x86-64, init: Fix a possible wraparound bug in switchover in head_64.S x86, range: fix missing merge during add range x86, efi: initial the local variable of DataSize to zero efivar: fix oops in efivar_update_sysfs_entries() caused by memory reuse efivarfs: Never return ENOENT from firmware again
-
- 30 May, 2013 7 commits
-
-
Pekka Riikonen authored
With the addition of eagerfpu the irq_fpu_usable() now returns false negatives especially in the case of ksoftirqd and interrupted idle task, two common cases for FPU use for example in networking/crypto. With eagerfpu=off FPU use is possible in those contexts. This is because of the eagerfpu check in interrupted_kernel_fpu_idle(): ... * For now, with eagerfpu we will return interrupted kernel FPU * state as not-idle. TBD: Ideally we can change the return value * to something like __thread_has_fpu(current). But we need to * be careful of doing __thread_clear_has_fpu() before saving * the FPU etc for supporting nested uses etc. For now, take * the simple route! ... if (use_eager_fpu()) return 0; As eagerfpu is automatically "on" on those CPUs that also have the features like AES-NI this patch changes the eagerfpu check to return 1 in case the kernel_fpu_begin() has not been said yet. Once it has been the __thread_has_fpu() will start returning 0. Notice that with eagerfpu the __thread_has_fpu is always true initially. FPU use is thus always possible no matter what task is under us, unless the state has already been saved with kernel_fpu_begin(). [ hpa: this is a performance regression, not a correctness regression, but since it can be quite serious on CPUs which need encryption at interrupt time I am marking this for urgent/stable. ] Signed-off-by:
Pekka Riikonen <priikone@iki.fi> Link: http://lkml.kernel.org/r/alpine.GSO.2.00.1305131356320.18@git.silcnet.org Cc: <stable@vger.kernel.org> v3.7+ Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com>
-
Jan Beulich authored
binutils prior to 2.18 (e.g. the ones found on SLE10) don't support assembling PEXTRD, so a macro based approach like the one for PCLMULQDQ in the same file should be used. This requires making the helper macros capable of recognizing 32-bit general purpose register operands. [ hpa: tagging for stable as it is a low risk build fix ] Signed-off-by:
Jan Beulich <jbeulich@suse.com> Link: http://lkml.kernel.org/r/51A6142A02000078000D99D8@nat28.tlf.novell.com Cc: Alexander Boyko <alexander_boyko@xyratex.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Huang Ying <ying.huang@intel.com> Cc: <stable@vger.kernel.org> v3.9 Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com>
-
Dave Chinner authored
Note: this changes the on-disk remote attribute format. I assert that this is OK to do as CRCs are marked experimental and the first kernel it is included in has not yet reached release yet. Further, the userspace utilities are still evolving and so anyone using this stuff right now is a developer or tester using volatile filesystems for testing this feature. Hence changing the format right now to save longer term pain is the right thing to do. The fundamental change is to move from a header per extent in the attribute to a header per filesytem block in the attribute. This means there are more header blocks and the parsing of the attribute data is slightly more complex, but it has the advantage that we always know the size of the attribute on disk based on the length of the data it contains. This is where the header-per-extent method has problems. We don't know the size of the attribute on disk without first knowing how many extents are used to hold it. And we can't tell from a mapping lookup, either, because remote attributes can be allocated contiguously with other attribute blocks and so there is no obvious way of determining the actual size of the atribute on disk short of walking and mapping buffers. The problem with this approach is that if we map a buffer incorrectly (e.g. we make the last buffer for the attribute data too long), we then get buffer cache lookup failure when we map it correctly. i.e. we get a size mismatch on lookup. This is not necessarily fatal, but it's a cache coherency problem that can lead to returning the wrong data to userspace or writing the wrong data to disk. And debug kernels will assert fail if this occurs. I found lots of niggly little problems trying to fix this issue on a 4k block size filesystem, finally getting it to pass with lots of fixes. The thing is, 1024 byte filesystems still failed, and it was getting really complex handling all the corner cases that were showing up. And there were clearly more that I hadn't found yet. It is complex, fragile code, and if we don't fix it now, it will be complex, fragile code forever more. Hence the simple fix is to add a header to each filesystem block. This gives us the same relationship between the attribute data length and the number of blocks on disk as we have without CRCs - it's a linear mapping and doesn't require us to guess anything. It is simple to implement, too - the remote block count calculated at lookup time can be used by the remote attribute set/get/remove code without modification for both CRC and non-CRC filesystems. The world becomes sane again. Because the copy-in and copy-out now need to iterate over each filesystem block, I moved them into helper functions so we separate the block mapping and buffer manupulations from the attribute data and CRC header manipulations. The code becomes much clearer as a result, and it is a lot easier to understand and debug. It also appears to be much more robust - once it worked on 4k block size filesystems, it has worked without failure on 1k block size filesystems, too. Signed-off-by:
Dave Chinner <dchinner@redhat.com> Reviewed-by:
Ben Myers <bpm@sgi.com> Signed-off-by:
Ben Myers <bpm@sgi.com> (cherry picked from commit ad1858d7)
-
Dave Chinner authored
xfs_attr3_leaf_compact() uses a temporary buffer for compacting the the entries in a leaf. It copies the the original buffer into the temporary buffer, then zeros the original buffer completely. It then copies the entries back into the original buffer. However, the original buffer has not been correctly initialised, and so the movement of the entries goes horribly wrong. Make sure the zeroed destination buffer is fully initialised, and once we've set up the destination incore header appropriately, write is back to the buffer before starting to move entries around. While debugging this, the _d/_s prefixes weren't sufficient to remind me what buffer was what, so rename then all _src/_dst. Signed-off-by:
Dave Chinner <dchinner@redhat.com> Reviewed-by:
Ben Myers <bpm@sgi.com> Signed-off-by:
Ben Myers <bpm@sgi.com> (cherry picked from commit d4c712bc)
-
Dave Chinner authored
xfs_attr3_leaf_unbalance() uses a temporary buffer for recombining the entries in two leaves when the destination leaf requires compaction. The temporary buffer ends up being copied back over the original destination buffer, so the header in the temporary buffer needs to contain all the information that is in the destination buffer. To make sure the temporary buffer is fully initialised, once we've set up the temporary incore header appropriately, write is back to the temporary buffer before starting to move entries around. Signed-off-by:
Dave Chinner <dchinner@redhat.com> Reviewed-by:
Ben Myers <bpm@sgi.com> Signed-off-by:
Ben Myers <bpm@sgi.com> (cherry picked from commit 8517de2a)
-
Dave Chinner authored
If we don't map the buffers correctly (same as for get/set operations) then the incore buffer lookup will fail. If a block number matches but a length is wrong, then debug kernels will ASSERT fail in _xfs_buf_find() due to the length mismatch. Ensure that we map the buffers correctly by basing the length of the buffer on the attribute data length rather than the remote block count. Signed-off-by:
Dave Chinner <dchinner@redhat.com> Reviewed-by:
Ben Myers <bpm@sgi.com> Signed-off-by:
Ben Myers <bpm@sgi.com> (cherry picked from commit 6863ef84)
-
Dave Chinner authored
When an attribute data does not fill then entire remote block, we zero the remaining part of the buffer. This, however, needs to take into account that the buffer has a header, and so the offset where zeroing starts and the length of zeroing need to take this into account. Otherwise we end up with zeros over the end of the attribute value when CRCs are enabled. While there, make sure we only ask to map an extent that covers the remaining range of the attribute, rather than asking every time for the full length of remote data. If the remote attribute blocks are contiguous with other parts of the attribute tree, it will map those blocks as well and we can potentially zero them incorrectly. We can also get buffer size mistmatches when trying to read or remove the remote attribute, and this can lead to not finding the correct buffer when looking it up in cache. Signed-off-by:
Dave Chinner <dchinner@redhat.com> Reviewed-by:
Ben Myers <bpm@sgi.com> Signed-off-by:
Ben Myers <bpm@sgi.com> (cherry picked from commit 4af3644c)
-