Re: [BUG] [linux-pm] Commit "Hibernation: Enter platform hibernation state in a consistent way)" makes my system to resume instantly from S4
On Sunday 28 October 2007 22:23:15 Rafael J. Wysocki wrote: > On Sunday, 28 October 2007 21:00, Maxim Levitsky wrote: > > On Saturday 27 October 2007 23:46:45 Rafael J. Wysocki wrote: > > > On Saturday, 27 October 2007 14:05, Maxim Levitsky wrote: > > > > Hi, > > > > > > > > Recently I noticed that my system resumes just after suspend to disk. > > > > > > > > I traced this to commit 9cd9a0058dd35268b24fa16795a92c800f4086d4. > > > > > > > > Note: > > > > > > > > This happens only if I enable WOL using /proc/acpi/wakeup > > > > (echo "ILAN" > /proc/acpi/wakeup) > > > > > > What happens after a suspend to RAM? > > I do more testing tomorrow, but what I remember is that, > > I had no issues with suspend-to-ram. > > (And take into account the fact that _all_ wakeup devices were enabled > > always, > > the rc.local does that for me, and still I did quite a lot of suspends, but > > I > > got the immediate resume, only and always after suspend to disk. > > Hm, can you please retest with the above commit applied, but with > device_suspend() in hibernation_platform_enter() replaced by > device_shutdown()? Bingo! doing the above fixes this problem. And... strange, since I did test the system with e1000 unloaded, but still got same bug, back when I chased that bug, thus it is probably not related to e1000 and WOL. the ACPI wake-up source (I have read the DSDT, and ICH datasheets, thus I know that this is a set of bits in southbridge) of e1000 is shared with EHCI and HDA sound codec. (But usb on my system only able to wake from S3, and the soundchip which can theoretically wake up from S3 too, doesn't have this ability) (But disabling this wakeup source, fixes this bug too) Thanks, Best regards, Maxim Levitsky - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Abit F-190HD Onboard rlt8169 Ethernet Controller
The Abit Fatal1ty F-190HD motherboard has a Realtek rlt8169 gigabit
ethernet controller onboard. It shows up in lspci as:
02:00.0 Ethernet controller: Unknown device 0001:8168 (rev 01)
Subsystem: ABIT Computer Corp. Unknown device 2410
Flags: bus master, fast devsel, latency 0, IRQ 16
I/O ports at ee00 [size=256]
Memory at fdeff000 (64-bit, non-prefetchable) [size=4K]
[virtual] Expansion ROM at fdd0 [disabled] [size=128K]
Capabilities: [40] Power Management version 2
Capabilities: [48] Vital Product Data
Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+
Queue=0/1 Enable-
Capabilities: [60] Express Endpoint, MSI 00
Capabilities: [84] Vendor Specific Information
Capabilities: [100] Advanced Error Reporting
Capabilities: [12c] Virtual Channel
Capabilities: [148] Device Serial Number 81-ec-10-00-00-00-4f-04
Capabilities: [154] Power Budgeting
It is not recognised by 2.6.24-rc1. I'm guessing it's because the
vendor ID is 0001 rather than something sensible. I patched the kernel
as follows:
--- drivers/net/r8169.c.orig2007-10-29 05:37:02.0 +
+++ drivers/net/r8169.c 2007-10-29 05:54:30.0 +
@@ -165,6 +165,7 @@
{ PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8136), 0, 0, RTL_CFG_2 },
{ PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8167), 0, 0, RTL_CFG_0 },
{ PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8168), 0, 0, RTL_CFG_1 },
+ { PCI_DEVICE(PCI_ANY_ID,0x8168), 0, 0, RTL_CFG_2 },
{ PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8169), 0, 0, RTL_CFG_0 },
{ PCI_DEVICE(PCI_VENDOR_ID_DLINK, 0x4300), 0, 0, RTL_CFG_0 },
{ PCI_DEVICE(PCI_VENDOR_ID_AT, 0xc107), 0, 0, RTL_CFG_0 },
This was enough to get the device recognised and operational. (Only
RTL_CFG_2 works, I have no idea why.) Is this the correct approach?
--
Ciaran McCreesh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
dm: struct io_restriction reordered
it saves some bytes memory
Signed-off-by: Vasily Averin <[EMAIL PROTECTED]>
--- a/include/linux/device-mapper.h
+++ b/include/linux/device-mapper.h
@@ -110,12 +110,12 @@ struct target_type {
};
struct io_restrictions {
+ unsigned long seg_boundary_mask;
unsigned intmax_sectors;
+ unsigned intmax_segment_size;
unsigned short max_phys_segments;
unsigned short max_hw_segments;
unsigned short hardsect_size;
- unsigned intmax_segment_size;
- unsigned long seg_boundary_mask;
unsigned char no_cluster; /* inverted so that 0 is default */
};
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
i2o: CONFIG_DEBUG_SG compilation fixed
i2o crashed when CONFIG_DEBUG_SG is enabled because i2o_block_request structure
includes array of scatterlists that should be initialised
Signed-off-by: Vasily Averin <[EMAIL PROTECTED]>
--- a/drivers/message/i2o/i2o_block.c
+++ b/drivers/message/i2o/i2o_block.c
@@ -1137,6 +1137,18 @@ static struct i2o_driver i2o_block_driver = {
*
* Returns 0 on success or negative error code on failure.
*/
+
+#ifdef CONFIG_DEBUG_SG
+static void i2o_block_req_ctor(struct kmem_cache *cachep, void *objp) {
+ sg_init_table(((struct i2o_block_request *)(objp))->sg_table,
+I2O_MAX_PHYS_SEGMENTS);
+}
+
+#define I2O_BLK_CTOR _block_req_ctor
+#else
+#define I2O_BLK_CTOR NULL
+#endif
+
static int __init i2o_block_init(void)
{
int rc;
@@ -1147,7 +1159,7 @@ static int __init i2o_block_init(void)
/* Allocate request mempool and slab */
size = sizeof(struct i2o_block_request);
i2o_blk_req_pool.slab = kmem_cache_create("i2o_block_req", size, 0,
- SLAB_HWCACHE_ALIGN, NULL);
+ SLAB_HWCACHE_ALIGN, I2O_BLK_CTOR);
if (!i2o_blk_req_pool.slab) {
osm_err("can't init request slab\n");
rc = -ENOMEM;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
i2o: debug messages corrected
max_phys_segments and max_sectors were swapped
Signed-off-by: Vasily Averin <[EMAIL PROTECTED]>
--- a/drivers/message/i2o/i2o_block.c
+++ b/drivers/message/i2o/i2o_block.c
@@ -1076,8 +1076,8 @@ static int i2o_block_probe(struct device *dev)
blk_queue_max_sectors(queue, max_sectors);
blk_queue_max_hw_segments(queue, i2o_sg_tablesize(c, body_size));
- osm_debug("max sectors = %d\n", queue->max_phys_segments);
- osm_debug("phys segments = %d\n", queue->max_sectors);
+ osm_debug("max sectors = %d\n", queue->max_sectors);
+ osm_debug("phys segments = %d\n", queue->max_phys_segments);
osm_debug("max hw segments = %d\n", queue->max_hw_segments);
/*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
dm: bounce_pfn limit added
Device mapper uses its own bounce_pfn that may differ from one on underlying
device. In that way dm can build incorrect requests that contain sg elements
greater than underlying device is able to handle.
This is the cause of slab corruption in i2o layer, occurred on i386 arch when
very long direct IO requests are addressed to dm-over-i2o device.
Signed-off-by: Vasily Averin <[EMAIL PROTECTED]>
--- a/drivers/md/dm-table.c
+++ b/drivers/md/dm-table.c
@@ -102,6 +102,8 @@ static void combine_restrictions_low(struct io_restrictions
lhs->seg_boundary_mask =
min_not_zero(lhs->seg_boundary_mask, rhs->seg_boundary_mask);
+ lhs->bounce_pfn = min_not_zero(lhs->bounce_pfn, rhs->bounce_pfn);
+
lhs->no_cluster |= rhs->no_cluster;
}
@@ -566,6 +568,8 @@ void dm_set_device_limits(struct dm_target *ti, struct
min_not_zero(rs->seg_boundary_mask,
q->seg_boundary_mask);
+ rs->bounce_pfn = min_not_zero(rs->bounce_pfn, q->bounce_pfn);
+
rs->no_cluster |= !test_bit(QUEUE_FLAG_CLUSTER, >queue_flags);
}
EXPORT_SYMBOL_GPL(dm_set_device_limits);
@@ -707,6 +711,8 @@ static void check_for_valid_limits(struct io_restrictions
rs->max_segment_size = MAX_SEGMENT_SIZE;
if (!rs->seg_boundary_mask)
rs->seg_boundary_mask = -1;
+ if (!rs->bounce_pfn)
+ rs->bounce_pfn = -1;
}
int dm_table_add_target(struct dm_table *t, const char *type,
@@ -891,6 +897,7 @@ void dm_table_set_restrictions(struct dm_table *t, struct
q->hardsect_size = t->limits.hardsect_size;
q->max_segment_size = t->limits.max_segment_size;
q->seg_boundary_mask = t->limits.seg_boundary_mask;
+ q->bounce_pfn = t->limits.bounce_pfn;
if (t->limits.no_cluster)
q->queue_flags &= ~(1 << QUEUE_FLAG_CLUSTER);
else
--- a/include/linux/device-mapper.h
+++ b/include/linux/device-mapper.h
@@ -111,6 +111,7 @@ struct target_type {
struct io_restrictions {
unsigned long seg_boundary_mask;
+ unsigned long bounce_pfn;
unsigned intmax_sectors;
unsigned intmax_segment_size;
unsigned short max_phys_segments;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 09/10] SLUB: Do our own locking via slab_lock and slab_unlock.
Hi, On 10/29/07, Christoph Lameter <[EMAIL PROTECTED]> wrote: > > We don't need preempt_enable for CONFIG_SMP, right? > > preempt_enable is needed if preemption is enabled. Disabled? But yeah, I see that slab_trylock() can leave preemption disabled if cmpxchg fails. Was confused by the #ifdefs... :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [REGRESSION] 2.6.24-rc1 fails to boot on a 486
On Sun, 28 Oct 2007 21:34:58 -0700, H. Peter Anvin wrote: > Mikael Pettersson wrote: > > My old 486 fails to boot with the 2.6.24-rc1 kernel. > > Grub loads it, 4 lines of text appear but not the kernel's > > "Linux version greet", and the machine reboots. > > Double-checked with a serial console: nothing appears > > before it reboots. > > > > All 2.6 kernels up to 2.6.23 worked fine on this machine. > > > > Config is at http://user.it.uu.se/~mikpe/linux/tmp/486-config-2.6.24-rc1. > > The kernel is unpatched 2.6.24-rc1 compiled with gcc-4.2.2. > > > > Any chance you could bisect this problem? I can try, but it will have to wait until next weekend. /Mikael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [REGRESSION] 2.6.24-rc1 fails to boot on a 486
On Sun, 28 Oct 2007 21:33:02 -0700, H. Peter Anvin wrote: > Mikael Pettersson wrote: > > My old 486 fails to boot with the 2.6.24-rc1 kernel. > > Grub loads it, 4 lines of text appear but not the kernel's > > "Linux version greet", and the machine reboots. > > Double-checked with a serial console: nothing appears > > before it reboots. > > What four lines of text? They're impossible to capture because they're only visible on the VGA screen for like 0.2 seconds before the machine reboots and the screen is blanked; they don't show up on the serial console. They look like paths to the vmlinuz and initrd surrounded by [ ] brackets, so I guess they come from grub. /Mikael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.23 regression: second access of empty ntfs file leads to D state hang
hrmph, CC to members only list removed. On Mon, 2007-10-29 at 07:08 +0100, Mike Galbraith wrote: > Greetings, > > I've stumbled across a 2.6.22->2.6.23 regression. First md5sum access > of an empty NTFS file leads to kernel I/O error gripe, a second access > leaves md5sum hung. 2.6.22.10 has no trouble accessing this file. > > Looking at the 22->23 diff, I don't see a quick and dirty stab > candidate, and since I'm preparing for a 5 week separation from my box > , I doubt I'll have time to do a bisect. /me punts. > > [EMAIL PROTECTED]: md5sum '/windows/C/Dokumente und Einstellungen/All > Users/Anwendungsdaten/Microsoft/Network/Connections/Pbk/rasphone.pbk' > md5sum: /windows/C/Dokumente und Einstellungen/All > Users/Anwendungsdaten/Microsoft/Network/Connections/Pbk/rasphone.pbk: > Input/output error > > [ 228.551859] NTFS-fs error (device hda1): ntfs_read_compressed_block(): > ntfs_map_runlist() failed. Cannot read compression block. > > [ 401.721890] md5sumD eee53d64 0 7249 7019 > [ 401.727155]eee53d78 00200082 0002 eee53d64 eee53d5c > e9b006b0 e9b00700 > [ 401.735469]5f6b3463 c0677060 c067a080 e9b00860 c180d080 > c180d080 c180d108 > [ 401.743991]0001 00200086 e9b006e0 00200086 f79ca640 eee53d94 > b4d3 00200202 > [ 401.752514] Call Trace: > [ 401.755155] [] io_schedule+0x1e/0x28 > [ 401.759711] [] sync_page+0x34/0x3f > [ 401.764102] [] __wait_on_bit_lock+0x40/0x63 > [ 401.769281] [] __lock_page+0x54/0x5c > [ 401.773845] [] do_generic_mapping_read+0x236/0x4e7 > [ 401.779629] [] generic_file_aio_read+0xff/0x198 > [ 401.785138] [] do_sync_read+0xd0/0x106 > [ 401.789873] [] vfs_read+0x89/0x11d > [ 401.794266] [] sys_read+0x3d/0x64 > [ 401.798569] [] syscall_call+0x7/0xb > [ 401.803039] === > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5]: [PCI]: Remove 3 incorrect MSI quirks.
Shane Huang wrote: >> I would like those to be removed, but to be conservative we should >> first get some testing feedback that confirms this just like those >> provided to me from the AMD folks for the RS690, RX790 and RD580 >> cases. >> >> Otherwise the risk to break people's systems is very real. > > In fact, our team only has boards with RS690+SB700 and RX790+SB700, > I don't know why the RD580 MSI is disabled too by the patch > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commi > t;h=aea6a433f50cd89b9cbd10850fd0b32f961f9883 > Maybe Tejun can give us more information on this case, > I think the cause should be same as RS690 and RX790. I don't remember history of each quirk entry but they're either reported in a bug report and successfully worked around with pci=nomsi or one of AMD guys told me certain PCI IDs share the same problem. I can dig mail archive if you wanna know how it went down for RD580. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] ucc_geth: add support for netpoll
> -Original Message-
> From: Anton Vorontsov [mailto:[EMAIL PROTECTED]
> Sent: Saturday, October 27, 2007 10:38 PM
> To: Sergei Shtylyov
> Cc: Anton Vorontsov; [EMAIL PROTECTED]; Li Yang-r58472;
> linux-kernel@vger.kernel.org; [EMAIL PROTECTED]
> Subject: Re: [PATCH] ucc_geth: add support for netpoll
>
> On Sat, Oct 27, 2007 at 05:09:51PM +0400, Sergei Shtylyov wrote:
> > Hello.
> >
> > Anton Vorontsov wrote:
> >
> > > This patch adds netpoll support for the QE UCC Gigabit Ethernet
> > > driver. The approach is very similar to the gianfar driver.
> >
> > It's rather contrarywise -- this is standard approach
> and gianfar
> > with its
> > 3 TSEC IRQs has a quite non-standard poll_controller()
> implementation.
>
> Oh.. well, right -- gianfar a bit more comlex in that regard.
>
> >
> > > Tested using netconsole.
> >
> > KGDBoE is considered a better test (I hope you've also
> tested with it).
>
> At the time of posting it was tested using netconsole only, a
> few days later it's was tested using KGDBoE also. So, it works indeed.
>
> > > Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
> diff --git
> > > a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c index
> > > 18a6f48..06807ce 100644
> > > --- a/drivers/net/ucc_geth.c
> > > +++ b/drivers/net/ucc_geth.c
> > > @@ -3691,6 +3691,22 @@ static irqreturn_t
> ucc_geth_irq_handler(int irq, void *info)
> > > return IRQ_HANDLED;
> > > }
> > >
> > > +#ifdef CONFIG_NET_POLL_CONTROLLER
> > > +/*
> > > + * Polling 'interrupt' - used by things like netconsole to send
> > > +skbs
> > > + * without having to re-enable interrupts. It's not called while
> > > + * the interrupt routine is executing.
> > > + */
> > > +static void ucc_netpoll(struct net_device *dev) {
> > > + struct ucc_geth_private *ugeth = netdev_priv(dev);
> > > +
> > > + disable_irq(ugeth->ug_info->uf_info.irq);
> > > + ucc_geth_irq_handler(ugeth->ug_info->uf_info.irq, dev);
> > > + enable_irq(ugeth->ug_info->uf_info.irq);
> >
> > Why not make it less complex (for a reader and gcc too :-) ?
>
> Yup, I'm agree here but it's too late. Again. ;-)
>
> This patch already accepted into the -mm (a week or so after
> the silence), so.. now I'd rather not bother Andrew with such
> really cosmetic changes. But if Jeff would directly apply
> modfied patch, I'll send it. ;-)
Oops. The original patch happened to hit the Junk mail box. :( I think
the patch is good to merge after the cosmetic change. I can do it in
next pull request to Jeff.
Thanks
- Leo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: western digital WD1500ADFD: spurious completions during NCQ
Jeff Garrett wrote: > Several threads that suggest this message is related to poor NCQ > support, but I did not see any for this drive. It's a Western Digital > WD1500ADFD-00NLR1. Is this the same thing, and should this drive be > blacklisted? How reproducible is the problem? -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.23 regression: second access of empty ntfs file leads to D state hang
Greetings, I've stumbled across a 2.6.22->2.6.23 regression. First md5sum access of an empty NTFS file leads to kernel I/O error gripe, a second access leaves md5sum hung. 2.6.22.10 has no trouble accessing this file. Looking at the 22->23 diff, I don't see a quick and dirty stab candidate, and since I'm preparing for a 5 week separation from my box , I doubt I'll have time to do a bisect. /me punts. [EMAIL PROTECTED]: md5sum '/windows/C/Dokumente und Einstellungen/All Users/Anwendungsdaten/Microsoft/Network/Connections/Pbk/rasphone.pbk' md5sum: /windows/C/Dokumente und Einstellungen/All Users/Anwendungsdaten/Microsoft/Network/Connections/Pbk/rasphone.pbk: Input/output error [ 228.551859] NTFS-fs error (device hda1): ntfs_read_compressed_block(): ntfs_map_runlist() failed. Cannot read compression block. [ 401.721890] md5sumD eee53d64 0 7249 7019 [ 401.727155]eee53d78 00200082 0002 eee53d64 eee53d5c e9b006b0 e9b00700 [ 401.735469]5f6b3463 c0677060 c067a080 e9b00860 c180d080 c180d080 c180d108 [ 401.743991]0001 00200086 e9b006e0 00200086 f79ca640 eee53d94 b4d3 00200202 [ 401.752514] Call Trace: [ 401.755155] [] io_schedule+0x1e/0x28 [ 401.759711] [] sync_page+0x34/0x3f [ 401.764102] [] __wait_on_bit_lock+0x40/0x63 [ 401.769281] [] __lock_page+0x54/0x5c [ 401.773845] [] do_generic_mapping_read+0x236/0x4e7 [ 401.779629] [] generic_file_aio_read+0xff/0x198 [ 401.785138] [] do_sync_read+0xd0/0x106 [ 401.789873] [] vfs_read+0x89/0x11d [ 401.794266] [] sys_read+0x3d/0x64 [ 401.798569] [] syscall_call+0x7/0xb [ 401.803039] === - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 5/5]: [PCI]: Remove 3 incorrect MSI quirks.
> I would like those to be removed, but to be conservative we should > first get some testing feedback that confirms this just like those > provided to me from the AMD folks for the RS690, RX790 and RD580 > cases. > > Otherwise the risk to break people's systems is very real. In fact, our team only has boards with RS690+SB700 and RX790+SB700, I don't know why the RD580 MSI is disabled too by the patch http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commi t;h=aea6a433f50cd89b9cbd10850fd0b32f961f9883 Maybe Tejun can give us more information on this case, I think the cause should be same as RS690 and RX790. If you need some small test on USB issue related with RS480 or something else, you may tell me, I can try to ask the help from our SW QA or test by myself, if we can find out such test platform. Thanks Shane - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: 2.6 patch] remove the USB_STORAGE_ONETOUCH driver
On 10/29/07, Dmitry Torokhov <[EMAIL PROTECTED]> wrote: > On Sunday 28 October 2007 16:39, Jiri Kosina wrote: > > On Sun, 28 Oct 2007, Torsten Kaiser wrote: > > > > > But it looks like that uses another driver: > > > hiddev0hidraw1: USB HID v1.10 Device [Western Digital External HDD] on > > > usb-:00:02.1-5.2 > > > Otherwise I would be willing to try to test this, if someone would tell > > > me how to check that the second commit did fix the suspend problem. [snip] > Maybe onetouch driver is not needed after all. I wonder what key/button does > HID deriver reports when it binds to it... Torsten, could you please post > your /proc/bus/input/devices? I only read the mail from Adrian, because I was 100% sure that my device is such a Maxtor Onetouch, because it's a external HDD and has buttons. (I even compiled this driver into my kernel when it was added...) But after finding these two git commits and starting to write my initial mail I looked for the exact name of my device and found that this is not a Maxtor at all but a Western Digital. So I'm rather unsure if this driver will work for me... Anyway here is my /proc/bus/input/devices: I: Bus=0019 Vendor= Product=0002 Version= N: Name="Power Button (FF)" P: Phys=LNXPWRBN/button/input0 S: Sysfs=/devices/virtual/input/input0 U: Uniq= H: Handlers=kbd event0 B: EV=3 B: KEY=10 0 I: Bus=0019 Vendor= Product=0001 Version= N: Name="Power Button (CM)" P: Phys=PNP0C0C/button/input0 S: Sysfs=/devices/virtual/input/input1 U: Uniq= H: Handlers=kbd event1 B: EV=3 B: KEY=10 0 I: Bus=0011 Vendor=0001 Product=0001 Version=ab41 N: Name="AT Translated Set 2 keyboard" P: Phys=isa0060/serio0/input0 S: Sysfs=/devices/platform/i8042/serio0/input/input2 U: Uniq= H: Handlers=kbd event2 B: EV=120013 B: KEY=40200 3803078f800d001 fedfffef fffe B: MSC=10 B: LED=7 I: Bus=0010 Vendor=001f Product=0001 Version=0100 N: Name="PC Speaker" P: Phys=isa0061/input0 S: Sysfs=/devices/platform/pcspkr/input/input3 U: Uniq= H: Handlers=kbd event3 B: EV=40001 B: SND=6 I: Bus=0003 Vendor=062a Product= Version=0110 N: Name="HID 062a:" P: Phys=usb-:00:02.0-9/input0 S: Sysfs=/devices/pci:00/:00:02.0/usb2/2-9/2-9:1.0/input/input4 U: Uniq= H: Handlers=mouse0 event4 B: EV=17 B: KEY=7 0 0 0 0 B: REL=103 B: MSC=10 The button part of the device is visible in sysfs under bus/usb, but not under class/input: (There is also a cardreader, a hub and the hdd visible under /sys/bus/usb/devices/1-5 ) /sys/bus/usb/devices/1-5.2:1.1 |-- driver -> ../../../../../../../bus/usb/drivers/usbhid |-- ep_81 -> ../../../../../../../devices/pci:00/:00:02.1/usb1/1-5/1-5.2/1-5.2:1.1/usb_endpoint/usbdev1.5_ep81 |-- subsystem -> ../../../../../../../bus/usb |-- usb | `-- hiddev0 | |-- device -> ../../../../../../../../../devices/pci:00/:00:02.1/usb1/1-5/1-5.2/1-5.2:1.1 | `-- subsystem -> ../../../../../../../../../class/usb `-- usb_endpoint `-- usbdev1.5_ep81 |-- device -> ../../../../../../../../../devices/pci:00/:00:02.1/usb1/1-5/1-5.2/1-5.2:1.1 `-- subsystem -> ../../../../../../../../../class/usb_endpoint Torsten - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Align PCI memory regions to page size (4K) - Fix
On Sun, Oct 28, 2007 at 01:03:36PM -0700, Greg KH wrote: > On Sun, Oct 28, 2007 at 03:53:20PM -0400, Barak Fargoun wrote: ... > > About your question: today, some of the hypervisors are using linux > > kernel as their domain-0 (e.g. Xen). In order to implement direct > > hardware access for these native domains (e.g. running windows in a > > virtual machine above Xen), the PCI memory regions should be aligned > > at-least at the page-level (so, a virtual machine - can't see data of > > other devices which may not be assigned to it). So, for that reason, > > we wanted a boot parameter to let us force the kernel to align PCI > > memory regions at-least at a PAGE_SIZE alignment. It is very useful > > for hypervisors which are developed at Linux environment (e.g.: Xen). ... > And if not, why would we not do this for all devices not just for > virtual machines, if it is such a benefit? It's a benefit IFF multiple devices are spread across more than one guest _and_ we don't trust every particating guest to play nicely with IO. That way the Hypervisor can assign one device to a specific guest OS for direct access. E.g. 4 port Gige card could directly support the host and 3 guests with somewhat lower risk of tromping on each other's MMIO space. If Xen is cooperative, this seems a bit paranoid. I don't recall ever seeing a driver bug where the driver accidentally poked MMIO space at the wrong device. That's much more common for IO Port space. The only exception was xfree86 where it poked around in random places to deal with buggy HW quirks. The use of an IOMMU will provide much more useful protection. grant - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [alsa-devel] sysfs: WARNING: at fs/sysfs/dir.c:424 sysfs_add_one() - with ALSA
Tobin Davis wrote: > First think I noticed, why are you compiling all the drivers into the > kernel instead of as modules? Do you need every sound device supported > simultaneously? > > Tobin > > On Fri, 2007-10-26 at 22:45 +0530, Kamalesh Babulal wrote: >> Takashi Iwai wrote: >> > At Fri, 26 Oct 2007 08:52:02 -0700, >> > Greg KH wrote: >> >> On Fri, Oct 26, 2007 at 02:47:22PM +0530, Kamalesh Babulal wrote: >> >>> I get similar warning, while loading the alsa driver >> >> This is a different problem, not a rename issue like the network one >> >> was. >> >> >> >>> [ 191.933548] Advanced Linux Sound Architecture Driver Version 1.0.15 >> >>> (Tue Oct 23 06:09:18 2007 UTC). >> >>> [ 191.996323] ALSA sound/core/seq/oss/seq_oss.c:232: can't register >> >>> device seq >> >>> [ 192.046004] sysfs: duplicate filename 'audio' can not be created >> >>> [ 192.086048] WARNING: at fs/sysfs/dir.c:424 sysfs_add_one() >> >> This is an error in the alsa core, perhaps the alsa developers can help >> >> figure out why they are registering the same file twice? >> > >> > ALSA core shouldn't do so. Maybe a built-in OSS driver conflict with >> > ALSA? We'd need to check .config, then. >> > >> > >> > Takashi >> > - >> Hi Takashi, >> >> Attaching the .config file, >> Hi Tobin, I Tried compiling the kernel with allyesconfig and with mtd devices disabled. When i tried booting into the kernel, i get this warning. -- Thanks & Regards, Kamalesh Babulal, Linux Technology Center, IBM, ISTL. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2/2] cpusets: add interleave_over_allowed option
David wrote: > If we can't identify any applications that would be broken by this, what's > the difference in simply implementing Choice B and then, if we hear > complaints, add your hack to revert back to Choice A behavior based on the > get_mempolicy() call you specified is always part of libnuma? I'll probably reply to other parts of your message later, but this one catches my eye right now. "if we hear complaints, add your hack ... back" -- this doesn't seem like a good idea to me. Maybe inside Google you don't see it, but for those of us shipping computer systems using major distributions such as SUSE or Red Hat, there can be a year lag between when I send a feature patch to Andrew, and when my customers send their first feedback to me resulting from using that new feature. There are ways to expedite fixes for specific situations, of course, but in general, this is rather like sending out a deep space probe. You have to conservatively cover your options pre-launch, because post-launch repairs are costly, slow and limited. -- 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: [PATCH 1/4] stringbuf: A string buffer implementation
On Monday 29 October 2007 14:03:52 Matt Mackall wrote:
> And on SLOB, which doesn't have those bloaty power-of-2 constraints?
> Looks like ~500 reallocs, including 25 bytes of memcpy. Ouch!
In other words, the system was compiled for size optimization and that's
what happened.
The question is: how bad is it? Let's look at those numbers for SLOB (32-bit
x86). First we find that it does 1000 reallocs to build the string, so it
really is worst case: we do a memcpy every time, so that's 500k of copying.
Yet SLOB comes in at 423 ns per call. Remember that the other allocators got
around 1491 ns? I went back and turned slub debugging off, and that number
hardly changed.
Deeper probing didn't show any convincing cause for the speedup. Perhaps
slob is recycling memory for this case far better than the others,
outweighing the overhead.
Here's the patch I'm using, analysis welcome.
Rusty.
===
diff --git a/drivers/lguest/core.c b/drivers/lguest/core.c
index cb4c670..a7b4033 100644
--- a/drivers/lguest/core.c
+++ b/drivers/lguest/core.c
@@ -239,6 +239,121 @@ int run_guest(struct lguest *lg, unsigned long __user
*user)
return -ENOENT;
}
+#include
+#include
+#include
+
+static inline void *realloc_no_copy(const void *p, size_t new_size, gfp_t
flags)
+{
+ void *ret;
+ size_t ks = 0;
+
+ if (unlikely(!new_size)) {
+ kfree(p);
+ return ZERO_SIZE_PTR;
+ }
+
+ if (p)
+ ks = ksize(p);
+
+ if (ks >= new_size)
+ return (void *)p;
+
+ ret = kmalloc_track_caller(new_size, flags);
+ if (ret)
+ kfree(p);
+ return ret;
+}
+
+static void test_stringbuf(void)
+{
+ unsigned int i, j;
+ ktime_t start, end;
+ unsigned int sb_alloc_count = 0;
+ char c[5];
+
+ start = ktime_get();
+ for (i = 0; i < 1000; i++) {
+ struct stringbuf *oldsb = NULL, *sb = NULL;
+
+ for (j = 0; j < 1000; j++) {
+ unsigned int k;
+ sb_printf_append(, GFP_KERNEL, "a");
+ sb_alloc_count += (sb != oldsb);
+ oldsb = sb;
+#if 0
+ if (sb->buf[j+1] != '\0') {
+ printk("Final sb->buf[%i] = %i\n",
+ j+1, sb->buf[j+1]);
+ break;
+ }
+ for (k = 0; k < j; k++) {
+ if (sb->buf[k] != 'a') {
+ printk("sb->buf[%i] = %i\n",
+ k, sb->buf[k]);
+ break;
+ }
+ }
+#endif
+ }
+ sb_free(sb);
+ }
+ end = ktime_get();
+
+ printk("1000 x 1000 sb_printf_append == %lli ns %u allocs\n",
+ ktime_to_ns(ktime_sub(end, start)), sb_alloc_count);
+
+ start = ktime_get();
+ for (i = 0; i < 1000; i++) {
+ struct stringbuf *oldsb = NULL, *sb = NULL;
+
+ for (j = 0; j < 1000; j++) {
+ sprintf(c, "a", );
+ sb_alloc_count += (sb != oldsb);
+ oldsb = sb;
+ }
+ sb_free(sb);
+ }
+ end = ktime_get();
+
+ printk("1000 x 1000 sprintf == %lli ns\n",
+ ktime_to_ns(ktime_sub(end, start)));
+
+ sb_alloc_count = 0;
+ start = ktime_get();
+ for (i = 0; i < 1000; i++) {
+ struct stringbuf *oldsb = NULL, *sb = NULL;
+
+ for (j = 0; j < 1000; j++) {
+ sb = realloc_no_copy(oldsb, j + 1, GFP_KERNEL);
+ sb_alloc_count += (sb != oldsb);
+ oldsb = sb;
+ }
+ kfree(sb);
+ }
+ end = ktime_get();
+
+ printk("1000 x 1000 realloc_no_copy == %lli ns %u allocs\n",
+ ktime_to_ns(ktime_sub(end, start)), sb_alloc_count);
+
+ sb_alloc_count = 0;
+ start = ktime_get();
+ for (i = 0; i < 1000; i++) {
+ struct stringbuf *oldsb = NULL, *sb = NULL;
+
+ for (j = 0; j < 1000; j++) {
+ sb = krealloc(oldsb, j + 1, GFP_KERNEL);
+ sb_alloc_count += (sb != oldsb);
+ oldsb = sb;
+ }
+ kfree(sb);
+ }
+ end = ktime_get();
+
+ printk("1000 x 1000 krealloc == %lli ns %u allocs\n",
+ ktime_to_ns(ktime_sub(end, start)), sb_alloc_count);
+}
+
/*H:000
* Welcome to the Host!
*
@@ -251,6 +366,8 @@ static int __init init(void)
{
int err;
+ test_stringbuf();
+
/* Lguest can't run under Xen, VMI or itself. It does Tricky Stuff. */
if (paravirt_enabled()) {
printk("lguest is afraid of %s\n",
[PATCH] Quieten hrtimer printk: "Switched to high resolution mode .."
Change the hrtimer printk "Switched to high resolution mode .." to be KERN_DEBUG, rather than KERN_INFO. If users need to see this they can pass "loglevel" or "debug" on the command line, or check dmesg. Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]> --- Any objections? It gets a little repetitive, eg: Switched to high resolution mode on CPU 0 Switched to high resolution mode on CPU 17 Switched to high resolution mode on CPU 10 Switched to high resolution mode on CPU 2 Switched to high resolution mode on CPU 7 Switched to high resolution mode on CPU 11 Switched to high resolution mode on CPU 3 Switched to high resolution mode on CPU 8 Switched to high resolution mode on CPU 12 Switched to high resolution mode on CPU 1 Switched to high resolution mode on CPU 4 Switched to high resolution mode on CPU 5 Switched to high resolution mode on CPU 13 Switched to high resolution mode on CPU 14 Switched to high resolution mode on CPU 15 Switched to high resolution mode on CPU 9 Switched to high resolution mode on CPU 6 Switched to high resolution mode on CPU 16 cheers kernel/hrtimer.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c index b6d2ff7..22a2514 100644 --- a/kernel/hrtimer.c +++ b/kernel/hrtimer.c @@ -602,7 +602,7 @@ static int hrtimer_switch_to_hres(void) /* "Retrigger" the interrupt to get things going */ retrigger_next_event(NULL); local_irq_restore(flags); - printk(KERN_INFO "Switched to high resolution mode on CPU %d\n", + printk(KERN_DEBUG "Switched to high resolution mode on CPU %d\n", smp_processor_id()); return 1; } -- 1.5.2.rc1.1884.g59b20 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Silence radeon_pm warning
On Mon, 29 Oct 2007 00:02:02 -0500 Olof Johansson <[EMAIL PROTECTED]> wrote: > > I posted this one a few days ago, without adding a new ifdef (just moving the > declaration down into the already existing ifdef below it): > > http://marc.info/?l=linux-kernel=119311699109698=2 Yeah, missed that and yours looks better. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpe4zbkBJP5K.pgp Description: PGP signature
Re: [2.6 patch] kprobe_exceptions_notify(): fix NULL dereference
On Sat, Oct 27, 2007 at 04:19:14PM +0200, Adrian Bunk wrote:
> This patch fixes later NULL dereferences spotted by the Coverity
> checker.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
NACK... see below
> ---
>
> BTW: The avr32 and s390 versions of kprobe_exceptions_notify() are
> not touched since they don't contain this check.
>
> arch/ia64/kernel/kprobes.c|2 +-
> arch/powerpc/kernel/kprobes.c |2 +-
> arch/sparc64/kernel/kprobes.c |2 +-
> arch/x86/kernel/kprobes_32.c |2 +-
> arch/x86/kernel/kprobes_64.c |2 +-
> 5 files changed, 5 insertions(+), 5 deletions(-)
>
> b6f1241ee20dd22210f48b4100bc5055315f3808
> diff --git a/arch/ia64/kernel/kprobes.c b/arch/ia64/kernel/kprobes.c
> index 5fd65d8..3663dfb 100644
> --- a/arch/ia64/kernel/kprobes.c
> +++ b/arch/ia64/kernel/kprobes.c
> @@ -886,11 +886,11 @@ int __kprobes kprobe_exceptions_notify(struct
> notifier_block *self,
> unsigned long val, void *data)
> {
> struct die_args *args = (struct die_args *)data;
> int ret = NOTIFY_DONE;
>
> - if (args->regs && user_mode(args->regs))
> + if (args->regs || user_mode(args->regs))
This change is incorrect as you return if args->regs != NULL leading to
a sure system crash.
Ananth
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [SCTP] endianness annotations regression
From: Al Viro <[EMAIL PROTECTED]> Date: Mon, 29 Oct 2007 05:03:23 + > > Signed-off-by: Al Viro <[EMAIL PROTECTED]> Acked-by: David S. Miller <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)
On Sun, 28 Oct 2007 15:08:56 -0700 Crispin Cowan <[EMAIL PROTECTED]> wrote: > To reject an LSM for providing "bad" security, IMHO you should have to > show how it is possible to subvert the self-stated goals of that LSM. > Complaints that the LSM fails to meet some goal outside of its stated > purpose is irrelevant. Conjecture that it probably can be violated > because of $contrivance is just so much FUD. exactly; this is why I've been pushing recently for each new LSM to at least document and make explicit what it tries to protect / protect against (threat model and defense model in traditional security terms). Without such an explicit description it's both impossible to "neutrally" review a proposed LSM towards its goals, and it ends up as a result with people making assumptions and attacking the model because there's no separation between code and model. > Exception: it is valid to say that the self-stated goal is too narrow > to be useful. But IMHO that bar of "too narrow" should be very, very > low. Defenses against specific modes of attack would be a fine thing > to build up in the library of LSMs, especially if we got a decent > stacking module so that they could be composed. again I agree pretty much; I do want to reserve some minimum "common sense" bar because people may (and probably will) do silly things withs LSMs that are really not the right thing to do objectively. -- If you want to reach me at my work email, use [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
arcmsr: endianness bug
initializing a field in data shared with the card with cpu_to_le32(something) | 0x10 is broken - the field is, indeed, little-endian and we need cpu_to_le32() on both parts. Signed-off-by: Al Viro <[EMAIL PROTECTED]> --- drivers/scsi/arcmsr/arcmsr_hba.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c index 152af46..acbc50f 100644 --- a/drivers/scsi/arcmsr/arcmsr_hba.c +++ b/drivers/scsi/arcmsr/arcmsr_hba.c @@ -932,7 +932,7 @@ static void arcmsr_build_ccb(struct AdapterControlBlock *acb, pdma_sg->addresshigh = address_hi; pdma_sg->address = address_lo; - pdma_sg->length = length|IS_SG64_ADDR; + pdma_sg->length = length|cpu_to_le32(IS_SG64_ADDR); psge += sizeof (struct SG64ENTRY); arccdbsize += sizeof (struct SG64ENTRY); } -- 1.5.3.GIT - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
fix reentrancy bug in arcmsr_get_iop_{r,w}qbuffer()
doh...
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
drivers/scsi/arcmsr/arcmsr_hba.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
index acbc50f..d466a2d 100644
--- a/drivers/scsi/arcmsr/arcmsr_hba.c
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c
@@ -1095,7 +1095,7 @@ static void arcmsr_iop_message_wrote(struct
AdapterControlBlock *acb)
struct QBUFFER __iomem *arcmsr_get_iop_rqbuffer(struct AdapterControlBlock
*acb)
{
- static struct QBUFFER __iomem *qbuffer;
+ struct QBUFFER __iomem *qbuffer = NULL;
switch (acb->adapter_type) {
@@ -1116,7 +1116,7 @@ struct QBUFFER __iomem *arcmsr_get_iop_rqbuffer(struct
AdapterControlBlock *acb)
static struct QBUFFER __iomem *arcmsr_get_iop_wqbuffer(struct
AdapterControlBlock *acb)
{
- static struct QBUFFER __iomem *pqbuffer;
+ struct QBUFFER __iomem *pqbuffer = NULL;
switch (acb->adapter_type) {
--
1.5.3.GIT
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] fix abuses of ptrdiff_t
Use of ptrdiff_t in places like
- if (!access_ok(VERIFY_WRITE, u_tmp->rx_buf, u_tmp->len))
+ if (!access_ok(VERIFY_WRITE, (u8 __user *)
+ (ptrdiff_t) u_tmp->rx_buf,
+ u_tmp->len))
is wrong; for one thing, it's a bad C (it's what uintptr_t is for; in general
we are not even promised that ptrdiff_t is large enough to hold a pointer,
just enough to hold a difference between two pointers within the same object).
For another, it confuses the fsck out of sparse.
Use unsigned long or uintptr_t instead. There are several places misusing
ptrdiff_t; fixed.
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
drivers/scsi/aacraid/commctrl.c | 12 ++--
drivers/scsi/aacraid/comminit.c |2 +-
drivers/scsi/aacraid/dpcsup.c |2 +-
drivers/spi/spidev.c|6 +++---
include/linux/types.h |2 ++
5 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/scsi/aacraid/commctrl.c b/drivers/scsi/aacraid/commctrl.c
index 72b0393..1e6d7a9 100644
--- a/drivers/scsi/aacraid/commctrl.c
+++ b/drivers/scsi/aacraid/commctrl.c
@@ -391,7 +391,7 @@ static int close_getadapter_fib(struct aac_dev * dev, void
__user *arg)
/*
* Extract the fibctx from the input parameters
*/
- if (fibctx->unique == (u32)(ptrdiff_t)arg) /* We found a winner
*/
+ if (fibctx->unique == (u32)(uintptr_t)arg) /* We found a winner
*/
break;
entry = entry->next;
fibctx = NULL;
@@ -590,7 +590,7 @@ static int aac_send_raw_srb(struct aac_dev* dev, void
__user * arg)
}
addr = (u64)upsg->sg[i].addr[0];
addr += ((u64)upsg->sg[i].addr[1]) << 32;
- sg_user[i] = (void __user *)(ptrdiff_t)addr;
+ sg_user[i] = (void __user *)(uintptr_t)addr;
sg_list[i] = p; // save so we can clean up later
sg_indx = i;
@@ -633,7 +633,7 @@ static int aac_send_raw_srb(struct aac_dev* dev, void
__user * arg)
rcode = -ENOMEM;
goto cleanup;
}
- sg_user[i] = (void __user
*)(ptrdiff_t)usg->sg[i].addr;
+ sg_user[i] = (void __user
*)(uintptr_t)usg->sg[i].addr;
sg_list[i] = p; // save so we can clean up later
sg_indx = i;
@@ -664,7 +664,7 @@ static int aac_send_raw_srb(struct aac_dev* dev, void
__user * arg)
if (actual_fibsize64 == fibsize) {
struct user_sgmap64* usg = (struct user_sgmap64 *)upsg;
for (i = 0; i < upsg->count; i++) {
- u64 addr;
+ uintptr_t addr;
void* p;
/* Does this really need to be GFP_DMA? */
p =
kmalloc(usg->sg[i].count,GFP_KERNEL|__GFP_DMA);
@@ -676,7 +676,7 @@ static int aac_send_raw_srb(struct aac_dev* dev, void
__user * arg)
}
addr = (u64)usg->sg[i].addr[0];
addr += ((u64)usg->sg[i].addr[1]) << 32;
- sg_user[i] = (void __user *)(ptrdiff_t)addr;
+ sg_user[i] = (void __user *)addr;
sg_list[i] = p; // save so we can clean up later
sg_indx = i;
@@ -704,7 +704,7 @@ static int aac_send_raw_srb(struct aac_dev* dev, void
__user * arg)
rcode = -ENOMEM;
goto cleanup;
}
- sg_user[i] = (void __user
*)(ptrdiff_t)upsg->sg[i].addr;
+ sg_user[i] = (void __user
*)(uintptr_t)upsg->sg[i].addr;
sg_list[i] = p; // save so we can clean up later
sg_indx = i;
diff --git a/drivers/scsi/aacraid/comminit.c b/drivers/scsi/aacraid/comminit.c
index 3009ad8..8736813 100644
--- a/drivers/scsi/aacraid/comminit.c
+++ b/drivers/scsi/aacraid/comminit.c
@@ -110,7 +110,7 @@ static int aac_alloc_comm(struct aac_dev *dev, void
**commaddr, unsigned long co
/*
* Align the beginning of Headers to commalign
*/
- align = (commalign - ((ptrdiff_t)(base) & (commalign - 1)));
+ align = (commalign - ((uintptr_t)(base) & (commalign - 1)));
base = base + align;
phys = phys + align;
/*
diff --git
deal with resource allocation bugs in arcmsr
a) for type B we should _not_ iounmap() acb->pmu; it's not ioremapped.
b) for type B we should iounmap() two regions we _do_ ioremap.
c) if ioremap() fails, we need to bail out (and clean up).
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
drivers/scsi/arcmsr/arcmsr.h |9 -
drivers/scsi/arcmsr/arcmsr_hba.c | 33 ++---
2 files changed, 30 insertions(+), 12 deletions(-)
diff --git a/drivers/scsi/arcmsr/arcmsr.h b/drivers/scsi/arcmsr/arcmsr.h
index 3c38cd8..a67e29f 100644
--- a/drivers/scsi/arcmsr/arcmsr.h
+++ b/drivers/scsi/arcmsr/arcmsr.h
@@ -348,14 +348,6 @@ struct MessageUnit_B
uint32_t__iomem *ioctl_rbuffer_reg;
};
-struct MessageUnit
-{
- union
- {
- struct MessageUnit_Apmu_A;
- struct MessageUnit_Bpmu_B;
- } u;
-};
/*
***
** Adapter Control Block
@@ -375,7 +367,6 @@ struct AdapterControlBlock
uint32_toutbound_int_enable;
union {
- struct MessageUnit *pmu;
struct MessageUnit_A __iomem * pmuA;
struct MessageUnit_B * pmuB;
};
diff --git a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
index aaee028..152af46 100644
--- a/drivers/scsi/arcmsr/arcmsr_hba.c
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c
@@ -240,14 +240,18 @@ static int arcmsr_alloc_ccb_pool(struct
AdapterControlBlock *acb)
if (!acb->pmuA) {
printk(KERN_NOTICE "arcmsr%d: memory mapping region
fail \n",
acb->host->host_no);
+ return -ENOMEM;
}
dma_coherent = dma_alloc_coherent(>dev,
ARCMSR_MAX_FREECCB_NUM *
sizeof (struct CommandControlBlock) + 0x20,
_coherent_handle, GFP_KERNEL);
- if (!dma_coherent)
+
+ if (!dma_coherent) {
+ iounmap(acb->pmuA);
return -ENOMEM;
+ }
acb->dma_coherent = dma_coherent;
acb->dma_coherent_handle = dma_coherent_handle;
@@ -331,8 +335,16 @@ static int arcmsr_alloc_ccb_pool(struct
AdapterControlBlock *acb)
acb->pmuB = reg;
mem_base0 = ioremap(pci_resource_start(pdev, 0),
pci_resource_len(pdev, 0));
+ if (!mem_base0)
+ goto out;
+
mem_base1 = ioremap(pci_resource_start(pdev, 2),
pci_resource_len(pdev, 2));
+ if (!mem_base1) {
+ iounmap(mem_base0);
+ goto out;
+ }
+
reg->drv2iop_doorbell_reg = mem_base0 + ARCMSR_DRV2IOP_DOORBELL;
reg->drv2iop_doorbell_mask_reg = mem_base0 +
ARCMSR_DRV2IOP_DOORBELL_MASK;
@@ -357,6 +369,12 @@ static int arcmsr_alloc_ccb_pool(struct
AdapterControlBlock *acb)
break;
}
return 0;
+
+out:
+ dma_free_coherent(>pdev->dev,
+ ARCMSR_MAX_FREECCB_NUM * sizeof(struct CommandControlBlock) +
0x20,
+ acb->dma_coherent, acb->dma_coherent_handle);
+ return -ENOMEM;
}
static int arcmsr_probe(struct pci_dev *pdev,
@@ -449,7 +467,6 @@ static int arcmsr_probe(struct pci_dev *pdev,
free_irq(pdev->irq, acb);
out_free_ccb_pool:
arcmsr_free_ccb_pool(acb);
- iounmap(acb->pmu);
out_release_regions:
pci_release_regions(pdev);
out_host_put:
@@ -810,7 +827,6 @@ static void arcmsr_remove(struct pci_dev *pdev)
}
free_irq(pdev->irq, acb);
- iounmap(acb->pmu);
arcmsr_free_ccb_pool(acb);
pci_release_regions(pdev);
@@ -1018,6 +1034,17 @@ static void arcmsr_stop_adapter_bgrb(struct
AdapterControlBlock *acb)
static void arcmsr_free_ccb_pool(struct AdapterControlBlock *acb)
{
+ switch (acb->adapter_type) {
+ case ACB_ADAPTER_TYPE_A: {
+ iounmap(acb->pmuA);
+ break;
+ }
+ case ACB_ADAPTER_TYPE_B: {
+ struct MessageUnit_B *reg = acb->pmuB;
+ iounmap(reg->drv2iop_doorbell_reg - ARCMSR_DRV2IOP_DOORBELL);
+ iounmap(reg->ioctl_wbuffer_reg - ARCMSR_IOCTL_WBUFFER);
+ }
+ }
dma_free_coherent(>pdev->dev,
ARCMSR_MAX_FREECCB_NUM * sizeof (struct CommandControlBlock) +
0x20,
acb->dma_coherent,
--
1.5.3.GIT
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
trivial annotations in arcmsr
driver still has serious portability problems
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
drivers/scsi/arcmsr/arcmsr.h | 32 ---
drivers/scsi/arcmsr/arcmsr_attr.c |6 +-
drivers/scsi/arcmsr/arcmsr_hba.c | 170 ++---
3 files changed, 103 insertions(+), 105 deletions(-)
diff --git a/drivers/scsi/arcmsr/arcmsr.h b/drivers/scsi/arcmsr/arcmsr.h
index ace7a15..3c38cd8 100644
--- a/drivers/scsi/arcmsr/arcmsr.h
+++ b/drivers/scsi/arcmsr/arcmsr.h
@@ -141,14 +141,14 @@ struct CMD_MESSAGE_FIELD
#define IS_SG64_ADDR0x0100 /* bit24 */
struct SG32ENTRY
{
- uint32_tlength;
- uint32_taddress;
+ __le32 length;
+ __le32 address;
};
struct SG64ENTRY
{
- uint32_tlength;
- uint32_taddress;
- uint32_taddresshigh;
+ __le32 length;
+ __le32 address;
+ __le32 addresshigh;
};
struct SGENTRY_UNION
{
@@ -339,13 +339,13 @@ struct MessageUnit_B
uint32_tdone_qbuffer[ARCMSR_MAX_HBB_POSTQUEUE];
uint32_tpostq_index;
uint32_tdoneq_index;
- uint32_t*drv2iop_doorbell_reg;
- uint32_t*drv2iop_doorbell_mask_reg;
- uint32_t*iop2drv_doorbell_reg;
- uint32_t*iop2drv_doorbell_mask_reg;
- uint32_t*msgcode_rwbuffer_reg;
- uint32_t*ioctl_wbuffer_reg;
- uint32_t*ioctl_rbuffer_reg;
+ uint32_t__iomem *drv2iop_doorbell_reg;
+ uint32_t__iomem *drv2iop_doorbell_mask_reg;
+ uint32_t__iomem *iop2drv_doorbell_reg;
+ uint32_t__iomem *iop2drv_doorbell_mask_reg;
+ uint32_t__iomem *msgcode_rwbuffer_reg;
+ uint32_t__iomem *ioctl_wbuffer_reg;
+ uint32_t__iomem *ioctl_rbuffer_reg;
};
struct MessageUnit
@@ -374,7 +374,11 @@ struct AdapterControlBlock
/* Offset is used in making arc cdb physical to virtual calculations */
uint32_toutbound_int_enable;
- struct MessageUnit *pmu;
+ union {
+ struct MessageUnit *pmu;
+ struct MessageUnit_A __iomem * pmuA;
+ struct MessageUnit_B * pmuB;
+ };
/* message unit ATU inbound base address0 */
uint32_tacb_flags;
@@ -558,7 +562,7 @@ struct SENSE_DATA
extern void arcmsr_post_ioctldata2iop(struct AdapterControlBlock *);
extern void arcmsr_iop_message_read(struct AdapterControlBlock *);
-extern struct QBUFFER *arcmsr_get_iop_rqbuffer(struct AdapterControlBlock *);
+extern struct QBUFFER __iomem *arcmsr_get_iop_rqbuffer(struct
AdapterControlBlock *);
extern struct class_device_attribute *arcmsr_host_attrs[];
extern int arcmsr_alloc_sysfs_attr(struct AdapterControlBlock *);
void arcmsr_free_sysfs_attr(struct AdapterControlBlock *acb);
diff --git a/drivers/scsi/arcmsr/arcmsr_attr.c
b/drivers/scsi/arcmsr/arcmsr_attr.c
index d04d1aa..7d7b0a5 100644
--- a/drivers/scsi/arcmsr/arcmsr_attr.c
+++ b/drivers/scsi/arcmsr/arcmsr_attr.c
@@ -85,13 +85,13 @@ static ssize_t arcmsr_sysfs_iop_message_read(struct kobject
*kobj,
allxfer_len++;
}
if (acb->acb_flags & ACB_F_IOPDATA_OVERFLOW) {
- struct QBUFFER *prbuffer;
- uint8_t *iop_data;
+ struct QBUFFER __iomem *prbuffer;
+ uint8_t __iomem *iop_data;
int32_t iop_len;
acb->acb_flags &= ~ACB_F_IOPDATA_OVERFLOW;
prbuffer = arcmsr_get_iop_rqbuffer(acb);
- iop_data = (uint8_t *)prbuffer->data;
+ iop_data = prbuffer->data;
iop_len = readl(>data_len);
while (iop_len > 0) {
acb->rqbuffer[acb->rqbuf_lastindex] = readb(iop_data);
diff --git a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
index f7a2528..aaee028 100644
--- a/drivers/scsi/arcmsr/arcmsr_hba.c
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c
@@ -236,8 +236,8 @@ static int arcmsr_alloc_ccb_pool(struct AdapterControlBlock
*acb)
uint32_t intmask_org;
int i, j;
- acb->pmu = ioremap(pci_resource_start(pdev, 0),
pci_resource_len(pdev, 0));
- if (!acb->pmu) {
+ acb->pmuA = ioremap(pci_resource_start(pdev, 0),
pci_resource_len(pdev, 0));
+ if (!acb->pmuA) {
printk(KERN_NOTICE "arcmsr%d: memory mapping region
fail \n",
[PATCH] [SCTP] endianness annotations regression
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
include/net/sctp/auth.h |2 +-
net/sctp/auth.c |4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/net/sctp/auth.h b/include/net/sctp/auth.h
index 9e8f13b..5db261a 100644
--- a/include/net/sctp/auth.h
+++ b/include/net/sctp/auth.h
@@ -103,7 +103,7 @@ struct sctp_hmac *sctp_auth_asoc_get_hmac(const struct
sctp_association *asoc);
void sctp_auth_asoc_set_default_hmac(struct sctp_association *asoc,
struct sctp_hmac_algo_param *hmacs);
int sctp_auth_asoc_verify_hmac_id(const struct sctp_association *asoc,
- __u16 hmac_id);
+ __be16 hmac_id);
int sctp_auth_send_cid(sctp_cid_t chunk, const struct sctp_association *asoc);
int sctp_auth_recv_cid(sctp_cid_t chunk, const struct sctp_association *asoc);
void sctp_auth_calculate_hmac(const struct sctp_association *asoc,
diff --git a/net/sctp/auth.c b/net/sctp/auth.c
index 8af1004..6d5fa6b 100644
--- a/net/sctp/auth.c
+++ b/net/sctp/auth.c
@@ -556,7 +556,7 @@ struct sctp_hmac *sctp_auth_asoc_get_hmac(const struct
sctp_association *asoc)
return _hmac_list[id];
}
-static int __sctp_auth_find_hmacid(__u16 *hmacs, int n_elts, __u16 hmac_id)
+static int __sctp_auth_find_hmacid(__be16 *hmacs, int n_elts, __be16 hmac_id)
{
int found = 0;
int i;
@@ -573,7 +573,7 @@ static int __sctp_auth_find_hmacid(__u16 *hmacs, int
n_elts, __u16 hmac_id)
/* See if the HMAC_ID is one that we claim as supported */
int sctp_auth_asoc_verify_hmac_id(const struct sctp_association *asoc,
- __u16 hmac_id)
+ __be16 hmac_id)
{
struct sctp_hmac_algo_param *hmacs;
__u16 n_elt;
--
1.5.3.GIT
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Silence radeon_pm warning
On Mon, Oct 29, 2007 at 01:59:11PM +1100, Stephen Rothwell wrote: > drivers/video/aty/radeon_pm.c:30: warning: 'radeon_reinitialize_M10' declared > 'static' but never defined > > Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]> I posted this one a few days ago, without adding a new ifdef (just moving the declaration down into the already existing ifdef below it): http://marc.info/?l=linux-kernel=119311699109698=2 -Olof - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] intel-iommu fixes
* off by one in dmar_get_fault_reason() (maximal index in
array is ARRAY_SIZE()-1, not ARRAY_SIZE())
* NULL noise removal
* __iomem annotation fix
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
diff --git a/drivers/pci/intel-iommu.c b/drivers/pci/intel-iommu.c
index 0c4ab3b..9b35259 100644
--- a/drivers/pci/intel-iommu.c
+++ b/drivers/pci/intel-iommu.c
@@ -745,7 +745,7 @@ static char *fault_reason_strings[] =
"non-zero reserved fields in PTE",
"Unknown"
};
-#define MAX_FAULT_REASON_IDX ARRAY_SIZE(fault_reason_strings)
+#define MAX_FAULT_REASON_IDX ARRAY_SIZE(fault_reason_strings) - 1
char *dmar_get_fault_reason(u8 fault_reason)
{
@@ -995,7 +995,6 @@ static struct intel_iommu *alloc_iommu(struct
dmar_drhd_unit *drhd)
return iommu;
error_unmap:
iounmap(iommu->reg);
- iommu->reg = 0;
error:
kfree(iommu);
return NULL;
@@ -1808,7 +1807,7 @@ get_valid_domain_for_dev(struct pci_dev *pdev)
if (!domain) {
printk(KERN_ERR
"Allocating domain for %s failed", pci_name(pdev));
- return 0;
+ return NULL;
}
/* make sure context mapping is ok */
@@ -1818,7 +1817,7 @@ get_valid_domain_for_dev(struct pci_dev *pdev)
printk(KERN_ERR
"Domain context map for %s failed",
pci_name(pdev));
- return 0;
+ return NULL;
}
}
diff --git a/drivers/pci/intel-iommu.h b/drivers/pci/intel-iommu.h
index ee88dd2..459ad1f 100644
--- a/drivers/pci/intel-iommu.h
+++ b/drivers/pci/intel-iommu.h
@@ -58,7 +58,7 @@
hi = readl(dmar + reg + 4); \
(((u64) hi) << 32) + lo; })
*/
-static inline u64 dmar_readq(void *addr)
+static inline u64 dmar_readq(void __iomem *addr)
{
u32 lo, hi;
lo = readl(addr);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] [SUNRPC] endianness annotations
From: Al Viro <[EMAIL PROTECTED]> Date: Mon, 29 Oct 2007 04:37:58 + > rpcrdma stuff lacks endianness annotations for on-the-wire data. > > Signed-off-by: Al Viro <[EMAIL PROTECTED]> Acked-by: David S. Miller <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2/2] cpusets: add interleave_over_allowed option
On Sun, 28 Oct 2007, Paul Jackson wrote:
> And, unless someone in the know tells us otherwise, I have to assume
> that this could break them. Now, the odds are that they simply don't
> run that solution stack on any system making active use of cpusets,
> so the odds are this would be no problem for them. But I don't
> presently have enough knowledge of their situation to take that risk.
>
If we can't identify any applications that would be broken by this, what's
the difference in simply implementing Choice B and then, if we hear
complaints, add your hack to revert back to Choice A behavior based on the
get_mempolicy() call you specified is always part of libnuma?
The problem that I see with immediately offering both choices is that we
don't know if anybody is actually reverting back to Choice A behavior
because libnuma, by default, would use it. That's going to making it very
painful to remove later because we've supported both options and have made
libnuma and {get,set}_mempolicy() arguments ambiguous. We should only
support both choices if they will both be used and there's no hard
evidence to suggest that at this point.
> But dual support is pretty easy so far as the kernel code is concerned.
> It's just a few nodes_remap() calls optionally invoked at a few key
> spots in mm/mempolicy.c. Consequently there won't be a big hurry to
> remove Choice A.
>
You earlier insisted on an ease of documentation for the MPOL_INTERLEAVE
case and now this dual support that you're proposing is going to make the
documentation very difficult to understand for anyone who simply wants to
use mempolicies.
Others even in this thread have had a hard enough time understanding the
difference between the two choices and you explained them very thoroughly.
It's going to be much more trouble than it's worth, I predict.
> There is no "_then_ attach the task to a cpuset." On systems with
> kernels configured with CONFIG_CPUSETS=y, all tasks are in a cpuset
> all the time. Moreover, from a practical point of view, on large
> systems managed with cpuset based mechanisms, almost all tasks are in
> cpusets that do not include all nodes, for the entire life of the task.
>
And that application would need to be implemented to know the nodes that
it has access to before it issues its set_mempolicy(MPOL_PREFERRED)
command anyway if it truly uses Choice A behavior. So unless these tasks
are looking in /proc/pid/status and parsing Mems_allowed and then
specifying one as its preferred node or always being guaranteed a certain
set of nodes that they are always attached to in a cpuset so they have
such foresight of what node to prefer, Choice A can't possibly be what
they want.
> > Yet the 'mems' file would still be system-wide; otherwise it would be
> > impossible to expand the memory your cpuset has access to.
>
> I had to read that a couple of times to make sense of it. I take that
> it means that the node numbering used in each cpuset's 'mems' file has
> to be system-wide. Yes, agreed.
>
> (Well, actually, the node numbering of each cpusets 'mems' file could
> be relative to its parent cpusets 'mem' numbers, but let's not go
> there, as this discussion is already sufficiently complicated ;)
>
I appreciate that very much.
> Would it meet the need that prompted your initial patch set if we
> added Choice B memory policy node numbering, but left Choice A as the
> kernel default, with a per-task option (perhaps invokable by a new
> option to one of the {get,set}_mempolicy() calls) to choose Choice B?
>
The needs I was addressing with my initial patchset was so that when a
cpuset is expanded, any MPOL_INTERLEAVE memory policy of attached tasks
automatically get expanded as well. This discussion has somewhat diverged
from that, but I hope you still support what we earlier talked about in
terms of adding a field to struct mempolicy to remember the intended
nodemask the application asked to interleave over.
> This lets us get Choice B out there, and lets the two main libraries,
> libnuma and libcpuset, dynamically adapt to whichever Choice is active
> for the current task.
>
> Unchanged applications and existing binaries would simply continue with
> Choice A. With one additional line of code, a user application could
> get Choice B, with its ability for example to request MPOL_INTERLEAVE
> over all cpuset allowed nodes, where the kernel automatically adapts
> that to changing cpuset changes from larger 'mems' to smaller 'mems'
> and back to larger 'mems' again.
>
You don't actually need to choose between the two choices for adapting
MPOL_INTERLEAVE over _all_ allowed cpuset nodes.
I thought what we agreed upon and what you were going to implement was
adding a nodemask_t to struct mempolicy for the intended nodemask of the
memory policy and then AND it with pol->cpuset_mems_allowed. That
completely satisfies my needs and my applications that want to allocate
over all available nodes
Re: [PATCH] slub: nr_slabs is an atomic_long_t
On Mon, Oct 29, 2007 at 02:24:30PM +1100, Stephen Rothwell wrote: > On Sun, 28 Oct 2007 19:53:55 -0700 (PDT) Christoph Lameter <[EMAIL > PROTECTED]> wrote: > > > > That was already fixed AFAICT. > > Not in Linus' tree, yet. Nope, it's still sitting in -mm. Al Viro just posted the same fix too. -Olof - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] missing atomic_read_long() in slub.c
nr_slabs is atomic_long_t, not atomic_t Signed-off-by: Al Viro <[EMAIL PROTECTED]> --- diff --git a/mm/slub.c b/mm/slub.c index aac1dd3..bcdb2c8 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -2734,7 +2734,7 @@ static void slab_mem_offline_callback(void *arg) * and offline_pages() function shoudn't call this * callback. So, we must fail. */ - BUG_ON(atomic_read(>nr_slabs)); + BUG_ON(atomic_long_read(>nr_slabs)); s->node[offline_node] = NULL; kmem_cache_free(kmalloc_caches, n); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] [SUNRPC] endianness annotations
rpcrdma stuff lacks endianness annotations for on-the-wire data.
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
diff --git a/include/linux/sunrpc/rpc_rdma.h b/include/linux/sunrpc/rpc_rdma.h
index 0013a0d..87b895d 100644
--- a/include/linux/sunrpc/rpc_rdma.h
+++ b/include/linux/sunrpc/rpc_rdma.h
@@ -41,17 +41,17 @@
#define _LINUX_SUNRPC_RPC_RDMA_H
struct rpcrdma_segment {
- uint32_t rs_handle; /* Registered memory handle */
- uint32_t rs_length; /* Length of the chunk in bytes */
- uint64_t rs_offset; /* Chunk virtual address or offset */
+ __be32 rs_handle; /* Registered memory handle */
+ __be32 rs_length; /* Length of the chunk in bytes */
+ __be64 rs_offset; /* Chunk virtual address or offset */
};
/*
* read chunk(s), encoded as a linked list.
*/
struct rpcrdma_read_chunk {
- uint32_t rc_discrim;/* 1 indicates presence */
- uint32_t rc_position; /* Position in XDR stream */
+ __be32 rc_discrim; /* 1 indicates presence */
+ __be32 rc_position; /* Position in XDR stream */
struct rpcrdma_segment rc_target;
};
@@ -66,29 +66,29 @@ struct rpcrdma_write_chunk {
* write chunk(s), encoded as a counted array.
*/
struct rpcrdma_write_array {
- uint32_t wc_discrim;/* 1 indicates presence */
- uint32_t wc_nchunks;/* Array count */
+ __be32 wc_discrim; /* 1 indicates presence */
+ __be32 wc_nchunks; /* Array count */
struct rpcrdma_write_chunk wc_array[0];
};
struct rpcrdma_msg {
- uint32_t rm_xid;/* Mirrors the RPC header xid */
- uint32_t rm_vers; /* Version of this protocol */
- uint32_t rm_credit; /* Buffers requested/granted */
- uint32_t rm_type; /* Type of message (enum rpcrdma_proc) */
+ __be32 rm_xid; /* Mirrors the RPC header xid */
+ __be32 rm_vers; /* Version of this protocol */
+ __be32 rm_credit; /* Buffers requested/granted */
+ __be32 rm_type; /* Type of message (enum rpcrdma_proc) */
union {
struct {/* no chunks */
- uint32_t rm_empty[3]; /* 3 empty chunk lists */
+ __be32 rm_empty[3]; /* 3 empty chunk lists */
} rm_nochunks;
struct {/* no chunks and padded */
- uint32_t rm_align; /* Padding alignment */
- uint32_t rm_thresh; /* Padding threshold */
- uint32_t rm_pempty[3]; /* 3 empty chunk lists */
+ __be32 rm_align;/* Padding alignment */
+ __be32 rm_thresh; /* Padding threshold */
+ __be32 rm_pempty[3];/* 3 empty chunk lists */
} rm_padded;
- uint32_t rm_chunks[0]; /* read, write and reply chunks */
+ __be32 rm_chunks[0];/* read, write and reply chunks */
} rm_body;
};
diff --git a/net/sunrpc/xprtrdma/rpc_rdma.c b/net/sunrpc/xprtrdma/rpc_rdma.c
index 12db635..f877b88 100644
--- a/net/sunrpc/xprtrdma/rpc_rdma.c
+++ b/net/sunrpc/xprtrdma/rpc_rdma.c
@@ -181,7 +181,7 @@ rpcrdma_create_chunks(struct rpc_rqst *rqst, struct xdr_buf
*target,
struct rpcrdma_read_chunk *cur_rchunk = NULL;
struct rpcrdma_write_array *warray = NULL;
struct rpcrdma_write_chunk *cur_wchunk = NULL;
- u32 *iptr = headerp->rm_body.rm_chunks;
+ __be32 *iptr = headerp->rm_body.rm_chunks;
if (type == rpcrdma_readch || type == rpcrdma_areadch) {
/* a read chunk - server will RDMA Read our memory */
@@ -217,7 +217,7 @@ rpcrdma_create_chunks(struct rpc_rqst *rqst, struct xdr_buf
*target,
cur_rchunk->rc_target.rs_handle = htonl(seg->mr_rkey);
cur_rchunk->rc_target.rs_length = htonl(seg->mr_len);
xdr_encode_hyper(
- (u32 *)_rchunk->rc_target.rs_offset,
+ (__be32
*)_rchunk->rc_target.rs_offset,
seg->mr_base);
dprintk("RPC: %s: read chunk "
"elem [EMAIL PROTECTED]:0x%x pos %d (%s)\n",
__func__,
@@ -229,7 +229,7 @@ rpcrdma_create_chunks(struct rpc_rqst *rqst, struct xdr_buf
*target,
cur_wchunk->wc_target.rs_handle = htonl(seg->mr_rkey);
cur_wchunk->wc_target.rs_length = htonl(seg->mr_len);
xdr_encode_hyper(
- (u32 *)_wchunk->wc_target.rs_offset,
+ (__be32
*)_wchunk->wc_target.rs_offset,
seg->mr_base);
dprintk("RPC: %s: %s chunk "
"elem [EMAIL
Re: [REGRESSION] 2.6.24-rc1 fails to boot on a 486
Mikael Pettersson wrote: My old 486 fails to boot with the 2.6.24-rc1 kernel. Grub loads it, 4 lines of text appear but not the kernel's "Linux version greet", and the machine reboots. Double-checked with a serial console: nothing appears before it reboots. All 2.6 kernels up to 2.6.23 worked fine on this machine. Config is at http://user.it.uu.se/~mikpe/linux/tmp/486-config-2.6.24-rc1. The kernel is unpatched 2.6.24-rc1 compiled with gcc-4.2.2. Any chance you could bisect this problem? -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [REGRESSION] 2.6.24-rc1 fails to boot on a 486
Mikael Pettersson wrote: My old 486 fails to boot with the 2.6.24-rc1 kernel. Grub loads it, 4 lines of text appear but not the kernel's "Linux version greet", and the machine reboots. Double-checked with a serial console: nothing appears before it reboots. What four lines of text? -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] misc uml annotation and section fixes
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
diff --git a/arch/um/kernel/mem.c b/arch/um/kernel/mem.c
index 8456397..59822de 100644
--- a/arch/um/kernel/mem.c
+++ b/arch/um/kernel/mem.c
@@ -165,7 +165,7 @@ static void __init kmap_init(void)
kmap_prot = PAGE_KERNEL;
}
-static void init_highmem(void)
+static void __init init_highmem(void)
{
pgd_t *pgd;
pud_t *pud;
diff --git a/arch/um/sys-i386/ptrace.c b/arch/um/sys-i386/ptrace.c
index 9657c89..bd3da8a 100644
--- a/arch/um/sys-i386/ptrace.c
+++ b/arch/um/sys-i386/ptrace.c
@@ -155,7 +155,7 @@ int get_fpregs(struct user_i387_struct __user *buf, struct
task_struct *child)
if (err)
return err;
- n = copy_to_user((void *) buf, fpregs, sizeof(fpregs));
+ n = copy_to_user(buf, fpregs, sizeof(fpregs));
if(n > 0)
return -EFAULT;
@@ -168,7 +168,7 @@ int set_fpregs(struct user_i387_struct __user *buf, struct
task_struct *child)
long fpregs[HOST_FP_SIZE];
BUG_ON(sizeof(*buf) != sizeof(fpregs));
- n = copy_from_user(fpregs, (void *) buf, sizeof(fpregs));
+ n = copy_from_user(fpregs, buf, sizeof(fpregs));
if (n > 0)
return -EFAULT;
@@ -185,7 +185,7 @@ int get_fpxregs(struct user_fxsr_struct __user *buf, struct
task_struct *child)
if (err)
return err;
- n = copy_to_user((void *) buf, fpregs, sizeof(fpregs));
+ n = copy_to_user(buf, fpregs, sizeof(fpregs));
if(n > 0)
return -EFAULT;
@@ -198,7 +198,7 @@ int set_fpxregs(struct user_fxsr_struct __user *buf, struct
task_struct *child)
long fpregs[HOST_XFP_SIZE];
BUG_ON(sizeof(*buf) != sizeof(fpregs));
- n = copy_from_user(fpregs, (void *) buf, sizeof(fpregs));
+ n = copy_from_user(fpregs, buf, sizeof(fpregs));
if (n > 0)
return -EFAULT;
diff --git a/arch/um/sys-x86_64/ptrace.c b/arch/um/sys-x86_64/ptrace.c
index a3cfeed..b7631b0 100644
--- a/arch/um/sys-x86_64/ptrace.c
+++ b/arch/um/sys-x86_64/ptrace.c
@@ -154,7 +154,7 @@ int get_fpregs(struct user_i387_struct __user *buf, struct
task_struct *child)
if (err)
return err;
- n = copy_to_user((void *) buf, fpregs, sizeof(fpregs));
+ n = copy_to_user(buf, fpregs, sizeof(fpregs));
if(n > 0)
return -EFAULT;
@@ -167,7 +167,7 @@ int set_fpregs(struct user_i387_struct __user *buf, struct
task_struct *child)
long fpregs[HOST_FP_SIZE];
BUG_ON(sizeof(*buf) != sizeof(fpregs));
- n = copy_from_user(fpregs, (void *) buf, sizeof(fpregs));
+ n = copy_from_user(fpregs, buf, sizeof(fpregs));
if (n > 0)
return -EFAULT;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] more x86 merge fallout (uml, again)
arch/i386/{Kconfig,Makefile}.cpu got moved
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
diff --git a/arch/um/Kconfig.i386 b/arch/um/Kconfig.i386
index 9876d80..e0ac74e 100644
--- a/arch/um/Kconfig.i386
+++ b/arch/um/Kconfig.i386
@@ -1,6 +1,6 @@
menu "Host processor type and features"
-source "arch/i386/Kconfig.cpu"
+source "arch/x86/Kconfig.cpu"
endmenu
diff --git a/arch/um/Makefile-i386 b/arch/um/Makefile-i386
index 08433f8..b01dfb0 100644
--- a/arch/um/Makefile-i386
+++ b/arch/um/Makefile-i386
@@ -28,7 +28,7 @@ CONFIG_X86_32 := y
export CONFIG_X86_32
# First of all, tune CFLAGS for the specific CPU. This actually sets cflags-y.
-include $(srctree)/arch/i386/Makefile.cpu
+include $(srctree)/arch/x86/Makefile_32.cpu
# prevent gcc from keeping the stack 16 byte aligned. Taken from i386.
cflags-y += $(call cc-option,-mpreferred-stack-boundary=2)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] x86 merge fallout: uml
Don't undef __i386__/__x86_64__ in uml anymore, make sure that (few) places
that required adjusting the ifdefs got those.
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
arch/um/Makefile-i386 |3 +--
arch/um/Makefile-x86_64 |5 +
drivers/char/mem.c|4 ++--
drivers/md/raid6algos.c |4 ++--
drivers/md/raid6mmx.c |2 +-
drivers/md/raid6sse1.c|2 +-
drivers/md/raid6sse2.c|4 ++--
drivers/md/raid6x86.h |2 +-
include/asm-um/unistd.h |1 -
include/linux/eventpoll.h |7 +--
kernel/signal.c |2 +-
11 files changed, 13 insertions(+), 23 deletions(-)
diff --git a/arch/um/Makefile-i386 b/arch/um/Makefile-i386
index 0178df3..08433f8 100644
--- a/arch/um/Makefile-i386
+++ b/arch/um/Makefile-i386
@@ -9,6 +9,7 @@ ELF_ARCH:= $(SUBARCH)
ELF_FORMAT := elf32-$(SUBARCH)
OBJCOPYFLAGS := -O binary -R .note -R .comment -S
HEADER_ARCH:= x86
+CHECKFLAGS += -D__i386__
ifeq ("$(origin SUBARCH)", "command line")
ifneq ("$(shell uname -m | sed -e s/i.86/i386/)", "$(SUBARCH)")
@@ -26,8 +27,6 @@ AFLAGS+= -DCONFIG_X86_32
CONFIG_X86_32 := y
export CONFIG_X86_32
-ARCH_KERNEL_DEFINES += -U__$(SUBARCH)__ -U$(SUBARCH)
-
# First of all, tune CFLAGS for the specific CPU. This actually sets cflags-y.
include $(srctree)/arch/i386/Makefile.cpu
diff --git a/arch/um/Makefile-x86_64 b/arch/um/Makefile-x86_64
index fe5316f..8ed362f 100644
--- a/arch/um/Makefile-x86_64
+++ b/arch/um/Makefile-x86_64
@@ -6,12 +6,9 @@ START := 0x6000
_extra_flags_ = -fno-builtin -m64
-#We #undef __x86_64__ for kernelspace, not for userspace where
-#it's needed for headers to work!
-ARCH_KERNEL_DEFINES = -U__$(SUBARCH)__
KBUILD_CFLAGS += $(_extra_flags_)
-CHECKFLAGS += -m64
+CHECKFLAGS += -m64 -D__x86_64__
KBUILD_AFLAGS += -m64
LDFLAGS += -m elf_x86_64
KBUILD_CPPFLAGS += -m64
diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index 0e937f6..20070b7 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -41,7 +41,7 @@
*/
static inline int uncached_access(struct file *file, unsigned long addr)
{
-#if defined(__i386__)
+#if defined(__i386__) && !defined(__arch_um__)
/*
* On the PPro and successors, the MTRRs are used to set
* memory types for physical addresses outside main memory,
@@ -57,7 +57,7 @@ static inline int uncached_access(struct file *file, unsigned
long addr)
test_bit(X86_FEATURE_CYRIX_ARR, boot_cpu_data.x86_capability)
||
test_bit(X86_FEATURE_CENTAUR_MCR,
boot_cpu_data.x86_capability) )
&& addr >= __pa(high_memory);
-#elif defined(__x86_64__)
+#elif defined(__x86_64__) && !defined(__arch_um__)
/*
* This is broken because it can generate memory type aliases,
* which can cause cache corruptions
diff --git a/drivers/md/raid6algos.c b/drivers/md/raid6algos.c
index 9265761..77a6e4b 100644
--- a/drivers/md/raid6algos.c
+++ b/drivers/md/raid6algos.c
@@ -52,7 +52,7 @@ const struct raid6_calls * const raid6_algos[] = {
_intx16,
_intx32,
#endif
-#if defined(__i386__)
+#if defined(__i386__) && !defined(__arch_um__)
_mmxx1,
_mmxx2,
_sse1x1,
@@ -60,7 +60,7 @@ const struct raid6_calls * const raid6_algos[] = {
_sse2x1,
_sse2x2,
#endif
-#if defined(__x86_64__)
+#if defined(__x86_64__) && !defined(__arch_um__)
_sse2x1,
_sse2x2,
_sse2x4,
diff --git a/drivers/md/raid6mmx.c b/drivers/md/raid6mmx.c
index 6181a5a..d4e4a1b 100644
--- a/drivers/md/raid6mmx.c
+++ b/drivers/md/raid6mmx.c
@@ -16,7 +16,7 @@
* MMX implementation of RAID-6 syndrome functions
*/
-#if defined(__i386__)
+#if defined(__i386__) && !defined(__arch_um__)
#include "raid6.h"
#include "raid6x86.h"
diff --git a/drivers/md/raid6sse1.c b/drivers/md/raid6sse1.c
index f0a1ba8..0666237 100644
--- a/drivers/md/raid6sse1.c
+++ b/drivers/md/raid6sse1.c
@@ -21,7 +21,7 @@
* worthwhile as a separate implementation.
*/
-#if defined(__i386__)
+#if defined(__i386__) && !defined(__arch_um__)
#include "raid6.h"
#include "raid6x86.h"
diff --git a/drivers/md/raid6sse2.c b/drivers/md/raid6sse2.c
index 0f01976..b034ad8 100644
--- a/drivers/md/raid6sse2.c
+++ b/drivers/md/raid6sse2.c
@@ -17,7 +17,7 @@
*
*/
-#if defined(__i386__) || defined(__x86_64__)
+#if (defined(__i386__) || defined(__x86_64__)) && !defined(__arch_um__)
#include "raid6.h"
#include "raid6x86.h"
@@ -161,7 +161,7 @@ const struct raid6_calls raid6_sse2x2 = {
#endif
-#ifdef __x86_64__
+#if defined(__x86_64__) && !defined(__arch_um__)
/*
* Unrolled-by-4 SSE2 implementation
diff --git a/drivers/md/raid6x86.h b/drivers/md/raid6x86.h
index 9111950..99fea7a 100644
--- a/drivers/md/raid6x86.h
+++ b/drivers/md/raid6x86.h
@@ -19,7 +19,7 @@
#ifndef LINUX_RAID_RAID6X86_H
#define LINUX_RAID_RAID6X86_H
-#if defined(__i386__) ||
Re: [patch 2/2] cpusets: add interleave_over_allowed option
> Nobody can show an example of an application that would be broken because
> of this and, given the scenario and sequence of events that it requires to
> be broken when implementing the default as Choice B, I don't think it's as
> much of an issue as you believe.
Well, neither you nor I have shown an example. That's different than
"nobody can."
Since it would affect any task setting memory policies while in a
cpuset holding less than all memory nodes, it seems potentially serious
to me.
Actually, I have one example. The libcpuset library would have some
breakage with Choice B the only Choice. But I'm in a position to deal
with that, so it's not a big deal.
> So all applications that use the libnuma interface and numactl will have
> different default behavior than those that simply issue
> {get,set}_mempolicy() calls.
Breaking the libnuma-Oracle solution stack is not an option.
And, unless someone in the know tells us otherwise, I have to assume
that this could break them. Now, the odds are that they simply don't
run that solution stack on any system making active use of cpusets,
so the odds are this would be no problem for them. But I don't
presently have enough knowledge of their situation to take that risk.
> if we go with what you're suggesting, we'll never get rid of the two
> differing behaviors and we'll be introducing different semantics
> to arguments of libnuma functions than the kernel API they are
> built upon.
We could get rid of Choice A once libnuma and libcpuset have adapted
to Choice B, and any other uses of Choice A that we've subsequently
identified have had sufficient time to adapt.
But dual support is pretty easy so far as the kernel code is concerned.
It's just a few nodes_remap() calls optionally invoked at a few key
spots in mm/mempolicy.c. Consequently there won't be a big hurry to
remove Choice A.
> > I'm trying to protect almost any application that uses both
> > set_mempolicy or mbind, while in a cpuset.
> >
> > If a task is in a cpuset on say nodes 16-23, and it wants to issue
> > any mbind, or any MPOL_PREFERRED, MPOL_BIND, or MPOL_INTERLEAVE
> > mempolicy call, then under Choice A it must issue nodemasks offset
> > by 16, relative to what it would issue under Choice B.
> >
>
> True, but the ordering of that scenario is troublesome. The correct way
> to implement it is to use set_mempolicy() or a higher level libnuma
> function with the same semantics and _then_ attach the task to a cpuset.
> Then the nodes_remap() takes care of the rest.
There is no "_then_ attach the task to a cpuset." On systems with
kernels configured with CONFIG_CPUSETS=y, all tasks are in a cpuset
all the time. Moreover, from a practical point of view, on large
systems managed with cpuset based mechanisms, almost all tasks are in
cpusets that do not include all nodes, for the entire life of the task.
And besides, I can't break existing applications willy-nilly, and
then claim it's their fault, because they should have been coded
differently. So "correct way" arguments don't hold alot of weight
for already released and deployed product.
> Paul, the changes required to an application that is currently using
> {get,set}_mempolicy() calls to setup the memory policy or the higher level
> functions through libnuma is so easy to use Choice B as a default instead
> of Choice A that it would be ridiculous to support configuring it on a
> per-system or per-cpuset basis.
David ;) I make some effort to avoid forcing applications to be
recoded and rebuilt in order to continue functioning.
> Yet the 'mems' file would still be system-wide; otherwise it would be
> impossible to expand the memory your cpuset has access to.
I had to read that a couple of times to make sense of it. I take that
it means that the node numbering used in each cpuset's 'mems' file has
to be system-wide. Yes, agreed.
(Well, actually, the node numbering of each cpusets 'mems' file could
be relative to its parent cpusets 'mem' numbers, but let's not go
there, as this discussion is already sufficiently complicated ;)
> Everything else would be relative to 'mems'.
That's what Choice B states, yes. Though to be clear, time for another
example:
* task is in cpuset with mems: 24-31
* task wants some memory policy on the first two nodes of its cpuset.
* by Choice A, it asks for nodes 24 and 25
* by Choice B, it asks for nodes 0 and 1
The Choice B numbering can be thought of as cpuset relative. In it,
node N means the N-th node in my current cpuset, modulo whatever is the
node size of that cpuset.
However ...
We need to continue to support Choice A as well, perhaps for some
interim, perhaps forever. Which doesn't much matter for now.
===
David - how would the following do for you?
Would it meet the need that prompted your initial patch set if we
added Choice B memory policy node numbering, but left Choice A as the
kernel default, with a per-task option (perhaps
Re: [PATCH] [CIFS] Silence two "defined but unused" warning
This should already be in the cifs-2.6.git tree and next -mm (I am waiting on the finish up of some CIFS ACL mapping code before requesting another cifs merge with mainline) http://git.kernel.org/?p=linux/kernel/git/sfrench/cifs-2.6.git;a=commitdiff;h=c94897790e7c67dcfe3a0b6f035996398c268313 On 10/28/07, Stephen Rothwell <[EMAIL PROTECTED]> wrote: > > Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]> > --- > fs/cifs/cifssmb.c |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > -- > Cheers, > Stephen Rothwell[EMAIL PROTECTED] > > diff --git a/fs/cifs/cifssmb.c b/fs/cifs/cifssmb.c > index f0d9a48..aa9dc9e 100644 > --- a/fs/cifs/cifssmb.c > +++ b/fs/cifs/cifssmb.c > @@ -2486,6 +2486,7 @@ querySymLinkRetry: > return rc; > } > > +#ifdef CONFIG_CIFS_EXPERIMENTAL > /* Initialize NT TRANSACT SMB into small smb request buffer. > This assumes that all NT TRANSACTS that we init here have > total parm and data under about 400 bytes (to fit in small cifs > @@ -2569,6 +2570,7 @@ validate_ntransact(char *buf, char **ppparm, char > **ppdata, > } > return 0; > } > +#endif /* CONFIG_CIFS_EXPERIMENTAL */ > > int > CIFSSMBQueryReparseLinkInfo(const int xid, struct cifsTconInfo *tcon, > -- > 1.5.3.4 > > -- Thanks, Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bluetooth: hci_sysfs work queue problem
On 10/1/07, Marcel Holtmann <[EMAIL PROTECTED]> wrote: > Hi Dave, > > > The hci_sysfs uses work queue to finish the sysfs add/del fuction. > > But when the same device connection failed, if another connection of > > same device come in before the delete work finish, sysfs will warn > > about duplicate filename creating. > > which kernel are we talking about. This problem should not exist > anymore. However the usage of a work queue is unavoidable. Recently, I encounted this issue again: Oct 26 16:57:00 darkstar kernel: sysfs: duplicate filename 'acl00194FA4E517' can not be created Oct 26 16:57:00 darkstar kernel: WARNING: at fs/sysfs/dir.c:424 sysfs_add_one() Oct 26 16:57:00 darkstar kernel: [] sysfs_add_one+0xa0/0xe0 Oct 26 16:57:00 darkstar kernel: [] sysfs_create_link+0x9b/0x140 Oct 26 16:57:00 darkstar kernel: [] create_files+0x31/0x60 Oct 26 16:57:00 darkstar kernel: [] bus_add_device+0x5b/0xf0 Oct 26 16:57:00 darkstar kernel: [] device_add+0x11c/0x350 Oct 26 16:57:00 darkstar kernel: [] add_conn+0x0/0x90 [bluetooth] Oct 26 16:57:00 darkstar kernel: [] add_conn+0xf/0x90 [bluetooth] Oct 26 16:57:00 darkstar kernel: [] run_workqueue+0x5e/0x110 Oct 26 16:57:00 darkstar kernel: [] worker_thread+0xac/0x100 Oct 26 16:57:00 darkstar kernel: [] autoremove_wake_function+0x0/0x50 Oct 26 16:57:00 darkstar kernel: [] autoremove_wake_function+0x0/0x50 Oct 26 16:57:00 darkstar kernel: [] worker_thread+0x0/0x100 Oct 26 16:57:00 darkstar kernel: [] kthread+0x59/0xa0 Oct 26 16:57:00 darkstar kernel: [] kthread+0x0/0xa0 Oct 26 16:57:00 darkstar kernel: [] kernel_thread_helper+0x7/0x14 Oct 26 16:57:00 darkstar kernel: === Oct 26 16:57:00 darkstar kernel: add_conn: Failed to register connection device Seems same problem as before. This time, I just used several rfcomm connections. I think if we can add an atomic variable 'going_away' like this: in hci_conn_del_sysfs: before INIT_WORK; atomic_set(_away, 1) in del_conn: after deleting completed atomic_set(_away, 0) in add_conn: busy waiting the going_away while (atomic_read(_away)) cpu_relax() Regards dave > Regards > > Marcel > > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 08/10] SLUB: Optional fast path using cmpxchg_local
On Sun, 28 Oct 2007, Pekka J Enberg wrote: > - local_irq_restore(flags); > + object = do_slab_alloc(s, c, gfpflags, node, addr); > + if (unlikely(!object)) > + goto out; Undoing the optimization that one of the earlier patches added. The #ifdef version is for me at least easier to read. The code there is a special unit that has to deal with the most performance critical piece of the slab allocator. And the #ifdef there clarifies that any changes have to be done to both branches. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] slub: nr_slabs is an atomic_long_t
On Sun, 28 Oct 2007 19:53:55 -0700 (PDT) Christoph Lameter <[EMAIL PROTECTED]> wrote: > > That was already fixed AFAICT. Not in Linus' tree, yet. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpttYSDYSayZ.pgp Description: PGP signature
Re: [RFC, PATCH] locks: remove posix deadlock detection
On Sun, 2007-10-28 at 16:41 -0600, Matthew Wilcox wrote: > On Sun, Oct 28, 2007 at 05:50:30PM -0400, Trond Myklebust wrote: > > > You can't fix the false EDEADLK detection without solving the halting > > > problem. Best of luck with that. > > > > I can see that it would be difficult to do efficiently, but basically, > > this boils down to finding a circular path in a graph. That is hardly an > > unsolvable issue... > > Bzzt. You get a false deadlock with multiple threads like so: > > Thread A of task B takes lock 1 > Thread C of task D takes lock 2 > Thread C of task D blocks on lock 1 > Thread E of task B blocks on lock 2 > > We currently declare deadlock at this point (unless the deadlock detection > code has changed since I last looked at it), despite thread A being about > to release lock 1. Oh, and by the way, thread E is capable of releasing > lock 1, so you can't just say "well, detect by thread instead of by task". > > So the only way I can see to accurately detect deadlock is to simulate > the future execution of all threads in task B to see if any of them > will release lock 1 without first gaining lock 2. Which, I believe, > is halting-equivalent. As several people have told you, the SUSv3 section on fcntl and deadlocks reads as follows: "A potential for deadlock occurs if a process controlling a locked region is put to sleep by attempting to lock another process' locked region. If the system detects that sleeping until a locked region is unlocked would cause a deadlock, fcntl() shall fail with an [EDEADLK] error." There is no mention there or anywhere else of a need to make exceptions when dealing with threads. The posix locking model is _process_ based, and so our deadlock detection only needs to take that into account. If programmers choose to play tricksy little games with threads, then it is their responsibility to ensure that the application doesn't get into a situation where the posix deadlock detection model breaks down. Trond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Silence radeon_pm warning
From: Stephen Rothwell <[EMAIL PROTECTED]> Date: Mon, 29 Oct 2007 13:59:11 +1100 > drivers/video/aty/radeon_pm.c:30: warning: 'radeon_reinitialize_M10' declared > 'static' but never defined > > Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]> Acked-by: David S. Miller <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] stringbuf: A string buffer implementation
On Sat, Oct 27, 2007 at 08:09:30PM +1000, Rusty Russell wrote: > On Saturday 27 October 2007 06:57:14 Matt Mackall wrote: > > Well I expect once you start letting people easily build strings by > > concatenation, you'll very shortly afterwards have people using them > > in loops. And having hidden O(n^2) behavior in there is a little sad, > > even though n will tend to be small and well-bounded. If we can do > > something simple to avoid it, we should. > > Hi Matt, > > I avoid typing even a single character of optimization until it's > justified. This is partially a reaction against the machoptimization > tendencies of many kernel programmers, but it's mainly a concern at the > kernel's complexity creep. > > Meanwhile, of course, I've now spent far too long analyzing this :) > > Building a 1000 byte string 1 byte at a time involves 6 reallocs (SLAB) or 10 > reallocs (SLUB). Frankly, that's good enough without an explicit alloc > length field (better in some ways). And on SLOB, which doesn't have those bloaty power-of-2 constraints? Looks like ~500 reallocs, including 25 bytes of memcpy. Ouch! SLAB and SLUB (accidentally) internalize the optimization that I'm proposing: grow the string by a constant factor at each step. Failing to do that makes the behavior dismal. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 09/10] SLUB: Do our own locking via slab_lock and slab_unlock.
On Sun, 28 Oct 2007, Pekka J Enberg wrote:
> It would be easier to review the actual locking changes if you did the
> SlabXXX removal in a separate patch.
There are no locking changes.
> > -static __always_inline void slab_lock(struct page *page)
> > +static __always_inline void slab_unlock(struct page *page,
> > + unsigned long state)
> > {
> > - bit_spin_lock(PG_locked, >flags);
> > + smp_wmb();
>
> Memory barriers deserve a comment. I suppose this is protecting
> page->flags but against what?
Its making sure that the changes to page flags are made visible after all
other changes.
>
> > + page->flags = state;
> > + preempt_enable();
>
> We don't need preempt_enable for CONFIG_SMP, right?
preempt_enable is needed if preemption is enabled.
>
> > +__release(bitlock);
>
> This needs a less generic name and maybe a comment explaining that it's
> not annotating a proper lock? Or maybe we can drop it completely?
Probably.
> > +static __always_inline unsigned long slab_trylock(struct page *page)
> > +{
> > + unsigned long state;
> > +
> > + preempt_disable();
> > + state = page->flags & ~LOCKED;
> > +#ifdef CONFIG_SMP
> > + if (cmpxchg(>flags, state, state | LOCKED) != state) {
> > +preempt_enable();
> > +return 0;
> > + }
> > +#endif
>
> This is hairy. Perhaps it would be cleaner to have totally separate
> functions for SMP and UP instead?
I think that is reasonably clear. Having code duplicated is not good
either. Well we may have to clean this up a bit.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 08/10] SLUB: Optional fast path using cmpxchg_local
On Sun, 28 Oct 2007, Pekka J Enberg wrote: > Can you please write a comment of the locking rules when cmpxchg_local() > is used? Looks as if we could push that local_irq_save() to slub_lock() > and local_irq_restore() to slub_unlock() and deal with the unused flags > variable for the non-CONFIG_FAST_CMPXCHG_LOCAL case with a macro, no? H... Maybe .. The locking rules are not changed at all by this patch. The cmpxchg_local is only used for the per cpu object list. The per cpu slabs are frozen. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Silence radeon_pm warning
drivers/video/aty/radeon_pm.c:30: warning: 'radeon_reinitialize_M10' declared 'static' but never defined Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]> --- drivers/video/aty/radeon_pm.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) -- Cheers, Stephen Rothwell[EMAIL PROTECTED] diff --git a/drivers/video/aty/radeon_pm.c b/drivers/video/aty/radeon_pm.c index be1d57b..f989836 100644 --- a/drivers/video/aty/radeon_pm.c +++ b/drivers/video/aty/radeon_pm.c @@ -27,7 +27,9 @@ #include "ati_ids.h" +#ifdef CONFIG_PM static void radeon_reinitialize_M10(struct radeonfb_info *rinfo); +#endif /* * Workarounds for bugs in PC laptops: -- 1.5.3.4 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] VFS: apply coding standards to fs/ioctl.c
On 10/28/07, Christoph Hellwig <[EMAIL PROTECTED]> wrote: > While you're at it, it's probably worth splitting this out into > a small helper function. Why? Is the same pattern called from more than one place? Regards, Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [M68KNOMMU]: new style ColdFire UART driver
Hi Andrew,
Andrew Morton wrote:
On Fri, 19 Oct 2007 11:42:41 +1000
Greg Ungerer <[EMAIL PROTECTED]> wrote:
A new style serial driver for the Freescale ColdFire UART to replace
the old style one currently in the tree (drivers/serial/mcfserial.c).
Currently this UART is only found in the ColdFire CPU family of parts
(thus I prefixed this patch [M68KNOMMU]).
This has been around for a long while now, tested on all available
platforms.
...
All of these:
+//
don't really add much value.
+static unsigned int mcf_get_mctrl(struct uart_port *port)
+{
+ struct mcf_uart *pp = (struct mcf_uart *) port;
container_of() would be nicer: it explains what's going on and removes the
unpleasing requirement that uart_port be the first member of mcf_uart.
+static void mcf_set_mctrl(struct uart_port *port, unsigned int sigs)
+{
+ struct mcf_uart *pp = (struct mcf_uart *) port;
Many instances..
Ok, I'll change those over to container_of().
+static void mcf_set_termios(struct uart_port *port, struct ktermios *termios,
+ struct ktermios *old)
+{
+ unsigned long flags;
+ unsigned int baud, baudclk;
+ unsigned char mr1, mr2;
Is this all up-to-date with Alan's recent termios changes?
As far as I can tell, yes.
+static struct mcf_uart mcf_ports[3];
+
+#defineMCF_MAXPORTS(sizeof(mcf_ports) / sizeof(struct mcf_uart))
Use ARRAY_SIZE here.
Yep, I'll change that.
+//
+#if defined(CONFIG_SERIAL_MCF_CONSOLE)
+//
+
+int __init early_mcf_setup(struct mcf_platform_uart *platp)
hrm, this is global and has no callers.
+{
+ struct uart_port *port;
+ int i;
+
+ for (i = 0; ((i < MCF_MAXPORTS) && (platp[i].mapbase)); i++) {
+ port = _ports[i].port;
+
+ port->line = i;
+ port->type = PORT_MCF;
+ port->mapbase = platp[i].mapbase;
+ port->membase = (platp[i].membase) ? platp[i].membase :
+ (unsigned char __iomem *) port->mapbase;
+ port->iotype = SERIAL_IO_MEM;
+ port->irq = platp[i].irq;
+ port->uartclk = MCF_BUSCLK;
+ port->flags = ASYNC_BOOT_AUTOCONF;
+ port->ops = _uart_ops;
+ }
+
+ return 0;
+}
+
It is intended to be used by ColdFire platforms that want early
boot console support. The old driver (drivers/serial/mcfserial.c)
sort of gave you this for free with its fixed resourcing.
I have changes to the ColdFire based m68knommu systems to
use a platform model at init, and this is used there.
Thanks.
Regards
Greg
Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED]
Secure Computing CorporationPHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [CIFS] Silence two "defined but unused" warning
Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]> --- fs/cifs/cifssmb.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) -- Cheers, Stephen Rothwell[EMAIL PROTECTED] diff --git a/fs/cifs/cifssmb.c b/fs/cifs/cifssmb.c index f0d9a48..aa9dc9e 100644 --- a/fs/cifs/cifssmb.c +++ b/fs/cifs/cifssmb.c @@ -2486,6 +2486,7 @@ querySymLinkRetry: return rc; } +#ifdef CONFIG_CIFS_EXPERIMENTAL /* Initialize NT TRANSACT SMB into small smb request buffer. This assumes that all NT TRANSACTS that we init here have total parm and data under about 400 bytes (to fit in small cifs @@ -2569,6 +2570,7 @@ validate_ntransact(char *buf, char **ppparm, char **ppdata, } return 0; } +#endif /* CONFIG_CIFS_EXPERIMENTAL */ int CIFSSMBQueryReparseLinkInfo(const int xid, struct cifsTconInfo *tcon, -- 1.5.3.4 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] slub: nr_slabs is an atomic_long_t
On Mon, 29 Oct 2007, Stephen Rothwell wrote: > so shouldn't be passed to atomic_read. That was already fixed AFAICT. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/5] Detect hwmon and i2c bus drivers interfering with ACPI Operation Region resources
On Saturday 27 October 2007 9:09:47 am Matthew Garrett wrote: > On Thu, Oct 25, 2007 at 09:06:22AM -0600, Bjorn Helgaas wrote: > > But we really *should* reserve things used by opregions, shouldn't > > we? After all, the whole point of resource reservation is to prevent > > conflicts. > > Only if you're happy to lose functionality like IDE, sadly. That's a simplistic answer to a complex problem. I don't think we should just ignore the whole problem, cross our fingers, and hope that firmware stays out of our way. Bjorn - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: 2.6 patch] remove the USB_STORAGE_ONETOUCH driver
On Sunday 28 October 2007 16:39, Jiri Kosina wrote: > On Sun, 28 Oct 2007, Torsten Kaiser wrote: > > > But it looks like that uses another driver: > > hiddev0hidraw1: USB HID v1.10 Device [Western Digital External HDD] on > > usb-:00:02.1-5.2 > > Otherwise I would be willing to try to test this, if someone would tell > > me how to check that the second commit did fix the suspend problem. > > If you need to unbind usbhid driver from the device and bind another one, > you can use the 'unbind' and 'bind' files in sysfs. > > As soon as the driver you are willing to test is bound to the device, you > can go ahead with testing any functionality you wish (probably > suspend/resume cycle is needed here?). > > If the device is claimed by usbhid driver (because its descriptor probably > states that it's HID-compliant device) and should be claimed by another > driver, it's necessary to add it to usbhid blacklist -- just let me know. > Maybe onetouch driver is not needed after all. I wonder what key/button does HID deriver reports when it binds to it... Torsten, could you please post your /proc/bus/input/devices? -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] VFS: swap do_ioctl and vfs_ioctl names
On Sun, 28 Oct 2007 20:40:56 -0400 Erez Zadok wrote:
> Rename old vfs_ioctl to do_ioctl, because the comment above it clearly
> indicates that it is an internal function not to be exported to modules;
> therefore it should have a more traditional do_XXX name. The new do_ioctl
> is exported in fs.h but not to modules.
>
> Rename the old do_ioctl to vfs_ioctl because the names vfs_XXX should
> preferably be reserved to callable VFS functions which modules may call, as
> many other vfs_XXX functions already do. Export the new vfs_ioctl to GPL
> modules so others can use it (including Unionfs and eCryptfs). Add DocBook
> for new vfs_ioctl.
>
> Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
> ---
> fs/compat_ioctl.c |2 +-
> fs/ioctl.c | 30 ++
> include/linux/fs.h |3 ++-
> 3 files changed, 25 insertions(+), 10 deletions(-)
>
> diff --git a/fs/ioctl.c b/fs/ioctl.c
> index 652cacf..34e3f58 100644
> --- a/fs/ioctl.c
> +++ b/fs/ioctl.c
> @@ -16,8 +16,21 @@
>
> #include
>
> -static long do_ioctl(struct file *filp, unsigned int cmd,
> - unsigned long arg)
> +/**
> + * vfs_ioctl - call filesystem specific ioctl methods
> + *
No "blank" line allowed in kernel-doc between function name and its
parameters.
> + * @filp: [in] open file to invoke ioctl method on
> + * @cmd: [in] ioctl command to execute
> + * @arg: [in/out] command-specific argument for ioctl
> + *
> + * Invokes filesystem specific ->unlock_ioctl, if one exists; otherwise
> + * invokes * filesystem specific ->ioctl method. If neither method exists,
> + * returns -ENOTTY.
> + *
> + * Returns 0 on success, -errno on error.
> + */
> +long vfs_ioctl(struct file *filp, unsigned int cmd,
> +unsigned long arg)
> {
> int error = -ENOTTY;
>
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index b3ec4a4..c0c5d36 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -1924,7 +1924,8 @@ extern int vfs_stat_fd(int dfd, char __user *, struct
> kstat *);
> extern int vfs_lstat_fd(int dfd, char __user *, struct kstat *);
> extern int vfs_fstat(unsigned int, struct kstat *);
>
> -extern int vfs_ioctl(struct file *, unsigned int, unsigned int, unsigned
> long);
> +extern long vfs_ioctl(struct file *filp, unsigned int cmd, unsigned long
> arg);
> +extern int do_ioctl(struct file *, unsigned int, unsigned int, unsigned
> long);
Use/keep parameter names, please. That is preferred.
> extern void get_filesystem(struct file_system_type *fs);
> extern void put_filesystem(struct file_system_type *fs);
> --
> 1.5.2.2
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
---
~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: [RFC, PATCH] locks: remove posix deadlock detection
On Sun, Oct 28, 2007 at 11:38:26PM +, Alan Cox wrote: > > > The spec and SYSV certainly ignore threading in this situation and you > > > know that perfectly well (or did in 2004) > > > > The discussion petered out (or that mailing list archive lost articles > > from the thread) without any kind of resolution, or indeed interest. > > I think the resolution was that the EDEADLK stayed. > > > What is your suggestion for handling this problem? As it is now, the > > kernel 'detects' deadlock where there is none, which doesn't seem > > allowed by SuSv3 either > > Re-read the spec. The EDEADLK doesn't account for threads, only processes. Do you have in mind a way to take advantage of that distinction? The practical requirement I see here is that our deadlock detection should never give false positives. If we return EDEADLK to applications with locking schemes that don't actually deadlock, then we're telling application designers that avoiding deadlock in itself isn't sufficient--they also have to know our particular deadlock detection algorithm, so as to avoid giving even the appearance of deadlock. And if posix file locks are to be useful to threaded applications, then we have to preserve the same no-false-positives requirement for them as well. But, OK, if we can identify unshared current->files at the time we put a task to sleep, then a slight modification of our current algorithm might be sufficient to detect any deadlock that involves purely posix file locks and processes. And we can tell people that avoiding deadlock is their problem as soon as any task with a shared current->files is involved. (Ditto, I assume, if nfsd/lockd acquires a lock.) --b. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: aim7 -30% regression in 2.6.24-rc1
On Fri, 2007-10-26 at 13:23 +0200, Ingo Molnar wrote: > * Zhang, Yanmin <[EMAIL PROTECTED]> wrote: > > > I tested 2.6.24-rc1 on my x86_64 machine which has 2 quad-core processors. > > > > Comparing with 2.6.23, aim7 has about -30% regression. I did a bisect > > and found patch > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b5869ce7f68b233ceb81465a7644be0d9a5f3dbb > > > > caused the issue. > > weird, that's a commit diff - i.e. it changes no code. I got the tag from #git log. As for above link, I just added prior http address, so readers could check the patch by clicking. > > > kbuild/SPECjbb2000/SPECjbb2005 also has big regressions. On my another > > tigerton machine (4 quad-core processors), SPECjbb2005 has more than > > -40% regression. I didn't do a bisect on such benchmark testing, but I > > suspect the root cause is like aim7's. > > these two commits might be relevant: > > 7a6c6bcee029a978f866511d6e41dbc7301fde4c I did a quick testing. This patch has no impact. > 95dbb421d12fdd9796ed153853daf3679809274f Above big patch doesn't include this one, which means if I do 'git checkout b5869ce7f68b233ceb81465a7644be0d9a5f3dbb', the kernel doesn't include 95dbb421d12fdd9796ed153853daf3679809274f. > > but a bisection result would be the best info. I will do a bisect between 2.6.23 and tag 9c63d9c021f375a2708ad79043d6f4dd1291a085. -yanmin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] slub: nr_slabs is an atomic_long_t
so shouldn't be passed to atomic_read. mm/slub.c: In function 'slab_mem_offline_callback': mm/slub.c:2737: warning: passing argument 1 of 'atomic_read' from incompatible pointer type mm/slub.c:2737: warning: passing argument 1 of 'atomic_read' from incompatible pointer type mm/slub.c:2737: warning: passing argument 1 of 'atomic_read' from incompatible pointer type Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]> --- mm/slub.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Seen on PowerPC allyesconfig build. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] diff --git a/mm/slub.c b/mm/slub.c index aac1dd3..bcdb2c8 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -2734,7 +2734,7 @@ static void slab_mem_offline_callback(void *arg) * and offline_pages() function shoudn't call this * callback. So, we must fail. */ - BUG_ON(atomic_read(>nr_slabs)); + BUG_ON(atomic_long_read(>nr_slabs)); s->node[offline_node] = NULL; kmem_cache_free(kmalloc_caches, n); -- 1.5.3.4 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] locks: remove posix deadlock detection
On Sun, Oct 28, 2007 at 04:41:57PM -0600, Matthew Wilcox wrote: > On Sun, Oct 28, 2007 at 05:50:30PM -0400, Trond Myklebust wrote: > > > You can't fix the false EDEADLK detection without solving the halting > > > problem. Best of luck with that. > > > > I can see that it would be difficult to do efficiently, but basically, > > this boils down to finding a circular path in a graph. That is hardly an > > unsolvable issue... > > Bzzt. You get a false deadlock with multiple threads like so: > > Thread A of task B takes lock 1 > Thread C of task D takes lock 2 > Thread C of task D blocks on lock 1 > Thread E of task B blocks on lock 2 Oh neat, I missed that case, thanks for pointing it out. > We currently declare deadlock at this point (unless the deadlock detection > code has changed since I last looked at it), despite thread A being about > to release lock 1. Oh, and by the way, thread E is capable of releasing > lock 1, so you can't just say "well, detect by thread instead of by task". > > So the only way I can see to accurately detect deadlock is to simulate > the future execution of all threads in task B to see if any of them > will release lock 1 without first gaining lock 2. Hm. It's annoying, but I'm not convinced it's *that* annoying. We're not trying to predict whether a deadlock could arise as the result of future behavior. We're just trying to determine whether granting the current lock request results in an immediate deadlock consisting purely of posix file locks. But yes, I'm assume it's possible, for example, that a thread-exit could race with a lock request, with the result that we see no deadlock at the time we handle the lock request, even though at that point the last task with the ability to solve the problem is already exiting. Supposing that we're willing to permit the request in such cases and return EDEADLK only in cases where we're positive there's a deadlock, is there still some useful subset of cases where we could return EDEADLK? For example, could we take note of tasks that, when they block on a lock, have a current->files with reference count one, and only follow cycles consisting of such blocks? I'm still not convinced it's worth the trouble, but I suspect you're overstating the difficulty. --b. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.24-rc1-git4: Reported regressions from 2.6.23
David Miller wrote: > >> Subject: Settings to /proc/sys/net/ipv[46]/conf/all are >> not propagated. via sysctl too >> Submitter : Serge van den Boom <[EMAIL PROTECTED]> >> References: http://bugzilla.kernel.org/show_bug.cgi?id=9224 >> Handled-By: Hideaki YOSHIFUJI <[EMAIL PROTECTED]> > > I am to understand, from a reply from Herbert Xu, that this issue has > existed a long time, definitely since before 2.6.22, therefore it > doesn't belong on the regression list. I'm fairly sure that this originates with 2.6.21 as it looks very similar to http://bugzilla.kernel.org/show_bug.cgi?id=8519 which I filed at that time and which I traced to 8030f54499925d07. I've never been convinced that that change was correct, but as it now "works for me" due to changes in the Debian default configuration files, I decided to not follow up. Of course, not honoring 'all' is more obviously a bug than not honoring 'default' for existing interfaces. I've added a comment to #8519. Hope this helps, Frans Pop - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.24-rc1-git4: Reported regressions from 2.6.23
On Monday, 29 October 2007 02:17, David Miller wrote: > From: "Rafael J. Wysocki" <[EMAIL PROTECTED]> > Date: Sun, 28 Oct 2007 23:51:55 +0100 > > > Subject : Settings to /proc/sys/net/ipv[46]/conf/all are not > > propagated. via sysctl too > > Submitter : Serge van den Boom <[EMAIL PROTECTED]> > > References : http://bugzilla.kernel.org/show_bug.cgi?id=9224 > > Handled-By : Hideaki YOSHIFUJI <[EMAIL PROTECTED]> > > I am to understand, from a reply from Herbert Xu, that this issue has > existed a long time, definitely since before 2.6.22, therefore it > doesn't belong on the regression list. I have removed it from the list. Thanks, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.24-rc1-git4: Reported regressions from 2.6.23
From: "Rafael J. Wysocki" <[EMAIL PROTECTED]> Date: Sun, 28 Oct 2007 23:51:55 +0100 > Subject : Settings to /proc/sys/net/ipv[46]/conf/all are not > propagated. via sysctl too > Submitter : Serge van den Boom <[EMAIL PROTECTED]> > References: http://bugzilla.kernel.org/show_bug.cgi?id=9224 > Handled-By: Hideaki YOSHIFUJI <[EMAIL PROTECTED]> I am to understand, from a reply from Herbert Xu, that this issue has existed a long time, definitely since before 2.6.22, therefore it doesn't belong on the regression list. The bug reporter says something that drives me a little batty, which is probably what got this onto the regression list. He says "2.6.22 (not sure)" as the most recent kernel where the problem didn't occur. People should list no version at all if they don't know, otherwise we'll just get more bogons on the regression list. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] locks: remove posix deadlock detection
On Sun, Oct 28, 2007 at 06:40:52PM +, Alan Cox wrote: > On Sun, 28 Oct 2007 12:27:32 -0600 > Matthew Wilcox <[EMAIL PROTECTED]> wrote: > > > On Sun, Oct 28, 2007 at 01:43:21PM -0400, J. Bruce Fields wrote: > > > We currently attempt to return -EDEALK to blocking fcntl() file locking > > > requests that would create a cycle in the graph of tasks waiting on > > > locks. > > > > > > This is inefficient: in the general case it requires us determining > > > whether we're adding a cycle to an arbitrary directed acyclic graph. > > > And this calculation has to be performed while holding a lock (currently > > > the BKL) that prevents that graph from changing. > > > > > > It has historically been a source of bugs; most recently it was noticed > > > that it could loop indefinitely while holding the BKL. > > > > It can also return -EDEADLK spuriously. So yeah, just kill it. > > NAK. This is an ABI change. It was also comprehensively rejected before > because > > - EDEADLK behaviour is ABI > - EDEADLK behaviour is required by SuSv3 > - We have no idea what applications may rely on this behaviour. On the second point I think you're mistaken; see http://www.opengroup.org/onlinepubs/009695399/functions/fcntl.html "Since implementation of full deadlock detection is not always feasible, the [EDEADLK] error was made optional." The third objection is the one that concerns me most, and is the one I'd like to understand better. So I'd be interested in any evidence of applications that do actually depend on the current behavior. (Even hypothetical use cases might be interesting.) I'm also curious what other OS's do. > See the thread > http://osdir.com/ml/file-systems/2004-06/msg00017.html > > so we need to fix the bugs - the lock usage and the looping. At that > point it merely becomes a performance concern to those who use it, which > is the proper behaviour. If you want a faster non-checking one use > flock(), or add another flag that is a Linux "don't check for deadlock" That's an interesting idea. The flag might not help as much, since looking for a cycle in the graph of blocked requests may be more difficult in the case where we don't know whether the graph is acyclic to start out with. (But I don't know--I haven't thought about it much.) --b. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Only show RESOURCES_64BIT on relevant architectures
From: Kyle McMartin <[EMAIL PROTECTED]> Date: Sun, 28 Oct 2007 16:15:49 -0400 > To quote lolcats: CONFIG_RESOURCES_64BIT DO NOT WANT! > > I *think* I have the logic of this right... Anyway, I was annoyed by > having to do the bloody ugly casts to unsigned long long in > arch-specific code. As near as I can tell, we only want this selectable > in the case of PAE on x86, and some random PPC and MIPS embedded boards. > > For everyone else, it should be whatever the value of 64BIT is. > > And I can be happy and continue using unsigned long and going about my > merry business. > > Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]> 32-bit sparc has 36-bit physical addresses and thus needs 64-bit resources too - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5]: [PCI]: Remove 3 incorrect MSI quirks.
From: "David Gaarenstroom" <[EMAIL PROTECTED]> Date: Sun, 28 Oct 2007 21:11:13 +0100 > > I would like those to be removed, but to be conservative we should > > first get some testing feedback that confirms this just like those > > provided to me from the AMD folks for the RS690, RX790 and RD580 > > cases. > > The patch works fine for my laptop with the RS480 chipset (with a > SB400 southbridge). > But it would be nice if AMD tested it as well... So please submit "The patch" :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Align PCI memory regions to page size (4K) - Fix
From: Greg KH <[EMAIL PROTECTED]> Date: Sun, 28 Oct 2007 13:03:36 -0700 > But doesn't aligning such regions on that alignment break some devices > as that is not what the device is asking for in the BIOS? There are also platforms where bootup firmware chooses the allocations, and that is what we use no matter what. This is so that when breaking into the firmware for debugging the firmware can still access the console device where it had mapped it in the first place. We really can't do things this way. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3 -v4] x86_64 EFI runtime service support: EFI basic runtime service support
On Fri, 2007-10-26 at 12:31 +0100, Alan Cox wrote: > On Fri, 26 Oct 2007 09:03:11 +0800 > "Huang, Ying" <[EMAIL PROTECTED]> wrote: > > > On Thu, 2007-10-25 at 18:09 +0200, Thomas Gleixner wrote: > > > > EFI runtime > > > > services initialization are implemented in efi.c. Some x86_64 > > > > specifics are worth noting here. On x86_64, parameters passed to UEFI > > > > firmware services need to follow the UEFI calling convention. For this > > > > purpose, a set of functions named lin2win ( is the number of > > > > parameters) are implemented. EFI function calls are wrapped before > > > > calling the firmware service. > > > > > > Why needs this to be called lin2win? We do not call Windows, we call > > > EFI services, so please use a naming convention which is related to > > > the functionality of the code. > > > > > > > + * > > > > + * Function calling ABI conversion from SYSV to Windows for x86_64 > > > > > > Again, these are wrappers to access EFI and not Windows. > > > > EFI uses the Windows x86_64 calling convention. The lin2win may be a > > more general naming convention that can be used for some other code (the > > NDISwrapper?) in the future. Do you agree? > > The SYSV description is wrong as well. SYSV has no calling convention. I > think you mean iABI or iBCS2 ? The SYSV description comes from the following document: http://www.x86-64.org/documentation/abi-0.98.pdf > Whats wrong with following the pattern of other calls like syscall(...) > and just having eficall() ? Yes. This is better. Best Regards, Huang Ying - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2/2] cpusets: add interleave_over_allowed option
On Sun, 28 Oct 2007, Paul Jackson wrote:
> The Linux documentation is not a legal contract. Anytime we change the
> actual behaviour of the code, we have to ask ourselves what will be the
> impact of that change on existing users and usages. The burden is on
> us to minimize breaking things (by that I mean, what users would
> consider breakage, even if we think it is all for the better and that
> their code was the real problem.) I didn't say no breakage, but
> minimum breakage, doing our best to guide users through changes with
> minimum disruption to their work.
>
Nobody can show an example of an application that would be broken because
of this and, given the scenario and sequence of events that it requires to
be broken when implementing the default as Choice B, I don't think it's as
much of an issue as you believe.
> > However, in deference to the needs of libnuma, if the following
> > call was made, this would change the mode for that task to
> > Choice A:
> >
> > get_mempolicy(NULL, NULL, 0, 0, 0);
> >
> > This last detail above is an admitted hack. *So far as I know*
> > it happens that all current infield versions of libnuma issue the
> > above call, as their first mempolicy query, to detemine whether
> > the active kernel supports mempolicy.
>
> The above is the hack that allows us to support existing libnuma based
> applications (the most significant users of memory policy historically)
> with a default of Choice A, while other code and future code defaults
> to Choice B.
>
So all applications that use the libnuma interface and numactl will have
different default behavior than those that simply issue
{get,set}_mempolicy() calls. libnuma is a collection of higher level
functions that should be built upon {get,set}_mempolicy() like they
currently are and not introduce new subtleties like changing the semantics
of a preferred node argument. This is going to quickly become a
documentation nightmare and, in my opinion, isn't worth the time or effort
to support because we haven't even idenitifed any real-world examples.
Maybe Andi Kleen should weigh in on this topic because, if we go with what
you're suggesting, we'll never get rid of the two differing behaviors and
we'll be introducing different semantics to arguments of libnuma functions
than the kernel API they are built upon.
> I'm trying to protect almost any application that uses both
> set_mempolicy or mbind, while in a cpuset.
>
> If a task is in a cpuset on say nodes 16-23, and it wants to issue
> any mbind, or any MPOL_PREFERRED, MPOL_BIND, or MPOL_INTERLEAVE
> mempolicy call, then under Choice A it must issue nodemasks offset
> by 16, relative to what it would issue under Choice B.
>
True, but the ordering of that scenario is troublesome. The correct way
to implement it is to use set_mempolicy() or a higher level libnuma
function with the same semantics and _then_ attach the task to a cpuset.
Then the nodes_remap() takes care of the rest.
The scenario you describe above has a problem because it requires the task
to have knowledge of the cpuset's mems in which it is attached when, for
portability, it should have been written so that it is robust to any range
of nodes you happen to assign it to.
> Almost any task using memory policies on a system making active use of
> cpusets will be affected, even well written ones doing simple things.
>
No, because nodes_remap() takes care of the instances you describe above
when the task sets its memory policy (usually done when it is started) and
is then attached to a cpuset.
> However, if anyone is deploying product or has important (to them) but
> not easy to change software using both memory policies and cpusets that
> are not doing so via libnuma or libcpuset, then any change that
> changes the default for their memory policy calls from Choice A to
> Choice B will probably break them.
>
Supporting two different behaviors is going to be more problematic than
simply selecting one and going with it and its associated documentation in
future versions of the kernel.
> I'm tempted to think I need to go a bit further:
> 1) Add a per-system or per-cpuset runtime mode, to enable a system
> administrator to revert to the Choice A default.
Paul, the changes required to an application that is currently using
{get,set}_mempolicy() calls to setup the memory policy or the higher level
functions through libnuma is so easy to use Choice B as a default instead
of Choice A that it would be ridiculous to support configuring it on a
per-system or per-cpuset basis.
> 2) Make sure that both the new libnuma and libcpuset versions dynamically
> probe the state of this default, and dynamically adapt to running
> on a kernel, or in a cpuset, of either default. If this mode is
> per-cpuset, then so long as there are not two applications that
> must both run in the same cpuset, both using memory
Linux 2.6.16.56-rc2
Security fixes since 2.6.16.55: - CVE-2007-3739: Don't allow the stack to grow into hugetlb reserved regions - CVE-2007-4133: hugetlb: fix prio_tree unit Location: ftp://ftp.kernel.org/pub/linux/kernel/people/bunk/linux-2.6.16.y/testing/ git tree: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git RSS feed of the git tree: http://www.kernel.org/git/?p=linux/kernel/git/stable/linux-2.6.16.y.git;a=rss Changes since 2.6.16.56-rc1: Adrian Bunk (1): Linux 2.6.16.56-rc2 David Gibson (1): hugetlb: check for brk() entering a hugepage region Hugh Dickins (2): hugetlb: fix error return for brk() entering a hugepage region hugetlb: fix size=4G parsing Ken Chen (1): [IA64] fix ia64 is_hugepage_only_range Makefile |2 +- arch/ia64/mm/hugetlbpage.c |7 +++ fs/hugetlbfs/inode.c |1 - include/asm-ia64/page.h|2 +- mm/mmap.c |3 +++ 5 files changed, 8 insertions(+), 7 deletions(-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] VFS: swap do_ioctl and vfs_ioctl names
Rename old vfs_ioctl to do_ioctl, because the comment above it clearly
indicates that it is an internal function not to be exported to modules;
therefore it should have a more traditional do_XXX name. The new do_ioctl
is exported in fs.h but not to modules.
Rename the old do_ioctl to vfs_ioctl because the names vfs_XXX should
preferably be reserved to callable VFS functions which modules may call, as
many other vfs_XXX functions already do. Export the new vfs_ioctl to GPL
modules so others can use it (including Unionfs and eCryptfs). Add DocBook
for new vfs_ioctl.
Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
---
fs/compat_ioctl.c |2 +-
fs/ioctl.c | 30 ++
include/linux/fs.h |3 ++-
3 files changed, 25 insertions(+), 10 deletions(-)
diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c
index a4284cc..a1604ce 100644
--- a/fs/compat_ioctl.c
+++ b/fs/compat_ioctl.c
@@ -2972,7 +2972,7 @@ asmlinkage long compat_sys_ioctl(unsigned int fd,
unsigned int cmd,
}
do_ioctl:
- error = vfs_ioctl(filp, fd, cmd, arg);
+ error = do_ioctl(filp, fd, cmd, arg);
out_fput:
fput_light(filp, fput_needed);
out:
diff --git a/fs/ioctl.c b/fs/ioctl.c
index 652cacf..34e3f58 100644
--- a/fs/ioctl.c
+++ b/fs/ioctl.c
@@ -16,8 +16,21 @@
#include
-static long do_ioctl(struct file *filp, unsigned int cmd,
- unsigned long arg)
+/**
+ * vfs_ioctl - call filesystem specific ioctl methods
+ *
+ * @filp: [in] open file to invoke ioctl method on
+ * @cmd: [in] ioctl command to execute
+ * @arg: [in/out] command-specific argument for ioctl
+ *
+ * Invokes filesystem specific ->unlock_ioctl, if one exists; otherwise
+ * invokes * filesystem specific ->ioctl method. If neither method exists,
+ * returns -ENOTTY.
+ *
+ * Returns 0 on success, -errno on error.
+ */
+long vfs_ioctl(struct file *filp, unsigned int cmd,
+ unsigned long arg)
{
int error = -ENOTTY;
@@ -39,6 +52,7 @@ static long do_ioctl(struct file *filp, unsigned int cmd,
out:
return error;
}
+EXPORT_SYMBOL_GPL(vfs_ioctl);
static int file_ioctl(struct file *filp, unsigned int cmd,
unsigned long arg)
@@ -72,18 +86,18 @@ static int file_ioctl(struct file *filp, unsigned int cmd,
return put_user(i_size_read(inode) - filp->f_pos, p);
}
- return do_ioctl(filp, cmd, arg);
+ return vfs_ioctl(filp, cmd, arg);
}
/*
* When you add any new common ioctls to the switches above and below
* please update compat_sys_ioctl() too.
*
- * vfs_ioctl() is not for drivers and not intended to be EXPORT_SYMBOL()'d.
+ * do_ioctl() is not for drivers and not intended to be EXPORT_SYMBOL()'d.
* It's just a simple helper for sys_ioctl and compat_sys_ioctl.
*/
-int vfs_ioctl(struct file *filp, unsigned int fd, unsigned int cmd,
- unsigned long arg)
+int do_ioctl(struct file *filp, unsigned int fd, unsigned int cmd,
+unsigned long arg)
{
unsigned int flag;
int on, error = 0;
@@ -152,7 +166,7 @@ int vfs_ioctl(struct file *filp, unsigned int fd, unsigned
int cmd,
if (S_ISREG(filp->f_path.dentry->d_inode->i_mode))
error = file_ioctl(filp, cmd, arg);
else
- error = do_ioctl(filp, cmd, arg);
+ error = vfs_ioctl(filp, cmd, arg);
break;
}
return error;
@@ -172,7 +186,7 @@ asmlinkage long sys_ioctl(unsigned int fd, unsigned int
cmd, unsigned long arg)
if (error)
goto out_fput;
- error = vfs_ioctl(filp, fd, cmd, arg);
+ error = do_ioctl(filp, fd, cmd, arg);
out_fput:
fput_light(filp, fput_needed);
out:
diff --git a/include/linux/fs.h b/include/linux/fs.h
index b3ec4a4..c0c5d36 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -1924,7 +1924,8 @@ extern int vfs_stat_fd(int dfd, char __user *, struct
kstat *);
extern int vfs_lstat_fd(int dfd, char __user *, struct kstat *);
extern int vfs_fstat(unsigned int, struct kstat *);
-extern int vfs_ioctl(struct file *, unsigned int, unsigned int, unsigned long);
+extern long vfs_ioctl(struct file *filp, unsigned int cmd, unsigned long arg);
+extern int do_ioctl(struct file *, unsigned int, unsigned int, unsigned long);
extern void get_filesystem(struct file_system_type *fs);
extern void put_filesystem(struct file_system_type *fs);
--
1.5.2.2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 4/4] Unionfs: use vfs_ioctl
Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
---
fs/unionfs/commonfops.c | 32 ++--
1 files changed, 6 insertions(+), 26 deletions(-)
diff --git a/fs/unionfs/commonfops.c b/fs/unionfs/commonfops.c
index 50e5775..c99b519 100644
--- a/fs/unionfs/commonfops.c
+++ b/fs/unionfs/commonfops.c
@@ -661,31 +661,6 @@ out:
return err;
}
-/* pass the ioctl to the lower fs */
-static long do_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
-{
- struct file *lower_file;
- int err;
-
- lower_file = unionfs_lower_file(file);
-
- err = -ENOTTY;
- if (!lower_file || !lower_file->f_op)
- goto out;
- if (lower_file->f_op->unlocked_ioctl) {
- err = lower_file->f_op->unlocked_ioctl(lower_file, cmd, arg);
- } else if (lower_file->f_op->ioctl) {
- lock_kernel();
- err = lower_file->f_op->ioctl(
- lower_file->f_path.dentry->d_inode,
- lower_file, cmd, arg);
- unlock_kernel();
- }
-
-out:
- return err;
-}
-
/*
* return to user-space the branch indices containing the file in question
*
@@ -752,6 +727,7 @@ out:
long unionfs_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
{
long err;
+ struct file *lower_file;
unionfs_read_lock(file->f_path.dentry->d_sb);
@@ -775,7 +751,11 @@ long unionfs_ioctl(struct file *file, unsigned int cmd,
unsigned long arg)
default:
/* pass the ioctl down */
- err = do_ioctl(file, cmd, arg);
+ lower_file = unionfs_lower_file(file);
+ if (lower_file)
+ err = vfs_ioctl(lower_file, cmd, arg);
+ else
+ err = -ENOTTY;
break;
}
--
1.5.2.2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 1/4] VFS: apply coding standards to fs/ioctl.c
Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
---
fs/ioctl.c | 164 +++-
1 files changed, 84 insertions(+), 80 deletions(-)
diff --git a/fs/ioctl.c b/fs/ioctl.c
index c2a773e..652cacf 100644
--- a/fs/ioctl.c
+++ b/fs/ioctl.c
@@ -12,8 +12,8 @@
#include
#include
#include
+#include
-#include
#include
static long do_ioctl(struct file *filp, unsigned int cmd,
@@ -45,31 +45,31 @@ static int file_ioctl(struct file *filp, unsigned int cmd,
{
int error;
int block;
- struct inode * inode = filp->f_path.dentry->d_inode;
+ struct inode *inode = filp->f_path.dentry->d_inode;
int __user *p = (int __user *)arg;
switch (cmd) {
- case FIBMAP:
- {
- struct address_space *mapping = filp->f_mapping;
- int res;
- /* do we support this mess? */
- if (!mapping->a_ops->bmap)
- return -EINVAL;
- if (!capable(CAP_SYS_RAWIO))
- return -EPERM;
- if ((error = get_user(block, p)) != 0)
- return error;
-
- lock_kernel();
- res = mapping->a_ops->bmap(mapping, block);
- unlock_kernel();
- return put_user(res, p);
- }
- case FIGETBSZ:
- return put_user(inode->i_sb->s_blocksize, p);
- case FIONREAD:
- return put_user(i_size_read(inode) - filp->f_pos, p);
+ case FIBMAP:
+ {
+ struct address_space *mapping = filp->f_mapping;
+ int res;
+ /* do we support this mess? */
+ if (!mapping->a_ops->bmap)
+ return -EINVAL;
+ if (!capable(CAP_SYS_RAWIO))
+ return -EPERM;
+ error = get_user(block, p);
+ if (error)
+ return error;
+ lock_kernel();
+ res = mapping->a_ops->bmap(mapping, block);
+ unlock_kernel();
+ return put_user(res, p);
+ }
+ case FIGETBSZ:
+ return put_user(inode->i_sb->s_blocksize, p);
+ case FIONREAD:
+ return put_user(i_size_read(inode) - filp->f_pos, p);
}
return do_ioctl(filp, cmd, arg);
@@ -82,81 +82,85 @@ static int file_ioctl(struct file *filp, unsigned int cmd,
* vfs_ioctl() is not for drivers and not intended to be EXPORT_SYMBOL()'d.
* It's just a simple helper for sys_ioctl and compat_sys_ioctl.
*/
-int vfs_ioctl(struct file *filp, unsigned int fd, unsigned int cmd, unsigned
long arg)
+int vfs_ioctl(struct file *filp, unsigned int fd, unsigned int cmd,
+ unsigned long arg)
{
unsigned int flag;
int on, error = 0;
switch (cmd) {
- case FIOCLEX:
- set_close_on_exec(fd, 1);
- break;
+ case FIOCLEX:
+ set_close_on_exec(fd, 1);
+ break;
- case FIONCLEX:
- set_close_on_exec(fd, 0);
- break;
+ case FIONCLEX:
+ set_close_on_exec(fd, 0);
+ break;
- case FIONBIO:
- if ((error = get_user(on, (int __user *)arg)) != 0)
- break;
- flag = O_NONBLOCK;
+ case FIONBIO:
+ error = get_user(on, (int __user *)arg);
+ if (error)
+ break;
+ flag = O_NONBLOCK;
#ifdef __sparc__
- /* SunOS compatibility item. */
- if(O_NONBLOCK != O_NDELAY)
- flag |= O_NDELAY;
+ /* SunOS compatibility item. */
+ if (O_NONBLOCK != O_NDELAY)
+ flag |= O_NDELAY;
#endif
- if (on)
- filp->f_flags |= flag;
- else
- filp->f_flags &= ~flag;
+ if (on)
+ filp->f_flags |= flag;
+ else
+ filp->f_flags &= ~flag;
+ break;
+
+ case FIOASYNC:
+ error = get_user(on, (int __user *)arg);
+ if (error)
break;
-
- case FIOASYNC:
- if ((error = get_user(on, (int __user *)arg)) != 0)
- break;
- flag = on ? FASYNC : 0;
-
- /* Did FASYNC state change ? */
- if ((flag ^ filp->f_flags) & FASYNC) {
- if (filp->f_op && filp->f_op->fasync) {
-
[PATCH 3/4] VFS: factor out three helpers for FIBMAP/FIONBIO/FIOASYNC file ioctls
Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
---
fs/ioctl.c | 128 ++-
1 files changed, 74 insertions(+), 54 deletions(-)
diff --git a/fs/ioctl.c b/fs/ioctl.c
index 34e3f58..8dd2ef1 100644
--- a/fs/ioctl.c
+++ b/fs/ioctl.c
@@ -54,32 +54,34 @@ long vfs_ioctl(struct file *filp, unsigned int cmd,
}
EXPORT_SYMBOL_GPL(vfs_ioctl);
+static int __ioctl_fibmap(struct file *filp, int __user *p)
+{
+ struct address_space *mapping = filp->f_mapping;
+ int res, block;
+
+ /* do we support this mess? */
+ if (!mapping->a_ops->bmap)
+ return -EINVAL;
+ if (!capable(CAP_SYS_RAWIO))
+ return -EPERM;
+ res = get_user(block, p);
+ if (res)
+ return res;
+ lock_kernel();
+ res = mapping->a_ops->bmap(mapping, block);
+ unlock_kernel();
+ return put_user(res, p);
+}
+
static int file_ioctl(struct file *filp, unsigned int cmd,
unsigned long arg)
{
- int error;
- int block;
struct inode *inode = filp->f_path.dentry->d_inode;
int __user *p = (int __user *)arg;
switch (cmd) {
case FIBMAP:
- {
- struct address_space *mapping = filp->f_mapping;
- int res;
- /* do we support this mess? */
- if (!mapping->a_ops->bmap)
- return -EINVAL;
- if (!capable(CAP_SYS_RAWIO))
- return -EPERM;
- error = get_user(block, p);
- if (error)
- return error;
- lock_kernel();
- res = mapping->a_ops->bmap(mapping, block);
- unlock_kernel();
- return put_user(res, p);
- }
+ return __ioctl_fibmap(filp, p);
case FIGETBSZ:
return put_user(inode->i_sb->s_blocksize, p);
case FIONREAD:
@@ -89,6 +91,57 @@ static int file_ioctl(struct file *filp, unsigned int cmd,
return vfs_ioctl(filp, cmd, arg);
}
+static int __ioctl_fionbio(struct file *filp, unsigned long arg)
+{
+ unsigned int flag;
+ int on, error;
+
+ error = get_user(on, (int __user *)arg);
+ if (error)
+ return error;
+ flag = O_NONBLOCK;
+#ifdef __sparc__
+ /* SunOS compatibility item. */
+ if (O_NONBLOCK != O_NDELAY)
+ flag |= O_NDELAY;
+#endif
+ if (on)
+ filp->f_flags |= flag;
+ else
+ filp->f_flags &= ~flag;
+ return error;
+}
+
+static int __ioctl_fioasync(unsigned int fd, struct file *filp,
+ unsigned long arg)
+{
+ unsigned int flag;
+ int on, error;
+
+ error = get_user(on, (int __user *)arg);
+ if (error)
+ return error;
+ flag = on ? FASYNC : 0;
+
+ /* Did FASYNC state change ? */
+ if ((flag ^ filp->f_flags) & FASYNC) {
+ if (filp->f_op && filp->f_op->fasync) {
+ lock_kernel();
+ error = filp->f_op->fasync(fd, filp, on);
+ unlock_kernel();
+ } else
+ error = -ENOTTY;
+ }
+ if (error)
+ return error;
+
+ if (on)
+ filp->f_flags |= FASYNC;
+ else
+ filp->f_flags &= ~FASYNC;
+ return error;
+}
+
/*
* When you add any new common ioctls to the switches above and below
* please update compat_sys_ioctl() too.
@@ -99,8 +152,7 @@ static int file_ioctl(struct file *filp, unsigned int cmd,
int do_ioctl(struct file *filp, unsigned int fd, unsigned int cmd,
unsigned long arg)
{
- unsigned int flag;
- int on, error = 0;
+ int error = 0;
switch (cmd) {
case FIOCLEX:
@@ -112,43 +164,11 @@ int do_ioctl(struct file *filp, unsigned int fd, unsigned
int cmd,
break;
case FIONBIO:
- error = get_user(on, (int __user *)arg);
- if (error)
- break;
- flag = O_NONBLOCK;
-#ifdef __sparc__
- /* SunOS compatibility item. */
- if (O_NONBLOCK != O_NDELAY)
- flag |= O_NDELAY;
-#endif
- if (on)
- filp->f_flags |= flag;
- else
- filp->f_flags &= ~flag;
+ error = __ioctl_fionbio(filp, arg);
break;
case FIOASYNC:
- error = get_user(on, (int __user *)arg);
- if (error)
- break;
- flag = on ? FASYNC : 0;
-
- /* Did FASYNC state change ? */
- if ((flag ^ filp->f_flags) & FASYNC) {
- if (filp->f_op && filp->f_op->fasync) {
- lock_kernel();
- error =
[PATCH] 0/4 fs/ioctl.c coding style, rename vfs_ioctl/do_ioctl, refactoring (take 2)
This series of 4 proposed patches changes fs/ioctl.c and Unionfs as follows. This series is against v2.6.24-rc1-192-gef49c32. Patch 1: just applies coding standards to fs/ioctl.c (while I'm at it, I figured it's worth cleaning VFS files one at a time). Patch 2: does two things: (a) Renames the old vfs_ioctl to do_ioctl, because the comment above it clearly indicates that it is an internal function not to be exported to modules; therefore it should have a more traditional do_XXX "internal function" name. The new do_ioctl is exported in fs.h but not to modules. (b) Renames the old (static) do_ioctl to vfs_ioctl because the names vfs_XXX should preferably be reserved to callable VFS functions which modules may call, as other vfs_XXX functions already do. Export the new vfs_ioctl to (GPL) modules so others can use it (including Unionfs and eCryptfs). Patch 3: factors out the switch statements' cases for FIBMAP/FIONBIO/FIOASYNC, into three small static helper functions. Patch 4: demonstrates how Unionfs can use the new vfs_ioctl. I successfully tested unionfs with this new exported vfs_ioctl. (eCryptfs could do the same.) I'd like to propose that the first 3 patches be merged in -mm and even mainline, pending review. Erez Zadok (4): VFS: apply coding standards to fs/ioctl.c VFS: swap do_ioctl and vfs_ioctl names VFS: factor out three helpers for FIBMAP/FIONBIO/FIOASYNC file ioctls Unionfs: use vfs_ioctl fs/compat_ioctl.c |2 fs/ioctl.c | 224 fs/unionfs/commonfops.c | 32 +- include/linux/fs.h |3 4 files changed, 140 insertions(+), 121 deletions(-) Cheers, Erez. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: aim7 -30% regression in 2.6.24-rc1
On Fri, 2007-10-26 at 11:53 +0200, Peter Zijlstra wrote: > On Fri, 2007-10-26 at 17:43 +0800, Zhang, Yanmin wrote: > > I tested 2.6.24-rc1 on my x86_64 machine which has 2 quad-core processors. > > > > Comparing with 2.6.23, aim7 has about -30% regression. I did a bisect and > > found > > patch > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b5869ce7f68b233ceb81465a7644be0d9a5f3dbb > > caused the issue. > > Bit weird that you point to a merge commit, and not an actual patch. Are > you sure git bisect pointed at this one? When I did a bisect, kernel couldn't boot and my testing log showed it's at b5869ce7f68b233ceb81465a7644be0d9a5f3dbb. So I did a manual checkout. #git clone ... #git pull ... #git checkout b5869ce7f68b233ceb81465a7644be0d9a5f3dbb Then, compiled kernel and tested it. Then, reversed above patch and recompiled/retested it. If I ran git log, I could see this tag in the list. -yanmin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 v2] pcmcia: Remove replace kio_addr_t with unsigned int everywhere
On Mon, Oct 29, 2007 at 10:50:05AM +1100, Stephen Rothwell wrote: > Hi Olof, > > diffstat output is very useful - especially for patches like this that > touch lots of files. It makes it easier for potential reviewers to see > if they should be potential reviewers. :-) Hi, Good point. I'll include it next time if I end up re-posting it. I hope I won't have to. :-) This is the diffstat from the posted patch: Documentation/pcmcia/driver-changes.txt |4 +- drivers/bluetooth/bt3c_cs.c |2 - drivers/bluetooth/btuart_cs.c |2 - drivers/net/pcmcia/3c574_cs.c | 49 - drivers/net/pcmcia/3c589_cs.c | 30 +++ drivers/net/pcmcia/axnet_cs.c | 26 ++--- drivers/net/pcmcia/fmvj18x_cs.c | 23 ++- drivers/net/pcmcia/nmclan_cs.c | 24 ++-- drivers/net/pcmcia/pcnet_cs.c | 36 +- drivers/net/pcmcia/smc91c92_cs.c| 62 drivers/net/pcmcia/xirc2ps_cs.c | 51 +- drivers/net/wireless/netwave_cs.c | 24 ++-- drivers/net/wireless/wavelan_cs.c | 56 ++-- drivers/pcmcia/i82092.c |2 - drivers/pcmcia/i82365.c | 14 +++ drivers/pcmcia/m32r_cfc.c |7 ++- drivers/pcmcia/m32r_pcc.c |5 +- drivers/pcmcia/rsrc_nonstatic.c |5 +- drivers/serial/serial_cs.c |6 +-- include/pcmcia/cs_types.h |1 include/pcmcia/ss.h |6 +-- 21 files changed, 220 insertions(+), 215 deletions(-) -Olof - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[REGRESSION] 2.6.24-rc1 fails to boot on a 486
My old 486 fails to boot with the 2.6.24-rc1 kernel. Grub loads it, 4 lines of text appear but not the kernel's "Linux version greet", and the machine reboots. Double-checked with a serial console: nothing appears before it reboots. All 2.6 kernels up to 2.6.23 worked fine on this machine. Config is at http://user.it.uu.se/~mikpe/linux/tmp/486-config-2.6.24-rc1. The kernel is unpatched 2.6.24-rc1 compiled with gcc-4.2.2. /Mikael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)
On 10/29/07, Crispin Cowan <[EMAIL PROTECTED]> wrote: > To reject an LSM for providing "bad" security, IMHO you should have to > show how it is possible to subvert the self-stated goals of that LSM. > Complaints that the LSM fails to meet some goal outside of its stated > purpose is irrelevant. Conjecture that it probably can be violated > because of $contrivance is just so much FUD. LSM is providing bad security on two fronts. Number 1 LSM are speeding effort to create features. Apparmor and Selinux both provide file access filtering from applications. Yet they double up the code to do it. So they cannot be used with each other without doubling up hooks. Then other LSM are creating there own sections of code to do the same thing. Simple rule more code more risk of bugs since it will be less audited. Duplication defense features is really bad for security. Some how code sharing has to be got into LSM construction. Number 2 The critical bit LSM stop at the edges of applications. Now without overlapping my hooks with existing LSMs I cannot create application level protections. Overlapping hooks will cause speed loss. LSM is set to protect the application. But inside the application there will be sections that need the access rights and others that don't. Now a exploit in any section of the application under LSM gets the LSM assigned rights. With application level this can be done a few ways extension to elf that is create by the complier and api calls lowering access functions of current thread or for a starting thread. If you exploit a section of the code without access to disk network access and so on and without the right to call any function that does that. What have you exploited. Minor data damage compared to complete data that the application have access to being stolen as what is the case with LSM at moment. Basically LSM prevent taking control of the complete system but don't help to stop peoples private data from being stolen. Both are bad to happen to a person. LSM design is there to help security development not get in its way or to cause bitrot. Currently LSM design is causing major risk bitrot in duplicated code. Reading and processing configuration files should be independent to the protection methods. Hopefully designed to be able to run user mode to test if the new profile for a application is safe to add before adding it to the OS. Typo prevention on both sides. Current method of just sticking everything into one huge blob is preventing code sharing and risking more security holes. The current LSM design is bad on so many levels. I am surprised that it takes a Non PHD System Admin to see it. Some how I think its a empire thing. If everything was just simple blocks a person could write a new LSM in hours with pretty good security. Compared to todays long time trying effort. Leads of Apparmor selinux and so on not being prepared to give up there little empire for the greater good. I personally hate stacking as a idea. I personally prefer two layers only. Config reading and enforcement. Of course that does not stop applications being assigned to different config reading systems. Depth the two layers should stay fixed even if you have many different models in use. All LSM seam to want to force System Admins to pick there LSM over another. Instead of being able to pick LSM for task at hand. Same with poor security being better than no security its true. Its nothing strange to find selinux based systems with there security disabled because the Admin cannot configure it. But the reverse is also true that when you have skilled Admins stuck with a system like Apparmor cannot harden the system as far as they could with selinux. Both ways its causing security holes poor security when you should have good security is bad too. Part of the problem LSM maintainers are not at the front lines is all I can guess. Because they don't seam to know what is really needed. Peter Dolding - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 v2] pcmcia: Remove replace kio_addr_t with unsigned int everywhere
Hi Olof, diffstat output is very useful - especially for patches like this that touch lots of files. It makes it easier for potential reviewers to see if they should be potential reviewers. :-) -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpKBhmpDlgYr.pgp Description: PGP signature
Re: [patch 2/2] cpusets: add interleave_over_allowed option
David wrote: > From a standpoint of the MPOL_PREFERRED memory policy itself, there > is no documented behavior or standard that specifies its interaction > with cpusets. Thus, it's "undefined." We are completely free > to implement an undefined behavior as we choose and change it as > Linux matures. You state this point clearly, but I have to disagree. The Linux documentation is not a legal contract. Anytime we change the actual behaviour of the code, we have to ask ourselves what will be the impact of that change on existing users and usages. The burden is on us to minimize breaking things (by that I mean, what users would consider breakage, even if we think it is all for the better and that their code was the real problem.) I didn't say no breakage, but minimum breakage, doing our best to guide users through changes with minimum disruption to their work. Linux is gaining market share rapidly because we co-operate with our users to give us both the best chance of succeeding. We don't just play gotcha games with the documentation -- ha ha -- we didn't document that detail, so it's your fault for ever depending on it. And besides your code sucks. So there! Let's leave that game for others. > And you're trying to protect this application that based this > implementation not on a standard or documentation, but on its observed > behavior. Yes, if there is such an application, I'm trying to protect it. > My bet is that it's going to issue that subsequent > set_mempolicy(), at least if libnuma returned a numa_preferred() value > that it wasn't expecting. Perhaps. Perhaps not. I don't know. > That still requires a change to the application. If that were so, then yes much of your subsequent reasoning would follow. However, let me repeat the following from my previous message: > However, in deference to the needs of libnuma, if the following > call was made, this would change the mode for that task to > Choice A: > > get_mempolicy(NULL, NULL, 0, 0, 0); > > This last detail above is an admitted hack. *So far as I know* > it happens that all current infield versions of libnuma issue the > above call, as their first mempolicy query, to detemine whether > the active kernel supports mempolicy. The above is the hack that allows us to support existing libnuma based applications (the most significant users of memory policy historically) with a default of Choice A, while other code and future code defaults to Choice B. > See? The problem is that you're trying to protect applications that know > its initial cpuset mems [the only way it could ever send a > set_mempolicy(MPOL_PREFERRED) for the right node in that range in the > first place] but then seemingly loses control over its cpuset and intends > for the kernel to fix it up for it without having the burden of issuing > another set_mempolicy() call. That's not the only sort of application I'm trying to protect. I'm trying to protect almost any application that uses both set_mempolicy or mbind, while in a cpuset. If a task is in a cpuset on say nodes 16-23, and it wants to issue any mbind, or any MPOL_PREFERRED, MPOL_BIND, or MPOL_INTERLEAVE mempolicy call, then under Choice A it must issue nodemasks offset by 16, relative to what it would issue under Choice B. Almost any task using memory policies on a system making active use of cpusets will be affected, even well written ones doing simple things. I am more concerned that the above hack for libnuma isn't enough, rather than it is unnecessary. I think the above hack covers existing libnuma users rather well, though I could be wrong even here, as I don't actually work with most of the existing libnuma users. And I can cover those using both memory policies and cpusets via libcpuset, as there I am the expert and know that I can guide libcpuset and its users through this change. There will be some breakage, but I know how to manage it. However, if anyone is deploying product or has important (to them) but not easy to change software using both memory policies and cpusets that are not doing so via libnuma or libcpuset, then any change that changes the default for their memory policy calls from Choice A to Choice B will probably break them. Perhaps there are no significant cases like this, using memory policies on cpuset managed systems, but not via libnuma or libcpuset. It might be that the only way to smoke out such cases is to ship the change (to Choice B default) and see what squawks. That kinda sucks. I'm tempted to think I need to go a bit further: 1) Add a per-system or per-cpuset runtime mode, to enable a system administrator to revert to the Choice A default. 2) Make sure that both the new libnuma and libcpuset versions dynamically probe the state of this default, and dynamically adapt to running on a kernel, or in a cpuset, of either default. If this mode is per-cpuset, then so long as there are not
Re: [RFC, PATCH] locks: remove posix deadlock detection
On Sun, 28 Oct 2007 17:38:14 -0600 Matthew Wilcox <[EMAIL PROTECTED]> wrote: > On Sun, Oct 28, 2007 at 09:38:55PM +, Alan Cox wrote: > > > It doesn't require the system to detect it, only mandate what to return > > > if it does detect it. > > > > We should be detecting at least the obvious case. > > What is the obvious case? A task that has never called clone()? Simple AB BA I would have thought obvious. Clone as has been said several times now is irrelevant as the standard is about *processes* [in the SuS sense] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] locks: remove posix deadlock detection
On Sun, Oct 28, 2007 at 09:38:55PM +, Alan Cox wrote: > > It doesn't require the system to detect it, only mandate what to return > > if it does detect it. > > We should be detecting at least the obvious case. What is the obvious case? A task that has never called clone()? > If SYSV only spots simple AB - BA deadlocks or taking the same lock twice > yourself then that ought to be sufficient for us too. You can't deadlock against yourself -- either with POSIX locks or BSD locks (POSIX simple upgrades/downgrades the lock; each byte in a file can only be in either read-locked state or write-locked state for a given process. BSD locks release the lock and wake all waiters before attempting to acquire the lock in its new state). In my other post, I showed a simple AB-BA deadlock that can't be easily detected. -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] locks: remove posix deadlock detection
> > The spec and SYSV certainly ignore threading in this situation and you > > know that perfectly well (or did in 2004) > > The discussion petered out (or that mailing list archive lost articles > from the thread) without any kind of resolution, or indeed interest. I think the resolution was that the EDEADLK stayed. > What is your suggestion for handling this problem? As it is now, the > kernel 'detects' deadlock where there is none, which doesn't seem > allowed by SuSv3 either Re-read the spec. The EDEADLK doesn't account for threads, only processes. 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: [RFC, PATCH] locks: remove posix deadlock detection
On Sun, Oct 28, 2007 at 11:55:52PM +0100, Jiri Kosina wrote: > On Sun, 28 Oct 2007, Matthew Wilcox wrote: > > > Bzzt. You get a false deadlock with multiple threads like so: > > Thread A of task B takes lock 1 > > Thread C of task D takes lock 2 > > Thread C of task D blocks on lock 1 > > Thread E of task B blocks on lock 2 > > A potential for deadlock occurs if a process controlling a locked > region is put to sleep by attempting to lock another process' > locked region. If the system detects that sleeping until a locked > region is unlocked would cause a deadlock, fcntl() shall fail with > an [EDEADLK] error. > > This is what POSIX says [1], even after being modified with respect to > POSIX Threads Extension, right? > > So it doesn't deal with threads at all, just processess are taken into > account. Probably for a reason :) Did you have a concrete suggestion, or are you just quoting the spec? The problem is that it's nonsense -- processes don't sleep, threads do. I think the key is "would deadlock", not "might deadlock". Our current behaviour is clearly in violation of SuSv3. -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] I8K: Allow i8k driver to be built on x86_64 systems
On Sun, 28 Oct 2007 18:37:24 +0100
Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> Please use CONFIG_X86_64.
>
> cu
> Adrian
>
Now uses CONFIG_X86_64.
Brad.
--- linux-2.6/drivers/char/i8k.c.orig 2007-10-28 12:27:34.0 +
+++ linux-2.6/drivers/char/i8k.c2007-10-28 14:27:56.0 +
@@ -113,6 +113,33 @@ static int i8k_smm(struct smm_regs *regs
int rc;
int eax = regs->eax;
+#if defined(CONFIG_X86_64)
+ asm("pushq %%rax\n\t"
+ "movl 0(%%rax),%%edx\n\t"
+ "pushq %%rdx\n\t"
+ "movl 4(%%rax),%%ebx\n\t"
+ "movl 8(%%rax),%%ecx\n\t"
+ "movl 12(%%rax),%%edx\n\t"
+ "movl 16(%%rax),%%esi\n\t"
+ "movl 20(%%rax),%%edi\n\t"
+ "popq %%rax\n\t"
+ "out %%al,$0xb2\n\t"
+ "out %%al,$0x84\n\t"
+ "xchgq %%rax,(%%rsp)\n\t"
+ "movl %%ebx,4(%%rax)\n\t"
+ "movl %%ecx,8(%%rax)\n\t"
+ "movl %%edx,12(%%rax)\n\t"
+ "movl %%esi,16(%%rax)\n\t"
+ "movl %%edi,20(%%rax)\n\t"
+ "popq %%rdx\n\t"
+ "movl %%edx,0(%%rax)\n\t"
+ "lahf\n\t"
+ "shrl $8,%%eax\n\t"
+ "andl $1,%%eax\n"
+ :"=a"(rc)
+ :"a"(regs)
+ :"%ebx", "%ecx", "%edx", "%esi", "%edi", "memory");
+#else
asm("pushl %%eax\n\t"
"movl 0(%%eax),%%edx\n\t"
"push %%edx\n\t"
@@ -137,7 +164,7 @@ static int i8k_smm(struct smm_regs *regs
"andl $1,%%eax\n":"=a"(rc)
:"a"(regs)
:"%ebx", "%ecx", "%edx", "%esi", "%edi", "memory");
-
+#endif
if (rc != 0 || (regs->eax & 0x) == 0x || regs->eax == eax)
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/
Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)
> To reject an LSM for providing "bad" security, IMHO you should have to > show how it is possible to subvert the self-stated goals of that LSM. > Complaints that the LSM fails to meet some goal outside of its stated > purpose is irrelevant. Conjecture that it probably can be violated > because of $contrivance is just so much FUD. That seems to be an appropriate test. > Exception: it is valid to say that the self-stated goal is too narrow to > be useful. But IMHO that bar of "too narrow" should be very, very low. > Defenses against specific modes of attack would be a fine thing to build > up in the library of LSMs, especially if we got a decent stacking module > so that they could be composed. Once you have stacking then it actually at times will make sense to have security modules that do one very precise thing and do it well. 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] Dell laptop backlight driver
Matt Domsch wrote: On Sun, Oct 28, 2007 at 07:06:23PM +0100, [EMAIL PROTECTED] wrote: Matt Domsch wrote: On Sun, Oct 28, 2007 at 05:12:37PM +0100, [EMAIL PROTECTED] wrote: Hello, this driver implements backlight control on Dell laptops which use SMI for changing brightness levels. The driver is INCOMPLETE since it is unable to probe some required parameters in order to perform backlight control. Such parameters are found in a Dell proprietary DMI table which should be parsed. For now external tools may be used to find these parameters by hand. So if you intend to try this out, FIRST write your laptop model parameters correctly inside the source code as explained in Documentation/dell-laptop.txt. Parts of this driver may also be used to provide additional functionalities similarly to the drivers/misc/*-laptop.c drivers. Why is this better done in the kernel rather than in userspace with libsmbios as you've noted? I had to do a kernelspace driver for controlling the backlight. This was part of a college project assignment. In order for it to be valid for an operating system course, it had to be in kernelspace (not Unix programming) :). As i mentioned that can be done in userspace and it IS sensible to do so. I know that the code which was already written for Dell implied a userspace approach, but i simply had no choice. I also don't expect this driver to become mainstream, but since i have written it, other people might want to have a look at it. OK, that's fair. Finally i really don't think there's any sensible way of implementing Linux LCD Backlight Abstraction relying on a userspace application. That would mean the kernel calling userspace code to change the brightness, then this latter code would again call the kernel to trigger a SMI and so on. That's just not a good design. I think a userspace solution implies choosing NOT to implement the LCD Abstraction. Causing Dell laptops to be treated differently from other machines (as they are not compliant with Linux's own interface). I've had this discussion on lkml before. Short story is, until Dell laptops implement the ACPI methods that the backlight API expects, the only sane way to do it is to let libsmbios handle it. Moving the fairly large and complex libsmbios into the kernel isn't a good idea (imho). I agree. The problem is that Dell's DMI tables are not defined in the SMBIOS standard. Thus getting the parameters required for the backlight control (io port, io code, location) needs to be dealt with specifically. Plus DMI is not as comprehensively supported as ACPI is under Linux. I think reading Dell's tables to find out backlight parameters in kernelspace is possible. Unfortunately it would require a significant amount of brand new code to be written. And i'm not sure it is worth the effort. Libsmbios is big and complex because it is written in proficient C++ with lots of OO abstraction. It is also portable. But the task accomplished is simple in principle. jacopo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: VIA VT6307 OHCI version?
Krzysztof Halasa wrote: > Stefan Richter <[EMAIL PROTECTED]> writes: >> # ./a.out 00:0a.3 >> I/O region #1 is at C800 >> It seems your VT6307 chip is connected to 93c46 EEPROM > > Interesting, really. Perhaps they aimed at I2C too with 9306 but > screwed up the silicon? Would have to look at the pinout but for > now I'm sick and high fever makes it hard. > > It's all consistent, amazingly. > > 6306#1 >> 00: 00 11 06 00 00 00 E3 32 00 88 00 08 44 00 00 00 >> 10: A1 E4 2F 00 06 11 44 30 03 DF 40 00 00 20 00 73 >> 20: 3C 10 00 00 00 00 FF FF FF FF FF FF D7 57 55 75 > > Obviously some values are different than these for my 3 vt6307 > (not counting GUID + PCI sub IDs). Though data at 0x20+ is equal. > > The last 4 bytes are almost certainly rubbish, that asks the question > if the contents hasn't been changed through some tests, works on > the drivers etc, or if the manufacturer did it right (for example > I somehow managed to clear the GUID on I^2C version before I had the > code to write to it, quite a mystery (writing correct I^2C sequence > for it isn't trivial due to the need of non-all-zeros DEVSEL byte > preceded by the start sequence). > > I wonder if the EEPROM has more non-FF data? IIRC the chips addresses > 0x80 bytes, or maybe 0x100? I limited it to 0x40 in the code because > the rest is never read by the chip, except if requested by the user. > (For 93c46 the program could read any location directly but I didn't > implement that). This device is a somewhat buggy PCI card which somebody sent me after unsuccessful attempts to get it properly working under Linux. Among more serious trouble, ohci1394 reads a bogus maximum async payload (a zero value) from the BusOptions register during startup. This has occasionally been reported for some VT6306 in the past. I haven't really tested this card myself yet, it's currently stuck in a PC which I don't use anymore. Bad VT6306 card: PCI: Found IRQ 11 for device :00:0a.3 PCI: Sharing IRQ 11 with :00:0a.0 PCI: Sharing IRQ 11 with :00:10.1 ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[11] MMIO=[ec101000-ec1017ff] Max Packet=[2] IR/IT contexts=[4/8] ohci1394: fw-host0: Serial EEPROM has suspicious values, attempting to set max_packet_size to 512 bytes ieee1394: Host added: ID:BUS[0-00:1023] GUID[00110600e332] VT6306 onboard controller: PCI: setting IRQ 5 as level-triggered PCI: Found IRQ 5 for device :00:0c.0 PCI: Sharing IRQ 5 with :00:0a.2 ohci1394: fw-host1: OHCI-1394 1.0 (PCI): IRQ=[5] MMIO=[ec103000-ec1037ff] Max Packet=[2048] IR/IT contexts=[8/8] ieee1394: Host added: ID:BUS[1-00:1023] GUID[00301bac2ba4] VT6306 CardBus card in my main PC: ACPI: PCI Interrupt :06:00.0[A] -> GSI 17 (level, low) -> IRQ 18 ohci1394: fw-host2: OHCI-1394 1.0 (PCI): IRQ=[18] MMIO=[8000-87ff] Max Packet=[1024] IR/IT contexts=[4/8] ieee1394: Host added: ID:BUS[2-00:1023] GUID[0011060041cc] The Max Packet value of the CardBus card is OK; all CardBus cards seem to have this limitation regardless of their link layer chip. I wonder what's up with the varying number of IR contexts. The datasheet talks about 8 IR contexts and 8 IR context registers, but also has a sentence "These registers are Context Control registers for isochronous Receive Contexts 0-3" which may be an editorial error. -- 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/
[PATCH] Allow auto-destruction of loop devices.
This allows a flag to be set on loop devices so that when they are
closed for the last time, they'll self-destruct.
Signed-off-by: David Woodhouse <[EMAIL PROTECTED]>
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index 56e2304..7fae828 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -973,6 +973,10 @@ loop_set_status(struct loop_device *lo, const struct
loop_info64 *info)
lo->transfer = xfer->transfer;
lo->ioctl = xfer->ioctl;
+ if ( (lo->lo_flags & LO_FLAGS_AUTOCLEAR) !=
+(info->lo_flags & LO_FLAGS_AUTOCLEAR))
+ lo->lo_flags ^= LO_FLAGS_AUTOCLEAR;
+
lo->lo_encrypt_key_size = info->lo_encrypt_key_size;
lo->lo_init[0] = info->lo_init[0];
lo->lo_init[1] = info->lo_init[1];
@@ -1331,6 +1335,10 @@ static int lo_release(struct inode *inode, struct file
*file)
mutex_lock(>lo_ctl_mutex);
--lo->lo_refcnt;
+
+ if ((lo->lo_flags & LO_FLAGS_AUTOCLEAR) && !lo->lo_refcnt)
+ loop_clr_fd(lo, inode->i_bdev);
+
mutex_unlock(>lo_ctl_mutex);
return 0;
diff --git a/include/linux/loop.h b/include/linux/loop.h
index 26a0a10..46169a7 100644
--- a/include/linux/loop.h
+++ b/include/linux/loop.h
@@ -76,6 +76,7 @@ struct loop_device {
enum {
LO_FLAGS_READ_ONLY = 1,
LO_FLAGS_USE_AOPS = 2,
+ LO_FLAGS_AUTOCLEAR = 4,
};
#include/* for __kernel_old_dev_t */
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc1-git4: Reported regressions from 2.6.23
On Sunday, 28 October 2007 23:53, Alan Cox wrote: > > Subject : 2.6.24-rc1: pata_acpi fails to activate DMA for > > DVD-ROM on ALi M5229 secondary channel > > Submitter : Andrey Borzenkov <[EMAIL PROTECTED]> > > References : http://marc.info/?l=linux-kernel=119342005216716=2 > > http://bugzilla.kernel.org/show_bug.cgi?id=9252 > > Handled-By : Alan Cox <[EMAIL PROTECTED]> > > 2.6.23 did not have pata_acpi. Its also not clear this is a bug in > pata_acpi as opposed to pata_ali which knows about the ALi quirks. The > ACPI and ATA specs sort of disagree here so I'll be trying to fix it > anyway. OK, but please let me keep that on the list. It may cause some people to experience problems that were not present before functionality-wise. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.24-rc1-git4: Reported regressions from 2.6.23
On Sunday, 28 October 2007 23:48, Frans Pop wrote: > The regression in process CPU usage display in top is still there: > http://bugzilla.kernel.org/show_bug.cgi?id=9135 > > It's a regression from .22, not from .23, but I guess it should still be > listed. Well, my intention is to list the most recent regressions in these messages. Your regression is in the bugzilla, is marked as a regression and linked to the appropriate meta bug entry ... Well, perhaps I'll be able to send a "post 2.6.22 regressions" message with a longer list from time to time, but I can't promise that. Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] locks: remove posix deadlock detection
On Sun, 28 Oct 2007, Matthew Wilcox wrote: > Bzzt. You get a false deadlock with multiple threads like so: > Thread A of task B takes lock 1 > Thread C of task D takes lock 2 > Thread C of task D blocks on lock 1 > Thread E of task B blocks on lock 2 A potential for deadlock occurs if a process controlling a locked region is put to sleep by attempting to lock another process' locked region. If the system detects that sleeping until a locked region is unlocked would cause a deadlock, fcntl() shall fail with an [EDEADLK] error. This is what POSIX says [1], even after being modified with respect to POSIX Threads Extension, right? So it doesn't deal with threads at all, just processess are taken into account. Probably for a reason :) [1] http://www.opengroup.org/onlinepubs/009695399/functions/fcntl.html -- Jiri Kosina - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] locks: remove posix deadlock detection
On Sun, Oct 28, 2007 at 10:48:33PM +, Alan Cox wrote: > > Bzzt. You get a false deadlock with multiple threads like so: > > > > Thread A of task B takes lock 1 > > Thread C of task D takes lock 2 > > Thread C of task D blocks on lock 1 > > Thread E of task B blocks on lock 2 > > The spec and SYSV certainly ignore threading in this situation and you > know that perfectly well (or did in 2004) The discussion petered out (or that mailing list archive lost articles from the thread) without any kind of resolution, or indeed interest. What is your suggestion for handling this problem? As it is now, the kernel 'detects' deadlock where there is none, which doesn't seem allowed by SuSv3 either. -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [Bugme-new] [Bug 9217] New: CONFIG_CMDLINE doesn't pass to kernel
On Sun, Oct 28, 2007 at 10:46:47PM +, Richard Purdie wrote: > On Thu, 2007-10-25 at 22:54 +0100, Richard Purdie wrote: > > On Thu, 2007-10-25 at 13:02 -0700, Andrew Morton wrote: > > > It was in the inital report, at > > > http://bugzilla.kernel.org/show_bug.cgi?id=9217 : > > > > This is the commandline they wanted to use, not the one that was > > actually used. The one that was used should appear on the console, on > > the serial console if they have the lead or in dmesg when the device > > boots. We know it probably contained root=/dev/mtdblock2 but thats it. > > > > I'd like to confirm which commandline is appearing since if we know > > which one it is we might stand a chance of knowing where it came from, > > until then this is just a guessing game. > > There was a followup in the bugzilla: > > > I use u-boot to boot kernel. > > When kernel >=2.6.23 boot it use u-boot default bootparam: > > console=ttyS0,115200 console=tty1 root=/dev/mtdblock2 rootfstype=jffs2 > > Now I try to change it in u-boot source. > > > > kernel 2.6.22.9 change default u-boot boot params to what I set in > > CONFIG_CMDLINE But 2.6.23 and later doesn't > > So its not the standard bootloader, its one which passes an ATAG > commandline and 2.6.23 onwards uses an ATAG commandline if present > over the compiled in commandline. That statement is misleading. The kernel has _always_ used the command line passed from the boot loader in preference to the built-in command line. The thing that's changed is that the kernel how honors the value passed from the boot loader in R2 to find out where the ATAG list is - as documented since 2002 that it will eventually do. That's 5 years of warning. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
