On Thu 2019-03-14 15:06:14, Rasmus Villemoes wrote:
> If userspace doesn't end the input with a newline (which can easily
> happen if the write happens from a C program that does write(fd,
> iface, strlen(iface))), we may end up including garbage from a
> previous, longer value in the device_name.
On Mon, Mar 18, 2019 at 12:09 PM Rafael J. Wysocki wrote:
>
> On Mon, Mar 18, 2019 at 11:54 AM Peter Zijlstra wrote:
> >
> > On Mon, Mar 18, 2019 at 08:05:14AM +0530, Viresh Kumar wrote:
> > > On 15-03-19, 13:29, Peter Zijlstra wrote:
> > > > On Fri, Mar 15, 2019 at 02:43:07PM +0530, Viresh Kumar
Hi,
Static analysis with cppcheck found a couple of interesting issues with
memcpy'ing of an uninitialized variable. Two occurrences of the same
issue are found in drivers/staging/rtl8712/rtl8712_cmd.c in functions
read_bbreg_hdl and read_rfreg_hdl.
For example:
static u8 read_bbreg_hdl(struct _
Hi!
> Take the part of device_name_store that puts the old device (if any),
> copies the new device name, looks the name up etc. into a separate
> helper function. This is preparation for using that helper from a
> function that will initialize the led_netdev_data from a device tree
> node. No fun
On Thu 2019-03-14 15:06:16, Rasmus Villemoes wrote:
> Currently, setting device_name to a 15-character name requires
> avoiding a trailing newline (e.g. by using 'echo -n' or 'printf'),
> which is inconsistent and potentially surprising. Instead of
> potentially including a newline in the copy and
On Thu 2019-03-14 15:06:17, Rasmus Villemoes wrote:
> It's better to check that size is sane in the function that does the
> memcpy'ing and 0-termination to the IFNAMSIZ-sized buffer instead of
> relying on callers getting it right. Not rejecting size upfront does
> mean we would do the cancel_dela
Hi Gregory,
> Hi Ilias,
>
> On jeu., mars 14 2019, Ilias Apalodimas wrote:
>
> > Hello Christian,
> >> Hi,
> >>
> >> I assume you use the 1000 MHz firmware. This does also not work on my Rev 7
> >> board. But I'm pretty sure this is not a problem of the patches, because if
> >> I take a newe
Hi, Thierry
Best Regards!
Anson Huang
> -Original Message-
> From: Thierry Reding [mailto:thierry.red...@gmail.com]
> Sent: 2019年3月18日 18:28
> To: Anson Huang
> Cc: robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org;
> s.ha...@pengutronix.de; ker...@pengutronix.de; feste...@gm
The test case:
#include
#include
#include
#include
#include
int main()
{
char *p = malloc(128);
struct robust_list_head *ro1;
struct robust_list *entry;
struct robust_list *pending;
int ret = 0;
pid_t pid = getpid();
print
Hi Ilias,
On lun., mars 18 2019, Ilias Apalodimas wrote:
> Hi Gregory,
>> Hi Ilias,
>>
>> On jeu., mars 14 2019, Ilias Apalodimas wrote:
>>
>> > Hello Christian,
>> >> Hi,
>> >>
>> >> I assume you use the 1000 MHz firmware. This does also not work on my Rev
>> >> 7
>> >> board. But I'm
On Mon, Mar 18, 2019 at 12:15 PM Thomas Renninger wrote:
>
> On Monday, March 18, 2019 11:26:10 AM CET Rafael J. Wysocki wrote:
> > On Fri, Mar 15, 2019 at 4:36 PM Thomas Renninger wrote:
> > > Hi Rafael,
> > >
>
> ...
>
> > > On my workstation the BIOS initializes perf bias to:
> > > cpupower in
On Mon, Mar 18, 2019 at 6:33 PM Luis Henriques wrote:
>
> "Yan, Zheng" writes:
>
> > On Fri, Mar 15, 2019 at 7:13 PM Luis Henriques wrote:
> >>
> >> I'm occasionally seeing a kmemleak warning in xfstest generic/013:
> >>
> >> unreferenced object 0x8881fccca940 (size 32):
> >> comm "kworker
cpuid faulting is a feature about CPUID instruction. When cpuif faulting
is enabled, all execution of the CPUID instruction outside system-management
mode (SMM) cause a general-protection (#GP) if the CPL > 0.
About this feature, detailed information can be found at
https://www.intel.com/content/d
Current cpuid faulting of guest is purely emulated in kvm, which exploits
CPUID vm exit to inject #GP to guest. However, if host hardware cpu has
X86_FEATURE_CPUID_FAULT, we can just use the hardware cpuid faulting for
guest to avoid the vm exit overhead.
Note: cpuid faulting takes higher priority
This series avoid cpuid faulting of host leakding to guest, which may
potentially cause guest boot failure, and use hardware cpuid faulting
to remove emulation overhead.
Patch 1 avoids cpuid faulting leaking to guest through clearing cpuid faulting
bit before enter guest and restoring host's cpuid
Hi,
static analysis with cppcheck has detected use of an uninitialized array
tmp_ssid in drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c in
function ieee80211_softmac_new_net()
Array tmp_ssid is only initialized when ssidbroad is non-null, however
it is being copied and the copy of this is
On Sat, Mar 16, 2019 at 05:17:06PM +0300, Alexey Budankov wrote:
SNIP
> static int perf_session__deliver_event(struct perf_session *session,
> union perf_event *event,
> struct perf_tool *tool,
> @@ -198,12 +259,23 @@ stat
On Sat, Mar 16, 2019 at 11:58:30AM +0300, Alexey Budankov wrote:
SNIP
> ---
> Alexey Budankov (12):
> feature: implement libzstd check, LIBZSTD_DIR and NO_LIBZSTD defines
> perf record: implement --mmap-flush= option
> perf session: define bytes_transferred and bytes_compressed metrics
>
On Sat, Mar 16, 2019 at 05:18:24PM +0300, Alexey Budankov wrote:
>
> Implemented basic integration test for Zstd based trace
> compression/decompression in record and report modes.
>
> Signed-off-by: Alexey Budankov
> ---
> .../tests/shell/record+zstd_comp_decomp.sh| 28 +++
If alloc_workqueue_attrs() fails, the workqueue lockdep is
uninitialized, it will trigger a warning in err_free_wq path
when try to unregister workqueue lockdep.
Cc: Andrew Morton
Cc: Bart Van Assche
Cc: Ingo Molnar
Cc: Tejun Heo
Cc: Peter Zijlstra
Fixes: 009bb421b6ce ("workqueue, lockdep: Fi
On Thu 14-03-19 09:51:42, Dave Hansen wrote:
[...]
> From: Dave Hansen
>
> MPX is being removed from the kernel due to a lack of support
> in the toolchain going forward (gcc).
>
> The first thing we need to do is remove the userspace-visible
> ABIs so that applications will stop using it. The
This patch series adds a PWM driver and DT documentation
for HiFive Unleashed board. The patches are mostly based on
Wesley's patch.
v10
- Use DIV_ROUND_CLOSEST_ULL instead of div_u64_round
- Change 'num' defination to u64 bit (in pwm_sifive_apply).
- Remove the usage of pwm_get_state()
v9
- Use
DT documentation for PWM controller added.
Signed-off-by: Wesley W. Terpstra
[Atish: Compatible string update]
Signed-off-by: Atish Patra
Signed-off-by: Yash Shah
Reviewed-by: Rob Herring
---
.../devicetree/bindings/pwm/pwm-sifive.txt | 33 ++
1 file changed, 33 in
Adds a PWM driver for PWM chip present in SiFive's HiFive Unleashed SoC.
Signed-off-by: Wesley W. Terpstra
[Atish: Various fixes and code cleanup]
Signed-off-by: Atish Patra
Signed-off-by: Yash Shah
---
drivers/pwm/Kconfig | 11 ++
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-sifive
On Fri, Mar 15, 2019 at 10:13 AM Viresh Kumar wrote:
>
> Currently we call these notifiers once for each CPU of the policy->cpus
> cpumask. It would be more optimal if the notifier can be called only
> once and all the relevant information be provided to it. Out of the 24
> drivers that register f
--
jmichell...@gmail.com
On Thu 2019-03-14 15:06:19, Rasmus Villemoes wrote:
> It can be quite convenient to initialize a netdev-triggered LED with a
> device name and setting the rx,tx,link properties from device tree,
> instead of having to do that in an init script (or udev rule) in
> userspace.
>
> My main motivation
Hi Axel,
On 16 March 2019 01:51, Axel Lin wrote:
> To: Mark Brown
> Subject: [PATCH] regulator: da9052: Include linux/of.h to fix build warning
> for
> of_match_ptr
>
> Remove #ifdef CONFIG_OF guard so linux/of.h will be included when
> !CONFIG_OF. This fixes build warnings when !CONFIG_OF.
>
On Fri, Mar 15, 2019 at 09:21:02PM +0100, Thomas Müller wrote:
> I've just re-tested with runlevel 3.
> Not a real VGA console, but at least no Wayland or Gnome to interfere...
>
> `echo 0 > /sys/...` just blocks and no message whatsoever is visible in dmesg.
>
> I've executed `echo 0 > ...` in t
Hello!
On Sunday 17 March 2019 15:30:49 Renato Soma wrote:
> Hello,
>
> On Sat, Mar 16, 2019 at 10:17:56AM +0100, Pali Rohár wrote:
> >
> > Looks like that those keys are not as obvious as you wrote. Look at my
> > email with some investigation about Dell Audio With Preset Switch key:
> > https:
On Mon, Mar 18, 2019 at 03:05:09AM +, Zhang, Lei wrote:
> Thanks for your comments.
> I also have considered to use MIDR_CPU_VAR_REV macro,
> but the implication of (~MIDR_CPU_VAR_REV(1, 0)) is "NOT v1r0".
> I think it may cause confusion, so I choose the
> simple way (~(0x1 << MIDR_VARIANT_SHI
On 18.03.2019 14:46, Jiri Olsa wrote:
> On Sat, Mar 16, 2019 at 05:17:06PM +0300, Alexey Budankov wrote:
>
> SNIP
>
>> static int perf_session__deliver_event(struct perf_session *session,
>> union perf_event *event,
>> struc
On Mon, Mar 18, 2019 at 12:53:16PM +0300, Andy Shevchenko wrote:
> Add an mfd driver for Intel Merrifield Basin Cove PMIC.
While I waiting for comments here, please, don't apply it either yet.
The individual driver names might be changed. So, I will update them in v2 when
all parties will be sati
On Mon, Mar 18, 2019 at 6:27 AM Tetsuo Handa
wrote:
>
> Dmitry Vyukov wrote:
> > > Then, we need to find what test is changing console_loglevel.
> > > Maybe add debug BUG_ON() in linux-next.git using
> > > CONFIG_DEBUG_AID_FOR_SYZBOT ?
> >
> > Is there a single place to catch this? I could run sy
On 18.03.2019 14:46, Jiri Olsa wrote:
> On Sat, Mar 16, 2019 at 05:18:24PM +0300, Alexey Budankov wrote:
>>
>> Implemented basic integration test for Zstd based trace
>> compression/decompression in record and report modes.
>>
>> Signed-off-by: Alexey Budankov
>> ---
>> .../tests/shell/record+zst
From: Bartosz Golaszewski
We now have a proper clocksource driver for davinci. Switch the dm365
platform to using it.
Signed-off-by: Bartosz Golaszewski
Reviewed-by: David Lechner
---
arch/arm/mach-davinci/dm365.c | 22 +++---
1 file changed, 15 insertions(+), 7 deletions(-)
From: Bartosz Golaszewski
All platforms have now been switched to the new clocksource driver.
Remove the old code and various no longer needed bits and pieces.
Signed-off-by: Bartosz Golaszewski
Reviewed-by: David Lechner
---
arch/arm/mach-davinci/Makefile | 3 +-
arch/arm/mach
From: Bartosz Golaszewski
Currently the clocksource and clockevent support for davinci platforms
lives in mach-davinci. It hard-codes many things, uses global variables,
implements functionalities unused by any platform and has code fragments
scattered across many (often unrelated) files.
Implem
From: Bartosz Golaszewski
Switch all davinci boards supporting device tree to using the new
clocksource driver: remove the previous OF_TIMER_DECLARE() from
mach-davinci and select davinci-timer for ARCH_DAVINCI.
Signed-off-by: Bartosz Golaszewski
Reviewed-by: David Lechner
---
arch/arm/Kconfi
From: Bartosz Golaszewski
This series removes the legacy timer code from mach-davinci in favor of
a new clocksource driver it introduces.
Patch 1 adds a new clocksource driver for davinci.
Patch 2 enables the new driver for device-tree based systems.
Patch 3 adds a WARN_ON() to the machine cod
From: Bartosz Golaszewski
We now have a proper clocksource driver for davinci. Switch the dm646x
platform to using it.
Signed-off-by: Bartosz Golaszewski
Reviewed-by: David Lechner
---
arch/arm/mach-davinci/dm646x.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions
From: Bartosz Golaszewski
We now have a proper clocksource driver for davinci. Switch the da830
platform to using it.
Signed-off-by: Bartosz Golaszewski
Reviewed-by: David Lechner
---
arch/arm/mach-davinci/da830.c | 41 ---
1 file changed, 14 insertions(+), 27
From: Bartosz Golaszewski
We now have a proper clocksource driver for davinci. Switch the dm644x
platform to using it.
Signed-off-by: Bartosz Golaszewski
Reviewed-by: David Lechner
---
arch/arm/mach-davinci/dm644x.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions
From: Bartosz Golaszewski
We now have a proper clocksource driver for davinci. Switch the dm355
platform to using it.
Signed-off-by: Bartosz Golaszewski
Reviewed-by: David Lechner
---
arch/arm/mach-davinci/dm355.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-
From: Bartosz Golaszewski
We now have a proper clocksource driver for davinci. Switch the da850
platform to using it.
Signed-off-by: Bartosz Golaszewski
Reviewed-by: David Lechner
---
arch/arm/mach-davinci/da850.c | 46 ++-
1 file changed, 13 insertions(+), 33
From: Bartosz Golaszewski
Currently the timer code checks if the clock pointer passed to it is
good (!IS_ERR(clk)). The new clocksource driver expects the clock to
be functional and doesn't perform any checks so emit a warning if
clk_get() fails. Apply this to all davinci platforms.
Signed-off-b
From: Bartosz Golaszewski
Boards from the dm* family rely on register offset definitions from
arch/arm/mach-davinci/include/mach/time.h. We'll be removing this file
soon, so move the required defines to davinci.h where the rest of such
constants live.
Signed-off-by: Bartosz Golaszewski
Reviewed
On Fri 2019-03-15 23:48:41, Yangtao Li wrote:
> Rearrange comment to make the comment style consistent, the previous
> function parameters are described first.
>
> Signed-off-by: Yangtao Li
Acked-by: Pavel Machek
> ---
> drivers/base/power/main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 de
On Fri 2019-03-15 23:37:51, Yangtao Li wrote:
> This brings the kernel doc in line with the function signature.
>
> Signed-off-by: Yangtao Li
Acked-by: Pavel Machek
> ---
> drivers/base/power/main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/base/power/m
On 13-Mar 21:18, Peter Zijlstra wrote:
> On Fri, Feb 08, 2019 at 10:05:42AM +, Patrick Bellasi wrote:
> > +static void uclamp_fork(struct task_struct *p)
> > +{
> > + unsigned int clamp_id;
> > +
> > + if (unlikely(!p->sched_class->uclamp_enabled))
> > + return;
> > +
> > + for
On Sun, Mar 17, 2019 at 12:04 PM Greg KH wrote:
>
> On Sun, Mar 17, 2019 at 03:43:01AM -0700, syzbot wrote:
> > syzbot has bisected this bug to:
> >
> > commit f1e3e92135202ff3d95195393ee62808c109208c
> > Author: Malcolm Priestley
> > Date: Wed Jul 22 18:16:42 2015 +
> >
> > staging: vt
On Sat 2019-03-16 00:59:24, Yangtao Li wrote:
> This patch set introduces some functions and macros that help reduce
> code duplication.
>
> Yangtao Li (4):
> PM / core: Introduce dpm_async_fn() helper
> PM / core: Introduce DEVICE_SUSPEND_FUNC() helper macro
> PM / core: Introduce ASYNC_RES
Hi Gregory,
> >>
> > [ 14.909524] clk_pm_cpu_set_parent old=28004840 -> val=0x600
> > load_level=0
> > [ 14.916424] clk_pm_cpu_set_parent old=2E004840 -> val=0x600 load_level=1
> > [ 14.923315] clk_pm_cpu_set_parent old=8880A8C0 -> val=0x600
> > load_level=2
> > [ 14.930572] cl
Hi Shawn,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.1-rc1]
[cannot apply to next-20190318]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https
Kernel 4.18.0 has a partial data loss when an NMI occurs but 5.0.0 has
complete data loss.
I tested with this simple kernel lockup code on kernels 4.18.0 through
5.0.0. On 4.18.0 (and after) the expected lockup messages
Uhhuh. NMI received for unknown reason 25 on CPU 0.
Do you have a strange
From: Bartosz Golaszewski
Resending rebased on top of v5.1-rc1.
This series depends on the clocksource rework that's been earlier
posted to LKML[1].
The first one adds necessary bits and pieces for davinci to support
multiplatform build and the second one actually adds all davinci boards
to mul
From: Bartosz Golaszewski
Add all DaVinci boards to multi_v5_defconfig.
Signed-off-by: Bartosz Golaszewski
---
arch/arm/configs/multi_v5_defconfig | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/configs/multi_v5_defconfig
b/arch/arm/configs/multi_v5_defconfig
index
From: Bartosz Golaszewski
Add modifications necessary to make davinci part of the ARM v5
multiplatform build.
Move the arch-specific configuration out of arch/arm/Kconfig and
into mach-davinci/Kconfig. Remove the sub-menu for DaVinci
implementations (they'll be visible directly under the system
Hi Shawn,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.1-rc1]
[cannot apply to next-20190318]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https
On Mon, Mar 18, 2019 at 1:07 PM Dmitry Vyukov wrote:
>
> On Mon, Mar 18, 2019 at 6:27 AM Tetsuo Handa
> wrote:
> >
> > Dmitry Vyukov wrote:
> > > > Then, we need to find what test is changing console_loglevel.
> > > > Maybe add debug BUG_ON() in linux-next.git using
> > > > CONFIG_DEBUG_AID_FOR_
Please ignore, no check lkml again, see https://lkml.org/lkml/2019/3/11/1274:-)
On 2019/3/18 19:58, Kefeng Wang wrote:
> If alloc_workqueue_attrs() fails, the workqueue lockdep is
> uninitialized, it will trigger a warning in err_free_wq path
> when try to unregister workqueue lockdep.
>
> Cc: An
On Mon, Mar 18, 2019 at 1:32 PM Dmitry Vyukov wrote:
>
> On Mon, Mar 18, 2019 at 1:07 PM Dmitry Vyukov wrote:
> >
> > On Mon, Mar 18, 2019 at 6:27 AM Tetsuo Handa
> > wrote:
> > >
> > > Dmitry Vyukov wrote:
> > > > > Then, we need to find what test is changing console_loglevel.
> > > > > Maybe a
On 27. 02. 19 21:51, Jolly Shah wrote:
> This patchset renames clock dt include file to align with other incldues.
> Other patch moves clock binding to a separate file under clock directory to
> align with other firmware child binding documenetation.
>
> Jolly Shah (1):
> include: dt-binding: cl
On 18. 02. 19 22:43, Jann Horn wrote:
> - Userspace wants to write a string with `len` bytes, not counting the
>terminating NULL, so we should allocate `len+1` bytes. It looks like the
>current code relied on having a nullbyte directly behind `kern_buff`,
>which happens to work reliabl
On 05. 03. 19 0:18, Jolly Shah wrote:
> From: Rajan Vaja
>
> Driver needs ZynqMP firmware interface to call EEMI
> APIs. In case firmware is not ready, dependent drivers
> should wait until the firmware is ready.
>
> Signed-off-by: Rajan Vaja
> Signed-off-by: Jolly Shah
> ---
> Documentation/
On Mon, Mar 18, 2019 at 07:38:26PM +0900, Chanwoo Choi wrote:
> Thanks for comment. I add my comments
> and then you have to rebase it on latest v5.0-rc1
> because the merge conflict happen on v5.0-rc1.
Thanks for review, see my answers below.
Non-answered items will be fixed accordingly.
> >> +
On 05. 03. 19 0:19, Jolly Shah wrote:
> From: Rajan Vaja
>
> Versal EEMI APIs uses clock device ID which is combination of class,
> subclass, type and clock index (e.g. 0x8104006 in which 0-13 bits are
> for index(6 in given example), 14-19 bits are for clock type (i.e pll,
> out or ref, 1 in giv
On 05. 03. 19 0:27, Jolly Shah wrote:
> From: Rajan Vaja
>
> Zero divider is valid and default for some of ZynqMP
> clocks. Allow zero divisor when CLK_DIVIDER_ALLOW_ZERO
> for the clock is set.
>
> Signed-off-by: Rajan Vaja
> Signed-off-by: Jolly Shah
> ---
> drivers/clk/zynqmp/divider.c | 7
On (03/18/19 13:32), Dmitry Vyukov wrote:
> Wait, but isn't SYSLOG_ACTION_CONSOLE_LEVEL what we are looking for?
> syzkaller knows about the syslog syscall:
There is also SYSLOG_ACTION_CONSOLE_OFF, which disables logging.
-ss
On Mon, 18 Mar 2019 00:21:24 +0100,
Colin King wrote:
>
> From: Colin Ian King
>
> The function snd_opl3_drum_switch declaration in the header file
> has the order of the two arguments on_off and vel swapped when
> compared to the definition arguments of vel and on_off. Fix this
> by swapping t
On Mon, Mar 18, 2019 at 6:55 PM Luis Henriques wrote:
>
> "Yan, Zheng" writes:
>
> > On Mon, Mar 18, 2019 at 5:06 PM Gregory Farnum wrote:
> >>
> >> On Mon, Mar 18, 2019 at 2:32 PM Yan, Zheng wrote:
> >> > After reading the code carefully. I feel a little uncomfortable with
> >> > the "lookup_i
The AXP223 can be used both using the RSB proprietary bus, or a more
traditional I2C bus. The RSB is a faster bus and provides more features
(like some integrity checks on the messages), so it's usually preferrable
to use it, but since it's proprietary, when we want to use the PMIC in a
multi-maste
The A23 and A33 both have an I2C controller in the ARISC domain, that share
the same pins with the RSB bus.
Even if it's an unusual configuration, that device can be used to drive the
PMIC, so let's use it.
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun8i-a23-a33.dtsi | 20 +
Hello,
I am facing issue of high latency in CMA allocation of large size buffer.
I am frequently allocating/deallocation CMA memory, latency of allocation is
very high.
Below are the stat for allocation/deallocation latency issue.
(390100 kB), latency 29997 us
(390100 kB), latency 22957 us
(
On 13-Mar 21:52, Peter Zijlstra wrote:
> On Fri, Feb 08, 2019 at 10:05:45AM +, Patrick Bellasi wrote:
> > diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> > index 070caa1f72eb..8b282616e9c9 100644
> > --- a/kernel/sched/core.c
> > +++ b/kernel/sched/core.c
> > @@ -1071,7 +1071,7 @@ stat
On Tue, Mar 12, 2019 at 10:22 PM Luis Henriques wrote:
>
> The CephFS kernel client does not enforce quotas set in a directory that
> isn't visible from the mount point. For example, given the path
> '/dir1/dir2', if quotas are set in 'dir1' and the filesystem is mounted with
>
> mount -t ceph
On Mon 18-03-19 12:58:28, Pankaj Suryawanshi wrote:
> Hello,
>
> I am facing issue of high latency in CMA allocation of large size buffer.
>
> I am frequently allocating/deallocation CMA memory, latency of allocation is
> very high.
>
> Below are the stat for allocation/deallocation latency iss
I guess this patch series missed the 5.1 merge window? :)
On Thu, 2019-01-31 at 21:24 +0100, KarimAllah Ahmed wrote:
> Guest memory can either be directly managed by the kernel (i.e. have a "struct
> page") or they can simply live outside kernel control (i.e. do not have a
> "struct page"). KVM mo
On Mon, Mar 18, 2019 at 12:18:04PM +, Patrick Bellasi wrote:
> On 13-Mar 21:18, Peter Zijlstra wrote:
> > On Fri, Feb 08, 2019 at 10:05:42AM +, Patrick Bellasi wrote:
> > > +static void uclamp_fork(struct task_struct *p)
> > > +{
> > > + unsigned int clamp_id;
> > > +
> > > + if (unlikely(!
On 14/03/2019 17:37, Jerome Brunet wrote:
> From: Guillaume La Roque
>
> drive-strength is a new feature needed for G12A SoC.
> the default DS setting after boot is usually 0.5mA and it is not enough for
> many functions. We need to be able to set the drive strength to reliably
> enable things li
On Mon, Mar 18, 2019 at 12:48 PM Mike Rapoport wrote:
>
> On Sat, Mar 16, 2019 at 04:55:30AM +0530, Anup Patel wrote:
> > On Fri, Mar 15, 2019 at 9:52 PM Anup Patel wrote:
> > >
> > > On Fri, Mar 15, 2019 at 9:28 PM Mike Rapoport wrote:
> > > >
> > > > I still don't get why it is that important
On Monday, March 18, 2019 12:40:46 PM CET Rafael J. Wysocki wrote:
> On Mon, Mar 18, 2019 at 12:15 PM Thomas Renninger wrote:
...
> And who's BIOS, really? I guess you mean the OEM? Note, however,
> that the user and the OEM may not agree on that, but whatever.
I mean both!
The OEM.
And the
stable-rc/linux-4.14.y boot: 103 boots: 1 failed, 101 passed with 1
untried/unknown (v4.14.106-35-g6fdcb56d3713)
Full Boot Summary:
https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.14.y/kernel/v4.14.106-35-g6fdcb56d3713/
Full Build Summary:
https://kernelci.org/build/stable-rc/branch/
On Fri, Mar 15, 2019 at 05:03:47PM +0100 Peter Zijlstra wrote:
> On Fri, Mar 15, 2019 at 11:30:42AM -0400, Phil Auld wrote:
>
> >> I'll rework the maths in the averaged version and post v2 if that makes
> >> sense.
> >
> > It may have the extra timer fetch, although maybe I could rework it so th
From: Michal Hocko
Sent: 18 March 2019 18:37:57
To: Pankaj Suryawanshi
Cc: linux...@kvack.org; linux-kernel@vger.kernel.org; minc...@kernel.org;
Kirill Tkhai
Subject: [External] Re: mm/cma.c: High latency for cma allocation
CAUTION: This email originated from outside of the organizatio
On 3/14/19 2:56 PM, Matias Bjørling wrote:
On 3/14/19 6:41 AM, Marcin Dziegielewski wrote:
Open channel devices are not able to handle traditional
IO requests addressed by LBA, so following current
approach to exposing special nvme devices as zero size
(e.g. with namespace formatted to use metad
[ adding Gil Weber in Cc: ]
Le 15/03/2019 à 10:23, Razvan Stefanescu a écrit :
> Use a helper function to check that a port needs to use half duplex
> communication, replacing several occurrences of multi-line bit checking.
>
> Signed-off-by: Razvan Stefanescu
> ---
> drivers/tty/serial/atmel_s
On Mon, Mar 18, 2019 at 1:50 PM Sergey Senozhatsky
wrote:
>
> On (03/18/19 13:32), Dmitry Vyukov wrote:
> > Wait, but isn't SYSLOG_ACTION_CONSOLE_LEVEL what we are looking for?
> > syzkaller knows about the syslog syscall:
>
> There is also SYSLOG_ACTION_CONSOLE_OFF, which disables logging.
That
stable-rc/linux-4.19.y boot: 103 boots: 0 failed, 102 passed with 1
untried/unknown (v4.19.29-53-g80fa0a60fe1b)
Full Boot Summary:
https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.19.y/kernel/v4.19.29-53-g80fa0a60fe1b/
Full Build Summary:
https://kernelci.org/build/stable-rc/branch/li
[Please do not use html emails to the mailing list and try to fix your
email client to not break quoating. Fixed for this email]
On Mon 18-03-19 13:28:50, Pankaj Suryawanshi wrote:
> On Mon 18-03-19 12:58:28, Pankaj Suryawanshi wrote:
> > > Hello,
> > >
> > > I am facing issue of high latency in C
On Fri, 15 Mar 2019, Rodrigo Rivas Costa wrote:
> When using this driver with the wireless dongle and some usermode
> program that monitors every input device (acpid, for example), while
> another usermode client opens and closes the low-level device
> repeadedly, the system eventually deadlocks.
On 3/17/19 9:46 AM, Ondrej Mosnacek wrote:
The conversion to kvmalloc() forgot to account for the possibility that
p->type_attr_map_array might be null in policydb_destroy().
Fix this by destroying its contents only if it is not NULL.
Also make sure ebitmap_init() is called on all entries befor
On Fri, 8 Mar 2019, Kai-Heng Feng wrote:
> Commit 71f6fa90a353 ("HID: increase maximum global item tag report size
> to 256") increases the max report size from 128 to 256.
>
> We also need to update the report size in hid_field_extract() otherwise
> it complains and truncates now valid report si
>Subject: [PATCH v2] infiniband: i40iw: fix potential NULL pointer dereferences
Something like "RDMA/i40iw: Handle workqueue allocation failure" is a more
appropriate subject line.
>
>alloc_ordered_workqueue may fail and return NULL.
>The fix captures the failure and handles it properly to avoid
Hi Mark,
For the DA9055, I have spoken with the management here. Dialog Semiconductor are
"no longer building the DA9055"; the device doesn't appear on the support portal
or website and; I have been told, "you can remove [it] from your list of
supported products".
But, as always: I realise that t
On 2019/3/17 19:26, Greg KH wrote:
> On Sat, Mar 09, 2019 at 11:26:00AM +0800, Mao Wenan wrote:
>> Using is_zero_ether_addr() instead of directly use
>> memcmp() to determine if the ethernet address is all
>> zeros.
>>
>> Signed-off-by: Mao Wenan
>> ---
>> drivers/staging/rtl8188eu/core/rtw_ml
From: Michal Hocko
Sent: 18 March 2019 19:12
To: Pankaj Suryawanshi
Cc: linux...@kvack.org; linux-kernel@vger.kernel.org; minc...@kernel.org;
Kirill Tkhai
Subject: Re: [External] Re: mm/cma.c: High latency for cma allocation
[Please do not use html emai
stable-rc/linux-4.9.y boot: 94 boots: 0 failed, 94 passed
(v4.9.163-32-g631b5fe18b59)
Full Boot Summary:
https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.9.y/kernel/v4.9.163-32-g631b5fe18b59/
Full Build Summary:
https://kernelci.org/build/stable-rc/branch/linux-4.9.y/kernel/v4.9.163-3
Hi, Uwe
Best Regards!
Anson Huang
> -Original Message-
> From: Anson Huang
> Sent: 2019年3月18日 18:08
> To: 'Uwe Kleine-König'
> Cc: thierry.red...@gmail.com; robh...@kernel.org; mark.rutl...@arm.com;
> shawn...@kernel.org; s.ha...@pengutronix.de; ker...@pengutronix.de;
> feste...@gmail.co
console_silent() is no longer used after the removal of
arch/mn10300/kernel/mn10300-watchdog.c in Linux 4.17-rc1.
Signed-off-by: Tetsuo Handa
---
include/linux/printk.h | 5 -
1 file changed, 5 deletions(-)
diff --git a/include/linux/printk.h b/include/linux/printk.h
index d7c77ed..65b6d4f
401 - 500 of 972 matches
Mail list logo
