MHI userspace client driver is creating device file node
for user application to perform file operations. File
operations are handled by MHI core driver. Currently
Loopback MHI channel is supported by this driver.
Signed-off-by: Hemant Kumar
---
Documentation/mhi/index.rst | 1 +
Introduce mhi_get_free_desc_count() API to return number
of TREs available to queue buffer. MHI clients can use this
API to know before hand if ring is full without calling queue
API.
Signed-off-by: Hemant Kumar
Reviewed-by: Jeffrey Hugo
---
drivers/bus/mhi/core/main.c | 12
Currently this macro is defined in internal MHI header as
a TRE length mask. Moving it to external header allows MHI
client drivers to set this upper bound for the transmit
buffer size.
Signed-off-by: Hemant Kumar
Reviewed-by: Jeffrey Hugo
---
drivers/bus/mhi/core/internal.h | 1 -
When flags don't have MPOL_MF_MOVE or MPOL_MF_MOVE_ALL bits, code breaks
and passing origin pte - 1 to pte_unmap_unlock seems like not a good idea.
Signed-off-by: Shijie Luo
Signed-off-by: Michal Hocko
Signed-off-by: Miaohe Lin
---
mm/mempolicy.c | 6 +++---
1 file changed, 3 insertions(+),
On receiving the MEM_GOING_OFFLINE notification, we disallow offlining of
any boot memory by checking if section_early or not. With the introduction
of SECTION_MARK_HOTPLUGGABLE, allow boot mem sections that are marked as
hotpluggable with this bit set to be offlined and removed. This now allows
Certain architectures such as arm64 doesn't allow boot memory to be
offlined and removed. Distinguish certain memory sections as
"hotpluggable" which can be marked by module drivers stating to memory
hotplug layer that these sections can be offlined and then removed.
This is done by using a
In the patch that enables memory hot-remove (commit bbd6ec605c0f ("arm64/mm:
Enable memory hot remove")) for arm64, there’s a notifier put in place that
prevents boot memory from being offlined and removed. The commit text mentions
that boot memory on arm64 cannot be removed. But x86 and other
This is the fourth attempt of inheriting the stream mapping for the framebuffer
on many Qualcomm platforms, in order to not hit catastrophic faults during
arm-smmu initialization.
The new approach does, based on Robin's suggestion, take a much more direct
approach with the allocation of a context
The Qualcomm boot loader configures stream mapping for the peripherals
that it accesses and in particular it sets up the stream mapping for the
display controller to be allowed to scan out a splash screen or EFI
framebuffer.
Read back the stream mappings during initialization and make the
The firmware found in some Qualcomm platforms intercepts writes to S2CR
in order to replace bypass type streams with fault; and ignore S2CR
updates of type fault.
Detect this behavior and implement a custom write_s2cr function in order
to trick the firmware into supporting bypass streams by the
The firmware found in some Qualcomm platforms intercepts writes to the
S2CR register in order to replace the BYPASS type with FAULT. Further
more it treats faults at this level as catastrophic and restarts the
device.
Add support for providing implementation specific versions of the S2CR
write
On Sat, Oct 17, 2020 at 7:37 AM Willy Tarreau wrote:
> On Sat, Oct 17, 2020 at 07:01:31AM +0200, Jann Horn wrote:
> > Microsoft's documentation
> > (http://go.microsoft.com/fwlink/?LinkId=260709) says that the VM
> > Generation ID that we get after a fork "is a 128-bit,
> > cryptographically
Hi Jacopo,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 8119c4332d253660e0a6b8748fe0749961cfbc97
commit: b18ee53ad297264a79cf4ea53f20786b6455 staging: bcm2835: Break MMAL
support out from camera
date: 4
On Fri, Oct 16, 2020 at 09:27:53PM -0400, j...@joelfernandes.org wrote:
[..]
> > > + *
> > > + * Memory barrier is needed after adding to length for the case
> > > + * where length transitions from 0 -> 1. This is because rcu_barrier()
> > > + * should never miss an update to the length. So the
On 10/16/20 3:29 PM, Bjorn Helgaas wrote:
[+cc Christoph, Ethan, Sinan, Keith; sorry should have cc'd you to
begin with since you're looking at this code too. Particularly
interested in your thoughts about whether we should be touching
PCI_ERR_ROOT_COMMAND and PCI_ERR_ROOT_STATUS when we
On Sat, Oct 17, 2020 at 8:26 AM Joe Perches wrote:
>
> On Wed, 2020-10-14 at 11:35 -0700, Joe Perches wrote:
> > On Wed, 2020-10-14 at 23:42 +0530, Dwaipayan Ray wrote:
> > > On Wed, Oct 14, 2020 at 11:33 PM Joe Perches wrote:
> > > > On Wed, 2020-10-14 at 22:07 +0530, Dwaipayan Ray wrote:
> > >
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 071a0578b0ce0b0e543d1e38ee6926b9cc21c198
commit: f0fe00d4972a8cd4b98cc2c29758615e4d51cdfe security: allow using Clang's
zero initialization for stack variables
date: 4 months ago
config:
On Mon, 2020-10-05 at 14:52 -0400, Nitesh Narayan Lal wrote:
> On 10/4/20 7:14 PM, Frederic Weisbecker wrote:
> > On Sun, Oct 04, 2020 at 02:44:39PM +, Alex Belits wrote:
> > > On Thu, 2020-10-01 at 15:56 +0200, Frederic Weisbecker wrote:
> > > > External Email
> > > >
> > > >
Hi,
On Fri, Oct 16, 2020 at 7:01 PM Stephen Boyd wrote:
>
> Quoting Stephen Boyd (2020-10-15 20:16:27)
> > Quoting Douglas Anderson (2020-10-14 17:13:29)
> > > From: Taniya Das
> > >
> > > In the case where the PLL configuration is lost, then the pm runtime
> > > resume will reconfigure before
> + if (priv->is_aspeed &&
> + phy_intf != PHY_INTERFACE_MODE_RMII &&
> + phy_intf != PHY_INTERFACE_MODE_RGMII &&
> + phy_intf != PHY_INTERFACE_MODE_RGMII_ID &&
> + phy_intf != PHY_INTERFACE_MODE_RGMII_RXID &&
> +
On Tue, 2020-10-06 at 12:35 +0200, Frederic Weisbecker wrote:
> On Mon, Oct 05, 2020 at 02:52:49PM -0400, Nitesh Narayan Lal wrote:
> > On 10/4/20 7:14 PM, Frederic Weisbecker wrote:
> > > On Sun, Oct 04, 2020 at 02:44:39PM +, Alex Belits wrote:
> > >
> > > > The idea behind this is that
On Fri, Oct 16, 2020 at 01:07:47PM +0200, Peter Zijlstra wrote:
> On Fri, Oct 09, 2020 at 12:42:54PM -0700, ira.we...@intel.com wrote:
> > +static inline void pks_update_protection(int pkey, unsigned long
> > protection)
> > +{
> > + current->thread.saved_pkrs =
On 2020/10/16 22:05, osalva...@suse.de wrote:
On 2020-10-16 15:42, Michal Hocko wrote:
OK, I finally managed to convince my friday brain to think and grasped
what the code is intended to do. The loop is hairy and we want to
prevent from spurious EIO when all the pages are on a proper node. So
On Sat, 2020-10-17 at 10:52 +0530, Dwaipayan Ray wrote:
> Recently, commit 4f6ad8aa1eac ("checkpatch: move repeated word test")
> moved the repeated word test to check for more file types. But after
> this, if checkpatch.pl is run on MAINTAINERS, it generates several
> new warnings of the type:
>
On Fri, 2020-10-16 at 14:35 +0200, Pavel Machek wrote:
> Hi!
>
> I'm getting this during boot: 32-bit thinkpad x60.
This is very odd.
The change in next is essentially a revert of a change, maybe I'm
missing something and the revert isn't quite a revert. Although
there was one difference.
I'll
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 071a0578b0ce0b0e543d1e38ee6926b9cc21c198
commit: 8f28ca6bd8211214faf717677bbffe375c2a6072 iomap: constify ioreadX()
iomem argument (as in generic implementation)
date: 9 weeks ago
config:
On Fri, Oct 16, 2020 at 03:10:26PM +0100, Robin Murphy wrote:
> On 2020-10-16 04:53, Nicolin Chen wrote:
> > On Thu, Oct 15, 2020 at 10:55:52AM +0100, Robin Murphy wrote:
> > > On 2020-10-15 05:13, Nicolin Chen wrote:
> > > > On Wed, Oct 14, 2020 at 06:42:36PM +0100, Robin Murphy wrote:
> > > > >
Remove including that don't need it.
Signed-off-by: Tian Tao
---
drivers/block/skd_main.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/block/skd_main.c b/drivers/block/skd_main.c
index ae6454c..a962b45 100644
--- a/drivers/block/skd_main.c
+++ b/drivers/block/skd_main.c
@@ -25,7
On Sat, Oct 17, 2020 at 6:34 AM Colm MacCarthaigh wrote:
> On 16 Oct 2020, at 21:02, Jann Horn wrote:
> > On Sat, Oct 17, 2020 at 5:36 AM Willy Tarreau wrote:
> > But in userspace, we just need a simple counter. There's no need for
> > us to worry about anything else, like timestamps or
Jakub Kicinski wrote:
> On Fri, 16 Oct 2020 14:23:48 -0700 Jesse Brandeburg wrote:
> > > These are tested to be the latest as part of the tools/lib/bpf build.
> >
> > But you didn't mention why you're making these changes, and you're
> > removing a lot of comments without explaining why/where
On Fri, Oct 16, 2020 at 01:06:36PM +0200, Peter Zijlstra wrote:
> On Fri, Oct 09, 2020 at 12:42:53PM -0700, ira.we...@intel.com wrote:
>
> > @@ -644,6 +663,8 @@ void __switch_to_xtra(struct task_struct *prev_p,
> > struct task_struct *next_p)
> >
> > if ((tifp ^ tifn) & _TIF_SLD)
> >
Quoting Stephen Boyd (2020-10-15 20:16:27)
> Quoting Douglas Anderson (2020-10-14 17:13:29)
> > From: Taniya Das
> >
> > In the case where the PLL configuration is lost, then the pm runtime
> > resume will reconfigure before usage.
>
> Taniya, this commit needs a lot more describing than one
On Sat, Oct 17, 2020 at 07:01:31AM +0200, Jann Horn wrote:
> Microsoft's documentation
> (http://go.microsoft.com/fwlink/?LinkId=260709) says that the VM
> Generation ID that we get after a fork "is a 128-bit,
> cryptographically random integer value". If multiple people use the
> same image, it
If the GDSC is enabled out of boot but doesn't have the retain ff bit
set we will get confusing results where the registers that are powered
by the GDSC lose their contents on the first power off of the GDSC but
thereafter they retain their contents. This is because gdsc_init() fails
to make sure
On Fri, Oct 16, 2020 at 01:12:26PM +0200, Peter Zijlstra wrote:
> On Tue, Oct 13, 2020 at 11:31:45AM -0700, Dave Hansen wrote:
> > > +/**
> > > + * It should also be noted that the underlying WRMSR(MSR_IA32_PKRS) is
> > > not
> > > + * serializing but still maintains ordering properties similar
From: Palmer Dabbelt
I was going to copy this but I didn't want to chase around the build
system stuff so I did it a different way.
Signed-off-by: Palmer Dabbelt
---
arch/nds32/kernel/vdso/gen_vdso_offsets.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Fri, Oct 16, 2020 at 12:57:43PM +0200, Peter Zijlstra wrote:
> On Fri, Oct 09, 2020 at 12:42:51PM -0700, ira.we...@intel.com wrote:
> > From: Fenghua Yu
> >
> > Define a helper, update_pkey_val(), which will be used to support both
> > Protection Key User (PKU) and the new Protection Key for
On Fri, Oct 16, 2020 at 10:02:24PM +0200, Christian Eggers wrote:
> Ensure that the skb is not cloned and has enough tail room for the tail
> tag. This code will be removed from the drivers in the next commits.
>
> Signed-off-by: Christian Eggers
> ---
Does 1588 work for you using this change,
Hi Linus
On Sat, 17 Oct 2020 at 01:56, Linus Walleij wrote:
> (...)
>
> > +config GPIO_MSC313
> > + bool "MStar MSC313 GPIO support"
> > + default y if ARCH_MSTARV7
> > + depends on ARCH_MSTARV7
> > + select GPIO_GENERIC
>
> Selecting GPIO_GENERIC, that is good.
> But
From: Palmer Dabbelt
I was going to copy this but I didn't want to chase around the build
system stuff so I did it a different way.
Signed-off-by: Palmer Dabbelt
---
arch/arm64/kernel/vdso/gen_vdso_offsets.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Hi,
Thank you for examine this patch in such a careful way!
On Fri, Oct 16, 2020 at 03:00:49PM +, Barnabás Pőcze wrote:
Hi,
I still think that `i2c_hid_resume()` and `i2c_hid_suspend()` are asymmetric and
that might lead to issues.
Do you think this commit message is relevant to your
On Thu, Oct 15, 2020 at 8:39 PM Jisheng Zhang
wrote:
>
> On Thu, 15 Oct 2020 15:08:33 +0100
> Robin Murphy wrote:
>
> >
> >
> > On 2020-10-15 10:52, Jisheng Zhang wrote:
> > > On Thu, 15 Oct 2020 01:48:13 -0700
> > > Saravana Kannan wrote:
> > >
> > >> On Thu, Oct 15, 2020 at 1:15 AM Jisheng
On Tue, 2020-10-06 at 23:41 +0200, Frederic Weisbecker wrote:
> On Sun, Oct 04, 2020 at 03:22:09PM +, Alex Belits wrote:
> > On Thu, 2020-10-01 at 16:44 +0200, Frederic Weisbecker wrote:
> > > > @@ -268,7 +269,8 @@ static void tick_nohz_full_kick(void)
> > > > */
> > > > void
defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a005-20201016
i386
On 10/16/20 3:29 PM, Bjorn Helgaas wrote:
[+cc Christoph, Ethan, Sinan, Keith; sorry should have cc'd you to
begin with since you're looking at this code too. Particularly
interested in your thoughts about whether we should be touching
PCI_ERR_ROOT_COMMAND and PCI_ERR_ROOT_STATUS when we
Recently, commit 4f6ad8aa1eac ("checkpatch: move repeated word test")
moved the repeated word test to check for more file types. But after
this, if checkpatch.pl is run on MAINTAINERS, it generates several
new warnings of the type:
WARNING: Possible repeated word: 'git'
For example:
WARNING:
This series introduces a generic pattern interface in the LED class and
a driver for the Qualcomm Light Pulse Generator.
It seems like it's been almost 3 years since I posted v3, which was hung
up on the lack of conclusion on the hw_pattern and multicolor support.
Now that those are concluded I
1. Change the fr_rx function to make this driver support any Ethertype
when receiving. (This driver is already able to handle any Ethertype
when sending.)
Originally in the fr_rx function, the code that parses the long (10-byte)
header only recognizes a few Ethertype values and drops frames with
The pm8994 contains a 6 LPG channels and the pmi8994 contains 4 MPP
channels and a 4 channel LPG, with TRILED and LUT blocks.
Add nodes for these blocks.
Signed-off-by: Bjorn Andersson
---
Changes since v4:
- Replaced msm8996 with pm(i)8994 in subject
arch/arm64/boot/dts/qcom/pm8994.dtsi |
The db820c has 4 "user LEDs", all connected to the PMI8994. The first
three are connected to the three current sinks provided by the TRILED
and the fourth is connected to MPP2.
By utilizing the DTEST bus the MPP is fed the control signal from the
fourth LPG block, providing a consistent interface
On Sat, Oct 17, 2020 at 10:12 AM Joe Perches wrote:
>
> On Sat, 2020-10-17 at 10:02 +0530, Dwaipayan Ray wrote:
> > On Sat, Oct 17, 2020 at 8:26 AM Joe Perches wrote:
> > > On Wed, 2020-10-14 at 11:35 -0700, Joe Perches wrote:
> > > > On Wed, 2020-10-14 at 23:42 +0530, Dwaipayan Ray wrote:
> > >
This adds the binding document describing the three hardware blocks
related to the Light Pulse Generator found in a wide range of Qualcomm
PMICs.
Signed-off-by: Bjorn Andersson
---
Changes since v4:
- Dropped quotes around power-source
- Moved "multi-led" to properties
- Corrected tab-indented
The Light Pulse Generator (LPG) is a PWM-block found in a wide range of
PMICs from Qualcomm. It can operate on fixed parameters or based on a
lookup-table, altering the duty cycle over time - which provides the
means for e.g. hardware assisted transitions of LED brightness.
Signed-off-by: Bjorn
On 16 Oct 2020, at 22:01, Jann Horn wrote:
On Sat, Oct 17, 2020 at 6:34 AM Colm MacCarthaigh
wrote:
For user-space, even a single bit would do. We added
MADVISE_WIPEONFORK
so that userspace libraries can detect fork()/clone() robustly, for
the
same reasons. It just wipes a page as the
It is redundant to do irqsave and irqrestore in hardIRQ context.
Signed-off-by: Tian Tao
---
drivers/char/ipmi/ipmi_si_intf.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/char/ipmi/ipmi_si_intf.c b/drivers/char/ipmi/ipmi_si_intf.c
index 45546ac..97452a8
On Thu, Oct 15, 2020 at 7:43 AM Kees Cook wrote:
>
> On Mon, Oct 12, 2020 at 05:31:45PM -0700, Sami Tolvanen wrote:
> > This change removes all instances of DISABLE_LTO from
> > Makefiles, as they are currently unused, and the preferred
> > method of disabling LTO is to filter out the flags
On 10/16/2020 09:11 PM, Pavel Machek wrote:
Hi!
Add /proc/boardinfo to get mainboard and BIOS info easily on the Loongson
platform, this is useful to point out the current used mainboard type and
BIOS version when there exists problems related with hardware or firmware.
E.g. with this patch:
Hi Konstantin,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.9 next-20201016]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base
On Sat, Oct 17, 2020 at 03:40:08AM +0200, Jann Horn wrote:
> [adding some more people who are interested in RNG stuff: Andy, Jason,
> Theodore, Willy Tarreau, Eric Biggers. also linux-api@, because this
> concerns some pretty fundamental API stuff related to RNG usage]
>
> On Fri, Oct 16, 2020 at
On Fri, Oct 16, 2020 at 9:59 PM Rasmus Villemoes
wrote:
>
> After commit 43fee2b23895 ("kbuild: do not redirect the first
> prerequisite for filechk"), the rule is no longer automatically passed
> $< as stdin, so remove the stale comment.
>
> Fixes: 43fee2b23895 ("kbuild: do not redirect the
Hi Bjorn
On Fri, Sep 25, 2020 at 04:01:38PM -0700, Ashok Raj wrote:
> When Mechanical Retention Lock (MRL) is present, Linux doesn't process
> those change events.
>
> The following changes need to be enabled when MRL is present.
>
> 1. Subscribe to MRL change events in SlotControl.
> 2. When
On 10/16/20 5:38 PM, Thomas Gleixner wrote:
> On Fri, Oct 16 2020 at 17:13, Jens Axboe wrote:
>> /**
>> * task_work_add - ask the @task to execute @work->func()
>> * @task: the task which should run the callback
>> * @work: the callback to run
>> * @notify: how to notify the targeted task
>>
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 8119c4332d253660e0a6b8748fe0749961cfbc97
commit: 868fd970e187d39c586565c875837e530c6f7e1b staging: wfx: improve
robustness of wfx_get_hw_rate()
date: 7 days ago
config: powerpc64-randconfig-r001-20201016
On Fri, Oct 16, 2020 at 05:24:14PM +0300, Andy Shevchenko wrote:
> On Wed, Oct 14, 2020 at 12:21 PM Kent Gibson wrote:
> >
> > The line.eflags field is shared so document this fact and highlight it
> > throughout using READ_ONCE() and WRITE_ONCE() accessors.
> >
> > Also use a local copy of the
On Fri, Oct 16 2020 at 17:13, Jens Axboe wrote:
> /**
> * task_work_add - ask the @task to execute @work->func()
> * @task: the task which should run the callback
> * @work: the callback to run
> * @notify: how to notify the targeted task
> *
> * Queue @work for task_work_run() below and
On Fri, 16 Oct 2020 12:12:11 +0800 Po-Hsu Lin wrote:
> The kci_test_encap_fou() test from kci_test_encap() in rtnetlink.sh
> needs the fou module to work. Otherwise it will fail with:
>
> $ ip netns exec "$testns" ip fou add port ipproto 47
> RTNETLINK answers: No such file or directory
On Fri, Oct 16, 2020 at 05:13:22PM +0300, Andy Shevchenko wrote:
> On Thu, Oct 15, 2020 at 6:53 AM Kent Gibson wrote:
> >
> > Using CLOCK_REALTIME as the source for event timestamps is crucial for
> > some specific applications, particularly those requiring timetamps
> > relative to a PTP clock,
On Sat, Oct 17, 2020 at 01:09:12AM +0200, Jann Horn wrote:
> Currently, mm_struct has two refcounts:
>
> - mm_users: preserves everything - the mm_struct, the page tables, the
>memory mappings, and so on
> - mm_count: preserves the mm_struct and pgd
>
> However, there are three types of
On Thu, Oct 15, 2020 at 08:06:06PM +0900, Benjamin Poirier wrote:
On 2020-10-15 11:37 +0800, Coiby Xu wrote:
On Tue, Oct 13, 2020 at 09:37:04AM +0900, Benjamin Poirier wrote:
> On 2020-10-12 19:24 +0800, Coiby Xu wrote:
> [...]
> > > I think, but didn't check in depth, that in those drivers,
On Thu, Oct 15, 2020 at 10:01:36AM +0900, Benjamin Poirier wrote:
On 2020-10-14 18:43 +0800, Coiby Xu wrote:
To avoid namespace clashes with other qlogic drivers and also for the
sake of naming consistency, use the "qlge_" prefix as suggested in
drivers/staging/qlge/TODO.
Suggested-by:
On Fri, Oct 16, 2020 at 12:03 PM John Stultz wrote:
> On Thu, Oct 8, 2020 at 4:51 AM Brian Starkey wrote:
> > On Sat, Oct 03, 2020 at 04:02:57AM +, John Stultz wrote:
> > > @@ -426,6 +487,16 @@ static int system_heap_create(void)
> > > if (IS_ERR(sys_heap))
> > > return
On Wed, Sep 16, 2020 at 10:19 AM Lyude Paul wrote:
>
> Since we're about to start adding support for Intel's magic HDR
> backlight interface over DPCD, we need to ensure we're properly
> programming this field so that Intel specific sink services are exposed.
> Otherwise, 0x300-0x3ff will just
On 10/16/20 5:09 PM, Thomas Gleixner wrote:
> On Fri, Oct 16 2020 at 16:39, Jens Axboe wrote:
>> On 10/16/20 3:44 PM, Thomas Gleixner wrote:
- * @notify: send the notification if true
+ * @notify: send chosen notification, if any
>>>
>>> Is that really all you found to be wrong in that
Hello Anshuman,
In the patch that enables memory hot-remove (commit bbd6ec605c0f
("arm64/mm: Enable memory hot remove")) for arm64, there’s a notifier
put in place that prevents boot memory from being offlined and removed.
Also commit text mentions that boot memory on arm64 cannot be
The preceding patches have removed all users of mmdrop_async(); get rid of
it.
Note that on MMU, we still need async_put_work because mmput_async() uses
it, which in turn is used by binder's shrinker callback. We could claw back
those 4 words per mm if we made mmput_async() depend on
On Fri, Oct 16 2020 at 16:39, Jens Axboe wrote:
> On 10/16/20 3:44 PM, Thomas Gleixner wrote:
>>> - * @notify: send the notification if true
>>> + * @notify: send chosen notification, if any
>>
>> Is that really all you found to be wrong in that comment?
>
> There really is nothing wrong, but
The OOM killer uses MMF_OOM_SKIP to avoid running on an mm that has started
__mmput(); it only uses the mmgrab() reference to ensure that the mm_struct
itself stays alive.
This means that we don't need a full mmgrab() reference, which will keep
the pgd (and potentially also some pmd pages) alive
We only use ->exit_mm to look up dumpability and the ->user_mm; we don't
need to keep the PGD alive for this.
mmgrab() is also inconvenient here, because it means that we need to use
mmdrop_async() when dropping the reference to the mm from an RCU callback.
Use mm_ref() instead of mmgrab() to make
__ptrace_may_access() checks can happen on target tasks that are in the
middle of do_exit(), past exit_mm(). At that point, the ->mm pointer has
been NULLed out, and the mm_struct has been mmput().
Unfortunately, the mm_struct contains the dumpability and the user_ns in
which the task last went
I want to use refcount_t in mm_struct, but if refcount_t is defined in
linux/refcount.h, that header would have to be included in
linux/mm_types.h; that would be wasteful.
Let's move refcount_t over into linux/types.h so that includes can be
written less wastefully.
Signed-off-by: Jann Horn
---
Currently, mm_struct has two refcounts:
- mm_users: preserves everything - the mm_struct, the page tables, the
memory mappings, and so on
- mm_count: preserves the mm_struct and pgd
However, there are three types of users of mm_struct:
1. users that want page tables, memory mappings and so
[sorry, had to resend - it was pointed out to me that when I sent
this series the first time, DKIM got broken by the kvack list
rewriting 8-bit into quoted-printable]
At the moment, there is a lifetime issue (no, not the UAF kind) around
__ptrace_may_access():
__ptrace_may_access() wants to
Hi,
On Thu, Oct 15, 2020 at 10:53 AM Sibi Sankar wrote:
>
> Tweak the DDR/L3 bandwidth votes on the lite variant of the SC7180 SoC
> since the gold cores only support frequencies upto 2.1 GHz.
>
> Signed-off-by: Sibi Sankar
> ---
> arch/arm64/boot/dts/qcom/sc7180-lite.dtsi | 14 ++
(resending because DKIM got mangled on the first try by the kvack
list, hopefully setting sendemail.transferEncoding to
quoted-printable helps...)
v3:
- add note about how this also fixes arch/um/ locking in patch 1
(Johannes Berg)
- use IS_DEFINED() instead of #ifdef in patch 2 (Jason
Until now, the mmap lock of the nascent mm was ordered inside the mmap lock
of the old mm (in dup_mmap() and in UML's activate_mm()).
A following patch will change the exec path to very broadly lock the
nascent mm, but fine-grained locking should still work at the same time for
the old mm.
In
While AFAIK there currently is nothing that can modify the VMA tree of a
new mm until userspace has started running under the mm, we should properly
lock the mm here anyway, both to keep lockdep happy when adding locking
assertions and to be safe in the future in case someone e.g. decides to
On Sat, 17 Oct 2020 00:33:02 +0300 Vladimir Oltean wrote:
> On Sat, Oct 17, 2020 at 12:16:28AM +0300, Vladimir Oltean wrote:
> > On Fri, Oct 16, 2020 at 11:03:18PM +0200, Andrew Lunn wrote:
> > > 2ecbc1f684482b4ed52447a39903bd9b0f222898 does not have net-next, as
> > > far as i see,
> >
> >
On Fri, Oct 16, 2020 at 03:20:38PM +0200, Christoph Hellwig wrote:
> this series cleans up and massively simplifies the pstore-blk code,
> please take a look.
Cool! Thanks for doing this work. I have a few things I'd like to see
done differently, and while I'm not a huge fan of the general
cma_release() now is a non-blocking function, so there is no more need
to drop hugetlb_lock to call it.
Signed-off-by: Roman Gushchin
---
mm/hugetlb.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index fe76f8fd5a73..c8c892b1cabc 100644
--- a/mm/hugetlb.c
cma_release() has to lock the cma_lock mutex to clear the cma bitmap.
It makes it a blocking function, which complicates its usage from
non-blocking contexts. For instance, hugetlbfs code is temporarily
dropping the hugetlb_lock spinlock to call cma_release().
This patch makes cma_release
This small patchset makes cma_release() non-blocking and simplifies
the code in hugetlbfs, where previously we had to temporarily drop
hugetlb_lock around the cma_release() call.
It should help Zi Yan on his work on 1 GB THPs: splitting a gigantic
THP under a memory pressure requires a
On Fri, Oct 16, 2020 at 12:53:13PM +0200, Peter Zijlstra wrote:
> That's like saying: "I'm too lazy to track what I've looked at already".
> You're basically proposing to graffiti "Kees was here -- 16/10/2020" all
> over the kernel. Just so you can see where you still need to go.
>
> It says the
From: Colin Ian King
Don't populate const arrays on the stack but instead make them
static. Makes the object code smaller by 57 bytes.
Before:
textdata bss dec hex filename
173256 38016 192 211464 33a08 sound/pci/hda/patch_ca0132.o
After:
textdata bss
On 10/16/20 3:44 PM, Thomas Gleixner wrote:
> On Fri, Oct 16 2020 at 09:16, Jens Axboe wrote:
>> A previous commit changed the notification mode from 0/1 to allowing
>
> No. It changed it from boolean to an int.
>
> There is a fundamental difference between 0/1 and false/true simply
> because
On Mon, Oct 12, 2020 at 02:52:59PM +0200, David Hildenbrand wrote:
>Let's check by traversing busy system RAM resources instead, to avoid
>relying on memory block states.
>
>Don't use walk_system_ram_range(), as that works on pages and we want to
>use the bare addresses we have easily at hand.
>
> -Original Message-
> From: Leo Li
> Sent: Friday, October 16, 2020 4:20 PM
> To: 'Yi Wang' ; Roy Pledge ;
> Laurentiu Tudor
> Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org; linux-arm-
> ker...@lists.infradead.org; xue.zhih...@zte.com.cn;
> jiang.xue...@zte.com.cn;
On Fri, Oct 16, 2020 at 12:32:50PM +0200, David Hildenbrand wrote:
Ok, I seems to understand the logic now.
But how we prevent ONLINE_PARTIAL memory block get offlined? There are
three
calls in virtio_mem_set_fake_offline(), while all of them adjust page's
flag.
On Wed, 14 Oct 2020 14:06:32 +0800 Dylan Hung wrote:
> The new HW arbitration feature on Aspeed ast2600 will cause MAC TX to
> hang when handling scatter-gather DMA. Disable the problematic feature
> by setting MAC register 0x58 bit28 and bit27.
>
> Signed-off-by: Dylan Hung
Applied, thank
From: Colin Ian King
Don't populate const array filter_ies on the stack but instead
make it static. Makes the object code smaller by 261 bytes.
Before:
textdata bss dec hex filename
216743166 448 2528862c8 drivers/staging/wfx/sta.o
After:
textdata
The pull request you sent on Fri, 16 Oct 2020 22:34:53 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git
> tags/ovl-update-5.10
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/071a0578b0ce0b0e543d1e38ee6926b9cc21c198
Thank you!
--
1 - 100 of 1099 matches
Mail list logo
