From: "Paul E. McKenney"
Some sorts of per-CPU clock sources have a history of going out of
synchronization with each other. However, this problem has purportedy
been solved in the past ten years. Except that it is all too possible
that the problem has instead simply been made less likely, whic
From: "Paul E. McKenney"
Although smp_call_function() has the advantage of simplicity, using
it to check for cross-CPU clock desynchronization means that any CPU
being slow reduces the sensitivity of the checking across all CPUs.
And it is not uncommon for smp_call_function() latencies to be in t
On Wed, Feb 17, 2021 at 9:20 PM Min Li wrote:
>
> I attached the G.8273.2 document, where chapter 6 is about supporting
> physical layer
> frequency. And combo mode is Renesas way to support this requirement. Other
> companies
> may come up with different ways to support it.
>
> When EEC quality
> +@depends on patch@
> +identifier tmp;
> +expression a, b;
> +type T;
> +@@
> +
> +(
> +- T tmp;
> +|
> +- T tmp = 0;
> +|
> +- T *tmp = NULL;
> +)
> +... when != tmp
> +- tmp = a;
> +- a = b;
> +- b = tmp;
> ++ swap(a, b);
> +... when != tmp
In this rule and the next one, if you remove the fina
On Wed, Feb 17, 2021 at 09:16:12PM +, Matthew Wilcox wrote:
> On Wed, Feb 17, 2021 at 12:46:19PM -0800, Minchan Kim wrote:
> > > I suspect you do not want to add atomic_read inside hot paths, right? Is
> > > this really something that we have to microoptimize for? atomic_read is
> > > a simple
Fixes a checkpatch CHECK message.
Signed-off-by: William Durand
---
drivers/staging/rtl8192e/rtl819x_BA.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8192e/rtl819x_BA.h
b/drivers/staging/rtl8192e/rtl819x_BA.h
index 34d66b8f5155..3e5bd3fc78ce 100644
---
Fixes a checkpatch CHECK message.
Signed-off-by: William Durand
---
drivers/staging/rtl8192e/rtl819x_BA.h | 2 +-
drivers/staging/rtl8192e/rtl819x_BAProc.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtl819x_BA.h
b/drivers/staging/rtl8192e
This patchset fixes the checkpatch issues related to the `sequence_control`
union defined in `rtl8192e/rtl819x_BA.h` (avoid camelcase).
William Durand (3):
staging: rtl8192e: rename ShortData to short_data in sequence_control
union
staging: rtl8192e: rename FragNum to frag_num in sequence_
On Thu, Feb 11, 2021 at 02:35:41PM +0200, Matti Vaittinen wrote:
> BD9576MUF provides over-current protection and detection. Current is
> measured as voltage loss over external FET. Allow specifying FET's on
> resistance so current monitoring limits can be converted to voltages.
>
> Signed-off-by:
Hi,
This is a release announcement for the 2.11.8 and 2.12.5 releases of the
LTTng kernel tracer.
New and noteworthy in these releases:
* Support for Linux kernel 5.11,
* Deal with stable kernel version overflow (sublevel >= 256),
* Prepare for Ubuntu, SLES, RHEL, and RT release version overflow
Fixes a checkpatch CHECK message.
Signed-off-by: William Durand
---
drivers/staging/rtl8192e/rtl819x_BA.h | 2 +-
drivers/staging/rtl8192e/rtl819x_BAProc.c | 2 +-
drivers/staging/rtl8192e/rtllib_tx.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging
1 more for the pnode_id comment
> -Original Message-
> From: Ben Levinsky
> Sent: Wednesday, February 17, 2021 11:12 AM
> To: Mathieu Poirier
> Cc: devicet...@vger.kernel.org; linux-remotep...@vger.kernel.org; linux-
> ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Michal S
> On 17. Feb 2021, at 21:28, Shuah Khan wrote:
>
> On 2/17/21 7:56 AM, Shuah Khan wrote:
>>> On 2/17/21 12:30 AM, Kalle Valo wrote:
>>> Shuah Khan writes:
>>>
On 2/16/21 12:53 AM, Felix Fietkau wrote:
>
> On 2021-02-16 08:03, Kalle Valo wrote:
>> Shuah Khan wrote:
>>
During testing of tiered memory management based on memory soft limit,
I found three issues with memory management using cgroup based soft
limit in the mainline code. Fix the issues with the three patches in
this series. Also updated patch 3 per Johannes' comments on the first
version of this pat
During soft limit memory reclaim, we will temporarily remove the target
mem cgroup from the cgroup soft limit tree. We then perform memory
reclaim, update the memory usage excess count and re-insert the mem
cgroup back into the mem cgroup soft limit tree according to the new
memory usage excess co
To rate limit updates to the mem cgroup soft limit tree, we only perform
updates every SOFTLIMIT_EVENTS_TARGET (defined as 1024) memory events.
However, this sampling based updates may miss a critical update: i.e. when
the mem cgroup first exceeded its limit but it was not on the soft limit tree.
> From: Sven Van Asbroeck
>
> Tree: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git #
> 9ec5eea5b6ac
>
> v2 -> v3:
> - Bryan Whitehead:
> + add Bryan's reviewed-by tag to patch 1/5.
> + Only use FRAME_LENGTH if the LS bit is checked.
> If set use the smaller of F
On a per node basis, the mem cgroup soft limit tree on each node tracks
how much a cgroup has exceeded its soft limit memory limit and sorts
the cgroup by its excess usage. On page release, the trees are not
updated right away, until we have gathered a batch of pages belonging to
the same cgroup.
On Wed, Feb 17, 2021 at 07:11:37PM +, Ben Levinsky wrote:
> Hi Mathieu,
>
> I worked on this further and had 1 more comment on the prepare/unprepare for
> TCM banks below
>
[...]
> > > > + */
> > > > +static int tcm_mem_release(struct rproc *rproc, struct rproc_mem_entry
> > > *mem)
> > >
On Wed, 17 Feb 2021 20:10:50 +,
Michael Walle wrote:
>
> Am 2021-02-17 21:02, schrieb Marc Zyngier:
> > On 2021-02-17 19:57, Michael Walle wrote:
> >> Hi Greg,
> >>
> >>> There's no need to keep around a dentry pointer to a simple file that
> >>> debugfs itself can look up when we need to re
Hello:
This series was applied to netdev/net-next.git (refs/heads/master):
On Tue, 16 Feb 2021 22:20:01 -0600 you wrote:
> These patches clean up some things I noticed while fixing suspend/resume
> behavior. The first four are minor code improvements. The last one adds
> a shutdown hook to minimi
On 2/17/2021 1:20 PM, Michael S. Tsirkin wrote:
On Wed, Feb 17, 2021 at 11:42:48AM -0800, Si-Wei Liu wrote:
On 2/16/2021 8:20 AM, Eli Cohen wrote:
When we suspend the VM, the VDPA interface will be reset. When the VM is
resumed again, clear_virtqueues() will clear the available and used
ind
On 2/16/2021 7:21 AM, Eli Cohen wrote:
On Thu, Feb 11, 2021 at 09:33:14AM +0200, Eli Cohen wrote:
On Wed, Feb 10, 2021 at 01:48:00PM -0800, Si-Wei Liu wrote:
While virtq is stopped, get_vq_state() is supposed to
be called to get sync'ed with the latest internal
avail_index from device.
On Wed, Feb 17, 2021 at 09:34:13PM +, Ben Levinsky wrote:
> 1 more for the pnode_id comment
>
[...]
> > > > > +static int parse_tcm_banks(struct rproc *rproc)
> > > > > +{
> > > > > + int i, num_banks;
> > > > > + struct zynqmp_r5_rproc *z_rproc = rproc->priv;
> > > > > + struct
Hello:
This series was applied to netdev/net-next.git (refs/heads/master):
On Wed, 17 Feb 2021 00:42:11 -0500 you wrote:
> From: Vincent Cheng
>
> This series fixes a race condition that may result in the output clock
> not aligned to internal 1 PPS clock.
>
> Part of device initialization is
Hi!
>
> diff --git a/kernel/power/swap.c b/kernel/power/swap.c
> index c73f2e295167..e92e36c053a6 100644
> --- a/kernel/power/swap.c
> +++ b/kernel/power/swap.c
> @@ -271,13 +271,12 @@ static int hib_submit_io(int op, int op_flags, pgoff_t
> page_off, void *addr,
> struct hib_bio_ba
Hi Jakub and Bryan,
On Wed, Feb 17, 2021 at 4:43 PM wrote:
>
> Just to let you know, my colleague tested the patches 1 and 2 on x86 PC and
> we are satisfied with the result.
> We confirmed some performance improvements.
> We also confirmed PTP is working.
>
> Thanks for your work on this.
>
> T
Hello:
This patch was applied to bpf/bpf-next.git (refs/heads/master):
On Wed, 17 Feb 2021 10:45:25 +0300 you wrote:
> The WARN_ON() argument is a condition, not an error message. So this
> code will print a stack trace but will not print the warning message.
> Fix that and also change it to onl
The first patch adds printing a warning in v4l2_get_link_freq() if
V4L2_CID_LINK_FREQ isn't implemented (this is a mandatory control for
CSI-2 transmitter drivers [1], but many sensor drivers don't have it
currently).
The second patch is the start of the work discussed in the "[RFC] Repurpose
V4L2
Print a warning if V4L2_CID_LINK_FREQ control is not implemented.
Signed-off-by: Andrey Konovalov
---
drivers/media/v4l2-core/v4l2-common.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-common.c
b/drivers/media/v4l2-core/v4l2-common.c
index 133d20e40f82..f1a
This series first converts the debugfs files in the pinctrl subsystem to
octal permissions and then adds a new debugfs file "pinmux-select".
Function name and group name can be written to "pinmux-select" which
will cause the function and group to be activated on the pin controller.
The final patc
From: Vladimir Lypak
Because of u32 type being used to store pixel clock rate, expression used
to calculate pipeline clocks (pixel_clock * bpp) produces wrong value due
to integer overflow. This patch changes data type used to store, pass and
retrieve pixel_clock from u32 to u64 to make this mist
There are places in the camss driver where camss_get_pixel_clock() is
called to get the pixel rate (using V4L2_CID_PIXEL_RATE control) and to
calculate the link frequency from it. There is a case when this would
not work: when V4L2_CID_PIXEL_RATE gets the rate at which the pixels are
read (sampled)
On Tue, Feb 16, 2021 at 04:31:26PM +, David Laight wrote:
> ...
> > > > + get_device(&chip->dev);
> > > > + chip->devs.release = tpm_devs_release;
> > > > + chip->devs.devt =
> > > > + MKDEV(MAJOR(tpm_devt), chip->dev_num + TPM_NUM_DEVICES);
> >
> > Isn't this l
Add "pinmux-select" to debugfs which will activate a function and group:
echo "" > pinmux-select
The write operation pinmux_select() handles this by checking that the
names map to valid selectors and then calling ops->set_mux().
The existing "pinmux-functions" debugfs file lists the pin functi
Document debugfs directories and files created for pinctrl subsystem.
Suggested-by: Andy Shevchenko
Reviewed-by: Andy Shevchenko
Reviewed-by: Tony Lindgren
Signed-off-by: Drew Fustini
---
Documentation/driver-api/pinctl.rst | 37 +
1 file changed, 37 insertions(+)
Switch over pinctrl debugfs files to use octal permissions as they are
preferred over symbolic permissions. Refer to commit f90774e1fd27
("checkpatch: look for symbolic permissions and suggest octal instead").
Note: S_IFREG flag is added to the mode by __debugfs_create_file()
in fs/debugfs/inode.c
From: Sven Van Asbroeck
Date: Wed, 17 Feb 2021 17:04:05 -0500
> Hi Jakub and Bryan,
>
> Jakub, is there anything else you'd like to see from us, before you
> are satisfied that patches 1/5 and 2/5 can be merged into your tree?
They are already merged into net-next
On Mon, Feb 15, 2021 at 12:29:03AM +0100, Adrien Grassein wrote:
> Lontium LT8912 is a DSI to HDMI bridge.
>
> Signed-off-by: Adrien Grassein
> ---
> .../display/bridge/lontium,lt8912.yaml| 102 ++
> MAINTAINERS | 5 +
> 2 files changed
On Tue, Feb 16, 2021 at 08:53:11PM +0100, Lino Sanfilippo wrote:
> From: Lino Sanfilippo
>
> The following sequence of operations results in a refcount warning:
>
> 1. Open device /dev/tpmrm.
> 2. Remove module tpm_tis_spi.
> 3. Write a TPM command to the file descriptor opened at step 1.
>
> -
From: Bjorn Andersson
Introduce a firmware-name property, in order to be able to support
device/platform specific firmware for the wireless connectivity
subsystem; in line with other Qualcomm remoteproc drivers.
Signed-off-by: Bjorn Andersson
Tested-by: Aníbal Limón
---
.../devicetree/binding
Am 2021-02-17 22:50, schrieb Marc Zyngier:
On Wed, 17 Feb 2021 20:10:50 +,
Michael Walle wrote:
Am 2021-02-17 21:02, schrieb Marc Zyngier:
> On 2021-02-17 19:57, Michael Walle wrote:
>> Hi Greg,
>>
>>> There's no need to keep around a dentry pointer to a simple file that
>>> debugfs itself
Mike Marshall wrote:
> Matthew has looked at how I'm fumbling about
> trying to deal with Orangefs's need for much larger
> than page-sized IO...
>
> I think I need to implement orangefs_readahead
> and from there fire off an asynchronous read
> and while that's going I'll call readahead_page
>
[+cc Krzysztof, since he commented on a previous version]
[+cc Lukas, who previously proposed exactly what I suggest below,
sorry for repeating. I think Lukas was right to propose passing in
the vendor ID because it makes it easier to read the caller.]
When you post new versions of a series, plea
On Wed, Feb 17, 2021 at 1:12 PM Jason A. Donenfeld wrote:
>
> Hi Netdev & Willem,
>
> I've received a report of stack corruption -- via the stack protector
> check -- in icmp_send. I was sent a vmcore, and was able to extract
> the OOPS from there. However, I've been unable to produce the bug and
Explain no_user_shstk/no_user_ibt kernel parameters, and introduce a new
document on Control-flow Enforcement Technology (CET).
Signed-off-by: Yu-cheng Yu
Reviewed-by: Kees Cook
---
.../admin-guide/kernel-parameters.txt | 6 +
Documentation/x86/index.rst | 1 +
Doc
Control-flow Enforcement (CET) is a new Intel processor feature that blocks
return/jump-oriented programming attacks. Details are in "Intel 64 and
IA-32 Architectures Software Developer's Manual" [1].
CET can protect applications and the kernel. This series enables only
application-level protect
Add CPU feature flags for Control-flow Enforcement Technology (CET).
CPUID.(EAX=7,ECX=0):ECX[bit 7] Shadow stack
CPUID.(EAX=7,ECX=0):EDX[bit 20] Indirect Branch Tracking
Signed-off-by: Yu-cheng Yu
Reviewed-by: Kees Cook
---
arch/x86/include/asm/cpufeatures.h | 2 ++
arch/x86/include/asm
Shadow Stack provides protection against function return address
corruption. It is active when the processor supports it, the kernel has
CONFIG_X86_CET enabled, and the application is built for the feature.
This is only implemented for the 64-bit kernel. When it is enabled, legacy
non-Shadow Stac
Introduce a software-defined X86_FEATURE_CET, which indicates either Shadow
Stack or Indirect Branch Tracking (or both) is present. Also introduce
related cpu init/setup functions.
Signed-off-by: Yu-cheng Yu
Reviewed-by: Kees Cook
---
arch/x86/include/asm/cpufeatures.h | 2 +-
arch/x
A control-protection fault is triggered when a control-flow transfer
attempt violates Shadow Stack or Indirect Branch Tracking constraints.
For example, the return address for a RET instruction differs from the copy
on the shadow stack; or an indirect JMP instruction, without the NOTRACK
prefix, ar
There is essentially no room left in the x86 hardware PTEs on some OSes
(not Linux). That left the hardware architects looking for a way to
represent a new memory type (shadow stack) within the existing bits.
They chose to repurpose a lightly-used state: Write=0, Dirty=1.
The reason it's lightly
Control-flow Enforcement Technology (CET) introduces these MSRs:
MSR_IA32_U_CET (user-mode CET settings),
MSR_IA32_PL3_SSP (user-mode shadow stack pointer),
MSR_IA32_PL0_SSP (kernel-mode shadow stack pointer),
MSR_IA32_PL1_SSP (Privilege Level 1 shadow stack pointer),
MSR_IA32
After the introduction of _PAGE_COW, a modified page's PTE can have either
_PAGE_DIRTY or _PAGE_COW. Change _PAGE_DIRTY to _PAGE_DIRTY_BITS.
Signed-off-by: Yu-cheng Yu
Reviewed-by: Kees Cook
Cc: David Airlie
Cc: Joonas Lahtinen
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Rodrigo Vivi
Cc: Zhenyu
When Shadow Stack is introduced, [R/O + _PAGE_DIRTY] PTE is reserved for
shadow stack. Copy-on-write PTEs have [R/O + _PAGE_COW].
When a PTE goes from [R/W + _PAGE_DIRTY] to [R/O + _PAGE_COW], it could
become a transient shadow stack PTE in two cases:
The first case is that some processors can s
The x86 family of processors do not directly create read-only and Dirty
PTEs. These PTEs are created by software. One such case is that kernel
read-only pages are historically setup as Dirty.
New processors that support Shadow Stack regard read-only and Dirty PTEs as
shadow stack pages. This re
When serving a page fault, maybe_mkwrite() makes a PTE writable if it is in
a writable vma. A shadow stack vma is writable, but its PTEs need
_PAGE_DIRTY to be set to become writable. For this reason, maybe_mkwrite()
has been updated.
There are a few places that call pte_mkwrite() directly, but
The read-only and Dirty PTE has been used to indicate copy-on-write pages.
However, newer x86 processors also regard a read-only and Dirty PTE as a
shadow stack page. In order to separate the two, the software-defined
_PAGE_COW is created to replace _PAGE_DIRTY for the copy-on-write case, and
pte_
When serving a page fault, maybe_mkwrite() makes a PTE writable if its vma
has VM_WRITE.
A shadow stack vma has VM_SHSTK. Its PTEs have _PAGE_DIRTY, but not
_PAGE_WRITE. In fork(), _PAGE_DIRTY is cleared to effect copy-on-write,
and in page fault, _PAGE_DIRTY is restored and the shadow stack pag
INCSSP(Q/D) increments shadow stack pointer and 'pops and discards' the
first and the last elements in the range, effectively touches those memory
areas.
The maximum moving distance by INCSSPQ is 255 * 8 = 2040 bytes and
255 * 4 = 1020 bytes by INCSSPD. Both ranges are far from PAGE_SIZE.
Thus, p
To deliver a signal, create a shadow stack restore token and put the token
and the signal restorer address on the shadow stack. For sigreturn, verify
the token and restore from it the shadow stack pointer.
A shadow stack restore token marks a restore point of the shadow stack, and
the address in
On Tue, Feb 16 2021 at 09:44 -0800, Asutosh Das wrote:
On Sat, Feb 13 2021 at 13:37 -0800, Avri Altman wrote:
+ } else {
Is it possible to get here?
Scsi_scan_host is called only after successful add_wluns
It looks so.
scsi 0:0:0:49488: Link setup for lun - ufshcd_setup_links
[...]
Call
Account shadow stack pages to stack memory.
Signed-off-by: Yu-cheng Yu
Reviewed-by: Kees Cook
---
arch/x86/mm/pgtable.c | 7 +++
include/linux/pgtable.h | 11 +++
mm/mmap.c | 5 +
3 files changed, 23 insertions(+)
diff --git a/arch/x86/mm/pgtable.c b/arch/x86/
Introduce basic shadow stack enabling/disabling/allocation routines.
A task's shadow stack is allocated from memory with VM_SHSTK flag and has
a fixed size of min(RLIMIT_STACK, 4GB).
Signed-off-by: Yu-cheng Yu
Reviewed-by: Kees Cook
---
arch/x86/include/asm/cet.h | 28 ++
arch/x86/in
Shadow stack accesses are those that are performed by the CPU where it
expects to encounter a shadow stack mapping. These accesses are performed
implicitly by CALL/RET at the site of the shadow stack pointer. These
accesses are made explicitly by shadow stack management instructions like
WRUSSQ.
A shadow stack PTE must be read-only and have _PAGE_DIRTY set. However,
read-only and Dirty PTEs also exist for copy-on-write (COW) pages. These
two cases are handled differently for page faults. Introduce VM_SHSTK to
track shadow stack VMAs.
Signed-off-by: Yu-cheng Yu
Reviewed-by: Kees Cook
There was no more caller passing vm_flags to do_mmap(), and vm_flags was
removed from the function's input by:
commit 45e55300f114 ("mm: remove unnecessary wrapper function
do_mmap_pgoff()").
There is a new user now. Shadow stack allocation passes VM_SHSTK to
do_mmap(). Re-introduce vm_fla
Can_follow_write_pte() ensures a read-only page is COWed by checking the
FOLL_COW flag, and uses pte_dirty() to validate the flag is still valid.
Like a writable data page, a shadow stack page is writable, and becomes
read-only during copy-on-write, but it is always dirty. Thus, in the
can_follow
An ELF file's .note.gnu.property indicates arch features supported by the
file. These features are extracted by arch_parse_elf_property() and stored
in 'arch_elf_state'.
Introduce x86 feature definitions and arch_setup_elf_property(), which
enables such features. The first use-case of this funct
Control-flow Enforcement (CET) is a new Intel processor feature that blocks
return/jump-oriented programming attacks. Details are in "Intel 64 and
IA-32 Architectures Software Developer's Manual" [1].
This is the second part of CET and enables Indirect Branch Tracking (IBT).
It is built on top of
Indirect branch tracking is a hardware security feature that verifies near
indirect call/jump instructions arrive at intended targets, which are
labeled by the compiler with ENDBR opcodes. If such instructions reach
unlabeled locations, the processor raises control-protection faults.
Check the co
arch_prctl(ARCH_X86_CET_STATUS, u64 *args)
Get CET feature status.
The parameter 'args' is a pointer to a user buffer. The kernel returns
the following information:
*args = shadow stack/IBT status
*(args + 1) = shadow stack base address
*(args + 2) = shadow stack size
To prepare changes to arch_calc_vm_prot_bits() in the next patch, and be
consistent with other architectures, move arch_vm_get_page_prot() and
arch_calc_vm_prot_bits() to arch/x86/include/asm/mman.h.
Signed-off-by: Yu-cheng Yu
Reviewed-by: Kees Cook
---
arch/x86/include/asm/mman.h | 30 +++
Introduce user-mode Indirect Branch Tracking (IBT) support. Add routines
for the setup/disable of IBT.
Signed-off-by: Yu-cheng Yu
Reviewed-by: Kees Cook
---
arch/x86/include/asm/cet.h | 3 +++
arch/x86/kernel/cet.c | 33 +
2 files changed, 36 insertions(+)
There are three possible options to create a shadow stack allocation API:
an arch_prctl, a new syscall, or adding PROT_SHSTK to mmap()/mprotect().
Each has its advantages and compromises.
An arch_prctl() is the least intrusive. However, the existing x86
arch_prctl() takes only two parameters. Mu
An ELF file's .note.gnu.property indicates features the file supports.
The property is parsed at loading time and passed to arch_setup_elf_
property(). Update it for Indirect Branch Tracking.
Signed-off-by: Yu-cheng Yu
Reviewed-by: Kees Cook
---
arch/x86/kernel/process_64.c | 8
1 fil
From: "H.J. Lu"
Update ARCH_X86_CET_STATUS and ARCH_X86_CET_DISABLE for Indirect Branch
Tracking.
Signed-off-by: H.J. Lu
Signed-off-by: Yu-cheng Yu
Reviewed-by: Kees Cook
---
arch/x86/kernel/cet_prctl.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/x86/kernel/cet_prctl.c b/ar
When an indirect CALL/JMP instruction is executed and before it reaches
the target, it is in 'WAIT_ENDBR' status, which can be read from
MSR_IA32_U_CET. The status is part of a task's status before a signal is
raised and preserved in the signal frame. It is restored for sigreturn.
IBT state mach
From: Bjorn Andersson
Enable the mpss remoteproc node and specify the firmware-name for this
and the wcnss remoteproc on the Dragonboard 410c.
Link:
https://lore.kernel.org/r/20200108055735.660475-1-bjorn.anders...@linaro.org
Signed-off-by: Bjorn Andersson
[rebased and moved to use pronto labe
The kernel allocates (and frees on thread exit) a new shadow stack for a
pthread child.
It is possible for the kernel to complete the clone syscall and set the
child's shadow stack pointer to NULL and let the child thread allocate
a shadow stack for itself. There are two issues in thi
Hi Dmitry,
On Wed, Feb 17, 2021 at 01:06:27PM -0800, Dmitry Torokhov wrote:
> On Wed, Feb 17, 2021 at 12:52:57PM -0800, Life is hard, and then you die
> wrote:
> >
> > On Wed, Feb 17, 2021 at 12:26:18PM -0800, Dmitry Torokhov wrote:
> > >
> > > On Wed, Feb 17, 2021 at 11:07:18AM -0800, Rona
Matthew Wilcox wrote:
> We're defeating the ondemand_readahead() algorithm here. Let's suppose
> userspace is doing 64kB reads, the filesystem is OrangeFS which only
> wants to do 4MB reads, the page cache is initially empty and there's
> only one thread doing a sequential read. ondemand_readah
From: "H.J. Lu"
When Indirect Branch Tracking (IBT) is enabled, vDSO functions may be
called indirectly, and must have ENDBR32 or ENDBR64 as the first
instruction. The compiler must support -fcf-protection=branch so that it
can be used to compile vDSO.
Signed-off-by: H.J. Lu
Signed-off-by: Yu-
From: "H.J. Lu"
Add ENDBR32 to __kernel_vsyscall entry point.
Signed-off-by: H.J. Lu
Signed-off-by: Yu-cheng Yu
Acked-by: Andy Lutomirski
Reviewed-by: Kees Cook
---
arch/x86/entry/vdso/vdso32/system_call.S | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/entry/vdso/vdso32/sys
Hello:
This patch was applied to netdev/net-next.git (refs/heads/master):
On Wed, 17 Feb 2021 17:57:05 +0800 you wrote:
> This patch populates the PCI bus info in the ethtool driver query data.
>
> Users will be able to view PCI bus info using 'ethtool -i '.
>
> Signed-off-by: Wong Vee Khee
>
> -Original Message-
> From: Finn Thain [mailto:fth...@telegraphics.com.au]
> Sent: Sunday, February 14, 2021 6:11 PM
> To: Song Bao Hua (Barry Song)
> Cc: Arnd Bergmann ; t...@linutronix.de;
> gre...@linuxfoundation.org; a...@arndb.de; ge...@linux-m68k.org;
> fun...@jurai.org; ph...@gn
On 2/13/21 5:58 AM, Greg Kroah-Hartman wrote:
On Fri, Feb 12, 2021 at 09:17:13AM -0700, Shuah Khan wrote:
On 2/11/21 8:01 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 5.10.16 release.
There are 54 patches in this series, all will be posted as a response
to
On Feb 17, 2021, at 9:08 AM, Theodore Ts'o wrote:
>
> On Tue, Feb 16, 2021 at 08:01:11PM -0800, Daniel Rosenberg wrote:
>> I'm not sure what the conflict is, at least format-wise. Naturally,
>> there would need to be some work to reconcile the two patches, but my
>> patch only alters the format f
On Wed, Feb 17, 2021 at 09:03:05AM +0100, Benjamin Gaignard wrote:
> The introduction on HEVC decoder lead to update the bindings
> to support it.
>
> Signed-off-by: Benjamin Gaignard
> Signed-off-by: Ezequiel Garcia
> Signed-off-by: Adrian Ratiu
> ---
> .../bindings/media/nxp,imx8mq-vpu.yaml
On Fri, Feb 12, 2021, Sean Christopherson wrote:
> Paolo, this is more or less ready, but on final read-through before
> sending I realized it would be a good idea to WARN during VM destruction
> if cpu_dirty_logging_count is non-zero. I wanted to get you this before
> the 5.12 window opens in cas
On Wed, Feb 17, 2021 at 10:34:39PM +, David Howells wrote:
> Matthew Wilcox wrote:
>
> > We're defeating the ondemand_readahead() algorithm here. Let's suppose
> > userspace is doing 64kB reads, the filesystem is OrangeFS which only
> > wants to do 4MB reads, the page cache is initially empt
Hi Willem,
On Wed, Feb 17, 2021 at 11:27 PM Willem de Bruijn
wrote:
> A vmlinux image might help. I couldn't find one for this kernel.
https://data.zx2c4.com/icmp_send-crash-e03b4a42-706a-43bf-bc40-1f15966b3216.tar.xz
has .debs with vmlinuz in there, which you can extract to vmlinux, as
well as
On Thursday, 11 February 2021 6:55:10 PM AEDT Christoph Hellwig wrote:
> On Wed, Feb 10, 2021 at 01:59:13PM -0400, Jason Gunthorpe wrote:
> > Really what you want to do here is leave the CPU page in the VMA and
> > the page tables where it started and deny CPU access to the page. Then
> > all the p
On Wed, Feb 17, 2021 at 5:56 PM Jason A. Donenfeld wrote:
>
> Hi Willem,
>
> On Wed, Feb 17, 2021 at 11:27 PM Willem de Bruijn
> wrote:
> > A vmlinux image might help. I couldn't find one for this kernel.
>
> https://data.zx2c4.com/icmp_send-crash-e03b4a42-706a-43bf-bc40-1f15966b3216.tar.xz
> has
On Wed, 17 Feb 2021 22:30:14 +0100 Arnd Bergmann wrote:
> On Wed, Feb 17, 2021 at 9:20 PM Min Li wrote:
> > I attached the G.8273.2 document, where chapter 6 is about supporting
> > physical layer
> > frequency. And combo mode is Renesas way to support this requirement. Other
> > companies
> > m
Drop limit link rate at HBR2 to support link rate
upto HBR3.
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_panel.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_panel.c
b/drivers/gpu/drm/msm/dp/dp_panel.c
index 9cc8166..63112fa 100644
--- a/drivers
On 2/18/21, Willem de Bruijn wrote:
> On Wed, Feb 17, 2021 at 5:56 PM Jason A. Donenfeld wrote:
>>
>> Hi Willem,
>>
>> On Wed, Feb 17, 2021 at 11:27 PM Willem de Bruijn
>> wrote:
>> > A vmlinux image might help. I couldn't find one for this kernel.
>>
>> https://data.zx2c4.com/icmp_send-crash-e0
Add hbr3_hbr2 voltage and premphasis swing table to support
HBR3 link rate.
Signed-off-by: Kuogee Hsieh
---
drivers/phy/qualcomm/phy-qcom-qmp.c | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c
b/drivers/phy/qualcomm
On Sun, Feb 14, 2021 at 09:52:51AM -0800, Randy Dunlap wrote:
> On 2/12/21 2:22 PM, mgr...@linux.intel.com wrote:
> > diff --git a/drivers/misc/xlink-core/Kconfig
> > b/drivers/misc/xlink-core/Kconfig
> > new file mode 100644
> > index ..a0ceb0b48219
> > --- /dev/null
> > +++ b/drivers
On Tue, Feb 02, 2021 at 11:03:32AM +0100, Geert Uytterhoeven wrote:
> Kmemleak reports:
>
> unreferenced object 0xc328de40 (size 64):
> comm "kworker/1:1", pid 21, jiffies 4294938212 (age 1484.670s)
> hex dump (first 32 bytes):
> 00 00 00 00 00 00 00 00 e0 d8 fc eb 00 00 00
701 - 800 of 1042 matches
Mail list logo
