Hi folks,
We stumble upon an issue while using an AF_ALG socket to compute a hash
(crc32) directly in the kernel (using splice magic)
The issue has been fixed AFAICS by Herbert Xu in
cc440a5b68873b7b98c3130d09a69a1b13acb0b7 in a rather isolated patch (three
lines diff)
I could validate
Hi folks,
We stumble upon an issue while using an AF_ALG socket to compute a hash
(crc32) directly in the kernel (using splice magic)
The issue has been fixed AFAICS by Herbert Xu in
cc440a5b68873b7b98c3130d09a69a1b13acb0b7 in a rather isolated patch (three
lines diff)
I could validate
Hi Kalle,
On Mon, 8 Jun 2015, Kalle Valo wrote:
For staging patches please prefix the title "staging: "
Here's a tip how you can check what commit title you should use:
git log --oneline drivers/staging/rtl8723au/include/rtw_io.h
Thanks a lot!
Xavier
--
To unsubscribe from this list: send
Hi Kalle,
On Mon, 8 Jun 2015, Kalle Valo wrote:
For staging patches please prefix the title staging:
Here's a tip how you can check what commit title you should use:
git log --oneline drivers/staging/rtl8723au/include/rtw_io.h
Thanks a lot!
Xavier
--
To unsubscribe from this list: send the
Minor warnings spotted by checkpatch.pl in lustre regarding const correctness:
struct seq_operations should be const.
Signed-off-by: Xavier Roche
---
drivers/staging/lustre/lustre/llite/vvp_dev.c | 2 +-
drivers/staging/lustre/lustre/lmv/lproc_lmv.c | 2 +-
drivers/staging/lustre/lustre/lov
Minor warnings spotted by checkpatch.pl in lustre regarding const correctness:
struct seq_operations should be const.
Signed-off-by: Xavier Roche roche+...@httrack.com
---
drivers/staging/lustre/lustre/llite/vvp_dev.c | 2 +-
drivers/staging/lustre/lustre/lmv/lproc_lmv.c | 2 +-
drivers/staging
Hi folks,
Would a closefrom syscall (ie. close all fd above a certain fd) make sense in
the kernel, or is this something deemed /undesirable/ ?
Zheng Liu submitted a patch some time ago
(<1396941142-24821-1-git-send-email-wenqing...@taobao.com> ; (3)) to add this
feature, but with minor code
Hi folks,
Would a closefrom syscall (ie. close all fd above a certain fd) make sense in
the kernel, or is this something deemed /undesirable/ ?
Zheng Liu submitted a patch some time ago
(1396941142-24821-1-git-send-email-wenqing...@taobao.com ; (3)) to add this
feature, but with minor code
Hi Greg & mailing-list members,
On Thu, 28 May 2015, Greg KH wrote:
In the future, always use scripts/get_maintainer.pl to determine who to
send patches to please.
Sorry, I did use the get_maintainer.pl script, but I did not want to
bother too many people, and I only picked Marek in CC: (I
Local functions not used in other modules should be static, not extern.
(patch checked against linux-next and staging)
Signed-off-by: Xavier Roche
---
drivers/staging/ft1000/ft1000-pcmcia/ft1000_dnld.c | 24 +++---
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git
Hi Greg mailing-list members,
On Thu, 28 May 2015, Greg KH wrote:
In the future, always use scripts/get_maintainer.pl to determine who to
send patches to please.
Sorry, I did use the get_maintainer.pl script, but I did not want to
bother too many people, and I only picked Marek in CC: (I
Local functions not used in other modules should be static, not extern.
(patch checked against linux-next and staging)
Signed-off-by: Xavier Roche ro...@httrack.com
---
drivers/staging/ft1000/ft1000-pcmcia/ft1000_dnld.c | 24 +++---
1 file changed, 12 insertions(+), 12 deletions
Minor additional checkpatch.pl fix for include/rtw_io.h
Signed-off-by: Xavier Roche
---
drivers/staging/rtl8723au/include/rtw_io.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8723au/include/rtw_io.h
b/drivers/staging/rtl8723au/include/rtw_io.h
index
Minor checkpatch.pl fix (staging tree -- also validated on linux-next)
Signed-off-by: Xavier Roche
---
drivers/staging/rtl8723au/include/osdep_service.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8723au/include/osdep_service.h
b/drivers/staging
Minor checkpatch.pl fix (staging tree -- also validated on linux-next)
Signed-off-by: Xavier Roche ro...@httrack.com
---
drivers/staging/rtl8723au/include/osdep_service.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8723au/include/osdep_service.h
Minor additional checkpatch.pl fix for include/rtw_io.h
Signed-off-by: Xavier Roche ro...@httrack.com
---
drivers/staging/rtl8723au/include/rtw_io.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8723au/include/rtw_io.h
b/drivers/staging/rtl8723au/include
Nicholas Miell wrote:
> so if uc_stack doesn't point to the stack in use immediately prior to
> signal generation, this is a bug.
Looking at arch/i386/kernel/signal.c (and others) inside
setup_rt_frame(), the problem is pretty obvious:
err |= __put_user(current->sas_ss_sp,
Nicholas Miell wrote:
so if uc_stack doesn't point to the stack in use immediately prior to
signal generation, this is a bug.
Looking at arch/i386/kernel/signal.c (and others) inside
setup_rt_frame(), the problem is pretty obvious:
err |= __put_user(current-sas_ss_sp,
Hi folks,
I have a probably louzy question regarding sigaction() behaviour when an
alternate signal stack is used: it seems that I can not get the user
stack reference in the ucontext_t stack context ; ie. the uc_stack
member contains reference of the alternate signal stack, not the stack
that
Hi folks,
I have a probably louzy question regarding sigaction() behaviour when an
alternate signal stack is used: it seems that I can not get the user
stack reference in the ucontext_t stack context ; ie. the uc_stack
member contains reference of the alternate signal stack, not the stack
that
vinay wrote:
I have a problem with linux kernel's Out Of Memory (OOM) killer.
I wanted to know, is there any way that we can force OOM killer to send a signal other than SIGKILL to kill a process when ever OOM detects a system memory crunch.
As far as I understand the kernel, oom is called
vinay wrote:
I have a problem with linux kernel's Out Of Memory (OOM) killer.
I wanted to know, is there any way that we can force OOM killer to send a signal other than SIGKILL to kill a process when ever OOM detects a system memory crunch.
As far as I understand the kernel, oom is called
Hi folks,
While trying to upgrade from Linux 2.6.7 to Linux 2.6.11.12, my reiserfs
partition screwed up for an unknown reason (inconsistency in the
filesystem ?) and the kernel started to reboot each 10 minutes ("panic
loop")
I'm not sure this is related to 2.6.11.12 (the filesystem might
Hi folks,
While trying to upgrade from Linux 2.6.7 to Linux 2.6.11.12, my reiserfs
partition screwed up for an unknown reason (inconsistency in the
filesystem ?) and the kernel started to reboot each 10 minutes (panic
loop)
I'm not sure this is related to 2.6.11.12 (the filesystem might
Timestamp of file modified through mmap are not changed in 2.6 (even
after msync()). Observations on 2.4 and 2.6 kernels:
- on 2.4, timestamps are altered a few seconds after the program exits.
- on 2.6, timestamps are never altered.
Is this behaviour a normal behaviour ?
Program example to
Timestamp of file modified through mmap are not changed in 2.6 (even
after msync()). Observations on 2.4 and 2.6 kernels:
- on 2.4, timestamps are altered a few seconds after the program exits.
- on 2.6, timestamps are never altered.
Is this behaviour a normal behaviour ?
Program example to
0 0 1 rw
unmaskirq 0 0 1 rw
using_dma 0 0 1 rw
--
Xavier Roche
-
To unsubscribe from this list: send the line "unsubscribe linux-ker
0 0 1 rw
using_dma 0 0 1 rw
--
Xavier Roche
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info
28 matches
Mail list logo
