n just leave it as is. Let me ask filesystem and networking
> people:
>
> Is it OK to leave some part of buffer uninitialized with read_iter() or
> recvmsg()?
I think that leaving part of the IO buffer within returned IO length
uninitialized is a very bad practice and I'm not aware of any place in
filesystem area that would do that. It makes life unnecessarily harder
for userspace and also it is invitation for subtle information leaks
(depending on who allocates the buffer and who then gets to read the
results). So I think the patch makes sense.
Honza
--
Jan Kara
SUSE Labs, CR
st insert the thing.. */
> folio_get(folio);
> + if (mkwrite)
> + entry = maybe_mkwrite(mk_pte(page, prot), vma);
> + else
> + entry = mk_pte(page, prot);
I'd prefer:
entry = mk_pte(page, prot);
if (mkwrite)
entry = maybe_mkwrite(entry, vma);
but I don't insist. Also insert_pfn() additionally has pte_mkyoung() and
pte_mkdirty(). Why was it left out here?
Honza
--
Jan Kara
SUSE Labs, CR
(requires CONFIG_QUOTA).
> +
> +noquota option ls silently ignored by ext2.
>
>
> Specification
> --
> 2.20.1
>
>
>
>
--
Jan Kara
SUSE Labs, CR
urity number or whatever), with would be weird, IMO.
>
> As we all use e-mails to uniquely identify contributors submissions,
> IMHO, the best is to keep using e-mails. The side effect is that
> we should keep those emails updated.
Understood but e-mails in code get stale eventually
On Tue 25-07-17 14:15:22, Christoph Hellwig wrote:
> On Tue, Jul 25, 2017 at 11:35:08AM +0200, Jan Kara wrote:
> > On Tue 25-07-17 10:01:58, Christoph Hellwig wrote:
> > > On Tue, Jul 25, 2017 at 01:14:00AM +0300, Kirill A. Shutemov wrote:
> > > > I guess it's up
he process
must run unmap_mapping_range() before installing the new PTE so that all
processes mapping this file offset actually refault and see the new
mapping. So this would go through pte_none() case. Am I missing something?
Honza
--
Jan
On Mon 24-07-17 09:23:57, Ross Zwisler wrote:
> On Mon, Jul 24, 2017 at 01:25:30PM +0200, Jan Kara wrote:
> > > @@ -1658,14 +1658,28 @@ static int insert_pfn(struct vm_area_struct *vma,
> > > unsigned long addr,
> > > if (!pte)
> > > goto o
> Signed-off-by: Ross Zwisler
> Suggested-by: Jan Kara
Looks good. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> fs/dax.c| 34 ++
t from dax.h.
>
> Signed-off-by: Ross Zwisler
> Suggested-by: Jan Kara
Looks good. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> fs/dax.c| 2 +-
> include/linux/dax.h | 2 --
> mm/filemap
helper. We will instead
> use dax_iomap_fault() to handle write-protection faults.
>
> This means that insert_pfn() needs to follow the lead of insert_pfn_pmd()
> and allow us to pass in a 'mkwrite' flag. If 'mkwrite' is set
> insert_pfn() will do the
, so we need to move its definition above all its callers.
>
> Signed-off-by: Ross Zwisler
Looks good. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> fs/dax.c | 138
> +++
therwise the patch looks good to me.
Honza
--
Jan Kara
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri 21-07-17 11:44:05, Ross Zwisler wrote:
> On Wed, Jul 19, 2017 at 03:58:31PM -0600, Ross Zwisler wrote:
> > On Wed, Jul 19, 2017 at 11:51:12AM -0600, Ross Zwisler wrote:
> > > On Wed, Jul 19, 2017 at 04:16:59PM +0200, Jan Kara wrote:
> > > > On Wed 28-06-1
ent' route can we at least add an enum
> like:
>
> enum {
> PTE_MKDIRTY,
> PTE_MKCLEAN,
> };
>
> ...to differentiate the two cases?
So how I usually deal with this is that I create e.g.:
__vm_insert_mixed() that takes the bool argument, make vm_insert_mixe
On Wed 19-07-17 10:26:45, Ross Zwisler wrote:
> On Wed, Jul 19, 2017 at 05:33:14PM +0200, Jan Kara wrote:
> > On Wed 28-06-17 16:01:50, Ross Zwisler wrote:
> > > Another major change is that we remove dax_pfn_mkwrite() from our fault
> > > flow, and instead rely on th
rotected. Then the process writes through mmap to the area - the code
in handle_pte_fault() ends up in do_wp_page() if I'm reading it right.
Then, since we are missing ->pfn_mkwrite() handlers, the PTE will be marked
writeable but radix tree entry stays clean - bug. Am I missing something?
le offset (via
unmap_mapping_range()) before mapping an allocated block there and thus the
case of filling the hole won't be affected by this?
Honza
--
Jan Kara
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri 16-06-17 22:09:26, Ross Zwisler wrote:
> On Thu, Jun 15, 2017 at 04:42:04PM +0200, Jan Kara wrote:
> > On Wed 14-06-17 11:22:09, Ross Zwisler wrote:
> > > To be able to use the common 4k zero page in DAX we need to have our PTE
> > > fault path look more like our
>
> - /* This will replace locked radix tree entry with a hole page */
> - page = find_or_create_page(mapping, vmf->pgoff,
> -vmf->gfp_mask | __GFP_ZERO);
With this gone, you can also remove the special DAX handling from
mm/filemap.c: page_cache_tree_insert() and remove from dax.h
dax_wake_mapping_entry_waiter(), dax_radix_locked_entry() and RADIX_DAX
definitions. Yay! As a separate patch please.
Honza
--
Jan Kara
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
* At this point we are committed to insert_page()
> + * regardless of whether the caller specified flags that
> + * result in pfn_t_has_page() == false.
> + */
> + page = pfn_to_page(pfn_t_to_pfn(pfn));
> + retu
On Fri 12-05-17 11:00:07, Mauro Carvalho Chehab wrote:
> kernel-doc will try to interpret a foo() string, except if
> properly escaped.
>
> Signed-off-by: Mauro Carvalho Chehab
Looks good. You can add:
Reviewed-
ooks good. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> fs/jbd2/transaction.c | 38 +++---
> 1 file changed, 19 insertions(+), 19 deletions(-)
>
> diff --git a/fs/jbd2/transaction.
ese wrappers are no longer used, and are unlikely to be
> used in the future. XFS has had locking analogous to what was recently
> added to ext2 and ext4 since DAX support was initially introduced by:
>
> commit 6b698edeeef0 ("xfs: add DAX file operations support")
&
23 matches
Mail list logo
