On 4/18/19 1:17 AM, Kees Cook wrote:
(
On Wed, Apr 17, 2019 at 12:27 AM Alexandre Ghiti wrote:
arm64 handles top-down mmap layout in a way that can be easily reused
by other architectures, so make it available in mm.
It then introduces a new config ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT
that
On Wed, Apr 17, 2019 at 12:30 AM Alexandre Ghiti wrote:
>
> arm uses a top-down mmap layout by default that exactly fits the generic
> functions, so get rid of arch specific code and use the generic version
> by selecting ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT.
>
> Signed-off-by: Alexandre Ghiti
On Wed, Apr 17, 2019 at 12:28 AM 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 arm here:
>
On Wed, Apr 17, 2019 at 12:34 AM Alexandre Ghiti wrote:
>
> In order to avoid wasting user address space by using bottom-up mmap
> allocation scheme, prefer top-down scheme when possible.
>
> Before:
> root@qemuriscv64:~# cat /proc/self/maps
> 0001-00016000 r-xp fe:00 6389
On Wed, Apr 17, 2019 at 12:31 AM 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:
>
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, thus keeps it on during
> system suspend and
On Wed, Apr 17, 2019 at 12:32 AM Alexandre Ghiti wrote:
>
> mmap base address must be computed wrt stack top address, using TASK_SIZE
> is wrong since STACK_TOP and TASK_SIZE are not equivalent.
>
> Signed-off-by: Alexandre Ghiti
Acked-by: Kees Cook
-Kees
> ---
> arch/mips/mm/mmap.c | 4
On Wed, Apr 17, 2019 at 12:33 AM Alexandre Ghiti wrote:
>
> mips uses a top-down layout by default that fits the generic functions.
> At the same time, this commit allows to fix problem uncovered
> and not fixed for mips here:
>
On Wed, 17 Apr 2019, Bjorn Helgaas wrote:
> On Sat, Apr 13, 2019 at 06:50:57PM +0200, Julia Lawall wrote:
> > Hello,
> >
> > Kirill will explain about this issue.
> >
> > julia
> >
> > -- Forwarded message --
> > Date: Sat, 13 Apr 2019 11:22:51 +0800
> > From: kbuild test robot
Hi all,
Today's linux-next merge of the phy-next tree got a conflict in:
Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
between commit:
369b89366a3d ("dt-bindings: phy-qcom-qmp: Tweak qcom,msm8998-qmp-ufs-phy")
from the qcom tree and commit:
2815588ea64b ("dt-bindings:
On 04/17/2019 11:09 PM, Mark Rutland wrote:
> On Wed, Apr 17, 2019 at 10:15:35PM +0530, Anshuman Khandual wrote:
>> On 04/17/2019 07:51 PM, Mark Rutland wrote:
>>> On Wed, Apr 17, 2019 at 03:28:18PM +0530, Anshuman Khandual wrote:
On 04/15/2019 07:18 PM, Mark Rutland wrote:
> On Sun, Apr
On Wed, Apr 17, 2019 at 12:29 AM Alexandre Ghiti wrote:
>
> mmap base address must be computed wrt stack top address, using TASK_SIZE
> is wrong since STACK_TOP and TASK_SIZE are not equivalent.
>
> Signed-off-by: Alexandre Ghiti
> ---
> arch/arm/mm/mmap.c | 4 ++--
> 1 file changed, 2
(
On Wed, Apr 17, 2019 at 12:27 AM Alexandre Ghiti wrote:
>
> arm64 handles top-down mmap layout in a way that can be easily reused
> by other architectures, so make it available in mm.
> It then introduces a new config ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT
> that can be set by other
On 4/18/19 12:37 AM, Kees Cook wrote:
On Wed, Apr 17, 2019 at 12:26 AM Alexandre Ghiti wrote:
Do not offset mmap base address because of stack randomization if
current task does not want randomization.
Maybe mention that this makes this logic match the existing x86 behavior too?
Ok I will
On 4/18/19 12:32 AM, Kees Cook wrote:
On Wed, Apr 17, 2019 at 12:25 AM Alexandre Ghiti wrote:
Each architecture has its own way to determine if a task is a compat task,
by using is_compat_task in arch_mmap_rnd, it allows more genericity and
then it prepares its moving to mm/.
Signed-off-by:
On Wed, Apr 17, 2019 at 12:24 AM Alexandre Ghiti wrote:
>
> This preparatory commit moves this function so that further introduction
> of generic topdown mmap layout is contained only in mm/util.c.
>
> Signed-off-by: Alexandre Ghiti
> Reviewed-by: Christoph Hellwig
> ---
> fs/binfmt_elf.c|
On Wed, 17 Apr 2019 22:54:14 +0200,
Jacek Anaszewski wrote:
>
> led_colors clashes with the array of the same name being added
> to the LED class. Do the following amendments to fix this issue
> and the other prospective one.
>
> led_colors -> toneport_led_colors
> led_init_vals ->
On Thu, Apr 18, 2019 at 11:51:56AM +0900, Sugaya Taichi wrote:
> Add Milbeaut serial control including earlycon and console.
>
> Signed-off-by: Sugaya Taichi
> ---
> Changes from v2:
> - Fix build warning.
No, I only need an incremental patch fixing the one sparse warning
found, not a whole
On Thu, 18 Apr 2019 02:22:57 +0200,
kernel test robot wrote:
>
>
> FYI, we noticed the following commit (built with gcc-5):
>
> commit: feb689025fbb6f0aa6297d3ddf97de945ea4ad32 ("ALSA: seq: Protect
> in-kernel ioctl calls with mutex")
>
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 have an even old glibc 2.17 and it still works. Not sure
why it failed here. Could you explain more?
But I applied the
On 18-02-19, 22:04, Bjorn Andersson wrote:
> +static int qcom_pcie2_phy_power_on(struct phy *phy)
> +{
> + struct qcom_phy *qphy = phy_get_drvdata(phy);
> + int ret;
> + u32 val;
> +
> + /* Program REF_CLK source */
> + val = readl(qphy->base + PCIE20_PARF_PHY_REFCLK_CTRL2);
>
Hi Greg,
On Monday, 15 April 2019 12:50:29 CEST Greg Kroah-Hartman wrote:
> On Fri, Apr 05, 2019 at 07:12:47AM +0200, Mathias Fröhlich wrote:
> > Greg,
> >
> > as I mentioned in the commit message, I saw more fixes to that area in Alex
> > Deuchers queue when I fed that to Alex. There is one fix
On Tue, 16 Apr 2019 at 23:53, Miquel Raynal wrote:
>
> Hi Anders,
>
> Anders Roxell wrote on Wed, 10 Apr 2019
> 21:58:51 +0200:
>
> > Config fragments should not have the prefix 'CONFIG_'.
> >
> > Rework to remove the prefix 'CONFIG_' from 'CONFIG_MTD_NAND_ECC_SW_BCH'.
> >
> > Fixes:
This patch depends on patch 01.
The rp_ioctl is deprecated.
Add dev_warn_ratelimited to warn the use of rp_ioctl.
Signed-off-by: Fuqian Huang
---
drivers/tty/rocket.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/tty/rocket.c b/drivers/tty/rocket.c
index
On Wed, Apr 17, 2019 at 12:26 AM Alexandre Ghiti wrote:
>
> Do not offset mmap base address because of stack randomization if
> current task does not want randomization.
Maybe mention that this makes this logic match the existing x86 behavior too?
> Signed-off-by: Alexandre Ghiti
Acked-by:
If the cmd is RCPK_GET_STRUCT, copy_to_user will copy
info to user space. As info->port.ops is the address of
a constant object rocket_port_ops (assigned in init_r_port),
a kernel address leakage happens.
Remove the RCPK_GET_STRUCT ioctl.
Signed-off-by: Fuqian Huang
---
drivers/tty/rocket.c |
On Wed, Apr 17, 2019 at 12:25 AM Alexandre Ghiti wrote:
>
> Each architecture has its own way to determine if a task is a compat task,
> by using is_compat_task in arch_mmap_rnd, it allows more genericity and
> then it prepares its moving to mm/.
>
> Signed-off-by: Alexandre Ghiti
Acked-by:
In the event that the start address of the initrd is not aligned, but
has an aligned size, the base + size will not cover the entire initrd
image and there is a chance that the kernel will corrupt the tail of the
image.
By aligning the end of the initrd to a page boundary and then
subtracting the
Hi folks,
I noticed that there might be new THP allocation in NUMA fault migration
path (migrate_misplaced_transhuge_page()) even when THP is disabled (set
to "never"). When THP is set to "never", there should be not any new THP
allocation, but the migration path is kind of special. So I'm
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
arch/x86/kernel/irq_64.c
between commit:
d75f773c86a2 ("treewide: Switch printk users from %pf and %pF to %ps and %pS,
respectively")
from the printk tree and commit:
117ed4548541 ("x86/irq/64: Remove stack overflow
On 17-04-19, 10:43, Quentin Perret wrote:
> static struct thermal_cooling_device *
> __cpufreq_cooling_register(struct device_node *np,
> - struct cpufreq_policy *policy, u32 capacitance)
> + struct cpufreq_policy *policy,
> + struct
count_threshol == 1 isn't working as expected. CEC only does soft
offline the second time the same pfn is hit by a correctable error.
Signed-off-by: WANG Chao
---
drivers/ras/cec.c | 36 +---
1 file changed, 21 insertions(+), 15 deletions(-)
diff --git
lx2160a supports pw20 which could help save more power during cpu is
dile. It needs system firmware support via PSCI.
Signed-off-by: Ran Wang
---
arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 25
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git
ces_entered should be put in a critical section to avoid race condition.
Signed-off-by: WANG Chao
---
drivers/ras/cec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/ras/cec.c b/drivers/ras/cec.c
index 2e0bf1269c31..702e4c02c713 100644
--- a/drivers/ras/cec.c
A left over pfn (because we don't clear) at ca->array[n] can be a match
in __find_elem. Later it'd cause a memmove size overflow in del_elem.
Signed-off-by: WANG Chao
---
drivers/ras/cec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/ras/cec.c b/drivers/ras/cec.c
On Tue, Apr 16, 2019 at 9:30 PM Luis Henriques wrote:
>
> Luis Henriques writes:
>
> > "Yan, Zheng" writes:
> >
> >> On Fri, Mar 22, 2019 at 6:04 PM Luis Henriques wrote:
> >>>
> >>> Luis Henriques writes:
> >>>
> >>> > "Yan, Zheng" writes:
> >>> >
> >>> >> On Tue, Mar 19, 2019 at 12:22 AM
> -Original Message-
> From: Daniel Lezcano
> Sent: 2019年4月12日 20:19
> To: Andy Tang ; shawn...@kernel.org
> Cc: Leo Li ; robh...@kernel.org; mark.rutl...@arm.com;
> linux-arm-ker...@lists.infradead.org; devicet...@vger.kernel.org;
> linux-kernel@vger.kernel.org;
On Wed, Apr 17, 2019 at 06:55:12PM -0700, Shakeel Butt wrote:
> On Wed, Apr 17, 2019 at 5:39 PM Roman Gushchin wrote:
> >
> > On Wed, Apr 17, 2019 at 04:41:01PM -0700, Shakeel Butt wrote:
> > > On Wed, Apr 17, 2019 at 2:55 PM Roman Gushchin wrote:
> > > >
> > > > This commit makes several
The memory allocated in the function iio_dummy_evgen_create is not
released if it fails to add the evgen device to device hierarchy. This
may result in a memory leak bug.
Signed-off-by: Pan Bian
---
drivers/iio/dummy/iio_dummy_evgen.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
From: YueHaibing
Fixes gcc '-Wunused-but-set-variable' warning:
sound/soc/intel/haswell/sst-haswell-ipc.c: In function 'hsw_stream_message':
sound/soc/intel/haswell/sst-haswell-ipc.c:669:29: warning: variable
'stage_type' set but not used [-Wunused-but-set-variable]
It is never used since
Add Milbeaut serial control including earlycon and console.
Signed-off-by: Sugaya Taichi
---
Changes from v2:
- Fix build warning.
Changes from v1:
- Add "COMPILE_TEST" dependency for coverage test.
drivers/tty/serial/Kconfig | 26 ++
drivers/tty/serial/Makefile| 1 +
Hi, Casey
On 2019/4/18 8:24, Casey Schaufler wrote:
On 4/17/2019 4:39 PM, Paul Moore wrote:
On Wed, Apr 17, 2019 at 12:27 PM Oleg Nesterov wrote:
On 04/17, Paul Moore wrote:
On Wed, Apr 17, 2019 at 10:57 AM Oleg Nesterov
wrote:
On 04/17, Paul Moore wrote:
I'm tempted to simply return an
On Wed, 17 Apr 2019 19:58:23 -0400
Masayoshi Mizuma wrote:
> From: Masayoshi Mizuma
>
> ktest fails if meta characters are in GRUB_MENU, for example
> GRUB_MENU = 'Fedora (test)'
>
> The failure happens because the meta characters are not escaped,
> so the menu doesn't match in any entries in
Hi,
On Wed, Apr 17, 2019 at 10:43:01AM +0800, Wen Yang wrote:
> The call to of_get_cpu_node/of_find_compatible_node/of_parse_phandle...
> returns a node pointer with refcount incremented thus it must be
> explicitly decremented after the last usage.
>
> We developed a coccinelle SmPL to detect
Hi,
The changes itself look all good to me, but this does multiple
things in a single patch, so please split it into multiple commits.
-- Sebastian
On Tue, Apr 16, 2019 at 06:43:19PM -0600, Nick Crews wrote:
> Add "Standard", "Adaptive", and "Custom" modes to the charge_type
> property, to
Hi,
On Fri, Apr 05, 2019 at 12:30:20AM -0700, Andrey Smirnov wrote:
> Fix a similar endless event loop as was done in commit 8dcf32175b4e
> ("i2c: prevent endless uevent loop with CONFIG_I2C_DEBUG_CORE"):
>
> The culprit is the dev_dbg printk in the i2c uevent handler. If
> this is activated
Hi,
On Thu, Apr 11, 2019 at 02:42:03PM +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> Add the DT binding document for the battery charger module of max77650.
>
> Signed-off-by: Bartosz Golaszewski
> ---
> .../power/supply/max77650-charger.txt | 28
Hi,
On Thu, Apr 11, 2019 at 02:42:08PM +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> Add basic support for the battery charger for max77650 PMIC.
>
> Signed-off-by: Bartosz Golaszewski
> Reviewed-by: Linus Walleij
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
>
On Thu, Apr 11, 2019 at 05:54:09AM +, Han Nandor wrote:
> Add a new reboot mode write interface that is using an NVMEM cell
> to store the reboot mode magic.
>
> Signed-off-by: Nandor Han
> ---
> drivers/power/reset/Kconfig | 9 +++
> drivers/power/reset/Makefile|
Hi,
On Tue, Apr 16, 2019 at 02:40:17PM +0800, Chen-Yu Tsai wrote:
> This is v4 of my A83T USB power supply / OTG series. Hopefully this is
> the last revision even though it's kind of late in the -rc cycle for
> the patches to make the next release. Fingers crossed.
Patches 1-5 (i.e. all except
In the function that creates a CSROW object, the object is not released
when failing to add the device to device hierarchy. This may result in a
memory leak bug.
Signed-off-by: Pan Bian
---
drivers/edac/edac_mc_sysfs.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git
On Wed, 17 Apr 2019 16:59:13 -0400
Masayoshi Mizuma wrote:
> > > diff --git a/tools/testing/ktest/ktest.pl b/tools/testing/ktest/ktest.pl
> > > index ea07d43856b8..765c6bc83ab4 100755
> > > --- a/tools/testing/ktest/ktest.pl
> > > +++ b/tools/testing/ktest/ktest.pl
> > > @@ -1737,6 +1737,11 @@
On Wed, Apr 17, 2019 at 09:07:35AM +0200, Peter Zijlstra wrote:
> On Tue, Apr 16, 2019 at 03:15:59PM -0500, Josh Poimboeuf wrote:
> > If you do the regs->eflags thing to mark the regs as fake in
> > (perf_arch_fetch_caller_regs()), then I don't think skip_sp would be
> > needed, because regs->sp
The RMI4 function structure has been released in rmi_register_function
if error occurs. However, it will be released again in the function
rmi_create_function, which may result in a double-free bug.
Signed-off-by: Pan Bian
---
drivers/input/rmi4/rmi_driver.c | 6 +-
1 file changed, 1
On Wed, Apr 17, 2019 at 5:39 PM Roman Gushchin wrote:
>
> On Wed, Apr 17, 2019 at 04:41:01PM -0700, Shakeel Butt wrote:
> > On Wed, Apr 17, 2019 at 2:55 PM Roman Gushchin wrote:
> > >
> > > This commit makes several important changes in the lifecycle
> > > of a non-root kmem_cache, which also
Hi Mukesh,
On Mon, Apr 15, 2019 at 03:35:51PM +0530, Mukesh Ojha wrote:
>
> Hi Dmitry,
>
> Can you please have a look at this patch ? as this seems to reproducing
> quite frequently
>
> Thanks,
> Mukesh
>
> On 4/10/2019 1:29 PM, Mukesh Ojha wrote:
> > uinput_destroy_device() gets called from
On Wed, Apr 17, 2019 at 11:02 AM Luca Weiss wrote:
>
> On Freitag, 12. April 2019 17:06:23 CEST Luca Weiss wrote:
> > Provide a simple driver for GPIO controllable vibrators.
> > It will be used by the Fairphone 2.
> >
> > Signed-off-by: Luca Weiss
> > ---
> >
Hi, Stu:
On Tue, 2019-04-16 at 17:30 +0800, Stu Hsieh wrote:
> This patch add mediatek mipicsi driver for mt2712,
> including probe function to get the value from device tree,
> and register to v4l2 the host device.
>
> Signed-off-by: Stu Hsieh
> ---
>
On 2019/4/18 1:41, Pierre-Louis Bossart wrote:
> On 4/17/19 10:11 AM, Yue Haibing wrote:
>> From: YueHaibing
>>
>> Fixes gcc '-Wunused-but-set-variable' warning:
>>
>> sound/soc/intel/haswell/sst-haswell-ipc.c: In function 'hsw_stream_message':
>> sound/soc/intel/haswell/sst-haswell-ipc.c:669:29:
Hi Igor,
Did you meet any issue with my latest patch?
> -Original Message-
> From: Robin Gong
> Sent: April 9, 2019 11:26>
> Hi Igor,
> Please have a try with the attached patches, and revert 25aaa75df1e6,
> ad0d92d7ba6a , dd4b487b32a3, df07101e1c4a before apply. Besides
Я знаю как стать первым номером в росте позиций сайтов.
Вы покаместь не в top=1?
Я эксперт в продвижении сео уже девять лет. Есть перворазрядное портфолио и
опыт.
Умудрюсь просунуть в google поиск.
Первостепенное с чем могу помочь это аудит.
Следом исправить что необходимо.
И в конце протолкнуть
On 04/17 :41, Alex Elder wrote:
> On 4/16/19 5:13 PM, Madhumitha Prabakaran wrote:
> > Fix a blank line after structure declarations. Also, convert
> > macros into inline functions in order to maintain Linux kernel
> > coding style based on which the inline function is
> > preferable over the
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
>>> allmodconfig) produced this warning:
>>>
>>> fs/f2fs/node.c: In function
Use the number of addresses to define the relevant macros.
Signed-off-by: damon
---
arch/riscv/include/asm/pgtable-32.h | 2 ++
arch/riscv/include/asm/pgtable-64.h | 3 ++-
arch/riscv/include/asm/pgtable.h| 4 ++--
3 files changed, 6 insertions(+), 3 deletions(-)
diff --git
On 04/17 :25, Greg KH wrote:
> On Tue, Apr 16, 2019 at 05:13:18PM -0500, Madhumitha Prabakaran wrote:
> > Fix a blank line after structure declarations. Also, convert
> > macros into inline functions in order to maintain Linux kernel
> > coding style based on which the inline function is
> >
On Tue, Apr 2, 2019 at 3:42 AM Patrick Bellasi wrote:
>
> Tasks without a user-defined clamp value are considered not clamped
> and by default their utilization can have any value in the
> [0..SCHED_CAPACITY_SCALE] range.
>
> Tasks with a user-defined clamp value are allowed to request any value
On Wed, Apr 17, 2019 at 04:41:01PM -0700, Shakeel Butt wrote:
> On Wed, Apr 17, 2019 at 2:55 PM Roman Gushchin wrote:
> >
> > This commit makes several important changes in the lifecycle
> > of a non-root kmem_cache, which also affect the lifecycle
> > of a memory cgroup.
> >
> > Currently each
On 4/17/2019 4:39 PM, Paul Moore wrote:
On Wed, Apr 17, 2019 at 12:27 PM Oleg Nesterov wrote:
On 04/17, Paul Moore wrote:
On Wed, Apr 17, 2019 at 10:57 AM Oleg Nesterov wrote:
On 04/17, Paul Moore wrote:
I'm tempted to simply return an error in selinux_setprocattr() if
the task's
On 19. 4. 18. 오전 7:29, Dmitry Osipenko wrote:
> There is no real need in the primary interrupt handler, hence move
> everything to the secondary (threaded) handler. In a result locking
> is consistent now and there are no potential races with the interrupt
> handler because it is protected with
On 19. 4. 18. 오전 7:29, Dmitry Osipenko wrote:
> The clk_set_min_rate() could fail and in this case clk_set_rate() sets
> rate to 0, which may drop EMC rate to minimum and make machine very
> difficult to use.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/tegra-devfreq.c | 16
On 19. 4. 18. 오전 7:29, Dmitry Osipenko wrote:
> In order to reflect that driver serves NVIDIA Tegra30 and later SoC
> generations, let's rename the driver's source file to "tegra30-devfreq.c".
> This will make driver files to look more consistent after addition of a
> driver for Tegra20.
>
>
On 19. 4. 18. 오전 7:29, Dmitry Osipenko wrote:
> The devfreq driver can be used on Tegra30 without any code change and
> it works perfectly fine, the default Tegra124 parameters are good enough
> for Tegra30.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/Kconfig | 4 ++--
>
On 4/17/19 4:39 PM, Paul Moore wrote:
> On Wed, Apr 17, 2019 at 12:27 PM Oleg Nesterov wrote:
>> On 04/17, Paul Moore wrote:
>>>
>>> On Wed, Apr 17, 2019 at 10:57 AM Oleg Nesterov wrote:
On 04/17, Paul Moore wrote:
>
> I'm tempted to simply return an error in selinux_setprocattr()
On Tue, Apr 2, 2019 at 3:43 AM Patrick Bellasi wrote:
>
> The cgroup CPU bandwidth controller allows to assign a specified
> (maximum) bandwidth to the tasks of a group. However this bandwidth is
> defined and enforced only on a temporal base, without considering the
> actual frequency a CPU is
On 04/17/2019 02:29 PM, Ingo Molnar wrote:
>
> * Thara Gopinath wrote:
>
>>
>> On 04/17/2019 01:36 AM, Ingo Molnar wrote:
>>>
>>> * Thara Gopinath wrote:
>>>
The test results below shows 3-5% improvement in performance when
using the third solution compared to the default system
On (04/17/19 23:18), Feng Tang wrote:
> > > +++ b/kernel/printk/printk.c
> > > @@ -2549,6 +2549,14 @@ void console_flush_on_panic(void)
> > >*/
> > > console_trylock();
> > > console_may_schedule = 0;
> > > + if (flush_mode == CONSOLE_FLUSH_ALL) {
> > > + /*
> > > + * Can
From: Masayoshi Mizuma
ktest fails if meta characters are in GRUB_MENU, for example
GRUB_MENU = 'Fedora (test)'
The failure happens because the meta characters are not escaped,
so the menu doesn't match in any entries in GRUB_FILE.
Use quotemeta() to escape the meta characters.
Signed-off-by:
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...@vger.kernel.org
Fixes: 226dfa4726eb ("clk: Add Ingenic jz4725b CGU driver")
> From: Thomas Gleixner
> Sent: Tuesday, April 16, 2019 1:13 PM
> > ...
> > True. And before we start digging deeper into this, let's step back: why
> > do we need to do clockevents_unbind_device() on hybernation? Can we just
> > disable the device and re-enable it back on resume?
We do
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
> ---
Is this breaking something
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 driver to use the 'BIT' macro from all '1 << XXX'
>>> bit operations to get rid of compiler warning and improve readability of
>>> the code
>>
>>
On Wed, Apr 17, 2019 at 2:55 PM Roman Gushchin wrote:
>
> This commit makes several important changes in the lifecycle
> of a non-root kmem_cache, which also affect the lifecycle
> of a memory cgroup.
>
> Currently each charged slab page has a page->mem_cgroup pointer
> to the memory cgroup and
This patch adds support for CDTech S050WV43-CT5 800x480 5" panel to DRM
simple panel driver.
Signed-off-by: Florent TOMASIN
---
drivers/gpu/drm/panel/panel-simple.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
On Wed, Apr 17, 2019 at 12:27 PM Oleg Nesterov wrote:
> On 04/17, Paul Moore wrote:
> >
> > On Wed, Apr 17, 2019 at 10:57 AM Oleg Nesterov wrote:
> > > On 04/17, Paul Moore wrote:
> > > >
> > > > I'm tempted to simply return an error in selinux_setprocattr() if
> > > > the task's credentials are
On Wed, Apr 17, 2019 at 4:21 PM Andrew Morton wrote:
>
> On Wed, 17 Apr 2019 15:53:28 -0700 Tri Vo wrote:
>
> > LLVM uses profiling data that's deliberately similar to GCC, but has a very
> > different way of exporting that data. LLVM calls llvm_gcov_init() once per
> > module, and provides a
Add documentation for S050WV43-CT5 panel
Signed-off-by: Florent TOMASIN
---
.../bindings/display/panel/cdtech,s050wv43-ct5.txt | 12
1 file changed, 12 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/cdtech,s050wv43-ct5.txt
diff --git
On Wed, 17 Apr 2019 15:53:28 -0700 Tri Vo wrote:
> LLVM uses profiling data that's deliberately similar to GCC, but has a very
> different way of exporting that data. LLVM calls llvm_gcov_init() once per
> module, and provides a couple of callbacks that we can use to ask for more
> data.
>
>
Hi Aaro, Tony,
On Wednesday, April 17, 2019 11:40:10 AM CEST Miquel Raynal wrote:
> Hi Janusz,
>
> Janusz Krzysztofik wrote on Sun, 24 Mar 2019
> 23:33:44 +0100:
>
> > After recent modifications, only a hardcoded partition info makes
> > the driver device specific. Other than that, the driver
On Tue, Apr 2, 2019 at 3:42 AM Patrick Bellasi wrote:
>
> By default FAIR tasks start without clamps, i.e. neither boosted nor
> capped, and they run at the best frequency matching their utilization
> demand. This default behavior does not fit RT tasks which instead are
> expected to run at the
On Thu, Apr 11, 2019 at 6:46 AM Andy Shevchenko
wrote:
>
> On Thu, Apr 11, 2019 at 3:38 AM Rajat Jain wrote:
> >
> > Add code to instantiate the pmc_core platform device and thus attach to
> > the driver, if the ACPI device for the same ("INT33A1") is not present
> > in a system where it should
On Thu, Apr 11, 2019 at 6:40 AM Andy Shevchenko
wrote:
>
> On Thu, Apr 11, 2019 at 3:38 AM Rajat Jain wrote:
> >
> > Add a module parameter which when enabled, will check on resume, if the
> > last S0ix attempt was successful. If not, the driver would warn and provide
> > helpful debug
On Thu, Apr 11, 2019 at 6:44 AM Andy Shevchenko
wrote:
>
> On Thu, Apr 11, 2019 at 3:37 AM Rajat Jain wrote:
> >
> > Convert the intel_pmc_core driver to a platform driver, and attach using
> > the ACPI enumeration method (via the ACPI device "INT33A1").
>
> > cpu_id =
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:
>
> > __vunmap() calls find_vm_area() twice without an obvious reason:
> > first directly to get the area pointer, second indirectly by calling
> > remove_vm_area(), which is
Hi Kees,
On Wed, 17 Apr 2019 17:28:39 -0500 Kees Cook wrote:
>
> On Wed, Apr 17, 2019 at 5:22 PM Kees Cook wrote:
> >
> > On Wed, Apr 17, 2019 at 1:53 AM Stephen Rothwell
> > wrote:
> > >
> > > Hi Andrew,
> > >
> > > After merging the akpm-current tree, today's linux-next build (arm
> > >
Add a module parameter which when enabled, will check on resume, if the
last S0ix attempt was successful. If not, the driver would warn and provide
helpful debug information (which gets latched during the failed suspend
attempt) to debug the S0ix failure.
This information is very useful to debug
Most modern platforms already have the ACPI device "INT33A1" that could
be used to attach to the driver. Switch the driver to using that and
thus make the intel_pmc_core.c a pure platform_driver.
Some of the legacy platforms though, may still not have this ACPI device
in their ACPI tables. Thus
Convert the intel_pmc_core driver to a platform driver. There is no
functional change to the driver, or to the way the devices are
instantiated.
Signed-off-by: Rajat Jain
---
v6: Let the way devices are instantiated exactly the same as before this
patch (so no functional change other than
On Wed, Apr 17, 2019 at 5:22 PM Kees Cook wrote:
>
> On Wed, Apr 17, 2019 at 1:53 AM Stephen Rothwell
> wrote:
> >
> > Hi Andrew,
> >
> > After merging the akpm-current tree, today's linux-next build (arm
> > multi_v7_defconfig) failed like this:
> >
> > fs/binfmt_elf.c: In function
On Tue, Apr 2, 2019 at 3:42 AM Patrick Bellasi wrote:
>
> The SCHED_DEADLINE scheduling class provides an advanced and formal
> model to define tasks requirements that can translate into proper
> decisions for both task placements and frequencies selections. Other
> classes have a more simplified
From: Greg Hackmann
LLVM uses profiling data that's deliberately similar to GCC, but has a very
different way of exporting that data. LLVM calls llvm_gcov_init() once per
module, and provides a couple of callbacks that we can use to ask for more
data.
We care about the "writeout" callback,
1 - 100 of 800 matches
Mail list logo
