On Tue, Aug 15, 2017 at 5:27 AM, Jan Kara wrote:
> On Mon 14-08-17 23:12:16, Dan Williams wrote:
>> The mmap syscall suffers from the ABI anti-pattern of not validating
>> unknown flags. However, proposals like MAP_SYNC and MAP_DIRECT need a
>> mechanism to define new behavior that
On Mon, Aug 14, 2017 at 11:46 PM, Oliver wrote:
> On Tue, Aug 15, 2017 at 4:02 PM, kbuild test robot wrote:
[..]
>>114 static const unsigned long *nd_pfn_supported_alignments(void)
>>115 {
>>116 /*
>>117 * This needs to be a
On Mon, Aug 14, 2017 at 11:12 PM, Dan Williams wrote:
> The mmap syscall suffers from the ABI anti-pattern of not validating
> unknown flags. However, proposals like MAP_SYNC and MAP_DIRECT need a
> mechanism to define new behavior that is known to fail on older kernels
On Tue, Aug 15, 2017 at 2:18 AM, Kirill A. Shutemov
wrote:
> On Mon, Aug 14, 2017 at 11:12:22PM -0700, Dan Williams wrote:
>> MAP_DIRECT is an mmap(2) flag with the following semantics:
>>
>> MAP_DIRECT
>> In addition to this mapping having MAP_SHARED semantics,
Dear Linux NVDIMM developers,
We are implementing a kernel module that get_user_pages()s an address
provided by a user-space application. This address is a mmap()-ed region of
a file backed by pmem (XFS with DAX).
It works or successfully gets a kernel virtual address for emulated PMEM
with
On Tue, Aug 15, 2017 at 2:56 PM, Honda Michio wrote:
> Dear Linux NVDIMM developers,
>
> We are implementing a kernel module that get_user_pages()s an address
> provided by a user-space application. This address is a mmap()-ed region of
> a file backed by pmem (XFS with
On Tue, Aug 15, 2017 at 9:28 AM, Andy Lutomirski wrote:
> On Mon, Aug 14, 2017 at 11:12 PM, Dan Williams
> wrote:
>> The mmap syscall suffers from the ABI anti-pattern of not validating
>> unknown flags. However, proposals like MAP_SYNC and MAP_DIRECT
You were right and it perfectly works now (I used "pending" branch of
ndctl). Thanks a lot!
Cheers,
- Michio
On 08/16/2017 12:05 AM, Dan Williams wrote:
On Tue, Aug 15, 2017 at 2:56 PM, Honda Michio wrote:
Dear Linux NVDIMM developers,
We are implementing a kernel
On Wed, Aug 16, 2017 at 1:47 AM, Dan Williams wrote:
> On Mon, Aug 14, 2017 at 11:46 PM, Oliver wrote:
>> On Tue, Aug 15, 2017 at 4:02 PM, kbuild test robot wrote:
> [..]
>>>114 static const unsigned long
Hi Jens,
On Mon, Aug 14, 2017 at 10:17:09AM -0600, Jens Axboe wrote:
> On 08/14/2017 09:38 AM, Jens Axboe wrote:
> > On 08/14/2017 09:31 AM, Minchan Kim wrote:
> >>> Secondly, generally you don't have slow devices and fast devices
> >>> intermingled when running workloads. That's the rare case.
>
On Tue, Aug 15, 2017 at 1:37 AM, Jan Kara wrote:
> On Mon 14-08-17 09:14:42, Dan Williams wrote:
>> On Mon, Aug 14, 2017 at 5:40 AM, Jan Kara wrote:
>> > On Sun 13-08-17 13:31:45, Dan Williams wrote:
>> >> On Sun, Aug 13, 2017 at 2:24 AM, Christoph Hellwig
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
On Tue, Aug 15, 2017 at 9:29 AM, Dan Williams wrote:
> On Tue, Aug 15, 2017 at 5:42 AM, Jan Kara wrote:
>> On Mon 14-08-17 23:12:22, Dan Williams wrote:
>>> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
>>> index
>
> >> Another approach could be to integrate NVDIMM event
> >> monitoring into some other utility, like the rasdaemon. I'm
> >> interested in
> >> your thoughts.
> >
> > Though I'm not sure which (existing or new) utility is appropriate yet.
> > I prefer this
-export-supported-page-size-alignments/20170815-105258
base: https://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git
libnvdimm-for-next
config: powerpc-allmodconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget
https
高级秘书、助理和行政人员技能提高训练营
8月18-19日北京 9月09-10日深圳 9月22-23日上海
行政管理实操训练
8月19-20日北京 9月09-10日深圳 9月23-24日上海
附 件 大 纲
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
When a filesystem sees this flag set it will not allow changes to the
file-offset to physical-block-offset relationship of any extent in the
file. The extent of the extents covered by the global S_IOMAP_SEALED is
filesystem specific. In other words it is similar to the inode-wide
MAP_DIRECT is an mmap(2) flag with the following semantics:
MAP_DIRECT
In addition to this mapping having MAP_SHARED semantics, successful
faults in this range may assume that the block map (logical-file-offset
to physical memory address) is pinned for the lifetime of the mapping.
Changes since v3 [1]:
* Move from an fallocate(2) interface to a new mmap(2) flag and rename
'immutable' to 'sealed'.
* Do not record the sealed state in permanent metadata it is now purely
a temporary state for as long as a MAP_DIRECT vma is referencing the
inode (Christoph)
* Drop the
te to
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Dan-Williams/libnvdimm-export-supported-page-size-alignments/20170815-105258
> base: https://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git
> libnvdimm-for-next
> config:
附件 大纲
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
On Mon, Aug 14, 2017 at 11:12:22PM -0700, Dan Williams wrote:
> MAP_DIRECT is an mmap(2) flag with the following semantics:
>
> MAP_DIRECT
> In addition to this mapping having MAP_SHARED semantics, successful
> faults in this range may assume that the block map (logical-file-offset
> to
On Mon 14-08-17 09:14:42, Dan Williams wrote:
> On Mon, Aug 14, 2017 at 5:40 AM, Jan Kara wrote:
> > On Sun 13-08-17 13:31:45, Dan Williams wrote:
> >> On Sun, Aug 13, 2017 at 2:24 AM, Christoph Hellwig wrote:
> >> > Thay being said I think we absolutely should support
On 15/08/17 12:06, Boaz Harrosh wrote:
> On 14/08/17 19:03, Dan Williams wrote:
>> On Mon, Aug 14, 2017 at 7:04 AM, Boaz Harrosh wrote:
>>>
>>> Thank you Jan, I'm patiently waiting for this MAP_SYNC flag since I asked
>>> for
>>> it in 2014. I'm so glad its time is finally do.
On Mon 14-08-17 23:12:16, Dan Williams wrote:
> The mmap syscall suffers from the ABI anti-pattern of not validating
> unknown flags. However, proposals like MAP_SYNC and MAP_DIRECT need a
> mechanism to define new behavior that is known to fail on older kernels
> without the feature. Use the fact
On Mon 14-08-17 23:12:22, Dan Williams wrote:
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index ff151814a02d..73fdc0ada9ee 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -306,6 +306,7 @@ struct vm_area_struct {
> struct mm_struct
26 matches
Mail list logo