Question on page length clamping in hash walk fix and syscall crashes
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 that the patch does indeed fix the issue we were having. This bug seems to be more than a computation issue, as we experienced weird crashes in random syscall when it is triggered (ie. unpatched), such as fork, or futex-related primitives (!). The issue can be reproduced with this standalone program: https://bitbucket.org/scality/xavier-sandbox-public/raw/HEAD/kernel/issues/splicertest.c Most up-to-date stable distro are using the buggy version (Centos 7: 3.10.0, Ubuntu trusty: 3.13.0, Fedora 22: 4.3.6, etc.) Question: is the weird behavior observed (crashes inside kernel) "normal" w.r.t this issue, and how cherry-pick policy is organized w.r.t older kernel releases (LTS only ?) [ Typically the bug does not appear in 3.14.70, 3.16.0, 3.19.0 or 4.2.0 ] And sorry in advance if this question has already been answered, but I could not find any clear hint.
Question on page length clamping in hash walk fix and syscall crashes
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 that the patch does indeed fix the issue we were having. This bug seems to be more than a computation issue, as we experienced weird crashes in random syscall when it is triggered (ie. unpatched), such as fork, or futex-related primitives (!). The issue can be reproduced with this standalone program: https://bitbucket.org/scality/xavier-sandbox-public/raw/HEAD/kernel/issues/splicertest.c Most up-to-date stable distro are using the buggy version (Centos 7: 3.10.0, Ubuntu trusty: 3.13.0, Fedora 22: 4.3.6, etc.) Question: is the weird behavior observed (crashes inside kernel) "normal" w.r.t this issue, and how cherry-pick policy is organized w.r.t older kernel releases (LTS only ?) [ Typically the bug does not appear in 3.14.70, 3.16.0, 3.19.0 or 4.2.0 ] And sorry in advance if this question has already been answered, but I could not find any clear hint.
Re: [PATCH] rtl8723au: replaced asm/atomic.h by linux/atomic.h
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 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] rtl8723au: replaced asm/atomic.h by linux/atomic.h
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 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/
[PATCH] staging: lustre: fixed const warnings (struct seq_operations should be const in these contexts)
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/lov_pool.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/lustre/lustre/llite/vvp_dev.c
b/drivers/staging/lustre/lustre/llite/vvp_dev.c
index fde41d7..742be5a 100644
--- a/drivers/staging/lustre/lustre/llite/vvp_dev.c
+++ b/drivers/staging/lustre/lustre/llite/vvp_dev.c
@@ -517,7 +517,7 @@ static void vvp_pgcache_stop(struct seq_file *f, void *v)
/* Nothing to do */
}
-static struct seq_operations vvp_pgcache_ops = {
+static const struct seq_operations vvp_pgcache_ops = {
.start = vvp_pgcache_start,
.next = vvp_pgcache_next,
.stop = vvp_pgcache_stop,
diff --git a/drivers/staging/lustre/lustre/lmv/lproc_lmv.c
b/drivers/staging/lustre/lustre/lmv/lproc_lmv.c
index 22e5c31..8892b8b 100644
--- a/drivers/staging/lustre/lustre/lmv/lproc_lmv.c
+++ b/drivers/staging/lustre/lustre/lmv/lproc_lmv.c
@@ -182,7 +182,7 @@ static int lmv_tgt_seq_show(struct seq_file *p, void *v)
return 0;
}
-static struct seq_operations lmv_tgt_sops = {
+static const struct seq_operations lmv_tgt_sops = {
.start = lmv_tgt_seq_start,
.stop = lmv_tgt_seq_stop,
.next = lmv_tgt_seq_next,
diff --git a/drivers/staging/lustre/lustre/lov/lov_pool.c
b/drivers/staging/lustre/lustre/lov/lov_pool.c
index d96163d..69eaf66 100644
--- a/drivers/staging/lustre/lustre/lov/lov_pool.c
+++ b/drivers/staging/lustre/lustre/lov/lov_pool.c
@@ -269,7 +269,7 @@ static int pool_proc_show(struct seq_file *s, void *v)
return 0;
}
-static struct seq_operations pool_proc_ops = {
+static const struct seq_operations pool_proc_ops = {
.start= pool_proc_start,
.next = pool_proc_next,
.stop = pool_proc_stop,
--
1.9.1
--
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/
[PATCH] staging: lustre: fixed const warnings (struct seq_operations should be const in these contexts)
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/lustre/lustre/lov/lov_pool.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/lustre/lustre/llite/vvp_dev.c
b/drivers/staging/lustre/lustre/llite/vvp_dev.c
index fde41d7..742be5a 100644
--- a/drivers/staging/lustre/lustre/llite/vvp_dev.c
+++ b/drivers/staging/lustre/lustre/llite/vvp_dev.c
@@ -517,7 +517,7 @@ static void vvp_pgcache_stop(struct seq_file *f, void *v)
/* Nothing to do */
}
-static struct seq_operations vvp_pgcache_ops = {
+static const struct seq_operations vvp_pgcache_ops = {
.start = vvp_pgcache_start,
.next = vvp_pgcache_next,
.stop = vvp_pgcache_stop,
diff --git a/drivers/staging/lustre/lustre/lmv/lproc_lmv.c
b/drivers/staging/lustre/lustre/lmv/lproc_lmv.c
index 22e5c31..8892b8b 100644
--- a/drivers/staging/lustre/lustre/lmv/lproc_lmv.c
+++ b/drivers/staging/lustre/lustre/lmv/lproc_lmv.c
@@ -182,7 +182,7 @@ static int lmv_tgt_seq_show(struct seq_file *p, void *v)
return 0;
}
-static struct seq_operations lmv_tgt_sops = {
+static const struct seq_operations lmv_tgt_sops = {
.start = lmv_tgt_seq_start,
.stop = lmv_tgt_seq_stop,
.next = lmv_tgt_seq_next,
diff --git a/drivers/staging/lustre/lustre/lov/lov_pool.c
b/drivers/staging/lustre/lustre/lov/lov_pool.c
index d96163d..69eaf66 100644
--- a/drivers/staging/lustre/lustre/lov/lov_pool.c
+++ b/drivers/staging/lustre/lustre/lov/lov_pool.c
@@ -269,7 +269,7 @@ static int pool_proc_show(struct seq_file *s, void *v)
return 0;
}
-static struct seq_operations pool_proc_ops = {
+static const struct seq_operations pool_proc_ops = {
.start= pool_proc_start,
.next = pool_proc_next,
.stop = pool_proc_stop,
--
1.9.1
--
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/
Would adding closefrom(2) syscall to the kernel make sense ?
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 issues, and no followup was made. Rationale: Many real-life programs use fork()/exec() to spawn child, and, before calling exec(), use close() on all file descriptors above 3. This is typically used using closefrom() when available, or, when unavailable, through regular close() calls from fd=3 to fd=sysconf(_SC_OPEN_MAX)-1 (or by listing /proc/self/fd, and taking note of the highest fd). The reason to close "all file descriptors above 3" is a pragmatic approach over the existing dirty universe, where almost everybody forget to clear the "close on exec" flag, leading to inherit fd in forked task. Clearing the "close on exec" flag for all file descriptors is cumbersome enough for most programmers to forget to comply: open(..., ...) => open(..., ... | O_CLOEXEC) fopen(..., ...) => open(..., ... | O_CLOEXEC) + fdopen(...) OR fopen(..., ... + "e") dup(...) => fcntl(..., F_DUPFD_CLOEXEC, (long) 0) dup2(..., ...) => dup3(..., ..., O_CLOEXEC) opendir(...) => open(..., O_RDONLY | O_DIRECTORY | O_CLOEXEC) + fdopendir(...) pipe(...) => pipe2(..., O_CLOEXEC) acept(..., ..., ...) => accept4(..., ..., ..., O_CLOEXEC) socket(..., ..., ...) => socket(..., ... | SOCK_CLOEXEC, ...) etc. (some of the solutions listed are unavailable depending on the kernel version, glibc version, etc.) This situation leads to thousands of useless close() syscall (see for example (4)), and a better solution might be desirable rather than relying on the hypothetic cleaning of the known universe. Both BSD (2) and Solaris (3) support this feature, by the way. (I know, some people will consider this as a rebuttal to add this feature, but anyway) (1) https://lwn.net/Articles/593778/ (2) http://www.unix.com/man-page/freebsd/2/closefrom/ (3) http://docs.oracle.com/cd/E26505_01/html/816-5168/fdwalk-3c.html (4) https://bugs.openjdk.java.net/browse/JDK-4791640 Regards, Xavier -- 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/
Would adding closefrom(2) syscall to the kernel make sense ?
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 issues, and no followup was made. Rationale: Many real-life programs use fork()/exec() to spawn child, and, before calling exec(), use close() on all file descriptors above 3. This is typically used using closefrom() when available, or, when unavailable, through regular close() calls from fd=3 to fd=sysconf(_SC_OPEN_MAX)-1 (or by listing /proc/self/fd, and taking note of the highest fd). The reason to close all file descriptors above 3 is a pragmatic approach over the existing dirty universe, where almost everybody forget to clear the close on exec flag, leading to inherit fd in forked task. Clearing the close on exec flag for all file descriptors is cumbersome enough for most programmers to forget to comply: open(..., ...) = open(..., ... | O_CLOEXEC) fopen(..., ...) = open(..., ... | O_CLOEXEC) + fdopen(...) OR fopen(..., ... + e) dup(...) = fcntl(..., F_DUPFD_CLOEXEC, (long) 0) dup2(..., ...) = dup3(..., ..., O_CLOEXEC) opendir(...) = open(..., O_RDONLY | O_DIRECTORY | O_CLOEXEC) + fdopendir(...) pipe(...) = pipe2(..., O_CLOEXEC) acept(..., ..., ...) = accept4(..., ..., ..., O_CLOEXEC) socket(..., ..., ...) = socket(..., ... | SOCK_CLOEXEC, ...) etc. (some of the solutions listed are unavailable depending on the kernel version, glibc version, etc.) This situation leads to thousands of useless close() syscall (see for example (4)), and a better solution might be desirable rather than relying on the hypothetic cleaning of the known universe. Both BSD (2) and Solaris (3) support this feature, by the way. (I know, some people will consider this as a rebuttal to add this feature, but anyway) (1) https://lwn.net/Articles/593778/ (2) http://www.unix.com/man-page/freebsd/2/closefrom/ (3) http://docs.oracle.com/cd/E26505_01/html/816-5168/fdwalk-3c.html (4) https://bugs.openjdk.java.net/browse/JDK-4791640 Regards, Xavier -- 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] staging: ft1000: warning removal: extern functions to static ones
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 also did not include commit_signer/authored emails) I also did not include triv...@kernel.org this time - wasn't sure is this was "trivial enough". Thanks for the feedback! (and sorry for the direct reply - did not intended to be rude) Xavier -- 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/
[PATCH] staging: ft1000: warning removal: extern functions to static ones
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 a/drivers/staging/ft1000/ft1000-pcmcia/ft1000_dnld.c
b/drivers/staging/ft1000/ft1000-pcmcia/ft1000_dnld.c
index 83683e9..3237ee73 100644
--- a/drivers/staging/ft1000/ft1000-pcmcia/ft1000_dnld.c
+++ b/drivers/staging/ft1000/ft1000-pcmcia/ft1000_dnld.c
@@ -82,12 +82,12 @@
#define STATE_DONE_PROV 0x06
#define STATE_DONE_FILE 0x07
-u16 get_handshake(struct net_device *dev, u16 expected_value);
-void put_handshake(struct net_device *dev, u16 handshake_value);
-u16 get_request_type(struct net_device *dev);
-long get_request_value(struct net_device *dev);
-void put_request_value(struct net_device *dev, long lvalue);
-u16 hdr_checksum(struct pseudo_hdr *pHdr);
+static u16 get_handshake(struct net_device *dev, u16 expected_value);
+static void put_handshake(struct net_device *dev, u16 handshake_value);
+static u16 get_request_type(struct net_device *dev);
+static long get_request_value(struct net_device *dev);
+static void put_request_value(struct net_device *dev, long lvalue);
+static u16 hdr_checksum(struct pseudo_hdr *pHdr);
struct dsp_file_hdr {
u32 version_id;/* Version ID of this image format. */
@@ -146,7 +146,7 @@ void card_bootload(struct net_device *dev)
spin_unlock_irqrestore(>dpram_lock, flags);
}
-u16 get_handshake(struct net_device *dev, u16 expected_value)
+static u16 get_handshake(struct net_device *dev, u16 expected_value)
{
struct ft1000_info *info = netdev_priv(dev);
u16 handshake;
@@ -180,7 +180,7 @@ u16 get_handshake(struct net_device *dev, u16
expected_value)
}
-void put_handshake(struct net_device *dev, u16 handshake_value)
+static void put_handshake(struct net_device *dev, u16 handshake_value)
{
struct ft1000_info *info = netdev_priv(dev);
u32 tempx;
@@ -196,7 +196,7 @@ void put_handshake(struct net_device *dev, u16
handshake_value)
}
}
-u16 get_request_type(struct net_device *dev)
+static u16 get_request_type(struct net_device *dev)
{
struct ft1000_info *info = netdev_priv(dev);
u16 request_type;
@@ -215,7 +215,7 @@ u16 get_request_type(struct net_device *dev)
}
-long get_request_value(struct net_device *dev)
+static long get_request_value(struct net_device *dev)
{
struct ft1000_info *info = netdev_priv(dev);
long value;
@@ -244,7 +244,7 @@ long get_request_value(struct net_device *dev)
}
-void put_request_value(struct net_device *dev, long lvalue)
+static void put_request_value(struct net_device *dev, long lvalue)
{
struct ft1000_info *info = netdev_priv(dev);
u16 size;
@@ -271,7 +271,7 @@ void put_request_value(struct net_device *dev, long lvalue)
}
-u16 hdr_checksum(struct pseudo_hdr *pHdr)
+static u16 hdr_checksum(struct pseudo_hdr *pHdr)
{
u16 *usPtr = (u16 *)pHdr;
u16 chksum;
--
1.9.1
--
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] staging: ft1000: warning removal: extern functions to static ones
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 also did not include commit_signer/authored emails) I also did not include triv...@kernel.org this time - wasn't sure is this was trivial enough. Thanks for the feedback! (and sorry for the direct reply - did not intended to be rude) Xavier -- 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/
[PATCH] staging: ft1000: warning removal: extern functions to static ones
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(-)
diff --git a/drivers/staging/ft1000/ft1000-pcmcia/ft1000_dnld.c
b/drivers/staging/ft1000/ft1000-pcmcia/ft1000_dnld.c
index 83683e9..3237ee73 100644
--- a/drivers/staging/ft1000/ft1000-pcmcia/ft1000_dnld.c
+++ b/drivers/staging/ft1000/ft1000-pcmcia/ft1000_dnld.c
@@ -82,12 +82,12 @@
#define STATE_DONE_PROV 0x06
#define STATE_DONE_FILE 0x07
-u16 get_handshake(struct net_device *dev, u16 expected_value);
-void put_handshake(struct net_device *dev, u16 handshake_value);
-u16 get_request_type(struct net_device *dev);
-long get_request_value(struct net_device *dev);
-void put_request_value(struct net_device *dev, long lvalue);
-u16 hdr_checksum(struct pseudo_hdr *pHdr);
+static u16 get_handshake(struct net_device *dev, u16 expected_value);
+static void put_handshake(struct net_device *dev, u16 handshake_value);
+static u16 get_request_type(struct net_device *dev);
+static long get_request_value(struct net_device *dev);
+static void put_request_value(struct net_device *dev, long lvalue);
+static u16 hdr_checksum(struct pseudo_hdr *pHdr);
struct dsp_file_hdr {
u32 version_id;/* Version ID of this image format. */
@@ -146,7 +146,7 @@ void card_bootload(struct net_device *dev)
spin_unlock_irqrestore(info-dpram_lock, flags);
}
-u16 get_handshake(struct net_device *dev, u16 expected_value)
+static u16 get_handshake(struct net_device *dev, u16 expected_value)
{
struct ft1000_info *info = netdev_priv(dev);
u16 handshake;
@@ -180,7 +180,7 @@ u16 get_handshake(struct net_device *dev, u16
expected_value)
}
-void put_handshake(struct net_device *dev, u16 handshake_value)
+static void put_handshake(struct net_device *dev, u16 handshake_value)
{
struct ft1000_info *info = netdev_priv(dev);
u32 tempx;
@@ -196,7 +196,7 @@ void put_handshake(struct net_device *dev, u16
handshake_value)
}
}
-u16 get_request_type(struct net_device *dev)
+static u16 get_request_type(struct net_device *dev)
{
struct ft1000_info *info = netdev_priv(dev);
u16 request_type;
@@ -215,7 +215,7 @@ u16 get_request_type(struct net_device *dev)
}
-long get_request_value(struct net_device *dev)
+static long get_request_value(struct net_device *dev)
{
struct ft1000_info *info = netdev_priv(dev);
long value;
@@ -244,7 +244,7 @@ long get_request_value(struct net_device *dev)
}
-void put_request_value(struct net_device *dev, long lvalue)
+static void put_request_value(struct net_device *dev, long lvalue)
{
struct ft1000_info *info = netdev_priv(dev);
u16 size;
@@ -271,7 +271,7 @@ void put_request_value(struct net_device *dev, long lvalue)
}
-u16 hdr_checksum(struct pseudo_hdr *pHdr)
+static u16 hdr_checksum(struct pseudo_hdr *pHdr)
{
u16 *usPtr = (u16 *)pHdr;
u16 chksum;
--
1.9.1
--
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/
[PATCH] rtl8723au: replaced asm/atomic.h by linux/atomic.h
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 c8119e2..dfdf35a 100644 --- a/drivers/staging/rtl8723au/include/rtw_io.h +++ b/drivers/staging/rtl8723au/include/rtw_io.h @@ -24,7 +24,7 @@ #include /* include */ #include -#include +#include #include #include -- 1.9.1 -- 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/
[PATCH] Replaced #include by #include
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/rtl8723au/include/osdep_service.h index dedb418..98250b1 100644 --- a/drivers/staging/rtl8723au/include/osdep_service.h +++ b/drivers/staging/rtl8723au/include/osdep_service.h @@ -29,10 +29,10 @@ #include #include #include -#include +#include #include -#include -#include +#include +#include #include #include #include -- 1.9.1 -- 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/
[PATCH] Replaced #include asm/(uaccess|atomic|io).h by #include linux/(uaccess|atomic|io).h
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 b/drivers/staging/rtl8723au/include/osdep_service.h index dedb418..98250b1 100644 --- a/drivers/staging/rtl8723au/include/osdep_service.h +++ b/drivers/staging/rtl8723au/include/osdep_service.h @@ -29,10 +29,10 @@ #include linux/kref.h #include linux/netdevice.h #include linux/skbuff.h -#include asm/uaccess.h +#include linux/uaccess.h #include asm/byteorder.h -#include asm/atomic.h -#include asm/io.h +#include linux/atomic.h +#include linux/io.h #include linux/semaphore.h #include linux/sem.h #include linux/sched.h -- 1.9.1 -- 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/
[PATCH] rtl8723au: replaced asm/atomic.h by linux/atomic.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/rtw_io.h index c8119e2..dfdf35a 100644 --- a/drivers/staging/rtl8723au/include/rtw_io.h +++ b/drivers/staging/rtl8723au/include/rtw_io.h @@ -24,7 +24,7 @@ #include linux/list.h /* include linux/smp_lock.h */ #include linux/spinlock.h -#include asm/atomic.h +#include linux/atomic.h #include linux/usb.h #include linux/usb/ch9.h -- 1.9.1 -- 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: sigaction's ucontext_t with incorrect stack reference when SA_SIGINFO is being used ?
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, _user->uc.uc_stack.ss_sp); err |= __put_user(sas_ss_flags(regs->esp), >uc.uc_stack.ss_flags); err |= __put_user(current->sas_ss_size, _user->uc.uc_stack.ss_size); And of course, the ss_sp is NULL when no alternative stack is used. Seems definitively a bug. However, my reading of include/linux/sched.h and thread_info.h did not enlighten me on the way to get the original thread's stack base and size. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sigaction's ucontext_t with incorrect stack reference when SA_SIGINFO is being used ?
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, frame_user-uc.uc_stack.ss_sp); err |= __put_user(sas_ss_flags(regs-esp), frame-uc.uc_stack.ss_flags); err |= __put_user(current-sas_ss_size, frame_user-uc.uc_stack.ss_size); And of course, the ss_sp is NULL when no alternative stack is used. Seems definitively a bug. However, my reading of include/linux/sched.h and thread_info.h did not enlighten me on the way to get the original thread's stack base and size. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
sigaction's ucontext_t with incorrect stack reference when SA_SIGINFO is being used ?
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 was used before the crash.
Is this is a normal behaviour ? Is there a way to retrieve the original
user's stack inside the signal callback ?
The example given below demonstrates the issue:
top of stack==0x7f3d7000, alternative_stack==0x501010
SEGV==0x7f3d6ff8; sp==0x501010; current stack is the alternate stack
It is obvious that the SEGV was a stack overflow: the si_addr address is
just on the page below the stack limit.
/* gcc -g [ -D_REENTRANT ] stacktest.c [ -lpthread ] -o stacktest */
#include
#include
#include
#include
#include
#ifdef _REENTRANT
#include
#endif
/* the alternative stack reference */
static stack_t ss;
/* this function does nasty things */
static void overflow(void) { overflow(); }
/* test entry point */
static void* threadEntry(void* parg) {
struct rlimit rlim;
/* setup alternative strack for the current thread */
ss.ss_flags = 0;
ss.ss_size = SIGSTKSZ;
ss.ss_sp = malloc(ss.ss_size);
if (ss.ss_sp == NULL) {
abort();
}
if (sigaltstack(, NULL) == -1) {
abort();
}
/* print current stack limit */
if (getrlimit(RLIMIT_STACK, ) == 0) {
const unsigned long page_size = (unsigned long) sysconf(_SC_PAGE_SIZE);
const unsigned long stack_bottom =
(((unsigned long)_cur+page_size-1)/page_size)*page_size;
printf("bottom of stack==%p, alternative_stack==%p\n", (void*)stack_bottom,
(void*)ss.ss_sp);
}
/* do something very nasty */
overflow();
/* we may not reach this point */
return NULL;
}
/* SEGV handler */
static void saHandler(int code, siginfo_t *si, void *sc_) {
void *kenny = (void*)
ucontext_t * const sc = (ucontext_t*) sc_;
printf("SEGV==%p; sp==%p; current stack is the %s\n", (void*)si->si_addr,
(void*)((ucontext_t*)sc_)->uc_stack.ss_sp,
( kenny >= ss.ss_sp && kenny < ss.ss_sp + SIGSTKSZ )
? "alternate stack" : "original stack");
abort();
}
/* main entry point */
int main(void) {
/* catch SEGV with SA_ONSTACK enabled */
struct sigaction s;
memset(, 0, sizeof(s));
sigemptyset(_mask);
s.sa_flags = SA_SIGINFO | SA_ONSTACK;
s.sa_sigaction = saHandler;
if(sigaction (SIGSEGV, , NULL)) {
abort();
}
#ifdef _REENTRANT
/* threaded version */
{
pthread_t t;
pthread_create(, NULL, threadEntry, NULL);
pause(); /* wait (almost) endlessly */
}
#else
/* single threaded version */
(void) threadEntry(NULL);
#endif
/* not reached */
abort();
return 0;
}
sigaction's ucontext_t with incorrect stack reference when SA_SIGINFO is being used ?
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 was used before the crash.
Is this is a normal behaviour ? Is there a way to retrieve the original
user's stack inside the signal callback ?
The example given below demonstrates the issue:
top of stack==0x7f3d7000, alternative_stack==0x501010
SEGV==0x7f3d6ff8; sp==0x501010; current stack is the alternate stack
It is obvious that the SEGV was a stack overflow: the si_addr address is
just on the page below the stack limit.
/* gcc -g [ -D_REENTRANT ] stacktest.c [ -lpthread ] -o stacktest */
#include stdio.h
#include stdlib.h
#include unistd.h
#include sys/resource.h
#include sys/ucontext.h
#ifdef _REENTRANT
#include pthread.h
#endif
/* the alternative stack reference */
static stack_t ss;
/* this function does nasty things */
static void overflow(void) { overflow(); }
/* test entry point */
static void* threadEntry(void* parg) {
struct rlimit rlim;
/* setup alternative strack for the current thread */
ss.ss_flags = 0;
ss.ss_size = SIGSTKSZ;
ss.ss_sp = malloc(ss.ss_size);
if (ss.ss_sp == NULL) {
abort();
}
if (sigaltstack(ss, NULL) == -1) {
abort();
}
/* print current stack limit */
if (getrlimit(RLIMIT_STACK, rlim) == 0) {
const unsigned long page_size = (unsigned long) sysconf(_SC_PAGE_SIZE);
const unsigned long stack_bottom =
(((unsigned long)rlim-rlim.rlim_cur+page_size-1)/page_size)*page_size;
printf(bottom of stack==%p, alternative_stack==%p\n, (void*)stack_bottom,
(void*)ss.ss_sp);
}
/* do something very nasty */
overflow();
/* we may not reach this point */
return NULL;
}
/* SEGV handler */
static void saHandler(int code, siginfo_t *si, void *sc_) {
void *kenny = (void*) code;
ucontext_t * const sc = (ucontext_t*) sc_;
printf(SEGV==%p; sp==%p; current stack is the %s\n, (void*)si-si_addr,
(void*)((ucontext_t*)sc_)-uc_stack.ss_sp,
( kenny = ss.ss_sp kenny ss.ss_sp + SIGSTKSZ )
? alternate stack : original stack);
abort();
}
/* main entry point */
int main(void) {
/* catch SEGV with SA_ONSTACK enabled */
struct sigaction s;
memset(s, 0, sizeof(s));
sigemptyset(s.sa_mask);
s.sa_flags = SA_SIGINFO | SA_ONSTACK;
s.sa_sigaction = saHandler;
if(sigaction (SIGSEGV, s, NULL)) {
abort();
}
#ifdef _REENTRANT
/* threaded version */
{
pthread_t t;
pthread_create(t, NULL, threadEntry, NULL);
pause(); /* wait (almost) endlessly */
}
#else
/* single threaded version */
(void) threadEntry(NULL);
#endif
/* not reached */
abort();
return 0;
}
Re: Kernels Out Of Memoy(OOM) killer Problem ?
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 when the system has no memory pages left, and MUST get one to continue normal (ie. kernel) processing. The kernel just do not have the time to execute some user-space code, it MUST get free pages where they are (and hence, kill immediately some innocent process). This condition should not occur without using overcommit. Are you sure you are not using overcommit ? (cat /proc/sys/vm/overcommit_memory) To dasable it: echo 0 > /proc/sys/vm/overcommit_memory Overcommit is quite dangerous on production systems, because it leads to oom kills on heavy loads (at least, this is what I experienced). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernels Out Of Memoy(OOM) killer Problem ?
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 when the system has no memory pages left, and MUST get one to continue normal (ie. kernel) processing. The kernel just do not have the time to execute some user-space code, it MUST get free pages where they are (and hence, kill immediately some innocent process). This condition should not occur without using overcommit. Are you sure you are not using overcommit ? (cat /proc/sys/vm/overcommit_memory) To dasable it: echo 0 /proc/sys/vm/overcommit_memory Overcommit is quite dangerous on production systems, because it leads to oom kills on heavy loads (at least, this is what I experienced). - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[reiserfs] exception/panic while trying to write data
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 have
screwed up during the reboot), but the filesystem was ok before that (no
errors at all), no disk (hardware) errors reported anywhere, no "brutal"
power off or anything that could explain the problem. But INN was
running on this fs, with some important load (many read/write
operations, continuously)
I had to fsck.reiserfs --rebuild-tree the disk, but unfortunately many
files were screwed up (blocks from other files before other files)
Here are the relevant entries related to reiserfs in the kernel log: (..
for log cuts) - I did not find any other clear references of the
problem. If anyone gets any hints, he's welcome!
System: Linux 2.6.7-grsec #1 SMP i686
Disk: Maxtor 6Y080P0, ATA DISK drive, on a IDE Promise Technology, Inc.
20269 (rev 02)
Aug 8 16:37:46 linux kernel: ReiserFS: hdh1: found reiserfs format
"3.6" with standard journal
Aug 8 16:37:46 linux kernel: ReiserFS: hdh1: using ordered data mode
Aug 8 16:37:46 linux kernel: ReiserFS: hdh1: journal params: device
hdh1, size 8192, journal first block 18, max trans len 1024, max batch
900, max commit age 30, max trans age 30
Aug 8 16:37:46 linux kernel: ReiserFS: hdh1: checking transaction log
(hdh1)
Aug 8 16:37:46 linux kernel: ReiserFS: hdh1: Using r5 hash to sort names
..
Aug 8 16:38:04 linux kernel: [ cut here ]
Aug 8 16:38:04 linux kernel: SMP
Aug 8 16:38:04 linux kernel: Modules linked in: agpgart 3c59x ns83820
md5 ipv6 reiserfs 8250 serial_core w83781d i2c_sensor i2c_isa i2c_viapro
i2c_dev i2c_core softdog
Aug 8 16:38:04 linux kernel: CPU:0
Aug 8 16:38:04 linux kernel: EIP:0060:[pg0+809516114/1068598272]
Not tainted VLI
Aug 8 16:38:04 linux kernel: EFLAGS: 00010286 (2.6.11.12-grsec)
Aug 8 16:38:04 linux kernel: EIP is at reiserfs_in_journal+0x142/0x1b0
[reiserfs]
Aug 8 16:38:04 linux kernel: eax: f0905f30 ebx: 00cf ecx:
1a64 edx: f0881000
Aug 8 16:38:04 linux kernel: esi: ef0e0e00 edi: f0881114 ebp:
esp: eb571bc0
Aug 8 16:38:04 linux kernel: ds: 007b es: 007b ss: 0068
Aug 8 16:38:04 linux kernel: Process innd (pid: 13370,
threadinfo=eb57 task=eb519550)
Aug 8 16:38:04 linux kernel: Stack: c023b122 0172 c02a3f5e f0881000
f0848cf0 ef0e0e00 eb571c4c
Aug 8 16:38:04 linux kernel:f08c629f ef0e0e00 019e
0001 eb571c00 c04d63b8
Aug 8 16:38:04 linux kernel: 019e ef0e0e00 eb571c4c
f08c659a eb571eb0 019e
Aug 8 16:38:04 linux kernel: Call Trace:
Aug 8 16:38:04 linux kernel: [__delay+18/32] __delay+0x12/0x20
Aug 8 16:38:04 linux kernel: [ide_execute_command+158/192]
ide_execute_command+0x9e/0xc0
Aug 8 16:38:04 linux kernel: [pg0+809370271/1068598272]
scan_bitmap_block+0x29f/0x330 [reiserfs]
Aug 8 16:38:04 linux kernel: [pg0+809371034/1068598272]
scan_bitmap+0x16a/0x280 [reiserfs]
Aug 8 16:38:04 linux kernel: [pg0+809375942/1068598272]
reiserfs_allocate_blocknrs+0x196/0x510 [reiserfs]
Aug 8 16:38:04 linux kernel: [pg0+809427645/1068598272]
reiserfs_allocate_blocks_for_region+0x24d/0x1640 [reiserfs]
Aug 8 16:38:04 linux kernel: [__wait_on_bit+81/112]
__wait_on_bit+0x51/0x70
Aug 8 16:38:04 linux kernel: [sync_buffer+0/80] sync_buffer+0x0/0x50
Aug 8 16:38:04 linux kernel: [sync_buffer+0/80] sync_buffer+0x0/0x50
Aug 8 16:38:04 linux kernel: [out_of_line_wait_on_bit+147/160]
out_of_line_wait_on_bit+0x93/0xa0
Aug 8 16:38:04 linux kernel: [wake_bit_function+0/96]
wake_bit_function+0x0/0x60
Aug 8 16:38:04 linux kernel: [pg0+809436082/1068598272]
reiserfs_prepare_file_region_for_write+0x522/0x940 [reiserfs]
Aug 8 16:38:04 linux kernel: [pg0+809438855/1068598272]
reiserfs_file_write+0x6b7/0x6d0 [reiserfs]
Aug 8 16:38:04 linux kernel: [__posix_lock_file+/1600]
__posix_lock_file+0x457/0x640
Aug 8 16:38:04 linux kernel: [may_open+94/544] may_open+0x5e/0x220
Aug 8 16:38:04 linux kernel: [fcntl_setlk+283/720] fcntl_setlk+0x11b/0x2d0
Aug 8 16:38:04 linux kernel: [get_empty_filp+195/272]
get_empty_filp+0xc3/0x110
Aug 8 16:38:04 linux kernel: [file_move+32/96] file_move+0x20/0x60
Aug 8 16:38:04 linux kernel: [dentry_open+235/512] dentry_open+0xeb/0x200
Aug 8 16:38:04 linux kernel: [_atomic_dec_and_lock+49/80]
_atomic_dec_and_lock+0x31/0x50
Aug 8 16:38:04 linux kernel: [dput+338/464] dput+0x152/0x1d0
Aug 8 16:38:04 linux kernel: [vfs_write+174/304] vfs_write+0xae/0x130
Aug 8 16:38:04 linux kernel: [sys_write+81/128] sys_write+0x51/0x80
Aug 8 16:38:04 linux kernel: [syscall_call+7/11] syscall_call+0x7/0xb
Aug 8 16:38:04 linux kernel: [ip_rt_init+139/960] ip_rt_init+0x8b/0x3c0
Aug 8 16:38:04 linux kernel: Code:
[reiserfs] exception/panic while trying to write data
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 have screwed up during the reboot), but the filesystem was ok before that (no errors at all), no disk (hardware) errors reported anywhere, no brutal power off or anything that could explain the problem. But INN was running on this fs, with some important load (many read/write operations, continuously) I had to fsck.reiserfs --rebuild-tree the disk, but unfortunately many files were screwed up (blocks from other files before other files) Here are the relevant entries related to reiserfs in the kernel log: (.. for log cuts) - I did not find any other clear references of the problem. If anyone gets any hints, he's welcome! System: Linux 2.6.7-grsec #1 SMP i686 Disk: Maxtor 6Y080P0, ATA DISK drive, on a IDE Promise Technology, Inc. 20269 (rev 02) Aug 8 16:37:46 linux kernel: ReiserFS: hdh1: found reiserfs format 3.6 with standard journal Aug 8 16:37:46 linux kernel: ReiserFS: hdh1: using ordered data mode Aug 8 16:37:46 linux kernel: ReiserFS: hdh1: journal params: device hdh1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 Aug 8 16:37:46 linux kernel: ReiserFS: hdh1: checking transaction log (hdh1) Aug 8 16:37:46 linux kernel: ReiserFS: hdh1: Using r5 hash to sort names .. Aug 8 16:38:04 linux kernel: [ cut here ] Aug 8 16:38:04 linux kernel: SMP Aug 8 16:38:04 linux kernel: Modules linked in: agpgart 3c59x ns83820 md5 ipv6 reiserfs 8250 serial_core w83781d i2c_sensor i2c_isa i2c_viapro i2c_dev i2c_core softdog Aug 8 16:38:04 linux kernel: CPU:0 Aug 8 16:38:04 linux kernel: EIP:0060:[pg0+809516114/1068598272] Not tainted VLI Aug 8 16:38:04 linux kernel: EFLAGS: 00010286 (2.6.11.12-grsec) Aug 8 16:38:04 linux kernel: EIP is at reiserfs_in_journal+0x142/0x1b0 [reiserfs] Aug 8 16:38:04 linux kernel: eax: f0905f30 ebx: 00cf ecx: 1a64 edx: f0881000 Aug 8 16:38:04 linux kernel: esi: ef0e0e00 edi: f0881114 ebp: esp: eb571bc0 Aug 8 16:38:04 linux kernel: ds: 007b es: 007b ss: 0068 Aug 8 16:38:04 linux kernel: Process innd (pid: 13370, threadinfo=eb57 task=eb519550) Aug 8 16:38:04 linux kernel: Stack: c023b122 0172 c02a3f5e f0881000 f0848cf0 ef0e0e00 eb571c4c Aug 8 16:38:04 linux kernel:f08c629f ef0e0e00 019e 0001 eb571c00 c04d63b8 Aug 8 16:38:04 linux kernel: 019e ef0e0e00 eb571c4c f08c659a eb571eb0 019e Aug 8 16:38:04 linux kernel: Call Trace: Aug 8 16:38:04 linux kernel: [__delay+18/32] __delay+0x12/0x20 Aug 8 16:38:04 linux kernel: [ide_execute_command+158/192] ide_execute_command+0x9e/0xc0 Aug 8 16:38:04 linux kernel: [pg0+809370271/1068598272] scan_bitmap_block+0x29f/0x330 [reiserfs] Aug 8 16:38:04 linux kernel: [pg0+809371034/1068598272] scan_bitmap+0x16a/0x280 [reiserfs] Aug 8 16:38:04 linux kernel: [pg0+809375942/1068598272] reiserfs_allocate_blocknrs+0x196/0x510 [reiserfs] Aug 8 16:38:04 linux kernel: [pg0+809427645/1068598272] reiserfs_allocate_blocks_for_region+0x24d/0x1640 [reiserfs] Aug 8 16:38:04 linux kernel: [__wait_on_bit+81/112] __wait_on_bit+0x51/0x70 Aug 8 16:38:04 linux kernel: [sync_buffer+0/80] sync_buffer+0x0/0x50 Aug 8 16:38:04 linux kernel: [sync_buffer+0/80] sync_buffer+0x0/0x50 Aug 8 16:38:04 linux kernel: [out_of_line_wait_on_bit+147/160] out_of_line_wait_on_bit+0x93/0xa0 Aug 8 16:38:04 linux kernel: [wake_bit_function+0/96] wake_bit_function+0x0/0x60 Aug 8 16:38:04 linux kernel: [pg0+809436082/1068598272] reiserfs_prepare_file_region_for_write+0x522/0x940 [reiserfs] Aug 8 16:38:04 linux kernel: [pg0+809438855/1068598272] reiserfs_file_write+0x6b7/0x6d0 [reiserfs] Aug 8 16:38:04 linux kernel: [__posix_lock_file+/1600] __posix_lock_file+0x457/0x640 Aug 8 16:38:04 linux kernel: [may_open+94/544] may_open+0x5e/0x220 Aug 8 16:38:04 linux kernel: [fcntl_setlk+283/720] fcntl_setlk+0x11b/0x2d0 Aug 8 16:38:04 linux kernel: [get_empty_filp+195/272] get_empty_filp+0xc3/0x110 Aug 8 16:38:04 linux kernel: [file_move+32/96] file_move+0x20/0x60 Aug 8 16:38:04 linux kernel: [dentry_open+235/512] dentry_open+0xeb/0x200 Aug 8 16:38:04 linux kernel: [_atomic_dec_and_lock+49/80] _atomic_dec_and_lock+0x31/0x50 Aug 8 16:38:04 linux kernel: [dput+338/464] dput+0x152/0x1d0 Aug 8 16:38:04 linux kernel: [vfs_write+174/304] vfs_write+0xae/0x130 Aug 8 16:38:04 linux kernel: [sys_write+81/128] sys_write+0x51/0x80 Aug 8 16:38:04 linux kernel: [syscall_call+7/11] syscall_call+0x7/0xb Aug 8 16:38:04 linux kernel: [ip_rt_init+139/960] ip_rt_init+0x8b/0x3c0 Aug 8 16:38:04 linux kernel: Code: e9 07
Timestamp of file modified through mmap are not changed in 2.6
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 reproduce the bug (you need to create a "test" file
in the current directory first):
#include
#include
#include
#include
#include
int main(void) {
int fd = open("test", O_RDWR);
struct stat st;
char* file;
if (fd == -1) {
printf("error opening file\n");
return 1;
}
if (fstat(fd, ) != 0) {
printf("error fstating file\n");
return 1;
}
if (st.st_size == 0) {
printf("error empty file\n");
return 1;
}
printf("Modified date before change: %u\n", st.st_mtime);
file = mmap(NULL, st.st_size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
if (file == NULL) {
printf("error mmaping file");
return 1;
}
file[0] = file[0] + 1;
if (msync((void*) file, st.st_size, MS_SYNC) != 0) {
printf("error syncing file");
return 1;
}
if (munmap(file, st.st_size) != 0) {
printf("error closing file");
return 1;
}
if (fstat(fd, ) != 0) {
printf("error fstating file\n");
return 1;
}
printf("Modified date after change: %u\n", st.st_mtime);
return 0;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Timestamp of file modified through mmap are not changed in 2.6
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 reproduce the bug (you need to create a test file
in the current directory first):
#include sys/mman.h
#include sys/types.h
#include sys/stat.h
#include unistd.h
#include fcntl.h
int main(void) {
int fd = open(test, O_RDWR);
struct stat st;
char* file;
if (fd == -1) {
printf(error opening file\n);
return 1;
}
if (fstat(fd, st) != 0) {
printf(error fstating file\n);
return 1;
}
if (st.st_size == 0) {
printf(error empty file\n);
return 1;
}
printf(Modified date before change: %u\n, st.st_mtime);
file = mmap(NULL, st.st_size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
if (file == NULL) {
printf(error mmaping file);
return 1;
}
file[0] = file[0] + 1;
if (msync((void*) file, st.st_size, MS_SYNC) != 0) {
printf(error syncing file);
return 1;
}
if (munmap(file, st.st_size) != 0) {
printf(error closing file);
return 1;
}
if (fstat(fd, st) != 0) {
printf(error fstating file\n);
return 1;
}
printf(Modified date after change: %u\n, st.st_mtime);
return 0;
}
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
bad block locks IDE on 2.2.18?
Hi,
I have a bad drive, with many bad blocks, as many other people have.
But my problem is not bad blocks, but system crash when detecting one of
these bad blocks.
The drive is hdb(1), an ide 3.8gb disk. The kernel used is a regular
2.2.18 kernel. I didn't see any hints on the kernel ChangeLog, so
I'm posting here.
When I try to run "e2fsck -f -c -v /dev/hdb1" or even "badblocks -b 4096
-s /dev/hdb1 938448", I get many "end_request: I/O error" errors (this is
perfectly normal, ad the drive is really bad)
But unfortunalely, at approx. sector 7459480, the system just hangs
without any syslog message.
It seems that the bad block reached just crashed the IDE subsystem (!),
even if the kernel is still running (I can ping the machine, I can type
the ENTER key in the console with an echo, until I launch a systemcommand,
which hangs the console. All IDE I/O seems frozen.)
Jun 25 11:46:26 linux kernel: end_request: I/O error, dev 03:41 (hdb),
sector 7459440
Jun 25 11:46:26 linux kernel: hdb: read_intr: status=0x59 { DriveReady
SeekComplete DataRequest Error }
Jun 25 11:46:29 linux kernel: hdb: read_intr: error=0x40 {
UncorrectableError }, LBAsect=7491696, sector=7459440
Jun 25 11:46:31 linux kernel: end_request: I/O error, dev 03:41 (hdb),
sector 7459440
Jun 25 11:46:32 linux kernel: hdb: read_intr: status=0x59 { DriveReady
SeekComplete DataRequest Error }
Jun 25 11:46:32 linux kernel: hdb: read_intr: error=0x40 {
UncorrectableError }, LBAsect=7491736, sector=7459480
Jun 25 11:46:33 linux kernel: end_request: I/O error, dev 03:41 (hdb),
sector 7459480
Jun 25 11:46:38 linux kernel: hdb: read_intr: status=0x59 { DriveReady
SeekComplete DataRequest Error }
Jun 25 11:46:39 linux kernel: hdb: read_intr: error=0x40 {
UncorrectableError }, LBAsect=7491736, sector=7459480
And of course, I have to reboot (power off/on)
Jun 25 11:59:42 linux syslogd 1.3-3: restart.
I know that the drive is bad, and can not be repaired, and I only use it
as "garbage store".
But the strange thing here is that once the bad block has been reached on
this drive, the 3 other IDE drives are unreachable, "frozen"
Model: QUANTUM FIREBALL_TM3840A
Geometry: physical 7480/16/63, logical 935/128/63
Capacity: 7539840 (3.8Gb)
Details on settings:
bios_cyl935 0 65535 rw
bios_head 128 0 255 rw
bios_sect 63 0 63 rw
breada_readahead4 0 127 rw
bswap 0 0 1 r
file_readahead 124 0 2097151 rw
io_32bit0 0 3 rw
keepsettings0 0 1 rw
max_kb_per_request 64 1 127 rw
multcount 0 0 8 rw
nice1 1 0 1 rw
nowerr 0 0 1 rw
pio_modewrite-only 0 255 w
slow0 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-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
bad block locks IDE on 2.2.18?
Hi,
I have a bad drive, with many bad blocks, as many other people have.
But my problem is not bad blocks, but system crash when detecting one of
these bad blocks.
The drive is hdb(1), an ide 3.8gb disk. The kernel used is a regular
2.2.18 kernel. I didn't see any hints on the kernel ChangeLog, so
I'm posting here.
When I try to run e2fsck -f -c -v /dev/hdb1 or even badblocks -b 4096
-s /dev/hdb1 938448, I get many end_request: I/O error errors (this is
perfectly normal, ad the drive is really bad)
But unfortunalely, at approx. sector 7459480, the system just hangs
without any syslog message.
It seems that the bad block reached just crashed the IDE subsystem (!),
even if the kernel is still running (I can ping the machine, I can type
the ENTER key in the console with an echo, until I launch a systemcommand,
which hangs the console. All IDE I/O seems frozen.)
Jun 25 11:46:26 linux kernel: end_request: I/O error, dev 03:41 (hdb),
sector 7459440
Jun 25 11:46:26 linux kernel: hdb: read_intr: status=0x59 { DriveReady
SeekComplete DataRequest Error }
Jun 25 11:46:29 linux kernel: hdb: read_intr: error=0x40 {
UncorrectableError }, LBAsect=7491696, sector=7459440
Jun 25 11:46:31 linux kernel: end_request: I/O error, dev 03:41 (hdb),
sector 7459440
Jun 25 11:46:32 linux kernel: hdb: read_intr: status=0x59 { DriveReady
SeekComplete DataRequest Error }
Jun 25 11:46:32 linux kernel: hdb: read_intr: error=0x40 {
UncorrectableError }, LBAsect=7491736, sector=7459480
Jun 25 11:46:33 linux kernel: end_request: I/O error, dev 03:41 (hdb),
sector 7459480
Jun 25 11:46:38 linux kernel: hdb: read_intr: status=0x59 { DriveReady
SeekComplete DataRequest Error }
Jun 25 11:46:39 linux kernel: hdb: read_intr: error=0x40 {
UncorrectableError }, LBAsect=7491736, sector=7459480
And of course, I have to reboot (power off/on)
Jun 25 11:59:42 linux syslogd 1.3-3: restart.
I know that the drive is bad, and can not be repaired, and I only use it
as garbage store.
But the strange thing here is that once the bad block has been reached on
this drive, the 3 other IDE drives are unreachable, frozen
Model: QUANTUM FIREBALL_TM3840A
Geometry: physical 7480/16/63, logical 935/128/63
Capacity: 7539840 (3.8Gb)
Details on settings:
bios_cyl935 0 65535 rw
bios_head 128 0 255 rw
bios_sect 63 0 63 rw
breada_readahead4 0 127 rw
bswap 0 0 1 r
file_readahead 124 0 2097151 rw
io_32bit0 0 3 rw
keepsettings0 0 1 rw
max_kb_per_request 64 1 127 rw
multcount 0 0 8 rw
nice1 1 0 1 rw
nowerr 0 0 1 rw
pio_modewrite-only 0 255 w
slow0 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-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
