ct super_block *sb)
> */
> int thaw_super(struct super_block *sb)
> {
> + int error;
> +
> down_write(>s_umount);
> - return thaw_super_locked(sb);
> + error = thaw_super_locked(sb);
> + if (error) {
> + up_write(>s_umount);
> + goto out;
> + }
> +
> + deactivate_locked_super(sb);
> +
> +out:
> + return error;
> }
> EXPORT_SYMBOL(thaw_super);
> --
> 2.16.3
>
--
Jan Kara
SUSE Labs, CR
t; superblock with bd_fsfreeze_count always positive.
>
> Fixes: fcccf502540e3 ("filesystem freeze: implement generic freeze feature")
> Signed-off-by: Luis R. Rodriguez <mcg...@kernel.org>
Looks good to me. You can add:
Reviewed-by: Jan Kara <j...@suse.cz>
t; superblock with bd_fsfreeze_count always positive.
>
> Fixes: fcccf502540e3 ("filesystem freeze: implement generic freeze feature")
> Signed-off-by: Luis R. Rodriguez
Looks good to me. You can add:
Reviewed-by: Jan Kara
lt;mcg...@kernel.org>
Looks good (modulo the -- which is probably worth fixing when touching the
comment anyway). You can add:
Reviewed-by: Jan Kara <j...@suse.cz>
Honza
> ---
> fs/super.c | 12 ++--
>
guez
Looks good (modulo the -- which is probably worth fixing when touching the
comment anyway). You can add:
Reviewed-by: Jan Kara
Honza
> ---
> fs/super.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
On Sun 22-04-18 19:25:05, Matthew Wilcox wrote:
> On Mon, Apr 23, 2018 at 01:09:48AM +0200, Jan Kara wrote:
> > > -int vm_insert_mixed_mkwrite(struct vm_area_struct *vma, unsigned long
> > > addr,
> > > - pfn_t pfn)
> > > +vm_fault_t vmf_ins
On Sun 22-04-18 19:25:05, Matthew Wilcox wrote:
> On Mon, Apr 23, 2018 at 01:09:48AM +0200, Jan Kara wrote:
> > > -int vm_insert_mixed_mkwrite(struct vm_area_struct *vma, unsigned long
> > > addr,
> > > - pfn_t pfn)
> > > +vm_fault_t vmf_ins
llers of this function (and also of
vmf_insert_mixed()) are OK with EBUSY? Because especially in the
vmf_insert_mixed() case other page than the caller provided is in page
tables and thus possibly the caller needs to do some error recovery (such
as drop page refcount) in such case...
Honza
--
Jan Kara <j...@suse.com>
SUSE Labs, CR
o of
vmf_insert_mixed()) are OK with EBUSY? Because especially in the
vmf_insert_mixed() case other page than the caller provided is in page
tables and thus possibly the caller needs to do some error recovery (such
as drop page refcount) in such case...
Honza
--
Jan Kara
SUSE Labs, CR
On Fri 20-04-18 11:49:32, Luis R. Rodriguez wrote:
> On Tue, Apr 17, 2018 at 05:59:36PM -0700, Luis R. Rodriguez wrote:
> > On Thu, Dec 21, 2017 at 12:03:29PM +0100, Jan Kara wrote:
> > > Hello,
> > >
> > > I think I owe you a reply here... Sorry that it
On Fri 20-04-18 11:49:32, Luis R. Rodriguez wrote:
> On Tue, Apr 17, 2018 at 05:59:36PM -0700, Luis R. Rodriguez wrote:
> > On Thu, Dec 21, 2017 at 12:03:29PM +0100, Jan Kara wrote:
> > > Hello,
> > >
> > > I think I owe you a reply here... Sorry that it
ode under CONFIG_CGROUP_WRITEBACK. So
you can add:
Reviewed-by: Jan Kara <j...@suse.cz>
Honza
> ---
> include/linux/memcontrol.h | 1 -
> mm/backing-dev.c | 4 ++--
> mm/memcontrol.c| 5 -
>
So
you can add:
Reviewed-by: Jan Kara
Honza
> ---
> include/linux/memcontrol.h | 1 -
> mm/backing-dev.c | 4 ++--
> mm/memcontrol.c| 5 -
> 3 files changed, 2 insertions(+), 8 deletions(
nal == NULL && !(old_sb_flags & SB_RDONLY)) {
> + err = ext4_commit_super(sb, 1);
> + goto restore_opts;
> + }
Why is goto restore_opts unconditional here?
Honza
--
Jan Kara <j...@suse.com>
SUSE Labs, CR
{
> + err = ext4_commit_super(sb, 1);
> + goto restore_opts;
> + }
Why is goto restore_opts unconditional here?
Honza
--
Jan Kara
SUSE Labs, CR
On Thu 19-04-18 21:37:25, Dexuan Cui wrote:
> > From: Jan Kara
> > Sent: Thursday, April 19, 2018 13:23
> > Good news guys, Robert has just spotted a bug which looks like what I'd
> > expect can cause your lockups / crashes. I've merged his patch to my tree
> > and
On Thu 19-04-18 21:37:25, Dexuan Cui wrote:
> > From: Jan Kara
> > Sent: Thursday, April 19, 2018 13:23
> > Good news guys, Robert has just spotted a bug which looks like what I'd
> > expect can cause your lockups / crashes. I've merged his patch to my tree
> > and
On Wed 18-04-18 10:32:21, Pavlos Parissis wrote:
> On 17/04/2018 02:12 μμ, Jan Kara wrote:
> > On Tue 17-04-18 01:31:24, Pavlos Parissis wrote:
> >> On 16/04/2018 04:40 μμ, Jan Kara wrote:
> >
> >
> >
> >>> How easily can you hit this?
>
On Wed 18-04-18 10:32:21, Pavlos Parissis wrote:
> On 17/04/2018 02:12 μμ, Jan Kara wrote:
> > On Tue 17-04-18 01:31:24, Pavlos Parissis wrote:
> >> On 16/04/2018 04:40 μμ, Jan Kara wrote:
> >
> >
> >
> >>> How easily can you hit this?
>
On Thu 19-04-18 12:44:56, Theodore Y. Ts'o wrote:
> On Thu, Apr 19, 2018 at 04:50:28PM +0200, Jan Kara wrote:
> > On Mon 19-03-18 16:34:09, zhenwei.pi wrote:
> > > "mark_unwritten" in comment and "unwritten" in variable
> > > argument lists is m
On Thu 19-04-18 12:44:56, Theodore Y. Ts'o wrote:
> On Thu, Apr 19, 2018 at 04:50:28PM +0200, Jan Kara wrote:
> > On Mon 19-03-18 16:34:09, zhenwei.pi wrote:
> > > "mark_unwritten" in comment and "unwritten" in variable
> > > argument lists is m
: ff72 RSI: 20003c00 RDI: 0018
> RBP: 0072bea0 R08: R09:
> R10: R11: 00000246 R12:
> R13: 046d R14: 006f8ad8 R15:
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 86400 seconds..
--
Jan Kara <j...@suse.com>
SUSE Labs, CR
: ff72 RSI: 20003c00 RDI: 0018
> RBP: 0072bea0 R08: R09:
> R10: R11: 00000246 R12:
> R13: 046d R14: 006f8ad8 R15:
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 86400 seconds..
--
Jan Kara
SUSE Labs, CR
> clear_buffer_write_io_error(sbh);
I'd rather rewrite this as:
if (buffer_write_io_error(sbh)) {
do stuff as now
}
if (error)
return error;
Honza
--
Jan Kara <j...@suse.com>
SUSE Labs, CR
RR, "I/O error while writing "
> "superblock");
> clear_buffer_write_io_error(sbh);
I'd rather rewrite this as:
if (buffer_write_io_error(sbh)) {
do stuff as now
}
if (error)
return error;
Honza
--
Jan Kara
SUSE Labs, CR
ap
> - * @mark_unwritten: Mark second inode's extents as unwritten after swap
> + * @unwritten: Mark second inode's extents as unwritten after swap
> * @erp: Pointer to save error value
> *
> * This helper routine does exactly what is promise "swap extents". All other
> --
> 2.7.4
>
--
Jan Kara <j...@suse.com>
SUSE Labs, CR
Mark second inode's extents as unwritten after swap
> + * @unwritten: Mark second inode's extents as unwritten after swap
> * @erp: Pointer to save error value
> *
> * This helper routine does exactly what is promise "swap extents". All other
> --
> 2.7.4
>
--
Jan Kara
SUSE Labs, CR
uff
> has in the past, so you had better also be reviewing all of my normal
> commits as well :)
>
> Anyway, we are trying not to do this, but it does, and will,
> occasionally happen.
Sure, that's understood. So this was just misunderstanding. Sasha's
original comment really sounded like "bug compatibility" with current
master is desirable and that made me go "Are you serious?" as well...
Honza
--
Jan Kara <j...@suse.com>
SUSE Labs, CR
t; has in the past, so you had better also be reviewing all of my normal
> commits as well :)
>
> Anyway, we are trying not to do this, but it does, and will,
> occasionally happen.
Sure, that's understood. So this was just misunderstanding. Sasha's
original comment really sounded like "bug compatibility" with current
master is desirable and that made me go "Are you serious?" as well...
Honza
--
Jan Kara
SUSE Labs, CR
On Fri 13-04-18 15:03:51, Dan Williams wrote:
> On Mon, Apr 9, 2018 at 9:51 AM, Dan Williams <dan.j.willi...@intel.com> wrote:
> > On Mon, Apr 9, 2018 at 9:49 AM, Jan Kara <j...@suse.cz> wrote:
> >> On Sat 07-04-18 12:38:24, Dan Williams wrote:
> > [..]
>
On Fri 13-04-18 15:03:51, Dan Williams wrote:
> On Mon, Apr 9, 2018 at 9:51 AM, Dan Williams wrote:
> > On Mon, Apr 9, 2018 at 9:49 AM, Jan Kara wrote:
> >> On Sat 07-04-18 12:38:24, Dan Williams wrote:
> > [..]
> >>> I wonder if this can be trivially
ng as lookup
> index. Usualy those flag are seldomly changed/accessed. Again the
> overhead (ignoring code size) would only be for page which are KSM.
> So maybe KSM will not make sense because perf overhead it has with
> page->flags access (i don't think so but i haven't tested this).
Yeah, sure, page->flags could be dealt with in a similar way but at this
point I don't think it's worth it. And without page->flags I don't think
abstracting page->private makes much sense - or am I missing something why
you need page->private depend on the mapping? So what I wanted to suggest
is that we leave page->private as is currently and just concentrate on
page->mapping hacks...
Honza
--
Jan Kara <j...@suse.com>
SUSE Labs, CR
ng as lookup
> index. Usualy those flag are seldomly changed/accessed. Again the
> overhead (ignoring code size) would only be for page which are KSM.
> So maybe KSM will not make sense because perf overhead it has with
> page->flags access (i don't think so but i haven't tested this).
Yeah, sure, page->flags could be dealt with in a similar way but at this
point I don't think it's worth it. And without page->flags I don't think
abstracting page->private makes much sense - or am I missing something why
you need page->private depend on the mapping? So what I wanted to suggest
is that we leave page->private as is currently and just concentrate on
page->mapping hacks...
Honza
--
Jan Kara
SUSE Labs, CR
ned long offset;
> unsigned long private;
> ...
> };
Auch, the fact that we could share a page as data storage for several
inode+offset combinations that are not sharing underlying storage just
looks viciously twisted ;) But is it really that useful to warrant
complications? In particular I'm afraid that filesystems expect consistency
between their internal state (attached to page->private) and page state
(e.g. page->flags) and when there are multiple internal states attached to
the same page this could go easily wrong...
Honza
--
Jan Kara <j...@suse.com>
SUSE Labs, CR
unsigned long private;
> ...
> };
Auch, the fact that we could share a page as data storage for several
inode+offset combinations that are not sharing underlying storage just
looks viciously twisted ;) But is it really that useful to warrant
complications? In particular I'm afraid that filesystems expect consistency
between their internal state (attached to page->private) and page state
(e.g. page->flags) and when there are multiple internal states attached to
the same page this could go easily wrong...
Honza
--
Jan Kara
SUSE Labs, CR
On Tue 17-04-18 17:59:36, Luis R. Rodriguez wrote:
> On Thu, Dec 21, 2017 at 12:03:29PM +0100, Jan Kara wrote:
> > On Fri 01-12-17 22:13:27, Luis R. Rodriguez wrote:
> > >
> > > I'll note that its still not perfectly clear if really the semantics
> > > beh
On Tue 17-04-18 17:59:36, Luis R. Rodriguez wrote:
> On Thu, Dec 21, 2017 at 12:03:29PM +0100, Jan Kara wrote:
> > On Fri 01-12-17 22:13:27, Luis R. Rodriguez wrote:
> > >
> > > I'll note that its still not perfectly clear if really the semantics
> > > beh
ting
memory and fsnotify is just a victim, or something like that...
Honza
--
Jan Kara <j...@suse.com>
SUSE Labs, CR
ting
memory and fsnotify is just a victim, or something like that...
Honza
--
Jan Kara
SUSE Labs, CR
On Tue 17-04-18 16:19:35, Sasha Levin wrote:
> On Tue, Apr 17, 2018 at 05:55:49PM +0200, Jan Kara wrote:
> >> Even regression chance is tricky, look at the commits I've linked
> >> earlier in the thread. Even the most trivial looking commits that end up
> >> in stabl
On Tue 17-04-18 16:19:35, Sasha Levin wrote:
> On Tue, Apr 17, 2018 at 05:55:49PM +0200, Jan Kara wrote:
> >> Even regression chance is tricky, look at the commits I've linked
> >> earlier in the thread. Even the most trivial looking commits that end up
> >> in stabl
On Tue 17-04-18 16:15:07, Pavlos Parissis wrote:
> On 17/04/2018 04:02 μμ, Jan Kara wrote:
> > On Tue 17-04-18 12:39:32, Pavlos Parissis wrote:
> >> In one of our production servers where we run kernel version 4.14.32, I
> >> noticed
> >> the f
On Tue 17-04-18 16:15:07, Pavlos Parissis wrote:
> On 17/04/2018 04:02 μμ, Jan Kara wrote:
> > On Tue 17-04-18 12:39:32, Pavlos Parissis wrote:
> >> In one of our production servers where we run kernel version 4.14.32, I
> >> noticed
> >> the f
On Tue 17-04-18 13:31:51, Sasha Levin wrote:
> On Tue, Apr 17, 2018 at 01:41:44PM +0200, Jan Kara wrote:
> >On Mon 16-04-18 17:23:30, Sasha Levin wrote:
> >> On Mon, Apr 16, 2018 at 07:06:04PM +0200, Pavel Machek wrote:
> >> >On Mon 2018-04-16 16:37:56, Sasha Levin
On Tue 17-04-18 13:31:51, Sasha Levin wrote:
> On Tue, Apr 17, 2018 at 01:41:44PM +0200, Jan Kara wrote:
> >On Mon 16-04-18 17:23:30, Sasha Levin wrote:
> >> On Mon, Apr 16, 2018 at 07:06:04PM +0200, Pavel Machek wrote:
> >> >On Mon 2018-04-16 16:37:56, Sasha Levin
there is no mark
> attached") arrived with 4.12-rc1 may be the cause of it.
>
> I am wondering if it is related to the issue I reported
> https://lkml.org/lkml/2018/4/16/506. But, that issue causes the whole server
> to
> crash, which is not the case for above kernel dump.
>
>
> Cheers,
> Pavlos
>
--
Jan Kara <j...@suse.com>
SUSE Labs, CR
there is no mark
> attached") arrived with 4.12-rc1 may be the cause of it.
>
> I am wondering if it is related to the issue I reported
> https://lkml.org/lkml/2018/4/16/506. But, that issue causes the whole server
> to
> crash, which is not the case for above kernel dump.
>
>
> Cheers,
> Pavlos
>
--
Jan Kara
SUSE Labs, CR
ub.com/torvalds/linux/blob/master/fs/notify/mark.c#L160
> and commit
> 08991e83b728 ("fsnotify: Free fsnotify_mark_connector when there is no mark
> attached") arrived with 4.12-rc1 may be the cause of it.
>
> I am wondering if it is related to the issue I reported
> https://lkml.org/lkml/2018/4/16/506. But, that issue causes the whole server
> to
> crash, which is not the case for above kernel dump.
>
>
> Cheers,
> Pavlos
>
--
Jan Kara <j...@suse.com>
SUSE Labs, CR
ub.com/torvalds/linux/blob/master/fs/notify/mark.c#L160
> and commit
> 08991e83b728 ("fsnotify: Free fsnotify_mark_connector when there is no mark
> attached") arrived with 4.12-rc1 may be the cause of it.
>
> I am wondering if it is related to the issue I reported
> https://lkml.org/lkml/2018/4/16/506. But, that issue causes the whole server
> to
> crash, which is not the case for above kernel dump.
>
>
> Cheers,
> Pavlos
>
--
Jan Kara
SUSE Labs, CR
On Tue 17-04-18 01:31:24, Pavlos Parissis wrote:
> On 16/04/2018 04:40 μμ, Jan Kara wrote:
> > How easily can you hit this?
>
> Very easily, I only need to wait 1-2 days for a crash to occur.
I wouldn't call that very easily but opinions may differ :). Anyway it's
good (at leas
On Tue 17-04-18 01:31:24, Pavlos Parissis wrote:
> On 16/04/2018 04:40 μμ, Jan Kara wrote:
> > How easily can you hit this?
>
> Very easily, I only need to wait 1-2 days for a crash to occur.
I wouldn't call that very easily but opinions may differ :). Anyway it's
good (at leas
On Tue 17-04-18 13:18:46, Pavlos Parissis wrote:
> On 17/04/2018 01:31 πμ, Pavlos Parissis wrote:
> > On 16/04/2018 04:40 μμ, Jan Kara wrote:
> >> On Mon 16-04-18 15:25:50, Guillaume Morin wrote:
> >>> Fwiw, there have been already reports of similar soft lockups in
&
On Tue 17-04-18 13:18:46, Pavlos Parissis wrote:
> On 17/04/2018 01:31 πμ, Pavlos Parissis wrote:
> > On 16/04/2018 04:40 μμ, Jan Kara wrote:
> >> On Mon 16-04-18 15:25:50, Guillaume Morin wrote:
> >>> Fwiw, there have been already reports of similar soft lockups in
&
On Tue 17-04-18 14:48:35, Amir Goldstein wrote:
> On Tue, Apr 17, 2018 at 1:33 PM, Greg KH <g...@kroah.com> wrote:
> > On Mon, Apr 16, 2018 at 09:10:35PM +, Dexuan Cui wrote:
> >> > From: Jan Kara <j...@suse.cz>
> >> > Sent: Monday, April 16, 2018 0
On Tue 17-04-18 14:48:35, Amir Goldstein wrote:
> On Tue, Apr 17, 2018 at 1:33 PM, Greg KH wrote:
> > On Mon, Apr 16, 2018 at 09:10:35PM +, Dexuan Cui wrote:
> >> > From: Jan Kara
> >> > Sent: Monday, April 16, 2018 07:41
> >> > ...
> >&
make is that if chance a patch causes a
regression is about 2% as you said somewhere else in a thread, then by
adding 20 patches that "may fix a bug that is annoying for someone" you've
just increased a chance there's a regression in the release by 34%. And
this is not just a math game, this also roughly matches a real experience
with maintaining our enterprise kernels. Do 20 "maybe" fixes outweight such
regression chance? And I also note that for a regression to get reported so
that it gets included into your 2% estimate of a patch regression rate,
someone must be bothered enough by it to triage it and send an email
somewhere so that already falls into a category of "serious" stuff to me.
So these are the reasons why I think that merging tons of patches into
stable isn't actually very good.
Honza
--
Jan Kara <j...@suse.com>
SUSE Labs, CR
regression is about 2% as you said somewhere else in a thread, then by
adding 20 patches that "may fix a bug that is annoying for someone" you've
just increased a chance there's a regression in the release by 34%. And
this is not just a math game, this also roughly matches a real experience
with maintaining our enterprise kernels. Do 20 "maybe" fixes outweight such
regression chance? And I also note that for a regression to get reported so
that it gets included into your 2% estimate of a patch regression rate,
someone must be bothered enough by it to triage it and send an email
somewhere so that already falls into a category of "serious" stuff to me.
So these are the reasons why I think that merging tons of patches into
stable isn't actually very good.
Honza
--
Jan Kara
SUSE Labs, CR
:
> >
> > [373782.772722] DR3: DR6: fffe0ff0 DR7:
> > 0400
> > [373782.790043] Call Trace:
> > [373782.802041] vfs_write+0x151/0x1b0
> > [373782.815081] ? syscall_trace_enter+0x1cd/0x2b0
> > [373782.82
:
> >
> > [373782.772722] DR3: DR6: fffe0ff0 DR7:
> > 0400
> > [373782.790043] Call Trace:
> > [373782.802041] vfs_write+0x151/0x1b0
> > [373782.815081] ? syscall_trace_enter+0x1cd/0x2b0
> > [373782.82
case Opt_iocharset:
> + kfree(popt->iocharset);
> popt->iocharset = match_strdup([0]);
> + if (!popt->iocharset)
> + return 0;
> break;
> #endif
> case Opt_map_a:
> --
> 1.8.3.1
>
--
Jan Kara <j...@suse.com>
SUSE Labs, CR
Opt_iocharset:
> + kfree(popt->iocharset);
> popt->iocharset = match_strdup([0]);
> + if (!popt->iocharset)
> + return 0;
> break;
> #endif
> case Opt_map_a:
> --
> 1.8.3.1
>
--
Jan Kara
SUSE Labs, CR
ge);
> + return -ENOMEM;
> + }
> pages[full_page] = page;
>
> for (i = 0; i < pcount; i++, index++) {
> @@ -357,6 +369,7 @@ static int zisofs_readpage(struct file *file, struct page
> *page)
> }
>
> /* At this point, err contains 0 or -EIO depending on the "critical"
> page */
> + kfree(pages);
> return err;
> }
>
> --
> 2.17.0.484.g0c8726318c-goog
>
--
Jan Kara <j...@suse.com>
SUSE Labs, CR
MEM;
> + }
> pages[full_page] = page;
>
> for (i = 0; i < pcount; i++, index++) {
> @@ -357,6 +369,7 @@ static int zisofs_readpage(struct file *file, struct page
> *page)
> }
>
> /* At this point, err contains 0 or -EIO depending on the "critical"
> page */
> + kfree(pages);
> return err;
> }
>
> --
> 2.17.0.484.g0c8726318c-goog
>
--
Jan Kara
SUSE Labs, CR
lier in the callchain.
>
> Fixes: 19f99cee206c ("f2fs: add core inode operations")
> Reported-by: Minchan Kim <minc...@kernel.org>
> Signed-off-by: Matthew Wilcox <mawil...@microsoft.com>
> Cc: sta...@vger.kernel.or
; Fixes: 19f99cee206c ("f2fs: add core inode operations")
> Reported-by: Minchan Kim
> Signed-off-by: Matthew Wilcox
> Cc: sta...@vger.kernel.org
Looks good to me. You can add:
Reviewed-by: Jan Kara
Honza
>
sofs_pages_per_cblock, 1),
> + sizeof(*pages), GFP_KERNEL);
> + if (!pages)
> + return -ENOMEM;
And this is wrong as well. You need to do:
if (!pages) {
unlock_page(page);
return -ENOMEM;
}
Honza
--
Jan Kara <j...@suse.com>
SUSE Labs, CR
1),
> + sizeof(*pages), GFP_KERNEL);
> + if (!pages)
> + return -ENOMEM;
And this is wrong as well. You need to do:
if (!pages) {
unlock_page(page);
return -ENOMEM;
}
Honza
--
Jan Kara
SUSE Labs, CR
On Tue 10-04-18 11:32:41, Michal Hocko wrote:
> On Tue 10-04-18 10:55:31, Jan Kara wrote:
> > On Tue 10-04-18 10:22:43, Michal Hocko wrote:
> > > On Mon 09-04-18 10:58:15, Minchan Kim wrote:
> > > > Recently, I got a report like below.
> > > >
> >
On Tue 10-04-18 11:32:41, Michal Hocko wrote:
> On Tue 10-04-18 10:55:31, Jan Kara wrote:
> > On Tue 10-04-18 10:22:43, Michal Hocko wrote:
> > > On Mon 09-04-18 10:58:15, Minchan Kim wrote:
> > > > Recently, I got a report like below.
> > > >
> >
some FS or subsystem pass
> > gfp_mask to __GFP_ZERO, slub allocator will do memset blindly.
> > That means allocated node can have !list_empty(node->private_list).
> > It ends up calling NULL deference at workingset_update_node by
> > failing list_empty check.
> >
> > This
some FS or subsystem pass
> > gfp_mask to __GFP_ZERO, slub allocator will do memset blindly.
> > That means allocated node can have !list_empty(node->private_list).
> > It ends up calling NULL deference at workingset_update_node by
> > failing list_empty check.
> >
> > This
in
workingset_update_node() will dereference NULL.
Fix the problem by removing __GFP_ZERO from the mask for radix tree
allocations. Also warn if __GFP_ZERO gets passed to __radix_tree_preload()
to avoid silent breakage in the future for other radix tree users.
With that fixed you can add:
Revie
e() will dereference NULL.
Fix the problem by removing __GFP_ZERO from the mask for radix tree
allocations. Also warn if __GFP_ZERO gets passed to __radix_tree_preload()
to avoid silent breakage in the future for other radix tree users.
With that fixed you can add:
Reviewed-by: Jan Kara
On Sat 07-04-18 12:38:24, Dan Williams wrote:
> [ adding Paul and Josh ]
>
> On Wed, Apr 4, 2018 at 2:46 AM, Jan Kara <j...@suse.cz> wrote:
> > On Fri 30-03-18 21:03:30, Dan Williams wrote:
> >> Background:
> >>
> >> get_user_pages() in the filesyst
On Sat 07-04-18 12:38:24, Dan Williams wrote:
> [ adding Paul and Josh ]
>
> On Wed, Apr 4, 2018 at 2:46 AM, Jan Kara wrote:
> > On Fri 30-03-18 21:03:30, Dan Williams wrote:
> >> Background:
> >>
> >> get_user_pages() in the filesystem pins file back
On Sat 07-04-18 20:11:13, Paul E. McKenney wrote:
> On Sat, Apr 07, 2018 at 12:38:24PM -0700, Dan Williams wrote:
> > [ adding Paul and Josh ]
> >
> > On Wed, Apr 4, 2018 at 2:46 AM, Jan Kara <j...@suse.cz> wrote:
> > > On Fri 30-03-18 21:03:30, D
On Sat 07-04-18 20:11:13, Paul E. McKenney wrote:
> On Sat, Apr 07, 2018 at 12:38:24PM -0700, Dan Williams wrote:
> > [ adding Paul and Josh ]
> >
> > On Wed, Apr 4, 2018 at 2:46 AM, Jan Kara wrote:
> > > On Fri 30-03-18 21:03:30, Dan Wil
; ---
> include/linux/backing-dev.h | 1 +
> 1 file changed, 1 insertion(+)
Yeah, the patch looks good. You can add:
Reviewed-by: Jan Kara <j...@suse.cz>
Honza
>
> diff --git a/include/linux/backing-dev.h b
acking-dev.h | 1 +
> 1 file changed, 1 insertion(+)
Yeah, the patch looks good. You can add:
Reviewed-by: Jan Kara
Honza
>
> diff --git a/include/linux/backing-dev.h b/include/linux/backing-dev.h
> index 3e4ce54d
pages(GFP_ATOMIC, order);
> + dquot_hash = (struct hlist_head *)__get_free_pages(GFP_KERNEL, order);
> if (!dquot_hash)
> panic("Cannot create dquot hash table");
>
> --
> 1.9.1
>
>
--
Jan Kara <j...@suse.com>
SUSE Labs, CR
;
> + dquot_hash = (struct hlist_head *)__get_free_pages(GFP_KERNEL, order);
> if (!dquot_hash)
> panic("Cannot create dquot hash table");
>
> --
> 1.9.1
>
>
--
Jan Kara
SUSE Labs, CR
> Cc: Mike Marshall <hub...@omnibond.com>
> Fixes: a5135eeab2e5 ("orangefs: implement vm_ops->fault")
> Signed-off-by: Arnd Bergmann <a...@arndb.de>
OK, makes sense. You can add:
Reviewed-by: Jan Kara <j...@suse.cz>
Fixes: a5135eeab2e5 ("orangefs: implement vm_ops->fault")
> Signed-off-by: Arnd Bergmann
OK, makes sense. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> mm/filemap.c | 6 +-
> 1 file changed, 5 insertio
On Mon 09-04-18 16:25:17, Jan Kara wrote:
> On Wed 04-04-18 21:48:53, Jeff Mahoney wrote:
> > On 4/4/18 9:45 PM, Andrew Morton wrote:
> > > On Wed, 4 Apr 2018 18:25:16 -0700 Randy Dunlap <rdun...@infradead.org>
> > > wrote:
> > >
> &
On Mon 09-04-18 16:25:17, Jan Kara wrote:
> On Wed 04-04-18 21:48:53, Jeff Mahoney wrote:
> > On 4/4/18 9:45 PM, Andrew Morton wrote:
> > > On Wed, 4 Apr 2018 18:25:16 -0700 Randy Dunlap
> > > wrote:
> > >
> > >> From: Randy Dunlap
> >
gt; > Isn't the bug in journal_init_dev()?
>
> Yep. That's exactly it.
>
> Acked-by: Jeff Mahoney <je...@suse.com>
Thanks. I've picked up the patch from Andrew, added his Signed-off-by (OK,
Andrew?), wrote a proper changelog and pushed it to my tree. The result is
attached.
; Yep. That's exactly it.
>
> Acked-by: Jeff Mahoney
Thanks. I've picked up the patch from Andrew, added his Signed-off-by (OK,
Andrew?), wrote a proper changelog and pushed it to my tree. The result is
attached.
Honza
--
Jan
Hi,
On Wed 04-04-18 13:56:53, Steven Whitehouse wrote:
> On 04/04/18 13:36, Jan Kara wrote:
> > Hi,
> >
> > On Wed 04-04-18 10:24:48, Steven Whitehouse wrote:
> > > On 03/04/18 13:05, Jan Kara wrote:
> > > > Hello,
> > > >
> > >
Hi,
On Wed 04-04-18 13:56:53, Steven Whitehouse wrote:
> On 04/04/18 13:36, Jan Kara wrote:
> > Hi,
> >
> > On Wed 04-04-18 10:24:48, Steven Whitehouse wrote:
> > > On 03/04/18 13:05, Jan Kara wrote:
> > > > Hello,
> > > >
> > >
Hi,
On Wed 04-04-18 10:24:48, Steven Whitehouse wrote:
> On 03/04/18 13:05, Jan Kara wrote:
> > Hello,
> >
> > On Sun 01-04-18 10:01:02, syzbot wrote:
> > > syzbot hit the following crash on upstream commit
> > > 10b84daddbec72c6b440216a69de9a960
Hi,
On Wed 04-04-18 10:24:48, Steven Whitehouse wrote:
> On 03/04/18 13:05, Jan Kara wrote:
> > Hello,
> >
> > On Sun 01-04-18 10:01:02, syzbot wrote:
> > > syzbot hit the following crash on upstream commit
> > > 10b84daddbec72c6b440216a69de9a960
On Wed 04-04-18 11:46:56, Jan Kara wrote:
> On Fri 30-03-18 21:03:30, Dan Williams wrote:
> > Background:
> >
> > get_user_pages() in the filesystem pins file backed memory pages for
> > access by devices performing dma. However, it only pins the memory pages
>
On Wed 04-04-18 11:46:56, Jan Kara wrote:
> On Fri 30-03-18 21:03:30, Dan Williams wrote:
> > Background:
> >
> > get_user_pages() in the filesystem pins file backed memory pages for
> > access by devices performing dma. However, it only pins the memory pages
>
pages involved
> in an I/O may cause faults that need to take XFS_MMAPLOCK_EXCL.
>
> Cc: Jan Kara <j...@suse.cz>
> Cc: Dave Chinner <da...@fromorbit.com>
> Cc: "Darrick J. Wong" <darrick.w...@oracle.com>
> Cc: Ross Zwisler <ross.zwis...@lin
pages involved
> in an I/O may cause faults that need to take XFS_MMAPLOCK_EXCL.
>
> Cc: Jan Kara
> Cc: Dave Chinner
> Cc: "Darrick J. Wong"
> Cc: Ross Zwisler
> Reviewed-by: Christoph Hellwig
> Signed-off-by: Dan Williams
...
> ---
> fs/xfs/xf
ach assumes that the page
> pinning is transient, if that assumption is violated the system would
> have likely hung from the uncompleted I/O.
>
> Cc: Jan Kara <j...@suse.cz>
> Cc: Jeff Moyer <jmo...@redhat.com>
> Cc: Dave Chinner <da...@fromorbit.com>
> Cc: Matthe
ach assumes that the page
> pinning is transient, if that assumption is violated the system would
> have likely hung from the uncompleted I/O.
>
> Cc: Jan Kara
> Cc: Jeff Moyer
> Cc: Dave Chinner
> Cc: Matthew Wilcox
> Cc: Alexander Viro
> Cc: "Darrick J. Wong"
2 ORIG_RAX: 00e7
> RAX: ffda RBX: RCX: 00456c29
> RDX: 004170e0 RSI: RDI: 0001
> RBP: 0003 R08: 000a R09: 00418100
> R10: 0000200a9300 R11: 0202 R12: 0004
> R13: 00418100 R14: R15:
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 86400 seconds..
Honza
--
Jan Kara <j...@suse.com>
SUSE Labs, CR
2 ORIG_RAX: 00e7
> RAX: ffda RBX: RCX: 00456c29
> RDX: 004170e0 RSI: RDI: 0001
> RBP: 0003 R08: 000a R09: 00418100
> R10: 0000200a9300 R11: 0202 R12: 0004
> R13: 00418100 R14: R15:
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 86400 seconds..
Honza
--
Jan Kara
SUSE Labs, CR
che assumptions and warnings.
>
> Cc: Jan Kara <j...@suse.com>
> Reported-by: kbuild test robot <l...@intel.com>
> Signed-off-by: Dan Williams <dan.j.willi...@intel.com>
Looks good. You can add:
Reviewed-by: Jan Kara <j...@suse.cz>
901 - 1000 of 6478 matches
Mail list logo
