On Wed, Jan 17, 2018 at 10:48:33AM +0100, Martin Schwidefsky wrote:
> @Greg: I have started with the backports for the stable kernel releases,
> but unless the interface for gmp/nospec_ptr/nospec_load is cast in stone
> does it make sense to send them?
No, I can't take anything until it is in Linu
On Wed, Jan 17, 2018 at 11:39 AM, Peter Rosin wrote:
> On 2018-01-17 10:35, Linus Walleij wrote:
>> I would first try to add the gpio range in the DTS. Then the
>> GPIO core will add the range (the code is in drivers/gpio/gpiolib-of.c)
>> and everything will be happy.
>
> If I, in the above menti
On Wed, Jan 03, 2018 at 02:09:20PM +0800, Jeffy Chen wrote:
> The for_each_matching_node_and_match() would return every matching
> nodes including unavailable ones.
>
> It's pointless to init unavailable IOMMUs, so add a sanity check to
> avoid that.
>
> Signed-off-by: Jeffy Chen
> ---
>
> dri
On Wed, Jan 17, 2018 at 12:55:06PM +0100, Martin Schwidefsky wrote:
> On Wed, 17 Jan 2018 12:14:52 +0100
> Christian Borntraeger wrote:
>
> > On 01/17/2018 11:03 AM, Florian Weimer wrote:
> > > On 01/17/2018 10:48 AM, Martin Schwidefsky wrote:
> > >> rc = syscall(__NR_s390_modify_bp);
On 1/6/2018 1:20 PM, Kohli, Gaurav wrote:
On 1/6/2018 2:35 AM, Alan Cox wrote:
On Sat, 6 Jan 2018 01:54:36 +0530
"Kohli, Gaurav" wrote:
Hi Alan,
Sorry correcting the typo here:
+retval = tty_ldisc_lock(tty, 5 * HZ);
+if (retval)
+ goto err_release_lock;
tty->port->itty = tty;
/*
* St
On Mon, 2018-01-15 at 13:30:03 UTC, Michal Suchanek wrote:
> Commit 6e032b350cd1 ("powerpc/powernv: Check device-tree for RFI flush
> settings") uses u64 in asm/hvcall.h without including linux/types.h
>
> This breaks hvcall.h users that do not include the header themselves.
>
> Fixes: 6e032b350c
There can be a race, if receive_buf call comes before
tty initialization completes in n_tty_open and tty->disc_data
may be NULL.
CPU0CPU1
000|n_tty_receive_buf_common() n_tty_open()
-001|n_tty_receive_buf2()
On Tue, Jan 02, 2018 at 04:29:45PM +0100, Geert Uytterhoeven wrote:
> When exposing data access through debugfs, the correct
> debugfs_create_*() functions must be used, depending on data type.
>
> Remove all casts from data pointers passed to debugfs_create_*()
> functions, as such casts prevent
On 17/01/18 12:25, Dave Martin wrote:
On Wed, Jan 17, 2018 at 10:05:56AM +, Suzuki K Poulose wrote:
When a CPU is brought up after we have finalised the system
wide capabilities (i.e, features and errata), we make sure the
new CPU doesn't need a new errata work around which has not been
dete
Hi Ayan,
On Fri, Jan 12, 2018 at 04:33:07PM +, Ayan Halder wrote:
> Mali dp needs to disable pixel alpha blending (use layer alpha blending) to
> display color formats that do not contain alpha bits per pixel
In the future, please mention any dependencies on other patches that are
not part of
On 17/01/18 12:25, Dave Martin wrote:
On Wed, Jan 17, 2018 at 10:05:56AM +, Suzuki K Poulose wrote:
When a CPU is brought up after we have finalised the system
wide capabilities (i.e, features and errata), we make sure the
new CPU doesn't need a new errata work around which has not been
dete
On Wed, 17 Jan 2018 09:03:48 +
Matt Redfearn wrote:
> Hi,
>
> On Wed, Jan 17, 2018 at 09:51:21AM +0300, Antony Pavlov wrote:
> > The commit b35cd9884fa5 ("lib: Add shared copies of
> > some GCC library routines") makes it possible
> > to share generic GCC library routines by several
> > arch
In x86 architecture dependend part function
get_cpuid_str() mallocs a 128 byte buffer, but does not
check if the memory allocation succeeded or not.
When the memory allocation fails, function __get_cpuid()
is called with first parameter being a NULL pointer.
However this function references its fir
On 01/17/2018 10:48 AM, Xishi Qiu wrote:
> On 2018/1/17 17:16, Vlastimil Babka wrote:
>
>> On 12/29/2017 09:58 AM, Xishi Qiu wrote:
>>> When calling vfree(), it calls unmap_vmap_area() to clear page table,
>>> but do not free the memory of page table, why? just for performance?
>>
>> I guess it's
On Wed, 2018-01-17 at 13:22 +0100, Paul Menzel wrote:
>
> Yes it does. Thank you. Rebuilding Linux 4.15-rc8+ with this patch
> applied, the UBSAN doesn’t report this issue anymore.
Thanks for testing, the patch is on its way to get to 4.15 (hopefully)
johannes
On 09.01.2018 06:17, Jaejoong Kim wrote:
> 2017-12-20 16:09 GMT+09:00 Jaejoong Kim :
>> Ignore the *.gcda files generated by gcov
>>
>> Signed-off-by: Jaejoong Kim
>> ---
>> .gitignore | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/.gitignore b/.gitignore
>> index 0c39aa2..580ef7c 10
On Wed 2018-01-17 11:18:56, Sergey Senozhatsky wrote:
> On (01/16/18 10:45), Steven Rostedt wrote:
> [..]
> > > [1] https://marc.info/?l=linux-mm&m=145692016122716
> >
> > Especially since Konstantin is working on pulling in all LKML archives,
> > the above should be denoted as:
> >
> > Link:
>
On Tue, Dec 19, 2017 at 12:37:47AM -0500, Sinan Kaya wrote:
> pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
> where a PCI device is present. This restricts the device drivers to be
> reused for other domain numbers.
>
> Getting ready to remove pci_get_bus_and_slot() functi
On 16/01/18 13:25, Jeffy Chen wrote:
There would be some masters sharing the same IOMMU device. Put them in
the same iommu group and share the same iommu domain.
Signed-off-by: Jeffy Chen
---
Changes in v2: None
drivers/iommu/rockchip-iommu.c | 39 +++
1
On 15.1.2018 11:19, Arnd Bergmann wrote:
> On Mon, Jan 15, 2018 at 11:14 AM, Michal Simek wrote:
>> On 15.1.2018 10:29, Arnd Bergmann wrote:
>>> On Sun, Jan 14, 2018 at 2:01 AM, kbuild test robot wrote:
Hi Arnd,
I love your patch! Yet something to improve:
[auto build tes
Sounds great for us (Nuvoton).
Avi.
On Wed, Jan 17, 2018 at 8:32 AM, Wang, Haiyue
wrote:
>
>
> On 2018-01-17 07:06, Joel Stanley wrote:
>>
>> On Tue, Jan 16, 2018 at 2:59 PM, Corey Minyard wrote:
>>>
>>> On 01/16/2018 05:43 AM, Haiyue Wang wrote:
The KCS (Keyboard Controller Style) in
On 01/17/2018 08:47 PM, JeffyChen wrote:
+static struct iommu_group *rk_iommu_device_group(struct device *dev)
+{
+struct iommu_group *group;
+int ret;
+
+group = iommu_group_get(dev);
+if (!group) {
This check is pointless - if dev->iommu_group were non-NULL you wouldn't
have
On Wed, 17 Jan 2018, Stephen Rothwell wrote:
> On Wed, 17 Jan 2018 13:23:17 +0100 (CET) Thomas Gleixner
> wrote:
> > No. Keep it and lets next time coordinate the relevant bits and pieces
> > better. I reserve that bit 20 and let Linus sort out the trivial conflict
> > when merging the stuff.
>
On 17.01.2018 00:13, Oleg Nesterov wrote:
> On 01/16, Kirill Tkhai wrote:
>>
>> On 15.01.2018 23:51, Oleg Nesterov wrote:
>>>
kill:
- force_sig(SIGKILL, p);
+ send_sig(SIGKILL, p, 1);
>>>
>>> Agreed, I didn't actually want to use force_sig(SIGKILL), copy-and-paste
Hi Robin,
On 01/17/2018 08:31 PM, Robin Murphy wrote:
On 16/01/18 13:25, Jeffy Chen wrote:
IOMMU drivers are supposed to call this function instead of manually
creating a group in their .add_device callback. This behavior is not
strictly required by ARM DMA mapping implementation, but ARM64 alr
Hi,
Sorry for the basic mistakes, posted new patch V1.
On 1/17/2018 5:39 PM, Thomas Gleixner wrote:
On Wed, 17 Jan 2018, Thomas Gleixner wrote:
On Wed, 17 Jan 2018, Lingutla Chandrasekhar wrote:
And please fix the subject line:
kernel: time:
is not the proper subsystem prefix.
git log
Hi Robin,
On 01/17/2018 08:18 PM, Robin Murphy wrote:
@@ -91,7 +92,6 @@ struct rk_iommu {
void __iomem **bases;
int num_mmu;
int *irq;
Nit: irq seems to be redundant now as well.
oops, will fix it.
-int num_irq;
bool reset_disabled;
struct iommu_device io
FYI, we noticed the following commit (built with gcc-7):
commit: c0033af7eec3e728c6b70d75950e632ace4c8a55 ("hugetlbfs: Convert to
fs_context")
https://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git mount-context
in testcase: trinity
with following parameters:
runtime: 300s
In case when timers are migrated to a CPU, after it exits
idle, but before timer base is forwarded, either from
run_timer_softirq()/mod_timer()/add_timer_on(), it's
possible that migrated timers are queued, based on older
clock value. This can cause delays in handling those timers.
For example, co
Hi Thomas,
On Wed, 17 Jan 2018 13:23:17 +0100 (CET) Thomas Gleixner
wrote:
>
> On Wed, 17 Jan 2018, Paolo Bonzini wrote:
> > On 17/01/2018 12:45, Thomas Gleixner wrote:
> > > On Wed, 17 Jan 2018, Stephen Rothwell wrote:
> > >> [This is the same conflict I reported the day before yesterday, b
On Wed, 17 Jan 2018, Martin Schwidefsky wrote:
> Implement nospec_load() and nospec_ptr() for s390 with the new
> gmb() barrier between the boundary condition and the load that
> may not be done speculatively.
FWIW the naming seems to be changing constantly. The latest patchset from
Dan Williams
There were made several efforts to make __do_SAK()
working in process context long ago, but it does
not solves the problem completely. Since __do_SAK()
may take tasklist_lock for a long time, the concurent
processes, waiting for write lock with interrupts
disabled (e.g., forking), get into the same
This reverts commit 20ac94378de5.
send_sig() does not take tasklist_lock for a long time,
so this commit and the problem it solves are not relevant
anymore.
Also, the problem of force_sig() is it clears SIGNAL_UNKILLABLE
flag, thus even global init may be killed by __do_SAK(),
which is definitely
From: Oleg Nesterov
The patch makes __do_SAK() iterate a next thread files
only in case of the thread's files are different
to previous. I.e., if all threads points the same
files_struct, the files will be iterated only once.
Since all threads have the same files_struct is
the generic case for m
Hi,
this patchset makes __do_SAK() to take tasklist_lock for very small time
in comparison to that it does now. Though this function is executed
in process context and it takes tasklist_lock read locked with interrupts
enabled,
another tasks may want to take it for writing with interrupt disabled
On Wed, Jan 17, 2018 at 12:15:05PM +, Dave Martin wrote:
> On Wed, Jan 17, 2018 at 11:57:09AM +, Russell King - ARM Linux wrote:
> > On Tue, Jan 16, 2018 at 04:28:50PM -0600, Eric W. Biederman wrote:
> > > I will keep FPE_FIXME as a place holder until this gets sorted out.
> > >
> > > Ther
From: yuzhoujian
Introduce a new option to print counts for fixed number of times
and update perf-stat documentation accordingly.
Show below is the output of the new option for perf stat.
$perf stat -I 1000 --times-print 2 -e cycles -a
# time counts unit ev
From: yuzhoujian
Introduce a new option to print counts for fixed number of times
and update perf-stat documentation accordingly.
Show below is the output of the new option for perf stat.
$perf stat -I 1000 --times-print 2 -e cycles -a
# time counts unit ev
On Wed, 17 Jan 2018, Paolo Bonzini wrote:
> On 17/01/2018 13:23, Thomas Gleixner wrote:
> > No. Keep it and lets next time coordinate the relevant bits and pieces
> > better. I reserve that bit 20 and let Linus sort out the trivial conflict
> > when merging the stuff.
>
> Thank you. In the future
On 17/01/2018 13:23, Thomas Gleixner wrote:
> On Wed, 17 Jan 2018, Paolo Bonzini wrote:
>> On 17/01/2018 12:45, Thomas Gleixner wrote:
>>> On Wed, 17 Jan 2018, Stephen Rothwell wrote:
[This is the same conflict I reported the day before yesterday, but one
of the commits has moved and anot
Hi,
Thanks for your comments.
On 01/17/18 at 09:57am, Petr Mladek wrote:
> On Wed 2018-01-17 12:50:57, Dave Young wrote:
> > It is useful to print kdump kernel loaded status in dump_stack()
> > especially when panic happens so that we can differenciate
> > kdump kernel early hang and a normal p
On 16/01/18 13:25, Jeffy Chen wrote:
IOMMU drivers are supposed to call this function instead of manually
creating a group in their .add_device callback. This behavior is not
strictly required by ARM DMA mapping implementation, but ARM64 already
relies on it. This patch fixes the rockchip-iommu d
On 16/01/18 17:35, Ingo Molnar wrote:
>
> * Juergen Gross wrote:
>
>> On 16/01/18 16:46, Ingo Molnar wrote:
>>>
>>> * Juergen Gross wrote:
>>>
There seem to exist several grub2 versions trashing
boot_params.hdr.acpi_rsdp_addr.
So don't just believe this address to be valid,
On Wed, Jan 17, 2018 at 4:19 PM, Tomasz Figa wrote:
>
> P.S. Looks like your email client is set to HTML messages. Your
> messages might end up dropped from the mailing list.
Never mind. Looks like gmail started displaying quotations in plain
text as graphics.
Best regards,
Tomasz
On Tuesday 16 January 2018 10:21 PM, David Lechner wrote:
>>> +static struct clk *davinci_psc_clk_register(const char *name,
>>> + const char *parent_name,
>>> + struct regmap *regmap,
>>> + u32 lpsc, u32 pd, u32 flags)
>>> +{
>>
On Wed, Jan 17, 2018 at 10:05:56AM +, Suzuki K Poulose wrote:
> When a CPU is brought up after we have finalised the system
> wide capabilities (i.e, features and errata), we make sure the
> new CPU doesn't need a new errata work around which has not been
> detected already. However we don't ru
On Wed, 17 Jan 2018, Paolo Bonzini wrote:
> On 17/01/2018 12:45, Thomas Gleixner wrote:
> > On Wed, 17 Jan 2018, Stephen Rothwell wrote:
> >> [This is the same conflict I reported the day before yesterday, but one
> >> of the commits has moved and another that contributed has been dropped.]
> >> di
Dear Johannes,
On 01/04/18 16:08, Johannes Berg wrote:
Hi,
Can you reproduce this?
[ 54.426491] UBSAN: Undefined behaviour in net/wireless/nl80211.c:718:4
[ 54.426492] signed integer overflow:
[ 54.426493] -1665903437 * 100 cannot be represented in type 'int'
Obviously.
However, it
On Thu, 4 Jan 2018, Yang Shi wrote:
> There are nested loops on debug objects free path, sometimes it may take
> over hundred thousands of loops, then cause soft lockup with !CONFIG_PREEMPT
> occasionally, like below:
Please trim back traces. The whole module info and whatever is completely
irrel
On 17/01/18 12:49, Rafael J. Wysocki wrote:
> On Tue, Jan 16, 2018 at 2:57 PM, Juergen Gross wrote:
>> There seem to exist several grub2 versions trashing
>> boot_params.hdr.acpi_rsdp_addr.
>>
>> So don't just believe this address to be valid, but verify it pointing
>> to a valid RSDP table.
>>
>>
On Tuesday 16 January 2018 10:46 PM, David Lechner wrote:
>>> +static const struct davinci_psc_clk_info da830_psc0_info[]
>>> __initconst = {
>>> + LPSC(0, 0, tpcc, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
>>> + LPSC(1, 0, tptc0, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
>>> + LPSC(2, 0, tptc1, pll0
On 16/01/18 13:25, Jeffy Chen wrote:
Suggested-by: Robin Murphy
Signed-off-by: Jeffy Chen
---
Changes in v2: None
drivers/iommu/rockchip-iommu.c | 38 +++---
1 file changed, 11 insertions(+), 27 deletions(-)
diff --git a/drivers/iommu/rockchip-iommu.c b/dri
On 17/01/2018 12:45, Thomas Gleixner wrote:
> On Wed, 17 Jan 2018, Stephen Rothwell wrote:
>> [This is the same conflict I reported the day before yesterday, but one
>> of the commits has moved and another that contributed has been dropped.]
>> diff --cc arch/x86/include/asm/cpufeatures.h
>> index
On Wed, Jan 17, 2018 at 11:57:09AM +, Russell King - ARM Linux wrote:
> On Tue, Jan 16, 2018 at 04:28:50PM -0600, Eric W. Biederman wrote:
> > I will keep FPE_FIXME as a place holder until this gets sorted out.
> >
> > There is a second issue I am looking at in this location,
> > and maybe I d
Hi,
On Wed, Jan 17, 2018 at 1:47 AM, Guo Yi wrote:
> This patch fix the bluetooth 6lowpan disconnect fail bug.
>
> The type of the same address type have different define value in HCI layer
> and L2CAP layer.That makes disconnect fail due to wrong network type.User
> will not be able to disconnec
Hi,
On 17/01/18 11:54, Julien Thierry wrote:
This series is a continuation of the work started by Daniel [1]. The goal
is to use GICv3 interrupt priorities to simulate an NMI.
I have submitted a separate series making use of this feature for the
ARM PMUv3 interrupt [1].
[1] https://www.sp
On Wed, 17 Jan 2018, Thomas Gleixner wrote:
> On Wed, 17 Jan 2018, Lingutla Chandrasekhar wrote:
And please fix the subject line:
kernel: time:
is not the proper subsystem prefix.
git log should give you a hint.
Aside of that the text after the prefix starts with an uppercase letter.
Than
The trailing semicolon is an empty statement that does no operation.
Removing it since it doesn't do anything.
Signed-off-by: Luis de Bethencourt
---
Hi,
After fixing the same thing in drivers/staging/rtl8723bs/, Joe Perches
suggested I fix it treewide [0].
Best regards,
Luis
[0]
http://dri
On Wed, 17 Jan 2018, Lingutla Chandrasekhar wrote:
> In case when timers are migrated to a CPU, after it exits
> idle, but before timer base is forwarded, either from
> run_timer_softirq()/mod_timer()/add_timer_on(), it's
> possible that migrated timers are queued, based on older
> clock value. Th
On 01/17/2018 01:00 PM, Cornelia Huck wrote:
> On Wed, 17 Jan 2018 10:48:33 +0100
> Martin Schwidefsky wrote:
>
>> This patch series implements multiple mitigations for the speculative
>> execution findings:
>> 1. The definition of the gmb() barrier as currently used by the
>>distributions,
On Wed 2018-01-17 11:19:53, Byungchul Park wrote:
> On 1/10/2018 10:24 PM, Petr Mladek wrote:
> > From: Steven Rostedt
> > By Petr Mladek about possible new deadlocks:
> >
> > The thing is that we move console_sem only to printk() call
> > that normally calls console_unlock() as well. It means th
see V4 discussion.. :)
I didn't see any v4
Hi Alexey,
On 2018-01-16, Alexey Dobriyan wrote:
> do_task_stat() accesses IP and SP of a task without bumping reference
> count of a stack (which became an entity with independent lifetime at
> some point).
>
> Steps to reproduce:
>
> #include
> #include
> #include
> #include
> #include
> #
On 17 January 2018 at 10:19, Will Deacon wrote:
> On Tue, Jan 16, 2018 at 02:08:32PM +, Mark Rutland wrote:
>> Currently the arm/arm64 runtime code registers the runtime servies
>> pagetables with ptdump regardless of whether runtime services page
>> tables have been created.
>>
>> As efi_mm.p
On Wed, 17 Jan 2018 10:48:33 +0100
Martin Schwidefsky wrote:
> This patch series implements multiple mitigations for the speculative
> execution findings:
> 1. The definition of the gmb() barrier as currently used by the
>distributions, we may have to find a better name for it
> 2. The archit
Hi Greg,
On Wed, Jan 17, 2018 at 12:14:02PM +0100, Greg KH wrote:
> On Wed, Jan 17, 2018 at 01:08:58PM +0200, Heikki Krogerus wrote:
> > Hi,
> >
> > On Wed, Jan 17, 2018 at 09:30:45AM +, shufan_lee(?) wrote:
> > > Dear Heikki,
> > >
> > > Sorry for bothering.
> > >
> > > Just wa
On Tuesday 16 January 2018 10:51 PM, David Lechner wrote:
> On 01/16/2018 08:00 AM, Sekhar Nori wrote:
>> On Monday 08 January 2018 07:47 AM, David Lechner wrote:
>>> +void __init da850_psc_clk_init(void __iomem *psc0, void __iomem *psc1)
>>> +{
>>> + struct clk_onecell_data *clk_data;
>>> +
>>>
On Tue, Jan 16, 2018 at 04:28:50PM -0600, Eric W. Biederman wrote:
> I will keep FPE_FIXME as a place holder until this gets sorted out.
>
> There is a second issue I am looking at in this location,
> and maybe I don't have to address it now. But it looks like the code is
> calling send_sig_info
On Wed, 17 Jan 2018 12:14:52 +0100
Christian Borntraeger wrote:
> On 01/17/2018 11:03 AM, Florian Weimer wrote:
> > On 01/17/2018 10:48 AM, Martin Schwidefsky wrote:
> >> rc = syscall(__NR_s390_modify_bp);
> >> if (rc) {
> >> perror("s390_modify_bp");
> >>
From: Daniel Thompson
Currently alternatives are applied very late in the boot process (and
a long time after we enable scheduling). Some alternative sequences,
such as those that alter the way CPU context is stored, must be applied
much earlier in the boot sequence.
Introduce apply_alternatives
arm64 does not provide native NMIs. Emulate the NMI behaviour using GIC
priorities.
Add the possibility to set an IRQ as an NMI and the handling of the NMI.
If the view of GIC priorities is the secure one (i.e. SCR_EL3.FIQ == 0), do
not allow the use of NMIs. Emit a warning when attempting to set
The values non secure EL1 needs to use for priority registers depends on
the value of SCR_EL3.FIQ.
Since we don't have access to SCR_EL3, we fake an interrupt and compare the
GIC priority with the one present in the [re]distributor.
Also, add firmware requirements related to SCR_EL3.
Signed-off-
Add functions to read/write priorities to the GIC [re]distributor.
Signed-off-by: Julien Thierry
Cc: Thomas Gleixner
Cc: Jason Cooper
Cc: Marc Zyngier
---
drivers/irqchip/irq-gic-common.c | 10 ++
drivers/irqchip/irq-gic-common.h | 2 ++
2 files changed, 12 insertions(+)
diff --git
From: Daniel Thompson
Currently irqflags is implemented using the PSR's I bit. It is possible
to implement irqflags by using the co-processor interface to the GIC.
Using the co-processor interface makes it feasible to simulate NMIs
using GIC interrupt prioritization.
This patch changes the irqfl
Hi,
This series is a continuation of the work started by Daniel [1]. The goal
is to use GICv3 interrupt priorities to simulate an NMI.
To achieve this, set two priorities, one for standard interrupts and
another, higher priority, for NMIs. Whenever we want to disable interrupts,
we mask the stand
From: Daniel Thompson
Currently it is not possible to detect features of the boot CPU
until the other CPUs have been brought up.
This prevents us from reacting to features of the boot CPU until
fairly late in the boot process. To solve this we allow a subset
of features (that are likely to be co
From: Colin Ian King
The pointer mos_parport is being initialized to pp->private_data and
then the assignment is duplicated after a spin lock. Remove the
initialization as it occurs before the spin lock and it is a redundant
assignment.
Cleans up clang warnings:
drivers/usb/serial/mos7720.c:521
On Wed, 10 Jan 2018 16:43:23 +0100,
Takashi Iwai wrote:
>
> On Wed, 10 Jan 2018 16:23:43 +0100,
> Mika Westerberg wrote:
> >
> > On Wed, Jan 10, 2018 at 04:13:51PM +0100, Takashi Iwai wrote:
> > > Hi,
> > >
> > > on the recent kernels, i2c-i801 skips the creation of iTCO wdt when
> > > ACPI WDAT
In case when timers are migrated to a CPU, after it exits
idle, but before timer base is forwarded, either from
run_timer_softirq()/mod_timer()/add_timer_on(), it's
possible that migrated timers are queued, based on older
clock value. This can cause delays in handling those timers.
For example, co
On 17/01/2018 12:14, Christian Borntraeger wrote:
>
>
> On 01/17/2018 11:03 AM, Florian Weimer wrote:
>> On 01/17/2018 10:48 AM, Martin Schwidefsky wrote:
>>> rc = syscall(__NR_s390_modify_bp);
>>> if (rc) {
>>> perror("s390_modify_bp");
>>> exi
On Tue, Jan 16, 2018 at 2:57 PM, Juergen Gross wrote:
> There seem to exist several grub2 versions trashing
> boot_params.hdr.acpi_rsdp_addr.
>
> So don't just believe this address to be valid, but verify it pointing
> to a valid RSDP table.
>
> Signed-off-by: Juergen Gross
> ---
> To be applied
On Tue, Jan 16, 2018 at 06:14:58PM -0800, David Rientjes wrote:
> There are three significant concerns about the cgroup aware oom killer as
> it is implemented in -mm:
>
> (1) allows users to evade the oom killer by creating subcontainers or
> using other controllers since scoring is done pe
On Tue, Jan 16, 2018 at 04:28:50PM -0600, Eric W. Biederman wrote:
> Dave Martin writes:
>
> > On Mon, Jan 15, 2018 at 11:23:03AM -0600, Eric W. Biederman wrote:
> >> Dave Martin writes:
> >>
> >> > On Thu, Jan 11, 2018 at 06:59:36PM -0600, Eric W. Biederman wrote:
> >> >> Setting si_code to 0
On Wed, 17 Jan 2018, Stephen Rothwell wrote:
> [This is the same conflict I reported the day before yesterday, but one
> of the commits has moved and another that contributed has been dropped.]
> diff --cc arch/x86/include/asm/cpufeatures.h
> index aa09559b2c0b,19f35be95f16..
> --- a/ar
On 2018年01月17日 19:07, Xin Long wrote:
On Wed, Jan 10, 2018 at 2:20 AM, Dmitry Vyukov wrote:
Hello,
syzkaller has hit the following memory leak on 4.15-rc7.
Reproducer is attached.
unreeferenced object 0x88002c9ac400 (size 4096):
comm "syz-executor0", pid 12349, jiffies 4295751114 (ag
On 01/17/2018 12:33 PM, David Hildenbrand wrote:
>
>> #define ECB_GS 0x40
>> #define ECB_TE 0x10
>> #define ECB_SRSI0x04
>> diff --git a/arch/s390/include/uapi/asm/kvm.h
>> b/arch/s390/include/uapi/asm/kvm.h
>> index 38535a57..20b9e9f 100644
>> --- a/arch/s390/i
On 17/01/18 05:26, Tomasz Figa wrote:
On Tue, Jan 16, 2018 at 10:25 PM, Jeffy Chen wrote:
It's hard to undo bus_set_iommu() in the error path, so move it to the
end of rk_iommu_probe().
Does this work fine now? I remember we used to need this called in an
early initcall for all the ARM/ARM64
> #define ECB_GS 0x40
> #define ECB_TE 0x10
> #define ECB_SRSI 0x04
> diff --git a/arch/s390/include/uapi/asm/kvm.h
> b/arch/s390/include/uapi/asm/kvm.h
> index 38535a57..20b9e9f 100644
> --- a/arch/s390/include/uapi/asm/kvm.h
> +++ b/arch/s390/include/uapi/asm/
Replace pointer comparison to 0 with NULL in prepare_ftrace_return
to improve code readability. Identified with coccinelle script
'badzero.cocci'.
Signed-off-by: Mathieu Malaterre
---
arch/mips/kernel/ftrace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/mips/kernel/f
On 17/01/2018 12:29, Christian Borntraeger wrote:
>> The problem is not that I announce the facility, I in fact announce that the
>> programmatic interface is available (the sebc sync reg and the usage of that
>> field).
>> (So the CAP is part of this patch to have both in lockstep)
>> A non-exist
On 01/17/2018 12:28 PM, Christian Borntraeger wrote:
>
>
> On 01/17/2018 12:22 PM, Paolo Bonzini wrote:
>>> while this is kvm code, my current plan is to submit the "final"
>>> version after review and probably some fixes/renames via Martin
>>> together with the other patches. Are you ok with
On 01/17/2018 12:22 PM, Paolo Bonzini wrote:
>> while this is kvm code, my current plan is to submit the "final"
>> version after review and probably some fixes/renames via Martin
>> together with the other patches. Are you ok with that? Right now it
>> seems that the CAP number is still fine.
>
There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.
Signed-off-by: Wei Yongjun
---
drivers/slimbus/qcom-ctrl.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/slimbus/qcom-ctrl.c b/drivers/slim
The patch
ASoC: Intel: remove second duplicated assignment to pointer 'res'
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 2
From: Colin Ian King
The functions devlink_resource_find and devlink_resource_validate_children
are local to the source and do not need to be in global scope, so make
them static.
Cleans up sparse warnings:
symbol 'devlink_resource_find' was not declared. Should it be static?
warning: symbol 'de
There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.
Signed-off-by: Wei Yongjun
---
drivers/memory/ti-emif-pm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/memory/ti-emif-pm.c b/drivers/memory/ti-emif-pm.c
inde
Remove unneeded error handling on the result of a call
to platform_get_resource() when the value is passed to
devm_ioremap_resource().
Signed-off-by: Wei Yongjun
---
drivers/phy/broadcom/phy-brcm-usb.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/phy/broadcom/phy-brcm-usb.c
b/
> while this is kvm code, my current plan is to submit the "final"
> version after review and probably some fixes/renames via Martin
> together with the other patches. Are you ok with that? Right now it
> seems that the CAP number is still fine.
Sure, though there will be a capability introduced b
There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.
Signed-off-by: Wei Yongjun
---
drivers/perf/hisilicon/hisi_uncore_ddrc_pmu.c | 4 +---
drivers/perf/hisilicon/hisi_uncore_hha_pmu.c | 4 +---
drivers/perf/hisilicon/hisi_un
Fix to return a negative error code from the request_irq() error
handling case instead of 0, as done elsewhere in this function.
Signed-off-by: Wei Yongjun
---
drivers/char/ipmi/ipmi_powernv.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/char/ipmi/ipmi_powernv
1001 - 1100 of 1318 matches
Mail list logo
