* [PATCH v2 09/21] arm: socfpga: Define SMC function identifiers for PSCI SiP services
From: Marek Vasut @ 2020-02-20 16:46 UTC (permalink / raw)
To: u-boot
In-Reply-To: <BN7PR11MB26593E27783A6CCC5FD7B220A2130@BN7PR11MB2659.namprd11.prod.outlook.com>
On 2/20/20 2:42 AM, Ang, Chee Hong wrote:
>> On 2/19/20 1:25 PM, chee.hong.ang at intel.com wrote:
>> [...]
>>> +++ b/include/linux/intel-smc.h
>>> @@ -0,0 +1,374 @@
>>> +/* SPDX-License-Identifier: GPL-2.0 */
>>> +/*
>>> + * Copyright (C) 2017-2018, Intel Corporation
>>
>> 2020 ?
> This file is new in U-Boot but it already exists in Linux kernel and adapted from there.
> Should I change it to 2020 ?
Then it's 2017-2020 .
[...]
^ permalink raw reply
* Re: [Xen-devel] [PATCH v6 1/6] libxl: add infrastructure to track and query 'recent' domids
From: Ian Jackson @ 2020-02-20 16:45 UTC (permalink / raw)
To: Durrant, Paul; +Cc: Anthony Perard, xen-devel@lists.xenproject.org, Wei Liu
In-Reply-To: <46a3c93352de4e07b33263c9fb7f37bf@EX13D32EUC003.ant.amazon.com>
Durrant, Paul writes ("RE: [PATCH v6 1/6] libxl: add infrastructure to track and query 'recent' domids"):
> [Ian:]
> > IMO the reuse timeout call and the clock_gettime call should be put in
> > libxl__open_domid_history; and the time filtering check should be
> > folded into libxl__read_recent.
>
> Ok. I was having a hard time guessing just exactly what you're looking for. I think that makes it a little clearer.
...
> > In my review of v4 I wrote:
> >
> > Do you think this can be combined somehow ? Possibilities seem to
> > include: explicit read_recent_{init,entry,finish} functions; a single
> > function with a "per-entry" callback; same but with a macro. If you
> > do that you can also have it have handle the "file does not exist"
> > special case.
> >
> > You've provided the read_recent_entry function but the "init" function
> > libxl__open_domid_history does too little. This series seems to be
> > moving towards what I called read_recent_{init,entry,finish} (which
> > should probably have the timestamp and FILE* in a struct together) but
> > it seems to be doing so quite slowly.
>
> Now again I'm not sure *exactly* what you want me to do, but I'll have another guess.
Maybe it would be better for us to try to come to a shared
understanding before you do another respin...
> > - It encourages vacuous log messages whose content is mainly in the
> > function and line number framing:
> > + LOGE(ERROR, "failed");
> > + return ERROR_FAIL;
> > +}
> > rather than
> > if (!*f) {
> > LOGE(ERROR, "failed to open recent domid file `%s'", path);
> > rc = ERROR_FAIL;
> > goto out;
> > }
> > (and the latter is to be preferred).
>
> But by asking me to put the error handling inside the sub-functions I lost context such as 'path' which was present in the previous structure. I could pass in an argument purely for the benefit of a log function but that seems excessive. I guess I will pull the error logging out again, but that seemed to be against your requirement to de-duplicate code.
I think the path needs to be passed into these functions. This is why
I think the functions need to take a struct* as an argument, for their
shared state (including the path and the other stuff).
Thanks,
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Please pull mmc mmc-2-20-2020
From: Tom Rini @ 2020-02-20 16:45 UTC (permalink / raw)
To: u-boot
In-Reply-To: <AM0PR04MB44815C08D9FD9469B90BD78288130@AM0PR04MB4481.eurprd04.prod.outlook.com>
On Thu, Feb 20, 2020 at 11:58:37AM +0000, Peng Fan wrote:
> Hi Tom
>
> Please pull mmc-2-20-2020.
> I redo CI with Masahiro's fix, and no issue.
>
Applied to u-boot/master, thanks!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200220/bd90dcfd/attachment.sig>
^ permalink raw reply
* [PATCH v2 06/21] configs: socfpga: Enable FIT image loading with ATF support
From: Marek Vasut @ 2020-02-20 16:45 UTC (permalink / raw)
To: u-boot
In-Reply-To: <BN7PR11MB26590C92D443A835CBA4D63CA2130@BN7PR11MB2659.namprd11.prod.outlook.com>
On 2/20/20 3:15 AM, Ang, Chee Hong wrote:
>> On 2/19/20 1:25 PM, chee.hong.ang at intel.com wrote:
>>> From: Chee Hong Ang <chee.hong.ang@intel.com>
>>>
>>> SPL now loads ATF (BL31), U-Boot proper and DTB from FIT image. The
>>> new boot flow with ATF support is as follow:
>>>
>>> SPL -> ATF (BL31) -> U-Boot proper -> OS (Linux)
>>>
>>> Signed-off-by: Chee Hong Ang <chee.hong.ang@intel.com>
>>> ---
>>> configs/socfpga_agilex_defconfig | 8 +++++++-
>>> configs/socfpga_stratix10_defconfig | 8 +++++++-
>>> 2 files changed, 14 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/configs/socfpga_agilex_defconfig
>>> b/configs/socfpga_agilex_defconfig
>>> index 693a774..0065ff0 100644
>>> --- a/configs/socfpga_agilex_defconfig
>>> +++ b/configs/socfpga_agilex_defconfig
>>> @@ -1,6 +1,6 @@
>>> CONFIG_ARM=y
>>> CONFIG_ARCH_SOCFPGA=y
>>> -CONFIG_SYS_TEXT_BASE=0x1000
>>> +CONFIG_SYS_TEXT_BASE=0x200000
>>
>> Why did the text base change ?
> This defconfig support ATF.
> ATF will occupy from this address range (0x1000)
> U-Boot now starts at 0x200000.
Then please document it in the commit message.
>>> CONFIG_SYS_MALLOC_F_LEN=0x2000
>>> CONFIG_ENV_SIZE=0x1000
>>> CONFIG_ENV_OFFSET=0x200
>>> @@ -10,10 +10,16 @@ CONFIG_TARGET_SOCFPGA_AGILEX_SOCDK=y
>>> CONFIG_IDENT_STRING="socfpga_agilex"
>>> CONFIG_SPL_FS_FAT=y
>>> CONFIG_SPL_TEXT_BASE=0xFFE00000
>>> +CONFIG_FIT=y
>>> +CONFIG_SPL_LOAD_FIT=y
>>> +CONFIG_SPL_FIT_SOURCE="board/altera/soc64/its/fit_spl_atf.its"
>>> CONFIG_BOOTDELAY=5
>>> +CONFIG_SPL_LEGACY_IMAGE_SUPPORT=y
>>
>> Is legacy image support really needed ?
> Let me check. Will get rid of this if it's not needed. Thanks.
Thanks
^ permalink raw reply
* Re: syzkaller wireguard key situation [was: Re: [PATCH net-next v2] net: WireGuard secure network tunnel]
From: Dmitry Vyukov @ 2020-02-20 16:44 UTC (permalink / raw)
To: Jason A. Donenfeld; +Cc: netdev, syzbot, WireGuard mailing list
In-Reply-To: <CAHmME9pSWRe8k3+4G45tWE9V+N3A9APN5KFq65S5D0JNvR2xxQ@mail.gmail.com>
On Thu, Feb 20, 2020 at 5:34 PM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> Hi Dmitry,
>
> On Thu, Feb 20, 2020 at 5:14 PM Dmitry Vyukov <dvyukov@google.com> wrote:
> > I got some coverage in wg_netdevice_notification:
> > https://imgur.com/a/1sJZKtp
> >
> > Or you mean the parts that are still red?
>
> Yes, it's the red parts that interest me. Intermixing those with
> various wireguard-specific netlink calls and setting devices up and
> down and putting traffic through those sockets, in weird ways, could
> dig up bugs.
>
> > I think theoretically these parts should be reachable too because
> > syzkaller can do unshare and obtain net ns fd's.
> >
> > It's quite hard to test because it just crashes all the time on known bugs.
> > So maybe the most profitable way to get more coverage throughout the
> > networking subsystem now is to fix the top layer of crashers ;)
>
> Ahhh, interesting, so the issue is that syzkaller is finding too many
> other networking stack bugs before it gets to being able to play with
> wireguard. Shucks.
If it's aimed only at, say, wireguard netlink interface, then it's not
distracted by bugs in other parts. But as you add some ipv4/6 tcp/udp
sockets, more netlink to change these net namespaces, namespaces
related syscalls, packet injection, etc, in the end it covers quite a
significant part of kernel. You know how fuzzing works, right. You
really need to fix the current layer of bugs to get to the next one.
And we accumulated 600+ open bugs. It still finds some new ones, but I
guess these are really primitive ones (as compared to its full bug
finding potential).
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
^ permalink raw reply
* Re: syzkaller wireguard key situation [was: Re: [PATCH net-next v2] net: WireGuard secure network tunnel]
From: Dmitry Vyukov @ 2020-02-20 16:44 UTC (permalink / raw)
To: Jason A. Donenfeld; +Cc: netdev, syzbot, WireGuard mailing list
In-Reply-To: <CAHmME9pSWRe8k3+4G45tWE9V+N3A9APN5KFq65S5D0JNvR2xxQ@mail.gmail.com>
On Thu, Feb 20, 2020 at 5:34 PM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> Hi Dmitry,
>
> On Thu, Feb 20, 2020 at 5:14 PM Dmitry Vyukov <dvyukov@google.com> wrote:
> > I got some coverage in wg_netdevice_notification:
> > https://imgur.com/a/1sJZKtp
> >
> > Or you mean the parts that are still red?
>
> Yes, it's the red parts that interest me. Intermixing those with
> various wireguard-specific netlink calls and setting devices up and
> down and putting traffic through those sockets, in weird ways, could
> dig up bugs.
>
> > I think theoretically these parts should be reachable too because
> > syzkaller can do unshare and obtain net ns fd's.
> >
> > It's quite hard to test because it just crashes all the time on known bugs.
> > So maybe the most profitable way to get more coverage throughout the
> > networking subsystem now is to fix the top layer of crashers ;)
>
> Ahhh, interesting, so the issue is that syzkaller is finding too many
> other networking stack bugs before it gets to being able to play with
> wireguard. Shucks.
If it's aimed only at, say, wireguard netlink interface, then it's not
distracted by bugs in other parts. But as you add some ipv4/6 tcp/udp
sockets, more netlink to change these net namespaces, namespaces
related syscalls, packet injection, etc, in the end it covers quite a
significant part of kernel. You know how fuzzing works, right. You
really need to fix the current layer of bugs to get to the next one.
And we accumulated 600+ open bugs. It still finds some new ones, but I
guess these are really primitive ones (as compared to its full bug
finding potential).
^ permalink raw reply
* [PATCH v2 05/21] arm: socfpga: Override 'lowlevel_init' to support ATF
From: Marek Vasut @ 2020-02-20 16:44 UTC (permalink / raw)
To: u-boot
In-Reply-To: <BN7PR11MB2659CA7FDF203F0E8BADF022A2130@BN7PR11MB2659.namprd11.prod.outlook.com>
On 2/20/20 3:27 AM, Ang, Chee Hong wrote:
>> On 2/19/20 1:25 PM, chee.hong.ang at intel.com wrote:
>> [...]
>>> diff --git a/arch/arm/mach-socfpga/lowlevel_init.S
>>> b/arch/arm/mach-socfpga/lowlevel_init.S
>>> new file mode 100644
>>> index 0000000..68053a0
>>> --- /dev/null
>>> +++ b/arch/arm/mach-socfpga/lowlevel_init.S
>>
>> This should be some lowlevel_init_64.S to make it clear it's only for
>> arm64 platforms.
> OK. It makes sense. Thanks.
>>
>>> @@ -0,0 +1,85 @@
>>> +/* SPDX-License-Identifier: GPL-2.0 */
>>> +/*
>>> + * Copyright (C) 2019, Intel Corporation */
>>> +
>>> +#include <asm-offsets.h>
>>> +#include <config.h>
>>> +#include <linux/linkage.h>
>>> +#include <asm/macro.h>
>>> +
>>> +ENTRY(lowlevel_init)
>>> + mov x29, lr /* Save LR */
>>> +
>>> +#if defined(CONFIG_GICV2) || defined(CONFIG_GICV3) #ifdef
>>> +CONFIG_SPL_ATF
>>> + branch_if_slave x0, 2f
>>> +#else
>>> + branch_if_slave x0, 1f
>>> +#endif
>>> +
>>> + ldr x0, =GICD_BASE
>>> + bl gic_init_secure
>>> +#ifdef CONFIG_SPL_BUILD
>>> + b 2f
>>> +#else
>>> + b 3f
>>> +#endif
>>
>> Can't this be done in C code ? Can we reduce the ifdeffery ?
> This lowlevel_init function is shared by SPL and U-Boot and they
> run in slightly different flow.
What does this 'different flow' mean ?
> I don't think this can be done in C code but let me see what I can
> do to further optimize the flow to reduce the ifdeffery.
That would be nice, thanks.
^ permalink raw reply
* [PATCH v2 01/21] configs: agilex: Remove CONFIG_OF_EMBED
From: Marek Vasut @ 2020-02-20 16:44 UTC (permalink / raw)
To: u-boot
In-Reply-To: <BN7PR11MB2659622454DB10AC8103C7C1A2130@BN7PR11MB2659.namprd11.prod.outlook.com>
On 2/20/20 3:12 AM, Ang, Chee Hong wrote:
>> On 2/19/20 1:25 PM, chee.hong.ang at intel.com wrote:
>>> From: Chee Hong Ang <chee.hong.ang@intel.com>
>>>
>>> CONFIG_OF_EMBED was primarily enabled to support the agilex spl hex
>>> file requirements. Since this option now produces a warning during
>>> build, and the spl hex can be created using alternate methods,
>>> CONFIG_OF_EMBED is no longer needed.
>>>
>>> Signed-off-by: Chee Hong Ang <chee.hong.ang@intel.com>
>>
>> If I apply just this patch, is the platform still bootable ?
> Yes. I tested on the platform.
> There is a similar patch from Dalon for Stratix10 and it still yet to be applied
> to mainline:
> https://lists.denx.de/pipermail/u-boot/2019-September/384906.html
>
> I hope the patch from Dalon get applied to mainline before these patchsets.
>
> In fact, this "CONFIG_OF_EMBED" produce warning during build.
> Better get rid of this.
If you just remove OF_EMBED, will the DT still be correctly passed in ?
The warning is there for a reason and just removing OF_EMBED to silence
the warning isn't the right approach. But if this works on Agilex, fine.
^ permalink raw reply
* Re: Thoughts on representing the LED groups in Redfish ?
From: Patrick Williams @ 2020-02-20 16:43 UTC (permalink / raw)
To: Vishwanatha Subbanna; +Cc: openbmc@lists.ozlabs.org
In-Reply-To: <A5C7580C-9577-4023-89E0-F7F715538EFF@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 2031 bytes --]
On Thu, Feb 20, 2020 at 02:28:59PM +0530, Vishwanatha Subbanna wrote:
> Hello,
>
> Wonder if the community has any thoughts ?
>
> Thanks,
> !! Vishwa !!
>
>
> On 14-Feb-2020, at 4:51 PM, Vishwanatha Subbanna
> <vishwa@linux.vnet.ibm.com> wrote:
>
> Hello,
>
> Writing this to get your thoughts on representing LED logical groups in
> Redfish.
>
> OpenBmc LED subsystem has 2 layers
>
> 1/. Logical LED group manager
> 2/. Physical LED controller that sets ONE particular LED to On/Off/Blink
>
> Logical LED group manager:
>
> This is where we define a group with set of physical LEDs and their
> respective actions for one use case.
>
> For example: https://github.com/openbmc/phosphor-led-manager/blob/master/
> led.yaml
>
> When the user wants to turn on the Identify indicators, they don’t target
> the physical LEDs individually. Instead, they just set the “Asserted”
> property : “xyz/openbmc_project/led/groups/enclosure_identify/attr/
> Asserted"
>
> LED manager will then request physical led controllers of those LEDs to
> take the right action
>
> Current bmcweb actually uses the groups than targeting the physical LEDs.
> So it’s good. https://github.com/openbmc/bmcweb/blob/
> 1c8fba97b1feb4164e9b54cd66aad530bbfc1826/redfish-core/lib/led.hpp#L33
>
> However, I am not sure if there are ways to express the LED logical groups
> in the redfish schema.
>
> Any ideas ?
>
> Thank you,
> !! Vishwa !!
It seems like if BMCWeb is using the logical groups already, this is
good because this is likely what the administrator is most interested in
anyhow. From what you've written here, I'm not sure what the new
feature is you'd be proposing. How might logical vs physical LEDs be
presented in a management interface like Redfish and what advantage does
it provide to a user (over what we're doing today)?
--
Patrick Williams
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 0/5] Support metric group constraint
From: Andi Kleen @ 2020-02-20 16:43 UTC (permalink / raw)
To: Liang, Kan
Cc: Jiri Olsa, acme, mingo, peterz, linux-kernel, mark.rutland,
namhyung, ravi.bangoria, yao.jin
In-Reply-To: <534b4b99-466a-0a5b-e9f5-b4711abd8a4a@linux.intel.com>
> For other metric groups, even they have cycles, the issue should not be
> triggered.
> For example, if they have 4 or less events, the cycles can be scheduled to
> GP counter instead.
> If they have 6 or more events, the weak group will be reject anyway.
> Perf tool will open it as non-group (standalone metrics).
Technically it can also happen for 9 events with Hyper Threading off or
on Icelake (8 generic counters)
I didn't think we had any of those, but please double check.
-Andi
^ permalink raw reply
* Re: [PATCH 11/19] target/arm: Replace ARM_FEATURE_VFP4 with isar_feature_aa32_simdfmac
From: Peter Maydell @ 2020-02-20 16:41 UTC (permalink / raw)
To: Richard Henderson; +Cc: QEMU Developers
In-Reply-To: <CAFEAcA-fDx8HAFcgx57FhnpHPY6GnC1PxRRW=sLRY=5dDysfiQ@mail.gmail.com>
On Thu, 20 Feb 2020 at 16:37, Peter Maydell <peter.maydell@linaro.org> wrote:
>
> On Fri, 14 Feb 2020 at 18:16, Richard Henderson
> <richard.henderson@linaro.org> wrote:
> >
> > All remaining tests for VFP4 are for fused multiply-add insns.
> >
> > Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
> > ---
> > target/arm/cpu.h | 5 +++++
> > target/arm/translate-vfp.inc.c | 12 ++++++++----
> > target/arm/translate.c | 2 +-
> > 3 files changed, 14 insertions(+), 5 deletions(-)
> >
> > diff --git a/target/arm/cpu.h b/target/arm/cpu.h
> > index 4ff28418df..f27b8e35df 100644
> > --- a/target/arm/cpu.h
> > +++ b/target/arm/cpu.h
> > @@ -3468,6 +3468,11 @@ static inline bool isar_feature_aa32_fp16_dpconv(const ARMISARegisters *id)
> > return FIELD_EX32(id->mvfr1, MVFR1, FPHP) > 1;
> > }
> >
> > +static inline bool isar_feature_aa32_simdfmac(const ARMISARegisters *id)
> > +{
> > + return FIELD_EX32(id->mvfr1, MVFR1, SIMDFMAC) != 0;
> > +}
>
> This is tricky, because the SIMDFMAC register
> field indicates "do we have fused-multiply-accumulate
> for either VFP or Neon", so in a VFP-no-Neon core or
> a Neon-no-VFP core it will be 1 but can't be used on its
> own as a gate on "should this insn be present".
>
> Currently in the part of arm_cpu_realize() which handles
> the user having selected vfp=off and/or neon=off we
> do allow (for AArch32 cores) both of those combinations.
>
> trans_VFM_dp already tests aa32_fpdp_v2, so I think the
> main thing we need to do is add a test on aa32_fpsp_v2 to
> trans_VFM_sp.
>
> We clear the SIMDFMAC field to 0 in the !has_neon condition,
> and I think that should actually be in the !neon && !vfp part.
>
> I propose to squash in the following and beef up the commit message:
>
> + /* Despite the name, this field covers both VFP and Neon */
> + u = cpu->isar.mvfr1;
> + u = FIELD_DP32(u, MVFR1, SIMDFMAC, 0);
> + cpu->isar.mvfr1;
... "cpu->isar.mvfr1 = u;", obviously.
> - if (!dc_isar_feature(aa32_simdfmac, s)) {
> + if (!dc_isar_feature(aa32_simdfmac, s) ||
> + !dc_isar_feature(aa32_fpsp_v2, s)) {
> + return false;
> + }
and not that extra "}".
-- PMM
^ permalink raw reply
* Re: [PATCH 0/4] btrfs: improve normal backref walking
From: David Sterba @ 2020-02-20 16:41 UTC (permalink / raw)
To: ethanwu; +Cc: linux-btrfs
In-Reply-To: <20200207093818.23710-1-ethanwu@synology.com>
On Fri, Feb 07, 2020 at 05:38:14PM +0800, ethanwu wrote:
> Btrfs has two types of data backref.
> For BTRFS_EXTENT_DATA_REF_KEY type of backref, we don't have the
> exact block number. Therefore, we need to call resolve_indirect_refs.
> It uses btrfs_search_slot to locate the leaf block. Then
> we need to walk through the leaves to search for the EXTENT_DATA items
> that have disk bytenr matching the extent item(add_all_parents).
>
> When resolving indirect refs, we could take entries that don't
> belong to the backref entry we are searching for right now.
> For that reason when searching backref entry, we always use total
> refs of that EXTENT_ITEM rather than individual count.
>
> For example:
> item 11 key (40831553536 EXTENT_ITEM 4194304) itemoff 15460 itemsize
> extent refs 24 gen 7302 flags DATA
> shared data backref parent 394985472 count 10 #1
> extent data backref root 257 objectid 260 offset 1048576 count 3 #2
> extent data backref root 256 objectid 260 offset 65536 count 6 #3
> extent data backref root 257 objectid 260 offset 65536 count 5 #4
>
> For example, when searching backref entry #4, we'll use total_refs
> 24, a very loose loop ending condition, instead of total_refs = 5.
>
> But using total_refs=24 is not accurate. Sometimes, we'll never find
> all the refs from specific root.
> As a result, the loop keeps on going until we reach the end of that inode.
>
> The first 3 patches, handle 3 different types refs we might encounter.
> These refs do not belong to the normal backref we are searching, and
> hence need to be skipped.
>
> The last patch changes the total_refs to correct number so that we could
> end loop as soon as we find all the refs we want.
>
> btrfs send uses backref to find possible clone sources, the following
> is a simple test to compare the results with and without this patch
>
> btrfs subvolume create /volume1/sub1
> for i in `seq 1 163840`; do dd if=/dev/zero of=/volume1/sub1/file bs=64K count=1 seek=$((i-1)) conv=notrunc oflag=direct 2>/dev/null; done
> btrfs subvolume snapshot /volume1/sub1 /volume1/sub2
> for i in `seq 1 163840`; do dd if=/dev/zero of=/volume1/sub1/file bs=4K count=1 seek=$(((i-1)*16+10)) conv=notrunc oflag=direct 2>/dev/null; done
> btrfs subvolume snapshot -r /volume1/sub1 /volume1/snap1
> time btrfs send /volume1/snap1 | btrfs receive /volume2
>
> without this patch
> real 69m48.124s
> user 0m50.199s
> sys 70m15.600s
>
> with this patch
> real 1m59.683s
> user 0m35.421s
> sys 2m42.684s
This is too good to be left only in the cover letter and lost in the
mailinglist, so I copied that to the 4th patch that puts all the things
together and the explanation is very useful. Also the numbers show a
significant improvement.
I've moved the patchset from a topic branch to misc-next for wider
testing. The test failure I reported is not directly caused by these
changes but it's still something to watch for. The target merge is 5.7
so there's plenty of time to test, backreferences are the corner stone
of btrfs so this must work 100%.
Thanks.
^ permalink raw reply
* Re: [PATCH v2 2/4] firmware: raspberrypi: Introduce vl805 init routine
From: Nicolas Saenz Julienne @ 2020-02-20 16:41 UTC (permalink / raw)
To: Florian Fainelli, linux-kernel, Ray Jui, Scott Branden,
bcm-kernel-feedback-list
Cc: tim.gover, gregkh, linux-usb, linux-rpi-kernel, linux-pci,
linux-arm-kernel, wahrenst
In-Reply-To: <538b8ba7-e6d3-e8f2-0cc6-ce3485bc7848@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1104 bytes --]
On Wed, 2020-02-19 at 11:13 -0800, Florian Fainelli wrote:
> On 2/19/20 4:39 AM, Nicolas Saenz Julienne wrote:
> > On the Raspberry Pi 4, after a PCI reset, VL805's firmware may either be
> > loaded directly from an EEPROM or, if not present, by the SoC's
> > VideCore. The function informs VideCore that VL805 was just reset, or
> > requests for a probe defer.
> >
> > Based on Tim Gover's downstream implementation.
> >
> > Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> > ---
>
> [snip]
>
>
> > diff --git a/include/soc/bcm2835/raspberrypi-firmware.h
> > b/include/soc/bcm2835/raspberrypi-firmware.h
> > index cc9cdbc66403..a37c3a461d2a 100644
> > --- a/include/soc/bcm2835/raspberrypi-firmware.h
> > +++ b/include/soc/bcm2835/raspberrypi-firmware.h
> > @@ -8,6 +8,7 @@
> >
> > #include <linux/types.h>
> > #include <linux/of_device.h>
> > +#include <linux/pci.h>
>
> I would move this inclusion where we need it, which is in
> drivers/firmware/raspberrypi.c and only provide a forward declaration
> here (avoids needless rebuilds).
Noted
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
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 v2 2/4] firmware: raspberrypi: Introduce vl805 init routine
From: Nicolas Saenz Julienne @ 2020-02-20 16:41 UTC (permalink / raw)
To: Florian Fainelli, linux-kernel, Ray Jui, Scott Branden,
bcm-kernel-feedback-list
Cc: linux-usb, linux-rpi-kernel, linux-arm-kernel, gregkh, tim.gover,
linux-pci, wahrenst
In-Reply-To: <538b8ba7-e6d3-e8f2-0cc6-ce3485bc7848@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1104 bytes --]
On Wed, 2020-02-19 at 11:13 -0800, Florian Fainelli wrote:
> On 2/19/20 4:39 AM, Nicolas Saenz Julienne wrote:
> > On the Raspberry Pi 4, after a PCI reset, VL805's firmware may either be
> > loaded directly from an EEPROM or, if not present, by the SoC's
> > VideCore. The function informs VideCore that VL805 was just reset, or
> > requests for a probe defer.
> >
> > Based on Tim Gover's downstream implementation.
> >
> > Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> > ---
>
> [snip]
>
>
> > diff --git a/include/soc/bcm2835/raspberrypi-firmware.h
> > b/include/soc/bcm2835/raspberrypi-firmware.h
> > index cc9cdbc66403..a37c3a461d2a 100644
> > --- a/include/soc/bcm2835/raspberrypi-firmware.h
> > +++ b/include/soc/bcm2835/raspberrypi-firmware.h
> > @@ -8,6 +8,7 @@
> >
> > #include <linux/types.h>
> > #include <linux/of_device.h>
> > +#include <linux/pci.h>
>
> I would move this inclusion where we need it, which is in
> drivers/firmware/raspberrypi.c and only provide a forward declaration
> here (avoids needless rebuilds).
Noted
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 02/13] fixup! KVM: selftests: Add support for vcpu_args_set to aarch64 and s390x
From: Paolo Bonzini @ 2020-02-20 16:40 UTC (permalink / raw)
To: Andrew Jones, Ben Gardon; +Cc: kvm, borntraeger, frankja, thuth, Peter Xu
In-Reply-To: <20200218173841.llr73vagnviejmuu@kamzik.brq.redhat.com>
On 18/02/20 18:38, Andrew Jones wrote:
> For me the code makes that super obvious, and I prefer not to describe what
> code does. Also, I'd put these type of comment blocks, written more
> generally, in the header files if they're functions that are implemented
> by all architectures, rather than duplicating them in each source file.
This makes sense. For now I've restored the comment, but moving them to
the .h files is a good idea.
Paolo
^ permalink raw reply
* Re: ioctl seems to change errno behaviour in 5.6.0rc2
From: Douglas Gilbert @ 2020-02-20 16:30 UTC (permalink / raw)
To: Antonio Larrosa, Jens Axboe; +Cc: linux-scsi, Arnd Bergmann
In-Reply-To: <68516393-f24a-dbb5-4c81-99fb1b70bb6f@suse.de>
On 2020-02-20 11:02 a.m., Antonio Larrosa wrote:
> Hello,
>
> I noticed cdparanoia stopped working with kernel 5.6.0rc2 while it worked fine
> with 5.5.2 .
>
> Running as root `cdparanoia -v -d /dev/sr0 [0]` with 5.6.0rc2, gives the
> following errors:
>
> Testing /dev/sr0 for SCSI/MMC interface
> no SG_IO support for device: /dev/sr0
> Error trying to open /dev/sga exclusively (No such file or directory).
>
> I checked that the sg module is loaded with both kernels and also did a diff of
> the lsmod output with both kernels and didn't find anything suspicious.
>
> After some tests, I did a small c application using code from cdparanoia where
> it can be seen that the ioctl(fd, SG_IO, &hdr) call returns EINVAL in errno with
> the 5.5.2 kernel but returns EFAULT with 5.6.0rc2 .
>
> The code is attached and can be built just with `gcc test.c -o test` (note it's
> hardcoded in main to use /dev/sr0, so it doesn't have any parameter).
>
> Note that I'm not a cdparanoia developer (in fact, it seems to have been
> unmaintained for many years), but I thought it might be interesting to report an
> ioctl that changes the behaviour in different kernels.
Antonio,
A fix is in the works for this, see:
[PATCH] compat_ioctl, cdrom: Replace .ioctl with .compat_ioctl in four
appropriate places
by Arnd Bergmann on the linux-scsi list.
Doug Gilbert
^ permalink raw reply
* Re: [PATCH] PCI: imx6: Add L1SS support for i.MX8MQ
From: Andrey Smirnov @ 2020-02-20 16:39 UTC (permalink / raw)
To: linux-pci
Cc: linux-arm-kernel, Lorenzo Pieralisi, Richard Zhu, linux-kernel,
dl-linux-imx, Bjorn Helgaas, Chris Healy, Lucas Stach
In-Reply-To: <20200114170231.16421-1-andrew.smirnov@gmail.com>
On Tue, Jan 14, 2020 at 9:02 AM Andrey Smirnov <andrew.smirnov@gmail.com> wrote:
>
> Add code to configure PCI IP block to utilize supported ASPM features.
>
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Chris Healy <cphealy@gmail.com>
> Cc: Lucas Stach <l.stach@pengutronix.de>
> Cc: Richard Zhu <hongxing.zhu@nxp.com>
> Cc: linux-imx@nxp.com
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-pci@vger.kernel.org
> ---
> drivers/pci/controller/dwc/pci-imx6.c | 72 ++++++++++++++++++++++-----
> 1 file changed, 60 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
> index acfbd34032a8..3cc94ab7d22b 100644
> --- a/drivers/pci/controller/dwc/pci-imx6.c
> +++ b/drivers/pci/controller/dwc/pci-imx6.c
> @@ -40,6 +40,9 @@
> #define IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE GENMASK(11, 8)
> #define IMX8MQ_PCIE2_BASE_ADDR 0x33c00000
>
> +#define IMX8MQ_PCIE_LINK_CAP_L1EL_64US (0x6 << 15)
> +#define IMX8MQ_PCIE_CTRL_APPS_CLK_REQ BIT(4)
> +
> #define to_imx6_pcie(x) dev_get_drvdata((x)->dev)
>
> enum imx6_pcie_variants {
> @@ -64,12 +67,14 @@ struct imx6_pcie {
> struct dw_pcie *pci;
> int reset_gpio;
> bool gpio_active_high;
> + bool supports_clkreq;
> struct clk *pcie_bus;
> struct clk *pcie_phy;
> struct clk *pcie_inbound_axi;
> struct clk *pcie;
> struct clk *pcie_aux;
> struct regmap *iomuxc_gpr;
> + struct regmap *src;
> u32 controller_id;
> struct reset_control *pciephy_reset;
> struct reset_control *apps_reset;
> @@ -421,11 +426,17 @@ static unsigned int imx6_pcie_grp_offset(const struct imx6_pcie *imx6_pcie)
> return imx6_pcie->controller_id == 1 ? IOMUXC_GPR16 : IOMUXC_GPR14;
> }
>
> +static unsigned int
> +imx6_pcie_pciphy_rcr_offset(const struct imx6_pcie *imx6_pcie)
> +{
> + WARN_ON(imx6_pcie->drvdata->variant != IMX8MQ);
> + return imx6_pcie->controller_id == 1 ? 0x48 : 0x2C;
> +}
> +
> static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
> {
> struct dw_pcie *pci = imx6_pcie->pci;
> struct device *dev = pci->dev;
> - unsigned int offset;
> int ret = 0;
>
> switch (imx6_pcie->drvdata->variant) {
> @@ -463,17 +474,19 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
> break;
> }
>
> - offset = imx6_pcie_grp_offset(imx6_pcie);
> - /*
> - * Set the over ride low and enabled
> - * make sure that REF_CLK is turned on.
> - */
> - regmap_update_bits(imx6_pcie->iomuxc_gpr, offset,
> - IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE,
> - 0);
> - regmap_update_bits(imx6_pcie->iomuxc_gpr, offset,
> - IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN,
> - IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN);
> + if (!imx6_pcie->supports_clkreq) {
> + unsigned int offset = imx6_pcie_grp_offset(imx6_pcie);
> + /*
> + * Set the over ride low and enabled
> + * make sure that REF_CLK is turned on.
> + */
> + regmap_update_bits(imx6_pcie->iomuxc_gpr, offset,
> + IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE,
> + 0);
> + regmap_update_bits(imx6_pcie->iomuxc_gpr, offset,
> + IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN,
> + IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN);
> + }
Ugh, I just realized all of my testing was implicitly relying on
bootloader configuring those CLKREQ overrides bits, so all of the code
related to in in this patch is bogus and broken. Glad it didn't get
applied. Will submit corrected v2 once I work out the right way to do
this.
> break;
> }
>
> @@ -547,6 +560,27 @@ static void imx6_pcie_deassert_core_reset(struct imx6_pcie *imx6_pcie)
> switch (imx6_pcie->drvdata->variant) {
> case IMX8MQ:
> reset_control_deassert(imx6_pcie->pciephy_reset);
> + if (imx6_pcie->supports_clkreq) {
> + u32 lcr;
> +
> + regmap_update_bits(imx6_pcie->src,
> + imx6_pcie_pciphy_rcr_offset(imx6_pcie),
> + IMX8MQ_PCIE_CTRL_APPS_CLK_REQ,
> + IMX8MQ_PCIE_CTRL_APPS_CLK_REQ);
> + /*
> + * Configure the L1 latency of rc to less than
> + * 64us Otherwise, the L1/L1SUB wouldn't be
> + * enable by ASPM.
> + */
> + dw_pcie_dbi_ro_wr_en(pci);
> +
> + lcr = dw_pcie_readl_dbi2(pci, PCIE_RC_LCR);
> + lcr &= ~PCI_EXP_LNKCAP_L1EL;
> + lcr |= IMX8MQ_PCIE_LINK_CAP_L1EL_64US;
> + dw_pcie_writel_dbi2(pci, PCIE_RC_LCR, lcr);
> +
> + dw_pcie_dbi_ro_wr_dis(pci);
> + }
> break;
> case IMX7D:
> reset_control_deassert(imx6_pcie->pciephy_reset);
> @@ -1054,6 +1088,11 @@ static int imx6_pcie_probe(struct platform_device *pdev)
> pci->dbi_base = devm_ioremap_resource(dev, dbi_base);
> if (IS_ERR(pci->dbi_base))
> return PTR_ERR(pci->dbi_base);
> + /*
> + * Configure dbi_base2 to access DBI space with CS2
> + * asserted
> + */
> + pci->dbi_base2 = pci->dbi_base + SZ_1M;
>
> /* Fetch GPIOs */
> imx6_pcie->reset_gpio = of_get_named_gpio(node, "reset-gpio", 0);
> @@ -1107,6 +1146,13 @@ static int imx6_pcie_probe(struct platform_device *pdev)
> dev_err(dev, "pcie_aux clock source missing or invalid\n");
> return PTR_ERR(imx6_pcie->pcie_aux);
> }
> + imx6_pcie->src =
> + syscon_regmap_lookup_by_compatible("fsl,imx8mq-src");
> + if (IS_ERR(imx6_pcie->src)) {
> + dev_err(dev, "SRC regmap is missing or invalid\n");
> + return PTR_ERR(imx6_pcie->src);
> + }
> +
> /* fall through */
> case IMX7D:
> if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
> @@ -1179,6 +1225,8 @@ static int imx6_pcie_probe(struct platform_device *pdev)
> imx6_pcie->vpcie = NULL;
> }
>
> + imx6_pcie->supports_clkreq = of_property_read_bool(node,
> + "supports-clkreq");
> platform_set_drvdata(pdev, imx6_pcie);
>
> ret = imx6_pcie_attach_pd(dev);
> --
> 2.21.0
_______________________________________________
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] PCI: imx6: Add L1SS support for i.MX8MQ
From: Andrey Smirnov @ 2020-02-20 16:39 UTC (permalink / raw)
To: linux-pci
Cc: Lorenzo Pieralisi, Bjorn Helgaas, Chris Healy, Lucas Stach,
Richard Zhu, dl-linux-imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20200114170231.16421-1-andrew.smirnov@gmail.com>
On Tue, Jan 14, 2020 at 9:02 AM Andrey Smirnov <andrew.smirnov@gmail.com> wrote:
>
> Add code to configure PCI IP block to utilize supported ASPM features.
>
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Chris Healy <cphealy@gmail.com>
> Cc: Lucas Stach <l.stach@pengutronix.de>
> Cc: Richard Zhu <hongxing.zhu@nxp.com>
> Cc: linux-imx@nxp.com
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-pci@vger.kernel.org
> ---
> drivers/pci/controller/dwc/pci-imx6.c | 72 ++++++++++++++++++++++-----
> 1 file changed, 60 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
> index acfbd34032a8..3cc94ab7d22b 100644
> --- a/drivers/pci/controller/dwc/pci-imx6.c
> +++ b/drivers/pci/controller/dwc/pci-imx6.c
> @@ -40,6 +40,9 @@
> #define IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE GENMASK(11, 8)
> #define IMX8MQ_PCIE2_BASE_ADDR 0x33c00000
>
> +#define IMX8MQ_PCIE_LINK_CAP_L1EL_64US (0x6 << 15)
> +#define IMX8MQ_PCIE_CTRL_APPS_CLK_REQ BIT(4)
> +
> #define to_imx6_pcie(x) dev_get_drvdata((x)->dev)
>
> enum imx6_pcie_variants {
> @@ -64,12 +67,14 @@ struct imx6_pcie {
> struct dw_pcie *pci;
> int reset_gpio;
> bool gpio_active_high;
> + bool supports_clkreq;
> struct clk *pcie_bus;
> struct clk *pcie_phy;
> struct clk *pcie_inbound_axi;
> struct clk *pcie;
> struct clk *pcie_aux;
> struct regmap *iomuxc_gpr;
> + struct regmap *src;
> u32 controller_id;
> struct reset_control *pciephy_reset;
> struct reset_control *apps_reset;
> @@ -421,11 +426,17 @@ static unsigned int imx6_pcie_grp_offset(const struct imx6_pcie *imx6_pcie)
> return imx6_pcie->controller_id == 1 ? IOMUXC_GPR16 : IOMUXC_GPR14;
> }
>
> +static unsigned int
> +imx6_pcie_pciphy_rcr_offset(const struct imx6_pcie *imx6_pcie)
> +{
> + WARN_ON(imx6_pcie->drvdata->variant != IMX8MQ);
> + return imx6_pcie->controller_id == 1 ? 0x48 : 0x2C;
> +}
> +
> static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
> {
> struct dw_pcie *pci = imx6_pcie->pci;
> struct device *dev = pci->dev;
> - unsigned int offset;
> int ret = 0;
>
> switch (imx6_pcie->drvdata->variant) {
> @@ -463,17 +474,19 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
> break;
> }
>
> - offset = imx6_pcie_grp_offset(imx6_pcie);
> - /*
> - * Set the over ride low and enabled
> - * make sure that REF_CLK is turned on.
> - */
> - regmap_update_bits(imx6_pcie->iomuxc_gpr, offset,
> - IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE,
> - 0);
> - regmap_update_bits(imx6_pcie->iomuxc_gpr, offset,
> - IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN,
> - IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN);
> + if (!imx6_pcie->supports_clkreq) {
> + unsigned int offset = imx6_pcie_grp_offset(imx6_pcie);
> + /*
> + * Set the over ride low and enabled
> + * make sure that REF_CLK is turned on.
> + */
> + regmap_update_bits(imx6_pcie->iomuxc_gpr, offset,
> + IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE,
> + 0);
> + regmap_update_bits(imx6_pcie->iomuxc_gpr, offset,
> + IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN,
> + IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN);
> + }
Ugh, I just realized all of my testing was implicitly relying on
bootloader configuring those CLKREQ overrides bits, so all of the code
related to in in this patch is bogus and broken. Glad it didn't get
applied. Will submit corrected v2 once I work out the right way to do
this.
> break;
> }
>
> @@ -547,6 +560,27 @@ static void imx6_pcie_deassert_core_reset(struct imx6_pcie *imx6_pcie)
> switch (imx6_pcie->drvdata->variant) {
> case IMX8MQ:
> reset_control_deassert(imx6_pcie->pciephy_reset);
> + if (imx6_pcie->supports_clkreq) {
> + u32 lcr;
> +
> + regmap_update_bits(imx6_pcie->src,
> + imx6_pcie_pciphy_rcr_offset(imx6_pcie),
> + IMX8MQ_PCIE_CTRL_APPS_CLK_REQ,
> + IMX8MQ_PCIE_CTRL_APPS_CLK_REQ);
> + /*
> + * Configure the L1 latency of rc to less than
> + * 64us Otherwise, the L1/L1SUB wouldn't be
> + * enable by ASPM.
> + */
> + dw_pcie_dbi_ro_wr_en(pci);
> +
> + lcr = dw_pcie_readl_dbi2(pci, PCIE_RC_LCR);
> + lcr &= ~PCI_EXP_LNKCAP_L1EL;
> + lcr |= IMX8MQ_PCIE_LINK_CAP_L1EL_64US;
> + dw_pcie_writel_dbi2(pci, PCIE_RC_LCR, lcr);
> +
> + dw_pcie_dbi_ro_wr_dis(pci);
> + }
> break;
> case IMX7D:
> reset_control_deassert(imx6_pcie->pciephy_reset);
> @@ -1054,6 +1088,11 @@ static int imx6_pcie_probe(struct platform_device *pdev)
> pci->dbi_base = devm_ioremap_resource(dev, dbi_base);
> if (IS_ERR(pci->dbi_base))
> return PTR_ERR(pci->dbi_base);
> + /*
> + * Configure dbi_base2 to access DBI space with CS2
> + * asserted
> + */
> + pci->dbi_base2 = pci->dbi_base + SZ_1M;
>
> /* Fetch GPIOs */
> imx6_pcie->reset_gpio = of_get_named_gpio(node, "reset-gpio", 0);
> @@ -1107,6 +1146,13 @@ static int imx6_pcie_probe(struct platform_device *pdev)
> dev_err(dev, "pcie_aux clock source missing or invalid\n");
> return PTR_ERR(imx6_pcie->pcie_aux);
> }
> + imx6_pcie->src =
> + syscon_regmap_lookup_by_compatible("fsl,imx8mq-src");
> + if (IS_ERR(imx6_pcie->src)) {
> + dev_err(dev, "SRC regmap is missing or invalid\n");
> + return PTR_ERR(imx6_pcie->src);
> + }
> +
> /* fall through */
> case IMX7D:
> if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
> @@ -1179,6 +1225,8 @@ static int imx6_pcie_probe(struct platform_device *pdev)
> imx6_pcie->vpcie = NULL;
> }
>
> + imx6_pcie->supports_clkreq = of_property_read_bool(node,
> + "supports-clkreq");
> platform_set_drvdata(pdev, imx6_pcie);
>
> ret = imx6_pcie_attach_pd(dev);
> --
> 2.21.0
^ permalink raw reply
* Re: [PATCH AUTOSEL 5.5 190/542] selinux: ensure we cleanup the internal AVC counters on error in avc_insert()
From: Sasha Levin @ 2020-02-20 16:40 UTC (permalink / raw)
To: Stephen Smalley; +Cc: linux-kernel, stable, Paul Moore, rsiddoji, selinux
In-Reply-To: <64b56666-4e4a-10e0-0a1d-60ee28615d23@tycho.nsa.gov>
On Fri, Feb 14, 2020 at 11:07:37AM -0500, Stephen Smalley wrote:
>On 2/14/20 10:43 AM, Sasha Levin wrote:
>>From: Paul Moore <paul@paul-moore.com>
>>
>>[ Upstream commit d8db60cb23e49a92cf8cada3297395c7fa50fdf8 ]
>>
>>Fix avc_insert() to call avc_node_kill() if we've already allocated
>>an AVC node and the code fails to insert the node in the cache.
>>
>>Fixes: fa1aa143ac4a ("selinux: extended permissions for ioctls")
>>Reported-by: rsiddoji@codeaurora.org
>>Suggested-by: Stephen Smalley <sds@tycho.nsa.gov>
>>Acked-by: Stephen Smalley <sds@tycho.nsa.gov>
>>Signed-off-by: Paul Moore <paul@paul-moore.com>
>>Signed-off-by: Sasha Levin <sashal@kernel.org>
>
>You should also apply 030b995ad9ece9fa2d218af4429c1c78c2342096
>("selinux: ensure we cleanup the internal AVC counters on error in
>avc_update()") which fixes one additional instance of the same kind of
>bug not addressed by this patch.
I took that patch as well, thank you.
--
Thanks,
Sasha
^ permalink raw reply
* [PATCH 1/4] wdt: Add CONFIG_DESIGNWARE_WATCHDOG to Kconfig
From: Marek Vasut @ 2020-02-20 16:39 UTC (permalink / raw)
To: u-boot
In-Reply-To: <f738a3ef-9718-13f1-950d-684372dbc132@gmail.com>
On 2/19/20 10:37 PM, Sean Anderson wrote:
> On 2/3/20 3:13 AM, Marek Vasut wrote:
>> On 2/2/20 7:02 PM, Sean Anderson wrote:
>>>> btw what's the motivation for this series, are you hitting some issues
>>>> with the WDT on SoCFPGA ?
>>>
>>> This watchdog appears on the Kendryte K210 CPU, which I am adding
>>> support for. The rest of the board uses devicetree to configure drivers,
>>> so I wanted to add support for this watchdog as well.
>>>
>>
>> You should be able to use what's in u-boot-socfpga/master then. Please
>> give it a try.
>>
>
> This patch series works except that I still need "[PATCH 2/4] arm: Move
> asm/utils.h to log2.h". I will include it with my k210 support series,
> since it is specific to that board.
Great! Rebase on u-boot/master and repost. Thanks.
^ permalink raw reply
* Re: [PATCH] task_work_run: don't take ->pi_lock unconditionally
From: Peter Zijlstra @ 2020-02-20 16:39 UTC (permalink / raw)
To: Oleg Nesterov
Cc: Jens Axboe, Carter Li 李通洲, Pavel Begunkov,
io-uring
In-Reply-To: <20200218155017.GD3466@redhat.com>
On Tue, Feb 18, 2020 at 04:50:18PM +0100, Oleg Nesterov wrote:
> As Peter pointed out, task_work() can avoid ->pi_lock and cmpxchg()
> if task->task_works == NULL && !PF_EXITING.
>
> And in fact the only reason why task_work_run() needs ->pi_lock is
> the possible race with task_work_cancel(), we can optimize this code
> and make the locking more clear.
>
> Signed-off-by: Oleg Nesterov <oleg@redhat.com>
> ---
Still playing with my try_cmpxchg() patches, how does the below look on
top?
---
--- a/kernel/task_work.c
+++ b/kernel/task_work.c
@@ -27,14 +27,13 @@ static struct callback_head work_exited;
int
task_work_add(struct task_struct *task, struct callback_head *work, bool notify)
{
- struct callback_head *head;
+ struct callback_head *head = READ_ONCE(tsk->task_works);
do {
- head = READ_ONCE(task->task_works);
if (unlikely(head == &work_exited))
return -ESRCH;
work->next = head;
- } while (cmpxchg(&task->task_works, head, work) != head);
+ } while (!try_cmpxchg(&task->task_works, &head, work))
if (notify)
set_notify_resume(task);
@@ -90,26 +89,24 @@ task_work_cancel(struct task_struct *tas
void task_work_run(void)
{
struct task_struct *task = current;
- struct callback_head *work, *head, *next;
+ struct callback_head *work, *next;
for (;;) {
- /*
- * work->func() can do task_work_add(), do not set
- * work_exited unless the list is empty.
- */
- do {
- head = NULL;
- work = READ_ONCE(task->task_works);
- if (!work) {
- if (task->flags & PF_EXITING)
- head = &work_exited;
- else
- break;
- }
- } while (cmpxchg(&task->task_works, work, head) != work);
+ work = READ_ONCE(task->task_works);
+ if (!work) {
+ if (!(task->flags & PF_EXITING))
+ return;
+
+ /*
+ * work->func() can do task_work_add(), do not set
+ * work_exited unless the list is empty.
+ */
+ if (try_cmpxchg(&task->task_works, &work, &work_exited))
+ return;
+ }
+
+ work = xchg(&task->task_works, NULL);
- if (!work)
- break;
/*
* Synchronize with task_work_cancel(). It can not remove
* the first entry == work, cmpxchg(task_works) must fail.
^ permalink raw reply
* Re: [PATCH v3 0/3] Introduce per-task latency_nice for scheduler hints
From: chris hyser @ 2020-02-20 16:34 UTC (permalink / raw)
To: Qais Yousef
Cc: Parth Shah, vincent.guittot, patrick.bellasi, valentin.schneider,
dhaval.giani, dietmar.eggemann, linux-kernel, peterz, mingo,
pavel, qperret, David.Laight, pjt, tj
In-Reply-To: <20200220150343.dvweamfnk257pg7z@e107158-lin.cambridge.arm.com>
On 2/20/20 10:03 AM, Qais Yousef wrote:
> On 02/20/20 09:30, chris hyser wrote:
>>> The below diff works out well enough in-order to align permission checks
>>> with NICE.
>>>
>>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>>> index 2bfcff5623f9..ef4a397c9170 100644
>>> --- a/kernel/sched/core.c
>>> +++ b/kernel/sched/core.c
>>> @@ -4878,6 +4878,10 @@ static int __sched_setscheduler(struct task_struct *p,
>>> return -EINVAL;
>>> if (attr->sched_latency_nice < MIN_LATENCY_NICE)
>>> return -EINVAL;
>>> + /* Use the same security checks as NICE */
>>> + if (attr->sched_latency_nice < p->latency_nice &&
>>> + !can_nice(p, attr->sched_latency_nice))
>>> + return -EPERM;
>>> }
>>>
>>> if (pi)
>>>
>>> With the above in effect,
>>> A non-root user can only increase the value upto +19, and once increased
>>> cannot be decreased. e.g., a user once sets the value latency_nice = 19,
>>> the same user cannot set the value latency_nice = 18. This is the same
>>> effect as with NICE.
>>>
>>> Is such permission checks required?
>>>
>>> Unlike NICE, we are going to use latency_nice for scheduler hints only, and
>>> so won't it make more sense to allow a user to increase/decrease the values
>>> of their owned tasks?
>>
>> Whether called a hint or not, it is a trade-off to reduce latency of select
>> tasks at the expense of the throughput of the other tasks in the the system.
>
> Does it actually affect the throughput of the other tasks? I thought this will
> allow the scheduler to reduce latencies, for instance, when selecting which cpu
> it should land on. I can't see how this could hurt other tasks.
This is why it is hard to argue about pure abstractions. The primary idea mentioned so far for how these latencies are
reduced is by short cutting the brute-force search for something idle. If you don't find an idle cpu because you didn't
spend the time to look, then you pre-empted a task, possibly with a large nice warm cache footprint that was cranking
away on throughput. It is ultimately going to be the usual latency vs throughput trade off. If latency reduction were
"free" we wouldn't need a per task attribute. We would just do the reduction for all tasks, everywhere, all the time.
>
> Can you expand on the scenario you have in mind please?
Hopefully, the above helps. It was my original plan to introduce this with a data laden RFC on the topic, but I felt the
need to respond to Parth immediately. I'm not currently pushing any particular change.
-chrish
^ permalink raw reply
* Re: crash on connect
From: Jens Axboe @ 2020-02-20 16:38 UTC (permalink / raw)
To: Glauber Costa; +Cc: io-uring, Avi Kivity
In-Reply-To: <CAD-J=zbRDiK2PfXW4B=gHjKtqX1SdXHHne9TsD-NVvp-uznkHg@mail.gmail.com>
On 2/20/20 9:34 AM, Glauber Costa wrote:
> On Thu, Feb 20, 2020 at 11:29 AM Jens Axboe <axboe@kernel.dk> wrote:
>>
>> On 2/20/20 9:17 AM, Jens Axboe wrote:
>>> On 2/20/20 7:19 AM, Glauber Costa wrote:
>>>> Hi there, me again
>>>>
>>>> Kernel is at 043f0b67f2ab8d1af418056bc0cc6f0623d31347
>>>>
>>>> This test is easier to explain: it essentially issues a connect and a
>>>> shutdown right away.
>>>>
>>>> It currently fails due to no fault of io_uring. But every now and then
>>>> it crashes (you may have to run more than once to get it to crash)
>>>>
>>>> Instructions are similar to my last test.
>>>> Except the test to build is now "tests/unit/connect_test"
>>>> Code is at git@github.com:glommer/seastar.git branch io-uring-connect-crash
>>>>
>>>> Run it with ./build/release/tests/unit/connect_test -- -c1
>>>> --reactor-backend=uring
>>>>
>>>> Backtrace attached
>>>
>>> Perfect thanks, I'll take a look!
>>
>> Haven't managed to crash it yet, but every run complains:
>>
>> got to shutdown of 10 with refcnt: 2
>> Refs being all dropped, calling forget for 10
>> terminate called after throwing an instance of 'fmt::v6::format_error'
>> what(): argument index out of range
>> unknown location(0): fatal error: in "unixdomain_server": signal: SIGABRT (application abort requested)
>>
>> Not sure if that's causing it not to fail here.
>
> Ok, that means it "passed". (I was in the process of figuring out
> where I got this wrong when I started seeing the crashes)
Can you do, in your kernel dir:
$ gdb vmlinux
[...]
(gdb) l *__io_queue_sqe+0x4a
and see what it says?
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH 01/13] HACK: Ensure __NR_userfaultfd is defined
From: Paolo Bonzini @ 2020-02-20 16:38 UTC (permalink / raw)
To: Andrew Jones, kvm; +Cc: bgardon, borntraeger, frankja, thuth, peterx
In-Reply-To: <20200214145920.30792-2-drjones@redhat.com>
On 14/02/20 15:59, Andrew Jones wrote:
> Without this hack kvm/queue kvm selftests don't compile for x86_64.
> ---
> tools/testing/selftests/kvm/demand_paging_test.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/tools/testing/selftests/kvm/demand_paging_test.c b/tools/testing/selftests/kvm/demand_paging_test.c
> index df1fc38b4df1..ec8860b70129 100644
> --- a/tools/testing/selftests/kvm/demand_paging_test.c
> +++ b/tools/testing/selftests/kvm/demand_paging_test.c
> @@ -20,6 +20,10 @@
> #include <linux/bitops.h>
> #include <linux/userfaultfd.h>
>
> +#ifndef __NR_userfaultfd
> +#define __NR_userfaultfd 282
> +#endif
> +
> #include "test_util.h"
> #include "kvm_util.h"
> #include "processor.h"
>
This is because we're getting a limited version of
asm/unistd.h from tools/arch/x86/include/asm/unistd_64.h.
So:
------------ 8< ----------------
From: Paolo Bonzini <pbonzini@redhat.com>
Subject: [PATCH] fixup! KVM: selftests: Add demand paging content to the demand paging test
Without this, kvm selftests don't compile for x86_64 on old-enough
userspace.
diff --git a/tools/arch/x86/include/asm/unistd_64.h b/tools/arch/x86/include/asm/unistd_64.h
index cb52a3a8b8fc..4205ed4158bf 100644
--- a/tools/arch/x86/include/asm/unistd_64.h
+++ b/tools/arch/x86/include/asm/unistd_64.h
@@ -1,4 +1,7 @@
/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __NR_userfaultfd
+#define __NR_userfaultfd 282
+#endif
#ifndef __NR_perf_event_open
# define __NR_perf_event_open 298
#endif
diff --git a/tools/testing/selftests/kvm/demand_paging_test.c b/tools/testing/selftests/kvm/demand_paging_test.c
index df1fc38b4df1..dd6c5ee56201 100644
--- a/tools/testing/selftests/kvm/demand_paging_test.c
+++ b/tools/testing/selftests/kvm/demand_paging_test.c
@@ -13,6 +13,7 @@
#include <stdlib.h>
#include <sys/syscall.h>
#include <unistd.h>
+#include <asm/unistd.h>
#include <time.h>
#include <poll.h>
#include <pthread.h>
@@ -24,6 +25,8 @@
#include "kvm_util.h"
#include "processor.h"
+#ifdef __NR_userfaultfd
+
/* The memory slot index demand page */
#define TEST_MEM_SLOT_INDEX 1
@@ -678,3 +681,15 @@ int main(int argc, char *argv[])
return 0;
}
+
+#else /* __NR_userfaultfd */
+
+#warning "missing __NR_userfaultfd definition"
+
+int main(void)
+{
+ printf("skip: Skipping userfaultfd test (missing __NR_userfaultfd)\n");
+ return KSFT_SKIP;
+}
+
+#endif /* __NR_userfaultfd */
Paolo
^ permalink raw reply related
* [Intel-gfx] ✗ Fi.CI.SPARSE: warning for Refactor Gen11+ SAGV support
From: Patchwork @ 2020-02-20 16:38 UTC (permalink / raw)
To: Stanislav Lisovskiy; +Cc: intel-gfx
In-Reply-To: <20200220120741.6917-1-stanislav.lisovskiy@intel.com>
== Series Details ==
Series: Refactor Gen11+ SAGV support
URL : https://patchwork.freedesktop.org/series/73703/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: drm/i915: Start passing latency as parameter
Okay!
Commit: drm/i915: Introduce skl_plane_wm_level accessor.
Okay!
Commit: drm/i915: Init obj state in intel_atomic_get_old/new_global_obj_state
Okay!
Commit: drm/i915: Refactor intel_can_enable_sagv
+drivers/gpu/drm/i915/intel_pm.c:3851:6: warning: symbol 'intel_compute_sagv_mask' was not declared. Should it be static?
+drivers/gpu/drm/i915/intel_pm.c:3905:6: warning: symbol 'intel_calculate_sagv_result' was not declared. Should it be static?
Commit: drm/i915: Added required new PCode commands
Okay!
Commit: drm/i915: Restrict qgv points which don't have enough bandwidth.
Okay!
Commit: drm/i915: Enable SAGV support for Gen12
Okay!
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ 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.