Re: linux-next: manual merge of the mac80211-next tree with the mac80211 tree
Hi Stephen,
> between commit:
>
> b71d856ab536 ("mac80211_hwsim: add workqueue to wait for deferred radio
> deletion on mod unload")
>
> from the mac80211 tree and commit:
>
> c6509cc3b3e8 ("mac80211_hwsim: add hashtable with mac address keys for
> faster lookup")
>
> from the mac80211-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary.
Yeah, thanks. I was pondering whether I should knowingly generate that
conflict, but I'll fix it up before merge anyway - might hold the -next
for later anyway.
Thanks!
johannes
[PATCH] MAINTAINERS: add the iommu list for swiotlb and xen-swiotlb
All other discussions related to the dma mapping interfaces are on the iommu list, so let's make it the official list for swiotlb and the second list for xen-swiotlb. Signed-off-by: Christoph Hellwig --- MAINTAINERS | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 2d54e636d625..30dcafd388ac 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -13034,7 +13034,7 @@ F: arch/x86/boot/video* SWIOTLB SUBSYSTEM M: Konrad Rzeszutek Wilk -L: linux-kernel@vger.kernel.org +L: io...@lists.linux-foundation.org T: git git://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb.git S: Supported F: lib/swiotlb.c @@ -14969,6 +14969,7 @@ F: include/xen/interface/io/vscsiif.h XEN SWIOTLB SUBSYSTEM M: Konrad Rzeszutek Wilk L: xen-de...@lists.xenproject.org (moderated for non-subscribers) +L: io...@lists.linux-foundation.org S: Supported F: arch/x86/xen/*swiotlb* F: drivers/xen/*swiotlb* -- 2.14.2
Re: consolidate swiotlb dma_map implementations
I've pulled this into the dma-mapping for-next tree, including the missing free_pages noted. I'd be fine to rebase another day or two for additional reviews or important fixes.
Re: consolidate direct dma mapping V4
I've pulled this into the dma-mapping for-next branch so that we get a few days exposure before then end of the merge window. If there is anything important (e.g. the powerpc naming issue) please send incremental patches.
Re: [Suspected-Phishing]Re: [PATCH V3 1/2] nvme: split resetting state into reset_prepate and resetting
On 01/16/2018 01:57 PM, jianchao.wang wrote:
> Hi Max
>
> Thanks for your kindly comment.
>
> On 01/15/2018 09:36 PM, Max Gurtovoy wrote:
> case NVME_CTRL_RECONNECTING:
> switch (old_state) {
> case NVME_CTRL_LIVE:
> case NVME_CTRL_RESETTING:
> + case NVME_CTRL_RESET_PREPARE:
>>
>> I forget to add that we shouldn't move from RESET_PREPARE to RECONNECTING
>> (with my suggestion to rdma.c).
>> Also need to consider adding another check in nvmf_check_init_req
>> (/drivers/nvme/host/fabrics.h) for the new state.
>
> After Sagi's nvme-rdma: fix concurrent reset and reconnect, the rdma ctrl
> state is changed to RECONNECTING state
> after some clearing and shutdown work, then some initializing procedure, no
> matter reset work path or error recovery path.
> The fc reset work also does the same thing.
> So if we define the range that RESET_PREPARE includes scheduling gap and
> disable and clear work, RESETTING includes initializing
> procedure, RECONNECTING is very similar with RESETTING.
>
> Maybe we could do like this;
> In nvme fc/rdma
> - set state to RESET_PREPARE, queue reset_work/err_work
> - clear/shutdown works, set state to RECONNECTING
> - initialization, set state to LIVE
>
> In nvme pci
> - set state to RESET_PREPARE, queue reset_work
> - clear/shutdown works, set state to RESETTING
> - initialization, set state to LIVE
Hi Christoph, Keith, Sagi
Can you please comment on this ?
Thanks in advance.
Jianchao
what trees/branches to test on syzbot
Hello, Several people proposed that linux-next should not be tested on syzbot. While some people suggested that it needs to test as many trees as possible. I've initially included linux-next as it is a staging area before upstream tree, with the intention that patches are _tested_ there, is they are not tested there, bugs enter upstream tree. And then it takes much longer to get fix into other trees. So the question is: what trees/branches should be tested? Preferably in priority order as syzbot can't test all of them. Thanks
Re: LKML admins (syzbot emails are not delivered)
On Tue, Jan 16, 2018 at 8:12 AM, Theodore Ts'o wrote: > On Mon, Jan 15, 2018 at 10:38:42AM -0600, Eric W. Biederman wrote: >> >> Sometimes the branches on linux-next are experimental crap. If someone >> adds an experimental memory allocator to linux-next before discovering >> it causes all kinds of problems I don't want bug reports about my code >> not being able to allocate memory because the memory allocator was bad. >> >> If you don't have the resources to test the individual branches of >> linux-next please just test Linus's tree. That will be much more >> meaningful and productive. > > I have to agree with Eric here, the reason why Fengguang Wu's 0-day > testing robot is much better received by developers is that he does > not test linux-net, I will remove linux-next if there is a general agreement that it's not useful. Though, I've heard different opinions from kernel developers as well. I will write a separate email asking what branches should be tested.
[PATCH v3 1/3] trace-cmd: Make read_proc() to return int status via OUT arg
This patch changes both the implementation and the interface of read_proc()
in trace-stack.c. First, it makes the function to read a string from the proc
file and then parse it as an integer using strtol(). Then, it makes the function
to return the integer read from the proc file using the int *status OUT
parameter, in order to make possible its return value to be used by the caller
to check if the operation succeeded.
This new implementation relaxes the external contraints the function relies on,
making it possible to be used by trace stat. The point is that 'stat' should not
fail in case there is something wrong with the stack tracer. Only the call to
die() in case the file is empty has been left in this patch: it will be removed
as well in a separate commit.
Signed-off-by: Vladislav Valtchev (VMware)
---
trace-stack.c | 79 +++
1 file changed, 63 insertions(+), 16 deletions(-)
diff --git a/trace-stack.c b/trace-stack.c
index aa79ae3..c1058ca 100644
--- a/trace-stack.c
+++ b/trace-stack.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -49,37 +50,79 @@ static void test_available(void)
die("stack tracer not configured on running kernel");
}
-static char read_proc(void)
+/*
+ * Returns:
+ * -1 - Something went wrong
+ *0 - File does not exist (stack tracer not enabled)
+ *1 - Success
+ */
+static int read_proc(int *status)
{
- char buf[1];
+ struct stat stat_buf;
+ char buf[64];
+ long num;
int fd;
int n;
+ if (stat(PROC_FILE, &stat_buf) < 0) {
+ /* stack tracer not configured on running kernel */
+ *status = 0; /* not configured means disabled */
+ return 0;
+ }
+
fd = open(PROC_FILE, O_RDONLY);
- if (fd < 0)
- die("reading %s", PROC_FILE);
- n = read(fd, buf, 1);
- close(fd);
- if (n != 1)
+
+ if (fd < 0) {
+ /* we cannot open the file: likely a permission problem. */
+ return -1;
+ }
+
+ n = read(fd, buf, sizeof(buf));
+
+ /* We assume that the file is never empty we got no errors. */
+ if (n <= 0)
die("error reading %s", PROC_FILE);
- return buf[0];
+ /* Does this file have more than 63 characters?? */
+ if (n >= sizeof(buf))
+ return -1;
+
+ /* n is guaranteed to be in the range [1, sizeof(buf)-1]. */
+ buf[n] = 0;
+ close(fd);
+
+ errno = 0;
+
+ /* Read an integer from buf ignoring any non-digit trailing characters.
*/
+ num = strtol(buf, NULL, 10);
+
+ /* strtol() returned 0: we have to check for errors */
+ if (!num && (errno == EINVAL || errno == ERANGE))
+ return -1;
+
+ if (num > INT_MAX || num < INT_MIN)
+ return -1; /* the number is good but does not fit in 'int' */
+
+ *status = num;
+ return 1; /* full success */
}
-static void start_stop_trace(char val)
+/* NOTE: this implementation only accepts new_status in the range [0..9]. */
+static void change_stack_tracer_status(int new_status)
{
char buf[1];
+ int status;
int fd;
int n;
- buf[0] = read_proc();
- if (buf[0] == val)
- return;
+ if (read_proc(&status) > 0 && status == new_status)
+ return; /* nothing to do */
fd = open(PROC_FILE, O_WRONLY);
+
if (fd < 0)
die("writing %s", PROC_FILE);
- buf[0] = val;
+ buf[0] = new_status + '0';
n = write(fd, buf, 1);
if (n < 0)
die("writing into %s", PROC_FILE);
@@ -88,12 +131,12 @@ static void start_stop_trace(char val)
static void start_trace(void)
{
- start_stop_trace('1');
+ change_stack_tracer_status(1);
}
static void stop_trace(void)
{
- start_stop_trace('0');
+ change_stack_tracer_status(0);
}
static void reset_trace(void)
@@ -123,8 +166,12 @@ static void read_trace(void)
char *buf = NULL;
size_t n;
int r;
+ int status;
- if (read_proc() == '1')
+ if (read_proc(&status) <= 0)
+ die("Invalid stack tracer state");
+
+ if (status > 0)
printf("(stack tracer running)\n");
else
printf("(stack tracer not running)\n");
--
2.14.1
[PATCH v3 2/3] trace-cmd: Remove the die() call from read_proc()
As trace-stack.c's read_proc() function is going to be used by trace-cmd stat,
we don't want it to make the program die in case something went wrong.
Therefore, this simple patch makes read_proc() to just return -1 in case the
proc file was empty or read() failed with an error, instead of using die().
Signed-off-by: Vladislav Valtchev (VMware)
---
trace-stack.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/trace-stack.c b/trace-stack.c
index c1058ca..d55d994 100644
--- a/trace-stack.c
+++ b/trace-stack.c
@@ -79,9 +79,9 @@ static int read_proc(int *status)
n = read(fd, buf, sizeof(buf));
- /* We assume that the file is never empty we got no errors. */
+ /* The file was empty or read() failed with an error. */
if (n <= 0)
- die("error reading %s", PROC_FILE);
+ return -1;
/* Does this file have more than 63 characters?? */
if (n >= sizeof(buf))
--
2.14.1
[PATCH] perf stat: Ignore error thread when enabling system-wide --per-thread
If we execute 'perf stat --per-thread' with non-root account
(even set kernel.perf_event_paranoid = -1 yet), it reports the error:
jinyao@skl:~$ perf stat --per-thread
Error:
You may not have permission to collect system-wide stats.
Consider tweaking /proc/sys/kernel/perf_event_paranoid,
which controls use of the performance events system by
unprivileged users (without CAP_SYS_ADMIN).
The current value is 2:
-1: Allow use of (almost) all events by all users
Ignore mlock limit after perf_event_mlock_kb without CAP_IPC_LOCK
>= 0: Disallow ftrace function tracepoint by users without CAP_SYS_ADMIN
Disallow raw tracepoint access by users without CAP_SYS_ADMIN
>= 1: Disallow CPU event access by users without CAP_SYS_ADMIN
>= 2: Disallow kernel profiling by users without CAP_SYS_ADMIN
To make this setting permanent, edit /etc/sysctl.conf too, e.g.:
kernel.perf_event_paranoid = -1
Perhaps the ptrace rule doesn't allow to trace some processes. But anyway
the global --per-thread mode had better ignore such errors and continue
working on other threads.
This patch will record the index of error thread in perf_evsel__open()
and remove this thread before retrying.
For example (run with non-root, kernel.perf_event_paranoid isn't set):
jinyao@skl:~$ perf stat --per-thread
^C
Performance counter stats for 'system wide':
vmstat-3458 6.171984 cpu-clock:u (msec)#
0.000 CPUs utilized
perf-3670 0.515599 cpu-clock:u (msec)#
0.000 CPUs utilized
vmstat-3458 1,163,643 cycles:u #
0.189 GHz
perf-3670 40,881 cycles:u #
0.079 GHz
vmstat-3458 1,410,238 instructions:u#
1.21 insn per cycle
perf-3670 3,536 instructions:u#
0.09 insn per cycle
vmstat-3458288,937 branches:u#
46.814 M/sec
perf-3670936 branches:u#
1.815 M/sec
vmstat-3458 15,195 branch-misses:u #
5.26% of all branches
perf-3670 76 branch-misses:u #
8.12% of all branches
12.651675247 seconds time elapsed
Signed-off-by: Jin Yao
---
tools/perf/builtin-stat.c| 14 +-
tools/perf/util/evsel.c | 3 +++
tools/perf/util/thread_map.c | 1 +
tools/perf/util/thread_map.h | 1 +
4 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 98bf9d3..bcdb47c 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -632,7 +632,19 @@ static int __run_perf_stat(int argc, const char **argv)
if (verbose > 0)
ui__warning("%s\n", msg);
goto try_again;
-}
+ } else if (target__has_per_thread(&target) &&
+ evsel_list->threads &&
+ evsel_list->threads->err_thread != -1) {
+ /*
+* For global --per-thread case, skip current
+* error thread.
+*/
+ if (!thread_map__remove(evsel_list->threads,
+
evsel_list->threads->err_thread)) {
+ evsel_list->threads->err_thread = -1;
+ goto try_again;
+ }
+ }
perf_evsel__open_strerror(counter, &target,
errno, msg, sizeof(msg));
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index a4d256e..12f8733 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -1899,6 +1899,9 @@ int perf_evsel__open(struct perf_evsel *evsel, struct
cpu_map *cpus,
goto fallback_missing_features;
}
out_close:
+ if (err)
+ threads->err_thread = thread;
+
do {
while (--thread >= 0) {
close(FD(evsel, cpu, thread));
diff --git a/tools/perf/util/thread_map.c b/tools/perf/util/thread_map.c
index 3e1038f..870cb0c 100644
--- a/tools/perf/util/thread_map.c
+++ b/tools/perf/util/thread_map.c
@@ -32,6 +32,7 @@ static void thread_map__reset(struct thread_map *map, int
start, int nr)
size_t size = (nr - start) * sizeof(map->map[0]);
memset(&map->map[start], 0, size);
+ map->err_thread = -1;
}
static struct thread_map *thread_map__realloc(struct thread_map *map, int nr)
diff --git a/tools/perf/util/thread_map.h b/tools/per
[PATCH v3 0/3] Integrate stack tracer status in 'stat'
This short patch series makes trace-cmd stat aware of the stack tracer: now, when the stack tracker is ON, the command will report that. Vladislav Valtchev (VMware) (3): trace-cmd: Make read_proc() to return int status via OUT arg trace-cmd: Remove the die() call from read_proc() trace-cmd: Making stat to report when the stack tracer is ON trace-cmd.h | 2 ++ trace-stack.c | 85 --- trace-stat.c | 8 ++ 3 files changed, 79 insertions(+), 16 deletions(-) -- 2.14.1
[PATCH v3 3/3] trace-cmd: Making stat to report when the stack tracer is ON
trace-cmd stat is a handy way for users to see what tracing is currently going
on, but currently it does not say anything about the stack tracing. This patch
makes the command to show a message when the stack tracer is ON.
Signed-off-by: Vladislav Valtchev (VMware)
---
trace-cmd.h | 2 ++
trace-stack.c | 6 ++
trace-stat.c | 8
3 files changed, 16 insertions(+)
diff --git a/trace-cmd.h b/trace-cmd.h
index 6fd34d7..9704b2e 100644
--- a/trace-cmd.h
+++ b/trace-cmd.h
@@ -358,6 +358,8 @@ void tracecmd_free_hooks(struct hook_list *hooks);
/* --- Hack! --- */
int tracecmd_blk_hack(struct tracecmd_input *handle);
+/* --- Stack tracer functions --- */
+int tracecmd_stack_tracer_status(int *status);
/* --- Debugging --- */
struct kbuffer *tracecmd_record_kbuf(struct tracecmd_input *handle,
diff --git a/trace-stack.c b/trace-stack.c
index d55d994..0028ecc 100644
--- a/trace-stack.c
+++ b/trace-stack.c
@@ -107,6 +107,12 @@ static int read_proc(int *status)
return 1; /* full success */
}
+/* Public wrapper of read_proc() */
+int tracecmd_stack_tracer_status(int *status)
+{
+ return read_proc(status);
+}
+
/* NOTE: this implementation only accepts new_status in the range [0..9]. */
static void change_stack_tracer_status(int new_status)
{
diff --git a/trace-stat.c b/trace-stat.c
index fd16354..23d7dd4 100644
--- a/trace-stat.c
+++ b/trace-stat.c
@@ -893,6 +893,7 @@ void trace_stat (int argc, char **argv)
{
struct buffer_instance *instance = &top_instance;
int topt = 0;
+ int status;
int c;
for (;;) {
@@ -928,5 +929,12 @@ void trace_stat (int argc, char **argv)
stat_instance(instance);
}
+ if (tracecmd_stack_tracer_status(&status) >= 0) {
+ if (status > 0)
+ printf("Stack tracing is enabled\n\n");
+ } else {
+ printf("Error reading stack tracer status\n\n");
+ }
+
exit(0);
}
--
2.14.1
Re: [PATCH] mm: memory: fixed a coding style issue
On Mon 15-01-18 19:17:12, Robert Donald Rickett wrote:
> This is a patch to the memory.c file that fixes the
> "ERROR: code indent should use tabs where possible"
> found by the checkpatch.pl tool.
Is this really worth it? The code is not any better readable and it just
adds a churn to the history and makes life of anybody using git blame
slightly more harder. So what is the benefit?
> Signed-off-by: Robert Donald Rickett
> ---
> mm/memory.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/memory.c b/mm/memory.c
> index ca5674cbaff2..e9f6e58aa77c 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -1663,7 +1663,7 @@ int zap_vma_ptes(struct vm_area_struct *vma, unsigned
> long address,
> unsigned long size)
> {
> if (address < vma->vm_start || address + size > vma->vm_end ||
> - !(vma->vm_flags & VM_PFNMAP))
> + !(vma->vm_flags & VM_PFNMAP))
> return -1;
> zap_page_range_single(vma, address, size, NULL);
> return 0;
> --
> 2.14.1
--
Michal Hocko
SUSE Labs
[PATCH] mtd: onenand: omap2: print resource using %pR format string
The omap2 onenand driver is now available for compile-testing, which
uncovers a warning in configurations that have a 64-bit resource_size_t:
drivers/mtd/onenand/omap2.c: In function 'omap2_onenand_probe':
drivers/mtd/onenand/omap2.c:536:54: error: format '%x' expects argument of type
'unsigned int', but argument 3 has type 'resource_size_t {aka long long
unsigned int}' [-Werror=format=]
dev_err(dev, "Cannot reserve memory region at 0x%08x, size: 0x%x\n",
drivers/mtd/onenand/omap2.c:536:66: error: format '%x' expects argument of type
'unsigned int', but argument 4 has type 'resource_size_t {aka long long
unsigned int}' [-Werror=format=]
Changing the format string to the special %pR simplifies the code
and lets it do the right thing in that configuration, while avoiding
the warning.
Fixes: a758f50f10cf ("mtd: onenand: omap2: Configure driver from DT")
Signed-off-by: Arnd Bergmann
---
drivers/mtd/onenand/omap2.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
index 2ce73fb6da1c..a4a2159bcfb7 100644
--- a/drivers/mtd/onenand/omap2.c
+++ b/drivers/mtd/onenand/omap2.c
@@ -533,8 +533,7 @@ static int omap2_onenand_probe(struct platform_device *pdev)
c->onenand.base = devm_ioremap_resource(dev, res);
if (IS_ERR(c->onenand.base)) {
- dev_err(dev, "Cannot reserve memory region at 0x%08x, size:
0x%x\n",
- res->start, resource_size(res));
+ dev_err(dev, "Cannot reserve memory region %pR\n", res);
return PTR_ERR(c->onenand.base);
}
--
2.9.0
Re: [PATCH 4.14 053/118] Revert "Revert "xfrm: Fix stack-out-of-bounds read in xfrm_state_find.""
Le 16/01/2018 à 07:33, Steffen Klassert a écrit : > On Mon, Jan 15, 2018 at 11:56:12AM -0500, David Miller wrote: >> From: Steffen Klassert >> Date: Mon, 15 Jan 2018 14:23:29 +0100 >> >>> On Mon, Jan 15, 2018 at 01:34:40PM +0100, Greg Kroah-Hartman wrote: 4.14-stable review patch. If anyone has any objections, please let me know. -- From: "David S. Miller" This reverts commit 94802151894d482e82c324edf2c658f8e6b96508. It breaks transport mode when the policy template has wildcard addresses configured. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman >>> >>> Hm, this seems to be one revert too much. >>> >>> commit 94802151894d482e82c324edf2c658f8e6b96508 reverted already >>> the buggy commit. Reverting the revert will bring the bug back. >> >> Steffen, in the email where you asked me to revert that is the >> commit ID you referenced. > > I think there was a misunderstanding. I asked you to queue the > commit with that ID to stable on Dec 23 (this commit ID is the > revert of the buggy patch). This commit was included to stable > on Jan 4 then: > > https://www.spinics.net/lists/stable/msg208727.html > > So with this, everything was ok. > > Maybe you started to look again into this because Nicolas Dichtel > (Cced) asked to queue this patch on Jan 5, the patch was already > in the stable tree (Jan 4) but probably not in an actual release > at this time. Oh, I didn't find it at this time in the linux-stable tree nor in the stable patchwork. Bad timing :/ I still don't find it in the patchwork: http://patchwork.ozlabs.org/bundle/davem/stable/?series=&submitter=1442&state=*&q=&archive=both Am I missing something? > >> >> We can drop this, but you need to then tell us whether 4.14 needs >> the revert any longer and if so what the correct SHA ID would >> be. > > I think we can we can just drop this. > > Unless Nicolas knows something that is still missing, v4.14.12 and > above should be ok as is. I agree, we can drop this. Thank you, Nicolas
Re: KASAN: slab-out-of-bounds Write in tcp_v6_syn_recv_sock
On Thu, Jan 4, 2018 at 12:31 AM, Cong Wang wrote: > On Wed, Jan 3, 2018 at 12:55 PM, Ozgur wrote: >> >> >> 03.01.2018, 21:57, "Cong Wang" : >>> On Tue, Jan 2, 2018 at 3:58 PM, syzbot >>> wrote: Hello, syzkaller hit the following crash on 61233580f1f33c50e159c50e24d80ffd2ba2e06b git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master compiler: gcc (GCC) 7.1.1 20170620 .config is attached Raw console output is attached. C reproducer is attached syzkaller reproducer is attached. See https://goo.gl/kgGztJ for information about syzkaller reproducers IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+6dc95bddc6976b800...@syzkaller.appspotmail.com It will help syzbot understand when the bug is fixed. See footer for details. If you forward the report, please keep this part and the footer. TCP: request_sock_TCPv6: Possible SYN flooding on port 20002. Sending cookies. Check SNMP counters. == BUG: KASAN: slab-out-of-bounds in memcpy include/linux/string.h:344 [inline] BUG: KASAN: slab-out-of-bounds in tcp_v6_syn_recv_sock+0x628/0x23a0 net/ipv6/tcp_ipv6.c:1144 Write of size 160 at addr 8801cbdd7460 by task syzkaller545407/3196 CPU: 1 PID: 3196 Comm: syzkaller545407 Not tainted 4.15.0-rc5+ #241 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:17 [inline] dump_stack+0x194/0x257 lib/dump_stack.c:53 print_address_description+0x73/0x250 mm/kasan/report.c:252 kasan_report_error mm/kasan/report.c:351 [inline] kasan_report+0x25b/0x340 mm/kasan/report.c:409 check_memory_region_inline mm/kasan/kasan.c:260 [inline] check_memory_region+0x137/0x190 mm/kasan/kasan.c:267 memcpy+0x37/0x50 mm/kasan/kasan.c:303 memcpy include/linux/string.h:344 [inline] tcp_v6_syn_recv_sock+0x628/0x23a0 net/ipv6/tcp_ipv6.c:1144 >>> >>> tls_init() changes sk->sk_prot from IPv6 to IPv4, which leads >>> to this bug. I guess IPv6 is not supported for TLS? If so, need >>> a check on proto in tls_init()... >> >> Hello, >> >> I think IPv6 supports with TLS. >> There was a previously posted commit by Mellanox: >> >> https://patchwork.ozlabs.org/patch/801530/ > > Good to know. > > Can you resend the fix? It could probably fix another warning > reported by syzbot too. FTR this has been assigned CVE-2018-5703
R: Re: [PATCH 8/8] KVM: x86: add SPEC_CTRL and IBPB_SUPPORT to MSR and CPUID lists
- Eric Wheeler ha scritto: > On Sat, 13 Jan 2018, Paolo Bonzini wrote: > > > Just add the new MSR at the end of the array. > > I'm assuming you meant emulated_msrs[], correct? No, msrs_to_save. It's just above emulated_msrs. Paolo > > > -- > Eric Wheeler > > > > > > > Paolo > > > > - Eric Wheeler ha scritto: > > > On Tue, 9 Jan 2018, Paolo Bonzini wrote: > > > > > > > Expose them to userspace, now that guests can use them. > > > > I am not adding cpufeatures here to avoid having a kernel > > > > that shows spec_ctrl in /proc/cpuinfo and actually has no > > > > support whatsoever for IBRS/IBPB. Keep the ugly special-casing > > > > for now, and clean it up once the generic arch/x86/ code > > > > learns about them. > > > > > > > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > > > > index daa1918031df..4abb37d9f4d8 100644 > > > > --- a/arch/x86/kvm/x86.c > > > > +++ b/arch/x86/kvm/x86.c > > > > @@ -1032,6 +1032,7 @@ unsigned int kvm_get_pt_addr_cnt(void) > > > > MSR_IA32_RTIT_ADDR1_A, MSR_IA32_RTIT_ADDR1_B, > > > > MSR_IA32_RTIT_ADDR2_A, MSR_IA32_RTIT_ADDR2_B, > > > > MSR_IA32_RTIT_ADDR3_A, MSR_IA32_RTIT_ADDR3_B, > > > > + MSR_IA32_SPEC_CTRL, > > > > }; > > > > > > Hi Paolo, > > > > > > Thank you for posting this! > > > > > > I am trying to merge this into 4.14 which does not have > > > kvm_get_pt_addr_cnt. The rest of the patch commits, but this gets > > > rejected. Is this a necessary part of the commit? > > > > > > patching file arch/x86/kvm/cpuid.c > > > Hunk #1 succeeded at 389 (offset -8 lines). > > > Hunk #2 succeeded at 479 (offset -9 lines). > > > Hunk #3 succeeded at 636 (offset -27 lines). > > > patching file arch/x86/kvm/x86.c > > > Hunk #1 FAILED at 1032. > > > 1 out of 1 hunk FAILED -- saving rejects to file arch/x86/kvm/x86.c.rej > > > > > > ]# cat arch/x86/kvm/x86.c.rej > > > --- arch/x86/kvm/x86.c > > > +++ arch/x86/kvm/x86.c > > > @@ -1032,6 +1032,7 @@ > > > MSR_IA32_RTIT_ADDR1_A, MSR_IA32_RTIT_ADDR1_B, > > > MSR_IA32_RTIT_ADDR2_A, MSR_IA32_RTIT_ADDR2_B, > > > MSR_IA32_RTIT_ADDR3_A, MSR_IA32_RTIT_ADDR3_B, > > > + MSR_IA32_SPEC_CTRL, > > > }; > > > > > > static unsigned num_msrs_to_save; > > > > > > > > > Thank you for your help! > > > > > > -- > > > Eric Wheeler > > > > > > > > > > > > > > static unsigned num_msrs_to_save; > > > > -- > > > > 1.8.3.1 > > > > > > > > > > > > > > > >
Re: [PATCH 04/14] mmc: mmci: Add STM32 variant
On Mon, Jan 15, 2018 at 6:17 PM, Patrice CHOTARD wrote:
>>> + {
>>> + .id = 0x00880180,
>>> + .mask = 0x00ff,
>>> + .data = &variant_stm32,
>>> + },
>>
>> Since ux500 was 480180 I wonder what variants 5,6,7 are...
>
> What is the rule to define the id ?
These four bits mean "revision".
The number comes from hardware, so the ST ASIC department
has some person who is responsible for revising the VHDL or
Verilog code that this hardware is compiled from, and that person
is bumping the version.
Theoretically it is a "company function" or something bureaucratic
like that updating the hardware so I guess it could be several
people following procedure who have updated this number in the
hardware over the years.
But I bet it is a single person in Grenoble who has been doing
the MMC/SD block since it appeared.
Yours,
Linus Walleij
Re: [PATCH] soc: xilinx: xlnx_vcu: Depends on HAS_IOMEM for xlnx_vcu
On 16.1.2018 07:34, Dhaval Shah wrote: > xlnx_vcu driver uses devm_ioremap_nocache, which is included > only when HAS_IOMEM is enabled. > > drivers/soc/xilinx/xlnx_vcu.o: In function `xvcu_probe': >xlnx_vcu.c:(.text+0x116): undefined reference to `devm_ioremap_nocache' >xlnx_vcu.c:(.text+0x1ae): undefined reference to `devm_ioremap_nocache' > > Signed-off-by: Dhaval Shah > --- > drivers/soc/xilinx/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/soc/xilinx/Kconfig b/drivers/soc/xilinx/Kconfig > index 266b50f..bf657ab 100644 > --- a/drivers/soc/xilinx/Kconfig > +++ b/drivers/soc/xilinx/Kconfig > @@ -3,6 +3,7 @@ menu "Xilinx SoC drivers" > > config XILINX_VCU > tristate "Xilinx VCU logicoreIP Init" > + depends on HAS_IOMEM > help >Provides the driver to enable and disable the isolation between the >processing system and programmable logic part by using the > logicoreIP > Applied. Thanks, Michal
Re: [PATCH 4.9 27/75] net: igmp: Use correct source address on IGMPv3 reports
Am 16.01.2018 um 06:55 schrieb Greg Kroah-Hartman: On Tue, Jan 16, 2018 at 04:50:39AM +0100, Sebastian Gottschall wrote: please revert that on 4.9 and 4.14 it breaks igmp routing. it can be reproduced with any iptv connection using igmp-proxy. reverting this patch fixes the issue. So Linus's kernel also is broken for you? Or does it work properly there?^ all kernels are broken since 3th january. 3.18, 4.4, 4.9. 4.14 unless this patch is removed. this can be verified with deutsche telekom iptv and igmp-proxy. i just stumbled accross this issue recently while i updated my kernel source to latest revision. last working revision i tested with iptv was late december and iptv stopped working after updating. so i stepped back until i found this small patch which did the magic Sebastian thanks, greg k-h -- Mit freundlichen Grüssen / Regards Sebastian Gottschall / CTO NewMedia-NET GmbH - DD-WRT Firmensitz: Stubenwaldallee 21a, 64625 Bensheim Registergericht: Amtsgericht Darmstadt, HRB 25473 Geschäftsführer: Peter Steinhäuser, Christian Scheele http://www.dd-wrt.com email: s.gottsch...@dd-wrt.com Tel.: +496251-582650 / Fax: +496251-5826565
[PATCH] powerpc/8xx: do not select CONFIG_PPC_LIB_RHEAP
Since commit 0e6e01ff694ee ("CPM/QE: use genalloc to manage CPM/QE
muram"), rheap is not used anymore.
Signed-off-by: Christophe Leroy
---
arch/powerpc/platforms/Kconfig.cputype | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/platforms/Kconfig.cputype
b/arch/powerpc/platforms/Kconfig.cputype
index 8944b24d2218..5a8b1bf1e819 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -33,7 +33,6 @@ config PPC_85xx
config PPC_8xx
bool "Freescale 8xx"
select FSL_SOC
- select PPC_LIB_RHEAP
select SYS_SUPPORTS_HUGETLBFS
config 40x
--
2.13.3
Re: [PATCH] ARM: dts: nomadik: add interrupt-parent for clcd
On Mon, Jan 15, 2018 at 5:37 PM, Arnd Bergmann wrote:
> The clcd device is lacking an interrupt-parent property, which makes
> the interrupt unusable and shows up as a warning with the latest
> dtc version:
>
> arch/arm/boot/dts/ste-nomadik-s8815.dtb: Warning (interrupts_property):
> Missing interrupt-parent for /amba/clcd@1012
> arch/arm/boot/dts/ste-nomadik-nhk15.dtb: Warning (interrupts_property):
> Missing interrupt-parent for /amba/clcd@1012
>
> I looked up the old board files and found that this interrupt has
> the same irqchip as all the other on-chip device, it just needs one
> extra line.
>
> Fixes: 17470b7da11c ("ARM: dts: add the CLCD LCD display to the NHK15")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Arnd Bergmann
Reviewed-by: Linus Walleij
Sorry for not getting to fixing this myself quickly enough.
Yours,
Linus Walleij
[patch v17 1/4] drivers: jtag: Add JTAG core driver
Initial patch for JTAG driver JTAG class driver provide infrastructure to support hardware/software JTAG platform drivers. It provide user layer API interface for flashing and debugging external devices which equipped with JTAG interface using standard transactions. Driver exposes set of IOCTL to user space for: - XFER: - SIR (Scan Instruction Register, IEEE 1149.1 Data Register scan); - SDR (Scan Data Register, IEEE 1149.1 Instruction Register scan); - RUNTEST (Forces the IEEE 1149.1 bus to a run state for a specified number of clocks). - SIOCFREQ/GIOCFREQ for setting and reading JTAG frequency. Driver core provides set of internal APIs for allocation and registration: - jtag_register; - jtag_unregister; - jtag_alloc; - jtag_free; Platform driver on registration with jtag-core creates the next entry in dev folder: /dev/jtagX Signed-off-by: Oleksandr Shamray Signed-off-by: Jiri Pirko Acked-by: Philippe Ombredanne --- v16->v17 Comments pointed by Julia Cartwright - Fix memory allocation on jtag alloc - Move out unnecessary form lock on jtag open - Rework jtag register behavior v15->v16 Commen ts pointed by Florian Fainelli - move check jtag->ops->* in ioctl before get_user() - change error type -EINVAL --> -EBUSY on open already opened jtag - remove unnecessary ARCH_DMA_MINALIGN flag from kzalloc - remove define ARCH_DMA_MINALIGN v14->v15 v13->v14 Comments pointed by Philippe Ombredanne - Change style of head block comment from /**/ to // v12->v13 Comments pointed by Philippe Ombredanne - Change jtag.c licence type to SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note and reorder line with license in description v11->v12 Comments pointed by Greg KH - Change jtag.h licence type to SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note and reorder line with license in description Chip Bilbrey - Remove Apeed reference from uapi jtag.h header - Remove access mode from xfer and idle transactions - Add new ioctl JTAG_SIOCMODE for set hw mode - Add only one open per JTAG port blocking with mutex blocking v10->v11 Notifications from kbuild test robot - include types.h headeri to jtag.h - fix incompatible type of xfer callback - remove rdundant class defination - Fix return order in case of xfer error V9->v10 Comments pointed by Greg KH - remove unnecessary alignment for pirv data - move jtag_copy_to_user and jtag_copy_from_user code just to ioctl - move int jtag_run_test_idle_op and jtag_xfer_op code just to ioctl - change return error codes to more applicable - add missing error checks - fix error check order in ioctl - remove unnecessary blank lines - add param validation to ioctl - remove compat_ioctl - remove only one open per JTAG port blocking. User will care about this. - Fix idr memory leak on jtag_exit - change cdev device type to misc V8->v9 Comments pointed by Arnd Bergmann - use get_user() instead of __get_user(). - change jtag->open type from int to atomic_t - remove spinlock on jtg_open - remove mutex on jtag_register - add unregister_chrdev_region on jtag_init err - add unregister_chrdev_region on jtag_exit - remove unnecessary pointer casts - add *data parameter to xfer function prototype v7->v8 Comments pointed by Moritz Fischer - Fix misspelling s/friver/driver v6->v7 Notifications from kbuild test robot - Remove include asm/types.h from jtag.h - Add include to jtag.c v5->v6 v4->v5 v3->v4 Comments pointed by Arnd Bergmann - change transaction pointer tdio type to __u64 - change internal status type from enum to __u32 - reorder jtag_xfer members to avoid the implied padding - add __packed attribute to jtag_xfer and jtag_run_test_idle v2->v3 Notifications from kbuild test robot - Change include path to in jtag.h v1->v2 Comments pointed by Greg KH - Change license type from GPLv2/BSD to GPLv2 - Change type of variables which crossed user/kernel to __type - Remove "default n" from Kconfig Comments pointed by Andrew Lunn - Change list_add_tail in jtag_unregister to list_del Comments pointed by Neil Armstrong - Add SPDX-License-Identifier instead of license text Comments pointed by Arnd Bergmann - Change __copy_to_user to memdup_user - Change __put_user to put_user - Change type of variables to __type for compatible 32 and 64-bit systems - Add check for maximum xfer data size - Change lookup data mechanism to get jtag data from inode - Add .compat_ioctl to file ops - Add mem alignment for jtag priv data Comments pointed by Tobias Klauser - Change function names to avoid match with variable types - Fix description for jtag_ru_test_idle in uapi jtag.h - Fix misprints IDEL/IDLE, trough/through --- Documentation/ioctl/ioctl-number.txt |2 + MAINTAINERS | 10 ++ drivers/Kconfig |2 + drivers/Makefile |1 + drivers/jtag/Kconfig | 16 ++ drivers/jtag/Makefile|1 + drivers/jtag/jtag.c | 284
[patch v17 4/4] Documentation: jtag: Add ABI documentation
Added document that describe the ABI for JTAG class drivrer Signed-off-by: Oleksandr Shamray Acked-by: Arnd Bergmann --- v16->v17 v15->v16 v14->v15 v13->v14 v12->v13 v11->v12 Tobias Klauser - rename /Documentation/ABI/testing/jatg-dev -> jtag-dev - Typo: s/interfase/interface v10->v11 v9->v10 Fixes added by Oleksandr: - change jtag-cdev to jtag-dev in documentation - update Kernel Version and Date in jtag-dev documentation; v8->v9 v7->v8 v6->v7 Comments pointed by Pavel Machek - Added jtag-cdev documentation to Documentation/ABI/testing folder --- Documentation/ABI/testing/jtag-dev | 27 +++ 1 files changed, 27 insertions(+), 0 deletions(-) create mode 100644 Documentation/ABI/testing/jtag-dev diff --git a/Documentation/ABI/testing/jtag-dev b/Documentation/ABI/testing/jtag-dev new file mode 100644 index 000..cea9552 --- /dev/null +++ b/Documentation/ABI/testing/jtag-dev @@ -0,0 +1,27 @@ +What: /dev/jtag[0-9]+ +Date: October 2017 +KernelVersion: 4.17 +Contact: oleksan...@mellanox.com +Description: + The misc device files /dev/jtag* are the interface + between JTAG master interface and userspace. + + The ioctl(2)-based ABI is defined and documented in + [include/uapi]. + + The following file operations are supported: + + open(2) + The argument flag currently support only one access + mode O_RDWR. + + ioctl(2) + Initiate various actions. + See the inline documentation in [include/uapi] + for descriptions of all ioctls. + + close(2) + Stops and free up the I/O contexts that was associated + with the file descriptor. + +Users: TBD \ No newline at end of file -- 1.7.1
[patch v17 2/4] drivers: jtag: Add Aspeed SoC 24xx and 25xx families JTAG master driver
Driver adds support of Aspeed 2500/2400 series SOC JTAG master controller. Driver implements the following jtag ops: - freq_get; - freq_set; - status_get; - idle; - xfer; It has been tested on Mellanox system with BMC equipped with Aspeed 2520 SoC for programming CPLD devices. Signed-off-by: Oleksandr Shamray Signed-off-by: Jiri Pirko Acked-by: Arnd Bergmann Acked-by: Philippe Ombredanne Acked-by: Joel Stanley --- v16->v17 v15->v16 Comments pointed by Joel Stanley - Add reset_control on Jtag init/deinit v14->v15 Comments pointed by Joel Stanley - Add ARCH_ASPEED || COMPILE_TEST to Kconfig - remove unused offset variable - remove "aspeed_jtag" from dev_err and dev_dbg messages - change clk_prepare_enable initialisation order v13->v14 Comments pointed by Philippe Ombredanne - Change style of head block comment from /**/ to // v12->v13 Comments pointed by Philippe Ombredanne - Change jtag-aspeed.c licence type to SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note and reorder line with license in description Comments pointed by Kun Yi - Changed capability check for aspeed,ast2400-jtag/ast200-jtag v11->v12 Comments pointed by Chip Bilbrey - Remove access mode from xfer and idle transactions - Add new ioctl JTAG_SIOCMODE for set hw mode v10->v11 v9->v10 V8->v9 Comments pointed by Arnd Bergmann - add *data parameter to xfer function prototype v7->v8 Comments pointed by Joel Stanley - aspeed_jtag_init replace goto to return; - change input variables type from __u32 to u32 in functios freq_get, freq_set, status_get - change sm_ variables type from char to u8 - in jatg_init add disable clocks on error case - remove release_mem_region on error case - remove devm_free_irq on jtag_deinit - Fix misspelling Disabe/Disable - Change compatible string to ast2400 and ast2000 v6->v7 Notifications from kbuild test robot - Add include to jtag-asapeed.c v5->v6 v4->v5 Comments pointed by Arnd Bergmann - Added HAS_IOMEM dependence in Kconfig to avoid "undefined reference to `devm_ioremap_resource'" error, because in some arch this not supported v3->v4 Comments pointed by Arnd Bergmann - change transaction pointer tdio type to __u64 - change internal status type from enum to __u32 v2->v3 v1->v2 Comments pointed by Greg KH - change license type from GPLv2/BSD to GPLv2 Comments pointed by Neil Armstrong - Add clk_prepare_enable/clk_disable_unprepare in clock init/deinit - Change .compatible to soc-specific compatible names aspeed,aspeed4000-jtag/aspeed5000-jtag - Added dt-bindings Comments pointed by Arnd Bergmann - Reorder functions and removed the forward declarations - Add static const qualifier to state machine states transitions - Change .compatible to soc-specific compatible names aspeed,aspeed4000-jtag/aspeed5000-jtag - Add dt-bindings Comments pointed by Randy Dunlap - Change module name jtag-aspeed in description in Kconfig Comments pointed by kbuild test robot - Remove invalid include - add resource_size instead of calculation --- drivers/jtag/Kconfig | 14 + drivers/jtag/Makefile |1 + drivers/jtag/jtag-aspeed.c | 785 3 files changed, 800 insertions(+), 0 deletions(-) create mode 100644 drivers/jtag/jtag-aspeed.c diff --git a/drivers/jtag/Kconfig b/drivers/jtag/Kconfig index 0fad1a3..63ddf1f 100644 --- a/drivers/jtag/Kconfig +++ b/drivers/jtag/Kconfig @@ -14,3 +14,17 @@ menuconfig JTAG To compile this driver as a module, choose M here: the module will be called jtag. + +menuconfig JTAG_ASPEED + tristate "Aspeed SoC JTAG controller support" + depends on JTAG && HAS_IOMEM + depends on ARCH_ASPEED || COMPILE_TEST + ---help--- + This provides a support for Aspeed JTAG device, equipped on + Aspeed SoC 24xx and 25xx families. Drivers allows programming + of hardware devices, connected to SoC through the JTAG interface. + + If you want this support, you should say Y here. + + To compile this driver as a module, choose M here: the module will + be called jtag-aspeed. diff --git a/drivers/jtag/Makefile b/drivers/jtag/Makefile index af37493..04a855e 100644 --- a/drivers/jtag/Makefile +++ b/drivers/jtag/Makefile @@ -1 +1,2 @@ obj-$(CONFIG_JTAG) += jtag.o +obj-$(CONFIG_JTAG_ASPEED) += jtag-aspeed.o diff --git a/drivers/jtag/jtag-aspeed.c b/drivers/jtag/jtag-aspeed.c new file mode 100644 index 000..9cbd6da --- /dev/null +++ b/drivers/jtag/jtag-aspeed.c @@ -0,0 +1,785 @@ +// SPDX-License-Identifier: GPL-2.0 +// drivers/jtag/aspeed-jtag.c +// +// Copyright (c) 2017 Mellanox Technologies. All rights reserved. +// Copyright (c) 2017 Oleksandr Shamray + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define ASPEED_JTAG_DATA 0x00 +#define ASPEED_JTAG_INST 0x04 +#define ASPEED_JTAG_CTRL
[patch v17 3/4] Documentation: jtag: Add bindings for Aspeed SoC 24xx and 25xx families JTAG master driver
It has been tested on Mellanox system with BMC equipped with
Aspeed 2520 SoC for programming CPLD devices.
Signed-off-by: Oleksandr Shamray
Signed-off-by: Jiri Pirko
Acked-by: Rob Herring
---
v16->v17
v15->v16
Comments pointed by Joel Stanley
- change clocks = <&clk_apb> to proper clocks = <&syscon ASPEED_CLK_APB>
- add reset descriptions in bndings file
v14->v15
v13->v14
v12->v13
v11->v12
v10->v11
v9->v10
v8->v9
v7->v8
Comments pointed by pointed by Joel Stanley
- Change compatible string to ast2400 and ast2000
V6->v7
Comments pointed by Tobias Klauser
- Fix spell "Doccumentation" -> "Documentation"
v5->v6
Comments pointed by Tobias Klauser
- Small nit: s/documentation/Documentation/
v4->v5
V3->v4
Comments pointed by Rob Herring
- delete unnecessary "status" and "reg-shift" descriptions in
bndings file
v2->v3
Comments pointed by Rob Herring
- split Aspeed jtag driver and binding to sepatrate patches
- delete unnecessary "status" and "reg-shift" descriptions in
bndings file
---
.../devicetree/bindings/jtag/aspeed-jtag.txt | 22
drivers/jtag/jtag-aspeed.c |1 +
2 files changed, 23 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/jtag/aspeed-jtag.txt
diff --git a/Documentation/devicetree/bindings/jtag/aspeed-jtag.txt
b/Documentation/devicetree/bindings/jtag/aspeed-jtag.txt
new file mode 100644
index 000..7c36eb6
--- /dev/null
+++ b/Documentation/devicetree/bindings/jtag/aspeed-jtag.txt
@@ -0,0 +1,22 @@
+Aspeed JTAG driver for ast2400 and ast2500 SoC
+
+Required properties:
+- compatible: Should be one of
+ - "aspeed,ast2400-jtag"
+ - "aspeed,ast2500-jtag"
+- reg contains the offset and length of the JTAG memory
+ region
+- clocks root clock of bus, should reference the APB
+ clock in the second cell
+- resets phandle to reset controller with the reset number in
+ the second cell
+- interrupts should contain JTAG controller interrupt
+
+Example:
+jtag: jtag@1e6e4000 {
+ compatible = "aspeed,ast2500-jtag";
+ reg = <0x1e6e4000 0x1c>;
+ clocks = <&syscon ASPEED_CLK_APB>;
+ resets = <&syscon ASPEED_RESET_JTAG_MASTER>;
+ interrupts = <43>;
+};
diff --git a/drivers/jtag/jtag-aspeed.c b/drivers/jtag/jtag-aspeed.c
index 9cbd6da..f679041 100644
--- a/drivers/jtag/jtag-aspeed.c
+++ b/drivers/jtag/jtag-aspeed.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
#include
--
1.7.1
[patch v17 0/4] JTAG driver introduction
When a need raise up to use JTAG interface for system's devices programming or CPU debugging, usually the user layer application implements jtag protocol by bit-bang or using a proprietary connection to vendor hardware. This method can be slow and not generic. We propose to implement general JTAG interface and infrastructure to communicate with user layer application. In such way, we can have the standard JTAG interface core part and separation from specific HW implementation. This allow new capability to debug the CPU or program system's device via BMC without additional devices nor cost. This patch purpose is to add JTAG master core infrastructure by defining new JTAG class and provide generic JTAG interface to allow hardware specific drivers to connect this interface. This will enable all JTAG drivers to use the common interface part and will have separate for hardware implementation. The JTAG (Joint Test Action Group) core driver provides minimal generic JTAG interface, which can be used by hardware specific JTAG master controllers. By providing common interface for the JTAG controllers, user space device programing is hardware independent. Modern SoC which in use for embedded system' equipped with internal JTAG master interface. This interface is used for programming and debugging system's hardware components, like CPLD, FPGA, CPU, voltage and industrial controllers. Firmware for such devices can be upgraded through JTAG interface during Runtime. The JTAG standard support for multiple devices programming, is in case their lines are daisy-chained together. For example, systems which equipped with host CPU, BMC SoC or/and number of programmable devices are capable to connect a pin and select system components dynamically for programming and debugging, This is using by the BMC which is equipped with internal SoC master controller. For example: BMC JTAG master --> pin selected to CPLDs chain for programming (filed upgrade, production) BMC JTAG master --> pin selected to voltage monitors for programming (field upgrade, production) BMC JTAG master --> pin selected to host CPU (on-site debugging and developers debugging) For example, we can have application in user space which using calls to JTAG driver executes CPLD programming directly from SVF file The JTAG standard (IEEE 1149.1) defines the next connector pins: - TDI (Test Data In); - TDO (Test Data Out); - TCK (Test Clock); - TMS (Test Mode Select); - TRST (Test Reset) (Optional); The SoC equipped with JTAG master controller, performs device programming on command or vector level. For example a file in a standard SVF (Serial Vector Format) that contains boundary scan vectors, can be used by sending each vector to the JTAG interface and the JTAG controller will execute the programming. Initial version provides the system calls set for: - SIR (Scan Instruction Register, IEEE 1149.1 Data Register scan); - SDR (Scan Data Register, IEEE 1149.1 Instruction Register scan); - RUNTEST (Forces the IEEE 1149.1 bus to a run state for a specified number of clocks. SoC which are not equipped with JTAG master interface, can be built on top of JTAG core driver infrastructure, by applying bit-banging of TDI, TDO, TCK and TMS pins within the hardware specific driver. Oleksandr Shamray (4): drivers: jtag: Add JTAG core driver drivers: jtag: Add Aspeed SoC 24xx and 25xx families JTAG master driver Documentation: jtag: Add bindings for Aspeed SoC 24xx and 25xx families JTAG master driver Documentation: jtag: Add ABI documentation Documentation/ABI/testing/jtag-dev | 27 + .../devicetree/bindings/jtag/aspeed-jtag.txt | 22 + Documentation/ioctl/ioctl-number.txt |2 + MAINTAINERS| 10 + drivers/Kconfig|2 + drivers/Makefile |1 + drivers/jtag/Kconfig | 30 + drivers/jtag/Makefile |2 + drivers/jtag/jtag-aspeed.c | 786 drivers/jtag/jtag.c| 284 +++ include/linux/jtag.h | 41 + include/uapi/linux/jtag.h | 104 +++ 12 files changed, 1311 insertions(+), 0 deletions(-) create mode 100644 Documentation/ABI/testing/jtag-dev create mode 100644 Documentation/devicetree/bindings/jtag/aspeed-jtag.txt create mode 100644 drivers/jtag/Kconfig create mode 100644 drivers/jtag/Makefile create mode 100644 drivers/jtag/jtag-aspeed.c create mode 100644 drivers/jtag/jtag.c create mode 100644 include/linux/jtag.h create mode 100644 include/uapi/linux/jtag.h
Re: [PATCH] drbd: fix discard_zeroes_if_aligned regression
NAK. Calling a discard and expecting zeroing is simply buggy. And double NAK for patches like this without a linux-block Cc.
Re: [PATCH] x86/jailhouse: fix building without X86_X2APIC
On Tue, Jan 16, 2018 at 3:34 AM, Dou Liyang wrote:
> At 01/16/2018 09:25 AM, Dou Liyang wrote:
>>> diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h
>>> index 98722773391d..0317d635d9ba 100644
>>> --- a/arch/x86/include/asm/apic.h
>>> +++ b/arch/x86/include/asm/apic.h
>>> @@ -188,6 +188,8 @@ static inline void lapic_assign_system_vectors(void)
>>> { }
>>> static inline void lapic_assign_legacy_vector(unsigned int i, bool r) {
>>> }
>>> #endif /* !CONFIG_X86_LOCAL_APIC */
>>> +extern int x2apic_mode;
>>> +extern int x2apic_phys;
>>
>> We can't do that, adding a macro for the X2APIC=n case is enough
>>
> I am sorry when I looked into your code in tip tree. I found this
> measure is not true. please try the the following v2 patch.
>
> The reason I don't want to expose the x2apic_mode and x2apic_phys is
> that they may be misused in X2APIC=n case. So I create an interface to
> wrap it. do you think so? ;-)
I'm not sure I follow what the intention of that is. If you want to hide
those two variables, maybe make them 'static' and remove the extern
declarations?
> diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h
> index 98722773391d..ac25ac2e49af 100644
> --- a/arch/x86/include/asm/apic.h
> +++ b/arch/x86/include/asm/apic.h
> @@ -251,6 +251,11 @@ static inline u64 native_x2apic_icr_read(void)
>
> extern int x2apic_mode;
> extern int x2apic_phys;
> +static inline void apic_set_x2apic_phys(void)
> +{
> + x2apic_phys = 1;
> +}
> +
> extern void __init check_x2apic(void);
> extern void x2apic_setup(void);
> static inline int x2apic_enabled(void)
> @@ -265,7 +270,10 @@ static inline void x2apic_setup(void) { }
> static inline int x2apic_enabled(void) { return 0; }
>
> #define x2apic_mode(0)
> -#definex2apic_supported() (0)
> +#define x2apic_phys(0)
> +#define x2apic_supported() (0)
> +
> +static inline void apic_set_x2apic_phys(void){}
> #endif /* !CONFIG_X86_X2APIC */
>
> struct irq_data;
I see nothing wrong it with this, but also don't see anything it does
that improves the interface.
Arnd
Re: Query: Crash is coming during /prod/PID/stat and do_exit of same task
On Tue, Jan 16, 2018 at 11:06:47AM +0530, Kohli, Gaurav wrote: > On 1/10/2018 10:50 AM, Alexey Dobriyan wrote: > > >> We are seeing crash in do_task_stat while accessing stack pointer, It > >> seems same task has already completed do_exit call. > >> So it seems a race between them: > > Please, post exact kernel version and struct task_struct::usage if you > > still have that kernel core (or even full task_struct) > > Hi Alexey, > > We are working on 4.9.65 and Please find below usage value and other > task_struct value, > please let me know if some other data required as well. Kernel stacks live their own lives nowadays, the code needs try_get_task_stack().
Re: LKML admins (syzbot emails are not delivered)
On Mon, Jan 15, 2018 at 10:38:42AM -0600, Eric W. Biederman wrote: > > Sometimes the branches on linux-next are experimental crap. If someone > adds an experimental memory allocator to linux-next before discovering > it causes all kinds of problems I don't want bug reports about my code > not being able to allocate memory because the memory allocator was bad. > > If you don't have the resources to test the individual branches of > linux-next please just test Linus's tree. That will be much more > meaningful and productive. I have to agree with Eric here, the reason why Fengguang Wu's 0-day testing robot is much better received by developers is that he does not test linux-net, but rather individual subsystem git trees and branches. His test automation also does an automatic bisection search, and can point at a specific commit --- at which point e-mail goes out to owner of the subsystem git tree, and to the people who authored and/or reviewed the guilty commit. Dmitry, perhaps you could collaborate with Intel's 0-day testing folks? They have code which does all of this, and perhaps it can be leveraged. > > When I made the complaint it came to me and to messages on lkml as > .log. With Content-Type: Application/Octent-stream. > > That is a bloody mess that wastes peoples time. If it is fixed good, > it certainly was not fixed at that point. I just checked a recent report from the Syzbot, and it's not fixed. The raw.log file still uses a Content-Type of Application/Octet-stream. Worse the reproducer C source file has a content type of Application/Octet-stream instead of the much more sane Application/text. Hint to Googlers --- many kernel developers do not use Gmail because it does unspeakable things to whitespaces, which results in mangled patches, or because they want real mail threading. The Content-Type really matters, because for many text-based Mail User Agents, if it is Application/octet-stream, the MUA will assume that it can't be displayed as text, and require that it be saved to a file, which the developer then has to manually read by firing up a pager or an editor. When you are getting hundreds or thousands of messages a day, having critical data which darn well *could* be displayed as text require manual processing adds friction and destroys developer productivity. So *you* might think the Content-type is trivial, but for developers who live in their MUA's (that's why many prefer to review patches in their mail reader, and not have to switch to web browser to use Gerrit), screwing up the Content-type is going to be a big deal to them. > Outside of the bugs being considered as considered as security issues, > the bugs syzbot finds are generally things that don't affect anyone in > practice. So are very low on the priority of things to get fixed. The real danger is that people will start auto-filing Syzbot reports to "file 13" (e.g., the trash can) because they are too annoying But that's Dmitry and the Syzkaller team's problem, not the kernel developers. :-) - Ted
Re: [BUG 4.15-rc7] IRQ matrix management errors
This is all way over my head, but the part that obviously shows something's gone wrong: kworker/u674:3-1421 [028] d... 335.307051: irq_matrix_reserve_managed: bit=56 cpu=0 online=1 avl=86 alloc=116 managed=3 online_maps=112 global_avl=22084, global_rsvd=157, total_alloc=570 kworker/u674:3-1421 [028] d... 335.307053: irq_matrix_remove_managed: bit=56 cpu=0 online=1 avl=87 alloc=116 managed=2 online_maps=112 global_avl=22085, global_rsvd=157, total_alloc=570 kworker/u674:3-1421 [028] 335.307054: vector_reserve_managed: irq=45 ret=-28 kworker/u674:3-1421 [028] 335.307054: vector_setup: irq=45 is_legacy=0 ret=-28 kworker/u674:3-1421 [028] d... 335.307055: vector_teardown: irq=45 is_managed=1 has_reserved=0 Which leads me to x86_vector_alloc_irqs goto error: error: x86_vector_free_irqs(domain, virq, i + 1); The last parameter looks weird. It's the nr_irqs, and since we failed and bailed, I would think we'd need to subtract 1 rather than add 1. Adding 1 would doublely remove the failed one, and remove the next one that was never setup, right? Or maybe irq_matrix_reserve_managed wasn't expected to fail in the first place?
RE: [patch v16 1/4] drivers: jtag: Add JTAG core driver
Hi Julia
> -Original Message-
> From: Julia Cartwright [mailto:jul...@eso.teric.us]
> Sent: 15 января 2018 г. 22:52
> To: Oleksandr Shamray
> Cc: gre...@linuxfoundation.org; a...@arndb.de; linux-
> ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; open...@lists.ozlabs.org; j...@jms.id.au;
> j...@resnulli.us; tklau...@distanz.ch; linux-ser...@vger.kernel.org; Vadim
> Pasternak ; system-sw-low-level le...@mellanox.com>; robh...@kernel.org; openocd-devel-
> ow...@lists.sourceforge.net; linux-...@vger.kernel.org;
> da...@davemloft.net; mche...@kernel.org; Jiri Pirko
>
> Subject: Re: [patch v16 1/4] drivers: jtag: Add JTAG core driver
>
> Hello Oleksandr-
>
> I have a few comments below.
>
> On Fri, Jan 12, 2018 at 07:08:26PM +0200, Oleksandr Shamray wrote:
> > Initial patch for JTAG driver
> > JTAG class driver provide infrastructure to support hardware/software
> > JTAG platform drivers. It provide user layer API interface for
> > flashing and debugging external devices which equipped with JTAG
> > interface using standard transactions.
> >
[..]
> > + break;
> > +
> > + case JTAG_IOCXFER:
> > + if (!jtag->ops->xfer)
>
> Are all ops optional? That seems bizarre. I would have expected at least one
> callback to be required.
You right. But I'm preferred to check pointers before use it.
>
> [..]
> > +static int jtag_open(struct inode *inode, struct file *file) {
> > + struct jtag *jtag = container_of(file->private_data, struct jtag,
> > +miscdev);
> > +
> > + if (mutex_lock_interruptible(&jtag->open_lock))
> > + return -ERESTARTSYS;
> > +
> > + if (jtag->opened) {
> > + mutex_unlock(&jtag->open_lock);
> > + return -EBUSY;
> > + }
> > +
> > + nonseekable_open(inode, file);
> > + file->private_data = jtag;
>
> These two can be moved out of the lock.
Agree.
>
> > + jtag->opened = true;
> > + mutex_unlock(&jtag->open_lock);
> > + return 0;
> > +}
> > +
> > +static int jtag_release(struct inode *inode, struct file *file) {
> > + struct jtag *jtag = file->private_data;
> > +
> > + mutex_lock(&jtag->open_lock);
> > + jtag->opened = false;
> > + mutex_unlock(&jtag->open_lock);
> > + return 0;
> > +}
> > +
> > +static const struct file_operations jtag_fops = {
> > + .owner = THIS_MODULE,
> > + .open = jtag_open,
> > + .release= jtag_release,
> > + .llseek = noop_llseek,
> > + .unlocked_ioctl = jtag_ioctl,
> > +};
> > +
> > +struct jtag *jtag_alloc(size_t priv_size, const struct jtag_ops *ops)
> > +{
> > + struct jtag *jtag;
> > +
> > + jtag = kzalloc(sizeof(*jtag), GFP_KERNEL);
>
> Did you mean to allocate: sizeof(*jtag) + priv_size?
Thank, it's a mistake.
>
> > + if (!jtag)
> > + return NULL;
> > +
> > + jtag->ops = ops;
> > + return jtag;
> > +}
> > +EXPORT_SYMBOL_GPL(jtag_alloc);
> > +
> > +void jtag_free(struct jtag *jtag)
> > +{
> > + kfree(jtag);
> > +}
> > +EXPORT_SYMBOL_GPL(jtag_free);
> > +
> > +int jtag_register(struct jtag *jtag)
> > +{
> > + char *name;
> > + int err;
> > + int id;
> > +
> > + id = ida_simple_get(&jtag_ida, 0, 0, GFP_KERNEL);
> > + if (id < 0)
> > + return id;
> > +
> > + jtag->id = id;
> > +
> > + name = kzalloc(MAX_JTAG_NAME_LEN, GFP_KERNEL);
> > + if (!name) {
> > + err = -ENOMEM;
> > + goto err_jtag_alloc;
> > + }
> > +
> > + err = snprintf(name, MAX_JTAG_NAME_LEN, "jtag%d", id);
> > + if (err < 0)
> > + goto err_jtag_name;
> > +
> > + mutex_init(&jtag->open_lock);
> > + jtag->miscdev.fops = &jtag_fops;
> > + jtag->miscdev.minor = MISC_DYNAMIC_MINOR;
> > + jtag->miscdev.name = name;
> > +
> > + err = misc_register(&jtag->miscdev);
> > + if (err)
> > + dev_err(jtag->dev, "Unable to register device\n");
> > + else
> > + return 0;
> > + jtag->opened = false;
>
> Well, this code flow is just confusing.
>
> I suggest a redo with:
>
> err = misc_register(&jtag->miscdev);
> if (err) {
> dev_err(jtag->dev, "Unable to register device\n");
> goto err_jtag_name;
> }
>
> If you need to initialize 'opened', do it prior to misc_register.
>
Thanks
> Thanks,
>Julia
Thanks for Review.
Br,
Oleksandr
Re: [PATCH] Remove structure passing and assignment to save stack and no coping structures.
Hi Karim,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.15-rc8 next-20180115]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Karim-Eshapa/Remove-structure-passing-and-assignment-to-save-stack-and-no-coping-structures/20180116-130502
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
>> kernel/bpf/verifier.c:1002:29: sparse: incorrect type in argument 2
>> (different modifiers) @@ expected struct tnum @@ got structstruct tnum @@
kernel/bpf/verifier.c:1002:29: expected struct tnum
kernel/bpf/verifier.c:1002:29: got struct tnum const
>> kernel/bpf/verifier.c:1003:17: sparse: not addressable
kernel/bpf/verifier.c:1028:29: sparse: incorrect type in argument 2
(different modifiers) @@ expected struct tnum @@ got structstruct tnum @@
kernel/bpf/verifier.c:1028:29: expected struct tnum
kernel/bpf/verifier.c:1028:29: got struct tnum const
kernel/bpf/verifier.c:1029:17: sparse: not addressable
kernel/bpf/verifier.c:1969:46: sparse: incorrect type in argument 2
(different modifiers) @@ expected struct tnum @@ got structstruct tnum @@
kernel/bpf/verifier.c:1969:46: expected struct tnum
kernel/bpf/verifier.c:1969:46: got struct tnum const
>> kernel/bpf/verifier.c:1970:26: sparse: incorrect type in argument 3
>> (different modifiers) @@ expected struct tnum lib @@ got structstruct tnum
>> lib @@
kernel/bpf/verifier.c:1970:26: expected struct tnum lib
kernel/bpf/verifier.c:1970:26: got struct tnum const
kernel/bpf/verifier.c:4527:38: sparse: subtraction of Share your drugs
>> kernel/bpf/verifier.c:1002:17: sparse: call with no type!
kernel/bpf/verifier.c:1028:17: sparse: call with no type!
kernel/bpf/verifier.c: In function 'check_pkt_ptr_alignment':
kernel/bpf/verifier.c:1003:3: error: lvalue required as unary '&' operand
&tnum_const(ip_align + reg->off + off));
^
kernel/bpf/verifier.c:1002:21: warning: passing argument 2 of 'tnum_add'
discards 'const' qualifier from pointer target type
tnum_add(®_off, ®->var_off,
^
In file included from include/linux/bpf_verifier.h:12:0,
from kernel/bpf/verifier.c:17:
include/linux/tnum.h:29:6: note: expected 'struct tnum but argument is of
type 'const struct tnum
void tnum_add(struct tnum struct tnum struct tnum
^~~~
kernel/bpf/verifier.c: In function 'check_generic_ptr_alignment':
kernel/bpf/verifier.c:1029:3: error: lvalue required as unary '&' operand
&tnum_const(reg->off + off));
^
kernel/bpf/verifier.c:1028:21: warning: passing argument 2 of 'tnum_add'
discards 'const' qualifier from pointer target type
tnum_add(®_off, ®->var_off,
^
In file included from include/linux/bpf_verifier.h:12:0,
from kernel/bpf/verifier.c:17:
include/linux/tnum.h:29:6: note: expected 'struct tnum but argument is of
type 'const struct tnum
void tnum_add(struct tnum struct tnum struct tnum
^~~~
kernel/bpf/verifier.c: In function 'adjust_ptr_min_max_vals':
kernel/bpf/verifier.c:1969:31: warning: passing argument 2 of 'tnum_add'
discards 'const' qualifier from pointer target type
tnum_add(&dst_reg->var_off, &ptr_reg->var_off,
^
In file included from include/linux/bpf_verifier.h:12:0,
from kernel/bpf/verifier.c:17:
include/linux/tnum.h:29:6: note: expected 'struct tnum but argument is of
type 'const struct tnum
void tnum_add(struct tnum struct tnum struct tnum
^~~~
kernel/bpf/verifier.c:1970:4: warning: passing argument 3 of 'tnum_add'
discards 'const' qualifier from pointer target type
&off_reg->var_off);
^
In file included from include/linux/bpf_verifier.h:12:0,
from kernel/bpf/verifier.c:17:
include/linux/tnum.h:29:6: note: expected 'struct tnum but argument is of
type 'const struct tnum
void tnum_add(struct tnum struct tnum struct tnum
^~~~
vim +1002 kernel/bpf/verifier.c
980
981 static int check_pkt_ptr_alignment(struct bpf_verifier_env *env,
982 const struct bpf_reg_state *reg,
983 int off, int size, bool strict)
984 {
985 struct tnum reg_off;
986 int ip_align;
987
988 /* Byte size accesses are always allowed. */
989 if (!strict || size == 1)
990 return 0;
991
992 /* For platforms that do not have a Kconfig enabling
993 * CONFIG_HAVE_EFFI
Re: [PATCH v2 1/2] drm/bridge/synopsys: dsi: use common mipi_dsi_create_packet()
On 01/10/2018 02:02 AM, Brian Norris wrote:
This takes care of 2 TODOs in this driver, by using the common DSI
packet-marshalling code instead of our custom short/long write code.
This both saves us some duplicated code and gets us free support for
command types that weren't already part of our switch block (e.g.,
MIPI_DSI_GENERIC_LONG_WRITE).
The code logic stays mostly intact, except that it becomes unnecessary
to split the short/long write functions, and we have to copy data a bit
more.
Along the way, I noticed that loop bounds were a little odd:
while (DIV_ROUND_UP(len, pld_data_bytes))
This really was just supposed to be 'len != 0', so I made that more
clear.
Tested on RK3399 with some pending refactoring patches by Nickey Yang,
to make the Rockchip DSI driver wrap this common driver.
Queued to drm-misc-next. Philippe's point about the return value of
mipi_dsi_device_transfer is addressed in a different patch.
Thanks,
Archit
Signed-off-by: Brian Norris
Reviewed-by: Philippe Cornu
Tested-by: Philippe Cornu
---
v2:
* remove "dcs" naming, since these commands handle generic DSI too, not
just DCS (thanks Philippe)
* add Philippe's {Tested,Reviewed}-by
---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 78 ++-
1 file changed, 16 insertions(+), 62 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index d9cca4fd66ec..ed91e32ee43a 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -136,10 +136,6 @@
GEN_SW_0P_TX_LP)
#define DSI_GEN_HDR 0x6c
-/* TODO These 2 defines will be reworked thanks to mipi_dsi_create_packet() */
-#define GEN_HDATA(data)(((data) & 0x) << 8)
-#define GEN_HTYPE(type)(((type) & 0xff) << 0)
-
#define DSI_GEN_PLD_DATA 0x70
#define DSI_CMD_PKT_STATUS 0x74
@@ -359,44 +355,15 @@ static int dw_mipi_dsi_gen_pkt_hdr_write(struct
dw_mipi_dsi *dsi, u32 hdr_val)
return 0;
}
-static int dw_mipi_dsi_dcs_short_write(struct dw_mipi_dsi *dsi,
- const struct mipi_dsi_msg *msg)
-{
- const u8 *tx_buf = msg->tx_buf;
- u16 data = 0;
- u32 val;
-
- if (msg->tx_len > 0)
- data |= tx_buf[0];
- if (msg->tx_len > 1)
- data |= tx_buf[1] << 8;
-
- if (msg->tx_len > 2) {
- dev_err(dsi->dev, "too long tx buf length %zu for short
write\n",
- msg->tx_len);
- return -EINVAL;
- }
-
- val = GEN_HDATA(data) | GEN_HTYPE(msg->type);
- return dw_mipi_dsi_gen_pkt_hdr_write(dsi, val);
-}
-
-static int dw_mipi_dsi_dcs_long_write(struct dw_mipi_dsi *dsi,
- const struct mipi_dsi_msg *msg)
+static int dw_mipi_dsi_write(struct dw_mipi_dsi *dsi,
+const struct mipi_dsi_packet *packet)
{
- const u8 *tx_buf = msg->tx_buf;
- int len = msg->tx_len, pld_data_bytes = sizeof(u32), ret;
- u32 hdr_val = GEN_HDATA(msg->tx_len) | GEN_HTYPE(msg->type);
+ const u8 *tx_buf = packet->payload;
+ int len = packet->payload_length, pld_data_bytes = sizeof(u32), ret;
u32 remainder;
u32 val;
- if (msg->tx_len < 3) {
- dev_err(dsi->dev, "wrong tx buf length %zu for long write\n",
- msg->tx_len);
- return -EINVAL;
- }
-
- while (DIV_ROUND_UP(len, pld_data_bytes)) {
+ while (len) {
if (len < pld_data_bytes) {
remainder = 0;
memcpy(&remainder, tx_buf, len);
@@ -419,40 +386,27 @@ static int dw_mipi_dsi_dcs_long_write(struct dw_mipi_dsi
*dsi,
}
}
- return dw_mipi_dsi_gen_pkt_hdr_write(dsi, hdr_val);
+ remainder = 0;
+ memcpy(&remainder, packet->header, sizeof(packet->header));
+ return dw_mipi_dsi_gen_pkt_hdr_write(dsi, remainder);
}
static ssize_t dw_mipi_dsi_host_transfer(struct mipi_dsi_host *host,
const struct mipi_dsi_msg *msg)
{
struct dw_mipi_dsi *dsi = host_to_dsi(host);
+ struct mipi_dsi_packet packet;
int ret;
- /*
-* TODO dw drv improvements
-* use mipi_dsi_create_packet() instead of all following
-* functions and code (no switch cases, no
-* dw_mipi_dsi_dcs_short_write(), only the loop in long_write...)
-* and use packet.header...
-*/
- dw_mipi_message_config(dsi, msg);
-
- switch (msg->type) {
- case MIPI_DSI_DCS_SHORT_WRITE:
- case MIPI_DSI_DCS_SHORT_WRITE_PARAM:
- case MIPI_DSI_SET_MAXIMUM_RETURN_PACKET_SIZE:
- ret = dw_mipi_dsi_dcs_short_write(dsi, msg);
- break;
- case MIPI_DSI
Re: [PATCH v2 2/2] drm/bridge/synopsys: dsi: handle endianness correctly in dw_mipi_dsi_write()
On 01/10/2018 08:03 PM, Andrzej Hajda wrote:
On 09.01.2018 21:32, Brian Norris wrote:
We're filling the "remainder" word with little-endian data, then writing
it out to IO registers with endian-correcting writel(). That probably
won't work on big-endian systems.
Let's mark the "remainder" variable as LE32 (since we fill it with
memcpy()) and do the swapping explicitly.
Some of this function could be done more easily without memcpy(), but
the unaligned "remainder" case is a little hard to do without
potentially overrunning 'tx_buf', so I just applied the same solution in
all cases (memcpy() + le32_to_cpu()).
Tested only on a little-endian system.
Signed-off-by: Brian Norris
---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index ed91e32ee43a..90f13df6f106 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -360,18 +360,18 @@ static int dw_mipi_dsi_write(struct dw_mipi_dsi *dsi,
{
const u8 *tx_buf = packet->payload;
int len = packet->payload_length, pld_data_bytes = sizeof(u32), ret;
- u32 remainder;
+ __le32 word;
u32 val;
while (len) {
if (len < pld_data_bytes) {
- remainder = 0;
- memcpy(&remainder, tx_buf, len);
- dsi_write(dsi, DSI_GEN_PLD_DATA, remainder);
+ word = 0;
+ memcpy(&word, tx_buf, len);
+ dsi_write(dsi, DSI_GEN_PLD_DATA, le32_to_cpu(word));
len = 0;
} else {
- memcpy(&remainder, tx_buf, pld_data_bytes);
- dsi_write(dsi, DSI_GEN_PLD_DATA, remainder);
+ memcpy(&word, tx_buf, pld_data_bytes);
+ dsi_write(dsi, DSI_GEN_PLD_DATA, le32_to_cpu(word));
tx_buf += pld_data_bytes;
len -= pld_data_bytes;
}
@@ -386,9 +386,9 @@ static int dw_mipi_dsi_write(struct dw_mipi_dsi *dsi,
}
}
- remainder = 0;
- memcpy(&remainder, packet->header, sizeof(packet->header));
- return dw_mipi_dsi_gen_pkt_hdr_write(dsi, remainder);
+ word = 0;
+ memcpy(&word, packet->header, sizeof(packet->header));
+ return dw_mipi_dsi_gen_pkt_hdr_write(dsi, le32_to_cpu(word));
You could create and use appropriate helper, lets say:
u32 le_to_cpup(const u8 *p, int count)
{
__le32 r = 0;
memcpy(&r, p, count);
return le32_to_cpu(r);
}
With or without this change:
Reviewed-by: Andrzej Hajda
Queued to drm-misc-next as is.
Thanks,
Archit
--
Regards
Andrzej
}
static ssize_t dw_mipi_dsi_host_transfer(struct mipi_dsi_host *host,
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH] reset: ti-rstctrl: use the reset-simple driver
On 16/01/18 03:11, Tony Lindgren wrote:
We can support the RSTCTRL reset registers on many TI SoCs with
reset-simple.
Cc: Dave Gerlach
Cc: Mark Rutland
Cc: Nishant Menon
Cc: Philipp Zabel
Cc: Rob Herring
Cc: Suman Anna
Cc: Tero Kristo
Signed-off-by: Tony Lindgren
---
That's all there is to it :) Naturally this can wait for v4.17
if necessary.
Thats pretty neat. :)
-Tero
---
.../devicetree/bindings/reset/ti-rstctrl.txt | 29 ++
drivers/reset/Kconfig | 2 +-
drivers/reset/reset-simple.c | 1 +
3 files changed, 31 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/reset/ti-rstctrl.txt
diff --git a/Documentation/devicetree/bindings/reset/ti-rstctrl.txt
b/Documentation/devicetree/bindings/reset/ti-rstctrl.txt
new file mode 100644
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/ti-rstctrl.txt
@@ -0,0 +1,29 @@
+TI RSTCTRL Reset Controller
+
+Required properties:
+- compatible : "ti,rstctrl"
+- reg : Should contain 1 register ranges(address and length)
+- #reset-cells: 1
+
+Example:
+
+ prcm: prcm@20 {
+ compatible = "ti,am3-prcm", "simple-bus";
+ reg = <0x20 0x4000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x20 0x4000>;
+
+ prm_gfx: prm@1100 {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x1100 0x100>;
+
+ gfx_rstctrl: rstctrl@4 {
+ reg = <0x4 0x4>;
+ #reset-cells = <1>;
+ compatible = "ti,rstctrl";
+ };
+ };
+ };
diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -83,7 +83,7 @@ config RESET_PISTACHIO
config RESET_SIMPLE
bool "Simple Reset Controller Driver" if COMPILE_TEST
- default ARCH_SOCFPGA || ARCH_STM32 || ARCH_STRATIX10 || ARCH_SUNXI ||
ARCH_ZX
+ default ARCH_OMAP2PLUS || ARCH_SOCFPGA || ARCH_STM32 || ARCH_STRATIX10
|| ARCH_SUNXI || ARCH_ZX
help
This enables a simple reset controller driver for reset lines that
that can be asserted and deasserted by toggling bits in a contiguous,
diff --git a/drivers/reset/reset-simple.c b/drivers/reset/reset-simple.c
--- a/drivers/reset/reset-simple.c
+++ b/drivers/reset/reset-simple.c
@@ -123,6 +123,7 @@ static const struct of_device_id reset_simple_dt_ids[] = {
{ .compatible = "st,stm32-rcc", },
{ .compatible = "allwinner,sun6i-a31-clock-reset",
.data = &reset_simple_active_low },
+ { .compatible = "ti,rstctrl", },
{ .compatible = "zte,zx296718-reset",
.data = &reset_simple_active_low },
{ /* sentinel */ },
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH v5 02/44] clk: davinci: New driver for davinci PLL clocks
On Saturday 13 January 2018 06:41 AM, David Lechner wrote: > On 01/12/2018 10:18 AM, Sekhar Nori wrote: >> On Friday 12 January 2018 08:55 PM, David Lechner wrote: PLL output on DA850 must never be below 300MHz or above 600MHz (see datasheet table "Allowed PLL Operating Conditions"). Does this take care of that? Thats one of the main reasons I recall I went with some specific values of prediv, pllm and post div in arch/arm/mach-davinci/da850.c >>> >>> Apparently, I missed this requirement. It looks like I am going to >>> have to >>> rework things so that there is some coordination between the PLL and the >>> PLLDIV clocks in order to get the < 300MHz operating points. >> >> Just to make sure we are on the same page. The datasheet >> constraint is 600 >= PLLOUT >= 300. PLLOUT is output of POSTDIV. > > Hmm... I am on a different page. It looks to me like PLLOUT is the output > of PLLM, not POSTDIV. The datasheet says nothing at all and the TRM does > not say it explicitly, but footnote 2 on the table "System PLLC Output > Clocks", for example, makes it pretty clear. You are right. There is also this note in "Device clock generation" of TRM which makes this clear. " The PLLOUT stage in PLLC0 and PLLC1 is capable of providing frequencies greater than what the SYSCLK dividers can handle. The POSTDIV stage should be programmed to keep the input to the SYSCLK dividers within operating limits. See the device datasheet for the maximum operating frequencies. " Thanks, Sekhar
Re: [RESEND PATCH 1/3] usb: dwc3: Don't reinitialize core during host bus-suspend/resume
Hi Roger, On 1/15/2018 9:10 PM, Roger Quadros wrote: > Hi Manu, [snip] >> I think it will be better to separate runtime_suspend and pm_suspend >> handling for >> host mode in dwc3. Powering offf/on PHYs and dwc3_core_exit/init across >> system >> suspend-resume should be ok but doing that for runtime suspend-resume is not >> correct. >> Let me know if that sounds ok, I can provide a patch for same instead of >> reverting this which affects runtime PM with dwc3 host. >> Also, we need to consider dwc3 in Host mode with dr_mode as DRD/OTG similar >> to >> dr_mode as HOST. >> >> > Are you going to provide a patch for this any time soon? > > FYI, suspend/resume is broken on DRA7x with Dual-role while in host mode. > Posted following patch: https://patchwork.kernel.org/patch/10166077/ Let me know if this works for you. -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH] soc: xilinx: xlnx_vcu: Depends on HAS_IOMEM for xlnx_vcu
xlnx_vcu driver uses devm_ioremap_nocache, which is included only when HAS_IOMEM is enabled. drivers/soc/xilinx/xlnx_vcu.o: In function `xvcu_probe': xlnx_vcu.c:(.text+0x116): undefined reference to `devm_ioremap_nocache' xlnx_vcu.c:(.text+0x1ae): undefined reference to `devm_ioremap_nocache' Signed-off-by: Dhaval Shah --- drivers/soc/xilinx/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/soc/xilinx/Kconfig b/drivers/soc/xilinx/Kconfig index 266b50f..bf657ab 100644 --- a/drivers/soc/xilinx/Kconfig +++ b/drivers/soc/xilinx/Kconfig @@ -3,6 +3,7 @@ menu "Xilinx SoC drivers" config XILINX_VCU tristate "Xilinx VCU logicoreIP Init" + depends on HAS_IOMEM help Provides the driver to enable and disable the isolation between the processing system and programmable logic part by using the logicoreIP -- 2.7.4 This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
Re: [PATCH 4.14 053/118] Revert "Revert "xfrm: Fix stack-out-of-bounds read in xfrm_state_find.""
On Mon, Jan 15, 2018 at 11:56:12AM -0500, David Miller wrote: > From: Steffen Klassert > Date: Mon, 15 Jan 2018 14:23:29 +0100 > > > On Mon, Jan 15, 2018 at 01:34:40PM +0100, Greg Kroah-Hartman wrote: > >> 4.14-stable review patch. If anyone has any objections, please let me > >> know. > >> > >> -- > >> > >> From: "David S. Miller" > >> > >> > >> This reverts commit 94802151894d482e82c324edf2c658f8e6b96508. > >> > >> It breaks transport mode when the policy template has > >> wildcard addresses configured. > >> > >> Signed-off-by: David S. Miller > >> Signed-off-by: Greg Kroah-Hartman > > > > Hm, this seems to be one revert too much. > > > > commit 94802151894d482e82c324edf2c658f8e6b96508 reverted already > > the buggy commit. Reverting the revert will bring the bug back. > > Steffen, in the email where you asked me to revert that is the > commit ID you referenced. I think there was a misunderstanding. I asked you to queue the commit with that ID to stable on Dec 23 (this commit ID is the revert of the buggy patch). This commit was included to stable on Jan 4 then: https://www.spinics.net/lists/stable/msg208727.html So with this, everything was ok. Maybe you started to look again into this because Nicolas Dichtel (Cced) asked to queue this patch on Jan 5, the patch was already in the stable tree (Jan 4) but probably not in an actual release at this time. > > We can drop this, but you need to then tell us whether 4.14 needs > the revert any longer and if so what the correct SHA ID would > be. I think we can we can just drop this. Unless Nicolas knows something that is still missing, v4.14.12 and above should be ok as is.
Re: [PATCH v5 02/44] clk: davinci: New driver for davinci PLL clocks
On Saturday 13 January 2018 07:43 AM, David Lechner wrote:
> On 01/12/2018 03:21 AM, Sekhar Nori wrote:
>> On Monday 08 January 2018 07:47 AM, David Lechner wrote:
>>> +static unsigned long davinci_pll_clk_recalc(struct clk_hw *hw,
>>> + unsigned long parent_rate)
>>> +{
>>> + struct davinci_pll_clk *pll = to_davinci_pll_clk(hw);
>>> + unsigned long rate = parent_rate;
>>> + u32 prediv, mult, postdiv;
>>> +
>>> + prediv = readl(pll->base + PREDIV) & PREDIV_RATIO_MASK;
>>> + mult = readl(pll->base + PLLM) & PLLM_MASK;
>>> + postdiv = readl(pll->base + POSTDIV) & POSTDIV_RATIO_MASK;
>>
>> Shouldn't we check if the pre and post dividers are enabled before using
>> them?
>
> I dug into this and the answer is no. The enable bit acts like a gate, not
> a bypass, so it does not affect the rate calculation.
Alright, thanks for checking this.
Regards,
Sekhar
Re: [PATCH] EDAC, mv64x60: Remove some code duplication
Le 15/01/2018 à 23:31, Michael Ellerman a écrit : Chris Packham writes: On 14/01/18 06:17, Christophe JAILLET wrote: Le 13/01/2018 à 15:22, Borislav Petkov a écrit : + Chris Packham who's been fixing some stuff in here too. On Sat, Jan 13, 2018 at 08:28:21AM +0100, Christophe JAILLET wrote: Reorder the error handling code in order to release the resources in reverse order than allocation. Introduce a new 'release_group' label in the error handling path and use it to void some code duplication. Signed-off-by: Christophe JAILLET --- drivers/edac/mv64x60_edac.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) ... -- Thanks, looks good. But looking at this driver, mv64x60_mc_err_probe() and mv64x60_sram_err_probe() have the same problem too. Can you address them with your patch too pls? Will do. mv64x60_pci_err_probe() also needs some tweaks. Also, if you feel like fixing more stuff in this driver, it doesn't use the edac_printk() infrastructure but naked printk() calls. It could be converted to it. I will only propose to remove a useless message and improve another one, but won't convert the whole driver, sorry. I take this you mean you have a system with a mv64x60 SoC? You might want to make yourself known to the linuxppc-dev list. A while back the prospects of dropping CONFIG_MV64X60 was raised[1]. I don't see anyone actually following through on this yet but I'm not really following linuxppc that closely. That's just because I haven't had time to do it and no one else took the hint :) So yes, Christophe if you have a machine that uses this driver please speak up, otherwise it will probably be removed. cheers -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Hi, No I don't have. I use static checker to find some potential issues in Linux (most of the time, with my own coccinelle scripts). Before proposing some patches, I check if the development on the corresponding files is still active. This driver looked active (i.e. there were several recent commits, even if only cleanups). If it is nearly dead, my small fixes/cleanups are useless, and I will leave it as-is. Thanks for pointing this out. I'll dig somewhere else :) For the records, and if someone is interested, in order to search for "active" files in what I've touched, I use: (this is a slightly updated version of a script found on Internet) # date of the last modification of updated files git status -s -uno | while read mode file; do echo "$(git log -1 --date=format:'%Y%m%d_%H:%M:%S' --format=%cd $file) $file"; done | sort -s -n -k 1,1 > last_modified.txt When I find a potential candidate, I then have a look in its recent history with 'git log' or with 'https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/...' Best regards, CJ
Re: [RFC PATCH] ubifs: Add zstd support
On 2018/1/12 18:45, Richard Weinberger wrote: Yufen Yu, Am Freitag, 12. Januar 2018, 10:24:21 CET schrieb Yufen Yu: Add zstd compression and decompression support to ubifs. zstd at its fastest level compresses almost as well as zlib, while offering much faster compression and decompression, approaching lzo speeds. This patch is based on the patch: https://patchwork.kernel.org/patch/9892631/ zstd source repository: https://github.com/facebook/zstd Do you have numbers on how much we gain for UBIFS on a typical embedded device? Thanks, //richard . This is a RFC patch. I will post the test results after the full function completing. Thanks a lot. Yufen Yu
Re: [PATCH net-next v5 2/4] phy: cp110-comphy: 2.5G SGMII mode
On Friday 12 January 2018 01:21 PM, Antoine Tenart wrote:
> This patch allow the CP100 comphy to configure some lanes in the
> 2.5G SGMII mode. This mode is quite close to SGMII and uses nearly the
> same code path.
>
> Signed-off-by: Antoine Tenart
Acked-by: Kishon Vijay Abraham I
> ---
> drivers/phy/marvell/phy-mvebu-cp110-comphy.c | 17 ++---
> 1 file changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
> b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
> index a0d522154cdf..4ef429250d7b 100644
> --- a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
> +++ b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
> @@ -135,19 +135,25 @@ struct mvebu_comhy_conf {
> static const struct mvebu_comhy_conf mvebu_comphy_cp110_modes[] = {
> /* lane 0 */
> MVEBU_COMPHY_CONF(0, 1, PHY_MODE_SGMII, 0x1),
> + MVEBU_COMPHY_CONF(0, 1, PHY_MODE_2500SGMII, 0x1),
> /* lane 1 */
> MVEBU_COMPHY_CONF(1, 2, PHY_MODE_SGMII, 0x1),
> + MVEBU_COMPHY_CONF(1, 2, PHY_MODE_2500SGMII, 0x1),
> /* lane 2 */
> MVEBU_COMPHY_CONF(2, 0, PHY_MODE_SGMII, 0x1),
> + MVEBU_COMPHY_CONF(2, 0, PHY_MODE_2500SGMII, 0x1),
> MVEBU_COMPHY_CONF(2, 0, PHY_MODE_10GKR, 0x1),
> /* lane 3 */
> MVEBU_COMPHY_CONF(3, 1, PHY_MODE_SGMII, 0x2),
> + MVEBU_COMPHY_CONF(3, 1, PHY_MODE_2500SGMII, 0x2),
> /* lane 4 */
> MVEBU_COMPHY_CONF(4, 0, PHY_MODE_SGMII, 0x2),
> + MVEBU_COMPHY_CONF(4, 0, PHY_MODE_2500SGMII, 0x2),
> MVEBU_COMPHY_CONF(4, 0, PHY_MODE_10GKR, 0x2),
> MVEBU_COMPHY_CONF(4, 1, PHY_MODE_SGMII, 0x1),
> /* lane 5 */
> MVEBU_COMPHY_CONF(5, 2, PHY_MODE_SGMII, 0x1),
> + MVEBU_COMPHY_CONF(5, 2, PHY_MODE_2500SGMII, 0x1),
> };
>
> struct mvebu_comphy_priv {
> @@ -206,6 +212,10 @@ static void mvebu_comphy_ethernet_init_reset(struct
> mvebu_comphy_lane *lane,
> if (mode == PHY_MODE_10GKR)
> val |= MVEBU_COMPHY_SERDES_CFG0_GEN_RX(0xe) |
> MVEBU_COMPHY_SERDES_CFG0_GEN_TX(0xe);
> + else if (mode == PHY_MODE_2500SGMII)
> + val |= MVEBU_COMPHY_SERDES_CFG0_GEN_RX(0x8) |
> +MVEBU_COMPHY_SERDES_CFG0_GEN_TX(0x8) |
> +MVEBU_COMPHY_SERDES_CFG0_HALF_BUS;
> else if (mode == PHY_MODE_SGMII)
> val |= MVEBU_COMPHY_SERDES_CFG0_GEN_RX(0x6) |
> MVEBU_COMPHY_SERDES_CFG0_GEN_TX(0x6) |
> @@ -296,13 +306,13 @@ static int mvebu_comphy_init_plls(struct
> mvebu_comphy_lane *lane,
> return 0;
> }
>
> -static int mvebu_comphy_set_mode_sgmii(struct phy *phy)
> +static int mvebu_comphy_set_mode_sgmii(struct phy *phy, enum phy_mode mode)
> {
> struct mvebu_comphy_lane *lane = phy_get_drvdata(phy);
> struct mvebu_comphy_priv *priv = lane->priv;
> u32 val;
>
> - mvebu_comphy_ethernet_init_reset(lane, PHY_MODE_SGMII);
> + mvebu_comphy_ethernet_init_reset(lane, mode);
>
> val = readl(priv->base + MVEBU_COMPHY_RX_CTRL1(lane->id));
> val &= ~MVEBU_COMPHY_RX_CTRL1_CLK8T_EN;
> @@ -487,7 +497,8 @@ static int mvebu_comphy_power_on(struct phy *phy)
>
> switch (lane->mode) {
> case PHY_MODE_SGMII:
> - ret = mvebu_comphy_set_mode_sgmii(phy);
> + case PHY_MODE_2500SGMII:
> + ret = mvebu_comphy_set_mode_sgmii(phy, lane->mode);
> break;
> case PHY_MODE_10GKR:
> ret = mvebu_comphy_set_mode_10gkr(phy);
>
Re: [PATCH net-next v5 1/4] phy: add 2.5G SGMII mode to the phy_mode enum
On Tuesday 16 January 2018 12:51 AM, David Miller wrote:
> From: Antoine Tenart
> Date: Fri, 12 Jan 2018 08:51:27 +0100
>
>> This patch adds one more generic PHY mode to the phy_mode enum, to allow
>> configuring generic PHYs to the 2.5G SGMII mode by using the set_mode
>> callback.
>>
>> Signed-off-by: Antoine Tenart
Acked-by: Kishon Vijay Abraham I
>
> PHY layer folks, and reviews please?
>
>> ---
>> include/linux/phy/phy.h | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
>> index 4f8423a948d5..5a80e9de3686 100644
>> --- a/include/linux/phy/phy.h
>> +++ b/include/linux/phy/phy.h
>> @@ -28,6 +28,7 @@ enum phy_mode {
>> PHY_MODE_USB_DEVICE,
>> PHY_MODE_USB_OTG,
>> PHY_MODE_SGMII,
>> +PHY_MODE_2500SGMII,
>> PHY_MODE_10GKR,
>> PHY_MODE_UFS_HS_A,
>> PHY_MODE_UFS_HS_B,
>> --
>> 2.14.3
>>
Re: [PATCH] fw_cfg: don't use DMA mapping for fw_cfg device
On Mon, Jan 15, 2018 at 12:22:48PM +0100, Marc-Andre Lureau wrote:
> Hi
>
> On Mon, Jan 15, 2018 at 9:55 AM, Peter Xu wrote:
> > fw_cfg device does not need IOMMU protection, so use physical addresses
> > always. That's how QEMU implements fw_cfg. Otherwise we'll see call
> > traces during boot when vIOMMU is enabled in guest:
> >
> > [1.018306] [ cut here ]
> > [1.018314] WARNING: CPU: 1 PID: 1 at drivers/firmware/qemu_fw_cfg.c:152
> > fw_cfg_dma_transfer+0x399/0x500
> > [1.018315] fw_cfg_dma_transfer: failed to map fw_cfg_dma
> > [1.018316] Modules linked in:
> > [1.018320] CPU: 1 PID: 1 Comm: swapper/0 Not tainted
> > 3.10.0-827.el7.x86_64 #1
> > [1.018321] Hardware name: Red Hat KVM, BIOS 1.11.0-1.el7 04/01/2014
> > [1.018322] Call Trace:
> > [1.018330] [] dump_stack+0x19/0x1b
> > [1.018334] [] __warn+0xd8/0x100
> > [1.018336] [] warn_slowpath_fmt+0x5f/0x80
> > [1.018338] [] fw_cfg_dma_transfer+0x399/0x500
> > [1.018340] [] fw_cfg_read_blob+0xac/0x1c0
> > [1.018342] [] fw_cfg_register_dir_entries+0x80/0x450
> > [1.018344] [] fw_cfg_sysfs_probe+0x212/0x3f0
> > [1.018347] [] platform_drv_probe+0x42/0x110
> > [1.018350] [] driver_probe_device+0xc2/0x3e0
> > [1.018352] [] __driver_attach+0x93/0xa0
> > [1.018354] [] ? __device_attach+0x40/0x40
> > [1.018359] [] bus_for_each_dev+0x73/0xc0
> > [1.018362] [] driver_attach+0x1e/0x20
> > [1.018364] [] bus_add_driver+0x200/0x2d0
> > [1.018366] [] ? firmware_map_add_early+0x58/0x58
> > [1.018368] [] driver_register+0x64/0xf0
> > [1.018370] [] __platform_driver_register+0x4a/0x50
> > [1.018372] [] fw_cfg_sysfs_init+0x34/0x61
> > [1.018376] [] do_one_initcall+0xb8/0x230
> > [1.018379] [] kernel_init_freeable+0x17a/0x219
> > [1.018381] [] ? initcall_blacklist+0xb0/0xb0
> > [1.018383] [] ? rest_init+0x80/0x80
> > [1.018385] [] kernel_init+0xe/0xf0
> > [1.018388] [] ret_from_fork+0x58/0x90
> > [1.018390] [] ? rest_init+0x80/0x80
> > [1.018392] ---[ end trace d00a5b71608a8f59 ]---
> >
> > Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1533367
> > Fixes: e90cb816599b ("fw_cfg: do DMA read operation", 2017-11-28)
> > CC: Marc-André Lureau
> > CC: Michael S. Tsirkin
> > Signed-off-by: Peter Xu
> > --
> >
> > This is based on tree:
> > https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git/log/?h=vhost
> >
> > Please review, thanks.
> >
> > Signed-off-by: Peter Xu
>
> The DMA business is confusing, sadly I didn't get much clue what I was
> supposed to do. What I can say:
>
> Tested-by: Marc-André Lureau
Thanks for confirming this.
>
> Should the series be removed from Michael tree and I squash your fix &
> send a v10?
>
> Fwiw, "fw_cfg: write vmcoreinfo details" should also be fixed to
> allocate memory (unless your approach fixes that?)
Yes, IMHO this patch should also work for writes (though not tested).
Thanks,
--
Peter Xu
Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup
Hi,
On (01/15/18 12:50), Petr Mladek wrote:
> On Mon 2018-01-15 11:17:43, Petr Mladek wrote:
> > PS: Sergey, you have many good points. The printk-stuff is very
> > complex and we could spend years discussing the perfect solution.
>
> BTW: One solution that comes to my mind is based on ideas
> already mentioned in this thread:
>
> void console_unlock(void)
> {
> disable_preemtion();
>
> while(pending_message) {
>
> call_console_drivers();
>
> if (too_long_here() && current != printk_kthread) {
> wake_up_process(printk_kthread())
>
> }
>
> enable_preemtion();
> }
unfortunately disabling preemtion in console_unlock() is a bit
dangerous :( we have paths that call console_unlock() exactly
to flush everything (not only new pending messages, but everything)
that is in logbuf and we cannot return from console_unlock()
preliminary in that case.
> bool too_long_here(void)
> {
> return should_resched();
> or
> return spent_here() > 1 / HZ / 2;
> or
> what ever we agree on
> }
>
>
> int printk_kthread_func(void *data)
> {
> while(1) {
>if (!pending_messaged)
> schedule();
>
> if (console_trylock_spinning())
> console_unlock();
>
> cond_resched();
> }
> }
overall that's very close to what I have in one of my private branches.
console_trylock_spinning() for some reason does not perform really
well on my made-up internal printk torture tests. it seems that I
have a much better stability (no lockups and so on) when I also let
printk_kthread to sleep on console_sem(). but I will look further.
-ss
[PATCH] selftests: Fix loss of test output in run_kselftests.sh
Commit fbcab13d2e25 ("selftests: silence test output by default")
changed the run_tests logic as well as the logic to generate
run_kselftests.sh to redirect test output away from the console.
As discussed on the list and at kernel summit, this is not a desirable
default as it means in order to debug a failure the console output is
not sufficient, you also need access to the test machine to get the
full test logs. Additionally it's impolite to write directly to
/tmp/$TEST_NAME on shared systems.
The change to the run_tests logic was reverted in commit
a323335e62cc ("selftests: lib.mk: print individual test results to
console by default"), and instead a summary option was added so that
quiet output could be requested.
However the change to run_kselftests.sh was left as-is.
This commit applies the same logic to the run_kselftests.sh code, ie.
the script now takes a "--summary" option which suppresses the output,
but shows all output by default.
Additionally instead of writing to /tmp/$TEST_NAME the output is
redirected to the directory where the generated test script is
located.
Fixes: fbcab13d2e25 ("selftests: silence test output by default")
Signed-off-by: Michael Ellerman
---
tools/testing/selftests/Makefile | 9 -
tools/testing/selftests/lib.mk | 2 +-
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
index eaf599dc2137..7442dfb73b7f 100644
--- a/tools/testing/selftests/Makefile
+++ b/tools/testing/selftests/Makefile
@@ -116,8 +116,15 @@ ifdef INSTALL_PATH
@# Ask all targets to emit their test scripts
echo "#!/bin/sh" > $(ALL_SCRIPT)
- echo "cd \$$(dirname \$$0)" >> $(ALL_SCRIPT)
+ echo "BASE_DIR=\$$(realpath \$$(dirname \$$0))" >> $(ALL_SCRIPT)
+ echo "cd \$$BASE_DIR" >> $(ALL_SCRIPT)
echo "ROOT=\$$PWD" >> $(ALL_SCRIPT)
+ echo "if [ \"\$$1\" = \"--summary\" ]; then" >> $(ALL_SCRIPT)
+ echo " OUTPUT=\$$BASE_DIR/output.log" >> $(ALL_SCRIPT)
+ echo " cat /dev/null > \$$OUTPUT" >> $(ALL_SCRIPT)
+ echo "else" >> $(ALL_SCRIPT)
+ echo " OUTPUT=/dev/stdout" >> $(ALL_SCRIPT)
+ echo "fi" >> $(ALL_SCRIPT)
for TARGET in $(TARGETS); do \
BUILD_TARGET=$$BUILD/$$TARGET; \
diff --git a/tools/testing/selftests/lib.mk b/tools/testing/selftests/lib.mk
index 5bef05d6ba39..7de482a0519d 100644
--- a/tools/testing/selftests/lib.mk
+++ b/tools/testing/selftests/lib.mk
@@ -77,7 +77,7 @@ endif
define EMIT_TESTS
@for TEST in $(TEST_GEN_PROGS) $(TEST_CUSTOM_PROGS) $(TEST_PROGS); do \
BASENAME_TEST=`basename $$TEST`;\
- echo "(./$$BASENAME_TEST > /tmp/$$BASENAME_TEST 2>&1 && echo
\"selftests: $$BASENAME_TEST [PASS]\") || echo \"selftests: $$BASENAME_TEST
[FAIL]\""; \
+ echo "(./$$BASENAME_TEST >> \$$OUTPUT 2>&1 && echo \"selftests:
$$BASENAME_TEST [PASS]\") || echo \"selftests: $$BASENAME_TEST [FAIL]\""; \
done;
endef
--
2.14.3
Re: [Suspected-Phishing]Re: [PATCH V3 1/2] nvme: split resetting state into reset_prepate and resetting
Hi Max
Thanks for your kindly comment.
On 01/15/2018 09:36 PM, Max Gurtovoy wrote:
case NVME_CTRL_RECONNECTING:
switch (old_state) {
case NVME_CTRL_LIVE:
case NVME_CTRL_RESETTING:
+ case NVME_CTRL_RESET_PREPARE:
>
> I forget to add that we shouldn't move from RESET_PREPARE to RECONNECTING
> (with my suggestion to rdma.c).
> Also need to consider adding another check in nvmf_check_init_req
> (/drivers/nvme/host/fabrics.h) for the new state.
After Sagi's nvme-rdma: fix concurrent reset and reconnect, the rdma ctrl state
is changed to RECONNECTING state
after some clearing and shutdown work, then some initializing procedure, no
matter reset work path or error recovery path.
The fc reset work also does the same thing.
So if we define the range that RESET_PREPARE includes scheduling gap and
disable and clear work, RESETTING includes initializing
procedure, RECONNECTING is very similar with RESETTING.
Maybe we could do like this;
In nvme fc/rdma
- set state to RESET_PREPARE, queue reset_work/err_work
- clear/shutdown works, set state to RECONNECTING
- initialization, set state to LIVE
In nvme pci
- set state to RESET_PREPARE, queue reset_work
- clear/shutdown works, set state to RESETTING
- initialization, set state to LIVE
Thanks
Jianchao
Re: [PATCH] ARM: davinci_all_defconfig: set CONFIG_DAVINCI_WATCHDOG=y
On Monday 15 January 2018 10:59 PM, David Lechner wrote:
> This changes CONFIG_DAVINCI_WATCHDOG from a module to a compiled-in
> option. Since the reset function has been moved out of the mach code in
> commit 0808d3260456 ("ARM: davinci: remove watchdog reset") and into the
> watchdog driver, devices cannot reboot unless the watchdog driver is
> loaded, so make it a compiled-in option so that we can always reboot, even
> when modules are not loaded.
>
> Cc: Sekhar Nori
> Suggested-by: Adam Ford
> Signed-off-by: David Lechner
Hmm, we already depend on modules to load correctly for a lot of
functionality. Why should reboot be an exception? In general, unless the
driver is needed for loading rootfile system, I would keep it as a module.
Thanks,
Sekhar
Re: linux-next: build warning after merge of the staging tree
On Tue, Jan 16, 2018 at 01:45:44PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the staging tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
>
> drivers/staging/lustre/lnet/selftest/module.c: In function
> 'lnet_selftest_init':
> drivers/staging/lustre/lnet/selftest/module.c:98:10: warning: 'rc' may be
> used uninitialized in this function [-Wmaybe-uninitialized]
>return rc;
> ^~
>
> Introduced by commit
>
> 6106c0f82481 ("staging: lustre: lnet: convert selftest to use workqueues")
Yeah, I told Neil about this, hopefully he sends me a fix soon :)
thanks,
greg k-h
Re: [PATCH 4.9 27/75] net: igmp: Use correct source address on IGMPv3 reports
On Tue, Jan 16, 2018 at 04:50:39AM +0100, Sebastian Gottschall wrote: > please revert that on 4.9 and 4.14 > it breaks igmp routing. it can be reproduced with any iptv connection using > igmp-proxy. reverting this patch fixes the issue. So Linus's kernel also is broken for you? Or does it work properly there? thanks, greg k-h
Re: [PATCH 4.14 000/118] 4.14.14-stable review
On Mon, Jan 15, 2018 at 04:11:15PM -0600, Dan Rue wrote: > On Mon, Jan 15, 2018 at 01:33:47PM +0100, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.14.14 release. > > There are 118 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Wed Jan 17 12:33:32 UTC 2018. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.14-rc1.gz > > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > linux-4.14.y > > and the diffstat can be found below. > > Results from Linaro’s test farm. > No regressions on arm64, arm and x86_64. Great, thanks for testing. greg k-h
Re: [PATCH 4.4 00/87] 4.4.112-stable review
On Mon, Jan 15, 2018 at 03:59:18PM -0600, Dan Rue wrote: > On Mon, Jan 15, 2018 at 01:33:59PM +0100, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.4.112 release. > > There are 87 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Wed Jan 17 12:33:11 UTC 2018. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.112-rc1.gz > > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > linux-4.4.y > > and the diffstat can be found below. > > Results from Linaro’s test farm. > No regressions on arm64, arm and x86_64. Same ebpf question here, did you test it? thanks, greg k-h
Re: [PATCH 4.9 00/96] 4.9.77-stable review
On Mon, Jan 15, 2018 at 04:03:06PM -0600, Dan Rue wrote: > On Mon, Jan 15, 2018 at 01:33:59PM +0100, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.9.77 release. > > There are 96 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Wed Jan 17 12:33:26 UTC 2018. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.77-rc1.gz > > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > linux-4.9.y > > and the diffstat can be found below. > > Results from Linaro’s test farm. > No regressions on arm64, arm and x86_64. Really? Did you test ebpf? If not, can you go and manually do that (I don't know if it's part of your skips), as it is important here... thanks, greg k-h
Re: lapic-related boot crash in 4.15-rc1
Hi Thomas,
At 01/16/2018 12:21 AM, Thomas Gleixner wrote:
On Mon, 15 Jan 2018, Meelis Roos wrote:
On Wed, 10 Jan 2018, Thomas Gleixner wrote:
On Wed, 10 Jan 2018, Meelis Roos wrote:
On 3 of my test computers, boot hangs with 4.15 git kernels. So far I
have traced it down to 4.14.0 being good and 4.15-rc1 being bad (bisect
is slow because the computers are somwehat remote). Also because of
trying to find when it started, I have not tries newer than rc5
kernels.
Please do so. We have fixes post rc5 in that area.
P4 was the quickest to rebuild the kernel and it is still hanging like
before with todays 4.15-rc7-00102-gcf1fb158230e.
So far I have bisected it to 4f45ed9f848f good, ae41a2a40ed4 bad. Will
continue tomorrow.
1be2172e96e3 bad
2cd83ba5bede bad
449fcf3ab0ba bad
43ff2f4db9d0 good
313144c1bcd6 good
b18d62891aaf bad
b24591e2fcf8 good
0696d059f23c bad
023a611748fd bad
ae41a2a40ed4 bad
4f45ed9f848f good
I've reverted the commit which Dou pointed out in rc8. Can you please confirm
that
this fixes the issue for you?
Due to my email server error, it seems Meelis didn't receive my email.
Can you FWD this patch to him?
Thanks,
dou.
--->8---
From: Ville Syrjälä
This reverts commit b371ae0d4a194b178817b0edfb6a7395c7aec37a.
Causes my P3 UP machine to hang at boot with "lapic".
Cc: Dou Liyang
Cc: Thomas Gleixner
Cc: ying...@kernel.org
Cc: b...@redhat.com
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Signed-off-by: Ville Syrjälä
---
arch/x86/include/asm/apic.h | 1 +
arch/x86/kernel/apic/apic.c | 49
+
arch/x86/kernel/irqinit.c | 3 +++
3 files changed, 53 insertions(+)
diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h
index a9e57f08bfa6..98722773391d 100644
--- a/arch/x86/include/asm/apic.h
+++ b/arch/x86/include/asm/apic.h
@@ -136,6 +136,7 @@ extern void disconnect_bsp_APIC(int virt_wire_setup);
extern void disable_local_APIC(void);
extern void lapic_shutdown(void);
extern void sync_Arb_IDs(void);
+extern void init_bsp_APIC(void);
extern void apic_intr_mode_init(void);
extern void setup_local_APIC(void);
extern void init_apic_mappings(void);
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 6e272f3ea984..cec9aaea7f9d 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1286,6 +1286,55 @@ static int __init apic_intr_mode_select(void)
return APIC_SYMMETRIC_IO;
}
+/*
+ * An initial setup of the virtual wire mode.
+ */
+void __init init_bsp_APIC(void)
+{
+unsigned int value;
+
+/*
+ * Don't do the setup now if we have a SMP BIOS as the
+ * through-I/O-APIC virtual wire mode might be active.
+ */
+if (smp_found_config || !boot_cpu_has(X86_FEATURE_APIC))
+return;
+
+/*
+ * Do not trust the local APIC being empty at bootup.
+ */
+clear_local_APIC();
+
+/*
+ * Enable APIC.
+ */
+value = apic_read(APIC_SPIV);
+value &= ~APIC_VECTOR_MASK;
+value |= APIC_SPIV_APIC_ENABLED;
+
+#ifdef CONFIG_X86_32
+/* This bit is reserved on P4/Xeon and should be cleared */
+if ((boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) &&
+(boot_cpu_data.x86 == 15))
+value &= ~APIC_SPIV_FOCUS_DISABLED;
+else
+#endif
+value |= APIC_SPIV_FOCUS_DISABLED;
+value |= SPURIOUS_APIC_VECTOR;
+apic_write(APIC_SPIV, value);
+
+/*
+ * Set up the virtual wire mode.
+ */
+apic_write(APIC_LVT0, APIC_DM_EXTINT);
+value = APIC_DM_NMI;
+if (!lapic_is_integrated())/* 82489DX */
+value |= APIC_LVT_LEVEL_TRIGGER;
+if (apic_extnmi == APIC_EXTNMI_NONE)
+value |= APIC_LVT_MASKED;
+apic_write(APIC_LVT1, value);
+}
+
/* Init the interrupt delivery mode for the BSP */
void __init apic_intr_mode_init(void)
{
diff --git a/arch/x86/kernel/irqinit.c b/arch/x86/kernel/irqinit.c
index 8da3e909e967..a539410c4ea9 100644
--- a/arch/x86/kernel/irqinit.c
+++ b/arch/x86/kernel/irqinit.c
@@ -61,6 +61,9 @@ void __init init_ISA_irqs(void)
struct irq_chip *chip = legacy_pic->chip;
int i;
+#if defined(CONFIG_X86_64) || defined(CONFIG_X86_LOCAL_APIC)
+init_bsp_APIC();
+#endif
legacy_pic->init(0);
for (i = 0; i < nr_legacy_irqs(); i++)
---
Thanks,
tglx
Re: lapic-related boot crash in 4.15-rc1
> I've reverted the commit which Dou pointed out in rc8. Can you please confirm > that > this fixes the issue for you? Tried rc8 on the P3, it still hangs. -- Meelis Roos (mr...@linux.ee)
Re: Query: Crash is coming during /prod/PID/stat and do_exit of same task
On 1/10/2018 10:50 AM, Alexey Dobriyan wrote:
We are seeing crash in do_task_stat while accessing stack pointer, It
seems same task has already completed do_exit call.
So it seems a race between them:
Please, post exact kernel version and struct task_struct::usage if you
still have that kernel core (or even full task_struct)
Hi Alexey,
We are working on 4.9.65 and Please find below usage value and other
task_struct value,
please let me know if some other data required as well.
crash_64> struct task_struct.usage -x 0xFFE80D8C2280
usage = {
counter = 0x4
}
struct task_struct.flags -x 0xFFE80D8C2280
flags = 0x40870c
crash_64> struct task_struct.exit_code -x 0xFFE80D8C2280
exit_code = 0x6
struct task_struct.state -x 0xFFE80D8C2280
state = 0x40
Please find below crash stack:
-000|user_stack_pointer(inline)
-000|do_task_stat(
| m = 0xFFE7A5CD7380,
| ns = 0xFF8E7C43C748,
| ?,
| task = 0xFFE80D8C2280,
| ?)
| tty_pgrp = 0
| ppid = 2084696064
| sid = 0
| mm = 0xFFE7B4424140
| tcomm = (84, 9, 71, 122, 142, 255, 255, 255, 48, 253, 240, 165, 231,
255, 255, 255)
| flags = 18446743969119403392
-001|proc_tgid_stat(
| m = 0xFFE7A5CD7380,
| ?,
| ?,
| ?)
-002|atomic_sub_return(inline)
Regards
Gaurav
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.
is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
linux-next: Tree for Jan 16
Hi all, News: I am now compiling with gcc 7.2.1 compilers, and 2.28.2 binutils (except for sparc64 where the latest I could get to build was 2.25.2). My final powerpc builds are done with gcc 5.2.1 as the 7.2.1 compiler hung for one build. Changes since 20180115: The printk tree gained a conflict against Linus' tree. The net-next tree gained conflicts against the net tree. The mac80211-next tree gained a conflict against the mac80211 tree. The akpm tree gained a conflict against the net-next tree for which I dropped a patch. Non-merge commits (relative to Linus' tree): 8951 9128 files changed, 371825 insertions(+), 238260 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 256 trees (counting Linus' and 44 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (a8750ddca918 Linux 4.15-rc8) Merging fixes/master (820bf5c419e4 Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi) Merging kbuild-current/fixes (36c1681678b5 genksyms: drop *.hash.c from .gitignore) Merging arc-current/for-curr (b2cd1df66037 Linux 4.15-rc7) Merging arm-current/fixes (36b0cb84ee85 ARM: 8731/1: Fix csum_partial_copy_from_user() stack mismatch) Merging m68k-current/for-linus (5e387199c17c m68k/defconfig: Update defconfigs for v4.14-rc7) Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups) Merging powerpc-fixes/fixes (349524bc0da6 powerpc: Don't preempt_disable() in show_cpuinfo()) Merging sparc/master (59585b4be9ae sparc64: repair calling incorrect hweight function from stubs) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (db9ca5cacbda Merge branch 'ipv4-Make-neigh-lookup-keys-for-loopback-point-to-point-devices-be-INADDR_ANY') Merging bpf/master (68fda450a7df bpf: fix 32-bit divide by zero) Merging ipsec/master (76a420119181 xfrm: Fix a race in the xdst pcpu cache.) Merging netfilter/master (889c604fd0b5 netfilter: x_tables: fix int overflow in xt_alloc_table_info()) Merging ipvs/master (f7fb77fc1235 netfilter: nft_compat: check extension hook mask only if set) Merging wireless-drivers/master (49fdde89e2b8 Merge ath-current from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git) Merging mac80211/master (59b179b48ce2 cfg80211: check dev_set_name() return value) Merging rdma-fixes/for-rc (57194fa763bf IB/hfi1: Prevent a NULL dereference) Merging sound-current/for-linus (b3defb791b26 ALSA: seq: Make ioctls race-free) Merging pci-current/for-linus (03a551734cfc x86/PCI: Move and shrink AMD 64-bit window to avoid conflict) Merging driver-core.current/driver-core-linus (30a7acd57389 Linux 4.15-rc6) Merging tty.current/tty-linus (30a7acd57389 Linux 4.15-rc6) Merging usb.current/usb-linus (a8750ddca918 Linux 4.15-rc8) Merging usb-gadget-fixes/fixes (b2cd1df66037 Linux 4.15-rc7) Merging usb-serial-fixes/usb-linus (d14ac576d10f USB: serial: cp210x: add new device ID ELV ALC 8xxx) Merging usb-chipidea-fixes/ci-for-usb-stable (964728f9f407 USB: chipidea: msm: fix ulpi-node lookup) Merging phy/fixes (2b88212c4cc6 phy: rcar-gen3-usb2: select USB_COMMON) Merging staging.current/staging-linus (a8750ddca918 Linux 4.15-rc8) Merging char-misc.current/char-misc-linus (a8750ddca
Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup
Hi, On (01/15/18 11:17), Petr Mladek wrote: > Hi Sergey, > > I wonder if there is still some miss understanding. > > Steven and me are trying to get this patch in because we believe > that it is a step forward. We know that it is not perfect. But > we believe that it makes things better. In particular, it limits > the time spent in console_unlock() in atomic context. It does > not make it worse in preemptible context. > > It does not block further improvements, including offloading > to the kthread. We will happily discuss and review further > improvements, it they prove to be necessary. > > The advantage of this approach is that it is incremental. It should > be easier for review and analyzing possible regressions. > > What is the aim of your mails, please? > Do you want to say that this patch might cause regressions? > Or do you want to say that it does not solve all scenarios? > > Please, answer the above questions. I am still confused. I ACK-ed the patch set, given that I hope that we at least will do (a) a) remove preemption out of printk()->user critical path --- b) the next thing would be - O(logbuf) is not a good boundary c) the thing after that would be to - O(logbuf) boundary can be broken in both preemptible and non-preemptible contexts. but (b) and (c) can wait. -ss
Re: WARNING in __vm_enough_memory
On Tue, Jan 16, 2018 at 12:58 AM, syzbot
wrote:
> Hello,
>
> syzkaller hit the following crash on
> 8418f88764046d0e8ca6a3c04a69a0e57189aa1e
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
Most likely it is drivers/staging/android/ashmem.c which is guilty. So
+ashmem maintainers.
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+cc298e15b6a571ba0...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
>
> audit: type=1400 audit(1515720420.441:8): avc: denied { sys_admin } for
> pid=3511 comm="syzkaller485245" capability=21
> scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
> tcontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023 tclass=cap_userns
> permissive=1
> audit: type=1400 audit(1515720420.495:9): avc: denied { sys_chroot } for
> pid=3512 comm="syzkaller485245" capability=18
> scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
> tcontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023 tclass=cap_userns
> permissive=1
> [ cut here ]
> memory commitment underflow
> WARNING: CPU: 0 PID: 3512 at mm/util.c:606 __vm_enough_memory+0x5a6/0x810
> mm/util.c:604
> Kernel panic - not syncing: panic_on_warn set ...
>
> CPU: 0 PID: 3512 Comm: syzkaller485245 Not tainted 4.15.0-rc7-next-20180111+
> #94
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:17 [inline]
> dump_stack+0x194/0x257 lib/dump_stack.c:53
> panic+0x1e4/0x41c kernel/panic.c:183
> __warn+0x1dc/0x200 kernel/panic.c:547
> report_bug+0x211/0x2d0 lib/bug.c:184
> fixup_bug.part.11+0x37/0x80 arch/x86/kernel/traps.c:178
> fixup_bug arch/x86/kernel/traps.c:247 [inline]
> do_error_trap+0x2d7/0x3e0 arch/x86/kernel/traps.c:296
> do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
> invalid_op+0x22/0x40 arch/x86/entry/entry_64.S:1102
> RIP: 0010:__vm_enough_memory+0x5a6/0x810 mm/util.c:604
> RSP: 0018:8801bfbaf8e0 EFLAGS: 00010282
> RAX: dc08 RBX: 110037f75f21 RCX: 815a613e
> RDX: RSI: 110037e84d3b RDI: 0293
> RBP: 8801bfbafa90 R08: 110037f75eaf R09:
> R10: R11: R12: 8801bfbafa68
> R13: 869b8c80 R14: 0fff R15: dc00
> security_vm_enough_memory_mm+0x90/0xb0 security/security.c:327
> mmap_region+0x321/0x15a0 mm/mmap.c:1666
> do_mmap+0x73c/0xf70 mm/mmap.c:1494
> do_mmap_pgoff include/linux/mm.h:2224 [inline]
> vm_mmap_pgoff+0x1de/0x280 mm/util.c:333
> SYSC_mmap_pgoff mm/mmap.c:1544 [inline]
> SyS_mmap_pgoff+0x23b/0x5f0 mm/mmap.c:1502
> SYSC_mmap arch/x86/kernel/sys_x86_64.c:100 [inline]
> SyS_mmap+0x16/0x20 arch/x86/kernel/sys_x86_64.c:91
> entry_SYSCALL_64_fastpath+0x29/0xa0
> RIP: 0033:0x440ac9
> RSP: 002b:007dff58 EFLAGS: 0212 ORIG_RAX: 0009
> RAX: ffda RBX: RCX: 00440ac9
> RDX: 0003 RSI: 00fff000 RDI: 2000
> RBP: 7fff R08: R09:
> R10: 0032 R11: 0212 R12: 6873612f7665642f
> R13: 6c616b7a79732f2e R14: R15:
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 86400 seconds..
>
>
> ---
> This bug is generated by a dumb bot. It may contain errors.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to syzkal...@googlegroups.com.
>
> syzbot will keep track of this bug report.
> If you forgot to add the Reported-by tag, once the fix for this bug is
> merged
> into any tree, please reply to this email with:
> #syz fix: exact-commit-title
> If you want to test a patch for this bug, please reply with:
> #syz test: git://repo/address.git branch
> and provide the patch inline or as an attachment.
> To mark this as a duplicate of another syzbot report, please reply with:
> #syz dup: exact-subject-of-another-report
> If it's a one-off invalid bug report, please reply with:
> #syz invalid
> Note: if the crash happens again, it will cause creation of a new bug
> report.
> Note: all commands must start from beginning of the line in the email body.
>
> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to syzkaller-bugs+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/syzkaller-bugs/001a1144593661efb50562d9624f%40google
Re: [PATCH] brcmfmac: Make sure CLM downloading is optional
On Mon 15 Jan 11:40 PST 2018, Arend van Spriel wrote:
> On 1/15/2018 6:10 PM, Bjorn Andersson wrote:
> > The presence of a CLM file is described as optional, but missing the clm
> > blob causes the preinit to return unsuccessfully. Fix this by ignoring
> > the return value of the brcmf_c_process_clm_blob().
> >
> > Also remove the extra debug print, as brcmf_c_process_clm_blob() already
> > did print a useful error message before returning.
> >
> > Fixes: fdd0bd88ceae ("brcmfmac: add CLM download support")
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Bjorn Andersson
> > ---
> >
> > This regression was introduced in v4.15-rc1, but I unfortunately didn't test
> > WiFi until now. Included a Cc to stable@ in case you choose to pick this up
> > after v4.15.
>
> Hi Bjorn,
>
> Thanks for looking into this. Actually there already have been a couple of
> fixes posted on the linux-wireless list. [1] was rejected, [2] is being
> discussed, and [2] was posted by me and I was awaiting response from the guy
> reporting it.
>
Thanks for pointing me to these discussions, I did for some reason not
find them this morning. I don't see the need for the retry in [1], so I
think that's invalid.
I tested [2] and it works well for me, but I agree with Kalle that a
better description of why would be in order. Unfortunatley I can't find
it in my inbox...even though I'm subscribed to linux-wireless@.
The answer to Kalle's question should probably include a reference to
0542ad88fbdd ("firmware loader: Fix _request_firmware_load() return val
for fw load abort")
> Now the thing is that for old (Broadcom) firmware this is optional. Those
> firmwares don't even have CLM support and those that do have the CLM data
> embedded in firmware.
I don't know which applies to my device, but it at least doesn't come
with a dedicated clm blob - and the device won't receive any upgrades
and hence will never get a clm blob.
> However, Cypress wants to provide their customers with
> firmware without CLM data. For those devices it is not optional. I still
> prefer we add a mechanism to the driver to detect that, but we do not have
> that yet.
>
That sounds reasonable, but I hope we can sort out the regression first
and then add such logic.
> Now regarding your patch some comments below ...
>
> > drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c | 8 ++--
> > 1 file changed, 2 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> > b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> > index 6a59d0609d30..0c67ba6ae135 100644
> > --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> > +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> > @@ -278,12 +278,8 @@ int brcmf_c_preinit_dcmds(struct brcmf_if *ifp)
> > }
> > ri->result = err;
> >
> > - /* Do any CLM downloading */
> > - err = brcmf_c_process_clm_blob(ifp);
> > - if (err < 0) {
> > - brcmf_err("download CLM blob file failed, %d\n", err);
> > - goto done;
> > - }
> > + /* Do any optional CLM downloading */
> > + brcmf_c_process_clm_blob(ifp);
>
> The error print is indeed redundant and should be removed here. However,
> brcmf_c_process_clm_blob() also returns -ENOMEM upon allocation failure and
> I would still fail the driver probe for that.
>
Agreed, but as we want to let a few errors, specifically from the
firmware loader, slip by I believe it's better to check the return value
there instead. So I prefer Write's [2].
Regards,
Bjorn
Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup
On (01/15/18 09:51), Petr Mladek wrote:
> On Sat 2018-01-13 16:31:00, Sergey Senozhatsky wrote:
> > On (01/12/18 13:55), Petr Mladek wrote:
> > [..]
> > > > I'm not fixing console_unlock(), I'm fixing printk(). BTW, all my
> > > > kernels are CONFIG_PREEMPT (I'm a RT guy), my mind thinks more about
> > > > PREEMPT kernels than !PREEMPT ones.
> > >
> > > I would say that the patch improves also console_unlock() but only in
> > > non-preemttive context.
> > >
> > > By other words, it makes console_unlock() finite in preemptible context
> > > (limited by buffer size). It might still be unlimited in
> > > non-preemtible context.
> >
> > could you elaborate a bit?
>
> Ah, I am sorry, I swapped the conditions. I meant that
> console_unlock() is finite in non-preemptible context.
by the way. just for the record,
probably there is a way for us to have a task printing more than
O(logbuf) even in non-preemptible context.
CPU0
vprintk_emit()
preempt_disable()
console_unlock()
{
for (;;) {
printk_safe_enter_irqsave()
call_console_drivers();
printk_safe_exit_irqrestore()
<< IRQ >>
dump_stack()
printk()->log_store()
printk()->log_store()
<< iret >>
}
}
preempt_enable()
-ss
Re: [PATCH 4.9 27/75] net: igmp: Use correct source address on IGMPv3 reports
On Mon, Jan 15, 2018 at 8:44 PM, Sebastian Gottschall
wrote:
> Am 16.01.2018 um 05:32 schrieb Kevin Cernekee:
>>
>> On Mon, Jan 15, 2018 at 8:26 PM, Sebastian Gottschall
>> wrote:
>>>
>>> havent check the source addresses right now. i basicly discovered that
>>> this
>>> patch breaks the igmp routing and all traffic stops
>>> this here is from a working system with the reverted patch. if you really
>>> need that i break it again using the patch you need to wait a little bit
>>>
>>> 05:14:22.697962 IP 10.88.195.138 > 239.35.100.8: igmp v2 report
>>> 239.35.100.8
>>
>> The patch should only affect IGMPv3 behavior. I did not intend to
>> change IGMPv2 behavior. If it does, that might be a bug.
>
> it does change the behaviour indeed. i dont know the reason. but i while
> discovering the issue on 4.14 last week and newly on 4.9 this week while
> testing
> (my latest firmware i builded was from 30. december and worked) i got
> tracked it down to this small patch and it immediatly worked after reverting
> it
>>
>> Is it possible that the kernel is using a source IP of 0.0.0.0, but
>> another host does not recognize it because it does not comply with RFC
>> 3376?
>
> this is possible yes, but i cannot look into the "deutsche telekom" host
>>
>>
>> Before/after packet traces would be the best way to see if the kernel
>> change is causing it to violate the standard.
>
> let me just take a look into our patch
> + for_ifa(in_dev) {
> + if (inet_ifa_match(fl4->saddr, ifa))
> + return fl4->saddr;
> + } endfor_ifa(in_dev);
> this looks like you're checking if the source address matches to a local
> interface, if not you return 0.0.0.0 instead of the source address
>
> (193.158.35.251, 239.35.20.4)Iif: ppp0 Oifs: briptv
>
> our first source address here 193.158.35.251 is from a remote network. so
> your patch also will change the behaviour since the source address will get
> ignored
According to my understanding of igmpv3_newpack(), the destination
address should always be IGMPV3_ALL_MCR = 224.0.0.22. That is what I
see in my testing.
However, your packet trace says 239.35.100.8. I don't know how the
code that we touched would be generating an IGMPv2 packet with that
destination address.
Would it be possible to get a stack trace for the case where the
source address is being cleared to 0.0.0.0 in your configuration?
Re: [PATCH v5 2/2] printk: Hide console waiter logic into helpers
On (01/15/18 17:08), Petr Mladek wrote: > > Besides the typos (which should be fixed)... > > > > Reviewed-by: Steven Rostedt (VMware) > > JFYI, I have fixed the typos, updated the commit message for > the 1st patch and pushed all into printk.git, > branch for-4.16-console-waiter-logic, see > https://git.kernel.org/pub/scm/linux/kernel/git/pmladek/printk.git/log/?h=for-4.16-console-waiter-logic > > I know that the discussion is not completely finished but it is > somehow cycling. Sergey few times wrote that he would not block > these patches. It is high time, I put it into linux-next. I could > always remove it if decided in the discussion. Acked-by: Sergey Senozhatsky at least we have preemption out of printk->user way (one of the things I tried to tell you), which looks more like a step forward to me personally. p.s. the printk is still pretty far from what I want it to be. vprintk_emit() still can cause disturbance and damage in pretty unrelated places. e.g. hung tasks on console_sem, and so on. I'm going to keep my out-of-tree patches alive, may be they will be merged upstream in some form or another may be not. -ss
Re: [PATCH 4.9 27/75] net: igmp: Use correct source address on IGMPv3 reports
3.18 and 4.4 is affected too
Am 16.01.2018 um 04:50 schrieb Sebastian Gottschall:
please revert that on 4.9 and 4.14
it breaks igmp routing. it can be reproduced with any iptv connection
using igmp-proxy. reverting this patch fixes the issue.
Sebastian
Am 01.01.2018 um 15:32 schrieb Greg Kroah-Hartman:
4.9-stable review patch. If anyone has any objections, please let me
know.
--
From: Kevin Cernekee
[ Upstream commit a46182b00290839fa3fa159d54fd3237bd8669f0 ]
Closing a multicast socket after the final IPv4 address is deleted
from an interface can generate a membership report that uses the
source IP from a different interface. The following test script, run
from an isolated netns, reproduces the issue:
#!/bin/bash
ip link add dummy0 type dummy
ip link add dummy1 type dummy
ip link set dummy0 up
ip link set dummy1 up
ip addr add 10.1.1.1/24 dev dummy0
ip addr add 192.168.99.99/24 dev dummy1
tcpdump -U -i dummy0 &
socat EXEC:"sleep 2" \
UDP4-DATAGRAM:239.101.1.68:8889,ip-add-membership=239.0.1.68:10.1.1.1 &
sleep 1
ip addr del 10.1.1.1/24 dev dummy0
sleep 5
kill %tcpdump
RFC 3376 specifies that the report must be sent with a valid IP source
address from the destination subnet, or from address 0.0.0.0. Add an
extra check to make sure this is the case.
Signed-off-by: Kevin Cernekee
Reviewed-by: Andrew Lunn
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
net/ipv4/igmp.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -89,6 +89,7 @@
#include
#include
#include
+#include
#include
#include
@@ -321,6 +322,23 @@ igmp_scount(struct ip_mc_list *pmc, int
return scount;
}
+/* source address selection per RFC 3376 section 4.2.13 */
+static __be32 igmpv3_get_srcaddr(struct net_device *dev,
+ const struct flowi4 *fl4)
+{
+ struct in_device *in_dev = __in_dev_get_rcu(dev);
+
+ if (!in_dev)
+ return htonl(INADDR_ANY);
+
+ for_ifa(in_dev) {
+ if (inet_ifa_match(fl4->saddr, ifa))
+ return fl4->saddr;
+ } endfor_ifa(in_dev);
+
+ return htonl(INADDR_ANY);
+}
+
static struct sk_buff *igmpv3_newpack(struct net_device *dev,
unsigned int mtu)
{
struct sk_buff *skb;
@@ -368,7 +386,7 @@ static struct sk_buff *igmpv3_newpack(st
pip->frag_off = htons(IP_DF);
pip->ttl = 1;
pip->daddr = fl4.daddr;
- pip->saddr = fl4.saddr;
+ pip->saddr = igmpv3_get_srcaddr(dev, &fl4);
pip->protocol = IPPROTO_IGMP;
pip->tot_len = 0; /* filled in later */
ip_select_ident(net, skb, NULL);
--
Mit freundlichen Grüssen / Regards
Sebastian Gottschall / CTO
NewMedia-NET GmbH - DD-WRT
Firmensitz: Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565
Re: [PATCH] powerpc/pseries: include linux/types.h in asm/hvcall.h
On Tue, Jan 16, 2018 at 02:16:58PM +1100, Michael Ellerman wrote:
> Michal Suchanek writes:
>
> > Commit 6e032b350cd1 ("powerpc/powernv: Check device-tree for RFI flush
> > settings") uses u64 in asm/hvcall.h without including linux/types.h
> >
> > This breaks hvcall.h users that do not include the header themselves.
> >
> > Fixes: 6e032b350cd1 ("powerpc/powernv: Check device-tree for RFI flush
> > settings")
> >
> > Signed-off-by: Michal Suchanek
> > ---
> > arch/powerpc/include/asm/hvcall.h | 1 +
> > 1 file changed, 1 insertion(+)
>
> Thanks. None of my ~250 defconfig test builds hit this, what config are
> you using?
I also hit this, but only when I backported the change to RH's 3.10
kernel. I assumed something since then had added an indirect include.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup
On (01/15/18 07:08), Steven Rostedt wrote: > On Fri, 12 Jan 2018 13:55:37 +0100 > Petr Mladek wrote: > > > > I'm not fixing console_unlock(), I'm fixing printk(). BTW, all my > > > kernels are CONFIG_PREEMPT (I'm a RT guy), my mind thinks more about > > > PREEMPT kernels than !PREEMPT ones. > > > > I would say that the patch improves also console_unlock() but only in > > non-preemttive context. > > > > By other words, it makes console_unlock() finite in preemptible context > > (limited by buffer size). It might still be unlimited in > > non-preemtible context. > > Since I'm worried most about printk(), I would argue to make printk > console unlock always non-preempt. +1 // The next stop is "victims of O(logbuf) memorial" station :) -ss
linux-next: manual merge of the akpm tree with the net-next tree
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in:
net/ipv6/route.c
between commit:
6802f3adcb3f ("ipv6: Fix build with gcc-4.4.5")
from the net-next tree and patch:
"net/ipv6/route.c: work around gcc-4.4.4 anon union initializer issue"
from the akpm tree.
I fixed it up (I just used the net-next tree version) and can carry the
fix as necessary. This is now fixed as far as linux-next is concerned,
but any non trivial conflicts should be mentioned to your upstream
maintainer when your tree is submitted for merging. You may also want
to consider cooperating with the maintainer of the conflicting tree to
minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup
On (01/16/18 11:23), Sergey Senozhatsky wrote:
[..]
> > Adding the preempt_disable() basically means to revert the already
> > mentioned commit 6b97a20d3a7909daa06625 ("printk: set may_schedule
> > for some of console_trylock() callers").
> >
> > I originally wanted to solve this separately to make it easier. But
> > the change looks fine to me. Therefore we reached a mutual agreement.
> > Sergey, do you want to send a patch or should I just put it at
> > the end of this patchset?
>
> you can add the patch.
if you don't mind, let me fix the thing that I broke.
that would be responsible. I believe I also must say the following:
Tetsuo, many thanks for reporting the issues for song long, and
sorry that it took quite a while to revert that change.
8<
From: Sergey Senozhatsky
Subject: [PATCH] printk: never set console_may_schedule in console_trylock()
This patch, basically, reverts commit 6b97a20d3a79 ("printk:
set may_schedule for some of console_trylock() callers").
That commit was a mistake, it introduced a big dependency
on the scheduler, by enabling preemption under console_sem
in printk()->console_unlock() path, which is rather too
critical. The patch did not significantly reduce the
possibilities of printk() lockups, but made it possible to
stall printk(), as has been reported by Tetsuo Handa [1].
Another issues is that preemption under console_sem also
messes up with Steven Rostedt's hand off scheme, by making
it possible to sleep with console_sem both in console_unlock()
and in vprintk_emit(), after acquiring the console_sem
ownership (anywhere between printk_safe_exit_irqrestore() in
console_trylock_spinning() and printk_safe_enter_irqsave()
in console_unlock()). This makes hand off less likely and,
at the same time, may result in a significant amount of
pending logbuf messages. Preempted console_sem owner makes
it impossible for other CPUs to emit logbuf messages, but
does not make it impossible for other CPUs to append new
messages to the logbuf.
Reinstate the old behavior and make printk() non-preemptible.
Should any printk() lockup reports arrive they must be handled
in a different way.
[1] https://marc.info/?l=linux-mm&m=145692016122716
Fixes: 6b97a20d3a79 ("printk: set may_schedule for some of console_trylock()
callers")
Signed-off-by: Sergey Senozhatsky
Reported-by: Tetsuo Handa
---
kernel/printk/printk.c | 22 --
1 file changed, 8 insertions(+), 14 deletions(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index ffe05024c622..9cb943c90d98 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -1895,6 +1895,12 @@ asmlinkage int vprintk_emit(int facility, int level,
/* If called from the scheduler, we can not call up(). */
if (!in_sched) {
+ /*
+* Disable preemption to avoid being preempted while holding
+* console_sem which would prevent anyone from printing to
+* console
+*/
+ preempt_disable();
/*
* Try to acquire and then immediately release the console
* semaphore. The release will print out buffers and wake up
@@ -1902,6 +1908,7 @@ asmlinkage int vprintk_emit(int facility, int level,
*/
if (console_trylock_spinning())
console_unlock();
+ preempt_enable();
}
return printed_len;
@@ -2229,20 +2236,7 @@ int console_trylock(void)
return 0;
}
console_locked = 1;
- /*
-* When PREEMPT_COUNT disabled we can't reliably detect if it's
-* safe to schedule (e.g. calling printk while holding a spin_lock),
-* because preempt_disable()/preempt_enable() are just barriers there
-* and preempt_count() is always 0.
-*
-* RCU read sections have a separate preemption counter when
-* PREEMPT_RCU enabled thus we must take extra care and check
-* rcu_preempt_depth(), otherwise RCU read sections modify
-* preempt_count().
-*/
- console_may_schedule = !oops_in_progress &&
- preemptible() &&
- !rcu_preempt_depth();
+ console_may_schedule = 0;
return 1;
}
EXPORT_SYMBOL(console_trylock);
--
2.15.1
Re: [PATCH 4.9 27/75] net: igmp: Use correct source address on IGMPv3 reports
Am 16.01.2018 um 05:32 schrieb Kevin Cernekee:
On Mon, Jan 15, 2018 at 8:26 PM, Sebastian Gottschall
wrote:
havent check the source addresses right now. i basicly discovered that this
patch breaks the igmp routing and all traffic stops
this here is from a working system with the reverted patch. if you really
need that i break it again using the patch you need to wait a little bit
05:14:22.697962 IP 10.88.195.138 > 239.35.100.8: igmp v2 report 239.35.100.8
The patch should only affect IGMPv3 behavior. I did not intend to
change IGMPv2 behavior. If it does, that might be a bug.
it does change the behaviour indeed. i dont know the reason. but i while
discovering the issue on 4.14 last week and newly on 4.9 this week while
testing
(my latest firmware i builded was from 30. december and worked) i got
tracked it down to this small patch and it immediatly worked after
reverting it
Is it possible that the kernel is using a source IP of 0.0.0.0, but
another host does not recognize it because it does not comply with RFC
3376?
this is possible yes, but i cannot look into the "deutsche telekom" host
Before/after packet traces would be the best way to see if the kernel
change is causing it to violate the standard.
let me just take a look into our patch
+ for_ifa(in_dev) {
+ if (inet_ifa_match(fl4->saddr, ifa))
+ return fl4->saddr;
+ } endfor_ifa(in_dev);
this looks like you're checking if the source address matches to a local
interface, if not you return 0.0.0.0 instead of the source address
(193.158.35.251, 239.35.20.4) Iif: ppp0 Oifs: briptv
our first source address here 193.158.35.251 is from a remote network.
so your patch also will change the behaviour since the source address
will get ignored
--
Mit freundlichen Grüssen / Regards
Sebastian Gottschall / CTO
NewMedia-NET GmbH - DD-WRT
Firmensitz: Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565
Re: KASAN: use-after-free Read in tipc_group_is_open
On Mon, Jan 15, 2018 at 7:58 PM, syzbot wrote: > Hello, > > syzkaller hit the following crash on > 594831a8aba3fd045c3212a3e3bb9788c77b989d > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console output is attached. > C reproducer is attached > syzkaller reproducer is attached. See https://goo.gl/kgGztJ > for information about syzkaller reproducers > > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+799dafde028679585...@syzkaller.appspotmail.com > It will help syzbot understand when the bug is fixed. See footer for > details. > If you forward the report, please keep this part and the footer. > > == > BUG: KASAN: use-after-free in tipc_group_is_open+0x3a/0x40 > net/tipc/group.c:106 > Read of size 1 at addr 8801d89f7378 by task syzkaller275009/3704 > > CPU: 0 PID: 3704 Comm: syzkaller275009 Not tainted 4.15.0-rc7+ #190 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > Call Trace: > __dump_stack lib/dump_stack.c:17 [inline] > dump_stack+0x194/0x257 lib/dump_stack.c:53 > print_address_description+0x73/0x250 mm/kasan/report.c:252 > kasan_report_error mm/kasan/report.c:351 [inline] > kasan_report+0x25b/0x340 mm/kasan/report.c:409 > __asan_report_load1_noabort+0x14/0x20 mm/kasan/report.c:427 > tipc_group_is_open+0x3a/0x40 net/tipc/group.c:106 > tipc_poll+0x364/0x4d0 net/tipc/socket.c:740 commit eb929a91b213d2a72c5a8b4af9a1acf63bfb8287 Author: Jon Maloy Date: Mon Jan 8 21:03:31 2018 +0100 tipc: improve poll() for group member socket Apparently Jon's commit doesn't fix this. I also don't understand why Jon believes sock_poll_wait() could sync with setsockopt path... > sock_poll+0x141/0x320 net/socket.c: > do_pollfd fs/select.c:822 [inline] > do_poll fs/select.c:872 [inline] > do_sys_poll+0x715/0x10b0 fs/select.c:966 > SYSC_poll fs/select.c:1024 [inline] > SyS_poll+0x10d/0x450 fs/select.c:1012 > entry_SYSCALL_64_fastpath+0x23/0x9a > RIP: 0033:0x446129 > RSP: 002b:7f0f2df96db8 EFLAGS: 0246 ORIG_RAX: 0007 > RAX: ffda RBX: 006dbc54 RCX: 00446129 > RDX: 7fff RSI: 000a RDI: 20ef5000 > RBP: 006dbc50 R08: R09: > R10: R11: 0246 R12: > R13: 7ffc07e2923f R14: 7f0f2df979c0 R15: 0007 > > Allocated by task 3702: > save_stack+0x43/0xd0 mm/kasan/kasan.c:447 > set_track mm/kasan/kasan.c:459 [inline] > kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551 > kmem_cache_alloc_trace+0x136/0x750 mm/slab.c:3610 > kmalloc include/linux/slab.h:499 [inline] > kzalloc include/linux/slab.h:688 [inline] > tipc_group_create+0x144/0x900 net/tipc/group.c:180 > tipc_sk_join net/tipc/socket.c:2762 [inline] > tipc_setsockopt+0x274/0xce0 net/tipc/socket.c:2877 > SYSC_setsockopt net/socket.c:1823 [inline] > SyS_setsockopt+0x189/0x360 net/socket.c:1802 > entry_SYSCALL_64_fastpath+0x23/0x9a > > Freed by task 3702: > save_stack+0x43/0xd0 mm/kasan/kasan.c:447 > set_track mm/kasan/kasan.c:459 [inline] > kasan_slab_free+0x71/0xc0 mm/kasan/kasan.c:524 > __cache_free mm/slab.c:3488 [inline] > kfree+0xd6/0x260 mm/slab.c:3803 > tipc_group_delete+0x2c8/0x3d0 net/tipc/group.c:234 > tipc_sk_join net/tipc/socket.c:2775 [inline] > tipc_setsockopt+0xaa9/0xce0 net/tipc/socket.c:2877 > SYSC_setsockopt net/socket.c:1823 [inline] > SyS_setsockopt+0x189/0x360 net/socket.c:1802 > entry_SYSCALL_64_fastpath+0x23/0x9a > > The buggy address belongs to the object at 8801d89f7300 > which belongs to the cache kmalloc-128 of size 128 > The buggy address is located 120 bytes inside of > 128-byte region [8801d89f7300, 8801d89f7380) > The buggy address belongs to the page: > page:ea0007627dc0 count:1 mapcount:0 mapping:8801d89f7000 index:0x0 > flags: 0x2fffc000100(slab) > raw: 02fffc000100 8801d89f7000 00010015 > raw: ea0007622720 ea0007627ce0 8801dac00640 > page dumped because: kasan: bad access detected > > Memory state around the buggy address: > 8801d89f7200: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb > 8801d89f7280: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc >> >> 8801d89f7300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > > ^ > 8801d89f7380: fc fc fc fc fc fc fc fc 00 00 00 00 00 00 00 00 > 8801d89f7400: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc > == > > > --- > This bug is generated by a dumb bot. It may contain errors. > See https://goo.gl/tpsmEJ for details. > Direct all questions to syzkal...@googlegroups.com. > > syzbot will keep track
[RFC PATCH 2/5] softirq: Per vector deferment to workqueue
Some softirq vectors can be more CPU hungry than others. Especially
networking may sometimes deal with packet storm and need more CPU than
IRQ tail can offer without inducing scheduler latencies. In this case
the current code defers to ksoftirqd that behaves nicer. Now this nice
behaviour can be bad for other IRQ vectors that usually need quick
processing.
To solve this we only defer to threading the vectors that outreached the
calls limit on IRQ tail processing and leave the others inline on real
Soft-IRQs service. This is achieved using workqueues with
per-CPU/per-vector worklets.
Note ksoftirqd is not yet removed as it is still needed for threaded IRQs
mode.
Suggested-by: Linus Torvalds
Signed-off-by: Frederic Weisbecker
Cc: Dmitry Safonov
Cc: Eric Dumazet
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Andrew Morton
Cc: David Miller
Cc: Hannes Frederic Sowa
Cc: Ingo Molnar
Cc: Levin Alexander
Cc: Paolo Abeni
Cc: Paul E. McKenney
Cc: Radu Rendec
Cc: Rik van Riel
Cc: Stanislaw Gruszka
Cc: Thomas Gleixner
Cc: Wanpeng Li
Cc: Mauro Carvalho Chehab
---
include/linux/interrupt.h | 2 +
kernel/sched/cputime.c| 5 +-
kernel/softirq.c | 121 +-
net/ipv4/tcp_output.c | 3 +-
4 files changed, 117 insertions(+), 14 deletions(-)
diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
index 69c2382..92d044d 100644
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -514,6 +514,8 @@ static inline struct task_struct *this_cpu_ksoftirqd(void)
return this_cpu_read(ksoftirqd);
}
+extern int softirq_serving_workqueue(void);
+
/* Tasklets --- multithreaded analogue of BHs.
Main feature differing them of generic softirqs: tasklet
diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
index bac6ac9..30f70e5 100644
--- a/kernel/sched/cputime.c
+++ b/kernel/sched/cputime.c
@@ -71,7 +71,8 @@ void irqtime_account_irq(struct task_struct *curr)
*/
if (hardirq_count())
irqtime_account_delta(irqtime, delta, CPUTIME_IRQ);
- else if (in_serving_softirq() && curr != this_cpu_ksoftirqd())
+ else if (in_serving_softirq() && curr != this_cpu_ksoftirqd() &&
+!softirq_serving_workqueue())
irqtime_account_delta(irqtime, delta, CPUTIME_SOFTIRQ);
}
EXPORT_SYMBOL_GPL(irqtime_account_irq);
@@ -375,7 +376,7 @@ static void irqtime_account_process_tick(struct task_struct
*p, int user_tick,
cputime -= other;
- if (this_cpu_ksoftirqd() == p) {
+ if (this_cpu_ksoftirqd() == p || softirq_serving_workqueue()) {
/*
* ksoftirqd time do not get accounted in cpu_softirq_time.
* So, we have to handle it separately here.
diff --git a/kernel/softirq.c b/kernel/softirq.c
index e0f4b29..255da68 100644
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@ -63,14 +63,20 @@ const char * const softirq_to_name[NR_SOFTIRQS] = {
};
struct vector {
+ int nr;
unsigned int jiffy_calls;
unsigned long jiffy_snap;
+ struct work_struct work;
};
-static DEFINE_PER_CPU(struct vector, vector_cpu[NR_SOFTIRQS]) = {
- [0 ... NR_SOFTIRQS-1] = { 0, INITIAL_JIFFIES }
+struct softirq {
+ unsigned int pending_work_mask;
+ int work_running;
+ struct vector vector[NR_SOFTIRQS];
};
+static DEFINE_PER_CPU(struct softirq, softirq_cpu);
+
/*
* we cannot loop indefinitely here to avoid userspace starvation,
* but we also don't want to introduce a worst case 1/HZ latency
@@ -242,8 +248,77 @@ static inline bool lockdep_softirq_start(void) { return
false; }
static inline void lockdep_softirq_end(bool in_hardirq) { }
#endif
+int softirq_serving_workqueue(void)
+{
+ return __this_cpu_read(softirq_cpu.work_running);
+}
+
+static void vector_work_func(struct work_struct *work)
+{
+ struct vector *vector = container_of(work, struct vector, work);
+ struct softirq *softirq = this_cpu_ptr(&softirq_cpu);
+ int vec_nr = vector->nr;
+ int vec_bit = BIT(vec_nr);
+ u32 pending;
+
+ local_irq_disable();
+ pending = local_softirq_pending();
+ account_irq_enter_time(current);
+ __local_bh_disable_ip(_RET_IP_, SOFTIRQ_OFFSET);
+ lockdep_softirq_enter();
+ set_softirq_pending(pending & ~vec_bit);
+ local_irq_enable();
+
+ if (pending & vec_bit) {
+ struct softirq_action *sa = &softirq_vec[vec_nr];
+
+ kstat_incr_softirqs_this_cpu(vec_nr);
+ softirq->work_running = 1;
+ trace_softirq_entry(vec_nr);
+ sa->action(sa);
+ trace_softirq_exit(vec_nr);
+ softirq->work_running = 0;
+ }
+
+ local_irq_disable();
+
+ pending = local_softirq_pending();
+ if (pending & vec_bit)
+ schedule_work_on(smp_processor_id(), &vector->work);
+ else
+ so
[RFC/OPTIONAL PATCH 5/5] softirq: Reset vector call counter before workqueue completion
Once a softirq vector queue has been completed from the workqueue, its
call counter for the current jiffy frame can be reset in order to handle
those that will follow from the normal IRQ tail softirq processing.
Suggested-by: Linus Torvalds
Signed-off-by: Frederic Weisbecker
Cc: Dmitry Safonov
Cc: Eric Dumazet
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Andrew Morton
Cc: David Miller
Cc: Hannes Frederic Sowa
Cc: Ingo Molnar
Cc: Levin Alexander
Cc: Paolo Abeni
Cc: Paul E. McKenney
Cc: Radu Rendec
Cc: Rik van Riel
Cc: Stanislaw Gruszka
Cc: Thomas Gleixner
Cc: Wanpeng Li
Cc: Mauro Carvalho Chehab
---
kernel/softirq.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/kernel/softirq.c b/kernel/softirq.c
index b2a5384..4e5a0ef 100644
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@ -255,10 +255,13 @@ static void vector_work_func(struct work_struct *work)
local_irq_disable();
pending = local_softirq_pending();
- if (pending & vec_bit)
+ if (pending & vec_bit) {
schedule_work_on(smp_processor_id(), &vector->work);
- else
+ } else {
softirq->pending_work_mask &= ~vec_bit;
+ vector->jiffy_calls = 0;
+ vector->jiffy_snap = jiffies;
+ }
lockdep_softirq_exit();
account_irq_exit_time(current);
--
2.7.4
[RFC PATCH 3/5] softirq: Defer to workqueue when rescheduling is needed
One more step toward converting ksoftirqd to per vector workqueues.
Suggested-by: Paolo Abeni
Suggested-by: Linus Torvalds
Signed-off-by: Frederic Weisbecker
Cc: Dmitry Safonov
Cc: Eric Dumazet
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Andrew Morton
Cc: David Miller
Cc: Hannes Frederic Sowa
Cc: Ingo Molnar
Cc: Levin Alexander
Cc: Paolo Abeni
Cc: Paul E. McKenney
Cc: Radu Rendec
Cc: Rik van Riel
Cc: Stanislaw Gruszka
Cc: Thomas Gleixner
Cc: Wanpeng Li
Cc: Mauro Carvalho Chehab
---
kernel/softirq.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/kernel/softirq.c b/kernel/softirq.c
index 255da68..441e654 100644
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@ -389,16 +389,14 @@ asmlinkage __visible void __softirq_entry
__do_softirq(void)
pending = local_softirq_pending() & ~softirq->pending_work_mask;
if (pending) {
- if (need_resched()) {
- wakeup_softirqd();
- } else {
- /* Vectors that overreached the limits are threaded */
- if (overrun & pending)
- do_softirq_workqueue(overrun & pending);
- pending &= ~overrun;
- if (pending)
- goto restart;
- }
+ if (need_resched())
+ overrun = pending;
+ /* Vectors that overreached the limits are threaded */
+ if (overrun & pending)
+ do_softirq_workqueue(overrun & pending);
+ pending &= ~overrun;
+ if (pending)
+ goto restart;
}
lockdep_softirq_end(in_hardirq);
--
2.7.4
[RFC PATCH 1/5] softirq: Account time and iteration stats per vector
As we plan to be able to defer some specific softirq vector processing
to workqueues when those vectors need more time than IRQs can offer,
let's first introduce the per-vector call counter/limit.
Each softirq vector is allowed to be called on IRQ tail at most
MAX_SOFTIRQ_RESTART per jiffy. Once we reach that limit, the softirq
processing is deferred to ksoftirqd. The threading will be divided to
per vector worklets in further patches.
Suggested-by: Linus Torvalds
Signed-off-by: Frederic Weisbecker
Cc: Dmitry Safonov
Cc: Eric Dumazet
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Andrew Morton
Cc: David Miller
Cc: Hannes Frederic Sowa
Cc: Ingo Molnar
Cc: Levin Alexander
Cc: Paolo Abeni
Cc: Paul E. McKenney
Cc: Radu Rendec
Cc: Rik van Riel
Cc: Stanislaw Gruszka
Cc: Thomas Gleixner
Cc: Wanpeng Li
Cc: Mauro Carvalho Chehab
---
kernel/softirq.c | 41 ++---
1 file changed, 26 insertions(+), 15 deletions(-)
diff --git a/kernel/softirq.c b/kernel/softirq.c
index 2f5e87f..e0f4b29 100644
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@ -62,6 +62,15 @@ const char * const softirq_to_name[NR_SOFTIRQS] = {
"TASKLET", "SCHED", "HRTIMER", "RCU"
};
+struct vector {
+ unsigned int jiffy_calls;
+ unsigned long jiffy_snap;
+};
+
+static DEFINE_PER_CPU(struct vector, vector_cpu[NR_SOFTIRQS]) = {
+ [0 ... NR_SOFTIRQS-1] = { 0, INITIAL_JIFFIES }
+};
+
/*
* we cannot loop indefinitely here to avoid userspace starvation,
* but we also don't want to introduce a worst case 1/HZ latency
@@ -192,19 +201,13 @@ EXPORT_SYMBOL(__local_bh_enable_ip);
/*
* We restart softirq processing for at most MAX_SOFTIRQ_RESTART times,
- * but break the loop if need_resched() is set or after 2 ms.
- * The MAX_SOFTIRQ_TIME provides a nice upper bound in most cases, but in
- * certain cases, such as stop_machine(), jiffies may cease to
- * increment and so we need the MAX_SOFTIRQ_RESTART limit as
- * well to make sure we eventually return from this method.
- *
+ * but break the loop if need_resched() is set.
* These limits have been established via experimentation.
* The two things to balance is latency against fairness -
* we want to handle softirqs as soon as possible, but they
* should not be able to lock up the box.
*/
-#define MAX_SOFTIRQ_TIME msecs_to_jiffies(2)
-#define MAX_SOFTIRQ_RESTART 10
+#define MAX_SOFTIRQ_RESTART 20
#ifdef CONFIG_TRACE_IRQFLAGS
/*
@@ -241,12 +244,10 @@ static inline void lockdep_softirq_end(bool in_hardirq) {
}
asmlinkage __visible void __softirq_entry __do_softirq(void)
{
- unsigned long end = jiffies + MAX_SOFTIRQ_TIME;
unsigned long old_flags = current->flags;
- int max_restart = MAX_SOFTIRQ_RESTART;
struct softirq_action *h;
bool in_hardirq;
- __u32 pending;
+ __u32 pending, overrun = 0;
int softirq_bit;
/*
@@ -271,6 +272,7 @@ asmlinkage __visible void __softirq_entry __do_softirq(void)
h = softirq_vec;
while ((softirq_bit = ffs(pending))) {
+ struct vector *vector;
unsigned int vec_nr;
int prev_count;
@@ -284,6 +286,16 @@ asmlinkage __visible void __softirq_entry
__do_softirq(void)
trace_softirq_entry(vec_nr);
h->action(h);
trace_softirq_exit(vec_nr);
+
+ vector = this_cpu_ptr(&vector_cpu[vec_nr]);
+ if (time_before(vector->jiffy_snap, jiffies)) {
+ vector->jiffy_calls = 0;
+ vector->jiffy_snap = jiffies;
+ }
+
+ if (++vector->jiffy_calls > MAX_SOFTIRQ_RESTART)
+ overrun |= 1 << vec_nr;
+
if (unlikely(prev_count != preempt_count())) {
pr_err("huh, entered softirq %u %s %p with
preempt_count %08x, exited with %08x?\n",
vec_nr, softirq_to_name[vec_nr], h->action,
@@ -299,11 +311,10 @@ asmlinkage __visible void __softirq_entry
__do_softirq(void)
pending = local_softirq_pending();
if (pending) {
- if (time_before(jiffies, end) && !need_resched() &&
- --max_restart)
+ if (overrun || need_resched())
+ wakeup_softirqd();
+ else
goto restart;
-
- wakeup_softirqd();
}
lockdep_softirq_end(in_hardirq);
--
2.7.4
[RFC PATCH 4/5] softirq: Replace ksoftirqd with workqueues entirely
Ksoftirqd only remains to implement threaded IRQs. Convert it to
existing per-vector workqueues to avoid code duplication.
Suggested-by: Linus Torvalds
Suggested-by: Paolo Abeni
Signed-off-by: Frederic Weisbecker
Cc: Dmitry Safonov
Cc: Eric Dumazet
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Andrew Morton
Cc: David Miller
Cc: Hannes Frederic Sowa
Cc: Ingo Molnar
Cc: Levin Alexander
Cc: Paolo Abeni
Cc: Paul E. McKenney
Cc: Radu Rendec
Cc: Rik van Riel
Cc: Stanislaw Gruszka
Cc: Thomas Gleixner
Cc: Wanpeng Li
Cc: Mauro Carvalho Chehab
---
Documentation/RCU/stallwarn.txt | 4 +-
include/linux/interrupt.h | 7
kernel/sched/cputime.c | 13 +++---
kernel/sched/sched.h| 4 +-
kernel/softirq.c| 87 +
net/ipv4/tcp_output.c | 4 +-
6 files changed, 31 insertions(+), 88 deletions(-)
diff --git a/Documentation/RCU/stallwarn.txt b/Documentation/RCU/stallwarn.txt
index a08f928..ea3a8de 100644
--- a/Documentation/RCU/stallwarn.txt
+++ b/Documentation/RCU/stallwarn.txt
@@ -17,8 +17,8 @@ o A CPU looping in an RCU read-side critical section.
o A CPU looping with interrupts disabled.
o A CPU looping with preemption disabled. This condition can
- result in RCU-sched stalls and, if ksoftirqd is in use, RCU-bh
- stalls.
+ result in RCU-sched stalls and, if softirq workqueue is in use,
+ RCU-bh stalls.
o A CPU looping with bottom halves disabled. This condition can
result in RCU-sched and RCU-bh stalls.
diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
index 92d044d..680f620 100644
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -507,13 +507,6 @@ extern void __raise_softirq_irqoff(unsigned int nr);
extern void raise_softirq_irqoff(unsigned int nr);
extern void raise_softirq(unsigned int nr);
-DECLARE_PER_CPU(struct task_struct *, ksoftirqd);
-
-static inline struct task_struct *this_cpu_ksoftirqd(void)
-{
- return this_cpu_read(ksoftirqd);
-}
-
extern int softirq_serving_workqueue(void);
/* Tasklets --- multithreaded analogue of BHs.
diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
index 30f70e5..c5b8dbd 100644
--- a/kernel/sched/cputime.c
+++ b/kernel/sched/cputime.c
@@ -64,15 +64,14 @@ void irqtime_account_irq(struct task_struct *curr)
irqtime->irq_start_time += delta;
/*
-* We do not account for softirq time from ksoftirqd here.
-* We want to continue accounting softirq time to ksoftirqd thread
+* We do not account for softirq time from workqueue here.
+* We want to continue accounting softirq time to workqueue thread
* in that case, so as not to confuse scheduler with a special task
* that do not consume any time, but still wants to run.
*/
if (hardirq_count())
irqtime_account_delta(irqtime, delta, CPUTIME_IRQ);
- else if (in_serving_softirq() && curr != this_cpu_ksoftirqd() &&
-!softirq_serving_workqueue())
+ else if (in_serving_softirq() && !softirq_serving_workqueue())
irqtime_account_delta(irqtime, delta, CPUTIME_SOFTIRQ);
}
EXPORT_SYMBOL_GPL(irqtime_account_irq);
@@ -376,11 +375,11 @@ static void irqtime_account_process_tick(struct
task_struct *p, int user_tick,
cputime -= other;
- if (this_cpu_ksoftirqd() == p || softirq_serving_workqueue()) {
+ if (softirq_serving_workqueue()) {
/*
-* ksoftirqd time do not get accounted in cpu_softirq_time.
+* Softirq wq time do not get accounted in cpu_softirq_time.
* So, we have to handle it separately here.
-* Also, p->stime needs to be updated for ksoftirqd.
+* Also, p->stime needs to be updated for workqueue.
*/
account_system_index_time(p, cputime, CPUTIME_SOFTIRQ);
} else if (user_tick) {
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index b19552a2..5d481f1 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -2061,8 +2061,8 @@ struct irqtime {
DECLARE_PER_CPU(struct irqtime, cpu_irqtime);
/*
- * Returns the irqtime minus the softirq time computed by ksoftirqd.
- * Otherwise ksoftirqd's sum_exec_runtime is substracted its own runtime
+ * Returns the irqtime minus the softirq time computed by workqueue.
+ * Otherwise workqueue's sum_exec_runtime is substracted its own runtime
* and never move forward.
*/
static inline u64 irq_time_read(int cpu)
diff --git a/kernel/softirq.c b/kernel/softirq.c
index 441e654..b2a5384 100644
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@ -55,8 +55,6 @@ EXPORT_SYMBOL(irq_stat);
static struct softirq_action softirq_vec[NR_SOFTIRQS]
__cacheline_aligned_in_smp;
-DEFINE_PER_CPU(struct task_struct *, ksoftirqd);
-
const char * const softirq_to_name[NR_SOFTIRQS] = {
[RFC PATCH 0/5] softirq: Per vector threading v2
So this set is in a testable state. I addressed preliminary reviews from Eric Dumazet, Paolo Abeni and Linus. You may want to play with MAX_SOFTIRQ_RESTART value, which is now the number of calls allowed for a vector in a jiffy frame before it gets queued to the workqueue. I set it to the arbitrary value of 20 which is likely too low. Also I'm not sure about the last patch. For example in the usecase of Dmitry Safonov it may be better not to apply it. I guess only testing and reviews can tell. git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git softirq/thread HEAD: 5a4c02b25bdcd853e3874d5319492ea6097f6e70 Thanks, Frederic --- Frederic Weisbecker (5): softirq: Account time and iteration stats per vector softirq: Per vector deferment to workqueue softirq: Defer to workqueue when rescheduling is needed softirq: Replace ksoftirqd with workqueues entirely softirq: Reset vector call counter before workqueue completion Documentation/RCU/stallwarn.txt | 4 +- include/linux/interrupt.h | 7 +- kernel/sched/cputime.c | 12 +-- kernel/sched/sched.h| 4 +- kernel/softirq.c| 232 +--- net/ipv4/tcp_output.c | 5 +- 6 files changed, 161 insertions(+), 103 deletions(-)
Re: [PATCH 4.9 27/75] net: igmp: Use correct source address on IGMPv3 reports
On Mon, Jan 15, 2018 at 8:26 PM, Sebastian Gottschall wrote: > havent check the source addresses right now. i basicly discovered that this > patch breaks the igmp routing and all traffic stops > this here is from a working system with the reverted patch. if you really > need that i break it again using the patch you need to wait a little bit > > 05:14:22.697962 IP 10.88.195.138 > 239.35.100.8: igmp v2 report 239.35.100.8 The patch should only affect IGMPv3 behavior. I did not intend to change IGMPv2 behavior. If it does, that might be a bug. Is it possible that the kernel is using a source IP of 0.0.0.0, but another host does not recognize it because it does not comply with RFC 3376? Before/after packet traces would be the best way to see if the kernel change is causing it to violate the standard.
[PATCH] scripts: kconfig: menu: fixed a coding style issue
Fixed coding style issue.
Signed-off-by: Robert Donald Rickett
---
scripts/kconfig/menu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/kconfig/menu.c b/scripts/kconfig/menu.c
index e9357931b47d..62f03f4eb96d 100644
--- a/scripts/kconfig/menu.c
+++ b/scripts/kconfig/menu.c
@@ -143,7 +143,7 @@ static struct property *menu_add_prop(enum prop_type type,
char *prompt, struct
prop_warn(prop, "prompt redefined");
/* Apply all upper menus' visibilities to actual prompts. */
- if(type == P_PROMPT) {
+ if (type == P_PROMPT) {
struct menu *menu = current_entry;
while ((menu = menu->parent) != NULL) {
--
2.14.1
Re: [PATCH 4.9 27/75] net: igmp: Use correct source address on IGMPv3 reports
Am 16.01.2018 um 04:58 schrieb Kevin Cernekee: On Mon, Jan 15, 2018 at 7:50 PM, Sebastian Gottschall wrote: please revert that on 4.9 and 4.14 it breaks igmp routing. it can be reproduced with any iptv connection using igmp-proxy. reverting this patch fixes the issue. Hi Sebastian, Is this the correct igmp-proxy (based on mrouted)? https://github.com/mirror/dd-wrt/tree/master/src/router/igmp-proxy What is the actual vs. expected source address you are seeing on the IGMP packets? this github mirror is unmaintained. (svn.dd-wrt.com is the correct repository) but yes, but same applies to upstream https://github.com/pali/igmpproxy havent check the source addresses right now. i basicly discovered that this patch breaks the igmp routing and all traffic stops this here is from a working system with the reverted patch. if you really need that i break it again using the patch you need to wait a little bit 05:14:22.697962 IP 10.88.195.138 > 239.35.100.8: igmp v2 report 239.35.100.8 root@shellfast:/proc/4032/net# /tmp/ip mroute (193.158.35.251, 239.35.20.4) Iif: ppp0 Oifs: briptv (10.88.193.141, 239.255.255.250) Iif: ppp0 Oifs: briptv (10.88.193.145, 239.255.255.250) Iif: ppp0 Oifs: briptv (10.88.195.138, 239.255.255.250) Iif: ppp0 Oifs: briptv (10.88.195.129, 239.255.255.250) Iif: ppp0 Oifs: briptv (10.88.193.134, 239.255.255.250) Iif: ppp0 Oifs: briptv (10.88.195.1, 239.255.255.250) Iif: ppp0 Oifs: briptv (10.88.193.109, 239.255.255.250) Iif: ppp0 Oifs: br0 (10.88.193.145, 239.192.152.143) Iif: ppp0 Oifs: br0 (10.88.193.1, 239.255.255.250) Iif: ppp0 Oifs: br0 -- Mit freundlichen Grüssen / Regards Sebastian Gottschall / CTO NewMedia-NET GmbH - DD-WRT Firmensitz: Stubenwaldallee 21a, 64625 Bensheim Registergericht: Amtsgericht Darmstadt, HRB 25473 Geschäftsführer: Peter Steinhäuser, Christian Scheele http://www.dd-wrt.com email: s.gottsch...@dd-wrt.com Tel.: +496251-582650 / Fax: +496251-5826565
Re: [PATCH v3 0/8] ARM: sun9i: SMP and CPU hotplug support
On Tue, Jan 16, 2018 at 5:00 AM, Nicolas Pitre wrote: > On Mon, 15 Jan 2018, Chen-Yu Tsai wrote: > >> Changes since v2: >> - Do away with the MCPM framework, directly implement smp_ops >> - Some debug messages were clarified >> - New ARCH_SUNXI_MCPM Kconfig symbol for this feature > > You should use ARCH_SUNXI_SMP instead to avoid confusion with the actual > MCPM code. Ditto for function names as Dave mentioned. All switched to "MC_SMP". There is existing, albeit deprecated, SMP code for single cluster SoCs, so "multi cluster" is desired to differentiate from the old stuff. > For the ARM to Thumb switch you could add something like this at the > beginning of your entry code: > > #ifdef CONFIG_THUMB2_KERNEL > .arm > mov ip, #1 > bx ip > .thumb > #endif > [your code follows here] > > And make sure that code is word aligned. Thanks for the tip. As I mentioned in my reply to Dave, this wasn't really needed. Thanks again! ChenYu
Re: [PATCH 1/2] objtool: Fix seg fault with gold linker
On Tue, Jan 16, 2018 at 01:21:44AM +0100, Ingo Molnar wrote: > > * Josh Poimboeuf wrote: > > > Objtool seg faults when the gold linker is used with > > CONFIG_MODVERSIONS=y and CONFIG_UNWINDER_ORC=y. > > > > With CONFIG_MODVERSIONS=y, the .o file gets passed to the linker before > > being passed to objtool. The gold linker seems to strip unused ELF > > symbols by default, which confuses objtool and causes the seg fault when > > it's trying to generate ORC metadata. > > BTW., if it's still unfixed, could we fix that segfault as well, and turn it > into > a more useful failure message? Good point. I'll fix up this seg fault, and the other one found/introduced when adding retpoline support. -- Josh
Re: [PATCH v3 1/8] ARM: sun9i: Support SMP bring-up on A80
On Mon, Jan 15, 2018 at 8:04 PM, Dave Martin wrote:
> On Mon, Jan 15, 2018 at 07:14:43AM +, Chen-Yu Tsai wrote:
>> The A80 is a big.LITTLE SoC with 1 cluster of 4 Cortex-A7s and
>> 1 cluster of 4 Cortex-A15s.
>>
>> This patch adds support to bring up the second cluster and thus all
>> cores using custom platform SMP code. Core/cluster power down has not
>> been implemented, thus CPU hotplugging is not supported.
>>
>> This is limited to !THUMB2_KERNEL for now. The entry code must be built
>> as ARM machine code, and it does not switch modes. Further work was
>> done to move the assembly code to a separate file and add the proper
>> mode statements and mode switching instructions. However initial tests
>> failed to boot properly with Thumb-2.
>>
>> Parts of the trampoline and re-entry code for the boot cpu was adapted
>> from the MCPM framework.
>>
>> Signed-off-by: Chen-Yu Tsai
>> ---
>> arch/arm/mach-sunxi/Kconfig | 7 +
>> arch/arm/mach-sunxi/Makefile | 1 +
>> arch/arm/mach-sunxi/mcpm.c | 548
>> +++
>> 3 files changed, 556 insertions(+)
>> create mode 100644 arch/arm/mach-sunxi/mcpm.c
>>
>> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
>> index 58153cdf025b..b53e37d170e6 100644
>> --- a/arch/arm/mach-sunxi/Kconfig
>> +++ b/arch/arm/mach-sunxi/Kconfig
>> @@ -48,4 +48,11 @@ config MACH_SUN9I
>> default ARCH_SUNXI
>> select ARM_GIC
>>
>> +config ARCH_SUNXI_MCPM
>> + bool
>> + depends on SMP && !THUMB2_KERNEL
>> + default MACH_SUN9I
>> + select ARM_CCI400_PORT_CTRL
>> + select ARM_CPU_SUSPEND
>> +
>
> If this no longer uses MCPM, you should get rid of "mcpm" from all the
> names, comments etc. -- it's just confusing otherwise.
Discussed with Maxime. Will switch to "mc_smp" instead. The "mc" part
is there to differentiate with some old smp code we have for the A31
and A23.
>
>> endif
>> diff --git a/arch/arm/mach-sunxi/Makefile b/arch/arm/mach-sunxi/Makefile
>> index 27b168f121a1..cacd1afa8137 100644
>> --- a/arch/arm/mach-sunxi/Makefile
>> +++ b/arch/arm/mach-sunxi/Makefile
>> @@ -1,2 +1,3 @@
>> obj-$(CONFIG_ARCH_SUNXI) += sunxi.o
>> +obj-$(CONFIG_ARCH_SUNXI_MCPM) += mcpm.o
>> obj-$(CONFIG_SMP) += platsmp.o
>> diff --git a/arch/arm/mach-sunxi/mcpm.c b/arch/arm/mach-sunxi/mcpm.c
>> new file mode 100644
>> index ..7c77bb3b367a
>> --- /dev/null
>> +++ b/arch/arm/mach-sunxi/mcpm.c
>
> [...]
>
>> +static int sunxi_mcpm_cpu_table[SUNXI_NR_CLUSTERS][SUNXI_CPUS_PER_CLUSTER];
>> +static int sunxi_mcpm_first_comer;
>> +
>> +/*
>> + * Enable cluster-level coherency, in preparation for turning on the MMU.
>> + *
>> + * Also enable regional clock gating and L2 data latency settings for
>> + * Cortex-A15. These settings are from the vendor kernel.
>> + */
>> +static void __naked sunxi_mcpm_cluster_cache_enable(void)
>> +{
>> + asm volatile (
>> + "mrcp15, 0, r1, c0, c0, 0\n"
>> + "movw r2, #" __stringify(ARM_CPU_PART_MASK & 0x) "\n"
>> + "movt r2, #" __stringify(ARM_CPU_PART_MASK >> 16) "\n"
>> + "andr1, r1, r2\n"
>> + "movw r2, #" __stringify(ARM_CPU_PART_CORTEX_A15 & 0x)
>> "\n"
>> + "movt r2, #" __stringify(ARM_CPU_PART_CORTEX_A15 >> 16) "\n"
>> + "cmpr1, r2\n"
>> + "bnenot_a15\n"
>> +
>> + /* The following is Cortex-A15 specific */
>> +
>> + /* ACTLR2: Enable CPU regional clock gates */
>> + "mrc p15, 1, r1, c15, c0, 4\n"
>> + "orr r1, r1, #(0x1<<31)\n"
>> + "mcr p15, 1, r1, c15, c0, 4\n"
>> +
>> + /* L2ACTLR */
>> + "mrc p15, 1, r1, c15, c0, 0\n"
>> + /* Enable L2, GIC, and Timer regional clock gates */
>> + "orr r1, r1, #(0x1<<26)\n"
>> + /* Disable clean/evict from being pushed to external */
>> + "orr r1, r1, #(0x1<<3)\n"
>> + "mcr p15, 1, r1, c15, c0, 0\n"
>> +
>> + /* L2CTRL: L2 data RAM latency */
>> + "mrc p15, 1, r1, c9, c0, 2\n"
>> + "bic r1, r1, #(0x7<<0)\n"
>> + "orr r1, r1, #(0x3<<0)\n"
>> + "mcr p15, 1, r1, c9, c0, 2\n"
>> +
>> + /* End of Cortex-A15 specific setup */
>> + "not_a15:\n"
>> +
>> + /* Get value of sunxi_mcpm_first_comer */
>> + "adrr1, first\n"
>> + "ldrr0, [r1]\n"
>> + "ldrr0, [r1, r0]\n"
>> +
>> + /* Skip cci_enable_port_for_self if not first comer */
>> + "cmpr0, #0\n"
>> + "bxeq lr\n"
>> + "b cci_enable_port_for_self\n"
>
> For Thumb, you need a ".align 2" here.
>
> I've never understood why gas doesn't implicitly align .word on arches
> that care about data alignment, but it doesn't...
>
> Since the MMU isn't on yet, you may get alignment faults if the .word
> is misaligned in the asse
Re: [PATCH 30/40] drm/rockchip: Flush PSR before committing modeset disables/enables
Hi Thierry, On Tue, Jan 16, 2018 at 2:16 AM, Thierry Escande wrote: > From: Tomasz Figa > > Currently PSR flush is triggered from CRTC's .atomic_begin() callback, > which is executed after modeset disables and enables and before plane > updates are committed. Since PSR flush and re-enable can be triggered > asynchronously by external sources (input event, delayed work), it can > race with hardware programming done in the aforementioned stages. > > To avoid the race, we can trigger PSR flush before committing modeset > disables/enables. This also has the advantage of removing some > PSR-specific knowledge from the VOP driver. FYI, this patch was eventually found to still leave few unsolved races and was later replaced with a more comprehensive redesign of Rockchip PSR code. Please refer to the following Chromium patches: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/430429/ https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/436571/ https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/438228/ https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/438229/ <- This one effectively replaces all the code added in this patch. https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/438230/ Best regards, Tomasz
Re: [patch v8 0/3] drivers/platform: replace module x86/mlxcpld-hotplug with mellanox/mlxreg-hotplug
On Mon, Jan 15, 2018 at 07:46:06PM -0800, Darren Hart wrote: > On Mon, Jan 15, 2018 at 07:42:09PM -0800, Darren Hart wrote: > > To follow this email, are two patches which are minor incremental > > cleanups, which I'd appreciate your review of before I push them to > > testing. > > > From ccfc9b138034b5ccd89da1d938e9241eaeb4dabf Mon Sep 17 00:00:00 2001 > Message-Id: > > In-Reply-To: > <2c5d26ee913e0f5f7d13c559d85e8da7e4ddcdab.1516073719.git.dvh...@infradead.org> > References: > <2c5d26ee913e0f5f7d13c559d85e8da7e4ddcdab.1516073719.git.dvh...@infradead.org> > From: "Darren Hart (VMware)" > Date: Mon, 15 Jan 2018 19:28:10 -0800 > Subject: [PATCH 2/2] platform/mellanox: mlxreg-hotplug: Cleanup local variable > declarations The v8 series with updated commit messages and my two patches are also available here to fetch if useful: http://git.infradead.org/linux-platform-drivers-x86.git/shortlog/refs/heads/review-dvhart 2 of 3 needs an improved commit message still. -- Darren Hart VMware Open Source Technology Center
[tip:x86/platform] x86/platform/UV: Fix UV4A BAU MMRs
Commit-ID: a631a0a7a3caf6a9924856f3dcfe256e747f7467
Gitweb: https://git.kernel.org/tip/a631a0a7a3caf6a9924856f3dcfe256e747f7467
Author: Mike Travis
AuthorDate: Mon, 8 Jan 2018 13:40:04 -0600
Committer: Ingo Molnar
CommitDate: Tue, 16 Jan 2018 03:58:38 +0100
x86/platform/UV: Fix UV4A BAU MMRs
Fixes to accommodate Intel Processor changes for UV4A broadcast assist unit
(BAU) MMRs.
Signed-off-by: Mike Travis
Acked-by: Andrew Banman
Cc: Andrew Morton
Cc: Dimitri Sivanich
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Russ Anderson
Cc: Thomas Gleixner
Link:
http://lkml.kernel.org/r/1515440405-20880-7-git-send-email-mike.tra...@hpe.com
Signed-off-by: Ingo Molnar
---
arch/x86/include/asm/uv/uv_mmrs.h | 59 +--
1 file changed, 38 insertions(+), 21 deletions(-)
diff --git a/arch/x86/include/asm/uv/uv_mmrs.h
b/arch/x86/include/asm/uv/uv_mmrs.h
index 30db549..ecb9dde 100644
--- a/arch/x86/include/asm/uv/uv_mmrs.h
+++ b/arch/x86/include/asm/uv/uv_mmrs.h
@@ -39,9 +39,11 @@
* #define UV2Hxxx b
* #define UV3Hxxx c
* #define UV4Hxxx d
+ * #define UV4AHxxx e
* #define UVHxxx (is_uv1_hub() ? UV1Hxxx :
* (is_uv2_hub() ? UV2Hxxx :
* (is_uv3_hub() ? UV3Hxxx :
+ * (is_uv4a_hub() ? UV4AHxxx :
* UV4Hxxx))
*
* If the MMR exists on all hub types > 1 but have different addresses, the
@@ -49,8 +51,10 @@
* #define UV2Hxxx b
* #define UV3Hxxx c
* #define UV4Hxxx d
+ * #define UV4AHxxx e
* #define UVHxxx (is_uv2_hub() ? UV2Hxxx :
* (is_uv3_hub() ? UV3Hxxx :
+ * (is_uv4a_hub() ? UV4AHxxx :
* UV4Hxxx))
*
* union uvh_xxx {
@@ -63,6 +67,7 @@
* } s2;
* struct uv3h_xxx_s { # Full UV3 definition (*)
* } s3;
+ * (NOTE: No struct uv4ah_xxx_s members exist)
* struct uv4h_xxx_s { # Full UV4 definition (*)
* } s4;
* };
@@ -2780,35 +2785,47 @@ union uvh_lb_bau_sb_activation_status_1_u {
/*is_uv4_hub*/ UV4H_LB_BAU_SB_DESCRIPTOR_BASE_32)
#define UVH_LB_BAU_SB_DESCRIPTOR_BASE_PAGE_ADDRESS_SHFT12
-#define UVH_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT 49
-#define UVH_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK 0x7ffeUL
+#define UV1H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT49
#define UV1H_LB_BAU_SB_DESCRIPTOR_BASE_PAGE_ADDRESS_MASK 0x07fff000UL
+#define UV1H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK0x7ffeUL
-
+#define UV2H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT49
#define UV2H_LB_BAU_SB_DESCRIPTOR_BASE_PAGE_ADDRESS_MASK 0x07fff000UL
+#define UV2H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK0x7ffeUL
+#define UV3H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT49
#define UV3H_LB_BAU_SB_DESCRIPTOR_BASE_PAGE_ADDRESS_MASK 0x07fff000UL
+#define UV3H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK0x7ffeUL
+#define UV4H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT49
#define UV4H_LB_BAU_SB_DESCRIPTOR_BASE_PAGE_ADDRESS_MASK 0x3000UL
-
-
-union uvh_lb_bau_sb_descriptor_base_u {
- unsigned long v;
- struct uvh_lb_bau_sb_descriptor_base_s {
- unsigned long rsvd_0_11:12;
- unsigned long rsvd_12_48:37;
- unsigned long node_id:14; /* RW */
- unsigned long rsvd_63:1;
- } s;
- struct uv4h_lb_bau_sb_descriptor_base_s {
- unsigned long rsvd_0_11:12;
- unsigned long page_address:34;/* RW */
- unsigned long rsvd_46_48:3;
- unsigned long node_id:14; /* RW */
- unsigned long rsvd_63:1;
- } s4;
-};
+#define UV4H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK0x7ffeUL
+
+#define UV4AH_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT 53
+#define UV4AH_LB_BAU_SB_DESCRIPTOR_BASE_PAGE_ADDRESS_MASK 0x000ff000UL
+#define UV4AH_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK 0xffe0UL
+
+#define UVH_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT ( \
+ is_uv1_hub() ? UV1H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT :\
+ is_uv2_hub() ? UV2H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT :\
+ is_uv3_hub() ? UV3H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT :\
+ is_uv4a_hub() ? UV4AH_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT : \
+ /*is_uv4_hub*/ UV4H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT)
+
+#define UVH_LB_BAU_SB_DESCRIPTOR_PAGE_ADDRESS_MASK ( \
+ is_uv1_hub() ? UV1H_LB_BAU_SB_DESCRIPTOR_PAGE_ADDRESS_MASK :\
+ is_uv2_hub() ? UV2H_LB_BAU_SB_DESCRIPTOR_PAGE_ADDRESS_MASK :\
+ is_uv3_hub() ? UV3H_LB_BAU_SB_DESCRIPTOR_PAGE_ADDRESS_MASK :\
+ is_uv4a_hub() ? UV4AH_LB_BAU
Re: [PATCH 4.9 27/75] net: igmp: Use correct source address on IGMPv3 reports
On Mon, Jan 15, 2018 at 7:50 PM, Sebastian Gottschall wrote: > please revert that on 4.9 and 4.14 > it breaks igmp routing. it can be reproduced with any iptv connection using > igmp-proxy. reverting this patch fixes the issue. Hi Sebastian, Is this the correct igmp-proxy (based on mrouted)? https://github.com/mirror/dd-wrt/tree/master/src/router/igmp-proxy What is the actual vs. expected source address you are seeing on the IGMP packets?
Re: [PATCH 01/40] drm/rockchip: Get rid of some unnecessary code
Hi Thierry, On Tue, Jan 16, 2018 at 2:15 AM, Thierry Escande wrote: > From: Tomasz Figa > > Current code implements prepare_fb and cleanup_fb callbacks only to > grab/release fb references, which is already done by atomic framework > when creating/destryoing plane state. AFAICT this is already gone in current code, so only the part mentioned below remains. > Also there are some unused fields > vop and vop_win structs. Let's remove these unused bits. ^^ Best regards, Tomasz Best regards, Tomasz
[tip:x86/platform] x86/platform/uv/BAU: Replace hard-coded values with MMR definitions
Commit-ID: 1da2fd61d956a01ead87173a8367e5c664617f7b Gitweb: https://git.kernel.org/tip/1da2fd61d956a01ead87173a8367e5c664617f7b Author: Andrew Banman AuthorDate: Mon, 8 Jan 2018 13:43:12 -0600 Committer: Ingo Molnar CommitDate: Tue, 16 Jan 2018 03:58:38 +0100 x86/platform/uv/BAU: Replace hard-coded values with MMR definitions Replaces hard-coded node ID shift for the descriptor base MMR to fix initialization on UV4A while maintaining support for previous architectures. Signed-off-by: Andrew Banman Acked-by: Mike Travis Cc: Andrew Morton Cc: Dimitri Sivanich Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Russ Anderson Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/1515440592-44060-1-git-send-email-aban...@hpe.com Signed-off-by: Ingo Molnar --- arch/x86/include/asm/uv/uv_bau.h | 1 - arch/x86/platform/uv/tlb_uv.c| 3 ++- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/include/asm/uv/uv_bau.h b/arch/x86/include/asm/uv/uv_bau.h index 7cac798..7803114 100644 --- a/arch/x86/include/asm/uv/uv_bau.h +++ b/arch/x86/include/asm/uv/uv_bau.h @@ -48,7 +48,6 @@ #define UV2_NET_ENDPOINT_INTD 0x28 #define UV_NET_ENDPOINT_INTD (is_uv1_hub() ? \ UV1_NET_ENDPOINT_INTD : UV2_NET_ENDPOINT_INTD) -#define UV_DESC_PSHIFT 49 #define UV_PAYLOADQ_GNODE_SHIFT49 #define UV_PTC_BASENAME"sgi_uv/ptc_statistics" #define UV_BAU_BASENAME"sgi_uv/bau_tunables" diff --git a/arch/x86/platform/uv/tlb_uv.c b/arch/x86/platform/uv/tlb_uv.c index 8538a67..c2e9285 100644 --- a/arch/x86/platform/uv/tlb_uv.c +++ b/arch/x86/platform/uv/tlb_uv.c @@ -1751,7 +1751,8 @@ static void activation_descriptor_init(int node, int pnode, int base_pnode) uv1 = 1; /* the 14-bit pnode */ - write_mmr_descriptor_base(pnode, (n << UV_DESC_PSHIFT | m)); + write_mmr_descriptor_base(pnode, + (n << UVH_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT | m)); /* * Initializing all 8 (ITEMS_PER_DESC) descriptors for each * cpu even though we only use the first one; one descriptor can
[tip:sched/urgent] delayacct: Account blkio completion on the correct task
Commit-ID: c96f5471ce7d2aefd0dda560cc23f08ab00bc65d
Gitweb: https://git.kernel.org/tip/c96f5471ce7d2aefd0dda560cc23f08ab00bc65d
Author: Josh Snyder
AuthorDate: Mon, 18 Dec 2017 16:15:10 +
Committer: Ingo Molnar
CommitDate: Tue, 16 Jan 2018 03:29:36 +0100
delayacct: Account blkio completion on the correct task
Before commit:
e33a9bba85a8 ("sched/core: move IO scheduling accounting from
io_schedule_timeout() into scheduler")
delayacct_blkio_end() was called after context-switching into the task which
completed I/O.
This resulted in double counting: the task would account a delay both waiting
for I/O and for time spent in the runqueue.
With e33a9bba85a8, delayacct_blkio_end() is called by try_to_wake_up().
In ttwu, we have not yet context-switched. This is more correct, in that
the delay accounting ends when the I/O is complete.
But delayacct_blkio_end() relies on 'get_current()', and we have not yet
context-switched into the task whose I/O completed. This results in the
wrong task having its delay accounting statistics updated.
Instead of doing that, pass the task_struct being woken to
delayacct_blkio_end(),
so that it can update the statistics of the correct task.
Signed-off-by: Josh Snyder
Acked-by: Tejun Heo
Acked-by: Balbir Singh
Cc:
Cc: Brendan Gregg
Cc: Jens Axboe
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: linux-bl...@vger.kernel.org
Fixes: e33a9bba85a8 ("sched/core: move IO scheduling accounting from
io_schedule_timeout() into scheduler")
Link: http://lkml.kernel.org/r/1513613712-571-1-git-send-email-jo...@netflix.com
Signed-off-by: Ingo Molnar
---
include/linux/delayacct.h | 8
kernel/delayacct.c| 42 ++
kernel/sched/core.c | 6 +++---
3 files changed, 33 insertions(+), 23 deletions(-)
diff --git a/include/linux/delayacct.h b/include/linux/delayacct.h
index 4178d24..5e335b6 100644
--- a/include/linux/delayacct.h
+++ b/include/linux/delayacct.h
@@ -71,7 +71,7 @@ extern void delayacct_init(void);
extern void __delayacct_tsk_init(struct task_struct *);
extern void __delayacct_tsk_exit(struct task_struct *);
extern void __delayacct_blkio_start(void);
-extern void __delayacct_blkio_end(void);
+extern void __delayacct_blkio_end(struct task_struct *);
extern int __delayacct_add_tsk(struct taskstats *, struct task_struct *);
extern __u64 __delayacct_blkio_ticks(struct task_struct *);
extern void __delayacct_freepages_start(void);
@@ -122,10 +122,10 @@ static inline void delayacct_blkio_start(void)
__delayacct_blkio_start();
}
-static inline void delayacct_blkio_end(void)
+static inline void delayacct_blkio_end(struct task_struct *p)
{
if (current->delays)
- __delayacct_blkio_end();
+ __delayacct_blkio_end(p);
delayacct_clear_flag(DELAYACCT_PF_BLKIO);
}
@@ -169,7 +169,7 @@ static inline void delayacct_tsk_free(struct task_struct
*tsk)
{}
static inline void delayacct_blkio_start(void)
{}
-static inline void delayacct_blkio_end(void)
+static inline void delayacct_blkio_end(struct task_struct *p)
{}
static inline int delayacct_add_tsk(struct taskstats *d,
struct task_struct *tsk)
diff --git a/kernel/delayacct.c b/kernel/delayacct.c
index 4a1c334..e2764d7 100644
--- a/kernel/delayacct.c
+++ b/kernel/delayacct.c
@@ -51,16 +51,16 @@ void __delayacct_tsk_init(struct task_struct *tsk)
* Finish delay accounting for a statistic using its timestamps (@start),
* accumalator (@total) and @count
*/
-static void delayacct_end(u64 *start, u64 *total, u32 *count)
+static void delayacct_end(spinlock_t *lock, u64 *start, u64 *total, u32 *count)
{
s64 ns = ktime_get_ns() - *start;
unsigned long flags;
if (ns > 0) {
- spin_lock_irqsave(¤t->delays->lock, flags);
+ spin_lock_irqsave(lock, flags);
*total += ns;
(*count)++;
- spin_unlock_irqrestore(¤t->delays->lock, flags);
+ spin_unlock_irqrestore(lock, flags);
}
}
@@ -69,17 +69,25 @@ void __delayacct_blkio_start(void)
current->delays->blkio_start = ktime_get_ns();
}
-void __delayacct_blkio_end(void)
+/*
+ * We cannot rely on the `current` macro, as we haven't yet switched back to
+ * the process being woken.
+ */
+void __delayacct_blkio_end(struct task_struct *p)
{
- if (current->delays->flags & DELAYACCT_PF_SWAPIN)
- /* Swapin block I/O */
- delayacct_end(¤t->delays->blkio_start,
- ¤t->delays->swapin_delay,
- ¤t->delays->swapin_count);
- else/* Other block I/O */
- delayacct_end(¤t->delays->blkio_start,
- ¤t->delays->blkio_delay,
- ¤t->delays->blkio_count);
+ struct task_delay_info *delays = p->delays;
+ u64 *total;
+ u32 *count;
+
+
[tip:x86/platform] x86/platform/UV: Fix GAM MMR references in the UV x2apic code
Commit-ID: 09c3ae12b2bf6dc2837d89c1017bf151af610a1f
Gitweb: https://git.kernel.org/tip/09c3ae12b2bf6dc2837d89c1017bf151af610a1f
Author: Mike Travis
AuthorDate: Mon, 8 Jan 2018 13:40:03 -0600
Committer: Ingo Molnar
CommitDate: Tue, 16 Jan 2018 03:58:37 +0100
x86/platform/UV: Fix GAM MMR references in the UV x2apic code
Along with the fixes in UV4A (rev2) MMRs, the code to access those
MMRs also was modified by the fixes. UV3, UV4, and UV4A no longer
have compatible setups for Global Address Memory (GAM).
Correct the new mistakes.
Signed-off-by: Mike Travis
Acked-by: Andrew Banman
Cc: Andrew Morton
Cc: Dimitri Sivanich
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Russ Anderson
Cc: Thomas Gleixner
Link:
http://lkml.kernel.org/r/1515440405-20880-6-git-send-email-mike.tra...@hpe.com
Signed-off-by: Ingo Molnar
---
arch/x86/kernel/apic/x2apic_uv_x.c | 83 +-
1 file changed, 37 insertions(+), 46 deletions(-)
diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c
b/arch/x86/kernel/apic/x2apic_uv_x.c
index 2ddc140..46b675a 100644
--- a/arch/x86/kernel/apic/x2apic_uv_x.c
+++ b/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -794,70 +794,61 @@ static __init void map_mmr_high(int max_pnode)
pr_info("UV: MMR disabled\n");
}
-/*
- * This commonality works because both 0 & 1 versions of the MMIOH OVERLAY
- * and REDIRECT MMR regs are exactly the same on UV3.
- */
-struct mmioh_config {
- unsigned long overlay;
- unsigned long redirect;
- char *id;
-};
-
-static __initdata struct mmioh_config mmiohs[] = {
- {
- UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR,
- UV3H_RH_GAM_MMIOH_REDIRECT_CONFIG0_MMR,
- "MMIOH0"
- },
- {
- UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR,
- UV3H_RH_GAM_MMIOH_REDIRECT_CONFIG1_MMR,
- "MMIOH1"
- },
-};
-
-/* UV3 & UV4 have identical MMIOH overlay configs */
-static __init void map_mmioh_high_uv3(int index, int min_pnode, int max_pnode)
+/* UV3/4 have identical MMIOH overlay configs, UV4A is slightly different */
+static __init void map_mmioh_high_uv34(int index, int min_pnode, int max_pnode)
{
- union uvh_rh_gam_mmioh_overlay_config0_mmr_u overlay;
+ unsigned long overlay;
unsigned long mmr;
unsigned long base;
+ unsigned long nasid_mask;
unsigned long m_overlay;
int i, n, shift, m_io, max_io;
int nasid, lnasid, fi, li;
char *id;
- id = mmiohs[index].id;
- overlay.v = uv_read_local_mmr(mmiohs[index].overlay);
- m_overlay = mmiohs[index].overlay;
-
- pr_info("UV: %s overlay 0x%lx(@0x%lx) base:0x%x m_io:%d\n",
- id, overlay.v, m_overlay, overlay.s3.base, overlay.s3.m_io);
- if (!overlay.s3.enable) {
+ if (index == 0) {
+ id = "MMIOH0";
+ m_overlay = UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR;
+ overlay = uv_read_local_mmr(m_overlay);
+ base = overlay & UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_MASK;
+ mmr = UVH_RH_GAM_MMIOH_REDIRECT_CONFIG0_MMR;
+ m_io = (overlay &
UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_MASK)
+ >> UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT;
+ shift = UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT;
+ n = UVH_RH_GAM_MMIOH_REDIRECT_CONFIG0_MMR_DEPTH;
+ nasid_mask = UVH_RH_GAM_MMIOH_REDIRECT_CONFIG0_MMR_NASID_MASK;
+ } else {
+ id = "MMIOH1";
+ m_overlay = UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR;
+ overlay = uv_read_local_mmr(m_overlay);
+ base = overlay & UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_BASE_MASK;
+ mmr = UVH_RH_GAM_MMIOH_REDIRECT_CONFIG1_MMR;
+ m_io = (overlay &
UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_M_IO_MASK)
+ >> UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_M_IO_SHFT;
+ shift = UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_M_IO_SHFT;
+ n = UVH_RH_GAM_MMIOH_REDIRECT_CONFIG1_MMR_DEPTH;
+ nasid_mask = UVH_RH_GAM_MMIOH_REDIRECT_CONFIG1_MMR_NASID_MASK;
+ }
+ pr_info("UV: %s overlay 0x%lx base:0x%lx m_io:%d\n", id, overlay, base,
m_io);
+ if (!(overlay & UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_MASK)) {
pr_info("UV: %s disabled\n", id);
return;
}
- shift = UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_SHFT;
- base = (unsigned long)overlay.s3.base;
- m_io = overlay.s3.m_io;
- mmr = mmiohs[index].redirect;
- n = UV3H_RH_GAM_MMIOH_REDIRECT_CONFIG0_MMR_DEPTH;
/* Convert to NASID: */
min_pnode *= 2;
max_pnode *= 2;
max_io = lnasid = fi = li = -1;
for (i = 0; i < n; i++) {
- union uvh_rh_gam_mmioh_redirect_config0_mmr_u redirect;
unsigned long m_redirect = mmr + i
[tip:x86/platform] x86/platform/UV: Fix GAM MMR changes in UV4A
Commit-ID: ecce47e0bde6faa3256740280754bfd06a1a4efa
Gitweb: https://git.kernel.org/tip/ecce47e0bde6faa3256740280754bfd06a1a4efa
Author: Mike Travis
AuthorDate: Mon, 8 Jan 2018 13:40:02 -0600
Committer: Ingo Molnar
CommitDate: Tue, 16 Jan 2018 03:58:37 +0100
x86/platform/UV: Fix GAM MMR changes in UV4A
Intel processor changes necessitated UV4 HUB Global Address Memory
(GAM) fixes to accommodate support for those processors. This patch
deals with the updated address range change from 46 to 52 bits in UV4A.
Signed-off-by: Mike Travis
Acked-by: Andrew Banman
Cc: Andrew Morton
Cc: Dimitri Sivanich
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Russ Anderson
Cc: Thomas Gleixner
Link:
http://lkml.kernel.org/r/1515440405-20880-5-git-send-email-mike.tra...@hpe.com
Signed-off-by: Ingo Molnar
---
arch/x86/include/asm/uv/uv_mmrs.h | 86 ---
1 file changed, 80 insertions(+), 6 deletions(-)
diff --git a/arch/x86/include/asm/uv/uv_mmrs.h
b/arch/x86/include/asm/uv/uv_mmrs.h
index b3afccc..30db549 100644
--- a/arch/x86/include/asm/uv/uv_mmrs.h
+++ b/arch/x86/include/asm/uv/uv_mmrs.h
@@ -3743,7 +3743,6 @@ union uvh_rh_gam_gru_overlay_config_mmr_u {
/*is_uv4_hub*/ UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR)
-
#define UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_SHFT26
#define UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT46
#define UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_SHFT 63
@@ -3758,6 +3757,30 @@ union uvh_rh_gam_gru_overlay_config_mmr_u {
#define UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_MASK
0x000fc000UL
#define UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_MASK 0x8000UL
+#define UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT 52
+#define UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_MASK 0x000ffc00UL
+#define UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_MASK 0x03f0UL
+#define UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_MASK 0x8000UL
+
+#define UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT ( \
+ is_uv3_hub() ? UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT : \
+ is_uv4a_hub() ? UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT : \
+ /*is_uv4_hub*/ UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT)
+
+#define UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_MASK ( \
+ is_uv3_hub() ? UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_MASK : \
+ is_uv4a_hub() ? UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_MASK : \
+ /*is_uv4_hub*/ UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_MASK)
+
+#define UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_MASK ( \
+ is_uv3_hub() ? UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_MASK : \
+ is_uv4a_hub() ? UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_MASK : \
+ /*is_uv4_hub*/ UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_MASK)
+
+#define UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_MASK ( \
+ is_uv3_hub() ? UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_MASK : \
+ is_uv4a_hub() ? UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_MASK : \
+ /*is_uv4_hub*/ UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_MASK)
union uvh_rh_gam_mmioh_overlay_config0_mmr_u {
unsigned long v;
@@ -3777,6 +3800,14 @@ union uvh_rh_gam_mmioh_overlay_config0_mmr_u {
unsigned long rsvd_56_62:7;
unsigned long enable:1; /* RW */
} s4;
+ struct uv4ah_rh_gam_mmioh_overlay_config0_mmr_s {
+ unsigned long rsvd_0_25:26;
+ unsigned long base:26;/* RW */
+ unsigned long m_io:6; /* RW */
+ unsigned long n_io:4;
+ unsigned long undef_62:1; /* Undefined */
+ unsigned long enable:1; /* RW */
+ } s4a;
};
/* = */
@@ -3784,8 +3815,8 @@ union uvh_rh_gam_mmioh_overlay_config0_mmr_u {
/* = */
#define UV1H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR
uv_undefined("UV1H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR")
#define UV2H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR
uv_undefined("UV2H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR")
-#define UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 0x1604000UL
-#define UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 0x484000UL
+#define UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 0x1603000UL
+#define UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 0x483000UL
#define UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR ( \
is_uv1_hub() ? UV1H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR : \
is_uv2_hub() ? UV2H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR : \
@@ -3793,7 +3824,6 @@ union uvh_rh_gam_mmioh_overlay_config0_mmr_u {
/*is_uv4_hub*/ UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR)
-
#define UV3H
[tip:x86/platform] x86/platform/UV: Add references to access fixed UV4A HUB MMRs
Commit-ID: 8078d1951da228e20dc36f83306845a565f51345
Gitweb: https://git.kernel.org/tip/8078d1951da228e20dc36f83306845a565f51345
Author: Mike Travis
AuthorDate: Mon, 8 Jan 2018 13:40:01 -0600
Committer: Ingo Molnar
CommitDate: Tue, 16 Jan 2018 03:58:37 +0100
x86/platform/UV: Add references to access fixed UV4A HUB MMRs
Add references to enable access to fixed UV4A (rev2) HUB MMRs.
Signed-off-by: Mike Travis
Acked-by: Andrew Banman
Cc: Andrew Morton
Cc: Dimitri Sivanich
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Russ Anderson
Cc: Thomas Gleixner
Link:
http://lkml.kernel.org/r/1515440405-20880-4-git-send-email-mike.tra...@hpe.com
Signed-off-by: Ingo Molnar
---
arch/x86/include/asm/uv/uv_hub.h | 14 ++
arch/x86/include/asm/uv/uv_mmrs.h | 1 +
arch/x86/kernel/apic/x2apic_uv_x.c | 2 ++
3 files changed, 17 insertions(+)
diff --git a/arch/x86/include/asm/uv/uv_hub.h b/arch/x86/include/asm/uv/uv_hub.h
index 036e26d..44cf6d6 100644
--- a/arch/x86/include/asm/uv/uv_hub.h
+++ b/arch/x86/include/asm/uv/uv_hub.h
@@ -241,6 +241,7 @@ static inline int uv_hub_info_check(int version)
#define UV2_HUB_REVISION_BASE 3
#define UV3_HUB_REVISION_BASE 5
#define UV4_HUB_REVISION_BASE 7
+#define UV4A_HUB_REVISION_BASE 8 /* UV4 (fixed) rev 2 */
#ifdef UV1_HUB_IS_SUPPORTED
static inline int is_uv1_hub(void)
@@ -280,6 +281,19 @@ static inline int is_uv3_hub(void)
}
#endif
+/* First test "is UV4A", then "is UV4" */
+#ifdef UV4A_HUB_IS_SUPPORTED
+static inline int is_uv4a_hub(void)
+{
+ return (uv_hub_info->hub_revision >= UV4A_HUB_REVISION_BASE);
+}
+#else
+static inline int is_uv4a_hub(void)
+{
+ return 0;
+}
+#endif
+
#ifdef UV4_HUB_IS_SUPPORTED
static inline int is_uv4_hub(void)
{
diff --git a/arch/x86/include/asm/uv/uv_mmrs.h
b/arch/x86/include/asm/uv/uv_mmrs.h
index f113e27..b3afccc 100644
--- a/arch/x86/include/asm/uv/uv_mmrs.h
+++ b/arch/x86/include/asm/uv/uv_mmrs.h
@@ -99,6 +99,7 @@
#define UV2_HUB_IS_SUPPORTED 1
#define UV3_HUB_IS_SUPPORTED 1
#define UV4_HUB_IS_SUPPORTED 1
+#define UV4A_HUB_IS_SUPPORTED 1
/* Error function to catch undefined references */
extern unsigned long uv_undefined(char *str);
diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c
b/arch/x86/kernel/apic/x2apic_uv_x.c
index ebb7d26..2ddc140 100644
--- a/arch/x86/kernel/apic/x2apic_uv_x.c
+++ b/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -137,6 +137,8 @@ static int __init early_get_pnodeid(void)
case UV3_HUB_PART_NUMBER_X:
uv_min_hub_revision_id += UV3_HUB_REVISION_BASE;
break;
+
+ /* Update: UV4A has only a modified revision to indicate HUB fixes */
case UV4_HUB_PART_NUMBER:
uv_min_hub_revision_id += UV4_HUB_REVISION_BASE - 1;
uv_cpuid.gnode_shift = 2; /* min partition is 4 sockets */
[tip:x86/platform] x86/platform/UV: Fix UV4A support on new Intel Processors
Commit-ID: 62807106c3219d2d6ddbfc778a5ee7e6ba38e58f
Gitweb: https://git.kernel.org/tip/62807106c3219d2d6ddbfc778a5ee7e6ba38e58f
Author: Mike Travis
AuthorDate: Mon, 8 Jan 2018 13:40:00 -0600
Committer: Ingo Molnar
CommitDate: Tue, 16 Jan 2018 03:58:37 +0100
x86/platform/UV: Fix UV4A support on new Intel Processors
Upcoming Intel CascadeLake and IceLake processors have some architecture
changes that required fixes in the UV4 HUB bringing that chip to
revision 2. The nomenclature for that new chip is "UV4A".
This patch fixes the references for the expanded MMR definitions in the
previous (automated) patch.
Signed-off-by: Mike Travis
Acked-by: Andrew Banman
Cc: Andrew Morton
Cc: Dimitri Sivanich
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Russ Anderson
Cc: Thomas Gleixner
Link:
http://lkml.kernel.org/r/1515440405-20880-3-git-send-email-mike.tra...@hpe.com
Signed-off-by: Ingo Molnar
---
arch/x86/kernel/apic/x2apic_uv_x.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c
b/arch/x86/kernel/apic/x2apic_uv_x.c
index 6de35fc..ebb7d26 100644
--- a/arch/x86/kernel/apic/x2apic_uv_x.c
+++ b/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -768,6 +768,7 @@ static __init void map_gru_high(int max_pnode)
return;
}
+ /* Only UV3 has distributed GRU mode */
if (is_uv3_hub() && gru.s3.mode) {
map_gru_distributed(gru.v);
return;
@@ -817,17 +818,20 @@ static __initdata struct mmioh_config mmiohs[] = {
/* UV3 & UV4 have identical MMIOH overlay configs */
static __init void map_mmioh_high_uv3(int index, int min_pnode, int max_pnode)
{
- union uv3h_rh_gam_mmioh_overlay_config0_mmr_u overlay;
+ union uvh_rh_gam_mmioh_overlay_config0_mmr_u overlay;
unsigned long mmr;
unsigned long base;
+ unsigned long m_overlay;
int i, n, shift, m_io, max_io;
int nasid, lnasid, fi, li;
char *id;
id = mmiohs[index].id;
overlay.v = uv_read_local_mmr(mmiohs[index].overlay);
+ m_overlay = mmiohs[index].overlay;
- pr_info("UV: %s overlay 0x%lx base:0x%x m_io:%d\n", id, overlay.v,
overlay.s3.base, overlay.s3.m_io);
+ pr_info("UV: %s overlay 0x%lx(@0x%lx) base:0x%x m_io:%d\n",
+ id, overlay.v, m_overlay, overlay.s3.base, overlay.s3.m_io);
if (!overlay.s3.enable) {
pr_info("UV: %s disabled\n", id);
return;
@@ -844,10 +848,14 @@ static __init void map_mmioh_high_uv3(int index, int
min_pnode, int max_pnode)
max_io = lnasid = fi = li = -1;
for (i = 0; i < n; i++) {
- union uv3h_rh_gam_mmioh_redirect_config0_mmr_u redirect;
+ union uvh_rh_gam_mmioh_redirect_config0_mmr_u redirect;
+ unsigned long m_redirect = mmr + i * 8;
redirect.v = uv_read_local_mmr(mmr + i * 8);
nasid = redirect.s3.nasid;
+ printk_once(KERN_INFO
+ "UV: %s redirect 0x%lx(@0x%lx) 0x%04x\n",
+ id, redirect.v, m_redirect, nasid);
/* Invalid NASID: */
if (nasid < min_pnode || max_pnode < nasid)
nasid = -1;
[tip:x86/platform] x86/platform/UV: Update uv_mmrs.h to prepare for UV4A fixes
Commit-ID: 673aa20c55a138621d1340d343cd6b07c1cb4e92
Gitweb: https://git.kernel.org/tip/673aa20c55a138621d1340d343cd6b07c1cb4e92
Author: Mike Travis
AuthorDate: Mon, 8 Jan 2018 13:39:59 -0600
Committer: Ingo Molnar
CommitDate: Tue, 16 Jan 2018 03:58:36 +0100
x86/platform/UV: Update uv_mmrs.h to prepare for UV4A fixes
Regenerate uv_mmrs.h file to accommodate fixes to UV4A MMRs.
Signed-off-by: Mike Travis
Acked-by: Andrew Banman
Cc: Andrew Morton
Cc: Dimitri Sivanich
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Russ Anderson
Cc: Thomas Gleixner
Link:
http://lkml.kernel.org/r/1515440405-20880-2-git-send-email-mike.tra...@hpe.com
Signed-off-by: Ingo Molnar
---
arch/x86/include/asm/uv/uv_mmrs.h | 615 +-
1 file changed, 533 insertions(+), 82 deletions(-)
diff --git a/arch/x86/include/asm/uv/uv_mmrs.h
b/arch/x86/include/asm/uv/uv_mmrs.h
index 548d684..f113e27 100644
--- a/arch/x86/include/asm/uv/uv_mmrs.h
+++ b/arch/x86/include/asm/uv/uv_mmrs.h
@@ -3031,6 +3031,41 @@ union uvh_node_present_table_u {
#define UVH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_MASK
0x001fUL
#define UVH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_MASK
0x8000UL
+#define UV1H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_SHFT 24
+#define UV1H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_SHFT 48
+#define UV1H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_SHFT 63
+#define UV1H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_MASK
0xff00UL
+#define UV1H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_MASK
0x001fUL
+#define UV1H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_MASK
0x8000UL
+
+#define UVXH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_SHFT 24
+#define UVXH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_SHFT 48
+#define UVXH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_SHFT 63
+#define UVXH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_MASK
0xff00UL
+#define UVXH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_MASK
0x001fUL
+#define UVXH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_MASK
0x8000UL
+
+#define UV2H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_SHFT 24
+#define UV2H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_SHFT 48
+#define UV2H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_SHFT 63
+#define UV2H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_MASK
0xff00UL
+#define UV2H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_MASK
0x001fUL
+#define UV2H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_MASK
0x8000UL
+
+#define UV3H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_SHFT 24
+#define UV3H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_SHFT 48
+#define UV3H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_SHFT 63
+#define UV3H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_MASK
0xff00UL
+#define UV3H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_MASK
0x001fUL
+#define UV3H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_MASK
0x8000UL
+
+#define UV4H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_SHFT 24
+#define UV4H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_SHFT 48
+#define UV4H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_SHFT 63
+#define UV4H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_MASK
0xff00UL
+#define UV4H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_MASK
0x001fUL
+#define UV4H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_MASK
0x8000UL
+
union uvh_rh_gam_alias210_overlay_config_0_mmr_u {
unsigned long v;
@@ -3042,6 +3077,46 @@ union uvh_rh_gam_alias210_overlay_config_0_mmr_u {
unsigned long rsvd_53_62:10;
unsigned long enable:1; /* RW */
} s;
+ struct uv1h_rh_gam_alias210_overlay_config_0_mmr_s {
+ unsigned long rsvd_0_23:24;
+ unsigned long base:8; /* RW */
+ unsigned long rsvd_32_47:16;
+ unsigned long m_alias:5; /* RW */
+ unsigned long rsvd_53_62:10;
+ unsigned long enable:1; /* RW */
+ } s1;
+ struct uvxh_rh_gam_alias210_overlay_config_0_mmr_s {
+ unsigned long rsvd_0_23:24;
+ unsigned long base:8; /* RW */
+ unsigned long rsvd_32_47:16;
+ unsigned long m_alias:5; /* RW */
+ unsigned long rsvd_53_62:10;
+ unsigned long enable:1; /* RW */
+ } sx;
+ struct uv2h_rh_gam_alias210_overlay_config_0_mmr_s {
+ unsigned long rsvd_0_23:24;
+ unsigned long base:8; /* RW */
+ unsigned long rsvd_32_47:16;
+ unsigned long m_alias:5; /* RW */
+ unsigned long rsvd_5
[tip:timers/core] hrtimer: Prepare handling of hard and softirq based hrtimers
Commit-ID: c458b1d102036eaa2c70e03000c959bd491c2037
Gitweb: https://git.kernel.org/tip/c458b1d102036eaa2c70e03000c959bd491c2037
Author: Anna-Maria Gleixner
AuthorDate: Thu, 21 Dec 2017 11:41:56 +0100
Committer: Ingo Molnar
CommitDate: Tue, 16 Jan 2018 03:01:20 +0100
hrtimer: Prepare handling of hard and softirq based hrtimers
The softirq based hrtimer can utilize most of the existing hrtimers
functions, but need to operate on a different data set.
Add an 'active_mask' parameter to various functions so the hard and soft bases
can be selected. Fixup the existing callers and hand in the ACTIVE_HARD
mask.
Signed-off-by: Anna-Maria Gleixner
Cc: Christoph Hellwig
Cc: John Stultz
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: keesc...@chromium.org
Link: http://lkml.kernel.org/r/20171221104205.7269-28-anna-ma...@linutronix.de
Signed-off-by: Ingo Molnar
---
kernel/time/hrtimer.c | 38 +-
1 file changed, 29 insertions(+), 9 deletions(-)
diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
index e2353f5..ba4674e 100644
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -60,6 +60,15 @@
#include "tick-internal.h"
/*
+ * Masks for selecting the soft and hard context timers from
+ * cpu_base->active
+ */
+#define MASK_SHIFT (HRTIMER_BASE_MONOTONIC_SOFT)
+#define HRTIMER_ACTIVE_HARD((1U << MASK_SHIFT) - 1)
+#define HRTIMER_ACTIVE_SOFT(HRTIMER_ACTIVE_HARD << MASK_SHIFT)
+#define HRTIMER_ACTIVE_ALL (HRTIMER_ACTIVE_SOFT | HRTIMER_ACTIVE_HARD)
+
+/*
* The timer bases:
*
* There are more clockids than hrtimer bases. Thus, we index
@@ -507,13 +516,24 @@ static ktime_t __hrtimer_next_event_base(struct
hrtimer_cpu_base *cpu_base,
return expires_next;
}
-static ktime_t __hrtimer_get_next_event(struct hrtimer_cpu_base *cpu_base)
+/*
+ * Recomputes cpu_base::*next_timer and returns the earliest expires_next but
+ * does not set cpu_base::*expires_next, that is done by hrtimer_reprogram.
+ *
+ * @active_mask must be one of:
+ * - HRTIMER_ACTIVE,
+ * - HRTIMER_ACTIVE_SOFT, or
+ * - HRTIMER_ACTIVE_HARD.
+ */
+static ktime_t __hrtimer_get_next_event(struct hrtimer_cpu_base *cpu_base,
+ unsigned int active_mask)
{
- unsigned int active = cpu_base->active_bases;
+ unsigned int active;
ktime_t expires_next = KTIME_MAX;
cpu_base->next_timer = NULL;
+ active = cpu_base->active_bases & active_mask;
expires_next = __hrtimer_next_event_base(cpu_base, active,
expires_next);
return expires_next;
@@ -553,7 +573,7 @@ hrtimer_force_reprogram(struct hrtimer_cpu_base *cpu_base,
int skip_equal)
{
ktime_t expires_next;
- expires_next = __hrtimer_get_next_event(cpu_base);
+ expires_next = __hrtimer_get_next_event(cpu_base, HRTIMER_ACTIVE_HARD);
if (skip_equal && expires_next == cpu_base->expires_next)
return;
@@ -1074,7 +1094,7 @@ u64 hrtimer_get_next_event(void)
raw_spin_lock_irqsave(&cpu_base->lock, flags);
if (!__hrtimer_hres_active(cpu_base))
- expires = __hrtimer_get_next_event(cpu_base);
+ expires = __hrtimer_get_next_event(cpu_base,
HRTIMER_ACTIVE_HARD);
raw_spin_unlock_irqrestore(&cpu_base->lock, flags);
@@ -1248,10 +1268,10 @@ static void __run_hrtimer(struct hrtimer_cpu_base
*cpu_base,
}
static void __hrtimer_run_queues(struct hrtimer_cpu_base *cpu_base, ktime_t
now,
-unsigned long flags)
+unsigned long flags, unsigned int active_mask)
{
struct hrtimer_clock_base *base;
- unsigned int active = cpu_base->active_bases;
+ unsigned int active = cpu_base->active_bases & active_mask;
for_each_active_base(base, cpu_base, active) {
struct timerqueue_node *node;
@@ -1314,10 +1334,10 @@ retry:
*/
cpu_base->expires_next = KTIME_MAX;
- __hrtimer_run_queues(cpu_base, now, flags);
+ __hrtimer_run_queues(cpu_base, now, flags, HRTIMER_ACTIVE_HARD);
/* Reevaluate the clock bases for the next expiry */
- expires_next = __hrtimer_get_next_event(cpu_base);
+ expires_next = __hrtimer_get_next_event(cpu_base, HRTIMER_ACTIVE_HARD);
/*
* Store the new expiry value so the migration code can verify
* against it.
@@ -1421,7 +1441,7 @@ void hrtimer_run_queues(void)
raw_spin_lock_irqsave(&cpu_base->lock, flags);
now = hrtimer_update_base(cpu_base);
- __hrtimer_run_queues(cpu_base, now, flags);
+ __hrtimer_run_queues(cpu_base, now, flags, HRTIMER_ACTIVE_HARD);
raw_spin_unlock_irqrestore(&cpu_base->lock, flags);
}
[tip:timers/core] hrtimer: Add clock bases and hrtimer mode for softirq context
Commit-ID: 98ecadd4305d8677ba77162152485798d47dcc85
Gitweb: https://git.kernel.org/tip/98ecadd4305d8677ba77162152485798d47dcc85
Author: Anna-Maria Gleixner
AuthorDate: Thu, 21 Dec 2017 11:41:55 +0100
Committer: Ingo Molnar
CommitDate: Tue, 16 Jan 2018 03:00:50 +0100
hrtimer: Add clock bases and hrtimer mode for softirq context
Currently hrtimer callback functions are always executed in hard interrupt
context. Users of hrtimers, which need their timer function to be executed
in soft interrupt context, make use of tasklets to get the proper context.
Add additional hrtimer clock bases for timers which must expire in softirq
context, so the detour via the tasklet can be avoided. This is also
required for RT, where the majority of hrtimer is moved into softirq
hrtimer context.
The selection of the expiry mode happens via a mode bit. Introduce
HRTIMER_MODE_SOFT and the matching combinations with the ABS/REL/PINNED
bits and update the decoding of hrtimer_mode in tracepoints.
Signed-off-by: Anna-Maria Gleixner
Cc: Christoph Hellwig
Cc: John Stultz
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: keesc...@chromium.org
Link: http://lkml.kernel.org/r/20171221104205.7269-27-anna-ma...@linutronix.de
Signed-off-by: Ingo Molnar
---
include/linux/hrtimer.h | 14 ++
include/trace/events/timer.h | 6 +-
kernel/time/hrtimer.c| 20
3 files changed, 39 insertions(+), 1 deletion(-)
diff --git a/include/linux/hrtimer.h b/include/linux/hrtimer.h
index 98ed357..26ae8a8 100644
--- a/include/linux/hrtimer.h
+++ b/include/linux/hrtimer.h
@@ -33,14 +33,24 @@ struct hrtimer_cpu_base;
* HRTIMER_MODE_REL- Time value is relative to now
* HRTIMER_MODE_PINNED - Timer is bound to CPU (is only considered
* when starting the timer)
+ * HRTIMER_MODE_SOFT - Timer callback function will be executed in
+ * soft irq context
*/
enum hrtimer_mode {
HRTIMER_MODE_ABS= 0x00,
HRTIMER_MODE_REL= 0x01,
HRTIMER_MODE_PINNED = 0x02,
+ HRTIMER_MODE_SOFT = 0x04,
HRTIMER_MODE_ABS_PINNED = HRTIMER_MODE_ABS | HRTIMER_MODE_PINNED,
HRTIMER_MODE_REL_PINNED = HRTIMER_MODE_REL | HRTIMER_MODE_PINNED,
+
+ HRTIMER_MODE_ABS_SOFT = HRTIMER_MODE_ABS | HRTIMER_MODE_SOFT,
+ HRTIMER_MODE_REL_SOFT = HRTIMER_MODE_REL | HRTIMER_MODE_SOFT,
+
+ HRTIMER_MODE_ABS_PINNED_SOFT = HRTIMER_MODE_ABS_PINNED |
HRTIMER_MODE_SOFT,
+ HRTIMER_MODE_REL_PINNED_SOFT = HRTIMER_MODE_REL_PINNED |
HRTIMER_MODE_SOFT,
+
};
/*
@@ -151,6 +161,10 @@ enum hrtimer_base_type {
HRTIMER_BASE_REALTIME,
HRTIMER_BASE_BOOTTIME,
HRTIMER_BASE_TAI,
+ HRTIMER_BASE_MONOTONIC_SOFT,
+ HRTIMER_BASE_REALTIME_SOFT,
+ HRTIMER_BASE_BOOTTIME_SOFT,
+ HRTIMER_BASE_TAI_SOFT,
HRTIMER_MAX_CLOCK_BASES,
};
diff --git a/include/trace/events/timer.h b/include/trace/events/timer.h
index 744b431..a57e4ee 100644
--- a/include/trace/events/timer.h
+++ b/include/trace/events/timer.h
@@ -148,7 +148,11 @@ DEFINE_EVENT(timer_class, timer_cancel,
{ HRTIMER_MODE_ABS, "ABS" }, \
{ HRTIMER_MODE_REL, "REL" }, \
{ HRTIMER_MODE_ABS_PINNED, "ABS|PINNED"}, \
- { HRTIMER_MODE_REL_PINNED, "REL|PINNED"})
+ { HRTIMER_MODE_REL_PINNED, "REL|PINNED"}, \
+ { HRTIMER_MODE_ABS_SOFT,"ABS|SOFT" }, \
+ { HRTIMER_MODE_REL_SOFT,"REL|SOFT" }, \
+ { HRTIMER_MODE_ABS_PINNED_SOFT, "ABS|PINNED|SOFT" },\
+ { HRTIMER_MODE_REL_PINNED_SOFT, "REL|PINNED|SOFT" })
/**
* hrtimer_init - called when the hrtimer is initialized
diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
index 31ccd86..e2353f5 100644
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -92,6 +92,26 @@ DEFINE_PER_CPU(struct hrtimer_cpu_base, hrtimer_bases) =
.clockid = CLOCK_TAI,
.get_time = &ktime_get_clocktai,
},
+ {
+ .index = HRTIMER_BASE_MONOTONIC_SOFT,
+ .clockid = CLOCK_MONOTONIC,
+ .get_time = &ktime_get,
+ },
+ {
+ .index = HRTIMER_BASE_REALTIME_SOFT,
+ .clockid = CLOCK_REALTIME,
+ .get_time = &ktime_get_real,
+ },
+ {
+ .index = HRTIMER_BASE_BOOTTIME_SOFT,
+ .clockid = CLOCK_BOOTTIME,
+ .get_time = &ktime_get_boottime,
+ },
+ {
+ .index = HRTIMER_BASE_TAI_SOFT,
+ .clockid = CLOCK_TA
[tip:timers/core] hrtimer: Use irqsave/irqrestore around __run_hrtimer()
Commit-ID: dd934aa8ad1fbaab3d916125c7fe42fff75aa7ff
Gitweb: https://git.kernel.org/tip/dd934aa8ad1fbaab3d916125c7fe42fff75aa7ff
Author: Anna-Maria Gleixner
AuthorDate: Thu, 21 Dec 2017 11:41:54 +0100
Committer: Ingo Molnar
CommitDate: Tue, 16 Jan 2018 03:00:47 +0100
hrtimer: Use irqsave/irqrestore around __run_hrtimer()
__run_hrtimer() is called with the hrtimer_cpu_base.lock held and
interrupts disabled. Before invoking the timer callback the base lock is
dropped, but interrupts stay disabled.
The upcoming support for softirq based hrtimers requires that interrupts
are enabled before the timer callback is invoked.
To avoid code duplication, take hrtimer_cpu_base.lock with
raw_spin_lock_irqsave(flags) at the call site and hand in the flags as
a parameter. So raw_spin_unlock_irqrestore() before the callback invocation
will either keep interrupts disabled in interrupt context or restore to
interrupt enabled state when called from softirq context.
Suggested-by: Peter Zijlstra
Signed-off-by: Anna-Maria Gleixner
Cc: Christoph Hellwig
Cc: John Stultz
Cc: Linus Torvalds
Cc: Thomas Gleixner
Cc: keesc...@chromium.org
Link: http://lkml.kernel.org/r/20171221104205.7269-26-anna-ma...@linutronix.de
Signed-off-by: Ingo Molnar
---
kernel/time/hrtimer.c | 31 ++-
1 file changed, 18 insertions(+), 13 deletions(-)
diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
index 5d9b81d..31ccd86 100644
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -1159,7 +1159,8 @@ EXPORT_SYMBOL_GPL(hrtimer_active);
static void __run_hrtimer(struct hrtimer_cpu_base *cpu_base,
struct hrtimer_clock_base *base,
- struct hrtimer *timer, ktime_t *now)
+ struct hrtimer *timer, ktime_t *now,
+ unsigned long flags)
{
enum hrtimer_restart (*fn)(struct hrtimer *);
int restart;
@@ -1194,11 +1195,11 @@ static void __run_hrtimer(struct hrtimer_cpu_base
*cpu_base,
* protected against migration to a different CPU even if the lock
* is dropped.
*/
- raw_spin_unlock(&cpu_base->lock);
+ raw_spin_unlock_irqrestore(&cpu_base->lock, flags);
trace_hrtimer_expire_entry(timer, now);
restart = fn(timer);
trace_hrtimer_expire_exit(timer);
- raw_spin_lock(&cpu_base->lock);
+ raw_spin_lock_irq(&cpu_base->lock);
/*
* Note: We clear the running state after enqueue_hrtimer and
@@ -1226,7 +1227,8 @@ static void __run_hrtimer(struct hrtimer_cpu_base
*cpu_base,
base->running = NULL;
}
-static void __hrtimer_run_queues(struct hrtimer_cpu_base *cpu_base, ktime_t
now)
+static void __hrtimer_run_queues(struct hrtimer_cpu_base *cpu_base, ktime_t
now,
+unsigned long flags)
{
struct hrtimer_clock_base *base;
unsigned int active = cpu_base->active_bases;
@@ -1257,7 +1259,7 @@ static void __hrtimer_run_queues(struct hrtimer_cpu_base
*cpu_base, ktime_t now)
if (basenow < hrtimer_get_softexpires_tv64(timer))
break;
- __run_hrtimer(cpu_base, base, timer, &basenow);
+ __run_hrtimer(cpu_base, base, timer, &basenow, flags);
}
}
}
@@ -1272,13 +1274,14 @@ void hrtimer_interrupt(struct clock_event_device *dev)
{
struct hrtimer_cpu_base *cpu_base = this_cpu_ptr(&hrtimer_bases);
ktime_t expires_next, now, entry_time, delta;
+ unsigned long flags;
int retries = 0;
BUG_ON(!cpu_base->hres_active);
cpu_base->nr_events++;
dev->next_event = KTIME_MAX;
- raw_spin_lock(&cpu_base->lock);
+ raw_spin_lock_irqsave(&cpu_base->lock, flags);
entry_time = now = hrtimer_update_base(cpu_base);
retry:
cpu_base->in_hrtirq = 1;
@@ -1291,7 +1294,7 @@ retry:
*/
cpu_base->expires_next = KTIME_MAX;
- __hrtimer_run_queues(cpu_base, now);
+ __hrtimer_run_queues(cpu_base, now, flags);
/* Reevaluate the clock bases for the next expiry */
expires_next = __hrtimer_get_next_event(cpu_base);
@@ -1301,7 +1304,7 @@ retry:
*/
cpu_base->expires_next = expires_next;
cpu_base->in_hrtirq = 0;
- raw_spin_unlock(&cpu_base->lock);
+ raw_spin_unlock_irqrestore(&cpu_base->lock, flags);
/* Reprogramming necessary ? */
if (!tick_program_event(expires_next, 0)) {
@@ -1322,7 +1325,7 @@ retry:
* Acquire base lock for updating the offsets and retrieving
* the current time.
*/
- raw_spin_lock(&cpu_base->lock);
+ raw_spin_lock_irqsave(&cpu_base->lock, flags);
now = hrtimer_update_base(cpu_base);
cpu_base->nr_retries++;
if (++retries < 3)
@@ -1335,7 +1338,8 @@ retry:
*/
cpu_base->nr_hangs++;
cpu_base->hang_det
