After the introduction of _PAGE_COW, a modified page's PTE can have either
_PAGE_DIRTY_HW 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:
Kernel read-only PTEs are setup as _PAGE_DIRTY_HW. Since these become
shadow stack PTEs, remove the dirty bit.
Signed-off-by: Yu-cheng Yu
Cc: "H. Peter Anvin"
Cc: Kees Cook
Cc: Thomas Gleixner
Cc: Dave Hansen
Cc: Christoph Hellwig
Cc: Andy Lutomirski
Cc: Ingo Molnar
Cc: Borislav Petkov
If a page sent into kernel_sendpage() is a slab page or it doesn't have
ref_count, this page is improper to send by the zero copy sendpage()
method. Otherwise such page might be unexpected released in network code
path and causes impredictable panic due to kernel memory management data
structure
In iscsci driver, iscsi_tcp_segment_map() uses the following code to
check whether the page should or not be handled by sendpage:
if (!recv && page_count(sg_page(sg)) >= 1 && !PageSlab(sg_page(sg)))
The "page_count(sg_page(sg)) >= 1 && !PageSlab(sg_page(sg)" part is to
make sure the page can
Currently nvme_tcp_try_send_data() doesn't use kernel_sendpage() to
send slab pages. But for pages allocated by __get_free_pages() without
__GFP_COMP, which also have refcount as 0, they are still sent by
kernel_sendpage() to remote end, this is problematic.
The new introduced helper
commit a10674bf2406 ("tcp: detecting the misuse of .sendpage for Slab
objects") adds the checks for Slab pages, but the pages don't have
page_count are still missing from the check.
Network layer's sendpage method is not designed to send page_count 0
pages neither, therefore both PageSlab() and
On Tue, Sep 22, 2020 at 09:52:43PM -0400, Joel Fernandes wrote:
> On Tue, Sep 22, 2020 at 09:46:22PM -0400, Joel Fernandes wrote:
> > On Fri, Aug 28, 2020 at 11:29:27PM +0200, Peter Zijlstra wrote:
> > >
> > >
> > > This is still a horrible patch..
> >
> > Hi Peter,
> > I wrote a new patch
Hi Dan,
On 2020-9-25 18:57, Dan Carpenter wrote:
On Fri, Sep 25, 2020 at 05:06:33PM +0800, Chao Yu wrote:
Hi,
I don't see any problem here, thanks for your report. :)
I bet the uninitialize value is because "max_depth" is zero.
I agree with you, thanks for the hint. :)
Thanks,
This series was original by a bug fix in nvme-over-tcp driver which only
checked whether a page was allocated from slab allcoator, but forgot to
check its page_count: The page handled by sendpage should be neither a
Slab page nor 0 page_count page.
As Sagi Grimberg suggested, the original fix is
On Fri, Sep 25, 2020 at 4:47 PM syzbot
wrote:
>
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:3fc826f1 Merge branch 'net-dsa-bcm_sf2-Additional-DT-chang..
> git tree: net-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=158f800990
> kernel config:
On Mon, 31 Aug 2020 13:22:35 +0200 SeongJae Park wrote:
> On Thu, 20 Aug 2020 09:27:38 +0200 SeongJae Park wrote:
>
> > On Mon, 17 Aug 2020 12:51:22 +0200 SeongJae Park wrote:
> >
> > > From: SeongJae Park
> > >
[...]
> > > Introduction
> > >
> > >
> > > DAMON is a data
Control-flow Enforcement Technology (CET) adds five MSRs. Introduce them
and their XSAVES supervisor states:
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
On Fri, Sep 25, 2020 at 04:49:28PM +0200, David Hildenbrand wrote:
> >> There were once RFC patches to make use of it in ACPI, but it could be
> >> solved using different interfaces [1].
> >>
> >>
> >> While I'd love to rip it out completely, I think it would break old
> >> lsmem/chmem completely
On 9/24/20 10:08 PM, Randy Dunlap wrote:
> On 9/24/20 7:58 AM, Ross Philipson wrote:
>> Initial bits to bring in Secure Launch functionality. Add Kconfig
>> options for compiling in/out the Secure Launch code.
>>
>> Signed-off-by: Ross Philipson
>
> Hi,
> from
On Fri, 25 Sep 2020 10:54:58 -0400
Steven Rostedt wrote:
> The crash looks like its cr3 related, which I believe Peter Zijlstra
s/cr3/cr2/
-- Steve
> did a restructuring of that code to not let it be an issue anymore.
> I'll have to look deeper. The rework may be too intrusive to backport,
On 9/24/20 1:38 PM, Arvind Sankar wrote:
> On Thu, Sep 24, 2020 at 10:58:35AM -0400, Ross Philipson wrote:
>> The Secure Launch (SL) stub provides the entry point for Intel TXT (and
>> later AMD SKINIT) to vector to during the late launch. The symbol
>> sl_stub_entry is that entry point and its
On Fri, Sep 25, 2020 at 11:31:14AM +0100, Mark Rutland wrote:
> Hi,
>
> Sorry to come to this so late; I've been meaning to provide feedback on
> this for a while but have been indisposed for a bit due to an injury.
>
> On Fri, Sep 25, 2020 at 11:50:29AM +0200, Peter Zijlstra wrote:
> > On Fri,
On Thu, Sep 24, 2020 at 10:17 PM Maximilian Luz wrote:
> On 9/24/20 10:30 AM, Andy Shevchenko wrote:
> > On Wed, Sep 23, 2020 at 6:32 PM Arnd Bergmann wrote:
> >> On Wed, Sep 23, 2020 at 5:15 PM Maximilian Luz
> >> wrote:
...
> >> I think this should go to drivers/platform/x86 or
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
---
arch/x86/kernel/cet_prctl.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cet_prctl.c
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
---
arch/x86/entry/vdso/vdso32/system_call.S | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/entry/vdso/vdso32/system_call.S
An indirect CALL/JMP moves the indirect branch tracking (IBT) state machine
to WAIT_ENDBR status until the instruction reaches an ENDBR opcode. If the
CALL/JMP does not reach an ENDBR opcode, the processor raises a control-
protection fault. WAIT_ENDBR status can be read from MSR_IA32_U_CET.
Introduce Kconfig option X86_BRANCH_TRACKING_USER.
Indirect Branch Tracking (IBT) provides protection against CALL-/JMP-
oriented programming attacks. It is active when the kernel has this
feature enabled, and the processor and the application support it.
When this feature is enabled, legacy
Update arch_setup_elf_property() for Indirect Branch Tracking.
Signed-off-by: Yu-cheng Yu
---
v9:
- Change cpu_feature_enabled() to static_cpu_has().
arch/x86/Kconfig | 2 ++
arch/x86/kernel/process_64.c | 8
2 files changed, 10 insertions(+)
diff --git a/arch/x86/Kconfig
Introduce user-mode Indirect Branch Tracking (IBT) support. Update setup
routines to include IBT.
Signed-off-by: Yu-cheng Yu
---
v10:
- Change no_cet_ibt to no_user_ibt.
v9:
- Change cpu_feature_enabled() to static_cpu_has().
v2:
- Change noibt to no_cet_ibt.
arch/x86/include/asm/cet.h
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:
Vsyscall entry points are effectively branch targets. Mark them with
ENDBR64 opcodes. When emulating the RET instruction, unwind shadow stack
and reset IBT state machine.
Signed-off-by: Yu-cheng Yu
---
v13:
- Check shadow stack address is canonical.
- Change from writing to MSRs to writing to
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
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
---
v13:
- Change X86_INTEL_* to X86_*.
v12:
- Remove ARCH_X86_CET_MMAP_SHSTK information.
v11:
- Add back GLIBC
On Fri, 25 Sep 2020 12:55:13 +0530
Naresh Kamboju wrote:
> On Fri, 25 Sep 2020 at 10:45, Greg Kroah-Hartman
> wrote:
> >
> > On Fri, Sep 25, 2020 at 10:13:05AM +0530, Naresh Kamboju wrote:
> > > >From stable rc 4.18.1 onwards to today's stable rc 4.19.147
> > >
> > > There are two problems
On Fri, Sep 25, 2020 at 11:05:58AM +0800, Dave Young wrote:
> Hi,
>
> On 09/24/20 at 01:16pm, boris.ostrov...@oracle.com wrote:
> >
> > On 9/24/20 12:43 PM, Michael Kelley wrote:
> > > From: Eric W. Biederman Sent: Thursday, September
> > > 24, 2020 9:26 AM
> > >> Michael Kelley writes:
> >
On Thu, Sep 24, 2020 at 10:38 PM Arnd Bergmann wrote:
> On Thu, Sep 24, 2020 at 8:59 PM Maximilian Luz
> wrote:
> > On 9/24/20 10:26 AM, Arnd Bergmann wrote:
> > > On Thu, Sep 24, 2020 at 1:28 AM Maximilian Luz
> > > wrote:
>
> > > Note that drivers that connect to the bus typically don't
Hi Yannick.
On Fri, Sep 25, 2020 at 12:22:33PM +0200, Yannick Fertre wrote:
> Standardize on the dev_ based logging and drop the include of drm_print.h.
The patchs filas to drop the include mentioned here.
> Remove useless dsi_color_from_mipi function.
IMO the dsi_color_from_mipi() was nice, and
On Tue, Sep 22, 2020 at 6:47 AM Pujin Shi wrote:
>
> Include the linux/idle_inject.h header to fix W=1 build warning:
>
> drivers/powercap/idle_inject.c:152:6: warning: no previous prototype for
> ‘idle_inject_set_duration’ [-Wmissing-prototypes]
> drivers/powercap/idle_inject.c:167:6:
>> There were once RFC patches to make use of it in ACPI, but it could be
>> solved using different interfaces [1].
>>
>>
>> While I'd love to rip it out completely, I think it would break old
>> lsmem/chmem completely - and I assume that's not acceptable. I was
>> wondering what would be
On Fri, Sep 25, 2020 at 3:26 PM Kent Gibson wrote:
> On Fri, Sep 25, 2020 at 12:35:49PM +0300, Andy Shevchenko wrote:
> > On Thu, Sep 24, 2020 at 6:07 AM Kent Gibson wrote:
> > > On Wed, Sep 23, 2020 at 06:47:28PM +0300, Andy Shevchenko wrote:
> > > > On Tue, Sep 22, 2020 at 5:35 AM Kent Gibson
On 25/09/20 16:10 +0200, Alejandro Colomar wrote:
On 2020-09-25 15:20, Alejandro Colomar wrote:
'nitems()' calculates the length of an array in number of items.
It is safe: if a pointer is passed to the macro (or function, in C++),
the compilation is broken due to:
- In >= C11:
Hello,
syzbot found the following issue on:
HEAD commit:171d4ff7 Merge tag 'mmc-v5.9-rc4-2' of git://git.kernel.or..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1597ead390
kernel config: https://syzkaller.appspot.com/x/.config?x=af502ec9a451c9fc
Hello,
syzbot found the following issue on:
HEAD commit:3fc826f1 Merge branch 'net-dsa-bcm_sf2-Additional-DT-chang..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=158f800990
kernel config: https://syzkaller.appspot.com/x/.config?x=51fb40e67d1e3dec
From: Kan Liang
Previously, the MSR uncore for the Ice Lake and Tiger Lake are
identical. The code path is shared. However, with recent update, the
global MSR_UNC_PERF_GLOBAL_CTRL register and ARB uncore unit are changed
for the Ice Lake. Split the Ice Lake and Tiger Lake MSR uncore support.
On Fri, Sep 25, 2020 at 2:56 PM Kent Gibson wrote:
>
> On Fri, Sep 25, 2020 at 01:12:14PM +0300, Andy Shevchenko wrote:
> > On Thu, Sep 24, 2020 at 12:48 PM Kent Gibson wrote:
> > > On Thu, Sep 24, 2020 at 11:39:03AM +0300, Andy Shevchenko wrote:
> > > > On Thu, Sep 24, 2020 at 5:39 AM Kent
Add arm64 subdirectory into the table of Contents for zh_CN,
then add other translations in arm64 conveniently.
Signed-off-by: Bailu Lin
---
Changes in v4:
- Remove index.rst's inappropriate License claim.
Changes in v3:
- Correct email encoding format.
Changes in v2:
- Fix patch description.
- On Sep 24, 2020, at 4:33 PM, rostedt rost...@goodmis.org wrote:
> On Thu, 24 Sep 2020 16:27:34 -0400 (EDT)
> Mathieu Desnoyers wrote:
>
>> I'd be a bit more specific: so far, the msr.h use-case requires to include
>> directly tracepoint-defs.h and use a tracepoint_enabled() macro defined
On Thu, Sep 24, 2020 at 10:01 AM wrote:
>
> From: zhuguangqing
>
> Currently, if CONFIG_SUSPEND=n and CONFIG_CPU_IDLE=y, the function
> cpuidle_enter_s2idle() is declared but not defined, it may cause error
> when cpuidle_enter_s2idle() is called.
>
> If CONFIG_SUSPEND=y and CONFIG_CPU_IDLE=n,
On Fri, Sep 25, 2020 at 03:25:15PM +0800, Willy Liu wrote:
> There are two chip pins named TXDLY and RXDLY which actually adds the 2ns
> delays to TXC and RXC for TXD/RXD latching. These two pins can config via
> 4.7k-ohm resistor to 3.3V hw setting, but also config via software setting
>
On Fri, Sep 25, 2020 at 01:31:51PM +0200, Arnd Bergmann wrote:
> On Thu, Sep 24, 2020 at 10:54 PM Sam Ravnborg wrote:
> >
> > Hi Daniel/Arnd.
> >
> > On Fri, Sep 18, 2020 at 02:48:08PM +0200, Daniel Vetter wrote:
> > > On Fri, Sep 18, 2020 at 12:08:10PM +0200, Arnd Bergmann wrote:
> > > > The
On Thu, Sep 24, 2020 at 12:03 PM Chanwoo Choi wrote:
>
> Dear Rafael,
>
> This is devfreq-next pull request for v5.9-rc7. I add detailed description of
> this pull request on the following tag. Please pull devfreq with following
> updates.
> - tag name : devfreq-fixes-for-5.9-rc7
Pulled,
On 25/09/2020 12:53, Robin Murphy wrote:
---
drivers/iommu/iova.c | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
index 45a251da5453..05e0b462e0d9 100644
--- a/drivers/iommu/iova.c
+++
MSRs are weird. Some of them are normal control registers, such as EFER.
Some however are registers that really are model specific, not very
interesting to virtualization workloads, and not performance critical.
Others again are really just windows into package configuration.
Out of these MSRs,
From: Aaron Lewis
Prepare vmx and svm for a subsequent change that ensures the MSR permission
bitmap is set to allow an MSR that userspace is tracking to force a vmx_vmexit
in the guest.
Signed-off-by: Aaron Lewis
Reviewed-by: Oliver Upton
[agraf: rebase, adapt SVM scheme to nested changes
Now that we have the ability to handle MSRs from user space and also to
select which ones we do want to prevent in-kernel KVM code from handling,
let's add a selftest to show case and verify the API.
Signed-off-by: Alexander Graf
---
v2 -> v3:
-
In the following commits we will add pieces of MSR filtering.
To ensure that code compiles even with the feature half-merged, let's add
a few stubs and struct definitions before the real patches start.
Signed-off-by: Alexander Graf
---
v7 -> v8:
s/KVM_MSR_ALLOW/KVM_MSR_FILTER/g
---
We will introduce the concept of MSRs that may not be handled in kernel
space soon. Some MSRs are directly passed through to the guest, effectively
making them handled by KVM from user space's point of view.
This patch introduces all logic required to ensure that MSRs that
user space wants
When we find an MSR that we can not handle, bubble up that error code as
MSR error return code. Follow up patches will use that to expose the fact
that an MSR is not handled by KVM to user space.
Suggested-by: Aaron Lewis
Signed-off-by: Alexander Graf
---
arch/x86/kvm/x86.c | 2 +-
1 file
While tying to add support for the MSR_CORE_THREAD_COUNT MSR in KVM,
I realized that we were still in a world where user space has no control
over what happens with MSR emulation in KVM.
That is bad for multiple reasons. In my case, I wanted to emulate the
MSR in user space, because it's a CPU
On 9/17/20 6:44 PM, Tejun Heo wrote:
> Hello,
>
> Debt reduction logic was recently added by dda1315f1853 ("blk-iocost: halve
> debts if device stays idle"). While it was effective at avoiding
> pathological cases where some iocgs were kept delayed while the device was
> most idle, it wasn't very
It's not desireable to have all MSRs always handled by KVM kernel space. Some
MSRs would be useful to handle in user space to either emulate behavior (like
uCode updates) or differentiate whether they are valid based on the CPU model.
To allow user space to specify which MSRs it wants to see
We will introduce the concept of MSRs that may not be handled in kernel
space soon. Some MSRs are directly passed through to the guest, effectively
making them handled by KVM from user space's point of view.
This patch introduces all logic required to ensure that MSRs that
user space wants
The following changes since commit ba4f184e126b751d1bffad5897f263108befc780:
Linux 5.9-rc6 (2020-09-20 16:33:55 -0700)
are available in the Git repository at:
git://git.linux-nfs.org/projects/cel/cel-2.6.git tags/nfsd-5.9-2
for you to fetch changes up to
> Subject: Re: [PATCH v2 3/3] PM / Domains: Add support for PM domain on/off
> notifiers for genpd
>
> On Fri, 25 Sep 2020 at 08:08, Peng Fan wrote:
> >
> > Hi Ulf,
> >
> > > Subject: [PATCH v2 3/3] PM / Domains: Add support for PM domain
> > > on/off notifiers for genpd
> > >
> > > A device may
Hi Pavel,
On 9/25/20 4:47 AM, Pavel Machek wrote:
Hi!
In linux-next, I published TODO list for LED subsystem. Is that
something linux-kernel-mentees could help with?
Best regards,
Pavel
Thanks for putting this list together. Will you
On Thu, Sep 24, 2020 at 11:46:32PM +0900, Namhyung Kim wrote:
> On Thu, Sep 24, 2020 at 03:44:44PM +0200, Jiri Olsa wrote:
> > On Thu, Sep 24, 2020 at 10:20:51PM +0900, Namhyung Kim wrote:
> > > On Thu, Sep 24, 2020 at 10:09 PM Jiri Olsa wrote:
> > > >
> > > > On Wed, Sep 23, 2020 at 05:05:34PM
Hello!
On Friday 25 September 2020 15:44:36 Gregory CLEMENT wrote:
> Hello Pali,
>
> could you add a commit log besides the topic ?
I can add, but I do not know what to write for such simple update.
> Also note that I've just sent the pull requests for 5.10 and I was
> already a little late
On 9/2/20 11:40 PM, Christoph Hellwig wrote:
> Hi Jens,
>
> this series add a new helepr to check if a struct block_device represents
> a parition, and removes most direct access to ->bd_contained from
> drivers.
Applied, thanks.
--
Jens Axboe
On Fri, Sep 25, 2020 at 11:27:54AM +0200, Greg KH wrote:
> On Thu, Sep 24, 2020 at 08:21:07PM +0200, Thomas Gleixner wrote:
> > On Thu, Sep 24 2020 at 08:33, Greg KH wrote:
> > > On Wed, Sep 23, 2020 at 05:08:32PM -0700, Prasad Sodagudi wrote:
> > >> +config CONSOLE_FLUSH_ON_HOTPLUG
> > >> +
Compute new timings to get a framerate of 50fps with a pixel clock
@54Mhz.
Signed-off-by: Yannick Fertre
---
drivers/gpu/drm/panel/panel-raydium-rm68200.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-raydium-rm68200.c
On Fri 25 Sep 2020 at 15:44, Sebastian Andrzej Siewior
wrote:
> On 2020-09-25 11:11:42 [+0200], Jerome Brunet wrote:
>> I'm not sure about this.
>> As you have explained on IRC, I understand that IRQF_ONESHOT is causing
>> trouble with RT as the hard IRQ part of the thread will not be
Change the parameters passed to iommu_dma_alloc_iova(): the dma_limit can
be easily extracted from the parameters of the passed struct device, so
replace it with a flags parameter, which can later hold more information
about the way the IOVA allocator should do it job. While touching the
parameter
S5P-MFC driver relied on the way the ARM DMA-IOMMU glue code worked -
mainly it relied on the fact that the allocator used first-fit algorithm
and the first allocated buffer were at 0x0 DMA/IOVA address. This is not
true for the generic IOMMU-DMA glue code that will be used for ARM
architecture
Implement support for the DMA_ATTR_LOW_ADDRESS DMA attribute. If it has
been set, call alloc_iova_first_fit() instead of the alloc_iova_fast() to
allocate the new IOVA from the beginning of the address space.
Signed-off-by: Marek Szyprowski
---
drivers/iommu/dma-iommu.c | 50
Add support for the 'first-fit' allocation algorithm. It will be used for
the special case of implementing DMA_ATTR_LOW_ADDRESS, so this path
doesn't use IOVA cache.
Signed-off-by: Marek Szyprowski
---
drivers/iommu/iova.c | 78
include/linux/iova.h
Some devices require to allocate a special buffer (usually for the
firmware) just at the beginning of the address space to ensure that all
further allocations can be expressed as a positive offset from that
special buffer. When IOMMU is used for managing the DMA address space,
such requirement can
Exynos4-IS driver relied on the way the ARM DMA-IOMMU glue code worked -
mainly it relied on the fact that the allocator used first-fit algorithm
and the first allocated buffer were at 0x0 DMA/IOVA address. This is not
true for the generic IOMMU-DMA glue code that will be used for ARM
architecture
This driver always operates on the DMA/IOVA addresses, so calling them
physicall addresses is misleading, although when no IOMMU is used they
equal each other. Fix this by renaming all such entries to 'addr' and
adjusting comments.
Signed-off-by: Marek Szyprowski
---
proposed
by Robin Murphy in [2] after the discussion of the workaround implemented
directly in the mentioned drivers [3].
Here is a git branch with this patchset and [1] patches applied on top of
linux next-20200925:
https://github.com/mszyprow/linux/tree/v5.9-next-20200925-arm-dma-iommu-low-address
Zero is a valid DMA and IOVA address on many architectures, so adjust the
IOVA management code to properly handle it. A new value IOVA_BAD_ADDR
(~0UL) is introduced as a generic value for the error case. Adjust all
callers of the alloc_iova_fast() function for the new return value.
Signed-off-by:
On Thu, Sep 24, 2020 at 10:54:50AM +, David Laight wrote:
From: Coiby Xu
Sent: 24 September 2020 11:21
Use __8 to replace int and remove the unnecessary __bitwise type attribute.
Found by sparse,
...
diff --git a/include/uapi/sound/asound.h b/include/uapi/sound/asound.h
index
On Tue, 22 Sep 2020 at 15:24, YueHaibing wrote:
>
> There is no caller in tree, so can remove it.
>
> Signed-off-by: YueHaibing
Reviewed-by: Vincent Guittot
> ---
> kernel/sched/core.c | 5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>
On Thu, 24 Sep 2020 at 03:55, Xianting Tian wrote:
>
> In the file fair.c, sometims update_tg_load_avg(cfs_rq, 0) is used,
> sometimes update_tg_load_avg(cfs_rq, false) is used.
> update_tg_load_avg() has the parameter force, but in current code,
> it never set 1 or true to it, so remove the
On Thu, Sep 24, 2020 at 07:50:57AM -0500, Alex Elder wrote:
On 9/24/20 5:20 AM, Coiby Xu wrote:
This patch fix the following warnings from sparse,
You need to address Greg's comment.
But in general this looks good. I have one comment below, which
you can address in v2. If you (or others)
On 2020-09-25 15:20, Alejandro Colomar wrote:
> 'nitems()' calculates the length of an array in number of items.
> It is safe: if a pointer is passed to the macro (or function, in C++),
> the compilation is broken due to:
> - In >= C11: _Static_assert()
> - In C89, C99: Negative anonymous
From: Zhou Wang
The zero length input will cause a call trace when use GZIP
decompress like this:
Unable to handle kernel paging request at virtual address
...
lr : get_gzip_head_size+0x7c/0xd0 [hisi_zip]
Judge the input length and return '-EINVAL' when input is invalid.
Fixes:
On Thu, 24 Sep 2020 at 14:59, Christoph Hellwig wrote:
>
> i915_gem_object_map implements fairly low-level vmap functionality in
> a driver. Split it into two helpers, one for remapping kernel memory
> which can use vmap, and one for I/O memory that uses vmap_pfn.
>
> The only practical
This patchset fix some bug:
patch 1:clear the debug registers when remove driver
patch 2:intercept invalid input when using decompress
patch 3:replace the return value '-EBUSY' with '-EAGAIN' when
device is busy
patch 4:initialize the 'curr_qm_qp_num' when probe device
Resend this patch
As before, when the ZIP device is too busy to creat a request, it will
return '-EBUSY'. But the crypto process think the '-EBUSY' means a
successful request and wait for its completion.
So replace '-EBUSY' with '-EAGAIN' to show crypto this request is failed.
Fixes: 62c455ca853e("crypto:
From: Hao Fang
ZIP debug registers aren't cleared even if its driver is removed,
so add a clearing operation when remove driver.
Signed-off-by: Hao Fang
Signed-off-by: Yang Shen
Reviewed-by: Zhou Wang
---
drivers/crypto/hisilicon/zip/zip_main.c | 18 ++
1 file changed, 18
On Sat, Sep 19, 2020 at 10:19 AM Russell King - ARM Linux admin
wrote:
>
> On Fri, Sep 18, 2020 at 02:46:15PM +0200, Arnd Bergmann wrote:
> > Hi Christoph, Russell,
> >
> > Here is an updated series for removing set_fs() from arch/arm,
> > based on the previous feedback.
> >
> > I have tested the
From: Sihang Chen
The 'qm->curr_qm_qp_num' is not initialized, which will result in failure
to write the current_q file.
Signed-off-by: Sihang Chen
Signed-off-by: Yang Shen
Reviewed-by: Zhou Wang
---
drivers/crypto/hisilicon/zip/zip_main.c | 1 +
1 file changed, 1 insertion(+)
diff --git
On Thu, Sep 24, 2020 at 01:00:57PM +0200, Greg Kroah-Hartman wrote:
On Thu, Sep 24, 2020 at 06:20:39PM +0800, Coiby Xu wrote:
Use __8 to replace int and remove the unnecessary __bitwise type attribute.
Found by sparse,
$ make C=2 drivers/staging/greybus/
When running as Xen dom0 the kernel isn't responsible for selecting the
error handling mode, this should be handled by the hypervisor.
So disable setting FF mode when running as Xen pv guest. Not doing so
might result in boot splats like:
[7.509696] HEST: Enabling Firmware First mode for
Re-add into the mail loop list.
ChiYuan Huang 於 2020年9月25日 週五 下午12:09寫道：
>
> Mark Brown 於 2020年9月25日 週五 上午12:24寫道：
> >
> > On Thu, Sep 24, 2020 at 11:04:51PM +0800, cy_huang wrote:
> >
> > > + enable-gpio:
> > > +description: A connection of the 'enable' gpio line.
> > > +maxItems: 1
>
Mark Brown 於 2020年9月25日 週五 下午7:33寫道：
>
> On Fri, Sep 25, 2020 at 12:07:50PM +0800, ChiYuan Huang wrote:
> > Mark Brown 於 2020年9月25日 週五 上午12:12寫道：
>
> Please don't take things off-list unless there is a really strong reason
> to do so. Sending things to the list ensures that everyone gets a
>
On 25/09/2020 12:06, Weiyi Lu wrote:
On Thu, 2020-09-10 at 19:28 +0200, Enric Balletbo i Serra wrote:
Dear all,
This is a new driver with the aim to deprecate the mtk-scpsys driver.
The problem with that driver is that, in order to support more Mediatek
SoCs you need to add some logic to
From: Kan Liang
There are some updates for the Icelake model specific uncore performance
monitors. (The update can be found at 10th generation intel core
processors families specification update Revision 004, ICL068)
1) Counter 0 of ARB uncore unit is not available for software use
2) The
On 25.09.2020 15:45, boris.ostrov...@oracle.com wrote:
> On 9/25/20 6:11 AM, Juergen Gross wrote:
>> @@ -1296,6 +1296,14 @@ asmlinkage __visible void __init
>> xen_start_kernel(void)
>>
>> xen_smp_init();
>>
>> +#ifdef CONFIG_ACPI
>> +/*
>> + * Disable selecting "Firmware First
Hi Herbert,
Thanks for your patch, The changes look good.
I have tested this patch, so,
Tested-by: Tianjia Zhang
Best regards,
Tianjia
On 9/25/20 4:19 PM, Herbert Xu wrote:
On Mon, Sep 21, 2020 at 12:20:55AM +0800, Tianjia Zhang wrote:
Expand the mpi library based on libgcrypt, and the ECC
Hey Ionela,
On Thursday 24 Sep 2020 at 17:10:02 (+0100), Ionela Voinescu wrote:
> I'm not sure what is a good way of fixing this.. I could add more info
> to the warning to suggest it might be temporary ("Disabling EAS:
> frequency-invariant load tracking currently not supported"). For further
>
Adds the driver_info and usb ids of the AX88179 based Toshiba USB 3.0
ethernet adapter.
Signed-off-by: Wilken Gottwalt
---
Changes in v2:
- reposted to proper mailing list with correct commit message as
suggested by Jakub Kicinski
---
drivers/net/usb/ax88179_178a.c | 17
On Wed, Sep 16, 2020 at 08:34:10PM +0200, David Hildenbrand wrote:
> Page isolation doesn't actually touch the pages, it simply isolates
> pageblocks and moves all free pages to the MIGRATE_ISOLATE freelist.
>
> We already place pages to the tail of the freelists when undoing
> isolation via
Hi Ethan,
On 9/24/20 9:34 PM, Ethan Zhao wrote:
When uncorrectable error happens, AER driver and DPC driver interrupt
handlers likely call
pcie_do_recovery()->pci_walk_bus()->report_frozen_detected() with
pci_channel_io_frozen the same time.
If pci_dev_set_io_state() return true even if
On Wed, 2020-08-26 at 13:17 +0200, Thomas Gleixner wrote:
> From: Thomas Gleixner
>
> The arch_.*_msi_irq[s] fallbacks are compiled in whether an architecture
> requires them or not. Architectures which are fully utilizing hierarchical
> irq domains should never call into that code.
>
> It's
701 - 800 of 1528 matches
Mail list logo
