Re: [PATCH 3/4] [SCSI] ips: PCI API cleanups
Jeff Garzik wrote:
> * pass Scsi_Host to ips_remove_device() via pci_set_drvdata(),
> allowing us to eliminate the ips_ha[] search loop and call
> ips_release() directly.
>
> * call pci_{request,release}_regions() and eliminate individual
> request/release_[mem_]region() calls
>
> * call pci_disable_device(), paired with pci_enable_device()
>
> * s/0/NULL/ in a few places
>
> * check ioremap() return value
> @@ -7036,32 +7042,17 @@ ips_init_phase1(struct pci_dev *pci_dev, int
> *indexPtr) uint32_t base;
> uint32_t offs;
>
> - if (!request_mem_region(mem_addr, mem_len, "ips")) {
> - IPS_PRINTK(KERN_WARNING, pci_dev,
> -"Couldn't allocate IO Memory space %x len
> %d.\n",
> -mem_addr, mem_len);
> - return -1;
> - }
> -
> base = mem_addr & PAGE_MASK;
> offs = mem_addr - base;
> ioremap_ptr = ioremap(base, PAGE_SIZE);
This looks odd. What are we actually doing here?
It seems that we want to map that PCI BAR. Since we're playing with PAGE_MASK
I assume the BAR always has a length
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH 0/2] add new notifier function ,take2
Nick Piggin wrote: >>> Is it possible to use a single bit of common code and a single >>> notifier for these things? Or is it too difficult? >> > >> > I'm sorry, I can't understand your image well. I'd like to know details of >> > your image. > > Rather than have each of "RAS tools" have their own notifier, and have > the user specify the priority of the notifiers, introduce some layer > which _knows_ that, for example, only one of these subsystems will be > called (it could arbitrate, perhaps distinguish between destructive and > non-destructive ones). It would need only a single notifier, but would > then have a specific way of calling into the ras modules. > > Does this make sense? I guess it is a lot more work to do, so maybe your > solution is the best one for now. Hi Nick, Thank you for your explanation. I understand. :-) This is crash_stop (the common infrastructure for debug tools) by Keith Owens. http://www.mail-archive.com/[EMAIL PROTECTED]/msg01929.html Is it same as your idea? I think it is very nice solution for debug tools conflict problem. By the way, on old notify_chain, if admin wants to change the list order, admin have to recompile the kernel. My patches add new *generic* notify_chain which admin can modify the list order. My patches are not only for RAS tools problem. I'm happy if both patches are merged into mainline. :-) Thanks, Takenori - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] iwl3945 & iwl4965: mark more functions/variables static
On Fri, 2007-10-12 at 14:32 +0200, Christoph Hellwig wrote: > int iwl_param_disable; /* def: enable radio */ > int iwl_param_antenna; /* def: 0 = both antennas (use diversity) > */ > int iwl_param_hwcrypto; /* def: using software encryption */ > -int iwl_param_qos_enable = 1; > +static int iwl_param_qos_enable = 1; > int iwl_param_queues_num = IWL_MAX_NUM_QUEUES; I think more of them could be static. Will send a updated patch later. Thanks, -yi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.24-rc1] fix sg_phys to use dma_addr_t
On Wed, 24 Oct 2007, Arjan van de Ven wrote: > > Signed-off-by: Hugh Dickins <[EMAIL PROTECTED]> > > --- > > Whether this is a complete patch, suitable for all architectures, > > I'm not sure: it builds, boots and runs correctly on the x86_32 box > > in question, but you'll be a lot wiser than me about using dma_addr_t > > for everyone. (Seems a bit of a shame to include here, > > when I think all arches already get to include it one way or another, > > typically via asm/scatterlist.h; but I guess it's safest to repeat > > it.) > > there is a problem with this... sg_phys doesn't return an actual *dma* > address at least not an address you can give to the device. > Using dma_addr_t is thus a bit misleading. True. Perhaps sg_phys() should use its own sg_phys_addr_t, defined or typedefed to be the same as dma_addr_t. But would this inline function then be the only place in the tree which uses that type? If so, then it'd probably be better just to let sg_phys() carry on using dma_addr_t, but insert a comment there to make your point. But I'll leave it to Jens to fix up the patch appropriately: for all I know, there might be arches on which using dma_addr_t there actually does the wrong thing - I don't think so, but I know too little about it. Hugh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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+comment] fix tmpfs BUG and AOP_WRITEPAGE_ACTIVATE
On Thu, 25 Oct 2007, Pekka Enberg wrote: > On 10/25/07, Hugh Dickins <[EMAIL PROTECTED]> wrote: > > --- 2.6.24-rc1/mm/shmem.c 2007-10-24 07:16:04.0 +0100 > > +++ linux/mm/shmem.c2007-10-24 22:31:09.0 +0100 > > @@ -915,6 +915,21 @@ static int shmem_writepage(struct page * > > struct inode *inode; > > > > BUG_ON(!PageLocked(page)); > > + /* > > +* shmem_backing_dev_info's capabilities prevent regular writeback > > or > > +* sync from ever calling shmem_writepage; but a stacking filesystem > > +* may use the ->writepage of its underlying filesystem, in which > > case > > I find the above bit somewhat misleading as it implies that the > !wbc->for_reclaim case can be removed after ecryptfs has similar fix > as unionfs. Can we just say that while BDI_CAP_NO_WRITEBACK does > prevent some callers from entering ->writepage(), it's just an > optimization and ->writepage() must deal with !wbc->for_reclaim case > properly? Sorry for being obtuse, but I don't see how that's misleading at all. ecryptfs already has a (dissimilar) fix in 2.6.24-rc1, not using the writepage route at all. But it remains the case that some stacking filesystem may (would you prefer "might" to "may"? "may" has a nice double meaning of "might" and "we'll allow it", but this patch does indeed allow it) use the ->writepage of its underlying filesystem. With unionfs also fixed, we don't know of an absolute need for this patch (and so, on that basis, the !wbc->for_reclaim case could indeed be removed very soon); but as I see it, the unionfs case has shown that it's time to future-proof this code against whatever stacking filesystems come along. Hence I didn't mention the names of such filesystems in the source comment. The !page_mapped assumption has been built in there since earliest 2.4, but it took a while for us to get a way to express it in a BUG. Hugh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] lguest: paravirt boot code
On Thu, 25 Oct 2007 15:19:05 +1000 Rusty Russell <[EMAIL PROTECTED]> wrote: > > So, this time for sure! I haven't figured out how everyone does those neat > committer: commits* lists, but I'm sure there's an option here somewhere... try "git request-pull ..." -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpExv8Gslr4p.pgp Description: PGP signature
Re: sysfs sys/kernel/ namespace (was Re: [PATCH 0/2] add new notifier function ,take2)
On Thursday 25 October 2007 15:45, Greg KH wrote: > On Thu, Oct 25, 2007 at 12:31:06PM +1000, Nick Piggin wrote: > > On Wednesday 24 October 2007 21:12, Kay Sievers wrote: > > > On 10/24/07, Nick Piggin <[EMAIL PROTECTED]> wrote: > > > It was intended to be something like /proc/sys/kernel/ only. > > > > Really? So you'd be happy to have a /sys/dev /sys/fs /sys/kernel > > /sys/net /sys/vm etc? "kernel" to me shouldn't really imply the > > stuff under the kernel/ source directory or other random stuff > > that doesn't fit into another directory, but attributes that are > > directly related to the kernel software (rather than directly > > associated with any device). > > What would you want in /sys/net and /sys/dev and /sys/vm? I don't mind > putting subdirs in /sys/kernel/ if you want it. I guess potentially things that are today in /proc/sys/*. Sysfs is much closer to the "right" place for this kind of attributes than procfs, isn't it? > > It would be nice to get a sysfs content maintainer or two. Just > > having new additions occasionally reviewed along with the rest of > > a patch, by random people, doesn't really aid consistency. Would it > > be much trouble to ask that _all_ additions to sysfs be accompanied > > by notification to this maintainer, along with a few line description? > > (then merge would require SOB from said maintainer). > > No, I would _love_ that. We should make the requirement that all new > sysfs files be documented in Documentation/API/ like that details. Obviously I'm for that too. A mandatory cc to a linux-abi list, documentation, and an acked-by from the relevant API maintainers, etc. All it needs is upstream to agree and sometime to implement it. > I'll be glad to review it, but as it's pretty trivial to add sysfs > files, everyone ends up doing it :) If it fits with the overall direction that yourself / Kay / everyone else has in mind, then yes. Problem is that if this stuff goes unreviewed, or reviewed by different people who don't have a coherent idea of what the API should look like, then it ends in a mess that you can't fix easily. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 - GIT pull] first step to get rid of x86_64 and i386 dirs
On 10/24/07, Randy Dunlap <[EMAIL PROTECTED]> wrote: > On Wed, 24 Oct 2007 23:30:52 +0200 Sam Ravnborg wrote: > > > Hi Ingo. > > > > This is first step in getting rid of the two directories. > > I had to do some very minor modifications in common files > > to let it work out - but nothing really hackish. > > > > If you & Thomas + hpa are OK with the changes they can be > > pulled from: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/sam/x86.git > > > > As this is mostly renames I have attached a git -M diff only. > > > > The remaining stuff is Kconfig files. > > > > Before looking into these I am hoping someone could > > step in and make the two Kconfig.debug > > files 100% equal - because then I can fix the kconfig > > stuff and finally kill the two directories. > > Uh, maybe I jumped too far. I merged the 2 x86 Kconfig.debug files > into arch/x86/Kconfig.debug > > --- > > From: Randy Dunlap <[EMAIL PROTECTED]> > > Merge i386/Kconfig.debug and x86_64/Kconfig.debug into x86/Kconfig.debug, > using "depends on X86_32" or X86_64 when needed. > > Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> > --- > arch/i386/Kconfig.debug | 88 -- > arch/x86/Kconfig.debug| 119 > ++ > arch/x86_64/Kconfig.debug | 61 --- > 3 files changed, 119 insertions(+), 149 deletions(-) > > --- linux-2.6.24-rc1.orig/arch/i386/Kconfig.debug > +++ /dev/null > @@ -1,88 +0,0 @@ > -menu "Kernel hacking" > - > -config TRACE_IRQFLAGS_SUPPORT > - bool > - default y > - > -source "lib/Kconfig.debug" > - > -config EARLY_PRINTK > - bool "Early printk" if EMBEDDED && DEBUG_KERNEL > - default y > - help > - Write kernel log output directly into the VGA buffer or to a serial > - port. ... > --- /dev/null > +++ linux-2.6.24-rc1/arch/x86/Kconfig.debug > @@ -0,0 +1,119 @@ > +menu "Kernel hacking" > + > +config TRACE_IRQFLAGS_SUPPORT > + def_bool y > + > +source "lib/Kconfig.debug" > + > +config EARLY_PRINTK > + bool "Early printk" if EMBEDDED && DEBUG_KERNEL > + default y > + depends on X86_32 > + help > + Write kernel log output directly into the VGA buffer or to a serial > + port. > + > + This is useful for kernel debugging when your machine crashes very > + early before the console code is initialized. For normal operation > + it is not recommended because it looks ugly and doesn't cooperate > + with klogd/syslogd or the X server. You should normally N here, > + unless you want to debug such a crash. > + ... in x86_64/Kconfig has EARLY_PRINTK too config EARLY_PRINTK bool default y YH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Exporting a lot of data to other processes?
Hello everybody, I've already pondered about a question for some time, and would like to ask for a better idea here. It's not entirely about the kernel - although that surely has some impact, too. I've got some process/daemon, that wants to export information to other processes. As model for exporting that data I found the sysfs and procfs nice - an easy "cat" can give you the needed data. Now, in order to do something like that from userspace, I either have to: -) use FUSE - feels slow (many context switches) - much overhead for such common things (another daemon) -) use named pipes in some directory structure, and keep them open in the daemon - waiting to be written to - many open filehandles - feels not really useable for bigger (>1000) structures -) use some ramfs/shmfs or similar, and overwrite the data occasionally - not current data - runtime overhead (processor load) Now the open/close events wouldn't be interesting; the read() and (possibly) write events would have to be relayed (which is not the case for FUSE, IIUC) Is there some better way? For small structures the pipes seem to be the best way ... just wait for a reader, give it data, and finished. Thank you for all ideas. Regards, Phil - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git patches] IDE updates (part 2)
Al Viro wrote: Proposed addition to icside part, provided that ARM folks ACK it - gets icside to build and AFAICS it's correct: diff --git a/drivers/ata/pata_icside.c b/drivers/ata/pata_icside.c index be30923..842fe08 100644 --- a/drivers/ata/pata_icside.c +++ b/drivers/ata/pata_icside.c @@ -332,12 +332,13 @@ static void ata_dummy_noret(struct ata_port *port) 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/
Re: [2.6 patch] libata-core.c: make 2 functions static
Adrian Bunk wrote: strn_pattern_cmp() and ata_port_detach() can become static. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- drivers/ata/libata-core.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) 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/
Re: [Bugme-new] [Bug 9217] New: CONFIG_CMDLINE doesn't pass to kernel
On Wed, 24 Oct 2007 05:32:14 -0700 (PDT) [EMAIL PROTECTED] wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=9217 > > Summary: CONFIG_CMDLINE doesn't pass to kernel > Product: Other > Version: 2.5 > KernelVersion: 2.6.23 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: high > Priority: P1 > Component: Other > AssignedTo: [EMAIL PROTECTED] > ReportedBy: [EMAIL PROTECTED] > > > Most recent kernel where this bug did not occur:2.6.24-rc1 > Distribution: Debian Armel (arm with EABI) > Hardware Environment: Sharp Zaurus 750 (ARM pxa255) > Software Environment: Debian > Problem Description: > I try to upgrade kernel from 2.6.22.9 to 2.6.23. > 2.6.22.9 works correct. Kernel 2.6.23 doesn't use CONFIG_CMDLINE and doesn't > pass bootparams: > CONFIG_CMDLINE="console=ttyS0,115200n8 console=tty1 noinitrd > root=/dev/mmcblk0p1 rootfstype=ext3 rw rootdelay=5" > But kernel still try to mount /dev/mtdblock2 using jffs2. > Steps to reproduce: > Compile kernel with CONFIG_CMDLINE and try to boot. > > Something broke CONFIG_CMDLINE of ARM (at least) between 2.6.22 and 2.6.23. I don't know whether it was an ARM patch one of those kernel-wide changes. We have futzed with the command-line parsing a bit recently, but the 2.6.23 changelog doesn't suggest anything obvious. I think the zaurus kernel deliberately ignored the bootparams passed in by the device's bootloader. The 2.6.23 kernel now honors the r2 setting from the bootloader, which is most likely pointing to those ATAGs that were being ignored earlier. I suppose you can hack up the logic in setup.c where the ATAGs are parsed, but it seems to me that it would be better to work out some logic, perhaps in the fixup section for that machine, to do whatever is necessary to override or otherwise get along with the bootloader. Mike (mwester) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: sysfs sys/kernel/ namespace (was Re: [PATCH 0/2] add new notifier function ,take2)
On Thu, Oct 25, 2007 at 12:31:06PM +1000, Nick Piggin wrote: > On Wednesday 24 October 2007 21:12, Kay Sievers wrote: > > On 10/24/07, Nick Piggin <[EMAIL PROTECTED]> wrote: > > > On Tuesday 23 October 2007 10:55, Takenori Nagano wrote: > > > > Nick Piggin wrote: > > > > > One thing I'd suggest is not to use debugfs, if it is going to > > > > > be a useful end-user feature. > > > > > > > > Is /sys/kernel/notifier_name/ an appropriate place? > > > > > > I'm curious about the /sys/kernel/ namespace. I had presumed that > > > it is intended to replace /proc/sys/ basically with the same > > > functionality. > > > > It was intended to be something like /proc/sys/kernel/ only. > > Really? So you'd be happy to have a /sys/dev /sys/fs /sys/kernel > /sys/net /sys/vm etc? "kernel" to me shouldn't really imply the > stuff under the kernel/ source directory or other random stuff > that doesn't fit into another directory, but attributes that are > directly related to the kernel software (rather than directly > associated with any device). What would you want in /sys/net and /sys/dev and /sys/vm? I don't mind putting subdirs in /sys/kernel/ if you want it. > > > I _assume_ these are system software stats and > > > tunables that are not exactly linked to device drivers (OTOH, > > > where do you draw the line? eg. Would filesystems go here? > > > > We already have /sys/fs/ ? > > > > > Core network algorithm tunables might, but per interface ones probably > > > not...). > > > > We will merge the nonsense of "block/", "class/" and "bus/" to one > > "subsystem". The block, class, bus directories will only be kept as > > symlinks for compatibility. Then every subsystem has a directory like: > > /sys/subsystem/block/, /sys/subsystem/net/ and the devices of the > > subsystem are in a devices/ directory below that. Just like the > > /sys/bus/< name>/devices/ layout looks today. All subsystem-global > > tunables can go below the /sys/subsystem// directory, without > > clashing with the list of devices or anything else. > > Makes sense. > > > > > I don't know. Is there guidelines for sysfs (and procfs for that > > > matter)? Is anyone maintaining it (not the infrastructure, but > > > the actual content)? > > > > Unfortunately, there was never really a guideline. > > > > > It's kind of ironic that /proc/sys/ looks like one of the best > > > organised directories in proc, while /sys/kernel seems to be in > > > danger of becoming a mess: it has kexec and uevent files in the > > > base directory, rather than in subdirectories... > > > > True, just looking at it now, people do crazy things like: > > /sys/kernel/notes, which is a file with binary content, and a name > > nobody will ever be able to guess what it is good for. That should > > definitely go into a section/ directory. Also the VM stuff there > > should probably move to a /sys/vm/ directory along with the weird > > placed top-level /sys/slab/. > > Top level directory IMO should be kept as sparse as possible. If > you agree to /sys/mm for example, that's fine, but then slab should > go under that. (I'd prefer all to go underneath /sys/kernel, but...). > > It would be nice to get a sysfs content maintainer or two. Just > having new additions occasionally reviewed along with the rest of > a patch, by random people, doesn't really aid consistency. Would it > be much trouble to ask that _all_ additions to sysfs be accompanied > by notification to this maintainer, along with a few line description? > (then merge would require SOB from said maintainer). No, I would _love_ that. We should make the requirement that all new sysfs files be documented in Documentation/API/ like that details. I'll be glad to review it, but as it's pretty trivial to add sysfs files, everyone ends up doing it :) thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ata: ahci: Enable enclosure management via LED (resend)
Kristen Carlson Accardi wrote: Enable enclosure management via LED As described in the AHCI spec, some AHCI controllers may support Enclosure management via a variety of protocols. This patch adds support for the LED message type that is specified in AHCI 1.1 and higher. Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]> --- drivers/ata/ahci.c| 153 +- drivers/ata/libata-scsi.c |5 - include/linux/libata.h|3 3 files changed, 157 insertions(+), 4 deletions(-) Comments: 1) it seems a bit questionable that the attributes are globally writeable, even by unpriveleged heathens? 2) ahci_led_locate_store() and ahci_led_fault()_store are the same, save for a single constant 3) Don't document ahci_em_messages values (like SGPIO) which are not actually supported in the code. Feel free to put these in a comment to make sure others follow your lead, however 4) ahci_transmit_led_message() is issued completely without any locking. that does not look safe in the face of libata-eh doing a reset? 5) please run through scripts/checkpatch in 2.6.24-rc1, there are several "use tabs not spaces" type errors and some other minor style nits 6) ATA_FLAG_EM is added but never used 7) Is it valid to check capabilities bit 6 (EMS) on AHCI 1.0? I would tend to shy away from assuming that all silicon gives us sane 'reserved' bits :) 8) when is this actually used? do you have a sample user in userspace? does a userspace daemon watch disk activity and manage LEDs somehow? I'm a bit cloudy on the usage need of this. 9) overall, sans the above comments, the overall goal seems OK to me, and the patch seems pretty good. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc1 oops
Jens, I should have CC'ed to you. On Thu, 25 Oct 2007 10:22:02 +0900 FUJITA Tomonori <[EMAIL PROTECTED]> wrote: > On Thu, 25 Oct 2007 01:40:00 +0100 > Sid Boyce <[EMAIL PROTECTED]> wrote: > > > x86_64 dual, gcc version 4.2.2 (SUSE Linux). > > [ cut here ] > > kernel BUG at include/linux/scatterlist.h:50! > > invalid opcode: [1] SMP > > CPU 1 > > Modules linked in: ub crc_itu_t hwmon cdrom soundcore v4l1_compat > > videobuf_core btcx_risc ff_memless floppy sg forcedeth ehci_hcd ohci_hcd > > sd_mod usbcore jfs edd ext3 mbcache jbd fan pata_jmicron ahci sata_nv > > pata_amd libata scsi_mod thermal processor > > Pid: 0, comm: swapper Not tainted 2.6.24-rc1-smp #1 > > RIP: 0010:[] [] > > :ub:ub_state_sense+0x9a/0x169 > > RSP: 0018:810100697e60 EFLAGS: 00010093 > > RAX: 87654321 RBX: 810105d55000 RCX: 81011f975540 > > RDX: RSI: RDI: 81011f975540 > > RBP: 810105d51000 R08: R09: 810105d55098 > > R10: 810001c319b8 R11: 0286 R12: 810105d55098 > > R13: 810105d55260 R14: 810105d55278 R15: 810105d55298 > > FS: 2afb8597c6f0() GS:81011800() knlGS: > > CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b > > CR2: 2afb8548200f CR3: 00010615b000 CR4: 06e0 > > DR0: DR1: DR2: > > DR3: DR6: 0ff0 DR7: 0400 > > Process swapper (pid: 0, threadinfo 81010069, task 810100689160) > > Stack: 0001 810105d55000 810105d51000 > > 810105d55260 881f4d43 810105919998 810105d553a0 > > 810105d553af 810105d55348 0286 810105d55058 > > Call Trace: > > [] :ub:ub_scsi_action+0x1e3/0x214 > > [] tasklet_action+0x54/0x97 > > [] __do_softirq+0x65/0xce > > [] call_softirq+0x1c/0x28 > > [] do_softirq+0x2c/0x7d > > [] irq_exit+0x3f/0x84 > > [] do_IRQ+0x13e/0x15f > > [] default_idle+0x0/0x3d > > [] default_idle+0x0/0x3d > > [] ret_from_intr+0x0/0xa > > [] default_idle+0x29/0x3d > > [] cpu_idle+0x93/0xbb > > Can you try this? > > Thanks, > > diff --git a/drivers/block/ub.c b/drivers/block/ub.c > index 14143f2..78f158f 100644 > --- a/drivers/block/ub.c > +++ b/drivers/block/ub.c > @@ -1428,6 +1428,7 @@ static void ub_state_sense(struct ub_dev *sc, struct > ub_scsi_cmd *cmd) > scmd->state = UB_CMDST_INIT; > scmd->nsg = 1; > sg = &scmd->sgv[0]; > + sg_init_table(sg, UB_MAX_REQ_SG); > sg_set_page(sg, virt_to_page(sc->top_sense)); > sg->offset = (unsigned long)sc->top_sense & (PAGE_SIZE-1); > sg->length = UB_SENSE_SIZE; > @@ -1864,6 +1865,7 @@ static int ub_sync_read_cap(struct ub_dev *sc, struct > ub_lun *lun, > cmd->state = UB_CMDST_INIT; > cmd->nsg = 1; > sg = &cmd->sgv[0]; > + sg_init_table(sg, UB_MAX_REQ_SG); > sg_set_page(sg, virt_to_page(p)); > sg->offset = (unsigned long)p & (PAGE_SIZE-1); > sg->length = 8; Here's a modified version for your sg branch (for sg_set_page API changes). - From: FUJITA Tomonori <[EMAIL PROTECTED]> Subject: [PATCH] ub: add sg_init_table for sense and read capacity commands Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]> --- drivers/block/ub.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/block/ub.c b/drivers/block/ub.c index 5e740e1..08e909d 100644 --- a/drivers/block/ub.c +++ b/drivers/block/ub.c @@ -1428,6 +1428,7 @@ static void ub_state_sense(struct ub_dev *sc, struct ub_scsi_cmd *cmd) scmd->state = UB_CMDST_INIT; scmd->nsg = 1; sg = &scmd->sgv[0]; + sg_init_table(sg, UB_MAX_REQ_SG); sg_set_page(sg, virt_to_page(sc->top_sense), UB_SENSE_SIZE, (unsigned long)sc->top_sense & (PAGE_SIZE-1)); scmd->len = UB_SENSE_SIZE; @@ -1863,6 +1864,7 @@ static int ub_sync_read_cap(struct ub_dev *sc, struct ub_lun *lun, cmd->state = UB_CMDST_INIT; cmd->nsg = 1; sg = &cmd->sgv[0]; + sg_init_table(sg, UB_MAX_REQ_SG); sg_set_page(sg, virt_to_page(p), 8, (unsigned long)p & (PAGE_SIZE-1)); cmd->len = 8; cmd->lun = lun; -- 1.5.2.4 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 0/3] MBCS: Convert semaphores to the mutex API
El Wed, Oct 24, 2007 at 09:11:49PM -0700 Andrew Morton ha dit: > On Wed, 24 Oct 2007 19:08:58 +0200 [EMAIL PROTECTED] wrote: > > > MBCS: Convert the semaphores algolock, dmareadlock and dmawritelock to the > > mutex API > > Thanks. Has this actually been runtime-tested? no, i could only test successfull compilation as i don't have the device > btw, your patches are in `patch -p2' form: > > --- kernel.orig/linux-2.6/drivers/char/mbcs.c > +++ kernel/linux-2.6/drivers/char/mbcs.c > > should have been in `patch -p1' form: > > --- linux-2.6/drivers/char/mbcs.c > +++ linux-2.6/drivers/char/mbcs.c > > I'd suggest that you grab and learn > http://savannah.nongnu.org/projects/quilt/ - it takes care of all these > things for you. i actually used quilt for this patchset but must have missed something. thanks for the pointer! -- Matthias Kaehlcke Linux Application Developer Barcelona Dreams and reality are opposites. Action synthesizes them (Assata Shakur) .''`. using free software / Debian GNU/Linux | http://debian.org : :' : `. `'` gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4 `- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Input: Support for a less exclusive grab.
On Wed, 2007-24-10 at 11:35 -0400, Zephaniah E. Hull wrote: > We need a way to, at the absolute minimum, unbind the keyboard from the > text console. The current solution sucks for things like rfkill. > > I'm not convinced that Ryan's fix is any better, but just saying that X > should open the console and ignore the characters is simply not an > option as far as I am concerned for X. Can you think of any other way to separate things like rfkill/evdev from things like the text console that's less hacky than my 'priority' scheme? 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: [PATCH 0/4]: Resolve MSI vs. INTX_DISABLE quirks.
David Miller wrote: The forthcoming patches are also available from: kernel.org:/pub/scm/linux/kernel/git/davem/msiquirk-2.6.git and clean up the handling of the common quirk wherein setting INTX_DISABLE will mistakedly disable MSI generation for some devices. For devices without that problem, we want to keep the pci_intx() calls in drivers/pci/msi.c because those help protect against devices with the opposite problem. Such devices always generate INTX interrupts even when MSI is enabled, unless INTX_DISABLE is set. Michael, please pay special attention to patch #3. I think I picked the correct PCI device IDs to match for the quirk (5714* and 5780*) but it's possible we might need more elaborate checks here. It at least worked properly for the chips in my Niagara system. In addition to the Tigon3 cases, I added quirk entries for the SB700/800 SATA chips and the IXP SB400 USB controllers. Signed-off-by: David S. Miller <[EMAIL PROTECTED]> I'm happy with this patch series. A quirk is better than a sledgehammer, and MSI-mode SATA is better than INTX-mode SATA :) 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+comment] fix tmpfs BUG and AOP_WRITEPAGE_ACTIVATE
Hi Hugh, On 10/25/07, Hugh Dickins <[EMAIL PROTECTED]> wrote: > --- 2.6.24-rc1/mm/shmem.c 2007-10-24 07:16:04.0 +0100 > +++ linux/mm/shmem.c2007-10-24 22:31:09.0 +0100 > @@ -915,6 +915,21 @@ static int shmem_writepage(struct page * > struct inode *inode; > > BUG_ON(!PageLocked(page)); > + /* > +* shmem_backing_dev_info's capabilities prevent regular writeback or > +* sync from ever calling shmem_writepage; but a stacking filesystem > +* may use the ->writepage of its underlying filesystem, in which case I find the above bit somewhat misleading as it implies that the !wbc->for_reclaim case can be removed after ecryptfs has similar fix as unionfs. Can we just say that while BDI_CAP_NO_WRITEBACK does prevent some callers from entering ->writepage(), it's just an optimization and ->writepage() must deal with !wbc->for_reclaim case properly? Pekka - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Enable Aggressive Link Power management for AHCI controllers.
Kristen Carlson Accardi wrote:
This patch will set the correct bits to turn on Aggressive
Link Power Management (ALPM) for the ahci driver. This
will cause the controller and disk to negotiate a lower
power state for the link when there is no activity (see
the AHCI 1.x spec for details). This feature is mutually
exclusive with Hot Plug, so when ALPM is enabled, Hot Plug
is disabled. ALPM will be enabled by default, but it is
settable via the scsi host syfs interface. Possible
settings for this feature are:
Setting Effect
--
min_power ALPM is enabled, and link set to enter
lowest power state (SLUMBER) when idle
Hot plug not allowed.
max_performance ALPM is disabled, Hot Plug is allowed
medium_powerALPM is enabled, and link set to enter
second lowest power state (PARTIAL) when
idle. Hot plug not allowed.
Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]>
applied, with minor changes (attached)
Please check libata-dev.git#alpm and make sure it still works as
expected (after it mirrors out to git.kernel.org)
commit 0fdf9763a76f4cce208b7139e555019217765e81
Author: Kristen Carlson Accardi <[EMAIL PROTECTED]>
Date: Thu Oct 25 01:33:26 2007 -0400
[libata] AHCI: add hw link power management support
This patch will set the correct bits to turn on Aggressive
Link Power Management (ALPM) for the ahci driver. This
will cause the controller and disk to negotiate a lower
power state for the link when there is no activity (see
the AHCI 1.x spec for details). This feature is mutually
exclusive with Hot Plug, so when ALPM is enabled, Hot Plug
is disabled. ALPM will be enabled by default, but it is
settable via the scsi host syfs interface. Possible
settings for this feature are:
Setting Effect
--
min_power ALPM is enabled, and link set to enter
lowest power state (SLUMBER) when idle
Hot plug not allowed.
max_performance ALPM is disabled, Hot Plug is allowed
medium_powerALPM is enabled, and link set to enter
second lowest power state (PARTIAL) when
idle. Hot plug not allowed.
Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]>
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
drivers/ata/ahci.c | 157 -
1 file changed, 155 insertions(+), 2 deletions(-)
0fdf9763a76f4cce208b7139e555019217765e81
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 95229e7..2b4faca 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -48,6 +48,9 @@
#define DRV_NAME "ahci"
#define DRV_VERSION"3.0"
+static int ahci_enable_alpm(struct ata_port *ap,
+ enum link_pm policy);
+static void ahci_disable_alpm(struct ata_port *ap);
enum {
AHCI_PCI_BAR= 5,
@@ -98,6 +101,7 @@ enum {
HOST_CAP_SSC= (1 << 14), /* Slumber capable */
HOST_CAP_PMP= (1 << 17), /* Port Multiplier support */
HOST_CAP_CLO= (1 << 24), /* Command List Override support */
+ HOST_CAP_ALPM = (1 << 26), /* Aggressive Link PM support */
HOST_CAP_SSS= (1 << 27), /* Staggered Spin-up */
HOST_CAP_SNTF = (1 << 29), /* SNotification register */
HOST_CAP_NCQ= (1 << 30), /* Native Command Queueing */
@@ -154,6 +158,8 @@ enum {
PORT_IRQ_PIOS_FIS | PORT_IRQ_D2H_REG_FIS,
/* PORT_CMD bits */
+ PORT_CMD_ASP= (1 << 27), /* Aggressive Slumber/Partial */
+ PORT_CMD_ALPE = (1 << 26), /* Aggressive Link PM enable */
PORT_CMD_ATAPI = (1 << 24), /* Device is ATAPI */
PORT_CMD_PMP= (1 << 17), /* PMP attached */
PORT_CMD_LIST_ON= (1 << 15), /* cmd list DMA engine running */
@@ -177,13 +183,14 @@ enum {
AHCI_HFLAG_MV_PATA = (1 << 4), /* PATA port */
AHCI_HFLAG_NO_MSI = (1 << 5), /* no PCI MSI */
AHCI_HFLAG_NO_PMP = (1 << 6), /* no PMP */
+ AHCI_HFLAG_NO_HOTPLUG = (1 << 7), /* ignore PxSERR.DIAG.N */
/* ap->flags bits */
- AHCI_FLAG_NO_HOTPLUG= (1 << 24), /* ignore PxSERR.DIAG.N */
AHCI_FLAG_COMMON= ATA_FLAG_SATA | ATA_FLAG_NO_LEGACY |
ATA_FLAG_MMIO | ATA_FLAG_PIO_DMA |
- ATA_FLAG_ACPI_SATA | ATA_FLAG_AN,
+ ATA_FLAG_ACPI_SATA | ATA_FLAG_AN |
+ ATA_FLAG_IPM,
AHCI_LFLAG_COMMON = ATA_LFLAG_SKIP_D2H_BSY,
};
@@ -252,6 +259,11
Re: [BUG] 2.6.23-git18 Kernel oops in sg helpers
On Thu, Oct 25 2007, FUJITA Tomonori wrote:
> On Wed, 24 Oct 2007 21:38:30 +0530
> Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
>
> > FUJITA Tomonori wrote:
> > > On Wed, 24 Oct 2007 12:54:36 +0100
> > > Andy Whitcroft <[EMAIL PROTECTED]> wrote:
> > >
> > >> On Tue, Oct 23, 2007 at 08:44:20PM +0200, Jens Axboe wrote:
> > >>> On Tue, Oct 23 2007, Kamalesh Babulal wrote:
> > Hi,
> >
> > Kernel oops is triggered while running fsx-linux test, followed by cpu
> > softlock
> > over the AMD box
> >
> > Unable to handle kernel NULL pointer dereference at 0018
> > RIP:
> > [] gart_map_sg+0x26c/0x406
> > PGD 10185b067 PUD 10075b067 PMD 0
> > Oops: 0002 [1] SMP
> > CPU 3
> > Modules linked in:
> > Pid: 18676, comm: fsx-linux Not tainted 2.6.23-git18-autokern1 #1
> > RIP: 0010:[] []
> > gart_map_sg+0x26c/0x406
> > RSP: :810181edf948 EFLAGS: 00010002
> > >>> Can you check where gart_map_sg+0x26c is at? Make sure you have
> > >>> CONFIG_DEBUG_INFO defined, then do:
> > >>>
> > >>> $ gdb vmlinux
> > >>> $ l *gart_map_sg+0x26c
> > >> Ok, this problem still seems to be about in 2.6.24-rc1. Here is the gdb
> > >> output from that version, the panic (also below) seems the same:
> > >>
> > >> (gdb) l *gart_map_sg+0x26c
> > >> 0x8022011e is in gart_map_sg (arch/x86/kernel/pci-gart_64.c:433).
> > >> 428 goto error;
> > >> 429 out++;
> > >> 430 flush_gart();
> > >> 431 if (out < nents) {
> > >> 432 sgmap = sg_next(sgmap);
> > >> 433 sgmap->dma_length = 0;
> > >> 434 }
> > >> 435 return out;
> > >> 436
> > >> 437 error:
> > >>
> > >> So it seems sg_next has returned 0.
> > >
> > > Have you tried this?
> > >
> > > http://marc.info/?l=linux-kernel&m=119317981406073&w=2
> > > -
> > Hi,
> > Thanks, this patch solves the kernel oops.
>
> Thanks for testing!
>
> Jens, here's the proper changelog.
Thanks, applied!
--
Jens Axboe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] fujitsu-laptop.c: remove dead code
> This patch removes dead code spotted by the Coverity checker.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Ack.
Signed-off-by: Jonathan Woithe <[EMAIL PROTECTED]>
jonathan
---
--- linux-2.6/drivers/misc/fujitsu-laptop.c.old 2007-10-23 18:51:10.0
+0200
+++ linux-2.6/drivers/misc/fujitsu-laptop.c 2007-10-23 18:51:50.0
+0200
@@ -110,33 +110,30 @@ static int get_lcd_level(void)
// Get the Brightness
status =
acpi_evaluate_integer(fujitsu->acpi_handle, "GBLL", NULL, &state);
if (status < 0)
return status;
fujitsu->fuj02b1_state = state;
fujitsu->brightness_level = state & 0x0fff;
if (state & 0x8000)
fujitsu->brightness_changed = 1;
else
fujitsu->brightness_changed = 0;
- if (status < 0)
- return status;
-
return fujitsu->brightness_level;
}
/* Backlight device stuff */
static int bl_get_brightness(struct backlight_device *b)
{
return get_lcd_level();
}
static int bl_update_status(struct backlight_device *b)
{
return set_lcd_level(b->props.brightness);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] fujitsu-laptop.c: make 2 functions static
> acpi_fujitsu_{add,remove}() can become static.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Looks fine. Ack.
Signed-off-by: Jonathan Woithe <[EMAIL PROTECTED]>
jonathan
---
drivers/misc/fujitsu-laptop.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
175c8b648a54b625037916a8f6e3851574141532
diff --git a/drivers/misc/fujitsu-laptop.c b/drivers/misc/fujitsu-laptop.c
index d366a6c..d686ba7 100644
--- a/drivers/misc/fujitsu-laptop.c
+++ b/drivers/misc/fujitsu-laptop.c
@@ -198,7 +198,7 @@ static struct platform_driver fujitsupf_driver = {
/* ACPI device */
-int acpi_fujitsu_add(struct acpi_device *device)
+static int acpi_fujitsu_add(struct acpi_device *device)
{
int result = 0;
int state = 0;
@@ -229,7 +229,7 @@ int acpi_fujitsu_add(struct acpi_device *device)
return result;
}
-int acpi_fujitsu_remove(struct acpi_device *device, int type)
+static int acpi_fujitsu_remove(struct acpi_device *device, int type)
{
ACPI_FUNCTION_TRACE("acpi_fujitsu_remove");
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc1 doesn't build...
Theodore Tso wrote: > I can't seem to get 2.6.24-rc1 to build: > > ... > LD .tmp_vmlinux1 > arch/x86/kernel/built-in.o: In function `smp_send_nmi_allbutself': > /usr/projects/linux/linux-2.6/arch/x86/kernel/crash.c:85: undefined reference > to `genapic' > make: *** [.tmp_vmlinux1] Error 1 > > Has anyone else seen this? > > - Ted Hi Ted, The patch for this build issue is available at http://lkml.org/lkml/2007/10/24/128. -- Thanks & Regards, Kamalesh Babulal, Linux Technology Center, IBM, ISTL. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] Enable link power management for ata drivers
applied as the attached two patches to jgarzik/libata-dev.git#alpm
open issues:
1) need to check ata_dev_set_feature() return value in
ata_dev_set_dipm() and do something useful with it
2) as the name implies, this probably better belongs in ata_link.
3) however, the feature is tightly coupled to the host controller. in
theory PMP -might- do this, but I think its unlikely. as such I was OK
with the present arrangement.
4) there has been some discussion of software-initiated device/link
power management, but I think this should go in, in parallel with those
discussions. ALPM
* is quite self-contained
* gives a noticable power savings
I'm definitely interested in seeing somebody pursue software-initiated
link PM as well...
Jeff
commit 218f3d30e60f32394738372c594d063f8e43ee6d
Author: Jeff Garzik <[EMAIL PROTECTED]>
Date: Thu Oct 25 00:33:27 2007 -0400
[libata] Create internal helper ata_dev_set_feature()
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
drivers/ata/libata-core.c | 26 +++---
1 file changed, 11 insertions(+), 15 deletions(-)
218f3d30e60f32394738372c594d063f8e43ee6d
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 2d147b5..294eee3 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -68,7 +68,8 @@ const unsigned long sata_deb_timing_long[]= {
100, 2000, 5000 };
static unsigned int ata_dev_init_params(struct ata_device *dev,
u16 heads, u16 sectors);
static unsigned int ata_dev_set_xfermode(struct ata_device *dev);
-static unsigned int ata_dev_set_AN(struct ata_device *dev, u8 enable);
+static unsigned int ata_dev_set_feature(struct ata_device *dev,
+ u8 enable, u8 feature);
static void ata_dev_xfermask(struct ata_device *dev);
static unsigned long ata_dev_blacklisted(const struct ata_device *dev);
@@ -1799,13 +1800,7 @@ int ata_dev_read_id(struct ata_device *dev, unsigned int
*p_class,
* SET_FEATURES spin-up subcommand before it will accept
* anything other than the original IDENTIFY command.
*/
- ata_tf_init(dev, &tf);
- tf.command = ATA_CMD_SET_FEATURES;
- tf.feature = SETFEATURES_SPINUP;
- tf.protocol = ATA_PROT_NODATA;
- tf.flags |= ATA_TFLAG_ISADDR | ATA_TFLAG_DEVICE;
- err_mask = ata_exec_internal(dev, &tf, NULL,
-DMA_NONE, NULL, 0, 0);
+ err_mask = ata_dev_set_feature(dev, SETFEATURES_SPINUP, 0);
if (err_mask && id[2] != 0x738c) {
rc = -EIO;
reason = "SPINUP failed";
@@ -2075,7 +2070,8 @@ int ata_dev_configure(struct ata_device *dev)
unsigned int err_mask;
/* issue SET feature command to turn this on */
- err_mask = ata_dev_set_AN(dev, SETFEATURES_SATA_ENABLE);
+ err_mask = ata_dev_set_feature(dev,
+ SETFEATURES_SATA_ENABLE, SATA_AN);
if (err_mask)
ata_dev_printk(dev, KERN_ERR,
"failed to enable ATAPI AN "
@@ -4181,15 +4177,14 @@ static unsigned int ata_dev_set_xfermode(struct
ata_device *dev)
DPRINTK("EXIT, err_mask=%x\n", err_mask);
return err_mask;
}
-
/**
- * ata_dev_set_AN - Issue SET FEATURES - SATA FEATURES
+ * ata_dev_set_feature - Issue SET FEATURES - SATA FEATURES
* @dev: Device to which command will be sent
* @enable: Whether to enable or disable the feature
+ * @feature: The sector count represents the feature to set
*
* Issue SET FEATURES - SATA FEATURES command to device @dev
- * on port @ap with sector count set to indicate Asynchronous
- * Notification feature
+ * on port @ap with sector count
*
* LOCKING:
* PCI/etc. bus probe sem.
@@ -4197,7 +4192,8 @@ static unsigned int ata_dev_set_xfermode(struct
ata_device *dev)
* RETURNS:
* 0 on success, AC_ERR_* mask otherwise.
*/
-static unsigned int ata_dev_set_AN(struct ata_device *dev, u8 enable)
+static unsigned int ata_dev_set_feature(struct ata_device *dev, u8 enable,
+ u8 feature)
{
struct ata_taskfile tf;
unsigned int err_mask;
@@ -4210,7 +4206,7 @@ static unsigned int ata_dev_set_AN(struct ata_device
*dev, u8 enable)
tf.feature = enable;
tf.flags |= ATA_TFLAG_ISADDR | ATA_TFLAG_DEVICE;
tf.protocol = ATA_PROT_NODATA;
- tf.nsect = SATA_AN;
+ tf.nsect = feature;
err_mask = ata_exec_internal(dev, &tf, NULL, DMA_NONE, NULL, 0, 0);
commit 01fdf95f877e2a3f767248a5896e08a9e8787971
Author: Kristen Carlson Accardi <[EMAIL PROTECTED]>
Date:
Re: [git pull] lguest: paravirt boot code
On Wednesday 24 October 2007 02:10:21 Linus Torvalds wrote: > On Tue, 23 Oct 2007, Rusty Russell wrote: > > Well, with that out the way, and some scatterlist fixups, please pull > > from > > > > git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-lguest.git > > Ok. However, please include a proper diffstat. And by proper, I mean: > > git diff -M --stat --summary Thanks, that is much better. I was just happy to locate git diff in the 133 git commands on my system; finding options 4, 8 and 22 was beyond my skill. So, this time for sure! I haven't figured out how everyone does those neat committer: commits* lists, but I'm sure there's an option here somewhere... Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-lguest.git Rusty Russell - lguest: documentation update Rusty Russell - lguest: Add to maintainers file. Jeff Garzik - lguest: build fix Rusty Russell - lguest: clean up lguest_launcher.h Rusty Russell - lguest: remove unused "wake" element from struct lguest Rusty Russell - lguest: use defines from x86 headers instead of magic numbers Rusty Russell - lguest: example launcher header cleanup. Without the documentation update (which only changes comments and whitespace), the diff looks like this: Documentation/lguest/lguest.c | 23 +++ MAINTAINERS |7 +++ arch/x86/lguest/boot.c |6 +++--- drivers/lguest/lg.h |3 --- drivers/lguest/x86/core.c |2 +- include/linux/lguest_launcher.h | 18 -- 6 files changed, 26 insertions(+), 33 deletions(-) Including the documentation update, it looks scarier: Documentation/lguest/lguest.c | 178 +++- MAINTAINERS |7 ++ arch/x86/lguest/boot.c| 54 +- arch/x86/lguest/i386_head.S |8 +- drivers/lguest/core.c |5 +- drivers/lguest/hypercalls.c | 11 +- drivers/lguest/interrupts_and_traps.c | 37 ++-- drivers/lguest/lg.h |7 +- drivers/lguest/lguest_device.c| 11 ++- drivers/lguest/lguest_user.c | 23 ++-- drivers/lguest/page_tables.c | 113 + drivers/lguest/segments.c | 48 ++ drivers/lguest/x86/core.c | 122 --- drivers/lguest/x86/switcher_32.S | 71 ++ include/asm-x86/lguest_hcall.h| 16 ++-- include/linux/lguest.h|4 +- include/linux/lguest_launcher.h | 24 ++--- 17 files changed, 440 insertions(+), 299 deletions(-) Cheers, Rusty. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] napi: use non-interruptible sleep in napi_disable
Benjamin Herrenschmidt wrote:
The current napi_disable() uses msleep_interruptible() but doesn't
(and can't) exit in case there's a signal, thus ending up doing a
hot spin without a cpu_relax. Use uninterruptible sleep instead.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
include/linux/netdevice.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-work/include/linux/netdevice.h
===
--- linux-work.orig/include/linux/netdevice.h 2007-10-17 12:39:16.0
+1000
+++ linux-work/include/linux/netdevice.h2007-10-17 12:45:00.0
+1000
@@ -390,7 +390,7 @@ static inline void napi_complete(struct
static inline void napi_disable(struct napi_struct *n)
{
while (test_and_set_bit(NAPI_STATE_SCHED, &n->state))
- msleep_interruptible(1);
+ msleep(1);
}
ACK
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] [SCSI] ips: remove ips_ha members that duplicate struct pci_dev members
Andrew Morton wrote:
On Wed, 24 Oct 2007 19:48:26 -0400 (EDT) Jeff Garzik <[EMAIL PROTECTED]> wrote:
drivers/scsi/ips.c | 178
this driver seems a bit of a basket case :(
What's going on here?
scb->dcdb.cmd_attribute =
ips_command_direction[scb->scsi_cmd->cmnd[0]];
/* Allow a WRITE BUFFER Command to Have no Data */
/* This is Used by Tape Flash Utilites */
if ((scb->scsi_cmd->cmnd[0] == WRITE_BUFFER) && (scb->data_len == 0))
scb->dcdb.cmd_attribute = 0;
if (!(scb->dcdb.cmd_attribute & 0x3))
scb->dcdb.transfer_length = 0;
if (scb->data_len >= IPS_MAX_XFER) {
I hope that's just busted indentation and not a missing {} block.
The driver is one of the grotty drivers people are afraid to touch,
therefore it bitrots even faster, in a vicious cycle. You don't have to
look hard at all to find checkpatch pukeage, very real bugs, and
Pythonesque silliness.
Not having hardware I went only for changes that are provable and
obvious, really...
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: Is gcc thread-unsafe?
Hi David, [BTW. can you retain cc lists, please?] On Thursday 25 October 2007 14:29, David Schwartz wrote: > > Well that's exactly right. For threaded programs (and maybe even > > real-world non-threaded ones in general), you don't want to be > > even _reading_ global variables if you don't need to. Cache misses > > and cacheline bouncing could easily cause performance to completely > > tank in some cases while only gaining a cycle or two in > > microbenchmarks for doing these funny x86 predication things. > > For some CPUs, replacing an conditional branch with a conditional move is a > *huge* win because it cannot be mispredicted. A *conditional* store should no be a problem. However the funny trick of doing this conditional add (implemented with unconditional store), is what is going to cause breakage. On the CPUs where predicated instructions are a big win, I'd expect they should also implement a conditional store for use here. However they might be slower than an unconditional store (eg. x86's cmov), and in those cases, gcc might just do the non-conditional store. > In general, compilers should > optimize for unshared data since that's much more common in typical code. > Even for shared data, the usual case is that you are going to access the > data few times, so pulling the cache line to the CPU is essentially free > since it will happen eventually. This is not just a question of data that you were going to use anyway. gcc generates memory accesses to locations that would never be accessed Even stores. It is basically impossible to say that this is a real performance win. Even on single threaded code: consider that cache misses take the vast majority of time in many loads, which gives a little hint that maybe it's a bad idea to do this ;) > Heuristics may show that the vast majority of such constructs write anyway. > So the optimization may also be valid based on such heuristics. I'd never say the optimisation would always be useless. But it's a nasty thing to have on by default, and apparently even with no good way to supress it even if we want to. > A better question is whether it's legal for a compiler that claims to > support POSIX threads. I'm going to post on comp.programming.threads, where > the threading experts hang out. Either way, I think we really need a way to turn it off for Linux. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Sky2 Driver Issue
On Wed, 24 Oct 2007 19:06:37 +0100 "Tom Spink" <[EMAIL PROTECTED]> wrote: > On 24/10/2007, Tom Spink <[EMAIL PROTECTED]> wrote: > > Hi, > > > > A couple of kernels ago, I ran into an issue with the sky2 driver. > > Basically, I began getting repeated errors on my console of the > > following: > > > > Oct 21 16:33:39 holly kernel: sky2 :04:00.0: error interrupt > > status=0x8000 > > Oct 21 16:33:39 holly kernel: sky2 :04:00.0: error interrupt > > status=0xc000 > > > > Which eventually led to: > > Oct 21 16:33:49 holly kernel: printk: 92 messages suppressed. > > > > Here is a section of the log that may be useful: > > Oct 21 16:33:37 holly kernel: sky2 eth1: enabling interface > > Oct 21 16:33:38 holly dhclient: DHCPDISCOVER on eth1 to > > 255.255.255.255 port 67 interval 8 > > Oct 21 16:33:39 holly kernel: sky2 :04:00.0: error interrupt > > status=0x8010 > > Oct 21 16:33:39 holly kernel: sky2 eth1: Link is up at 1000 Mbps, full > > duplex, flow control both > > Oct 21 16:33:39 holly kernel: sky2 :04:00.0: error interrupt > > status=0x8000 > > Oct 21 16:33:39 holly kernel: sky2 :04:00.0: error interrupt > > status=0xc000 > > Oct 21 16:33:40 holly kernel: sky2 :04:00.0: error interrupt > > status=0x8000 > > Oct 21 16:33:40 holly kernel: sky2 :04:00.0: error interrupt > > status=0xc000 > > Oct 21 16:33:41 holly kernel: sky2 :04:00.0: error interrupt > > status=0x8000 > > Oct 21 16:33:41 holly kernel: sky2 :04:00.0: error interrupt > > status=0xc000 > > Oct 21 16:33:42 holly kernel: sky2 :04:00.0: error interrupt > > status=0x8000 > > > > These messages are appearing on all the VTs, and because they keep > > popping up, I can't reasonably use the consoles to test if the network > > driver is working. > > > > The kernel I've got going at the moment is 2.6.23-rc9 with git > > revision g804b3f9a, and it's fine. The error surfaced _sometime_ > > after this. Attached is my .config. > > > > I'll try rebooting and pinging the machine to see if the network > > driver is working, and this is just (unnecessary?) spew from the > > kernel. > > > > -- > > Regards, > > Tom Spink > > University of Edinburgh > > > > > > Hi again, > > So it seems the driver and the network card is functioning, but I'm > getting the 'error interrupt' message plastered over every console. > > I can ping and ssh into the computer, but the message is still > scrolling everything off my screens. > Your system is not supporting MMCONFIG access to allow driver to turn off PCI express error value. It looks like the hw error irq mask doesn't work as expected either. What is your kernel config? -- Stephen Hemminger <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is gcc thread-unsafe?
On Wed, 24 Oct 2007 21:29:56 -0700 "David Schwartz" <[EMAIL PROTECTED]> wrote: > > > Well that's exactly right. For threaded programs (and maybe even > > real-world non-threaded ones in general), you don't want to be > > even _reading_ global variables if you don't need to. Cache misses > > and cacheline bouncing could easily cause performance to completely > > tank in some cases while only gaining a cycle or two in > > microbenchmarks for doing these funny x86 predication things. > > For some CPUs, replacing an conditional branch with a conditional > move is a *huge* win because it cannot be mispredicted. please name one... Hint: It's not one made by either Intel or AMD in the last 4 years... > In general, > compilers should optimize for unshared data since that's much more > common in typical code. Even for shared data, the usual case is that > you are going to access the data few times, so pulling the cache line > to the CPU is essentially free since it will happen eventually. it's not about pulling it to the CPU, it's pulling it *out* of all the other cpus AS WELL. (and writing it back to memory, taking away memory bandwidth) -- If you want to reach me at my work email, use [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.24-rc1] resource_len() utility function
On Wednesday 24 October 2007, Jeff Garzik wrote: > >> Then a dev_iomap() analogue to pci_iomap() should be pretty > >> straightforward to create. > > > > Another minor nit: addressing the various resource types. > > The platform bus code has multiple lookup schemes. > > > > Calls like resource_iomap() might be more flexible, so that > > lookup schemes can stay flexible. > > I figured that, in the absence of a true, defined BAR concept, the > struct device version would simply index into the discussed array of > struct resource. That means any ordering or layout of resources should > work, presuming (the usual case) that both driver and platform agree on > the resource layout. So you'd suggest having search utilities (as with platform_bus) returning resource indices not resources? Thing is, BARs are usually well defined, but when folk glue resources together they use whatever order is convenient on that particular platform. And different platforms can have different numbers and types of resources, etc. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Is gcc thread-unsafe?
> Well that's exactly right. For threaded programs (and maybe even > real-world non-threaded ones in general), you don't want to be > even _reading_ global variables if you don't need to. Cache misses > and cacheline bouncing could easily cause performance to completely > tank in some cases while only gaining a cycle or two in > microbenchmarks for doing these funny x86 predication things. For some CPUs, replacing an conditional branch with a conditional move is a *huge* win because it cannot be mispredicted. In general, compilers should optimize for unshared data since that's much more common in typical code. Even for shared data, the usual case is that you are going to access the data few times, so pulling the cache line to the CPU is essentially free since it will happen eventually. Heuristics may show that the vast majority of such constructs write anyway. So the optimization may also be valid based on such heuristics. A better question is whether it's legal for a compiler that claims to support POSIX threads. I'm going to post on comp.programming.threads, where the threading experts hang out. A very interesting case to be sure. DS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] [SCSI] ips: remove ips_ha members that duplicate struct pci_dev members
On Wed, 24 Oct 2007 19:48:26 -0400 (EDT) Jeff Garzik <[EMAIL PROTECTED]> wrote:
> drivers/scsi/ips.c | 178
>
this driver seems a bit of a basket case :(
What's going on here?
scb->dcdb.cmd_attribute =
ips_command_direction[scb->scsi_cmd->cmnd[0]];
/* Allow a WRITE BUFFER Command to Have no Data */
/* This is Used by Tape Flash Utilites */
if ((scb->scsi_cmd->cmnd[0] == WRITE_BUFFER) && (scb->data_len == 0))
scb->dcdb.cmd_attribute = 0;
if (!(scb->dcdb.cmd_attribute & 0x3))
scb->dcdb.transfer_length = 0;
if (scb->data_len >= IPS_MAX_XFER) {
I hope that's just busted indentation and not a missing {} block.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/5] Add lock_page_killable
On Thursday 25 October 2007 14:11, Andrew Morton wrote: > On Wed, 24 Oct 2007 08:24:57 -0400 Matthew Wilcox <[EMAIL PROTECTED]> wrote: > > and associated infrastructure such as sync_page_killable and > > fatal_signal_pending. Use lock_page_killable in > > do_generic_mapping_read() to allow us to kill `cat' of a file on an > > NFS-mounted filesystem. > > whoa, big change. > > What exactly are the semantics here? If the process has actually been > killed (ie: we know that userspace won't be running again) then we break > out of a lock_page() and allow the process to exit? ie: it's basically > invisible to userspace? The actual conversions should also be relatively useful groundwork if we ever want to make more things become generally interruptible. > If so, it sounds OK. I guess. We're still screwed if the process is doing > a synchronous write and lots of other scenarios. I don't think it will matter in too many situations. If the process is doing a synchronous write, nothing is guaranteed until the syscall returns success... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Use BOOTMEM_EXCLUSIVE for kdump
On Wed, Oct 24, 2007 at 09:05:33PM -0700, Andrew Morton wrote: > On Wed, 24 Oct 2007 18:37:35 +0200 Bernhard Walle <[EMAIL PROTECTED]> wrote: > > This patch uses the BOOTMEM_EXCLUSIVE, introduced in the previous patch, > > to avoid conflicts while reserving the memory for the kdump carpture kernel > > (crashkernel=). > > > > Signed-off-by: Bernhard Walle <[EMAIL PROTECTED]> > > > > --- > > arch/sh/kernel/setup.c | 29 ++--- > > arch/x86/kernel/setup_32.c | 28 ++-- > > arch/x86/kernel/setup_64.c | 35 +-- > > ia64 and powerpc support crash dump too? > Not via a reserved bootmem area at least, which is what these patches touch. Acked-by: Paul Mundt <[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/
QUESTION: How to fix race between .suspend routine and watchdog timer
Hi, Recently, trying to fix saa7134 suspend/resume problems I found that there is a race between IRQ handler and .suspend , and that I cant let driver access the device while its in D3 since it can lock up some systems. Now I am looking to fix those issues in two drivers that have my .suspend/.resume routines. the saa7134 capture chip and dmfe, the davicom network driver. Looking through the dmfe code, I noticed yet another possible race. A race between the .suspend, and a timer that serves both as a watchdog, and link state detector. Again I need to prevent it from running during the suspend/resume, but how? I can use del_timer in .suspend, and mod_timer in .resume, but that doesn't protect against race with already running timer. I can use del_timer_sync, but it states that it is useless if timer re-enables itself, and I agree with that. In dmfe case the timer does re-enable itself. I can put checks in the timer for ->insuspend, and don't re enable it if set, but that opens a new can of worms with memory barriers, etc... So please tell me how properly to do that. By the way, this problem, together with synchronize_irq it very generic, since most drivers have and irq handler, and a timeout timer. Best regards, Maxim Levitsky - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 0/3] MBCS: Convert semaphores to the mutex API
On Wed, 24 Oct 2007 19:08:58 +0200 [EMAIL PROTECTED] wrote: > MBCS: Convert the semaphores algolock, dmareadlock and dmawritelock to the > mutex API Thanks. Has this actually been runtime-tested? btw, your patches are in `patch -p2' form: --- kernel.orig/linux-2.6/drivers/char/mbcs.c +++ kernel/linux-2.6/drivers/char/mbcs.c should have been in `patch -p1' form: --- linux-2.6/drivers/char/mbcs.c +++ linux-2.6/drivers/char/mbcs.c I'd suggest that you grab and learn http://savannah.nongnu.org/projects/quilt/ - it takes care of all these things for 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/5] Add lock_page_killable
On Wed, 24 Oct 2007 08:24:57 -0400 Matthew Wilcox <[EMAIL PROTECTED]> wrote: > and associated infrastructure such as sync_page_killable and > fatal_signal_pending. Use lock_page_killable in do_generic_mapping_read() > to allow us to kill `cat' of a file on an NFS-mounted filesystem. whoa, big change. What exactly are the semantics here? If the process has actually been killed (ie: we know that userspace won't be running again) then we break out of a lock_page() and allow the process to exit? ie: it's basically invisible to userspace? If so, it sounds OK. I guess. We're still screwed if the process is doing a synchronous write and lots of other scenarios. How well has this been tested? Have the NFS guys had a think about it? Why does it return -EIO from read() and not -EINTR? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: How to debug complete kernel lock-ups
On Wed, Oct 24, 2007 at 11:17:40AM +0200, John Sigler wrote: ... > I've tested with a vanilla 2.6.22.10 kernel (no PREEMPT_RT patch). > That system also locks up and remains completely unresponsive (I can't open > new ssh sessions, the system won't answer ICMP echo requests). > > How do driver writers deal with complete kernel hangs? Use different HW. Both IA64 and PARISC gives useful diagnostics when the machine has a hard crash (MCA or HPMC respectively). I'll bet PPC does too on the POWER machines. Maybe a newer x86 machine can provide some MCE data as well? Otherwise it's what gregkh said...not the "we slowly go crazy" part. :) Well, sometimes. :) BTW, getting PCI bus traces would be quite helpful in this case. It'll give you clear data as to whether the devices are being programmed as expected (also to rule out chipset/Host bus controller issues) and whether they are responding as expected (maybe something else dies when they do). hth, grant hth, grant - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Bugme-new] [Bug 9217] New: CONFIG_CMDLINE doesn't pass to kernel
Andrew Morton wrote: Something broke CONFIG_CMDLINE of ARM (at least) between 2.6.22 and 2.6.23. I don't know whether it was an ARM patch one of those kernel-wide changes. We have futzed with the command-line parsing a bit recently, but the 2.6.23 changelog doesn't suggest anything obvious. What does the affected system's bootloader pass in r2? If it's nonzero, ARM's 2.6.23 may interpret it as being an ATAGS pointer. And when that happens, the system prefers the ATAGS over CONFIG_CMDLINE. There's sanity checking in __vet_atags, but maybe it isn't enough. Other than that, I can't see anything yet. b.g. -- Bill Gatliff [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: Is gcc thread-unsafe?
On Thursday 25 October 2007 13:46, Arjan van de Ven wrote: > On Thu, 25 Oct 2007 13:24:49 +1000 > > Nick Piggin <[EMAIL PROTECTED]> wrote: > > Hi, > > > > Andi spotted this exchange on the gcc list. I don't think he's > > brought it up here yet, but it worries me enough that I'd like > > to discuss it. > > > > Starts here > > http://gcc.gnu.org/ml/gcc/2007-10/msg00266.html > > > > Concrete example here > > http://gcc.gnu.org/ml/gcc/2007-10/msg00275.html > > > > Basically, what the gcc developers are saying is that gcc is > > free to load and store to any memory location, so long as it > > behaves as if the instructions were executed in sequence. > > this optimization btw is a serious mis-optimization, it makes memory > more dirty and causes cachelines to become unshared I'm sure it > works great on microbenchmarks but it sucks bigtime for anything real Well that's exactly right. For threaded programs (and maybe even real-world non-threaded ones in general), you don't want to be even _reading_ global variables if you don't need to. Cache misses and cacheline bouncing could easily cause performance to completely tank in some cases while only gaining a cycle or two in microbenchmarks for doing these funny x86 predication things. I'm not sure about ia64 -- I _hope_ that for most of their predication stuff, they also predicate the stores, rather than just store unconditionally and rely on the source operand not changing in the case they didn't intend the memory to change. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Use BOOTMEM_EXCLUSIVE for kdump
On Wed, 24 Oct 2007 18:37:35 +0200 Bernhard Walle <[EMAIL PROTECTED]> wrote: > This patch uses the BOOTMEM_EXCLUSIVE, introduced in the previous patch, > to avoid conflicts while reserving the memory for the kdump carpture kernel > (crashkernel=). > > > Signed-off-by: Bernhard Walle <[EMAIL PROTECTED]> > > --- > arch/sh/kernel/setup.c | 29 ++--- > arch/x86/kernel/setup_32.c | 28 ++-- > arch/x86/kernel/setup_64.c | 35 +-- ia64 and powerpc support crash dump too? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] TASK_KILLABLE
On Friday 19 October 2007 08:25, Matthew Wilcox wrote: > This series of patches introduces the facility to deliver only fatal > signals to tasks which are otherwise waiting uninterruptibly. This is pretty nice I think. It also is a significant piece of infrastructure required to fix some of the main oom kill deadlocks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Make wait_on_retry_sync_kiocb killable
On Friday 19 October 2007 08:26, Matthew Wilcox wrote:
> Use TASK_KILLABLE to allow wait_on_retry_sync_kiocb to return -EINTR.
> All callers then check the return value and break out of their loops.
>
> Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
> ---
> fs/read_write.c | 17 -
> 1 files changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/fs/read_write.c b/fs/read_write.c
> index 124693e..3196a3b 100644
> --- a/fs/read_write.c
> +++ b/fs/read_write.c
> @@ -218,14 +218,15 @@ Einval:
> return -EINVAL;
> }
>
> -static void wait_on_retry_sync_kiocb(struct kiocb *iocb)
> +static int wait_on_retry_sync_kiocb(struct kiocb *iocb)
> {
> - set_current_state(TASK_UNINTERRUPTIBLE);
> + set_current_state(TASK_KILLABLE);
> if (!kiocbIsKicked(iocb))
> schedule();
> else
> kiocbClearKicked(iocb);
> __set_current_state(TASK_RUNNING);
> + return fatal_signal_pending(current) ? -EINTR : 0;
Although the EINTR never gets to userspace anyway, is there a good
reason why the last patch for do_generic_mapping_read doesn't pass
back -EINTR?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] napi: use non-interruptible sleep in napi_disable
The current napi_disable() uses msleep_interruptible() but doesn't
(and can't) exit in case there's a signal, thus ending up doing a
hot spin without a cpu_relax. Use uninterruptible sleep instead.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
include/linux/netdevice.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-work/include/linux/netdevice.h
===
--- linux-work.orig/include/linux/netdevice.h 2007-10-17 12:39:16.0
+1000
+++ linux-work/include/linux/netdevice.h2007-10-17 12:45:00.0
+1000
@@ -390,7 +390,7 @@ static inline void napi_complete(struct
static inline void napi_disable(struct napi_struct *n)
{
while (test_and_set_bit(NAPI_STATE_SCHED, &n->state))
- msleep_interruptible(1);
+ msleep(1);
}
/**
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] Detect hwmon and i2c bus drivers interfering with ACPI Operation Region resources
On Wed, 24 Oct 2007 16:31:59 +0200 Thomas Renninger <[EMAIL PROTECTED]> wrote: > it seems Len's test tree and Linus tree diverged a bit, at least with > this patch set things do not apply cleanly. > > Therefore I post these for discussion whether and in which kernel tree > they should end up before doing work for nothing. > If they are still a candidate for 2.6.24 (rather unintrusive), pls tell > me whether and when I should base them against Len's test/release branch > or whatever other tree. > If not, it would be great if they can be included into the -mm tree and > I can rebase them against this one. I staged the three acpi patches against Len's tree and I staged the hwmon patch against Mark's tree and I staged the I2C patch against Jean's tree. This means that if/when the ACPI patches have gone me->Len->Linus, I can send the I2C patch to Jean and the hwmon patch to Mark and we're all good. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/5] Use macros instead of TASK_ flags
On Friday 19 October 2007 08:25, Matthew Wilcox wrote:
> Abstracting away direct uses of TASK_ flags allows us to change the
> definitions of the task flags more easily.
>
> Also restructure do_wait() a little
>
> Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
> ---
> arch/ia64/kernel/perfmon.c |4 +-
> fs/proc/array.c|9 +---
> fs/proc/base.c |2 +-
> include/linux/sched.h | 15 +++
> include/linux/wait.h | 11 +++--
> kernel/exit.c | 90
> +++ kernel/power/process.c |
> 7 +--
> kernel/ptrace.c|8 ++--
> kernel/sched.c | 15 +++
> kernel/signal.c|6 +-
> kernel/wait.c |2 +-
> 11 files changed, 83 insertions(+), 86 deletions(-)
>
> diff --git a/arch/ia64/kernel/perfmon.c b/arch/ia64/kernel/perfmon.c
> index f55fa07..6b0a6cf 100644
> --- a/arch/ia64/kernel/perfmon.c
> +++ b/arch/ia64/kernel/perfmon.c
> @@ -2630,7 +2630,7 @@ pfm_task_incompatible(pfm_context_t *ctx, struct
> task_struct *task) */
> if (task == current) return 0;
>
> - if ((task->state != TASK_STOPPED) && (task->state != TASK_TRACED)) {
> + if (!is_task_stopped_or_traced(task)) {
> DPRINT(("cannot attach to non-stopped task [%d] state=%ld\n",
> task->pid,
> task->state)); return -EBUSY;
> }
> @@ -4790,7 +4790,7 @@ recheck:
>* the task must be stopped.
>*/
> if (PFM_CMD_STOPPED(cmd)) {
> - if ((task->state != TASK_STOPPED) && (task->state !=
> TASK_TRACED)) {
> + if (!is_task_stopped_or_traced(task)) {
> DPRINT(("[%d] task not in stopped state\n", task->pid));
> return -EBUSY;
> }
> diff --git a/fs/proc/array.c b/fs/proc/array.c
> index 27b59f5..8939bf0 100644
> --- a/fs/proc/array.c
> +++ b/fs/proc/array.c
> @@ -140,13 +140,8 @@ static const char *task_state_array[] = {
>
> static inline const char *get_task_state(struct task_struct *tsk)
> {
> - unsigned int state = (tsk->state & (TASK_RUNNING |
> - TASK_INTERRUPTIBLE |
> - TASK_UNINTERRUPTIBLE |
> - TASK_STOPPED |
> - TASK_TRACED)) |
> - (tsk->exit_state & (EXIT_ZOMBIE |
> - EXIT_DEAD));
> + unsigned int state = (tsk->state & TASK_REPORT) |
> + (tsk->exit_state & (EXIT_ZOMBIE | EXIT_DEAD));
> const char **p = &task_state_array[0];
>
> while (state) {
> diff --git a/fs/proc/base.c b/fs/proc/base.c
> index 4fe74d1..e7e1815 100644
> --- a/fs/proc/base.c
> +++ b/fs/proc/base.c
> @@ -196,7 +196,7 @@ static int proc_root_link(struct inode *inode, struct
> dentry **dentry, struct vf (task == current || \
> (task->parent == current && \
> (task->ptrace & PT_PTRACED) && \
> - (task->state == TASK_STOPPED || task->state == TASK_TRACED) && \
> + (is_task_stopped_or_traced(task)) && \
>security_ptrace(current,task) == 0))
>
> static int proc_pid_cmdline(struct task_struct *task, char * buffer)
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index c204ab0..5ef5253 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -177,6 +177,21 @@ print_cfs_rq(struct seq_file *m, int cpu, struct
> cfs_rq *cfs_rq) /* in tsk->state again */
> #define TASK_DEAD64
>
> +/* Convenience macros for the sake of wake_up */
> +#define TASK_NORMAL (TASK_INTERRUPTIBLE | TASK_UNINTERRUPTIBLE)
> +#define TASK_ALL (TASK_NORMAL | TASK_STOPPED | TASK_TRACED)
> +
> +/* get_task_state() */
> +#define TASK_REPORT (TASK_RUNNING | TASK_INTERRUPTIBLE | \
> + TASK_UNINTERRUPTIBLE | TASK_STOPPED | \
> + TASK_TRACED)
I think it would be nicer if you made it explicit in the name that
these are not individual flags. Maybe it doesn't matter though...
Also, TASK_NORMAL / TASK_ALL aren't very good names. TASK_SLEEP_NORMAL
TASK_SLEEP_ALL might be a bit more helpful?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [Fwd: [PATCH 3/5] Export acpi_check_resource_conflict]
On Wed, 24 Oct 2007 16:33:07 +0200 Thomas Renninger <[EMAIL PROTECTED]> wrote: > From: Thomas Renninger <[EMAIL PROTECTED]> > To: linux-acpi <[EMAIL PROTECTED]> > Cc: linux-kernel , Len Brown <[EMAIL > PROTECTED]>, Andrew Morton <[EMAIL PROTECTED]>, Jean Delvare <[EMAIL > PROTECTED]> > Reply-To: [EMAIL PROTECTED] > Subject: [Fwd: [PATCH 3/5] Export acpi_check_resource_conflict] > Date: Wed, 24 Oct 2007 16:33:07 +0200 > Organization: Novell/SUSE > X-Mailer: Evolution 2.8.2 > > Export acpi_check_resource_conflict(), sometimes drivers already have > a struct resource at hand so no need to use the wrappers to build a new > one. > > Signed-off-by: Jean Delvare <[EMAIL PROTECTED]> > --- The attributions on this are all mucked up. I _think_ it was written by Jean, in which case the changlog should have had From:him right at the start to indicate this. And as you were in the delivery path, it should have had your signoff. I'll make those changes - please let me know if I misguessed. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)
On Oct 24, 2007, at 17:37:04, Serge E. Hallyn wrote: The scariest thing to consider is programs which don't appropriately handle failure. So I don't know, maybe the system runs a remote logger to which the multiadm policy gives some extra privs, but now the portac module prevents it from sending its data. And maybe, since the authors never saw this failure as possible, the program happens to dump sensitive data in a public readable place. I *could* be more vague but it'd be tough :) But you get the idea. Well, there *was* that problem with sendmail where it did not properly check the result of setuid() and just assumed it had succeeded. So instead of running as "smtpd" it was running as "root". Not a happy memory. Cheers, Kyle Moffett - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Is gcc thread-unsafe?
On Thu, 25 Oct 2007 13:24:49 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote: > Hi, > > Andi spotted this exchange on the gcc list. I don't think he's > brought it up here yet, but it worries me enough that I'd like > to discuss it. > > Starts here > http://gcc.gnu.org/ml/gcc/2007-10/msg00266.html > > Concrete example here > http://gcc.gnu.org/ml/gcc/2007-10/msg00275.html > > Basically, what the gcc developers are saying is that gcc is > free to load and store to any memory location, so long as it > behaves as if the instructions were executed in sequence. > this optimization btw is a serious mis-optimization, it makes memory more dirty and causes cachelines to become unshared I'm sure it works great on microbenchmarks but it sucks bigtime for anything real - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.24-rc1] resource_len() utility function
David Brownell wrote: On Wednesday 24 October 2007, Jeff Garzik wrote: With regards to resource reservation... IMO we should mimic struct pci_dev and add struct resource[] to struct device. One minor difficulty: PCI has a limit on the number of BARs, but other busses don't. It'd be better as a "struct resource *". Just like we have pci_request_regions(), we should also be able to easily to a dev_request_regions(). the implementation should be very close to pci_request_region() and pci_release_region(). Wouldn't it be nicer to have PCI use those dev_*() calls? Ideally pci_request_region() wraps dev_request_region()... Absolutely... Then a dev_iomap() analogue to pci_iomap() should be pretty straightforward to create. Another minor nit: addressing the various resource types. The platform bus code has multiple lookup schemes. Calls like resource_iomap() might be more flexible, so that lookup schemes can stay flexible. I figured that, in the absence of a true, defined BAR concept, the struct device version would simply index into the discussed array of struct resource. That means any ordering or layout of resources should work, presuming (the usual case) that both driver and platform agree on the resource layout. 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 1/2] [NetLabel] Introduce a new kernel configuration API for NetLabel - Version 9 (2.6.24-rc1) Smack: Simplified Mandatory Access Control Kernel
From: Paul Moore <[EMAIL PROTECTED]>
Add a new set of configuration functions to the NetLabel/LSM API so that
LSMs can perform their own configuration of the NetLabel subsystem without
relying on assistance from userspace.
Signed-off-by: Paul Moore <[EMAIL PROTECTED]>
---
include/net/netlabel.h | 47 --
net/ipv4/cipso_ipv4.c |4 -
net/netlabel/netlabel_cipso_v4.c |2
net/netlabel/netlabel_cipso_v4.h |3 +
net/netlabel/netlabel_domainhash.h |1
net/netlabel/netlabel_kapi.c | 177
6 files changed, 225 insertions(+), 9 deletions(-)
diff --git a/include/net/netlabel.h b/include/net/netlabel.h
index 2e5b2f6..facaf68 100644
--- a/include/net/netlabel.h
+++ b/include/net/netlabel.h
@@ -36,6 +36,8 @@
#include
#include
+struct cipso_v4_doi;
+
/*
* NetLabel - A management interface for maintaining network packet label
*mapping tables for explicit packet labling protocols.
@@ -99,12 +101,6 @@ struct netlbl_audit {
uid_t loginuid;
};
-/* Domain mapping definition struct */
-struct netlbl_dom_map;
-
-/* Domain mapping operations */
-int netlbl_domhsh_remove(const char *domain, struct netlbl_audit *audit_info);
-
/* LSM security attributes */
struct netlbl_lsm_cache {
atomic_t refcount;
@@ -285,6 +281,19 @@ static inline void netlbl_secattr_free(struct
netlbl_lsm_secattr *secattr)
#ifdef CONFIG_NETLABEL
/*
+ * LSM configuration operations
+ */
+int netlbl_cfg_map_del(const char *domain, struct netlbl_audit *audit_info);
+int netlbl_cfg_unlbl_add_map(const char *domain,
+struct netlbl_audit *audit_info);
+int netlbl_cfg_cipsov4_add(struct cipso_v4_doi *doi_def,
+ struct netlbl_audit *audit_info);
+int netlbl_cfg_cipsov4_add_map(struct cipso_v4_doi *doi_def,
+ const char *domain,
+ struct netlbl_audit *audit_info);
+int netlbl_cfg_cipsov4_del(u32 doi, struct netlbl_audit *audit_info);
+
+/*
* LSM security attribute operations
*/
int netlbl_secattr_catmap_walk(struct netlbl_lsm_secattr_catmap *catmap,
@@ -318,6 +327,32 @@ void netlbl_cache_invalidate(void);
int netlbl_cache_add(const struct sk_buff *skb,
const struct netlbl_lsm_secattr *secattr);
#else
+static inline int netlbl_cfg_map_del(const char *domain,
+struct netlbl_audit *audit_info)
+{
+ return -ENOSYS;
+}
+static inline int netlbl_cfg_unlbl_add_map(const char *domain,
+ struct netlbl_audit *audit_info)
+{
+ return -ENOSYS;
+}
+static inline int netlbl_cfg_cipsov4_add(struct cipso_v4_doi *doi_def,
+struct netlbl_audit *audit_info)
+{
+ return -ENOSYS;
+}
+static inline int netlbl_cfg_cipsov4_add_map(struct cipso_v4_doi *doi_def,
+const char *domain,
+struct netlbl_audit *audit_info)
+{
+ return -ENOSYS;
+}
+static inline int netlbl_cfg_cipsov4_del(u32 doi,
+struct netlbl_audit *audit_info)
+{
+ return -ENOSYS;
+}
static inline int netlbl_secattr_catmap_walk(
struct netlbl_lsm_secattr_catmap *catmap,
u32 offset)
diff --git a/net/ipv4/cipso_ipv4.c b/net/ipv4/cipso_ipv4.c
index ab56a05..714461c 100644
--- a/net/ipv4/cipso_ipv4.c
+++ b/net/ipv4/cipso_ipv4.c
@@ -557,8 +557,8 @@ int cipso_v4_doi_remove(u32 doi,
spin_unlock(&cipso_v4_doi_list_lock);
list_for_each_entry_rcu(dom_iter, &doi_def->dom_list, list)
if (dom_iter->valid)
- netlbl_domhsh_remove(dom_iter->domain,
-audit_info);
+ netlbl_cfg_map_del(dom_iter->domain,
+ audit_info);
cipso_v4_cache_invalidate();
rcu_read_unlock();
diff --git a/net/netlabel/netlabel_cipso_v4.c b/net/netlabel/netlabel_cipso_v4.c
index c060e3f..07f7fd4 100644
--- a/net/netlabel/netlabel_cipso_v4.c
+++ b/net/netlabel/netlabel_cipso_v4.c
@@ -89,7 +89,7 @@ static const struct nla_policy
netlbl_cipsov4_genl_policy[NLBL_CIPSOV4_A_MAX + 1
* safely.
*
*/
-static void netlbl_cipsov4_doi_free(struct rcu_head *entry)
+void netlbl_cipsov4_doi_free(struct rcu_head *entry)
{
struct cipso_v4_doi *ptr;
diff --git a/net/netlabel/netlabel_cipso_v4.h b/net/netlabel/netlabel_cipso_v4.h
index f03cf9b..220cb9d 100644
--- a/net/netlabel/netlabel_cipso_v4.h
+++ b/net/netlabel/netlabel_cipso_v4.h
@@ -163,4 +163,7 @@ enum {
/* NetLabel protocol functions */
int netlbl_cipsov4_genl_init(void);
+/* Free the memory associated with a CIPSOv4 DOI definition */
+void
[PATCH 0/2] Version 9 (2.6.24-rc1) Smack: Simplified Mandatory Access Control Kernel
The Smack patch and Paul Moore's netlabel API patch, together for 2.6.24-rc1. Paul's changes are identical to the previous posting, but it's been a while so they're here again. The sole intent of change has been to address locking and/or list processing issues. Please don't hesitate to point out any problems that you might see or suggest alternatives where things might not be to your liking. This version is aimed at 2.6.24, and has been tested against 2.6.24-rc1. Thank you again. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Make wait_on_retry_sync_kiocb killable
On Wed, 24 Oct 2007 08:24:58 -0400 Matthew Wilcox <[EMAIL PROTECTED]> wrote:
> Use TASK_KILLABLE to allow wait_on_retry_sync_kiocb to return -EINTR.
> All callers then check the return value and break out of their loops.
>
Let's cc the AIO list on AIO patches, please.
> ---
> fs/read_write.c | 17 -
> 1 files changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/fs/read_write.c b/fs/read_write.c
> index 124693e..3196a3b 100644
> --- a/fs/read_write.c
> +++ b/fs/read_write.c
> @@ -218,14 +218,15 @@ Einval:
> return -EINVAL;
> }
>
> -static void wait_on_retry_sync_kiocb(struct kiocb *iocb)
> +static int wait_on_retry_sync_kiocb(struct kiocb *iocb)
> {
> - set_current_state(TASK_UNINTERRUPTIBLE);
> + set_current_state(TASK_KILLABLE);
> if (!kiocbIsKicked(iocb))
> schedule();
> else
> kiocbClearKicked(iocb);
> __set_current_state(TASK_RUNNING);
> + return fatal_signal_pending(current) ? -EINTR : 0;
> }
>
> ssize_t do_sync_read(struct file *filp, char __user *buf, size_t len, loff_t
> *ppos)
> @@ -242,7 +243,9 @@ ssize_t do_sync_read(struct file *filp, char __user *buf,
> size_t len, loff_t *pp
> ret = filp->f_op->aio_read(&kiocb, &iov, 1, kiocb.ki_pos);
> if (ret != -EIOCBRETRY)
> break;
> - wait_on_retry_sync_kiocb(&kiocb);
> + ret = wait_on_retry_sync_kiocb(&kiocb);
> + if (ret)
> + break;
> }
>
> if (-EIOCBQUEUED == ret)
> @@ -300,7 +303,9 @@ ssize_t do_sync_write(struct file *filp, const char
> __user *buf, size_t len, lof
> ret = filp->f_op->aio_write(&kiocb, &iov, 1, kiocb.ki_pos);
> if (ret != -EIOCBRETRY)
> break;
> - wait_on_retry_sync_kiocb(&kiocb);
> + ret = wait_on_retry_sync_kiocb(&kiocb);
> + if (ret)
> + break;
> }
>
> if (-EIOCBQUEUED == ret)
> @@ -466,7 +471,9 @@ ssize_t do_sync_readv_writev(struct file *filp, const
> struct iovec *iov,
> ret = fn(&kiocb, iov, nr_segs, kiocb.ki_pos);
> if (ret != -EIOCBRETRY)
> break;
> - wait_on_retry_sync_kiocb(&kiocb);
> + ret = wait_on_retry_sync_kiocb(&kiocb);
> + if (ret)
> + break;
> }
>
> if (ret == -EIOCBQUEUED)
> --
> 1.4.4.2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Quad core CPU detected but shows as single core in 2.6.23.1
Zurk Tech wrote: Hi guys, I have a tyan s3992 h2000 with single barcelona amd quad core cpu (the other cpu socket is empty). cat /proc/cpuinfo shows amd quad core processor but core : 1ive compiled the kernel from scratch with smp and amd64 + the numa stuff. i also tried debian etchs amd64 smp kernel and same result. is amd barcelona quad core cpu not yet supported or is it something else ? Thanks for any insight. im completely stumped. ive dealt with mutliprocessing machines before and have a couple of dual cores which are fine with the exact same kernel configs. my amd tk-53 x2 turions show 2 cores in cpuinfo The bootstrap protocol for Barcelona is a little different from older Opterons, so an older BIOS that doesn't know the new protocol won't be able to bring up any CPU other than the bootstrap processor. My wild guess is that this is what's happening and a BIOS update will fix it, but as Arjan said, please post dmesg when reporting bugs like this. -- 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/
Is gcc thread-unsafe?
Hi, Andi spotted this exchange on the gcc list. I don't think he's brought it up here yet, but it worries me enough that I'd like to discuss it. Starts here http://gcc.gnu.org/ml/gcc/2007-10/msg00266.html Concrete example here http://gcc.gnu.org/ml/gcc/2007-10/msg00275.html Basically, what the gcc developers are saying is that gcc is free to load and store to any memory location, so long as it behaves as if the instructions were executed in sequence. I guess that dynamically allocated memory and computed pointers are more difficult for gcc to do anything unsafe with, because it is harder to tell if a given function has deallocated the memory. However even that could theoretically happen in future if the compiler can work out the address comes from a global variable or is not changed intermediately. Linux makes extensive use of both trylocks and interruptible locks (ie. which automatically result in divergant code paths, one of which holds the lock, the other doesn't). However there are also other code paths which will either hold a particular lock or will not hold it, depending on context or some flags etc. barrier() doesn't help. For x86, obviously the example above shows it can be miscompiled, but it is probably relatively hard to make it happen for a non trivial sequence. For an ISA with lots of predicated instructions like ia64, it would seem to be much more likely. But of course we don't want even the possibility of failures. The gcc guys seem to be saying to mark everything volatile that could be touched in a critical section. This is insane for Linux. Any thoughts? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/5] Use macros instead of TASK_ flags
On Wed, 24 Oct 2007 08:24:55 -0400 Matthew Wilcox <[EMAIL PROTECTED]> wrote: > Abstracting away direct uses of TASK_ flags allows us to change the > definitions of the task flags more easily. > > Also restructure do_wait() a little umm, spose so. There's an excellent chance that a millionth of our monkeys will come along and wreck this diff during the next two months. In which case I might end up dropping bits of it, we'll see. It would be much better if this patch was a series of patches: one to add the new infrastructure and one-per-subsystem to introduce users of the infrastructure. That way I wouldn't have to go mucking around in the internals of the patch and remembering to tell you when I tossed bits of it out, and which bits those were. This shouldn't come as news to an old-timer :( - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: USB: FIx locks and urb->status in adutux
BTW, the patch in my previous message had one buglet - an extra
remove_wait_queue. It was in an error case though, so it should be
ok to test. But just in case, here's a fixed one.
-- Pete
diff --git a/drivers/usb/misc/adutux.c b/drivers/usb/misc/adutux.c
index c567aa7..6914c0b 100644
--- a/drivers/usb/misc/adutux.c
+++ b/drivers/usb/misc/adutux.c
@@ -79,12 +79,22 @@ MODULE_DEVICE_TABLE(usb, device_table);
#define COMMAND_TIMEOUT(2*HZ) /* 60 second timeout for a command */
+/*
+ * The locking scheme is a vanilla 3-lock:
+ * adu_device.buflock: A spinlock, covers what IRQs touch.
+ * adutux_mutex: A Static lock to cover open_count. It would also cover
+ * any globals, but we don't have them in 2.6.
+ * adu_device.mtx: A mutex to hold across sleepers like copy_from_user.
+ * It covers all of adu_device, except the open_count
+ * and what .buflock covers.
+ */
+
/* Structure to hold all of our device specific stuff */
struct adu_device {
- struct mutexmtx; /* locks this structure */
+ struct mutexmtx;
struct usb_device* udev; /* save off the usb device pointer */
struct usb_interface* interface;
- unsigned char minor; /* the starting minor number for this
device */
+ unsigned intminor; /* the starting minor number for this
device */
charserial_number[8];
int open_count; /* number of times this port has
been opened */
@@ -107,8 +117,11 @@ struct adu_device {
char* interrupt_out_buffer;
struct usb_endpoint_descriptor* interrupt_out_endpoint;
struct urb* interrupt_out_urb;
+ int out_urb_finished;
};
+static DEFINE_MUTEX(adutux_mutex);
+
static struct usb_driver adu_driver;
static void adu_debug_data(int level, const char *function, int size,
@@ -132,27 +145,31 @@ static void adu_debug_data(int level, const char
*function, int size,
*/
static void adu_abort_transfers(struct adu_device *dev)
{
- dbg(2," %s : enter", __FUNCTION__);
+ unsigned long flags;
- if (dev == NULL) {
- dbg(1," %s : dev is null", __FUNCTION__);
- goto exit;
- }
+ dbg(2," %s : enter", __FUNCTION__);
if (dev->udev == NULL) {
dbg(1," %s : udev is null", __FUNCTION__);
goto exit;
}
- dbg(2," %s : udev state %d", __FUNCTION__, dev->udev->state);
- if (dev->udev->state == USB_STATE_NOTATTACHED) {
- dbg(1," %s : udev is not attached", __FUNCTION__);
- goto exit;
- }
-
/* shutdown transfer */
- usb_unlink_urb(dev->interrupt_in_urb);
- usb_unlink_urb(dev->interrupt_out_urb);
+
+ /* XXX Anchor these instead */
+ spin_lock_irqsave(&dev->buflock, flags);
+ if (!dev->read_urb_finished) {
+ spin_unlock_irqrestore(&dev->buflock, flags);
+ usb_kill_urb(dev->interrupt_in_urb);
+ } else
+ spin_unlock_irqrestore(&dev->buflock, flags);
+
+ spin_lock_irqsave(&dev->buflock, flags);
+ if (!dev->out_urb_finished) {
+ spin_unlock_irqrestore(&dev->buflock, flags);
+ usb_kill_urb(dev->interrupt_out_urb);
+ } else
+ spin_unlock_irqrestore(&dev->buflock, flags);
exit:
dbg(2," %s : leave", __FUNCTION__);
@@ -162,8 +179,6 @@ static void adu_delete(struct adu_device *dev)
{
dbg(2, "%s enter", __FUNCTION__);
- adu_abort_transfers(dev);
-
/* free data structures */
usb_free_urb(dev->interrupt_in_urb);
usb_free_urb(dev->interrupt_out_urb);
@@ -239,7 +254,10 @@ static void adu_interrupt_out_callback(struct urb *urb)
goto exit;
}
- wake_up_interruptible(&dev->write_wait);
+ spin_lock(&dev->buflock);
+ dev->out_urb_finished = 1;
+ wake_up(&dev->write_wait);
+ spin_unlock(&dev->buflock);
exit:
adu_debug_data(5, __FUNCTION__, urb->actual_length,
@@ -252,12 +270,17 @@ static int adu_open(struct inode *inode, struct file
*file)
struct adu_device *dev = NULL;
struct usb_interface *interface;
int subminor;
- int retval = 0;
+ int retval;
dbg(2,"%s : enter", __FUNCTION__);
subminor = iminor(inode);
+ if ((retval = mutex_lock_interruptible(&adutux_mutex))) {
+ dbg(2, "%s : mutex lock failed", __FUNCTION__);
+ goto exit_no_lock;
+ }
+
interface = usb_find_interface(&adu_driver, subminor);
if (!interface) {
err("%s - error, can't find device for minor %d",
@@ -272,13 +295,6 @@ static int adu_open(struct inode *inode, struct file *file)
goto exit_no_device;
}
- /* lock this d
Re: [PATCH 1/4] stringbuf: A string buffer implementation
On Wed, Oct 24, 2007 at 08:07:23PM -0400, Kyle Moffett wrote:
> No, the problem is what happens when you don't have enough space
> allocated: you call "vsnprintf(s, len, format, args);" and then
> later call "vsprintf(s, format, args);" with the *SAME* "args".
> That's what's broken.
Ah, gotcha. I don't really like the va_copy idea, and I don't like the idea of
having sb_printf call sb_vprintf twice ... how about just doing away with
sb_vprintf altogether:
diff --git a/include/linux/stringbuf.h b/include/linux/stringbuf.h
index c030bc6..ae5c02f 100644
--- a/include/linux/stringbuf.h
+++ b/include/linux/stringbuf.h
@@ -57,11 +57,6 @@ static inline void sb_free(struct stringbuf *sb)
extern void sb_printf(struct stringbuf *sb, gfp_t gfp, const char *fmt, ...)
__attribute__((format(printf, 3, 4)));
-#if 0
-/* Waiting for a user to show up */
-extern void sb_vprintf(struct stringbuf *sb, gfp_t gfp, const char *fmt,
- va_list args) __attribute__((format(printf, 3, 0)));
-#endif
/*
* Convert the stringbuf to a string. It is the caller's responsibility
diff --git a/lib/stringbuf.c b/lib/stringbuf.c
index b4e59f4..691fcd1 100644
--- a/lib/stringbuf.c
+++ b/lib/stringbuf.c
@@ -22,12 +22,9 @@
#define INITIAL_SIZE 128
#define ERR_STRING "out of memory"
-/*
- * Not currently used outside this file, but separated from sb_printf
- * for when someone needs it.
- */
-static void sb_vprintf(struct stringbuf *sb, gfp_t gfp, const char *format,
va_list args)
+void sb_printf(struct stringbuf *sb, gfp_t gfp, const char *format, ...)
{
+ va_list args;
char *s;
int size, newlen;
@@ -41,7 +38,9 @@ static void sb_vprintf(struct stringbuf *sb, gfp_t gfp, const
char *format, va_l
}
s = sb->buf + sb->len;
+ va_start(args, format);
size = vsnprintf(s, sb->alloc - sb->len, format, args);
+ va_end(args);
sb->len += size;
if (likely(sb->len < sb->alloc))
@@ -61,7 +60,9 @@ static void sb_vprintf(struct stringbuf *sb, gfp_t gfp, const
char *format, va_l
/* Point to the end of the old string since we already updated ->len */
s += sb->len - size;
+ va_start(args, format);
vsprintf(s, format, args);
+ va_end(args);
return;
nomem:
@@ -70,16 +71,4 @@ static void sb_vprintf(struct stringbuf *sb, gfp_t gfp,
const char *format, va_l
sb->len = sizeof(ERR_STRING);
sb->alloc = -ENOMEM;
}
-/* When we get our first modular user, delete this comment
-EXPORT_SYMBOL(sb_vprintf);
-*/
-
-void sb_printf(struct stringbuf *sb, gfp_t gfp, const char *format, ...)
-{
- va_list args;
-
- va_start(args, format);
- sb_vprintf(sb, gfp, format, args);
- va_end(args);
-}
EXPORT_SYMBOL(sb_printf);
--
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: USB: FIx locks and urb->status in adutux
On Wed, 24 Oct 2007 17:09:47 +0300, Vitaliy Ivanov <[EMAIL PROTECTED]> wrote:
> > static void adu_abort_transfers(struct adu_device *dev)
> > {
> ...
> > + mutex_lock(&dev->mtx);
> ...
> > + mutex_unlock(&dev->mtx);
>
> > }
>
> Don't you think it's needed? You call adu_abort_transfers from adu_release
> only where it's locked by adutux_mutex.
Yes, it's not needed anymore. It's a carry-over from the time
when the old code aborted ransfers from the outside of adutux_mutex.
> /* send off the urb */
> usb_fill_int_urb(
> dev->interrupt_out_urb,
> dev->interrupt_in_endpoint->bInterval);
> Typo? Seems like that.
Looks like one. It actually is a risky thing to fix... What if the device
as broken descriptors and the driver worked only thanks to the bug above?
But let's fix it and see.
> I just tried your patch on the adutux from 2.6.24-rc1 but on my 2.6.20.7. It
> failed with the following message:
> [176200.425776] list_add corruption. next->prev should be prev (c15e6c30),
> but was . (next=c58bdf5c).
> [176200.426536] kernel BUG at lib/list_debug.c:28!
> [176200.427843] [] list_add+0xa/0xf
> [176200.427848] [] add_wait_queue+0x1f/0x2d
This is probably what Oliver caught, I did not have all removals
from wait queue where necessary.
> [176200.428593] <3>BUG: sleeping function called from invalid context at
> kernel/rwsem.c:20
This looks like a debugging-caused oops. It should go away by itself
once the above is fixed.
> I'm not sure whether it's because I'm trying it on 2.6.20.7 and not on
> 2.6.24-rc1.
> Will check it on 2.6.24-rc1 asap and let you know.
Please try attached on any of those.
Thank you,
-- Pete
diff --git a/drivers/usb/misc/adutux.c b/drivers/usb/misc/adutux.c
index c567aa7..bea6262 100644
--- a/drivers/usb/misc/adutux.c
+++ b/drivers/usb/misc/adutux.c
@@ -79,12 +79,22 @@ MODULE_DEVICE_TABLE(usb, device_table);
#define COMMAND_TIMEOUT(2*HZ) /* 60 second timeout for a command */
+/*
+ * The locking scheme is a vanilla 3-lock:
+ * adu_device.buflock: A spinlock, covers what IRQs touch.
+ * adutux_mutex: A Static lock to cover open_count. It would also cover
+ * any globals, but we don't have them in 2.6.
+ * adu_device.mtx: A mutex to hold across sleepers like copy_from_user.
+ * It covers all of adu_device, except the open_count
+ * and what .buflock covers.
+ */
+
/* Structure to hold all of our device specific stuff */
struct adu_device {
- struct mutexmtx; /* locks this structure */
+ struct mutexmtx;
struct usb_device* udev; /* save off the usb device pointer */
struct usb_interface* interface;
- unsigned char minor; /* the starting minor number for this
device */
+ unsigned intminor; /* the starting minor number for this
device */
charserial_number[8];
int open_count; /* number of times this port has
been opened */
@@ -107,8 +117,11 @@ struct adu_device {
char* interrupt_out_buffer;
struct usb_endpoint_descriptor* interrupt_out_endpoint;
struct urb* interrupt_out_urb;
+ int out_urb_finished;
};
+static DEFINE_MUTEX(adutux_mutex);
+
static struct usb_driver adu_driver;
static void adu_debug_data(int level, const char *function, int size,
@@ -132,27 +145,31 @@ static void adu_debug_data(int level, const char
*function, int size,
*/
static void adu_abort_transfers(struct adu_device *dev)
{
- dbg(2," %s : enter", __FUNCTION__);
+ unsigned long flags;
- if (dev == NULL) {
- dbg(1," %s : dev is null", __FUNCTION__);
- goto exit;
- }
+ dbg(2," %s : enter", __FUNCTION__);
if (dev->udev == NULL) {
dbg(1," %s : udev is null", __FUNCTION__);
goto exit;
}
- dbg(2," %s : udev state %d", __FUNCTION__, dev->udev->state);
- if (dev->udev->state == USB_STATE_NOTATTACHED) {
- dbg(1," %s : udev is not attached", __FUNCTION__);
- goto exit;
- }
-
/* shutdown transfer */
- usb_unlink_urb(dev->interrupt_in_urb);
- usb_unlink_urb(dev->interrupt_out_urb);
+
+ /* XXX Anchor these instead */
+ spin_lock_irqsave(&dev->buflock, flags);
+ if (!dev->read_urb_finished) {
+ spin_unlock_irqrestore(&dev->buflock, flags);
+ usb_kill_urb(dev->interrupt_in_urb);
+ } else
+ spin_unlock_irqrestore(&dev->buflock, flags);
+
+ spin_lock_irqsave(&dev->buflock, flags);
+ if (!dev->out_urb_finished) {
+ spin_unlock_irqrestore(&dev->buflock, flags);
+ usb_kill_urb(dev->interrupt_out_urb);
+ } else
+ spin_unlock_irqresto
Re: [2.6 patch] blackfin: "extern inline" -> "static inline"
On 10/24/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> Mike Frysinger wrote:
> > On 10/24/07, Jie Zhang <[EMAIL PROTECTED]> wrote:
> >> On 10/25/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> >>> "extern inline" will have different semantics with gcc 4.3.
> >>>
> >>> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
> >>>
> >>> --- a/include/asm-blackfin/string.h
> >>> +++ b/include/asm-blackfin/string.h
> >>> @@ -4,7 +4,7 @@
> >>> #ifdef __KERNEL__ /* only set these up for kernel code */
> >>>
> >>> #define __HAVE_ARCH_STRCPY
> >>> -extern inline char *strcpy(char *dest, const char *src)
> >>> +static inline char *strcpy(char *dest, const char *src)
> >>> {
> >>> char *xdest = dest;
> >>> char temp = 0;
> >> What if we compile it with gcc 4.1?
> >
> > we'll have to either use the gcc attributes to force old inline
> > behavior or use the gcc flag to force it
>
> We should probably have an extern_inline define then, assuming this is a
> function that does exist in a linkable version already -- otherwise
> "static inline" is correct.
right, we do have string versions in arch/blackfin/lib/ and we do want
the "classical" gcc behavior here with "extern static". an
extern_inline macro in compiler.h sounds good since
__attribute__((__gnu_inline__)) doesnt exist in gcc-3.4.x (the other
version that works for Blackfin other than gcc-4.1.x).
so i guess NACK this patch since we dont want "static inline" and we
dont yet support gcc-4.3 on Blackfin.
-mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Using -traditional in EXTRA_AFLAGS
Guys, is there any particular reason we're using -traditional in EXTRA_AFLAGS in Makefiles? According to http://gcc.gnu.org/onlinedocs/cpp/Traditional-macros.html#Traditional-macros, (and to my painful recent experience), it disallows the use of token pasting in pre-processor macros, which is a functionality we heavily rely upon for the rest of kernel things. I'd suggest just removing it, but obviously, there might well be people with good reasons for it to stay (The same effect of token pasting can be achieved in some ways, so if -traditional stays, that's not the greatest problem in the world... just that token pasting in asm files will diverge from the way in which we (-)traditionally do ;-) ) So, does any one have a word on that? -- Glauber de Oliveira Costa. "Free as in Freedom" http://glommer.net "The less confident you are, the more serious you have to act." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: SLUB 0:1 SLAB (OOM during massive parallel kernel builds)
On Thursday 25 October 2007 12:43, Christoph Lameter wrote: > On Thu, 25 Oct 2007, Nick Piggin wrote: > > > Ummm... all unreclaimable is set! Are you mlocking the pages in memory? > > > Or what causes this? All pages under writeback? What is the dirty ratio > > > set to? > > > > Why is SLUB behaving differently, though. > > Nore sure. Are we really sure that this does not occur using SLAB? >From the reports it seems pretty consistent. I guess it could well be something that may occur with SLAB *if the conditions are a bit different*... > > Memory efficiency wouldn't be the reason, would it? I mean, SLUB > > should be more efficient than SLAB, plus have less data lying around > > in queues. > > SLAB may have data around in queues which (if the stars align the right > way) may allow it to go longer without having to get a page from the page > allocator. But page allocs from slab isn't where the OOMs are occurring, so this seems unlikely (also, the all_unreclaimable logic now should be pretty strict, so you have to really run the machine out of memory (1GB of swap gets fully used, then his DMA32 zone is scanned 8 times without reclaiming a single page). That said, parallel kernel compiling can really change a lot in memory footprint depending on small variations in timing. So it might not be anything to worry about. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Quad core CPU detected but shows as single core in 2.6.23.1
On Wed, 24 Oct 2007 23:02:14 -0400 "Zurk Tech" <[EMAIL PROTECTED]> wrote: > Hi guys, > I have a tyan s3992 h2000 with single barcelona amd quad core cpu (the > other cpu socket is empty). cat /proc/cpuinfo shows amd quad core > processor > but core : 1ive compiled the kernel from scratch with smp and > amd64 + the numa stuff. i also tried debian etchs amd64 smp kernel and > same result. > is amd barcelona quad core cpu not yet supported or is it something > else ? Thanks for any insight. im completely stumped. ive dealt with > mutliprocessing machines before and have a couple of dual cores which > are fine with the > exact same kernel configs. my amd tk-53 x2 turions show 2 cores in > cpuinfo -Zurk- Hi, this sort of issue is usually best diagnosed when we can get to see the dmesg output... since quite often the kernel will note errors and warnings there that will give a clue of what is going on. Would you mind attaching your dmesg on the broken machine to a mail ? Greetings, Arjan van de Ven - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] blackfin: "extern inline" -> "static inline"
Mike Frysinger wrote:
On 10/24/07, Jie Zhang <[EMAIL PROTECTED]> wrote:
On 10/25/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
"extern inline" will have different semantics with gcc 4.3.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
--- a/include/asm-blackfin/string.h
+++ b/include/asm-blackfin/string.h
@@ -4,7 +4,7 @@
#ifdef __KERNEL__ /* only set these up for kernel code */
#define __HAVE_ARCH_STRCPY
-extern inline char *strcpy(char *dest, const char *src)
+static inline char *strcpy(char *dest, const char *src)
{
char *xdest = dest;
char temp = 0;
What if we compile it with gcc 4.1?
we'll have to either use the gcc attributes to force old inline
behavior or use the gcc flag to force it
We should probably have an extern_inline define then, assuming this is a
function that does exist in a linkable version already -- otherwise
"static inline" is correct.
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Bugme-new] [Bug 9217] New: CONFIG_CMDLINE doesn't pass to kernel
On Wed, 24 Oct 2007 05:32:14 -0700 (PDT) [EMAIL PROTECTED] wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=9217 > >Summary: CONFIG_CMDLINE doesn't pass to kernel >Product: Other >Version: 2.5 > KernelVersion: 2.6.23 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: high > Priority: P1 > Component: Other > AssignedTo: [EMAIL PROTECTED] > ReportedBy: [EMAIL PROTECTED] > > > Most recent kernel where this bug did not occur:2.6.24-rc1 > Distribution: Debian Armel (arm with EABI) > Hardware Environment: Sharp Zaurus 750 (ARM pxa255) > Software Environment: Debian > Problem Description: > I try to upgrade kernel from 2.6.22.9 to 2.6.23. > 2.6.22.9 works correct. Kernel 2.6.23 doesn't use CONFIG_CMDLINE and doesn't > pass bootparams: > CONFIG_CMDLINE="console=ttyS0,115200n8 console=tty1 noinitrd > root=/dev/mmcblk0p1 rootfstype=ext3 rw rootdelay=5" > But kernel still try to mount /dev/mtdblock2 using jffs2. > Steps to reproduce: > Compile kernel with CONFIG_CMDLINE and try to boot. > > Something broke CONFIG_CMDLINE of ARM (at least) between 2.6.22 and 2.6.23. I don't know whether it was an ARM patch one of those kernel-wide changes. We have futzed with the command-line parsing a bit recently, but the 2.6.23 changelog doesn't suggest anything obvious. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Quad core CPU detected but shows as single core in 2.6.23.1
Hi guys, I have a tyan s3992 h2000 with single barcelona amd quad core cpu (the other cpu socket is empty). cat /proc/cpuinfo shows amd quad core processor but core : 1ive compiled the kernel from scratch with smp and amd64 + the numa stuff. i also tried debian etchs amd64 smp kernel and same result. is amd barcelona quad core cpu not yet supported or is it something else ? Thanks for any insight. im completely stumped. ive dealt with mutliprocessing machines before and have a couple of dual cores which are fine with the exact same kernel configs. my amd tk-53 x2 turions show 2 cores in cpuinfo -Zurk- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] blackfin: "extern inline" -> "static inline"
On 10/24/07, Jie Zhang <[EMAIL PROTECTED]> wrote:
> On 10/25/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > "extern inline" will have different semantics with gcc 4.3.
> >
> > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
> >
> > --- a/include/asm-blackfin/string.h
> > +++ b/include/asm-blackfin/string.h
> > @@ -4,7 +4,7 @@
> > #ifdef __KERNEL__ /* only set these up for kernel code */
> >
> > #define __HAVE_ARCH_STRCPY
> > -extern inline char *strcpy(char *dest, const char *src)
> > +static inline char *strcpy(char *dest, const char *src)
> > {
> > char *xdest = dest;
> > char temp = 0;
>
> What if we compile it with gcc 4.1?
we'll have to either use the gcc attributes to force old inline
behavior or use the gcc flag to force it
-mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] blackfin: "extern inline" -> "static inline"
On 10/25/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> "extern inline" will have different semantics with gcc 4.3.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>
> --- a/include/asm-blackfin/string.h
> +++ b/include/asm-blackfin/string.h
> @@ -4,7 +4,7 @@
> #ifdef __KERNEL__ /* only set these up for kernel code */
>
> #define __HAVE_ARCH_STRCPY
> -extern inline char *strcpy(char *dest, const char *src)
> +static inline char *strcpy(char *dest, const char *src)
> {
> char *xdest = dest;
> char temp = 0;
What if we compile it with gcc 4.1?
Jie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.24-rc1] resource_len() utility function
On Wednesday 24 October 2007, Jeff Garzik wrote: > With regards to resource reservation... IMO we should mimic struct > pci_dev and add struct resource[] to struct device. One minor difficulty: PCI has a limit on the number of BARs, but other busses don't. It'd be better as a "struct resource *". > Just like we have pci_request_regions(), we should also be able to > easily to a dev_request_regions(). the implementation should be very > close to pci_request_region() and pci_release_region(). Wouldn't it be nicer to have PCI use those dev_*() calls? Ideally pci_request_region() wraps dev_request_region()... > Then a dev_iomap() analogue to pci_iomap() should be pretty > straightforward to create. Another minor nit: addressing the various resource types. The platform bus code has multiple lookup schemes. Calls like resource_iomap() might be more flexible, so that lookup schemes can stay flexible. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SLUB 0:1 SLAB (OOM during massive parallel kernel builds)
On Thu, 25 Oct 2007, Nick Piggin wrote: > > Ummm... all unreclaimable is set! Are you mlocking the pages in memory? Or > > what causes this? All pages under writeback? What is the dirty ratio set > > to? > > Why is SLUB behaving differently, though. Nore sure. Are we really sure that this does not occur using SLAB? > Memory efficiency wouldn't be the reason, would it? I mean, SLUB > should be more efficient than SLAB, plus have less data lying around > in queues. SLAB may have data around in queues which (if the stars align the right way) may allow it to go longer without having to get a page from the page allocator. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: SLUB 0:1 SLAB (OOM during massive parallel kernel builds)
On Thursday 25 October 2007 12:15, Christoph Lameter wrote: > On Wed, 24 Oct 2007, Alexey Dobriyan wrote: > > [12728.701398] DMA free:8032kB min:32kB low:40kB high:48kB active:2716kB > > inactive:2208kB present:12744kB pages_scanned:9299 all_unreclaimable? > > yes [12728.701567] lowmem_reserve[]: 0 2003 2003 2003 [12728.701654] > > Ummm... all unreclaimable is set! Are you mlocking the pages in memory? Or > what causes this? All pages under writeback? What is the dirty ratio set > to? Why is SLUB behaving differently, though. Memory efficiency wouldn't be the reason, would it? I mean, SLUB should be more efficient than SLAB, plus have less data lying around in queues. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.24-rc1] resource_len() utility function
On Wednesday 24 October 2007, Alan Cox wrote:
> On Wed, 24 Oct 2007 18:20:52 -0700
> David Brownell <[EMAIL PROTECTED]> wrote:
>
> > Add a new resource_len() function, so drivers can start using this
> > instead of driver-private code for a common idiom. The call can be
> > useful with at least:
> >
> > - request_region(), release_region()
> > - request_mem_region(), release_mem_region()
> > - ioremap()
> >
> > Candidate drivers include those using platform or PNP busses, and
> > maybe some others. PCI already has a similar function.
> >
> > This patch also updates a representative set of drivers in two
> > subsystems to use this call (SPI, and USB peripheral/gadget).
>
> PCI also increasingly is using functions that allow the user to choose to
> map a resource as a resource (eg pci_iomap). So is it better to have
> functions request_mem_resource(res) free_mem_resource(res) and similar
> instead or as well ?
This was intended to be a minor band-aid. ;)
We already have request_resource(), which does something
different than the request_*region() calls. I think calls
with those names would complicate an already-too-strange
interface, adding oddball siblings to request_resource().
I'd hope that when those resource calls were defined they
made sense ... but to me, they don't do so today. Consider
that the *typical* caller is given a "struct resource", and
then to claim the specified address space it must convert
it into a "start + length" representation before getting
back a *NEW* "struct resource" ... with identical contents,
other than the value of one all-but-undocumented flag bit.
Then, if it's I/O space the address is usable already; but
for memory space, it still needs an ioremap()...
Oh, and PCI has its own resource structs ("BAR") that don't
look or act the same as other resources.
So while I like the notion of starting to abolish that
conversion step, this wasn't an attempt to fix all the
bizarre behaviors of the resource API.
I could imagine a call taking a resource and returning
a "void __iomem *" to use for IO, which implicitly claims
the region (in either memory or i/o space) and does any
ioremap needed for memory space. With a sibling call to
undo all that. If that's the answer, someone else should
develop the patch and update drivers...
- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: sysfs sys/kernel/ namespace (was Re: [PATCH 0/2] add new notifier function ,take2)
On Wednesday 24 October 2007 21:12, Kay Sievers wrote: > On 10/24/07, Nick Piggin <[EMAIL PROTECTED]> wrote: > > On Tuesday 23 October 2007 10:55, Takenori Nagano wrote: > > > Nick Piggin wrote: > > > > One thing I'd suggest is not to use debugfs, if it is going to > > > > be a useful end-user feature. > > > > > > Is /sys/kernel/notifier_name/ an appropriate place? > > > > I'm curious about the /sys/kernel/ namespace. I had presumed that > > it is intended to replace /proc/sys/ basically with the same > > functionality. > > It was intended to be something like /proc/sys/kernel/ only. Really? So you'd be happy to have a /sys/dev /sys/fs /sys/kernel /sys/net /sys/vm etc? "kernel" to me shouldn't really imply the stuff under the kernel/ source directory or other random stuff that doesn't fit into another directory, but attributes that are directly related to the kernel software (rather than directly associated with any device). > > I _assume_ these are system software stats and > > tunables that are not exactly linked to device drivers (OTOH, > > where do you draw the line? eg. Would filesystems go here? > > We already have /sys/fs/ ? > > > Core network algorithm tunables might, but per interface ones probably > > not...). > > We will merge the nonsense of "block/", "class/" and "bus/" to one > "subsystem". The block, class, bus directories will only be kept as > symlinks for compatibility. Then every subsystem has a directory like: > /sys/subsystem/block/, /sys/subsystem/net/ and the devices of the > subsystem are in a devices/ directory below that. Just like the > /sys/bus/< name>/devices/ layout looks today. All subsystem-global > tunables can go below the /sys/subsystem// directory, without > clashing with the list of devices or anything else. Makes sense. > > I don't know. Is there guidelines for sysfs (and procfs for that > > matter)? Is anyone maintaining it (not the infrastructure, but > > the actual content)? > > Unfortunately, there was never really a guideline. > > > It's kind of ironic that /proc/sys/ looks like one of the best > > organised directories in proc, while /sys/kernel seems to be in > > danger of becoming a mess: it has kexec and uevent files in the > > base directory, rather than in subdirectories... > > True, just looking at it now, people do crazy things like: > /sys/kernel/notes, which is a file with binary content, and a name > nobody will ever be able to guess what it is good for. That should > definitely go into a section/ directory. Also the VM stuff there > should probably move to a /sys/vm/ directory along with the weird > placed top-level /sys/slab/. Top level directory IMO should be kept as sparse as possible. If you agree to /sys/mm for example, that's fine, but then slab should go under that. (I'd prefer all to go underneath /sys/kernel, but...). It would be nice to get a sysfs content maintainer or two. Just having new additions occasionally reviewed along with the rest of a patch, by random people, doesn't really aid consistency. Would it be much trouble to ask that _all_ additions to sysfs be accompanied by notification to this maintainer, along with a few line description? (then merge would require SOB from said maintainer). For that matter, this should be the case for *all* userspace API changes ([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: + reiserfs-dont-drop-pg_dirty-when-releasing-sub-page-sized-dirty-file .patch added to -mm tree
On Wed, Oct 24, 2007 at 04:07:37PM -0700, [EMAIL PROTECTED] wrote: > > The patch titled > reiserfs: don't drop PG_dirty when releasing sub-page-sized dirty file > has been added to the -mm tree. Its filename is > > reiserfs-dont-drop-pg_dirty-when-releasing-sub-page-sized-dirty-file.patch > > *** Remember to use Documentation/SubmitChecklist when testing your code *** > > See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find > out what to do about this > > -- > Subject: reiserfs: don't drop PG_dirty when releasing sub-page-sized dirty > file > From: Fengguang Wu <[EMAIL PROTECTED]> > > This is not a new problem in 2.6.23-git17. 2.6.22/2.6.23 is buggy in the > same way. > > Reiserfs could accumulate dirty sub-page-size files until umount time. > They cannot be synced to disk by pdflush routines or explicit `sync' ~ Sorry it's not that horrible. The *data* will still be written to disk. Only the inodes will be stuck in I_DIRTY_PAGES state, and the pages stuck in PAGECACHE_TAG_DIRTY state. > commands. Only `umount' can do the trick. > > The direct cause is: the dirty page's PG_dirty is wrongly _cleared_. > Call trace: >[] cancel_dirty_page+0xd0/0xf0 >[] :reiserfs:reiserfs_cut_from_item+0x660/0x710 >[] :reiserfs:reiserfs_do_truncate+0x271/0x530 >[] :reiserfs:reiserfs_truncate_file+0xfd/0x3b0 >[] :reiserfs:reiserfs_file_release+0x1e0/0x340 >[] __fput+0xcc/0x1b0 >[] fput+0x16/0x20 >[] filp_close+0x56/0x90 >[] sys_close+0xad/0x110 >[] system_call+0x7e/0x83 > > Fix the bug by removing the cancel_dirty_page() call. Tests show that > it causes no bad behaviors on various write sizes. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.24-rc1] fix sg_phys to use dma_addr_t
> Signed-off-by: Hugh Dickins <[EMAIL PROTECTED]> > --- > Whether this is a complete patch, suitable for all architectures, > I'm not sure: it builds, boots and runs correctly on the x86_32 box > in question, but you'll be a lot wiser than me about using dma_addr_t > for everyone. (Seems a bit of a shame to include here, > when I think all arches already get to include it one way or another, > typically via asm/scatterlist.h; but I guess it's safest to repeat > it.) there is a problem with this... sg_phys doesn't return an actual *dma* address at least not an address you can give to the device. Using dma_addr_t is thus a bit misleading. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [lm-sensors] hwmon/f75375s.c: buggy if()
Hi Riku: * Riku Voipio <[EMAIL PROTECTED]> [2007-10-24 14:50:34 +0300]: > On Fri, Oct 19, 2007 at 02:37:54PM +0200, Jean Delvare wrote: > > Riku, can you please submit a patch fixing this? The attribute should > > be declared read-only, and then you can use sysfs_chmod_file() to > > change it to read-write where supported. > > Thanks, this was good suggestion. Patch attached. No patch? -- Mark M. Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/5] wait: use lock bitops for __wait_on_bit_lock
On Thursday 25 October 2007 11:14, Andrew Morton wrote: > On Wed, 24 Oct 2007 18:13:06 +1000 [EMAIL PROTECTED] wrote: > > Signed-off-by: Nick Piggin <[EMAIL PROTECTED]> > > > > --- > > kernel/wait.c |2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > Index: linux-2.6/kernel/wait.c > > === > > --- linux-2.6.orig/kernel/wait.c > > +++ linux-2.6/kernel/wait.c > > @@ -195,7 +195,7 @@ __wait_on_bit_lock(wait_queue_head_t *wq > > if ((ret = (*action)(q->key.flags))) > > break; > > } > > - } while (test_and_set_bit(q->key.bit_nr, q->key.flags)); > > + } while (test_and_set_bit_lock(q->key.bit_nr, q->key.flags)); > > finish_wait(wq, &q->wait); > > return ret; > > } > > Sorry, I'm just not going to apply a patch like that. > > I mean, how the heck is anyone else supposed to understand what you're up > to? Hmm, I might just withdraw this patch 1/5. This is generally a slowpath, and it's hard to guarantee that any exported user doesn't rely on the full barrier here (not that they would know whether they do or not, let alone document the fact). I think all the others are pretty clear, though? (read on if no) > There's a bit of documentation in Documentation/atomic_ops.txt > (probably enough, I guess) but it is totally unobvious to 98.3% of kernel > developers when they should use test_and_set_bit() versus > test_and_set_bit_lock() and it is far too much work to work out why it was > used in __wait_on_bit_lock(), whether it is correct, what advantages it > brings and whether and where others should emulate it. If you set a bit for the purpose of opening a critical section, then you can use this. And clear_bit_unlock to close it. The advantages are that it is faster, and the hapless driver writer doesn't have to butcher or forget about doing the correct smp_mb__before_clear_bit(), or have reviewers wondering exactly WTF that barrier is for, etc. Basically, it is faster, harder to get wrong, and more self-docuemnting. In general, others should not emulate it, because they should be using our regular locking primitives instead. If they really must roll their own, then using these would be nice, IMO. > So in my opinion this submission isn't of sufficient quality to be > included in Linux. > > IOW: please write changelogs. Preferably good ones. 2/5: "tasklet_trylock opens a critical section. tasklet_unlock closes it. hence, _lock bitops can be used for the bitops" 5/5: "trylock_page opens a critical section. unlock_page closes it. hence, _lock bitops can be used for the bitops" 5/5: "trylock_buffer opens a critical section. unlock_buffer closes it. hence, _lock bitops can be used for the bitops" Are those helpful? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Hardware Monitor LM70: Convert semaphore to mutex
Hi: * Matthias Kaehlcke <[EMAIL PROTECTED]> [2007-10-24 14:59:09 +0200]: > Hardware Monitor LM70: Convert the semaphore lm70->sem to the mutex > API > > Signed-off-by: Matthias Kaehlcke <[EMAIL PROTECTED]> Applied to hwmon-2.6.git/testing, thanks. -- Mark M. Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)
On Wed, 24 Oct 2007 17:41:28 -0700 Chris Wright <[EMAIL PROTECTED]> wrote: > * Linus Torvalds ([EMAIL PROTECTED]) wrote: > > Do other people want to stand up and be "LSM maintainers" in the > > sense that they also end up being informed members who can also > > stand up for new modules and help merge them, rather than just push > > the existing one(s)? Chris? Casey? Crispin? > > Stephen and James, despite their clear bias towards SELinux, do try to > give good feedback. But you are right, there's not enough active help > for people trying to make a contribution to get their code in shape. > Many of the modules that come along have been misguided conceptually, > but I think that e.g. apparmor, tomoyo, smack could use that kind > of constructive help to get into final mergable shape. Personally, > I haven't spent nearly enough time reviewing those, my apologies to > those developers. So, yes, help is welcome. > I'll be happy to help out; I'd consider my self neutral in this space not having worked with any of the LSM out there. I do think we need to be somewhat critical to what we accept; we should at least be able to filter out "pretend security" somehow. (this is not the same as saying that you're bad if you only provide a limited security, in the contrary, I strongly believe in simple pieces. What I mean is that we should be critical to things that appear/claim to be strong but are not). Secondly, we should make sure that no new holes are added (the original SMACK series suffered from this, Al Viro helped getting that reviewed bigtime). In addition we probably should strive to getting some sort of rough "this is sort of where we draw the line" guideline set up, just to keep things more objective. (Oh and of course, if a security module is deeply involved in another kernel subsystem, say networking or the VFS, very obviously we should consult and listen to the respective maintainers of that subsystem; LSM is not there to be a big hook to bypass the process of well maintained subsystems) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] make jffs2_get_acl() static
Adrian Bunk wrote:
jffs2_get_acl() can now become static again.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Acked-by: KaiGai Kohei <[EMAIL PROTECTED]>
---
fs/jffs2/acl.c |2 +-
fs/jffs2/acl.h |2 --
2 files changed, 1 insertion(+), 3 deletions(-)
add2b887d64536f3fe978e62f0774292456f1ddb
diff --git a/fs/jffs2/acl.c b/fs/jffs2/acl.c
index 9728614..b14e805 100644
--- a/fs/jffs2/acl.c
+++ b/fs/jffs2/acl.c
@@ -176,7 +176,7 @@ static void jffs2_iset_acl(struct inode *inode, struct
posix_acl **i_acl, struct
spin_unlock(&inode->i_lock);
}
-struct posix_acl *jffs2_get_acl(struct inode *inode, int type)
+static struct posix_acl *jffs2_get_acl(struct inode *inode, int type)
{
struct jffs2_inode_info *f = JFFS2_INODE_INFO(inode);
struct posix_acl *acl;
diff --git a/fs/jffs2/acl.h b/fs/jffs2/acl.h
index 76c6ebd..0bb7f00 100644
--- a/fs/jffs2/acl.h
+++ b/fs/jffs2/acl.h
@@ -28,7 +28,6 @@ struct jffs2_acl_header {
#define JFFS2_ACL_NOT_CACHED ((void *)-1)
-extern struct posix_acl *jffs2_get_acl(struct inode *inode, int type);
extern int jffs2_permission(struct inode *, int, struct nameidata *);
extern int jffs2_acl_chmod(struct inode *);
extern int jffs2_init_acl_pre(struct inode *, struct inode *, int *);
@@ -40,7 +39,6 @@ extern struct xattr_handler jffs2_acl_default_xattr_handler;
#else
-#define jffs2_get_acl(inode, type) (NULL)
#define jffs2_permission (NULL)
#define jffs2_acl_chmod(inode) (0)
#define jffs2_init_acl_pre(dir_i,inode,mode) (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: SLUB 0:1 SLAB (OOM during massive parallel kernel builds)
On Wed, 24 Oct 2007, Alexey Dobriyan wrote: > [12728.701398] DMA free:8032kB min:32kB low:40kB high:48kB active:2716kB > inactive:2208kB present:12744kB pages_scanned:9299 all_unreclaimable? > yes [12728.701567] lowmem_reserve[]: 0 2003 2003 2003 [12728.701654] Ummm... all unreclaimable is set! Are you mlocking the pages in memory? Or what causes this? All pages under writeback? What is the dirty ratio set to? > pages_scanned:9363 all_unreclaimable? yes [12735.178618] And again. > lowmem_reserve[]: 0 2003 2003 2003 [12735.178706] DMA32 free:5700kB > min:5708kB low:7132kB high:8560kB active:512264kB inactive:1304912kB > present:2051880kB pages_scanned:3251584 all_unreclaimable? yes And again. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.24-rc1] resource_len() utility function
Alan Cox wrote: On Wed, 24 Oct 2007 18:20:52 -0700 David Brownell <[EMAIL PROTECTED]> wrote: Add a new resource_len() function, so drivers can start using this instead of driver-private code for a common idiom. The call can be useful with at least: - request_region(), release_region() - request_mem_region(), release_mem_region() - ioremap() Candidate drivers include those using platform or PNP busses, and maybe some others. PCI already has a similar function. This patch also updates a representative set of drivers in two subsystems to use this call (SPI, and USB peripheral/gadget). PCI also increasingly is using functions that allow the user to choose to map a resource as a resource (eg pci_iomap). So is it better to have functions request_mem_resource(res) free_mem_resource(res) and similar instead or as well ? With regards to resource reservation... IMO we should mimic struct pci_dev and add struct resource[] to struct device. Just like we have pci_request_regions(), we should also be able to easily to a dev_request_regions(). the implementation should be very close to pci_request_region() and pci_release_region(). Then a dev_iomap() analogue to pci_iomap() should be pretty straightforward to create. 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: Linux Security *Module* Framework (Was: LSM conversion to static interface)
On Thu, 25 Oct 2007, Alan Cox wrote: The idea that poor security is worse than no security is fallacious, and not backed up by common experience. There is a ton of evidence both in computing and outside of it which shows that poor security can be very much worse than no security at all. In particular stuff which makes users think they are secure but is worthless is very dangerous indeed. there is also pleanty of evidence that you don't have to be perfect to be good enough. in addition security is useually traded off for something else (useability, administrative effort, money, etc) and depending on what's being protected the cost that's appropriate is going to be different. When you know that security is limited you act appropriately, when you believe security is good but it is not you take inappropriate risks and get badly burned. This is very true, but the solution isn't to try and eliminate everything other then perfect security, it's to properly document the limitations of various options and educate people about them. David Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
SPI doesn't detect first dataflash (CS0) on a AT91rm9200ek with kernel 2.6.23.1
Hello I want to use SPI on a at91rm9200ek. The SPI starts and the dataflash is probed but fails with error 255. I tried on another board very similar to at91rm9200ek but with 4 dataflashs (chip select 0 to 3). The flashs 1 2 3 are well detected but the 0 fails also with the same error code. Debug traces tells all transfers seems to be OK. The board with 4 dataflashs works well with a 2.6.17 + patch at91. I don't find any answers to my problem. Could you help me ? Thanks Bruno - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)
On Wed, 24 Oct 2007, Serge E. Hallyn wrote: The scariest thing to consider is programs which don't appropriately handle failure. So I don't know, maybe the system runs a remote logger to which the multiadm policy gives some extra privs, but now the portac module prevents it from sending its data. And maybe, since the authors never saw this failure as possible, the program happens to dump sensitive data in a public readable place. I *could* be more vague but it'd be tough :) But you get the idea. Or, a better example, a privileged program reads some sensitive data - as allowed by multiadm, writes it to a file, but apparmor prevented it from chowning the file to the right user before writing, the program kept writing anyway, and now the calling user hallyn, rather than the privileged user sensitive_log_t, owns the file. I ran into examples of this with the stacker module. For instance suddenly the capability module had to be changed so that it would allow selinux xattrs to be written - leaving that arbitration to selinux. That hadn't been necessary before since selinux simply didn't explicitly call the secondary->inode_setxattr() hook. Note I'm not arguing for or against, only arguing for caution :) this sort of problem is possible with just a single LSM. remember that unix doesn't try to make it impossible for the system owner to hang himself, becouse there are many other cases where the rope is used productivly. don't let the possibility that things can be done wrong prevent other people from being creative in ways that you never thought of. David Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)
> The idea that poor security is worse than no security is fallacious, > and not backed up by common experience. There is a ton of evidence both in computing and outside of it which shows that poor security can be very much worse than no security at all. In particular stuff which makes users think they are secure but is worthless is very dangerous indeed. When you know that security is limited you act appropriately, when you believe security is good but it is not you take inappropriate risks and get badly burned. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)
* Linus Torvalds ([EMAIL PROTECTED]) wrote: > Do other people want to stand up and be "LSM maintainers" in the sense > that they also end up being informed members who can also stand up for new > modules and help merge them, rather than just push the existing one(s)? > Chris? Casey? Crispin? Stephen and James, despite their clear bias towards SELinux, do try to give good feedback. But you are right, there's not enough active help for people trying to make a contribution to get their code in shape. Many of the modules that come along have been misguided conceptually, but I think that e.g. apparmor, tomoyo, smack could use that kind of constructive help to get into final mergable shape. Personally, I haven't spent nearly enough time reviewing those, my apologies to those developers. So, yes, help is welcome. 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/
[PATCH 2.6.24-rc1] fix sg_phys to use dma_addr_t
x86_32 CONFIG_HIGHMEM64G with 5GB RAM hung when booting, after issuing
some "request_module: runaway loop modprobe binfmt-" messages in
trying to exec /sbin/init.
The binprm buf doesn't see the right ".ELF" header because sg_phys()
is providing the wrong physical addresses for high pages: a 32-bit
unsigned long is too small in this case, we need to use dma_addr_t.
Signed-off-by: Hugh Dickins <[EMAIL PROTECTED]>
---
Whether this is a complete patch, suitable for all architectures,
I'm not sure: it builds, boots and runs correctly on the x86_32 box
in question, but you'll be a lot wiser than me about using dma_addr_t
for everyone. (Seems a bit of a shame to include here,
when I think all arches already get to include it one way or another,
typically via asm/scatterlist.h; but I guess it's safest to repeat it.)
include/linux/scatterlist.h |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- 2.6.24-rc1/include/linux/scatterlist.h 2007-10-24 12:42:16.0
+0100
+++ linux/include/linux/scatterlist.h 2007-10-24 19:17:13.0 +0100
@@ -1,6 +1,7 @@
#ifndef _LINUX_SCATTERLIST_H
#define _LINUX_SCATTERLIST_H
+#include
#include
#include
#include
@@ -237,7 +238,7 @@ static inline void sg_init_table(struct
* on the sg page.
*
**/
-static inline unsigned long sg_phys(struct scatterlist *sg)
+static inline dma_addr_t sg_phys(struct scatterlist *sg)
{
return page_to_phys(sg_page(sg)) + sg->offset;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)
--- Chris Wright <[EMAIL PROTECTED]> wrote: > * Casey Schaufler ([EMAIL PROTECTED]) wrote: > > And don't give me the old "LKML is a tough crowd" feldercarb. > > Security modules have been much worse. Innovation, even in > > security, is a good thing and treating people harshly, even > > "for their own good", is an impediment to innovation. > > I agree that innovation is critical to the success of Linux, and security > is not immune to that. The trouble is that most of the security modules > that have come forward have had some real serious shortcomings. I do > believe it is prudent to keep in-tree security sensitive code under > high scrutiny because we do not want to create security holes by adding > problematic security code. I agree that security code does need to provide security. What we need to get away from is the automatic attacks that are based on 20th century computer system assumptions. Things like "name based access control is rediculous", and "a module can't be any good if it doesn't deal with all objects", or "the granularity isn't fine enough". Look at TOMOYO. It's chuck full of good ideas. Why spend so much energy badgering them about not dealing with sockets? How about helping the AppArmor crew come up with acceptable implementations rather than whinging about the evils of hard links? And maybe, just maybe, we can get away from the inevitable claim that you could do that with a few minutes work in SELinux policy, but only if you're a security professional of course. Sure, some LSM proposals will be lousy, and some really will be better done as an SELinux policy module. Some will even have merit but require unreasonable interface changes. As people who care about security (y'all who are only from the LKML are excused) it is our obligation to look beyond the preconceived notions of what is and isn't secure. Security is subjective. It's how you feel about it. 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 2.6.24-rc1] resource_len() utility function
On Wed, 24 Oct 2007 18:20:52 -0700 David Brownell <[EMAIL PROTECTED]> wrote: > Add a new resource_len() function, so drivers can start using this > instead of driver-private code for a common idiom. The call can be > useful with at least: > > - request_region(), release_region() > - request_mem_region(), release_mem_region() > - ioremap() > > Candidate drivers include those using platform or PNP busses, and > maybe some others. PCI already has a similar function. > > This patch also updates a representative set of drivers in two > subsystems to use this call (SPI, and USB peripheral/gadget). PCI also increasingly is using functions that allow the user to choose to map a resource as a resource (eg pci_iomap). So is it better to have functions request_mem_resource(res) free_mem_resource(res) and similar instead or as well ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)
I have different deal breakers. If a LSM is something simple/commonly required it should be made like posix file capability's provided to all to use. Sorry to say I see the file protection in apparmor as something everyone should be able to use at will like posix file capability's. All enforcement features should be common. I see a LSM as a director commander its reason for existence is to read security configs and hand them permissions and respond to problems. Any enforcement should be default in kernel. So LSM could be roll based, mac or any other model. Current problem enforcement and guiding are mixed up in one block. So evolution is not happening. The enforcing bits of LSM's should be a simple no brainier addons to the Linux kernel. The problem is at moment they are mixed up with Mac A security model to use has to be picked to suit job. Role Based can be Better than Mac and Mac can be better than Role based. It all depends on what you are defending. Thing common all need to protect suid, file access, network access... The bits you need to defend don't change if or if not you are running a LSM. So why are these bits bottled up inside LSM forcing people to choose the wrong security model for there task to get protection at times. There can never be one LSM to do every job. But the big but all the common bits to protect every job could be in kernel. Only thing missing is the director. This is exactly the same problem Virtual Server solutions had when then wanted to get into the kernel. At least the Virtual Server solutions were not as pig headed as some of the LSM guys about it. Where its all in or not in at all. Little bits into kernel is better than nothing. Really this will sound bad if I had my way I would kick all LSM's out of the main kernel tree until they learn to work with each other to share bits. We don't need 10 copies of protect files from access. Or 10 copies of limit what .so a application and interface with and so on. It worked with Virtual Servers to get them to sit down and start talking. What we really need working on is system wide security. No bothering a lot about the little box of LSM. Yes I am not nice to LSM. I see them as bitrot. They are going to cause containers problems in there current form as containers evolve. They are not improving the base line security level. Yes selinux saying make me default to improve secuity says that in selinux there are parts that should be chopped out and made default. But since it contains a security model it cannot be all made default because it just will not fit everywhere. Basically a LSM should make it simpler to run security tight. The big all mighty but it should not alter achievable security. If its altering achievable security main kernel is missing features and someone needs to slice and dice that LSM. Peter Dolding - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [dm-devel] [PATCH] dm: noflush resizing (0/3)
On Wed, Oct 24, 2007 at 05:25:17PM -0400, Jun'ichi Nomura wrote: > - For some device-mapper targets (multipath and mirror), > the mapping table sometimes has to be replaced to cope with device > failure. > OTOH, device-mapper flushes all pending I/Os upon table replacement > and may result in I/O errors, if there are device failures. > 'noflush' suspend is used to let dm queue the pending I/Os > instead of flushing them. > Since it's not possible for user space program to tell whether > the suspend could cause I/O error, they always use > 'noflush' to suspend mirror/multipath targets. > > - Currently resizing is disabled for 'noflush' suspend. > Resizing occurs in the course of table replacement. > To resize the device under use, device-mapper needs to get its > bdev inode. However, using bdget() in this case could cause deadlock > by waiting for I_LOCK where an I/O process holding I_LOCK is > waiting for completion of table replacement. Before reviewing the details of the proposed workaround, I'd like to see a deeper analysis of the problem to see that there isn't a cleaner way to resolve this. For example: Question) What are the realistic situations we must support that lead to a resize during table reload with I/O outstanding? - The resize is the purpose of the reload; noflush is only set to avoid losing I/O if a path should fail. So any outstanding I/O may be expected to be consistent with both the old and new sizes of the device. E.g. If it's beyond the end of a shrinking device and userspace cared about not losing that I/O, it would have waited for that I/O to be flushed *before* issuing the resize. If the I/O is beyond the end of the existing device but within the new size, userspace would have waited for the resize operation to complete before allowing the new I/O to be issued. => Is it OK for device-mapper to handle the device size check internally, rejecting any I/O that falls beyond the end of the table (it already must do this lookup anyway), and to update the size recorded in the inode later, after I/O is flowing through the device again, but (of course) before reporting that the resize operation is complete? I.e. does it eliminate deadlocks if the bdget() and i_size_write() happen after the 'resume'? Alasdair -- [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: 2.6.24-rc1 oops
On Thu, 25 Oct 2007 01:40:00 +0100 Sid Boyce <[EMAIL PROTECTED]> wrote: > x86_64 dual, gcc version 4.2.2 (SUSE Linux). > [ cut here ] > kernel BUG at include/linux/scatterlist.h:50! > invalid opcode: [1] SMP > CPU 1 > Modules linked in: ub crc_itu_t hwmon cdrom soundcore v4l1_compat > videobuf_core btcx_risc ff_memless floppy sg forcedeth ehci_hcd ohci_hcd > sd_mod usbcore jfs edd ext3 mbcache jbd fan pata_jmicron ahci sata_nv > pata_amd libata scsi_mod thermal processor > Pid: 0, comm: swapper Not tainted 2.6.24-rc1-smp #1 > RIP: 0010:[] [] > :ub:ub_state_sense+0x9a/0x169 > RSP: 0018:810100697e60 EFLAGS: 00010093 > RAX: 87654321 RBX: 810105d55000 RCX: 81011f975540 > RDX: RSI: RDI: 81011f975540 > RBP: 810105d51000 R08: R09: 810105d55098 > R10: 810001c319b8 R11: 0286 R12: 810105d55098 > R13: 810105d55260 R14: 810105d55278 R15: 810105d55298 > FS: 2afb8597c6f0() GS:81011800() knlGS: > CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b > CR2: 2afb8548200f CR3: 00010615b000 CR4: 06e0 > DR0: DR1: DR2: > DR3: DR6: 0ff0 DR7: 0400 > Process swapper (pid: 0, threadinfo 81010069, task 810100689160) > Stack: 0001 810105d55000 810105d51000 > 810105d55260 881f4d43 810105919998 810105d553a0 > 810105d553af 810105d55348 0286 810105d55058 > Call Trace: > [] :ub:ub_scsi_action+0x1e3/0x214 > [] tasklet_action+0x54/0x97 > [] __do_softirq+0x65/0xce > [] call_softirq+0x1c/0x28 > [] do_softirq+0x2c/0x7d > [] irq_exit+0x3f/0x84 > [] do_IRQ+0x13e/0x15f > [] default_idle+0x0/0x3d > [] default_idle+0x0/0x3d > [] ret_from_intr+0x0/0xa > [] default_idle+0x29/0x3d > [] cpu_idle+0x93/0xbb Can you try this? Thanks, diff --git a/drivers/block/ub.c b/drivers/block/ub.c index 14143f2..78f158f 100644 --- a/drivers/block/ub.c +++ b/drivers/block/ub.c @@ -1428,6 +1428,7 @@ static void ub_state_sense(struct ub_dev *sc, struct ub_scsi_cmd *cmd) scmd->state = UB_CMDST_INIT; scmd->nsg = 1; sg = &scmd->sgv[0]; + sg_init_table(sg, UB_MAX_REQ_SG); sg_set_page(sg, virt_to_page(sc->top_sense)); sg->offset = (unsigned long)sc->top_sense & (PAGE_SIZE-1); sg->length = UB_SENSE_SIZE; @@ -1864,6 +1865,7 @@ static int ub_sync_read_cap(struct ub_dev *sc, struct ub_lun *lun, cmd->state = UB_CMDST_INIT; cmd->nsg = 1; sg = &cmd->sgv[0]; + sg_init_table(sg, UB_MAX_REQ_SG); sg_set_page(sg, virt_to_page(p)); sg->offset = (unsigned long)p & (PAGE_SIZE-1); sg->length = 8; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 2.6.24-rc1] resource_len() utility function
Add a new resource_len() function, so drivers can start using this
instead of driver-private code for a common idiom. The call can be
useful with at least:
- request_region(), release_region()
- request_mem_region(), release_mem_region()
- ioremap()
Candidate drivers include those using platform or PNP busses, and
maybe some others. PCI already has a similar function.
This patch also updates a representative set of drivers in two
subsystems to use this call (SPI, and USB peripheral/gadget).
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
Despite comments that we have "needed" this for at least five years,
this is pure cleanup. IMO it's appropriate for 2.6.25 and to simmer
with the rest of the MM soup for a while.
drivers/spi/atmel_spi.c |2 +-
drivers/spi/omap2_mcspi.c |7 +++
drivers/spi/spi_imx.c |5 ++---
drivers/spi/spi_mpc83xx.c |2 +-
drivers/spi/spi_s3c24xx.c |4 ++--
drivers/spi/spi_txx9.c|2 +-
drivers/spi/xilinx_spi.c |5 ++---
drivers/usb/gadget/at91_udc.c | 12 +---
drivers/usb/gadget/fsl_usb2_udc.c |9 -
drivers/usb/gadget/omap_udc.c |6 +++---
include/linux/ioport.h|5 +
11 files changed, 29 insertions(+), 30 deletions(-)
--- at91.orig/include/linux/ioport.h2007-10-19 11:38:39.0 -0700
+++ at91/include/linux/ioport.h 2007-10-19 14:26:50.0 -0700
@@ -22,6 +22,11 @@ struct resource {
struct resource *parent, *sibling, *child;
};
+static inline resource_size_t __pure resource_len(const struct resource *r)
+{
+ return r->end + 1 - r->start;
+}
+
struct resource_list {
struct resource_list *next;
struct resource *res;
--- at91.orig/drivers/usb/gadget/at91_udc.c 2007-10-13 15:16:13.0
-0700
+++ at91/drivers/usb/gadget/at91_udc.c 2007-10-19 14:26:33.0 -0700
@@ -1656,9 +1656,7 @@ static int __init at91udc_probe(struct p
if (!res)
return -ENXIO;
- if (!request_mem_region(res->start,
- res->end - res->start + 1,
- driver_name)) {
+ if (!request_mem_region(res->start, resource_len(res), driver_name)) {
DBG("someone's using UDC memory\n");
return -EBUSY;
}
@@ -1670,9 +1668,9 @@ static int __init at91udc_probe(struct p
udc->pdev = pdev;
udc->enabled = 0;
- udc->udp_baseaddr = ioremap(res->start, res->end - res->start + 1);
+ udc->udp_baseaddr = ioremap(res->start, resource_len(res));
if (!udc->udp_baseaddr) {
- release_mem_region(res->start, res->end - res->start + 1);
+ release_mem_region(res->start, resource_len(res));
return -ENOMEM;
}
@@ -1735,7 +1733,7 @@ static int __init at91udc_probe(struct p
fail1:
device_unregister(&udc->gadget.dev);
fail0:
- release_mem_region(res->start, res->end - res->start + 1);
+ release_mem_region(res->start, resource_len(res));
DBG("%s probe failed, %d\n", driver_name, retval);
return retval;
}
@@ -1761,7 +1759,7 @@ static int __exit at91udc_remove(struct
iounmap(udc->udp_baseaddr);
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- release_mem_region(res->start, res->end - res->start + 1);
+ release_mem_region(res->start, resource_len(res));
clk_put(udc->iclk);
clk_put(udc->fclk);
--- at91.orig/drivers/usb/gadget/fsl_usb2_udc.c 2007-10-13 15:16:13.0
-0700
+++ at91/drivers/usb/gadget/fsl_usb2_udc.c 2007-10-19 11:43:12.0
-0700
@@ -2268,14 +2268,13 @@ static int __init fsl_udc_probe(struct p
return -ENXIO;
}
- if (!request_mem_region(res->start, res->end - res->start + 1,
- driver_name)) {
+ if (!request_mem_region(res->start, resource_len(res), driver_name)) {
ERR("request mem region for %s failed \n", pdev->name);
kfree(udc_controller);
return -EBUSY;
}
- dr_regs = ioremap(res->start, res->end - res->start + 1);
+ dr_regs = ioremap(res->start, resource_len(res));
if (!dr_regs) {
ret = -ENOMEM;
goto err1;
@@ -2376,7 +2375,7 @@ err3:
err2:
iounmap(dr_regs);
err1:
- release_mem_region(res->start, res->end - res->start + 1);
+ release_mem_region(res->start, resource_len(res));
kfree(udc_controller);
return ret;
}
@@ -2405,7 +2404,7 @@ static int __exit fsl_udc_remove(struct
dma_pool_destroy(udc_controller->td_pool);
free_irq(udc_controller->irq, udc_controller);
iounmap(dr_regs);
- release_mem_region(res->start, res->end - res->start + 1);
+ release_mem_region(res->start, resource_len(res));
device_unregister(&udc_controller->gadget.dev);
/* fr
Re: [patch 1/5] wait: use lock bitops for __wait_on_bit_lock
On Wed, 24 Oct 2007 18:13:06 +1000 [EMAIL PROTECTED] wrote: > Signed-off-by: Nick Piggin <[EMAIL PROTECTED]> > > --- > kernel/wait.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > Index: linux-2.6/kernel/wait.c > === > --- linux-2.6.orig/kernel/wait.c > +++ linux-2.6/kernel/wait.c > @@ -195,7 +195,7 @@ __wait_on_bit_lock(wait_queue_head_t *wq > if ((ret = (*action)(q->key.flags))) > break; > } > - } while (test_and_set_bit(q->key.bit_nr, q->key.flags)); > + } while (test_and_set_bit_lock(q->key.bit_nr, q->key.flags)); > finish_wait(wq, &q->wait); > return ret; > } > Sorry, I'm just not going to apply a patch like that. I mean, how the heck is anyone else supposed to understand what you're up to? There's a bit of documentation in Documentation/atomic_ops.txt (probably enough, I guess) but it is totally unobvious to 98.3% of kernel developers when they should use test_and_set_bit() versus test_and_set_bit_lock() and it is far too much work to work out why it was used in __wait_on_bit_lock(), whether it is correct, what advantages it brings and whether and where others should emulate it. So in my opinion this submission isn't of sufficient quality to be included in Linux. IOW: please write changelogs. Preferably good ones. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)
--- Linus Torvalds <[EMAIL PROTECTED]> wrote: > > > On Thu, 25 Oct 2007, Adrian Bunk wrote: > > > > What I'm giving you is "Linus has decreed there can be LSMs other than > > SELinux." > > > > Getting LSMs included should no longer be harder than for other > > parts of the kernel. > > Well, despite my heart-felt feelings that we should support different > people in trying out different things, one of the issues is also that I'm > obviously not myself a security person. I can "decree" all I want, but in > the end, I really want the people *involved* to merge security stuff. > > Right now Chris Wrigt is the documented maintainer for LSM, and quite > frankly, I do not want to take it over. I really really really hope that > people that are interested in security can work this thing out, and my > only requirement is that it doesn't end up being any kind of force-feeding > of opinions and ideas, since clearly there is tons of room for > disagreement in the area.. > > Do other people want to stand up and be "LSM maintainers" in the sense > that they also end up being informed members who can also stand up for new > modules and help merge them, rather than just push the existing one(s)? > Chris? Casey? Crispin? Count me in. > [ Ie there's the "core LSM hooks" on one side, but there's also the "what > modules make any sense at all to merge?" on the other, and I really > don't have the expertise to make any sensible judgements except for the > pure "process" judgement that we should not hardcode things to just one > module! ] > > 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/ > > > 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: [uml-devel] User Mode Linux still doesn't build in 2.6.23-final.
On Wed, Oct 24, 2007 at 04:46:54PM -0500, Rob Landley wrote: > Prebuilt for Ubuntu 7.04: > http://landley.net/code/firmware/downloads/cross-compiler/host-i686/cross-compiler-sparc.tar.bz2 > > Source code: > Or http://landley.net/code/firmware/downloads/firmware-0.2.2.tar.bz2 Thanks - I already got Dan Kegel's crosstools, and they did the trick. What I'd like to do is have linux/swap.h include linux/pagemap.h, but there's this scary comment about that not working on sparc. When I fix this bug "correctly", sparc expodes into a mess of interconnected headers which seem to boil down to sparc including swap.h in pgtable.h when no one else does. The thing is, sparc looks like it's doing things more correctly than anyone else. asm/pgtable.h (i386 and UML, and probably everyone else except sparc) refers to swp_entry_t, which is defined in linux/swap.h, without including swap.h and that's somehow OK. So, from a quick look, it seems like this is a case of our headers being too interconnected and sparc had to opt out in order to do things more correctly. Jeff -- Work email - jdike at linux dot intel dot 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: [2.6 patch] drivers/base/node.c: cleanups
On Wed, 24 Oct 2007 09:52:56 -0700 (PDT) Christoph Lameter <[EMAIL PROTECTED]> wrote: > On Wed, 24 Oct 2007, Adrian Bunk wrote: > > > This patch contains the following cleanups: > > - make the following needlessly globalcode static: > > - register_node() > > - node_state_attr[] > > - #if 0 the following unused global functions: > > - unregister_node() > > - unregister_one_node() > > These may beneeded by the memory hotplug folks. Better leave them > alone. > Yes, please leave them for a while... Thanks, -Kame Thank you >> Christoph-san. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
