[PATCH] doc/ko_KR/memory-barriers: Update control-dependencies example

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(+),

Re: [PATCH v5 00/17] fs: introduce new writeback error reporting and convert ext2 and ext4 to use it

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

Re: [PATCH v5 00/17] fs: introduce new writeback error reporting and convert ext2 and ext4 to use it

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 > >

Re: [PATCH v5 00/17] fs: introduce new writeback error reporting and convert ext2 and ext4 to use it

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

Re: [PATCH v5 00/17] fs: introduce new writeback error reporting and convert ext2 and ext4 to use it

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

Re: [xfstests PATCH v3 1/5] generic: add a writeback error handling test

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

Re: [PATCH v3 01/10] arm: sunxi: add support for R40 SoC

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. > >

Re: [PATCH 0/8] i2c: refactor core and break out blocks

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

Re: [xfstests PATCH v3 1/5] generic: add a writeback error handling test

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

Re: [RFC PATCH] mm, oom: cgroup-aware OOM-killer

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

[PATCH 1/5] irq: generic-chip: provide irq_free_generic_chip()

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:

[PATCH 0/5] irq: generic-chip: resource management improvements

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()

[PATCH 3/5] irq: generic-chip: export irq_init_generic_chip() locally

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

[PATCH 4/5] irq: generic-chip: provide devm_irq_alloc_generic_chip()

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

[PATCH 5/5] irq: generic-chip: provide devm_irq_setup_generic_chip()

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

[PATCH 2/5] irq: generic-chip: provide irq_destroy_generic_chip()

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(+)

Re: [PATCH v5 28/32] x86/mm, kexec: Allow kexec to be used with SME

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

Re: [PATCH v5 28/32] x86/mm, kexec: Allow kexec to be used with SME

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

Re: [PATCH v5 32/32] x86/mm: Add support to make use of Secure Memory Encryption

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

Re: [PATCH v5 29/32] x86/mm: Add support to encrypt the kernel in-place

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

[xfstests PATCH v3 0/5] add a test for reporting writeback errors across all fds on fsync

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

[xfstests PATCH v3 2/5] ext4: allow ext4 to use $SCRATCH_LOGDEV

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

[xfstests PATCH v3 4/5] ext3: allow it to put journal on a separate device when doing scratch_mkfs

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()

[xfstests PATCH v3 3/5] generic: test writeback error handling on dmerror devices

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

[xfstests PATCH v3 5/5] btrfs: allow it to use $SCRATCH_LOGDEV

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

[xfstests PATCH v3 1/5] generic: add a writeback error handling test

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

[PATCH v5 01/17] lib: add errseq_t type and infrastructure for handling it

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

[PATCH v5 02/17] fs: new infrastructure for writeback error handling and reporting

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

[PATCH v5 00/17] fs: introduce new writeback error reporting and convert ext2 and ext4 to use it

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

[PATCH v5 04/17] fs: add a new fstype flag to indicate how writeback errors are tracked

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

[PATCH v5 03/17] mm: tracepoints for writeback error events

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 +-

[PATCH v5 05/17] Documentation: flesh out the section in vfs.txt on storing and reporting writeback errors

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

[PATCH v5 10/17] block: add sync_blockdev_since and sync_filesystem_since

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

[PATCH v5 08/17] dax: set errors in mapping when writeback fails

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

[PATCH v5 06/17] fs: adapt sync_file_range to new reporting infrastructure

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

[PATCH v5 09/17] block: convert to errseq_t based writeback error tracking

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

[PATCH v5 12/17] fs: allow __generic_file_fsync to support both flavors of error reporting

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 ---

[PATCH v5 15/17] fs: add a write_one_page_since

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

[PATCH v5 13/17] jbd2: conditionally handle errors using errseq_t based on FS_WB_ERRSEQ flag

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

[PATCH v5 16/17] ext2: convert to errseq_t based writeback error tracking

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

[PATCH v5 17/17] fs: convert ext2 to use write_one_page_since

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

[PATCH v5 07/17] mm: add filemap_fdatawait_range_since and filemap_write_and_wait_range_since

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

[PATCH v5 11/17] fs: add f_md_wb_err field to struct file for tracking metadata errors

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

Re: [PATCH v5 17/32] x86/mm: Add support to access boot related data in the clear

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

Re: [PATCH 12/29] rtc.txt: standardize document format

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

Re: [PATCH v5 28/32] x86/mm, kexec: Allow kexec to be used with SME

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

Re: [PATCH v5 29/32] x86/mm: Add support to encrypt the kernel in-place

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

Re: [PATCH v5 32/32] x86/mm: Add support to make use of Secure Memory Encryption

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

Re: [PATCH v5 32/32] x86/mm: Add support to make use of Secure Memory Encryption

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