[This email was generated by a script. Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 3 of them as possibly being bugs in the vhost
tree:
https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: ad5e427e0f6b702e52c11d1f7b2b7be3bac7de82
commit: 7a78a7f7695bf9ef9cef3c06fbc5fa4573fd0eef power: reset:
nvmem-reboot-mode: use NVMEM as reboot mode write interface
date: 4 weeks ago
config:
Actually I'll make a revised version and merge it with a patchset that
makes use of this feature.
-Paul
Le mar. 23 juil. 2019 à 14:55, Paul Cercueil a
écrit :
device_node_to_regmap() is exactly like syscon_node_to_regmap(), but
it
does not check that the node is compatible with "syscon".
[This email was generated by a script. Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 4 of them as possibly being bugs in the "net/hsr"
[This email was generated by a script. Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 4 of them as possibly being bugs in the "net/rds"
On 7/23/2019 21:49, Tony Lindgren wrote:
+#define MOTOROLA_VENDOR_ID 0x22b8
+#define MOTOROLA_PRODUCT_MDM6600 0x2a70
+#define MOTOROLA_PRODUCT_MDM9600 0x2e0a
+#define MOTOROLA_PRODUCT_MDM_RAM_DL0x4281
+#define
[This email was generated by a script. Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 4 of them as possibly being bugs in the tty subsystem.
[This email was generated by a script. Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 5 of them as possibly being bugs in the "fs/fuse"
[This email was generated by a script. Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 5 of them as possibly being bugs in the "fs/ntfs"
Hi all,
Today's linux-next merge of the keys tree got conflicts in:
fs/afs/security.c
include/linux/key.h
between commit:
dd05d852085f ("afs: Provide an RCU-capable key lookup")
from the afs tree and commit:
f802f2b3a991 ("keys: Replace uid/gid/perm permissions checking with an ACL")
[This email was generated by a script. Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 5 of them as possibly being bugs in the "fs/reiserfs"
On Tue, Jul 23, 2019 at 04:49:46PM -0400, Qian Cai wrote:
> The commit d66acc39c7ce ("bitops: Optimise get_order()") introduced a
> compilation warning because "rx_frag_size" is an "ushort" while
> PAGE_SHIFT here is 16. The commit changed the get_order() to be a
> multi-line macro where compilers
[This email was generated by a script. Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 5 of them as possibly being bugs in the "net/smc"
[This email was generated by a script. Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 5 of them as possibly being bugs in the "net/x25"
I did some additional testing and it looks like the "allow_signal"
change may be safe enough
# git diff -a
diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
index a4830ced0f98..a15a6e738eb5 100644
--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -1113,6 +1113,7 @@ cifs_demultiplex_thread(void
[This email was generated by a script. Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 6 of them as possibly being bugs in the "net/dccp"
Pavel noticed I missed a line from the attempt to do a similar patch
to Eric's suggestion
(it still didn't work though - although "allow_signal" does albeit is
possibly dangerous as user space can kill cifsd)
# git diff -a
diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
index
[This email was generated by a script. Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 8 of them as possibly being bugs in the input
[This email was generated by a script. Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 10 of them as possibly being bugs in the "net/sctp"
Currently, when calling prctl(PR_SET_TIMERSLACK, arg2), arg2 is an
unsigned long value, arg2 will never < 0. Negative judgment is
meaningless, so remove it.
Fixes: 6976675d9404 ("hrtimer: create a "timer_slack" field in the task struct")
Signed-off-by: Yang Xu
Cc: Cyrill Gorcunov
---
The memc node from mt7621.dtsi has incorrect register resource.
Fix it according to the programming guide.
Signed-off-by: Weijie Gao
Signed-off-by: Chuanhong Guo
---
Change since v1: None.
drivers/staging/mt7621-dts/mt7621.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
This commit adds device tree binding documentation for MT7621
PLL controller.
Signed-off-by: Chuanhong Guo
---
Change since v1:
drop useless syscon in compatible string
.../bindings/clock/mediatek,mt7621-pll.txt | 18 ++
1 file changed, 18 insertions(+)
create mode 100644
This commit adds device-tree node for mt7621-pll and use its clocks
accordingly.
Signed-off-by: Chuanhong Guo
---
Changes since v1:
1. drop cpuclock node in gbpc1.dts
2. drop syscon in mt7621-pll node
drivers/staging/mt7621-dts/gbpc1.dts | 5 -
drivers/staging/mt7621-dts/mt7621.dtsi |
For a long time the mt7621 uses a fixed cpu clock which causes a problem
if the cpu frequency is not 880MHz.
This patch adds cpu/bus clock calculation code and binds clocks to
mt7621-pll node.
Ported from OpenWrt:
c7ca224299 ramips: fix cpu clock of mt7621 and add dt clk devices
Signed-off-by:
This patchset ports CPU clock detection for MT7621 from OpenWrt.
Last time I sent this, I forgot to add an binding include which
caused a compile error and the patch doesn't stay in linux-next.
This patchset resent the first two commits and also added binding
documentation for mt7621-pll and
This function isn't called anywhere. just drop it.
Signed-off-by: Chuanhong Guo
---
Change since v1:
New patch. Split from:
"MIPS: ralink: fix cpu clock of mt7621 and add dt clk devices"
arch/mips/ralink/mt7621.c | 43 ---
1 file changed, 43 deletions(-)
This patch adds dt binding header for mediatek,mt7621-pll
Signed-off-by: Weijie Gao
Signed-off-by: Chuanhong Guo
Reviewed-by: Rob Herring
---
Change since v1:
Change commit title prefix.
include/dt-bindings/clock/mt7621-clk.h | 14 ++
1 file changed, 14 insertions(+)
create mode
In kernfs_path_from_node_locked(), there is an if statement on line 147
to check whether buf is NULL:
if (buf)
When buf is NULL, it is used on line 151:
len += strlcpy(buf + len, parent_str, ...)
and line 158:
len += strlcpy(buf + len, "/", ...)
and line 160:
len += strlcpy(buf +
On Tue, 23 Jul 2019 at 20:39, Ulf Hansson wrote:
>
> On Tue, 23 Jul 2019 at 05:05, Baolin Wang wrote:
> >
> > Hi Ulf,
> >
> > On Mon, 22 Jul 2019 at 19:54, Ulf Hansson wrote:
> > >
> > > On Wed, 17 Jul 2019 at 04:29, Baolin Wang wrote:
> > > >
> > > > In sdhci_runtime_resume_host() function,
Tyrel,
> While removing an ibmvfc client adapter a WARN_ON like the following
> WARN_ON is seen in the kernel log:
Applied to 5.3/scsi-fixes, thanks!
--
Martin K. Petersen Oracle Linux Engineering
Add a Intel event file for perf.
Signed-off-by: Haiyan Song
---
tools/perf/pmu-events/arch/x86/icelake/cache.json | 552 +
.../arch/x86/icelake/floating-point.json | 102 +++
.../perf/pmu-events/arch/x86/icelake/frontend.json | 424 ++
On 2019/7/23 下午11:02, Michael S. Tsirkin wrote:
On Tue, Jul 23, 2019 at 09:34:29PM +0800, Jason Wang wrote:
On 2019/7/23 下午6:27, Michael S. Tsirkin wrote:
Yes, since there could be multiple co-current invalidation requests. We need
count them to make sure we don't pin wrong pages.
I also
Colin,
> Fix spelling mistake in kernel warning message and replace printk with
> with pr_warn.
Applied to 5.3/scsi-fixes, thanks!
--
Martin K. Petersen Oracle Linux Engineering
Christophe,
> #define relative to FCOE CTLR start with FCOE_CTLR, except
> FCOE_CTRL_SOL_TOV.
>
> This is likely a typo and CTRL should be CTLR here as well.
Applied to 5.3/scsi-fixes, thanks!
--
Martin K. Petersen Oracle Linux Engineering
YueHaibing,
> Fix sparse warnings:
>
> drivers/scsi/megaraid/megaraid_sas_fusion.c:541:1: warning: symbol
> 'megasas_alloc_cmdlist_fusion' was not declared. Should it be static?
Applied to 5.3/scsi-fixes. Thanks!
--
Martin K. Petersen Oracle Linux Engineering
Junxiao,
> While loading fw crashdump in function fw_crash_buffer_show(), left
> bytes in one dma chunk was not checked, if copying size over it,
> overflow access will cause kernel panic.
Applied to 5.3/scsi-fixes. Thanks!
--
Martin K. Petersen Oracle Linux Engineering
> On Jul 23, 2019, at 9:51 PM, Navid Emamdoost
> wrote:
>
> xdr_inline_decode may return NULL, so the check is necessary. The base
> pointer will be dereferenced later in rpcrdma_inline_fixup.
NACK. When xdr_inline_decode is passed a zero “length” argument, it can never
return NULL.
>
Instead of using to_pci_dev + pci_get_drvdata,
use dev_get_drvdata to make code simpler.
Signed-off-by: Chuhong Yuan
---
Changes in v2:
- Change pci_set_drvdata to dev_set_drvdata
to keep consistency.
drivers/media/pci/intel/ipu3/ipu3-cio2.c | 5 ++---
drivers/media/pci/pt1/pt1.c
On Tue, Jul 23, 2019 at 8:32 PM Eric W. Biederman wrote:
>
> Steve French writes:
>
> > Very easy to see what caused the regression with this global change:
> >
> > mount (which launches "cifsd" thread to read the socket)
> > umount (which kills the "cifsd" thread)
> > rmmod (rmmod now fails
On 2019-7-24 at 08:49 Shawn Guo wrote:
> On Tue, Jul 23, 2019 at 09:39:38AM +, Robin Gong wrote:
> > On 2019-7-17 at 14:42 Shawn Guo wrote:
> > > On Mon, Jun 10, 2019 at 04:17:50PM +0800, yibin.g...@nxp.com wrote:
> > > > From: Robin Gong
> > > >
> > > > Add dma support on ecspi.
> > > >
>
xdr_inline_decode may return NULL, so the check is necessary. The base
pointer will be dereferenced later in rpcrdma_inline_fixup.
Signed-off-by: Navid Emamdoost
---
net/sunrpc/xprtrdma/rpc_rdma.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/sunrpc/xprtrdma/rpc_rdma.c
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/wireless/ath/carl9170/usb.c: In function 'carl9170_usb_disconnect':
drivers/net/wireless/ath/carl9170/usb.c:1110:21: warning:
variable 'udev' set but not used [-Wunused-but-set-variable]
It is not used, so can be removed.
Reported-by:
[This email was generated by a script. Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 11 of them as possibly being bugs in the RDMA
[This email was generated by a script. Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 11 of them as possibly being bugs in the "net/wireless"
[This email was generated by a script. Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 13 of them as possibly being bugs in the "net/netrom"
[This email was generated by a script. Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 14 of them as possibly being bugs in the "net/tipc"
[This email was generated by a script. Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 18 of them as possibly being bugs in the "fs/9p"
[This email was generated by a script. Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 19 of them as possibly being bugs in the perf
[This email was generated by a script. Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 25 of them as possibly being bugs in the kvm subsystem.
Look at the required OPPs of the "parent" device to determine the OPP that
is required from the slave device managed by the passive governor. This
allows having mappings between a parent device and a slave device even when
they don't have the same number of OPPs.
Signed-off-by: Saravana Kannan
Currently, the linking of required-opps fails silently if the
destination OPP table hasn't been added before the source OPP table is
added. This puts an unnecessary requirement that the destination table
be added before the source table is added.
In reality, the destination table is needed only
The OPP table can be used often in devfreq. Trying to get it each time can
be expensive, so cache it in the devfreq struct.
Signed-off-by: Saravana Kannan
Reviewed-by: Chanwoo Choi
Acked-by: MyungJoo Ham
---
drivers/devfreq/devfreq.c | 6 ++
include/linux/devfreq.h | 2 ++
2 files
[This email was generated by a script. Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 26 of them as possibly being bugs in the "net/xfrm"
Add a function that allows looking up required OPPs given a source OPP
table, destination OPP table and the source OPP.
Signed-off-by: Saravana Kannan
---
drivers/opp/core.c | 53 ++
include/linux/pm_opp.h | 11 +
2 files changed, 64
The devfreq passive governor scales the frequency of a "child" device based
on the current frequency of a "parent" device (not parent/child in the
sense of device hierarchy). As of today, the passive governor requires one
of the following to work correctly:
1. The parent and child device have the
A Device-A can have a (minimum) performance requirement on another
Device-B to be able to function correctly. This performance requirement
on Device-B can also change based on the current performance level of
Device-A.
The existing required-opps feature fits well to describe this need. So,
[This email was generated by a script. Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 29 of them as possibly being bugs in the bluetooth
Greg Thelen's on July 22, 2019 4:32 pm:
> Since commit 9e3596b0c653 ("kbuild: initramfs cleanup, set target from
> Kconfig") "make clean" leaves behind compressed initramfs images.
> Example:
> $ make defconfig
> $ sed -i
>
[This email was generated by a script. Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 35 of them as possibly being bugs in the media
On Tue, Jul 23, 2019 at 05:38:30PM -0600, Jane Chu wrote:
> @@ -331,16 +330,21 @@ static void add_to_kill(struct task_struct *tsk, struct
> page *p,
> tk->size_shift = compound_order(compound_head(p)) + PAGE_SHIFT;
>
> /*
> - * In theory we don't have to kill when the
[This email was generated by a script. Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 99 of them as possibly being bugs in the net subsystem.
On Tue, Jul 23, 2019 at 4:49 PM Jane Chu wrote:
>
> Mmap /dev/dax more than once, then read the poison location using address
> from one of the mappings. The other mappings due to not having the page
> mapped in will cause SIGKILLs delivered to the process. SIGKILL succeeds
> over SIGBUS, so user
On Tue, Jul 23, 2019 at 10:39 PM Cao, Bingbu wrote:
>
>
>
>
> BRs,
> Bingbu Cao
>
>
> -Original Message-
> From: Chuhong Yuan
> Sent: Tuesday, July 23, 2019 7:50 PM
> Cc: Zhi, Yong ; Sakari Ailus
> ; Cao, Bingbu ; Mauro
> Carvalho Chehab ; Akihiro Tsukada ;
>
The "ti,lp87565" compatible string is still in of_lp87565_match_table,
but current code will return -EINVAL because lp87565->dev_type is unknown.
This was working in earlier kernel versions, so fix it.
Fixes: 7ee63bd74750 ("regulator: lp87565: Add 4-phase lp87561 regulator
support")
Mark Brown 於 2019年7月24日 週三 上午12:35寫道：
>
> On Tue, Jul 23, 2019 at 08:28:35PM +0800, Axel Lin wrote:
> > Mark Brown 於 2019年7月23日 週二 下午7:26寫道：
> > > On Thu, Jul 11, 2019 at 07:35:17PM +0800, Axel Lin wrote:
>
> > > > The "ti,lp87565" compatible string is still in of_lp87565_match_table,
> > > >
On Tue, Jul 23, 2019 at 09:39:38AM +, Robin Gong wrote:
> On 2019-7-17 at 14:42 Shawn Guo wrote:
> > On Mon, Jun 10, 2019 at 04:17:50PM +0800, yibin.g...@nxp.com wrote:
> > > From: Robin Gong
> > >
> > > Add dma support on ecspi.
> > >
> > > Signed-off-by: Robin Gong
> >
> > Applied,
Very easy to see what caused the regression with this global change:
mount (which launches "cifsd" thread to read the socket)
umount (which kills the "cifsd" thread)
rmmod (rmmod now fails since "cifsd" thread is still active)
mount launches a thread to read from the socket ("cifsd")
umount is
On Tue, Jul 23, 2019 at 3:04 AM Viresh Kumar wrote:
>
> On 17-07-19, 15:23, Saravana Kannan wrote:
> > Look at the required OPPs of the "parent" device to determine the OPP that
> > is required from the slave device managed by the passive governor. This
> > allows having mappings between a parent
On Tue, Jul 23, 2019 at 2:53 AM Viresh Kumar wrote:
>
> On 17-07-19, 15:23, Saravana Kannan wrote:
> > Add a function that allows looking up required OPPs given a source OPP
> > table, destination OPP table and the source OPP.
> >
> > Signed-off-by: Saravana Kannan
> > ---
> >
This file is used by clangd to use language server protocol.
It can be generated at each compile using scripts/gen_compile_commands.py.
Therefore it is different depending on the environment and should be
ignored.
Signed-off-by: Toru Komatsu
---
.gitignore | 3 +++
1 file changed, 3
On Tue, Jul 23, 2019 at 7:27 AM Rob Herring wrote:
>
> On Mon, Jul 22, 2019 at 5:41 PM Saravana Kannan wrote:
> >
> > On Mon, Jul 22, 2019 at 4:35 PM Rob Herring wrote:
> > >
> > > On Tue, Jul 16, 2019 at 11:58:08AM -0700, Saravana Kannan wrote:
> > > > On Tue, Jul 16, 2019 at 10:25 AM Sibi
Default busses also have devices created for them. But there's no point
in creating device links for them. It's especially wasteful as it'll
cause the traversal of the entire device tree and also spend a lot of
time checking and figuring out that creating those links isn't allowed.
So check for
This sync_state driver/bus callback is called once all the consumers
of a supplier have probed successfully.
This allows the supplier device's driver/bus to sync the supplier
device's state to the software state with the guarantee that all the
consumers are actively managing the resources
A parent device can have child devices that it adds when it probes. But
this probing of the parent device can happen way after kernel init is done
-- for example, when the parent device's driver is loaded as a module.
In such cases, if the child devices depend on a supplier in the system, we
need
When all the top level devices are populated from DT during kernel
init, the supplier devices could be added and probed before the
consumer devices are added and linked to the suppliers. To avoid the
sync_state() callback from being called prematurely, pause the
sync_state() callbacks before
When devices are added, the bus might want to create device links to track
functional dependencies between supplier and consumer devices. This
tracking of supplier-consumer relationship allows optimizing device probe
order and tracking whether all consumers of a supplier are active. The
add_links
The driver core/bus adding supplier-consumer dependencies by default
enables functional dependencies to be tracked correctly even when the
consumer devices haven't had their drivers registered or loaded (if they
are modules).
However, when the bus incorrectly adds dependencies that it shouldn't
Add device-links to track functional dependencies between devices
after they are created (but before they are probed) by looking at
their common DT bindings like clocks, interconnects, etc.
Having functional dependencies automatically added before the devices
are probed, provides the following
On Mon, 2019-06-24 at 17:12 -0700, Song Liu wrote:
> This patch is (hopefully) the first step to enable THP for non-shmem
> filesystems.
>
> This patch enables an application to put part of its text sections to THP
> via madvise, for example:
>
> madvise((void *)0x60, 0x20,
On Tue, Jul 23, 2019 at 04:30:15PM -0700, Ralph Campbell wrote:
> - if (pmd_huge(pmd) && (range->vma->vm_flags & VM_HUGETLB))
> + if (pmd_huge(pmd) && is_vm_hugetlb_page(vma))
> return hmm_pfns_bad(start, end, walk);
This one is not a minor cleanup.. I think it should be
On Tue, 23 Jul 2019, Kees Cook wrote:
> On Wed, Jul 24, 2019 at 12:59:03AM +0200, Thomas Gleixner wrote:
> > And as we have sys_clock_gettime64() exposed for 32bit anyway you need to
> > deal with that in seccomp independently of the VDSO. It does not make sense
> > to treat sys_clock_gettime()
Hi all,
After merging the input-current tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
drivers/input/mouse/elantech.c: In function 'elantech_use_host_notify':
drivers/input/mouse/elantech.c:1843:6: warning: this statement may fall through
[-Wimplicit-fallthrough=]
On Wed, Jul 24, 2019 at 12:59:03AM +0200, Thomas Gleixner wrote:
> And as we have sys_clock_gettime64() exposed for 32bit anyway you need to
> deal with that in seccomp independently of the VDSO. It does not make sense
> to treat sys_clock_gettime() differently than sys_clock_gettime64(). They
>
Mmap /dev/dax more than once, then read the poison location using address
from one of the mappings. The other mappings due to not having the page
mapped in will cause SIGKILLs delivered to the process. SIGKILL succeeds
over SIGBUS, so user process looses the opportunity to handle the UE.
Although
On 7/23/19 7:27 AM, Dmitry Osipenko wrote:
23.07.2019 6:43, Dmitry Osipenko пишет:
23.07.2019 6:31, Sowjanya Komatineni пишет:
On 7/22/19 8:25 PM, Dmitry Osipenko wrote:
23.07.2019 6:09, Sowjanya Komatineni пишет:
On 7/22/19 8:03 PM, Dmitry Osipenko wrote:
23.07.2019 4:52, Sowjanya
On Wed, Jul 17, 2019 at 09:29:52PM -0600, Kelsey Skunberg wrote:
> pci_bus_sem is not used by a loadable kernel module and does not need to
> be exported. Remove line exporting pci_bus_sem.
>
> Signed-off-by: Kelsey Skunberg
Applied to pci/hide for v5.4, thanks!
> ---
> drivers/pci/search.c |
[+cc Greg]
On Wed, Jul 17, 2019 at 12:23:53PM -0600, Kelsey Skunberg wrote:
> pci_bus_get() and pci_bus_put() are not used by a loadable kernel module
> and do not need to be exported. Remove lines exporting pci_bus_get() and
> pci_bus_put().
>
> Functions were exported in commit fe830ef62ac6
fm_set_max_frm() existed in the Freescale SDK as a callback for an
early_param. When this code was ported to the upstream kernel the
early_param was converted to a module_param making the reference to the
function incorrect. The rest of the comment already does a good job of
explaining the
On Mon, Jul 15, 2019 at 02:34:16PM -0600, Kelsey Skunberg wrote:
> Remove the following uncalled functions from include/linux/pci.h:
>
> pci_block_cfg_access()
> pci_block_cfg_access_in_atomic()
> pci_unblock_cfg_access()
>
> Functions were added in commit fb51ccbf217c
A few more comments and minor programming style clean ups.
There should be no functional changes.
Signed-off-by: Ralph Campbell
Cc: "Jérôme Glisse"
Cc: Jason Gunthorpe
Cc: Christoph Hellwig
---
mm/hmm.c | 34 --
1 file changed, 16 insertions(+), 18
Here are two more patches for things I found to clean up.
I assume this will go into Jason's tree since there will likely be
more HMM changes in this cycle.
Ralph Campbell (2):
mm/hmm: a few more C style and comment clean ups
mm/hmm: make full use of walk_page_range()
mm/hmm.c | 231
hmm_range_snapshot() and hmm_range_fault() both call find_vma() and
walk_page_range() in a loop. This is unnecessary duplication since
walk_page_range() calls find_vma() in a loop already.
Simplify hmm_range_snapshot() and hmm_range_fault() by defining a
walk_test() callback function to filter
On Tue, Jul 23, 2019 at 03:23:36PM -0700, Andrew Morton wrote:
> On Tue, 23 Jul 2019 15:17:00 -0700 syzbot
> wrote:
>
> > syzbot has bisected this bug to:
> >
> > commit af49a63e101eb62376cc1d6bd25b97eb8c691d54
> > Author: Matthew Wilcox
> > Date: Sat May 21 00:03:33 2016 +
> >
> >
On Tue, Jul 23, 2019 at 06:07:01PM -0500, Bjorn Helgaas wrote:
> On Thu, Jul 11, 2019 at 04:23:30PM -0600, Kelsey Skunberg wrote:
> > Move symbols defined in include/linux/pci.h that are only used in
> > drivers/pci/ to drivers/pci/pci.h.
> >
> > Symbols only used in drivers/pci/ do not need to
On Tue, Jul 16, 2019 at 1:15 AM Sasha Levin wrote:
>
> From: "Eric W. Biederman"
>
> [ Upstream commit 72abe3bcf0911d69b46c1e8bdb5612675e0ac42c ]
>
> The locking in force_sig_info is not prepared to deal with a task that
> exits or execs (as sighand may change). The is not a locking problem
>
On Tue, Jul 23, 2019 at 05:56:04PM -0500, Bjorn Helgaas wrote:
> On Tue, Jul 23, 2019 at 1:59 PM Kelsey Skunberg
> wrote:
> >
> > acpi_evaluate_object will already return an error if the needed method
> > does not exist. Remove unnecessary acpi_has_method() calls and check the
> > returned
Hello,
syzbot found the following crash on:
HEAD commit:3bfe1fc4 Merge tag 'for-5.3/dm-changes-2' of git://git.ker..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=130322afa0
kernel config: https://syzkaller.appspot.com/x/.config?x=dcfc65ee492509c6
On Thu, Jul 11, 2019 at 04:23:30PM -0600, Kelsey Skunberg wrote:
> Move symbols defined in include/linux/pci.h that are only used in
> drivers/pci/ to drivers/pci/pci.h.
>
> Symbols only used in drivers/pci/ do not need to be visible to the rest of
> the kernel.
>
> Kelsey Skunberg (11):
>
On 23.07.19 09:06, Florian Eckert wrote:
I'd like to ack only the keycode change, but not the deprecated .gpio
field. I'll post a separate patch for the keycode change only.
I am fine if we only change the keycode.
Do I have to send a v2 patch set?
already sent one.
--
Enrico Weigelt,
On Tue, 23 Jul 2019, Kees Cook wrote:
> On Mon, Jul 22, 2019 at 04:47:36PM -0700, Andy Lutomirski wrote:
> > I don't love this whole concept, but I also don't have a better idea.
>
> How about we revert the vDSO change? :P
Sigh. Add more special case code to the VDSO again?
> I keep coming back
101 - 200 of 876 matches
Mail list logo
