On Fri, Dec 22, 2017 at 12:56 PM, Mikulas Patocka wrote:
>
>
> On Fri, 8 Dec 2017, Dan Williams wrote:
>
>> > > What about memcpy_flushcache?
>> >
>> > but
>> >
>> > - using memcpy_flushcache is overkill if we need just one or two 8-byte
>> > writes to the metadata area. Why
On Fri, 8 Dec 2017, Dan Williams wrote:
> > > What about memcpy_flushcache?
> >
> > but
> >
> > - using memcpy_flushcache is overkill if we need just one or two 8-byte
> > writes to the metadata area. Why not use movnti directly?
> >
>
> The driver performs so many 8-byte moves that the cost
I will give that commit a try. Thanks.
On 12/22/2017 05:00 PM, Bart Van Assche wrote:
> On Fri, 2017-12-22 at 10:53 +0100, Christian Borntraeger wrote:
>> any quick ideas?
>
> Hello Christian,
>
> Was commit afc567a4977b ("dm table: fix regression from improper
> dm_dev_internal.count
>
On Tue, Dec 19 2017 at 4:05pm -0500,
Mike Snitzer wrote:
> These patches enable DM multipath to work well on NVMe over Fabrics
> devices. Currently that implies CONFIG_NVME_MULTIPATH is _not_ set.
>
> But follow-on work will be to make it so that native NVMe multipath
>
On Fri, Dec 22 2017 at 11:00am -0500,
Bart Van Assche wrote:
> On Fri, 2017-12-22 at 10:53 +0100, Christian Borntraeger wrote:
> > any quick ideas?
>
> Hello Christian,
>
> Was commit afc567a4977b ("dm table: fix regression from improper
> dm_dev_internal.count
>
From: Seth Forshee
When looking up a block device by path no permission check is
done to verify that the user has access to the block device inode
at the specified path. In some cases it may be necessary to
check permissions towards the inode, such as allowing
Since 4.15-rc1 I get the following during boot relatively often (but not 100%
reproducable)
Seems to be 2 oopses...
"[5.851954] device-mapper: multipath service-time: version 0.3.0 loaded
"[5.902244] Unable to handle kernel pointer dereference in virtual kernel
address space
"[