From: Alexander Usyskin
Fix the hbm power gating state machine so it will wait till it receives
confirmation interrupt for the PG_ISOLATION_EXIT message.
In process of the suspend flow the devices first have to exit from the
power gating state (runtime pm resume).
If we do not handle the
The '__init aesni_init()' function calls the '__exit crypto_fpu_exit()'
function directly. Since they are in different sections, this generates
a warning.
make CONFIG_DEBUG_SECTION_MISMATCH=y
...
WARNING: arch/x86/crypto/aesni-intel.o(.init.text+0x12b): Section
mismatch in reference from
On 6/12/15 9:11 PM, pi3orama wrote:
发自我的 iPhone
在 2015年6月13日，上午10:31，Alexei Starovoitov 写道：
On 6/11/15 10:35 PM, Wang Nan wrote:
# Path to clang. If omit, search it from $PATH.
clang-path = "/path/to/clang"
I think this bit and search_program() from the next patch is
overly
On Sat, Jun 13, 2015 at 05:30:09AM +0300, Dmitry Kalinkin wrote:
>
> > On 13 Jun 2015, at 05:24, Greg Kroah-Hartman
> > wrote:
> >
> > On Sat, Jun 13, 2015 at 05:04:28AM +0300, Dmitry Kalinkin wrote:
> >> On Sat, Jun 13, 2015 at 3:31 AM, Greg Kroah-Hartman
> >> wrote:
> >> I thought 12 was
发自我的 iPhone
> 在 2015年6月13日，上午10:31，Alexei Starovoitov 写道：
>
>> On 6/11/15 10:35 PM, Wang Nan wrote:
>> # Path to clang. If omit, search it from $PATH.
>>clang-path = "/path/to/clang"
>
> I think this bit and search_program() from the next patch is
> overly flexible. It's always
coming back to this ...
On 6/12/15 2:39 PM, Liang, Kan wrote:
Yes, perf always can read proc file. The problem is that the proc file
is huge and keep growing faster than proc reader.
So perf top do loop in perf_event__synthesize_mmap_events until the
test case exit.
I'm confused. How are you
I think you misunderstand partial register stalls. They happen (on some
microarchitectures) when you write part of a register and then use the whole
register.
As you say, we do need the branch anyway, which is a good reason to do it, but
the motivation is wrong.
Sent from my tablet, pardon
On 6/12/15 4:41 PM, Liang, Kan wrote:
On 6/12/15 2:39 PM, Liang, Kan wrote:
Here are the test results.
Please note that I get "synthesized threads took..." after the test case
exit.
It means both way have the same issue.
Got it. So what you really mean is launching perf on an already
Dudley,
On Fri, Jun 12, 2015 at 02:56:37PM +0800, Dudley Du wrote:
> Add of_match_device machanism support for Cypress trackpad device, and
> add the sample description document of adding the trackpad device node in DT.
> TEST=test on Chromebook.
>
> Signed-off-by: Dudley Du
> ---
>
On Fri, Jun 12, 2015 at 12:12:47AM +0900, Seunghun Lee wrote:
> Encryption mode is unsupported when blocksize != pagesize.
>
> Signed-off-by: Seunghun Lee
This only checks for blocksize != pagesize in the case where the test
dummy encryption mount option is given. We need to check also for the
发自我的 iPhone
> 在 2015年6月13日，上午11:03，Alexei Starovoitov 写道：
>
>> On 6/12/15 7:52 PM, pi3orama wrote:
>>
>>
>> 发自我的 iPhone
>>
在 2015年6月13日，上午10:31，Alexei Starovoitov 写道：
On 6/11/15 10:35 PM, Wang Nan wrote:
# Path to clang. If omit, search it from $PATH.
On 06/11/2015 10:21 AM, Will Deacon wrote:
Hi Waiman,
On Tue, Jun 09, 2015 at 04:19:12PM +0100, Waiman Long wrote:
The qrwlock is fair in the process context, but becoming unfair when
in the interrupt context to support use cases like the tasklist_lock.
However, the unfair code in the
On 6/12/15 7:52 PM, pi3orama wrote:
发自我的 iPhone
在 2015年6月13日，上午10:31，Alexei Starovoitov 写道：
On 6/11/15 10:35 PM, Wang Nan wrote:
# Path to clang. If omit, search it from $PATH.
clang-path = "/path/to/clang"
I think this bit and search_program() from the next patch is
overly
On 6/12/15 12:27 PM, Arnaldo Carvalho de Melo wrote:
Alexei, is this already possible with eBPF?
I want to decode that attr_uptr thing :-)
yes, it's already possible :)
Here is working example from our experimental c+python thingy:
#!/usr/bin/env python
from bpf import BPF
from subprocess
发自我的 iPhone
> 在 2015年6月13日，上午10:31，Alexei Starovoitov 写道：
>
>> On 6/11/15 10:35 PM, Wang Nan wrote:
>> # Path to clang. If omit, search it from $PATH.
>>clang-path = "/path/to/clang"
>
> I think this bit and search_program() from the next patch is
> overly flexible. It's always
Hi,
On Fri, Jun 12, 2015 at 03:25:51PM +0300, Anda-Maria Nicolae wrote:
> The result of container_of macro cannot be NULL, so there is no need to
> check whether info is NULL.
Thanks, queued for 4.2.
-- Sebastian
signature.asc
Description: Digital signature
eBPF programs attached to kprobes need to filter based on
current->pid, uid and other fields, so introduce helper functions:
u64 bpf_get_current_pid_tgid(void)
Return: current->tgid << 32 | current->pid
u64 bpf_get_current_uid_gid(void)
Return: current_gid << 32 | current_uid
v1->v2: switched to init_user_ns from current_user_ns as suggested by Andy
Introduce new helpers to access 'struct task_struct'->pid, tgid, uid, gid, comm
fields in tracing and networking.
Share bpf_trace_printk() and bpf_get_smp_processor_id() helpers between
tracing and networking.
Alexei
It's useful to do per-cpu histograms.
Suggested-by: Daniel Wagner
Signed-off-by: Alexei Starovoitov
---
v1->v2: no changes
kernel/trace/bpf_trace.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index 4f9b5d41869b..88a041adee90
bpf_trace_printk() is a helper function used to debug eBPF programs.
Let socket and TC programs use it as well.
Note, it's DEBUG ONLY helper. If it's used in the program,
the kernel will print warning banner to make sure users don't use
it in production.
Signed-off-by: Alexei Starovoitov
---
On 6/11/15 10:35 PM, Wang Nan wrote:
# Path to clang. If omit, search it from $PATH.
clang-path = "/path/to/clang"
I think this bit and search_program() from the next patch is
overly flexible. It's always delicate to search file paths.
Unless this is really needed, I would
> On 13 Jun 2015, at 05:24, Greg Kroah-Hartman
> wrote:
>
> On Sat, Jun 13, 2015 at 05:04:28AM +0300, Dmitry Kalinkin wrote:
>> On Sat, Jun 13, 2015 at 3:31 AM, Greg Kroah-Hartman
>> wrote:
>> I thought 12 was the most harmless out of the whole set. Am I wrong?
>
> You added a new userspace
On Friday, June 12, 2015 08:01:15 AM Roland Dreier wrote:
> On Thu, Jun 11, 2015 at 1:50 PM, Rafael J. Wysocki wrote:
> > Changing the ordering between those two routines would work around that
> > problem,
> > but in my view that wouldn't be a proper fix. In fact, the role of
> >
On Sat, Jun 13, 2015 at 05:04:28AM +0300, Dmitry Kalinkin wrote:
> 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,
On Thu, Jun 11, 2015 at 11:43:58AM +0200, Rasmus Villemoes wrote:
> Whatever the "historical reasons" were back around 1996 when this
> comment was added,
>
> git grep -E '\b_(S?SIZE|TIME|CLOCK|PTRDIFF|CADDR)_T\b'
>
> seems to say that they are no longer relevant. Relieve the
> preprocessor
Pantelis Antoniou konsulko.com> writes:
...
> +static ssize_t
> +configfs_write_bin_file(struct file *file, const char __user *buf,
> + size_t count, loff_t *ppos)
> +{
...
> + len = simple_write_to_buffer(buffer->bin_buffer,
> +
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:
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]
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
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
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
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
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)
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
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
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
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
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
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
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 |
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
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
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
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:
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
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
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
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.
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 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
> ---
>
On 6/12/15 5:24 PM, Andy Lutomirski wrote:
>so what specifically you proposing?
>Use from_kuid(_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: send
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
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
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:
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 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
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
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"
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.
>
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
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
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
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
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
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
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
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
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 --
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
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
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
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
---
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
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
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
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.
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
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
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
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
---
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
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
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
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
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
---
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
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
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
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
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
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
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
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
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
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
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
1 - 100 of 1492 matches
Mail list logo
