Add a new VFIO_PCI_DMA_FAULT_IRQ_INDEX index. This allows to
set/unset an eventfd that will be triggered when DMA translation
faults are detected at physical level when the nested mode is used.
Signed-off-by: Eric Auger
---
drivers/vfio/pci/vfio_pci.c | 3 +++
drivers/vfio/pci/vfio_pci_in
On Fri, Mar 15, 2019 at 8:56 AM Suren Baghdasaryan wrote:
>
> On Thu, Mar 14, 2019 at 9:37 PM Daniel Colascione wrote:
> >
> > On Thu, Mar 14, 2019 at 8:16 PM Steven Rostedt wrote:
> > >
> > > On Thu, 14 Mar 2019 13:49:11 -0700
> > > Sultan Alsawaf wrote:
> > >
> > > > Perhaps I'm missing somet
Hi.
On Sat, Mar 16, 2019 at 12:19 AM Doug Anderson wrote:
>
> Hi,
>
> On Fri, Mar 15, 2019 at 7:11 AM Masahiro Yamada
> wrote:
> >
> > On Fri, Mar 15, 2019 at 2:59 AM Douglas Anderson
> > wrote:
> > >
> > > If the call to strip returns an error code then it makes sense for the
> > > build to
On Fri, Mar 15, 2019 at 05:03:47PM +0100 Peter Zijlstra wrote:
> On Fri, Mar 15, 2019 at 11:30:42AM -0400, Phil Auld wrote:
>
> > In my defense here, all the fair.c imbalance pct code also uses 100 :)
>
> Yes, I know, I hate on that too ;-) Just never got around to fixing
> that.
>
>
> > with t
Hi Alex,
Some nitpick review comments below.
On Wed, Mar 13, 2019 at 12:33 PM Alexandre Bailon wrote:
>
> This series implements busfreq, a framework used in MXP's
s/MXP/NXP/
> tree to scale the interconnect and dram frequencies.
> In the vendor tree, device's driver request for a
> performanc
On Fri, Mar 15, 2019 at 9:28 PM Mike Rapoport wrote:
>
> On Thu, Mar 14, 2019 at 11:28:32PM +0530, Anup Patel wrote:
> > On Thu, Mar 14, 2019 at 12:23 PM Mike Rapoport wrote:
> > >
> > > On Thu, Mar 14, 2019 at 02:36:01AM +0530, Anup Patel wrote:
> > > > On Thu, Mar 14, 2019 at 12:01 AM Mike Rapo
On Fri, Mar 15, 2019 at 04:59:33PM +0100 Peter Zijlstra wrote:
> On Fri, Mar 15, 2019 at 09:51:25AM -0400, Phil Auld wrote:
> > On Fri, Mar 15, 2019 at 11:33:57AM +0100 Peter Zijlstra wrote:
> > > On Fri, Mar 15, 2019 at 11:11:50AM +0100, Peter Zijlstra wrote:
> > > > diff --git a/kernel/sched/fair
On Fri, Mar 15, 2019 at 9:28 PM Mike Rapoport wrote:
>
> On Thu, Mar 14, 2019 at 11:28:32PM +0530, Anup Patel wrote:
> > On Thu, Mar 14, 2019 at 12:23 PM Mike Rapoport wrote:
> > >
> > > On Thu, Mar 14, 2019 at 02:36:01AM +0530, Anup Patel wrote:
> > > > On Thu, Mar 14, 2019 at 12:01 AM Mike Rapo
Hi Rob,
On 3/13/19 2:20 PM, Rob Herring wrote:
On Tue, Mar 12, 2019 at 2:28 PM Thor Thayer wrote:
Hi Rob,
On 3/12/19 11:04 AM, Rob Herring wrote:
On Wed, Feb 27, 2019 at 11:27:22AM -0600, thor.tha...@linux.intel.com wrote:
From: Thor Thayer
Add peripheral bindings for Stratix10 EDAC to c
This reverts commit caf6fe91ddf62a96401e21e9b7a07227440f4185.
The commit was fine but is no longer needed as of commit 3a2429e1faf4
("kbuild: change if_changed_rule for multi-line recipe"). Let's go
back to using ";" to be consistent.
For some discussion, see:
https://lkml.kernel.org/r/CAK7LNAS
Quoting Lina Iyer (2019-03-13 14:18:41)
> ---
> Changes in v4:
> - Remove irq_set_wake() on summary IRQ interrupt
> Changes in v3:
> - Use of_irq_domain_map() and pass PDC pin to parent irqdomain
> Changes in v2:
> - Call parent mask when masking GPIO interrupt
> Changes in
On Fri, Mar 15, 2019 at 09:30:42AM -0400, Phil Auld wrote:
> On Fri, Mar 15, 2019 at 11:11:50AM +0100 Peter Zijlstra wrote:
> > Computers _suck_ at /100. And since you're free to pick the constant,
> > pick a power of two, computers love those.
> >
>
> Fair enough, I was thinking percents. And a
Since the enabling and disabling of IRQs within preempt_schedule_irq()
is contained in a need_resched() loop, we don't need the outer arch
code loop.
Note that commit a18815abcdfd ("Use preempt_schedule_irq.") initially
removed the existing loop, but missed the final branch to restore_all.
Commit
On Thu, 14 Mar 2019 21:36:43 -0700
Daniel Colascione wrote:
> On Thu, Mar 14, 2019 at 8:16 PM Steven Rostedt wrote:
> >
> > On Thu, 14 Mar 2019 13:49:11 -0700
> > Sultan Alsawaf wrote:
> >
> > > Perhaps I'm missing something, but if you want to know when a process has
> > > died
> > > after
Hi Mike,
On 3/15/19 5:17 PM, Michael Turquette wrote:
Hi Alex,
Some nitpick review comments below.
On Wed, Mar 13, 2019 at 12:33 PM Alexandre Bailon wrote:
This series implements busfreq, a framework used in MXP's
s/MXP/NXP/
tree to scale the interconnect and dram frequencies.
In the ven
On 3/15/19 8:29 AM, Michel Dänzer wrote:
> On 2019-03-15 11:25 a.m., Boris Brezillon wrote:
>> On Fri, 15 Mar 2019 11:11:36 +0100
>> Michel Dänzer wrote:
>>
>>> On 2019-03-14 6:51 p.m., Helen Koike wrote:
On 3/14/19 6:15 AM, Michel Dänzer wrote:
> On 2019-03-13 7:08 p.m., Helen Koike
On Fri, 15 Mar 2019 at 13:57:05 +0100, Geert Uytterhoeven wrote:
> On Fri, Mar 15, 2019 at 11:23 AM George Spelvin wrote:
>> On Fri, 15 Mar 2019 at 09:20:58 +0100, Geert Uytterhoeven wrote:
>>> On Fri, Mar 15, 2019 at 5:33 AM George Spelvin wrote:
One question I should ask everyone: should "
On 15-03-19, 03:49, Katsuhiro Suzuki wrote:
> This patch adds debugfs interface to show the relationship between
> DMA threads (hardware resource for transferring data) and DMA
> channel ID of DMA slave.
>
> Typically, PL330 has many slaves than number of DMA threads.
> So sometimes PL330 cannot a
Provide helpers to manage the power state, and initial configuration of
the CRTC.
rcar_du_crtc_get() and rcar_du_crtc_get() are no longer used, and are
removed, simplifying the implementation and removing the initialized
flag which was needed to track the state of the CRTC.
Signed-off-by: Kieran
Refactoring of the group control code will soon require more iteration
over the available groups. Simplify this process by introducing a group
iteration helper.
Signed-off-by: Kieran Bingham
---
v2:
- no change
drivers/gpu/drm/rcar-du/rcar_du_drv.h | 5 +
drivers/gpu/drm/rcar-du/rcar_du_k
The group can now be handled independently from the CRTC tracking its
own state.
Introduce an rcar_du_group_atomic_check() call which will iterate the
CRTCs to determine the per-state use-count of the group.
This use count then allows us to determine if the group should be
configured or disabled
The rcar_du_crtc functions have a heavy reliance on the rcar_du_group
structure, in many cases just to access the DU device context.
To better separate the groups out of the CRTC handling code, give the
rcar_du_crtc its own pointer to the device and remove the indirection
through the group pointer
Tim Wawrzynczak (1):
platform/chrome: mfd/cros_ec_sysfs: Add sysfs entry to retrieve EC
uptime.
drivers/platform/chrome/cros_ec_sysfs.c | 34 +
include/linux/mfd/cros_ec_commands.h| 15 +++
2 files changed, 49 insertions(+)
--
2.20.1
Adds a new sysfs node under the cros_ec device which contains the uptime
of the EC in milliseconds since boot.
Signed-off-by: Tim Wawrzynczak
---
drivers/platform/chrome/cros_ec_sysfs.c | 34 +
include/linux/mfd/cros_ec_commands.h| 15 +++
2 files changed, 49
In case dmaengine_prep_dma_cyclic fails, the fix returns a proper
error code to avoid NULL pointer dereference.
Signed-off-by: Kangjie Lu
Fixes: 34df42f59a60 ("serial: at91: add rx dma support")
---
V2: simplified the patch as suggested by
Richard Genoud
---
drivers/tty/serial/atmel_serial.c |
Quoting Jerome Brunet (2019-03-15 03:01:53)
> On Tue, 2019-02-26 at 14:34 -0800, Stephen Boyd wrote:
> > ---
> > drivers/clk/clk.c| 260 ++-
> > include/linux/clk-provider.h | 19 +++
> > 2 files changed, 217 insertions(+), 62 deletions(-)
>
> Sorry fo
On 15/03/19 00:16, Fenghua Yu wrote:
> Hi, Valo,
>
> On Thu, Mar 14, 2019 at 03:16:33PM +0200, Kalle Valo wrote:
>> Fenghua Yu writes:
>>
>>> From: Paolo Bonzini
>>>
>>> Bitmaps are defined on unsigned longs, so the usage of u32[2] in the
>>> wlcore driver is incorrect. As noted by Peter Zijlst
On 3/15/19 11:31 AM, Alexandre Bailon wrote:
>>> This series is sent as RFC mostly because the current support of i.MX SoC
>>> won't
>>> benefit of busfreq framework, because the clocks' driver don't support
>>> interconnect / dram frequency scaling.
>>> As exemple, this series implements busfreq
On Fri, Mar 15, 2019 at 9:43 AM Steven Rostedt wrote:
>
> On Thu, 14 Mar 2019 21:36:43 -0700
> Daniel Colascione wrote:
>
> > On Thu, Mar 14, 2019 at 8:16 PM Steven Rostedt wrote:
> > >
> > > On Thu, 14 Mar 2019 13:49:11 -0700
> > > Sultan Alsawaf wrote:
> > >
> > > > Perhaps I'm missing someth
The patch
regulator: da9055: Convert to regulator core's simplified DT parsing code
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually somet
The patch
regulator: 88pm800: Get rid of struct pm800_regulators
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24
The patch
regulator: da9052: Convert to regulator core's simplified DT parsing code
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually somet
The patch
spi: spi-mem: stm32-qspi: add suspend/resume support
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sen
The patch
spi: spi-mem: stm32-qspi: avoid memory corruption at low frequency
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24
On Fri, 15 Mar 2019, Oscar Salvador wrote:
> On Fri, Mar 15, 2019 at 01:47:33PM +0100, Michal Hocko wrote:
> > diff --git a/mm/debug.c b/mm/debug.c
> > index 1611cf00a137..499c26d5ebe5 100644
> > --- a/mm/debug.c
> > +++ b/mm/debug.c
> > @@ -78,6 +78,9 @@ void __dump_page(struct page *page, const c
On Fri, 15 Mar 2019 14:26:34 +0100
Pierre Morel wrote:
> On 15/03/2019 11:20, Cornelia Huck wrote:
> > On Wed, 13 Mar 2019 17:04:58 +0100
> > Pierre Morel wrote:
> >
> >> +/*
> >> + * handle_pqap: Handling pqap interception
> >> + * @vcpu: the vcpu having issue the pqap instruction
> >> + *
> >
On 3/15/19 1:43 PM, André Almeida wrote:
Hello,
This series implements support for multiplane pixel formats at vimc.
A lot of changes were required since vimc support for singleplane
was "hardcoded". The code has been adapted in order to support both
formats. When was possible, the functions
On 31/01/19 17:09, Yu Zhang wrote:
> Previously, 'commit 372fddf70904 ("x86/mm: Introduce the 'no5lvl' kernel
> parameter")' cleared X86_FEATURE_LA57 in boot_cpu_data, if Linux chooses
> to not run in 5-level paging mode. Yet boot_cpu_data is queried by
> do_cpuid_ent() as the host capability later
On Fri, Mar 15, 2019 at 3:31 PM Gabriel Lazar
wrote:
>
> Add touchscreen platform data for the Myrya MY8307 2-in-1 laptop.
You sent one patch twice or two patches?
Please, clarify this by sending v2 with correct subject line(s) and
amount of patches.
>
> Signed-off-by: Gabriel Lazar
> ---
> dr
On Fri, Mar 15, 2019 at 08:57:18AM -0700, Luck, Tony wrote:
> fsl_ddr_edac.c looks to be doing exactly what we are doing with
> skx_common.c. They just get away with it for now because they don't
> have a reference to THIS_MODULE since they don't set up anything
> in sysfs.
>
> If this is your goa
Hi,
On 3/15/19 6:33 PM, Andy Shevchenko wrote:
On Fri, Mar 15, 2019 at 3:31 PM Gabriel Lazar
wrote:
Add touchscreen platform data for the Myrya MY8307 2-in-1 laptop.
You sent one patch twice or two patches?
Please, clarify this by sending v2 with correct subject line(s) and
amount of patche
On Fri, 15 Mar 2019 15:10:25 +0100
Pierre Morel wrote:
> Sorry, wrong conclusion, handling this in userland will bring us much
> too far if we want to answer correctly for the case the hook is not
> there but QEMU accepted the facility for AQIC.
>
> The alternative is easier, we just continue
On 06/02/19 06:53, Masahiro Yamada wrote:
> I do not see any consistency about headers_install of
> and .
>
> According to my analysis of Linux 5.0-rc5, there are 3 groups:
>
> [1] Both and are exported
>
> alpha, arm, hexagon, mips, powerpc, s390, sparc, x86
>
> [2] is exported, but
On 22/02/19 11:48, lantianyu1...@gmail.com wrote:
> From: Lan Tianyu
>
> The max flush rep count of HvFlushGuestPhysicalAddressList hypercall
> is equal with how many entries of union hv_gpa_page_range can be populated
> into the input parameter page. The origin code lacks parenthesis around
> PA
Hi,
On 3/15/19 2:31 PM, Gabriel Lazar wrote:
Add touchscreen platform data for the Myrya MY8307 2-in-1 laptop.
Signed-off-by: Gabriel Lazar
Patch looks good to me:
Reviewed-by: Hans de Goede
Regards,
Hans
---
drivers/platform/x86/touchscreen_dmi.c | 25 +
1
On 3/15/19 10:49 AM, Tom Lendacky wrote:
> On 3/15/19 10:11 AM, Peter Zijlstra wrote:
>> On Fri, Mar 15, 2019 at 02:44:32PM +, Lendacky, Thomas wrote:
>>
> @@ -689,6 +731,7 @@ static __initconst const struct x86_pmu amd_pmu = {
> .amd_nb_constraints = 1,
> .wait_on_
Hi George,
On Fri, Mar 15, 2019 at 5:59 PM George Spelvin wrote:
> On Fri, 15 Mar 2019 at 13:57:05 +0100, Geert Uytterhoeven wrote:
> > On Fri, Mar 15, 2019 at 11:23 AM George Spelvin wrote:
> >> On Fri, 15 Mar 2019 at 09:20:58 +0100, Geert Uytterhoeven wrote:
> >>> On Fri, Mar 15, 2019 at 5:33
On Fri, Mar 15, 2019 at 06:37:20PM +0100, Borislav Petkov wrote:
> I think the shared code should not have any reference to modules because
> it is supposed to be a library. Can you move the THIS_MODULE out of the
> common file and into the actual module?
Yes - Qiuxu did that already ... patch re
Hi Greg,
Just wanted to check with you on how we may proceed with this series.
The main feature is exporting new sysfs attributes through driver core,
so I think it makes most sense to go through you unless you'd prefer
this go through a different route.
The proposed interface has been pretty sta
From: Kan Liang
Perf fails to parse uncore event alias, for example:
#perf stat -e unc_m_clockticks -a --no-merge sleep 1
event syntax error: 'unc_m_clockticks'
\___ parser error
Current code assumes that the event alias is from one specific PMU.
To find the PMU, perf
On 3/10/19 11:21 AM, Jonathan Cameron wrote:
> On Wed, 6 Mar 2019 09:55:23 +0100
> Fabrice Gasnier wrote:
>
>> DFSDM can operate using these buffer modes:
>> - INDIO_BUFFER_SOFTWARE: regular continuous conversions (no trigger)
>> but limited to 1 channel. User can set sampling frequency in this
On Fri, Mar 15, 2019 at 10:49:56AM -0700, Luck, Tony wrote:
> Yes - Qiuxu did that already ... patch reposted below.
... to which Arnd said that it were fragile because it might break if it
includes a THIS_MODULE reference. So I'd say we won't do that then. And
keep it strictly a library.
Right?
On Thu, Mar 14, 2019 at 09:36:43PM -0700, Daniel Colascione wrote:
> On Thu, Mar 14, 2019 at 8:16 PM Steven Rostedt wrote:
> >
> > On Thu, 14 Mar 2019 13:49:11 -0700
> > Sultan Alsawaf wrote:
> >
> > > Perhaps I'm missing something, but if you want to know when a process has
> > > died
> > > aft
On 13/03/19 18:13, Vitaly Kuznetsov wrote:
> When userspace initializes guest vCPUs it may want to zero all supported
> MSRs including Hyper-V related ones including HV_X64_MSR_STIMERn_CONFIG/
> HV_X64_MSR_STIMERn_COUNT. With commit f3b138c5d89a ("kvm/x86: Update SynIC
> timers on guest entry only"
On 13/03/19 21:16, Sean Christopherson wrote:
> Gah, this also needs: tools/testing/selftests/kvm/*/
>
No, it doesn't.
$ scripts/get_maintainer.pl tools/testing/selftests/kvm/x86_64/state_test.c
Paolo Bonzini (supporter:KERNEL VIRTUAL MACHINE
(KVM),commit_signer:8/9=89%,authored:3/9=33%)
"Radi
On Fri, Mar 15, 2019 at 07:02:06PM +0100, Borislav Petkov wrote:
> On Fri, Mar 15, 2019 at 10:49:56AM -0700, Luck, Tony wrote:
> > Yes - Qiuxu did that already ... patch reposted below.
>
> ... to which Arnd said that it were fragile because it might break if it
> includes a THIS_MODULE reference.
On Fri, Mar 15, 2019 at 07:03:07PM +0100, Christian Brauner wrote:
> On Thu, Mar 14, 2019 at 09:36:43PM -0700, Daniel Colascione wrote:
> > On Thu, Mar 14, 2019 at 8:16 PM Steven Rostedt wrote:
> > >
> > > On Thu, 14 Mar 2019 13:49:11 -0700
> > > Sultan Alsawaf wrote:
> > >
> > > > Perhaps I'm mi
On Wed, 13 Mar 2019 17:05:01 +0100
Pierre Morel wrote:
> When the mediated device is open we setup the relation with KVM unset it
> when the mediated device is released.
>
> We ensure KVM is present on opening of the mediated device.
>
> We ensure that KVM survives the mediated device, and esta
I don't know if fix is functional correct, but at least it compiles now.
It failed before with a config for an AMD CPU.
Bug was introduced with commit d01b1f96a82e5dd7841a1d39db3abfdaf95f70ab
"perf/x86/intel: Make cpuc allocations consistent" which was merged
with 004cc08675b761fd82288bab1b5ba5e1c
Hi,
I'm working on organizing a microconference for Linux Plumbers 2019
focused on distribution kernels. The focus is on collaboration on
common problems for maintaining and distributing a kernel for any
kind of distribution (embedded, enterprise, community, internal, extrnal).
Ideally, this woul
On Fri, Mar 15, 2019 at 02:13:24PM -0400, Joel Fernandes wrote:
> On Fri, Mar 15, 2019 at 07:03:07PM +0100, Christian Brauner wrote:
> > On Thu, Mar 14, 2019 at 09:36:43PM -0700, Daniel Colascione wrote:
> > > On Thu, Mar 14, 2019 at 8:16 PM Steven Rostedt
> > > wrote:
> > > >
> > > > On Thu, 14
On Fri, Mar 15, 2019 at 07:07:45PM +0100, Paolo Bonzini wrote:
> On 13/03/19 21:16, Sean Christopherson wrote:
> > Gah, this also needs: tools/testing/selftests/kvm/*/
> >
>
> No, it doesn't.
>
> $ scripts/get_maintainer.pl tools/testing/selftests/kvm/x86_64/state_test.c
> Paolo Bonzini (suppor
On Fri, Mar 15, 2019 at 7:47 PM Hans de Goede wrote:
>
> Hi,
>
> On 3/15/19 2:31 PM, Gabriel Lazar wrote:
> > Add touchscreen platform data for the Myrya MY8307 2-in-1 laptop.
> >
> > Signed-off-by: Gabriel Lazar
>
> Patch looks good to me:
>
> Reviewed-by: Hans de Goede
>
OK, thanks for explan
From: Masami Hiramatsu
Since alloc_trace_*probe() returns -EINVAL only if !event && !group,
it should not happen in trace_*probe_create(). If we catch that case
there is a bug. So use WARN_ON_ONCE() instead of pr_info().
Link:
http://lkml.kernel.org/r/155253785078.14922.16902223633734601469.stg
From: Masami Hiramatsu
Check event and group naming rule at parsing it instead
of allocating probes.
Link:
http://lkml.kernel.org/r/155253784064.14922.2336893061156236237.stgit@devnote2
Signed-off-by: Masami Hiramatsu
Signed-off-by: Steven Rostedt (VMware)
---
kernel/trace/trace_kprobe.c |
From: =?UTF-8?q?Valdis=20Kl=C4=93tnieks?=
sparse complains:
CHECK kernel/trace/trace_probe.c
kernel/trace/trace_probe.c:16:12: warning: symbol 'reserved_field_names' was
not declared. Should it be static?
Yes, it should be static.
Link: http://lkml.kernel.org/r/2478.1552380778@turing-polic
From: Masami Hiramatsu
Check maxactive on kprobe error case, because maxactive
is only for kretprobe, not for kprobe. Also, maxactive
should not be 0, it should be at least 1.
Link:
http://lkml.kernel.org/r/155253780952.14922.15784129810238750331.stgit@devnote2
Signed-off-by: Masami Hiramatsu
On Fri, Mar 15, 2019 at 8:44 PM Enrico Weigelt, metux IT consult
wrote:
> On 15.03.19 19:11, Andy Shevchenko wrote:
> OTOH, the name, IMHO, is a bit misleading. Any chance of ever changing
> it to a more clear name (eg. devm_request_and_ioremap_resource()) ?
Compare iomap vs. ioREmap.
--
Wit
From: Masami Hiramatsu
Ensure given name of event is not too long when parsing it,
and fix to update event name offset correctly when the group
name is given. For example, this makes probe event to check
the "p:foo/" error case correctly.
Link:
http://lkml.kernel.org/r/155253782046.14922.147241
From: Douglas Anderson
As reported back in 2016-11 [1], the "ftdump" kdb command triggers a
BUG for "sleeping function called from invalid context".
kdb's "ftdump" command wants to call ring_buffer_read_prepare() in
atomic context. A very simple solution for this is to add allocation
flags to r
Linus,
This contains a series of last minute clean ups, small fixes and
error checks.
Please pull the latest trace-v5.1-2 tree, which can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
trace-v5.1-2
Tag SHA1: de3d34862ab43473fb0ce9d774c09241b85c7c9c
Head
From: Masami Hiramatsu
Check the size of argument name and expression is not 0
and smaller than maximum length.
Link:
http://lkml.kernel.org/r/155253783029.14922.12650939303827581096.stgit@devnote2
Signed-off-by: Masami Hiramatsu
Signed-off-by: Steven Rostedt (VMware)
---
kernel/trace/trace
From: =?UTF-8?q?Valdis=20Kl=C4=93tnieks?=
CC kernel/trace/trace_kprobe.o
kernel/trace/trace_kprobe.c:41: warning: cannot understand function prototype:
'struct trace_kprobe '
The real problem is that a comment looked like kerneldoc when it shouldn't be...
Link: http://lkml.kernel.org/r/
On Fri, Mar 15, 2019 at 07:24:28PM +0100, Christian Brauner wrote:
[..]
> > why do we want to add a new syscall (pidfd_wait) though? Why not just use
> > standard poll/epoll interface on the proc fd like Daniel was suggesting.
> > AFAIK, once the proc file is opened, the struct pid is essentially p
If we encounter a failure during suspend where this RTC was programmed
to wakeup the system from suspend, but that wakeup couldn't be
configured because the system didn't support wakeup interrupts, we'll
run into the following warning:
Unbalanced IRQ 166 wake disable
WARNING: CPU:
> I'm trying to present the case to spur discussion, but it realy is
> a *question* I'm asking about whether to do that, not a suggestion
> phrased as a question.
> If it's just x86_64, use size_t everywhere, and let them suffer, for not
> being real 64-bit ;-)
But what is the problem of local ty
Hi Matthew,
On Thu, Mar 14, 2019 at 9:30 PM Matthew Wilcox wrote:
>
> On Thu, Mar 14, 2019 at 03:10:19PM +0530, Souptick Joarder wrote:
> > > >> mm/memory.c:3968:21: sparse: incorrect type in assignment (different
> > > >> base types) @@expected restricted vm_fault_t [usertype] ret @@
>
On 3/13/19 2:30 PM, Georgi Djakov wrote:
Here is a proposal to extend the OPP bindings with bandwidth based on
a previous discussion [1].
Every functional block on a SoC can contribute to the system power
efficiency by expressing its own bandwidth needs (to memory or other SoC
modules). This
On Fri, Mar 15, 2019 at 09:53:07PM +0300, Andrey Abramov wrote:
> > I'm trying to present the case to spur discussion, but it realy is
> > a *question* I'm asking about whether to do that, not a suggestion
> > phrased as a question.
>
> > If it's just x86_64, use size_t everywhere, and let them su
On Thu, 14 Mar 2019, Kangjie Lu wrote:
> securityfs_create_file may fail. The fix checks its status and
> returns EFAULT upstream if it fails.
>
> Signed-off-by: Kangjie Lu
> ---
> security/inode.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/security/inode.c b/security/inode
When using this driver with the wireless dongle and some usermode
program that monitors every input device (acpid, for example), while
another usermode client opens and closes the low-level device
repeadedly, the system eventually deadlocks.
The reason is that steam_input_register_device() must no
Dear Sir, I Know That This Mail Will Come To You As A Surprise As We
Never Met Before. I Need Your Urgent Assistance in Transferring the
Sum Of ($15.5m) to your account for safe keeping and investment this
is not a spam, its a real business that will benefit both of us. upon
receipt of your reply o
15.03.2019, 22:06, "Andy Shevchenko" :
> It makes harder to read and understand the code. One needs spend deciseconds /
> seconds to catch instead of santiseconds of time.
If it is true for someone (for example, for me it is almost as readable
as a simple size_t), then I agree with Geert who sa
_OSC now has a way to inform firmware that OS has the capability to
interpret HPX type 3 tables. Since ACPI 6.3 deprecated _OSC specifics,
these are now part of the PCI Firmware Specification.
The following is the document describing the changes:
ECN:_HPX and PCIe Completion Timeout related _O
Building the 32-bit vDSO with a recent clang version fails due
to undefined symbols:
arch/x86/entry/vdso/vdso32.so.dbg: undefined symbols found
The undefined symbol in this case is __lshrdi3, which is part of
the compiler runtime library, however the vDSO isn't linked against
this library.
Inclu
I am pleased with this patch. Yes there is still a couple of controversial
issues but in my opinion, it is mostly "matter of taste", and whatever solutions
could be made, the patch is great.
So you may add me to the "Acked-by" section.
(And I mean the whole patch from 1 to 5)
With Best Regards, A
On Fri, Mar 15, 2019 at 10:23:53PM +0300, Andrey Abramov wrote:
> 15.03.2019, 22:06, "Andy Shevchenko" :
> > It makes harder to read and understand the code. One needs spend
> > deciseconds /
> > seconds to catch instead of santiseconds of time.
>
> If it is true for someone (for example, for me
Updates from v5 [5]:
* Drop the new tain flag (TAINT_INSECURE)
* Cleanup copy_thread_tls(), some changelog, and unnecessary comments on
assembly macros
* Rearrange some helper updates appropriately (from patch 4 to 6)
Updates from v4 [4]:
* Remove the FSGSBASE assembly macros
Updates from v3 [3
From: Andy Lutomirski
This validates that GS and GSBASE are independently preserved across
context switches.
[ chang: Use FSGSBASE instructions directly instead of .byte ]
Signed-off-by: Andy Lutomirski
Reviewed-by: Andi Kleen
Signed-off-by: Chang S. Bae
Cc: H. Peter Anvin
Cc: Thomas Gleixn
It helps to use some new instructions directly in assembly code.
Suggested-by: Andi Kleen
Signed-off-by: Chang S. Bae
Reviewed-by: Andi Kleen
Acked-by: Andrew Morton
Cc: Andy Lutomirski
Cc: Linux Torvalds
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: H. Peter Anvin
---
Documentation/process/ch
From: Andy Lutomirski
With the new FSGSBASE instructions, we can efficiently read and write
the FSBASE and GSBASE in __switch_to(). Use that capability to preserve
the full state.
This will enable user code to do whatever it wants with the new
instructions without any kernel-induced gotchas. (
From: Andi Kleen
v2: Minor updates to documentation requested in review.
v3: Update for new gcc and various improvements.
Signed-off-by: Andi Kleen
Signed-off-by: Chang S. Bae
Cc: Andy Lutomirski
Cc: H. Peter Anvin
Cc: Thomas Gleixner
Cc: Ingo Molnar
---
Documentation/x86/fsgs.txt | 104 +
From: Andi Kleen
The kernel needs to explicitly enable FSGSBASE. So, the application needs
to know if it can safely use these instructions. Just looking at the CPUID
bit is not enough because it may be running in a kernel that does not
enable the instructions.
One way for the application would b
The FSGSBASE instructions allow fast accesses on GSBASE. Now, at the
paranoid_entry, the per-CPU base value can be always copied to GSBASE.
And the original GSBASE value will be restored at the exit.
So far, GSBASE modification has not been directly allowed from userspace.
So, swapping GSBASE has
From: Andy Lutomirski
Now that FSGSBASE is fully supported, remove unsafe_fsgsbase, enable
FSGSBASE by default, and add nofsgsbase to disable it.
Signed-off-by: Andy Lutomirski
Signed-off-by: Chang S. Bae
Reviewed-by: Andi Kleen
Cc: H. Peter Anvin
Cc: Thomas Gleixner
Cc: Ingo Molnar
---
.
GSBASE is used to find per-CPU data in the kernel. But when it is unknown,
the per-CPU base can be found from the per_cpu_offset table with a CPU NR.
The CPU NR is extracted from the limit field of the CPUNODE entry in GDT,
or by the RDPID instruction.
Also, add the GAS-compatible RDPID macro.
Th
From: Andi Kleen
Add C intrinsics and assembler macros for the new FSBASE and GSBASE
instructions.
Very straight forward. Used in followon patches.
[ luto: Rename the variables from FS and GS to FSBASE and GSBASE and
make safe to include on 32-bit kernels. ]
Signed-off-by: Andi Kleen
Signe
On 3/6/19 9:01 AM, John Stultz wrote:
On Wed, Mar 6, 2019 at 8:14 AM Benjamin Gaignard
wrote:
Le mar. 5 mars 2019 à 21:54, John Stultz a écrit :
+
+ printf("Allocating 1 MEG\n");
+ ret = dmabuf_heap_alloc(heap_fd, ONE_MEG, 0, &dmabuf_fd);
+ if (ret)
+ goto out;
Copy real FS/GSBASE values instead of approximation when FSGSBASE is
enabled.
Suggested-by: Andy Lutomirski
Signed-off-by: Chang S. Bae
Cc: Andy Lutomirski
Cc: H. Peter Anvin
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Andi Kleen
---
arch/x86/kernel/process_64.c | 15 +--
1 file ch
From: Andy Lutomirski
This is temporary. It will allow the next few patches to be tested
incrementally.
Setting unsafe_fsgsbase is a root hole. Don't do it.
Signed-off-by: Andy Lutomirski
Signed-off-by: Chang S. Bae
Reviewed-by: Andi Kleen
Reviewed-by: Andy Lutomirski
Cc: Thomas Gleixner
201 - 300 of 433 matches
Mail list logo
