Re: [dm-devel] [PATCH 3/3] block: fail writes to read-only devices

On Fri, Jun 2, 2023 at 11:41 AM Christoph Hellwig wrote: > > Except the whole make a thing readonly just for fun is the corner case. > DM does it, and we have a sysfs file to allow it. But the usual > case is that a block device has been read-only all the time, or has > been force to be

Re: [dm-devel] [PATCH 3/3] block: fail writes to read-only devices

On Thu, Jun 1, 2023 at 3:28 AM Christoph Hellwig wrote: > > Note that the last attempt to do this got reverted by Linus in commit > a32e236eb93e ("Partially revert "block: fail op_is_write() requests to > read-only partitions") because device mapper relyied on not enforcing > the read-only state

Re: [dm-devel] [git pull] device mapper changes for 6.3

On Mon, Feb 20, 2023 at 9:31 AM Mike Snitzer wrote: > > - Fix all of DM's checkpatch errors and warnings (famous last words). Actually, I think some of these are potentially actively detrimental. I do *not* believe that we should run checkpatch on existing code, since many of those things are

Re: [dm-devel] [git pull] device mapper changes for 6.1

On Tue, Oct 18, 2022 at 3:11 PM Milan Broz wrote: > > The problem is that ioctl() are often just translated to -EINVAL. Oh, that's absolutely a real problem. Don't use one single error number. Linus -- dm-devel mailing list dm-devel@redhat.com

Re: [dm-devel] [git pull] device mapper changes for 6.1

On Tue, Oct 18, 2022 at 1:29 PM Mikulas Patocka wrote: > > The error string is not intended to be parsed by userspace (I agree that > parsing the error string is a horrible idea, but this is not going to > happen). I am happy we agree on that fundamental issue. But it's also why error strings

Re: [dm-devel] [git pull] device mapper changes for 6.1

On Tue, Oct 18, 2022 at 11:54 AM Linus Torvalds wrote: > > But no, we absolutely do *not* want to emulate that particular horror > anywhere else. Side note: if DM people go "Hmm, a lot of our management really does have the exact same issues as 'mount()' and friends, and doing t

Re: [dm-devel] [git pull] device mapper changes for 6.1

On Tue, Oct 18, 2022 at 11:17 AM Christoph Hellwig wrote: > > On Tue, Oct 18, 2022 at 12:20:50PM -0400, Mike Snitzer wrote: > > > > - Enhance DM ioctl interface to allow returning an error string to > > userspace. Depends on exporting is_vmalloc_or_module_addr() to allow > > DM core to

Re: [dm-devel] [git pull] Additional device mapper changes for 6.0

On Sat, Aug 6, 2022 at 11:30 AM Mike Snitzer wrote: > > > > > Please don't use version numbers for ABI issues. Version numbers are > > for human consumption, nothing more, and shouldn't be used for > > anything that has semantics. > > Yes, I know you mentioned this before and I said I'd look to

Re: [dm-devel] [git pull] Additional device mapper changes for 6.0

On Sat, Aug 6, 2022 at 11:09 AM Linus Torvalds wrote: > > Feature bitmasks work. Version numbers don't. Version numbers > fundamentally break when something is backported or any other > non-linearity happens. Side note: even feature bitmaps should be discouraged as an interface, un

Re: [dm-devel] [git pull] Additional device mapper changes for 6.0

On Fri, Aug 5, 2022 at 12:10 PM Mike Snitzer wrote: > > All said: I think it worthwhile to merge these changes for 6.0, rather > than hold until 6.1, now that we have confidence this _optional_ DM > verity feature is working as expected. Please be aware there was a > small linux-next merge fixup

Re: [dm-devel] [git pull] device mapper fixes for 5.19-rc1

On Wed, Jun 1, 2022 at 1:59 PM Mike Snitzer wrote: > > > - Fix DM core's dm_table_supports_poll to return false if no data > devices. So looking at that one (mainly because of the incomprehensible explanation), I do note: (a)

Re: [dm-devel] [PATCH v2] hex2bin: make the function hex_to_bin constant-time

On Wed, May 4, 2022 at 1:26 PM Linus Torvalds wrote: > > Could be anywhere. Xfinity, Nest WiFi, or the cable router. They all > are doing their own dns thing. > > Probably my cable box, since it's likely the oldest thing in the chain. No, it seems to be my Nest WiFi router. I

Re: [dm-devel] [PATCH v2] hex2bin: make the function hex_to_bin constant-time

On Wed, May 4, 2022 at 1:12 PM Stafford Horne wrote: > > Which version of Fedora? F35 here. But looking further, it's not dnsmasq either. Yes, dnsmasq is built with no-i18n, but as mentioned IDN2 does seem to be enabled, so I think it's just "no i18n messages". It seems to be the upstream dns

Re: [dm-devel] [PATCH v2] hex2bin: make the function hex_to_bin constant-time

On Wed, May 4, 2022 at 12:58 PM Stafford Horne wrote: > > I have uploaded a diff I created here: > https://gist.github.com/54334556f2907104cd12374872a0597c > > It shows the same output. In hex_to_bin itself it seems to only be a difference due to some register allocation (r19 and r3 switched

Re: [dm-devel] [PATCH v2] hex2bin: make the function hex_to_bin constant-time

On Wed, May 4, 2022 at 12:51 PM Linus Torvalds wrote: > > But I don't think that it's the browser, actually. Even 'nslookup' > refuses to touch it with > >** server can't find א.cc: SERVFAIL > > and it seems it's literally the local dns caching (dnsmasq?) Looks like

Re: [dm-devel] [PATCH v2] hex2bin: make the function hex_to_bin constant-time

On Wed, May 4, 2022 at 12:43 PM Jason A. Donenfeld wrote: > > א.cc is correct. If you can't load it, your browser or something in > your stack is broken. It's just google-chrome. And honestly, the last thing I want to ever see is non-ASCII URL's. Particularly from a security person. It's a

Re: [dm-devel] [PATCH v2] hex2bin: make the function hex_to_bin constant-time

On Wed, May 4, 2022 at 3:15 AM Jason A. Donenfeld wrote: > > > Alignment? Compiler bug? HW issue? > > Probably one of those, yea. Removing the instruction addresses, the only > difference between the two compiles is: > https://xn--4db.cc/Rrn8usaX/diff#line-440 Well, that address doesn't work

Re: [dm-devel] [PATCH v2] hex2bin: make the function hex_to_bin constant-time

On Mon, Apr 25, 2022 at 5:07 AM Mikulas Patocka wrote: > > We are subtracting values that are in the 0 ... 255 range. Well, except that's not what the original patch did. It was subtracting values that were in the -128 ... 255 range (where the exact range depended on the sign of 'char'). But

Re: [dm-devel] [PATCH] hex2bin: make the function hex_to_bin constant-time

On Sun, Apr 24, 2022 at 2:37 PM Linus Torvalds wrote: > > Finally, for the same reason - please don't use ">> 8". Because I do > not believe that bit 8 is well-defined in your arithmetic. The *sign* > bit will be, but I'm not convinced bit 8 is. Hmm.. I think it'

Re: [dm-devel] [PATCH] hex2bin: make the function hex_to_bin constant-time

On Sun, Apr 24, 2022 at 1:54 PM Mikulas Patocka wrote: > > + * > + * Explanation of the logic: > + * (ch - '9' - 1) is negative if ch <= '9' > + * ('0' - 1 - ch) is negative if ch >= '0' True, but... Please, just to make me happier, make the sign of 'ch' be something very explicit. Right now

Re: [dm-devel] Intel QAT on A2SDi-8C-HLN4F causes massive data corruption with dm-crypt + xfs

On Mon, Feb 28, 2022 at 3:26 PM Herbert Xu wrote: > > Indeed, qat has been disabled for dm-crypt since > > commit b8aa7dc5c7535f9abfca4bceb0ade9ee10cf5f54 > Author: Mikulas Patocka > Date: Thu Jul 9 23:20:41 2020 -0700 > > crypto: drivers - set the flag CRYPTO_ALG_ALLOCATES_MEMORY > > So

Re: [dm-devel] Intel QAT on A2SDi-8C-HLN4F causes massive data corruption with dm-crypt + xfs

On Mon, Feb 28, 2022 at 12:18 AM Kyle Sanderson wrote: > > Makes sense - this kernel driver has been destroying users for many > years. I'm disappointed that this critical bricking failure isn't > searchable for others. It does sound like we should just disable that driver entirely until it is

Re: [dm-devel] libnvdimm fixes 5.9-rc6

On Sun, Sep 20, 2020 at 11:56 AM Dan Williams wrote: > >You will notice that this branch was rebased this > morning and it has not appeared in -next. I decided to cut short the > soak time because the infinite-recursion regression is currently > crashing anyone attempting to test

Re: [dm-devel] [git pull] device mapper changes for 5.9

On Tue, Aug 18, 2020 at 2:12 PM Ignat Korchagin wrote: > > Additionally if one cares about latency I think everybody really deep down cares about latency, they just don't always know it, and the benchmarks are very seldom about it because it's so much harder to measure. > they will not use HDDs

Re: [dm-devel] [git pull] device mapper changes for 5.9

On Tue, Aug 18, 2020 at 1:40 PM John Dorminy wrote: > >The summary (for my FIO workloads focused on > parallelism) is that offloading is useful for high IO depth random > writes on SSDs, and for long sequential small writes on HDDs. Do we have any non-microbenchmarks that might be somewhat

Re: [dm-devel] [git pull] device mapper changes for 5.9

On Fri, Aug 7, 2020 at 9:03 AM Mike Snitzer wrote: > > - DM crypt improvement to optionally avoid async processing via > workqueues for reads and/or writes -- via "no_read_workqueue" and > "no_write_workqueue" features. This more direct IO processing > improves latency and throughput with

Re: [dm-devel] [git pull] device mapper fixes for 5.6-rc5

On Wed, Mar 4, 2020, 13:23 Mike Snitzer wrote: > > These versions are for userspace's benefit (be it lvm2, cryptsetup, > multipath-tools, etc). But yes, these versions are bogus even for > that -- primarily because it requires userspace to know when a > particular feature/fix it cares about was

Re: [dm-devel] [git pull] device mapper fixes for 5.6-rc5

On Wed, Mar 4, 2020 at 9:03 AM Mike Snitzer wrote: > > - Bump the minor version for DM core and all target versions that have > seen interface changes or important fixes during the 5.6 cycle. Can we please remove these pointless version markers entirely? They make no sense. The kernel doesn't

Re: [dm-devel] [git pull v2] device mapper changes for 5.2

On Thu, May 16, 2019 at 7:32 AM Mike Snitzer wrote: > > Seems you haven't pulled my 'for-5.2/dm-changes' tag from earlier this > week so I've added 4 additional simple commits to this v2 pull. Hmm. Strange. I see your email from three days ago now that you mention it, but I don't recall having

Re: [dm-devel] [git pull] device mapper changes for 4.21

On Sun, Dec 30, 2018 at 11:15 AM Mikulas Patocka wrote: > > But you're right that 2TiB devices are common and that perhaps this option > should go away. 2TiB devices are definitely not common in the one situation where this option might matter: small embedded devices. I don't think the cost of

Re: [dm-devel] [git pull] device mapper changes for 4.20

On Fri, Oct 26, 2018 at 8:28 AM Mike Snitzer wrote: > > git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git > tags/for-4.20/dm-changes Pulled, thanks, Linus -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel

Re: [dm-devel] [git pull] device mapper changes for 4.19

On Fri, Aug 17, 2018 at 11:13 AM Mike Snitzer wrote: > > I should be able to get these tested changes to you early next week. > I'll defer to you on whether to take them for 4.19 or wait. There is absolutely no hurry about this - the comment really was more about a "future development" than

Re: [dm-devel] [git pull] device mapper changes for 4.19

This is only very weakly related to this pull request, but when I look at the diffstat, I note that outside of the Documentation changes, it looks like this: On Thu, Aug 16, 2018 at 1:04 PM Mike Snitzer wrote: > > drivers/md/dm-cache-metadata.c| 13 +- >

Re: [dm-devel] LVM snapshot broke between 4.14 and 4.16

On Fri, Aug 3, 2018 at 12:30 PM Mike Snitzer wrote: > > I was trying to give context for the "best to update lvm2 anyway" > disclaimer that was used. Yeah, it was specious. So I'll apologize for the strong words, and I'll just say - not excuse, but explanation - that this is the *ONE* thing

Re: [dm-devel] LVM snapshot broke between 4.14 and 4.16

On Fri, Aug 3, 2018 at 1:08 PM Alasdair G Kergon wrote: > > 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 header taken from a kernel up to now will see the old behaviour, > but anything

Re: [dm-devel] LVM snapshot broke between 4.14 and 4.16

On Fri, Aug 3, 2018 at 12:18 PM Zdenek Kabelac wrote: > > From my userland POV - leaving kernel write to devices that are supposed to > be read-only 'just because' it's kernel is wrong - the fact it has NOT been > discover for so long means - there are not many users and not many testers of >

Re: [dm-devel] LVM snapshot broke between 4.14 and 4.16

On Fri, Aug 3, 2018 at 12:06 PM Mike Snitzer wrote: > > How does that pass for a fix to this issue? > > That'll unilaterally mark all dm device's readonly. Well, if it wasn't honored before anyway, then... But yes, a much more targeted patch would be preferred. And in fact, maybe the right

Re: [dm-devel] LVM snapshot broke between 4.14 and 4.16

On Fri, Aug 3, 2018 at 11:39 AM Mike Snitzer wrote: > > Please stop with the overreaction and making this something it isn't. It's not an overreaction when people get their scripts broken, and some developers then argue "that's not a serious bug". Guys, this needs to be fixed. With all the

Re: [dm-devel] LVM snapshot broke between 4.14 and 4.16

On Sat, Aug 4, 2018 at 3:03 AM WGH wrote: > > > > The patch works for me. > > However, there's no text messsage in the kernel log, just a traceback. I > think that's because WARN_ONCE is supposed to take condition as a first > argument. Duh. It needs to be WARN_ONCE(1, ...); I obviously didn't

Re: [dm-devel] LVM snapshot broke between 4.14 and 4.16

On Fri, Aug 3, 2018 at 12:06 PM Mike Snitzer wrote: > > But you're making Zdenek's response into mine and threathening to no > longer pull from me. No. I'm *very* unhappy about how you seem to think that Zdenek's response was even half-way ok, and you jumped in when Ted said it wasn't.

Re: [dm-devel] LVM snapshot broke between 4.14 and 4.16

On Fri, Aug 3, 2018 at 11:54 AM Mike Snitzer wrote: > > > As I explained to Ted in my previous reply to this thread: using an lvm2 > that is of the same vintage of the kernel is generally going to provide > a more robust user experience You said that yes. And it is completely irrelevant. The

Re: [dm-devel] LVM snapshot broke between 4.14 and 4.16

[ Dammit. I haven't had to shout and curse at people for a while, but this is ABSOLUTELY THE MOST IMPORTANT THING IN THE UNIVERSE WHEN IT COMES TO SOFTWARE DEVELOPMENT ] On Fri, Aug 3, 2018 at 6:31 AM Zdenek Kabelac wrote: > > IMHO (as the author of fixing lvm2 patch) user should not be

Re: [dm-devel] LVM snapshot broke between 4.14 and 4.16

On Thu, Aug 2, 2018 at 2:39 PM WGH wrote: > > I've just found one public report of this bug, though: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900442 Yeah, it does sound like we should fix this issue. Ilya? Linus -- dm-devel mailing list dm-devel@redhat.com

Re: [dm-devel] LVM snapshot broke between 4.14 and 4.16

On Thu, Aug 2, 2018 at 11:18 AM Ilya Dryomov wrote: > > I think it was my commit 721c7fc701c7 ("block: fail op_is_write() > requests to read-only partitions"). The block layer was previously > allowing non-blkdev_write_iter() writes to read-only disks and > partitions. dm's chunk_io() boils

Re: [dm-devel] LVM snapshot broke between 4.14 and 4.16

On Thu, Aug 2, 2018 at 8:16 AM WGH wrote: > > On 08/02/2018 04:31 PM, Ilya Dryomov wrote: > > > > From a quick look, --permission r sets DM_READONLY_FLAG, which makes dm > > mark the disk read-only with set_disk_ro(dm_disk(md), 1) in do_resume(). > > A bit later it tries to write to the disk from

Re: [dm-devel] [git pull] device mapper fix for 4.18-rc6

On Fri, Jul 20, 2018 at 12:14 PM Mike Snitzer wrote: > > Fix DM writecache target to allow an optional offset to the start of > the data and metadata area. This allows userspace tools (e.g. LVM2) > to place a header and metadata at the front of the writecache device > for its use.

Re: [dm-devel] [git pull] device mapper changes for 4.18

On Tue, Jun 5, 2018 at 1:59 AM Peter Zijlstra wrote: > > We've had a whole bunch of broken. We fixed a pile of them a few > years back but I'm sure that if you look hard you can still find a few. > > The one commit I can readily find is: > > 91f65facba5a ("iommu/amd: Fix

Re: [dm-devel] [git pull] device mapper changes for 4.18

On Mon, Jun 4, 2018 at 2:53 PM Mikulas Patocka wrote: > > I'd be interested - does the kernel deal properly with spurious wake-up? - > i.e. suppose that the kernel thread that I created is doing simething else > in a completely different subsystem - can I call wake_up_process on it? > Could it

Re: [dm-devel] [git pull] device mapper changes for 4.18

On Mon, Jun 4, 2018 at 2:13 PM Mike Snitzer wrote: > > (Mikulas would like to still use swait for the dm-writecache's endio > thread, since endio_thread_wait only has a single waiter. If you already know it has a single waiter, please don't use a queue at all. Just have the "struct task_struct

Re: [dm-devel] [git pull] device mapper changes for 4.18

On Mon, Jun 4, 2018 at 12:59 PM Peter Zijlstra wrote: > > > The below will of course conflict with the merge request under > discussion. Also completely untested. Side note: it's not just swake_up() itself. It's very much the "prepare_to_swait()" logic and the event waiting friends. For a

Re: [dm-devel] [git pull] device mapper changes for 4.18

On Mon, Jun 4, 2018 at 12:37 PM Peter Zijlstra wrote: > > Would it help if we did s/swake_up/swake_up_one/g ? > > Then there would not be an swake_up() to cause confusion. Yes, i think that would already be a big improvement, forcing people to be aware of the exclusive nature. Linus

Re: [dm-devel] [git pull] device mapper changes for 4.18

On Mon, Jun 4, 2018 at 12:09 PM Mike Snitzer wrote: > > Mikulas elected to use swait because of the very low latency nature of > layering ontop of persistent memory. Use of "simple waitqueues" > _seemed_ logical to me. I know. It's actually the main reason I have an almost irrational hatred of

Re: [dm-devel] [git pull] device mapper changes for 4.18

On Mon, Jun 4, 2018 at 11:54 AM Linus Torvalds wrote: > > The swait interface is pure and utter garbage, and I thought we > already agreed to just have a big comment telling people not to use > them. > > That seems to not have happened. .. oh, actually it did, but it was app

Re: [dm-devel] [git pull] device mapper changes for 4.18

On Mon, Jun 4, 2018 at 8:32 AM Mike Snitzer wrote: > > - Export 2 swait symbols for use by the new DM writecache target. I am *EXTREMELY* unhappy with this. The swait interface is pure and utter garbage, and I thought we already agreed to just have a big comment telling people not to use them.

Re: [dm-devel] limits->max_sectors is getting set to 0, why/where? [was: Re: dm: kernel oops by divide error on v4.16+]

On Mon, Apr 9, 2018 at 3:32 PM, Jens Axboe wrote: > > The resulting min/max and friends would have been trivial to test, but > clearly they weren't. Well, the min/max macros themselves actually were tested in user space by me. It was the interaction with the unrelated

Re: [dm-devel] limits->max_sectors is getting set to 0, why/where? [was: Re: dm: kernel oops by divide error on v4.16+]

On mobile, sorry for html crud and top posting, but here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e9092d0d97961146655ce51f43850907d95f68c3 Should fix it. Linus On Mon, Apr 9, 2018, 14:56 Jens Axboe wrote: > On 4/9/18 3:26 PM,

Re: [dm-devel] [git pull] device mapper changes for 4.12

On Tue, May 2, 2017 at 11:58 AM, Mike Snitzer wrote: > > - Add a new DM integrity target that emulates a block device that has > additional per-sector tags that can be used for storing integrity > information. So this one comes with a nice documentation file and

Re: [dm-devel] [git pull] device mapper fixes for 4.10-rc7

On Fri, Feb 3, 2017 at 11:11 AM, Mike Snitzer wrote: > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git > dm-4.10-fixes Hmm. "fatal: Couldn't find remote ref dm-4.10-fixes" Forgot to push? And why

[dm-devel] Can we please make 'allow_discards' the default for dm-crypt?

I really detest our current dm-crypt policy of not allowing discard by default. It has this silly "but but security" reason behind it, but let's face it: if you don't want to do discards for security reasons, then JUST DON'T DO THEM. Or add a "no_discards" option. Because right now, the default