* Re: [GIT PULL] sh: remove sh5 support
From: Christoph Hellwig @ 2020-05-29 18:22 UTC (permalink / raw)
To: Rich Felker
Cc: Christoph Hellwig, Arnd Bergmann, linux-sh, ysato, linux-kernel,
viro, Rob Landley, Geert Uytterhoeven, Linus Torvalds
In-Reply-To: <20200529175335.GK1079@brightrain.aerifal.cx>
On Fri, May 29, 2020 at 01:53:38PM -0400, Rich Felker wrote:
> Frustratingly, I _still_ don't have an official tree on kernel.org for
> the purpose of being the canonical place for linux-next to pull from,
> due to policies around pgp keys and nobody following up on signing
> mine. This is all really silly since there are ridiculously many
> independent channels I could cryptographically validate identity
> through with vanishing probability that they're all compromised. For
> the time being I'll reactivate my repo on git.musl-libc.org.
You don't need a kernel.org tree. None of the trees I maintain are
hosted on kernel.org. Just make sure you sign your tags.
^ permalink raw reply
* + mm-ptdump-expand-type-of-val-in-note_page-fix.patch added to -mm tree
From: akpm @ 2020-05-29 18:22 UTC (permalink / raw)
To: akpm, bp, dave.hansen, jbeulich, lkp, luto, mingo, mm-commits,
peterz, steven.price, tglx
The patch titled
Subject: mm-ptdump-expand-type-of-val-in-note_page-fix
has been added to the -mm tree. Its filename is
mm-ptdump-expand-type-of-val-in-note_page-fix.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-ptdump-expand-type-of-val-in-note_page-fix.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-ptdump-expand-type-of-val-in-note_page-fix.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Andrew Morton <akpm@linux-foundation.org>
Subject: mm-ptdump-expand-type-of-val-in-note_page-fix
fix riscv
Reported-by: kbuild test robot <lkp@intel.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Price <steven.price@arm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
arch/riscv/mm/ptdump.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/riscv/mm/ptdump.c~mm-ptdump-expand-type-of-val-in-note_page-fix
+++ a/arch/riscv/mm/ptdump.c
@@ -204,7 +204,7 @@ static void note_prot_wx(struct pg_state
}
static void note_page(struct ptdump_state *pt_st, unsigned long addr,
- int level, unsigned long val)
+ int level, u64 val)
{
struct pg_state *st = container_of(pt_st, struct pg_state, ptdump);
u64 pa = PFN_PHYS(pte_pfn(__pte(val)));
_
Patches currently in -mm which might be from akpm@linux-foundation.org are
mm-ptdump-expand-type-of-val-in-note_page-fix.patch
squashfs-migrate-from-ll_rw_block-usage-to-bio-fix.patch
arch-parisc-include-asm-pgtableh-remove-unused-old_pte.patch
drivers-tty-serial-sh-scic-suppress-uninitialized-var-warning.patch
mm.patch
mm-slub-fix-corrupted-freechain-in-deactivate_slab-fix.patch
mm-slub-add-panic_on_error-to-the-debug-facilities-fix.patch
mm-migratec-call-detach_page_private-to-cleanup-code-fix.patch
mm-migratec-call-detach_page_private-to-cleanup-code-fix-fix.patch
mm-gupc-updating-the-documentation-fix.patch
mm-swapfilec-classify-swap_map_xxx-to-make-it-more-readable-fix.patch
mm-remove-__vmalloc_node_flags_caller-fix.patch
mm-switch-the-test_vmalloc-module-to-use-__vmalloc_node-fix.patch
mm-switch-the-test_vmalloc-module-to-use-__vmalloc_node-fix-fix.patch
mm-remove-vmalloc_user_node_flags-fix.patch
mm-vmalloc-track-which-page-table-levels-were-modified-fix.patch
mm-free_area_init-allow-defining-max_zone_pfn-in-descending-order-fix-2-fix.patch
mm-page_alloc-skip-waternark_boost-for-atomic-order-0-allocations-fix.patch
arch-kunmap-remove-duplicate-kunmap-implementations-fix.patch
arch-kmap_atomic-consolidate-duplicate-code-checkpatch-fixes.patch
arch-kunmap_atomic-consolidate-duplicate-code-checkpatch-fixes.patch
kmap-consolidate-kmap_prot-definitions-checkpatch-fixes.patch
mm-add-debug_wx-support-fix.patch
riscv-support-debug_wx-fix.patch
mm-replace-zero-length-array-with-flexible-array-member-fix.patch
mm-hugetlb-fix-a-typo-in-comment-manitained-maintained-v2-checkpatch-fixes.patch
seq_file-introduce-define_seq_attribute-helper-macro-checkpatch-fixes.patch
ipc-convert-ipcs_idr-to-xarray-update-fix.patch
linux-next-pre.patch
linux-next-rejects.patch
linux-next-post.patch
kernel-add-panic_on_taint-fix.patch
mm-consolidate-pgd_index-and-pgd_offset_k-definitions-fix.patch
mmap-locking-api-convert-mmap_sem-call-sites-missed-by-coccinelle-fix.patch
mmap-locking-api-convert-mmap_sem-call-sites-missed-by-coccinelle-fix-fix.patch
mmap-locking-api-convert-mmap_sem-call-sites-missed-by-coccinelle-fix-fix-fix.patch
mmap-locking-api-rename-mmap_sem-to-mmap_lock-fix.patch
mmap-locking-api-convert-mmap_sem-comments-fix.patch
mmap-locking-api-convert-mmap_sem-comments-fix-fix.patch
mmap-locking-api-convert-mmap_sem-comments-fix-fix-fix.patch
mm-pass-task-and-mm-to-do_madvise.patch
mm-introduce-external-memory-hinting-api-fix-2-fix.patch
mm-support-vector-address-ranges-for-process_madvise-fix-fix-fix-fix-fix.patch
maccess-unify-the-probe-kernel-arch-hooks-fix.patch
bpf-bpf_seq_printf-handle-potentially-unsafe-format-string-better.patch
maccess-always-use-strict-semantics-for-probe_kernel_read-fix.patch
x86-use-non-set_fs-based-maccess-routines-checkpatch-fixes.patch
doc-cgroup-update-note-about-conditions-when-oom-killer-is-invoked-fix.patch
kernel-forkc-export-kernel_thread-to-modules.patch
^ permalink raw reply
* Re: [GIT PULL] sh: remove sh5 support
From: Christoph Hellwig @ 2020-05-29 18:22 UTC (permalink / raw)
To: Rich Felker
Cc: Christoph Hellwig, Arnd Bergmann, linux-sh, ysato, linux-kernel,
viro, Rob Landley, Geert Uytterhoeven, Linus Torvalds
In-Reply-To: <20200529175335.GK1079@brightrain.aerifal.cx>
On Fri, May 29, 2020 at 01:53:38PM -0400, Rich Felker wrote:
> Frustratingly, I _still_ don't have an official tree on kernel.org for
> the purpose of being the canonical place for linux-next to pull from,
> due to policies around pgp keys and nobody following up on signing
> mine. This is all really silly since there are ridiculously many
> independent channels I could cryptographically validate identity
> through with vanishing probability that they're all compromised. For
> the time being I'll reactivate my repo on git.musl-libc.org.
You don't need a kernel.org tree. None of the trees I maintain are
hosted on kernel.org. Just make sure you sign your tags.
^ permalink raw reply
* Re: [linux-next:master 11894/13554] arch/riscv/mm/ptdump.c:255:17: error: initialization of 'void (*)(struct ptdump_state *, long unsigned int, int, u64)' {aka 'void (*)(struct ptdump_state *, long unsigned int, int, long long unsigned int)'} from incompatible pointer type 'void (*)(struct ptdump_state *, long unsigned int, int, long unsigned int)'
From: Andrew Morton @ 2020-05-29 18:22 UTC (permalink / raw)
To: kbuild test robot
Cc: Steven, Price,, kbuild-all, Linux Memory Management List
In-Reply-To: <202005300054.IITfkKUU%lkp@intel.com>
On Sat, 30 May 2020 00:14:57 +0800 kbuild test robot <lkp@intel.com> wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> head: ff387fc20c697cdc887b2abf7ef494e853795a2f
> commit: f6396a9ececda3fa26571ccd38167373db1d2ec3 [11894/13554] mm: ptdump: expand type of 'val' in note_page()
> config: riscv-allyesconfig (attached as .config)
> compiler: riscv64-linux-gcc (GCC) 9.3.0
> reproduce (this is a W=1 build):
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout f6396a9ececda3fa26571ccd38167373db1d2ec3
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=riscv
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kbuild test robot <lkp@intel.com>
>
> All errors (new ones prefixed by >>, old ones prefixed by <<):
>
> arch/riscv/mm/ptdump.c: In function 'ptdump_walk':
> >> arch/riscv/mm/ptdump.c:255:17: error: initialization of 'void (*)(struct ptdump_state *, long unsigned int, int, u64)' {aka 'void (*)(struct ptdump_state *, long unsigned int, int, long long unsigned int)'} from incompatible pointer type 'void (*)(struct ptdump_state *, long unsigned int, int, long unsigned int)' [-Werror=incompatible-pointer-types]
> 255 | .note_page = note_page,
Thanks.
--- a/arch/riscv/mm/ptdump.c~mm-ptdump-expand-type-of-val-in-note_page-fix
+++ a/arch/riscv/mm/ptdump.c
@@ -204,7 +204,7 @@ static void note_prot_wx(struct pg_state
}
static void note_page(struct ptdump_state *pt_st, unsigned long addr,
- int level, unsigned long val)
+ int level, u64 val)
{
struct pg_state *st = container_of(pt_st, struct pg_state, ptdump);
u64 pa = PFN_PHYS(pte_pfn(__pte(val)));
_
^ permalink raw reply
* Re: [linux-next:master 11894/13554] arch/riscv/mm/ptdump.c:255:17: error: initialization of 'void (*)(struct ptdump_state *, long unsigned int, int, u64)' {aka 'void (*)(struct ptdump_state *, long unsigned int, int, long long unsigned int)'} from incompatible pointer type 'void (*)(struct ptdump_state *, long unsigned int, int, long unsigned int)'
From: Andrew Morton @ 2020-05-29 18:22 UTC (permalink / raw)
To: kbuild-all
In-Reply-To: <202005300054.IITfkKUU%lkp@intel.com>
[-- Attachment #1: Type: text/plain, Size: 1916 bytes --]
On Sat, 30 May 2020 00:14:57 +0800 kbuild test robot <lkp@intel.com> wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> head: ff387fc20c697cdc887b2abf7ef494e853795a2f
> commit: f6396a9ececda3fa26571ccd38167373db1d2ec3 [11894/13554] mm: ptdump: expand type of 'val' in note_page()
> config: riscv-allyesconfig (attached as .config)
> compiler: riscv64-linux-gcc (GCC) 9.3.0
> reproduce (this is a W=1 build):
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout f6396a9ececda3fa26571ccd38167373db1d2ec3
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=riscv
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kbuild test robot <lkp@intel.com>
>
> All errors (new ones prefixed by >>, old ones prefixed by <<):
>
> arch/riscv/mm/ptdump.c: In function 'ptdump_walk':
> >> arch/riscv/mm/ptdump.c:255:17: error: initialization of 'void (*)(struct ptdump_state *, long unsigned int, int, u64)' {aka 'void (*)(struct ptdump_state *, long unsigned int, int, long long unsigned int)'} from incompatible pointer type 'void (*)(struct ptdump_state *, long unsigned int, int, long unsigned int)' [-Werror=incompatible-pointer-types]
> 255 | .note_page = note_page,
Thanks.
--- a/arch/riscv/mm/ptdump.c~mm-ptdump-expand-type-of-val-in-note_page-fix
+++ a/arch/riscv/mm/ptdump.c
@@ -204,7 +204,7 @@ static void note_prot_wx(struct pg_state
}
static void note_page(struct ptdump_state *pt_st, unsigned long addr,
- int level, unsigned long val)
+ int level, u64 val)
{
struct pg_state *st = container_of(pt_st, struct pg_state, ptdump);
u64 pa = PFN_PHYS(pte_pfn(__pte(val)));
_
^ permalink raw reply
* [dunfell/master][PATCH] ti-sci-fw: update to 2020.04a and 07.00.00.004 tag
From: Denys Dmytriyenko @ 2020-05-29 18:21 UTC (permalink / raw)
To: meta-ti; +Cc: Denys Dmytriyenko
From: Denys Dmytriyenko <denys@ti.com>
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
---
.../{ti-sci-fw-source_2020.04.bb => ti-sci-fw-source_2020.04a.bb} | 0
recipes-bsp/ti-sci-fw/{ti-sci-fw_2020.04.bb => ti-sci-fw_2020.04a.bb} | 0
.../ti-sci-fw/{ti-sci-fw_2020.04.inc => ti-sci-fw_2020.04a.inc} | 4 ++--
3 files changed, 2 insertions(+), 2 deletions(-)
rename recipes-bsp/ti-sci-fw/{ti-sci-fw-source_2020.04.bb => ti-sci-fw-source_2020.04a.bb} (100%)
rename recipes-bsp/ti-sci-fw/{ti-sci-fw_2020.04.bb => ti-sci-fw_2020.04a.bb} (100%)
rename recipes-bsp/ti-sci-fw/{ti-sci-fw_2020.04.inc => ti-sci-fw_2020.04a.inc} (79%)
diff --git a/recipes-bsp/ti-sci-fw/ti-sci-fw-source_2020.04.bb b/recipes-bsp/ti-sci-fw/ti-sci-fw-source_2020.04a.bb
similarity index 100%
rename from recipes-bsp/ti-sci-fw/ti-sci-fw-source_2020.04.bb
rename to recipes-bsp/ti-sci-fw/ti-sci-fw-source_2020.04a.bb
diff --git a/recipes-bsp/ti-sci-fw/ti-sci-fw_2020.04.bb b/recipes-bsp/ti-sci-fw/ti-sci-fw_2020.04a.bb
similarity index 100%
rename from recipes-bsp/ti-sci-fw/ti-sci-fw_2020.04.bb
rename to recipes-bsp/ti-sci-fw/ti-sci-fw_2020.04a.bb
diff --git a/recipes-bsp/ti-sci-fw/ti-sci-fw_2020.04.inc b/recipes-bsp/ti-sci-fw/ti-sci-fw_2020.04a.inc
similarity index 79%
rename from recipes-bsp/ti-sci-fw/ti-sci-fw_2020.04.inc
rename to recipes-bsp/ti-sci-fw/ti-sci-fw_2020.04a.inc
index 429d077..e785ce0 100644
--- a/recipes-bsp/ti-sci-fw/ti-sci-fw_2020.04.inc
+++ b/recipes-bsp/ti-sci-fw/ti-sci-fw_2020.04a.inc
@@ -3,9 +3,9 @@ SUMMARY = "TI SCI firmware (SYSFW)"
LICENSE = "TI-TFL"
LIC_FILES_CHKSUM = "file://LICENSE.ti;md5=b5aebf0668bdf95621259288c4a46d76"
-SRCREV = "6b02b1ea07da65a68444e86439ad5b031e9fd5a2"
+SRCREV = "c8decf64be551dfd1244cd1d231a97eb2255fb80"
BRANCH ?= "ti-linux-firmware"
-SRCREV_imggen = "a7d3909ed8ae23a7c90f7ef821713a8b0c3c061d"
+SRCREV_imggen = "d9a550b91ec95d06a80f2ccc6dd829815ba35d88"
SRCREV_FORMAT = "imggen"
SRC_URI = " \
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 1/2] arm64: dts: Add a device tree for the Librem5 phone
From: Martin Kepplinger @ 2020-05-29 18:20 UTC (permalink / raw)
To: Pavel Machek
Cc: robh, kernel, Anson.Huang, devicetree, shawnguo, s.hauer, angus,
linux-kernel, linux-imx, kernel, mchehab, festevam, agx,
linux-arm-kernel
In-Reply-To: <20200529180743.GA1081@bug>
On 29.05.20 20:07, Pavel Machek wrote:
> Hi!
>
> Plus, do we need calibration matrix for magnetometer?
I guess so. It's not a calibration matrix, it's the mount matrix that
tells you how the chip is placed on the PCB relative to a "natural"
orientation, see
https://github.com/torvalds/linux/blob/master/Documentation/ABI/testing/sysfs-bus-iio#L1638
>
> Best regards,
> Pavel
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* master - integrity: skip calling add when removing images
From: David Teigland @ 2020-05-29 18:21 UTC (permalink / raw)
To: lvm-devel
Gitweb: https://sourceware.org/git/?p=lvm2.git;a=commitdiff;h=ae029fcced5f79af748df28f20f952d158804482
Commit: ae029fcced5f79af748df28f20f952d158804482
Parent: 7b04ed07ba2e68f527ebb4f8d2b2bd092692f2d2
Author: David Teigland <teigland@redhat.com>
AuthorDate: Fri May 29 13:18:24 2020 -0500
Committer: David Teigland <teigland@redhat.com>
CommitterDate: Fri May 29 13:18:24 2020 -0500
integrity: skip calling add when removing images
When lvconvert is used to remove raid images, we can
skip calling lv_add_integrity_to_raid(), which finds
nothing to do, but the the blocksize validation would
be called unnecessarily and trigger spurious errors.
---
tools/lvconvert.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/tools/lvconvert.c b/tools/lvconvert.c
index 8652252d3..76e00f0a2 100644
--- a/tools/lvconvert.c
+++ b/tools/lvconvert.c
@@ -1319,6 +1319,7 @@ static int _raid4_conversion_supported(struct logical_volume *lv, struct lvconve
static int _lvconvert_raid(struct logical_volume *lv, struct lvconvert_params *lp)
{
int image_count = 0;
+ int images_reduced = 0;
struct cmd_context *cmd = lv->vg->cmd;
struct lv_segment *seg = first_seg(lv);
@@ -1357,6 +1358,8 @@ static int _lvconvert_raid(struct logical_volume *lv, struct lvconvert_params *l
else
image_count = lp->mirrors + 1;
+ images_reduced = (image_count < lv_raid_image_count(lv));
+
if (image_count < 1) {
log_error("Unable to %s images by specified amount.",
lp->keep_mimages ? "split" : "reduce");
@@ -1400,7 +1403,7 @@ static int _lvconvert_raid(struct logical_volume *lv, struct lvconvert_params *l
lp->region_size : seg->region_size , lp->pvh))
return_0;
- if (lv_raid_has_integrity(lv)) {
+ if (lv_raid_has_integrity(lv) && !images_reduced) {
struct integrity_settings *isettings = NULL;
if (!lv_get_raid_integrity_settings(lv, &isettings))
return_0;
^ permalink raw reply related
* Re: [PATCH] usb: dwc2: Fix shutdown callback in platform
From: Frank Mori Hess @ 2020-05-29 18:21 UTC (permalink / raw)
To: Doug Anderson
Cc: Minas Harutyunyan, John Youn, Felipe Balbi, Greg Kroah-Hartman,
linux-usb@vger.kernel.org, # 4.0+
In-Reply-To: <CAD=FV=URUeE55xyL3iB5GmS7BRoDG2ey3UE4qSwwc7XZHR0c-Q@mail.gmail.com>
On Fri, May 29, 2020 at 1:53 PM Doug Anderson <dianders@chromium.org> wrote:
> >
> > I don't get it. A hypothetical machine could have literally anything
> > sharing the IRQ line, right?
>
> It's not a real physical line, though? I don't think it's common to
> have a shared interrupt between different IP blocks in a given SoC.
> Even if it existed, all the drivers should disable their interrupts?
I don't know, it's a hypothetical machine so it can be whatever you
want. The driver requests shared irqs, if it doesn't actually support
irq sharing, it shouldn't request them.
> > Anyways, my screaming interrupt occurs after a a new kernel has been
> > booted with kexec. In this case, it doesn't matter if the old kernel
> > called disable_irq or not. As soon as the new kernel re-enables the
> > interrupt line, the kernel immediately disables it again with a
> > backtrace due to the unhandled screaming interrupt. That's why the
> > dwc2 hardware needs to have its interrupts turned off when the old
> > kernel is shutdown.
>
> Isn't that a bug with your new kernel? I've seen plenty of bugs where
> drivers enable their interrupt before their interrupt handler is set
> to handle it. You never know what state the bootloader (or previous
> kernel) might have left things in and if an interrupt was pending it
> shouldn't kill you.
It wouldn't hurt to add disabling of the dwc2 irq early in dwc2
initialization, but why leave the irq screaming after shutdown? If
there is another device using the same irq, it will generate unhandled
interrupt backtraces and get its irq disabled when the new kernel
requests its irq, if the device's driver is loaded before the dwc2
driver (assuming the new kernel even has a dwc2 driver). The dwc2
driver in its current state will generate unhandled interrupt
backtraces by itself until it registers the right handler.
--
Frank
^ permalink raw reply
* Re: Sd_bus_call - ELOOP Issue
From: Vernon Mauery @ 2020-05-29 18:21 UTC (permalink / raw)
To: Patrick Williams
Cc: Kumar Thangavel, openbmc, tomjose, anoo, dkodihal, ratagupt,
Brad Bishop, Vijay Khemka, Sai Dasari
In-Reply-To: <20200529180709.GH17541@heinlein>
On 29-May-2020 01:07 PM, Patrick Williams wrote:
>On Fri, May 29, 2020 at 09:29:48PM +0530, Kumar Thangavel wrote:
>
>> 6. As per our understanding, current sd_bus_call not supported for
>> connection with the same bus/clients. (sender and receiver are same
>> application name ). Please confirm.
>>
>> Log :
>> yosemitev2 ipmid[370]: sd_bus_call function called..
>> yosemitev2 ipmid[370]: sd_bus_call function ELOOP .
>> yosemitev2 ipmid[370]: unique name = :1.71
>> yosemitev2 ipmid[370]: incoming sender = :1.71
>> yosemitev2 ipmid[370]: executeCallback called. catch block
>> yosemitev2 ipmid[370]: EXCEPTION=sd_bus_call:
>> System.Error.ELOOP: Too many levels of symbolic links
>
>Yes, it appears that systemd has some code to specifically return ELOOP
>in this case:
>
>https://github.com/systemd/systemd/blob/master/src/libsystemd/sd-bus/sd-bus.c#L2236
>
>>
>> So, Could you please confirm sd_bus_call does not support the same
>> bus/clients with in the same process.
>>
>> Also, Please let us know if any alternate method to call the
>> execute dbus method with the same bus/connection.
>
>My suggestion would be to see if one of the functions in ipmid-new.cpp,
>such as executeIpmiCommand, can be exposed to providers for these kind
>of recursive callbacks.
>
>Maintainers of phosphor-host-ipmid have opinions here?
ipmid hosts a very small set of D-Bus objects/interfaces. I don't know
of any standard commands that would call back to itself though. There is
some context I seem to be missing here.
--Vernon
^ permalink raw reply
* Re: [PATCH 1/2] arm64: dts: Add a device tree for the Librem5 phone
From: Martin Kepplinger @ 2020-05-29 18:20 UTC (permalink / raw)
To: Pavel Machek
Cc: robh, kernel, shawnguo, s.hauer, kernel, festevam, linux-imx,
mchehab, Anson.Huang, agx, angus, linux-kernel, devicetree,
linux-arm-kernel
In-Reply-To: <20200529180743.GA1081@bug>
On 29.05.20 20:07, Pavel Machek wrote:
> Hi!
>
> Plus, do we need calibration matrix for magnetometer?
I guess so. It's not a calibration matrix, it's the mount matrix that
tells you how the chip is placed on the PCB relative to a "natural"
orientation, see
https://github.com/torvalds/linux/blob/master/Documentation/ABI/testing/sysfs-bus-iio#L1638
>
> Best regards,
> Pavel
>
^ permalink raw reply
* [PATCH v2 net] l2tp: do not use inet_hash()/inet_unhash()
From: Eric Dumazet @ 2020-05-29 18:20 UTC (permalink / raw)
To: David S . Miller
Cc: netdev, Eric Dumazet, Eric Dumazet, James Chapman,
Andrii Nakryiko, syzbot+3610d489778b57cc8031
syzbot recently found a way to crash the kernel [1]
Issue here is that inet_hash() & inet_unhash() are currently
only meant to be used by TCP & DCCP, since only these protocols
provide the needed hashinfo pointer.
L2TP uses a single list (instead of a hash table)
This old bug became an issue after commit 610236587600
("bpf: Add new cgroup attach type to enable sock modifications")
since after this commit, sk_common_release() can be called
while the L2TP socket is still considered 'hashed'.
general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
CPU: 0 PID: 7063 Comm: syz-executor654 Not tainted 5.7.0-rc6-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:inet_unhash+0x11f/0x770 net/ipv4/inet_hashtables.c:600
Code: 03 0f b6 04 02 84 c0 74 08 3c 03 0f 8e dd 04 00 00 48 8d 7d 08 44 8b 73 08 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 55 05 00 00 48 8d 7d 14 4c 8b 6d 08 48 b8 00 00
RSP: 0018:ffffc90001777d30 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: ffff88809a6df940 RCX: ffffffff8697c242
RDX: 0000000000000001 RSI: ffffffff8697c251 RDI: 0000000000000008
RBP: 0000000000000000 R08: ffff88809f3ae1c0 R09: fffffbfff1514cc1
R10: ffffffff8a8a6607 R11: fffffbfff1514cc0 R12: ffff88809a6df9b0
R13: 0000000000000007 R14: 0000000000000000 R15: ffffffff873a4d00
FS: 0000000001d2b880(0000) GS:ffff8880ae600000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000006cd090 CR3: 000000009403a000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
sk_common_release+0xba/0x370 net/core/sock.c:3210
inet_create net/ipv4/af_inet.c:390 [inline]
inet_create+0x966/0xe00 net/ipv4/af_inet.c:248
__sock_create+0x3cb/0x730 net/socket.c:1428
sock_create net/socket.c:1479 [inline]
__sys_socket+0xef/0x200 net/socket.c:1521
__do_sys_socket net/socket.c:1530 [inline]
__se_sys_socket net/socket.c:1528 [inline]
__x64_sys_socket+0x6f/0xb0 net/socket.c:1528
do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295
entry_SYSCALL_64_after_hwframe+0x49/0xb3
RIP: 0033:0x441e29
Code: e8 fc b3 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 eb 08 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007ffdce184148 EFLAGS: 00000246 ORIG_RAX: 0000000000000029
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000441e29
RDX: 0000000000000073 RSI: 0000000000000002 RDI: 0000000000000002
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000402c30 R14: 0000000000000000 R15: 0000000000000000
Modules linked in:
---[ end trace 23b6578228ce553e ]---
RIP: 0010:inet_unhash+0x11f/0x770 net/ipv4/inet_hashtables.c:600
Code: 03 0f b6 04 02 84 c0 74 08 3c 03 0f 8e dd 04 00 00 48 8d 7d 08 44 8b 73 08 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 55 05 00 00 48 8d 7d 14 4c 8b 6d 08 48 b8 00 00
RSP: 0018:ffffc90001777d30 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: ffff88809a6df940 RCX: ffffffff8697c242
RDX: 0000000000000001 RSI: ffffffff8697c251 RDI: 0000000000000008
RBP: 0000000000000000 R08: ffff88809f3ae1c0 R09: fffffbfff1514cc1
R10: ffffffff8a8a6607 R11: fffffbfff1514cc0 R12: ffff88809a6df9b0
R13: 0000000000000007 R14: 0000000000000000 R15: ffffffff873a4d00
FS: 0000000001d2b880(0000) GS:ffff8880ae600000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000006cd090 CR3: 000000009403a000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Fixes: 0d76751fad77 ("l2tp: Add L2TPv3 IP encapsulation (no UDP) support")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: James Chapman <jchapman@katalix.com>
Cc: Andrii Nakryiko <andriin@fb.com>
Reported-by: syzbot+3610d489778b57cc8031@syzkaller.appspotmail.com
---
v2: do not try to share a common unhash() method between IPv4 and IPv6
net/l2tp/l2tp_ip.c | 29 ++++++++++++++++++++++-------
net/l2tp/l2tp_ip6.c | 30 ++++++++++++++++++++++--------
2 files changed, 44 insertions(+), 15 deletions(-)
diff --git a/net/l2tp/l2tp_ip.c b/net/l2tp/l2tp_ip.c
index 0d7c887a2b75db65afba7955a2bf9572a6a37786..955662a6dee754478da0f8ac95d41a787339242b 100644
--- a/net/l2tp/l2tp_ip.c
+++ b/net/l2tp/l2tp_ip.c
@@ -20,7 +20,6 @@
#include <net/icmp.h>
#include <net/udp.h>
#include <net/inet_common.h>
-#include <net/inet_hashtables.h>
#include <net/tcp_states.h>
#include <net/protocol.h>
#include <net/xfrm.h>
@@ -209,15 +208,31 @@ static int l2tp_ip_recv(struct sk_buff *skb)
return 0;
}
+static int l2tp_ip_hash(struct sock *sk)
+{
+ if (sk_unhashed(sk)) {
+ write_lock_bh(&l2tp_ip_lock);
+ sk_add_node(sk, &l2tp_ip_table);
+ write_unlock_bh(&l2tp_ip_lock);
+ }
+ return 0;
+}
+
+static void l2tp_ip_unhash(struct sock *sk)
+{
+ if (sk_unhashed(sk))
+ return;
+ write_lock_bh(&l2tp_ip_lock);
+ sk_del_node_init(sk);
+ write_unlock_bh(&l2tp_ip_lock);
+}
+
static int l2tp_ip_open(struct sock *sk)
{
/* Prevent autobind. We don't have ports. */
inet_sk(sk)->inet_num = IPPROTO_L2TP;
- write_lock_bh(&l2tp_ip_lock);
- sk_add_node(sk, &l2tp_ip_table);
- write_unlock_bh(&l2tp_ip_lock);
-
+ l2tp_ip_hash(sk);
return 0;
}
@@ -594,8 +609,8 @@ static struct proto l2tp_ip_prot = {
.sendmsg = l2tp_ip_sendmsg,
.recvmsg = l2tp_ip_recvmsg,
.backlog_rcv = l2tp_ip_backlog_recv,
- .hash = inet_hash,
- .unhash = inet_unhash,
+ .hash = l2tp_ip_hash,
+ .unhash = l2tp_ip_unhash,
.obj_size = sizeof(struct l2tp_ip_sock),
#ifdef CONFIG_COMPAT
.compat_setsockopt = compat_ip_setsockopt,
diff --git a/net/l2tp/l2tp_ip6.c b/net/l2tp/l2tp_ip6.c
index d148766f40d117c50fc28092173d3686428d1dfc..0fa694bd3f6a992518cab05feb8922fbf94d9829 100644
--- a/net/l2tp/l2tp_ip6.c
+++ b/net/l2tp/l2tp_ip6.c
@@ -20,8 +20,6 @@
#include <net/icmp.h>
#include <net/udp.h>
#include <net/inet_common.h>
-#include <net/inet_hashtables.h>
-#include <net/inet6_hashtables.h>
#include <net/tcp_states.h>
#include <net/protocol.h>
#include <net/xfrm.h>
@@ -222,15 +220,31 @@ static int l2tp_ip6_recv(struct sk_buff *skb)
return 0;
}
+static int l2tp_ip6_hash(struct sock *sk)
+{
+ if (sk_unhashed(sk)) {
+ write_lock_bh(&l2tp_ip6_lock);
+ sk_add_node(sk, &l2tp_ip6_table);
+ write_unlock_bh(&l2tp_ip6_lock);
+ }
+ return 0;
+}
+
+static void l2tp_ip6_unhash(struct sock *sk)
+{
+ if (sk_unhashed(sk))
+ return;
+ write_lock_bh(&l2tp_ip6_lock);
+ sk_del_node_init(sk);
+ write_unlock_bh(&l2tp_ip6_lock);
+}
+
static int l2tp_ip6_open(struct sock *sk)
{
/* Prevent autobind. We don't have ports. */
inet_sk(sk)->inet_num = IPPROTO_L2TP;
- write_lock_bh(&l2tp_ip6_lock);
- sk_add_node(sk, &l2tp_ip6_table);
- write_unlock_bh(&l2tp_ip6_lock);
-
+ l2tp_ip6_hash(sk);
return 0;
}
@@ -728,8 +742,8 @@ static struct proto l2tp_ip6_prot = {
.sendmsg = l2tp_ip6_sendmsg,
.recvmsg = l2tp_ip6_recvmsg,
.backlog_rcv = l2tp_ip6_backlog_recv,
- .hash = inet6_hash,
- .unhash = inet_unhash,
+ .hash = l2tp_ip6_hash,
+ .unhash = l2tp_ip6_unhash,
.obj_size = sizeof(struct l2tp_ip6_sock),
#ifdef CONFIG_COMPAT
.compat_setsockopt = compat_ipv6_setsockopt,
--
2.27.0.rc2.251.g90737beb825-goog
^ permalink raw reply related
* Re: [PATCH][next] RDMA/hns: remove duplicate assignment to pointer raq
From: Jason Gunthorpe @ 2020-05-29 18:20 UTC (permalink / raw)
To: Colin King
Cc: Lijun Ou, Wei Hu, Weihang Li, Doug Ledford, linux-rdma,
kernel-janitors, linux-kernel
In-Reply-To: <20200528150427.420624-1-colin.king@canonical.com>
On Thu, May 28, 2020 at 04:04:27PM +0100, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> The pointer raq is being assigned twice. Fix this by removing
> one of the redundant assignments.
>
> Fixes: 14ba87304bf9 ("RDMA/hns: Remove redundant type cast for general pointers")
> Addressses-Coverity: ("Evaluation order violation")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> drivers/infiniband/hw/hns/hns_roce_hw_v1.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied to for-next
Thanks,
Jason
^ permalink raw reply
* Re: [PATCH][next] RDMA/hns: remove duplicate assignment to pointer raq
From: Jason Gunthorpe @ 2020-05-29 18:20 UTC (permalink / raw)
To: Colin King
Cc: Lijun Ou, Wei Hu, Weihang Li, Doug Ledford, linux-rdma,
kernel-janitors, linux-kernel
In-Reply-To: <20200528150427.420624-1-colin.king@canonical.com>
On Thu, May 28, 2020 at 04:04:27PM +0100, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> The pointer raq is being assigned twice. Fix this by removing
> one of the redundant assignments.
>
> Fixes: 14ba87304bf9 ("RDMA/hns: Remove redundant type cast for general pointers")
> Addressses-Coverity: ("Evaluation order violation")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> drivers/infiniband/hw/hns/hns_roce_hw_v1.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied to for-next
Thanks,
Jason
^ permalink raw reply
* [m68k:m68k-queue 8/13] drivers/usb/host/isp116x.h:370:87: note: in expansion of macro 'isa_rom_writew_raw'
From: kbuild test robot @ 2020-05-29 18:19 UTC (permalink / raw)
To: Michael, Schmitz,
Cc: kbuild-all, linux-m68k, Geert Uytterhoeven, Michael Schmitz
[-- Attachment #1: Type: text/plain, Size: 9683 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git m68k-queue
head: 5e423cc0afd9cc668eba93f37fd9975db9a9d96c
commit: ef0029557f6a4845901edc3f08a2fe21a16c982c [8/13] m68k: atari: usb: Add ISP1160 USB host controller support
config: m68k-allmodconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout ef0029557f6a4845901edc3f08a2fe21a16c982c
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=m68k
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot <lkp@intel.com>
All warnings (new ones prefixed by >>, old ones prefixed by <<):
In file included from arch/m68k/include/asm/io_mm.h:25,
from arch/m68k/include/asm/io.h:8,
from include/linux/io.h:13,
from include/linux/irq.h:20,
from include/asm-generic/hardirq.h:13,
from ./arch/m68k/include/generated/asm/hardirq.h:1,
from include/linux/hardirq.h:9,
from include/linux/interrupt.h:11,
from include/linux/usb.h:16,
from drivers/usb/host/isp116x-hcd.c:66:
arch/m68k/include/asm/raw_io.h: In function 'raw_rom_outsb':
arch/m68k/include/asm/raw_io.h:83:7: warning: variable '__w' set but not used [-Wunused-but-set-variable]
83 | ({u8 __w, __v = (b); u32 _addr = ((u32) (addr)); | ^~~
arch/m68k/include/asm/raw_io.h:430:3: note: in expansion of macro 'rom_out_8'
430 | rom_out_8(port, *buf++);
| ^~~~~~~~~
arch/m68k/include/asm/raw_io.h: In function 'raw_rom_outsw':
arch/m68k/include/asm/raw_io.h:86:8: warning: variable '__w' set but not used [-Wunused-but-set-variable]
86 | ({u16 __w, __v = (w); u32 _addr = ((u32) (addr)); | ^~~
arch/m68k/include/asm/raw_io.h:448:3: note: in expansion of macro 'rom_out_be16'
448 | rom_out_be16(port, *buf++);
| ^~~~~~~~~~~~
arch/m68k/include/asm/raw_io.h: In function 'raw_rom_outsw_swapw':
arch/m68k/include/asm/raw_io.h:90:8: warning: variable '__w' set but not used [-Wunused-but-set-variable]
90 | ({u16 __w, __v = (w); u32 _addr = ((u32) (addr)); | ^~~
arch/m68k/include/asm/raw_io.h:466:3: note: in expansion of macro 'rom_out_le16'
466 | rom_out_le16(port, *buf++);
| ^~~~~~~~~~~~
drivers/usb/host/isp116x.h: In function 'isp116x_write_addr':
arch/m68k/include/asm/raw_io.h:86:8: warning: variable '__w' set but not used [-Wunused-but-set-variable]
86 | ({u16 __w, __v = (w); u32 _addr = ((u32) (addr)); | ^~~
arch/m68k/include/asm/io_mm.h:246:37: note: in expansion of macro 'rom_out_be16'
246 | #define isa_rom_writew_raw(val, p) rom_out_be16(isa_mtw((unsigned long)(p)), (val))
| ^~~~~~~~~~~~
>> drivers/usb/host/isp116x.h:370:87: note: in expansion of macro 'isa_rom_writew_raw'
370 | #define isp_writew(v, p) ((((unsigned long)(__pa(p)) & 0x00000F00) == 0x00000300UL) ? isa_rom_writew_raw((v), __pa(p)) : __raw_writew((v), (p)))
| ^~~~~~~~~~~~~~~~~~
drivers/usb/host/isp116x.h:391:2: note: in expansion of macro 'isp_writew'
391 | isp_writew(reg & 0xff, isp116x->addr_reg);
| ^~~~~~~~~~
drivers/usb/host/isp116x.h: In function 'isp116x_write_data16':
arch/m68k/include/asm/raw_io.h:86:8: warning: variable '__w' set but not used [-Wunused-but-set-variable]
86 | ({u16 __w, __v = (w); u32 _addr = ((u32) (addr)); | ^~~
arch/m68k/include/asm/io_mm.h:246:37: note: in expansion of macro 'rom_out_be16'
246 | #define isa_rom_writew_raw(val, p) rom_out_be16(isa_mtw((unsigned long)(p)), (val))
| ^~~~~~~~~~~~
>> drivers/usb/host/isp116x.h:370:87: note: in expansion of macro 'isa_rom_writew_raw'
370 | #define isp_writew(v, p) ((((unsigned long)(__pa(p)) & 0x00000F00) == 0x00000300UL) ? isa_rom_writew_raw((v), __pa(p)) : __raw_writew((v), (p)))
| ^~~~~~~~~~~~~~~~~~
drivers/usb/host/isp116x.h:397:2: note: in expansion of macro 'isp_writew'
397 | isp_writew(val, isp116x->data_reg);
| ^~~~~~~~~~
drivers/usb/host/isp116x.h: In function 'isp116x_raw_write_data16':
arch/m68k/include/asm/raw_io.h:86:8: warning: variable '__w' set but not used [-Wunused-but-set-variable]
86 | ({u16 __w, __v = (w); u32 _addr = ((u32) (addr)); | ^~~
arch/m68k/include/asm/io_mm.h:241:13: note: in expansion of macro 'rom_out_be16'
241 | (ISA_SEX ? rom_out_be16(isa_mtw((unsigned long)(p)), (val)) | ^~~~~~~~~~~~
>> drivers/usb/host/isp116x.h:372:91: note: in expansion of macro 'isa_rom_writew'
372 | #define isp_raw_writew(v, p) ((((unsigned long)(__pa(p)) & 0x00000F00) == 0x00000300UL) ? isa_rom_writew((v), __pa(p)) : writew((v), (p)))
| ^~~~~~~~~~~~~~
drivers/usb/host/isp116x.h:403:2: note: in expansion of macro 'isp_raw_writew'
403 | isp_raw_writew(val, isp116x->data_reg);
| ^~~~~~~~~~~~~~
arch/m68k/include/asm/raw_io.h:90:8: warning: variable '__w' set but not used [-Wunused-but-set-variable]
90 | ({u16 __w, __v = (w); u32 _addr = ((u32) (addr)); | ^~~
arch/m68k/include/asm/io_mm.h:242:6: note: in expansion of macro 'rom_out_le16'
242 | : rom_out_le16(isa_mtw((unsigned long)(p)), (val)))
| ^~~~~~~~~~~~
>> drivers/usb/host/isp116x.h:372:91: note: in expansion of macro 'isa_rom_writew'
372 | #define isp_raw_writew(v, p) ((((unsigned long)(__pa(p)) & 0x00000F00) == 0x00000300UL) ? isa_rom_writew((v), __pa(p)) : writew((v), (p)))
| ^~~~~~~~~~~~~~
drivers/usb/host/isp116x.h:403:2: note: in expansion of macro 'isp_raw_writew'
403 | isp_raw_writew(val, isp116x->data_reg);
| ^~~~~~~~~~~~~~
drivers/usb/host/isp116x.h: In function 'isp116x_write_data32':
arch/m68k/include/asm/raw_io.h:86:8: warning: variable '__w' set but not used [-Wunused-but-set-variable]
86 | ({u16 __w, __v = (w); u32 _addr = ((u32) (addr)); | ^~~
arch/m68k/include/asm/io_mm.h:246:37: note: in expansion of macro 'rom_out_be16'
246 | #define isa_rom_writew_raw(val, p) rom_out_be16(isa_mtw((unsigned long)(p)), (val))
| ^~~~~~~~~~~~
>> drivers/usb/host/isp116x.h:370:87: note: in expansion of macro 'isa_rom_writew_raw'
370 | #define isp_writew(v, p) ((((unsigned long)(__pa(p)) & 0x00000F00) == 0x00000300UL) ? isa_rom_writew_raw((v), __pa(p)) : __raw_writew((v), (p)))
| ^~~~~~~~~~~~~~~~~~
drivers/usb/host/isp116x.h:427:2: note: in expansion of macro 'isp_writew'
427 | isp_writew(val & 0xffff, isp116x->data_reg);
| ^~~~~~~~~~
arch/m68k/include/asm/raw_io.h:86:8: warning: variable '__w' set but not used [-Wunused-but-set-variable]
86 | ({u16 __w, __v = (w); u32 _addr = ((u32) (addr)); | ^~~
arch/m68k/include/asm/io_mm.h:246:37: note: in expansion of macro 'rom_out_be16'
246 | #define isa_rom_writew_raw(val, p) rom_out_be16(isa_mtw((unsigned long)(p)), (val))
| ^~~~~~~~~~~~
>> drivers/usb/host/isp116x.h:370:87: note: in expansion of macro 'isa_rom_writew_raw'
370 | #define isp_writew(v, p) ((((unsigned long)(__pa(p)) & 0x00000F00) == 0x00000300UL) ? isa_rom_writew_raw((v), __pa(p)) : __raw_writew((v), (p)))
| ^~~~~~~~~~~~~~~~~~
drivers/usb/host/isp116x.h:429:2: note: in expansion of macro 'isp_writew'
429 | isp_writew(val >> 16, isp116x->data_reg);
| ^~~~~~~~~~
vim +/isa_rom_writew_raw +370 drivers/usb/host/isp116x.h
357
358
359 #ifdef CONFIG_ATARI_ROM_ISA
360 /*
361 * 16 bit data bus byte swapped in hardware on both Atari variants.
362 * EtherNAT variant of ISP1160 integration is memory mapped at 0x800000XX,
363 * and uses regular readw/__raw_readw (but semantics swapped).
364 * NetUSBee variant is hooked up through ROM port and uses ROM port
365 * IO access, with fake IO address of 0x3XX.
366 * Selection of the appropriate accessors relies on ioremapped addresses still
367 * retaining the 0x3XX bit.
368 */
369 #define isp_readw(p) ((((unsigned long)(__pa(p)) & 0x00000F00) == 0x00000300UL) ? isa_rom_readw_raw(__pa(p)) : __raw_readw((p)))
> 370 #define isp_writew(v, p) ((((unsigned long)(__pa(p)) & 0x00000F00) == 0x00000300UL) ? isa_rom_writew_raw((v), __pa(p)) : __raw_writew((v), (p)))
371 #define isp_raw_readw(p) ((((unsigned long)(__pa(p)) & 0x00000F00) == 0x00000300UL) ? isa_rom_readw(__pa(p)) : readw((p)))
> 372 #define isp_raw_writew(v, p) ((((unsigned long)(__pa(p)) & 0x00000F00) == 0x00000300UL) ? isa_rom_writew((v), __pa(p)) : writew((v), (p)))
373 #elif defined(CONFIG_ATARI)
374 /*
375 * 16 bit data bus byte swapped in hardware on EtherNAT only.
376 */
377 #define isp_readw __raw_readw
378 #define isp_writew __raw_writew
379 #define isp_raw_readw readw
380 #define isp_raw_writew writew
381 #else
382 /* sane hardware */
383 #define isp_readw readw
384 #define isp_writew writew
385 #define isp_raw_readw __raw_readw
386 #define isp_raw_writew __raw_writew
387 #endif
388
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 53974 bytes --]
^ permalink raw reply
* [m68k:m68k-queue 8/13] drivers/usb/host/isp116x.h:370:87: note: in expansion of macro 'isa_rom_writew_raw'
From: kbuild test robot @ 2020-05-29 18:19 UTC (permalink / raw)
To: kbuild-all
[-- Attachment #1: Type: text/plain, Size: 9838 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git m68k-queue
head: 5e423cc0afd9cc668eba93f37fd9975db9a9d96c
commit: ef0029557f6a4845901edc3f08a2fe21a16c982c [8/13] m68k: atari: usb: Add ISP1160 USB host controller support
config: m68k-allmodconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout ef0029557f6a4845901edc3f08a2fe21a16c982c
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=m68k
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot <lkp@intel.com>
All warnings (new ones prefixed by >>, old ones prefixed by <<):
In file included from arch/m68k/include/asm/io_mm.h:25,
from arch/m68k/include/asm/io.h:8,
from include/linux/io.h:13,
from include/linux/irq.h:20,
from include/asm-generic/hardirq.h:13,
from ./arch/m68k/include/generated/asm/hardirq.h:1,
from include/linux/hardirq.h:9,
from include/linux/interrupt.h:11,
from include/linux/usb.h:16,
from drivers/usb/host/isp116x-hcd.c:66:
arch/m68k/include/asm/raw_io.h: In function 'raw_rom_outsb':
arch/m68k/include/asm/raw_io.h:83:7: warning: variable '__w' set but not used [-Wunused-but-set-variable]
83 | ({u8 __w, __v = (b); u32 _addr = ((u32) (addr)); | ^~~
arch/m68k/include/asm/raw_io.h:430:3: note: in expansion of macro 'rom_out_8'
430 | rom_out_8(port, *buf++);
| ^~~~~~~~~
arch/m68k/include/asm/raw_io.h: In function 'raw_rom_outsw':
arch/m68k/include/asm/raw_io.h:86:8: warning: variable '__w' set but not used [-Wunused-but-set-variable]
86 | ({u16 __w, __v = (w); u32 _addr = ((u32) (addr)); | ^~~
arch/m68k/include/asm/raw_io.h:448:3: note: in expansion of macro 'rom_out_be16'
448 | rom_out_be16(port, *buf++);
| ^~~~~~~~~~~~
arch/m68k/include/asm/raw_io.h: In function 'raw_rom_outsw_swapw':
arch/m68k/include/asm/raw_io.h:90:8: warning: variable '__w' set but not used [-Wunused-but-set-variable]
90 | ({u16 __w, __v = (w); u32 _addr = ((u32) (addr)); | ^~~
arch/m68k/include/asm/raw_io.h:466:3: note: in expansion of macro 'rom_out_le16'
466 | rom_out_le16(port, *buf++);
| ^~~~~~~~~~~~
drivers/usb/host/isp116x.h: In function 'isp116x_write_addr':
arch/m68k/include/asm/raw_io.h:86:8: warning: variable '__w' set but not used [-Wunused-but-set-variable]
86 | ({u16 __w, __v = (w); u32 _addr = ((u32) (addr)); | ^~~
arch/m68k/include/asm/io_mm.h:246:37: note: in expansion of macro 'rom_out_be16'
246 | #define isa_rom_writew_raw(val, p) rom_out_be16(isa_mtw((unsigned long)(p)), (val))
| ^~~~~~~~~~~~
>> drivers/usb/host/isp116x.h:370:87: note: in expansion of macro 'isa_rom_writew_raw'
370 | #define isp_writew(v, p) ((((unsigned long)(__pa(p)) & 0x00000F00) == 0x00000300UL) ? isa_rom_writew_raw((v), __pa(p)) : __raw_writew((v), (p)))
| ^~~~~~~~~~~~~~~~~~
drivers/usb/host/isp116x.h:391:2: note: in expansion of macro 'isp_writew'
391 | isp_writew(reg & 0xff, isp116x->addr_reg);
| ^~~~~~~~~~
drivers/usb/host/isp116x.h: In function 'isp116x_write_data16':
arch/m68k/include/asm/raw_io.h:86:8: warning: variable '__w' set but not used [-Wunused-but-set-variable]
86 | ({u16 __w, __v = (w); u32 _addr = ((u32) (addr)); | ^~~
arch/m68k/include/asm/io_mm.h:246:37: note: in expansion of macro 'rom_out_be16'
246 | #define isa_rom_writew_raw(val, p) rom_out_be16(isa_mtw((unsigned long)(p)), (val))
| ^~~~~~~~~~~~
>> drivers/usb/host/isp116x.h:370:87: note: in expansion of macro 'isa_rom_writew_raw'
370 | #define isp_writew(v, p) ((((unsigned long)(__pa(p)) & 0x00000F00) == 0x00000300UL) ? isa_rom_writew_raw((v), __pa(p)) : __raw_writew((v), (p)))
| ^~~~~~~~~~~~~~~~~~
drivers/usb/host/isp116x.h:397:2: note: in expansion of macro 'isp_writew'
397 | isp_writew(val, isp116x->data_reg);
| ^~~~~~~~~~
drivers/usb/host/isp116x.h: In function 'isp116x_raw_write_data16':
arch/m68k/include/asm/raw_io.h:86:8: warning: variable '__w' set but not used [-Wunused-but-set-variable]
86 | ({u16 __w, __v = (w); u32 _addr = ((u32) (addr)); | ^~~
arch/m68k/include/asm/io_mm.h:241:13: note: in expansion of macro 'rom_out_be16'
241 | (ISA_SEX ? rom_out_be16(isa_mtw((unsigned long)(p)), (val)) | ^~~~~~~~~~~~
>> drivers/usb/host/isp116x.h:372:91: note: in expansion of macro 'isa_rom_writew'
372 | #define isp_raw_writew(v, p) ((((unsigned long)(__pa(p)) & 0x00000F00) == 0x00000300UL) ? isa_rom_writew((v), __pa(p)) : writew((v), (p)))
| ^~~~~~~~~~~~~~
drivers/usb/host/isp116x.h:403:2: note: in expansion of macro 'isp_raw_writew'
403 | isp_raw_writew(val, isp116x->data_reg);
| ^~~~~~~~~~~~~~
arch/m68k/include/asm/raw_io.h:90:8: warning: variable '__w' set but not used [-Wunused-but-set-variable]
90 | ({u16 __w, __v = (w); u32 _addr = ((u32) (addr)); | ^~~
arch/m68k/include/asm/io_mm.h:242:6: note: in expansion of macro 'rom_out_le16'
242 | : rom_out_le16(isa_mtw((unsigned long)(p)), (val)))
| ^~~~~~~~~~~~
>> drivers/usb/host/isp116x.h:372:91: note: in expansion of macro 'isa_rom_writew'
372 | #define isp_raw_writew(v, p) ((((unsigned long)(__pa(p)) & 0x00000F00) == 0x00000300UL) ? isa_rom_writew((v), __pa(p)) : writew((v), (p)))
| ^~~~~~~~~~~~~~
drivers/usb/host/isp116x.h:403:2: note: in expansion of macro 'isp_raw_writew'
403 | isp_raw_writew(val, isp116x->data_reg);
| ^~~~~~~~~~~~~~
drivers/usb/host/isp116x.h: In function 'isp116x_write_data32':
arch/m68k/include/asm/raw_io.h:86:8: warning: variable '__w' set but not used [-Wunused-but-set-variable]
86 | ({u16 __w, __v = (w); u32 _addr = ((u32) (addr)); | ^~~
arch/m68k/include/asm/io_mm.h:246:37: note: in expansion of macro 'rom_out_be16'
246 | #define isa_rom_writew_raw(val, p) rom_out_be16(isa_mtw((unsigned long)(p)), (val))
| ^~~~~~~~~~~~
>> drivers/usb/host/isp116x.h:370:87: note: in expansion of macro 'isa_rom_writew_raw'
370 | #define isp_writew(v, p) ((((unsigned long)(__pa(p)) & 0x00000F00) == 0x00000300UL) ? isa_rom_writew_raw((v), __pa(p)) : __raw_writew((v), (p)))
| ^~~~~~~~~~~~~~~~~~
drivers/usb/host/isp116x.h:427:2: note: in expansion of macro 'isp_writew'
427 | isp_writew(val & 0xffff, isp116x->data_reg);
| ^~~~~~~~~~
arch/m68k/include/asm/raw_io.h:86:8: warning: variable '__w' set but not used [-Wunused-but-set-variable]
86 | ({u16 __w, __v = (w); u32 _addr = ((u32) (addr)); | ^~~
arch/m68k/include/asm/io_mm.h:246:37: note: in expansion of macro 'rom_out_be16'
246 | #define isa_rom_writew_raw(val, p) rom_out_be16(isa_mtw((unsigned long)(p)), (val))
| ^~~~~~~~~~~~
>> drivers/usb/host/isp116x.h:370:87: note: in expansion of macro 'isa_rom_writew_raw'
370 | #define isp_writew(v, p) ((((unsigned long)(__pa(p)) & 0x00000F00) == 0x00000300UL) ? isa_rom_writew_raw((v), __pa(p)) : __raw_writew((v), (p)))
| ^~~~~~~~~~~~~~~~~~
drivers/usb/host/isp116x.h:429:2: note: in expansion of macro 'isp_writew'
429 | isp_writew(val >> 16, isp116x->data_reg);
| ^~~~~~~~~~
vim +/isa_rom_writew_raw +370 drivers/usb/host/isp116x.h
357
358
359 #ifdef CONFIG_ATARI_ROM_ISA
360 /*
361 * 16 bit data bus byte swapped in hardware on both Atari variants.
362 * EtherNAT variant of ISP1160 integration is memory mapped at 0x800000XX,
363 * and uses regular readw/__raw_readw (but semantics swapped).
364 * NetUSBee variant is hooked up through ROM port and uses ROM port
365 * IO access, with fake IO address of 0x3XX.
366 * Selection of the appropriate accessors relies on ioremapped addresses still
367 * retaining the 0x3XX bit.
368 */
369 #define isp_readw(p) ((((unsigned long)(__pa(p)) & 0x00000F00) == 0x00000300UL) ? isa_rom_readw_raw(__pa(p)) : __raw_readw((p)))
> 370 #define isp_writew(v, p) ((((unsigned long)(__pa(p)) & 0x00000F00) == 0x00000300UL) ? isa_rom_writew_raw((v), __pa(p)) : __raw_writew((v), (p)))
371 #define isp_raw_readw(p) ((((unsigned long)(__pa(p)) & 0x00000F00) == 0x00000300UL) ? isa_rom_readw(__pa(p)) : readw((p)))
> 372 #define isp_raw_writew(v, p) ((((unsigned long)(__pa(p)) & 0x00000F00) == 0x00000300UL) ? isa_rom_writew((v), __pa(p)) : writew((v), (p)))
373 #elif defined(CONFIG_ATARI)
374 /*
375 * 16 bit data bus byte swapped in hardware on EtherNAT only.
376 */
377 #define isp_readw __raw_readw
378 #define isp_writew __raw_writew
379 #define isp_raw_readw readw
380 #define isp_raw_writew writew
381 #else
382 /* sane hardware */
383 #define isp_readw readw
384 #define isp_writew writew
385 #define isp_raw_readw __raw_readw
386 #define isp_raw_writew __raw_writew
387 #endif
388
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 53974 bytes --]
^ permalink raw reply
* Re: Rebase failure with git version 2.17.1
From: Bryan Turner @ 2020-05-29 18:19 UTC (permalink / raw)
To: Bensaid, Selma; +Cc: git@vger.kernel.org
In-Reply-To: <BY5PR11MB426002E5EC02396535220F70E18F0@BY5PR11MB4260.namprd11.prod.outlook.com>
On Fri, May 29, 2020 at 11:11 AM Bensaid, Selma <selma.bensaid@intel.com> wrote:
>
> Hi,
> I'm running into a rebase failure with git version 2.17.1 the same rebase is successful with git version 2.7.4.
> Do you have any idea if this a regression or I'm I missing something:
> This the command I run with the 2 versions:
> git rebase --verbose to_remote/to_branch from_remote/from_branch
> Both versions print: Changes from b944516f66e253a325bd3c071f8810b7bd3e0416 to cceddad5aa3161b8b841be92090d12f3ed2349ec:
> However git version 2.17.1 fails the rebase.
Without providing any details of what the failure looks like, it's
going to be pretty difficult for anyone on the list to help you with
the problem. Perhaps you can include more complete output from 2.7.4
and 2.17.1.
> Thanks for your help,
> Selma.
>
^ permalink raw reply
* Re: [PATCH rdma-next v1] RDMA/mlx5: Support TX port affinity for VF drivers in LAG mode
From: Jason Gunthorpe @ 2020-05-29 18:19 UTC (permalink / raw)
To: Leon Romanovsky; +Cc: Doug Ledford, Mark Zhang, linux-rdma, Maor Gottlieb
In-Reply-To: <20200527055014.355093-1-leon@kernel.org>
On Wed, May 27, 2020 at 08:50:14AM +0300, Leon Romanovsky wrote:
> From: Mark Zhang <markz@mellanox.com>
>
> The mlx5 VF driver doesn't set QP tx port affinity because it doesn't
> know if the lag is active or not, since the "lag_active" works only for
> PF interfaces. In this case for VF interfaces only one lag is used
> which brings performance issue.
>
> Add a lag_tx_port_affinity CAP bit; When it is enabled and
> "num_lag_ports > 1", then driver always set QP tx affinity, regardless
> of lag state.
>
> Signed-off-by: Mark Zhang <markz@mellanox.com>
> Reviewed-by: Maor Gottlieb <maorg@mellanox.com>
> Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> ---
> Changelog
> v1:
> * Fixed wrong check of num_lag_ports.
> v0: https://lore.kernel.org/linux-rdma/20200526143457.218840-1-leon@kernel.org
> ---
> drivers/infiniband/hw/mlx5/main.c | 2 +-
> drivers/infiniband/hw/mlx5/mlx5_ib.h | 7 +++++++
> drivers/infiniband/hw/mlx5/qp.c | 3 ++-
> 3 files changed, 10 insertions(+), 2 deletions(-)
Applied to for-next thanks
Jason
^ permalink raw reply
* Re: almost no CIFS stats?
From: Steve French @ 2020-05-29 18:18 UTC (permalink / raw)
To: Pavel Shilovsky; +Cc: Matthias Leopold, ronnie sahlberg, CIFS
In-Reply-To: <CAKywueQ6H=pJQXGWeF3mHUstSjjWMeC64DdKNSYBNSEQO=ss=A@mail.gmail.com>
RHEL7 (and related like CentOS7) did not enable stats by default in
the build (unless Ronnie changed it in later service packs) but the
last 3 RHEL version (RHEL8.2, 8.1, 8.0 and CentOS equivalents) do have
stats enabled. Remember the 3.10 kernel is 7 years old so many things
are missing from it.
Note that for additional stats, including timing (slowest, fastest,
and total time by command), private builds can be done of cifs.ko with
CONFIG_CIFS_STATS2.
I suggest trying it on a more recent version of RHEL or CentOS if
possible (although even for this 7 year old kernel rebuilding cifs.ko
with CONFIG_CIFS_STATS enabled is not too hard if you have the source
RPMs installed).
On Fri, May 29, 2020 at 11:22 AM Pavel Shilovsky <piastryyy@gmail.com> wrote:
>
> HI Matthias,
>
> I remember Stats not working on CentOS 7 - showing zeros as you reported.
>
> Adding Ronnie to comment.
>
> --
> Best regards,
> Pavel Shilovsky
>
> пт, 29 мая 2020 г. в 01:18, Matthias Leopold
> <matthias.leopold@meduniwien.ac.at>:
> >
> > CentOS 7 has kernel 3.10 (modified by Red Hat)
> >
> > Am 28.05.20 um 23:31 schrieb Steve French:
> > > Stats should show counters for most rows. See example below:
> > >
> > > # cat /proc/fs/cifs/Stats
> > > Resources in use
> > > CIFS Session: 1
> > > Share (unique mount targets): 2
> > > SMB Request/Response Buffer: 1 Pool size: 5
> > > SMB Small Req/Resp Buffer: 1 Pool size: 30
> > > Operations (MIDs): 0
> > >
> > > 0 session 0 share reconnects
> > > Total vfs operations: 36 maximum at one time: 2
> > >
> > > Max requests in flight: 3
> > > 1) \\localhost\test
> > > SMBs: 67
> > > Bytes read: 90177536 Bytes written: 2
> > > Open files: 0 total (local), 0 open on server
> > > TreeConnects: 1 total 0 failed
> > > TreeDisconnects: 0 total 0 failed
> > > Creates: 12 total 0 failed
> > > Closes: 13 total 1 failed
> > > Flushes: 1 total 0 failed
> > > Reads: 22 total 0 failed
> > > Writes: 1 total 0 failed
> > > Locks: 0 total 0 failed
> > > IOCTLs: 1 total 1 failed
> > > QueryDirectories: 2 total 0 failed
> > > ChangeNotifies: 0 total 0 failed
> > > QueryInfos: 12 total 0 failed
> > > SetInfos: 2 total 0 failed
> > > OplockBreaks: 0 sent 0 failed
> > >
> > >
> > > Are you running an old kernel (pre-5.0 e.g.)?
> > >
> > > On Thu, May 28, 2020 at 3:39 PM Matthias Leopold
> > > <matthias.leopold@meduniwien.ac.at> wrote:
> > >>
> > >> Hi,
> > >>
> > >> I'm trying to debug the performance of rsync reading from a Windows 2012
> > >> R2 share mounted readonly in CentOS 7. I tried to use cifsiostat, which
> > >> doesn't print any stats. I looked into /proc/fs/cifs/Stats and saw that
> > >> it contains mostly "0" for counters (I would expect to see some numbers
> > >> for eg "Reads"). What am I doing wrong?
> > >>
> > >> options from /proc/mounts are
> > >> ro,relatime,vers=3.0,cache=strict,username=foo,domain=xxx,uid=1706,forceuid,gid=1676,forcegid,addr=10.110.81.122,file_mode=0660,dir_mode=0770,soft,nounix,serverino,mapposix,rsize=61440,wsize=1048576,echo_interval=60,actimeo=1
> > >>
> > >> thx
> > >> Matthias
> > >
> > >
> > >
> >
> > --
> > Matthias Leopold
> > IT Systems & Communications
> > Medizinische Universität Wien
> > Spitalgasse 23 / BT 88 /Ebene 00
> > A-1090 Wien
> > Tel: +43 1 40160-21241
> > Fax: +43 1 40160-921200
--
Thanks,
Steve
^ permalink raw reply
* Re: CFLAGS overridden by distribution build system
From: Stephen Smalley @ 2020-05-29 18:18 UTC (permalink / raw)
To: William Roberts; +Cc: Laurent Bigonville, SElinux list
In-Reply-To: <CAFftDdr3A=rKcbzWcMDmz-XrqBTGd7mNbLLxt2vzU71DsqZ_9w@mail.gmail.com>
On Fri, May 29, 2020 at 1:15 PM William Roberts
<bill.c.roberts@gmail.com> wrote:
>
> On Fri, May 29, 2020 at 11:40 AM Stephen Smalley
> <stephen.smalley.work@gmail.com> wrote:
> >
> > On Fri, May 29, 2020 at 12:05 PM William Roberts
> > <bill.c.roberts@gmail.com> wrote:
> > >
> > > On Fri, May 29, 2020 at 8:31 AM Stephen Smalley
> > > <stephen.smalley.work@gmail.com> wrote:
> > > >
> > > > On Sat, May 23, 2020 at 11:59 AM William Roberts
> > > > <bill.c.roberts@gmail.com> wrote:
> > > > >
> > > > > On Sat, May 23, 2020 at 5:57 AM Laurent Bigonville <bigon@debian.org> wrote:
> > > > > >
> > > > > > Hello,
> > > > > >
> > > > > > The current build system of the userspace is setting a lot of CFLAGS,
> > > > > > but most of these are overridden by the distributions when building.
> > > > > >
> > > > > > Today I received a bug report[0] from Christian Göttsche asking me to
> > > > > > set -fno-semantic-interposition again in libsepol. I see also the same
> > > > > > flag and also a lot of others set in libselinux and libsemanage build
> > > > > > system.
> > > > >
> > > > > Why would it be again? The old DSO design made that option impotent.
> > > > > Clang does it by default.
> > > > >
> > > > > >
> > > > > > For what I understand some of these are just needed for code quality
> > > > > > (-W) and could be controlled by distributions but others might actually
> > > > > > need to be always set (-f?).
> > > > >
> > > > > If you look at the Makefiles overall in all the projects, you'll see hardening
> > > > > flags, etc. Libsepol has a pretty minimal set compared to say libselinux, but
> > > > > they all get overridden by build time CFLAGS if you want.
> > > > >
> > > > > >
> > > > > > Shouldn't the flags that always need to be set (which ones?) be moved to
> > > > > > a "override CFLAGS" directive to avoid these to be unset by distributions?
> > > > >
> > > > > If you we're cleaver with CFLAGS before, you could acually circumvent
> > > > > the buildtime
> > > > > DSO stuff. While i'm not opposed to adding it to immutable flag, if
> > > > > you're setting
> > > > > CFLAGS, you're on your own. At least with the current design.
> > > > >
> > > > > I have no issues with adding it to override, but we would have to
> > > > > overhaul a bunch
> > > > > of them and make them consistent.
> > > >
> > > > I'm inclined to agree with Laurent here - we should always set this
> > > > flag in order to preserve the same behavior prior to the patches that
> > > > removed hidden_def/hidden_proto and switched to relying on this
> > > > instead.
> > >
> > > Theirs a lot of features that rely on particular cflags, consider hardening
> > > options. A lot of the warnings/error stuff is not just a code hygiene, but also
> > > spotting potential issues that could arise as security issues. If one starts
> > > tinkering with cflags, you can really change the code quite a bit. This is why
> > > some places only approve sanctioned builds of crypto libraries.
> >
> > I think the difference here is that we made a change in the source
> > code (hidden_def/hidden_proto removal) that requires use of
> > -fno-semantic-interposition to preserve existing behavior.
> >
> > > But one of the things to consider is that for clang builds, clang
> > > doesn't support
> > > this option, so we would need to move the compiler checking code into each
> > > projects root makefile and ensure any consuming subordinate leafs add a
> > > default, or move it to the global makefile and make sure each leaf that needs it
> > > has a default.
> >
> > I think clang does support it now? https://reviews.llvm.org/D72724
>
> Yeah but that bug is all 2020 stuff. It is in the clang-10 release. I
> verified that
> with a local build from here:
> - https://apt.llvm.org/
> So anything sub clang-10 won't support it, do you want to tie us to that
> new of a clang?
No, I guess not. So I guess our options are to leave it alone and
just make sure it is well documented or complicate the Makefiles.
^ permalink raw reply
* Re: [PATCH v3 104/105] dt-bindings: display: vc4: hdmi: Add BCM2711 HDMI controllers bindings
From: Rob Herring @ 2020-05-29 18:18 UTC (permalink / raw)
To: Maxime Ripard
Cc: devicetree, Tim Gover, Dave Stevenson, linux-kernel, dri-devel,
Eric Anholt, bcm-kernel-feedback-list, Nicolas Saenz Julienne,
Phil Elwell, linux-arm-kernel, linux-rpi-kernel
In-Reply-To: <e85e24a494a3ff41177c94673ced0f4280b6a0ee.1590594512.git-series.maxime@cerno.tech>
On Wed, May 27, 2020 at 05:49:14PM +0200, Maxime Ripard wrote:
> The HDMI controllers found in the BCM2711 SoC need some adjustments to the
> bindings, especially since the registers have been shuffled around in more
> register ranges.
>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> ---
> Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml | 109 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 109 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
>
> diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> new file mode 100644
> index 000000000000..6091fe3d315b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> @@ -0,0 +1,109 @@
> +# SPDX-License-Identifier: GPL-2.0
Dual license...
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/brcm,bcm2711-hdmi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Broadcom BCM2711 HDMI Controller Device Tree Bindings
> +
> +maintainers:
> + - Eric Anholt <eric@anholt.net>
> +
> +properties:
> + compatible:
> + enum:
> + - brcm,bcm2711-hdmi0
> + - brcm,bcm2711-hdmi1
What's the difference between the 2 blocks?
> +
> + reg:
> + items:
> + - description: HDMI controller register range
> + - description: DVP register range
> + - description: HDMI PHY register range
> + - description: Rate Manager register range
> + - description: Packet RAM register range
> + - description: Metadata RAM register range
> + - description: CSC register range
> + - description: CEC register range
> + - description: HD register range
> +
> + reg-names:
> + items:
> + - const: hdmi
> + - const: dvp
> + - const: phy
> + - const: rm
> + - const: packet
> + - const: metadata
> + - const: csc
> + - const: cec
> + - const: hd
> +
> + clocks:
> + description: The HDMI state machine clock
> +
> + clock-names:
> + const: hdmi
> +
> + ddc:
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/phandle
> + description: >
> + Phandle of the I2C controller used for DDC EDID probing
Goes in the connector.
And isn't the standard name ddc-i2c-bus?
> +
> + hpd-gpios:
> + description: >
> + The GPIO pin for the HDMI hotplug detect (if it doesn't appear
> + as an interrupt/status bit in the HDMI controller itself)
Goes in the connector.
> +
> + dmas:
> + maxItems: 1
> + description: >
> + Should contain one entry pointing to the DMA channel used to
> + transfer audio data.
> +
> + dma-names:
> + const: audio-rx
> +
> + resets:
> + maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - clocks
> + - resets
> + - ddc
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + hdmi0: hdmi@7ef00700 {
> + compatible = "brcm,bcm2711-hdmi0";
> + reg = <0x7ef00700 0x300>,
> + <0x7ef00300 0x200>,
> + <0x7ef00f00 0x80>,
> + <0x7ef00f80 0x80>,
> + <0x7ef01b00 0x200>,
> + <0x7ef01f00 0x400>,
> + <0x7ef00200 0x80>,
> + <0x7ef04300 0x100>,
> + <0x7ef20000 0x100>;
> + reg-names = "hdmi",
> + "dvp",
> + "phy",
> + "rm",
> + "packet",
> + "metadata",
> + "csc",
> + "cec",
> + "hd";
> + clocks = <&firmware_clocks 13>;
> + clock-names = "hdmi";
> + resets = <&dvp 0>;
> + ddc = <&ddc0>;
> + };
> +
> +...
> --
> git-series 0.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 104/105] dt-bindings: display: vc4: hdmi: Add BCM2711 HDMI controllers bindings
From: Rob Herring @ 2020-05-29 18:18 UTC (permalink / raw)
To: Maxime Ripard
Cc: Nicolas Saenz Julienne, Eric Anholt, dri-devel, linux-rpi-kernel,
bcm-kernel-feedback-list, linux-arm-kernel, linux-kernel,
Dave Stevenson, Tim Gover, Phil Elwell, devicetree
In-Reply-To: <e85e24a494a3ff41177c94673ced0f4280b6a0ee.1590594512.git-series.maxime@cerno.tech>
On Wed, May 27, 2020 at 05:49:14PM +0200, Maxime Ripard wrote:
> The HDMI controllers found in the BCM2711 SoC need some adjustments to the
> bindings, especially since the registers have been shuffled around in more
> register ranges.
>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> ---
> Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml | 109 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 109 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
>
> diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> new file mode 100644
> index 000000000000..6091fe3d315b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> @@ -0,0 +1,109 @@
> +# SPDX-License-Identifier: GPL-2.0
Dual license...
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/brcm,bcm2711-hdmi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Broadcom BCM2711 HDMI Controller Device Tree Bindings
> +
> +maintainers:
> + - Eric Anholt <eric@anholt.net>
> +
> +properties:
> + compatible:
> + enum:
> + - brcm,bcm2711-hdmi0
> + - brcm,bcm2711-hdmi1
What's the difference between the 2 blocks?
> +
> + reg:
> + items:
> + - description: HDMI controller register range
> + - description: DVP register range
> + - description: HDMI PHY register range
> + - description: Rate Manager register range
> + - description: Packet RAM register range
> + - description: Metadata RAM register range
> + - description: CSC register range
> + - description: CEC register range
> + - description: HD register range
> +
> + reg-names:
> + items:
> + - const: hdmi
> + - const: dvp
> + - const: phy
> + - const: rm
> + - const: packet
> + - const: metadata
> + - const: csc
> + - const: cec
> + - const: hd
> +
> + clocks:
> + description: The HDMI state machine clock
> +
> + clock-names:
> + const: hdmi
> +
> + ddc:
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/phandle
> + description: >
> + Phandle of the I2C controller used for DDC EDID probing
Goes in the connector.
And isn't the standard name ddc-i2c-bus?
> +
> + hpd-gpios:
> + description: >
> + The GPIO pin for the HDMI hotplug detect (if it doesn't appear
> + as an interrupt/status bit in the HDMI controller itself)
Goes in the connector.
> +
> + dmas:
> + maxItems: 1
> + description: >
> + Should contain one entry pointing to the DMA channel used to
> + transfer audio data.
> +
> + dma-names:
> + const: audio-rx
> +
> + resets:
> + maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - clocks
> + - resets
> + - ddc
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + hdmi0: hdmi@7ef00700 {
> + compatible = "brcm,bcm2711-hdmi0";
> + reg = <0x7ef00700 0x300>,
> + <0x7ef00300 0x200>,
> + <0x7ef00f00 0x80>,
> + <0x7ef00f80 0x80>,
> + <0x7ef01b00 0x200>,
> + <0x7ef01f00 0x400>,
> + <0x7ef00200 0x80>,
> + <0x7ef04300 0x100>,
> + <0x7ef20000 0x100>;
> + reg-names = "hdmi",
> + "dvp",
> + "phy",
> + "rm",
> + "packet",
> + "metadata",
> + "csc",
> + "cec",
> + "hd";
> + clocks = <&firmware_clocks 13>;
> + clock-names = "hdmi";
> + resets = <&dvp 0>;
> + ddc = <&ddc0>;
> + };
> +
> +...
> --
> git-series 0.9.1
^ permalink raw reply
* Re: [PATCH v3 104/105] dt-bindings: display: vc4: hdmi: Add BCM2711 HDMI controllers bindings
From: Rob Herring @ 2020-05-29 18:18 UTC (permalink / raw)
To: Maxime Ripard
Cc: devicetree, Tim Gover, Dave Stevenson, linux-kernel, dri-devel,
bcm-kernel-feedback-list, Nicolas Saenz Julienne, Phil Elwell,
linux-arm-kernel, linux-rpi-kernel
In-Reply-To: <e85e24a494a3ff41177c94673ced0f4280b6a0ee.1590594512.git-series.maxime@cerno.tech>
On Wed, May 27, 2020 at 05:49:14PM +0200, Maxime Ripard wrote:
> The HDMI controllers found in the BCM2711 SoC need some adjustments to the
> bindings, especially since the registers have been shuffled around in more
> register ranges.
>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> ---
> Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml | 109 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 109 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
>
> diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> new file mode 100644
> index 000000000000..6091fe3d315b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> @@ -0,0 +1,109 @@
> +# SPDX-License-Identifier: GPL-2.0
Dual license...
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/brcm,bcm2711-hdmi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Broadcom BCM2711 HDMI Controller Device Tree Bindings
> +
> +maintainers:
> + - Eric Anholt <eric@anholt.net>
> +
> +properties:
> + compatible:
> + enum:
> + - brcm,bcm2711-hdmi0
> + - brcm,bcm2711-hdmi1
What's the difference between the 2 blocks?
> +
> + reg:
> + items:
> + - description: HDMI controller register range
> + - description: DVP register range
> + - description: HDMI PHY register range
> + - description: Rate Manager register range
> + - description: Packet RAM register range
> + - description: Metadata RAM register range
> + - description: CSC register range
> + - description: CEC register range
> + - description: HD register range
> +
> + reg-names:
> + items:
> + - const: hdmi
> + - const: dvp
> + - const: phy
> + - const: rm
> + - const: packet
> + - const: metadata
> + - const: csc
> + - const: cec
> + - const: hd
> +
> + clocks:
> + description: The HDMI state machine clock
> +
> + clock-names:
> + const: hdmi
> +
> + ddc:
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/phandle
> + description: >
> + Phandle of the I2C controller used for DDC EDID probing
Goes in the connector.
And isn't the standard name ddc-i2c-bus?
> +
> + hpd-gpios:
> + description: >
> + The GPIO pin for the HDMI hotplug detect (if it doesn't appear
> + as an interrupt/status bit in the HDMI controller itself)
Goes in the connector.
> +
> + dmas:
> + maxItems: 1
> + description: >
> + Should contain one entry pointing to the DMA channel used to
> + transfer audio data.
> +
> + dma-names:
> + const: audio-rx
> +
> + resets:
> + maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - clocks
> + - resets
> + - ddc
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + hdmi0: hdmi@7ef00700 {
> + compatible = "brcm,bcm2711-hdmi0";
> + reg = <0x7ef00700 0x300>,
> + <0x7ef00300 0x200>,
> + <0x7ef00f00 0x80>,
> + <0x7ef00f80 0x80>,
> + <0x7ef01b00 0x200>,
> + <0x7ef01f00 0x400>,
> + <0x7ef00200 0x80>,
> + <0x7ef04300 0x100>,
> + <0x7ef20000 0x100>;
> + reg-names = "hdmi",
> + "dvp",
> + "phy",
> + "rm",
> + "packet",
> + "metadata",
> + "csc",
> + "cec",
> + "hd";
> + clocks = <&firmware_clocks 13>;
> + clock-names = "hdmi";
> + resets = <&dvp 0>;
> + ddc = <&ddc0>;
> + };
> +
> +...
> --
> git-series 0.9.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v30 09/20] mm: Introduce vm_ops->may_mprotect()
From: Jarkko Sakkinen @ 2020-05-29 18:18 UTC (permalink / raw)
To: Borislav Petkov
Cc: linux-kernel, x86, linux-sgx, akpm, dave.hansen,
sean.j.christopherson, nhorman, npmccallum, haitao.huang,
andriy.shevchenko, tglx, kai.svahn, josh, luto, kai.huang,
rientjes, cedric.xing, puiterwijk, Jethro Beekman
In-Reply-To: <20200529121038.GG9011@zn.tnic>
On Fri, May 29, 2020 at 02:10:38PM +0200, Borislav Petkov wrote:
> On Fri, May 15, 2020 at 03:43:59AM +0300, Jarkko Sakkinen wrote:
> > From: Sean Christopherson <sean.j.christopherson@intel.com>
> >
> > Add vm_ops()->may_mprotect() to check additional constrains set by a
>
> "constraints"
>
> > subsystem for a mprotect() call.
> >
> > Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
> > Acked-by: Jethro Beekman <jethro@fortanix.com>
> > Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> > ---
> > include/linux/mm.h | 2 ++
> > mm/mprotect.c | 14 +++++++++++---
> > 2 files changed, 13 insertions(+), 3 deletions(-)
>
> This needs an ACK from an mm person.
Good point. I'll add the needed cc's.
/Jarkko
^ permalink raw reply
* Re: [PATCH 0/2] x86/entry: simplify RESTORE_CR3
From: Andy Lutomirski @ 2020-05-29 18:17 UTC (permalink / raw)
To: Lai Jiangshan
Cc: LKML, Andy Lutomirski, Peter Zijlstra, Thomas Gleixner, X86 ML
In-Reply-To: <20200526043507.51977-1-laijs@linux.alibaba.com>
On Mon, May 25, 2020 at 9:35 PM Lai Jiangshan <laijs@linux.alibaba.com> wrote:
>
> When I searched percpu data touched by entry code for #DB
> protection[1], it seems to me RESTORE_CR3() does too much work,
> this patchset simplifies it.
>
> Patch 1 enhances 21e944591102("x86/mm: Optimize RESTORE_CR3") for
> kernel CR3.
>
> Patch 2 *reverts* 21e944591102("x86/mm: Optimize RESTORE_CR3") for
> User CR3.
This series looks correct, but I don't think it's 5.8 material. I
also want to try moving all this code to C, so it's possible this
little series will become obsolete.
>
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: x86@kernel.org
> Link: https://lore.kernel.org/lkml/20200525145102.122557-1-laijs@linux.alibaba.com
> Lai Jiangshan (2):
> x86/entry: Don't write to CR3 when restoring to kernel CR3
> x86/entry: always flush user CR3 in RESTORE_CR3
>
> arch/x86/entry/calling.h | 36 ++++++++----------------------------
> arch/x86/entry/entry_64.S | 6 +++---
> 2 files changed, 11 insertions(+), 31 deletions(-)
>
> --
> 2.20.1
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.