On Wed, Oct 07, 2020 at 09:41:17PM +0200, Corentin Labbe wrote:
> I have added CONFIG_FTRACE=y and your second patch.
> The boot log can be seen at http://kernel.montjoie.ovh/108789.log
>
> But it seems the latest dump_stack addition flood a bit.
Heh, sorry for making it spew, there wasn't such
Heiner
On 10/8/20 11:51 AM, Heiner Kallweit wrote:
On 08.10.2020 18:23, Dan Murphy wrote:
The DP83TD510E is an ultra-low power Ethernet physical layer transceiver
that supports 10M single pair cable.
The device supports both 2.4-V p2p and 1-V p2p output voltage as defined
by IEEE 802.3cg
I report a array-index-out-of-bounds bug (in linux-5.9.0-rc6) found by
kernel fuzz.
kernel config:
https://github.com/butterflyhack/syzkaller-fuzz/blob/master/v5.9.0-rc6-config
and can reproduce.
the dmtree_t is that
typedef union dmtree {
struct dmaptree t1;
struct dmapctl t2;
} dmtree_t;
On Wed, Oct 7, 2020 at 12:54 PM Borislav Petkov wrote:
>
> On Wed, Oct 07, 2020 at 11:53:15AM -0700, Dan Williams wrote:
> > Oh nice! I just sent a patch [1] to fix this up as well,
>
> Yeah, for some reason it took you a while to see it - wondering if your
> mail servers are slow again.
>
> >
On Thu, 8 Oct 2020, Serge Semin wrote:
> > > At least I don't see a decent reason to preserve them. The memory
> > > registration
> > > method does nearly the same sanity checks. The memory reservation function
> > > defers a bit in adding the being reserved memory first. That seems
> > >
On Thu, 08 Oct 2020 10:07:20 +0200 Bjørn Mork wrote:
> Wilken Gottwalt writes:
> > Add usb ids of the Cellient MPL200 card.
> >
> > Signed-off-by: Wilken Gottwalt
> > ---
> > drivers/net/usb/qmi_wwan.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/net/usb/qmi_wwan.c
Writing a new value of 3 to /proc/sys/kernel/randomize_va_space
enables full randomization of memory mappings created with mmap(NULL,
...). With 2, the base of the VMA used for such mappings is random,
but the mappings are created in predictable places within the VMA and
in sequential order. With
NXP lab almost always down? I have a branch
> now to test things and I'm not done breaking the DWC driver. :)
Now the NXP LAVA lab is back online after upgrade.
LKFT running daily testing on device "nxp-ls2088" [1]
You can monitor and check results on Linaro Linux next project [2]
[1] https://lavalab.nxp.com/scheduler/device_type/nxp-ls2088
[2]
https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20201008/?results_layout=table_only=false#!?details=995,999#test-results
- Naresh
On 10/8/2020 12:39 AM, Thomas Gleixner wrote:
On Wed, Oct 07 2020 at 14:54, Dave Jiang wrote:
On 9/30/2020 12:57 PM, Thomas Gleixner wrote:
Aside of that this is fiddling in the IMS storage array behind the irq
chips back without any comment here and a big fat comment about the
shared usage
On 08.10.2020 18:23, Dan Murphy wrote:
> The DP83TD510E is an ultra-low power Ethernet physical layer transceiver
> that supports 10M single pair cable.
>
> The device supports both 2.4-V p2p and 1-V p2p output voltage as defined
> by IEEE 802.3cg 10Base-T1L specfications. These modes can be
On 10/8/2020 8:54 AM, Serge Semin wrote:
On Thu, Oct 08, 2020 at 04:30:35PM +0100, Maciej W. Rozycki wrote:
On Thu, 8 Oct 2020, Serge Semin wrote:
At least I don't see a decent reason to preserve them. The memory registration
method does nearly the same sanity checks. The memory
On Wed, 7 Oct 2020 18:44:21 +0200
Daniel Vetter wrote:
> Way back it was a reasonable assumptions that iomem mappings never
> change the pfn range they point at. But this has changed:
>
> - gpu drivers dynamically manage their memory nowadays, invalidating
> ptes with unmap_mapping_range when
On 10/7/20 10:17 PM, Ram Pai wrote:
On Thu, Oct 01, 2020 at 11:17:15AM -0700, Ralph Campbell wrote:
ZONE_DEVICE struct pages have an extra reference count that complicates the
code for put_page() and several places in the kernel that need to check the
reference count to see that a page is not
With threadirqs, stmmac_interrupt() is called on a thread with hardirqs
enabled so we cannot call __napi_schedule_irqoff(). Under lockdep it
leads to:
[ cut here ]
WARNING: CPU: 0 PID: 285 at kernel/softirq.c:598
__raise_softirq_irqoff+0x6c/0x1c8
Hi Sorry there were some typos and errors in my response so I'll correct them
below:
> -Original Message-
> From: Ben Levinsky
> Sent: Thursday, October 8, 2020 7:21 AM
> To: Linus Walleij ; Catalin Marinas
> ; Stefano Stabellini ; Ed T.
> Mooring
> Cc: Ed T. Mooring ;
Hi,
On Wed, Oct 7, 2020 at 2:40 PM Doug Anderson wrote:
>
> Hi,
>
> On Wed, Oct 7, 2020 at 6:26 AM Rob Herring wrote:
> >
> > On Tue, Oct 6, 2020 at 8:17 PM Doug Anderson wrote:
> > >
> > > Hi,
> > >
> > > On Tue, Oct 6, 2020 at 3:24 PM Rob Herring wrote:
> > > >
> > > > On Fri, Oct 2, 2020
Hi,
This series adds blktests for the nvmet passthru feature that was merged
for 5.9. It's been reconciled with Sagi's blktest series that Omar
recently merged.
This series is based off of the current blktests master and a git repo is
available for this here:
On Thu, Oct 08, 2020 at 10:52:04AM +0100, Colin King wrote:
> From: Colin Ian King
>
> An incorrect sizeof is being used, struct rvt_ibport ** is not correct,
> it should be struct rvt_ibport *. Note that since ** is the same size as
> * this is not causing any issues. Improve this fix by using
Instead of each individual test removing this file, just do it
in the common helper.
Signed-off-by: Logan Gunthorpe
Reviewed-by: Chaitanya Kulkarni
---
common/fio | 1 +
tests/nvme/010 | 1 -
tests/nvme/011 | 1 -
tests/nvme/012 | 1 -
tests/nvme/013 | 1 -
5 files changed, 1 insertion(+),
This tests creates and connects to a passthru controller backed
by a test NVMe namespace. It then verifies that some common fields
in id-ctrl and id-ns are the same in the target and the orginial
device.
Signed-off-by: Logan Gunthorpe
---
tests/nvme/033 | 67
On Thu, Oct 08, 2020 at 06:22:06PM +0200, Enric Balletbo i Serra wrote:
> As part of KernelCI, we added a bunch of different x86 based Chromebooks
> to do test booting and runtime testing. It will be useful have serial
> support for these platforms in the default defconfig, as this, is the
>
Make a common helper from the code in tests nvme/012 and nvme/013
to run an fio verify on a XFS file system backed by the
specified block device.
While we are at it, all the output is redirected to $FULL instead of
/dev/null.
Signed-off-by: Logan Gunthorpe
---
common/xfs | 22
Two nvme tests create and mount XFS filesystems and check for mkfs.xfs.
They should also check for XFS support in the kernel so create a common
helper for this.
Signed-off-by: Logan Gunthorpe
---
common/rc | 8
common/xfs | 11 +++
tests/nvme/012 | 6 --
Test that we can remove a subsystem that has not been enabled by
passthru or any ns. Do the same for ports while we are at it.
This was an issue in the original passthru patches and is
not commonly tested. So this test will ensure we don't regress this.
Signed-off-by: Logan Gunthorpe
---
Add some simple helpers to setup a passthru target that passes through
to a nvme test device.
Signed-off-by: Logan Gunthorpe
---
tests/nvme/rc | 75 +++
1 file changed, 75 insertions(+)
diff --git a/tests/nvme/rc b/tests/nvme/rc
index
Similar to test nvme/031 except for passthru controllers.
Note: it's normal to get I/O errors in this test as when the controller
disconnects it races with the partition table read.
Signed-off-by: Logan Gunthorpe
---
tests/nvme/037 | 35 +++
This ensures we find the correct nvme loop device if others exist on a
given system (which is generally not expected on test systems).
Additionally, this will be required in the upcomming test nvme/037 which
will have controllers racing with ones being destroyed.
Signed-off-by: Logan Gunthorpe
This is a similar test as nvme/012 and nvme/013, except with a
passthru controller.
Signed-off-by: Logan Gunthorpe
---
tests/nvme/035 | 37 +
tests/nvme/035.out | 3 +++
2 files changed, 40 insertions(+)
create mode 100755 tests/nvme/035
create mode
Similar to test 022 but for passthru controllers.
Signed-off-by: Logan Gunthorpe
---
tests/nvme/036 | 37 +
tests/nvme/036.out | 3 +++
2 files changed, 40 insertions(+)
create mode 100755 tests/nvme/036
create mode 100644 tests/nvme/036.out
diff
Similar to test nvme/010 and nvme/011 but for a passthru controller
Signed-off-by: Logan Gunthorpe
---
tests/nvme/034 | 35 +++
tests/nvme/034.out | 3 +++
2 files changed, 38 insertions(+)
create mode 100755 tests/nvme/034
create mode 100644
On Thu, 2020-10-08 at 10:32 +0800, Kai-Heng Feng wrote:
> Hi Lyude,
>
> > On Oct 8, 2020, at 05:53, Lyude Paul wrote:
> >
> > Hi! I thought this patch rang a bell, we actually already had some
> > discussion
> > about this since there's a couple of other systems this was causing issues
> > for.
On Mon, 2020-10-05 at 10:41 +0200, Christoph Hellwig wrote:
> Hi Martin,
>
> this series tidies up various loose ends in the SCSI I/O submission path.
Reverting this patchset on the top of today's linux-next fixed the boot failures
below with libata, i.e.,
git revert --no-edit
On Thu, Oct 8, 2020 at 9:47 AM Calvin Johnson
wrote:
>
> Better place for of_mdio.c is drivers/net/mdio.
> Move of_mdio.c from drivers/of to drivers/net/mdio
One thing off my todo list. I'd started this ages ago[1].
>
> Signed-off-by: Calvin Johnson
> ---
>
> MAINTAINERS
Bjorn,
Any comments on this? I would like to know if there is any chances of
taking this patch for v5.10 merge window?
Thanks,
Kathiravan T.
On 9/17/2020 7:26 PM, Kathiravan T wrote:
Lets enable the APSS clock driver for the DVFS support.
Signed-off-by: Kathiravan T
---
Running a kernel on a R3k of machine definitly will never see one of
the newer CPU cores. And since R3k system usually are low on memory
we could save quite some kbytes:
textdata bss dec hex filename
15070 88 32 151903b56 arch/mips/kernel/cpu-probe.o
844
cpu-probe.c has grown when supporting more and more CPUs and there
are use cases where probing for all the CPUs isn't useful like
running on a R3k system. But still the fpu handling is nearly
the same. For sharing put the fpu code into it's own file.
Signed-off-by: Thomas Bogendoerfer
---
The DP83TD510E is an ultra-low power Ethernet physical layer transceiver
that supports 10M single pair cable.
The device supports both 2.4-V p2p and 1-V p2p output voltage as defined
by IEEE 802.3cg 10Base-T1L specfications. These modes can be forced via
the device tree or the device is defaulted
The DP83TD510 is a 10M single twisted pair Ethernet PHY
Signed-off-by: Dan Murphy
---
.../devicetree/bindings/net/ti,dp83td510.yaml | 70 +++
1 file changed, 70 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/ti,dp83td510.yaml
diff --git
Hello
The DP83TD510 is an Ethernet PHY supporting single pair of twisted wires. The
PHY is capable of 10Mbps communication over long distances and exceeds the
IEEE 802.3cg 10BASE-T1L single-pair Ethernet specification. The PHY supports
various voltage level signalling and can be forced to
As part of KernelCI, we added a bunch of different x86 based Chromebooks
to do test booting and runtime testing. It will be useful have serial
support for these platforms in the default defconfig, as this, is the
defconfig used by default for the different maintainer's tree.
SERIAL_8250_DW is the
Hello
The DP83TD510 is an Ethernet PHY supporting single pair of twisted wires. The
PHY is capable of 10Mbps communication over long distances and exceeds the
IEEE 802.3cg 10BASE-T1L single-pair Ethernet specification. The PHY supports
various voltage level signalling and can be forced to
Hi "Christian,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on staging/staging-testing linux/master linus/master
v5.9-rc8 next-20201008]
[cannot apply to mmotm/master]
[If your patch is applied to the wrong git
On Thu, Oct 08, 2020 at 11:30:02AM -0400, Arvind Sankar wrote:
> I'm working on a couple of separate series to clean up cmdline
> and the compressed boot code a bit. I was actually planning to
> get rid of boot/compressed/cmdline.c entirely, replacing it with
> arch/x86/lib/cmdline.c instead:
The
On Thu, Oct 08, 2020 at 03:33:50PM +0100, Matteo Franchin wrote:
> Add ABGR format with 10-bit components packed in 64-bit per pixel.
> This format can be used to handle
> VK_FORMAT_R10X6G10X6B10X6A10X6_UNORM_4PACK16 on little-endian
> architectures.
>
> Signed-off-by: Matteo Franchin
Ok so
> Subject: [PATCH v1 net-next] net: stmmac: Enable EEE HW LPI timer with auto
> SW/HW switching
>
> From: "Vineetha G. Jaya Kumaran"
>
> This patch enables the HW LPI Timer which controls the automatic entry and
> exit of the LPI state.
> The EEE LPI timer value is configured through ethtool.
On 08/10/2020 16:02, Alexandre Courbot wrote:
> Hi Hans, thanks for taking the time to look at this!
>
> On Thu, Oct 8, 2020 at 10:12 PM Hans Verkuil wrote:
>>
>> On 08/10/2020 15:07, Hans Verkuil wrote:
>>> Hi Alexandre,
>>>
>>> On 04/10/2020 14:22, Alexandre Courbot wrote:
The addition of
If riov and wiov are both defined and they point to different
objects, only riov is initialized. If the wiov is not initialized
by the caller, the function fails returning -EINVAL and printing
"Readable desc 0x... after writable" error message.
Let's replace the 'else if' clause with 'if' to
From: "Vineetha G. Jaya Kumaran"
This patch enables the HW LPI Timer which controls the automatic entry
and exit of the LPI state.
The EEE LPI timer value is configured through ethtool. The driver will
auto select the LPI HW timer if the value in the HW timer supported range.
Else, the driver
On Thu, 2020-10-08 at 13:55 +0100, David Woodhouse wrote:
>
> In fact I'm really tempted to make Linux's io_apic.c just use
> irq_chip_compose_msi_msg() and swizzle the bits out of the message
> identically for IR and non-IR alike (modulo the pin hack), and delete
> the IR_IO_APIC_route_entry
On Thursday 08 Oct 2020 at 17:18:25 (+0200), Rafael J. Wysocki wrote:
> On Thu, Oct 8, 2020 at 4:06 PM Sudeep Holla wrote:
> >
> > On Wed, Oct 07, 2020 at 04:34:44PM +0200, Rafael J. Wysocki wrote:
> > > On Thu, Sep 24, 2020 at 2:30 PM Ionela Voinescu
> > > wrote:
> > > >
> > > > This series is
> "Sagar" == Sagar Kadam writes:
> Hello Peter,
>> Are both affected by this issue? if not, we will need to extend the code
>> to handle them differently.
>>
> No, this issue is present in FU540-C000 SoC i.e SoC- specific, and so I can
> check
> for the soc-compatible string as
On Wed, 7 Oct 2020 16:31:51 -0700
John Hubbard wrote:
> sysfs-pci and sysfs-tagging were mis-filed: their locations with
> Documentation/ implied that they were related to file systems. Actually,
> each topic is about a very specific *use* of sysfs, and sysfs *happens*
> to be a (virtual)
On Thu, Oct 08, 2020 at 05:13:15PM +0200, Maxime Ripard wrote:
> Hi,
>
> On Tue, Sep 29, 2020 at 10:30:25AM +0200, Michal Suchanek wrote:
> > The flash is present on all new boards and users went out of their way
> > to add it on the old ones.
> >
> > Enabling it makes a more reasonable default.
07.10.2020 04:44, Sean Christopherson пишет:
Two bug fixes to handle KVM_SET_SREGS without a preceding KVM_SET_CPUID2.
Hi Sean & KVM devs.
I tested the patches, and wherever I
set VMXE in CR4, I now get
KVM: KVM_SET_SREGS: Invalid argument
Before the patch I was able (with many
problems, but
On Thu, Oct 8, 2020 at 8:53 AM Christoph Hellwig wrote:
>
> All user of the pnp_find_card compat wrapper are gone, so remove
> the function as well.
>
> Signed-off-by: Christoph Hellwig
> ---
> Documentation/admin-guide/pnp.rst | 4
> drivers/pnp/isapnp/compat.c | 23
On Thu, Oct 8, 2020 at 3:20 AM Christian König wrote:
>
> Am 07.10.20 um 18:01 schrieb Gustavo A. R. Silva:
> > Hi all,
> >
> > This series aims to replace one-element arrays with flexible-array
> > members.
> >
> > There is a regular need in the kernel to provide a way to declare having
> > a
Hi Viresh and Ionela,
@Viresh, I am sorry it's still not crystal clear, please find an example below.
@Ionela, thanks for adding more details.
On 10/8/20 4:03 PM, Ionela Voinescu wrote:
> Hi Viresh,
>
> On Thursday 08 Oct 2020 at 16:32:41 (+0530), Viresh Kumar wrote:
>> On 07-10-20, 13:58,
On Thu, Oct 8, 2020 at 5:03 PM Ionela Voinescu wrote:
>
> Hi Viresh,
>
> On Thursday 08 Oct 2020 at 16:32:41 (+0530), Viresh Kumar wrote:
> > On 07-10-20, 13:58, Nicola Mazzucato wrote:
> > > Hi Viresh,
> > >
> > > performance controls is what is exposed by the firmware through a
> > > protocol
On Thu, Oct 8, 2020 at 7:55 AM Johannes Weiner wrote:
>
> On Tue, Oct 06, 2020 at 09:55:43AM -0700, Shakeel Butt wrote:
> > On Thu, Oct 1, 2020 at 7:33 AM Johannes Weiner wrote:
> > >
> > [snip]
> > > > >So instead of asking users for a target size whose suitability
> > > > >heavily
On Thu, Oct 08, 2020 at 05:45:58PM +0200, Arnd Bergmann wrote:
> The ebsa110 platform is the last thing that uses
> CONFIG_ARCH_USES_GETTIMEOFFSET, and Russell has previously said that he
> thinks the platform can be retired now.
>
> Removing it allows us clean up the timer code by throwing out
On Thu, Oct 08, 2020 at 04:30:35PM +0100, Maciej W. Rozycki wrote:
> On Thu, 8 Oct 2020, Serge Semin wrote:
>
> > At least I don't see a decent reason to preserve them. The memory
> > registration
> > method does nearly the same sanity checks. The memory reservation function
> > defers a bit in
On Thu, Oct 08, 2020 at 05:24:03PM +0200, Jan Engelhardt wrote:
> In the case of the RDMA headers, even if we assume best conditions --
> a block of malloc(sizeof(struct ib_uverbs_create_cq_resp) +
> sizeof(u64)*N) and not some struct -- it smells a lot like undefined
> behavior, because
Now that the infrastructure allows kernels to have both legacy timer
ticks and clockevent drivers in the same image, start by moving one
platform to generic clockevents.
As qemu only supports the q800 platform among the classic m68k, use
that as an example.
I also tried adding oneshot mode,
There are no more users of xtime_update aside from legacy_timer_tick(),
so fold it into that function and remove the declaration.
update_process_times() is now only called inside of the kernel/time/
code, so the declaration can be moved there.
Signed-off-by: Arnd Bergmann
---
On Wed, 7 Oct 2020, Lokesh Gidra wrote:
> Is there anything else that needs to be done before merging this
> patch series? I urge the reviewers to please take a look.
>
It looks generally fine to me from a security POV, we really need some
feedback from VFS folk.
--
James Morris
There are nine more machines that each have their own timer interrupt
calling the m68k timer_interrupt() function through an indirect pointer.
This function is now the same as legacy_timer_tick, so just call that
directly and select the corresponding Kconfig symbol.
Signed-off-by: Arnd Bergmann
When change sched_rt_{runtime, period}_us, we validate that the new
settings should at least accommodate the currently allocated -dl
bandwidth:
sched_rt_handler()
--> sched_dl_bandwidth_validate()
{
new_bw = global_rt_runtime()/global_rt_period();
Almost all machines use GENERIC_CLOCKEVENTS, so it feels wrong to
require each one to select that symbol manually.
Instead, enable it whenever CONFIG_LEGACY_TIMER_TICK is disabled as
a simplification. It should be possible to select both
GENERIC_CLOCKEVENTS and LEGACY_TIMER_TICK from an
This gets passed to a number of init functions, but is
ignored everywhere, so remove the function and change the
mach_sched_init callback to take no arguments.
Signed-off-by: Arnd Bergmann
---
arch/m68k/68000/timers.c| 2 +-
arch/m68k/amiga/config.c| 4 ++--
These two are different from all other machines:
* sun3 does not call timer_routine() but open-codes it
except for the profile_tick() call that appears to
be unintentionally missing.
* sun3x has a commented-out timer irq handler but no
functional timer tick I could find.
Change both to
When I created the patch removing CONFIG_ARCH_GETTIMEOFFSET,
I also had a look at CONFIG_GENERIC_CLOCKEVENTS, which is
selected by most, but not all, platforms today, each of the
ones that lack it doing the timer tick slightly differently.
The cleanups here make the old platforms a bit more
Replace the indirect function calls in the timer code
with direct calls to the newly added legacy_timer_tick()
helper for those that have not yet been converted to
generic clockevents.
This makes the timer code a little more self-contained.
Signed-off-by: Arnd Bergmann
---
The heartbeat functionality is mostly separate from the
actual timer interrupt handling, and it is only used on
five platforms.
Split it out into a separate function and call that directly
from the timer irq on those platforms.
Signed-off-by: Arnd Bergmann
---
arch/m68k/amiga/config.c|
rpc is the only user of the timer_tick() function now, and can
just call the newly added generic version instead.
Signed-off-by: Arnd Bergmann
---
arch/arm/Kconfig | 1 +
arch/arm/include/asm/mach/time.h | 2 --
arch/arm/kernel/time.c | 14 --
Under CONFIG_SMP, dl_bw is per root domain, but not per CPU.
When checking or updating dl_bw, currently iterating every CPU is
overdoing, just need iterate each root domain once.
Suggested-by: Peter Zijlstra
Signed-off-by: Peng Liu
---
kernel/sched/deadline.c | 39
A couple of machines share the m68328 timer code that
is based on calling timer_interrupt(). Change these
to the new and slightly more generic legacy_timer_tick()
helper.
Signed-off-by: Arnd Bergmann
---
arch/m68k/68000/timers.c | 5 ++---
arch/m68k/Kconfig.machine | 4
2 files changed, 6
parisc has selected CONFIG_GENERIC_CLOCKEVENTS since commit 43b1f6abd590
("parisc: Switch to generic sched_clock implementation"), but does not
appear to actually be using it, and instead calls the low-level
timekeeping functions directly.
Remove the GENERIC_CLOCKEVENTS select again, and instead
All platforms that currently do not use generic clockevents roughly call
the same set of functions in their timer interrupts: xtime_update(),
update_process_times() and profile_tick(), sometimes in a different
sequence.
Add a helper function that performs all three of them, to make the
callers
ia64 is the only architecture that calls xtime_update() in a loop,
once for each jiffie that has passed since the last event.
Before commit 3171a0305d62 ("[PATCH] simplify update_times (avoid
jiffies/jiffies_64 aliasing problem)") in 2006, it could not actually do
this any differently, but now it
With Arm EBSA110 gone, nothing uses it any more, so the corresponding
code and the Kconfig option can be removed.
Signed-off-by: Arnd Bergmann
---
.../time/modern-timekeeping/arch-support.txt | 33 ---
drivers/Makefile | 2 --
This driver was only used on the EBSA110 platform, which is now
getting removed, so the driver is no longer needed either.
Signed-off-by: Arnd Bergmann
---
drivers/net/ethernet/amd/Kconfig | 10 +-
drivers/net/ethernet/amd/Makefile| 1 -
drivers/net/ethernet/amd/am79c961a.c | 763
When change global rt bandwidth, we check to make sure that new
settings could accommodate the allocated dl bandwidth.
Under SMP, the dl_bw is on a per root domain basis, currently we check
and update the new settings one cpu by one cpu, but not in the unit of
root domain, which is either
The ebsa110 platform is the last thing that uses
CONFIG_ARCH_USES_GETTIMEOFFSET, and Russell has previously said that he
thinks the platform can be retired now.
Removing it allows us clean up the timer code by throwing out all of
the references to arch_gettimeoffset().
The am79c961a network
Use per_cpu_ptr_to_phys() instead of virt_to_phys() and __pa()
for per-cpu address conversion.
In xen_starting_cpu(), per-cpu xen_vcpu_info address is converted
to gfn by virt_to_gfn() macro. However, since the virt_to_gfn(v)
assumes the given virtual address is in linear mapped kernel memory
Russell said that he is no longer using this machine, and it seems that
nobody else has in a long time, so it's time to say goodbye to it.
As this is the last platform using CONFIG_ARCH_USES_GETTIMEOFFSET,
there are some follow-up patches to remove that as well.
Signed-off-by: Arnd Bergmann
---
On Mon, Oct 5, 2020 at 9:03 AM Kent Gibson wrote:
>
> I'm intending to add some GPIO chardev documentation to
> Documentation/admin-guide/gpio/chardev.rst (or perhaps
> Documentation/userspace-api/??), but that is taking longer than I'd like,
> so in the meantime here is a collection of minor
On Wed, Oct 7, 2020 at 12:05 PM Gustavo A. R. Silva
wrote:
>
> There is a regular need in the kernel to provide a way to declare having
> a dynamically sized set of trailing elements in a structure. Kernel code
> should always use “flexible array members”[1] for these cases. The older
> style of
On Thu, Oct 08, 2020 at 11:30:28AM -0400, Jerome Glisse wrote:
> On Wed, Oct 07, 2020 at 11:09:16PM +0100, Matthew Wilcox wrote:
> > So ... why don't you put a PageKsm page in the page cache? That way you
> > can share code with the current KSM implementation. You'd need
> > something like this:
From: Colin Ian King
An incorrect sizeof() is being used, sizeof(psy->supplied_from) is not
correct, it should be sizeof(*psy->supplied_from). This bug did not
cause any issues because it just so happens the sizes are the same.
Addresses-Coverity: ("Sizeof not portable (SIZEOF_MISMATCH)")
Add the bindings for the bq25790.
Reviewed-by: Rob Herring
Signed-off-by: Ricardo Rivera-Matos
Signed-off-by: Dan Murphy
---
.../bindings/power/supply/bq25790.yaml| 95 +++
1 file changed, 95 insertions(+)
create mode 100644
BQ25790 is a highly integrated switch-mode buck-boost charger
for 1-4 cell Li-ion battery and Li-polymer battery.
Signed-off-by: Ricardo Rivera-Matos
Signed-off-by: Dan Murphy
---
drivers/power/supply/Kconfig |8 +
drivers/power/supply/Makefile |1 +
On Thu, Oct 1, 2020 at 6:30 AM Andrew Jeffery wrote:
>
> Setting both CONFIG_KPROBES=y and CONFIG_FORTIFY_SOURCE=y on ARM leads
> to a panic in memcpy() when injecting a kprobe despite the fixes found
> in commit e46daee53bb5 ("ARM: 8806/1: kprobes: Fix false positive with
> FORTIFY_SOURCE") and
Hi "Christian,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on hnaz-linux-mm/master staging/staging-testing
linux/master linus/master v5.9-rc8 next-20201008]
[cannot apply to mmotm/master]
[If your patch is ap
;>>> Hello,
>>>>>
>>>>> syzbot found the following issue on:
>>>>>
>>>>> HEAD commit:e4fb79c7 Add linux-next specific files for 20201008
>>>>> git tree: linux-next
>>>>> console output: ht
From: Mickaël Salaün
The sb_delete security hook is called when shutting down a superblock,
which may be useful to release kernel objects tied to the superblock's
lifetime (e.g. inodes).
This new hook is needed by Landlock to release (ephemerally) tagged
struct inodes. This comes from the
From: Mickaël Salaün
A Landlock ruleset is mainly a red-black tree with Landlock rules as
nodes. This enables quick update and lookup to match a requested access
e.g., to a file. A ruleset is usable through a dedicated file
descriptor (cf. following commit implementing the syscall) which
From: Mickaël Salaün
A process credentials point to a Landlock domain, which is underneath
implemented with a ruleset. In the following commits, this domain is
used to check and enforce the ptrace and filesystem security policies.
A domain is inherited from a parent to its child the same way a
From: Mickaël Salaün
Add a basic sandbox tool to launch a command which can only access a
whitelist of file hierarchies in a read-only or read-write way.
Cc: James Morris
Cc: Jann Horn
Cc: Kees Cook
Cc: Serge E. Hallyn
Signed-off-by: Mickaël Salaün
---
Changes since v20:
* Update with new
From: Mickaël Salaün
Wire up the following system calls for all architectures:
* landlock_create_ruleset(2)
* landlock_add_rule(2)
* landlock_enforce_ruleset_current(2)
Cc: Arnd Bergmann
Cc: James Morris
Cc: Jann Horn
Cc: Kees Cook
Cc: Serge E. Hallyn
Signed-off-by: Mickaël Salaün
---
From: Mickaël Salaün
These 3 system calls are designed to be used by unprivileged processes
to sandbox themselves:
* landlock_create_ruleset(2): Creates a ruleset and returns its file
descriptor.
* landlock_add_rule(2): Adds a rule (e.g. file hierarchy access) to a
ruleset, identified by the
401 - 500 of 1070 matches
Mail list logo
