On Mon, Feb 01, 2021 at 11:26:36PM -0600, Benjamin Marzinski wrote:
> On Mon, Feb 01, 2021 at 04:12:34PM +0100, Martin Wilck wrote:
> > On Mon, 2021-02-01 at 22:50 +0800, lixiaokeng wrote:
> > >
> > > > >
> > > > > cli_add_path
> > > > > ->ev_add_path
> > > > > ->add_map_with_path
> > >
On Mon, Feb 01, 2021 at 04:12:34PM +0100, Martin Wilck wrote:
> On Mon, 2021-02-01 at 22:50 +0800, lixiaokeng wrote:
> >
> > > >
> > > > cli_add_path
> > > > ->ev_add_path
> > > > ->add_map_with_path
> > > > ->adopt_paths
> > > > ->pathinfo
> > > >
The 02/01/2021 21:50, Mike Snitzer wrote:
> On Mon, Feb 01 2021 at 1:18pm -0500,
> Sergei Shtepa wrote:
>
> > The 02/01/2021 18:45, Bart Van Assche wrote:
> > > On 1/28/21 9:12 AM, Sergei Shtepa wrote:
> > > > I`m ready to suggest the blk_interposer again.
> > > > blk_interposer allows to
On Thu, Jan 28, 2021 at 09:45:44PM +0100, mwi...@suse.com wrote:
> From: Martin Wilck
>
> glibc's implementation of pthread_cancel() loads symbols from
> libgcc_s.so using dlopen() when pthread_cancel() is called
> for the first time. This happens even with LD_BIND_NOW=1.
> This may imply the
On Thu, Jan 28, 2021 at 09:45:43PM +0100, mwi...@suse.com wrote:
> From: Martin Wilck
>
> With SAS expanders, SAS node names have 3 digits. libmultipath
> would fail to discover the sas_end_device matching a given SCSI
> target in this case. Fix it.
>
> Signed-off-by: Martin Wilck
Reviewed-by:
On Fri, Jan 29, 2021 at 02:27:55PM +0800, Shiyang Ruan wrote:
> With the support of ->rmap(), it is possible to obtain the superblock on
> a mapped device.
>
> If a pmem device is used as one target of mapped device, we cannot
> obtain its superblock directly. With the help of SYSFS, the mapped
On Thu, Jan 28, 2021 at 09:45:41PM +0100, mwi...@suse.com wrote:
> From: Martin Wilck
>
> Hi Christophe, hi Ben,
>
> here are 3 patches I'd like to get reviewed before we create a pull
> request. The first two are related to complex SAS setups, the second
> one is to avoid accessing the root
On Fri, Jan 29, 2021 at 02:27:56PM +0800, Shiyang Ruan wrote:
> This function is used to handle errors which may cause data lost in
> filesystem. Such as memory failure in fsdax mode.
>
> In XFS, it requires "rmapbt" feature in order to query for files or
> metadata which associated to the
On Thu, Jan 28, 2021 at 09:45:42PM +0100, mwi...@suse.com wrote:
> From: Martin Wilck
>
> On SAS expanders, node id's have 3 digits. sysfs paths look like this:
>
>
The 02/01/2021 18:45, Bart Van Assche wrote:
> On 1/28/21 9:12 AM, Sergei Shtepa wrote:
> > I`m ready to suggest the blk_interposer again.
> > blk_interposer allows to intercept bio requests, remap bio to
> > another devices or add new bios.
> >
> > This version has support from device mapper.
>
On Mon, 2021-02-01 at 22:50 +0800, lixiaokeng wrote:
>
> > >
> > > cli_add_path
> > > ->ev_add_path
> > > ->add_map_with_path
> > > ->adopt_paths
> > > ->pathinfo
> > > ->filter_property
> > > ->return PATHINFO_SKIPPED,
> > >
On Mon, Feb 01 2021 at 1:18pm -0500,
Sergei Shtepa wrote:
> The 02/01/2021 18:45, Bart Van Assche wrote:
> > On 1/28/21 9:12 AM, Sergei Shtepa wrote:
> > > I`m ready to suggest the blk_interposer again.
> > > blk_interposer allows to intercept bio requests, remap bio to
> > > another devices or
On Mon, 2021-02-01 at 19:49 +0800, lixiaokeng wrote:
>
>
> On 2021/2/1 19:16, Martin Wilck wrote:
> > I don't understand. All callers (uev_add_path(), cli_add_path(),
> > check_path()) call pathinfo() first, which would return
> > PATHINFO_SKIPPED if the path was blacklisted. How do you end up
On 1/28/21 9:12 AM, Sergei Shtepa wrote:
I`m ready to suggest the blk_interposer again.
blk_interposer allows to intercept bio requests, remap bio to
another devices or add new bios.
This version has support from device mapper.
For the dm-linear device creation command, the `noexcl` parameter
Hello lixiaokeng,
On Sun, 2021-01-31 at 18:55 +0800, lixiaokeng wrote:
> When find_multipaths is no and add local path by multiapthd,
> the local path will be filtered by filter_property. The
> pp->mpp is not set in adopt_paths. Then the pp->mpp will be
> dereferenced in get_be6.
>
> Here add
On Sun, 2021-01-31 at 18:59 +0800, lixiaokeng wrote:
> Hi Martin,
> The local disks will not be a multipath device. Is it?
It depends on your configuration.
Regards
Martin
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
>>
>> cli_add_path
>> ->ev_add_path
>> ->add_map_with_path
>> ->adopt_paths
>> ->pathinfo
>> ->filter_property
>> ->return PATHINFO_SKIPPED,
>> ->pp->mpp is NULL and not be set
>> ->return 0
>
> This returns 0,
On Sat, Jan 30, 2021 at 03:56:46AM +, Matthew Wilcox wrote:
> On Tue, Jan 26, 2021 at 03:52:34PM +0100, Christoph Hellwig wrote:
> > bio_kmalloc shares almost no logic with the bio_set based fast path
> > in bio_alloc_bioset. Split it into an entirely separate implementation.
> >
> >
On 2021/2/1 19:16, Martin Wilck wrote:
> I don't understand. All callers (uev_add_path(), cli_add_path(),
> check_path()) call pathinfo() first, which would return
> PATHINFO_SKIPPED if the path was blacklisted. How do you end up
> in ev_add_path() with a blacklisted path?
>
> And how is it
Hello,
Tested with 5.4/5.8/5.11-rc4 with same problems - all cores 100% in WA.
Please check this:
https://launchpadlibrarian.net/520192412/5.8_kernel_2021-01-29%2013-44-35.png
nvme0n1 259:0 0 465,8G 0 disk
├─nvme0n1p1 259:1 0 512M 0 part /boot/efi
├─nvme0n1p2 259:2 0 732M 0 part /boot
Hi Christoph,
I tried with latest for-5.12/block branch, and got below issue when
trying to create raid1 array.
[ 80.605832] BUG: kernel NULL pointer dereference, address:
0018
[ 80.606159] #PF: supervisor read access in kernel mode
[ 80.606159] #PF: error_code(0x) -
On Thu, Jan 14, 2021 at 01:00:49PM -0500, Mike Snitzer wrote:
> On Tue, Dec 29 2020 at 3:55am -0500,
> Satya Tangirala wrote:
>
> > Update the device-mapper core to support exposing the inline crypto
> > support of the underlying device(s) through the device-mapper device.
> >
> > This works
Introduce blk_ksm_update_capabilities() to update the capabilities of
a keyslot manager (ksm) in-place. The pointer to a ksm in a device's
request queue may not be easily replaced, because upper layers like
the filesystem might access it (e.g. for programming keys/checking
capabilities) at the
Update the device-mapper core to support exposing the inline crypto
support of the underlying device(s) through the device-mapper device.
This works by creating a "passthrough keyslot manager" for the dm
device, which declares support for encryption settings which all
underlying devices support.
dm-linear and dm-flakey obviously can pass through inline crypto support.
Co-developed-by: Eric Biggers
Signed-off-by: Eric Biggers
Signed-off-by: Satya Tangirala
---
drivers/md/dm-flakey.c | 4 +++-
drivers/md/dm-linear.c | 5 +++--
2 files changed, 6 insertions(+), 3 deletions(-)
diff
This patch series adds support for inline encryption to the device mapper.
Patch 1 introduces the "passthrough" keyslot manager.
The regular keyslot manager is designed for inline encryption hardware that
have only a small fixed number of keyslots. A DM device itself does not
actually have only
26 matches
Mail list logo
