On 2020-06-03 5:44 a.m., Piotr Stankiewicz wrote:
> When debugging an issue where I was asking the PCI machinery to enable a
> set of MSI-X vectors, without falling back on MSI, I ran across a
> behaviour which seems odd. The pci_alloc_irq_vectors_affinity() will
> always return -ENOSPC on
Changes in v7:
- added missing perf-record.txt changes
- adjusted docs wording for --ctl-fd,ctl-fd-ack options
to additionally mention --delay=-1 effect
v6:
https://lore.kernel.org/lkml/f8e3a714-d9b1-4647-e1d2-9981cbaa8...@linux.intel.com/
Changes in v6:
- split re-factoring of events
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: d6f9469a03d832dcd17041ed67774ffb5f3e73b3
commit: 78ed001d9e7106171e0ee761cd854137dd731302 compat: scsi: sg: fix v3
compat read/write interface
date: 5 months ago
config: sh-randconfig-s031-20200603
From: Colin Ian King
There are two error return paths where the call to path_put is
dereferencing the null pointer 'stack'. Fix this by avoiding the
error exit path via label 'out_err' that will lead to the path_put
calls and instead just return the error code directly.
Addresses-Coverity:
Thomas Gleixner writes:
> Miklos Szeredi writes:
>> On Fri, May 29, 2020 at 2:31 PM Miklos Szeredi wrote:
>>
>>> > Can you please describe the setup of this test?
>>> >
>>> > - Host kernel version
>>
>> 5.5.16-100.fc30.x86_64
>>
>>> > - Guest kernel version
>>
>> 75caf310d16c ("Merge branch
On 3/06/20 3:52 pm, Alexey Budankov wrote:
>
> On 03.06.2020 15:05, Adrian Hunter wrote:
>> On 25/05/20 5:23 pm, Alexey Budankov wrote:
>>>
>>> Introduce --ctl-fd[-ack] options to pass open file descriptors numbers
>>> from command line. Extend perf-record.txt file with --ctl-fd[-ack]
>>> options
The VersaClock driver now supports some additional bindings to support
child nodes which can configure optional settings like mode, voltage
and slew.
This patch updates the binding document to describe what is available
in the driver.
Signed-off-by: Adam Ford
Reviewed-by: Rob Herring
---
V3:
Currently, the Versaclock driver is only expecting one instance and
uses hard-coded names for the various clock names. Unfortunately,
this is a problem when there is more than one instance of the driver,
because the subsequent instantiations of the driver use the identical
name. Each clock after
The existing driver is expecting the Versaclock to be pre-programmed,
and only sets the output frequency. Unfortunately, not all devices
are pre-programmed, and the Versaclock chip has more options beyond
just the frequency.
This patch enables the following additional features:
-
Miklos Szeredi writes:
> On Fri, May 29, 2020 at 2:31 PM Miklos Szeredi wrote:
>
>> > Can you please describe the setup of this test?
>> >
>> > - Host kernel version
>
> 5.5.16-100.fc30.x86_64
>
>> > - Guest kernel version
>
> 75caf310d16c ("Merge branch 'akpm' (patches from Andrew)")
>
>> >
On 6/3/20 3:12 AM, Tada, Kenta (Sony) wrote:
Once PR_SPEC_FORCE_DISABLE is set, users cannot set PR_SPEC_ENABLE.
This commit checks whether PR_SPEC_FORCE_DISABLE was previously set.
Signed-off-by: Kenta Tada
---
arch/x86/kernel/cpu/bugs.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
Improve best_map_size so that PUD or PGDIR entries are used for linear
mapping when possible as it allows better TLB utilization.
Signed-off-by: Alexandre Ghiti
---
arch/riscv/mm/init.c | 45 +---
1 file changed, 34 insertions(+), 11 deletions(-)
diff
Early page table uses the kernel load address as mapping for PAGE_OFFSET:
that makes memblock remove any memory below the kernel which results in
using only PMD entries for the linear mapping.
By setting MIN_MEMBLOCK_ADDR to 0, we allow this memory to be present
when creating the kernel page
On 6/3/20 4:03 AM, Masami Hiramatsu wrote:
Hi Stephen,
On Wed, 3 Jun 2020 18:29:01 +1000
Stephen Rothwell wrote:
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
tools/testing/selftests/sysctl/sysctl.sh
between commit:
eee470e0739a ("selftests/sysctl:
On Fri, Mar 27, 2020 at 11:31:08PM +, Al Viro wrote:
> From: Al Viro
>
> Just inline the call and use memcpy() instead of __copy_from_user() and
> note that the tail is precisely ia64 csum_partial().
>
> Signed-off-by: Al Viro
This patch results in:
arch/ia64/lib/csum_partial_copy.c: In
This small patchset intends to use PUD/PGDIR entries for linear mapping
in order to better utilize TLB.
At the moment, only PMD entries can be used since on common platforms
(qemu/unleashed), the kernel is loaded at DRAM + 2MB which dealigns virtual
and physical addresses and then prevents the
On Wed, Jun 03, 2020 at 10:06:07PM +0800, Wangshaobo (bobo) wrote:
> Today I test your fix, but arch_stack_walk_reliable() still return failed
> sometimes, I
>
> found one of three scenarios mentioned failed:
>
>
> 1. user task (just fork) but not been scheduled
>
> test FAILED
>
> it
> On Jun 3, 2020, at 8:20 AM, chenzhou wrote:
>
> Hi,
>
>
> On 2020/6/3 19:47, Prabhakar Kushwaha wrote:
>> Hi Chen,
>>
>> On Tue, Jun 2, 2020 at 8:12 PM John Donnelly
>> wrote:
>>>
>>>
On Jun 2, 2020, at 12:38 AM, Prabhakar Kushwaha
wrote:
On Tue, Jun 2, 2020 at
Hello,
syzbot found the following crash on:
HEAD commit:2089c6ed usb: core: kcov: collect coverage from usb comple..
git tree: https://github.com/google/kasan.git usb-fuzzer
console output: https://syzkaller.appspot.com/x/log.txt?x=12576bd610
kernel config:
Hello,
syzbot found the following crash on:
HEAD commit:2089c6ed usb: core: kcov: collect coverage from usb comple..
git tree: https://github.com/google/kasan.git usb-fuzzer
console output: https://syzkaller.appspot.com/x/log.txt?x=17cf6bd610
kernel config:
> A deadlock caused by logbuf_lock occurs when panic:
I suggest a few wording adjustments for this change description.
Would you like to omit an extra space character at the beginning of this
sentence?
> we try to re-init …
We …
> … deadlock, but it … here, because :
… deadlock. But it …
On Wed, 03 Jun 2020 10:24:36 -0500
Tom Zanussi wrote:
> > It appears to be the ascii art that is causing the issue. I have no
> > idea
> > how to fix it. If someone has a patch they would like to submit, I
> > will
> > take it before I push it off to Linus.
> >
> > -- Steve
>
> I just sent
Hi Pradeep,
On Wed, Jun 03, 2020 at 02:39:35PM +0530, Pradeep P V K wrote:
> Interconnect bandwidth scaling support is now added as a
> part of OPP [1]. So, make sure interconnect driver is ready
> before handling interconnect scaling.
>
> This change is based on
> [1] [Patch v8] Introduce OPP
On 6/2/2020 11:33 PM, Vinod Koul wrote:
Hi Dave,
On 01-06-20, 15:09, Dave Jiang wrote:
Vinod,
Obviously this series won't make it for 5.8 due to being blocked by
Fenghua's PASID series. Do you think you can take patches 4 and 5
independently? I think these can go into 5.8 and is not
On Tue, May 26, 2020 at 10:13:50AM +0200, Peter Zijlstra wrote:
> On Tue, May 26, 2020 at 02:52:31AM +0200, Ahmed S. Darwish wrote:
> > Peter Zijlstra wrote:
>
> > > +#define lockdep_assert_irqs_enabled()
> > > \
> > > +do {
Hi Maxime,
Am 03.06.20 um 15:14 schrieb Maxime Ripard:
> Hi Stefan,
>
> On Tue, Jun 02, 2020 at 10:03:13PM +0200, Stefan Wahren wrote:
>> Am 02.06.20 um 21:31 schrieb Eric Anholt:
>>> On Tue, Jun 2, 2020 at 8:02 AM Dave Stevenson
>>> wrote:
Hi Maxime and Eric
On Tue, 2 Jun 2020 at
Use kstrdup() instead of opencoded alloc and copy. kzalloc() is
excessive here.
Signed-off-by: Denis Efremov
---
drivers/net/xen-netback/xenbus.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index
On 03/06/20 13:45, Benjamin Gaignard wrote:
> +static void dcmi_set_min_frequency(struct stm32_dcmi *dcmi, u64 freq)
> +{
> + struct cpufreq_policy *p;
> + int cpu;
> +
> + for_each_cpu(cpu, irq_get_affinity_mask(dcmi->irq)) {
> + p = per_cpu(policy, cpu);
> +
On Wed, May 20, 2020 at 10:39:16AM +0200, Borislav Petkov wrote:
> On Tue, Apr 28, 2020 at 05:16:48PM +0200, Joerg Roedel wrote:
> > +bool sev_es_active(void)
> > +{
> > + return !!(sev_status & MSR_AMD64_SEV_ES_ENABLED);
> > +}
> > +EXPORT_SYMBOL_GPL(sev_es_active);
>
> I don't see this being
Hi Steve,
On Wed, 2020-06-03 at 11:22 -0400, Steven Rostedt wrote:
> On Wed, 3 Jun 2020 17:42:53 +1000
> Stephen Rothwell wrote:
>
> > Hi all,
> >
> > After merging the ftrace tree, today's linux-next build (htmldocs)
> > failed like this:
> >
> >
> > Sphinx parallel build error:
> >
On Wed, 3 Jun 2020 17:42:53 +1000
Stephen Rothwell wrote:
> Hi all,
>
> After merging the ftrace tree, today's linux-next build (htmldocs)
> failed like this:
>
>
> Sphinx parallel build error:
> docutils.utils.SystemMessage:
>
This fixes the Sphinx parallel build error when building htmldocs:
docutils.utils.SystemMessage:
/home/sfr/next/next/Documentation/trace/histogram-design.rst:219: (SEVERE/4)
Unexpected section title.
It also fixes a bunch of other warnings I noticed when fixing the
above, caused by mixing
On Wed, Jun 3, 2020 at 8:12 AM Greg KH wrote:
>
> On Tue, Jun 02, 2020 at 10:41:16PM -0700, syzbot wrote:
> > syzbot has found a reproducer for the following crash on:
> >
> > HEAD commit:1ee08de1 Merge tag 'for-5.8/io_uring-2020-06-01' of git://..
> > git tree: upstream
> > console
From: Colin Ian King
Currently the assignment of -ENOMEM to error is redudant because error
is not being read and -ENOMEM is being hard coded as an error return.
Fix this by returning the error code in variable 'error'; this also
allows the error code from a failed call to input_register_device
On Tue, May 19, 2020 at 11:15:26AM +0200, Borislav Petkov wrote:
> On Tue, Apr 28, 2020 at 05:16:45PM +0200, Joerg Roedel wrote:
> > From: Joerg Roedel
> >
> > The code inserted by the stack protector does not work in the early
> > boot environment because it uses the GS segment, at least with
On Tue, May 19, 2020 at 09:58:18AM -0400, Brian Gerst wrote:
> On Tue, Apr 28, 2020 at 11:28 AM Joerg Roedel wrote:
> The proper fix would be to initialize MSR_GS_BASE earlier.
That'll mean to initialize it two times during boot, as the first C
function with stack-protection is called before
On 2020-06-02 19:47, Saidi, Ali wrote:
[...]
Looks like the x86 apic set_affinity call explicitly checks for if
it’s activated in the managed case which makes sense given the code
Ben posted above:
/*
* Core code can call here for inactive interrupts. For
inactive
Not sure how this strange cv subject got copy-pasted, but
hopefully it's clear what it does from the description.
On 03/06/2020 18:03, Pavel Begunkov wrote:
> The first one adds checks {SQPOLL,IOPOLL}. IOPOLL check can be
> moved in the common path later, or rethinked entirely, e.g.
> not
If the template field 'd' is chosen and the digest to be added to the
measurement entry was not calculated with SHA1 or MD5, it is
recalculated with SHA1, by using the passed file descriptor. However, this
cannot be done for boot_aggregate, because there is no file descriptor.
This patch adds a
Fix the SCS debug usage check so that we report the number of bytes
usedm, rather than the number of entries.
Fixes: 5bbaf9d1fcb9 ("scs: Add support for stack usage debugging")
Reported-by: Sami Tolvanen
Signed-off-by: Will Deacon
---
kernel/scs.c | 2 +-
1 file changed, 1 insertion(+), 1
This patch prevents the following oops:
[ 10.771813] BUG: kernel NULL pointer dereference, address: 0
[...]
[ 10.779790] RIP: 0010:ima_match_policy+0xf7/0xb80
[...]
[ 10.798576] Call Trace:
[ 10.798993] ? ima_lsm_policy_change+0x2b0/0x2b0
[ 10.799753] ?
Hi,
we need to decide how to continue with the lan743x patch for fixed phy support.
Thanks everyone for the valuable time.
Summary of the development steps so far:
The patch initially had low influence on the installed base, but lacked some
compatibility to Linux best practices. During the
Hi,
On Wed, 2020-06-03 at 17:42 +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the ftrace tree, today's linux-next build (htmldocs)
> failed like this:
>
>
> Sphinx parallel build error:
> docutils.utils.SystemMessage:
>
On 03/06/2020 15:45, Dan Carpenter wrote:
> On Wed, Jun 03, 2020 at 03:18:46PM +0100, Colin Ian King wrote:
>> On 03/06/2020 15:09, Dan Carpenter wrote:
>>> On Wed, Jun 03, 2020 at 02:51:02PM +0100, Colin King wrote:
From: Colin Ian King
The variable error is being initialized with
Linus,
please pull the latest x86/timers branch from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
x86-timers-2020-06-03
up to: bd35c77e32e4: x86/tsc: Add tsc_early_khz command line parameter
X86 timer specific updates:
- Add TPAUSE based delay which allows the CPU to
On 03/06/2020 11:42, Jon Hunter wrote:
>
> On 02/06/2020 19:13, Greg Kroah-Hartman wrote:
>> This is the start of the stable review cycle for the 4.9.226 release.
>> There are 55 patches in this series, all will be posted as a response
>> to this one. If anyone has any issues with these being
build_open_how() is just adjusting open_flags/mode. Do it once during
prep. It looks better than storing raw values for the future.
Signed-off-by: Pavel Begunkov
---
fs/io_uring.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/fs/io_uring.c b/fs/io_uring.c
Hi Reinette,
> -Original Message-
> From: Reinette Chatre
> Sent: Tuesday, June 2, 2020 6:28 PM
> To: Moger, Babu ; fenghua...@intel.com;
> t...@linutronix.de; mi...@redhat.com; b...@alien8.de; x...@kernel.org;
> h...@zytor.com; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH]
io_openat_prep() and io_openat2_prep() are identical except for how
struct open_how is built. Deduplicate it with a helper.
Signed-off-by: Pavel Begunkov
---
fs/io_uring.c | 55 ++-
1 file changed, 19 insertions(+), 36 deletions(-)
diff --git
Fail recv/send in case of IORING_SETUP_IOPOLL earlier during prep,
so it'd be done only once. Removes duplication as well
Signed-off-by: Pavel Begunkov
---
fs/io_uring.c | 18 ++
1 file changed, 6 insertions(+), 12 deletions(-)
diff --git a/fs/io_uring.c b/fs/io_uring.c
index
IORING_SETUP_IOPOLL is defined only for read/write, other opcodes should
be disallowed, otherwise it'll get an error as below. Also refuse
open/cloes with SQPOLL, as the polling thread wouldn't know which file
table to use.
RIP: 0010:io_iopoll_getevents+0x111/0x5a0
Call Trace:
?
The first one adds checks {SQPOLL,IOPOLL}. IOPOLL check can be
moved in the common path later, or rethinked entirely, e.g.
not io_iopoll_req_issued()'ed for unsupported opcodes.
3 others are just cleanups on top.
v2: add IOPOLL to the whole bunch of opcodes in [1/4].
dirty and effective.
On 03.06.2020 16:33, Lukas Straub wrote:
> On Mon, 29 Apr 2019 18:16:51 +0200
> "Maciej S. Szmigiero" wrote:
>
>> This series adds support for analog part of Medion 95700 in the cxusb
>> driver.
>>
(..)
> Hi,
> Any status on this?
It has been merged already a year ago.
> Regards,
> Lukas
On Wed, Jun 03, 2020 at 03:21:47PM +0200, Andrew Lunn wrote:
> On Tue, Jun 02, 2020 at 11:50:17PM +0100, Russell King - ARM Linux admin
> wrote:
> > On Fri, May 29, 2020 at 06:33:40PM +0200, Andrew Lunn wrote:
> > > Given the current code, you cannot. Now we understand the
> > > requirements, we
On Wed, 3 Jun 2020 at 12:10, Mel Gorman wrote:
>
> On Wed, Jun 03, 2020 at 10:29:22AM +0200, Patrick Bellasi wrote:
> >
> > Hi Dietmar,
> > thanks for sharing these numbers.
> >
> > On Tue, Jun 02, 2020 at 18:46:00 +0200, Dietmar Eggemann
> > wrote...
> >
> > [...]
> >
> > > I ran these tests
Something went wrong, don't mind it
On 03/06/2020 16:29, Pavel Begunkov wrote:
> The first one adds checks {SQPOLL,IOPOLL}. IOPOLL check can be
> moved in the common path later, or rethinked entirely, e.g.
> not io_iopoll_req_issued()'ed for unsupported opcodes.
>
> 3 others are just cleanups on
On Wed, Jun 03, 2020 at 06:03:17AM -0700, Rajat Jain wrote:
> Currently, an external malicious PCI device can masquerade the VID:PID
> of faulty gfx devices, and thus apply iommu quirks to effectively
> disable the IOMMU restrictions for itself.
>
> Thus we need to ensure that the device we are
TEST REPORT: BROKEN PATCH
Thanks to everyone for working on the fixed link feature of lan743x eth driver.
I received more test hardware today, and one piece of hardware (EVBlan7430)
becomes incompatible by the patch. We need to roll back for now. Sorry.
I’ll discuss about options of how to
Add binding for ZynqMP R5 OpenAMP.
Represent the RPU domain resources in one device node. Each RPU
processor is a subnode of the top RPU domain node.
Signed-off-by: Ben Levinsky
Signed-off-by: Jason Wu
Signed-off-by: Wendy Liang
Signed-off-by: Michal Simek
---
v3:
- update zynqmp_r5 yaml
On Sun, May 31, 2020 at 8:26 PM Giovanni Gherdovich wrote:
>
> Be defensive against the case where the processor reports a base_freq
> larger than turbo_freq (the ratio would be zero).
>
> Signed-off-by: Giovanni Gherdovich
> Signed-off-by: Peter Zijlstra (Intel)
> Fixes: 1567c3e3467c ("x86,
Add ZynqMP firmware ioctl enums for RPU configuration.
Signed-off-by: Ben Levinsky
---
v3:
- add xilinx-related platform mgmt fn's instead of wrapping around
function pointer in xilinx eemi ops struct
v4:
- add default values for enums
---
include/linux/firmware/xlnx-zynqmp.h | 19
Please pull the proc-linus branch from the git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git
proc-linus
HEAD: 9d78edeaec759f997c303f286ecd39daee166f2a proc: proc_pid_ns takes
super_block as an argument
This branch has 4 sets of changes:
proc:
This patch adds APIs to provide access and a configuration interface
to the current power state of a sub-system on Zynqmp sub-system.
Signed-off-by: Ben Levinsky
---
v3:
- add xilinx-related platform mgmt fn's instead of wrapping around
function pointer in xilinx eemi ops struct
v4:
- add
Sequence counters write paths are critical sections that must never be
preempted, and blocking, even for CONFIG_PREEMPTION=n, is not allowed.
Commit 5dbe7c178d3f ("net: fix kernel deadlock with interface rename and
netdev name retrieval.") handled a deadlock, observed with
CONFIG_PREEMPTION=n,
Provide basic driver to control Arm R5 co-processor found on
Xilinx ZynqMP UltraScale+ and Versal MPSoC's.
Currently it is able to start, stop and load elf on to the
processor.
The driver was tested on Xilinx ZynqMP and Versal.
v2:
- remove domain struct as per review from Mathieu
v3:
- add
Commit 3c3b177a9369 ("reservation: add support for read-only access
using rcu") introduced a sequence counter to manage updates to
reservations. Back then, the reservation object initializer
reservation_object_init() was always inlined.
Having the sequence counter initialization inlined meant
The u64_stats mechanism uses sequence counters to protect against 64-bit
values tearing on 32-bit architectures. Updating u64_stats is thus a
sequence counter write side critical section where preemption must be
disabled.
For mdiobus_stats_acct(), disable preemption upon the u64_stats update.
It
For optimized block readers not holding a mutex, the "number of sectors"
64-bit value is protected from tearing on 32-bit architectures by a
sequence counter.
Disable preemption before entering that sequence counter's write side
critical section. Otherwise, the read side can preempt the write
Commit bf7afb29d545 ("phy: improve safety of fixed-phy MII register
reading") protected the fixed PHY status with a sequence counter.
Two years later, commit d2b977939b18 ("net: phy: fixed-phy: remove
fixed_phy_update_state()") removed the sequence counter's write side
critical section --
Hi,
Since patch #7 and #8 from the series:
[PATCH v1 00/25] seqlock: Extend seqcount API with associated locks
https://lore.kernel.org/lkml/20200519214547.352050-1-a.darw...@linutronix.de
are now pending on the lockdep/x86 IRQ state tracking patch series:
[PATCH 00/14] x86/entry:
The u64_stats mechanism uses sequence counters to protect against 64-bit
values tearing on 32-bit architectures. Updating such statistics is a
sequence counter write side critical section.
Preemption must be disabled before entering this seqcount write critical
section. Failing to do so, the
R5 is included in Xilinx Zynq UltraScale MPSoC so by adding this
remotproc driver, we can boot the R5 sub-system in different
configurations.
Acked-by: Stefano Stabellini
Acked-by: Ben Levinsky
Reviewed-by: Radhey Shyam Pandey
Signed-off-by: Ben Levinsky
Signed-off-by: Wendy Liang
Add shutdown/wakeup a resource eemi operations to shutdown
or bringup a resource.
Signed-off-by: Ben Levinsky
---
v3:
- add xilinx-related platform mgmt fn's instead of wrapping around
function pointer in xilinx eemi ops struct
- fix formatting
v4:
- add default values for enums
---
On Wed, Jun 03, 2020 at 03:32:57PM +0200, Joerg Roedel wrote:
> On Wed, Jun 03, 2020 at 04:20:57PM +0530, Abdul Haleem wrote:
> > @Joerg, Could you please have a look?
>
> Can you please try the attached patch?
Hi Joerg,
I did hit the similar boot failue on a Power9 baremetal box(mentioned in
Hi Jonathan,
something I forgot, about the __packed attribute for the sensor data structure
struct inv_icm42600_fifo_sensor_data located inside inv_icm42600_buffer.h.
I added it because this structure is used for decoding the FIFO data frame
which can be unaligned. It is also used for storing
On Wed, 3 Jun 2020 at 15:32, Marco Elver wrote:
>
> On Wed, 3 Jun 2020 at 14:18, Peter Zijlstra wrote:
> >
> > On Wed, Jun 03, 2020 at 02:08:57PM +0200, Marco Elver wrote:
> >
> > > What is the .config you used? I somehow can't reproduce. I've applied
> > > the patches on top of -tip/master.
> >
On Wed, Jun 03, 2020 at 03:18:46PM +0100, Colin Ian King wrote:
> On 03/06/2020 15:09, Dan Carpenter wrote:
> > On Wed, Jun 03, 2020 at 02:51:02PM +0100, Colin King wrote:
> >> From: Colin Ian King
> >>
> >> The variable error is being initialized with a value that is
> >> never read and the
On Wed, Jun 03, 2020 at 12:34:35PM +0800, Hillf Danton wrote:
>
> On Tue, 2 Jun 2020 17:55:17 -0400 "J. Bruce Fields" wrote:
> >
> > As far as I know, this one's still unresolved. I can't see the bug from
> > code inspection, and we don't have a reproducer. If anyone else sees
> > this or has
Move building of fast lookup table from boot to sorttable tool. This saves us
6380us boot time on Intel(R) Xeon(R) CPU E5-2682 v4 @ 2.50GHz with cores. It
adds a little more than 7ms to boot time when testing on the same CPU.
Changelog v3:
1. Modify annotation of unwind_init().
Changelog v2:
1.
The orc fast lookup table is built by scripts/sorttable tool. All that
is left is setting lookup_num_blocks.
Signed-off-by: Huaixin Chang
Signed-off-by: Shile Zhang
---
arch/x86/kernel/unwind_orc.c | 41 ++---
1 file changed, 2 insertions(+), 39 deletions(-)
Since orc tables are already sorted by sorttable tool, let us move
building of fast lookup table into sorttable tool too. This saves us
6380us from boot time under Intel(R) Xeon(R) CPU E5-2682 v4 @ 2.50GHz
with 64 cores.
Signed-off-by: Huaixin Chang
Signed-off-by: Shile Zhang
---
In order to edit orc_lookup table via sorttable, type of section
orc_lookup needs to be SHT_PROGBITS instead of SHT_NOBITS.
Linker script doesn't seem to allow manual specification of the section
type, so just write a byte into the section instead.
Signed-off-by: Josh Poimboeuf
Signed-off-by:
Thu, May 28, 2020 at 05:12:42PM CEST, vadym.koc...@plvision.eu wrote:
>Add very basic support for devlink interface:
>
>- driver name
>- fw version
>- devlink ports
>
>Signed-off-by: Vadym Kochan
>---
> drivers/net/ethernet/marvell/prestera/Kconfig | 1 +
>
Hi Chuhong,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v5.7 next-20200603]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base
Wed, Jun 03, 2020 at 04:29:44PM CEST, j...@resnulli.us wrote:
>Thu, May 28, 2020 at 05:12:40PM CEST, vadym.koc...@plvision.eu wrote:
>
>[...]
>
>>+static int prestera_port_create(struct prestera_switch *sw, u32 id)
>>+{
>>+ struct prestera_port *port;
>>+ struct net_device *dev;
>>+
Hello Sumit,
if this doc is for driver developers it might be useful to add some
code examples how to register drivers on tee bus.
Best regards,
Maxim.
On Wed, 3 Jun 2020 at 14:31, Sumit Garg wrote:
>
> Update documentation with TEE bus infrastructure which provides an
> interface for kernel
On Mon, 29 Apr 2019 18:16:51 +0200
"Maciej S. Szmigiero" wrote:
> This series adds support for analog part of Medion 95700 in the cxusb
> driver.
>
> What works:
> * Video capture at various sizes with sequential fields,
> * Input switching (TV Tuner, Composite, S-Video),
> * TV and radio
On Wed, May 20, 2020 at 05:51:27AM -0700, Eric Dumazet wrote:
>
> On 5/19/20 11:42 PM, Ahmed S. Darwish wrote:
> > Hello Eric,
> >
> > On Tue, May 19, 2020 at 07:01:38PM -0700, Eric Dumazet wrote:
> >>
> >> On 5/19/20 2:45 PM, Ahmed S. Darwish wrote:
> >>> Sequence counters write paths are
On Wed, 3 Jun 2020 08:51:13 +0900
Masami Hiramatsu wrote:
> On Tue, 2 Jun 2020 09:21:45 -0400
> Steven Rostedt wrote:
>
> > On Tue, 2 Jun 2020 18:08:31 +0900
> > Masami Hiramatsu wrote:
> >
> > > +++ b/tools/testing/selftests/ftrace/test.d/template
> > > @@ -1,6 +1,7 @@
> > > #!/bin/sh
>
The orc fast lookup table is built by scripts/sorttable tool. All that
is left is setting lookup_num_blocks.
Signed-off-by: Huaixin Chang
Signed-off-by: Shile Zhang
---
arch/x86/kernel/unwind_orc.c | 40
1 file changed, 40 deletions(-)
diff --git
Move building of fast lookup table from boot to sorttable tool. This saves us
6380us boot time on Intel(R) Xeon(R) CPU E5-2682 v4 @ 2.50GHz with cores.
Changelog v2:
1. Type of section orc_lookup needs to be SHT_PROGBITS.
2. unwind_init() cannot be removed totally as setting lookup_num_blocks is
In order to edit orc_lookup table via sorttable, type of section
orc_lookup needs to be SHT_PROGBITS instead of SHT_NOBITS.
Linker script doesn't seem to allow manual specification of the section
type, so just write a byte into the section instead.
Signed-off-by: Josh Poimboeuf
Signed-off-by:
Since orc tables are already sorted by sorttable tool, let us move
building of fast lookup table into sorttable tool too. This saves us
6380us from boot time under Intel(R) Xeon(R) CPU E5-2682 v4 @ 2.50GHz
with 64 cores.
Signed-off-by: Huaixin Chang
Signed-off-by: Shile Zhang
---
Thu, May 28, 2020 at 05:12:40PM CEST, vadym.koc...@plvision.eu wrote:
[...]
>+static int prestera_port_create(struct prestera_switch *sw, u32 id)
>+{
>+ struct prestera_port *port;
>+ struct net_device *dev;
>+ int err;
>+
>+ dev = alloc_etherdev(sizeof(*port));
>+ if
> Its time cost is about 800 nanoseconds on a 2C/4T platform and
> 2~3 microseconds on a 2S/36C/72T server in normal case, and in
> worst case where vm_committed_as's spinlock is under severe
> contention, it costs 30~40 microseconds for the 2S/36C/72T sever,
This will be likely 40-80us on larger
Hi Piotr,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on pci/next]
[also build test ERROR on mkp-scsi/for-next scsi/for-next linus/master v5.7
next-20200603]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we
On Sun, May 31, 2020 at 8:26 PM Giovanni Gherdovich wrote:
>
> There may be CPUs that support turbo boost but don't declare any turbo
> ratio, i.e. their MSR_TURBO_RATIO_LIMIT is all zeroes. In that condition
> scale-invariant calculations can't be performed.
>
> Signed-off-by: Giovanni
Hi Jean,
On Tue, May 19, 2020 at 11:20:55PM -0700, Sean Christopherson wrote:
> On Tue, Apr 28, 2020 at 05:16:35PM +0200, Joerg Roedel wrote:
> > + /*
> > +* For the string variants with rep prefix the amount of in/out
> > +* operations per #VC exception is
On Sun, May 31, 2020 at 8:26 PM Giovanni Gherdovich wrote:
>
> The product mcnt * arch_max_freq_ratio can overflows u64.
>
> For context, a large value for arch_max_freq_ratio would be 5000,
> corresponding to a turbo_freq/base_freq ratio of 5 (normally it's more like
> 1500-2000). A large
On Sat, May 16, 2020 at 09:57:14AM +0200, Borislav Petkov wrote:
> Just a reminder so that this doesn't get lost:
>
> On Tue, Apr 28, 2020 at 05:16:35PM +0200, Joerg Roedel wrote:
> > + if (exit_info_1 & IOIO_TYPE_STR) {
> > + int df = (regs->flags & X86_EFLAGS_DF) ? -1 : 1;
>
> ...
501 - 600 of 1155 matches
Mail list logo
