linux-ext4 - Re: [PATCH 0/9 v4] ext4: Punch hole and DAX fixes

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 10 Dec 2015 11:26:42 -0500
From:	Theodore Ts'o <tytso@....edu>
To:	Ross Zwisler <ross.zwisler@...ux.intel.com>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: [PATCH 0/9 v4] ext4: Punch hole and DAX fixes

On Wed, Dec 09, 2015 at 04:55:18PM -0700, Ross Zwisler wrote:
> Hey Ted,
> 
> I'm working on some fsync/msync patches that I'm hoping to merge for v4.5 and
> my patches build upon the work done in this series by Jan.
> 
> I see Jan's patches in your dev branch - do you expect that branch to be part
> of a pull request (are the commit IDs stable)?  Or will patches from the dev
> branch get moved into another branch before you send the pull request to
> Linus?

Thanks for asking.  I assume your work is not just ext4 specific (in
which I could just manage it using patches in the ext4 patch queue).,
but where you want to start a git tree and then push to Linus
independently, yes?

> I'm just trying to figure out what I should use as a baseline for my changes
> since I need to build on Jan's patches but obviously don't want to include new
> ext4 code with my pull request (which I will send after you send yours). :)

Please use the "master" branch from the ext4 tree as your baseline.
Normally dev is a rewinding branch, but for these sorts of situations
I'll guarantee that everything between origin..master will be stable,
while commits between master..dev may be rewound or dropped to fix
bugs/regressions:

* dde86e3 - (HEAD -> guilt/origin, dev) ext4 crypto: add missing locking for keyring_key access (10 hours ago)
* 0969c39 - ext4 crypto: add ioctls to allow backup of encryption metadata (10 hours ago)
* 843848f - ext4 crypto: add ciphertext_access mount option (10 hours ago)
* ba5843f - (master) ext4: use pre-zeroed blocks for DAX page faults (3 days ago)
* c86d8db - ext4: implement allocation of pre-zeroed blocks (3 days ago)
* 53085fa - ext4: provide ext4_issue_zeroout() (3 days ago)
* 2dcba47 - ext4: get rid of EXT4_GET_BLOCKS_NO_LOCK flag (3 days ago)
* e74031f - ext4: document lock ordering (3 days ago)
* 0112784 - ext4: fix races of writeback with punch hole and zero range (3 days ago)
* 32ebffd - ext4: fix races between buffered IO and collapse / insert range (3 days ago)
* 17048e8 - ext4: move unlocked dio protection from ext4_alloc_file_blocks() (3 days ago)
* ea3d720 - ext4: fix races between page faults and hole punching (3 days ago)

Jan's patches have gone through multiple rounds of testing and I'm
quite confident there are no bugs or regressions that can't be dealt
with using follow up patches.

Cheers,

							- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html