= (__le32 *)((char *)header +
> + __le32 *value = (__le32 *)((char *)value_base +
> le16_to_cpu(entry->e_value_offs));
> for (n = (le32_to_cpu(entry->e_value_size) +
>EXT4_XATTR_ROUND) >> EXT4_XATTR_PAD_BITS; n; n--) {
> @@ -2945,13 +2949,11 @@ static inline void ext4_xattr_hash_entry(struct
> ext4_xattr_header *header,
> *
> * Re-compute the extended attribute hash value after an entry has changed.
> */
> -static void ext4_xattr_rehash(struct ext4_xattr_header *header,
> - struct ext4_xattr_entry *entry)
> +static void ext4_xattr_rehash(struct ext4_xattr_header *header)
> {
> struct ext4_xattr_entry *here;
> __u32 hash = 0;
>
> - ext4_xattr_hash_entry(header, entry);
> here = ENTRY(header+1);
> while (!IS_LAST_ENTRY(here)) {
> if (!here->e_hash) {
> --
> 2.13.1.508.gb3defc5cc-goog
>
>
--
Jan Kara
SUSE Labs, CR
On Wed 14-06-17 21:36:45, Pali Rohár wrote:
> On Tuesday 13 June 2017 14:59:55 Jan Kara wrote:
> > Hi,
> >
> > On Mon 12-06-17 22:40:14, Pali Rohár wrote:
> > > Hi! I found that following UDF patch was included into linus tree:
> > > https://patchwork.kerne
On Wed 14-06-17 09:49:29, Dan Williams wrote:
> On Wed, Jun 14, 2017 at 3:54 AM, Jan Kara wrote:
> >> -/**
> >> - * arch_wb_cache_pmem - write back a cache range with CLWB
> >> - * @vaddr: virtual start address
> >> - * @size:number of bytes to wr
ilcox
> Cc: Ross Zwisler
> Suggested-by: Jan Kara
> Signed-off-by: Dan Williams
Looks good. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> Changes since v3:
> * move the check of QUEUE_FLAG_WC into t
eiserfs_write_unlock(inode->i_sb);
> if (error)
> goto out;
> - error = dquot_transfer(inode, attr);
> + error = dquot_transfer(inode, attr, 0);
> reiserfs_write_lock(inode->i_sb);
>
ntry */
> + cache_value_t e_value;
> };
>
> struct mb_cache *mb_cache_create(int bucket_bits);
> void mb_cache_destroy(struct mb_cache *cache);
>
> int mb_cache_entry_create(struct mb_cache *cache, gfp_t mask, u32 key,
> - sector_t block, bool reusable);
> + cache_value_t value, bool reusable);
> void __mb_cache_entry_free(struct mb_cache_entry *entry);
> static inline int mb_cache_entry_put(struct mb_cache *cache,
>struct mb_cache_entry *entry)
> @@ -38,10 +40,10 @@ static inline int mb_cache_entry_put(struct mb_cache
> *cache,
> return 1;
> }
>
> -void mb_cache_entry_delete_block(struct mb_cache *cache, u32 key,
> - sector_t block);
> +void mb_cache_entry_delete(struct mb_cache *cache, u32 key,
> +cache_value_t value);
> struct mb_cache_entry *mb_cache_entry_get(struct mb_cache *cache, u32 key,
> - sector_t block);
> + cache_value_t value);
> struct mb_cache_entry *mb_cache_entry_find_first(struct mb_cache *cache,
>u32 key);
> struct mb_cache_entry *mb_cache_entry_find_next(struct mb_cache *cache,
> --
> 2.13.0.219.gdb65acc882-goog
>
>
--
Jan Kara
SUSE Labs, CR
d:
Reviewed-by: Jan Kara
Honza
> ---
> arch/x86/include/asm/pmem.h | 50
> ---
> fs/dax.c|3 ++-
> include/linux/pmem.h| 24 -
range specified by the NFIT. So, this "no flush"
> property might be something passed down by the bus / libnvdimm.
>
> Cc: Christoph Hellwig
> Cc: Matthew Wilcox
> Cc: Ross Zwisler
> Signed-off-by: Dan Williams
e management work when the underlying driver does not
> specify a flush method.
>
> We still do all the dirty tracking since the radix entry will already be
> there for locking purposes. However, the work to clean the entry will be
> a nop for some dax drivers.
>
> Cc: Jan Kara
y.
>
> With clear_pmem() gone we can follow on with a patch to make pmem cache
> management completely defined within the pmem driver.
>
> Cc:
> Cc: Jan Kara
> Cc: Jeff Moyer
> Cc: Ingo Molnar
> Cc: Christoph Hellwig
> Cc: "H. Peter Anvin"
> Cc: Th
efined
> for x86_64, but it is straightforward to add other archs in the future.
>
> Cc:
> Cc: Jan Kara
> Cc: Jeff Moyer
> Cc: Ingo Molnar
> Cc: Christoph Hellwig
> Cc: "H. Peter Anvin"
> Cc: Thomas Gleixner
> Cc: Oliver O'Halloran
> Cc: Matth
On Fri 09-06-17 13:24:35, Dan Williams wrote:
> Kill this globally defined wrapper and move to libnvdimm so that we can
> ultimately remove include/linux/pmem.h.
>
> Cc:
> Cc: Jan Kara
> Cc: Jeff Moyer
> Cc: Ingo Molnar
> Cc: Christoph Hellwig
> Cc: "H. Pet
On Fri 09-06-17 13:24:40, Dan Williams wrote:
> Now that all callers of the pmem api have been converted to dax helpers that
> call back to the pmem driver, we can remove include/linux/pmem.h.
>
> Cc:
> Cc: Jan Kara
> Cc: Jeff Moyer
> Cc: Ingo Molnar
> Cc: Christoph H
ing purposes this patch only disables the cache flush
> loop, not the dirty tracking.
>
> Userspace can override the default cache setting via the block device
> queue "write_cache" attribute in sysfs.
>
> Cc: Jan Kara
> Cc: Jeff Moyer
> Cc: Christoph Hel
understood the spec correctly. What I think we should do is to
make udf-tools and blkid accept both variants but create the one defined in
the spec (to have higher chances for interoperability).
Honza
--
Jan Kara
SUSE Labs, CR
ore, so it can be deleted. I think its name was incorrect as default
> block size for UDF should be logical block size of disk, not hardcoded
> value 2048 which is logical block size for optical media.
Thanks. Removed.
Honza
--
Jan Kara
SUSE Labs, CR
On Mon 12-06-17 10:37:27, Johannes Weiner wrote:
> On Mon, Jun 12, 2017 at 10:09:57AM +0200, Jan Kara wrote:
> > On Tue 16-05-17 18:03:37, Jan Kara wrote:
> > > On Tue 16-05-17 11:41:05, Johannes Weiner wrote:
> > > > On Tue, May 16, 2017 at 04:36:45PM +0200, Jan Kara
_emergency_remount+0xb0
> [] process_one_work+0x228
> [] worker_thread+0x2e0
> [] kthread+0xf4
> [] ret_from_fork+0x10
>
> Link: http://marc.info/?t=14951151482&r=1&w=2
> Fix-suggested-by: Jan kara
> Signed-off-by: Sahitya Tummala
Looks good to me. You can add:
Reviewed
| 1 +
> mm/internal.h| 20
> mm/madvise.c | 4 +
> mm/memory.c | 291
> +++++++----
> mm/mempolicy.c | 10 +-
> mm/mlock.c | 9 +-
> mm/mmap.c| 123 +++-
> mm/mprotect.c| 2 +
> mm/mremap.c | 7 ++
> 15 files changed, 435 insertions(+), 81 deletions(-)
>
> --
> 2.7.4
>
--
Jan Kara
SUSE Labs, CR
arly for other functions like __rb_insert()... It would seem like less
> >churn and I don't see downside to it...
>
> I propagate args so we don't have to duplicate the checks between the regular
> and augmented rbtrees.
OK, yeah. Feel free to add:
Reviewed-by: Jan Kara
Honza
--
Jan Kara
SUSE Labs, CR
On Tue 16-05-17 18:03:37, Jan Kara wrote:
> On Tue 16-05-17 11:41:05, Johannes Weiner wrote:
> > On Tue, May 16, 2017 at 04:36:45PM +0200, Jan Kara wrote:
> > > On Mon 15-05-17 11:46:34, Johannes Weiner wrote:
> > > > We have observed across several workloa
than 1 child (easy!)
Why do you propagate e.g. 'leftmost' down to __rb_erase_augmented() when
you could just handle everything within rb_erase_augmented_cached?
Similarly for other functions like __rb_insert()... It would seem like less
churn and I don't see downside to it...
Honza
--
Jan Kara
SUSE Labs, CR
gt; - if (!pmd_none(*vmf->pmd))
> + if (!pmd_none(*vmf->pmd) && !pmd_trans_huge(*vmf->pmd) &&
> + !pmd_devmap(*vmf->pmd)) {
> + result = 0;
> goto unlock_entry;
> + }
>
> /*
>* Note that we don't use iomap_apply here. We aren't doing I/O, only
> --
> 2.9.4
>
--
Jan Kara
SUSE Labs, CR
> console_sem before it goes into sleep.
>
>
> The advantages:
>
>+ all messages are handled synchronously if there is not
> a flood of messages
>
>+ if there is the flood of messages; kthread works only
> as a fallback; processes that produce the messages
> are involved into handling the console (nature throttling);
> the messages appear on the console even when printk_kthread
> is sleeping; but the softlockup is prevented
>
> => it should work pretty well in all situations, including the flood
>of messages and sudden dead.
Honza
--
Jan Kara
SUSE Labs, CR
e ext4_inode_info->i_dquot is not initialized yet.
>
> Add dquot_initialize() to call paths that lead to ext4_xattr_block_set().
>
> Signed-off-by: Tahsin Erdogan
Looks good to me. You can add:
Reviewed-by: Jan Kara
some common fallback paths that
you'd think are worth detecting and it's not easy to add information to the
final tracepoint, then we can add a specific tracepoint to that branch.
Honza
--
Jan Kara
SUSE Labs, CR
testing these races result in the following types of errors:
>
> BUG: Bad rss-counter state mm:8800a817d280 idx:1 val:1
> BUG: non-zero nr_ptes on freeing mm: 15
>
> Fix this issue by having the DAX fault handler
On Mon 22-05-17 15:09:33, Jeff Layton wrote:
> On Mon, 2017-05-22 at 19:53 +0200, Jan Kara wrote:
> > On Mon 22-05-17 09:53:21, Jeff Layton wrote:
> > > On Mon, 2017-05-22 at 15:38 +0200, Jan Kara wrote:
> > > > > In the case of something like ext2, could we inst
t; index bb2554f..415980d 100644
> --- a/include/uapi/linux/aio_abi.h
> +++ b/include/uapi/linux/aio_abi.h
> @@ -54,6 +54,12 @@ enum {
> */
> #define IOCB_FLAG_RESFD (1 << 0)
>
> +/*
> + * IOCB_FLAG_IOPRIO - Set if the "aio_reqprio" member of the "struct iocb"
> + *is interpreted as an I/O scheduling class and priority
> + */
> +#define IOCB_FLAG_IOPRIO (1 << 1)
> +
> /* read() from /dev/aio returns these structures. */
> struct io_event {
> __u64 data; /* the data field from the iocb */
> --
> 2.7.4
>
--
Jan Kara
SUSE Labs, CR
ck_xattr(inode, &no_expand);
>
> error = ext4_reserve_inode_write(handle, inode, &is.iloc);
> --
> 2.13.0.219.gdb65acc882-goog
>
--
Jan Kara
SUSE Labs, CR
On Mon 22-05-17 09:53:21, Jeff Layton wrote:
> On Mon, 2017-05-22 at 15:38 +0200, Jan Kara wrote:
> > On Fri 19-05-17 15:20:52, Jeff Layton wrote:
> > > On Mon, 2017-05-15 at 12:42 +0200, Jan Kara wrote:
> > > > On Tue 09-05-17 11:49:18, Jeff Layton wrote:
> >
t; + * our page tables.
> + */
> + split_huge_pmd(vmf->vma, vmf->pmd, vmf->address);
> +
Can we just check the PMD and if is isn't as we want it, bail out and retry
the fault? IMHO it will be more obvious that way (and also more in line
like these races are handled for the classical THP). Otherwise the patch
looks good to me.
Honza
--
Jan Kara
SUSE Labs, CR
ation until we have
> page to map")
> Cc: sta...@vger.kernel.org
With the change requested by Dave this looks good to me. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> mm/memory.c | 4 ++--
> 1 file c
On Thu 18-05-17 15:29:39, Ross Zwisler wrote:
> On Thu, May 18, 2017 at 09:50:37AM +0200, Jan Kara wrote:
> > On Wed 17-05-17 11:16:39, Ross Zwisler wrote:
> > > We currently have two related PMD vs PTE races in the DAX code. These can
> > > both be easily triggered by
On Fri 19-05-17 15:20:52, Jeff Layton wrote:
> On Mon, 2017-05-15 at 12:42 +0200, Jan Kara wrote:
> > On Tue 09-05-17 11:49:18, Jeff Layton wrote:
> > > Now that we have a better way to store and report errors that occur
> > > during writeback, we need to convert the
start a new nofs context.
>*/
Yeah, this is much better. Tahsin, please use Michal's version. Thanks!
Honza
--
Jan Kara
SUSE Labs, CR
> /*
> + * It is possible, particularly with mixed reads & writes to private
> + * mappings, that we have raced with a PTE fault that overlaps with
> + * the PMD we need to set up. If so we just fall back to a PTE fault
> + * ourselves.
> + */
> + if (!pmd_none(*vmf->pmd))
> + goto unlock_entry;
> +
> + /*
>* Note that we don't use iomap_apply here. We aren't doing I/O, only
>* setting up a mapping, so really we're using iomap_begin() as a way
>* to look up our filesystem block.
> --
> 2.9.4
>
--
Jan Kara
SUSE Labs, CR
> we start a new transaction? I thought we were doing that already but the
> code is so convoluted I have hard time to wrap my head around it.
I was thinking about his as well but the fact is jbd2__journal_restart()
actually does equivalent of jbd2_journal_stop() for the handle above the
place where memalloc_nofs_restore() was added so in this sense we really
miss memalloc_nofs_restore() there... So what Tahsin did makes sense.
Honza
--
Jan Kara
SUSE Labs, CR
rt()
> jbd2_journal_stop()
>
> Make jbd2__journal_restart() restore the original value before calling
> start_this_handle().
>
> Fixes: 81378da64de6 ("jbd2: mark the transaction context with the scope
> GFP_NOFS context")
> Signed-off-by: Tahsin Erdogan
Thanks for
On Tue 16-05-17 11:41:05, Johannes Weiner wrote:
> On Tue, May 16, 2017 at 04:36:45PM +0200, Jan Kara wrote:
> > On Mon 15-05-17 11:46:34, Johannes Weiner wrote:
> > > We have observed across several workloads situations where kswapd and
> > > direct reclaimers get stu
es and i_datasync_tid just happens to be set to the current
transaction because it is initialized that way and we are evicting inode
that was recently read from disk.
Anyway if you add: "&& inode->i_data.nrpages" to the test in
ext4_evict_inode() do the stalls go away?
Honza
--
Jan Kara
SUSE Labs, CR
ooks good. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> fs/jbd2/transaction.c | 38 +++---
> 1 file changed, 19 insertions(+), 19 deletions(-)
>
> diff --git a/fs/jbd2/transaction.
On Fri 12-05-17 11:00:07, Mauro Carvalho Chehab wrote:
> kernel-doc will try to interpret a foo() string, except if
> properly escaped.
>
> Signed-off-by: Mauro Carvalho Chehab
Looks good. You can add:
Reviewed-
riteback error since then.
>
> Signed-off-by: Jeff Layton
Looks good to me. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> mm/page-writeback.c | 11 +--
> 1 file changed, 5 insertions(+), 6 deletions(-)
&g
On Tue 09-05-17 11:49:25, Jeff Layton wrote:
> Now that we don't clear writeback errors after fetching them, there is
> no need to reset them. This is also potentially racy.
>
> Signed-off-by: Jeff Layton
Looks good. You can add:
Revi
heck this flag in order to set the error in the
> mapping.
>
> This sets the error in the mapping earlier, at the time that it's first
> detected.
>
> Signed-off-by: Jeff Layton
Looks good to me. You can add:
Reviewed-by: Jan Kara
Small nits below.
> @@ -354,7 +354
etadata mapping (and this is not a problem
specific to f2fs. For example ext2 also uses this scheme where block
devices' mapping is the metadata mapping). And we need to merge error
information from these two mappings so for the stamping scheme to work,
we'd need two stamps stored in struct file. One for data mapping and one
for metadata mapping. Or maybe there's some more clever scheme but for now
I don't see one...
Honza
--
Jan Kara
SUSE Labs, CR
On Thu 11-05-17 14:59:43, J. Bruce Fields wrote:
> On Wed, Apr 05, 2017 at 02:14:09PM -0400, J. Bruce Fields wrote:
> > On Wed, Apr 05, 2017 at 10:05:51AM +0200, Jan Kara wrote:
> > > 1) Keep i_version as is, make clients also check for i_ctime.
> >
> > That would
On Wed 10-05-17 08:19:50, Jeff Layton wrote:
> On Wed, 2017-05-10 at 13:48 +0200, Jan Kara wrote:
> > On Tue 09-05-17 11:49:17, Jeff Layton wrote:
> > > diff --git a/fs/file_table.c b/fs/file_table.c
> > > index 954d510b765a..d6138b6411ff 100644
> > >
false report of success.
>
> The new behavior is still consistent with the POSIX spec, and is more
> reliable for application developers. This patch just adds some basic
> infrastructure for doing this. Later patches will change the existing
> code to use this new infrastructu
*/
> + new = old | ERRSEQ_SEEN;
> + if (new != old)
> + cmpxchg(eseq, old, new);
> + *since = new;
> + err = -(new & MAX_ERRNO);
> + }
> + return err;
> +}
> +EXPORT_SYMBOL(errseq_check_and_advance);
Honza
--
Jan Kara
SUSE Labs, CR
On Tue 09-05-17 11:49:15, Jeff Layton wrote:
> Signed-off-by: Jeff Layton
> Reviewed-by: Christoph Hellwig
Looks good to me. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> fs/cifs/file.c | 12 +++-
>
On Tue 09-05-17 11:49:14, Jeff Layton wrote:
> This ensures that we see errors on fsync when writeback fails.
>
> Signed-off-by: Jeff Layton
> Reviewed-by: Christoph Hellwig
Looks good to me. You can add:
Reviewed-
On Tue 09-05-17 11:49:08, Jeff Layton wrote:
> Nothing checks its return value.
>
> Signed-off-by: Jeff Layton
Looks good to me. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> fs/btrfs/disk-io.c | 6 +++---
&
On Tue 09-05-17 11:49:04, Jeff Layton wrote:
> Signed-off-by: Jeff Layton
Looks good. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> include/linux/fs.h | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --g
.
>
> Signed-off-by: Ross Zwisler
> Fixes: c6dcf52c23d2 ("mm: Invalidate DAX radix tree entries only if
> appropriate")
> Reported-by: Jan Kara
> Reviewed-by: Jan Kara
> Cc: [4.10+]
Ah, I've just sent out a series which contains these two patches and
anoth
ore DAX special casing up into the
> mm/truncate.c code.
>
> Or am I missing something?
No, my thinking was to put the invalidation at the end of
invalidate_inode_pages2_range(). I agree it means more special-casing for
DAX in mm/truncate.c.
Honza
--
Jan Kara
SUSE Labs, CR
On Wed 03-05-17 19:19:11, Corentin Labbe wrote:
> On Wed, May 03, 2017 at 01:44:54PM +0200, Jan Kara wrote:
> > On Tue 02-05-17 19:22:22, Corentin Labbe wrote:
> > > On Tue, May 02, 2017 at 06:27:04PM +0200, Jan Kara wrote:
> > > > Hello,
> > > >
> &
On Tue 02-05-17 19:22:22, Corentin Labbe wrote:
> On Tue, May 02, 2017 at 06:27:04PM +0200, Jan Kara wrote:
> > Hello,
> >
> > On Fri 28-04-17 11:56:24, Corentin Labbe wrote:
> > > Since linux next-20170421, mounting nfs give me:
> > >
synchronous since they can block progress of the
> journalling (commit, log syncs) machinery and thus the whole filesystem.
>
> [1] https://www.spinics.net/lists/linux-ext4/msg56238.html
>
> Fixes: b685d3d65ac (block: treat REQ_FUA and REQ_PREFLUSH as synchronous)
> Cc: stab
with: "mount.nfs: Cannot allocate memory"
I've tried reproducing this (both with NFSv3 and NFSv4) and failed. Also I
have looked through the code and I fail to see how this could happen. Is
this the only NFS mount that you have on your system? Didn't also the
W
_mount+0x54/0x128)
> [ 774.995921] [] (vfs_kern_mount) from []
> (do_mount+0x158/0xc7c)
> [ 774.995935] [] (do_mount) from [] (SyS_mount+0x8c/0xb4)
> [ 774.995949] [] (SyS_mount) from []
> (ret_fast_syscall+0x0/0x3c)
> [ 774.995958] ---[ end trace 0665e451f8864ff1 ]---
>
> The mount command is
> mount -t nfs -o tcp,hard,intr,async,rsize=4096,wsize=4096
> 192.168.1.100:/mnt/local_kernel /usr/src/
>
> the mount command failling with: "mount.nfs: Cannot allocate memory"
>
> Regards
--
Jan Kara
SUSE Labs, CR
On Wed 26-04-17 16:52:36, Ross Zwisler wrote:
> On Wed, Apr 26, 2017 at 10:52:35AM +0200, Jan Kara wrote:
> > On Tue 25-04-17 16:59:36, Ross Zwisler wrote:
> > > On Tue, Apr 25, 2017 at 01:10:43PM +0200, Jan Kara wrote:
> > > <>
> > > > Hum, but now thi
On Tue 25-04-17 16:59:36, Ross Zwisler wrote:
> On Tue, Apr 25, 2017 at 01:10:43PM +0200, Jan Kara wrote:
> <>
> > Hum, but now thinking more about it I have hard time figuring out why write
> > vs fault cannot actually still race:
> >
> > CPU1 - write(2)
; + return -EIO;
> }
> memcpy(sig, boot_bh->b_data, 4);
> brelse(boot_bh);
> --
> 2.1.0
>
>
--
Jan Kara
SUSE Labs, CR
nux/fs/read_write.c:558
> > [< inline >] SYSC_pwrite64 project/linux/fs/read_write.c:647
> > [< none >] SyS_pwrite64+0x98/0xc0
> > project/linux/fs/read_write.c:634
> > [< none >] entry_SYSCALL_64_fastpath+0x1f/0xc2
> > project/linux_2/arch/x86/entry/entry_64.S:204
> > RIP: 0033:0x7f42acd4d213
> > RSP: 002b:7ffc846e4e38 EFLAGS: 0246 ORIG_RAX: 0012
> > RAX: ffda RBX: RCX: 7f42acd4d213
> > RDX: 001e RSI: 7f42a5c9f010 RDI: 0003
> > RBP: 559bd6c46380 R08: 7f42a5c9f010 R09: 0200
> > R10: 00068082 R11: 0246 R12: 7ffc846e4f9c
> > R13: 0425 R14: 0200 R15: 559bd6c46380
> >
>
--
Jan Kara
SUSE Labs, CR
On Tue 25-04-17 06:35:13, Jeff Layton wrote:
> On Tue, 2017-04-25 at 10:17 +0200, Jan Kara wrote:
> > On Mon 24-04-17 13:14:36, Jeff Layton wrote:
> > > On Mon, 2017-04-24 at 18:04 +0200, Jan Kara wrote:
> > > > On Mon 24-04-17 09:22:49, Jeff Layton wrote:
> > &
calling invalidate_inode_pages2_range() in
> dax_iomap_actor() for new block allocations, and by enhancing
> __dax_invalidate_mapping_entry() so that it properly unmaps the DAX entry
> being removed from the radix tree.
>
> This is based on an initial patch from Jan Kara.
>
> Sign
tially never have unmapped DAX entries to evict from the
> radix tree, just remove dax_invalidate_mapping_entry().
>
> Signed-off-by: Ross Zwisler
> Fixes: c6dcf52c23d2 ("mm: Invalidate DAX radix tree entries only if
> appropriate")
> Reported-by: Jan Kara
> Cc: [4.10+]
On Mon 24-04-17 13:14:36, Jeff Layton wrote:
> On Mon, 2017-04-24 at 18:04 +0200, Jan Kara wrote:
> > On Mon 24-04-17 09:22:49, Jeff Layton wrote:
> > > This ensures that we see errors on fsync when writeback fails.
> > >
> > > Signed-off-by: Jeff Layton
&g
gned-off-by: Andrey Ryabinin
> Acked-by: Konrad Rzeszutek Wilk
Looks sensible to me but I don't really know cleancache :). Anyway feel
free to add:
Acked-by: Jan Kara
Honza
> ---
> mm/truncate.c | 12 +++-
y: Konrad Rzeszutek Wilk
Looks good. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> mm/truncate.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/mm/truncate.c b/mm/truncate.c
> index 6263aff..8f
gt;
> Fixes: c515e1fd361c ("mm/fs: add hooks to support cleancache")
> Signed-off-by: Andrey Ryabinin
> Acked-by: Konrad Rzeszutek Wilk
> Cc:
Looks good. You can add:
Reviewed-by: Jan Kara
Honza
> ---
&
ge_readpage[s]()), so they
> are not affected by this bug.
>
> Fixes: c515e1fd361c ("mm/fs: add hooks to support cleancache")
> Signed-off-by: Andrey Ryabinin
> Acked-by: Konrad Rzeszutek Wilk
> Cc:
OK, looks good. You can add:
Reviewed-by: Jan Kara
gt; @@ -1669,6 +1669,7 @@ static int fuse_writepage_locked(struct page *page)
> err_free:
> fuse_request_free(req);
> err:
> + mapping_set_error(page->mapping, error);
> end_page_writeback(page);
> return error;
> }
> --
> 2.9.3
>
>
--
Jan Kara
SUSE Labs, CR
On Mon 24-04-17 09:22:48, Jeff Layton wrote:
> launder_page is just writeback under the page lock. We still need to
> mark the mapping for errors there when they occur.
>
> Signed-off-by: Jeff Layton
Looks good. You can add:
Reviewed-
On Mon 24-04-17 09:22:47, Jeff Layton wrote:
> If writepage fails during a page migration, then we need to ensure that
> fsync will see it by flagging the mapping.
>
> Signed-off-by: Jeff Layton
Looks good to me. You can add:
Reviewed-
gh the mapping.
After improving the changelog you can add:
Reviewed-by: Jan Kara
Honza
> ---
> fs/dax.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/fs/dax.c b/fs/dax.c
> index 85ab
That
> will be sufficient for this case, and help other callers detect
> these errors properly as well.
>
> With that, we don't need to twiddle it in ext2.
>
> Suggested-by: Jan Kara
> Signed-off-by: Jeff Layton
Looks good t
b_cache_pmem().
>
> Cc: Jan Kara
> Cc: Jeff Moyer
> Cc: Christoph Hellwig
> Cc: Toshi Kani
> Cc: Al Viro
> Cc: Matthew Wilcox
> Cc: Ross Zwisler
> Cc: Linus Torvalds
> Signed-off-by: Dan Williams
...
> +static int pmem_from_user(void *dst, const void __user *s
rk_locked(struct fsnotify_mark *mark,
> struct inode *inode,
>FSNOTIFY_MARK_FLAG_ATTACHED);
> list_del_init(&mark->g_list);
> atomic_dec(&group->num_marks);
> - spin_unlock(&mark->lock);
>
> fsnotify_put_mark(mark);
> return ret;
--
Jan Kara
SUSE Labs, CR
/* Restore everything back so that we don't lose data... */
> lock_page(page);
> - kaddr = kmap(page);
> down_write(&iinfo->i_data_sem);
> + kaddr = kmap_atomic(page);
> memcpy(iinfo->i_ext.i_dat
s/udf/namei.c
> @@ -906,7 +906,7 @@ static int udf_unlink(struct inode *dir, struct dentry
> *dentry)
> static int udf_symlink(struct inode *dir, struct dentry *dentry,
> const char *symname)
> {
> - struct inode *inode = udf_new_inode(dir, S_IFLNK | S_IRWXUGO);
> + struct inode *inode = udf_new_inode(dir, S_IFLNK | 0777);
> struct pathComponent *pc;
> const char *compstart;
> struct extent_position epos = {};
> --
> 2.9.3
>
>
--
Jan Kara
SUSE Labs, CR
On Thu 20-04-17 16:35:10, Jan Kara wrote:
> On Wed 19-04-17 13:28:36, Ross Zwisler wrote:
> > On Wed, Apr 19, 2017 at 06:11:31PM +0300, Andrey Ryabinin wrote:
> > > On 04/18/2017 10:38 PM, Ross Zwisler wrote:
> > > > On Fri, Apr 14, 2017 at 05:07:50PM +0300, Andrey
wise?
>
> For DAX we only invalidate clean DAX exceptional entries so that we can keep
> dirty entries around for writeback, but yes you're correct that we only do the
> invalidation if nrpages > 0. And yes, it does seem a bit weird. :)
Actually in this place the nrpages check is deliberate since there should
only be hole pages or nothing in the invalidated range - see the comment
before the if. But thinking more about it this assumption actually is not
right in presence of zero PMD entries in the radix tree. So this change
actually also fixes a possible bug for DAX but we should do it as a
separate patch with a proper changelog.
Honza
--
Jan Kara
SUSE Labs, CR
ow long would it take for the counter to overflow if we
incremented it say every nanosecond?
Honza
--
Jan Kara
SUSE Labs, CR
t2_error(sb, __func__,
> "detected IO error when writing metadata buffers");
> --
> 2.9.3
>
--
Jan Kara
SUSE Labs, CR
On Wed 12-04-17 08:06:00, Jeff Layton wrote:
> Signed-off-by: Jeff Layton
Looks good. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> fs/buffer.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
&g
ayton
> Reviewed-by: Ross Zwisler
Looks good. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> mm/memory-failure.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/memory-f
igned-off-by: Jeff Layton
> Reviewed-by: Ross Zwisler
Looks good. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> fs/exofs/dir.c| 2 +-
> fs/ext2/dir.c | 2 +-
> fs/jfs/jfs_metapage.c | 4 +
On Sun 19-03-17 12:12:37, Jan Kara wrote:
> On Fri 17-03-17 14:19:22, Andreas Dilger wrote:
> > On Mar 16, 2017, at 11:47 PM, Eric Biggers wrote:
> > > On Thu, Mar 16, 2017 at 11:35:33AM +, David Howells wrote:
> > >> +
> > >> +ext4_get_i
On Mon 10-04-17 14:34:29, Ross Zwisler wrote:
> On Mon, Apr 10, 2017 at 03:41:11PM +0200, Jan Kara wrote:
> > On Thu 06-04-17 15:29:44, Ross Zwisler wrote:
> > > While running generic/340 in my test setup I hit the following race. It
> > > can
> > > happen w
On Mon 10-04-17 15:07:58, alexander.le...@verizon.com wrote:
> On Mon, Apr 10, 2017 at 02:06:38PM +0200, Jan Kara wrote:
> > On Mon 10-04-17 02:22:33, alexander.le...@verizon.com wrote:
> > > On Fri, Dec 05, 2014 at 09:52:44AM -0500, Johannes Weiner wrote:
> > > > T
index in the PMD range. We haven't
> - * inserted anything into the radix tree and have no
> - * waiters to wake.
> + * Our insertion of a DAX entry failed, most likely
> + * because we were insert
0b ud2 <-- trapping instruction
> 2d: 48 ba 00 00 00 00 00movabs $0xdc00,%rdx
> 34: fc ff df
> 37: 48 c7 04 13 00 00 00movq $0x0,(%rbx,%rdx,1)
> 3e: 00
> 3f: 48 rex.W
> ...
>
> Code starting with the faulting instruction
> ===
>0: 0f 0b ud2
>2: 48 ba 00 00 00 00 00movabs $0xdc00,%rdx
>9: fc ff df
>c: 48 c7 04 13 00 00 00movq $0x0,(%rbx,%rdx,1)
> 13: 00
> 14: 48 rex.W
> ...
> [ 19.050311] RIP: __set_page_dirty_nobuffers+0x407/0x450 RSP:
> 8800c0f47318^M (??:?)
>
> --
>
> Thanks,
> Sasha
--
Jan Kara
SUSE Labs, CR
On Thu 06-04-17 11:12:02, NeilBrown wrote:
> On Wed, Apr 05 2017, Jan Kara wrote:
> >> If you want to ensure read-only files can remain cached over a crash,
> >> then you would have to mark a file in some way on stable storage
> >> *before* allowing any change.
&
:11:48AM -0400, Jeff Layton wrote:
> >> > > On Thu, 2017-03-30 at 08:47 +0200, Jan Kara wrote:
> >> > > > Because if above is acceptable we could make reported i_version to
> >> > > > be a sum
> >> > > > of "superblock crash co
s usually stack allocated.
Or just a plain sequence counter of the lock operations? There are ways how
we could implement the functionality without the counter and although
asymptotically they will be the same, they are more complex code-wise so I
think the counter is the best solution.
Hoza
--
Jan Kara
SUSE Labs, CR
On Sun 02-04-17 09:05:26, Dave Chinner wrote:
> On Thu, Mar 30, 2017 at 12:12:31PM -0400, J. Bruce Fields wrote:
> > On Thu, Mar 30, 2017 at 07:11:48AM -0400, Jeff Layton wrote:
> > > On Thu, 2017-03-30 at 08:47 +0200, Jan Kara wrote:
> > > > Because if above is acc
see as viable to reduce amount of messages as it is neverending
fight and always someone will be unhappy. As a result currently some machines
are not able to boot due to printk traffic and there are other nasty
effects from CPUs getting stuck printing messages to serial console (and
this really bothers people as is proved by the fact that about every 6
months someone comes with a hack to printk to fix the particular lockup he
is hitting).
This patch set gives up part of the printk() reliability for bounded
latency (at least unless we detect we are really in trouble) which is IMHO
a good trade-off for lots of users (and others can just turn this feature
off).
Honza
--
Jan Kara
SUSE Labs, CR
1101 - 1200 of 3531 matches
Mail list logo
