On Wed, 2018-08-01 at 15:57 -0500, Benjamin Marzinski wrote:
> when tur_thread() was calling tur_check(), it was passing ct->message as
> the copy argument, but copy_msg_to_tcc() was assuming that it was
> getting a tur_checker_context pointer. This means it was treating
> ct->message as ct. This
On Wed, 2018-08-01 at 15:57 -0500, Benjamin Marzinski wrote:
> I realize that this locking was added to make an analyzer happy,
> presumably because sometimes ct->devt was being accessed while ct->devt
> was held, and sometimes not. The tur checker locking will be cleaned
> up in a later patch to
On Sat, Aug 04 2018 at 1:04pm -0400,
Linus Torvalds wrote:
> 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
On Sat, Aug 04 2018 at 1:20am -0400,
Theodore Y. Ts'o wrote:
> On Fri, Aug 03, 2018 at 03:30:37PM -0400, Mike Snitzer wrote:
> >
> > I was trying to give context for the "best to update lvm2 anyway"
> > disclaimer that was used. Yeah, it was specious.
>
> Well, it seemed to indicate a
On Fri, Aug 03, 2018 at 03:30:37PM -0400, Mike Snitzer wrote:
>
> I was trying to give context for the "best to update lvm2 anyway"
> disclaimer that was used. Yeah, it was specious.
Well, it seemed to indicate a certain attitude that both Linus and I
are concerned about. I tried to use more
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
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
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
>
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
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
In the quest to remove all stack VLA usage from the kernel[1], this uses
the newly defined max alignment to perform unaligned hashing to avoid
VLAs, and drops the helper function while adding sanity checks on the
resulting buffer sizes. Additionally, the __aligned_largest macro is
removed since
From: Ard Biesheuvel
In the quest to remove all stack VLA usage from the kernel[1], this drops
AHASH_REQUEST_ON_STACK by preallocating the ahash request area combined
with the skcipher area (which are not used at the same time).
[1]
In the quest to remove all stack VLA usage from the kernel[1], this
uses the upper bounds on blocksize. Since this is always a cipher
blocksize, use the existing cipher max blocksize.
[1]
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
Signed-off-by:
In the quest to remove all stack VLA usage from the kernel[1], this
caps the skcipher request size similar to other limits and adds a sanity
check at registration. Looking at instrumented tcrypt output, the largest
is for lrw:
crypt: testing lrw(aes)
crypto_skcipher_set_reqsize: 8
On Thu, Aug 02 2018, Guilherme G. Piccoli wrote:
> On 01/08/2018 22:51, NeilBrown wrote:
>>> [...]
>> If you have hard drive and some sectors or track stop working, I think
>> you would still expect IO to the other sectors or tracks to keep
>> working.
>>
>> For this reason, the behaviour of
On Wed, 2018-08-01 at 18:03 -0700, Dmitry Torokhov wrote:
> I put the first 3 patches into an immutable branch off 4.17:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git ib/4.17-
> bitmap
Thank you!
--
Andy Shevchenko
Intel Finland Oy
--
dm-devel mailing list
This patch adds a new path wildcard 'P', that will print the path's
protocol. For scsi devices, it will additionally print the transport
protocol being used.
Reviewed-by: Martin Wilck
Signed-off-by: Benjamin Marzinski
---
libmultipath/print.c | 43 +++
dm_devn shouldn't be returning success if you can't create a dm task to
find the device info. Found by coverity.
Signed-off-by: Benjamin Marzinski
---
kpartx/devmapper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kpartx/devmapper.c b/kpartx/devmapper.c
index
since vector_foreach_slot() already checks if the entry is NULL, there's
no point in checking it in the loop, since it can't be NULL there. Found
by coverity.
Signed-off-by: Benjamin Marzinski
---
libmultipath/print.c | 8
1 file changed, 8 deletions(-)
diff --git
Multiple users have requested an easy way to setup blacklists that do
things such as blacklisting all non FC and iSCSI devices. Currently
there is no easy way to do this, without knowing in advance what the
devices are. Looking into the udev property values, I didn't see a
consistent set of
an open() failure for fd_dasd will return -1, not 0. Also, cast blocksize
to a uint64_t to keep coverity from complaining about sign extension issues.
Signed-off-by: Benjamin Marzinski
---
kpartx/dasd.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/kpartx/dasd.c
Reviewed-by: Martin Wilck
Signed-off-by: Benjamin Marzinski
---
libmultipath/structs.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/libmultipath/structs.h b/libmultipath/structs.h
index ca14315..0a2623a 100644
--- a/libmultipath/structs.h
+++ b/libmultipath/structs.h
@@ -58,7 +58,6 @@
If the tur checker is run, and the tur_thread has timed out,
libcheck_check() doesn't actually check if the thread is still running.
This means that the thread could have already completed successfully,
but the tur checker would still return PATH_TIMEOUT, instead of the
value returned by the
In update_multipath(), conf is set again in a couple of lines, and
nothing uses it before then, so there's no point in setting it twice.
Also, in ev_remove_path(), strncpy() could end up unterminated, so
use strlcpy() instead.
Signed-off-by: Benjamin Marzinski
---
multipathd/main.c | 4 ++--
1
This batch of patches is a resend of my previous 10 patches, as well
as new patches mostly found by running coverity.
patches 0001-0010 are identical to my previous patchset
patches 0012-0015 & 0021-0032 are minor issues found by coverity.
Not all of them are bugs that could actually
tur_devt() locks ct->lock. However, it is ocassionally called while
ct->lock is already locked. In reality, there is no reason why we need
to lock all the accesses to ct->devt. The tur checker only needs to
write to this variable one time, when it first gets the file descripter
that it is
There are only three variables whose access needs to be synchronized
between the tur thread and the path checker itself: state, message, and
active. The rest of the variables are either only written when the tur
thread isn't running, or they aren't accessed by the tur thread, or they
are atomics
These are tests to validate the filter_* blacklist functions. They not
only verify that the device is correctly blacklisted/whitelisted, but
they also verify the log messages that are printed out.
Reviewed-by: Martin Wilck
Signed-off-by: Benjamin Marzinski
---
tests/Makefile| 4 +-
After the call to make_prefixed_uuid() allocs uuid, it must be freed if
dm_find_part() fails.
Signed-off-by: Benjamin Marzinski
---
kpartx/devmapper.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/kpartx/devmapper.c b/kpartx/devmapper.c
index f94d70e..cd33449
Commit d3b71498 stopped multipath from setting conf->version. Instead,
it was always being set to 0.0.0. Multipathd was still setting this
correctly.
Fixes: d3b71498 "multipath: fix rcu thread cancellation hang"
Reviewed-by: Martin Wilck
Signed-off-by: Benjamin Marzinski
---
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Xose Vazquez Perez
[ Upstream commit 37b37d2609cb0ac267280ef27350b962d16d272e ]
SGI/TP9100 is not an RDAC array:
^^^
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Xose Vazquez Perez
[ Upstream commit 37b37d2609cb0ac267280ef27350b962d16d272e ]
SGI/TP9100 is not an RDAC array:
^^^
On Wed 01-08-18 10:48:00, jing xia wrote:
> We reproduced this issue again and found out the root cause.
> dm_bufio_prefetch() with dm_bufio_lock enters the direct reclaim and
> takes a long time to do the soft_limit_reclaim, because of the huge
> number of memory excess of the memcg.
> Then, all
On 7/30/2018 12:15 AM, Huaisheng Ye wrote:
Applied
From: Huaisheng Ye
Changes since v2 [2]:
* Collect Martin and Mike's acks for dcssblk and dm-writecache;
* Rebase the series of patch to v4.18-rc7.
Changes since v1 [1]:
* Involve the previous patches for pfn can be NULL.
* Reword the patch
34 matches
Mail list logo
