On Tue, Oct 06, 2020 at 04:28:09AM +0200, Willy Tarreau wrote:
> Hi Kees,
>
> On Mon, Oct 05, 2020 at 07:12:29PM -0700, Kees Cook wrote:
> > On Fri, Oct 02, 2020 at 05:16:11PM +0200, Thibaut Sautereau wrote:
> > > From: Thibaut Sautereau
> > >
> > > Commit f227e3ec3b5c ("random32: update the
On Mon, 5 Oct 2020 at 20:59, Greg Kroah-Hartman
wrote:
>
> This is the start of the stable review cycle for the 5.4.70 release.
> There are 57 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
>
Lee Jones writes:
> On Thu, 10 Sep 2020, Lee Jones wrote:
>
>> This is a rebased/re-worked set of patches which have been
>> previously posted to the mailing list(s).
>>
>> This set is part of a larger effort attempting to clean-up W=1
>> kernel builds, which are currently overwhelmingly
On 05.10.2020 18:00, Florian Fainelli wrote:
>
>
> On 10/5/2020 8:54 AM, Heiner Kallweit wrote:
>> On 05.10.2020 17:41, Florian Fainelli wrote:
>>>
>>>
>>> On 10/5/2020 1:53 AM, Jisheng Zhang wrote:
On Wed, 30 Sep 2020 13:23:29 -0700 Florian Fainelli wrote:
>
> On
This fixes a regression for blocking connects introduced by commit
4becb7ee5b3d ("net/x25: Fix x25_neigh refcnt leak when x25 disconnect").
The x25->neighbour is already set to "NULL" by x25_disconnect() now,
while a blocking connect is waiting in
x25_wait_for_connection_establishment().
On 05-10-20, 13:38, Rob Herring wrote:
> In order to add meta-schema checks for additional/unevaluatedProperties
> being present, all schema need to make this explicit. As the top-level
> board/SoC schemas always have additional properties, add
> 'additionalProperties: true'.
>
> Signed-off-by:
Hi Christoph,
On Tue, 6 Oct 2020 07:13:01 +0200 Christoph Hellwig wrote:
>
> On Tue, Oct 06, 2020 at 02:58:47PM +1100, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the net-next tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
>
> It actually doesn't
On Tue, Oct 06, 2020 at 11:39:49AM +0900, namhy...@kernel.org wrote:
> > > On Fri, Oct 02, 2020 at 10:03:17PM +0900, Namhyung Kim wrote:
> > > > Below measures time and memory usage during the perf inject and
> > > > report using ~190MB data file.
> > > >
> > > > Before:
> > > > perf inject:
On 06-10-20, 00:24, Sumit Gupta wrote:
>
> > > Warning coming during boot because the boot freq set by bootloader
> > > gets filtered out due to big freq steps while creating freq_table.
> > > Fixing this by setting closest ndiv value from freq_table.
> > > Warning:
> > >cpufreq:
On 05-10-20, 13:38, Rob Herring wrote:
> In order to add meta-schema checks for additional/unevaluatedProperties
> being present, all schema need to make this explicit. As common/shared
> schema are included by other schemas, they should always allow for
> additionalProperties.
Acked-By: Vinod
On 05-10-20, 13:38, Rob Herring wrote:
> This doesn't yet do anything in the tools, but make it explicit so we can
> check either 'unevaluatedProperties' or 'additionalProperties' is present
> in schemas.
>
> 'unevaluatedProperties' is appropriate when including another schema (via
> '$ref') and
Hi all,
After merging the mmc tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
drivers/mmc/host/sdhci-acpi.c: In function 'amd_select_drive_strength':
drivers/mmc/host/sdhci-acpi.c:562:39: error: 'SDHCI_PRESET_DRV_SHIFT'
undeclared (first use in this function); did you
On Mon, 5 Oct 2020 at 21:01, Greg Kroah-Hartman
wrote:
>
> This is the start of the stable review cycle for the 5.8.14 release.
> There are 85 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
>
On Mon, 5 Oct 2020 14:33:21 +0530, Vignesh Raghavendra wrote:
> This reverts commit 03edda0e1edaa3c2e99239c66e3c14d749318fd6.
>
> This leads to warn dump like [1] on some platforms and reorders MTD
> devices thus may break user space expectations. So revert the change.
>
> [1]:
>
> [...]
On Tue, Oct 06, 2020 at 02:58:47PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the net-next tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
It actually doesn't need that or the two other internal headers.
Bjoern has a fixed, and it was supposed to be
On Mon, Oct 05, 2020 at 08:35:59PM -0700, Guenter Roeck wrote:
> On 10/5/20 7:59 PM, Sergey Senozhatsky wrote:
> > Cc-ing Guenter,
> >
> > On (20/05/22 12:00), Petr Mladek wrote:
> >> On Fri 2020-05-22 16:53:06, Shreyas Joshi wrote:
> >>> If uboot passes a blank string to console_setup then it
Hi all,
Today's linux-next merge of the input tree got a conflict in:
Documentation/devicetree/bindings/vendor-prefixes.yaml
between commit:
cb1cc137a2c1 ("dt-bindings: Add vendor prefix for Shenzhen Zkmagic Technology
Co., Ltd.")
from the arm-soc tree and commit:
8f445ffa851e
Hi Russell,
Could you have a look a those two patches for the STi platform ?
Regards,
Alain
On Sat, Sep 12, 2020 at 12:13:59PM +0200, Linus Walleij wrote:
> On Sun, Aug 30, 2020 at 9:58 PM Alain Volmat wrote:
>
> > This serie update the STi Platform LL_UART code to rely on
> >
On Mon, Oct 05, 2020 at 11:18:34PM -0400, Theodore Y. Ts'o wrote:
> What Josh is proposing I'm pretty sure would also break "e2fsck -E
> unshare_blocks", so that's another reason not to accept this as a
> valid format change.
The kernel already accepted this as a valid mountable filesystem
On 10/5/20 7:13 AM, Maxime Ripard wrote:
> On Sat, Oct 03, 2020 at 04:19:38PM +0200, Clément Péron wrote:
>> As slots and slot_width can be set manually using set_tdm().
>> These values are then kept in sun4i_i2s struct.
>> So we need to check if these values are setted or not
>> in the struct.
>>
On Mon, Oct 05, 2020 at 10:38:17AM +0200, Christoph Hellwig wrote:
> On Fri, Oct 02, 2020 at 01:20:35PM -0700, Sagi Grimberg wrote:
> >> Well, why would they change it? The whole point of the infrastructure
> >> is that there is a single sane affinity setting for a given setup. Now
> >> that
On Mon, 2020-10-05 at 21:50 -0700, Randy Dunlap wrote:
> From: Randy Dunlap
>
> arch/arc/ implements BUG_ON() with BUG(). ARC has its own BUG()
> function and that function uses pr_warn() as part of its implementation.
>
> Several (8) files in amd/powerplay/ #undef various pr_xyz() functions so
syzbot suspects this issue was fixed by commit:
commit bce1305c0ece3dc549663605e567655dd701752c
Author: Marc Zyngier
Date: Sat Aug 29 11:26:01 2020 +
HID: core: Correctly handle ReportSize being zero
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=10b82f5050
start
On 10/5/20 7:04 AM, Maxime Ripard wrote:
> Hi,
>
> On Wed, Sep 30, 2020 at 09:11:46PM -0500, Samuel Holland wrote:
>> The AIF clock control register has the same layout for all three AIFs.
>> The only difference between them is that AIF3 is missing some fields. We
>> can reuse the same register
On Mon, Oct 5, 2020 at 7:29 PM Sean Christopherson
wrote:
>
> On Mon, Oct 05, 2020 at 12:30:03PM -0700, Andy Lutomirski wrote:
> > On 32-bit kernels, the stackprotector canary is quite nasty -- it is
> > stored at %gs:(20), which is nasty because 32-bit kernels use %fs for
> > percpu storage.
From: Randy Dunlap
arch/arc/ implements BUG_ON() with BUG(). ARC has its own BUG()
function and that function uses pr_warn() as part of its implementation.
Several (8) files in amd/powerplay/ #undef various pr_xyz() functions so
that they won't be used by these drivers, since dev_() functions
On 05. 10. 20, 13:31, Greg Kroah-Hartman wrote:
> On Fri, Oct 02, 2020 at 08:03:04AM -0500, miny...@acm.org wrote:
>> From: Corey Minyard
>>
>> If you write to a pty master an immediately close the pty master, the
>> receiver might get a chunk of data dropped, but then receive some later
>> data.
Hi Dmitry,
> Hello, Wolfram! Thank you! This series started with 10 small patches and
> then was growing with every new review round because more ideas were
> suggested and I needed to rebase/redo majority of the patches, hence it
> was a bit difficult to split it up into a smaller parts that
On 10/5/20 8:15 AM, Chen-Yu Tsai wrote:
> On Mon, Oct 5, 2020 at 8:01 PM Maxime Ripard wrote:
>>
>> On Wed, Sep 30, 2020 at 09:11:43PM -0500, Samuel Holland wrote:
>>> The codec's clock input is shared among all AIFs, and shared with other
>>> audio-related hardware in the SoC, including I2S and
On 10/5/20 7:01 AM, Maxime Ripard wrote:
> On Wed, Sep 30, 2020 at 09:11:43PM -0500, Samuel Holland wrote:
>> The codec's clock input is shared among all AIFs, and shared with other
>> audio-related hardware in the SoC, including I2S and SPDIF controllers.
>> To ensure sample rates selected by
On Tue, 6 Oct 2020, Dwaipayan Ray wrote:
> On Tue, Oct 6, 2020 at 2:39 AM Joe Perches wrote:
> >
> > On Tue, 2020-10-06 at 01:37 +0530, Dwaipayan Ray wrote:
> > > On Tue, Oct 6, 2020 at 1:07 AM Joe Perches wrote:
> > > > On Tue, 2020-10-06 at 00:54 +0530, Dwaipayan Ray wrote:
> > > > > The
Guenter Roeck 於 2020年10月5日 週一 下午11:30寫道：
>
> On 10/5/20 4:08 AM, Greg KH wrote:
> [ ... ]
> >>> What ever happened with this patch, is there still disagreement?
> >>>
> >>
> >> Yes, there is. I wouldn't have added the conditional without reason,
> >> and I am concerned that removing it entirely
On Fri, 2020-10-02 at 13:07 +0200, Krzysztof Kozlowski wrote:
> On Wed, Sep 30, 2020 at 03:06:24PM +0800, Yong Wu wrote:
> > Convert MediaTek IOMMU to DT schema.
> >
> > Signed-off-by: Yong Wu
> > ---
> > .../bindings/iommu/mediatek,iommu.txt | 103
> >
Hi all,
On Mon, 5 Oct 2020 23:01:50 +1100 Stephen Rothwell
wrote:
>
> On Sun, 04 Oct 2020 22:11:23 +0200 Paul Cercueil wrote:
> >
> > Pushed to drm-misc-next with the changelog fix, thanks.
> >
> > Stephen:
> > Now it should build fine again. Could you remove the BROKEN flag?
>
> Thanks
On 10/5/20 6:30 AM, Maxime Ripard wrote:
On Wed, Sep 30, 2020 at 09:11:34PM -0500, Samuel Holland wrote:
When using the I2S, LEFT_J, or RIGHT_J format, the hardware supports
independent BCLK and LRCK inversion control. When using DSP_A or DSP_B,
LRCK inversion is not supported. The register
On Fri, 2020-10-02 at 13:08 +0200, Krzysztof Kozlowski wrote:
> On Wed, Sep 30, 2020 at 03:06:25PM +0800, Yong Wu wrote:
> > Convert MediaTek SMI to DT schema.
> >
> > Signed-off-by: Yong Wu
> > ---
> > .../mediatek,smi-common.txt | 49 -
> >
Hi Krzysztof,
On Fri, 2020-10-02 at 13:10 +0200, Krzysztof Kozlowski wrote:
> On Wed, Sep 30, 2020 at 03:06:29PM +0800, Yong Wu wrote:
> > This patch adds decriptions for mt8192 IOMMU and SMI.
> >
> > mt8192 also is MTK IOMMU gen2 which uses ARM Short-Descriptor translation
> > table format. The
On Tue, Oct 6, 2020 at 2:39 AM Joe Perches wrote:
>
> On Tue, 2020-10-06 at 01:37 +0530, Dwaipayan Ray wrote:
> > On Tue, Oct 6, 2020 at 1:07 AM Joe Perches wrote:
> > > On Tue, 2020-10-06 at 00:54 +0530, Dwaipayan Ray wrote:
> > > > The author signed-off-by checks are currently very vague.
> >
On Tue, Oct 6, 2020 at 11:57 AM Ikjoon Jang wrote:
>
> On Mon, Oct 5, 2020 at 7:50 PM Stephen Rothwell wrote:
> >
> > Hi all,
> >
> > In commit
> >
> > f9d293364b45 ("power: supply: sbs-battery: keep error code when
> > get_property() fails")
> >
> > Fixes tag
> >
> > Fixes: c4f382930145
On Tue, Oct 06, 2020 at 12:47:37AM +0530, Vaibhav Agarwal wrote:
On Sat, Oct 3, 2020 at 5:01 AM Coiby Xu wrote:
This patch fix the following warnings from sparse,
$ make C=2 drivers/staging/greybus/
drivers/staging/greybus/audio_module.c:222:25: warning: incorrect type in
assignment
The order in which 'users' counter is decremented vs calling drivers'
close() method is implementation specific, and we should not rely on
it. Let's introduce driver private flag and use it to signal ISR
to exit when device is being closed.
This has a side-effect of fixing issue of accessing
On Tue, 6 Oct 2020 11:40:58 +0900
Masami Hiramatsu wrote:
> On Mon, 5 Oct 2020 18:13:22 -0700 (PDT)
> Stefano Stabellini wrote:
>
> > On Mon, 5 Oct 2020, Julien Grall wrote:
> > > Hi Masami,
> > >
> > > On 05/10/2020 14:39, Masami Hiramatsu wrote:
> > > > Use per_cpu_ptr_to_phys() instead of
On Tue, 2020-10-06 at 11:59 +0800, Chris Chiu wrote:
> From: Chris Chiu
>
> The legacy_httxpowerdiff in rtl8192se is pretty much the same as
> the legacy_ht_txpowerdiff for other chips. Use the same name to
> keep the consistency.
>
> Signed-off-by: Chris Chiu
> ---
>
On 10/5/20 8:30 PM, Randy Dunlap wrote:
> From: Randy Dunlap
>
> Fix copy/paste spello of "themselves" in 3 places.
>
> Signed-off-by: Randy Dunlap
> Cc: Vineet Gupta
> Cc: linux-snps-...@lists.infradead.org
Thx for the fix Randy. Added to for-curr.
-Vineet
> ---
>
On 10/5/20 9:12 AM, Mike Rapoport wrote:
> From: Mike Rapoport
>
> When a secondary CPU fails to come up, there is a missing space in the
> log:
>
> Timeout: CPU1 FAILED to comeup !!!
>
> Fix it.
>
> Signed-off-by: Mike Rapoport
Thx for the fix Mike. Added to for-curr.
-Vineet
> ---
From: Chris Chiu
The legacy_httxpowerdiff in rtl8192se is pretty much the same as
the legacy_ht_txpowerdiff for other chips. Use the same name to
keep the consistency.
Signed-off-by: Chris Chiu
---
drivers/net/wireless/realtek/rtlwifi/rtl8192se/hw.c | 2 +-
Changes since v9 [1]:
- (Boris) Compile out the copy_mc_fragile() infrastructure in the
CONFIG_X86_MCE=n case.
This had several knock-on effects. The proposed x86: copy_mc_generic()
was internally checking for X86_FEATURE_ERMS and falling back to
copy_mc_fragile(), however that fallback
The original copy_mc_fragile() implementation had negative performance
implications since it did not use the fast-string instruction sequence
to perform copies. For this reason copy_mc_to_kernel() fell back to
plain memcpy() to preserve performance on platform that did not indicate
the capability
In reaction to a proposal to introduce a memcpy_mcsafe_fast()
implementation Linus points out that memcpy_mcsafe() is poorly named
relative to communicating the scope of the interface. Specifically what
addresses are valid to pass as source, destination, and what faults /
exceptions are handled.
Hi all,
After merging the net-next tree, today's linux-next build (x86_64
allmodconfig) failed like this:
net/xdp/xsk_buff_pool.c:7:10: fatal error: linux/dma-noncoherent.h: No such
file or directory
7 | #include
| ^
Caused by commit
1c1efc2af158
On Mon, Oct 5, 2020 at 7:50 PM Stephen Rothwell wrote:
>
> Hi all,
>
> In commit
>
> f9d293364b45 ("power: supply: sbs-battery: keep error code when
> get_property() fails")
>
> Fixes tag
>
> Fixes: c4f382930145 (power: supply: sbs-battery: don't assume i2c errors as
> battery disconnect)
>
Hi Junio,
Thanks for the release candidate!
Minor comments follow.
On Tue, 6 Oct 2020 at 01:00, Junio C Hamano wrote:
> * The final leg of SHA-256 transition plus doc updates. Note that
>there is no inter-operability between SHA-1 and SHA-256
>repositories yet.
I suspect the dash in
Hi all,
Today's linux-next merge of the sunxi tree got a conflict in:
arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
between commit:
0dea1794f3b4 ("arm64: allwinner: A100: add the basical Allwinner A100 DTSI
file")
from the arm-soc tree and commit:
7e66a778cb8b ("arm64: allwinner:
The AES code uses a 'br x7' as part of a function called by
a macro. That branch needs a bti_j as a target. This results
in a panic as seen below. Instead of trying to replace the branch
target with a bti_jc, lets replace the indirect branch with a
bl/ret, bl sequence that can target the existing
On Mon, Oct 5, 2020 at 5:44 PM Hillf Danton wrote:
>
>
> On Mon, 5 Oct 2020 18:17:01 Kristian H. Kristensen wrote:
> > On Mon, Oct 5, 2020 at 4:02 PM Daniel Vetter wrote:
> > >
> > > On Mon, Oct 05, 2020 at 05:24:19PM +0800, Hillf Danton wrote:
> > > >
> > > > On Sun, 4 Oct 2020 12:21:45
> > >
On 10/02/2020 01:46 AM, Sudarshan Rajagopalan wrote:
> When section mappings are enabled, we allocate vmemmap pages from physically
> continuous memory of size PMD_SIZE using vmemmap_alloc_block_buf(). Section
> mappings are good to reduce TLB pressure. But when system is highly fragmented
>
On 10/5/20 7:59 PM, Sergey Senozhatsky wrote:
> Cc-ing Guenter,
>
> On (20/05/22 12:00), Petr Mladek wrote:
>> On Fri 2020-05-22 16:53:06, Shreyas Joshi wrote:
>>> If uboot passes a blank string to console_setup then it results in a
>>> trashed memory.
>>> Ultimately, the kernel crashes during
On Mon, 5 Oct 2020 14:47:47 -0300 Jason Gunthorpe wrote:
> Andrew please let me know if you need a resend
Andrew is rather confused.
Can we please identify the minimal patch(es) which are needed for 5.9
and -stable?
From: Randy Dunlap
Fix copy/paste spello of "themselves" in 3 places.
Signed-off-by: Randy Dunlap
Cc: Vineet Gupta
Cc: linux-snps-...@lists.infradead.org
---
arch/arc/include/asm/atomic.h |4 ++--
arch/arc/include/asm/cmpxchg.h |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
On Mon, Oct 5, 2020 at 11:20 AM Daniel Vetter wrote:
>
> On Mon, Oct 5, 2020 at 6:24 PM Kristian Høgsberg wrote:
> >
> > On Sun, Oct 4, 2020 at 9:21 PM Rob Clark wrote:
> > >
> > > From: Rob Clark
> > >
> > > This doesn't remove *all* the struct_mutex, but it covers the worst
> > > of it, ie.
On Tue, 2020-10-06 at 00:34 +, Joel Stanley wrote:
> arch/powerpc/boot is the powerpc wrapper, and it's not built with the
> same includes or flags as the rest of the kernel. It doesn't include
> any of the headers in the top level include/ directory for hysterical
> raisins.
>
> The
Sergey, thanks for your patch.
Reviewed-by: Bingbu Cao
BRs,
Bingbu Cao
> -Original Message-
> From: Sergey Senozhatsky
> Sent: Wednesday, September 30, 2020 9:13 AM
> To: Mauro Carvalho Chehab ; Cao, Bingbu
>
> Cc: Sakari Ailus ;
On Mon, Oct 05, 2020 at 07:51:10PM -0700, Darrick J. Wong wrote:
> > > Could /somebody/ please document the ondisk format changes that are
> > > associated with this feature?
> >
> > I pretty much had to sort it out by looking at a combination of
> > e2fsprogs and the kernel, and a lot of
On 10/01/2020 06:23 AM, Gavin Shan wrote:
> Hi Anshuman,
>
> On 9/29/20 11:54 PM, Anshuman Khandual wrote:
>> This adds a validation function that scans the entire boot memory and makes
>> sure that all early memory sections are online. This check is essential for
>> the memory notifier to
Cc-ing Guenter,
On (20/05/22 12:00), Petr Mladek wrote:
> On Fri 2020-05-22 16:53:06, Shreyas Joshi wrote:
> > If uboot passes a blank string to console_setup then it results in a
> > trashed memory.
> > Ultimately, the kernel crashes during freeing up the memory. This fix
> > checks if there
>
On 10/01/2020 05:27 AM, Gavin Shan wrote:
> Hi Anshuman,
>
> On 9/29/20 11:54 PM, Anshuman Khandual wrote:
>> This enables MEM_OFFLINE memory event handling. It will help intercept any
>> possible error condition such as if boot memory some how still got offlined
>> even after an explicit
On 10/05/2020 11:35 AM, Michal Hocko wrote:
> On Mon 05-10-20 07:59:12, Anshuman Khandual wrote:
>>
>>
>> On 10/02/2020 05:34 PM, Michal Hocko wrote:
>>> On Wed 30-09-20 11:30:49, Anshuman Khandual wrote:
Add following new vmstat events which will track HugeTLB page migration.
1.
On Sat, Oct 03, 2020 at 07:50:56AM +0300, Jarkko Sakkinen wrote:
> From: Sean Christopherson
> + /* Validate that the reserved area contains only zeros. */
> + push%rax
> + push%rbx
> + mov $SGX_ENCLAVE_RUN_RESERVED_START, %rbx
> +1:
> + mov (%rcx, %rbx), %rax
On Mon, Oct 05, 2020 at 05:32:16PM -0700, Josh Triplett wrote:
> On Mon, Oct 05, 2020 at 10:36:39AM -0700, Darrick J. Wong wrote:
> > On Mon, Oct 05, 2020 at 01:14:54AM -0700, Josh Triplett wrote:
> > > Ran into an ext4 regression when testing upgrades to 5.9-rc kernels:
> > >
> > > Commit
On 05-10-2020 14:48, Hans de Goede wrote:
> To fully fix the memleak you also need to add a kfree_skb(h5->rx_skb);
> call to the end of h5_serdev_remove(), because in the hu->serdev case
> that is where the h5 struct will be free-ed (it is free-ed after that
> function exits).
Hi Hans,
I'm not
This doesn't seem like a great idea to me.
For my system I've got:
/sys/devices/platform/Fixed MDIO bus.0/
/sys/bus/platform/drivers/int3401 thermal/
/sys/bus/platform/drivers/int3403 thermal/
/sys/bus/platform/drivers/int3400 thermal/
/sys/bus/mdio_bus/drivers/Generic PHY/
On Mon, 5 Oct 2020 18:13:22 -0700 (PDT)
Stefano Stabellini wrote:
> On Mon, 5 Oct 2020, Julien Grall wrote:
> > Hi Masami,
> >
> > On 05/10/2020 14:39, Masami Hiramatsu wrote:
> > > Use per_cpu_ptr_to_phys() instead of virt_to_phys() for per-cpu
> > > address conversion.
> > >
> > > In
> > On Fri, Oct 02, 2020 at 10:03:17PM +0900, Namhyung Kim wrote:
> > > Below measures time and memory usage during the perf inject and
> > > report using ~190MB data file.
> > >
> > > Before:
> > > perf inject: 11.09 s, 382148 KB
> > > perf report: 8.05 s, 397440 KB
> > >
> > > After:
>
HI Sudeep and Michal,
>-Original Message-
>From: Sudeep Holla
>Sent: Tuesday, October 6, 2020 4:08 AM
>To: Zulkifli, Muhammad Husaini
>Cc: Michal Simek ; Hunter, Adrian
>; ulf.hans...@linaro.org; linux-
>m...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
On Mon, Oct 05, 2020 at 12:30:03PM -0700, Andy Lutomirski wrote:
> On 32-bit kernels, the stackprotector canary is quite nasty -- it is
> stored at %gs:(20), which is nasty because 32-bit kernels use %fs for
> percpu storage. It's even nastier because it means that whether %gs
> contains
Hi Kees,
On Mon, Oct 05, 2020 at 07:12:29PM -0700, Kees Cook wrote:
> On Fri, Oct 02, 2020 at 05:16:11PM +0200, Thibaut Sautereau wrote:
> > From: Thibaut Sautereau
> >
> > Commit f227e3ec3b5c ("random32: update the net random state on interrupt
> > and activity") broke compilation and was
On Mon, Oct 5, 2020 at 4:19 AM Peter Zijlstra wrote:
>
> On Fri, Mar 06, 2020 at 02:34:20PM -0800, Xi Wang wrote:
> > On Fri, Mar 6, 2020 at 12:40 AM Peter Zijlstra wrote:
> > >
> > > On Thu, Mar 05, 2020 at 02:11:49PM -0800, Paul Turner wrote:
> > > > The goal is to improve jitter since we're
It will reuse the memory for other things when the whole slab is freed
though. Not really realistic to change that without it being backed by
virtual memory along with higher-level management of regions to avoid
intense fragmentation and metadata waste. It would depend a lot on
having much
Hi Alexander,
On Mon, Oct 05, 2020 at 10:34:42PM +0200, Alexander Dahl wrote:
> The node names for devices using the pwm-leds driver follow a certain
> naming scheme (now). Parent node name is not enforced, but recommended
> by DT project.
>
> DTC
On Tue, Oct 6, 2020 at 4:09 AM Kees Cook wrote:
> On Tue, Oct 06, 2020 at 01:44:14AM +0100, Matthew Wilcox wrote:
> > On Tue, Oct 06, 2020 at 12:56:33AM +0200, Jann Horn wrote:
> > > It seems to me like, if you want to make UAF exploitation harder at
> > > the heap allocator layer, you could do
On Fri, Oct 02, 2020 at 05:16:11PM +0200, Thibaut Sautereau wrote:
> From: Thibaut Sautereau
>
> Commit f227e3ec3b5c ("random32: update the net random state on interrupt
> and activity") broke compilation and was temporarily fixed by Linus in
> 83bdc7275e62 ("random32: remove net_rand_state from
Hi Catalin,
On 2020/10/6 1:19, Catalin Marinas wrote:
> On Mon, Sep 07, 2020 at 09:47:45PM +0800, Chen Zhou wrote:
>> diff --git a/Documentation/admin-guide/kdump/kdump.rst
>> b/Documentation/admin-guide/kdump/kdump.rst
>> index 2da65fef2a1c..549611abc581 100644
>> ---
On Tue, Oct 06, 2020 at 01:44:14AM +0100, Matthew Wilcox wrote:
> On Tue, Oct 06, 2020 at 12:56:33AM +0200, Jann Horn wrote:
> > It seems to me like, if you want to make UAF exploitation harder at
> > the heap allocator layer, you could do somewhat more effective things
> > with a probably much
From: Randy Dunlap
Fix multiple occurrences of duplicated words in kernel/.
Fix one typo/spello on the same line as a duplicate word.
Change one instance of "the the" to "that the".
Otherwise just drop one of the repeated words.
Signed-off-by: Randy Dunlap
Cc: Andrew Morton
---
Hi Bhupesh,
On 2020/10/6 1:42, Bhupesh Sharma wrote:
> Hi Catalin, Chen,
>
> On Mon, Oct 5, 2020 at 10:39 PM Catalin Marinas
> wrote:
>> On Sat, Sep 12, 2020 at 06:44:29AM -0500, John Donnelly wrote:
>>> On 9/7/20 8:47 AM, Chen Zhou wrote:
Chen Zhou (9):
x86: kdump: move
On Mon, Oct 5, 2020 at 6:29 PM Alexandre Belloni
wrote:
>
> On 05/10/2020 09:13:08-0400, Peter Geis wrote:
> > Good Morning,
> >
> > While testing suspend to ram on the Ouya, I encountered an interesting
> > issue with the rtc-tps65910 driver.
> > Attempting to use rtc-wake on the default
On Sat, Oct 3, 2020 at 4:29 AM Jiri Olsa wrote:
>
> On Fri, Oct 02, 2020 at 10:34:51AM -0700, Ian Rogers wrote:
>
> SNIP
>
> > > > +
> > > > LIBJVMTI = libperf-jvmti.so
> > > >
> > > > ifndef NO_JVMTI
> > > > @@ -756,6 +763,13 @@ $(OUTPUT)perf-read-vdsox32: perf-read-vdso.c
> > > >
On 2020/10/6 1:12, Catalin Marinas wrote:
> On Mon, Sep 07, 2020 at 09:47:43PM +0800, Chen Zhou wrote:
>> diff --git a/kernel/crash_core.c b/kernel/crash_core.c
>> index 3f735cb37ace..d11d597a470d 100644
>> --- a/kernel/crash_core.c
>> +++ b/kernel/crash_core.c
>> @@ -378,6 +378,15 @@ int
On 2020/10/6 1:16, Catalin Marinas wrote:
> On Mon, Sep 07, 2020 at 09:47:42PM +0800, Chen Zhou wrote:
>> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
>> index 53acbeca4f57..1b24072f2bae 100644
>> --- a/arch/arm64/kernel/setup.c
>> +++ b/arch/arm64/kernel/setup.c
>> @@
Hi Jiri,
On Mon, Oct 5, 2020 at 4:52 AM Jiri Olsa wrote:
>
> On Fri, Oct 02, 2020 at 10:03:17PM +0900, Namhyung Kim wrote:
> > Currently perf inject just repipes the event without any flush. It
> > makes an issue that it changes the order of events processed.
> >
> > Normally we want to process
Hello,
On Fri, Oct 2, 2020 at 12:02 PM Song Bao Hua (Barry Song)
wrote:
>
>
>
> > -Original Message-
> > From: Andi Kleen [mailto:a...@linux.intel.com]
> > Sent: Friday, October 2, 2020 12:07 PM
> > To: Song Bao Hua (Barry Song)
> > Cc: linux-kernel@vger.kernel.org; Linuxarm ; Peter
> >
On Mon, Oct 05, 2020 at 11:19:02PM +, Harley A.W. Lorenzo wrote:
> On Monday, October 5, 2020 5:31 PM, Sudip Mukherjee
> wrote:
>
> > find_tt() can return NULL or the error value in ERR_PTR() and
> > dereferencing the return value without checking for the error can
> > lead to a possible
On Mon, Oct 05, 2020 at 05:38:22PM -0600, Shuah Khan wrote:
> On 10/5/20 9:25 AM, Alan Stern wrote:
> > On Mon, Oct 05, 2020 at 05:21:30PM +0200, Andrey Konovalov wrote:
> > No, no -- it won't work right if it's called in process context. Not
> > only do the spinlock calls leave the interrupt
On Fri, Oct 02, 2020 at 08:27:41PM -0700, Randy Dunlap wrote:
> On 10/2/20 6:17 PM, Ricardo Neri wrote:
> > +/**
> > + * arch_get_cpu_type() - Get the CPU type number
> > + * @cpu: Index of the CPU of which the index is needed
> > + *
> > + * Get the CPU type number of @cpu, a non-zero unsigned
On Mon, Oct 05, 2020 at 12:56:38PM +0200, Thierry Reding wrote:
> On Mon, Oct 05, 2020 at 11:41:08AM +0300, Dmitry Osipenko wrote:
> > 05.10.2020 00:57, Nicolin Chen пишет:
> > > On Sat, Oct 03, 2020 at 05:06:42PM +0300, Dmitry Osipenko wrote:
> > >> 03.10.2020 09:59, Nicolin Chen пишет:
> > >>>
Hi Michal,
>-Original Message-
>From: Sudeep Holla
>Sent: Tuesday, October 6, 2020 4:08 AM
>To: Zulkifli, Muhammad Husaini
>Cc: Michal Simek ; Hunter, Adrian
>; ulf.hans...@linaro.org; linux-
>m...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
>ker...@vger.kernel.org;
On Mon, 5 Oct 2020, Julien Grall wrote:
> Hi Masami,
>
> On 05/10/2020 14:39, Masami Hiramatsu wrote:
> > Use per_cpu_ptr_to_phys() instead of virt_to_phys() for per-cpu
> > address conversion.
> >
> > In xen_starting_cpu(), per-cpu xen_vcpu_info address is converted
> > to gfn by virt_to_gfn()
On Mon, Oct 05, 2020 at 11:57:54AM +0200, Thierry Reding wrote:
> On Fri, Oct 02, 2020 at 11:58:29AM -0700, Nicolin Chen wrote:
> > On Fri, Oct 02, 2020 at 06:02:18PM +0300, Dmitry Osipenko wrote:
> > > 02.10.2020 09:08, Nicolin Chen пишет:
> > > > static int tegra_smmu_of_xlate(struct device
On 10/6/20 3:38 AM, Rob Herring wrote:
> In order to add meta-schema checks for additional/unevaluatedProperties
> being present, all schema need to make this explicit. As common/shared
> schema are included by other schemas, they should always allow for
> additionalProperties.
>
> Signed-off-by:
On Sat, Oct 03, 2020 at 01:05:48PM +0200, Greg Kroah-Hartman wrote:
> On Sat, Oct 03, 2020 at 10:53:45AM +0200, Greg Kroah-Hartman wrote:
> > On Fri, Oct 02, 2020 at 06:17:42PM -0700, Ricardo Neri wrote:
> > > +/**
> > > + * arch_get_cpu_type_name() - Get the CPU type name
> > > + * @cpu_type:
1 - 100 of 1486 matches
Mail list logo
