The function blkdev_report_zones() returns success even if no zone
information is reported (empty report). Empty zone reports can only
happen if the report start sector passed exceeds the device capacity.
The conditions for this to happen are either a bug in the caller code,
or, a change in the dev
On 4/18/19 11:41 AM, Thomas Gleixner wrote:
> Replace the indirection through struct stack_trace by using the storage
> array based interfaces.
>
> Signed-off-by: Thomas Gleixner
> Acked-by: Dmitry Vyukov
> Cc: Andrey Ryabinin
> Cc: Alexander Potapenko
> Cc: kasan-...@googlegroups.com
> Cc: li
On Thu, Apr 18, 2019 at 4:04 AM Damien Le Moal
wrote:
> The function blkdev_report_zones() returns success even if no zone
> information is reported (empty report). Empty zone reports can only
> happen if the report start sector passed exceeds the device capacity.
> The conditions for this to hap
On Thu, 18 Apr 2019 14:11:44 +0200
Alexander Potapenko wrote:
> On Thu, Apr 18, 2019 at 1:54 PM Thomas Gleixner wrote:
> >
> > On Thu, 18 Apr 2019, Alexander Potapenko wrote:
> > > On Thu, Apr 18, 2019 at 11:06 AM Thomas Gleixner
> > > wrote:
> > > > - save_stack_trace(&b->stack_trac
[ Added Tom Zanussi ]
On Thu, 18 Apr 2019 10:41:39 +0200
Thomas Gleixner wrote:
> The indirection through struct stack_trace is not necessary at all. Use the
> storage array based interface.
>
> Signed-off-by: Thomas Gleixner
> Cc: Steven Rostedt
Looks fine to me
Acked-by: Steven Rostedt
On Thu, 18 Apr 2019 10:41:40 +0200
Thomas Gleixner wrote:
> The per cpu stack trace buffer usage pattern is odd at best. The buffer has
> place for 512 stack trace entries on 64-bit and 1024 on 32-bit. When
> interrupts or exceptions nest after the per cpu buffer was acquired the
> stacktrace len
On Thu, 18 Apr 2019 17:43:59 +0200 (CEST)
Thomas Gleixner wrote:
> On Thu, 18 Apr 2019, Steven Rostedt wrote:
> > On Thu, 18 Apr 2019 10:41:40 +0200
> > Thomas Gleixner wrote:
> > > -static DEFINE_PER_CPU(struct ftrace_stack, ftrace_stack);
> > > +/* This allows 8 level nesting which is plenty
On Thu, Apr 11, 2019 at 12:49:19PM +0200, Martin Wilck wrote:
> A recent bug report revealed that the handling of path priorities is
> inconsistent in multipathd when paths fail. In the current code, depending
> on timing, the prio of a faild path may be reset to 0, reset to -1
> (PRIO_UNDEF), or n
When "multipath -u" is run, it checks if multipathd is running.
Currently it does this by trying to connect to the mutipathd socket.
This can cause problems during boot. The multipathd.socket systemd unit
file will cause "multipath -u" to wait until multipathd has been started
before continuing.
On Wed, Apr 17 2019 at 9:28am -0400,
Bart Van Assche wrote:
> On 4/4/19 9:33 AM, Christoph Hellwig wrote:
> > The sector used here is a little endian value, so use the right
> > type for it.
>
> Hi Christoph,
>
> You may want to fix the spelling of "endianness" in the subject. Anyway:
I fixed
On Thu, 18 Apr 2019 14:58:55 -0500
Tom Zanussi wrote:
> > Tom,
> >
> > Can you review this too?
>
> Looks good to me too!
>
> Acked-by: Tom Zanussi
>
Would you be OK to upgrade this to a Reviewed-by tag?
Thanks!
-- Steve
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.c
Hi Ben,
On Thu, 2019-04-18 at 12:49 -0500, Benjamin Marzinski wrote:
> When "multipath -u" is run, it checks if multipathd is running.
> Currently it does this by trying to connect to the mutipathd socket.
> This can cause problems during boot. The multipathd.socket systemd
> unit
> file will cau
On Thu, 18 Apr 2019 23:14:45 +0200 (CEST)
Thomas Gleixner wrote:
> On Thu, 18 Apr 2019, Josh Poimboeuf wrote:
>
> > On Thu, Apr 18, 2019 at 10:41:20AM +0200, Thomas Gleixner wrote:
> > > - Remove the extra array member of stack_dump_trace[]. It's not required
> > > as
> > > the stack tracer
On Thu, 18 Apr 2019 17:24:43 -0400
Steven Rostedt wrote:
> I believe it was for historical leftovers (there was a time it was
> required), and left there for "paranoid" sake. But let me apply the
> patch and see if it is really needed.
I removed the +1 on the max_entries and set SET_TRACE_ENTRIE
On Thu, 18 Apr 2019 10:41:20 +0200
Thomas Gleixner wrote:
> @@ -412,23 +404,20 @@ stack_trace_sysctl(struct ctl_table *tab
> void __user *buffer, size_t *lenp,
> loff_t *ppos)
> {
> - int ret;
> + int ret, was_enabled;
One small nit. Could this be:
On Fri, 19 Apr 2019 00:44:17 +0200 (CEST)
Thomas Gleixner wrote:
> On Thu, 18 Apr 2019, Steven Rostedt wrote:
> > On Thu, 18 Apr 2019 10:41:20 +0200
> > Thomas Gleixner wrote:
> >
> > > @@ -412,23 +404,20 @@ stack_trace_sysctl(struct ctl_table *tab
> > > void __user *buffer, size
16 matches
Mail list logo
