been built successfully.
More configs may be tested in the coming days.
tested configs:
alphaalldefconfig gcc
alphaallyesconfig gcc
alpha defconfig gcc
alpharandconfig-r002-20230707 g
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
fixes-test
branch HEAD: 05088041a9eef84af5386cd237d754754bb142de
powerpc/mm/book3s64/hash/4k: Add pmd_same callback for 4K page size
elapsed time: 721m
configs tested: 28
configs skipped: 116
The following configs
On 7/6/23 17:32, Palmer Dabbelt wrote:
On Thu, 06 Jul 2023 15:20:25 PDT (-0700), eric.devol...@oracle.com wrote:
The kexec and crash kernel options are provided in the common
kernel/Kconfig.kexec. Utilize the common options and provide
the ARCH_SUPPORTS_ and ARCH_SELECTS_ entries to recreate
On Wed, 2023-07-05 at 14:58 -0400, Jeff Layton wrote:
> v2:
> - prepend patches to add missing ctime updates
> - add simple_rename_timestamp helper function
> - rename ctime accessor functions as inode_get_ctime/inode_set_ctime_*
> - drop individual inode_ctime_set_{sec,nsec} helpers
>
After revi
On 7/7/23 00:58, Christophe Leroy wrote:
Le 07/07/2023 à 00:20, Eric DeVolder a écrit :
The kexec and crash kernel options are provided in the common
kernel/Kconfig.kexec. Utilize the common options and provide
the ARCH_SUPPORTS_ and ARCH_SELECTS_ entries to recreate the
equivalent set of K
On 07.07.23 18:25, Aneesh Kumar K V wrote:
On 7/7/23 9:12 PM, David Hildenbrand wrote:
On 07.07.23 15:30, Aneesh Kumar K V wrote:
On 7/7/23 5:47 PM, David Hildenbrand wrote:
On 06.07.23 18:06, Aneesh Kumar K V wrote:
On 7/6/23 6:29 PM, David Hildenbrand wrote:
On 06.07.23 14:32, Aneesh Kumar
The pull request you sent on Fri, 07 Jul 2023 23:26:06 +1000:
> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
> tags/powerpc-6.5-2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/22dcc7d77fa463914bc2a2fb4580e6d183ca415d
Thank you!
--
Deet-doot-do
On 7/7/23 9:29 PM, Tobias Huschle wrote:
> On 2023-07-07 16:33, Shrikanth Hegde wrote:
>> On 7/7/23 1:14 PM, Tobias Huschle wrote:
>>> On 2023-07-05 09:52, Vincent Guittot wrote:
Le lundi 05 juin 2023 à 10:07:16 (+0200), Tobias Huschle a écrit :
> On 2023-05-16 15:36, Vincent Guittot wr
On 7/7/23 9:12 PM, David Hildenbrand wrote:
> On 07.07.23 15:30, Aneesh Kumar K V wrote:
>> On 7/7/23 5:47 PM, David Hildenbrand wrote:
>>> On 06.07.23 18:06, Aneesh Kumar K V wrote:
On 7/6/23 6:29 PM, David Hildenbrand wrote:
> On 06.07.23 14:32, Aneesh Kumar K V wrote:
>> On 7/6/23 4
On 2023-07-07 16:33, Shrikanth Hegde wrote:
On 7/7/23 1:14 PM, Tobias Huschle wrote:
On 2023-07-05 09:52, Vincent Guittot wrote:
Le lundi 05 juin 2023 à 10:07:16 (+0200), Tobias Huschle a écrit :
On 2023-05-16 15:36, Vincent Guittot wrote:
> On Mon, 15 May 2023 at 13:46, Tobias Huschle
> wrot
On 07.07.23 15:30, Aneesh Kumar K V wrote:
On 7/7/23 5:47 PM, David Hildenbrand wrote:
On 06.07.23 18:06, Aneesh Kumar K V wrote:
On 7/6/23 6:29 PM, David Hildenbrand wrote:
On 06.07.23 14:32, Aneesh Kumar K V wrote:
On 7/6/23 4:44 PM, David Hildenbrand wrote:
On 06.07.23 11:36, Aneesh Kumar
"Arnd Bergmann" writes:
> On Fri, Jul 7, 2023, at 15:40, Javier Martinez Canillas wrote:
[...]
>> And this is only used by mdacon (not supported by ia64), vgacon and
>> vga16fb (not supported by ia64 either).
>>
>> So this could just be guarded just by CONFIG_VGA_CONSOLE for ia64 ?
>
> Right, I
On Wed, 5 Jul 2023 17:52:40 -0700 (PDT)
Hugh Dickins wrote:
> On Wed, 5 Jul 2023, Alexander Gordeev wrote:
> > On Sat, Jul 01, 2023 at 09:32:38PM -0700, Hugh Dickins wrote:
> > > On Thu, 29 Jun 2023, Hugh Dickins wrote:
> >
> > Hi Hugh,
> >
> > ...
> >
> > > +#ifdef CONFIG_TRANSPARENT_HU
On 7/7/23 1:14 PM, Tobias Huschle wrote:
> On 2023-07-05 09:52, Vincent Guittot wrote:
>> Le lundi 05 juin 2023 à 10:07:16 (+0200), Tobias Huschle a écrit :
>>> On 2023-05-16 15:36, Vincent Guittot wrote:
>>> > On Mon, 15 May 2023 at 13:46, Tobias Huschle
>>> > wrote:
>>> > >
>>> > > The curren
On Fri, Jul 7, 2023, at 15:40, Javier Martinez Canillas wrote:
>> diff --git a/arch/ia64/kernel/setup.c b/arch/ia64/kernel/setup.c
>> index 5a55ac82c13a4..0c09ff7fde46b 100644
>> --- a/arch/ia64/kernel/setup.c
>> +++ b/arch/ia64/kernel/setup.c
>> @@ -86,9 +86,11 @@ EXPORT_SYMBOL(local_per_cpu_offse
On 7/7/23 5:47 PM, David Hildenbrand wrote:
> On 06.07.23 18:06, Aneesh Kumar K V wrote:
>> On 7/6/23 6:29 PM, David Hildenbrand wrote:
>>> On 06.07.23 14:32, Aneesh Kumar K V wrote:
On 7/6/23 4:44 PM, David Hildenbrand wrote:
> On 06.07.23 11:36, Aneesh Kumar K V wrote:
>> On 7/6/23 2
Arnd Bergmann writes:
> From: Arnd Bergmann
>
> On non-x86 architectures, the screen_info variable is generally only
> used for the VGA console where supported, and in some cases the EFI
> framebuffer or vga16fb.
>
> Now that we have a definite list of which architectures actually use it
> for w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi Linus,
Please pull a few powerpc fixes for 6.5:
The following changes since commit d8b0bd57c2d68eb500f356f0f9228e6183da94ae:
Merge tag 'powerpc-6.5-1' of
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux (2023-06-30
09:20:08 -0700
On 06.07.23 18:06, Aneesh Kumar K V wrote:
On 7/6/23 6:29 PM, David Hildenbrand wrote:
On 06.07.23 14:32, Aneesh Kumar K V wrote:
On 7/6/23 4:44 PM, David Hildenbrand wrote:
On 06.07.23 11:36, Aneesh Kumar K V wrote:
On 7/6/23 2:48 PM, David Hildenbrand wrote:
On 06.07.23 10:50, Aneesh Kumar
On Thu, 2023-07-06 at 21:02 +, Seth Arnold wrote:
> On Wed, Jul 05, 2023 at 08:04:41PM -0400, Jeff Layton wrote:
> >
> > I don't believe it's an issue. I've seen nothing in the POSIX spec that
> > mandates that timestamp updates to different inodes involved in an
> > operation be set to the _s
Le 07/07/2023 à 00:20, Eric DeVolder a écrit :
> The kexec and crash kernel options are provided in the common
> kernel/Kconfig.kexec. Utilize the common options and provide
> the ARCH_SUPPORTS_ and ARCH_SELECTS_ entries to recreate the
> equivalent set of KEXEC and CRASH options.
Why do you ne
Hi Mark
On Tue, Jul 4, 2023 at 12:03 PM Shengjiu Wang
wrote:
>
>
> On Tue, Jul 4, 2023 at 1:59 AM Mark Brown wrote:
>
>> On Mon, Jul 03, 2023 at 03:12:55PM +0200, Hans Verkuil wrote:
>>
>> > My main concern is that these cross-subsystem drivers are a pain to
>> > maintain. So there have to be g
From: Arnd Bergmann
On non-x86 architectures, the screen_info variable is generally only
used for the VGA console where supported, and in some cases the EFI
framebuffer or vga16fb.
Now that we have a definite list of which architectures actually use it
for what, use consistent #ifdef checks so t
On Fri, Jul 7, 2023, at 11:50, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> On non-x86 architectures, the screen_info variable is generally only
> used for the VGA console where supported, and in some cases the EFI
> framebuffer or vga16fb.
>
This should have been patch 2/4, not 1/3, please ign
From: Arnd Bergmann
On non-x86 architectures, the screen_info variable is generally only
used for the VGA console where supported, and in some cases the EFI
framebuffer or vga16fb.
Now that we have a definite list of which architectures actually use it
for what, use consistent #ifdef checks so t
On Thu 06-07-23 08:34:05, Thomas Weißschuh wrote:
> On 2023-07-06 11:41:38+0530, Sachin Sant wrote:
> > While running LTP tests (madvise06) on IBM Power9 LPAR booted with
> > 6.4.0-next-20230705 following crash is seen
> >
> > Injecting memory failure for pfn 0x3f79 at process virtual address
> >
On 2023-07-06 19:19, Shrikanth Hegde wrote:
On 5/15/23 5:16 PM, Tobias Huschle wrote:
The current load balancer implementation implies that scheduler
groups,
within the same domain, all host the same number of CPUs. This is
reflected in the condition, that a scheduler group, which is load
balan
On 2023-07-04 15:40, Peter Zijlstra wrote:
On Mon, May 15, 2023 at 01:46:01PM +0200, Tobias Huschle wrote:
The current load balancer implementation implies that scheduler
groups,
within the same domain, all host the same number of CPUs. This is
reflected in the condition, that a scheduler group
On 2023-07-05 09:52, Vincent Guittot wrote:
Le lundi 05 juin 2023 à 10:07:16 (+0200), Tobias Huschle a écrit :
On 2023-05-16 15:36, Vincent Guittot wrote:
> On Mon, 15 May 2023 at 13:46, Tobias Huschle
> wrote:
> >
> > The current load balancer implementation implies that scheduler
> > groups,
Secondary TLBs are now invalidated from the architecture specific TLB
invalidation functions. Therefore there is no need to explicitly
notify or invalidate as part of the range end functions. This means we
can remove mmu_notifier_invalidate_range_end_only() and some of the
ptep_*_notify() functions
The arch_invalidate_secondary_tlbs() is a architecture specific mmu
notifier use to keep the TLB of secondary MMUs such as an IOMMU in
sync with the CPU page tables. Currently it is called from separate
code paths to the main CPU TLB invalidations. This can lead to a
secondary TLB not getting inval
There are two main use cases for mmu notifiers. One is by KVM which
uses mmu_notifier_invalidate_range_start()/end() to manage a software
TLB.
The other is to manage hardware TLBs which need to use the
invalidate_range() callback because HW can establish new TLB entries
at any time. Hence using st
This is a follow up to the initial RFC posted here -
https://lore.kernel.org/linux-mm/cover.063f3dc2100ae7cbe3a6527689589646ea787216.1687259597.git-series.apop...@nvidia.com/
The main change is to move secondary TLB invalidation mmu notifier
callbacks into the architecture specific TLB flushing fu
33 matches
Mail list logo
