Re: WARNING: filesystem loop0 was created with 512 inodes, the real maximum is 511, mounting anyway
On Mon, 28 Sep 2020 at 09:29, Dmitry Vyukov wrote:
> On Mon, Sep 28, 2020 at 10:23 AM Tigran Aivazian
> > No, this is not an issue. In the latest change to BFS I added the
> > following comment to the header fs/bfs/bfs.h, which explains it:
> >
> > /* In theory BFS supports up to 512 inodes, numbered from 2 (for /) up
> > to 513 inclusive.
> >In actual fact, attempting to create the 512th inode (i.e. inode
> > No. 513 or file No. 511)
> >will fail with ENOSPC in bfs_add_entry(): the root directory cannot
> > contain so many entries, counting '..'.
> >So, mkfs.bfs(8) should really limit its -N option to 511 and not
> > 512. For now, we just print a warning
> >if a filesystem is mounted with such "impossible to fill up" number
> > of inodes */
>
> There are rules for use of "WARNING" in output required to support
> kernel testing:
> https://github.com/torvalds/linux/blob/master/include/asm-generic/bug.h#L67-L80
> This seems to be triggerable by exteranal inputs and breaks these rules.
Thank you, I didn't know about these rules. Ok, then, since this
warning does not "need prompt attention if it should ever occur at
runtime", the easiest solution is to change "WARNING" to lower case
"warning" in that printk in fs/bfs/inode.c:
--- fs/bfs/inode.c.0 2020-09-28 10:03:00.658549556 +0100
+++ fs/bfs/inode.c 2020-09-28 10:03:05.408548250 +0100
@@ -351,7 +351,7 @@
info->si_lasti = (le32_to_cpu(bfs_sb->s_start) - BFS_BSIZE) /
sizeof(struct bfs_inode) + BFS_ROOT_INO - 1;
if (info->si_lasti == BFS_MAX_LASTI)
- printf("WARNING: filesystem %s was created with 512 inodes, the real
maximum is 511, mounting anyway\n", s->s_id);
+ printf("warning: filesystem %s was created with 512 inodes, the real
maximum is 511, mounting anyway\n", s->s_id);
else if (info->si_lasti > BFS_MAX_LASTI) {
printf("Impossible last inode number %lu > %d on %s\n",
info->si_lasti, BFS_MAX_LASTI, s->s_id);
goto out1;
If you want to submit this patch to the appropriate place(s), feel
free to do this -- I approve it. If the comment in asm/bug.h is
inaccurate and its mention of "BUG/WARNING" implies the lowercase
"bug/warning" also, then one can remove the prefix "warning: " from
the patch altogether and proper case "filesystem" to "Filesystem".
Kind regards,
Tigran
Acked-By: Tigran Aivazian
Approved-By: Tigran Aivazian
Re: WARNING: filesystem loop0 was created with 512 inodes, the real maximum is 511, mounting anyway
Hello Dmitry, On Mon, 28 Sep 2020 at 08:51, Dmitry Vyukov wrote: > On Mon, Sep 28, 2020 at 9:48 AM syzbot > wrote: > > BFS-fs: bfs_fill_super(): WARNING: filesystem loop0 was created with 512 > > inodes, the real maximum is 511, mounting anyway > > This looks like a BFS issue. +BFS maintainers. No, this is not an issue. In the latest change to BFS I added the following comment to the header fs/bfs/bfs.h, which explains it: /* In theory BFS supports up to 512 inodes, numbered from 2 (for /) up to 513 inclusive. In actual fact, attempting to create the 512th inode (i.e. inode No. 513 or file No. 511) will fail with ENOSPC in bfs_add_entry(): the root directory cannot contain so many entries, counting '..'. So, mkfs.bfs(8) should really limit its -N option to 511 and not 512. For now, we just print a warning if a filesystem is mounted with such "impossible to fill up" number of inodes */ Kind regards, Tigran
Re: [PATCH v8 06/20] fs: Fill in max and min timestamps in superblock
I see no problems for BFS. Acked-By: Tigran Aivazian
Re: [patch set 4.19.6] BFS updates
Re-sending the patches with the "Cc: sta...@vger.kernel.org" included
in the sign-off area, as per Option 1 of the rules Greg referred me
to. I hope that now I have done everything by the rules.
On Sun, 2 Dec 2018 at 21:42, Tigran Aivazian wrote:
>
> just wanted to add: although the subject says "4.19.6" the patches
> apply perfectly to the top of "torvalds/linux" tree from github.
> On Sun, 2 Dec 2018 at 21:01, Tigran Aivazian
> wrote:
> >
> > Hi Linus,
> >
> > I attached two incremental patches for BFS:
> >
> > 1. Make inode bitmap allocation static (applies on top of 4.19.6)
> > 2. Strengthen the superblock sanity checking code (applies on top of 1.
> > above)
> >
> > Kind regards,
> > Tigran
From: Tigran Aivazian
Subject: [PATCH 4.19.6 1/2] BFS updates
Make in-core inode bitmap static part of superblock info structure an.
print a warning when mounting a BFS filesystem created with "-N 512"
option as only 510 files can be created in the root directory.
Signed-off-by: Tigran Aivazian
Cc: sta...@vger.kernel.org
---
bfs.h |9 -
inode.c | 27 +++
2 files changed, 19 insertions(+), 17 deletions(-)
--- fs/bfs/bfs.h.0 2018-12-02 20:33:02.252710291 +
+++ fs/bfs/bfs.h 2018-12-02 20:34:34.041246489 +
@@ -8,6 +8,13 @@
#include
+/* In theory BFS supports up to 512 inodes, numbered from 2 (for /) up to 513 inclusive.
+ In actual fact, attempting to create the 512th inode (i.e. inode No. 513 or file No. 511)
+ will fail with ENOSPC in bfs_add_entry(): the root directory cannot contain so many entries, counting '..'.
+ So, mkfs.bfs(8) should really limit its -N option to 511 and not 512. For now, we just print a warning
+ if a filesystem is mounted with such "impossible to fill up" number of inodes */
+#define BFS_MAX_LASTI 513
+
/*
* BFS file system in-core superblock info
*/
@@ -17,7 +24,7 @@
unsigned long si_freei;
unsigned long si_lf_eblk;
unsigned long si_lasti;
- unsigned long *si_imap;
+ DECLARE_BITMAP(si_imap, BFS_MAX_LASTI+1);
struct mutex bfs_lock;
};
--- fs/bfs/inode.c.0 2018-12-02 20:34:03.211740877 +
+++ fs/bfs/inode.c 2018-12-02 20:36:54.508963813 +
@@ -214,7 +214,6 @@
return;
mutex_destroy(&info->bfs_lock);
- kfree(info->si_imap);
kfree(info);
s->s_fs_info = NULL;
}
@@ -322,7 +321,7 @@
struct buffer_head *bh, *sbh;
struct bfs_super_block *bfs_sb;
struct inode *inode;
- unsigned i, imap_len;
+ unsigned i;
struct bfs_sb_info *info;
int ret = -EINVAL;
unsigned long i_sblock, i_eblock, i_eoff, s_size;
@@ -356,13 +355,11 @@
goto out1;
}
- info->si_lasti = (le32_to_cpu(bfs_sb->s_start) - BFS_BSIZE) /
- sizeof(struct bfs_inode)
- + BFS_ROOT_INO - 1;
- imap_len = (info->si_lasti / 8) + 1;
- info->si_imap = kzalloc(imap_len, GFP_KERNEL | __GFP_NOWARN);
- if (!info->si_imap) {
- printf("Cannot allocate %u bytes\n", imap_len);
+ info->si_lasti = (le32_to_cpu(bfs_sb->s_start) - BFS_BSIZE) / sizeof(struct bfs_inode) + BFS_ROOT_INO - 1;
+ if (info->si_lasti == BFS_MAX_LASTI)
+ printf("WARNING: filesystem %s was created with 512 inodes, the real maximum is 511, mounting anyway\n", s->s_id);
+ else if (info->si_lasti > BFS_MAX_LASTI) {
+ printf("Impossible last inode number %lu > %d on %s\n", info->si_lasti, BFS_MAX_LASTI, s->s_id);
goto out1;
}
for (i = 0; i < BFS_ROOT_INO; i++)
@@ -372,12 +369,12 @@
inode = bfs_iget(s, BFS_ROOT_INO);
if (IS_ERR(inode)) {
ret = PTR_ERR(inode);
- goto out2;
+ goto out1;
}
s->s_root = d_make_root(inode);
if (!s->s_root) {
ret = -ENOMEM;
- goto out2;
+ goto out1;
}
info->si_blocks = (le32_to_cpu(bfs_sb->s_end) + 1) >> BFS_BSIZE_BITS;
@@ -391,7 +388,7 @@
if (!bh) {
printf("Last block not available: %lu\n", info->si_blocks - 1);
ret = -EIO;
- goto out3;
+ goto out2;
}
brelse(bh);
@@ -429,7 +426,7 @@
brelse(bh);
ret = -EIO;
- goto out3;
+ goto out2;
}
if (!di->i_ino) {
@@ -448,11 +445,9 @@
bfs_dump_imap("read_super", s);
return 0;
-out3:
+out2:
dput(s->s_root);
s->s_root = NULL;
-out2:
- kfree(info->si_imap);
out1:
brelse(sbh);
out:
From: Tigran Aivazian
Subject: [PATCH 4.19.6 2/2] BFS updates
Strengthen the superblock sanity checking (supersedes the code
that went into 4.19.6).
Signed-off-by: Tigran Aivazian
Cc: sta...@vger.kernel.org
---
inode.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- fs/bfs/inode.c.0 2018-12-02 20:49:00.525461354 +
+++ fs/bfs/inode.c 2018-12-02 20:49:51.054686779 +
@@ -350,7 +350,7 @@
s->s_magic = BFS_MAGIC;
if (le32_to_cpu(bfs_sb->s_start) > le32_to_cpu(bfs_sb->s_end) ||
- le32_to_cpu(bfs_sb->s_start) < BFS_BSIZE) {
+ le32_to_cpu(bfs_sb->s_start) < sizeof(struct bfs_super_block) + sizeof(struct bfs_dirent)) {
printf("Superblock is corrupted\n");
goto out1;
}
Re: [patch set 4.19.6] BFS updates
just wanted to add: although the subject says "4.19.6" the patches apply perfectly to the top of "torvalds/linux" tree from github. On Sun, 2 Dec 2018 at 21:01, Tigran Aivazian wrote: > > Hi Linus, > > I attached two incremental patches for BFS: > > 1. Make inode bitmap allocation static (applies on top of 4.19.6) > 2. Strengthen the superblock sanity checking code (applies on top of 1. above) > > Kind regards, > Tigran
[patch set 4.19.6] BFS updates
Hi Linus,
I attached two incremental patches for BFS:
1. Make inode bitmap allocation static (applies on top of 4.19.6)
2. Strengthen the superblock sanity checking code (applies on top of 1. above)
Kind regards,
Tigran
From: Tigran Aivazian
Subject: [PATCH 4.19.6 1/2] BFS updates
Make in-core inode bitmap static part of superblock info structure an.
print a warning when mounting a BFS filesystem created with "-N 512"
option as only 510 files can be created in the root directory.
Signed-off-by: Tigran Aivazian
---
bfs.h |9 -
inode.c | 27 +++
2 files changed, 19 insertions(+), 17 deletions(-)
--- fs/bfs/bfs.h.0 2018-12-02 20:33:02.252710291 +
+++ fs/bfs/bfs.h 2018-12-02 20:34:34.041246489 +
@@ -8,6 +8,13 @@
#include
+/* In theory BFS supports up to 512 inodes, numbered from 2 (for /) up to 513 inclusive.
+ In actual fact, attempting to create the 512th inode (i.e. inode No. 513 or file No. 511)
+ will fail with ENOSPC in bfs_add_entry(): the root directory cannot contain so many entries, counting '..'.
+ So, mkfs.bfs(8) should really limit its -N option to 511 and not 512. For now, we just print a warning
+ if a filesystem is mounted with such "impossible to fill up" number of inodes */
+#define BFS_MAX_LASTI 513
+
/*
* BFS file system in-core superblock info
*/
@@ -17,7 +24,7 @@
unsigned long si_freei;
unsigned long si_lf_eblk;
unsigned long si_lasti;
- unsigned long *si_imap;
+ DECLARE_BITMAP(si_imap, BFS_MAX_LASTI+1);
struct mutex bfs_lock;
};
--- fs/bfs/inode.c.0 2018-12-02 20:34:03.211740877 +
+++ fs/bfs/inode.c 2018-12-02 20:36:54.508963813 +
@@ -214,7 +214,6 @@
return;
mutex_destroy(&info->bfs_lock);
- kfree(info->si_imap);
kfree(info);
s->s_fs_info = NULL;
}
@@ -322,7 +321,7 @@
struct buffer_head *bh, *sbh;
struct bfs_super_block *bfs_sb;
struct inode *inode;
- unsigned i, imap_len;
+ unsigned i;
struct bfs_sb_info *info;
int ret = -EINVAL;
unsigned long i_sblock, i_eblock, i_eoff, s_size;
@@ -356,13 +355,11 @@
goto out1;
}
- info->si_lasti = (le32_to_cpu(bfs_sb->s_start) - BFS_BSIZE) /
- sizeof(struct bfs_inode)
- + BFS_ROOT_INO - 1;
- imap_len = (info->si_lasti / 8) + 1;
- info->si_imap = kzalloc(imap_len, GFP_KERNEL | __GFP_NOWARN);
- if (!info->si_imap) {
- printf("Cannot allocate %u bytes\n", imap_len);
+ info->si_lasti = (le32_to_cpu(bfs_sb->s_start) - BFS_BSIZE) / sizeof(struct bfs_inode) + BFS_ROOT_INO - 1;
+ if (info->si_lasti == BFS_MAX_LASTI)
+ printf("WARNING: filesystem %s was created with 512 inodes, the real maximum is 511, mounting anyway\n", s->s_id);
+ else if (info->si_lasti > BFS_MAX_LASTI) {
+ printf("Impossible last inode number %lu > %d on %s\n", info->si_lasti, BFS_MAX_LASTI, s->s_id);
goto out1;
}
for (i = 0; i < BFS_ROOT_INO; i++)
@@ -372,12 +369,12 @@
inode = bfs_iget(s, BFS_ROOT_INO);
if (IS_ERR(inode)) {
ret = PTR_ERR(inode);
- goto out2;
+ goto out1;
}
s->s_root = d_make_root(inode);
if (!s->s_root) {
ret = -ENOMEM;
- goto out2;
+ goto out1;
}
info->si_blocks = (le32_to_cpu(bfs_sb->s_end) + 1) >> BFS_BSIZE_BITS;
@@ -391,7 +388,7 @@
if (!bh) {
printf("Last block not available: %lu\n", info->si_blocks - 1);
ret = -EIO;
- goto out3;
+ goto out2;
}
brelse(bh);
@@ -429,7 +426,7 @@
brelse(bh);
ret = -EIO;
- goto out3;
+ goto out2;
}
if (!di->i_ino) {
@@ -448,11 +445,9 @@
bfs_dump_imap("read_super", s);
return 0;
-out3:
+out2:
dput(s->s_root);
s->s_root = NULL;
-out2:
- kfree(info->si_imap);
out1:
brelse(sbh);
out:
From: Tigran Aivazian
Subject: [PATCH 4.19.6 2/2] BFS updates
Strengthen the superblock sanity checking (supersedes the code
that went into 4.19.6).
Signed-off-by: Tigran Aivazian
---
inode.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- fs/bfs/inode.c.0 2018-12-02 20:49:00.525461354 +
+++ fs/bfs/inode.c 2018-12-02 20:49:51.054686779 +
@@ -350,7 +350,7 @@
s->s_magic = BFS_MAGIC;
if (le32_to_cpu(bfs_sb->s_start) > le32_to_cpu(bfs_sb->s_end) ||
- le32_to_cpu(bfs_sb->s_start) < BFS_BSIZE) {
+ le32_to_cpu(bfs_sb->s_start) < sizeof(struct bfs_super_block) + sizeof(struct bfs_dirent)) {
printf("Superblock is corrupted\n");
goto out1;
}
Re: [PATCH 4.19.6] BFS: static inode bitmap and extra sanity checking
On Sun, 2 Dec 2018 at 20:13, Greg KH wrote: > What is the git commit id of this patch in Linus's tree? In linux-next the commit id is d2e6681167c634cfc3558991b59a6f614a31d226 , but it is not in Linus' tree (i.e. at github.com/torvalds/linux) yet. It went into Andrew Morton's "-mm" tree and then into "linux-next" tree. I am happy to split it into multiple logical patches and send them to Linus, of course. Kind regards, Tigran
[PATCH 4.19.6] BFS: static inode bitmap and extra sanity checking
Hello,
Please find a patch attached which contains the following changes:
1. Simplifies inode bitmap allocation by making it static.
2. Supersedes the changes to BFS that went into 4.19.6 with stronger checking.
3. Other changes are trivial (like whitespace cleanup, warning messages etc).
Fully tested under 4.19.6 kernel.
Kind regards,
Tigran
From: Tigran Aivazian
Subject: [PATCH 4.19.6] BFS: static inode bitmap and extra sanity checking
Strengthen validation of BFS superblock against corruption.
Make in-core inode bitmap static part of superblock info structure.
Print a warning when mounting a BFS filesystem created with "-N 512"
option as only 510 files can be created in the root directory.
Make the kernel messages more uniform. Update the 'prefix' passed to
bfs_dump_imap() to match the current naming of operations.
White space and comments cleanup.
Signed-off-by: Tigran Aivazian
Cc: Tetsuo Handa
Cc: Andrew Morton
Cc: Matthew Wilcox
Cc: Linus Torvalds
Cc: Greg Kroah-Hartman
---
fs/bfs/bfs.h| 11 ++-
fs/bfs/dir.c|4 +-
fs/bfs/file.c |2 -
fs/bfs/inode.c | 65 ++--
include/uapi/linux/bfs_fs.h |2 -
5 files changed, 41 insertions(+), 43 deletions(-)
--- include/uapi/linux/bfs_fs.h.0 2018-11-13 19:19:55.941267342 +
+++ include/uapi/linux/bfs_fs.h 2018-11-13 19:20:24.101182357 +
@@ -1,7 +1,7 @@
/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
/*
* include/linux/bfs_fs.h - BFS data structures on disk.
- * Copyright (C) 1999 Tigran Aivazian
+ * Copyright (C) 1999-2018 Tigran Aivazian
*/
#ifndef _LINUX_BFS_FS_H
--- fs/bfs/bfs.h.0 2018-11-13 19:20:40.151161044 +
+++ fs/bfs/bfs.h 2018-11-13 19:21:32.929740656 +
@@ -1,13 +1,20 @@
/* SPDX-License-Identifier: GPL-2.0 */
/*
* fs/bfs/bfs.h
- * Copyright (C) 1999 Tigran Aivazian
+ * Copyright (C) 1999-2018 Tigran Aivazian
*/
#ifndef _FS_BFS_BFS_H
#define _FS_BFS_BFS_H
#include
+/* In theory BFS supports up to 512 inodes, numbered from 2 (for /) up to 513 inclusive.
+ In actual fact, attempting to create the 512th inode (i.e. inode No. 513 or file No. 511)
+ will fail with ENOSPC in bfs_add_entry(): the root directory cannot contain so many entries, counting '..'.
+ So, mkfs.bfs(8) should really limit its -N option to 511 and not 512. For now, we just print a warning
+ if a filesystem is mounted with such "impossible to fill up" number of inodes */
+#define BFS_MAX_LASTI 513
+
/*
* BFS file system in-core superblock info
*/
@@ -17,7 +24,7 @@
unsigned long si_freei;
unsigned long si_lf_eblk;
unsigned long si_lasti;
- unsigned long *si_imap;
+ DECLARE_BITMAP(si_imap, BFS_MAX_LASTI+1);
struct mutex bfs_lock;
};
--- fs/bfs/dir.c.0 2018-11-13 19:29:32.361259272 +
+++ fs/bfs/dir.c 2018-11-13 19:30:01.380683858 +
@@ -2,8 +2,8 @@
/*
* fs/bfs/dir.c
* BFS directory operations.
- * Copyright (C) 1999,2000 Tigran Aivazian
- * Made endianness-clean by Andrew Stribblehill 2005
+ * Copyright (C) 1999-2018 Tigran Aivazian
+ * Made endianness-clean by Andrew Stribblehill 2005
*/
#include
--- fs/bfs/file.c.0 2018-11-13 19:30:11.760489957 +
+++ fs/bfs/file.c 2018-11-13 19:30:27.020214845 +
@@ -2,7 +2,7 @@
/*
* fs/bfs/file.c
* BFS file operations.
- * Copyright (C) 1999,2000 Tigran Aivazian
+ * Copyright (C) 1999-2018 Tigran Aivazian
*
* Make the file block allocation algorithm understand the size
* of the underlying block device.
--- fs/bfs/inode.c.0 2018-12-02 18:25:00.452000686 +
+++ fs/bfs/inode.c 2018-12-02 18:32:21.751786701 +
@@ -1,10 +1,9 @@
/*
* fs/bfs/inode.c
* BFS superblock and inode operations.
- * Copyright (C) 1999-2006 Tigran Aivazian
+ * Copyright (C) 1999-2018 Tigran Aivazian
* From fs/minix, Copyright (C) 1991, 1992 Linus Torvalds.
- *
- * Made endianness-clean by Andrew Stribblehill , 2005.
+ * Made endianness-clean by Andrew Stribblehill , 2005.
*/
#include
@@ -118,12 +117,12 @@
{
struct bfs_sb_info *info = BFS_SB(inode->i_sb);
unsigned int ino = (u16)inode->i_ino;
-unsigned long i_sblock;
+ unsigned long i_sblock;
struct bfs_inode *di;
struct buffer_head *bh;
int err = 0;
-dprintf("ino=%08x\n", ino);
+ dprintf("ino=%08x\n", ino);
di = find_inode(inode->i_sb, ino, &bh);
if (IS_ERR(di))
@@ -144,7 +143,7 @@
di->i_atime = cpu_to_le32(inode->i_atime.tv_sec);
di->i_mtime = cpu_to_le32(inode->i_mtime.tv_sec);
di->i_ctime = cpu_to_le32(inode->i_ctime.tv_sec);
-i_sblock = BFS_I(inode)->i_sblock;
+ i_sblock = BFS_I(inode)->i_sblock;
di->i_sblock = cpu_to_le32(i_sblock);
di->i_eblock = cpu_to_le32(BFS_I(inode)->i_eblock);
di->i_eoffset = cpu_to_le32(i_sblock * BFS_BSIZE + inode->i_size - 1);
@@ -188,13 +187,13 @@
mark_buff
Re: [PATCH 4.19 033/110] bfs: add sanity check at bfs_fill_super()
On Thu, 29 Nov 2018 at 17:10, Greg KH wrote: > Your patch has to apply on top of the existing one, so there's not an > issue here. > And might as well fix it now, as I can never count on a "future" patch > getting merged. It is already fixed, i.e. it applies cleanly against the existing (i.e. 4.19.5) kernel. What I meant is that, there is little or no point in applying a short-lived patch as there is no conceivable reason that it can become a long-lived one. Whatever else may have changed (all for the better of course) in the past 20 years in Linux kernel development, I presume the basic fundamental fact that no patch is accepted if the relevant maintainer has objections to it is still intact. And I am both the author and the maintainer of the BFS filesystem. Kind regards, Tigran
Re: [PATCH 4.19 033/110] bfs: add sanity check at bfs_fill_super()
On Thu, 29 Nov 2018 at 16:07, Greg KH wrote: > On Thu, Nov 29, 2018 at 03:23:00PM +0000, Tigran Aivazian wrote: > > Yes, of course I object to it. > I can not apply a patch to the stable trees that are not in Linus's tree > first. So there's nothing I can do here with this. Ok, we can wait until my patch propagates into Linus' tree, but I would have thought it would be a waste of your time to apply a patch which is waiting to be inevitably superseded by a different one. I can see there are 238 PRs at Linus' tree on github and I am very glad that I looked into one of them --- it contained a long comment explaining that I should NOT do what I was just about to do, i.e. make a PR against Linus' tree! :) And, besides, in the email conversation Linus approved my version of the patch anyway. Kind regards, Tigran
Re: [PATCH 4.19 033/110] bfs: add sanity check at bfs_fill_super()
Hello,
Yes, of course I object to it. I ignored this version of the patch
being applied to the older Linux versions, but for the latest versions
surely the version that I have authored should be applied instead. I
have sent to Andrew Morton both the 4.20-rc1 and 4.19.2 versions of
the patch. The 4.20 was applied (as "linux-next", I don't know why it
is not in 4.20-rc4 yet), but 4.19.2 version was not applied yet, so
here it is attached again (with the proper changelog etc). It applies
to 4.19.5 cleanly as well, so please use this version (attached).
Kind regards,
Tigran
On Thu, 29 Nov 2018 at 14:29, Greg Kroah-Hartman
wrote:
>
> 4.19-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Tetsuo Handa
>
> commit 9f2df09a33aa2c76ce6385d382693f98d7f2f07e upstream.
>
> syzbot is reporting too large memory allocation at bfs_fill_super() [1].
> Since file system image is corrupted such that bfs_sb->s_start == 0,
> bfs_fill_super() is trying to allocate 8MB of continuous memory. Fix
> this by adding a sanity check on bfs_sb->s_start, __GFP_NOWARN and
> printf().
>
> [1]
> https://syzkaller.appspot.com/bug?id=16a87c236b951351374a84c8a32f40edbc034e96
>
> Link:
> http://lkml.kernel.org/r/1525862104-3407-1-git-send-email-penguin-ker...@i-love.sakura.ne.jp
> Signed-off-by: Tetsuo Handa
> Reported-by: syzbot
> Reviewed-by: Andrew Morton
> Cc: Tigran Aivazian
> Cc: Matthew Wilcox
> Signed-off-by: Andrew Morton
> Signed-off-by: Linus Torvalds
> Signed-off-by: Greg Kroah-Hartman
>
> ---
> fs/bfs/inode.c |9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> --- a/fs/bfs/inode.c
> +++ b/fs/bfs/inode.c
> @@ -350,7 +350,8 @@ static int bfs_fill_super(struct super_b
>
> s->s_magic = BFS_MAGIC;
>
> - if (le32_to_cpu(bfs_sb->s_start) > le32_to_cpu(bfs_sb->s_end)) {
> + if (le32_to_cpu(bfs_sb->s_start) > le32_to_cpu(bfs_sb->s_end) ||
> + le32_to_cpu(bfs_sb->s_start) < BFS_BSIZE) {
> printf("Superblock is corrupted\n");
> goto out1;
> }
> @@ -359,9 +360,11 @@ static int bfs_fill_super(struct super_b
> sizeof(struct bfs_inode)
> + BFS_ROOT_INO - 1;
> imap_len = (info->si_lasti / 8) + 1;
> - info->si_imap = kzalloc(imap_len, GFP_KERNEL);
> - if (!info->si_imap)
> + info->si_imap = kzalloc(imap_len, GFP_KERNEL | __GFP_NOWARN);
> + if (!info->si_imap) {
> + printf("Cannot allocate %u bytes\n", imap_len);
> goto out1;
> + }
> for (i = 0; i < BFS_ROOT_INO; i++)
> set_bit(i, info->si_imap);
>
>
>
From: Tigran Aivazian
Subject: bfs: extra sanity checking and static inode bitmap
Strengthen validation of BFS superblock against corruption.
Make in-core inode bitmap static part of superblock info structure.
Print a warning when mounting a BFS filesystem created with "-N 512"
option as only 510 files can be created in the root directory.
Make the kernel messages more uniform. Update the 'prefix' passed to
bfs_dump_imap() to match the current naming of operations.
White space and comments cleanup.
Signed-off-by: Tigran Aivazian
Reported-by: Tetsuo Handa
---
fs/bfs/bfs.h| 11 ++-
fs/bfs/dir.c|4 +-
fs/bfs/file.c |2 -
fs/bfs/inode.c | 66
include/uapi/linux/bfs_fs.h |2 -
5 files changed, 43 insertions(+), 42 deletions(-)
--- include/uapi/linux/bfs_fs.h.0 2018-11-13 19:19:55.941267342 +
+++ include/uapi/linux/bfs_fs.h 2018-11-13 19:20:24.101182357 +
@@ -1,7 +1,7 @@
/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
/*
* include/linux/bfs_fs.h - BFS data structures on disk.
- * Copyright (C) 1999 Tigran Aivazian
+ * Copyright (C) 1999-2018 Tigran Aivazian
*/
#ifndef _LINUX_BFS_FS_H
--- fs/bfs/bfs.h.0 2018-11-13 19:20:40.151161044 +
+++ fs/bfs/bfs.h 2018-11-13 19:21:32.929740656 +
@@ -1,13 +1,20 @@
/* SPDX-License-Identifier: GPL-2.0 */
/*
* fs/bfs/bfs.h
- * Copyright (C) 1999 Tigran Aivazian
+ * Copyright (C) 1999-2018 Tigran Aivazian
*/
#ifndef _FS_BFS_BFS_H
#define _FS_BFS_BFS_H
#include
+/* In theory BFS supports up to 512 inodes, numbered from 2 (for /) up to 513 inclusive.
+ In actual fact, attempting to create the 512th inode (i.e. inode No. 513 or file No. 511)
+ will fail with ENOSPC in bfs_add_entry(): the root directory cannot contain so many entries, counting '..'.
+ So, mkfs.bfs(8) should really limit its -N option to 511 and not
Re: [PATCH AUTOSEL 3.18 1/9] bfs: add sanity check at bfs_fill_super()
On Thu, 22 Nov 2018 at 19:42, Sasha Levin wrote: > Hm, but this one is not upstream yet? I'll wait with it until it gets > some time to soak upstream. It is in linux-next, so I assume it will propagate to the numbered releases soon, see here: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/fs/bfs/inode.c?h=next-20181122
Re: [patch 14/15] bfs: add sanity check at bfs_fill_super()
On Thu, 15 Nov 2018 at 22:26, Andrew Morton wrote:
> Can you please resend it in the usual fashion? Changelogged, signed
> off, mailing list cc's etc?
Yes, sure, here it is again, attached both the 4.19.2 and 4.20-rc1
versions. It did (and still does) include the ChangeLog text,
"Signed-off-by:" line and diffstat output. And now I've also cc'd the
linux-kernel mailing list.
Kind regards,
Tigran
From: Tigran Aivazian
Subject: bfs: extra sanity checking and static inode bitmap
Strengthen validation of BFS superblock against corruption.
Make in-core inode bitmap static part of superblock info structure.
Print a warning when mounting a BFS filesystem created with "-N 512"
option as only 510 files can be created in the root directory.
Make the kernel messages more uniform. Update the 'prefix' passed to
bfs_dump_imap() to match the current naming of operations.
White space and comments cleanup.
Signed-off-by: Tigran Aivazian
Reported-by: Tetsuo Handa
---
fs/bfs/bfs.h| 11 ++-
fs/bfs/dir.c|4 +-
fs/bfs/file.c |2 -
fs/bfs/inode.c | 65 ++--
include/uapi/linux/bfs_fs.h |2 -
5 files changed, 41 insertions(+), 43 deletions(-)
--- include/uapi/linux/bfs_fs.h.0 2018-11-06 21:41:12.824782484 +
+++ include/uapi/linux/bfs_fs.h 2018-11-07 07:33:44.866456063 +
@@ -1,7 +1,7 @@
/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
/*
* include/linux/bfs_fs.h - BFS data structures on disk.
- * Copyright (C) 1999 Tigran Aivazian
+ * Copyright (C) 1999-2018 Tigran Aivazian
*/
#ifndef _LINUX_BFS_FS_H
--- fs/bfs/bfs.h.0 2018-11-07 07:42:04.561264110 +
+++ fs/bfs/bfs.h 2018-11-07 07:39:48.924757351 +
@@ -1,13 +1,20 @@
/* SPDX-License-Identifier: GPL-2.0 */
/*
* fs/bfs/bfs.h
- * Copyright (C) 1999 Tigran Aivazian
+ * Copyright (C) 1999-2018 Tigran Aivazian
*/
#ifndef _FS_BFS_BFS_H
#define _FS_BFS_BFS_H
#include
+/* In theory BFS supports up to 512 inodes, numbered from 2 (for /) up to 513 inclusive.
+ In actual fact, attempting to create the 512th inode (i.e. inode No. 513 or file No. 511)
+ will fail with ENOSPC in bfs_add_entry(): the root directory cannot contain so many entries, counting '..'.
+ So, mkfs.bfs(8) should really limit its -N option to 511 and not 512. For now, we just print a warning
+ if a filesystem is mounted with such "impossible to fill up" number of inodes */
+#define BFS_MAX_LASTI 513
+
/*
* BFS file system in-core superblock info
*/
@@ -17,7 +24,7 @@
unsigned long si_freei;
unsigned long si_lf_eblk;
unsigned long si_lasti;
- unsigned long *si_imap;
+ DECLARE_BITMAP(si_imap, BFS_MAX_LASTI+1);
struct mutex bfs_lock;
};
--- fs/bfs/inode.c.0 2018-11-06 21:40:58.705038577 +
+++ fs/bfs/inode.c 2018-11-07 07:37:37.369301388 +
@@ -1,10 +1,9 @@
/*
* fs/bfs/inode.c
* BFS superblock and inode operations.
- * Copyright (C) 1999-2006 Tigran Aivazian
+ * Copyright (C) 1999-2018 Tigran Aivazian
* From fs/minix, Copyright (C) 1991, 1992 Linus Torvalds.
- *
- * Made endianness-clean by Andrew Stribblehill , 2005.
+ * Made endianness-clean by Andrew Stribblehill , 2005.
*/
#include
@@ -118,12 +117,12 @@
{
struct bfs_sb_info *info = BFS_SB(inode->i_sb);
unsigned int ino = (u16)inode->i_ino;
-unsigned long i_sblock;
+ unsigned long i_sblock;
struct bfs_inode *di;
struct buffer_head *bh;
int err = 0;
-dprintf("ino=%08x\n", ino);
+ dprintf("ino=%08x\n", ino);
di = find_inode(inode->i_sb, ino, &bh);
if (IS_ERR(di))
@@ -144,7 +143,7 @@
di->i_atime = cpu_to_le32(inode->i_atime.tv_sec);
di->i_mtime = cpu_to_le32(inode->i_mtime.tv_sec);
di->i_ctime = cpu_to_le32(inode->i_ctime.tv_sec);
-i_sblock = BFS_I(inode)->i_sblock;
+ i_sblock = BFS_I(inode)->i_sblock;
di->i_sblock = cpu_to_le32(i_sblock);
di->i_eblock = cpu_to_le32(BFS_I(inode)->i_eblock);
di->i_eoffset = cpu_to_le32(i_sblock * BFS_BSIZE + inode->i_size - 1);
@@ -188,13 +187,13 @@
mark_buffer_dirty(bh);
brelse(bh);
-if (bi->i_dsk_ino) {
+ if (bi->i_dsk_ino) {
if (bi->i_sblock)
info->si_freeb += bi->i_eblock + 1 - bi->i_sblock;
info->si_freei++;
clear_bit(ino, info->si_imap);
- bfs_dump_imap("delete_inode", s);
-}
+ bfs_dump_imap("evict_inode", s);
+ }
/*
* If this was the last file, make the previous block
@@ -214,7 +213,6 @@
return;
mutex_destroy(&info->bfs_lock);
- kfree(info->si_imap);
kfree(info);
s->s_fs_info = NULL;
}
@@ -311,8 +309,7 @@
else
strcat(tmpbuf, "0");
}
- printf("BFS-fs: %s: lasti=%08lx <%s>\n",
-prefix, BFS_SB(s)->si_lasti, tmpbuf);
+ printf("%s: lasti=%08lx <%s>\n&qu
Re: [PATCH AUTOSEL 3.18 1/9] bfs: add sanity check at bfs_fill_super()
On Tue, 13 Nov 2018 at 19:40, Tigran Aivazian wrote:
>
> On Tue, 13 Nov 2018 at 08:31, Tigran Aivazian
> wrote:
> > Andrew, if you would like me to make the same patch against 4.19.1 as
> > well, please let me know.
>
> I decided to just go ahead and backport it to 4.19.1 anyway (see
> attached). Tested thoroughly under 4.19.1.
I just missed the 4.19.2 release by a few minutes.
And just as well, because the 4.19.1 patch contained a double of a
(trivial) chunk (change to comment in include/uapi/linux/bfs_fs.h) in
which "gmail.com" was misspelled as "veritas.com" :)
So, the final patch against 4.19.2 is attached.
From: Tigran Aivazian
Subject: bfs: extra sanity checking and static inode bitmap
Strengthen validation of BFS superblock against corruption.
Make in-core inode bitmap static part of superblock info structure.
Print a warning when mounting a BFS filesystem created with "-N 512"
option as only 510 files can be created in the root directory.
Make the kernel messages more uniform. Update the 'prefix' passed to
bfs_dump_imap() to match the current naming of operations.
White space and comments cleanup.
Signed-off-by: Tigran Aivazian
Reported-by: Tetsuo Handa
---
fs/bfs/bfs.h| 11 ++-
fs/bfs/dir.c|4 +-
fs/bfs/file.c |2 -
fs/bfs/inode.c | 66
include/uapi/linux/bfs_fs.h |2 -
5 files changed, 43 insertions(+), 42 deletions(-)
--- include/uapi/linux/bfs_fs.h.0 2018-11-13 19:19:55.941267342 +
+++ include/uapi/linux/bfs_fs.h 2018-11-13 19:20:24.101182357 +
@@ -1,7 +1,7 @@
/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
/*
* include/linux/bfs_fs.h - BFS data structures on disk.
- * Copyright (C) 1999 Tigran Aivazian
+ * Copyright (C) 1999-2018 Tigran Aivazian
*/
#ifndef _LINUX_BFS_FS_H
--- fs/bfs/bfs.h.0 2018-11-13 19:20:40.151161044 +
+++ fs/bfs/bfs.h 2018-11-13 19:21:32.929740656 +
@@ -1,13 +1,20 @@
/* SPDX-License-Identifier: GPL-2.0 */
/*
* fs/bfs/bfs.h
- * Copyright (C) 1999 Tigran Aivazian
+ * Copyright (C) 1999-2018 Tigran Aivazian
*/
#ifndef _FS_BFS_BFS_H
#define _FS_BFS_BFS_H
#include
+/* In theory BFS supports up to 512 inodes, numbered from 2 (for /) up to 513 inclusive.
+ In actual fact, attempting to create the 512th inode (i.e. inode No. 513 or file No. 511)
+ will fail with ENOSPC in bfs_add_entry(): the root directory cannot contain so many entries, counting '..'.
+ So, mkfs.bfs(8) should really limit its -N option to 511 and not 512. For now, we just print a warning
+ if a filesystem is mounted with such "impossible to fill up" number of inodes */
+#define BFS_MAX_LASTI 513
+
/*
* BFS file system in-core superblock info
*/
@@ -17,7 +24,7 @@
unsigned long si_freei;
unsigned long si_lf_eblk;
unsigned long si_lasti;
- unsigned long *si_imap;
+ DECLARE_BITMAP(si_imap, BFS_MAX_LASTI+1);
struct mutex bfs_lock;
};
--- fs/bfs/dir.c.0 2018-11-13 19:29:32.361259272 +
+++ fs/bfs/dir.c 2018-11-13 19:30:01.380683858 +
@@ -2,8 +2,8 @@
/*
* fs/bfs/dir.c
* BFS directory operations.
- * Copyright (C) 1999,2000 Tigran Aivazian
- * Made endianness-clean by Andrew Stribblehill 2005
+ * Copyright (C) 1999-2018 Tigran Aivazian
+ * Made endianness-clean by Andrew Stribblehill 2005
*/
#include
--- fs/bfs/file.c.0 2018-11-13 19:30:11.760489957 +
+++ fs/bfs/file.c 2018-11-13 19:30:27.020214845 +
@@ -2,7 +2,7 @@
/*
* fs/bfs/file.c
* BFS file operations.
- * Copyright (C) 1999,2000 Tigran Aivazian
+ * Copyright (C) 1999-2018 Tigran Aivazian
*
* Make the file block allocation algorithm understand the size
* of the underlying block device.
--- fs/bfs/inode.c.0 2018-11-13 19:21:46.089579726 +
+++ fs/bfs/inode.c 2018-11-13 19:29:22.521467104 +
@@ -1,10 +1,9 @@
/*
* fs/bfs/inode.c
* BFS superblock and inode operations.
- * Copyright (C) 1999-2006 Tigran Aivazian
+ * Copyright (C) 1999-2018 Tigran Aivazian
* From fs/minix, Copyright (C) 1991, 1992 Linus Torvalds.
- *
- * Made endianness-clean by Andrew Stribblehill , 2005.
+ * Made endianness-clean by Andrew Stribblehill , 2005.
*/
#include
@@ -118,12 +117,12 @@
{
struct bfs_sb_info *info = BFS_SB(inode->i_sb);
unsigned int ino = (u16)inode->i_ino;
-unsigned long i_sblock;
+ unsigned long i_sblock;
struct bfs_inode *di;
struct buffer_head *bh;
int err = 0;
-dprintf("ino=%08x\n", ino);
+ dprintf("ino=%08x\n", ino);
di = find_inode(inode->i_sb, ino, &bh);
if (IS_ERR(di))
@@ -144,7 +143,7 @@
di->i_atime = cpu_to_le32(inode->i_atime.tv_sec);
di->i_mtime = cpu_to_le32(inode->i_mtime.tv_sec);
di->i_ctime = cpu_to_le32(inode->i_ctime.tv_sec);
-i_sblock = BFS_I(inode)->i_sblock;
+ i_sblock = BFS
Re: [PATCH AUTOSEL 3.18 1/9] bfs: add sanity check at bfs_fill_super()
On Tue, 13 Nov 2018 at 08:31, Tigran Aivazian wrote:
> Andrew, if you would like me to make the same patch against 4.19.1 as
> well, please let me know.
I decided to just go ahead and backport it to 4.19.1 anyway (see
attached). Tested thoroughly under 4.19.1.
From: Tigran Aivazian
Subject: bfs: extra sanity checking and static inode bitmap
Strengthen validation of BFS superblock against corruption.
Make in-core inode bitmap static part of superblock info structure.
Print a warning when mounting a BFS filesystem created with "-N 512"
option as only 510 files can be created in the root directory.
Make the kernel messages more uniform. Update the 'prefix' passed to
bfs_dump_imap() to match the current naming of operations.
White space and comments cleanup.
Signed-off-by: Tigran Aivazian
Reported-by: Tetsuo Handa
---
fs/bfs/bfs.h| 11 ++-
fs/bfs/dir.c|4 +-
fs/bfs/file.c |2 -
fs/bfs/inode.c | 66
include/uapi/linux/bfs_fs.h |4 +-
5 files changed, 44 insertions(+), 43 deletions(-)
--- include/uapi/linux/bfs_fs.h.0 2018-11-13 19:19:55.941267342 +
+++ include/uapi/linux/bfs_fs.h 2018-11-13 19:20:24.101182357 +
@@ -1,7 +1,7 @@
/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
/*
* include/linux/bfs_fs.h - BFS data structures on disk.
- * Copyright (C) 1999 Tigran Aivazian
+ * Copyright (C) 1999-2018 Tigran Aivazian
*/
#ifndef _LINUX_BFS_FS_H
--- fs/bfs/bfs.h.0 2018-11-13 19:20:40.151161044 +
+++ fs/bfs/bfs.h 2018-11-13 19:21:32.929740656 +
@@ -1,13 +1,20 @@
/* SPDX-License-Identifier: GPL-2.0 */
/*
* fs/bfs/bfs.h
- * Copyright (C) 1999 Tigran Aivazian
+ * Copyright (C) 1999-2018 Tigran Aivazian
*/
#ifndef _FS_BFS_BFS_H
#define _FS_BFS_BFS_H
#include
+/* In theory BFS supports up to 512 inodes, numbered from 2 (for /) up to 513 inclusive.
+ In actual fact, attempting to create the 512th inode (i.e. inode No. 513 or file No. 511)
+ will fail with ENOSPC in bfs_add_entry(): the root directory cannot contain so many entries, counting '..'.
+ So, mkfs.bfs(8) should really limit its -N option to 511 and not 512. For now, we just print a warning
+ if a filesystem is mounted with such "impossible to fill up" number of inodes */
+#define BFS_MAX_LASTI 513
+
/*
* BFS file system in-core superblock info
*/
@@ -17,7 +24,7 @@
unsigned long si_freei;
unsigned long si_lf_eblk;
unsigned long si_lasti;
- unsigned long *si_imap;
+ DECLARE_BITMAP(si_imap, BFS_MAX_LASTI+1);
struct mutex bfs_lock;
};
--- fs/bfs/dir.c.0 2018-11-13 19:29:32.361259272 +
+++ fs/bfs/dir.c 2018-11-13 19:30:01.380683858 +
@@ -2,8 +2,8 @@
/*
* fs/bfs/dir.c
* BFS directory operations.
- * Copyright (C) 1999,2000 Tigran Aivazian
- * Made endianness-clean by Andrew Stribblehill 2005
+ * Copyright (C) 1999-2018 Tigran Aivazian
+ * Made endianness-clean by Andrew Stribblehill 2005
*/
#include
--- fs/bfs/file.c.0 2018-11-13 19:30:11.760489957 +
+++ fs/bfs/file.c 2018-11-13 19:30:27.020214845 +
@@ -2,7 +2,7 @@
/*
* fs/bfs/file.c
* BFS file operations.
- * Copyright (C) 1999,2000 Tigran Aivazian
+ * Copyright (C) 1999-2018 Tigran Aivazian
*
* Make the file block allocation algorithm understand the size
* of the underlying block device.
--- fs/bfs/inode.c.0 2018-11-13 19:21:46.089579726 +
+++ fs/bfs/inode.c 2018-11-13 19:29:22.521467104 +
@@ -1,10 +1,9 @@
/*
* fs/bfs/inode.c
* BFS superblock and inode operations.
- * Copyright (C) 1999-2006 Tigran Aivazian
+ * Copyright (C) 1999-2018 Tigran Aivazian
* From fs/minix, Copyright (C) 1991, 1992 Linus Torvalds.
- *
- * Made endianness-clean by Andrew Stribblehill , 2005.
+ * Made endianness-clean by Andrew Stribblehill , 2005.
*/
#include
@@ -118,12 +117,12 @@
{
struct bfs_sb_info *info = BFS_SB(inode->i_sb);
unsigned int ino = (u16)inode->i_ino;
-unsigned long i_sblock;
+ unsigned long i_sblock;
struct bfs_inode *di;
struct buffer_head *bh;
int err = 0;
-dprintf("ino=%08x\n", ino);
+ dprintf("ino=%08x\n", ino);
di = find_inode(inode->i_sb, ino, &bh);
if (IS_ERR(di))
@@ -144,7 +143,7 @@
di->i_atime = cpu_to_le32(inode->i_atime.tv_sec);
di->i_mtime = cpu_to_le32(inode->i_mtime.tv_sec);
di->i_ctime = cpu_to_le32(inode->i_ctime.tv_sec);
-i_sblock = BFS_I(inode)->i_sblock;
+ i_sblock = BFS_I(inode)->i_sblock;
di->i_sblock = cpu_to_le32(i_sblock);
di->i_eblock = cpu_to_le32(BFS_I(inode)->i_eblock);
di->i_eoffset = cpu_to_le32(i_sblock * BFS_BSIZE + inode->i_size - 1);
@@ -188,13 +187,13 @@
mark_buffer_dirty(bh);
brelse(bh);
-if (bi->i_dsk_ino) {
+ if (bi->i_dsk_ino) {
if (bi->i_sblock)
info->si_freeb += bi->i_eblock + 1 -
Re: [PATCH AUTOSEL 3.18 1/9] bfs: add sanity check at bfs_fill_super()
On Tue, 13 Nov 2018 at 05:52, Sasha Levin wrote:
> syzbot is reporting too large memory allocation at bfs_fill_super() [1].
> Since file system image is corrupted such that bfs_sb->s_start == 0,
> bfs_fill_super() is trying to allocate 8MB of continuous memory. Fix
> this by adding a sanity check on bfs_sb->s_start, __GFP_NOWARN and
> printf().
>
> [1]
> https://syzkaller.appspot.com/bug?id=16a87c236b951351374a84c8a32f40edbc034e96
Hi Sasha,
Thank you, but no, I am rejecting this patch as I have already
submitted a much more robust and accurate (stronger check) patch to
Andrew Morton a couple of days ago against 4.20-rc1.
Andrew, if you would like me to make the same patch against 4.19.1 as
well, please let me know.
Kind regards,
Tigran
>
> Link:
> http://lkml.kernel.org/r/1525862104-3407-1-git-send-email-penguin-ker...@i-love.sakura.ne.jp
> Signed-off-by: Tetsuo Handa
> Reported-by: syzbot
> Reviewed-by: Andrew Morton
> Cc: Tigran Aivazian
> Cc: Matthew Wilcox
> Signed-off-by: Andrew Morton
> Signed-off-by: Linus Torvalds
> Signed-off-by: Sasha Levin
> ---
> fs/bfs/inode.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/fs/bfs/inode.c b/fs/bfs/inode.c
> index 90bc079d9982..0ee38b284ad7 100644
> --- a/fs/bfs/inode.c
> +++ b/fs/bfs/inode.c
> @@ -349,7 +349,8 @@ static int bfs_fill_super(struct super_block *s, void
> *data, int silent)
>
> s->s_magic = BFS_MAGIC;
>
> - if (le32_to_cpu(bfs_sb->s_start) > le32_to_cpu(bfs_sb->s_end)) {
> + if (le32_to_cpu(bfs_sb->s_start) > le32_to_cpu(bfs_sb->s_end) ||
> + le32_to_cpu(bfs_sb->s_start) < BFS_BSIZE) {
> printf("Superblock is corrupted\n");
> goto out1;
> }
> @@ -358,9 +359,11 @@ static int bfs_fill_super(struct super_block *s, void
> *data, int silent)
> sizeof(struct bfs_inode)
> + BFS_ROOT_INO - 1;
> imap_len = (info->si_lasti / 8) + 1;
> - info->si_imap = kzalloc(imap_len, GFP_KERNEL);
> - if (!info->si_imap)
> + info->si_imap = kzalloc(imap_len, GFP_KERNEL | __GFP_NOWARN);
> + if (!info->si_imap) {
> + printf("Cannot allocate %u bytes\n", imap_len);
> goto out1;
> + }
> for (i = 0; i < BFS_ROOT_INO; i++)
> set_bit(i, info->si_imap);
>
> --
> 2.17.1
>
Re: [PATCH 3/4] x86/microcode: Add SPDX license identifiers
Hi Borislav, Ok, that's fine. I noticed these things when changing BFS code a couple of days ago and wondered what they were --- now I know :) Kind regards, Tigran On Fri, 9 Nov 2018 at 15:04, Borislav Petkov wrote: > > From: Borislav Petkov > > ... and drop the GPL v2 license free text. > > Signed-off-by: Borislav Petkov > Cc: Fenghua Yu > Cc: "H Peter Anvin" > Cc: Shaohua Li > Cc: Tigran Aivazian > Cc: Tom Lendacky > --- > arch/x86/kernel/cpu/microcode/amd.c | 4 +--- > arch/x86/kernel/cpu/microcode/core.c | 6 +- > arch/x86/kernel/cpu/microcode/intel.c | 6 +- > 3 files changed, 3 insertions(+), 13 deletions(-) > > diff --git a/arch/x86/kernel/cpu/microcode/amd.c > b/arch/x86/kernel/cpu/microcode/amd.c > index 07b5fc00b188..a1b02f2f0697 100644 > --- a/arch/x86/kernel/cpu/microcode/amd.c > +++ b/arch/x86/kernel/cpu/microcode/amd.c > @@ -1,3 +1,4 @@ > +// SPDX-License-Identifier: GPL-2.0 > /* > * AMD CPU Microcode Update Driver for Linux > * > @@ -17,9 +18,6 @@ > * > * Author: Jacob Shin > * Fixes: Borislav Petkov > - * > - * Licensed under the terms of the GNU General Public > - * License version 2. See file COPYING for details. > */ > #define pr_fmt(fmt) "microcode: " fmt > > diff --git a/arch/x86/kernel/cpu/microcode/core.c > b/arch/x86/kernel/cpu/microcode/core.c > index 2637ff09d6a0..b126180c15db 100644 > --- a/arch/x86/kernel/cpu/microcode/core.c > +++ b/arch/x86/kernel/cpu/microcode/core.c > @@ -1,3 +1,4 @@ > +// SPDX-License-Identifier: GPL-2.0+ > /* > * CPU Microcode Update Driver for Linux > * > @@ -12,11 +13,6 @@ > * (C) 2015 Borislav Petkov > * > * This driver allows to upgrade microcode on x86 processors. > - * > - * This program is free software; you can redistribute it and/or > - * modify it under the terms of the GNU General Public License > - * as published by the Free Software Foundation; either version > - * 2 of the License, or (at your option) any later version. > */ > > #define pr_fmt(fmt) "microcode: " fmt > diff --git a/arch/x86/kernel/cpu/microcode/intel.c > b/arch/x86/kernel/cpu/microcode/intel.c > index 16936a24795c..e199d3140be0 100644 > --- a/arch/x86/kernel/cpu/microcode/intel.c > +++ b/arch/x86/kernel/cpu/microcode/intel.c > @@ -1,3 +1,4 @@ > +// SPDX-License-Identifier: GPL-2.0+ > /* > * Intel CPU Microcode Update Driver for Linux > * > @@ -8,11 +9,6 @@ > * > * Copyright (C) 2012 Fenghua Yu > * H Peter Anvin" > - * > - * This program is free software; you can redistribute it and/or > - * modify it under the terms of the GNU General Public License > - * as published by the Free Software Foundation; either version > - * 2 of the License, or (at your option) any later version. > */ > > /* > -- > 2.19.1 >
Re: [PATCH] KASAN: slab-out-of-bounds Read in find_first_zero_bit
> RBP: 0003 R08: 000a R09: 6f6f6c2f7665642f >> R10: R11: 0207 R12: 0004 >> R13: 00401d70 R14: R15: >> >> Allocated by task 4476: >> save_stack+0x43/0xd0 mm/kasan/kasan.c:447 >> set_track mm/kasan/kasan.c:459 [inline] >> kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:552 >> __do_kmalloc mm/slab.c:3706 [inline] >> __kmalloc+0x162/0x760 mm/slab.c:3715 >> kmalloc include/linux/slab.h:517 [inline] >> kzalloc include/linux/slab.h:701 [inline] >> bfs_fill_super+0x3d3/0xea0 fs/bfs/inode.c:362 >> mount_bdev+0x2b7/0x370 fs/super.c:1119 >> bfs_mount+0x34/0x40 fs/bfs/inode.c:465 >> mount_fs+0x66/0x2d0 fs/super.c:1222 >> vfs_kern_mount.part.26+0xc6/0x4a0 fs/namespace.c:1037 >> vfs_kern_mount fs/namespace.c:2509 [inline] >> do_new_mount fs/namespace.c:2512 [inline] >> do_mount+0xea4/0x2bb0 fs/namespace.c:2842 >> SYSC_mount fs/namespace.c:3058 [inline] >> SyS_mount+0xab/0x120 fs/namespace.c:3035 >> do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287 >> entry_SYSCALL_64_after_hwframe+0x42/0xb7 >> >> Freed by task 2830: >> save_stack+0x43/0xd0 mm/kasan/kasan.c:447 >> set_track mm/kasan/kasan.c:459 [inline] >> __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:520 >> kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:527 >> __cache_free mm/slab.c:3486 [inline] >> kfree+0xd9/0x260 mm/slab.c:3801 >> single_release+0x88/0xb0 fs/seq_file.c:606 >> __fput+0x327/0x7e0 fs/file_table.c:209 >> fput+0x15/0x20 fs/file_table.c:243 >> task_work_run+0x199/0x270 kernel/task_work.c:113 >> tracehook_notify_resume include/linux/tracehook.h:191 [inline] >> exit_to_usermode_loop+0x275/0x2f0 arch/x86/entry/common.c:166 >> prepare_exit_to_usermode arch/x86/entry/common.c:196 [inline] >> syscall_return_slowpath arch/x86/entry/common.c:265 [inline] >> do_syscall_64+0x6ec/0x940 arch/x86/entry/common.c:292 >> entry_SYSCALL_64_after_hwframe+0x42/0xb7 >> >> The buggy address belongs to the object at 8801d7480a00 >> which belongs to the cache kmalloc-32 of size 32 >> The buggy address is located 0 bytes inside of >> 32-byte region [8801d7480a00, 8801d7480a20) >> The buggy address belongs to the page: >> page:ea00075d2000 count:1 mapcount:0 mapping:8801d748 >> index:0x8801d7480fc1 >> flags: 0x2fffc000100(slab) >> raw: 02fffc000100 8801d748 8801d7480fc1 0001003f >> raw: ea00075d1ea0 ea00075d32a0 8801dac001c0 >> page dumped because: kasan: bad access detected >> >> Memory state around the buggy address: >> 8801d7480900: 00 02 fc fc fc fc fc fc 00 02 fc fc fc fc fc fc >> 8801d7480980: 00 02 fc fc fc fc fc fc 00 fc fc fc fc fc fc fc >> > 8801d7480a00: 07 fc fc fc fc fc fc fc fb fb fb fb fc fc fc fc >> ^ >> 8801d7480a80: fb fb fb fb fc fc fc fc fb fb fb fb fc fc fc fc >> 8801d7480b00: fb fb fb fb fc fc fc fc fb fb fb fb fc fc fc fc >> == >> >> >> --- >> This bug is generated by a dumb bot. It may contain errors. >> See https://goo.gl/tpsmEJ for details. >> Direct all questions to syzk...@googlegroups.com. >> >> syzbot will keep track of this bug report. >> If you forgot to add the Reported-by tag, once the fix for this bug is >> merged >> into any tree, please reply to this email with: >> #syz fix: exact-commit-title >> If you want to test a patch for this bug, please reply with: >> #syz test: git://repo/address.git branch >> and provide the patch inline or as an attachment. >> To mark this as a duplicate of another syzbot report, please reply with: >> #syz dup: exact-subject-of-another-report >> If it's a one-off invalid bug report, please reply with: >> #syz invalid >> Note: if the crash happens again, it will cause creation of a new bug >> report. >> Note: all commands must start from beginning of the line in the email body. > > -- > You received this message because you are subscribed to a topic in the Google > Groups "syzkaller-bugs" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/syzkaller-bugs/GvNFae8m4fw/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > syzkaller-bugs+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/s
Re: WARNING: kmalloc bug in bfs_fill_super
Looks good to me, thank you.
On 1 May 2018 at 11:01, Tetsuo Handa wrote:
>
> From 247cae4da0490c2e285e0a99e630ef963fabb6d5 Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa
> Date: Tue, 1 May 2018 14:15:19 +0900
> Subject: [PATCH] bfs: add sanity check at bfs_fill_super().
>
> syzbot is reporting too large memory allocation at bfs_fill_super() [1].
> Since file system image is corrupted such that bfs_sb->s_start == 0,
> bfs_fill_super() is trying to allocate 8MB of continuous memory. Fix this
> by adding a sanity check on bfs_sb->s_start, __GFP_NOWARN and printf().
>
> [1]
> https://syzkaller.appspot.com/bug?id=16a87c236b951351374a84c8a32f40edbc034e96
>
> Signed-off-by: Tetsuo Handa
> Reported-by: syzbot
> Cc: Tigran A. Aivazian
> ---
> fs/bfs/inode.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/fs/bfs/inode.c b/fs/bfs/inode.c
> index 9a69392..d81c148 100644
> --- a/fs/bfs/inode.c
> +++ b/fs/bfs/inode.c
> @@ -350,7 +350,8 @@ static int bfs_fill_super(struct super_block *s, void
> *data, int silent)
>
> s->s_magic = BFS_MAGIC;
>
> - if (le32_to_cpu(bfs_sb->s_start) > le32_to_cpu(bfs_sb->s_end)) {
> + if (le32_to_cpu(bfs_sb->s_start) > le32_to_cpu(bfs_sb->s_end) ||
> + le32_to_cpu(bfs_sb->s_start) < BFS_BSIZE) {
> printf("Superblock is corrupted\n");
> goto out1;
> }
> @@ -359,9 +360,11 @@ static int bfs_fill_super(struct super_block *s, void
> *data, int silent)
> sizeof(struct bfs_inode)
> + BFS_ROOT_INO - 1;
> imap_len = (info->si_lasti / 8) + 1;
> - info->si_imap = kzalloc(imap_len, GFP_KERNEL);
> - if (!info->si_imap)
> + info->si_imap = kzalloc(imap_len, GFP_KERNEL | __GFP_NOWARN);
> + if (!info->si_imap) {
> + printf("Cannot allocate %u bytes\n", imap_len);
> goto out1;
> + }
> for (i = 0; i < BFS_ROOT_INO; i++)
> set_bit(i, info->si_imap);
>
> --
> 1.8.3.1
>
Re: [PATCH] bfs: Fix sanity checks for empty files
Hi,
If you had created the filesystem with the proper mkfs under SCO
UnixWare 7 you (probably) wouldn't encounter this issue. But since
commercial Unix-es are now part of history and the only proper way is
the Linux mkfs.bfs utility, your patch is fine.
Kind regards,
Tigran
On 5 May 2017 at 21:16, Rakesh Pandit wrote:
> Mount fails if file system image has empty files because of sanity
> check while reading superblock. For empty files disk offset to end of
> file (i_eoffset) is cpu_to_le32(-1). Sanity check comparison, which
> compares disk offset with file system size isn't valid for this value
> and hence is ignored with this patch.
>
> Steps to reproduce:
>
> $ dd if=/dev/zero of=bfs-image count=204800
> $ mkfs.bfs bfs-image
> $ mkdir bfs-mount-point
> $ sudo mount -t bfs -o loop bfs-image bfs-mount-point/
> $ cd bfs-mount-point/
> $ sudo touch a
> $ cd ..
> $ sudo umount bfs-mount-point/
> $ sudo mount -t bfs -o loop bfs-image bfs-mount-point/
> mount: /dev/loop0: can't read superblock
>
> $ dmesg
> [25526.689580] BFS-fs: bfs_fill_super(): Inode 0x0003 corrupted
>
> Signed-off-by: Rakesh Pandit
> ---
>
> This was sent three years but maintainer has been unresponsive:
> https://marc.info/?l=linux-kernel&m=138980764525250
>
> So sending you Andrew as previous patches to bfs have gone through
> your tree. This is tested and reproducible.
>
> fs/bfs/inode.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/bfs/inode.c b/fs/bfs/inode.c
> index f2deec0..0d3dc18 100644
> --- a/fs/bfs/inode.c
> +++ b/fs/bfs/inode.c
> @@ -419,7 +419,7 @@ static int bfs_fill_super(struct super_block *s, void
> *data, int silent)
> if (i_sblock > info->si_blocks ||
> i_eblock > info->si_blocks ||
> i_sblock > i_eblock ||
> - i_eoff > s_size ||
> + (i_eoff != le32_to_cpu(-1) && i_eoff > s_size) ||
> i_sblock * BFS_BSIZE > i_eoff) {
>
> printf("Inode 0x%08x corrupted\n", i);
> --
> 2.9.3
>
Re: MAINTAINERS without commits in the last 3 years
Hi Joe, I would suggest that those addresses which bounce should certainly be removed, but the rest should be left alone. Kind regards, Tigran PS. Joe, sorry if you received this message twice --- my first attempt to reply failed because gmail used html by default :) On 25 August 2016 at 00:33, Joe Perches wrote: > Many email addresses in MAINTAINERS no longer work so many > sections in > MAINTAINERS could likely be considered either > obsolete or unmaintained. > > Marking these sections appropriately or simply removing the > sections would make MAINTAINERS and get_maintainer.pl more > useful. > > These M: entries in MAINTAINERS haven't authored or had any > -by: signature entries in git log for the last 3 years. > > Some of these, like sta...@kernel.org and triv...@kernel.org, are > obviously addresses that should not be deleted from MAINTAINERS, > but most of them are candidates for removal or update. > > The email addresses below are also bcc'd here to see what bounces. > The list of the bounces will be collected. > > Thoughts? > > aacr...@adaptec.com > aacr...@microsemi.com > achim_leub...@adaptec.com > adap...@gmail.com > adilger.ker...@dilger.ca > a...@cwi.nl > ag...@suse.com > a...@comnets.uni-bremen.de > a...@alarsen.net > ali...@web.de > alist...@devzero.co.uk > aloisio.alme...@openbossa.org > andrew.d.henr...@intel.com > andrew.hen...@gmail.com > andre...@usa.net > anil.s.keshavamur...@intel.com > arhu...@freaks-unidos.net > arvin...@gmail.com > ath9k-de...@qca.qualcomm.com > ballabio_da...@emc.com > bcm-kernel-feedback-l...@broadcom.com > ber...@plugable.com > bi...@melbpc.org.au > brij...@gmail.com > brk...@us.ibm.com > brucech...@via.com.tw > castet.matth...@free.fr > ccaul...@redhat.com > cezary.jackiew...@gmail.com > chaoming...@realsil.com.cn > char...@alacritech.com > chess...@tux.org > chr...@sous-sol.org > c...@cs.cmu.edu > co...@colino.net > courmi...@gmail.com > dept-gelinuxnic...@qlogic.com > dept-hsglinuxnic...@qlogic.com > dev...@lanana.org > dh.herrm...@googlemail.com > d...@opfer-online.de > dm-de...@redhat.com > dmitry.tarnya...@lockless.no > d...@syst.com.br > d...@dotat.at > douglas_warze...@dell.com > dougthomp...@xmission.com > drw...@gmail.com > dsax...@plexity.net > d...@gentoo.org > duncan.sa...@free.fr > e...@pasemi.com > eib...@gdsys.de > epa...@parisplace.org > erik.and...@gmail.com > everest-linux...@qlogic.com > fa...@cs.unc.edu > f...@drama.obuda.kando.hu > fisc...@norbit.de > fiz...@tin.it > florian.c.schilha...@googlemail.com > florianschandi...@gmx.de > for...@alittletooquiet.net > fr...@f-seidel.de > fujita.tomon...@lab.ntt.co.jp > fun...@jurai.org > gilles.mul...@lip6.fr > go...@debian.or.jp > guillaume.lign...@gmail.com > gust...@padovan.org > hal.rosenst...@gmail.com > haraldwe...@viatech.com > henk.vergo...@gmail.com > her...@canonical.com > hlhun...@gmail.com > hskinnem...@gmail.com > hswon...@gmail.com > hubert.feurst...@contec.at > ibm-a...@hmh.eng.br > inaky.perez-gonza...@intel.com > infinip...@intel.com > i...@jurassic.park.msu.ru > intel-linux-...@intel.com > io...@badula.org > jansimon.moel...@gmx.de > jarkko.lavi...@nokia.com > ja...@wilsonet.com > jayakumar.a...@gmail.com > jay...@intworks.biz > jclib...@gmail.com > jd...@addtoit.com > j.du...@option.com > j...@parisc-linux.org > jens.tapro...@taprogge.org > jer...@goop.org > j...@trained-monkey.org > ji...@cam.ac.uk > jirisl...@gmail.com > jjcia...@raiz.uncu.edu.ar > joc...@scram.de > jo...@lazybastard.org > johan.hedb...@gmail.com > j...@johnmccutchan.com > jonat...@buzzard.org.uk > jon.nettle...@gmail.com > josh.h.mor...@us.ibm.com > j...@f6fbb.org > jreu...@yaina.de > j...@vanzandt.mv.com > jtp.p...@samsung.com > jue...@gmail.com > juhle...@akamai.com > k...@fi.muni.cz > ker...@savoirfairelinux.com > kevin.cur...@farsite.co.uk > k...@gmx.de > k...@reisers.ca > klass...@mathematik.tu-chemnitz.de > kou.ishiz...@toshiba.co.jp > k...@deine-taler.de > kuz...@ms2.inr.ac.ru > lafo...@gnumonks.org > lafo...@openezx.org > lauro.venan...@openbossa.org > lcostant...@gmail.com > l...@flatcap.org > l...@kernel.org > lene...@twibble.org > linasveps...@gmail.com > linux-dri...@qlogic.com > linuxdriv...@attotech.com > linux-graphics-maintai...@vmware.com > linux-ker...@hansmi.ch > linux-net-driv...@solarflare.com > linuxr...@lsi.com > li...@simtec.co.uk > linuxw...@intel.com > linux-wi...@intel.com > lio...@gmail.com > liqin.li...@gmail.com > m...@melware.de > maintain...@bluecherrydvr.com > mal...@foss.arm.com > manohar.va...@gmail.com > mark.brown...@gmail.com > matt...@wil.cx > m...@qti.qualcomm.com > mbroe...@plusserver.de > mcg...@gmail.com > mche...@kernel.org > mdharm-...@one-eyed-alien.net > m...@sgi.com > m.huls...@tudelft.nl > miguel.ojeda.sando...@gmail.com > m...@compulab.co.il > miq...@df.uba.ar > mi...@sfgoth.com > m...@volny.cz > m...@ucw.cz > mkpe...@internode.on.net > mostr...@earthlink.net > m...@selenic.com > mpor...@kernel.crashing.org > mr.swami.re...@ti.com > neepa...@cisco.com > nic_
Re: [PATCH 5/9] bfs: move function prototype to the proper header file
On Fri, 25 Jan 2008, Dmitri Vorobiev wrote: Heikki Orsila пишет: +extern void dump_imap(const char *, struct super_block *); + Functions should not be externed, remove extern keyword. Care to explain why? because dump_imap() is just a BFS' internal helper (for debugging purposes only btw) to dump the inode map via printk. Why should it be moved into the header, i.e. where one expects to see things potentially visible by the rest of the kernel? 3) The checkpatch.pl did not complain at this particular patch. maybe this script should be simplified to not complain at things like that, which are best left to the author of the code to decide which declaration should be where? Kind regards Tigran
Re: [PATCH 5/9] bfs: move function prototype to the proper header file
On Fri, 25 Jan 2008, Heikki Orsila wrote: On Fri, Jan 25, 2008 at 01:32:04AM +0300, Dmitri Vorobiev wrote: diff --git a/fs/bfs/bfs.h b/fs/bfs/bfs.h index 090b96e..ecc74bb 100644 --- a/fs/bfs/bfs.h +++ b/fs/bfs/bfs.h ... +/* inode.c */ +extern void dump_imap(const char *, struct super_block *); + Functions should not be externed, remove extern keyword. why not? In (roughly, because ^extern pattern is not ideal) 3959 cases only in include/linux/*h they are: $ grep ^extern include/linux/*h | wc -l 3959 Kind regards Tigran -- 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: [PATCH 5/9] bfs: move function prototype to the proper header file
Ooops, I didn't look at the _name_ of the function, i.e. it being dump_imap(), an internal helper --- of course it shouldn't be extern'd you are right :) On Thu, 24 Jan 2008, Tigran Aivazian wrote: On Fri, 25 Jan 2008, Heikki Orsila wrote: On Fri, Jan 25, 2008 at 01:32:04AM +0300, Dmitri Vorobiev wrote: diff --git a/fs/bfs/bfs.h b/fs/bfs/bfs.h index 090b96e..ecc74bb 100644 --- a/fs/bfs/bfs.h +++ b/fs/bfs/bfs.h ... +/* inode.c */ +extern void dump_imap(const char *, struct super_block *); + Functions should not be externed, remove extern keyword. why not? In (roughly, because ^extern pattern is not ideal) 3959 cases only in include/linux/*h they are: $ grep ^extern include/linux/*h | wc -l 3959 Kind regards Tigran -- 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: umask ignored in mkdir(2)?
I figured it out! I thought you might be interested --- the reason is the mismatch between the default mount options stored in the superblock on disk and the filesystem features compiled into the kernel. Namely, dumpe2fs on the offending filesystems showed the following default mount options: user_xattr acl but on good filesystems it showed "(none)". So, I used "tune2fs -o ^acl" (and ^user_xattr) to clear these in the superblock and mounted the filesystem --- and now mkdir system call works as expected, i.e. honours the umask. Maybe the ext3 filesystem should automatically detect this (the mismatch) and printk a warning so the user is told that his filesystem is mounted in extremely insecure way, i.e. making directories as root will result in lots of 0777 places (e.g. try "make modules_install" --- this will create lots of security holes in /lib/modules). I cc'd linux-kernel as someone may wish to fix this. (see below for the actual report). Kind regards Tigran On Sun, 14 Jan 2007, Tigran Aivazian wrote: I forgot to mention that on another machine running the same kernel version with the same (as close as a UP machine can be to SMP) kernel configuration the umask is honoured properly on ext3 filesystem. On Sun, 14 Jan 2007, Tigran Aivazian wrote: Hi Hugh, I think I may have found a bug --- on one of my machines the umask value is ignored by ext3 (but honoured on tmpfs) for mkdir system call: $ cd /tmp $ df -T . FilesystemType 1K-blocks Used Available Use% Mounted on /dev/hdf1 ext3 189238556 155721568 23749068 87% / $ rmdir ok ; mkdir ok ; ls -ld ok rmdir: ok: No such file or directory drwxrwxrwx 2 tigran tigran 4096 Jan 14 20:36 ok/ $ umask 0022 $ cd /dev/shm $ df -T . FilesystemType 1K-blocks Used Available Use% Mounted on tmpfstmpfs 517988 0517988 0% /dev/shm $ rmdir ok ; mkdir ok ; ls -ld ok rmdir: ok: No such file or directory drwxr-xr-x 2 tigran tigran 40 Jan 14 20:36 ok/ $ uname -a Linux ws 2.6.19.1 #6 SMP Sun Jan 14 20:03:30 GMT 2007 i686 i686 i386 GNU/Linux $ grep -i acl /usr/src/linux/.config # CONFIG_FS_POSIX_ACL is not set # CONFIG_TMPFS_POSIX_ACL is not set # CONFIG_NFS_V3_ACL is not set # CONFIG_NFSD_V3_ACL is not set As you see, ACL is not configured in, and neither are extended attributes: $ grep -i xattr /usr/src/linux/.config # CONFIG_EXT2_FS_XATTR is not set # CONFIG_EXT3_FS_XATTR is not set So, this is something fs-specific. What do you think? Kind regards Tigran - 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: [PATCH] microcode: Fix mc_cpu_notifier section warning
Hi Jean, On Tue, 19 Dec 2006, Jean Delvare wrote: I don't see anything in arch/i386/kernel/microcode.c depending on CONFIG_HOTPLUG_CPU (in 2.6.20-rc1), sorry. I run 2.6.19.1 and there both mc_cpu_notifier (which your patch modified) and mc_cpu_callback (which uses mc_cpu_notifier) are inside #ifdef CONFIG_HOTPLUG_CPU. Kind regards Tigran - 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: [PATCH] microcode: Fix mc_cpu_notifier section warning
Hi Jean,
Ok, your patch is correct, although I assume you realize that it does
nothing --- both the function and the data it operates on are inside
CONFIG_HOTPLUG_CPU and checking include/linux/init.h I see that
__cpuinitdata is nothing in this case. E.g. msr_class_cpu_notifier in the
msr driver isn't declared __cpuinitdata...
But to tidy up one should add __cpuinitdata as you suggest (to guard for
the case if these two slip out of CONFIG_HOTPLUG_CPU, although they are
meaningless if cpu hotplug support is not configured in).
Kind regards
Tigran
On Sun, 17 Dec 2006, Jean Delvare wrote:
Structure mc_cpu_notifier references a __cpuinit function, but
isn't declared __cpuinitdata itself:
WARNING: arch/i386/kernel/microcode.o - Section mismatch: reference
to .init.text: from .data after 'mc_cpu_notifier' (at offset 0x118)
Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>
---
arch/i386/kernel/microcode.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-2.6.20-rc1.orig/arch/i386/kernel/microcode.c 2006-12-15
09:05:20.0 +0100
+++ linux-2.6.20-rc1/arch/i386/kernel/microcode.c 2006-12-17
15:23:40.0 +0100
@@ -722,7 +722,7 @@
return NOTIFY_OK;
}
-static struct notifier_block mc_cpu_notifier = {
+static struct notifier_block __cpuinitdata mc_cpu_notifier = {
.notifier_call = mc_cpu_callback,
};
--
Jean Delvare
-
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/
[patch-2.6.19.1] remaining fixes for my email address.
Hi Andrew,
As Adrian pointed out recently, there were still a couple of places where
I should have fixed my email address. The patch is attached (as attachment
so as to not let pine corrupt it).
The patch is against 2.6.19.1.
Kind regards
Tigran--- arch/i386/kernel/microcode.c.0 2006-12-12 13:09:56.679782000 +
+++ arch/i386/kernel/microcode.c2006-12-12 13:11:14.259782000 +
@@ -1,7 +1,7 @@
/*
* Intel CPU Microcode Update Driver for Linux
*
- * Copyright (C) 2000-2004 Tigran Aivazian
+ * Copyright (C) 2000-2006 Tigran Aivazian <[EMAIL PROTECTED]>
* 2006 Shaohua Li <[EMAIL PROTECTED]>
*
* This driver allows to upgrade microcode on Intel processors
@@ -92,7 +92,7 @@
#include
MODULE_DESCRIPTION("Intel CPU (IA-32) Microcode Update Driver");
-MODULE_AUTHOR("Tigran Aivazian <[EMAIL PROTECTED]>");
+MODULE_AUTHOR("Tigran Aivazian <[EMAIL PROTECTED]>");
MODULE_LICENSE("GPL");
#define MICROCODE_VERSION "1.14a"
@@ -754,7 +754,7 @@
register_hotcpu_notifier(&mc_cpu_notifier);
printk(KERN_INFO
- "IA-32 Microcode Update Driver: v" MICROCODE_VERSION " <[EMAIL
PROTECTED]>\n");
+ "IA-32 Microcode Update Driver: v" MICROCODE_VERSION " <[EMAIL
PROTECTED]>\n");
return 0;
}
--- fs/bfs/inode.c.02006-12-12 13:11:40.799782000 +
+++ fs/bfs/inode.c 2006-12-12 13:12:14.949782000 +0000
@@ -1,7 +1,7 @@
/*
* fs/bfs/inode.c
* BFS superblock and inode operations.
- * Copyright (C) 1999,2000 Tigran Aivazian <[EMAIL PROTECTED]>
+ * Copyright (C) 1999-2006 Tigran Aivazian <[EMAIL PROTECTED]>
* From fs/minix, Copyright (C) 1991, 1992 Linus Torvalds.
*
* Made endianness-clean by Andrew Stribblehill <[EMAIL PROTECTED]>, 2005.
@@ -18,7 +18,7 @@
#include
#include "bfs.h"
-MODULE_AUTHOR("Tigran A. Aivazian <[EMAIL PROTECTED]>");
+MODULE_AUTHOR("Tigran Aivazian <[EMAIL PROTECTED]>");
MODULE_DESCRIPTION("SCO UnixWare BFS filesystem for Linux");
MODULE_LICENSE("GPL");
--- Documentation/filesystems/bfs.txt.0 2006-12-12 13:14:56.169782000 +
+++ Documentation/filesystems/bfs.txt 2006-12-12 13:15:10.009782000 +
@@ -54,4 +54,4 @@
If you have any patches, questions or suggestions regarding this BFS
implementation please contact the author:
-Tigran A. Aivazian <[EMAIL PROTECTED]>
+Tigran Aivazian <[EMAIL PROTECTED]>
Re: [2.6 patch] Tigran Aivazian: remove bouncing email addresses
On Sat, 2 Dec 2006, Adrian Bunk wrote: The only bits that should be made sure to remain valid are the MODULE_AUTHOR, as Arjan also mentioned. Even the "please contact the author" and the printk() should continue to contain known bouncing addresses? Ah, I forgot about that one, but I see Alan Cox already replied and I agree with both you and Alan on this. Kind regards Tigran - 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: [2.6 patch] Tigran Aivazian: remove bouncing email addresses
On Fri, 1 Dec 2006, Jesper Juhl wrote: In my opinion the addresses should be working ones or not present at all (or at the very least there should be a note that the email address is outdated). The above argument is not valid for entries in a revision history. Most likely (though not necessarily), when there are multiple entries in a revision history with different email addresses, some are going to contain obsolete parts. Besides, I am sure there are thousands of stale email addresses throughout the current kernel source tree (and there have always been such) --- why start with me? Start with the top --- Linus Torvalds :) Try finding an obsolete email address for him in the kernel. By 2030 my turn may come :) Kind regards Tigran - 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: [2.6 patch] Tigran Aivazian: remove bouncing email addresses
Hi Adrian, I have only now had time to read your patch and reject most of it --- the email addresses in the revision histories etc are for historical purposes and as such are very useful. They are NOT meant to be valid except at the moment of time when they are written. The only purpose of email address in the revision history is the indication where the person worked _at the time_. The only bits that should be made sure to remain valid are the MODULE_AUTHOR, as Arjan also mentioned. Also, it is very strange that I have _not_ received your original email containing the patch --- I only saw it now via lkml archive. Kind regards Tigran On Fri, 1 Dec 2006, Adrian Bunk wrote: On Fri, Dec 01, 2006 at 10:08:39AM +0100, Arjan van de Ven wrote: On Thu, 2006-11-30 at 22:00 -0800, Hua Zhong wrote: I am curious, what's the point? These email addresses serve a "historical" purpose: they tell when the contribution was made, what the author's email addresses were at that point. .. and which company owns the copyright. ... Email addresses aren't good for this kind of information. As an example, what is stusta.de and does it have any rights on my contributions? [1] cu Adrian [1] it can't own the copyright since in Germany the copyright belongs untransferably [2] to the author [3] [2] except for heritage [3] but he can give exclusive usage rights for known kinds of usage -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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: [2.6 patch] Tigran Aivazian: remove bouncing email addresses
Hi Arjan, On Fri, 1 Dec 2006, Arjan van de Ven wrote: On Thu, 2006-11-30 at 22:00 -0800, Hua Zhong wrote: I am curious, what's the point? These email addresses serve a "historical" purpose: they tell when the contribution was made, what the author's email addresses were at that point. .. and which company owns the copyright. VERITAS doesn't own any copyright of the microcode driver because I wrote it _before_ I joined VERITAS. Lets not remove historical email addresses. Just make sure there's a current one in MODULE_AUTHOR / MAINTAINERS. I agree, so I should have included in the patch the change to MODULE_AUTHOR (in both microcode and bfs). Or maybe MODULE_AUTHOR shouldn't contain the email address, if the module is mentioned in the MAINTAINERS which does contain it? Why repeat the data and so have to remember to maintain it? Kind regards Tigran - 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: [discuss] booting a kernel compiled with -mregparm=0
Sorry, it was a "red herring", namely my module's Makefile still had "-mregparm=0" in CFLAGS, so that is why kdb showed it's arguments correctly (and then paniced on the way out). So we still have to deal with DWARF2 data then... Ok, will look into it. Kind regards Tigran On Tue, 18 Jan 2005, Tigran Aivazian wrote: On Tue, 18 Jan 2005, Tigran Aivazian wrote: I already solved this paricular problem. And the solution is (but don't tell me you knew it, for then why didn't you tell anyone) simply --- compile the kernel with -g and that includes enough debug information to be able to decode the stack content correctly. And yes, kdb does show the correct argument values now. No changes to kdb are necessary and no need to do the work with dwarf2 implementation etc etc. actually I am very surprized that it worked (because looking at the code I concluded that it should NOT). So I need to retest in all cases to make sure this is not a coincidence but a solid fact... Kind regards Tigran - 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/ - 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: [discuss] booting a kernel compiled with -mregparm=0
On Tue, 18 Jan 2005, Tigran Aivazian wrote: I already solved this paricular problem. And the solution is (but don't tell me you knew it, for then why didn't you tell anyone) simply --- compile the kernel with -g and that includes enough debug information to be able to decode the stack content correctly. And yes, kdb does show the correct argument values now. No changes to kdb are necessary and no need to do the work with dwarf2 implementation etc etc. actually I am very surprized that it worked (because looking at the code I concluded that it should NOT). So I need to retest in all cases to make sure this is not a coincidence but a solid fact... Kind regards Tigran - 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: [discuss] booting a kernel compiled with -mregparm=0
On Mon, 17 Jan 2005, H. Peter Anvin wrote: Or does kdb not have a client at all? (If so, I have no sympathy for it.) Peter, it was very easy for you to call my emails "rants" and "not even funny" but the above statement is displaying complete ignorance of what kdb actually is :) So, instead of "patronizing" your fellow-hacker, please listen to what he has to say below: I already solved this paricular problem. And the solution is (but don't tell me you knew it, for then why didn't you tell anyone) simply --- compile the kernel with -g and that includes enough debug information to be able to decode the stack content correctly. And yes, kdb does show the correct argument values now. No changes to kdb are necessary and no need to do the work with dwarf2 implementation etc etc. However, this highlighted a more serious problem in the x86_64 kernel (or more likely in the kdb patch) --- the kernel compiled with -g panics when you try to return from kdb after hitting a breakpoint. This is a bug and I'll investigate to find out the reason why it panics. (I hope it is not an "assumption" of the x86_64 port that one must never compile the kernel with -g either...) Kind regards Tigran - 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: [discuss] booting a kernel compiled with -mregparm=0
Hi Andi, On Mon, 17 Jan 2005, Andi Kleen wrote: The ABI supported way is to read the DWARF2 unwind tables. For that you would a dwarf2 reader. gdb does that in user space, and libgcc2 also does it for exception unwinding. IA64 has an in kernel dwarf2 reader library (and ia64 kdb uses it), although it would probably need some work to make it work on x86-64. So far nobody wanted it enough to do the porting work though. Thank you for the pointer. I will look at it and see if I can try to port it to x86_64, since that is the standard and official way. I admit that I didn't realize that the "magic stuff" which gdb does is in fact a dwarf2 implementation (and this is what's missing in kdb on x86_64). Kind regards Tigran - 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: [discuss] Re: [2.6 patch] x8664_ksyms.c: unexport register_die_notifier
On Mon, 17 Jan 2005, Arjan van de Ven wrote: On Mon, 2005-01-17 at 10:26 +0100, Andi Kleen wrote: On Sun, Jan 16, 2005 at 08:46:49AM +0100, Adrian Bunk wrote: The only user of register_die_notifier (kernel/kprobes.c) can't be built modular. Therefore, it's the EXPORT_SYMBOL is superfluous. Please don't apply this, it was especially intended for modular debuggers. There is already a hacvked kdb around that uses it. eh didn't Tigran just mail lkml claiming that kdb and x86-64 really don't mix ?? No, I emailed saying that kdb on x86_64 does NOT show the values of parameters passed to functions in the backtrace. And, ok, it has some other bugs (e.g. reboot doesn't work on SMP) too. But generally speaking kdb does work on x86_64. It just still has bugs, but so does every piece of software. We should just fix them all, that's all :) Kind regards Tigran - 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: [discuss] booting a kernel compiled with -mregparm=0
On Mon, 17 Jan 2005, Arjan van de Ven wrote: Actually, having cc'd Linus made me think very _carefully_ about what I say and I went and checked how the userspace does it, as I couldn't believe that such fine piece of software as gdb would be broken as well. And to my surprize I discovered that gdb (when a program is compiled with -g) works fine! I.e. it shows the function arguments correctly. And so why don't you use kgdb instead of kdb ? If kdb was some dead unmaintained piece of software then, yes, I would follow your advice and switch to kgdb. But kdb is a very nice and actively maintained piece of work, so it should be fixed to show the parameter values correctly in the backtrace. Kind regards Tigran - 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: [discuss] booting a kernel compiled with -mregparm=0
On Sat, 15 Jan 2005, H. Peter Anvin wrote: It depends on the architecture ABI. This is the case for the i386 ABI, but definitely *NOT* for x86-64. Yes, precisely. The ABI/x86_64 defines this behaviour explicitly. However, that would mean the ABI was designed without giving thought to debugging via kdb. When I said "2-3 weeks of work" I didn't fully realize the complexity of the problem. It is actually more like several months of research work and then (most likely) coming to the conclusion that the code to simulate the cpu (by disassembling the functions to track down where those registers went in each function) is just too complex to be written. So, this means there is no way for kdb on x86_64 to show the parameter values for each function in the back trace. Any chance of changing the ABI/x86_64 to do the right (i.e. passing via stack like on i386) thing now? Then kdb would automatically support it via normal ar-handling code. Also, we should NOT claim that Linux has been ported to x86_64 architecture yet, because the port is not clean, i.e. doesn't allow breaking ABI like it allows on i386, by means of CONFIG_REGPARM optimization. Anyone working on fixing this? I cc'd Linus as I cannot believe he agreed with allowing such an optimization to be a default and standard thing accepted by the Linux kernel. (But I may be wrong, especially since Linus isn't particularly fond of kdb anyway :) Actually, having cc'd Linus made me think very _carefully_ about what I say and I went and checked how the userspace does it, as I couldn't believe that such fine piece of software as gdb would be broken as well. And to my surprize I discovered that gdb (when a program is compiled with -g) works fine! I.e. it shows the function arguments correctly. And disassembling the functions shows that although the arguments are passed via registers (as ABI demands) they are also saved somewhere on the stack. Hmmm, interesting, then -g compiled Linux kernel should also be useable, with perhaps some tweaks to kdb to decode these frames correctly, right? I just want someone who knows the answer to confirm the last statement and so then I can go ahead and (try to) implement the solution by mimicking gdb behaviour (or help Jack Vogel implement it if he prefers doing it himself as defacto kdb/x86_64 maintainer) Kind regards Tigran - 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: function of getname() function
Hi Sathish, The function of getname() is to allocate some (kernel-space) memory for the userspace-passed filename and copy it from user space to kernel space. Regards, Tigran On Mon, 18 Jun 2001, SATHISH.J wrote: > Hi, > > Sorry if this question is too silly. > > I could not understand what getname(filename) function in the sys_open() > function is doing. I could not understand from the code what exactly it is > doing. Please help me with the same. > > Thanks in advance, > > Regards, > sathish > > > > - > 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/ > - 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: dget()
On 15 May 2001, Xavier Bestel wrote: > # cd /usr/src/linux > # make tags No, I never use that one because it skips very useful entries like the ones from EXPORT_SYMBOL etc. Also, it only shows the current architecture. So, the tags target in the Makefile would only become useful when it is stripped of extra (unnecessary, imho) logic and turned into a plain one I suggested above. Regards, Tigran - 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: dget()
On 15 May 2001, Blesson Paul wrote: > In everyfile system, dget() function is called. But I cannot find > where is the dget() function is written. Where is it To find this out, you type: # vi -t dget and then look at the bottom line which would show "./include/linux/dcache.h" This assumes you have built the tags by: # cd /usr/src/linux # find -name '*.[ch]' | ctags -L- & # echo "set tags=tags" >> .vimrc And, btw, it is a static inline, not a function per se. Regards, Tigran - 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: kdb wishlist
Keith, What would be really great is to add the following item to your wishlist: * make it possible (it is trivial but a pain to have to do it manually every time I upgrade to your latest version!) for those extra "modules" to be statically linked in. So that one doesn't have to keep these lines in the rc.local if [ -f /proc/sys/kernel/kdb ] then insmod kdbm_pg > /dev/null 2>&1 insmod kdbm_vm > /dev/null 2>&1 fi and then discover that the modules are from the compilation corresponding to a different tweak in page.h or highmem or whatever (let him who readeth understand ;) Long time ago I suggested removing the infrastructure for these "modules" completely (justification being -- it is not useless _only_ in a very exotic case of the need to teach kdb new features on a running kernel without permission to reboot) but you objected and that is fine, but at least making it optionally possible would be _very nice_, please. Regards, Tigran - 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: 2.2.19 breaks iBCS2: Patch
http://sourceforge.net/projects/linux-abi/ iBCS has been ported and maintained against most of 2.3.x series for a long time. And it is still, of course, available under 2.4.x, It is now called ABI because old name iBCS was a misnomer (iBCS2 is an Intel standard but the Linux implementation is far beyond the bounds of IA32 architecture -- it is portable, flexible and, in one word, perfect :) Regards, Tigran On Mon, 2 Apr 2001, Wolfgang Rohdewald wrote: > in 2.2.19, linux/include/asm-i386/uaccess.h is missing the line > > #define strlen_user(str) strnlen_user(str, ~0UL >> 1) > > putting it back makes iBCS2 work again. > > Btw will iBCS2 ever be ported to the 2.4 kernel? I'm stuck with 2.2 > until this is ported. > > Please CC: me, I'm not (yet) subscribed > > Thanks, Wolfgang > - > To unsubscribe from this list: send the line "unsubscribe linux-ibcs2" in > the body of a message to [EMAIL PROTECTED] > - 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: Questions about Enterprise Storage with Linux
Hi, On Wed, 7 Mar 2001, Jauder Ho wrote: > I am not sure what you intend this application for. If it is mission > critical in any way shape or form, I would still recommend using something > like Veritas (which unfortunately is not ported to Linux yet). What do you mean not ported? Of course it has been ported and everything works nicely and has been so for ages. Ok, it is true that you can't buy it just yet but should be able to sometime this year. By "it" I meant the volume manager, vxfs journalling filesystem etc... Regards, Tigran - 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: Linux 2.4.2ac7
On Fri, 2 Mar 2001, Alan Cox wrote: > [24940903.pdf] > Table 14 in paticular gives the config bits ok, thank you. Now I understand (maybe) whats' going on. Linux treated bits 22,23,24,25 but ignored 27 which it shouldn't have. Now, coupled with the fact that the problematic box I have (Celeron) has that bit 27 set suggests that we ought to extend mult[] table appropriately. The values for that Celeron do not match anything in the Table 14 so we have to extend mult[] emprirically. (so I now come back to the idea of 4bit representation of 'bus'). I will stop here/now but I will definitely come back to this interesting problem in 24 hours. But if anyone fixes it before then, I won't cry :) Of course, before sending anything I will make sure my patch works on _all_ my machines without any exceptions. Regards, Tigran - 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: Linux 2.4.2ac7
Alan, Those formulae (both 'bus' and 'mul' calculation) are broken, I think. If I extend 'bus' to be 4 bits instead of 2 then I can make it work on all of my machines (or all those I tried), of course, extending the buscode[] table appropriately. However, the radically broken, imho, thing is that the (bus, mul) pair is _not_ constant when I vary the bus/cpu speed settings in the "soft cpu BIOS". If the bits of the 0x2A msr are supposed to be used for finding out the "true" i.e. intended bus/cpu speeds (hence the label "overclocked" in the code) then they should remain constant when one is overclocking, right? As for my question on the evenness of the calls to identify_cpu() -- ignore it, it was obvious, of course (called from check_bugs() on boot_cpu_data and then on SMP on each cpu_data + id) Regards, Tigran - 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/
cpu/bus speed detection (was Re: Linux 2.4.2ac7
On Thu, 1 Mar 2001, Alan Cox wrote: > Please send me the value of your 0x2A MTRR. Because this isnt properly intel > documented there is a certain amount of research still required. > ok, adding this to init_intel(): u32 lo, hi; rdmsr(0x2A, lo, hi); printk(KERN_ERR "lo=%x hi=%x\n", lo, hi); produces the output: # dmesg | grep lo= lo=c5100800 hi=0 lo=c5100800 hi=0 lo=c5000800 hi=0 Tigran - 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: [patch] ps2fix-2.4.2-A0
On Fri, 2 Mar 2001, Ingo Molnar wrote:
> > + if (c == &misc_list) {
> >
> > This should be (c != &misc_list)
>
oops, I didn't notice -- ignore the patch I sent a minute ago :)
Regards,
Tigran
-
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/
[patch-2.4.2-ac8] misc_register() fix (was Re: Linux 2.4.2ac8
On Fri, 2 Mar 2001, Tigran Aivazian wrote:
> On Thu, 1 Mar 2001, Alan Cox wrote:
> > 2.4.2-ac8
> > o Stop two people claiming the same misc dev id (Philipp Rumpf)
>
> is this what has broken misc devi registration on my machine? I have two
> misc devices -- microcode and psaux -- now (ac8) I get none, /proc/misc is
> empty. Also, on boot gpm generates an "oops" from gpm.c(968) saying
> "/dev/mouse: No such device"
Hi Alan,
here is the fix, tested, it works fine. The only unsatisfactory thing is
that we do an extra if() on each iteration making misc_register()
typically a few instructions slower. I will think a few minutes on how to
make the old version work (i.e. I suspect it was just an incorrect walking
of the misc_list in ac8).
Regards,
Tigran
--- linux/drivers/char/misc.c.0 Fri Mar 2 09:35:01 2001
+++ linux/drivers/char/misc.c Fri Mar 2 10:01:17 2001
@@ -175,14 +175,16 @@
if (misc->next || misc->prev)
return -EBUSY;
+
down(&misc_sem);
- c = misc_list.next;
- while ((c != &misc_list) && (c->minor != misc->minor))
+ c = misc_list.next;
+ while (c != &misc_list) {
+ if (c->minor == misc->minor) {
+ up(&misc_sem);
+ return -EBUSY;
+ }
c = c->next;
- if (c == &misc_list) {
- up(&misc_sem);
- return -EBUSY;
}
if (misc->minor == MISC_DYNAMIC_MINOR) {
-
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: Linux 2.4.2ac8
On Thu, 1 Mar 2001, Alan Cox wrote: > 2.4.2-ac8 > o Stop two people claiming the same misc dev id (Philipp Rumpf) is this what has broken misc devi registration on my machine? I have two misc devices -- microcode and psaux -- now (ac8) I get none, /proc/misc is empty. Also, on boot gpm generates an "oops" from gpm.c(968) saying "/dev/mouse: No such device" So, ac8 has two problems for me: 1. /proc/cpuinfo shows wrong info about bus (claims to be overclocked) -- I will get back to you with the info you requested shortly 2. misc device registration is broken. Regards, Tigran - 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: 2.4.2ac8 lost char devices
On Thu, 1 Mar 2001, Mark Hahn wrote: > > > > > > Well, somethig has broken in ac8, because I lost my PS/2 mouse and > > > > > me too . > > No luck. > > it seems to be the mdelay(2) added to pc_keyb.c in -ac6. are you sure? My bet is that it is to do with misc device registration as I lost not just psaux but microcode device (which happens to be misc as well) Regards, Tigran - 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: Linux 2.4.2ac7
On Thu, 1 Mar 2001, José Luis Domingo López wrote: > Linux 2.4.2-ac7 reports wrong CPU speed and model name for a Pentium III > correctly detected on, at least, 2.2.18, 2.4.2 and 2.4.2-ac4. The > processor is a 600 MHz one, with a 133 MHz front bus. same here with PIII550MHz/100MHz bus. Actually, it is wrong in 2.4.2-ac6 as well -- don't know about ac5: here is info from bootlog: NT 05 Int: type 0, pol 0, trig 0, bus 3, IRQ 06, APIC ID 2, APIC INT 06 Int: type 0, pol 0, trig 0, bus 3, IRQ 07, APIC ID 2, APIC INT 07 Int: type 0, pol 1, trig 1, bus 3, IRQ 08, APIC ID 2, APIC INT 08 Int: type 0, pol 0, trig 0, bus 3, IRQ 09, APIC ID 2, APIC INT 09 Int: type 0, pol 0, trig 0, bus 3, IRQ 0a, APIC ID 2, APIC INT 0a Int: type 0, pol 0, trig 0, bus 3, IRQ 0b, APIC ID 2, APIC INT 0b Int: type 0, pol 0, trig 0, bus 3, IRQ 0c, APIC ID 2, APIC INT 0c Int: type 0, pol 0, trig 0, bus 3, IRQ 0d, APIC ID 2, APIC INT 0d Int: type 0, pol 0, trig 0, bus 3, IRQ 0e, APIC ID 2, APIC INT 0e Int: type 0, pol 0, trig 0, bus 3, IRQ 0f, APIC ID 2, APIC INT 0f Int: type 0, pol 3, trig 3, bus 0, IRQ 24, APIC ID 2, APIC INT 11 Int: type 0, pol 3, trig 3, bus 0, IRQ 28, APIC ID 2, APIC INT 12 Int: type 0, pol 3, trig 3, bus 0, IRQ 29, APIC ID 2, APIC INT 12 Int: type 0, pol 3, trig 3, bus 0, IRQ 30, APIC ID 2, APIC INT 10 Int: type 0, pol 3, trig 3, bus 1, IRQ 00, APIC ID 2, APIC INT 10 Int: type 0, pol 3, trig 3, bus 2, IRQ 10, APIC ID 2, APIC INT 13 Int: type 0, pol 3, trig 3, bus 2, IRQ 14, APIC ID 2, APIC INT 10 Int: type 2, pol 3, trig 1, bus 3, IRQ 00, APIC ID 2, APIC INT 17 Lint: type 3, pol 0, trig 0, bus 0, IRQ 00, APIC ID ff, APIC LINT 00 Lint: type 1, pol 0, trig 0, bus 0, IRQ 00, APIC ID ff, APIC LINT 01 Processors: 2 mapped APIC to e000 (fee0) mapped IOAPIC to d000 (fec0) Kernel command line: auto BOOT_IMAGE=242-ac6 ro root=341 BOOT_FILE=/boot/vmlinuz-2.4.2-ac6 video=matrox:vesa:0x118 parport=0x378,7 console=ttyS1,38400 console=tty0 nmi_watchdog=0 Initializing CPU#0 Detected 548.547 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 1094.45 BogoMIPS Memory: 1026616k/1048512k available (1855k kernel code, 21508k reserved, 477k data, 248k init, 131008k highmem) Dentry-cache hash table entries: 131072 (order: 8, 1048576 bytes) Buffer-cache hash table entries: 65536 (order: 6, 262144 bytes) Page-cache hash table entries: 262144 (order: 8, 1048576 bytes) Inode-cache hash table entries: 65536 (order: 7, 524288 bytes) CPU: Before vendor init, caps: 0387fbff , vendor = 0 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 512K CPU speed 363Mhz, Bus Speed 66MHz Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: After vendor init, caps: 0387fbff CPU serial number disabled. CPU: After generic, caps: 0383fbff CPU: Common caps: 0383fbff Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED]) mtrr: detected mtrr type: Intel CPU: Before vendor init, caps: 0383fbff , vendor = 0 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 512K CPU speed 363Mhz, Bus Speed 66MHz Intel machine check reporting enabled on CPU#0. CPU: After vendor init, caps: 0383fbff CPU: After generic, caps: 0383fbff CPU: Common caps: 0383fbff CPU0: Intel Pentium III (Katmai) stepping 03 per-CPU timeslice cutoff: 1462.42 usecs. Getting VERSION: 40011 Getting VERSION: 40011 Getting ID: 0 Getting ID: f00 Getting LVT0: 700 Getting LVT1: 400 enabled ExtINT on CPU#0 ESR value before enabling vector: ESR value after enabling vector: CPU present map: 3 Booting processor 1/1 eip 2000 Setting warm reset code and vector. 1. 2. 3. Asserting INIT. Waiting for send to finish... +Deasserting INIT. Waiting for send to finish... +#startup loops: 2. Sending STARTUP #1. After apic_write. Initializing CPU#1 Startup point 1. CPU#1 (phys ID: 1) waiting for CALLOUT Waiting for send to finish... +Sending STARTUP #2. After apic_write. Startup point 1. Waiting for send to finish... +After Startup. Before Callout 1. After Callout 1. CALLIN, before setup_local_APIC(). masked ExtINT on CPU#1 ESR value before enabling vector: ESR value after enabling vector: Calibrating delay loop... 1094.45 BogoMIPS Stack at about c221dfbc CPU: Before vendor init, caps: 0387fbff , vendor = 0 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 512K CPU speed 363Mhz, Bus Speed 66MHz Intel machine check reporting enabled on CPU#1. CPU: After vendor init, caps: 0387fbff CPU serial number disabled. CPU: After generic, caps: 0383fbff CPU: Common caps: 0383fbff 0
Re: Hashing and directories
On Thu, 1 Mar 2001, Alexander Viro wrote: > * userland issues (what, you thought that limits on the > command size will go away?) the space allowed for arguments is not a userland issue, it is a kernel limit defined by MAX_ARG_PAGES in binfmts.h, so one could tweak it if one wanted to without breaking any userland. Regards, Tigran - 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: What is 2.4 Linux networking performance like compared to BSD?
On Thu, 1 Mar 2001, Hans Reiser wrote: > > This is indeed what we should do if we get no answer from the list by someone > who has already done such work. > Hans, exactly what you want to measure? I have UP, 2way-SMP and 4way-SMP machines all of which have at least Linux+FreeBSD installed. All my tests so far (e.g. comparing NFS servers or filesystems etc) showed Linux (2.4) to be a lot faster than FreeBSD in all areas. However, to get specific answers you need to ask specific questions. Ask and you shall receive. (things like SPEC SFS results I can't tell because it is illegal (without going through proper steps of publishing them), I shouldn't even be saying that they show Linux to be much faster :) Regards, Tigran - 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/
[patch-2.4.2] bugfix -- ENXIO for read/write beyond end of raw device
Hi Linus,
Yes, I know that Stephen had fixed this bug ages ago but, nevertheless, it
is still present in 2.4.2 and I don't know about his plans for resending
the patch -- but it is a part of the set I maintain so I just wanted to
bring it to your attention. Small bug, small obvious fix -- why not
consider it sooner rather than later?
Regards,
Tigran
diff -urN -X dontdiff linux/drivers/char/raw.c vmfs/drivers/char/raw.c
--- linux/drivers/char/raw.cMon Oct 2 04:35:15 2000
+++ vmfs/drivers/char/raw.c Thu Feb 22 07:21:26 2001
@@ -277,8 +277,11 @@
if ((*offp & sector_mask) || (size & sector_mask))
return -EINVAL;
- if ((*offp >> sector_bits) > limit)
+ if ((*offp >> sector_bits) >= limit) {
+ if (size)
+ return -ENXIO;
return 0;
+ }
/*
* We'll just use one kiobuf
-
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: awe_ram.c
Hi, Hmm, it's a curious driver... Here is the patch (and the final .c) to get it to compile under 2.4.2 http://www.moses.uklinux.net/patches/aweram/ but the driver doesn't probe for the (extremely frequent!) case when the device has been prepared by the ISA-PNP subsystem. Looking at the infrastructure in drivers/net/ne.c it seems doable to teach it the language of isapnp_find_dev() API -- one just needs to know what signatures to plug into the ISAPNP_VENDOR() and ISAPNP_FUNCTION() macros -- my guess is that the output of /proc/isapnp contains this info. Interesting... I will play with this and see if it detects my ISA-PNP SB AWE64 card. Give the above patch a try and see if you figure out the values to plug in there sooner than I do. Regards, Tigran - 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: 128MB lost... where ?
On Wed, 21 Feb 2001, Giuliano Pochini wrote: > > Perhaps this is a faq... > I have a dual-800 (mb asus, no AGP) with 1GB ram, > but according to /proc/meminfo tells I only have > 90KB. I tried "mem=1024" boot parameter without > success. How can I get my 128MB back ? > when you compile your 2.4.x kernel make sure you set the "4G of RAM" option, i.e. CONFIG_HIGHMEM4G. If you chose "up to 1G" then it means "up to 986M" (or something like that) -- the number in Help is just rounded up to confuse the dummy user :) Regards, Tigran - 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: Detecting SMP
yes, just run the famous mptable program. If the machine is SMP then it will have a valid Intel MP 1.4 configuration tables so the program will show meaningful output. Regards, Tigran On Tue, 20 Feb 2001, Burton Windle wrote: > Hello. Is there a way, when running a non-SMP kernel, to detect or > otherwise tell (software only; the machine is 2400 miles away) if the > system has SMP capibilties? Would /proc/cpuinfo show two CPUs if the > kernel is non-SMP? Thanks! > > (btw, the kernel in question is a stock RH6.2 kernel 2.2.14-5, and yes, I > know I should update it anyways and that a SMP kernel will run on a UP > system) > > - 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: Detecting SMP
On Wed, 21 Feb 2001, Jeff Garzik wrote: > On Wed, 21 Feb 2001, Tigran Aivazian wrote: > > yes, just run the famous mptable program. If the machine is SMP then it > > will have a valid Intel MP 1.4 configuration tables so the program will > > show meaningful output. > > Does that allow you to detect multiple processors... or just an SMP board? > the answer is in section 4.1 of the Intel MP 1.4 spec: "An MP-compliant system must implement the MP floating pointer structure, ..." So, one would normally expect this to mean an SMP board rather than multiple processors, _HOWEVER_, I can imagine a very clever MP-aware BIOS implementation which detects that there are many processors and prepares MP floating config table and does _not_ prepare it otherwise. So, it all depends on the BIOS implementation. Actually, I never tried unplugging all-1 processors from my SMP machines and seeing what sort of MP table is left... Regards, Tigran - 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: Detecting SMP
On Wed, 21 Feb 2001, Tigran Aivazian wrote: > yes, just run the famous mptable program. before I am snowed under with questions about where to get this program, here is the src and binaries that I use -- it is quite possible that there is a newer version (I suspect Ingo Molnar might know better :) http://www.moses.uklinux.net/mptable Regards, Tigran - 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: 128MB lost... where ?
On Wed, 21 Feb 2001, Tigran Aivazian wrote: > On Wed, 21 Feb 2001, Giuliano Pochini wrote: > > > > > Perhaps this is a faq... > > I have a dual-800 (mb asus, no AGP) with 1GB ram, > > but according to /proc/meminfo tells I only have > > 90KB. I tried "mem=1024" boot parameter without > > success. How can I get my 128MB back ? > > > > when you compile your 2.4.x kernel make sure you set the "4G of RAM" > option, i.e. CONFIG_HIGHMEM4G. If you chose "up to 1G" then it means "up > to 986M" (or something like that) -- the number in Help is just rounded up ~~~ not 986M but (unsigned long)(-PAGE_OFFSET-VMALLOC_RESERVE)>>20 MB which is around 876M or so. Regards, Tigran - 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: 128MB lost... where ?
Hi, free is not an interesting command. Much more interesting is the kernel messages on boot, e.g. on my laptop it looks like this: BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: c000 @ 000c (reserved) BIOS-e820: 07ef @ 0010 (usable) BIOS-e820: 0001 @ 07ff (ACPI data) BIOS-e820: 0006 @ 100a (reserved) BIOS-e820: 0020 @ ffe0 (reserved) On node 0 totalpages: 32752 zone(0): 4096 pages. zone(1): 28656 pages. zone(2): 0 pages. Kernel command line: auto BOOT_IMAGE=241 ro root=302 BOOT_FILE=/boot/vmlinuz-2.4.1 Initializing CPU#0 Detected 448.628 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 894.56 BogoMIPS kdb version 1.7 by Scott Lurndal, Keith Owens. Copyright SGI, All Rights Reserved Memory: 125696k/131008k available (1311k kernel code, 4924k reserved, 949k data, 184k init, 0k highm em) as you can see, the above tells you exactly how many pages you have in each zone and the total number of usable pages. But even that is not relevant to your question. What is relevant is the number after the first "/" in the "Memory:" line and also the BIOS-e820 map, of course. Also, on 6.4G machine you should definitely use 64G i.e. PAE support and so if not all memory is detected, please report to this list. People like David Parsons will probably be interested in your configuration... Regards, Tigran - 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: mke2fs and kernel VM issues
On Thu, 15 Feb 2001, Samuel Flory wrote: > What is believed to be the current status of the typical mke2fs > crashes/hangs due to vm issues? I can reliably reproduce the issue on a > heavily modifed VA kernel based on 2.2.18. Is there a kernel which is > believed to be a known good kernel? (both 2.2.x and 2.4.x) I can mke2fs (successfully) on a 270G block device. Yes, of course, I also get various page allocation failures while this happens but they are not deadly, i.e. the thing (our volume manager) just retries until it works and after a while I have a valid (and a very big) ext2 filesystem with 0 processes killed. The kernel I use is 2.4.2-pre3. The machine has 6G RAM with the 3G given to kernel virtual. The amount of swap is massive (2G) but it is never used. Regards, Tigran - 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: [patch-2.4.1-ac10] unsetting TASK_RUNNING
On Tue, 13 Feb 2001, John Levon wrote: > I had a similar set of patches a while ago. I had several more unnecessary settings. > > At least Matthew Dharm as usb-storage maintainer wanted to keep his in. Of more > concern IMHO were the drivers busy waiting by failing to reset current->state > on each iteration - e.g. maestro2, maestro3. > > The patches I sent (out dated, and some of it buggy) are at : > > http://www.movement.uklinux.net/patches/kernel/schedule1.diff > http://www.movement.uklinux.net/patches/kernel/schedule2.diff > http://www.movement.uklinux.net/patches/kernel/schedule3.diff > http://www.movement.uklinux.net/patches/kernel/schedule4.diff > > for your reference. The last is similar to your patch. > Ok, good -- so why aren't your patches already in the kernel? Also, I think the concept of "maintainer of some part of Linux" means (or should mean) a person who has the intimate knowledge of a particular subject and is responsible for fixing bugs in that particular piece of software. This should add the burden but should _not_ give the person right to decide that the bugs should be left there. In other words, no maintainer should be allowed to say "I want to keep this line of code there" if such line serves no purpose and only adds confusion to people reading the code. At least that is how I treat myself wrt maintaining microcode driver and BFS -- everyone in the world is welcome to find bugs in them and _mandate_ that I accept the fixes (if they are correct) -- I have no right to neglect them. Regards, Tigran - 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/
[patch-2.4.1-ac10] unsetting TASK_RUNNING
Hi Alan,
The only case in schedule_timeout() which does not call schedule() does
set tsk->state = TASK_RUNNING explicitly before returning. Therefore, any
code which unconditionally calls schedule_timeout() (and, of course
schedule()) does not need to set TASK_RUNNING afterwards.
I have seen some people setting this TASK_RUNNING incorrectly, based on a
mere observation that "official Linux kernel code does so" -- so the patch
below is not just an optimization but serves for education (i.e. to stop
people copying unnecessary code).
Regards,
Tigran
PS. Btw, I still haven't lost a single character on this laptop (still
running 2.2.19-pre9)
diff -urN -X dontdiff linux/drivers/char/cyclades.c trun/drivers/char/cyclades.c
--- linux/drivers/char/cyclades.c Wed Nov 15 08:41:03 2000
+++ trun/drivers/char/cyclades.cTue Feb 13 15:39:38 2001
@@ -2798,7 +2798,6 @@
/* Run one more char cycle */
current->state = TASK_INTERRUPTIBLE;
schedule_timeout(char_time * 5);
-current->state = TASK_RUNNING;
#ifdef CY_DEBUG_WAIT_UNTIL_SENT
printk("Clean (jiff=%lu)...done\n", jiffies);
#endif
diff -urN -X dontdiff linux/drivers/char/istallion.c trun/drivers/char/istallion.c
--- linux/drivers/char/istallion.c Tue Feb 13 15:23:03 2001
+++ trun/drivers/char/istallion.c Tue Feb 13 15:40:20 2001
@@ -1533,7 +1533,6 @@
if (len > 0) {
current->state = TASK_INTERRUPTIBLE;
schedule_timeout(len);
- current->state = TASK_RUNNING;
}
}
diff -urN -X dontdiff linux/drivers/net/wan/cosa.c trun/drivers/net/wan/cosa.c
--- linux/drivers/net/wan/cosa.cTue Feb 13 15:23:06 2001
+++ trun/drivers/net/wan/cosa.c Tue Feb 13 15:35:35 2001
@@ -523,7 +523,6 @@
current->state = TASK_INTERRUPTIBLE;
cosa_putstatus(cosa, SR_TX_INT_ENA);
schedule_timeout(30);
- current->state = TASK_RUNNING;
irq = probe_irq_off(irqs);
/* Disable all IRQs from the card */
cosa_putstatus(cosa, 0);
@@ -822,7 +821,6 @@
if (signal_pending(current) && chan->rx_status == 0) {
chan->rx_status = 1;
remove_wait_queue(&chan->rxwaitq, &wait);
- current->state = TASK_RUNNING;
spin_unlock_irqrestore(&cosa->lock, flags);
up(&chan->rsem);
return -ERESTARTSYS;
@@ -907,7 +905,6 @@
if (signal_pending(current) && chan->tx_status == 0) {
chan->tx_status = 1;
remove_wait_queue(&chan->txwaitq, &wait);
- current->state = TASK_RUNNING;
chan->tx_status = 1;
spin_unlock_irqrestore(&cosa->lock, flags);
return -ERESTARTSYS;
@@ -1542,7 +1539,6 @@
#ifdef MODULE
current->state = TASK_INTERRUPTIBLE;
schedule_timeout(HZ/2);
- current->state = TASK_RUNNING;
#else
udelay(5*10);
#endif
diff -urN -X dontdiff linux/drivers/scsi/scsi.c trun/drivers/scsi/scsi.c
--- linux/drivers/scsi/scsi.c Tue Feb 13 15:23:08 2001
+++ trun/drivers/scsi/scsi.cTue Feb 13 15:35:35 2001
@@ -441,11 +441,6 @@
remove_wait_queue(&device->scpnt_wait, &wait);
/*
- * FIXME - Isn't this redundant?? Someone
- * else will have forced the state back to running.
- */
-set_current_state(TASK_RUNNING);
-/*
* In the event that a signal has arrived that we need
* to consider, then simply return NULL. Everyone
* that calls us should be prepared for this
diff -urN -X dontdiff linux/fs/devfs/base.c trun/fs/devfs/base.c
--- linux/fs/devfs/base.c Tue Feb 13 15:23:09 2001
+++ trun/fs/devfs/base.cTue Feb 13 15:35:35 2001
@@ -3177,7 +3177,6 @@
if ( signal_pending (current) )
{
remove_wait_queue (&fs_info->devfsd_wait_queue, &wait);
- current->state = TASK_RUNNING;
return -EINTR;
}
set_current_state(TASK_INTERRUPTIBLE);
diff -urN -X dontdiff linux/fs/locks.c trun/fs/locks.c
--- linux/fs/locks.cTue Feb 13 15:23:10 2001
+++ trun/fs/locks.c Tue Feb 13 15:35:35 2001
@@ -590,7 +590,6 @@
if (signal_pending(current))
result = -ERESTARTSYS;
remove_wait_queue(fl_wait, &wait);
- current->state = TASK_RUNNING;
return result;
}
diff -urN -X dontdiff linux/fs/ncpfs/sock.c trun/fs/ncpfs/sock.c
--- linux/fs/ncpfs/sock.c Sat Jan 20 16:51:51 2001
+++ trun/fs/ncpfs/sock.cTue Feb 13 15:35:35 2001
@@ -153,7 +153,6 @@
}
timed_out = !schedule_timeout(timeout);
Re: How to install Alan's patches?
Alan's patches are installed like this:
# cd /usr/src
# tar xIf linux-2.4.1.tar.bz2
# cd linux
# patch -sp1 < ../patch-2.4.1-ac6
# chown -R root:root .
Note the "-sp1" and that you need to be _inside_ the tree. Also, you don't
need to waste another process ("cat") and create a pipe, just use shell
input redirection facility "<".
Regards,
Tigran
On Tue, 13 Feb 2001, Thomas Foerster wrote:
> Hi folks,
>
> sorry for the silly question, but i can't get it to work :
>
> I have linux-2.4.1 unpacked, configured and installed.
> Now i want to apply Alan Cox patche (linux-2.4.1-ac9), but i always get
> these errors :
>
> [root@space src]# cat /home/puck/patch-2.4.1-ac9 | patch -p0
> can't find file to patch at input line 4
> Perhaps you used the wrong -p or --strip option?
> The text leading up to this was:
> --
> |diff -u --new-file --recursive --exclude-from /usr/src/exclude
>linux.vanilla/CREDITS linux.ac/CREDITS
> |--- linux.vanilla/CREDITS Wed Jan 31 22:05:29 2001
> |+++ linux.ac/CREDITS Fri Feb 9 13:19:13 2001
> --
> File to patch:
> [root@space src]#
>
> Do i have to create linux.vanilla and linux.ac, or what's the magic?! :-)
>
> Thanx a lot,
> Thomas
>
> -
> 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/
>
-
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: lost charaters -- this is becoming annoying!
On Tue, 13 Feb 2001, Andrew Morton wrote: > Well, an external keyboard in a Dell Latitude works just fine here. > Perhaps you should remove it from the docking station and test > with an external keyboard? yes, I can try that. In the meantime you can see for yourself -- just plug into the docking station and stop using external keyboard (you must have lots of spare space on your desk -- I am not so tidy to allow so much wasted space to be wasted by such insignificant item as keyboard :) > > Or maybe it's just that chainsaw accident you had - have you tried > counting to ten lately? > yes, my fingers are okay -- I frequently check the mapping between the items in Exodus 20 and the fingers to make sure I still have the right number (of both). Regards, Tigran - 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: lost charaters -- this is becoming annoying!
Hi Alan, I am now running 2.2.19-pre9 and it is working fine. Also, just in case, I retyped this same message in pine in xterm and on the console. No character loss whatsoever. Also, licq stopped losing characters as well. I will continue using 2.2.19-pre9 until the evening and report anything suspicious. Regards, Tigran On Tue, 13 Feb 2001, Alan Cox wrote: > > > When you say 2.2.x works does that include 2.2.18. > > > > no, I meant the plain 2.2.x as of Red Hat 7.0 which is labelled as > > "2.2.16-22". > > Can you try 2.2.18/2.2.19pre. Those if my first guess is right will behave > like 2.4 does to you. > > > - 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: lost charaters -- this is becoming annoying!
Ok, I decided to write this email inine on the console and... see? the "inine" was supped to be "in pine" (not to mention the "supped" :) Yes, I do lose characters when working in pine on the console! So, it is not X-specific. Now, what I was going to write this email about was -- I get the same effect licq (just lost "in" before licq!) so it is not xterm-specific but probably that is not importt anymore (just lost "an" in "important").. (lost a . in "..." :) Tgran (unbelievable -- it doesn't even let me spell my own name correctly!) On Tue, 13 Feb 2001, Tigran Aivazian wrote: > Hi Andrew, > > Keyboard internal, but... you are right -- this _only_ happens when the > laptop is plugged into the docking station... that could be an extra clue > (i.e. two PS/2 controllers simultaneously -- maybe the docking station one > needs to be somehow explicitly disabled). > > How come I can't tell? Because when I type on the console it seems to be > ok, i.e. it is probably _not_ a keyboard driver. On the other hand, on the > laptop I don't type that much on the console and spend all the time in > X in xterm. That is why I am not certain what exactly is broken. > > I do not have ACPI enabled, nor APM in the kernel. > > Regards, > Tigran > > On Tue, 13 Feb 2001, Andrew Morton wrote: > > > Hi, Tigran. > > > > Internal keyboard, or external? > > > > Does it happen on the console or just in X? (How come you can't > > tell whether it's the k/b driver or the PTY driver?) > > > > Tried disabling ACPI? > > > > Tigran Aivazian wrote: > > > > > > Hi, > > > > > > I amtyping this without correcting -- allthe lost characters you see > > > (including spaces!) are exactly what the pseudo-tty driver does! This is > > > 2.4.1 a it definitely (oh, see "nd" of the ave "and" disappeared? and > > > "above" turned into "ave"!) did work fine previously -- like in the days > > > of 2.3.99 and 2.4.0-teX series (yes, teX was meant to be "testX"!) > > > > > > So, the keyboard or pty driver is badly broken. > > > > > > Regards, > > > Tigran > > > > > > PS. This only happens on this Dell latitude CPx (notice lost shift in > > > Latitude?) H450GT. > > > > > > PPS. No, my laptop is fine -- rebootingnto 2.2.x makes it type without > > > loosing characters... > > > > > > - > > > 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/ > > > > - 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: lost charaters -- this is becoming annoying!
Hi Andrew, Keyboard internal, but... you are right -- this _only_ happens when the laptop is plugged into the docking station... that could be an extra clue (i.e. two PS/2 controllers simultaneously -- maybe the docking station one needs to be somehow explicitly disabled). How come I can't tell? Because when I type on the console it seems to be ok, i.e. it is probably _not_ a keyboard driver. On the other hand, on the laptop I don't type that much on the console and spend all the time in X in xterm. That is why I am not certain what exactly is broken. I do not have ACPI enabled, nor APM in the kernel. Regards, Tigran On Tue, 13 Feb 2001, Andrew Morton wrote: > Hi, Tigran. > > Internal keyboard, or external? > > Does it happen on the console or just in X? (How come you can't > tell whether it's the k/b driver or the PTY driver?) > > Tried disabling ACPI? > > Tigran Aivazian wrote: > > > > Hi, > > > > I amtyping this without correcting -- allthe lost characters you see > > (including spaces!) are exactly what the pseudo-tty driver does! This is > > 2.4.1 a it definitely (oh, see "nd" of the ave "and" disappeared? and > > "above" turned into "ave"!) did work fine previously -- like in the days > > of 2.3.99 and 2.4.0-teX series (yes, teX was meant to be "testX"!) > > > > So, the keyboard or pty driver is badly broken. > > > > Regards, > > Tigran > > > > PS. This only happens on this Dell latitude CPx (notice lost shift in > > Latitude?) H450GT. > > > > PPS. No, my laptop is fine -- rebootingnto 2.2.x makes it type without > > loosing characters... > > > > - > > 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/ > - 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: lost charaters -- this is becoming annoying!
On Tue, 13 Feb 2001, Alan Cox wrote: > > PS. This only happens on this Dell latitude CPx (notice lost shift in > > Latitude?) H450GT. > > > > PPS. No, my laptop is fine -- rebootingnto 2.2.x makes it type without > > loosing characters... > > 2.2 and 2.4 handle keyboard error cases quite differently (less so as of 2.2.18) > When you say 2.2.x works does that include 2.2.18. no, I meant the plain 2.2.x as of Red Hat 7.0 which is labelled as "2.2.16-22". > > The next stage then is probably to log when you see errored keyboard bytes > ok. Regards, Tigran - 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: lost charaters -- this is becoming annoying!
On Tue, 13 Feb 2001, Tigran Aivazian wrote: > > PPS. No, my laptop is fine -- rebootingnto 2.2.x makes it type without > loosing characters... > just to clarify -- it does _not_ add characters -- the "loosing" vs "losing" thing is my own frequent typo :) Tigran - 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/
lost charaters -- this is becoming annoying!
Hi, I amtyping this without correcting -- allthe lost characters you see (including spaces!) are exactly what the pseudo-tty driver does! This is 2.4.1 a it definitely (oh, see "nd" of the ave "and" disappeared? and "above" turned into "ave"!) did work fine previously -- like in the days of 2.3.99 and 2.4.0-teX series (yes, teX was meant to be "testX"!) So, the keyboard or pty driver is badly broken. Regards, Tigran PS. This only happens on this Dell latitude CPx (notice lost shift in Latitude?) H450GT. PPS. No, my laptop is fine -- rebootingnto 2.2.x makes it type without loosing characters... - 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: sysinfo.sharedram not accounted for on i386 ?
On Mon, 12 Feb 2001, Brian Grossman wrote: > > Yes. > > Thanks. Is there a preferred way of getting the equivalent info > as free(1) did under 2.2? btw, this is not only x86 behaviour but is also true on all other architectures. I.e. Linux defines "shared memory" as a "integer constant with value 0". So, to say "zero" is just a shorter form of saying "Linux concept of shared memory". However, remember that if you are interested in shared _pages_, that information is available and is not identically 0. See the show_mem() function in arch/i386/mm/init.c. > > I've written a script to derive it from /proc/[0-9]*/statm, but that seems > like an awkward approach. A related question: is the page size stored in > /proc somewhere? No, PAGE_SIZE is known at compile time and cannot ever change (especially it cannot change ig you stay within i386 architecture). It is available to programs by including header. Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.1-ac7
Doug, I confirm that ac7 fixed all the aic7xxx problems on my machine. Thanks, Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.1-ac7
two mistakes: a) [EMAIL PROTECTED], not veritas.com! (it was pine, not me -- default domain etc :) b) it was ac6 which fixed it, not ac7 (but I am running ac7) On Thu, 8 Feb 2001, Tigran Aivazian wrote: > Doug, > > I confirm that ac7 fixed all the aic7xxx problems on my machine. > > Thanks, > Tigran > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[bug] aic7xxx panic Re: Linux 2.4.1-ac5
Alan, Doug, If this is a known problem -- ignore. Otherwise, I will gladly assist as much as you need. Just tried ac5 kernel and, behold (btw, why does serial console not work anymore, I had to copy these by hand): (scsi0) BRKADRINT error(0x44): Illegal Opcode in sequencer program PCI Error detected (scsi0) SEQADDR=0x58 Kernel panic: aic7xxx: unrecoverable BRKADRINT The Linux 2.4.2-pre1 works fine. Next thing I was thinking was to try ac4 and also to try on a different machine which has a different revision of the same type of aic7xxx HBA. Any more ideas? Regards, Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[reiserfs] SPEC SFS fails at low loads...
Hi, Under 2.4.1, after a little bit of running SPEC SFS (with NFSv3) I get these messages on the server: vs-13042: reiserfs_read_inode2: [0 1 0x0 SD] not found vs-13048: reiserfs_iget: bad_inode. Stat data of (0 1) not found vs-13048: reiserfs_iget: bad_inode. Stat data of (0 1) not found vs-13048: reiserfs_iget: bad_inode. Stat data of (0 1) not found and the run aborts. Any clues? Regards, Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Q. on marking __initdata
and, while you are at it, you should (probably) also mark pin_2_irq() and IO_APIC_get_PCI_irq_vector() functions as __init as well, for exactly the same reason as what you noticed. Regards, Tigran On Mon, 5 Feb 2001, Dunlap, Randy wrote: > Hi, > > Just a question (not a patch proposal): > > Could > +/* # of MP IRQ source entries */ > +struct mpc_config_intsrc mp_irqs[MAX_IRQ_SOURCES]; > > in arch/i386/kernel/mpparse.c (in 2.4.1-ac3; or in > arch/i386/kernel/io_apic.c in 2.4.1) be marked as > __initdata ? If not, why not? Or is __initdata > not needed on it for some reason (and if so, what > reason)? > > Thanks, > ~Randy_ > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux2.4.1-pre1, Kernel is too big for standalone boot fromfloppy
On Mon, 5 Feb 2001, Tigran Aivazian wrote: > Basically, I badly needed to be able to build kernels of arbitrary size not just "to build", but "to boot", of course :) Also, while we are in a history lesson, I might as well add that this was precisely the time when he (Werner) replaced the monstrously hardcoded initial page table with the one generated "automagically" -- hence the source file size went down dramatically... > and I asked someone who I was sure would know (Werner) how to fix it -- > and I was right -- he did know and he fixed it so now one could build very > large kernels and have them booted via LILO. But, the old plain bootsect.S > was still left as is, i.e. unable to boot very large kernels (for exact > size limits see the source, arch/i386/boot/tools/build.c) and so it was > only natural that one should printf a warning. > > So, in short, such kernels are okay to boot with LILO (and most other > bootloaders) but not if you just dd if=bzImage of=/dev/fd0, i.e. not by > bootsect.S > > > If you want the date... it was approximately the beginning of 2000, I > think. > > Regards, > Tigran > > > > > > make[2]: Leaving directory > > `/usr/src/linux-2.4.2-pre1/arch/i386/boot/compressed' > > gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o tools/build > > tools/build.c -I/usr/src/linux/include > > objcopy -O binary -R .note -R .comment -S compressed/bvmlinux > > compressed/bvmlinux.out > > tools/build -b bbootsect bsetup compressed/bvmlinux.out CURRENT > bzImage > > Root device is (8, 1) > > Boot sector 512 bytes. > > Setup is 4512 bytes. > > System is 1418 kB > > warning: kernel is too big for standalone boot from floppy > > > >++ > >| James W. Laferriere | System Techniques | Give me VMS | > >| NetworkEngineer | 25416 22nd So | Give me Linux | > >| [EMAIL PROTECTED] | DesMoines WA 98198 | only on AXP | > >++ > > > > - > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to [EMAIL PROTECTED] > > Please read the FAQ at http://www.tux.org/lkml/ > > > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux2.4.1-pre1, Kernel is too big for standalone boot fromfloppy
On Mon, 5 Feb 2001, Mr. James W. Laferriere wrote: > > Hello All , I like the warning Ladies & Gents . But when did it > first appear ? I seem to have missed the announcement in the > change logs . Tia , JimL you mean when did Werner Almesberger add the check and a printf of the warning you see below? I can't remember the date exactly but I remember it very clearly (i.e. everything except the date :) Basically, I badly needed to be able to build kernels of arbitrary size and I asked someone who I was sure would know (Werner) how to fix it -- and I was right -- he did know and he fixed it so now one could build very large kernels and have them booted via LILO. But, the old plain bootsect.S was still left as is, i.e. unable to boot very large kernels (for exact size limits see the source, arch/i386/boot/tools/build.c) and so it was only natural that one should printf a warning. So, in short, such kernels are okay to boot with LILO (and most other bootloaders) but not if you just dd if=bzImage of=/dev/fd0, i.e. not by bootsect.S If you want the date... it was approximately the beginning of 2000, I think. Regards, Tigran > > make[2]: Leaving directory > `/usr/src/linux-2.4.2-pre1/arch/i386/boot/compressed' > gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o tools/build > tools/build.c -I/usr/src/linux/include > objcopy -O binary -R .note -R .comment -S compressed/bvmlinux > compressed/bvmlinux.out > tools/build -b bbootsect bsetup compressed/bvmlinux.out CURRENT > bzImage > Root device is (8, 1) > Boot sector 512 bytes. > Setup is 4512 bytes. > System is 1418 kB > warning: kernel is too big for standalone boot from floppy > >++ >| James W. Laferriere | System Techniques | Give me VMS | >| NetworkEngineer | 25416 22nd So | Give me Linux | >| [EMAIL PROTECTED] | DesMoines WA 98198 | only on AXP | >++ > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch-2.4.2-pre1] rootfs boot parameter
ok, since so many people ask for it to be called "rootfstype=", I will do so and resend the patch. Any other comments? I think on the last round I have incorporated all the comments (except the "rootfs" -> "rootfstype" one)... Tigran On Mon, 5 Feb 2001, Werner Almesberger wrote: > Tigran Aivazian wrote: > > This patch adds "rootfs" boot parameter which selects the filesystem type > > for the root filesystem. > > Could you please make this rootfstype= or fstype= or maybe > root=[,] or such ? Calling it "rootfs" is just asking > for trouble ... > > - Werner > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[patch-2.4.2-pre1] rootfs boot parameter
Hi Linus,
This patch adds "rootfs" boot parameter which selects the filesystem type
for the root filesystem. Useful (nay, live-saving :) to distinguish
between filesystems which cannot detect damage to their structural
integrity. E.g. ext2 cannot detect if the block device has had another
filesystem made on it if it's superblock is left intact.
Regards,
Tigran
diff -urN -X ../dontdiff linux/Documentation/kernel-parameters.txt
rootfs/Documentation/kernel-parameters.txt
--- linux/Documentation/kernel-parameters.txt Sat Dec 30 19:23:13 2000
+++ rootfs/Documentation/kernel-parameters.txt Mon Feb 5 13:51:16 2001
@@ -479,7 +479,10 @@
ro [KNL] Mount root device read-only on boot.
- root= [KNL] root filesystem.
+ root= [KNL] Mount root filesystem on specified (as hex or
+"/dev/XXX") device.
+
+ rootfs= [KNL] Use filesystem type specified (e.g. rootfs=ext2) for
+root.
+
rw [KNL] Mount root device read-write on boot.
diff -urN -X ../dontdiff linux/fs/super.c rootfs/fs/super.c
--- linux/fs/super.cTue Jan 16 04:53:11 2001
+++ rootfs/fs/super.c Mon Feb 5 13:54:08 2001
@@ -18,6 +18,7 @@
*Torbjörn Lindh ([EMAIL PROTECTED]), April 14, 1996.
* Added devfs support: Richard Gooch <[EMAIL PROTECTED]>, 13-JAN-1998
* Heavily rewritten for 'one fs - one tree' dcache architecture. AV, Mar 2000
+ * Added rootfs boot param. used by mount_root(): Tigran Aivazian. Feb 2001.
*/
#include
@@ -59,6 +60,12 @@
/* this is initialized in init/main.c */
kdev_t ROOT_DEV;
+/* this can be set at boot time, e.g. rootfs=ext2
+ * if set to an invalid value or if read_super() fails on the specified
+ * filesystem type then mount_root() will panic
+ */
+static char rootfs[32] __initdata = "";
+
int nr_super_blocks;
int max_super_blocks = NR_SUPER;
LIST_HEAD(super_blocks);
@@ -79,6 +86,17 @@
static struct file_system_type *file_systems;
static rwlock_t file_systems_lock = RW_LOCK_UNLOCKED;
+static int __init rootfs_setup(char *line)
+{
+ int n = strlen(line) + 1;
+
+ if (n > 1 && n <= sizeof(rootfs))
+ strncpy(rootfs, line, n);
+ return 1;
+}
+
+__setup("rootfs=", rootfs_setup);
+
/* WARNING: This can be used only if we _already_ own a reference */
static void get_filesystem(struct file_system_type *fs)
{
@@ -1577,6 +1595,16 @@
goto mount_it;
}
+ if (*rootfs) {
+ fs_type = get_fs_type(rootfs);
+ if (fs_type) {
+ sb = read_super(ROOT_DEV,bdev,fs_type,root_mountflags,NULL,1);
+ if (sb)
+ goto mount_it;
+ }
+ /* don't try others if type given explicitly, same behaviour as
+mount(8) */
+ goto fail;
+ }
read_lock(&file_systems_lock);
for (fs_type = file_systems ; fs_type ; fs_type = fs_type->next) {
if (!(fs_type->fs_flags & FS_REQUIRES_DEV))
@@ -1591,7 +1619,8 @@
put_filesystem(fs_type);
}
read_unlock(&file_systems_lock);
- panic("VFS: Unable to mount root fs on %s", kdevname(ROOT_DEV));
+fail:
+ panic("VFS: Unable to mount root %s on %s", *rootfs ? rootfs : "fs",
+kdevname(ROOT_DEV));
mount_it:
printk ("VFS: Mounted root (%s filesystem)%s.\n",
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: SMP Race in brelse
Hi Daniel,
That is very well known (I posted about it many years ago :) but, as Ingo
(or someone else? maybe sct or Alan? actually, I think it was Andrea)
explained it is not a bug -- for that if() is only for purpose of catching
bad callers (which, in perfect world, shouldn't exist). The whole brelse()
could just contain a single atomic_dec() and that is all.
Regards,
Tigran
PS. Having thought about it -- it was neither sct, nor Alan, nor even
Andrea -- it was Linus who explained it :)
On Fri, 2 Feb 2001, Daniel Phillips wrote:
> There is a rare SMP race in brelse:
>
> 1138 void __brelse(struct buffer_head * buf)
> 1139 {
> 1140 if (atomic_read(&buf->b_count)) {
> 1141 atomic_dec(&buf->b_count);
> 1142 return;
> 1143 }
> 1144 printk("VFS: brelse: Trying to free free buffer\n");
> 1145 }
>
> cpu1 cpu2
>
> Starting with buf->b_count = 1, if we have:
>
>if (atomic_read(&buf->b_count))
>if (atomic_read(&buf->b_count))
>atomic_dec(&buf->b_count);
> atomic_dec(&buf->b_count);
>
> buf->b_count is now 0, but it should be -1, we fail to to report
> an erroneous extra brelse.
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [UPDATE] Zerocopy, last one today I promise :-)
On Thu, 25 Jan 2001, David S. Miller wrote: > 3) NFS client side activity this bit interesting (to me). Do you mean Linux NFS client as present in the Linux kernel source (nfs filesystem) or just the type of traffic generated by arbitrary NFS client (e.g. the builtin one used by SPEC SFS benchmark suite)? Regards, Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A little patch for i386/kernel/microcode.c (fwd)
On Wed, 24 Jan 2001, Jo l'Indien wrote: > With a 2.4.1-pre10 kernel, I noticed that /dev/cpu/microcode > was created as a file, and note as a node in the devfs. > So, I made this very little patch to correct this: > [bogus patch deleted] Hi Jocelyn, No, that file is created as a regular file for a purpose. The design of the Linux IA32 microcode device driver (btw, described fully in latest Linux Magazine) is such that it uses a characted device node on misc major _AND_ a regular file in devfs namespace, if available. The initialization succeeds if at least one of the method succeeds. If you are wondering why is this the case, the answer is -- ask yourself "what information can regular files provide which device nodes do not?". The answer is "file size" so I store an extra bit of information in the size of the regular devfs file which cannot be stored in the device node inode. That is the only benefit of devfs (in this case) -- just an extra integer to stash somewhere. But this has a lot of consequences, e.g. it means you could (in theory) just use your favourite binary editor to "edit" the microcode on the cpu "directly". (for this to work in practice you would need to instruct the editor of the suitable buffer sizes or to furnish the driver with a huge amount of extra logic to accumulate the chunks received of any size into appropriate ones). So, in short, no, your patch is of no use, thank you. Regards, Tigran PS. Also, where did you get that [EMAIL PROTECTED] from? The microcode.c plainly says "[EMAIL PROTECTED]" in recent references. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.1-pre8/10 klogd taking 100% of CPU time -- bug?
On Tue, 23 Jan 2001, Tigran Aivazian wrote: > So, since kdb was unable to tell me what's going on (and truss also can't > attach to it) one will have to debug it the old-fashioned way -- manually, > i.e. by trussing klogd from the beginning and reading it's sources... actually, all this means is that the task is busy looping in userspace (in retrospective, it is easy to "guess"). Regards, Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.1-pre8/10 klogd taking 100% of CPU time -- bug?
On 23 Jan 2001, Chmouel Boudjnah wrote: > Andrew Morton <[EMAIL PROTECTED]> writes: > > > As far as the klogd problem is concerned, see > > > > http://www.uwsg.iu.edu/hypermail/linux/kernel/0101.1/1053.html > > > > for a probable solution. > > it look like it fixes the problem for me, thanks. > Yes, it works, but one should NOT forget to rename /sbin/syslogd -> syslogd.old and klogd likewise because the new versions install themselves into /usr/sbin and so without renaming the old versions will be picked up. Also, one needs to edit /etc/rc.d/init.d/syslog. This is very similar to what one has to do if he wants to use NFSv3 client/server and latest nfsutils on Red Hat systems (they are broken by default) Regards, Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.1-pre8/10 klogd taking 100% of CPU time -- bug?
On 23 Jan 2001, Chmouel Boudjnah wrote: > Tigran Aivazian <[EMAIL PROTECTED]> writes: > > > Btw, this only happens on my laptop and not on the desktop. It only > > happens _after_ some activity but I have not yet managed to narrow down > > exactly what activity. > > i got the same problems on my desktop machine (Dell P4 which support > (broken) APM) and not on my laptop :\ I forgot top say that my laptop is identified (by DMI) as: BIOS Vendor: Dell Computer Corporation BIOS Version: A03 BIOS Release: 01/29/2000 System Vendor: Dell Computer Corporation. Product Name: Latitude CPx H450GT . Version . Serial Number . Board Vendor: Dell Computer Corporation. Board Name: Latitude CPx H450GT . Board Version: . Asset Tag: Ñ^L. Asset Tag: Ò^L. Btw, that Asset Tag printk's are surely buggy, aren't they? Aren't they supposed to dump in hex instead of some unprintable stuff? Regards, Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.1-pre8/10 klogd taking 100% of CPU time -- bug?
Hi, Has anyone else seen this? The system load is 1.0 and all the cpu time is taken by klogd but I do not have a stream of messages (or maybe I do but they all are lost?). Also, kdb refuses to decode klogd's stack saying "stack is not in task structure". It does show stack trace of other tasks though. So, since kdb was unable to tell me what's going on (and truss also can't attach to it) one will have to debug it the old-fashioned way -- manually, i.e. by trussing klogd from the beginning and reading it's sources... Btw, this only happens on my laptop and not on the desktop. It only happens _after_ some activity but I have not yet managed to narrow down exactly what activity. Regards, Tigran PS. No, I don't use power management or anything fancy/unproven like that -- laptop is just a small/portable desktop, imho. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0 bug: file /proc/dri 4 times in ls listing
On Tue, 16 Jan 2001, Tigran Aivazian wrote: > Fixing this requires either a new filesystem type (drifs) or > (simpler!) redesigning dri to separate common things into a separate > dri_core thing shared amongst them. just for completeness -- there is the 3rd option -- one could just fix the hack which is there (or was there half a year ago when I looked at it) which is supposed to detect that a file in /proc is already present. It is just not esthetically pleasant (good to eyes :) so I omitted this from the options... > > Regards, > Tigran > > On Tue, 16 Jan 2001, Bobo Rajec wrote: > > > > > Hi, > > > > I'm running kernel 2.4.0 on Redhat 7.0. I tried to get direct > > rendering running (it failed, but that's another story). Today I > > noticed something strange in /proc: dri appears there 4 times. > > > > ls /proc: > > ... > > -r--r--r--1 root root0 Jan 16 08:57 dma > > dr-xr-xr-x3 root root0 Jan 16 08:57 dri > > dr-xr-xr-x3 root root0 Jan 16 08:57 dri > > dr-xr-xr-x3 root root0 Jan 16 08:57 dri > > dr-xr-xr-x3 root root0 Jan 16 08:57 dri > > dr-xr-xr-x2 root root0 Jan 16 08:57 driver > > ... > > > > Chdir /proc/dri/0 works fine: > > > > bobo:/proc/dri/0>ls > > bufs clients histo mem name queues vm vma > > > > No dri modules, everything is linked in (I know I don't need all of > > these, but I have lots of memory, so...). > > > > ... > > CONFIG_AGP=y > > CONFIG_AGP_INTEL=y > > CONFIG_AGP_I810=y > > CONFIG_AGP_VIA=y > > CONFIG_AGP_AMD=y > > CONFIG_AGP_SIS=y > > CONFIG_AGP_ALI=y > > CONFIG_DRM=y > > CONFIG_DRM_TDFX=y > > CONFIG_DRM_GAMMA=y > > CONFIG_DRM_R128=y > > CONFIG_DRM_I810=y > > CONFIG_DRM_MGA=y > > ... > > > > Regards, > > bobo > > - > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to [EMAIL PROTECTED] > > Please read the FAQ at http://www.tux.org/lkml/ > > > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0 bug: file /proc/dri 4 times in ls listing
Hi Bobo, To fix this just link in only the support that corresponds to your hardware. The design of dri is such that (one could paraphrase) each driver-specific part includes its own copy of what should be "driver-independent shared dri_core engine" (e.g. proc handling stuff). Fixing this requires either a new filesystem type (drifs) or (simpler!) redesigning dri to separate common things into a separate dri_core thing shared amongst them. Regards, Tigran On Tue, 16 Jan 2001, Bobo Rajec wrote: > > Hi, > > I'm running kernel 2.4.0 on Redhat 7.0. I tried to get direct > rendering running (it failed, but that's another story). Today I > noticed something strange in /proc: dri appears there 4 times. > > ls /proc: > ... > -r--r--r--1 root root0 Jan 16 08:57 dma > dr-xr-xr-x3 root root0 Jan 16 08:57 dri > dr-xr-xr-x3 root root0 Jan 16 08:57 dri > dr-xr-xr-x3 root root0 Jan 16 08:57 dri > dr-xr-xr-x3 root root0 Jan 16 08:57 dri > dr-xr-xr-x2 root root0 Jan 16 08:57 driver > ... > > Chdir /proc/dri/0 works fine: > > bobo:/proc/dri/0>ls > bufs clients histo mem name queues vm vma > > No dri modules, everything is linked in (I know I don't need all of > these, but I have lots of memory, so...). > > ... > CONFIG_AGP=y > CONFIG_AGP_INTEL=y > CONFIG_AGP_I810=y > CONFIG_AGP_VIA=y > CONFIG_AGP_AMD=y > CONFIG_AGP_SIS=y > CONFIG_AGP_ALI=y > CONFIG_DRM=y > CONFIG_DRM_TDFX=y > CONFIG_DRM_GAMMA=y > CONFIG_DRM_R128=y > CONFIG_DRM_I810=y > CONFIG_DRM_MGA=y > ... > > Regards, > bobo > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Confirmation request about new 2.4.x. kernel limits
On Thu, 4 Jan 2001, A.D.F. wrote: > Max. RAM size:64 GB (any slowness accessing RAM over 4 GB >with 32 bit machines ?) realistic benchmarks (unixbench) will show about 3%-6% performance degradation with use of PAE. Note that this is not "accessing RAM over 4G" but (what you probably meant) "accessing any RAM in a machine with over 4G of RAM" or even "accessing any RAM in a machine with less than 4G or RAM but running kernel capable of accessing >4G". If you really meant "accessing RAM over 4G" then you are probably talking about 36bit MTRR support which is present in recent 2.4.x kernels and works very nicely! You can construct artificial benchmarks that will show 10% performance degradation. I haven't compared this with other PAE implementation, e.g. that of UnixWare 7.1.1+ -- this would be a very useful exercise as I vaguely remember some people claiming that Linux PAE implementation is not ideal (if it is true then it ought to be made ideal to be inline with the rest of the kernel). Regards, Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[patch-2.4.0-ac4] bugfix in the microcode driver.
Hi Alan, I sent this one-liner to Linus ages ago but he didn't notice it. The bug is obvious -- the goal of microcode_init() is to succeed at least in one of either devfs or misc registration. Regards, Tigran --- linux/arch/i386/kernel/microcode.c Mon Dec 11 21:42:08 2000 +++ work/arch/i386/kernel/microcode.c Wed Jan 3 12:13:27 2001 @@ -126,6 +126,7 @@ printk(KERN_ERR "microcode: failed to devfs_register()\n"); goto out; } + error = 0; printk(KERN_INFO "IA-32 Microcode Update Driver: v%s <[EMAIL PROTECTED]>\n", MICROCODE_VERSION); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[patch-2.2.19-pre3] fix to the oops in microcode driver
Hi,
I have already sent this to Alan but some people on #kernelnewbies on irc
complained about this Oops so I decided to send to all. (on the first
round I cc'd:[EMAIL PROTECTED])
Regards,
Tigran
diff -urN -X dontdiff linux/Documentation/Changes ucode-2.2/Documentation/Changes
--- linux/Documentation/Changes Wed Dec 27 07:32:10 2000
+++ ucode-2.2/Documentation/Changes Wed Dec 27 07:46:42 2000
@@ -529,8 +529,8 @@
chmod 0644 /dev/cpu/microcode
as root before you can use this. You'll probably also want to
-get the user-space microcode_ctl utility to use with this. The utility is
-available at:
+get the user-space microcode_ctl utility (and, obviously, the microcode
+data itself) to use with this. Both are available at:
http://www.urbanmyth.org/microcode
@@ -539,29 +539,8 @@
alias char-major-10-184 microcode
-to your /etc/modules.conf file.
-
-
-Intel IA32 microcode
-
-
-A driver has been added to allow updating of Intel IA32 microcode,
-accessible as both a devfs regular file and as a normal (misc)
-character device. If you are not using devfs you may need to:
-
-mkdir /dev/cpu
-mknod /dev/cpu/microcode c 10 184
-chmod 0644 /dev/cpu/microcode
-
-as root before you can use this. You'll probably also want to
-get the user-space microcode_ctl utility to use with this.
-
-If you have compiled the driver as a module you may need to add
-the following line:
-
-alias char-major-10-184 microcode
-
-to your /etc/modules.conf file.
+to your /etc/modules.conf file, unless you are using recent enough
version
+of modutils which knows about this by default.
Where to get the files
diff -urN -X dontdiff linux/arch/i386/kernel/microcode.c
ucode-2.2/arch/i386/kernel/microcode.c
--- linux/arch/i386/kernel/microcode.c Wed Dec 27 07:32:10 2000
+++ ucode-2.2/arch/i386/kernel/microcode.c Wed Dec 27 07:52:07 2000
@@ -35,6 +35,8 @@
* Pentium 4 support + backported fixes from 2.4
* 1.07 13 Dec 2000, Tigran Aivazian <[EMAIL PROTECTED]>
* More bugfixes backported from 2.4
+ * 1.08 27 Dec 2000, Tigran Aivazian <[EMAIL PROTECTED]>
+ * Fix: X86_FEATURE_30 was used incorrectly (in a 2.4 manner)
*/
#include
@@ -49,7 +51,7 @@
#include
#include
-#define MICROCODE_VERSION "1.07"
+#define MICROCODE_VERSION "1.08"
MODULE_DESCRIPTION("Intel CPU (IA-32) microcode update driver");
MODULE_AUTHOR("Tigran Aivazian <[EMAIL PROTECTED]>");
@@ -161,7 +163,7 @@
req->err = 1; /* be pessimistic */
if (c->x86_vendor != X86_VENDOR_INTEL || c->x86 < 6 ||
- test_bit(X86_FEATURE_30, &c->x86_capability)) { /* IA64 */
+ (c->x86_capability & X86_FEATURE_30) ) { /* IA64 */
printk(KERN_ERR "microcode: CPU%d not a capable Intel processor\n",
cpu_num);
return;
}
@@ -307,8 +309,8 @@
memset(mc_applied, 0, mc_fsize);
kfree(mc_applied);
mc_applied = NULL;
- printk(KERN_WARNING "microcode: freed %d bytes\n",
bytes);
mc_fsize = 0;
+ printk(KERN_WARNING "microcode: freed %d bytes\n",
+bytes);
up(µcode_sem);
return 0;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
FEATURE (was Re: PROBLEM: multiple mount of devices possible2.4.0-test1 - 2.4.0-test13-pre4
it is not a problem, it is a feature. (and a useful one!) On Sat, 23 Dec 2000 [EMAIL PROTECTED] wrote: > > 1. multiple mount of devices possible 2.4.0-test1 - 2.4.0-test13-pre4 > > 2. its still possible to mount devices several times. >IMHO it shouldnt be possible like 2.2.18 >with umount in /proc/mounts is still the real information, >in /etc/mtab all corresponding mountpoints are deleted. > > 3. kernel, filesystem, mount > > 4. Linux version 2.4.0-test13-pre4 (root@apollo) (gcc version 2.95.2 > 19991024 (release)) #1 SMP Sat Dec 23 17:04:07 CET 2000 > > 5. none > > 6. example >#!/bin/sh >mount /dev/hda2 /gate >mount -t nfs gate:/ /gate >mount -t nfs gate:/ /gate >mount /dev/hda2 /mnt > > 7. > > 7.1 > -- Versions installed: (if some fields are empty or look > -- unusual then possibly you have very old versions) > Linux apollo 2.4.0-test13-pre4 #1 SMP Sat Dec 23 17:04:07 CET 2000 i586 > unknown > Kernel modules 2.3.11 > Gnu C 2.95.2 > Gnu Make 3.79.1 > Binutils 2.9.5.0.24 > Linux C Libraryx 1 root root 4070406 Jul 30 21:41 > /lib/libc.so.6 > Dynamic linker ldd (GNU libc) 2.1.3 > Procps 2.0.6 > Mount 2.10m > Net-tools 1.56 > Kbd0.99 > Sh-utils 2.0 > Modules Loaded > > 7.2 > processor : 0 > vendor_id : AuthenticAMD > cpu family: 5 > model : 8 > model name: AMD-K6(tm) 3D processor > stepping : 12 > cpu MHz : 400.906 > cache size: 64 KB > fdiv_bug : no > hlt_bug : no > f00f_bug : no > coma_bug : no > fpu : yes > fpu_exception : yes > cpuid level : 1 > wp: yes > flags : fpu vme de pse tsc msr mce cx8 pge mmx syscall 3dnow k6_mtrr > bogomips : 799.54 > > 7.3 > > 7.4 > -001f : dma1 > 0020-003f : pic1 > 0040-005f : timer > 0060-006f : keyboard > 0080-008f : dma page reg > 00a0-00bf : pic2 > 00c0-00df : dma2 > 00f0-00ff : fpu > 0170-0177 : ide1 > 01f0-01f7 : ide0 > 0213-0213 : isapnp read > 02f8-02ff : serial(auto) > 0376-0376 : ide1 > 0378-037a : parport0 > 03c0-03df : vga+ > 03f6-03f6 : ide0 > 03f8-03ff : serial(auto) > 0a79-0a79 : isapnp write > 0cf8-0cff : PCI conf1 > 5c20-5c3f : Acer Laboratories Inc. [ALi] M7101 PMU > d000-d00f : Acer Laboratories Inc. [ALi] M5229 IDE > d400-d43f : Ensoniq ES1371 [AudioPCI-97] > d400-d43f : es1371 > d800-d8ff : Realtek Semiconductor Co., Ltd. RTL-8139 > d800-d8ff : eth0 > > -0009fbff : System RAM > 0009fc00-0009 : reserved > 000a-000b : Video RAM area > 000c-000c7fff : Video ROM > 000f-000f : System ROM > 0010-07ffbfff : System RAM > 0010-002ef4af : Kernel code > 002ef4b0-0031193f : Kernel data > 07ffc000-07ffefff : ACPI Tables > 07fff000-07ff : ACPI Non-volatile Storage > de00-deff : Realtek Semiconductor Co., Ltd. RTL-8139 > de00-deff : eth0 > df00-dfff : PCI Bus #01 > df00-df7f : Matrox Graphics, Inc. MGA G400 AGP > df80-df803fff : Matrox Graphics, Inc. MGA G400 AGP > e000-e3ff : Acer Laboratories Inc. [ALi] M1541 > e5f0-e7ff : PCI Bus #01 > e600-e7ff : Matrox Graphics, Inc. MGA G400 AGP > - : reserved > > 7.5 > 00:00.0 Host bridge: Acer Laboratories Inc. [ALi] M1541 (rev 04) > Subsystem: Acer Laboratories Inc. [ALi] ALI M1541 Aladdin V/V+ AGP > System Controller > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR- FastB2B- > Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- SERR-Latency: 64 > Region 0: Memory at e000 (32-bit, non-prefetchable) [size=64M] > Capabilities: [b0] AGP version 1.0 > Status: RQ=28 SBA+ 64bit- FW- Rate=x1,x2 > Command: RQ=0 SBA- AGP- 64bit- FW- Rate= > > 00:01.0 PCI bridge: Acer Laboratories Inc. [ALi] M5243 (rev 04) (prog-if > 00 [Normal decode]) > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR- FastB2B- > Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- SERR-Latency: 64 > Bus: primary=00, secondary=01, subordinate=01, sec-latency=64 > I/O behind bridge: e000-dfff > Memory behind bridge: df00-dfff > Prefetchable memory behind bridge: e5f0-e7ff > BridgeCtl: Parity- SERR- NoISA- VGA+ MAbort- >Reset- FastB2B- > > 00:03.0 Bridge: Acer Laboratories Inc. [ALi] M7101 PMU > Subsystem: Acer Laboratories Inc. [ALi] ALI M7101 Power Management > Controller > Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR- FastB2B- > Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- > SERR- > 00:07.0 ISA bridge: Acer Laboratories Inc. [ALi] M1533 PCI to ISA Bridge > [Aladdin IV] (rev c3) > Con
Re: why both kernel lock as well as semaphore
On Sat, 23 Dec 2000, Sourav Sen wrote: > > In many parts of the kernel, I have seen both semaphore is taken > (eg. down(¤t->mm->mmap_sem)) as well as kernel lock (lock_kernel()) > is also taken, why both are required? Whats the purpose of each? > because the semaphore is really needed (by design of the subsystem) but the big kernel lock (BKL) is taken "just in case", i.e. just in case the design is broken. Occasionally, the lock is removed to "see what happens" -- if nobody complains then the design is probably correct i.e. things are declared to "just work" and the attention is shifted to some other subsystem :) Does it make things clearer? Regards, Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Oops with microcode update driver on 2.2.19pre3
Hi Aaron, Although I have not looked at Oops report in detail (Sabbath is now on, can't do work!) but I am well aware of two (or more) bugs in that area and one of them may well be the cause of your oops I assumed the X86_FEATURE flags semantics to be the same on 2.2 as in 2.4 but then discovered it is different, fix is trivia) -- I will send Alan all the fixes real soon now. Possibly on Monday/Tuesday during the so-called "holidays" (I don't recognize those pagan feasts either :) Regards, Tigran On Fri, 22 Dec 2000, Aaron Sethman wrote: > > I am getting the following oops while trying to update the microcode of a > PII@266mhz using the microcode update driver. Below is the output of > ksymoops. This was built using egcs-1.1.2. > > Also in case it matters I've applied the ide-2.2.18 patch so I can use my > Promise ATA66 controller and the latest reiserfs patch.. > > Regards, > > Aaron > > ksymoops 0.7c on i686 2.2.19pre3. Options used > -V (default) > -k /proc/ksyms (default) > -l /proc/modules (default) > -o /lib/modules/2.2.19pre3/ (default) > -m /usr/src/linux/System.map (default) > > No modules in ksyms, skipping objects > Warning (read_lsmod): no symbols in lsmod, is /proc/modules a valid lsmod file? > Unable to handle kernel paging request at virtual address c823e12c > current->tss.cr3 = 05e9b000, %cr3 = 05e9b000 > *pde = > Oops: > CPU:0 > EIP:0010:[] > Using defaults from ksymoops -t elf32-i386 -a i386 > EFLAGS: 00010202 > eax: 0006 ebx: ecx: edx: bf87933c > esi: c023e120 edi: c6c31000 ebp: c5e9c000 esp: c5e9df4c > ds: 0018 es: 0018 ss: 0018 > Process microcode_ctl (pid: 1011, process nr: 48, stackpage=c5e9d000) > Stack: c6c31000 c5e9c000 0025 06101c8c c8a5 c8a34000 >c010782d 0001b800 c5e84540 c6c31000 c5e9c000 c0107c21 c5bcabb0 >ffea c01245c9 c5e84540 bf85db3c 0001b800 c5e84554 c5e9c000 0003 > Call Trace: [] [] [] [] [] >[] [] > Code: a1 2c e1 23 c8 a8 01 74 5a 6a 00 68 20 78 20 c0 e8 d2 bc 00 > > >>EIP; c01078b1<= > Trace; c8a5 > Trace; c8a34000 > Trace; c010782d > Trace; c0107c21 > Trace; c01245c9 > Trace; c0107b38 > Trace; c01094e8 > Code; c01078b1 > <_EIP>: > Code; c01078b1<= >0: a1 2c e1 23 c8mov0xc823e12c,%eax <= > Code; c01078b6 >5: a8 01 test $0x1,%al > Code; c01078b8 >7: 74 5a je 63 <_EIP+0x63> c0107914 > > Code; c01078ba >9: 6a 00 push $0x0 > Code; c01078bc >b: 68 20 78 20 c0push $0xc0207820 > Code; c01078c1 > 10: e8 d2 bc 00 00call bce7 <_EIP+0xbce7> c0113598 > > > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Mount system call hangs up the system
On Thu, 21 Dec 2000 [EMAIL PROTECTED] wrote: > Can somebody tell me why mount call just hangs? Is there anyway to take a > dump when the call is being executed. You don't need a dump. Just go to the source and start inserting printk() statements all over the sys_mount/do_mount etc. and sooner or later the reason for hang will become obvious. Either it is a bug in your program or in the kernel (or both). In any case it can be fixed. Regards, Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
