: 7e25f40eab52c57ff6772d27d2aef3640a3237d7
config: powerpc-randconfig-c004-20210416 (attached as .config)
compiler: powerpc-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
Hi "David,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on 823b31517ad3196324322804ee365d5fcff704d6]
url:
https://github.com/0day-ci/linux/commits/David-E-Box/intel_pmc_core-Add-sub-state-requirements-and-mode/20210417-111530
base:
On Tue, 13 Apr 2021 07:43:17 +0900
Naoya Horiguchi wrote:
> Hi,
>
> I wrote this patchset to materialize what I think is the current
> allowable solution mentioned by the previous discussion [1].
> I simply borrowed Tony's mutex patch and Aili's return code patch,
> then I queued another one to
On 14/04/2021 07:52, Matti Vaittinen wrote:
> Thermal core contains a logic for safety shutdown. System is attempted to
> be powered off if temperature exceeds safety limits.
>
> Currently this can be also utilized by regulator subsystem as a final
> protection measure if PMICs report dangerous
randconfig-a003-20210416
i386 randconfig-a006-20210416
i386 randconfig-a001-20210416
i386 randconfig-a005-20210416
i386 randconfig-a004-20210416
i386 randconfig-a002-20210416
x86_64 randconfig-a014-20210416
Hi Luiz,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.12-rc7 next-20210416]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base
On Fri, Apr 16, 2021 at 4:24 AM Peter Zijlstra wrote:
> Simlar thing for RCU; C11 can't optimally do that; it needs to make
> rcu_dereference() a load-acquire [something ARM64 has already done in C
> because the compiler might be too clever by half when doing LTO :-(].
> But it's the compiler
The following changes since commit 4e04e7513b0fa2fe8966a1c83fb473f1667e2810:
Merge tag 'net-5.12-rc7' of
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net (2021-04-09 15:26:51
-0700)
are available in the Git repository at:
On Sat, Apr 17, 2021 at 12:45 AM 赵亚 wrote:
>
> On Fri, Apr 16, 2021 at 7:52 PM Eric Dumazet wrote:
> >
> > On Fri, Apr 16, 2021 at 12:52 PM zhaoya wrote:
> > >
> > > When syncookie is triggered, since $MSSID is spliced into cookie and
> > > the legal index of msstab is 0,1,2,3, this gives
On 14/04/2021 07:52, Matti Vaittinen wrote:
> Thermal core contains a logic for safety shutdown. System is attempted to
> be powered off if temperature exceeds safety limits.
>
> Currently this can be also utilized by regulator subsystem as a final
> protection measure if PMICs report dangerous
On 17/4/21 11:10 am, Damien Le Moal wrote:
uclibc/gcc combined with elf2flt riscv linker file fully resolve the
PC relative __global_pointer$ value at compile time and do not generate
a relocation entry to set a correct value of the gp register at runtime.
As a result, if the flatbin loader
On 2021/04/17 13:52, Greg Ungerer wrote:
>
> On 17/4/21 11:10 am, Damien Le Moal wrote:
>> Commit 2217b9826246 ("binfmt_flat: revert "binfmt_flat: don't offset
>> the data start"") restored offsetting the start of the data section by
>> a number of words defined by MAX_SHARED_LIBS. As a result,
On Sat, Apr 17, 2021 at 2:08 AM Xie He wrote:
>
> When an skb is allocated by "__netdev_alloc_skb" in "net/core/skbuff.c",
> if "sk_memalloc_socks()" is true, and if there's not sufficient memory,
> the skb would be allocated using emergency memory reserves. This kind of
> skbs are called
On 17/4/21 11:10 am, Damien Le Moal wrote:
Commit 2217b9826246 ("binfmt_flat: revert "binfmt_flat: don't offset
the data start"") restored offsetting the start of the data section by
a number of words defined by MAX_SHARED_LIBS. As a result, since
MAX_SHARED_LIBS is never 0, a gap between the
From: Guo Ren
The linux/atomic-arch-fallback.h has been there for a while, but
only x86 & arm64 support it. Let's make riscv follow the
linux/arch/* development trendy and make the codes more readable
and maintainable.
This patch also cleanup some codes:
- Add atomic_andnot_* operation
-
From: Guo Ren
Current GENERIC_ATOMIC64 in atomic-arch-fallback.h is broken. When a 32-bit
arch use atomic-arch-fallback.h will cause compile error.
In file included from include/linux/atomic.h:81,
from include/linux/rcupdate.h:25,
from
On Sat, Apr 17, 2021 at 2:31 AM David Ahern wrote:
>
> [ cc author of 648700f76b03b7e8149d13cc2bdb3355035258a9 ]
I think this has been discussed already. There is no strategy that
makes IP reassembly units immune to DDOS attacks.
We added rb-tree and sysctls to let admins choose to use GB of
The css_set_lock is used to guard the list of inherited objcgs. So there
is no need to uncharge kernel memory under css_set_lock. Just move it
out of the lock.
Signed-off-by: Muchun Song
Reviewed-by: Shakeel Butt
Acked-by: Roman Gushchin
Acked-by: Johannes Weiner
---
mm/memcontrol.c | 3 ++-
The noinline_for_stack is introduced by commit 666356297ec4 ("vmscan:
set up pagevec as late as possible in shrink_inactive_list()"), its
purpose is to delay the allocation of pagevec as late as possible to
save stack memory. But the commit 2bcf88796381 ("mm: take pagevecs off
reclaim stack")
All the callers of mem_cgroup_page_lruvec() just pass page_pgdat(page)
as the 2nd parameter to it (except isolate_migratepages_block()). But
for isolate_migratepages_block(), the page_pgdat(page) is also equal
to the local variable of @pgdat. So mem_cgroup_page_lruvec() do not
need the pgdat
The obj_cgroup_release() and memcg_reparent_objcgs() are serialized by
the css_set_lock. We do not need to care about objcg->memcg being
released in the process of obj_cgroup_release(). So there is no need
to pin memcg before releasing objcg. Remove those pinning logic to
simplfy the code.
There
We already have a helper lruvec_memcg() to get the memcg from lruvec, we
do not need to do it ourselves in the lruvec_holds_page_lru_lock(). So use
lruvec_memcg() instead. And if mem_cgroup_disabled() returns false, the
page_memcg(page) (the LRU pages) cannot be NULL. So remove the odd logic
of
lruvec_holds_page_lru_lock() doesn't check anything about locking and is
used to check whether the page belongs to the lruvec. So rename it to
page_matches_lruvec().
Signed-off-by: Muchun Song
Acked-by: Michal Hocko
Acked-by: Johannes Weiner
Reviewed-by: Shakeel Butt
---
The pages aren't accounted at the root level, so do not charge the page
to the root memcg in page replacement. Although we do not display the
value (mem_cgroup_usage) so there shouldn't be any actual problem, but
there is a WARN_ON_ONCE in the page_counter_cancel(). Who knows if it
will trigger?
When mm is NULL, we do not need to hold rcu lock and call css_tryget for
the root memcg. And we also do not need to check !mm in every loop of
while. So bail out early when !mm.
Signed-off-by: Muchun Song
Acked-by: Johannes Weiner
Reviewed-by: Shakeel Butt
Acked-by: Roman Gushchin
Acked-by:
This patch series is part of [1] patch series. Because those patches are
code cleanup or simplification. I gather those patches into a separate
series to make it easier to review.
[1]
https://lore.kernel.org/linux-mm/20210409122959.82264-1-songmuc...@bytedance.com/
Changlogs in v3:
1. Collect
On Mon, 5 Apr 2021, Collin Fijalkovich wrote:
> Transparent huge pages are supported for read-only non-shmem files,
> but are only used for vmas with VM_DENYWRITE. This condition ensures that
> file THPs are protected from writes while an application is running
> (ETXTBSY). Any existing file
On Sat, Apr 17, 2021 at 01:46:35AM +0200, Miguel Ojeda wrote:
> On Sat, Apr 17, 2021 at 12:04 AM Willy Tarreau wrote:
> >
> > But my point remains that the point of extreme care is at the interface
> > with the rest of the kernel because there is a change of semantics
> > there.
> >
> > Sure but
Hi Matt,
> Like patch 1/6, I can apply it in MPTCP tree and send it later to
> net-next with other patches.
> Except if you guys prefer to apply it in KUnit tree and send it to
> linux-next?
Given 1/6 is going to net-next, it makes sense to send this out that
way too, then, IMHO.
The only slight
On Fri, Apr 16, 2021 at 08:42:49PM -0700, rentao.b...@gmail.com wrote:
> From: Tao Ren
>
> Fix hardware timeout calculation in aspeed_wdt_set_timeout function to
> ensure the reload value does not exceed the hardware limit.
>
> Fixes: efa859f7d786 ("watchdog: Add Aspeed watchdog driver")
>
-20210416 (attached as .config)
compiler: hppa64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://git.kernel.org/pub/scm/linux/kernel/git
On Sat, Apr 17, 2021 at 2:04 AM Daniel Latypov wrote:
>
> Add basic test coverage for files that don't require any config options:
> * part of math.h (what seem to be the most commonly used macros)
> * gcd.c
> * lcm.c
> * int_sqrt.c
> * reciprocal_div.c
> (Ignored int_pow.c since it's a simple
On Sat, Apr 17, 2021 at 7:56 AM Mike Kravetz wrote:
>
> On 4/15/21 1:40 AM, Muchun Song wrote:
> > In the subsequent patch, we should allocate the vmemmap pages when
> > freeing a HugeTLB page. But update_and_free_page() can be called
> > under any context, so we cannot use GFP_KERNEL to allocate
Abandoned, it has duplicated definition export in gen-atomic-instrumented.sh
On Sat, Apr 17, 2021 at 10:57 AM wrote:
>
> From: Guo Ren
>
> Current GENERIC_ATOMIC64 in atomic-arch-fallback.h is broken. When a 32-bit
> arch use atomic-arch-fallback.h will cause compile error.
>
> In file included
allnoconfig
i386 randconfig-a003-20210416
i386 randconfig-a006-20210416
i386 randconfig-a001-20210416
i386 randconfig-a005-20210416
i386 randconfig-a004-20210416
i386 randconfig-a002
The kunit_tool documentation page was pretty minimal, and a bit
outdated. Update it and flesh it out a bit.
In particular,
- Mention that .kunitconfig is now in the build directory
- Describe the use of --kunitconfig to specify a different config
framgent
- Mention the split functionality
On 2021/1/6 11:32, Dongseok Yi wrote:
> On 2021-01-06 12:07, Willem de Bruijn wrote:
>>
>> On Tue, Jan 5, 2021 at 8:29 PM Dongseok Yi wrote:
>>>
>>> On 2021-01-05 06:03, Willem de Bruijn wrote:
On Mon, Jan 4, 2021 at 4:00 AM Dongseok Yi wrote:
>
> skbs in frag_list could be
From: Tao Ren
Fix hardware timeout calculation in aspeed_wdt_set_timeout function to
ensure the reload value does not exceed the hardware limit.
Fixes: efa859f7d786 ("watchdog: Add Aspeed watchdog driver")
Reported-by: Amithash Prasad
Signed-off-by: Tao Ren
---
drivers/watchdog/aspeed_wdt.c
Hi Linus, please pull from:
...to receive a handful of libnvdimm fixups.
The largest change is for a regression that landed during -rc1 for
block-device read-only handling. Vaibhav found a new use for the
ability (originally introduced by virtio_pmem) to call back to the
platform to flush data,
On 2021/04/15 0:39, Andrey Konovalov wrote:
> On Wed, Apr 14, 2021 at 7:45 AM Dmitry Vyukov wrote:
>> The reproducer connects some USB HID device and communicates with the driver.
>> Previously we observed reboots because HID devices can trigger reboot
>> SYSRQ, but we disable it with
On Fri, Apr 16, 2021 at 07:08:23PM +0200, Jesper Dangaard Brouer wrote:
> On Fri, 16 Apr 2021 16:27:55 +0100
> Matthew Wilcox wrote:
>
> > On Thu, Apr 15, 2021 at 08:08:32PM +0200, Jesper Dangaard Brouer wrote:
> > > See below patch. Where I swap32 the dma address to satisfy
> > >
The intel_pmc_core driver did not always bind to a device which meant it
lacked a struct device that could be used to maintain driver data. So a
global instance of struct pmc_dev was used for this purpose and functions
accessed this directly. Since the driver now binds to an ACPI device,
remove
From: Gayatri Kammela
The current implementation of pmc_core_substate_res_show() is written
specifically for Tiger Lake. However, new platform will also have
sub-states and may support different modes. Therefore rewrite the code to
handle sub-states generically.
Obtain the number and type of
By default the Low Power Mode (LPM or sub-state) status registers will
latch condition status on every entry into Package C10. This is
configurable in the PMC to allow latching on any achievable sub-state. Add
a debugfs file to support this.
Also add the option to clear the status registers to 0.
From: Gayatri Kammela
Platforms that support low power modes (LPM) such as Tiger Lake maintain
requirements for each sub-state that a readable in the PMC. However, unlike
LPM status registers, requirement registers are not memory mapped but are
available from an ACPI _DSM. Collect the
From: Gayatri Kammela
Add the debugfs file, substate_requirements, to view the low power mode
(LPM) requirements for each enabled mode alongside the last latched status
of the condition.
After this patch, the new file will look like this:
Element |S0i2.0 |S0i3.0 |
Alder PCH-P is based on Tiger Lake PCH.
Signed-off-by: David E. Box
Reviewed-by: Hans de Goede
Acked-by: Rajneesh Bhardwaj
---
V2: No change
drivers/platform/x86/intel_pmc_core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/platform/x86/intel_pmc_core.c
From: Gayatri Kammela
Just like Ice Lake, Tiger Lake uses Cannon Lake's LTR information
and supports a few additional registers. Hence add the LTR registers
specific to Tiger Lake to the cnp_ltr_show_map[].
Also adjust the number of LTR IPs for Tiger Lake to the correct amount.
Signed-off-by:
From: Gayatri Kammela
Modify the low power mode (LPM or sub-state) residency counters to display
in microseconds just like the slp_s0_residency counter. The granularity of
the counter is approximately 30.5us per tick. Double this value then divide
by two to maintain accuracy.
Signed-off-by:
The DMI callbacks, used for quirks, currently access the PMC by getting
the address a global pmc_dev struct. Instead, have the callbacks set a
global quirk specific variable. In probe, after calling dmi_check_system(),
pass pmc_dev to a function that will handle each quirk if its variable
- Patch 1 and 2 remove the use of the global struct pmc_dev
- Patches 3-7 add support for reading low power mode sub-state
requirements, latching sub-state status on different low power mode
events, and displaying the sub-state residency in microseconds
- Patch 8 adds missing LTR IPs for TGL
-
On 2021/4/16 23:20, Alan Stern wrote:
> On Fri, Apr 16, 2021 at 10:03:21AM +0800, liulongfang wrote:
>> On 2021/4/15 22:43, Alan Stern wrote:
>>> On Thu, Apr 15, 2021 at 08:22:38PM +0800, Longfang Liu wrote:
When the number of ports on the USB hub is 0, skip the registration
operation of
Hi Linus, please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/cxl/cxl
tags/cxl-fixes-for-5.12-rc8
...to receive a collection of fixes for the CXL memory class driver
introduced in v5.12-rc1.
The driver was primarily developed on a work-in-progress QEMU
emulation of the interface
On Sat, Apr 17, 2021 at 12:08 AM Peter Enderborg
wrote:
>
> This adds a total used dma-buf memory. Details
> can be found in debugfs, however it is not for everyone
> and not always available. dma-buf are indirect allocated by
> userspace. So with this value we can monitor and detect
> userspace
From: Guo Ren
The linux/atomic-arch-fallback.h has been there for a while, but
only x86 & arm64 support it. Let's make riscv follow the
linux/arch/* development trendy and make the codes more readable
and maintainable.
This patch also cleanup some codes:
- Add atomic_andnot_* operation
-
From: Guo Ren
Current GENERIC_ATOMIC64 in atomic-arch-fallback.h is broken. When a 32-bit
arch use atomic-arch-fallback.h will cause compile error.
In file included from include/linux/atomic.h:81,
from include/linux/rcupdate.h:25,
from
On Sat, Apr 17, 2021 at 5:10 AM Mike Kravetz wrote:
>
> On 4/15/21 1:40 AM, Muchun Song wrote:
> > Every HugeTLB has more than one struct page structure. We __know__ that
> > we only use the first 4 (__NR_USED_SUBPAGE) struct page structures
> > to store metadata associated with each HugeTLB.
> >
On Fri, Apr 16, 2021 at 11:20 PM Johannes Weiner wrote:
>
> On Fri, Apr 16, 2021 at 01:14:04PM +0800, Muchun Song wrote:
> > lruvec_holds_page_lru_lock() doesn't check anything about locking and is
> > used to check whether the page belongs to the lruvec. So rename it to
> >
On Thu, Apr 15, 2021 at 03:00:36PM -0600, Jonathan Corbet wrote:
> Wu XiangCheng writes:
>
> > Hi all,
> >
> > This set of patches aim to add a new translation tool - trslt.py, which
> > can control the transltions version corresponding to source files.
> >
> > For a long time, kernel
Replacement patch to fix compiler warning.
From: "Matthew Wilcox (Oracle)"
Date: Fri, 16 Apr 2021 16:34:55 -0400
Subject: [PATCH 1/2] mm: Fix struct page layout on 32-bit systems
To: bro...@redhat.com
Cc: linux-kernel@vger.kernel.org,
linux...@kvack.org,
net...@vger.kernel.org,
Excerpts from Andrew Morton's message of April 16, 2021 4:55 am:
> On Thu, 15 Apr 2021 12:23:55 +0200 Christophe Leroy
> wrote:
>> > + * is done. STRICT_MODULE_RWX may require extra work to support this
>> > + * too.
>> > + */
>> >
>> > - return __vmalloc_node_range(size, 1,
The function patch_insn_write() expects that the text_mutex is already
held. There's a case that text_mutex is acquired by ftrace_run_update_code()
under syscall context but then patch_insn_write() will be executed under the
migration kthread context as we involves stop machine. So we should
On Fri, Apr 16, 2021 at 04:34:53PM -0500, Serge E. Hallyn wrote:
> On Fri, Apr 16, 2021 at 05:05:01PM +0200, Christian Brauner wrote:
> > On Thu, Apr 15, 2021 at 11:58:51PM -0500, Serge Hallyn wrote:
> > > (Eric - this patch (v3) is a cleaned up version of the previous approach.
> > > v4 is at
>
: arm64-randconfig-r034-20210416 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project
f549176ad976caa3e19edd036df9a7e12770af7c)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin
Hello Marc,
在 2021/4/16 22:15, Marc Zyngier 写道:
[+ Mark]
On Fri, 16 Apr 2021 07:22:17 +0100,
He Ying wrote:
We found this problem in our kernel src tree:
[ 14.816231] [ cut here ]
[ 14.816231] kernel BUG at irq.c:99!
[ 14.816232] Internal error: Oops - BUG: 0
On Fri, Apr 16, 2021 at 6:14 PM Andy Lutomirski wrote:
> My point is that every ...
I encourage you to continue to question everything and trust nobody.
While it may cost you a lot in counseling, it is certainly valuable,
at least to me! :-)
I do request, however, that feedback stay specific,
On Thu, Apr 15, 2021 at 4:52 PM Peter Zijlstra wrote:
>
> On Thu, Apr 15, 2021 at 07:39:22AM +, guo...@kernel.org wrote:
> > - Add atomic_andnot_* operation
>
> > @@ -76,6 +59,12 @@ ATOMIC_OPS(sub, add, -i)
> > ATOMIC_OPS(and, and, i)
> > ATOMIC_OPS( or, or, i)
> > ATOMIC_OPS(xor, xor,
: arm64-randconfig-r022-20210416 (attached as .config)
compiler: aarch64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day
M5Stack are releasing a new widget based on the
SigmaStar SSD202D. We have some support for the
SSD202D so lets add a dts for it.
Link: https://m5stack-store.myshopify.com/products/unitv2-ai-camera-gc2145
Signed-off-by: Daniel Palmer
---
arch/arm/boot/dts/Makefile| 1 +
Add a compatible for the M5Stack UnitV2 that is based on the
SigmaStar SSD202D (inifinity2m).
Signed-off-by: Daniel Palmer
---
Documentation/devicetree/bindings/arm/mstar/mstar.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/mstar/mstar.yaml
On 2021/4/16 23:24, Joerg Roedel wrote:
> On Fri, Mar 26, 2021 at 02:24:04PM +0800, Zhen Lei wrote:
>> This detection and correction covers the entire driver/iommu directory.
>>
>> Zhen Lei (8):
>> iommu/pamu: fix a couple of spelling mistakes
>> iommu/omap: Fix spelling mistake
This series adds basic support for the soon to be released M5Stack
UnitV2 based on the SigmaStar SSD202D.
With the rest of the commits in my tree the SPI NAND, ethernet, USB etc
should work so the UnitV2 should be fully usable with a mainline-ish
kernel.
Hopefully this will encourage someone
M5Stack make various modules for STEM, Makers, IoT.
Their UnitV2 is based on a SigmaStar SSD202D SoC which
we already have some minimal support for so add a
prefix in preparation for UnitV2 board support.
Link: https://m5stack.com/
Signed-off-by: Daniel Palmer
---
On 2021/4/16 23:55, John Garry wrote:
> On 26/03/2021 06:24, Zhen Lei wrote:
>> There are several spelling mistakes, as follows:
>> funcions ==> functions
>> distiguish ==> distinguish
>> detroyed ==> destroyed
>>
>> Signed-off-by: Zhen Lei
>
> I think that there should be a
Commit 2217b9826246 ("binfmt_flat: revert "binfmt_flat: don't offset
the data start"") restored offsetting the start of the data section by
a number of words defined by MAX_SHARED_LIBS. As a result, since
MAX_SHARED_LIBS is never 0, a gap between the text and data sections
always exists. For
uclibc/gcc combined with elf2flt riscv linker file fully resolve the
PC relative __global_pointer$ value at compile time and do not generate
a relocation entry to set a correct value of the gp register at runtime.
As a result, if the flatbin loader offsets the start of the data
section, the
RISC-V NOMMU flat binaries cannot tolerate a gap between the text and
data section as the toolchain fully resolves at compile time the PC
relative global pointer (__global_pointer$ value loaded in the gp
register). Without a relocation entry provided, the flat bin loader
cannot fix the value if a
Hi "Matthew,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linux/master]
[also build test WARNING on linus/master v5.12-rc7]
[cannot apply to hnaz-linux-mm/master next-20210416]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And
Hi Marc,
On 2021/4/16 22:44, Marc Zyngier wrote:
> On Thu, 15 Apr 2021 15:08:09 +0100,
> Keqian Zhu wrote:
>>
>> Hi Marc,
>>
>> On 2021/4/15 22:03, Keqian Zhu wrote:
>>> The MMIO region of a device maybe huge (GB level), try to use
>>> block mapping in stage2 to speedup both map and unmap.
>>>
On 2021/4/15 22:47, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 5.10.31 release.
There are 25 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.
Responses should be
On Fri, 16 Apr 2021 at 03:41, Michael Ellerman wrote:
>
> Tony Ambardar writes:
> > Hello Michael,
> >
> > The latest version of this patch addressed all feedback I'm aware of
> > when submitted last September, and I've seen no further comments from
> > reviewers since then.
> >
> > Could you
On 2021/4/15 22:46, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.14.231 release.
There are 68 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.
Responses should be
On Fri, 2021-04-16 at 17:43 -0700, Dan Williams wrote:
> The CXL Identify Memory Device output payload emits capacity in 256MB
> units. The driver is treating the capacity field as bytes. This was
> missed because QEMU reports bytes when it should report bytes / 256MB.
>
> Fixes: 8adaf747c9f0
|-- alpha-randconfig-r013-20210416
| |--
arch-alpha-include-asm-string.h:warning:__builtin_memcpy-offset-from-the-object-at-alloc-is-out-of-the-bounds-of-referenced-subobject-key-with-type-struct-bkey-at-offset
| `--
arch-alpha-include-asm-string.h:warning:__builtin_memcpy-offset-from-the-object
The CXL Identify Memory Device output payload emits capacity in 256MB
units. The driver is treating the capacity field as bytes. This was
missed because QEMU reports bytes when it should report bytes / 256MB.
Fixes: 8adaf747c9f0 ("cxl/mem: Find device capabilities")
Cc: Ben Widawsky
From: Joseph Salisbury
There is not a consistent pattern for checking Hyper-V hypercall status.
Existing code uses a number of variants. The variants work, but a consistent
pattern would improve the readability of the code, and be more conformant
to what the Hyper-V TLFS says about hypercall
From: Joseph Salisbury
This patch makes no functional changes. It simply moves hv_do_rep_hypercall()
out of arch/x86/include/asm/mshyperv.h and into asm-generic/mshyperv.h
hv_do_rep_hypercall() is architecture independent, so it makes sense that it
should be in the architecture independent
On Mon, 12 Apr 2021, Axel Rasmussen wrote:
> In a previous commit, we added the mcopy_atomic_install_ptes() helper.
> This helper does the job of setting up PTEs for an existing page, to map
> it into a given VMA. It deals with both the anon and shmem cases, as
> well as the shared and private
[ cc author of 648700f76b03b7e8149d13cc2bdb3355035258a9 ]
On 4/16/21 3:58 PM, Keyu Man wrote:
> Hi,
>
>
>
> My name is Keyu Man. We are a group of researchers from University
> of California, Riverside. Zhiyun Qian is my advisor. We found the code
> in processing IPv4/IPv6 fragments will
On Fri, Apr 16, 2021 at 10:45:28PM +0200, Thomas Gleixner wrote:
> On Tue, Apr 13 2021 at 21:35, Paul E. McKenney wrote:
> > #define WATCHDOG_INTERVAL (HZ >> 1)
> > #define WATCHDOG_THRESHOLD (NSEC_PER_SEC >> 4)
>
> Didn't we discuss that the threshold is too big ?
Indeed we did! How about
On Fri, Apr 16 2021 at 23:37, Thomas Gleixner wrote:
> On Fri, Apr 16 2021 at 13:38, Sami Tolvanen wrote:
>> #ifdef CONFIG_STATIC_CALL_SELFTEST
>>
>> -static int func_a(int x)
>> +int func_a(int x)
>> {
>> return x+1;
>> }
>>
>> -static int func_b(int x)
>> +int func_b(int x)
>> {
>>
Userspace can initiate a freeze call using ioctls. If the kernel decides
to freeze a filesystem later it must be able to distinguish if userspace
had initiated the freeze, so that it does not unfreeze it later
automatically on resume.
Likewise if the kernel is initiating a freeze on its own it
Add support to automatically handle freezing and thawing filesystems
during the kernel's suspend/resume cycle.
This is needed so that we properly really stop IO in flight without
races after userspace has been frozen. Without this we rely on
kthread freezing and its semantics are loose and error
There are use cases where we wish to traverse the superblock list
but also capture errors, and in which case we want to avoid having
our callers issue a lock themselves since we can do the locking for
the callers. Provide a iterate_supers_excl() which calls a function
with the write lock held. If
freeze_super() holds a write lock, however we wish to also enable
callers which already hold the write lock. To do this provide a helper
and make freeze_super() use it. This way, all that freeze_super() does
now is lock handling and active count management.
This change has no functional changes.
The thaw_super_locked() expects the caller to hold the sb->s_umount
semaphore. It also handles the unlocking of the semaphore for you.
Allow for cases where the caller will do the unlocking of the semaphore.
Signed-off-by: Luis Chamberlain
---
fs/super.c | 25 +++--
1 file
The question of whether or not a superblock is frozen needs to be
augmented in the future to account for differences between a user
initiated freeze and a kernel initiated freeze done automatically
on behalf of the kernel.
Provide helpers so that these can be used instead so that we don't
have to
This picks up where I left off in 2017, I was inclined to respin this
up again due to a new issue Lukas reported which is easy to reproduce.
I posted a stop-gap patch for that issue [0] and a test case, however,
*this* is the work we want upstream to fix these sorts of issues.
As discussed long
On Fri, 2021-04-16 at 14:41 -0600, Khalid Aziz wrote:
> On 4/15/21 8:08 PM, Joe Perches wrote:
> > And while it's a lot more code, I'd prefer a solution that looks more
> > like the other commonly used kernel logging extension mechanisms
> > where adapter is placed before the format, ... in the
When an skb is allocated by "__netdev_alloc_skb" in "net/core/skbuff.c",
if "sk_memalloc_socks()" is true, and if there's not sufficient memory,
the skb would be allocated using emergency memory reserves. This kind of
skbs are called pfmemalloc skbs.
pfmemalloc skbs must be specially handled in
1 - 100 of 1309 matches
Mail list logo
