, 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.
--
Guillaume Morin guilla
From: Guillaume Morin guilla...@morinfr.org
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
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.
What am I missing?
Guillaume.
--
Guillaume Morin guilla...@morinfr.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
message for the thread you created in
main().
But let me repeat just in case: I am not arguing with this change.
That was my understanding from my message. But I wanted to respond to
make sure I understood your points correctly.
Thanks for your help. I appreciate it.
Guillaume.
--
Guillaume
might
as well save it before printf() is called.
--
Guillaume Morin guilla...@morinfr.org
--
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
[8103c677] sys_exit_group+0x17/0x20
[814d03d2] system_call_fastpath+0x16/0x1b
--
Guillaume Morin guilla...@morinfr.org
#define _GNU_SOURCE
#include libaio.h
#include errno.h
#include unistd.h
#include sys/types.h
#include sys/stat.h
#include fcntl.h
#include sys/eventfd.h
#include sys/epoll.h
, Guillaume Morin wrote:
Hi,
I wrote this simple program (attached) to play around with kernel AIO.
It simply does kernel AIO with O_DIRECT on a small temp file stored on
an ext4 filesystem.
When I run it with HUGETLB_MORECORE=yes LD_PRELOAD=libhugetlbfs.so, it
triggers the kernel bug on exit
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 guilla...@morinfr.org
--
To unsubscribe from this list: send the line
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 guilla...@morinfr.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
Use gfp_t to store GPF_* flags instead of unsigned int.
This was reported by sparse.
Signed-off-by: Guillaume Morin guilla...@morinfr.org
---
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
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 guilla...@morinfr.org
Suggested-by: gre...@linuxfoundation.org
---
v2: remove the variable instead of just fixing the type since it is not used
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 guilla...@morinfr.org
--
To unsubscribe from this list: send the line
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
v2: add missing Signed-off-by
Signed-off-by: Guillaume Morin guilla...@morinfr.org
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
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...
--
Guillaume Morin guilla
, it isn't always correct.
Right, I guess it's borderline. Should I resend the patch or just drop
it?
Guillaume.
--
Guillaume Morin guilla...@morinfr.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo
From: Guillaume Morin guilla...@morinfr.org
Simple code style fixes
Signed-off-by: Guillaume Morin guilla...@morinfr.org
---
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
Welling.
Signed-off-by: Guillaume Morin guilla...@morinfr.org
---
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
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 guilla
From: Guillaume Morin guilla...@morinfr.org
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 guilla...@morinfr.org
---
Changes since v1
(as
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 guilla
when I remove your patch though
Guillaume.
--
Guillaume Morin guilla...@morinfr.org
--
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
the huge_ptep_get call for that
case and it's fixing the problem for me...
Hmm, want a patch?
--
Guillaume Morin guilla...@morinfr.org
--
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
> 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 will pick them up
ids in that message, the fixed list is
here:
http://www.spinics.net/lists/stable/msg111553.html
--
Guillaume Morin <guilla...@morinfr.org>
emd 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 <guilla...@morinfr.org>
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.
What am I missing?
Gu
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/
be 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/
ixup...
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.
--
Gui
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
+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_event ev;
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:
>
&
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 &quo
ne.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 unsubscri
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
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
hanged:
$ 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...
-
t 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: send the line "unsubsc
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
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/drivers/staging/iio
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
Reported
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
---
C
(as
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
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/
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_ptep_set_wrprotect() in the pte_present()
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 "unsubscribe l
emd 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
*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
> 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 will pick
ids in that message, the fixed list is
here:
http://www.spinics.net/lists/stable/msg111553.html
--
Guillaume Morin
(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, the
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
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
pin_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, _folio->page, !unshare);
+ const bool writable = !unshare && (vma->vm_flags & VM_WRITE);
+ pte_t newpte = make_huge_pte(vma, _folio->page, writable);
/* Break COW or unshare */
huge_ptep_clear_flush(vma, vmf->address, vmf->pte);
--
Guillaume Morin
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
e 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 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're not fol
) {
> > + 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
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
63 matches
Mail list logo