This set is part of a larger effort attempting to clean-up W=1
kernel builds, which are currently overwhelmingly riddled with
niggly little warnings.
Last set! All clean after this for; Arm, Arm64, PPC, MIPS and x86.
Lee Jones (29):
drm/vmwgfx/vmwgfx_cmdbuf: Fix misnaming of 'headers' should b
Also fix a small formatting issue.
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c:83: warning: Function parameter or
member 'res_type' not described in 'vmw_cmdbuf_res_lookup'
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c:83: warning: Excess function
Hi Linus,
Please pull the arm64 fixes below. Thanks.
The following changes since commit 7c53f6b671f4aba70ff15e1b05148b10d58c2837:
Linux 5.11-rc3 (2021-01-10 14:34:50 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes
f
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/gma500/gem.h:13:57: warning: ‘struct drm_device’ declared
inside parameter list will not be visible outside of this definition or
declaration
Cc: Patrik Jakobsson
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesk
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/gma500/psb_intel_modes.c:17: warning: Function parameter or
member 'adapter' not described in 'psb_intel_ddc_probe'
drivers/gpu/drm/gma500/psb_intel_modes.c:51: warning: Function parameter or
member 'adapter' not described in 'ps
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/gma500/gma_display.c:27: warning: Function parameter or member
'crtc' not described in 'gma_pipe_has_type'
drivers/gpu/drm/gma500/gma_display.c:27: warning: Function parameter or member
'type' not described in 'gma_pipe_has_type'
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c:142: warning: Excess function parameter
'pin' description in 'vmw_bo_pin_in_vram_or_gmr'
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c:647: warning: Function parameter or member
'p_base' not described in 'vmw_user_bo_allo
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c:48: warning: cannot understand
function prototype: 'struct vmw_overlay '
drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c:98: warning: Function parameter or
member 'dev_priv' not described in 'vmw_overlay_send_put'
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c:58: warning: Function parameter or
member 'block_submission' not described in 'vmw_cmdbuf_context'
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c:109: warning: cannot understand
function prototype: 'struct vmw_cmdb
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c:90: warning: cannot understand function
prototype: 'struct vmw_screen_object_unit '
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c:122: warning: Function parameter or
member 'dev_priv' not described in 'vmw_sou_fifo_cr
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/gma500/power.c:190: warning: Excess function parameter 'state'
description in 'gma_power_suspend'
Cc: Patrik Jakobsson
Cc: David Airlie
Cc: Daniel Vetter
Cc: Benjamin Defnet
Cc: Rajesh Poornachandran
Cc: Alan Cox
Cc: dri-de.
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/vmwgfx/vmwgfx_context.c:121: warning: Function parameter or
member 'dev_priv' not described in 'vmw_context_cotables_unref'
drivers/gpu/drm/vmwgfx/vmwgfx_context.c:121: warning: Function parameter or
member 'uctx' not described i
hr_sleep is a new system call engineered for nanosecond time scale
granularities.
With respect to nanosleep, it uses a single value representation
of the sleep period.
hr_sleep achieves 15x improvement for microsecond scale timers
w.r.t. nanosleep: the reason is the use of a CPU register for
passin
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/gma500/intel_i2c.c:108: warning: Excess function parameter
'output' description in 'psb_intel_i2c_create'
drivers/gpu/drm/gma500/intel_i2c.c:153: warning: Function parameter or member
'chan' not described in 'psb_intel_i2c_destro
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/gma500/gem.c:59:5: warning: no previous prototype for
‘psb_gem_create’ [-Wmissing-prototypes]
Cc: Patrik Jakobsson
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gp
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/vmwgfx/vmwgfx_shader.c:134: warning: Function parameter or
member 'res' not described in 'vmw_res_to_shader'
drivers/gpu/drm/vmwgfx/vmwgfx_shader.c:663: warning: Function parameter or
member 'base' not described in 'vmw_user_shad
Fixes the following W=1 kernel build warning(s):
In file included from drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:37:
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:483: warning: Function parameter or member
'new_state' not described in 'vmw_du_cursor_plane_atomic_check'
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:483:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c:77: warning: Function parameter or member
'pitch' not described in 'vmw_stdu_dirty'
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c:125: warning: Function parameter or
member 'content_fb_type' not described in 'vmw_scre
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c: In function
‘vmw_cmdbuf_res_revert’:
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c:162:6: warning: variable ‘ret’ set
but not used [-Wunused-but-set-variable]
Cc: VMware Graphics
Cc: Roland Scheidegger
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/gma500/mmu.c:420:10: warning: no previous prototype for
‘psb_get_default_pd_addr’ [-Wmissing-prototypes]
Cc: Patrik Jakobsson
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Lee Jones
---
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/gma500/mmu.c:316:20: warning: no previous prototype for
‘psb_mmu_pt_alloc_map_lock’ [-Wmissing-prototypes]
Cc: Patrik Jakobsson
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Lee Jones
--
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c:55: warning: Function parameter or
member 'prime' not described in 'vmw_user_surface'
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c:55: warning: Function parameter or
member 'backup_base' not described in 'vmw_u
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/gma500/power.c:101: warning: Function parameter or member
'pdev' not described in 'gma_resume_display'
drivers/gpu/drm/gma500/power.c:155: warning: Function parameter or member
'pdev' not described in 'gma_resume_pci'
drivers/gp
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/r128/r128_ioc32.c:2: warning: Cannot understand * file
r128_ioc32.c
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/r128/r128_ioc32.c | 2 +-
1 file changed,
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c:55: warning: cannot understand function
prototype: 'struct vmw_legacy_display_unit '
drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c:218: warning: Function parameter or member
'state' not described in 'vmw_ldu_crtc_atomic
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/gma500/framebuffer.c:171: warning: Function parameter or
member 'obj' not described in 'psb_framebuffer_init'
drivers/gpu/drm/gma500/framebuffer.c:171: warning: Excess function parameter
'gt' description in 'psb_framebuffer_init'
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/gma500/gem.c:57:5: warning: no previous prototype for
‘psb_gem_create’ [-Wmissing-prototypes]
drivers/gpu/drm/gma500/gem.c:59: warning: Function parameter or member
'stolen' not described in 'psb_gem_create'
drivers/gpu/drm/gma5
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/gma500/psb_intel_display.c:79: warning: Function parameter or
member 'dev' not described in 'psb_intel_panel_fitter_pipe'
Cc: Patrik Jakobsson
Cc: David Airlie
Cc: Daniel Vetter
Cc: Eric Anholt
Cc: dri-de...@lists.freedesktop.
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/r128/r128_ioc32.c:182: warning: Function parameter or member
'filp' not described in 'r128_compat_ioctl'
drivers/gpu/drm/r128/r128_ioc32.c:182: warning: Function parameter or member
'cmd' not described in 'r128_compat_ioctl'
dri
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/mga/mga_ioc32.c:2: warning: Cannot understand * file
mga_ioc32.c
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/mga/mga_ioc32.c | 2 +-
1 file changed, 1 in
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:89: warning: Enum value
'vmw_res_rel_max' not described in enum 'vmw_resource_relocation_type'
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:136: warning: Function parameter or
member 'func' not described in 'vm
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c:299: warning: Function parameter or
member 'dev_priv' not described in 'vmw_local_fifo_reserve'
drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c:299: warning: Function parameter or
member 'bytes' not described in 'vmw_lo
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c:275: warning: Function parameter or
member 'p_offset' not described in 'vmw_piter_start'
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c:676: warning: Function parameter or
member 'evict' not described in 'v
This set is part of a larger effort attempting to clean-up W=1
kernel builds, which are currently overwhelmingly riddled with
niggly little warnings.
Penultimate set, promise. :)
Lee Jones (40):
drm/r128/r128_ioc32: Document headers do not make good kernel-doc
candidates
drm/mga/mga_ioc32
On Wed, Jan 13, 2021 at 3:05 PM Pavel Tatashin
wrote:
>
> > > > Oh, that existing logic is wrong too :( Another bug.
> > >
> > > I do not think there is a bug.
> > >
> > > > You can't skip pages in the pages[] array under the assumption they
> > > > are contiguous. ie the i+=step is wrong.
> > >
>
On Tue, Dec 15, 2020, Uros Bizjak wrote:
> This patch series introduces try_cmpxchg64() atomic locking function.
>
> try_cmpxchg64() provides the same interface for 64 bit and 32 bit targets,
> emits CMPXCHGQ for 64 bit targets and CMPXCHG8B for 32 bit targets,
> and provides appropriate fallbacks
Hello Drew,
On Wed, 1 Jul 2020 03:33:20 +0200
Drew Fustini wrote:
> Increase #pinctrl-cells to 2 so that mux and conf be kept separate. This
> requires the AM33XX_PADCONF macro in omap.h to also be modified to keep pin
> conf and pin mux values separate.
>
> Signed-off-by: Drew Fustini
> -
On Fri, Jan 15, 2021 at 6:59 PM Catalin Marinas wrote:
>
> On Fri, Jan 15, 2021 at 06:41:53PM +0100, Andrey Konovalov wrote:
> > As of the "arm64: expose FAR_EL1 tag bits in siginfo" patch, the address
> > that is passed to report_tag_fault has pointer tags in the format of 0x0X,
> > while KASAN u
On 1/14/21 5:34 PM, Nava kishore Manne wrote:
> This patch Adds compatible value for Xilinx Dynamic Function eXchnage(DFX)
> AXI Shutdown manager IP.
A multi patch set should have a cover letter.
Use git format-patch --cover-letter
> Signed-off-by: Nava kishore Manne
> ---
> .../bindings/fpg
The following commit has been merged into the x86/platform branch of tip:
Commit-ID: ab20fda2a3da1b189a061ca045d9ca734e1db234
Gitweb:
https://git.kernel.org/tip/ab20fda2a3da1b189a061ca045d9ca734e1db234
Author:Linus Walleij
AuthorDate:Tue, 24 Nov 2020 09:53:38 +01:00
Commit
The following commit has been merged into the x86/platform branch of tip:
Commit-ID: 604303018221d00b58422e1d117ba29ce84295cb
Gitweb:
https://git.kernel.org/tip/604303018221d00b58422e1d117ba29ce84295cb
Author:Linus Walleij
AuthorDate:Tue, 24 Nov 2020 09:53:39 +01:00
Commit
The following commit has been merged into the x86/platform branch of tip:
Commit-ID: 3ff13602d7cae283bca1c52caacd0ca6426f37d2
Gitweb:
https://git.kernel.org/tip/3ff13602d7cae283bca1c52caacd0ca6426f37d2
Author:Linus Walleij
AuthorDate:Tue, 24 Nov 2020 09:53:37 +01:00
Commit
On Fri, 15 Jan 2021 17:26:42 +0800
Keqian Zhu wrote:
> If a group with non-pinned-page dirty scope is detached with dirty
> logging enabled, we should fully populate the dirty bitmaps at the
> time it's removed since we don't know the extent of its previous DMA,
> nor will the group be present to
On 1/15/21 5:41 PM, Andrey Konovalov wrote:
> As of the "arm64: expose FAR_EL1 tag bits in siginfo" patch, the address
> that is passed to report_tag_fault has pointer tags in the format of 0x0X,
> while KASAN uses 0xFX format (note the difference in the top 4 bits).
>
> Fix up the pointer tag
On Fri, Jan 15, 2021 at 06:41:53PM +0100, Andrey Konovalov wrote:
> As of the "arm64: expose FAR_EL1 tag bits in siginfo" patch, the address
> that is passed to report_tag_fault has pointer tags in the format of 0x0X,
> while KASAN uses 0xFX format (note the difference in the top 4 bits).
>
> Fix
The DE2 display engine hardware takes physical addresses that do not
need PHYS_BASE subtracted. As a result, they should not be present
on the mbus driver match list. Remove them.
This was tested on the A83T, along with the patch allowing the DMA
range map to be non-NULL and restores a working dis
A mechanism was recently introduced for the sunxi architecture where
the DMA offset for specific devices (under the MBUS) is set by a common
driver (sunxi_mbus). This driver calls dma_direct_set_offset to set
the device's dma_range_map manually.
However this information was overwritten by of_dma_c
On Fri, Jan 15, 2021, Xu, Like wrote:
> Hi Sean,
>
> Thanks for your comments !
>
> On 2021/1/15 3:10, Sean Christopherson wrote:
> > On Mon, Jan 04, 2021, Like Xu wrote:
> > > 2) Slow path (part 3, patch 0012-0017)
> > >
> > > This is when the host assigned physical PMC has a different index
>
On 12/23/20 7:14 AM, Zheng Yongjun wrote:
spinlock can be initialized automatically with DEFINE_SPINLOCK()
rather than explicitly calling spin_lock_init().
Signed-off-by: Zheng Yongjun
---
drivers/usb/usbip/stub_main.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/dr
Some KASAN tests require specific kernel configs to be enabled.
Instead of copy-pasting the checks for these configs add a few helper
macros and use them.
Link:
https://linux-review.googlesource.com/id/I237484a7fddfedf4a4aae9cc61ecbcdbe85a0a63
Suggested-by: Alexander Potapenko
Reviewed-by: Marco
Don't run KASAN tests when it's disabled with kasan.mode=off to avoid
corrupting kernel memory.
Link:
https://linux-review.googlesource.com/id/I6447af436a69a94bfc35477f6bf4e2122948355e
Reviewed-by: Marco Elver
Reviewed-by: Alexander Potapenko
Signed-off-by: Andrey Konovalov
---
lib/test_kasan
On a high level, this patch allows running KUnit KASAN tests with the
hardware tag-based KASAN mode.
Internally, this change reenables tag checking at the end of each KASAN
test that triggers a tag fault and leads to tag checking being disabled.
Also simplify is_write calculation in report_tag_fa
In the kmalloc_uaf2() test, the pointers to the two allocated memory
blocks might happen to be the same, and the test will fail. With the
software tag-based mode, the probability of the that is 1/254, so it's
hard to observe the failure. For the hardware tag-based mode though,
the probablity is 1/1
It might not be obvious to the compiler that the expression must be
executed between writing and reading to fail_data. In this case, the
compiler might reorder or optimize away some of the accesses, and
the tests will fail.
Add compiler barriers around the expression in KUNIT_EXPECT_KASAN_FAIL
and
Add a test for kmem_cache_alloc/free_bulk to make sure there are no
false-positives when these functions are used.
Link:
https://linux-review.googlesource.com/id/I2a8bf797aecf81baeac61380c567308f319e263d
Reviewed-by: Marco Elver
Reviewed-by: Alexander Potapenko
Signed-off-by: Andrey Konovalov
The currently existing kasan_check_read/write() annotations are intended
to be used for kernel modules that have KASAN compiler instrumentation
disabled. Thus, they are only relevant for the software KASAN modes that
rely on compiler instrumentation.
However there's another use case for these anno
The currently existing page allocator tests rely on kmalloc fallback
with large sizes that is only present for SLUB. Add proper tests that
use alloc/free_pages().
Link:
https://linux-review.googlesource.com/id/Ia173d5a1b215fe6b2548d814ef0f4433cf983570
Reviewed-by: Marco Elver
Reviewed-by: Alexan
Generic mm functions that call KASAN annotations that might report a bug
pass _RET_IP_ to them as an argument. This allows KASAN to include the
name of the function that called the mm function in its report's header.
Now that KASAN has inline wrappers for all of its annotations, move
_RET_IP_ to t
Since the hardware tag-based KASAN mode might not have a redzone that
comes after an allocated object (when kasan.mode=prod is enabled), the
kasan_bitops_tags() test ends up corrupting the next object in memory.
Change the test so it always accesses the redzone that lies within the
allocated objec
Rename CONFIG_TEST_KASAN_MODULE to CONFIG_KASAN_MODULE_TEST.
This naming is more consistent with the existing CONFIG_KASAN_KUNIT_TEST.
Link:
https://linux-review.googlesource.com/id/Id347dfa5fe8788b7a1a189863e039f409da0ae5f
Reviewed-by: Marco Elver
Reviewed-by: Alexander Potapenko
Signed-off-b
Add 3 new tests for tag-based KASAN modes:
1. Check that match-all pointer tag is not assigned randomly.
2. Check that 0xff works as a match-all pointer tag.
3. Check that there are no match-all memory tags.
Note, that test #3 causes a significant number (255) of KASAN reports
to be printed durin
Clarify and update comments in KASAN tests.
Link:
https://linux-review.googlesource.com/id/I6c816c51fa1e0eb7aa3dead6bda1f339d2af46c8
Reviewed-by: Marco Elver
Reviewed-by: Alexander Potapenko
Signed-off-by: Andrey Konovalov
---
lib/test_kasan.c| 59 +
Mention in the documentation that enabling CONFIG_KASAN_HW_TAGS
always results in in-kernel TBI (Top Byte Ignore) being enabled.
Also do a few minor documentation cleanups.
Link:
https://linux-review.googlesource.com/id/Iba2a6697e3c6304cb53f89ec61dedc77fa29e3ae
Reviewed-by: Marco Elver
Reviewed
There's a number of internal KASAN functions that are used across multiple
source code files and therefore aren't marked as static inline. To avoid
littering the kernel function names list with generic function names,
prefix all such KASAN functions with kasan_.
As a part of this change:
- Rename
This patchset adds support for running KASAN-KUnit tests with the
hardware tag-based mode and also contains a few fixes.
Changes v3->v4:
- Fix using tabs instead of spaces in bulk tests.
- Simplify is_write calculation in report_tag_fault().
- Add a comment about tests to report_tag_fault().
Andr
Add the compatible strings for the USB2 PHYs found on QCOM
SM8250 & SM8350 SoCs.
Note that the SM8250 compatible is already in use in the dts and
driver implementation but was missing from the documentation.
Signed-off-by: Jack Pham
---
.../devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml
Add support for the USB DP & UNI PHYs found on SM8350. These use
version 5.0.0 of the QMP PHY IP and thus require new "V5"
definitions of the register offset macros for the QSERDES RX
and TX blocks. The QSERDES common and QPHY PCS blocks' register
offsets are largely unchanged from V4 so some of th
Add compatible strings for the USB DWC3 controller on QCOM SM8150,
SM8250 and SM8350 SoCs.
Note the SM8150 & SM8250 compatibles are already being used in the
dts but was missing from the documentation.
Signed-off-by: Jack Pham
---
Documentation/devicetree/bindings/usb/qcom,dwc3.yaml | 3 +++
1
On 1/15/21 2:16 AM, Oscar Salvador wrote:
> On Mon, Jan 11, 2021 at 01:01:52PM -0800, Mike Kravetz wrote:
>> Use new hugetlb specific flag HPageTempSurplus to replace the
>> PageHugeTemporary() interfaces.
>>
>> Signed-off-by: Mike Kravetz
>> ---
>> mm/hugetlb.c | 38 +
Add the compatible strings for the USB3 PHYs found on SM8150, SM8250
and SM8350 SoCs. These require separate subschemas due to the different
required clock entries.
Note the SM8150 and SM8250 compatibles have already been in place in
the dts as well as the driver implementation but were missing fr
This series adds support for the SM8350 USB PHY to the QMP PHY driver
as well as adds the documentation for the QMP, SNPS PHY and DWC3
controller bindings. This also adds the bindings for SM8150 and SM8250
to the same docs which had not been added previously even though they
are in use now.
v2: Re
Am 15/01/2021 um 17:52 schrieb Jonathan Corbet:
> On Fri, 15 Jan 2021 07:57:51 +0100
> Lukas Bulwahn wrote:
>
>> Pia Eichinger has done some related analysis and work in this area as
>> part of her bachelor's thesis on Maintainers Expectations vs.
>> Maintainers Reality: An Analysis of Organis
On 1/14/21 11:16 AM, Bhaumik Bhatt wrote:
When moving from SBL to mission mode execution environment, there
is no remove callback notification to MHI client drivers which
operate on SBL mode only. Client driver devices are being created
in SBL or AMSS(mission mode) and only destroyed after pow
On Fri, Jan 15, 2021 at 8:13 AM Jon Hunter wrote:
>
>
> On 14/01/2021 21:50, Saravana Kannan wrote:
> > On Thu, Jan 14, 2021 at 10:55 AM Jon Hunter wrote:
> >>
> >>
> >> On 14/01/2021 16:52, Saravana Kannan wrote:
> >>
> >> ...
> >>
> >>> Thanks! I think you forgot to enable those logs though. Al
On 1/15/21 1:17 AM, Oscar Salvador wrote:
> On Mon, Jan 11, 2021 at 01:01:51PM -0800, Mike Kravetz wrote:
>> Use the new hugetlb page specific flag to replace the page_huge_active
>> interfaces. By it's name, page_huge_active implied that a huge page
>> was on the active list. However, that is no
On Fri, Jan 15, 2021, Xu, Like wrote:
> On 2021/1/15 2:55, Sean Christopherson wrote:
> > On Mon, Jan 04, 2021, Like Xu wrote:
> > > + * Note: KVM disables the co-existence of guest PEBS and host PEBS.
> > By "KVM", do you mean KVM's loading of the MSRs provided by
> > intel_guest_get_msrs()?
> >
As of the "arm64: expose FAR_EL1 tag bits in siginfo" patch, the address
that is passed to report_tag_fault has pointer tags in the format of 0x0X,
while KASAN uses 0xFX format (note the difference in the top 4 bits).
Fix up the pointer tag for kernel pointers in do_tag_check_fault by
setting them
Changes v2->v3:
- Fix up kernel pointer tag in do_tag_check_fault() instead of
report_tag_fault().
Andrey Konovalov (2):
kasan, mm: fix conflicts with init_on_alloc/free
kasan, arm64: fix pointer tags in KASAN reports
arch/arm64/mm/fault.c | 7 ---
mm/slub.c | 7 ---
2
A few places where SLUB accesses object's data or metadata were missed in
a previous patch. This leads to false positives with hardware tag-based
KASAN when bulk allocations are used with init_on_alloc/free.
Fix the false-positives by resetting pointer tags during these accesses.
(The kasan_reset
On Fri, Jan 15, 2021 at 6:21 PM Saravana Kannan wrote:
>
> On Fri, Jan 15, 2021 at 5:03 AM Rafael J. Wysocki wrote:
> >
> > On Fri, Jan 15, 2021 at 11:03 AM Stephan Gerhold
> > wrote:
> > >
> > > Hi,
> > >
> > > On Thu, Jan 14, 2021 at 11:31:12AM -0800, Saravana Kannan wrote:
> > > > On Thu, Ja
On Fri, Jan 15, 2021 at 6:06 PM Catalin Marinas wrote:
>
> On Fri, Jan 15, 2021 at 06:00:36PM +0100, Andrey Konovalov wrote:
> > On Fri, Jan 15, 2021 at 5:56 PM Catalin Marinas
> > wrote:
> > >
> > > On Fri, Jan 15, 2021 at 05:30:40PM +0100, Andrey Konovalov wrote:
> > > > On Wed, Jan 13, 2021 a
On Thu, Dec 10, 2020 at 02:23:09AM +0800, John Garry wrote:
> Leizhen reported some time ago that IOVA performance may degrade over time
> [0], but unfortunately his solution to fix this problem was not given
> attention.
>
> To summarize, the issue is that as time goes by, the CPU rcache and depo
fdt_appendprop_addrrange() function adds a property, with the given name,
to the device tree at the given node offset, and also sets the address
and size of the property. This function should be used to add
"linux,ima-kexec-buffer" property to the device tree and set the address
and size of the IM
create_dtb() function allocates kernel virtual memory for
the device tree blob (DTB). This is not consistent with other
architectures, such as powerpc, which calls kmalloc() for allocating
memory for the DTB.
Call kmalloc() to allocate memory for the DTB, and kfree() to free
the allocated memory.
arch_ima_add_kexec_buffer() defined in "arch/powerpc/kexec/ima.c"
sets up the address and size of the IMA measurement list in
the architecture specific fields in kimage struct. This function does not
have architecture specific code, but is currently limited to powerpc.
Move arch_ima_add_kexec_buf
The functions defined in "arch/powerpc/kexec/ima.c" handle setting up
and freeing the resources required to carry over the IMA measurement
list from the current kernel to the next kernel across kexec system call.
These functions do not have architecture specific code, but are
currently limited to p
On kexec file load Integrity Measurement Architecture (IMA) subsystem
may verify the IMA signature of the kernel and initramfs, and measure
it. The command line parameters passed to the kernel in the kexec call
may also be measured by IMA. A remote attestation service can verify
a TPM quote based
Address and size of the buffer containing the IMA measurement log need
to be passed from the current kernel to the next kernel on kexec.
Add address and size fields to "struct kimage_arch" for ARM64 platform
to hold the address and size of the IMA measurement log buffer.
Update CONFIG_KEXEC_FILE
From: Rob Herring
Both arm64 and powerpc do essentially the same FDT /chosen setup for
kexec. The differences are either omissions that arm64 should have
or additional properties that will be ignored. The setup code can be
combined and shared by both powerpc and arm64.
The differences relative
delete_fdt_mem_rsv() defined in "arch/powerpc/kexec/file_load.c"
has been renamed to fdt_find_and_del_mem_rsv(), and moved to
"drivers/of/kexec.c".
Remove delete_fdt_mem_rsv() in "arch/powerpc/kexec/file_load.c".
Co-developed-by: Prakhar Srivastava
Signed-off-by: Prakhar Srivastava
Signed-off-b
On Fri, Jan 15, 2021, Like Xu wrote:
> Ping ?
>
> On 2020/12/30 16:19, Like Xu wrote:
> > The HW_REF_CPU_CYCLES event on the fixed counter 2 is pseudo-encoded as
> > 0x0300 in the intel_perfmon_event_map[]. Correct its usage.
> >
> > Fixes: 62079d8a4312 ("KVM: PMU: add proper support for fixed co
From: Rob Herring
The code for setting up the /chosen node in the device tree
and updating the memory reservation for the next kernel has been
moved to of_kexec_setup_new_fdt() defined in "drivers/of/kexec.c".
Use the common of_kexec_setup_new_fdt() to setup the device tree
and update the memory
From: Rob Herring
The code for setting up the /chosen node in the device tree
and updating the memory reservation for the next kernel has been
moved to of_kexec_setup_new_fdt() defined in "drivers/of/kexec.c".
Use the common of_kexec_setup_new_fdt() to setup the device tree
and update the memory
From: Rob Herring
The architecture specific field, elfcorehdr_addr in struct kimage_arch,
that holds the address of the buffer in memory for ELF core header for
powerpc has a different name than the one used for arm64. This makes
it hard to have a common code for setting up the device tree for
k
On Fri, 15 Jan 2021 11:45:44 +, Quentin Perret wrote:
> From: Nicolas Boichat
>
> If the device tree is incorrectly configured, and attempts to
> define a "no-map" reserved memory that overlaps with the kernel
> data/code, the kernel would crash quickly after boot, with no
> obvious clue abou
From: Yingjie Wang
In rvu_mbox_handler_cgx_mac_addr_get()
and rvu_mbox_handler_cgx_mac_addr_set(),
the msg is expected only from PFs that are mapped to CGX LMACs.
It should be checked before mapping,
so we add the is_cgx_config_permitted() in the functions.
Fixes: 96be2e0da85e ("octeontx2-af: Su
Hi Liu Ying,
I promised I would have a second, more in-depth, look at this and I finally
managed to do it.
I have to admit it was a challenge. Partially because I'm not very familiar
with DPU but mostly because of the abundance of macros used. It's true, macros
make the code more compact. However
On Thu, Dec 10, 2020 at 02:23:08AM +0800, John Garry wrote:
> A similar crash to the following could be observed if initial CPU rcache
> magazine allocations fail in init_iova_rcaches():
Any idea why that's happening? This fix seems ok but if we're expecting
allocation failures for the loaded mag
On Fri, 15 Jan 2021 11:45:43 +, Quentin Perret wrote:
> From: KarimAllah Ahmed
>
> Mark the memory region with NOMAP flag instead of completely removing it
> from the memory blocks. That makes the FDT handling consistent with the EFI
> memory map handling.
>
> Cc: Rob Herring
> Cc: Frank Ro
On Thu, Dec 10, 2020 at 02:23:07AM +0800, John Garry wrote:
> Add a helper function to free the CPU rcache for all online CPUs.
>
> There also exists a function of the same name in
> drivers/iommu/intel/iommu.c, but the parameters are different, and there
> should be no conflict.
>
> Signed-off-b
501 - 600 of 1585 matches
Mail list logo
