On Mon, Apr 11, 2016 at 08:50:39PM +0530, Sudip Mukherjee wrote:
> The entry of dm-devel@redhat.com was duplicated and the duplicate entry
> was marked as a Maintainer but it appears from the email address that it
> is a List. So remove the entry of M and only keep the L entry.
M and L are not
On Mon, Apr 11, 2016 at 09:45:01PM +0530, Sudip Mukherjee wrote:
> L stands for "Mailing list that is relevant to this area", and this is a
> mailing list. :)
Your proposed patch isn't changing the L entry, so this is of no relevance.
Alasdair
--
dm-devel mailing list
dm-devel@redhat.com
On Fri, Apr 29, 2016 at 06:59:56PM +0200, hei...@redhat.com wrote:
> + rs->ti->error = "Unable to assemble array: No feature flags supported
> yet";
> + if (le32_to_cpu(sb->features)) /* No features supported yet */
Is it worth splitting this into compat_flags and incompat_flags like we
On Tue, May 03, 2016 at 09:27:32AM -0500, Benjamin Marzinski wrote:
> I don't see why this same issue can't happen for anyone creating any
> type of dm device build out of multiple physical devices, and AFAIK, lvm
> doesn't bother to protect users against this, even though it can now
>
The library functions and return states are supposed to be well-defined.
If you think you've found a cookie leak on an error path within a library
function, we can investigate that and fix the library if need be.
Alasdair
--
dm-devel mailing list
dm-devel@redhat.com
On Wed, May 04, 2016 at 04:23:47PM -0400, Todd Gill wrote:
> I had earlier sent an email to dm-devel proposing we add a feature
> in multipathd to output multipath map topology in JSON format. This
> patch contains to the code for that feature.
> Having an option for the CLI to output in JSON
On Tue, Oct 04, 2016 at 04:39:28PM -0700, Andy Grover wrote:
> devicemapper is using uevents for:
> a. dm-verity detected corruption
> b. dm-multipath: path failed or reinstated
> c. dm device renamed
> d. there's also some use in md and bcache.
>
> devicemapper uses DM_EVENT ioctl (yuck) for:
>
Well to start with some device-mapper basics, looks at the newer files
(e.g. thin-provisioning.txt, cache.txt) in the Documentation directory
to see what format to use and how to document the interface.
Constructor, status, examples using dmsetup only etc.
(BTW We don't use equals signs in our
On Tue, Apr 25, 2017 at 04:31:29PM -0700, Adrian Salido wrote:
> Struct dm_ioctl has some padding/data that is not explicitly cleared
> before copying to user. This can cause kernel stack contents to be
> leaked to user space.
Please be more precise here, explaining which part of the buffer
and
On Tue, Apr 25, 2017 at 05:33:19PM -0700, Adrian Salido wrote:
> it's actually the data portion of the struct under a custom user ioctl
> where (param_kernel->data_size - minimum_data_size) <
> sizeof(param_kernel->data)
> Will update the patch to be clear
Yes - but before updating the patch, we
On Tue, Apr 25, 2017 at 05:33:19PM -0700, Adrian Salido wrote:
> Will update the patch to be clear
So at the moment, we're leaning towards just:
param->data_size = offsetof(struct dm_ioctl, data)
to replace
param->data_size = sizeof(*param);
in the caller.
Alasdair
--
dm-devel mailing
On Thu, May 11, 2017 at 09:49:14PM +0200, Martin Wilck wrote:
> Here is an idea: the best way to avoid the race mentioned by Mike might
> be to set priv->global_event_nr to the highest event nr reported by the
> DM_LIST_DEVICES ioctl when this ioctl returns. DM_LIST_DEVICES would
> then represent
On Thu, May 11, 2017 at 09:30:43PM +0200, Martin Wilck wrote:
> I see - but I don't see yet how the ioctl approach (or the
> close()/open() based one, for that matter) would avoid this race.
> 1) application processes event N
> 2) event N+1 arrives in the kernel
> 3) user space issues ioctl or
On Thu, May 11, 2017 at 10:45:27PM +0200, Martin Wilck wrote:
> Except that it can cause userspace to miss events, as I tried to point
> out in my reply to Mike.
It should never miss new events. Because the calls are separate,
occasionally it might trigger when it didn't need to, but userspace
Some more thoughts with your example, dmsetup might look like:
# dmsetup create --bootformat "lroot:uuid,rw,0 2097152 linear 8:2 0, \
2097152 2097152 linear 8:3 0, 4194304 2097152 linear 8:4 0"
- also supporting creating multiple devices if the semi-colon is used
- colon to separate name from
On Sat, May 06, 2017 at 12:05:57AM +0200, Martin Wilck wrote:
> Introduce a "fake" UUID for these devices to make sure kpartx
> deletes only devices it had created previously. Otherwise kpartx
> might e.g. delete LVM LVs that are inside a device it is trying
> to delete partitions for. It seems to
On Sat, May 06, 2017 at 12:05:49AM +0200, Martin Wilck wrote:
> 3) kpartx should only delete "partitions", which are single-target
> linear mappings into a block device. Other maps should not be touched.
The prefix on the dm device's uuid should guarantee this: all devices
kpartx creates
On Thu, May 04, 2017 at 01:18:41PM +0200, Enric Balletbo Serra wrote:
> I'm wondering if a command line like this would be acceptable.
1) Make sure the implementation continues to support backslash quoting
so that any characters you introduce with special meanings (comma,
semi-colon, double-quote
On Tue, Oct 03, 2017 at 02:08:04PM -0400, Mike Snitzer wrote:
> Not sure why you're putting such value on that behaviour. The earlier
> we catch invalid tables the better off we are. Failing at resume time
> sucks (always has).
Validation code shouldn't be making assumptions about things that
On Mon, Oct 02, 2017 at 10:43:56AM -0400, Mikulas Patocka wrote:
> Here I send a patch that checks invalid limits when the table is loaded
> and aborts the table load ioctl with an error.
The code does not already do this because it needs to avoid unnecessary
failures if any characteristics of
On Fri, Nov 24, 2017 at 04:59:13PM +0800, monty_pa...@sina.com wrote:
> All that we need do is to ensure pool_target registering ops
> is the last ops in dm_thin_init.
Any other targets wrong too? cache? multipath? snapshot?
Alasdair
--
dm-devel mailing list
dm-devel@redhat.com
On Fri, Nov 24, 2017 at 08:29:42AM +, Reshetova, Elena wrote:
> By looking at the code, I don't see where the change in the reference counting
> could have caused this.
The cause was the bug I identified in patch 3, not this patch.
The regression is easily hit - tables that reference the
On Fri, Oct 20, 2017 at 10:37:38AM +0300, Elena Reshetova wrote:
> } else if (dd->dm_dev->mode != (mode | dd->dm_dev->mode)) {
> r = upgrade_mode(dd, mode, t->md);
> if (r)
> return r;
> + refcount_inc(>count);
> }
Missing
On Tue, Dec 12, 2017 at 07:45:56AM -0700, Keith Busch wrote:
> Ah, this device's makers call the "stripe" size what should be called
> "chunk".
If this target is to go anywhere, let's try to define it as 'undoing'
the existing dm-stripe target using primary terminology, field names
etc. as close
On Fri, Aug 03, 2018 at 11:20:34AM -0400, Theodore Y. Ts'o wrote:
> It *used* to be the case that users running RHEL 2 or RHEL 3 could try
> updating to the latest upstream kernel, and everything would break and
> fall apart. This was universally considered to be a failure, and a
> Bad Thing. So
On Fri, Aug 03, 2018 at 01:42:52PM -0700, Linus Torvalds wrote:
> So even in case 2, we do try to avoid versioning. More often we add a
> new flag, and say "hey, if you want the new behavior, use the new flag
> to say so". Not versioning, but explicit "I want the new behavior"
There are spare
On Fri, Aug 03, 2018 at 08:56:36PM +0100, Alasdair G Kergon wrote:
> Anything passing in version 4.37.0 or earlier (which is the version in
If taking this approach, it might be better to use the current version
i.e. where we add the kernel-side fix. IOW anything compiling against
a uapi hea
On Wed, Oct 24, 2018 at 03:24:29PM -0400, Mikulas Patocka wrote:
> What about allocating a big file, using the FIEMAP ioctl to find the
For reference, dmfilemapd in the lvm2 tree (in daemons/) uses FIEMAP
(in libdm/libdm-stats.c) for monitoring I/O by file.
> If you decide that rollback is no
On Tue, Oct 23, 2018 at 02:23:28PM -0700, Paul Lawrence wrote:
> It is planned to use this driver to enable restoration of a failed
> update attempt on Android devices using ext4.
Could you say a bit more about the reason for this new dm target so we
can understand better what parameters you are
On Sat, Feb 23, 2019 at 11:01:45PM +0100, Kurt Garloff wrote:
> Fixing patch is attached. The parser not never get to the third entry ...
Try this.
Alasdair
--- a/tools/dmsetup.c
+++ b/tools/dmsetup.c
@@ -369,7 +369,7 @@ static int _parse_table_lines(struct dm_task *dmt)
do {
On Sat, Feb 23, 2019 at 10:56:59PM +0100, Kurt Garloff wrote:
> if I store device-mapper tables with dmsetup table --concise, I would
> expect that dmsetup create --concise would be able to parse the tables.
That was the intention. Thanks for reporting the bug - fix applied upstream.
Alasdair
On Fri, Nov 15, 2019 at 08:19:53AM -0800, Randy Dunlap wrote:
> BTW, dm-devel@redhat.com seems to be invalid or dead.
Red Hat made a few changes to its mail configuration over the last
week.
If anyone reading this still has problems that might be related to
this, please send me the relevant
On Thu, Feb 06, 2020 at 07:28:04PM -0500, John Dorminy wrote:
> To be clear, I care more about getting the name in kernelspace than
> about getting the UUID in kernelspace. (253:0) is a unique name for
>From the kernel's point of view, it is THE unique and definitive name
for the lifetime of the
On Fri, Feb 07, 2020 at 01:24:33AM +, Alasdair G Kergon wrote:
> In other words, NEVER report name/uuid without ALSO still reporting
> dm_device_name alongside it.
The reason we only log dm_device_name() is because it is the minimum
necessary to uniquely identify the device and tie to
I'm experimenting with ways of recording changes to the udev database so
you can look back at the history of the storage stack on a particular
machine. This is still a work-in-progress, but it's reached a point
where I'd like more people to try it out.
I've written a shell script that records
On Fri, Mar 27, 2020 at 03:50:06PM -0400, Brian McCullough wrote:
> In your instructions, you say to put the "working" script in /usr/sbin,
> while in the udev rule, it is in /sbin/
In Fedora they are the same.
> I tried adding and removing a USB-connected drive, but did not see any
> response
On Thu, May 07, 2020 at 07:05:33PM -0400, Kjetil Orbekk wrote:
> This will track ioerr_cnt on all dm targets and expose it as
> /dm/ioerr_cnt.
How do you propose to use this?
What are you trying to measure and why?
- How exact must the number be to meet your requirements?
Or to put it another
On Sun, May 03, 2020 at 03:02:21PM +0800, Dongyang Zhan wrote:
> I am a security researcher, my name is Dongyang Zhan. I found a potential
> bug in
> /drivers/md/dm-region-hash.c in Linux 4.10.17. I hope you can help me to
> confirm it.
> __rh_alloc() in /drivers/md/dm-region-hash.c
On Mon, Jun 08, 2020 at 04:45:11PM +0800, yangerkun wrote:
> $ sudo dmsetup message dust1 0 listbadblocks
> The following message will appear, listing one bad block number per
Did you consider returning the data directly to the caller so it
can be accessed directly?
(e.g. like @stats_list
On Tue, Dec 22, 2020 at 06:24:09PM +0100, Hannes Reinecke wrote:
> However, lookup_bdev() now always recurses into the filesystem, causing
> multipath to stall in an all-paths-down scenario.
I have not read the background about whatever the new problem is - I'm
jumping in cold seeing this
On Mon, Jul 12, 2021 at 05:49:03PM -0700, Tushar Sugandhi wrote:
> The DM target data measured by IMA subsystem can alternatively
> be queried from userspace by setting DM_IMA_MEASUREMENT_FLAG with
> DM_TABLE_STATUS_CMD.
I was able to try this out - as 'dmsetup measure' - by applying the quick
On Fri, Jan 29, 2021 at 06:40:06PM +0800, Coly Li wrote:
> Recently I receive a report that whole system hung and no response after
> a while with I/O load. The special configuration is the dm thin-pool
> volume is used as the swap partition of the system.
> My questions are,
> - Can a thin-pool
On Wed, Aug 04, 2021 at 11:41:39AM +0200, Christoph Hellwig wrote:
> allows device mapper to use the normal scheme
> of calling add_disk when it is ready to accept I/O.
For clarity, even after this patchset, the device is not ready to accept
I/O when add_disk is called. It is ready to accept I/O
On Wed, Aug 04, 2021 at 11:41:46AM +0200, Christoph Hellwig wrote:
> device mapper is currently the only outlier that tries to call
> register_disk after add_disk, leading to fairly inconsistent state
> of these block layer data structures.
> Note that this introduces a user visible change: the
On Tue, Aug 10, 2021 at 12:31:43AM +0100, Alasdair G Kergon wrote:
> When loading tables, our tools also always refer to devices using
> the 'major:minor' format, which isn't affected, rather than using
Wrong - that is also affecte
On Tue, Aug 10, 2021 at 01:36:08AM +0100, Alasdair G Kergon wrote:
> On Wed, Aug 04, 2021 at 11:41:39AM +0200, Christoph Hellwig wrote:
> > allows device mapper to use the normal scheme
> > of calling add_disk when it is ready to accept I/O.
> For clarity, even after this pa
On Tue, Jul 27, 2021 at 12:18:02PM +0200, Thore Sommer wrote:
> How is the measured uuid created? The format seems to be
> "CRYPT-VERITY-UUID-NAME" where UUID is uuid from the verity device and NAME is
> the device mapper name. Does this naming come from the kernel or
> libcryptsetup?
See
On Tue, Aug 10, 2021 at 03:12:27PM +0200, Peter Rajnoha wrote:
> (I'm not counting the very corner use case of
> 'dmsetup --addnodeoncreate --verifyudev' which now ends up with a dev node
> in /dev that logically returns -ENODEV when accessed instead of zero-sized
> device as it was before.)
On Fri, Oct 08, 2021 at 05:06:26PM +0200, Xose Vazquez Perez wrote:
> Just for subscribers
Although we manually moderate non-subscribers so their messages
do get through, often a bit delayed.
Alasdair
--
dm-devel mailing list
dm-devel@redhat.com
On Tue, Nov 23, 2021 at 02:27:18PM -0800, Akilesh Kailash wrote:
> On Tue, Nov 23, 2021 at 1:03 PM Mikulas Patocka wrote:
> Older devices do not get new kernel features, only LTS updates. On the
> other hand, by having
> it in user-space, we have more control by adding in new features. For
> ex:
On Tue, Nov 23, 2021 at 04:07:21PM -0800, Akilesh Kailash wrote:
> Why not extend dm-snapshot; in that way you can have the existing
> kernel COW format + support compression.
In short, this is quite a focussed requirement and it doesn't seem worth
compromising on the goals by attempting to
On Wed, Nov 24, 2021 at 12:38:31AM +, Alasdair G Kergon wrote:
> There seems to be a general industry movement towards edge, attestation,
> trusted boot, nested systems, confidential computing, containers,
> etc. and I think this type of
> device-mapper target might play a useful
On Tue, Jul 27, 2021 at 12:18:02PM +0200, Thore Sommer wrote:
> No new IMA measurement is generated if dm-verity verification fails. This is
> unfortunate because to make the dm-verity measurements useful we need to be
> notified when hash_failed is set to true. We will need something like
>
On Mon, Jan 24, 2022 at 07:02:09AM -0800, Brian Geffon wrote:
> When a device is being removed with deferred remove it's
> still possible to open and use the device. This change
> introduces a flag called DM_DEFERRED_REMOVE_NO_OPEN_FLAG
> which when used with DM_DEFERRED_REMOVE will cause any
>
On Mon, Jan 24, 2022 at 10:25:47AM -0500, Brian Geffon wrote:
> Thank you for looking at this. There are a few reasons this might be
> useful, the first is if you're trying to speed up a graceful teardown
> of the device by informing userspace that this device is going to be
> removed in the near
On Thu, Aug 25, 2022 at 12:49:06AM +0800, Coly Li wrote:
> 5, reload dm table for dm-0
> # cat dm-table-reload | dmsetup reload /dev/dm-0
> And the content of dm-table-reload is,
> 0 1 linear /dev/dm-0 0
> 1 181065566 linear /dev/dm-0 1
> 1) Does anyone observe or encounter such
Some curious happenings led to the configuration and membership
of the dm-devel mailing list getting wound back to its state in 2004
just over a week ago. It was restored yesterday, but you might want to
look at the list archives to check for any messages you missed:
On Wed, Jun 14, 2023 at 11:12:19AM +0800, baomingtong...@208suo.com wrote:
>在 2023-06-14 10:42，Alasdair G Kergon 写道：
> > Did the patched code compile OK for you?
>Yes!
So what is the definition of DMEMIT that your compiler uses and why?
Alasdair
--
dm-devel mailing l
On Tue, Aug 08, 2023 at 03:45:03PM -0700, Fan Wu wrote:
> On Tue, Jul 25, 2023 at 04:43:48PM -0400, Paul Moore wrote:
> > Where would the finalize() hook be called?
>
> It is in the __bind function in drivers/md/dm.c, calling just before
> rcu_assign_pointer(md->map, (void *)t) which activates
On Wed, Jun 14, 2023 at 10:10:33AM +0800, baomingtong...@208suo.com wrote:
> fix the following coccicheck warning:
> drivers/md/dm-snap-persistent.c:909:14-16: Unneeded variable: "sz".
> - unsigned int sz = 0;
> - return sz;
> + return 0;
Did the patched code compile OK for you?
The
60 matches
Mail list logo
