On 12/14/2016 03:01 AM, Mauricio Faria de Oliveira wrote:
In alloc_path_with_pathinfo(), if the 'pp_ptr' argument is NULL
(which is acceptable and checked in the function in two places)
the 'pp' pointer is lost as it is not referenced anywhere else;
thus the memory allocated for it is leaked.
So
On 12/14/2016 03:02 AM, Mauricio Faria de Oliveira wrote:
Currently, multipath still prints the 'spurious uevent, path not found'
message if a path is blacklisted by something different than a devnode
in the 'change' uevent handling. (uev_trigger() calls filter_devnode()).
Thus blacklisting by v
On 12/14/2016 03:02 AM, Mauricio Faria de Oliveira wrote:
The udev property blacklisting is ignored on 'add' uevents
because uev_add_path() calls pathinfo() directly - but the
filter_property() check is only performed in path_discover().
So, move the call out from path_discover() into pathinfo()
Hi,
Recently I met a problem with descrptions below:
When /etc/multipath.conf was configured "path_checker" with
readsector0 and passed in BUFFER_SIZE 4096 to
sg_read() as below:
int libcheck_check (struct checker * c)
{
unsigned char buf[4096];
Currently, multipath still prints the 'spurious uevent, path not found'
message if a path is blacklisted by something different than a devnode
in the 'change' uevent handling. (uev_trigger() calls filter_devnode()).
Thus blacklisting by vendor/product, wwid, and udev property still get
that messag
In alloc_path_with_pathinfo(), if the 'pp_ptr' argument is NULL
(which is acceptable and checked in the function in two places)
the 'pp' pointer is lost as it is not referenced anywhere else;
thus the memory allocated for it is leaked.
So, call free_path() in the case 'pp_ptr' is NULL too.
Signed
The udev property blacklisting is ignored on 'add' uevents
because uev_add_path() calls pathinfo() directly - but the
filter_property() check is only performed in path_discover().
So, move the call out from path_discover() into pathinfo().
Since path_discover() always calls pathinfo() to return,
Ben,
On 12/13/2016 07:50 PM, Benjamin Marzinski wrote:
[snip] I don't see why the udev_device_ref/unref
is necessary. While servicing uevents, when we first get the udevice
from udev_monitor_receive_device() in uevent_listen() it comes with a
reference. After we finish servicing the uevent, we d
On Tue, 2016-12-13 at 11:14 +0100, Michal Hocko wrote:
> Are there any more comments or objections to this patch? Is this a good
> start or kv[mz]alloc has to provide a way to cover GFP_NOFS users as
> well in the initial version.
Did Andrew Morton ever comment on this?
I believe he was the primar
Hi,
On Mon, Dec 12, 2016 at 4:08 PM, Doug Anderson wrote:
> OK, so I just put a printk in wait_iff_congested() and it didn't show
> me waiting for the timeout (!). I know that I saw
> wait_iff_congested() in the originally reproduction of this problem,
> but it appears that in my little "balloon
On Tue, Dec 13, 2016 at 04:27:09PM -0200, Mauricio Faria de Oliveira wrote:
Thanks for working on this. I like this version much better, but I still
have some issues. First off, I don't see why the udev_device_ref/unref
is necessary. While servicing uevents, when we first get the udevice
from udev
On Dec 13, 2016, at 3:14 AM, Michal Hocko wrote:
>
> Are there any more comments or objections to this patch? Is this a good
> start or kv[mz]alloc has to provide a way to cover GFP_NOFS users as
> well in the initial version.
I'm in favour of this cleanup as a starting point. I definitely agre
There's no need to create a tautology by introducing a new device health char
'J',
because the position of the status line field uniquely defines the char refering
to the journal.
This patch is on top of
"[PATCH v2] dm raid: add raid4/5/6 journaling support"
dated 11/30/2016.
Related: rhbz140019
In alloc_path_with_pathinfo(), if the 'pp_ptr' argument is NULL
(which is acceptable and checked in the function in two places)
the 'pp' pointer is lost as it is not referenced anywhere else;
thus the memory allocated for it is leaked.
So, call free_path() in the case 'pp_ptr' is NULL too.
Signed
Currently, multipath still prints the 'spurious uevent, path not found'
message if a path is blacklisted by something different than a devnode
in the 'change' uevent handling. (uev_trigger() calls filter_devnode()).
Thus blacklisting by vendor/product, wwid, and udev property still get
that messag
Ben,
On 12/12/2016 01:20 PM, Mauricio Faria de Oliveira wrote:
On 12/12/2016 12:23 PM, Benjamin Marzinski wrote:
Why don't we just call pathinfo here? I see that you set the pathvec to
NULL so that you don't actually store the path, but this sure does a lot
of unnecessary work before failing. A
Are there any more comments or objections to this patch? Is this a good
start or kv[mz]alloc has to provide a way to cover GFP_NOFS users as
well in the initial version.
On Thu 08-12-16 11:33:00, Michal Hocko wrote:
> From: Michal Hocko
>
> Using kmalloc with the vmalloc fallback for larger allo
On 12/13/2016 09:49 AM, Binoy Jayan wrote:
> Currently, the iv generation algorithms are implemented in dm-crypt.c.
> The goal is to move these algorithms from the dm layer to the kernel
> crypto layer by implementing them as template ciphers so they can be
> implemented in hardware for performance
Currently, the iv generation algorithms are implemented in dm-crypt.c.
The goal is to move these algorithms from the dm layer to the kernel
crypto layer by implementing them as template ciphers so they can be
implemented in hardware for performance. As part of this patchset, the
iv-generation code
===
GENIV Template cipher
===
Currently, the iv generation algorithms are implemented in dm-crypt.c. The goal
is to move these algorithms from the
20 matches
Mail list logo
