On Wed 27-03-19 18:59:48, Al Viro wrote:
> On Wed, Mar 27, 2019 at 05:58:31PM +0100, Jan Kara wrote:
> > On Tue 26-03-19 04:15:10, Al Viro wrote:
> > > On Mon, Mar 25, 2019 at 08:18:25PM -0700, Mark Fasheh wrote:
> > >
> > > > Hey Al,
> > > >
d was the
reason why writeback code does not take inode references but relies on
I_SYNC to protect it from inode reclaim instead (see commit 169ebd90131b
"writeback: Avoid iput() from flusher thread"). And they noticed the
problem as well and hacked around it... Now I don't know enough about F2FS
and its garbage collection to tell how they can avoid dropping inode
references from flush worker context. But that's the right solution for
avoiding deadlocks.
Honza
--
Jan Kara
SUSE Labs, CR
ops the flusher
thread from touching the inode but explicit writeback through
write_inode_now(inode, 1) should go through just fine.
Honza
--
Jan Kara
SUSE Labs, CR
On Wed 27-03-19 22:31:35, Liu Song wrote:
> From: Liu Song
>
> At the beginning, nblocks has been assigned. There is no need
> to repeat the assignment in the while loop, and remove it.
>
> Signed-off-by: Liu Song
Looks good. You can add:
Rev
> * Fixes: Dmitry Gorodchanin , 11 Feb 96
> @@ -51,7 +51,7 @@
> * Added journalled quota support, fix lock inversion problems
> * Jan Kara, , 2003,2004
> *
> - * (C) Copyright 1994 - 1997 Marco van Wieringen
> + * (C) Copyright 1994 - 1997 Marco van Wie
node.c:502:12: note: initialize the variable 'retval' to silence
> this warning
>
> Change it to BUG() so clang can see that this code path can never
> continue.
>
> Signed-off-by: Arnd Bergmann
Sure. Feel free to add:
Reviewed-by: Jan Kara
th in which the buffer does not get marked dirty again.
Generally, we add new extents to the created indirect extent which dirties
the buffer and that should fix the problem. But you are definitely right
that the code is suspicious and should be fixed. Will you send a patch?
Honza
--
Jan Kara
SUSE Labs, CR
result in e.g. open(2) returning -EINTR where
previously such error code never happened in practice. To avoid
confusion of userspace due to this error code, return -ERESTARTNOINTR
instead.
Signed-off-by: Jan Kara
---
fs/notify/fanotify/fanotify.c | 11 +--
1 file changed, 9 insertions(+), 2
Hello Linus,
could you please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git
fixes_for_v5.1-rc2
to get two udf error handling fixes.
Top of the tree is 2b42be5eb245. The full shortlog is:
Jan Kara (2):
udf: Fix crash on IO error during truncate
udf
Hello Linus,
could you please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git
fsnotify_for_v5.1-rc2
to get one inotify and one fanotify fix.
Top of the tree is b2d22b6bb33a. The full shortlog is:
Jan Kara (1):
fanotify: Allow copying of file handle to
On Wed 20-03-19 12:21:29, Dongli Zhang wrote:
> On 3/19/19 5:41 PM, Jan Kara wrote:
> > On Mon 18-03-19 20:27:02, Dongli Zhang wrote:
> >> Hi Jan,
> >>
> >> Indeed there is another issue implicitly reported by below console output
> >> from
&g
dquots[cnt]->dq_dqb.dqb_rsvspace -=
> number;
> } else {
> --
> 2.20.1
>
>
--
Jan Kara
SUSE Labs, CR
t; Yes, please. It sounds more sensible to me to dirty the page on get, not
> on put.
I fully agree this is a desirable final state of affairs. And with changes
to how we treat pinned pages during writeback there won't have to be any
explicit dirtying at all in the end because the page is guaranteed to be
dirty after a write page fault and pin would make sure it stays dirty until
unpinned. However initially I want the helpers to be as close to code they
are replacing as possible. Because it will be hard to catch all the bugs
due to driver conversions even in that situation. So I still think that
these helpers as they are a good first step. Then we need to convert
GUP users to use them and then it is much easier to modify the behavior
since it is no longer opencoded in two hudred or how many places...
Honza
--
Jan Kara
SUSE Labs, CR
On Sat 23-02-19 21:35:49, Yafang Shao wrote:
> With cgroup v2 writeback, we can know these pages are written from which
> cgroup.
> So expose the cgroup_ino for better tracking.
>
> Signed-off-by: Yafang Shao
Fine by me. You can add:
Ack
;nls_map)
> + return 0;
> uopt->flags |= (1 << UDF_FLAG_NLS_MAP);
> }
> break;
> --
> 2.17.1
>
>
--
Jan Kara
SUSE Labs, CR
;
> Signed-off-by: Alexander Lochmann
> Signed-off-by: Horst Schirmeier
Thanks! You can add:
Reviewed-by: Jan Kara
Honza
> ---
> include/linux/jbd2.h | 10 ++
> 1 file changed, 6 insertions(+), 4 delet
On Mon 18-03-19 11:27:12, Kees Cook wrote:
> On Wed, Mar 13, 2019 at 8:47 AM Jan Kara wrote:
> >
> > On Wed 13-03-19 08:35:33, Kees Cook wrote:
> > > On Wed, Mar 13, 2019 at 7:35 AM Jan Kara wrote:
> > > > On Tue 12-03-19 23:26:22, Kees Cook wrote:
>
On Thu 14-03-19 09:57:18, Jason Gunthorpe wrote:
> On Thu, Mar 14, 2019 at 10:03:45AM +0100, Jan Kara wrote:
> > On Wed 13-03-19 19:16:51, Christopher Lameter wrote:
> > > On Tue, 12 Mar 2019, Jerome Glisse wrote:
> > >
> > > > > > This has been
On Thu 14-03-19 14:01:18, Amir Goldstein wrote:
> On Thu, Mar 14, 2019 at 10:37 AM Jan Kara wrote:
> >
> > AFAICS this is the known problem with weird mips definitions of
> > __kernel_fsid_t which uses long whereas all other architectures use int,
> > right? Seeing th
e pages. Meaning the regular filesystems
> maintain control of whats happening with their pages.
And as I mentioned in my other email, we cannot just fail the pin for
pagecache pages as that would regress existing applications.
Honza
--
Jan Kara
SUSE Labs, CR
rs and you are welcome to do that in the drivers you care
about but definitely not for all.
Honza
--
Jan Kara
SUSE Labs, CR
fid->fsid = stat.f_fsid;
>193event->fh_len = bytes;
>194
>195return type;
>196
>197out_err:
> > 198 pr_warn_ratelimited("fanotify: failed to encode fid
> (fsid=%x.%x, "
>199"type=%d, bytes=%d, err=%i)\n",
>200stat.f_fsid.val[0],
> stat.f_fsid.val[1],
>201type, bytes, err);
>202kfree(fid->ext_fh);
>203fid->ext_fh = NULL;
>204event->fh_len = 0;
>205
>206return FILEID_INVALID;
>207}
>208
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
--
Jan Kara
SUSE Labs, CR
On Wed 13-03-19 08:35:33, Kees Cook wrote:
> On Wed, Mar 13, 2019 at 7:35 AM Jan Kara wrote:
> > On Tue 12-03-19 23:26:22, Kees Cook wrote:
> > > On Mon, Mar 11, 2019 at 1:42 PM syzbot
> > > wrote:
> > > > C reproducer: https://syzkaller
dening protections.
> +*/
> + fh = fanotify_event_fh(event);
> + if (fh_len <= sizeof(bounce)) {
> + memcpy(bounce, fh, fh_len);
> + fh = bounce;
> + }
> +
> + if (copy_to_user(buf, fh, fh_len))
> return -EFAULT;
>
> /* Pad with 0's */
>
>
> --
> Kees Cook
--
Jan Kara
SUSE Labs, CR
uct jbd2_revoke_table_s *j_revoke;
>
This is also not true. The contents of the revoke table itself is protected
by j_revoke_lock. The pointer to current revoke table (i.e. j_revoke
itself) is changed only when the currently running transation is in
T_SWITCH state - a special state where no updates can be happening anymore
and new transaction cannot be running yet either.
Honza
--
Jan Kara
SUSE Labs, CR
te(), possibly do some IO.
set_page_dirty() is rather uncertain context to acquire locks or do IO...
Honza
--
Jan Kara
SUSE Labs, CR
fanotify: add support for create/attrib/move/delete events
fanotify: report FAN_ONDIR to listener with FAN_REPORT_FID
Jan Kara (8):
fanotify: Select EXPORTFS
fanotify: Fold dequeue_event() into process_access_response()
fanotify: Move locking inside get_one_event
corrupted filesystem so that it doesn't get
corrupted even further
* couple smaller ext2 and udf cleanups
Top of the tree is 52b9666efd8b. The full shortlog is:
Chengguang Xu (1):
ext2: set proper return code
Jan Kara (3):
ext2: Set superblock revision when enabling xattr fe
fs_types.h
Thanks
Honza
--
Jan Kara
SUSE Labs, CR
&transparent_hugepage_flags);
> ret = 1;
> }
> out:
> @@ -753,6 +756,7 @@ static void insert_pfn_pmd(struct vm_area_struct *vma,
> unsigned long addr,
> spinlock_t *ptl;
>
> ptl = pmd_lock(mm, pmd);
> + /* should we check for none here again? */
> entry = pmd_mkhuge(pfn_t_pmd(pfn, prot));
> if (pfn_t_devmap(pfn))
> entry = pmd_mkdevmap(entry);
> --
> 2.20.1
>
--
Jan Kara
SUSE Labs, CR
; ext4_file_write_iter+0x254/0x460 [ext4]
> __vfs_write+0x120/0x1e0
> vfs_write+0xd8/0x220
> SyS_write+0x6c/0x110
> system_call+0x3c/0x130
>
> Signed-off-by: Aneesh Kumar K.V
Thanks for the patch. It looks good to me. You can add:
Reviewed-by: Jan Kara
> ---
>
gned-off-by: Liu Song
Looks good. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> fs/jbd2/transaction.c | 8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/fs/jbd2/transaction.c b/fs/jbd
On Mon 25-02-19 10:40:07, Sahitya Tummala wrote:
> On Tue, Feb 19, 2019 at 02:53:02PM +0100, Jan Kara wrote:
> > One has to be really careful when using i_size like this. By the time the
> > transaction is committing, i_size could have been reduced from the value at
> > the ti
lr_fd: partition scan of loop0 failed (rc=-22)
>
> This patch sets GENHD_FL_NO_PART_SCAN after blkdev_reread_part().
>
> Fixes: 0da03cab87e6 ("loop: Fix deadlock when calling blkdev_reread_part()")
> Signed-off-by: Dongli Zhang
> ---
> Changed since v1:
> * move the sett
where to look will help. Thanks!
>
> Tested both.
>
> Just CONFIG_MIGRATION + CONFIG_COMPACTION breaks the alpha.
> Just CONFIG_BOUNCE has no effect in 5 tries.
OK, so page migration is problematic. Thanks for confirmation!
Honza
--
Jan Kara
SUSE Labs, CR
here cannot be anybody else entering __loop_clr_fd() as
lo->lo_backing_file is already cleared and Lo_rundown state protects us
from all the other places trying to change the 'lo' device (please make
this last sentence into a comment in the code explaining why setting
lo->lo_state so late is fine). Thanks!
Honza
--
Jan Kara
SUSE Labs, CR
ow come I didn't see this in my
testing. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> drivers/block/loop.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/block/loop.c b/
On Tue 19-02-19 08:17:09, Steve Magnani wrote:
> On 2/19/19 8:02 AM, Jan Kara wrote:
> > On Tue 19-02-19 11:44:03, Colin King wrote:
> > > From: Colin Ian King
> > >
> > > There is a null check on the pointer bh to avoid a null pointer
> > > derefe
ks for testing! Can you narrow down whether the problem is due to
CONFIG_BOUNCE or CONFIG_MIGRATION + CONFIG_COMPACTION? These are two
completely different things so knowing where to look will help. Thanks!
Honza
--
Jan Kara
SUSE Labs, CR
mark_buffer_dirty(bh);
> + }
> sbi->s_lvid_dirty = 0;
> }
> mutex_unlock(&sbi->s_alloc_mutex);
> --
> 2.20.1
>
>
--
Jan Kara
SUSE Labs, CR
>From a00eb52e3f2f815efa52a9e3bf1b730d86c05faa Mon Sep 17 00:00:00 2001
From:
r
> context.
>
> Request you to share your thoughts and comments on this issue
> and the fix suggested above.
>
> Thanks,
> Sahitya.
>
> --
> Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
> Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
> Foundation Collaborative Project.
--
Jan Kara
SUSE Labs, CR
en.
Thanks for information. Yeah, that makes somewhat more sense. Can you ever
see the failure if you disable CONFIG_TRANSPARENT_HUGEPAGE? Because your
findings still seem to indicate that there' some problem with page
migration and Alpha (added MM list to CC).
Honza
--
Jan Kara
SUSE Labs, CR
k device pages we were not able to migrate
previously and that could be causing some unexpected issue. I'll look into
this.
Honza
--
Jan Kara
SUSE Labs, CR
eds to select EXPORTFS now. Added patch to my tree. Thanks
for report!
Honza
--
Jan Kara
SUSE Labs, CR
_do_munmap+0x2f0/0x510
>.__vm_munmap+0x80/0x110
>.__se_sys_munmap+0x14/0x30
>system_call+0x5c/0x70
>
> The fix is simple, we need to convert the result of the bitwise && to
> an int before returning it.
>
> Thanks to Jan Kara and Aneesh for help with debu
ade a mistake there. However, seeing this:
> https://lore.kernel.org/lkml/20190110030838.84446-1-yuz...@google.com/
>
> makes me think that I should be using xa_index + 1 there.
Yeah, you're right. Thanks!
Honza
--
Jan Kara
SUSE Labs, CR
On Tue 12-02-19 16:55:21, Christopher Lameter wrote:
> On Tue, 12 Feb 2019, Jan Kara wrote:
>
> > > Isn't that already racy? If the mmap user is fast enough can't it
> > > prevent the page from becoming freed in the first place today?
> >
> > No,
/
> if (unlikely(page != xas_reload(&xas)))
> goto put_page;
>
> - pages[ret] = page;
> + pages[ret] = find_subpage(page, xas.xa_index);
> if (++ret == nr_pages) {
> *index = page->
v_pagemap, Xarray entries, and sector-to-pfn
> translation established for pmem namespaces.
>
> Cc: Jan Kara
> Cc: "Darrick J. Wong"
> Signed-off-by: Dan Williams
> ---
> drivers/dax/super.c | 39 +--
> 1 file changed,
memcgs
set up that make the page allocation fail, can't you? So in principle Dan
is right. Page faults can and do fail...
Honza
--
Jan Kara
SUSE Labs, CR
gt; >
> > > Blocks also won't be free if you unlink a file that is currently still
> > > open.
> > >
> > > This isn't really new behavior for a FS.
> >
> > An mmap write after a fault due to a hole punch is free to trigger
> > SIGBUS if the subsequent page allocation fails.
>
> Isn't that already racy? If the mmap user is fast enough can't it
> prevent the page from becoming freed in the first place today?
No, it cannot. We block page faulting for the file (via a lock), tear down
page tables, free pages and blocks. Then we resume faults and return
SIGBUS (if the page ends up being after the new end of file in case of
truncate) or do new page fault and fresh block allocation (which can end
with SIGBUS if the filesystem cannot allocate new block to back the page).
Honza
--
Jan Kara
SUSE Labs, CR
ile before allowing gup_longterm() looks
like a more viable alternative.
Honza
--
Jan Kara
SUSE Labs, CR
to the user.
> Not sure if my assumption is correct that this would be ok
> w.r.t locking rules?
It should be fine AFAICT.
> Not sure if we can get away with trylock in all the cases that
> we need to modify upper.
I don't know overlayfs enough to be able to tell :).
Honza
--
Jan Kara
SUSE Labs, CR
On Mon 11-02-19 09:22:58, Dan Williams wrote:
> On Mon, Feb 11, 2019 at 2:24 AM Jan Kara wrote:
> >
> > On Fri 08-02-19 12:50:37, Dan Williams wrote:
> > > On Fri, Feb 8, 2019 at 3:11 AM Jan Kara wrote:
> > > >
> > > > On Fri 08-02-19 15:43:02, Da
may be missing something.
>
> My other thought is that perhaps sb_start_write() should invoke
> s_ops->start_write() so that overlay can do the freeze protection on
> the upper early.
So my understanding of overlayfs is pretty basic so I'm sorry if I miss
something. If I'm right, we have three superblocks here: ovl, upper, lower.
Now 'lower' is read-only so for freezing purposes we can just forget about
it. 'upper' is where the real changes are going into and 'ovl' is a wrapper
virtual superblock that handles merging of 'lower' and 'upper'. Correct so
far?
And the problem seems to be that when you acquire freeze protection for the
'ovl' superblock, you in fact want to acquire freeze protection for the
'upper' (as 'ovl' is just virtual and has no disk state to protect). So I
agree that a callback to allow overlayfs to acquire freeze protection on
'upper' right away would be one solution. Or we could make s_writers a
pointer and redirect ovl->s_writers to upper->s_writers. Then VFS should do
the right thing from the start unless overlayfs calls back into operations
on 'upper' that will try to acquire the freeze protection again. Thoughts?
Honza
--
Jan Kara
SUSE Labs, CR
On Mon 11-02-19 09:56:53, Matthew Wilcox wrote:
> On Mon, Feb 11, 2019 at 06:48:46PM +0100, Jan Kara wrote:
> > On Mon 11-02-19 13:59:24, Linux Upstream wrote:
> > > >
> > > >> Signed-off-by: Chintan Pandya
> > > >
> > > > NAK.
>
ed to
the xarray. So that one particular instance might benefit from atomic
SetPageLocked or a barrier somewhere between __SetPageLocked() and the
actual addition of entry into the xarray.
Honza
--
Jan Kara
SUSE Labs, CR
> + "readonly mount\n");
> + ret = -EACCES;
> + }
> + }
> out_bh:
> brelse(bh);
> return ret;
>
--
Jan Kara
SUSE Labs, CR
On Fri 08-02-19 12:50:37, Dan Williams wrote:
> On Fri, Feb 8, 2019 at 3:11 AM Jan Kara wrote:
> >
> > On Fri 08-02-19 15:43:02, Dave Chinner wrote:
> > > On Thu, Feb 07, 2019 at 04:55:37PM +, Christopher Lameter wrote:
> > > > One approach that may be
force read-only mount when
> no LVID is available.
Agreed. OSTA UDF standard requires LVID to be present so forcing read-only
mount is perfectly fine.
Honza
--
Jan Kara
SUSE Labs, CR
On Fri 08-02-19 10:55:07, Jan Kara wrote:
> On Thu 07-02-19 21:37:27, Andrew Morton wrote:
> > On Thu, 7 Feb 2019 11:27:50 +0100 Jan Kara wrote:
> >
> > > On Fri 01-02-19 09:19:04, Dave Chinner wrote:
> > > > Maybe for memcgs, but that's exactly the
immutable files but RDMA store would be effectively corrupting the data of
the target inode. But we could treat it similarly as swapfiles - those also
have to deal with writes to blocks beyond filesystem control. In fact the
similarity seems to be quite large there. What do you think?
Honza
--
Jan Kara
SUSE Labs, CR
On Thu 07-02-19 21:37:27, Andrew Morton wrote:
> On Thu, 7 Feb 2019 11:27:50 +0100 Jan Kara wrote:
>
> > On Fri 01-02-19 09:19:04, Dave Chinner wrote:
> > > Maybe for memcgs, but that's exactly the oppose of what we want to
> > > do for global caches (e.g. file
gt; Is an NV-DIMM the only thing we use DAX on?
Currently yes. However KVM people are soon going to use it for their
purposes as well (essentially directly sharing host page cache between
guests).
Honza
--
Jan Kara
SUSE Labs, CR
machines and storage, it will have a major impact.
Just as a data point, our performance testing infrastructure has bisected
down to the commits discussed in this thread as the cause of about 40%
regression in XFS file delete performance in bonnie++ benchmark.
normal conditions there should be a way to revoke the
access. And if the HW/driver cannot support this, then don't let it anywhere
near DAX filesystem.
Honza
--
Jan Kara
SUSE Labs, CR
but it seems you have those just not merged yet, right?
Honza
--
Jan Kara
SUSE Labs, CR
hat already in my tree. Thanks for letting me know and
sorry for the breakage.
Honza
--
Jan Kara
SUSE Labs, CR
g-term pins. But we haven't figured
out the details yet. For now we concentrate on fixing short-term pins and
issues with those.
Honza
--
Jan Kara
SUSE Labs, CR
to allocate for this branch.
>*/
> count = ext2_blks_to_allocate(partial, indirect_blks,
> --
> 1.9.1
>
>
--
Jan Kara
SUSE Labs, CR
On Mon 28-01-19 22:41:41, John Hubbard wrote:
> On 1/28/19 5:23 PM, Jerome Glisse wrote:
> > On Mon, Jan 28, 2019 at 04:22:16PM -0800, John Hubbard wrote:
> > > On 1/23/19 11:04 AM, Jerome Glisse wrote:
> > > > On Wed, Jan 23, 2019 at 07:02:30PM +0100, Jan Kara wrote
uct super_block *sb, struct
> inode *parent)
> best_desc = desc;
> }
> }
> - if (!best_desc)
> - return -1;
>
> return best_group;
> }
> --
> 1.9.1
>
>
--
Jan Kara
SUSE Labs, CR
mark_inode_dirty(inode);
> ext2_free_branches(inode, &nr, &nr+1, 2);
> }
> + /* fall through */
> case EXT2_DIND_BLOCK:
> nr = i_data[EXT2_TIND_BLOCK];
> if (nr) {
> --
> 2.19.2
>
>
--
Jan Kara
SUSE Labs, CR
ize);
> de->inode = 0;
> --
> 1.9.1
>
>
--
Jan Kara
SUSE Labs, CR
s.
>
> The linux-nvdimm mailing hosts a patchwork instance for both DAX and
> NVDIMM patches.
>
> Cc: Jan Kara
> Cc: Ira Weiny
> Cc: Ross Zwisler
> Cc: Keith Busch
> Cc: Matthew Wilcox
> Signed-off-by: Dan Williams
Acked-by: Jan Kara
On Thu 24-01-19 20:19:57, Greg Kroah-Hartman wrote:
> 4.4-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Jan Kara
>
> commit 967d1dc144b50ad005e5eecdfadfbcfb3996 upstream.
>
> __loop_release() has a sing
s not migratable at all).
I've sent Andrew a patch over week ago but so far it got ignored. The patch
is attached, can you give it a try whether it changes something for you?
Thanks!
Honza
--
Jan Kara
SUSE Labs, CR
>From 59ab3a8504c35e2215af6c251bdb2a8a1caca1dd Mon Sep 17
leak in inotify_add_watch().
The diffstat is
fs/notify/inotify/inotify_user.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
Thanks
Honza
--
Jan Kara
SUSE Labs
On Tue 22-01-19 11:46:13, Jerome Glisse wrote:
> On Tue, Jan 22, 2019 at 04:24:59PM +0100, Jan Kara wrote:
> > On Thu 17-01-19 10:17:59, Jerome Glisse wrote:
> > > On Thu, Jan 17, 2019 at 10:30:47AM +0100, Jan Kara wrote:
> > > > On Wed 16-01-19 08:08:14, Jerome Gliss
On Tue 22-01-19 16:27:53, Dmitry Vyukov wrote:
> On Mon, Jan 21, 2019 at 9:37 AM Jan Kara wrote:
> >
> > On Thu 17-01-19 14:18:56, Dmitry Vyukov wrote:
> > > On Wed, Jan 16, 2019 at 5:28 PM Greg Kroah-Hartman
> > > wrote:
> > > >
> > > >
On Thu 17-01-19 10:17:59, Jerome Glisse wrote:
> On Thu, Jan 17, 2019 at 10:30:47AM +0100, Jan Kara wrote:
> > On Wed 16-01-19 08:08:14, Jerome Glisse wrote:
> > > On Wed, Jan 16, 2019 at 12:38:19PM +0100, Jan Kara wrote:
> > > > On Tue 15-01-19 09:07:59, Jan Kara wr
Hello,
On Mon 14-01-19 11:30:11, Jan Kara wrote:
> On Mon 14-01-19 01:33:30, Kevin Weidemann wrote:
> > this is RE the patch 8515b9edf7a0c9dcf1ad218ccc783700db217336 (Upstream
> > commit a9ad01bc759df79b0012f43ee52164391e31cd96) in 4.18.20.
> >
> > I have an issue wit
0)
> - goto cantfind_ext2;
> sbi->s_inodes_per_block = sb->s_blocksize / EXT2_INODE_SIZE(sb);
> if (sbi->s_inodes_per_block == 0 || sbi->s_inodes_per_group == 0)
> goto cantfind_ext2;
> --
> 1.9.1
>
>
--
Jan Kara
SUSE Labs, CR
ense to me. I'd just copy a lot of the rationale from the
cover latter to this commit log so that it gets preseved in git history.
Other than that feel free to add:
Acked-by: Jan Kara
Honza
> ---
> kernel/ucount.c | 2
erflows such as rdma
> user input controlled from userspace.
>
> Signed-off-by: Davidlohr Bueso
The patch looks good to me. You can add:
Reviewed-by: Jan Kara
and I really like the cleanups allowed by this in the drivers :)
would regress.
Honza
>
> ----------
>
> From: Jan Kara
>
> commit 04906b2f542c23626b0ef6219b808406f8dddbe9 upstream.
>
> bd_set_size() updates also block device's block size. This is somew
On Wed 16-01-19 08:08:14, Jerome Glisse wrote:
> On Wed, Jan 16, 2019 at 12:38:19PM +0100, Jan Kara wrote:
> > On Tue 15-01-19 09:07:59, Jan Kara wrote:
> > > Agreed. So with page lock it would actually look like:
> > >
> > > get_page_pin()
> > >
On Wed 16-01-19 21:25:05, John Hubbard wrote:
> On 1/15/19 12:07 AM, Jan Kara wrote:
> >>>>> [...]
> >>> Also there is one more idea I had how to record number of pins in the
> >>> page:
> >>>
> >>> #define PAGE_PIN_BIAS
On Wed 16-01-19 13:37:22, Dmitry Vyukov wrote:
> On Wed, Jan 16, 2019 at 12:56 PM Jan Kara wrote:
> >
> > On Wed 16-01-19 12:03:27, Dmitry Vyukov wrote:
> > > On Wed, Jan 16, 2019 at 11:43 AM Jan Kara wrote:
> > > >
> > > > On Wed 16-01-19 10:47:5
On Tue 15-01-19 09:07:59, Jan Kara wrote:
> Agreed. So with page lock it would actually look like:
>
> get_page_pin()
> lock_page(page);
> wait_for_stable_page();
> atomic_add(&page->_refcount, PAGE_PIN_BIAS);
> unlock_page(page);
>
> And
on when forward
> porting the debugging patch from an older kernel.
>
> Fix the issue by dropping mem_hotplug_done from the failure condition
> and keeping the single unlock in the catch all failure path.
>
> Reported-by: Jan Kara
> Fixes: 7960509329c2 ("mm, memory_hotplug:
On Tue 15-01-19 11:50:41, Pali Rohár wrote:
> On Tuesday 15 January 2019 10:45:55 Jan Kara wrote:
> > On Tue 15-01-19 09:48:32, Pali Rohár wrote:
> > > On Tuesday 15 January 2019 09:41:19 Jan Kara wrote:
> > > > On Tue 15-01-19 09:31:11, Pali Rohár wrote:
> > &
On Tue 15-01-19 09:48:32, Pali Rohár wrote:
> On Tuesday 15 January 2019 09:41:19 Jan Kara wrote:
> > On Tue 15-01-19 09:31:11, Pali Rohár wrote:
> > > On Monday 14 January 2019 19:07:35 Michael Sabolish wrote:
> > > > I can try and make a pull-request for ud
On Mon 14-01-19 16:13:08, Dmitry Vyukov wrote:
> On Mon, Jan 14, 2019 at 4:11 PM Dmitry Vyukov wrote:
> >
> > On Wed, Jan 9, 2019 at 2:30 PM Jan Kara wrote:
> > >
> > > On Tue 08-01-19 12:49:08, Dmitry Vyukov wrote:
> > > > On Tue, Jan 8, 2019 at 12:
e.g.:
udftune -E access-type=
Another question about the feature is - the access type is actually per
partition and there can be multiple partitions on UDF media. So I think we
need to specify the partition number in the command and has to
actually be something like ,.
Honza
--
Jan Kara
SUSE Labs, CR
ed(page);
> +
> + unlock_page(page);
> +}
> +
> +/*
> + * A variant of track_gup_page() that returns -EBUSY, instead of waiting.
> + */
> +static int track_gup_page_atomic(struct page *page)
> +{
> + page = compound_head(page);
> +
> + if (PageWriteback(page) || !trylock_page(page))
> + return -EBUSY;
> +
> + if (PageWriteback(page)) {
> + unlock_page(page);
> + return -EBUSY;
> + }
Here you'd need some helper that would return whether
wait_for_stable_page() is going to wait. Like would_wait_for_stable_page()
but maybe you can come up with a better name.
> + atomic_inc(&page->_mapcount);
> + SetPageGupPinned(page);
> +
> + unlock_page(page);
> + return 0;
> +}
> +
Honza
--
Jan Kara
SUSE Labs, CR
On Mon 14-01-19 12:21:25, Jerome Glisse wrote:
> On Mon, Jan 14, 2019 at 03:54:47PM +0100, Jan Kara wrote:
> > On Fri 11-01-19 19:06:08, John Hubbard wrote:
> > > On 1/11/19 6:46 PM, Jerome Glisse wrote:
> > > > On Fri, Jan 11, 2019 at 06:38:
;
put_page_pin();
atomic_add(&page->_refcount, -PAGE_PIN_BIAS);
page_pinned(page)
(atomic_read(&page->_refcount) - page_mapcount(page)) > PAGE_PIN_BIAS
This is pretty trivial scheme. It still gives us 22-bits for page pins
which should be plenty (but we should check for that and bail with error if
it would overflow). Also there will be no false negatives and false
positives only if there are more than 1024 non-page-table references to the
page which I expect to be rare (we might want to also subtract
hpage_nr_pages() for radix tree references to avoid excessive false
positives for huge pages although at this point I don't think they would
matter). Thoughts?
Honza
--
Jan Kara
SUSE Labs, CR
269c8db30cf5b6 "ext2:
Set the write time in ext2_sync_fs()" in 2010. I'll fix it. Thanks for
report.
Honza
--
Jan Kara
SUSE Labs, CR
On Mon 14-01-19 13:00:23, Pali Rohár wrote:
> On Monday 14 January 2019 11:30:11 Jan Kara wrote:
> > > As for the case of remounting as rw if the UDF is ro but the device is
> > > rw, I am not sure what the best idea is to deal with this. If this new
> > > behavior
501 - 600 of 2887 matches
Mail list logo
