_len) {
> + /* Ran off the end of the bitmap,
> + * and bits following are non-compliant (not all zero)
> + */
> + goto error_return;
> + }
> +
> if (!udf_clear_bit(bit, bh->b_data)) {
> udf_debug("bit already cleared for block %d\n", bit);
> goto repeat;
>
--
Jan Kara
SUSE Labs, CR
hus, the check of bh on line 3447 is unnecessary and can be removed.
> Thank Andrew Morton for good advice.
>
> Signed-off-by: Jia-Ju Bai
Looks good to me. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> fs/reiserfs/jou
ixes: b48c104d2211 ("writeback: trace event bdi_dirty_ratelimit")
> Fixes: cc1676d917f3 ("writeback: Move requeueing when I_SYNC set to
> writeback_sb_inodes()")
> Fixes: 9fb0a7da0c52 ("writeback: add more tracepoints")
> Signed-off-by: Qian Cai
Looks
dm->dqb_itime = 0;
> clear_bit(DQ_INODES_B, >dq_flags);
> } else if (!(di->d_fieldmask & QC_INO_TIMER))
> --
> 2.20.1
>
>
>
>
--
Jan Kara
SUSE Labs, CR
On Tue 30-07-19 17:57:18, Konstantin Khlebnikov wrote:
> On 30.07.2019 17:14, Jan Kara wrote:
> > On Tue 23-07-19 11:16:51, Konstantin Khlebnikov wrote:
> > > On 23.07.2019 3:52, Andrew Morton wrote:
> > > >
> > > > (cc linux-fsdevel and Jan)
> >
&
arting writeback.
>
> Special case set_page_writeback_keepwrite() which does not clear to-write
> should be for dirty page thus dirty tag is not going to be cleared either.
> Ext4 calls it after redirty_page_for_writepage()
> XFS even without clear_page_dirty_for_io()
>
> Anywa
On Tue 16-07-19 20:39:46, Dan Williams wrote:
> On Fri, Jul 12, 2019 at 2:14 AM Jan Kara wrote:
> >
> > On Thu 11-07-19 08:25:50, Matthew Wilcox wrote:
> > > On Thu, Jul 11, 2019 at 07:13:50AM -0700, Matthew Wilcox wrote:
> > > > However, the XA_RETRY_ENTRY
ame(wb->bdi->dev), 32);
> > + strlcpy(__entry->name, dev_name(wb->bdi->dev), 32);
> > __entry->older = older_than_this ? *older_than_this : 0;
> > __entry->age= older_than_this ?
> > (jiffies - *older_than_this) * 1000 / HZ : -1;
> > @@ -597,7 +597,7 @@ static inline unsigned int
> > __trace_wbc_assign_cgroup(struct writeback_control *w
> > ),
> >
> > TP_fast_assign(
> > - strncpy(__entry->name,
> > + strlcpy(__entry->name,
> > dev_name(inode_to_bdi(inode)->dev), 32);
> > __entry->ino= inode->i_ino;
> > __entry->state = inode->i_state;
> > @@ -671,7 +671,7 @@ static inline unsigned int
> > __trace_wbc_assign_cgroup(struct writeback_control *w
> > ),
> >
> > TP_fast_assign(
> > - strncpy(__entry->name,
> > + strlcpy(__entry->name,
> > dev_name(inode_to_bdi(inode)->dev), 32);
> > __entry->ino= inode->i_ino;
> > __entry->state = inode->i_state;
>
--
Jan Kara
SUSE Labs, CR
= 2;
> > + else if (!strncmp(vsd->stdIdent, VSD_STD_ID_NSR03, VSD_STD_ID_LEN))
> > + vsd_id = 3;
> > + else if (!strncmp(vsd->stdIdent, VSD_STD_ID_BOOT2, VSD_STD_ID_LEN))
> > + ; /* vsd_id = 0 */
> > + else if (!strncmp(vsd->stdIdent, VSD_STD_ID_CDW02, VSD_STD_ID_LEN))
> > + ; /* vsd_id = 0 */
> > + else {
> > + /* TEA01 or invalid id : end of volume recognition area */
> > + vsd_id = 255;
> > + }
> > +
> > + return vsd_id;
> > +}
>
> --
> Pali Rohár
> pali.ro...@gmail.com
--
Jan Kara
SUSE Labs, CR
On Thu 11-07-19 10:56:52, Steve Magnani wrote:
> On 7/11/19 10:04 AM, Jan Kara wrote:
> > Thanks for the patches! I've added them to my tree and somewhat simplified
> > the logic since we don't really care about nsr 2 vs 3 or whether we
> > actually saw BEA or not. Everythi
wake the next one */
> - if (entry)
> + if (entry && dax_is_conflict(entry))
This should be !dax_is_conflict(entry)...
> dax_wake_entry(xas, entry, false);
> }
Otherwise the patch looks good to me
+
> brelse(bh);
> }
>
> if ((nsr >= 2) && (nsr <= 3))
> return nsr;
> + else if ((quirk_nsr >= 2) && (quirk_nsr <= 3))
> + return quirk_nsr;
> else if (!bh && sector - (sbi->s_session << sb->s_blocksize_bits) ==
> VSD_FIRST_SECTOR_OFFSET)
> return -1;
>
--
Jan Kara
SUSE Labs, CR
On Wed 10-07-19 13:15:39, Matthew Wilcox wrote:
> On Wed, Jul 10, 2019 at 09:02:04PM +0200, Jan Kara wrote:
> > +#define DAX_ENTRY_CONFLICT dax_make_entry(pfn_to_pfn_t(1), DAX_EMPTY)
>
> I was hoping to get rid of DAX_EMPTY ... it's almost unused now. Once
> we switch to having
On Wed 10-07-19 20:35:55, Matthew Wilcox wrote:
> On Wed, Jul 10, 2019 at 09:02:04PM +0200, Jan Kara wrote:
> > So how about the attached patch? That keeps the interface sane and passes a
> > smoketest for me (full fstest run running). Obviously it also needs a
>
On Wed 10-07-19 20:08:55, Matthew Wilcox wrote:
> On Wed, Jul 10, 2019 at 09:02:04PM +0200, Jan Kara wrote:
> > @@ -848,7 +853,7 @@ static int dax_writeback_one(struct xa_state *xas,
> > struct dax_device *dax_dev,
> > if (unlikely(dax_is_locked(entry))) {
> >
; > > > On Thu, Jul 04, 2019 at 06:54:50PM +0200, Jan Kara wrote:
> > > > > On Wed 03-07-19 20:27:28, Matthew Wilcox wrote:
> > > > > > So I think we're good for all current users.
> > > > >
> > > > > Agreed but it is
On Wed 10-07-19 09:47:12, Dave Chinner wrote:
> On Mon, Jul 08, 2019 at 03:31:14PM +0200, Jan Kara wrote:
> > I'd be really careful with nesting range locks. You can have nasty
> > situations like:
> >
> > Thread 1Thread 2
> > read_lock(0,1000)
&
@@ -760,7 +806,8 @@ static sector_t inode_getblk(struct inod
> startnum = (offset > 0);
> }
> /* Create extents for the hole between EOF and offset */
> - ret = udf_do_extend_file(inode, _epos, laarr, offset);
> + hole_len = offset << inode->i_sb->s_blocksize_bits;
The same as above.
> + ret = udf_do_extend_file(inode, _epos, laarr, hole_len);
> if (ret < 0) {
> *err = ret;
> newblock = 0;
Honza
--
Jan Kara
SUSE Labs, CR
ows.
Yeah, I think we could do that although it will be a bit painful. I would
do it by default if we found BEA descriptor but not NSR descriptor. We do
already have handling for various quirks of other udf creators so this is
nothing new... I think Palo replied about the rest of the issues you've
found.
Honza
--
Jan Kara
SUSE Labs, CR
read_lock(0,1000)
write_lock(500,1500) -> blocks due to read lock
read_lock(1001,1500) -> blocks due to write lock (or you have to break
fairness and then deal with starvation issues).
So once you allow nesting of range locks, you have to very carefully define
what is and what is not allowed. That's why in my range lock implementation
ages back I've decided to treat range lock as a rwsem for deadlock
verification purposes.
Honza
--
Jan Kara
SUSE Labs, CR
int is probably the best we
can do. Let's CC Linus, Andrew, and Greg (Linus is travelling AFAIK so I'm
not sure whether Greg won't do release for him).
Honza
--
Jan Kara
SUSE Labs, CR
eep the interfaces sane. For example get_unlocked_entry() could
return special "error code" indicating that there's no entry with matching
order in xarray but there's a conflict with it. That would be much less
error-prone interface.
Honza
--
Jan Kara
SUSE Labs, CR
On Wed 03-07-19 08:47:00, Matthew Wilcox wrote:
> On Mon, Jul 01, 2019 at 02:11:19PM +0200, Jan Kara wrote:
> > BTW, looking into the xarray code, I think I found another difference
> > between the old radix tree code and the new xarray code that could cause
> > issues. In th
On Wed 03-07-19 04:04:57, Boaz Harrosh wrote:
> On 19/06/2019 11:21, Jan Kara wrote:
> <>
> > Yes, I have patch to make madvise(MADV_WILLNEED) go through ->fadvise() as
> > well. I'll post it soon since the rest of the se
NEL);
> error = -ENOMEM;
> if (header == NULL)
> goto cleanup;
> - memcpy(header, HDR(bh), bh->b_size);
> header->h_refcount = cpu_to_le32(1);
>
> offset = (char *)here - bh->b_data;
> --
> 2.11.0
>
>
--
Jan Kara
SUSE Labs, CR
Return "0" on
> line 1719
>
> Signed-off-by: Hariprasad Kelam
I can see Andrew already picked up the cleanup. The patch looks good to me.
Feel free to add:
Reviewed-by: Jan Kara
Honza
> ---
> fs/reiserfs/journal.
code if we tried to insert PMD entry but
there was some PTE entry in the covered range, we'd get EEXIST error back
and the DAX fault code relies on this. I don't see how similar behavior is
achieved by xas_store()...
Honza
--
Jan Kara
SUSE Labs, CR
ing convention you've chosen. When
udf_do_extend_file() needs to now byte length, then why not pass it to it
directly, instead of somewhat cumbersome "sector length + byte offset"
pair?
Will you update the patch please? Thanks!
Honza
--
Jan Kara
SUSE Labs, CR
Hello Tejun!
On Thu 20-06-19 10:02:50, Tejun Heo wrote:
> On Thu, Jun 20, 2019 at 05:21:45PM +0200, Jan Kara wrote:
> > I'm completely ignorant of how btrfs compressed writeback works so don't
> > quite understand implications of this. So does this mean that writeback to
>
stupid and unsupportable...
Honza
--
Jan Kara
SUSE Labs, CR
On Wed 19-06-19 11:21:56, Ross Zwisler wrote:
> Use the newly introduced jbd2_inode dirty range scoping to prevent us
> from waiting forever when trying to complete a journal transaction.
>
> Signed-off-by: Ross Zwisler
Looks good to me. You can add:
Reviewed-
eparate ranges for current and the next transaction but I guess it is not
worth it at least for now. So just one nit below. With that applied feel free
to add:
Reviewed-by: Jan Kara
> @@ -257,15 +262,24 @@ static int journal_finish_inode_data_buffers(journal_t
> *journal,
>
;
> Signed-off-by: Ross Zwisler
The patch looks good to me. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> include/linux/fs.h | 2 ++
> mm/filemap.c | 22 ++
> 2 files changed, 24 insertion
On Wed 19-06-19 16:11:36, Sasha Levin wrote:
> On Mon, Jun 10, 2019 at 11:00:13AM +0200, Jan Kara wrote:
> > On Sat 08-06-19 07:39:14, Sasha Levin wrote:
> > > From: Jan Kara
> > >
> > > [ Upstream commit 33ec3e53e7b1869d7851e59e126bdb0fe0bd1982 ]
>
gt; 0x81800081 : entry_SYSCALL_64_after_hwframe+0x3d/0xa2 [kernel]
>
> I have patched it on online servers, It can improved the performance.
Ah, OK, directory lookup code... Makes sense. Thanks for sharing!
Honza
>
&
t; Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King
Looks good to me. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> fs/ext4/extents_status.c | 1 -
> 1 file changed, 1 deletion(-)
>
>
which path do you see __ext4_get_inode_loc() being
called without IO already plugged?
Otherwise the patch looks good to me. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> fs/ext4/inode.c | 6 ++
> 1 file changed, 6 insertion
ybody is OK, we can think about lifting private filesystem solutions
into a generic one. I'm fine with that.
That being said as Dave said we use those fs-private locks also for
serializing against equivalent issues arising for DAX. So the problem is
not only about page cache but generally about doing IO and caching
block mapping information for a file range. So the solution should not be
too tied to page cache.
Honza
--
Jan Kara
SUSE Labs, CR
through ->fadvise() as
well. I'll post it soon since the rest of the series isn't really dependent
on it.
Honza
--
Jan Kara
SUSE Labs, CR
I'll look into it this week.
Thanks a lot for debugging the problem and sending the fixes!
Honza
--
Jan Kara
SUSE Labs, CR
On Wed 12-06-19 11:41:53, Dan Williams wrote:
> On Wed, Jun 12, 2019 at 5:09 AM Jan Kara wrote:
> >
> > On Wed 12-06-19 08:47:21, Jason Gunthorpe wrote:
> > > On Wed, Jun 12, 2019 at 12:29:17PM +0200, Jan Kara wrote:
> > >
> > > > > > T
On Wed 12-06-19 11:49:52, Dan Williams wrote:
> On Wed, Jun 12, 2019 at 3:29 AM Jan Kara wrote:
> >
> > On Fri 07-06-19 07:52:13, Ira Weiny wrote:
> > > On Fri, Jun 07, 2019 at 09:17:29AM -0300, Jason Gunthorpe wrote:
> > > > On Fri, Jun 07, 2019
On Wed 12-06-19 15:13:36, Ira Weiny wrote:
> On Wed, Jun 12, 2019 at 04:14:21PM -0300, Jason Gunthorpe wrote:
> > On Wed, Jun 12, 2019 at 02:09:07PM +0200, Jan Kara wrote:
> > > On Wed 12-06-19 08:47:21, Jason Gunthorpe wrote:
> > > > On Wed, Jun 12, 2019 at 12
On Wed 12-06-19 12:36:53, Srivatsa S. Bhat wrote:
>
> [ Adding Greg to CC ]
>
> On 6/12/19 6:04 AM, Jan Kara wrote:
> > On Tue 11-06-19 15:34:48, Srivatsa S. Bhat wrote:
> >> On 6/2/19 12:04 AM, Srivatsa S. Bhat wrote:
> >>>
On Wed 12-06-19 08:47:21, Jason Gunthorpe wrote:
> On Wed, Jun 12, 2019 at 12:29:17PM +0200, Jan Kara wrote:
>
> > > > The main objection to the current ODP & DAX solution is that very
> > > > little HW can actually implement it, having the alternative still
On Fri 07-06-19 07:52:13, Ira Weiny wrote:
> On Fri, Jun 07, 2019 at 09:17:29AM -0300, Jason Gunthorpe wrote:
> > On Fri, Jun 07, 2019 at 12:36:36PM +0200, Jan Kara wrote:
> >
> > > Because the pins would be invisible to sysadmin from that point on.
> >
> > I
use the NFS lease is non-exclusive where the user space one (for the
> purpose of GUP pinning) would need to be.
>
> FWIW I have not worked out exactly what this new "exclusive" code will look
> like. Jan said:
>
> "There actually is support for locks that are not broken after given
> timeout so there shouldn't be too many changes need."
>
> But I'm not seeing that for Lease code. So I'm working on something for the
> lease code now.
Yeah, sorry for misleading you. Somehow I thought that if lease_break_time
== 0, we will wait indefinitely but when checking the code again, that
doesn't seem to be the case.
Honza
--
Jan Kara
SUSE Labs, CR
On Thu 06-06-19 15:03:30, Ira Weiny wrote:
> On Thu, Jun 06, 2019 at 12:42:03PM +0200, Jan Kara wrote:
> > On Wed 05-06-19 18:45:33, ira.we...@intel.com wrote:
> > > From: Ira Weiny
> >
> > So I'd like to actually mandate that you *must* hold the file lease
On Thu 06-06-19 15:22:28, Ira Weiny wrote:
> On Thu, Jun 06, 2019 at 04:51:15PM -0300, Jason Gunthorpe wrote:
> > On Thu, Jun 06, 2019 at 12:42:03PM +0200, Jan Kara wrote:
> >
> > > So I'd like to actually mandate that you *must* hold the file lease until
> > >
uch lease would return error and not break it) and if
breaking leases succeeds (i.e., there are no long-term pinned pages), we'd
just wait for the remaining references as we do now.
Honza
--
Jan Kara
SUSE Labs, CR
| 97 ---
> fs/xfs/xfs_file.c| 24 --
> fs/xfs/xfs_inode.h | 5 +-
> fs/xfs/xfs_ioctl.c | 15 +++-
> fs/xfs/xfs_iops.c| 14 +++-
> fs/xfs/xfs_pnfs.c| 14 ++--
> include/linux/dax.h | 9 ++-
> include/linux/fs.h | 2 +-
> include/linux/mm.h | 2 +
> include/trace/events/filelock.h | 35 +
> include/uapi/asm-generic/fcntl.h | 3 +
> mm/gup.c | 129 ---
> mm/huge_memory.c | 12 +++
> 18 files changed, 299 insertions(+), 135 deletions(-)
>
> --
> 2.20.1
>
--
Jan Kara
SUSE Labs, CR
more #defines to
> mman-common.h. That can be done as a separate patch.
>
> Signed-off-by: Aneesh Kumar K.V
Looks good to me FWIW (I don't have much experience with mmap flags and
their peculirarities). So feel free to add:
Reviewed-by: Jan Kara
On Sat 25-05-19 17:12:51, Liu Song wrote:
> From: Liu Song
>
> delayed/dealyed
>
> Signed-off-by: Liu Song
Thanks. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> fs/jbd2/commit.c | 2 +-
> 1 file ch
ing on how renames race). And by the
time you decide A/B/C/target exists, it doesn't need to exist anymore.
Honestly I don't see how you want to implement *any* solution in a sane
way. About the most reliable+simple would seem to be stat "A/B/C/target"
once per second as dumb as it is.
Honza
--
Jan Kara
SUSE Labs, CR
ed how should look a reasonably clean interface for this
that isn't specific to a particular IO scheduler implementation.
Honza
--
Jan Kara
SUSE Labs, CR
ngelog. And the above paragraph helped me
clarify which checks in dax_iomap_actor() you think replace those usercopy
checks. So I think it would be good to add that paragraph to those
copy_from_pmem() functions as a comment just in case we are wondering in
the future why we are skipping t
Honza
>
> Bypass this overhead and call the 'no check' versions of the
> copy_{to,from}_iter operations directly.
>
> Fixes: 0aed55af8834 ("x86, uaccess: introduce copy_from_iter_flushcache...")
> Cc: Jan Kara
> Cc
On Fri 17-05-19 14:19:51, Gaowei Pu wrote:
> There are some print format mistakes in debug messages. Fix them.
>
> Signed-off-by: Gaowei Pu
Looks good. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> fs/jbd2
On Thu 16-05-19 21:17:14, Tetsuo Handa wrote:
> On 2019/05/16 20:48, Jan Kara wrote:
> > OK, so non-racy fix was a bit more involved and I've ended up just
> > upgrading the file reference to an exclusive one in loop_set_fd() instead
> > of trying to hand-craft some locking
t; page_fault+0x1e/0x30
>
> Cc:
> Fixes: c6f3c5ee40c1 ("mm/huge_memory.c: fix modifying of page protection by
> insert_pfn_pmd()")
> Reported-by: Piotr Balcer
> Tested-by: Yan Ma
> Cc: Aneesh Kumar K.V
> Cc: Chandan Rajendra
> Cc: Jan Kara
> Cc:
o when mark
> + * dirtied, and this list is searched when writeback diry dquots to
> + * quota file.
> + *
> * Dquots with a specific identity (device, type and id) are placed on
> * one of the dquot_hash[] hash chains. The provides an efficient search
> * mechanism to locate a specific dquot.
> --
> 2.17.2
>
>
--
Jan Kara
SUSE Labs, CR
he.
So what I'd do is that I'd split initialization of jbd2_inode_cache into a
separate function (and the same for destruction). That more aligns with how
things are currently done in jbd2 and also fixes the problem with double
destruction.
Honza
--
Jan Kara
SUSE Labs, CR
latter can be used to test for specific
> event types.
>
> Signed-off-by: Amir Goldstein
> Signed-off-by: Jan Kara
> Signed-off-by: Sasha Levin
Sasha, why did you select this patch? It is just a cleanup with no user
visible effect and was done mostly to simplify implementing follow
/* Back out changes we already did */
> spin_lock([cnt]->dq_dqb_lock);
> - dquots[cnt]->dq_dqb.dqb_curinodes--;
> + dquot_decr_inodes(dquots[cnt], 1);
> spin_unlock([cnt]->dq_dqb_lock);
> }
> goto warn_put_all;
> --
> 2.20.1
>
>
--
Jan Kara
SUSE Labs, CR
On Tue 30-04-19 14:18:21, Al Viro wrote:
> On Tue, Apr 30, 2019 at 03:07:39PM +0200, Jan Kara wrote:
> > On Tue 30-04-19 04:11:44, Al Viro wrote:
> > > On Tue, Apr 30, 2019 at 04:55:01AM +0200, Jan Kara wrote:
> > >
> > > > Yeah, you're right. And if we p
On Tue 30-04-19 04:11:44, Al Viro wrote:
> On Tue, Apr 30, 2019 at 04:55:01AM +0200, Jan Kara wrote:
>
> > Yeah, you're right. And if we push the patch a bit further to not take
> > loop_ctl_mutex for invalid ioctl number, that would fix the problem. I
> > can send a fix.
if (!(mode & FMODE_WRITE) && !capable(CAP_SYS_ADMIN))
> return -EPERM;
> - /* Fall through */
> + return lo_simple_ioctl(lo, cmd, arg);
> default:
> - err = lo_simple_ioctl(lo, cmd, arg);
> - break;
> + return -EINVAL;
> }
>
> return err;
> diff --git a/drivers/block/loop.h b/drivers/block/loop.h
> index af75a5ee4094..56a9a0c161d7 100644
> --- a/drivers/block/loop.h
> +++ b/drivers/block/loop.h
> @@ -84,7 +84,6 @@ struct loop_func_table {
> int (*init)(struct loop_device *, const struct loop_info64 *);
> /* release is called from loop_unregister_transfer or clr_fd */
> int (*release)(struct loop_device *);
> - int (*ioctl)(struct loop_device *, int cmd, unsigned long arg);
> struct module *owner;
> };
>
--
Jan Kara
SUSE Labs, CR
e(struct inode *inode, int
> type)
> dquot = NULL;
> }
> got[cnt] = dquot;
> +
> + if (got[cnt])
> + init_needed = 1;
> }
>
> /* All required i_dquot has been initialized */
> --
> 2.20.1
>
>
--
Jan Kara
SUSE Labs, CR
s were blown away leading to
> _ext4_show_options() output being incorrect.
>
> Signed-off-by: Debabrata Banerjee
Thanks! You can add:
Reviewed-by: Jan Kara
Honza
> ---
> fs/ext4/super.c | 2 +-
> 1 file changed, 1
goto failed_mount_wq;
> }
> - sbi->s_def_mount_opt &= EXT4_MOUNT_JOURNAL_CHECKSUM;
> clear_opt(sb, JOURNAL_CHECKSUM);
> clear_opt(sb, DATA_FLAGS);
> sbi->s_journal = NULL;
> --
> 2.21.0
>
--
Jan Kara
SUSE Labs, CR
com/x/log.txt?x=13020ef4a0
> kernel config: https://syzkaller.appspot.com/x/.config?x=a42d110b47dd6b36
> compiler: gcc (GCC) 9.0.0 20181231 (experimental)
Let's try new version of the patch:
#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git
fsnotify
Honza
--
Jan Kara
SUSE Labs, CR
git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git
fsnotify
Honza
--
Jan Kara
SUSE Labs, CR
reserved = 1;
> +#endif
> remove_inode_dquot_ref(inode, type, tofree_head);
> }
> spin_unlock(_data_lock);
> --
> 2.17.2 (Apple Git-113)
>
>
--
Jan Kara
SUSE Labs, CR
type]->read_dqblk(dquot);
> - if (ret < 0)
> - goto out_iolock;
> + if (ret < 0)
> + goto out_iolock;
> + }
> /* Make sure flags update is visible after dquot has been filled */
> smp_mb__before_atomic();
> set_bit(DQ_READ_B, >dq_flags);
> --
> 2.20.1
>
>
--
Jan Kara
SUSE Labs, CR
On Tue 23-04-19 21:05:22, Amir Goldstein wrote:
> On Tue, Apr 23, 2019 at 7:27 PM Jan Kara wrote:
> >
> > On Fri 19-04-19 12:33:02, Amir Goldstein wrote:
> > > On Thu, Apr 18, 2019 at 8:14 PM syzbot
> > > wrote:
> > > >
> > > >
smp_wmb(); \
hlist_add_##where##_rcu(>obj_list, head); \
} while (0)
And I would not really worry about fsnotify_put_mark() - if it ever sees
mark->connector set, mark really is on the connector's list and
fsnotify_put_mark() does the right thing (i.e. locks connector->lock if
needed).
Honza
--
Jan Kara
SUSE Labs, CR
SER_HINTS)
streamid = 0;
else
streamid = nr_streams - streamid - 1;
}
what do you think?
Honza
--
Jan Kara
SUSE Labs, CR
4: add ext4_sb_bread() to disambiguate ENOMEM
> cases")
>
> Signed-off-by: Pan Bian
Thanks for the patch! Good spotting. You can add:
Reviewed-by: Jan Kara
I'm just wondering: Ted, shouldn't we make ext4_mark_iloc_dirty() clear the
iloc.bh pointer on it's own? I believe this is no
dax/super.c | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
Added Dan to CC since I'm not sure how closely he follows fsdevel. The
patch looks good to me FWIW so feel free to add:
Reviewed-by: Jan Kara
Honza
>
On Tue 16-04-19 18:53:32, Al Viro wrote:
> From: Al Viro
>
> the rest of this ->destroy_inode() instance could probably be folded
> into ext4_evict_inode()
>
> Signed-off-by: Al Viro
Looks good to me. You can add:
Reviewed-by: Jan Kara
You're right about the possibilit
rted-by: syzbot+f584efa0ac7213c22...@syzkaller.appspotmail.com
> Signed-off-by: Barret Rhoden
> Cc: sta...@vger.kernel.org
The patch looks good to me. You can add:
Reviewed-by: Jan Kara
Honza
> ---
>
> - In the current cod
ext4_msg(sb, KERN_ERR, "can't read descriptor %u", i);
> --
> 2.21.0.392.gf8f6787159e-goog
>
--
Jan Kara
SUSE Labs, CR
n
February [1] by just bailing out from file_remove_privs() for non-regular
files. But so far you've ignored that patch... Will you pick it up please?
Honza
[1]
https://lore.kernel.org/lkml/cbdc8071-de76-bb0a-6890-15ef21023...@tu-dortmund.de
--
Jan Kara
SUSE Labs, CR
simple_strtoul(dentry->d_name.name + 3,
> - NULL, 0),
> - };
> - inode = udf_iget(dir->i_sb, lb);
> - if (IS_ERR(inode))
> - return inode;
> - } else
> -#endif /* UDF_RECOVERY */
>
struct fileIdentDesc *fi = NULL;
>
> if (dentry->d_name.len > UDF_NAME_LEN)
> return ERR_PTR(-ENAMETOOLONG);
> --
> 2.7.4
>
>
--
Jan Kara
SUSE Labs, CR
On Thu 21-03-19 16:11:42, Jan Kara wrote:
> Switch waiting for response to fanotify permission events interruptible.
> This allows e.g. the system to be suspended while there are some
> fanotify permission events pending (which is reportedly pretty common
> when for example AV soluti
gt; qinfo->dqi_entry_size = sizeof(struct v2r1_disk_dqblk);
> qinfo->dqi_ops = _qtree_ops;
> }
> - ret = 0;
> out:
> up_read(>dqio_sem);
> return ret;
> --
> 2.17.2
>
>
--
Jan Kara
SUSE Labs, CR
; +static void remove_journal_hash(struct super_block *sb,
>struct reiserfs_journal_cnode **table,
>struct reiserfs_journal_list *jl,
> unsigned long block, int remove_freed)
> --
> 2.7.4
>
--
Jan Kara
SUSE Labs, CR
LL mean generic_nvdimm_flush(). Just so that people don't
get confused by the code.
Honza
--
Jan Kara
SUSE Labs, CR
On Wed 10-04-19 13:42:23, Amir Goldstein wrote:
> On Wed, Apr 10, 2019 at 12:10 PM Jan Kara wrote:
> >
> > On Tue 09-04-19 21:01:54, Amir Goldstein wrote:
> > > On Tue, Apr 9, 2019 at 6:43 PM Jan Kara wrote:
> > > > On Tue 09-04-19 14:49:22, Amir Goldstein
On Tue 09-04-19 21:01:54, Amir Goldstein wrote:
> On Tue, Apr 9, 2019 at 6:43 PM Jan Kara wrote:
> > On Tue 09-04-19 14:49:22, Amir Goldstein wrote:
> > > Commit 23d0127096cb ("fs/sync.c: make sync_file_range(2) use WB_SYNC_NONE
> > > writeback") c
On Tue 09-04-19 21:11:22, zhangxiaoxu (A) wrote:
>
>
> On 4/8/2019 7:11 PM, Jan Kara wrote:
> > On Sat 06-04-19 15:13:13, ZhangXiaoxu wrote:
> > > When the buffer write failed, 'end_buffer_write_sync' and
> > > 'end_buffer_async_write' will clear the
FILE_RANGE_WAIT_BEFORE) {
> ret = file_fdatawait_range(f.file, offset, endbyte);
> if (ret < 0)
> diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h
> index 121e82ce296b..59c71fa8c553 100644
> --- a/include/uapi/linux/fs.h
> +++ b/include/uapi/linux/fs.h
> @@ -320,6 +320,9 @@ struct fscrypt_key {
> #define SYNC_FILE_RANGE_WAIT_BEFORE 1
> #define SYNC_FILE_RANGE_WRITE2
> #define SYNC_FILE_RANGE_WAIT_AFTER 4
> +#define SYNC_FILE_RANGE_WRITE_AND_WAIT (SYNC_FILE_RANGE_WRITE | \
> + SYNC_FILE_RANGE_WAIT_BEFORE | \
> + SYNC_FILE_RANGE_WAIT_AFTER)
>
> /*
> * Flags for preadv2/pwritev2:
> --
> 2.17.1
>
--
Jan Kara
SUSE Labs, CR
lse {
> buffer_io_error(bh, ", lost async page write");
> mark_buffer_write_io_error(bh);
> - clear_buffer_uptodate(bh);
> SetPageError(page);
> }
>
> --
> 2.7.4
>
--
Jan Kara
SUSE Labs, CR
On Wed 03-04-19 16:10:17, Pankaj Gupta wrote:
> Virtio pmem provides asynchronous host page cache flush
> mechanism. We don't support 'MAP_SYNC' with virtio pmem
> and ext4.
>
> Signed-off-by: Pankaj Gupta
The patch looks good to me. You can add:
Review
Hi,
On Sat 30-03-19 14:49:46, Steve Magnani wrote:
> On 3/25/19 11:42 AM, Jan Kara wrote:
> > Hi!
> >
> > On Sat 23-03-19 15:14:05, Steve Magnani wrote:
> > > I have been hunting a UDF bug that occasionally results in generation
> > > of an Allocat
;bh, "call brelse");
> > > + brelse(partial2->bh);
> > > + }
> > > return 0;
> > > }
> > >
> >
> > Greg & Co,
> > Please revert that above patch from stable kernels or backport the
> > follow-up patch that fixes the problem.
>
> So you need 5e86bdda4153 ("ext4: cleanup bh release code in
> ext4_ind_remove_space()") applied to all of the stable and LTS kernels
> at the moment (as that patch only showed up in 5.1-rc1)?
>
> If so, I need an ack from the ext4 developers/maintainer to do so.
Ack from me, and sorry for missing this brown paper bag bug during
review...
Honza
--
Jan Kara
SUSE Labs, CR
't notice the problems when merging the patch.
I've fixed these problems up.
Honza
--
Jan Kara
SUSE Labs, CR
+ need_to_start = !tid_geq(journal->j_commit_request, tid);
> read_unlock(>j_state_lock);
> if (need_to_start)
> jbd2_log_start_commit(journal, tid);
> --
> 2.19.1
>
>
--
Jan Kara
SUSE Labs, CR
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,
> > >
401 - 500 of 6478 matches
Mail list logo
