lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 9 Apr 2014 11:26:35 +0200
From:	Jan Kara <jack@...e.cz>
To:	Matthew Wilcox <matthew.r.wilcox@...el.com>
Cc:	linux-fsdevel@...r.kernel.org, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, willy@...ux.intel.com
Subject: Re: [PATCH v7 08/22] Replace xip_truncate_page with dax_truncate_page

On Wed 09-04-14 00:17:59, Jan Kara wrote:
> On Sun 23-03-14 15:08:34, Matthew Wilcox wrote:
> > +/**
> > + * dax_truncate_page - handle a partial page being truncated in a DAX file
> > + * @inode: The file being truncated
> > + * @from: The file offset that is being truncated to
> > + * @get_block: The filesystem method used to translate file offsets to blocks
> > + *
> > + * Similar to block_truncate_page(), this function can be called by a
> > + * filesystem when it is truncating an DAX file to handle the partial page.
> > + *
> > + * We work in terms of PAGE_CACHE_SIZE here for commonality with
> > + * block_truncate_page(), but we could go down to PAGE_SIZE if the filesystem
> > + * took care of disposing of the unnecessary blocks.  Even if the filesystem
> > + * block size is smaller than PAGE_SIZE, we have to zero the rest of the page
> > + * since the file might be mmaped.
>   Well, DAX mmap support pretty much relies on PAGE_CACHE_SIZE == block
> size (we cannot really map only a part of a physical page directly...). So
> the comment seems somewhat misleading.
  I thought about this for a while and classical IO, truncation etc. could
easily work for blocksize < pagesize. And for mmap() you could just use
pagecache. Not sure if it's worth the complications though. Anyway we
should decide whether we don't care about blocksize < PAGE_CACHE_SIZE at
all, or whether we try to make things which can work reasonably easily
functional. In that case dax_truncate_page() needs some tweaking because it
currently assumes blocksize == PAGE_CACHE_SIZE.

								Honza
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
-- 
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ