* Re: [PATCH 2/5] ide: add cpu cache flushes after kmapping and modifying a page
From: Tejun Heo @ 2006-06-04 9:09 UTC (permalink / raw)
To: Christoph Hellwig, Tejun Heo, Jens Axboe, James Bottomley,
Dave Miller, bzolnier, james.steward, jgarzik, mattjreimer,
Guennadi Liakhovetski, rmk, lkml, linux-ide, linux-scsi
In-Reply-To: <20060604081734.GA29696@infradead.org>
Christoph Hellwig wrote:
> On Sun, Jun 04, 2006 at 12:41:20PM +0900, Tejun Heo wrote:
>> data = bvec_kmap_irq(bvec, &flags);
>> drive->hwif->atapi_input_bytes(drive, data, count);
>> + flush_kernel_dcache_page(kmap_atomic_to_page(data));
>> bvec_kunmap_irq(data, &flags);
>
> shouldn't bvec_kunmap_irq do the flush_kernel_dcache_page call?
>
Eventually, yes. At the moment, not all archs implement
flush_kernel_dcache_page(), so converting
kmap();
modify buffer;
flush_dcache_page();
kunmap();
to
kmap_wrapper();
modify buffer;
kunmap_wrapper_which_calls_flush_kernel_dcache_page()
breaks cache coherency on those archs. The current patches simply add
calls to flush_kernel_dcache_page() where missing such that it doesn't
break anything while fixing cache coherency for arm and parisc. In the
long term...
1. implement flush_kernel_dcache_page() for all needed archs
2. update kmap interface such that the caller is mandated to specify
whether the buffer has been modified or not when unmapping (maybe
addition of simple boolean argument?)
3. update bvec_kmap_*() similarly
4. update all calls to kunmap & friends.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH] readahead: initial method - expected read size - fix fastcall
From: Andrew Morton @ 2006-06-04 9:07 UTC (permalink / raw)
To: Fengguang Wu; +Cc: Valdis.Kletnieks, diegocg, lista1, linux-kernel
In-Reply-To: <349406446.10828@ustc.edu.cn>
On Sun, 4 Jun 2006 15:34:15 +0800
Fengguang Wu <wfg@mail.ustc.edu.cn> wrote:
> Remove 'fastcall' directive for function readahead_close().
>
> It has drawn concerns from Andrew Morton.
Well. I think fastcall is ugly and vaguely silly. Now if we has a
really_really_fastcall then I'd like to use that!
> Now I have some benchmarks
> on it, and proved it as a _false_ optimization.
Sorry, I don't believe this will be measurable (and with CONFIG_REGPARM
it'll be a no-op).
But I'm always glad to see a fastcall disappear ;)
^ permalink raw reply
* Re: [RFC] Per-architecture randomization
From: Arjan van de Ven @ 2006-06-04 9:06 UTC (permalink / raw)
To: John Richard Moser; +Cc: linux-kernel
In-Reply-To: <44825E42.5090902@comcast.net>
On Sun, 2006-06-04 at 00:14 -0400, John Richard Moser wrote:
> Pavel Machek recommended per-architecture randomization defaults when I
> poked a (very hackish) patch up here. As follow-up, I have taken out
> the command line parameter code and used the infrastructure I wrote to
> implement per-architecture randomization settings.
>
> Three #defines are needed per architecture, preferably in
> include/asm-ARCH/processor.h or equivalent. These defines are as follows:
>
> STACK_ALIGN -- Alignment of the stack, typically 16 (bytes).
> If not defined, stack randomization is carried out to page
> granularity
> ARCH_RANDOM_STACK_BITS -- Bits of entropy to apply to the stack.
> If not defined, stack randomization is disabled by defining this
> as 0.
> ARCH_RANDOM_MMAP_BITS -- Bits of entropy to apply to the mmap() base.
> If not defined, mmap() randomization is disabled by defining this
> as 0.
eh....
I think you missed a few things..
like
1) This is per architecture already for the most part!
arch_align_stack() is obvious per architecture already
the mmap randomisation also happens in arch/<foo>/mm
and this is per arch by definition as well
2) you missed that the mmap randomization is *ON TOP OF*
the stack randomization. So while you say "1Mb" in your
doc in practice it is 8Mb
Also your patch is still full of XXX's and "other noise"...
Also you probably should explain what the advantage is over the existing
per architecture approach. Just stating "it's per architecture" (as you
suggest) doesn't cut it since it is per architecture already for the
most part.
If all you want to do is turn
- if (current->flags & PF_RANDOMIZE)
- random_variable = get_random_int() % (8*1024*1024);
that 8 into a per architecture thing.. then your patch is awefully big
and complex to just achieve that.
^ permalink raw reply
* Re: [patch, -rc5-mm3] lock validator: fix ns83820.c irq-flags bug
From: Ingo Molnar @ 2006-06-04 8:58 UTC (permalink / raw)
To: Keith Owens
Cc: Andrew Morton, linux-kernel, Barry K. Nathan, Arjan van de Ven
In-Reply-To: <16537.1149411027@ocs3.ocs.com.au>
* Keith Owens <kaos@ocs.com.au> wrote:
> Ingo Molnar (on Sun, 4 Jun 2006 10:30:17 +0200) wrote:
> >2) allowing the nesting of hardware interrupts only 'spreads out'
> >the handling of the current ISR, causing extra cachemisses that would
> >otherwise not happen. Furthermore, on architectures where ISRs share
> >the kernel stacks, enabling interrupts in ISRs introduces a much
> >higher kernel-stack-nesting and thus kernel-stack-overflow risk.
>
> It is worse than you think. A third party network driver enabled
> interrupts in its irq handler. For reasons that are still not clear,
> that allowed recursive interrupts from the same device. Unexpected I
> know, because the card's ISR should still have been masked, but the
> stack trace said otherwise. When multiple packets arrived for the
> same driver it drove multiple levels of kernel functions to handle
> them and completely blew the kernel stack, even though it was using a
> separate IRQ stack.
ouch!
They seem to be quite rare in practice (Barry's was the only one so
far), but when they happen they can be very nasty. So the lock validator
creates some gentle pressure to get these fixed ;-) For the really
really rare cases where the irq enabling is justified (mostly old, very
slow hardware) it can be easily annotated for lockdep.
Ingo
^ permalink raw reply
* [ANNOUNCE qgit-1.3]
From: Marco Costalba @ 2006-06-04 8:55 UTC (permalink / raw)
To: git, linux-kernel
This is qgit-1.3
With qgit you will be able to browse revisions history, view patch content
and changed files, graphically following different development branches.
FEATURES
- View revisions, diffs, files history, files annotation, archive tree.
- Commit changes visually cherry picking modified files.
- Apply or format patch series from selected commits, drag and
drop commits between two instances of qgit.
- qgit implements a GUI for the most common StGIT commands like push/pop
and apply/format patches. You can also create new patches or refresh
current top one using the same semantics of git commit, i.e. cherry
picking single modified files.
NEW IN THIS RELEASE
Main focus of this release is usability.
The big feature is the use of tabs instead of independent windows.
This change alone could be enough for a release. It's a big rewrite of UI
code to let browsing revisions and patches quicker and easier.
An whole set of key and mouse bindings has been introduced to support tab
navigation, see handbook (F1) for details.
Also changes in annotation/file viewer and StGIT integration.
Please note that you will need git 1.3.0 or newer.
DOWNLOAD
Tarball is
http://prdownloads.sourceforge.net/qgit/qgit-1.3.tar.bz2?download
Git archive is
git://git.kernel.org/pub/scm/qgit/qgit.git
See http://digilander.libero.it/mcostalba/ for detailed download information.
INSTALLATION
git 1.3.0 is required.
To install from tarball:
./configure
make
make install
To install from git archive:
autoreconf -i
./configure
make
make install
Or check the shipped README for detailed information.
CHANGELOG
from 1.3rc1 to 1.3
- added another powerful key binding to switch pages: <Alt+wheel>
- add refresh button to main toolbar
- disable back and forward buttons when not in a git archive
- patch viewer should not parse HTML
- strip debug info when installing qgit
- move 'Settings...' at the end of Edit menu
- fix code range filtering in case of multi indipendent branches
- actually support embedded Qt, make configuration code more robust
(Pavel Roskin)
- always select at first revision after opening a repository
from 1.2 to 1.3rc1
- convert UI to use tabs instead of independent windows
- use key bindings to quickly change view
- use 's' key to quickly hide/unhide secondary panes in current view
- use a standard 'find text' (CTRL+F) dialog across views
- add support for filter a given substring or regexp through patches content
- highlight matched filter patterns in diff viewer
- add up/down one revision key binding
- double clicking on file list now shows the patch
- improve file content loading time
- add support for hide/unhide annotation in file viewer
- fix 'format patch series' broken in multi revision case
- fix search for StGIT patches only under current stg branch directory
- fix don't be confused by out-of-date parent IDs of unapplied patches
(Pavel Roskin)
- fix show ref names in pop-up menu also for applied StGIT patches
- fix unable to push and pop patches if "check working dir" is enabled
- add support for finding Qt on SuSE-9.2 for x86_64 (Pavel Roskin)
For a complete changelog see shipped ChangeLog file or git repository
revision's history
Marco
^ permalink raw reply
* Re: [patch, -rc5-mm3] lock validator: fix ns83820.c irq-flags bug
From: Keith Owens @ 2006-06-04 8:50 UTC (permalink / raw)
To: Ingo Molnar
Cc: Andrew Morton, linux-kernel, Barry K. Nathan, Arjan van de Ven
In-Reply-To: <20060604083017.GA8241@elte.hu>
Ingo Molnar (on Sun, 4 Jun 2006 10:30:17 +0200) wrote:
>2) allowing the nesting of hardware interrupts only 'spreads out'
>the handling of the current ISR, causing extra cachemisses that would
>otherwise not happen. Furthermore, on architectures where ISRs share
>the kernel stacks, enabling interrupts in ISRs introduces a much
>higher kernel-stack-nesting and thus kernel-stack-overflow risk.
It is worse than you think. A third party network driver enabled
interrupts in its irq handler. For reasons that are still not clear,
that allowed recursive interrupts from the same device. Unexpected I
know, because the card's ISR should still have been masked, but the
stack trace said otherwise. When multiple packets arrived for the same
driver it drove multiple levels of kernel functions to handle them and
completely blew the kernel stack, even though it was using a separate
IRQ stack.
^ permalink raw reply
* [SCSI] 3w-9xxx: kmap_atomic in twa_scsiop_execute_scsi
From: Vasily Averin @ 2006-06-04 8:49 UTC (permalink / raw)
To: adam radford, Adam Radford
Cc: James Bottomley, Linux Kernel Mailing List, linux-scsi, devel,
Andrew Morton
[-- Attachment #1: Type: text/plain, Size: 349 bytes --]
Hello Adam,
you have fixed recently potential memory corruption, kmap_atomic issue in
3w-9xxx driver, however it seems for me you have forgotten to fix the same issue
in yet another similar place, in twa_scsiop_execute_scsi() function.
Signed-off-by: Vasily Averin <vvs@sw.ru>
Thank you,
Vasily Averin
SWsoft Virtuozzo/OpenVZ Linux kernel team
[-- Attachment #2: diff-scsi-3w9xxx-kmap-20060604 --]
[-- Type: text/plain, Size: 1070 bytes --]
--- a/drivers/scsi/3w-9xxx.c 2006-06-04 11:15:52.000000000 +0400
+++ b/drivers/scsi/3w-9xxx.c 2006-06-04 11:18:34.000000000 +0400
@@ -1864,9 +1864,13 @@ static int twa_scsiop_execute_scsi(TW_De
if ((tw_dev->srb[request_id]->use_sg == 1) && (tw_dev->srb[request_id]->request_bufflen < TW_MIN_SGL_LENGTH)) {
if (tw_dev->srb[request_id]->sc_data_direction == DMA_TO_DEVICE || tw_dev->srb[request_id]->sc_data_direction == DMA_BIDIRECTIONAL) {
struct scatterlist *sg = (struct scatterlist *)tw_dev->srb[request_id]->request_buffer;
- char *buf = kmap_atomic(sg->page, KM_IRQ0) + sg->offset;
+ unsigned long flags = 0;
+ char *buf;
+ local_irq_save(flags);
+ buf = kmap_atomic(sg->page, KM_IRQ0) + sg->offset;
memcpy(tw_dev->generic_buffer_virt[request_id], buf, sg->length);
kunmap_atomic(buf - sg->offset, KM_IRQ0);
+ local_irq_restore(flags);
}
command_packet->sg_list[0].address = TW_CPU_TO_SGL(tw_dev->generic_buffer_phys[request_id]);
command_packet->sg_list[0].length = cpu_to_le32(TW_MIN_SGL_LENGTH);
^ permalink raw reply
* [minor fix] radixtree: regulate tag get return value
From: Wu Fengguang @ 2006-06-04 8:45 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, nickpiggin
Andrew, this small patch makes the radixtree tester program from
http://www.zip.com.au/~akpm/linux/patches/stuff/rtth.tar.gz
run OK, with the latest radix tree code in linux-2.6.17-rc5-mm2.
It regulates the return value to 0/1 for functions
radix_tree_tag_get() and radix_tree_tagged().
Signed-off-by: Wu Fengguang <wfg@mail.ustc.edu.cn>
---
--- linux.orig/lib/radix-tree.c
+++ linux/lib/radix-tree.c
@@ -156,7 +156,7 @@ static inline void tag_clear(struct radi
static inline int tag_get(struct radix_tree_node *node, unsigned int tag,
int offset)
{
- return test_bit(offset, node->tags[tag]);
+ return !! test_bit(offset, node->tags[tag]);
}
static inline void root_tag_set(struct radix_tree_root *root, unsigned int tag)
@@ -177,7 +177,7 @@ static inline void root_tag_clear_all(st
static inline int root_tag_get(struct radix_tree_root *root, unsigned int tag)
{
- return root->gfp_mask & (1 << (tag + __GFP_BITS_SHIFT));
+ return !! (root->gfp_mask & (1 << (tag + __GFP_BITS_SHIFT)));
}
/*
^ permalink raw reply
* Changing careers but lack the right Degree? fz1crh
From: Shannon Boucher @ 2006-06-04 8:40 UTC (permalink / raw)
To: autoanswer
In-Reply-To: <d8e701c68705$9268bbf9$74ee450c@kvv94a3>
A Genuine University Degree in 4-6 weeks!
Have you ever thought that the only thing stopping you from a great job and better pay was a few letters behind you name?
Well now you can get them!
BA BSc MA MSc MBA PhD
Within 4-6 weeks!
Call US now and leave message.We will call you back soon.
1-520-844-1041
No Study Required!
100% Verifiable!
These are real, genuine degrees that include Bachelors, Masters, MBA and Doctorate Degrees. They are fully verifiable and certified transcripts are also available.
Just call the number below.
You'll thank me later...
Call US now and leave message.We will call you back soon.
1-520-844-1041
24 hours a day, 7 days a week including Sundays and Holidays
^ permalink raw reply
* Re: [PATCH-rt] ARM: Fix dump_stack() config dependencies
From: Ingo Molnar @ 2006-06-04 8:43 UTC (permalink / raw)
To: Deepak Saxena; +Cc: Thomas Gleixner, dwalker, James Perkins, linux-kernel
In-Reply-To: <20060601233925.GA23811@plexity.net>
* Deepak Saxena <dsaxena@plexity.net> wrote:
> DEBUG_ERRORS does not depend on DEBUG_MUTEXES and the kernel will not
> build if the former is enabled and the later disables. Other option is
> to make DEBUG_ERRORS automatically enabled DEBUG_MUTEXES in the RT
> case.
>
> Signed-off-by: Deepak Saxena <dsaxena@plexity.net>
thanks, applied.
Ingo
^ permalink raw reply
* Re: [PATCH-rt]: Add missing headers to clocksource.h
From: Ingo Molnar @ 2006-06-04 8:42 UTC (permalink / raw)
To: Deepak Saxena; +Cc: Thomas Gleixner, dwalker, James Perkins, linux-kernel
In-Reply-To: <20060601231010.GA21704@plexity.net>
* Deepak Saxena <dsaxena@plexity.net> wrote:
> rt26 won't compile w/o this if GENERIC_TIME is set.
thanks, applied.
Ingo
^ permalink raw reply
* [Qemu-devel] yet another proposed solution for gcc 4.x
From: Carlo Marcelo Arenas Belon @ 2006-06-04 8:59 UTC (permalink / raw)
To: qemu-devel
[-- Attachment #1: Type: text/plain, Size: 1246 bytes --]
Greetings,
attached patch, adds a ./configure option for setting the C compiler that will
be used to build op.c for each of the targets; letting the user compile
everything else with gcc 4.x if configured as the default C compiler while
isolating the opcode generation which currently relies in gcc 3.x for dyngen
to be able to make sense of it.
tested it in a gentoo 2006.0 system (amd64) using gcc-4.1.1 to compile
qemu-0.8.1 and the CVS HEAD, by instructing qemu to use gcc-3.4.5 for op.c,
configuring it with :
./configure --op-cc=gcc-3.4.5 --disable-gcc-check
didn't modify the gcc-check function in ./configure to test $op_cc instead to
minimize the changes proposed, and because I wasn't sure that doing so was
beneficial to the end user without a description of the options that can be
used to select a different compiler for different parts of the code.
FYI gcc-4.1.1 is not able to compile qemu-0.8.1 or the CVS HEAD because it
confuses dyngen and makes it generate invalid code as can be seen in gentoo's
bug 132667.
https://bugs.gentoo.org/show_bug.cgi?id=132667
and which includes a hacky fix (by using a helper function), but i consider
wasn't worth fixing as the resulting binary won't work at all (as expected).
Carlo
[-- Attachment #2: qemu-opcc.patch --]
[-- Type: text/plain, Size: 2524 bytes --]
Index: Makefile.target
===================================================================
RCS file: /sources/qemu/qemu/Makefile.target,v
retrieving revision 1.113
diff -u -p -r1.113 Makefile.target
--- Makefile.target 30 May 2006 01:48:12 -0000 1.113
+++ Makefile.target 4 Jun 2006 07:53:52 -0000
@@ -445,7 +445,7 @@ gen-op.h: op.o $(DYNGEN)
$(DYNGEN) -g -o $@ $<
op.o: op.c
- $(CC) $(OP_CFLAGS) $(DEFINES) -c -o $@ $<
+ $(OP_CC) $(OP_CFLAGS) $(DEFINES) -c -o $@ $<
helper.o: helper.c
$(CC) $(HELPER_CFLAGS) $(DEFINES) -c -o $@ $<
Index: configure
===================================================================
RCS file: /sources/qemu/qemu/configure,v
retrieving revision 1.102
diff -u -p -r1.102 configure
--- configure 14 May 2006 11:30:38 -0000 1.102
+++ configure 4 Jun 2006 07:53:53 -0000
@@ -23,6 +23,7 @@ static="no"
cross_prefix=""
cc="gcc"
host_cc="gcc"
+op_cc="gcc"
ar="ar"
make="make"
install="install"
@@ -182,6 +183,8 @@ for opt do
;;
--host-cc=*) host_cc="$optarg"
;;
+ --op-cc=*) op_cc="$optarg"
+ ;;
--make=*) make="$optarg"
;;
--install=*) install="$optarg"
@@ -271,6 +274,7 @@ echo " --source-path=PATH path of
echo " --cross-prefix=PREFIX use PREFIX for compile tools [$cross_prefix]"
echo " --cc=CC use C compiler CC [$cc]"
echo " --host-cc=CC use C compiler CC [$host_cc] for dyngen etc."
+echo " --op-cc=CC use C compiler CC [$op_cc] for op.c"
echo " --make=MAKE use specified make [$make]"
echo " --install=INSTALL use specified install [$install]"
echo " --static enable static build [$static]"
@@ -417,7 +421,7 @@ int main(void) {
EOF
have_gcc3_options="no"
-if $cc -fno-reorder-blocks -fno-optimize-sibling-calls -o $TMPO $TMPC 2> /dev/null ; then
+if $op_cc -fno-reorder-blocks -fno-optimize-sibling-calls -o $TMPO $TMPC 2> /dev/null ; then
have_gcc3_options="yes"
fi
@@ -522,6 +526,7 @@ fi
echo "Source path $source_path"
echo "C compiler $cc"
echo "Host C compiler $host_cc"
+echo "OP C compiler $op_cc"
echo "make $make"
echo "install $install"
echo "host CPU $cpu"
@@ -588,6 +593,7 @@ if test "$have_gcc3_options" = "yes" ; t
echo "HAVE_GCC3_OPTIONS=yes" >> $config_mak
fi
echo "HOST_CC=$host_cc" >> $config_mak
+echo "OP_CC=$op_cc" >> $config_mak
echo "AR=$ar" >> $config_mak
echo "STRIP=$strip -s -R .comment -R .note" >> $config_mak
echo "CFLAGS=$CFLAGS" >> $config_mak
^ permalink raw reply
* Changing careers but lack the right Degree? fz1crh
From: Shannon Boucher @ 2006-06-04 8:40 UTC (permalink / raw)
To: autoanswer
In-Reply-To: <d8e701c68705$9268bbf9$74ee450c@kvv94a3>
A Genuine University Degree in 4-6 weeks!
Have you ever thought that the only thing stopping you from a great job and better pay was a few letters behind you name?
Well now you can get them!
BA BSc MA MSc MBA PhD
Within 4-6 weeks!
Call US now and leave message.We will call you back soon.
1-520-844-1041
No Study Required!
100% Verifiable!
These are real, genuine degrees that include Bachelors, Masters, MBA and Doctorate Degrees. They are fully verifiable and certified transcripts are also available.
Just call the number below.
You'll thank me later...
Call US now and leave message.We will call you back soon.
1-520-844-1041
24 hours a day, 7 days a week including Sundays and Holidays
^ permalink raw reply
* Re: 2.6.17-rc5-mm2
From: Ingo Molnar @ 2006-06-04 8:33 UTC (permalink / raw)
To: Barry K. Nathan; +Cc: Andrew Morton, linux-kernel, Arjan van de Ven
In-Reply-To: <986ed62e0606031929g41ad18fbrb1788c26da86287f@mail.gmail.com>
* Barry K. Nathan <barryn@pobox.com> wrote:
> Yes, the latest combo patch works. It still gives the warning, too
> (copied here since it looks slightly different with the latency trace
> patch added):
> I've posted the /proc/latency_trace here:
> http://members.cox.net/barrykn/linux/trace/latency_trace.bz2
ok, thanks - this pinpointed the problem. I have just sent the fix for
that (against -mm3), does your networking card still work with that
patch applied, and if yes, is the lock validator silent on your box now?
Btw., the easiest way to find out whether there's a lockdep problem on
your box is to grep for debug_locks in /proc/lockdep_stats - it should
still be on 1. If there's a warning, it goes to 0. That is an easy to
script flag.
> It turns out that I was *way* off on the size in my last mail. It's
> actually close to 9MB decompressed, 370K bz2-compressed.
heh ;) Yeah. But it does tell us everything (and much more) about the
immediate history of any particular bug.
Ingo
^ permalink raw reply
* [patch, -rc5-mm3] lock validator: fix ns83820.c irq-flags bug
From: Ingo Molnar @ 2006-06-04 8:30 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Barry K. Nathan, Arjan van de Ven
Subject: lock validator: fix ns83820.c irq-flags bug
From: Ingo Molnar <mingo@elte.hu>
Barry K. Nathan reported the following lockdep warning:
[ 197.343948] BUG: warning at kernel/lockdep.c:1856/trace_hardirqs_on()
[ 197.345928] [<c010329b>] show_trace_log_lvl+0x5b/0x105
[ 197.346359] [<c0103896>] show_trace+0x1b/0x20
[ 197.346759] [<c01038ed>] dump_stack+0x1f/0x24
[ 197.347159] [<c012efa2>] trace_hardirqs_on+0xfb/0x185
[ 197.348873] [<c029b009>] _spin_unlock_irq+0x24/0x2d
[ 197.350620] [<e09034e8>] do_tx_done+0x171/0x179 [ns83820]
[ 197.350895] [<e090445c>] ns83820_irq+0x149/0x20b [ns83820]
[ 197.351166] [<c013b4b8>] handle_IRQ_event+0x1d/0x52
[ 197.353216] [<c013c6c2>] handle_level_irq+0x97/0xe1
[ 197.355157] [<c01048c3>] do_IRQ+0x8b/0xac
[ 197.355612] [<c0102d9d>] common_interrupt+0x25/0x2c
this is caused because the ns83820 driver re-enables irq flags
in hardirq context.
While legal in theory, in practice it should only be done if the
hardware is really old and has some very high overhead in its ISR.
(such as PIO IDE)
For modern hardware, running ISRs with irqs enabled is discouraged,
because 1) new hardware is fast enough to not cause latency problems
2) allowing the nesting of hardware interrupts only 'spreads out'
the handling of the current ISR, causing extra cachemisses that would
otherwise not happen. Furthermore, on architectures where ISRs share
the kernel stacks, enabling interrupts in ISRs introduces a much
higher kernel-stack-nesting and thus kernel-stack-overflow risk.
3) not managing irq-flags via the _irqsave / _irqrestore variants
is dangerous: it's easy to forget whether one function nests inside
another, and irq flags might be mismanaged.
In the few cases where re-enabling interrupts in an ISR is considered
useful (and unavoidable), it has to be taught to the lock validator
explicitly (because the lock validator needs the "no ISR ever enables
hardirqs" artificial simplification to keep the IRQ/softirq locking
dependencies manageable).
This teaching is done via the explicit use local_irq_enable_in_hardirq().
On a stock kernel this maps to local_irq_enable(). If the lock validator
is enabled then this does not enable interrupts.
Now, the analysis of drivers/net/ns83820.c's irq flags use: the
irq-enabling in irq context seems intentional, but i dont think it's
justified. Furthermore, the driver suffers from problem #3 above too,
in ns83820_tx_timeout() it disables irqs via local_irq_save(), but
then it calls do_tx_done() which does a spin_unlock_irq(),
re-enabling for a function that does not expect it! While currently
this bug seems harmless (only some debug printout seems to be
affected by it), it's nevertheless something to be fixed.
So this patch makes the ns83820 ISR irq-flags-safe, and cleans up
do_tx_done() use and locking to avoid the ns83820_tx_timeout() bug.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
drivers/net/ns83820.c | 23 ++++++++++++-----------
1 file changed, 12 insertions(+), 11 deletions(-)
Index: v/drivers/net/ns83820.c
===================================================================
--- v.orig/drivers/net/ns83820.c
+++ v/drivers/net/ns83820.c
@@ -1013,8 +1013,6 @@ static void do_tx_done(struct net_device
struct ns83820 *dev = PRIV(ndev);
u32 cmdsts, tx_done_idx, *desc;
- spin_lock_irq(&dev->tx_lock);
-
dprintk("do_tx_done(%p)\n", ndev);
tx_done_idx = dev->tx_done_idx;
desc = dev->tx_descs + (tx_done_idx * DESC_SIZE);
@@ -1070,7 +1068,6 @@ static void do_tx_done(struct net_device
netif_start_queue(ndev);
netif_wake_queue(ndev);
}
- spin_unlock_irq(&dev->tx_lock);
}
static void ns83820_cleanup_tx(struct ns83820 *dev)
@@ -1308,6 +1305,8 @@ static irqreturn_t ns83820_irq(int foo,
static void ns83820_do_isr(struct net_device *ndev, u32 isr)
{
struct ns83820 *dev = PRIV(ndev);
+ unsigned long flags;
+
#ifdef DEBUG
if (isr & ~(ISR_PHY | ISR_RXDESC | ISR_RXEARLY | ISR_RXOK | ISR_RXERR | ISR_TXIDLE | ISR_TXOK | ISR_TXDESC))
Dprintk("odd isr? 0x%08x\n", isr);
@@ -1322,10 +1321,10 @@ static void ns83820_do_isr(struct net_de
if ((ISR_RXDESC | ISR_RXOK) & isr) {
prefetch(dev->rx_info.next_rx_desc);
- spin_lock_irq(&dev->misc_lock);
+ spin_lock_irqsave(&dev->misc_lock, flags);
dev->IMR_cache &= ~(ISR_RXDESC | ISR_RXOK);
writel(dev->IMR_cache, dev->base + IMR);
- spin_unlock_irq(&dev->misc_lock);
+ spin_unlock_irqrestore(&dev->misc_lock, flags);
tasklet_schedule(&dev->rx_tasklet);
//rx_irq(ndev);
@@ -1371,16 +1370,18 @@ static void ns83820_do_isr(struct net_de
* work has accumulated
*/
if ((ISR_TXDESC | ISR_TXIDLE | ISR_TXOK | ISR_TXERR) & isr) {
+ spin_lock_irqsave(&dev->tx_lock, flags);
do_tx_done(ndev);
+ spin_unlock_irqrestore(&dev->tx_lock, flags);
/* Disable TxOk if there are no outstanding tx packets.
*/
if ((dev->tx_done_idx == dev->tx_free_idx) &&
(dev->IMR_cache & ISR_TXOK)) {
- spin_lock_irq(&dev->misc_lock);
+ spin_lock_irqsave(&dev->misc_lock, flags);
dev->IMR_cache &= ~ISR_TXOK;
writel(dev->IMR_cache, dev->base + IMR);
- spin_unlock_irq(&dev->misc_lock);
+ spin_unlock_irqrestore(&dev->misc_lock, flags);
}
}
@@ -1391,10 +1392,10 @@ static void ns83820_do_isr(struct net_de
* nature are expected, we must enable TxOk.
*/
if ((ISR_TXIDLE & isr) && (dev->tx_done_idx != dev->tx_free_idx)) {
- spin_lock_irq(&dev->misc_lock);
+ spin_lock_irqsave(&dev->misc_lock, flags);
dev->IMR_cache |= ISR_TXOK;
writel(dev->IMR_cache, dev->base + IMR);
- spin_unlock_irq(&dev->misc_lock);
+ spin_unlock_irqrestore(&dev->misc_lock, flags);
}
/* MIB interrupt: one of the statistics counters is about to overflow */
@@ -1456,7 +1457,7 @@ static void ns83820_tx_timeout(struct ne
u32 tx_done_idx, *desc;
unsigned long flags;
- local_irq_save(flags);
+ spin_lock_irqsave(&dev->tx_lock, flags);
tx_done_idx = dev->tx_done_idx;
desc = dev->tx_descs + (tx_done_idx * DESC_SIZE);
@@ -1483,7 +1484,7 @@ static void ns83820_tx_timeout(struct ne
ndev->name,
tx_done_idx, dev->tx_free_idx, le32_to_cpu(desc[DESC_CMDSTS]));
- local_irq_restore(flags);
+ spin_unlock_irqrestore(&dev->tx_lock, flags);
}
static void ns83820_tx_watch(unsigned long data)
^ permalink raw reply
* Re: [PATCH 4/5] SCSI: add cpu cache flushes after kmapping and modifying a page
From: Christoph Hellwig @ 2006-06-04 8:20 UTC (permalink / raw)
To: Tejun Heo
Cc: Jens Axboe, James Bottomley, Dave Miller, bzolnier, james.steward,
jgarzik, mattjreimer, Guennadi Liakhovetski, rmk, lkml, linux-ide,
linux-scsi
In-Reply-To: <11493924803460-git-send-email-htejun@gmail.com>
On Sun, Jun 04, 2006 at 12:41:20PM +0900, Tejun Heo wrote:
> local_irq_save(flags);
> buf = kmap_atomic(sg->page, KM_IRQ0) + sg->offset;
> memcpy(buf, tw_dev->generic_buffer_virt[request_id], sg->length);
> + flush_kernel_dcache_page(kmap_atomic_to_page(buf - sg->offset));
> kunmap_atomic(buf - sg->offset, KM_IRQ0);
> local_irq_restore(flags);
all these should switch to scsi_kmap_atomic_sg which should do the
flush_kernel_dcache_page call for you.
^ permalink raw reply
* Re: Re: Vertualization of Unmodified Operating Systems
From: Yinghai Lu @ 2006-06-04 8:19 UTC (permalink / raw)
To: Ronald G Minnich; +Cc: xen-devel, Dave Feustel
In-Reply-To: <4442A9B6.2030804@lanl.gov>
You can get Laptop from HP with turion X2. It will be amd64 with SVM
support and dual core.
YH
On 4/16/06, Ronald G Minnich <rminnich@lanl.gov> wrote:
> Is there a VT or pacifica laptop out there? Or is that technology just
> "assumed" for later CPUs? I'd like to get such a laptop.
>
> It seems to me that I could boot Plan 9 unmodified, and from there,
> develop the xenfront drivers I need, thus making test/debug much easier.
>
> thanks
>
> ron
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
^ permalink raw reply
* Re: [PATCH 2/5] ide: add cpu cache flushes after kmapping and modifying a page
From: Christoph Hellwig @ 2006-06-04 8:17 UTC (permalink / raw)
To: Tejun Heo
Cc: Jens Axboe, James Bottomley, Dave Miller, bzolnier, james.steward,
jgarzik, mattjreimer, Guennadi Liakhovetski, rmk, lkml, linux-ide,
linux-scsi
In-Reply-To: <1149392480987-git-send-email-htejun@gmail.com>
On Sun, Jun 04, 2006 at 12:41:20PM +0900, Tejun Heo wrote:
> data = bvec_kmap_irq(bvec, &flags);
> drive->hwif->atapi_input_bytes(drive, data, count);
> + flush_kernel_dcache_page(kmap_atomic_to_page(data));
> bvec_kunmap_irq(data, &flags);
shouldn't bvec_kunmap_irq do the flush_kernel_dcache_page call?
^ permalink raw reply
* Re: irq 17: nobody cared (try booting with the "irqpoll" option)
From: Keir Fraser @ 2006-06-04 8:03 UTC (permalink / raw)
To: Hans-Christian Armingeon; +Cc: xen-devel, xen-users
In-Reply-To: <200606031451.52939.mog.johnny@gmx.net>
On 3 Jun 2006, at 13:51, Hans-Christian Armingeon wrote:
> [ 1199.028108] irq 17: nobody cared (try booting with the "irqpoll"
> option)
> [ 1199.031054]
> [ 1199.031055] Call Trace: <IRQ>
> <ffffffff8014d754>{__report_bad_irq+48}
> [ 1199.034294] <ffffffff8014d9bc>{note_interrupt+539}
> <ffffffff8014d2ab>{__do_IRQ+190}
> [ 1199.040504] <ffffffff8010c934>{do_IRQ+62}
> <ffffffff802d0034>{evtchn_do_upcall+132}
> [ 1199.046403] <ffffffff8010b152>{do_hypervisor_callback+30}
> <EOI>
> [ 1199.052363] handlers:
> [ 1199.055141] [<ffffffff880354ab>] (ata_interrupt+0x0/0x166 [libata])
> [ 1199.058267] Disabling IRQ #17
>
> So I rebooted with irqpoll option.
>
> Is this a bug, or what's the cause of this error message?
It's caused by receiving lots of spurious interrupts on that IRQ. If
you don't see similar on native then post boot output from Xen and
native Linux and we can look for differences.
-- Keir
^ permalink raw reply
* Re: [RFC PATCH 1/2] Hardware button support for Wireless cards: radiobtn
From: Ivo van Doorn @ 2006-06-04 8:02 UTC (permalink / raw)
To: Stefan Rompf; +Cc: Francois Romieu, netdev, rt2400-devel
In-Reply-To: <200606031045.08763.stefan@loplof.de>
[-- Attachment #1: Type: text/plain, Size: 1063 bytes --]
On Saturday 3 June 2006 10:45, Stefan Rompf wrote:
> Am Freitag 02 Juni 2006 16:30 schrieb Ivo van Doorn:
>
> > > Or actually, I don't think the radiobtn/ won't be actually needed as
> > > prefix. The name passed to the radiobtn driver by the driver should be
> > > sufficient.
> >
> > Updated version,
> >
> > Signed-off-by Ivo van Doorn <IvDoorn@gmail.com>
>
> I don't like the patch in it's current form. Many notebooks have a number of
> additional keys that need to be queried/polled using the same interface, but
> just one button is to control the radio, the rest are multimedia keys that
> just need to be forwarded to userspace. Or maybe a bluetooth key.
Except for the bluetooth radio key (which should be supported by the radiobtn interface as well)
the other buttons have support through already excisting input devices if I am correct.
This radiobtn driver is there to poll the device frequently about the radio state only
since that is one of the few buttons that is not sending anything to userspace at the moment.
Ivo
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* RE: How stop DoS and SYN attack..
From: Sietse van Zanen @ 2006-06-04 7:57 UTC (permalink / raw)
To: Alberto Ferrer, netfilter
There's not really very much you can do about DDOS attacks with netfilter alone. You can block the traffic ofcourse, or try to fiddle with --limit, or tcp_syn_cookies.
But usually the problem is that the amount of traffic just fills your entire Internet connecection, which renders it useless. The only thing you can do in such a situation is ask yout ISP to block the attack upstream.
And often, ISPs are very unhappy about customers being DDOS-ed.
-Sietse
-----Original Message-----
From: netfilter-bounces@lists.netfilter.org [mailto:netfilter-bounces@lists.netfilter.org] On Behalf Of Alberto Ferrer
Sent: Saturday, June 03, 2006 10:33 PM
To: netfilter@lists.netfilter.org
Subject: How stop DoS and SYN attack..
¿any know a way to stop via Linux with iptables or related a SYN attack ?
¿where i can read something related to this?
Thanks in advance.
P.S: sorry for my bad english :D
--
Alberto Ferrer
^ permalink raw reply
* Re: 2.6.17-rc5-mm2
From: Ingo Molnar @ 2006-06-04 7:57 UTC (permalink / raw)
To: Barry K. Nathan; +Cc: Andrew Morton, linux-kernel, Arjan van de Ven
In-Reply-To: <986ed62e0606031410h48efd8b7i3a89e1c7ba1cd778@mail.gmail.com>
* Barry K. Nathan <barryn@pobox.com> wrote:
> BTW, the latency_trace is close to 130K. Should I send it to you by
> private mail instead of to the list? Or should I compress it and send
> it as an attachment?
bzip -9 has a better than 1:20 compression ratio on latency traces, so
the 130K should go down to ~6K - perfectly fine for attaching it. (that
way others on lkml can take a look too)
Ingo
^ permalink raw reply
* Re: [Qemu-devel] RTC fix/Sparc32
From: Joerg Platte @ 2006-06-04 7:45 UTC (permalink / raw)
To: qemu-devel; +Cc: paul
In-Reply-To: <BAY104-F209471C15CF975844AA754FF960@phx.gbl>
[-- Attachment #1: Type: text/plain, Size: 416 bytes --]
Am Samstag, 3. Juni 2006 22:02 schrieb Blue Swirl:
Hi!
> I installed Debian 3.1r1 from scratch using the system emulator, OpenBIOS,
> and CD image. Network is not working and some programs segfault, otherwise
> everything works well.
Did you apply the attached FPU patch I posted one week ago as well? With this
patch and your patches all programs I tested did not segfault any longer.
regards,
Jörg
[-- Attachment #2: qemu-sparc-fpu-pc.patch --]
[-- Type: text/x-diff, Size: 1101 bytes --]
--- translate.c 2005-11-22 00:33:12.000000000 +0100
+++ translate.c.new 2006-05-22 20:40:07.000000000 +0200
@@ -982,6 +982,7 @@
{
int cc = GET_FIELD_SP(insn, 20, 21);
#if !defined(CONFIG_USER_ONLY)
+ save_state(dc);
gen_op_trap_ifnofpu();
#endif
target = GET_FIELD_SP(insn, 0, 18);
@@ -1002,6 +1003,7 @@
case 0x6: /* FBN+x */
{
#if !defined(CONFIG_USER_ONLY)
+ save_state(dc);
gen_op_trap_ifnofpu();
#endif
target = GET_FIELD(insn, 10, 31);
@@ -1236,6 +1238,7 @@
#endif
} else if (xop == 0x34) { /* FPU Operations */
#if !defined(CONFIG_USER_ONLY)
+ save_state(dc);
gen_op_trap_ifnofpu();
#endif
rs1 = GET_FIELD(insn, 13, 17);
@@ -1424,6 +1427,7 @@
int cond;
#endif
#if !defined(CONFIG_USER_ONLY)
+ save_state(dc);
gen_op_trap_ifnofpu();
#endif
rs1 = GET_FIELD(insn, 13, 17);
@@ -2346,6 +2350,7 @@
#endif
} else if (xop >= 0x20 && xop < 0x24) {
#if !defined(CONFIG_USER_ONLY) || defined(TARGET_SPARC64)
+ save_state(dc);
gen_op_trap_ifnofpu();
#endif
switch (xop) {
^ permalink raw reply
* [PATCH] readahead: initial method - expected read size - fix fastcall
From: Fengguang Wu @ 2006-06-04 7:34 UTC (permalink / raw)
To: Andrew Morton; +Cc: Valdis.Kletnieks, diegocg, Voluspa, linux-kernel
Remove 'fastcall' directive for function readahead_close().
It has drawn concerns from Andrew Morton. Now I have some benchmarks
on it, and proved it as a _false_ optimization.
The tests are simple runs of the following command over _cached_ dirs:
time find / > /dev/null
Table of summary(averages):
user sys cpu total
fastcall: 1.236 4.39 89% 6.2936
non-fastcall: 1.18 4.14166667 92% 5.75416667
stock: 1.25833333 4.14666667 93.3% 5.75866667
-----------
Detailed outputs:
readahead patched kernel with fastcall:
noglob find / > /dev/null 1.21s user 4.58s system 90% cpu 6.378 total
noglob find / > /dev/null 1.25s user 4.47s system 86% cpu 6.623 total
noglob find / > /dev/null 1.23s user 4.36s system 90% cpu 6.173 total
noglob find / > /dev/null 1.25s user 4.33s system 92% cpu 6.067 total
noglob find / > /dev/null 1.24s user 4.21s system 87% cpu 6.227 total
readahead patched kernel without fastcall:
noglob find / > /dev/null 1.21s user 4.46s system 95% cpu 5.962 total
noglob find / > /dev/null 1.26s user 4.58s system 94% cpu 6.142 total
noglob find / > /dev/null 1.10s user 3.80s system 86% cpu 5.661 total
noglob find / > /dev/null 1.13s user 3.98s system 95% cpu 5.355 total
noglob find / > /dev/null 1.18s user 4.00s system 89% cpu 5.805 total
noglob find / > /dev/null 1.22s user 4.03s system 93% cpu 5.600 total
stock kernel:
noglob find / > /dev/null 1.22s user 4.24s system 94% cpu 5.803 total
noglob find / > /dev/null 1.31s user 4.21s system 95% cpu 5.784 total
noglob find / > /dev/null 1.27s user 4.24s system 97% cpu 5.676 total
noglob find / > /dev/null 1.34s user 4.21s system 94% cpu 5.844 total
noglob find / > /dev/null 1.26s user 4.08s system 89% cpu 5.935 total
noglob find / > /dev/null 1.15s user 3.90s system 91% cpu 5.510 total
-----------
Similar regression has also been found by Voluspa <lista1@comhem.se>:
> "cd /usr ; time find . -type f -exec md5sum {} \;"
>
> 2.6.17-rc5 ------- 2.6.17-rc5-ar
>
> real 21m21.009s -- 21m37.663s
> user 3m20.784s -- 3m20.701s
> sys 6m34.261s -- 6m41.735s
Signed-off-by: Wu Fengguang <wfg@mail.ustc.edu.cn>
---
--- linux-2.6.17-rc5-mm2.orig/include/linux/mm.h
+++ linux-2.6.17-rc5-mm2/include/linux/mm.h
@@ -1068,7 +1068,7 @@ unsigned long page_cache_readahead(struc
void handle_ra_miss(struct address_space *mapping,
struct file_ra_state *ra, pgoff_t offset);
unsigned long max_sane_readahead(unsigned long nr);
-void fastcall readahead_close(struct file *file);
+void readahead_close(struct file *file);
unsigned long
page_cache_readahead_adaptive(struct address_space *mapping,
struct file_ra_state *ra, struct file *filp,
--- linux-2.6.17-rc5-mm2.orig/mm/readahead.c
+++ linux-2.6.17-rc5-mm2/mm/readahead.c
@@ -1943,7 +1943,7 @@ void fastcall readahead_cache_hit(struct
* The resulted `ra_expect_bytes' answers the question of:
* How many pages are expected to be read on start-of-file?
*/
-void fastcall readahead_close(struct file *file)
+void readahead_close(struct file *file)
{
struct inode *inode = file->f_dentry->d_inode;
struct address_space *mapping = inode->i_mapping;
^ permalink raw reply
* [BUG] jfs: possible deadlocks
From: Evgeniy Dushistov @ 2006-06-04 7:16 UTC (permalink / raw)
To: jfs-discussion, Ingo Molnar; +Cc: linux-kernel
I try 2.6.17-rc5-mm2:
====================================
[ BUG: possible deadlock detected! ]
------------------------------------
mount/5587 is trying to acquire lock:
(&jfs_ip->commit_mutex){--..}, at: [<c02f7096>] mutex_lock+0x12/0x15
but task is already holding lock:
(&jfs_ip->commit_mutex){--..}, at: [<c02f7096>] mutex_lock+0x12/0x15
which could potentially lead to deadlocks!
other info that might help us debug this:
2 locks held by mount/5587:
#0: (&inode->i_mutex){--..}, at: [<c02f7096>] mutex_lock+0x12/0x15
#1: (&jfs_ip->commit_mutex){--..}, at: [<c02f7096>] mutex_lock+0x12/0x15
stack backtrace:
[<c0103095>] show_trace+0x16/0x19
[<c0103562>] dump_stack+0x1a/0x1f
[<c012ddd7>] __lockdep_acquire+0x6c6/0x907
[<c012e063>] lockdep_acquire+0x4b/0x63
[<c02f6f0c>] __mutex_lock_slowpath+0xa4/0x21c
[<c02f7096>] mutex_lock+0x12/0x15
[<c01b99be>] jfs_create+0x90/0x2b8
[<c0161016>] vfs_create+0x91/0xda
[<c0163939>] open_namei+0x15a/0x5b0
[<c015326c>] do_filp_open+0x22/0x39
[<c01541a8>] do_sys_open+0x40/0xbc
[<c015424d>] sys_open+0x13/0x15
[<c02f875d>] sysenter_past_esp+0x56/0x8d
--
/Evgeniy
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.