History log of /linux/fs/xfs/xfs_aops.h (Results 226 – 250 of 401)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 14ddde78 08-Mar-2016 Ingo Molnar <mingo@kernel.org>

Merge branch 'linus' into x86/fpu, to pick up fixes

Signed-off-by: Ingo Molnar <mingo@kernel.org>


# fe36d891 08-Mar-2016 Ingo Molnar <mingo@kernel.org>

Merge branch 'linus' into irq/core, to pick up fixes

Signed-off-by: Ingo Molnar <mingo@kernel.org>


# a1a8ba2d 08-Mar-2016 Ingo Molnar <mingo@kernel.org>

Merge branch 'linus' into ras/core, to pick up fixes

Signed-off-by: Ingo Molnar <mingo@kernel.org>


# 56d94d70 08-Mar-2016 Takashi Iwai <tiwai@suse.de>

Merge branch 'topic/hda' into for-next


# ad09ef2c 07-Mar-2016 Takashi Iwai <tiwai@suse.de>

Merge tag 'asoc-fix-v4.5-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus

ASoC: Fixes for v4.5

This is far too big a set of fixes for this late in the release cycl

Merge tag 'asoc-fix-v4.5-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus

ASoC: Fixes for v4.5

This is far too big a set of fixes for this late in the release cycle
but the overwhelming bulk is essentially the same simple fix from
Takashi for a cut'n'pasted 64 bit cleanliness issue in the userspace
interface where drivers were accessing things using the wrong element in
a union which worked OK on 32 bit platforms as the correct element
happened to be aligned the same way but with 64 bit platforms ABIs are
different and the two members of the union are laid out in different
places. They aren't all tagged to stable since some of these chips have
vanishingly little chance of being used in 64 bit systems.

The other changes are:
- A fix for Qualcomm devices to work on big endian systems. The
original change is actually correct but triggered a bug in regmap
which is too invasive to fix for this cycle and can be worked around
by just letting regmap pick the default.
- A fix for the Samsung I2S driver locking which wasn't using IRQ safe
spinlocks when it needed to.
- A fix for the new Intel Sky Lake driver forgetting that C pointer
arithmetic takes the type of the pointer into consideration.
- A revert of a change to the FSL SSI driver that broke some systems.
- A fix for the cleanup path of the wm9713 driver.
- A fix for some incorrect register definitions in the ADAU17x1 driver
that caused misclocking in some configurations.
- A fix for the tracepoints for jack detection to avoid using an
internal field of the core jack structure which is no longer present
in all configurations.
- A fix for another of the new Intel drivers which tried to write to a
string literal.

show more ...


# ec87e1cf 07-Mar-2016 Ingo Molnar <mingo@kernel.org>

Merge tag 'v4.5-rc7' into x86/asm, to pick up SMAP fix

Signed-off-by: Ingo Molnar <mingo@kernel.org>


Revision tags: v4.5-rc7
# 3d93ec03 06-Mar-2016 Dave Chinner <david@fromorbit.com>

Merge branch 'xfs-writepage-rework-4.6' into for-next


# bc94b996 04-Mar-2016 Ingo Molnar <mingo@kernel.org>

Merge tag 'v4.5-rc6' into core/resources, to resolve conflict

Signed-off-by: Ingo Molnar <mingo@kernel.org>


# 523462df 02-Mar-2016 Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Merge 4.5-rc6 into char-misc-next

We want the fixes in here, and others are sending us pull requests based
on this kernel tree.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>


# 71e41bbb 02-Mar-2016 Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Merge 4.5-rc6 into usb-next

We want the USB fixes in here as well.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>


# 3e66848a 02-Mar-2016 Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Merge 4.5-rc6 into staging-next

We want the staging fixes in here as well.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>


# 39a1142d 29-Feb-2016 Ingo Molnar <mingo@kernel.org>

Merge tag 'v4.5-rc6' into locking/core, to pick up fixes

Signed-off-by: Ingo Molnar <mingo@kernel.org>


# 6aa447bc 29-Feb-2016 Ingo Molnar <mingo@kernel.org>

Merge branch 'sched/urgent' into sched/core, to pick up fixes before applying new changes

Signed-off-by: Ingo Molnar <mingo@kernel.org>


# 0a734892 29-Feb-2016 Ingo Molnar <mingo@kernel.org>

Merge tag 'v4.5-rc6' into perf/core, to pick up fixes

Signed-off-by: Ingo Molnar <mingo@kernel.org>


Revision tags: v4.5-rc6
# 691429e1 27-Feb-2016 Linus Torvalds <torvalds@linux-foundation.org>

Merge branch 'akpm' (patches from Andrew)

Merge fixes from Andrew Morton:
"10 fixes"

* emailed patches from Andrew Morton <akpm@linux-foundation.org>:
dax: move writeback calls into the filesyst

Merge branch 'akpm' (patches from Andrew)

Merge fixes from Andrew Morton:
"10 fixes"

* emailed patches from Andrew Morton <akpm@linux-foundation.org>:
dax: move writeback calls into the filesystems
dax: give DAX clearing code correct bdev
ext4: online defrag not supported with DAX
ext2, ext4: only set S_DAX for regular inodes
block: disable block device DAX by default
ocfs2: unlock inode if deleting inode from orphan fails
mm: ASLR: use get_random_long()
drivers: char: random: add get_random_long()
mm: numa: quickly fail allocations for NUMA balancing on full nodes
mm: thp: fix SMP race condition between THP page fault and MADV_DONTNEED

show more ...


# 20a90f58 27-Feb-2016 Ross Zwisler <ross.zwisler@linux.intel.com>

dax: give DAX clearing code correct bdev

dax_clear_blocks() needs a valid struct block_device and previously it
was using inode->i_sb->s_bdev in all cases. This is correct for normal
inodes on moun

dax: give DAX clearing code correct bdev

dax_clear_blocks() needs a valid struct block_device and previously it
was using inode->i_sb->s_bdev in all cases. This is correct for normal
inodes on mounted ext2, ext4 and XFS filesystems, but is incorrect for
DAX raw block devices and for XFS real-time devices.

Instead, rename dax_clear_blocks() to dax_clear_sectors(), and change
its arguments to take a bdev and a sector instead of an inode and a
block. This better reflects what the function does, and it allows the
filesystem and raw block device code to pass in an appropriate struct
block_device.

Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Suggested-by: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Cc: Theodore Ts'o <tytso@mit.edu>
Cc: Al Viro <viro@ftp.linux.org.uk>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Jens Axboe <axboe@fb.com>
Cc: Matthew Wilcox <matthew.r.wilcox@intel.com>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

show more ...


# e5451c8f 23-Feb-2016 Laxman Dewangan <ldewangan@nvidia.com>

Merge remote-tracking branch 'linusw-gpio/for-next' into devm_gpiochip

Base for demv_gpiochip_add_data() and devm_gpiochip_remove().


Revision tags: v4.5-rc5
# e10de372 15-Feb-2016 Dave Chinner <dchinner@redhat.com>

xfs: don't chain ioends during writepage submission

Currently we can build a long ioend chain during ->writepages that
gets attached to the writepage context. IO submission only then
occurs when we

xfs: don't chain ioends during writepage submission

Currently we can build a long ioend chain during ->writepages that
gets attached to the writepage context. IO submission only then
occurs when we finish all the writepage processing. This means we
can have many ioends allocated and pending, and this violates the
mempool guarantees that we need to give about forwards progress.
i.e. we really should only have one ioend being built at a time,
otherwise we may drain the mempool trying to allocate a new ioend
and that blocks submission, completion and freeing of ioends that
are already in progress.

To prevent this situation from happening, we need to submit ioends
for IO as soon as they are ready for dispatch rather than queuing
them for later submission. This means the ioends have bios built
immediately and they get queued on any plug that is current active.
Hence if we schedule away from writeback, the ioends that have been
built will make forwards progress due to the plug flushing on
context switch. This will also prevent context switches from
creating unnecessary IO submission latency.

We can't completely avoid having nested IO allocation - when we have
a block size smaller than a page size, we still need to hold the
ioend submission until after we have marked the current page dirty.
Hence we may need multiple ioends to be held while the current page
is completely mapped and made ready for IO dispatch. We cannot avoid
this problem - the current code already has this ioend chaining
within a page so we can mostly ignore that it occurs.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>

show more ...


# fbcc0256 15-Feb-2016 Dave Chinner <dchinner@redhat.com>

xfs: Introduce writeback context for writepages

xfs_vm_writepages() calls generic_writepages to writeback a range of
a file, but then xfs_vm_writepage() clusters pages itself as it does
not have any

xfs: Introduce writeback context for writepages

xfs_vm_writepages() calls generic_writepages to writeback a range of
a file, but then xfs_vm_writepage() clusters pages itself as it does
not have any context it can pass between->writepage calls from
__write_cache_pages().

Introduce a writeback context for xfs_vm_writepages() and call
__write_cache_pages directly with our own writepage callback so that
we can pass that context to each writepage invocation. This
encapsulates the current mapping, whether it is valid or not, the
current ioend and it's IO type and the ioend chain being built.

This requires us to move the ioend submission up to the level where
the writepage context is declared. This does mean we do not submit
IO until we packaged the entire writeback range, but with the block
plugging in the writepages call this is the way IO is submitted,
anyway.

It also means that we need to handle discontiguous page ranges. If
the pages sent down by write_cache_pages to the writepage callback
are discontiguous, we need to detect this and put each discontiguous
page range into individual ioends. This is needed to ensure that the
ioend accurately represents the range of the file that it covers so
that file size updates during IO completion set the size correctly.
Failure to take into account the discontiguous ranges results in
files being too small when writeback patterns are non-sequential.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>

show more ...


Revision tags: v4.5-rc4, v4.5-rc3, v4.5-rc2, v4.5-rc1
# d1208404 21-Jan-2016 Chris Zankel <chris@zankel.net>

Merge tag 'v4.4'

Linux 4.4


Revision tags: v4.4, v4.4-rc8, v4.4-rc7, v4.4-rc6, v4.4-rc5, v4.4-rc4, v4.4-rc3, v4.4-rc2
# a52079da 16-Nov-2015 Mike Marshall <hubcap@omnibond.com>

Orangefs: Merge tag 'v4.4-rc1' into for-next

Linux 4.4-rc1


# 83f1bfd6 14-Jan-2016 Jiri Kosina <jkosina@suse.cz>

Merge branches 'for-4.4/upstream-fixes', 'for-4.5/async-suspend', 'for-4.5/container-of-cleanups', 'for-4.5/core', 'for-4.5/i2c-hid', 'for-4.5/logitech', 'for-4.5/multitouch', 'for-4.5/sony', 'for-4.

Merge branches 'for-4.4/upstream-fixes', 'for-4.5/async-suspend', 'for-4.5/container-of-cleanups', 'for-4.5/core', 'for-4.5/i2c-hid', 'for-4.5/logitech', 'for-4.5/multitouch', 'for-4.5/sony', 'for-4.5/upstream' and 'for-4.5/wacom' into for-linus

show more ...


# 009f7738 12-Jan-2016 Dmitry Torokhov <dmitry.torokhov@gmail.com>

Merge branch 'next' into for-linus

Prepare first round of input updates for 4.5 merge window.


# e219aafe 21-Dec-2015 Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Merge back earlier 'pm-domains' material for v4.5.


# 0fa85119 19-Dec-2015 Thomas Gleixner <tglx@linutronix.de>

Merge branch 'linus' into x86/cleanups

Pull in upstream changes so we can apply depending patches.


12345678910>>...17