Hi Martin,
Thanks for the review, we really appreciate your time.
Please see my comments below.
On 2019/9/6 4:15, Martin Blumenstingl wrote:
> Hi Jianxin,
>
> (it's great to see that you and your team are upstreaming this early)
>
> On Thu, Sep 5, 2019 at 9:08 AM Jianxin Pan wrote:
> [...]
>>
The following commit has been merged into the x86/cpu branch of tip:
Commit-ID: 6e1c32c5dbb4b90eea8f964c2869d0bde050dbe0
Gitweb:
https://git.kernel.org/tip/6e1c32c5dbb4b90eea8f964c2869d0bde050dbe0
Author:Gayatri Kammela
AuthorDate:Thu, 05 Sep 2019 12:30:17 -07:00
The following commit has been merged into the x86/cpu branch of tip:
Commit-ID: 0f65605a8d744b3a205d0a2cd8f20707e31fc023
Gitweb:
https://git.kernel.org/tip/0f65605a8d744b3a205d0a2cd8f20707e31fc023
Author:Gayatri Kammela
AuthorDate:Thu, 05 Sep 2019 12:30:18 -07:00
The following commit has been merged into the x86/cpu branch of tip:
Commit-ID: 855fa1f362cab2dc7574acb853b0963dd01d6b8d
Gitweb:
https://git.kernel.org/tip/855fa1f362cab2dc7574acb853b0963dd01d6b8d
Author:Rahul Tanwar
AuthorDate:Thu, 05 Sep 2019 12:30:19 -07:00
Committer:
The following commit has been merged into the x86/platform branch of tip:
Commit-ID: 864b23f0169d5bff677e8443a7a90dfd6b090afc
Gitweb:
https://git.kernel.org/tip/864b23f0169d5bff677e8443a7a90dfd6b090afc
Author:Austin Kim
AuthorDate:Fri, 06 Sep 2019 08:29:51 +09:00
The following commit has been merged into the x86/cpu branch of tip:
Commit-ID: 0cc5359d8fd45bc410906e009117e78e2b5b2322
Gitweb:
https://git.kernel.org/tip/0cc5359d8fd45bc410906e009117e78e2b5b2322
Author:Rahul Tanwar
AuthorDate:Thu, 05 Sep 2019 12:30:20 -07:00
Committer:
On Fri, Sep 06, 2019 at 07:54:41AM +0300, Oded Gabbay wrote:
> On Fri, Sep 6, 2019 at 7:38 AM Oded Gabbay wrote:
> >
> > On Thu, Sep 5, 2019 at 11:50 PM Greg KH wrote:
> > >
> > > On Thu, Sep 05, 2019 at 03:19:34PM +0300, Oded Gabbay wrote:
> > > > Hello Greg,
> > > >
> > > > This is the pull
On Thu, Sep 05, 2019 at 01:03:46PM +0300, Felipe Balbi wrote:
> This a bit confusing, really. Specially when the comment right above
> those flags states:
>
> /* PTP_xxx bits, for the flags field within the request structures. */
Agreed, it is confusing. Go ahead and remove this comment.
>
Quoting Jack Pham (2019-09-05 10:58:02)
> Hi Jorge, Bjorn,
>
> On Thu, Sep 05, 2019 at 09:18:57AM +0200, Jorge Ramirez wrote:
> > On 9/4/19 01:34, Bjorn Andersson wrote:
> > > On Tue 03 Sep 14:45 PDT 2019, Stephen Boyd wrote:
> > >> that would need an of_regulator_get() sort of API that can get
> +/* How many bytes left in this page. */
> +static unsigned int rest_of_page(void *data)
> +{
> + return PAGE_SIZE - offset_in_page(data);
> +}
Not needed.
> +/* Create sg_table from a vmalloc'd buffer. */
> +static struct sg_table *vmalloc_to_sgt(char *data, uint32_t size, int
>
Quoting Vinod Koul (2019-09-05 22:10:17)
> SM8150 UFS PHY is v4 of QMP phy. Add support for V4 QMP phy register
> defines and support for SM8150 QMP UFS PHY.
>
> Signed-off-by: Vinod Koul
> Reviewed-by: Bjorn Andersson
> ---
Reviewed-by: Stephen Boyd
Quoting YueHaibing (2019-09-05 20:30:06)
> When do coccicheck, I get this error:
>
> spatch -D report --no-show-diff --very-quiet --cocci-file
> ./scripts/coccinelle/api/platform_get_irq.cocci --include-headers
> --dir . -I ./arch/x86/include -I ./arch/x86/include/generated -I ./include
> -I
Hi,
On 06/09/2019 03:48, Ming Lei wrote:
[ ... ]
>> You did not share yet the analysis of the problem (the kernel warnings
>> give the symptoms) and gave the reasoning for the solution. It is hard
>> to understand what you are looking for exactly and how to connect the dots.
>
> Let me
On 04-09-19, 01:18, Jassi Brar wrote:
> On Wed, Sep 4, 2019 at 12:51 AM Vinod Koul wrote:
> >
> > On 18-08-19, 00:17, jassisinghb...@gmail.com wrote:
> > > From: Jassi Brar
> > >
> > > Document the devicetree bindings for Socionext Milbeaut HDMAC
> > > controller. Controller has upto 8 floating
Document "qcom,sdm845-qmp-ufs-phy" compatible string for QMP UFS PHY
found on SM8150.
Signed-off-by: Vinod Koul
Reviewed-by: Bjorn Andersson
Reviewed-by: Stephen Boyd
---
Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff
SM8150 UFS PHY is v4 of QMP phy. Add support for V4 QMP phy register
defines and support for SM8150 QMP UFS PHY.
Signed-off-by: Vinod Koul
Reviewed-by: Bjorn Andersson
---
drivers/phy/qualcomm/phy-qcom-qmp.c | 125
drivers/phy/qualcomm/phy-qcom-qmp.h | 96
This series adds compatible strings for ufs hc and ufs qmp phy found in
Qualcomm SM8150 SoC. Also update the qmp phy driver with version 4 and
support for ufs phy.
Changes since v1:
- make the numbers a lower case hex
- add review tags recieved
Vinod Koul (3):
dt-bindings: ufs: Add sm8150
Document "qcom,sm8150-ufshc" compatible string for UFS HC found on
SM8150.
Signed-off-by: Vinod Koul
Reviewed-by: Bjorn Andersson
Reviewed-by: Stephen Boyd
---
Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt | 1 +
1 file changed, 1 insertion(+)
diff --git
On Fri, 6 Sep 2019, YueHaibing wrote:
> When do coccicheck, I get this error:
>
> spatch -D report --no-show-diff --very-quiet --cocci-file
> ./scripts/coccinelle/api/platform_get_irq.cocci --include-headers
> --dir . -I ./arch/x86/include -I ./arch/x86/include/generated -I ./include
> -I
On Mon, Aug 12, 2019 at 02:15:32PM +0200, Christoph Hellwig wrote:
> On Sun, Aug 11, 2019 at 04:55:27AM -0400, Michael S. Tsirkin wrote:
> > On Sun, Aug 11, 2019 at 07:56:07AM +0200, Christoph Hellwig wrote:
> > > So we need a flag on the virtio device, exposed by the
> > > hypervisor (or hardware
Update the gcc qcs404 clock driver to use floor ops for sdcc clocks. As
disuccsed in [1] it is good idea to use floor ops for sdcc clocks as we
dont want the clock rates to do round up.
[1]:
https://lore.kernel.org/linux-arm-msm/20190830195142.103564-1-swb...@chromium.org/
Signed-off-by: Vinod
On Fri, Sep 6, 2019 at 7:38 AM Oded Gabbay wrote:
>
> On Thu, Sep 5, 2019 at 11:50 PM Greg KH wrote:
> >
> > On Thu, Sep 05, 2019 at 03:19:34PM +0300, Oded Gabbay wrote:
> > > Hello Greg,
> > >
> > > This is the pull request for habanalabs driver for kernel 5.4.
> > >
> > > It contains one major
On 9/5/19 12:33 PM, Grygorii Strashko wrote:
Hi Santosh,
On 06/07/2019 02:48, santosh.shilim...@oracle.com wrote:
On 7/5/19 8:12 AM, Grygorii Strashko wrote:
Hi Santosh,
This series is set of platform changes required to enable NETCP CPTS
reference
clock selection and final patch to enable
On Tue, Sep 03, 2019 at 09:38:07AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:6d028043 Add linux-next specific files for 20190830
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=179e59de60
> kernel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi Linus,
Please pull some more powerpc fixes for 5.3:
The following changes since commit ed4289e8b48845888ee46377bd2b55884a55e60b:
Revert "powerpc: slightly improve cache helpers" (2019-07-31 22:56:27 +1000)
are available in the git
>Subject: Re: [PATCH 1/4] softirq: implement IRQ flood detection mechanism
>
>
>On 06/09/2019 03:22, Long Li wrote:
>[ ... ]
>>
>
>> Tracing shows that the CPU was in either hardirq or softirq all the
>> time before warnings. During tests, the system was unresponsive at
>> times.
>>
>> Ming's
On 05-09-19, 22:35, Arnd Bergmann wrote:
> Soundwire gained a warning for randconfig builds without
> CONFIG_ACPI during the linux-5.3-rc cycle:
>
> drivers/soundwire/slave.c:16:12: error: unused function 'sdw_slave_add'
> [-Werror,-Wunused-function]
>
> Add the CONFIG_ACPI dependency at the
On Thu, Sep 5, 2019 at 11:50 PM Greg KH wrote:
>
> On Thu, Sep 05, 2019 at 03:19:34PM +0300, Oded Gabbay wrote:
> > Hello Greg,
> >
> > This is the pull request for habanalabs driver for kernel 5.4.
> >
> > It contains one major change, the creation of an additional char device
> > per PCI
Now that all users of references have moved to reference properties,
we can remove separate handling of references.
Signed-off-by: Dmitry Torokhov
---
drivers/base/swnode.c| 31 +--
include/linux/property.h | 26 ++
2 files changed, 15
Now that static device properties allow defining reference properties
together with all other types of properties, instead of managing them
separately, let's adjust the driver.
Signed-off-by: Dmitry Torokhov
---
Heikki, I do not have this hardware, so if you could try this out
it would be
It is possible to store references to software nodes in the same fashion as
other static properties, so that users do not need to define separate
structures:
const struct software_node gpio_bank_b_node = {
.name = "B",
};
const struct property_entry simone_key_enter_props[] __initconst =
On 06/09/2019 03:22, Long Li wrote:
[ ... ]
>
> Tracing shows that the CPU was in either hardirq or softirq all the
> time before warnings. During tests, the system was unresponsive at
> times.
>
> Ming's patch fixed this problem. The system was responsive throughout
> tests.
>
> As for
On (09/05/19 12:03), Qian Cai wrote:
> > ---
> > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> > index cd51aa7d08a9..89cb47882254 100644
> > --- a/kernel/printk/printk.c
> > +++ b/kernel/printk/printk.c
> > @@ -2027,8 +2027,11 @@ asmlinkage int vprintk_emit(int facility, int
On 04-09-19, 16:23, Stephen Boyd wrote:
> Quoting Vinod Koul (2019-09-04 03:08:35)
> > @@ -878,6 +883,93 @@ static const struct qmp_phy_init_tbl
> > msm8998_usb3_pcs_tbl[] = {
> > QMP_PHY_INIT_CFG(QPHY_V3_PCS_RXEQTRAINING_RUN_TIME, 0x13),
> > };
> >
> > +static const struct
Invalidate PAXB inbound/outbound address mapping each time before
programming it. This is helpful for the cases where we need to
reprogram inbound/outbound address mapping without resetting PAXB.
kexec kernel is one such example.
Signed-off-by: Abhishek Shah
Reviewed-by: Ray Jui
Reviewed-by:
Add virtual command queue support.
Signed-off-by: Baolin Wang
---
drivers/mmc/host/Kconfig |1 +
drivers/mmc/host/sdhci-sprd.c | 16
2 files changed, 17 insertions(+)
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index e2a12c3..851e947 100644
---
Add cqhci_virt_finalize_request() to help to complete a request
from virtual command queue.
Signed-off-by: Baolin Wang
---
drivers/mmc/host/sdhci.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index
The struct cqhci_slot will be used by virtual command queue introducing
by following patches, thus move it to the header file.
Signed-off-by: Baolin Wang
---
drivers/mmc/host/cqhci.c | 10 --
drivers/mmc/host/cqhci.h | 11 ++-
2 files changed, 10 insertions(+), 11
Now the MMC read/write stack will always wait for previous request is
completed by mmc_blk_rw_wait(), before sending a new request to hardware,
or queue a work to complete request, that will bring context switching
overhead, especially for high I/O per second rates, to affect the IO
performance.
Hi All,
Now the MMC read/write stack will always wait for previous request is
completed by mmc_blk_rw_wait(), before sending a new request to hardware,
or queue a work to complete request, that will bring context switching
overhead, especially for high I/O per second rates, to affect the IO
On Thu, 5 Sep 2019 at 21:11, Vitaly Kuznetsov wrote:
>
> Wanpeng Li writes:
>
> > On Thu, 5 Sep 2019 at 16:53, syzbot
> > wrote:
> >>
> >> Hello,
> >>
> >> syzbot found the following crash on:
> >>
> >> HEAD commit:3b47fd5c Merge tag 'nfs-for-5.3-4' of
> >> git://git.linux-nfs...
> >> git
On (09/05/19 13:23), Steven Rostedt wrote:
> > I think we can queue significantly much less irq_work-s from printk().
> >
> > Petr, Steven, what do you think?
[..]
> I mean, really, do we need to keep calling wake up if it
> probably never even executed?
I guess ratelimiting you are talking
>Subject: RE: [Patch v3] storvsc: setup 1:1 mapping between hardware queue
>and CPU queue
>
>From: Long Li Sent: Thursday, September 5, 2019 3:55
>PM
>>
>> storvsc doesn't use a dedicated hardware queue for a given CPU queue.
>> When issuing I/O, it selects returning CPU (hardware queue)
>>
On 9/6/2019 4:31 AM, Martin Blumenstingl wrote:
Hi Dilip,
On Wed, Sep 4, 2019 at 12:11 PM Dilip Kota wrote:
[...]
+properties:
+ compatible:
+const: intel,lgm-pcie
should we add the "snps,dw-pcie" here (and in the example below) as well?
(this is what for example
On Thu, 2019-09-05 at 10:03 +0200, Vlastimil Babka wrote:
> On 9/4/19 4:24 PM, Walter Wu wrote:
> > On Wed, 2019-09-04 at 16:13 +0200, Vlastimil Babka wrote:
> >> On 9/4/19 4:06 PM, Walter Wu wrote:
> >>
> >> The THP fix is not required for the rest of the series, it was even merged
> >> to
> >>
Fix a logic flaw in the way membarrier_register_private_expedited()
handles ready state checks for private expedited sync core and private
expedited registrations.
If a private expedited membarrier registration is first performed, and
then a private expedited sync_core registration is performed,
This series of fixes/cleanups is submitted for feedback. It takes care
of membarrier issues recently discussed.
Thanks,
Mathieu
Mathieu Desnoyers (4):
Fix: sched/membarrier: private expedited registration check
Cleanup: sched/membarrier: remove redundant check
Cleanup: sched/membarrier:
The membarrier_state field is located within the mm_struct, which
is not guaranteed to exist when used from runqueue-lock-free iteration
on runqueues by the membarrier system call.
Copy the membarrier_state from the mm_struct into the scheduler runqueue
in the scheduler prepare task switch when
Checking that the number of threads is 1 is redundant with checking
mm_users == 1.
Suggested-by: Oleg Nesterov
Signed-off-by: Mathieu Desnoyers
Cc: "Paul E. McKenney"
Cc: Peter Zijlstra
Cc: Oleg Nesterov
Cc: "Eric W. Biederman"
Cc: Linus Torvalds
Cc: Russell King - ARM Linux admin
Cc:
When the prev and next task's mm change, switch_mm() provides the core
serializing guarantees before returning to usermode. The only case
where an explicit core serialization is needed is when the scheduler
keeps the same mm for prev and next.
Suggested-by: Oleg Nesterov
Signed-off-by: Mathieu
On 05-09-19, 07:32, Tony Lindgren wrote:
> Acked-by: Tony Lindgren
Do you want to pick the series instead as this has lots of DT changes
?
--
viresh
The connect() system call for a UDP socket is for setting the destination
address and port. But the current code mistakenly sets the source address
for the socket as well. Remove the source address setting in connect() for
UDP in this patch.
Implications of the bug:
- Packet drop:
On a
On 05-09-19, 07:32, Tony Lindgren wrote:
> * H. Nikolaus Schaller [190904 08:54]:
> > This adds code and tables to read the silicon revision and
> > eFuse (speed binned / 720 MHz grade) bits for selecting
> > opp-v2 table entries.
> >
> > Since these bits are not always part of the syscon
On Thu, Sep 05, 2019 at 06:15:43PM -0700, Daniel Colascione wrote:
[snip]
> > > > > > > The bigger improvement with the threshold is the number of trace
> > > > > > > records are
> > > > > > > almost halved by using a threshold. The number of records went
> > > > > > > from 4.6K to
> > > > > > >
On Fri, Aug 30, 2019 at 10:10:24PM -0500, Eric Biggers wrote:
> From: Eric Biggers
>
> syzbot reported an invalid free in debugfs_release_dentry(). The
> reproducer tries to mount debugfs with the 'dirsync' option, which is
> not allowed. The bug is that if reconfigure_super() fails in
>
On Fri, Sep 6, 2019 at 4:26 AM Andrii Nakryiko
wrote:
>
> On Tue, Sep 3, 2019 at 11:20 PM Masahiro Yamada
> wrote:
> >
> > On Wed, Sep 4, 2019 at 3:00 PM Stephen Rothwell
> > wrote:
> > >
> > > Hi all,
> > >
> > > After merging the net-next tree, today's linux-next build (arm
> > >
On (09/05/19 13:14), Steven Rostedt wrote:
> > Hmm, from the article,
> >
> > https://en.wikipedia.org/wiki/Universal_asynchronous_receiver-transmitter
> >
> > "Since transmission of a single or multiple characters may take a long time
> > relative to CPU speeds, a UART maintains a flag showing
On Tue, Sep 3, 2019 at 1:37 PM Chris Chiu wrote:
>
> The RTL8723BU suffers the wifi disconnection problem while bluetooth
> device connected. While wifi is doing tx/rx, the bluetooth will scan
> without results. This is due to the wifi and bluetooth share the same
> single antenna for RF
Due to:
* Current implementation of l2cap_config_rsp() dropping BT
connection if sender of configuration response replied with unknown
option failure (Result=0x0003/L2CAP_CONF_UNKNOWN)
* Current implementation of l2cap_build_conf_req() adding
L2CAP_CONF_RFC(0x04) option to initial
From: Ben Chuang
Add support for the GL9750 and GL9755 chipsets.
Enable v4 mode and wait 5ms after set 1.8V signal enable for GL9750/
GL9755. Fix the value of SDHCI_MAX_CURRENT register and use the vendor
tuning flow for GL9750.
Co-developed-by: Michael K Johnson
Signed-off-by: Michael K
From: Ben Chuang
Export sdhci_abort_tuning() function symbols which are used by other SD Host
controller driver modules.
Signed-off-by: Ben Chuang
Co-developed-by: Michael K Johnson
Signed-off-by: Michael K Johnson
Acked-by: Adrian Hunter
---
drivers/mmc/host/sdhci.c | 3 ++-
From: Ben Chuang
Add the Genesys Logic, Inc. vendor ID to pci_ids.h.
Signed-off-by: Ben Chuang
Co-developed-by: Michael K Johnson
Signed-off-by: Michael K Johnson
Acked-by: Adrian Hunter
---
include/linux/pci_ids.h | 2 ++
1 file changed, 2 insertions(+)
diff --git
From: Ben Chuang
The GL9750 and GL9755 chipsets, and possibly others, require PLL Enable
setup as part of the internal clock setup as described in 3.2.1 Internal
Clock Setup Sequence of SD Host Controller Simplified Specification
Version 4.20.
Signed-off-by: Ben Chuang
Co-developed-by: Michael
From: Ben Chuang
According to section 3.2.1 internal clock setup in SD Host Controller
Simplified Specifications 4.20, the timeout of loop for checking
internal clock stable is defined as 150ms.
Signed-off-by: Ben Chuang
Co-developed-by: Michael K Johnson
Signed-off-by: Michael K Johnson
From: Ben Chuang
The patches modify internal clock setup to match SD Host Controller
Simplified Specifications 4.20 and support Genesys Logic GL9750/GL9755
chipsets.
v8:
refine codes in sdhci-gli-pci.c
- remove duplicate assignment
- remove redundant delay
- use '!!'(not not) logical
v4:
- pick r-b
- swap the last two patches [Sean]
v3:
- use unsigned int for vcpu id [Sean]
- a new patch to fix ple_window type [Sean]
v2:
- fix commit messages, change format of ple window tracepoint [Sean]
- rebase [Wanpeng]
Each small patch explains itself. I noticed them when I'm tracing
The VMX ple_window is 32 bits wide, so logically it can overflow with
an int. The module parameter is declared as unsigned int which is
good, however the dynamic variable is not. Switching all the
ple_window references to use unsigned int.
The tracepoint changes will also affect SVM, but SVM is
It's done by TP_printk() already.
Reviewed-by: Krish Sadhukhan
Reviewed-by: Sean Christopherson
Signed-off-by: Peter Xu
---
arch/x86/kvm/trace.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/trace.h b/arch/x86/kvm/trace.h
index 20d6cac9f157..8a7570f8c943
The PLE window tracepoint triggers even if the window is not changed,
and the wording can be a bit confusing too. One example line:
kvm_ple_window: vcpu 0: ple_window 4096 (shrink 4096)
It easily let people think of "the window now is 4096 which is
shrinked", but the truth is the value
Tracing the ID helps to pair vmenters and vmexits for guests with
multiple vCPUs.
Reviewed-by: Krish Sadhukhan
Reviewed-by: Sean Christopherson
Signed-off-by: Peter Xu
---
arch/x86/kvm/trace.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/trace.h
On 9/5/2019 7:24 AM, Andrey Konovalov wrote:
> On Thu, Sep 5, 2019 at 4:20 AM Hui Peng wrote:
>>
>> Can you guys have a look at the attached patch?
>
> Let's try it:
>
> #syz test: https://github.com/google/kasan.git eea39f24
>
> FYI: there are two more reports coming from this driver,
On Thu, 5 Sep 2019 at 21:16, Vitaly Kuznetsov wrote:
>
> Wanpeng Li writes:
>
> > From: Wanpeng Li
> >
> > Reported by syzkaller:
> >
> > kasan: GPF could be caused by NULL-ptr deref or user memory access
> > general protection fault: [#1] PREEMPT SMP KASAN
> > RIP:
Hi Daniel,
On Thu, Sep 05, 2019 at 12:37:13PM +0200, Daniel Lezcano wrote:
>
> Hi Ming,
>
> On 05/09/2019 11:06, Ming Lei wrote:
> > On Wed, Sep 04, 2019 at 07:31:48PM +0200, Daniel Lezcano wrote:
> >> Hi,
> >>
> >> On 04/09/2019 19:07, Bart Van Assche wrote:
> >>> On 9/3/19 12:50 AM, Daniel
Hi,
Here is the 3rd version of patches to handle Xen/KVM emulate
prefix by x86 instruction decoder.
These patches allow x86 instruction decoder to decode
Xen and KVM emulate prefix correctly, and prohibit kprobes to
probe on it.
Josh reported that the objtool can not decode such special
Prohibit probing on instruction which has XEN_EMULATE_PREFIX
or KVM's emulate prefix. Since that prefix is a marker for Xen
and KVM, if we modify the marker by kprobe's int3, that doesn't
work as expected.
Signed-off-by: Masami Hiramatsu
---
arch/x86/kernel/kprobes/core.c |4
1 file
Decode Xen and KVM's emulate-prefix signature by x86 insn decoder.
It is called "prefix" but actually not x86 instruction prefix, so
this adds insn.emulate_prefix_size field instead of reusing
insn.prefixes.
If x86 decoder finds a special sequence of instructions of
XEN_EMULATE_PREFIX and 'ud2a;
padata_do_parallel currently returns -EINVAL if the callback CPU isn't
in the callback cpumask.
pcrypt tries to prevent this situation by keeping its own callback
cpumask in sync with padata's and checks that the callback CPU it passes
to padata is valid. Make padata handle this instead.
On Thu, 2019-09-05 at 09:57 +0530, Nagarjuna Kristam wrote:
>
> On 04-09-2019 16:00, Chunfeng Yun wrote:
> > On Wed, 2019-09-04 at 13:53 +0530, Nagarjuna Kristam wrote:
> >> This patch adds UDC driver for tegra XUSB 3.0 device mode controller.
> >> XUSB device mode controller supports SS, HS and
On Thu, 5 Sep 2019 20:13:50 -0500
Josh Poimboeuf wrote:
> On Fri, Sep 06, 2019 at 09:50:19AM +0900, Masami Hiramatsu wrote:
> > --- a/tools/objtool/sync-check.sh
> > +++ b/tools/objtool/sync-check.sh
> > @@ -4,6 +4,7 @@
> > FILES='
> > arch/x86/include/asm/inat_types.h
> >
Use common 1413X/1416X PLL clock structure to save a lot
of duplicated code on i.MX8MN clock driver.
Signed-off-by: Anson Huang
---
Changes since V1:
- Changes according to patch 1/2, now PLL table/structure is in pll14xx
driver.
---
drivers/clk/imx/clk-imx8mn.c | 89
Many i.MX8M SoCs use same 1443X/1416X PLL, such as i.MX8MM,
i.MX8MN and later i.MX8M SoCs, moving these PLL definitions
to pll14xx driver can save a lot of duplicated code on each
platform.
Meanwhile, no need to define PLL clock structure for every
module which uses same type of PLL, e.g.,
From: Wanpeng Li
Even if for realtime CPUs, cache line bounces, frequency scaling, presence
of higher-priority RT tasks, etc can still cause different response. These
interferences should be considered and periodically revaluate whether
or not the lapic_timer_advance_ns value is the best, do
From: Wanpeng Li
Using a moving average based on per-vCPU lapic_timer_advance_ns to tune
smoothly, filter out drastic fluctuation which prevents this before,
let's assume it is 1 cycles.
Cc: Paolo Bonzini
Cc: Radim Krčmář
Signed-off-by: Wanpeng Li
---
arch/x86/kvm/lapic.c | 18
From: Wanpeng Li
The hrtimer which is used to emulate lapic timer is stopped during
vcpu reset, preemption timer should do the same.
Cc: Paolo Bonzini
Cc: Radim Krčmář
Signed-off-by: Wanpeng Li
---
arch/x86/kvm/vmx/vmx.c | 1 +
1 file changed, 1 insertion(+)
diff --git
From: Wanpeng Li
This patch optimizes the virtual IPI emulation sequence:
write ICR2 write ICR2
write ICR read ICR2
read ICR==>send virtual IPI
read ICR2 write ICR
send virtual IPI
It can reduce
From: Wanpeng Li
Reported by syzkaller:
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: [#1] PREEMPT SMP KASAN
RIP: 0010:__apic_accept_irq+0x46/0x740 arch/x86/kvm/lapic.c:1029
Call Trace:
On Sat, Aug 31, 2019 at 12:59:10AM +0300, Daniel Baluta wrote:
> From: Viorel Suman
>
> This is to allow machine drivers to set a certain bitclk rate
> which might not be exactly rate * frame size.
Just a quick thought of mine: slot_width and slots could be
set via set_dai_tdm_slot() actually,
BDW boards using this machine driver supports only stereo capture and
playback. Implement a constraint to enforce it.
Signed-off-by: Brent Lu
---
sound/soc/intel/boards/bdw-rt5677.c | 33 +
1 file changed, 33 insertions(+)
diff --git
Hi Eric,
On 2019/7/26 17:58, Eric Dumazet wrote:
>
>
> On 7/26/19 11:17 AM, Shaokun Zhang wrote:
>> From: Yang Guo
>>
>> There is an significant performance regression with the following
>> commit-id
>> ("net: get rid of an signed integer overflow in ip_idents_reserve()").
>>
>>
>
> So, you
On Fri, Aug 30, 2019 at 11:09:00PM +0300, Daniel Baluta wrote:
> From: Mihai Serban
>
> EDMA requires the period size to be multiple of maxburst. Otherwise the
> remaining bytes are not transferred and thus noise is produced.
>
> We can handle this issue by adding a constraint on
>
>Subject: Re: [PATCH 1/4] softirq: implement IRQ flood detection mechanism
>
>
>Hi Ming,
>
>On 05/09/2019 11:06, Ming Lei wrote:
>> On Wed, Sep 04, 2019 at 07:31:48PM +0200, Daniel Lezcano wrote:
>>> Hi,
>>>
>>> On 04/09/2019 19:07, Bart Van Assche wrote:
On 9/3/19 12:50 AM, Daniel Lezcano
On Thu, Sep 5, 2019 at 5:59 PM Joel Fernandes wrote:
> On Thu, Sep 05, 2019 at 10:50:27AM -0700, Daniel Colascione wrote:
> > On Thu, Sep 5, 2019 at 10:35 AM Steven Rostedt wrote:
> > > On Thu, 5 Sep 2019 09:03:01 -0700
> > > Suren Baghdasaryan wrote:
> > >
> > > > On Thu, Sep 5, 2019 at 7:43
On Fri, Sep 06, 2019 at 09:50:19AM +0900, Masami Hiramatsu wrote:
> --- a/tools/objtool/sync-check.sh
> +++ b/tools/objtool/sync-check.sh
> @@ -4,6 +4,7 @@
> FILES='
> arch/x86/include/asm/inat_types.h
> arch/x86/include/asm/orc_types.h
> +arch/x86/include/asm/xen/prefix.h
>
On Fri, Aug 30, 2019 at 10:41:10AM +0900, Austin Kim wrote:
> If the CONFIG_BUG is enabled, BUG is executed and then system is crashed.
> However, the bailout for mount is no longer proceeding.
>
> Using WARN_ON_ONCE rather than BUG can prevent this situation.
>
> Signed-off-by: Austin Kim
Hi, Leonard
> On 05.09.2019 12:59, Anson Huang wrote:
> > Many i.MX8M SoCs use same 1443X/1416X PLL, such as i.MX8MM,
> i.MX8MN
> > and later i.MX8M SoCs, moving these PLL definitions to common place
> > can save a lot of duplicated code on each platform.
>
> There are lots of similarities
On Thu, Sep 05, 2019 at 10:50:27AM -0700, Daniel Colascione wrote:
> On Thu, Sep 5, 2019 at 10:35 AM Steven Rostedt wrote:
> > On Thu, 5 Sep 2019 09:03:01 -0700
> > Suren Baghdasaryan wrote:
> >
> > > On Thu, Sep 5, 2019 at 7:43 AM Michal Hocko wrote:
> > > >
> > > > [Add Steven]
> > > >
> > >
- On Sep 4, 2019, at 2:26 PM, Peter Zijlstra pet...@infradead.org wrote:
> On Wed, Sep 04, 2019 at 01:12:53PM -0400, Mathieu Desnoyers wrote:
>> - On Sep 4, 2019, at 12:09 PM, Peter Zijlstra pet...@infradead.org wrote:
>>
>> > On Wed, Sep 04, 2019 at 11:19:00AM -0400, Mathieu Desnoyers
Prohibit probing on instruction which has XEN_EMULATE_PREFIX
or KVM's emulate prefix. Since that prefix is a marker for Xen
and KVM, if we modify the marker by kprobe's int3, that doesn't
work as expected.
Signed-off-by: Masami Hiramatsu
---
arch/x86/kernel/kprobes/core.c |4
1 file
Hi,
Here is the 2nd version of patches to handle Xen/KVM emulate
prefix by x86 instruction decoder.
These patches allow x86 instruction decoder to decode
Xen and KVM emulate prefix correctly, and prohibit kprobes to
probe on it.
Josh reported that the objtool can not decode such special
Decode Xen and KVM's emulate-prefix signature by x86 insn decoder.
It is called "prefix" but actually not x86 instruction prefix, so
this adds insn.emulate_prefix_size field instead of reusing
insn.prefixes.
If x86 decoder finds a special sequence of instructions of
XEN_EMULATE_PREFIX and 'ud2a;
1 - 100 of 1076 matches
Mail list logo
