g, 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 changed, 13 insertions(+), 16 del
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
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 +-
>
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
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 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 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 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
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
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
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
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(+),
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(+),
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!
> Signed-off-by: Dominique Ma
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!
> Signed-off-by: Dominique Ma
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
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
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'll get a
warning
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'll get a
warning
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 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 changed
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 changed
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.
Signed
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.
Signed
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
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'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
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'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, and it only adds a page
at most to the file.
Signed-off-by: Omar Sandoval
---
fs/proc
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:
#define
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_update_ram
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:
#define
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_update_ram
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 is p
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 is p
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
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
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'll get a
warning
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'll get a
warning
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
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_update_ram
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's
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 changed
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.
Signed
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_update_ram
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's
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 changed
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.
Signed
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 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
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
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
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 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: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 chang
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 chang
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 al
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 al
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'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 | 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's
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 changed
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 file changed, 1
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 changed
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 file changed, 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.
Signed
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.
Signed
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
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_update_ram
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 one
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_update_ram
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 one
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
>
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 file changed, 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
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 file changed, 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_update_ram
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 changed
1 - 100 of 773 matches
Mail list logo
