Re: Syba 8-Port Serial Card Unidentified By Kernel
On 290, 10 17, 2007 at 06:16:58 -0400, Chris Bergeron wrote: > Andrey Panin wrote: >> >> Is it possible to connect two ports and run getty on one port and minicom >> on >> another ? We should check that UARTs are really working. >> >> > I used the on-board serial port as a known working control (after getting > it to work with the other onboard serial port) to try and connect over to > one of the Syba card ports (using Cutecom & getty). The lines light up, > but there's nothing getting sent from the 8-port as far as I can see. Oh crap... I missed this fscking "Disabling IRQ #17" line in your dmesg. Can you try with firewire controller disabled somehow ? -- Andrey Panin| Linux and UNIX system administrator [EMAIL PROTECTED] | PGP key: wwwkeys.pgp.net signature.asc Description: Digital signature
[PATCH 1/1] INPUT/BF54x-KEYPAD driver: Remove useless line -errno returned by irq_request
From: Michael Hennerich <[EMAIL PROTECTED]> Cc: Andrey Panin <[EMAIL PROTECTED]> Signed-off-by: Michael Hennerich <[EMAIL PROTECTED]> Signed-off-by: Bryan Wu <[EMAIL PROTECTED]> --- drivers/input/keyboard/bf54x-keys.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/input/keyboard/bf54x-keys.c b/drivers/input/keyboard/bf54x-keys.c index a67b29b..e5f4da9 100644 --- a/drivers/input/keyboard/bf54x-keys.c +++ b/drivers/input/keyboard/bf54x-keys.c @@ -256,7 +256,6 @@ static int __devinit bfin_kpad_probe(struct platform_device *pdev) printk(KERN_ERR DRV_NAME ": unable to claim irq %d; error %d\n", bf54x_kpad->irq, error); - error = -EBUSY; goto out2; } -- 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: [bug] ata subsystem related crash with latest -git
Mark Lord wrote: Mark Lord wrote: Linus Torvalds wrote: On Wed, 17 Oct 2007, Mark Lord wrote: It would be good to have something soon-ish. This "dead at boot time" issue is impacting the general ability to test patches against latest -git in time for the current merge window. In the meantime, does the patch I sent out help people? Your patch from this posting http://lkml.org/lkml/2007/10/17/285 does not seem to make much difference here. It still crashes at exactly the same place. However, Jens's patch from that same thread: http://lkml.org/lkml/2007/10/17/269 ..allowed me to boot and post this followup message from -git12 Jeff: try that one. That's already in my upstream kernel, here. commits ba951841ceb7fa5b06ad48caa5270cc2ae17941e and a3bec5c5aea0da263111c4d8f8eabc1f8560d7bf. sata_mv and sata_nv still reliably poop themselves here, whereas its rock solid with 2.6.23.1. Sounds like different issues from yours, as I see a stream of SATA errors on the bad kernels, errors which are often a symptom of something whacked in the DMA engine (misprogramming causes the silicon to generate bogus FIS's, which the device then chokes on) Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.23-git12: WARNING: at fs/sysfs/dir.c:424 sysfs_add_one()
usb 5-1: new high speed USB device using ehci_hcd and address 2 usb 5-1: configuration #1 chosen from 1 choice hub 5-1:1.0: USB hub found hub 5-1:1.0: 4 ports detected sysfs: duplicate filename 'bInterfaceNumber' can not be created WARNING: at fs/sysfs/dir.c:424 sysfs_add_one() [sysfs_add_one+159/224] sysfs_add_one+0x9f/0xe0 hda_intel: azx_get_response timeout, switching to polling mode: last cmd=0x010f000c [sysfs_add_file+79/144] sysfs_add_file+0x4f/0x90 b44: eth0: Link is up at 100 Mbps, full duplex. b44: eth0: Flow control is off for TX and off for RX. [sysfs_create_group+103/256] sysfs_create_group+0x67/0x100 [klist_add_tail+30/80] klist_add_tail+0x1e/0x50 [device_add+61/1472] device_add+0x3d/0x5c0 [] usb_create_sysfs_intf_files+0x2c/0xb0 [usbcore] [] usb_set_configuration+0x391/0x5d0 [usbcore] [] generic_probe+0x76/0xb0 [usbcore] [] usb_probe_device+0x33/0x40 [usbcore] [driver_probe_device+142/400] driver_probe_device+0x8e/0x190 [klist_next+93/160] klist_next+0x5d/0xa0 [bus_for_each_drv+68/112] bus_for_each_drv+0x44/0x70 [device_attach+125/144] device_attach+0x7d/0x90 [__device_attach+0/16] __device_attach+0x0/0x10 [bus_attach_device+77/160] bus_attach_device+0x4d/0xa0 [bus_add_device+300/352] bus_add_device+0x12c/0x160 [device_add+1155/1472] device_add+0x483/0x5c0 [] usb_new_device+0x54/0xa0 [usbcore] [] hub_thread+0x45a/0xca0 [usbcore] [schedule+460/1680] schedule+0x1cc/0x690 [autoremove_wake_function+0/80] autoremove_wake_function+0x0/0x50 [] hub_thread+0x0/0xca0 [usbcore] [kthread+66/112] kthread+0x42/0x70 [kthread+0/112] kthread+0x0/0x70 [kernel_thread_helper+7/24] kernel_thread_helper+0x7/0x18 === NET: Registered protocol family 17 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] [kexec-tools] Pass vmcoreinfo's address and size
On Wed, Oct 17, 2007 at 02:16:19PM +0900, Ken'ichi Ohmichi wrote: > > Hi Simon, > > Simon Horman wrote: > > On Wed, Aug 22, 2007 at 09:13:39PM +0900, Ken'ichi Ohmichi wrote: > >> [2/3] [kexec-tools] Pass vmcoreinfo's address and size > >> The patch is for kexec-tools-testing-20070330. > >> (http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/) > >> kexec command gets the address and size of the vmcoreinfo data from > >> /sys/kernel/vmcoreinfo, and passes them to the second kernel through > >> ELF header of /proc/vmcore. When the second kernel is booting, the > >> kernel gets them from the ELF header and creates vmcoreinfo's PT_NOTE > >> segment into /proc/vmcore. > > > > Sorry for the long delay, I completely missed this patch. > > > > The kexec-tools change seems ok to me. What is the status of > > the kernel portion of the change? > > The kernel portion is merged into linux-2.6.23-mm1. > According to Andrew's mail "-mm merge plans for 2.6.24", its status is > "The infamous misc. Will re-review and will merge basically all of them". > > http://www.ussg.iu.edu/hypermail/linux/kernel/0710.0/0313.html > > > > Do you still want the kexec-tools portion applied? > > Yes, I hope so. Thanks, applied :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG] 2.6.23-git12 - Kernel oops at blk_rq_map_sg+0x270/0x4e0
Hi, Kernel oops is triggered within few seconds after boot up in ia64 machine [ 113.004837] Unable to handle kernel NULL pointer dereference (address 0022) [ 113.013077] tail[3466]: Oops 8813272891392 [1] [ 113.017643] Modules linked in: [ 113.020854] [ 113.020855] Pid: 3466, CPU 0, comm: tail [ 113.027901] psr : 101008022018 ifs : 8184 ip : []Not tainted [ 113.037187] ip is at blk_rq_map_sg+0x270/0x4e0 [ 113.041755] unat: pfs : 0309 rsc : 0003 [ 113.049369] rnat: bsps: pr : 1595696a56aa9a69 [ 113.056987] ldrs: ccv : fpsr: 0009804c8a70033f [ 113.064596] csd : ssd : [ 113.070120] b0 : a001006c0050 b6 : a00100100400 b7 : a001006dbe40 [ 113.077736] f6 : 1003e f7 : 1003e0008 [ 113.084131] f8 : 1003e00016701 f9 : 10005a800 [ 113.090526] f10 : 100138cc143fffcb90900 f11 : 1003e00119828 [ 113.096923] r1 : a00100f7fd90 r2 : 0001084d8000 r3 : [ 113.104535] r8 : 0002 r9 : 000420f5 r10 : 002109b0 [ 113.112146] r11 : 000e r12 : e0014b107900 r13 : e0014b10 [ 113.119755] r14 : 0001084d9000 r15 : 0001083d4000 r16 : 0001083d8000 [ 113.127368] r17 : 0001083d4000 r18 : 001ce6b3 r19 : 1000 [ 113.134977] r20 : 40042136 r21 : 0002 r22 : e001434797f0 [ 113.142591] r23 : 1000 r24 : e001434797fc r25 : [ 113.150206] r26 : 000a r27 : 0022 r28 : e0014a907e80 [ 113.157818] r29 : e0014347d628 r30 : 0001 r31 : a00100d9ef18 [ 113.165442] [ 113.165443] Call Trace: [ 113.169623] [] show_stack+0x80/0xa0 [ 113.169624] sp=e0014b1074d0 bsp=e0014b101a68 [ 113.182857] [] show_regs+0x870/0x8a0 [ 113.182858] sp=e0014b1076a0 bsp=e0014b101a10 [ 113.196177] [] die+0x190/0x300 [ 113.196178] sp=e0014b1076a0 bsp=e0014b1019c0 [ 113.208998] [] ia64_do_page_fault+0xa50/0xba0 [ 113.209000] sp=e0014b1076a0 bsp=e0014b101960 [ 113.223098] [] ia64_leave_kernel+0x0/0x270 [ 113.223100] sp=e0014b107730 bsp=e0014b101960 [ 113.236934] [] blk_rq_map_sg+0x270/0x4e0 [ 113.236935] sp=e0014b107900 bsp=e0014b101940 [ 113.250598] [] scsi_init_io+0xf0/0x1e0 [ 113.250599] sp=e0014b107900 bsp=e0014b101910 [ 113.264086] [] scsi_setup_fs_cmnd+0xb0/0x120 [ 113.264088] sp=e0014b107900 bsp=e0014b1018e8 [ 113.278108] [] sd_prep_fn+0xd0/0x11e0 [ 113.278110] sp=e0014b107900 bsp=e0014b101868 [ 113.291516] [] elv_next_request+0x220/0x400 [ 113.291518] sp=e0014b107900 bsp=e0014b1017e8 [ 113.305443] [] scsi_request_fn+0x80/0x940 [ 113.305444] sp=e0014b107910 bsp=e0014b101770 [ 113.319190] [] __generic_unplug_device+0xa0/0xc0 [ 113.319192] sp=e0014b107910 bsp=e0014b101750 [ 113.333544] [] generic_unplug_device+0x30/0x80 [ 113.333546] sp=e0014b107910 bsp=e0014b101728 [ 113.347741] [] blk_backing_dev_unplug+0x60/0xa0 [ 113.347743] sp=e0014b107910 bsp=e0014b101708 [ 113.362024] [] sync_buffer+0xe0/0x120 [ 113.362025] sp=e0014b107910 bsp=e0014b1016e8 [ 113.375424] [] __wait_on_bit+0x140/0x160 [ 113.375426] sp=e0014b107910 bsp=e0014b101698 [ 113.389084] [] out_of_line_wait_on_bit+0xd0/0x100 [ 113.389086] sp=e0014b107910 bsp=e0014b101660 [ 113.403521] [] __wait_on_buffer+0x40/0x60 [ 113.403523] sp=e0014b107950 bsp=e0014b101640 [ 113.417275] [] __bread+0x1e0/0x220 [ 113.417276] sp=e0014b107950 bsp=e0014b101610 [ 113.431925] [] ext3_get_branch+0xe0/0x200 [ 113.431927] sp=e0014b107950 bsp=e0014b1015a8 [ 113.445679] [] ext3_get_blocks_handle+0x120/0x1840 [ 113.445681] sp=e0014b107950 bsp=e0014b101498 [ 113.460220] [] ext3_get_block+0xe0/0x2c0 [ 113.460221] sp=e0014b107a00 bsp=e0014b101440 [ 113.473886] [] do_mpage_readpage+0x630/0xee0 [ 113.473888] sp=e0014b107a00
Re: [BUG] 2.6.23-git12 - Kernel oops at blk_rq_map_sg+0x270/0x4e0
Try this patch and report back again: http://lkml.org/lkml/2007/10/17/269 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [bug] ata subsystem related crash with latest -git
Mark Lord wrote:
Linus Torvalds wrote:
On Wed, 17 Oct 2007, Mark Lord wrote:
It would be good to have something soon-ish.
This "dead at boot time" issue is impacting the general ability to test
patches against latest -git in time for the current merge window.
In the meantime, does the patch I sent out help people?
Your patch from this posting http://lkml.org/lkml/2007/10/17/285
does not seem to make much difference here.
It still crashes at exactly the same place.
However, Jens's patch from that same thread:
http://lkml.org/lkml/2007/10/17/269
..allowed me to boot and post this followup message from -git12
Jeff: try that one.
Patch reproduced here for convenience:
Jens Axboe wrote:
OK, it is fine, as long as the sglist is cleared initially. And I don't
think there's anyway around that, clearly I didn't think long enough
before including the memset() removal from Tomo.
Ingo, please try this rolled up version.
Linus, this should work. It would probably be best if you first did a
git revert on f5c0dde4c66421a3a2d7d6fa604a712c9b0744e5 and then applied
the ll_rw_blk.c bit alone. Do you want me to stuff that (revert + patch)
into a branch for you to pull?
diff --git a/block/ll_rw_blk.c b/block/ll_rw_blk.c
index 9e3f3cc..3935469 100644
--- a/block/ll_rw_blk.c
+++ b/block/ll_rw_blk.c
@@ -1322,8 +1322,8 @@ int blk_rq_map_sg(struct request_queue *q, struct request
*rq,
struct scatterlist *sglist)
{
struct bio_vec *bvec, *bvprv;
- struct scatterlist *next_sg, *sg;
struct req_iterator iter;
+ struct scatterlist *sg;
int nsegs, cluster;
nsegs = 0;
@@ -1333,7 +1333,7 @@ int blk_rq_map_sg(struct request_queue *q, struct request
*rq,
* for each bio in rq
*/
bvprv = NULL;
- sg = next_sg = [0];
+ sg = NULL;
rq_for_each_segment(bvec, rq, iter) {
int nbytes = bvec->bv_len;
@@ -1349,8 +1349,10 @@ int blk_rq_map_sg(struct request_queue *q, struct
request *rq,
sg->length += nbytes;
} else {
new_segment:
- sg = next_sg;
- next_sg = sg_next(sg);
+ if (!sg)
+ sg = sglist;
+ else
+ sg = sg_next(sg);
memset(sg, 0, sizeof(*sg));
sg->page = bvec->bv_page;
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 0c86be7..aac8a02 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -764,6 +764,8 @@ struct scatterlist *scsi_alloc_sgtable(struct scsi_cmnd
*cmd, gfp_t gfp_mask)
if (unlikely(!sgl))
goto enomem;
+ memset(sgl, 0, sizeof(*sgl) * sgp->size);
+
/*
* first loop through, set initial index and return value
*/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Virtual Netdevice
From: rajashok <[EMAIL PROTECTED]> Date: Wed, 17 Oct 2007 22:10:43 -0700 (PDT) > we are trying to to integrate our ipsec onto linux 2.6 kernel Why not use the already existing 2.6.x kernel IPSEC stack? It works quite well. And for this reason, it is unlikely you will get much help on these mailing lists in your efforts to replace it with your own. :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [bug] ata subsystem related crash with latest -git
Linus Torvalds wrote: On Wed, 17 Oct 2007, Mark Lord wrote: It would be good to have something soon-ish. This "dead at boot time" issue is impacting the general ability to test patches against latest -git in time for the current merge window. In the meantime, does the patch I sent out help people? Your patch from this posting http://lkml.org/lkml/2007/10/17/285 does not seem to make much difference here. It still crashes at exactly the same place. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [PATCH 2/2] capabilities: implement 64-bit capabilities
* Serge E. Hallyn ([EMAIL PROTECTED]) wrote: > I guess now that I've written this out, it seems pretty clear > that capget64() and capget64() are the way to go. Any objections? How is capget64() different from capget() that supports 2 different header->versions (I thought that was the whole point of the versioned, rather opaque interface)? I don't object to a new syscall, but I don't see why it's required to avoid breaking libcap. thanks, -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] block: Isolate the buffer cache in it's own mappings.
On Thursday 18 October 2007 13:59, Eric W. Biederman wrote: > If filesystems care at all they want absolute control over the buffer > cache. Controlling which buffers are dirty and when. Because we > keep the buffer cache in the page cache for the block device we have > not quite been giving filesystems that control leading to really weird > bugs. Mmm. Like I said, when a live filesystem is mounted on a bdev, it isn't like you want userspace to go dancing around on it without knowing exactly what it is doing. The kernel more or less does the right thing here with respect to the *state* of the data[*] (that is, buffer heads and pagecache). It's when you actually start changing the data itself around is when you'll blow up the filesystem. [*] The ramdisk code is simply buggy, right? (and not the buffer cache) The idea of your patch in theory is OK, but Andrew raises valid points about potential coherency problems, I think. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Version 8 (2.6.23) Smack: Simplified Mandatory Access Control Kernel
On Thu, Oct 18, 2007 at 05:57:05AM +0100, Al Viro wrote: > On Tue, Oct 16, 2007 at 09:17:40PM -0700, Casey Schaufler wrote: > Think what happens if CPU1 adds to list and CPU2 sees write to smk_known > *before* it sees write to ->smk_next. We see a single-element list and > we'll be lucky if that single entry won't be FUBAR. While we are at it, what protects smack_cipso_count? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [bug] ata subsystem related crash with latest -git
Mark Lord wrote: Mark Lord wrote: Mark Lord wrote: Linus Torvalds wrote: On Wed, 17 Oct 2007, Mark Lord wrote: It would be good to have something soon-ish. This "dead at boot time" issue is impacting the general ability to test patches against latest -git in time for the current merge window. In the meantime, does the patch I sent out help people? I'd like to get feedback, but I'm a lazy bum, and don't use DEBUG_PAGEALLOC myself, so I was hoping that people who actually see this could comment on my untested suggestion. Oh.. so this bug is supposed to only bite with DEBUG_PAGEALLOC=y ?? Then something else is broken, perhaps. I just saw a long traceback scroll off the top of the screen, with lots of bio_* functions in the list and assumed it was the same bug. Mmm.. I'll get out the camera and try it again now.. Okay, mine is dying with EIP at blk_rq_map_sg+0xcb/0x160. Screen photo is at http://rtr.ca/recent/2.6.23-git12-crash.jpg, but the top was cut off (isn't there a new config option or patch to do double-columns or scrollback or something ???. I tried the fancy "boot_delay=nnn" feature, but that doesn't slow down the tracebacks at all. So I hardcoded some mdelay(1000) lines into the traceback code, and here's the top part of the oops now: http://rtr.ca/recent/2.6.23-git12-crash2.jpg ... And, yes, I make that out as being this line from blk_rq_map_sg(): next_sg = sg_next(sg); "objdump -d" output from my actual kernel: 3ce0 : 3ce0: 55 push %ebp 3ce1: 57 push %edi 3ce2: 56 push %esi 3ce3: 53 push %ebx 3ce4: 83 ec 24sub$0x24,%esp 3ce7: 89 44 24 04 mov%eax,0x4(%esp) 3ceb: 8b 98 44 01 00 00 mov0x144(%eax),%ebx 3cf1: 83 e3 01and$0x1,%ebx 3cf4: 89 5c 24 14 mov%ebx,0x14(%esp) 3cf8: 8b 52 34mov0x34(%edx),%edx 3cfb: c7 44 24 10 00 00 00movl $0x0,0x10(%esp) 3d02: 00 3d03: 85 d2 test %edx,%edx 3d05: 89 54 24 1c mov%edx,0x1c(%esp) 3d09: 0f 84 f4 00 00 00 je 3e03 3d0f: 89 cb mov%ecx,%ebx 3d11: 31 ff xor%edi,%edi 3d13: 89 4c 24 0c mov%ecx,0xc(%esp) 3d17: 8b 44 24 1c mov0x1c(%esp),%eax 3d1b: 0f b7 48 16 movzwl 0x16(%eax),%ecx 3d1f: 8b 50 2cmov0x2c(%eax),%edx 3d22: 89 4c 24 18 mov%ecx,0x18(%esp) 3d26: 0f b7 40 14 movzwl 0x14(%eax),%eax 3d2a: 39 c1 cmp%eax,%ecx 3d2c: 0f 8d be 00 00 00 jge3df0 3d32: 8d 04 49lea(%ecx,%ecx,2),%eax 3d35: 8d 34 82lea(%edx,%eax,4),%esi 3d38: 0f b6 44 24 14 movzbl 0x14(%esp),%eax 3d3d: 88 44 24 23 mov%al,0x23(%esp) 3d41: eb 05 jmp3d48 3d43: 89 f7 mov%esi,%edi 3d45: 83 c6 0cadd$0xc,%esi 3d48: 80 7c 24 23 00 cmpb $0x0,0x23(%esp) 3d4d: 8b 6e 04mov0x4(%esi),%ebp 3d50: 74 4e je 3da0 3d52: 85 ff test %edi,%edi 3d54: 74 4a je 3da0 3d56: 8b 54 24 0c mov0xc(%esp),%edx 3d5a: 8b 44 24 04 mov0x4(%esp),%eax 3d5e: 8b 4a 0cmov0xc(%edx),%ecx 3d61: 01 e9 add%ebp,%ecx 3d63: 89 4c 24 08 mov%ecx,0x8(%esp) 3d67: 3b 88 94 01 00 00 cmp0x194(%eax),%ecx 3d6d: 77 31 ja 3da0 3d6f: 8b 15 00 00 00 00 mov0x0,%edx 3d75: 8b 0f mov(%edi),%ecx 3d77: 8b 47 04mov0x4(%edi),%eax 3d7a: 29 d1 sub%edx,%ecx 3d7c: c1 f9 05sar$0x5,%ecx 3d7f: c1 e1 0cshl$0xc,%ecx 3d82: 03 4f 08add0x8(%edi),%ecx 3d85: 8d 3c 01lea(%ecx,%eax,1),%edi 3d88: 8b 06 mov(%esi),%eax 3d8a: 29 d0 sub%edx,%eax 3d8c: c1 f8 05sar$0x5,%eax 3d8f: c1 e0 0cshl$0xc,%eax 3d92: 03 46 08add0x8(%esi),%eax 3d95: 39 c7 cmp%eax,%edi 3d97: 74 76 je 3e0f 3d99: 8d b4 26 00 00 00 00lea0x0(%esi),%esi 3da0: 8d 43 10lea
[serial?] 6.2.23.git.today poking SysRq-T triggers NMI watchdog
Greetings, When shutting down this kernel, my box is hanging when the init scripts tries to set the hardware clock, so I fired up my serial console box, and set nmi_watchdog=2, but nothing happened. When I poked SysRq-T however, I received the below. I also notice that I can't login via serial console with this kernel. (the taint is due to previously posted oops loading microcode module) [ 257.624720] BUG: NMI Watchdog detected LOCKUP on CPU0, eip c04c00ed, registers: [ 257.632036] Modules linked in: radeon drm snd_pcm_oss w83781d hwmon_vid hwmon eeprom snd_mixer_oss snd_seq_midi snd_seq_midi_event microcode snd_seq edd button battery ac ip6t_REJECT xt_tcpudp ipt_REJECT xt_state iptable_mangle iptable_nat nf_nat iptable_filter ip6table_mangle nf_conntrack_ipv4 nf_conntrack ip_tables ip6table_filter ip6_tables x_tables nls_iso8859_1 nls_cp437 nls_utf8 snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm prism54 snd_timer snd_mpu401 snd_mpu401_uart snd_rawmidi snd_seq_device intel_agp snd agpgart snd_page_alloc soundcore i2c_i801 fan thermal processor [ 257.683837] CPU:0 [ 257.683838] EIP:0060:[]Tainted: G D VLI [ 257.683840] EFLAGS: 0006 (2.6.23-smp-git #13) [ 257.696806] EIP is at _spin_lock_irqsave+0x51/0x66 [ 257.701589] eax: ebx: c061ffa0 ecx: 0027 edx: 0002 [ 257.708369] esi: c068e000 edi: 0074 ebp: c068ee60 esp: c068ee58 [ 257.715151] ds: 007b es: 007b fs: 00d8 gs: ss: 0068 [ 257.720980] Process swapper (pid: 0, ti=c068e000 task=c06083c0 task.ti=c0645000) [ 257.728193] Stack: c2d0c000 0001 c068ee88 c033e493 c2d0c11c c068ee78 c2d0c000 0002 [ 257.736679]c068ee80 c2d0c000 0074 c2d0c000 c068ee98 c033e5ae 0001 0014 [ 257.745167]c068eec0 c0338658 4716e406 0002d6d1 01010004 c39c0c00 0014 c0338325 [ 257.753654] Call Trace: [ 257.756288] [] show_trace_log_lvl+0x1a/0x30 [ 257.761450] [] show_stack_log_lvl+0xa5/0xca [ 257.766611] [] show_registers+0x1fc/0x33d [ 257.771599] [] die_nmi+0x86/0xd9 [ 257.775799] [] nmi_watchdog_tick+0x13b/0x140 [ 257.781038] [] do_nmi+0x80/0x253 [ 257.785240] [] nmi_stack_correct+0x26/0x2b [ 257.790314] [] __handle_sysrq+0x1a/0x115 [ 257.795209] [] handle_sysrq+0x20/0x24 [ 257.799849] [] kbd_event+0x333/0x5cb [ 257.804397] [] input_pass_event+0xb2/0xc3 [ 257.809384] [] input_handle_event+0x131/0x3b4 [ 257.814712] [] input_event+0x54/0x67 [ 257.819266] [] atkbd_interrupt+0x425/0x570 [ 257.824332] [] serio_interrupt+0x32/0x6c [ 257.829226] [] i8042_interrupt+0x10a/0x23f [ 257.834300] [] handle_IRQ_event+0x2c/0x55 [ 257.839280] [] handle_edge_irq+0xbc/0x11d [ 257.844252] [] do_IRQ+0x79/0xce [ 257.848366] === [ 257.851941] Code: d0 5b 5e 5d c3 52 9d 83 6e 14 01 8b 46 08 a8 04 75 22 8b 43 04 85 c0 75 12 c7 43 04 01 00 00 00 eb 09 8b 4b 04 85 c9 74 c0 f3 90 <0f> b6 03 84 c0 7e f0 eb b5 e8 cb ed ff ff 90 8d 74 26 00 eb d2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Version 8 (2.6.23) Smack: Simplified Mandatory Access Control Kernel
On Tue, Oct 16, 2007 at 09:17:40PM -0700, Casey Schaufler wrote:
At random:
> +static int smack_netlabel(struct sock *sk)
> +{
> + static int initialized;
> + struct socket_smack *ssp = sk->sk_security;
> + struct netlbl_lsm_secattr secattr;
> + int rc = 0;
> +
> + if (!initialized) {
> + smk_cipso_doi();
> + initialized = 1;
> + }
And just what happens if another task calls the same while we are
blocked on allocation in smk_cipso_doi()?
Another problem is your handling of smk_known - you add to head under
mutex; fine. However, you read without one _and_ have no barriers
in initializing new list entries.
Think what happens if CPU1 adds to list and CPU2 sees write to smk_known
*before* it sees write to ->smk_next. We see a single-element list and
we'll be lucky if that single entry won't be FUBAR.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [bug] ata subsystem related crash with latest -git
Mark Lord wrote: Mark Lord wrote: Linus Torvalds wrote: On Wed, 17 Oct 2007, Mark Lord wrote: It would be good to have something soon-ish. This "dead at boot time" issue is impacting the general ability to test patches against latest -git in time for the current merge window. In the meantime, does the patch I sent out help people? I'd like to get feedback, but I'm a lazy bum, and don't use DEBUG_PAGEALLOC myself, so I was hoping that people who actually see this could comment on my untested suggestion. Oh.. so this bug is supposed to only bite with DEBUG_PAGEALLOC=y ?? Then something else is broken, perhaps. I just saw a long traceback scroll off the top of the screen, with lots of bio_* functions in the list and assumed it was the same bug. Mmm.. I'll get out the camera and try it again now.. Okay, mine is dying with EIP at blk_rq_map_sg+0xcb/0x160. Screen photo is at http://rtr.ca/recent/2.6.23-git12-crash.jpg, but the top was cut off (isn't there a new config option or patch to do double-columns or scrollback or something ???. I tried the fancy "boot_delay=nnn" feature, but that doesn't slow down the tracebacks at all. So I hardcoded some mdelay(1000) lines into the traceback code, and here's the top part of the oops now: http://rtr.ca/recent/2.6.23-git12-crash2.jpg And here's the .config for the kernel, just in case it's of any use here: # # Automatically generated make config: don't edit # Linux kernel version: 2.6.23-git12 # Thu Oct 18 00:28:52 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=16 # CONFIG_CPUSETS is not set # CONFIG_FAIR_GROUP_SCHED is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y # CONFIG_SLUB_DEBUG is not set # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set CONFIG_BLK_DEV_BSG=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y # CONFIG_IOSCHED_DEADLINE is not set CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_SMP=y CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y # CONFIG_PARAVIRT is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set CONFIG_MCORE2=y # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_XADD=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y
Re: [PATCH]: drm: cleanup DRM_DEBUG() parameters
From: Márton Németh <[EMAIL PROTECTED]>
As DRM_DEBUG macro already prints out the __FUNCTION__ string (see
drivers/char/drm/drmP.h), it is not worth doing this again. At some
other places the ending "\n" was added.
Signed-off-by: Márton Németh <[EMAIL PROTECTED]>
---
diff -uprN linux-2.6.23-mm1.orig/drivers/char/drm/ati_pcigart.c
linux-2.6.23-mm1/drivers/char/drm/ati_pcigart.c
--- linux-2.6.23-mm1.orig/drivers/char/drm/ati_pcigart.c2007-10-09
22:31:38.0 +0200
+++ linux-2.6.23-mm1/drivers/char/drm/ati_pcigart.c 2007-10-17
22:22:19.0 +0200
@@ -41,7 +41,7 @@ static void *drm_ati_alloc_pcigart_table
struct page *page;
int i;
- DRM_DEBUG("%s: alloc %d order\n", __FUNCTION__, order);
+ DRM_DEBUG("%d order\n", order);
address = __get_free_pages(GFP_KERNEL | __GFP_COMP,
order);
@@ -54,7 +54,7 @@ static void *drm_ati_alloc_pcigart_table
for (i = 0; i < order; i++, page++)
SetPageReserved(page);
- DRM_DEBUG("%s: returning 0x%08lx\n", __FUNCTION__, address);
+ DRM_DEBUG("returning 0x%08lx\n", address);
return (void *)address;
}
@@ -63,7 +63,7 @@ static void drm_ati_free_pcigart_table(v
struct page *page;
int i;
int num_pages = 1 << order;
- DRM_DEBUG("%s\n", __FUNCTION__);
+ DRM_DEBUG("\n");
page = virt_to_page((unsigned long)address);
diff -uprN linux-2.6.23-mm1.orig/drivers/char/drm/drm_irq.c
linux-2.6.23-mm1/drivers/char/drm/drm_irq.c
--- linux-2.6.23-mm1.orig/drivers/char/drm/drm_irq.c2007-10-17
22:19:21.0 +0200
+++ linux-2.6.23-mm1/drivers/char/drm/drm_irq.c 2007-10-17 22:22:19.0
+0200
@@ -107,7 +107,7 @@ static int drm_irq_install(struct drm_de
dev->irq_enabled = 1;
mutex_unlock(>struct_mutex);
- DRM_DEBUG("%s: irq=%d\n", __FUNCTION__, dev->irq);
+ DRM_DEBUG("irq=%d\n", dev->irq);
if (drm_core_check_feature(dev, DRIVER_IRQ_VBL)) {
init_waitqueue_head(>vbl_queue);
@@ -164,7 +164,7 @@ int drm_irq_uninstall(struct drm_device
if (!irq_enabled)
return -EINVAL;
- DRM_DEBUG("%s: irq=%d\n", __FUNCTION__, dev->irq);
+ DRM_DEBUG("irq=%d\n", dev->irq);
dev->driver->irq_uninstall(dev);
diff -uprN linux-2.6.23-mm1.orig/drivers/char/drm/drm_scatter.c
linux-2.6.23-mm1/drivers/char/drm/drm_scatter.c
--- linux-2.6.23-mm1.orig/drivers/char/drm/drm_scatter.c2007-10-17
22:19:21.0 +0200
+++ linux-2.6.23-mm1/drivers/char/drm/drm_scatter.c 2007-10-17
22:31:42.0 +0200
@@ -67,7 +67,7 @@ int drm_sg_alloc(struct drm_device *dev,
struct drm_sg_mem *entry;
unsigned long pages, i, j;
- DRM_DEBUG("%s\n", __FUNCTION__);
+ DRM_DEBUG("\n");
if (!drm_core_check_feature(dev, DRIVER_SG))
return -EINVAL;
@@ -81,7 +81,7 @@ int drm_sg_alloc(struct drm_device *dev,
memset(entry, 0, sizeof(*entry));
pages = (request->size + PAGE_SIZE - 1) / PAGE_SIZE;
- DRM_DEBUG("sg size=%ld pages=%ld\n", request->size, pages);
+ DRM_DEBUG("size=%ld pages=%ld\n", request->size, pages);
entry->pages = pages;
entry->pagelist = drm_alloc(pages * sizeof(*entry->pagelist),
@@ -122,8 +122,8 @@ int drm_sg_alloc(struct drm_device *dev,
entry->handle = ScatterHandle((unsigned long)entry->virtual);
- DRM_DEBUG("sg alloc handle = %08lx\n", entry->handle);
- DRM_DEBUG("sg alloc virtual = %p\n", entry->virtual);
+ DRM_DEBUG("handle = %08lx\n", entry->handle);
+ DRM_DEBUG("virtual = %p\n", entry->virtual);
for (i = (unsigned long)entry->virtual, j = 0; j < pages;
i += PAGE_SIZE, j++) {
@@ -210,7 +210,7 @@ int drm_sg_free(struct drm_device *dev,
if (!entry || entry->handle != request->handle)
return -EINVAL;
- DRM_DEBUG("sg free virtual = %p\n", entry->virtual);
+ DRM_DEBUG("virtual = %p\n", entry->virtual);
drm_sg_cleanup(entry);
diff -uprN linux-2.6.23-mm1.orig/drivers/char/drm/drm_vm.c
linux-2.6.23-mm1/drivers/char/drm/drm_vm.c
--- linux-2.6.23-mm1.orig/drivers/char/drm/drm_vm.c 2007-10-17
22:19:21.0 +0200
+++ linux-2.6.23-mm1/drivers/char/drm/drm_vm.c 2007-10-17 22:22:19.0
+0200
@@ -180,7 +180,7 @@ static __inline__ struct page *drm_do_vm
return NOPAGE_SIGBUS;
get_page(page);
- DRM_DEBUG("shm_nopage 0x%lx\n", address);
+ DRM_DEBUG("0x%lx\n", address);
return page;
}
@@ -294,7 +294,7 @@ static __inline__ struct page *drm_do_vm
get_page(page);
- DRM_DEBUG("dma_nopage 0x%lx (page %lu)\n", address, page_nr);
+ DRM_DEBUG("0x%lx (page %lu)\n", address, page_nr);
return page;
}
diff -uprN linux-2.6.23-mm1.orig/drivers/char/drm/i810_dma.c
linux-2.6.23-mm1/drivers/char/drm/i810_dma.c
---
Re: [bug] ata subsystem related crash with latest -git
On Thu, 18 Oct 2007, Jeff Garzik wrote: > > Is this a sata_mv box? If so, could you try this patch? That could explain it: if the SG allocation is simply too small, the scatter-gather code will run off the end of the SG list, and encounter random uninitialized entries, and if any of those have the low bit set, they will be considered to be "link" entries, and the SG list goes wild. That SG code is really pretty fragile. I don't see it *ever* checking that the SG allocation is large enough when it fills it in. And these things take the sizes from different places (ie "cmd->use_sg" bs "req->nr_phys_segments" vs God knows what else..) Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] IB/ehca: Enable large page MRs by default
thanks, applied 1-5 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [bug] ata subsystem related crash with latest -git
On Thu, 18 Oct 2007, Mark Lord wrote: > > Okay, mine is dying with EIP at blk_rq_map_sg+0xcb/0x160. Ok, I think your picture cut off the last hex digits on the right, but what I can make out of the disassembly, I have to admit that it looks very much like it might be exactly the same thing Ingo was seeing. The disassembly is a bit scrambled, but the particular instruction that oopses for you is mov0x10(%ebx),%eax and the instructions around it do seem to bear some similarity to the whole "sg_next()" thing, ie I see a test $0x1,%al and a lea0x10(%ebx),%eax around there too. If you cut down the number of entries printed for the call trace (which involves editing the source code, no nice config options, I'm afraid), you could get the rest of it.. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [bug] ata subsystem related crash with latest -git
Jeff Garzik wrote: Mark Lord wrote: Okay, mine is dying with EIP at blk_rq_map_sg+0xcb/0x160. Screen photo is at http://rtr.ca/recent/2.6.23-git12-crash.jpg, but the top was cut off (isn't there a new config option or patch to do double-columns or scrollback or something ???. Is this a sata_mv box? If so, could you try this patch? No.. it's a pretty ordinary ata_piix machine, with no serial ports either. Cheers - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] block: Isolate the buffer cache in it's own mappings.
On Wed, 17 Oct 2007 21:59:02 -0600 [EMAIL PROTECTED] (Eric W. Biederman) wrote: > If filesystems care at all they want absolute control over the buffer > cache. Controlling which buffers are dirty and when. Because we > keep the buffer cache in the page cache for the block device we have > not quite been giving filesystems that control leading to really weird > bugs. > > In addition this tieing of the implemetation of block device caching > and the buffer cache has resulted in a much more complicated and > limited implementation then necessary. Block devices for example > don't need buffer_heads, and it is perfectly reasonable to cache > block devices in high memory. > > To start untangling the worst of this mess this patch introduces a > second block device inode for the buffer cache. All buffer cache > operations are diverted to that use the new bd_metadata_inode, which > keeps the weirdness of the metadata requirements isolated in their > own little world. I don't think we little angels want to tread here. There are so many weirdo things out there which will break if we bust the coherence between the fs and /dev/hda1. Online resize, online fs checkers, various local tools which people have hacked up to look at metadata in a live fs, direct-io access to the underlying fs, heaven knows how many boot loader installers, etc. Cerainly I couldn't enumerate tham all. The mere thought of all this scares the crap out of me. I don't actually see what the conceptual problem is with the existing implementation. The buffer_head is a finer-grained view onto the blockdev's pagecache: it provides additional states and additional locking against a finer-grained section of the page. It works well. Yeah, the highmem thing is a bit of a problem (but waning in importance). But we can fix that by teaching individual filesystems about kmap and then tweak the blockdev's caching policy with mapping_set_gfp_mask() at mount time. If anyone cares, which they don't. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2/3] Introduce BOOTMEM_EXCLUSIVE
On Wed, Oct 17, 2007 at 01:36:51PM +0200, Bernhard Walle wrote:
[..]
> > > +static int __init reserve_bootmem_core(bootmem_data_t *bdata, unsigned
> > > long addr,
> > > + unsigned long size, int flags)
> > > {
> > > unsigned long sidx, eidx;
> > > unsigned long i;
> > > @@ -133,7 +133,11 @@ static void __init reserve_bootmem_core(
> > > #ifdef CONFIG_DEBUG_BOOTMEM
> > > printk("hm, page %08lx reserved twice.\n", i*PAGE_SIZE);
> > > #endif
> > > + if (flags & BOOTMEM_EXCLUSIVE)
> > > + return -EBUSY;
> >
> > I think we should unreserve the chunks of memory we have reserved so
> > far (Memory reserved from sidx to i), in case of error.
>
> Unfortunately, that's not possible without using a lock (or counters
> instead of a bitmap) any more. If we just do
>
> for (i--; i >= sidx; i--)
> clear_bit(i, bdata->node_bootmem_map);
>
> then another thread of execution could reserve the memory (without
> BOOTMEM_EXCLUSIVE) in between -- and the code would free the memory
> which is already reserved.
>
> I think that could be modelled with a rwlock, not changing the default
> case where BOOTMEM_EXCLUSIVE is not specified.
SMP initialization takes place after bootmem allocator has retired. That
would mean only one thread will be using bootmem allocator. Hence I think
unreserving memory without any kind of locking should be safe.
Thanks
Vivek
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [bug] ata subsystem related crash with latest -git
Mark Lord wrote:
Okay, mine is dying with EIP at blk_rq_map_sg+0xcb/0x160.
Screen photo is at http://rtr.ca/recent/2.6.23-git12-crash.jpg,
but the top was cut off (isn't there a new config option or patch
to do double-columns or scrollback or something ???.
Is this a sata_mv box? If so, could you try this patch?
Jeff
diff --git a/drivers/ata/sata_mv.c b/drivers/ata/sata_mv.c
index 4df8311..d8cf8b1 100644
--- a/drivers/ata/sata_mv.c
+++ b/drivers/ata/sata_mv.c
@@ -421,7 +421,6 @@ static void mv_error_handler(struct ata_port *ap);
static void mv_post_int_cmd(struct ata_queued_cmd *qc);
static void mv_eh_freeze(struct ata_port *ap);
static void mv_eh_thaw(struct ata_port *ap);
-static int mv_slave_config(struct scsi_device *sdev);
static int mv_init_one(struct pci_dev *pdev, const struct pci_device_id *ent);
static void mv5_phy_errata(struct mv_host_priv *hpriv, void __iomem *mmio,
@@ -459,7 +458,7 @@ static struct scsi_host_template mv5_sht = {
.use_clustering = 1,
.proc_name = DRV_NAME,
.dma_boundary = MV_DMA_BOUNDARY,
- .slave_configure= mv_slave_config,
+ .slave_configure= ata_scsi_slave_config,
.slave_destroy = ata_scsi_slave_destroy,
.bios_param = ata_std_bios_param,
};
@@ -477,7 +476,7 @@ static struct scsi_host_template mv6_sht = {
.use_clustering = 1,
.proc_name = DRV_NAME,
.dma_boundary = MV_DMA_BOUNDARY,
- .slave_configure= mv_slave_config,
+ .slave_configure= ata_scsi_slave_config,
.slave_destroy = ata_scsi_slave_destroy,
.bios_param = ata_std_bios_param,
};
@@ -756,17 +755,6 @@ static void mv_irq_clear(struct ata_port *ap)
{
}
-static int mv_slave_config(struct scsi_device *sdev)
-{
- int rc = ata_scsi_slave_config(sdev);
- if (rc)
- return rc;
-
- blk_queue_max_phys_segments(sdev->request_queue, MV_MAX_SG_CT / 2);
-
- return 0; /* scsi layer doesn't check return value, sigh */
-}
-
static void mv_set_edma_ptrs(void __iomem *port_mmio,
struct mv_host_priv *hpriv,
struct mv_port_priv *pp)
[microcode] 2.6.23.git pulled this morning oopses loading P4 microcode
Greetings,
Freshly pulled tree oopes per $subject.
[ 114.714335] BUG: unable to handle kernel NULL pointer dereference at virtual
address 0031
[ 114.732810] printing eip: c03332ff *pde =
[ 114.747614] Oops: [#1] PREEMPT SMP
[ 114.761320] Modules linked in: microcode snd_seq edd button battery ac
ip6t_REJECT xt_tcpudp ipt_REJECT xt_state iptable_mangle iptable_nat nf_nat
iptable_filter ip6table_mangle nf_conntrack_ipv4 nf_conntrack ip_tables
ip6table_filter ip6_tables x_tables nls_iso8859_1 nls_cp437 nls_utf8
snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_mpu401 snd_timer
snd_mpu401_uart snd_rawmidi prism54 snd_page_alloc snd_seq_device snd soundcore
intel_agp agpgart i2c_i801 fan thermal processor
[ 114.781462] CPU:0
[ 114.781464] EIP:0060:[]Not tainted VLI
[ 114.781468] EFLAGS: 00010293 (2.6.23-smp-git #13)
[ 114.781478] EIP is at misc_register+0x53/0x14f
[ 114.781483] eax: 0025 ebx: f8bff858 ecx: f8bff900 edx: 0031
[ 114.781490] esi: 00b8 edi: f8bff864 ebp: c2e0de88 esp: c2e0de68
[ 114.781496] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
[ 114.781502] Process modprobe (pid: 6115, ti=c2e0d000 task=c2efa070
task.ti=c2e0d000)
[ 114.781508] Stack: c1cb4070 f8bff900 c2e0de88 c014818c f8bff900 f8bff900
f8bff900 0029
[ 114.781521]c2e0de9c f8bac011 c01368e6 f8bff900 c2e0dfb0
c0149dfa
[ 114.781533] 2000 c04d4060 c2e0ded0 c2e0df58 f8be0058
f8be0054 f8bff948
[ 114.781545] Call Trace:
[ 114.781548] [] show_trace_log_lvl+0x1a/0x30
[ 114.781558] [] show_stack_log_lvl+0xa5/0xca
[ 114.781564] [] show_registers+0x1fc/0x33d
[ 114.781571] [] die+0x116/0x239
[ 114.781577] [] do_page_fault+0x2dc/0x5c4
[ 114.781585] [] error_code+0x72/0x78
[ 114.781594] [] microcode_init+0x11/0xbb [microcode]
[ 114.781604] [] sys_init_module+0xef/0x19bb
[ 114.781612] [] syscall_call+0x7/0xb
[ 114.781618] ===
[ 114.781621] Code: 0c 0f 18 02 90 81 3d 60 d5 61 c0 60 d5 61 c0 0f 84 fb 00
00 00 8b 33 39 30 75 0d e9 a9 00 00 00 39 30 0f 84 a1 00 00 00 8d 42 f4 <8b> 50
0c 0f 18 02 90 3d 54 d5 61 c0 75 e7 81 fe ff 00 00 00 0f
[ 114.781677] EIP: [] misc_register+0x53/0x14f SS:ESP 0068:c2e0de68
(gdb) list *misc_register+0x53
0xc03332ff is in misc_register (drivers/char/misc.c:194).
189 int err = 0;
190
191 INIT_LIST_HEAD(>list);
192
193 mutex_lock(_mtx);
194 list_for_each_entry(c, _list, list) {
195 if (c->minor == misc->minor) {
196 mutex_unlock(_mtx);
197 return -EBUSY;
198 }
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: hda-intel: no soundcard with current linus' git tree
Maxim Levitsky wrote: Probably everything is fine. I added a new mixer control called "Master Volume" it is a VolumeKnob. It is a hardware control, that was unused in the driver before. It affects the volume of all DACs check if it is enabled, and set to maximum value. This control affects the volume quite a lot, for example on my system if I set it to middle, I almost hear no sound. Maybe something else unrelated to my patches broke your sound too. 'alsamixergui' shows it enabled, and near the maximum. I'll bisect this no-audio regression when I have time, but that will be after I'm finished with the current libata explosions :( In the meantime, feel free to ask for more diagnostic output. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [bug] ata subsystem related crash with latest -git
On Thu, 18 Oct 2007, Mark Lord wrote: > > Oh.. so this bug is supposed to only bite with DEBUG_PAGEALLOC=y ?? Yeah, this particular one really should only bite you with DEBUG_PAGEALLOC. The SG code potentially _derefences_ a field past the end of the SG array, but it should be a read, and the result should never be used (it's used to calculate the pointer to past the end of the queue, so if it's used, there's another bug lurking). > Then something else is broken, perhaps. I just saw a long traceback > scroll off the top of the screen, with lots of bio_* functions in the > list and assumed it was the same bug. > > Mmm.. I'll get out the camera and try it again now.. Please do. I wouldn't be surprised if it's also related to the SG changes, but I don't think it's the exact particular bug that Ingo saw. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/21] KGDB: Request to merge KGDB
On Mon, 15 Oct 2007 13:32:24 -0500 Jason Wessel <[EMAIL PROTECTED]> wrote: > This is a request to merge KGDB into the mainline kernel. This won't work very well. There's a lot of review work to be done here, and a lot of it by busy architecture maintainers. Expecting people to do all this review and test work late in the merge window when they're all madly scrambling to get their bugs^Wpatches into mainline is not reasonable. This should all have started a month ago. So we're looking at a 2.6.25 merge for this work. After this round of review has settled, please upissue the patches and keep linux-arch (cc'ed here) copied on everything, thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [bug] ata subsystem related crash with latest -git
Mark Lord wrote: Linus Torvalds wrote: On Wed, 17 Oct 2007, Mark Lord wrote: It would be good to have something soon-ish. This "dead at boot time" issue is impacting the general ability to test patches against latest -git in time for the current merge window. In the meantime, does the patch I sent out help people? I'd like to get feedback, but I'm a lazy bum, and don't use DEBUG_PAGEALLOC myself, so I was hoping that people who actually see this could comment on my untested suggestion. Oh.. so this bug is supposed to only bite with DEBUG_PAGEALLOC=y ?? Then something else is broken, perhaps. I just saw a long traceback scroll off the top of the screen, with lots of bio_* functions in the list and assumed it was the same bug. Mmm.. I'll get out the camera and try it again now.. Okay, mine is dying with EIP at blk_rq_map_sg+0xcb/0x160. Screen photo is at http://rtr.ca/recent/2.6.23-git12-crash.jpg, but the top was cut off (isn't there a new config option or patch to do double-columns or scrollback or something ???. Cheers - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [bug] ata subsystem related crash with latest -git
Mark Lord wrote: Linus Torvalds wrote: On Wed, 17 Oct 2007, Mark Lord wrote: It would be good to have something soon-ish. This "dead at boot time" issue is impacting the general ability to test patches against latest -git in time for the current merge window. In the meantime, does the patch I sent out help people? I'd like to get feedback, but I'm a lazy bum, and don't use DEBUG_PAGEALLOC myself, so I was hoping that people who actually see this could comment on my untested suggestion. Oh.. so this bug is supposed to only bite with DEBUG_PAGEALLOC=y ?? Then something else is broken, perhaps. I just saw a long traceback scroll off the top of the screen, with lots of bio_* functions in the list and assumed it was the same bug. Mmm.. I'll get out the camera and try it again now.. I'm currently bisecting on two machines (sata_mv and sata_nv). sata_mv suddenly started spewing errors in recent kernels, but kernels from ~48 hours ago are just fine. AMD64 sata_nv machine will simply lock up if I push it too hard. Again, reproducible, and kernels from ~48 hours ago are fine. AHCI machine so far seems fine (kernel ~24 hours ago), storage-wise, but the hda_intel audio decided to stop working :) I'm quite happy to test patches, but I never run with DEBUG_PAGEALLOC so that shouldn't be causing the problems here. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hda-intel: no soundcard with current linus' git tree
On Thursday 18 October 2007 05:38:06 Jeff Garzik wrote: > Maxim Levitsky wrote: > > What sound codec do you have? > > cat /proc/asound/Intel/codec* > > Attached. > > I'm on x86-64/Fedora 7 FWIW. > > > > You probably have different issue, since your card is probed correctly > > Agreed (though I was surprised that a correct probe did not yield a > single printk). > > Jeff > > > Thanks. Probably everything is fine. I added a new mixer control called "Master Volume" it is a VolumeKnob. It is a hardware control, that was unused in the driver before. It affects the volume of all DACs check if it is enabled, and set to maximum value. This control affects the volume quite a lot, for example on my system if I set it to middle, I almost hear no sound. Maybe something else unrelated to my patches broke your sound too. 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/
Re: [PATCH 2/2] ext2: Avoid rec_len overflow with 64KB block size
On Thu, 11 Oct 2007 13:18:49 +0200 Jan Kara <[EMAIL PROTECTED]> wrote: > With 64KB blocksize, a directory entry can have size 64KB which does not fit > into 16 bits we have for entry lenght. So we store 0x instead and convert > value when read from / written to disk. btw, this changes ext2's on-disk format. a) is the ext2 format documented anywhere? If so, that document will need updating. b) what happens when an old ext2 driver tries to read and/or write this directory entry? Do we need a compat flag for it? c) what happens when old and new ext3 or ext4 try to read/write this directory entry? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] ext2: Avoid rec_len overflow with 64KB block size
On Thu, 11 Oct 2007 13:18:49 +0200 Jan Kara <[EMAIL PROTECTED]> wrote:
> +static inline __le16 ext2_rec_len_to_disk(unsigned len)
> +{
> + if (len == (1 << 16))
> + return cpu_to_le16(EXT2_MAX_REC_LEN);
> + else if (len > (1 << 16))
> + BUG();
> + return cpu_to_le16(len);
> +}
Of course, ext2 shouldn't be trying to write a bad record length into a
directory entry. But are we sure that there is no way in which this
situation could occur is the on-disk data was _already_ bad?
Because it is very bad for a fileysstem to go BUG in response to unexpected
data on the disk.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [bug] ata subsystem related crash with latest -git
Linus Torvalds wrote: On Wed, 17 Oct 2007, Mark Lord wrote: It would be good to have something soon-ish. This "dead at boot time" issue is impacting the general ability to test patches against latest -git in time for the current merge window. In the meantime, does the patch I sent out help people? I'd like to get feedback, but I'm a lazy bum, and don't use DEBUG_PAGEALLOC myself, so I was hoping that people who actually see this could comment on my untested suggestion. Oh.. so this bug is supposed to only bite with DEBUG_PAGEALLOC=y ?? Then something else is broken, perhaps. I just saw a long traceback scroll off the top of the screen, with lots of bio_* functions in the list and assumed it was the same bug. Mmm.. I'll get out the camera and try it again now.. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [bug] ata subsystem related crash with latest -git
On Wed, 17 Oct 2007, Mark Lord wrote: > > It would be good to have something soon-ish. > This "dead at boot time" issue is impacting the general ability to test > patches against latest -git in time for the current merge window. In the meantime, does the patch I sent out help people? I'd like to get feedback, but I'm a lazy bum, and don't use DEBUG_PAGEALLOC myself, so I was hoping that people who actually see this could comment on my untested suggestion. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH] block: Isolate the buffer cache in it's own mappings.
If filesystems care at all they want absolute control over the buffer
cache. Controlling which buffers are dirty and when. Because we
keep the buffer cache in the page cache for the block device we have
not quite been giving filesystems that control leading to really weird
bugs.
In addition this tieing of the implemetation of block device caching
and the buffer cache has resulted in a much more complicated and
limited implementation then necessary. Block devices for example
don't need buffer_heads, and it is perfectly reasonable to cache
block devices in high memory.
To start untangling the worst of this mess this patch introduces a
second block device inode for the buffer cache. All buffer cache
operations are diverted to that use the new bd_metadata_inode, which
keeps the weirdness of the metadata requirements isolated in their
own little world.
This should enable future cleanups to diverge and simplify the
address_space_operations of the buffer cache and block device
page cache.
As a side effect of this cleanup the current ramdisk code should
be safe from dropping pages because we never place any buffer heads
on ramdisk pages.
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
---
fs/block_dev.c | 45 -
fs/buffer.c| 17 -
fs/ext3/dir.c |2 +-
fs/ext4/dir.c |2 +-
fs/fat/inode.c |2 +-
include/linux/fs.h |1 +
6 files changed, 48 insertions(+), 21 deletions(-)
diff --git a/fs/block_dev.c b/fs/block_dev.c
index 379a446..87a5760 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -59,10 +59,12 @@ static sector_t max_block(struct block_device *bdev)
/* Kill _all_ buffers and pagecache , dirty or not.. */
static void kill_bdev(struct block_device *bdev)
{
- if (bdev->bd_inode->i_mapping->nrpages == 0)
- return;
- invalidate_bh_lrus();
- truncate_inode_pages(bdev->bd_inode->i_mapping, 0);
+ if (bdev->bd_inode->i_mapping->nrpages)
+ truncate_inode_pages(bdev->bd_inode->i_mapping, 0);
+ if (bdev->bd_metadata_inode->i_mapping->nrpages) {
+ truncate_inode_pages(bdev->bd_metadata_inode->i_mapping, 0);
+ invalidate_bh_lrus();
+ }
}
int set_blocksize(struct block_device *bdev, int size)
@@ -80,6 +82,7 @@ int set_blocksize(struct block_device *bdev, int size)
sync_blockdev(bdev);
bdev->bd_block_size = size;
bdev->bd_inode->i_blkbits = blksize_bits(size);
+ bdev->bd_metadata_inode->i_blkbits = blksize_bits(size);
kill_bdev(bdev);
}
return 0;
@@ -114,7 +117,7 @@ static int
blkdev_get_block(struct inode *inode, sector_t iblock,
struct buffer_head *bh, int create)
{
- if (iblock >= max_block(I_BDEV(inode))) {
+ if (iblock >= max_block(inode->i_bdev)) {
if (create)
return -EIO;
@@ -126,7 +129,7 @@ blkdev_get_block(struct inode *inode, sector_t iblock,
*/
return 0;
}
- bh->b_bdev = I_BDEV(inode);
+ bh->b_bdev = inode->i_bdev;
bh->b_blocknr = iblock;
set_buffer_mapped(bh);
return 0;
@@ -136,7 +139,7 @@ static int
blkdev_get_blocks(struct inode *inode, sector_t iblock,
struct buffer_head *bh, int create)
{
- sector_t end_block = max_block(I_BDEV(inode));
+ sector_t end_block = max_block(inode->i_bdev);
unsigned long max_blocks = bh->b_size >> inode->i_blkbits;
if ((iblock + max_blocks) > end_block) {
@@ -152,7 +155,7 @@ blkdev_get_blocks(struct inode *inode, sector_t iblock,
}
}
- bh->b_bdev = I_BDEV(inode);
+ bh->b_bdev = inode->i_bdev;
bh->b_blocknr = iblock;
bh->b_size = max_blocks << inode->i_blkbits;
if (max_blocks)
@@ -167,7 +170,7 @@ blkdev_direct_IO(int rw, struct kiocb *iocb, const struct
iovec *iov,
struct file *file = iocb->ki_filp;
struct inode *inode = file->f_mapping->host;
- return blockdev_direct_IO_no_locking(rw, iocb, inode, I_BDEV(inode),
+ return blockdev_direct_IO_no_locking(rw, iocb, inode, inode->i_bdev,
iov, offset, nr_segs, blkdev_get_blocks, NULL);
}
@@ -244,7 +247,7 @@ blkdev_direct_IO(int rw, struct kiocb *iocb, const struct
iovec *iov,
loff_t pos, unsigned long nr_segs)
{
struct inode *inode = iocb->ki_filp->f_mapping->host;
- unsigned blkbits = blksize_bits(bdev_hardsect_size(I_BDEV(inode)));
+ unsigned blkbits = blksize_bits(bdev_hardsect_size(inode->i_bdev);
unsigned blocksize_mask = (1 << blkbits) - 1;
unsigned long seg = 0; /* iov segment iterator */
unsigned long nvec; /* number of bio vec needed */
@@ -292,7 +295,7 @@ blkdev_direct_IO(int rw, struct kiocb *iocb, const struct
iovec *iov,
Re: [RFC] remove netpoll receive code
Kgdb has been submitted for inclusion in the mainline kernel at this point, along with an additional change to the netpoll rx path. If it is the case that this needs to be implemented in another manner, that is ok but please do let me know what the plans are for the API so that the kgdboe code can be adapted. Thanks, Jason. Stephen Hemminger wrote: > The netpoll receive code is: > 1. Not used by any in-tree features, it is used by kgdb-over-ether. > 2. A nice hook for people doing nasty things like private binary network > stacks or rootkits. > 3. Unsecured by any of the normal firewalling code. > > Hopefully all distro's are smart enough to turn it off in their default > config *nudge, nudge*. > Doubly true for any distribution that claims to be secure or enterprise ready. > > I propose that we take out all the whole netpoll rx path. If/when kgdb gets > submitted > a better and alternative receive path can be added. > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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](memory hotplug) Make kmem_cache_node for SLUB on memory online to avoid panic(take 3)
On Thu, 18 Oct 2007 12:25:37 +0900 Yasunori Goto <[EMAIL PROTECTED]> wrote:
>
> This patch fixes panic due to access NULL pointer
> of kmem_cache_node at discard_slab() after memory online.
>
> When memory online is called, kmem_cache_nodes are created for
> all SLUBs for new node whose memory are available.
>
> slab_mem_going_online_callback() is called to make kmem_cache_node()
> in callback of memory online event. If it (or other callbacks) fails,
> then slab_mem_offline_callback() is called for rollback.
>
> In memory offline, slab_mem_going_offline_callback() is called to
> shrink all slub cache, then slab_mem_offline_callback() is called later.
>
> This patch is tested on my ia64 box.
>
> ...
>
> +#if defined(CONFIG_NUMA) && defined(CONFIG_MEMORY_HOTPLUG)
hm. There should be no linkage between memory hotpluggability and
NUMA, surely?
> +static int slab_mem_going_offline_callback(void *arg)
> +{
> + struct kmem_cache *s;
> +
> + down_read(_lock);
> + list_for_each_entry(s, _caches, list)
> + kmem_cache_shrink(s);
> + up_read(_lock);
> +
> + return 0;
> +}
> +
> +static void slab_mem_offline_callback(void *arg)
> +{
> + struct kmem_cache_node *n;
> + struct kmem_cache *s;
> + struct memory_notify *marg = arg;
> + int offline_node;
> +
> + offline_node = marg->status_change_nid;
> +
> + /*
> + * If the node still has available memory. we need kmem_cache_node
> + * for it yet.
> + */
> + if (offline_node < 0)
> + return;
> +
> + down_read(_lock);
> + list_for_each_entry(s, _caches, list) {
> + n = get_node(s, offline_node);
> + if (n) {
> + /*
> + * if n->nr_slabs > 0, slabs still exist on the node
> + * that is going down. We were unable to free them,
> + * and offline_pages() function shoudn't call this
> + * callback. So, we must fail.
> + */
> + BUG_ON(atomic_read(>nr_slabs));
Expereince tells us that WARN_ON is preferred for newly added code ;)
> + s->node[offline_node] = NULL;
> + kmem_cache_free(kmalloc_caches, n);
> + }
> + }
> + up_read(_lock);
> +}
> +
> +static int slab_mem_going_online_callback(void *arg)
> +{
> + struct kmem_cache_node *n;
> + struct kmem_cache *s;
> + struct memory_notify *marg = arg;
> + int nid = marg->status_change_nid;
> +
> + /*
> + * If the node's memory is already available, then kmem_cache_node is
> + * already created. Nothing to do.
> + */
> + if (nid < 0)
> + return 0;
> +
> + /*
> + * We are bringing a node online. No memory is availabe yet. We must
> + * allocate a kmem_cache_node structure in order to bring the node
> + * online.
> + */
> + down_read(_lock);
> + list_for_each_entry(s, _caches, list) {
> + /*
> + * XXX: kmem_cache_alloc_node will fallback to other nodes
> + * since memory is not yet available from the node that
> + * is brought up.
> + */
> + n = kmem_cache_alloc(kmalloc_caches, GFP_KERNEL);
> + if (!n)
> + return -ENOMEM;
err, we forgot slub_lock. I'll fix that.
> + init_kmem_cache_node(n);
> + s->node[nid] = n;
> + }
> + up_read(_lock);
> +
> + return 0;
> +}
So that's slub. Does slab already have this functionality or are you
not bothering to maintain slab in this area?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [bug] ata subsystem related crash with latest -git
Linus Torvalds wrote: On Wed, 17 Oct 2007, David Miller wrote: I believe that we have enough of a limited set of accessors to sg->page that we can more aggressively encode things in the lower bits. I'm thinking of encoding the low two bits of sg->page as follows: ... Yes, that sounds sane. It would be good to have something soon-ish. This "dead at boot time" issue is impacting the general ability to test patches against latest -git in time for the current merge window. :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 002/002](memory hotplug) rearrange patch for notifier of memory hotplug
On Thu, 18 Oct 2007 12:23:34 +0900 Yasunori Goto <[EMAIL PROTECTED]> wrote: > writeback_set_ratelimit(); > + > + if (onlined_pages) > + memory_notify(MEM_ONLINE, ); perhaps that open-coded writeback_set_ratelimit() should become a notifier callback. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: hda-intel: no soundcard with current linus' git tree
Maxim Levitsky wrote: What sound codec do you have? cat /proc/asound/Intel/codec* Attached. I'm on x86-64/Fedora 7 FWIW. You probably have different issue, since your card is probed correctly Agreed (though I was surprised that a correct probe did not yield a single printk). Jeff Codec: SigmaTel STAC9221D A2 Address: 2 Vendor Id: 0x83847683 Subsystem Id: 0x80860417 Revision Id: 0x103201 No Modem Function Group found Default PCM: rates [0x7e0]: 44100 48000 88200 96000 176400 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Default Amp-In caps: ofs=0x00, nsteps=0x0e, stepsize=0x05, mute=1 Default Amp-Out caps: ofs=0x7f, nsteps=0x7f, stepsize=0x02, mute=1 Node 0x02 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out Amp-Out caps: N/A Amp-Out vals: [0xff 0xff] Power: 0x0 Node 0x03 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out Amp-Out caps: N/A Amp-Out vals: [0xff 0xff] Power: 0x0 Node 0x04 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out Amp-Out caps: N/A Amp-Out vals: [0xff 0xff] Power: 0x0 Node 0x05 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out Amp-Out caps: N/A Amp-Out vals: [0xff 0xff] Power: 0x0 Node 0x06 [Audio Input] wcaps 0x1d0541: Stereo Power: 0x0 Connection: 1 0x17 Node 0x07 [Audio Input] wcaps 0x1d0541: Stereo Power: 0x0 Connection: 1 0x18 Node 0x08 [Audio Output] wcaps 0x40211: Stereo Digital PCM: rates [0x7e0]: 44100 48000 88200 96000 176400 192000 bits [0xe]: 16 20 24 formats [0x5]: PCM AC3 Node 0x09 [Audio Input] wcaps 0x140311: Stereo Digital PCM: rates [0x160]: 44100 48000 96000 bits [0xe]: 16 20 24 formats [0x5]: PCM AC3 Connection: 1 0x11 Node 0x0a [Pin Complex] wcaps 0x400181: Stereo Pincap 0x08173f: IN OUT HP Detect Pin Default 0x0221401f: [Jack] HP Out at Ext Front Conn = 1/8, Color = Green Pin-ctls: 0xc0: OUT HP Connection: 1 0x02 Node 0x0b [Pin Complex] wcaps 0x400181: Stereo Pincap 0x081737: IN OUT Detect Pin Default 0x01011012: [Jack] Line Out at Ext Rear Conn = 1/8, Color = Black Pin-ctls: 0x40: OUT Connection: 1 0x04 Node 0x0c [Pin Complex] wcaps 0x400181: Stereo Pincap 0x081737: IN OUT Detect Pin Default 0x01813024: [Jack] Line In at Ext Rear Conn = 1/8, Color = Blue Pin-ctls: 0x20: IN Connection: 1 0x03 Node 0x0d [Pin Complex] wcaps 0x400181: Stereo Pincap 0x08173f: IN OUT HP Detect Pin Default 0x01014010: [Jack] Line Out at Ext Rear Conn = 1/8, Color = Green Pin-ctls: 0x40: OUT Connection: 1 0x02 Node 0x0e [Pin Complex] wcaps 0x400081: Stereo Pincap 0x0824: IN Detect Pin Default 0x01a19021: [Jack] Mic at Ext Rear Conn = 1/8, Color = Pink Pin-ctls: 0x20: IN Node 0x0f [Pin Complex] wcaps 0x400181: Stereo Pincap 0x0837: IN OUT Detect Pin Default 0x01016011: [Jack] Line Out at Ext Rear Conn = 1/8, Color = Orange Pin-ctls: 0x40: OUT Connection: 1 0x05 Node 0x10 [Pin Complex] wcaps 0x400301: Stereo Digital Pincap 0x0810: OUT Pin Default 0x01452130: [Jack] SPDIF Out at Ext Rear Conn = Optical, Color = Grey Pin-ctls: 0x40: OUT Connection: 3 0x08* 0x17 0x19 Node 0x11 [Pin Complex] wcaps 0x430681: Stereo Digital Pincap 0x0810024: IN EAPD Detect Pin Default 0x4100: [N/A] Line Out at Ext N/A Conn = Unknown, Color = Unknown Pin-ctls: 0x00: Power: 0x0 Node 0x12 [Audio Selector] wcaps 0x30010d: Stereo Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0 Amp-Out vals: [0x00 0x00] Connection: 7 0x0e* 0x15 0x0f 0x0b 0x0c 0x0d 0x0a Node 0x13 [Audio Selector] wcaps 0x30010d: Stereo Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0 Amp-Out vals: [0x00 0x00] Connection: 7 0x0e* 0x15 0x0f 0x0b 0x0c 0x0d 0x0a Node 0x14 [Beep Generator Widget] wcaps 0x7c: Mono Amp-Out Amp-Out caps: ofs=0x03, nsteps=0x03, stepsize=0x17, mute=0 Amp-Out vals: [0x00] Node 0x15 [Pin Complex] wcaps 0x41: Stereo Pincap 0x0820: IN Pin Default 0x02a19320: [Jack] Mic at Ext Front Conn = 1/8, Color = Pink Pin-ctls: 0x20: IN Node 0x16 [Volume Knob Widget] wcaps 0x60: Mono Node 0x17 [Audio Selector] wcaps 0x300903: Stereo Amp-In Amp-In caps: N/A Amp-In vals: [0x07 0x07] Connection: 1 0x12 Node 0x18 [Audio Selector] wcaps 0x300903: Stereo Amp-In Amp-In caps: N/A Amp-In vals: [0x80 0x80] Connection: 1 0x13 Node 0x19 [Vendor Defined Widget] wcaps 0xf30201: Stereo Digital Node 0x1a [Audio Output] wcaps 0x30201: Stereo Digital Node 0x1b [Pin Complex] wcaps 0x400301: Stereo Digital Pincap 0x0810: OUT Pin Default 0x4100: [N/A] Line Out at Ext N/A Conn = Unknown, Color = Unknown Pin-ctls: 0x00: Connection: 1 0x1a
Re: hda-intel: no soundcard with current linus' git tree
On Thursday 18 October 2007 04:35:56 Jeff Garzik wrote: > Thomas Meyer wrote: > > $ dmesg > > > > [schnipp] > > > > ACPI: PCI Interrupt :00:1b.0[A] -> GSI 22 (level, low) -> IRQ 21 > > PCI: Enabling bus mastering for device :00:1b.0 > > PCI: Setting latency timer of device :00:1b.0 to 64 > > hda_codec: STAC922x, Apple subsys_id=106b0200 > > ACPI: PCI interrupt for device :00:1b.0 disabled > > HDA Intel: probe of :00:1b.0 failed with error -16 > > > > [schnipp] > > My sound ability similarly disappeared an upstream kernel <24 hours old > (includes the ALSA merge). > > [EMAIL PROTECTED] ~]$ lsmod | grep -i snd > snd_hda_intel 367396 2 > snd_pcm_oss42080 0 > snd_mixer_oss 16640 2 snd_pcm_oss > snd_pcm79624 2 snd_hda_intel,snd_pcm_oss > snd_page_alloc 9040 2 snd_hda_intel,snd_pcm > > [EMAIL PROTECTED] ~]$ lspci | grep -i audio > 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High > Definition Audio Controller (rev 01) > > [EMAIL PROTECTED] ~]$ dmesg | egrep -i 'snd|hda' > [EMAIL PROTECTED] ~]$ > > mplayer says > > AO: [alsa] 48000Hz 2ch s16le (2 bytes per sample) > > but no sound is emitted. > > Earlier kernels been working fine since hda_intel was introduced. > > Jeff > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > What sound codec do you have? cat /proc/asound/Intel/codec* You probably have different issue, since your card is probed correctly 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/
[PATCH 3/3] pciehp: hotplug: reinit hotplug h/w on resume from suspend
(repost to conform with akpm's subject line conventions)
Make use of the previously split out pcie_init_enable_events() function
to reinitialize the hotplug hardware on resume from suspend,
but only when pciehp_force==1. Otherwise behaviour is unmodified.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
---
--- git12/drivers/pci/hotplug/pciehp_ctrl.c 2007-10-17 19:28:23.0
-0400
+++ linux/drivers/pci/hotplug/pciehp_ctrl.c 2007-10-17 19:31:22.0
-0400
@@ -37,7 +37,6 @@
#include "pciehp.h"
static void interrupt_event_handler(struct work_struct *work);
-static int pciehp_disable_slot(struct slot *p_slot);
static int queue_interrupt_event(struct slot *p_slot, u32 event_type)
{
--- git12/drivers/pci/hotplug/pciehp.h 2007-10-17 19:28:23.0 -0400
+++ linux/drivers/pci/hotplug/pciehp.h 2007-10-17 19:32:03.0 -0400
@@ -162,6 +162,8 @@
extern void pciehp_queue_pushbutton_work(struct work_struct *work);
int pcie_init(struct controller *ctrl, struct pcie_device *dev);
int pciehp_enable_slot(struct slot *p_slot);
+int pciehp_disable_slot(struct slot *p_slot);
+int pcie_init_hardware(struct controller *ctrl, struct pcie_device *dev);
static inline struct slot *pciehp_find_slot(struct controller *ctrl, u8 device)
{
--- git12/drivers/pci/hotplug/pciehp_core.c 2007-10-17 19:28:23.0
-0400
+++ linux/drivers/pci/hotplug/pciehp_core.c 2007-10-17 19:33:05.0
-0400
@@ -510,6 +510,24 @@
static int pciehp_resume (struct pcie_device *dev)
{
printk("%s ENTRY\n", __FUNCTION__);
+ if (pciehp_force) {
+ struct pci_dev *pdev = dev->port;
+ struct controller *ctrl = pci_get_drvdata(pdev);
+ struct slot *t_slot;
+ u8 status;
+
+ /* reinitialize the chipset's event detection logic */
+ pcie_init_hardware(ctrl, dev);
+
+ t_slot = pciehp_find_slot(ctrl, ctrl->slot_device_offset);
+
+ /* Check if slot is occupied */
+ t_slot->hpc_ops->get_adapter_status(t_slot, );
+ if (status)
+ pciehp_enable_slot(t_slot);
+ else
+ pciehp_disable_slot(t_slot);
+ }
return 0;
}
#endif
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/3] pciehp: hotplug: split out hardware init from pcie_init()
(repost to conform with akpm's subject line conventions)
One of three patches to fix PCIe Hotplug so that it works with ExpressCard slots
on Dell notebooks (and others?) in conjunction with modparam of pciehp_force=1
Split out the hotplug hardware initialization code from pcie_init()
into pcie_init_enable_events(), without changing any functionality.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
---
--- a/drivers/pci/hotplug/pciehp_hpc.c 2007-10-17 19:06:38.0 -0400
+++ b/drivers/pci/hotplug/pciehp_hpc.c 2007-10-17 19:29:42.0 -0400
@@ -1067,99 +1067,22 @@
}
#endif
-int pcie_init(struct controller * ctrl, struct pcie_device *dev)
+int pcie_init_hardware(struct controller *ctrl, struct pcie_device *dev)
{
int rc;
u16 temp_word;
- u16 cap_reg;
u16 intr_enable = 0;
u32 slot_cap;
- int cap_base;
- u16 slot_status, slot_ctrl;
+ u16 slot_status;
struct pci_dev *pdev;
pdev = dev->port;
- ctrl->pci_dev = pdev;/* save pci_dev in context */
-
- dbg("%s: hotplug controller vendor id 0x%x device id 0x%x\n",
- __FUNCTION__, pdev->vendor, pdev->device);
-
- if ((cap_base = pci_find_capability(pdev, PCI_CAP_ID_EXP)) == 0) {
- dbg("%s: Can't find PCI_CAP_ID_EXP (0x10)\n", __FUNCTION__);
- goto abort_free_ctlr;
- }
-
- ctrl->cap_base = cap_base;
-
- dbg("%s: pcie_cap_base %x\n", __FUNCTION__, cap_base);
-
- rc = pciehp_readw(ctrl, CAPREG, _reg);
- if (rc) {
- err("%s: Cannot read CAPREG register\n", __FUNCTION__);
- goto abort_free_ctlr;
- }
- dbg("%s: CAPREG offset %x cap_reg %x\n",
- __FUNCTION__, ctrl->cap_base + CAPREG, cap_reg);
-
- if (((cap_reg & SLOT_IMPL) == 0) ||
- (((cap_reg & DEV_PORT_TYPE) != 0x0040)
- && ((cap_reg & DEV_PORT_TYPE) != 0x0060))) {
- dbg("%s : This is not a root port or the port is not "
- "connected to a slot\n", __FUNCTION__);
- goto abort_free_ctlr;
- }
rc = pciehp_readl(ctrl, SLOTCAP, _cap);
if (rc) {
err("%s: Cannot read SLOTCAP register\n", __FUNCTION__);
goto abort_free_ctlr;
}
- dbg("%s: SLOTCAP offset %x slot_cap %x\n",
- __FUNCTION__, ctrl->cap_base + SLOTCAP, slot_cap);
-
- if (!(slot_cap & HP_CAP)) {
- dbg("%s : This slot is not hot-plug capable\n", __FUNCTION__);
- goto abort_free_ctlr;
- }
- /* For debugging purpose */
- rc = pciehp_readw(ctrl, SLOTSTATUS, _status);
- if (rc) {
- err("%s: Cannot read SLOTSTATUS register\n", __FUNCTION__);
- goto abort_free_ctlr;
- }
- dbg("%s: SLOTSTATUS offset %x slot_status %x\n",
- __FUNCTION__, ctrl->cap_base + SLOTSTATUS, slot_status);
-
- rc = pciehp_readw(ctrl, SLOTCTRL, _ctrl);
- if (rc) {
- err("%s: Cannot read SLOTCTRL register\n", __FUNCTION__);
- goto abort_free_ctlr;
- }
- dbg("%s: SLOTCTRL offset %x slot_ctrl %x\n",
- __FUNCTION__, ctrl->cap_base + SLOTCTRL, slot_ctrl);
-
- for (rc = 0; rc < DEVICE_COUNT_RESOURCE; rc++)
- if (pci_resource_len(pdev, rc) > 0)
- dbg("pci resource[%d] start=0x%llx(len=0x%llx)\n", rc,
- (unsigned long long)pci_resource_start(pdev, rc),
- (unsigned long long)pci_resource_len(pdev, rc));
-
- info("HPC vendor_id %x device_id %x ss_vid %x ss_did %x\n",
-pdev->vendor, pdev->device,
-pdev->subsystem_vendor, pdev->subsystem_device);
-
- mutex_init(>crit_sect);
- mutex_init(>ctrl_lock);
- spin_lock_init(>lock);
-
- /* setup wait queue */
- init_waitqueue_head(>queue);
-
- /* return PCI Controller Info */
- ctrl->slot_device_offset = 0;
- ctrl->num_slots = 1;
- ctrl->first_slot = slot_cap >> 19;
- ctrl->ctrlcap = slot_cap & 0x007f;
/* Mask Hot-plug Interrupt Enable */
rc = pciehp_readw(ctrl, SLOTCTRL, _word);
@@ -1280,8 +1203,6 @@
goto abort_disable_intr;
}
- ctrl->hpc_ops = _hpc_ops;
-
return 0;
/* We end up here for the many possible ways to fail this API. */
@@ -1303,3 +1224,105 @@
abort_free_ctlr:
return -1;
}
+
+int pcie_init(struct controller *ctrl, struct pcie_device *dev)
+{
+ int rc;
+ u16 cap_reg;
+ u32 slot_cap;
+ int cap_base;
+ u16 slot_status, slot_ctrl;
+ struct pci_dev *pdev;
+
+ pdev = dev->port;
+ ctrl->pci_dev = pdev;/* save pci_dev in context */
+
+ dbg("%s: hotplug controller vendor id 0x%x device id 0x%x\n",
+ __FUNCTION__, pdev->vendor, pdev->device);
+
+ cap_base =
[PATCH 1/3] pciehp: hotplug: deal with pre-inserted ExpressCards
(repost to conform with akpm's subject line conventions)
One of three patches to fix PCIe Hotplug so that it works with ExpressCard slots
on Dell notebooks (and others?) in conjunction with modparam of pciehp_force=1.
Fix pciehp_probe() to deal with ExpressCard cards
that were inserted prior to the driver being loaded.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
---
--- a/drivers/pci/hotplug/pciehp_ctrl.c 2007-10-17 22:30:19.0 -0400
+++ b/drivers/pci/hotplug/pciehp_ctrl.c 2007-10-17 22:29:59.0 -0400
@@ -37,7 +37,6 @@
#include "pciehp.h"
static void interrupt_event_handler(struct work_struct *work);
-static int pciehp_enable_slot(struct slot *p_slot);
static int pciehp_disable_slot(struct slot *p_slot);
static int queue_interrupt_event(struct slot *p_slot, u32 event_type)
--- git12/drivers/pci/hotplug/pciehp.h 2007-10-17 22:30:19.0 -0400
+++ linux/drivers/pci/hotplug/pciehp.h 2007-10-17 22:29:59.0 -0400
@@ -161,6 +161,7 @@
extern int pciehp_unconfigure_device(struct slot *p_slot);
extern void pciehp_queue_pushbutton_work(struct work_struct *work);
int pcie_init(struct controller *ctrl, struct pcie_device *dev);
+int pciehp_enable_slot(struct slot *p_slot);
static inline struct slot *pciehp_find_slot(struct controller *ctrl, u8 device)
{
--- git12/drivers/pci/hotplug/pciehp_core.c 2007-10-17 22:30:19.0
-0400
+++ linux/drivers/pci/hotplug/pciehp_core.c 2007-10-17 22:36:06.0
-0400
@@ -471,6 +471,11 @@
t_slot = pciehp_find_slot(ctrl, ctrl->slot_device_offset);
t_slot->hpc_ops->get_adapter_status(t_slot, ); /* Check if slot
is occupied */
+ if (value) {
+ rc = pciehp_enable_slot(t_slot);
+ if (rc) /* -ENODEV: shouldn't happen, but deal with it */
+ value = 0;
+ }
if ((POWER_CTRL(ctrl->ctrlcap)) && !value) {
rc = t_slot->hpc_ops->power_off_slot(t_slot); /* Power off slot
if not occupied*/
if (rc)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] rd: Mark ramdisk buffers heads dirty
Chris Mason <[EMAIL PROTECTED]> writes: > On Wed, 2007-10-17 at 17:28 -0600, Eric W. Biederman wrote: >> Chris Mason <[EMAIL PROTECTED]> writes: >> >> > So, the problem is using the Dirty bit to indicate pinned. You're >> > completely right that our current setup of buffer heads and pages and >> > filesystpem metadata is complex and difficult. >> > >> > But, moving the buffer heads off of the page cache pages isn't going to >> > make it any easier to use dirty as pinned, especially in the face of >> > buffer_head users for file data pages. >> >> Let me specific. Not moving buffer_heads off of page cache pages, >> moving buffer_heads off of the block devices page cache pages. >> >> My problem is the coupling of how block devices are cached and the >> implementation of buffer heads, and by removing that coupling >> we can generally make things better. Currently that coupling >> means silly things like all block devices are cached in low memory. >> Which probably isn't what you want if you actually have a use >> for block devices. >> >> For the ramdisk case in particular what this means is that there >> are no more users that create buffer_head mappings on the block >> device cache so using the dirty bit will be safe. > > Ok, we move the buffer heads off to a different inode, and that indoe > has pages. The pages on the inode still need to get pinned, how does > that pinning happen? > The problem you described where someone cleans a page because the buffer > heads are clean happens already without help from userland. So, keeping > the pages away from userland won't save them from cleaning. > > Sorry if I'm reading your suggestion wrong... Yes. I was suggesting to continue to pin the pages for the page cache pages block device inode, and having the buffer cache live on some other inode. Thus not causing me problems by adding clean buffer_heads to my dirty pages. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [PATCH 2/2] capabilities: implement 64-bit capabilities
On Wed, 17 Oct 2007 21:59:20 -0500 "Serge E. Hallyn" <[EMAIL PROTECTED]> wrote: > Quoting Andrew Morton ([EMAIL PROTECTED]): > > On Tue, 16 Oct 2007 16:41:59 -0500 > > "Serge E. Hallyn" <[EMAIL PROTECTED]> wrote: > > > > > To properly test this the libcap code will need to be updated first, > > > which I'm looking at now... > > > > This seems fairly significant. I asusme that this patch won't break > > presently-deployed libcap? > > It will break libcap. yikes, dropped! > And I'm not sure of the right way to address it. > So I was hoping to hear some ideas from Andrew Morgan, Chris Wright, and > Kaigai. > > We can introduce new capget64() and capset64() calls, and have > capget() return -EINVAL or -EAGAIN if a high bit would be needed to > accurately get the task's capabilities. > > Or we can require a new libcap, since capget and capset aren't > required for most day-to-day function anyway. > > I guess now that I've written this out, it seems pretty clear > that capget64() and capget64() are the way to go. Any objections? Sounds sane. New syscalls are cheap and it's clear separation. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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](memory hotplug) Make kmem_cache_node for SLUB on memory online to avoid panic(take 3)
This patch fixes panic due to access NULL pointer
of kmem_cache_node at discard_slab() after memory online.
When memory online is called, kmem_cache_nodes are created for
all SLUBs for new node whose memory are available.
slab_mem_going_online_callback() is called to make kmem_cache_node()
in callback of memory online event. If it (or other callbacks) fails,
then slab_mem_offline_callback() is called for rollback.
In memory offline, slab_mem_going_offline_callback() is called to
shrink all slub cache, then slab_mem_offline_callback() is called later.
This patch is tested on my ia64 box.
Please apply.
Signed-off-by: Yasunori Goto <[EMAIL PROTECTED]>
---
mm/slub.c | 115 ++
1 file changed, 115 insertions(+)
Index: current/mm/slub.c
===
--- current.orig/mm/slub.c 2007-10-17 21:17:53.0 +0900
+++ current/mm/slub.c 2007-10-17 22:23:08.0 +0900
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
/*
* Lock order:
@@ -2688,6 +2689,118 @@ int kmem_cache_shrink(struct kmem_cache
}
EXPORT_SYMBOL(kmem_cache_shrink);
+#if defined(CONFIG_NUMA) && defined(CONFIG_MEMORY_HOTPLUG)
+static int slab_mem_going_offline_callback(void *arg)
+{
+ struct kmem_cache *s;
+
+ down_read(_lock);
+ list_for_each_entry(s, _caches, list)
+ kmem_cache_shrink(s);
+ up_read(_lock);
+
+ return 0;
+}
+
+static void slab_mem_offline_callback(void *arg)
+{
+ struct kmem_cache_node *n;
+ struct kmem_cache *s;
+ struct memory_notify *marg = arg;
+ int offline_node;
+
+ offline_node = marg->status_change_nid;
+
+ /*
+* If the node still has available memory. we need kmem_cache_node
+* for it yet.
+*/
+ if (offline_node < 0)
+ return;
+
+ down_read(_lock);
+ list_for_each_entry(s, _caches, list) {
+ n = get_node(s, offline_node);
+ if (n) {
+ /*
+* if n->nr_slabs > 0, slabs still exist on the node
+* that is going down. We were unable to free them,
+* and offline_pages() function shoudn't call this
+* callback. So, we must fail.
+*/
+ BUG_ON(atomic_read(>nr_slabs));
+
+ s->node[offline_node] = NULL;
+ kmem_cache_free(kmalloc_caches, n);
+ }
+ }
+ up_read(_lock);
+}
+
+static int slab_mem_going_online_callback(void *arg)
+{
+ struct kmem_cache_node *n;
+ struct kmem_cache *s;
+ struct memory_notify *marg = arg;
+ int nid = marg->status_change_nid;
+
+ /*
+* If the node's memory is already available, then kmem_cache_node is
+* already created. Nothing to do.
+*/
+ if (nid < 0)
+ return 0;
+
+ /*
+* We are bringing a node online. No memory is availabe yet. We must
+* allocate a kmem_cache_node structure in order to bring the node
+* online.
+*/
+ down_read(_lock);
+ list_for_each_entry(s, _caches, list) {
+ /*
+* XXX: kmem_cache_alloc_node will fallback to other nodes
+* since memory is not yet available from the node that
+* is brought up.
+*/
+ n = kmem_cache_alloc(kmalloc_caches, GFP_KERNEL);
+ if (!n)
+ return -ENOMEM;
+ init_kmem_cache_node(n);
+ s->node[nid] = n;
+ }
+ up_read(_lock);
+
+ return 0;
+}
+
+static int slab_memory_callback(struct notifier_block *self,
+ unsigned long action, void *arg)
+{
+ int ret = 0;
+
+ switch (action) {
+ case MEM_GOING_ONLINE:
+ ret = slab_mem_going_online_callback(arg);
+ break;
+ case MEM_GOING_OFFLINE:
+ ret = slab_mem_going_offline_callback(arg);
+ break;
+ case MEM_OFFLINE:
+ case MEM_CANCEL_ONLINE:
+ slab_mem_offline_callback(arg);
+ break;
+ case MEM_ONLINE:
+ case MEM_CANCEL_OFFLINE:
+ break;
+ }
+
+ ret = notifier_from_errno(ret);
+ return ret;
+}
+
+#endif /* CONFIG_MEMORY_HOTPLUG */
+
/
* Basic setup of slabs
***/
@@ -2709,6 +2822,8 @@ void __init kmem_cache_init(void)
sizeof(struct kmem_cache_node), GFP_KERNEL);
kmalloc_caches[0].refcount = -1;
caches++;
+
+ hotplug_memory_notifier(slab_memory_callback, 1);
#endif
/* Able to allocate the per
[Patch 002/002](memory hotplug) rearrange patch for notifier of memory hotplug
Current memory notifier has some defects yet. (Fortunately, nothing uses it.)
This patch is to fix and rearrange for them.
- Add information of start_pfn, nr_pages, and node id if node status is
changes from/to memoryless node for callback functions.
Callbacks can't do anything without those information.
- Add notification going-online status.
It is necessary for creating per node structure before the node's
pages are available.
- Move GOING_OFFLINE status notification after page isolation.
It is good place for return memory like cache for callback,
because returned page is not used again.
- Make CANCEL events for rollingback when error occurs.
- Delete MEM_MAPPING_INVALID notification. It will be not used.
- Fix compile error of (un)register_memory_notifier().
Signed-off-by: Yasunori Goto <[EMAIL PROTECTED]>
---
drivers/base/memory.c |9 +
include/linux/memory.h | 27 +++
mm/memory_hotplug.c| 48 +---
3 files changed, 61 insertions(+), 23 deletions(-)
Index: current/drivers/base/memory.c
===
--- current.orig/drivers/base/memory.c 2007-10-17 21:17:54.0 +0900
+++ current/drivers/base/memory.c 2007-10-17 21:21:30.0 +0900
@@ -137,7 +137,7 @@ static ssize_t show_mem_state(struct sys
return len;
}
-static inline int memory_notify(unsigned long val, void *v)
+int memory_notify(unsigned long val, void *v)
{
return blocking_notifier_call_chain(_chain, val, v);
}
@@ -183,7 +183,6 @@ memory_block_action(struct memory_block
break;
case MEM_OFFLINE:
mem->state = MEM_GOING_OFFLINE;
- memory_notify(MEM_GOING_OFFLINE, NULL);
start_paddr = page_to_pfn(first_page) << PAGE_SHIFT;
ret = remove_memory(start_paddr,
PAGES_PER_SECTION << PAGE_SHIFT);
@@ -191,7 +190,6 @@ memory_block_action(struct memory_block
mem->state = old_state;
break;
}
- memory_notify(MEM_MAPPING_INVALID, NULL);
break;
default:
printk(KERN_WARNING "%s(%p, %ld) unknown action: %ld\n",
@@ -199,11 +197,6 @@ memory_block_action(struct memory_block
WARN_ON(1);
ret = -EINVAL;
}
- /*
-* For now, only notify on successful memory operations
-*/
- if (!ret)
- memory_notify(action, NULL);
return ret;
}
Index: current/include/linux/memory.h
===
--- current.orig/include/linux/memory.h 2007-10-17 21:17:54.0 +0900
+++ current/include/linux/memory.h 2007-10-17 21:21:30.0 +0900
@@ -41,18 +41,15 @@ struct memory_block {
#defineMEM_ONLINE (1<<0) /* exposed to userspace */
#defineMEM_GOING_OFFLINE (1<<1) /* exposed to userspace */
#defineMEM_OFFLINE (1<<2) /* exposed to userspace */
+#defineMEM_GOING_ONLINE(1<<3)
+#defineMEM_CANCEL_ONLINE (1<<4)
+#defineMEM_CANCEL_OFFLINE (1<<5)
-/*
- * All of these states are currently kernel-internal for notifying
- * kernel components and architectures.
- *
- * For MEM_MAPPING_INVALID, all notifier chains with priority >0
- * are called before pfn_to_page() becomes invalid. The priority=0
- * entry is reserved for the function that actually makes
- * pfn_to_page() stop working. Any notifiers that want to be called
- * after that should have priority <0.
- */
-#defineMEM_MAPPING_INVALID (1<<3)
+struct memory_notify {
+ unsigned long start_pfn;
+ unsigned long nr_pages;
+ int status_change_nid;
+};
struct notifier_block;
struct mem_section;
@@ -69,12 +66,18 @@ static inline int register_memory_notifi
static inline void unregister_memory_notifier(struct notifier_block *nb)
{
}
+static inline int memory_notify(unsigned long val, void *v)
+{
+ return 0;
+}
#else
+extern int register_memory_notifier(struct notifier_block *nb);
+extern void unregister_memory_notifier(struct notifier_block *nb);
extern int register_new_memory(struct mem_section *);
extern int unregister_memory_section(struct mem_section *);
extern int memory_dev_init(void);
extern int remove_memory_block(unsigned long, struct mem_section *, int);
-
+extern int memory_notify(unsigned long val, void *v);
#define CONFIG_MEM_BLOCK_SIZE (PAGES_PER_SECTION<= end_pfn);
/* at least, alignment against pageblock is necessary */
@@ -480,11 +502,27 @@ int offline_pages(unsigned long start_pf
we assume this for now. .*/
if
[Patch 001/002](memory hotplug) Make description of memory hotplug notifier in document
Add description about event notification callback routine to the document.
Signed-off-by: Yasunori Goto <[EMAIL PROTECTED]>
---
Documentation/memory-hotplug.txt | 58 ---
1 file changed, 55 insertions(+), 3 deletions(-)
Index: current/Documentation/memory-hotplug.txt
===
--- current.orig/Documentation/memory-hotplug.txt 2007-10-17
15:57:50.0 +0900
+++ current/Documentation/memory-hotplug.txt2007-10-17 21:26:30.0
+0900
@@ -2,7 +2,8 @@
Memory Hotplug
==
-Last Updated: Jul 28 2007
+Created: Jul 28 2007
+Add description of notifier of memory hotplug Oct 11 2007
This document is about memory hotplug including how-to-use and current status.
Because Memory Hotplug is still under development, contents of this text will
@@ -24,7 +25,8 @@ be changed often.
6.1 Memory offline and ZONE_MOVABLE
6.2. How to offline memory
7. Physical memory remove
-8. Future Work List
+8. Memory hotplug event notifier
+9. Future Work List
Note(1): x86_64's has special implementation for memory hotplug.
This text does not describe it.
@@ -307,8 +309,58 @@ Need more implementation yet
- Notification completion of remove works by OS to firmware.
- Guard from remove if not yet.
+
+8. Memory hotplug event notifier
+
+Memory hotplug has event notifer. There are 6 types of notification.
+
+MEMORY_GOING_ONLINE
+ Generated before new memory becomes available in order to be able to
+ prepare subsystems to handle memory. The page allocator is still unable
+ to allocate from the new memory.
+
+MEMORY_CANCEL_ONLINE
+ Generated if MEMORY_GOING_ONLINE fails.
+
+MEMORY_ONLINE
+ Generated when memory has succesfully brought online. The callback may
+ allocate pages from the new memory.
+
+MEMORY_GOING_OFFLINE
+ Generated to begin the process of offlining memory. Allocations are no
+ longer possible from the memory but some of the memory to be offlined
+ is still in use. The callback can be used to free memory known to a
+ subsystem from the indicated memory section.
+
+MEMORY_CANCEL_OFFLINE
+ Generated if MEMORY_GOING_OFFLINE fails. Memory is available again from
+ the section that we attempted to offline.
+
+MEMORY_OFFLINE
+ Generated after offlining memory is complete.
+
+A callback routine can be registered by
+ hotplug_memory_notifier(callback_func, priority)
+
+The second argument of callback function (action) is event types of above.
+The third argument is passed by pointer of struct memory_notify.
+
+struct memory_notify {
+ unsigned long start_pfn;
+ unsigned long nr_pages;
+ int status_cahnge_nid;
+}
+
+start_pfn is start_pfn of online/offline memory.
+nr_pages is # of pages of online/offline memory.
+status_change_nid is set node id when N_HIGH_MEMORY of nodemask is (will be)
+set/clear. It means a new(memoryless) node gets new memory by online and a
+node loses all memory. If this is -1, then nodemask status is not changed.
+If status_changed_nid >= 0, callback should create/discard structures for the
+node if necessary.
+
--
-8. Future Work
+9. Future Work
--
- allowing memory hot-add to ZONE_MOVABLE. maybe we need some switch like
sysctl or new control file.
--
Yasunori Goto
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 000/002](memory hotplug) Rearrange notifier of memory hotplug (take 2)
Hello. This patch set is to rearrange event notifier for memory hotplug, because the old notifier has some defects. For example, there is no information like new memory's pfn and # of pages for callback functions. Fortunately, nothing uses this notifier so far, there is no impact by this change. (SLUB will use this after this patch set to make kmem_cache_node structure). In addition, descriptions of notifer is added to memory hotplug document. This patch was a part of patch set to make kmem_cache_node of SLUB to avoid panic of memory online. But, I think this change becomes not only for SLUB but also for others. So, I extracted this from it. This patch set is for 2.6.23-mm1. I tested this patch on my ia64 box. Please apply. Bye. -- Yasunori Goto - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 /proc/acpi/alarm BCD alarm encodings
Linus Torvalds wrote:
On Wed, 26 Sep 2007, Mark Lord wrote:
The existing code in linux/drivers/acpi/sleep/proc.c has a nasty bug
that prevents BCD mode from working: the code converts binary to BCD
three times in a row, each time taking the previous result.
This thoroughly mangles the alarm timestamp, and never worked.
The patch below fixes it, by removing the first two (bogus)
conversions, and leaving only the final conversion in place.
Tested & working on my system here.
Actually, it cannot possibly really fix it.
That code is doing all the arithmetic in non-BCD mode, but the "adjust"
case doesn't do a BCD_TO_BIN() on that arithmetic.
In other words, the logic you removed was certainly total crap, but
there's more crap remaining inside the "if (adjust)" logic. I just suspect
you never tested that part (ie using a string that starts with '+').
In fact, for the non-broken case, the old broken code *should* have been a
no-op, since it did BIN_TO_BCD() followed by BCD_TO_BIN(). It then totally
stupidly seemed to expect that the "adjust" case would do a BCD addition!
So I don't even see why your patch should have mattered or worked!
So how about this cleanup instead? Does this work for you?
NOTE! I wanted to switch "acpi_system_alarm_seq_show()" over to this too,
but that code has a strange rule:
if (acpi_gbl_FADT.day_alarm)
/* ACPI spec: only low 6 its should be cared */
day = CMOS_READ(acpi_gbl_FADT.day_alarm) & 0x3F;
else
day = CMOS_READ(RTC_DAY_OF_MONTH);
and note the "& 0x3f" which is done in BCD mode. Strange. But we always
write zero (which may or may not be correct). So I'd have to add a mask to
the interface, and I decided it wasn't worth it until somebody talks about
how that thing actually works..
Linus, this is your patch from a few weeks ago.
It (still) solves problems for me here.
This should go into 2.6.24.
Fix BIN_TO_BCD()/BCD_TO_BIN() handling when setting the real-time alarm clock.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
---
drivers/acpi/sleep/proc.c | 66 +++-
1 files changed, 29 insertions(+), 37 deletions(-)
diff --git a/drivers/acpi/sleep/proc.c b/drivers/acpi/sleep/proc.c
index 3839efd..1538355 100644
--- a/drivers/acpi/sleep/proc.c
+++ b/drivers/acpi/sleep/proc.c
@@ -194,6 +194,23 @@ static int get_date_field(char **p, u32 * value)
return result;
}
+/* Read a possibly BCD register, always return binary */
+static u32 cmos_bcd_read(int offset, int rtc_control)
+{
+ u32 val = CMOS_READ(offset);
+ if (!(rtc_control & RTC_DM_BINARY) || RTC_ALWAYS_BCD)
+ BCD_TO_BIN(val);
+ return val;
+}
+
+/* Write binary value into possibly BCD register */
+static void cmos_bcd_write(u32 val, int offset, int rtc_control)
+{
+ if (!(rtc_control & RTC_DM_BINARY) || RTC_ALWAYS_BCD)
+ BIN_TO_BCD(val);
+ CMOS_WRITE(val, offset);
+}
+
static ssize_t
acpi_system_write_alarm(struct file *file,
const char __user * buffer, size_t count, loff_t * ppos)
@@ -258,35 +275,18 @@ acpi_system_write_alarm(struct file *file,
spin_lock_irq(_lock);
rtc_control = CMOS_READ(RTC_CONTROL);
- if (!(rtc_control & RTC_DM_BINARY) || RTC_ALWAYS_BCD) {
- BIN_TO_BCD(yr);
- BIN_TO_BCD(mo);
- BIN_TO_BCD(day);
- BIN_TO_BCD(hr);
- BIN_TO_BCD(min);
- BIN_TO_BCD(sec);
- }
if (adjust) {
- yr += CMOS_READ(RTC_YEAR);
- mo += CMOS_READ(RTC_MONTH);
- day += CMOS_READ(RTC_DAY_OF_MONTH);
- hr += CMOS_READ(RTC_HOURS);
- min += CMOS_READ(RTC_MINUTES);
- sec += CMOS_READ(RTC_SECONDS);
+ yr += cmos_bcd_read(RTC_YEAR, rtc_control);
+ mo += cmos_bcd_read(RTC_MONTH, rtc_control);
+ day += cmos_bcd_read(RTC_DAY_OF_MONTH, rtc_control);
+ hr += cmos_bcd_read(RTC_HOURS, rtc_control);
+ min += cmos_bcd_read(RTC_MINUTES, rtc_control);
+ sec += cmos_bcd_read(RTC_SECONDS, rtc_control);
}
spin_unlock_irq(_lock);
- if (!(rtc_control & RTC_DM_BINARY) || RTC_ALWAYS_BCD) {
- BCD_TO_BIN(yr);
- BCD_TO_BIN(mo);
- BCD_TO_BIN(day);
- BCD_TO_BIN(hr);
- BCD_TO_BIN(min);
- BCD_TO_BIN(sec);
- }
-
if (sec > 59) {
min++;
sec -= 60;
@@ -307,14 +307,6 @@ acpi_system_write_alarm(struct file *file,
yr++;
mo -= 12;
}
- if (!(rtc_control & RTC_DM_BINARY) || RTC_ALWAYS_BCD) {
- BIN_TO_BCD(yr);
- BIN_TO_BCD(mo);
- BIN_TO_BCD(day);
- BIN_TO_BCD(hr);
- BIN_TO_BCD(min);
- BIN_TO_BCD(sec);
- }
Re: [PATCH] Simplify /proc/cgroups
On Wed, 17 Oct 2007 19:56:36 -0700 (PDT) [EMAIL PROTECTED] (Paul Menage) wrote: > + seq_printf(m, "%s\t%d\t%d\n", > +ss->name, ss->root->subsys_bits, > +ss->root->number_of_cgroups); > } Because subsys_bits is unsigned long, then %lu or %lx is better. Thanks, -Kame - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [PATCH 2/2] capabilities: implement 64-bit capabilities
--- "Serge E. Hallyn" <[EMAIL PROTECTED]> wrote: > Quoting Andrew Morton ([EMAIL PROTECTED]): > > On Tue, 16 Oct 2007 16:41:59 -0500 > > "Serge E. Hallyn" <[EMAIL PROTECTED]> wrote: > > > > > To properly test this the libcap code will need to be updated first, > > > which I'm looking at now... > > > > This seems fairly significant. I asusme that this patch won't break > > presently-deployed libcap? > > It will break libcap. And I'm not sure of the right way to address it. > So I was hoping to hear some ideas from Andrew Morgan, Chris Wright, and > Kaigai. > > We can introduce new capget64() and capset64() calls, and have > capget() return -EINVAL or -EAGAIN if a high bit would be needed to > accurately get the task's capabilities. > > Or we can require a new libcap, since capget and capset aren't > required for most day-to-day function anyway. > > I guess now that I've written this out, it seems pretty clear > that capget64() and capget64() are the way to go. Any objections? Not from me. Thank you. Casey Schaufler [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 0/3] Fix two PEIe hotplug issues
Mark Lord wrote: Fix PCIe Hotplug so that it works with ExpressCard slots on Dell notebooks (and others?) in conjunction with the modparam of pciehp_force=1. To make things simpler for distro people, I'm contemplating another patch in this series, to allow something like: pciehp_force=2 This would then *try* the ACPI BIOS calls, and only fall back to pcie_force=1 if the BIOS support fails. This would be an ideal default for most desktop/notebook distros to consider using. Without this, they don't have any good choice: use the defaults, and things fail on the most popular brand of machines in the marketplace. Use pciehp_force=1, and they may break (?) on other brands. So a hybrid of the two seems best. Pity it couldn't be the default behaviour, though. Or could it? We're early enough in the 2.6.24 cycle for it.. Opinions? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: LSM conversion to static interface
On Wed, 17 Oct 2007 18:34:16 -0700 "Thomas Fricaccia" <[EMAIL PROTECTED]> wrote: > > But then I noticed that, while the LSM would remain in existence, it > was being closed to out-of-tree security frameworks. Yikes! Since > then, I've been following the rush to put SMACK, TOMOYO and AppArmor > "in-tree". I think your statement isn't quite correct: it's not closed to out of tree security frameworks; it's no longer possible to do MODULES. You can easily patch any of the ones you mention in (and in fact, this is how distros that use apparmor will use it anyway). You are totally free to compile whatever security module you want into your kernel and use it... I would actually highly encourage that; the freedom to do that is what Linux is about. The problem with "loadable security modules" is actually fundamental, and afaik even the AppArmor people mostly agree with this: The security any such system provides is generally based on being in a "Safe" state from the start, so knowing all objects that go through the system, being able to label them (or at least do something with them, I realize the term "label" is maybe seen as SELinux specific, but I mean it in a generic way; the SELinux people will tell you I'm not a fan of their approach *at all*), check them etc etc. A loadable-module approach can't do that, it would, at load time, have to inspect the system, make sure no operations are in "half process" when the LSM hooks go into effect (just think of it: if you have an operation that gets 3 LSM checks done to it, and you load and activate your module after the first one is done as NOP, and your code only sees the 2nd and 3rd... showing that that gives you sane behavior unpleasant no matter what you do) and on unload, undo all it's work in a semi atomic way (just try doing it race free is already impossible). This is the prime motivation behind the change as I understand it: It wasn't really an option to get this correct, the distros who deploy these frameworks tend to compile them in anyway as a result, and there are real downsides as well (see below). > technical arguments seem to be (1) some people use the LSM interface > for "non-security" purposes, which is frowned upon, (2) it's > difficult to properly secure a system with an open-ended interface > like LSM, and (3) my security framework should be all any fair-minded > person would ever want, so we won't let you use something else. you missed another one: the curent (now merged) patch allows a new option (which is under development and will be proposed for 2.6.25): A config option to compile the kernel such that the security framework of your choice gets compiled as "exclusive" for your binary kernel, and such that the code doesn't go via the LSM function pointers anymore, but just via preprocessor rules, does direct calls instead. (And gets patched out if you issue kernel commandline options to disable security entirely). This takes away one of the main performance overheads of LSM (many many function pointer calls) for those who know which LSM module they'll be using. That option obviously doesn't mean that you can't have multiple LSM drivers anymore in the kernel, again it is an option that IF you know you'll only use one, you can get rid of all the overhead of needing to be ready to do multiple. While this strict technically isn't in conflict with the non-modular LSM (modular-LSM can obviously be a config option in itself as well), it does make it a lot easier and cleaner to 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 0/3] Fix two PEIe hotplug issues
Kristen, If you're happy with this set, please add your Acked-by (or whatever). Thanks, Mark - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/3] pciehp_handle_preinserted_card
01_pciehp_handle_preinserted_card.patch:
Fix pciehp_probe() to deal with ExpressCard cards
that were inserted prior to the driver being loaded.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
---
--- git12/drivers/pci/hotplug/pciehp_ctrl.c 2007-10-17 22:30:19.0
-0400
+++ linux/drivers/pci/hotplug/pciehp_ctrl.c 2007-10-17 22:29:59.0
-0400
@@ -37,7 +37,6 @@
#include "pciehp.h"
static void interrupt_event_handler(struct work_struct *work);
-static int pciehp_enable_slot(struct slot *p_slot);
static int pciehp_disable_slot(struct slot *p_slot);
static int queue_interrupt_event(struct slot *p_slot, u32 event_type)
--- git12/drivers/pci/hotplug/pciehp.h 2007-10-17 22:30:19.0 -0400
+++ linux/drivers/pci/hotplug/pciehp.h 2007-10-17 22:29:59.0 -0400
@@ -161,6 +161,7 @@
extern int pciehp_unconfigure_device(struct slot *p_slot);
extern void pciehp_queue_pushbutton_work(struct work_struct *work);
int pcie_init(struct controller *ctrl, struct pcie_device *dev);
+int pciehp_enable_slot(struct slot *p_slot);
static inline struct slot *pciehp_find_slot(struct controller *ctrl, u8 device)
{
--- git12/drivers/pci/hotplug/pciehp_core.c 2007-10-17 22:30:19.0
-0400
+++ linux/drivers/pci/hotplug/pciehp_core.c 2007-10-17 22:36:06.0
-0400
@@ -471,6 +471,11 @@
t_slot = pciehp_find_slot(ctrl, ctrl->slot_device_offset);
t_slot->hpc_ops->get_adapter_status(t_slot, ); /* Check if slot
is occupied */
+ if (value) {
+ rc = pciehp_enable_slot(t_slot);
+ if (rc) /* -ENODEV: shouldn't happen, but deal with it */
+ value = 0;
+ }
if ((POWER_CTRL(ctrl->ctrlcap)) && !value) {
rc = t_slot->hpc_ops->power_off_slot(t_slot); /* Power off slot
if not occupied*/
if (rc)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/3] pciehp_split_pcie_init
02_pciehp_split_pcie_init.patch:
Split out the hotplug hardware initialization code from pcie_init()
into pcie_init_enable_events(), without changing any functionality.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
---
--- git12/drivers/pci/hotplug/pciehp_hpc.c 2007-10-17 19:06:38.0
-0400
+++ linux/drivers/pci/hotplug/pciehp_hpc.c 2007-10-17 19:29:42.0
-0400
@@ -1067,99 +1067,22 @@
}
#endif
-int pcie_init(struct controller * ctrl, struct pcie_device *dev)
+int pcie_init_hardware(struct controller *ctrl, struct pcie_device *dev)
{
int rc;
u16 temp_word;
- u16 cap_reg;
u16 intr_enable = 0;
u32 slot_cap;
- int cap_base;
- u16 slot_status, slot_ctrl;
+ u16 slot_status;
struct pci_dev *pdev;
pdev = dev->port;
- ctrl->pci_dev = pdev;/* save pci_dev in context */
-
- dbg("%s: hotplug controller vendor id 0x%x device id 0x%x\n",
- __FUNCTION__, pdev->vendor, pdev->device);
-
- if ((cap_base = pci_find_capability(pdev, PCI_CAP_ID_EXP)) == 0) {
- dbg("%s: Can't find PCI_CAP_ID_EXP (0x10)\n", __FUNCTION__);
- goto abort_free_ctlr;
- }
-
- ctrl->cap_base = cap_base;
-
- dbg("%s: pcie_cap_base %x\n", __FUNCTION__, cap_base);
-
- rc = pciehp_readw(ctrl, CAPREG, _reg);
- if (rc) {
- err("%s: Cannot read CAPREG register\n", __FUNCTION__);
- goto abort_free_ctlr;
- }
- dbg("%s: CAPREG offset %x cap_reg %x\n",
- __FUNCTION__, ctrl->cap_base + CAPREG, cap_reg);
-
- if (((cap_reg & SLOT_IMPL) == 0) ||
- (((cap_reg & DEV_PORT_TYPE) != 0x0040)
- && ((cap_reg & DEV_PORT_TYPE) != 0x0060))) {
- dbg("%s : This is not a root port or the port is not "
- "connected to a slot\n", __FUNCTION__);
- goto abort_free_ctlr;
- }
rc = pciehp_readl(ctrl, SLOTCAP, _cap);
if (rc) {
err("%s: Cannot read SLOTCAP register\n", __FUNCTION__);
goto abort_free_ctlr;
}
- dbg("%s: SLOTCAP offset %x slot_cap %x\n",
- __FUNCTION__, ctrl->cap_base + SLOTCAP, slot_cap);
-
- if (!(slot_cap & HP_CAP)) {
- dbg("%s : This slot is not hot-plug capable\n", __FUNCTION__);
- goto abort_free_ctlr;
- }
- /* For debugging purpose */
- rc = pciehp_readw(ctrl, SLOTSTATUS, _status);
- if (rc) {
- err("%s: Cannot read SLOTSTATUS register\n", __FUNCTION__);
- goto abort_free_ctlr;
- }
- dbg("%s: SLOTSTATUS offset %x slot_status %x\n",
- __FUNCTION__, ctrl->cap_base + SLOTSTATUS, slot_status);
-
- rc = pciehp_readw(ctrl, SLOTCTRL, _ctrl);
- if (rc) {
- err("%s: Cannot read SLOTCTRL register\n", __FUNCTION__);
- goto abort_free_ctlr;
- }
- dbg("%s: SLOTCTRL offset %x slot_ctrl %x\n",
- __FUNCTION__, ctrl->cap_base + SLOTCTRL, slot_ctrl);
-
- for (rc = 0; rc < DEVICE_COUNT_RESOURCE; rc++)
- if (pci_resource_len(pdev, rc) > 0)
- dbg("pci resource[%d] start=0x%llx(len=0x%llx)\n", rc,
- (unsigned long long)pci_resource_start(pdev, rc),
- (unsigned long long)pci_resource_len(pdev, rc));
-
- info("HPC vendor_id %x device_id %x ss_vid %x ss_did %x\n",
-pdev->vendor, pdev->device,
-pdev->subsystem_vendor, pdev->subsystem_device);
-
- mutex_init(>crit_sect);
- mutex_init(>ctrl_lock);
- spin_lock_init(>lock);
-
- /* setup wait queue */
- init_waitqueue_head(>queue);
-
- /* return PCI Controller Info */
- ctrl->slot_device_offset = 0;
- ctrl->num_slots = 1;
- ctrl->first_slot = slot_cap >> 19;
- ctrl->ctrlcap = slot_cap & 0x007f;
/* Mask Hot-plug Interrupt Enable */
rc = pciehp_readw(ctrl, SLOTCTRL, _word);
@@ -1280,8 +1203,6 @@
goto abort_disable_intr;
}
- ctrl->hpc_ops = _hpc_ops;
-
return 0;
/* We end up here for the many possible ways to fail this API. */
@@ -1303,3 +1224,105 @@
abort_free_ctlr:
return -1;
}
+
+int pcie_init(struct controller *ctrl, struct pcie_device *dev)
+{
+ int rc;
+ u16 cap_reg;
+ u32 slot_cap;
+ int cap_base;
+ u16 slot_status, slot_ctrl;
+ struct pci_dev *pdev;
+
+ pdev = dev->port;
+ ctrl->pci_dev = pdev;/* save pci_dev in context */
+
+ dbg("%s: hotplug controller vendor id 0x%x device id 0x%x\n",
+ __FUNCTION__, pdev->vendor, pdev->device);
+
+ cap_base = pci_find_capability(pdev, PCI_CAP_ID_EXP);
+ if (cap_base == 0) {
+ dbg("%s: Can't find PCI_CAP_ID_EXP (0x10)\n", __FUNCTION__);
+ goto abort;
[PATCH 3/3] pciehp_resume_reinit_hardware
03_pciehp_resume_reinit_hardware.patch:
Make use of the previously split out pcie_init_enable_events() function
to reinitialize the hotplug hardware on resume from suspend,
but only when pciehp_force==1. Otherwise behaviour is unmodified.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
---
--- git12/drivers/pci/hotplug/pciehp_ctrl.c 2007-10-17 19:28:23.0
-0400
+++ linux/drivers/pci/hotplug/pciehp_ctrl.c 2007-10-17 19:31:22.0
-0400
@@ -37,7 +37,6 @@
#include "pciehp.h"
static void interrupt_event_handler(struct work_struct *work);
-static int pciehp_disable_slot(struct slot *p_slot);
static int queue_interrupt_event(struct slot *p_slot, u32 event_type)
{
--- git12/drivers/pci/hotplug/pciehp.h 2007-10-17 19:28:23.0 -0400
+++ linux/drivers/pci/hotplug/pciehp.h 2007-10-17 19:32:03.0 -0400
@@ -162,6 +162,8 @@
extern void pciehp_queue_pushbutton_work(struct work_struct *work);
int pcie_init(struct controller *ctrl, struct pcie_device *dev);
int pciehp_enable_slot(struct slot *p_slot);
+int pciehp_disable_slot(struct slot *p_slot);
+int pcie_init_hardware(struct controller *ctrl, struct pcie_device *dev);
static inline struct slot *pciehp_find_slot(struct controller *ctrl, u8 device)
{
--- git12/drivers/pci/hotplug/pciehp_core.c 2007-10-17 19:28:23.0
-0400
+++ linux/drivers/pci/hotplug/pciehp_core.c 2007-10-17 19:33:05.0
-0400
@@ -510,6 +510,24 @@
static int pciehp_resume (struct pcie_device *dev)
{
printk("%s ENTRY\n", __FUNCTION__);
+ if (pciehp_force) {
+ struct pci_dev *pdev = dev->port;
+ struct controller *ctrl = pci_get_drvdata(pdev);
+ struct slot *t_slot;
+ u8 status;
+
+ /* reinitialize the chipset's event detection logic */
+ pcie_init_hardware(ctrl, dev);
+
+ t_slot = pciehp_find_slot(ctrl, ctrl->slot_device_offset);
+
+ /* Check if slot is occupied */
+ t_slot->hpc_ops->get_adapter_status(t_slot, );
+ if (status)
+ pciehp_enable_slot(t_slot);
+ else
+ pciehp_disable_slot(t_slot);
+ }
return 0;
}
#endif
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] pciehp_split_pcie_init
02_pciehp_split_pcie_init.patch:
Split out the hotplug hardware initialization code from pcie_init()
into pcie_init_enable_events(), without changing any functionality.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
---
--- git12/drivers/pci/hotplug/pciehp_hpc.c 2007-10-17 19:06:38.0
-0400
+++ linux/drivers/pci/hotplug/pciehp_hpc.c 2007-10-17 19:29:42.0
-0400
@@ -1067,99 +1067,22 @@
}
#endif
-int pcie_init(struct controller * ctrl, struct pcie_device *dev)
+int pcie_init_hardware(struct controller *ctrl, struct pcie_device *dev)
{
int rc;
u16 temp_word;
- u16 cap_reg;
u16 intr_enable = 0;
u32 slot_cap;
- int cap_base;
- u16 slot_status, slot_ctrl;
+ u16 slot_status;
struct pci_dev *pdev;
pdev = dev->port;
- ctrl->pci_dev = pdev;/* save pci_dev in context */
-
- dbg("%s: hotplug controller vendor id 0x%x device id 0x%x\n",
- __FUNCTION__, pdev->vendor, pdev->device);
-
- if ((cap_base = pci_find_capability(pdev, PCI_CAP_ID_EXP)) == 0) {
- dbg("%s: Can't find PCI_CAP_ID_EXP (0x10)\n", __FUNCTION__);
- goto abort_free_ctlr;
- }
-
- ctrl->cap_base = cap_base;
-
- dbg("%s: pcie_cap_base %x\n", __FUNCTION__, cap_base);
-
- rc = pciehp_readw(ctrl, CAPREG, _reg);
- if (rc) {
- err("%s: Cannot read CAPREG register\n", __FUNCTION__);
- goto abort_free_ctlr;
- }
- dbg("%s: CAPREG offset %x cap_reg %x\n",
- __FUNCTION__, ctrl->cap_base + CAPREG, cap_reg);
-
- if (((cap_reg & SLOT_IMPL) == 0) ||
- (((cap_reg & DEV_PORT_TYPE) != 0x0040)
- && ((cap_reg & DEV_PORT_TYPE) != 0x0060))) {
- dbg("%s : This is not a root port or the port is not "
- "connected to a slot\n", __FUNCTION__);
- goto abort_free_ctlr;
- }
rc = pciehp_readl(ctrl, SLOTCAP, _cap);
if (rc) {
err("%s: Cannot read SLOTCAP register\n", __FUNCTION__);
goto abort_free_ctlr;
}
- dbg("%s: SLOTCAP offset %x slot_cap %x\n",
- __FUNCTION__, ctrl->cap_base + SLOTCAP, slot_cap);
-
- if (!(slot_cap & HP_CAP)) {
- dbg("%s : This slot is not hot-plug capable\n", __FUNCTION__);
- goto abort_free_ctlr;
- }
- /* For debugging purpose */
- rc = pciehp_readw(ctrl, SLOTSTATUS, _status);
- if (rc) {
- err("%s: Cannot read SLOTSTATUS register\n", __FUNCTION__);
- goto abort_free_ctlr;
- }
- dbg("%s: SLOTSTATUS offset %x slot_status %x\n",
- __FUNCTION__, ctrl->cap_base + SLOTSTATUS, slot_status);
-
- rc = pciehp_readw(ctrl, SLOTCTRL, _ctrl);
- if (rc) {
- err("%s: Cannot read SLOTCTRL register\n", __FUNCTION__);
- goto abort_free_ctlr;
- }
- dbg("%s: SLOTCTRL offset %x slot_ctrl %x\n",
- __FUNCTION__, ctrl->cap_base + SLOTCTRL, slot_ctrl);
-
- for (rc = 0; rc < DEVICE_COUNT_RESOURCE; rc++)
- if (pci_resource_len(pdev, rc) > 0)
- dbg("pci resource[%d] start=0x%llx(len=0x%llx)\n", rc,
- (unsigned long long)pci_resource_start(pdev, rc),
- (unsigned long long)pci_resource_len(pdev, rc));
-
- info("HPC vendor_id %x device_id %x ss_vid %x ss_did %x\n",
-pdev->vendor, pdev->device,
-pdev->subsystem_vendor, pdev->subsystem_device);
-
- mutex_init(>crit_sect);
- mutex_init(>ctrl_lock);
- spin_lock_init(>lock);
-
- /* setup wait queue */
- init_waitqueue_head(>queue);
-
- /* return PCI Controller Info */
- ctrl->slot_device_offset = 0;
- ctrl->num_slots = 1;
- ctrl->first_slot = slot_cap >> 19;
- ctrl->ctrlcap = slot_cap & 0x007f;
/* Mask Hot-plug Interrupt Enable */
rc = pciehp_readw(ctrl, SLOTCTRL, _word);
@@ -1280,8 +1203,6 @@
goto abort_disable_intr;
}
- ctrl->hpc_ops = _hpc_ops;
-
return 0;
/* We end up here for the many possible ways to fail this API. */
@@ -1303,3 +1224,105 @@
abort_free_ctlr:
return -1;
}
+
+int pcie_init(struct controller *ctrl, struct pcie_device *dev)
+{
+ int rc;
+ u16 cap_reg;
+ u32 slot_cap;
+ int cap_base;
+ u16 slot_status, slot_ctrl;
+ struct pci_dev *pdev;
+
+ pdev = dev->port;
+ ctrl->pci_dev = pdev;/* save pci_dev in context */
+
+ dbg("%s: hotplug controller vendor id 0x%x device id 0x%x\n",
+ __FUNCTION__, pdev->vendor, pdev->device);
+
+ cap_base = pci_find_capability(pdev, PCI_CAP_ID_EXP);
+ if (cap_base == 0) {
+ dbg("%s: Can't find PCI_CAP_ID_EXP (0x10)\n", __FUNCTION__);
+ goto abort;
Re: [RFC] [PATCH 2/2] capabilities: implement 64-bit capabilities
Quoting Andrew Morton ([EMAIL PROTECTED]): > On Tue, 16 Oct 2007 16:41:59 -0500 > "Serge E. Hallyn" <[EMAIL PROTECTED]> wrote: > > > To properly test this the libcap code will need to be updated first, > > which I'm looking at now... > > This seems fairly significant. I asusme that this patch won't break > presently-deployed libcap? It will break libcap. And I'm not sure of the right way to address it. So I was hoping to hear some ideas from Andrew Morgan, Chris Wright, and Kaigai. We can introduce new capget64() and capset64() calls, and have capget() return -EINVAL or -EAGAIN if a high bit would be needed to accurately get the task's capabilities. Or we can require a new libcap, since capget and capset aren't required for most day-to-day function anyway. I guess now that I've written this out, it seems pretty clear that capget64() and capget64() are the way to go. Any objections? thanks, -serge - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] pciehp_handle_preinserted_card
01_pciehp_handle_preinserted_card.patch:
Fix pciehp_probe() to deal with ExpressCard cards
that were inserted prior to the driver being loaded.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
---
--- git12/drivers/pci/hotplug/pciehp_ctrl.c 2007-10-17 22:30:19.0
-0400
+++ linux/drivers/pci/hotplug/pciehp_ctrl.c 2007-10-17 22:29:59.0
-0400
@@ -37,7 +37,6 @@
#include "pciehp.h"
static void interrupt_event_handler(struct work_struct *work);
-static int pciehp_enable_slot(struct slot *p_slot);
static int pciehp_disable_slot(struct slot *p_slot);
static int queue_interrupt_event(struct slot *p_slot, u32 event_type)
--- git12/drivers/pci/hotplug/pciehp.h 2007-10-17 22:30:19.0 -0400
+++ linux/drivers/pci/hotplug/pciehp.h 2007-10-17 22:29:59.0 -0400
@@ -161,6 +161,7 @@
extern int pciehp_unconfigure_device(struct slot *p_slot);
extern void pciehp_queue_pushbutton_work(struct work_struct *work);
int pcie_init(struct controller *ctrl, struct pcie_device *dev);
+int pciehp_enable_slot(struct slot *p_slot);
static inline struct slot *pciehp_find_slot(struct controller *ctrl, u8 device)
{
--- git12/drivers/pci/hotplug/pciehp_core.c 2007-10-17 22:30:19.0
-0400
+++ linux/drivers/pci/hotplug/pciehp_core.c 2007-10-17 22:36:06.0
-0400
@@ -471,6 +471,11 @@
t_slot = pciehp_find_slot(ctrl, ctrl->slot_device_offset);
t_slot->hpc_ops->get_adapter_status(t_slot, ); /* Check if slot
is occupied */
+ if (value) {
+ rc = pciehp_enable_slot(t_slot);
+ if (rc) /* -ENODEV: shouldn't happen, but deal with it */
+ value = 0;
+ }
if ((POWER_CTRL(ctrl->ctrlcap)) && !value) {
rc = t_slot->hpc_ops->power_off_slot(t_slot); /* Power off slot
if not occupied*/
if (rc)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] synchronize_irq needs a barrier
> > In general, I tend to think that for this function to make any sense > (that is, to synchronize anything at all), it needs a barrier or you are > just making a decision based on a totally random value of desc->status > since it can have been re-ordered, speculatively loaded, pre-fetched, > whatever'ed... :-). Take a real life example: drivers/message/fusion/mptbase.c /* Disable interrupts! */ CHIPREG_WRITE32(>chip->IntMask, 0x); ioc->active = 0; synchronize_irq(pdev->irq); And we aren't in a spinlock here. That's just a random example grepped I think I see a few more. Then, some drivers like tg3 actually do an smp_mb() before calling synchronize_irq(). But then, some don't. I think trying to have all drivers be correct here is asking for trouble, we'd rather have synchronize_irq() be uber-safe. It's not like it was used in hot path anyway. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] Fix two PEIe hotplug issues
Fix PCIe Hotplug so that it works with ExpressCard slots on Dell notebooks (and others?) in conjunction with the modparam of pciehp_force=1. The PCIe Hotplug driver has two issues when used on Dell notebooks which lack ACPI BIOS support for PCIe hotplug: 1. The driver does not recognise cards that were inserted prior to the driver being modprobe'd. 2. The driver stops functioning after a suspend/resume (RAM) cycle, and needs to be rmmod'd and modprobe'd to get it working again. This patch series addresses those issues, resulting in a completely functional PCIe Hotplug driver for Dell notebooks, and possibly others as well which may lack ACPI BIOS support for this. Note that pciehp_force=1 is (still) required. There are three patches in this series: 01_pciehp_handle_preinserted_card.patch -- fixes problem number 1 (above). 02_pciehp_split_pcie_init.patch -- preparation for the resume patch. 03_pciehp_resume_reinit_hardware.patch -- fixes problem number 2 (above). diffstat summary for the three patches combined: drivers/pci/hotplug/pciehp.h |3 drivers/pci/hotplug/pciehp_core.c | 23 +++ drivers/pci/hotplug/pciehp_ctrl.c |2 drivers/pci/hotplug/pciehp_hpc.c | 185 +++- 4 files changed, 130 insertions(+), 83 deletions(-) Cheers -- Mark Lord <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Simplify /proc/cgroups
This patch simplifies /proc/cgroups by removing pointers and some
debugging information, and simply presenting a list of subsystems,
which hierarchy they are part of (if any) and the number of cgroups
created for that subsystem. Hierarchy id is determined by the bitmask
of subsystem ids attached to that hierarchy.
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
---
Several people have commented that /proc/cgroups is too confusing or
contains strange information. Here's an attempt to simplify it. New
typical output looks like:
#subsys_namehierarchy num_cgroups
cpuset 1 2
cpuacct 10 1
debug 0 1
ns 10 1
memory 0 1
cpu 0 1
Maybe there should be more tabs so that the columns line up better?
But then it'll be out of line if people create subsystems with longer
names ...
kernel/cgroup.c | 25 -
1 file changed, 4 insertions(+), 21 deletions(-)
Index: container-2.6.23-mm1/kernel/cgroup.c
===
--- container-2.6.23-mm1.orig/kernel/cgroup.c
+++ container-2.6.23-mm1/kernel/cgroup.c
@@ -2403,31 +2403,14 @@ static int proc_cgroupstats_show(struct
int i;
struct cgroupfs_root *root;
+ seq_puts(m, "#subsys_name\thierarchy\tnum_cgroups\n");
mutex_lock(_mutex);
- seq_puts(m, "Hierarchies:\n");
- for_each_root(root) {
- struct cgroup_subsys *ss;
- int first = 1;
- seq_printf(m, "%p: bits=%lx cgroups=%d (", root,
- root->subsys_bits, root->number_of_cgroups);
- for_each_subsys(root, ss) {
- seq_printf(m, "%s%s", first ? "" : ", ", ss->name);
- first = false;
- }
- seq_putc(m, ')');
- if (root->sb) {
- seq_printf(m, " s_active=%d",
- atomic_read(>sb->s_active));
- }
- seq_putc(m, '\n');
- }
- seq_puts(m, "Subsystems:\n");
for (i = 0; i < CGROUP_SUBSYS_COUNT; i++) {
struct cgroup_subsys *ss = subsys[i];
- seq_printf(m, "%d: name=%s hierarchy=%p\n",
- i, ss->name, ss->root);
+ seq_printf(m, "%s\t%d\t%d\n",
+ ss->name, ss->root->subsys_bits,
+ ss->root->number_of_cgroups);
}
- seq_printf(m, "Control Group groups: %d\n", css_set_count);
mutex_unlock(_mutex);
return 0;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] 9p patches for 2.6.24 merge window
On Wed, Oct 17, 2007 at 06:19:53PM -0500, Eric Van Hensbergen wrote: > On 10/17/07, Sam Ravnborg <[EMAIL PROTECTED]> wrote: > > On Wed, Oct 17, 2007 at 04:34:02PM -0500, Eric Van Hensbergen wrote: > > > Linus, please pull from the 'for-linus' branch of: > > > git://git.kernel.org/pub/scm/linux/kernel/git/ericvh/v9fs.git/ for-linus > > > > > > This tree contains the following: > > > > > > Latchesar Ionkov(3): > > > attach-per-user support > > > rename uid and gid parameters > > > define session flags > > > > > > Eric Van Hensbergen(4) > > > remove sysctl code > > > fix bad kconfig cross-dependency > > > soften invalidationin loose mode > > > make transports dynamic > > > > Could you please tag your patches with 9p: or [9p] so it > > is obvious that they belong to this subsystem. > > When browsing head-commits and other places this is a great help. > > > > They should be so tagged, I just stripped it in my pull email summary. OK - thanks. Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] synchronize_irq needs a barrier
On Wed, 2007-10-17 at 19:12 -0700, Linus Torvalds wrote: > > So, what exactly does it protect against? At a minimum, this needs a > comment in the changelog, and probably preferably in the source code too. I replied to Andrew, but I agree, it's worth a comment, I'll add one. > The thing is, synchronize_irq() can only protect against interrupts that > are *already*running* on another CPU, and the caller must have made sure > that no new interrupts are coming in (or at least that whatever new > interrupts that come in will not pick up a certain piece of data). > > So I can imagine that the smb_mb() is there so that the caller - who has > cleared some list or done something like that - will have any preceding > writes that it did be serialized with actually checking the old state of > "desc->status". Yes. > Fair enough - I can see that a smp_mb() is useful. But I think it needs > documenting as such, and preferably with an example of how this actually > happened in the first place (do you have one?) One could argue that it's the caller that should do the mb() but that would really be asking for trouble. Since most usage scenario require it, and it's not a hot path, I prefer having it here. Note that some kind of read barrier or compiler barrier should be needed regardless, or we are just not sync'ing with anything at all (we may have loaded the value ages ago and thus operate on a totally stale value). I prefer a full barrier to also ensure all previous stores are pushed out. > The synchronize_irq() users that are really fundamental (ie the irq > datastructures themselves) all should use the irq descriptor spinlock, and > should *not* be needing any of this, since they would have serialized with > whoever actually set the IRQ_INPROGRESS bit in the first place. That isn't always the case. You can have very efficient lock-less fast path and use synchronize_irq as a kind of RCU-like way to have the slow path do the right thing. > So in *that* sense, I think the memory barrier is useless, and I can't > make up my mind whether it's good or bad. Which is why I'd really like to > have an example scenario spelled out where it makes a difference.. Well, typically, I can clear a pointer and want to make sure my IRQ handler isn't using it anymore before freeing the memory. Or set a "HW is off" flag. Having spinlocks all over isn't always the best approach on things that are really hot path, it's fair enough to use lockless approaches like that by moving the burden to the slow path that does synchronize_irq. In general, I tend to think that for this function to make any sense (that is, to synchronize anything at all), it needs a barrier or you are just making a decision based on a totally random value of desc->status since it can have been re-ordered, speculatively loaded, pre-fetched, whatever'ed... :-). Want a respin with a comment ? Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Videopix Frame Grabber: Convert device_lock_sem to mutex
From: Matthias Kaehlcke <[EMAIL PROTECTED]> Date: Tue, 16 Oct 2007 19:18:52 +0200 > Videopix Frame Grabber: Convert the semaphore device_lock_sem to the > mutex API > > Signed-off-by: Matthias Kaehlcke <[EMAIL PROTECTED]> Applied, thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hda-intel: no soundcard with current linus' git tree
Thomas Meyer wrote: $ dmesg [schnipp] ACPI: PCI Interrupt :00:1b.0[A] -> GSI 22 (level, low) -> IRQ 21 PCI: Enabling bus mastering for device :00:1b.0 PCI: Setting latency timer of device :00:1b.0 to 64 hda_codec: STAC922x, Apple subsys_id=106b0200 ACPI: PCI interrupt for device :00:1b.0 disabled HDA Intel: probe of :00:1b.0 failed with error -16 [schnipp] My sound ability similarly disappeared an upstream kernel <24 hours old (includes the ALSA merge). [EMAIL PROTECTED] ~]$ lsmod | grep -i snd snd_hda_intel 367396 2 snd_pcm_oss42080 0 snd_mixer_oss 16640 2 snd_pcm_oss snd_pcm79624 2 snd_hda_intel,snd_pcm_oss snd_page_alloc 9040 2 snd_hda_intel,snd_pcm [EMAIL PROTECTED] ~]$ lspci | grep -i audio 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01) [EMAIL PROTECTED] ~]$ dmesg | egrep -i 'snd|hda' [EMAIL PROTECTED] ~]$ mplayer says AO: [alsa] 48000Hz 2ch s16le (2 bytes per sample) but no sound is emitted. Earlier kernels been working fine since hda_intel was introduced. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pfkey: sending an SADB_GET responds with an SADB_GET
From: Charles Hardin <[EMAIL PROTECTED]> Date: Wed, 17 Oct 2007 14:36:10 -0700 > Kernel needs to respond to an SADB_GET with the same message type to conform > to the RFC 2367 Section 3.1.5 I can't apply this: 1) We need you to provide an appropriate Signed-off-by: line in the changelog of your patch. 2) Your email client corrupted the patch, changing tabs into spaces, and adding newline breaks to long lines. Please resubmit with these two errors corrected, thank you. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] Fix PCIe hotplug for non-ACPI ExpressCard slots (version 2)
Kristen Carlson Accardi wrote: On Tue, 16 Oct 2007 21:55:30 -0400 Mark Lord <[EMAIL PROTECTED]> wrote: Make use of the previously split out pcie_init_enable_events() function to reinitialize the hotplug hardware on resume from suspend, but only when pciehp_force==1. Otherwise behaviour is unmodified. OK - definitely in this case the right thing to do is not use this code unless you are forcing pciehp, thanks. Yeah, that was Ted's suggestion, and it makes sense. I think I'd be careful when you rename this patch - non-ACPI ExpressCard slots is not what you want to say, as this fix is very specific for your machine. No, from reading through the driver it seems that any machine that lacks ACPI BIOS support for PCIe slots will suffer from the exact same problems. That's a large class of machines, not just my tiny little individual one here (of which *millions* have been manufactured and sold). But, whatever. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [Pcihpd-discuss] [PATCH 2/4] Fix PCIe hotplug for non-ACPI ExpressCard slots (version 2)
Kristen Carlson Accardi wrote: On Tue, 16 Oct 2007 21:54:42 -0400 Mark Lord <[EMAIL PROTECTED]> wrote: Fix pciehp_probe() to deal with pre-inserted ExpressCard cards, but only when pciehp_force==1. Otherwise behaviour is unmodified. I think it would be ok to try allowing the slot to be enabled when not using pciehp_force mode. We can wrap it later if it proves to break things, however, see my comment below: Could you test that on ACPI-supported hardware and report back, please. ... Here it seems like what you want to do just go ahead and try to call pciehp_enable_slot always, but check the return value. If an adapter is not present, it will return -ENODEV, and then you can check to see if you have the ability to power off the slot, and try to power it off. Okay, will do. Please fix CodingStyle issues 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: LSM conversion to static interface
On Wed, 17 Oct 2007, Casey Schaufler wrote: > > The in-tree vs out-of-tree discussion is independent of LSM. Indeed. I think there is certainly likely to be some small overlap, but I *think* they are largely independent issues - "do we want choice in securitu models" (a very emphatic YES as far as I'm concerned) vs "do we necessarily want to do them as out-of-tree modules" (I'd like people who actually *do* things like that to educate us on why and what they are doing). Hmm? Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LSM conversion to static interface
On Wed, 17 Oct 2007, Thomas Fricaccia wrote: > > But then I noticed that, while the LSM would remain in existence, it was > being closed to out-of-tree security frameworks. Yikes! Since then, > I've been following the rush to put SMACK, TOMOYO and AppArmor > "in-tree". Yeah, it did come up. Andrew, when he sent it on to me, said that the SuSE people were ok with it (AppArmor), but I'm with you - I applied it, but I'm also perfectly willing to unapply it if there actually are valid out-of-tree users that people push for not merging. So Í don't think this is settled in any way - please keep discussing, and bringing it up. I'm definitely not in the camp that thinks that LSM needs to be "controlled", but on the other hand, I'm also not going to undo that commit unless there are good real arguments for undoing it (not just theoretical ones). For example, I do kind of see the point that a "real" security model might want to be compiled-in, and not something you override from a module. Of course, I'm personally trying to not use any modules at all, so I'm just odd and contrary, so whatever.. Real usage scenarios with LSM modules, please speak up! Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] synchronize_irq needs a barrier
On Thu, 18 Oct 2007, Benjamin Herrenschmidt wrote: > > + smp_mb(); > while (desc->status & IRQ_INPROGRESS) > cpu_relax(); So, what exactly does it protect against? At a minimum, this needs a comment in the changelog, and probably preferably in the source code too. The thing is, synchronize_irq() can only protect against interrupts that are *already*running* on another CPU, and the caller must have made sure that no new interrupts are coming in (or at least that whatever new interrupts that come in will not pick up a certain piece of data). So I can imagine that the smb_mb() is there so that the caller - who has cleared some list or done something like that - will have any preceding writes that it did be serialized with actually checking the old state of "desc->status". Fair enough - I can see that a smp_mb() is useful. But I think it needs documenting as such, and preferably with an example of how this actually happened in the first place (do you have one?) The synchronize_irq() users that are really fundamental (ie the irq datastructures themselves) all should use the irq descriptor spinlock, and should *not* be needing any of this, since they would have serialized with whoever actually set the IRQ_INPROGRESS bit in the first place. So in *that* sense, I think the memory barrier is useless, and I can't make up my mind whether it's good or bad. Which is why I'd really like to have an example scenario spelled out where it makes a difference.. Ok? Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LSM conversion to static interface
--- Thomas Fricaccia <[EMAIL PROTECTED]> wrote: > ... > > But then I noticed that, while the LSM would remain in existence, it was > being closed to out-of-tree security frameworks. Yikes! Since then, I've > been following the rush to put SMACK, TOMOYO and AppArmor "in-tree". > > Since I know that the people behind these security frameworks are serious and > worthy folk of general good repute, I make no claims to worthyness, strongly deny being serious, and challenge you to demonstrate my good repute. > I've reluctantly come to the tentative > conclusion that the fix is in. Nope. I remain carefully neutral regarding the static/dynamic LSM issue. I was involved with the LSM when SELinux was still known as the Flask port and my development group proposed the first implementation, featuring authoritative hooks. Believe me, this is nothing compared to what we went through as a community then. > There seem to be powers at work that want LSM > closed, and they don't want much public discussion about it. The thing that killed authoritative hooks and that could kill LSM is the notion (which I refuse to take a side on) that out of tree facilities can use it to avoid the stated intent of the GPL. > I think this is bad technology. I've done due diligence by reviewing the > LKML discussion behind closing LSM (and there isn't much). I think the primary parties have gotten to the point where they just call out the arguments by number we've been over them so many times. > The technical > arguments seem to be (1) some people use the LSM interface for "non-security" > purposes, which is frowned upon, It goes way beyond frowned upon. The first use proposed for LSM was an audit implementation and that was throughly shredded. Additional restrictions on accesses only. > (2) it's difficult to properly secure a > system with an open-ended interface like LSM, and Which is pure feldercarb. > (3) my security framework > should be all any fair-minded person would ever want, so we won't let you use > something else. That argument makes Linus mad. > Exactly. > > Well, any system that permits loading code into "ring 0" can't be made > completely secure, so argument 2 reduces to argument 3, which is > transparently self-serving (and invalid). > > I submit for discussion the idea that a free and open operating system should > preserve as much freedom for the end user as possible. To this end, the > kernel should cleanly permit and support the deployment of ANY security > framework the end user desires, whether "in-tree" or "out-of-tree". I agree > that any out-of-tree LSM module should be licensed under the GPL (if for no > other reason than many current commercial support contracts require > non-tainted kernels). > > But restricting security frameworks to "in-tree" only is bad technology. > > "Freedom" includes the power to do bad things to yourself by, for example, > making poor choices in security frameworks. This possible and permitted end > result shouldn't be the concern of kernel developers. Making configuration > and installation of user-chosen frameworks as clean and safe as possible > should be. > > In my opinion. > > Though not sure why, I expect to be scorched by this. Try not to patronize > or condescend. Give me technical arguments backed by real data. Show me why > a home user or 10,000 node commercial enterprise shouldn't be able to choose > what he wants for security without having to jump through your hoops. Show > me why you shouldn't make his use of technology up to him, and as safely and > conveniently as you can contrive. The in-tree vs out-of-tree discussion is independent of LSM. Casey Schaufler [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] synchronize_irq needs a barrier
> > Index: linux-work/kernel/irq/manage.c > > === > > --- linux-work.orig/kernel/irq/manage.c 2007-10-18 11:22:16.0 > > +1000 > > +++ linux-work/kernel/irq/manage.c 2007-10-18 11:22:20.0 +1000 > > @@ -33,6 +33,7 @@ void synchronize_irq(unsigned int irq) > > if (irq >= NR_IRQS) > > return; > > > > + smp_mb(); > > while (desc->status & IRQ_INPROGRESS) > > cpu_relax(); > > } > > Anyone reading this code is going to ask "wtf is that for". It needs a > comment telling them. > > > mb() is the new lock_kernel(). Sigh. Ugh ? That sounds fairly obvious to me :-) we are reading a value, that is totally unordered, nothing to do about lock kernel or whatever, if we want the above statement to make any sense in any kind of usage scenario, it needs to be ordered vs. what happens before. For example, take a construct like: device->my_hw_is_off = 1; synchronize_irq(); turn_off_hardware(); That basically makes sure the irq either sees device->my_hw_is_off being set to 1, or if an irq handler is already in progress and hasn't seen it, we wait for it to complete. (You can replace "hw_is_off" with anything that we want to set and make sure the IRQ handler sees it before proceeding. It could be clearing a pointer to something and make sure the irq sees it before freeing the data, etc...). I think pretty much any use of synchronize_irq() I can imagine needs such kind of ordering... or it simply doesn't synchronize anything :-) Cheers, Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hda-intel: no soundcard with current linus' git tree
>From 0824b077b75c19253b45c5a455775c331acd54ee Mon Sep 17 00:00:00 2001
From: Maxim Levitsky <[EMAIL PROTECTED]>
Date: Thu, 18 Oct 2007 03:35:37 +0200
Subject: [PATCH] [HDA] [STAC] Since there is now a master volume control,
don't call the headphone output "Master", it isn't strictly correct anyway
Signed-off-by: Maxim Levitsky <[EMAIL PROTECTED]>
---
pci/hda/patch_sigmatel.c |7 +--
1 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/pci/hda/patch_sigmatel.c b/pci/hda/patch_sigmatel.c
index 6dffa54..7f157a6 100644
--- a/pci/hda/patch_sigmatel.c
+++ b/pci/hda/patch_sigmatel.c
@@ -1907,12 +1907,7 @@ static int stac92xx_auto_create_hp_ctls(struct hda_codec
*codec,
return err;
}
if (spec->multiout.hp_nid) {
- const char *pfx;
- if (old_num_dacs == spec->multiout.num_dacs)
- pfx = "Master";
- else
- pfx = "Headphone";
- err = create_controls(spec, pfx, spec->multiout.hp_nid, 3);
+ err = create_controls(spec, "Headphone", spec->multiout.hp_nid,
3);
if (err < 0)
return err;
}
--
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: [linux-usb-devel] usb+sysfs: duplicate filename 'bInterfaceNumber'
On 10/17/07, Alan Stern <[EMAIL PROTECTED]> wrote: > On Tue, 16 Oct 2007, Matthew Dharm wrote: > > > On Tue, Oct 16, 2007 at 02:04:43PM -0400, Alan Stern wrote: > > > On Tue, 16 Oct 2007, Matthew Dharm wrote: > > > > > > > I haven't looked at this code at all, but neither approach feels right > > > > to > > > > me. > > > > > > > > How does this work at all? Even if you load a driver later, wouldn't it > > > > call usb_set_interface(), which would call usb_create_sysfs_intf_files() > > > > and hit the same issue? > > > > > > usb_set_interface() is smart enough to remove the old interface files > > > before creating new ones, since it expects them to exist already. > > > Hence there's no problem in that scenario. > > > > > > But usb_set_configuration doesn't expect there to be any pre-existing > > > interface files, because there isn't even an interface until the > > > registration is performed. > > > > And I'm guessing that you can't call usb_create_sysfs_intf_files() until > > registration is performed, right? > > Right. > > > > The most important reason has to do with the endpoint pseudo-devices. > > > Different altsettings can have different endpoints, so those have to be > > > removed and re-created whenever the altsetting changes. > > > > Right, altsettings. I forgot about those. I only ever think in terms of > > multiple configurations. > > > > *grumble* > > > > If usb_set_interface() has to be smart enough to remove existing files > > first already, then I guess it's reasonably symmetric to have > > usb_set_configuration() have the same smarts. Maybe they can share some > > common code, even. > > It's not a big deal to remove the files first. In fact, here's a patch > to do it. Dave, see if this doesn't fix your problem. I don't like it > much because it does an unnecessary remove/create cycle, but that's > better than doing something wrong. Although it's not the best fix, the problem is fixed, Thanks. > > It's slightly odd that the sysfs core logs an error when you try to > create the same file twice but it doesn't when you try to remove a > non-existent file (or try to remove an existing file twice). Oh > well... > > Alan Stern > > > > Index: usb-2.6/drivers/usb/core/message.c > === > --- usb-2.6.orig/drivers/usb/core/message.c > +++ usb-2.6/drivers/usb/core/message.c > @@ -1643,7 +1643,13 @@ free_interfaces: > intf->dev.bus_id, ret); > continue; > } > - usb_create_sysfs_intf_files (intf); > + > + /* The driver's probe method can call usb_set_interface(), > +* which would mean the interface's sysfs files are already > +* created. Just in case, we'll remove them first. > +*/ > + usb_remove_sysfs_intf_files(intf); > + usb_create_sysfs_intf_files(intf); > } > > usb_autosuspend_device(dev); > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: hda-intel: no soundcard with current linus' git tree
Hi, I understand why this happens. Your sound card has a single "headphone" output, and since it is single, it is called "Master" the stac you have also has a real master volume control, that controls all the DACs, not just the headphones. I added support for it, thus two controls collided. The following patch will rename the "Master" output to "Headphone" Note that on the stac 9205/9204, the only one that has no master volume (the volume knob) but has a "Master Volume" amplifier widget, this will probably rename the "Master Volume" to Headphones. This chip is quite different, thus I think this should be handled in its patch function. I see what I can do later. Meanwhile the rename from "Master" to Headphones" is the only regression. Best regards, Maxim Levitsky PS: I reply to this mail with 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: [bug] ata subsystem related crash with latest -git
From: Linus Torvalds <[EMAIL PROTECTED]> Date: Wed, 17 Oct 2007 18:36:34 -0700 (PDT) > Although I also wonder whether we want one global per-arch > ARCH_HAS_SG_CHAIN It's there because the DMA mapping support code for a platform has to be converted to handle these chains and audited to make sure the conversion is right. Some platforms, such as sparc64, took a lot of work to get right :-) Once that macro is set, the block device driver has to support it too, and there are knobs all the way down to the scsi host driver to indicate this. The idea is that all of this mess gets deleted in the end, it was meant to be a safe transition scheme. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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-mm1 - build failure with advansys
On Thu, Oct 18, 2007 at 10:07:54AM +1000, Paul Mackerras wrote: > The correct fix is to make advansys depend on CONFIG_VIRT_TO_BUS, or > alternatively fix advansys.c properly by making it use the interfaces > described in Documentation/DMA-mapping.txt (or the equivalent scsi > helpers). If you look at the git logs, you'll notice there's some progress towards this. It's already the case for the narrow boards. I have a patch to rip it all out for the wide boards, but there's clearly a bug because it crashes my parisc machine. Works fine on x86 though. I can't work on it this week because I'm travelling and the parisc machine with remote power died on me last week. I think I already suggested a temporary CONFIG_VIRT_TO_BUS dependency to akpm last week. -- 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] synchronize_irq needs a barrier
On Thu, 18 Oct 2007 11:25:42 +1000 Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > synchronize_irq needs at the very least a compiler barrier and a > read barrier on SMP, Why? > but there are enough cases around where a > write barrier is also needed and it's not a hot path so I prefer > using a full smp_mb() here. > > It will degrade to a compiler barrier on !SMP. > > Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> > --- > > Index: linux-work/kernel/irq/manage.c > === > --- linux-work.orig/kernel/irq/manage.c 2007-10-18 11:22:16.0 > +1000 > +++ linux-work/kernel/irq/manage.c2007-10-18 11:22:20.0 +1000 > @@ -33,6 +33,7 @@ void synchronize_irq(unsigned int irq) > if (irq >= NR_IRQS) > return; > > + smp_mb(); > while (desc->status & IRQ_INPROGRESS) > cpu_relax(); > } Anyone reading this code is going to ask "wtf is that for". It needs a comment telling them. mb() is the new lock_kernel(). Sigh. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
LSM conversion to static interface
Like many of us who earn a good living with Linux (for over a decade now) and follow the kernel developer discussions with waxing and waning interest depending on topic, I noticed James Morris' proposal to eliminate the LSM in favor of ordaining SELinux as THE security framework forever and amen, followed by the definitive decision by Linus that LSM would remain. Well, good, I thought. Linux should continue to represent freedom for anyone to use basic technology in any way he sees fit. I turned my attention back to my prosaic day-to-day concerns, thinking that the choice of which security framework to deploy would remain in the hands of the user, regardless of which distributor he chose. But then I noticed that, while the LSM would remain in existence, it was being closed to out-of-tree security frameworks. Yikes! Since then, I've been following the rush to put SMACK, TOMOYO and AppArmor "in-tree". Since I know that the people behind these security frameworks are serious and worthy folk of general good repute, I've reluctantly come to the tentative conclusion that the fix is in. There seem to be powers at work that want LSM closed, and they don't want much public discussion about it. I think this is bad technology. I've done due diligence by reviewing the LKML discussion behind closing LSM (and there isn't much). The technical arguments seem to be (1) some people use the LSM interface for "non-security" purposes, which is frowned upon, (2) it's difficult to properly secure a system with an open-ended interface like LSM, and (3) my security framework should be all any fair-minded person would ever want, so we won't let you use something else. Exactly. Well, any system that permits loading code into "ring 0" can't be made completely secure, so argument 2 reduces to argument 3, which is transparently self-serving (and invalid). I submit for discussion the idea that a free and open operating system should preserve as much freedom for the end user as possible. To this end, the kernel should cleanly permit and support the deployment of ANY security framework the end user desires, whether "in-tree" or "out-of-tree". I agree that any out-of-tree LSM module should be licensed under the GPL (if for no other reason than many current commercial support contracts require non-tainted kernels). But restricting security frameworks to "in-tree" only is bad technology. "Freedom" includes the power to do bad things to yourself by, for example, making poor choices in security frameworks. This possible and permitted end result shouldn't be the concern of kernel developers. Making configuration and installation of user-chosen frameworks as clean and safe as possible should be. In my opinion. Though not sure why, I expect to be scorched by this. Try not to patronize or condescend. Give me technical arguments backed by real data. Show me why a home user or 10,000 node commercial enterprise shouldn't be able to choose what he wants for security without having to jump through your hoops. Show me why you shouldn't make his use of technology up to him, and as safely and conveniently as you can contrive. Thanks for a really great operating system, I really love it, Tommy F. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [bug] ata subsystem related crash with latest -git
On Wed, 17 Oct 2007, David Miller wrote: > > I believe that we have enough of a limited set of accessors to > sg->page that we can more aggressively encode things in the lower > bits. > > I'm thinking of encoding the low two bits of sg->page as > follows: > > 1) bits == 0 > >then the SG list is linear and sg_next() is sg++ > > 2) bits == 1 > >the nest SG is an indirect chunk, sg_next() is >therefore something like: > > next = *((struct scatterlist **)(sg + 1)); > > 3) bits == 2 > >this is the last entry in the scatterlist, sg_next() is NULL > > So for the cases of ARCH_HAS_SG_CHAIN not being set (ie. back > compatible), we can do no bit encoding in page->flags and just do > sg_next() == sg++, as is done now. Yes, that sounds sane. Although I also wonder whether we want one global per-arch ARCH_HAS_SG_CHAIN, or perhaps have something more dynamic, which allows a per-SG-list choice (which in turn would require some kind of "head" entry that is passed into sg_next(), and in general descibes the SG list) Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Inquiry data and emulated SG devices
Robert Hancock wrote:
This doesn't seem a very reliable way to identify an IDE device, as all
that 0 means is that the device does not claim conformance to any
standard. I would think it would be legitimate for an IDE device to put
a value like 5 in there as well, if it complies with SPC-4..
Via the this-doesnt-really-matter-but-it-should-be-noted department:
According to the latest on t10.org, MMC retroactively permitted SCSI
version to be zero, for MMC-compliant USB and ATAPI devices.
In the case of libata though, that appears to be due to this code in
drivers/ata/libata-scsi.c:
/* ATAPI devices typically report zero for their SCSI version,
* and sometimes deviate from the spec WRT response data
* format. If SCSI version is reported as zero like normal,
* then we make the following fixups: 1) Fake MMC-5 version,
* to indicate to the Linux scsi midlayer this is a modern
* device. 2) Ensure response data format / ATAPI information
* are always correct.
*/
if (buf[2] == 0) {
buf[2] = 0x5;
buf[3] = 0x32;
}
This technically seems to go against what the SCSI/ATA Translation (SAT)
spec says regarding INQUIRY on ATAPI devices: "the SATL shall use the
ATA PACKET Command feature set to pass all INQUIRY commands and
parameter data to the ATAPI device without altering the INQUIRY
commands or the parameter data." However, it might realistically be
needed if the SCSI layer in the kernel has problems with a device
indicating it supports no SCSI version..
The above tweak is entirely software->software communication... as the
comment you quoted notes, it's just a signal to the SCSI midlayer.
At the moment, the SCSI midlayer assumes any device that reports scsi
version as less than 2 is forced to SCSI version 2. Ultimately that's
incorrect behavior for all ATAPI devices (and later MMC revisions).
At the time, libata simply worked around this SCSI buglet in its own
code, since that was easier than auditing all SCSI code paths to ensure
new ATAPI/USB MMC logic does not break ancient devices.
But if someone is motivated enough to revisit this...
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] synchronize_irq needs a barrier
synchronize_irq needs at the very least a compiler barrier and a read barrier on SMP, but there are enough cases around where a write barrier is also needed and it's not a hot path so I prefer using a full smp_mb() here. It will degrade to a compiler barrier on !SMP. Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> --- Index: linux-work/kernel/irq/manage.c === --- linux-work.orig/kernel/irq/manage.c 2007-10-18 11:22:16.0 +1000 +++ linux-work/kernel/irq/manage.c 2007-10-18 11:22:20.0 +1000 @@ -33,6 +33,7 @@ void synchronize_irq(unsigned int irq) if (irq >= NR_IRQS) return; + smp_mb(); while (desc->status & IRQ_INPROGRESS) cpu_relax(); } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Inquiry data and emulated SG devices
(cc-ing linux-ide)
Mathieu Fluhr wrote:
Hello all,
First of all, let me introduce myself a little bit. I am the responsable
for the development of the Nero Linux burning application. So I have
access to all the source code of the application.
Now let's go with the story: It seems that there is a slight problem in
the libata (and also the new pata_xxx) interfaces with the data returned
by the INQUIRY cmd since every S-ATA or IDE device is assumed to be a
SCSI dev.
Normally, the IDE devices (physical type) can be differentied with the
format field of the inquiry data, i.e. the last bytes (ANSI version) are
set to 0 -> This is done and works great with USB external devices for
example.
The thing is that with S-ATA/IDE devices when using the libata/pata
driver, the version field is (always?) set to 5, as any _real_ SCSI
device, and thus the physical device type cannot be checked anymore.
This doesn't seem a very reliable way to identify an IDE device, as all
that 0 means is that the device does not claim conformance to any
standard. I would think it would be legitimate for an IDE device to put
a value like 5 in there as well, if it complies with SPC-4..
In the case of libata though, that appears to be due to this code in
drivers/ata/libata-scsi.c:
/* ATAPI devices typically report zero for their SCSI version,
* and sometimes deviate from the spec WRT response data
* format. If SCSI version is reported as zero like normal,
* then we make the following fixups: 1) Fake MMC-5 version,
* to indicate to the Linux scsi midlayer this is a modern
* device. 2) Ensure response data format / ATAPI information
* are always correct.
*/
if (buf[2] == 0) {
buf[2] = 0x5;
buf[3] = 0x32;
}
This technically seems to go against what the SCSI/ATA Translation (SAT)
spec says regarding INQUIRY on ATAPI devices: "the SATL shall use the
ATA PACKET Command feature set to pass all INQUIRY commands and
parameter data to the ATAPI device without altering the INQUIRY
commands or the parameter data." However, it might realistically be
needed if the SCSI layer in the kernel has problems with a device
indicating it supports no SCSI version..
I cannot go so deep in details, but our burn engine is differentiating
IDE and read-good-old-SCSI devices and handles them sometimes in a
different way, so this differenciation is really important for us.
-> How can I detect the real physical device type now?
I don't have a great answer off the top of my head..
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [bug] ata subsystem related crash with latest -git
From: Linus Torvalds <[EMAIL PROTECTED]> Date: Wed, 17 Oct 2007 18:07:19 -0700 (PDT) > sg_next() - as it stands now - never actually looks at the SG that its > argument points to: it explicitly *only* looks at the next one. > > That's the bug. If sg_next() looked at the actual *current* sg entry, we > wouldn't have any issues to begin with, and that's what I'm arguing we > should do in the longer run (where "longer run" is defined as "when Jens > does it asap"). What the thing really wants is some kind of indication of state, without having to bloat up the scatterlist structure. I believe that we have enough of a limited set of accessors to sg->page that we can more aggressively encode things in the lower bits. I'm thinking of encoding the low two bits of sg->page as follows: 1) bits == 0 then the SG list is linear and sg_next() is sg++ 2) bits == 1 the nest SG is an indirect chunk, sg_next() is therefore something like: next = *((struct scatterlist **)(sg + 1)); 3) bits == 2 this is the last entry in the scatterlist, sg_next() is NULL So for the cases of ARCH_HAS_SG_CHAIN not being set (ie. back compatible), we can do no bit encoding in page->flags and just do sg_next() == sg++, as is done now. When doing SG chaining, in each non-linear chunk we have to allocate one more pointer past the end of the scatterlist array (instead of a full extra scatterlist entry for the indirect pointer encode). Next, all sg->page accesses have to be guarded to clear the state bits out first. I don't know, maybe it would work, and would make the loop termination issues easier to handle properly. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [bug] ata subsystem related crash with latest -git
On a related hardware note: FWIW, most ATA controllers have scatter/gather tables that terminate themselves by a bit in the final s/g entry. The 90% case needs to know the last scatterlist entry, at the end of the s/g walk. So however this all gets worked out, please make sure not to unduly punish libata controllers with an expensive sg_last() inside a loop, or something like that. :) Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[git patches] libata fixes
Well, the new driver is not a fix.
Anyway -- still plugging away at debugging libata. It seems some
outside changes are causing a bunch of my test boxes to crap themselves.
These need to go up in the meantime, however.
Maybe its the sg-chaining stuff, we'll see. I'm watching that thread
closely (after recovering from an email outage).
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
drivers/ata/Kconfig | 16 +-
drivers/ata/Makefile |1 +
drivers/ata/libata-sff.c |2 +-
drivers/ata/pata_acpi.c |2 +
drivers/ata/pata_bf54x.c | 77 ++--
drivers/ata/sata_fsl.c | 1490 ++
6 files changed, 1540 insertions(+), 48 deletions(-)
create mode 100644 drivers/ata/sata_fsl.c
Alan Cox (1):
libata-sff: Correct use of check_status()
Li Yang (1):
drivers/ata: add support to Freescale 3.0Gbps SATA Controller
Sonic Zhang (1):
Update libata driver for bf548 atapi controller against the 2.6.24 tree.
Tejun Heo (1):
pata_acpi: fix build breakage if !CONFIG_PM
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 33f5eb0..ba63619 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -182,6 +182,15 @@ config PATA_ACPI
firmware in the BIOS. This driver can sometimes handle
otherwise unsupported hardware.
+config SATA_FSL
+ tristate "Freescale 3.0Gbps SATA support"
+ depends on PPC_MPC837x
+ help
+ This option enables support for Freescale 3.0Gbps SATA controller.
+ It can be found on MPC837x and MPC8315.
+
+ If unsure, say N.
+
config PATA_ALI
tristate "ALi PATA support (Experimental)"
depends on PCI && EXPERIMENTAL
@@ -641,11 +650,4 @@ config PATA_BF54X
If unsure, say N.
-config PATA_BF54X_DMA
- bool "DMA mode"
- depends on PATA_BF54X
- default y
- help
- Enable DMA mode for Blackfin ATAPI controller.
-
endif # ATA
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index 6bdc307..b13feb2 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_SATA_ULI)+= sata_uli.o
obj-$(CONFIG_SATA_MV) += sata_mv.o
obj-$(CONFIG_SATA_INIC162X)+= sata_inic162x.o
obj-$(CONFIG_PDC_ADMA) += pdc_adma.o
+obj-$(CONFIG_SATA_FSL) += sata_fsl.o
obj-$(CONFIG_PATA_ALI) += pata_ali.o
obj-$(CONFIG_PATA_AMD) += pata_amd.o
diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c
index 026439e..1232dcb 100644
--- a/drivers/ata/libata-sff.c
+++ b/drivers/ata/libata-sff.c
@@ -156,7 +156,7 @@ void ata_tf_read(struct ata_port *ap, struct ata_taskfile
*tf)
{
struct ata_ioports *ioaddr = >ioaddr;
- tf->command = ata_check_status(ap);
+ tf->command = ata_chk_status(ap);
tf->feature = ioread8(ioaddr->error_addr);
tf->nsect = ioread8(ioaddr->nsect_addr);
tf->lbal = ioread8(ioaddr->lbal_addr);
diff --git a/drivers/ata/pata_acpi.c b/drivers/ata/pata_acpi.c
index 5d3920f..0f6f7bc 100644
--- a/drivers/ata/pata_acpi.c
+++ b/drivers/ata/pata_acpi.c
@@ -370,8 +370,10 @@ static struct pci_driver pacpi_pci_driver = {
.id_table = pacpi_pci_tbl,
.probe = pacpi_init_one,
.remove = ata_pci_remove_one,
+#ifdef CONFIG_PM
.suspend= ata_pci_device_suspend,
.resume = ata_pci_device_resume,
+#endif
};
static int __init pacpi_init(void)
diff --git a/drivers/ata/pata_bf54x.c b/drivers/ata/pata_bf54x.c
index 747549e..b5e3842 100644
--- a/drivers/ata/pata_bf54x.c
+++ b/drivers/ata/pata_bf54x.c
@@ -1092,14 +1092,15 @@ static unsigned int bfin_bus_softreset(struct ata_port
*ap,
* Note: Original code is ata_std_softreset().
*/
-static int bfin_std_softreset(struct ata_port *ap, unsigned int *classes,
+static int bfin_std_softreset(struct ata_link *link, unsigned int *classes,
unsigned long deadline)
{
+ struct ata_port *ap = link->ap;
unsigned int slave_possible = ap->flags & ATA_FLAG_SLAVE_POSS;
unsigned int devmask = 0, err_mask;
u8 err;
- if (ata_port_offline(ap)) {
+ if (ata_link_offline(link)) {
classes[0] = ATA_DEV_NONE;
goto out;
}
@@ -1122,9 +1123,11 @@ static int bfin_std_softreset(struct ata_port *ap,
unsigned int *classes,
}
/* determine by signature whether we have ATA or ATAPI devices */
- classes[0] = ata_dev_try_classify(ap, 0, );
+ classes[0] = ata_dev_try_classify(>link.device[0],
+ devmask & (1 << 0), );
if (slave_possible && err != 0x81)
- classes[1] = ata_dev_try_classify(ap, 1, );
+ classes[1] =
Re: [patch][rfc] rewrite ramdisk
On Thursday 18 October 2007 04:45, Eric W. Biederman wrote: > At this point my concern is what makes a clean code change in the > kernel. Because user space can currently play with buffer_heads > by way of the block device and cause lots of havoc (see the recent Well if userspace is writing to the filesystem metadata via the blockdevice while it is running... that's the definition of havoc, isn't it? ;) Whether or not the writes are going via a unified metadata/blockdev cache or separate ones. You really just have to not do that. The actual reiserfs problem being seen is not because of userspace going silly, but because ramdisk is hijacking the dirty bits. > If that change is made then it happens that the current ramdisk > would not need to worry about buffer heads and all of that > nastiness and could just lock pages in the page cache. It would not > be quite as good for testing filesystems but retaining the existing > characteristics would be simple. No, it wouldn't. Because if you're proposing to split up the buffer cache and the metadata cache, then you're back to a 2 cache solution which is basically has the memory characteristics of my proposal while still being horribly incestuous with the pagecache. > After having looked a bit deeper the buffer_heads and the block > devices don't look as intricately tied up as I had first thought. > We still have the nasty case of: > if (buffer_new(bh)) > unmap_underlying_metadata(bh->b_bdev, bh->b_blocknr); > That I don't know how it got merged. But otherwise the caches > are fully separate. Well its needed because some filesystems forget about their old metadata. It's not really there to solve aliasing with the blockdev pagecache. > So currently it looks to me like there are two big things that will > clean up that part of the code a lot: > - moving the metadata buffer_heads to a magic filesystem inode. > - Using a simpler non-buffer_head returning version of get_block > so we can make simple generic code for generating BIOs. Although this is going off the track of the ramdisk problem. For that we should just do the rewrite. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [bug] ata subsystem related crash with latest -git
On Thu, 18 Oct 2007, FUJITA Tomonori wrote: > > Looks that (sglist) - 1 isn't initialized and we use sg_next for it? sg_next() - as it stands now - never actually looks at the SG that its argument points to: it explicitly *only* looks at the next one. That's the bug. If sg_next() looked at the actual *current* sg entry, we wouldn't have any issues to begin with, and that's what I'm arguing we should do in the longer run (where "longer run" is defined as "when Jens does it asap"). So the hacky solution as it stands right now is to actually use the behaviour of "sg_next()" to our advantage in for_each_sg(), and starting off by setting sg to (sglist)-1. That way we can do the "sg_next()" (which will *not* look at the uninitialized space before the array) before entering the loop, regardless of whether it's the first time through the loop or not. So no, it's not technically "strictly conforming ANSI C", because we use a pointer (not do not dereference it!) outside of its allocation, which is strictly speaking against the standard. However, the kernel does those kinds of things all the time, since the kernel does its own memory allocation, so that's not actually relevant. The *standard* may say that you cannot decrement a pointer to before the beginning of the object and then increment it back up again and be strictly conforming, but the fact is, we very much depend on contiguous and flat kernel pointer model, and always have (and probably always will) Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[git patches] net driver fixes
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-linus
to receive the following updates:
drivers/net/3c59x.c|2 +-
drivers/net/forcedeth.c| 27 ++---
drivers/net/fs_enet/fs_enet-main.c | 28 ++---
drivers/net/fs_enet/fs_enet.h |1 +
drivers/net/gianfar.c |4 ++-
drivers/net/gianfar.h |1 -
drivers/net/ibm_newemac/mal.c |2 +-
drivers/net/pcnet32.c | 58
drivers/net/sky2.c | 46
include/linux/netdevice.h | 18 +++
10 files changed, 108 insertions(+), 79 deletions(-)
Anton Vorontsov (1):
gianfar: fix obviously wrong #ifdef CONFIG_GFAR_NAPI placement
Badari Pulavarty (1):
vortex_up should initialize "err"
Benjamin Herrenschmidt (1):
fix EMAC driver for proper napi_synchronize API
Don Fry (3):
pcnet32: fix non-napi packet reception
pcnet32: remove compile warnings in non-napi mode
pcnet32: remove private net_device_stats structure
Ingo Molnar (1):
forcedeth: fix rx-work condition in nv_rx_process_optimized() too
Manfred Spraul (1):
forcedeth msi bugfix
Scott Wood (1):
fs_enet: Update for API changes
Sebastian Siewior (1):
gianfar: remove orphan struct.
Stephen Hemminger (2):
napi_synchronize: waiting for NAPI
sky2: shutdown cleanup
diff --git a/drivers/net/3c59x.c b/drivers/net/3c59x.c
index 862f472..6f8e7d4 100644
--- a/drivers/net/3c59x.c
+++ b/drivers/net/3c59x.c
@@ -1491,7 +1491,7 @@ vortex_up(struct net_device *dev)
struct vortex_private *vp = netdev_priv(dev);
void __iomem *ioaddr = vp->ioaddr;
unsigned int config;
- int i, mii_reg1, mii_reg5, err;
+ int i, mii_reg1, mii_reg5, err = 0;
if (VORTEX_PCI(vp)) {
pci_set_power_state(VORTEX_PCI(vp), PCI_D0);/* Go active */
diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c
index cfbb7aa..70ddf1a 100644
--- a/drivers/net/forcedeth.c
+++ b/drivers/net/forcedeth.c
@@ -992,7 +992,7 @@ static void nv_enable_irq(struct net_device *dev)
if (np->msi_flags & NV_MSI_X_ENABLED)
enable_irq(np->msi_x_entry[NV_MSI_X_VECTOR_ALL].vector);
else
- enable_irq(dev->irq);
+ enable_irq(np->pci_dev->irq);
} else {
enable_irq(np->msi_x_entry[NV_MSI_X_VECTOR_RX].vector);
enable_irq(np->msi_x_entry[NV_MSI_X_VECTOR_TX].vector);
@@ -1008,7 +1008,7 @@ static void nv_disable_irq(struct net_device *dev)
if (np->msi_flags & NV_MSI_X_ENABLED)
disable_irq(np->msi_x_entry[NV_MSI_X_VECTOR_ALL].vector);
else
- disable_irq(dev->irq);
+ disable_irq(np->pci_dev->irq);
} else {
disable_irq(np->msi_x_entry[NV_MSI_X_VECTOR_RX].vector);
disable_irq(np->msi_x_entry[NV_MSI_X_VECTOR_TX].vector);
@@ -1607,7 +1607,7 @@ static void nv_do_rx_refill(unsigned long data)
if (np->msi_flags & NV_MSI_X_ENABLED)
disable_irq(np->msi_x_entry[NV_MSI_X_VECTOR_ALL].vector);
else
- disable_irq(dev->irq);
+ disable_irq(np->pci_dev->irq);
} else {
disable_irq(np->msi_x_entry[NV_MSI_X_VECTOR_RX].vector);
}
@@ -1625,7 +1625,7 @@ static void nv_do_rx_refill(unsigned long data)
if (np->msi_flags & NV_MSI_X_ENABLED)
enable_irq(np->msi_x_entry[NV_MSI_X_VECTOR_ALL].vector);
else
- enable_irq(dev->irq);
+ enable_irq(np->pci_dev->irq);
} else {
enable_irq(np->msi_x_entry[NV_MSI_X_VECTOR_RX].vector);
}
@@ -2408,13 +2408,13 @@ static int nv_rx_process_optimized(struct net_device
*dev, int limit)
struct fe_priv *np = netdev_priv(dev);
u32 flags;
u32 vlanflags = 0;
- u32 rx_processed_cnt = 0;
+ int rx_work = 0;
struct sk_buff *skb;
int len;
while((np->get_rx.ex != np->put_rx.ex) &&
!((flags = le32_to_cpu(np->get_rx.ex->flaglen)) & NV_RX2_AVAIL) &&
- (rx_processed_cnt++ < limit)) {
+ (rx_work < limit)) {
dprintk(KERN_DEBUG "%s: nv_rx_process_optimized: flags 0x%x.\n",
dev->name, flags);
@@ -2517,9 +2517,11 @@ next_pkt:
np->get_rx.ex = np->first_rx.ex;
if (unlikely(np->get_rx_ctx++ == np->last_rx_ctx))
np->get_rx_ctx = np->first_rx_ctx;
+
+ rx_work++;
}
- return rx_processed_cnt;
+ return
Re: [RFC] [PATCH 2/2] capabilities: implement 64-bit capabilities
On Tue, 16 Oct 2007 16:41:59 -0500 "Serge E. Hallyn" <[EMAIL PROTECTED]> wrote: > To properly test this the libcap code will need to be updated first, > which I'm looking at now... This seems fairly significant. I asusme that this patch won't break presently-deployed libcap? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] I/OAT: Add completion callback for async_tx interface use (take 2)
The async_tx interface includes a completion callback. This adds support
for using that callback, including using interrupts on completion.
This second try does better at defining the callback prototype.
Cc: David Miller <[EMAIL PROTECTED]>
Signed-off-by: Shannon Nelson <[EMAIL PROTECTED]>
---
drivers/dma/ioat_dma.c | 25 +
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/drivers/dma/ioat_dma.c b/drivers/dma/ioat_dma.c
index 117ac38..517bfa1 100644
--- a/drivers/dma/ioat_dma.c
+++ b/drivers/dma/ioat_dma.c
@@ -212,6 +212,18 @@ static dma_cookie_t ioat_tx_submit(struct
dma_async_tx_descriptor *tx)
} while (len && (new = ioat_dma_get_next_descriptor(ioat_chan)));
hw->ctl = IOAT_DMA_DESCRIPTOR_CTL_CP_STS;
+ if (new->async_tx.callback) {
+ hw->ctl |= IOAT_DMA_DESCRIPTOR_CTL_INT_GN;
+ if (first != new) {
+ /* move callback into to last desc */
+ new->async_tx.callback = first->async_tx.callback;
+ new->async_tx.callback_param
+ = first->async_tx.callback_param;
+ first->async_tx.callback = NULL;
+ first->async_tx.callback_param = NULL;
+ }
+ }
+
new->tx_cnt = desc_count;
new->async_tx.ack = orig_ack; /* client is in control of this ack */
@@ -516,6 +528,11 @@ static void ioat_dma_memcpy_cleanup(struct ioat_dma_chan
*ioat_chan)
pci_unmap_addr(desc, src),
pci_unmap_len(desc, len),
PCI_DMA_TODEVICE);
+ if (desc->async_tx.callback) {
+ desc->async_tx.callback(
+ desc->async_tx.callback_param);
+ desc->async_tx.callback = NULL;
+ }
}
if (desc->async_tx.phys != phys_complete) {
@@ -637,6 +654,12 @@ static void ioat_dma_start_null_desc(struct ioat_dma_chan
*ioat_chan)
*/
#define IOAT_TEST_SIZE 2000
+static void ioat_dma_test_callback(void *dma_async_param)
+{
+ printk(KERN_ERR "ioatdma: ioat_dma_test_callback(%p)\n",
+ dma_async_param);
+}
+
/**
* ioat_dma_self_test - Perform a IOAT transaction to verify the HW works.
* @device: device to be tested
@@ -691,6 +714,8 @@ static int ioat_dma_self_test(struct ioatdma_device *device)
addr = dma_map_single(dma_chan->device->dev, dest, IOAT_TEST_SIZE,
DMA_FROM_DEVICE);
ioat_set_dest(addr, tx, 0);
+ tx->callback = ioat_dma_test_callback;
+ tx->callback_param = (void *)0x8086;
cookie = ioat_tx_submit(tx);
if (cookie < 0) {
dev_err(>pdev->dev,
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Update libata driver for bf548 atapi controller against the 2.6.24 tree.
Sonic Zhang wrote: Changes: 1. Remove irq_ack() and port_disable() methods 2. Acocomodate for the libata-link patches 3. Change Kconfig ATAPI mode option into a module param. 4. Add supported WMDMA mode. Signed-off-by: Sonic Zhang <[EMAIL PROTECTED]> applied - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/5] I/OAT: cleanup pci issues
Reorder the pci release actions
Letting go of the resources in the right order helps get rid of
occasional kernel complaints.
Fix the pci_driver object name [Randy Dunlap]
Rename the struct pci_driver data so that false section mismatch
warnings won't be produced.
Cc: Randy Dunlap <[EMAIL PROTECTED]>
Signed-off-by: Shannon Nelson <[EMAIL PROTECTED]>
---
drivers/dma/ioat.c | 23 ++-
drivers/dma/ioat_dma.c |5 -
2 files changed, 10 insertions(+), 18 deletions(-)
diff --git a/drivers/dma/ioat.c b/drivers/dma/ioat.c
index f7276bf..54fdeb7 100644
--- a/drivers/dma/ioat.c
+++ b/drivers/dma/ioat.c
@@ -55,9 +55,7 @@ struct ioat_device {
static int __devinit ioat_probe(struct pci_dev *pdev,
const struct pci_device_id *id);
-#ifdef IOAT_DMA_REMOVE
static void __devexit ioat_remove(struct pci_dev *pdev);
-#endif
static int ioat_dca_enabled = 1;
module_param(ioat_dca_enabled, int, 0644);
@@ -100,14 +98,12 @@ static void ioat_shutdown_functionality(struct pci_dev
*pdev)
}
-static struct pci_driver ioat_pci_drv = {
+static struct pci_driver ioat_pci_driver = {
.name = "ioatdma",
.id_table = ioat_pci_tbl,
.probe = ioat_probe,
.shutdown = ioat_shutdown_functionality,
-#ifdef IOAT_DMA_REMOVE
.remove = __devexit_p(ioat_remove),
-#endif
};
static int __devinit ioat_probe(struct pci_dev *pdev,
@@ -122,7 +118,7 @@ static int __devinit ioat_probe(struct pci_dev *pdev,
if (err)
goto err_enable_device;
- err = pci_request_regions(pdev, ioat_pci_drv.name);
+ err = pci_request_regions(pdev, ioat_pci_driver.name);
if (err)
goto err_request_regions;
@@ -176,13 +172,11 @@ err_enable_device:
return err;
}
-#ifdef IOAT_DMA_REMOVE
/*
* It is unsafe to remove this module: if removed while a requested
* dma is outstanding, esp. from tcp, it is possible to hang while
- * waiting for something that will never finish, thus hanging at
- * least one cpu. However, if you're feeling lucky and need to do
- * some testing, this usually works just fine.
+ * waiting for something that will never finish. However, if you're
+ * feeling lucky, this usually works just fine.
*/
static void __devexit ioat_remove(struct pci_dev *pdev)
{
@@ -191,21 +185,16 @@ static void __devexit ioat_remove(struct pci_dev *pdev)
ioat_shutdown_functionality(pdev);
kfree(device);
-
- iounmap(device->iobase);
- pci_release_regions(pdev);
- pci_disable_device(pdev);
}
-#endif
static int __init ioat_init_module(void)
{
- return pci_register_driver(_pci_drv);
+ return pci_register_driver(_pci_driver);
}
module_init(ioat_init_module);
static void __exit ioat_exit_module(void)
{
- pci_unregister_driver(_pci_drv);
+ pci_unregister_driver(_pci_driver);
}
module_exit(ioat_exit_module);
diff --git a/drivers/dma/ioat_dma.c b/drivers/dma/ioat_dma.c
index 66c5bb5..59d4344 100644
--- a/drivers/dma/ioat_dma.c
+++ b/drivers/dma/ioat_dma.c
@@ -931,7 +931,6 @@ err_completion_pool:
err_dma_pool:
kfree(device);
err_kzalloc:
- iounmap(iobase);
dev_err(>pdev->dev,
"ioatdma: Intel(R) I/OAT DMA Engine initialization failed\n");
return NULL;
@@ -949,6 +948,10 @@ void ioat_dma_remove(struct ioatdma_device *device)
pci_pool_destroy(device->dma_pool);
pci_pool_destroy(device->completion_pool);
+ iounmap(device->reg_base);
+ pci_release_regions(device->pdev);
+ pci_disable_device(device->pdev);
+
list_for_each_entry_safe(chan, _chan,
>common.channels, device_node) {
ioat_chan = to_ioat_chan(chan);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
