(Dropping Mike Kravetz as CC since he has retired and his email is no
longer valid, adding Muchun since he's the current hugetlb maintainer,
as well as linux-trace-kernel)
On 22 Apr 11:39, David Hildenbrand wrote:
>
> On 19.04.24 20:37, Guillaume Morin wrote:
> > libhugetlbfs
lb folios don't grow on trees. Likely, Many
> setups *don't* reserve extra hugetlb folios and you might just easily be
> running out of free hugetlb folios that you can use to break COW here
> (replace a file hugetlb by a fresh anon hugetlb page). Likely it's easy to
> make register or unregister fail.
Agreed.
--
Guillaume Morin
t; > plan or testing as you see fit. Let me know.
>
> I'm hacking on a redesign that removes the manual COW breaking logic and
> *might* make it easier to integrate hugetlb. (very likely, but until I have
> the redesign running I cannot promise anything :) )
>
> I'll let you know once I have something ready so you could integrate the
> hugetlb portion.
Sounds good.
--
Guillaume Morin
de that if the pte is not writable and this is a write fault
then we're in the FOLL_FORCE|FOLL_WRITE case. Or do we want to keep the
checks simply not enforce it for FOLL_FORCE|FOLL_WRITE?
The latter is more complicated in the fault path because there is no
FAULT_FLAG_FORCE flag.
--
Guillaume Morin
On 25 Apr 21:56, David Hildenbrand wrote:
>
> On 25.04.24 17:19, Guillaume Morin wrote:
> > On 24 Apr 23:00, David Hildenbrand wrote:
> > > > One issue here is that FOLL_FORCE|FOLL_WRITE is not implemented for
> > > > hugetlb mappings. However this wa
truct folio
*pagecache_folio,
spin_lock(vmf->ptl);
vmf->pte = hugetlb_walk(vma, vmf->address, huge_page_size(h));
if (likely(vmf->pte && pte_same(huge_ptep_get(vmf->pte), pte))) {
- pte_t newpte = make_huge_pte(vma, &new_folio->page, !unshare);
+ const bool writable = !unshare && (vma->vm_flags & VM_WRITE);
+ pte_t newpte = make_huge_pte(vma, &new_folio->page, writable);
/* Break COW or unshare */
huge_ptep_clear_flush(vma, vmf->address, vmf->pte);
--
Guillaume Morin
On 26 Apr 21:55, Guillaume Morin wrote:
>
> On 26 Apr 9:19, David Hildenbrand wrote:
> > A couple of points:
> >
> > a) Don't use page_mapcount(). Either folio_mapcount(), but likely you want
> > to check PageAnonExclusive.
> >
> > b) If you'
pcode(page, opcode_vaddr, &opcode);
> > +
> > + if (is_vm_hugetlb_page(vma)) {
> > + struct hstate *h = hstate_vma(vma);
> > + page_size = huge_page_size(h);
> > + vaddr &= huge_page_mask(h);
> > + page = compound_head(page);
>
> I think we should only adjust the range we pass to the mmu notifier and for
> walking the VMA range. But we should not adjust vaddr.
>
> Further, we should not adjust the page if possible ... ideally, we'll treat
> hugetlb folios just like large folios here and operate on subpages.
>
> Inside __write_opcode(), we can derive the the page of interest from
> data->opcode_vaddr.
Here you mean __write_opcode_hugetlb(), right? Since we're going with
the 2 independent variants. Just want to 100% sure I am following
> find_get_page() might need some though, if it won't return a subpage of a
> hugetlb folio. Should be solvable by a wrapper, though.
We can zero out the subbits with the huge page mask in the
vaddr_to_offset() in the hugetlb variant like I do in __copy_insn() and
that should work, no? Or you prefer a wrapper?
Guillaume.
--
Guillaume Morin
getlbfs specific
+* logic
+*/
if (!inode->i_mapping->a_ops->read_folio &&
- !shmem_mapping(inode->i_mapping))
+ !shmem_mapping(inode->i_mapping) &&
+ !hugetlbfs_mapping(inode->i_mapping))
return -EIO;
/* Racy, just to catch the obvious mistakes */
if (offset > i_size_read(inode))
--
Guillaume Morin
On 02 May 5:59, Guillaume Morin wrote:
>
> On 30 Apr 21:25, David Hildenbrand wrote:
> > > I tried to get the hugepd stuff right but this was the first I heard
> > > about it :-) Afaict follow_huge_pmd and friends were already DTRT
> >
> > I'll have t
struct acpi_processor_performance
+ *performance, unsigned int cpu) {
+ return __acpi_processor_register_performance(performance, cpu, 0);
+}
extern void acpi_processor_unregister_performance(unsigned int cpu);
int acpi_processor_pstate_control(void);
--
Guillaume Morin
nal fixup...
Yes, it did get resolved. Khalid backported
27c73ae759774e63313c1fbfeb17ba076cea64c5 which fixed the problem in the
mainline kernel and it was released in 3.4.79 as
50d8f1b5c57bb29f02ab5834be334b4f7922b856 (and included the other stable
branches as well).
Guillaume.
--
Guill
From: Guillaume Morin
The process events connector delivers a notification when a process
exits. This is really convenient for a process that spawns and wants
to monitor its children through an epoll-able() interface.
Unfortunately, there is a small window between when the event is
delivered
aybe I am nitpicking here but printf() could modify errno, so you might
as well save it before printf() is called.
--
Guillaume Morin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
w
this could happen?
My understanding is that if all threads exited before waitpid() is
called, exit->state will be set to EXIT_ZOMBIE for the pid and that
delay_group_leader() will be false (because all sub-threads have
exited), so that waitpid(WNOHANG) will successfully reap the process.
Wh
sure I understood your points correctly.
Thanks for your help. I appreciate it.
Guillaume.
--
Guillaume Morin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
l_fastpath+0x16/0x1b
--
Guillaume Morin
#define _GNU_SOURCE
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define FILE_SIZE 4096
int main(void)
{
io_context_t ctx;
int fd,fd_odirect,i,event_fd,epoll_fd;
struct epoll_eve
Greg,
I am going to do more testing but it seems that reverting this patch
from 3.4.69 fixes the BUG
commit b07ef016454ff46f98e633b5a6247ca7e343fb67
Author: Khalid Aziz
I also verified that I cannot reproduce this problem with 3.13-rc8
Guillaume.
On 14 Jan 21:34, Guillaume Morin wrote:
>
&
2bcdd4933ff4dc46445dcae93cb37c648283b782 in the stable branch). The 3.4
and 3.14 patches are identical to the upstream commit so that's not a patch
backport issue.
If I revert only 2bcdd4933ff4dc46445dcae93cb37c648283b782 in my 3.4
tree, the crashes disappear right away and everything is stable.
--
Guillaume Morin
s gets stuck instead asserting out. But I could not
make it SIGSEGV
Same result with the 3.4.98 kernel.
It works fine when I remove your patch though
Guillaume.
--
Guillaume Morin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
I checked with systemtap
> that both these check returned false in the above test program.
> So I'm wondering why the commit makes difference for this test program.
I don't know why I am just thinking about that now. Isn't this the fact
that your patch moved the huge_ptep_get() before
huge
Use gfp_t to store GPF_* flags instead of unsigned int.
This was reported by sparse.
Signed-off-by: Guillaume Morin
---
drivers/staging/lustre/lustre/llite/rw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/lustre/lustre/llite/rw.c
b/drivers/staging
sparse reported that gfp_mask was of the wrong type to store gfp flags. The
variable is not used so it can be removed.
Signed-off-by: Guillaume Morin
Suggested-by: gre...@linuxfoundation.org
---
v2: remove the variable instead of just fixing the type since it is not used
drivers/staging
On 21 Jul 19:08, Greg KH wrote:
> Odd thing is, that function doesn't seem to even use that variable
> anywhere... Can you just remove it entirely?
Oh that's right. Resubmitted.
Thanks
Guillaume.
--
Guillaume Morin
--
To unsubscribe from this list: send the line "uns
diff --git a/drivers/staging/iio/frequency/ad9850.c
b/drivers/staging/iio/frequency/ad9850.c
index af877ff..6183670 100644
--- a/drivers/staging/iio/frequency/ad9850.c
+++ b/drivers/staging/iio/frequency/ad9850.c
@@ -21,7 +21,7 @@
#define DRV_NAME "ad9850"
-#define value_mask (u16)0xf000
+#d
v2: add missing Signed-off-by
Signed-off-by: Guillaume Morin
diff --git a/drivers/staging/iio/frequency/ad9850.c
b/drivers/staging/iio/frequency/ad9850.c
index af877ff..6183670 100644
--- a/drivers/staging/iio/frequency/ad9850.c
+++ b/drivers/staging/iio/frequency/ad9850.c
@@ -21,7 +21,7
s what I changed:
$ scripts/checkpatch.pl -f drivers/staging/iio/frequency/ad9850.c
ERROR: Macros with complex values should be enclosed in parenthesis
#24: FILE: drivers/staging/iio/frequency/ad9850.c:24:
+#define value_mask (u16)0xf000
I assumed that if it was reported as an error, it needed to be fixed...
sumed that if it was reported as an error, it needed to be fixed...
>
> Use your judgement, checkpatch is a tool, it isn't always correct.
Right, I guess it's borderline. Should I resend the patch or just drop
it?
Guillaume.
--
Guillaume Morin
--
To unsubscribe from this list: se
From: Guillaume Morin
Simple code style fixes
Signed-off-by: Guillaume Morin
---
drivers/staging/dgnc/dgnc_driver.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_driver.c
b/drivers/staging/dgnc/dgnc_driver.c
index d52a9e8..68460af
chael Welling.
Signed-off-by: Guillaume Morin
---
Changes since v2:
- Got rid of the macro altogether since it's unused
- removed unused addr_shit
- remove error_ret since it's not needed
drivers/staging/iio/frequency/ad9850.c |6 --
1 file changed, 6 deletions(-)
diff --git a/driv
checkpath.pl was complaining about value_mask:
ERROR: Macros with complex values should be enclosed in parenthesis
I fixed this by simply removing it since it's not used (as well as another
macro). Got rid of the un-necessary error_ret label as well.
Signed-off-by: Guillaume Morin
Report
From: Guillaume Morin
Simple code style fixes:
- "if(" -> "if ("
- "switch(" -> "switch ("
- move one open brace to the line of the declaration instead of
its own line
- remove trailing whitespace
Signed-off-by: Guillaume Morin
---
Changes
here but the original thread does not
say when/if they are going to be included in 3.4. If this information
is somewhere else, could you just point me to the discussion?
Thanks in advance for your help,
Guillaume.
--
Guillaume Morin
--
To unsubscribe from this list: send the line "unsubs
ane.org/gmane.linux.kernel.stable/77261/
Note that I am not pushing for anything. I was just under the
(incorrect) impression that you would apply them to the 3.4 branch and
was surprised when it did not happen
I hope the situation is a bit clearer.
Guillaume.
--
Guillaume Morin
--
To unsubsc
th systemd handling coredumps. It's using fsnotify to learn
about new dumps.
Note that on this machine, the dumps are on a loop mount:
/dev/loop0 /usr/cores ext4 rw,relatime,data=ordered 0 0
--
Guillaume Morin
10b6a67d (Pull
> vfs dcache livelock fix from Al Viro) brought in a series to address
> this issue. So that may be needed here as well...
FWIW I noticed the same thing. The commits listed in
http://www.spinics.net/lists/stable/msg111553.html fixed the problem for me.
I assume Greg wi
messed up the commit ids in that message, the fixed list is
here:
http://www.spinics.net/lists/stable/msg111553.html
--
Guillaume Morin
37 matches
Mail list logo
