- Linux-stable-mirror - lists.linaro.org

Patch "sched: act_csum: don't mangle TCP and UDP GSO packets" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled sched: act_csum: don't mangle TCP and UDP GSO packets to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: sched-act_csum-don-t-mangle-tcp-and-udp-gso-packets.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 10:11:52 CET 2018 From: Davide Caratti <dcaratti(a)redhat.com> Date: Thu, 23 Mar 2017 10:39:40 +0100 Subject: sched: act_csum: don't mangle TCP and UDP GSO packets From: Davide Caratti <dcaratti(a)redhat.com> [ Upstream commit add641e7dee31b36aee83412c29e39dd1f5e0c9c ] after act_csum computes the checksum on skbs carrying GSO TCP/UDP packets, subsequent segmentation fails because skb_needs_check(skb, true) returns true. Because of that, skb_warn_bad_offload() is invoked and the following message is displayed: WARNING: CPU: 3 PID: 28 at net/core/dev.c:2553 skb_warn_bad_offload+0xf0/0xfd <...> [<ffffffff8171f486>] skb_warn_bad_offload+0xf0/0xfd [<ffffffff8161304c>] __skb_gso_segment+0xec/0x110 [<ffffffff8161340d>] validate_xmit_skb+0x12d/0x2b0 [<ffffffff816135d2>] validate_xmit_skb_list+0x42/0x70 [<ffffffff8163c560>] sch_direct_xmit+0xd0/0x1b0 [<ffffffff8163c760>] __qdisc_run+0x120/0x270 [<ffffffff81613b3d>] __dev_queue_xmit+0x23d/0x690 [<ffffffff81613fa0>] dev_queue_xmit+0x10/0x20 Since GSO is able to compute checksum on individual segments of such skbs, we can simply skip mangling the packet. Signed-off-by: Davide Caratti <dcaratti(a)redhat.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/sched/act_csum.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) --- a/net/sched/act_csum.c +++ b/net/sched/act_csum.c @@ -176,6 +176,9 @@ static int tcf_csum_ipv4_tcp(struct sk_b struct tcphdr *tcph; const struct iphdr *iph; + if (skb_is_gso(skb) && skb_shinfo(skb)->gso_type & SKB_GSO_TCPV4) + return 1; + tcph = tcf_csum_skb_nextlayer(skb, ihl, ipl, sizeof(*tcph)); if (tcph == NULL) return 0; @@ -197,6 +200,9 @@ static int tcf_csum_ipv6_tcp(struct sk_b struct tcphdr *tcph; const struct ipv6hdr *ip6h; + if (skb_is_gso(skb) && skb_shinfo(skb)->gso_type & SKB_GSO_TCPV6) + return 1; + tcph = tcf_csum_skb_nextlayer(skb, ihl, ipl, sizeof(*tcph)); if (tcph == NULL) return 0; @@ -220,6 +226,9 @@ static int tcf_csum_ipv4_udp(struct sk_b const struct iphdr *iph; u16 ul; + if (skb_is_gso(skb) && skb_shinfo(skb)->gso_type & SKB_GSO_UDP) + return 1; + /* * Support both UDP and UDPLITE checksum algorithms, Don't use * udph->len to get the real length without any protocol check, @@ -273,6 +282,9 @@ static int tcf_csum_ipv6_udp(struct sk_b const struct ipv6hdr *ip6h; u16 ul; + if (skb_is_gso(skb) && skb_shinfo(skb)->gso_type & SKB_GSO_UDP) + return 1; + /* * Support both UDP and UDPLITE checksum algorithms, Don't use * udph->len to get the real length without any protocol check, Patches currently in stable-queue which might be from dcaratti(a)redhat.com are queue-3.18/sched-act_csum-don-t-mangle-tcp-and-udp-gso-packets.patch

7 years, 3 months

1
0
0 0

Patch "regulator: isl9305: fix array size" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled regulator: isl9305: fix array size to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: regulator-isl9305-fix-array-size.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 10:11:52 CET 2018 From: "Vincent Stehlé" <vincent.stehle(a)laposte.net> Date: Sun, 9 Apr 2017 22:05:05 +0200 Subject: regulator: isl9305: fix array size From: "Vincent Stehlé" <vincent.stehle(a)laposte.net> [ Upstream commit 0c08aaf873174c95e674cf21ffcd041c589d2e5b ] ISL9305_MAX_REGULATOR is the last index used to access the init_data[] array, so we need to add one to this last index to obtain the necessary array size. This fixes the following smatch error: drivers/regulator/isl9305.c:160 isl9305_i2c_probe() error: buffer overflow 'pdata->init_data' 3 <= 3 Fixes: dec38b5ce6a9edb4 ("regulator: isl9305: Add Intersil ISL9305/H driver") Signed-off-by: Vincent StehlÃ© <vincent.stehle(a)laposte.net> Cc: Mark Brown <broonie(a)kernel.org> Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- include/linux/platform_data/isl9305.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/include/linux/platform_data/isl9305.h +++ b/include/linux/platform_data/isl9305.h @@ -24,7 +24,7 @@ struct regulator_init_data; struct isl9305_pdata { - struct regulator_init_data *init_data[ISL9305_MAX_REGULATOR]; + struct regulator_init_data *init_data[ISL9305_MAX_REGULATOR + 1]; }; #endif Patches currently in stable-queue which might be from vincent.stehle(a)laposte.net are queue-3.18/regulator-isl9305-fix-array-size.patch

7 years, 3 months

1
0
0 0

Patch "reiserfs: Make cancel_old_flush() reliable" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled reiserfs: Make cancel_old_flush() reliable to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: reiserfs-make-cancel_old_flush-reliable.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 10:11:52 CET 2018 From: Jan Kara <jack(a)suse.cz> Date: Wed, 5 Apr 2017 14:09:48 +0200 Subject: reiserfs: Make cancel_old_flush() reliable From: Jan Kara <jack(a)suse.cz> [ Upstream commit 71b0576bdb862e964a82c73327cdd1a249c53e67 ] Currently canceling of delayed work that flushes old data using cancel_old_flush() does not prevent work from being requeued. Thus in theory new work can be queued after cancel_old_flush() from reiserfs_freeze() has run. This will become larger problem once flush_old_commits() can requeue the work itself. Fix the problem by recording in sbi->work_queue that flushing work is canceled and should not be requeued. Signed-off-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/reiserfs/journal.c | 2 +- fs/reiserfs/reiserfs.h | 1 + fs/reiserfs/super.c | 21 +++++++++++++++------ 3 files changed, 17 insertions(+), 7 deletions(-) --- a/fs/reiserfs/journal.c +++ b/fs/reiserfs/journal.c @@ -1961,7 +1961,7 @@ static int do_journal_release(struct rei * will be requeued because superblock is being shutdown and doesn't * have MS_ACTIVE set. */ - cancel_delayed_work_sync(&REISERFS_SB(sb)->old_work); + reiserfs_cancel_old_flush(sb); /* wait for all commits to finish */ cancel_delayed_work_sync(&SB_JOURNAL(sb)->j_work); --- a/fs/reiserfs/reiserfs.h +++ b/fs/reiserfs/reiserfs.h @@ -2946,6 +2946,7 @@ int reiserfs_allocate_list_bitmaps(struc struct reiserfs_list_bitmap *, unsigned int); void reiserfs_schedule_old_flush(struct super_block *s); +void reiserfs_cancel_old_flush(struct super_block *s); void add_save_link(struct reiserfs_transaction_handle *th, struct inode *inode, int truncate); int remove_save_link(struct inode *inode, int truncate); --- a/fs/reiserfs/super.c +++ b/fs/reiserfs/super.c @@ -89,7 +89,9 @@ static void flush_old_commits(struct wor s = sbi->s_journal->j_work_sb; spin_lock(&sbi->old_work_lock); - sbi->work_queued = 0; + /* Avoid clobbering the cancel state... */ + if (sbi->work_queued == 1) + sbi->work_queued = 0; spin_unlock(&sbi->old_work_lock); reiserfs_sync_fs(s, 1); @@ -116,21 +118,22 @@ void reiserfs_schedule_old_flush(struct spin_unlock(&sbi->old_work_lock); } -static void cancel_old_flush(struct super_block *s) +void reiserfs_cancel_old_flush(struct super_block *s) { struct reiserfs_sb_info *sbi = REISERFS_SB(s); - cancel_delayed_work_sync(&REISERFS_SB(s)->old_work); spin_lock(&sbi->old_work_lock); - sbi->work_queued = 0; + /* Make sure no new flushes will be queued */ + sbi->work_queued = 2; spin_unlock(&sbi->old_work_lock); + cancel_delayed_work_sync(&REISERFS_SB(s)->old_work); } static int reiserfs_freeze(struct super_block *s) { struct reiserfs_transaction_handle th; - cancel_old_flush(s); + reiserfs_cancel_old_flush(s); reiserfs_write_lock(s); if (!(s->s_flags & MS_RDONLY)) { @@ -151,7 +154,13 @@ static int reiserfs_freeze(struct super_ static int reiserfs_unfreeze(struct super_block *s) { + struct reiserfs_sb_info *sbi = REISERFS_SB(s); + reiserfs_allow_writes(s); + spin_lock(&sbi->old_work_lock); + /* Allow old_work to run again */ + sbi->work_queued = 0; + spin_unlock(&sbi->old_work_lock); return 0; } @@ -2164,7 +2173,7 @@ error_unlocked: if (sbi->commit_wq) destroy_workqueue(sbi->commit_wq); - cancel_delayed_work_sync(&REISERFS_SB(s)->old_work); + reiserfs_cancel_old_flush(s); reiserfs_free_bitmap_cache(s); if (SB_BUFFER_WITH_SB(s)) Patches currently in stable-queue which might be from jack(a)suse.cz are queue-3.18/reiserfs-make-cancel_old_flush-reliable.patch

7 years, 3 months

1
0
0 0

Patch "rcutorture/configinit: Fix build directory error message" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled rcutorture/configinit: Fix build directory error message to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: rcutorture-configinit-fix-build-directory-error-message.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 10:11:52 CET 2018 From: SeongJae Park <sj38.park(a)gmail.com> Date: Fri, 3 Nov 2017 19:17:20 +0900 Subject: rcutorture/configinit: Fix build directory error message From: SeongJae Park <sj38.park(a)gmail.com> [ Upstream commit 2adfa4210f8f35cdfb4e08318cc06b99752964c2 ] The 'configinit.sh' script checks the format of optional argument for the build directory, printing an error message if the format is not valid. However, the error message uses the wrong variable, indicating an empty string even though the user entered a non-empty (but erroneous) string. This commit fixes the script to use the correct variable. Fixes: c87b9c601ac8 ("rcutorture: Add KVM-based test framework") Signed-off-by: SeongJae Park <sj38.park(a)gmail.com> Signed-off-by: Paul E. McKenney <paulmck(a)linux.vnet.ibm.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/testing/selftests/rcutorture/bin/configinit.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/tools/testing/selftests/rcutorture/bin/configinit.sh +++ b/tools/testing/selftests/rcutorture/bin/configinit.sh @@ -51,7 +51,7 @@ then mkdir $builddir fi else - echo Bad build directory: \"$builddir\" + echo Bad build directory: \"$buildloc\" exit 2 fi fi Patches currently in stable-queue which might be from sj38.park(a)gmail.com are queue-3.18/rcutorture-configinit-fix-build-directory-error-message.patch

7 years, 3 months

1
0
0 0

Patch "powerpc: Avoid taking a data miss on every userspace instruction miss" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled powerpc: Avoid taking a data miss on every userspace instruction miss to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: powerpc-avoid-taking-a-data-miss-on-every-userspace-instruction-miss.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 10:11:52 CET 2018 From: Anton Blanchard <anton(a)samba.org> Date: Mon, 3 Apr 2017 16:41:02 +1000 Subject: powerpc: Avoid taking a data miss on every userspace instruction miss From: Anton Blanchard <anton(a)samba.org> [ Upstream commit a7a9dcd882a67b68568868b988289fce5ffd8419 ] Early on in do_page_fault() we call store_updates_sp(), regardless of the type of exception. For an instruction miss this doesn't make sense, because we only use this information to detect if a data miss is the result of a stack expansion instruction or not. Worse still, it results in a data miss within every userspace instruction miss handler, because we try and load the very instruction we are about to install a pte for! A simple exec microbenchmark runs 6% faster on POWER8 with this fix: #include <stdlib.h> #include <stdio.h> #include <unistd.h> int main(int argc, char *argv[]) { unsigned long left = atol(argv[1]); char leftstr[16]; if (left-- == 0) return 0; sprintf(leftstr, "%ld", left); execlp(argv[0], argv[0], leftstr, NULL); perror("exec failed\n"); return 0; } Pass the number of iterations on the command line (eg 10000) and time how long it takes to execute. Signed-off-by: Anton Blanchard <anton(a)samba.org> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/mm/fault.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/powerpc/mm/fault.c +++ b/arch/powerpc/mm/fault.c @@ -294,7 +294,7 @@ int __kprobes do_page_fault(struct pt_re * can result in fault, which will cause a deadlock when called with * mmap_sem held */ - if (user_mode(regs)) + if (!is_exec && user_mode(regs)) store_update_sp = store_updates_sp(regs); if (user_mode(regs)) Patches currently in stable-queue which might be from anton(a)samba.org are queue-3.18/powerpc-avoid-taking-a-data-miss-on-every-userspace-instruction-miss.patch

7 years, 3 months

1
0
0 0

Patch "perf tools: Make perf_event__synthesize_mmap_events() scale" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled perf tools: Make perf_event__synthesize_mmap_events() scale to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: perf-tools-make-perf_event__synthesize_mmap_events-scale.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 10:11:52 CET 2018 From: Stephane Eranian <eranian(a)google.com> Date: Wed, 15 Mar 2017 10:17:13 -0700 Subject: perf tools: Make perf_event__synthesize_mmap_events() scale From: Stephane Eranian <eranian(a)google.com> [ Upstream commit 88b897a30c525c2eee6e7f16e1e8d0f18830845e ] This patch significantly improves the execution time of perf_event__synthesize_mmap_events() when running perf record on systems where processes have lots of threads. It just happens that cat /proc/pid/maps support uses a O(N^2) algorithm to generate each map line in the maps file. If you have 1000 threads, then you have necessarily 1000 stacks. For each vma, you need to check if it corresponds to a thread's stack. With a large number of threads, this can take a very long time. I have seen latencies >> 10mn. As of today, perf does not use the fact that a mapping is a stack, therefore we can work around the issue by using /proc/pid/tasks/pid/maps. This entry does not try to map a vma to stack and is thus much faster with no loss of functonality. The proc-map-timeout logic is kept in case users still want some upper limit. In V2, we fix the file path from /proc/pid/tasks/pid/maps to actual /proc/pid/task/pid/maps, tasks -> task. Thanks Arnaldo for catching this. Committer note: This problem seems to have been elliminated in the kernel since commit : b18cb64ead40 ("fs/proc: Stop trying to report thread stacks"). Signed-off-by: Stephane Eranian <eranian(a)google.com> Acked-by: Jiri Olsa <jolsa(a)redhat.com> Cc: Andy Lutomirski <luto(a)kernel.org> Cc: Namhyung Kim <namhyung(a)kernel.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Link: http://lkml.kernel.org/r/20170315135059.GC2177@redhat.com Link: http://lkml.kernel.org/r/1489598233-25586-1-git-send-email-eranian@google.c… Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/perf/util/event.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/tools/perf/util/event.c +++ b/tools/perf/util/event.c @@ -167,8 +167,8 @@ int perf_event__synthesize_mmap_events(s if (machine__is_default_guest(machine)) return 0; - snprintf(filename, sizeof(filename), "%s/proc/%d/maps", - machine->root_dir, pid); + snprintf(filename, sizeof(filename), "%s/proc/%d/task/%d/maps", + machine->root_dir, pid, pid); fp = fopen(filename, "r"); if (fp == NULL) { Patches currently in stable-queue which might be from eranian(a)google.com are queue-3.18/perf-session-don-t-rely-on-evlist-in-pipe-mode.patch queue-3.18/perf-tools-make-perf_event__synthesize_mmap_events-scale.patch queue-3.18/perf-inject-copy-events-when-reordering-events-in-pipe-mode.patch

7 years, 3 months

1
0
0 0

Patch "perf session: Don't rely on evlist in pipe mode" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled perf session: Don't rely on evlist in pipe mode to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: perf-session-don-t-rely-on-evlist-in-pipe-mode.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 10:11:52 CET 2018 From: David Carrillo-Cisneros <davidcc(a)google.com> Date: Mon, 10 Apr 2017 13:14:30 -0700 Subject: perf session: Don't rely on evlist in pipe mode From: David Carrillo-Cisneros <davidcc(a)google.com> [ Upstream commit 0973ad97c187e06aece61f685b9c3b2d93290a73 ] Session sets a number parameters that rely on evlist. These parameters are not used in pipe-mode and should not be set, since evlist is unavailable. Fix that. Signed-off-by: David Carrillo-Cisneros <davidcc(a)google.com> Acked-by: Jiri Olsa <jolsa(a)kernel.org> Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com> Cc: Andi Kleen <ak(a)linux.intel.com> Cc: He Kuang <hekuang(a)huawei.com> Cc: Masami Hiramatsu <mhiramat(a)kernel.org> Cc: Paul Turner <pjt(a)google.com> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Simon Que <sque(a)chromium.org> Cc: Stephane Eranian <eranian(a)google.com> Cc: Wang Nan <wangnan0(a)huawei.com> Link: http://lkml.kernel.org/r/20170410201432.24807-6-davidcc@google.com [ Check if file != NULL in perf_session__new(), like when used by builtin-top.c ] Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/perf/util/session.c | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) --- a/tools/perf/util/session.c +++ b/tools/perf/util/session.c @@ -108,8 +108,14 @@ struct perf_session *perf_session__new(s if (perf_session__open(session) < 0) goto out_close; - perf_session__set_id_hdr_size(session); - perf_session__set_comm_exec(session); + /* + * set session attributes that are present in perf.data + * but not in pipe-mode. + */ + if (!file->is_pipe) { + perf_session__set_id_hdr_size(session); + perf_session__set_comm_exec(session); + } } } @@ -122,7 +128,11 @@ struct perf_session *perf_session__new(s pr_warning("Cannot read kernel map\n"); } - if (tool && tool->ordering_requires_timestamps && + /* + * In pipe-mode, evlist is empty until PERF_RECORD_HEADER_ATTR is + * processed, so perf_evlist__sample_id_all is not meaningful here. + */ + if ((!file || !file->is_pipe) && tool && tool->ordering_requires_timestamps && tool->ordered_events && !perf_evlist__sample_id_all(session->evlist)) { dump_printf("WARNING: No sample_id_all support, falling back to unordered processing\n"); tool->ordered_events = false; Patches currently in stable-queue which might be from davidcc(a)google.com are queue-3.18/perf-session-don-t-rely-on-evlist-in-pipe-mode.patch queue-3.18/perf-inject-copy-events-when-reordering-events-in-pipe-mode.patch

7 years, 3 months

1
0
0 0

Patch "perf inject: Copy events when reordering events in pipe mode" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled perf inject: Copy events when reordering events in pipe mode to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: perf-inject-copy-events-when-reordering-events-in-pipe-mode.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 10:11:52 CET 2018 From: David Carrillo-Cisneros <davidcc(a)google.com> Date: Mon, 10 Apr 2017 13:14:27 -0700 Subject: perf inject: Copy events when reordering events in pipe mode From: David Carrillo-Cisneros <davidcc(a)google.com> [ Upstream commit 1e0d4f0200e4dbdfc38d818f329d8a0955f7c6f5 ] __perf_session__process_pipe_events reuses the same memory buffer to process all events in the pipe. When reordering is needed (e.g. -b option), events are not immediately flushed, but kept around until reordering is possible, causing memory corruption. The problem is usually observed by a "Unknown sample error" output. It can easily be reproduced by: perf record -o - noploop | perf inject -b > output Committer testing: Before: $ perf record -o - stress -t 2 -c 2 | perf inject -b > /dev/null stress: info: [8297] dispatching hogs: 2 cpu, 0 io, 0 vm, 0 hdd stress: info: [8297] successful run completed in 2s [ perf record: Woken up 3 times to write data ] [ perf record: Captured and wrote 0.000 MB - ] Warning: Found 1 unknown events! Is this an older tool processing a perf.data file generated by a more recent tool? If that is not the case, consider reporting to linux-kernel(a)vger.kernel.org. $ After: $ perf record -o - stress -t 2 -c 2 | perf inject -b > /dev/null stress: info: [9027] dispatching hogs: 2 cpu, 0 io, 0 vm, 0 hdd stress: info: [9027] successful run completed in 2s [ perf record: Woken up 3 times to write data ] [ perf record: Captured and wrote 0.000 MB - ] no symbols found in /usr/bin/stress, maybe install a debug package? no symbols found in /usr/bin/stress, maybe install a debug package? $ Signed-off-by: David Carrillo-Cisneros <davidcc(a)google.com> Tested-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> Acked-by: Jiri Olsa <jolsa(a)kernel.org> Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com> Cc: Andi Kleen <ak(a)linux.intel.com> Cc: He Kuang <hekuang(a)huawei.com> Cc: Masami Hiramatsu <mhiramat(a)kernel.org> Cc: Paul Turner <pjt(a)google.com> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Simon Que <sque(a)chromium.org> Cc: Stephane Eranian <eranian(a)google.com> Cc: Wang Nan <wangnan0(a)huawei.com> Link: http://lkml.kernel.org/r/20170410201432.24807-3-davidcc@google.com Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/perf/util/ordered-events.c | 3 ++- tools/perf/util/session.c | 1 + 2 files changed, 3 insertions(+), 1 deletion(-) --- a/tools/perf/util/ordered-events.c +++ b/tools/perf/util/ordered-events.c @@ -80,7 +80,7 @@ static union perf_event *dup_event(struc static void free_dup_event(struct ordered_events *oe, union perf_event *event) { - if (oe->copy_on_queue) { + if (event && oe->copy_on_queue) { oe->cur_alloc_size -= event->header.size; free(event); } @@ -151,6 +151,7 @@ void ordered_events__delete(struct order list_move(&event->list, &oe->cache); oe->nr_events--; free_dup_event(oe, event->event); + event->event = NULL; } static int __ordered_events__flush(struct perf_session *s, --- a/tools/perf/util/session.c +++ b/tools/perf/util/session.c @@ -1080,6 +1080,7 @@ static int __perf_session__process_pipe_ buf = malloc(cur_size); if (!buf) return -errno; + ordered_events__set_copy_on_queue(oe, true); more: event = buf; err = readn(fd, event, sizeof(struct perf_event_header)); Patches currently in stable-queue which might be from davidcc(a)google.com are queue-3.18/perf-session-don-t-rely-on-evlist-in-pipe-mode.patch queue-3.18/perf-inject-copy-events-when-reordering-events-in-pipe-mode.patch

7 years, 3 months

1
0
0 0

Patch "PCI/MSI: Stop disabling MSI/MSI-X in pci_device_shutdown()" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled PCI/MSI: Stop disabling MSI/MSI-X in pci_device_shutdown() to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: pci-msi-stop-disabling-msi-msi-x-in-pci_device_shutdown.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 10:11:52 CET 2018 From: Prarit Bhargava <prarit(a)redhat.com> Date: Thu, 26 Jan 2017 14:07:47 -0500 Subject: PCI/MSI: Stop disabling MSI/MSI-X in pci_device_shutdown() From: Prarit Bhargava <prarit(a)redhat.com> [ Upstream commit fda78d7a0ead144f4b2cdb582dcba47911f4952c ] The pci_bus_type .shutdown method, pci_device_shutdown(), is called from device_shutdown() in the kernel restart and shutdown paths. Previously, pci_device_shutdown() called pci_msi_shutdown() and pci_msix_shutdown(). This disables MSI and MSI-X, which causes the device to fall back to raising interrupts via INTx. But the driver is still bound to the device, it doesn't know about this change, and it likely doesn't have an INTx handler, so these INTx interrupts cause "nobody cared" warnings like this: irq 16: nobody cared (try booting with the "irqpoll" option) CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.2-1.el7_UNSUPPORTED.x86_64 #1 Hardware name: Hewlett-Packard HP Z820 Workstation/158B, BIOS J63 v03.90 06/ ... The MSI disabling code was added by d52877c7b1af ("pci/irq: let pci_device_shutdown to call pci_msi_shutdown v2") because a driver left MSI enabled and kdump failed because the kexeced kernel wasn't prepared to receive the MSI interrupts. Subsequent commits 1851617cd2da ("PCI/MSI: Disable MSI at enumeration even if kernel doesn't support MSI") and e80e7edc55ba ("PCI/MSI: Initialize MSI capability for all architectures") changed the kexeced kernel to disable all MSIs itself so it no longer depends on the crashed kernel to clean up after itself. Stop disabling MSI/MSI-X in pci_device_shutdown(). This resolves the "nobody cared" unhandled IRQ issue above. It also allows PCI serial devices, which may rely on the MSI interrupts, to continue outputting messages during reboot/shutdown. [bhelgaas: changelog, drop pci_msi_shutdown() and pci_msix_shutdown() calls altogether] Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=187351 Signed-off-by: Prarit Bhargava <prarit(a)redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com> CC: Alex Williamson <alex.williamson(a)redhat.com> CC: David Arcari <darcari(a)redhat.com> CC: Myron Stowe <mstowe(a)redhat.com> CC: Lukas Wunner <lukas(a)wunner.de> CC: Keith Busch <keith.busch(a)intel.com> CC: Mika Westerberg <mika.westerberg(a)linux.intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/pci/pci-driver.c | 2 -- 1 file changed, 2 deletions(-) --- a/drivers/pci/pci-driver.c +++ b/drivers/pci/pci-driver.c @@ -450,8 +450,6 @@ static void pci_device_shutdown(struct d if (drv && drv->shutdown) drv->shutdown(pci_dev); - pci_msi_shutdown(pci_dev); - pci_msix_shutdown(pci_dev); #ifdef CONFIG_KEXEC /* Patches currently in stable-queue which might be from prarit(a)redhat.com are queue-3.18/pci-msi-stop-disabling-msi-msi-x-in-pci_device_shutdown.patch

7 years, 3 months

1
0
0 0

Patch "of: fix of_device_get_modalias returned length when truncating buffers" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled of: fix of_device_get_modalias returned length when truncating buffers to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: of-fix-of_device_get_modalias-returned-length-when-truncating-buffers.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 10:11:52 CET 2018 From: Rob Herring <robh(a)kernel.org> Date: Mon, 16 Jan 2017 14:28:39 -0600 Subject: of: fix of_device_get_modalias returned length when truncating buffers From: Rob Herring <robh(a)kernel.org> [ Upstream commit bcf54d5385abaea9c8026aae6f4eeb348671a52d ] If the length of the modalias is greater than the buffer size, then the modalias is truncated. However the untruncated length is returned which will cause an error. Fix this to return the truncated length. If an error in the case was desired, then then we should just return -ENOMEM. The reality is no device will ever have 4KB of compatible strings to hit this case. Signed-off-by: Rob Herring <robh(a)kernel.org> Cc: Frank Rowand <frowand.list(a)gmail.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/of/device.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/of/device.c +++ b/drivers/of/device.c @@ -126,7 +126,7 @@ ssize_t of_device_get_modalias(struct de str[i] = '_'; } - return tsize; + return repend; } EXPORT_SYMBOL_GPL(of_device_get_modalias); Patches currently in stable-queue which might be from robh(a)kernel.org are queue-3.18/of-fix-of_device_get_modalias-returned-length-when-truncating-buffers.patch

7 years, 3 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror