Re: [RFC][PATCH] uprobe: support for private hugetlb mappings

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

Re: [RFC][PATCH] uprobe: support for private hugetlb mappings

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

Re: [RFC][PATCH] uprobe: support for private hugetlb mappings

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

Re: [RFC][PATCH] uprobe: support for private hugetlb mappings

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

Re: [RFC][PATCH] uprobe: support for private hugetlb mappings

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

Re: [RFC][PATCH] uprobe: support for private hugetlb mappings

(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

[BUG] incorrect scaling_max_freq with intel_pstate after offline/online

*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

Re: kernel panics with 4.14.X versions

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>

Re: kernel panics with 4.14.X versions

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

Re: 3.14 stable regression don't remove from shrink list in select_collect()

ids in that message, the fixed list is here: http://www.spinics.net/lists/stable/msg111553.html -- Guillaume Morin

Re: 3.14 stable regression don't remove from shrink list in select_collect()

ids in that message, the fixed list is here: http://www.spinics.net/lists/stable/msg111553.html -- Guillaume Morin <guilla...@morinfr.org>

Re: Linux 3.14.58

> 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

Re: Linux 3.14.58

> 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

Re: [PATCH] staging: llite: rw.c: use gfp_t to store GFP flags

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

[PATCH v2] staging: llite: rw.c: remove gfp_mask

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

[PATCH] staging: llite: rw.c: use gfp_t to store GFP flags

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

[PATCH] staging: llite: rw.c: use gfp_t to store GFP flags

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

[PATCH v2] staging: llite: rw.c: remove gfp_mask

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

Re: [PATCH] staging: llite: rw.c: use gfp_t to store GFP flags

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

Re: [BUG] new copy_hugetlb_page_range() causing crashes

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()

Re: [BUG] new copy_hugetlb_page_range() causing crashes

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/

[BUG] new copy_hugetlb_page_range() causing crashes

(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

[BUG] new copy_hugetlb_page_range() causing crashes

(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

Re: [BUG] new copy_hugetlb_page_range() causing crashes

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

Re: [BUG] new copy_hugetlb_page_range() causing crashes

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

[PATCH v2] staging: dgnc_driver.c: code style fixes

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

[PATCH v4 1/1] staging: iio: ad9850.c: code cleanup

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

[PATCH v3 1/1] staging: iio: ad9850.c: code cleanup

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

[PATCH v3 1/1] staging: iio: ad9850.c: code cleanup

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

[PATCH v4 1/1] staging: iio: ad9850.c: code cleanup

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

[PATCH v2] staging: dgnc_driver.c: code style fixes

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

[PATCH] staging: dgnc_driver.c: code style fixes

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

Re: [PATCH v2 1/1] staging: iio: ad9850.c: fix checkpatch.pl error

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

Re: [PATCH v2 1/1] staging: iio: ad9850.c: fix checkpatch.pl error

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... -

[PATCH v2 1/1] staging: iio: ad9850.c: fix checkpatch.pl error

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

[PATCH 1/1] staging: iio: ad9850.c: fix checkpatch.pl error

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

[PATCH 1/1] staging: iio: ad9850.c: fix checkpatch.pl error

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

[PATCH v2 1/1] staging: iio: ad9850.c: fix checkpatch.pl error

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

Re: [PATCH v2 1/1] staging: iio: ad9850.c: fix checkpatch.pl error

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

Re: [PATCH v2 1/1] staging: iio: ad9850.c: fix checkpatch.pl error

, 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

[PATCH] staging: dgnc_driver.c: code style fixes

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

Re: [PATCH] selftests: ipc: handle msgget failure return correctly

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/

Re: [PATCH] selftests: ipc: handle msgget failure return correctly

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

Re: + exitc-call-proc_exit_connector-after-exit_state-is-set.patch added to -mm tree

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/

Re: + exitc-call-proc_exit_connector-after-exit_state-is-set.patch added to -mm tree

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

Re: + exitc-call-proc_exit_connector-after-exit_state-is-set.patch added to -mm tree

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

Re: + exitc-call-proc_exit_connector-after-exit_state-is-set.patch added to -mm tree

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

[PATCH] exit.c: call proc_exit_connector() after exit_state is set

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

Re: BUG: Bad page state in process with linux 3.4.76

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

Re: BUG: Bad page state in process with linux 3.4.76

, 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

[PATCH] exit.c: call proc_exit_connector() after exit_state is set

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

Re: [PATCH 3.4 00/37] 3.4.79-stable review

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

Re: [PATCH 3.4 00/37] 3.4.79-stable review

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

Re: [PATCH 3.4 00/37] 3.4.79-stable review

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

Re: [PATCH 3.4 00/37] 3.4.79-stable review

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

Re: BUG: Bad page state in process with linux 3.4.76

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: > &

BUG: Bad page state in process with linux 3.4.76

+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;

BUG: Bad page state in process with linux 3.4.76

[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

Re: BUG: Bad page state in process with linux 3.4.76

, 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