On 9 Oct 2020, at 11:34, Sean V Kelley wrote:
On 9 Oct 2020, at 11:26, Sean V Kelley wrote:
Hi Bjorn,
On 9 Oct 2020, at 10:57, Bjorn Helgaas wrote:
On Fri, Oct 02, 2020 at 11:47:32AM -0700, Sean V Kelley wrote:
From: Qiuxu Zhuo
When attempting error recovery for an RCiEP associated with
Jerome Pouiller writes:
> From: Jérôme Pouiller
>
> Smatch complains:
>
>drivers/staging/wfx/hif_rx.c:177 hif_scan_complete_indication() warn:
> potential NULL parameter dereference 'wvif'
>drivers/staging/wfx/data_tx.c:576 wfx_flush() warn: potential NULL
> parameter dereference 'wvif
Jerome Pouiller writes:
> From: Jérôme Pouiller
>
> Smatch complains:
>
>main.c:228 wfx_send_pdata_pds() warn: potential NULL parameter dereference
> 'tmp_buf'
>227 tmp_buf = kmemdup(pds->data, pds->size, GFP_KERNEL);
>228 ret = wfx_send_pds(wdev, tmp_buf, pds->siz
Hi Florian,
On Fri, 9 Oct 2020, Florian Westphal wrote:
> Jozsef Kadlecsik wrote:
> > > The reproducer has two files. client_server.py creates both ends of
> > > a tcp connection, bounces a few packets back and forth, and then
> > > blocks on a recv on the client side. The client's keepalive i
On 10/9/20 2:42 AM, Pali Rohár wrote:
> Older ATF does not provide SMC call for SATA phy power on functionality and
> therefore initialization of ahci_mvebu is failing when older version of ATF
> is using. In this case phy_power_on() function returns -EOPNOTSUPP.
>
> This patch adds a new hflag AH
On 10/9/20 2:00 AM, Yang Yang wrote:
> blk_exit_queue will free elevator_data, while blk_mq_run_work_fn
> will access it. Move cancel of hctx->run_work to the front of
> blk_exit_queue to avoid use-after-free.
Applied, thanks.
--
Jens Axboe
On Fri, Oct 09, 2020 at 11:34:23AM +0530, Bharata B Rao wrote:
Hi Bharata,
> Object cgroup charging is done for all the objects during
> allocation, but during freeing, uncharging ends up happening
> for only one object in the case of bulk allocation/freeing.
Yes, it's definitely a problem. Than
On 10/9/2020 11:32 AM, Yu-cheng Yu wrote:
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].
[...]
Hi,
The series did not get send out complet
On Fri, 9 Oct 2020 12:30:04 +0800
gchen chen wrote:
> Alex Williamson 于2020年9月30日周三 下午10:09写道：
> >
> >
> > Please version your postings so we know which one to consider as the
> > current proposal.
> >
> > On Wed, 30 Sep 2020 20:54:39 +0800
> > guomin_c...@sina.com wrote:
> >
> > > From: guomi
On 10/1/20 1:50 AM, Thorsten Leemhuis wrote:
> Describe what users have to do if they can't reproduce a problem with
> mainline they want to see fixed in stable and longterm kernels. This is
> separated from the main flow, as integrating it there would make it
> harder to follow.
>
> Note users wi
On Fri, Oct 09, 2020 at 02:15:31PM +0200, Mauro Carvalho Chehab wrote:
> The README file was converted to ReST format. Update the
> references for it accordingly.
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
> drivers/crypto/allwinner/sun8i-ce/sun8i-ce-hash.c | 2 +-
> drivers/crypto/allwinner
Hi Akhil,
On Thu, Oct 08, 2020 at 10:39:07PM +0530, Akhil P Oommen wrote:
> Register GPU as a devfreq cooling device so that it can be passively
> cooled by the thermal framework.
>
> Signed-off-by: Akhil P Oommen
> ---
> drivers/gpu/drm/msm/msm_gpu.c | 13 -
> drivers/gpu/drm/msm/m
The variable async_registration is used to indicate whether or not
CONFIG_BCACHE_ASYNC_REGISTRATION is enabled, triggering a (false)
warning in Coverity about unreachable code. However, it seems clearer in
this case just to use an #ifdef, so let's do that instead.
Addresses-Coverity-ID: 1497746: C
On Fri, Oct 9, 2020 at 12:25 PM Andy Lutomirski wrote:
> Is the idea that any syscall that's out of range for this (e.g. all of
> the x32 syscalls) is unoptimized? I'm okay with this, but I think it
> could use a comment.
Yes, any syscall number that is out of range is unoptimized. Where do
you
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
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 (Privilege
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
Before introducing _PAGE_COW for non-hardware memory management purposes in
the next patch, rename _PAGE_DIRTY to _PAGE_DIRTY_HW and _PAGE_BIT_DIRTY to
_PAGE_BIT_DIRTY_HW to make meanings more clear. There are no functional
changes from this patch.
Signed-off-by: Yu-cheng Yu
Reviewed-by: Kees Co
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 u
allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a006-20201009
i386 randconfig-a005-20201009
i386 randconfig-a001-20201009
i386 randconfig-a004
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 tunabl
On 9 Oct 2020, at 11:26, Sean V Kelley wrote:
Hi Bjorn,
On 9 Oct 2020, at 10:57, Bjorn Helgaas wrote:
On Fri, Oct 02, 2020 at 11:47:32AM -0700, Sean V Kelley wrote:
From: Qiuxu Zhuo
When attempting error recovery for an RCiEP associated with an RCEC
device,
there needs to be a way to upda
Shadow Stack provides protection against function return address
corruption. It is active when the processor supports it, the kernel has
CONFIG_X86_SHADOW_STACK_USER, and the application is built for the feature.
This is only implemented for the 64-bit kernel. When it is enabled, legacy
non-shado
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: Borislav Petkov
Reviewed-by: Kees Cook
---
arch/x86/include/asm/cpufeatures.h
Account shadow stack pages to stack memory.
Signed-off-by: Yu-cheng Yu
v10:
- Use arch_shadow_stack_mapping() to make meaning clear.
v8:
- Change shadow stake pages from data_vm to stack_vm.
---
arch/x86/mm/pgtable.c | 7 +++
include/linux/pgtable.h | 11 +++
mm/mmap.c
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: Zhen
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.
Shadow stack memory is writable, but its VMA has VM_SHSTK instead of
VM_WRITE. Update maybe_mkwrite() to include the shadow stack.
Signed-off-by: Yu-cheng Yu
---
arch/x86/Kconfig| 4
arch/x86/mm/pgtable.c | 18 ++
include/linux/mm.h | 2 ++
include/linux/pg
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
C
Pte_modify() changes a PTE to 'newprot'. It doesn't use the pte_*()
helpers that a previous patch fixed up, so we need a new site.
Introduce fixup_dirty_pte() to set the dirty bits based on _PAGE_RW, and
apply the same changes to pmd_modify().
Signed-off-by: Yu-cheng Yu
v14:
- Update fixup_dir
When shadow stack is introduced, [R/O + _PAGE_DIRTY_HW] PTE is reserved
for shadow stack. Copy-on-write PTEs have [R/O + _PAGE_COW].
When a PTE goes from [R/W + _PAGE_DIRTY_HW] to [R/O + _PAGE_COW], it could
become a transient shadow stack PTE in two cases:
The first case is that some processors
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
A shadow stack page is made writable by pte_mkwrite_shstk(), which sets
_PAGE_DIRTY_HW. There are a few places that call pte_mkwrite() directly
and miss the maybe_mkwrite() fixup in the previous patch. Fix them with
maybe_mkwrite():
- do_anonymous_page() and migrate_vma_insert_page() check VM_WR
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
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
On Fri, Oct 9, 2020 at 7:32 AM Jason Gunthorpe wrote:
>
> On Fri, Oct 09, 2020 at 04:24:45PM +0200, Daniel Vetter wrote:
> > On Fri, Oct 9, 2020 at 2:31 PM Jason Gunthorpe wrote:
> > >
> > > On Fri, Oct 09, 2020 at 09:59:31AM +0200, Daniel Vetter wrote:
> > >
> > > > +struct address_space *iomem_
Hi Bjorn,
On 9 Oct 2020, at 10:57, Bjorn Helgaas wrote:
On Fri, Oct 02, 2020 at 11:47:32AM -0700, Sean V Kelley wrote:
From: Qiuxu Zhuo
When attempting error recovery for an RCiEP associated with an RCEC
device,
there needs to be a way to update the Root Error Status, the
Uncorrectable
Er
On Okt 09 2020, Sagar Shrikant Kadam wrote:
> diff --git a/drivers/i2c/busses/i2c-ocores.c b/drivers/i2c/busses/i2c-ocores.c
> index f5fc75b..9b3d1ab 100644
> --- a/drivers/i2c/busses/i2c-ocores.c
> +++ b/drivers/i2c/busses/i2c-ocores.c
> @@ -686,17 +686,21 @@ static int ocores_i2c_probe(struct pl
On Fri, Oct 09, 2020 at 01:54:34PM -0400, Qian Cai wrote:
> On Fri, 2020-10-09 at 13:36 -0400, Qian Cai wrote:
> > Back to x86, we have:
> >
> > start_secondary()
> > smp_callin()
> > apic_ap_setup()
> > setup_local_APIC()
> > printk() in certain conditions.
> >
> > which is b
access in kernel mode
Oct 09 14:17:46 lp-sasha kernel: #PF: error_code(0x) - not-present page
Oct 09 14:17:46 lp-sasha kernel: PGD 0 P4D 0
Oct 09 14:17:46 lp-sasha kernel: Oops: [#1] SMP PTI
Oct 09 14:17:46 lp-sasha kernel: CPU: 1 PID: 191 Comm: systemd-udevd Not
tainted 5.9.0-rc8-next-20201009
On Thu, 8 Oct 2020 20:19:28 +0800
Pujin Shi wrote:
> For older versions of gcc, the array = {0}; will cause warnings:
>
> net/smc/smc_llc.c: In function 'smc_llc_send_link_delete_all':
> net/smc/smc_llc.c:1317:9: warning: missing braces around initializer
> [-Wmissing-braces]
> struct smc_ll
On Fri, Oct 09, 2020 at 07:52:05PM +0200, Daniel Vetter wrote:
> > > If this is the case, the proper fix seems to have a GFP_NOT_MOVABLE
> > > flag that it would be denying the core mm code to set __GFP_MOVABLE.
> >
> > We can't tell from the VMA these kinds of details..
> >
> > It has to go the o
On Thu, 8 Oct 2020 20:19:29 +0800
Pujin Shi wrote:
> For older versions of gcc, the array = {0}; will cause warnings:
>
> net/smc/smc_llc.c: In function 'smc_llc_add_link_local':
> net/smc/smc_llc.c:1212:9: warning: missing braces around initializer
> [-Wmissing-braces]
> struct smc_llc_msg_
On Fri, Oct 09, 2020 at 09:55:55AM -0600, Shuah Khan wrote:
> Note: Would like to get this into Linux 5.10-rc1 so we can continue
> updating drivers that can be updated to use this API. If this all looks
> good, Kees, would you like to take this through your tree or would you
> like to take this th
On Fri, Oct 09, 2020 at 09:55:59AM -0600, Shuah Khan wrote:
> counter_atomic* is introduced to be used when a variable is used as
> a simple counter and doesn't guard object lifetimes. This clearly
> differentiates atomic_t usages that guard object lifetimes.
>
> counter_atomic* variables wrap aro
On Fri, Oct 09, 2020 at 10:13:13AM -0700, Paul E. McKenney wrote:
> On Fri, Oct 09, 2020 at 06:55:00PM +0200, Ingo Molnar wrote:
> >
> > * Paul E. McKenney wrote:
> >
> > > Hello!
> > >
> > > This pull request contains Thomas Gleixner's "Make preempt count
> > > unconditional" series [1], but w
On Fri, Oct 09, 2020 at 09:55:57AM -0600, Shuah Khan wrote:
> Add a new selftest for testing counter_atomic* Counters API. This test
> load test_counters test modules and unloads.
>
> The test module runs tests and prints results in dmesg.
>
> There are a number of atomic_t usages in the kernel w
On Fri, 2020-10-09 at 18:14 +0200, Borislav Petkov wrote:
> From: Borislav Petkov
>
> Instruction opcode bytes spelled using the gas directive .byte should
> carry a comment above them stating which binutils version has added
> support for the instruction mnemonic so that they can be replaced wit
On Fri, Oct 09, 2020 at 09:55:56AM -0600, Shuah Khan wrote:
> Introduce Simple atomic counters.
>
> There are a number of atomic_t usages in the kernel where atomic_t api
> is used strictly for counting and not for managing object lifetime. In
> some cases, atomic_t might not even be needed.
>
>
On Fri, Oct 02, 2020 at 11:47:32AM -0700, Sean V Kelley wrote:
> From: Qiuxu Zhuo
>
> When attempting error recovery for an RCiEP associated with an RCEC device,
> there needs to be a way to update the Root Error Status, the Uncorrectable
> Error Status and the Uncorrectable Error Severity of the
On Fri, 2020-10-09 at 13:36 -0400, Qian Cai wrote:
> Back to x86, we have:
>
> start_secondary()
> smp_callin()
> apic_ap_setup()
> setup_local_APIC()
> printk() in certain conditions.
>
> which is before smp_store_cpu_info().
>
> Can't we add a rcu_cpu_starting() at the very
Hi Linus,
The following changes since commit 9123e3a74ec7b934a4a099e98af6a61c2f80bbf5:
Linux 5.9-rc1 (2020-08-16 13:04:57 -0700)
are available in the Git repository at:
ssh://g...@gitolite.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply.git
tags/for-v5.9-rc
for you to fetch ch
The following changes since commit 549738f15da0e5a00275977623be199fbbf7df50:
Linux 5.9-rc8 (2020-10-04 16:04:34 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git
tags/riscv-for-linus-5.9
for you to fetch changes up to 84814460eef9a
On Fri, Oct 9, 2020 at 2:48 PM Jason Gunthorpe wrote:
>
> On Fri, Oct 09, 2020 at 02:37:23PM +0200, Mauro Carvalho Chehab wrote:
>
> > I'm not a mm/ expert, but, from what I understood from Daniel's patch
> > description is that this is unsafe *only if* __GFP_MOVABLE is used.
>
> No, it is uncond
On Fri, Oct 09, 2020 at 01:36:47PM -0400, Qian Cai wrote:
> On Fri, 2020-10-09 at 18:23 +0200, Peter Zijlstra wrote:
> > On Fri, Oct 09, 2020 at 06:58:37AM -0700, Paul E. McKenney wrote:
> > > On Fri, Oct 09, 2020 at 09:41:24AM -0400, Qian Cai wrote:
> > > > On Fri, 2020-10-09 at 07:58 +, tip-b
Hi,
>-Original Message-
>From: Ulf Hansson
>Sent: Friday, October 9, 2020 2:56 PM
>To: Zulkifli, Muhammad Husaini
>Cc: Hunter, Adrian ; Michal Simek
>; Shevchenko, Andriy
>; linux-...@vger.kernel.org; Linux ARM
>; Linux Kernel Mailing List ker...@vger.kernel.org>; Raja Subramanian, Laksh
On Fri, Oct 09, 2020 at 02:29:21PM +0200, Michal Hocko wrote:
> Hi,
> let me repost the pile that has grown from the initial patch based on
> the review feedback I have collected from Peter. I do realize that he
> also suggested to go from the other direction and implement this for the
> full preem
On 10/8/20 10:50 PM, Hugh Dickins wrote:
> On Thu, 8 Oct 2020, Mike Kravetz wrote:
>> On 10/7/20 8:21 PM, Hugh Dickins wrote:
>>>
>>> Mike, j'accuse... your 5.7 commit c0d0381ade79 ("hugetlbfs:
>>> use i_mmap_rwsem for more pmd sharing synchronization"), in which
>>> unmap_and_move_huge_page() now
On Fri, Oct 09, 2020 at 05:18:03PM +, Yazen Ghannam wrote:
> From: Yazen Ghannam
>
> AMD Family 19h Models 20h-2Fh use the same PCI IDs as Family 17h Models
> 70h-7Fh. The same family ops and number of channels also apply.
>
> Use the Family17h Model 70h family_type and ops for Family 19h Mo
On Tue, Oct 6, 2020 at 12:09 PM Yu, Yu-cheng wrote:
>
> On 10/1/2020 10:26 AM, Andy Lutomirski wrote:
> > On Thu, Oct 1, 2020 at 9:51 AM Yu, Yu-cheng wrote:
> >>
> >> On 9/30/2020 6:10 PM, Andy Lutomirski wrote:
> >>> On Wed, Sep 30, 2020 at 6:01 PM H.J. Lu wrote:
>
> On Wed, Sep 30, 2
On Wed, Oct 07, 2020 at 04:41PM +0200, Marco Elver wrote:
> On Wed, 7 Oct 2020 at 16:15, Jann Horn wrote:
[...]
> > > > > + return false;
> > > > > +
> > > > > + if (protect)
> > > > > + set_pte(pte, __pte(pte_val(*pte) & ~_PAGE_PRESENT));
> > > > > + else
>
On Thu, 8 Oct 2020 17:46:00 +0200 Arnd Bergmann wrote:
> This driver was only used on the EBSA110 platform, which is now
> getting removed, so the driver is no longer needed either.
>
> Signed-off-by: Arnd Bergmann
FWIW
Acked-by: Jakub Kicinski
On 10/1/20 1:50 AM, Thorsten Leemhuis wrote:
> Users should know that sending the report is not the end of this
> process: if want to see the issue fixed, they will need to keep the ball
> rolling sometimes. Hence, explain why it's in their interest to send a
> reminder occasionally. Als point out
From: YiFei Zhu
Currently the kernel does not provide an infrastructure to translate
architecture numbers to a human-readable name. Translating syscall
numbers to syscall names is possible through FTRACE_SYSCALL
infrastructure but it does not provide support for compat syscalls.
This will create
On Fri, 2020-10-09 at 18:23 +0200, Peter Zijlstra wrote:
> On Fri, Oct 09, 2020 at 06:58:37AM -0700, Paul E. McKenney wrote:
> > On Fri, Oct 09, 2020 at 09:41:24AM -0400, Qian Cai wrote:
> > > On Fri, 2020-10-09 at 07:58 +, tip-bot2 for Peter Zijlstra wrote:
> > > > The following commit has bee
Hi!
> Thank you for the review.
Note I'm LED maintainer.
> > > + leds {
> > > + compatible = "gpio-leds";
> > > +
> > > + sdhi2_led {
> > > + label = "sdio-led";
> >
> > This should use appropriate label... probably mmc1:green:activity.
> >
> $ gre
On Fri, Oct 09, 2020 at 08:57:55AM -0600, Jens Axboe wrote:
> > + if (unlikely(!cur_uring)) {
> > int ret;
> >
> > ret = io_uring_alloc_task_context(current);
> > if (unlikely(ret))
> > return ret;
> > }
>
> I think this is missing a:
From: Kees Cook
Provide seccomp internals with the details to calculate which syscall
table the running kernel is expecting to deal with. This allows for
efficient architecture pinning and paves the way for constant-action
bitmaps.
Signed-off-by: Kees Cook
Co-developed-by: YiFei Zhu
Signed-off
For the whole series:
For the whole series:
Reviewed-by: Lyude Paul
I'm going to add a Cc for stable so that it can be backported, and I'll push it
to drm-intel-next-queued once I get the OK from drm-misc/i915 folks
On Fri, 2020-10-09 at 16:57 +0800, Aaron Ma wrote:
> BOE panel with ID 2270 cl
On Fri, Oct 9, 2020 at 10:15 AM YiFei Zhu wrote:
>
> From: Kees Cook
>
> Provide seccomp internals with the details to calculate which syscall
> table the running kernel is expecting to deal with. This allows for
> efficient architecture pinning and paves the way for constant-action
> bitmaps.
>
From: Kees Cook
As part of the seccomp benchmarking, include the expectations with
regard to the timing behavior of the constant action bitmaps, and report
inconsistencies better.
Example output with constant action bitmaps on x86:
$ sudo ./seccomp_benchmark 1
Current BPF sysctl setting
On 10/9/20 9:53 AM, Ira Weiny wrote:
On Thu, Oct 08, 2020 at 10:25:44AM -0700, Ralph Campbell wrote:
ZONE_DEVICE struct pages have an extra reference count that complicates the
code for put_page() and several places in the kernel that need to check the
reference count to see that a page is not
From: YiFei Zhu
The overhead of running Seccomp filters has been part of some past
discussions [1][2][3]. Oftentimes, the filters have a large number
of instructions that check syscall numbers one by one and jump based
on that. Some users chain BPF filters which further enlarge the
overhead. A re
On Fri, Sep 18, 2020 at 07:02:35PM -0700, Bhaumik Bhatt wrote:
> Clients on the host may see the device in an active state for a short
Clients? Are you referring client drivers or controllers? Please don't mix
the conventions.
> period of time after the host detects a device error or power down.
From: Yazen Ghannam
AMD Family 19h Models 20h-2Fh use the same PCI IDs as Family 17h Models
70h-7Fh. The same family ops and number of channels also apply.
Use the Family17h Model 70h family_type and ops for Family 19h Models
20h-2Fh. Update the controller name to match the system.
Signed-off-b
From: YiFei Zhu
SECCOMP_CACHE will only operate on syscalls that do not access
any syscall arguments or instruction pointer. To facilitate
this we need a static analyser to know whether a filter will
return allow regardless of syscall arguments for a given
architecture number / syscall number pai
From: YiFei Zhu
Alternative:
https://lore.kernel.org/lkml/20200923232923.3142503-1-keesc...@chromium.org/T/
Major differences from the linked alternative by Kees:
* No x32 special-case handling -- not worth the complexity
* No caching of denylist -- not worth the complexity
* No seccomp arch pi
From: Jérôme Pouiller
Smatch complains:
hif_rx.c:98 hif_wakeup_indication() warn:
'gpiod_get_value(wdev->pdata.gpio_wakeup)' returns positive and negative
bh.c:24 device_wakeup() warn:
'gpiod_get_value_cansleep(wdev->pdata.gpio_wakeup)' returns positive and
negative
Reported-by: Dan
On 9 October 2020 19:01:59 CEST, Aleksandr Nogikh wrote:
>This patch series conflicts with another proposed patch
>http://lkml.kernel.org/r/223901affc7bd759b2d6995c2dbfbdd0a29bc88a.1602248029.git.andreyk...@google.com
>One of these patches needs to be rebased once the other one is merged.
Ma
From: Jérôme Pouiller
Smatch complains:
data_tx.c:37 wfx_get_hw_rate() warn: constraint '(struct
ieee80211_supported_band)->bitrates' overflow 'band->bitrates' 0 <= abs_rl
'0-127' user_rl '' required = '(struct ieee80211_supported_band)->n_bitrates'
23 struct ieee80211_support
From: Jérôme Pouiller
Smatch complains:
bus_spi.c:228 wfx_spi_probe() warn: 'bus->core' could be an error pointer
bus_sdio.c:221 wfx_sdio_probe() warn: 'bus->core' could be an error pointer
bus->core contains the result of wfx_init_common(). With this patch,
wfx_init_common() returns a
From: Jérôme Pouiller
Smatch complains:
main.c:228 wfx_send_pdata_pds() warn: potential NULL parameter dereference
'tmp_buf'
227 tmp_buf = kmemdup(pds->data, pds->size, GFP_KERNEL);
228 ret = wfx_send_pds(wdev, tmp_buf, pds->size);
From: Jérôme Pouiller
Smatch complains:
hif_rx.c:235 hif_generic_indication() warn: format string contains non-ascii
character '\xc2'
hif_rx.c:235 hif_generic_indication() warn: format string contains non-ascii
character '\xb0'
234 if (!wfx_api_older_than(wdev, 1, 4))
From: Jérôme Pouiller
Smatch complains:
hif_tx.c:319 hif_join() error: we previously assumed 'channel' could be null
(see line 315)
311 if (!hif)
312 return -ENOMEM;
313 body->infrastructure_bss_mode = !conf->ibss_joined;
314 body->shor
From: Jérôme Pouiller
Smatch complains:
drivers/staging/wfx/hif_rx.c:26 hif_generic_confirm() warn: negative user
subtract: 0-u16max - 4
20 static int hif_generic_confirm(struct wfx_dev *wdev,
21 const struct hif_msg *hif, const void
*buf)
22 {
From: Jérôme Pouiller
Smatch complains:
drivers/staging/wfx/hif_rx.c:177 hif_scan_complete_indication() warn:
potential NULL parameter dereference 'wvif'
drivers/staging/wfx/data_tx.c:576 wfx_flush() warn: potential NULL parameter
dereference 'wvif'
Indeed, if the vif id returned by the
The pull request you sent on Fri, 9 Oct 2020 08:46:00 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git tags/mmc-v5.9-rc4-4
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/f318052ef2f07da2cd0c535d0d2900d5080a47e1
Thank you!
--
Deet-doot-dot, I am a
From: Jérôme Pouiller
Fix the issues reported by Dan using Smatch[1].
[1] https://lore.kernel.org/lkml/20201008131320.GA1042@kadam/
Jérôme Pouiller (8):
staging: wfx: improve error handling of hif_join()
staging: wfx: check memory allocation
staging: wfx: standardize the error when vif do
On Fri, Oct 09, 2020 at 06:55:00PM +0200, Ingo Molnar wrote:
>
> * Paul E. McKenney wrote:
>
> > Hello!
> >
> > This pull request contains Thomas Gleixner's "Make preempt count
> > unconditional" series [1], but with the addition of a kvfree_rcu() bug-fix
> > commit making use of this PREEMPT_C
The pull request you sent on Fri, 9 Oct 2020 14:29:16 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-10-09
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/fd330b1bc2f5840d68cbfa61c60573b4250bf14f
Thank you!
--
Deet-doot-dot, I am a bot.
https://ko
On Fri, Oct 09, 2020 at 06:23:06PM +0200, Ard Biesheuvel wrote:
> On Fri, 9 Oct 2020 at 17:24, Lorenzo Pieralisi
> wrote:
> > We can move this check to IORT code and call it from arm64 if it
> > can be made to work.
>
> Finding the smallest value in the IORT, and assigning it to
> zone_dma_bits i
Add a yamllint config file and support for running yamllint on DT
binding schema files. This runs on the whole tree as yamllint is Python
and suffers from Python's slow startup times.
Users can run on individual files doing:
yamllint -c Documentation/devicetree/bindings/.yamllint
Signed-off-by:
On 10/9/2020 9:38 AM, Sudeep Holla wrote:
On Sat, Sep 19, 2020 at 03:22:30PM -0400, Jim Quinlan wrote:
only implements the agent-to-platform channel;
In that case any reason why you can't reuse the existing smc transport
for SCMI. It was added recently in case you haven't checked the latest
From: Aleksandr Nogikh
Add KCOV remote annotations to ieee80211_iface_work and
ieee80211_rx. This will enable coverage-guided fuzzing of mac80211
code that processes incoming 802.11 frames.
Signed-off-by: Aleksandr Nogikh
---
v2:
* The commit now affects ieee80211_rx instead of
ieee80211_task
The following commit has been merged into the core/rcu branch of tip:
Commit-ID: 16a6320addfc4692a79aa452eefd40460fff4959
Gitweb:
https://git.kernel.org/tip/16a6320addfc4692a79aa452eefd40460fff4959
Author:Uladzislau Rezki (Sony)
AuthorDate:Tue, 22 Sep 2020 21:06:22 +02:00
From: Aleksandr Nogikh
kcov_common_handle is a method that is used to obtain a "default" KCOV
remote handle of the current process. The handle can later be passed
to kcov_remote_start in order to collect coverage for the processing
that is initiated by one process, but done in another. For detail
The following commit has been merged into the core/rcu branch of tip:
Commit-ID: 68e10f9fe712edbc69be2a1e2914ea6e31a9283f
Gitweb:
https://git.kernel.org/tip/68e10f9fe712edbc69be2a1e2914ea6e31a9283f
Author:Thomas Gleixner
AuthorDate:Mon, 14 Sep 2020 19:33:53 +02:00
Committe
The following commit has been merged into the core/rcu branch of tip:
Commit-ID: 7681205ba49d8b0dcb3a0f55d97f71e1da93e972
Gitweb:
https://git.kernel.org/tip/7681205ba49d8b0dcb3a0f55d97f71e1da93e972
Author:Thomas Gleixner
AuthorDate:Mon, 14 Sep 2020 19:18:06 +02:00
Committe
The following commit has been merged into the core/rcu branch of tip:
Commit-ID: 45015f8840baa8a99f5161d42fc1ca070d534365
Gitweb:
https://git.kernel.org/tip/45015f8840baa8a99f5161d42fc1ca070d534365
Author:Thomas Gleixner
AuthorDate:Mon, 14 Sep 2020 20:35:55 +02:00
Committe
301 - 400 of 1086 matches
Mail list logo
