ow, but they are low enough risk for this late in the cycle and
the fixes have waiting users . They have received a build success
notification from the 0day robot, pass the latest ndctl unit tests,
and appeared in next-20170206.
The following changes since commit 7a308bb3016f57e5be11a677d15b821536419d3
I recently hit an issue in my DAX testing where I was unable to get ext4 to
give me 2 MiB sized and aligned block allocations in a situation where I
thought I should be able to. I'm using a PMEM ramdisk of size 16 GiB, created
using the memmap kernel command line parameter.
# fdisk -l /dev/pmem
On Sun, Feb 05, 2017 at 02:21:44PM +0800, Xiong Zhou wrote:
> Mount TEST_DEV as non-DAX, SCRATCH_DEV as DAX, then
> do some IO between them. In this case we use mmap
> and dio/buffered IO read/write test programme.
>
> Signed-off-by: Ross Zwisler
Yep, this is fine.
> Signed-off-by: Xiong Zhou
On Sun, Feb 05, 2017 at 02:21:43PM +0800, Xiong Zhou wrote:
> In a DAX mountpoint, do IO betwen files with and
> without DAX per-inode flag. We do mmap, both
> O_DIRECT and buffered read/write IO in this case.
> Then test again in the same device without dax
> mountoption.
>
> Add help _require_sc
Missing dummy function native_pud_clear() for 32bit x86 build caught
by 0-day build.
Fix: a10a1701 mm, x86: add support for PUD-sized transparent hugepages
Signed-off-by: Dave Jiang
---
arch/x86/include/asm/pgtable-3level.h |4
1 file changed, 4 insertions(+)
diff --git a/arch/x86/inc
On Mon, Feb 6, 2017 at 9:27 AM, Christoph Hellwig wrote:
> On Mon, Feb 06, 2017 at 08:24:48AM -0800, Dan Williams wrote:
>> > Also can be use this opportunity
>> > to fold ->huge_fault into ->fault?
>>
>> Hmm, yes, just need a scheme to not attempt huge_faults on pte-only handlers.
>
> Do we need
On Mon, Feb 06, 2017 at 08:24:48AM -0800, Dan Williams wrote:
> > Also can be use this opportunity
> > to fold ->huge_fault into ->fault?
>
> Hmm, yes, just need a scheme to not attempt huge_faults on pte-only handlers.
Do we need anything more than checking vma->vm_flags for VM_HUGETLB?
On Mon, Feb 6, 2017 at 6:36 AM, Christoph Hellwig wrote:
> On Fri, Feb 03, 2017 at 02:31:22PM -0700, Dave Jiang wrote:
>> Since the introduction of FAULT_FLAG_SIZE to the vm_fault flag, it has
>> been somewhat painful with getting the flags set and removed at the
>> correct locations. More than on
On Fri, Feb 03, 2017 at 02:31:22PM -0700, Dave Jiang wrote:
> Since the introduction of FAULT_FLAG_SIZE to the vm_fault flag, it has
> been somewhat painful with getting the flags set and removed at the
> correct locations. More than one kernel oops was introduced due to
> difficulties of getting t
On Fri 03-02-17 14:31:22, Dave Jiang wrote:
> Since the introduction of FAULT_FLAG_SIZE to the vm_fault flag, it has
> been somewhat painful with getting the flags set and removed at the
> correct locations. More than one kernel oops was introduced due to
> difficulties of getting the placement cor
10 matches
Mail list logo
