Hi Martin,
On 2019/4/19 3:44, Martin Blumenstingl wrote:
Hi Liang,
On Mon, Apr 15, 2019 at 8:04 AM Liang Yang wrote:
On 2019/4/12 6:00, Martin Blumenstingl wrote:
Documentation/scheduler/completion.txt states:
Calling init_completion() on the same completion object twice is
most li
Hi,
On Thu, Apr 18, 2019 at 04:46:45PM +0200, Lubomir Rintel wrote:
> This patch set modifies the OLPC battery driver so that it could eventually
> be used on an Arm-based OLPC XO 1.75 machine.
>
> Compared to the previous version, it addresses review comments for the
> x86 platform parts from Th
Hi,
On Thu, Apr 18, 2019 at 08:24:04PM +0200, Artur Rojek wrote:
> Add a driver for battery present on Ingenic JZ47xx SoCs.
>
> Signed-off-by: Artur Rojek
> Reviewed-by: Jonathan Cameron
> ---
Thanks, queued.
-- Sebastian
>
> Changes:
>
> v2: - rework the return logic in ingenic_battery_ge
Hi,
On Sun, Apr 14, 2019 at 11:34:54AM +0100, Jonathan Cameron wrote:
> On Sun, 24 Mar 2019 15:27:25 +
> Jonathan Cameron wrote:
>
> > On Sat, 23 Mar 2019 18:28:06 +0100
> > Artur Rojek wrote:
> >
> > > Extend the inkern API with a function for reading available
> > > attribute values of i
Hi,
On Sun, Mar 24, 2019 at 03:30:18PM +, Jonathan Cameron wrote:
> On Sat, 23 Mar 2019 18:28:08 +0100
> Artur Rojek wrote:
>
> > Add documentation for the ingenic-battery driver, used on JZ47xx SoCs.
> >
> > Signed-off-by: Artur Rojek
> Looks fine to me.
>
> Acked-by: Jonathan Cameron
From: YueHaibing
During randconfig builds, I occasionally run into an invalid configuration
drivers/pci/controller/dwc/pci-keystone.o: In function `ks_pcie_link_up':
pci-keystone.c:(.text+0x90): undefined reference to `__dw_pcie_read_dbi'
pci-keystone.c:(.text+0x90): relocation truncated to fit:
From: Jian Shen
In current codes, tx_timeout_cnt is used before increased,
then we can see the tx_timeout_count is still 0 from the
print when tx timeout happens, e.g.
"hns3 :7d:00.3 eth3: tx_timeout count: 0, queue id: 0, SW_NTU:
0xa6, SW_NTC: 0xa4, HW_HEAD: 0xa4, HW_TAIL: 0xa6, INT: 0x1"
From: Weihang Li
This patch allow users to dump content of NCL_CONFIG by using debugfs
command.
Command format:
echo dump ncl_config > cmd
It will print as follows:
hns3 :7d:00.0: offset |data
hns3 :7d:00.0: 0x | 0x0020
hns3 :7d:00.0: 0x00
On Wed, 2019-04-17 at 13:39 +0300, Jarkko Sakkinen wrote:
> In order to provide a mechanism for devilering provisoning rights:
>
> 1. Add a new device file /dev/sgx/provision that works as a token for
>allowing an enclave to have the provisioning privileges.
> 2. Add a new ioctl called SGX_IOC
On Fri, Apr 19, 2019 at 12:36 AM Jessica Yu wrote:
>
> +++ Masahiro Yamada [19/04/19 00:26 +0900]:
> >On Thu, Apr 18, 2019 at 10:52 PM Jessica Yu wrote:
> >>
> >> +++ Masahiro Yamada [18/04/19 20:10 +0900]:
> >> >On Sat, Apr 6, 2019 at 9:15 PM Alexey Gladkov
> >> >wrote:
> >> >>
> >> >> Problem
On 04/18/2019 07:01 PM, PlusOneSecond wrote:
> In ax25_info_show of af_ax25.c:1891, linux-5.1.
> The pointer ax25 is cast to long type to print out.
>
> Why it prints the a pointer 'ax25' use %8.8lx rather than %p?
> If it really want to print the value of ax25, it should use %px.
I guess nobo
On 2019/4/19 10:04, Paul Moore wrote:
On Wed, Apr 17, 2019 at 10:50 PM Yang Yingliang
wrote:
On 2019/4/18 8:24, Casey Schaufler wrote:
On 4/17/2019 4:39 PM, Paul Moore wrote:
Since it looks like all three LSMs which implement the setprocattr
hook are vulnerable I'm open to the idea that pr
1. Using X86_FEATURE_ARCH_CAPABILITIES to enumerate the existence of
MSR_IA32_ARCH_CAPABILITIES to avoid using rdmsrl_safe().
2. Since kvm_get_arch_capabilities() is only used in this file, making
it static.
Signed-off-by: Xiaoyao Li
---
arch/x86/include/asm/kvm_host.h | 1 -
arch/x86/kvm/x86.c
On Fri, Apr 19, 2019 at 8:58 AM Josh Poimboeuf wrote:
>
> I still don't like using regs->bp because it results in different code
> paths for FP and ORC. In the FP case, the regs are treated like real
> regs even though they're fake.
>
> Something like the below would be much simpler. Would this
On Thu, Apr 18, 2019 at 01:01:52PM +0200, Petr Mladek wrote:
> On Thu 2019-04-18 17:00:44, Feng Tang wrote:
> > Hi Petr,
> >
> > On Thu, Apr 18, 2019 at 09:45:52AM +0200, Petr Mladek wrote:
> > > On Thu 2019-04-18 09:00:14, Sergey Senozhatsky wrote:
> > > > I think that PANIC_PRINT_ALL_PRINTK_MSG
On Wed, Apr 17, 2019 at 10:50 PM Yang Yingliang
wrote:
> On 2019/4/18 8:24, Casey Schaufler wrote:
> > On 4/17/2019 4:39 PM, Paul Moore wrote:
> >>
> >> Since it looks like all three LSMs which implement the setprocattr
> >> hook are vulnerable I'm open to the idea that proc_pid_attr_write() is
>
In ax25_info_show of af_ax25.c:1891, linux-5.1.
The pointer ax25 is cast to long type to print out.
Why it prints the a pointer 'ax25' use %8.8lx rather than %p?
If it really want to print the value of ax25, it should use %px.
Also, I scan the kernel code and notice that most of the pointers cas
On (04/17/19 13:53), Petr Mladek wrote:
> Crash in vsprintf() might be silent when it happens under logbuf_lock
> in vprintk_emit(). This patch set prevents most of the crashes by probing
> the address. The check is done only by %s and some %p* specifiers that need
> to dereference the address.
>
>
From: Tzvetomir Stoyanov
Install directories of header and library files are hardcoded in pkg-config
templete file. They must be configurable, the Makefile should set them on the
compilation / install stage.
Link: http://lkml.kernel.org/r/20190329144546.5819-1-tstoya...@vmware.com
Signed-off-
On 2019/4/18 22:01, Jaegeuk Kim wrote:
> On 04/18, Chao Yu wrote:
>> On 2019/4/17 22:03, Jaegeuk Kim wrote:
>>> On 04/17, Chao Yu wrote:
Hi Jaegeuk,
On 2019/4/17 10:31, Stephen Rothwell wrote:
> Hi all,
>
> After merging the block tree, today's linux-next build (x86_64
>>
On Fri, Apr 19, 2019 at 09:17:17AM +0900, Matteo Croce wrote:
> > extern const int sysctl_zero;
> > /* comment goes here */
> > #define SYSCTL_ZERO ((void *)&sysctl_zero)
> >
> > and then use SYSCTL_ZERO everywhere. That centralizes the ugliness
> > and
> > makes it easier to switch over if/when
On 4/18/19 4:22 PM, Kevin Hilman wrote:
Hi Paul,
Paul Walmsley writes:
This series adds a serial driver, with console support, for the
UART IP block present on the SiFive FU540 SoC. The programming
model is straightforward, but unique.
Boot-tested on a SiFive FU540 HiFive-U board, using BBL
The *regmap and *rdev can be replaced by local variables.
The slew_rate is no longer used since commit dd7e71fbeefe
("regulator: fan53555: use set_ramp_delay to set the ramp up slew rate").
Signed-off-by: Axel Lin
---
drivers/regulator/fan53555.c | 36 +---
1 file
On Thu, Apr 18, 2019 at 12:07:30PM -0400, Kairui Song wrote:
> Currently perf callchain doesn't work well when sampling from trace
> point, with ORC unwinder enabled and CONFIG_FRAME_POINTER disabled.
> We'll get useless in kernel callchain like this:
>
> perf 6429 [000]22.498450:
Signed-off-by: Axel Lin
---
drivers/regulator/fan53555.c | 24 ++--
1 file changed, 10 insertions(+), 14 deletions(-)
diff --git a/drivers/regulator/fan53555.c b/drivers/regulator/fan53555.c
index e2caf4173ab5..dbe477da4e55 100644
--- a/drivers/regulator/fan53555.c
+++ b/driv
> Are you saying that on x86, atomic_inc() acts as a full memory barrier
> but not as a compiler barrier, and vice versa for
> smp_mb__after_atomic()? Or that neither atomic_inc() nor
> smp_mb__after_atomic() implements a full memory barrier?
I'd say the former; AFAICT, these boil down to:
On Fri, Apr 19, 2019 at 08:35:36AM +0800, PanBian wrote:
> Yes, I see that. Because the loop start with (--i), there is no put
> operation for the device that fails to create. So, I think we cannot
> rule out the possibility of memory leak.
Ok, so this is not something you trigger - you're basical
On Thu, Apr 18, 2019 at 05:07:45PM -0700, Luck, Tony wrote:
> On Fri, Apr 19, 2019 at 01:29:10AM +0200, Borislav Petkov wrote:
> > Which reminds me, Tony, I think all those debugging files "pfn"
> > and "array" and the one you add now, should all be under a
> > CONFIG_RAS_CEC_DEBUG which is default
I updated the patch with a trival fix.
Could you review it?
- Naoya
From: Naoya Horiguchi
Date: Fri, 19 Apr 2019 09:21:59 +0900
Subject: [PATCH v2] tools/power: turbostat: make output buffer extensible
"turbostat --Dump" could be terminated by general protection fault on
some latest hardwa
On Thu, Apr 18, 2019 at 04:58:22PM -0700, Cong Wang wrote:
> No, it is all about whether we should break users' expectation.
What user expectation?
> This doesn't sounds like a valid reason for us to break users'
> expectation.
I think it is *you* who has some sort of "expectation" but that
"exp
On April 19, 2019 7:40:45 AM GMT+09:00, Andrew Morton
wrote:
> On Wed, 17 Apr 2019 15:15:31 +0200 Matteo Croce
> wrote:
>
> > In the sysctl code the proc_dointvec_minmax() function is often used
> to
> > validate the user supplied value between an allowed range. This
> function
> > uses the ext
On Fri, Apr 19, 2019 at 01:29:10AM +0200, Borislav Petkov wrote:
> Which reminds me, Tony, I think all those debugging files "pfn"
> and "array" and the one you add now, should all be under a
> CONFIG_RAS_CEC_DEBUG which is default off and used only for development.
> Mind adding that too pls?
Pat
The mm-of-the-moment snapshot 2019-04-18-16-58 has been uploaded to
http://www.ozlabs.org/~akpm/mmotm/
mmotm-readme.txt says
README for mm-of-the-moment:
http://www.ozlabs.org/~akpm/mmotm/
This is a snapshot of my -mm patch queue. Uploaded at random hopefully
more than once a week.
You wi
On Thu, Apr 18, 2019 at 4:29 PM Borislav Petkov wrote:
>
> On Thu, Apr 18, 2019 at 03:51:07PM -0700, Cong Wang wrote:
> > On Thu, Apr 18, 2019 at 3:02 PM Tony Luck wrote:
> > >
> > > Useful when running error injection tests that want to
> > > see all of the MCi_(STATUS|ADDR|MISC) data via /dev/m
On 04/18/2019 07:46 PM, Waiman Long wrote:
> v5:
> - Drop v4 patch 1 as it is merged into tip's locking/core branch.
> - Integrate the 2 followup patches into the series. The first
> follow-up patch is broken into 2 pieces. The first piece comes in
> before the "Enable readers spinning
On 64-bit architectures, each rwsem writer will have its unique lock
word for acquiring the lock. Right now, the writer code recomputes the
lock word every time it tries to acquire the lock. This is a waste of
time. The lock word is now cached and reused when it is needed.
When CONFIG_RWSEM_OWNER_
After merging all the relevant rwsem code into one single file, there
are a number of optimizations and cleanups that can be done:
1) Remove all the EXPORT_SYMBOL() calls for functions that are not
accessed elsewhere.
2) Remove all the __visible tags as none of the functions will be
call
With separate count and owner, there are timing windows where the two
values are inconsistent. That can cause problem when trying to figure
out the exact state of the rwsem. For instance, a RT task will stop
optimistic spinning if the lock is acquired by a writer but the owner
field isn't set yet.
Reader optimistic spinning is helpful when the reader critical section
is short and there aren't that many readers around. It makes readers
relatively more preferred than writers. When a writer times out spinning
on a reader-owned lock and set the nospinnable bits, there are two main
reasons for th
Because of writer lock stealing, it is possible that a constant
stream of incoming writers will cause a waiting writer or reader to
wait indefinitely leading to lock starvation.
This patch implements a lock handoff mechanism to disable lock stealing
and force lock handoff to the first waiter or wa
Now we only have one implementation of rwsem. Even though we still use
xadd to handle reader locking, we use cmpxchg for writer instead. So
the filename rwsem-xadd.c is not strictly correct. Also no one outside
of the rwsem code need to know the internal implementation other than
function prototype
The upper bits of the count field is used as reader count. When
sufficient number of active readers are present, the most significant
bit will be set and the count becomes negative. If the number of active
readers keep on piling up, we may eventually overflow the reader counts.
This is not likely t
Before combining owner and count, we are adding two new helpers for
accessing the owner value in the rwsem.
1) struct task_struct *rwsem_get_owner(struct rw_semaphore *sem)
2) bool is_rwsem_reader_owned(struct rw_semaphore *sem)
Signed-off-by: Waiman Long
---
kernel/locking/rwsem.c | 41 +
Bit 1 of sem->owner (RWSEM_ANONYMOUSLY_OWNED) is used to designate an
anonymous owner - readers or an anonymous writer. The setting of this
anonymous bit is used as an indicator that optimistic spinning cannot
be done on this rwsem.
With the upcoming reader optimistic spinning patches, a reader-ow
When the rwsem is owned by reader, writers stop optimistic spinning
simply because there is no easy way to figure out if all the readers
are actively running or not. However, there are scenarios where
the readers are unlikely to sleep and optimistic spinning can help
performance.
This patch provid
This patch modifies rwsem_spin_on_owner() to return four possible
values to better reflect the state of lock holder which enables us to
make a better decision of what to do next.
Signed-off-by: Waiman Long
---
kernel/locking/rwsem.c | 65 ++
1 file changed
An RT task can do optimistic spinning only if the lock holder is
actually running. If the state of the lock holder isn't known, there
is a possibility that high priority of the RT task may block forward
progress of the lock holder if it happens to reside on the same CPU.
This will lead to deadlock.
The current way of using various reader, writer and waiting biases
in the rwsem code are confusing and hard to understand. I have to
reread the rwsem count guide in the rwsem-xadd.c file from time to
time to remind myself how this whole thing works. It also makes the
rwsem code harder to be optimiz
With the use of wake_q, we can do task wakeups without holding the
wait_lock. There is one exception in the rwsem code, though. It is
when the writer in the slowpath detects that there are waiters ahead
but the rwsem is not held by a writer. This can lead to a long wait_lock
hold time especially wh
With the commit 59aabfc7e959 ("locking/rwsem: Reduce spinlock contention
in wakeup after up_read()/up_write()"), the rwsem_wake() forgoes doing
a wakeup if the wait_lock cannot be directly acquired and an optimistic
spinning locker is present. This can help performance by avoiding
spinning on the
This patch enables readers to optimistically spin on a
rwsem when it is owned by a writer instead of going to sleep
directly. The rwsem_can_spin_on_owner() function is extracted
out of rwsem_optimistic_spin() and is called directly by
__rwsem_down_read_failed_common() and __rwsem_down_write_failed
When the front of the wait queue is a reader, other readers
immediately following the first reader will also be woken up at the
same time. However, if there is a writer in between. Those readers
behind the writer will not be woken up.
Because of optimistic spinning, the lock acquisition order is n
v5:
- Drop v4 patch 1 as it is merged into tip's locking/core branch.
- Integrate the 2 followup patches into the series. The first
follow-up patch is broken into 2 pieces. The first piece comes in
before the "Enable readers spinning on writer" and the 2nd piece
is merged into the
The owner field in the rw_semaphore structure is used primarily for
optimistic spinning. However, identifying the rwsem owner can also be
helpful in debugging as well as tracing locking related issues when
analyzing crash dump. The owner field may also store state information
that can be important
Add control of the charging algorithm used on Wilco devices.
See Documentation/ABI/testing/sysfs-class-power-wilco for the
userspace interface and other info.
v5 changes:
-Remove OP_SYNC, it has no immediate use case.
-Merge properties.h into wilco-ec.h
-Remove enum get_set_sync_op from the public
The kzalloc here was being used without checking the return - if the
kzalloc fails return VCHIQ_ERROR. The call-site of
vchiq_platform_init_state() vchiq_init_state() was not responding
to an allocation failure so checks for != VCHIQ_SUCCESS
and pass VCHIQ_ERROR up to vchiq_platform_init() which th
On Thu, Apr 18, 2019 at 10:05:34AM +0200, Takashi Iwai wrote:
> On Thu, 18 Apr 2019 09:53:28 +0200,
> Greg Kroah-Hartman wrote:
> >
> > On Thu, Apr 18, 2019 at 09:38:52AM +0200, Takashi Iwai wrote:
> > > Hi,
> > >
> > > we've got a regression report on the recent 5.0.x kernel, starting
> > > from
On Thu, Apr 18, 2019 at 03:51:07PM -0700, Cong Wang wrote:
> On Thu, Apr 18, 2019 at 3:02 PM Tony Luck wrote:
> >
> > Useful when running error injection tests that want to
> > see all of the MCi_(STATUS|ADDR|MISC) data via /dev/mcelog.
> >
> > Signed-off-by: Tony Luck
>
> We saw the same proble
See comments inline
On Wed, Apr 17, 2019 at 11:15 AM Mohan Kumar wrote:
>
> As per Documentation/timers/timers-howto.txt Msleep < 20ms can sleep for
> up to 20ms. so use usleep_range.
>
> Signed-off-by: Mohan Kumar
> ---
> drivers/iio/proximity/mb1232.c | 2 +-
> drivers/iio/proximity/srf08.c
On Thu, Apr 18, 2019 at 02:52:44PM -0700, Stephen Boyd wrote:
> Quoting Leo Yan (2019-04-17 22:33:39)
> > Hi Michael, Stephen,
> >
> > On Wed, Mar 20, 2019 at 06:05:08PM +0800, Leo Yan wrote:
> > > clk_gate_ufs_subsys is a system bus clock, turning off it will
> > > introduce lockup issue during s
Hi Paul,
Paul Walmsley writes:
> This series adds a serial driver, with console support, for the
> UART IP block present on the SiFive FU540 SoC. The programming
> model is straightforward, but unique.
>
> Boot-tested on a SiFive FU540 HiFive-U board, using BBL and the
> open-source FSBL (with
On 04/18/2019 03:24 PM, Andrew Morton wrote:
> afaict, vfree() will only do a mutex_trylock() in
> try_purge_vmap_area_lazy(). So does vfree actually sleep in any
> situation? Whether or not local interrupts are enabled?
We would be in a big trouble if vfree() could potentially sleep...
Ran
On Thu, Apr 18, 2019 at 11:06 AM Wang YanQing wrote:
>
> I meet below compile errors:
> "
> In file included from test_tcpnotify_kern.c:12:
> /usr/include/netinet/in.h:101:5: error: expected identifier
> IPPROTO_HOPOPTS = 0, /* IPv6 Hop-by-Hop options. */
> ^
> /usr/include/linux/in6.h:
On Mon 15 Apr 03:43 PDT 2019, Georgi Djakov wrote:
> diff --git a/drivers/interconnect/qcom/qcs404.c
> b/drivers/interconnect/qcom/qcs404.c
[..]
> +#define QCS404_MASTER_AMPSS_M0 0
> +#define QCS404_MASTER_GRAPHICS_3D1
> +#define QCS404_MASTER_MDP_PORT0
On Wed, 17 Apr 2019 17:22:00 +0530 Bharath Vedartham
wrote:
> This patch fixes the sparse warning:
>
> fs/reiserfs//xattr.c:453:28: warning: incorrect type in return
> expression (different base types)
> fs/reiserfs//xattr.c:453:28:expected unsigned int
> fs/reiserfs//xattr.c:453:28:got
On Thu, Apr 18, 2019 at 3:02 PM Tony Luck wrote:
>
> Useful when running error injection tests that want to
> see all of the MCi_(STATUS|ADDR|MISC) data via /dev/mcelog.
>
> Signed-off-by: Tony Luck
We saw the same problem, CONFIG_RAS hijacks all the
correctable memory errors, which leaves mcelo
On Mon 15 Apr 03:43 PDT 2019, Georgi Djakov wrote:
> There are separate hardware blocks per each interconnect that allow QoS
> configuration to be applied to each port (node). There are different kinds of
> priorities that could be set on these ports. Each port supports also various
> QoS modes su
On Wed, Apr 17, 2019 at 2:15 PM Luck, Tony wrote:
>
> On Tue, Apr 16, 2019 at 07:37:41PM -0700, Cong Wang wrote:
> > On Tue, Apr 16, 2019 at 7:31 PM Cong Wang wrote:
> > > Yes it is, I have a stacktrace in production which clearly shows
> > > del_elem.isra.1+0x34/0x40, unlike the one I triggered
On Wed, 17 Apr 2019 15:15:31 +0200 Matteo Croce wrote:
> In the sysctl code the proc_dointvec_minmax() function is often used to
> validate the user supplied value between an allowed range. This function
> uses the extra1 and extra2 members from struct ctl_table as minimum and
> maximum allowed v
On Thu, 18 Apr 2019, Thomas Gleixner wrote:
> On Wed, 17 Apr 2019, Daniel Drake wrote:
>
> > The CPUID.0x16 leaf provides "Bus (Reference) Frequency (in MHz)".
> >
> > In the thread "No 8254 PIT & no HPET on new Intel N3350 platforms
> > causes kernel panic during early boot" we are exploring way
On Thu, 18 Apr 2019 04:18:34 -0700 Matthew Wilcox wrote:
> On Wed, Apr 17, 2019 at 02:58:27PM -0700, Andrew Morton wrote:
> > On Wed, 17 Apr 2019 12:40:01 -0700 Roman Gushchin wrote:
> > > +static struct vm_struct *__remove_vm_area(struct vmap_area *va)
> > > +{
> > > + struct vm_struct *vm = va
On Thu, 18 Apr 2019 21:39:25 +0200 "Uladzislau Rezki (Sony)"
wrote:
> On my "Intel(R) Xeon(R) W-2135 CPU @ 3.70GHz" system(12 CPUs)
> i get the warning from the compiler about frame size:
>
>
> warning: the frame size of 1096 bytes is larger than 1024 bytes
> [-Wframe-larger-than=]
>
>
> the
Useful when running error injection tests that want to
see all of the MCi_(STATUS|ADDR|MISC) data via /dev/mcelog.
Signed-off-by: Tony Luck
---
drivers/ras/cec.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/ras/cec.c b/drivers/ras/cec.c
index 2
On 3/28/2019 6:43 PM, Leonard Crestez wrote:
> On Fri, 2019-03-22 at 16:49 +, Abel Vesa wrote:
>> Add generic i.MX8 SoC driver along with the i.MX8MQ SoC specific code.
>> For now, only i.MX8MQ revision B1 is supported. For any other, i.MX8MQ
>> revision it will print 'unknown'.
>
>> +#define
Takashi Iwai [18.04.2019 09:38]:
> Hi,
>
> we've got a regression report on the recent 5.0.x kernel, starting
> from 5.0.6, where Windows XP can't boot on KVM any longer.
Not for all configurations. I just checked with 5.0.8, and Windows XP
boots just fine on KVM.
--
Hilsen Harald
Quoting Paul Cercueil (2019-04-17 04:24:20)
> The pixel clock is directly connected to the output of the PLL, and not
> to the /2 divider.
>
> Cc: sta...@vger.kernel.org
> Fixes: 226dfa4726eb ("clk: Add Ingenic jz4725b CGU driver")
> Signed-off-by: Paul Cercueil
> ---
Applied to clk-next
Quoting Colin King (2019-04-16 04:56:16)
> From: Colin Ian King
>
> There are a few spelling mistakes in comments and a pr_err
> error message. Fix these.
>
> Signed-off-by: Colin Ian King
> ---
Applied to clk-next
Quoting Leo Yan (2019-04-17 22:33:39)
> Hi Michael, Stephen,
>
> On Wed, Mar 20, 2019 at 06:05:08PM +0800, Leo Yan wrote:
> > clk_gate_ufs_subsys is a system bus clock, turning off it will
> > introduce lockup issue during system suspend flow. Let's mark
> > clk_gate_ufs_subsys as critical clock,
On Thu, Apr 18, 2019 at 2:41 PM Song Liu wrote:
>
> On Thu, Apr 18, 2019 at 8:59 AM Alban Crequy wrote:
> >
> > From: Alban Crequy
> >
> > sockops programs can now access the network namespace inode and device
> > via (struct bpf_sock_ops)->netns_ino and ->netns_dev. This can be useful
> > to ap
Vince
On Tue, Apr 16, 2019 at 11:06 PM Ingo Molnar wrote:
>
>
> * Vince Weaver wrote:
>
> > On Tue, 16 Apr 2019, tip-bot for Stephane Eranian wrote:
> >
> > > Commit-ID: f447e4eb3ad1e60d173ca997fcb2ef2a66f12574
> > > Gitweb:
> > > https://git.kernel.org/tip/f447e4eb3ad1e60d173ca997fcb2ef2a
Greg Kroah-Hartman [18.04.2019 09:53]:
> On Thu, Apr 18, 2019 at 09:38:52AM +0200, Takashi Iwai wrote:
>> Hi,
>>
>> we've got a regression report on the recent 5.0.x kernel, starting
>> from 5.0.6, where Windows XP can't boot on KVM any longer.
>>
>> The culprit seems to be the patch
>>KVM:
чт, 18 апр. 2019 г. в 14:12, Jerome Glisse :
>
> On Wed, Apr 10, 2019 at 09:47:01PM -0500, Steve French wrote:
> > How was this discovered? Does it address a reported user problem?
>
> I have spotted it while tracking down how page reference are taken
> for bio and how they are release. In the curr
The commit 475d0487a2ad ("mm: memcontrol: use per-cpu stocks for socket
memory uncharging") added refill_stock() for skmem uncharging path to
optimize workloads having high network traffic. Do the same for the kmem
uncharging as well. However bypass the refill for offlined memcgs to not
cause zombi
On 2019-04-18 19:25, Ray Jui wrote:
>
>
> On 4/17/2019 11:21 PM, Peter Rosin wrote:
>> On 2019-04-18 01:48, Ray Jui wrote:
>>>
>>>
>>> On 4/14/2019 11:56 PM, Peter Rosin wrote:
On 2019-04-13 00:59, Peter Rosin wrote:
> On 2019-04-03 23:05, Ray Jui wrote:
>> Change the iProc I2C drive
Hi Alexandre,
On Wed, Apr 17, 2019 at 01:22:44AM -0400, Alexandre Ghiti wrote:
> This commit takes care of stack randomization and stack guard gap when
> computing mmap base address and checks if the task asked for randomization.
> This fixes the problem uncovered and not fixed for mips here:
> ht
On Thu, 2019-04-18 at 22:53 +0200, Martin Blumenstingl wrote:
> Hi Jerome,
>
> On Thu, Apr 18, 2019 at 10:46 PM Jerome Brunet wrote:
> > On Thu, 2019-04-18 at 22:16 +0200, Martin Blumenstingl wrote:
> > > Hi Jerome,
> > >
> > > On Wed, Apr 17, 2019 at 10:44 PM Jerome Brunet
> > > wrote:
> > >
On Wed, Apr 10, 2019 at 09:47:01PM -0500, Steve French wrote:
> How was this discovered? Does it address a reported user problem?
I have spotted it while tracking down how page reference are taken
for bio and how they are release. In the current code, once the page
are GUPed they are never release
On Tue, Apr 09, 2019 at 02:08:39PM +0800, Peter Xu wrote:
> On Wed, Mar 20, 2019 at 10:06:14AM +0800, Peter Xu wrote:
> > This series implements initial write protection support for
> > userfaultfd. Currently both shmem and hugetlbfs are not supported
> > yet, but only anonymous memory. This is t
On 18 Apr 2019, at 15:23, Yang Shi wrote:
> On 4/18/19 11:16 AM, Keith Busch wrote:
>> On Wed, Apr 17, 2019 at 10:13:44AM -0700, Dave Hansen wrote:
>>> On 4/17/19 2:23 AM, Michal Hocko wrote:
yes. This could be achieved by GFP_NOWAIT opportunistic allocation for
the migration target. Tha
On Wed, Mar 20, 2019 at 10:06:39AM +0800, Peter Xu wrote:
> In change_pte_range() we do nothing for uffd if the PTE is a swap
> entry. That can lead to data mismatch if the page that we are going
> to write protect is swapped out when sending the UFFDIO_WRITEPROTECT.
> This patch applies/removes t
On Wed, Mar 20, 2019 at 10:06:31AM +0800, Peter Xu wrote:
> For either swap and page migration, we all use the bit 2 of the entry to
> identify whether this entry is uffd write-protected. It plays a similar
> role as the existing soft dirty bit in swap entries but only for keeping
> the uffd-wp tr
Hi Thomas,
On Tue, Mar 19, 2019 at 04:47:49PM +0100, Thomas Bogendoerfer wrote:
> SGI IP27 (Origin/Onyx2) and SGI IP30 (Octane) have a similair
> architecture and share some hardware (ioc3/bridge). To share
> the software parts this patchset reworks SGI IP27 interrupt
> and pci bridge code. By usi
Hi Jerome,
On Thu, Apr 18, 2019 at 10:46 PM Jerome Brunet wrote:
>
> On Thu, 2019-04-18 at 22:16 +0200, Martin Blumenstingl wrote:
> > Hi Jerome,
> >
> > On Wed, Apr 17, 2019 at 10:44 PM Jerome Brunet wrote:
> > > Activating DDR in the Amlogic mmc controller, among other things, will
> > > divid
On Wed, Mar 20, 2019 at 10:06:28AM +0800, Peter Xu wrote:
> This allows uffd-wp to support write-protected pages for COW.
>
> For example, the uffd write-protected PTE could also be write-protected
> by other usages like COW or zero pages. When that happens, we can't
> simply set the write bit in
On Thu, 2019-04-18 at 22:16 +0200, Martin Blumenstingl wrote:
> Hi Jerome,
>
> On Wed, Apr 17, 2019 at 10:44 PM Jerome Brunet wrote:
> > Activating DDR in the Amlogic mmc controller, among other things, will
> > divide the output clock by 2. So by activating it with clock on, we are
> > creating
On 4/18/19 11:05 AM, Wang YanQing wrote:
> I meet below compile errors:
> "
> In file included from test_tcpnotify_kern.c:12:
> /usr/include/netinet/in.h:101:5: error: expected identifier
> IPPROTO_HOPOPTS = 0, /* IPv6 Hop-by-Hop options. */
> ^
> /usr/include/linux/in6.h:131:26: not
Quoting Stephen Boyd (2019-04-12 11:31:42)
> We recently introduced a change to support devm clk lookups. That change
> introduced a code-path that used clk_find() without holding the
> 'clocks_mutex'. Unfortunately, clk_find() iterates over the 'clocks'
> list and so we need to prevent the list fr
On 4/18/19 11:00 AM, Wang YanQing wrote:
> On Thu, Apr 18, 2019 at 05:09:53AM +, Yonghong Song wrote:
>>
>>
>> On 4/17/19 10:48 AM, Wang YanQing wrote:
>>> The older glibc (for example, 2.23) doesn't handle __UAPI_DEF_*
>>> in libc-compat.h properly, and it bring below compile errors:
>>
>> I
Quoting Paul Cercueil (2019-04-17 16:53:53)
> Hi Stephen,
>
> Le jeu. 18 avril 2019 à 1:48, Stephen Boyd a écrit
> :
> > Quoting Paul Cercueil (2019-04-17 04:24:20)
> >> The pixel clock is directly connected to the output of the PLL, and
> >> not
> >> to the /2 divider.
> >>
> >> Cc: sta...
On Thu, Apr 18, 2019 at 2:28 PM Jerome Brunet wrote:
>
> For some reason the vim2 is missing the clk-gate pinctrl setting all
> the other board have. Just add this missing bit
>
> Signed-off-by: Jerome Brunet
Reviewed-by: Martin Blumenstingl
1 - 100 of 934 matches
Mail list logo
