t able to reproduce the hang, but this looks correct, and it
passed my tests.
Reviewed-by: Omar Sandoval
> ---
> v2:
> - Change the commit message
> - Change from sbitmap::depth to 2^sbitmap::shift
> ---
> block/kyber-iosched.c | 29 +
> 1 file cha
On Thu, Oct 22, 2020 at 12:45:25PM -0600, Logan Gunthorpe wrote:
>
> On 2020-10-08 10:40 a.m., Logan Gunthorpe wrote:
> > Hi,
> >
> > This series adds blktests for the nvmet passthru feature that was merged
> > for 5.9. It's been reconciled with Sagi's blktest series that Omar
> > recently merged
On Mon, Sep 07, 2020 at 10:41:16AM -0600, Jens Axboe wrote:
> CC Omar
>
> On 9/7/20 1:43 AM, Yang Yang wrote:
> > Kernel crash when requeue flush request.
> > It can be reproduced as below:
> >
> > [2.517297] Unable to handle kernel paging request at virtual address
> > ffd8071c0b00
> >
On Sat, Mar 16, 2019 at 04:24:37PM +0800, Shenghui Wang wrote:
> "sbitmap_batch_clear" should be "sbitmap_deferred_clear"
Acked-by: Omar Sandoval
> Signed-off-by: Shenghui Wang
> ---
> include/linux/sbitmap.h | 2 +-
> 1 file changed, 1 insertion(+), 1 de
On Mon, Jan 28, 2019 at 04:24:27PM -0500, Dennis Zhou wrote:
> It is very easy to miss places that rely on a certain bitshifting for
> decyphering the type_level overloading. Make macros handle this instead.
>
> Signed-off-by: Dennis Zhou
> ---
> fs/btrfs/compression.c | 2 +-
> fs/btrfs/compres
On Tue, Jan 22, 2019 at 04:21:04PM +0100, Greg Kroah-Hartman wrote:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Cc: "Ed L. Cashin"
> Cc: Jens Axboe
On Sat, Dec 22, 2018 at 08:03:54AM -0200, Marcos Paulo de Souza wrote:
> Instead of just using plain '1', as it improves readability.
>
> Signed-off-by: Marcos Paulo de Souza
> ---
> include/linux/blk_types.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux
On Thu, Dec 06, 2018 at 11:07:46AM -0500, Steven Sistare wrote:
> On 11/27/2018 8:19 PM, Omar Sandoval wrote:
> > On Tue, Nov 27, 2018 at 10:16:56AM -0500, Steven Sistare wrote:
> >> On 11/9/2018 7:50 AM, Steve Sistare wrote:
> >>> From: Steve Sistare
> >&g
On Fri, Nov 30, 2018 at 04:32:40AM -0500, Huijin Park wrote:
> From: "huijin.park"
>
> This patch changes the 'sectors' type to an u64.
> In 32 bit system, the 'sectors' can accumulate up to about 2TiB.
> If a 32 bit system makes i/o over 2TiB while running,
> the 'sectors' will overflow.
> As a
On Tue, Nov 27, 2018 at 10:16:56AM -0500, Steven Sistare wrote:
> On 11/9/2018 7:50 AM, Steve Sistare wrote:
> > From: Steve Sistare
> >
> > Provide struct sparsemask and functions to manipulate it. A sparsemask is
> > a sparse bitmap. It reduces cache contention vs the usual bitmap when many
>
On Fri, Oct 05, 2018 at 03:47:21PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the akpm-current tree got a conflict in:
>
> include/linux/swap.h
>
> between commit:
>
> 0f83d16b8f1f ("mm: split SWP_FILE into SWP_ACTIVATED and SWP_FS")
>
> from the btrfs-kdave t
On Fri, Sep 28, 2018 at 11:11:24AM +1000, Stephen Rothwell wrote:
> Hi Jens,
>
> After merging the block tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
>
> block/kyber-iosched.c:84:22: warning: integer overflow in expression of type
> 'long int' results in '7050
On Wed, Sep 26, 2018 at 04:35:45PM +0800, zhong jiang wrote:
> Trival cleanup, list_move_tail will implement the same function that
> list_del() + list_add_tail() will do. hence just replace them.
>
> Signed-off-by: zhong jiang
> ---
> fs/btrfs/send.c | 3 +--
> 1 file changed, 1 insertion(+), 2
we did not find any entry in the previous iteration
>
> Reset 'm' to NULL in that case at Omar Sandoval's suggestion.
>
> Fixes: bf991c2231117 ("proc/kcore: optimize multiple page reads")
Reviewed-by: Omar Sandoval
Thanks again for catching this!
> Si
On Wed, Aug 29, 2018 at 06:04:07AM +0200, Dominique Martinet wrote:
> The 'm' kcore_list item can point to kclist_head, and it is incorrect to
> look at m->addr / m->size in this case.
> There is no choice but to run through the list of entries for every address
> if we did not find any entry in th
From: Omar Sandoval
kclist_add() is only called at init time, so there's no point in
grabbing any locks. We're also going to replace the rwlock with a rwsem,
which we don't want to try grabbing during early boot.
While we're here, mark kclist_add() with __init so that we
From: Omar Sandoval
Now we only need kclist_lock from user context and at fs init time, and
the following changes need to sleep while holding the kclist_lock.
Signed-off-by: Omar Sandoval
---
fs/proc/kcore.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff
From: Omar Sandoval
Now that we're using an rwsem, we can hold it during the entirety of
read_kcore() and have a common return path. This is preparation for the
next change.
Signed-off-by: Omar Sandoval
---
fs/proc/kcore.c | 70 -
1 file ch
From: Omar Sandoval
The current code does a full search of the segment list every time for
every page. This is wasteful, since it's almost certain that the next
page will be in the same segment. Instead, check if the previous segment
covers the current page before doing the list search.
S
From: Omar Sandoval
The memory hotplug notifier kcore_callback() only needs kclist_lock to
prevent races with __kcore_update_ram(), but we can easily eliminate
that race by using an atomic xchg() in __kcore_update_ram(). This is
preparation for converting kclist_lock to an rwsem.
Reviewed-by
From: Omar Sandoval
Currently, the ELF file header, program headers, and note segment are
allocated all at once, in some icky code dating back to 2.3. Programs
tend to read the file header, then the program headers, then the note
segment, all separately, so this is a waste of effort. It&#
From: Omar Sandoval
The vmcoreinfo information is useful for runtime debugging tools, not
just for crash dumps. A lot of this information can be determined by
other means, but this is much more convenient, and it only adds a page
at most to the file.
Signed-off-by: Omar Sandoval
---
fs/proc
From: Omar Sandoval
Hi,
This series makes a few improvements to /proc/kcore. It fixes a couple
of small issues in v3 but is otherwise the same. Patches 1, 2, and 3 are
prep patches. Patch 4 is a fix/cleanup. Patch 5 is another prep patch.
Patches 6 and 7 are optimizations to ->read(). Patc
From: Omar Sandoval
This is preparation for allowing CRASH_CORE to be enabled for any
architecture.
swapper_pg_dir is always either an array or a macro expanding to NULL.
In the latter case, VMCOREINFO_SYMBOL() won't work, as it tries to take
the address of the given symbol:
#d
From: Omar Sandoval
There's a theoretical race condition that will cause /proc/kcore to miss
a memory hotplug event:
CPU0 CPU1
// hotplug event 1
kcore_need_update = 1
open_kcore() open_kcore()
kcore_updat
On Wed, Jul 25, 2018 at 12:11:26AM +0900, Tetsuo Handa wrote:
> On 2018/07/19 7:58, Omar Sandoval wrote:
> > From: Omar Sandoval
> >
> > Now that we're using an rwsem, we can hold it during the entirety of
> > read_kcore() and have a common return path. This
On Mon, Jul 23, 2018 at 07:42:31PM +1000, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm tree, today's linux-next build (sparc (32 bit)
> defconfig) failed like this:
>
> In file included from kernel/crash_core.c:9:0:
> kernel/crash_core.c: In function 'crash_save_vmcoreinfo_init
From: Omar Sandoval
kclist_add() is only called at init time, so there's no point in
grabbing any locks. We're also going to replace the rwlock with a rwsem,
which we don't want to try grabbing during early boot.
While we're here, mark kclist_add() with __init so that we
From: Omar Sandoval
Hi,
This series makes a few improvements to /proc/kcore. Patches 1, 2, and 3
are prep patches. Patch 4 is a fix/cleanup. Patch 5 is another prep
patch. Patches 6 and 7 are optimizations to ->read(). Patch 8 adds
vmcoreinfo to /proc/kcore.
Again, based on v4.18-rc4 + Ja
From: Omar Sandoval
There's a theoretical race condition that will cause /proc/kcore to miss
a memory hotplug event:
CPU0 CPU1
// hotplug event 1
kcore_need_update = 1
open_kcore() open_kcore()
kcore_updat
From: Omar Sandoval
Currently, the ELF file header, program headers, and note segment are
allocated all at once, in some icky code dating back to 2.3. Programs
tend to read the file header, then the program headers, then the note
segment, all separately, so this is a waste of effort. It&#
From: Omar Sandoval
Now that we're using an rwsem, we can hold it during the entirety of
read_kcore() and have a common return path. This is preparation for the
next change.
Signed-off-by: Omar Sandoval
---
fs/proc/kcore.c | 70 -
1 file ch
From: Omar Sandoval
The current code does a full search of the segment list every time for
every page. This is wasteful, since it's almost certain that the next
page will be in the same segment. Instead, check if the previous segment
covers the current page before doing the list search.
S
From: Omar Sandoval
Now we only need kclist_lock from user context and at fs init time, and
the following changes need to sleep while holding the kclist_lock.
Signed-off-by: Omar Sandoval
---
fs/proc/kcore.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff
From: Omar Sandoval
The memory hotplug notifier kcore_callback() only needs kclist_lock to
prevent races with __kcore_update_ram(), but we can easily eliminate
that race by using an atomic xchg() in __kcore_update_ram(). This is
preparation for converting kclist_lock to an rwsem.
Signed-off-by
From: Omar Sandoval
The vmcoreinfo information is useful for runtime debugging tools, not
just for crash dumps. A lot of this information can be determined by
other means, but this is much more convenient, and it only adds a page
at most to the file.
Signed-off-by: Omar Sandoval
---
fs/proc
On Tue, Jul 17, 2018 at 08:27:53PM -0700, Andrew Morton wrote:
> On Tue, 17 Jul 2018 20:24:05 -0700 Omar Sandoval wrote:
>
> > > > --- a/fs/proc/kcore.c
> > > > +++ b/fs/proc/kcore.c
> > > > @@ -59,8 +59,8 @@ struct memelfnote
> > > &g
On Tue, Jul 17, 2018 at 07:44:21PM -0700, Andrew Morton wrote:
> On Thu, 12 Jul 2018 17:09:39 -0700 Omar Sandoval wrote:
>
> > From: Omar Sandoval
> >
> > The vmcoreinfo information is useful for runtime debugging tools, not
> > just for crash dumps. A lot of this
On Tue, Jul 17, 2018 at 07:38:41PM -0700, Andrew Morton wrote:
> On Thu, 12 Jul 2018 17:09:34 -0700 Omar Sandoval wrote:
>
> > From: Omar Sandoval
> >
> > Now we only need kclist_lock from user context and at fs init time, and
> > the following changes n
On Tue, Jul 17, 2018 at 07:35:04PM -0700, Andrew Morton wrote:
> On Thu, 12 Jul 2018 17:09:33 -0700 Omar Sandoval wrote:
>
> > From: Omar Sandoval
> >
> > kclist_add() is only called at init time, so there's no point in
> > grabbing any locks. We're
From: Omar Sandoval
Now we only need kclist_lock from user context and at fs init time, and
the following changes need to sleep while holding the kclist_lock.
Signed-off-by: Omar Sandoval
---
fs/proc/kcore.c | 32 +++-
1 file changed, 15 insertions(+), 17 deletions
From: Omar Sandoval
Currently, the ELF file header, program headers, and note segment are
allocated all at once, in some icky code dating back to 2.3. Programs
tend to read the file header, then the program headers, then the note
segment, all separately, so this is a waste of effort. It&#
From: Omar Sandoval
Now that we're using an rwsem, we can hold it during the entirety of
read_kcore() and have a common return path. This is preparation for the
next change.
Signed-off-by: Omar Sandoval
---
fs/proc/kcore.c | 70 -
1 file ch
From: Omar Sandoval
kclist_add() is only called at init time, so there's no point in
grabbing any locks. We're also going to replace the rwlock with a rwsem,
which we don't want to try grabbing during early boot.
Signed-off-by: Omar Sandoval
---
fs/proc/kcore.c | 3 +--
1
From: Omar Sandoval
The current code does a full search of the segment list every time for
every page. This is wasteful, since it's almost certain that the next
page will be in the same segment. Instead, check if the previous segment
covers the current page before doing the list search.
S
From: Omar Sandoval
The vmcoreinfo information is useful for runtime debugging tools, not
just for crash dumps. A lot of this information can be determined by
other means, but this is much more convenient.
Signed-off-by: Omar Sandoval
---
fs/proc/Kconfig| 1 +
fs/proc/kcore.c
From: Omar Sandoval
There's a theoretical race condition that will cause /proc/kcore to miss
a memory hotplug event:
CPU0 CPU1
// hotplug event 1
kcore_need_update = 1
open_kcore() open_kcore()
kcore_updat
From: Omar Sandoval
Hi,
This series makes a few improvements to /proc/kcore. Patches 1 and 2 are
prep patches. Patch 3 is a fix/cleanup. Patch 4 is another prep patch.
Patches 5 and 6 are optimizations to ->read(). Patch 7 adds vmcoreinfo
to /proc/kcore (apparently I'm not the only
rong git tree, please drop us a note to
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Omar-Sandoval/proc-kcore-improvements/20180707-052548
> reproduce:
> # apt-get install sparse
> make ARCH=x86_64 allmodconfig
>
From: Omar Sandoval
Now we only need kclist_lock from user context and at fs init time, and
the following changes need to sleep while holding the kclist_lock.
Signed-off-by: Omar Sandoval
---
fs/proc/kcore.c | 32 +++-
1 file changed, 15 insertions(+), 17 deletions
From: Omar Sandoval
kclist_add() is only called at init time, so there's no point in
grabbing any locks. We're also going to replace the rwlock with a rwsem,
which we don't want to try grabbing during early boot.
Signed-off-by: Omar Sandoval
---
fs/proc/kcore.c | 3 +--
1
From: Omar Sandoval
Hi,
This series makes a few improvements to /proc/kcore. Patches 1 and 2 are
prep patches. Patch 3 is a fix/cleanup. Patch 4 is another prep patch.
Patches 5 and 6 are optimizations to ->read(). Patch 7 adds vmcoreinfo
to /proc/kcore. This series is based on v4.18-
From: Omar Sandoval
There's a theoretical race condition that will cause /proc/kcore to miss
a memory hotplug event:
CPU0 CPU1
// hotplug event 1
kcore_need_update = 1
open_kcore() open_kcore()
kcore_updat
From: Omar Sandoval
The vmcoreinfo information is useful for runtime debugging tools, not
just for crash dumps. A lot of this information can be determined by
other means, but this is much more convenient.
Signed-off-by: Omar Sandoval
---
fs/proc/Kconfig| 1 +
fs/proc/kcore.c
From: Omar Sandoval
Now that we're using an rwsem, we can hold it during the entirety of
read_kcore() and have a common return path. This is preparation for the
next change.
Signed-off-by: Omar Sandoval
---
fs/proc/kcore.c | 70 -
1 file ch
From: Omar Sandoval
The current code does a full search of the segment list every time for
every page. This is wasteful, since it's almost certain that the next
page will be in the same segment. Instead, check if the previous segment
covers the current page before doing the list search.
S
From: Omar Sandoval
Currently, the ELF file header, program headers, and note segment are
allocated all at once, in some icky code dating back to 2.3. Programs
tend to read the file header, then the program headers, then the note
segment, all separately, so this is a waste of effort. It&#
On Tue, May 22, 2018 at 10:48:29PM +0800, Jianchao Wang wrote:
> Currently, kyber is very unfriendly with merging. kyber depends
> on ctx rq_list to do merging, however, most of time, it will not
> leave any requests in ctx rq_list. This is because even if tokens
> of one domain is used up, kyber w
On Mon, May 21, 2018 at 03:11:08PM +, Bart Van Assche wrote:
> On Sun, 2018-05-20 at 19:58 -0400, Kent Overstreet wrote:
> > On Sun, May 20, 2018 at 11:40:45PM +, Bart Van Assche wrote:
> > > On Sun, 2018-05-20 at 19:21 -0400, Kent Overstreet wrote:
> > > > I really have better things to do
From: Omar Sandoval
This parameter has been around since commit e162b39a368f ("softlockup:
decouple hung tasks check from softlockup detection") in 2009 but was
never documented.
Signed-off-by: Omar Sandoval
---
Documentation/admin-guide/kernel-parameters.txt | 10 ++
1 fi
On Fri, Apr 20, 2018 at 10:17:42AM +0200, Peter Zijlstra wrote:
> On Sun, Apr 15, 2018 at 12:42:25AM -0700, Omar Sandoval wrote:
> > From: Omar Sandoval
> >
> > While revisiting my Btrfs swapfile series [1], I introduced a situation
> > in which reclaim would lock i
On Mon, Apr 16, 2018 at 06:33:27PM +0200, Steffen Maier wrote:
> Hi Greg,
>
> On 04/15/2018 10:31 AM, Greg Kroah-Hartman wrote:
> > On Fri, Apr 13, 2018 at 03:07:18PM +0200, Steffen Maier wrote:
> > > diff --git a/include/trace/events/block.h b/include/trace/events/block.h
> > > index a13613d27cee
From: Omar Sandoval
While revisiting my Btrfs swapfile series [1], I introduced a situation
in which reclaim would lock i_rwsem, and even though the swapon() path
clearly made GFP_KERNEL allocations while holding i_rwsem, I got no
complaints from lockdep. It turns out that the rework of the
On Tue, Mar 27, 2018 at 11:31:47AM +0200, Johannes Thumshirn wrote:
> Add a regression test for the patch titled "nvme: don't send
> keep-alives to the discovery controller".
>
> This patch creates a local loopback nvme target and then connects to
> it. If the patch is not applied we see two error
On Fri, Apr 06, 2018 at 02:22:06PM -0700, Randy Dunlap wrote:
> On 02/11/2018 10:40 PM, Andrew Kelley wrote:
> > Whatever happened to this patch?
> >
> > https://patchwork.kernel.org/patch/9636735/
> >
> > It looks fine and addresses a legitimate issue.
> >
> > Please CC me on replies as I am no
On Fri, Apr 06, 2018 at 05:43:43PM +0200, Peter Zijlstra wrote:
> On Fri, Apr 06, 2018 at 10:55:03PM +0900, Tetsuo Handa wrote:
> > Peter Zijlstra wrote:
> > > On Fri, Apr 06, 2018 at 09:04:18PM +0900, Tetsuo Handa wrote:
> > > > + /* Temporary hack for handling lock imbalance. */
> > > > +
Just wanted to make sure this doesn't get missed because I misspelled
the stable email address in the patch. It applies to v4.13+.
On Mon, Apr 02, 2018 at 04:49:39PM -0700, Linus Torvalds wrote:
> On Mon, Apr 2, 2018 at 4:37 PM, Linus Torvalds
> wrote:
> >
> > We should probably have at least switched it to "unsigned long int"
>
> I meant just "unsigned int", of course.
>
> Right now we occasionally have a silly 64-bit fiel
On Mon, Apr 02, 2018 at 03:58:31PM -0700, Omar Sandoval wrote:
> From: Omar Sandoval
>
> Commit 2a98dc028f91 introduced an optimization to bitmap_{set,clear}()
> which uses memset() when the start and length are constants aligned to a
> byte. This is wrong on big-endian systems;
From: Omar Sandoval
Commit 2a98dc028f91 introduced an optimization to bitmap_{set,clear}()
which uses memset() when the start and length are constants aligned to a
byte. This is wrong on big-endian systems; our bitmaps are arrays of
unsigned long, so bit n is not at byte n / 8 in memory. This
On Tue, Mar 13, 2018 at 04:16:27PM -0700, Howard McLauchlan wrote:
> Error injection is a useful mechanism to fail arbitrary kernel
> functions. However, it is often hard to guarantee an error propagates
> appropriately to user space programs. By injecting into syscalls, we can
> return arbitrary v
87b1c2 ("nbd: add a basic netlink interface")
Reviewed-by: Omar Sandoval
> Signed-off-by: Gustavo A. R. Silva
> ---
> drivers/block/nbd.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
> index 5f2
VMCOREINFO_SYMBOL(contig_page_data);
> > #endif
> > #ifdef CONFIG_SPARSEMEM
> > - VMCOREINFO_SYMBOL(mem_section);
> > + VMCOREINFO_SYMBOL_ARRAY(mem_section);
> > VMCOREINFO_LENGTH(mem_section, NR_SECTION_ROOTS);
> > VMCOREINFO_STRUCT_SIZE(mem_section);
> > VMCOREINFO
Commit-ID: c6b9d9a33029014446bd9ed84c1688f6d3d4eab9
Gitweb: https://git.kernel.org/tip/c6b9d9a33029014446bd9ed84c1688f6d3d4eab9
Author: Omar Sandoval
AuthorDate: Tue, 5 Dec 2017 23:15:31 -0800
Committer: Ingo Molnar
CommitDate: Wed, 6 Dec 2017 19:30:34 +0100
sched/wait: Fix
From: Omar Sandoval
Commit 50816c48997a ("sched/wait: Standardize internal naming of
wait-queue entries") changed the behavior of add_wait_queue() from
inserting the wait entry at the head of the wait queue to the tail of
the wait queue. That commit was a cleanup and didn
Hi, Ingo,
Commit 50816c48997a ("sched/wait: Standardize internal naming of
wait-queue entries") changed the behavior of add_wait_queue() from
inserting the wait entry at the head of the wait queue to the tail of
the wait queue. This is the relevant hunk:
-void add_wait_queue(wait_queue_head_t *q,
On Wed, Mar 22, 2017 at 11:29:25PM +0400, Dmitry Monakhov wrote:
> It is reasonable drop page cache on discard, otherwise that pages may
> be written by writeback second later, so thin provision devices will
> not be happy. This seems to be a security leak in case of secure discard
> case.
>
> A
On Thu, Oct 12, 2017 at 10:40:42PM +0100, Christos Gkekas wrote:
> Remove variables 'start' and 'end', which are set but never used.
Oops.
Reviewed-by: Omar Sandoval
> Signed-off-by: Christos Gkekas
> ---
> fs/btrfs/free-space-tree.c | 4
> 1 file chan
ake sure that request isn't dequeued until ->dispatch is
> flushed.
>
> Reviewed-by: Bart Van Assche
> Reviewed-by: Christoph Hellwig
I think this will do for now.
Reviewed-by: Omar Sandoval
> Signed-off-by: Ming Lei
> ---
&
.
This still didn't address Jens' concern about using q->queue_depth as
the heuristic for whether to do the full sw queue flush or one-by-one
dispatch. The EWMA approach is a bit too complex for now, can you please
try the heuristic of whether the driver ever returned BLK_STS_RESOURCE?
On Mon, Oct 09, 2017 at 07:24:22PM +0800, Ming Lei wrote:
> We need to iterate ctx starting from any ctx in round robin
> way, so introduce this helper.
>
> Cc: Omar Sandoval
Reviewed-by: Omar Sandoval
> Signed-off-by: Ming Lei
> ---
> include
, ...) when mq-deadline/kyber
> is used by not taking requests if hw queue is busy.
>
> Reviewed-by: Bart Van Assche
> Reviewed-by: Christoph Hellwig
Reviewed-by: Omar Sandoval
> Signed-off-by: Ming Lei
> ---
> block/blk-mq-sched.c | 12 ++--
> 1 file changed, 6
On Tue, Jun 27, 2017 at 12:01:47PM +0800, James Wang wrote:
> Add a regression testing for loop device. when an unbound device
> be close that take too long time. kernel will consume serveral orders
> of magnitude more wall time than it does for a mounted device.
James, sorry I forgot about this.
On Mon, Aug 07, 2017 at 03:37:50PM +0300, Anton Volkov wrote:
> The early device registration made possible a race leading to allocations
> of disks with wrong minors.
>
> This patch moves the device registration further down the loop_init
> function to make the race infeasible.
>
> Found by Linu
On Tue, Jul 04, 2017 at 01:35:18PM -0300, Ben Mezger wrote:
> This patch, allows BFQ to be chosen in the Default I/O scheduler prompt.
Nak, this doesn't work. The default scheduler Kconfig option is for the
legacy block path, but BFQ is a blk-mq scheduler.
> Signed-off-by: Ben Mezger
> ---
> bl
Hi, James, thanks for sending this in. Sorry for the delay, I've been
out of the office for a couple of weeks. A few comments below.
On Thu, Jun 08, 2017 at 08:28:12PM +0800, James Wang wrote:
> Add a regression testing for loop device. when an unbound device
> be close that take too long time. ke
On Sat, Jun 03, 2017 at 04:04:02PM +0200, Christoph Hellwig wrote:
> Currently we only create hctx for online CPUs, which can lead to a lot
> of churn due to frequent soft offline / online operations. Instead
> allocate one for each present CPU to avoid this and dramatically simplify
> the code.
>
On Wed, May 31, 2017 at 11:19:05AM +0200, Michal Hocko wrote:
> On Wed 31-05-17 02:12:02, Omar Sandoval wrote:
> > On Wed, May 31, 2017 at 08:51:28AM +0200, Michal Hocko wrote:
> > > On Wed 31-05-17 14:30:33, kernel test robot wrote:
> > > >
> > >
On Wed, May 31, 2017 at 08:51:28AM +0200, Michal Hocko wrote:
> On Wed 31-05-17 14:30:33, kernel test robot wrote:
> >
> > FYI, we noticed the following commit:
> >
> > commit: beeeccca9bebcec386cc31c250cff8a06cf27034 ("btrfs: Use kvzalloc
> > instead of kzalloc/vmalloc in alloc_bitmap")
> > htt
On Thu, May 25, 2017 at 12:18:02PM -0700, Vinnie Magro wrote:
> Replace alloc_bitmap with call to kvzalloc. kvzalloc preserves the
> same fallback heuristic.
Looks good, thanks.
Reviewed-by: Omar Sandoval
> Signed-off-by: Vinnie Magro
> ---
> fs/btrfs/free-sp
Hi,
Linux kernel commit 4027494ae6e3 ("ARM: dts: add arm/arm64 include
symlinks") introduced a couple of symlink cycles:
$ ls -al arch/arm{,64}/boot/dts/include
arch/arm64/boot/dts/include:
total 12
drwxr-xr-x 1 osandov users 38 May 11 14:01 .
drwxr-xr-x 1 osandov users 320 Jan 25 20:44 ..
lrwxr
Commit-ID: 6f6266a561306e206e0e31a5038f029b6a7b1d89
Gitweb: http://git.kernel.org/tip/6f6266a561306e206e0e31a5038f029b6a7b1d89
Author: Omar Sandoval
AuthorDate: Wed, 12 Apr 2017 16:27:19 +0100
Committer: Ingo Molnar
CommitDate: Thu, 13 Apr 2017 08:09:27 +0200
x86/efi: Don't t
From: Omar Sandoval
Reserving a runtime region results in splitting the efi memory
descriptors for the runtime region. This results in runtime region
descriptors with bogus memory mappings, leading to interesting crashes
like the following during a kexec:
[0.001000] general protection fault
On Thu, Mar 16, 2017 at 10:50:48AM -0700, Omar Sandoval wrote:
> On Thu, Mar 16, 2017 at 12:41:32PM +, Matt Fleming wrote:
> > On Mon, 13 Mar, at 03:37:48PM, Dave Young wrote:
> > >
> > > Omar, could you try below patch? Looking at the efi_mem_desc_lookup, it
>
From: Omar Sandoval
This patch introduces a new I/O scheduler based on the classic random
early detection active queue management algorithm [1]. Random early
detection is one of the simplest and most studied AQM algorithms for
networking, but until now, it hasn't been applied to dis
On Sun, Mar 19, 2017 at 06:46:01PM -0700, Linus Torvalds wrote:
> On Sun, Mar 19, 2017 at 10:24 AM, Al Viro wrote:
> > Bringing back an old conversation - what do you think about the
> > potential usefulness of the following ...at() option:
> > * no mountpoint crossings allowed (mo
ze)
> return;
> }
>
> + /* No need to reserve regions that will never be freed. */
> + if (md.attribute & EFI_MEMORY_RUNTIME)
> + return;
> +
> size += addr % EFI_PAGE_SIZE;
> size = round_up(size, EFI_PAGE_SIZE);
> addr = round_down(addr, EFI_PAGE_SIZE);
This works for me.
Reported-and-tested-by: Omar Sandoval
On Thu, Mar 09, 2017 at 02:38:06PM +0800, Dave Young wrote:
> Add efi/kexec list.
>
> On 03/08/17 at 12:16pm, Omar Sandoval wrote:
[snip]
> I have no more clue yet from your provided log, but the runtime value is
> odd to me. It is set in below code:
>
> arch/x
On Thu, Mar 09, 2017 at 10:21:36AM +0800, Dave Young wrote:
> I have no esrt machine to test, can you share the full kernel log with
> efi=debug in kernel cmdline?
>
> *) normal boot kernel log without the reverting
> *) kexec boot log with and without the reverting
Attached.
[0.00] Linux
Hi, everyone,
Since 4.9, kexec results in the following panic on some of our servers:
[0.001000] general protection fault: [#1] SMP
[0.001000] Modules linked in:
[0.001000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.11.0-rc1 #53
[0.001000] Hardware name: Wiwynn Leopard-Orv2/
1 - 100 of 390 matches
Mail list logo
