e log tree and the fsync must report the
>* file data write error and not commit the current transaction.
>*/
> - ret = btrfs_inode_check_errors(inode);
> + ret = filemap_check_errors(inode->i_mapping);
> if (ret)
> ctx->io_err = ret;
> process:
Btrfs part looks fine.
Reviewed-by: Omar Sandoval
--
Omar
On Mon, Sep 19, 2016 at 09:22:34AM -0600, Jens Axboe wrote:
> On 09/19/2016 09:14 AM, Arnd Bergmann wrote:
> > On Monday, September 19, 2016 8:43:12 AM CEST Jens Axboe wrote:
> > > On 09/19/2016 06:33 AM, Arnd Bergmann wrote:
> > > > The sbitmap code that has just been turned into a library module
On Sun, Sep 18, 2016 at 09:37:14AM +0200, Alexander Gordeev wrote:
> Currently maximum number of used hardware queues is limited to
> number of CPUs in the system. However, using 'nr_cpu_ids' as
> the limit for (de-)allocations of data structures instead of
> existing data structures' counters (a)
On Sun, Sep 18, 2016 at 09:37:19AM +0200, Alexander Gordeev wrote:
> CC: linux-bl...@vger.kernel.org
> Signed-off-by: Alexander Gordeev
> ---
> block/blk-mq.c | 14 +-
> 1 file changed, 5 insertions(+), 9 deletions(-)
>
> diff --git a/block/blk-mq.c b/block/blk-mq.c
> index 3efb700..
On Sun, Sep 18, 2016 at 09:37:20AM +0200, Alexander Gordeev wrote:
> CC: linux-bl...@vger.kernel.org
> Signed-off-by: Alexander Gordeev
> ---
> block/blk-mq.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/block/blk-mq.c b/block/blk-mq.c
> index cd32a08..c589096 10064
On Sun, Sep 18, 2016 at 09:37:12AM +0200, Alexander Gordeev wrote:
> If number of used hardware queues is dynamically decreased
> then tags corresponding to the newly unused queues are freed.
>
> If previously unused hardware queues are then reused again
> they will start referring the previously
On Sun, Sep 18, 2016 at 09:37:13AM +0200, Alexander Gordeev wrote:
> CC: linux-bl...@vger.kernel.org
> Signed-off-by: Alexander Gordeev
Reviewed-by: Omar Sandoval
> ---
> block/blk-mq.c | 2 --
> include/linux/blkdev.h | 1 -
> 2 files changed, 3 deletions(-)
>
On Sun, Sep 18, 2016 at 09:37:15AM +0200, Alexander Gordeev wrote:
> blk_mq_hw_ctx::queue_num is initialized in blk_mq_init_hctx()
> function.
>
> CC: linux-bl...@vger.kernel.org
> Signed-off-by: Alexander Gordeev
Reviewed-by: Omar Sandoval
> ---
> block/blk-mq.c | 1 -
On Sun, Sep 18, 2016 at 09:37:16AM +0200, Alexander Gordeev wrote:
> CC: linux-bl...@vger.kernel.org
> Signed-off-by: Alexander Gordeev
Makes sense.
Reviewed-by: Omar Sandoval
> ---
> block/blk-mq.c | 9 -
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> d
On Sun, Sep 18, 2016 at 09:37:17AM +0200, Alexander Gordeev wrote:
> CC: linux-bl...@vger.kernel.org
> Signed-off-by: Alexander Gordeev
So set->nr_hw_queues is always >= q->nr_hw_queues, right?
Reviewed-by: Omar Sandoval
> ---
> block/blk-mq.c | 9 +++--
> 1 fi
On Tue, Sep 20, 2016 at 01:44:36PM +0200, Alexander Gordeev wrote:
> On Mon, Sep 19, 2016 at 10:48:49AM -0700, Omar Sandoval wrote:
> > On Sun, Sep 18, 2016 at 09:37:14AM +0200, Alexander Gordeev wrote:
> > > Currently maximum number of used hardware queues is limited to
>
From: Omar Sandoval
Since scripts/gdb/linux/constants.py is autogenerated, this should have
been added to .gitignore when it was introduced.
Fixes: f197d75fcad1 ("scripts/gdb: provide linux constants")
Signed-off-by: Omar Sandoval
---
.gitignore | 3 +++
1 file changed, 3 insertion
From: Omar Sandoval
Since scripts/gdb/linux/constants.py is autogenerated, this should have
been added to .gitignore when it was introduced.
Fixes: f197d75fcad1 ("scripts/gdb: provide linux constants")
Signed-off-by: Omar Sandoval
---
Thanks, Kieran, I totally missed the comment in
On Tue, Jun 21, 2016 at 10:20:14PM +0100, Kieran Bingham wrote:
> On 21/06/16 22:11, Omar Sandoval wrote:
> > From: Omar Sandoval
> >
> > Since scripts/gdb/linux/constants.py is autogenerated, this should have
> > been added to .gitignore when it was introduced.
&
On Tue, Jun 21, 2016 at 11:03:39PM +0100, Kieran Bingham wrote:
> On 21/06/16 22:34, Omar Sandoval wrote:
> > $ git status
> > On branch master
> > Untracked files:
> > (use "git add ..." to include in what will be committed)
> >
> > as
From: Omar Sandoval
Here's v2 of the patch making blk-mq's scalable bitmaps a generic
library, now blown up into 5 patches. v1 is here [1].
Changes since v1:
- Return -EINVAL instead of BUG_ON() if an invalid shift is passed to
the initialization functions.
- Rename last_cache to
From: Omar Sandoval
Allocating your own per-cpu allocation hint separately makes for an
awkward API. Instead, allocate the per-cpu hint as part of the `struct
scale_bitmap_queue`. There's no point for a `struct scale_bitmap_queue`
without the cache, but you can still use a bare `s
From: Omar Sandoval
Again, there's no point in passing this in every time. Make it part of
`struct scale_bitmap_queue` and clean up the API.
Signed-off-by: Omar Sandoval
---
block/blk-mq-tag.c | 33 +++--
block/blk-mq-tag.h | 1 -
include/
From: Omar Sandoval
In order to get good cache behavior from a scale_bitmap, we want each
CPU to stick to its own cacheline(s) as much as possible. This might
happen naturally as the bitmap gets filled up and the last_cache values
spread out, but we really want this behavior from the start. blk
From: Omar Sandoval
The original `bt_alloc()` we converted from was using `kzalloc()`, not
`kzalloc_node()`, to allocate the wait queues. This was probably an
oversight, so fix it for `scale_bitmap_queue_init_node()`.
Signed-off-by: Omar Sandoval
---
lib/scale_bitmap.c | 2 +-
1 file changed
From: Omar Sandoval
This is a generally useful data structure, so make it available to
anyone else who might want to use it. It's also a nice cleanup
separating the allocation logic from the rest of the tag handling logic.
The code is behind a new Kconfig option, CONFIG_SCALE_BITMAP, whi
On Wed, Sep 07, 2016 at 05:01:56PM -0700, Alexei Starovoitov wrote:
> On 9/7/16 4:46 PM, Omar Sandoval wrote:
> > From: Omar Sandoval
> >
> > This is a generally useful data structure, so make it available to
> > anyone else who might want to use it. It's also a
On Thu, Sep 08, 2016 at 10:11:58AM -0600, Jens Axboe wrote:
> On 09/07/2016 07:12 PM, Alexei Starovoitov wrote:
> > On 9/7/16 5:38 PM, Omar Sandoval wrote:
> > > On Wed, Sep 07, 2016 at 05:01:56PM -0700, Alexei Starovoitov wrote:
> > > > On 9/7/16 4:46 PM, Omar Sandov
On Thu, Sep 15, 2016 at 08:09:23AM +0800, Ian Kent wrote:
> On Wed, 2016-09-14 at 12:28 -0500, Eric W. Biederman wrote:
> > Ian Kent writes:
> >
> > > If an automount mount is clone(2)ed into a file system that is
> > > propagation private, when it later expires in the originating
> > > namespace
On Wed, Aug 31, 2016 at 11:05:45AM -0600, Jens Axboe wrote:
> Add wbc_to_write_flags(), which returns the write modifier flags to use,
> based on a struct writeback_control. No functional changes in this
> patch, but it prepares us for factoring other wbc fields for write type.
>
> Signed-off-by:
On Wed, Aug 31, 2016 at 11:05:50AM -0600, Jens Axboe wrote:
> We can hook this up to the block layer, to help throttle buffered
> writes. Or NFS can tap into it, to accomplish the same.
>
> wbt registers a few trace points that can be used to track what is
> happening in the system:
>
> wbt_lat:
On Mon, Aug 08, 2016 at 04:09:56PM +0200, Paolo wrote:
> Hi Jens, Tejun, Christoph, all,
> AFAIK blk-mq does not yet feature I/O schedulers. In particular, there
> is no scheduler providing strong guarantees in terms of
> responsiveness, latency for time-sensitive applications and bandwidth
> distr
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 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
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
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
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
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
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
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
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
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
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
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
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
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 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
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
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 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 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
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&#
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
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
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. */
> > > > +
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 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 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
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
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 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 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
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
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
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
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 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 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
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: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 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
Extents mapping a swap file should remain pinned in memory in order to
avoid doing allocations to look up an extent when we're already low on
memory. Rather than overloading EXTENT_FLAG_PINNED, add a new flag
specifically for this purpose.
Signed-off-by: Omar Sandoval
---
fs/btrfs/extent
ith an active swap file, so this creates a surprising
inconsistency for users (in my opinion).
As with before, this functionality is tenuously tested in a virtual machine with
some artificial workloads, but it "works for me". I'm pretty happy with the
results on my end, so please
allocations for a COW when we're already low on memory
2. Pins the extent maps in memory with EXTENT_FLAG_SWAPFILE
Deactivation unpins all of the extent maps.
Signed-off-by: Omar Sandoval
---
fs/btrfs/inode.c | 131 +++
1 file changed, 131 inser
Parameters were added to swap_activate in the same patch series that
introduced it without updating the documentation. Additionally, the
documentation claims that non-existent address space operations
swap_{in,out} are used for swap I/O, but it's (now) direct_IO.
Signed-off-by: Omar San
On Mon, Nov 17, 2014 at 07:48:17AM -0800, Christoph Hellwig wrote:
> With the new iov_iter infrastructure that supprots direct I/O to kernel
> pages please get rid of the ->readpage hack first. I'm still utterly
> disapoined that this crap ever got merged.
Cc: Mel Gorman
Si
- dedup
Signed-off-by: Omar Sandoval
---
fs/btrfs/ctree.h | 3 +++
fs/btrfs/disk-io.c | 1 +
fs/btrfs/ioctl.c | 35 +++
3 files changed, 35 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index fe69edd..38979b9 100644
--- a/fs/btrfs
Reads through the iov_iter infrastructure for kernel pages shouldn't be
dirtied by the direct I/O code.
This is based on Dave Kleikamp's and Ming Lei's previously posted
patches.
Cc: Ming Lei
Acked-by: Dave Kleikamp
Signed-off-by: Omar Sandoval
---
fs/direct-io.c | 8 +---
As with the generic blockdev code, kernel pages shouldn't be dirtied by
the direct I/O path.
Signed-off-by: Omar Sandoval
---
fs/nfs/direct.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/fs/nfs/direct.c b/fs/nfs/direct.c
index 10bf072..a67fa2c 100644
--- a/f
Add arguments to kernel doc for printk wrappers, use ##__VA_ARGS
v6: Add header dependencies to rcustring.h
v5: Rebase against v3.18-rc3
v4: Don't return anything from the printk wrappers on the assumption that
printk will return void someday
v3: Add __rcu annotation to relevant functions, add Paul&
This introduces some helper functions that factor out this
functionality.
Signed-off-by: Omar Sandoval
---
fs/btrfs/volumes.c | 93 +-
fs/btrfs/volumes.h | 2 +-
2 files changed, 65 insertions(+), 30 deletions(-)
diff --git a/fs/btrfs/volumes.c b/fs/
A naked read of the value of an RCU pointer isn't safe. Put the whole
access in an RCU critical section, not just the pointer dereference.
Signed-off-by: Omar Sandoval
---
fs/btrfs/ioctl.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/
The RCU-friendly string API used internally by BTRFS is generic enough
for common use. This doesn't add any new functionality but instead just
moves the code and documents the existing API.
Reviewed-by: Josh Triplett
Acked-by: Paul E. McKenney
Signed-off-by: Omar Sandoval
---
fs/btrfs/
On Mon, Jan 12, 2015 at 11:43:02AM -0800, Omar Sandoval wrote:
> On Sat, Jan 10, 2015 at 05:08:03PM -0500, Trond Myklebust wrote:
> > Hi Omar,
> >
> > On Thu, Jan 8, 2015 at 4:18 AM, Omar Sandoval wrote:
> > > Most filesystems prevent truncation o
On Fri, Jan 23, 2015 at 08:07:41AM -0500, Trond Myklebust wrote:
> On Thu, Jan 22, 2015 at 11:07 PM, Omar Sandoval wrote:
> > On Mon, Jan 12, 2015 at 11:43:02AM -0800, Omar Sandoval wrote:
> >> On Sat, Jan 10, 2015 at 05:08:03PM -0500, Trond Myklebust wrote:
> >> >
On Fri, Dec 19, 2014 at 07:18:24PM -0800, Omar Sandoval wrote:
> Hi,
>
> This patch series (based on ecb5ec0 in Linus' tree) contains all of the
> non-BTRFS work that I've done to implement swapfiles on BTRFS. The BTRFS
> portion is still undergoing development and is no
, and truncating a swapfile can't possibly be good.
Signed-off-by: Omar Sandoval
---
Hi, Trond,
Now that the holidays are over, could you take a look at this? It was
generated against v3.19-rc3.
Thanks!
fs/nfs/inode.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --gi
On Mon, Jan 05, 2015 at 09:41:00AM -0500, Anna Schumaker wrote:
> Hi Omar,
>
> On 12/19/2014 10:18 PM, Omar Sandoval wrote:
> > As with the generic blockdev code, kernel pages shouldn't be dirtied by
> > the direct I/O path.
> >
> > Signed-off-by: Omar Sand
1 - 100 of 390 matches
Mail list logo
