On Fri, Jun 12, 2015 at 3:44 PM, Alexei Starovoitov wrote:
> On 6/12/15 3:08 PM, Andy Lutomirski wrote:
>>
>> On Fri, Jun 12, 2015 at 2:40 PM, Alexei Starovoitov
>> wrote:
>>>
>>> eBPF programs attached to kprobes need to filter based on
>>> current->pid, uid and other fields, so introduce helper
On 06/13, Oleg Nesterov wrote:
>
> Afaics, we need to ensure that:
>
> > + if (pgd_val(*pgd_src))
> > + WRITE_ONCE(*pgd_dst, *pgd_src);
>
> either we notice the recent update of this PGD, or (say) the subsequent
> sync_global_pgds() can miss the child.
a
On 06/12/2015 04:45 AM, Ingo Molnar wrote:
* Waiman Long wrote:
Mind posting the microbenchmark?
I have attached the tool that I used for testing.
Thanks, that's interesting!
Btw., we could also do something like this in user-space, in tools/perf/bench/,
we
have no 'perf bench locking' sub
On Fri, Jun 12, 2015 at 5:10 PM, Duc Dang wrote:
> Hi Bjorn,
>
> On Fri, Jun 12, 2015 at 2:59 PM, Bjorn Helgaas wrote:
>> Hi Duc,
>>
>> On Thu, Jun 11, 2015 at 01:08:14PM -0700, Duc Dang wrote:
>>> X-Gene v1 PCIe controller has a bug in Configuration Request Retry
>>> Status (CRS) logic:
>>> Wh
On Jun 12, 2015 12:59 AM, "Jan Beulich" wrote:
>
> >>> On 12.06.15 at 01:23, wrote:
> > There are two usages on MTRRs:
> > 1) MTRR entries set by firmware
> > 2) MTRR entries set by OS drivers
> >
> > We can obsolete 2), but we have no control over 1). As UEFI firmwares
> > also set this up, t
On Jun 12, 2015 1:43 AM, "Borislav Petkov" wrote:
>
> On Tue, Jun 09, 2015 at 09:46:52AM -0700, Andy Lutomirski wrote:
> > I don't like this hack. The compiler is entirely within is rights to
> > poke addr's cacheline (i.e. the stack) between the two instructions.
> > I'd suggest either making th
On 06/11, Ingo Molnar wrote:
>
> void sync_global_pgds(unsigned long start, unsigned long end, int removed)
> {
> @@ -169,29 +169,33 @@ void sync_global_pgds(unsigned long start, unsigned
> long end, int removed)
>
> for (address = start; address <= end; address += PGDIR_SIZE) {
>
Hallo
Hilsen fra SUN EAST Federal Credit Union, er vi godt etablert og godkjent
britiske lån selskaper, i løpet av årene har vi utviklet en god forståelse av
dine behov og individuelle behov. vi forpliktet oss til å behandle våre kunder
rettferdig og tilbyr en tjeneste som er profesjonell og
On 6/12/15 3:54 PM, Andy Lutomirski wrote:
On Fri, Jun 12, 2015 at 3:44 PM, Alexei Starovoitov wrote:
On 6/12/15 3:08 PM, Andy Lutomirski wrote:
On Fri, Jun 12, 2015 at 2:40 PM, Alexei Starovoitov
wrote:
eBPF programs attached to kprobes need to filter based on
current->pid, uid and other
On 06/11/2015 08:13 PM, Rob Herring wrote:
> On Thu, Jun 11, 2015 at 7:37 PM, Stephen Boyd wrote:
>> Add support for over current protection (OCP), pin control
>> selection, soft start and soft start strength, auto-mode, input
>> current limiting, and pull down.
>>
>> Cc:
>> Signed-off-by: Stephe
On Thu, Jun 11, 2015 at 4:47 AM, Denys Vlasenko wrote:
> "setbe %al" insn has a register merge stall: it needs to combine
> previous %eax value with new value for the lowest byte.
> Subsequent "movzbl %al,%edi" in turn depends on its completion.
>
> This patch replaces "setbe %al + movzbl %al,%edi
On Fri, Jun 12, 2015 at 4:23 PM, Alexei Starovoitov wrote:
> On 6/12/15 3:54 PM, Andy Lutomirski wrote:
>>
>> On Fri, Jun 12, 2015 at 3:44 PM, Alexei Starovoitov
>> wrote:
>>>
>>> On 6/12/15 3:08 PM, Andy Lutomirski wrote:
On Fri, Jun 12, 2015 at 2:40 PM, Alexei Starovoitov
w
On Jun 9, 2015 11:21 PM, "Ingo Molnar" wrote:
>
>
> * Denys Vlasenko wrote:
>
> > We use three MOVs to swap edx and ecx. We can use one XCHG instead.
> >
> > Expand the comments. It's difficult to keep track which arg# every register
> > corresponds to, so spell it out.
>
> > + /*
> > +
On Wed, Jun 10, 2015 at 1:18 PM, Kees Cook wrote:
> On Wed, Jun 10, 2015 at 10:20 AM, Andy Lutomirski wrote:
>> On Wed, Jun 10, 2015 at 9:31 AM, Oleg Nesterov wrote:
>>> On 06/09, Andy Lutomirski wrote:
On Tue, Jun 9, 2015 at 5:49 PM, Tycho Andersen
>
> @@ -556,6 +556,15 @@ s
On Fri, 2015-06-12 at 16:15 -0700, Andy Lutomirski wrote:
> On Jun 12, 2015 12:59 AM, "Jan Beulich" wrote:
> >
> > >>> On 12.06.15 at 01:23, wrote:
> > > There are two usages on MTRRs:
> > > 1) MTRR entries set by firmware
> > > 2) MTRR entries set by OS drivers
> > >
> > > We can obsolete 2),
On Fri, Jun 12, 2015 at 4:27 PM, Andy Lutomirski wrote:
> On Wed, Jun 10, 2015 at 1:18 PM, Kees Cook wrote:
>> On Wed, Jun 10, 2015 at 10:20 AM, Andy Lutomirski
>> wrote:
>>> On Wed, Jun 10, 2015 at 9:31 AM, Oleg Nesterov wrote:
On 06/09, Andy Lutomirski wrote:
>
> On Tue, Jun 9,
Hallo
Hilsen fra SUN EAST Federal Credit Union, er vi godt etablert og godkjent
britiske lån selskaper, i løpet av årene har vi utviklet en god forståelse av
dine behov og individuelle behov. vi forpliktet oss til å behandle våre kunder
rettferdig og tilbyr en tjeneste som er profesjonell og
On 06/12, Boris Ostrovsky wrote:
>
> On 06/12/2015 04:53 PM, Oleg Nesterov wrote:
>>>
>>> for_each_process(p) {
>>>
>>> for_each_thread(p, t) {
>>> if (t->mm) {
>>> do_something(t->mm);
>>> break;
>>>
On 6/12/15 4:25 PM, Andy Lutomirski wrote:
It's a dangerous tool. Also, shouldn't the returned uid match the
namespace of the task that installed the probe, not the task that's
being probed?
so leaking info to unprivileged apps is the concern?
The whole thing is for root only as you know.
The
After the some recent threads about rdtsc barriers, I remembered
that our RDTSC wrappers are a big mess. Let's clean it up.
Currently we have rdtscl, rdtscll, native_read_tsc,
paravirt_read_tsc, and rdtsc_barrier. For people who haven't
noticed rdtsc_barrier and who haven't carefully read the do
This timing code is hideous, and this doesn't help. It gets rid of
one of the last users of rdtscl, though.
Cc: Dmitry Torokhov
Cc: linux-in...@vger.kernel.org
Signed-off-by: Andy Lutomirski
---
drivers/input/joystick/analog.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --g
They have no users. Leave native_read_tscp, which seems potentially
useful despite also having no callers.
Signed-off-by: Andy Lutomirski
---
arch/x86/include/asm/msr.h | 9 -
arch/x86/include/asm/paravirt.h | 16
2 files changed, 25 deletions(-)
diff --git a/arc
Using get_cycles was unnecessary: check_tsc_warp() is not called on
TSC-less systems. Replace barrier_before_rdtsc(); get_cycles() with
rdtsc_ordered().
While we're at it, make the somewhat more dangerous change of
removing barrier_before_rdtsc after RDTSC in the TSC warp check
code. This should
There are two logical changes here. First, this removes a check for
cpu_has_tsc. That check is unnecessary, as we don't register the
TSC as a clocksource on systems that have no TSC. Second, it adds a
barrier, thus preventing observable non-monotonicity.
I suspect that the missing barrier was n
It's unclear to me why this code exists in the first place.
Cc: Dmitry Torokhov
Cc: linux-in...@vger.kernel.org
Signed-off-by: Andy Lutomirski
---
drivers/input/gameport/gameport.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/input/gameport/gameport.c
b/drive
barrier_before_rdtsc(); rdtsc_unordered() is an unnecessary mouthful and
requires more thought than should be necessary. Add an rdtsc_ordered()
helper and replace the trivial call sites with it.
This should not change generated code.
Signed-off-by: Andy Lutomirski
---
arch/x86/entry/vdso/vcloc
Using get_cycles was unnecessary: check_tsc_warp() is not called on
TSC-less systems. Replace barrier_before_rdtsc(); get_cycles() with
rdtsc_ordered().
While we're at it, make the somewhat more dangerous change of
removing barrier_before_rdtsc after RDTSC in the TSC warp check
code. This should
On 6/12/2015 9:29 AM, Borislav Petkov wrote:
On Thu, Jun 11, 2015 at 11:26:00AM -0700, Jonathan (Zhixiong) Zhang wrote:
From: "Jonathan (Zhixiong) Zhang"
With ACPI APEI firmware first handling, generic hardware error
record is updated by firmware in GHES memory region. When firmware
updated
Now that there is no paravirt TSC, the "native" is inappropriate.
The fact that rdtsc is not ordered can catch people by surprise, so
call it rdtsc_unordered().
Signed-off-by: Andy Lutomirski
---
arch/x86/boot/compressed/aslr.c | 2 +-
arch/x86/entry/vdso/vclock_gettime.c
rdtsc_barrier() (i.e. MFENCE or LFENCE depending on vendor) is
supported by the docs as a barrier immediately before RDTSC. There
is neither empirical evidence that it's needed at all after RDTSC
nor is there any reason to believe that the type of fence to put
after RDTSC (if any) would be the sam
It has no more callers, and it was never a very sensible interface
to begin with. Users of the TSC should either read all 64 bits or
explicitly throw out the high bits.
Signed-off-by: Andy Lutomirski
---
arch/x86/include/asm/msr.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/x86/i
They have no users. Leave native_read_tscp, which seems potentially
useful despite also having no callers.
Signed-off-by: Andy Lutomirski
---
arch/x86/include/asm/msr.h | 9 -
1 file changed, 9 deletions(-)
diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
index 7273
This code is timing 100k indirect calls, so the added overhead of
counting the number of cycles elapsed as a 64-bit number should be
insignificant. Drop the optimization of using a 32-bit count.
Signed-off-by: Andy Lutomirski
---
arch/x86/kernel/cpu/amd.c | 6 +++---
1 file changed, 3 insertion
It's unclear to me why this code exists in the first place.
Cc: Dmitry Torokhov
Cc: linux-in...@vger.kernel.org
Signed-off-by: Andy Lutomirski
---
drivers/input/gameport/gameport.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/input/gameport/gameport.c
b/drive
Using get_cycles was unnecessary: check_tsc_warp() is not called on
TSC-less systems. Replace barrier_before_rdtsc(); get_cycles() with
rdtsc_ordered().
While we're at it, make the somewhat more dangerous change of
removing barrier_before_rdtsc after RDTSC in the TSC warp check
code. This should
There are two logical changes here. First, this removes a check for
cpu_has_tsc. That check is unnecessary, as we don't register the
TSC as a clocksource on systems that have no TSC. Second, it adds a
barrier, thus preventing observable non-monotonicity.
I suspect that the missing barrier was n
It has no more callers, and it was never a very sensible interface
to begin with. Users of the TSC should either read all 64 bits or
explicitly throw out the high bits.
Signed-off-by: Andy Lutomirski
---
arch/x86/include/asm/msr.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/x86/i
rdtsc_barrier() (i.e. MFENCE or LFENCE depending on vendor) is
supported by the docs as a barrier immediately before RDTSC. There
is neither empirical evidence that it's needed at all after RDTSC
nor is there any reason to believe that the type of fence to put
after RDTSC (if any) would be the sam
On Fri, Jun 12, 2015 at 03:26:26PM -0700, Greg KH wrote:
> On Fri, Jun 12, 2015 at 10:06:16PM +0100, One Thousand Gnomes wrote:
> > On Fri, 12 Jun 2015 13:43:27 -0700
> > Greg KH wrote:
> >
> > > On Fri, Jun 12, 2015 at 10:20:38PM +0200, julien.de...@gmail.com wrote:
> > > > From: Julien Dehee
>
barrier_before_rdtsc(); rdtsc_unordered() is an unnecessary mouthful and
requires more thought than should be necessary. Add an rdtsc_ordered()
helper and replace the trivial call sites with it.
This should not change generated code.
Signed-off-by: Andy Lutomirski
---
arch/x86/entry/vdso/vcloc
Now that there is no paravirt TSC, the "native" is inappropriate.
The fact that rdtsc is not ordered can catch people by surprise, so
call it rdtsc_unordered().
Signed-off-by: Andy Lutomirski
---
arch/x86/boot/compressed/aslr.c | 2 +-
arch/x86/entry/vdso/vclock_gettime.c
On Fri, Jun 12, 2015 at 4:38 PM, Alexei Starovoitov wrote:
> On 6/12/15 4:25 PM, Andy Lutomirski wrote:
>>
>> It's a dangerous tool. Also, shouldn't the returned uid match the
>> namespace of the task that installed the probe, not the task that's
>> being probed?
>
>
> so leaking info to unprivil
As a very minor optimization, tsc_delay was only using the low 32
bits of the TSC. It's a delay function, so just use the whole
thing.
Signed-off-by: Andy Lutomirski
---
arch/x86/lib/delay.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/x86/lib/delay.c b/arch/
It wasn't compiled in by default. I suspect that the driver was and
still is broken, though -- it's calling udelay with a parameter
that's derived from loops_per_jiffy.
Cc: Jarod Wilson
Cc: de...@driverdev.osuosl.org
Cc: Greg Kroah-Hartman
Signed-off-by: Andy Lutomirski
---
drivers/staging/me
This timing code is hideous, and this doesn't help. It gets rid of
one of the last users of rdtscl, though.
Cc: Dmitry Torokhov
Cc: linux-in...@vger.kernel.org
Signed-off-by: Andy Lutomirski
---
drivers/input/joystick/analog.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --g
Now that the read_tsc paravirt hook is gone, rdtscll() is just a
wrapper around native_read_tsc(). Unwrap it.
Signed-off-by: Andy Lutomirski
---
arch/x86/boot/compressed/aslr.c | 2 +-
arch/x86/include/asm/msr.h | 3 ---
arch/x86/include/asm/tsc.h
This is only used if BAYCOM_DEBUG is defined.
Cc: Thomas Sailer
Cc: linux-h...@vger.kernel.org
Signed-off-by: Andy Lutomirski
---
drivers/net/hamradio/baycom_epp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/hamradio/baycom_epp.c
b/drivers/net/hamradio/bayco
On 6/12/2015 12:52 AM, Ingo Molnar wrote:
* Jonathan (Zhixiong) Zhang wrote:
From: "Jonathan (Zhixiong) Zhang"
This definition is used in APEI code when needing to map pages as
uncached.
Signed-off-by: Jonathan (Zhixiong) Zhang
---
arch/x86/include/asm/acpi.h | 4
1 file changed
The only caller was kvm's read_tsc. The only difference between
vget_cycles and native_read_tsc was that vget_cycles returned zero
instead of crashing on TSC-less systems. KVM's already checks
vclock_mode before calling that function, so the extra check is
unnecessary.
(Off-topic, but the whole
We've had read_tsc and read_tscp paravirt hooks since the very
beginning of paravirt, i.e., d3561b7fa0fb ("[PATCH] paravirt: header
and stubs for paravirtualisation"). AFAICT the only paravirt guest
implementation that ever replaced these calls was vmware, and it's
gone. Arguably even vmware shou
In cdc7957d1954 ("x86: move native_read_tsc() offline"),
native_read_tsc was moved out of line, presumably for some
now-obsolete vDSO-related reason. Undo it.
The entire rdtsc, shl, or sequence is only 11 bytes, and calls via
rdtscl and similar helpers were already inlined.
Signed-off-by: Andy L
My sincere apologies for the spam. I send an unholy mixture of the
real patch set and an old poorly split-up patch set, and the result
is incomprehensible. Here's what I meant to send.
After the some recent threads about rdtsc barriers, I remembered
that our RDTSC wrappers are a big mess. Let's
This code is timing 100k indirect calls, so the added overhead of
counting the number of cycles elapsed as a 64-bit number should be
insignificant. Drop the optimization of using a 32-bit count.
Signed-off-by: Andy Lutomirski
---
arch/x86/kernel/cpu/amd.c | 6 +++---
1 file changed, 3 insertion
It wasn't compiled in by default. I suspect that the driver was and
still is broken, though -- it's calling udelay with a parameter
that's derived from loops_per_jiffy.
Cc: Jarod Wilson
Cc: de...@driverdev.osuosl.org
Cc: Greg Kroah-Hartman
Signed-off-by: Andy Lutomirski
---
drivers/staging/me
This is only used if BAYCOM_DEBUG is defined.
Cc: Thomas Sailer
Cc: linux-h...@vger.kernel.org
Signed-off-by: Andy Lutomirski
---
drivers/net/hamradio/baycom_epp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/hamradio/baycom_epp.c
b/drivers/net/hamradio/bayco
As a very minor optimization, tsc_delay was only using the low 32
bits of the TSC. It's a delay function, so just use the whole
thing.
Signed-off-by: Andy Lutomirski
---
arch/x86/lib/delay.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/x86/lib/delay.c b/arch/
rdtscll() was a wrapper around native_read_tsc(). Unwrap it.
Signed-off-by: Andy Lutomirski
---
arch/x86/boot/compressed/aslr.c | 2 +-
arch/x86/include/asm/msr.h | 3 ---
arch/x86/include/asm/paravirt.h | 2 --
arch/x86/includ
Now that the read_tsc paravirt hook is gone, rdtscll() is just a
wrapper around native_read_tsc(). Unwrap it.
Signed-off-by: Andy Lutomirski
---
arch/x86/boot/compressed/aslr.c | 2 +-
arch/x86/include/asm/msr.h | 3 ---
arch/x86/include/asm/tsc.h
They have no users. Leave native_read_tscp, which seems potentially
useful despite also having no callers.
Signed-off-by: Andy Lutomirski
---
arch/x86/include/asm/msr.h | 9 -
1 file changed, 9 deletions(-)
diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
index 7273
We've had read_tsc and read_tscp paravirt hooks since the very
beginning of paravirt, i.e., d3561b7fa0fb ("[PATCH] paravirt: header
and stubs for paravirtualisation"). AFAICT the only paravirt guest
implementation that ever replaced these calls was vmware, and it's
gone. Arguably even vmware shou
We've had read_tsc and read_tscp paravirt hooks since the very
beginning of paravirt, i.e., d3561b7fa0fb ("[PATCH] paravirt: header
and stubs for paravirtualisation"). AFAICT the only paravirt guest
implementation that ever replaced these calls was vmware, and it's
gone. Arguably even vmware shou
The only caller was kvm's read_tsc. The only difference between
vget_cycles and native_read_tsc was that vget_cycles returned zero
instead of crashing on TSC-less systems. KVM's already checks
vclock_mode before calling that function, so the extra check is
unnecessary.
(Off-topic, but the whole
In cdc7957d1954 ("x86: move native_read_tsc() offline"),
native_read_tsc was moved out of line, presumably for some
now-obsolete vDSO-related reason. Undo it.
The entire rdtsc, shl, or sequence is only 11 bytes, and calls via
rdtscl and similar helpers were already inlined.
Signed-off-by: Andy L
On 6/12/15 4:47 PM, Andy Lutomirski wrote:
On Fri, Jun 12, 2015 at 4:38 PM, Alexei Starovoitov wrote:
On 6/12/15 4:25 PM, Andy Lutomirski wrote:
It's a dangerous tool. Also, shouldn't the returned uid match the
namespace of the task that installed the probe, not the task that's
being probed?
1) Fix uninitialized struct station_info in cfg80211_wireless_stats(), from
Johannes Berg.
2) Revert commit attempt to fix ipv6 protocol resubmission, it adds
regressions.
3) Endless loops can be created in bridge port lists, fix from Nikolay
Aleksandrov.
4) Don't WARN_ON() if sk->sk_f
On Thu, Jun 04, 2015 at 04:26:07PM -0700, K. Y. Srinivasan wrote:
> From: Vitaly Kuznetsov
>
> Loaded Hyper-V module will use these functions to disable CPU
> hotplug under certain circumstances. Convert cpu_hotplug_disabled
> to a counter (protected by cpu_add_remove_lock) to support e.g.
> disa
On Fri, Jun 12, 2015 at 4:55 PM, Alexei Starovoitov wrote:
> On 6/12/15 4:47 PM, Andy Lutomirski wrote:
>>
>> On Fri, Jun 12, 2015 at 4:38 PM, Alexei Starovoitov
>> wrote:
>>>
>>> On 6/12/15 4:25 PM, Andy Lutomirski wrote:
It's a dangerous tool. Also, shouldn't the returned uid ma
On Fri, Jun 12, 2015 at 04:37:41PM +0100, Ian Abbott wrote:
> Normally, low-level Comedi drivers set an `insn_bits` handler for
> digital input (DI), digital output (DO) and digital input/output (DIO)
> subdevice types to handle normal reading and writing of digital
> channels. The "cb_pcimdas" dr
The SYSCALL prologue starts with SWAPGS immediately followed by a
gs-prefixed instruction. I think this causes a pipeline stall.
If we instead do:
mov %rsp, rsp_scratch(%rip)
mov sp0(%rip), %rsp)
swapgs
...
pushq rsp_scratch(%rip)
then we avoid the stall and save about three cycles.
Horrible h
On 06/13/2015 01:43 AM, Alan Stern wrote:
On Fri, 12 Jun 2015, Lu Baolu wrote:
Commit 25cd2882e2fc ("usb/xhci: Change how we indicate a host supports
Link PM.") removed the code to set lpm_capable for USB 3.0 super-speed
root hub. The intention of that change was to avoid touching usb core
in
On 6/12/15 5:03 PM, Andy Lutomirski wrote:
On Fri, Jun 12, 2015 at 4:55 PM, Alexei Starovoitov wrote:
On 6/12/15 4:47 PM, Andy Lutomirski wrote:
On Fri, Jun 12, 2015 at 4:38 PM, Alexei Starovoitov
wrote:
On 6/12/15 4:25 PM, Andy Lutomirski wrote:
It's a dangerous tool. Also, shouldn't
On Tue, Jun 09, 2015 at 05:58:24PM +0300, Andrew Andrianov wrote:
> This patch adds a generic ion driver that allows
> ion heaps to be added via devicetree. It provides
> a simple and generic way to feed physical memory regions
> to ion without writing a custom driver, e.g.
>
> ion_sram: ion
On Tue, Jun 09, 2015 at 04:59:01PM -0500, J. German Rivera wrote:
> This patch series includes new functionality for the Freescale fsl-mc
> bus driver.
Why are people working on "new functionality" instead of working on
getting this out of the staging tree? I really hate adding new
functions to s
On Fri, Jun 12, 2015 at 5:15 PM, Alexei Starovoitov wrote:
> On 6/12/15 5:03 PM, Andy Lutomirski wrote:
>>
>> On Fri, Jun 12, 2015 at 4:55 PM, Alexei Starovoitov
>> wrote:
>>>
>>> On 6/12/15 4:47 PM, Andy Lutomirski wrote:
On Fri, Jun 12, 2015 at 4:38 PM, Alexei Starovoitov
w
On 6/12/15 5:24 PM, Andy Lutomirski wrote:
>so what specifically you proposing?
>Use from_kuid(&init_user_ns,...) instead?
That seems reasonable to me. After all, you can't install one of
these probes from a non-init userns.
ok. will respin with that change.
--
To unsubscribe from this list:
On Thu, May 28, 2015 at 03:07:05PM +0300, Dmitry Kalinkin wrote:
> This introduces a new dma device that provides a single ioctl call that
> provides DMA read and write functionality to the user space.
>
> Signed-off-by: Dmitry Kalinkin
> Cc: Igor Alekseev
> ---
> drivers/staging/vme/devices/vm
Add a "param_lock" mutex to each module, and update params.c to use
the correct built-in or module mutex while locking kernel params.
Remove the kparam_block_sysfs_r/w() macros, replace them with direct
calls to kernel_param_[un]lock(module).
The kernel param code currently uses a single mutex to
On Wed, Jun 10, 2015 at 04:09:19PM +0300, Dmitry Kalinkin wrote:
> On Sun, May 31, 2015 at 6:06 AM, Greg Kroah-Hartman
> wrote:
> > On Thu, May 28, 2015 at 03:06:57PM +0300, Dmitry Kalinkin wrote:
> >> The first item in this submission documents previously introduced
> >> vme_master_mmap() call. F
On Thu, May 28, 2015 at 03:07:13PM +0300, Dmitry Kalinkin wrote:
> This separates VME related constants that are a part of both kernel and
> user space API into a common uapi header.
Why? We don't want non-userspace things in the uapi header file, that's
not needed and just exports things to user
On Mon, Jun 08, 2015 at 11:28:13AM +0530, Bhuvanchandra DV wrote:
> Hello,
>
> Ping!
>
> On 06/01/2015 10:51 AM, Bhuvanchandra DV wrote:
7 days later? Please be patient...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kern
X-Gene v1 PCIe controller has a bug in Configuration Request Retry
Status (CRS) logic:
When CPU tries to read Vendor ID and Device ID of not-existed
remote device, the controller returns 0x0001 instead of
0x; this will add significant delay in boot time as
pci_bus_read_dev_vendo
On Fri, Jun 12, 2015 at 09:32:31AM +0200, Claudio Cappelli wrote:
> On Wednesday 10 June 2015 20:38:30 Claudio Cappelli wrote:
> > From: Claudio Cappelli
> >
> > Add device Olivetti Olicard 300 (Network Connect: MT6225) - IDs 2020:4000.
> >
> > Signed-off-by: Claudio Cappelli
> > Suggested-by:
On Mon, Jun 8, 2015 at 6:14 PM, John Stultz wrote:
> After setting up functionfs for adb w/ 4.1-rc7, I noticed some flakey
> behavior.
> I enabled some lock debugging and got the following:
>
> [ 91.648093] read strings
> [ 91.650264] g_ffs gadget: g_ffs ready
> [ 91.652551] ci_hdrc ci_hdrc
From: "Jonathan (Zhixiong) Zhang"
On a platform with APEI (ACPI Platform Error Interface) enabled, firmware
updates a memory region with hardware error record using nocache
attribute. When OS reads the region, since it maps the region with
cacahed attribute even though EFI memory map defines this
From: "Jonathan (Zhixiong) Zhang"
x86 and ia64 implement efi_mem_attributes() differently. This
function needs to be available for other arch (such as arm64)
as well, such as for the purpose of ACPI/APEI.
ia64 efi does not setup memmap variable and does not set
EFI_MEMMAP flag, so it needs to ha
From: "Jonathan (Zhixiong) Zhang"
... to allow arch specific implementation of getting page
protection type associated with a physical address.
If the physical address has memory attributes defined by EFI
memmap as EFI_MEMORY_UC, the page protection type is
PAGE_KENERL_NOCACHE. Otherwise, the pa
From: "Jonathan (Zhixiong) Zhang"
With ACPI APEI firmware first handling, generic hardware error
record is updated by firmware in GHES memory region. When firmware
updated GHES memory region with uncached access attribute, Linux
reads stale data from cache.
GHES memory region should be mapped wi
From: "Jonathan (Zhixiong) Zhang"
If the physical address has memory attributes defined by EFI
memmap as EFI_MEMORY_UC, the page protection type is
PROT_DEVICE_nGnRE. Otherwise, the page protection type is
PAGE_KERNEL.
Signed-off-by: Jonathan (Zhixiong) Zhang
---
arch/arm64/kernel/Makefile |
On Fri, 12 Jun 2015, Steven Rostedt wrote:
> On Fri, 12 Jun 2015 17:18:22 -0400 (EDT)
> Vince Weaver wrote:
>
> >
> > So I've modified my fuzzer to try to exercise the
> > PERF_EVENT_IOC_SET_FILTER ioctl() and it is starting to turn up some
> > warnings.
>
> Is there any way to know what the
On 2015/06/13 4:12, Arnaldo Carvalho de Melo wrote:
> Em Fri, Jun 12, 2015 at 02:08:13PM +0900, Masami Hiramatsu escreveu:
>> Since commit 5e17b28f1e24 ("perf probe: Add --quiet option to
>> suppress output result message") have replaced printf with pr_info,
>> perf probe -l outputs its result in s
On 2015/06/13 4:17, Arnaldo Carvalho de Melo wrote:
> Em Fri, Jun 12, 2015 at 02:08:27PM +0900, Masami Hiramatsu escreveu:
>> Fix to check both of non-exist symbols and kprobe blacklist symbols at
>> symbol-map based converting too.
>>
>> E.g. without this fix, perf-probe failes to write the event.
On Fri, 12 Jun 2015 21:15:10 -0400 (EDT)
Vince Weaver wrote:
> On Fri, 12 Jun 2015, Steven Rostedt wrote:
>
> > On Fri, 12 Jun 2015 17:18:22 -0400 (EDT)
> > Vince Weaver wrote:
> >
> > >
> > > So I've modified my fuzzer to try to exercise the
> > > PERF_EVENT_IOC_SET_FILTER ioctl() and it is
When the last part of converted events are blacklisted or out-of-text,
those are skipped and perf probe doesn't show usage examples.
This fixes it to show the example even if the last part of event list
is skipped.
E.g. without this patch, events are added, but suddenly end;
# perf probe
Hi Arnaldo,
Here is the updated series of bugfix patches for perf-probe.
I've fixed inverted bool flags bug on the 1/3.
This series fixes below bugs;
- --list shows the list of probes in stderr.
(It is refined from https://lkml.org/lkml/2015/5/30/34)
- non-probe-able symbols (out of .text) a
Fix to check both of non-exist symbols and kprobe blacklist symbols at
symbol-map based converting too.
E.g. without this fix, perf-probe failes to write the event.
# perf probe vfs_caches_init_early
Added new event:
Failed to write event: Invalid argument
Error: Failed to add eve
Since commit 5e17b28f1e24 ("perf probe: Add --quiet option to
suppress output result message") have replaced printf with pr_info,
perf probe -l outputs its result in stderr. However, that is not
what the commit expected.
e.g.
-
# perf probe -l > /dev/null
probe:vfs_read (on vfs_re
On 2015/06/13 4:27, Arnaldo Carvalho de Melo wrote:
> Hi Masami,
>
> I tried somethig with perf probe today, namely to ask for a
> variable that is a struct perf_event_attr to be collected after
> the perf_event_open syscall copies it from userspace, and got this
> message:
>
> [root@zoo ~]
On Tue, Jun 09, 2015 at 10:01:45AM +0100, Lorenzo Pieralisi wrote:
> When a PCI bus is scanned, upon PCI bridge detection the kernel
> has to read the bridge registers to set-up its resources so that
> the PCI resource hierarchy can be validated properly.
>
> Most if not all architectures read PCI
Arnaldo Carvalho de Melo [a...@kernel.org] wrote:
| Em Thu, Jun 11, 2015 at 11:00:04PM -0700, Sukadev Bhattiprolu escreveu:
| > >From 6669ed960a3ee4f9a02790f60b6a73ffc82fd6de Mon Sep 17 00:00:00 2001
| > From: Sukadev Bhattiprolu
| > Date: Fri, 12 Jun 2015 01:28:36 -0400
| > Subject: [PATCH] perf,
On Sat, Jun 13, 2015 at 3:31 AM, Greg Kroah-Hartman
wrote:
> On Wed, Jun 10, 2015 at 04:09:19PM +0300, Dmitry Kalinkin wrote:
>> Also, there are some patches that IMO don't need any special VME
>> subsystem expertise, namely:
>> Documentation: mention vme_master_mmap() in VME API
>> vme: ca91c
601 - 700 of 759 matches
Mail list logo
