LLET
Looks good. Feel free to add:
Reviewed-by: Jan Kara
Honza
> ---
> Slightly compile tested only, but "git grep dax_supported" now returns
> nothing.
> ---
> include/linux/dax.h | 6 --
> 1 file
support DAX.
>
> This is relevant for architectures which require a dynamic check
> to validate whether they have virtually aliased data caches.
>
> Fixes: d92576f1167c ("dax: does not work correctly with virtual aliasing
> caches")
> Signed-off-by: Mathieu Desnoyers
>
sed data caches
> (ARCH_HAS_CACHE_ALIASING_DYNAMIC=y).
>
> Fixes: d92576f1167c ("dax: does not work correctly with virtual aliasing
> caches")
> Signed-off-by: Mathieu Desnoyers
> Cc: Jan Kara
> Cc: linux-e...@vger.kernel.org
> Cc: Andrew Morton
> Cc: Li
0.
>
> Signed-off-by: Abhinav Singh
Nice cleanup. Feel free to add:
Reviewed-by: Jan Kara
Honza
> ---
> fs/dax.c | 2 +-
> fs/direct-io.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
alue stored to 'error' is
> used in the enclosing expression, the value is never actually read
> from 'error' [deadcode.DeadStores]
>
> Signed-off-by: Colin Ian King
Yeah, good spotting. Feel free to add:
Reviewed-by: Jan Kara
"dax: wrprotect pmd_t in dax_mapping_entry_mkclean")
> Signed-off-by: Muchun Song
Looks good. Feel free to add:
Reviewed-by: Jan Kara
Honza
> ---
> fs/dax.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deleti
due to this. Maybe because the architectures that
> have virtual indexed caches is less.
>
> Fixes: f27176cfc363 ("mm: convert page_mkclean_one() to use
> page_vma_mapped_walk()")
> Signed-off-by: Muchun Song
> Reviewed-by: Yang Shi
Looks good.
t; > {
> > > - /* If we were the only waiter woken, wake the next one */
> > > - if (entry && !dax_is_conflict(entry))
> > > - dax_wake_entry(xas, entry, false);
> > > + if (dax_is_conflict(entry))
> > > + return;
> > > +
> > > + dax_wake_entry(xas, entry, false);
> >
>
> Hi Dan,
>
> > How does this work if entry is NULL? dax_entry_waitqueue() will not
> > know if it needs to adjust the index.
>
> Wake waiters both at current index as well PMD adjusted index. It feels
> little ugly though.
>
> > I think the fix might be to
> > specify that put_unlocked_entry() in the invalidate path needs to do a
> > wake_up_all().
>
> Doing a wake_up_all() when we invalidate an entry, sounds good. I will give
> it a try.
Yeah, that's what I'd suggest as well. After invalidating entry, there's no
point to let other waiters sleep. Trying to optimize for thundering herd
problems in face of entry invalidation is really fragile as you noticed.
Honza
--
Jan Kara
SUSE Labs, CR
On Wed 14-04-21 11:33:14, Khazhy Kumykov wrote:
> On Wed, Apr 14, 2021 at 2:54 AM Jan Kara wrote:
> >
> > On Thu 18-03-21 23:00:15, Khazhismel Kumykov wrote:
> > > lockdep warns of circular locking due to inversion between
> > > bfq_insert_requests and bfq_exit
ev_direct_IO(struct kiocb *iocb, struct inode
> *inode,
>
> fail_dio:
> if (dio->flags & DIO_LOCKING && iov_iter_rw(iter) == READ)
> - inode_unlock(inode);
> + inode_unlock_shared(inode);
>
> kmem_cache_free(dio_cache, dio);
> return retval;
> --
> 2.29.2
>
--
Jan Kara
SUSE Labs, CR
xit_icq is either called with a refcount,
> + * or with queue quiesced, use a differnet lock class to
> + * silence lockdep
> + */
> + spin_lock_irqsave_nested(&bfqd->lock, flags, 1);
> bfqq->bic = NULL;
> bfq_exit_bfqq(bfqd, bfqq);
> bic_set_bfqq(bic, NULL, is_sync);
> --
> 2.31.0.rc2.261.g7f71774620-goog
>
--
Jan Kara
SUSE Labs, CR
On Mon 12-04-21 18:42:58, Hao Sun wrote:
> Jan Kara 于2021年4月12日周一 下午5:02写道：
> >
> > Hello,
> >
> > On Sun 11-04-21 11:42:05, Hao Sun wrote:
> > > Since the last KCSAN report[1], I found two more KCSAN reports that
> > > Syzbot had not reported.
>
0
> vfs_write+0x6db/0x7c0
> ksys_write+0xce/0x180
> __x64_sys_write+0x3e/0x50
> do_syscall_64+0x39/0x80
> entry_SYSCALL_64_after_hwframe+0x44/0xae
>
>
> [1]
> https://lore.kernel.org/lkml/cackbjszw5sp4jb51+c5mrmssgq73x8ieko_ev6ctxvvtva7...@mail.gmail.com/
--
Jan Kara
SUSE Labs, CR
info 8813bb5f72d0
> > struct ext4_group_info {
> > bb_state = 0,
> > bb_free_root = {
> > rb_node = 0x0
> > },
> > bb_first_free = 1681,
> > bb_free = 0,
>
> Not related to this issue, but above two variables values doesn't looks
> consistent.
>
> > bb_fragments = 0,
> > bb_largest_free_order = -1,
> > bb_prealloc_list = {
> > next = 0x880268291d78,
> > prev = 0x880268291d78 ---> *** The list is empty
> > },
>
> Ok. So when you collected the dump this list was empty.
No, it is not empty. It has a single element. Note that the structure is at
8813bb5f72d0 so the pointers would have to be like 8813bb5f7xxx.
Honza
--
Jan Kara
SUSE Labs, CR
s harder to understand for me. So
I prefer to keep things as they are in this particular case...
Honza
--
Jan Kara
SUSE Labs, CR
On Tue 06-04-21 11:01:39, Theodore Ts'o wrote:
> On Tue, Apr 06, 2021 at 02:32:33PM +0200, Jan Kara wrote:
> > And the comment explains, why we do this unreliable check. Again, if we
> > wanted to silence KCSAN, we could use data_race() macro but AFAIU Ted isn't
> &g
I'm quite confident it was caused by one of
unlocked accesses to jh->b_transaction in jbd2_journal_dirty_metadata().
And as the comments explain, these are only assertions which we redo under
proper lock if they look like they would fail. So the code is in fact
correct.
. Again, if we
wanted to silence KCSAN, we could use data_race() macro but AFAIU Ted isn't
very fond of that annotation.
Honza
--
Jan Kara
SUSE Labs, CR
12 ---
> fs/ext2/namei.c | 34 +++---
> 3 files changed, 89 insertions(+), 51 deletions(-)
>
> --
> 2.28.0.rc0.12.gb6a658bd00c9
>
--
Jan Kara
SUSE Labs, CR
ntk() macros to no_printk(), which avoids this
> warning and adds format string checking.
>
> Signed-off-by: Arnd Bergmann
Sure. Feel free to add:
Reviewed-by: Jan Kara
Honza
> ---
> include/linux/jbd2.h | 2 +-
> 1 f
mark_wake() can be
called only for marks attached to objects and these have mark->conn !=
NULL and we are sure that fsnotify_destroy_group() will wait for all such
marks to be torn down and freed before dropping last group reference and
freeing the group.
Honza
--
Jan Kara
SUSE Labs, CR
On Fri 26-03-21 09:18:45, Alexander Lochmann wrote:
> On 11.02.21 10:30, Jan Kara wrote:
> >> diff --git a/include/linux/jbd2.h b/include/linux/jbd2.h
> >> index 99d3cd051ac3..18f77d9b1745 100644
> >> --- a/include/linux/jbd2.h
> >> +++ b/include/linux/j
patch together to submit with the kmap_local_page()
> patch.
OK :).
Honza
--
Jan Kara
SUSE Labs, CR
;
> Cc: Amir Goldstein
> Cc: Jan Kara
> Signed-off-by: Christian Brauner
Thanks for the cleanup. I've added it to my tree.
Honza
> ---
> fs/notify/fanotify/fanotify_user.c | 2 +-
> 1 file changed, 1 insertion
3-21 07:24:18, Sasha Levin wrote:
> From: Jan Kara
>
> [ Upstream commit 163f0ec1df33cf468509ff38cbcbb5eb0d7fac60 ]
>
> Syzbot is reporting that ext4 can enter fs reclaim from kvmalloc() while
> the transaction is started like:
>
> fs_reclaim_acquire+0x117/0x150 mm
nn
> Signed-off-by: Horst Schirmeier
Yeah, I think that was a typo since the beginning. Thanks for the fix. Feel
free to add:
Reviewed-by: Jan Kara
Honza
> ---
> include/linux/journal-head.h | 4 ++--
> 1 file
&sbi->s_next_gen_lock);
>
> - /* per fileystem reservation list head & lock */
> + /* per filesystem reservation list head & lock */
> spin_lock_init(&sbi->s_rsv_window_lock);
> sbi->s_rsv_window_root = RB_ROOT;
> /*
> --
> 2.25.1
>
--
Jan Kara
SUSE Labs, CR
it2sys_epoll_pwait2
> compat_sys_epoll_pwait2
> 442 common mount_setattr sys_mount_setattr
> sys_mount_setattr
> -443 common quotactl_path sys_quotactl_path
> +443 common quotactl_path sys_quotactl_path
> sys_quotactl_path
--
Jan Kara
SUSE Labs, CR
hile the inode is alive. Now this is fine for the particular flag we
update but in theory, if the compiler wants to screw us and stores
temporarily some nonsensical value in i_opflags we'd have a problem. This
is mostly a theoretical issue but eventually we probably want to fix this.
Honza
--
Jan Kara
SUSE Labs, CR
1 +
> arch/x86/entry/syscalls/syscall_64.tbl | 1 +
> arch/xtensa/kernel/syscalls/syscall.tbl | 1 +
> fs/quota/quota.c| 49 +++--
> include/linux/syscalls.h| 2 +
> include/uapi/asm-generic/unistd.h | 4 +-
> kernel/sys_ni.c | 1 +
> 22 files changed, 71 insertions(+), 5 deletions(-)
>
> --
> 2.29.2
>
--
Jan Kara
SUSE Labs, CR
m/x/repro.c?x=1191aab2d0
>
> The issue was bisected to:
>
> commit 2d01ddc86606564fb08c56e3bc93a0693895f710
> Author: Jan Kara
> Date: Wed Dec 16 10:18:40 2020 +
>
> ext4: save error info to sb through journal if available
After some head scratching I think
==
So this case is harmless. start_this_handle() does indeed check
journal->j_running_transaction without any protection and this is only a
racy check to opportunistically preallocate a transaction if we are likely
to need it. There was some macro to instruct KCSAN that the read is
actually fine, wasn't there?
Honza
--
Jan Kara
SUSE Labs, CR
On Wed 24-02-21 13:41:15, Matthew Wilcox wrote:
> On Wed, Feb 24, 2021 at 01:38:48PM +0100, Jan Kara wrote:
> > > We allocate a page and try to read it. 29 threads pile up waiting
> > > for the page lock in filemap_update_page(). The error returned by the
> > > orig
/vmscan.c:3523 [inline]
> balance_pgdat+0x745/0x1270 mm/vmscan.c:3681
> kswapd+0x5b1/0xdb0 mm/vmscan.c:3938
> kthread+0x3b1/0x4a0 kernel/kthread.c:292
> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296
Honza
--
Jan Kara
SUSE Labs, CR
page);
> clear_bit_unlock(PG_fscache, &page->flags);
> - wake_up_page_bit(page, PG_fscache);
> + wake_up_page_bit(page, PG_fscache, 0);
> }
> EXPORT_SYMBOL(unlock_page_fscache);
>
> @@ -2298,8 +2310,11 @@ static int filemap_update_page(struct kiocb *iocb,
> if (iocb->ki_flags & (IOCB_NOWAIT | IOCB_NOIO))
> return -EAGAIN;
> if (!(iocb->ki_flags & IOCB_WAITQ)) {
> - put_and_wait_on_page_locked(page, TASK_KILLABLE);
> - return AOP_TRUNCATED_PAGE;
> + error = put_and_wait_on_page_locked(page,
> + TASK_KILLABLE);
> + if (!error)
> + return AOP_TRUNCATED_PAGE;
> + return error;
> }
> error = __lock_page_async(page, iocb->ki_waitq);
> if (error)
--
Jan Kara
SUSE Labs, CR
er.c:4983
>
> Reported-by: syzbot+a8b4b0c60155e87e9...@syzkaller.appspotmail.com
> Signed-off-by: Sabyrzhan Tasbolatov
Looks good. Feel free to add:
Reviewed-by: Jan Kara
Honza
> ---
> v2: updated > 32 condit
Honza
> + ext4_msg(sb, KERN_ERR, "too many log groups per
> flexible block group");
> + goto err_freesgi;
> + }
> + sbi->s_mb_prefetch = min_t(uint, 1 <<
> sbi->s_es->s_log_groups_per_flex,
> BLK_MAX_SEGMENT_SIZE >> (sb->s_blocksize_bits - 9));
> sbi->s_mb_prefetch *= 8; /* 8 prefetch IOs in flight at most */
> } else {
> --
> 2.25.1
>
--
Jan Kara
SUSE Labs, CR
On Mon 15-02-21 23:06:15, Tetsuo Handa wrote:
> On 2021/02/15 21:45, Jan Kara wrote:
> > On Sat 13-02-21 23:26:37, Tetsuo Handa wrote:
> >> Excuse me, but it seems to me that nothing prevents
> >> ext4_xattr_set_handle() from reaching ext4_xattr_inode_l
On Sat 13-02-21 23:26:37, Tetsuo Handa wrote:
> On 2021/02/11 19:49, Jan Kara wrote:
> > This stacktrace should never happen. ext4_xattr_set() starts a transaction.
> > That internally goes through start_this_handle() which calls:
> >
> > handle->saved_allo
On Fri 12-02-21 11:29:00, Sascha Hauer wrote:
> On Fri, Feb 12, 2021 at 11:05:05AM +0100, Jan Kara wrote:
> > On Fri 12-02-21 09:38:35, Sascha Hauer wrote:
> > > On Thu, Feb 11, 2021 at 03:38:13PM +, Christoph Hellwig wrote:
> > > > > + if (!mountpoin
uapi/asm-generic/unistd.h | 4 +-
> kernel/sys_ni.c | 1 +
> 22 files changed, 74 insertions(+), 2 deletions(-)
>
> --
> 2.20.1
>
--
Jan Kara
SUSE Labs, CR
fix this or is there userspace code that is confused by a changed
> return value?
I'd leave the original quotactl(2) as is. There's no strong reason to risk
breaking some userspace. For the new syscall, I agree we can just
standardize the return value, there ENODEV makes even less s
mment:
> "no lock needed for jbd2 thread".
>
> Signed-off-by: Alexander Lochmann
> Signed-off-by: Horst Schirmeier
Thanks. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> include/linux/jbd2.h | 8 +
On Thu 11-02-21 12:47:18, Dmitry Vyukov wrote:
> On Thu, Feb 11, 2021 at 12:37 PM Jan Kara wrote:
> >
> > On Wed 10-02-21 03:25:22, syzbot wrote:
> > > Hello,
> > >
> > > syzbot found the following issue on:
> > >
> > > HEAD commit:
On Thu 11-02-21 10:53:51, Alexander Lochmann wrote:
>
>
> On 11.02.21 10:30, Jan Kara wrote:
> > >*/
> > > unsigned long t_log_start;
> > > - /* Number of buffers on the t_buffers list [j_list_lock] */
> > >
On Thu 11-02-21 20:04:14, Hillf Danton wrote:
> On Thu 11-02-21 12:07:29, Jan Kara wrote:
> >> Fix 71b565ceff37 ("ext4: drop ext4_kvmalloc()") by restoring the
> >> GFP_NOFS introduced in dec214d00e0d ("ext4: xattr inode deduplication").
> >&g
On Thu 11-02-21 12:28:48, Dmitry Vyukov wrote:
> On Thu, Feb 11, 2021 at 12:22 PM Dmitry Vyukov wrote:
> >
> > On Thu, Feb 11, 2021 at 11:49 AM Jan Kara wrote:
> > >
> > > Hello,
> > >
> > > added mm guys to CC.
> > >
> > > On
On Thu 11-02-21 12:22:39, Dmitry Vyukov wrote:
> On Thu, Feb 11, 2021 at 11:49 AM Jan Kara wrote:
> >
> > Hello,
> >
> > added mm guys to CC.
> >
> > On Wed 10-02-21 05:35:18, syzbot wrote:
> > > HEAD commit:1e0d27fc Merge branch 'akpm&
56bf60
> R13: 00007ffefc77f01f R14: 7f8097ffc300 R15: 00022000
>
>
> ---
> This report is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkal...@googlegroups.com.
>
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
>
--
Jan Kara
SUSE Labs, CR
out. Given we don't have
a reproducer it will be probably difficult to debug this. I'd note that
about year and half ago similar report happened (got autoclosed) so it may
be something real somewhere but it may also be just some HW glitch or
something like that.
Honza
--
Jan Kara
SUSE Labs, CR
fs/xattr.c:583
> > do_syscall_32_irqs_on arch/x86/entry/common.c:77 [inline]
> > __do_fast_syscall_32+0x56/0x80 arch/x86/entry/common.c:139
> > do_fast_syscall_32+0x2f/0x70 arch/x86/entry/common.c:164
> > entry_SYSENTER_compat_after_hwframe+0x4d/0x5c
>
> Fix 71b565ceff37 ("ext4: drop ext4_kvmalloc()") by restoring the
> GFP_NOFS introduced in dec214d00e0d ("ext4: xattr inode deduplication").
>
> Note this may be the fix also to possible deadlock
> Reported-by: syzbot+bfdded10ab7dcd750...@syzkaller.appspotmail.com
> https://lore.kernel.org/linux-ext4/563a0205bafb7...@google.com/
Please no. Ext4 is using scoping API to limit allocations to GFP_NOFS
inside transactions. In this case something didn't work which seems like a
lockdep bug at the first sight but I'll talk to mm guys about it.
Definitely to problem doesn't seem to be in ext4.
Honza
>
> --- a/fs/ext4/xattr.c
> +++ b/fs/ext4/xattr.c
> @@ -1459,7 +1459,7 @@ ext4_xattr_inode_cache_find(struct inode
> if (!ce)
> return NULL;
>
> - ea_data = kvmalloc(value_len, GFP_KERNEL);
> + ea_data = kvmalloc(value_len, GFP_NOFS);
> if (!ea_data) {
> mb_cache_entry_put(ea_inode_cache, ce);
> return NULL;
--
Jan Kara
SUSE Labs, CR
em is marked with a short comment:
> "no lock for quick racy checks".
>
> Signed-off-by: Alexander Lochmann
> Signed-off-by: Horst Schirmeier
This patch looks good. You can add:
Reviewed-by: Jan Kara
this
> - * list match each other one for one at all times. [j_list_lock]
> + * list match each other one for one at all times. [j_list_lock, no
> lock for quick racy checks]
>*/
> struct journal_head *t_shadow_list;
The above three cases are the same as t_reserved_list.
Honza
--
Jan Kara
SUSE Labs, CR
On Tue 09-02-21 08:51:01, Christoph Hellwig wrote:
> On Thu, Feb 04, 2021 at 01:53:50PM +0100, Jan Kara wrote:
> > Now quota data stored in a normal file is a setup we try to deprecate
> > anyway so another option is to just leave quotactl_path() only for those
> > setups wh
ap_util.c | 6 +-
> fs/xfs/xfs_file.c | 30 ++-
> fs/xfs/xfs_inode.c | 8 +-
> fs/xfs/xfs_inode.h | 1 +
> fs/xfs/xfs_iomap.c | 3 +-
> fs/xfs/xfs_iops.c | 11 ++-
> fs/xfs/xfs_reflink.c | 23 -
> include/linux/dax.h | 5 ++
>
On Thu 04-02-21 07:34:14, Christoph Hellwig wrote:
> On Tue, Feb 02, 2021 at 07:02:41PM +0100, Jan Kara wrote:
> > Hum, let me think out loud. The path we pass to Q_QUOTAON is a path to
> > quota file - unless the filesystem stores quota in hidden files in which
> > case
e as well since
I don't think we have a designated lib/parser.c maintainer...
Honza
--
Jan Kara
SUSE Labs, CR
.
>
> BingJing Chang (3):
> parser: add unsigned int parser
> isofs: handle large user and group ID
> udf: handle large user and group ID
Thanks for the patches. I've added these three patches to my tree.
Honza
--
Jan Kara
SUSE Labs, CR
ma->fsx_nextents = old_ma.fsx_nextents;
> + ma->fsx_projid = old_ma.fsx_projid;
> + ma->fsx_cowextsize = old_ma.fsx_cowextsize;
> + } else {
> + ma->flags |= old_ma.flags & ~FS_COMMON_F
ed queues in the waking mechanism may
> cause more control troubles than throughput benefits. This commit
> keeps shared queues out of the waker-detection mechanism.
>
> Tested-by: Jan Kara
> Signed-off-by: Paolo Valente
Honestly this makes me somewhat nervous. It is just a ban
new I/O request as
> >> soon as possible. So this commit puts this new I/O request directly
> >> into the dispatch list.
> >>
> >> Tested-by: Jan Kara
> >> Signed-off-by: Paolo Valente
> >> ---
> >> block/bfq-iosched.c | 17 +
ite(cmd)) {
This needs to be (quotactl_cmd_write(cmd) || quotactl_cmd_onoff(cmd)).
Otherwise I agree what you suggest is somewhat more readable given how
small the function is.
> ret = mnt_want_write(path.mnt);
> if (ret)
> goto out1;
> }
> if (quotactl_cmd_onoff(cmd))
> down_write(&sb->s_umount);
> else
> down_read(&sb->s_umount);
>
> and duplicate the checks after the do_quotactl call.
Honza
--
Jan Kara
SUSE Labs, CR
this!
What I didn't notice is that shallow_depth indeed gets used for each bitmap
word separately and not for bitmap as a whole. I'd say this could use some
more documentation but that's unrelated to your revert. So feel free to add:
Rev
; fs/isofs/inode.c | 9 +
> fs/udf/super.c | 9 +
> include/linux/parser.h | 1 +
> lib/parser.c | 44 +---
> 4 files changed, 44 insertions(+), 19 deletions(-)
>
> --
> 2.7.4
>
--
Jan Kara
SUSE Labs, CR
tification to each message similarly as we do it with ext4
messages (likely by using journal->j_dev) - which is very simple to do
after your patches 3 and 4.
Honza
--
Jan Kara
SUSE Labs, CR
On Tue 26-01-21 08:47:55, Jens Axboe wrote:
> On 1/26/21 6:29 AM, Jan Kara wrote:
> > On Mon 25-01-21 11:39:50, Jens Axboe wrote:
> >> On 1/25/21 11:35 AM, Paolo Valente wrote:
> >>>
> >>>
> >>>> Il giorno 25 gen 2021, alle ore 10:40, S
)
> >>
> >
> > Hi Jens,
> > how to proceed in such a case (with patches already applied by you)?
> > Shall I send you a v2 with only this change?
>
> We just have to ignore it... But in the future, always double check that
> you are using the right shas, not some sha from an internal tree.
FWIW I have a commit hook in my git tree that just refuses a commit with
unknown Fixes tag SHA. Exactly to catch such mishaps in the patches I
merge...
Honza
--
Jan Kara
SUSE Labs, CR
On Mon 18-01-21 15:41:23, Jan Kara wrote:
> On Mon 18-01-21 04:04:55, Pan Bian wrote:
> > Release the buffer header before returning error code.
> >
> > Fixes: 2deb1acc653c ("isofs: fix access to unallocated memory when reading
> > corrupted filesystem")
; +
> +#define jbd2_debug(j, fmt, a...) \
> + jbd2_log(JBD2_DEBUG, j, __FILE__, __func__, __LINE__, (fmt), ##a)
> +
> +#else
> +
> +#define jbd2_err(j, fmt, a...)
> +#define jbd2_warn(j, fmt, a...)
> +#define jbd2_notice(j, fmt, a...)
> +#define jbd2_info(j, fmt, a...)
> +#define jbd2_debug(j, fmt, a...)
> +
> +#endif
> #endif
>
> /*
> --
> 2.30.0
>
--
Jan Kara
SUSE Labs, CR
ate solution for this read problem. And
I'm also against duplicating ->read_iter functionatily in ->read handler.
The maintenance burden of this code duplication is IMHO just too big. We
rather need to improve the generic code so that the fast path is faster.
And every filesystem will benefit because this is not ext4 specific
problem.
Honza
--
Jan Kara
SUSE Labs, CR
On Sun 17-01-21 16:53:42, Dinghao Liu wrote:
> Once we have called device_initialize(), we should use put_device() to
> give up the reference on error, just like what we have done on failure
> of device_add().
>
> Signed-off-by: Dinghao Liu
Looks good to me. You can add:
Review
> " in block %lu of inode %lu\n", block,
> inode->i_ino);
> + brelse(bh);
> return -EIO;
> }
>
> --
> 2.17.1
>
--
Jan Kara
SUSE Labs, CR
sem). As a result this has been a long term source of
deadlocks, stale data exposure issues, and filesystem corruption issues due
to insufficient locking for multiple filesystems.
But when I was looking at what it would take to achieve this several years
ago, fixing all GUP users to deal with mmap_sem being dropped during a
fault was a gigantic task because there were users of GUP relying on
mmap_sem being held for large code sections around the GUP call...
Honza
--
Jan Kara
SUSE Labs, CR
returns true for it. At
least for shared pages. Because filesystems/mm in the writeback path need
to detect whether the page is pinned and thus its contents can change
anytime without noticing, the page can be dirtied at random times etc. In
that case we need to bounce the page during writeback (to avoid checksum
failures), keep page as dirty in internal filesystem bookkeeping (and in MM
as well) etc...
Honza
--
Jan Kara
SUSE Labs, CR
t; sb->s_blocksize_bits),
> @@ -757,8 +759,7 @@ static int udf_check_vsd(struct super_block *sb)
>
> if (nsr > 0)
> return 1;
> - else if (!bh && sector - (sbi->s_session << sb->s_blocksize_bits) ==
> - VSD_FIRST_SECTOR_OFFSET)
> + else if (!bh && sector - sector_offset == VSD_FIRST_SECTOR_OFFSET)
> return -1;
> else
> return 0;
> --
> 2.20.1
>
>
>
--
Jan Kara
SUSE Labs, CR
nt' loaded by udf_next_aext() ends up being EXT_NOT_RECORDED_ALLOCATED,
we will end up passing it to udf_do_extend_file() which recognizes it as
preallocation extent and will insert a hole extent before it? Am I missing
something?
Honza
> etype = udf_next_aext(inode, &next_epos, &eloc, &elen, 1);
> if (etype == -1)
> break;
>
--
Jan Kara
SUSE Labs, CR
* We've rewritten the last extent but there may be
> empty
> + * indirect extent after it - enter it.
> + */
> + udf_next_aext(inode, last_pos, &tmploc, &tmplen, 0);
> + }
> }
>
> /* Managed to do everything necessary? */
>
--
Jan Kara
SUSE Labs, CR
blocksize_bits),
> @@ -757,8 +759,7 @@ static int udf_check_vsd(struct super_block *sb)
>
> if (nsr > 0)
> return 1;
> - else if (!bh && sector - (sbi->s_session << sb->s_blocksize_bits) ==
> - VSD_FIRST_SECTOR_OFFSET)
> + else if (!bh && sector - sector_offset == VSD_FIRST_SECTOR_OFFSET)
> return -1;
> else
> return 0;
> --
> 2.20.1
>
>
>
--
Jan Kara
SUSE Labs, CR
5 # PD
> require_tag_id $AED_LSN 258 # AED
>
> LBN_BASE=`extract32 $PD_LSN 188` # Partition Starting Location
> AED_LBN=`expr $AED_LSN - $LBN_BASE`
> AED_TAG_LOCATION=`extract32 $AED_LSN 12`
>
> if [ $AED_TAG_LOCATION -ne $AED_LBN ] ; then
> echo Test FAILED: expected AED tag location $AED_LBN, actual is
> $AED_TAG_LOCATION
> exit 1
> else
> echo Test PASSED. AED tag location field is correct.
> fi
>
> Steven J. Magnani "I claim this network for MARS!
> Earthling, return my space modulator!"
> #include
>
--
Jan Kara
SUSE Labs, CR
ile it's being written back but usually it
takes time before next writeback of the page is started. But I guess with
the DB load it is possible e.g. if we frequently flush out some page for
data consistency reasons (I know PostgreSQL is using sync_file_range(2)
interface to start flushing pages early and then uses fsync(2) when it
really needs the pages written which could create a situation with unfair
treatment of PageWriteback bit).
Honza
--
Jan Kara
SUSE Labs, CR
> - end >> PAGE_SHIFT);
> + invalidate_first_page,
> + invalidate_last_page);
> }
>
> const struct file_operations def_blk_fops = {
> --
>
t gendisk *disk, bool
> verbose);
> bool bdev_check_media_change(struct block_device *bdev);
> int __invalidate_device(struct block_device *bdev, bool kill_dirty);
> void bd_set_nr_sectors(struct block_device *bdev, sector_t sectors);
> +int bd_corrupted_range(struct block_device *bdev, loff_t disk_off,
> +loff_t bdev_off, size_t len, void *data);
>
> /* for drivers/char/raw.c: */
> int blkdev_ioctl(struct block_device *, fmode_t, unsigned, unsigned long);
> --
> 2.29.2
>
>
>
--
Jan Kara
SUSE Labs, CR
largest mapping to avoid breaking up
> - * device-dax mappings which are constant size. The
> - * actual size of the mapping being torn down is
> - * communicated in siginfo, see kill_proc()
> - */
> - start = (page->index << PAGE_SHIFT) & ~(size - 1);
> - unmap_mapping_range(page->mapping, start, start + size, 0);
> - }
> - kill_procs(&to_kill, flags & MF_MUST_KILL, !unmap_success, pfn, flags);
> - rc = 0;
> -unlock:
> - dax_unlock_page(page, cookie);
> out:
> /* drop pgmap ref acquired in caller */
> put_dev_pagemap(pgmap);
> --
> 2.29.2
>
>
>
--
Jan Kara
SUSE Labs, CR
d *to_kill,
>* to be informed of all such data corruptions.
>*/
> if (vma->vm_mm == t->mm)
> - add_to_kill(t, page, vma, to_kill);
> + add_to_kill(t, page, mapping, pgoff, vma,
> to_kill);
> }
> }
> read_unlock(&tasklist_lock);
> @@ -550,7 +551,8 @@ static void collect_procs(struct page *page, struct
> list_head *tokill,
> if (PageAnon(page))
> collect_procs_anon(page, tokill, force_early);
> else
> - collect_procs_file(page, tokill, force_early);
> + collect_procs_file(page, page->mapping, page_to_pgoff(page),
Why not use page_mapping() helper here? It would be safer for THPs if they
ever get here...
Honza
--
Jan Kara
SUSE Labs, CR
nks for the patch! It looks good to me. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> fs/ext4/fast_commit.c | 23 ---
> 1 file changed, 12 insertions(+), 11 deletions(-)
>
> diff --g
ata;
> + struct block_device *bdev = &ei->bdev;
>
> inode_init_once(&ei->vfs_inode);
> + bdev->bd_bdi = &noop_backing_dev_info;
> }
>
> static void bdev_evict_inode(struct inode *inode)
> --
> 2.17.1
>
--
Jan Kara
SUSE Labs, CR
(wb->bdi), inode->i_ino, sb->s_id);
>
> inode->dirtied_when = jiffies;
> if (dirtytime)
> --
> 2.17.1
>
--
Jan Kara
SUSE Labs, CR
ttps://syzkaller.appspot.com/x/repro.syz?x=1798348750
> > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=10c0293750
> >
> > The issue was bisected to:
> >
> > commit e810c942a325cf749e859d7aa3a43dc219cea299
> > Author: Jan Kara
> >
zkaller.appspot.com/x/repro.syz?x=128f512350
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14f9f30f50
>
> The issue was bisected to:
>
> commit e810c942a325cf749e859d7aa3a43dc219cea299
> Author: Jan Kara
> Date: Wed Dec 16 10:18:40 2020 +
>
>
It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkal...@googlegroups.com.
>
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> syzbot can test
zeof(struct inotify_event_info),
> > GFP_KERNEL_ACCOUNT);
> > if (unlikely(!oevent)) {
> > fsnotify_destroy_group(group);
> > return ERR_PTR(-ENOMEM);
> > diff --git a/include/linux/fsnotify_backend.h
> > b/include/linux/fsnotify_backend.h
> > index a2e42d3cd87c..e5409b83e731 100644
> > --- a/include/linux/fsnotify_backend.h
> > +++ b/include/linux/fsnotify_backend.h
> > @@ -470,6 +470,7 @@ static inline void fsnotify_update_flags(struct dentry
> > *dentry)
> >
> > /* create a new group */
> > extern struct fsnotify_group *fsnotify_alloc_group(const struct
> > fsnotify_ops *ops);
> > +extern struct fsnotify_group *fsnotify_alloc_user_group(const struct
> > fsnotify_ops *ops);
> > /* get reference to a group */
> > extern void fsnotify_get_group(struct fsnotify_group *group);
> > /* drop reference on a group from fsnotify_alloc_group */
> > --
> > 2.29.2.684.gfbc64c5ab5-goog
> >
--
Jan Kara
SUSE Labs, CR
coherent so ignoring ->sync_fs() return value there is fine.
With dquot_quota_sync() it might make some sense to return the error -
that's just a backend for Q_SYNC quotactl(2). OTOH I'm not sure anybody
really cares - Q_SYNC is rarely used.
Honza
--
Jan Kara
SUSE Labs, CR
/*
>* Some events can be sent on both parent dir and child marks
>* (e.g. FS_ATTRIB). If both parent dir and child are
>* watching, report the event once to parent dir with name (if
>* interested) and once to child without name (if interested).
> + * The child watcher is expecting an event without a file name
> + * and without the FS_EVENT_ON_CHILD flag.
>*/
> + mask &= ~FS_EVENT_ON_CHILD;
> dir = NULL;
> name = NULL;
> }
> --
> 2.25.1
>
--
Jan Kara
SUSE Labs, CR
On Wed 09-12-20 17:15:02, Miklos Szeredi wrote:
> On Wed, Dec 9, 2020 at 2:59 PM Jan Kara wrote:
> >
> > On Wed 09-12-20 14:38:42, Jan Kara wrote:
> > > Hello!
> > >
> > > so I was debugging the dnotify crash below (it's 100% reproducible for me)
&g
On Wed 09-12-20 14:38:42, Jan Kara wrote:
> Hello!
>
> so I was debugging the dnotify crash below (it's 100% reproducible for me)
> and I came to the following. The reproducer opens 'file0' on FUSE
> filesystem which is a directory at that point. Then it attached d
://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkal...@googlegroups.com.
>
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection
> syzbot can test patches for this issue, for details see:
> https://goo.gl/tpsmEJ#testing-patches
--
Jan Kara
SUSE Labs, CR
if (ret < 0)
> - vfs_cleanup_quota_inode(sb, type);
> + vfs_cleanup_quota_inode(sb, cnt);
> }
>
> return ret;
> --
> 2.25.1
>
--
Jan Kara
SUSE Labs, CR
On Tue 01-12-20 16:51:26, Borislav Petkov wrote:
> On Tue, Dec 01, 2020 at 10:48:10AM +0100, Jan Kara wrote:
> > On Mon 30-11-20 17:30:59, Brian Gerst wrote:
> > > Commit 121b32a58a3a converted native x86-32 which take 64-bit arguments to
> > > use the compat hand
for the patch! It looks good to me. Feel free to add:
Acked-by: Jan Kara
I assume you plan to push this via x86 tree given the changes are mostly
there, don't you?
Honza
--
Jan Kara
SUSE Labs, CR
if (is_direntry_le_ih(ih) && (ih_item_len(ih) <
> (ih_entry_count(ih) * IH_SIZE))) {
> + reiserfs_warning(NULL, "reiserfs-5093",
> + "item entry count seems wrong %h",
> + ih);
> +
1 - 100 of 2015 matches
Mail list logo
