These functions are introduced in hugetlb.c so the private
hugetlb_lock can be accessed.
hugetlb_lock is reused for this PoC, but a separate lock should be
used in a future revision to avoid interference due to hash collisions
with HugeTLB's usage of this lock.
Co-developed-by: Ackerley Tng
Sign
While parsing the domains list, start offsets from 0 rather than from
domains_read. The domains_read is equal to the total count of the
domains we have seen, while the domains list in the message starts from
offset 0.
Fixes: fbe639b44a82 ("soc: qcom: Introduce Protection Domain Restart helpers")
T
On 5/11/2024 2:56 PM, Dmitry Baryshkov wrote:
While parsing the domains list, start offsets from 0 rather than from
domains_read. The domains_read is equal to the total count of the
domains we have seen, while the domains list in the message starts from
offset 0.
Fixes: fbe639b44a82 ("soc: qc
While parsing the domains list, start offsets from 0 rather than from
domains_read. The domains_read is equal to the total count of the
domains we have seen, while the domains list in the message starts from
offset 0.
Fixes: fbe639b44a82 ("soc: qcom: Introduce Protection Domain Restart helpers")
T
While parsing the domains list, start offsets from 0 rather than from
domains_read. The domains_read is equal to the total count of the
domains we have seen, while the domains list in the message starts from
offset 0.
Fixes: fbe639b44a82 ("soc: qcom: Introduce Protection Domain Restart helpers")
S
On Mon, Oct 16, 2023 at 01:41:15PM +0100, Alexandru Elisei wrote:
> On Thu, Oct 12, 2023 at 10:25:11AM +0900, Hyesoo Yu wrote:
> > I don't think it would be effcient when the majority of movable pages
> > do not use GFP_TAGGED.
> >
> > Metadata pages have a low probability of being in the pcp list
Hi,
On Thu, Oct 12, 2023 at 10:25:11AM +0900, Hyesoo Yu wrote:
> On Wed, Aug 23, 2023 at 02:13:19PM +0100, Alexandru Elisei wrote:
> > pcp lists keep MIGRATE_METADATA pages on the MIGRATE_MOVABLE list. Make
> > sure pages from the movable list are allocated only when the
> >
On Wed, Aug 23, 2023 at 02:13:19PM +0100, Alexandru Elisei wrote:
> pcp lists keep MIGRATE_METADATA pages on the MIGRATE_MOVABLE list. Make
> sure pages from the movable list are allocated only when the
> ALLOC_FROM_METADATA alloc flag is set, as otherwise the page allocator
>
c_page);
> > > encl->secs.epc_page = NULL;
> > > }
> >
> > The "record" of SECS/VA pages should be done together with this. I see
> > no
> > reason why the "record" and "drop" are separated into different p
On Wed, 27 Sep 2023 06:57:18 -0500, Huang, Kai wrote:
On Fri, 2023-09-22 at 20:06 -0700, Haitao Huang wrote:
From: Sean Christopherson
When an OOM event occurs, all pages associated with an enclave will need
to be freed, including pages that are not currently tracked by the
cgroup LRU lists
e "record" and "drop" are separated into different patches.
"record" of SECS/VA pages are done in this patch. Before nothing done in
"record" for them because no tracking LRU lists for them. Now they are
tracked.
Thanks
Haitao
> --- a/arch/x86/kernel/cpu/sgx/encl.c
> +++ b/arch/x86/kernel/cpu/sgx/encl.c
> @@ -746,6 +746,7 @@ void sgx_encl_release(struct kref *ref)
> xa_destroy(&encl->page_array);
>
> if (!encl->secs_child_cnt && encl->secs.epc_page) {
> + sgx_drop_epc_page(encl->secs.epc_page);
On Fri, 2023-09-22 at 20:06 -0700, Haitao Huang wrote:
> From: Sean Christopherson
>
> When an OOM event occurs, all pages associated with an enclave will need
> to be freed, including pages that are not currently tracked by the
> cgroup LRU lists.
What are "cgroup LRU lis
From: Sean Christopherson
When an OOM event occurs, all pages associated with an enclave will need
to be freed, including pages that are not currently tracked by the
cgroup LRU lists.
Add a new "unreclaimable" list to the sgx_epc_lru_lists struct and
update the "sgx_record
nts for the spinlock and the non-reclaimables.
(Kai, Jarkko)
- Revised the commit to add introduction comments for unreclaimables and
multiple LRU lists.(Kai)
- Reordered the patches: delay all changes for unreclaimables to
later, and this one becomes the first change in the SGX subsystem.
V3:
On Thu, 14 Sep 2023 05:31:30 -0500, Huang, Kai wrote:
Some non-technical staff:
On Tue, 2023-09-12 at 21:06 -0700, Haitao Huang wrote:
From: Kristen Carlson Accardi
The patch was from Kristen, but ...
Introduce a data structure to wrap the existing reclaimable list and its
spinlock. Eac
On Thu, 2023-09-14 at 09:13 -0700, Dave Hansen wrote:
> On 9/14/23 03:31, Huang, Kai wrote:
> > > Signed-off-by: Haitao Huang
> > > Cc: Sean Christopherson
> > You don't need 'Cc:' Sean if the patch has Sean's SoB.
>
> It is a SoB for Sean's @intel address and cc's his @google address.
>
> It i
On 9/14/23 03:31, Huang, Kai wrote:
>> Signed-off-by: Haitao Huang
>> Cc: Sean Christopherson
> You don't need 'Cc:' Sean if the patch has Sean's SoB.
It is a SoB for Sean's @intel address and cc's his @google address.
It is fine.
Some non-technical staff:
On Tue, 2023-09-12 at 21:06 -0700, Haitao Huang wrote:
> From: Kristen Carlson Accardi
The patch was from Kristen, but ...
>
> Introduce a data structure to wrap the existing reclaimable list and its
> spinlock. Each cgroup later will have one instance of this structu
On Wed Sep 13, 2023 at 7:06 AM EEST, Haitao Huang wrote:
> From: Kristen Carlson Accardi
>
> When an OOM event occurs, all pages associated with an enclave will need
> to be freed, including pages that are not currently tracked by the
> cgroup LRU lists.
>
> Add a new "
rlson Accardi
> Signed-off-by: Haitao Huang
> Cc: Sean Christopherson
> ---
> V4:
> - Removed unneeded comments for the spinlock and the non-reclaimables.
> (Kai, Jarkko)
> - Revised the commit to add introduction comments for unreclaimables and
> multiple LRU lists.(Kai)
> - Re
From: Kristen Carlson Accardi
When an OOM event occurs, all pages associated with an enclave will need
to be freed, including pages that are not currently tracked by the
cgroup LRU lists.
Add a new "unreclaimable" list to the sgx_epc_lru_lists struct and
update the "sgx_record
ed the commit to add introduction comments for unreclaimables and
multiple LRU lists.(Kai)
- Reordered the patches: delay all changes for unreclaimables to
later, and this one becomes the first change in the SGX subsystem.
V3:
- Removed the helper functions and revised commit messages.
---
arc
The per-cpu page allocator lists and the per-cpu vmstat deltas are stored
in the same struct per_cpu_pages even though vmstats have no direct impact
on the per-cpu page lists. This is inconsistent because the vmstats for a
node are stored on a dedicated structure. The bigger issue is that the
The per-cpu page allocator lists and the per-cpu vmstat deltas are stored
in the same struct per_cpu_pages even though vmstats have no direct impact
on the per-cpu page lists. This is inconsistent because the vmstats for a
node are stored on a dedicated structure. The bigger issue is that the
On Mon, Apr 12, 2021 at 07:43:18PM +0200, Vlastimil Babka wrote:
> On 4/7/21 10:24 PM, Mel Gorman wrote:
> > @@ -6691,7 +6697,7 @@ static __meminit void zone_pcp_init(struct zone *zone)
> > * relies on the ability of the linker to provide the
> > * offset of a (static) per cpu variable in
On 4/7/21 10:24 PM, Mel Gorman wrote:
> @@ -6691,7 +6697,7 @@ static __meminit void zone_pcp_init(struct zone *zone)
>* relies on the ability of the linker to provide the
>* offset of a (static) per cpu variable into the per cpu area.
>*/
> - zone->pageset = &boot_pagese
kimage
*kimage)
}
}
+int machine_kexec_post_load(struct kimage *kimage)
+{
+ void *reloc_code = page_to_virt(kimage->control_code_page);
+
+ /* If in place flush new kernel image, else flush lists and buffers */
+ if (kimage->head & IND_DONE)
+ kex
The per-cpu page allocator lists and the per-cpu vmstat deltas are stored
in the same struct per_cpu_pages even though vmstats have no direct impact
on the per-cpu page lists. This is inconsistent because the vmstats for a
node are stored on a dedicated structure. The bigger issue is that the
The per-cpu page allocator lists and the per-cpu vmstat deltas are stored
in the same struct per_cpu_pages even though vmstats have no direct impact
on the per-cpu page lists. This is inconsistent because the vmstats for a
node are stored on a dedicated structure. The bigger issue is that the
Hi!
> > I assume this is just to install a trojan horse when opening the
> > attached zip (also I assume most of you will work on linux and it
> > might not be a Problem for you anyhow ;-) .
> >
> > Virus total reports a Trojan horse, but only for with 2 out of 61
> > virus scan engines (and I
When dumping the current VMCS state, include the MSRs that are being
automatically loaded/stored during VM entry/exit.
Suggested-by: Paolo Bonzini
Signed-off-by: David Edmondson
---
arch/x86/kvm/vmx/vmx.c | 16
1 file changed, 16 insertions(+)
diff --git a/arch/x86/kvm/vmx/vmx
>>> reserved for active enclaves before the operation.
>>>
>>> The section local lists are redundant, as sgx_free_epc_page() figures
>>> out the correction by using epc_page->section.
>>
>> During normal runtime, the "ksgxd" daemon behaves
st round can fail, if all child pages have not yet been removed.
> > The driver puts all pages on startup first to sgx_dirty_page_list, as the
> > initialization could be triggered by kexec(), meaning that pages have been
> > reserved for active enclaves before the operation.
> &g
ts all pages on startup first to sgx_dirty_page_list, as the
> initialization could be triggered by kexec(), meaning that pages have been
> reserved for active enclaves before the operation.
>
> The section local lists are redundant, as sgx_free_epc_page() figures
> out the correction
initialization could be triggered by kexec(), meaning that pages have been
reserved for active enclaves before the operation.
The section local lists are redundant, as sgx_free_epc_page() figures
out the correction by using epc_page->section.
Signed-off-by: Jarkko Sakkinen
---
v4:
* Open co
kimage
*kimage)
}
}
+int machine_kexec_post_load(struct kimage *kimage)
+{
+ void *reloc_code = page_to_virt(kimage->control_code_page);
+
+ /* If in place flush new kernel image, else flush lists and buffers */
+ if (kimage->head & IND_DONE)
+ kex
When dumping the current VMCS state, include the MSRs that are being
automatically loaded/stored during VM entry/exit.
Signed-off-by: David Edmondson
---
arch/x86/kvm/vmx/vmx.c | 16
1 file changed, 16 insertions(+)
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
i
When dumping the current VMCS state, include the MSRs that are being
automatically loaded/stored during VM entry/exit.
Signed-off-by: David Edmondson
---
arch/x86/kvm/vmx/vmx.c | 25 +
arch/x86/kvm/vmx/vmx.h | 2 +-
2 files changed, 22 insertions(+), 5 deletions(-)
diff
When dumping the current VMCS state, include the MSRs that are being
automatically loaded/stored during VM entry/exit.
Signed-off-by: David Edmondson
---
arch/x86/kvm/vmx/vmx.c | 25 +
arch/x86/kvm/vmx/vmx.h | 2 +-
2 files changed, 22 insertions(+), 5 deletions(-)
diff
On 2021-01-15 13:53, Masahiro Yamada wrote:
On Sat, Jan 16, 2021 at 5:15 AM wrote:
On 2021-01-14 17:12, Masahiro Yamada wrote:
> On Fri, Jan 15, 2021 at 6:50 AM Jeff Johnson
> wrote:
>>
>> From: Mahesh Kumar Kalikot Veetil
>>
>> Modules with a large number of compilation units may be
>> exce
On Sat, Jan 16, 2021 at 5:15 AM wrote:
>
> On 2021-01-14 17:12, Masahiro Yamada wrote:
> > On Fri, Jan 15, 2021 at 6:50 AM Jeff Johnson
> > wrote:
> >>
> >> From: Mahesh Kumar Kalikot Veetil
> >>
> >> Modules with a large number of compilation units may be
> >> exceeding AR and LD command argume
On 2021-01-14 17:12, Masahiro Yamada wrote:
On Fri, Jan 15, 2021 at 6:50 AM Jeff Johnson
wrote:
From: Mahesh Kumar Kalikot Veetil
Modules with a large number of compilation units may be
exceeding AR and LD command argument list. Handle this gracefully by
writing the long argument list in a f
On Fri, Jan 15, 2021 at 10:01 AM Nick Desaulniers
wrote:
>
> On Thu, Jan 14, 2021 at 1:50 PM Jeff Johnson wrote:
> >
> > From: Mahesh Kumar Kalikot Veetil
> >
> > Modules with a large number of compilation units may be
> > exceeding AR and LD command argument list. Handle this gracefully by
> >
On Fri, Jan 15, 2021 at 6:50 AM Jeff Johnson wrote:
>
> From: Mahesh Kumar Kalikot Veetil
>
> Modules with a large number of compilation units may be
> exceeding AR and LD command argument list. Handle this gracefully by
> writing the long argument list in a file. The command line options
> read
On Thu, Jan 14, 2021 at 1:50 PM Jeff Johnson wrote:
>
> From: Mahesh Kumar Kalikot Veetil
>
> Modules with a large number of compilation units may be
> exceeding AR and LD command argument list. Handle this gracefully by
> writing the long argument list in a file. The command line options
> read
From: Mahesh Kumar Kalikot Veetil
Modules with a large number of compilation units may be
exceeding AR and LD command argument list. Handle this gracefully by
writing the long argument list in a file. The command line options
read from file are inserted in place of the original @file option.
The
On 2021-01-14 13:07, Nick Desaulniers wrote:
From: Mahesh Kumar Kalikot Veetil
Modules with a large number of compilation units may be
exceeding AR and LD command argument list. Handle this gracefully by
writing the long argument list in a file. The command line options
read from file are inser
> From: Mahesh Kumar Kalikot Veetil
>
> Modules with a large number of compilation units may be
> exceeding AR and LD command argument list. Handle this gracefully by
> writing the long argument list in a file. The command line options
> read from file are inserted in place of the original @file
From: Mahesh Kumar Kalikot Veetil
Modules with a large number of compilation units may be
exceeding AR and LD command argument list. Handle this gracefully by
writing the long argument list in a file. The command line options
read from file are inserted in place of the original @file option.
The
umerate
devices in the given scope of the ACPI namespace in two passes,
where the first pass covers the devices without "significant" lists
of dependencies coming from _DEP only and the second pass covers
all of the devices that were not enumerated in the first pass.
Take _DEP into accoun
: Paul E. McKenney
CommitterDate: Thu, 19 Nov 2020 19:37:16 -08:00
list.h: Update comment to explicitly note circular lists
The students in the Operating System Lecture Section at the
American University of Sharjah were confused by the header comment
in include/linux/list.h, which says "S
On Thu, 19 Nov 2020 10:27:09 +0800
Wei Li wrote:
> The feature lists don't match reality as of v5.10-rc4, update them
> accordingly (by features-refresh.sh).
>
> Fixes: aa65ff6b18e0 ("powerpc/64s: Implement queued spinlocks and rwlocks")
> Fixes: e95a4f8cb
The feature lists don't match reality as of v5.10-rc4, update them
accordingly (by features-refresh.sh).
Fixes: aa65ff6b18e0 ("powerpc/64s: Implement queued spinlocks and rwlocks")
Fixes: e95a4f8cb985 ("csky: Add SECCOMP_FILTER supported")
Fixes: 0bb605c2c7f2 ("
*
* Some of the internal functions ("__xxx") are useful when
* manipulating whole lists rather than single entries, as
--
2.9.5
Hi Jeremy,
On Thursday 05 Nov 2020 at 09:50:30 (-0600), Jeremy Linton wrote:
> Hi,
>
> On 11/5/20 6:55 AM, Ionela Voinescu wrote:
> > The cppc_cpudata per-cpu storage was inefficient (1) additional to causing
> > functional issues (2) when CPUs are hotplugged out, due to per-cpu data
> > being im
Hi,
On 11/5/20 6:55 AM, Ionela Voinescu wrote:
The cppc_cpudata per-cpu storage was inefficient (1) additional to causing
functional issues (2) when CPUs are hotplugged out, due to per-cpu data
being improperly initialised.
(1) The amount of information needed for CPPC performance control in it
The cppc_cpudata per-cpu storage was inefficient (1) additional to causing
functional issues (2) when CPUs are hotplugged out, due to per-cpu data
being improperly initialised.
(1) The amount of information needed for CPPC performance control in its
cpufreq driver depends on the domain (PSD) c
From: Rob Clark
Rather than relying on the big dev->struct_mutex hammer, introduce a
more specific lock for protecting the bo lists.
Signed-off-by: Rob Clark
Reviewed-by: Jordan Crouse
Reviewed-by: Kristian H. Kristensen
---
drivers/gpu/drm/msm/msm_debugfs.c | 7 +++
drivers/
From: Rob Clark
Rather than relying on the big dev->struct_mutex hammer, introduce a
more specific lock for protecting the bo lists.
Signed-off-by: Rob Clark
Reviewed-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_debugfs.c | 7 +++
drivers/gpu/drm/msm/msm_drv.c |
From: Rob Clark
Rather than relying on the big dev->struct_mutex hammer, introduce a
more specific lock for protecting the bo lists.
Signed-off-by: Rob Clark
Reviewed-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_debugfs.c | 7 +++
drivers/gpu/drm/msm/msm_drv.c |
On Sun, Oct 04, 2020 at 12:21:36PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Rather than relying on the big dev->struct_mutex hammer, introduce a
> more specific lock for protecting the bo lists.
Most excellent.
Reviewed-by: Jordan Crouse
> Signed-off-by: Rob Clark
&g
On Sun, Oct 4, 2020 at 3:15 PM Daniel Vetter wrote:
>
> On Sun, Oct 4, 2020 at 9:21 PM Rob Clark wrote:
> >
> > From: Rob Clark
> >
> > Rather than relying on the big dev->struct_mutex hammer, introduce a
> > more specific lock for protecting the bo
On Sun, Oct 4, 2020 at 9:21 PM Rob Clark wrote:
>
> From: Rob Clark
>
> Rather than relying on the big dev->struct_mutex hammer, introduce a
> more specific lock for protecting the bo lists.
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/msm_debugfs.c
From: Rob Clark
Rather than relying on the big dev->struct_mutex hammer, introduce a
more specific lock for protecting the bo lists.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_debugfs.c | 7 +++
drivers/gpu/drm/msm/msm_drv.c | 1 +
drivers/gpu/drm/msm/msm_dr
From: Hans de Goede
commit c4440b8a457779adeec42c5e181cb4016f19ce0f upstream.
The keyboard drops keypresses early during boot unless both the nomux
and reset quirks are set. Add DMI table entries for this.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1806085
Signed-off-by: Hans de Goede
From: Hans de Goede
commit c4440b8a457779adeec42c5e181cb4016f19ce0f upstream.
The keyboard drops keypresses early during boot unless both the nomux
and reset quirks are set. Add DMI table entries for this.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1806085
Signed-off-by: Hans de Goede
From: Hans de Goede
commit c4440b8a457779adeec42c5e181cb4016f19ce0f upstream.
The keyboard drops keypresses early during boot unless both the nomux
and reset quirks are set. Add DMI table entries for this.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1806085
Signed-off-by: Hans de Goede
From: Hans de Goede
commit c4440b8a457779adeec42c5e181cb4016f19ce0f upstream.
The keyboard drops keypresses early during boot unless both the nomux
and reset quirks are set. Add DMI table entries for this.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1806085
Signed-off-by: Hans de Goede
From: Hans de Goede
commit c4440b8a457779adeec42c5e181cb4016f19ce0f upstream.
The keyboard drops keypresses early during boot unless both the nomux
and reset quirks are set. Add DMI table entries for this.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1806085
Signed-off-by: Hans de Goede
From: Hans de Goede
commit c4440b8a457779adeec42c5e181cb4016f19ce0f upstream.
The keyboard drops keypresses early during boot unless both the nomux
and reset quirks are set. Add DMI table entries for this.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1806085
Signed-off-by: Hans de Goede
am commit 83d060ca8d90fa1e3feac227f995c013100862d3 ]
> > > > > > > >
> > > > > > > > Before this patch, transactions could be merged into the system
> > > > > > > > transaction by function gfs2_merge_trans(), but the transactio
Bundle the trap related lists: trap_list, trap_group_list and
trap_policer_list in a dedicated struct. This will be handy in the
coming patches in the set introducing traps in devlink port context.
With trap_lists, code reuse is much simpler.
Signed-off-by: Aya Levin
---
Changelog:
v1->v2:
Pa
gt; > > > From: Bob Peterson
> > > > > > >
> > > > > > > [ Upstream commit 83d060ca8d90fa1e3feac227f995c013100862d3 ]
> > > > > > >
> > > > > > > Before this patch, transactions could be merged into the system
> > > > > &
mmit 83d060ca8d90fa1e3feac227f995c013100862d3 ]
> > > > > >
> > > > > > Before this patch, transactions could be merged into the system
> > > > > > transaction by function gfs2_merge_trans(), but the transaction ail
> > > > > > li
Christoph,
> On Fri, Sep 11, 2020 at 08:37:54AM +0200, Lukas Bulwahn wrote:
>> - ocfs2-devel.oss.oracle.com
>> - rds-devel.oss.oracle.com
Both of these are public development lists and should be fully
functional, have archives available, etc. Let me know if that
23, 2020 at 09:57:50PM +0200, Greg Kroah-Hartman wrote:
> > > > > From: Bob Peterson
> > > > >
> > > > > [ Upstream commit 83d060ca8d90fa1e3feac227f995c013100862d3 ]
> > > > >
> > > > > Before this patch, transactions c
d060ca8d90fa1e3feac227f995c013100862d3 ]
> > > > > >
> > > > > > Before this patch, transactions could be merged into the system
> > > > > > transaction by function gfs2_merge_trans(), but the transaction ail
> > > > > > lists were n
an wrote:
> > > > From: Bob Peterson
> > > >
> > > > [ Upstream commit 83d060ca8d90fa1e3feac227f995c013100862d3 ]
> > > >
> > > > Before this patch, transactions could be merged into the system
> > > > transaction by function gfs2_merge_
On Fri, Sep 11, 2020 at 2:09 PM Salvatore Bonaccorso wrote:
> On Fri, Sep 11, 2020 at 01:58:16PM +0200, Greg Kroah-Hartman wrote:
> > Can you report this to the gfs2 developers?
>
> Sure! Bob Peterson and Andreas Gruenbacher were already on the
> recipient list but I forgot cluster-de...@redhat.co
; > > From: Bob Peterson
> > >
> > > [ Upstream commit 83d060ca8d90fa1e3feac227f995c013100862d3 ]
> > >
> > > Before this patch, transactions could be merged into the system
> > > transaction by function gfs2_merge_trans(), but the transaction ai
commit 83d060ca8d90fa1e3feac227f995c013100862d3 ]
> > >
> > > Before this patch, transactions could be merged into the system
> > > transaction by function gfs2_merge_trans(), but the transaction ail
> > > lists were never merged. Because the ail flushing mechanism can run
efore this patch, transactions could be merged into the system
> > transaction by function gfs2_merge_trans(), but the transaction ail
> > lists were never merged. Because the ail flushing mechanism can run
> > separately, bd elements can be attached to the transaction's buffer
>
On Fri, 11 Sep 2020, Joe Perches wrote:
> On Fri, 2020-09-11 at 08:37 +0200, Lukas Bulwahn wrote:
> > Hi Joe,
> >
> > in my continued effort to clean up MAINTAINERS, I came across various
> > email "lists" that are actually just some kind of internal
On Fri, 2020-09-11 at 08:37 +0200, Lukas Bulwahn wrote:
> Hi Joe,
>
> in my continued effort to clean up MAINTAINERS, I came across various
> email "lists" that are actually just some kind of internal distribution
> lists, but we cannot subscribe to them (no archives a
com seems
> pretty much unmaintained.
>
> > - rds-devel.oss.oracle.com
>
> The same probably applies here.
>
Thanks, Christoph; it seems that I miscategorized those two email
addresses in my first attempt going through the data.
I found the URLs how to subscribe to those
On Fri, Sep 11, 2020 at 08:37:54AM +0200, Lukas Bulwahn wrote:
> - ocfs2-devel.oss.oracle.com
This is a normal mailing list, and I subscribed to it normally. It
might howerever be brken in various ways as oss.oracle.com seems
pretty much unmaintained.
> - rds-devel.oss.oracle.com
The same p
Hi Joe,
in my continued effort to clean up MAINTAINERS, I came across various
email "lists" that are actually just some kind of internal distribution
lists, but we cannot subscribe to them (no archives available) and they
are not affiliated to a specific person.
Some examples are
ut the transaction ail
> lists were never merged. Because the ail flushing mechanism can run
> separately, bd elements can be attached to the transaction's buffer
> list during the transaction (trans_add_meta, etc) but quickly moved
> to its ail lists. Later, in function gfs2_trans_
Wed, Sep 02, 2020 at 05:32:11PM CEST, a...@mellanox.com wrote:
>Bundle the trap related lists: trap_list, trap_group_list and
>trap_policer_list and trap ops like: trap_init, trap_fini,
>trap_action_set... together in trap_mngr. This will be handy in the
>coming patches in the set
Bundle the trap related lists: trap_list, trap_group_list and
trap_policer_list and trap ops like: trap_init, trap_fini,
trap_action_set... together in trap_mngr. This will be handy in the
coming patches in the set introducing traps in devlink port context.
With trap_mngr, code reuse is much
From: Jernej Skrabec
When dealing with interlaced frames, reference lists must tell if
each particular reference is meant for top or bottom field. This info
is currently not provided at all in the H264 related controls.
Change reference lists to hold a structure, which specifies
an index into
Commit 0b0393d59eb4a ("media: uapi: h264: clarify
expected scaling_list_4x4/8x8 order") improved the
documentation on H264 scaling lists order.
This commit improves the documentation by clarifying
that the lists themselves are expected in raster scan order.
Signed-off-by: Ezequiel Garc
On 14/08/2020 15:36, Ezequiel Garcia wrote:
> From: Jernej Skrabec
>
> When dealing with with interlaced frames, reference lists must tell if
> each particular reference is meant for top or bottom field. This info
> is currently not provided at all in the H264 related cont
From: Jernej Skrabec
When dealing with with interlaced frames, reference lists must tell if
each particular reference is meant for top or bottom field. This info
is currently not provided at all in the H264 related controls.
Make reference lists hold a structure which will also hold an
Commit 0b0393d59eb4a ("media: uapi: h264: clarify
expected scaling_list_4x4/8x8 order") improved the
documentation on H264 scaling lists order.
This commit improves the documentation by clarifying
that the lists themselves are expected in raster scan order.
Signed-off-by: Ezequiel Garc
On Thu, 6 Aug 2020 at 14:38, Ezequiel Garcia wrote:
>
> From: Jernej Skrabec
>
> When dealing with with interlaced frames, reference lists must tell if
> each particular reference is meant for top or bottom field. This info
> is currently not provided at all in the H26
On Thu, 2020-08-06 at 17:47 +0200, Paul Kocialkowski wrote:
> Hi,
>
> On Thu 06 Aug 20, 12:12, Ezequiel Garcia wrote:
> > From: Jernej Skrabec
> >
> > When dealing with with interlaced frames, reference lists must tell if
> > each particular reference is meant f
Commit 0b0393d59eb4a ("media: uapi: h264: clarify
expected scaling_list_4x4/8x8 order") improved the
documentation on H264 scaling lists order.
This commit improves the documentation by clarifying
that the lists themselves are expected in raster scan order.
Signed-off-by: Ezequiel Garc
Hi!
Dne četrtek, 06. avgust 2020 ob 17:47:07 CEST je Paul Kocialkowski napisal(a):
> Hi,
>
> On Thu 06 Aug 20, 12:12, Ezequiel Garcia wrote:
> > From: Jernej Skrabec
> >
> > When dealing with with interlaced frames, reference lists must tell if
> > each particu
1 - 100 of 1072 matches
Mail list logo
