Re: [PATCH] Simplify some code to use the container_of() macro.
On Wed, 3 Jan 2007, Andrew Morton wrote:
> On Sun, 31 Dec 2006 15:55:22 -0500 (EST)
> "Robert P. J. Day" <[EMAIL PROTECTED]> wrote:
>
> > --- a/net/ipv4/netfilter/nf_nat_core.c
> > +++ b/net/ipv4/netfilter/nf_nat_core.c
> > @@ -168,7 +168,7 @@ find_appropriate_src(const struct nf_conntrack_tuple
> > *tuple,
> >
> > read_lock_bh(_nat_lock);
> > list_for_each_entry(nat, [h], info.bysource) {
> > - ct = (struct nf_conn *)((char *)nat - offsetof(struct nf_conn,
> > data));
> > + ct = container_of(nat, struct nf_conn, data);
>
> This one isn't right. Please always carefully compile-test these things.
i was quite sure i had. i'll take another look at it.
rday
-
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] MTD driver for MMC cards
Arnd Bergmann wrote: > > One promising effort for a replacement is Jörn's logfs > (http://wiki.laptop.org/go/Logfs), which should scale well to many > gigabytes. A driver based on MMC would be a nice development tool > for that, since it enables regular PCs as a debugging machine > instead of having to load test kernels onto an actual embedded > machine. > A bit of a niche area, but as long as this driver doesn't look like high maintenance then it could be enough. > Another thing I have been thinking about was an MTD version of > fat16/fat32. There are a number of optimizations that you can > do for flash media, including: > > - limiting the number of writes to the FAT > - erasing blocks when they are freed in the FS > - always writing full erase blocks if the erase block > size matches the cluster size > - optimize for wear leveling instead of avoiding > fragmentation > These sound like they would be nicer in the block layer, to cover other devices where you know there is flash at the bottom. > I read that the SD cards have some restrictions of how > the fat fs needs to be laid out on them, presumably to > make sure clusters are aligned with erase blocks. > Do you have any specific information on what SD actually > requires? > No, as we don't give a rats ass about them. I don't know why they stuck a FAT requirement into the spec. Perhaps Microsoft wanted a chance at the extortio^Wlicense money for any patent issues. > > ok, I'll have a look. I keep having trouble identifying the right > specifications (physical spec sounded like it was only about wiring > and electric properties, so I did not look at that). Maybe it would That had me fooled for quite a while as well. > be good if you could put pointers to the relevant documents into > your Wiki? Probably. I haven't really put that much time into the wiki lately. It turned out to be a one man show, so I'm doubting its usefulness. >> First of all, you cannot assume that read_blkbits is a valid block >> size when doing writes. > > Right, I see. I introduced that bug when I merged parts of the read and > write paths. > > Is it fair to assume that write_blkbits is always bigger than > read_blkbits, so that one can be used in both cases? > There is some relation, yes, but I don't remember the details right now. More important is that the card can only be set to one block size at any given time (both read and write). So unless you want terrible latency by switching block size back and forth I'd suggest selecting one size and sticking with it. As the newer cards only support a block size of 512 bytes, the most future proof would be to use that. > > I tried to do multiple block access at first, but then took it out again. > If it turns out valuable to have these, I'll implement it properly later. > Does it make a difference performance-wise to do larger accesses? > Yes. On my rather slow ISA device, the speedup was over 100% for writes. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - 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.6.19] mmc: Add support for SDHC cards (Take 2)
Philip Langdale wrote: > Pierre Ossman wrote: > >> Amen to that. All hw vendors that implement this particular form of >> brain damage should be dragged out and shot. >> >> I'll fix a patch for this later on. >> > > See my updated Take 3 patch. I've implemented a uniqueness fix by > adding additional RSP flags do make R6 and R7 unique. I don't know > if this is what you wanted, but it works without being too ugly. > > NAK. If two response types look the same over the wire, then they should have the same definition. Hardware that uses type codes is simply broken. There are a lot of sinners unfortunately... > However, also note my caveat that it's not clear if tifm or imxmmc > can ever be made to work with SD 2.0 cards. *sigh* > They probably can. They just need a fix for their switch statements. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - 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.6.20-rc2] [BUGFIX] drivers/atm/firestream.c: Fix infinite recursion when alignment passed is 0.
On 12/31/06, Mitchell Blank Jr <[EMAIL PROTECTED]> wrote: Looking at aligned_kmalloc() it seems to be pretty badly broken -- its fallback if it gets a non-aligned buffer is to just try a larger size which doesn't necessarily fix the problem. It looks like explicitly aligning the buffer is a better solution. Shouldn't we be using dma_alloc_*() here instead of abusing kmalloc()? - 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: VM: Fix nasty and subtle race in shared mmap'ed page writeback
Andrew Morton wrote: On Wed, 03 Jan 2007 22:56:07 -0800 (PST) David Miller <[EMAIL PROTECTED]> wrote: Anyway that leaves us with the question of why Andrea's database is getting corrupted. Hopefully he can give us a minimal test-case. It'd odd that stories of pre-2.6.19 BerkeleyDB corruption are now coming out of the woodwork. It's the first I've ever heard of them. Note that the original rtorrent debian bug report was against 2.6.18 I think that was 2.6.18+debian-added-dirty-page-tracking-patches. If that memory is correct, I'll assert (and emphasise) that the cause of the alleged BerkeleyDB corruption is not known at this time. I think that's right. Even if it were plain 2.6.18 that had rtorrent corruption, then it would be more evidence we still have an unidentified bug, because none of the patches fixed anything we have found to be buggy in 2.6.18. The post-2.6.19 "fix" might make it go away. But if it does, we do not know why, and it might still be there, only harder to hit. Likely. I think it is only hiding the bug (maybe the writeout patterns from shared dirty accounting are changing timings or codepaths). Of course, this means that we still can't confirm whether or not it is a kernel bug. It could be a BDB bug that's being hidden. -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com - 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 + gcc 4.1 = several problems
Linus Torvalds writes: [probably Mikael Pettersson] writes: The suggestions I've had so far which I have not yet tried: - Select a different x86 CPU in the config. - Unfortunately the C3-2 flags seem to simply tell GCC to schedule for ppro (like i686) and enabled MMX and SSE - Probably useless Actually, try this one. Try using something that doesn't like "cmov". Maybe the C3-2 simply has some internal cmov bugginess. Of course that changes register usage, register spilling, and thus ultimately even the stack layout. :-( Adjusting gcc flags to eliminate optimizations is another way to go. Adding -fwrapv would be an excellent start. Lack of this flag breaks most code which checks for integer wrap-around. The compiler "knows" that signed integers don't ever wrap, and thus eliminates any code which checks for values going negative after a wrap-around. I could imagine this affecting a switch() or other jump table. - 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: VM: Fix nasty and subtle race in shared mmap'ed page writeback
On Wed, 03 Jan 2007 22:56:07 -0800 (PST) David Miller <[EMAIL PROTECTED]> wrote: > From: Andrew Morton <[EMAIL PROTECTED]> > Date: Wed, 3 Jan 2007 22:12:20 -0800 > > > On Thu, 04 Jan 2007 17:03:43 +1100 > > Nick Piggin <[EMAIL PROTECTED]> wrote: > > > > > > That bug was introduced in 2.6.19, with the dirty page tracking patches. > > > > > > > > 2.6.18 and earlier used ->private_lock coverage in > > > > try_to_free_buffers() to > > > > prevent it. > > > > > > Ohh, right you are, I was looking at 2.6.19 sources. The comments above > > > ttfb match that as well. Curious that the dirty page patches were allowed > > > to mess with this... > > > > Frankly, those patches scared the crap out of me, specifically because of > > the delicacy and complexity of the various dirtiness state coherencies. > > But I just didn't have the bandwidth to go through them with a sufficiently > > fine toothcomb, sorry. > > > > > Anyway that leaves us with the question of why Andrea's database is > > > getting > > > corrupted. Hopefully he can give us a minimal test-case. > > > > It'd odd that stories of pre-2.6.19 BerkeleyDB corruption are now coming > > out of the woodwork. It's the first I've ever heard of them. > > Note that the original rtorrent debian bug report was against 2.6.18 I think that was 2.6.18+debian-added-dirty-page-tracking-patches. If that memory is correct, I'll assert (and emphasise) that the cause of the alleged BerkeleyDB corruption is not known at this time. The post-2.6.19 "fix" might make it go away. But if it does, we do not know why, and it might still be there, only harder to hit. - 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/
useless asm/page.h exported to userspace for some architectures
most architectures (pretty much everyone but like x86/x86_64/s390) export empty asm/page.h headers ... considering how useless these are, why bother exporting them at all ? clearly userspace is unable to rely on it across architectures, so by making it available to the two most common (x86/x86_64), applications crop up that build "fine" on them but fail just about everywhere else -mike - 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: VM: Fix nasty and subtle race in shared mmap'ed page writeback
From: Andrew Morton <[EMAIL PROTECTED]> Date: Wed, 3 Jan 2007 22:12:20 -0800 > On Thu, 04 Jan 2007 17:03:43 +1100 > Nick Piggin <[EMAIL PROTECTED]> wrote: > > > > That bug was introduced in 2.6.19, with the dirty page tracking patches. > > > > > > 2.6.18 and earlier used ->private_lock coverage in try_to_free_buffers() > > > to > > > prevent it. > > > > Ohh, right you are, I was looking at 2.6.19 sources. The comments above > > ttfb match that as well. Curious that the dirty page patches were allowed > > to mess with this... > > Frankly, those patches scared the crap out of me, specifically because of > the delicacy and complexity of the various dirtiness state coherencies. > But I just didn't have the bandwidth to go through them with a sufficiently > fine toothcomb, sorry. > > > Anyway that leaves us with the question of why Andrea's database is getting > > corrupted. Hopefully he can give us a minimal test-case. > > It'd odd that stories of pre-2.6.19 BerkeleyDB corruption are now coming > out of the woodwork. It's the first I've ever heard of them. Note that the original rtorrent debian bug report was against 2.6.18 - 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: [FSAIO][PATCH 6/8] Enable asynchronous wait page and lock page
Christoph Hellwig wrote: On Thu, Dec 28, 2006 at 08:17:17PM +0530, Suparna Bhattacharya wrote: I am really bad with names :( I tried using the _wq suffixes earlier and that seemed confusing to some, but if no one else objects I'm happy to use that. I thought aio_lock_page() might be misleading because it is synchronous if a regular wait queue entry is passed in, but again it may not be too bad. What's your preference ? Does anything more intuitive come to mind ? Beein bad about naming seems to be a disease, at least I suffer from it aswell. I wouldn't mind either the _wq or aio_ naming - _wq describes the way it's called and aio_ describes it's a special case for aio. Similarly to how ->aio_read/->aio_write can be used for synchronous I/O aswell. What about lock_page_async? A synchronous lock_page is the normal case, and for that guy it makes no sense to explicitly pass in a waitqueue, so it kind of falls into place? -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com - 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: [PATCHSET 1][PATCH 0/6] Filesystem AIO read/write
Suparna Bhattacharya wrote: On Thu, Jan 04, 2007 at 04:51:58PM +1100, Nick Piggin wrote: So long as AIO threads do the same, there would be no problem (plugging is optional, of course). Yup, the AIO threads run the same code as for regular IO, i.e in the rare situations where they actually end up submitting IO, so there should be no problem. And you have already added plug/unplug at the appropriate places in those path, so things should just work. Yes I think it should. This (is supposed to) give a number of improvements over the traditional plugging (although some downsides too). Most notably for me, the VM gets cleaner ;) However AIO could be an interesting case to test for explicit plugging because of the way they interact. What kind of improvements do you see with samba and do you have any benchmark setups? I think aio-stress would be a good way to test/benchmark this sort of stuff, at least for a start. Samba (if I understand this correctly based on my discussions with Tridge) is less likely to generate the kind of io patterns that could benefit from explicit plugging (because the file server has no way to tell what the next request is going to be, it ends up submitting each independently instead of batching iocbs). OK, but I think that after IO submission, you do not run sync_page to unplug the block device, like the normal IO path would (via lock_page, before the explicit plug patches). However, with explicit plugging, AIO requests will be started immediately. Maybe this won't be noticable if the device is always busy, but I would like to know there isn't a regression. In future there may be optimization possibilities to consider when submitting batches of iocbs, i.e. on the io submission path. Maybe AIO - O_DIRECT would be interesting to play with first in this regardi ? Well I've got some simple per-process batching in there now, each process has a list of pending requests. Request merging is done locklessly against the last request added; and submission at unplug time is batched under a single block device lock. I'm sure more merging or batching could be done, but also consider that most programs will not ever make use of any added complexity. Regarding your patches, I've just had a quick look and have a question -- what do you do about blocking in page reclaim and dirty balancing? Aren't those major points of blocking with buffered IO? Did your test cases dirty enough to start writeout or cause a lot of reclaim? (admittedly, blocking in reclaim will now be much less common since the dirty mapping accounting). -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com - 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.6.19] mmc: Add support for SDHC cards (Take 2)
Pierre Ossman wrote: > > Amen to that. All hw vendors that implement this particular form of > brain damage should be dragged out and shot. > > I'll fix a patch for this later on. See my updated Take 3 patch. I've implemented a uniqueness fix by adding additional RSP flags do make R6 and R7 unique. I don't know if this is what you wanted, but it works without being too ugly. However, also note my caveat that it's not clear if tifm or imxmmc can ever be made to work with SD 2.0 cards. *sigh* --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/
[PATCH 2.6.19] mmc: Add support for SDHC cards (Take 3)
Thanks to the generous donation of an SDHC card by John Gilmore, and the
surprisingly enlightened decision by the SD Card Association to publish
useful specs, I've been able to bash out support for SDHC. The changes
are not too profound:
i) Add a card flag indicating the card uses block level addressing and check
it in the block driver. As we never took advantage of byte-level addressing,
this simply involves skipping the block -> byte translation when sending
commands.
ii) The layout of the CSD is changed - a set of fields are discarded to make
space
for a larger C_SIZE. We did not reference any of the discarded fields except
those
related to the C_SIZE.
iii) Read and write timeouts are fixed values and not calculated from CSD
values.
iv) Before invoking SEND_APP_OP_COND, we must invoke the new SEND_IF_COND to
inform
the card we support SDHC.
I've done some basic read and write tests and everything seems to work fine but
one
should obviously use caution in case it eats your data.
Caveat:
Due to braindead hardware design, some drivers have to tell the host controller
what response code an issued command uses. This leads to two problems:
1) Before this change, R1 and R6 were actually identical except R6 was
incorrectly
defined and appeared different. Fixing this means the tifm_sd driver is unhappy
as
it can't distinguish them. I have fixed it by adding new flags that describe the
response a bit more so that R6 and R7 are unique and correct.
2) What happens if the hardware doesn't grok R7? Is there anything we can
do or have they managed to build hardware that will never work with SD 2.0
cards?
Right now, if you stick an SDHC card in, the tifm_sd driver will BUG() due to
the unknown response type while the imxmmc driver will probably fail to dispatch
the command correctly. All other supported controllers except SDHCI do some work
based on response type but appear to be able to cope with the new R7.
Signed-off-by: Philipl Langdale <[EMAIL PROTECTED]>
---
drivers/mmc/mmc.c| 138 ++-
drivers/mmc/mmc_block.c |8 ++
include/linux/mmc/card.h |3
include/linux/mmc/mmc.h | 23 ---
include/linux/mmc/protocol.h | 13 +++-
5 files changed, 149 insertions(+), 36 deletions(-)
--- /usr/src/linux/drivers/mmc/mmc.c2007-01-03 22:17:11.0 -0800
+++ linux-2.6.19-sdhc/drivers/mmc/mmc.c 2007-01-03 22:16:24.0 -0800
@@ -289,7 +289,10 @@
else
limit_us = 10;
- if (timeout_us > limit_us) {
+ /*
+* SDHC cards always use these fixed values.
+*/
+ if (timeout_us > limit_us || mmc_card_blockaddr(card)) {
data->timeout_ns = limit_us * 1000;
data->timeout_clks = 0;
}
@@ -588,34 +591,65 @@
if (mmc_card_sd(card)) {
csd_struct = UNSTUFF_BITS(resp, 126, 2);
- if (csd_struct != 0) {
+
+ switch (csd_struct) {
+ case 0:
+ m = UNSTUFF_BITS(resp, 115, 4);
+ e = UNSTUFF_BITS(resp, 112, 3);
+ csd->tacc_ns = (tacc_exp[e] * tacc_mant[m] + 9) /
10;
+ csd->tacc_clks = UNSTUFF_BITS(resp, 104, 8) * 100;
+
+ m = UNSTUFF_BITS(resp, 99, 4);
+ e = UNSTUFF_BITS(resp, 96, 3);
+ csd->max_dtr = tran_exp[e] * tran_mant[m];
+ csd->cmdclass = UNSTUFF_BITS(resp, 84, 12);
+
+ e = UNSTUFF_BITS(resp, 47, 3);
+ m = UNSTUFF_BITS(resp, 62, 12);
+ csd->capacity = (1 + m) << (e + 2);
+
+ csd->read_blkbits = UNSTUFF_BITS(resp, 80, 4);
+ csd->read_partial = UNSTUFF_BITS(resp, 79, 1);
+ csd->write_misalign = UNSTUFF_BITS(resp, 78, 1);
+ csd->read_misalign = UNSTUFF_BITS(resp, 77, 1);
+ csd->r2w_factor = UNSTUFF_BITS(resp, 26, 3);
+ csd->write_blkbits = UNSTUFF_BITS(resp, 22, 4);
+ csd->write_partial = UNSTUFF_BITS(resp, 21, 1);
+ break;
+ case 1:
+ /*
+* This is a block-addressed SDHC card. Most
+* interesting fields are unused and have fixed
+* values. To avoid getting tripped by buggy cards,
+* we assume those fixed values ourselves.
+*/
+ mmc_card_set_blockaddr(card);
+
+ csd->tacc_ns = 0; /* Unused */
+ csd->tacc_clks = 0; /* Unused */
+
+ m = UNSTUFF_BITS(resp, 99, 4);
+ e =
Re: [patch 2.6.19-git] rts-rs5c372 updates: more chips, alarm, 12hr mode, etc
On Wednesday 03 January 2007 2:51 pm, Voipio Riku wrote:
>
> > Yes, the patch you sent (switching to "method 3" to work around the
> > evident bug in the i2c-ixp3xx driver) works on the platform I was
> > using too (after unrelated tweaks).
>
> > Here's an updated patch, using "method 3". If it still behaves
> > for you, it'd seem ready to merge...
>
> Works fine, thanks! Unfortunately the i2c-ixp3xx issue has not advanced in
> the meantime, so we still need the third method.
Right. Thanks for confirming this! Alessandro?
Here's a version with corrected patch comments. (Against 2.6.20-rc3 now,
but I didn't change $SUBJECT).
- Dave
=== CUT HERE
Update the rtc-rs5c372 driver:
Bugfixes:
- Handle RTCs which are configured to use 12-hour mode.
- Never report bogus/un-initialized times.
- Displaying "raw trim" requires not masking it first!
- Fix the sysfs and procfs display of crystal and trim data.
Features:
- Handle other RTCs in this family, notably rv5c386/rv5c387.
- Declare the other registers.
- Provide alarm get/set functionality.
- Handle AIE and UIE; but no IRQ handling yet.
Cleanup:
- Shrink object by not including needless sysfs or procfs support
- We don't need no steenkin' forward declarations. (Except one.)
Until the I2C framework merges "new style" driver support, matching
the driver model better, using rv5c chips or alarm IRQs requires a
separate board-specific patch. (And an IRQ handler, handing off labor
through a work_struct...)
This uses the "method 3" register reads, but notes that it's done
to work around an evident i2c adapter driver bug.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
Index: g26/drivers/rtc/rtc-rs5c372.c
===
--- g26.orig/drivers/rtc/rtc-rs5c372.c 2006-12-27 17:19:55.0 -0800
+++ g26/drivers/rtc/rtc-rs5c372.c 2007-01-02 18:44:35.0 -0800
@@ -1,5 +1,5 @@
/*
- * An I2C driver for the Ricoh RS5C372 RTC
+ * An I2C driver for Ricoh RS5C372 and RV5C38[67] RTCs
*
* Copyright (C) 2005 Pavel Mironchik <[EMAIL PROTECTED]>
* Copyright (C) 2006 Tower Technologies
@@ -13,7 +13,7 @@
#include
#include
-#define DRV_VERSION "0.3"
+#define DRV_VERSION "0.4"
/* Addresses to scan */
static unsigned short normal_i2c[] = { /* 0x32,*/ I2C_CLIENT_END };
@@ -21,6 +21,13 @@ static unsigned short normal_i2c[] = { /
/* Insmod parameters */
I2C_CLIENT_INSMOD;
+
+/*
+ * Ricoh has a family of I2C based RTCs, which differ only slightly from
+ * each other. Differences center on pinout (e.g. how many interrupts,
+ * output clock, etc) and how the control registers are used. The '372
+ * is significant only because that's the one this driver first supported.
+ */
#define RS5C372_REG_SECS 0
#define RS5C372_REG_MINS 1
#define RS5C372_REG_HOURS 2
@@ -29,59 +36,142 @@ I2C_CLIENT_INSMOD;
#define RS5C372_REG_MONTH 5
#define RS5C372_REG_YEAR 6
#define RS5C372_REG_TRIM 7
+# define RS5C372_TRIM_XSL 0x80
+# define RS5C372_TRIM_MASK0x7F
-#define RS5C372_TRIM_XSL 0x80
-#define RS5C372_TRIM_MASK 0x7F
-
-#define RS5C372_REG_BASE 0
-
-static int rs5c372_attach(struct i2c_adapter *adapter);
-static int rs5c372_detach(struct i2c_client *client);
-static int rs5c372_probe(struct i2c_adapter *adapter, int address, int kind);
+#define RS5C_REG_ALARM_A_MIN 8 /* or ALARM_W */
+#define RS5C_REG_ALARM_A_HOURS 9
+#define RS5C_REG_ALARM_A_WDAY 10
+
+#define RS5C_REG_ALARM_B_MIN 11 /* or ALARM_D */
+#define RS5C_REG_ALARM_B_HOURS 12
+#define RS5C_REG_ALARM_B_WDAY 13 /* (ALARM_B only) */
+
+#define RS5C_REG_CTRL1 14
+# define RS5C_CTRL1_AALE (1 << 7)/* or WALE */
+# define RS5C_CTRL1_BALE (1 << 6)/* or DALE */
+# define RV5C387_CTRL1_24 (1 << 5)
+# define RS5C372A_CTRL1_SL1 (1 << 5)
+# define RS5C_CTRL1_CT_MASK (7 << 0)
+# define RS5C_CTRL1_CT0 (0 << 0)/* no periodic irq */
+# define RS5C_CTRL1_CT4 (4 << 0)/* 1 Hz level irq */
+#define RS5C_REG_CTRL2 15
+# define RS5C372_CTRL2_24 (1 << 5)
+# define RS5C_CTRL2_XSTP (1 << 4)
+# define RS5C_CTRL2_CTFG (1 << 2)
+# define RS5C_CTRL2_AAFG (1 << 1)/* or WAFG */
+# define RS5C_CTRL2_BAFG (1 << 0)/* or DAFG */
+
+
+/* to read (style 1) or write registers starting at R */
+#define RS5C_ADDR(R) (((R) << 4) | 0)
+
+
+enum rtc_type {
+ rtc_undef = 0,
+ rtc_rs5c372a,
+ rtc_rs5c372b,
+ rtc_rv5c386,
+ rtc_rv5c387a,
+};
+/* REVISIT: this assumes that:
+ * - we're in the 21st century, so it's safe to ignore the century
+ *bit for rv5c38[67] (REG_MONTH bit 7);
+ * - we should use ALARM_A not ALARM_B (may be wrong on
Re: [PATCHSET 1][PATCH 0/6] Filesystem AIO read/write
On Thu, Jan 04, 2007 at 04:51:58PM +1100, Nick Piggin wrote: > Suparna Bhattacharya wrote: > >On Wed, Jan 03, 2007 at 02:15:56PM -0800, Andrew Morton wrote: > > >>Plus Jens's unplugging changes add more reliance upon context inside > >>*current, for the plugging and unplugging operations. I expect that the > >>fsaio patches will need to be aware of the protocol which those proposed > >>changes add. > > > > > >Whatever logic applies to background writeout etc should also just apply > >as is to aio worker threads, shouldn't it ? At least at a quick glance I > >don't see anything special that needs to be done for fsaio, but its good > >to be aware of this anyway, thanks ! > > The submitting process plugs itself, submits all its IO, then unplugs > itself (ie. so the plug is now on the process, rather than the block > device). > > So long as AIO threads do the same, there would be no problem (plugging > is optional, of course). Yup, the AIO threads run the same code as for regular IO, i.e in the rare situations where they actually end up submitting IO, so there should be no problem. And you have already added plug/unplug at the appropriate places in those path, so things should just work. > > This (is supposed to) give a number of improvements over the traditional > plugging (although some downsides too). Most notably for me, the VM gets > cleaner ;) > > However AIO could be an interesting case to test for explicit plugging > because of the way they interact. What kind of improvements do you see > with samba and do you have any benchmark setups? I think aio-stress would be a good way to test/benchmark this sort of stuff, at least for a start. Samba (if I understand this correctly based on my discussions with Tridge) is less likely to generate the kind of io patterns that could benefit from explicit plugging (because the file server has no way to tell what the next request is going to be, it ends up submitting each independently instead of batching iocbs). In future there may be optimization possibilities to consider when submitting batches of iocbs, i.e. on the io submission path. Maybe AIO - O_DIRECT would be interesting to play with first in this regardi ? Regards Suparna > > Thanks, > Nick > > -- > SUSE Labs, Novell Inc. > Send instant messages to your online friends http://au.messenger.yahoo.com > > -- > To unsubscribe, send a message with 'unsubscribe linux-aio' in > the body to [EMAIL PROTECTED] For more info on Linux AIO, > see: http://www.kvack.org/aio/ > Don't email: mailto:"[EMAIL PROTECTED]">[EMAIL PROTECTED] -- Suparna Bhattacharya ([EMAIL PROTECTED]) Linux Technology Center IBM Software Lab, India - 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: VM: Fix nasty and subtle race in shared mmap'ed page writeback
On Thu, 04 Jan 2007 17:03:43 +1100 Nick Piggin <[EMAIL PROTECTED]> wrote: > > That bug was introduced in 2.6.19, with the dirty page tracking patches. > > > > 2.6.18 and earlier used ->private_lock coverage in try_to_free_buffers() to > > prevent it. > > Ohh, right you are, I was looking at 2.6.19 sources. The comments above > ttfb match that as well. Curious that the dirty page patches were allowed > to mess with this... Frankly, those patches scared the crap out of me, specifically because of the delicacy and complexity of the various dirtiness state coherencies. But I just didn't have the bandwidth to go through them with a sufficiently fine toothcomb, sorry. > Anyway that leaves us with the question of why Andrea's database is getting > corrupted. Hopefully he can give us a minimal test-case. It'd odd that stories of pre-2.6.19 BerkeleyDB corruption are now coming out of the woodwork. It's the first I've ever heard of them. - 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: VM: Fix nasty and subtle race in shared mmap'ed page writeback
Andrew Morton wrote:
On Wed, 3 Jan 2007 20:44:36 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
Actually, I think 2.6.18 may have a subtle variation on it.
In particular, I look back at the try_to_free_buffers() thing that I hated
so much, and it makes me wonder.. It used to do:
spin_lock(>private_lock);
ret = drop_buffers(page, _to_free);
spin_unlock(>private_lock);
if (ret) {
.. crappy comment ..
if (test_clear_page_dirty(page))
task_io_account_cancelled_write(PAGE_CACHE_SIZE);
}
and I think that at least on SMP, we had a race with another CPU doing the
"mark page dirty if it was dirty in the PTE" at the same time. Because the
marking dirty would come in, find no buffers (they just got dropped), and
then mark the page dirty (ignoring the lack of any buffers), but then the
above would do the "test_clear_page_dirty()" thing on it.
That bug was introduced in 2.6.19, with the dirty page tracking patches.
2.6.18 and earlier used ->private_lock coverage in try_to_free_buffers() to
prevent it.
Ohh, right you are, I was looking at 2.6.19 sources. The comments above
ttfb match that as well. Curious that the dirty page patches were allowed
to mess with this...
Anyway that leaves us with the question of why Andrea's database is getting
corrupted. Hopefully he can give us a minimal test-case.
Ie the race, I think, existed where that crappy comment was.
The comment was complete, accurate and needed.
Indeed ;)
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
-
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.6.19] mmc: Add support for SDHC cards (Take 2)
Philip Langdale wrote: > This is a bug. The MMC_RSP_R? #defines do not fully characterise the > responses (specically, the way that the response is parsed is not > characterised) and consequently there is no guarantee of uniqueness. > Given this reality - the way that the tifm_sd driver works is unsafe. > > Amen to that. All hw vendors that implement this particular form of brain damage should be dragged out and shot. I'll fix a patch for this later on. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - 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: [PATCHSET 1][PATCH 0/6] Filesystem AIO read/write
Suparna Bhattacharya wrote: On Wed, Jan 03, 2007 at 02:15:56PM -0800, Andrew Morton wrote: Plus Jens's unplugging changes add more reliance upon context inside *current, for the plugging and unplugging operations. I expect that the fsaio patches will need to be aware of the protocol which those proposed changes add. Whatever logic applies to background writeout etc should also just apply as is to aio worker threads, shouldn't it ? At least at a quick glance I don't see anything special that needs to be done for fsaio, but its good to be aware of this anyway, thanks ! The submitting process plugs itself, submits all its IO, then unplugs itself (ie. so the plug is now on the process, rather than the block device). So long as AIO threads do the same, there would be no problem (plugging is optional, of course). This (is supposed to) give a number of improvements over the traditional plugging (although some downsides too). Most notably for me, the VM gets cleaner ;) However AIO could be an interesting case to test for explicit plugging because of the way they interact. What kind of improvements do you see with samba and do you have any benchmark setups? Thanks, Nick -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com - 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: Why to I2c drivers not autoload like other PCI devices?
On Wed, Jan 03, 2007 at 05:29:16PM -0800, Stephen Hemminger wrote: > On Wed, 3 Jan 2007 16:56:00 -0800 > Greg KH <[EMAIL PROTECTED]> wrote: > > > On Wed, Jan 03, 2007 at 04:50:20PM -0800, Stephen Hemminger wrote: > > > Is there some missing magic (udev rule?) that keeps i2c device modules > > > from loading? For example: the Intel i2c-i801 module ought to get loaded > > > automatically on boot up since it has a set of PCI id's that generate > > > the necessary module aliases. It would be better if I2C device's > > > autoloaded > > > like other PCI devices. > > > > No, it should autoload, if it has a MODULE_DEVICE_TABLE() in it. In > > fact, the i2c-i801 autoloads on one of my machines just fine. Are you > > sure your pci ids match properly? > > > > thanks, > > > > greg k-h > > This laptop is running Ubuntu Edgy (6.10) and it doesn't autoload. > Everything works fine if I manually load the module with modprobe. > > This device should match: > > 00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev > 02) > 00: 86 80 da 27 01 00 80 02 02 00 05 0c 00 00 00 00 > 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 20: a1 18 00 00 00 00 00 00 00 00 00 00 cf 10 88 13 > 30: 00 00 00 00 00 00 00 00 00 00 00 00 0b 02 00 00 > > This driver modinfo: > > filename: /lib/modules/2.6.20-rc3/kernel/drivers/i2c/busses/i2c-i801.ko What does: modprobe --show-depends `cat /sys/bus/pci/:00:1f.3/modalias` show? Is it different from: modprobe --config /dev/null --show-depends `cat /sys/bus/pci/:00:1f.3/modalias` ? > author: Frodo Looijaard <[EMAIL PROTECTED]>, Philip Edelbrock <[EMAIL > PROTECTED]>, and Mark D. Studebaker <[EMAIL PROTECTED]> > description:I801 SMBus driver > license:GPL > vermagic: 2.6.20-rc3 mod_unload PENTIUMM 4KSTACKS > depends:i2c-core > alias: pci:v8086d2413sv*sd*bc*sc*i* > alias: pci:v8086d2423sv*sd*bc*sc*i* > alias: pci:v8086d2443sv*sd*bc*sc*i* > alias: pci:v8086d2483sv*sd*bc*sc*i* > alias: pci:v8086d24C3sv*sd*bc*sc*i* > alias: pci:v8086d24D3sv*sd*bc*sc*i* > alias: pci:v8086d25A4sv*sd*bc*sc*i* > alias: pci:v8086d266Asv*sd*bc*sc*i* > alias: pci:v8086d27DAsv*sd*bc*sc*i* <--- should > match Yeah, I would think so. What does: cat /sys/bus/pci/:00:1f.3/modalias show? thanks, greg k-h - 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/
wireless Q
Greetings all; I bought a Belkin Wireless G card, a pci 802-11 radio of some sort. The main chip on it wears the label "RTL8185L" Is there any support for making this a wireless server in the kernel at the present time? I have visions of sticking it in the last pci slot of a box running DD-WRT if there is a driver available. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2007 by Maurice Eugene Heskett, all rights reserved. - 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: VM: Fix nasty and subtle race in shared mmap'ed page writeback
On Wed, 3 Jan 2007 20:44:36 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
> Actually, I think 2.6.18 may have a subtle variation on it.
>
> In particular, I look back at the try_to_free_buffers() thing that I hated
> so much, and it makes me wonder.. It used to do:
>
> spin_lock(>private_lock);
> ret = drop_buffers(page, _to_free);
> spin_unlock(>private_lock);
> if (ret) {
> .. crappy comment ..
> if (test_clear_page_dirty(page))
> task_io_account_cancelled_write(PAGE_CACHE_SIZE);
> }
>
> and I think that at least on SMP, we had a race with another CPU doing the
> "mark page dirty if it was dirty in the PTE" at the same time. Because the
> marking dirty would come in, find no buffers (they just got dropped), and
> then mark the page dirty (ignoring the lack of any buffers), but then the
> above would do the "test_clear_page_dirty()" thing on it.
>
That bug was introduced in 2.6.19, with the dirty page tracking patches.
2.6.18 and earlier used ->private_lock coverage in try_to_free_buffers() to
prevent it.
> Ie the race, I think, existed where that crappy comment was.
The comment was complete, accurate and needed.
-
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: sonypc with Sony Vaio VGN-SZ1VP
On Wednesday 27 September 2006 07:51, [EMAIL PROTECTED] wrote:
> >> > Will sony_acpi ever make it to the mainline? Its very useful for new
> > Nope, not as it is. Useful != supportable.
> >
> > 1. It must not create any files under /proc/acpi
> > This is creating a machine-specific API, which
> > is exactly what we don't want Nobody can maintain
> > 50 machine specific APIs.
> >
> > These objects must appear generic and under sysfs
> > as if acpi were not involved in providing them.
> >
> > 2. its source code shall not live in drivers/acpi
> > it is not part of the ACPI implementation after all --
> > it is a platform specific driver.
>
>...
>
> I don't really care much about sony_acpi (since I'm not maintaining it
> anymore, even if I still answer support requests about it), but this is
> just silly. This has been going on for more than one and a half year now.
>
> Meanwhile (at least from what I've seen), the ACPI subsystem still doesn't
> provide this "generic" API which platform specific driver need to
> implement. drivers/acpi/{hotkey.c,video.c} are just rudimentary, and there
> is no indication that this is going forward:
You are right. And the reason is that platform specific drivers are not part
of ACPI.
They must either be vendor documented/supplied or reverse-engineered.
Vendors have not been forthcoming with documentation or code to support
Linux laptops, and our happy team here at Intel is not allowed to be in
the reverse enginering business.
So I concur that hotkey.c is a failed experiment, and I'm going to delete it.
There is more different than common on these boxes, so it makes no sense.
video.c, however, is standard, and stays for those machines that actually
do follow the public specification.
> In March 2005 you (Len) said:
>
> > The goal is to DELETE ibm, toshiba, and asus drivers -- or at least the
> video.c handles the standard compliant machines.> duplicated functions in
> them.
> >
> > platform specific drivers make it harder, not easier, to support more
> > hardware -- there are a zillion vendors out there, implementing special
> > drivers for each of them is a strategy of last resort.
Still true, though it is clear we'll never be able to delete platform specific
parts --
just the parts that duplicate the generic standard functions..
> > I'd like to keep this driver out-of-tree
> > until we prove that we can't enhance the
> > generic code to handle this hardware
> > without the addition of a new driver.
>
> How long is this going to take ?
How about 2.6.21?
What needs to happen is
1. a maintainer for sony_acpi.c needs to step forward
I can't do this, I'm not allowed to be in the reverse engineering business.
2. /proc/acpi/sony API needs to be deleted
3. source needs to move out of drivers/acpi, and into drivers/misc along with
msi.
Luming has a sony laptop and can help with this, but
he can't be the permanent maintainer any more than I can, for the same reason.
If we can get past #1, then I recommend we apply the patch series in -mm to
the acpi-test tree and go from there.
-Len
-
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.6.19] mmc: Add support for SDHC cards (Take 2)
Andrew Morton wrote: > On Mon, 01 Jan 2007 07:29:55 -0800 > Philip Langdale <[EMAIL PROTECTED]> wrote: > >> #define MMC_RSP_R1B >> (MMC_RSP_PRESENT|MMC_RSP_CRC|MMC_RSP_OPCODE|MMC_RSP_BUSY) >> #define MMC_RSP_R2 (MMC_RSP_PRESENT|MMC_RSP_136|MMC_RSP_CRC) >> #define MMC_RSP_R3 (MMC_RSP_PRESENT) >> -#define MMC_RSP_R6 (MMC_RSP_PRESENT|MMC_RSP_CRC) >> +#define MMC_RSP_R6 (MMC_RSP_PRESENT|MMC_RSP_CRC|MMC_RSP_OPCODE) >> +#define MMC_RSP_R7 (MMC_RSP_PRESENT|MMC_RSP_CRC|MMC_RSP_OPCODE) > > This gives MMC_RSP_R1 and MMC_RSP_R6 the same value, so > > drivers/mmc/tifm_sd.c: In function 'tifm_sd_op_flags': > drivers/mmc/tifm_sd.c:190: error: duplicate case value > drivers/mmc/tifm_sd.c:181: error: previously used here This is a bug. The MMC_RSP_R? #defines do not fully characterise the responses (specically, the way that the response is parsed is not characterised) and consequently there is no guarantee of uniqueness. Given this reality - the way that the tifm_sd driver works is unsafe. If R6 had not been incorrectly defined (the missing RSP_OPCODE should always have been there), then this code would not have worked. As things currently stand, it is necessary to also check the command number to decide on the correct response type - that's suboptimal and it's probably good to uniquely identify the response in the mmc_command in some other fashion. I'm going to remove the R6 fix from my next diff to keep these things distinct but this needs to be resolved. --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 v4 01/13] Linux RDMA Core Changes
> If you think I should not add the udata parameter to the req_notify_cq() > provider verb, then I can rework the chelsio driver: > > 1) at cq creation time, pass the virtual address of the u32 used by the > library to track the current cq index. That way the chelsio kernel > driver can save the address in its kernel cq context for later use. > > 2) change chelsio's req_notify_cq() to copy in the current cq index > value directly for rearming. > > This puts all the burden on the chelsio driver, which is apparently the > only one that needs this functionality. Good thinking, I haven't thought of this approach. This way there won't be any API/core changes and no changes to other low level drivers, correct? And for chelsio, there's no overhead as compared to code you posted. Sounds good. -- MST - 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: VM: Fix nasty and subtle race in shared mmap'ed page writeback
Linus Torvalds wrote:
On Thu, 4 Jan 2007, Nick Piggin wrote:
Yhat's when the bug was introduced -- 2.6.19. 2.6.18 does not have
this bug, so it cannot be years old.
Actually, I think 2.6.18 may have a subtle variation on it.
In particular, I look back at the try_to_free_buffers() thing that I hated
so much, and it makes me wonder.. It used to do:
spin_lock(>private_lock);
ret = drop_buffers(page, _to_free);
spin_unlock(>private_lock);
if (ret) {
.. crappy comment ..
if (test_clear_page_dirty(page))
task_io_account_cancelled_write(PAGE_CACHE_SIZE);
}
and I think that at least on SMP, we had a race with another CPU doing the
"mark page dirty if it was dirty in the PTE" at the same time. Because the
marking dirty would come in, find no buffers (they just got dropped), and
then mark the page dirty (ignoring the lack of any buffers), but then the
above would do the "test_clear_page_dirty()" thing on it.
Ie the race, I think, existed where that crappy comment was.
But that much older race would only trigger on SMP (or possibly UP with
preempt).
Oh yes the try_to_free_buffers race, I think, does exist in older kernels.
Yes according to our earlier analysis it would trigger with UP+preempt and
SMP.
But the patch that Andrea was pointing to was your last patch (The Fix),
which stopped page_mkclean caller throwing out dirty bits. You probably
didn't see that in the mail I cc'ed you on.
So yes it would be interesting to see whether fixing try_to_free_buffers
fixes Andrea's problem on older kernels.
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
-
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: SATA problems
Pablo Sebastian Greco wrote:
> By crash I mean the whole system going down, having to reset the entire
> machine.
> I'm sending you 4 files:
> dmesg: current boot dmesg, just a boot, because no errors appeared after
> last crash, since the server is out of production right now (errors
> usually appear under heavy load, and this primarily a transparent proxy
> for about 1000 simultaneous users)
> lspci: the way you asked for it
> messages and messages.1: files where you can see old boots and crashes
> (even a soft lockup).
> If there is anything else I can do, let me know. If you need direct
> access to the server, I can arrange that too.
Can you try 2.6.20-rc3 and see if 'CLO not available' message goes away
(please post boot dmesg)?
The crash/lock is because filesystem code does not cope with IO errors
very well. I can't tell why timeouts are occurring in the first place.
It seems that only samsung drives are affected (sda2, 3, 4). Hmmm...
Please apply the attached patch to 2.6.20-rc3 and test it.
Thanks.
--
tejun
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 0d51d13..f8cf349 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3327,6 +3327,8 @@ static const struct ata_blacklist_entry
ata_device_blacklist [] = {
/* NCQ is slow */
{ "WDC WD740ADFD-00", NULL, ATA_HORKAGE_NONCQ },
+ { "SAMSUNG SP2504C",NULL, ATA_HORKAGE_NONCQ },
+
/* Devices with NCQ limits */
/* End Marker */
Re: [2.6 patch] the scheduled find_trylock_page() removal
Adrian Bunk wrote: This patch contains the scheduled find_trylock_page() removal. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> I guess I don't have a problem with this going into -mm and making its way upstream sometime after the next release. I would normally say it is OK to stay for another year because it is so unintrusive, but I don't like the fact it doesn't give one an explicit ref on the page -- it could be misused slightly more easily than find_lock_page or find_get_page. Anyone object? Otherwise: Acked-by: Nick Piggin <[EMAIL PROTECTED]> -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com - 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: [PATCHSET 1][PATCH 0/6] Filesystem AIO read/write
On Wed, Jan 03, 2007 at 02:15:56PM -0800, Andrew Morton wrote: > On Thu, 28 Dec 2006 13:53:08 +0530 > Suparna Bhattacharya <[EMAIL PROTECTED]> wrote: > > > This patchset implements changes to make filesystem AIO read > > and write asynchronous for the non O_DIRECT case. > > Unfortunately the unplugging changes in Jen's block tree have trashed these > patches to a degree that I'm not confident in my repair attempts. So I'll > drop the fasio patches from -mm. I took a quick look and the conflicts seem pretty minor to me, the unplugging changes mostly touch nearby code. Please let know how you want this fixed up. >From what I can tell the comments in the unplug patches seem to say that it needs more work and testing, so perhaps a separate fixup patch may be a better idea rather than make the fsaio patchset dependent on this. > > Zach's observations regarding this code's reliance upon things at *current > sounded pretty serious, so I expect we'd be seeing changes for that anyway? Not really, at least nothing that I can see needing a change. As I mentioned there is no reliance on *current in the code that runs in the aio threads that we need to worry about. The generic_write_checks etc that Zach was referring to all happens in the context of submitting process, not in retry context. The model is to perform all validation at the time of io submission. And of course things like copy_to_user() are already taken care of by use_mm(). Lets look at it this way - the kernel already has the ability to do background writeout on behalf of a task from a kernel thread and likewise read(ahead) pages that may be consumed by another task. There is also the ability to operate another task's address space (as used by ptrace). So there is nothing groundbreaking here. In fact on most occasions, all the IO is initiated in the context of the submitting task, so the aio threads mainly deal with checking for completion and transfering completed data to user space. > > Plus Jens's unplugging changes add more reliance upon context inside > *current, for the plugging and unplugging operations. I expect that the > fsaio patches will need to be aware of the protocol which those proposed > changes add. Whatever logic applies to background writeout etc should also just apply as is to aio worker threads, shouldn't it ? At least at a quick glance I don't see anything special that needs to be done for fsaio, but its good to be aware of this anyway, thanks ! Regards Suparna > > -- > To unsubscribe, send a message with 'unsubscribe linux-aio' in > the body to [EMAIL PROTECTED] For more info on Linux AIO, > see: http://www.kvack.org/aio/ > Don't email: mailto:"[EMAIL PROTECTED]">[EMAIL PROTECTED] -- Suparna Bhattacharya ([EMAIL PROTECTED]) Linux Technology Center IBM Software Lab, India - 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] lock stat for -rt 2.6.20-rc2-rt2.2.lock_stat.patch
* Bill Huey <[EMAIL PROTECTED]> wrote:
> > - Documentation/CodingStyle compliance - the code is not ugly per se
> >but still looks a bit 'alien' - please try to make it look Linuxish,
> >if i apply this we'll probably stick with it forever. This is the
> >major reason i havent applied it yet.
>
> I reformatted most of the patch to be 80 column limited. I simplified
> a number of names, but I'm open to suggestions and patches to how to
> go about this. Much of this code was a style experiment, but now I
> have to make this more mergable.
thanks. It's looking better, but there's still quite a bit of work left:
there's considerable amount of whitespace noise in it - lots of lines
with space/tab at the end, lines with 8 spaces instead of tabs, etc.
comment style issues:
+/* To be use for avoiding the dynamic attachment of spinlocks at runtime
+ * by attaching it inline with the lock initialization function */
the proper multi-line style is:
/*
* To be used for avoiding the dynamic attachment of spinlocks at
* runtime by attaching it inline with the lock initialization function:
*/
(note i also fixed a typo in the one above)
more unused code:
+/*
+static DEFINE_LS_ENTRY(__pte_alloc);
+static DEFINE_LS_ENTRY(get_empty_filp);
+static DEFINE_LS_ENTRY(init_waitqueue_head);
...
+*/
these:
+static int lock_stat_inited = 0;
should not be initialized to 0, that is implicit for static variables.
weird alignment here:
+void lock_stat_init(struct lock_stat *oref)
+{
+ oref->function[0] = 0;
+ oref->file = NULL;
+ oref->line = 0;
+
+ oref->ntracked = 0;
funky branching:
+ spin_lock_irqsave(_store_lock, flags);
+ if (!list_empty(_stat_free_store)) {
+ struct list_head *e = lock_stat_free_store.next;
+ struct lock_stat *s;
+
+ s = container_of(e, struct lock_stat, list_head);
+ list_del(e);
+
+ spin_unlock_irqrestore(_store_lock, flags);
+
+ return s;
+ }
+ spin_unlock_irqrestore(_store_lock, flags);
+
+ return NULL;
that should be s = NULL in the function scope and a plain unlock and
return s.
assignments mixed with arithmetics:
+static
+int lock_stat_compare_objs(struct lock_stat *x, struct lock_stat *y)
+{
+ int a = 0, b = 0, c = 0;
+
+ (a = ksym_strcmp(x->function, y->function)) ||
+ (b = ksym_strcmp(x->file, y->file)) ||
+ (c = (x->line - y->line));
+
+ return a | b | c;
the usual (and more readable) style is to separate them out explicitly:
a = ksym_strcmp(x->function, y->function);
if (!a)
return 0;
b = ksym_strcmp(x->file, y->file);
if (!b)
return 0;
return x->line == y->line;
(detail: this btw also fixes a bug in the function above AFAICS, in the
a && !b case.)
also, i'm not fully convinced we want that x->function as a string. That
makes comparisons alot slower. Why not make it a void *, and resolve to
the name via kallsyms only when printing it in /proc, like lockdep does
it?
no need to put dates into comments:
+* Fri Oct 27 00:26:08 PDT 2006
then:
+ while (node)
+ {
proper style is:
+ while (node) {
this function definition:
+static
+void lock_stat_insert_object(struct lock_stat *o)
can be single-line. We make it multi-line only when needed.
these are only samples of the types of style problems still present in
the code.
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: VM: Fix nasty and subtle race in shared mmap'ed page writeback
On Thu, 4 Jan 2007, Nick Piggin wrote:
>
> Yhat's when the bug was introduced -- 2.6.19. 2.6.18 does not have
> this bug, so it cannot be years old.
Actually, I think 2.6.18 may have a subtle variation on it.
In particular, I look back at the try_to_free_buffers() thing that I hated
so much, and it makes me wonder.. It used to do:
spin_lock(>private_lock);
ret = drop_buffers(page, _to_free);
spin_unlock(>private_lock);
if (ret) {
.. crappy comment ..
if (test_clear_page_dirty(page))
task_io_account_cancelled_write(PAGE_CACHE_SIZE);
}
and I think that at least on SMP, we had a race with another CPU doing the
"mark page dirty if it was dirty in the PTE" at the same time. Because the
marking dirty would come in, find no buffers (they just got dropped), and
then mark the page dirty (ignoring the lack of any buffers), but then the
above would do the "test_clear_page_dirty()" thing on it.
Ie the race, I think, existed where that crappy comment was.
But that much older race would only trigger on SMP (or possibly UP with
preempt).
And I haven't actually thought about it that much, so I could be full of
crap. But I don't see anything that protects against it: we may hold the
page lock, but since the code that marks things _dirty_ doesn't
necessarily always hold it, that doesn't help us. And we may hold the
"private_lock", but we drop it before we do the dirty bit clearing, and in
fact on UP+PREEMPT that very dropping could cause an active preemption to
take place, so..
I dunno.
I would certainly suggest the whole series of my "dirty cleanup" be added
on top of 2.6.18.3 (which apparently has the dirty mapped page tracking).
For older kernels? If there is a race there, it must be pretty damn hard
to hit in practice (and it must have been there for a looong time), so
trying to fix it is possibly as likely to cause problems as it migh to fix
them.
Linus
-
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] X.25: Trivial, SOCK_DEBUG's in x25_facilities missing newlines
Trivial. Newlines missing on the SOCK_DEBUG's for X.25 facility negotiation.
Signed-off-by: Andrew Hendry <[EMAIL PROTECTED]>
--- linux-2.6.19-vanilla/net/x25/x25_facilities.c 2006-12-31
22:31:07.0 +1100
+++ linux-2.6.19/net/x25/x25_facilities.c 2007-01-01 22:56:17.0
+1100
@@ -254,7 +254,7 @@ int x25_negotiate_facilities(struct sk_b
* They want reverse charging, we won't accept it.
*/
if ((theirs.reverse & 0x01 ) && (ours->reverse & 0x01)) {
- SOCK_DEBUG(sk, "X.25: rejecting reverse charging request");
+ SOCK_DEBUG(sk, "X.25: rejecting reverse charging request\n");
return -1;
}
@@ -262,29 +262,29 @@ int x25_negotiate_facilities(struct sk_b
if (theirs.throughput) {
if (theirs.throughput < ours->throughput) {
- SOCK_DEBUG(sk, "X.25: throughput negotiated down");
+ SOCK_DEBUG(sk, "X.25: throughput negotiated down\n");
new->throughput = theirs.throughput;
}
}
if (theirs.pacsize_in && theirs.pacsize_out) {
if (theirs.pacsize_in < ours->pacsize_in) {
- SOCK_DEBUG(sk, "X.25: packet size inwards negotiated
down");
+ SOCK_DEBUG(sk, "X.25: packet size inwards negotiated
down\n");
new->pacsize_in = theirs.pacsize_in;
}
if (theirs.pacsize_out < ours->pacsize_out) {
- SOCK_DEBUG(sk, "X.25: packet size outwards negotiated
down");
+ SOCK_DEBUG(sk, "X.25: packet size outwards negotiated
down\n");
new->pacsize_out = theirs.pacsize_out;
}
}
if (theirs.winsize_in && theirs.winsize_out) {
if (theirs.winsize_in < ours->winsize_in) {
- SOCK_DEBUG(sk, "X.25: window size inwards negotiated
down");
+ SOCK_DEBUG(sk, "X.25: window size inwards negotiated
down\n");
new->winsize_in = theirs.winsize_in;
}
if (theirs.winsize_out < ours->winsize_out) {
- SOCK_DEBUG(sk, "X.25: window size outwards negotiated
down");
+ SOCK_DEBUG(sk, "X.25: window size outwards negotiated
down\n");
new->winsize_out = theirs.winsize_out;
}
}
-
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] 4/4 block: explicit plugging
Jens Axboe wrote: Nick writes: This is a patch to perform block device plugging explicitly in the submitting process context rather than implicitly by the block device. Hi Jens, Hey thanks for doing so much hard work with this, I couldn't have fixed all the block layer stuff myself. QRCU looks like a good solution for the barrier/sync operations (/me worried that one wouldn't exist), and a novel use of RCU! The only thing I had been thinking about before it is ready for primetime -- as far as the VM side of things goes -- is whether we should change the hard calls to address_space operations, such that they might be avoided or customised when there is no backing block device? I'm sure the answer to this is "yes", so I have an idea for a simple implementation... but I'd like to hear thoughts from network fs / raid people? Nick -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com - 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 3/2] fix flush_workqueue() vs CPU_DEAD race
On Wed, Jan 03, 2007 at 08:26:57PM +0300, Oleg Nesterov wrote: > > I thought that these patches don't depend on each other, flush_work/workueue > don't care where cpu-hotplug takes workqueue_mutex, in CPU_LOCK_ACQUIRE or in > CPU_UP_PREPARE case (or CPU_DEAD/CPU_LOCK_RELEASE for unlock). > > Could you clarify? Just curious. You are right. They don't depend on each other. The intention behind introducing CPU_LOCK_ACQUIRE and CPU_LOCK_RELEASE was to have a standard place where the subsystems could acquire/release the "cpu hotplug protection" mutex in the cpu_hotplug callback function. The same can be acheived by acquiring these mutexes in CPU_UP_PREPARE/CPU_DOWN_PREPARE etc. This is true for every subsystem that is cpu-hotplug aware. > Oleg. > Thanks and Regards gautham. -- Gautham R Shenoy Linux Technology Center IBM India. "Freedom comes with a price tag of responsibility, which is still a bargain, because Freedom is priceless!" - 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: VM: Fix nasty and subtle race in shared mmap'ed page writeback
Andrea Gelmini wrote: On Sun, Dec 31, 2006 at 02:55:58PM +1100, Nick Piggin wrote: This bug was only introduced in 2.6.19, due to a change that caused pte no, Linus said that with 2.6.19 it's easier to trigger this bug... Yhat's when the bug was introduced -- 2.6.19. 2.6.18 does not have this bug, so it cannot be years old. So if your corruption is years old, then it must be something else. Maybe it is hidden by a timing change, or BDB isn't using msync properly. I can give you a complete image where just changing kernel (everything is same, of course) corruptions goes away. we spent a lot, I mean a *lot*, of time looking for our code mistake, and so on. I don't want to seem rude, but I am sure that Berkeley DB corruption we have seen (not just Klibido, but I also think about postgrey, and so on) depends on this bug. I repeat, if you have time/interest I can give you a complete machine to see the problem. You're not being rude, but I just wanted to point out that this patch (nor the dirty page accounting also in 2.6.19) doesn't fix anything that was in 2.6.18, AFAIKS. I wouldn't discount a kernel bug, but it will be hard to track down unless you can find an earlier kernel that did not cause the corruptions and/or provide source for a minimal test case to reproduce. -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.19 2/2] X.25: Adds /proc/net/x25/forward to view active forwarded calls.
View the active forwarded call list
cat /proc/net/x25/forward
Signed-off-by: Andrew Hendry <[EMAIL PROTECTED]>
--- linux-2.6.19-vanilla/net/x25/x25_proc.c 2006-12-31 22:31:07.0
+1100
+++ linux-2.6.19/net/x25/x25_proc.c 2007-01-01 19:16:56.0 +1100
@@ -165,6 +165,75 @@ out:
return 0;
}
+static __inline__ struct x25_forward *x25_get_forward_idx(loff_t pos)
+{
+ struct x25_forward *f;
+ struct list_head *entry;
+
+ list_for_each(entry, _forward_list) {
+ f = list_entry(entry, struct x25_forward, node);
+ if (!pos--)
+ goto found;
+ }
+
+ f = NULL;
+found:
+ return f;
+}
+
+static void *x25_seq_forward_start(struct seq_file *seq, loff_t *pos)
+{
+ loff_t l = *pos;
+
+ read_lock_bh(_forward_list_lock);
+ return l ? x25_get_forward_idx(--l) : SEQ_START_TOKEN;
+}
+
+static void *x25_seq_forward_next(struct seq_file *seq, void *v, loff_t *pos)
+{
+ struct x25_forward *f;
+
+ ++*pos;
+ if (v == SEQ_START_TOKEN) {
+ f = NULL;
+ if (!list_empty(_forward_list))
+ f = list_entry(x25_forward_list.next,
+ struct x25_forward, node);
+ goto out;
+ }
+ f = v;
+ if (f->node.next != _forward_list)
+ f = list_entry(f->node.next, struct x25_forward, node);
+ else
+ f = NULL;
+out:
+ return f;
+
+}
+
+static void x25_seq_forward_stop(struct seq_file *seq, void *v)
+{
+ read_unlock_bh(_forward_list_lock);
+}
+
+static int x25_seq_forward_show(struct seq_file *seq, void *v)
+{
+ struct x25_forward *f;
+
+ if (v == SEQ_START_TOKEN) {
+ seq_printf(seq, "lci dev1 dev2\n");
+ goto out;
+ }
+
+ f = v;
+
+ seq_printf(seq, "%d %-10s %-10s\n",
+ f->lci, f->dev1->name, f->dev2->name);
+
+out:
+ return 0;
+}
+
static struct seq_operations x25_seq_route_ops = {
.start = x25_seq_route_start,
.next = x25_seq_route_next,
@@ -179,6 +248,13 @@ static struct seq_operations x25_seq_soc
.show = x25_seq_socket_show,
};
+static struct seq_operations x25_seq_forward_ops = {
+ .start = x25_seq_forward_start,
+ .next = x25_seq_forward_next,
+ .stop = x25_seq_forward_stop,
+ .show = x25_seq_forward_show,
+};
+
static int x25_seq_socket_open(struct inode *inode, struct file *file)
{
return seq_open(file, _seq_socket_ops);
@@ -189,6 +265,11 @@ static int x25_seq_route_open(struct ino
return seq_open(file, _seq_route_ops);
}
+static int x25_seq_forward_open(struct inode *inode, struct file *file)
+{
+ return seq_open(file, _seq_forward_ops);
+}
+
static struct file_operations x25_seq_socket_fops = {
.owner = THIS_MODULE,
.open = x25_seq_socket_open,
@@ -205,6 +286,14 @@ static struct file_operations x25_seq_ro
.release= seq_release,
};
+static struct file_operations x25_seq_forward_fops = {
+ .owner = THIS_MODULE,
+ .open = x25_seq_forward_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release= seq_release,
+};
+
static struct proc_dir_entry *x25_proc_dir;
int __init x25_proc_init(void)
@@ -225,9 +314,17 @@ int __init x25_proc_init(void)
if (!p)
goto out_socket;
p->proc_fops = _seq_socket_fops;
+
+ p = create_proc_entry("forward", S_IRUGO, x25_proc_dir);
+ if (!p)
+ goto out_forward;
+ p->proc_fops = _seq_forward_fops;
rc = 0;
+
out:
return rc;
+out_forward:
+ remove_proc_entry("socket", x25_proc_dir);
out_socket:
remove_proc_entry("route", x25_proc_dir);
out_route:
@@ -237,6 +334,7 @@ out_route:
void __exit x25_proc_exit(void)
{
+ remove_proc_entry("forward", x25_proc_dir);
remove_proc_entry("route", x25_proc_dir);
remove_proc_entry("socket", x25_proc_dir);
remove_proc_entry("x25", proc_net);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.19 1/2] X.25: Adds call forwarding to X.25
Adds call forwarding to X.25, allowing it to operate like an X.25 router.
Useful if one needs to manipulate X.25 traffic with tools like tc.
This is an update/cleanup based off a patch submitted by Daniel Ferenci a few
years ago.
Worked ok with Cisco XoT, linux X.25 back to back, and some old NTUs/PADs.
Signed-off-by: Andrew Hendry <[EMAIL PROTECTED]>
diff -uprN -X linux-2.6.19/Documentation/dontdiff
linux-2.6.19-vanilla/include/net/x25.h linux-2.6.19/include/net/x25.h
--- linux-2.6.19-vanilla/include/net/x25.h 2006-12-31 22:31:06.0
+1100
+++ linux-2.6.19/include/net/x25.h 2007-01-01 17:06:13.0 +1100
@@ -161,6 +161,14 @@ struct x25_sock {
unsigned long vc_facil_mask; /* inc_call facilities mask */
};
+struct x25_forward {
+ struct list_headnode;
+ unsigned intlci;
+ struct net_device *dev1;
+ struct net_device *dev2;
+ atomic_trefcnt;
+};
+
static inline struct x25_sock *x25_sk(const struct sock *sk)
{
return (struct x25_sock *)sk;
@@ -198,6 +206,12 @@ extern int x25_negotiate_facilities(stru
struct x25_dte_facilities *);
extern void x25_limit_facilities(struct x25_facilities *, struct x25_neigh *);
+/* x25_forward.c */
+extern void x25_clear_forwards(struct net_device *);
+extern struct x25_neigh *x25_find_forward(int, struct x25_neigh *);
+extern int x25_forward_call(struct x25_address *, struct x25_neigh *,
+ struct sk_buff *, int);
+
/* x25_in.c */
extern int x25_process_rx_frame(struct sock *, struct sk_buff *);
extern int x25_backlog_rcv(struct sock *, struct sk_buff *);
@@ -281,6 +295,8 @@ extern struct hlist_head x25_list;
extern rwlock_t x25_list_lock;
extern struct list_head x25_route_list;
extern rwlock_t x25_route_list_lock;
+extern struct list_head x25_forward_list;
+extern rwlock_t x25_forward_list_lock;
extern int x25_proc_init(void);
extern void x25_proc_exit(void);
diff -uprN -X linux-2.6.19/Documentation/dontdiff
linux-2.6.19-vanilla/net/x25/af_x25.c linux-2.6.19/net/x25/af_x25.c
--- linux-2.6.19-vanilla/net/x25/af_x25.c 2006-12-31 22:31:07.0
+1100
+++ linux-2.6.19/net/x25/af_x25.c 2007-01-01 00:32:48.0 +1100
@@ -850,6 +850,9 @@ int x25_rx_call_request(struct sk_buff *
struct x25_dte_facilities dte_facilities;
int len, rc;
+ struct sk_buff *skbn;
+ skbn = skb_clone(skb, GFP_ATOMIC);
+
/*
* Remove the LCI and frame type.
*/
@@ -875,11 +878,23 @@ int x25_rx_call_request(struct sk_buff *
sk = x25_find_listener(_addr,skb);
skb_push(skb,len);
+ if (sk != NULL && sk_acceptq_is_full(sk)) {
+ goto out_sock_put;
+ }
+
/*
-* We can't accept the Call Request.
+* We dont have any listeners for this incoming call.
+* Try forwarding it.
*/
- if (sk == NULL || sk_acceptq_is_full(sk))
- goto out_clear_request;
+ if (sk == NULL) {
+ if (x25_forward_call(_addr, nb, skbn, lci) == 0) {
+ /* Call was fowarded, dont process it any more */
+ return 0;
+ } else {
+ /* No listeners, can't forward, clear the call */
+ goto out_clear_request;
+ }
+ }
/*
* Try to reach a compromise on the requested facilities.
@@ -1600,6 +1615,9 @@ void x25_kill_by_neigh(struct x25_neigh
x25_disconnect(s, ENETUNREACH, 0, 0);
write_unlock_bh(_list_lock);
+
+ /* Remove any related forwards */
+ x25_clear_forwards(nb->dev);
}
static int __init x25_init(void)
diff -uprN -X linux-2.6.19/Documentation/dontdiff
linux-2.6.19-vanilla/net/x25/Makefile linux-2.6.19/net/x25/Makefile
--- linux-2.6.19-vanilla/net/x25/Makefile 2006-12-31 22:31:07.0
+1100
+++ linux-2.6.19/net/x25/Makefile 2006-12-31 23:25:38.0 +1100
@@ -6,5 +6,5 @@ obj-$(CONFIG_X25) += x25.o
x25-y := af_x25.o x25_dev.o x25_facilities.o x25_in.o \
x25_link.o x25_out.o x25_route.o x25_subr.o \
- x25_timer.o x25_proc.o
+ x25_timer.o x25_proc.o x25_forward.o
x25-$(CONFIG_SYSCTL) += sysctl_net_x25.o
diff -uprN -X linux-2.6.19/Documentation/dontdiff
linux-2.6.19-vanilla/net/x25/x25_dev.c linux-2.6.19/net/x25/x25_dev.c
--- linux-2.6.19-vanilla/net/x25/x25_dev.c 2006-12-31 22:31:07.0
+1100
+++ linux-2.6.19/net/x25/x25_dev.c 2007-01-01 17:07:30.0 +1100
@@ -29,6 +29,7 @@ static int x25_receive_data(struct sk_bu
struct sock *sk;
unsigned short frametype;
unsigned int lci;
+ struct x25_neigh *to_neigh;
frametype = skb->data[2];
lci = ((skb->data[0] << 8)
Re: S.M.A.R.T no longer available in 2.6.20-rc2-mm2 with libata
On Thursday 04 January 2007 01:50, Ed Sweetman wrote: > Not sure what went on between 2.6.19-rc5-mm2 and 2.6.20-rc2-mm2 in > libata land but SMART is no longer available on my hdds. I'm assuming > this is not the intended behavior. > > In case this is chipset specific, IDE interface: nVidia Corporation > CK804 Serial ATA Controller (rev f3) > > I'm using Libata nvidia driver, the drives happen to be sata drives, but > even the pata ones no longer report having SMART. What program are you trying to use here? As I reported around -rc1 time, hddtemp is broken by 2.6.20-rc but Jens posted a patch to fix it. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - 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: [Openipmi-developer] [PATCH] IPMI: Fix some RCU problems
On Wed, Jan 03, 2007 at 01:22:32PM -0800, Andrew Morton wrote:
> It's nice to always have a comment explaining the use of open-coded
> barriers. Because often the reader is left wondered what on earth it's
> barriering against what on earth else.
>
Ok, here it is...
Andrew asked that the open-coded barriers be commented, so here it
is. I also realized that one of the read barriers was in an area
where the protecting mutex was held, so no read barrier was needed.
Signed-off-by: Corey Minyard <[EMAIL PROTECTED]>
Index: linux-2.6.19/drivers/char/ipmi/ipmi_msghandler.c
===
--- linux-2.6.19.orig/drivers/char/ipmi/ipmi_msghandler.c
+++ linux-2.6.19/drivers/char/ipmi/ipmi_msghandler.c
@@ -839,7 +839,6 @@ int ipmi_create_user(unsigned int
goto out_kfree;
found:
- smp_rmb();
/* Note that each existing user holds a refcount to the interface. */
kref_get(>refcount);
@@ -2762,10 +2761,15 @@ int ipmi_register_smi(struct ipmi_smi_ha
synchronize_rcu();
kref_put(>refcount, intf_free);
} else {
- /* After this point the interface is legal to use. */
- smp_wmb(); /* Keep memory order straight for RCU readers. */
+ /*
+* Keep memory order straight for RCU readers. Make
+* sure everything else is committed to memory before
+* setting intf_num to mark the interface valid.
+*/
+ smp_wmb();
intf->intf_num = i;
mutex_unlock(_interfaces_mutex);
+ /* After this point the interface is legal to use. */
call_smi_watchers(i, intf->si_dev);
mutex_unlock(_watchers_mutex);
}
@@ -3927,6 +3931,12 @@ static void send_panic_events(char *str)
/* Interface was not ready yet. */
continue;
+ /*
+* intf_num is used as an marker to tell if the
+* interface is valid. Thus we need a read barrier to
+* make sure data fetched before checking intf_num
+* won't be used.
+*/
smp_rmb();
/* First job here is to figure out where to send the
-
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: ata1: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 0x0) r0xj0
Andrew Lyon wrote: > Is there anything more I can do to assist? I plan to upgrade to > 2.6.19/latest at the weekend, let me know if there is anything more i > can do. WD740ADFD-00 is blacklisted for NCQ in .20-rcX kernels, so you won't see the problem anymore there. If you're gonna use 2.6.19, you probably wanna patch it. -- tejun - 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: ata1: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 0x0) r0xj0
bbee wrote: > Sorry, I thought you meant you would need to update it *further*. I > applied the patch you gave to Andrew with this result so far: > > $ dmesg | grep -A1 "spurious interrupt" > ata1: spurious interrupt (irq_stat 0x8 active_tag 0xfafbfcfd sactive 0x0) > ata1: issue=0x0 SAct=0x0 SDB_FIS=004040a1:0008 > -- > ata1: spurious interrupt (irq_stat 0x8 active_tag 0xfafbfcfd sactive 0x0) > ata1: issue=0x0 SAct=0x0 SDB_FIS=004040a1:0001 Ek... Your problem is similar too. > No luck yet triggering the exception. > > On Wed, 3 Jan 2007, Andrew Lyon wrote: >> Alan said he was going to add the drive to a blacklist he was >> maintaining for NCQ, perhaps that has been done in kernel 2.6.19, I >> dont know as I am still running 2.6.18. >> >> Perhaps the WD Raptor drive that I have does have lousy NCQ and that >> explains both the poor performance and the spurious interrupts. > > Blacklisting NCQ on the drive(s) for all controllers might be ill > advised, since it could be a JMicron-specific issue (or ahci-specific, > since the person in the thread I referenced had a different ahci > controller..). Either that, or both our drive models have "lousy NCQ".. If it turns out to be drive's fault, I'm afraid there's no other solution than blacklisting those drives on all controllers. It's protocol violation on drive's side, so I don't think there is an easy way out here except for firmware upgrade. I'm asking people about this, so please be patient. -- tejun - 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 + gcc 4.1 = several problems
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Linus Torvalds > Sent: 2007年1月4日 0:04 > To: Grzegorz Kulewski > Cc: Alan; Mikael Pettersson; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; > linux-kernel@vger.kernel.org; [EMAIL PROTECTED] > Subject: Re: kernel + gcc 4.1 = several problems > > > > On Wed, 3 Jan 2007, Grzegorz Kulewski wrote: > > > > Could you explain why CMOV is pointless now? Are there any benchmarks > > proving > > that? > > CMOV (and, more generically, any "predicated instruction") tends to > generally a bad idea on an aggressively out-of-order CPU. It doesn't > always have to be horrible, but in practice it is seldom very nice, and > (as usual) on the P4 it can be really quite bad. > > On a P4, I think a cmov basically takes 10 cycles. > > But even ignoring the usual P4 "I suck at things that aren't totally > normal", cmov is actually not a great idea. You can always replace it by > > j forward > mov ..., %reg > forward: > > and assuming the branch is AT ALL predictable (and 95+% of all branches > are), the branch-over will actually be a LOT better for a CPU. > > Why? Becuase branches can be predicted, and when they are predicted they > basically go away. They go away on many levels, too. Not just the branch > itself, but the _conditional_ for the branch goes away as far as the > critical path of code is concerned: the CPU still has to calculate it and > check it, but from a performance angle it "doesn't exist any more", > because it's not holding anything else up (well, you want to do it in > _some_ reasonable time, but the point stands..) > > Similarly, whichever side of the branch wasn't taken goes away. Again, in > an out-of-order machine with register renaming, this means that even if > the branch isn't taken above, and you end up executing all the non-branch > instructions, because you now UNCONDITIONALLY over-write the register, the > old data in the register is now DEAD, so now all the OTHER writes to that > register are off the critical path too! > > So the end result is that with a conditional branch, ona good CPU, the > _only_ part of the code that is actually performance-sensitive is the > actual calculation of the value that gets used! > > In contrast, if you use a predicated instruction, ALL of it is on the > critical path. Calculating the conditional is on the critical path. > Calculating the value that gets used is obviously ALSO on the critical > path, but so is the calculation for the value that DOESN'T get used too. > So the cmov - rather than speeding things up - actually slows things down, > because it makes more code be dependent on each other. > > So here's the basic rule: > > - cmov is sometimes nice for code density. It's not a big win, but it >certainly can be a win. > > - if you KNOW the branch is totally unpredictable, cmov is often good for >performance. But a compiler almost never knows that, and even if you >train it with input data and profiling, remember that not very many >branches _are_ totally unpredictable, so even if you were to know that >something is unpredictable, it's going to be very rare. > > - on a P4, branch mispredictions are expensive, but so is cmov, so all >the above is to some degree exaggerated. On nicer microarchitectures >(the Intel Core 2 in particular is something I have to say is very nice >indeed), the difference will be a lot less noticeable. The loss from >cmov isn't very big (it's not as sucky as P4), but neither is the win >(branch misprediction isn't that expensive either). > > Here's an example program that you can test and time yourself. > > On my Core 2, I get > > [EMAIL PROTECTED] ~]$ gcc -DCMOV -Wall -O2 t.c > [EMAIL PROTECTED] ~]$ time ./a.out > 6 > > real0m0.194s > user0m0.192s > sys 0m0.000s > > [EMAIL PROTECTED] ~]$ gcc -Wall -O2 t.c > [EMAIL PROTECTED] ~]$ time ./a.out > 6 > > real0m0.167s > user0m0.168s > sys 0m0.000s > > ie the cmov is quite a bit slower. Maybe I did something wrong. But note > how cmov not only is slower, it's fundamnetally more limited too (ie the > branch-over can actually do a lot of things cmov simply cannot do). Hi, cmov will stall on eflags in your test program. I think you will see benefit of cmov if you can manage to put some instructions which does NOT modify eflags between testl and cmov. Thanks Zou Nan hai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] proper prototype for x25_init_timers()
From: Adrian Bunk <[EMAIL PROTECTED]> Date: Thu, 4 Jan 2007 00:09:28 +0100 > This patch adds a proper prototype for x25_init_timers() in > include/net/x25.h > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> Applied, thanks Adrian. - 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.6.20-rc2] [BUGFIX] drivers/atm/firestream.c: Fix infinite recursion when alignment passed is 0.
From: Amit Choudhary <[EMAIL PROTECTED]> Date: Sat, 30 Dec 2006 18:26:03 -0800 > Description: Fix infinite recursion when alignment passed is 0 in function > aligned_kmalloc(), in file drivers/atm/firestream.c. Also, a negative value > for alignment does not make sense. Check for negative value too. > The function prototype is: > static void __devinit *aligned_kmalloc (int size, gfp_t flags, > int alignment). > > > Signed-off-by: Amit Choudhary <[EMAIL PROTECTED]> There is only one call to aligned_kmalloc() and it passes in 0x10 as the alignment argument. Therefore all of this checking is completely pointless. - 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] lock stat for -rt 2.6.20-rc2-rt2.2.lock_stat.patch
Bill Huey (hui) wrote:
> This should have the fix.
>
>
http://mmlinux.sf.net/public/patch-2.6.20-rc2-rt2.3.lock_stat.patch
>
> If you can rerun it and post the results, it'll hopefully show the
> behavior of that lock acquisition better.
>
Here's the run with fix to produce correct statistics.
Tim
@contention events = 848858
@failure_events = 10
@lookup_failed_scope = 175
@lookup_failed_static = 47
@static_found = 17
[2, 0, 0 -- 1, 0] {journal_init_common, fs/jbd/journal.c,
667}
[2, 0, 0 -- 31, 0] {blk_init_queue_node, block/ll_rw_blk.c,
1910}
[2, 0, 0 -- 31, 0] {create_workqueue_thread,
kernel/workqueue.c, 474}
[3, 3, 2 -- 16384, 0] {tcp_init, net/ipv4/tcp.c, 2426}
[4, 4, 1 -- 1, 0] {lock_kernel, -, 0}
[19, 0, 0 -- 1, 0] {kmem_cache_alloc, -, 0}
[25, 0, 0 -- 1, 0] {kfree, -, 0}
[49, 0, 0 -- 2, 0] {kmem_cache_free, -, 0}
[69, 38, 176 -- 1, 0] {lock_timer_base, -, 0}
[211, 117, 517 -- 3, 0] {init_timers_cpu, kernel/timer.c, 1842}
[1540, 778, 365 -- 7326, 0] {sock_lock_init,
net/core/sock.c, 817}
[112584, 150, 6 -- 256, 0] {init, kernel/futex.c, 2781}
[597012, 183895, 136277 -- 9546, 0] {mm_init, kernel/fork.c,
369}
-
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] Open Firmware device tree virtual filesystem
From: Segher Boessenkool <[EMAIL PROTECTED]> Date: Wed, 3 Jan 2007 16:23:53 +0100 > >>> therefore you can't let multiple CPUs call > >>> into OFW at one time. You must use some kind of locking mechanism, > >>> and that locking mechanism is not simple because it has to not just > >>> stop the other cpus, it has to be able to stop the other cpus yet > >>> still allow them to receive SMP cross-calls from the firmware if the > >>> OFW call is 'stop' or similar. > >> > >> YOu don't need to *stop* the other CPUs, you just need to > >> prevent them from entering the client interface. Put a lock > >> in front. > > > > That's not the issue. > > > > If the global OFW lock disables interrupts, > > Why would it? Because if a serial/keyboard/other-console-input-device interrupt arrives, from the user hitting the "BREAK" key sequence, you'll have to enter OBP from a hardware interrupt handler. Look, this thread is already tiring me, having to explain a lot of things and not making much useful progress. So I'll just be honest and say that I'll go work on other things which need my time and won't take part in this thread any more. Take care. - 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/
Initial Promise SX4 hw docs opened
The first open hardware docs for the Promise SX4 (sata_sx4) series are now available: http://gkernel.sourceforge.net/specs/promise/pdc20621-pguide-dimm-1.6.pdf.bz2 http://gkernel.sourceforge.net/specs/promise/pdc20621-pguide-pll-ata-timing-1.2.pdf.bz2 These are only small, ancillary guides; the main hardware doc should be opened soon. However, I would like to take this opportunity to point hackers looking for a project at this hardware. The Promise SX4 is pretty neat, and it needs more attention than I can give, to reach its full potential. Here's a braindump: * It's an older chipset/board, probably not actively sold anymore * ATA programming interface very close to sata_promise (PDC2037x) * Contains on-board DIMM, to be used for any purpose the driver desires * Contains on-board RAID5 XOR, also fully programmable A key problem is that, under Linux, sata_sx4 cannot fully exploit the RAID-centric power of this hardware by driving the hardware in "dumb ATA mode" as it does. A better driver would notice when a RAID1 or RAID5 array contains multiple components attached to the SX4, and send only a single copy of the data to the card (saving PCI bus bandwidth tremendously). Similarly, a better driver would take advantage of the RAID5 XOR offload capabilities, to offload the entire RAID5 read or write transaction to the card. All this is difficult within either the MD or DM RAID frameworks, because optimizing each RAID transaction requires intimate knowledge of the hardware. We have the knowledge... but I don't have good ideas -- aside from an SX4-specific RAID 0/1/5/6 driver -- on how to exploit this knowledge. Traditionally the vendor has distributed a SCSI driver that implements the necessary RAID stack pieces entirely in the hardware driver itself. That sort of approach definitely works, but is traditionally rejected by upstream maintainers because it essentially requires a third (if h/w specific) RAID stack. Jeff - 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/
S.M.A.R.T no longer available in 2.6.20-rc2-mm2 with libata
Not sure what went on between 2.6.19-rc5-mm2 and 2.6.20-rc2-mm2 in libata land but SMART is no longer available on my hdds. I'm assuming this is not the intended behavior. In case this is chipset specific, IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3) I'm using Libata nvidia driver, the drives happen to be sata drives, but even the pata ones no longer report having SMART. - 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: Why to I2c drivers not autoload like other PCI devices?
On Wed, 3 Jan 2007 16:56:00 -0800
Greg KH <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 03, 2007 at 04:50:20PM -0800, Stephen Hemminger wrote:
> > Is there some missing magic (udev rule?) that keeps i2c device modules
> > from loading? For example: the Intel i2c-i801 module ought to get loaded
> > automatically on boot up since it has a set of PCI id's that generate
> > the necessary module aliases. It would be better if I2C device's autoloaded
> > like other PCI devices.
>
> No, it should autoload, if it has a MODULE_DEVICE_TABLE() in it. In
> fact, the i2c-i801 autoloads on one of my machines just fine. Are you
> sure your pci ids match properly?
>
> thanks,
>
> greg k-h
This laptop is running Ubuntu Edgy (6.10) and it doesn't autoload.
Everything works fine if I manually load the module with modprobe.
This device should match:
00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 02)
00: 86 80 da 27 01 00 80 02 02 00 05 0c 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: a1 18 00 00 00 00 00 00 00 00 00 00 cf 10 88 13
30: 00 00 00 00 00 00 00 00 00 00 00 00 0b 02 00 00
This driver modinfo:
filename: /lib/modules/2.6.20-rc3/kernel/drivers/i2c/busses/i2c-i801.ko
author: Frodo Looijaard <[EMAIL PROTECTED]>, Philip Edelbrock <[EMAIL
PROTECTED]>, and Mark D. Studebaker <[EMAIL PROTECTED]>
description:I801 SMBus driver
license:GPL
vermagic: 2.6.20-rc3 mod_unload PENTIUMM 4KSTACKS
depends:i2c-core
alias: pci:v8086d2413sv*sd*bc*sc*i*
alias: pci:v8086d2423sv*sd*bc*sc*i*
alias: pci:v8086d2443sv*sd*bc*sc*i*
alias: pci:v8086d2483sv*sd*bc*sc*i*
alias: pci:v8086d24C3sv*sd*bc*sc*i*
alias: pci:v8086d24D3sv*sd*bc*sc*i*
alias: pci:v8086d25A4sv*sd*bc*sc*i*
alias: pci:v8086d266Asv*sd*bc*sc*i*
alias: pci:v8086d27DAsv*sd*bc*sc*i* <--- should match
alias: pci:v8086d269Bsv*sd*bc*sc*i*
alias: pci:v8086d283Esv*sd*bc*sc*i*
alias: pci:v8086d2930sv*sd*bc*sc*i*
Table in drivers/i2c/busses/i2c-i801.c
static struct pci_device_id i801_ids[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801AA_3) },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801AB_3) },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801BA_2) },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801CA_3) },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801DB_3) },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801EB_3) },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ESB_4) },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH6_16) },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH7_17) },
<-- should match
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ESB2_17) },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH8_5) },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH9_6) },
{ 0, }
};
MODULE_DEVICE_TABLE (pci, i801_ids);
--
Stephen Hemminger <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] lock stat for -rt 2.6.20-rc2-rt2.2.lock_stat.patch
On Wed, Jan 03, 2007 at 05:11:04PM -0800, Chen, Tim C wrote: > Bill Huey (hui) wrote: > > > > Thanks, the numbers look a bit weird in that the first column should > > have a bigger number of events than that second column since it is a > > special case subset. Looking at the lock_stat_note() code should show > > that to be the case. Did you make a change to the output ? > > No, I did not change the output. I did reset to the contention content > > by doing echo "0" > /proc/lock_stat/contention. > > I noticed that the first column get reset but not the second column. So > the reset code probably need to be checked. This should have the fix. http://mmlinux.sf.net/public/patch-2.6.20-rc2-rt2.3.lock_stat.patch If you can rerun it and post the results, it'll hopefully show the behavior of that lock acquisition better. Thanks bill - 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/
xfs_file_ioctl / xfs_freeze: BUG: warning at kernel/mutex-debug.c:80/debug_mutex_unlock()
just a simple test I did... xfs_freeze -f /mnt/newtest cp /etc/fstab /mnt/newtest xfs_freeze -u /mnt/newtest 2007-01-04 01:44:30.341979500 <4>BUG: warning at kernel/mutex-debug.c:80/debug_mutex_unlock() 2007-01-04 01:44:30.385771500 <4> [] dump_trace+0x215/0x21a 2007-01-04 01:44:30.385774500 <4> [] show_trace_log_lvl+0x1a/0x30 2007-01-04 01:44:30.385775500 <4> [] show_trace+0x12/0x14 2007-01-04 01:44:30.385777500 <4> [] dump_stack+0x19/0x1b 2007-01-04 01:44:30.385778500 <4> [] debug_mutex_unlock+0x69/0x120 2007-01-04 01:44:30.385779500 <4> [] __mutex_unlock_slowpath+0x44/0xf0 2007-01-04 01:44:30.385780500 <4> [] mutex_unlock+0x8/0xa 2007-01-04 01:44:30.385782500 <4> [] thaw_bdev+0x57/0x6e 2007-01-04 01:44:30.385791500 <4> [] xfs_ioctl+0x7ce/0x7d3 2007-01-04 01:44:30.385793500 <4> [] xfs_file_ioctl+0x33/0x54 2007-01-04 01:44:30.385794500 <4> [] do_ioctl+0x76/0x85 2007-01-04 01:44:30.385795500 <4> [] vfs_ioctl+0x59/0x1aa 2007-01-04 01:44:30.385796500 <4> [] sys_ioctl+0x67/0x77 2007-01-04 01:44:30.385797500 <4> [] syscall_call+0x7/0xb 2007-01-04 01:44:30.385799500 <4> [<001be410>] 0x1be410 2007-01-04 01:44:30.385800500 <4> === fstab was there just fine after -u. Linux 2.6.19.1 SMP on Pentium D. -- - 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] lock stat for -rt 2.6.20-rc2-rt2.2.lock_stat.patch
Bill Huey (hui) wrote: > > Thanks, the numbers look a bit weird in that the first column should > have a bigger number of events than that second column since it is a > special case subset. Looking at the lock_stat_note() code should show > that to be the case. Did you make a change to the output ? No, I did not change the output. I did reset to the contention content by doing echo "0" > /proc/lock_stat/contention. I noticed that the first column get reset but not the second column. So the reset code probably need to be checked. Tim - 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/
[2.6 patch] proper prototype for x25_init_timers()
This patch adds a proper prototype for x25_init_timers() in
include/net/x25.h
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
include/net/x25.h |1 +
net/x25/af_x25.c |2 --
2 files changed, 1 insertion(+), 2 deletions(-)
--- linux-2.6.20-rc2-mm1/include/net/x25.h.old 2007-01-03 22:57:52.0
+0100
+++ linux-2.6.20-rc2-mm1/include/net/x25.h 2007-01-03 22:58:17.0
+0100
@@ -259,6 +259,7 @@
extern void x25_disconnect(struct sock *, int, unsigned char, unsigned char);
/* x25_timer.c */
+extern void x25_init_timers(struct sock *sk);
extern void x25_start_heartbeat(struct sock *);
extern void x25_start_t2timer(struct sock *);
extern void x25_start_t21timer(struct sock *);
--- linux-2.6.20-rc2-mm1/net/x25/af_x25.c.old 2007-01-03 22:58:28.0
+0100
+++ linux-2.6.20-rc2-mm1/net/x25/af_x25.c 2007-01-03 22:58:35.0
+0100
@@ -484,8 +484,6 @@
return sk;
}
-void x25_init_timers(struct sock *sk);
-
static int x25_create(struct socket *sock, int protocol)
{
struct sock *sk;
-
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] lock stat for -rt 2.6.20-rc2-rt2.2.lock_stat.patch
On Wed, Jan 03, 2007 at 05:00:49PM -0800, Bill Huey wrote:
> On Wed, Jan 03, 2007 at 04:46:37PM -0800, Chen, Tim C wrote:
> > @contention events = 247149
> > @failure_events = 146
> > @lookup_failed_scope = 175
> > @lookup_failed_static = 43
> > @static_found = 16
> > [1, 113, 77 -- 32768, 0]{tcp_init, net/ipv4/tcp.c, 2426}
> > [2, 759, 182 -- 1, 0] {lock_kernel, -, 0}
> > [13, 0, 7 -- 4, 0] {kmem_cache_free, -, 0}
> > [25, 3564, 9278 -- 1, 0]{lock_timer_base, -, 0}
> > [56, 9528, 24552 -- 3, 0] {init_timers_cpu, kernel/timer.c, 1842}
> > [471, 52845, 17682 -- 10448, 0] {sock_lock_init, net/core/sock.c, 817}
> > [32251, 9024, 242 -- 256, 0]{init, kernel/futex.c, 2781}
> > [173724, 11899638, 9886960 -- 11194, 0] {mm_init, kernel/fork.c,
> > 369}
>
> Thanks, the numbers look a bit weird in that the first column should
> have a bigger number of events than that second column since it is a
> special case subset. Looking at the lock_stat_note() code should show
> that to be the case. Did you make a change to the output ?
>
> I can't tell which are "steal", actively running or overall contention
> stats against the lock from your output.
Also, the output is weird in that the "contention_events" should be
a total of all of the events in the first three columns. Clearly the
number is wrong and I don't know if the text output was mangled or
if that's accurate and my code is buggy. I have yet to see it give
me data like that yet in my set up.
The fourth and fifth columns are the number of times this lock was
initialized inline by a function like spin_lock_init(). It might
have a correspondence to clone() calls.
bill
-
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: ata1: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 0x0) r0xj0
On 1/3/07, bbee <[EMAIL PROTECTED]> wrote: On Wed, 3 Jan 2007, Tejun Heo wrote: > bbee wrote: >>> Yeap, I have major issues with SDB FISes which contains spurious >>> completions but most other spurious interrupts shouldn't be dangerous >>> and I haven't seen spurious completions for quite some time, so I was >>> thinking either removing the message or printing it only on SDB FIS >>> containing spurious completions. >>> >>> But, Andrew Lyon *is* reporting spurious completions. Now I just wanna >>> update those printks such that more info is reported only on spurious >>> SDB FISes. >> >> That would certainly help verify that I'm having the exact same problem, >> since Andrew didn't say anything about his drive going offline. > > Okay. Sorry, I thought you meant you would need to update it *further*. I applied the patch you gave to Andrew with this result so far: $ dmesg | grep -A1 "spurious interrupt" ata1: spurious interrupt (irq_stat 0x8 active_tag 0xfafbfcfd sactive 0x0) ata1: issue=0x0 SAct=0x0 SDB_FIS=004040a1:0008 -- ata1: spurious interrupt (irq_stat 0x8 active_tag 0xfafbfcfd sactive 0x0) ata1: issue=0x0 SAct=0x0 SDB_FIS=004040a1:0001 No luck yet triggering the exception. On Wed, 3 Jan 2007, Andrew Lyon wrote: > Alan said he was going to add the drive to a blacklist he was > maintaining for NCQ, perhaps that has been done in kernel 2.6.19, I > dont know as I am still running 2.6.18. > > Perhaps the WD Raptor drive that I have does have lousy NCQ and that > explains both the poor performance and the spurious interrupts. Blacklisting NCQ on the drive(s) for all controllers might be ill advised, since it could be a JMicron-specific issue (or ahci-specific, since the person in the thread I referenced had a different ahci controller..). Either that, or both our drive models have "lousy NCQ".. Thanks, bbee Is there anything more I can do to assist? I plan to upgrade to 2.6.19/latest at the weekend, let me know if there is anything more i can do. Andy - 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] lock stat for -rt 2.6.20-rc2-rt2.2.lock_stat.patch
On Wed, Jan 03, 2007 at 04:46:37PM -0800, Chen, Tim C wrote:
> Bill Huey (hui) wrote:
> > Can you sort the output ("sort -n" what ever..) and post it without
> > the zeroed entries ?
> >
> > I'm curious about how that statistical spike compares to the rest of
> > the system activity. I'm sure that'll get the attention of Peter as
> > well and maybe he'll do something about it ? :)
...
> @contention events = 247149
> @failure_events = 146
> @lookup_failed_scope = 175
> @lookup_failed_static = 43
> @static_found = 16
> [1, 113, 77 -- 32768, 0]{tcp_init, net/ipv4/tcp.c, 2426}
> [2, 759, 182 -- 1, 0] {lock_kernel, -, 0}
> [13, 0, 7 -- 4, 0]{kmem_cache_free, -, 0}
> [25, 3564, 9278 -- 1, 0]{lock_timer_base, -, 0}
> [56, 9528, 24552 -- 3, 0] {init_timers_cpu, kernel/timer.c, 1842}
> [471, 52845, 17682 -- 10448, 0] {sock_lock_init, net/core/sock.c, 817}
> [32251, 9024, 242 -- 256, 0]{init, kernel/futex.c, 2781}
> [173724, 11899638, 9886960 -- 11194, 0] {mm_init, kernel/fork.c, 369}
Thanks, the numbers look a bit weird in that the first column should
have a bigger number of events than that second column since it is a
special case subset. Looking at the lock_stat_note() code should show
that to be the case. Did you make a change to the output ?
I can't tell which are "steal", actively running or overall contention
stats against the lock from your output.
Thanks
bill
-
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: Why to I2c drivers not autoload like other PCI devices?
On Wed, Jan 03, 2007 at 04:50:20PM -0800, Stephen Hemminger wrote: > Is there some missing magic (udev rule?) that keeps i2c device modules > from loading? For example: the Intel i2c-i801 module ought to get loaded > automatically on boot up since it has a set of PCI id's that generate > the necessary module aliases. It would be better if I2C device's autoloaded > like other PCI devices. No, it should autoload, if it has a MODULE_DEVICE_TABLE() in it. In fact, the i2c-i801 autoloads on one of my machines just fine. Are you sure your pci ids match properly? thanks, greg k-h - 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/
Why to I2c drivers not autoload like other PCI devices?
Is there some missing magic (udev rule?) that keeps i2c device modules from loading? For example: the Intel i2c-i801 module ought to get loaded automatically on boot up since it has a set of PCI id's that generate the necessary module aliases. It would be better if I2C device's autoloaded like other PCI devices. -- Stephen Hemminger <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Simplify some code to use the container_of() macro.
On Sun, 31 Dec 2006 15:55:22 -0500 (EST)
"Robert P. J. Day" <[EMAIL PROTECTED]> wrote:
> --- a/net/ipv4/netfilter/nf_nat_core.c
> +++ b/net/ipv4/netfilter/nf_nat_core.c
> @@ -168,7 +168,7 @@ find_appropriate_src(const struct nf_conntrack_tuple
> *tuple,
>
> read_lock_bh(_nat_lock);
> list_for_each_entry(nat, [h], info.bysource) {
> - ct = (struct nf_conn *)((char *)nat - offsetof(struct nf_conn,
> data));
> + ct = container_of(nat, struct nf_conn, data);
This one isn't right. Please always carefully compile-test these things.
-
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: OT Coffee (was Re: Open letter to Linux kernel developers (was Re: Binary Drivers)
> On Tue, 02 Jan 2007 15:01:56 PST, David Schwartz said: > > There is simply no way you can argue that McDonald's failed to > > warn people > > about the risks. The cup says "hot" on it, > Actually, the "HOT" on the cup and the sticker in the drive-through that > says "Warning: Coffee is served very hot" were added after that lawsuit. Yes. And pretty much everyone agrees that these warnings serve no purpose. Everyone knows that hot coffee is served hot. What people probably don't know is that if you spill hot coffee on yourself and remain in contact with the coffee for more than about 45 seconds, a third-degree burn can result. This warning doesn't convey that information. I find it almost impossible to believe that anyone is going to alter their behavior in any significant way as a result of that warning. DS - 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] lock stat for -rt 2.6.20-rc2-rt2.2.lock_stat.patch
Bill Huey (hui) wrote:
> Can you sort the output ("sort -n" what ever..) and post it without
> the zeroed entries ?
>
> I'm curious about how that statistical spike compares to the rest of
> the system activity. I'm sure that'll get the attention of Peter as
> well and maybe he'll do something about it ? :)
>
Here's the lockstat trace. You can cross reference it with my
earlier post.
http://marc.theaimsgroup.com/?l=linux-kernel=116743637422465=2
The contention happened on mm->mmap_sem shared
by the java threads during futex_wake's invocation of _rt_down_read.
Tim
@contention events = 247149
@failure_events = 146
@lookup_failed_scope = 175
@lookup_failed_static = 43
@static_found = 16
[1, 113, 77 -- 32768, 0]{tcp_init, net/ipv4/tcp.c, 2426}
[2, 759, 182 -- 1, 0] {lock_kernel, -, 0}
[13, 0, 7 -- 4, 0] {kmem_cache_free, -, 0}
[25, 3564, 9278 -- 1, 0]{lock_timer_base, -, 0}
[56, 9528, 24552 -- 3, 0] {init_timers_cpu, kernel/timer.c,
1842}
[471, 52845, 17682 -- 10448, 0] {sock_lock_init, net/core/sock.c,
817}
[32251, 9024, 242 -- 256, 0]{init, kernel/futex.c, 2781}
[173724, 11899638, 9886960 -- 11194, 0] {mm_init, kernel/fork.c,
369}
-
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: [nfsv4] RE: Finding hardlinks
On Wed, 2007-01-03 at 14:35 +0200, Benny Halevy wrote: > Believe it or not, but server companies like Panasas try to follow the > standard > when designing and implementing their products while relying on client vendors > to do the same. I personally have never given a rats arse about "standards" if they make no sense to me. If the server is capable of knowing about hard links, then why does it need all this extra crap in the filehandle that just obfuscates the hard link info? The bottom line is that nothing in our implementation will result in such a server performing sub-optimally w.r.t. the client. The only result is that we will conform to close-to-open semantics instead of strict POSIX caching semantics when two processes have opened the same file via different hard links. > I sincerely expect you or anybody else for this matter to try to provide > feedback and object to the protocol specification in case they disagree > with it (or think it's ambiguous or self contradicting) rather than ignoring > it and implementing something else. I think we're shooting ourselves in the > foot when doing so and it is in our common interest to strive to reach a > realistic standard we can all comply with and interoperate with each other. This has nothing to do with the protocol itself: it has only to do with caching semantics. As far as caching goes, the only guarantees that NFS clients give are the close-to-open semantics, and this should indeed be respected by the implementation in question. 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: qconf: reproducible segfault
On 1/3/07, Bauke Jan Douma <[EMAIL PROTECTED]> wrote:
Not a big deal (I just discovered 'make gconfig'), but I'm experiencing
a reproducible segfault in 'make xconfig', i.e. qconf.
I was wondering if anyone else can reproduce this:
1. QTDIR=/usr/local/lib/qt make xconfig
mine by default has all qconf options OFF ('Show Name', 'Show Range',
'Show Data', 'Show All Options', 'Show Debug Info')
2. from the kernel options, select:
Networking / Networking options / Network packet filtering (replaces
ipchains)
3. from the qconf options, now select 'Show Debug Info'
voila -> segfault
This is with qt-3.3.3:
I can't reproduce it with FC6's current qt-devel in 2.6.20-rc3-git3...
but point 2 is in my tree
Networking / Networking options / Network packet filtering framework (Netfilter)
hmm, curious - let me download 2.6.19.1 and apply it... ok, now I see
your point 2, but I still can't reproduce the problem (Show Debug Info
does indeed show, well, debug information).
[EMAIL PROTECTED] ~]# rpm -q qt-devel
qt-devel-3.3.7-0.1.fc6
ldd /usr/src/linux-2.6.19.1/scripts/kconfig/qconf
linux-gate.so.1 => (0xe000)
libqt-mt.so.3 => /usr/local/lib/qt/lib/libqt-mt.so.3 (0xb76c2000)
libdl.so.2 => /lib/libdl.so.2 (0xb76ad000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb75c9000)
libm.so.6 => /lib/libm.so.6 (0xb75a4000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0xb7598000)
libc.so.6 => /lib/libc.so.6 (0xb746f000)
libpng.so.3 => /usr/local/lib/libpng.so.3 (0xb7449000)
libz.so.1 => /lib/libz.so.1 (0xb7435000)
libGL.so.1 => /usr/lib/libGL.so.1 (0xb73a9000)
libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0xb7393000)
libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0xb738b000)
libXrandr.so.2 => /usr/X11R6/lib/libXrandr.so.2 (0xb7387000)
libXcursor.so.1 => /usr/X11R6/lib/libXcursor.so.1 (0xb737e000)
libXinerama.so.1 => /usr/X11R6/lib/libXinerama.so.1 (0xb737b000)
libXft.so.2 => /usr/X11R6/lib/libXft.so.2 (0xb7369000)
libfreetype.so.6 => /usr/local/lib/libfreetype.so.6 (0xb72e4000)
libfontconfig.so.1 => /usr/local/lib/libfontconfig.so.1 (0xb72a6000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0xb7298000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0xb71cb000)
libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0xb71c2000)
libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0xb71aa000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb7192000)
/lib/ld-linux.so.2 (0xb7f1b000)
libGLcore.so.1 => /usr/lib/libGLcore.so.1 (0xb690c000)
libnvidia-tls.so.1 => /usr/lib/tls/libnvidia-tls.so.1 (0xb690a000)
libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0xb68b8000)
libexpat.so.0 => /usr/local/lib/libexpat.so.0 (0xb688c000)
libiconv.so.2 => /lib/libiconv.so.2 (0xb67b1000)
First I thought qconf window geometry and maybe font would make a
telling difference here, but I can resize the window all I want and
change fonts any which way I can, but the segfault persists.
I guess you'll have to try a more recent qt-devel version :)
FWIW, my initial geometry is 957x843, font is usually LuciduxSans 7.
Strace output didn't provide much of an apparent clue, just the
SIGSEGV.
Oh, kernel is 2.6.19.1 -- not important I'd say.
Thanks for your time.
Ciao,
--alessandro
"but I thought that I should let you know
the things that I don't always show
might not be worth the time it took"
(Steve Wynn, 'If My Life Was An Open Book')
-
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] lock stat for -rt 2.6.20-rc2-rt2.2.lock_stat.patch
On Wed, Jan 03, 2007 at 04:25:46PM -0800, Chen, Tim C wrote:
> Earlier I used latency_trace and figured that there was read contention
> on mm->mmap_sem during call to _rt_down_read by java threads
> when I was running volanomark. That caused the slowdown of the rt
> kernel
> compared to non-rt kernel. The output from lock_stat confirm
> that mm->map_sem was indeed the most heavily contended lock.
Can you sort the output ("sort -n" what ever..) and post it without the
zeroed entries ?
I'm curious about how that statistical spike compares to the rest of the
system activity. I'm sure that'll get the attention of Peter as well and
maybe he'll do something about it ? :)
bill
-
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: [UPDATED PATCH] fix memory corruption from misinterpreted bad_inode_ops return values
On Wed, 03 Jan 2007 17:46:00 -0600
Eric Sandeen <[EMAIL PROTECTED]> wrote:
> Take 2... all in one file. I suppose I really did know better than
> to create that new header. ;-)
>
> Better?
>
> ---
>
> CVE-2006-5753 is for a case where an inode can be marked bad, switching
> the ops to bad_inode_ops, which are all connected as:
>
> static int return_EIO(void)
> {
> return -EIO;
> }
>
> #define EIO_ERROR ((void *) (return_EIO))
>
> static struct inode_operations bad_inode_ops =
> {
> .create = bad_inode_create
> ...etc...
>
> The problem here is that the void cast causes return types to not be
> promoted, and for ops such as listxattr which expect more than 32 bits of
> return value, the 32-bit -EIO is interpreted as a large positive 64-bit
> number, i.e. 0xfffa instead of 0xfffa.
>
> This goes particularly badly when the return value is taken as a number of
> bytes to copy into, say, a user's buffer for example...
>
> I originally had coded up the fix by creating a return_EIO_ macro
> for each return type, like this:
>
> static int return_EIO_int(void)
> {
> return -EIO;
> }
> #define EIO_ERROR_INT ((void *) (return_EIO_int))
>
> static struct inode_operations bad_inode_ops =
> {
> .create = EIO_ERROR_INT,
> ...etc...
>
> but Al felt that it was probably better to create an EIO-returner for each
> actual op signature. Since so few ops share a signature, I just went ahead
> & created an EIO function for each individual file & inode op that returns
> a value.
>
Al is correct, of course. But the patch takes bad_inode.o from 280 up to 703
bytes, which is a bit sad for some cosmetic thing which nobody ever looks
at or modifies.
Perhaps you can do
static int return_EIO_int(void)
{
return -EIO;
}
static int bad_file_release(struct inode * inode, struct file * filp)
__attribute__((alias("return_EIO_int")));
static int bad_file_fsync(struct inode * inode, struct file * filp)
__attribute__((alias("return_EIO_int")));
etcetera?
-
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] lock stat for -rt 2.6.20-rc2-rt2.2.lock_stat.patch
Bill Huey (hui) wrote: > > Good to know that. What did the output reveal ? > > What's your intended use again summarized ? futex contention ? I'll > read the first posting again. > Earlier I used latency_trace and figured that there was read contention on mm->mmap_sem during call to _rt_down_read by java threads when I was running volanomark. That caused the slowdown of the rt kernel compared to non-rt kernel. The output from lock_stat confirm that mm->map_sem was indeed the most heavily contended lock. Tim - 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] sata_nv: add suspend/resume support v3 (Resubmit)
Thoughts from Jeff & company on merging the patch below into libata-dev?
This has been in the -mm tree for over a month now, I haven't heard any
complaints about regressions..
---
From: Robert Hancock <[EMAIL PROTECTED]>
This patch adds the necessary callbacks to support suspend/resume properly
in sata_nv. Most of the controllers don't need any specific handling but
CK804/MCP04 controllers, whether ADMA is enabled or not, need some
additional setup on resume.
As well as the additional storage of the controller type needed for proper
resume handling, this also removes the inline helper functions for getting
ADMA register locations by storing the pointers so we don't have to keep
calculating them all the time.
Signed-off-by: Robert Hancock <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/ata/sata_nv.c | 225
1 file changed, 161 insertions(+), 64 deletions(-)
diff -puN drivers/ata/sata_nv.c~sata_nv-add-suspend-resume-support
drivers/ata/sata_nv.c
--- a/drivers/ata/sata_nv.c~sata_nv-add-suspend-resume-support
+++ a/drivers/ata/sata_nv.c
@@ -49,7 +49,7 @@
#include
#define DRV_NAME"sata_nv"
-#define DRV_VERSION"3.2"
+#define DRV_VERSION"3.3"
#define NV_ADMA_DMA_BOUNDARY0xUL
@@ -213,12 +213,21 @@ struct nv_adma_port_priv {
dma_addr_t cpb_dma;
struct nv_adma_prd *aprd;
dma_addr_t aprd_dma;
+ void __iomem * ctl_block;
+ void __iomem * gen_block;
+ void __iomem * notifier_clear_block;
u8 flags;
};
+struct nv_host_priv {
+ unsigned long type;
+};
+
#define NV_ADMA_CHECK_INTR(GCTL, PORT) ((GCTL) & ( 1 << (19 + (12 * (PORT)
static int nv_init_one (struct pci_dev *pdev, const struct pci_device_id *ent);
+static void nv_remove_one (struct pci_dev *pdev);
+static int nv_pci_device_resume(struct pci_dev *pdev);
static void nv_ck804_host_stop(struct ata_host *host);
static irqreturn_t nv_generic_interrupt(int irq, void *dev_instance);
static irqreturn_t nv_nf2_interrupt(int irq, void *dev_instance);
@@ -239,6 +248,8 @@ static irqreturn_t nv_adma_interrupt(int
static void nv_adma_irq_clear(struct ata_port *ap);
static int nv_adma_port_start(struct ata_port *ap);
static void nv_adma_port_stop(struct ata_port *ap);
+static int nv_adma_port_suspend(struct ata_port *ap, pm_message_t mesg);
+static int nv_adma_port_resume(struct ata_port *ap);
static void nv_adma_error_handler(struct ata_port *ap);
static void nv_adma_host_stop(struct ata_host *host);
static void nv_adma_bmdma_setup(struct ata_queued_cmd *qc);
@@ -284,7 +295,9 @@ static struct pci_driver nv_pci_driver =
.name = DRV_NAME,
.id_table = nv_pci_tbl,
.probe = nv_init_one,
- .remove = ata_pci_remove_one,
+ .suspend= ata_pci_device_suspend,
+ .resume = nv_pci_device_resume,
+ .remove = nv_remove_one,
};
static struct scsi_host_template nv_sht = {
@@ -303,6 +316,8 @@ static struct scsi_host_template nv_sht
.slave_configure = ata_scsi_slave_config,
.slave_destroy = ata_scsi_slave_destroy,
.bios_param = ata_std_bios_param,
+ .suspend= ata_scsi_device_suspend,
+ .resume = ata_scsi_device_resume,
};
static struct scsi_host_template nv_adma_sht = {
@@ -321,6 +336,8 @@ static struct scsi_host_template nv_adma
.slave_configure= nv_adma_slave_config,
.slave_destroy = ata_scsi_slave_destroy,
.bios_param = ata_std_bios_param,
+ .suspend= ata_scsi_device_suspend,
+ .resume = ata_scsi_device_resume,
};
static const struct ata_port_operations nv_generic_ops = {
@@ -429,6 +446,8 @@ static const struct ata_port_operations
.scr_write = nv_scr_write,
.port_start = nv_adma_port_start,
.port_stop = nv_adma_port_stop,
+ .port_suspend = nv_adma_port_suspend,
+ .port_resume= nv_adma_port_resume,
.host_stop = nv_adma_host_stop,
};
@@ -467,6 +486,7 @@ static struct ata_port_info nv_port_info
{
.sht= _adma_sht,
.flags = ATA_FLAG_SATA | ATA_FLAG_NO_LEGACY |
+ ATA_FLAG_HRST_TO_RESUME |
ATA_FLAG_MMIO | ATA_FLAG_NCQ,
.pio_mask = NV_PIO_MASK,
.mwdma_mask = NV_MWDMA_MASK,
@@ -483,32 +503,10 @@ MODULE_VERSION(DRV_VERSION);
static int adma_enabled = 1;
-static inline void __iomem *__nv_adma_ctl_block(void __iomem *mmio,
- unsigned int
Re: [PATCH] lock stat for -rt 2.6.20-rc2-rt2.2.lock_stat.patch
On Wed, Jan 03, 2007 at 03:59:28PM -0800, Chen, Tim C wrote: > Bill Huey (hui) wrote: > http://mmlinux.sourceforge.net/public/patch-2.6.20-rc2-rt2.2.lock_stat.patch > > This version is much better and ran stablely. > > If I'm reading the output correctly, the locks are listed by > their initialization point (function, file and line # that a lock is > initialized). > That's good information to identify the lock. Yes, that's correct. Good to know that. What did the output reveal ? It can be extended by pid/futex for userspace app that has yet to be done. It might require changes to glibc or a some kind of dynamic tracing to communicate to kernel space information about that lock. There are other kernel uses as well. It's just a basic mechanisms for a variety of uses. This patch has some LTT and Dtrace-isms to it. What's your intended use again summarized ? futex contention ? I'll read the first posting again. > However, it will be more useful if there is information about where the > locking > was initiated from and who was trying to obtain the lock. It would add quite a bit more overhead, but it could be done with lockdep directly I believe in conjunction with this patch. However, it should be specific enough though that a kernel code examination at the key points of all users of the lock would show where the problem places are as well as users. bill - 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: Finding hardlinks
On Thu, Jan 04, 2007 at 12:43:20AM +0100, Mikulas Patocka wrote:
> On Wed, 3 Jan 2007, Frank van Maarseveen wrote:
> >Currently, large file support is already necessary to handle dvd and
> >video. It's also useful for images for virtualization. So the failing
> >stat()
> >calls should already be a thing of the past with modern distributions.
>
> As long as glibc compiles by default with 32-bit ino_t, the problem exists
> and is severe --- programs handling large files, such as coreutils, tar,
> mc, mplayer, already compile with 64-bit ino_t and off_t, but the user (or
> script) may type something like:
>
> cat >file.c < #include
> #include
> main()
> {
> int h;
> struct stat st;
> if ((h = creat("foo", 0600)) < 0) perror("creat"), exit(1);
> if (fstat(h, )) perror("stat"), exit(1);
> close(h);
> return 0;
> }
> EOF
> gcc file.c; ./a.out
>
> --- and you certainly do not want this to fail (unless you are out of disk
> space).
>
> The difference is, that with 32-bit program and 64-bit off_t, you get
> deterministic failure on large files, with 32-bit program and 64-bit
> ino_t, you get random failures.
What's (technically) the problem with changing the gcc default?
Alternatively we could make the error deterministic in various ways. Start
st_ino numbering from 4G (except for a few special ones maybe such
as root/mounts). Or make old and new programs look differently at the
ELF level or by sys_personality() and/or check against a "ino64" mount
flag/filesystem feature. Lots of possibilities.
--
Frank
-
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] lock stat for -rt 2.6.20-rc2-rt2.2.lock_stat.patch
Bill Huey (hui) wrote: > > Patch here: > > http://mmlinux.sourceforge.net/public/patch-2.6.20-rc2-rt2.2.lock_stat.p atch > > bill This version is much better and ran stablely. If I'm reading the output correctly, the locks are listed by their initialization point (function, file and line # that a lock is initialized). That's good information to identify the lock. However, it will be more useful if there is information about where the locking was initiated from and who was trying to obtain the lock. Tim - 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/2] EDAC: e752x-bit-mask-fix
On Tue, 2 Jan 2007 16:13:36 -0800 (PST) Doug Thompson wrote: > from: Brian Pomerantz <[EMAIL PROTECTED]> > > Description: > The fatal vs. non-fatal mask for the sysbus FERR status is > incorrect > according to the E7520 datasheet. This patch corrects the mask to > correctly > handle fatal and non-fatal errors. > > Signed-off-by: Brian Pomerantz <[EMAIL PROTECTED]> > Signed-off-by: Dave Jiang <[EMAIL PROTECTED]> > Signed-off-by: Doug Thompson <[EMAIL PROTECTED]> > > e752x_edac.c | 16 > 1 file changed, 8 insertions(+), 8 deletions(-) > > Index: linux-2.6.18/drivers/edac/e752x_edac.c > === > --- linux-2.6.18.orig/drivers/edac/e752x_edac.c > +++ linux-2.6.18/drivers/edac/e752x_edac.c > @@ -561,17 +561,17 @@ static void e752x_check_sysbus(struct e7 > error32 = (stat32 >> 16) & 0x3ff; > stat32 = stat32 & 0x3ff; > > - if(stat32 & 0x083) > - sysbus_error(1, stat32 & 0x083, error_found, handle_error); > + if(stat32 & 0x087) > + sysbus_error(1, stat32 & 0x087, error_found, handle_error); > > - if(stat32 & 0x37c) > - sysbus_error(0, stat32 & 0x37c, error_found, handle_error); > + if(stat32 & 0x378) > + sysbus_error(0, stat32 & 0x378, error_found, handle_error); > > - if(error32 & 0x083) > - sysbus_error(1, error32 & 0x083, error_found, handle_error); > + if(error32 & 0x087) > + sysbus_error(1, error32 & 0x087, error_found, handle_error); > > - if(error32 & 0x37c) > - sysbus_error(0, error32 & 0x37c, error_found, handle_error); > + if(error32 & 0x378) > + sysbus_error(0, error32 & 0x378, error_found, handle_error); > } if ( Are these bit masks documented somewhere? You could make that almost readable by using some #defines for them. --- ~Randy - 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/
[UPDATED PATCH] fix memory corruption from misinterpreted bad_inode_ops return values
Take 2... all in one file. I suppose I really did know better than
to create that new header. ;-)
Better?
---
CVE-2006-5753 is for a case where an inode can be marked bad, switching
the ops to bad_inode_ops, which are all connected as:
static int return_EIO(void)
{
return -EIO;
}
#define EIO_ERROR ((void *) (return_EIO))
static struct inode_operations bad_inode_ops =
{
.create = bad_inode_create
...etc...
The problem here is that the void cast causes return types to not be
promoted, and for ops such as listxattr which expect more than 32 bits of
return value, the 32-bit -EIO is interpreted as a large positive 64-bit
number, i.e. 0xfffa instead of 0xfffa.
This goes particularly badly when the return value is taken as a number of
bytes to copy into, say, a user's buffer for example...
I originally had coded up the fix by creating a return_EIO_ macro
for each return type, like this:
static int return_EIO_int(void)
{
return -EIO;
}
#define EIO_ERROR_INT ((void *) (return_EIO_int))
static struct inode_operations bad_inode_ops =
{
.create = EIO_ERROR_INT,
...etc...
but Al felt that it was probably better to create an EIO-returner for each
actual op signature. Since so few ops share a signature, I just went ahead
& created an EIO function for each individual file & inode op that returns
a value.
Thanks,
-Eric
Signed-off-by: Eric Sandeen <[EMAIL PROTECTED]>
Index: linux-2.6.19/fs/bad_inode.c
===
--- linux-2.6.19.orig/fs/bad_inode.c
+++ linux-2.6.19/fs/bad_inode.c
@@ -14,59 +14,308 @@
#include
#include
#include
+#include
-static int return_EIO(void)
+
+static loff_t bad_file_llseek(struct file *file, loff_t offset, int origin)
+{
+ return -EIO;
+}
+
+static ssize_t bad_file_read(struct file *filp, char __user *buf,
+ size_t size, loff_t *ppos)
+{
+return -EIO;
+}
+
+static ssize_t bad_file_write(struct file *filp, const char __user *buf,
+ size_t siz, loff_t *ppos)
+{
+return -EIO;
+}
+
+static ssize_t bad_file_aio_read(struct kiocb *iocb, const struct iovec *iov,
+ unsigned long nr_segs, loff_t pos)
+{
+ return -EIO;
+}
+
+static ssize_t bad_file_aio_write(struct kiocb *iocb, const struct iovec *iov,
+ unsigned long nr_segs, loff_t pos)
+{
+ return -EIO;
+}
+
+static int bad_file_readdir(struct file * filp, void * dirent,
+ filldir_t filldir)
+{
+ return -EIO;
+}
+
+static unsigned int bad_file_poll(struct file *filp, poll_table *wait)
+{
+ return -EIO;
+}
+
+static int bad_file_ioctl (struct inode * inode, struct file * filp,
+ unsigned int cmd, unsigned long arg)
{
return -EIO;
}
-#define EIO_ERROR ((void *) (return_EIO))
+static long bad_file_unlocked_ioctl(struct file *file, unsigned cmd,
+ unsigned long arg)
+{
+ return -EIO;
+}
+
+static long bad_file_compat_ioctl(struct file *file, unsigned int cmd,
+ unsigned long arg)
+{
+ return -EIO;
+}
+
+static int bad_file_mmap(struct file * file, struct vm_area_struct * vma)
+{
+ return -EIO;
+}
+
+static int bad_file_open(struct inode * inode, struct file * filp)
+{
+ return -EIO;
+}
+
+static int bad_file_flush(struct file *file, fl_owner_t id)
+{
+ return -EIO;
+}
+
+static int bad_file_release(struct inode * inode, struct file * filp)
+{
+ return -EIO;
+}
+
+static int bad_file_fsync(struct file * file, struct dentry *dentry,
+ int datasync)
+{
+ return -EIO;
+}
+
+static int bad_file_aio_fsync(struct kiocb *iocb, int datasync)
+{
+ return -EIO;
+}
+
+static int bad_file_fasync(int fd, struct file *filp, int on)
+{
+ return -EIO;
+}
+
+static int bad_file_lock(struct file *file, int cmd, struct file_lock *fl)
+{
+ return -EIO;
+}
+
+static ssize_t bad_file_sendfile(struct file *in_file, loff_t *ppos,
+ size_t count, read_actor_t actor, void *target)
+{
+ return -EIO;
+}
+
+static ssize_t bad_file_sendpage(struct file *file, struct page *page,
+ int off, size_t len, loff_t *pos, int more)
+{
+ return -EIO;
+}
+
+static unsigned long bad_file_get_unmapped_area(struct file *file,
+ unsigned long addr, unsigned long len,
+ unsigned long pgoff, unsigned long flags)
+{
+ return -EIO;
+}
+
+static int bad_file_check_flags(int flags)
+{
+ return -EIO;
+}
+
+static int bad_file_dir_notify(struct file * file, unsigned long arg)
+{
+ return -EIO;
+}
+
+static int bad_file_flock(struct file *filp, int cmd, struct file_lock *fl)
+{
+ return -EIO;
+}
+
+static ssize_t bad_file_splice_write(struct pipe_inode_info *pipe,
+ struct file *out, loff_t
Re: Finding hardlinks
On Wed, 3 Jan 2007, Frank van Maarseveen wrote:
On Wed, Jan 03, 2007 at 01:09:41PM -0800, Bryan Henderson wrote:
On any decent filesystem st_ino should uniquely identify an object and
reliably provide hardlink information. The UNIX world has relied upon
this
for decades. A filesystem with st_ino collisions without being hardlinked
(or the other way around) needs a fix.
But for at least the last of those decades, filesystems that could not do
that were not uncommon. They had to present 32 bit inode numbers and
either allowed more than 4G files or just didn't have the means of
assigning inode numbers with the proper uniqueness to files. And the sky
did not fall. I don't have an explanation why,
I think it's mostly high end use and high end users tend to understand
more. But we're going to see more really large filesystems in "normal"
use so..
Currently, large file support is already necessary to handle dvd and
video. It's also useful for images for virtualization. So the failing stat()
calls should already be a thing of the past with modern distributions.
As long as glibc compiles by default with 32-bit ino_t, the problem exists
and is severe --- programs handling large files, such as coreutils, tar,
mc, mplayer, already compile with 64-bit ino_t and off_t, but the user (or
script) may type something like:
cat >file.c <
#include
main()
{
int h;
struct stat st;
if ((h = creat("foo", 0600)) < 0) perror("creat"), exit(1);
if (fstat(h, )) perror("stat"), exit(1);
close(h);
return 0;
}
EOF
gcc file.c; ./a.out
--- and you certainly do not want this to fail (unless you are out of disk
space).
The difference is, that with 32-bit program and 64-bit off_t, you get
deterministic failure on large files, with 32-bit program and 64-bit
ino_t, you get random failures.
Mikulas
-
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: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping related bug?!
Christoph Anton Mitterer wrote: Hi. Perhaps some of you have read my older two threads: http://marc.theaimsgroup.com/?t=11631244001=1=2 and the even older http://marc.theaimsgroup.com/?t=11629131451=1=2 The issue was basically the following: I found a severe bug mainly by fortune because it occurs very rarely. My test looks like the following: I have about 30GB of testing data on my harddisk,... I repeat verifying sha512 sums on these files and check if errors occur. One test pass verifies the 30GB 50 times,... about one to four differences are found in each pass. The corrupted data is not one single completely wrong block of data or so,.. but if you look at the area of the file where differences are found,.. than some bytes are ok,.. some are wrong,.. and so on (seems to be randomly). Also, there seems to be no event that triggers the corruption,.. it seems to be randomly, too. It is really definitely not a harware issue (see my old threads my emails to Tyan/Hitachi and my "workaround" below. My system isn't overclocked. My System: Mainboard: Tyan S2895 Chipsets: Nvidia nforce professional 2200 and 2050 and AMD 8131 CPU: 2x DualCore Opterons model 275 RAM: 4GB Kingston Registered/ECC Diskdrives: IBM/Hitachi: 1 PATA, 2 SATA The data corruption error occurs on all drives. You might have a look at the emails between me and Tyan and Hitachi,.. they contain probalby lots of valuable information (especially my different tests). Some days ago,.. an engineer of Tyan suggested me to boot the kernel with mem=3072M. When doing this,.. the issue did not occur (I don't want to say it was solved. Why? See my last emails to Tyan!) Then he suggested me to disable the memory hole mapping in the BIOS,... When doing so,.. the error doesn't occur, too. But I loose about 2GB RAM,.. and,.. more important,.. I cant believe that this is responsible for the whole issue. I don't consider it a solution but more a poor workaround which perhaps only by fortune solves the issue (Why? See my last eMails to Tyan ;) ) So I'd like to ask you if you perhaps could read the current information in this and previous mails,.. and tell me your opinions. It is very likely that a large number of users suffer from this error (namely all Nvidia chipset users) but only few (there are some,.. I found most of them in the Nvidia forums,.. and they have exactly the same issue) identify this as an error because it's so rare. Perhaps someone have an idea why disabling the memhole mapping solves it. I've always thought that memhole mapping just moves some address space to higher addreses to avoid the conflict between address space for PCI devices and address space for pyhsical memory. But this should be just a simple addition and not solve this obviously complex error. If this is related to some problem with using the GART IOMMU with memory hole remapping enabled, then 2.6.20-rc kernels may avoid this problem on nForce4 CK804/MCP04 chipsets as far as transfers to/from the SATA controller are concerned as the sata_nv driver now supports 64-bit DMA on these chipsets and so no longer requires the IOMMU. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - 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] tipc: checking returns and Re: Possible Circular Locking in TIPC
See my comments below.
Regards
///jon
Jarek Poplawski wrote:
..
Maybe I misinterpret this but, IMHO lockdep
complains about locks acquired in different
order: tipc_ref_acquire() gets ref_table_lock
and then tipc_ret_table.entries[index]->lock,
but tipc_deleteport() inversely (with:
tipc_port_lock() and tipc_ref_discard()).
I hope maintainers will decide the correct
order.
This order is correct. There can never be parallel access to the
same _instance_ of tipc_ret_table.entries[index]->lock from
the two functions you mention.
Note that tipc_deleteport() takes as argument the reference (=index)
returned from tipc_ref_acquire(), so it can not be (and is not) called
until and unless the latter function has returned a valid reference.
As a parallel, you can't do free() on a memory chunk until
malloc() has given you a pointer to it.
Btw. there is a problem with tipc_ref_discard():
it should be called with tipc_port_lock, but
how to discard a ref if this lock can't be
acquired? Is it OK to call it without the lock
like in subscr_named_msg_event()?
I suspect you are mixing up things here.
We are handling two different reference entries and two
different locks in this function.
One reference entry points to a subscription instance, and its
reference (index) is obtainable from subscriber->ref. So, we
could easily lock the entry if needed. However, in this
particular case it is unnecessary, since there is no chance that
anybody else could have obtained the new reference, and
hence no risk for race conditions.
The other reference entry was intended to point to a new port,
but, since we didn't obtain any reference in the first place,
there is no port to delete and no reference to discard.
Btw. #2: during this checking I've found
two places where return values from
tipc_ref_lock() and tipc_port_lock() are not
checked, so I attach a patch proposal for
this (compiled but not tested):
Thanks.
Regards,
Jarek P.
---
[PATCH] tipc: checking returns from locking functions
Checking of return values from tipc_ref_lock()
and tipc_port_lock() added in 2 places.
Signed-off-by: Jarek Poplawski <[EMAIL PROTECTED]>
---
diff -Nurp linux-2.6.20-rc2-/net/tipc/port.c linux-2.6.20-rc2/net/tipc/port.c
--- linux-2.6.20-rc2-/net/tipc/port.c 2006-11-29 22:57:37.0 +0100
+++ linux-2.6.20-rc2/net/tipc/port.c2006-12-28 11:05:17.0 +0100
@@ -238,7 +238,12 @@ u32 tipc_createport_raw(void *usr_handle
return 0;
}
- tipc_port_lock(ref);
+ if (!tipc_port_lock(ref)) {
+ tipc_ref_discard(ref);
+ warn("Port creation failed, reference table invalid\n");
+ kfree(p_ptr);
+ return 0;
+ }
p_ptr->publ.ref = ref;
msg = _ptr->publ.phdr;
msg_init(msg, DATA_LOW, TIPC_NAMED_MSG, TIPC_OK, LONG_H_SIZE, 0);
diff -Nurp linux-2.6.20-rc2-/net/tipc/subscr.c
linux-2.6.20-rc2/net/tipc/subscr.c
--- linux-2.6.20-rc2-/net/tipc/subscr.c 2006-12-18 09:01:04.0 +0100
+++ linux-2.6.20-rc2/net/tipc/subscr.c 2006-12-28 11:31:27.0 +0100
@@ -499,7 +499,12 @@ static void subscr_named_msg_event(void
/* Add subscriber to topology server's subscriber list */
- tipc_ref_lock(subscriber->ref);
+ if (!tipc_ref_lock(subscriber->ref)) {
+ warn("Subscriber rejected, unable to find port\n");
+ tipc_ref_discard(subscriber->ref);
+ kfree(subscriber);
+ return;
+ }
spin_lock_bh();
list_add(>subscriber_list, _list);
spin_unlock_bh();
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.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] fix memory corruption from misinterpreted bad_inode_ops return values
Stephen Rothwell wrote: > Hi Eric, > > On Wed, 03 Jan 2007 12:42:47 -0600 Eric Sandeen <[EMAIL PROTECTED]> wrote: >> So here's the first stab at fixing it. I'm sure there are style points >> to be hashed out. Putting all the functions as static inlines in a header >> was just to avoid hundreds of lines of simple function declarations before >> we get to the meat of bad_inode.c, but it's probably technically wrong to >> put it in a header. Also if putting a copyright on that trivial header file >> is going overboard, just let me know. Or if anyone has a less verbose >> but still correct way to address this problem, I'm all ears. > > Since the only uses of these functions is to take their addresses, the > inline gains you nothing Hm, yes of course... my fingers just automatically type "static inline" in header files I guess. :) > and since the only uses are in the one file, you > should just define them in that file. Ok, will do. That seems to be the consensus. Thanks, -Eric - 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] fix memory corruption from misinterpreted bad_inode_ops return values
Hi Eric, On Wed, 03 Jan 2007 12:42:47 -0600 Eric Sandeen <[EMAIL PROTECTED]> wrote: > > So here's the first stab at fixing it. I'm sure there are style points > to be hashed out. Putting all the functions as static inlines in a header > was just to avoid hundreds of lines of simple function declarations before > we get to the meat of bad_inode.c, but it's probably technically wrong to > put it in a header. Also if putting a copyright on that trivial header file > is going overboard, just let me know. Or if anyone has a less verbose > but still correct way to address this problem, I'm all ears. Since the only uses of these functions is to take their addresses, the inline gains you nothing and since the only uses are in the one file, you should just define them in that file. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpWcClvqMma1.pgp Description: PGP signature
Re: [patch 2.6.19-git] rts-rs5c372 updates: more chips, alarm, 12hr mode, etc
Hi David,
> Yes, the patch you sent (switching to "method 3" to work around the
> evident bug in the i2c-ixp3xx driver) works on the platform I was
> using too (after unrelated tweaks).
> Here's an updated patch, using "method 3". If it still behaves
> for you, it'd seem ready to merge...
Works fine, thanks! Unfortunately the i2c-ixp3xx issue has not advanced in
the meantime, so we still need the third method.
> CUT HERE
> Update the rtc-rs5c372 driver:
>
> Bugfixes:
> - Handle RTCs which are configured to use 12-hour mode.
> - Never report bogus/un-initialized times.
> - Displaying "raw trim" requires not masking it first!
> - Fix the and sysfs procfs display of crystal and trim data.
>
> Features:
> - Handle other RTCs in this family, notably rv5c386/rv5c387.
> - Declare the other registers.
> - Provide alarm get/set functionality.
> - Handle AIE and UIE; but no IRQ handling yet.
> - Warn if the clock needs to be set.
>
> Cleanup:
> - Shrink object by not including needless sysfs or procfs support
> - We don't need no steenkin' forward declarations. (Except one.)
>
> Until the I2C framework merges "new style" driver support, matching
> the driver model better, using rv5c chips or alarm IRQs requires a
> separate board-specific patch. (And an IRQ handler, handing off labor
> through a work_struct...)
>
> This uses the "method 3" register reads, but notes that it's done
> to work around an evident i2c adapter driver bug, and the curious
> issue where the chip behavior disagrees with the chip docs.
>
> Signed-off-by: David Brownell <[EMAIL PROTECTED]>
>
> Index: g26/drivers/rtc/rtc-rs5c372.c
> ===
> --- g26.orig/drivers/rtc/rtc-rs5c372.c2006-12-27 17:19:55.0
> -0800
> +++ g26/drivers/rtc/rtc-rs5c372.c 2007-01-02 18:44:35.0 -0800
> @@ -1,5 +1,5 @@
> /*
> - * An I2C driver for the Ricoh RS5C372 RTC
> + * An I2C driver for Ricoh RS5C372 and RV5C38[67] RTCs
> *
> * Copyright (C) 2005 Pavel Mironchik <[EMAIL PROTECTED]>
> * Copyright (C) 2006 Tower Technologies
> @@ -13,7 +13,7 @@
> #include
> #include
>
> -#define DRV_VERSION "0.3"
> +#define DRV_VERSION "0.4"
>
> /* Addresses to scan */
> static unsigned short normal_i2c[] = { /* 0x32,*/ I2C_CLIENT_END };
> @@ -21,6 +21,13 @@ static unsigned short normal_i2c[] = { /
> /* Insmod parameters */
> I2C_CLIENT_INSMOD;
>
> +
> +/*
> + * Ricoh has a family of I2C based RTCs, which differ only slightly from
> + * each other. Differences center on pinout (e.g. how many interrupts,
> + * output clock, etc) and how the control registers are used. The '372
> + * is significant only because that's the one this driver first
> supported.
> + */
> #define RS5C372_REG_SECS 0
> #define RS5C372_REG_MINS 1
> #define RS5C372_REG_HOURS2
> @@ -29,59 +36,142 @@ I2C_CLIENT_INSMOD;
> #define RS5C372_REG_MONTH5
> #define RS5C372_REG_YEAR 6
> #define RS5C372_REG_TRIM 7
> +#define RS5C372_TRIM_XSL 0x80
> +#define RS5C372_TRIM_MASK0x7F
>
> -#define RS5C372_TRIM_XSL 0x80
> -#define RS5C372_TRIM_MASK0x7F
> -
> -#define RS5C372_REG_BASE 0
> -
> -static int rs5c372_attach(struct i2c_adapter *adapter);
> -static int rs5c372_detach(struct i2c_client *client);
> -static int rs5c372_probe(struct i2c_adapter *adapter, int address, int
> kind);
> +#define RS5C_REG_ALARM_A_MIN 8 /* or ALARM_W */
> +#define RS5C_REG_ALARM_A_HOURS 9
> +#define RS5C_REG_ALARM_A_WDAY10
> +
> +#define RS5C_REG_ALARM_B_MIN 11 /* or ALARM_D */
> +#define RS5C_REG_ALARM_B_HOURS 12
> +#define RS5C_REG_ALARM_B_WDAY13 /* (ALARM_B
> only) */
> +
> +#define RS5C_REG_CTRL1 14
> +#define RS5C_CTRL1_AALE (1 << 7)/* or WALE */
> +#define RS5C_CTRL1_BALE (1 << 6)/* or DALE */
> +#define RV5C387_CTRL1_24 (1 << 5)
> +#define RS5C372A_CTRL1_SL1 (1 << 5)
> +#define RS5C_CTRL1_CT_MASK (7 << 0)
> +#define RS5C_CTRL1_CT0 (0 << 0)/* no periodic irq */
> +#define RS5C_CTRL1_CT4 (4 << 0)/* 1 Hz level irq */
> +#define RS5C_REG_CTRL2 15
> +#define RS5C372_CTRL2_24 (1 << 5)
> +#define RS5C_CTRL2_XSTP (1 << 4)
> +#define RS5C_CTRL2_CTFG (1 << 2)
> +#define RS5C_CTRL2_AAFG (1 << 1)/* or WAFG */
> +#define RS5C_CTRL2_BAFG (1 << 0)/* or DAFG */
> +
> +
> +/* to read (style 1) or write registers starting at R */
> +#define RS5C_ADDR(R) (((R) << 4) | 0)
> +
> +
> +enum rtc_type {
> + rtc_undef = 0,
> + rtc_rs5c372a,
> + rtc_rs5c372b,
> + rtc_rv5c386,
> + rtc_rv5c387a,
> +};
>
> +/* REVISIT: this assumes that:
> + * - we're in the 21st century, so it's safe to ignore the century
> + *bit
[2.6 patch] drivers/ata/: make 4 functions static
This patch makes the following needlessly global functions static:
- libata-core.c: ata_qc_complete_internal()
- libata-scsi.c: ata_scsi_qc_new()
- libata-scsi.c: ata_dump_status()
- libata-scsi.c: ata_to_sense_error()
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/ata/libata-core.c |2 +-
drivers/ata/libata-scsi.c | 12 ++--
2 files changed, 7 insertions(+), 7 deletions(-)
--- linux-2.6.20-rc2-mm1/drivers/ata/libata-core.c.old 2007-01-03
23:06:04.0 +0100
+++ linux-2.6.20-rc2-mm1/drivers/ata/libata-core.c 2007-01-03
23:06:12.0 +0100
@@ -1160,7 +1160,7 @@
ata_port_printk(ap, KERN_DEBUG, "%s: EXIT\n", __FUNCTION__);
}
-void ata_qc_complete_internal(struct ata_queued_cmd *qc)
+static void ata_qc_complete_internal(struct ata_queued_cmd *qc)
{
struct completion *waiting = qc->private_data;
--- linux-2.6.20-rc2-mm1/drivers/ata/libata-scsi.c.old 2007-01-03
23:06:35.0 +0100
+++ linux-2.6.20-rc2-mm1/drivers/ata/libata-scsi.c 2007-01-03
23:07:52.0 +0100
@@ -397,9 +397,9 @@
* RETURNS:
* Command allocated, or %NULL if none available.
*/
-struct ata_queued_cmd *ata_scsi_qc_new(struct ata_device *dev,
- struct scsi_cmnd *cmd,
- void (*done)(struct scsi_cmnd *))
+static struct ata_queued_cmd *ata_scsi_qc_new(struct ata_device *dev,
+ struct scsi_cmnd *cmd,
+ void (*done)(struct scsi_cmnd *))
{
struct ata_queued_cmd *qc;
@@ -435,7 +435,7 @@
* LOCKING:
* inherited from caller
*/
-void ata_dump_status(unsigned id, struct ata_taskfile *tf)
+static void ata_dump_status(unsigned id, struct ata_taskfile *tf)
{
u8 stat = tf->command, err = tf->feature;
@@ -610,8 +610,8 @@
* LOCKING:
* spin_lock_irqsave(host lock)
*/
-void ata_to_sense_error(unsigned id, u8 drv_stat, u8 drv_err, u8 *sk, u8 *asc,
- u8 *ascq, int verbose)
+static void ata_to_sense_error(unsigned id, u8 drv_stat, u8 drv_err, u8 *sk,
+ u8 *asc, u8 *ascq, int verbose)
{
int i;
-
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/
[2.6 patch] arch/i386/kernel/alternative.c should #include
Every file should include the headers containing the prototypes for it's global functions. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- linux-2.6.20-rc2-mm1/arch/i386/kernel/alternative.c.old 2007-01-03 23:13:18.0 +0100 +++ linux-2.6.20-rc2-mm1/arch/i386/kernel/alternative.c 2007-01-03 23:13:32.0 +0100 @@ -4,6 +4,7 @@ #include #include #include +#include static int no_replacement= 0; static int smp_alt_once = 0; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] proper prototype for tosh_smm()
This atch adds a proper prototype for tosh_smm() to include/linux/toshiba.h Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- drivers/video/neofb.c |1 - include/linux/toshiba.h |2 ++ 2 files changed, 2 insertions(+), 1 deletion(-) --- linux-2.6.20-rc2-mm1/include/linux/toshiba.h.old2007-01-03 23:03:10.0 +0100 +++ linux-2.6.20-rc2-mm1/include/linux/toshiba.h2007-01-03 23:03:25.0 +0100 @@ -33,4 +33,6 @@ unsigned int edi __attribute__ ((packed)); } SMMRegisters; +int tosh_smm(SMMRegisters *regs); + #endif --- linux-2.6.20-rc2-mm1/drivers/video/neofb.c.old 2007-01-03 23:03:32.0 +0100 +++ linux-2.6.20-rc2-mm1/drivers/video/neofb.c 2007-01-03 23:03:39.0 +0100 @@ -66,7 +66,6 @@ #include #ifdef CONFIG_TOSHIBA #include -extern int tosh_smm(SMMRegisters *regs); #endif #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/
[2.6 patch] drivers/isdn/sc/: proper prototypes
This patch adds proper prototypes in a header file for global code under
drivers/isdn/sc/.
Since the GNU C compiler is now able do tell us that caller and callee
disagreed about the number of arguments of setup_buffers(), this patch
also fixes this bug.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/isdn/sc/card.h | 30 ++
drivers/isdn/sc/command.c | 17 ++---
drivers/isdn/sc/event.c |3 ---
drivers/isdn/sc/init.c |6 --
drivers/isdn/sc/interrupt.c | 10 --
drivers/isdn/sc/ioctl.c | 10 --
drivers/isdn/sc/message.c | 10 --
drivers/isdn/sc/packet.c| 10 --
drivers/isdn/sc/scioc.h |6 ++
drivers/isdn/sc/shmem.c |6 --
drivers/isdn/sc/timer.c |8
11 files changed, 38 insertions(+), 78 deletions(-)
--- linux-2.6.20-rc2-mm1/drivers/isdn/sc/card.h.old 2007-01-03
22:10:02.0 +0100
+++ linux-2.6.20-rc2-mm1/drivers/isdn/sc/card.h 2007-01-03 22:42:13.0
+0100
@@ -26,7 +26,9 @@
#include
#include
#include
+#include
#include "message.h"
+#include "scioc.h"
/*
* Amount of time to wait for a reset to complete
@@ -98,4 +100,32 @@
spinlock_t lock;/* local lock */
} board;
+
+extern board *sc_adapter[];
+extern int cinst;
+
+void memcpy_toshmem(int card, void *dest, const void *src, size_t n);
+void memcpy_fromshmem(int card, void *dest, const void *src, size_t n);
+int get_card_from_id(int driver);
+int indicate_status(int card, int event, ulong Channel, char *Data);
+irqreturn_t interrupt_handler(int interrupt, void *cardptr);
+int sndpkt(int devId, int channel, struct sk_buff *data);
+void rcvpkt(int card, RspMessage *rcvmsg);
+int command(isdn_ctrl *cmd);
+int reset(int card);
+int startproc(int card);
+int send_and_receive(int card, unsigned int procid, unsigned char type,
+unsigned char class, unsigned char code,
+unsigned char link, unsigned char data_len,
+unsigned char *data, RspMessage *mesgdata, int timeout);
+void flushreadfifo (int card);
+int sendmessage(int card, unsigned int procid, unsigned int type,
+ unsigned int class, unsigned int code, unsigned int link,
+ unsigned int data_len, unsigned int *data);
+int receivemessage(int card, RspMessage *rspmsg);
+int sc_ioctl(int card, scs_ioctl *data);
+int setup_buffers(int card, int c);
+void check_reset(unsigned long data);
+void check_phystat(unsigned long data);
+
#endif /* CARD_H */
--- linux-2.6.20-rc2-mm1/drivers/isdn/sc/scioc.h.old2007-01-03
22:44:10.0 +0100
+++ linux-2.6.20-rc2-mm1/drivers/isdn/sc/scioc.h2007-01-03
22:44:52.0 +0100
@@ -1,3 +1,6 @@
+#ifndef __ISDN_SC_SCIOC_H__
+#define __ISDN_SC_SCIOC_H__
+
/*
* This software may be used and distributed according to the terms
* of the GNU General Public License, incorporated herein by reference.
@@ -103,3 +106,6 @@
POTInfo potsinfo;
} info;
} boardInfo;
+
+#endif /* __ISDN_SC_SCIOC_H__ */
+
--- linux-2.6.20-rc2-mm1/drivers/isdn/sc/packet.c.old 2007-01-03
22:10:42.0 +0100
+++ linux-2.6.20-rc2-mm1/drivers/isdn/sc/packet.c 2007-01-03
22:31:00.0 +0100
@@ -20,16 +20,6 @@
#include "message.h"
#include "card.h"
-extern board *sc_adapter[];
-extern unsigned int cinst;
-
-extern int get_card_from_id(int);
-extern int indicate_status(int, int,ulong, char*);
-extern void memcpy_toshmem(int, void *, const void *, size_t);
-extern void memcpy_fromshmem(int, void *, const void *, size_t);
-extern int sendmessage(int, unsigned int, unsigned int, unsigned int,
-unsigned int, unsigned int, unsigned int, unsigned int *);
-
int sndpkt(int devId, int channel, struct sk_buff *data)
{
LLData ReqLnkWrite;
--- linux-2.6.20-rc2-mm1/drivers/isdn/sc/shmem.c.old2007-01-03
22:12:09.0 +0100
+++ linux-2.6.20-rc2-mm1/drivers/isdn/sc/shmem.c2007-01-03
22:12:18.0 +0100
@@ -22,12 +22,6 @@
#include "card.h"
/*
- * Main adapter array
- */
-extern board *sc_adapter[];
-extern int cinst;
-
-/*
*
*/
void memcpy_toshmem(int card, void *dest, const void *src, size_t n)
--- linux-2.6.20-rc2-mm1/drivers/isdn/sc/command.c.old 2007-01-03
22:12:32.0 +0100
+++ linux-2.6.20-rc2-mm1/drivers/isdn/sc/command.c 2007-01-03
22:50:27.0 +0100
@@ -31,19 +31,6 @@
static int setl3(int card, unsigned long arg);
static int acceptb(int card, unsigned long channel);
-extern int cinst;
-extern board *sc_adapter[];
-
-extern int sc_ioctl(int, scs_ioctl *);
-extern int setup_buffers(int, int, unsigned int);
-extern int indicate_status(int, int,ulong,char*);
-extern void check_reset(unsigned long);
-extern int send_and_receive(int, unsigned int, unsigned char, unsigned char,
-unsigned char, unsigned char, unsigned char, unsigned char *,
-
Re: [PATCH 2.6.19] mmc: Add support for SDHC cards (Take 2)
On Mon, 01 Jan 2007 07:29:55 -0800 Philip Langdale <[EMAIL PROTECTED]> wrote: > #define MMC_RSP_R1B > (MMC_RSP_PRESENT|MMC_RSP_CRC|MMC_RSP_OPCODE|MMC_RSP_BUSY) > #define MMC_RSP_R2 (MMC_RSP_PRESENT|MMC_RSP_136|MMC_RSP_CRC) > #define MMC_RSP_R3 (MMC_RSP_PRESENT) > -#define MMC_RSP_R6 (MMC_RSP_PRESENT|MMC_RSP_CRC) > +#define MMC_RSP_R6 (MMC_RSP_PRESENT|MMC_RSP_CRC|MMC_RSP_OPCODE) > +#define MMC_RSP_R7 (MMC_RSP_PRESENT|MMC_RSP_CRC|MMC_RSP_OPCODE) This gives MMC_RSP_R1 and MMC_RSP_R6 the same value, so drivers/mmc/tifm_sd.c: In function 'tifm_sd_op_flags': drivers/mmc/tifm_sd.c:190: error: duplicate case value drivers/mmc/tifm_sd.c:181: error: previously used 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: [PATCH] add i386 idle notifier (take 3)
On Wed, Jan 03, 2007 at 05:20:15AM -0800, Stephane Eranian wrote: > Adrian, > > On Sat, Dec 23, 2006 at 12:40:15PM +0100, Adrian Bunk wrote: > > > > > > If you look at the perfmon-new-base patch, you'll see a base.diff patch > > > which > > > includes this one. I am slowly getting rid of this requirement by pushing > > > those "infrastructure patches" to mainline so that the perfmon patch gets > > > smaller over time. Submitting smaller patches makes it easier for > > > maintainers > > > to integrate. > > > > No, the preferred way is to start with getting both the infrastructure > > and the users into -mm. > > > > Adding infrastructure without users doesn't fit into the kernel > > development model. > > I am hearing conflicting opinions on this one. > > Perfmon is a fairly big patch. It is hard to take it as one. I have tried to > split it up in smaller, more manageable pieces as requested by top-level > maintainers. This process implies that I supply small patches which may not > necessarily have users just yet. There should be a big patchset consisting of manageable pieces, if possible all of it in -mm. > > The unused x86-64 idle notifiers are now bloating the kernel since > > nearly one year. > > > > > > And why does it bloat the kernel with EXPORT_SYMBOL's although even > > > > your > > > > perfmon-new-base-061204 doesn't seem to add any modular user? > > > > > Where does the perfmon code use the EXPORT_SYMBOL's? > > The perfmon patch includes several kernel modules which make use of > the exported entry points. The following symbols are exported: > > pfm_pmu_register/pfm_pmu_unregister: > * PMU description module registration. > * Used to describe PMU model. > * Used by perfmon_p4.c, perfmon_core.c, perfmon_mckinley.c, and others > > pfm_fmt_register/pfm_fmt_unregister: > * Sampling format module registration > * Used by perfmon_dfl_smpl.c, perfmon_pebs_smpl.c > > pfm_interrupt_handler: > * PMU interrupt handler > * Used by MIPS-specific perfmon code > > pfm_pmu_conf/pfm_controls: > * global state/control variable > > All exported symbols are currently used. Why are you saying this adds bloat? Which module uses idle_notifier_register/idle_notifier_unregister? > -Stephane cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] Handle error in sync_sb_inodes()
On Wed, 03 Jan 2007 23:30:05 +0100
Guillaume Chazarain <[EMAIL PROTECTED]> wrote:
> Unfortunately, with your patch and not mine, the problem is still
> present: msync()
> does not return the error. Both pieces of code (yours and mine) are
> called for the
> same mapping though, albeit yours more frequently.
>
> My interpretation (based more on imagination than experience) is that
> __writeback_single_inode() ends up calling __block_write_full_page() which
> sets the page flags (your patch), then calls wait_on_page_writeback_range()
> which clears the flags but returns the error as its return value. And this
> error code is dropped by sync_sb_inodes() (my patch not applied).
>
> With my patch, wait_on_page_writeback_range() would get the error code
> by some other mean, and sync_sb_inodes() would re-put it in the flags for
> msync() later.
hm, something like that.
There's a lot of sloppiness in there. Do these two patches fix things up?
From: Andrew Morton <[EMAIL PROTECTED]>
Guillame points out that sync_sb_inodes() is failing to propagate error codes
back. Fix that, and make several other void-returning functions not drop
reportable error codes.
Cc: Guillaume Chazarain <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
fs/fs-writeback.c | 55 ++--
include/linux/writeback.h |6 +--
2 files changed, 44 insertions(+), 17 deletions(-)
diff -puN fs/fs-writeback.c~sync_sb_inodes-propagate-errors fs/fs-writeback.c
--- a/fs/fs-writeback.c~sync_sb_inodes-propagate-errors
+++ a/fs/fs-writeback.c
@@ -302,15 +302,18 @@ __writeback_single_inode(struct inode *i
* on the writer throttling path, and we get decent balancing between many
* throttled threads: we don't want them all piling up on __wait_on_inode.
*/
-static void
+static int
sync_sb_inodes(struct super_block *sb, struct writeback_control *wbc)
{
const unsigned long start = jiffies;/* livelock avoidance */
+ int ret = 0;
if (!wbc->for_kupdate || list_empty(>s_io))
list_splice_init(>s_dirty, >s_io);
while (!list_empty(>s_io)) {
+ int err;
+
struct inode *inode = list_entry(sb->s_io.prev,
struct inode, i_list);
struct address_space *mapping = inode->i_mapping;
@@ -365,7 +368,9 @@ sync_sb_inodes(struct super_block *sb, s
BUG_ON(inode->i_state & I_FREEING);
__iget(inode);
pages_skipped = wbc->pages_skipped;
- __writeback_single_inode(inode, wbc);
+ err = __writeback_single_inode(inode, wbc);
+ if (!ret)
+ ret = err;
if (wbc->sync_mode == WB_SYNC_HOLD) {
inode->dirtied_when = jiffies;
list_move(>i_list, >s_dirty);
@@ -386,7 +391,7 @@ sync_sb_inodes(struct super_block *sb, s
if (wbc->nr_to_write <= 0)
break;
}
- return; /* Leave any unwritten inodes on s_io */
+ return ret; /* Leave any unwritten inodes on s_io */
}
/*
@@ -408,10 +413,10 @@ sync_sb_inodes(struct super_block *sb, s
* sync_sb_inodes will seekout the blockdev which matches `bdi'. Maybe not
* super-efficient but we're about to do a ton of I/O...
*/
-void
-writeback_inodes(struct writeback_control *wbc)
+int writeback_inodes(struct writeback_control *wbc)
{
struct super_block *sb;
+ int ret = 0;
might_sleep();
spin_lock(_lock);
@@ -429,9 +434,13 @@ restart:
*/
if (down_read_trylock(>s_umount)) {
if (sb->s_root) {
+ int err;
+
spin_lock(_lock);
- sync_sb_inodes(sb, wbc);
+ err = sync_sb_inodes(sb, wbc);
spin_unlock(_lock);
+ if (!ret)
+ ret = err;
}
up_read(>s_umount);
}
@@ -443,6 +452,7 @@ restart:
break;
}
spin_unlock(_lock);
+ return ret;
}
/*
@@ -456,7 +466,7 @@ restart:
* We add in the number of potentially dirty inodes, because each inode write
* can dirty pagecache in the underlying blockdev.
*/
-void sync_inodes_sb(struct super_block *sb, int wait)
+int sync_inodes_sb(struct super_block *sb, int wait)
{
struct writeback_control wbc = {
.sync_mode = wait ? WB_SYNC_ALL : WB_SYNC_HOLD,
@@ -465,14 +475,16 @@ void sync_inodes_sb(struct super_block *
};
unsigned long nr_dirty = global_page_state(NR_FILE_DIRTY);
unsigned long
Re: Symbol links to only needed and targeted source files
On 1/3/07, Sam Ravnborg <[EMAIL PROTECTED]> wrote: On Wed, Jan 03, 2007 at 10:14:43PM +0100, Pelle Svensson wrote: > Hi Sam, > > You misunderstand me I think, I already using a separate output directory. > What I like to do is a separate 'source tree' with only valid files > for my configuration. In that way, when I use grep for instance, > I would only hit valid files and not 50 other files which are > not in the current build configuration. I see. There is nothing in kbuild that will help you to achieve this. If you build the kernel and parse all .*.cmd files then you can build a complete list of files used and create your symlinked tree. But then you need a fully build kernel to do so. I see no easy way to get the info without building the kernel and if we do this only as a preprocessing step then we will most likely not integrate it in kbuild since the user base will be small. But if you hack up something lets take a look at it. Sam Hi Sam, Ok, at least I know I'm not doing double work. /Thanks - 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] 4/4 block: explicit plugging
Jens Axboe wrote on Wednesday, January 03, 2007 2:30 PM > > We are having some trouble with the patch set that some of our fiber channel > > host controller doesn't initialize properly anymore and thus lost whole > > bunch of disks (somewhere around 200 disks out of 900) at boot time. > > Presumably FC loop initialization command are done through block layer etc. > > I haven't looked into the problem closely. > > > > Jens, I assume the spin lock bug in __blk_run_queue is fixed in this patch > > set? > > It is. Are you still seeing problems after the initial mail exchange we > had prior to christmas, Yes. Not the same kernel panic, but a problem with FC loop reset itself. > or are you referencing that initial problem? No. we got passed that point thanks for the bug fix patch you give me prior to Christmas. That fixed a kernel panic on boot up. > It's not likely to be a block layer issue, more likely the SCSI <-> > block interactions. If you mail me a new dmesg (if your problem is with > the __blk_run_queue() fixups), I can take a look. Otherwise please do > test with the __blk_run_queue() fixup, just use the current patchset. I will just retake the tip of your plug tree and retest. - 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: Finding hardlinks
Hi! > >Sure it is. Numerous popular POSIX filesystems do that. There is a lot of > >inode number space in 64 bit (of course it is a matter of time for it to > >jump to 128 bit and more) > > If the filesystem was designed by someone not from Unix world (FAT, SMB, > ...), then not. And users still want to access these filesystems. > > 64-bit inode numbers space is not yet implemented on Linux --- the problem > is that if you return ino >= 2^32, programs compiled without > -D_FILE_OFFSET_BITS=64 will fail with stat() returning -EOVERFLOW --- this > failure is specified in POSIX, but not very useful. Hehe, can we simply -EOVERFLOW on VFAT all the time? ...probably not useful :-(. But ability to say "unknown" in st_ino field would help 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: kernel + gcc 4.1 = several problems
On Wed, 2007-01-03 at 08:03 -0800, Linus Torvalds wrote: > and assuming the branch is AT ALL predictable (and 95+% of all branches > are), the branch-over will actually be a LOT better for a CPU. IF... Counterexample: Add-Compare-Select in a Viterbi Decoder. If the compare can be predicted, you botched the compression of the data (if you can predict the data, you could have compressed it better), or your noise is not white, i.e. you f*** up the whitening filter. So in any practical viterbi decoder, the compares cannot be predicted. I remember cmov made a big difference in Viterbi Decoder performance on a Cyrix 6x86. But granted, nowadays these things are usually done with SIMD and masks. 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 2/2] Handle error in sync_sb_inodes()
Andrew Morton a écrit :
@@ -365,7 +366,8 @@ sync_sb_inodes(struct super_block *sb, s
BUG_ON(inode->i_state & I_FREEING);
__iget(inode);
pages_skipped = wbc->pages_skipped;
- __writeback_single_inode(inode, wbc);
+ ret = __writeback_single_inode(inode, wbc);
+ mapping_set_error(mapping, ret);
if (wbc->sync_mode == WB_SYNC_HOLD) {
inode->dirtied_when = jiffies;
list_move(>i_list, >s_dirty);
--- a/fs/buffer.c~a
+++ a/fs/buffer.c
@@ -1739,6 +1739,7 @@ recover:
}
} while ((bh = bh->b_this_page) != head);
SetPageError(page);
+ mapping_set_error(page->mapping, err);
BUG_ON(PageWriteback(page));
set_page_writeback(page);
unlock_page(page);
Unfortunately, with your patch and not mine, the problem is still
present: msync()
does not return the error. Both pieces of code (yours and mine) are
called for the
same mapping though, albeit yours more frequently.
My interpretation (based more on imagination than experience) is that
__writeback_single_inode() ends up calling __block_write_full_page() which
sets the page flags (your patch), then calls wait_on_page_writeback_range()
which clears the flags but returns the error as its return value. And this
error code is dropped by sync_sb_inodes() (my patch not applied).
With my patch, wait_on_page_writeback_range() would get the error code
by some other mean, and sync_sb_inodes() would re-put it in the flags for
msync() later.
Sorry, for the speculation, but I would need some hint to debug this ;-)
Thanks.
--
Guillaume
-
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/5] lpfc : Make Emulex lpfc driver legacy I/O port free
On Wed, 2007-01-03 at 14:23 -0800, Andrew Morton wrote: > > drivers/scsi/lpfc/lpfc_init.c: In function 'lpfc_pci_probe_one': > > drivers/scsi/lpfc/lpfc_init.c:1418: warning: implicit declaration of > > function 'pci_select_bars' > > drivers/scsi/lpfc/lpfc_init.c:1422: warning: implicit declaration of > > function 'pci_request_selected_regions' > > drivers/scsi/lpfc/lpfc_init.c:1734: warning: implicit declaration of > > function 'pci_release_selected_regions' > > That's here, in Greg's PCI tree: Ah, OK, thanks! > http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-02-pci/pci-add-selected_regions-funcs.patch > > > Is there any ETA on the rest of the infrastructure? > > > > It doesn't look like a bugfix :( OK, I'll defer this then ... someone remind me when 2.6.20 rolls around. James - 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] 4/4 block: explicit plugging
On Wed, Jan 03 2007, Chen, Kenneth W wrote: > Jens Axboe wrote on Wednesday, January 03, 2007 12:22 AM > > > Do you have any benchmarks which got faster with these changes? > > > > On the hardware I have immediately available, I see no regressions wrt > > performance. With instrumentation it's simple to demonstrate that most > > of the queueing activity of an io heavy benchmark spends less time in > > the kernel (most merging activity takes place outside of the queue > lock, > > hence queueing is lock free). > > > > I've asked Ken to run this series on some of his big iron, I hope > he'll > > have some results for us soonish. > > We are having some trouble with the patch set that some of our fiber > channel > host controller doesn't initialize properly anymore and thus lost whole > bunch > of disks (somewhere around 200 disks out of 900) at boot time. > Presumably FC > loop initialization command are done through block layer etc. I haven't > looked into the problem closely. > > Jens, I assume the spin lock bug in __blk_run_queue is fixed in this > patch > set? It is. Are you still seeing problems after the initial mail exchange we had prior to christmas, or are you referencing that initial problem? It's not likely to be a block layer issue, more likely the SCSI <-> block interactions. If you mail me a new dmesg (if your problem is with the __blk_run_queue() fixups), I can take a look. Otherwise please do test with the __blk_run_queue() fixup, just use the current patchset. -- Jens Axboe - 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/5] lpfc : Make Emulex lpfc driver legacy I/O port free
On Wed, 03 Jan 2007 16:06:48 -0600 James Bottomley <[EMAIL PROTECTED]> wrote: > On Wed, 2006-11-22 at 10:44 -0500, James Smart wrote: > > ACK :) > > > > (I thought this had already gone in a while ago) > > Actually, there seems to be missing infrastructure for this: > > CC [M] drivers/scsi/lpfc/lpfc_init.o > drivers/scsi/lpfc/lpfc_init.c: In function 'lpfc_pci_probe_one': > drivers/scsi/lpfc/lpfc_init.c:1418: warning: implicit declaration of function > 'pci_select_bars' > drivers/scsi/lpfc/lpfc_init.c:1422: warning: implicit declaration of function > 'pci_request_selected_regions' > drivers/scsi/lpfc/lpfc_init.c:1734: warning: implicit declaration of function > 'pci_release_selected_regions' That's here, in Greg's PCI tree: http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-02-pci/pci-add-selected_regions-funcs.patch > Is there any ETA on the rest of the infrastructure? > It doesn't look like a bugfix :( - 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 + gcc 4.1 = several problems
On Wed, 3 Jan 2007, Denis Vlasenko wrote: > > IOW: yet another slot in instruction opcode matrix and thousands of > transistors in instruction decoders are wasted because of this > "clever invention", eh? Well, in all fairness, it can probably help more on certain microarchitectures. Intel is fairly aggressively OoO, especially in Core 2, and predicted branches are not only free, they allow OoO to do a great job around them. But an in-order architecture doesn't have that, and cmov might show more of an advantage there. Linus - 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: [PATCHSET 1][PATCH 0/6] Filesystem AIO read/write
On Thu, 28 Dec 2006 13:53:08 +0530 Suparna Bhattacharya <[EMAIL PROTECTED]> wrote: > This patchset implements changes to make filesystem AIO read > and write asynchronous for the non O_DIRECT case. Unfortunately the unplugging changes in Jen's block tree have trashed these patches to a degree that I'm not confident in my repair attempts. So I'll drop the fasio patches from -mm. Zach's observations regarding this code's reliance upon things at *current sounded pretty serious, so I expect we'd be seeing changes for that anyway? Plus Jens's unplugging changes add more reliance upon context inside *current, for the plugging and unplugging operations. I expect that the fsaio patches will need to be aware of the protocol which those proposed changes add. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] the scheduled eepro100 removal
On 1/2/07, Eric Piel <[EMAIL PROTECTED]> wrote: Hi, I've been using e100 for years with no problem, however more by curiosity than necessity I'd like to know how will be handled the devices which are (supposedly) supported by eepro100 and not by e100? According to "modinfo eepro100" and "modinfo e100" those devices IDs are only matched by eepro100: +alias: pci:v8086d1035sv +alias: pci:v8086d1036sv +alias: pci:v8086d1037sv These are phoneline (RJ-11) adapters, I doubt it would work with e100 or eepro100 +alias: pci:v8086d1227sv 1227 doesn't exist as a pro/100 in our database, typo maybe? +alias: pci:v8086d5200sv doesn't exist in our database +alias: pci:v8086d5201sv This was the pro/100 intelligent server adapter with a pro/100 behind a 960. There aren't too many of these out there, and they usually require some special configuration (although they can work as a dumb nic, but why would you want a full length pro/100 card?) Are they matched by some joker rule that I haven't noticed in e100, or is support for them really going to disappear? I think support for these devices can disappear (as I don't think they will work anyway) but if someone complains we can take into account what eepro100 did to support it (if anything) and enable it in e100. Jesse (e100 maintainer) - 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] Remove fastcall references in x86_64 code.
On Tue, Jan 02, 2007 at 07:09:30PM -0200, Glauber de Oliveira Costa wrote: > Unlike x86, x86_64 already passes arguments in registers. >... Nitpick: In 2.6.20-rc: s/x86/UML on x86/ cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel + gcc 4.1 = several problems
On Wed, 3 Jan 2007, Thomas Sailer wrote: > > IF... Counterexample: Add-Compare-Select in a Viterbi Decoder. Yes. [De]compression stuff tends to be (a) totally unpredictable and (b) a situation where people care about performance. It's fairly rare in many other situations. That said, any real performance these days is about avoiding cache misses. There cmov really can help more, if it results in denser code (fairly big if, though). Linus - 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] radeonfb: add support for newer cards
> Is there a list of cards this adds support for? I'm waiting on support > for the X1600 This is not supported, neither by radeonfb (patches or not) nor by X.org. X1xxx cards have a new display engine and ATI refuses to provide any specs for it. Note: I wonder how much of that is related to M$ new Vista DRM that basically forbids video or sound card vendors from providing specs or doing open source or they get "revoked" and never get to see "HD" content... Ben. - 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/5] lpfc : Make Emulex lpfc driver legacy I/O port free
On Wed, 2006-11-22 at 10:44 -0500, James Smart wrote: > ACK :) > > (I thought this had already gone in a while ago) Actually, there seems to be missing infrastructure for this: CC [M] drivers/scsi/lpfc/lpfc_init.o drivers/scsi/lpfc/lpfc_init.c: In function 'lpfc_pci_probe_one': drivers/scsi/lpfc/lpfc_init.c:1418: warning: implicit declaration of function 'pci_select_bars' drivers/scsi/lpfc/lpfc_init.c:1422: warning: implicit declaration of function 'pci_request_selected_regions' drivers/scsi/lpfc/lpfc_init.c:1734: warning: implicit declaration of function 'pci_release_selected_regions' Is there any ETA on the rest of the infrastructure? James - 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/
