-
Notifications
You must be signed in to change notification settings - Fork 54.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merge pull request #1 from torvalds/master #208
Closed
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Update from original
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jun 6, 2016
WARNING: Possible unwrapped commit description (prefer a maximum 75 chars per line) torvalds#17: Thus, checks for "frontswap_enabled" are replaced with "frontswap_enabled()" WARNING: space prohibited between function name and open parenthesis '(' torvalds#208: FILE: mm/frontswap.c:255: + VM_BUG_ON (!frontswap_ops); total: 0 errors, 2 warnings, 188 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. ./patches/mm-frontswap-convert-frontswap_enabled-to-static-key.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: "Kirill A. Shutemov" <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jun 8, 2016
WARNING: Possible unwrapped commit description (prefer a maximum 75 chars per line) torvalds#17: Thus, checks for "frontswap_enabled" are replaced with "frontswap_enabled()" WARNING: space prohibited between function name and open parenthesis '(' torvalds#208: FILE: mm/frontswap.c:255: + VM_BUG_ON (!frontswap_ops); total: 0 errors, 2 warnings, 188 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. ./patches/mm-frontswap-convert-frontswap_enabled-to-static-key.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: "Kirill A. Shutemov" <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jun 16, 2016
WARNING: Possible unwrapped commit description (prefer a maximum 75 chars per line) torvalds#17: Thus, checks for "frontswap_enabled" are replaced with "frontswap_enabled()" WARNING: space prohibited between function name and open parenthesis '(' torvalds#208: FILE: mm/frontswap.c:255: + VM_BUG_ON (!frontswap_ops); total: 0 errors, 2 warnings, 188 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. ./patches/mm-frontswap-convert-frontswap_enabled-to-static-key.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: "Kirill A. Shutemov" <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jun 21, 2016
WARNING: Possible unwrapped commit description (prefer a maximum 75 chars per line) torvalds#17: Thus, checks for "frontswap_enabled" are replaced with "frontswap_enabled()" WARNING: space prohibited between function name and open parenthesis '(' torvalds#208: FILE: mm/frontswap.c:255: + VM_BUG_ON (!frontswap_ops); total: 0 errors, 2 warnings, 188 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. ./patches/mm-frontswap-convert-frontswap_enabled-to-static-key.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: "Kirill A. Shutemov" <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jun 23, 2016
WARNING: Possible unwrapped commit description (prefer a maximum 75 chars per line) torvalds#17: Thus, checks for "frontswap_enabled" are replaced with "frontswap_enabled()" WARNING: space prohibited between function name and open parenthesis '(' torvalds#208: FILE: mm/frontswap.c:255: + VM_BUG_ON (!frontswap_ops); total: 0 errors, 2 warnings, 188 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. ./patches/mm-frontswap-convert-frontswap_enabled-to-static-key.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: "Kirill A. Shutemov" <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jul 24, 2016
WARNING: Possible unwrapped commit description (prefer a maximum 75 chars per line) torvalds#17: Thus, checks for "frontswap_enabled" are replaced with "frontswap_enabled()" WARNING: space prohibited between function name and open parenthesis '(' torvalds#208: FILE: mm/frontswap.c:255: + VM_BUG_ON (!frontswap_ops); total: 0 errors, 2 warnings, 188 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. ./patches/mm-frontswap-convert-frontswap_enabled-to-static-key.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: "Kirill A. Shutemov" <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
laijs
pushed a commit
to laijs/linux
that referenced
this pull request
Feb 13, 2017
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
May 30, 2017
The taggers are currently responsible to free the original SKB if they made a copy of it, or in case of error. This patch simplifies this by freeing the original SKB in the dsa_slave_xmit caller if it differs from the return SKB (copy or NULL.) At the same time, fix the checkpatch NULL comparison check: CHECK: Comparison to NULL could be written "!nskb" torvalds#208: FILE: net/dsa/tag_trailer.c:35: + if (nskb == NULL) Signed-off-by: Vivien Didelot <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
May 31, 2017
The taggers are currently responsible to free the original SKB if they made a copy of it, or in case of error. This patch simplifies this by freeing the original SKB in the dsa_slave_xmit caller, but only if an error (NULL) is returned. It is still the responsibility of the tagger to free the original SKB if it returned a copy of it. At the same time, fix the checkpatch NULL comparison check: CHECK: Comparison to NULL could be written "!nskb" torvalds#208: FILE: net/dsa/tag_trailer.c:35: + if (nskb == NULL) Signed-off-by: Vivien Didelot <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jun 1, 2017
As of a86d8be ("net: dsa: Factor bottom tag receive functions"), the rcv caller frees the original SKB in case or error. Be symmetric with that and make the xmit caller do the same. At the same time, fix the checkpatch NULL comparison check: CHECK: Comparison to NULL could be written "!nskb" torvalds#208: FILE: net/dsa/tag_trailer.c:35: + if (nskb == NULL) Signed-off-by: Vivien Didelot <[email protected]>
vivien
added a commit
to vivien/linux
that referenced
this pull request
Jun 2, 2017
As of a86d8be ("net: dsa: Factor bottom tag receive functions"), the rcv caller frees the original SKB in case or error. Be symmetric with that and make the xmit caller do the same. At the same time, fix the checkpatch NULL comparison check: CHECK: Comparison to NULL could be written "!nskb" torvalds#208: FILE: net/dsa/tag_trailer.c:35: + if (nskb == NULL) Signed-off-by: Vivien Didelot <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jun 4, 2017
GIT 1bc60b48157f140f72a98357b7f1f4eef12a887b commit 4f61e1e687c45ee8c6820519fdd9027ed95bb774 Author: Nicholas Bellinger <[email protected]> Date: Thu Jun 1 08:57:15 2017 +0200 target: Avoid target_shutdown_sessions loop during queue_depth change When target_shutdown_sessions() is invoked to shutdown all active sessions associated with a se_node_acl when se_node_acl->queue_depth is changed via core_tpg_set_initiator_node_queue_depth(), it's possible that new connections reconnect immediately after explicit shutdown occurs via target_shutdown_sessions(). Which means it's possible for the newly reconnected session with the proper queue_depth can be shutdown multiple times when target_shutdown_sessions() loops to drain all active sessions for all cases. This was regression was introduced by: commit bc6e6bb470eda42f44bcac96c261cff1216577b3 Author: Christoph Hellwig <[email protected]> Date: Mon May 2 15:45:19 2016 +0200 target: consolidate and fix session shutdown To avoid this case, instead change target_shutdown_sessions() to pass 'do_restart' and avoid the looping drain of sessions when invoked via core_tpg_set_initiator_node_queue_depth(), but still loop during normal se_node_acl delete until all associated sessions have been shutdown. (v2 - go back to the original version instead of a local list, in order to protect list_del_init(&sess->sess_acl_list) from transport_deregister_session_configfs. Also use safe list walking in target_shutdown_sessions - nab) Cc: Christoph Hellwig <[email protected]> Cc: Mike Christie <[email protected]> Cc: Hannes Reinecke <[email protected]> Cc: <[email protected]> # 4.7+ Signed-off-by: Nicholas Bellinger <[email protected]> commit e4c078873f138fc2db3256ed1454c5fadd109e81 Author: Nicholas Bellinger <[email protected]> Date: Thu Jun 1 20:21:33 2017 -0700 iscsi-target: Avoid holding ->tpg_state_lock during param update As originally reported by Jia-Ju, iscsit_tpg_enable_portal_group() holds iscsi_portal_group->tpg_state_lock while updating AUTHMETHOD via iscsi_update_param_value(), which performs a GFP_KERNEL allocation. However, since iscsit_tpg_enable_portal_group() is already protected by iscsit_get_tpg() -> iscsi_portal_group->tpg_access_lock in it's parent caller, ->tpg_state_lock only needs to be held when setting TPG_STATE_ACTIVE. Reported-by: Jia-Ju Bai <[email protected]> Reviewed-by: Jia-Ju Bai <[email protected]> Signed-off-by: Nicholas Bellinger <[email protected]> commit 06fd91ce633d46898e1d0b272a342a4c9b310b34 Author: Nicholas Bellinger <[email protected]> Date: Thu Jun 1 03:11:18 2017 -0700 target/configfs: Kill se_lun->lun_link_magic Instead of using a hardcoded magic value in se_lun when verifying a target config_item symlink source during target_fabric_mappedlun_link(), go ahead and use target_fabric_port_item_ops directly instead. Reviewed-by: Christoph Hellwig <[email protected]> Cc: Mike Christie <[email protected]> Cc: Hannes Reinecke <[email protected]> Signed-off-by: Nicholas Bellinger <[email protected]> commit 9af17008a0add07105569ba6adaa60078e5b36fa Author: Nicholas Bellinger <[email protected]> Date: Thu Jun 1 03:10:53 2017 -0700 target/configfs: Kill se_device->dev_link_magic Instead of using a hardcoded magic value in se_device when verifying a target config_item symlink source during target_fabric_port_link(), go ahead and use target_core_dev_item_ops directly instead. Reviewed-by: Christoph Hellwig <[email protected]> Cc: Mike Christie <[email protected]> Cc: Hannes Reinecke <[email protected]> Signed-off-by: Nicholas Bellinger <[email protected]> commit 1b7d8dd63b27518c97990c64321293fdb929cf30 Author: Yunlei He <[email protected]> Date: Thu Jun 1 16:43:51 2017 +0800 f2fs: fix a panic caused by NULL flush_cmd_control Mount fs with option noflush_merge, boot failed for illegal address fcc in function f2fs_issue_flush: if (!test_opt(sbi, FLUSH_MERGE)) { ret = submit_flush_wait(sbi); atomic_inc(&fcc->issued_flush); -> Here, fcc illegal return ret; } Signed-off-by: Yunlei He <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> commit dbc30d988661f652f9d61d8f112f2cf4fb9a0bab Author: Zhang Shengju <[email protected]> Date: Thu Jun 1 16:50:10 2017 +0800 f2fs: remove the unnecessary cast for PTR_ERR It's not necessary to specify 'int' casting for PTR_ERR. Signed-off-by: Zhang Shengju <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> commit a7e7fd11b8efb1a5a9525ec4667faf11f3fbfed1 Author: Jaegeuk Kim <[email protected]> Date: Thu Jun 1 15:39:27 2017 -0700 f2fs: remove false-positive bug_on For example, f2fs_create - new_node_page is failed - handle_failed_inode - skip to add it into orphan list, since ni.blk_addr == NULL_ADDR : set_inode_flag(inode, FI_FREE_NID) f2fs_evict_inode - EIO due to fault injection - f2fs_bug_on() is triggered So, we don't need to call f2fs_bug_on in this case. Signed-off-by: Jaegeuk Kim <[email protected]> commit ce0407e1e88392deaf20fca542d139cdbeeb75a8 Author: Paul E. McKenney <[email protected]> Date: Tue May 2 15:22:26 2017 -0700 rcutorture: Don't wait for kernel when all builds fail Currently, rcutorture groups runs in batches, building each scenario in a given batch, then invoking qemu to run all the kernels in the batch. Of course, if a given scenario's kernel fails to build, there is no qemu run for that scenario. And if all of the kernels in a given batch fail to build, there are no runs, and rcutorture immediately starts on the next batch. But not if --jitter has been specified, which it is by default. In this case, the jitter scripts are started unconditionally, and rcutorture waits for them to complete, even though there are no kernels to run. This commit therefore checks for this situation, and refuses to start jitter unless at least one of the kernels in the batch built successfully. This saves substantial time when all scenarios' kernels fail to build, particularly if a long --duration was specified. Signed-off-by: Paul E. McKenney <[email protected]> commit 597635ee552b0fe91521cffe688b0c6085b19778 Author: Paul E. McKenney <[email protected]> Date: Mon May 1 17:49:29 2017 -0700 torture: Add --kconfig argument to kvm.sh Currently, testing a variant of an existing scenario requires editing that scenario's file or creating a new scenario file. This is messy and error prone with respect to changes to scenarios. This commit therefore adds a --kconfig argument to kvm.sh, so that '--kconfig "CONFIG_RCU_TRACE=y CONFIG_RCU_EQS_DEBUG=n" will override those two Kconfig options. In addition, there is now clear precedence: the config fragment overrides CFcommon, and the --kconfig argument overrides both. Signed-off-by: Paul E. McKenney <[email protected]> commit 0d51d5d59e8767cb2b7d74882b15d998433e07f9 Author: Paul E. McKenney <[email protected]> Date: Fri May 26 16:16:40 2017 -0700 srcu: Move rcu_scheduler_starting() from Tiny RCU to Tiny SRCU Other than lockdep support, Tiny RCU has no need for the scheduler status. However, Tiny SRCU will need this to control boot-time behavior independent of lockdep. Therefore, this commit moves rcu_scheduler_starting() from kernel/rcu/tiny_plugin.h to kernel/rcu/srcutiny.c. This in turn allows the complete removal of kernel/rcu/tiny_plugin.h. Signed-off-by: Paul E. McKenney <[email protected]> commit be215bb343adb2b3b0e9b4f18e728eb7a39b12d6 Author: Paul E. McKenney <[email protected]> Date: Fri May 26 17:31:45 2017 -0700 rcutorture: Select CONFIG_PROVE_LOCKING for Tiny SRCU scenario This commit selects CONFIG_PROVE_LOCKING for the SRCU-u scenario to get better test coverage. Signed-off-by: Paul E. McKenney <[email protected]> commit 8a2ccf36fd4eea0b1f9121e7781363050cf365a5 Author: Paul E. McKenney <[email protected]> Date: Thu May 25 08:51:48 2017 -0700 rcu: Create reasonable API for do_exit() TASKS_RCU processing Currently, the exit-time support for TASKS_RCU is open-coded in do_exit(). This commit creates exit_tasks_rcu_start() and exit_tasks_rcu_finish() APIs for do_exit() use. This has the benefit of confining the use of the tasks_rcu_exit_srcu variable to one file, allowing it to become static. Signed-off-by: Paul E. McKenney <[email protected]> commit 035932dfada84331bbec2f126b53c3f377f32daa Author: Paul E. McKenney <[email protected]> Date: Thu May 25 08:23:06 2017 -0700 rcu: Remove CONFIG_TASKS_RCU ifdef from rcuperf.c The synchronize_rcu_tasks() and call_rcu_tasks() APIs are now available regardless of kernel configuration, so this commit removes the CONFIG_TASKS_RCU ifdef from rcuperf.c. Signed-off-by: Paul E. McKenney <[email protected]> commit ddd3da98d603c72dcbf32f53cf4a204fcc2abff8 Author: Paul E. McKenney <[email protected]> Date: Thu May 25 08:05:00 2017 -0700 rcu: Drive TASKS_RCU directly off of PREEMPT The actual use of TASKS_RCU is only when PREEMPT, otherwise RCU-sched is used instead. This commit therefore makes synchronize_rcu_tasks() and call_rcu_tasks() available always, but mapped to synchronize_sched() and call_rcu_sched(), respectively, when !PREEMPT. This approach also allows some #ifdefs to be removed from rcutorture. Reported-by: Ingo Molnar <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]> Reviewed-by: Masami Hiramatsu <[email protected]> Acked-by: Ingo Molnar <[email protected]> commit 14c8d59b22d326ea33f4e0e1b8612d0903189633 Author: Paul E. McKenney <[email protected]> Date: Mon May 22 13:59:52 2017 -0700 rcutorture: Print SRCU lock/unlock totals This commit adds printing of SRCU lock/unlock totals, which are just the sums of the per-CPU counts. Saves a bit of mental arithmetic. Signed-off-by: Paul E. McKenney <[email protected]> commit ed5cbd3db8d718a6c880904432b439e8b5e6abf6 Author: Paul E. McKenney <[email protected]> Date: Mon May 22 13:31:03 2017 -0700 rcutorture: Move SRCU status printing to SRCU implementations This commit gets rid of some ugly #ifdefs in rcutorture.c by moving the SRCU status printing to the SRCU implementations. Signed-off-by: Paul E. McKenney <[email protected]> commit 6ba3472d3218db2be12c6f1c6a40e56daafc2335 Author: Paul E. McKenney <[email protected]> Date: Tue May 30 15:20:37 2017 -0700 module: Fix pr_fmt() bug for header use of printk This commit removes the pr_fmt() macro, replacing it with mod_err() and mod_debug() macros to avoid errors when using printk() from header files. Signed-off-by: Joe Perches <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]> commit e2b41e3196cb8320f81fa10bda17d17ddcf6e419 Author: Paul E. McKenney <[email protected]> Date: Sat Apr 29 20:03:20 2017 -0700 rcu: Use timer as backstop for NOCB deferred wakeups The handling of RCU's no-CBs CPUs has a maintenance headache, namely that if call_rcu() is invoked with interrupts disabled, the rcuo kthread wakeup must be defered to a point where we can be sure that scheduler locks are not held. Of course, there are a lot of code paths leading from an interrupts-disabled invocation of call_rcu(), and missing any one of these can result in excessive callback-invocation latency, and potentially even system hangs. This commit therefore uses a timer to guarantee that the wakeup will eventually occur. If one of the deferred-wakeup points kicks in, then the timer is simply cancelled. This commit also fixes up an incomplete removal of commits that were intended to plug remaining exit paths, which should have the added benefit of reducing the overhead of RCU's context-switch hooks. Signed-off-by: Paul E. McKenney <[email protected]> [ paulmck: Dan Carpenter fix for mod_timer() usage bug found by smatch. ] commit 1b9d76e44cac9aaa2e7d19fe746252b4b41d8353 Author: Paul E. McKenney <[email protected]> Date: Wed Nov 30 06:24:30 2016 -0800 sched,rcu: Make cond_resched() provide RCU quiescent state There is some confusion as to which of cond_resched() or cond_resched_rcu_qs() should be added to long in-kernel loops. This commit therefore eliminates the decision by adding RCU quiescent states to cond_resched(). This commit also simplifies the code that used to interact with cond_resched_rcu_qs(), and that now interacts with cond_resched(), to reduce its overhead. This reduction is necessary to allow the heavier-weight cond_resched_rcu_qs() mechanism to be invoked everywhere that cond_resched() is invoked. Part of that reduction in overhead converts the jiffies_till_sched_qs kernel parameter to read-only at runtime, thus eliminating the need for bounds checking. Reported-by: Michal Hocko <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]> Cc: Peter Zijlstra <[email protected]> commit c3fa663c7c4b86dc42a23cf72607616a6cc4da92 Author: Paul E. McKenney <[email protected]> Date: Wed May 17 10:54:29 2017 -0700 rcu: Remove RCU CPU stall warnings from Tiny RCU Tiny RCU's job is to be tiny, so this commit removes its RCU CPU stall warning code. After this, there is no longer any need for rcu_sched_ctrlblk and rcu_bh_ctrlblk to be in tiny_plugin.h, so this commit also moves them to tiny.c. Signed-off-by: Paul E. McKenney <[email protected]> commit e574636033dbb5f720c7d008ec073a8af6c53539 Author: Paul E. McKenney <[email protected]> Date: Wed May 17 10:17:03 2017 -0700 rcu: Remove event tracing from Tiny RCU This commit saves a few lines by getting rid of Tiny RCU's event tracing. Signed-off-by: Paul E. McKenney <[email protected]> commit d53d3a286a91da65d09ab3dccf93f32a2d53648f Author: Paul E. McKenney <[email protected]> Date: Wed May 17 09:19:44 2017 -0700 rcu: Move RCU debug Kconfig options to kernel/rcu RCU's debugging Kconfig options are in the unintuitive location lib/Kconfig.debug, and there are enough of them that it would be good for them to be more centralized. This commit therefore extracts RCU's Kconfig options from init/Kconfig into a new kernel/rcu/Kconfig.debug file. Reported-by: Ingo Molnar <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]> commit 287b1b5a0b431a5b85747140d1d91ecb72ece1e3 Author: Paul E. McKenney <[email protected]> Date: Wed May 17 08:43:40 2017 -0700 rcu: Move RCU non-debug Kconfig options to kernel/rcu RCU's Kconfig options are scattered, and there are enough of them that it would be good for them to be more centralized. This commit therefore extracts RCU's Kconfig options from init/Kconfig into a new kernel/rcu/Kconfig file. Reported-by: Ingo Molnar <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]> commit 4c22da1f2c0a63172d567403316fcf2006dac7a2 Author: Paul E. McKenney <[email protected]> Date: Mon May 15 16:26:34 2017 -0700 rcu: Eliminate NOCBs CPU-state Kconfig options The CONFIG_RCU_NOCB_CPU_ALL, CONFIG_RCU_NOCB_CPU_NONE, and CONFIG_RCU_NOCB_CPU_ZERO Kconfig options are used only in testing and are redundant with the rcu_nocbs= boot parameter. This commit therefore removes these three Kconfig options and adjusts the rcutorture scripts to use the boot parameter instead. Signed-off-by: Paul E. McKenney <[email protected]> commit 64d6535de2b2949d005b81f98a224cd7992e7e7c Author: Paul E. McKenney <[email protected]> Date: Mon May 15 15:30:32 2017 -0700 rcu: Remove debugfs tracing RCU's debugfs tracing used to be the only reasonable low-level debug information available, but ftrace and event tracing has since surpassed the RCU debugfs level of usefulness. This commit therefore removes RCU's debugfs tracing. Signed-off-by: Paul E. McKenney <[email protected]> commit 0ce2e8a0aa44d456179b47c31ff3e48b5b0a7e64 Author: Paul E. McKenney <[email protected]> Date: Mon May 15 14:57:01 2017 -0700 srcu: Remove Classic SRCU Classic SRCU was only ever intended to be a fallback in case of issues with Tree/Tiny SRCU, and the latter two are doing quite well in testing. This commit therefore removes Classic SRCU. Signed-off-by: Paul E. McKenney <[email protected]> commit 49ba6fb1e68f5ab828f1f789295a97ad691e076c Author: Paul E. McKenney <[email protected]> Date: Sun May 14 17:06:30 2017 -0700 srcu: Fix rcutorture-statistics typo The function srcutorture_get_gp_data() duplicated the check for sp->batch_check0.head instead of also checking sp->batch_check1.head. The only effect of this typo would be for rcutorture statistics to understate the fraction of time that an SRCU grace period was in flight, and only for Classic SRCU. This commit fixes this typo. Reported-by: David Binderman <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]> commit 27ad1d73e8271e565825b9072a2ddfd82a355a05 Author: Paul E. McKenney <[email protected]> Date: Fri May 12 15:56:35 2017 -0700 rcu: Remove SPARSE_RCU_POINTER Kconfig option The sparse-based checking for non-RCU accesses to RCU-protected pointers has been around for a very long time, and it is now the only type of sparse-based checking that is optional. This commit therefore makes it unconditional. Reported-by: Ingo Molnar <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]> Cc: Fengguang Wu <[email protected]> commit 0dd218086c81075a539385667f51452c006b04fc Author: Paul E. McKenney <[email protected]> Date: Fri May 12 14:37:19 2017 -0700 rcu: Remove the now-obsolete PROVE_RCU_REPEATEDLY Kconfig option The PROVE_RCU_REPEATEDLY Kconfig option was initially added due to the volume of messages from PROVE_RCU: Doing just one per boot would have required excessive numbers of boots to locate them all. However, PROVE_RCU messages are now relatively rare, so there is no longer any reason to need more than one such message per boot. This commit therefore removes the PROVE_RCU_REPEATEDLY Kconfig option. Signed-off-by: Paul E. McKenney <[email protected]> Cc: Ingo Molnar <[email protected]> commit 742714427fbaaa6a9ad877a2409e569eb4ade08d Author: Paul E. McKenney <[email protected]> Date: Thu May 11 15:33:23 2017 -0700 rcu: Remove typecheck() from RCU locking wrapper functions Because raw_spin_lock_irqsave() and raw_spin_unlock_irqrestore() both do typecheck() on their flags argument, there is no point in duplicating this check in raw_spin_lock_irqsave_rcu_node() and raw_spin_unlock_irqrestore_rcu_node(). This commit therefore saves a few lines by removing this duplicated check. Signed-off-by: Paul E. McKenney <[email protected]> commit 06a7b44feb2f317e6ff3066a0a69caa86701b871 Author: Paul E. McKenney <[email protected]> Date: Thu May 11 12:01:50 2017 -0700 rcu: Remove #ifdef moving rcu_end_inkernel_boot from rcupdate.h This commit removes a #ifdef and saves a few lines of code by moving the rcu_end_inkernel_boot() function from include/linux/rcupdate.h to include/linux/rcutiny.h (for TINY_RCU) and to include/linux/rcutree.h (for TREE_RCU). Signed-off-by: Paul E. McKenney <[email protected]> commit 5e62cf9dc3773c3ec8f08f86b441b0d6f0e472e2 Author: Paul E. McKenney <[email protected]> Date: Thu May 11 11:26:22 2017 -0700 rcu: Remove nohz_full full-system-idle state machine The NO_HZ_FULL_SYSIDLE full-system-idle capability was added in 2013 by commit 0edd1b1784cb ("nohz_full: Add full-system-idle state machine"), but has not been used. This commit therefore removes it. If it turns out to be needed later, this commit can always be reverted. Signed-off-by: Paul E. McKenney <[email protected]> Cc: Frederic Weisbecker <[email protected]> Cc: Rik van Riel <[email protected]> Cc: Ingo Molnar <[email protected]> Acked-by: Linus Torvalds <[email protected]> commit a34830f754e21c81c9ef7c89b65f61797d1b17dd Author: Paul E. McKenney <[email protected]> Date: Wed May 10 15:57:16 2017 -0700 rcu: Remove the RCU_KTHREAD_PRIO Kconfig option Anything that can be done with the RCU_KTHREAD_PRIO Kconfig option can also be done with the rcutree.kthread_prio kernel boot parameter. This commit therefore removes this Kconfig option. Reported-by: Linus Torvalds <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]> Cc: Frederic Weisbecker <[email protected]> Cc: Rik van Riel <[email protected]> commit ed4b57aa2231315ce6d242d5348526d685172f61 Author: Paul E. McKenney <[email protected]> Date: Wed May 10 14:36:55 2017 -0700 rcu: Remove *_SLOW_* Kconfig options The RCU_TORTURE_TEST_SLOW_PREINIT, RCU_TORTURE_TEST_SLOW_PREINIT_DELAY, RCU_TORTURE_TEST_SLOW_PREINIT_DELAY, RCU_TORTURE_TEST_SLOW_INIT, RCU_TORTURE_TEST_SLOW_INIT_DELAY, RCU_TORTURE_TEST_SLOW_CLEANUP, and RCU_TORTURE_TEST_SLOW_CLEANUP_DELAY Kconfig options are only useful for torture testing, and there are the rcutree.gp_cleanup_delay, rcutree.gp_init_delay, and rcutree.gp_preinit_delay kernel boot parameters that rcutorture can use instead. The effect of these parameters is to artificially slow down grace period initialization and cleanup in order to make some types of race conditions happen more often. This commit therefore simplifies Tree RCU a bit by removing the Kconfig options and adding the corresponding kernel parameters to rcutorture's .boot files instead. However, this commit also leaves out the kernel parameters for TREE02, TREE04, and TREE07 in order to have about the same number of tests slowed as not slowed. TREE01, TREE03, TREE05, and TREE06 are slowed, and the rest are not slowed. Reported-by: Linus Torvalds <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]> commit 1b8b5fe04eceed655e21f58e5f5b0d034d2892a2 Author: Paul E. McKenney <[email protected]> Date: Tue May 9 15:00:14 2017 -0700 srcu: Use rnp->lock wrappers to replace explicit memory barriers This commit uses TREE RCU's rnp->lock wrappers to replace a few explicit memory barriers. This change also has the advantage of making SRCU's memory-ordering properties be implemented in roughly the same way as they are in Tree RCU. Signed-off-by: Paul E. McKenney <[email protected]> commit e3a95369a3f612804d09a12b0edcc6581b7f5368 Author: Paul E. McKenney <[email protected]> Date: Tue May 9 13:28:51 2017 -0700 rcu: Move rnp->lock wrappers for SRCU use This commit moves the now-generic rnp->lock wrapper macros from kernel/rcu/tree.h to kernel/rcu/rcu.h, thus allowing SRCU to use them. Signed-off-by: Paul E. McKenney <[email protected]> commit 642b6fda21c2e31c1e3d667d41d0f2f2e021aafe Author: Paul E. McKenney <[email protected]> Date: Tue May 9 12:05:46 2017 -0700 rcu: Convert rnp->lock wrappers to macros for SRCU use Use of smp_mb__after_unlock_lock() would allow SRCU to omit a full memory barrier during callback execution, so this commit converts raw_spin_lock_rcu_node() from inline functions to type-generic macros to allow them to handle locks in srcu_node structures as well as rcu_node structures. Signed-off-by: Paul E. McKenney <[email protected]> commit 8820bc038470f90fd584fada46b6b0d551d1c259 Author: Paul E. McKenney <[email protected]> Date: Wed May 3 15:24:25 2017 -0700 rcu: Refactor #includes from include/linux/rcupdate.h The list of #includes from include/linux/rcupdate.h has grown quite a bit, so it is time to trim it. This commit moves the #include of include/linux/ktime.h to include/linux/rcutiny.h, along with the Tiny-RCU-only function that was the only thing needing ktimem.h. It then reconstructs the files included into include/linux/ktime.h based on what is actually needed, with significant help from the 0day Test Robot. This single change reduces the .i file footprint from rcupdate.h from 9018 lines to 7101 lines. Reported-by: Ingo Molnar <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]> commit 2411354d68627e94d9d2e4c9ea96c8cd06a040f6 Author: Arnd Bergmann <[email protected]> Date: Wed May 31 09:26:07 2017 -0700 bcm47xx: Fix build regression Commit 0bc2d534708b ("rcu: Refactor #includes from include/linux/rcupdate.h") caused a build regression in an MTD partition driver: In file included from drivers/mtd/bcm47xxpart.c:12:0: include/linux/bcm47xx_nvram.h: In function 'bcm47xx_nvram_init_from_mem': include/linux/bcm47xx_nvram.h:27:10: error: 'ENOTSUPP' undeclared (first use in this function) The rcupdate.h file has no particular need for linux/errno.h, so this commit includes linux/errno.h into bcm47xx_nvram.h. Fixes: 0bc2d534708b ("rcu: Refactor #includes from include/linux/rcupdate.h") Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]> commit fe47d563065c91cd30088d9b118b79d44905be6f Author: Vivien Didelot <[email protected]> Date: Thu Jun 1 16:07:15 2017 -0400 net: dsa: factor skb freeing on xmit As of a86d8becc3f0 ("net: dsa: Factor bottom tag receive functions"), the rcv caller frees the original SKB in case or error. Be symmetric with that and make the xmit caller do the same. At the same time, fix the checkpatch NULL comparison check: CHECK: Comparison to NULL could be written "!nskb" #208: FILE: net/dsa/tag_trailer.c:35: + if (nskb == NULL) Signed-off-by: Vivien Didelot <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 5470979585d81271d4338c2accfd5e71dafa4af6 Author: Vivien Didelot <[email protected]> Date: Thu Jun 1 16:07:14 2017 -0400 net: dsa: remove out_drop label in taggers rcv Many rcv functions from net/dsa/tag_*.c have a useless out_drop goto label which simply returns NULL. Kill it in favor of the obvious. Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: Vivien Didelot <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 717ffbfb28ac2b53d3140b2a7dfd345e1569b3a5 Author: Vivien Didelot <[email protected]> Date: Thu Jun 1 16:07:13 2017 -0400 net: dsa: remove dsa_uses_tagged_protocol Since dev->dsa_ptr is a pointer to a dsa_switch_tree, there is no need to have another inline helper just to check rcv. Remove dsa_uses_tagged_protocol and check dsa_ptr && dsa_ptr->rcv together at the same time. Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: Vivien Didelot <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 02f840cbc9fa9ee147d882edb96b203999c3ac62 Author: Vivien Didelot <[email protected]> Date: Thu Jun 1 16:07:12 2017 -0400 net: dsa: do not cast dst dsa_ptr is not a void pointer anymore since Nov 2011, as of cf50dcc24f82 ("dsa: Change dsa_uses_{dsa, trailer}_tags() into inline functions"), but an explicit dsa_switch_tree pointer, thus remove the (void *) cast. Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: Vivien Didelot <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 73a7ece8f70c955464080e434b5324bcdfdcb1b1 Author: Vivien Didelot <[email protected]> Date: Thu Jun 1 16:07:11 2017 -0400 net: dsa: comment hot path requirements The DSA layer uses inline helpers and copy of the tagging functions for faster access in hot path. Add comments to detail that. Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: Vivien Didelot <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 30181faae37fa80d3aa73672e5df5f2a5b8dea0a Author: Bart Van Assche <[email protected]> Date: Wed May 31 14:43:50 2017 -0700 nfsd: Check queue type before submitting a SCSI request Since using scsi_req() is only allowed against request queues for which struct scsi_request is the first member of their private request data, refuse to submit SCSI commands against a queue for which this is not the case. References: commit 82ed4db499b8 ("block: split scsi_request out of struct request") Signed-off-by: Bart Van Assche <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Acked-by: J. Bruce Fields <[email protected]> Cc: Jeff Layton <[email protected]> Cc: Omar Sandoval <[email protected]> Cc: [email protected] Signed-off-by: Jens Axboe <[email protected]> commit 73d17701db503382eeed03afb3a6c39ec4d9a5c7 Author: Bart Van Assche <[email protected]> Date: Wed May 31 14:43:49 2017 -0700 cdrom: Check SCSI passthrough support before reading audio The CDROMREADAUDIO ioctl uses SCSI passthrough when the .disk pointer has been set in struct cdrom_device_info. Hence check whether SCSI passthrough is supported before submitting a SCSI command. Note: both the ide-cd and sr drivers set the disk pointer in struct cdrom_device_info but neither the pcd nor the gdrom driver sets that pointer. References: commit 82ed4db499b8 ("block: split scsi_request out of struct request") Signed-off-by: Bart Van Assche <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Cc: Omar Sandoval <[email protected]> Cc: [email protected] Signed-off-by: Jens Axboe <[email protected]> commit ec2be6a98e50d3eb9f35f70aa51c5d2c23737c55 Author: Bart Van Assche <[email protected]> Date: Wed May 31 14:43:48 2017 -0700 pktcdvd: Check queue type before attaching to a queue Since the pktcdvd driver only supports request queues for which struct scsi_request is the first member of their private request data, refuse to register block layer queues for which struct scsi_request is not the first member of the private data. References: commit 82ed4db499b8 ("block: split scsi_request out of struct request") Signed-off-by: Bart Van Assche <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Cc: Omar Sandoval <[email protected]> Signed-off-by: Jens Axboe <[email protected]> commit d9f972644606ecc2581390b43cb5a980b54c04bf Author: Bart Van Assche <[email protected]> Date: Wed May 31 14:43:47 2017 -0700 bsg: Check queue type before attaching to a queue Since BSG only supports request queues for which struct scsi_request is the first member of their private request data, refuse to register block layer queues for which struct scsi_request is not the first member of their private data. References: commit bd1599d931ca ("scsi_transport_sas: fix BSG ioctl memory corruption") References: commit 82ed4db499b8 ("block: split scsi_request out of struct request") Signed-off-by: Bart Van Assche <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Cc: Omar Sandoval <[email protected]> Signed-off-by: Jens Axboe <[email protected]> commit 9efc160f4bbd69b17b48edec53067537d04e62b7 Author: Bart Van Assche <[email protected]> Date: Wed May 31 14:43:46 2017 -0700 block: Introduce queue flag QUEUE_FLAG_SCSI_PASSTHROUGH From the context where a SCSI command is submitted it is not always possible to figure out whether or not the queue the command is submitted to has struct scsi_request as the first member of its private data. Hence introduce the flag QUEUE_FLAG_SCSI_PASSTHROUGH. Signed-off-by: Bart Van Assche <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: Martin K. Petersen <[email protected]> Cc: Omar Sandoval <[email protected]> Cc: Don Brace <[email protected]> Signed-off-by: Jens Axboe <[email protected]> commit 0266f79778de0afadd070941aae493c28529d974 Author: Ido Schimmel <[email protected]> Date: Wed May 31 21:33:42 2017 +0300 mlxsw: spectrum: Add bridge dependency for spectrum When BRIDGE is a loadable module, MLXSW_SPECTRUM mustn't be built-in: drivers/built-in.o: In function `mlxsw_sp_bridge_device_create': drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c:145: undefined reference to `br_vlan_enabled' drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c:158: undefined reference to `br_multicast_enabled' drivers/built-in.o: In function `mlxsw_sp_dev_rif_type': drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:2972: undefined reference to `br_vlan_enabled' drivers/built-in.o: In function `mlxsw_sp_inetaddr_vlan_event': drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:3310: undefined reference to `br_vlan_enabled' Add Kconfig dependency to enforce usable configurations. Fixes: c57529e1d5d8 ("mlxsw: spectrum: Replace vPorts with Port-VLAN") Signed-off-by: Ido Schimmel <[email protected]> Reported-by: Nikolay Aleksandrov <[email protected]> Tested-by: Nikolay Aleksandrov <[email protected]> Cc: Arnd Bergmann <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit edea55abb86ff67afda96120d6254290e7a75d9e Author: Bart Van Assche <[email protected]> Date: Thu Jun 1 08:55:13 2017 -0700 blk-mq-debugfs: Add 'kick' operation Running a queue causes the block layer to examine the per-CPU and hw queues but not the requeue list. Hence add a 'kick' operation that also examines the requeue list. Signed-off-by: Bart Van Assche <[email protected]> Reviewed-by: Ming Lei <[email protected]> Reviewed-by: Eduardo Valentin <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Hannes Reinecke <[email protected]> Cc: Omar Sandoval <[email protected]> Signed-off-by: Jens Axboe <[email protected]> commit 2720bab50258782573df0f536681bece11e784f0 Author: Bart Van Assche <[email protected]> Date: Thu Jun 1 08:55:12 2017 -0700 blk-mq-debugfs: Show busy requests Requests that got stuck in a block driver are neither on blk_mq_ctx.rq_list nor on any hw dispatch queue. Make these visible in debugfs through the "busy" attribute. Signed-off-by: Bart Van Assche <[email protected]> Reviewed-by: Eduardo Valentin <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Hannes Reinecke <[email protected]> Cc: Omar Sandoval <[email protected]> Cc: Ming Lei <[email protected]> Signed-off-by: Jens Axboe <[email protected]> commit 8ef1a191038c138d5675933cd69d47747d0d396b Author: Bart Van Assche <[email protected]> Date: Thu Jun 1 08:55:11 2017 -0700 blk-mq-debugfs: Show requeue list When verifying whether or not a blk-mq driver forgot to kick the requeue list after having requeued a request it is important to be able to verify the contents of the requeue list. Hence export that list through debugfs. Signed-off-by: Bart Van Assche <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]> Reviewed-by: Ming Lei <[email protected]> Reviewed-by: Eduardo Valentin <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Omar Sandoval <[email protected]> Signed-off-by: Jens Axboe <[email protected]> commit c0cb1c6d39060ce04470b10347b7b6f1df77bef5 Author: Bart Van Assche <[email protected]> Date: Thu Jun 1 08:55:10 2017 -0700 blk-mq-debugfs: Show atomic request flags When analyzing e.g. queue lockups it is important to know whether or not a request has already been started. Hence also show the atomic request flags. Signed-off-by: Bart Van Assche <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]> Reviewed-by: Ming Lei <[email protected]> Reviewed-by: Eduardo Valentin <[email protected]> Cc: Omar Sandoval <[email protected]> Cc: Christoph Hellwig <[email protected]> Signed-off-by: Jens Axboe <[email protected]> commit 79e498a9c7da0737829ff864aae44df434105676 Author: Leonard Crestez <[email protected]> Date: Wed May 31 13:29:30 2017 +0300 net: phy: micrel: Restore led_mode and clk_sel on resume These bits seem to be lost after a suspend/resume cycle so just set them again. Do this by splitting the handling of these bits into a function that is also called on resume. This patch fixes ethernet suspend/resume on imx6ul-14x14-evk boards. Signed-off-by: Leonard Crestez <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit e6f4292ae0a1e73fae26ced57de13a48f71ad1fa Author: Leonard Crestez <[email protected]> Date: Wed May 31 13:29:29 2017 +0300 ARM: dts: imx6ul-14x14-evk: Add ksz8081 phy properties Right now mach-imx6ul registers a fixup for the ksz8081 phy. The same register values can be set through the micrel phy driver by using dts properties. This seems preferable and allows cleanly fixing suspend/resume. Signed-off-by: Leonard Crestez <[email protected]> Reviewed-by: Fabio Estevam <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 2428fd0fe5508f5d8599d70cd6f650e19e835b5a Author: LABBE Corentin <[email protected]> Date: Wed May 31 09:18:52 2017 +0200 arm64: defconfig: Enable dwmac-sun8i driver on defconfig Enable the dwmac-sun8i ethernet driver as a module in the ARM64 defconfig. Signed-off-by: Corentin Labbe <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 5209324407477f5dbe2ad6def17584e80b7faa91 Author: LABBE Corentin <[email protected]> Date: Wed May 31 09:18:51 2017 +0200 arm: multi_v7: Enable dwmac-sun8i driver on multi_v7_defconfig Enable the dwmac-sun8i driver in the multi_v7 default configuration Signed-off-by: Corentin Labbe <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit b97a96848011322f7ce24c7a4dce5c0066846e56 Author: LABBE Corentin <[email protected]> Date: Wed May 31 09:18:50 2017 +0200 arm: sunxi: Enable dwmac-sun8i driver on sunxi_defconfig Enable the dwmac-sun8i driver in the sunxi default configuration Signed-off-by: Corentin Labbe <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 67e29b4240e305c687b43de908c51f842ce1b507 Author: LABBE Corentin <[email protected]> Date: Wed May 31 09:18:49 2017 +0200 arm64: allwinner: bananapi-m64: Enable dwmac-sun8i The dwmac-sun8i hardware is present on the BananaPi M64. It uses an external PHY rtl8211e via RGMII. Signed-off-by: Corentin Labbe <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 72aa5f0fd198569be85c843bbbf6ec4a06553910 Author: LABBE Corentin <[email protected]> Date: Wed May 31 09:18:48 2017 +0200 arm64: allwinner: pine64-plus: Enable dwmac-sun8i The dwmac-sun8i hardware is present on the pine64 plus. It uses an external PHY rtl8211e via RGMII. Signed-off-by: Corentin Labbe <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 93264150b017ae1d3edbae883d0df6962d859180 Author: LABBE Corentin <[email protected]> Date: Wed May 31 09:18:47 2017 +0200 arm64: allwinner: pine64: Enable dwmac-sun8i The dwmac-sun8i hardware is present on the pine64 It uses an external PHY via RMII. Signed-off-by: Corentin Labbe <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 103aefa01c1ba7528a6035658dcf43f85409115d Author: LABBE Corentin <[email protected]> Date: Wed May 31 09:18:46 2017 +0200 arm64: allwinner: sun50i-a64: add dwmac-sun8i Ethernet driver The dwmac-sun8i is an Ethernet MAC that supports 10/100/1000 Mbit connections. It is very similar to the device found in the Allwinner H3, but lacks the internal 100 Mbit PHY and its associated control bits. This adds the necessary bits to the Allwinner A64 SoC .dtsi, but keeps it disabled at this level. Signed-off-by: Corentin Labbe <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit b89acf34c6427104b63cdc2be9300c80540728ed Author: LABBE Corentin <[email protected]> Date: Wed May 31 09:18:45 2017 +0200 arm64: allwinner: sun50i-a64: Add dt node for the syscon control module This patch add the dt node for the syscon register present on the Allwinner A64. Only two register are present in this syscon and the only one useful is the one dedicated to EMAC clock. Signed-off-by: Corentin Labbe <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 6f9461d6a489b3e9884a7a4eb9df6f20ad7c5857 Author: LABBE Corentin <[email protected]> Date: Wed May 31 09:18:44 2017 +0200 arm: sun8i: nanopi-neo: Enable dwmac-sun8i The dwmac-sun8i hardware is present on the NanoPi Neo. It uses the internal PHY. This patch create the needed emac node. Signed-off-by: Corentin Labbe <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 29eb9d2984402db5e303c476c8efa8a2f587196b Author: LABBE Corentin <[email protected]> Date: Wed May 31 09:18:43 2017 +0200 arm: sun8i: orangepi-pc-plus: Set EMAC activity LEDs to active high On the Orange Pi PC Plus, the polarity of the LEDs on the RJ45 Ethernet port were changed from active low to active high. Signed-off-by: Chen-Yu Tsai <[email protected]> Signed-off-by: Corentin Labbe <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 0d38218c4d84ec1a975195cf45eeda0fae6b0c0a Author: LABBE Corentin <[email protected]> Date: Wed May 31 09:18:42 2017 +0200 arm: sun8i: orangepi-2: Enable dwmac-sun8i The dwmac-sun8i hardware is present on the Orange PI 2. It uses the internal PHY. This patch create the needed emac node. Signed-off-by: Corentin Labbe <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit bec8f59b740d8e4f6c7fa868487f795a5897b09a Author: LABBE Corentin <[email protected]> Date: Wed May 31 09:18:41 2017 +0200 arm: sun8i: orangepi-one: Enable dwmac-sun8i The dwmac-sun8i hardware is present on the Orange PI One. It uses the internal PHY. This patch create the needed emac node. Signed-off-by: Corentin Labbe <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 0e4da3444597a737e26d296d782227674effc5b7 Author: LABBE Corentin <[email protected]> Date: Wed May 31 09:18:40 2017 +0200 arm: sun8i: orangepi-zero: Enable dwmac-sun8i The dwmac-sun8i hardware is present on the Orange PI Zero. It uses the internal PHY. This patch create the needed emac node. Signed-off-by: Corentin Labbe <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 62781b28785d3b21b58152489fea6fe14450eaaf Author: LABBE Corentin <[email protected]> Date: Wed May 31 09:18:39 2017 +0200 arm: sun8i: orangepi-pc: Enable dwmac-sun8i The dwmac-sun8i hardware is present on the Orange PI PC. It uses the internal PHY. This patch create the needed emac node. Signed-off-by: Corentin Labbe <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 33125eaae481ad7da6b281f25b77a7bc91732b25 Author: LABBE Corentin <[email protected]> Date: Wed May 31 09:18:38 2017 +0200 arm: sun8i: sunxi-h3-h5: add dwmac-sun8i ethernet driver The dwmac-sun8i is an ethernet MAC hardware that support 10/100/1000 speed. This patch enable the dwmac-sun8i on Allwinner H3/H5 SoC Device-tree. SoC H3/H5 have an internal PHY, so optionals syscon and ephy are set. Signed-off-by: Corentin Labbe <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 2c0cba482e795ff2cae4729bd1522b289c5b4412 Author: LABBE Corentin <[email protected]> Date: Wed May 31 09:18:37 2017 +0200 arm: sun8i: sunxi-h3-h5: Add dt node for the syscon control module This patch add the dt node for the syscon register present on the Allwinner H3/H5 Only two register are present in this syscon and the only one useful is the one dedicated to EMAC clock.. Signed-off-by: Corentin Labbe <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 9f93ac8d4085f718d3c7c5fedcb98dbdd2287648 Author: LABBE Corentin <[email protected]> Date: Wed May 31 09:18:36 2017 +0200 net-next: stmmac: Add dwmac-sun8i The dwmac-sun8i is a heavy hacked version of stmmac hardware by allwinner. In fact the only common part is the descriptor management and the first register function. Signed-off-by: Corentin Labbe <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit ce5a4ff3c5058a1c934d3416385948a499a62e6f Author: LABBE Corentin <[email protected]> Date: Wed May 31 09:18:35 2017 +0200 dt-bindings: syscon: Add DT bindings documentation for Allwinner syscon This patch adds documentation for Device-Tree bindings for the syscon present in allwinner devices. Signed-off-by: Corentin Labbe <[email protected]> Acked-by: Rob Herring <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 0441bde003bee53a61d7e365562a295f2049ca53 Author: LABBE Corentin <[email protected]> Date: Wed May 31 09:18:34 2017 +0200 dt-bindings: net-next: Add DT bindings documentation for Allwinner dwmac-sun8i This patch adds documentation for Device-Tree bindings for the Allwinner dwmac-sun8i driver. Signed-off-by: Corentin Labbe <[email protected]> Acked-by: Rob Herring <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit ec33d71de7309c50531c2ae0eb178244899e6e46 Author: LABBE Corentin <[email protected]> Date: Wed May 31 09:18:33 2017 +0200 net-next: stmmac: add optional setup function Instead of adding more ifthen logic for adding a new mac_device_info setup function, it is easier to add a function pointer to the function needed. Signed-off-by: Corentin Labbe <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 3874191898675ac34b6d1d94cfe997c570492bbb Author: LABBE Corentin <[email protected]> Date: Wed May 31 09:18:32 2017 +0200 net-next: stmmac: export stmmac_set_mac_addr/stmmac_get_mac_addr Thoses symbol will be needed for the dwmac-sun8i ethernet driver. For letting it to be build as module, they need to be exported. Signed-off-by: Corentin Labbe <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 93818da5eed63fbc17b64080406ea53b86b23309 Author: Jia-Ju Bai <[email protected]> Date: Wed May 31 15:08:25 2017 +0800 mISDN: Fix a sleep-in-atomic bug The driver may sleep under a read spin lock, and the function call path is: send_socklist (acquire the lock by read_lock) skb_copy(GFP_KERNEL) --> may sleep To fix it, the "GFP_KERNEL" is replaced with "GFP_ATOMIC". Signed-off-by: Jia-Ju Bai <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 042cc409349f997d8a04f26829e4a048538a9794 Author: Stephen Rothwell <[email protected]> Date: Wed May 31 15:43:37 2017 +1000 powerpc: use asm-generic/socket.h as much as possible asm-generic/socket.h already has an exception for the differences that powerpc needs, so just include it after defining the differences. Signed-off-by: Stephen Rothwell <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 35cf2845563c1aaa01d27bd34d64795c4ae72700 Author: Lance Richardson <[email protected]> Date: Mon May 29 13:25:57 2017 -0400 vxlan: eliminate cached dst leak After commit 0c1d70af924b ("net: use dst_cache for vxlan device"), cached dst entries could be leaked when more than one remote was present for a given vxlan_fdb entry, causing subsequent netns operations to block indefinitely and "unregister_netdevice: waiting for lo to become free." messages to appear in the kernel log. Fix by properly releasing cached dst and freeing resources in this case. Fixes: 0c1d70af924b ("net: use dst_cache for vxlan device") Signed-off-by: Lance Richardson <[email protected]> Acked-by: Paolo Abeni <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 44225c9c79ae288b5f1668dc5dda7ba9f87995f1 Author: Chris Packham <[email protected]> Date: Thu May 25 11:49:13 2017 +1200 mtd: mchp23k256: switch to mtd_device_register() Use mtd_device_register() instead of mtd_device_parse_register() to eliminate two unused parameters. Signed-off-by: Chris Packham <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Tested-by: Andrew Lunn <[email protected]> Acked-by: Boris Brezillon <[email protected]> Signed-off-by: Brian Norris <[email protected]> commit 4db4d35ebda390b5287d758fdd51b26c24fbc26b Author: Chris Packham <[email protected]> Date: Thu May 25 11:49:12 2017 +1200 mtd: mchp23k256: Add OF device ID table This allows registering of this device via a Device Tree. Signed-off-by: Chris Packham <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Tested-by: Andrew Lunn <[email protected]> Acked-by: Boris Brezillon <[email protected]> Acked-by: Rob Herring <[email protected]> Signed-off-by: Brian Norris <[email protected]> commit cf97825862f0acd7d6bad67da59962e4badc870a Author: Vadim Lomovtsev <[email protected]> Date: Wed May 31 18:51:57 2017 +0300 EDAC, thunderx: Fix a warning during l2c debugfs node creation Compare the number of debugfs entries created by thunderx_create_debugfs_nodes() with the requested number of entries to properly determine whether to print a warning. Signed-off-by: Vadim Lomovtsev <[email protected]> Cc: linux-edac <[email protected]> Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Sergey Temerkhanov <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> commit 1151f838cb626005f4d69bf675dacaaa5ea909d6 Author: Ard Biesheuvel <[email protected]> Date: Fri May 19 16:42:00 2017 +0100 arm64: kernel: restrict /dev/mem read() calls to linear region When running lscpu on an AArch64 system that has SMBIOS version 2.0 tables, it will segfault in the following way: Unable to handle kernel paging request at virtual address ffff8000bfff0000 pgd = ffff8000f9615000 [ffff8000bfff0000] *pgd=0000000000000000 Internal error: Oops: 96000007 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 1284 Comm: lscpu Not tainted 4.11.0-rc3+ #103 Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 task: ffff8000fa78e800 task.stack: ffff8000f9780000 PC is at __arch_copy_to_user+0x90/0x220 LR is at read_mem+0xcc/0x140 This is caused by the fact that lspci issues a read() on /dev/mem at the offset where it expects to find the SMBIOS structure array. However, this region is classified as EFI_RUNTIME_SERVICE_DATA (as per the UEFI spec), and so it is omitted from the linear mapping. So let's restrict /dev/mem read/write access to those areas that are covered by the linear region. Reported-by: Alexander Graf <[email protected]> Fixes: 4dffbfc48d65 ("arm64/efi: mark UEFI reserved regions as MEMBLOCK_NOMAP") Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Will Deacon <[email protected]> commit cae285ea12b54adb99fb758f9edc0333606e4f89 Author: Richard Gong <[email protected]> Date: Thu Jun 1 09:23:59 2017 -0500 dt-bindings: reset: Add reset manager offsets for Stratix10 There are several changes in reset manager offsets from Arria10 to Stratix10. This patch is based on one from Arria10 and adds offset updates for Stratix10 Signed-off-by: Richard Gong <[email protected]> commit ffd526e290f118e634a642314245f416f2aaaba5 Author: Stefan Berger <[email protected]> Date: Thu May 25 18:29:13 2017 -0400 tpm: vtpm_proxy: Suppress error logging when in closed state Suppress the error logging when the core TPM driver sends commands to the VTPM proxy driver and -EPIPE is returned in case the VTPM proxy driver is 'closed' (closed anonymous file descriptor). This error code is only returned by the send function and by tpm_transmit when the VTPM proxy driver is being used. Signed-off-by: Stefan Berger <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Tested-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]> commit 0fde7ad71ee371ede73b3f326e58f9e8d102feb6 Author: David S. Miller <[email protected]> Date: Thu Jun 1 09:42:46 2017 -0700 sparc64: Fix build warnings with gcc 7. arch/sparc/kernel/ds.c: In function ‘register_services’: arch/sparc/kernel/ds.c:912:3: error: ‘strcpy’: writing at least 1 byte into a region of size 0 overflows the destination Reported-by: Anatoly Pugachev <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit aeb073241fe7a2b932e04e20c60e47718332877f Author: Nikolay Aleksandrov <[email protected]> Date: Thu Jun 1 18:07:55 2017 +0300 net: bridge: start hello timer only if device is up When the transition of NO_STP -> KERNEL_STP was fixed by always calling mod_timer in br_stp_start, it introduced a new regression which causes the timer to be armed even when the bridge is down, and since we stop the timers in its ndo_stop() function, they never get disabled if the device is destroyed before it's upped. To reproduce: $ while :; do ip l add br0 type bridge hello_time 100; brctl stp br0 on; ip l del br0; done; CC: Xin Long <[email protected]> CC: Ivan Vecera <[email protected]> CC: Sebastian Ott <[email protected]> Reported-by: Sebastian Ott <[email protected]> Fixes: 6d18c732b95c ("bridge: start hello_timer when enabling KERNEL_STP in br_stp_start") Signed-off-by: Nikolay Aleksandrov <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit ce6ef68f433f2c97e5d2cf35d2b694e17592d350 Author: Yotam Gigi <[email protected]> Date: Thu Jun 1 16:26:46 2017 +0300 mlxsw: spectrum: Implement the ethtool flash_device callback Add callback to the ethtool flash_device op. This callback uses the mlxfw module to flash the new firmware file to the device. As the firmware flash process takes about 20 seconds and ethtool takes the rtnl lock during the flash_device callback, release the rtnl lock at the beginning of the flash process and take it again before leaving the callback. This way, the rtnl is not held during the process. To make sure the device does not get deleted during the flash process, take a reference to it before releasing the rtnl lock. Signed-off-by: Yotam Gigi <[email protected]> Reviewed-by: Ido Schimmel <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 3968d38917eb9bd0cd391265f6c9c538d9b33ffa Author: Mintz, Yuval <[email protected]> Date: Thu Jun 1 15:57:56 2017 +0300 bnx2x: Fix Multi-Cos Apparently multi-cos isn't working for bnx2x quite some time - driver implements ndo_select_queue() to allow queue-selection for FCoE, but the regular L2 flow would cause it to modulo the fallback's result by the number of queues. The fallback would return a queue matching the needed tc [via __skb_tx_hash()], but since the modulo is by the number of TSS queues where number of TCs is not accounted, transmission would always be done by a queue configured into using TC0. Fixes: ada7c19e6d27 ("bnx2x: use XPS if possible for bnx2x_select_queue instead of pure hash") Signed-off-by: Yuval Mintz <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 1ee240e31d4c0a5fd37ebaf064ca1f6cb6adcb6f Author: Mintz, Yuval <[email protected]> Date: Thu Jun 1 15:29:11 2017 +0300 qed: No need to reset SBs on IOV init Since we're resetting the IGU CAM each time we initialize the PF device, there's no need to reset the VF SBs again when initializing IOV. Signed-off-by: Yuval Mintz <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit ebbdcc669c7f9d8632d358a739d814485f8917dc Author: Mintz, Yuval <[email protected]> Date: Thu Jun 1 15:29:10 2017 +0300 qed: Reset IGU CAM to default on init The IGU CAM contains an assocaition between hardware SBs and interrupt lines, and it can be dynamically configured to allow more interrupts in one entity over another, specifically for Re-distibution of SBs between a PF and its child VFs. While we don't yet use this functionality, there are other clients that do and as such its possible the information passed from management firmware during initialization in regard to the possible number of SBs doesn't accurately reflect the current HW configuration. The following changes are going to apply to the driver init sequence: a. PF is going to re-configure all entries belonging to itself and its child VFs in IGU CAM based on the management firmware info regarding the number of SBs that are supposed to exist there. b. PF is going to stop using the SB resource [management firmware provided information] for anything but the initialization. Instead, it would use the live-time counters it maintains for the numbers. Signed-off-by: Yuval Mintz <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 50a207147fceb64ad24c1e08e4a2a75535922e81 Author: Mintz, Yuval <[email protected]> Date: Thu Jun 1 15:29:09 2017 +0300 qed: Hold a single array for SBs A PF today holds 2 different arrays - one holding information about the HW configuration and one holding information about the SBs that are used by the protocol drivers. These arrays aren't really connected - e.g., protocol driver initializing a given SB would not mark the same SB as occupied in the HW shadow array. Move into a single array [at least for PFs] - hold the mapping of the driver-protocol SBs on the HW entry which they configure. Signed-off-by: Yuval Mintz <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 09b6b14749523e3660b72be2ed91b3c0b852f58f Author: Mintz, Yuval <[email protected]> Date: Thu Jun 1 15:29:08 2017 +0300 qed: Provide auxiliary for getting free VF SB IOV code is very intrusive in its manipulation of the status block database. Add a new auxiliary function to allow the PF to find an available unused status block to configure for a specific VF's MSI-x vector. Signed-off-by: Yuval Mintz <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 1ac72433c565c8db38fd1f9db80a73193369e5fc Author: Mintz, Yuval <[email protected]> Date: Thu Jun 1 15:29:07 2017 +0300 qed: Remove assumption on SB order in IGU Current code assumes there's a known layout for SBs in the IGU, where all the SBs of a single entity would be laid in consecutive order of vectors. While the assumption is still kept by management firmware, we already have the necessary information to eliminate it, so no reason to keep it in code. Signed-off-by: Yuval Mintz <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 726fdbe9fa7ebccda1579716f68f8bae6fa9c87a Author: Mintz, Yuval <[email protected]> Date: Thu Jun 1 15:29:06 2017 +0300 qed: Encapsulate interrupt counters in struct We already have an API struct that contains interrupt-related numbers. Use it to encapsulate all information relating to the status of SBs as (used|free). Signed-off-by: Yuval Mintz <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit a333f7f3fd327d736a23c52aafcfe17c75f2610c Author: Mintz, Yuval <[email protected]> Date: Thu Jun 1 15:29:05 2017 +0300 qed: Add aux. function translating sb_id -> igu_sb_id An additional step for relaxing the IGU order assumption, we now add an auxiliary function that can be used for finding the HW status block that's associated with a given MSI-x vector. Signed-off-by: Yuval Mintz <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit d031548e9194714dc2e8cb928d9f671432c8a342 Author: Mintz, Yuval <[email protected]> Date: Thu Jun 1 15:29:04 2017 +0300 qed: Distinguish between sb_id and igu_sb_id In qed code, sb_id means 2 different things: - An interrupt vector [usually when received as a parameter from a protocol driver, but not only] that's associated with a status block. - An index to a status block entity existing in HW. This patch renames the references to the HW entity, adding an 'igu_' prefix to allow an easier distinction. Signed-off-by: Yuval Mintz <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit d749dd0dc117e7b02fa3a169c431476d59d18950 Author: Mintz, Yuval <[email protected]> Date: Thu Jun 1 15:29:03 2017 +0300 qed: IGU read revised As a first step for relaxing various assumptions done by driver about the IGU m…
wzyy2
pushed a commit
to wzyy2/linux
that referenced
this pull request
Jun 19, 2017
(1) use cpu id from bl31 delivers; (2) sp_el0 should point to kernel address in EL1 mode. On ARM64, kernel uses sp_el0 to store current_thread_info(), we see a problem: when fiq occurs, cpu is EL1 mode but sp_el0 point to userspace address. At this moment, if we read 'current_thread_info()->cpu' or other, it leads an error. We find above situation happens when save/restore cpu context between system mode and user mode under heavy load. Like 'ret_fast_syscall()', kernel restore context of user mode, but fiq occurs before the instruction 'eret', so this causes the above situation. Assembly code: ffffff80080826c8 <ret_fast_syscall>: ...skipping... ffffff80080826fc: d503201f nop ffffff8008082700: d5384100 mrs x0, sp_el0 ffffff8008082704: f9400c00 ldr x0, [x0,torvalds#24] ffffff8008082708: d5182000 msr ttbr0_el1, x0 ffffff800808270c: d5033fdf isb ffffff8008082710: f9407ff7 ldr x23, [sp,torvalds#248] ffffff8008082714: d5184117 msr sp_el0, x23 ffffff8008082718: d503201f nop ffffff800808271c: d503201f nop ffffff8008082720: d5184035 msr elr_el1, x21 ffffff8008082724: d5184016 msr spsr_el1, x22 ffffff8008082728: a94007e0 ldp x0, x1, [sp] ffffff800808272c: a9410fe2 ldp x2, x3, [sp,torvalds#16] ffffff8008082730: a94217e4 ldp x4, x5, [sp,torvalds#32] ffffff8008082734: a9431fe6 ldp x6, x7, [sp,torvalds#48] ffffff8008082738: a94427e8 ldp x8, x9, [sp,torvalds#64] ffffff800808273c: a9452fea ldp x10, x11, [sp,torvalds#80] ffffff8008082740: a94637ec ldp x12, x13, [sp,torvalds#96] ffffff8008082744: a9473fee ldp x14, x15, [sp,torvalds#112] ffffff8008082748: a94847f0 ldp x16, x17, [sp,torvalds#128] ffffff800808274c: a9494ff2 ldp x18, x19, [sp,torvalds#144] ffffff8008082750: a94a57f4 ldp x20, x21, [sp,torvalds#160] ffffff8008082754: a94b5ff6 ldp x22, x23, [sp,torvalds#176] ffffff8008082758: a94c67f8 ldp x24, x25, [sp,torvalds#192] ffffff800808275c: a94d6ffa ldp x26, x27, [sp,torvalds#208] ffffff8008082760: a94e77fc ldp x28, x29, [sp,torvalds#224] ffffff8008082764: f9407bfe ldr x30, [sp,torvalds#240] ffffff8008082768: 9104c3ff add sp, sp, #0x130 ffffff800808276c: d69f03e0 eret Change-Id: I071e899f8a407764e166ca0403199c9d87d6ce78 Signed-off-by: chenjh <[email protected]>
vivien
added a commit
to vivien/linux
that referenced
this pull request
Jul 26, 2017
As of a86d8be ("net: dsa: Factor bottom tag receive functions"), the rcv caller frees the original SKB in case or error. Be symmetric with that and make the xmit caller do the same. At the same time, fix the checkpatch NULL comparison check: CHECK: Comparison to NULL could be written "!nskb" torvalds#208: FILE: net/dsa/tag_trailer.c:35: + if (nskb == NULL) Signed-off-by: Vivien Didelot <[email protected]>
torvalds
pushed a commit
that referenced
this pull request
Jul 31, 2018
bpf_parse_prog() is protected by rcu_read_lock(). so that GFP_KERNEL is not allowed in the bpf_parse_prog(). [51015.579396] ============================= [51015.579418] WARNING: suspicious RCU usage [51015.579444] 4.18.0-rc6+ #208 Not tainted [51015.579464] ----------------------------- [51015.579488] ./include/linux/rcupdate.h:303 Illegal context switch in RCU read-side critical section! [51015.579510] other info that might help us debug this: [51015.579532] rcu_scheduler_active = 2, debug_locks = 1 [51015.579556] 2 locks held by ip/1861: [51015.579577] #0: 00000000a8c12fd1 (rtnl_mutex){+.+.}, at: rtnetlink_rcv_msg+0x2e0/0x910 [51015.579711] #1: 00000000bf815f8e (rcu_read_lock){....}, at: lwtunnel_build_state+0x96/0x390 [51015.579842] stack backtrace: [51015.579869] CPU: 0 PID: 1861 Comm: ip Not tainted 4.18.0-rc6+ #208 [51015.579891] Hardware name: To be filled by O.E.M. To be filled by O.E.M./Aptio CRB, BIOS 5.6.5 07/08/2015 [51015.579911] Call Trace: [51015.579950] dump_stack+0x74/0xbb [51015.580000] ___might_sleep+0x16b/0x3a0 [51015.580047] __kmalloc_track_caller+0x220/0x380 [51015.580077] kmemdup+0x1c/0x40 [51015.580077] bpf_parse_prog+0x10e/0x230 [51015.580164] ? kasan_kmalloc+0xa0/0xd0 [51015.580164] ? bpf_destroy_state+0x30/0x30 [51015.580164] ? bpf_build_state+0xe2/0x3e0 [51015.580164] bpf_build_state+0x1bb/0x3e0 [51015.580164] ? bpf_parse_prog+0x230/0x230 [51015.580164] ? lock_is_held_type+0x123/0x1a0 [51015.580164] lwtunnel_build_state+0x1aa/0x390 [51015.580164] fib_create_info+0x1579/0x33d0 [51015.580164] ? sched_clock_local+0xe2/0x150 [51015.580164] ? fib_info_update_nh_saddr+0x1f0/0x1f0 [51015.580164] ? sched_clock_local+0xe2/0x150 [51015.580164] fib_table_insert+0x201/0x1990 [51015.580164] ? lock_downgrade+0x610/0x610 [51015.580164] ? fib_table_lookup+0x1920/0x1920 [51015.580164] ? lwtunnel_valid_encap_type.part.6+0xcb/0x3a0 [51015.580164] ? rtm_to_fib_config+0x637/0xbd0 [51015.580164] inet_rtm_newroute+0xed/0x1b0 [51015.580164] ? rtm_to_fib_config+0xbd0/0xbd0 [51015.580164] rtnetlink_rcv_msg+0x331/0x910 [ ... ] Fixes: 3a0af8f ("bpf: BPF for lightweight tunnel infrastructure") Signed-off-by: Taehee Yoo <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Feb 4, 2019
Fix the following checkpatch.pl warning: WARNING: Statements should start on a tabstop torvalds#208: FILE: pci.h:208: + /*ASPM*/ u8 const_pci_aspm; Signed-off-by: Felipe Cardoso Resende <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
krzk
pushed a commit
to krzk/linux
that referenced
this pull request
Feb 21, 2019
There are a number of CamelCase variables remaining in the source files of modules rtl_pci, rtl_usb, and rtlwifi. The following checkpatch excettions are also fixed: for_kalle1/0001-rtlwifi-Remove-CamelCase-variables-from-base-code.patch ----------------------------------------------------------------------- CHECK: Unnecessary parentheses around 'rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i] != rtlefuse->efuse_map[EFUSE_MODIFY_MAP][base + i]' torvalds#68: FILE: drivers/net/wireless/realtek/rtlwifi/efuse.c:377: + if ((rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i] != + rtlefuse->efuse_map[EFUSE_MODIFY_MAP][base + i]) || + (rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i + 1] != + rtlefuse->efuse_map[EFUSE_MODIFY_MAP][base + i + 1])) { CHECK: Unnecessary parentheses around 'rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i + 1] != rtlefuse->efuse_map[EFUSE_MODIFY_MAP][base + i + 1]' torvalds#68: FILE: drivers/net/wireless/realtek/rtlwifi/efuse.c:377: + if ((rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i] != + rtlefuse->efuse_map[EFUSE_MODIFY_MAP][base + i]) || + (rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i + 1] != + rtlefuse->efuse_map[EFUSE_MODIFY_MAP][base + i + 1])) { WARNING: line over 80 characters #70: FILE: drivers/net/wireless/realtek/rtlwifi/efuse.c:379: + (rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i + 1] != CHECK: No space is necessary after a cast torvalds#186: FILE: drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c:396: + status->rx_is40mhzpacket = (bool) GET_RX_DESC_BW(pdesc); CHECK: No space is necessary after a cast torvalds#208: FILE: drivers/net/wireless/realtek/rtlwifi/rtl8192ce/trx.c:335: + stats->rx_is40mhzpacket = (bool) GET_RX_DESC_BW(pdesc); CHECK: No space is necessary after a cast torvalds#243: FILE: drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c:301: + stats->rx_is40mhzpacket = (bool) GET_RX_DESC_BW(pdesc); CHECK: No space is necessary after a cast torvalds#252: FILE: drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c:368: + stats.rx_is40mhzpacket = (bool) GET_RX_DESC_BW(rxdesc); CHECK: No space is necessary after a cast torvalds#265: FILE: drivers/net/wireless/realtek/rtlwifi/rtl8192de/trx.c:475: + stats->rx_is40mhzpacket = (bool) GET_RX_DESC_BW(pdesc); WARNING: Unnecessary space before function pointer arguments torvalds#455: FILE: drivers/net/wireless/realtek/rtlwifi/wifi.h:1462: + void (*writen_sync) (struct rtl_priv *rtlpriv, u32 addr, void *buf, WARNING: Unnecessary space before function pointer arguments torvalds#483: FILE: drivers/net/wireless/realtek/rtlwifi/wifi.h:2257: + void (*fill_fake_txdesc) (struct ieee80211_hw *hw, u8 *pdesc, Note that not all checkpatch exceptions are addressed. Those will be handled in later patches. Signed-off-by: Larry Finger <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Mar 6, 2019
There are a number of CamelCase variables remaining in the source files of modules rtl_pci, rtl_usb, and rtlwifi. The following checkpatch excettions are also fixed: for_kalle1/0001-rtlwifi-Remove-CamelCase-variables-from-base-code.patch ----------------------------------------------------------------------- CHECK: Unnecessary parentheses around 'rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i] != rtlefuse->efuse_map[EFUSE_MODIFY_MAP][base + i]' torvalds#68: FILE: drivers/net/wireless/realtek/rtlwifi/efuse.c:377: + if ((rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i] != + rtlefuse->efuse_map[EFUSE_MODIFY_MAP][base + i]) || + (rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i + 1] != + rtlefuse->efuse_map[EFUSE_MODIFY_MAP][base + i + 1])) { CHECK: Unnecessary parentheses around 'rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i + 1] != rtlefuse->efuse_map[EFUSE_MODIFY_MAP][base + i + 1]' torvalds#68: FILE: drivers/net/wireless/realtek/rtlwifi/efuse.c:377: + if ((rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i] != + rtlefuse->efuse_map[EFUSE_MODIFY_MAP][base + i]) || + (rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i + 1] != + rtlefuse->efuse_map[EFUSE_MODIFY_MAP][base + i + 1])) { WARNING: line over 80 characters #70: FILE: drivers/net/wireless/realtek/rtlwifi/efuse.c:379: + (rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i + 1] != CHECK: No space is necessary after a cast torvalds#186: FILE: drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c:396: + status->rx_is40mhzpacket = (bool) GET_RX_DESC_BW(pdesc); CHECK: No space is necessary after a cast torvalds#208: FILE: drivers/net/wireless/realtek/rtlwifi/rtl8192ce/trx.c:335: + stats->rx_is40mhzpacket = (bool) GET_RX_DESC_BW(pdesc); CHECK: No space is necessary after a cast torvalds#243: FILE: drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c:301: + stats->rx_is40mhzpacket = (bool) GET_RX_DESC_BW(pdesc); CHECK: No space is necessary after a cast torvalds#252: FILE: drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c:368: + stats.rx_is40mhzpacket = (bool) GET_RX_DESC_BW(rxdesc); CHECK: No space is necessary after a cast torvalds#265: FILE: drivers/net/wireless/realtek/rtlwifi/rtl8192de/trx.c:475: + stats->rx_is40mhzpacket = (bool) GET_RX_DESC_BW(pdesc); WARNING: Unnecessary space before function pointer arguments torvalds#455: FILE: drivers/net/wireless/realtek/rtlwifi/wifi.h:1462: + void (*writen_sync) (struct rtl_priv *rtlpriv, u32 addr, void *buf, WARNING: Unnecessary space before function pointer arguments torvalds#483: FILE: drivers/net/wireless/realtek/rtlwifi/wifi.h:2257: + void (*fill_fake_txdesc) (struct ieee80211_hw *hw, u8 *pdesc, Note that not all checkpatch exceptions are addressed. Those will be handled in later patches. Signed-off-by: Larry Finger <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Dec 20, 2019
Inspired by btrfs-progs github issue torvalds#208, where chunk item in chunk tree has invalid num_stripes (0). Although that can already be catched by current btrfs_check_chunk_valid(), that function doesn't really check item size as it needs to handle chunk item in super block sys_chunk_array(). This patch will just add two extra checks for chunk items in chunk tree: - Basic chunk item size If the item is smaller than btrfs_chunk (which already contains one stripe), exit right now as reading num_stripes may even go beyond eb boundary. - Item size check against num_stripes If item size doesn't match with calculated chunk size, then either the item size or the num_stripes is corrupted. Error out anyway. Signed-off-by: Qu Wenruo <[email protected]>
kdave
pushed a commit
to kdave/btrfs-devel
that referenced
this pull request
Jan 2, 2020
Inspired by btrfs-progs github issue torvalds#208, where chunk item in chunk tree has invalid num_stripes (0). Although that can already be caught by current btrfs_check_chunk_valid(), that function doesn't really check item size as it needs to handle chunk item in super block sys_chunk_array(). This patch will add two extra checks for chunk items in chunk tree: - Basic chunk item size If the item is smaller than btrfs_chunk (which already contains one stripe), exit right now as reading num_stripes may even go beyond eb boundary. - Item size check against num_stripes If item size doesn't match with calculated chunk size, then either the item size or the num_stripes is corrupted. Error out anyway. Reviewed-by: Josef Bacik <[email protected]> Signed-off-by: Qu Wenruo <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]>
kdave
pushed a commit
to kdave/btrfs-devel
that referenced
this pull request
Jan 2, 2020
Inspired by btrfs-progs github issue torvalds#208, where chunk item in chunk tree has invalid num_stripes (0). Although that can already be caught by current btrfs_check_chunk_valid(), that function doesn't really check item size as it needs to handle chunk item in super block sys_chunk_array(). This patch will add two extra checks for chunk items in chunk tree: - Basic chunk item size If the item is smaller than btrfs_chunk (which already contains one stripe), exit right now as reading num_stripes may even go beyond eb boundary. - Item size check against num_stripes If item size doesn't match with calculated chunk size, then either the item size or the num_stripes is corrupted. Error out anyway. Reviewed-by: Josef Bacik <[email protected]> Signed-off-by: Qu Wenruo <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]>
kdave
pushed a commit
to kdave/btrfs-devel
that referenced
this pull request
Jan 6, 2020
Inspired by btrfs-progs github issue torvalds#208, where chunk item in chunk tree has invalid num_stripes (0). Although that can already be caught by current btrfs_check_chunk_valid(), that function doesn't really check item size as it needs to handle chunk item in super block sys_chunk_array(). This patch will add two extra checks for chunk items in chunk tree: - Basic chunk item size If the item is smaller than btrfs_chunk (which already contains one stripe), exit right now as reading num_stripes may even go beyond eb boundary. - Item size check against num_stripes If item size doesn't match with calculated chunk size, then either the item size or the num_stripes is corrupted. Error out anyway. Reviewed-by: Josef Bacik <[email protected]> Signed-off-by: Qu Wenruo <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]>
kdave
pushed a commit
to kdave/btrfs-devel
that referenced
this pull request
Jan 9, 2020
Inspired by btrfs-progs github issue torvalds#208, where chunk item in chunk tree has invalid num_stripes (0). Although that can already be caught by current btrfs_check_chunk_valid(), that function doesn't really check item size as it needs to handle chunk item in super block sys_chunk_array(). This patch will add two extra checks for chunk items in chunk tree: - Basic chunk item size If the item is smaller than btrfs_chunk (which already contains one stripe), exit right now as reading num_stripes may even go beyond eb boundary. - Item size check against num_stripes If item size doesn't match with calculated chunk size, then either the item size or the num_stripes is corrupted. Error out anyway. Reviewed-by: Josef Bacik <[email protected]> Signed-off-by: Qu Wenruo <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]>
kdave
pushed a commit
to kdave/btrfs-devel
that referenced
this pull request
Jan 10, 2020
Inspired by btrfs-progs github issue torvalds#208, where chunk item in chunk tree has invalid num_stripes (0). Although that can already be caught by current btrfs_check_chunk_valid(), that function doesn't really check item size as it needs to handle chunk item in super block sys_chunk_array(). This patch will add two extra checks for chunk items in chunk tree: - Basic chunk item size If the item is smaller than btrfs_chunk (which already contains one stripe), exit right now as reading num_stripes may even go beyond eb boundary. - Item size check against num_stripes If item size doesn't match with calculated chunk size, then either the item size or the num_stripes is corrupted. Error out anyway. Reviewed-by: Josef Bacik <[email protected]> Signed-off-by: Qu Wenruo <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]>
kdave
pushed a commit
to kdave/btrfs-devel
that referenced
this pull request
Jan 13, 2020
Inspired by btrfs-progs github issue torvalds#208, where chunk item in chunk tree has invalid num_stripes (0). Although that can already be caught by current btrfs_check_chunk_valid(), that function doesn't really check item size as it needs to handle chunk item in super block sys_chunk_array(). This patch will add two extra checks for chunk items in chunk tree: - Basic chunk item size If the item is smaller than btrfs_chunk (which already contains one stripe), exit right now as reading num_stripes may even go beyond eb boundary. - Item size check against num_stripes If item size doesn't match with calculated chunk size, then either the item size or the num_stripes is corrupted. Error out anyway. Reviewed-by: Josef Bacik <[email protected]> Signed-off-by: Qu Wenruo <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]>
kdave
pushed a commit
to kdave/btrfs-devel
that referenced
this pull request
Jan 13, 2020
Inspired by btrfs-progs github issue torvalds#208, where chunk item in chunk tree has invalid num_stripes (0). Although that can already be caught by current btrfs_check_chunk_valid(), that function doesn't really check item size as it needs to handle chunk item in super block sys_chunk_array(). This patch will add two extra checks for chunk items in chunk tree: - Basic chunk item size If the item is smaller than btrfs_chunk (which already contains one stripe), exit right now as reading num_stripes may even go beyond eb boundary. - Item size check against num_stripes If item size doesn't match with calculated chunk size, then either the item size or the num_stripes is corrupted. Error out anyway. Reviewed-by: Josef Bacik <[email protected]> Signed-off-by: Qu Wenruo <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]>
kdave
pushed a commit
to kdave/btrfs-devel
that referenced
this pull request
Jan 15, 2020
Inspired by btrfs-progs github issue torvalds#208, where chunk item in chunk tree has invalid num_stripes (0). Although that can already be caught by current btrfs_check_chunk_valid(), that function doesn't really check item size as it needs to handle chunk item in super block sys_chunk_array(). This patch will add two extra checks for chunk items in chunk tree: - Basic chunk item size If the item is smaller than btrfs_chunk (which already contains one stripe), exit right now as reading num_stripes may even go beyond eb boundary. - Item size check against num_stripes If item size doesn't match with calculated chunk size, then either the item size or the num_stripes is corrupted. Error out anyway. Reviewed-by: Josef Bacik <[email protected]> Signed-off-by: Qu Wenruo <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]>
kdave
pushed a commit
to kdave/btrfs-devel
that referenced
this pull request
Jan 21, 2020
Inspired by btrfs-progs github issue torvalds#208, where chunk item in chunk tree has invalid num_stripes (0). Although that can already be caught by current btrfs_check_chunk_valid(), that function doesn't really check item size as it needs to handle chunk item in super block sys_chunk_array(). This patch will add two extra checks for chunk items in chunk tree: - Basic chunk item size If the item is smaller than btrfs_chunk (which already contains one stripe), exit right now as reading num_stripes may even go beyond eb boundary. - Item size check against num_stripes If item size doesn't match with calculated chunk size, then either the item size or the num_stripes is corrupted. Error out anyway. Reviewed-by: Josef Bacik <[email protected]> Signed-off-by: Qu Wenruo <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jul 14, 2020
…arnings Since commit 845e0eb ("net: change addr_list_lock back to static key"), cascaded DSA setups (DSA switch port as DSA master for another DSA switch port) are emitting this lockdep warning: ============================================ WARNING: possible recursive locking detected 5.8.0-rc1-00133-g923e4b5032dd-dirty torvalds#208 Not tainted -------------------------------------------- dhcpcd/323 is trying to acquire lock: ffff000066dd4268 (&dsa_master_addr_list_lock_key/1){+...}-{2:2}, at: dev_mc_sync+0x44/0x90 but task is already holding lock: ffff00006608c268 (&dsa_master_addr_list_lock_key/1){+...}-{2:2}, at: dev_mc_sync+0x44/0x90 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&dsa_master_addr_list_lock_key/1); lock(&dsa_master_addr_list_lock_key/1); *** DEADLOCK *** May be due to missing lock nesting notation 3 locks held by dhcpcd/323: #0: ffffdbd1381dda18 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_lock+0x24/0x30 #1: ffff00006614b268 (_xmit_ETHER){+...}-{2:2}, at: dev_set_rx_mode+0x28/0x48 #2: ffff00006608c268 (&dsa_master_addr_list_lock_key/1){+...}-{2:2}, at: dev_mc_sync+0x44/0x90 stack backtrace: Call trace: dump_backtrace+0x0/0x1e0 show_stack+0x20/0x30 dump_stack+0xec/0x158 __lock_acquire+0xca0/0x2398 lock_acquire+0xe8/0x440 _raw_spin_lock_nested+0x64/0x90 dev_mc_sync+0x44/0x90 dsa_slave_set_rx_mode+0x34/0x50 __dev_set_rx_mode+0x60/0xa0 dev_mc_sync+0x84/0x90 dsa_slave_set_rx_mode+0x34/0x50 __dev_set_rx_mode+0x60/0xa0 dev_set_rx_mode+0x30/0x48 __dev_open+0x10c/0x180 __dev_change_flags+0x170/0x1c8 dev_change_flags+0x2c/0x70 devinet_ioctl+0x774/0x878 inet_ioctl+0x348/0x3b0 sock_do_ioctl+0x50/0x310 sock_ioctl+0x1f8/0x580 ksys_ioctl+0xb0/0xf0 __arm64_sys_ioctl+0x28/0x38 el0_svc_common.constprop.0+0x7c/0x180 do_el0_svc+0x2c/0x98 el0_sync_handler+0x9c/0x1b8 el0_sync+0x158/0x180 Since DSA never made use of the netdev API for describing links between upper devices and lower devices, the dev->lower_level value of a DSA switch interface would be 1, which would warn when it is a DSA master. We can use netdev_upper_dev_link() to describe the relationship between a DSA slave and a DSA master. To be precise, a DSA "slave" (switch port) is an "upper" to a DSA "master" (host port). The relationship is "many uppers to one lower", like in the case of VLAN. So, for that reason, we use the same function as VLAN uses. Since this warning was not there when lockdep was using dynamic keys for addr_list_lock, we are blaming the lockdep patch itself. The network stack _has_ been using static lockdep keys before, and it _is_ likely that stacked DSA setups have been triggering these lockdep warnings since forever, however I can't test very old kernels on this particular stacked DSA setup, to ensure I'm not in fact introducing regressions. Fixes: 845e0eb ("net: change addr_list_lock back to static key") Suggested-by: Cong Wang <[email protected]> Signed-off-by: Vladimir Oltean <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Sep 8, 2020
…arnings Since commit 845e0eb ("net: change addr_list_lock back to static key"), cascaded DSA setups (DSA switch port as DSA master for another DSA switch port) are emitting this lockdep warning: ============================================ WARNING: possible recursive locking detected 5.8.0-rc1-00133-g923e4b5032dd-dirty torvalds#208 Not tainted -------------------------------------------- dhcpcd/323 is trying to acquire lock: ffff000066dd4268 (&dsa_master_addr_list_lock_key/1){+...}-{2:2}, at: dev_mc_sync+0x44/0x90 but task is already holding lock: ffff00006608c268 (&dsa_master_addr_list_lock_key/1){+...}-{2:2}, at: dev_mc_sync+0x44/0x90 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&dsa_master_addr_list_lock_key/1); lock(&dsa_master_addr_list_lock_key/1); *** DEADLOCK *** May be due to missing lock nesting notation 3 locks held by dhcpcd/323: #0: ffffdbd1381dda18 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_lock+0x24/0x30 #1: ffff00006614b268 (_xmit_ETHER){+...}-{2:2}, at: dev_set_rx_mode+0x28/0x48 #2: ffff00006608c268 (&dsa_master_addr_list_lock_key/1){+...}-{2:2}, at: dev_mc_sync+0x44/0x90 stack backtrace: Call trace: dump_backtrace+0x0/0x1e0 show_stack+0x20/0x30 dump_stack+0xec/0x158 __lock_acquire+0xca0/0x2398 lock_acquire+0xe8/0x440 _raw_spin_lock_nested+0x64/0x90 dev_mc_sync+0x44/0x90 dsa_slave_set_rx_mode+0x34/0x50 __dev_set_rx_mode+0x60/0xa0 dev_mc_sync+0x84/0x90 dsa_slave_set_rx_mode+0x34/0x50 __dev_set_rx_mode+0x60/0xa0 dev_set_rx_mode+0x30/0x48 __dev_open+0x10c/0x180 __dev_change_flags+0x170/0x1c8 dev_change_flags+0x2c/0x70 devinet_ioctl+0x774/0x878 inet_ioctl+0x348/0x3b0 sock_do_ioctl+0x50/0x310 sock_ioctl+0x1f8/0x580 ksys_ioctl+0xb0/0xf0 __arm64_sys_ioctl+0x28/0x38 el0_svc_common.constprop.0+0x7c/0x180 do_el0_svc+0x2c/0x98 el0_sync_handler+0x9c/0x1b8 el0_sync+0x158/0x180 Since DSA never made use of the netdev API for describing links between upper devices and lower devices, the dev->lower_level value of a DSA switch interface would be 1, which would warn when it is a DSA master. We can use netdev_upper_dev_link() to describe the relationship between a DSA slave and a DSA master. To be precise, a DSA "slave" (switch port) is an "upper" to a DSA "master" (host port). The relationship is "many uppers to one lower", like in the case of VLAN. So, for that reason, we use the same function as VLAN uses. There might be a chance that somebody will try to take hold of this interface and use it immediately after register_netdev() and before netdev_upper_dev_link(). To avoid that, we do the registration and linkage while holding the RTNL, and we use the RTNL-locked cousin of register_netdev(), which is register_netdevice(). Since this warning was not there when lockdep was using dynamic keys for addr_list_lock, we are blaming the lockdep patch itself. The network stack _has_ been using static lockdep keys before, and it _is_ likely that stacked DSA setups have been triggering these lockdep warnings since forever, however I can't test very old kernels on this particular stacked DSA setup, to ensure I'm not in fact introducing regressions. Fixes: 845e0eb ("net: change addr_list_lock back to static key") Suggested-by: Cong Wang <[email protected]> Signed-off-by: Vladimir Oltean <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Sep 9, 2020
…arnings Since commit 845e0eb ("net: change addr_list_lock back to static key"), cascaded DSA setups (DSA switch port as DSA master for another DSA switch port) are emitting this lockdep warning: ============================================ WARNING: possible recursive locking detected 5.8.0-rc1-00133-g923e4b5032dd-dirty torvalds#208 Not tainted -------------------------------------------- dhcpcd/323 is trying to acquire lock: ffff000066dd4268 (&dsa_master_addr_list_lock_key/1){+...}-{2:2}, at: dev_mc_sync+0x44/0x90 but task is already holding lock: ffff00006608c268 (&dsa_master_addr_list_lock_key/1){+...}-{2:2}, at: dev_mc_sync+0x44/0x90 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&dsa_master_addr_list_lock_key/1); lock(&dsa_master_addr_list_lock_key/1); *** DEADLOCK *** May be due to missing lock nesting notation 3 locks held by dhcpcd/323: #0: ffffdbd1381dda18 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_lock+0x24/0x30 #1: ffff00006614b268 (_xmit_ETHER){+...}-{2:2}, at: dev_set_rx_mode+0x28/0x48 #2: ffff00006608c268 (&dsa_master_addr_list_lock_key/1){+...}-{2:2}, at: dev_mc_sync+0x44/0x90 stack backtrace: Call trace: dump_backtrace+0x0/0x1e0 show_stack+0x20/0x30 dump_stack+0xec/0x158 __lock_acquire+0xca0/0x2398 lock_acquire+0xe8/0x440 _raw_spin_lock_nested+0x64/0x90 dev_mc_sync+0x44/0x90 dsa_slave_set_rx_mode+0x34/0x50 __dev_set_rx_mode+0x60/0xa0 dev_mc_sync+0x84/0x90 dsa_slave_set_rx_mode+0x34/0x50 __dev_set_rx_mode+0x60/0xa0 dev_set_rx_mode+0x30/0x48 __dev_open+0x10c/0x180 __dev_change_flags+0x170/0x1c8 dev_change_flags+0x2c/0x70 devinet_ioctl+0x774/0x878 inet_ioctl+0x348/0x3b0 sock_do_ioctl+0x50/0x310 sock_ioctl+0x1f8/0x580 ksys_ioctl+0xb0/0xf0 __arm64_sys_ioctl+0x28/0x38 el0_svc_common.constprop.0+0x7c/0x180 do_el0_svc+0x2c/0x98 el0_sync_handler+0x9c/0x1b8 el0_sync+0x158/0x180 Since DSA never made use of the netdev API for describing links between upper devices and lower devices, the dev->lower_level value of a DSA switch interface would be 1, which would warn when it is a DSA master. We can use netdev_upper_dev_link() to describe the relationship between a DSA slave and a DSA master. To be precise, a DSA "slave" (switch port) is an "upper" to a DSA "master" (host port). The relationship is "many uppers to one lower", like in the case of VLAN. So, for that reason, we use the same function as VLAN uses. There might be a chance that somebody will try to take hold of this interface and use it immediately after register_netdev() and before netdev_upper_dev_link(). To avoid that, we do the registration and linkage while holding the RTNL, and we use the RTNL-locked cousin of register_netdev(), which is register_netdevice(). Since this warning was not there when lockdep was using dynamic keys for addr_list_lock, we are blaming the lockdep patch itself. The network stack _has_ been using static lockdep keys before, and it _is_ likely that stacked DSA setups have been triggering these lockdep warnings since forever, however I can't test very old kernels on this particular stacked DSA setup, to ensure I'm not in fact introducing regressions. Fixes: 845e0eb ("net: change addr_list_lock back to static key") Suggested-by: Cong Wang <[email protected]> Signed-off-by: Vladimir Oltean <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Noltari
pushed a commit
to Noltari/linux
that referenced
this pull request
Oct 1, 2020
[ Upstream commit f6d2a5c ] Inspired by btrfs-progs github issue torvalds#208, where chunk item in chunk tree has invalid num_stripes (0). Although that can already be caught by current btrfs_check_chunk_valid(), that function doesn't really check item size as it needs to handle chunk item in super block sys_chunk_array(). This patch will add two extra checks for chunk items in chunk tree: - Basic chunk item size If the item is smaller than btrfs_chunk (which already contains one stripe), exit right now as reading num_stripes may even go beyond eb boundary. - Item size check against num_stripes If item size doesn't match with calculated chunk size, then either the item size or the num_stripes is corrupted. Error out anyway. Reviewed-by: Josef Bacik <[email protected]> Signed-off-by: Qu Wenruo <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
jackpot51
pushed a commit
to pop-os/linux
that referenced
this pull request
Oct 19, 2020
…arnings BugLink: https://bugs.launchpad.net/bugs/1897550 [ Upstream commit 2f1e8ea ] Since commit 845e0eb ("net: change addr_list_lock back to static key"), cascaded DSA setups (DSA switch port as DSA master for another DSA switch port) are emitting this lockdep warning: ============================================ WARNING: possible recursive locking detected 5.8.0-rc1-00133-g923e4b5032dd-dirty torvalds#208 Not tainted -------------------------------------------- dhcpcd/323 is trying to acquire lock: ffff000066dd4268 (&dsa_master_addr_list_lock_key/1){+...}-{2:2}, at: dev_mc_sync+0x44/0x90 but task is already holding lock: ffff00006608c268 (&dsa_master_addr_list_lock_key/1){+...}-{2:2}, at: dev_mc_sync+0x44/0x90 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&dsa_master_addr_list_lock_key/1); lock(&dsa_master_addr_list_lock_key/1); *** DEADLOCK *** May be due to missing lock nesting notation 3 locks held by dhcpcd/323: #0: ffffdbd1381dda18 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_lock+0x24/0x30 #1: ffff00006614b268 (_xmit_ETHER){+...}-{2:2}, at: dev_set_rx_mode+0x28/0x48 #2: ffff00006608c268 (&dsa_master_addr_list_lock_key/1){+...}-{2:2}, at: dev_mc_sync+0x44/0x90 stack backtrace: Call trace: dump_backtrace+0x0/0x1e0 show_stack+0x20/0x30 dump_stack+0xec/0x158 __lock_acquire+0xca0/0x2398 lock_acquire+0xe8/0x440 _raw_spin_lock_nested+0x64/0x90 dev_mc_sync+0x44/0x90 dsa_slave_set_rx_mode+0x34/0x50 __dev_set_rx_mode+0x60/0xa0 dev_mc_sync+0x84/0x90 dsa_slave_set_rx_mode+0x34/0x50 __dev_set_rx_mode+0x60/0xa0 dev_set_rx_mode+0x30/0x48 __dev_open+0x10c/0x180 __dev_change_flags+0x170/0x1c8 dev_change_flags+0x2c/0x70 devinet_ioctl+0x774/0x878 inet_ioctl+0x348/0x3b0 sock_do_ioctl+0x50/0x310 sock_ioctl+0x1f8/0x580 ksys_ioctl+0xb0/0xf0 __arm64_sys_ioctl+0x28/0x38 el0_svc_common.constprop.0+0x7c/0x180 do_el0_svc+0x2c/0x98 el0_sync_handler+0x9c/0x1b8 el0_sync+0x158/0x180 Since DSA never made use of the netdev API for describing links between upper devices and lower devices, the dev->lower_level value of a DSA switch interface would be 1, which would warn when it is a DSA master. We can use netdev_upper_dev_link() to describe the relationship between a DSA slave and a DSA master. To be precise, a DSA "slave" (switch port) is an "upper" to a DSA "master" (host port). The relationship is "many uppers to one lower", like in the case of VLAN. So, for that reason, we use the same function as VLAN uses. There might be a chance that somebody will try to take hold of this interface and use it immediately after register_netdev() and before netdev_upper_dev_link(). To avoid that, we do the registration and linkage while holding the RTNL, and we use the RTNL-locked cousin of register_netdev(), which is register_netdevice(). Since this warning was not there when lockdep was using dynamic keys for addr_list_lock, we are blaming the lockdep patch itself. The network stack _has_ been using static lockdep keys before, and it _is_ likely that stacked DSA setups have been triggering these lockdep warnings since forever, however I can't test very old kernels on this particular stacked DSA setup, to ensure I'm not in fact introducing regressions. Fixes: 845e0eb ("net: change addr_list_lock back to static key") Suggested-by: Cong Wang <[email protected]> Signed-off-by: Vladimir Oltean <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Paolo Pisati <[email protected]>
vladimiroltean
added a commit
to vladimiroltean/linux
that referenced
this pull request
Nov 6, 2020
…arnings Since commit 845e0eb ("net: change addr_list_lock back to static key"), cascaded DSA setups (DSA switch port as DSA master for another DSA switch port) are emitting this lockdep warning: ============================================ WARNING: possible recursive locking detected 5.8.0-rc1-00133-g923e4b5032dd-dirty torvalds#208 Not tainted -------------------------------------------- dhcpcd/323 is trying to acquire lock: ffff000066dd4268 (&dsa_master_addr_list_lock_key/1){+...}-{2:2}, at: dev_mc_sync+0x44/0x90 but task is already holding lock: ffff00006608c268 (&dsa_master_addr_list_lock_key/1){+...}-{2:2}, at: dev_mc_sync+0x44/0x90 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&dsa_master_addr_list_lock_key/1); lock(&dsa_master_addr_list_lock_key/1); *** DEADLOCK *** May be due to missing lock nesting notation 3 locks held by dhcpcd/323: #0: ffffdbd1381dda18 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_lock+0x24/0x30 #1: ffff00006614b268 (_xmit_ETHER){+...}-{2:2}, at: dev_set_rx_mode+0x28/0x48 #2: ffff00006608c268 (&dsa_master_addr_list_lock_key/1){+...}-{2:2}, at: dev_mc_sync+0x44/0x90 stack backtrace: Call trace: dump_backtrace+0x0/0x1e0 show_stack+0x20/0x30 dump_stack+0xec/0x158 __lock_acquire+0xca0/0x2398 lock_acquire+0xe8/0x440 _raw_spin_lock_nested+0x64/0x90 dev_mc_sync+0x44/0x90 dsa_slave_set_rx_mode+0x34/0x50 __dev_set_rx_mode+0x60/0xa0 dev_mc_sync+0x84/0x90 dsa_slave_set_rx_mode+0x34/0x50 __dev_set_rx_mode+0x60/0xa0 dev_set_rx_mode+0x30/0x48 __dev_open+0x10c/0x180 __dev_change_flags+0x170/0x1c8 dev_change_flags+0x2c/0x70 devinet_ioctl+0x774/0x878 inet_ioctl+0x348/0x3b0 sock_do_ioctl+0x50/0x310 sock_ioctl+0x1f8/0x580 ksys_ioctl+0xb0/0xf0 __arm64_sys_ioctl+0x28/0x38 el0_svc_common.constprop.0+0x7c/0x180 do_el0_svc+0x2c/0x98 el0_sync_handler+0x9c/0x1b8 el0_sync+0x158/0x180 Since DSA never made use of the netdev API for describing links between upper devices and lower devices, the dev->lower_level value of a DSA switch interface would be 1, which would warn when it is a DSA master. We can use netdev_upper_dev_link() to describe the relationship between a DSA slave and a DSA master. To be precise, a DSA "slave" (switch port) is an "upper" to a DSA "master" (host port). The relationship is "many uppers to one lower", like in the case of VLAN. So, for that reason, we use the same function as VLAN uses. There might be a chance that somebody will try to take hold of this interface and use it immediately after register_netdev() and before netdev_upper_dev_link(). To avoid that, we do the registration and linkage while holding the RTNL, and we use the RTNL-locked cousin of register_netdev(), which is register_netdevice(). Since this warning was not there when lockdep was using dynamic keys for addr_list_lock, we are blaming the lockdep patch itself. The network stack _has_ been using static lockdep keys before, and it _is_ likely that stacked DSA setups have been triggering these lockdep warnings since forever, however I can't test very old kernels on this particular stacked DSA setup, to ensure I'm not in fact introducing regressions. Fixes: 845e0eb ("net: change addr_list_lock back to static key") Suggested-by: Cong Wang <[email protected]> Signed-off-by: Vladimir Oltean <[email protected]>
vladimiroltean
added a commit
to vladimiroltean/linux
that referenced
this pull request
Nov 6, 2020
…arnings Since commit 845e0eb ("net: change addr_list_lock back to static key"), cascaded DSA setups (DSA switch port as DSA master for another DSA switch port) are emitting this lockdep warning: ============================================ WARNING: possible recursive locking detected 5.8.0-rc1-00133-g923e4b5032dd-dirty torvalds#208 Not tainted -------------------------------------------- dhcpcd/323 is trying to acquire lock: ffff000066dd4268 (&dsa_master_addr_list_lock_key/1){+...}-{2:2}, at: dev_mc_sync+0x44/0x90 but task is already holding lock: ffff00006608c268 (&dsa_master_addr_list_lock_key/1){+...}-{2:2}, at: dev_mc_sync+0x44/0x90 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&dsa_master_addr_list_lock_key/1); lock(&dsa_master_addr_list_lock_key/1); *** DEADLOCK *** May be due to missing lock nesting notation 3 locks held by dhcpcd/323: #0: ffffdbd1381dda18 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_lock+0x24/0x30 #1: ffff00006614b268 (_xmit_ETHER){+...}-{2:2}, at: dev_set_rx_mode+0x28/0x48 #2: ffff00006608c268 (&dsa_master_addr_list_lock_key/1){+...}-{2:2}, at: dev_mc_sync+0x44/0x90 stack backtrace: Call trace: dump_backtrace+0x0/0x1e0 show_stack+0x20/0x30 dump_stack+0xec/0x158 __lock_acquire+0xca0/0x2398 lock_acquire+0xe8/0x440 _raw_spin_lock_nested+0x64/0x90 dev_mc_sync+0x44/0x90 dsa_slave_set_rx_mode+0x34/0x50 __dev_set_rx_mode+0x60/0xa0 dev_mc_sync+0x84/0x90 dsa_slave_set_rx_mode+0x34/0x50 __dev_set_rx_mode+0x60/0xa0 dev_set_rx_mode+0x30/0x48 __dev_open+0x10c/0x180 __dev_change_flags+0x170/0x1c8 dev_change_flags+0x2c/0x70 devinet_ioctl+0x774/0x878 inet_ioctl+0x348/0x3b0 sock_do_ioctl+0x50/0x310 sock_ioctl+0x1f8/0x580 ksys_ioctl+0xb0/0xf0 __arm64_sys_ioctl+0x28/0x38 el0_svc_common.constprop.0+0x7c/0x180 do_el0_svc+0x2c/0x98 el0_sync_handler+0x9c/0x1b8 el0_sync+0x158/0x180 Since DSA never made use of the netdev API for describing links between upper devices and lower devices, the dev->lower_level value of a DSA switch interface would be 1, which would warn when it is a DSA master. We can use netdev_upper_dev_link() to describe the relationship between a DSA slave and a DSA master. To be precise, a DSA "slave" (switch port) is an "upper" to a DSA "master" (host port). The relationship is "many uppers to one lower", like in the case of VLAN. So, for that reason, we use the same function as VLAN uses. There might be a chance that somebody will try to take hold of this interface and use it immediately after register_netdev() and before netdev_upper_dev_link(). To avoid that, we do the registration and linkage while holding the RTNL, and we use the RTNL-locked cousin of register_netdev(), which is register_netdevice(). Since this warning was not there when lockdep was using dynamic keys for addr_list_lock, we are blaming the lockdep patch itself. The network stack _has_ been using static lockdep keys before, and it _is_ likely that stacked DSA setups have been triggering these lockdep warnings since forever, however I can't test very old kernels on this particular stacked DSA setup, to ensure I'm not in fact introducing regressions. Fixes: 845e0eb ("net: change addr_list_lock back to static key") Suggested-by: Cong Wang <[email protected]> Signed-off-by: Vladimir Oltean <[email protected]>
alistair23
pushed a commit
to alistair23/linux
that referenced
this pull request
Jan 31, 2021
Update 5.4-2.2.x-imx to v5.4.87
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Mar 12, 2021
This commit fixes the following checkpatch.pl warnings: WARNING: do not add new typedefs torvalds#47: FILE: hal/HalBtcOutSrc.h:47: +typedef enum _BTC_POWERSAVE_TYPE { WARNING: do not add new typedefs torvalds#54: FILE: hal/HalBtcOutSrc.h:54: +typedef enum _BTC_BT_REG_TYPE { WARNING: do not add new typedefs torvalds#63: FILE: hal/HalBtcOutSrc.h:63: +typedef enum _BTC_CHIP_INTERFACE { WARNING: do not add new typedefs torvalds#71: FILE: hal/HalBtcOutSrc.h:71: +typedef enum _BTC_CHIP_TYPE { WARNING: do not add new typedefs torvalds#81: FILE: hal/HalBtcOutSrc.h:81: +typedef enum _BTC_MSG_TYPE { WARNING: do not add new typedefs torvalds#167: FILE: hal/HalBtcOutSrc.h:167: +typedef struct _BTC_BOARD_INFO { WARNING: do not add new typedefs torvalds#177: FILE: hal/HalBtcOutSrc.h:177: +typedef enum _BTC_DBG_OPCODE { WARNING: do not add new typedefs torvalds#187: FILE: hal/HalBtcOutSrc.h:187: +typedef enum _BTC_RSSI_STATE { WARNING: do not add new typedefs torvalds#200: FILE: hal/HalBtcOutSrc.h:200: +typedef enum _BTC_WIFI_ROLE { WARNING: do not add new typedefs torvalds#208: FILE: hal/HalBtcOutSrc.h:208: +typedef enum _BTC_WIFI_BW_MODE { WARNING: do not add new typedefs torvalds#215: FILE: hal/HalBtcOutSrc.h:215: +typedef enum _BTC_WIFI_TRAFFIC_DIR { WARNING: do not add new typedefs torvalds#221: FILE: hal/HalBtcOutSrc.h:221: +typedef enum _BTC_WIFI_PNP { WARNING: do not add new typedefs torvalds#228: FILE: hal/HalBtcOutSrc.h:228: +typedef enum _BT_WIFI_COEX_STATE { WARNING: do not add new typedefs torvalds#239: FILE: hal/HalBtcOutSrc.h:239: +typedef enum _BTC_GET_TYPE { WARNING: do not add new typedefs torvalds#281: FILE: hal/HalBtcOutSrc.h:281: +typedef enum _BTC_SET_TYPE { WARNING: do not add new typedefs torvalds#321: FILE: hal/HalBtcOutSrc.h:321: +typedef enum _BTC_DBG_DISP_TYPE { WARNING: do not add new typedefs torvalds#328: FILE: hal/HalBtcOutSrc.h:328: +typedef enum _BTC_NOTIFY_TYPE_IPS { WARNING: do not add new typedefs torvalds#334: FILE: hal/HalBtcOutSrc.h:334: +typedef enum _BTC_NOTIFY_TYPE_LPS { WARNING: do not add new typedefs torvalds#340: FILE: hal/HalBtcOutSrc.h:340: +typedef enum _BTC_NOTIFY_TYPE_SCAN { WARNING: do not add new typedefs torvalds#346: FILE: hal/HalBtcOutSrc.h:346: +typedef enum _BTC_NOTIFY_TYPE_ASSOCIATE { WARNING: do not add new typedefs torvalds#352: FILE: hal/HalBtcOutSrc.h:352: +typedef enum _BTC_NOTIFY_TYPE_MEDIA_STATUS { WARNING: do not add new typedefs torvalds#358: FILE: hal/HalBtcOutSrc.h:358: +typedef enum _BTC_NOTIFY_TYPE_SPECIAL_PACKET { WARNING: do not add new typedefs torvalds#366: FILE: hal/HalBtcOutSrc.h:366: +typedef enum _BTC_NOTIFY_TYPE_STACK_OPERATION { WARNING: do not add new typedefs torvalds#374: FILE: hal/HalBtcOutSrc.h:374: +typedef enum _BTC_ANTENNA_POS { WARNING: do not add new typedefs torvalds#412: FILE: hal/HalBtcOutSrc.h:412: +typedef struct _BTC_BT_INFO { WARNING: do not add new typedefs torvalds#440: FILE: hal/HalBtcOutSrc.h:440: +typedef struct _BTC_STACK_INFO { WARNING: do not add new typedefs torvalds#455: FILE: hal/HalBtcOutSrc.h:455: +typedef struct _BTC_BT_LINK_INFO { WARNING: do not add new typedefs torvalds#468: FILE: hal/HalBtcOutSrc.h:468: +typedef struct _BTC_STATISTICS { WARNING: do not add new typedefs torvalds#487: FILE: hal/HalBtcOutSrc.h:487: +typedef struct _BTC_COEXIST { Signed-off-by: Marco Cesati <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Mar 13, 2021
This commit fixes the following checkpatch.pl warnings: WARNING: do not add new typedefs torvalds#47: FILE: hal/HalBtcOutSrc.h:47: +typedef enum _BTC_POWERSAVE_TYPE { WARNING: do not add new typedefs torvalds#54: FILE: hal/HalBtcOutSrc.h:54: +typedef enum _BTC_BT_REG_TYPE { WARNING: do not add new typedefs torvalds#63: FILE: hal/HalBtcOutSrc.h:63: +typedef enum _BTC_CHIP_INTERFACE { WARNING: do not add new typedefs torvalds#71: FILE: hal/HalBtcOutSrc.h:71: +typedef enum _BTC_CHIP_TYPE { WARNING: do not add new typedefs torvalds#81: FILE: hal/HalBtcOutSrc.h:81: +typedef enum _BTC_MSG_TYPE { WARNING: do not add new typedefs torvalds#167: FILE: hal/HalBtcOutSrc.h:167: +typedef struct _BTC_BOARD_INFO { WARNING: do not add new typedefs torvalds#177: FILE: hal/HalBtcOutSrc.h:177: +typedef enum _BTC_DBG_OPCODE { WARNING: do not add new typedefs torvalds#187: FILE: hal/HalBtcOutSrc.h:187: +typedef enum _BTC_RSSI_STATE { WARNING: do not add new typedefs torvalds#200: FILE: hal/HalBtcOutSrc.h:200: +typedef enum _BTC_WIFI_ROLE { WARNING: do not add new typedefs torvalds#208: FILE: hal/HalBtcOutSrc.h:208: +typedef enum _BTC_WIFI_BW_MODE { WARNING: do not add new typedefs torvalds#215: FILE: hal/HalBtcOutSrc.h:215: +typedef enum _BTC_WIFI_TRAFFIC_DIR { WARNING: do not add new typedefs torvalds#221: FILE: hal/HalBtcOutSrc.h:221: +typedef enum _BTC_WIFI_PNP { WARNING: do not add new typedefs torvalds#228: FILE: hal/HalBtcOutSrc.h:228: +typedef enum _BT_WIFI_COEX_STATE { WARNING: do not add new typedefs torvalds#239: FILE: hal/HalBtcOutSrc.h:239: +typedef enum _BTC_GET_TYPE { WARNING: do not add new typedefs torvalds#281: FILE: hal/HalBtcOutSrc.h:281: +typedef enum _BTC_SET_TYPE { WARNING: do not add new typedefs torvalds#321: FILE: hal/HalBtcOutSrc.h:321: +typedef enum _BTC_DBG_DISP_TYPE { WARNING: do not add new typedefs torvalds#328: FILE: hal/HalBtcOutSrc.h:328: +typedef enum _BTC_NOTIFY_TYPE_IPS { WARNING: do not add new typedefs torvalds#334: FILE: hal/HalBtcOutSrc.h:334: +typedef enum _BTC_NOTIFY_TYPE_LPS { WARNING: do not add new typedefs torvalds#340: FILE: hal/HalBtcOutSrc.h:340: +typedef enum _BTC_NOTIFY_TYPE_SCAN { WARNING: do not add new typedefs torvalds#346: FILE: hal/HalBtcOutSrc.h:346: +typedef enum _BTC_NOTIFY_TYPE_ASSOCIATE { WARNING: do not add new typedefs torvalds#352: FILE: hal/HalBtcOutSrc.h:352: +typedef enum _BTC_NOTIFY_TYPE_MEDIA_STATUS { WARNING: do not add new typedefs torvalds#358: FILE: hal/HalBtcOutSrc.h:358: +typedef enum _BTC_NOTIFY_TYPE_SPECIAL_PACKET { WARNING: do not add new typedefs torvalds#366: FILE: hal/HalBtcOutSrc.h:366: +typedef enum _BTC_NOTIFY_TYPE_STACK_OPERATION { WARNING: do not add new typedefs torvalds#374: FILE: hal/HalBtcOutSrc.h:374: +typedef enum _BTC_ANTENNA_POS { WARNING: do not add new typedefs torvalds#412: FILE: hal/HalBtcOutSrc.h:412: +typedef struct _BTC_BT_INFO { WARNING: do not add new typedefs torvalds#440: FILE: hal/HalBtcOutSrc.h:440: +typedef struct _BTC_STACK_INFO { WARNING: do not add new typedefs torvalds#455: FILE: hal/HalBtcOutSrc.h:455: +typedef struct _BTC_BT_LINK_INFO { WARNING: do not add new typedefs torvalds#468: FILE: hal/HalBtcOutSrc.h:468: +typedef struct _BTC_STATISTICS { WARNING: do not add new typedefs torvalds#487: FILE: hal/HalBtcOutSrc.h:487: +typedef struct _BTC_COEXIST { Signed-off-by: Marco Cesati <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Mar 15, 2021
This commit fixes the following checkpatch.pl errors: ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#14: FILE: ./hal/odm_DIG.c:14: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#30: FILE: ./hal/odm_DIG.c:30: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#41: FILE: ./hal/odm_DIG.c:41: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#51: FILE: ./hal/odm_DIG.c:51: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#59: FILE: ./hal/odm_DIG.c:59: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#72: FILE: ./hal/odm_DIG.c:72: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#136: FILE: ./hal/odm_DIG.c:136: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#208: FILE: ./hal/odm_DIG.c:208: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#236: FILE: ./hal/odm_DIG.c:236: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#325: FILE: ./hal/odm_DIG.c:325: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#326: FILE: ./hal/odm_DIG.c:326: + struct DIG_T * pDM_DigTable = &pDM_Odm->DM_DigTable; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#365: FILE: ./hal/odm_DIG.c:365: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#366: FILE: ./hal/odm_DIG.c:366: + struct DIG_T * pDM_DigTable = &pDM_Odm->DM_DigTable; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#438: FILE: ./hal/odm_DIG.c:438: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#469: FILE: ./hal/odm_DIG.c:469: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#470: FILE: ./hal/odm_DIG.c:470: + struct DIG_T * pDM_DigTable = &pDM_Odm->DM_DigTable; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#507: FILE: ./hal/odm_DIG.c:507: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#510: FILE: ./hal/odm_DIG.c:510: + struct DIG_T * pDM_DigTable = &pDM_Odm->DM_DigTable; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#826: FILE: ./hal/odm_DIG.c:826: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#895: FILE: ./hal/odm_DIG.c:895: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#896: FILE: ./hal/odm_DIG.c:896: + struct false_ALARM_STATISTICS * FalseAlmCnt = &(pDM_Odm->FalseAlmCnt); ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#1065: FILE: ./hal/odm_DIG.c:1065: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#1081: FILE: ./hal/odm_DIG.c:1081: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#1082: FILE: ./hal/odm_DIG.c:1082: + struct DIG_T * pDM_DigTable = &pDM_Odm->DM_DigTable; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#1083: FILE: ./hal/odm_DIG.c:1083: + struct false_ALARM_STATISTICS * pFalseAlmCnt = &(pDM_Odm->FalseAlmCnt); ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1137: FILE: ./hal/odm_DIG.c:1137: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1138: FILE: ./hal/odm_DIG.c:1138: + struct false_ALARM_STATISTICS * FalseAlmCnt = &(pDM_Odm->FalseAlmCnt); ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1198: FILE: ./hal/odm_DIG.c:1198: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1199: FILE: ./hal/odm_DIG.c:1199: + struct DIG_T * pDM_DigTable = &pDM_Odm->DM_DigTable; Signed-off-by: Marco Cesati <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Mar 15, 2021
This commit fixes the following checkpatch.pl error: ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#208: FILE: ./os_dep/os_intfs.c:208: +static void loadparam(struct adapter *padapter, struct net_device * pnetdev) Signed-off-by: Marco Cesati <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Mar 16, 2021
This commit fixes the following checkpatch.pl errors: ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#14: FILE: ./hal/odm_DIG.c:14: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#30: FILE: ./hal/odm_DIG.c:30: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#41: FILE: ./hal/odm_DIG.c:41: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#51: FILE: ./hal/odm_DIG.c:51: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#59: FILE: ./hal/odm_DIG.c:59: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#72: FILE: ./hal/odm_DIG.c:72: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#136: FILE: ./hal/odm_DIG.c:136: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#208: FILE: ./hal/odm_DIG.c:208: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#236: FILE: ./hal/odm_DIG.c:236: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#325: FILE: ./hal/odm_DIG.c:325: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#326: FILE: ./hal/odm_DIG.c:326: + struct DIG_T * pDM_DigTable = &pDM_Odm->DM_DigTable; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#365: FILE: ./hal/odm_DIG.c:365: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#366: FILE: ./hal/odm_DIG.c:366: + struct DIG_T * pDM_DigTable = &pDM_Odm->DM_DigTable; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#438: FILE: ./hal/odm_DIG.c:438: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#469: FILE: ./hal/odm_DIG.c:469: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#470: FILE: ./hal/odm_DIG.c:470: + struct DIG_T * pDM_DigTable = &pDM_Odm->DM_DigTable; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#507: FILE: ./hal/odm_DIG.c:507: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#510: FILE: ./hal/odm_DIG.c:510: + struct DIG_T * pDM_DigTable = &pDM_Odm->DM_DigTable; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#826: FILE: ./hal/odm_DIG.c:826: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#895: FILE: ./hal/odm_DIG.c:895: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#896: FILE: ./hal/odm_DIG.c:896: + struct false_ALARM_STATISTICS * FalseAlmCnt = &(pDM_Odm->FalseAlmCnt); ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#1065: FILE: ./hal/odm_DIG.c:1065: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#1081: FILE: ./hal/odm_DIG.c:1081: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#1082: FILE: ./hal/odm_DIG.c:1082: + struct DIG_T * pDM_DigTable = &pDM_Odm->DM_DigTable; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#1083: FILE: ./hal/odm_DIG.c:1083: + struct false_ALARM_STATISTICS * pFalseAlmCnt = &(pDM_Odm->FalseAlmCnt); ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1137: FILE: ./hal/odm_DIG.c:1137: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1138: FILE: ./hal/odm_DIG.c:1138: + struct false_ALARM_STATISTICS * FalseAlmCnt = &(pDM_Odm->FalseAlmCnt); ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1198: FILE: ./hal/odm_DIG.c:1198: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1199: FILE: ./hal/odm_DIG.c:1199: + struct DIG_T * pDM_DigTable = &pDM_Odm->DM_DigTable; Reviewed-by: Dan Carpenter <[email protected]> Signed-off-by: Marco Cesati <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Mar 16, 2021
This commit fixes the following checkpatch.pl error: ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#208: FILE: ./os_dep/os_intfs.c:208: +static void loadparam(struct adapter *padapter, struct net_device * pnetdev) Reviewed-by: Dan Carpenter <[email protected]> Signed-off-by: Marco Cesati <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
gatieme
pushed a commit
to gatieme/linux
that referenced
this pull request
Nov 24, 2022
ANBZ: torvalds#208 commit 032146c upstream. If we open a file without read access and then pass the fd to a syscall whose implementation calls kernel_read_file_from_fd(), we get a warning from __kernel_read(): if (WARN_ON_ONCE(!(file->f_mode & FMODE_READ))) This currently affects both finit_module() and kexec_file_load(), but it could affect other syscalls in the future. Link: https://lkml.kernel.org/r/[email protected] Fixes: b844f0e ("vfs: define kernel_copy_file_from_fd()") Signed-off-by: Matthew Wilcox (Oracle) <[email protected]> Reported-by: Hao Sun <[email protected]> Reviewed-by: Kees Cook <[email protected]> Acked-by: Christian Brauner <[email protected]> Cc: Al Viro <[email protected]> Cc: Mimi Zohar <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: hongnanli <[email protected]> Reviewed-by: Joseph Qi <[email protected]>
gatieme
pushed a commit
to gatieme/linux
that referenced
this pull request
Nov 24, 2022
ANBZ: torvalds#208 commit 7622435 upstream. fuse_finish_open() will be called with FUSE_NOWRITE in case of atomic O_TRUNC. This can deadlock with fuse_wait_on_page_writeback() in fuse_launder_page() triggered by invalidate_inode_pages2(). Fix by replacing invalidate_inode_pages2() in fuse_finish_open() with a truncate_pagecache() call. This makes sense regardless of FOPEN_KEEP_CACHE or fc->writeback cache, so do it unconditionally. Reported-by: Xie Yongji <[email protected]> Reported-and-tested-by: [email protected] Fixes: e464830 ("fuse: truncate pending writes on O_TRUNC") Cc: <[email protected]> Signed-off-by: Miklos Szeredi <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Hongnan Li <[email protected]> Reviewed-by: Joseph Qi <[email protected]>
gatieme
pushed a commit
to gatieme/linux
that referenced
this pull request
Nov 24, 2022
ANBZ: torvalds#208 commit 712a951 upstream. It is possible to trigger a crash by splicing anon pipe bufs to the fuse device. The reason for this is that anon_pipe_buf_release() will reuse buf->page if the refcount is 1, but that page might have already been stolen and its flags modified (e.g. PG_lru added). This happens in the unlikely case of fuse_dev_splice_write() getting around to calling pipe_buf_release() after a page has been stolen, added to the page cache and removed from the page cache. Fix by calling pipe_buf_release() right after the page was inserted into the page cache. In this case the page has an elevated refcount so any release function will know that the page isn't reusable. Reported-by: Frank Dinoff <[email protected]> Link: https://lore.kernel.org/r/CAAmZXrsGg2xsP1CK+cbuEMumtrqdvD-NKnWzhNcvn71RV3c1yw@mail.gmail.com/ Fixes: dd3bb14 ("fuse: support splice() writing to fuse device") Cc: <[email protected]> # v2.6.35 Signed-off-by: Miklos Szeredi <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Hongnan Li <[email protected]> Reviewed-by: Joseph Qi <[email protected]>
gatieme
pushed a commit
to gatieme/linux
that referenced
this pull request
Nov 24, 2022
ANBZ: torvalds#208 commit c1e6311 upstream. To clear a user buffer we cannot simply use memset, we have to use clear_user(). With a virtio-mem device that registers a vmcore_cb and has some logically unplugged memory inside an added Linux memory block, I can easily trigger a BUG by copying the vmcore via "cp": systemd[1]: Starting Kdump Vmcore Save Service... kdump[420]: Kdump is using the default log level(3). kdump[453]: saving to /sysroot/var/crash/127.0.0.1-2021-11-11-14:59:22/ kdump[458]: saving vmcore-dmesg.txt to /sysroot/var/crash/127.0.0.1-2021-11-11-14:59:22/ kdump[465]: saving vmcore-dmesg.txt complete kdump[467]: saving vmcore BUG: unable to handle page fault for address: 00007f2374e01000 #PF: supervisor write access in kernel mode #PF: error_code(0x0003) - permissions violation PGD 7a523067 P4D 7a523067 PUD 7a528067 PMD 7a525067 PTE 800000007048f867 Oops: 0003 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 468 Comm: cp Not tainted 5.15.0+ torvalds#6 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.14.0-27-g64f37cc530f1-prebuilt.qemu.org 04/01/2014 RIP: 0010:read_from_oldmem.part.0.cold+0x1d/0x86 Code: ff ff ff e8 05 ff fe ff e9 b9 e9 7f ff 48 89 de 48 c7 c7 38 3b 60 82 e8 f1 fe fe ff 83 fd 08 72 3c 49 8d 7d 08 4c 89 e9 89 e8 <49> c7 45 00 00 00 00 00 49 c7 44 05 f8 00 00 00 00 48 83 e7 f81 RSP: 0018:ffffc9000073be08 EFLAGS: 00010212 RAX: 0000000000001000 RBX: 00000000002fd000 RCX: 00007f2374e01000 RDX: 0000000000000001 RSI: 00000000ffffdfff RDI: 00007f2374e01008 RBP: 0000000000001000 R08: 0000000000000000 R09: ffffc9000073bc50 R10: ffffc9000073bc48 R11: ffffffff829461a8 R12: 000000000000f000 R13: 00007f2374e01000 R14: 0000000000000000 R15: ffff88807bd421e8 FS: 00007f2374e12140(0000) GS:ffff88807f000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2374e01000 CR3: 000000007a4aa000 CR4: 0000000000350eb0 Call Trace: read_vmcore+0x236/0x2c0 proc_reg_read+0x55/0xa0 vfs_read+0x95/0x190 ksys_read+0x4f/0xc0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae Some x86-64 CPUs have a CPU feature called "Supervisor Mode Access Prevention (SMAP)", which is used to detect wrong access from the kernel to user buffers like this: SMAP triggers a permissions violation on wrong access. In the x86-64 variant of clear_user(), SMAP is properly handled via clac()+stac(). To fix, properly use clear_user() when we're dealing with a user buffer. Link: https://lkml.kernel.org/r/[email protected] Fixes: 997c136 ("fs/proc/vmcore.c: add hook to read_from_oldmem() to check for non-ram pages") Signed-off-by: David Hildenbrand <[email protected]> Acked-by: Baoquan He <[email protected]> Cc: Dave Young <[email protected]> Cc: Baoquan He <[email protected]> Cc: Vivek Goyal <[email protected]> Cc: Philipp Rudo <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: David Hildenbrand <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Hongnan Li <[email protected]> Reviewed-by: Joseph Qi <[email protected]>
gatieme
pushed a commit
to gatieme/linux
that referenced
this pull request
Nov 24, 2022
ANBZ: torvalds#208 commit 4734417 upstream. Checking buf->flags should be done before the pipe_buf_release() is called on the pipe buffer, since releasing the buffer might modify the flags. This is exactly what page_cache_pipe_buf_release() does, and which results in the same VM_BUG_ON_PAGE(PageLRU(page)) that the original patch was trying to fix. Reported-by: Justin Forbes <[email protected]> Fixes: 712a951 ("fuse: fix page stealing") Cc: <[email protected]> # v2.6.35 Signed-off-by: Miklos Szeredi <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Hongnan Li <[email protected]> Reviewed-by: Joseph Qi <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Update from original