This series fixes the fallback of the top-down mmap: in case of
failure, a bottom-up scheme can be tried as a last resort between
the top-down mmap base and the stack, hoping for a large unused stack
limit.
Lots of architectures and even mm code start this fallback
at TASK_UNMAPPED_BASE, which is
Fix a spelling typo in the function comment.
Signed-off-by: Harry Pan
---
drivers/usb/core/hub.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 8d4631c81b9f..1988f8f88f75 100644
--- a/drivers/usb/core/hub.c
+++
On Thu, Jun 20, 2019 at 11:11:28AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the jc_docs tree got a conflict in:
>
> Documentation/fb/fbcon.rst
>
> between commit:
>
> fce677d7e8f0 ("docs: fb: Add TER16x32 to the available font names")
>
> from the
>From: Russell King - ARM Linux admin
>
>On Wed, Jun 19, 2019 at 11:23:01AM +, Parshuram Raju Thombare wrote:
>
>> >From: Russell King - ARM Linux admin
>
>> >
>
>> >On Wed, Jun 19, 2019 at 09:40:46AM +0100, Parshuram Thombare wrote:
>
>> >
>
>> >> This patch add support for SGMII interface)
When sys_hung_task_warnings reaches 0, the hang task messages will not
be reported any more.
If the user want to get more hung task messages, he must reset
kernel.hung_task_warnings to a postive integer or -1 with sysctl.
This is not a good way for the user.
We'd better reset hung task warnings
On Wed, Jun 12, 2019 at 2:06 AM Maximilian Luz wrote:
>
> Since there are no comments on this, should I simply submit this as patch?
No top post, please.
And yes, submit it as a series. Also Cc to Benjamin Tissoires.
> On 6/1/19 9:07 PM, Maximilian Luz wrote:
> > Hi,
> >
> > any comments on
On Wed 19-06-19 16:25:14, Shakeel Butt wrote:
> Currently for CONFIG_SLUB, if a memcg kmem cache creation is failed and
> the corresponding root kmem cache has SLAB_PANIC flag, the kernel will
> be crashed. This is unnecessary as the kernel can handle the creation
> failures of memcg kmem caches.
Hi all,
Today's linux-next merge of the char-misc tree got a conflict in:
drivers/misc/mei/debugfs.c
between commit:
5666d896e838 ("mei: no need to check return value of debugfs_create
functions")
from the driver-core tree and commit:
b728ddde769c ("mei: Convert to use
From: Aliasgar Surti
checkpatch reported "WARNING: line over 80 characters".
This patch fixes the warning for file davinci_vpfe/dm365_isif.c
Signed-off-by: Aliasgar Surti
---
drivers/staging/media/davinci_vpfe/dm365_isif.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff
selftests: bpf: test_align failed running Linux -next kernel
5.2.0-rc5-next-20190619.
Here is the log from x86_64,
# selftests bpf test_align
bpf: test_align_ #
# Test 0 mov ... PASS
0: mov_... #
# Test 1 shift ... PASS
1: shift_... #
# Test 2 addsub ... PASS
2: addsub_... #
# Test 3 mul
Alastair D'Silva's on June 20, 2019 2:12 pm:
> From: Alastair D'Silva
>
> If an OpenCAPI context is to be used directly by a kernel driver, there
> may not be a suitable mm to use.
>
> The patch makes the mm parameter to ocxl_context_attach optional.
>
> Signed-off-by: Alastair D'Silva
Yeah
From: Dan Williams
A platform-driver for nvme resources needs access to struct nvme_dev and
other definitions that are currently local to pci.c.
Signed-off-by: Dan Williams
Signed-off-by: Daniel Drake
---
drivers/nvme/host/pci.c | 125 +---
Provide a platform driver for the nvme resources that may be remapped
behind an ahci bar on common Intel platforms. The implementation relies
on the standard nvme driver, but reimplements the nvme_dev_ops accordingly.
As the original NVMe PCI device is inaccessible, this driver is somewhat
From: Dan Williams
In preparation for adding a platform_device nvme host, rename to a more
generic "mmio" prefix.
Signed-off-by: Dan Williams
Signed-off-by: Daniel Drake
---
drivers/nvme/host/pci.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff
Intel SATA AHCI controllers support a strange mode where NVMe devices
disappear from the PCI bus, and instead are remapped into AHCI PCI memory
space.
Many current and upcoming consumer products ship with the AHCI controller
in this "RAID" or "Intel RST Premium with Intel Optane System
In preparation for a platform device nvme driver, move the bus specific
portions of nvme to nvme_dev_ops, or otherwise rewrite routines to use a
generic 'struct device' instead of 'struct pci_dev'.
Based on earlier work by Dan Williams.
Signed-off-by: Daniel Drake
---
drivers/nvme/host/pci.c |
Intel SATA AHCI controllers support a strange mode where NVMe devices
disappear from the PCI bus, and instead are remapped into AHCI PCI memory
space.
Many current and upcoming consumer products ship with the AHCI controller
in this "RAID" or "Intel RST Premium with Intel Optane System
>>From: Jose Abreu [mailto:jose.ab...@synopsys.com]
>>From: Florian Fainelli
>>
>>> +Russell,
>>>
>>> On 6/4/2019 11:58 AM, Voon Weifeng wrote:
>>> > From: Ong Boon Leong
>>> >
>>> > xPCS is DWC Ethernet Physical Coding Sublayer that may be integrated
>>> > into a GbE controller that uses DWC
Now that x86 and parisc do not use those fields anymore, remove them from
mm code.
Signed-off-by: Alexandre Ghiti
---
include/linux/mm_types.h | 2 --
mm/debug.c | 4 ++--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/include/linux/mm_types.h
Bottom-up mmap scheme is used twice:
- for legacy mode, in which mmap_legacy_base and mmap_compat_legacy_base
are respectively equal to mmap_base and mmap_compat_base.
- in case of mmap failure in top-down mode, where there is no need to go
through the whole address space again for the bottom-up
Bottom-up mmap scheme is used twice:
- for legacy mode, in which mmap_legacy_base and mmap_base are equal.
- in case of mmap failure in top-down mode, where there is no need to go
through the whole address space again for the bottom-up fallback: the goal
of this fallback is to find, as a last
In case of mmap failure in top-down mode, there is no need to go through
the whole address space again for the bottom-up fallback: the goal of this
fallback is to find, as a last resort, space between the top-down mmap base
and the stack, which is the only place not covered by the top-down mmap.
On Thu, Jun 20, 2019 at 10:32:48AM +0530, Aliasgar Surti wrote:
> From: Aliasgar Surti
>
> checkpatch reported "WARNING: line over 80 characters".
> This patch fixes the warning for file davinci_vpfe/dm365_isif.c
>
> Signed-off-by: Aliasgar Surti
> ---
>
In case of mmap failure in top-down mode, there is no need to go through
the whole address space again for the bottom-up fallback: the goal of this
fallback is to find, as a last resort, space between the top-down mmap base
and the stack, which is the only place not covered by the top-down mmap.
The helper vmx_xsaves_supported() returns the bit value of
SECONDARY_EXEC_XSAVES in vmcs_config.cpu_based_2nd_exec_ctrl, which
remains unchanged true if vmcs supports 1-setting of this bit after
setup_vmcs_config(). It should check the guest's cpuid not this
unchanged value when get/set msr.
In case of mmap failure in top-down mode, there is no need to go through
the whole address space again for the bottom-up fallback: the goal of this
fallback is to find, as a last resort, space between the top-down mmap base
and the stack, which is the only place not covered by the top-down mmap.
In case of mmap failure in top-down mode, there is no need to go through
the whole address space again for the bottom-up fallback: the goal of this
fallback is to find, as a last resort, space between the top-down mmap base
and the stack, which is the only place not covered by the top-down mmap.
From: Aliasgar Surti
checkpatch reported "WARNING: line over 80 characters".
This patch fixes the warning for file davinci_vpfe/dm365_isif.c
Signed-off-by: Aliasgar Surti
---
drivers/staging/media/davinci_vpfe/dm365_isif.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff
On Wed, Jun 19, 2019 at 01:13:40PM -0400, Joel Fernandes wrote:
< snip >
Ccing Vladimir
> > > > > > +static int madvise_cold_pte_range(pmd_t *pmd, unsigned long addr,
> > > > > > + unsigned long end, struct mm_walk *walk)
> > > > > > +{
> > > > > > + pte_t *orig_pte,
On 6/18/19 4:09 AM, Bitan Biswas wrote:
The usage of BUG() macro is generally discouraged in kernel, unless
it's a problem that results in a physical damage or loss of data.
This patch removes unnecessary BUG() macros and replaces the rest
with warning.
Signed-off-by: Bitan Biswas
---
On Wed, Jun 12, 2019 at 6:36 PM Tomasz Figa wrote:
>
> When the application calls VIDIOC_DQBUF with the DMABUF memory type, the
> v4l2_buffer structure (or v4l2_plane structures) are filled with DMA-buf
> file descriptors. However, the current documentation does not explain
> whether those are
On Wed, 2019-06-19 at 14:30 +0200, Miklos Szeredi wrote:
> While this is a standard option as documented in mount(8), it is ignored by
> most filesystems. So reject, unless filesystem explicitly wants to handle
> it.
>
> The exception is unconverted filesystems, where it is unknown if the
>
On Wed, Jun 19, 2019 at 9:02 AM Gustavo A. R. Silva
wrote:
>
> Notice that in this case, it's much clearer to explicitly add a break
> rather than letting the code to fall through. It also avoid potential
> future fall-through warnings[1].
>
> This patch is part of the ongoing efforts to enable
>
Hi David,
Commit
0b8f4f05f41a ("afs: Add some callback tracepoints")
is missing a Signed-off-by from its author and committer.
--
Cheers,
Stephen Rothwell
pgppOKf05bf8B.pgp
Description: OpenPGP digital signature
Hi David,
On Wed, 19 Jun 2019 16:09:01 +0100 David Howells wrote:
>
> Could you add my keys-next and afs-next branches to linux-next? They can be
> found here:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git#keys-next
>
On Sat, 8 Jun 2019 21:21:11 +0800
Liu Yi L wrote:
> This patch adds sample driver named vfio-mdev-pci. It is to wrap
> a PCI device as a mediated device. For a pci device, once bound
> to vfio-mdev-pci driver, user space access of this device will
> go through vfio mdev framework. The usage of
On Wed, Jun 19, 2019 at 02:10:22PM -0500, Bjorn Helgaas wrote:
> On Wed, Jun 19, 2019 at 12:48 PM Puranjay Mohan wrote:
> >
> > skfbi.h defines its own copies of PCI_COMMAND, PCI_STATUS, etc.
> > remove them in favor of the generic definitions in
> > include/uapi/linux/pci_regs.h
>
> 1) Since
On Wed, Jun 19, 2019 at 03:24:50PM +0200, Michal Hocko wrote:
> On Mon 10-06-19 20:12:51, Minchan Kim wrote:
> [...]
> > +static int madvise_pageout_pte_range(pmd_t *pmd, unsigned long addr,
> > + unsigned long end, struct mm_walk *walk)
>
> Again the same question about
From: Alastair D'Silva
If an OpenCAPI context is to be used directly by a kernel driver, there
may not be a suitable mm to use.
The patch makes the mm parameter to ocxl_context_attach optional.
Signed-off-by: Alastair D'Silva
---
arch/powerpc/mm/book3s64/radix_tlb.c | 5 +
On Wed, Jun 19, 2019 at 10:00:06AM +0100, Colin King wrote:
> From: Colin Ian King
>
> Pointer 'node' is assigned a value that is never read, node is
> later overwritten when it re-assigned a different value inside
> the while-loop. The assignment is redundant and can be removed.
>
>
> 在 2019年6月19日，19:08，Jan Kara 写道：
>
> On Mon 17-06-19 23:57:12, jinshui zhang wrote:
>> From: zhangjs
>>
>> If the task is unplugged when called, the inode_readahead_blks may not be
>> merged,
>> these will cause small pieces of io, It should be plugged.
>>
>> Signed-off-by: zhangjs
>
>
Hello dear,
We are in the market for your products after meeting at your stand during last
expo.
Please kindly send us your latest catalog and price list so as to start a new
project/order as promised during the exhibition.
I would appreciate your response about the above details required
Hi all,
On Thu, Jun 20, 2019 at 08:54:28AM +0800, Leo Yan wrote:
[...]
> diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
> index 51dd00f65709..cf5906d667aa 100644
> --- a/tools/perf/Makefile.config
> +++ b/tools/perf/Makefile.config
> @@ -418,6 +418,26 @@ ifdef CORESIGHT
>
Arm and arm64 architecture reserve some memory regions prior to the
symbol '_stext' and these memory regions later will be used by device
module and BPF jit. The current code misses to consider these memory
regions thus any address in the regions will be taken as user space
mode, but perf cannot
On Mon, Jun 17, 2019 at 11:57:12PM +0800, jinshui zhang wrote:
> From: zhangjs
>
> If the task is unplugged when called, the inode_readahead_blks may not be
> merged,
> these will cause small pieces of io, It should be plugged.
>
> Signed-off-by: zhangjs
Thanks, applied.
I cleaned up the
Hi all,
Today's linux-next merge of the apparmor tree got a conflict in:
security/apparmor/include/policy.h
between commit:
23375b13f98c ("apparmor: fix PROFILE_MEDIATES for untrusted input")
from Linus' tree and commit:
06c13f554a71 ("apparmor: re-introduce a variant of
Martin Blumenstingl writes:
> Avoid polling of the PHY status by passing the Ethernet PHY's GPIO
> interrupt line to the PHY node.
>
> I tested this successfully on my X96 Max, but I don't have an Odroid-N2
> to test it there. The reset and interrupt GPIO part of the schematics
> seems to be
>-Original Message-
>From: Gomes, Vinicius
>> +++ b/drivers/net/ethernet/stmicro/stmmac/dw_tsn_lib.c
>> @@ -0,0 +1,790 @@
>> +
>> +static struct tsn_hw_cap dw_tsn_hwcap;
>> +static bool dw_tsn_feat_en[TSN_FEAT_ID_MAX];
>> +static unsigned int dw_tsn_hwtunable[TSN_HWTUNA_MAX];
>> +static
> -Original Message-
> From: Rob Herring
> Sent: 2019年6月19日 22:07
> To: Wen He
> Cc: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; shawn...@kernel.org; Leo Li
>
> Subject: Re: [EXT] Re: [v1 1/4] dt-bindings: display: Add DT bindings
Martin Blumenstingl writes:
> While trying to add the Ethernet PHY interrupt on the X96 Max I found
> that the current reset line definition is incorrect. Patch #1 fixes
> this.
>
> Since the fix requires moving from the deprecated "snps,reset-gpio"
> property to the generic Ethernet PHY reset
The mm-of-the-moment snapshot 2019-06-19-20-32 has been uploaded to
http://www.ozlabs.org/~akpm/mmotm/
mmotm-readme.txt says
README for mm-of-the-moment:
http://www.ozlabs.org/~akpm/mmotm/
This is a snapshot of my -mm patch queue. Uploaded at random hopefully
more than once a week.
You
On Thu, 2019-06-20 at 12:10 +1000, Stephen Rothwell wrote:
> 2d3c72ed5041 ("rdma: Remove nes")
Yeah, not much you can do about tree wide patchsets conflicting with a
removal ;-)
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57
On Thu, 2019-06-20 at 12:06 +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the rdma tree got a conflict in:
>
> include/rdma/ib_verbs.h
>
> between commit:
>
> dc1435c00fcd ("RDMA/srp: Rename SRP sysfs name after IB device
> rename trigger")
>
> from Linus' tree
>> > It looks like most o the TSN_WARN should actually be netdev_dbg().
>> >
>> >Andrew
>>
>> Hi Andrew,
>> This file is targeted for dual licensing which is GPL-2.0 OR BSD-3-Clause.
>> This is the reason why we are using wrappers around the functions so that
>> all the function call is
Initialize pidfd to an invalid descriptor, to fail gracefully on
those kernels that do not implement CLONE_PIDFD and leave pidfd
unchanged.
Signed-off-by: Dmitry V. Levin
---
samples/pidfd/pidfd-metadata.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git
Their implementations are quite similar, lets modify
cpufreq_update_current_freq() a little and use it from __cpufreq_get().
Also rename cpufreq_update_current_freq() to
cpufreq_verify_current_freq(), as that's what it is doing.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq.c | 70
On some occasions cpufreq_verify_current_freq() schedules a work whose
callback is handle_update(), which further calls cpufreq_update_policy()
which may end up calling cpufreq_verify_current_freq() again.
On the other hand, when cpufreq_update_policy() is called from
handle_update(), the pointer
For code consistency, use has_target() instead of !setpolicy everywhere,
as it is already done at several places. Maybe we should also use
"!has_target()" instead of "cpufreq_driver->setpolicy" where we need to
check if the driver supports setpolicy, so to use only one expression
for this kind of
CPUFREQ_CONST_LOOPS was introduced in a very old commit from pre-2.6
kernel release commit 6a4a93f9c0d5 ("[CPUFREQ] Fix 'out of sync'
issue").
Probably the initial idea was to just avoid these checks for set_policy
type drivers and then things got changed over the years. And it is very
unclear
Hi Rafael,
I accumulated these while reworking the freq-constraint series and it
would be nice if these can get in before I send the next version of
freq-constraint stuff.
These are mostly cleanups and code consolidation for better management
of code. Compile and boot tested only.
Thanks.
cpufreq_start_governor() is only called for !setpolicy case, checking it
again is not required.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index
Hi all,
On Mon, 17 Jun 2019 12:19:59 +1000 Stephen Rothwell
wrote:
>
> Hi Leon,
>
> Today's linux-next merge of the mlx5-next tree got a conflict in:
>
> include/linux/mlx5/eswitch.h
>
> between commit:
>
> 02f3afd97556 ("net/mlx5: E-Switch, Correct type to u16 for vport_num and
> int
On Wed, Jun 19, 2019 at 05:19:07PM -0700, 'Nick Desaulniers' via Clang Built
Linux wrote:
> Add keyword support so that our mailing list gets cc'ed for clang/llvm
> patches. We're pretty active on our mailing list so far as code review.
> There are numerous Googlers like myself that are paid to
Both MT8183 & MT6765 have more control steps of bus protection
than previous project. And there add more bus protection registers
reside at infracfg & smi-common. Also add new APIs for multiple
step bus protection control with more customized arguments.
Signed-off-by: Weiyi Lu
---
Put bus protection enable and disable control in separate functions.
Signed-off-by: Weiyi Lu
---
drivers/soc/mediatek/mtk-scpsys.c | 44 ++-
1 file changed, 30 insertions(+), 14 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-scpsys.c
Try to stop extending the clk_id or clk_names if there are
more and more new BASIC clocks. To get its own clocks by the
basic_clk_id of each power domain.
Signed-off-by: Weiyi Lu
---
drivers/soc/mediatek/mtk-scpsys.c | 29 +
1 file changed, 21 insertions(+), 8
Put regulator enable and disable control in separate functions.
Signed-off-by: Weiyi Lu
---
drivers/soc/mediatek/mtk-scpsys.c | 32 +++-
1 file changed, 23 insertions(+), 9 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-scpsys.c
Put sram enable and disable control in separate functions.
Signed-off-by: Weiyi Lu
Reviewed-by: Nicolas Boichat
---
drivers/soc/mediatek/mtk-scpsys.c | 79 +--
1 file changed, 51 insertions(+), 28 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-scpsys.c
Add subsys CG control flow before/after the bus protect control
due to bus protection need SMI bus relative CGs enabled to feedback
its ack.
Signed-off-by: Weiyi Lu
---
drivers/soc/mediatek/mtk-scpsys.c | 72 +--
1 file changed, 70 insertions(+), 2
Add power controller node and smi-common node for MT8183
In scpsys node, it contains clocks and regmapping of
infracfg and smi-common for bus protection.
Signed-off-by: Weiyi Lu
---
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 62
1 file changed, 62 insertions(+)
Add power dt-bindings of MT8183 and introduces "BASIC" and
"SUBSYS" clock types in binding document.
The "BASIC" type is compatible to the original power control with
clock name [a-z]+[0-9]*, e.g. mm, vpu1.
The "SUBSYS" type is used for bus protection control with clock
name [a-z]+-[0-9]+, e.g.
Add scpsys driver for MT8183
Signed-off-by: Weiyi Lu
---
drivers/soc/mediatek/mtk-scpsys.c | 226 ++
1 file changed, 226 insertions(+)
diff --git a/drivers/soc/mediatek/mtk-scpsys.c
b/drivers/soc/mediatek/mtk-scpsys.c
index d3fdb3f..ea5a221 100644
---
For scpsys driver using regmap based syscon driver API.
Signed-off-by: Weiyi Lu
---
.../devicetree/bindings/memory-controllers/mediatek,smi-common.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Signed-off-by: Weiyi Lu
---
drivers/soc/mediatek/mtk-scpsys.c | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-scpsys.c
b/drivers/soc/mediatek/mtk-scpsys.c
index 5b24bb4..9f52f50 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++
Put clock enable and disable control in separate function.
Signed-off-by: Weiyi Lu
---
drivers/soc/mediatek/mtk-scpsys.c | 45 ---
1 file changed, 28 insertions(+), 17 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-scpsys.c
This series is based on v5.2-rc1 with MT8183 dts v11 patch[1] and
MT8183 SMI dt-binding v7 patch[2].
[1] https://patchwork.kernel.org/patch/10962375/
[2] https://patchwork.kernel.org/patch/10984743/
changes since v5:
- fix documentation in [PATCH 04/14]
- remove useless variable checking and
For some power domains like vpu_core on MT8183 whose sram need to
do clock and internal isolation while power on/off sram.
We add a flag "sram_iso_ctrl" in scp_domain_data to judge if we
need to do the extra sram isolation control or not.
Signed-off-by: Weiyi Lu
---
Use USEC_PER_SEC to indicate the polling timeout directly.
And add documentation of scp_domain_data.
Signed-off-by: Weiyi Lu
---
drivers/soc/mediatek/mtk-scpsys.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/soc/mediatek/mtk-scpsys.c
On 6/19/19 4:02 PM, Benjamin Herrenschmidt wrote:
> On Wed, 2019-06-19 at 22:32 +, Tao Ren wrote:
>> Thank you for the quick response, Brendan.
>>
>> Aspeed I2C bus frequency is defined by 3 parameters
>> (base_clk_divisor, clk_high_width, clk_low_width), and I choose
>> base_clk_divisor
Remove pHalData variable as it is set but unused in function.
Remove pU1Tmp and replace this with pu8
Signed-off-by: Hariprasad Kelam
---
drivers/staging/rtl8723bs/hal/hal_btcoex.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git
This patch adds uffd tests for write protection.
Instead of introducing new tests for it, let's simply squashing uffd-wp
tests into existing uffd-missing test cases. Changes are:
(1) Bouncing tests
We do the write-protection in two ways during the bouncing test:
- By using
Only declare _UFFDIO_WRITEPROTECT if the user specified
UFFDIO_REGISTER_MODE_WP and if all the checks passed. Then when the
user registers regions with shmem/hugetlbfs we won't expose the new
ioctl to them. Even with complete anonymous memory range, we'll only
expose the new WP ioctl bit if the
Introduce uffd_stats structure for statistics of the self test, at the
same time refactor the code to always pass in the uffd_stats for either
read() or poll() typed fault handling threads instead of using two
different ways to return the statistic results. No functional change.
With the new
From: Martin Cracauer
Adds documentation about the write protection support.
Signed-off-by: Martin Cracauer
Signed-off-by: Andrea Arcangeli
[peterx: rewrite in rst format; fixups here and there]
Reviewed-by: Jerome Glisse
Reviewed-by: Mike Rapoport
Signed-off-by: Peter Xu
---
It does not make sense to try to wake up any waiting thread when we're
write-protecting a memory region. Only wake up when resolving a write
protected page fault.
Reviewed-by: Mike Rapoport
Signed-off-by: Peter Xu
---
fs/userfaultfd.c | 13 -
1 file changed, 8 insertions(+), 5
From: Shaohua Li
Now it's safe to enable write protection in userfaultfd API
Cc: Andrea Arcangeli
Cc: Pavel Emelyanov
Cc: Rik van Riel
Cc: Kirill A. Shutemov
Cc: Mel Gorman
Cc: Hugh Dickins
Cc: Johannes Weiner
Signed-off-by: Shaohua Li
Signed-off-by: Andrea Arcangeli
Reviewed-by:
From: Shaohua Li
Add API to enable/disable writeprotect a vma range. Unlike mprotect,
this doesn't split/merge vmas.
Cc: Andrea Arcangeli
Cc: Rik van Riel
Cc: Kirill A. Shutemov
Cc: Mel Gorman
Cc: Hugh Dickins
Cc: Johannes Weiner
Signed-off-by: Shaohua Li
Signed-off-by: Andrea Arcangeli
From: Andrea Arcangeli
v1: From: Shaohua Li
v2: cleanups, remove a branch.
[peterx writes up the commit message, as below...]
This patch introduces the new uffd-wp APIs for userspace.
Firstly, we'll allow to do UFFDIO_REGISTER with write protection
tracking using the new
Em Wed, 19 Jun 2019 23:27:53 +0200
Peter Zijlstra escreveu:
> On Wed, Jun 19, 2019 at 10:19:22AM -0300, Mauro Carvalho Chehab wrote:
> > (c/c list cleaned)
> >
> > Em Wed, 19 Jun 2019 13:43:56 +0200
> > Peter Zijlstra escreveu:
> >
> > > On Tue, Jun 18, 2019 at 05:53:17PM -0300, Mauro
Don't collapse the huge PMD if there is any userfault write protected
small PTEs. The problem is that the write protection is in small page
granularity and there's no way to keep all these write protection
information if the small pages are going to be merged into a huge PMD.
The same thing
We've have multiple (and more coming) places that would like to find a
userfault enabled VMA from a mm struct that covers a specific memory
range. This patch introduce the helper for it, meanwhile apply it to
the code.
Suggested-by: Mike Rapoport
Reviewed-by: Jerome Glisse
Reviewed-by: Mike
Firstly, introduce two new flags MM_CP_UFFD_WP[_RESOLVE] for
change_protection() when used with uffd-wp and make sure the two new
flags are exclusively used. Then,
- For MM_CP_UFFD_WP: apply the _PAGE_UFFD_WP bit and remove _PAGE_RW
when a range of memory is write protected by uffd
-
change_protection() was used by either the NUMA or mprotect() code,
there's one parameter for each of the callers (dirty_accountable and
prot_numa). Further, these parameters are passed along the calls:
- change_protection_range()
- change_p4d_range()
- change_pud_range()
-
UFFD_EVENT_FORK support for uffd-wp should be already there, except
that we should clean the uffd-wp bit if uffd fork event is not
enabled. Detect that to avoid _PAGE_UFFD_WP being set even if the VMA
is not being tracked by VM_UFFD_WP. Do this for both small PTEs and
huge PMDs.
Reviewed-by:
Adding these missing helpers for uffd-wp operations with pmd
swap/migration entries.
Reviewed-by: Jerome Glisse
Reviewed-by: Mike Rapoport
Signed-off-by: Peter Xu
---
arch/x86/include/asm/pgtable.h | 15 +++
include/asm-generic/pgtable_uffd.h | 15 +++
2 files
For either swap and page migration, we all use the bit 2 of the entry to
identify whether this entry is uffd write-protected. It plays a similar
role as the existing soft dirty bit in swap entries but only for keeping
the uffd-wp tracking for a specific PTE/PMD.
Something special here is that
From: Shaohua Li
add helper for writeprotect check. Will use it later.
Cc: Andrea Arcangeli
Cc: Pavel Emelyanov
Cc: Rik van Riel
Cc: Kirill A. Shutemov
Cc: Mel Gorman
Cc: Hugh Dickins
Cc: Johannes Weiner
Signed-off-by: Shaohua Li
Signed-off-by: Andrea Arcangeli
Reviewed-by: Jerome
From: Andrea Arcangeli
This allows UFFDIO_COPY to map pages write-protected.
Signed-off-by: Andrea Arcangeli
[peterx: switch to VM_WARN_ON_ONCE in mfill_atomic_pte; add brackets
around "dst_vma->vm_flags & VM_WRITE"; fix wordings in comments and
commit messages]
Reviewed-by: Jerome Glisse
From: Andrea Arcangeli
There are several cases write protection fault happens. It could be a
write to zero page, swaped page or userfault write protected
page. When the fault happens, there is no way to know if userfault
write protect the page before. Here we just blindly issue a userfault
From: Andrea Arcangeli
Implement helpers methods to invoke userfaultfd wp faults more
selectively: not only when a wp fault triggers on a vma with
vma->vm_flags VM_UFFD_WP set, but only if the _PAGE_UFFD_WP bit is set
in the pagetable too.
Signed-off-by: Andrea Arcangeli
Reviewed-by: Jerome
1 - 100 of 886 matches
Mail list logo
