che assumptions and warnings.
>
> Cc: Jan Kara
> Reported-by: kbuild test robot
> Signed-off-by: Dan Williams
Looks good. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> fs/ext2/ext2.h |
che assumptions and warnings.
>
> Cc: "Theodore Ts'o" <ty...@mit.edu>
> Cc: Andreas Dilger <adilger.ker...@dilger.ca>
> Cc: linux-e...@vger.kernel.org
> Cc: Jan Kara <j...@suse.cz>
> Signed-off-by: Dan Williams <dan.j.willi...@intel.com
che assumptions and warnings.
>
> Cc: "Theodore Ts'o"
> Cc: Andreas Dilger
> Cc: linux-e...@vger.kernel.org
> Cc: Jan Kara
> Signed-off-by: Dan Williams
Looks good. You can add:
Reviewed-by: Jan Kara
dev_pagemap_get_ops();
>
> devmem = devres_alloc_node(_devmem_release, sizeof(*devmem),
> GFP_KERNEL, dev_to_node(device));
> @@ -1090,7 +1081,7 @@ struct hmm_devmem *hmm_devmem_add_resource(const struct
> hmm_devmem_ops *ops,
> if (res->desc != IORES_DESC_DEVICE_PUBLIC_MEMORY)
> return ERR_PTR(-EINVAL);
>
> - static_branch_enable(_private_key);
> + dev_pagemap_get_ops();
>
> devmem = devres_alloc_node(_devmem_release, sizeof(*devmem),
> GFP_KERNEL, dev_to_node(device));
> diff --git a/mm/swap.c b/mm/swap.c
> index 0f17330dd0e5..eed846cfc8b8 100644
> --- a/mm/swap.c
> +++ b/mm/swap.c
> @@ -29,6 +29,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -744,7 +745,7 @@ void release_pages(struct page **pages, int nr)
> flags);
> locked_pgdat = NULL;
> }
> - put_zone_device_private_or_public_page(page);
> + put_devmap_managed_page(page);
> continue;
> }
>
>
--
Jan Kara <j...@suse.com>
SUSE Labs, CR
;page_free() callbacks. Rework the HMM-specific
> static-key into a generic mechanism that either HMM or FS_DAX code paths
> can enable.
>
> Cc: Michal Hocko
> Reviewed-by: "Jérôme Glisse"
> Signed-off-by: Dan Willia
On Thu 29-03-18 16:02:45, Dan Williams wrote:
> On Thu, Mar 29, 2018 at 9:02 AM, Jan Kara <j...@suse.cz> wrote:
> > On Wed 21-03-18 15:57:48, Dan Williams wrote:
> [..]
> > I find it quite tricky that in case we pass zero page / empty entry into
> > dax_[dis]ass
On Thu 29-03-18 16:02:45, Dan Williams wrote:
> On Thu, Mar 29, 2018 at 9:02 AM, Jan Kara wrote:
> > On Wed 21-03-18 15:57:48, Dan Williams wrote:
> [..]
> > I find it quite tricky that in case we pass zero page / empty entry into
> > dax_[dis]associate_entry(), it will
lwig <h...@lst.de>
> Signed-off-by: Dan Williams <dan.j.willi...@intel.com>
The patch looks good to me. You can add:
Reviewed-by: Jan Kara <j...@suse.cz>
Honza
> ---
> drivers/dax/super.c | 79
&
ount time. No functional changes
> are expected as this only registers a nop handler for the ->page_free()
> event for device-mapped pages.
>
> Cc: Michal Hocko
> Reviewed-by: "Jérôme Glisse"
> Reviewed-by: Christoph Hellwig
>
s_fallocate+0x20c/0x270
> vfs_fallocate+0x154/0x270
> SyS_fallocate+0x43/0x80
> entry_SYSCALL_64_fastpath+0x1f/0x96
>
> Cc: Jeff Moyer <jmo...@redhat.com>
> Cc: Matthew Wilcox <mawil...@microsoft.com>
> Cc: Ross Zwisler <ross.zwis...@linux.intel.com
s_fallocate+0x20c/0x270
> vfs_fallocate+0x154/0x270
> SyS_fallocate+0x43/0x80
> entry_SYSCALL_64_fastpath+0x1f/0x96
>
> Cc: Jeff Moyer
> Cc: Matthew Wilcox
> Cc: Ross Zwisler
> Reviewed-by: Jan Kara
> Reviewed-by: Christoph Hellwig
> Signed-o
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>
Thanks for the cleanup in the patch when setting inode ops. The patch looks
good except the same
che assumptions and warnings.
>
> Cc: Jan Kara
> Reported-by: kbuild test robot
> Signed-off-by: Dan Williams
Thanks for the cleanup in the patch when setting inode ops. The patch looks
good except the same comment applies as for ext4 - please provide
ext2_dax_direct_IO() w
che assumptions and warnings.
>
> Cc: "Theodore Ts'o" <ty...@mit.edu>
> Cc: Andreas Dilger <adilger.ker...@dilger.ca>
> Cc: linux-e...@vger.kernel.org
> Cc: Jan Kara <j...@suse.cz>
> Signed-off-by: Dan Williams <dan.j.willi...@intel.com>
Looks good
che assumptions and warnings.
>
> Cc: "Theodore Ts'o"
> Cc: Andreas Dilger
> Cc: linux-e...@vger.kernel.org
> Cc: Jan Kara
> Signed-off-by: Dan Williams
Looks good, just one nit below.
> @@ -3946,6 +3961,13 @@ static const struct address_space_operations
n 'struct page' flags.
>
> Cc: Jeff Moyer <jmo...@redhat.com>
> Cc: Matthew Wilcox <mawil...@microsoft.com>
> Cc: Ross Zwisler <ross.zwis...@linux.intel.com>
> Reviewed-by: Christoph Hellwig <h...@lst.de>
> Suggested-by: Jan Kara <j...@suse.cz>
> Sugges
uct page' flags.
>
> Cc: Jeff Moyer
> Cc: Matthew Wilcox
> Cc: Ross Zwisler
> Reviewed-by: Christoph Hellwig
> Suggested-by: Jan Kara
> Suggested-by: Dave Chinner
> Signed-off-by: Dan Williams
Looks good to me. You can add:
Reviewed-by: Jan Kara
> Cc: Matthew Wilcox <mawil...@microsoft.com>
> Cc: Jan Kara <j...@suse.cz>
> Cc: Dave Chinner <da...@fromorbit.com>
> Reviewed-by: Christoph Hellwig <h...@lst.de>
> Signed-off-by: Dan Williams <dan.j.willi...@inte
On Wed 21-03-18 15:57:27, Dan Williams wrote:
> Block device inodes never have S_DAX set, so kill the check for DAX and
> diversion to dax_writeback_mapping_range().
>
> Cc: Jeff Moyer
> Cc: Ross Zwisler
> Cc: Matthew Wilcox
> Cc: Jan Kara
> Cc: Dave Chinner
> Rev
;ross.zwis...@linux.intel.com>
> Suggested-by: Matthew Wilcox <mawil...@microsoft.com>
> Suggested-by: Jan Kara <j...@suse.cz>
> Suggested-by: Christoph Hellwig <h...@lst.de>
> Reviewed-by: Christoph Hellwig <h...@lst.de>
> Suggested-by: Dave Chinner <da...@fr
dax. These noop implementations are there in the dax case to
> prevent the VFS from falling back to operations with page-cache
> assumptions, dax_writeback_mapping_range() may not be referenced in the
> FS_DAX=n case.
>
> Cc: Jeff Moyer
> Cc: Ross Zwisler
> Suggested-by: Matthew Wilcox
&
On Thu 22-03-18 10:00:33, Dominik Brodowski wrote:
> While sys32_quotactl() is only needed on x86, it can use the recommended
> COMPAT_SYSCALL_DEFINEx() machinery for its setup.
>
> Cc: Jan Kara <j...@suse.com>
> Cc: Christoph Hellwig <h...@infradead.org>
> Signed
On Thu 22-03-18 10:00:33, Dominik Brodowski wrote:
> While sys32_quotactl() is only needed on x86, it can use the recommended
> COMPAT_SYSCALL_DEFINEx() machinery for its setup.
>
> Cc: Jan Kara
> Cc: Christoph Hellwig
> Signed-off-by: Dominik Brodowski
Looks good AFAICT. Y
is, the syscall entry path can be streamlined.
>
> Cc: Jan Kara <j...@suse.com>
> Signed-off-by: Dominik Brodowski <li...@dominikbrodowski.net>
Looks good. Feel free to add:
Acked-by: Jan Kara <j...@suse.cz>
is, the syscall entry path can be streamlined.
>
> Cc: Jan Kara
> Signed-off-by: Dominik Brodowski
Looks good. Feel free to add:
Acked-by: Jan Kara
Honza
> ---
> fs/quota/compat.c| 8
&g
. On this basis, the syscall entry path can be streamlined.
>
> Cc: Jan Kara <j...@suse.cz>
> Cc: Amir Goldstein <amir7...@gmail.com>
> Signed-off-by: Dominik Brodowski <li...@dominikbrodowski.net>
Looks good. Feel f
. On this basis, the syscall entry path can be streamlined.
>
> Cc: Jan Kara
> Cc: Amir Goldstein
> Signed-off-by: Dominik Brodowski
Looks good. Feel free to add:
Acked-by: Jan Kara
Honza
> ---
> fs/not
is, the syscall entry path can be streamlined.
>
> Cc: Jan Kara <j...@suse.cz>
> Cc: Amir Goldstein <amir7...@gmail.com>
> Cc: linux-fsde...@vger.kernel.org
> Signed-off-by: Dominik Brodowski <li...@dominikbrodowski.net>
Looks good. Fee
is, the syscall entry path can be streamlined.
>
> Cc: Jan Kara
> Cc: Amir Goldstein
> Cc: linux-fsde...@vger.kernel.org
> Signed-off-by: Dominik Brodowski
Looks good. Feel free to add:
Acked-by: Jan Kara
Hon
int type)
> --
> 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 <j...@suse.com>
SUSE Labs, CR
comm 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
on on whether your ~90ms of boot time are good
enough justification for a kernel config option...
Honza
--
Jan Kara <j...@suse.com>
SUSE Labs, CR
d
enough justification for a kernel config option...
Honza
--
Jan Kara
SUSE Labs, CR
a known issue.
As I've mentioned above, so far I didn't see reports like this...
Honza
--
Jan Kara <j...@suse.com>
SUSE Labs, CR
a known issue.
As I've mentioned above, so far I didn't see reports like this...
Honza
--
Jan Kara
SUSE Labs, CR
of fsnotify_group to keep the
> size same, at least for 64 bit build, even with additional member by
> filling the holes.
>
> Signed-off-by: Shakeel Butt <shake...@google.com>
The patch looks OK to me from fsnotify POV. So feel free to add:
Acked-by: Jan Kara <
of fsnotify_group to keep the
> size same, at least for 64 bit build, even with additional member by
> filling the holes.
>
> Signed-off-by: Shakeel Butt
The patch looks OK to me from fsnotify POV. So feel free to add:
Acked-by: Jan Kara
2_setsize(struct inode *inode, loff_t
> newsize)
>
> inode_dio_wait(inode);
>
> - if (IS_DAX(inode)) {
> + if (IS_ENABLED(CONFIG_FS_DAX) && IS_DAX(inode)) {
> error = iomap_zero_range(inode, newsize,
>PAGE_ALIGN(n
> newsize)
>
> inode_dio_wait(inode);
>
> - if (IS_DAX(inode)) {
> + if (IS_ENABLED(CONFIG_FS_DAX) && IS_DAX(inode)) {
> error = iomap_zero_range(inode, newsize,
>PAGE_ALIGN(newsize) - newsize, NULL,
>_iomap_ops);
> --
> 2.9.0
>
>
--
Jan Kara
SUSE Labs, CR
e:
> @@ -2082,8 +2086,8 @@ error_out:
> for (i = 0; i < sbi->s_partitions; i++)
> udf_free_partition(>s_partmaps[i]);
> #ifdef CONFIG_UDF_NLS
> - if (UDF_QUERY_FLAG(sb, UDF_FLAG_NLS_MAP))
> - unload_nls(sbi->s_nls_map);
+2086,8 @@ error_out:
> for (i = 0; i < sbi->s_partitions; i++)
> udf_free_partition(>s_partmaps[i]);
> #ifdef CONFIG_UDF_NLS
> - if (UDF_QUERY_FLAG(sb, UDF_FLAG_NLS_MAP))
> - unload_nls(sbi->s_nls_map);
> + if (uopt.nls_map)
> + unload_nls(uopt.nls_map);
> #endif
> if (!(sb->s_flags & MS_RDONLY))
> udf_close_lvid(sb);
> --
> 1.8.3.1
>
--
Jan Kara
SUSE Labs, CR
On Mon 26-02-18 20:20:48, Dan Williams wrote:
> In preparation for fixing the broken definition of S_DAX in the
> CONFIG_FS_DAX=n + CONFIG_DEV_DAX=y case, convert all the remaining
> IS_DAX() usages to use explicit tests for FSDAX.
>
> Cc: Jan Kara <j...@suse.com>
> C
On Mon 26-02-18 20:20:48, Dan Williams wrote:
> In preparation for fixing the broken definition of S_DAX in the
> CONFIG_FS_DAX=n + CONFIG_DEV_DAX=y case, convert all the remaining
> IS_DAX() usages to use explicit tests for FSDAX.
>
> Cc: Jan Kara
> Cc: Matthew Wilcox
> C
On Mon 26-02-18 20:20:42, Dan Williams wrote:
> In preparation for fixing the broken definition of S_DAX in the
> CONFIG_FS_DAX=n + CONFIG_DEV_DAX=y case, convert all IS_DAX() usages to
> use explicit tests for the DEVDAX and FSDAX sub-cases of DAX
> functionality.
>
> Cc: Jan K
On Mon 26-02-18 20:20:42, Dan Williams wrote:
> In preparation for fixing the broken definition of S_DAX in the
> CONFIG_FS_DAX=n + CONFIG_DEV_DAX=y case, convert all IS_DAX() usages to
> use explicit tests for the DEVDAX and FSDAX sub-cases of DAX
> functionality.
>
> Cc: Jan K
On Mon 26-02-18 20:20:37, Dan Williams wrote:
> In preparation for fixing the broken definition of S_DAX in the
> CONFIG_FS_DAX=n + CONFIG_DEV_DAX=y case, convert all IS_DAX() usages to
> use explicit tests for FSDAX since DAX is ambiguous.
>
> Cc: Jan Kara <j...@suse.com>
&
On Mon 26-02-18 20:20:37, Dan Williams wrote:
> In preparation for fixing the broken definition of S_DAX in the
> CONFIG_FS_DAX=n + CONFIG_DEV_DAX=y case, convert all IS_DAX() usages to
> use explicit tests for FSDAX since DAX is ambiguous.
>
> Cc: Jan Kara
> Cc: "Darric
On Mon 26-02-18 20:20:32, Dan Williams wrote:
> In preparation for fixing the broken definition of S_DAX in the
> CONFIG_FS_DAX=n + CONFIG_DEV_DAX=y case, convert all IS_DAX() usages to
> use explicit tests for FSDAX since DAX is ambiguous.
>
> Cc: Jan Kara <j...@suse.com>
On Mon 26-02-18 20:20:32, Dan Williams wrote:
> In preparation for fixing the broken definition of S_DAX in the
> CONFIG_FS_DAX=n + CONFIG_DEV_DAX=y case, convert all IS_DAX() usages to
> use explicit tests for FSDAX since DAX is ambiguous.
>
> Cc: Jan Kara
> Cc: "Theodo
ove all ifdef handling to header files rather than in the source. The
> compiler will still be able to determine that all the related code can
> be discarded in the CONFIG_FS_DAX=n case.
>
> Cc: Jan Kara <j...@suse.com>
> Cc: <sta...@vger.kernel.org>
> Fixes: dee410792419 (&quo
ove all ifdef handling to header files rather than in the source. The
> compiler will still be able to determine that all the related code can
> be discarded in the CONFIG_FS_DAX=n case.
>
> Cc: Jan Kara
> Cc:
> Fixes: dee410792419 ("/dev/dax, core: file operations and dax-mmap"
ove all ifdef handling to header files rather than in the source. The
> compiler will still be able to determine that all the related code can
> be discarded in the CONFIG_FS_DAX=n case.
>
> Cc: Jan Kara <j...@suse.com>
> Cc: <sta...@vger.kernel.org>
> Fixes: dee410792419 (&quo
ove all ifdef handling to header files rather than in the source. The
> compiler will still be able to determine that all the related code can
> be discarded in the CONFIG_FS_DAX=n case.
>
> Cc: Jan Kara
> Cc:
> Fixes: dee410792419 ("/dev/dax, core: file operations and dax-mmap"
On Mon 26-02-18 20:20:27, Dan Williams wrote:
> In preparation for fixing the broken definition of S_DAX in the
> CONFIG_FS_DAX=n + CONFIG_DEV_DAX=y case, convert all IS_DAX() usages to
> use explicit tests for FSDAX since DAX is ambiguous.
>
> Cc: Jan Kara <j...@suse.com>
On Mon 26-02-18 20:20:27, Dan Williams wrote:
> In preparation for fixing the broken definition of S_DAX in the
> CONFIG_FS_DAX=n + CONFIG_DEV_DAX=y case, convert all IS_DAX() usages to
> use explicit tests for FSDAX since DAX is ambiguous.
>
> Cc: Jan Kara
> Cc: Matthew
ert all open-coded usages of the semaphore to the
> helpers.
Just one nit below. With that fixed you can add:
Reviewed-by: Jan Kara <j...@suse.cz>
> Cc: Jan Kara <j...@suse.com>
> Cc: <sta...@vger.kernel.org>
> Fixes: dee410792419 ("/dev/dax, core: file operatio
ert all open-coded usages of the semaphore to the
> helpers.
Just one nit below. With that fixed you can add:
Reviewed-by: Jan Kara
> Cc: Jan Kara
> Cc:
> Fixes: dee410792419 ("/dev/dax, core: file operations and dax-mmap")
> Signed-off-by: Dan Williams
> ---
>
prefer to solve link-time problems with stubs instead of
relying on dead-code elimination, I can live with split macros so once the
changelog is settled, feel free to add:
Reviewed-by: Jan Kara <j...@suse.cz>
Honza
> i
prefer to solve link-time problems with stubs instead of
relying on dead-code elimination, I can live with split macros so once the
changelog is settled, feel free to add:
Reviewed-by: Jan Kara
Honza
> is only non-zero in the CONFIG
ned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging. You may
> also want to consider cooperating with the maintainer of the conflicting
> tree to minimise any particularly complex conflicts.
Thanks for the conflict resol
ned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging. You may
> also want to consider cooperating with the maintainer of the conflicting
> tree to minimise any particularly complex conflicts.
Thanks for the conflict resolution. I
On Mon 26-02-18 11:38:19, Mark Rutland wrote:
> On Mon, Feb 26, 2018 at 11:52:56AM +0100, Jan Kara wrote:
> > On Fri 23-02-18 15:47:36, Mark Rutland wrote:
> > > Hi all,
> > >
> > > While fuzzing arm64/v4.16-rc2 with syzkaller, I simultaneously hit a
>
On Mon 26-02-18 11:38:19, Mark Rutland wrote:
> On Mon, Feb 26, 2018 at 11:52:56AM +0100, Jan Kara wrote:
> > On Fri 23-02-18 15:47:36, Mark Rutland wrote:
> > > Hi all,
> > >
> > > While fuzzing arm64/v4.16-rc2 with syzkaller, I simultaneously hit a
>
On Fri 23-02-18 15:47:36, Mark Rutland wrote:
> Hi all,
>
> While fuzzing arm64/v4.16-rc2 with syzkaller, I simultaneously hit a
> number of splats in the block layer:
>
> * inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-R} usage in
> jbd2_trans_will_send_data_barrier
>
> * BUG: sleeping function
_event_percpu+0x5c/0x148
> [ 162.814657] handle_irq_event_percpu+0x34/0x88
> [ 162.815730] handle_irq_event+0x48/0x78
> [ 162.816856] handle_fasteoi_irq+0xc0/0x198
> [ 162.817946] generic_handle_irq+0x24/0x38
> [ 162.818948] __handle_domain_irq+0x84/0xf0
> [ 162.820056] gic_hand
On Fri 23-02-18 16:43:37, Dan Williams wrote:
> Do not bother looking up the file type in the case when Filesystem-DAX
> is disabled at build time.
>
> Cc: Alexander Viro <v...@zeniv.linux.org.uk>
> Cc: linux-fsde...@vger.kernel.org
> Cc: Christoph Hellwig <h..
On Fri 23-02-18 16:43:37, Dan Williams wrote:
> Do not bother looking up the file type in the case when Filesystem-DAX
> is disabled at build time.
>
> Cc: Alexander Viro
> Cc: linux-fsde...@vger.kernel.org
> Cc: Christoph Hellwig
> Cc: Jan Kara
> Signed-off-by: Dan Wi
c
> +++ b/fs/xfs/xfs_reflink.c
> @@ -1351,7 +1351,7 @@ xfs_reflink_remap_range(
> goto out_unlock;
>
> /* Don't share DAX file data for now. */
> - if (IS_DAX(inode_in) || IS_DAX(inode_out))
> + if (IS_FSDAX(inode_in) || IS_FSDAX(inode_out))
> goto
/* Don't share DAX file data for now. */
> - if (IS_DAX(inode_in) || IS_DAX(inode_out))
> + if (IS_FSDAX(inode_in) || IS_FSDAX(inode_out))
> goto out_unlock;
>
> ret = vfs_clone_file_prep_inodes(inode_in, pos_in, inode_out, pos_out,
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 79c413985305..a4310a95011b 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -1909,6 +1909,8 @@ static inline bool sb_rdonly(const struct super_block
> *sb) { return sb->s_flags
> #define IS_WHITEOUT(inode) (S_ISCHR(inode->i_mode) && \
>(inode)->i_rdev == WHITEOUT_DEV)
>
> +#define IS_FSDAX(inode) (IS_ENABLED(CONFIG_FS_DAX) && IS_DAX(inode))
> +
> static inline bool HAS_UNMAPPED_ID(struct inode *inode)
> {
> return !uid_valid(inode->i_uid) || !gid_valid(inode->i_gid);
>
--
Jan Kara
SUSE Labs, CR
n Williams <dan.j.willi...@intel.com>
I wonder how I didn't notice this when reading the original patch. Anyway
the fix looks good. You can add:
Reviewed-by: Jan Kara <j...@suse.cz>
Honza
> ---
> include/linux/fs.h
2bb6d2837083 ("mm: introduce get_user_pages_longterm")
> Cc:
> Reported-by: Gerd Rausch
> Acked-by: Jane Chu
> Reported-by: Haozhong Zhang
> Signed-off-by: Dan Williams
I wonder how I didn't notice this when reading the original patch. Anyway
the fix look
e so that mm/truncate.c drops its link time
> dependencies on fs/dax.c.
>
> Cc: Alexander Viro <v...@zeniv.linux.org.uk>
> Cc: linux-fsde...@vger.kernel.org
> Cc: Christoph Hellwig <h...@lst.de>
> Cc: Jan Kara <j...@suse.cz>
> Cc: <sta...@vger.kernel.org>
e so that mm/truncate.c drops its link time
> dependencies on fs/dax.c.
>
> Cc: Alexander Viro
> Cc: linux-fsde...@vger.kernel.org
> Cc: Christoph Hellwig
> Cc: Jan Kara
> Cc:
> Reported-by: kbuild test robot
> Fixes: dee410792419 ("/dev/dax, core: file op
...@vger.kernel.org
> Cc: Christoph Hellwig <h...@lst.de>
> Cc: Jan Kara <j...@suse.cz>
> Cc: <sta...@vger.kernel.org>
> Fixes: dee410792419 ("/dev/dax, core: file operations and dax-mmap")
> Signed-off-by: Dan Williams <dan.j.willi...@int
ph Hellwig
> Cc: Jan Kara
> Cc:
> Fixes: dee410792419 ("/dev/dax, core: file operations and dax-mmap")
> Signed-off-by: Dan Williams
Looks good. You can add:
Reviewed-by: Jan Kara
Honza
> ---
>
memcgs. From Alibaba request it seems it happens...
Honza
[1] https://lkml.org/lkml/2017/10/27/523
--
Jan Kara <j...@suse.com>
SUSE Labs, CR
memcgs. From Alibaba request it seems it happens...
Honza
[1] https://lkml.org/lkml/2017/10/27/523
--
Jan Kara
SUSE Labs, CR
if (wait_event_freezable(group->fanotify_data.access_waitq,
> + event->response))
> + flush_signals(current);
> + }
Hum, I don't think this is correct either as this way if any signal was
delivered while waiting for fanotify response, we'd just lose it while
previously it has been properly handled. So what I think needs to be done
is that we just use wait_event_freezable() and propagate non-zero return
value (-ERESTARTSYS) up to the caller to handle the signal and restart the
syscall as necessary.
Honza
--
Jan Kara <j...@suse.com>
SUSE Labs, CR
e(group->fanotify_data.access_waitq,
> + event->response))
> + flush_signals(current);
> + }
Hum, I don't think this is correct either as this way if any signal was
delivered while waiting for fanotify response, we'd just lose it while
previously it has been properly handled. So what I think needs to be done
is that we just use wait_event_freezable() and propagate non-zero return
value (-ERESTARTSYS) up to the caller to handle the signal and restart the
syscall as necessary.
Honza
--
Jan Kara
SUSE Labs, CR
etc. Or do you mean that you'd
queue task work for current task and then somehow magically switch memcg
there? In that case this magic switching isn't clear to me...
Honza
--
Jan Kara <j...@suse.com>
SUSE Labs, CR
n that you'd
queue task work for current task and then somehow magically switch memcg
there? In that case this magic switching isn't clear to me...
Honza
--
Jan Kara
SUSE Labs, CR
ating the task_struct?
Yeah, even better, but then we really need to make sure these things stack
properly.
Honza
--
Jan Kara <j...@suse.com>
SUSE Labs, CR
struct field, so it nests.
>
> What do others think?
Sounds nice to me.
> Maybe we can rename task_struct.reclaim_state to `struct task_mm_state
> *task_mm_state", add remote_memcg_to_charge to struct task_mm_state and
> avoid bloating the task_struct?
Yeah, even better, but then we really need to make sure these things stack
properly.
Honza
--
Jan Kara
SUSE Labs, CR
On Mon 19-02-18 21:07:28, Amir Goldstein wrote:
> On Mon, Feb 19, 2018 at 3:50 PM, Jan Kara <j...@suse.cz> wrote:
> [...]
> > For fanotify without FAN_UNLIMITED_QUEUE the situation is similar as for
> > inotify - IMO low practical impact, apps should generally handle queue
On Mon 19-02-18 21:07:28, Amir Goldstein wrote:
> On Mon, Feb 19, 2018 at 3:50 PM, Jan Kara wrote:
> [...]
> > For fanotify without FAN_UNLIMITED_QUEUE the situation is similar as for
> > inotify - IMO low practical impact, apps should generally handle queue
> > overfl
ear whom to
account connector to since it is shared by all events attached to the
inode.
Honza
--
Jan Kara <j...@suse.com>
SUSE Labs, CR
om to
account connector to since it is shared by all events attached to the
inode.
Honza
--
Jan Kara
SUSE Labs, CR
t see how this is not a good thing by default - and if such reaction
is not desirable, there's memcg's oom_control to tune the OOM behavior
which has capabilities far beyond of what we could invent for fanotify...
What do you think Amir?
Honza
--
Jan Kara <j...@suse.com>
SUSE Labs, CR
not a good thing by default - and if such reaction
is not desirable, there's memcg's oom_control to tune the OOM behavior
which has capabilities far beyond of what we could invent for fanotify...
What do you think Amir?
Honza
--
Jan Kara
SUSE Labs, CR
ith freeing its inodes normally AFAICT. I don't see that happening
anywhere in the tree but in theory it is possible with some effort... But
frankly I don't see a good reason for that so all we should do is to
document that .destroy_inode needs to free the inode structure through RCU
if it uses page cache? Al?
Honza
--
Jan Kara <j...@suse.com>
SUSE Labs, CR
mally AFAICT. I don't see that happening
anywhere in the tree but in theory it is possible with some effort... But
frankly I don't see a good reason for that so all we should do is to
document that .destroy_inode needs to free the inode structure through RCU
if it uses page cache? Al?
Honza
--
Jan Kara
SUSE Labs, CR
event->response);
But if the process gets a signal while waiting, we will just livelock the
kernel in this loop as wait_event_freezable() will keep returning
ERESTARTSYS. So you need to be a bit more clever here...
Honza
--
Jan Kara <j...@suse.com>
SUSE Labs, CR
But if the process gets a signal while waiting, we will just livelock the
kernel in this loop as wait_event_freezable() will keep returning
ERESTARTSYS. So you need to be a bit more clever here...
Honza
--
Jan Kara
SUSE Labs, CR
ss_space usage in rcu_read_lock/unlock(). Some comments are
> added in code to make it clear what is protected by the RCU read lock.
>
> Signed-off-by: "Huang, Ying" <ying.hu...@intel.com>
> Cc: Mel Gorman <mgor...@techsingularity.net>
> Cc: Minchan Kim <
ead_lock/unlock(). Some comments are
> added in code to make it clear what is protected by the RCU read lock.
>
> Signed-off-by: "Huang, Ying"
> Cc: Mel Gorman
> Cc: Minchan Kim
> Cc: "Huang, Ying"
> Cc:
grabbed
by this process in __blkdev_put() before calling sync_blockdev().
Honza
--
Jan Kara <j...@suse.com>
SUSE Labs, CR
grabbed
by this process in __blkdev_put() before calling sync_blockdev().
Honza
--
Jan Kara
SUSE Labs, CR
On Thu 08-02-18 15:18:11, Dmitry Vyukov wrote:
> On Thu, Feb 8, 2018 at 3:08 PM, Jan Kara <j...@suse.cz> wrote:
> > On Thu 08-02-18 14:28:08, Dmitry Vyukov wrote:
> >> On Thu, Feb 8, 2018 at 10:28 AM, Jan Kara <j...@suse.cz> wrote:
> >> > On Wed 07-02-18
On Thu 08-02-18 15:18:11, Dmitry Vyukov wrote:
> On Thu, Feb 8, 2018 at 3:08 PM, Jan Kara wrote:
> > On Thu 08-02-18 14:28:08, Dmitry Vyukov wrote:
> >> On Thu, Feb 8, 2018 at 10:28 AM, Jan Kara wrote:
> >> > On Wed 07-02-18 07:52:29, Andi Kleen wro
On Thu 08-02-18 14:28:08, Dmitry Vyukov wrote:
> On Thu, Feb 8, 2018 at 10:28 AM, Jan Kara <j...@suse.cz> wrote:
> > On Wed 07-02-18 07:52:29, Andi Kleen wrote:
> >> > #0: (>bd_mutex){+.+.}, at: [<40269370>]
> >> > __blkdev_put+0xbc/0x7f0
1001 - 1100 of 6478 matches
Mail list logo
