On Tue, May 30, 2017 at 10:37:03AM -0500, Tom Lendacky wrote:
> I can define the command line option and the "on" and "off" values as
> character buffers in the function and initialize them on a per character
> basis (using a static string causes the same issues as referencing a
> string constant),
On Tue, May 30, 2017 at 10:48:27AM -0500, Tom Lendacky wrote:
> I'll look at doing that instead of removing the support for the whole
> file.
Right, so I don't think the stack protector is even ready that early -
we do set it up later:
/* Set up %gs.
*
* The base of %gs
On Tue, May 30, 2017 at 11:39:07AM -0500, Tom Lendacky wrote:
> Yes, it's from objtool:
>
> arch/x86/mm/mem_encrypt_boot.o: warning: objtool: .text+0xd2: return
> instruction outside of a callable function
Oh, well, let's make it a global symbol then. Who knows, we might have
to live-patch it som
On Tue, May 30, 2017 at 12:46:14PM -0500, Tom Lendacky wrote:
> This is an area that I'm not familiar with, so I don't completely
> understand the flow in regards to where/when/how the ELF headers are
> copied and what needs to be done.
So my suggestion is still to put kexec/kdump on the backburne
On 18/05/2017 at 22:25:56 -0300, Mauro Carvalho Chehab wrote:
> Each text file under Documentation follows a different
> format. Some doesn't even have titles!
>
> Change its representation to follow the adopted standard,
> using ReST markups for it to be parseable by Sphinx:
>
> - adjust identat
On Tue, May 30, 2017 at 11:46:52AM -0500, Tom Lendacky wrote:
> Check if you have CONFIG_DEBUG_SECTION_MISMATCH=y
$ grep MISM .config
CONFIG_DEBUG_SECTION_MISMATCH=y
CONFIG_SECTION_MISMATCH_WARN_ONLY=y
Still no joy.
Can you give me your .config?
--
Regards/Gruss,
Boris.
Good mailing pract
Some filesystems (particularly local ones) keep a different mapping for
metadata writeback. Add a second errseq_t to struct file for tracking
metadata writeback errors. Also add a new function for checking a
mapping of the caller's choosing vs. the f_md_wb_err value.
Signed-off-by: Jeff Layton
--
Sample the wb_err before changing the directory, so that we can catch
errors that occur since that point.
Signed-off-by: Jeff Layton
---
fs/ext2/dir.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/fs/ext2/dir.c b/fs/ext2/dir.c
index 6e476c9929f8..073f096a
Add new filemap_*wait* variants that take a "since" value and return an
error if one occurred since that sample point.
Signed-off-by: Jeff Layton
---
include/linux/fs.h | 9
mm/filemap.c | 67 ++
2 files changed, 76 insertions(+
Set the flag to indicate that we want new-style data writeback error
handling.
This means that we need to override the open routines for files and
directories so that we can sample the bdev wb_err at open.
XXX: doesn't quite pass the xfstest for this currently, as ext2_error
resets the error
Allow filesystems to pass in an errseq_t for a since value.
Signed-off-by: Jeff Layton
---
include/linux/mm.h | 2 ++
mm/page-writeback.c | 53 +
2 files changed, 43 insertions(+), 12 deletions(-)
diff --git a/include/linux/mm.h b/include/li
Grab the current mapping->wb_err when linking a transaction to the list
and stash it in the journal inode. Then we can use that as a "since"
value when committing it to ensure that there were no writeback errors
since the transaction was started.
We do still need to perform old-style error handlin
For now, we add a FS_WB_ERRSEQ check to know how to handle it.
Signed-off-by: Jeff Layton
---
fs/libfs.c | 26 +++---
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/fs/libfs.c b/fs/libfs.c
index 1dec90819366..2ae58a252718 100644
--- a/fs/libfs.c
+++ b/fs/libfs
Fairly straightforward conversion. In fsync, just use the file->f_wb_err
value as a "since" value. At the end, call filemap_report_wb_err to
advance the cursor in it.
Signed-off-by: Jeff Layton
---
fs/block_dev.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/
Jan's description for this patch is much better than mine, so I'm
quoting it verbatim here:
-8<-
DAX currently doesn't set errors in the mapping when cache flushing
fails in dax_writeback_mapping_range(). Since this function can get
called only from fsync(2) or sync
Since it returns errors in a way similar to fsync, have it use the same
method for returning previously-reported writeback errors.
Signed-off-by: Jeff Layton
---
fs/sync.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/fs/sync.c b/fs/sync.c
index ec93aac4f
Sample the block device inode's errseq_t when opening a file, so we can
catch metadata writeback errors at fsync time. Change ext4_sync_file to
check for data errors first, and then check the blockdev for metadata
errors afterward.
There are also several internal callers of filemap_write_and_wait_
New variants of sync_filesystem and sync_blockdev.
Signed-off-by: Jeff Layton
---
fs/block_dev.c | 15 +++
fs/internal.h | 8
fs/sync.c | 45 +
include/linux/fs.h | 13 -
4 files changed, 80 insertion
I waxed a little loquacious here, but I figured that more detail was
better, and writeback error handling is so hard to get right.
Although I think we'll eventually remove it once the transition is
complete, I've gone ahead and documented the FS_WB_ERRSEQ flag as well.
Cc: Jan Kara
Signed-off-by
To enable that, make __errseq_set return the value that it was set to
we exit the loop. Take heed that that value is not suitable as a later
"since" value, as it will not have been marked seen.
Signed-off-by: Jeff Layton
---
include/linux/errseq.h | 2 +-
include/linux/fs.h
Now that we have new infrastructure for handling writeback errors using
errseq_t, we need to convert the existing code to use it. We could
attempt to retrofit the old interfaces on top of the new, but there is
a conceptual disconnect here in the case of internal callers that
invoke filemap_fdatawai
v5: don't retrofit old API over the new infrastructure
add fstype flag to indicate how wb errors are tracked within that fs
add more function variants that take a errseq_t "since" value
add second errseq_t to struct file to track metadata wb errors
convert ext4 and ext2 to use the n
An errseq_t is a way of recording errors in one place, and allowing any
number of "subscribers" to tell whether an error has been set again
since a previous time.
It's implemented as an unsigned 32-bit value that is managed with atomic
operations. The low order bits are designated to hold an error
Most filesystems currently use mapping_set_error and
filemap_check_errors for setting and reporting/clearing writeback errors
at the mapping level. filemap_check_errors is indirectly called from
most of the filemap_fdatawait_* functions and from
filemap_write_and_wait*. These functions are called f
I'm working on a set of kernel patches to change how writeback errors
are handled and reported in the kernel. Instead of reporting a
writeback error to only the first fsync caller on the file, I aim
to make the kernel report them once on every file description.
This patch adds a test for the new b
Ensure that we get an error back on all fds when a block device is
open by multiple writers and writeback fails.
Signed-off-by: Jeff Layton
---
tests/generic/998 | 64 +++
tests/generic/998.out | 2 ++
tests/generic/group | 1 +
3 files cha
With btrfs, we can't really put the log on a separate device. What we
can do however is mirror the metadata across two devices and make the
data striped across all devices. When we turn on dmerror then the
metadata can fall back to using the other mirror while the data errors
out.
Note that the cu
Signed-off-by: Jeff Layton
---
common/rc | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/common/rc b/common/rc
index 391d36f373cd..83765aacfb06 100644
--- a/common/rc
+++ b/common/rc
@@ -832,7 +832,16 @@ _scratch_mkfs()
mkfs_cmd="$MKFS_BTRFS_PROG"
The writeback error handling test requires that you put the journal on a
separate device. This allows us to use dmerror to simulate data
writeback failure, without affecting the journal.
xfs already has infrastructure for this (a'la $SCRATCH_LOGDEV), so wire
up the ext4 code so that it can do the
This patchset is a companion to the Linux kernel patch series I recently
posted with the cover letter:
[PATCH v5 00/17] fs: introduce new writeback error reporting and convert
ext2 and ext4 to use it
That patchset adds a new userland-visible change to report errors on
all open file descripti
On 5/31/2017 4:51 AM, Borislav Petkov wrote:
On Tue, May 30, 2017 at 11:39:07AM -0500, Tom Lendacky wrote:
Yes, it's from objtool:
arch/x86/mm/mem_encrypt_boot.o: warning: objtool: .text+0xd2: return
instruction outside of a callable function
Oh, well, let's make it a global symbol then. Who
On 5/31/2017 3:49 AM, Borislav Petkov wrote:
On Tue, May 30, 2017 at 10:37:03AM -0500, Tom Lendacky wrote:
I can define the command line option and the "on" and "off" values as
character buffers in the function and initialize them on a per character
basis (using a static string causes the same i
On Wed, May 31, 2017 at 08:37:50AM -0500, Tom Lendacky wrote:
> I like keeping the command line option and the values together. It may
> not look the greatest but I like it more than defining the command line
> option in head_64.S and passing it in as an argument.
>
> OTOH, I don't think the rip-r
On 05/31/2017 at 01:46 AM, Tom Lendacky wrote:
> On 5/25/2017 11:17 PM, Xunlei Pang wrote:
>> On 04/19/2017 at 05:21 AM, Tom Lendacky wrote:
>>> Provide support so that kexec can be used to boot a kernel when SME is
>>> enabled.
>>>
>>> Support is needed to allocate pages for kexec without encrypti
On Wed, May 31, 2017 at 11:03:52PM +0800, Xunlei Pang wrote:
> For kdump case, it will be put in some reserved crash memory allocated
> by kexec-tools, and passed the corresponding start address of the
> allocated reserved crash memory to kdump kernel via "elfcorehdr=",
> please see kernel function
Most users of irq_alloc_generic_chip() call irq_setup_generic_chip()
too. To simplify the cleanup provide a function that both removes a
generic chip and frees its memory.
Signed-off-by: Bartosz Golaszewski
---
include/linux/irq.h | 8
1 file changed, 8 insertions(+)
diff --git a/inclu
Provide a resource managed variant of irq_alloc_generic_chip().
Signed-off-by: Bartosz Golaszewski
---
Documentation/driver-model/devres.txt | 1 +
include/linux/irq.h | 5 +
kernel/irq/devres.c | 34 ++
3 files changed, 4
Provide a resource managed variant of irq_setup_generic_chip().
Signed-off-by: Bartosz Golaszewski
---
Documentation/driver-model/devres.txt | 1 +
include/linux/irq.h | 3 ++
kernel/irq/devres.c | 52 +++
3 files changed, 56
This function will be used in the devres variant of
irq_alloc_generic_chip().
Signed-off-by: Bartosz Golaszewski
---
kernel/irq/generic-chip.c | 7 +++
kernel/irq/internals.h| 11 +++
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/kernel/irq/generic-chip.c b/ker
This series is a follow-up to [1].
Some users of irq_alloc_generic_chip() are modules which can be
removed (e.g. gpio-ml-ioh) but have no means of freeing the allocated
generic chip.
Last time it was suggested to provide irq_destroy_generic_chip() which
would undo both irq_remove_generic_chip() a
Currently there's no way for users of irq_alloc_generic_chip() to free
the allocated memory other than calling kfree() manually on the
returned pointer. This may lead to errors if the internals of
irq_alloc_generic_chip() ever change. Provide a routine to free the
generic chip.
Signed-off-by: Bart
[I am sorry I didn't get to reply earlier]
On Thu 25-05-17 13:08:05, Johannes Weiner wrote:
> On Thu, May 25, 2017 at 05:38:19PM +0200, Michal Hocko wrote:
> > On Tue 23-05-17 09:25:44, Johannes Weiner wrote:
[...]
> > > We don't need any elaborate
> > > just-in-time evaluation of what each entity
On Wed, May 31, 2017 at 06:25:04PM +0200, Michal Hocko wrote:
> On Thu 25-05-17 13:08:05, Johannes Weiner wrote:
> > Everything the user would want to dynamically program in the kernel,
> > say with bpf, they could do in userspace and then update the scores
> > for each group and task periodically.
Hello,
On Wed, May 31, 2017 at 09:08:16AM -0400, Jeff Layton wrote:
> I'm working on a set of kernel patches to change how writeback errors
> are handled and reported in the kernel. Instead of reporting a
> writeback error to only the first fsync caller on the file, I aim
> to make the kernel repo
On Fri, May 26, 2017 at 10:20:51AM +0200, Wolfram Sang wrote:
> Yes, I wanted to do this for years now... The I2C core became a huge
> monolithic
> blob getting harder and harder to maintain. This series breaks out some
> functional parts into seperate files. This makes the code easier to handle
>
On Sat, May 27, 2017 at 06:22:59PM +0800, Icenowy Zheng wrote:
> Allwinner R40 is a new SoC, with Quad Core Cortex-A7 and peripherals
> like A20.
>
> Add support for it.
>
> Signed-off-by: Icenowy Zheng
> ---
> Changes in v3:
> - Use V1.0 documents.
>
> Documentation/arm/sunxi/README
On Wed, 2017-05-31 at 11:59 -0700, Eduardo Valentin wrote:
> Hello,
>
> On Wed, May 31, 2017 at 09:08:16AM -0400, Jeff Layton wrote:
> > I'm working on a set of kernel patches to change how writeback errors
> > are handled and reported in the kernel. Instead of reporting a
> > writeback error to o
On Wed, 31 May 2017 08:45:23 -0400 Jeff Layton wrote:
> This is v5 of the patchset to improve how we're tracking and reporting
> errors that occur during pagecache writeback.
I'm curious to know how you've been testing this? Is that testing
strong enough for us to be confident that all nature o
On Wed, 2017-05-31 at 13:27 -0700, Andrew Morton wrote:
> On Wed, 31 May 2017 08:45:23 -0400 Jeff Layton wrote:
>
> > This is v5 of the patchset to improve how we're tracking and reporting
> > errors that occur during pagecache writeback.
>
> I'm curious to know how you've been testing this?
>
On Wed, 31 May 2017 17:31:49 -0400 Jeff Layton wrote:
> On Wed, 2017-05-31 at 13:27 -0700, Andrew Morton wrote:
> > On Wed, 31 May 2017 08:45:23 -0400 Jeff Layton wrote:
> >
> > > This is v5 of the patchset to improve how we're tracking and reporting
> > > errors that occur during pagecache wri
On Wed, 2017-05-31 at 14:37 -0700, Andrew Morton wrote:
> On Wed, 31 May 2017 17:31:49 -0400 Jeff Layton wrote:
>
> > On Wed, 2017-05-31 at 13:27 -0700, Andrew Morton wrote:
> > > On Wed, 31 May 2017 08:45:23 -0400 Jeff Layton wrote:
> > >
> > > > This is v5 of the patchset to improve how we're
This commit applies upstream change, commit b26cfc48e3e0 ("doc: Update
control-dependencies section of memory-barriers.txt"), to Korean
translation.
Signed-off-by: SeongJae Park
---
Documentation/translations/ko_KR/memory-barriers.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -
52 matches
Mail list logo
