Re: [PATCH] connector: Some fixes for ia64 unaligned access errors
On Fri, 2006-12-08 at 19:20 -0800, Pete Zaitcev wrote: > On Thu, 7 Dec 2006 17:22:13 -0600, Erik Jacobson <[EMAIL PROTECTED]> wrote: Erik, Thanks for cc'ing me on this patch. > > Here, we just adjust how the variables are declared and use memcopy to > > avoid the error messages. > > - ev->timestamp_ns = timespec_to_ns(); > > + ev.timestamp_ns = timespec_to_ns(); > > Please try to declare u64 timestamp_ns, then copy it into the *ev > instead of copying whole *ev. This ought to fix the problem if > buffer[] ends aligned to 32 bits or better. Yes, I like this suggestion. > Also... Since Linus does not take patches in general off l-k anymore, > you have to find whoever herds the connector and feed the patch through > him/her. > > -- Pete I contributed and continue to follow this particular connector (Evgeniy Polyakov wrote the generic connector code). In the past I've given my patches to Andrew Morton and requested inclusion in -mm -- that may be the best route (Andrew?). I'd be happy to Ack a patch implementing Pete's suggestion. Cheers, -Matt Helsley - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] Import fw-ohci driver.
Kristian Høgsberg wrote: > Yup, I've done away with the bitfields and switched to a mix of __le16 > and __le32 struct fields. I suppose the struct should get __attribute__((packed)) then. But is the order of two adjacent __le16 fields (i.e. two halves of a quadlet) independent of host byte order? -- Stefan Richter -=-=-==- ==-- -=--= http://arcgraph.de/sr/ - 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: PPC compiler error (redefinition of 'struct bug_entry')
Meelis Roos wrote: >> Hm, what's your .config? >> > > Below. It's a PReP machine so using the old ppc arch. > > >> Hey, what's arch/pps/include/asm/bug.h? Is your tree clean? >> > > Tree is clean So why don't I have arch/ppc/include/asm/bug.h in my tree here? It does look like the patch which converted ppc to use the generic bug stuff did not remove any of the ppc-specific definitions though. Did some part of the patch get lost? J - 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-rc6] fix hotplug for legacy platform drivers
On Wednesday 06 December 2006 3:56 pm, Marco d'Itri wrote: > On Dec 06, David Brownell <[EMAIL PROTECTED]> wrote: > > > > Please explain in more details how hotplugging would be broken, possibly > > > with examples. > > > > First, for reference, I refer to hotplugging using the trivial ASH scripts > > from [1], updated by removing no-longer-needed special cases for > > platform_bus > > (that original logic didn't work sometimes) and pcmcia. See the (short) > > I.e. a quick hack which has never been used by any distribution. Not a "quick hack" at all; boiling down hotplug + coldplug to something that tight got a fair degree of thought back then. It takes work to get things to be small enough to use on very small Linux-based systems. As for "never been used" ... you can't know that, given that embedded distros are normally custom built. I'm certain that I submitted it to buildroot back then. So a lot of folk building custom distros have had access to that, and I'd be surprised if it was "never" used. > And anyway some kernel component is supposed to provide the aliases > pointing from the $MODALIAS values to the drivers, so modprobe $MODALIAS > would still work. A driver named "foo" is usually named "foo.ko"; aliases not needed, or even desirable. The kernel source tree has done that for years. > > Second, note that you're asking me to construct a straw man for you and > > then break it down, since nobody arguing with the $SUBJECT patch has ever > > provided a complete counter-proposal (much less respond to the points > > I've made about legacy driver bugginess -- which is suggestive). > > I am asking what is the point for a module to provide its own name in > $MODALIAS. As I pointed out previously, more than once: it's providing a driver identifier there, all it needs is to be understood by "modprobe". > $MODALIAS is available only *after* the module has been loaded by > something else. You seem like you're being intentionally dense here ... that's rarely true, which is what makes hotplug-driven driver loading work. The $MODALIAS thing is passed to userspace after creation of driver model device nodes. (Contrary to what you said above. It's related to add_device calls, not module loading.) Normal driver modules do not create those nodes ... and $MODALIAS is used as a driver identifier so that /sbin/hotplug can "modprobe $MODALIAS" to load the right driver module. But *legacy* driver modules are not well behaved; they create those nodes themselves, rather than letting bus infrastructure do so. Which is why they are not hotpluggable. The $SUBJECT patch just turns off $MODALIAS based hotplugging for those ill-mannered drivers. - Dave - 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] usbhid quirks for macbook(pro) (was: Re: Fwd: Re: [linux-usb-devel] usb initialization order (usbhid vs. appletouch))
On Mon, 2006-10-30 at 05:12 -0500, Joseph Fannin wrote:
> On Sat, Oct 28, 2006 at 10:27:46PM +0200, Soeren Sonnenburg wrote:
> > On Sat, 2006-10-28 at 20:55 +0200, Oliver Neukum wrote:
> > > > From: Sergey Vlasov <[EMAIL PROTECTED]>
> > > > Subject: usbhid: Add HID_QUIRK_IGNORE_MOUSE flag
> > > >
> > > > Some HID devices by Apple have both keyboard and mouse interfaces; the
> > > > keyboard interface is handled by usbhid, but the mouse (really
> > > > touchpad) interface must be handled by the separate 'appletouch'
> > > > driver. Using HID_QUIRK_IGNORE will make hiddev ignore both
> > > > interfaces, therefore a new quirk flag to ignore only the mouse
> > > > interface is required.
>
> The appletouch driver doesn't work properly on the MacBook
> (non-Pro). It claims the device, and sort of functions, but is
> basically unusable.
>
> If this goes in, and blacklists the MacBook touchpad too, Macbook
> users will be unhappy. I think the MacBook and the -Pro use the same
> IDs, though, which makes a problem for this patch until appletouch is
> fixed on MacBooks.
ok, this patch was now in the mactel svn repository since about a month
and I've never ever seen a report about it failing. Also I asked on the
mailinglist for anyone having problems with that and got no answer,
execpt Joseph, the problem you have been seeing might have been that
one:
http://www.mail-archive.com/mactel-linux-devel@lists.sourceforge.net/msg00129.html
I would therefore hope it can be applied and thus appear in .20. I am
attaching the version that is now in mactel-svn (which also includes
geyser4 support).
Soeren
--
Sometimes, there's a moment as you're waking, when you become aware of
the real world around you, but you're still dreaming.
diff -uNr linux-2.6.19/drivers/usb/input/hid-core.c linux-2.6.19-mactel/drivers/usb/input/hid-core.c
--- linux-2.6.19/drivers/usb/input/hid-core.c 2006-11-29 22:57:37.0 +0100
+++ linux-2.6.19-mactel/drivers/usb/input/hid-core.c 2006-11-30 09:20:49.0 +0100
@@ -1627,6 +1627,16 @@
#define USB_VENDOR_ID_APPLE 0x05ac
#define USB_DEVICE_ID_APPLE_MIGHTYMOUSE 0x0304
+#define USB_DEVICE_ID_APPLE_GEYSER_ANSI 0x0214
+#define USB_DEVICE_ID_APPLE_GEYSER_ISO 0x0215
+#define USB_DEVICE_ID_APPLE_GEYSER_JIS 0x0216
+#define USB_DEVICE_ID_APPLE_GEYSER3_ANSI 0x0217
+#define USB_DEVICE_ID_APPLE_GEYSER3_ISO 0x0218
+#define USB_DEVICE_ID_APPLE_GEYSER3_JIS 0x0219
+#define USB_DEVICE_ID_APPLE_GEYSER4_ANSI 0x021A
+#define USB_DEVICE_ID_APPLE_GEYSER4_ISO 0x021B
+#define USB_DEVICE_ID_APPLE_GEYSER4_JIS 0x021C
+#define USB_DEVICE_ID_APPLE_IR 0x8240
#define USB_VENDOR_ID_CHERRY 0x046a
#define USB_DEVICE_ID_CHERRY_CYMOTION 0x0023
@@ -1794,17 +1804,21 @@
{ USB_VENDOR_ID_CHERRY, USB_DEVICE_ID_CHERRY_CYMOTION, HID_QUIRK_CYMOTION },
- { USB_VENDOR_ID_APPLE, 0x020E, HID_QUIRK_POWERBOOK_HAS_FN },
- { USB_VENDOR_ID_APPLE, 0x020F, HID_QUIRK_POWERBOOK_HAS_FN },
- { USB_VENDOR_ID_APPLE, 0x0214, HID_QUIRK_POWERBOOK_HAS_FN },
- { USB_VENDOR_ID_APPLE, 0x0215, HID_QUIRK_POWERBOOK_HAS_FN | HID_QUIRK_POWERBOOK_ISO_KEYBOARD},
- { USB_VENDOR_ID_APPLE, 0x0216, HID_QUIRK_POWERBOOK_HAS_FN },
- { USB_VENDOR_ID_APPLE, 0x0217, HID_QUIRK_POWERBOOK_HAS_FN },
- { USB_VENDOR_ID_APPLE, 0x0218, HID_QUIRK_POWERBOOK_HAS_FN | HID_QUIRK_POWERBOOK_ISO_KEYBOARD},
- { USB_VENDOR_ID_APPLE, 0x0219, HID_QUIRK_POWERBOOK_HAS_FN },
- { USB_VENDOR_ID_APPLE, 0x021B, HID_QUIRK_POWERBOOK_HAS_FN },
- { USB_VENDOR_ID_APPLE, 0x030A, HID_QUIRK_POWERBOOK_HAS_FN },
- { USB_VENDOR_ID_APPLE, 0x030B, HID_QUIRK_POWERBOOK_HAS_FN },
+ { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER_ANSI, HID_QUIRK_POWERBOOK_HAS_FN | HID_QUIRK_IGNORE_MOUSE},
+ { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER_ISO, HID_QUIRK_POWERBOOK_HAS_FN | HID_QUIRK_IGNORE_MOUSE | HID_QUIRK_POWERBOOK_ISO_KEYBOARD},
+ { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER_JIS, HID_QUIRK_POWERBOOK_HAS_FN | HID_QUIRK_IGNORE_MOUSE},
+ { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER3_ANSI, HID_QUIRK_POWERBOOK_HAS_FN | HID_QUIRK_IGNORE_MOUSE},
+ { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER3_ISO, HID_QUIRK_POWERBOOK_HAS_FN | HID_QUIRK_IGNORE_MOUSE | HID_QUIRK_POWERBOOK_ISO_KEYBOARD},
+ { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER3_JIS, HID_QUIRK_POWERBOOK_HAS_FN | HID_QUIRK_IGNORE_MOUSE},
+ { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_ANSI, HID_QUIRK_POWERBOOK_HAS_FN | HID_QUIRK_IGNORE_MOUSE},
+ { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_ISO, HID_QUIRK_POWERBOOK_HAS_FN | HID_QUIRK_IGNORE_MOUSE | HID_QUIRK_POWERBOOK_ISO_KEYBOARD},
+ { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_JIS, HID_QUIRK_POWERBOOK_HAS_FN | HID_QUIRK_IGNORE_MOUSE},
+ { USB_VENDOR_ID_APPLE, 0x020E, HID_QUIRK_POWERBOOK_HAS_FN | HID_QUIRK_IGNORE_MOUSE},
+ { USB_VENDOR_ID_APPLE, 0x020F, HID_QUIRK_POWERBOOK_HAS_FN | HID_QUIRK_IGNORE_MOUSE},
+ { USB_VENDOR_ID_APPLE, 0x030A, HID_QUIRK_POWERBOOK_HAS_FN | HID_QUIRK_IGNORE_MOUSE},
+ { USB_VENDOR_ID_APPLE, 0x030B,
Re: [patch 08/32] cryptoloop: Select CRYPTO_CBC
Chris Wright wrote: -stable review patch. If anyone has any objections, please let us know. -- From: Herbert Xu <[EMAIL PROTECTED]> As CBC is the default chaining method for cryptoloop, we should select it from cryptoloop to ease the transition. Signed-off-by: Herbert Xu <[EMAIL PROTECTED]> Signed-off-by: Chris Wright <[EMAIL PROTECTED]> --- drivers/block/Kconfig |1 + 1 file changed, 1 insertion(+) --- linux-2.6.19.orig/drivers/block/Kconfig +++ linux-2.6.19/drivers/block/Kconfig @@ -305,6 +305,7 @@ config BLK_DEV_LOOP config BLK_DEV_CRYPTOLOOP tristate "Cryptoloop Support" select CRYPTO + select CRYPTO_CBC depends on BLK_DEV_LOOP ---help--- Say Y here if you want to be able to use the ciphers that are dm-crypt needs CBC in the same manner -- normal (via howto) use of cryptsetup doesn't work otherwise, same as with cryptoloop. Rene. - 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/
Recursive spinlocks for Network Recursion Bugs in 2.6.18
This code segment in /net/core/dev.c is a prime example of the need for
recursive spin locks.
if (dev->flags & IFF_UP) {
int cpu = smp_processor_id(); /* ok because BHs are off */
if (dev->xmit_lock_owner != cpu) {
HARD_TX_LOCK(dev, cpu);
if (!netif_queue_stopped(dev)) {
rc = 0;
if (!dev_hard_start_xmit(skb, dev)) {
HARD_TX_UNLOCK(dev);
goto out;
}
}
HARD_TX_UNLOCK(dev);
if (net_ratelimit())
printk(KERN_CRIT "Virtual device %s asks
to "
"queue packet!\n", dev->name);
} else {
/* Recursion is detected! It is possible,
* unfortunately */
if (net_ratelimit())
printk(KERN_CRIT "Dead loop on virtual
device "
"%s, fix it urgently!\n", dev->name);
}
}
Recursive spinlocks perform the logic
rspin_lock(spin_lock)
{
if (spin_lock->lock->cpu_owner = cpu I am on) && (spin_lock->lock)
{
spin_lock->use_count++;
}
else
{
spin_lock(lock)
lock->cpu_owner = cpu I am on;
lock->use_count++;
}
}
rspin_unlock(spin_lock)
{
if (spin_lock->lock->cpu_owner = cpu I am on) && (spin_lock->use_count)
{
spin_lock->use_count--;
}
else
{
lock->use_count++;
lock->cpu_owner = cpu I am on;
spin_unlock(lock)
}
}
One implementation of this is:
LONG rspin_lock(rlock_t *rlock)
{
register LONG proc = get_processor_id();
register LONG retCode;
if (rlock->lockValue && rlock->processor == (proc + 1))
{
rlock->count++;
retCode = 1;
}
else
{
dspin_lock(>lockValue);
rlock->processor = (proc + 1);
retCode = 0;
}
return retCode;
}
LONG rspin_unlock(rlock_t *rlock)
{
register LONG retCode;
if (rlock->count)
{
rlock->count--;
retCode = 1;
}
else
{
rlock->processor = 0;
dspin_unlock(>lockValue);
retCode = 0;
}
return retCode;
}
Just a suggestion. Would be a useful primitive for a lot of context
implementations where users turn on interrupts inside of nested spin
lock code.
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/
Re: [PATCH] cpuset - rework cpuset_zone_allowed api
On Fri, 08 Dec 2006 03:21:52 -0800 Paul Jackson <[EMAIL PROTECTED]> wrote: > From: Paul Jackson <[EMAIL PROTECTED]> > > Elaborate the API for calling cpuset_zone_allowed(), so that users > have to explicitly choose between the two variants: > > cpuset_zone_allowed_hardwall() > cpuset_zone_allowed_softwall() > > Until now, whether or not you got the hardwall flavor depended solely > on whether or not you or'd in the __GFP_HARDWALL gfp flag to the > gfp_mask argument. yeah, nice change that. - 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: single bit errors on files stored on USB-HDDs via USB2/usb_storage
Also, you mentioned that the corruption occurs systematically on certain byte patterns. Therefore it's certainly not related to the cables. It'd guess that too, but who can that say for sure. :-| You may have a bit pattern that stresses the controllers and suddenly a marginal cable may matter. The errors occur in strings of 0xFFs. From the USB standard: a “1” is represented by no change in level and a “0” is represented by a change in level so this error-infested bytes are effectively long, quiet times on the wire. I would have thought this would be the _least_ stressful time for the controllers but maybe they are also more susceptible to noise during this period. Regards, 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] group xtime, xtime_lock, wall_to_monotonic, avenrun, calc_load_count fields together in ktimed
On Fri, 8 Dec 2006 21:46:25 -0800 Andrew Morton wrote:
> On Fri, 8 Dec 2006 17:52:09 +0100
> Eric Dumazet <[EMAIL PROTECTED]> wrote:
[snip]
> Sounds like you have about three patches there.
>
> />
>
> >
> > -extern struct timespec xtime;
> > -extern struct timespec wall_to_monotonic;
> > -extern seqlock_t xtime_lock;
> > +/*
> > + * define a structure to keep all fields close to each others.
> > + */
> > +struct ktimed_struct {
> > + struct timespec _xtime;
> > + struct timespec wall_to_monotonic;
> > + seqlock_t lock;
> > + unsigned long avenrun[3];
> > + int calc_load_count;
> > +};
>
> crappy name, but I guess it doesn't matter as nobody will use it at this
> stage. But...
ktimedata would be better IMO. somethingd looks like a daemon.
>
> > +extern struct ktimed_struct ktimed;
> > +#define xtime ktimed._xtime
> > +#define wall_to_monotonic ktimed.wall_to_monotonic
> > +#define xtime_lockktimed.lock
> > +#define avenrun ktimed.avenrun
>
> They'll use these instead.
>
> Frankly, I think we'd be better off removing these macros and, longer-term,
> use
>
> write_seqlock(time_data.xtime_lock);
>
> The approach you have here would be a good transition-period thing.
[snip]
> hm, the patch seems to transform a mess into a mess. I guess it's a messy
> problem.
>
> I agree that aggregating all the time-related things into a struct like
> this makes some sense. As does aggregating them all into a similar-looking
> namespace, but that'd probably be too intrusive - too late for that.
Just curious, is the change measurable (time/performance wise)?
Patch makes sense anyway.
---
~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/
Re: VCD not readable under 2.6.18
Hi,
I am having problems reading VCDs under various Linux distros (Fedora Core 6,
openSUSE 10.2, Slackware 11 with the 2.6 kernel), and while searching Google
for a solution I found that this problem has been mentioned on the LKML list
too. (http://lkml.org/lkml/2006/10/29/95)
I didn't see any responses after the post linked to above, so I'd like to add
that I too get this problem and that I've tried with various VCDs and players.
In previous versions of these distros I could just mount the VCD and copy the
*.DAT files across; but in the current versions I can't even mount! dmesg gets
flooded with errors such as the below:
hdc: command error: status=0x51 { DriveReady SeekComplete Error }
hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 }
ide: failed opcode was: unknown
ATAPI device hdc:
Error: Illegal request -- (Sense key=0x05)
Illegal mode for this track or incompatible medium -- (asc=0x64, ascq=0x00)
The failed "Read 10" packet command was:
"28 00 00 00 73 f2 00 00 01 00 00 00 00 00 00 00 "
end_request: I/O error, dev hdc, sector 118728
Buffer I/O error on device hdc, logical block 29682
hdc: command error: status=0x51 { DriveReady SeekComplete Error }
hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 }
ide: failed opcode was: unknown
ATAPI device hdc:
Error: Illegal request -- (Sense key=0x05)
Illegal mode for this track or incompatible medium -- (asc=0x64, ascq=0x00)
The failed "Read 10" packet command was:
"28 00 00 00 73 f3 00 00 03 00 00 00 00 00 00 00 "
end_request: I/O error, dev hdc, sector 118732
Buffer I/O error on device hdc, logical block 29683
Buffer I/O error on device hdc, logical block 29684
Buffer I/O error on device hdc, logical block 29685
hdc: command error: status=0x51 { DriveReady SeekComplete Error }
hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 }
ide: failed opcode was: unknown
ATAPI device hdc:
Error: Illegal request -- (Sense key=0x05)
Illegal mode for this track or incompatible medium -- (asc=0x64, ascq=0x00)
The failed "Read 10" packet command was:
"28 00 00 00 73 f2 00 00 02 00 00 00 00 00 00 00 "
end_request: I/O error, dev hdc, sector 118728
Buffer I/O error on device hdc, logical block 29682
Buffer I/O error on device hdc, logical block 29683
hdc: command error: status=0x51 { DriveReady SeekComplete Error }
hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 }
ide: failed opcode was: unknown
ATAPI device hdc:
Error: Illegal request -- (Sense key=0x05)
Illegal mode for this track or incompatible medium -- (asc=0x64, ascq=0x00)
The failed "Read 10" packet command was:
"28 00 00 00 73 f2 00 00 02 00 00 00 00 00 00 00 "
end_request: I/O error, dev hdc, sector 118728
Buffer I/O error on device hdc, logical block 29682
Buffer I/O error on device hdc, logical block 29683
hdc: command error: status=0x51 { DriveReady SeekComplete Error }
hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 }
Another link on the net (by the same poster as the LKML link above) mentioned
that this problem appears *after* kernel 2.6.16. So I downgraded my Slackware
kernel to 2.6.16 and sure enough the problem goes away. I haven't tried with
the 2.6.19 kernel, so I can't confirm if that solves the problem or not.
Thanks,
Rakhesh
ps. Am not subscribed to this list. Please cc me any replies etc. Thanks.
Have a burning question?
Go to www.Answers.yahoo.com and get answers from real people who know.
-
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 driver for Silan SC92031 (second try)
On Fri, 08 Dec 2006 18:17:06 -0200 Cesar Eduardo Barros <[EMAIL PROTECTED]> wrote: > From: Cesar Eduardo Barros <[EMAIL PROTECTED]> > > This is a driver for the Silan SC92031/Rsltek 8139D NIC chip. > > ... > +config SC92031 > + depends on NET_PCI && PCI && EXPERIMENTAL > + select CRC32 > > ... > > + } while(unlikely(cmpxchg(>intr_status, You'll have the arm maintainer after you with a pointy stick. cmpxchg is only available on certain architectures. It would be acceptable to make this driver depend on X86 (or something). Better to rewrite this code so it doesn't use cmpxchg. - 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] group xtime, xtime_lock, wall_to_monotonic, avenrun, calc_load_count fields together in ktimed
On Fri, 8 Dec 2006 17:52:09 +0100
Eric Dumazet <[EMAIL PROTECTED]> wrote:
> This patch introduces a new structure called ktimed (Kernel Time Data), where
> some time keeping related variables are put together to share as few cache
> lines as possible. This avoid some false sharing, (since linker could put
> calc_load_count in a *random* cache line for example)
>
> I also optimized calc_load() to not always call count_active_tasks() :
> It should call it only once every 5 seconds (LOAD_FREQ=5*HZ)
>
> Note : x86_64 was using an arch specific placement of __xtime and
> __xtime_lock
> (see arch/x86_64/kernel/vmlinux.lds.S). (vsyscall stuff)
> It is now using a specific placement of __ktimed, since xtime and xtime_lock
> are now fields from __ktimed.
>
> Note : I failed to move jiffies64 as well in ktimed : too many changes needed
> because of jiffies aliasing (and endianess), but it could be done.
>
Sounds like you have about three patches there.
/>
>
> -extern struct timespec xtime;
> -extern struct timespec wall_to_monotonic;
> -extern seqlock_t xtime_lock;
> +/*
> + * define a structure to keep all fields close to each others.
> + */
> +struct ktimed_struct {
> + struct timespec _xtime;
> + struct timespec wall_to_monotonic;
> + seqlock_t lock;
> + unsigned long avenrun[3];
> + int calc_load_count;
> +};
crappy name, but I guess it doesn't matter as nobody will use it at this
stage. But...
> +extern struct ktimed_struct ktimed;
> +#define xtime ktimed._xtime
> +#define wall_to_monotonic ktimed.wall_to_monotonic
> +#define xtime_lockktimed.lock
> +#define avenrun ktimed.avenrun
They'll use these instead.
Frankly, I think we'd be better off removing these macros and, longer-term,
use
write_seqlock(time_data.xtime_lock);
The approach you have here would be a good transition-period thing.
> void timekeeping_init(void);
>
> --- linux-2.6.19/kernel/timer.c 2006-12-08 11:50:11.0 +0100
> +++ linux-2.6.19-ed/kernel/timer.c2006-12-08 18:13:24.0 +0100
> @@ -570,11 +570,13 @@ found:
> * however, we will ALWAYS keep the tv_nsec part positive so we can use
> * the usual normalization.
> */
> -struct timespec xtime __attribute__ ((aligned (16)));
> -struct timespec wall_to_monotonic __attribute__ ((aligned (16)));
> -
> -EXPORT_SYMBOL(xtime);
> -
> +#ifndef ARCH_HAVE_KTIMED
argh, another ARCH_HAVE_MESS. Due to the x86_64 vsyscall code.
Could you please see if we can nuke this by making
kernel/timer.c:xtime_lock use attribute(weak)? In a separate patch ;)
> +struct ktimed_struct ktimed __cacheline_aligned = {
> + .lock = __SEQLOCK_UNLOCKED(ktimed.lock),
> + .calc_load_count = LOAD_FREQ,
> +};
> +EXPORT_SYMBOL(ktimed);
> +#endif
>
> /* XXX - all of this timekeeping code should be later moved to time.c */
> #include
> @@ -995,9 +997,6 @@ static unsigned long count_active_tasks(
> *
> * Requires xtime_lock to access.
> */
> -unsigned long avenrun[3];
> -
> -EXPORT_SYMBOL(avenrun);
>
> /*
> * calc_load - given tick count, update the avenrun load estimates.
> @@ -1006,27 +1005,21 @@ EXPORT_SYMBOL(avenrun);
> static inline void calc_load(unsigned long ticks)
> {
> unsigned long active_tasks; /* fixed-point */
> - static int count = LOAD_FREQ;
>
> - active_tasks = count_active_tasks();
> - for (count -= ticks; count < 0; count += LOAD_FREQ) {
> - CALC_LOAD(avenrun[0], EXP_1, active_tasks);
> - CALC_LOAD(avenrun[1], EXP_5, active_tasks);
> - CALC_LOAD(avenrun[2], EXP_15, active_tasks);
> + ktimed.calc_load_count -= ticks;
> +
> + if (unlikely(ktimed.calc_load_count < 0)) {
> + active_tasks = count_active_tasks();
> + do {
> + ktimed.calc_load_count += LOAD_FREQ;
> + CALC_LOAD(avenrun[0], EXP_1, active_tasks);
> + CALC_LOAD(avenrun[1], EXP_5, active_tasks);
> + CALC_LOAD(avenrun[2], EXP_15, active_tasks);
> + } while (ktimed.calc_load_count < 0);
> }
> }
>
> ...
>
> +extern struct ktimed_struct __ktimed;
> +#define __xtime_lock __ktimed.lock
> +#define __xtime __ktimed._xtime
>
> /* kernel space (writeable) */
> extern struct vxtime_data vxtime;
> extern int vgetcpu_mode;
> extern struct timezone sys_tz;
> extern int sysctl_vsyscall;
> -extern seqlock_t xtime_lock;
>
> -extern int sysctl_vsyscall;
> -
> -#define ARCH_HAVE_XTIME_LOCK 1
> +#define ARCH_HAVE_KTIMED 1
>
hm, the patch seems to transform a mess into a mess. I guess it's a messy
problem.
I agree that aggregating all the time-related things into a struct like
this makes some sense. As does aggregating them all into a similar-looking
namespace, but that'd probably be too intrusive - too late for that.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Re: PPC compiler error (redefinition of 'struct bug_entry')
> Hm, what's your .config?
Below. It's a PReP machine so using the old ppc arch.
> Hey, what's arch/pps/include/asm/bug.h? Is your tree clean?
Tree is clean except a local in-progress patch against cirrusfb and
another against net/ipv6/ndisc.c that made 2.6.19 work, nothing unclean
about header files or anything mentioned in the error message.
arch/ppc/include/asm/bug.h:
#ifndef _ASM_POWERPC_BUG_H
#define _ASM_POWERPC_BUG_H
#ifdef __KERNEL__
#include
/*
* Define an illegal instr to trap on the bug.
* We don't use 0 because that marks the end of a function
* in the ELF ABI. That's "Boo Boo" in case you wonder...
*/
#define BUG_OPCODE .long 0x00b00b00 /* For asm */
#define BUG_ILLEGAL_INSTR "0x00b00b00" /* For BUG macro */
#ifndef __ASSEMBLY__
struct bug_entry {
unsigned long bug_addr;
longline;
const char *file;
const char *function;
};
struct bug_entry *find_bug(unsigned long bugaddr);
/*
* If this bit is set in the line number it means that the trap
* is for WARN_ON rather than BUG or BUG_ON.
*/
#define BUG_WARNING_TRAP0x100
#ifdef CONFIG_BUG
/*
* BUG_ON() and WARN_ON() do their best to cooperate with compile-time
* optimisations. However depending on the complexity of the condition
* some compiler versions may not produce optimal results.
*/
#define BUG() do { \
__asm__ __volatile__(\
"1: twi 31,0,0\n"\
".section __bug_table,\"a\"\n" \
"\t"PPC_LONG" 1b,%0,%1,%2\n" \
".previous" \
: : "i" (__LINE__), "i" (__FILE__), "i" (__FUNCTION__)); \
} while (0)
#define BUG_ON(x) do { \
if (__builtin_constant_p(x)) { \
if (x) \
BUG(); \
} else {\
__asm__ __volatile__( \
"1: "PPC_TLNEI" %0,0\n" \
".section __bug_table,\"a\"\n" \
"\t"PPC_LONG" 1b,%1,%2,%3\n" \
".previous" \
: : "r" ((long)(x)), "i" (__LINE__),\
"i" (__FILE__), "i" (__FUNCTION__));\
} \
} while (0)
#define __WARN() do { \
__asm__ __volatile__( \
"1: twi 31,0,0\n" \
".section __bug_table,\"a\"\n" \
"\t"PPC_LONG" 1b,%0,%1,%2\n" \
".previous" \
: : "i" (__LINE__ + BUG_WARNING_TRAP), \
"i" (__FILE__), "i" (__FUNCTION__));\
} while (0)
#define WARN_ON(x) ({ \
typeof(x) __ret_warn_on = (x); \
if (__builtin_constant_p(__ret_warn_on)) { \
if (__ret_warn_on) \
__WARN(); \
} else {\
__asm__ __volatile__( \
"1: "PPC_TLNEI" %0,0\n" \
".section __bug_table,\"a\"\n" \
"\t"PPC_LONG" 1b,%1,%2,%3\n" \
".previous" \
: : "r" (__ret_warn_on),\
"i" (__LINE__ + BUG_WARNING_TRAP), \
"i" (__FILE__), "i" (__FUNCTION__));\
} \
unlikely(__ret_warn_on);\
})
#define HAVE_ARCH_BUG
#define HAVE_ARCH_BUG_ON
#define HAVE_ARCH_WARN_ON
#endif /* CONFIG_BUG */
#endif /* __ASSEMBLY __ */
#include
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_BUG_H */
config:
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.19
# Fri Dec 8 20:51:53 2006
#
CONFIG_MMU=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_ILOG2_U32=y
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_PPC=y
CONFIG_PPC32=y
CONFIG_GENERIC_NVRAM=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
2.6.19-ck2
This patchset is designed to improve system responsiveness and interactivity. It is configurable to any workload but the default -ck patch is aimed at the desktop and -cks is available with more emphasis on serverspace. Apply to 2.6.19 http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.19/2.6.19-ck2/patch-2.6.19-ck2.bz2 or server version http://www.kernel.org/pub/linux/kernel/people/ck/patches/cks/patch-2.6.19-cks2.bz2 web: http://kernel.kolivas.org all patches: http://www.kernel.org/pub/linux/kernel/people/ck/patches/ Changes (first significant changes since : Added: +sched-fix_iso_starvation.patch A bug first introduced into 2.6.18-ck1/cks1 meant that SCHED_ISO tasks were not being throttled when above their cpu limit. This presents a security risk to any machine with user logins and upgrading for this issue should be considered a high priority. +sched-make_softirqd_batch.patch Instead of 'nice'ing ksoftirqd we can use the policy hint of SCHED_BATCH which specifies it as not requiring low latency. This increases the cpu use possible under very heavy softirq traffic (such as network loads) and decreases the latency that might otherwise be seen (such as keyboard input under heavy cpu load on slow machines). Split patches available. Full patchlist: sched-staircase-16.2.patch sched-staircase16_interactive_tunable.patch sched-staircase16_compute_tunable.patch sched-range.patch sched-iso-4.6.patch sched-fix_iso_starvation.patch track_mutexes-1.patch sched-idleprio-1.11.patch sched-limit_policy_changes.patch sched-make_softirqd_batch.patch cfq-ioprio_inherit_rt_class.patch cfq-iso_idleprio_ionice.patch hz-default_1000.patch hz-no_default_250.patch sched-add-above-background-load-function.patch mm-swap_prefetch-33.patch mm-convert_swappiness_to_mapped.patch mm-lots_watermark.diff mm-kswapd_inherit_prio-1.patch mm-prio_dependant_scan-2.patch mm-background_scan-2.patch mm-idleprio_prio.patch mm-decrease_minimum_dirty_ratio.patch mm-set_zero_dirty_ratio.patch mm-filesize_dependant_lru_cache_add.patch kconfig-expose_vmsplit_option.patch ck2-version.patch 楽しみなさい -- -ck -- -ck pgpwUzV5rMphv.pgp Description: PGP signature
Re: [RFC] [PATCH] virtual memmap on sparsemem v3 [4/4] ia64 support
I tested ia64 with this patch under - DISCONTIGMEM + VIRTUAL_MEM_MAP - SPARSEMEM - SPARSEMEM_VMEMMAP on SMP with tiger4_defconfig. Fix typo for DISCONTIGMEM Signed-Off-By: KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> Index: devel-2.6.19/include/asm-ia64/pgtable.h === --- devel-2.6.19.orig/include/asm-ia64/pgtable.h2006-12-09 13:22:47.0 +0900 +++ devel-2.6.19/include/asm-ia64/pgtable.h 2006-12-09 13:23:44.0 +0900 @@ -237,7 +237,7 @@ #elif defined(CONFIG_VIRTUAL_MEM_MAP) #define VMALLOC_START (RGN_BASE(RGN_GATE) + 0x2UL) -#defineVMALLOC_END_INIT(RGN_BASE(RGN_GATE) + (1UL << (4*PAGE_SHIFT - 9))) +#define VMALLOC_END_INIT(RGN_BASE(RGN_GATE) + (1UL << (4*PAGE_SHIFT - 9))) #define VMALLOC_ENDvmalloc_end extern unsigned long vmalloc_end; #else - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [PATCH] virtual memmap on sparsemem v3 [1/4] map and unmap
This removes implicit default actions in map_generic_kernel() call.
Also changes comments in vmalloc.h
Signed-Off-By: KAMEZAWA Hiroyuki <[EMAIL PROTECTED]>
Index: devel-2.6.19/include/linux/vmalloc.h
===
--- devel-2.6.19.orig/include/linux/vmalloc.h 2006-12-08 15:02:39.0
+0900
+++ devel-2.6.19/include/linux/vmalloc.h2006-12-09 13:46:17.0
+0900
@@ -81,6 +81,9 @@
* not managed by standard vmap calls.
* The caller has to be responsible to manage his own virtual address space.
*
+ * what you have to do in pud/pmd/pte allocation is allocate page and
+ * populate that entry.
+ *
* Bootstrap consideration:
* you can pass pud/pmd/pte alloc functions to map_generic_kernel().
* So you can use bootmem function or something to alloc page tables if
@@ -88,13 +91,12 @@
*/
struct gen_map_kern_ops {
- /* must be defined */
+ /* all pointers must be filled */
int (*k_pte_set)(pte_t *pte, unsigned long addr, void *data);
- int (*k_pte_clear)(pte_t *pte, unsigned long addr, void *data);
- /* optional */
int (*k_pud_alloc)(pgd_t *pgd, unsigned long addr, void *data);
int (*k_pmd_alloc)(pud_t *pud, unsigned long addr, void *data);
int (*k_pte_alloc)(pmd_t *pmd, unsigned long addr, void *data);
+ int (*k_pte_clear)(pte_t *pte, unsigned long addr, void *data);
};
/*
Index: devel-2.6.19/mm/vmalloc.c
===
--- devel-2.6.19.orig/mm/vmalloc.c 2006-12-08 15:02:39.0 +0900
+++ devel-2.6.19/mm/vmalloc.c 2006-12-09 13:44:35.0 +0900
@@ -764,15 +764,10 @@
int ret = 0;
unsigned long next;
if (!pmd_present(*pmd)) {
- if (ops->k_pte_alloc) {
- ret = ops->k_pte_alloc(pmd, addr, data);
- if (ret)
- return ret;
- } else {
- pte = pte_alloc_kernel(pmd, addr);
- if (!pte)
- return -ENOMEM;
- }
+ BUG_ON(!ops->k_pte_alloc);
+ ret = ops->k_pte_alloc(pmd, addr, data);
+ if (ret)
+ return ret;
}
pte = pte_offset_kernel(pmd, addr);
@@ -796,15 +791,10 @@
int ret;
if (pud_none(*pud)) {
- if (ops->k_pmd_alloc) {
- ret = ops->k_pmd_alloc(pud, addr, data);
- if (ret)
- return ret;
- } else {
- pmd = pmd_alloc(_mm, pud, addr);
- if (!pmd)
- return -ENOMEM;
- }
+ BUG_ON(!ops->k_pmd_alloc);
+ ret = ops->k_pmd_alloc(pud, addr, data);
+ if (ret)
+ return ret;
}
pmd = pmd_offset(pud, addr);
do {
@@ -824,15 +814,10 @@
unsigned long next;
int ret;
if (pgd_none(*pgd)) {
- if (ops->k_pud_alloc) {
- ret = ops->k_pud_alloc(pgd, addr, data);
- if (ret)
- return ret;
- } else {
- pud = pud_alloc(_mm, pgd, addr);
- if (!pud)
- return -ENOMEM;
- }
+ BUG_ON(!ops->k_pud_alloc);
+ ret = ops->k_pud_alloc(pgd, addr, data);
+ if (ret)
+ return ret;
}
pud = pud_offset(pgd, addr);
do {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [PATCH] virtual memmap on sparsemem v3 [3/4] static virtual mem_map
for avoiding complex inclusion of headr file in the middle of another header
file.
Signed-Off-By: KAMEZAWA Hiroyuki <[EMAIL PROTECTED]>
Index: devel-2.6.19/include/linux/mmzone.h
===
--- devel-2.6.19.orig/include/linux/mmzone.h2006-12-08 15:05:18.0
+0900
+++ devel-2.6.19/include/linux/mmzone.h 2006-12-09 13:00:32.0 +0900
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
@@ -562,7 +563,6 @@
#error Allocator MAX_ORDER exceeds SECTION_SIZE
#endif
-struct page;
struct mem_section {
/*
* This is, logically, a pointer to an array of struct
@@ -619,7 +619,6 @@
#error "PAGE_SIZE/SECTION_SIZE relationship is not suitable for vmem_map"
#endif
#ifdef CONFIG_SPARSEMEM_VMEMMAP_STATIC
-#include
extern struct page mem_map[];
#else
extern struct page* mem_map;
-
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][resend] PNX8550 UART driver
On Fri, 8 Dec 2006 18:04:46 +0300 Vitaly Wool <[EMAIL PROTECTED]> wrote: > This patch adds UART support for PNX8330/8550/8950 Philips MIPS-based SoCs. I expect it'll need updating for the terios->ktermios changes which were merged today. > Should be applied together with the PNX UART header fixup patch last sent > yesterday (http://lkml.org/lkml/2006/12/7/147). OK, after some struggle I found that. > This stuff has been basically approved by rmk before he quitted maintaining > serial core but hasn't been accepted yet due to merge window miss at that > moment. Please keep those emails to under 80-cols, 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][resend] fix PNX8550 serial breakage
On Thu, 7 Dec 2006 18:24:39 +0300 Vitaly Wool <[EMAIL PROTECTED]> wrote: > inlined is the patch (being resent) that fixes the serial header breakage for > the PNX8550 MIPS platform. When sending a fix please include a full description of the problem which is being fixed, and a description of how the patch fixes it, if that is not utterly obvious. 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: 2.6.19-git libusual: modprobe for usb-storage succeeded, but module is not present
to: linux-kernel@vger.kernel.org cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Re: 2.6.19-git libusual: modprobe for usb-storage succeeded, but module is not present usb 2-2: new high speed USB device using ehci_hcd and address 3 > usb 2-2: configuration #1 chosen from 1 choice > libusual: modprobe for usb-storage succeeded, but module is not present > usb 2-4: new high speed USB device using ehci_hcd and address 5 > usb 2-4: configuration #1 chosen from 1 choice > libusual: modprobe for usb-storage succeeded, but module is not present > usb 2-5: new high speed USB device using ehci_hcd and address 6 > usb 2-5: configuration #1 chosen from 1 choice > libusual: modprobe for usb-storage succeeded, but module is not present I don't know what you've done to accomplish it, but either your modules got separated (e.g. libusual built statically while usb-storage is dynamic), or your modprobe is toast, or 100 other reasons. Just deconfigure CONFIG_BLK_DEV_UB and CONFIG_USB_LIBUSUAL and forget about it all. I know, I have to think of a workaround for this, but nothing is readily apparent. -- Pete was CONFIG_BLK_DEV_UB=m CONFIG_USB_LIBUSUAL=y now # CONFIG_BLK_DEV_UB is not set # CONFIG_USB_LIBUSUAL is not set works ok thanx xboom - 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 28/32] autofs: fix error code path in autofs_fill_sb()
On Fri, 2006-12-08 at 15:58 -0800, Chris Wright wrote:
> plain text document attachment
> (autofs-fix-error-code-path-in-autofs_fill_sb.patch)
> -stable review patch. If anyone has any objections, please let us know.
> --
Stable review of what (version)?
>
> From: Jiri Kosina <[EMAIL PROTECTED]>
>
> When kernel is compiled with old version of autofs (CONFIG_AUTOFS_FS), and
> new (observed at least with 5.x.x) automount deamon is started, kernel
> correctly reports incompatible version of kernel and userland daemon, but
> then screws things up instead of correct handling of the error:
No objections.
I'm sure I tested this case when I did the original patch that has the
error which this patch fixes.
The bug is clearly present and needs fixing.
>
> autofs: kernel does not match daemon version
> =
> [ BUG: bad unlock balance detected! ]
> -
> automount/4199 is trying to release lock (>s_umount_key) at:
> [] get_sb_nodev+0x76/0xa4
> but there are no more locks to release!
>
> other info that might help us debug this:
> no locks held by automount/4199.
>
> stack backtrace:
> [] dump_trace+0x68/0x1b2
> [] show_trace_log_lvl+0x18/0x2c
> [] show_trace+0xf/0x11
> [] dump_stack+0x12/0x14
> [] print_unlock_inbalance_bug+0xe7/0xf3
> [] lock_release+0x8d/0x164
> [] up_write+0x14/0x27
> [] get_sb_nodev+0x76/0xa4
> [] vfs_kern_mount+0x83/0xf6
> [] do_kern_mount+0x2d/0x3e
> [] do_mount+0x607/0x67a
> [] sys_mount+0x72/0xa4
> [] sysenter_past_esp+0x5f/0x99
> DWARF2 unwinder stuck at sysenter_past_esp+0x5f/0x99
> Leftover inexact backtrace:
> ===
>
> and then deadlock comes.
>
> The problem: autofs_fill_super() returns EINVAL to get_sb_nodev(), but
> before that, it calls kill_anon_super() to destroy the superblock which
> won't be needed. This is however way too soon to call kill_anon_super(),
> because get_sb_nodev() has to perform its own cleanup of the superblock
> first (deactivate_super(), etc.). The correct time to call
> kill_anon_super() is in the autofs_kill_sb() callback, which is called by
> deactivate_super() at proper time, when the superblock is ready to be
> killed.
>
> I can see the same faulty codepath also in autofs4. This patch solves
> issues in both filesystems in a same way - it postpones the
> kill_anon_super() until the proper time is signalized by deactivate_super()
> calling the kill_sb() callback.
>
> [EMAIL PROTECTED]: update comment]
> Signed-off-by: Jiri Kosina <[EMAIL PROTECTED]>
> Acked-by: Ian Kent <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Signed-off-by: Ian Kent <[EMAIL PROTECTED]>
> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
> Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
> ---
>
> fs/autofs/inode.c |7 ---
> fs/autofs4/inode.c |7 ---
> 2 files changed, 8 insertions(+), 6 deletions(-)
>
> --- linux-2.6.19.orig/fs/autofs/inode.c
> +++ linux-2.6.19/fs/autofs/inode.c
> @@ -28,10 +28,11 @@ void autofs_kill_sb(struct super_block *
> /*
>* In the event of a failure in get_sb_nodev the superblock
>* info is not present so nothing else has been setup, so
> - * just exit when we are called from deactivate_super.
> + * just call kill_anon_super when we are called from
> + * deactivate_super.
>*/
> if (!sbi)
> - return;
> + goto out_kill_sb;
>
> if ( !sbi->catatonic )
> autofs_catatonic_mode(sbi); /* Free wait queues, close pipe */
> @@ -44,6 +45,7 @@ void autofs_kill_sb(struct super_block *
>
> kfree(sb->s_fs_info);
>
> +out_kill_sb:
> DPRINTK(("autofs: shutting down\n"));
> kill_anon_super(sb);
> }
> @@ -209,7 +211,6 @@ fail_iput:
> fail_free:
> kfree(sbi);
> s->s_fs_info = NULL;
> - kill_anon_super(s);
> fail_unlock:
> return -EINVAL;
> }
> --- linux-2.6.19.orig/fs/autofs4/inode.c
> +++ linux-2.6.19/fs/autofs4/inode.c
> @@ -152,10 +152,11 @@ void autofs4_kill_sb(struct super_block
> /*
>* In the event of a failure in get_sb_nodev the superblock
>* info is not present so nothing else has been setup, so
> - * just exit when we are called from deactivate_super.
> + * just call kill_anon_super when we are called from
> + * deactivate_super.
>*/
> if (!sbi)
> - return;
> + goto out_kill_sb;
>
> sb->s_fs_info = NULL;
>
> @@ -167,6 +168,7 @@ void autofs4_kill_sb(struct super_block
>
> kfree(sbi);
>
> +out_kill_sb:
> DPRINTK("shutting down");
> kill_anon_super(sb);
> }
> @@ -426,7 +428,6 @@ fail_ino:
> fail_free:
> kfree(sbi);
> s->s_fs_info = NULL;
> - kill_anon_super(s);
> fail_unlock:
> return -EINVAL;
> }
>
> --
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL
Re: [RFC] [PATCH] virtual memmap on sparsemem v3 [3/4] static virtual mem_map
On Fri, 8 Dec 2006 19:33:23 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > > Would prefer to unconditionally include the header file - conditional > > > inclusions > > > like this can cause compile failures when someone changes a config > > > option. They > > > generally raise the complexity level. > > > > > Okay. > > Now, forward declearation of 'struct page' is in mmzone.h. > > I'll remove it and include mm_types.h instead of it. > > If someone says "Don't do that", I'll look for anothere way. > > > > This header needs mm_types.h, so including it is certainly OK - there's no > choice. But I think it'd be better to include mm_types.h outside of any > ifdefs. Just stick the #include at the start of the file as usual. > Okay, I'll make clean up patch in that way. Thanks, -Kame - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [PATCH] virtual memmap on sparsemem v3 [3/4] static virtual mem_map
On Sat, 9 Dec 2006 11:49:50 +0900 KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote: > On Fri, 8 Dec 2006 16:30:20 -0800 > Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > +#ifdef CONFIG_SPARSEMEM_VMEMMAP_STATIC > > > +#include > > > +extern struct page mem_map[]; > > > +#else > > > extern struct page* mem_map; > > > #endif > > > +#endif > > > > This looks rather unpleasant - what went wrong here? > > > definition of 'struct page' is necessary before declearing array[]. (for > gcc-4.0) hm, OK, that declaration needs all of `struct page' in scope. > > > Would prefer to unconditionally include the header file - conditional > > inclusions > > like this can cause compile failures when someone changes a config option. > > They > > generally raise the complexity level. > > > Okay. > Now, forward declearation of 'struct page' is in mmzone.h. > I'll remove it and include mm_types.h instead of it. > If someone says "Don't do that", I'll look for anothere way. > This header needs mm_types.h, so including it is certainly OK - there's no choice. But I think it'd be better to include mm_types.h outside of any ifdefs. Just stick the #include at the start of the file as usual. - 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: [stable] [patch 00/32] -stable review
* Chuck Ebbert ([EMAIL PROTECTED]) wrote:
> In-Reply-To: <[EMAIL PROTECTED]>
>
> On Fri, 8 Dec 2006 16:38:10 -0800, Chris Wright wrote:
>
> > And a roll-up is available at:
> >
> >
> > http://www.kernel.org/pub/linux/kernel/people/chrisw/stable/patch-2.6.19.1-rc1.{gz,bz2}
>
> Would it be possible to make this available as a quilt patchset, like this:
Well, that's how we keep it in stable-queue. For example, there's a quilt
series
in k.o/pub/scm/linux/kernel/git/stable/stable-queue/review-2.6.19
Can you pull from that?
thanks,
-chris
-
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.19-git libusual: modprobe for usb-storage succeeded, but module is not present
On Fri, 08 Dec 2006 19:08:29 -0600, [EMAIL PROTECTED] wrote: > usb 2-2: new high speed USB device using ehci_hcd and address 3 > usb 2-2: configuration #1 chosen from 1 choice > libusual: modprobe for usb-storage succeeded, but module is not present > usb 2-4: new high speed USB device using ehci_hcd and address 5 > usb 2-4: configuration #1 chosen from 1 choice > libusual: modprobe for usb-storage succeeded, but module is not present > usb 2-5: new high speed USB device using ehci_hcd and address 6 > usb 2-5: configuration #1 chosen from 1 choice > libusual: modprobe for usb-storage succeeded, but module is not present I don't know what you've done to accomplish it, but either your modules got separated (e.g. libusual built statically while usb-storage is dynamic), or your modprobe is toast, or 100 other reasons. Just deconfigure CONFIG_BLK_DEV_UB and CONFIG_USB_LIBUSUAL and forget about it all. I know, I have to think of a workaround for this, but nothing is readily apparent. -- Pete - 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: [stable] [patch 00/32] -stable review
In-Reply-To: <[EMAIL PROTECTED]>
On Fri, 8 Dec 2006 16:38:10 -0800, Chris Wright wrote:
> And a roll-up is available at:
>
>
> http://www.kernel.org/pub/linux/kernel/people/chrisw/stable/patch-2.6.19.1-rc1.{gz,bz2}
Would it be possible to make this available as a quilt patchset, like this:
-rw-rw 1 me me 267 Dec 8 21:59 00_version_2.6.19.1-pre1.patch
-rw-rw 1 me me 2791 Dec 8 20:38 01_net_ipv6_ndisc_calc_pkt_length.patch
-rw-rw 1 me me 2105 Dec 8 20:40 02_net_80211_softmac_tx_no_disable.patch
-rw-rw 1 me me 3187 Dec 8 21:01
03_net_bridge_ebtables_fix_wraparound.patch
-rw-rw 1 me me 2714 Dec 8 20:59
04_net_filter_ebtables_iterator_check_zero.patch
-rw-rw 1 me me 1755 Dec 8 21:09
05_net_bridge_ebtables_loop_worst_case.patch
-rw-rw 1 me me 3240 Dec 8 21:03
06_net_bridge_ebtables_fix_size_wrap.patch
-rw-rw 1 me me 3277 Dec 8 20:48
07_net_sched_act_police_backwards_compat.patch
-rw-rw 1 me me 1406 Dec 8 21:11 08_blk_cryptoloop_select_cbc.patch
-rw-rw 1 me me 2992 Dec 8 20:36 09_acpi_revert_sci_override.patch
-rw-rw 1 me me 1803 Dec 8 20:42 10_net_sched_gact_div_by_zero_fix.patch
-rw-rw 1 me me 1729 Dec 8 20:54 11_net_sunhme_fix_x86_failure.patch
-rw-rw 1 me me 11012 Dec 8 20:38 12_net_filter_fix_hook_validation.patch
-rw-rw 1 me me 5334 Dec 8 21:10
13_net_filter_ipv4_fix_compat_validation.patch
-rw-rw 1 me me 5325 Dec 8 21:12
14_net_filter_bridge_handle_martians.patch
-rw-rw 1 me me 1944 Dec 8 21:07
15_net_80211_softmac_unbalanced_mutex.patch
-rw-rw 1 me me 2126 Dec 8 20:43 16_drv_infiniband_cleanup_deadlock.patch
-rw-rw 1 me me 2090 Dec 8 20:46 17_fs_exec_coredump_stop_rewrite.patch
-rw-rw 1 me me 1883 Dec 8 20:55 18_net_tokenring_memory_corruption.patch
-rw-rw 1 me me 2033 Dec 8 20:47 19_net_ipv4_use_output_dev_xfrm.patch
-rw-rw 1 me me 1475 Dec 8 20:51 20_drv_usb_phidget_oops.patch
-rw-rw 1 me me 1604 Dec 8 20:59 21_net_ipv4_xfrm_peer_leak.patch
-rw-rw 1 me me 1889 Dec 8 21:02
22_net_irds_incorrect_ttp_hdr_reserv.patch
-rw-rw 1 me me 1419 Dec 8 21:05
23_net_netlink_restore_compatibility.patch
-rw-rw 1 me me 2970 Dec 8 21:06 24_separate_bh_declarations.patch
-rw-rw 1 me me 1477 Dec 8 20:52 25_drv_drm_sis_linkage.patch
-rw-rw 1 me me 3445 Dec 8 20:57 26_compat_mount_skip_null_data_page.patch
-rw-rw 1 me me 1431 Dec 8 20:56 27_pm_swsusp_debug.patch
-rw-rw 1 me me 4882 Dec 8 20:44 28_fs_autofs_fill_sb_error_code.patch
-rw-rw 1 me me 2506 Dec 8 21:13 29_krnl_softirq_remove_bug_on.patch
-rw-rw 1 me me 6657 Dec 8 20:49 30_m32r_make_userspace_hdrs.patch
-rw-rw 1 me me 2472 Dec 8 20:41 31_x86_64_fix_nmi_init_hang.patch
-rw-rw 1 me me 3016 Dec 8 20:53 32_net_drv_forcedeth_disable_intx.patch
-rw-rw 1 me me 1279 Dec 8 22:01 series
It makes things much easier to review because I can use 'quilt annotate'
to find out which patch changed a line of source.
--
Chuck
"Even supernovas have their duller moments."
-
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] connector: Some fixes for ia64 unaligned access errors
On Thu, 7 Dec 2006 17:22:13 -0600, Erik Jacobson <[EMAIL PROTECTED]> wrote: > Here, we just adjust how the variables are declared and use memcopy to > avoid the error messages. > - ev->timestamp_ns = timespec_to_ns(); > + ev.timestamp_ns = timespec_to_ns(); Please try to declare u64 timestamp_ns, then copy it into the *ev instead of copying whole *ev. This ought to fix the problem if buffer[] ends aligned to 32 bits or better. Also... Since Linus does not take patches in general off l-k anymore, you have to find whoever herds the connector and feed the patch through him/her. -- Pete - 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: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, December 07, 2006 11:42 PM >> With Eric code in LinuxBIOS, it will report "No device found in debug >> port" >Hmm. At least this is partial progress :) It works in LinuxBIOS now. It will loop all connected port and find debug device. Will check in the code together with MCP55. YH - 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: Relative atime (was Re: What's in ocfs2.git)
On Tue, Dec 05, 2006 at 08:58:02PM -0800, Andrew Morton wrote:
> That's the easy part. How are we going to get mount(8) patched?
Karel, interested in taking a look at the following patch? The kernel
bits are in -mm currently.
-VAL
Add the "relatime" (relative atime) option support to mount. Relative
atime only updates the atime if the previous atime is older than the
mtime or ctime. Like noatime, but useful for applications like mutt
that need to know when a file has been read since it was last
modified.
Cc: Adrian Bunk <[EMAIL PROTECTED]>
Cc: Al Viro <[EMAIL PROTECTED]>
Cc: Karel Zak <[EMAIL PROTECTED]>
Signed-off-by: Valerie Henson <[EMAIL PROTECTED]>
---
mount/mount.8 |7 +++
mount/mount.c |6 ++
mount/mount_constants.h |4
3 files changed, 17 insertions(+)
--- util-linux-2.13-pre7.orig/mount/mount.8
+++ util-linux-2.13-pre7/mount/mount.8
@@ -586,6 +586,13 @@ access on the news spool to speed up new
.B nodiratime
Do not update directory inode access times on this filesystem.
.TP
+.B relatime
+Update inode access times relative to modify or change time. Access
+time is only updated if the previous access time was earlier than the
+current modify or change time. (Similar to noatime, but doesn't break
+mutt or other applications that need to know if a file has been read
+since the last time it was modified.)
+.TP
.B noauto
Can only be mounted explicitly (i.e., the
.B \-a
--- util-linux-2.13-pre7.orig/mount/mount.c
+++ util-linux-2.13-pre7/mount/mount.c
@@ -164,6 +164,12 @@ static const struct opt_map opt_map[] =
{ "diratime",0, 1, MS_NODIRATIME }, /* Update dir access times */
{ "nodiratime", 0, 0, MS_NODIRATIME },/* Do not update dir access times */
#endif
+#ifdef MS_RELATIME
+ { "relatime", 0, 0, MS_RELATIME }, /* Update access times relative to
+ mtime/ctime */
+ { "norelatime", 0, 1, MS_RELATIME }, /* Update access time without regard
+ to mtime/ctime */
+#endif
{ NULL, 0, 0, 0 }
};
--- util-linux-2.13-pre7.orig/mount/mount_constants.h
+++ util-linux-2.13-pre7/mount/mount_constants.h
@@ -57,6 +57,10 @@ if we have a stack or plain mount - moun
#ifndef MS_VERBOSE
#define MS_VERBOSE 0x8000 /* 32768 */
#endif
+#ifndef MS_RELATIME
+#define MS_RELATIME 0x20 /* 20: Update access times relative
+ to mtime/ctime */
+#endif
/*
* Magic mount flag number. Had to be or-ed to the flag values.
*/
-
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: CD/DVD drive errors and lost ticks
Hi.
Sorry for my late reply,.. but I've been very busy this week (dozens of
new Sun Fires that hat to be installed, etc.) ;-)
Parag Warudkar wrote:
> It seems that your kernel is using IDE for your CDROM and libata for your
> other drives.
Yes it does.
> I recall having a similar problem with my laptop (DMA Disabled) when I had
> both IDE and SATA/PATA support enabled. I had to disable IDE altogether and
> let SATA/PATA drivers handle all my drives in order to get DMA on the CDROM.
>
While this is a good idea in general,.. I doubt that it will solve my
problem,...
First of all,.. if this was a driver related issue it wouldn't happen
under windows (which I booted solely for testing reasons ;) ), too,
would it?
Secondly,... it seems that the drive isn't even able to read the CD
in,.. I mean I think that this is a drive internal issue and the drive
simply tells the kernel "wait,.. haven't read in yet" or so.
I've also hat some errors like this:
hdb: irq timeout: status=0xd0 { Busy }
ide: failed opcode was: unknown
hdb: DMA disabled
hdb: ATAPI reset complete
hdb: irq timeout: status=0x80 { Busy }
ide: failed opcode was: unknown
hdb: ATAPI reset complete
hdb: irq timeout: status=0x80 { Busy }
ide: failed opcode was: unknown
hdb: cdrom_read_intr: data underrun (4 blocks)
end_request: I/O error, dev hdb, sector 7831400
Buffer I/O error on device hdb, logical block 1957850
hdb: tray open
end_request: I/O error, dev hdb, sector 7831404
Buffer I/O error on device hdb, logical block 1957851
Buffer I/O error on device hdb, logical block 1957852
Buffer I/O error on device hdb, logical block 1957853
Buffer I/O error on device hdb, logical block 1957854
Buffer I/O error on device hdb, logical block 1957855
Buffer I/O error on device hdb, logical block 1957856
Buffer I/O error on device hdb, logical block 1957857
Buffer I/O error on device hdb, logical block 1957858
Buffer I/O error on device hdb, logical block 1957859
hdb: tray open
end_request: I/O error, dev hdb, sector 7831656
hdb: tray open
end_request: I/O error, dev hdb, sector 7831400
hdb: tray open
end_request: I/O error, dev hdb, sector 7831400
hdb: tray open
end_request: I/O error, dev hdb, sector 7831400
hdb: tray open
and so on and so on.
That happened on a DVD (successfully read in and played by the drive),..
but when I pushed the eject button (while xine sill was playing) I got
those errors,..
I assume that xine continued to read data but the DVD was already
ejected and thus the request errors
But I think there shouldn't be a request error but more something like
"no medium found" or the eject button should have been disabled at
all,... so I think something goes really wrong with that drive ;)
> Try and pass ide=noprobe option to the kernel boot command line and see if
> that makes a difference first - may be that will allow the SATA/PATA drivers
> to claim the CDROM before IDE sees it.
>
> If that won't work try and disable ATA/ATAPI/MFM/RLL support in your config
> and enable Serial ATA (prod) and Parallel ATA (experimental drivers) and
> select the right SATA drivers as built ins or modules (I think in your case
> it is going to be NVIDIA SATA support and/or AMD/Nvidia PATA support but I
> may be wrong). Then rebuild the kernel and see if your DVD drive has DMA and
> you can watch DVDs.
>
I'll do that,.. but I've already contacted my seller,.. and asked for a
new device :-) But in the meantime I can test for this stuff.
Does anyone have some answers about the following:
I had some problems with my system the last months,.. first of all the
powersupply died,.. and then I've found some data corruption problems
(see my posts here on lkml).
I think the powersupply was simply damaged,.. and I assume (correct me
if it may be likely) that nothing else was damaged when the powersupply
broke.
The data corruption error is quite sure not a hardware defect of my
system but more likely a issue that all nvidia chipset boards (or at
least many of them) have (see my threads here at lkml)
But the DVD/CD defect makes me nervous,...
Is it likely that something in my system is defect and the damage
propagates to other components and makes them defect too?
Best wishes,
Chris,
begin:vcard
fn:Mitterer, Christoph Anton
n:Mitterer;Christoph Anton
email;internet:[EMAIL PROTECTED]
x-mozilla-html:TRUE
version:2.1
end:vcard
[patch 2.6.19-git] rts-rs5c372 updates: more chips, alarm, 12hr mode, etc
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 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:
- 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 the chip IRQs requires
a seperate board-specific patch. (And an IRQ handler, handing off
labor through a work_struct...)
Note that this reverts part of a previous patch, which seems to have
included key parts of the initial version of this one. I suspect the
issue wasn't that "mode 1" didn't work on that board; the original
code to fetch the trim was broken. If "mode 1" really won't work,
that's almost certainly a bug in that board's I2C driver.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
Index: g26/drivers/rtc/rtc-rs5c372.c
===
--- g26.orig/drivers/rtc/rtc-rs5c372.c 2006-12-08 16:44:05.0 -0800
+++ g26/drivers/rtc/rtc-rs5c372.c 2006-12-08 17:08:19.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,140 @@ 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 /* (if available) */
+
+#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_rv5c387,
+};
+/* 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
+ */
struct rs5c372 {
- u8 reg_addr;
- u8 regs[17];
- struct i2c_msg msg[1];
- struct i2c_client client;
- struct rtc_device *rtc;
-};
+ struct i2c_client *client;
+ struct rtc_device *rtc;
+ enum rtc_type type;
+ unsignedtime24:1;
+ unsignedhas_irq:1;
+ charregs[16];
-static struct i2c_driver rs5c372_driver = {
- .driver = {
- .name = "rs5c372",
- },
-
Re: [RFC] [PATCH] virtual memmap on sparsemem v3 [3/4] static virtual mem_map
On Fri, 8 Dec 2006 16:30:20 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote: > > +#ifdef CONFIG_SPARSEMEM_VMEMMAP_STATIC > > +#include > > +extern struct page mem_map[]; > > +#else > > extern struct page* mem_map; > > #endif > > +#endif > > This looks rather unpleasant - what went wrong here? > definition of 'struct page' is necessary before declearing array[]. (for gcc-4.0) > Would prefer to unconditionally include the header file - conditional > inclusions > like this can cause compile failures when someone changes a config option. > They > generally raise the complexity level. > Okay. Now, forward declearation of 'struct page' is in mmzone.h. I'll remove it and include mm_types.h instead of it. If someone says "Don't do that", I'll look for anothere way. -Kame - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [PATCH] virtual memmap on sparsemem v3 [1/4] map and unmap
On Fri, 8 Dec 2006 16:28:19 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote: > Generally we prefer to simply *require* that the function vector be filled > in appropriately. So if the caller has no special needs, the caller will > set their gen_map_kern_ops.k_pte_alloc to point at pte_alloc_kernel(). > > erk, pte_alloc_kernel() is a macro. As is pmd_alloc(), etc. Well, let > that be a lesson to us. What a mess. > > I suppose we could go through and convert them all to inlines and then the > compiler will generate an out-of-line copy for us. Better would be to turn > these things into regular, out-of-line C functions. > > What a mess. > Thank you for review. I'll remove this default action. -Kame - 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] PCI legacy resource fix
> Checking the patch, my problem is that the old way, all BAR's were being > set at start = end = flags = 0. The patch makes it set all the BAR's to Yes the old quirk used to blank the resources as the values on the chip are undefined and random. This gives you corrupt resource trees and needs hacks in the drivers as well > the normal values. This is what it looks like in lspci, pre this patch: > > Region 0: I/O ports at > Region 1: I/O ports at > Region 2: I/O ports at > Region 3: I/O ports at Then your device is in legacy mode, or was disabled > So my device is not running in compatibility mode, and should not have The paste you have their shows that it almost certainly is in legacy mode. > the BAR's set, as Alan's patch does. Dump the class code and other bits during boot check how your device is seen (native v legacy/compatibility) and whether the fixup logic triggers. It should only trigger for legacy devices. Alan - 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] PCI legacy resource fix
On Sat, 2006-12-09 at 01:25 +, Ralf Baechle wrote: > On Fri, Dec 08, 2006 at 07:46:18PM -0500, Ben Collins wrote: > > > On Wed, 2006-12-06 at 13:41 +, Ralf Baechle wrote: > > > Since commit 368c73d4f689dae0807d0a2aa74c61fd2b9b075f the kernel will try > > > to update the non-writeable BAR registers 0..3 of PIIX4 IDE adapters if > > > pci_assign_unassigned_resources() is used to do full resource assignment > > > of the bus. This fails because in the PIIX4 these BAR registers have > > > implicitly assumed values and read back as zero; it used to work because > > > the kernel used to just write zero to that register the read back value > > > did match what was written. > > > > > > The fix is a new resource flag IORESOURCE_PCI_FIXED used to mark a > > > resource as non-movable. This will also be useful to keep other import > > > system resources from being moved around - for example system consoles > > > on PCI busses. > > > > I have a problem where an ich6 (SATA+PATA) is getting its port0 reserved > > by the pci quirk for libata so that it gets picked up by ata_piix. In > > current git, ata_piix complains: > > > > [ 124.507570] PCI: Unable to reserve I/O region #1:[EMAIL PROTECTED] for > > device :00:1f.2 > > > > I bisected to the same commit, 368c73d4f689dae0807d0a2aa74c61fd2b9b075f, > > however, your patch doesn't fix my problem. > > Looks like a double reservation. My patch doesn't deal with reservations > at all. I thought about resource reservations but decieded that should > be dealt with elsewhere. Checking the patch, my problem is that the old way, all BAR's were being set at start = end = flags = 0. The patch makes it set all the BAR's to the normal values. This is what it looks like in lspci, pre this patch: Region 0: I/O ports at Region 1: I/O ports at Region 2: I/O ports at Region 3: I/O ports at So my device is not running in compatibility mode, and should not have the BAR's set, as Alan's patch does. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] Import fw-ohci driver.
Jeff Garzik wrote:
Thanks for reviewing this. I'm updating my git repo with your changes now,
will send an updated patch set in a few days.
+struct descriptor {
+u32 req_count:16;
+
+u32 wait:2;
+u32 branch:2;
+u32 irq:2;
+u32 yy:1;
+u32 ping:1;
+
+u32 key:3;
+u32 status:1;
+u32 command:4;
+
+u32 data_address;
+u32 branch_address;
+
+u32 res_count:16;
+u32 transfer_status:16;
+} __attribute__ ((aligned(16)));
you probably want __le32 annotations for sparse, right?
Yup, I've done away with the bitfields and switched to a mix of __le16 and
__le32 struct fields.
+struct it_header {
+u32 sy:4;
+u32 tcode:4;
+u32 channel:6;
+u32 tag:2;
+u32 speed:3;
+u32 reserved0:13;
+u32 reserved1:16;
+u32 data_length:16;
+};
ditto.
And for the last two fields, I bet that using the normal 'u16' type
(__le16?) would generate much better code than a bitfield:16 ever would.
Yeah, as for struct descriptor, this is now just accessed as an __le32 array.
+struct fw_ohci {
+struct fw_card card;
+
+struct pci_dev *dev;
struct device* instead? grep for to_pci_dev() to see how to get pci-dev
from device.
Right, and I have the struct device pointer in struct fw_card so I just
dropped this field.
+char *registers;
should be 'void __iomem *'
Ok.
+#define FW_OHCI_MAJOR240
+#define OHCI1394_REGISTER_SIZE0x800
+#define OHCI_LOOP_COUNT500
+#define OHCI1394_PCI_HCI_Control0x40
+#define SELF_ID_BUF_SIZE0x800
consider using
enum {
constant1= 1234,
constant2= 5678,
};
for constants. These actually have some type information attached by
the compiler, and they show up as symbols in the debugger since they are
not stripped out by the C pre-processor.
All those are basically one-off constants, so maybe a static const u32 would
be better? As for the OHCI register map, I'd like to make a struct with a
bunch of __le32 fields.
+static void ar_context_run(struct ar_context *ctx)
+{
+reg_write(ctx->ohci, ctx->command_ptr, ctx->descriptor_bus | 1);
+reg_write(ctx->ohci, ctx->control_set, CONTEXT_RUN);
PCI posting?
Added here, and the other places you pointed out.
+static int
+ar_context_init(struct ar_context *ctx, struct fw_ohci *ohci, u32
control_set)
+{
+/* FIXME: cpu_to_le32. */
+
+ctx->descriptor_bus =
+dma_map_single(>dev->dev, >descriptor,
+ sizeof ctx->descriptor, PCI_DMA_TODEVICE);
+if (ctx->descriptor_bus == 0)
+return -ENOMEM;
+
+if (ctx->descriptor_bus & 0xf)
+fw_notify("descriptor not 16-byte aligned: 0x%08x\n",
+ ctx->descriptor_bus);
+
+ctx->buffer_bus =
+dma_map_single(>dev->dev, ctx->buffer,
+ sizeof ctx->buffer, PCI_DMA_FROMDEVICE);
+
+if (ctx->buffer_bus == 0)
+return -ENOMEM;
leak on error
Fixed.
+static irqreturn_t irq_handler(int irq, void *data, struct pt_regs
*unused)
+{
+struct fw_ohci *ohci = data;
+u32 event, iso_event;
+int i;
+
+event = reg_read(ohci, OHCI1394_IntEventClear);
+
+if (!event)
+return IRQ_NONE;
check for 0x also
Ok.
...
+static int ohci_enable(struct fw_card *card, u32 * config_rom, size_t
length)
+{
+struct fw_ohci *ohci = fw_ohci(card);
+
+/* When the link is not yet enabled, the atomic config rom
+ * described above is not active. We have to update
+ * ConfigRomHeader and BusOptions manually, and the write to
+ * ConfigROMmap takes effect immediately. We tie this to the
+ * enabling of the link, so we ensure that we have a valid
+ * config rom before enabling - the OHCI requires that
+ * ConfigROMhdr and BusOptions have valid values before
+ * enabling.
+ */
+
+ohci->config_rom = pci_alloc_consistent(ohci->dev, CONFIG_ROM_SIZE,
+>config_rom_bus);
+if (ohci->config_rom == NULL)
+return -ENOMEM;
+
+memset(ohci->config_rom, 0, CONFIG_ROM_SIZE);
+fw_memcpy_to_be32(ohci->config_rom, config_rom, length * 4);
+
+reg_write(ohci, OHCI1394_ConfigROMmap, ohci->config_rom_bus);
+reg_write(ohci, OHCI1394_ConfigROMhdr, config_rom[0]);
+reg_write(ohci, OHCI1394_BusOptions, config_rom[2]);
+
+reg_write(ohci, OHCI1394_AsReqFilterHiSet, 0x8000);
+
+if (request_irq(ohci->dev->irq, irq_handler,
+SA_SHIRQ, ohci_driver_name, ohci)) {
+fw_error("Failed to allocate shared interrupt %d.\n",
+ ohci->dev->irq);
+return -EIO;
leak on error
Fixed.
+static int
+ohci_set_config_rom(struct fw_card *card, u32 * config_rom, size_t
length)
+{
+struct fw_ohci *ohci;
+unsigned long flags;
+int retval = 0;
+
+ohci = fw_ohci(card);
+
+/* When the OHCI controller is enabled, the config rom update
+ * mechanism is a bit tricky, but easy enough to use. See
+ * section
[BUG] acpi: failed to poweroff
Hi, all. I got a hasee notebook, and failed to poweroff after win soundcard (ALC861) problem. I seen someone said acpi=off may help this, but when I append it on kernel parameter list, the kernel even can not boot, the kernel just said "hdc: lost interrupt" at last, and freezeing. The dmesg is in the attachment. What do you need more? Any word is welcome. Thanks in advanced. -Liyu Linux version 2.6.19 ([EMAIL PROTECTED]) (gcc version 3.4.5 20051201 (Co-Create 3.4.5-2.cocreate.3)) #18 SMP PREEMPT Fri Dec 8 18:07:02 CST 2006 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e - 0010 (reserved) BIOS-e820: 0010 - 3fcf7000 (usable) BIOS-e820: 3fcf7000 - 3fcff000 (reserved) BIOS-e820: 3fcff000 - 3fdbd000 (usable) BIOS-e820: 3fdbd000 - 3fdbf000 (reserved) BIOS-e820: 3fdbf000 - 3fe8a000 (usable) BIOS-e820: 3fe8a000 - 3febf000 (ACPI NVS) BIOS-e820: 3febf000 - 3ff0 (ACPI data) BIOS-e820: 3ff0 - 4000 (reserved) BIOS-e820: e000 - f000 (reserved) BIOS-e820: fec0 - fec01000 (reserved) BIOS-e820: fed14000 - fed1a000 (reserved) BIOS-e820: fed1c000 - fed2 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: fff0 - 0001 (reserved) user-defined physical RAM map: user: - 0009fc00 (usable) user: 0009fc00 - 000a (reserved) user: 000e - 0010 (reserved) user: 0010 - 3fcf7000 (usable) user: 3fcf7000 - 3fcff000 (reserved) user: 3fcff000 - 3fdbd000 (usable) user: 3fdbd000 - 3fdbf000 (reserved) user: 3fdbf000 - 3fe8a000 (usable) Warning only 896MB will be used. Use a HIGHMEM enabled kernel. 896MB LOWMEM available. found SMP MP-table at 000fe060 Entering add_active_range(0, 0, 229376) 0 entries of 256 used Zone PFN ranges: DMA 0 -> 4096 Normal 4096 -> 229376 early_node_map[1] active PFN ranges 0:0 -> 229376 On node 0 totalpages: 229376 DMA zone: 32 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4064 pages, LIFO batch:0 Normal zone: 1760 pages used for memmap Normal zone: 223520 pages, LIFO batch:31 DMI 2.3 present. ACPI: RSDP (v000 NEC ) @ 0x000fe020 ACPI: RSDT (v001 NECH2O 0x0001 0x0113) @ 0x3fefe038 ACPI: FADT (v001 NECH2O 0x0001 MSFT 0x0113) @ 0x3fefd000 ACPI: SSDT (v001 NECH2O 0x0001 MSFT 0x0113) @ 0x3fef7000 ACPI: MADT (v001 NECH2O 0x0001 MSFT 0x0113) @ 0x3fef6000 ACPI: MCFG (v001 NECH2O 0x0001 MSFT 0x0113) @ 0x3fef4000 ACPI: DSDT (v001 NECH2O 0x0001 MSFT 0x0113) @ 0x ACPI: PM-Timer IO Port: 0x408 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 6:15 APIC version 20 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 6:15 APIC version 20 ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1]) ACPI: IOAPIC (id[0x04] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 4, version 32, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 4000 (gap: 3fe8a000:c0176000) Detected 1995.066 MHz processor. Built 1 zonelists. Total pages: 227584 Kernel command line: ro root=LABEL=/ 1 mem=1047080K mapped APIC to d000 (fee0) mapped IOAPIC to c000 (fec0) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 PID hash table entries: 4096 (order: 12, 16384 bytes) Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 904036k/917504k available (2577k kernel code, 12944k reserved, 1040k data, 252k init, 0k highmem) virtual kernel memory layout: fixmap : 0xfffb7000 - 0xf000 ( 288 kB) vmalloc : 0xf880 - 0xfffb5000 ( 119 MB) lowmem : 0xc000 - 0xf800 ( 896 MB) .init : 0xc048f000 - 0xc04ce000 ( 252 kB) .data : 0xc0384487 - 0xc048852c (1040 kB) .text : 0xc010 - 0xc0384487 (2577 kB) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay
Re: [PATCH 0/4] atl1: Revised Attansic L1 ethernet driver
I've got the p5B-E board to with the onboard attansic l1. I did the the atl1-2.0.2 patch against the 2.6.19.rc6 kernel. I can confirm the card is working but performance is *really* bad, 200Kb/s over Gbit LAN. I tried copying a ~50MB file over SSH and it didn't complete because of a connection stall. I also tried turninig off TSO as adviced, but i got the message "operation not supported". Im willing to do more testing, just tell me what I can do. Greetings Vasco Jay Cliburn wrote: > > Luca Tettamanti wrote: > >> Got the board, done some basic testing: so far so good :) >> >> The controller also supports MSI and (at least with my chipset - G965) >> it works fine: >> >> 218: 80649 0 PCI-MSI-edge eth1 >> >> which is nice, otherwise it ends up sharing the IRQ with SATA and USB. >> >> I also have a small patch: > > Thanks for the patch. We'll add it for the next version. > > FYI, TSO performance is _really_ bad; your tx speed will drop dramatically > with > TSO on (and it's on by default). I haven't yet been able to find the > problem. > If you want to improve tx performance, turn off TSO with ethtool. > > Jay > - > 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/ > > -- View this message in context: http://www.nabble.com/-PATCH-0-4--atl1%3A-Revised-Attansic-L1-ethernet-driver-tf2665327.html#a7768448 Sent from the linux-kernel mailing list archive at Nabble.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 0/4] atl1: Revised Attansic L1 ethernet driver
I've got the p5B-E board to with the onboard attansic l1. I did the the atl1-2.0.2 patch against the 2.6.19.rc6 kernel. I can confirm the card is working but performance is *really* bad, 200Kb/s over Gbit LAN. I tried copying a ~50MB file over SSH and it didn't complete because of a connection stall. I also tried turninig off TSO as adviced, but i got the message "operation not supported". Im willing to do more testing, just tell me what I can do. Greetings Vasco Jay Cliburn wrote: > > Luca Tettamanti wrote: > >> Got the board, done some basic testing: so far so good :) >> >> The controller also supports MSI and (at least with my chipset - G965) >> it works fine: >> >> 218: 80649 0 PCI-MSI-edge eth1 >> >> which is nice, otherwise it ends up sharing the IRQ with SATA and USB. >> >> I also have a small patch: > > Thanks for the patch. We'll add it for the next version. > > FYI, TSO performance is _really_ bad; your tx speed will drop dramatically > with > TSO on (and it's on by default). I haven't yet been able to find the > problem. > If you want to improve tx performance, turn off TSO with ethtool. > > Jay > - > 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/ > > -- View this message in context: http://www.nabble.com/-PATCH-0-4--atl1%3A-Revised-Attansic-L1-ethernet-driver-tf2665327.html#a7768447 Sent from the linux-kernel mailing list archive at Nabble.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: BUG: warning at drivers/scsi/ahci.c:859/ahci_host_intr() [ 2.6.17.14 ]
On Sat, Dec 09, 2006 at 01:18:30AM +, Alan wrote:
> On Fri, 8 Dec 2006 20:05:07 -0500
> koan <[EMAIL PROTECTED]> wrote:
>
> > ata4: status=0x50 { DriveReady SeekComplete }
> > ata4: error=0x01 { AddrMarkNotFound }
>
> That looks like a genuine drive problem.
Is a disk driver supposed to BUG() on a drive missing sector though?
OG.
-
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 33/32] NETLINK: Put {IFA,IFLA}_{RTA,PAYLOAD} macros back for userspace.
-stable review patch. If anyone has any objections, please let us know.
--
From: David Miller <[EMAIL PROTECTED]>
NETLINK: Put {IFA,IFLA}_{RTA,PAYLOAD} macros back for userspace.
GLIBC uses them etc.
They are guarded by ifndef __KERNEL__ so nobody will start
accidently using them in the kernel again, it's just for
userspace.
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
commit c0279128f20aa3580b0b43aaa49f351f6bad5f30
Author: David S. Miller <[EMAIL PROTECTED]>
Date: Fri Dec 8 17:05:13 2006 -0800
include/linux/if_addr.h |6 ++
include/linux/if_link.h |6 ++
2 files changed, 12 insertions(+)
--- linux-2.6.19.orig/include/linux/if_addr.h
+++ linux-2.6.19/include/linux/if_addr.h
@@ -52,4 +52,10 @@ struct ifa_cacheinfo
__u32 tstamp; /* updated timestamp, hundredths of seconds */
};
+/* backwards compatibility for userspace */
+#ifndef __KERNEL__
+#define IFA_RTA(r) ((struct rtattr*)(((char*)(r)) + NLMSG_ALIGN(sizeof(struct
ifaddrmsg
+#define IFA_PAYLOAD(n) NLMSG_PAYLOAD(n,sizeof(struct ifaddrmsg))
+#endif
+
#endif
--- linux-2.6.19.orig/include/linux/if_link.h
+++ linux-2.6.19/include/linux/if_link.h
@@ -82,6 +82,12 @@ enum
#define IFLA_MAX (__IFLA_MAX - 1)
+/* backwards compatibility for userspace */
+#ifndef __KERNEL__
+#define IFLA_RTA(r) ((struct rtattr*)(((char*)(r)) +
NLMSG_ALIGN(sizeof(struct ifinfomsg
+#define IFLA_PAYLOAD(n) NLMSG_PAYLOAD(n,sizeof(struct ifinfomsg))
+#endif
+
/* ifi_flags.
IFF_* flags.
-
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] PCI legacy resource fix
On Fri, Dec 08, 2006 at 07:46:18PM -0500, Ben Collins wrote: > On Wed, 2006-12-06 at 13:41 +, Ralf Baechle wrote: > > Since commit 368c73d4f689dae0807d0a2aa74c61fd2b9b075f the kernel will try > > to update the non-writeable BAR registers 0..3 of PIIX4 IDE adapters if > > pci_assign_unassigned_resources() is used to do full resource assignment > > of the bus. This fails because in the PIIX4 these BAR registers have > > implicitly assumed values and read back as zero; it used to work because > > the kernel used to just write zero to that register the read back value > > did match what was written. > > > > The fix is a new resource flag IORESOURCE_PCI_FIXED used to mark a > > resource as non-movable. This will also be useful to keep other import > > system resources from being moved around - for example system consoles > > on PCI busses. > > I have a problem where an ich6 (SATA+PATA) is getting its port0 reserved > by the pci quirk for libata so that it gets picked up by ata_piix. In > current git, ata_piix complains: > > [ 124.507570] PCI: Unable to reserve I/O region #1:[EMAIL PROTECTED] for > device :00:1f.2 > > I bisected to the same commit, 368c73d4f689dae0807d0a2aa74c61fd2b9b075f, > however, your patch doesn't fix my problem. Looks like a double reservation. My patch doesn't deal with reservations at all. I thought about resource reservations but decieded that should be dealt with elsewhere. Ralf - 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/
oops on 2.6.19-rc6-mm2: deref of 0x28 at permission+0x7
Hi! I got this oops on 2.6.19-rc6-mm2 when starting the system. It happened only once -- when echo "raidautorun /dev/md0" | nash --quiet was executed. I don't know why it happened, after reboot it started OK. There is no md0, only md1, md2 and md3. See camera-shots here: http://www.fi.muni.cz/~xslaby/sklad/dm_oops1.png http://www.fi.muni.cz/~xslaby/sklad/dm_oops2.png regards, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC][PATCH 2/2] x86_64: earlyprintk usb debug device support.
-Original Message- From: Greg KH [mailto:[EMAIL PROTECTED] Sent: Friday, December 08, 2006 5:17 PM >Buffer size? flow control? the fact that the buffer has already >overflowed? Who knows, don't trust usb-serial as a real "console" >please :) I set buffer size to 128k, and can get all. Thanks YH - 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.19-git libusual: modprobe for usb-storage succeeded, but module is not present
to: linux-kernel@vger.kernel.org cc: [EMAIL PROTECTED] 2.6.19-git libusual: modprobe for usb-storage succeeded, but module is not present Linux version 2.6.19-200612081830-g17097758 ([EMAIL PROTECTED]) (gcc version 4.1.1 20061011 ) #16 SMP PREEMPT Fri Dec 8 18:37:41 CST 2006 Command line: ro root=/dev/VolGroup00/LogVol00 rhgb mem=3583M ... AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ stepping 01 ... usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb ... usbcore: registered new interface driver libusual usbcore: registered new interface driver hiddev usbcore: registered new interface driver usbhid drivers/usb/input/hid-core.c: v2.6:USB HID core driver ... ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI) ACPI: PCI Interrupt Link [APCF] enabled at IRQ 23 ACPI: PCI Interrupt :00:0b.0[A] -> Link [APCF] -> GSI 23 (level, low) -> IRQ 23 PCI: Setting latency timer of device :00:0b.0 to 64 ohci_hcd :00:0b.0: OHCI Host Controller ohci_hcd :00:0b.0: new USB bus registered, assigned bus number 1 ohci_hcd :00:0b.0: irq 23, io mem 0xfe02f000 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 8 ports detected ACPI: PCI Interrupt Link [APCL] enabled at IRQ 22 ACPI: PCI Interrupt :00:0b.1[B] -> Link [APCL] -> GSI 22 (level, low) -> IRQ 22 PCI: Setting latency timer of device :00:0b.1 to 64 ehci_hcd :00:0b.1: EHCI Host Controller ehci_hcd :00:0b.1: new USB bus registered, assigned bus number 2 ehci_hcd :00:0b.1: debug port 1 PCI: cache line size of 64 is not supported by device :00:0b.1 ehci_hcd :00:0b.1: irq 22, io mem 0xfe02e000 ehci_hcd :00:0b.1: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 usb usb2: configuration #1 chosen from 1 choice hub 2-0:1.0: USB hub found hub 2-0:1.0: 8 ports detected SCSI subsystem initialized ACPI: PCI Interrupt Link [APC2] enabled at IRQ 17 ACPI: PCI Interrupt :03:09.0[A] -> Link [APC2] -> GSI 17 (level, low) -> IRQ 17 usb 2-1: new high speed USB device using ehci_hcd and address 2 usb 2-1: configuration #1 chosen from 1 choice hub 2-1:1.0: USB hub found hub 2-1:1.0: 4 ports detected usb 2-2: new high speed USB device using ehci_hcd and address 3 usb 2-2: configuration #1 chosen from 1 choice libusual: modprobe for usb-storage succeeded, but module is not present usb 2-4: new high speed USB device using ehci_hcd and address 5 usb 2-4: configuration #1 chosen from 1 choice libusual: modprobe for usb-storage succeeded, but module is not present usb 2-5: new high speed USB device using ehci_hcd and address 6 usb 2-5: configuration #1 chosen from 1 choice libusual: modprobe for usb-storage succeeded, but module is not present ^^^ xboom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 2/2] x86_64: earlyprintk usb debug device support.
On Wed, Dec 06, 2006 at 07:20:16PM -0800, Lu, Yinghai wrote: > Greg, > > I wonder why the netconsole could print all boot log from beginning with > buffer. But your usb serial console can not. Buffer size? flow control? the fact that the buffer has already overflowed? Who knows, don't trust usb-serial as a real "console" please :) 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/
Re: BUG: warning at drivers/scsi/ahci.c:859/ahci_host_intr() [ 2.6.17.14 ]
On Fri, 8 Dec 2006 20:05:07 -0500
koan <[EMAIL PROTECTED]> wrote:
> ata4: status=0x50 { DriveReady SeekComplete }
> ata4: error=0x01 { AddrMarkNotFound }
That looks like a genuine drive problem.
Alan
-
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/
BUG: warning at drivers/scsi/ahci.c:859/ahci_host_intr() [ 2.6.17.14 ]
Hello,
After 33 days of uptime, I noticed something in my dmesg output.
The system is 4 x SATA2 disks connected to the onboard SATA2
controller. They are all part of a linux software raid 5 volume.
According to /proc/mdstat , all of the disks are still online (?).
Right now the system is still up, so if more information is needed I
should be able to provide it (given some instruction). I am not on the
list, so please CC me.
Thanks, Jesse
This is the message:
ata4: handling error/timeout
ata4: port reset, p_is 0 is 0 pis 0 cmd 1c017 tf d0 ss 123 se 180001
BUG: warning at drivers/scsi/ahci.c:859/ahci_host_intr()
ahci_interrupt+0xff/0x20b handle_IRQ_event+0x21/0x4a
__do_IRQ+0x53/0x8f scsi_error_handler+0x0/0xa1
do_IRQ+0x19/0x24 common_interrupt+0x1a/0x20
scsi_error_handler+0x0/0xa1 ahci_eng_timeout+0x55/0x5d
ata_scsi_error+0x89/0xd3 scsi_error_handler+0x5f/0xa1
kthread+0x75/0x9d kthread+0x0/0x9d
kernel_thread_helper+0x5/0xb
ata4: status=0x50 { DriveReady SeekComplete }
sdd: Current: sense key=0x0
ASC=0x0 ASCQ=0x0
Info fld=0xf5a623e
ata2: handling error/timeout
ata2: port reset, p_is 0 is 0 pis 0 cmd 1c017 tf d0 ss 123 se 180001
BUG: warning at drivers/scsi/ahci.c:859/ahci_host_intr()
ahci_interrupt+0xff/0x20b handle_IRQ_event+0x21/0x4a
__do_IRQ+0x53/0x8f scsi_error_handler+0x0/0xa1
do_IRQ+0x19/0x24 common_interrupt+0x1a/0x20
scsi_error_handler+0x0/0xa1 ahci_eng_timeout+0x55/0x5d
ata_scsi_error+0x89/0xd3 scsi_error_handler+0x5f/0xa1
kthread+0x75/0x9d kthread+0x0/0x9d
kernel_thread_helper+0x5/0xb
ata2: status=0x50 { DriveReady SeekComplete }
sdb: Current: sense key=0x0
ASC=0x0 ASCQ=0x0
ata4: handling error/timeout
ata4: port reset, p_is 0 is 0 pis 0 cmd 1c017 tf 150 ss 123 se 0
ata4: status=0x50 { DriveReady SeekComplete }
ata4: error=0x01 { AddrMarkNotFound }
sdd: Current: sense key=0x0
ASC=0x0 ASCQ=0x0
Info fld=0x1
ata2: handling error/timeout
ata2: port reset, p_is 0 is 0 pis 0 cmd 1c017 tf 150 ss 123 se 0
ata2: status=0x50 { DriveReady SeekComplete }
ata2: error=0x01 { AddrMarkNotFound }
sdb: Current: sense key=0x0
ASC=0x0 ASCQ=0x0
This is my normal boot message:
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ALI15X3: IDE controller at PCI slot :00:16.0
ACPI: PCI Interrupt :00:16.0[A] -> GSI 19 (level, low) -> IRQ 21
ALI15X3: chipset revision 199
ALI15X3: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xff00-0xff07, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xff08-0xff0f, BIOS settings: hdc:pio, hdd:pio
Probing IDE interface ide0...
hda: IBM-DTTA-350430, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
Probing IDE interface ide1...
hda: max request size: 128KiB
hda: 8249472 sectors (4223 MB) w/469KiB Cache, CHS=8184/16/63, UDMA(33)
hda: cache flushes not supported
hda: hda1 hda2
libata version 1.20 loaded.
ahci :00:16.1: version 1.2
ACPI: PCI Interrupt :00:16.1[A] -> GSI 19 (level, low) -> IRQ 21
ahci :00:16.1: AHCI 0001. 32 slots 4 ports 3 Gbps 0xf impl SATA mode
ahci :00:16.1: flags: ncq ilck pm led clo pmp pio slum part
ata1: SATA max UDMA/133 cmd 0xF8806100 ctl 0x0 bmdma 0x0 irq 21
ata2: SATA max UDMA/133 cmd 0xF8806180 ctl 0x0 bmdma 0x0 irq 21
ata3: SATA max UDMA/133 cmd 0xF8806200 ctl 0x0 bmdma 0x0 irq 21
ata4: SATA max UDMA/133 cmd 0xF8806280 ctl 0x0 bmdma 0x0 irq 21
ata1: SATA link up 3.0 Gbps (SStatus 123)
ata1: dev 0 cfg 49:2f00 82:746b 83:7f01 84:4023 85:7469 86:3c01 87:4023 88:40ff
ata1: dev 0 ATA-7, max UDMA7, 586072368 sectors: LBA48
ata1: dev 0 configured for UDMA/133
scsi0 : ahci
ata2: SATA link up 3.0 Gbps (SStatus 123)
ata2: dev 0 cfg 49:2f00 82:346b 83:7d01 84:4023 85:3469 86:3c01 87:4023 88:407f
ata2: dev 0 ATA-7, max UDMA/133, 625142448 sectors: LBA48
ata2: dev 0 configured for UDMA/133
scsi1 : ahci
ata3: SATA link up 3.0 Gbps (SStatus 123)
ata3: dev 0 cfg 49:2f00 82:346b 83:7d01 84:4023 85:3469 86:3c01 87:4023 88:407f
ata3: dev 0 ATA-7, max UDMA/133, 586072368 sectors: LBA48
ata3: dev 0 configured for UDMA/133
scsi2 : ahci
ata4: SATA link up 3.0 Gbps (SStatus 123)
ata4: dev 0 cfg 49:2f00 82:346b 83:7d01 84:4023 85:3469 86:3c01 87:4023 88:407f
ata4: dev 0 ATA-7, max UDMA/133, 586072368 sectors: LBA48
ata4: dev 0 configured for UDMA/133
scsi3 : ahci
Vendor: ATA Model: SAMSUNG HD300LJ Rev: ZT10
Type: Direct-Access ANSI SCSI revision: 05
Vendor: ATA Model: ST3320620AS Rev: 3.AA
Type: Direct-Access ANSI SCSI revision: 05
Vendor: ATA Model: ST3300822AS Rev: 3.AA
Type: Direct-Access ANSI SCSI revision: 05
Vendor: ATA Model: ST3300822AS Rev: 3.AA
Type: Direct-Access ANSI SCSI revision: 05
SCSI device sda: 586072368 512-byte hdwr sectors (300069 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive
Re: Possible circular locking in ntfs on 2.6.19-rc5-mm2 (now 2.6.19-rc6-mm2)
Jiri Slaby wrote:
> -- Forwarded message --
> From: Larry Finger <[EMAIL PROTECTED]>
> Date: Nov 24, 2006 5:17 PM
> Subject: Possible circular locking in ntfs on 2.6.19-rc5-mm2
> To: LKML , [EMAIL PROTECTED]
>
>
> On kernel 2.6.19-rc5-mm2, my log shows the following dump of a
> possible circular locking problem.
> The dump occurred while running an updatedb command that was initiated
> by cron.
>
> Nov 24 02:13:23 larrylap kernel:
> ===
> Nov 24 02:13:23 larrylap kernel: [ INFO: possible circular locking
> dependency detected ]
> Nov 24 02:13:23 larrylap kernel: 2.6.19-rc5-mm2-DSCA #4
> Nov 24 02:13:23 larrylap kernel:
> ---
> Nov 24 02:13:23 larrylap kernel: find/32325 is trying to acquire lock:
> Nov 24 02:13:23 larrylap kernel: (iprune_mutex){--..}, at:
> [] mutex_lock+0x29/0x30
> Nov 24 02:13:23 larrylap kernel:
> Nov 24 02:13:23 larrylap kernel: but task is already holding lock:
> Nov 24 02:13:23 larrylap kernel: (>mrec_lock){--..}, at:
> [] mutex_lock+0x29/0x30
> Nov 24 02:13:23 larrylap kernel:
> Nov 24 02:13:23 larrylap kernel: which lock already depends on the new
> lock.
> Nov 24 02:13:23 larrylap kernel:
> Nov 24 02:13:25 larrylap kernel:
> Nov 24 02:13:25 larrylap kernel: the existing dependency chain (in
> reverse order) is:
> Nov 24 02:13:25 larrylap kernel:
> Nov 24 02:13:25 larrylap kernel: -> #2 (>mrec_lock){--..}:
> Nov 24 02:13:25 larrylap kernel:[]
> add_lock_to_list+0x3d/0xb0
> Nov 24 02:13:25 larrylap kernel:[]
> __lock_acquire+0xac7/0xcd0
> Nov 24 02:13:25 larrylap kernel:[] lock_acquire+0x62/0x80
> Nov 24 02:13:25 larrylap kernel:[]
> __mutex_lock_slowpath+0x7f/0x280
> Nov 24 02:13:25 larrylap kernel:[] mutex_lock+0x29/0x30
> Nov 24 02:13:25 larrylap kernel:[]
> map_mft_record+0x1c/0x260 [ntfs]
> Nov 24 02:13:25 larrylap kernel:[]
> ntfs_map_runlist_nolock+0x3dc/0x520 [ntfs]
> Nov 24 02:13:25 larrylap kernel:[]
> ntfs_map_runlist+0x54/0x80 [ntfs]
> Nov 24 02:13:25 larrylap kernel:[]
> ntfs_readpage+0x7d8/0x930 [ntfs]
> Nov 24 02:13:25 larrylap kernel:[]
> read_cache_page+0xa3/0x180
> Nov 24 02:13:25 larrylap kernel:[]
> ntfs_lookup_inode_by_name+0x3c6/0xde0 [ntfs]
> Nov 24 02:13:25 larrylap kernel:[]
> ntfs_lookup+0x65/0x5e0 [ntfs]
> Nov 24 02:13:25 larrylap kernel:[] do_lookup+0x144/0x190
> Nov 24 02:13:25 larrylap kernel:[]
> __link_path_walk+0x144/0xe00
> Nov 24 02:13:25 larrylap kernel:[]
> link_path_walk+0x4e/0xe0
> Nov 24 02:13:25 larrylap kernel:[]
> do_path_lookup+0x8c/0x1d0
> Nov 24 02:13:25 larrylap kernel:[]
> __path_lookup_intent_open+0x4a/0x90
> Nov 24 02:13:25 larrylap kernel:[]
> path_lookup_open+0x2a/0x30
> Nov 24 02:13:25 larrylap kernel:[] open_namei+0x77/0x6a0
> Nov 24 02:13:25 larrylap kernel:[] do_filp_open+0x38/0x60
> Nov 24 02:13:25 larrylap kernel:[] do_sys_open+0x4b/0x100
> Nov 24 02:13:25 larrylap kernel:[] sys_open+0x27/0x30
> Nov 24 02:13:25 larrylap kernel:[]
> sysenter_past_esp+0x5f/0x99
> Nov 24 02:13:25 larrylap kernel:[] 0xb7f72410
> Nov 24 02:13:25 larrylap kernel:[] 0x
> Nov 24 02:13:25 larrylap kernel:
> Nov 24 02:13:25 larrylap kernel: -> #1 (>lock){}:
> Nov 24 02:13:25 larrylap kernel:[]
> add_lock_to_list+0x3d/0xb0
> Nov 24 02:13:25 larrylap kernel:[]
> __lock_acquire+0xac7/0xcd0
> Nov 24 02:13:25 larrylap kernel:[] lock_acquire+0x62/0x80
> Nov 24 02:13:25 larrylap kernel:[] down_write+0x55/0x70
> Nov 24 02:13:25 larrylap kernel:[]
> __ntfs_clear_inode+0x15/0x160 [ntfs]
> Nov 24 02:13:25 larrylap kernel:[]
> ntfs_clear_big_inode+0x69/0xf0 [ntfs]
> Nov 24 02:13:25 larrylap kernel:[] clear_inode+0x92/0x130
> Nov 24 02:13:25 larrylap kernel:[]
> dispose_list+0x28/0x100
> Nov 24 02:13:25 larrylap kernel:[]
> shrink_icache_memory+0x1ed/0x220
> Nov 24 02:13:26 larrylap kernel:[]
> shrink_slab+0x122/0x1a0
> Nov 24 02:13:26 larrylap kernel:[] kswapd+0x287/0x420
> Nov 24 02:13:26 larrylap kernel:[] kthread+0xdb/0xe0
> Nov 24 02:13:26 larrylap kernel:[]
> kernel_thread_helper+0x7/0x14
> Nov 24 02:13:26 larrylap kernel:[] 0x
> Nov 24 02:13:26 larrylap kernel:
> Nov 24 02:13:26 larrylap kernel: -> #0 (iprune_mutex){--..}:
> Nov 24 02:13:26 larrylap kernel:[]
> print_circular_bug_tail+0x46/0x90
> Nov 24 02:13:26 larrylap kernel:[]
> __lock_acquire+0x929/0xcd0
> Nov 24 02:13:26 larrylap kernel:[] lock_acquire+0x62/0x80
> Nov 24 02:13:26 larrylap kernel:[]
> __mutex_lock_slowpath+0x7f/0x280
> Nov 24 02:13:26 larrylap kernel:[] mutex_lock+0x29/0x30
> Nov 24 02:13:26 larrylap kernel:[]
> shrink_icache_memory+0x61/0x220
> Nov 24 02:13:26 larrylap kernel:[]
>
[PATCH 1/1 v3] Char: isicom, fix card locking
me wrote:
> If nothing appeared in dmesg (even before setserial) and the second option is
> enabled, then I'm out of clues for now (however I revealed another recursive
> locking issue in close() function). Could you apply this dirty hack
Ok, this third version covers the revealed recursion. Could you test it?
--
isicom, fix card locking
- Somebody omitted spin_unlock in interrupt handler and hence card causes
deadlock. Add two unlocks, before returning from handler, if the lock was
acquired before.
- Recursive locking causes deadlock when _open and _close is called on SMP
machine, fix this by avoiding recursion.
Thanks Eric Fox <[EMAIL PROTECTED]> for pointing these out.
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
---
commit d1cf4c06710e37fee58dbca38e08b236ba8ff50c
tree da27dc848eb073662174276ab7e0472c9da4193c
parent 1240cd642c42688fab680d1d783eb1821ded9490
author Jiri Slaby <[EMAIL PROTECTED]> Thu, 07 Dec 2006 17:42:51 +0059
committer Jiri Slaby <[EMAIL PROTECTED]> Thu, 07 Dec 2006 17:42:51 +0059
isicom.c | 105 +++
1 file changed, 53 insertions(+), 52 deletions(-)
diff --git a/drivers/char/isicom.c b/drivers/char/isicom.c
index 1637c1d..adbb16d 100644
--- a/drivers/char/isicom.c
+++ b/drivers/char/isicom.c
@@ -228,6 +228,20 @@ static struct isi_port isi_ports[PORT_C
* it wants to talk.
*/
+static inline int WaitTillCardIsFree(u16 base)
+{
+ unsigned int count = 0;
+ unsigned int a = in_atomic(); /* do we run under spinlock? */
+
+ while (!(inw(base + 0xe) & 0x1) && count++ < 100)
+ if (a)
+ mdelay(1);
+ else
+ msleep(1);
+
+ return !(inw(base + 0xe) & 0x1);
+}
+
static int lock_card(struct isi_board *card)
{
charretries;
@@ -274,69 +288,71 @@ static void unlock_card(struct isi_board
* ISI Card specific ops ...
*/
+/* card->lock HAS to be held */
static void raise_dtr(struct isi_port *port)
{
struct isi_board *card = port->card;
unsigned long base = card->base;
u16 channel = port->channel;
- if (!lock_card(card))
+ if (WaitTillCardIsFree(base))
return;
outw(0x8000 | (channel << card->shift_count) | 0x02, base);
outw(0x0504, base);
InterruptTheCard(base);
port->status |= ISI_DTR;
- unlock_card(card);
}
+/* card->lock HAS to be held */
static inline void drop_dtr(struct isi_port *port)
{
struct isi_board *card = port->card;
unsigned long base = card->base;
u16 channel = port->channel;
- if (!lock_card(card))
+ if (WaitTillCardIsFree(base))
return;
outw(0x8000 | (channel << card->shift_count) | 0x02, base);
outw(0x0404, base);
InterruptTheCard(base);
port->status &= ~ISI_DTR;
- unlock_card(card);
}
+/* card->lock HAS to be held */
static inline void raise_rts(struct isi_port *port)
{
struct isi_board *card = port->card;
unsigned long base = card->base;
u16 channel = port->channel;
- if (!lock_card(card))
+ if (WaitTillCardIsFree(base))
return;
outw(0x8000 | (channel << card->shift_count) | 0x02, base);
outw(0x0a04, base);
InterruptTheCard(base);
port->status |= ISI_RTS;
- unlock_card(card);
}
+
+/* card->lock HAS to be held */
static inline void drop_rts(struct isi_port *port)
{
struct isi_board *card = port->card;
unsigned long base = card->base;
u16 channel = port->channel;
- if (!lock_card(card))
+ if (WaitTillCardIsFree(base))
return;
outw(0x8000 | (channel << card->shift_count) | 0x02, base);
outw(0x0804, base);
InterruptTheCard(base);
port->status &= ~ISI_RTS;
- unlock_card(card);
}
+/* card->lock MUST NOT be held */
static inline void raise_dtr_rts(struct isi_port *port)
{
struct isi_board *card = port->card;
@@ -353,35 +369,20 @@ static inline void raise_dtr_rts(struct
unlock_card(card);
}
+/* card->lock HAS to be held */
static void drop_dtr_rts(struct isi_port *port)
{
struct isi_board *card = port->card;
unsigned long base = card->base;
u16 channel = port->channel;
- if (!lock_card(card))
+ if (WaitTillCardIsFree(base))
return;
outw(0x8000 | (channel << card->shift_count) | 0x02, base);
outw(0x0c04, base);
InterruptTheCard(base);
port->status &= ~(ISI_RTS | ISI_DTR);
- unlock_card(card);
-}
-
-static inline void kill_queue(struct isi_port *port, short queue)
-{
- struct isi_board *card = port->card;
- unsigned long base = card->base;
- u16 channel = port->channel;
-
- if (!lock_card(card))
- return;
-
- outw(0x8000 | (channel <<
Re: [PATCH] PCI legacy resource fix
On Wed, 2006-12-06 at 13:41 +, Ralf Baechle wrote: > Since commit 368c73d4f689dae0807d0a2aa74c61fd2b9b075f the kernel will try > to update the non-writeable BAR registers 0..3 of PIIX4 IDE adapters if > pci_assign_unassigned_resources() is used to do full resource assignment > of the bus. This fails because in the PIIX4 these BAR registers have > implicitly assumed values and read back as zero; it used to work because > the kernel used to just write zero to that register the read back value > did match what was written. > > The fix is a new resource flag IORESOURCE_PCI_FIXED used to mark a > resource as non-movable. This will also be useful to keep other import > system resources from being moved around - for example system consoles > on PCI busses. I have a problem where an ich6 (SATA+PATA) is getting its port0 reserved by the pci quirk for libata so that it gets picked up by ata_piix. In current git, ata_piix complains: [ 124.507570] PCI: Unable to reserve I/O region #1:[EMAIL PROTECTED] for device :00:1f.2 I bisected to the same commit, 368c73d4f689dae0807d0a2aa74c61fd2b9b075f, however, your patch doesn't fix my problem. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] file capabilities: two bugfixes
On Fri, Dec 08, 2006 at 01:36:57PM -0600, Serge E. Hallyn wrote: > The other is that root can lose capabilities by executing files with > only some capabilities set. The next two patches change these > behaviors. I saw this in my code review and thought that this behaviour was intentional. :) It seemed like a good idea to me.. pgpvyMp4kRq5P.pgp Description: PGP signature
Re: [stable] [patch 00/32] -stable review
And a roll-up is available at:
http://www.kernel.org/pub/linux/kernel/people/chrisw/stable/patch-2.6.19.1-rc1.{gz,bz2}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [PATCH] virtual memmap on sparsemem v3 [3/4] static virtual mem_map
On Fri, 8 Dec 2006 16:07:08 +0900 KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote: > This patch adds support for statically allocated virtual mem_map. > (means virtual address of mem_map array is defined statically.) > This removes reference to *(_map). > > Signed-Off-By: KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> > > > Index: devel-2.6.19/include/linux/mmzone.h > === > --- devel-2.6.19.orig/include/linux/mmzone.h 2006-12-08 15:04:30.0 > +0900 > +++ devel-2.6.19/include/linux/mmzone.h 2006-12-08 15:05:18.0 > +0900 > @@ -618,8 +618,13 @@ > #if (((BITS_PER_LONG/4) * PAGES_PER_SECTION) % PAGE_SIZE) != 0 > #error "PAGE_SIZE/SECTION_SIZE relationship is not suitable for vmem_map" > #endif > +#ifdef CONFIG_SPARSEMEM_VMEMMAP_STATIC > +#include > +extern struct page mem_map[]; > +#else > extern struct page* mem_map; > #endif > +#endif This looks rather unpleasant - what went wrong here? Would prefer to unconditionally include the header file - conditional inclusions like this can cause compile failures when someone changes a config option. They generally raise the complexity level. - 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.19-rt10: compilation/link failure
Hi guys I still can't get 2.6.19-rt to compile. This time it fails during the final link process: LD .tmp_vmlinux1 arch/i386/kernel/built-in.o(.text+0xf2c7): In function `smp_send_nmi_allbutself': : undefined reference to `send_IPI_mask_bitmask' make: *** [.tmp_vmlinux1] Error 1 The kernel config follows. Regards jonathan # # Automatically generated make config: don't edit # Linux kernel version: 2.6.19-rt10 # Fri Dec 8 21:48:14 2006 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set # CONFIG_IKCONFIG is not set # CONFIG_RELAY is not set CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Block layer # CONFIG_BLOCK=y CONFIG_LBD=y # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="anticipatory" # # Processor type and features # # CONFIG_HIGH_RES_TIMERS is not set # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set CONFIG_MPENTIUMM=y # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_CMPXCHG64=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y # CONFIG_HPET_TIMER is not set # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT_DESKTOP is not set CONFIG_PREEMPT_RT=y CONFIG_PREEMPT=y CONFIG_PREEMPT_SOFTIRQS=y CONFIG_PREEMPT_HARDIRQS=y CONFIG_PREEMPT_BKL=y # CONFIG_CLASSIC_RCU is not set CONFIG_PREEMPT_RCU=y CONFIG_RCU_TRACE=y CONFIG_ASM_SEMAPHORES=y CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=y CONFIG_X86_MCE_P4THERMAL=y CONFIG_VM86=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_X86_REBOOTFIXUPS is not set CONFIG_MICROCODE=m CONFIG_MICROCODE_OLD_INTERFACE=y CONFIG_X86_MSR=m CONFIG_X86_CPUID=m # # Firmware Drivers # # CONFIG_EDD is not set # CONFIG_DELL_RBU is not set # CONFIG_DCDBAS is not set # CONFIG_NOHIGHMEM is not set CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set CONFIG_PAGE_OFFSET=0xC000 CONFIG_HIGHMEM=y CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_SELECT_MEMORY_MODEL=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y CONFIG_SPARSEMEM_STATIC=y
Re: [PATCH] cpuset - rework cpuset_zone_allowed api
Paul M wrote: > While you're changing this, is there a good reason not to check > is_mem_exclusive() *before* taking callback_mutex and calling > nearest_exclusive_ancestor()? > > something like: > > rcu_read_lock(); > exc = is_mem_exclusive(rcu_dereference(current->cs)); > rcu_read_unlock(); > if (exc) > return 1; Hmmm ... Interesting suggestion, but I'm not sure this is a good idea. For one thing, shouldn't that be "return 0", not "return 1". If the current tasks cpuset is mem_exclusive, and if we've already determined that it doesn't allow the node in question, and if we've also just determined that it is itself our nearest mem_exclusive ancestor, then can't we conclude that the node in question is -not- allowed in our nearest mem_exclusive ancestor? And for another thing, it extends the RCU locking use just a teeny bit. Until now, we just RCU to let us check whether the cpuset mems_generation was changed or not, without risking an invalid memory reference. The above proposal makes stronger demands, as follows. Say for instance, another task changed our tasks cpuset just as we were running this cpuset_zone_allowed() check, from a cpuset whose -parent- would have allowed the node in question and which parent was the nearest enclosing mem_exclusive cpuset, to a different cpuset which would itself have allowed the node in question and which was marked mem_exclusive. Either the old or the new cpuset would have allowed the node, but if we flip at just the wrong instant, after we realize the node isn't allowed in the current cpuset, before we check to see if that cpuset is mem_exclusive, we would conclude that the node is not allowed. I can't imagine even a micro benchmark test case that would detect the above race failing, not to mention a real world noticable impact. But it is a lost race. Better not to code races, than to learn two years later why they might matter. For a third thing, this adds a little more kernel text, in order to optimize the case that the current cpuset is mem_exclusive, at the expense of a slightly longer code path for the case that it is some ancestor that is the nearest enclosing mem_exclusive cpuset. I guess it is workload and cpuset config dependent whether or not such a tradeoff is an improvement, or a step backward. Lacking a persuasive argument that the case for which this optimizes is enough more frequent than the other case to matter, I'm inclined to pick the solution with the least code -- what's there now. What am I missing? -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.925.600.0401 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [PATCH] virtual memmap on sparsemem v3 [1/4] map and unmap
On Fri, 8 Dec 2006 16:01:42 +0900
KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote:
> When we want to map pages into the kernel space by vmalloc()'s routine,
> we always need 'struct page' to do that.
>
> There are cases where there is no page struct to use (bootstrap, etc..).
> This function is designed to help map any memory to anywhere, anytime.
>
> Users should manage their virtual/physical space by themselves.
> Because it's complex and danger to manage virtual address space by
> each function's own code, it's better to use fixed address.
>
> Note: My first purpose is supporting virtual mem_map both at boot/hotplug
> sharing the same logic.
>
A little thing:
> + if (ops->k_pte_alloc) {
> + ret = ops->k_pte_alloc(pmd, addr, data);
> + if (ret)
> + return ret;
> + } else {
> + pte = pte_alloc_kernel(pmd, addr);
> + if (!pte)
> + return -ENOMEM;
> + }
> + if (ops->k_pmd_alloc) {
> + ret = ops->k_pmd_alloc(pud, addr, data);
> + if (ret)
> + return ret;
> + } else {
> + pmd = pmd_alloc(_mm, pud, addr);
> + if (!pmd)
> + return -ENOMEM;
> + if (ops->k_pud_alloc) {
> + ret = ops->k_pud_alloc(pgd, addr, data);
> + if (ret)
> + return ret;
> + } else {
> + pud = pud_alloc(_mm, pgd, addr);
> + if (!pud)
> + return -ENOMEM;
> + }
Generally we prefer to simply *require* that the function vector be filled
in appropriately. So if the caller has no special needs, the caller will
set their gen_map_kern_ops.k_pte_alloc to point at pte_alloc_kernel().
erk, pte_alloc_kernel() is a macro. As is pmd_alloc(), etc. Well, let
that be a lesson to us. What a mess.
I suppose we could go through and convert them all to inlines and then the
compiler will generate an out-of-line copy for us. Better would be to turn
these things into regular, out-of-line C functions.
What a mess.
-
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 11/32] SUNHME: Fix for sunhme failures on x86
-stable review patch. If anyone has any objections, please let us know.
--
From: Jurij Smakov <[EMAIL PROTECTED]>
The following patch fixes the failure of sunhme drivers on x86 hosts
due to missing pci_enable_device() and pci_set_master() calls, lost
during code refactoring. It has been filed as bugzilla bug #7502 [0]
and Debian bug #397460 [1].
[0] http://bugzilla.kernel.org/show_bug.cgi?id=7502
[1] http://bugs.debian.org/397460
Signed-off-by: Jurij Smakov <[EMAIL PROTECTED]>
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
drivers/net/sunhme.c |5 +
1 file changed, 5 insertions(+)
--- linux-2.6.19.orig/drivers/net/sunhme.c
+++ linux-2.6.19/drivers/net/sunhme.c
@@ -3012,6 +3012,11 @@ static int __devinit happy_meal_pci_prob
#endif
err = -ENODEV;
+
+ if (pci_enable_device(pdev))
+ goto err_out;
+ pci_set_master(pdev);
+
if (!strcmp(prom_name, "SUNW,qfe") || !strcmp(prom_name, "qfe")) {
qp = quattro_pci_find(pdev);
if (qp == NULL)
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 25/32] drm-sis linkage fix
-stable review patch. If anyone has any objections, please let us know. -- From: Andrew Morton <[EMAIL PROTECTED]> Fix http://bugzilla.kernel.org/show_bug.cgi?id=7606 WARNING: "drm_sman_set_manager" [drivers/char/drm/sis.ko] undefined! Cc: <[EMAIL PROTECTED]> Cc: Dave Airlie <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Signed-off-by: Chris Wright <[EMAIL PROTECTED]> --- drivers/char/drm/drm_sman.c |1 + 1 file changed, 1 insertion(+) --- linux-2.6.19.orig/drivers/char/drm/drm_sman.c +++ linux-2.6.19/drivers/char/drm/drm_sman.c @@ -162,6 +162,7 @@ drm_sman_set_manager(drm_sman_t * sman, return 0; } +EXPORT_SYMBOL(drm_sman_set_manager); static drm_owner_item_t *drm_sman_get_owner_item(drm_sman_t * sman, unsigned long owner) -- - 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 17/32] do_coredump() and not stopping rewrite attacks? (CVE-2006-6304)
-stable review patch. If anyone has any objections, please let us know.
--
From: Alexey Dobriyan <[EMAIL PROTECTED]>
On Sat, Dec 02, 2006 at 11:47:44PM +0300, Alexey Dobriyan wrote:
> David Binderman compiled 2.6.19 with icc and grepped for "was set but never
> used". Many warnings are on
> http://coderock.org/kj/unused-2.6.19-fs
Heh, the very first line:
fs/exec.c(1465): remark #593: variable "flag" was set but never used
fs/exec.c:
1477 /*
1478 * We cannot trust fsuid as being the "true" uid of the
1479 * process nor do we know its entire history. We only know
it
1480 * was tainted so we dump it as root in mode 2.
1481 */
1482 if (mm->dumpable == 2) {/* Setuid core dump mode */
1483 flag = O_EXCL; /* Stop rewrite attacks */
1484 current->fsuid = 0; /* Dump root private */
1485 }
And then filp_open follows with "flag" totally ignored.
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
fs/exec.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- linux-2.6.19.orig/fs/exec.c
+++ linux-2.6.19/fs/exec.c
@@ -1515,7 +1515,8 @@ int do_coredump(long signr, int exit_cod
ispipe = 1;
} else
file = filp_open(corename,
-O_CREAT | 2 | O_NOFOLLOW | O_LARGEFILE, 0600);
+O_CREAT | 2 | O_NOFOLLOW | O_LARGEFILE | flag,
+0600);
if (IS_ERR(file))
goto fail_unlock;
inode = file->f_dentry->d_inode;
--
-
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 27/32] PM: Fix swsusp debug mode testproc
-stable review patch. If anyone has any objections, please let us know. -- From: Rafael J Wysocki <[EMAIL PROTECTED]> The 'testproc' swsusp debug mode thaws tasks twice in a row, which is _very_ confusing. Fix that. Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> Acked-by: Pavel Machek <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Signed-off-by: Chris Wright <[EMAIL PROTECTED]> --- kernel/power/disk.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-2.6.19.orig/kernel/power/disk.c +++ linux-2.6.19/kernel/power/disk.c @@ -127,7 +127,7 @@ int pm_suspend_disk(void) return error; if (pm_disk_mode == PM_DISK_TESTPROC) - goto Thaw; + return 0; suspend_console(); error = device_suspend(PMSG_FREEZE); -- - 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 22/32] IrDA: Incorrect TTP header reservation
-stable review patch. If anyone has any objections, please let us know.
--
From: Jeet Chaudhuri <[EMAIL PROTECTED]>
We must reserve SAR + MAX_HEADER bytes for IrLMP to fit in.
This fixes an oops reported (and fixed) by Jeet Chaudhuri, when max_sdu_size
is greater than 0.
Signed-off-by: Samuel Ortiz <[EMAIL PROTECTED]>
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
net/irda/irttp.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-2.6.19.orig/net/irda/irttp.c
+++ linux-2.6.19/net/irda/irttp.c
@@ -1099,7 +1099,7 @@ int irttp_connect_request(struct tsap_cb
return -ENOMEM;
/* Reserve space for MUX_CONTROL and LAP header */
- skb_reserve(tx_skb, TTP_MAX_HEADER);
+ skb_reserve(tx_skb, TTP_MAX_HEADER + TTP_SAR_HEADER);
} else {
tx_skb = userdata;
/*
@@ -1348,7 +1348,7 @@ int irttp_connect_response(struct tsap_c
return -ENOMEM;
/* Reserve space for MUX_CONTROL and LAP header */
- skb_reserve(tx_skb, TTP_MAX_HEADER);
+ skb_reserve(tx_skb, TTP_MAX_HEADER + TTP_SAR_HEADER);
} else {
tx_skb = userdata;
/*
--
-
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 31/32] x86_64: fix boot hang due to nmi watchdog init code
-stable review patch. If anyone has any objections, please let us know.
--
From: Ravikiran G Thirumalai <[EMAIL PROTECTED]>
2.6.19 stopped booting (or booted based on build/config) on our x86_64
systems due to a bug introduced in 2.6.19. check_nmi_watchdog schedules an
IPI on all cpus to busy wait on a flag, but fails to set the busywait flag
if NMI functionality is disabled.
This causes the secondary cpus to spin in an endless loop, causing the
kernel bootup to hang.
Depending upon the build, the busywait flag got overwritten (stack
variable) and caused the kernel to bootup on certain builds. Following
patch fixes the bug by setting the busywait flag before returning from
check_nmi_watchdog.
I guess using a stack variable is not good here as the calling function
could potentially return while the busy wait loop is still spinning on the
flag. I would think this is a good candidate for 2.6.19 stable as well.
[EMAIL PROTECTED]: cleanups]
Signed-off-by: Ravikiran Thirumalai <[EMAIL PROTECTED]>
Signed-off-by: Shai Fultheim <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/nmi.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- linux-2.6.19.orig/arch/x86_64/kernel/nmi.c
+++ linux-2.6.19/arch/x86_64/kernel/nmi.c
@@ -212,7 +212,7 @@ static __init void nmi_cpu_busy(void *da
int __init check_nmi_watchdog (void)
{
- volatile int endflag = 0;
+ static int __initdata endflag;
int *counts;
int cpu;
@@ -253,6 +253,7 @@ int __init check_nmi_watchdog (void)
if (!atomic_read(_active)) {
kfree(counts);
atomic_set(_active, -1);
+ endflag = 1;
return -1;
}
endflag = 1;
--
-
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 29/32] softirq: remove BUG_ONs which can incorrectly trigger
-stable review patch. If anyone has any objections, please let us know.
--
From: Zachary Amsden <[EMAIL PROTECTED]>
It is possible to have tasklets get scheduled before softirqd has had a chance
to spawn on all CPUs. This is totally harmless; after success during action
CPU_UP_PREPARE, action CPU_ONLINE will be called, which immediately wakes
softirqd on the appropriate CPU to process the already pending tasklets. So
there is no danger of having a missed wakeup for any tasklets that were
already pending.
In particular, i386 is affected by this during startup, and is visible when
using a very large initrd; during the time it takes for the initrd to be
decompressed, a timer IRQ can come in and schedule RCU callbacks. It is also
possible that resending of a hardware IRQ via a softirq triggers the same bug.
Because of different timing conditions, this shows up in all emulators and
virtual machines tested, including Xen, VMware, Virtual PC, and Qemu. It is
also possible to trigger on native hardware with a large enough initrd,
although I don't have a reliable case demonstrating that.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Cc: Ingo Molnar <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
kernel/softirq.c |2 --
1 file changed, 2 deletions(-)
--- linux-2.6.19.orig/kernel/softirq.c
+++ linux-2.6.19/kernel/softirq.c
@@ -574,8 +574,6 @@ static int __cpuinit cpu_callback(struct
switch (action) {
case CPU_UP_PREPARE:
- BUG_ON(per_cpu(tasklet_vec, hotcpu).list);
- BUG_ON(per_cpu(tasklet_hi_vec, hotcpu).list);
p = kthread_create(ksoftirqd, hcpu, "ksoftirqd/%d", hotcpu);
if (IS_ERR(p)) {
printk("ksoftirqd for %i failed\n", hotcpu);
--
-
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 04/32] EBTABLES: Verify that ebt_entries have zero ->distinguisher.
-stable review patch. If anyone has any objections, please let us know.
--
From: Al Viro <[EMAIL PROTECTED]>
We need that for iterator to work; existing check had been too weak.
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
net/bridge/netfilter/ebtables.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
--- linux-2.6.19.orig/net/bridge/netfilter/ebtables.c
+++ linux-2.6.19/net/bridge/netfilter/ebtables.c
@@ -417,7 +417,7 @@ ebt_check_entry_size_and_hooks(struct eb
/* beginning of a new chain
if i == NF_BR_NUMHOOKS it must be a user defined chain */
if (i != NF_BR_NUMHOOKS || !(e->bitmask & EBT_ENTRY_OR_ENTRIES)) {
- if ((e->bitmask & EBT_ENTRY_OR_ENTRIES) != 0) {
+ if (e->bitmask != 0) {
/* we make userspace set this right,
so there is no misunderstanding */
BUGPRINT("EBT_ENTRY_OR_ENTRIES shouldn't be set "
@@ -500,7 +500,7 @@ ebt_get_udc_positions(struct ebt_entry *
int i;
/* we're only interested in chain starts */
- if (e->bitmask & EBT_ENTRY_OR_ENTRIES)
+ if (e->bitmask)
return 0;
for (i = 0; i < NF_BR_NUMHOOKS; i++) {
if ((valid_hooks & (1 << i)) == 0)
@@ -550,7 +550,7 @@ ebt_cleanup_entry(struct ebt_entry *e, u
{
struct ebt_entry_target *t;
- if ((e->bitmask & EBT_ENTRY_OR_ENTRIES) == 0)
+ if (e->bitmask == 0)
return 0;
/* we're done */
if (cnt && (*cnt)-- == 0)
@@ -576,7 +576,7 @@ ebt_check_entry(struct ebt_entry *e, str
int ret;
/* don't mess with the struct ebt_entries */
- if ((e->bitmask & EBT_ENTRY_OR_ENTRIES) == 0)
+ if (e->bitmask == 0)
return 0;
if (e->bitmask & ~EBT_F_MASK) {
@@ -1309,7 +1309,7 @@ static inline int ebt_make_names(struct
char *hlp;
struct ebt_entry_target *t;
- if ((e->bitmask & EBT_ENTRY_OR_ENTRIES) == 0)
+ if (e->bitmask == 0)
return 0;
hlp = ubase - base + (char *)e + e->target_offset;
--
-
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 13/32] NETFILTER: Fix iptables compat hook validation
-stable review patch. If anyone has any objections, please let us know.
--
From: Dmitry Mishin <[EMAIL PROTECTED]>
In compat mode, matches and targets valid hooks checks always successful due
to not initialized e->comefrom field yet. This patch separates this checks from
translation code and moves them after mark_source_chains() call, where these
marks are initialized.
Signed-off-by: Dmitry Mishin <[EMAIL PROTECTED]>
Signed-off-by; Patrick McHardy <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
commit 14f5487cb9bd34cd59360d2cac7dccac9b27e8ce
tree fab7cabcdb7fe450ff47bf42918f845ff3da1b86
parent 756c508367e95d6f963502e4feecb8c76aeee332
author Dmitry Mishin <[EMAIL PROTECTED]> Mon, 04 Dec 2006 12:19:35 +0100
committer Patrick McHardy <[EMAIL PROTECTED]> Mon, 04 Dec 2006 12:19:35 +0100
net/ipv4/netfilter/ip_tables.c | 78 ++---
1 file changed, 51 insertions(+), 27 deletions(-)
--- linux-2.6.19.orig/net/ipv4/netfilter/ip_tables.c
+++ linux-2.6.19/net/ipv4/netfilter/ip_tables.c
@@ -1516,25 +1516,8 @@ static inline int compat_copy_match_from
void **dstptr, compat_uint_t *size, const char *name,
const struct ipt_ip *ip, unsigned int hookmask)
{
- struct ipt_entry_match *dm;
- struct ipt_match *match;
- int ret;
-
- dm = (struct ipt_entry_match *)*dstptr;
- match = m->u.kernel.match;
xt_compat_match_from_user(m, dstptr, size);
-
- ret = xt_check_match(match, AF_INET, dm->u.match_size - sizeof(*dm),
-name, hookmask, ip->proto,
-ip->invflags & IPT_INV_PROTO);
- if (!ret && m->u.kernel.match->checkentry
- && !m->u.kernel.match->checkentry(name, ip, match, dm->data,
- hookmask)) {
- duprintf("ip_tables: check failed for `%s'.\n",
-m->u.kernel.match->name);
- ret = -EINVAL;
- }
- return ret;
+ return 0;
}
static int compat_copy_entry_from_user(struct ipt_entry *e, void **dstptr,
@@ -1556,7 +1539,7 @@ static int compat_copy_entry_from_user(s
ret = IPT_MATCH_ITERATE(e, compat_copy_match_from_user, dstptr, size,
name, >ip, de->comefrom);
if (ret)
- goto err;
+ return ret;
de->target_offset = e->target_offset - (origsize - *size);
t = ipt_get_target(e);
target = t->u.kernel.target;
@@ -1569,26 +1552,62 @@ static int compat_copy_entry_from_user(s
if ((unsigned char *)de - base < newinfo->underflow[h])
newinfo->underflow[h] -= origsize - *size;
}
+ return ret;
+}
+
+static inline int compat_check_match(struct ipt_entry_match *m, const char
*name,
+ const struct ipt_ip *ip, unsigned int hookmask)
+{
+ struct ipt_match *match;
+ int ret;
- t = ipt_get_target(de);
+ match = m->u.kernel.match;
+ ret = xt_check_match(match, AF_INET, m->u.match_size - sizeof(*m),
+name, hookmask, ip->proto,
+ip->invflags & IPT_INV_PROTO);
+ if (!ret && m->u.kernel.match->checkentry
+ && !m->u.kernel.match->checkentry(name, ip, match, m->data,
+ hookmask)) {
+ duprintf("ip_tables: compat: check failed for `%s'.\n",
+m->u.kernel.match->name);
+ ret = -EINVAL;
+ }
+ return ret;
+}
+
+static inline int compat_check_target(struct ipt_entry *e, const char *name)
+{
+ struct ipt_entry_target *t;
+ struct ipt_target *target;
+ int ret;
+
+ t = ipt_get_target(e);
target = t->u.kernel.target;
ret = xt_check_target(target, AF_INET, t->u.target_size - sizeof(*t),
name, e->comefrom, e->ip.proto,
e->ip.invflags & IPT_INV_PROTO);
- if (ret)
- goto err;
-
- if (t->u.kernel.target->checkentry
- && !t->u.kernel.target->checkentry(name, de, target,
- t->data, de->comefrom)) {
+ if (!ret && t->u.kernel.target->checkentry
+ && !t->u.kernel.target->checkentry(name, e, target,
+ t->data, e->comefrom)) {
duprintf("ip_tables: compat: check failed for `%s'.\n",
t->u.kernel.target->name);
ret = -EINVAL;
}
-err:
return ret;
}
+static inline int compat_check_entry(struct ipt_entry *e, const char *name)
+{
+ int ret;
+
+ ret = IPT_MATCH_ITERATE(e, compat_check_match, name, >ip,
+ e->comefrom);
+ if (ret)
+ return ret;
+
+ return
[patch 32/32] forcedeth: Disable INTx when enabling MSI in forcedeth
-stable review patch. If anyone has any objections, please let us know.
--
From: Daniel Barkalow <[EMAIL PROTECTED]>
At least some nforce cards continue to send legacy interrupts when MSI
is enabled, and these interrupts are treated as unhandled by the
kernel. This patch disables legacy interrupts explicitly when enabling
MSI mode.
The correct fix is to change the MSI infrastructure to disable legacy
interrupts when enabling MSI, but this is potentially risky if the
device isn't PCI-2.3 or is quirky, so the correct fix is going into
mainline, while patches like this one go into -stable.
Legend has it that it is most correct to disable legacy interrupts
before enabling MSI, but the mainline patch does it in the other
order, and this patch is "obviously" the same as mainline.
Signed-off-by: Daniel Barkalow <[EMAIL PROTECTED]>
Cc: Jeff Garzik <[EMAIL PROTECTED]>
Cc: Greg KH <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
The general patch got into mainline last night, and this patch is clearly
the same as that one, limited to the case of forcedeth (the pci_intx()
calls are lifted from {enable,disable}_msi_mode to all of the indirect
callers in forcedeth).
drivers/net/forcedeth.c |3 +++
1 file changed, 3 insertions(+)
--- linux-2.6.19.orig/drivers/net/forcedeth.c
+++ linux-2.6.19/drivers/net/forcedeth.c
@@ -2815,11 +2815,13 @@ static int nv_request_irq(struct net_dev
}
if (ret != 0 && np->msi_flags & NV_MSI_CAPABLE) {
if ((ret = pci_enable_msi(np->pci_dev)) == 0) {
+ pci_intx(np->pci_dev, 0);
np->msi_flags |= NV_MSI_ENABLED;
if ((!intr_test && request_irq(np->pci_dev->irq,
_nic_irq, IRQF_SHARED, dev->name, dev) != 0) ||
(intr_test && request_irq(np->pci_dev->irq,
_nic_irq_test, IRQF_SHARED, dev->name, dev) != 0)) {
printk(KERN_INFO "forcedeth: request_irq failed
%d\n", ret);
pci_disable_msi(np->pci_dev);
+ pci_intx(np->pci_dev, 1);
np->msi_flags &= ~NV_MSI_ENABLED;
goto out_err;
}
@@ -2862,6 +2864,7 @@ static void nv_free_irq(struct net_devic
free_irq(np->pci_dev->irq, dev);
if (np->msi_flags & NV_MSI_ENABLED) {
pci_disable_msi(np->pci_dev);
+ pci_intx(np->pci_dev, 1);
np->msi_flags &= ~NV_MSI_ENABLED;
}
}
--
-
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 18/32] TOKENRING: Remote memory corruptor in ibmtr.c
-stable review patch. If anyone has any objections, please let us know.
--
From: David Miller <[EMAIL PROTECTED]>
ip_summed changes last summer had missed that one. As the result,
we have ip_summed interpreted as CHECKSUM_PARTIAL now. IOW,
->csum is interpreted as offset of checksum in the packet. net/core/*
will both read and modify the value as that offset, with obvious
reasons. At the very least it's a remote memory corruptor.
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
commit b1875feda8c1735915e12d953acba85d96129f6a
Author: Al Viro <[EMAIL PROTECTED]>
Date: Mon Dec 4 19:37:42 2006 -0800
drivers/net/tokenring/ibmtr.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-2.6.19.orig/drivers/net/tokenring/ibmtr.c
+++ linux-2.6.19/drivers/net/tokenring/ibmtr.c
@@ -1826,7 +1826,7 @@ static void tr_rx(struct net_device *dev
skb->protocol = tr_type_trans(skb, dev);
if (IPv4_p) {
skb->csum = chksum;
- skb->ip_summed = 1;
+ skb->ip_summed = CHECKSUM_COMPLETE;
}
netif_rx(skb);
dev->last_rx = jiffies;
--
-
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 14/32] NETFILTER: bridge netfilter: deal with martians correctly
-stable review patch. If anyone has any objections, please let us know.
--
From: Bart De Schuymer <[EMAIL PROTECTED]>
The attached patch resolves an issue where a IP DNATed packet with a
martian source is forwarded while it's better to drop it. It also
resolves messages complaining about ip forwarding being disabled while
it's actually enabled. Thanks to lepton <[EMAIL PROTECTED]> for
reporting this problem.
This is probably a candidate for the -stable release.
Signed-off-by: Bart De Schuymer <[EMAIL PROTECTED]>
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
commit bb01f827bae980efdecc33fbcdc1b90f1c355b3e
tree 432a8f2843b47ccac094efea35da6f19731ed834
parent 14f5487cb9bd34cd59360d2cac7dccac9b27e8ce
author Bart De Schuymer <[EMAIL PROTECTED]> Mon, 04 Dec 2006 12:19:46 +0100
committer Patrick McHardy <[EMAIL PROTECTED]> Mon, 04 Dec 2006 12:19:46 +0100
net/bridge/br_netfilter.c | 36
1 file changed, 28 insertions(+), 8 deletions(-)
--- linux-2.6.19.orig/net/bridge/br_netfilter.c
+++ linux-2.6.19/net/bridge/br_netfilter.c
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#include
#include
@@ -222,10 +223,14 @@ static void __br_dnat_complain(void)
*
* Otherwise, the packet is considered to be routed and we just
* change the destination MAC address so that the packet will
- * later be passed up to the IP stack to be routed.
+ * later be passed up to the IP stack to be routed. For a redirected
+ * packet, ip_route_input() will give back the localhost as output device,
+ * which differs from the bridge device.
*
* Let us now consider the case that ip_route_input() fails:
*
+ * This can be because the destination address is martian, in which case
+ * the packet will be dropped.
* After a "echo '0' > /proc/sys/net/ipv4/ip_forward" ip_route_input()
* will fail, while __ip_route_output_key() will return success. The source
* address for __ip_route_output_key() is set to zero, so __ip_route_output_key
@@ -238,7 +243,8 @@ static void __br_dnat_complain(void)
*
* --Lennert, 20020411
* --Bart, 20020416 (updated)
- * --Bart, 20021007 (updated) */
+ * --Bart, 20021007 (updated)
+ * --Bart, 20062711 (updated) */
static int br_nf_pre_routing_finish_bridge(struct sk_buff *skb)
{
if (skb->pkt_type == PACKET_OTHERHOST) {
@@ -265,15 +271,15 @@ static int br_nf_pre_routing_finish(stru
struct net_device *dev = skb->dev;
struct iphdr *iph = skb->nh.iph;
struct nf_bridge_info *nf_bridge = skb->nf_bridge;
+ int err;
if (nf_bridge->mask & BRNF_PKT_TYPE) {
skb->pkt_type = PACKET_OTHERHOST;
nf_bridge->mask ^= BRNF_PKT_TYPE;
}
nf_bridge->mask ^= BRNF_NF_BRIDGE_PREROUTING;
-
if (dnat_took_place(skb)) {
- if (ip_route_input(skb, iph->daddr, iph->saddr, iph->tos, dev))
{
+ if ((err = ip_route_input(skb, iph->daddr, iph->saddr,
iph->tos, dev))) {
struct rtable *rt;
struct flowi fl = {
.nl_u = {
@@ -284,19 +290,33 @@ static int br_nf_pre_routing_finish(stru
},
.proto = 0,
};
+ struct in_device *in_dev = in_dev_get(dev);
+
+ /* If err equals -EHOSTUNREACH the error is due to a
+* martian destination or due to the fact that
+* forwarding is disabled. For most martian packets,
+* ip_route_output_key() will fail. It won't fail for 2
types of
+* martian destinations: loopback destinations and
destination
+* 0.0.0.0. In both cases the packet will be dropped
because the
+* destination is the loopback device and not the
bridge. */
+ if (err != -EHOSTUNREACH || !in_dev ||
IN_DEV_FORWARD(in_dev))
+ goto free_skb;
if (!ip_route_output_key(, )) {
/* - Bridged-and-DNAT'ed traffic doesn't
-* require ip_forwarding.
-* - Deal with redirected traffic. */
- if (((struct dst_entry *)rt)->dev == dev ||
- rt->rt_type == RTN_LOCAL) {
+* require ip_forwarding. */
+ if (((struct dst_entry *)rt)->dev == dev) {
skb->dst = (struct dst_entry *)rt;
goto bridged_dnat;
}
+ /* we are sure that forwarding is disabled, so
printing
+* this message is no problem.
[patch 10/32] PKT_SCHED act_gact: division by zero
-stable review patch. If anyone has any objections, please let us know.
--
From: David Miller <[EMAIL PROTECTED]>
Not returning -EINVAL, because someone might want to use the value
zero in some future gact_prob algorithm?
Signed-off-by: Kim Nordlund <[EMAIL PROTECTED]>
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
net/sched/act_gact.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-2.6.19.orig/net/sched/act_gact.c
+++ linux-2.6.19/net/sched/act_gact.c
@@ -48,14 +48,14 @@ static struct tcf_hashinfo gact_hash_inf
#ifdef CONFIG_GACT_PROB
static int gact_net_rand(struct tcf_gact *gact)
{
- if (net_random() % gact->tcfg_pval)
+ if (!gact->tcfg_pval || net_random() % gact->tcfg_pval)
return gact->tcf_action;
return gact->tcfg_paction;
}
static int gact_determ(struct tcf_gact *gact)
{
- if (gact->tcf_bstats.packets % gact->tcfg_pval)
+ if (!gact->tcfg_pval || gact->tcf_bstats.packets % gact->tcfg_pval)
return gact->tcf_action;
return gact->tcfg_paction;
}
--
-
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 000 of 5] md: Assorted minor fixes for mainline
On Fri, 8 Dec 2006 12:05:24 +1100 NeilBrown <[EMAIL PROTECTED]> wrote: > Following are 5 patches for md in 2.6.19-rc6-mm2 that are suitable for 2.6.20. > > Patch 4 might fix an outstanding bug against md which manifests as an > oops early in boot, but I don't have test results yet. > > NeilBrown > > [PATCH 001 of 5] md: Remove some old ifdefed-out code from raid5.c > [PATCH 002 of 5] md: Return a non-zero error to bi_end_io as appropriate in > raid5. > [PATCH 003 of 5] md: Assorted md and raid1 one-liners > [PATCH 004 of 5] md: Close a race between destroying and recreating an md > device. > [PATCH 005 of 5] md: Allow mddevs to live a bit longer to avoid a loop with > udev. md-change-lifetime-rules-for-md-devices.patch still has a cloud over its head (Jiri Kosina <[EMAIL PROTECTED]>'s repeatable failure), so I staged these new patches as below: md-fix-innocuous-bug-in-raid6-stripe_to_pdidx.patch # md-conditionalize-some-code.patch +md-remove-some-old-ifdefed-out-code-from-raid5c.patch +md-return-a-non-zero-error-to-bi_end_io-as-appropriate-in-raid5.patch +md-assorted-md-and-raid1-one-liners.patch md-change-lifetime-rules-for-md-devices.patch +md-close-a-race-between-destroying-and-recreating-an-md-device.patch +md-allow-mddevs-to-live-a-bit-longer-to-avoid-a-loop-with-udev.patch So the last three are maybe-not-for-2.6.20. Does that sounds sane? - 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 21/32] IPSEC: Fix inetpeer leak in ipv4 xfrm dst entries.
-stable review patch. If anyone has any objections, please let us know. -- From: David Miller <[EMAIL PROTECTED]> We grab a reference to the route's inetpeer entry but forget to release it in xfrm4_dst_destroy(). Bug discovered by Kazunori MIYAZAWA <[EMAIL PROTECTED]> Signed-off-by: David S. Miller <[EMAIL PROTECTED]> Signed-off-by: Chris Wright <[EMAIL PROTECTED]> --- commit 26db167702756d0022f8ea5f1f30cad3018cfe31 Author: David S. Miller <[EMAIL PROTECTED]> Date: Wed Dec 6 23:45:15 2006 -0800 net/ipv4/xfrm4_policy.c |2 ++ 1 file changed, 2 insertions(+) --- linux-2.6.19.orig/net/ipv4/xfrm4_policy.c +++ linux-2.6.19/net/ipv4/xfrm4_policy.c @@ -273,6 +273,8 @@ static void xfrm4_dst_destroy(struct dst if (likely(xdst->u.rt.idev)) in_dev_put(xdst->u.rt.idev); + if (likely(xdst->u.rt.peer)) + inet_putpeer(xdst->u.rt.peer); xfrm_dst_destroy(xdst); } -- - 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 30/32] m32r: make userspace headers platform-independent
-stable review patch. If anyone has any objections, please let us know. -- From: Hirokazu Takata <[EMAIL PROTECTED]> The m32r kernel 2.6.18-rc1 or after cause build errors of "unknown isa configuration" for userspace application programs, such as glibc, gdb, etc. This is because the recent kernel do not include linux/config.h not to expose kernel headers for userspace. To fix the above compile errors, this patch fixes two headers ptrace.h and sigcontext.h for m32r and makes them platform-independent. Signed-off-by: Hirokazu Takata <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Signed-off-by: Chris Wright <[EMAIL PROTECTED]> --- arch/m32r/kernel/entry.S | 65 ++ include/asm-m32r/ptrace.h | 28 ++ include/asm-m32r/sigcontext.h | 13 +--- 3 files changed, 35 insertions(+), 71 deletions(-) --- linux-2.6.19.orig/arch/m32r/kernel/entry.S +++ linux-2.6.19/arch/m32r/kernel/entry.S @@ -23,35 +23,35 @@ * updated in fork.c:copy_thread, signal.c:do_signal, * ptrace.c and ptrace.h * - * M32Rx/M32R2 M32R - * @(sp) - r4 ditto - * @(0x04,sp) - r5 ditto - * @(0x08,sp) - r6 ditto - * @(0x0c,sp) - *pt_regs ditto - * @(0x10,sp) - r0 ditto - * @(0x14,sp) - r1 ditto - * @(0x18,sp) - r2 ditto - * @(0x1c,sp) - r3 ditto - * @(0x20,sp) - r7 ditto - * @(0x24,sp) - r8 ditto - * @(0x28,sp) - r9 ditto - * @(0x2c,sp) - r10 ditto - * @(0x30,sp) - r11 ditto - * @(0x34,sp) - r12 ditto - * @(0x38,sp) - syscall_nr ditto - * @(0x3c,sp) - acc0h@(0x3c,sp) - acch - * @(0x40,sp) - acc0l@(0x40,sp) - accl - * @(0x44,sp) - acc1h@(0x44,sp) - dummy_acc1h - * @(0x48,sp) - acc1l@(0x48,sp) - dummy_acc1l - * @(0x4c,sp) - psw ditto - * @(0x50,sp) - bpc ditto - * @(0x54,sp) - bbpswditto - * @(0x58,sp) - bbpc ditto - * @(0x5c,sp) - spu (cr3)ditto - * @(0x60,sp) - fp (r13) ditto - * @(0x64,sp) - lr (r14) ditto - * @(0x68,sp) - spi (cr2)ditto - * @(0x6c,sp) - orig_r0 ditto + * M32R/M32Rx/M32R2 + * @(sp) - r4 + * @(0x04,sp) - r5 + * @(0x08,sp) - r6 + * @(0x0c,sp) - *pt_regs + * @(0x10,sp) - r0 + * @(0x14,sp) - r1 + * @(0x18,sp) - r2 + * @(0x1c,sp) - r3 + * @(0x20,sp) - r7 + * @(0x24,sp) - r8 + * @(0x28,sp) - r9 + * @(0x2c,sp) - r10 + * @(0x30,sp) - r11 + * @(0x34,sp) - r12 + * @(0x38,sp) - syscall_nr + * @(0x3c,sp) - acc0h + * @(0x40,sp) - acc0l + * @(0x44,sp) - acc1h; ISA_DSP_LEVEL2 only + * @(0x48,sp) - acc1l; ISA_DSP_LEVEL2 only + * @(0x4c,sp) - psw + * @(0x50,sp) - bpc + * @(0x54,sp) - bbpsw + * @(0x58,sp) - bbpc + * @(0x5c,sp) - spu (cr3) + * @(0x60,sp) - fp (r13) + * @(0x64,sp) - lr (r14) + * @(0x68,sp) - spi (cr2) + * @(0x6c,sp) - orig_r0 */ #include @@ -95,17 +95,10 @@ #define R11(reg) @(0x30,reg) #define R12(reg) @(0x34,reg) #define SYSCALL_NR(reg)@(0x38,reg) -#if defined(CONFIG_ISA_M32R2) && defined(CONFIG_ISA_DSP_LEVEL2) #define ACC0H(reg) @(0x3C,reg) #define ACC0L(reg) @(0x40,reg) #define ACC1H(reg) @(0x44,reg) #define ACC1L(reg) @(0x48,reg) -#elif defined(CONFIG_ISA_M32R2) || defined(CONFIG_ISA_M32R) -#define ACCH(reg) @(0x3C,reg) -#define ACCL(reg) @(0x40,reg) -#else -#error unknown isa configuration -#endif #define PSW(reg) @(0x4C,reg) #define BPC(reg) @(0x50,reg) #define BBPSW(reg) @(0x54,reg) --- linux-2.6.19.orig/include/asm-m32r/ptrace.h +++ linux-2.6.19/include/asm-m32r/ptrace.h @@ -33,21 +33,10 @@ #define PT_R15 PT_SP /* processor status and miscellaneous context registers. */ -#if defined(CONFIG_ISA_M32R2) && defined(CONFIG_ISA_DSP_LEVEL2) #define PT_ACC0H 15 #define PT_ACC0L 16 -#define PT_ACC1H 17 -#define PT_ACC1L 18 -#define PT_ACCHPT_ACC0H -#define PT_ACCLPT_ACC0L -#elif defined(CONFIG_ISA_M32R2) || defined(CONFIG_ISA_M32R) -#define PT_ACCH15 -#define PT_ACCL16 -#define PT_DUMMY_ACC1H 17 -#define PT_DUMMY_ACC1L 18 -#else -#error unknown isa conifiguration -#endif +#define PT_ACC1H 17 /* ISA_DSP_LEVEL2 only */ +#define PT_ACC1L 18 /* ISA_DSP_LEVEL2 only */
[patch 08/32] cryptoloop: Select CRYPTO_CBC
-stable review patch. If anyone has any objections, please let us know. -- From: Herbert Xu <[EMAIL PROTECTED]> As CBC is the default chaining method for cryptoloop, we should select it from cryptoloop to ease the transition. Signed-off-by: Herbert Xu <[EMAIL PROTECTED]> Signed-off-by: Chris Wright <[EMAIL PROTECTED]> --- drivers/block/Kconfig |1 + 1 file changed, 1 insertion(+) --- linux-2.6.19.orig/drivers/block/Kconfig +++ linux-2.6.19/drivers/block/Kconfig @@ -305,6 +305,7 @@ config BLK_DEV_LOOP config BLK_DEV_CRYPTOLOOP tristate "Cryptoloop Support" select CRYPTO + select CRYPTO_CBC depends on BLK_DEV_LOOP ---help--- Say Y here if you want to be able to use the ciphers that are -- - 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 28/32] autofs: fix error code path in autofs_fill_sb()
-stable review patch. If anyone has any objections, please let us know.
--
From: Jiri Kosina <[EMAIL PROTECTED]>
When kernel is compiled with old version of autofs (CONFIG_AUTOFS_FS), and
new (observed at least with 5.x.x) automount deamon is started, kernel
correctly reports incompatible version of kernel and userland daemon, but
then screws things up instead of correct handling of the error:
autofs: kernel does not match daemon version
=
[ BUG: bad unlock balance detected! ]
-
automount/4199 is trying to release lock (>s_umount_key) at:
[] get_sb_nodev+0x76/0xa4
but there are no more locks to release!
other info that might help us debug this:
no locks held by automount/4199.
stack backtrace:
[] dump_trace+0x68/0x1b2
[] show_trace_log_lvl+0x18/0x2c
[] show_trace+0xf/0x11
[] dump_stack+0x12/0x14
[] print_unlock_inbalance_bug+0xe7/0xf3
[] lock_release+0x8d/0x164
[] up_write+0x14/0x27
[] get_sb_nodev+0x76/0xa4
[] vfs_kern_mount+0x83/0xf6
[] do_kern_mount+0x2d/0x3e
[] do_mount+0x607/0x67a
[] sys_mount+0x72/0xa4
[] sysenter_past_esp+0x5f/0x99
DWARF2 unwinder stuck at sysenter_past_esp+0x5f/0x99
Leftover inexact backtrace:
===
and then deadlock comes.
The problem: autofs_fill_super() returns EINVAL to get_sb_nodev(), but
before that, it calls kill_anon_super() to destroy the superblock which
won't be needed. This is however way too soon to call kill_anon_super(),
because get_sb_nodev() has to perform its own cleanup of the superblock
first (deactivate_super(), etc.). The correct time to call
kill_anon_super() is in the autofs_kill_sb() callback, which is called by
deactivate_super() at proper time, when the superblock is ready to be
killed.
I can see the same faulty codepath also in autofs4. This patch solves
issues in both filesystems in a same way - it postpones the
kill_anon_super() until the proper time is signalized by deactivate_super()
calling the kill_sb() callback.
[EMAIL PROTECTED]: update comment]
Signed-off-by: Jiri Kosina <[EMAIL PROTECTED]>
Acked-by: Ian Kent <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Signed-off-by: Ian Kent <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
fs/autofs/inode.c |7 ---
fs/autofs4/inode.c |7 ---
2 files changed, 8 insertions(+), 6 deletions(-)
--- linux-2.6.19.orig/fs/autofs/inode.c
+++ linux-2.6.19/fs/autofs/inode.c
@@ -28,10 +28,11 @@ void autofs_kill_sb(struct super_block *
/*
* In the event of a failure in get_sb_nodev the superblock
* info is not present so nothing else has been setup, so
-* just exit when we are called from deactivate_super.
+* just call kill_anon_super when we are called from
+* deactivate_super.
*/
if (!sbi)
- return;
+ goto out_kill_sb;
if ( !sbi->catatonic )
autofs_catatonic_mode(sbi); /* Free wait queues, close pipe */
@@ -44,6 +45,7 @@ void autofs_kill_sb(struct super_block *
kfree(sb->s_fs_info);
+out_kill_sb:
DPRINTK(("autofs: shutting down\n"));
kill_anon_super(sb);
}
@@ -209,7 +211,6 @@ fail_iput:
fail_free:
kfree(sbi);
s->s_fs_info = NULL;
- kill_anon_super(s);
fail_unlock:
return -EINVAL;
}
--- linux-2.6.19.orig/fs/autofs4/inode.c
+++ linux-2.6.19/fs/autofs4/inode.c
@@ -152,10 +152,11 @@ void autofs4_kill_sb(struct super_block
/*
* In the event of a failure in get_sb_nodev the superblock
* info is not present so nothing else has been setup, so
-* just exit when we are called from deactivate_super.
+* just call kill_anon_super when we are called from
+* deactivate_super.
*/
if (!sbi)
- return;
+ goto out_kill_sb;
sb->s_fs_info = NULL;
@@ -167,6 +168,7 @@ void autofs4_kill_sb(struct super_block
kfree(sbi);
+out_kill_sb:
DPRINTK("shutting down");
kill_anon_super(sb);
}
@@ -426,7 +428,6 @@ fail_ino:
fail_free:
kfree(sbi);
s->s_fs_info = NULL;
- kill_anon_super(s);
fail_unlock:
return -EINVAL;
}
--
-
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 06/32] EBTABLES: Prevent wraparounds in checks for entry components sizes.
-stable review patch. If anyone has any objections, please let us know.
--
From: Al Viro <[EMAIL PROTECTED]>
---
net/bridge/netfilter/ebtables.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
--- linux-2.6.19.orig/net/bridge/netfilter/ebtables.c
+++ linux-2.6.19/net/bridge/netfilter/ebtables.c
@@ -338,10 +338,11 @@ ebt_check_match(struct ebt_entry_match *
const char *name, unsigned int hookmask, unsigned int *cnt)
{
struct ebt_match *match;
+ size_t left = ((char *)e + e->watchers_offset) - (char *)m;
int ret;
- if (((char *)m) + m->match_size + sizeof(struct ebt_entry_match) >
- ((char *)e) + e->watchers_offset)
+ if (left < sizeof(struct ebt_entry_match) ||
+ left - sizeof(struct ebt_entry_match) < m->match_size)
return -EINVAL;
match = find_match_lock(m->u.name, , _mutex);
if (!match)
@@ -367,10 +368,11 @@ ebt_check_watcher(struct ebt_entry_watch
const char *name, unsigned int hookmask, unsigned int *cnt)
{
struct ebt_watcher *watcher;
+ size_t left = ((char *)e + e->target_offset) - (char *)w;
int ret;
- if (((char *)w) + w->watcher_size + sizeof(struct ebt_entry_watcher) >
- ((char *)e) + e->target_offset)
+ if (left < sizeof(struct ebt_entry_watcher) ||
+ left - sizeof(struct ebt_entry_watcher) < w->watcher_size)
return -EINVAL;
watcher = find_watcher_lock(w->u.name, , _mutex);
if (!watcher)
@@ -573,6 +575,7 @@ ebt_check_entry(struct ebt_entry *e, str
struct ebt_entry_target *t;
struct ebt_target *target;
unsigned int i, j, hook = 0, hookmask = 0;
+ size_t gap = e->next_offset - e->target_offset;
int ret;
/* don't mess with the struct ebt_entries */
@@ -634,8 +637,7 @@ ebt_check_entry(struct ebt_entry *e, str
t->u.target = target;
if (t->u.target == _standard_target) {
- if (e->target_offset + sizeof(struct ebt_standard_target) >
- e->next_offset) {
+ if (gap < sizeof(struct ebt_standard_target)) {
BUGPRINT("Standard target size too big\n");
ret = -EFAULT;
goto cleanup_watchers;
@@ -646,8 +648,7 @@ ebt_check_entry(struct ebt_entry *e, str
ret = -EFAULT;
goto cleanup_watchers;
}
- } else if ((e->target_offset + t->target_size +
- sizeof(struct ebt_entry_target) > e->next_offset) ||
+ } else if (t->target_size > gap - sizeof(struct ebt_entry_target) ||
(t->u.target->check &&
t->u.target->check(name, hookmask, e, t->data, t->target_size) !=
0)){
module_put(t->u.target->me);
--
-
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 15/32] softmac: fix unbalanced mutex_lock/unlock in ieee80211softmac_wx_set_mlme
-stable review patch. If anyone has any objections, please let us know. -- From: Maxime Austruy <[EMAIL PROTECTED]> Routine ieee80211softmac_wx_set_mlme has one return that fails to release a mutex acquired at entry. Signed-off-by: Maxime Austruy <[EMAIL PROTECTED]> Signed-off-by: Larry Finger <[EMAIL PROTECTED]> Signed-off-by: Chris Wright <[EMAIL PROTECTED]> --- John and Chris, This error was introduced in the 2.6.19-rxX series and must be applied to 2.6.19-stable and wireless-2.6. Larry net/ieee80211/softmac/ieee80211softmac_wx.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- linux-2.6.19.orig/net/ieee80211/softmac/ieee80211softmac_wx.c +++ linux-2.6.19/net/ieee80211/softmac/ieee80211softmac_wx.c @@ -495,7 +495,8 @@ ieee80211softmac_wx_set_mlme(struct net_ printk(KERN_DEBUG PFX "wx_set_mlme: we should know the net here...\n"); goto out; } - return ieee80211softmac_deauth_req(mac, net, reason); + err = ieee80211softmac_deauth_req(mac, net, reason); + goto out; case IW_MLME_DISASSOC: ieee80211softmac_send_disassoc_req(mac, reason); mac->associnfo.associated = 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/
[patch 03/32] EBTABLES: Fix wraparounds in ebt_entries verification.
-stable review patch. If anyone has any objections, please let us know.
--
From: Al Viro <[EMAIL PROTECTED]>
We need to verify that
a) we are not too close to the end of buffer to dereference
b) next entry we'll be checking won't be _before_ our
While we are at it, don't subtract unrelated pointers...
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
net/bridge/netfilter/ebtables.c | 23 ---
1 file changed, 16 insertions(+), 7 deletions(-)
--- linux-2.6.19.orig/net/bridge/netfilter/ebtables.c
+++ linux-2.6.19/net/bridge/netfilter/ebtables.c
@@ -401,13 +401,17 @@ ebt_check_entry_size_and_hooks(struct eb
struct ebt_entries **hook_entries, unsigned int *n, unsigned int *cnt,
unsigned int *totalcnt, unsigned int *udc_cnt, unsigned int valid_hooks)
{
+ unsigned int offset = (char *)e - newinfo->entries;
+ size_t left = (limit - base) - offset;
int i;
+ if (left < sizeof(unsigned int))
+ goto Esmall;
+
for (i = 0; i < NF_BR_NUMHOOKS; i++) {
if ((valid_hooks & (1 << i)) == 0)
continue;
- if ( (char *)hook_entries[i] - base ==
- (char *)e - newinfo->entries)
+ if ((char *)hook_entries[i] == base + offset)
break;
}
/* beginning of a new chain
@@ -428,11 +432,8 @@ ebt_check_entry_size_and_hooks(struct eb
return -EINVAL;
}
/* before we look at the struct, be sure it is not too big */
- if ((char *)hook_entries[i] + sizeof(struct ebt_entries)
- > limit) {
- BUGPRINT("entries_size too small\n");
- return -EINVAL;
- }
+ if (left < sizeof(struct ebt_entries))
+ goto Esmall;
if (((struct ebt_entries *)e)->policy != EBT_DROP &&
((struct ebt_entries *)e)->policy != EBT_ACCEPT) {
/* only RETURN from udc */
@@ -455,6 +456,8 @@ ebt_check_entry_size_and_hooks(struct eb
return 0;
}
/* a plain old entry, heh */
+ if (left < sizeof(struct ebt_entry))
+ goto Esmall;
if (sizeof(struct ebt_entry) > e->watchers_offset ||
e->watchers_offset > e->target_offset ||
e->target_offset >= e->next_offset) {
@@ -466,10 +469,16 @@ ebt_check_entry_size_and_hooks(struct eb
BUGPRINT("target size too small\n");
return -EINVAL;
}
+ if (left < e->next_offset)
+ goto Esmall;
(*cnt)++;
(*totalcnt)++;
return 0;
+
+Esmall:
+ BUGPRINT("entries_size too small\n");
+ return -EINVAL;
}
struct ebt_cl_stack
--
-
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 19/32] XFRM: Use output device disable_xfrm for forwarded packets
-stable review patch. If anyone has any objections, please let us know. -- From: Patrick McHardy <[EMAIL PROTECTED]> Currently the behaviour of disable_xfrm is inconsistent between locally generated and forwarded packets. For locally generated packets disable_xfrm disables the policy lookup if it is set on the output device, for forwarded traffic however it looks at the input device. This makes it impossible to disable xfrm on all devices but a dummy device and use normal routing to direct traffic to that device. Always use the output device when checking disable_xfrm. Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]> Signed-off-by: David S. Miller <[EMAIL PROTECTED]> Signed-off-by: Chris Wright <[EMAIL PROTECTED]> --- commit 9be2b4e36fb04bbc968693ef95a75acc17cf2931 Author: Patrick McHardy <[EMAIL PROTECTED]> Date: Mon Dec 4 19:59:00 2006 -0800 net/ipv4/route.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-2.6.19.orig/net/ipv4/route.c +++ linux-2.6.19/net/ipv4/route.c @@ -1784,7 +1784,7 @@ static inline int __mkroute_input(struct #endif if (in_dev->cnf.no_policy) rth->u.dst.flags |= DST_NOPOLICY; - if (in_dev->cnf.no_xfrm) + if (out_dev->cnf.no_xfrm) rth->u.dst.flags |= DST_NOXFRM; rth->fl.fl4_dst = daddr; rth->rt_dst = daddr; -- - 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 20/32] USB: Fix oops in PhidgetServo
-stable review patch. If anyone has any objections, please let us know. -- From: Sean Young <[EMAIL PROTECTED]> The PhidgetServo causes an Oops when any of its sysfs attributes are read or written too, making the driver useless. Signed-off-by: Sean Young <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> Signed-off-by: Chris Wright <[EMAIL PROTECTED]> --- drivers/usb/misc/phidgetservo.c |1 + 1 file changed, 1 insertion(+) --- linux-2.6.19.orig/drivers/usb/misc/phidgetservo.c +++ linux-2.6.19/drivers/usb/misc/phidgetservo.c @@ -282,6 +282,7 @@ servo_probe(struct usb_interface *interf dev->dev = NULL; goto out; } + dev_set_drvdata(dev->dev, dev); servo_count = dev->type & SERVO_COUNT_QUAD ? 4 : 1; -- - 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 23/32] NETLINK: Restore API compatibility of address and neighbour bits
-stable review patch. If anyone has any objections, please let us know. -- From: Thomas Graf <[EMAIL PROTECTED]> Restore API compatibility due to bits moved from rtnetlink.h to separate headers. Signed-off-by: Thomas Graf <[EMAIL PROTECTED]> Signed-off-by: David S. Miller <[EMAIL PROTECTED]> Signed-off-by: Chris Wright <[EMAIL PROTECTED]> --- include/linux/rtnetlink.h |2 ++ 1 file changed, 2 insertions(+) --- linux-2.6.19.orig/include/linux/rtnetlink.h +++ linux-2.6.19/include/linux/rtnetlink.h @@ -3,6 +3,8 @@ #include #include +#include +#include / * Routing/neighbour discovery messages. -- - 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 16/32] IB/ucm: Fix deadlock in cleanup
-stable review patch. If anyone has any objections, please let us know. -- From: Michael S Tsirkin <[EMAIL PROTECTED]> ib_ucm_cleanup_events() holds file_mutex while calling ib_destroy_cm_id(). This can deadlock since ib_destroy_cm_id() flushes event handlers, and ib_ucm_event_handler() needs file_mutex, too. Therefore, drop the file_mutex during the call to ib_destroy_cm_id(). Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]> Signed-off-by: Roland Dreier <[EMAIL PROTECTED]> Acked-by: Sean Hefty <[EMAIL PROTECTED]> Signed-off-by: Chris Wright <[EMAIL PROTECTED]> --- Hello, -stable team! This patch backports commit f469b2626f48829c06e40ac799c1edf62b12048e to 2.6.19. Please consider it for 2.6.19.y - this fixes a deadlock reproduced here at Mellanox. drivers/infiniband/core/ucm.c |2 ++ 1 file changed, 2 insertions(+) --- linux-2.6.19.orig/drivers/infiniband/core/ucm.c +++ linux-2.6.19/drivers/infiniband/core/ucm.c @@ -161,12 +161,14 @@ static void ib_ucm_cleanup_events(struct struct ib_ucm_event, ctx_list); list_del(>file_list); list_del(>ctx_list); + mutex_unlock(>file->file_mutex); /* clear incoming connections. */ if (ib_ucm_new_cm_id(uevent->resp.event)) ib_destroy_cm_id(uevent->cm_id); kfree(uevent); + mutex_lock(>file->file_mutex); } mutex_unlock(>file->file_mutex); } -- - 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 05/32] EBTABLES: Deal with the worst-case behaviour in loop checks.
-stable review patch. If anyone has any objections, please let us know.
--
From: Al Viro <[EMAIL PROTECTED]>
No need to revisit a chain we'd already finished with during
the check for current hook. It's either instant loop (which
we'd just detected) or a duplicate work.
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
net/bridge/netfilter/ebtables.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- linux-2.6.19.orig/net/bridge/netfilter/ebtables.c
+++ linux-2.6.19/net/bridge/netfilter/ebtables.c
@@ -717,7 +717,9 @@ static int check_chainloops(struct ebt_e
BUGPRINT("loop\n");
return -1;
}
- /* this can't be 0, so the above test is correct */
+ if (cl_s[i].hookmask & (1 << hooknr))
+ goto letscontinue;
+ /* this can't be 0, so the loop test is correct */
cl_s[i].cs.n = pos + 1;
pos = 0;
cl_s[i].cs.e = ((void *)e + e->next_offset);
--
-
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 26/32] compat: skip data conversion in compat_sys_mount when data_page is NULL
-stable review patch. If anyone has any objections, please let us know.
--
From: Andrey Mirkin <[EMAIL PROTECTED]>
OpenVZ Linux kernel team has found a problem with mounting in compat mode.
Simple command "mount -t smbfs ..." on Fedora Core 5 distro in 32-bit mode
leads to oops:
Unable to handle kernel NULL pointer dereference at RIP:
[] compat_sys_mount+0xd6/0x290
PGD 34d48067 PUD 34d03067 PMD 0
Oops: [1] SMP
CPU: 0
Modules linked in: iptable_nat simfs smbfs ip_nat ip_conntrack vzdquota
parport_pc lp parport 8021q bridge llc vznetdev vzmon nfs lockd sunrpc vzdev
iptable_filter af_packet xt_length ipt_ttl xt_tcpmss ipt_TCPMSS
iptable_mangle xt_limit ipt_tos ipt_REJECT ip_tables x_tables thermal
processor fan button battery asus_acpi ac uhci_hcd ehci_hcd usbcore i2c_i801
i2c_core e100 mii floppy ide_cd cdrom
Pid: 14656, comm: mount
RIP: 0060:[] []
compat_sys_mount+0xd6/0x290
RSP: :810034d31f38 EFLAGS: 00010292
RAX: 002c RBX: RCX:
RDX: 810034c86bc0 RSI: 0096 RDI: 8061fc90
RBP: 810034d31f78 R08: R09: 000d
R10: 810034d31e58 R11: 0001 R12: 810039dc3000
R13: 0805ea48 R14: R15: c0ed
FS: () GS:80749000(0033) knlGS:b7d556b0
CS: 0060 DS: 007b ES: 007b CR0: 8005003b
CR2: CR3: 34d43000 CR4: 06e0
Process mount (pid: 14656, veid=300, threadinfo 810034d3, task
810034c86bc0)
Stack: 810034dd 810034e4a000 0805ea48
0805ea48 8021e64e
Call Trace:
[] ia32_sysret+0x0/0xa
Code: 83 3b 06 0f 85 41 01 00 00 0f b7 43 0c 89 43 14 0f b7 43 0a
RIP [] compat_sys_mount+0xd6/0x290
RSP
CR2:
The problem is that data_page pointer can be NULL, so we should skip data
conversion in this case.
Signed-off-by: Andrey Mirkin <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
fs/compat.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-2.6.19.orig/fs/compat.c
+++ linux-2.6.19/fs/compat.c
@@ -869,7 +869,7 @@ asmlinkage long compat_sys_mount(char __
retval = -EINVAL;
- if (type_page) {
+ if (type_page && data_page) {
if (!strcmp((char *)type_page, SMBFS_NAME)) {
do_smb_super_data_conv((void *)data_page);
} else if (!strcmp((char *)type_page, NCPFS_NAME)) {
--
-
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 07/32] NET_SCHED: policer: restore compatibility with old iproute binaries
-stable review patch. If anyone has any objections, please let us know.
--
From: Patrick McHardy <[EMAIL PROTECTED]>
The tc actions increased the size of struct tc_police, which broke
compatibility with old iproute binaries since both the act_police
and the old NET_CLS_POLICE code check for an exact size match.
Since the new members are not even used, the simple fix is to also
accept the size of the old structure. Dumping is not affected since
old userspace will receive a bigger structure, which is handled fine.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
Acked-by: Jamal Hadi Salim <[EMAIL PROTECTED]>
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
net/sched/act_police.c | 26 ++
1 file changed, 22 insertions(+), 4 deletions(-)
--- linux-2.6.19.orig/net/sched/act_police.c
+++ linux-2.6.19/net/sched/act_police.c
@@ -46,6 +46,18 @@ static struct tcf_hashinfo police_hash_i
.lock = _lock,
};
+/* old policer structure from before tc actions */
+struct tc_police_compat
+{
+ u32 index;
+ int action;
+ u32 limit;
+ u32 burst;
+ u32 mtu;
+ struct tc_ratespec rate;
+ struct tc_ratespec peakrate;
+};
+
/* Each policer is serialized by its individual spinlock */
#ifdef CONFIG_NET_CLS_ACT
@@ -131,12 +143,15 @@ static int tcf_act_police_locate(struct
struct tc_police *parm;
struct tcf_police *police;
struct qdisc_rate_table *R_tab = NULL, *P_tab = NULL;
+ int size;
if (rta == NULL || rtattr_parse_nested(tb, TCA_POLICE_MAX, rta) < 0)
return -EINVAL;
- if (tb[TCA_POLICE_TBF-1] == NULL ||
- RTA_PAYLOAD(tb[TCA_POLICE_TBF-1]) != sizeof(*parm))
+ if (tb[TCA_POLICE_TBF-1] == NULL)
+ return -EINVAL;
+ size = RTA_PAYLOAD(tb[TCA_POLICE_TBF-1]);
+ if (size != sizeof(*parm) && size != sizeof(struct tc_police_compat))
return -EINVAL;
parm = RTA_DATA(tb[TCA_POLICE_TBF-1]);
@@ -415,12 +430,15 @@ struct tcf_police *tcf_police_locate(str
struct tcf_police *police;
struct rtattr *tb[TCA_POLICE_MAX];
struct tc_police *parm;
+ int size;
if (rtattr_parse_nested(tb, TCA_POLICE_MAX, rta) < 0)
return NULL;
- if (tb[TCA_POLICE_TBF-1] == NULL ||
- RTA_PAYLOAD(tb[TCA_POLICE_TBF-1]) != sizeof(*parm))
+ if (tb[TCA_POLICE_TBF-1] == NULL)
+ return NULL;
+ size = RTA_PAYLOAD(tb[TCA_POLICE_TBF-1]);
+ if (size != sizeof(*parm) && size != sizeof(struct tc_police_compat))
return NULL;
parm = RTA_DATA(tb[TCA_POLICE_TBF-1]);
--
-
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 24/32] add bottom_half.h
-stable review patch. If anyone has any objections, please let us know. -- From: Andrew Morton <[EMAIL PROTECTED]> With CONFIG_SMP=n: drivers/input/ff-memless.c:384: warning: implicit declaration of function 'local_bh_disable' drivers/input/ff-memless.c:393: warning: implicit declaration of function 'local_bh_enable' Really linux/spinlock.h should include linux/interrupt.h. But interrupt.h includes sched.h which will need spinlock.h. So the patch breaks the _bh declarations out into a separate header and includes it in bothj interrupt.h and spinlock.h. Cc: "Randy.Dunlap" <[EMAIL PROTECTED]> Cc: Andi Kleen <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Cc: Ingo Molnar <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Signed-off-by: Chris Wright <[EMAIL PROTECTED]> --- include/linux/bottom_half.h |5 + include/linux/interrupt.h |7 +-- include/linux/spinlock.h|1 + 3 files changed, 7 insertions(+), 6 deletions(-) --- /dev/null +++ linux-2.6.19/include/linux/bottom_half.h @@ -0,0 +1,5 @@ +extern void local_bh_disable(void); +extern void __local_bh_enable(void); +extern void _local_bh_enable(void); +extern void local_bh_enable(void); +extern void local_bh_enable_ip(unsigned long ip); --- linux-2.6.19.orig/include/linux/interrupt.h +++ linux-2.6.19/include/linux/interrupt.h @@ -11,6 +11,7 @@ #include #include #include +#include #include #include #include @@ -217,12 +218,6 @@ static inline void __deprecated save_and #define save_and_cli(x)save_and_cli() #endif /* CONFIG_SMP */ -extern void local_bh_disable(void); -extern void __local_bh_enable(void); -extern void _local_bh_enable(void); -extern void local_bh_enable(void); -extern void local_bh_enable_ip(unsigned long ip); - /* PLEASE, avoid to allocate new softirqs, if you need not _really_ high frequency threaded job scheduling. For almost all the purposes tasklets are more than enough. F.e. all serial device BHs et --- linux-2.6.19.orig/include/linux/spinlock.h +++ linux-2.6.19/include/linux/spinlock.h @@ -52,6 +52,7 @@ #include #include #include +#include #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/
Re: [patch] net: dev_watchdog() locking fix
On Fri, Dec 08, 2006 at 03:19:02PM -0800, Andrew Morton wrote:
>
> Like this?
>
> /* don't get messages out of order, and no recursion */
> if (skb_queue_len(>txq) == 0 &&
> npinfo->poll_owner != smp_processor_id()) {
> local_bh_disable(); /* Where's netif_tx_trylock_bh()? */
> if (netif_tx_trylock(dev)) {
> /* try until next clock tick */
> for (tries = jiffies_to_usecs(1)/USEC_PER_POLL;
> tries > 0; --tries) {
> if (!netif_queue_stopped(dev))
> status = dev->hard_start_xmit(skb, dev);
>
> if (status == NETDEV_TX_OK)
> break;
>
> /* tickle device maybe there is some cleanup */
> netpoll_poll(np);
>
> udelay(USEC_PER_POLL);
> }
> netif_tx_unlock(dev);
> }
> local_bh_enable();
> }
Looks good to me. Thanks Andrew!
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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 12/32] NETFILTER: Fix {ip, ip6, arp}_tables hook validation
-stable review patch. If anyone has any objections, please let us know.
--
From: Dmitry Mishin <[EMAIL PROTECTED]>
Commit 590bdf7fd2292b47c428111cb1360e312eff207e introduced a regression
in match/target hook validation. mark_source_chains builds a bitmask
for each rule representing the hooks it can be reached from, which is
then used by the matches and targets to make sure they are only called
from valid hooks. The patch moved the match/target specific validation
before the mark_source_chains call, at which point the mask is always zero.
This patch returns back to the old order and moves the standard checks
to mark_source_chains. This allows to get rid of a special case for
standard targets as a nice side-effect.
Signed-off-by: Dmitry Mishin <[EMAIL PROTECTED]>
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
commit 756c508367e95d6f963502e4feecb8c76aeee332
tree 2be0ffb477e890a713eb48f3993a2f425baf5683
parent 0215ffb08ce99e2bb59eca114a99499a4d06e704
author Dmitry Mishin <[EMAIL PROTECTED]> Mon, 04 Dec 2006 12:19:27 +0100
committer Patrick McHardy <[EMAIL PROTECTED]> Mon, 04 Dec 2006 12:19:27 +0100
net/ipv4/netfilter/arp_tables.c | 48 ++--
net/ipv4/netfilter/ip_tables.c | 68 ++--
net/ipv6/netfilter/ip6_tables.c | 59 +-
3 files changed, 72 insertions(+), 103 deletions(-)
--- linux-2.6.19.orig/net/ipv4/netfilter/arp_tables.c
+++ linux-2.6.19/net/ipv4/netfilter/arp_tables.c
@@ -375,6 +375,13 @@ static int mark_source_chains(struct xt_
&& unconditional(>arp)) {
unsigned int oldpos, size;
+ if (t->verdict < -NF_MAX_VERDICT - 1) {
+ duprintf("mark_source_chains: bad "
+ "negative verdict (%i)\n",
+ t->verdict);
+ return 0;
+ }
+
/* Return: backtrack through the last
* big jump.
*/
@@ -404,6 +411,14 @@ static int mark_source_chains(struct xt_
if (strcmp(t->target.u.user.name,
ARPT_STANDARD_TARGET) == 0
&& newpos >= 0) {
+ if (newpos > newinfo->size -
+ sizeof(struct arpt_entry)) {
+ duprintf("mark_source_chains: "
+ "bad verdict (%i)\n",
+ newpos);
+ return 0;
+ }
+
/* This a jump; chase it. */
duprintf("Jump rule %u -> %u\n",
pos, newpos);
@@ -426,8 +441,6 @@ static int mark_source_chains(struct xt_
static inline int standard_check(const struct arpt_entry_target *t,
unsigned int max_offset)
{
- struct arpt_standard_target *targ = (void *)t;
-
/* Check standard info. */
if (t->u.target_size
!= ARPT_ALIGN(sizeof(struct arpt_standard_target))) {
@@ -437,18 +450,6 @@ static inline int standard_check(const s
return 0;
}
- if (targ->verdict >= 0
- && targ->verdict > max_offset - sizeof(struct arpt_entry)) {
- duprintf("arpt_standard_check: bad verdict (%i)\n",
-targ->verdict);
- return 0;
- }
-
- if (targ->verdict < -NF_MAX_VERDICT - 1) {
- duprintf("arpt_standard_check: bad negative verdict (%i)\n",
-targ->verdict);
- return 0;
- }
return 1;
}
@@ -627,18 +628,20 @@ static int translate_table(const char *n
}
}
+ if (!mark_source_chains(newinfo, valid_hooks, entry0)) {
+ duprintf("Looping hook\n");
+ return -ELOOP;
+ }
+
/* Finally, each sanity check must pass */
i = 0;
ret = ARPT_ENTRY_ITERATE(entry0, newinfo->size,
check_entry, name, size, );
- if (ret != 0)
- goto cleanup;
-
- ret = -ELOOP;
- if (!mark_source_chains(newinfo, valid_hooks, entry0)) {
- duprintf("Looping hook\n");
- goto cleanup;
+ if (ret != 0) {
+ ARPT_ENTRY_ITERATE(entry0, newinfo->size,
+ cleanup_entry, );
+ return ret;
}
[patch 01/32] IPV6 NDISC: Calculate packet length correctly for allocation.
-stable review patch. If anyone has any objections, please let us know.
--
From: David Miller <[EMAIL PROTECTED]>
MAX_HEADER does not include the ipv6 header length in it,
so we need to add it in explicitly.
With help from YOSHIFUJI Hideaki.
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
commit 6e38433357e2381bb278a418fb7e2fd201475101
Author: David S. Miller <[EMAIL PROTECTED]>
Date: Sat Dec 2 21:00:06 2006 -0800
net/ipv6/ndisc.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
--- linux-2.6.19.orig/net/ipv6/ndisc.c
+++ linux-2.6.19/net/ipv6/ndisc.c
@@ -472,7 +472,9 @@ static void ndisc_send_na(struct net_dev
inc_opt = 0;
}
- skb = sock_alloc_send_skb(sk, MAX_HEADER + len + LL_RESERVED_SPACE(dev),
+ skb = sock_alloc_send_skb(sk,
+ (MAX_HEADER + sizeof(struct ipv6hdr) +
+ len + LL_RESERVED_SPACE(dev)),
1, );
if (skb == NULL) {
@@ -561,7 +563,9 @@ void ndisc_send_ns(struct net_device *de
if (send_llinfo)
len += ndisc_opt_addr_space(dev);
- skb = sock_alloc_send_skb(sk, MAX_HEADER + len + LL_RESERVED_SPACE(dev),
+ skb = sock_alloc_send_skb(sk,
+ (MAX_HEADER + sizeof(struct ipv6hdr) +
+ len + LL_RESERVED_SPACE(dev)),
1, );
if (skb == NULL) {
ND_PRINTK0(KERN_ERR
@@ -636,7 +640,9 @@ void ndisc_send_rs(struct net_device *de
if (dev->addr_len)
len += ndisc_opt_addr_space(dev);
-skb = sock_alloc_send_skb(sk, MAX_HEADER + len +
LL_RESERVED_SPACE(dev),
+skb = sock_alloc_send_skb(sk,
+ (MAX_HEADER + sizeof(struct ipv6hdr) +
+ len + LL_RESERVED_SPACE(dev)),
1, );
if (skb == NULL) {
ND_PRINTK0(KERN_ERR
@@ -1446,7 +1452,9 @@ void ndisc_send_redirect(struct sk_buff
rd_len &= ~0x7;
len += rd_len;
- buff = sock_alloc_send_skb(sk, MAX_HEADER + len +
LL_RESERVED_SPACE(dev),
+ buff = sock_alloc_send_skb(sk,
+ (MAX_HEADER + sizeof(struct ipv6hdr) +
+ len + LL_RESERVED_SPACE(dev)),
1, );
if (buff == NULL) {
ND_PRINTK0(KERN_ERR
--
-
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 02/32] softmac: remove netif_tx_disable when scanning
-stable review patch. If anyone has any objections, please let us know.
--
From: Michael Buesch <[EMAIL PROTECTED]>
In the scan section of ieee80211softmac, network transmits are disabled.
When SoftMAC re-enables transmits, it may override the wishes of a driver
that may have very good reasons for disabling transmits. At least one failure
in bcm43xx can be traced to this problem. In addition, several unexplained
problems may arise from the unexpected enabling of transmits.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
net/ieee80211/softmac/ieee80211softmac_scan.c |2 --
1 file changed, 2 deletions(-)
--- linux-2.6.19.orig/net/ieee80211/softmac/ieee80211softmac_scan.c
+++ linux-2.6.19/net/ieee80211/softmac/ieee80211softmac_scan.c
@@ -47,7 +47,6 @@ ieee80211softmac_start_scan(struct ieee8
sm->scanning = 1;
spin_unlock_irqrestore(>lock, flags);
- netif_tx_disable(sm->ieee->dev);
ret = sm->start_scan(sm->dev);
if (ret) {
spin_lock_irqsave(>lock, flags);
@@ -248,7 +247,6 @@ void ieee80211softmac_scan_finished(stru
if (net)
sm->set_channel(sm->dev, net->channel);
}
- netif_wake_queue(sm->ieee->dev);
ieee80211softmac_call_events(sm, IEEE80211SOFTMAC_EVENT_SCAN_FINISHED,
NULL);
}
EXPORT_SYMBOL_GPL(ieee80211softmac_scan_finished);
--
-
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 09/32] Revert "ACPI: SCI interrupt source override"
-stable review patch. If anyone has any objections, please let us know.
--
From: Len Brown <[EMAIL PROTECTED]>
This reverts commit 281ea49b0c294649a6de47a6f8fbe5611137726b,
which broke ACPI Interrupt source overrides that move
the SCI from one IRQ in PIC mode to another in IOAPIC mode.
If the SCI shared an interrupt line with another device,
this would result in a "irq 18: nobody cared" type failure.
http://bugzilla.kernel.org/show_bug.cgi?id=7601
Signed-off-by: Len Brown <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
arch/i386/kernel/acpi/boot.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
--- linux-2.6.19.orig/arch/i386/kernel/acpi/boot.c
+++ linux-2.6.19/arch/i386/kernel/acpi/boot.c
@@ -333,7 +333,7 @@ acpi_parse_ioapic(acpi_table_entry_heade
/*
* Parse Interrupt Source Override for the ACPI SCI
*/
-static void acpi_sci_ioapic_setup(u32 bus_irq, u32 gsi, u16 polarity, u16
trigger)
+static void acpi_sci_ioapic_setup(u32 gsi, u16 polarity, u16 trigger)
{
if (trigger == 0) /* compatible SCI trigger is level */
trigger = 3;
@@ -353,13 +353,13 @@ static void acpi_sci_ioapic_setup(u32 bu
* If GSI is < 16, this will update its flags,
* else it will create a new mp_irqs[] entry.
*/
- mp_override_legacy_irq(bus_irq, polarity, trigger, gsi);
+ mp_override_legacy_irq(gsi, polarity, trigger, gsi);
/*
* stash over-ride to indicate we've been here
* and for later update of acpi_fadt
*/
- acpi_sci_override_gsi = bus_irq;
+ acpi_sci_override_gsi = gsi;
return;
}
@@ -377,7 +377,7 @@ acpi_parse_int_src_ovr(acpi_table_entry_
acpi_table_print_madt_entry(header);
if (intsrc->bus_irq == acpi_fadt.sci_int) {
- acpi_sci_ioapic_setup(intsrc->bus_irq, intsrc->global_irq,
+ acpi_sci_ioapic_setup(intsrc->global_irq,
intsrc->flags.polarity,
intsrc->flags.trigger);
return 0;
@@ -880,7 +880,7 @@ static int __init acpi_parse_madt_ioapic
* pretend we got one so we can set the SCI flags.
*/
if (!acpi_sci_override_gsi)
- acpi_sci_ioapic_setup(acpi_fadt.sci_int, acpi_fadt.sci_int, 0,
0);
+ acpi_sci_ioapic_setup(acpi_fadt.sci_int, 0, 0);
/* Fill in identity legacy mapings where no override */
mp_config_acpi_legacy_irqs();
--
-
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 00/32] -stable review
This is the start of the stable review cycle for the 2.6.19.1 release. There are 32 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let us know. If anyone is a maintainer of the proper subsystem, and wants to add a Signed-off-by: line to the patch, please respond with it. These patches are sent out with a number of different people on the Cc: line. If you wish to be a reviewer, please email [EMAIL PROTECTED] to add your name to the list. If you want to be off the reviewer list, also email us. Responses should be made by Mon Dec 11 00:00 UTC Anything received after that time might be too late. thanks, the -stable release team -- - 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: Status of buffered write path (deadlock fixes)
On Fri, Dec 08, 2006 at 02:28:10PM +1100, Nick Piggin wrote: > >In generic_file_buffered_write() we now do: > > > > status = a_ops->commit_write(file, page, offset,offset+copied); > > > >Which tells the file system to commit only the amount of data that > >filemap_copy_from_user() was able to pull in, despite our zeroing of > >the newly allocated buffers in the copied != bytes case. Shouldn't we be > >doing: > > > >status = a_ops->commit_write(file, page, offset,offset+bytes); > > > >instead, thus preserving ordered writeout (for ext3, ocfs2, etc) for those > >parts of the page which are properly allocated and zero'd but haven't been > >copied into yet? I think that in the case of a crash just after the > >transaction is closed in ->commit_write(), we might lose those guarantees, > >exposing stale data on disk. > > No, because we might be talking about buffers that haven't been newly > allocated, but are not uptodate (so the pagecache can contain junk). > > We can't zero these guys and do the commit_write, because that exposes > transient zeroes to a concurrent reader. Ahh ok - zeroing would populate with incorrect data and we can't write those buffers because we'd write junk over good data. And of course, the way it works right now will break ordered write mode. Sigh. > What we *could* do, is to do the full length commit_write for uptodate > pages, even if the copy is short. But we still need to do a zero-length > commit_write if the page is not uptodate (this would reduce the number > of new cases that need to be considered). > > Does a short commit_write cause a problem for filesystems? They can > still do any and all operations they would have with a full-length one. If they've done allocation, yes. You're telling the file system to stop early in the page, even though there may be BH_New buffers further on which should be processed (for things like ordered data mode). Hmm, I think we should just just change functions like walk_page_buffers() in fs/ext3/inode.c and fs/ocfs2/aops.c to look for BH_New buffers outside the range specified (they walk the entire buffer list anyway). If it finds one that's buffer_new() it passes it to the journal unconditionally. You'd also have to revert the change you did in fs/ext3/inode.c to at least always make the call to walk_page_buffers(). I really don't like that we're hiding a detail of this interaction so deep within the file system commit_write() callback. I suppose we can just do our best to document it. > But maybe it would be better to eliminate that case. OK. > How about a zero-length commit_write? In that case again, they should > be able to remain unchanged *except* that they are not to extend i_size > or mark the page uptodate. If we make the change I described above (looking for BH_New buffers outside the range passed), then zero length or partial shouldn't matter, but zero length instead of partial would be nicer imho just for the sake of reducing the total number of cases down to the entire range or zero length. > >For some reason, I'm not seeing where BH_New is being cleared in case with > >no errors or faults. Hopefully I'm wrong, but if I'm not I believe we need > >to clear the flag somewhere (perhaps in block_commit_write()?). > > Hmm, it is a bit inconsistent. It seems to be anywhere from prepare_write > to block_write_full_page. > > Where do filesystems need the bit? It would be nice to clear it in > commit_write if possible. Worst case we'll need a new bit. ->commit_write() would probably do fine. Currently, block_prepare_write() uses it to know which buffers were newly allocated (the file system specific get_block_t sets the bit after allocation). I think we could safely move the clearing of that bit to block_commit_write(), thus still allowing us to detect and zero those blocks in generic_file_buffered_write() Thanks, --Mark -- Mark Fasheh Senior Software Developer, Oracle [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/
[PATCH] kcalloc: Re-order the first two out-of-order args to kcalloc().
Some calls to kcalloc() appear to have the first two args in the
wrong order.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
drivers/macintosh/smu.c |2 +-
drivers/net/skge.c |2 +-
drivers/scsi/sym53c8xx_2/sym_hipd.c |2 +-
drivers/usb/misc/uss720.c |2 +-
net/sunrpc/svc.c|2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/macintosh/smu.c b/drivers/macintosh/smu.c
index 6dde27a..8c36894 100644
--- a/drivers/macintosh/smu.c
+++ b/drivers/macintosh/smu.c
@@ -945,7 +945,7 @@ static struct smu_sdbp_header *smu_creat
*/
tlen = sizeof(struct property) + len + 18;
- prop = kcalloc(tlen, 1, GFP_KERNEL);
+ prop = kcalloc(1, tlen, GFP_KERNEL);
if (prop == NULL)
return NULL;
hdr = (struct smu_sdbp_header *)(prop + 1);
diff --git a/drivers/net/skge.c b/drivers/net/skge.c
index b60f045..8a39376 100644
--- a/drivers/net/skge.c
+++ b/drivers/net/skge.c
@@ -749,7 +749,7 @@ static int skge_ring_alloc(struct skge_r
struct skge_element *e;
int i;
- ring->start = kcalloc(sizeof(*e), ring->count, GFP_KERNEL);
+ ring->start = kcalloc(ring->count, sizeof(*e), GFP_KERNEL);
if (!ring->start)
return -ENOMEM;
diff --git a/drivers/scsi/sym53c8xx_2/sym_hipd.c
b/drivers/scsi/sym53c8xx_2/sym_hipd.c
index 940fa1e..21cd4c7 100644
--- a/drivers/scsi/sym53c8xx_2/sym_hipd.c
+++ b/drivers/scsi/sym53c8xx_2/sym_hipd.c
@@ -5545,7 +5545,7 @@ int sym_hcb_attach(struct Scsi_Host *sho
/*
* Allocate the array of lists of CCBs hashed by DSA.
*/
- np->ccbh = kcalloc(sizeof(struct sym_ccb **), CCB_HASH_SIZE,
GFP_KERNEL);
+ np->ccbh = kcalloc(CCB_HASH_SIZE, sizeof(struct sym_ccb **),
GFP_KERNEL);
if (!np->ccbh)
goto attach_failed;
diff --git a/drivers/usb/misc/uss720.c b/drivers/usb/misc/uss720.c
index 7e8a0ac..0df16f9 100644
--- a/drivers/usb/misc/uss720.c
+++ b/drivers/usb/misc/uss720.c
@@ -705,7 +705,7 @@ static int uss720_probe(struct usb_inter
/*
* Allocate parport interface
*/
- if (!(priv = kcalloc(sizeof(struct parport_uss720_private), 1,
GFP_KERNEL))) {
+ if (!(priv = kcalloc(1, sizeof(struct parport_uss720_private),
GFP_KERNEL))) {
usb_put_dev(usbdev);
return -ENOMEM;
}
diff --git a/net/sunrpc/svc.c b/net/sunrpc/svc.c
index eb44ec9..1ae79a8 100644
--- a/net/sunrpc/svc.c
+++ b/net/sunrpc/svc.c
@@ -308,7 +308,7 @@ __svc_create(struct svc_program *prog, u
serv->sv_nrpools = npools;
serv->sv_pools =
- kcalloc(sizeof(struct svc_pool), serv->sv_nrpools,
+ kcalloc(serv->sv_nrpools, sizeof(struct svc_pool),
GFP_KERNEL);
if (!serv->sv_pools) {
kfree(serv);
-
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 RFC] use of activate_mm in fs/aio.c:use_mm()?
On Wed, 06 Dec 2006 17:36:02 -0800 Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote: > Jeremy Fitzhardinge wrote: > > I'm wondering if activate_mm() is the right thing to be using in > > use_mm(); shouldn't this be switch_mm()? > > > > On normal x86, they're synonymous, but for the Xen patches I'm adding a > > hook which assumes that activate_mm is only used the first time a new mm > > is used after creation (I have another hook for dealing with dup_mm). I > > think this use of activate_mm() is the only place where it could be used > > a second time on an mm. > > > > From a quick look at the other architectures I think this is OK (most > > simply implement one in terms of the other), but some are doing some > > subtly different stuff between the two. > > > > Thanks, > > J > > > > > > > Er, lets try that again: > > diff -r 455b71ed4525 fs/aio.c > --- a/fs/aio.cWed Dec 06 13:16:42 2006 -0800 > +++ b/fs/aio.cWed Dec 06 17:17:43 2006 -0800 > @@ -588,7 +588,7 @@ static void use_mm(struct mm_struct *mm) >* Note that on UML this *requires* PF_BORROWED_MM to be set, otherwise >* it won't work. Update it accordingly if you change it here >*/ > - activate_mm(active_mm, mm); > + switch_mm(active_mm, mm, tsk); > task_unlock(tsk); > > mmdrop(active_mm); That to me sounds like a reasonable description of the difference between activate_mm() and switch_mm(). And the change appears reasonable as well. But it is a change which the architecture maintainers would need to have a think about, please. - 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] e1000: use pcix_set_mmrbc
On 12/8/06, Auke Kok <[EMAIL PROTECTED]> wrote: Stephen Hemminger wrote: > On Fri, 08 Dec 2006 13:45:05 -0800 > > Hmm.. looks like all that code should really be moved off to PCI bus > quirk/setup. None of it is E1000 specific. Something like this (untested): This is not true, and I have to NAK the original patch. Part of the code Stephan is removing fixes a BUG in one of our *e1000 parts* that has the wrong size. It would be nice to fix generix pci-x issues qith quirks for platforms but the adjustment needs to stay for this specific e1000 case. Perhaps we can accomodate that specific case so that it is apparent from our code, as is not the case right now. Auke PS Thanks to Jeb for fishing this out ;) Actually there are two issues that are being resolved with this function: 1- BIOS reports incorrect maximum memory read byte count (mmrbc). This was seen on some older systems > 5 years ago. 2- EEPROM is reporting an incorrect mmrbc. This function corrects both of these issues, Stephen second suggestion of moving the BIOS fix to quirks.c is fine with me. Even with the code added to quirks.c, we still need this workaround as is to correct for EEPROM's reporting 4k for a mmrbc. So I am fine with Stephen's second suggestion NAK the suggested change to e1000_hw.c -- Cheers, 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/
Re: [patch] net: dev_watchdog() locking fix
On Fri, 8 Dec 2006 08:06:57 +1100
Herbert Xu <[EMAIL PROTECTED]> wrote:
> On Thu, Dec 07, 2006 at 09:55:22PM +0100, Ingo Molnar wrote:
> >
> > fallout of the recent big networking merge i guess. Tested fix below.
> > David, Herbert, do you agree with it, or is it a false positive?
>
> I agree that this is a bug, but the fix is in the wrong spot. The
> dev_watchdog function already runs in softirq context so it doesn't
> need to disable BH.
>
> You can almost be guaranteed that if netpoll is involved in a bug
> then it should be fixed :)
>
> In this case, it's taking the tx lock in process context which is
> not allowed. So it should disable BH before taking the tx lock.
>
Like this?
/* don't get messages out of order, and no recursion */
if (skb_queue_len(>txq) == 0 &&
npinfo->poll_owner != smp_processor_id()) {
local_bh_disable(); /* Where's netif_tx_trylock_bh()? */
if (netif_tx_trylock(dev)) {
/* try until next clock tick */
for (tries = jiffies_to_usecs(1)/USEC_PER_POLL;
tries > 0; --tries) {
if (!netif_queue_stopped(dev))
status = dev->hard_start_xmit(skb, dev);
if (status == NETDEV_TX_OK)
break;
/* tickle device maybe there is some cleanup */
netpoll_poll(np);
udelay(USEC_PER_POLL);
}
netif_tx_unlock(dev);
}
local_bh_enable();
}
--- a/net/core/netpoll.c~netpoll-locking-fix
+++ a/net/core/netpoll.c
@@ -242,22 +242,26 @@ static void netpoll_send_skb(struct netp
/* don't get messages out of order, and no recursion */
if (skb_queue_len(>txq) == 0 &&
- npinfo->poll_owner != smp_processor_id() &&
- netif_tx_trylock(dev)) {
- /* try until next clock tick */
- for (tries = jiffies_to_usecs(1)/USEC_PER_POLL; tries > 0;
--tries) {
- if (!netif_queue_stopped(dev))
- status = dev->hard_start_xmit(skb, dev);
+ npinfo->poll_owner != smp_processor_id()) {
+ local_bh_disable(); /* Where's netif_tx_trylock_bh()? */
+ if (netif_tx_trylock(dev)) {
+ /* try until next clock tick */
+ for (tries = jiffies_to_usecs(1)/USEC_PER_POLL;
+ tries > 0; --tries) {
+ if (!netif_queue_stopped(dev))
+ status = dev->hard_start_xmit(skb, dev);
- if (status == NETDEV_TX_OK)
- break;
+ if (status == NETDEV_TX_OK)
+ break;
- /* tickle device maybe there is some cleanup */
- netpoll_poll(np);
+ /* tickle device maybe there is some cleanup */
+ netpoll_poll(np);
- udelay(USEC_PER_POLL);
+ udelay(USEC_PER_POLL);
+ }
+ netif_tx_unlock(dev);
}
- netif_tx_unlock(dev);
+ local_bh_enable();
}
if (status != NETDEV_TX_OK) {
_
-
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] sysctl: remove unused "context" param
Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
---
arch/frv/kernel/pm.c |6 ++---
arch/mips/lasat/sysctl.c | 17 ++
arch/x86_64/kernel/vsyscall.c |3 --
drivers/char/random.c |2 -
include/linux/sysctl.h |5 +---
include/net/ip.h |3 --
include/net/sctp/sctp.h|2 -
kernel/sysctl.c| 47 +++--
net/decnet/dn_dev.c|6 +
net/decnet/sysctl_net_decnet.c |6 +
net/ipv4/devinet.c |3 --
net/ipv4/route.c |3 --
net/ipv4/sysctl_net_ipv4.c | 16 +
net/ipv6/addrconf.c|3 --
net/ipv6/ndisc.c |9 ++-
15 files changed, 55 insertions(+), 76 deletions(-)
--- a/arch/frv/kernel/pm.c
+++ b/arch/frv/kernel/pm.c
@@ -223,7 +223,7 @@ static int cmode_procctl(ctl_table *ctl,
static int cmode_sysctl(ctl_table *table, int __user *name, int nlen,
void __user *oldval, size_t __user *oldlenp,
- void __user *newval, size_t newlen, void **context)
+ void __user *newval, size_t newlen)
{
if (oldval && oldlenp) {
size_t oldlen;
@@ -326,7 +326,7 @@ static int p0_procctl(ctl_table *ctl, in
static int p0_sysctl(ctl_table *table, int __user *name, int nlen,
void __user *oldval, size_t __user *oldlenp,
-void __user *newval, size_t newlen, void **context)
+void __user *newval, size_t newlen)
{
if (oldval && oldlenp) {
size_t oldlen;
@@ -370,7 +370,7 @@ static int cm_procctl(ctl_table *ctl, in
static int cm_sysctl(ctl_table *table, int __user *name, int nlen,
void __user *oldval, size_t __user *oldlenp,
-void __user *newval, size_t newlen, void **context)
+void __user *newval, size_t newlen)
{
if (oldval && oldlenp) {
size_t oldlen;
--- a/arch/mips/lasat/sysctl.c
+++ b/arch/mips/lasat/sysctl.c
@@ -40,12 +40,12 @@ static DEFINE_MUTEX(lasat_info_mutex);
/* Strategy function to write EEPROM after changing string entry */
int sysctl_lasatstring(ctl_table *table, int *name, int nlen,
void *oldval, size_t *oldlenp,
- void *newval, size_t newlen, void **context)
+ void *newval, size_t newlen)
{
int r;
mutex_lock(_info_mutex);
r = sysctl_string(table, name,
- nlen, oldval, oldlenp, newval, newlen, context);
+ nlen, oldval, oldlenp, newval, newlen);
if (r < 0) {
mutex_unlock(_info_mutex);
return r;
@@ -119,11 +119,11 @@ #endif
/* Sysctl for setting the IP addresses */
int sysctl_lasat_intvec(ctl_table *table, int *name, int nlen,
void *oldval, size_t *oldlenp,
- void *newval, size_t newlen, void **context)
+ void *newval, size_t newlen)
{
int r;
mutex_lock(_info_mutex);
- r = sysctl_intvec(table, name, nlen, oldval, oldlenp, newval, newlen,
context);
+ r = sysctl_intvec(table, name, nlen, oldval, oldlenp, newval, newlen);
if (r < 0) {
mutex_unlock(_info_mutex);
return r;
@@ -139,14 +139,14 @@ #ifdef CONFIG_DS1603
/* Same for RTC */
int sysctl_lasat_rtc(ctl_table *table, int *name, int nlen,
void *oldval, size_t *oldlenp,
- void *newval, size_t newlen, void **context)
+ void *newval, size_t newlen)
{
int r;
mutex_lock(_info_mutex);
rtctmp = ds1603_read();
if (rtctmp < 0)
rtctmp = 0;
- r = sysctl_intvec(table, name, nlen, oldval, oldlenp, newval, newlen,
context);
+ r = sysctl_intvec(table, name, nlen, oldval, oldlenp, newval, newlen);
if (r < 0) {
mutex_unlock(_info_mutex);
return r;
@@ -251,13 +251,12 @@ #endif /* defined(CONFIG_INET) */
static int sysctl_lasat_eeprom_value(ctl_table *table, int *name, int nlen,
void *oldval, size_t *oldlenp,
-void *newval, size_t newlen,
-void **context)
+void *newval, size_t newlen)
{
int r;
mutex_lock(_info_mutex);
- r = sysctl_intvec(table, name, nlen, oldval, oldlenp, newval, newlen,
context);
+ r = sysctl_intvec(table, name, nlen, oldval, oldlenp, newval, newlen);
if (r < 0) {
mutex_unlock(_info_mutex);
return r;
--- a/arch/x86_64/kernel/vsyscall.c
+++ b/arch/x86_64/kernel/vsyscall.c
@@ -225,8 +225,7 @@ out:
static int vsyscall_sysctl_nostrat(ctl_table *t, int __user *name, int nlen,
void
[PATCH] sysctl: remove some OPs
kernel.cap-bound uses only OP_SET and OP_AND
Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
---
kernel/sysctl.c | 10 --
1 file changed, 10 deletions(-)
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -1931,9 +1931,6 @@ int proc_dointvec(ctl_table *table, int
#define OP_SET 0
#define OP_AND 1
-#define OP_OR 2
-#define OP_MAX 3
-#define OP_MIN 4
static int do_proc_dointvec_bset_conv(int *negp, unsigned long *lvalp,
int *valp,
@@ -1945,13 +1942,6 @@ static int do_proc_dointvec_bset_conv(in
switch(op) {
case OP_SET:*valp = val; break;
case OP_AND:*valp &= val; break;
- case OP_OR: *valp |= val; break;
- case OP_MAX:if(*valp < val)
- *valp = val;
- break;
- case OP_MIN:if(*valp > val)
- *valp = val;
- break;
}
} else {
int val = *valp;
-
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/
