[PATCH CPA] [5/28] Add pte_pgprot on i386
64bit already had it.
Needed for later patches.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
include/asm-x86/pgtable-2level.h |2 ++
include/asm-x86/pgtable-3level.h |2 ++
2 files changed, 4 insertions(+)
Index: linux/include/asm-x86/pgtable-2level.h
===
--- linux.orig/include/asm-x86/pgtable-2level.h
+++ linux/include/asm-x86/pgtable-2level.h
@@ -76,6 +76,8 @@ static inline int pte_exec_kernel(pte_t
#define pgoff_to_pte(off) \
((pte_t) { (((off) & 0x1f) << 1) + (((off) >> 5) << 8) + _PAGE_FILE })
+#define pte_pgprot(x) __pgprot((x).pte_low & 0xfff)
+
/* Encode and de-code a swap entry */
#define __swp_type(x) (((x).val >> 1) & 0x1f)
#define __swp_offset(x)((x).val >> 8)
Index: linux/include/asm-x86/pgtable-3level.h
===
--- linux.orig/include/asm-x86/pgtable-3level.h
+++ linux/include/asm-x86/pgtable-3level.h
@@ -172,6 +172,8 @@ static inline pmd_t pfn_pmd(unsigned lon
pgprot_val(pgprot)) & __supported_pte_mask);
}
+#define pte_pgprot(x) __pgprot(pte_val(x) & (0xfff | _PAGE_NX))
+
/*
* Bits 0, 6 and 7 are taken in the low part of the pte,
* put the 32 bits of offset into the high part.
--
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 CPA] [4/28] Add pte_clrhuge on i386
64bit had it already
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
include/asm-x86/pgtable_32.h |1 +
1 file changed, 1 insertion(+)
Index: linux/include/asm-x86/pgtable_32.h
===
--- linux.orig/include/asm-x86/pgtable_32.h
+++ linux/include/asm-x86/pgtable_32.h
@@ -234,6 +234,7 @@ static inline pte_t pte_mkdirty(pte_t pt
static inline pte_t pte_mkyoung(pte_t pte) { (pte).pte_low |=
_PAGE_ACCESSED; return pte; }
static inline pte_t pte_mkwrite(pte_t pte) { (pte).pte_low |= _PAGE_RW;
return pte; }
static inline pte_t pte_mkhuge(pte_t pte) { (pte).pte_low |= _PAGE_PSE;
return pte; }
+static inline pte_t pte_clrhuge(pte_t pte) { (pte).pte_low &= ~_PAGE_PSE;
return pte; }
static inline pte_t pte_mkglobal(pte_t pte){ (pte).pte_low |=
_PAGE_GLOBAL; return pte; }
static inline pte_t pte_clrglobal(pte_t pte) { (pte).pte_low &=
~_PAGE_GLOBAL; return pte; }
--
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 CPA] [3/28] Add pte accessors for the global bit
Needed for some test code.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
include/asm-x86/pgtable_32.h |3 +++
include/asm-x86/pgtable_64.h |3 +++
2 files changed, 6 insertions(+)
Index: linux/include/asm-x86/pgtable_64.h
===
--- linux.orig/include/asm-x86/pgtable_64.h
+++ linux/include/asm-x86/pgtable_64.h
@@ -275,6 +275,7 @@ static inline int pte_young(pte_t pte)
static inline int pte_write(pte_t pte) { return pte_val(pte) &
_PAGE_RW; }
static inline int pte_file(pte_t pte) { return pte_val(pte) &
_PAGE_FILE; }
static inline int pte_huge(pte_t pte) { return pte_val(pte) &
_PAGE_PSE; }
+static inline int pte_global(pte_t pte){ return pte_val(pte) &
_PAGE_GLOBAL; }
static inline pte_t pte_mkclean(pte_t pte) { set_pte(,
__pte(pte_val(pte) & ~_PAGE_DIRTY)); return pte; }
static inline pte_t pte_mkold(pte_t pte) { set_pte(,
__pte(pte_val(pte) & ~_PAGE_ACCESSED)); return pte; }
@@ -285,6 +286,8 @@ static inline pte_t pte_mkyoung(pte_t pt
static inline pte_t pte_mkwrite(pte_t pte) { set_pte(,
__pte(pte_val(pte) | _PAGE_RW)); return pte; }
static inline pte_t pte_mkhuge(pte_t pte) { set_pte(,
__pte(pte_val(pte) | _PAGE_PSE)); return pte; }
static inline pte_t pte_clrhuge(pte_t pte) { set_pte(,
__pte(pte_val(pte) & ~_PAGE_PSE)); return pte; }
+static inline pte_t pte_mkglobal(pte_t pte){ set_pte(,
__pte(pte_val(pte) | _PAGE_GLOBAL)); return pte; }
+static inline pte_t pte_clrglobal(pte_t pte) { set_pte(,
__pte(pte_val(pte) & ~_PAGE_GLOBAL)); return pte; }
struct vm_area_struct;
Index: linux/include/asm-x86/pgtable_32.h
===
--- linux.orig/include/asm-x86/pgtable_32.h
+++ linux/include/asm-x86/pgtable_32.h
@@ -220,6 +220,7 @@ static inline int pte_dirty(pte_t pte)
static inline int pte_young(pte_t pte) { return (pte).pte_low &
_PAGE_ACCESSED; }
static inline int pte_write(pte_t pte) { return (pte).pte_low &
_PAGE_RW; }
static inline int pte_huge(pte_t pte) { return (pte).pte_low &
_PAGE_PSE; }
+static inline int pte_global(pte_t pte){ return (pte).pte_low
& _PAGE_GLOBAL; }
/*
* The following only works if pte_present() is not true.
@@ -233,6 +234,8 @@ static inline pte_t pte_mkdirty(pte_t pt
static inline pte_t pte_mkyoung(pte_t pte) { (pte).pte_low |=
_PAGE_ACCESSED; return pte; }
static inline pte_t pte_mkwrite(pte_t pte) { (pte).pte_low |= _PAGE_RW;
return pte; }
static inline pte_t pte_mkhuge(pte_t pte) { (pte).pte_low |= _PAGE_PSE;
return pte; }
+static inline pte_t pte_mkglobal(pte_t pte){ (pte).pte_low |=
_PAGE_GLOBAL; return pte; }
+static inline pte_t pte_clrglobal(pte_t pte) { (pte).pte_low &=
~_PAGE_GLOBAL; return pte; }
#ifdef CONFIG_X86_PAE
# include
--
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 CPA] [1/28] Shrink __PAGE_KERNEL/__PAGE_KERNEL_EXEC on non PAE kernels
No need to make it 64bit there.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
arch/x86/mm/init_32.c|4 ++--
include/asm-x86/pgtable_32.h |3 ++-
2 files changed, 4 insertions(+), 3 deletions(-)
Index: linux/arch/x86/mm/init_32.c
===
--- linux.orig/arch/x86/mm/init_32.c
+++ linux/arch/x86/mm/init_32.c
@@ -326,9 +326,9 @@ static void __init set_highmem_pages_ini
#define set_highmem_pages_init(bad_ppro) do { } while (0)
#endif /* CONFIG_HIGHMEM */
-unsigned long long __PAGE_KERNEL = _PAGE_KERNEL;
+typeof_field(pgprot_t, pgprot) __PAGE_KERNEL = _PAGE_KERNEL;
EXPORT_SYMBOL(__PAGE_KERNEL);
-unsigned long long __PAGE_KERNEL_EXEC = _PAGE_KERNEL_EXEC;
+typeof_field(pgprot_t, pgprot) __PAGE_KERNEL_EXEC = _PAGE_KERNEL_EXEC;
#ifdef CONFIG_NUMA
extern void __init remap_numa_kva(void);
Index: linux/include/asm-x86/pgtable_32.h
===
--- linux.orig/include/asm-x86/pgtable_32.h
+++ linux/include/asm-x86/pgtable_32.h
@@ -153,7 +153,8 @@ void paging_init(void);
#define _PAGE_KERNEL_EXEC \
(_PAGE_PRESENT | _PAGE_RW | _PAGE_DIRTY | _PAGE_ACCESSED)
-extern unsigned long long __PAGE_KERNEL, __PAGE_KERNEL_EXEC;
+#define typeof_field(t, m) typeof(((t *)0)->m)
+extern typeof_field(pgprot_t, pgprot) __PAGE_KERNEL, __PAGE_KERNEL_EXEC;
#define __PAGE_KERNEL_RO (__PAGE_KERNEL & ~_PAGE_RW)
#define __PAGE_KERNEL_RX (__PAGE_KERNEL_EXEC & ~_PAGE_RW)
#define __PAGE_KERNEL_NOCACHE (__PAGE_KERNEL | _PAGE_PCD | _PAGE_PWT)
--
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/2] Kprobes: Move kprobes examples to samples/
* Ingo Molnar ([EMAIL PROTECTED]) wrote: > > * Ananth N Mavinakayanahalli <[EMAIL PROTECTED]> wrote: > > > > feature request: please make this work in the !modular case as well > > > - if built-in then it should just run sometime during bootup and run > > > the tests and report success/failure. This way automated testing can > > > pick up any regressions much easier. > > > > Will try cook up something along those lines. It'll be easy to verify > > if the probes inserted and removed properly, but verifying handlers > > run correctly will need some work. > > > > We have a sort of regression test bucket that uses expect to parse the > > dmesg to verify handlers did run correctly; that isn't a totally > > in-kernel solution anyway. I have a couple of ideas in mind to make it > > easier. > > Great. Would be really nice to have something along the lines of > CONFIG_DEBUG_LOCKING_API_SELFTESTS. Those unit tests took time to > develop, but they caught more than 90% (!) of the internal lockdep > engine bugs before they ever hit mainline. > I would just like to point out that the samples/ directory should keep files as easy to read and understand for newcomers (it is meant to be compiled Documentation examples). I see the interest in turning it into a regression test too, but I would recommend leaving the "test" code out of the sample module itself to improve readability. Mathieu > Ingo -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 -- 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] teach checkpatch.pl about list_for_each
On Jan. 03, 2008, 14:30 +0200, Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
wrote:
> Em Thu, Jan 03, 2008 at 12:26:10PM +, Christoph Hellwig escreveu:
>> On Thu, Jan 03, 2008 at 11:10:58AM +, Andy Whitcroft wrote:
>>> We have had some stabs at changing this, but no consensus was reached on
>>> whether it was a "for" or a "function". My memory is of there being
>>> slightly more "without a space" tenders than the other and so it has not
>>> been changed. This thread also seems so far to have not really
>>> generated a concensus. So I would tend to leave things as they are.
>>>
>>> A third option might be to accept either on *for_each* constructs.
>>> That might tend to lead to divergance. Difficult. However, also see my
>>> later comments on "style guide".
>> Pretty much all core code uses list_for_each_entry( so new code should
>> follow that example.
>
> Agreed, CodingStyle is not about mindless consistency such as "for (" is
> the right thing, so "list_for_each (" is consistent with it, it is about
> codifying practice contributors got used to over the years.
>
Why mindless?
Coding style is also about giving the coding language logic a graphical
representation. Following a convention that flow control keywords
such as "if", "for", or "while" are distinguished from function calls
by use of a space after the keyword really helps the code readability
regardless of how people used to code it in the past...
The for_each_* macros are clearly not function calls but rather translate
to for () flow control constructs hence they should follow the same convention.
FWIW, I think that changing the existing convention is worth it in this case.
Benny
> - Arnaldo
--
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: [RFC] sample kset/ktype/kobject implementation code
On Wed, 19 Dec 2007 16:31:35 -0800,
Greg KH <[EMAIL PROTECTED]> wrote:
> /*
>* Initialize and add the kobject to the kernel. All the default files
>* will be created here. As we have already specified a kset for this
>* kobject, we don't have to set a parent for the kobject, the kobject
>* will be placed beneath that kset automatically.
>*/
> retval = kobject_init_and_add(>kobj, _ktype, NULL, "%s", name);
> if (retval) {
> kfree(foo);
> return NULL;
> }
I really hate to say this, but the example is still wrong. There needs
to be a kobject_put(>kobj) instead of the kfree(foo) (as the
comments for kobject_init_and_add() resp. kobject_add_ng() correctly
explain :))
--
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/
regression w.r.t. problems #lilo when an usb-key is present: problem no longer
I reported a regression, that when a usb-key is connected, #lilo produces a bootloader which don't work, on 2.6.24-rc6-git2, diferently to kernels before. Yesterday I compiled 2.6.24-rc6-git8 with exactly the same kernel parameters, with this, the problem didnt occure again, on the same 2 computers. Thus probably the problem was resolved == *** www.copaya.yi.org / www.monkey.is-a-geek.net *** O único servidor comunitário na Guiana-Francesa. Situado no local, rápido, imuno contra guerras / desastres na Europa. Serviço não-comercial e gratuito de: http (forum, página web), irc (chat), ftp (download), name (subdomain) .
Re: serial console _after_ boot ? - was: Redirect kernel console
On Jan 3 2008 15:39, [EMAIL PROTECTED] wrote:
>fantastic, thanks!
>
>unfortunately..
>
>opensuse103:/home/roland/serialcons # ./mytioccons
>ioctl: Device or resource busy
>
>but i`m not deep enough into programming to understand this.
>
>int main(void)
>{
>int fd = open("/dev/ttyS0", O_RDWR);
>int errno;
This errno is so out of place.
>
>ioctl(0, TIOCCONS, NULL);
>
>if (ioctl(fd, TIOCCONS, NULL) < 0)
>printf("ioctl: %s\n", strerror(errno));
>}
--
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: [x86] kernel/audit.c cleanup according to checkpatch.pl
On Thu, 2008-01-03 at 17:50 +0300, Cyrill Gorcunov wrote: > > > so what i would do now? i could post updated patch *without* that > splitted line, should I? And with the if (rc == 0) thing fixed too. Yes please. -- dwmw2 -- 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: [x86] kernel/audit.c cleanup according to checkpatch.pl
[David Woodhouse - Thu, Jan 03, 2008 at 02:37:24PM +] | | On Thu, 2008-01-03 at 15:37 +0100, Ingo Molnar wrote: | > * David Woodhouse <[EMAIL PROTECTED]> wrote: | > | > > On Thu, 2008-01-03 at 15:05 +0100, Ingo Molnar wrote: | > > > not to make a big issue out of this, but when was the last time you | > > > tried to grep this way: | > > > | > > > grep -E "audit_rate_limit=[0-9]+ audit_backlog" */*.c | > > | > > Not precisely that, but I've certainly had greps fail because people | > > have split up strings to meet the stupid 80-character "limit". | > | > yes - but if you read my whole reply you'll see that i qualified it: | > | > >> That's pretty much the only grep pattern that would break. People | > >> usually grep on the constant portion of the string, so breaking up a | > >> ^ | > >> line along a variable boundary is perfectly okay. | | Yes, you did. But you failed to provide any good reason for actually | changing it, either. Leave it as it was. | | -- | dwmw2 | so what i would do now? i could post updated patch *without* that splitted line, should I? - Cyrill - -- 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: [GIT] More NFS client fixes for 2.6.24-rc6
On Thu, 2008-01-03 at 10:30 +0100, Ingo Molnar wrote: > * Trond Myklebust <[EMAIL PROTECTED]> wrote: > > > commit 53478daff2c8b494d2af1ede6611f166f81bc393 > > Author: Trond Myklebust <[EMAIL PROTECTED]> > > Date: Wed Jan 2 13:28:57 2008 -0500 > > > > NFS: Fix a possible Oops in fs/nfs/super.c > > > > Sigh... commit 4584f520e1f773082ef44ff4f8969a5d992b16ec (NFS: Fix NFS > > mountpoint crossing...) had a slight flaw: server can be NULL if sget() > > returned an existing superblock. > > > > Fix the fix by dereferencing s->s_fs_info. > > > > Also add in the same namespace Oops fix for NFSv4 in both the mountpoint > > crossing case, and the referral case. > > > > Signed-off-by: Trond Myklebust <[EMAIL PROTECTED]> > > shouldnt this commit have included the full credit of the bugfix: > > http://bugzilla.kernel.org/show_bug.cgi?id=9647 > > > > Description From Adrian Bunk 2007-12-27 12:36 > > The Coverity checker spotted that commit > 4584f520e1f773082ef44ff4f8969a5d992b16ec introduced the following NULL > dereference in 2.6.24-rc6: Point taken, however I assume that a reference to the bugzilla report should suffice. I've therefore updated the commit changelog to read as follows: NFS: Fix a possible Oops in fs/nfs/super.c Sigh... commit 4584f520e1f773082ef44ff4f8969a5d992b16ec (NFS: Fix NFS mountpoint crossing...) had a slight flaw: server can be NULL if sget() returned an existing superblock. Fix the fix by dereferencing s->s_fs_info. Thanks to Coverity/Adrian Bunk and Frank Filz for spotting the bug. (See http://bugzilla.kernel.org/show_bug.cgi?id=9647) Also add in the same namespace Oops fix for NFSv4 in both the mountpoint crossing case, and the referral case. Signed-off-by: Trond Myklebust <[EMAIL PROTECTED]> Cheers Trond -- 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: serial console _after_ boot ? - was: Redirect kernel console
fantastic, thanks!
unfortunately..
opensuse103:/home/roland/serialcons # ./mytioccons
ioctl: Device or resource busy
but, it`s not userspace:
opensuse103:/home/roland # lsof |egrep "console|ttyS0"
opensuse103:/home/roland #
in tty_io.c -> ticoccons() there is
if (redirect) {
spin_unlock(_lock);
return -EBUSY;
}
but i`m not deep enough into programming to understand this.
---
mytioccons.c
#include
#include
#include
#include
#include
#include
#include
int main(void)
{
int fd = open("/dev/ttyS0", O_RDWR);
int errno;
ioctl(0, TIOCCONS, NULL);
if (ioctl(fd, TIOCCONS, NULL) < 0)
printf("ioctl: %s\n", strerror(errno));
}
---
> -Ursprüngliche Nachricht-
> Von: "Jan Engelhardt" <[EMAIL PROTECTED]>
> Gesendet: 03.01.08 14:28:45
> An: [EMAIL PROTECTED]
> CC: linux-kernel@vger.kernel.org
> Betreff: Re: serial console _after_ boot ? - was: Redirect kernel console
>
>
> On Jan 3 2008 13:43, [EMAIL PROTECTED] wrote:
> >
> >hi !
> >
> >i was wondering how to make kernel messages appear on /dev/ttyS0 without a
> >reboot, i.e. kernelparam "console=ttyS0"
>
> The solution is simple... the following piece of code is inside
> opensuse-10.3/src/sysvinit-2.86-115.src.rpm#showconsole-1.08.tar.bz2#showconsole-1.08/blogd.c
>
> (void)ioctl(0, TIOCCONS, NULL); /* Undo any current map if any */
> if (ioctl(pts, TIOCCONS, NULL) < 0)
> error("can not set console device to %s: %s\n", ptsname,
> strerror(errno));
>
> so I suppose that's it. Write up a new program that calls the ioctl
> on a tty, and you should be done. IOW:
>
> #include
> #include
> #include
> #include
>
> int main(void)
> {
> int fd = open("/dev/ttyS0", O_RDWR);
> ioctl(0, TIOCCONS, NULL);
> ioctl(fd, TIOCCONS, NULL);
> }
>
__
Erweitern Sie FreeMail zu einem noch leistungsstärkeren E-Mail-Postfach!
Mehr Infos unter http://produkte.web.de/club/?mc=021131
--
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: [x86] kernel/audit.c cleanup according to checkpatch.pl
On Thu, 2008-01-03 at 15:37 +0100, Ingo Molnar wrote: > * David Woodhouse <[EMAIL PROTECTED]> wrote: > > > On Thu, 2008-01-03 at 15:05 +0100, Ingo Molnar wrote: > > > not to make a big issue out of this, but when was the last time you > > > tried to grep this way: > > > > > > grep -E "audit_rate_limit=[0-9]+ audit_backlog" */*.c > > > > Not precisely that, but I've certainly had greps fail because people > > have split up strings to meet the stupid 80-character "limit". > > yes - but if you read my whole reply you'll see that i qualified it: > > >> That's pretty much the only grep pattern that would break. People > >> usually grep on the constant portion of the string, so breaking up a > >> ^ > >> line along a variable boundary is perfectly okay. Yes, you did. But you failed to provide any good reason for actually changing it, either. Leave it as it was. -- dwmw2 -- 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: [x86] kernel/audit.c cleanup according to checkpatch.pl
* David Woodhouse <[EMAIL PROTECTED]> wrote: > On Thu, 2008-01-03 at 15:05 +0100, Ingo Molnar wrote: > > not to make a big issue out of this, but when was the last time you > > tried to grep this way: > > > > grep -E "audit_rate_limit=[0-9]+ audit_backlog" */*.c > > Not precisely that, but I've certainly had greps fail because people > have split up strings to meet the stupid 80-character "limit". yes - but if you read my whole reply you'll see that i qualified it: >> That's pretty much the only grep pattern that would break. People >> usually grep on the constant portion of the string, so breaking up a >> ^ >> line along a variable boundary is perfectly okay. >> Ingo -- 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: [x86] kernel/audit.c cleanup according to checkpatch.pl
On Thu, 2008-01-03 at 15:05 +0100, Ingo Molnar wrote: > not to make a big issue out of this, but when was the last time you > tried to grep this way: > > grep -E "audit_rate_limit=[0-9]+ audit_backlog" */*.c Not precisely that, but I've certainly had greps fail because people have split up strings to meet the stupid 80-character "limit". Leave it as it was. Also, please don't add 'if (rc == 0)'. Use 'if (rc)' instead. -- dwmw2 -- 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: isofs oops - d_splice_alias+0x1f (2.6.24-rc5-mm1)
On 01/03/2008 02:51 PM, Pekka J Enberg wrote:
> Hi Jiri,
>
> On Thu, 3 Jan 2008, Jiri Slaby wrote:
>> this happened, while playing with broken dvd.
>
> [snip]
>
>> Buffer I/O error on device sr0, logical block 5441
>> end_request: I/O error, dev sr0, sector 136
>> ISOFS: unable to read i-node block
>> Unable to handle kernel NULL pointer dereference at 00ad RIP:
>> [] d_splice_alias+0x1f/0x100
>
> [snip]
>
>> Call Trace:
>> [] :isofs:isofs_lookup+0x395/0x4a0
>> [] d_alloc+0x2b/0x1d0
>> [] do_lookup+0x1ac/0x200
>
> Does the following patch fix it?
>
> Pekka
>
> [PATCH] isofs: check for bad inode in isofs_lookup
> From: Pekka Enberg <[EMAIL PROTECTED]>
>
> If isofs_read_inode() fails to read one of the inode blocks from disk, it
> returns a bad inode.
>
> Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
> ---
> fs/isofs/namei.c |5 +
> 1 file changed, 5 insertions(+)
>
> Index: linux-2.6/fs/isofs/namei.c
> ===
> --- linux-2.6.orig/fs/isofs/namei.c
> +++ linux-2.6/fs/isofs/namei.c
> @@ -183,6 +183,11 @@ struct dentry *isofs_lookup(struct inode
> unlock_kernel();
> return ERR_PTR(-EACCES);
> }
> + if (is_bad_inode(inode)) {
> + unlock_kernel();
> + iput(inode);
> + return ERR_PTR(-ENOENT);
> + }
> }
> unlock_kernel();
> return d_splice_alias(inode, dentry);
Can't say, the DVD seems to be OK, I don't know what was wrong (as I can say,
this happened several times in the past yet and after reboot everything OK; I
suspect gnome auto mounter -- multiple machines, several DVD ROMs, same disk
with OS, similar errors, but that's too few to report).
--
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: isofs oops - d_splice_alias+0x1f (2.6.24-rc5-mm1)
On Thu, Jan 03, 2008 at 03:11:20PM +0100, Ingo Molnar wrote: > and there are about 5 other callsites as well that only check for a NULL > return. ... except that this is *not* getting NULL or make_bad_inode(); that's getting ERR_PTR(), which can't happen in mainline. So that looks like an -mm patch changing calling conventions and not updating callers... -- 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: isofs oops - d_splice_alias+0x1f (2.6.24-rc5-mm1)
* Pekka J Enberg <[EMAIL PROTECTED]> wrote:
> return ERR_PTR(-EACCES);
> }
> + if (is_bad_inode(inode)) {
> + unlock_kernel();
> + iput(inode);
> + return ERR_PTR(-ENOENT);
> + }
fs/isofs/rock.c:474 parse_rock_ridge_inode_internal() seems buggy too:
reloc =
isofs_iget(inode->i_sb,
ISOFS_I(inode)->i_first_extent,
0);
if (!reloc)
goto out;
it should probably do "!reloc || is_bad_inode(inode)" as well.
and there are about 5 other callsites as well that only check for a NULL
return.
perhaps the better fix would be to add this to inode.c:isofs_iget():
if (inode && (inode->i_state & I_NEW)) {
sb->s_op->read_inode(inode);
unlock_new_inode(inode);
if (s_bad_inode(inode))
inode = NULL;
}
?
Ingo
--
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: isofs oops - d_splice_alias+0x1f (2.6.24-rc5-mm1)
On Thu, Jan 03, 2008 at 03:51:28PM +0200, Pekka J Enberg wrote: > Does the following patch fix it? Highly doubtful, and doesn't deal with the real problem, AFAICS... -- 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: isofs oops - d_splice_alias+0x1f (2.6.24-rc5-mm1)
On Thu, Jan 03, 2008 at 02:23:44PM +0100, Jiri Slaby wrote:
> ISOFS: unable to read i-node block
isofs_read_inode() failing, about to do make_bad_inode()
> Unable to handle kernel NULL pointer dereference at 00ad RIP:
> [] d_splice_alias+0x1f/0x100
struct dentry *d_splice_alias(struct inode *inode, struct dentry *dentry)
{
struct dentry *new = NULL;
if (inode && S_ISDIR(inode->i_mode)) {
^
> RIP: 0010:[] [] d_splice_alias+0x1f/0x100
> RSP: :810061543b08 EFLAGS: 00010282
> RAX: RBX: fffb RCX: 880d3454
> RDX: 810048542750 RSI: 81005e114e10 RDI: fffb
with inode equal to (struct inode *)-5. Which is ERR_PTR(-EIO)...
> [] :isofs:isofs_lookup+0x395/0x4a0
inode = NULL;
if (found) {
inode = isofs_iget(dir->i_sb, block, offset);
if (!inode) {
unlock_kernel();
return ERR_PTR(-EACCES);
}
}
unlock_kernel();
return d_splice_alias(inode, dentry);
So we've got ERR_PTR(-EIO) from isofs_iget(). Bloody odd, seeing that
isofs_iget() either explicitly returns NULL or does
if (inode && (inode->i_state & I_NEW)) {
sb->s_op->read_inode(inode);
unlock_new_inode(inode);
}
return inode;
which would not manage to return ERR_PTR(-EIO), no matter what - it would
die on access to inode->i_state. I don't have -mm tree at hand, check if
there's anything affected in these areas. Perhaps somebody tried to pass
error values from isofs_iget() and forgot to update callers?
--
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: [RFC PATCH 01/11] Add basic support for gcc profiler instrumentation
Hi Sam! On Thu, 3 Jan 2008, Sam Ravnborg wrote: > > --- > > > > Index: linux-compile.git/Documentation/stable_api_nonsense.txt > > === > > --- linux-compile.git.orig/Documentation/stable_api_nonsense.txt > > 2008-01-03 01:02:28.0 -0500 > > +++ linux-compile.git/Documentation/stable_api_nonsense.txt 2008-01-03 > > 01:02:33.0 -0500 > > @@ -62,6 +62,9 @@ consider the following facts about the L > >- different structures can contain different fields > >- Some functions may not be implemented at all, (i.e. some locks > > compile away to nothing for non-SMP builds.) > > + - Parameter passing of variables from function to function can be > > + done in different ways (the CONFIG_REGPARM option controls > > + this.) > > As CONFIG_REGPARM affects calling convention we should add it to the > list of symbols checked when loading modules (vermagic.h). Good point, thanks for mentioning this. > > Index: linux-compile.git/Makefile > > === > > --- linux-compile.git.orig/Makefile 2008-01-03 01:02:28.0 -0500 > > +++ linux-compile.git/Makefile 2008-01-03 01:02:39.0 -0500 > > @@ -509,11 +509,15 @@ endif > > > > include $(srctree)/arch/$(SRCARCH)/Makefile > > > > +ifdef CONFIG_MCOUNT > > +KBUILD_CFLAGS += -pg -fno-omit-frame-pointer > > -fno-optimize-sibling-calls > > +else > > ifdef CONFIG_FRAME_POINTER > > KBUILD_CFLAGS += -fno-omit-frame-pointer -fno-optimize-sibling-calls > > else > > KBUILD_CFLAGS += -fomit-frame-pointer > > endif > > +endif > Could we please move these relations to Kconfig. So we do not end up in a > situation > where CONFIG_FRAME_POINTER is set but the flag is not added. Yes, most definitely. I thought this part was a bit sloppy, but it "worked". My next series will clean this up. > > > > > > ifdef CONFIG_DEBUG_INFO > > KBUILD_CFLAGS += -g > > Index: linux-compile.git/arch/x86/Kconfig > > === > > --- linux-compile.git.orig/arch/x86/Kconfig 2008-01-03 01:02:28.0 > > -0500 > > +++ linux-compile.git/arch/x86/Kconfig 2008-01-03 01:02:33.0 > > -0500 > > @@ -28,6 +28,12 @@ config GENERIC_CMOS_UPDATE > > bool > > default y > > > > +# function tracing might turn this off: > > +config REGPARM > > + bool > > + depends on !MCOUNT > > + default y > > + > > Could we please define config REGPARM in _one_ Kconfig file > and let those who want it select it. > If you consider this x86 spacific this should be included in the naming > as in CONFIG_X86_REGPARM - and then the above is OK. This is pending on resolving what effects REGPARM really has on mcount. But, I'll keep REGPARM until it's solved, and in the mean time I'll clean it up as you asked. > > Defining the same config variable in several files is not good (but done too > often these days). > > > Index: linux-compile.git/lib/mcount/Makefile > > === > > --- /dev/null 1970-01-01 00:00:00.0 + > > +++ linux-compile.git/lib/mcount/Makefile 2008-01-03 01:02:33.0 > > -0500 > > @@ -0,0 +1,3 @@ > > +obj-$(CONFIG_MCOUNT) += libmcount.o > > + > > +libmcount-objs := mcount.o > > Preferred syntax is now: > libmcount-y := mcount.o Ah! I learn something new every day :-) Yeah, I stumbled over a few updates in formats with the makefiles. Thanks! -- Steve -- 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: [x86] kernel/audit.c cleanup according to checkpatch.pl
* Jörn Engel <[EMAIL PROTECTED]> wrote: > > - "audit: audit_lost=%d audit_rate_limit=%d > > audit_backlog_limit=%d\n", > > + "audit: audit_lost=%d audit_rate_limit=%d " > > + "audit_backlog_limit=%d\n", > >atomic_read(_lost), > >audit_rate_limit, > >audit_backlog_limit); > > This hunk is a bit questionable. It can easily deceive a reader to > assume two seperate lines printed out and sometimes defeats grepping > for printk output to find the code generating the message. not to make a big issue out of this, but when was the last time you tried to grep this way: grep -E "audit_rate_limit=[0-9]+ audit_backlog" */*.c ? That's pretty much the only grep pattern that would break. People usually grep on the constant portion of the string, so breaking up a line along a variable boundary is perfectly okay. Ingo -- 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/3] CONFIG_HIGHPTE vs. sub-page page tables.
On Thu, Jan 03 2008 at 15:12 +0200, Andi Kleen <[EMAIL PROTECTED]> wrote: >> Can we please just nuke CONFIG_HIGHPTE? There's only been a small >> amount of 32bit machines > > It's unfortunately a larger amount :/ And for unknown reasons a lot of > people still install 32bit kernels on new perfectly capable 64bit systems > even if they have a lot of memory. > Yes I've seen that too many times. When I comment about it, people say: "What this 'core 2' supports AMD64 ??!!" I think this is the distros fault. 1. Most call it AMD64 and not, i don't know what it should be called. 2. They put the first and default installation as i386 and not the x64, the later is only farther down or on a different link. 3. My Fedora x86_64 installation has a full blown 32bit installation inside. In fact, every time I yum install this or that, I get installed by default both the 64bit and 32bit libraries. I don't even know how to turn the 32bit off. This means that Distros can supply one x86 installation for both flavors and decide at setup time what to install. By this, follow the Kernel in observing that it is the same-ARCH same-INSTALL. 4. Some binary modules like Flash, media-codecs acrobat-reader etc... think (That snow ball effect here) that 32bit is much more common and only provide that. So people think that for best compatibility they should stick with 32bit. But this is not true. They all work perfectly here in 64bit land. Distros should both confirm on that publicly. And also make extensive tests for 32bit compatibility on 64bit machines, even for these binary only bad guys. 5. Distros should jump on the 64bit bang-wagon, to stand it-self apart from Window 32bit-ness. It has bin proven more than once that a Huge Linux 64bit machine, with lots of CPUs and memory, can be the best Windows 32bit performer in existence. Both under KVM/VMWARE or Wine. 64bit Vista can never get close, not to speak of the "none-existent" 64bit XP. Just my $0.02 Boaz > I don't think removing CONFIG_HIGHPTE will be an option any time soon. > > -Andi > -- -- 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] w1-gpio: Add GPIO w1 bus master driver
On Thu, 3 Jan 2008 15:48:35 +0200
Ville Syrjälä <[EMAIL PROTECTED]> wrote:
> On Wed, Dec 26, 2007 at 11:24:54PM +0100, Haavard Skinnemoen wrote:
> > On Fri, 21 Dec 2007 09:34:01 +0200
> > Ville Syrjala <[EMAIL PROTECTED]> wrote:
> >
> > > +static struct platform_device foo_w1_device = {
> > > + .name = "w1-gpio",
> > > + .id = -1,
> >
> > Assigning -1 to a u32 member isn't a very nice example. What does it
> > mean anyway?
>
> id is 'int'. The bus_name won't include the id when -1 is used.
Ah, indeed. I was looking at 2.6.23, where it is u32.
> > ...call platform_driver_probe(_gpio_driver, w1_gpio_probe) here.
>
> I was wondering what platform_driver_probe() was for but never bothered
> to read the code. I'll change the code to use it.
>
> I already sent an updated patch but forgot to send this reply.
I saw it. Thanks :)
Haavard
--
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: [RFC PATCH 01/11] Add basic support for gcc profiler instrumentation
[Added Chris Wright, Rusty and Virt list because they were involved with this issue before] On Thu, 3 Jan 2008, Ingo Molnar wrote: > > * Steven Rostedt <[EMAIL PROTECTED]> wrote: > > > +# function tracing might turn this off: > > +config REGPARM > > + bool > > + depends on !MCOUNT > > + default y > > are you sure -pg really needs this? Nope! Arnaldo and I only carried it because you had it ;-) > I just carried this along the years > and went the path of least resistence, but we should not be > reintroducing the !REGPARM build mode for the kernel. I'd not be > surprised if there were a few issues with REGPARM + mcount, but we have > to figure it out before merging ... Hmm, I know paravirt-ops had an issue with mcount in the RT tree. I can't remember the exact issues, but it did have something to do with the way parameters were passed in. Chris, do you remember what the issues were? I'm also thinking that this is only an i386 issue. Thanks, -- Steve -- 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: isofs oops - d_splice_alias+0x1f (2.6.24-rc5-mm1)
Hi Jiri,
On Thu, 3 Jan 2008, Jiri Slaby wrote:
> this happened, while playing with broken dvd.
[snip]
> Buffer I/O error on device sr0, logical block 5441
> end_request: I/O error, dev sr0, sector 136
> ISOFS: unable to read i-node block
> Unable to handle kernel NULL pointer dereference at 00ad RIP:
> [] d_splice_alias+0x1f/0x100
[snip]
> Call Trace:
> [] :isofs:isofs_lookup+0x395/0x4a0
> [] d_alloc+0x2b/0x1d0
> [] do_lookup+0x1ac/0x200
Does the following patch fix it?
Pekka
[PATCH] isofs: check for bad inode in isofs_lookup
From: Pekka Enberg <[EMAIL PROTECTED]>
If isofs_read_inode() fails to read one of the inode blocks from disk, it
returns a bad inode.
Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
---
fs/isofs/namei.c |5 +
1 file changed, 5 insertions(+)
Index: linux-2.6/fs/isofs/namei.c
===
--- linux-2.6.orig/fs/isofs/namei.c
+++ linux-2.6/fs/isofs/namei.c
@@ -183,6 +183,11 @@ struct dentry *isofs_lookup(struct inode
unlock_kernel();
return ERR_PTR(-EACCES);
}
+ if (is_bad_inode(inode)) {
+ unlock_kernel();
+ iput(inode);
+ return ERR_PTR(-ENOENT);
+ }
}
unlock_kernel();
return d_splice_alias(inode, dentry);
--
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] w1-gpio: Add GPIO w1 bus master driver
On Wed, Dec 26, 2007 at 11:24:54PM +0100, Haavard Skinnemoen wrote:
> On Fri, 21 Dec 2007 09:34:01 +0200
> Ville Syrjala <[EMAIL PROTECTED]> wrote:
>
> > +static struct platform_device foo_w1_device = {
> > + .name = "w1-gpio",
> > + .id = -1,
>
> Assigning -1 to a u32 member isn't a very nice example. What does it
> mean anyway?
id is 'int'. The bus_name won't include the id when -1 is used.
> > +static int __init w1_gpio_probe(struct platform_device *pdev)
>
> This must be __devinit, or if you want to save a bit of memory...
>
> > + .probe = w1_gpio_probe,
>
> ...remove this line, and...
>
> > +static int __init w1_gpio_init(void)
> > +{
> > + return platform_driver_register(_gpio_driver);
>
> ...call platform_driver_probe(_gpio_driver, w1_gpio_probe) here.
I was wondering what platform_driver_probe() was for but never bothered
to read the code. I'll change the code to use it.
I already sent an updated patch but forgot to send this reply.
--
Ville Syrjälä
[EMAIL PROTECTED]
http://www.sci.fi/~syrjala/
--
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/
Ban can ho cao cap V-Star (Korea) Quan 7, TP.HCM Gia Dac Biet Dau nam 2008
Chao cac ban, Ban nhan duoc email nay la do ban hoac mot ai do da dang ky dia chi email cua ban tai trang web: www.nhaban.net.tf, www.nhaban.vnn.bz, www.nhadep.us de nhan cac thong tin nha dat moi nhat cua chung toi. Nay chung toi han hanh thong bao voi cac ban cac can ho cao cap chung toi dang chao ban (CHI CON CO 2 CAN- DEP NHAT -GIA TOT NHAT). Chung toi can ban mot so can ho cao cap V-Star cua Han Quoc xay dung o quan 7 (RAT GAN PHU MY HUNG), TP.HCM Vi tri tuyet voi, cac can ho thiet ke rat dep, hien dai, tien nghi, an ninh...va rat nhieu cac tien ich khac. Ban co the xem bai viet cua BAO SAI GON GIAI PHONG (20/05/2007) o Website: http://www.canhocaocap.net/page.asp?nha=21 Can ho rat thich hop voi moi doi tuong, co the dung de o hoac dau tu... TOA NHA V-STAR DA HOAN THIEN PHAN MONG VA TANG HAM Moi quy khach vao xem chi tiet cu the o website: http://www.canhocaocap.net Ban co the xem cac hinh anh toa nha, phong oc, cac tien ich, ban do... email: [EMAIL PROTECTED] Ngoai ra ban co the xem cac hinh kien truc nha dep o Sai Gon ( http://nhadep.us ) Xin cam on da xem tin *** V-Star- Vstar- vstar - vsta - vta - korea -- 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/
isofs oops - d_splice_alias+0x1f (2.6.24-rc5-mm1)
Hi, this happened, while playing with broken dvd. ISO 9660 Extensions: Microsoft Joliet Level 3 ISO 9660 Extensions: RRIP_1991A end_request: I/O error, dev sr0, sector 21760 Buffer I/O error on device sr0, logical block 5440 Buffer I/O error on device sr0, logical block 5441 Buffer I/O error on device sr0, logical block 5442 Buffer I/O error on device sr0, logical block 5443 Buffer I/O error on device sr0, logical block 5444 Buffer I/O error on device sr0, logical block 5445 Buffer I/O error on device sr0, logical block 5446 Buffer I/O error on device sr0, logical block 5447 Buffer I/O error on device sr0, logical block 5448 Buffer I/O error on device sr0, logical block 5449 end_request: I/O error, dev sr0, sector 1447344 end_request: I/O error, dev sr0, sector 1447344 end_request: I/O error, dev sr0, sector 21808 end_request: I/O error, dev sr0, sector 21812 end_request: I/O error, dev sr0, sector 21760 end_request: I/O error, dev sr0, sector 21760 end_request: I/O error, dev sr0, sector 21760 end_request: I/O error, dev sr0, sector 21764 end_request: I/O error, dev sr0, sector 21760 end_request: I/O error, dev sr0, sector 21764 end_request: I/O error, dev sr0, sector 21760 end_request: I/O error, dev sr0, sector 21764 end_request: I/O error, dev sr0, sector 21760 end_request: I/O error, dev sr0, sector 21764 end_request: I/O error, dev sr0, sector 21760 end_request: I/O error, dev sr0, sector 21764 end_request: I/O error, dev sr0, sector 21760 end_request: I/O error, dev sr0, sector 21764 end_request: I/O error, dev sr0, sector 21760 printk: 40 messages suppressed. Buffer I/O error on device sr0, logical block 5440 Buffer I/O error on device sr0, logical block 5441 end_request: I/O error, dev sr0, sector 136 ISOFS: unable to read i-node block Unable to handle kernel NULL pointer dereference at 00ad RIP: [] d_splice_alias+0x1f/0x100 PGD 67f1a067 PUD 67e15067 PMD 0 Oops: [1] SMP last sysfs file: /sys/devices/platform/coretemp.1/temp1_input CPU 0 Modules linked in: isofs tun bitrev ipv6 arc4 ecb crypto_blkcipher cryptomgr cry pto_algapi ath5k mac80211 cfg80211 rtc_cmos rtc_core rtc_lib crc32 floppy ehci_h cd sr_mod cdrom Pid: 3096, comm: nautilus Not tainted 2.6.24-rc5-mm1_64 #354 RIP: 0010:[] [] d_splice_alias+0x1f/0x100 RSP: :810061543b08 EFLAGS: 00010282 RAX: RBX: fffb RCX: 880d3454 RDX: 810048542750 RSI: 81005e114e10 RDI: fffb RBP: 810061543b28 R08: 0049 R09: 8000 R10: R11: 0001 R12: 81005e114e10 R13: 81005e2b11c0 R14: 0003 R15: 013c FS: 42123950(0063) GS:8065() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 00ad CR3: 67d2f000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process nautilus (pid: 3096, threadinfo 810061542000, task 810048542750) Stack: 81007c0799c0 fffb 81007c0799c0 81005e2b11c0 810061543bd8 880d2395 802a565b 81005e114e10 81005e2ec030 8100638a3000 e200015c63a8 0022 Call Trace: [] :isofs:isofs_lookup+0x395/0x4a0 [] d_alloc+0x2b/0x1d0 [] do_lookup+0x1ac/0x200 [] __link_path_walk+0x827/0xd10 [] link_path_walk+0x63/0xe0 [] free_pages_and_swap_cache+0x9f/0xd0 [] unmap_region+0x135/0x150 [] kmem_cache_free+0x15/0xa0 [] __pagevec_free+0x26/0x30 [] path_walk+0x1c/0x20 [] do_path_lookup+0x83/0x1b0 [] __user_walk_fd+0x4c/0x80 [] vfs_lstat_fd+0x2b/0x70 [] free_pages_and_swap_cache+0x9f/0xd0 [] unmap_region+0x135/0x150 [] kmem_cache_free+0x15/0xa0 [] sys_newlstat+0x27/0x50 [] up_write+0x9/0x10 [] sys_munmap+0x55/0x70 [] system_call+0x7e/0x83 Code: 0f b7 87 b2 00 00 00 25 00 f0 00 00 3d 00 40 00 00 74 27 48 RIP [] d_splice_alias+0x1f/0x100 RSP CR2: 00ad regards, -- Jiri Slaby ([EMAIL PROTECTED]) Faculty of Informatics, Masaryk University -- 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: serial console _after_ boot ? - was: Redirect kernel console
On Jan 3 2008 13:43, [EMAIL PROTECTED] wrote:
>
>hi !
>
>i was wondering how to make kernel messages appear on /dev/ttyS0 without a
>reboot, i.e. kernelparam "console=ttyS0"
The solution is simple... the following piece of code is inside
opensuse-10.3/src/sysvinit-2.86-115.src.rpm#showconsole-1.08.tar.bz2#showconsole-1.08/blogd.c
(void)ioctl(0, TIOCCONS, NULL); /* Undo any current map if any */
if (ioctl(pts, TIOCCONS, NULL) < 0)
error("can not set console device to %s: %s\n", ptsname,
strerror(errno));
so I suppose that's it. Write up a new program that calls the ioctl
on a tty, and you should be done. IOW:
#include
#include
#include
#include
int main(void)
{
int fd = open("/dev/ttyS0", O_RDWR);
ioctl(0, TIOCCONS, NULL);
ioctl(fd, TIOCCONS, NULL);
}
--
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/
[RESEND PATCH 10/10] ide-floppy: replace ntoh{s,l} and hton{s,l} calls with the generic byteorder macros
Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]>
---
drivers/ide/ide-floppy.c | 28 ++--
1 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/ide/ide-floppy.c b/drivers/ide/ide-floppy.c
index 6c29b5f..ddab66c 100644
--- a/drivers/ide/ide-floppy.c
+++ b/drivers/ide/ide-floppy.c
@@ -695,8 +695,8 @@ static void idefloppy_create_format_unit_cmd(idefloppy_pc_t
*pc, int b, int l,
pc->buffer[1] ^= 0x20; /* ... turn off DCRT bit */
pc->buffer[3] = 8;
- put_unaligned(htonl(b), (unsigned int *)(>buffer[4]));
- put_unaligned(htonl(l), (unsigned int *)(>buffer[8]));
+ put_unaligned(cpu_to_be32(b), (unsigned int *)(>buffer[4]));
+ put_unaligned(cpu_to_be32(l), (unsigned int *)(>buffer[8]));
pc->buffer_size=12;
set_bit(PC_WRITING, >flags);
}
@@ -723,7 +723,7 @@ static void idefloppy_create_mode_sense_cmd(idefloppy_pc_t
*pc, u8 page_code,
printk(KERN_ERR "ide-floppy: unsupported page code "
"in create_mode_sense_cmd\n");
}
- put_unaligned(htons(length), (u16 *) >c[7]);
+ put_unaligned(cpu_to_be16(length), (u16 *) >c[7]);
pc->request_transfer = length;
}
@@ -753,12 +753,12 @@ static void idefloppy_create_rw_cmd(idefloppy_t *floppy,
idefloppy_pc_t *pc,
idefloppy_init_pc(pc);
if (idefl_use_rw(floppy)) {
pc->c[0] = cmd == READ ? GPCMD_READ_12 : GPCMD_WRITE_12;
- put_unaligned(htonl(blocks), (unsigned int *) >c[6]);
+ put_unaligned(cpu_to_be32(blocks), (unsigned int *) >c[6]);
} else {
pc->c[0] = cmd == READ ? GPCMD_READ_10 : GPCMD_WRITE_10;
- put_unaligned(htons(blocks), (unsigned short *) >c[7]);
+ put_unaligned(cpu_to_be16(blocks), (unsigned short *)
>c[7]);
}
- put_unaligned(htonl(block), (unsigned int *) >c[2]);
+ put_unaligned(cpu_to_be32(block), (unsigned int *) >c[2]);
pc->callback = _rw_callback;
pc->rq = rq;
pc->b_count = cmd == READ ? 0 : rq->bio->bi_size;
@@ -890,10 +890,10 @@ static int idefloppy_get_flexible_disk_page(ide_drive_t
*drive)
set_disk_ro(floppy->disk, floppy->wp);
page = (idefloppy_flex_disk_page_t *) (header + 1);
- page->transfer_rate = ntohs(page->transfer_rate);
- page->sector_size = ntohs(page->sector_size);
- page->cyls = ntohs(page->cyls);
- page->rpm = ntohs(page->rpm);
+ page->transfer_rate = be16_to_cpu(page->transfer_rate);
+ page->sector_size = be16_to_cpu(page->sector_size);
+ page->cyls = be16_to_cpu(page->cyls);
+ page->rpm = be16_to_cpu(page->rpm);
capacity = page->cyls * page->heads * page->sectors * page->sector_size;
if (memcmp (page, >flex_disk_page,
@@ -972,8 +972,8 @@ static int idefloppy_get_capacity(ide_drive_t *drive)
descriptor = (idefloppy_cap_desc_t *) (header + 1);
for (i = 0; i < descriptors; i++, descriptor++) {
- blocks = descriptor->blocks = ntohl(descriptor->blocks);
- length = descriptor->length = ntohs(descriptor->length);
+ blocks = descriptor->blocks = be32_to_cpu(descriptor->blocks);
+ length = descriptor->length = be16_to_cpu(descriptor->length);
if (!i)
{
@@ -1100,8 +1100,8 @@ static int idefloppy_get_format_capacities(ide_drive_t
*drive, int __user *arg)
if (i == 0)
continue; /* Skip the first descriptor */
- blocks = ntohl(descriptor->blocks);
- length = ntohs(descriptor->length);
+ blocks = be32_to_cpu(descriptor->blocks);
+ length = be16_to_cpu(descriptor->length);
if (put_user(blocks, argp))
return(-EFAULT);
--
1.5.3.7
--
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/
[RESEND PATCH 06/10] ide-floppy: report DMA handling in idefloppy_pc_intr() properly
while at it:
-cleanup small issues raised by scripts/checkpatch.pl
-remove redundant and shorten some comments
There should be no functionality change resulting from this patch
Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]>
---
drivers/ide/ide-floppy.c | 195 --
1 files changed, 83 insertions(+), 112 deletions(-)
diff --git a/drivers/ide/ide-floppy.c b/drivers/ide/ide-floppy.c
index 7823447..5d0fd1f 100644
--- a/drivers/ide/ide-floppy.c
+++ b/drivers/ide/ide-floppy.c
@@ -5,9 +5,7 @@
* Copyright (C) 2000 - 2002 Paul Bristow <[EMAIL PROTECTED]>
*
* The driver currently doesn't have any fancy features, just the bare
- * minimum read/write support.
- *
- * This driver supports the following IDE floppy drives:
+ * minimum read/write support. It supports the following IDE floppy drives:
*
* LS-120/240 SuperDisk
* Iomega Zip 100/250
@@ -75,8 +73,8 @@ static void ide_floppy_put(struct ide_floppy_obj *floppy)
}
/*
- * Too bad. The drive wants to send us data which we are not ready to
accept.
- * Just throw it away.
+ * Too bad. The drive wants to send us data which we are not ready to accept.
+ * Just throw it away.
*/
static void idefloppy_discard_data (ide_drive_t *drive, unsigned int bcount)
{
@@ -94,10 +92,8 @@ static void idefloppy_write_zeros (ide_drive_t *drive,
unsigned int bcount)
/*
- * idefloppy_do_end_request is used to finish servicing a request.
- *
- * For read/write requests, we will call ide_end_request to pass to the
- * next buffer.
+ * Used to finish servicing a request. For read/write requests, we will call
+ * ide_end_request to pass to the next buffer.
*/
static int idefloppy_do_end_request(ide_drive_t *drive, int uptodate, int
nsecs)
{
@@ -128,7 +124,7 @@ static int idefloppy_do_end_request(ide_drive_t *drive, int
uptodate, int nsecs)
return 0;
}
-static void idefloppy_input_buffers (ide_drive_t *drive, idefloppy_pc_t *pc,
+static void idefloppy_input_buffers(ide_drive_t *drive, idefloppy_pc_t *pc,
unsigned int bcount)
{
struct request *rq = pc->rq;
@@ -162,7 +158,7 @@ static void idefloppy_input_buffers (ide_drive_t *drive,
idefloppy_pc_t *pc,
}
}
-static void idefloppy_output_buffers (ide_drive_t *drive, idefloppy_pc_t *pc,
+static void idefloppy_output_buffers(ide_drive_t *drive, idefloppy_pc_t *pc,
unsigned int bcount)
{
struct request *rq = pc->rq;
@@ -198,7 +194,7 @@ static void idefloppy_output_buffers (ide_drive_t *drive,
idefloppy_pc_t *pc,
#endif
}
-static void idefloppy_update_buffers (ide_drive_t *drive, idefloppy_pc_t *pc)
+static void idefloppy_update_buffers(ide_drive_t *drive, idefloppy_pc_t *pc)
{
struct request *rq = pc->rq;
struct bio *bio = rq->bio;
@@ -208,11 +204,11 @@ static void idefloppy_update_buffers (ide_drive_t *drive,
idefloppy_pc_t *pc)
}
/*
- * idefloppy_queue_pc_head generates a new packet command request in front
- * of the request queue, before the current request, so that it will be
- * processed immediately, on the next pass through the driver.
+ * Generates a new packet command request in front
+ * of the request queue, before the current request, so that it will be
+ * processed immediately, on the next pass through the driver.
*/
-static void idefloppy_queue_pc_head (ide_drive_t *drive,idefloppy_pc_t *pc,
+static void idefloppy_queue_pc_head(ide_drive_t *drive, idefloppy_pc_t *pc,
struct request *rq)
{
struct ide_floppy_obj *floppy = drive->driver_data;
@@ -224,7 +220,7 @@ static void idefloppy_queue_pc_head (ide_drive_t
*drive,idefloppy_pc_t *pc,
(void) ide_do_drive_cmd(drive, rq, ide_preempt);
}
-static idefloppy_pc_t *idefloppy_next_pc_storage (ide_drive_t *drive)
+static idefloppy_pc_t *idefloppy_next_pc_storage(ide_drive_t *drive)
{
idefloppy_t *floppy = drive->driver_data;
@@ -233,7 +229,7 @@ static idefloppy_pc_t *idefloppy_next_pc_storage
(ide_drive_t *drive)
return (>pc_stack[floppy->pc_stack_index++]);
}
-static struct request *idefloppy_next_rq_storage (ide_drive_t *drive)
+static struct request *idefloppy_next_rq_storage(ide_drive_t *drive)
{
idefloppy_t *floppy = drive->driver_data;
@@ -242,11 +238,8 @@ static struct request *idefloppy_next_rq_storage
(ide_drive_t *drive)
return (>rq_stack[floppy->rq_stack_index++]);
}
-/*
- * idefloppy_analyze_error is called on each failed packet command retry
- * to analyze the request sense.
- */
-static void idefloppy_analyze_error (ide_drive_t *drive,
+/* Called on each failed packet command retry to analyze the request sense. */
+static void idefloppy_analyze_error(ide_drive_t *drive,
rq_sense_res_t *result)
{
idefloppy_t *floppy = drive->driver_data;
@@ -265,7 +258,7 @@ static void idefloppy_analyze_error (ide_drive_t *drive,
[RESEND PATCH 09/10] ide-floppy: use test_bit wrappers for testing flags
also, fix header comments and remove superfluous ones. There should be no
functionality change resulting from this patch.
Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]>
---
drivers/ide/ide-floppy.c | 45 -
drivers/ide/ide-floppy.h | 127 +-
2 files changed, 79 insertions(+), 93 deletions(-)
diff --git a/drivers/ide/ide-floppy.c b/drivers/ide/ide-floppy.c
index fd5fe7b..6c29b5f 100644
--- a/drivers/ide/ide-floppy.c
+++ b/drivers/ide/ide-floppy.c
@@ -337,7 +337,7 @@ static ide_startstop_t idefloppy_pc_intr(ide_drive_t *drive)
debug_log("Reached %s interrupt handler\n", __FUNCTION__);
- if (test_bit(PC_DMA_IN_PROGRESS, >flags)) {
+ if (idefl_dma_ongoing(pc)) {
dma_error = HWIF(drive)->ide_dma_end(drive);
if (dma_error) {
@@ -365,7 +365,7 @@ static ide_startstop_t idefloppy_pc_intr(ide_drive_t *drive)
local_irq_enable_in_hardirq();
- if (status.b.check || test_bit(PC_DMA_ERROR, >flags)) {
+ if (status.b.check || idefl_dma_err(pc)) {
/* Error detected */
debug_log("%s: I/O error\n", drive->name);
rq->errors++;
@@ -404,7 +404,7 @@ static ide_startstop_t idefloppy_pc_intr(ide_drive_t *drive)
printk(KERN_ERR "ide-floppy: CoD != 0 in idefloppy_pc_intr\n");
return ide_do_reset(drive);
}
- if (ireason.b.io == test_bit(PC_WRITING, >flags)) {
+ if (ireason.b.io == idefl_data_dir(pc)) {
/* Hopefully, we will never get here */
printk(KERN_ERR "ide-floppy: We wanted to %s, ",
ireason.b.io ? "Write":"Read");
@@ -412,7 +412,7 @@ static ide_startstop_t idefloppy_pc_intr(ide_drive_t *drive)
ireason.b.io ? "Read":"Write");
return ide_do_reset(drive);
}
- if (!test_bit(PC_WRITING, >flags)) {
+ if (!idefl_data_dir(pc)) {
/* Reading - Check that we have enough space */
temp = pc->actually_transferred + bcount.all;
if (temp > pc->request_transfer) {
@@ -432,7 +432,7 @@ static ide_startstop_t idefloppy_pc_intr(ide_drive_t *drive)
"expected - allowing transfer\n");
}
}
- if (test_bit(PC_WRITING, >flags)) {
+ if (idefl_data_dir(pc)) {
if (pc->buffer != NULL)
/* Write the current buffer */
HWIF(drive)->atapi_output_bytes(drive,
@@ -579,14 +579,13 @@ static ide_startstop_t idefloppy_issue_pc(ide_drive_t
*drive, idefloppy_pc_t *pc
/* Set the current packet command */
floppy->pc = pc;
- if (pc->retries > IDEFLOPPY_MAX_PC_RETRIES ||
- test_bit(PC_ABORT, >flags)) {
+ if (pc->retries > IDEFLOPPY_MAX_PC_RETRIES || idefl_abort(pc)) {
/*
-* We will "abort" retrying a packet command in case
-* a legitimate error code was received.
+* We will "abort" retrying a packet command in case a
+* legitimate error code was received.
*/
- if (!test_bit(PC_ABORT, >flags)) {
- if (!test_bit(PC_SUPPRESS_ERROR, >flags)) {
+ if (!idefl_abort(pc)) {
+ if (!idefl_supp_err(pc)) {
if (idefloppy_report_error(floppy))
printk(KERN_ERR "ide-floppy: %s: I/O
error, "
"pc = %2x, key = %2x, "
@@ -616,7 +615,7 @@ static ide_startstop_t idefloppy_issue_pc(ide_drive_t
*drive, idefloppy_pc_t *pc
feature.all = 0;
- if (test_bit(PC_DMA_RECOMMENDED, >flags) && drive->using_dma)
+ if (idefl_dma_prefd(pc) && drive->using_dma)
feature.b.dma = !hwif->dma_setup(drive);
if (IDE_CONTROL_REG)
@@ -633,7 +632,7 @@ static ide_startstop_t idefloppy_issue_pc(ide_drive_t
*drive, idefloppy_pc_t *pc
}
/* Can we transfer the packet when we get the interrupt or wait? */
- if (test_bit(IDEFLOPPY_ZIP_DRIVE, >flags)) {
+ if (idefl_zip_drive(floppy)) {
/* wait */
pkt_xfer_routine = _transfer_pc1;
} else {
@@ -641,7 +640,7 @@ static ide_startstop_t idefloppy_issue_pc(ide_drive_t
*drive, idefloppy_pc_t *pc
pkt_xfer_routine = _transfer_pc;
}
- if (test_bit(IDEFLOPPY_DRQ_INTERRUPT, >flags)) {
+ if (idefl_drq_intr(floppy)) {
/* Issue the packet command */
ide_execute_command(drive, WIN_PACKETCMD,
pkt_xfer_routine,
@@ -749,11 +748,10 @@ static void idefloppy_create_rw_cmd(idefloppy_t *floppy,
idefloppy_pc_t *pc,
int cmd = rq_data_dir(rq);
[RESEND PATCH 04/10] ide-floppy: cleanup debugging macros
There should be no functional change resulting from this patch.
Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]>
---
drivers/ide/ide-floppy.c | 58 +
drivers/ide/ide-floppy.h |3 +-
2 files changed, 29 insertions(+), 32 deletions(-)
diff --git a/drivers/ide/ide-floppy.c b/drivers/ide/ide-floppy.c
index 4fb6128..196a697 100644
--- a/drivers/ide/ide-floppy.c
+++ b/drivers/ide/ide-floppy.c
@@ -105,7 +105,7 @@ static int idefloppy_do_end_request(ide_drive_t *drive, int
uptodate, int nsecs)
struct request *rq = HWGROUP(drive)->rq;
int error;
- debug_log(KERN_INFO "Reached idefloppy_end_request\n");
+ debug_log("Reached %s\n", __FUNCTION__);
switch (uptodate) {
case 0: error = IDEFLOPPY_ERROR_GENERAL; break;
@@ -257,13 +257,12 @@ static void idefloppy_analyze_error (ide_drive_t *drive,
floppy->progress_indication = result->sksv[0] & 0x80 ?
(u16)get_unaligned((u16 *)(result->sksv+1)):0x1;
if (floppy->failed_pc)
- debug_log(KERN_INFO "ide-floppy: pc = %x, sense key = %x, "
- "asc = %x, ascq = %x\n", floppy->failed_pc->c[0],
- result->sense_key, result->asc, result->ascq);
+ debug_log("pc = %x, sense key = %x, asc = %x, ascq = %x\n",
+ floppy->failed_pc->c[0], result->sense_key,
+ result->asc, result->ascq);
else
- debug_log(KERN_INFO "ide-floppy: sense key = %x, asc = %x, "
- "ascq = %x\n", result->sense_key,
- result->asc, result->ascq);
+ debug_log("sense key = %x, asc = %x, ascq = %x\n",
+ result->sense_key, result->asc, result->ascq);
}
static void idefloppy_request_sense_callback (ide_drive_t *drive)
@@ -271,7 +270,7 @@ static void idefloppy_request_sense_callback (ide_drive_t
*drive)
idefloppy_t *floppy = drive->driver_data;
u8 *buf = floppy->pc->buffer;
- debug_log(KERN_INFO "ide-floppy: Reached %s\n", __FUNCTION__);
+ debug_log("Reached %s\n", __FUNCTION__);
if (!floppy->pc->error) {
idefloppy_analyze_error(drive, (rq_sense_res_t *) buf);
@@ -291,7 +290,7 @@ static void idefloppy_pc_callback (ide_drive_t *drive)
{
idefloppy_t *floppy = drive->driver_data;
- debug_log(KERN_INFO "ide-floppy: Reached %s\n", __FUNCTION__);
+ debug_log("Reached %s\n", __FUNCTION__);
idefloppy_do_end_request(drive, floppy->pc->error ? 0 : 1, 0);
}
@@ -351,8 +350,7 @@ static ide_startstop_t idefloppy_pc_intr (ide_drive_t
*drive)
struct request *rq = pc->rq;
unsigned int temp;
- debug_log(KERN_INFO "ide-floppy: Reached %s interrupt handler\n",
- __FUNCTION__);
+ debug_log("Reached %s interrupt handler\n", __FUNCTION__);
if (test_bit(PC_DMA_IN_PROGRESS, >flags)) {
if (HWIF(drive)->ide_dma_end(drive)) {
@@ -361,23 +359,23 @@ static ide_startstop_t idefloppy_pc_intr (ide_drive_t
*drive)
pc->actually_transferred = pc->request_transfer;
idefloppy_update_buffers(drive, pc);
}
- debug_log(KERN_INFO "ide-floppy: DMA finished\n");
+ debug_log("%s: DMA finished\n", __FUNCTION__);
}
/* Clear the interrupt */
status.all = HWIF(drive)->INB(IDE_STATUS_REG);
if (!status.b.drq) {/* No more interrupts */
- debug_log(KERN_INFO "Packet command completed, %d bytes "
- "transferred\n", pc->actually_transferred);
+ debug_log("Packet command completed, %d bytes transferred\n",
+ pc->actually_transferred);
+
clear_bit(PC_DMA_IN_PROGRESS, >flags);
local_irq_enable_in_hardirq();
if (status.b.check || test_bit(PC_DMA_ERROR, >flags)) {
/* Error detected */
- debug_log(KERN_INFO "ide-floppy: %s: I/O error\n",
- drive->name);
+ debug_log("%s: I/O error\n", drive->name);
rq->errors++;
if (pc->c[0] == GPCMD_REQUEST_SENSE) {
printk(KERN_ERR "ide-floppy: I/O error in "
@@ -438,9 +436,8 @@ static ide_startstop_t idefloppy_pc_intr (ide_drive_t
*drive)
NULL);
return ide_started;
}
- debug_log(KERN_NOTICE "ide-floppy: The floppy wants to "
- "send us more data than expected - "
- "allowing transfer\n");
+ debug_log("The floppy wants to send us more data than"
+
[RESEND PATCH 07/10] ide-floppy: remove unnecessary ->handler != NULL check
This BUG_ON is unneeded since the ->handler != NULL check is performed in ide_set_handler(). Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]> --- drivers/ide/ide-floppy.c |8 +++- 1 files changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/ide/ide-floppy.c b/drivers/ide/ide-floppy.c index 5d0fd1f..2c139e7 100644 --- a/drivers/ide/ide-floppy.c +++ b/drivers/ide/ide-floppy.c @@ -421,7 +421,7 @@ static ide_startstop_t idefloppy_pc_intr(ide_drive_t *drive) "to send us more data than expected " "- discarding data\n"); idefloppy_discard_data(drive,bcount.all); - BUG_ON(HWGROUP(drive)->handler != NULL); + ide_set_handler(drive, _pc_intr, IDEFLOPPY_WAIT_CMD, @@ -453,8 +453,6 @@ static ide_startstop_t idefloppy_pc_intr(ide_drive_t *drive) pc->actually_transferred += bcount.all; pc->current_position += bcount.all; - BUG_ON(HWGROUP(drive)->handler != NULL); - /* And set the interrupt handler again */ ide_set_handler(drive, _pc_intr, IDEFLOPPY_WAIT_CMD, NULL); return ide_started; @@ -482,7 +480,7 @@ static ide_startstop_t idefloppy_transfer_pc(ide_drive_t *drive) "issuing a packet command\n"); return ide_do_reset(drive); } - BUG_ON(HWGROUP(drive)->handler != NULL); + /* Set the interrupt routine */ ide_set_handler(drive, _pc_intr, IDEFLOPPY_WAIT_CMD, NULL); /* Send the actual packet */ @@ -537,7 +535,7 @@ static ide_startstop_t idefloppy_transfer_pc1(ide_drive_t *drive) * 40 and 50msec work well. idefloppy_pc_intr will not be actually * used until after the packet is moved in about 50 msec. */ - BUG_ON(HWGROUP(drive)->handler != NULL); + ide_set_handler(drive, _pc_intr, /* service routine for packet command */ floppy->ticks,/* wait this long before "failing" */ -- 1.5.3.7 -- 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/
[RESEND PATCH 02/10] ide-floppy: move ide-floppy struct and macro defs into its own header. While at it
- do a white-space cleanup
- remove old crufty code untouched since at least 2005
- shorten lines longer than 80ish columns
- shorten some LAAARGE typenames.
There should be no functional changes resulting from this patch.
Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]>
---
drivers/ide/ide-floppy.c | 763 --
drivers/ide/ide-floppy.h | 382 +++
2 files changed, 581 insertions(+), 564 deletions(-)
diff --git a/drivers/ide/ide-floppy.c b/drivers/ide/ide-floppy.c
index 785fbde..52d09c1 100644
--- a/drivers/ide/ide-floppy.c
+++ b/drivers/ide/ide-floppy.c
@@ -44,418 +44,7 @@
#include
#include
-/*
- * The following are used to debug the driver.
- */
-#define IDEFLOPPY_DEBUG_LOG0
-#define IDEFLOPPY_DEBUG_INFO 0
-#define IDEFLOPPY_DEBUG_BUGS 1
-
-/* #define IDEFLOPPY_DEBUG(fmt, args...) printk(KERN_INFO fmt, ## args) */
-#define IDEFLOPPY_DEBUG( fmt, args... )
-
-#if IDEFLOPPY_DEBUG_LOG
-#define debug_log printk
-#else
-#define debug_log(fmt, args... ) do {} while(0)
-#endif
-
-
-/*
- * Some drives require a longer irq timeout.
- */
-#define IDEFLOPPY_WAIT_CMD (5 * WAIT_CMD)
-
-/*
- * After each failed packet command we issue a request sense command
- * and retry the packet command IDEFLOPPY_MAX_PC_RETRIES times.
- */
-#define IDEFLOPPY_MAX_PC_RETRIES 3
-
-/*
- * With each packet command, we allocate a buffer of
- * IDEFLOPPY_PC_BUFFER_SIZE bytes.
- */
-#define IDEFLOPPY_PC_BUFFER_SIZE 256
-
-/*
- * In various places in the driver, we need to allocate storage
- * for packet commands and requests, which will remain valid while
- * we leave the driver to wait for an interrupt or a timeout event.
- */
-#define IDEFLOPPY_PC_STACK (10 + IDEFLOPPY_MAX_PC_RETRIES)
-
-/*
- * Our view of a packet command.
- */
-typedef struct idefloppy_packet_command_s {
- u8 c[12]; /* Actual packet bytes */
- int retries;/* On each retry, we increment
retries */
- int error; /* Error code */
- int request_transfer; /* Bytes to transfer */
- int actually_transferred; /* Bytes actually transferred */
- int buffer_size;/* Size of our data buffer */
- int b_count;/* Missing/Available data on
the current buffer */
- struct request *rq; /* The corresponding request */
- u8 *buffer; /* Data buffer */
- u8 *current_position; /* Pointer into the above
buffer */
- void (*callback) (ide_drive_t *); /* Called when this packet
command is completed */
- u8 pc_buffer[IDEFLOPPY_PC_BUFFER_SIZE]; /* Temporary buffer */
- unsigned long flags;/* Status/Action bit flags:
long for set_bit */
-} idefloppy_pc_t;
-
-/*
- * Packet command flag bits.
- */
-#definePC_ABORT0 /* Set when an error is
considered normal - We won't retry */
-#define PC_DMA_RECOMMENDED 2 /* 1 when we prefer to use DMA
if possible */
-#definePC_DMA_IN_PROGRESS 3 /* 1 while DMA in
progress */
-#definePC_DMA_ERROR4 /* 1 when encountered
problem during DMA */
-#definePC_WRITING 5 /* Data direction */
-
-#definePC_SUPPRESS_ERROR 6 /* Suppress error
reporting */
-
-/*
- * Removable Block Access Capabilities Page
- */
-typedef struct {
-#if defined(__LITTLE_ENDIAN_BITFIELD)
- unsignedpage_code :6; /* Page code - Should be 0x1b */
- unsignedreserved1_6 :1; /* Reserved */
- unsignedps :1; /* Should be 0 */
-#elif defined(__BIG_ENDIAN_BITFIELD)
- unsignedps :1; /* Should be 0 */
- unsignedreserved1_6 :1; /* Reserved */
- unsignedpage_code :6; /* Page code - Should be 0x1b */
-#else
-#error "Bitfield endianness not defined! Check your byteorder.h"
-#endif
- u8 page_length;/* Page Length - Should be 0xa
*/
-#if defined(__LITTLE_ENDIAN_BITFIELD)
- unsignedreserved2 :6;
- unsignedsrfp:1; /* Supports reporting progress
of format */
- unsignedsflp:1; /* System floppy type device */
- unsignedtlun:3; /* Total logical units
supported by the device */
- unsignedreserved3 :3;
- unsignedsml :1; /* Single / Multiple lun
supported */
- unsignedncd :1; /* Non cd optical device */
-#elif defined(__BIG_ENDIAN_BITFIELD)
-
[RESEND PATCH 08/10] ide-floppy: mv idefloppy_{should_,}report_error
Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]>
---
drivers/ide/ide-floppy.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/ide/ide-floppy.c b/drivers/ide/ide-floppy.c
index 2c139e7..fd5fe7b 100644
--- a/drivers/ide/ide-floppy.c
+++ b/drivers/ide/ide-floppy.c
@@ -544,7 +544,7 @@ static ide_startstop_t idefloppy_transfer_pc1(ide_drive_t
*drive)
}
/* Supresses error messages resulting from Medium not present */
-static inline int idefloppy_should_report_error(idefloppy_t *floppy)
+static inline int idefloppy_report_error(idefloppy_t *floppy)
{
if (floppy->sense_key == 0x02 &&
floppy->asc == 0x3a &&
@@ -587,7 +587,7 @@ static ide_startstop_t idefloppy_issue_pc(ide_drive_t
*drive, idefloppy_pc_t *pc
*/
if (!test_bit(PC_ABORT, >flags)) {
if (!test_bit(PC_SUPPRESS_ERROR, >flags)) {
- if (idefloppy_should_report_error(floppy))
+ if (idefloppy_report_error(floppy))
printk(KERN_ERR "ide-floppy: %s: I/O
error, "
"pc = %2x, key = %2x, "
"asc = %2x, ascq = %2x\n",
@@ -809,7 +809,7 @@ static ide_startstop_t idefloppy_do_request(ide_drive_t
*drive,
if (rq->errors >= ERROR_MAX) {
if (floppy->failed_pc != NULL) {
- if (idefloppy_should_report_error(floppy))
+ if (idefloppy_report_error(floppy))
printk(KERN_ERR "ide-floppy: %s: I/O error,"
" pc = %2x, key = %2x, asc = %2x,"
" ascq = %2x\n",
--
1.5.3.7
--
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/
[RESEND PATCH 01/10] move ide-floppy historical changelog to Documentation/ide/ChangeLog.ide-floppy.1996-2002;
Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]> --- Documentation/ide/ChangeLog.ide-floppy.1996-2002 | 64 drivers/ide/ide-floppy.c | 69 +- 2 files changed, 67 insertions(+), 66 deletions(-) diff --git a/Documentation/ide/ChangeLog.ide-floppy.1996-2002 b/Documentation/ide/ChangeLog.ide-floppy.1996-2002 new file mode 100644 index 000..70166f3 --- /dev/null +++ b/Documentation/ide/ChangeLog.ide-floppy.1996-2002 @@ -0,0 +1,64 @@ +/* + * Many thanks to Lode Leroy <[EMAIL PROTECTED]>, who tested so many + * ALPHA patches to this driver on an EASYSTOR LS-120 ATAPI floppy drive. + * + * Ver 0.1 Oct 17 96 Initial test version, mostly based on ide-tape.c. + * Ver 0.2 Oct 31 96 Minor changes. + * Ver 0.3 Dec 2 96 Fixed error recovery bug. + * Ver 0.4 Jan 26 97 Add support for the HDIO_GETGEO ioctl. + * Ver 0.5 Feb 21 97 Add partitions support. + * Use the minimum of the LBA and CHS capacities. + * Avoid hwgroup->rq == NULL on the last irq. + * Fix potential null dereferencing with DEBUG_LOG. + * Ver 0.8 Dec 7 97 Increase irq timeout from 10 to 50 seconds. + * Add media write-protect detection. + * Issue START command only if TEST UNIT READY fails. + * Add work-around for IOMEGA ZIP revision 21.D. + * Remove idefloppy_get_capabilities(). + * Ver 0.9 Jul 4 99 Fix a bug which might have caused the number of + *bytes requested on each interrupt to be zero. + *Thanks to <[EMAIL PROTECTED]> for pointing this out. + * Ver 0.9.sv Jan 6 01 Sam Varshavchik <[EMAIL PROTECTED]> + * Implement low level formatting. Reimplemented + * IDEFLOPPY_CAPABILITIES_PAGE, since we need the srfp + * bit. My LS-120 drive barfs on + * IDEFLOPPY_CAPABILITIES_PAGE, but maybe it's just me. + * Compromise by not reporting a failure to get this + * mode page. Implemented four IOCTLs in order to + * implement formatting. IOCTls begin with 0x4600, + * 0x46 is 'F' as in Format. + *Jan 9 01 Userland option to select format verify. + * Added PC_SUPPRESS_ERROR flag - some idefloppy drives + * do not implement IDEFLOPPY_CAPABILITIES_PAGE, and + * return a sense error. Suppress error reporting in + * this particular case in order to avoid spurious + * errors in syslog. The culprit is + * idefloppy_get_capability_page(), so move it to + * idefloppy_begin_format() so that it's not used + * unless absolutely necessary. + * If drive does not support format progress indication + * monitor the dsc bit in the status register. + * Also, O_NDELAY on open will allow the device to be + * opened without a disk available. This can be used to + * open an unformatted disk, or get the device capacity. + * Ver 0.91 Dec 11 99 Added IOMEGA Clik! drive support by + *<[EMAIL PROTECTED]> + * Ver 0.92 Oct 22 00 Paul Bristow became official maintainer for this + *driver. Included Powerbook internal zip kludge. + * Ver 0.93 Oct 24 00 Fixed bugs for Clik! drive + *no disk on insert and disk change now works + * Ver 0.94 Oct 27 00 Tidied up to remove strstr(Clik) everywhere + * Ver 0.95 Nov 7 00 Brought across to kernel 2.4 + * Ver 0.96 Jan 7 01 Actually in line with release version of 2.4.0 + * including set_bit patch from Rusty Russell + * Ver 0.97 Jul 22 01 Merge 0.91-0.96 onto 0.9.sv for ac series + * Ver 0.97.sv Aug 3 01 Backported from 2.4.7-ac3 + * Ver 0.98 Oct 26 01 Split idefloppy_transfer_pc into two pieces to + *fix a lost interrupt problem. It appears the busy + *bit was being deasserted by my IOMEGA ATAPI ZIP 100 + *drive before the drive was actually ready. + * Ver 0.98a Oct 29 01 Expose delay value so we can play. + * Ver 0.99 Feb 24 02 Remove duplicate code, modify clik! detection code + *to support new PocketZip drives + */ + diff --git a/drivers/ide/ide-floppy.c b/drivers/ide/ide-floppy.c index 04a3578..785fbde 100644 --- a/drivers/ide/ide-floppy.c +++ b/drivers/ide/ide-floppy.c @@ -1,12 +1,8 @@ /* - * linux/drivers/ide/ide-floppy.c Version 0.99Feb 24 2002 + * IDE ATAPI floppy driver. * * Copyright (C) 1996 - 1999 Gadi Oxman <[EMAIL PROTECTED]>
[RESEND PATCH 05/10] ide-floppy: factor out ioctl handlers from idefloppy_ioctl()
There should be no functional change resulting from this patch.
Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]>
---
drivers/ide/ide-floppy.c | 90 +-
1 files changed, 57 insertions(+), 33 deletions(-)
diff --git a/drivers/ide/ide-floppy.c b/drivers/ide/ide-floppy.c
index 196a697..7823447 100644
--- a/drivers/ide/ide-floppy.c
+++ b/drivers/ide/ide-floppy.c
@@ -1600,6 +1600,58 @@ static int idefloppy_getgeo(struct block_device *bdev,
struct hd_geometry *geo)
return 0;
}
+static int idefloppy_lockdoor(struct inode *inode, idefloppy_pc_t *pc,
+ int event, unsigned int cmd)
+{
+ struct block_device *bdev = inode->i_bdev;
+ struct ide_floppy_obj *floppy = ide_floppy_g(bdev->bd_disk);
+ ide_drive_t *drive = floppy->drive;
+
+ if (floppy->openers > 1)
+ return -EBUSY;
+
+ /* The IOMEGA Clik! Drive doesn't support this command -
+* no room for an eject mechanism */
+ if (!test_bit(IDEFLOPPY_CLIK_DRIVE, >flags)) {
+ idefloppy_create_prevent_cmd(pc, event);
+ (void) idefloppy_queue_pc_tail(drive, pc);
+ }
+
+ if (cmd == CDROMEJECT) {
+ idefloppy_create_start_stop_cmd(pc, 2);
+ (void) idefloppy_queue_pc_tail(drive, pc);
+ }
+
+ return 0;
+}
+
+static
+int idefloppy_format_start(struct file *file, struct inode *inode,
+ void __user *argp)
+{
+ struct block_device *bdev = inode->i_bdev;
+ struct ide_floppy_obj *floppy = ide_floppy_g(bdev->bd_disk);
+ ide_drive_t *drive = floppy->drive;
+ int err;
+
+ if (!(file->f_mode & 2))
+ return -EPERM;
+
+ if (floppy->openers > 1) {
+ /* Don't format if someone is using the disk */
+ clear_bit(IDEFLOPPY_FORMAT_IN_PROGRESS, >flags);
+ return -EBUSY;
+ }
+
+ set_bit(IDEFLOPPY_FORMAT_IN_PROGRESS, >flags);
+
+ err = idefloppy_begin_format(drive, argp);
+ if (err)
+ clear_bit(IDEFLOPPY_FORMAT_IN_PROGRESS, >flags);
+
+ return err;
+}
+
static int idefloppy_ioctl(struct inode *inode, struct file *file,
unsigned int cmd, unsigned long arg)
{
@@ -1612,47 +1664,19 @@ static int idefloppy_ioctl(struct inode *inode, struct
file *file,
idefloppy_pc_t pc;
switch (cmd) {
+
case CDROMEJECT:
prevent = 0;
/* fall through */
- case CDROM_LOCKDOOR:
- if (floppy->openers > 1)
- return -EBUSY;
- /* The IOMEGA Clik! Drive doesn't support this command -
-* no room for an eject mechanism */
-if (!test_bit(IDEFLOPPY_CLIK_DRIVE, >flags)) {
- idefloppy_create_prevent_cmd(, prevent);
- (void) idefloppy_queue_pc_tail(drive, );
- }
- if (cmd == CDROMEJECT) {
- idefloppy_create_start_stop_cmd(, 2);
- (void) idefloppy_queue_pc_tail(drive, );
- }
- return 0;
+ case CDROM_LOCKDOOR:
+ return idefloppy_lockdoor(inode, , prevent, cmd);
case IDEFLOPPY_IOCTL_FORMAT_SUPPORTED:
return 0;
case IDEFLOPPY_IOCTL_FORMAT_GET_CAPACITY:
return idefloppy_get_format_capacities(drive, argp);
case IDEFLOPPY_IOCTL_FORMAT_START:
-
- if (!(file->f_mode & 2))
- return -EPERM;
-
- if (floppy->openers > 1) {
-
- /* Don't format if someone is using the disk */
- clear_bit(IDEFLOPPY_FORMAT_IN_PROGRESS,
- >flags);
- return -EBUSY;
- }
-
- set_bit(IDEFLOPPY_FORMAT_IN_PROGRESS, >flags);
-
- err = idefloppy_begin_format(drive, argp);
- if (err)
- clear_bit(IDEFLOPPY_FORMAT_IN_PROGRESS, >flags);
- return err;
+ return idefloppy_format_start(file, inode, argp);
/*
* Note, the bit will be cleared when the device is
* closed. This is the cleanest way to handle the
@@ -1669,7 +1693,7 @@ static int idefloppy_ioctl(struct inode *inode, struct
file *file,
*/
if (cmd != CDROM_SEND_PACKET && cmd != SCSI_IOCTL_SEND_COMMAND)
err = scsi_cmd_ioctl(file, bdev->bd_disk->queue,
- bdev->bd_disk, cmd, argp);
+ bdev->bd_disk, cmd, argp);
else
err = -ENOTTY;
--
1.5.3.7
--
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
[RESEND PATCH 03/10] ide-floppy: convert to generic packet commands
Replace the ide-floppy packet commands opcode defines with the generic ones.
Add a missing GPCMD_WRITE_12 (opcode 0xaa) to the generic ones in cdrom.h. The
last one can be found in the current version of INF-8090, p.905.
CC: Jens Axboe <[EMAIL PROTECTED]>
Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]>
---
drivers/ide/ide-floppy.c | 26 +-
drivers/ide/ide-floppy.h | 21 -
include/linux/cdrom.h|1 +
3 files changed, 14 insertions(+), 34 deletions(-)
diff --git a/drivers/ide/ide-floppy.c b/drivers/ide/ide-floppy.c
index 52d09c1..4fb6128 100644
--- a/drivers/ide/ide-floppy.c
+++ b/drivers/ide/ide-floppy.c
@@ -313,7 +313,7 @@ static void idefloppy_init_pc (idefloppy_pc_t *pc)
static void idefloppy_create_request_sense_cmd (idefloppy_pc_t *pc)
{
idefloppy_init_pc(pc);
- pc->c[0] = IDEFLOPPY_REQUEST_SENSE_CMD;
+ pc->c[0] = GPCMD_REQUEST_SENSE;
pc->c[4] = 255;
pc->request_transfer = 18;
pc->callback = _request_sense_callback;
@@ -379,7 +379,7 @@ static ide_startstop_t idefloppy_pc_intr (ide_drive_t
*drive)
debug_log(KERN_INFO "ide-floppy: %s: I/O error\n",
drive->name);
rq->errors++;
- if (pc->c[0] == IDEFLOPPY_REQUEST_SENSE_CMD) {
+ if (pc->c[0] == GPCMD_REQUEST_SENSE) {
printk(KERN_ERR "ide-floppy: I/O error in "
"request sense command\n");
return ide_do_reset(drive);
@@ -586,8 +586,8 @@ static ide_startstop_t idefloppy_issue_pc (ide_drive_t
*drive, idefloppy_pc_t *p
and have lived on another thread's stack; that stack may have become
unmapped meanwhile (CONFIG_DEBUG_PAGEALLOC). */
#if IDEFLOPPY_DEBUG_BUGS
- if (floppy->pc->c[0] == IDEFLOPPY_REQUEST_SENSE_CMD &&
- pc->c[0] == IDEFLOPPY_REQUEST_SENSE_CMD) {
+ if (floppy->pc->c[0] == GPCMD_REQUEST_SENSE &&
+ pc->c[0] == GPCMD_REQUEST_SENSE) {
printk(KERN_ERR "ide-floppy: possible ide-floppy.c bug - "
"Two request sense in serial were issued\n");
}
@@ -595,7 +595,7 @@ static ide_startstop_t idefloppy_issue_pc (ide_drive_t
*drive, idefloppy_pc_t *p
#endif
if (floppy->failed_pc == NULL &&
- pc->c[0] != IDEFLOPPY_REQUEST_SENSE_CMD)
+ pc->c[0] != GPCMD_REQUEST_SENSE)
floppy->failed_pc = pc;
/* Set the current packet command */
floppy->pc = pc;
@@ -690,14 +690,14 @@ static void idefloppy_create_prevent_cmd (idefloppy_pc_t
*pc, int prevent)
"prevent = %d\n", prevent);
idefloppy_init_pc(pc);
- pc->c[0] = IDEFLOPPY_PREVENT_REMOVAL_CMD;
+ pc->c[0] = GPCMD_PREVENT_ALLOW_MEDIUM_REMOVAL;
pc->c[4] = prevent;
}
static void idefloppy_create_read_capacity_cmd (idefloppy_pc_t *pc)
{
idefloppy_init_pc(pc);
- pc->c[0] = IDEFLOPPY_READ_CAPACITY_CMD;
+ pc->c[0] = GPCMD_READ_FORMAT_CAPACITIES;
pc->c[7] = 255;
pc->c[8] = 255;
pc->request_transfer = 255;
@@ -707,7 +707,7 @@ static void idefloppy_create_format_unit_cmd
(idefloppy_pc_t *pc, int b, int l,
int flags)
{
idefloppy_init_pc(pc);
- pc->c[0] = IDEFLOPPY_FORMAT_UNIT_CMD;
+ pc->c[0] = GPCMD_FORMAT_UNIT;
pc->c[1] = 0x17;
memset(pc->buffer, 0, 12);
@@ -733,7 +733,7 @@ static void idefloppy_create_mode_sense_cmd (idefloppy_pc_t
*pc, u8 page_code,
u16 length = sizeof(idefloppy_mode_par_hdr_t);
idefloppy_init_pc(pc);
- pc->c[0] = IDEFLOPPY_MODE_SENSE_CMD;
+ pc->c[0] = GPCMD_MODE_SENSE_10;
pc->c[1] = 0;
pc->c[2] = page_code + (type << 6);
@@ -755,14 +755,14 @@ static void idefloppy_create_mode_sense_cmd
(idefloppy_pc_t *pc, u8 page_code,
static void idefloppy_create_start_stop_cmd (idefloppy_pc_t *pc, int start)
{
idefloppy_init_pc(pc);
- pc->c[0] = IDEFLOPPY_START_STOP_CMD;
+ pc->c[0] = GPCMD_START_STOP_UNIT;
pc->c[4] = start;
}
static void idefloppy_create_test_unit_ready_cmd(idefloppy_pc_t *pc)
{
idefloppy_init_pc(pc);
- pc->c[0] = IDEFLOPPY_TEST_UNIT_READY_CMD;
+ pc->c[0] = GPCMD_TEST_UNIT_READY;
}
static void idefloppy_create_rw_cmd (idefloppy_t *floppy, idefloppy_pc_t *pc,
@@ -778,10 +778,10 @@ static void idefloppy_create_rw_cmd (idefloppy_t *floppy,
idefloppy_pc_t *pc,
idefloppy_init_pc(pc);
if (test_bit(IDEFLOPPY_USE_READ12, >flags)) {
- pc->c[0] = cmd == READ ? IDEFLOPPY_READ12_CMD :
IDEFLOPPY_WRITE12_CMD;
+ pc->c[0] = cmd == READ ? GPCMD_READ_12 : GPCMD_WRITE_12;
put_unaligned(htonl(blocks), (unsigned int *) >c[6]);
} else {
- pc->c[0] = cmd == READ ?
[RESEND PATCH 0/10] ide-floppy redux p1
Hi Bart, here's the unfinished redux of ide-floppy which i'm REsending now so that we could sinchronize trees. The original send got busted in vger's filters due to syntax error in the Message-ID tag. Documentation/ide/ChangeLog.ide-floppy.1996-2002 | 64 ++ drivers/ide/ide-floppy.c | 1248 +++--- drivers/ide/ide-floppy.h | 351 ++ include/linux/cdrom.h|1 + 4 files changed, 819 insertions(+), 845 deletions(-) -- 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: [Bluez-devel] Oops involving RFCOMM and sysfs
On Wed, Jan 02, 2008 at 04:16:42PM +0100, Gabor Gombas wrote: > So the patch referenced above does not help. But I've found a very easy > way to trigger the bug: > > - do a "cat /dev/zero > /dev/rfcomm0" > - switch the phone off > - switch the phone on, and the kernel oopses FYI I also remember having oopses with 2.6.22. but I do not have those logs anymore. Also I now booted 2.6.20.7 and it did not oops. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- 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/3] CONFIG_HIGHPTE vs. sub-page page tables.
> Can we please just nuke CONFIG_HIGHPTE? There's only been a small > amount of 32bit machines It's unfortunately a larger amount :/ And for unknown reasons a lot of people still install 32bit kernels on new perfectly capable 64bit systems even if they have a lot of memory. I don't think removing CONFIG_HIGHPTE will be an option any time soon. -Andi -- 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: Make checkpatch.pl's quiet option not print the summary on no errors
On Thu, Jan 03, 2008 at 01:54:42AM +0100, Arjan van de Ven wrote: > Subject: Make checkpatch.pl's quiet option not print the summary on no > errors > From: Arjan van de Ven <[EMAIL PROTECTED]> > CC: [EMAIL PROTECTED] > > Right now, in quiet mode, checkpatch.pl still prints a summary line even > if the patch is 100% clean. IMO, "quiet mode" should mean "no output if > clean", > the patch below makes that so. (This also makes the quilt integration > on my system work nicer :) > > Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]> I think that sounds reasonable. Should people want the summary regardless it makes more sense to provice an option for that, perhaps a doubling of the --summary flag. Will be in 0.13. -apw -- 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: git-x86 broken on 32bit
On Thursday 03 January 2008 09:10:25 Ingo Molnar wrote: > > * Ingo Molnar <[EMAIL PROTECTED]> wrote: > > > * Andi Kleen <[EMAIL PROTECTED]> wrote: > > > > > Current git-x86 seems to be totally broken on i386 > > > > > > commit a6f08929f0566f9d309ef5f6651371d8e20fc833 > > > Author: Russell Leidich <[EMAIL PROTECTED]> > > > Date: Wed Jan 2 22:46:22 2008 +0100 > > > > that patch was not included in x86.git anymore at the time you wrote > > your email. You probably picked up an interim version of the queue > > that had the breakage - i noticed it and pulled it a few minutes > > later. > > correction: i had fixed it but did not push it out - pushed it out now. > Please check that it works for you. I'll check once git.kernel.org unbreaks itself % git pull -u fatal: The remote end hung up unexpectedly Cannot get the repository state from git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git -Andi -- 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] [1/20] x86: Make ptrace.h safe to include from assembler code
On Thursday 03 January 2008 10:54:52 Ingo Molnar wrote: > > * Andi Kleen <[EMAIL PROTECTED]> wrote: > > > Index: linux/include/asm-x86/ptrace-abi.h > > === > > --- linux.orig/include/asm-x86/ptrace-abi.h > > +++ linux/include/asm-x86/ptrace-abi.h > > @@ -80,6 +80,7 @@ > > > > #define PTRACE_SINGLEBLOCK 33 /* resume execution until next branch */ > > > > +#ifndef __ASSEMBLY__ > > hm, this patch misses a rationale - what assembly code includes > ptrace-abi.h directly or indirectly? Did you see any build breakage with > x86.git that requires this? (if yes then please send me the .config) It's needed for the dwarf2 unwinder, but imho useful on its own. -Andi -- 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] [19/20] x86: Use shorter addresses in i386 segfault printks
On Thursday 03 January 2008 11:56:14 Ingo Molnar wrote: > > * Andi Kleen <[EMAIL PROTECTED]> wrote: > > > x86: Use shorter addresses in i386 segfault printks > > hm, why? It's pretty well-established that we print addresses 8 char > wide on 32-bit. It's useless. What purpose does it have? -Andi -- 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] [20/20] x86: Print which shared library/executable faulted in segfault etc. messages
> > And printing the offset into a mapping also always allows to find the
> > correct fault point in a library even with randomized mappings. Previously
> > there was no way to actually find the correct code address inside
> > the randomized mapping.
> >
> > Relies on earlier patch to shorten the printk formats.
> >
> > They are often now longer than 80 characters, but I think that's worth
> > it.
>
> why not make it multi-line? that way the %lx hack wouldnt be needed
> either.
I prefer it single-line. I also disagree on %lx being a hack.
>
> > +void print_vma_addr(char *prefix, unsigned long ip)
> > +{
> > + struct mm_struct *mm = current->mm;
> > + struct vm_area_struct *vma;
> > + down_read(>mmap_sem);
> > + vma = find_vma(mm, ip);
>
> grumble. Proper CodingStyle please.
Looks fine to me. If you mean the new line after variables -- that was always
optional.
Anyways I'll repost with the error check.
Also it seems like you did apply only parts of the patchkit. If you do that can
you send a list of what patches you didn't add, otherwise it'll be messy to
figure
this out from here.
-Andi
--
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] [12/20] x86: Use a per cpu timer for correctable machine check checking
On Thursday 03 January 2008 11:49:56 Ingo Molnar wrote: > > * Andi Kleen <[EMAIL PROTECTED]> wrote: > > > Previously the code used a single timer that then used > > smp_call_function to interrupt all CPUs while the original CPU was > > waiting for them. > > > > But it is better / more real time and more power friendly to simply > > run individual timers on each CPU so they all do this independently. > > > > This way no single CPU has to wait for all others. > > i think we should unify this code first and provide it on 32-bit as > well. That's done in another patch that hasn't been posted yet. -Andi -- 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] [11/20] x86: Use the correct cpuid method to detect MWAIT support for C states
On Thursday 03 January 2008 11:45:26 Ingo Molnar wrote:
>
> * Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > +static int mwait_usable(const struct cpuinfo_x86 *c)
> > +{
> > + if (force_mwait)
> > + return 1;
> > + /* Any C1 states supported? */
> > + return c->cpuid_level >= 5 && ((cpuid_edx(5) >> 4) & 0xf) > 0;
> > +}
> > +
> > void __cpuinit select_idle_routine(const struct cpuinfo_x86 *c)
> > {
> > - if (cpu_has(c, X86_FEATURE_MWAIT)) {
> > + if (cpu_has(c, X86_FEATURE_MWAIT) && mwait_usable(c)) {
> > printk("monitor/mwait feature present.\n");
>
> hm, why not clear FEATURE_MWAIT if it's "not usable"? That's the
> standard approach we do for CPU features that do not work.
Well it works, just in a unexpected way not useful to the kernel.
At least on AMD there is a bit to enable it for ring 3 too, so
in theory someone could use it anyways.
-Andi
--
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/20] x86: Introduce nsec_barrier()
On Thursday 03 January 2008 11:47:54 Ingo Molnar wrote: > > * Andi Kleen <[EMAIL PROTECTED]> wrote: > > > nsec_barrier() is a new barrier primitive that stops RDTSC speculation > > to avoid races with timer interrupts on other CPUs. > > > > Add it to all architectures. Except for x86 it is a nop right now. I > > only tested x86, but it's a very simple change. > > > > On x86 it expands either to LFENCE (for Intel CPUs) or MFENCE (for AMD > > CPUs) which stops RDTSC on all currently known microarchitectures that > > implement SSE. On CPUs without SSE there is generally no RDTSC > > speculation. > > i've picked up your rdtsc patches into x86.git but have simplified it: > there's no nsec_barrier() anymore - rdtsc() is always synchronous. > MFENCE/LFENCE is fast enough. Open-coding such barriers almost always > leads to needless trouble. Please check the next x86.git tree. That's most likely wrong unless you added two barriers -- the barriers are strictly need to be before and after RDTSC. I still think having the open barrier is the better approach here. It's also useful for performance measurements because it allows a cheap way to measure a specific region with RDTSC -Andi -- 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] [9/20] x86: Don't use oops_begin in 64bit mce code
On Thursday 03 January 2008 11:39:12 Ingo Molnar wrote: > > * Andi Kleen <[EMAIL PROTECTED]> wrote: > > > It is not really useful to lock machine checks against oopses. And > > machine checks normally don't nest, so they don't need their own > > locking. Just call bust_spinlock/console_verbose directly. > > is this in response to any particular incident you've seen? No, that was a preparatory patch for the "use 64bit machine check code for 32bit kernels" because 32bit doesn't have oops_begin(), but it is useful on its own. -Andi -- 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: [uml-devel] UML woes in 2.6.24-rc6-mm1
> > 32bit UML, 64bit host, config attached. > > Hadn't tried that, but that works here too. > > I'll see if your config reproduces it. > > > Can't reproduce with plain -rc6. > > Feel like bisecting -mm1? This is the one: uml-runtime-detection-of-host-vmsplit-on-i386.patch The relevant log line (both for successful and failed boots): Locating the top of the address space ... 0xffc0 Miklos -- 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: serial console _after_ boot ? - was: Redirect kernel console
hi ! i was wondering how to make kernel messages appear on /dev/ttyS0 without a reboot, i.e. kernelparam "console=ttyS0" after playing for a while with setconsole, setterm and klogconsole i didn`t find a way to make that happen. i can do "setconsole /dev/tty1 /dev/console" and see "test" on tty1 "setterm -msg on -msglevel 8 >/dev/console" (or >/dev/tty1), modprobe loop;rmmod loop - and i see the kernel message there i can do "setconsole /dev/ttyS0 /dev/console" and see "test" on ttyS0 BUT : "setterm -msg on -msglevel 8 >/dev/console" (or >/dev/ttyS0), modprobe loop;rmmod loop .. nothing! since i came across jan`s posting from 2005, which didn`t get a reply i think it`s not that stupid to ask again... any clue how to do that at runtime or what`s the issue here ? (see excerpts below) i can set regards roland List: linux-kernel Subject:Redirect kernel console From: Jan Engelhardt Date: 2005-08-13 12:48:22 Message-ID: Pine.LNX.4.61.0508131447220.4457 () yvahk01 ! tjqt ! qr [Download message RAW] Hi, there is a klogconsole utiltity that allows to change the console to which kernel messages are printed. However, is it possible to redirect to ttyS0 without a reboot? Jan Engelhardt --- >> Subject: Re: serial console _after_ boot ? >> > Setterm outputs the correct escape sequences to stdout. You can >> > configure another tty using 'setterm -msglevel 8 -msg on > /dev/ttyS0'. >> > I tested this on the standard kernel consoles (/dev/tty1-9), and it >> > worked. You obviously need root access to write the escape sequences to >> > the tty's. >> >> oh - yes, this works! but with tty1-9 only. >> not with ttyS0 :( > >.as the docs tell. > > Some options however (marked "virtual consoles only" below) do not > correspond to a terminfo(5) capability. > > -msg [on|off] (virtual consoles only) > Enables or disables the sending of kernel printk() messages to > the console. > > -msglevel 1-8 (virtual consoles only) > Sets the console logging level for kernel printk() messages. > All messages strictly more important than this > will be printed, so a logging level of 0 has the same effect > as -msg on and a logging level of 8 will print > all kernel messages. klogd(8) may be a more convenient > interface to the logging of kernel messages. > > > but i don`t have change_console. > > > searched the net and found that this eventually should be part of > > > sysvinit package. > > > but mine doesn`t provide that tool. > > > > > > found "setconsole" which looks like something similar, but "setconsole > > > /dev/ttyS0 < /dev/console" > > > doesn`t have any effect > > > > What distribution do you use? I have change_console on gentoo, yet I > > cannot find the tool on a debian etch. But that's a vserver, so it's > > probably not a reference. > > i have opensuse 10.3 _ Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! http://smartsurfer.web.de/?mc=100071=0066 -- 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] teach checkpatch.pl about list_for_each
Christer Weinigel wrote: By the way, what is the consensus on lines over 80 characters? checkpatch complains about the following: WARNING: line over 80 characters #762: FILE: drivers/spi/spi_s3c24xx_dma.c:720: + printk(KERN_INFO "S3C24xx SPI DMA driver (c) 2007 Nordnav Technologies AB\n"); I can of course break this into: printk(KERN_INFO "S3C24xx SPI DMA driver (c) 2007 Nordnav " "Technologies AB\n"); but in my opinion that becomes more even unreadable. Would it be possible to add a special case so that checkpatch ignores long strings that go beyond 80 characters? Do you think it is a good idea? At the top of the file add a #define and use that in the code? Some drivers define their version/author etc that way and then just printk(DRIVER_VERSION DRIVER_AUTHOR); tom -- 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] teach checkpatch.pl about list_for_each
Em Thu, Jan 03, 2008 at 12:26:10PM +, Christoph Hellwig escreveu:
> On Thu, Jan 03, 2008 at 11:10:58AM +, Andy Whitcroft wrote:
> > We have had some stabs at changing this, but no consensus was reached on
> > whether it was a "for" or a "function". My memory is of there being
> > slightly more "without a space" tenders than the other and so it has not
> > been changed. This thread also seems so far to have not really
> > generated a concensus. So I would tend to leave things as they are.
> >
> > A third option might be to accept either on *for_each* constructs.
> > That might tend to lead to divergance. Difficult. However, also see my
> > later comments on "style guide".
>
> Pretty much all core code uses list_for_each_entry( so new code should
> follow that example.
Agreed, CodingStyle is not about mindless consistency such as "for (" is
the right thing, so "list_for_each (" is consistent with it, it is about
codifying practice contributors got used to over the years.
- Arnaldo
--
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] teach checkpatch.pl about list_for_each
On Thu, Jan 03, 2008 at 11:10:58AM +, Andy Whitcroft wrote: > We have had some stabs at changing this, but no consensus was reached on > whether it was a "for" or a "function". My memory is of there being > slightly more "without a space" tenders than the other and so it has not > been changed. This thread also seems so far to have not really > generated a concensus. So I would tend to leave things as they are. > > A third option might be to accept either on *for_each* constructs. > That might tend to lead to divergance. Difficult. However, also see my > later comments on "style guide". Pretty much all core code uses list_for_each_entry( so new code should follow that example. -- 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: [x86] kernel/audit.c cleanup according to checkpatch.pl
[Tomas Carnecky - Thu, Jan 03, 2008 at 01:10:28PM +0100]
> Cyrill Gorcunov wrote:
>> [=?ISO-8859-1?Q?J=F6rn_Engel_ - Thu, Jan 03, 2008 at 12:29:57PM +0100]
>> | On Thu, 3 January 2008 14:19:25 +0300, Cyrill Gorcunov wrote:
>> | > @@ -232,7 +232,8 @@ void audit_log_lost(const char *message)
>> | > | > if (print) {
>> | > printk(KERN_WARNING
>> | > - "audit: audit_lost=%d audit_rate_limit=%d
>> audit_backlog_limit=%d\n",
>> | > + "audit: audit_lost=%d audit_rate_limit=%d "
>> | > + "audit_backlog_limit=%d\n",
>> | > atomic_read(_lost),
>> | > audit_rate_limit,
>> | > audit_backlog_limit);
>> | | This hunk is a bit questionable. It can easily deceive a reader to
>> | assume two seperate lines printed out and sometimes defeats grepping
>> | for printk output to find the code generating the message.
>> | | Rest looks good to me.
>> | | Jörn
>> | | -- | He that composes himself is wiser than he that composes a book.
>> | -- B. Franklin
>> | indeed.
>> here is updated one (with these part removed)
>
> Instead of removing that part completely, why not print this:
> "audit: lost=%d rate_limit=%d backlog_limit=%d\n"
>
> In that line there were too many 'audit's IMHO, and if someone wants to
> grep 'audit_lost=' he still can, 'audit:.*lost=' or something like that..
>
> tom
>
Well, it seems David is a mainteiner of this code,
so if he would not argue against this the we could.
- Cyrill -
--
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: [x86] kernel/audit.c cleanup according to checkpatch.pl
Cyrill Gorcunov wrote:
[=?ISO-8859-1?Q?J=F6rn_Engel_ - Thu, Jan 03, 2008 at 12:29:57PM +0100]
| On Thu, 3 January 2008 14:19:25 +0300, Cyrill Gorcunov wrote:
| > @@ -232,7 +232,8 @@ void audit_log_lost(const char *message)
| >
| > if (print) {
| > printk(KERN_WARNING
| > - "audit: audit_lost=%d audit_rate_limit=%d
audit_backlog_limit=%d\n",
| > + "audit: audit_lost=%d audit_rate_limit=%d "
| > + "audit_backlog_limit=%d\n",
| > atomic_read(_lost),
| > audit_rate_limit,
| > audit_backlog_limit);
|
| This hunk is a bit questionable. It can easily deceive a reader to
| assume two seperate lines printed out and sometimes defeats grepping
| for printk output to find the code generating the message.
|
| Rest looks good to me.
|
| Jörn
|
| --
| He that composes himself is wiser than he that composes a book.
| -- B. Franklin
|
indeed.
here is updated one (with these part removed)
Instead of removing that part completely, why not print this:
"audit: lost=%d rate_limit=%d backlog_limit=%d\n"
In that line there were too many 'audit's IMHO, and if someone wants to
grep 'audit_lost=' he still can, 'audit:.*lost=' or something like that..
tom
--
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] xfrm_policy_destroy: rename and relative fixes
Since __xfrm_policy_destroy is used to destory the resources
allocated by xfrm_policy_alloc. So using the name
__xfrm_policy_destroy is not correspond with xfrm_policy_alloc.
Rename it to xfrm_policy_destroy.
And along with some instances that call xfrm_policy_alloc
but not using xfrm_policy_destroy to destroy the resource,
fix them.
Cc: David Miller <[EMAIL PROTECTED]>
Cc: Herbert Xu <[EMAIL PROTECTED]>
Signed-off-by: WANG Cong <[EMAIL PROTECTED]>
---
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index 58dfa82..6eff085 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -505,12 +505,12 @@ static inline void xfrm_pol_hold(struct xfrm_policy
*policy)
atomic_inc(>refcnt);
}
-extern void __xfrm_policy_destroy(struct xfrm_policy *policy);
+extern void xfrm_policy_destroy(struct xfrm_policy *policy);
static inline void xfrm_pol_put(struct xfrm_policy *policy)
{
if (atomic_dec_and_test(>refcnt))
- __xfrm_policy_destroy(policy);
+ xfrm_policy_destroy(policy);
}
#ifdef CONFIG_XFRM_SUB_POLICY
diff --git a/net/key/af_key.c b/net/key/af_key.c
index 26d5e63..3667f44 100644
--- a/net/key/af_key.c
+++ b/net/key/af_key.c
@@ -2291,8 +2291,7 @@ static int pfkey_spdadd(struct sock *sk, struct sk_buff
*skb, struct sadb_msg *h
return 0;
out:
- security_xfrm_policy_free(xp);
- kfree(xp);
+ xfrm_policy_destroy(xp);
return err;
}
@@ -3236,8 +3235,7 @@ static struct xfrm_policy *pfkey_compile_policy(struct
sock *sk, int opt,
return xp;
out:
- security_xfrm_policy_free(xp);
- kfree(xp);
+ xfrm_policy_destroy(xp);
return NULL;
}
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index 26b846e..087484e 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -206,7 +206,7 @@ EXPORT_SYMBOL(xfrm_policy_alloc);
/* Destroy xfrm_policy: descendant resources must be released to this moment.
*/
-void __xfrm_policy_destroy(struct xfrm_policy *policy)
+void xfrm_policy_destroy(struct xfrm_policy *policy)
{
BUG_ON(!policy->dead);
@@ -218,7 +218,7 @@ void __xfrm_policy_destroy(struct xfrm_policy *policy)
security_xfrm_policy_free(policy);
kfree(policy);
}
-EXPORT_SYMBOL(__xfrm_policy_destroy);
+EXPORT_SYMBOL(xfrm_policy_destroy);
static void xfrm_policy_gc_kill(struct xfrm_policy *policy)
{
diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
index e75dbdc..73cc755 100644
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -1048,7 +1048,7 @@ static struct xfrm_policy *xfrm_policy_construct(struct
xfrm_userpolicy_info *p,
return xp;
error:
*errp = err;
- kfree(xp);
+ xfrm_policy_destroy(xp);
return NULL;
}
--
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: [x86] kernel/audit.c cleanup according to checkpatch.pl
[=?ISO-8859-1?Q?J=F6rn_Engel_ - Thu, Jan 03, 2008 at 12:29:57PM +0100]
| On Thu, 3 January 2008 14:19:25 +0300, Cyrill Gorcunov wrote:
| > @@ -232,7 +232,8 @@ void audit_log_lost(const char *message)
| >
| > if (print) {
| > printk(KERN_WARNING
| > - "audit: audit_lost=%d audit_rate_limit=%d
audit_backlog_limit=%d\n",
| > + "audit: audit_lost=%d audit_rate_limit=%d "
| > + "audit_backlog_limit=%d\n",
| >atomic_read(_lost),
| >audit_rate_limit,
| >audit_backlog_limit);
|
| This hunk is a bit questionable. It can easily deceive a reader to
| assume two seperate lines printed out and sometimes defeats grepping
| for printk output to find the code generating the message.
|
| Rest looks good to me.
|
| Jörn
|
| --
| He that composes himself is wiser than he that composes a book.
| -- B. Franklin
|
indeed.
here is updated one (with these part removed)
---
kernel/audit.c | 66 ++-
1 files changed, 36 insertions(+), 30 deletions(-)
diff --git a/kernel/audit.c b/kernel/audit.c
index f93c271..22b951e 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -89,7 +89,7 @@ static intaudit_rate_limit;
/* Number of outstanding audit_buffers allowed. */
static int audit_backlog_limit = 64;
static int audit_backlog_wait_time = 60 * HZ;
-static int audit_backlog_wait_overflow = 0;
+static int audit_backlog_wait_overflow;
/* The identity of the user shutting down the audit system. */
uid_t audit_sig_uid = -1;
@@ -158,8 +158,7 @@ static void audit_set_pid(struct audit_buffer *ab, pid_t
pid)
void audit_panic(const char *message)
{
- switch (audit_failure)
- {
+ switch (audit_failure) {
case AUDIT_FAIL_SILENT:
break;
case AUDIT_FAIL_PRINTK:
@@ -173,15 +172,16 @@ void audit_panic(const char *message)
static inline int audit_rate_check(void)
{
- static unsigned longlast_check = 0;
- static int messages = 0;
+ static unsigned longlast_check;
+ static int messages;
static DEFINE_SPINLOCK(lock);
unsigned long flags;
unsigned long now;
unsigned long elapsed;
int retval = 0;
- if (!audit_rate_limit) return 1;
+ if (!audit_rate_limit)
+ return 1;
spin_lock_irqsave(, flags);
if (++messages < audit_rate_limit) {
@@ -210,7 +210,7 @@ static inline int audit_rate_check(void)
*/
void audit_log_lost(const char *message)
{
- static unsigned longlast_msg = 0;
+ static unsigned longlast_msg;
static DEFINE_SPINLOCK(lock);
unsigned long flags;
unsigned long now;
@@ -253,7 +253,8 @@ static int audit_set_rate_limit(int limit, uid_t loginuid,
u32 sid)
if (sid) {
char *ctx = NULL;
u32 len;
- if ((rc = selinux_sid_to_string(sid, , )) == 0) {
+ rc = selinux_sid_to_string(sid, , );
+ if (rc == 0) {
audit_log(NULL, GFP_KERNEL, AUDIT_CONFIG_CHANGE,
"audit_rate_limit=%d old=%d by auid=%u"
" subj=%s res=%d",
@@ -288,7 +289,8 @@ static int audit_set_backlog_limit(int limit, uid_t
loginuid, u32 sid)
if (sid) {
char *ctx = NULL;
u32 len;
- if ((rc = selinux_sid_to_string(sid, , )) == 0) {
+ rc = selinux_sid_to_string(sid, , );
+ if (rc == 0) {
audit_log(NULL, GFP_KERNEL, AUDIT_CONFIG_CHANGE,
"audit_backlog_limit=%d old=%d by auid=%u"
" subj=%s res=%d",
@@ -326,7 +328,8 @@ static int audit_set_enabled(int state, uid_t loginuid, u32
sid)
if (sid) {
char *ctx = NULL;
u32 len;
- if ((rc = selinux_sid_to_string(sid, , )) == 0) {
+ rc = selinux_sid_to_string(sid, , );
+ if (rc == 0) {
audit_log(NULL, GFP_KERNEL, AUDIT_CONFIG_CHANGE,
"audit_enabled=%d old=%d by auid=%u"
" subj=%s res=%d",
@@ -366,7 +369,8 @@ static int audit_set_failure(int state, uid_t loginuid, u32
sid)
if (sid) {
char *ctx = NULL;
u32 len;
- if ((rc = selinux_sid_to_string(sid, , )) == 0) {
+ rc = selinux_sid_to_string(sid, , );
+ if (rc == 0) {
audit_log(NULL, GFP_KERNEL, AUDIT_CONFIG_CHANGE,
"audit_failure=%d old=%d by auid=%u"
" subj=%s res=%d",
@@ -626,18 +630,20 @@ static int
Re: [PATCHv3] powerpc: DBox2 Board Support
Hi David,
+/ {
+ model = "unknown,dbox2"; // boot wrapper fills in correct manufacturer
Probably better just to leave model out of the dts and let the
bootwrapper add it.
Unfortunately, dtc requires a model:
$ dtc arch/powerpc/boot/dts/dbox2.dts
DTC: dts->dts on file "arch/powerpc/boot/dts/dbox2.dts"
ERROR: Missing "model" property in /
+ [EMAIL PROTECTED],0 {
+ compatible = "cfi-flash";
+ reg = <0 0 80>;
+ bank-width = <4>;
+ device-width = <1>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ [EMAIL PROTECTED] {
+ label = "BR bootloader";
+ reg = <0 2>;
+ read-only;
+ };
+ [EMAIL PROTECTED] {
+ label = "FLFS (U-Boot)";
+ reg = <2 2>;
+ };
+ [EMAIL PROTECTED] {
+ label = "rootfs";
+ reg = <4 7c>;
+ };
+ [EMAIL PROTECTED] {
Uh.. I really don't know what the MTD driver will handle these
overlapping partitions. I suspect it will not be pretty...
+ label = "Flash without bootloader";
+ reg = <2 7e>;
+ };
+ [EMAIL PROTECTED] {
+ label = "Complete Flash";
+ reg = <0 80>;
+ read-only;
+ };
+ };
+ };
MTD handles this correctly. dbox2 uses "Flash without bootloader" for flashing image
updates and "Complete Flash" for creating a backup of everything.
OpenWRT also uses overlapping partitions BTW (and also for flashing updates).
Thanks,
Jochen
--
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: [x86] kernel/audit.c cleanup according to checkpatch.pl
On Thu, 3 January 2008 14:19:25 +0300, Cyrill Gorcunov wrote:
> @@ -232,7 +232,8 @@ void audit_log_lost(const char *message)
>
> if (print) {
> printk(KERN_WARNING
> -"audit: audit_lost=%d audit_rate_limit=%d
> audit_backlog_limit=%d\n",
> +"audit: audit_lost=%d audit_rate_limit=%d "
> +"audit_backlog_limit=%d\n",
> atomic_read(_lost),
> audit_rate_limit,
> audit_backlog_limit);
This hunk is a bit questionable. It can easily deceive a reader to
assume two seperate lines printed out and sometimes defeats grepping
for printk output to find the code generating the message.
Rest looks good to me.
Jörn
--
He that composes himself is wiser than he that composes a book.
-- B. Franklin
--
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] teach checkpatch.pl about list_for_each
On Dec 2, 2007 1:03 PM, Christer Weinigel <[EMAIL PROTECTED]> wrote:
> Hi Andy,
>
> you seem to be the last person messing around with checkpatch.pl so I'm
> addressing this to you. :-)
>
> checkpatch complains about the following:
>
> WARNING: no space between function name and open parenthesis '('
> #520: FILE: drivers/spi/spi_s3c24xx_dma.c:478:
> + list_for_each_entry (transfer, >transfers, transfer_list) {
>
> which I think is a bit bogus since it actually is a for statement in
> disguise. The following patch adds list_for_each to the list of things
> that look like functions that it shouldn't complain about.
>
> By the way, what is the consensus on lines over 80 characters?
> checkpatch complains about the following:
>
> WARNING: line over 80 characters
> #762: FILE: drivers/spi/spi_s3c24xx_dma.c:720:
> + printk(KERN_INFO "S3C24xx SPI DMA driver (c) 2007 Nordnav
> Technologies AB\n");
>
> I can of course break this into:
>
> printk(KERN_INFO "S3C24xx SPI DMA driver (c) 2007 Nordnav "
>"Technologies AB\n");
I'd not split it in the middle of a name or phrase if possible.
printk(KERN_INFO "S3C24xx SPI DMA driver"
"(c) 2007 Nordnav Technologies AB\n");
but ...
> but in my opinion that becomes more even unreadable. Would it be
> possible to add a special case so that checkpatch ignores long strings
> that go beyond 80 characters? Do you think it is a good idea?
... in this case
pr_info("S3C24xx SPI DMA driver (c) 2007 Nordnav Technologies AB\n");
might just push it under the limit.
cheers
Philipp
--
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/
[x86] kernel/audit.c cleanup according to checkpatch.pl
This patch eliminates code-style errors according
to checkpatch.pl
Signed-off-by: Cyrill Gorcunov <[EMAIL PROTECTED]>
---
Ingo, David, md5sums will be different for old and patched
asm listings due to:
- zero initialized static vars take off
- assignments moved out from 'if' conditions
- EXPORT_SYMBOL's set at appropriate places
anyway the changes are trivial, so even a glance review
would be enough to ensure that it doesn't bring errors
into the kernel
before:
total: 20 errors, 17 warnings, 1473 lines checked
after:
total: 2 errors, 12 warnings, 1480 lines checked
Any comments are welcome.
kernel/audit.c | 69 ++-
1 files changed, 38 insertions(+), 31 deletions(-)
diff --git a/kernel/audit.c b/kernel/audit.c
index f93c271..4e71602 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -89,7 +89,7 @@ static intaudit_rate_limit;
/* Number of outstanding audit_buffers allowed. */
static int audit_backlog_limit = 64;
static int audit_backlog_wait_time = 60 * HZ;
-static int audit_backlog_wait_overflow = 0;
+static int audit_backlog_wait_overflow;
/* The identity of the user shutting down the audit system. */
uid_t audit_sig_uid = -1;
@@ -158,8 +158,7 @@ static void audit_set_pid(struct audit_buffer *ab, pid_t
pid)
void audit_panic(const char *message)
{
- switch (audit_failure)
- {
+ switch (audit_failure) {
case AUDIT_FAIL_SILENT:
break;
case AUDIT_FAIL_PRINTK:
@@ -173,15 +172,16 @@ void audit_panic(const char *message)
static inline int audit_rate_check(void)
{
- static unsigned longlast_check = 0;
- static int messages = 0;
+ static unsigned longlast_check;
+ static int messages;
static DEFINE_SPINLOCK(lock);
unsigned long flags;
unsigned long now;
unsigned long elapsed;
int retval = 0;
- if (!audit_rate_limit) return 1;
+ if (!audit_rate_limit)
+ return 1;
spin_lock_irqsave(, flags);
if (++messages < audit_rate_limit) {
@@ -210,7 +210,7 @@ static inline int audit_rate_check(void)
*/
void audit_log_lost(const char *message)
{
- static unsigned longlast_msg = 0;
+ static unsigned longlast_msg;
static DEFINE_SPINLOCK(lock);
unsigned long flags;
unsigned long now;
@@ -232,7 +232,8 @@ void audit_log_lost(const char *message)
if (print) {
printk(KERN_WARNING
- "audit: audit_lost=%d audit_rate_limit=%d
audit_backlog_limit=%d\n",
+ "audit: audit_lost=%d audit_rate_limit=%d "
+ "audit_backlog_limit=%d\n",
atomic_read(_lost),
audit_rate_limit,
audit_backlog_limit);
@@ -253,7 +254,8 @@ static int audit_set_rate_limit(int limit, uid_t loginuid,
u32 sid)
if (sid) {
char *ctx = NULL;
u32 len;
- if ((rc = selinux_sid_to_string(sid, , )) == 0) {
+ rc = selinux_sid_to_string(sid, , );
+ if (rc == 0) {
audit_log(NULL, GFP_KERNEL, AUDIT_CONFIG_CHANGE,
"audit_rate_limit=%d old=%d by auid=%u"
" subj=%s res=%d",
@@ -288,7 +290,8 @@ static int audit_set_backlog_limit(int limit, uid_t
loginuid, u32 sid)
if (sid) {
char *ctx = NULL;
u32 len;
- if ((rc = selinux_sid_to_string(sid, , )) == 0) {
+ rc = selinux_sid_to_string(sid, , );
+ if (rc == 0) {
audit_log(NULL, GFP_KERNEL, AUDIT_CONFIG_CHANGE,
"audit_backlog_limit=%d old=%d by auid=%u"
" subj=%s res=%d",
@@ -326,7 +329,8 @@ static int audit_set_enabled(int state, uid_t loginuid, u32
sid)
if (sid) {
char *ctx = NULL;
u32 len;
- if ((rc = selinux_sid_to_string(sid, , )) == 0) {
+ rc = selinux_sid_to_string(sid, , );
+ if (rc == 0) {
audit_log(NULL, GFP_KERNEL, AUDIT_CONFIG_CHANGE,
"audit_enabled=%d old=%d by auid=%u"
" subj=%s res=%d",
@@ -366,7 +370,8 @@ static int audit_set_failure(int state, uid_t loginuid, u32
sid)
if (sid) {
char *ctx = NULL;
u32 len;
- if ((rc = selinux_sid_to_string(sid, , )) == 0) {
+ rc = selinux_sid_to_string(sid, , );
+ if (rc == 0) {
audit_log(NULL, GFP_KERNEL, AUDIT_CONFIG_CHANGE,
"audit_failure=%d
Re: [patch 1/3] move WARN_ON() out of line
Hi Arjan,
On Jan 3, 2008 2:56 AM, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> +int do_warn_on(const unsigned long condition, const char *file,
> + const int line, const char *function)
> +{
> + if (unlikely(condition)) {
> + printk(KERN_WARNING "WARNING: at %s:%d %s()\n",
> + __FILE__, __LINE__, __FUNCTION__);
I don't think you want to use __FILE__ and friends here...
--
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: struct should not be named same way as function in sony-laptop
On Thu, Jan 03, 2008 at 12:01:54PM +0100, Pavel Machek wrote: > Naming struct and function by same name is evil. Rename the struct. Um... why? It's not even particulary bad style per se... Occurs less frequently than things like struct foo *foo; but nothing inherently terrible and not likely to cause any kind of confusion. -- 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: freeze vs freezer
Am Donnerstag, 3. Januar 2008 10:52:53 schrieb Nigel Cunningham: > Hi. > > Oliver Neukum wrote: > > Am Donnerstag 03 Januar 2008 schrieb Nigel Cunningham: > >> On top of this, I made a (too simple at the moment) freeze_filesystems > >> function which iterates through _blocks in reverse order, freezing > >> fuse filesystems or ordinary ones. I say 'too simple' because it doesn't > >> currently allow for the possibility of someone mounting (say) ext3 on > >> fuse, but that would just be an extension of what's already done. > > > > How do you deal with fuse server tasks using other fuse filesystems? > > Since they're frozen in reverse order, the dependant one would be frozen > first. Say I do: a) mount fuse on /tmp/first b) mount fuse on /tmp/second Then the server task for (a) does "ls /tmp/second". So it will be frozen, right? How do you then freeze (a)? And keep in mind that the server task may have forked. Regards Oliver -- 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] teach checkpatch.pl about list_for_each
On Sun, Dec 02, 2007 at 01:03:35PM +0100, Christer Weinigel wrote:
> Hi Andy,
>
> you seem to be the last person messing around with checkpatch.pl so I'm
> addressing this to you. :-)
>
> checkpatch complains about the following:
>
> WARNING: no space between function name and open parenthesis '('
> #520: FILE: drivers/spi/spi_s3c24xx_dma.c:478:
> + list_for_each_entry (transfer, >transfers, transfer_list) {
>
> which I think is a bit bogus since it actually is a for statement in
> disguise. The following patch adds list_for_each to the list of things
> that look like functions that it shouldn't complain about.
We have had some stabs at changing this, but no consensus was reached on
whether it was a "for" or a "function". My memory is of there being
slightly more "without a space" tenders than the other and so it has not
been changed. This thread also seems so far to have not really
generated a concensus. So I would tend to leave things as they are.
A third option might be to accept either on *for_each* constructs.
That might tend to lead to divergance. Difficult. However, also see my
later comments on "style guide".
>
> By the way, what is the consensus on lines over 80 characters?
> checkpatch complains about the following:
>
> WARNING: line over 80 characters
> #762: FILE: drivers/spi/spi_s3c24xx_dma.c:720:
> + printk(KERN_INFO "S3C24xx SPI DMA driver (c) 2007 Nordnav
> Technologies AB\n");
>
> I can of course break this into:
>
> printk(KERN_INFO "S3C24xx SPI DMA driver (c) 2007 Nordnav "
> "Technologies AB\n");
>
> but in my opinion that becomes more even unreadable. Would it be
> possible to add a special case so that checkpatch ignores long strings
> that go beyond 80 characters? Do you think it is a good idea?
I think you are miss-understanding the point of checkpatch here. It has
flagged this line as suspect. You are happy it is better as it is. You
should therefore leave it as it is as you "are happy to justify that
checkpatch failure". Checkpatch is a style guide, if it complains you
should think about its complaint and act as you see fit in response.
Sometimes you will ignore it, that is fine.
-apw
--
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/
don't #error on higher HZ values
For some crazy reason (trying to work around hw problem in i810) I wanted to use HZ around 4000. Signed-off-by: Pavel Machek <[EMAIL PROTECTED]> Pavel diff --git a/include/linux/jiffies.h b/include/linux/jiffies.h index 8b08002..7ba9e47 100644 --- a/include/linux/jiffies.h +++ b/include/linux/jiffies.h @@ -29,6 +29,12 @@ #elif HZ >= 384 && HZ < 768 # define SHIFT_HZ 9 #elif HZ >= 768 && HZ < 1536 # define SHIFT_HZ 10 +#elif HZ >= 1536 && HZ < 3072 +# define SHIFT_HZ 11 +#elif HZ >= 3072 && HZ < 6144 +# define SHIFT_HZ 12 +#elif HZ >= 6144 && HZ < 12288 +# define SHIFT_HZ 13 #else # error You lose. #endif -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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/2] Kprobes: Move kprobes examples to samples/
* Ananth N Mavinakayanahalli <[EMAIL PROTECTED]> wrote: > > feature request: please make this work in the !modular case as well > > - if built-in then it should just run sometime during bootup and run > > the tests and report success/failure. This way automated testing can > > pick up any regressions much easier. > > Will try cook up something along those lines. It'll be easy to verify > if the probes inserted and removed properly, but verifying handlers > run correctly will need some work. > > We have a sort of regression test bucket that uses expect to parse the > dmesg to verify handlers did run correctly; that isn't a totally > in-kernel solution anyway. I have a couple of ideas in mind to make it > easier. Great. Would be really nice to have something along the lines of CONFIG_DEBUG_LOCKING_API_SELFTESTS. Those unit tests took time to develop, but they caught more than 90% (!) of the internal lockdep engine bugs before they ever hit mainline. Ingo -- 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/
struct should not be named same way as function in sony-laptop
Naming struct and function by same name is evil. Rename the struct.
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
diff --git a/drivers/misc/sony-laptop.c b/drivers/misc/sony-laptop.c
index b0f6803..31ce39d 100644
--- a/drivers/misc/sony-laptop.c
+++ b/drivers/misc/sony-laptop.c
@@ -1180,7 +1180,7 @@ struct sony_pic_ioport {
struct list_headlist;
};
-struct sony_pic_irq {
+struct sony_pic_irqdesc {
struct acpi_resource_irqirq;
struct list_headlist;
};
@@ -1192,7 +1192,7 @@ struct sony_pic_dev {
u8 bluetooth_power;
u8 wwan_power;
struct acpi_device *acpi_dev;
- struct sony_pic_irq *cur_irq;
+ struct sony_pic_irqdesc *cur_irq;
struct sony_pic_ioport *cur_ioport;
struct list_headinterrupts;
struct list_headioports;
@@ -2094,7 +2094,7 @@ sony_pic_read_possible_resource(struct a
case ACPI_RESOURCE_TYPE_IRQ:
{
struct acpi_resource_irq *p = >data.irq;
- struct sony_pic_irq *interrupt = NULL;
+ struct sony_pic_irqdesc *interrupt = NULL;
if (!p || !p->interrupt_count) {
/*
* IRQ descriptors may have no IRQ# bits set,
@@ -2218,7 +2218,7 @@ static int sony_pic_disable(struct acpi_
* Call _SRS to set current resources
*/
static int sony_pic_enable(struct acpi_device *device,
- struct sony_pic_ioport *ioport, struct sony_pic_irq *irq)
+ struct sony_pic_ioport *ioport, struct sony_pic_irqdesc *irq)
{
acpi_status status;
int result = 0;
@@ -2381,7 +2381,7 @@ found:
static int sony_pic_remove(struct acpi_device *device, int type)
{
struct sony_pic_ioport *io, *tmp_io;
- struct sony_pic_irq *irq, *tmp_irq;
+ struct sony_pic_irqdesc *irq, *tmp_irq;
if (sony_pic_disable(device)) {
printk(KERN_ERR DRV_PFX "Couldn't disable device.\n");
@@ -2422,7 +2422,7 @@ static int sony_pic_add(struct acpi_devi
{
int result;
struct sony_pic_ioport *io, *tmp_io;
- struct sony_pic_irq *irq, *tmp_irq;
+ struct sony_pic_irqdesc *irq, *tmp_irq;
printk(KERN_INFO DRV_PFX "%s v%s.\n",
SONY_PIC_DRIVER_NAME, SONY_LAPTOP_DRIVER_VERSION);
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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] [15/20] x86: Move X86_FEATURE_CONSTANT_TSC into early cpu feature detection
* Andi Kleen <[EMAIL PROTECTED]> wrote: > Need this in the next patch in time_init and that happens early. > > This includes a minor fix on i386 where early_intel_workarounds() > [which is now called early_init_intel] really executes early as the > comments say. thanks, applied. I'll wait for Thomas to comment on the TSC bits though. (but as long as we carry this patch in x86.git it should make your future patching efforts easier.) Ingo -- 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] [20/20] x86: Print which shared library/executable faulted in segfault etc. messages
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> They now look like
>
> hal-resmgr[13791]: segfault at 3c rip 2b9c8caec182 rsp 7fff1e825d30
> error 4 in libacl.so.1.1.0[2b9c8caea000+6000]
>
> This makes it easier to pinpoint bugs to specific libraries.
yep, that's really useful.
I think the patch needs one more iteration though:
> And printing the offset into a mapping also always allows to find the
> correct fault point in a library even with randomized mappings. Previously
> there was no way to actually find the correct code address inside
> the randomized mapping.
>
> Relies on earlier patch to shorten the printk formats.
>
> They are often now longer than 80 characters, but I think that's worth
> it.
why not make it multi-line? that way the %lx hack wouldnt be needed
either.
> +void print_vma_addr(char *prefix, unsigned long ip)
> +{
> + struct mm_struct *mm = current->mm;
> + struct vm_area_struct *vma;
> + down_read(>mmap_sem);
> + vma = find_vma(mm, ip);
grumble. Proper CodingStyle please.
> + if (buf) {
> + char *p, *s;
> + p = d_path(f->f_dentry, f->f_vfsmnt, buf, PAGE_SIZE);
this one too.
> + if (show_unhandled_signals && printk_ratelimit()) {
> + printk("%s[%d] bad frame in %s frame:%p ip:%lx sp:%lx orax:%lx",
> me->comm,me->pid,where,frame,regs->ip,regs->sp,regs->orig_ax);
and this.
Ingo
--
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 0/4] PM: Do not destroy/create devices while suspended (rev. 2)
Hi! > > > > That way any suspend breakage would be detectable (and bisectable) > > > > in automated testing - if the resume does not come back after 10-20 > > > > seconds then the test failed. > > > > > > Yes, but please note that some systems require user space > > > manipulations of the graphics adapter for suspend to work and to > > > detect a breakage of such a system you need to boot it into X and use > > > s2ram to suspend. > > > > yeah, i wouldnt expect graphics mode to come back without quirks. But it > > should still work fine over the network, right? (which is my main mode > > of testing anyway) > > Well, if the graphics is sufficiently broken, it won't resume at > all. Actually, no. Unless you try to boot the bios, it should come up without graphics. Hmm... first framebuffer access may kill the machine at that point... so disable framebuffer...? ;-). vga=1 and no acpi_sleep options usually does the trick for me. That should work everywhere, independend of graphics options, AFAICT. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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] [19/20] x86: Use shorter addresses in i386 segfault printks
* Andi Kleen <[EMAIL PROTECTED]> wrote: > x86: Use shorter addresses in i386 segfault printks hm, why? It's pretty well-established that we print addresses 8 char wide on 32-bit. Ingo -- 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] [12/20] x86: Use a per cpu timer for correctable machine check checking
* Andi Kleen <[EMAIL PROTECTED]> wrote: > Previously the code used a single timer that then used > smp_call_function to interrupt all CPUs while the original CPU was > waiting for them. > > But it is better / more real time and more power friendly to simply > run individual timers on each CPU so they all do this independently. > > This way no single CPU has to wait for all others. i think we should unify this code first and provide it on 32-bit as well. Ingo -- 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/20] x86: Introduce nsec_barrier()
* Andi Kleen <[EMAIL PROTECTED]> wrote: > nsec_barrier() is a new barrier primitive that stops RDTSC speculation > to avoid races with timer interrupts on other CPUs. > > Add it to all architectures. Except for x86 it is a nop right now. I > only tested x86, but it's a very simple change. > > On x86 it expands either to LFENCE (for Intel CPUs) or MFENCE (for AMD > CPUs) which stops RDTSC on all currently known microarchitectures that > implement SSE. On CPUs without SSE there is generally no RDTSC > speculation. i've picked up your rdtsc patches into x86.git but have simplified it: there's no nsec_barrier() anymore - rdtsc() is always synchronous. MFENCE/LFENCE is fast enough. Open-coding such barriers almost always leads to needless trouble. Please check the next x86.git tree. Ingo -- 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: [RFC][PATCH 3/7] ACPI: Separate disabling of GPEs from _PTS
Hi! > From: Rafael J. Wysocki <[EMAIL PROTECTED]> > > The preparation to enter an ACPI system sleep state is now tied to > the disabling of GPEs, but the GPEs should not be disabled before > suspending devices. Since on ACPI 1.0x systems the _PTS global > control method should be executed before suspending devices, we > need to disable GPEs separately. > > Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> Looks ok to me... as does rest of the series. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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] [11/20] x86: Use the correct cpuid method to detect MWAIT support for C states
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> +static int mwait_usable(const struct cpuinfo_x86 *c)
> +{
> + if (force_mwait)
> + return 1;
> + /* Any C1 states supported? */
> + return c->cpuid_level >= 5 && ((cpuid_edx(5) >> 4) & 0xf) > 0;
> +}
> +
> void __cpuinit select_idle_routine(const struct cpuinfo_x86 *c)
> {
> - if (cpu_has(c, X86_FEATURE_MWAIT)) {
> + if (cpu_has(c, X86_FEATURE_MWAIT) && mwait_usable(c)) {
> printk("monitor/mwait feature present.\n");
hm, why not clear FEATURE_MWAIT if it's "not usable"? That's the
standard approach we do for CPU features that do not work.
Ingo
--
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] [10/20] i386: Move MWAIT idle check to generic CPU initialization
* Andi Kleen <[EMAIL PROTECTED]> wrote: > Previously it was only run for Intel CPUs, but AMD Fam10h implements > MWAIT too. > > This matches 64bit behaviour. > > Signed-off-by: Andi Kleen <[EMAIL PROTECTED]> thanks, applied. Ingo -- 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: [RFC][PATCH 2/7] ACPI: Separate invocations of _GTS and _BFS from _PTS and _WAK
On Thu 2007-12-27 19:15:16, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki <[EMAIL PROTECTED]> > > The execution of ACPI global control methods _GTS and _BFS is > currently tied to the preparation to enter a sleep state and to the > leaving of the sleep state, respectively. However, these functions > are called before disabling the nonboot CPUs and after enabling > them, respectively (in fact, on ACPI 1.0x systems the first of them > ought to be called before suspending devices), while according to the > ACPI specification, _GTS is to be executed right prior to entering > the system sleep state and _BFS is to be executed right after the > platfor firmware has returned control to the OS on wake up. > > Move the execution of _GTS and _BFS to the right places. > > Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> Seems ok to me, but it is 2.6.25 material earliest, right? -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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] [9/20] x86: Don't use oops_begin in 64bit mce code
* Andi Kleen <[EMAIL PROTECTED]> wrote: > It is not really useful to lock machine checks against oopses. And > machine checks normally don't nest, so they don't need their own > locking. Just call bust_spinlock/console_verbose directly. is this in response to any particular incident you've seen? Ingo -- 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/
"mconf" and help texts
Hello everybody!
[[ Please keep me CC'ed. Thank you. ]]
I just tried looking at NF_CONNTRACK_MARK (menuconfig, in 2.6.23.12), and
found it disallowed.
So I took a look at "Help", and saw that blob:
Selected by: NETFILTER_XT_TARGET_CONNMARK && NET && INET && NETFILTER &&
NETFILTER_XTABLES && (IP_NF_MANGLE || IP6_NF_MANGLE) && NF_CONNTRACK ||
NETFILTER_XT_MATCH_CONNMARK && NET && INET && NETFILTER &&
NETFILTER_XTABLES && NF_CONNTRACK || IP_NF_TARGET_CLUSTERIP && NET &&
INET && NETFILTER && IP_NF_MANGLE && EXPERIMENTAL && NF_CONNTRACK_IPV4
That is a _bit_ unreadable.
Now breaking that into multiple lines would show me this:
NETFILTER_XT_TARGET_CONNMARK && NET && INET && NETFILTER &&
NETFILTER_XTABLES && (IP_NF_MANGLE || IP6_NF_MANGLE) && NF_CONNTRACK ||
NETFILTER_XT_MATCH_CONNMARK && NET && INET && NETFILTER &&
NETFILTER_XTABLES && NF_CONNTRACK ||
IP_NF_TARGET_CLUSTERIP && NET && INET && NETFILTER && IP_NF_MANGLE &&
EXPERIMENTAL && NF_CONNTRACK_IPV4
Is that correct? If yes, how about putting such line-breaks in the shown text?
Furthermore ... how about removing duplicate symbols from there?
A bit of editing shows me
1 EXPERIMENTAL
3 INET
1 IP6_NF_MANGLE
2 IP_NF_MANGLE
1 IP_NF_TARGET_CLUSTERIP
3 NET
3 NETFILTER
2 NETFILTER_XTABLES
1 NETFILTER_XT_MATCH_CONNMARK
1 NETFILTER_XT_TARGET_CONNMARK
2 NF_CONNTRACK
1 NF_CONNTRACK_IPV4
Now I wonder ... complete reductions of this might be a bit awful, but
repeated
INET && ... ||
INET && ... ||
INET && ...
could surely be made shorter.
It would be nice (depending on your value of "nice", of course :-))
to see
NET && INET && NETFILTER &&
NETFILTER_XT_TARGET_CONNMARK && NETFILTER_XTABLES &&
(IP_NF_MANGLE || IP6_NF_MANGLE) && NF_CONNTRACK ||
NETFILTER_XT_MATCH_CONNMARK && NETFILTER_XTABLES && NF_CONNTRACK ||
IP_NF_TARGET_CLUSTERIP && IP_NF_MANGLE && EXPERIMENTAL && NF_CONNTRACK_IPV4
I'm not sure whether it would be worth the additional work to get
NET && INET && NETFILTER &&
( NETFILTER_XTABLES && NF_CONNTRACK &&
( NETFILTER_XT_MATCH_CONNMARK && NETFILTER_XTABLES ) ||
( NETFILTER_XT_TARGET_CONNMARK && NF_CONNTRACK &&
(IP_NF_MANGLE || IP6_NF_MANGLE) ) ||
IP_NF_TARGET_CLUSTERIP && IP_NF_MANGLE && EXPERIMENTAL &&
NF_CONNTRACK_IPV4
(if I translated that correctly, manually)
Would there be interest if I supplied some script (perl would be easiest for
me) that tried to simplify such strings? Calling that from C wouldn't be
nice, but acceptable for the occasional help text showing.
There has to be some expression parser for that ... could that be used? Where
gets this string built?
As a side-node - I cannot get xconfig to work (pkg-config); is there some way
in menuconfig to see why some config option is disallowed? The location tree
shows some data ("-> Networking support (NET [=y])"), but not for all
dependencies. [Does xconfig allow enabling them while seeing this option?]
Regards,
Phil
--
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/2] Kprobes: Move kprobes examples to samples/
On Thu, Jan 03, 2008 at 10:33:03AM +0100, Ingo Molnar wrote: > > * Ananth N Mavinakayanahalli <[EMAIL PROTECTED]> wrote: > > > From: Ananth N Mavinakayanahalli <[EMAIL PROTECTED]> > > > > Move kprobes examples from Documentation/kprobes.txt to under > > samples/. Patch originally by Randy Dunlap. > > nice! > > > +config SAMPLE_KPROBES > > + tristate "Build kprobes examples -- loadable modules only" > > + depends on KPROBES && m > > + help > > + This build several kprobes example modules. > > feature request: please make this work in the !modular case as well - if > built-in then it should just run sometime during bootup and run the > tests and report success/failure. This way automated testing can pick up > any regressions much easier. Will try cook up something along those lines. It'll be easy to verify if the probes inserted and removed properly, but verifying handlers run correctly will need some work. We have a sort of regression test bucket that uses expect to parse the dmesg to verify handlers did run correctly; that isn't a totally in-kernel solution anyway. I have a couple of ideas in mind to make it easier. Ananth -- 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: Kernel BUG in 2.6.23.9
Arjan van de Ven wrote: On Sun, 09 Dec 2007 14:49:16 -0500 Jerry Geis <[EMAIL PROTECTED]> wrote: I am using centos 5.1, 2.6.23.9 kernel. Machine works great all day. Then sometime through the night the kernel dies, the trace is below. is this when a 3D screensaver is active? Probably worth running without the proprietary nvidia driver it also tends to get more people to pay attention :) In addition to this suspicion; you're the first one to report this oops since at least a year as shown in http://www.kerneloops.org/guilty.php?guilty=journal_dirty_data=2.6.23-release=1540096=1572863 so it might well be something weird on your side (like the binary driver or some heat problem created by having a 3D screensaver) Hi, For a while, I have the same behavior. I tested under 2.6.23.9, 2.6.24-rc3 and rc4. So all of these kernels have the same issue. Also, I don't use any proprietary driver. My video card is Intel-945 and I use the "intel" driver. I use 3D screensavers as well. These kernels die after some long idles like 1 or 2 days after. My distribution is Kubuntu 7.10 and with Kubuntu kernel this behavior did not happened. So, how to track this interesting problem ? Any ideas welcomed :-) Cheers, Tarkan Erimer -- 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] [1/20] x86: Make ptrace.h safe to include from assembler code
* Andi Kleen <[EMAIL PROTECTED]> wrote: > Index: linux/include/asm-x86/ptrace-abi.h > === > --- linux.orig/include/asm-x86/ptrace-abi.h > +++ linux/include/asm-x86/ptrace-abi.h > @@ -80,6 +80,7 @@ > > #define PTRACE_SINGLEBLOCK 33 /* resume execution until next branch */ > > +#ifndef __ASSEMBLY__ hm, this patch misses a rationale - what assembly code includes ptrace-abi.h directly or indirectly? Did you see any build breakage with x86.git that requires this? (if yes then please send me the .config) Ingo -- 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: freeze vs freezer
Hi.
Oliver Neukum wrote:
> Am Donnerstag 03 Januar 2008 schrieb Nigel Cunningham:
>> On top of this, I made a (too simple at the moment) freeze_filesystems
>> function which iterates through _blocks in reverse order, freezing
>> fuse filesystems or ordinary ones. I say 'too simple' because it doesn't
>> currently allow for the possibility of someone mounting (say) ext3 on
>> fuse, but that would just be an extension of what's already done.
>
> How do you deal with fuse server tasks using other fuse filesystems?
Since they're frozen in reverse order, the dependant one would be frozen
first.
> How does freeze_filesystems() look?
Removing my ugly debugging statements, it's currently:
/**
* freeze_filesystems - lock all filesystems and force them into a
consistent
* state
*/
void freeze_filesystems(int which)
{
struct super_block *sb;
lockdep_off();
/*
* Freeze in reverse order so filesystems dependant upon others are
* frozen in the right order (eg. loopback on ext3).
*/
list_for_each_entry_reverse(sb, _blocks, s_list) {
if (sb->s_type->fs_flags & FS_IS_FUSE &&
sb->s_frozen == SB_UNFROZEN &&
which & FS_FREEZER_FUSE) {
sb->s_frozen = SB_FREEZE_TRANS;
sb->s_flags |= MS_FROZEN;
continue;
}
if (!sb->s_root || !sb->s_bdev ||
(sb->s_frozen == SB_FREEZE_TRANS) ||
(sb->s_flags & MS_RDONLY) ||
(sb->s_flags & MS_FROZEN) ||
!(which & FS_FREEZER_NORMAL))
continue;
freeze_bdev(sb->s_bdev);
sb->s_flags |= MS_FROZEN;
}
lockdep_on();
}
Nigel
--
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: freeze vs freezer
Am Donnerstag 03 Januar 2008 schrieb Nigel Cunningham: > On top of this, I made a (too simple at the moment) freeze_filesystems > function which iterates through _blocks in reverse order, freezing > fuse filesystems or ordinary ones. I say 'too simple' because it doesn't > currently allow for the possibility of someone mounting (say) ext3 on > fuse, but that would just be an extension of what's already done. How do you deal with fuse server tasks using other fuse filesystems? How does freeze_filesystems() look? Regards Oliver -- 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] x86: Use is_kprobe_fault to better match usage
* Harvey Harrison <[EMAIL PROTECTED]> wrote: > Currently the notify_page_fault helper is used to test it the page > fault was caused by a kprobe causing an early return from > do_page_fault. > > Change the name of the helper to is_kprobe_fault to match the usage > and remove the preempt_disable/enable pair around kprobe_running() > with an explicit test for preemption. The idea for this comes from a > patch by Quentin Barnes to kprobes.c > > Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]> hm, this doesnt apply: Hunk #3 FAILED at 426. Hunk #4 succeeded at 413 (offset -22 lines). 1 out of 4 hunks FAILED -- rejects in file arch/x86/mm/fault_32.c patching file arch/x86/mm/fault_64.c Hunk #3 FAILED at 476. Hunk #4 succeeded at 475 (offset -10 lines). 1 out of 4 hunks FAILED -- rejects in file arch/x86/mm/fault_64.c could you double-check x86.git#mm, perhaps we are out of sync with a patch somewhere? Ingo -- 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/2] Kprobes: Move kprobes examples to samples/
* Ananth N Mavinakayanahalli <[EMAIL PROTECTED]> wrote: > From: Ananth N Mavinakayanahalli <[EMAIL PROTECTED]> > > Move kprobes examples from Documentation/kprobes.txt to under > samples/. Patch originally by Randy Dunlap. nice! > +config SAMPLE_KPROBES > + tristate "Build kprobes examples -- loadable modules only" > + depends on KPROBES && m > + help > + This build several kprobes example modules. feature request: please make this work in the !modular case as well - if built-in then it should just run sometime during bootup and run the tests and report success/failure. This way automated testing can pick up any regressions much easier. Ingo -- 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: [GIT] More NFS client fixes for 2.6.24-rc6
* Trond Myklebust <[EMAIL PROTECTED]> wrote:
> commit 53478daff2c8b494d2af1ede6611f166f81bc393
> Author: Trond Myklebust <[EMAIL PROTECTED]>
> Date: Wed Jan 2 13:28:57 2008 -0500
>
> NFS: Fix a possible Oops in fs/nfs/super.c
>
> Sigh... commit 4584f520e1f773082ef44ff4f8969a5d992b16ec (NFS: Fix NFS
> mountpoint crossing...) had a slight flaw: server can be NULL if sget()
> returned an existing superblock.
>
> Fix the fix by dereferencing s->s_fs_info.
>
> Also add in the same namespace Oops fix for NFSv4 in both the mountpoint
> crossing case, and the referral case.
>
> Signed-off-by: Trond Myklebust <[EMAIL PROTECTED]>
shouldnt this commit have included the full credit of the bugfix:
http://bugzilla.kernel.org/show_bug.cgi?id=9647
>
Description From Adrian Bunk 2007-12-27 12:36
The Coverity checker spotted that commit
4584f520e1f773082ef44ff4f8969a5d992b16ec introduced the following NULL
dereference in 2.6.24-rc6:
<-- snip -->
if (s->s_fs_info != server) {
nfs_free_server(server);
server = NULL; <---
}
--- Comment #1 From Adrian Bunk 2007-12-27 12:37:42 ---
The NULL dereference is at the
server->nfs_client->rpc_ops->dir_inode_ops.
<--
Ingo
--
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 1/3] move WARN_ON() out of line
* Arjan van de Ven <[EMAIL PROTECTED]> wrote: > +#define WARN_ON(condition) do_warn_on((unsigned long)(condition), __FILE__, \ > + __LINE__, __FUNCTION__) hm. This passes in 4 arguments to do_warn_on(). i think we could get away with no arguments (!), by using section tricks. Firstly, we can get rid of __FUNCTION__ and replace it with a ksyms lookup - that is fine enough. Secondly, we could put __FILE__ and __LINE__ into a text section and key it up to the return address from do_warn_on(). the condition code should not be passed in at all i think - it creates extra function calls to do_warn_on() all the time. Ingo -- 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: neigh: timer & !nud_in_timer
John Sigler wrote: I noticed the following message in my kernel log. kernel: neigh: timer & !nud_in_timer (Might be due to a race condition.) I'm running a UP Linux version 2.6.22.1-rt9 ( http://rt.wiki.kernel.org/index.php ) The following /proc entries might be relevant. /proc/sys/net/ipv4/conf/all/arp_accept 0 /proc/sys/net/ipv4/conf/all/arp_announce 2 /proc/sys/net/ipv4/conf/all/arp_filter 0 /proc/sys/net/ipv4/conf/all/arp_ignore 1 I also lowered the priority of softirq-timer/0 to 10 which means it can be interrupted by other IRQ handlers. Comments or musings? -- 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: [RFC PATCH 01/11] Add basic support for gcc profiler instrumentation
* Steven Rostedt <[EMAIL PROTECTED]> wrote: > +# function tracing might turn this off: > +config REGPARM > + bool > + depends on !MCOUNT > + default y are you sure -pg really needs this? I just carried this along the years and went the path of least resistence, but we should not be reintroducing the !REGPARM build mode for the kernel. I'd not be surprised if there were a few issues with REGPARM + mcount, but we have to figure it out before merging ... Ingo -- 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: freeze vs freezer
Hi.
Rafael J. Wysocki wrote:
> On Wednesday, 2 of January 2008, Nigel Cunningham wrote:
>> Pavel Machek wrote:
So how do you handle threads that are blocked on I/O or a lock
during the system freeze process, then?
>>> We wait until they can continue.
>> So if I have a process blocked on an unavilable NFS mount, I can't
>> suspend?
> That's correct, you can't.
>
> [And I know what you're going to say. ;-)]
Why exactly does suspend/hibernation depend on "TASK_INTERRUPTIBLE"
instead of a zero preempt_count()? Really what we should do is just
iterate over all of the actual physical devices and tell each one
"Block new IO requests preemptably, finish pending DMA, put the
hardware in low-power mode, and prepare for suspend/hibernate". As
long as each driver knows how to do those simple things we can have
an entirely consistent kernel image for both suspend and for
hibernation.
>>> "each driver" means this is a lot of work. But yes, that is probably
>>> way to go, and patch would be welcome.
>> Yes, that does work. It's what I've done in my (preliminary) support for
>> fuse.
>
> Hmm, can you please elaborate a bit?
Sorry. I wasn't very unambiguous, was I? And I'm not sure now whether
you're meaning "How does fuse support relate to freezing block devices?"
or "What's this about fuse support?". Let me therefore seek to answer
both questions:
Higher level, I know (filesystems rather than block devices), but I was
meaning the general concept of blocking new requests and completing
existing ones worked fine for the supposedly impossible fuse support.
Re fuse support, let me start by saying "I know this doesn't handle all
situations, but I think it's a good enough proof-of-concept implementation".
I added some simple hooks to the code for submitting new work to fuse
threads.
#define FUSE_MIGHT_FREEZE(superblock, desc) \
do { \
int printed = 0; \
while(superblock->s_frozen != SB_UNFROZEN) { \
if (!printed) { \
printk("%d frozen in " desc ".\n", current->pid); \
printed = 1; \
} \
try_to_freeze(); \
yield(); \
} \
} while (0)
On top of this, I made a (too simple at the moment) freeze_filesystems
function which iterates through _blocks in reverse order, freezing
fuse filesystems or ordinary ones. I say 'too simple' because it doesn't
currently allow for the possibility of someone mounting (say) ext3 on
fuse, but that would just be an extension of what's already done.
The end result is:
int freeze_processes(void)
{
int error;
printk(KERN_INFO "Stopping fuse filesystems.\n");
freeze_filesystems(FS_FREEZER_FUSE);
freezer_state = FREEZER_FILESYSTEMS_FROZEN;
printk(KERN_INFO "Freezing user space processes ... ");
error = try_to_freeze_tasks(FREEZER_USER_SPACE);
if (error)
goto Exit;
printk(KERN_INFO "done.\n");
sys_sync();
printk(KERN_INFO "Stopping normal filesystems.\n");
freeze_filesystems(FS_FREEZER_NORMAL);
freezer_state = FREEZER_USERSPACE_FROZEN;
printk(KERN_INFO "Freezing remaining freezable tasks ... ");
error = try_to_freeze_tasks(FREEZER_KERNEL_THREADS);
if (error)
goto Exit;
printk(KERN_INFO "done.");
freezer_state = FREEZER_FULLY_ON;
Exit:
BUG_ON(in_atomic());
printk("\n");
return error;
}
Sorry if that's more info than you wanted.
Nigel
--
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] aio: negative offset should return -EINVAL
An AIO read or write should return -EINVAL if the offset is negative.
This check matches the one in pread and pwrite.
This was found by the libaio test suite.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
diff -r 18802689361a fs/aio.c
--- a/fs/aio.c Thu Jan 03 15:22:24 2008 +1100
+++ b/fs/aio.c Thu Jan 03 18:05:25 2008 +1100
@@ -1330,6 +1330,10 @@ static ssize_t aio_rw_vect_retry(struct
opcode = IOCB_CMD_PWRITEV;
}
+ /* This matches the pread()/pwrite() logic */
+ if (iocb->ki_pos < 0)
+ return -EINVAL;
+
do {
ret = rw_op(iocb, >ki_iovec[iocb->ki_cur_seg],
iocb->ki_nr_segs - iocb->ki_cur_seg,
--
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] aio: partial write should not return error code.
When an AIO write gets an error after writing some data (eg. ENOSPC), it should return the amount written already, not the error. Just like write() is supposed to. This was found by the libaio test suite. Signed-off-by: Rusty Russell <[EMAIL PROTECTED]> diff -r 18802689361a fs/aio.c --- a/fs/aio.c Thu Jan 03 15:22:24 2008 +1100 +++ b/fs/aio.c Thu Jan 03 18:05:25 2008 +1100 @@ -1346,6 +1350,13 @@ static ssize_t aio_rw_vect_retry(struct /* This means we must have transferred all that we could */ /* No need to retry anymore */ if ((ret == 0) || (iocb->ki_left == 0)) + ret = iocb->ki_nbytes - iocb->ki_left; + + /* If we managed to write some out we return that, rather than +* the eventual error. */ + if (opcode == IOCB_CMD_PWRITEV + && ret < 0 + && iocb->ki_nbytes - iocb->ki_left) ret = iocb->ki_nbytes - iocb->ki_left; return ret; -- 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 02/20] make the inode i_mmap_lock a reader/writer lock
* Nick Piggin <[EMAIL PROTECTED]> wrote: > > Have you done anything more with allowing > 256 CPUS in this > > spinlock patch? We've been testing with 1k cpus and to verify with > > -mm kernel, we need to "unpatch" these spinlock changes. > > Hi Mike, > > Actually I had it in my mind that 64 bit used single-byte locking like > i386, so I didn't think I'd caused a regression there. > > I'll take a look at fixing that up now. thanks - this is a serious showstopper for the ticket spinlock patch. ( which has otherwise been performing very well in x86.git so far - it has passed a few thousand bootup tests on 64-bit and 32-bit as well, so we are close to it being in a mergable state. Would be a pity to lose it due to the 256 cpus limit. ) Ingo -- 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/
