Re: [patch 14/22] pollfs: pollable futex
On 5/6/07, Andrew Morton <[EMAIL PROTECTED]> wrote: What is your position on the timerfd/signalfd/etc patches? One more thing: recently in a network-related discussion with DaveM et.al. we came across a situation where we want events from the kernel. The requirement is for fast event notification (or non-blocking polling) and the event is only implicitly needed. Having a file descriptor open is not an option. The possibilities are - open a file in /proc or /sys or a socket for every call to te function to check for events - have a memory-mapped interface like kevent which does not keep file descriptors open File descriptions are problematic when it comes implicitly uses in the runtime. This is, for instance, why we have MAP_ANON instead of keeping a /dev/null file descriptor open all the time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 14/22] pollfs: pollable futex
On 5/6/07, Andrew Morton <[EMAIL PROTECTED]> wrote: What is your position on the timerfd/signalfd/etc patches? Seems to me that if we were to have fancy new event-delivery machinery like kevent then the timerfd/signalfd work is heading in the other direction and ultimately would prove to have been unneeded? That's my point. I think we ultimately have to have something like kevent and then all this *fd() work is unnecessary and just adds code to the kernel which has to be kept around and which might hinder further work in this area. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [00/17] Large Blocksize Support V3
On Sun, May 06, 2007 at 10:48:23PM -0600, Eric W. Biederman wrote: > David Chinner <[EMAIL PROTECTED]> writes: > > > On Fri, May 04, 2007 at 07:33:54AM -0600, Eric W. Biederman wrote: > >> > > >> > So while the jury is out about how many other filesystems might use > >> > it, I suspect it's more than you might think. At the very least, > >> > there may be some IA64 users who might be trying to transition their > >> > way to x86_64, and have existing filesystems using a 8k or 16k > >> > block filesystems. :-) > >> > >> How much of a problem would it be if those blocks were not necessarily > >> contiguous in RAM, but placed in normal 4K pages in the page cache? > > > > If you need to treat the block in a contiguous range, then you need to > > vmap() the discontiguous pages. That has substantial overhead if you > > have to do it regularly. > > Which is why I would prefer not to do it. I think vmap is not really > compatible with the design of the linux page cache. Right - so how do we efficiently manipulate data inside a large block that spans multiple discontigous pages if we don't vmap it? > Although we can't even count on the pages being mapped into low > memory right now and have to call kmap if we want to access them > so things might not be that bad. Even if it was a multipage kmap > type operation. Except when you structures span page boundaries. Then you can't directly reference the structure - it needs to be copied out elsewhere, modified and copied back. That's messy and will require significant modification to any filesystem that wants large block sizes > > We do this in xfs_buf.c for > page size blocks - the overhead that > > caused when operating on inode clusters resulted in us doing some > > pointer fiddling and directly addresing the contents of each page > > to avoid the vmap overhead. See xfs_buf_offset() and friends > > > >> I expect meta data operations would have to be modified but that otherwise > >> you would not care. > > > > I think you might need to modify the copy-in and copy-out operations > > substantially (e.g. prepare_/commit_write()) as they assume a buffer doesn't > > span multple pages. > > But in a filesystem like ext2 except for a zeroing some unused hunks > of the page all that really happens is you setup for DMA straight out > of the page cache. So this is primarily an issue for meta-data. I'm not sure I follow you here - copyin/copyout is to userspace and has to handle things like RMW cycles to a filesystem block. e.g. if we get a partial block over-write, we need to read in all the bits around it and that will span multiple discontiguous pages. Currently these function only handle RMW operations on something up to a single page in size - to handle a RMW cycle on a block larger than a page they are going to need substantial modification or entirely new interfaces. The high order page cache avoids the need to redesign interfaces because it doesn't change the interfaces between the filesystem and the page cache - everything still effectively operates on single pages and the filesystem block size never exceeds the size of a single page. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] ARM: include IXP4xx "fuses" support
Hello, Krzysztof.
On 5/7/07, Krzysztof Halasa <[EMAIL PROTECTED]> wrote:
...
+IXP4XX_FUSE_RSA | \
+IXP4XX_FUSE_XSCALE_MAX_FREQ)
+
#ifndef __ASSEMBLY__
+static inline u32 ixp4xx_read_fuses(void)
+{
+ unsigned int fuses = ~*IXP4XX_EXP_CFG2;
...
+ fuses &= ~IXP4XX_FUSE_RESERVED;
+}
#endif /* __ASSEMBLY__ */
+
#endif
Are you sure this is the version you wanted to send? I don't see how this could
compile without this #ifndef. And also there is some problem with undefined
processor_id, but this is not your fault, but a flaw in the pre-rc1
kernel, which
I hope is now noticed. So maybe you should just send the patches made for
the 2.6.21 kernel?
Otherwise, when applied on top of my 2.6.20 kernel, the driver just
works (at least
I see the pings, haven't considered any other tests yet), thank you a lot!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: OOPS when swsusp/resume when connected to the internet via BT and GPRS
On Mon, May 07, 2007 at 07:04:29AM +0200, CIJOML wrote: > Hi Michal, > > my kernel is tainted with madwifi opensource driver :). Only binary part is > ath_hal module, which doesn't have anythink to do with this part of kernel. Any module can change any part of the kernel, e.g. a part of the code executed when loading the ath_hal module could accidentally corrupt a kernel data structure. > Ath_hal is doing RF part of card to protect others tune/transmit in other > frequency than 2.5/5.8GHz (Wifi 802.11a/b/g). > > My kernel is 100% opensource :) That's wrong, the binary-only blob from ath_hal loaded into your kernel is not opensource. > And BTW this happens also with madwifi kernel modules unloaded. An Oops without any external module ever loaded since booting is strongly preferred. > Best regards > > Michal cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] add support for reading stdin with gen_init_cpio
Treat an argument of "-" as meaning "read stdin for cpio files" so
gen_init_cpio can be piped into.
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
---
diff --git a/usr/gen_init_cpio.c b/usr/gen_init_cpio.c
index 8365db6..7abc07f 100644
--- a/usr/gen_init_cpio.c
+++ b/usr/gen_init_cpio.c
@@ -498,7 +498,9 @@ int main (int argc, char *argv[])
exit(1);
}
- if (! (cpio_list = fopen(argv[1], "r"))) {
+ if (!strcmp(argv[1], "-"))
+ cpio_list = stdin;
+ else if (! (cpio_list = fopen(argv[1], "r"))) {
fprintf(stderr, "ERROR: unable to open '%s': %s\n\n",
argv[1], strerror(errno));
usage(argv[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: OOPS when swsusp/resume when connected to the internet via BT and GPRS
Hi Michal, my kernel is tainted with madwifi opensource driver :). Only binary part is ath_hal module, which doesn't have anythink to do with this part of kernel. Ath_hal is doing RF part of card to protect others tune/transmit in other frequency than 2.5/5.8GHz (Wifi 802.11a/b/g). My kernel is 100% opensource :) And BTW this happens also with madwifi kernel modules unloaded. Best regards Michal Dne pondělí 07 květen 2007 00:34 jste napsal(a): > Hi Michal, > > On 07/05/07, CIJOML <[EMAIL PROTECTED]> wrote: > > Hi all, > > > > today I experienced OOPS when connected via BT/GPRS to the internet, then > > swsup and resumed with dongle in HID proxy mode. Please see details in > > dmesg log: > > > > Restarting tasks ... <6>usb 3-1: USB disconnect, address 3 > > done. > > BUG: unable to handle kernel NULL pointer dereference at virtual address > > 0008 > > printing eip: > > c018db5d > > *pde = > > Oops: [#1] > > PREEMPT > > Modules linked in: ppp_deflate zlib_deflate bsd_comp ppp_async > > ppp_generic slhc usbhid nls_iso8859_1 nls_cp437 vfat fat sg > > sr_mod sd_mod usb_storage bnep rfcomm hidp l2cap lp fuse eeprom hci_usb > > bluetooth 8250_pci 8250 serial_core snd_intel8x0 sn > > d_intel8x0m snd_ac97_codec wlan_scan_sta ac97_bus ath_rate_sample > > nsc_ircc snd_pcm ide_cd ath_pci wlan ath_hal(P) 8139too m > > ii snd_timer snd irda ehci_hcd psmouse pcspkr i2c_i801 iTCO_wdt > > iTCO_vendor_support rtc cdrom parport_pc parport snd_page_a > > lloc uhci_hcd crc_ccitt > > CPU:0 > > EIP:0060:[]Tainted: P VLI > > You are using tainted kernel. > > "When you are using a binary driver, the kernel is "tainted", > which means that the source > of possible problems may be unrelated to the kernel code (see > https://secure-support. > novell.com/KanisaPlatform/Publishing/250/3582750_f.SAL_Public.html for more > de- tails). You can check whether or not the kernel was tainted when the > problem occured by > looking at the corresponding error message. If can you see something > similar to the following > line: > EIP: 0060:[] Tainted: P VLI > (the word Tainted is crucial here), the kernel was tainted and most > probably the kernel > developers will not be able to help you. In that case you should try > to reproduce the problem > without the binary driver loaded. Moreover, if the problem does not > occur without it, you > should send a bug report to the creators of the binary driver and ask > them to fix it." > > -- Linux Kernel Tester's Guide > > > EFLAGS: 00010282 (2.6.21 #3) > > EIP is at sysfs_move_dir+0x3e/0x117 > > eax: ebx: efd7df40 ecx: f79a1e7c edx: c1b88940 > > esi: c1b91e28 edi: ebp: c1b88940 esp: f79a1e50 > > ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 > > Process pppd (pid: 6550, ti=f79a task=f29d6ab0 task.ti=f79a) > > Stack: c03475a4 f7f86e68 fff4 efd7df40 f7f86e68 fff4 > > c1b88940 c01d27ec f12a5240 c0347596 efd7df40 f12a5240 f12a5240 > > f7f86e00 c1b88940 c023c984 f7f86e68 f7f36640 ef67b000 > > Call Trace: > > [] kobject_move+0xaf/0xfa > > [] device_move+0x49/0xd7 > > [] rfcomm_tty_close+0x23/0x7a [rfcomm] > > [] release_dev+0x1df/0x5e7 > > [] inode_has_perm+0x66/0x6e > > [] __posix_lock_file_conf+0x44e/0x48b > > [] file_has_perm+0x89/0x91 > > [] tty_release+0xf/0x18 > > [] __fput+0x96/0x15e > > [] filp_close+0x51/0x58 > > [] sys_close+0x75/0xbf > > [] syscall_call+0x7/0xb > > === > > Code: 40 30 eb 0b a1 a0 79 42 c0 8b 40 14 8b 40 38 89 44 24 08 85 d2 74 > > 05 8b 72 30 eb 0b a1 a0 79 42 c0 8b 40 14 8b 70 38 > > 8b 7c 24 08 <8b> 47 08 31 ff 3b 46 08 0f 84 c1 00 00 00 8b 54 24 08 8b 42 > > 08 EIP: [] sysfs_move_dir+0x3e/0x117 SS:ESP 0068:f79a1e50 > > > > Thanks for fixing this issue > > > > Michal > > Regards, > Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [00/17] Large Blocksize Support V3
On Fri, May 04, 2007 at 07:31:37AM -0600, Eric W. Biederman wrote: > David Chinner <[EMAIL PROTECTED]> writes: > > > On Fri, Apr 27, 2007 at 12:04:03AM -0700, Andrew Morton wrote: > > I've got several year-old Irix bugs assigned that are hit every so > > often where one page in the aggregated set has the wrong state, and > > it's simply not possible to either reproduce the problem or work out > > how it happened. The code has grown too complex and convoluted, and > > by the time the problem is noticed (either by hang, panic or bug > > check) the cause of it is long gone. > > > > I don't want to go back to having to deal with this sort of problem > > - I'd much prefer to have a design that does not make the same > > mistakes that lead to these sorts of problem. > > So the practical question is. Was it a high level design problem or > was it simply a choice of implementation issue. Both. To many things can happen asynchroonously to a page that it makes it just about impossible to predict all the potential race conditions that are involved. complexity arose from trying to fix the races that were uncovered without breaking everything else... > Until we code review and implementation that does page aggregation for > linux we can't say how nasty it would be. We already have an implementation - I've pointed it out several times now: see fs/xfs/linux-2.6/xfs_buf.[ch]. There are a lot of nasties in there > >> You're addressing Christoph's straw man here. > > > > No, I'm speaking from years of experience working on a > > page/buffer/chunk cache capable of using both large pages and > > aggregating multiple pages. It has, at times, almost driven me > > insane and I don't want to go back there. > > The suggestion seems to be to always aggregate pages (to handle > PAGE_SIZE < block size), and not to even worry about the fact > that it happens that the pages you are aggregating are physically > contiguous. The memory allocator and the block layer can worry > about that. It isn't something the page cache or filesystems > need to pay attention to. perfomrance problems in using discontigous pages and needing to vmap() them says otherwise > I suspect the implementation in linux would be sufficiently different > that it would not be prone to the same problems. Among other things > we are already do most things on a range of page addresses, so we > would seem to have most of the infrastructure already. Filesystems don't typically do this - they work on blocks and assume that a block can be directly referenced. > Given that small block sizes give us better storage efficiency, > which means less disk bandwidth used, which means less time > to get the data off of a slow disk (especially if you can > put multiple files you want simultaneously in that same space). > I'm not convinced that large block sizes are a clear disk performance > advantage, so we should not neglect the small file sizes. Hmmm - we're not talking about using 64k block size filesystems to store lots of little files or using them on small, slow disks. We're looking at optimising for multi-petabyte filesystems with multi-terabyte sized files sustaining throughput of tens to hundreds of GB/s to/from hundreds to thousands of disk. I certinaly don't consider 64k block size filesystems as something suitable for desktop use - maybe PVRs would benefit, but this is not something you'd use for your kernel build environment on a single disk in a desktop system Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] MM: implement MADV_FREE lazy freeing of anonymous memory
Rik van Riel wrote: It's trivial to merge the MADV_FREE #defines into the kernel though, and aliasing MADV_FREE to MADV_DONTNEED for the time being is a one-liner - just an extra constant into the big switch statement in sys_madvise(). Until the semantics of the implementation is cut into stone by having it in the kernel I'll not start using it. -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [00/17] Large Blocksize Support V3
David Chinner <[EMAIL PROTECTED]> writes: > On Fri, May 04, 2007 at 07:33:54AM -0600, Eric W. Biederman wrote: >> > >> > So while the jury is out about how many other filesystems might use >> > it, I suspect it's more than you might think. At the very least, >> > there may be some IA64 users who might be trying to transition their >> > way to x86_64, and have existing filesystems using a 8k or 16k >> > block filesystems. :-) >> >> How much of a problem would it be if those blocks were not necessarily >> contiguous in RAM, but placed in normal 4K pages in the page cache? > > If you need to treat the block in a contiguous range, then you need to > vmap() the discontiguous pages. That has substantial overhead if you > have to do it regularly. Which is why I would prefer not to do it. I think vmap is not really compatible with the design of the linux page cache. Although we can't even count on the pages being mapped into low memory right now and have to call kmap if we want to access them so things might not be that bad. Even if it was a multipage kmap type operation. > We do this in xfs_buf.c for > page size blocks - the overhead that > caused when operating on inode clusters resulted in us doing some > pointer fiddling and directly addresing the contents of each page > to avoid the vmap overhead. See xfs_buf_offset() and friends > >> I expect meta data operations would have to be modified but that otherwise >> you would not care. > > I think you might need to modify the copy-in and copy-out operations > substantially (e.g. prepare_/commit_write()) as they assume a buffer doesn't > span multple pages. But in a filesystem like ext2 except for a zeroing some unused hunks of the page all that really happens is you setup for DMA straight out of the page cache. So this is primarily an issue for meta-data. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] MM: implement MADV_FREE lazy freeing of anonymous memory
Ulrich Drepper wrote: Rik van Riel wrote: I think that maybe for 2.6.22 we should just alias MADV_FREE to run with the MADV_DONTNEED functionality, so that the glibc people can make the change on their side while we figure out what will be the best thing to do on the kernel side. No need for that. We can later extend glibc to use MADV_FREE and fall back on MADV_DONTNEED. It's trivial to merge the MADV_FREE #defines into the kernel though, and aliasing MADV_FREE to MADV_DONTNEED for the time being is a one-liner - just an extra constant into the big switch statement in sys_madvise(). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: JBD: ext2online wants too many credits (744 > 256)
On Mon, 7 May 2007 00:26:26 +0200 Frank van Maarseveen <[EMAIL PROTECTED]> wrote: > 2.6.20.6, FC4: > > I created a 91248k ext3 fs with 4k blocksize: > > | mke2fs -j -b 4096 /dev/vol1/project > | mke2fs 1.38 (30-Jun-2005) > | Filesystem label= > | OS type: Linux > | Block size=4096 (log=2) > | Fragment size=4096 (log=2) > | 23552 inodes, 23552 blocks > | 1177 blocks (5.00%) reserved for the super user > | First data block=0 > | Maximum filesystem blocks=25165824 > | 1 block group > | 32768 blocks per group, 32768 fragments per group > | 23552 inodes per group > > Writing inode tables: done > Creating journal (1024 blocks): done > Writing superblocks and filesystem accounting information: done > > Next, I tried to resize it to about 3G using ext2online while mounted: > > | # ext2online /dev/vol1/project > | ext2online v1.1.18 - 2001/03/18 for EXT2FS 0.5b > | ext2online: ext2_ioctl: No space left on device > | > | ext2online: unable to resize /dev/mapper/vol1-project > > At that time the kernel said: > > |JBD: ext2online wants too many credits (744 > 256) > > What is the limitation I should be aware of? Has it something to do with > the journal log size? > > The size actually did increase a bit, to 128112k. > > > Steps to reproduce: > Create a 3G partition, say /dev/vol1/project > mke2fs -j -b 4096 /dev/vol1/project 22812 > mount it > ext2online /dev/vol1/project said: > > | ext2online v1.1.18 - 2001/03/18 for EXT2FS 0.5b > | ext2online: ext2_ioctl: No space left on device > | > | ext2online: unable to resize /dev/mapper/vol1-project > > kernel said: > > | JBD: ext2online wants too many credits (721 > 256) > (added linux-ext4 to cc) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [00/17] Large Blocksize Support V3
On Fri, May 04, 2007 at 07:33:54AM -0600, Eric W. Biederman wrote: > > > > So while the jury is out about how many other filesystems might use > > it, I suspect it's more than you might think. At the very least, > > there may be some IA64 users who might be trying to transition their > > way to x86_64, and have existing filesystems using a 8k or 16k > > block filesystems. :-) > > How much of a problem would it be if those blocks were not necessarily > contiguous in RAM, but placed in normal 4K pages in the page cache? If you need to treat the block in a contiguous range, then you need to vmap() the discontiguous pages. That has substantial overhead if you have to do it regularly. We do this in xfs_buf.c for > page size blocks - the overhead that caused when operating on inode clusters resulted in us doing some pointer fiddling and directly addresing the contents of each page to avoid the vmap overhead. See xfs_buf_offset() and friends > I expect meta data operations would have to be modified but that otherwise > you would not care. I think you might need to modify the copy-in and copy-out operations substantially (e.g. prepare_/commit_write()) as they assume a buffer doesn't span multple pages. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SCSI discover order strangeness [Bug 8412] New: CONFIG_MOUSE_PS2 makes RAID detection fail
On Tuesday May 1, [EMAIL PROTECTED] wrote: > On Tue, May 01, 2007 at 07:46:36PM +1000, Neil Brown wrote: > > > > My first thought was that the new threaded device discovery was > > allowing md init to happen before scsi discovery was complete. Maybe > > the presence of CONFIG_MOUSE_PS2 makes some bit go faster... > > > > However > > # CONFIG_SCSI_SCAN_ASYNC is not set > > > > so maybe not... > > > > Greg (or anyone else reading): you know about this threaded > > discovery.. could it allow some discovery to complete after userspace > > has started, and does CONFIG_SCSI_SCAN_ASYNC affect it? > > This kind of threaded discovery is different from the bus-level threaded > probing that I originally proposed a while back, and then later > retracted due to bugs. > > So this is just a scsi thing, I know nothing about it. > OK, thanks. It turns out they are USB drives, so maybe it is a USB problem, or maybe their expectations are wrong. It also turns out that the email->bugzilla gateway completely failed for me in trying to deal with this bug. Ho hum. NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] please pull infiniband.git
Linus, please pull from master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git for-linus This tree is also available from kernel.org mirrors at: git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git for-linus This is the second batch of merges for 2.6.22 -- mostly fixes, but also the conversion of IPoIB to use NAPI: Ishai Rabinovitz (1): IB/srp: Add orig_dgid sysfs attribute to scsi_host Michael S. Tsirkin (4): IB/mthca: Work around kernel QP starvation IPoIB/cm: Fix error handling in ipoib_cm_dev_open() IPoIB/cm: Don't crash if remote side uses one QP for both directions IB: Add CQ comp_vector support Ralph Campbell (4): IB/ipath: Don't call spin_lock_irq() from interrupt context IB/ipath: Don't put QP in timeout queue if waiting to send IB/ipath: Fix two more spin lock problems IB/ipath: Fix a race condition when generating ACKs Robert Walsh (1): IB/ipath: Don't corrupt pending mmap list when unmapped objects are freed Roland Dreier (4): IB/srp: Set proc_name IB/fmr_pool: Add prefix to all printks IB: Return "maybe missed event" hint from ib_req_notify_cq() IPoIB: Convert to NAPI Steve Wise (4): RDMA/cxgb3: Fix TERM codes RDMA/cxgb3: Fail qp creation if the requested max_inline is too large RDMA/cxgb3: Initialize cpu_idx field in cpl_close_listserv_req message RDMA/cxgb3: Support for new abort logic drivers/infiniband/core/fmr_pool.c | 32 + drivers/infiniband/core/mad.c|2 +- drivers/infiniband/core/uverbs_cmd.c |1 + drivers/infiniband/core/uverbs_main.c|2 +- drivers/infiniband/core/verbs.c |4 +- drivers/infiniband/hw/amso1100/c2.h |2 +- drivers/infiniband/hw/amso1100/c2_cq.c | 16 - drivers/infiniband/hw/amso1100/c2_provider.c |3 +- drivers/infiniband/hw/cxgb3/cxio_hal.c |3 + drivers/infiniband/hw/cxgb3/cxio_wr.h|1 + drivers/infiniband/hw/cxgb3/iwch_cm.c| 19 ++ drivers/infiniband/hw/cxgb3/iwch_cm.h|6 ++ drivers/infiniband/hw/cxgb3/iwch_provider.c | 14 +++- drivers/infiniband/hw/cxgb3/iwch_qp.c| 69 +++- drivers/infiniband/hw/ehca/ehca_cq.c |2 +- drivers/infiniband/hw/ehca/ehca_iverbs.h |4 +- drivers/infiniband/hw/ehca/ehca_main.c |3 +- drivers/infiniband/hw/ehca/ehca_reqs.c | 14 +++- drivers/infiniband/hw/ehca/ipz_pt_fn.h |8 ++ drivers/infiniband/hw/ipath/ipath_cq.c | 68 ++-- drivers/infiniband/hw/ipath/ipath_mmap.c | 64 +-- drivers/infiniband/hw/ipath/ipath_qp.c | 52 +-- drivers/infiniband/hw/ipath/ipath_rc.c | 55 drivers/infiniband/hw/ipath/ipath_srq.c | 55 drivers/infiniband/hw/ipath/ipath_verbs.c|4 + drivers/infiniband/hw/ipath/ipath_verbs.h| 24 +-- drivers/infiniband/hw/mthca/mthca_cq.c | 12 ++-- drivers/infiniband/hw/mthca/mthca_dev.h |4 +- drivers/infiniband/hw/mthca/mthca_provider.c |2 + drivers/infiniband/hw/mthca/mthca_qp.c | 13 drivers/infiniband/ulp/ipoib/ipoib.h |1 + drivers/infiniband/ulp/ipoib/ipoib_cm.c | 14 +++-- drivers/infiniband/ulp/ipoib/ipoib_ib.c | 89 -- drivers/infiniband/ulp/ipoib/ipoib_main.c|2 + drivers/infiniband/ulp/ipoib/ipoib_verbs.c |2 +- drivers/infiniband/ulp/iser/iser_verbs.c |2 +- drivers/infiniband/ulp/srp/ib_srp.c | 27 +++- drivers/infiniband/ulp/srp/ib_srp.h |1 + drivers/net/cxgb3/version.h |4 +- include/rdma/ib_verbs.h | 47 +++--- 40 files changed, 508 insertions(+), 239 deletions(-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] relay: use plain timer instead of delayed work
Patch updated to include changes suggested by Oleg Nesterov and Satyam
Sharma.
---
relay doesn't need to use schedule_delayed_work() for waking readers
when a simple timer will do.
Signed-off-by: Tom Zanussi <[EMAIL PROTECTED]>
---
include/linux/relay.h |3 ++-
kernel/relay.c| 35 ---
2 files changed, 18 insertions(+), 20 deletions(-)
diff --git a/include/linux/relay.h b/include/linux/relay.h
index 759a0f9..6cd8c44 100644
--- a/include/linux/relay.h
+++ b/include/linux/relay.h
@@ -12,6 +12,7 @@
#include
#include
+#include
#include
#include
#include
@@ -38,7 +39,7 @@ struct rchan_buf
size_t subbufs_consumed;/* count of sub-buffers consumed */
struct rchan *chan; /* associated channel */
wait_queue_head_t read_wait;/* reader wait queue */
- struct delayed_work wake_readers; /* reader wake-up work struct */
+ struct timer_list timer;/* reader wake-up timer */
struct dentry *dentry; /* channel file dentry */
struct kref kref; /* channel buffer refcount */
struct page **page_array; /* array of current buffer pages */
diff --git a/kernel/relay.c b/kernel/relay.c
index 577f251..e804589 100644
--- a/kernel/relay.c
+++ b/kernel/relay.c
@@ -310,16 +310,13 @@ static struct rchan_callbacks default_channel_callbacks =
{
/**
* wakeup_readers - wake up readers waiting on a channel
- * @work: work struct that contains the the channel buffer
+ * @data: contains the the channel buffer
*
- * This is the work function used to defer reader waking. The
- * reason waking is deferred is that calling directly from write
- * causes problems if you're writing from say the scheduler.
+ * This is the timer function used to defer reader waking.
*/
-static void wakeup_readers(struct work_struct *work)
+static void wakeup_readers(unsigned long data)
{
- struct rchan_buf *buf =
- container_of(work, struct rchan_buf, wake_readers.work);
+ struct rchan_buf *buf = (struct rchan_buf *)data;
wake_up_interruptible(>read_wait);
}
@@ -337,11 +334,9 @@ static void __relay_reset(struct rchan_buf *buf, unsigned
int init)
if (init) {
init_waitqueue_head(>read_wait);
kref_init(>kref);
- INIT_DELAYED_WORK(>wake_readers, NULL);
- } else {
- cancel_delayed_work(>wake_readers);
- flush_scheduled_work();
- }
+ setup_timer(>timer, wakeup_readers, (unsigned long)buf);
+ } else
+ del_timer_sync(>timer);
buf->subbufs_produced = 0;
buf->subbufs_consumed = 0;
@@ -447,8 +442,7 @@ end:
static void relay_close_buf(struct rchan_buf *buf)
{
buf->finalized = 1;
- cancel_delayed_work(>wake_readers);
- flush_scheduled_work();
+ del_timer_sync(>timer);
kref_put(>kref, relay_remove_buf);
}
@@ -608,11 +602,14 @@ size_t relay_switch_subbuf(struct rchan_buf *buf, size_t
length)
buf->dentry->d_inode->i_size += buf->chan->subbuf_size -
buf->padding[old_subbuf];
smp_mb();
- if (waitqueue_active(>read_wait)) {
- PREPARE_DELAYED_WORK(>wake_readers,
-wakeup_readers);
- schedule_delayed_work(>wake_readers, 1);
- }
+ if (waitqueue_active(>read_wait))
+ /*
+* Calling wake_up_interruptible() from here
+* will deadlock if we happen to be logging
+* from the scheduler (trying to re-grab
+* rq->lock), so defer it.
+*/
+ __mod_timer(>timer, jiffies + 1);
}
old = buf->data;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] relay: use plain timer instead of delayed work
On Sun, 2007-05-06 at 15:40 +0530, Satyam Sharma wrote: > Hi Tom, > > On 5/6/07, Tom Zanussi <[EMAIL PROTECTED]> wrote: > > [...] > > relay doesn't need to use schedule_delayed_work() for waking readers > > when a simple timer will do. > > > > Signed-off-by: Tom Zanussi <[EMAIL PROTECTED]> > > [...] > > diff --git a/include/linux/relay.h b/include/linux/relay.h > > index 759a0f9..cac0732 100644 > > --- a/include/linux/relay.h > > +++ b/include/linux/relay.h > > @@ -38,7 +38,7 @@ struct rchan_buf > > size_t subbufs_consumed;/* count of sub-buffers consumed */ > > struct rchan *chan; /* associated channel */ > > wait_queue_head_t read_wait;/* reader wait queue */ > > - struct delayed_work wake_readers; /* reader wake-up work struct */ > > + struct timer_list timer;/* reader wake-up timer */ > > struct dentry *dentry; /* channel file dentry */ > > struct kref kref; /* channel buffer refcount */ > > struct page **page_array; /* array of current buffer pages */ > > I suspect you could now safely get rid of the "#include > " at the top of relay.h too. And although timer.h comes > via #include , you might want to do that explicitly > too. > Hi Satyam, Thanks for your comments - I've updated the patch to include timer.h but wait.h would still be needed for wait_queue_head_t, so will leave that in. Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] relay: use plain timer instead of delayed work
On Sun, 2007-05-06 at 16:47 +0400, Oleg Nesterov wrote:
> On 05/05, Tom Zanussi wrote:
> >
> > This patch makes relay use timers instead of workqueues for reader
> > waking.
>
> A couple of very minor nits,
>
> > @@ -337,11 +334,11 @@ static void __relay_reset(struct rchan_buf *buf,
> > unsigned int init)
> > if (init) {
> > init_waitqueue_head(>read_wait);
> > kref_init(>kref);
> > - INIT_DELAYED_WORK(>wake_readers, NULL);
> > - } else {
> > - cancel_delayed_work(>wake_readers);
> > - flush_scheduled_work();
> > - }
> > + init_timer(>timer);
> > + buf->timer.data = (unsigned long)buf;
> > + buf->timer.function = wakeup_readers;
>
> I'd suggest to use setup_timer(>timer, wakeup_readers, buf);
>
> > @@ -609,9 +605,16 @@ size_t relay_switch_subbuf(struct rchan_buf *buf,
> > size_t length)
> > buf->padding[old_subbuf];
> > smp_mb();
> > if (waitqueue_active(>read_wait)) {
> > - PREPARE_DELAYED_WORK(>wake_readers,
> > -wakeup_readers);
> > - schedule_delayed_work(>wake_readers, 1);
> > + /*
> > +* Calling wake_up_interruptible() from here
> > +* will deadlock if we happen to be logging
> > +* from the scheduler (trying to re-grab
> > +* rq->lock), so defer it.
> > +*/
> > + if (!timer_pending(>timer)) {
> > + buf->timer.expires = jiffies + 1;
> > + add_timer(>timer);
> > + }
>
> I think it is better to use __mod_timer(>timer, jiffies + 1). In that
> case this "if (!timer_pending(>timer))" is not strictly needed, yes?
>
> Imho, add_timer() is almost never should be used. The only valid usage is when
> timer->expires was already set by somebody else.
>
> Btw, thanks for your explanation about deferred wakeup.
>
OK, and thanks for your helpful comments. Corrected patch to follow...
Tom
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Back to the future.
On May 06, 2007, at 22:13:51, David Lang wrote: anyone who is doing a hibernate or suspend who expect all the network connections to be working afterwords is dreaming or smokeing something. this is just another way that the failure can show up. in fact, I would say that it would probalby be a nice thing to do for intervening firewalls and external servers if a suspend closed all external TCP connections rather then leaving them dangling (eating up resources until they time out) if you software can't tolorate the network connection going away on you it will have problems in normal operation anyway, let alone when you suspend/hibernate your machine. Yeah, for suspend-to-ram+resume and for snapshot+restore you probably want userspace to support some kind of initscript-like mechanism which is triggered by the lid-switch or something before calling into the kernel. That way it can close network connections mostly-nicely and down network interfaces before suspending, then re-run DHCP/ 802.11/whatever configuration after resume/restore. That might not be a bad place to handle NFS mounts and such too. 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: get_user_pages vs mmap MAP_FIXED bug
On Mon, 07 May 2007 11:26:44 +1000 Rusty Russell <[EMAIL PROTECTED]> wrote: > On Sun, 2007-05-06 at 17:01 +1000, Rusty Russell wrote: > > This bug is in 2.6.21-rc7-mm2, but not 2.6.21. Haven't tested > > 2.6.21-mm1 yet. > > OK, 2.6.21-mm1 fails too. 2.6.21-git6 ... is fine. > > Here's a standalone test using ptrace. No kernel module req'd. > > [EMAIL PROTECTED]:~/linux-2.6.21-mm1$ ../examiner > ptrace says 0, child says 0x464c457f thanks. > Any clues Andrew? Or should I take your patches and do a binary search? I've been assuming that Nick's vm_operations.fault changes have broken get_user_pages()'s manual faulting. The next step is to wait for Nick to turn up. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Back to the future.
On Thu, 3 May 2007, Pavel Machek wrote: Hi! nobody is suggesting that you leave peocesses running while you do the snapshot, what is being proposed is 1. pause userspace (prevent scheduling) 2. make snapshot image of memory 3. make mounted filesystems read-only (possibly with snapshot/checkpoint) 4. unpause 5. save image (with full userspace available, including network) Including network? Your tcp peers will be really confused, then, if you ACK packets then claim you did not get them. No, you do not want to start network. anyone who is doing a hibernate or suspend who expect all the network connections to be working afterwords is dreaming or smokeing something. this is just another way that the failure can show up. in fact, I would say that it would probalby be a nice thing to do for intervening firewalls and external servers if a suspend closed all external TCP connections rather then leaving them dangling (eating up resources until they time out) if you software can't tolorate the network connection going away on you it will have problems in normal operation anyway, let alone when you suspend/hibernate your machine. 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: [PATCH] MM: implement MADV_FREE lazy freeing of anonymous memory
Rik van Riel wrote: I think that maybe for 2.6.22 we should just alias MADV_FREE to run with the MADV_DONTNEED functionality, so that the glibc people can make the change on their side while we figure out what will be the best thing to do on the kernel side. No need for that. We can later extend glibc to use MADV_FREE and fall back on MADV_DONTNEED. -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/7] [RFC] Common power driver for Linux gadgets
On Sun, May 06, 2007 at 06:39:27PM -0700, David Brownell wrote:
> On Thursday 12 April 2007, David Brownell wrote:
> > > This driver used to stop code/logic duplication through different
> > > machines we porting at handhelds.org. pda_power register machs' power
> > > supplies, and will take care about notifying batteries about power
> > > changes through external power interface.
> >
> > It gets USB power management wrong though. ...
>
> And that seems not to have been resolved in the version you
> reposted and then put into your GIT tree, either ... what's
> your plan for addressing the feedback, then?
pda_power have nothing to do with USB at all, as I've said. It
*monitors* MAINS/USB power supply state through *platform hooks*, and
platform hooks will do things as caring how much current to draw, if
charger used.
There is nothing wrong with pda_power. If you're hinting that for
pda_power we can use not some platform hooks, but some generic
USB/UDC/OTG/whatever api - okay, patches are welcome. I'm not usb
expert.
Please, speak code, not USB words. I don't understand USB language.
All I've understood, that we could not get as much current as we
want/expect from USB. And I believe you.
> > Key points:
> >
> > - The API needs to say *how much power* can be drawn. ...
> >
> > - Sensing VBUS power is not the same thing as being allowed to consume
> >it. Again, USB OTG devices are different...
> >
> > In general, no component other than the USB peripheral (or host) controller
> > driver has any business trying to control how VBUS power is used. It's
> > likely to get it wrong ... as shown by this patch. ;)
>
> I see on other LKML threads that folk are spreading misinformation
> about USB, like "no control signaling over USB for power control".
> I sincerly hope you're not believing that's correct!
And again, I believe you. But you're not helping.
> Plus, I'm wondering why this doesn't try to leverage the voltage
> framework that's been posted (to the ARM list, most recently).
(1)
> At some level there's not a lot different between saying "turn on
> the 3V3 supply to this MMC card slot, budgeting 80mA" and saying
> instead "let the system draw up to 200 mA from USB VBUS". The
> current goes in different directions in those examples, sure. Plus
> the usage of VBUS as a power _input_ is of course board-specific:
> battery charging, or powering specific circuits (like USB), etc.
>
> Then there are devices which _output_ power on VBUS of course ...
> so the only difference between that and the MMC example being how
> much of the power budget is consumed. Plus devices which either
> use VBUS as an input or an output, based on how they're hooked up.
>
> All of those are differences that seem to fit better into the notion
> of a general purpose voltage framework than this "power" thing
> you've provided. (Batter management being a separate issue.)
^^^ This
> Also that whole notion that there's only a handful of power "supplies"
> to manage ("ac", "main-battery", "usb") just flies in the face of
> how most boards actually work -- multiple voltage rails and switches,
> more types than battery/UPS/"AC"/USB, etc -- and the mechanisms needed
> to manage power when it's critical to eke out every last milliWatt.
And this ^^^ shows that you've completely misunderstood whole power
supply (was battery) class. This is mostly monitoring class, think of
hwmon. This class *monitors* what power supplies *attached* to the
board, monitors state of the power. Drivers to this class is mostly
*passive*.
pda_power is "active" in sense that it controls charger (usually
through one GPIO pin) via platform code. Not more.
And if some driver will want to be "active" (i.e. battery driver can
can control its voltage/current output), patches are welcome to do
(1), i.e. registering "voltage provider" inside power supply class.
> - Dave
Thanks,
--
Anton Vorontsov
email: [EMAIL PROTECTED]
backup email: [EMAIL PROTECTED]
irc://irc.freenode.org/bd2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Fix/add raw1394 CONFIG_COMPAT code
Hello Dan,
This patch makes raw1394 in current Linux git tree (2.6.21-1570) usable to 32bit
applications running on 64bit kernel (tested on i386 app using x86_64 kernel).
I
had to make following changes:
* read() always failed with -EFAULT. This was happening due to
raw1394_compat_read copying data to wrong location - access_ok always
failed as 'r' is kernel address, not user. Whole function just tried to
copy data from 'r' to 'r', which is not good.
* write(fd, buf, 52) from 32bit app was returning 56. Most of callers did not
care, but some (arm registration) did, and anyway it looks bad if request for
writing 52 bytes returns 56. And returning sizeof anything in 'int' is not
good as well. So all functions now return '0' instead of
sizeof(struct raw1394_request) on success, and write() itself provides correct
return value (it just returns value it was asked to write on success as
raw1394
does not do any partial writes at all).
* Related to this was problem that write() could have returned 0 when kernel
state would become corrupted and moved to different state than
opened/initialized/connected. Now it returns -EBADFD which seemed
appropriate.
* And add compat_ioctl. Although all structures are more or less same,
raw1394_iso_packets got pointer inside, and raw1394_cycle_timer got unwanted
padding in the middle. I did not add any translation for ioctls passing array
of integers around as integers seem to have same size (32 bits) on all
architectures supported by Linux.
With this in place I was able to run my test app and grab some mpegs, so I
believe
that I got everything necessary done. If you believe I have missed some ioctl,
yell
at me.
Thanks,
Petr Vandrovec
Signed-off-by: Petr Vandrovec <[EMAIL PROTECTED]>
diff -uprdN linux/drivers/ieee1394/raw1394.c linux/drivers/ieee1394/raw1394.c
--- linux/drivers/ieee1394/raw1394.c2007-05-06 17:45:47.0 -0700
+++ linux/drivers/ieee1394/raw1394.c2007-05-06 18:08:05.0 -0700
@@ -460,7 +460,7 @@ static const char __user *raw1394_compat
static int
raw1394_compat_read(const char __user *buf, struct raw1394_request *r)
{
- struct compat_raw1394_req __user *cr = (typeof(cr)) r;
+ struct compat_raw1394_req __user *cr = (typeof(cr)) buf;
if (!access_ok(VERIFY_WRITE, cr, sizeof(struct compat_raw1394_req)) ||
P(type) ||
P(error) ||
@@ -588,7 +588,7 @@ static int state_opened(struct file_info
req->req.length = 0;
queue_complete_req(req);
- return sizeof(struct raw1394_request);
+ return 0;
}
static int state_initialized(struct file_info *fi, struct pending_request *req)
@@ -602,7 +602,7 @@ static int state_initialized(struct file
req->req.generation = atomic_read(_generation);
req->req.length = 0;
queue_complete_req(req);
- return sizeof(struct raw1394_request);
+ return 0;
}
switch (req->req.type) {
@@ -674,7 +674,7 @@ out_set_card:
}
queue_complete_req(req);
- return sizeof(struct raw1394_request);
+ return 0;
}
static void handle_iso_listen(struct file_info *fi, struct pending_request
*req)
@@ -866,7 +866,7 @@ static int handle_async_request(struct f
if (req->req.error) {
req->req.length = 0;
queue_complete_req(req);
- return sizeof(struct raw1394_request);
+ return 0;
}
hpsb_set_packet_complete_task(packet,
@@ -884,7 +884,7 @@ static int handle_async_request(struct f
hpsb_free_tlabel(packet);
queue_complete_req(req);
}
- return sizeof(struct raw1394_request);
+ return 0;
}
static int handle_iso_send(struct file_info *fi, struct pending_request *req,
@@ -908,7 +908,7 @@ static int handle_iso_send(struct file_i
req->req.error = RAW1394_ERROR_MEMFAULT;
req->req.length = 0;
queue_complete_req(req);
- return sizeof(struct raw1394_request);
+ return 0;
}
req->req.length = 0;
@@ -928,7 +928,7 @@ static int handle_iso_send(struct file_i
queue_complete_req(req);
}
- return sizeof(struct raw1394_request);
+ return 0;
}
static int handle_async_send(struct file_info *fi, struct pending_request *req)
@@ -943,7 +943,7 @@ static int handle_async_send(struct file
req->req.error = RAW1394_ERROR_INVALID_ARG;
req->req.length = 0;
queue_complete_req(req);
- return sizeof(struct raw1394_request);
+ return 0;
}
packet = hpsb_alloc_packet(req->req.length - header_length);
@@ -956,7 +956,7 @@ static int handle_async_send(struct file
[GIT PULL] sh updates
Please pull from: master.kernel.org:/pub/scm/linux/kernel/git/lethal/sh-2.6.git Which contains: Kristoffer Ericson (3): sh: hp6xx driver compile fixes. sh: hp6xx pata_platform support. sh: Fix APM emulation on hp6xx. Nobuhiro Iwamatsu (7): sh: pata_platform pcmcia support for SolutionEngine boards. sh: L-BOX RE2 support. sh: MS7712SE01 board support. sh: Add defconfig for se7712. sh: SH7780 Solution Engine board support. sh: se7780 PCI support. sh: Solution Engine SH7705 board and CPU updates. Paul Mundt (20): sh: Bring kgdb back from the dead. sh: Rip out broken kgdb thread support. sh: speculative execution support for SH7780. sh: generic BUG() support. sh: NR_IRQS consolidation. sh: Add SH7785 Highlander board support (R7785RP). serial: sh-sci: Kill off breakpoint in break IRQ. doc: Update sysrq doc for sh kgdb trigger. sh: bootmem tidying for discontig/sparsemem preparation. sh: Kill off udivdi3 div64_32 wrapping. sh: Add defconfig for se7722. sh: Tidy up L-BOX area5 addresses. sh: Add a dummy SH-4 PCIC fixup. sh: Obey CONFIG_HZ for HZ definition. serial: sh-sci: Fix module clock refcount for serial console. sh: Move clock reporting to its own proc entry. sh: kdump support. sh: Fix r7780rp build. sh: Add die chain notifiers. sh: Update r7780rp defconfig. Ryusuke Sakato (2): sh: Solution Engine 7722 board support. sh: R7785RP board updates. SUGIOKA Toshinobu (1): sh: Fix fstatat64() syscall. Takashi YOSHII (2): sh: heartbeat double 0 fix. sh: Wire up more IRQs for SH7709. dmitry pervushin (2): sh: SH7722 clock framework support. serial: sh-sci: Fix module clock refcounting. kogiidena (1): sh: landisk updates. Documentation/sh/clk.txt | 32 + Documentation/sysrq.txt |4 +- arch/sh/Kconfig | 97 ++- arch/sh/Kconfig.debug| 20 +- arch/sh/Makefile |6 +- arch/sh/boards/hp6xx/Makefile|4 +- arch/sh/boards/hp6xx/setup.c | 67 +- arch/sh/boards/landisk/Makefile |2 +- arch/sh/boards/landisk/gio.c | 167 arch/sh/boards/landisk/io.c | 250 - arch/sh/boards/landisk/irq.c | 83 +-- arch/sh/boards/landisk/landisk_pwb.c | 346 --- arch/sh/boards/landisk/psw.c | 143 +++ arch/sh/boards/landisk/rtc.c | 91 -- arch/sh/boards/landisk/setup.c | 163 +--- arch/sh/boards/lboxre2/Makefile |5 + arch/sh/boards/lboxre2/irq.c | 31 + arch/sh/boards/lboxre2/setup.c | 85 ++ arch/sh/boards/renesas/r7780rp/Kconfig | 18 +- arch/sh/boards/renesas/r7780rp/Makefile |6 +- arch/sh/boards/renesas/r7780rp/irq-r7780rp.c | 21 + arch/sh/boards/renesas/r7780rp/irq-r7785rp.c | 29 + arch/sh/boards/renesas/r7780rp/irq.c | 25 +- arch/sh/boards/renesas/r7780rp/setup.c | 78 +- arch/sh/boards/se/770x/io.c |2 + arch/sh/boards/se/770x/irq.c | 57 +- arch/sh/boards/se/770x/setup.c | 30 +- arch/sh/boards/se/7722/Makefile | 10 + arch/sh/boards/se/7722/irq.c | 101 ++ arch/sh/boards/se/7722/setup.c | 148 +++ arch/sh/boards/se/7751/setup.c | 148 --- arch/sh/boards/se/7780/Makefile | 10 + arch/sh/boards/se/7780/irq.c | 89 ++ arch/sh/boards/se/7780/setup.c | 122 +++ arch/sh/configs/lboxre2_defconfig| 1271 arch/sh/configs/r7780rp_defconfig| 108 ++- arch/sh/configs/r7785rp_defconfig| 1334 ++ arch/sh/configs/se7705_defconfig | 106 ++- arch/sh/configs/se7712_defconfig | 1088 + arch/sh/configs/se7722_defconfig | 980 +++ arch/sh/configs/se7780_defconfig | 1309 + arch/sh/drivers/Kconfig | 10 + arch/sh/drivers/heartbeat.c | 13 +- arch/sh/drivers/pci/Makefile |5 +- arch/sh/drivers/pci/fixups-lboxre2.c | 41 + arch/sh/drivers/pci/fixups-se7780.c | 60 ++ arch/sh/drivers/pci/ops-landisk.c|4 +- arch/sh/drivers/pci/ops-lboxre2.c| 63 ++ arch/sh/drivers/pci/ops-r7780rp.c| 27 +- arch/sh/drivers/pci/ops-se7780.c | 96 ++ arch/sh/drivers/pci/ops-sh4.c|6 + arch/sh/drivers/pci/pci-sh4.h|2 +- arch/sh/drivers/pci/pci-sh7751.c | 15 +-
Re: [PATCH 1/1] nfsctl: Use vfs_path_lookup
On Sunday May 6, [EMAIL PROTECTED] wrote:
> use vfs_path_lookup instead of open-coding the necessary functionality.
>
> Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
Acked-by: NeilBrown <[EMAIL PROTECTED]>
Thanks,
NeilBrown
> ---
> fs/nfsctl.c | 16 ++--
> 1 files changed, 6 insertions(+), 10 deletions(-)
>
> diff --git a/fs/nfsctl.c b/fs/nfsctl.c
> index c043136..51f1b31 100644
> --- a/fs/nfsctl.c
> +++ b/fs/nfsctl.c
> @@ -23,19 +23,15 @@
> static struct file *do_open(char *name, int flags)
> {
> struct nameidata nd;
> + struct vfsmount *mnt;
> int error;
>
> - nd.mnt = do_kern_mount("nfsd", 0, "nfsd", NULL);
> + mnt = do_kern_mount("nfsd", 0, "nfsd", NULL);
> + if (IS_ERR(mnt))
> + return (struct file *)mnt;
>
> - if (IS_ERR(nd.mnt))
> - return (struct file *)nd.mnt;
> -
> - nd.dentry = dget(nd.mnt->mnt_root);
> - nd.last_type = LAST_ROOT;
> - nd.flags = 0;
> - nd.depth = 0;
> -
> - error = path_walk(name, );
> + error = vfs_path_lookup(mnt->mnt_root, mnt, name, 0, );
> + mntput(mnt);/* drop do_kern_mount reference */
> if (error)
> return ERR_PTR(error);
>
> --
> 1.5.2.rc1.20.g86b9
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] lguest: don't use paravirt_probe, it's dying
Rusty Russell <[EMAIL PROTECTED]> writes: > On Sat, 2007-05-05 at 13:22 +1000, Rusty Russell wrote: >> On Fri, 2007-05-04 at 20:53 -0600, Eric W. Biederman wrote: >> > Frankly I think the least risk of problems comes from just doing a >> > separate entry point for lguest for now. It means we don't even have >> > to touch the common code path and later dropping will be trivially >> > lguest specific, and certain to not break anything else. >> >> Hmm, I railed for so long against Xen doing that, it feels... wrong... >> to do that now 8) > > And here's the patch. It's pretty trivial actually. It even worked > first time. It applies against -mm (ie. before the "boot with P=V" > patches I showed before). > > Thanks! > Rusty. > == Looks fine to me. I'm not thrilled about grepping for a know ascii string in the kernel binary, to find the lguest entry point. But it is simple, and it's temporary so it looks fine. It clearly keeps us from having problems on the traditional x86 entry point. Acked-by: "Eric W. Biederman" <[EMAIL PROTECTED]> Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: regressions
On Sun, 6 May 2007 22:49:13 +0200 (MEST) [EMAIL PROTECTED] wrote: > 2.6.21 breaks HPT366 - back to 2.6.20 > 2.6.20 breaks ZIP - back to 2.6.19 > 2.6.19 seems OK at first sight > > [more info on request, this is well-known?] ZIP as in ZIP drive(r)? imm/ppa or IDE? imm breakage was reported and is fixed. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] WAN Kconfig: change "depends on HDLC" to "select"
Hi, On Mon, 7 May 2007, Krzysztof Halasa wrote: > Allow enabling WAN drivers without selecting generic HDLC first, > HDLC will be selected automatically. > > Signed-off-by: Krzysztof Halasa <[EMAIL PROTECTED]> > > diff --git a/drivers/net/wan/Kconfig b/drivers/net/wan/Kconfig > index 8897f53..3a2fe82 100644 > --- a/drivers/net/wan/Kconfig > +++ b/drivers/net/wan/Kconfig > @@ -171,7 +171,8 @@ comment "X.25/LAPB support is disabled" > > config PCI200SYN > tristate "Goramo PCI200SYN support" > - depends on HDLC && PCI > + depends on PCI > + select HDLC > help > Driver for PCI200SYN cards by Goramo sp. j. > What's the advantage? The HDLC option is directly before this? bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/7] [RFC] Common power driver for Linux gadgets
On Thursday 12 April 2007, David Brownell wrote:
> > This driver used to stop code/logic duplication through different
> > machines we porting at handhelds.org. pda_power register machs' power
> > supplies, and will take care about notifying batteries about power
> > changes through external power interface.
>
> It gets USB power management wrong though. ...
And that seems not to have been resolved in the version you
reposted and then put into your GIT tree, either ... what's
your plan for addressing the feedback, then?
> Key points:
>
> - The API needs to say *how much power* can be drawn. ...
>
> - Sensing VBUS power is not the same thing as being allowed to consume
>it. Again, USB OTG devices are different...
>
> In general, no component other than the USB peripheral (or host) controller
> driver has any business trying to control how VBUS power is used. It's
> likely to get it wrong ... as shown by this patch. ;)
I see on other LKML threads that folk are spreading misinformation
about USB, like "no control signaling over USB for power control".
I sincerly hope you're not believing that's correct!
Plus, I'm wondering why this doesn't try to leverage the voltage
framework that's been posted (to the ARM list, most recently).
At some level there's not a lot different between saying "turn on
the 3V3 supply to this MMC card slot, budgeting 80mA" and saying
instead "let the system draw up to 200 mA from USB VBUS". The
current goes in different directions in those examples, sure. Plus
the usage of VBUS as a power _input_ is of course board-specific:
battery charging, or powering specific circuits (like USB), etc.
Then there are devices which _output_ power on VBUS of course ...
so the only difference between that and the MMC example being how
much of the power budget is consumed. Plus devices which either
use VBUS as an input or an output, based on how they're hooked up.
All of those are differences that seem to fit better into the notion
of a general purpose voltage framework than this "power" thing
you've provided. (Batter management being a separate issue.)
Also that whole notion that there's only a handful of power "supplies"
to manage ("ac", "main-battery", "usb") just flies in the face of
how most boards actually work -- multiple voltage rails and switches,
more types than battery/UPS/"AC"/USB, etc -- and the mechanisms needed
to manage power when it's critical to eke out every last milliWatt.
- 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: RFC airo : wpa support
On Sat, 2007-05-05 at 00:52 +0200, matthieu castet wrote: > Hi, > > I attach a diff against 2.6.21 for adding wpa support for airo driver. > In then end of 2005 I manage to make work wpa but the code was really > ugly. I manage to find some time to clean it. > > > To support wpa, a new interface of the firmware should be used. This > interface is incompatible with the old interface and using both > interface at the same time make the firmware hang. > > Porting OPEN and WEP mode to new interface need some driver rewrite, and > the old interface should be keep for the older cards (or the cards that > doesn't have newer firmware). > That's why I didn't do it, and I added a module parameter for choosing > between the old driver behavior (with no wpa support) or the driver with > wpa only support. Nice, thanks for cleaning it up. However, having a module option for WPA vs. no WPA gets a big, big NAK from me. We need to be able to have it all co-exist. I'll see if I can clean it up and make the modes able to function in parallel. > The wireless extension handlers are a bit ugly, I will be very happy, if > somebody could help me to clean them. I can take a shot at it. Dan > Any comments are appreciated. > > > Matthieu > > > PS : the lastest version of the driver can be found in > http://svn.gna.org/viewcvs/airo-wpa/branches/kernel/ > > PS2 : There is some remaining trace in the driver for debug purpose, > that will be removed in the final version - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 03/10] sh: dma: use __attribute_unused__
On Tue, May 01, 2007 at 09:28:56PM -0700, David Rientjes wrote: > There is no such thing as labeling a variable as __attribute__((used)). > Since ts_shift is not referenced in inline assembly, we assume that we're > simply suppressing a warning here if the variable is declared but > unreferenced. > > Cc: Paul Mundt <[EMAIL PROTECTED]> > Signed-off-by: David Rientjes <[EMAIL PROTECTED]> 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/
Re: get_user_pages vs mmap MAP_FIXED bug
On Sun, 2007-05-06 at 17:01 +1000, Rusty Russell wrote:
> This bug is in 2.6.21-rc7-mm2, but not 2.6.21. Haven't tested
> 2.6.21-mm1 yet.
OK, 2.6.21-mm1 fails too. 2.6.21-git6 ... is fine.
Here's a standalone test using ptrace. No kernel module req'd.
[EMAIL PROTECTED]:~/linux-2.6.21-mm1$ ../examiner
ptrace says 0, child says 0x464c457f
Any clues Andrew? Or should I take your patches and do a binary search?
Cheers,
Rusty.
/* Make with gcc -o examine_mmap examine_mmap.c */
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
/* Compare ptrace (ie. get_user_pages()) result with what process
* actually sees. */
int main(int argc, char *argv[])
{
long int *p, res1, res2;
int fd, child;
int child2parent[2], parent2child[2];
char c = 0;
pipe(child2parent);
pipe(parent2child);
if ((child = fork()) == 0) {
/* Grab some file to mmap. */
fd = open(argv[0], O_RDONLY);
if (fd < 0)
err(1, "open");
/* Map one page of it at 4096 */
p = (void *)4096;
if (mmap(p, 4096, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED, fd, 0) != p)
err(1, "mmap");
/* This makes it work. */
if (argc > 1 && strcmp(argv[1], "--touch") == 0)
printf("Before: %p == %li\n", p, *p);
/* Allow parent to trace me. */
if (ptrace(PTRACE_TRACEME, 0, 0, 0) != 0)
err(1, "PTRACE_TRACEME");
/* Tell parent to look at memory, and wait for response. */
write(child2parent[1], , 1);
read(parent2child[0], , 1);
/* Write what we see to pipe */
write(child2parent[1], p, sizeof(*p));
exit(0);
}
/* Wait for child to be ready. */
read(child2parent[0], , 1);
/* Child needs to be stopped. What a POS. */
kill(child, SIGSTOP);
sleep(1);
/* Get ptrace to tell us what the kernel thinks the value is */
res1 = ptrace(PTRACE_PEEKDATA, child, (void *)4096, NULL);
/* Continue the child. */
ptrace(PTRACE_DETACH, child, NULL, NULL);
/* Tell the child to continue. */
write(parent2child[1], , 1);
/* Get the child's opinion of what the value is. */
read(child2parent[0], , sizeof(res2));
printf("ptrace says %#lx, child says %#lx\n", res1, res2);
exit(res1 == res2 ? 0 : 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]: linux-2.6.21-uc0 (MMU-less updates)
On Thu, May 03, 2007 at 11:30:53PM +1000, Greg Ungerer wrote: > Robin Getz wrote: > >>Its not an architecture problem. It can effect any board that > >>has RAM mapped at a large numerical addresses (larger than TASK_SIZE). > >>So it can effect any non-MMU platform. > > > >Depending on how TASK_SIZE is defined - it looks like everyone else forces > >it to end of memory, except 68k[nommu]. > > > >asm-arm/memory.h:#define TASK_SIZE (CONFIG_DRAM_SIZE) > >asm-blackfin/processor.h:#define TASK_SIZE (memory_end) > >asm-frv/mem-layout.h:#define TASK_SIZE __UL(0xUL) > > > >asm-m68k/processor.h:#define TASK_SIZE (0xF000UL) > >asm-m68k/processor.h:#define TASK_SIZE (0x0E00) > >asm-m68k/processor.h:#define TASK_SIZE (0x0E00UL) > >asm-m68knommu/processor.h:#define TASK_SIZE (0xF000UL) > > Probably too: > > asm-sh/processor.h:#define TASK_SIZE0x7c00UL > > which has some parts with MMU. > > There have been others out of tree that have it like this to. > It would be at 0x8000UL on SH if it weren't for address space area limitations. The 0x7c00 - 0x7fff space is used for shadowing P4 registers in the virtual address space (area 7) with the MMU and it's a reserved area without the MMU, so TASK_SIZE is trimmed right before this. However, I'm not sure that the patch Greg has in this set is sufficient for the problem described. do_mmap_pgoff() won't allow a > TASK_SIZE mapping anyways. In the SH case we certainly have address spaces that can be given user permissions well above TASK_SIZE, area 7 space is used as a bit of a hack for some of this in the MMU case.. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] lguest: use standard bootloader format, fix badly-sized initrds
Eric Biederman complained that lguest doesn't use the Linux standard
boot header format. He's got a good point.
This also simplifies the code: the example launcher writes the header
directly, rather than lguest writing into it during boot.
While we're touching this code, we also fix the problem of initrd's
which don't have a page-aligned size.
This anticipates changing the paravirt-finding routines to use a
"platform type" field from %esi, rather than a "probe all until one
succeeds" routine, but doesn't actually change that code.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
---
Documentation/lguest/lguest.c | 50 ---
drivers/lguest/lguest.c | 22 +++--
drivers/lguest/lguest_asm.S |5 +++
drivers/lguest/lguest_user.c|4 ---
include/linux/lguest.h |5 ---
include/linux/lguest_launcher.h |8 --
6 files changed, 46 insertions(+), 48 deletions(-)
===
--- a/Documentation/lguest/lguest.c
+++ b/Documentation/lguest/lguest.c
@@ -30,10 +30,12 @@
#include
#include
#include
+typedef unsigned long long u64;
typedef uint32_t u32;
typedef uint16_t u16;
typedef uint8_t u8;
#include "../../include/linux/lguest_launcher.h"
+#include "../../include/asm-i386/e820.h"
#define PAGE_PRESENT 0x7 /* Present, RW, Execute */
#define NET_PEERNUM 1
@@ -241,31 +243,33 @@ static unsigned long load_kernel(int fd,
return load_bzimage(fd, page_offset);
}
+static inline unsigned long page_align(unsigned long addr)
+{
+ return ((addr + getpagesize()-1) & ~(getpagesize()-1));
+}
+
/* initrd gets loaded at top of memory: return length. */
static unsigned long load_initrd(const char *name, unsigned long mem)
{
int ifd;
struct stat st;
+ unsigned long len;
void *iaddr;
ifd = open_or_die(name, O_RDONLY);
if (fstat(ifd, ) < 0)
err(1, "fstat() on initrd '%s'", name);
- iaddr = mmap((void *)mem - st.st_size, st.st_size,
+ len = page_align(st.st_size);
+ iaddr = mmap((void *)mem - len, st.st_size,
PROT_READ|PROT_EXEC|PROT_WRITE,
MAP_FIXED|MAP_PRIVATE, ifd, 0);
- if (iaddr != (void *)mem - st.st_size)
+ if (iaddr != (void *)mem - len)
err(1, "Mmaping initrd '%s' returned %p not %p",
- name, iaddr, (void *)mem - st.st_size);
+ name, iaddr, (void *)mem - len);
close(ifd);
verbose("mapped initrd %s size=%lu @ %p\n", name, st.st_size, iaddr);
- return st.st_size;
-}
-
-static inline unsigned long page_align(unsigned long addr)
-{
- return ((addr + getpagesize()-1) & ~(getpagesize()-1));
+ return len;
}
static unsigned long setup_pagetables(unsigned long mem,
@@ -933,10 +937,10 @@ static void usage(void)
int main(int argc, char *argv[])
{
- unsigned long mem, pgdir, start, page_offset;
+ unsigned long mem, pgdir, start, page_offset, initrd_size = 0;
int c, lguest_fd, waker_fd;
struct device_list device_list;
- struct lguest_boot_info *boot = (void *)0;
+ void *boot = (void *)0;
const char *initrd_name = NULL;
device_list.max_infd = -1;
@@ -984,15 +988,25 @@ int main(int argc, char *argv[])
map_device_descriptors(_list, mem);
/* Map the initrd image if requested */
- if (initrd_name)
- boot->initrd_size = load_initrd(initrd_name, mem);
+ if (initrd_name) {
+ initrd_size = load_initrd(initrd_name, mem);
+ *(unsigned long *)(boot+0x218) = mem - initrd_size;
+ *(unsigned long *)(boot+0x21c) = initrd_size;
+ *(unsigned char *)(boot+0x210) = 0xFF;
+ }
/* Set up the initial linar pagetables. */
- pgdir = setup_pagetables(mem, boot->initrd_size, page_offset);
-
- /* Give the guest the boot information it needs. */
- concat(boot->cmdline, argv+optind+2);
- boot->max_pfn = mem/getpagesize();
+ pgdir = setup_pagetables(mem, initrd_size, page_offset);
+
+ /* E820 memory map: ours is a simple, single region. */
+ *(char*)(boot+E820NR) = 1;
+ *((struct e820entry *)(boot+E820MAP))
+ = ((struct e820entry) { 0, mem, E820_RAM });
+ /* Command line pointer and command line (at 4096) */
+ *(void **)(boot + 0x228) = boot + 4096;
+ concat(boot + 4096, argv+optind+2);
+ /* Paravirt type: 1 == lguest */
+ *(int *)(boot + 0x23c) = 1;
lguest_fd = tell_kernel(pgdir, start, page_offset);
waker_fd = setup_waker(_list);
===
--- a/drivers/lguest/lguest.c
+++ b/drivers/lguest/lguest.c
@@ -52,7 +52,6 @@ struct lguest_data lguest_data = {
.blocked_interrupts = { 1 }, /* Block timer interrupts */
};
[PATCH 3/3] lguest: 2.6.21-mm1 update: lguest-net-stats-inline.patch
Now inline net_device_stats is upstream, we can use it in the lguest
net driver.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
---
drivers/net/lguest_net.c | 20 +---
1 file changed, 5 insertions(+), 15 deletions(-)
===
--- a/drivers/net/lguest_net.c
+++ b/drivers/net/lguest_net.c
@@ -38,8 +38,6 @@ struct lguestnet_info
/* My peerid. */
unsigned int me;
- struct net_device_stats stats;
-
/* Receive queue. */
struct sk_buff *skb[NUM_SKBS];
struct lguest_dma dma[NUM_SKBS];
@@ -120,13 +118,13 @@ static void transfer_packet(struct net_d
hcall(LHCALL_SEND_DMA, peer_key(info,peernum), __pa(), 0);
if (dma.used_len != skb->len) {
- info->stats.tx_carrier_errors++;
+ dev->stats.tx_carrier_errors++;
pr_debug("Bad xfer to peer %i: %i of %i (dma %p/%i)\n",
peernum, dma.used_len, skb->len,
(void *)dma.addr[0], dma.len[0]);
} else {
- info->stats.tx_bytes += skb->len;
- info->stats.tx_packets++;
+ dev->stats.tx_bytes += skb->len;
+ dev->stats.tx_packets++;
}
}
@@ -212,8 +210,8 @@ static irqreturn_t lguestnet_rcv(int irq
pr_debug("Receiving skb proto 0x%04x len %i type %i\n",
ntohs(skb->protocol), skb->len, skb->pkt_type);
- info->stats.rx_bytes += skb->len;
- info->stats.rx_packets++;
+ dev->stats.rx_bytes += skb->len;
+ dev->stats.rx_packets++;
netif_rx(skb);
}
return done ? IRQ_HANDLED : IRQ_NONE;
@@ -258,13 +256,6 @@ static int lguestnet_close(struct net_de
for (i = 0; i < ARRAY_SIZE(info->dma); i++)
dev_kfree_skb(info->skb[i]);
return 0;
-}
-
-static struct net_device_stats *lguestnet_get_stats(struct net_device *dev)
-{
- struct lguestnet_info *info = dev->priv;
-
- return >stats;
}
static int lguestnet_probe(struct lguest_device *lgdev)
@@ -295,7 +286,6 @@ static int lguestnet_probe(struct lguest
dev->open = lguestnet_open;
dev->stop = lguestnet_close;
dev->hard_start_xmit = lguestnet_start_xmit;
- dev->get_stats = lguestnet_get_stats;
/* Turning on/off promisc will call dev->set_multicast_list.
* We don't actually support multicast yet */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] lguest: 2.6.21-mm1 update: lguest-remove-unnecessary-gdt-load.patch
Andrew did a great job of merging in the PDA->percpu changes and
lguest code for 2.6.21-mm1, but the load_gdt is now unnecessary.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
---
drivers/lguest/lguest.c |4
1 file changed, 4 deletions(-)
===
--- a/drivers/lguest/lguest.c
+++ b/drivers/lguest/lguest.c
@@ -409,9 +409,6 @@ static unsigned lguest_patch(u8 type, u1
memcpy(insns, lguest_insns[type].start, insn_len);
return insn_len;
}
-
-/* From head.S */
-extern struct Xgt_desc_struct early_gdt_descr;
__init void lguest_init(void)
{
@@ -468,7 +465,6 @@ __init void lguest_init(void)
/* We use top of mem for initial pagetables. */
init_pg_tables_end = __pa(pg0);
- load_gdt(_gdt_descr);
asm volatile ("mov %0, %%fs" : : "r" (__KERNEL_DS) : "memory");
reserve_top_address(lguest_data.reserve_mem);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] lguest: 2.6.21-mm1 update: lguest-magic-signature.patch
paravirt_probe() and its infrastructure proved as popular as it was
pretty. In anticipation of its imminent demise, this switches lguest to
use a magic string to identify a different entry point.
This is not the long-term solution: that will take a new bootloader rev
and will hopefully be done in the next few months.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
---
Documentation/lguest/lguest.c | 25 +
drivers/lguest/lguest.c |2 --
drivers/lguest/lguest_asm.S | 23 +--
3 files changed, 30 insertions(+), 20 deletions(-)
===
--- a/Documentation/lguest/lguest.c
+++ b/Documentation/lguest/lguest.c
@@ -96,6 +96,19 @@ static void *map_zeroed_pages(unsigned l
return (void *)addr;
}
+/* Find magic string marking entry point, return entry point. */
+static unsigned long entry_point(void *start, void *end,
+unsigned long page_offset)
+{
+ void *p;
+
+ for (p = start; p < end; p++)
+ if (memcmp(p, "GenuineLguest", strlen("GenuineLguest")) == 0)
+ return (long)p + strlen("GenuineLguest") + page_offset;
+
+ err(1, "Is this image a genuine lguest?");
+}
+
/* Returns the entry point */
static unsigned long map_elf(int elf_fd, const Elf32_Ehdr *ehdr,
unsigned long *page_offset)
@@ -103,6 +116,7 @@ static unsigned long map_elf(int elf_fd,
void *addr;
Elf32_Phdr phdr[ehdr->e_phnum];
unsigned int i;
+ unsigned long start = -1UL, end = 0;
/* Sanity checks. */
if (ehdr->e_type != ET_EXEC
@@ -131,6 +145,11 @@ static unsigned long map_elf(int elf_fd,
*page_offset = phdr[i].p_vaddr - phdr[i].p_paddr;
else if (*page_offset != phdr[i].p_vaddr - phdr[i].p_paddr)
errx(1, "Page offset of section %i different", i);
+
+ if (phdr[i].p_paddr < start)
+ start = phdr[i].p_paddr;
+ if (phdr[i].p_paddr + phdr[i].p_filesz > end)
+ end = phdr[i].p_paddr + phdr[i].p_filesz;
/* We map everything private, writable. */
addr = mmap((void *)phdr[i].p_paddr,
@@ -143,8 +162,7 @@ static unsigned long map_elf(int elf_fd,
i, addr, (void *)phdr[i].p_paddr);
}
- /* Entry is physical address: convert to virtual */
- return ehdr->e_entry + *page_offset;
+ return entry_point((void *)start, (void *)end, *page_offset);
}
/* This is amazingly reliable. */
@@ -175,8 +193,7 @@ static unsigned long unpack_bzimage(int
verbose("Unpacked size %i addr %p\n", len, img);
*page_offset = intuit_page_offset(img, len);
- /* Entry is physical address: convert to virtual */
- return (unsigned long)img + *page_offset;
+ return entry_point(img, img + len, *page_offset);
}
static unsigned long load_bzimage(int fd, unsigned long *page_offset)
===
--- a/drivers/lguest/lguest.c
+++ b/drivers/lguest/lguest.c
@@ -43,7 +43,6 @@ extern const char lgstart_popf[], lgend_
extern const char lgstart_popf[], lgend_popf[];
extern const char lgstart_pushf[], lgend_pushf[];
extern const char lgstart_iret[], lgend_iret[];
-extern asmlinkage void lguest_maybe_init(void);
extern void lguest_iret(void);
struct lguest_data lguest_data = {
@@ -497,4 +496,3 @@ __init void lguest_init(void)
pm_power_off = lguest_power_off;
start_kernel();
}
-paravirt_probe(lguest_maybe_init);
===
--- a/drivers/lguest/lguest_asm.S
+++ b/drivers/lguest/lguest_asm.S
@@ -1,29 +1,24 @@
#include
#include
#include
+#include
/* FIXME: Once asm/processor-flags.h goes in, include that */
#define X86_EFLAGS_IF 0x0200
/*
- * This is where we begin: head.S notes that paging is already enabled (which
- * doesn't happen in native boot) and calls the registered paravirt_probe
- * functions one at a time. Ours is a simple assembler test for magic
- * registers. If they're correct we jump to lguest_init.
+ * This is where we begin: we have a magic signature which the launcher looks
+ * for. The plan is that the Linux boot protocol will be extended with a
+ * "platform type" field which will guide us here from the normal entry point,
+ * but for the moment this suffices.
*
* We put it in .init.text will be discarded after boot.
*/
.section .init.text, "ax", @progbits
-ENTRY(lguest_maybe_init)
- cmpl $LGUEST_MAGIC_EBP, %ebp
- jne out
- cmpl $LGUEST_MAGIC_EDI, %edi
- jne out
- cmpl $LGUEST_MAGIC_ESI, %esi
- jne out
- je lguest_init
-out:
- ret
+.ascii "GenuineLguest"
+ /* Set up initial stack. */
+ movl
Re: ChunkFS - measuring cross-chunk references
On Mon, Apr 23, 2007 at 02:05:47AM +0530, Karuna sagar K wrote: > Hi, > > The attached code contains program to estimate the cross-chunk > references for ChunkFS file system (idea from Valh). Below are the > results: Nice work! Thank you very much for doing this! -VAL - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ChunkFS - measuring cross-chunk references
On Mon, Apr 23, 2007 at 02:53:33PM -0600, Andreas Dilger wrote: > > Also, is it considered a cross-chunk reference if a directory entry is > referencing an inode in another group? Should there be a continuation > inode in the local group, or is the directory entry itself enough? (Sorry for the delay; just moved to Portland these last couple of weeks.) It is a cross-chunk reference - we can't calculate the correct link count for the target file unless we have a quick way to get all the directory entries pointing to an inode. My current scheme is to create a continuation inode for the directory in the chunk containing the inode (if the chunk containing the inode is full, create new continuation inodes for both in a new chunk). -VAL - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: regressions
[EMAIL PROTECTED] wrote: 2.6.21 breaks HPT366 - back to 2.6.20 I thought Bart/Sergei had fixed this. Are you using libata or old-IDE driver? 2.6.20 breaks ZIP - back to 2.6.19 What does this mean? How is it broken? 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: kconfig: error out if recursive dependencies are found
Hi,
On Sun, 6 May 2007, Sam Ravnborg wrote:
> if (sym->flags & SYMBOL_CHECK) {
> - printf("Warning! Found recursive dependency: %s", sym->name);
> + fprintf(stderr, "%s:%d:error: found recursive dependency: %s",
> + sym->prop->file->name, sym->prop->lineno, sym->name);
> return sym;
> }
If it were that simple to print the location, I had done it already. :)
Try this:
config FOO
bool
select BAR
depends on BAR
config BAR
bool
I looked into this before, for simple properties one could just remember
the last checked property via a static variable. The problem are the
selects which are checked before that loop, here the information from
where they were selected is not available anymore (at least not easily).
bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 007 of 8] knfsd: Various nfsd xdr cleanups.
1/ decode_sattr and decode_sattr3 never return NULL, so remove
several checks for that. ditto for xdr_decode_hyper.
2/ replace some open coded XDR_QUADLEN calls with calls to
XDR_QUADLEN
3/ in decode_writeargs, simply an 'if' to use a single
calculation.
.page_len is the length of that part of the packet that did
not fit in the first page (the head).
So the length of the data part is the remainder of the
head, plus page_len.
3/ other minor cleanups.
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./fs/nfsd/nfs3xdr.c | 55 ++--
./fs/nfsd/nfsxdr.c | 39 +---
2 files changed, 34 insertions(+), 60 deletions(-)
diff .prev/fs/nfsd/nfs3xdr.c ./fs/nfsd/nfs3xdr.c
--- .prev/fs/nfsd/nfs3xdr.c 2007-05-07 10:30:15.0 +1000
+++ ./fs/nfsd/nfs3xdr.c 2007-05-07 10:31:05.0 +1000
@@ -239,7 +239,7 @@ static __be32 *
encode_post_op_attr(struct svc_rqst *rqstp, __be32 *p, struct svc_fh *fhp)
{
struct dentry *dentry = fhp->fh_dentry;
- if (dentry && dentry->d_inode != NULL) {
+ if (dentry && dentry->d_inode) {
int err;
struct kstat stat;
@@ -300,9 +300,9 @@ int
nfs3svc_decode_sattrargs(struct svc_rqst *rqstp, __be32 *p,
struct nfsd3_sattrargs *args)
{
- if (!(p = decode_fh(p, >fh))
-|| !(p = decode_sattr3(p, >attrs)))
+ if (!(p = decode_fh(p, >fh)))
return 0;
+ p = decode_sattr3(p, >attrs);
if ((args->check_guard = ntohl(*p++)) != 0) {
struct timespec time;
@@ -343,9 +343,9 @@ nfs3svc_decode_readargs(struct svc_rqst
int v,pn;
u32 max_blocksize = svc_max_payload(rqstp);
- if (!(p = decode_fh(p, >fh))
-|| !(p = xdr_decode_hyper(p, >offset)))
+ if (!(p = decode_fh(p, >fh)))
return 0;
+ p = xdr_decode_hyper(p, >offset);
len = args->count = ntohl(*p++);
@@ -372,9 +372,9 @@ nfs3svc_decode_writeargs(struct svc_rqst
unsigned int len, v, hdr, dlen;
u32 max_blocksize = svc_max_payload(rqstp);
- if (!(p = decode_fh(p, >fh))
-|| !(p = xdr_decode_hyper(p, >offset)))
+ if (!(p = decode_fh(p, >fh)))
return 0;
+ p = xdr_decode_hyper(p, >offset);
args->count = ntohl(*p++);
args->stable = ntohl(*p++);
@@ -388,29 +388,16 @@ nfs3svc_decode_writeargs(struct svc_rqst
/*
* Check to make sure that we got the right number of
* bytes.
-*
-* If more than one page was used, then compute the length
-* of the data in the request as the total size of the
-* request minus the transport protocol headers minus the
-* RPC protocol headers minus the NFS protocol fields
-* already consumed. If the request fits into a single
-* page, then compete the length of the data as the size
-* of the NFS portion of the request minus the NFS
-* protocol fields already consumed.
*/
hdr = (void*)p - rqstp->rq_arg.head[0].iov_base;
- if (rqstp->rq_respages != rqstp->rq_pages + 1) {
- dlen = rqstp->rq_arg.len -
- (PAGE_SIZE - rqstp->rq_arg.head[0].iov_len) - hdr;
- } else {
- dlen = rqstp->rq_arg.head[0].iov_len - hdr;
- }
+ dlen = rqstp->rq_arg.head[0].iov_len + rqstp->rq_arg.page_len
+ - hdr;
/*
* Round the length of the data which was specified up to
* the next multiple of XDR units and then compare that
* against the length which was actually received.
*/
- if (dlen != ((len + 3) & ~0x3))
+ if (dlen != XDR_QUADLEN(len)*4)
return 0;
if (args->count > max_blocksize) {
@@ -442,8 +429,7 @@ nfs3svc_decode_createargs(struct svc_rqs
switch (args->createmode = ntohl(*p++)) {
case NFS3_CREATE_UNCHECKED:
case NFS3_CREATE_GUARDED:
- if (!(p = decode_sattr3(p, >attrs)))
- return 0;
+ p = decode_sattr3(p, >attrs);
break;
case NFS3_CREATE_EXCLUSIVE:
args->verf = p;
@@ -459,10 +445,10 @@ int
nfs3svc_decode_mkdirargs(struct svc_rqst *rqstp, __be32 *p,
struct nfsd3_createargs *args)
{
- if (!(p = decode_fh(p, >fh))
-|| !(p = decode_filename(p, >name, >len))
-|| !(p = decode_sattr3(p, >attrs)))
+ if (!(p = decode_fh(p, >fh)) ||
+ !(p = decode_filename(p, >name, >len)))
return 0;
+ p = decode_sattr3(p, >attrs);
return xdr_argsize_check(rqstp, p);
}
@@ -476,11 +462,12 @@ nfs3svc_decode_symlinkargs(struct svc_rq
char *old, *new;
struct kvec *vec;
- if (!(p = decode_fh(p, >ffh))
-|| !(p =
[PATCH 008 of 8] knfsd: Avoid Oops if buggy userspace performs confusing filehandle->dentry mapping.
When a lookup request arrives, nfsd uses information provided by
userspace (mountd) to find the right filesystem.
It then assumes that the same filehandle type as the incoming filehandle
can be used to create an outgoing filehandle.
However if mountd is buggy, or maybe just being creative, the filesystem
may not support that filesystem type, and the kernel could oops, particularly
if 'ex_uuid' is NULL but a FSID_UUID* filehandle type is used.
So add some proper checking that the fsid version/type from the
incoming filehandle is actually supportable, and ignore that information
if it isn't supportable.
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./fs/nfsd/nfsfh.c | 56 --
1 file changed, 50 insertions(+), 6 deletions(-)
diff .prev/fs/nfsd/nfsfh.c ./fs/nfsd/nfsfh.c
--- .prev/fs/nfsd/nfsfh.c 2007-05-07 10:30:13.0 +1000
+++ ./fs/nfsd/nfsfh.c 2007-05-07 10:31:05.0 +1000
@@ -323,7 +323,7 @@ fh_compose(struct svc_fh *fhp, struct sv
*
*/
- u8 version = 1;
+ u8 version;
u8 fsid_type = 0;
struct inode * inode = dentry->d_inode;
struct dentry *parent = dentry->d_parent;
@@ -341,15 +341,59 @@ fh_compose(struct svc_fh *fhp, struct sv
* the reference filehandle (if it is in the same export)
* or the export options.
*/
+ retry:
+ version = 1;
if (ref_fh && ref_fh->fh_export == exp) {
version = ref_fh->fh_handle.fh_version;
- if (version == 0xca)
+ fsid_type = ref_fh->fh_handle.fh_fsid_type;
+
+ if (ref_fh == fhp)
+ fh_put(ref_fh);
+ ref_fh = NULL;
+
+ switch (version) {
+ case 0xca:
fsid_type = FSID_DEV;
- else
- fsid_type = ref_fh->fh_handle.fh_fsid_type;
- /* We know this version/type works for this export
-* so there is no need for further checks.
+ break;
+ case 1:
+ break;
+ default:
+ goto retry;
+ }
+
+ /* Need to check that this type works for this
+* export point. As the fsid -> filesystem mapping
+* was guided by user-space, there is no guarantee
+* that the filesystem actually supports that fsid
+* type. If it doesn't we loop around again without
+* ref_fh set.
*/
+ switch(fsid_type) {
+ case FSID_DEV:
+ if (!old_valid_dev(ex_dev))
+ goto retry;
+ /* FALL THROUGH */
+ case FSID_MAJOR_MINOR:
+ case FSID_ENCODE_DEV:
+ if (!(exp->ex_dentry->d_inode->i_sb->s_type->fs_flags
+ & FS_REQUIRES_DEV))
+ goto retry;
+ break;
+ case FSID_NUM:
+ if (! (exp->ex_flags & NFSEXP_FSID))
+ goto retry;
+ break;
+ case FSID_UUID8:
+ case FSID_UUID16:
+ if (!root_export)
+ goto retry;
+ /* fall through */
+ case FSID_UUID4_INUM:
+ case FSID_UUID16_INUM:
+ if (exp->ex_uuid == NULL)
+ goto retry;
+ break;
+ }
} else if (exp->ex_uuid) {
if (fhp->fh_maxsize >= 64) {
if (root_export)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 003 of 8] knfsd: Fix resource leak resulting in module refcount leak for rpcsec_gss_krb5.ko
From: Frank Filz <[EMAIL PROTECTED]>
I have been investigating a module reference count leak on the server
for rpcsec_gss_krb5.ko. It turns out the problem is a reference count
leak for the security context in net/sunrpc/auth_gss/svcauth_gss.c.
The problem is that gss_write_init_verf() calls gss_svc_searchbyctx()
which does a rsc_lookup() but never releases the reference to the
context. There is another issue that rpc.svcgssd sets an "end of time"
expiration for the context
By adding a cache_put() call in gss_svc_searchbyctx(), and setting an
expiration timeout in the downcall, cache_clean() does clean up the
context and the module reference count now goes to zero after unmount.
I also verified that if the context expires and then the client makes a
new request, a new context is established.
Here is the patch to fix the kernel, I will start a separate thread to
discuss what expiration time should be set by rpc.svcgssd.
Acked-by: "J. Bruce Fields" <[EMAIL PROTECTED]>
Signed-off-by: Frank Filz <[EMAIL PROTECTED]>
diff --git a/net/sunrpc/auth_gss/svcauth_gss.c
b/net/sunrpc/auth_gss/svcauth_gss.c
index db298b5..eb16e30 100644
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./net/sunrpc/auth_gss/svcauth_gss.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff .prev/net/sunrpc/auth_gss/svcauth_gss.c ./net/sunrpc/auth_gss/svcauth_gss.c
--- .prev/net/sunrpc/auth_gss/svcauth_gss.c 2007-05-07 10:30:38.0
+1000
+++ ./net/sunrpc/auth_gss/svcauth_gss.c 2007-05-07 10:31:03.0 +1000
@@ -938,6 +938,7 @@ static inline int
gss_write_init_verf(struct svc_rqst *rqstp, struct rsi *rsip)
{
struct rsc *rsci;
+ intrc;
if (rsip->major_status != GSS_S_COMPLETE)
return gss_write_null_verf(rqstp);
@@ -946,7 +947,9 @@ gss_write_init_verf(struct svc_rqst *rqs
rsip->major_status = GSS_S_NO_CONTEXT;
return gss_write_null_verf(rqstp);
}
- return gss_write_verf(rqstp, rsci->mechctx, GSS_SEQ_WIN);
+ rc = gss_write_verf(rqstp, rsci->mechctx, GSS_SEQ_WIN);
+ cache_put(>h, _cache);
+ return rc;
}
/*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 004 of 8] knfsd: rpcgss : RPC_GSS_PROC_ DESTROY request will get a bad rpc
From: Wei Yongjun <[EMAIL PROTECTED]> If I send a RPC_GSS_PROC_DESTROY message to NFSv4 server, it will reply with a bad rpc reply which lacks an authentication verifier. Maybe this patch is needed. Send/recv packets as following: send: RemoteProcedureCall xid rpcvers = 2 prog = 13 vers = 4 proc = 0 cred = AUTH_GSS version = 1 gss_proc = 3 (RPCSEC_GSS_DESTROY) service = 1 (RPC_GSS_SVC_NONE) verf = AUTH_GSS checksum reply: RemoteProcedureReply xid msg_type reply_stat accepted_reply Signed-off-by: Wei Yongjun <[EMAIL PROTECTED]> Signed-off-by: "J. Bruce Fields" <[EMAIL PROTECTED]> Signed-off-by: Neil Brown <[EMAIL PROTECTED]> ### Diffstat output ./net/sunrpc/auth_gss/svcauth_gss.c |2 ++ 1 file changed, 2 insertions(+) diff .prev/net/sunrpc/auth_gss/svcauth_gss.c ./net/sunrpc/auth_gss/svcauth_gss.c --- .prev/net/sunrpc/auth_gss/svcauth_gss.c 2007-05-07 10:31:03.0 +1000 +++ ./net/sunrpc/auth_gss/svcauth_gss.c 2007-05-07 10:31:04.0 +1000 @@ -1106,6 +1106,8 @@ svcauth_gss_accept(struct svc_rqst *rqst } goto complete; case RPC_GSS_PROC_DESTROY: + if (gss_write_verf(rqstp, rsci->mechctx, gc->gc_seq)) + goto auth_err; set_bit(CACHE_NEGATIVE, >h.flags); if (resv->iov_len + 4 > PAGE_SIZE) goto drop; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 005 of 8] knfsd: Simplify a 'while' condition in svcsock.c
This while loop has an overly complex condition, which performs a
couple of assignments. This hurts readability.
We don't really need a loop at all. We can just return -EAGAIN and
(providing we set SK_DATA), the function will be called again.
So discard the loop, make the complex conditional become a few clear
function calls, and hopefully improve readability.
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./net/sunrpc/svcsock.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff .prev/net/sunrpc/svcsock.c ./net/sunrpc/svcsock.c
--- .prev/net/sunrpc/svcsock.c 2007-05-07 10:30:16.0 +1000
+++ ./net/sunrpc/svcsock.c 2007-05-07 10:31:04.0 +1000
@@ -788,15 +788,20 @@ svc_udp_recvfrom(struct svc_rqst *rqstp)
}
clear_bit(SK_DATA, >sk_flags);
- while ((err = kernel_recvmsg(svsk->sk_sock, , NULL,
-0, 0, MSG_PEEK | MSG_DONTWAIT)) < 0 ||
- (skb = skb_recv_datagram(svsk->sk_sk, 0, 1, )) == NULL) {
- if (err == -EAGAIN) {
- svc_sock_received(svsk);
- return err;
+ skb = NULL;
+ err = kernel_recvmsg(svsk->sk_sock, , NULL,
+0, 0, MSG_PEEK | MSG_DONTWAIT);
+ if (err >= 0)
+ skb = skb_recv_datagram(svsk->sk_sk, 0, 1, );
+
+ if (skb == NULL) {
+ if (err != -EAGAIN) {
+ /* possibly an icmp error */
+ dprintk("svc: recvfrom returned error %d\n", -err);
+ set_bit(SK_DATA, >sk_flags);
}
- /* possibly an icmp error */
- dprintk("svc: recvfrom returned error %d\n", -err);
+ svc_sock_received(svsk);
+ return -EAGAIN;
}
rqstp->rq_addrlen = sizeof(rqstp->rq_addr);
if (skb->tstamp.tv64 == 0) {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 006 of 8] knfsd: Trivial makefile cleanup
From: Christoph Hellwig <[EMAIL PROTECTED]> kbuild directly interprets -y as objects to build into a module, no need to assign it to the old foo-objs variable. Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]> Signed-off-by: Neil Brown <[EMAIL PROTECTED]> ### Diffstat output ./fs/nfsd/Makefile |1 - 1 file changed, 1 deletion(-) diff .prev/fs/nfsd/Makefile ./fs/nfsd/Makefile --- .prev/fs/nfsd/Makefile 2007-05-07 10:30:15.0 +1000 +++ ./fs/nfsd/Makefile 2007-05-07 10:31:05.0 +1000 @@ -11,4 +11,3 @@ nfsd-$(CONFIG_NFSD_V3)+= nfs3proc.o nfs nfsd-$(CONFIG_NFSD_V3_ACL) += nfs3acl.o nfsd-$(CONFIG_NFSD_V4) += nfs4proc.o nfs4xdr.o nfs4state.o nfs4idmap.o \ nfs4acl.o nfs4callback.o nfs4recover.o -nfsd-objs := $(nfsd-y) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 000 of 8] knfsd: Assorted bugfixes for 2.6.22
Following are 8 patches for knfsd and related code that are suitable for 2.6.22. First two are suitable for -stable: they can cause an oops. (8 can also cause an oops, but you really need buggy userspace code running as root, and it is a larger patch than I like to send to -stable). Other 6 are less significant bug fixes and cleanups. Thanks, NeilBrown [PATCH 001 of 8] knfsd: Avoid use of unitialised variables on error path when nfs exports. [PATCH 002 of 8] knfsd: rpc: fix server-side wrapping of krb5i replies [PATCH 003 of 8] knfsd: Fix resource leak resulting in module refcount leak forrpcsec_gss_krb5.ko [PATCH 004 of 8] knfsd: rpcgss : RPC_GSS_PROC_ DESTROY request will get a bad rpc [PATCH 005 of 8] knfsd: Simplify a 'while' condition in svcsock.c [PATCH 006 of 8] knfsd: Trivial makefile cleanup [PATCH 007 of 8] knfsd: Various nfsd xdr cleanups. [PATCH 008 of 8] knfsd: Avoid Oops if buggy userspace performs confusing filehandle->dentry mapping. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 001 of 8] knfsd: Avoid use of unitialised variables on error path when nfs exports.
We need to zero various parts of 'exp' before any 'goto out', otherwise when we go to free the contents... we die. Signed-off-by: Neil Brown <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] ### Diffstat output ./fs/nfsd/export.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff .prev/fs/nfsd/export.c ./fs/nfsd/export.c --- .prev/fs/nfsd/export.c 2007-05-07 10:30:16.0 +1000 +++ ./fs/nfsd/export.c 2007-05-07 10:30:28.0 +1000 @@ -469,6 +469,13 @@ static int svc_export_parse(struct cache nd.dentry = NULL; exp.ex_path = NULL; + /* fs locations */ + exp.ex_fslocs.locations = NULL; + exp.ex_fslocs.locations_count = 0; + exp.ex_fslocs.migrated = 0; + + exp.ex_uuid = NULL; + if (mesg[mlen-1] != '\n') return -EINVAL; mesg[mlen-1] = 0; @@ -509,13 +516,6 @@ static int svc_export_parse(struct cache if (exp.h.expiry_time == 0) goto out; - /* fs locations */ - exp.ex_fslocs.locations = NULL; - exp.ex_fslocs.locations_count = 0; - exp.ex_fslocs.migrated = 0; - - exp.ex_uuid = NULL; - /* flags */ err = get_int(, _int); if (err == -ENOENT) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 002 of 8] knfsd: rpc: fix server-side wrapping of krb5i replies
It's not necessarily correct to assume that the xdr_buf used to hold the
server's reply must have page data whenever it has tail data.
And there's no need for us to deal with that case separately anyway.
Acked-by: "J. Bruce Fields" <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
### Diffstat output
./net/sunrpc/auth_gss/svcauth_gss.c |8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff .prev/net/sunrpc/auth_gss/svcauth_gss.c ./net/sunrpc/auth_gss/svcauth_gss.c
--- .prev/net/sunrpc/auth_gss/svcauth_gss.c 2007-05-07 10:30:18.0
+1000
+++ ./net/sunrpc/auth_gss/svcauth_gss.c 2007-05-07 10:30:38.0 +1000
@@ -1210,13 +1210,7 @@ svcauth_gss_wrap_resp_integ(struct svc_r
if (xdr_buf_subsegment(resbuf, _buf, integ_offset,
integ_len))
BUG();
- if (resbuf->page_len == 0
- && resbuf->head[0].iov_len + RPC_MAX_AUTH_SIZE
- < PAGE_SIZE) {
- BUG_ON(resbuf->tail[0].iov_len);
- /* Use head for everything */
- resv = >head[0];
- } else if (resbuf->tail[0].iov_base == NULL) {
+ if (resbuf->tail[0].iov_base == NULL) {
if (resbuf->head[0].iov_len + RPC_MAX_AUTH_SIZE > PAGE_SIZE)
goto out_err;
resbuf->tail[0].iov_base = resbuf->head[0].iov_base
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] ARM: include IXP4xx "fuses" support
Adds "fuse" functions to help determine installed IXP4xx CPU
components and to reset/disable/enable them (only NPE - network
coprocessors - can be reset and reenabled).
Signed-off-by: Krzysztof Halasa <[EMAIL PROTECTED]>
diff --git a/include/asm-arm/arch-ixp4xx/ixp4xx-regs.h
b/include/asm-arm/arch-ixp4xx/ixp4xx-regs.h
index 5d949d7..780c851 100644
--- a/include/asm-arm/arch-ixp4xx/ixp4xx-regs.h
+++ b/include/asm-arm/arch-ixp4xx/ixp4xx-regs.h
@@ -607,4 +607,51 @@
#define DCMD_LENGTH0x01fff /* length mask (max = 8K - 1) */
+/* Fuse Bits of IXP_EXP_CFG2 */
+#define IXP4XX_FUSE_RCOMP (1 << 0)
+#define IXP4XX_FUSE_USB_DEVICE (1 << 1)
+#define IXP4XX_FUSE_HASH (1 << 2)
+#define IXP4XX_FUSE_AES(1 << 3)
+#define IXP4XX_FUSE_DES(1 << 4)
+#define IXP4XX_FUSE_HDLC (1 << 5)
+#define IXP4XX_FUSE_AAL(1 << 6)
+#define IXP4XX_FUSE_HSS(1 << 7)
+#define IXP4XX_FUSE_UTOPIA (1 << 8)
+#define IXP4XX_FUSE_NPEB_ETH0 (1 << 9)
+#define IXP4XX_FUSE_NPEC_ETH (1 << 10)
+#define IXP4XX_FUSE_RESET_NPEA (1 << 11)
+#define IXP4XX_FUSE_RESET_NPEB (1 << 12)
+#define IXP4XX_FUSE_RESET_NPEC (1 << 13)
+#define IXP4XX_FUSE_PCI(1 << 14)
+#define IXP4XX_FUSE_ECC_TIMESYNC (1 << 15)
+#define IXP4XX_FUSE_UTOPIA_PHY_LIMIT (3 << 16)
+#define IXP4XX_FUSE_USB_HOST (1 << 18)
+#define IXP4XX_FUSE_NPEA_ETH (1 << 19)
+#define IXP4XX_FUSE_NPEB_ETH_1_TO_3(1 << 20)
+#define IXP4XX_FUSE_RSA(1 << 21)
+#define IXP4XX_FUSE_XSCALE_MAX_FREQ(3 << 22)
+#define IXP4XX_FUSE_RESERVED (0xFF << 24)
+
+#define IXP4XX_FUSE_IXP46X_ONLY (IXP4XX_FUSE_ECC_TIMESYNC |\
+IXP4XX_FUSE_USB_HOST | \
+IXP4XX_FUSE_NPEA_ETH | \
+IXP4XX_FUSE_NPEB_ETH_1_TO_3 | \
+IXP4XX_FUSE_RSA | \
+IXP4XX_FUSE_XSCALE_MAX_FREQ)
+
+static inline u32 ixp4xx_read_fuses(void)
+{
+ unsigned int fuses = ~*IXP4XX_EXP_CFG2;
+ fuses &= ~IXP4XX_FUSE_RESERVED;
+ if (!cpu_is_ixp46x())
+ fuses &= ~IXP4XX_FUSE_IXP46X_ONLY;
+
+ return fuses;
+}
+
+static inline void ixp4xx_write_fuses(u32 value)
+{
+ *IXP4XX_EXP_CFG2 = ~value;
+}
+
#endif
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] WAN Kconfig: change "depends on HDLC" to "select"
Allow enabling WAN drivers without selecting generic HDLC first, HDLC will be selected automatically. Signed-off-by: Krzysztof Halasa <[EMAIL PROTECTED]> diff --git a/drivers/net/wan/Kconfig b/drivers/net/wan/Kconfig index 8897f53..3a2fe82 100644 --- a/drivers/net/wan/Kconfig +++ b/drivers/net/wan/Kconfig @@ -171,7 +171,8 @@ comment "X.25/LAPB support is disabled" config PCI200SYN tristate "Goramo PCI200SYN support" - depends on HDLC && PCI + depends on PCI + select HDLC help Driver for PCI200SYN cards by Goramo sp. j. @@ -185,7 +186,8 @@ config PCI200SYN config WANXL tristate "SBE Inc. wanXL support" - depends on HDLC && PCI + depends on PCI + select HDLC help Driver for wanXL PCI cards by SBE Inc. @@ -208,7 +210,8 @@ config WANXL_BUILD_FIRMWARE config PC300 tristate "Cyclades-PC300 support (RS-232/V.35, X.21, T1/E1 boards)" - depends on HDLC && PCI + depends on PCI + select HDLC ---help--- Driver for the Cyclades-PC300 synchronous communication boards. @@ -225,19 +228,21 @@ config PC300 config PC300_MLPPP bool "Cyclades-PC300 MLPPP support" - depends on PC300 && PPP_MULTILINK && PPP_SYNC_TTY && HDLC_PPP + depends on PC300 && PPP_MULTILINK && PPP_SYNC_TTY + select HDLC_PPP help Multilink PPP over the PC300 synchronous communication boards. comment "Cyclades-PC300 MLPPP support is disabled." - depends on WAN && HDLC && PC300 && (PPP=n || !PPP_MULTILINK || PPP_SYNC_TTY=n || !HDLC_PPP) + depends on WAN && PC300 && (PPP=n || !PPP_MULTILINK || PPP_SYNC_TTY=n) comment "Refer to the file README.mlppp, provided by PC300 package." - depends on WAN && HDLC && PC300 && (PPP=n || !PPP_MULTILINK || PPP_SYNC_TTY=n || !HDLC_PPP) + depends on WAN && PC300 && (PPP=n || !PPP_MULTILINK || PPP_SYNC_TTY=n) config PC300TOO tristate "Cyclades PC300 RSV/X21 alternative support" - depends on HDLC && PCI + depends on PCI + select HDLC help Alternative driver for PC300 RSV/X21 PCI cards made by Cyclades, Inc. If you have such a card, say Y here and see @@ -250,7 +255,8 @@ config PC300TOO config N2 tristate "SDL RISCom/N2 support" - depends on HDLC && ISA + depends on ISA + select HDLC help Driver for RISCom/N2 single or dual channel ISA cards by SDL Communications Inc. @@ -267,7 +273,8 @@ config N2 config C101 tristate "Moxa C101 support" - depends on HDLC && ISA + depends on ISA + select HDLC help Driver for C101 SuperSync ISA cards by Moxa Technologies Co., Ltd. @@ -281,7 +288,8 @@ config C101 config FARSYNC tristate "FarSync T-Series support" - depends on HDLC && PCI + depends on PCI + select HDLC ---help--- Support for the FarSync T-Series X.21 (and V.35/V.24) cards by FarSite Communications Ltd. @@ -300,7 +308,8 @@ config FARSYNC config DSCC4 tristate "Etinc PCISYNC serial board support" - depends on HDLC && PCI && m + depends on PCI && m + select HDLC help Driver for Etinc PCISYNC boards based on the Infineon (ex. Siemens) DSCC4 chipset. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] CFS scheduler, -v8
Damien Wyart wrote: Hello, * Ingo Molnar <[EMAIL PROTECTED]> [2007-05-03 15:02]: great! So it seems -v8 does improve OpenGL handling too :-) What are your thoughts/plans concerning merging CFS into mainline ? Is it a bit premature to get it into 2.6.22 ? I remember Linus was ok to change the default scheduler rapidly (the discussion was about sd at that time) to get more testing than in -mm. It would seem that a number of us are testing the variants and reporting results (I now have to pull all the new versions and redo stuff, but I have a new test I'm going to run as well). Given that and the fact that there is another idea which can be tested from Tong Li, I think that decision can be postponed, Linus willing. There appear to be enough testers to be driving evolution now, authors may disagree, of course. Several folks added to cc list... -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] make hci_notifier a blocking notifier (was Re: BUG: sleeping function called from invalid context at net/core/sock.c:1523)
(Dropped Pavel, Rafael and linux-pm from CC list, this isn't a PM error so don't want to spam them; and added bluez-devel) On 5/7/07, Ray Lee <[EMAIL PROTECTED]> wrote: On 5/6/07, Alan Stern <[EMAIL PROTECTED]> wrote: > On Sun, 6 May 2007, Satyam Sharma wrote: > > > Anyway, the hci_notifier is called from the following six call sites: > > > > hci_dev_open() and hci_dev_close() -> both called from > > hci_sock_ioctl() => both can sleep > > hci_register_dev() and hci_unregister_dev() => again both are capable > > of sleeping > > hci_suspend_dev() and hci_resume_dev() -> called from the .suspend() > > and .resume() of the hci_usb_driver, and again both of these can sleep > > > > Is there any other reason why hci_notifier must be an atomic notifier? > > > > (CC'ing Alan Stern just in case, apparently hci_notifier became atomic > > when notifier chains were classified into atomic / blocking) > > I don't remember exactly why this particular choice was made. Perhaps we > found that the notifier callout routines didn't use any blocking > primitives (we may have been mistaken about this -- there was a lot of > code to check) and so therefore the choice didn't matter. In that case we > probably just decided to make it an atomic notifier to keep things simple. > > As you found, changing it to a blocking notifier is very easy. Provided > all the callers are non-atomic it should work just fine. Okay, I'll go ahead and try the patch, then, and report back. You'd still get the BUG message. To fully resolve the problem, we need to make the hci_sock_dev_event() notifier callout blocking (which happened with this patch) but also convert hci_sk_list.lock to a rwsem, but some users of that rwlock (other than hci_sock_dev_event) are atomic. However, please do try and get back, as your testing would still be helpful to see whether converting hci_notifier to blocking had other side-effects -- if you only see the same message again and otherwise things seem fine, then we're good as far as at least this change was concerned. Thanks, Satyam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 4/4] KMON - kmon build infrastrcuture ...
Adds the kmon interface to the build infrastrcuture. Signed-off-by: Davide Libenzi <[EMAIL PROTECTED]> - Davide Index: linux-2.6.21.scdev/init/Kconfig === --- linux-2.6.21.scdev.orig/init/Kconfig2007-05-05 18:11:26.0 -0700 +++ linux-2.6.21.scdev/init/Kconfig 2007-05-06 14:10:22.0 -0700 @@ -492,6 +492,12 @@ on EMBEDDED systems. /proc/vmstat will only show page counts if VM event counters are disabled. +config KMON + default n + bool "Enable Kernel Monitor interface" + help + Enable the kernel monitor interface through the /dev/kmon device. + endmenu# General setup config RT_MUTEXES Index: linux-2.6.21.scdev/drivers/char/Makefile === --- linux-2.6.21.scdev.orig/drivers/char/Makefile 2007-05-05 18:11:26.0 -0700 +++ linux-2.6.21.scdev/drivers/char/Makefile2007-05-06 14:10:22.0 -0700 @@ -56,6 +56,7 @@ obj-$(CONFIG_HVCS) += hvcs.o obj-$(CONFIG_SGI_MBCS) += mbcs.o obj-$(CONFIG_BRIQ_PANEL) += briq_panel.o +obj-$(CONFIG_KMON) += kmon-dev.o obj-$(CONFIG_PRINTER) += lp.o obj-$(CONFIG_TIPAR)+= tipar.o Index: linux-2.6.21.scdev/kernel/Makefile === --- linux-2.6.21.scdev.orig/kernel/Makefile 2007-05-05 18:11:26.0 -0700 +++ linux-2.6.21.scdev/kernel/Makefile 2007-05-06 14:10:22.0 -0700 @@ -51,6 +51,7 @@ obj-$(CONFIG_UTS_NS) += utsname.o obj-$(CONFIG_TASK_DELAY_ACCT) += delayacct.o obj-$(CONFIG_TASKSTATS) += taskstats.o tsacct.o +obj-$(CONFIG_KMON) += kmon.o kmon-stats.o ifneq ($(CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER),y) # According to Alan Modra <[EMAIL PROTECTED]>, the -fno-omit-frame-pointer is Index: linux-2.6.21.scdev/include/linux/Kbuild === --- linux-2.6.21.scdev.orig/include/linux/Kbuild2007-05-05 18:11:26.0 -0700 +++ linux-2.6.21.scdev/include/linux/Kbuild 2007-05-06 14:10:22.0 -0700 @@ -246,6 +246,7 @@ unifdef-y += kernelcapi.h unifdef-y += kernel.h unifdef-y += keyboard.h +unifdef-y += kmon.h unifdef-y += llc.h unifdef-y += loop.h unifdef-y += lp.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/
[patch 1/4] KMON - kmon device/instrumentation ...
This patch serie introduces a way to log high frequency/volume data out of the kernel. Logging scheduler operations for example, with loads that generate tenths of thousands of context switches per second (possibly from multiple CPUs), can overload the kernel printk. Also, logging in binary form helps in reducing the size of the logged data that is tranfered from kernel to userspace. The kmon logger uses per CPU buffers (rings) that are flushed at a given frequency to all the instances of the kmon devices. Those per CPU buffers are allocated only when at least an instance of the kmon device is opened, and are deallocated when the last one is closed. On the kernel side, the API: int kmon_add_data(const void *data, unsigned long size); can be used to log a blob of data into the per-CPU kmon rings. The kmon_add_data() API can be called from any context. The data is prepended by an header with the following format: [0] = CPU number where the log happened (1 byte) [1] = Nanosecond time reported by ktime_get() (little-endian - 8 bytes) [9] = Size of the data blob (little-endian - 2 bytes) Following the header, the data blob is stored. A blob usually begins with a byte specifying the blob type. The currently defined blob formats are: [KMON_DT_TSKQUEUE - Task enqueue] [0] = Blob ID - KMON_DT_TSKQUEUE (1 byte) [1] = Task PID (little-endian - 2 bytes) [KMON_DT_TSKDEQUEUE - Task dequeue] [0] = Blob ID - KMON_DT_TSKDEQUEUE (1 byte) [1] = Task PID (little-endian - 2 bytes) [KMON_DT_TSKSWITCH - Task switch] [0] = Blob ID - KMON_DT_TSKQUEUE (1 byte) [1] = Prev task PID (little-endian - 2 bytes) [3] = Next task PID (little-endian - 2 bytes) [KMON_DT_TSKWAKEUP - Task wakeup] [0] = Blob ID - KMON_DT_TSKQUEUE (1 byte) [1] = From task PID - 0 == IRQ context (little-endian - 2 bytes) [3] = To task PID (little-endian - 2 bytes) The kmon device (/dev/kmon) is a misc-device that supports poll, read and ioctl. The poll(2) system call returns POLLIN when data is available to be read, and returns POLLERR if a kmon buffer overrun happened. The kmon buffer overrun can happen if the caller is not prompt enough to fetch data out of the kmon rings. Once the kmon device is opened, it is put in stopped mode. The user must issue an ioctl(KMON_START) to tell the kernel to start logging the data. An ioctl(KMON_STOP) can be used to put the kmon device back in stopped mode. When the kmon device is in stopped mode, the user can call ioctl(KMON_BUFFSIZE, ) to set the device buffer size (whose default is 1MB). An utility to use the kmon device is available here: http://www.xmailserver.org/kmon/kmonlog.c $ kmonlog [-d KDEV] [-b BUFSIZ] [-o OUTFIL] [-t MSTEST] [-m BMAX] [-p PIDFIL] [-h] -d KDEV = Sets the kmon device file (default "/dev/kmon") -b BUFSIZ = Sets the kmon device buffer size (default 1MB) -o OUTFIL = Sets the output file name (default STDOUT) -t MSTEST = Sets the sample time in millisecs (default unlimited) -m BMAX = Sets the maximum data to be fetched (default unlimited) -p PIDFIL = Sets the PID file name (default "pids.dat") The kmonlog binary fetches the data out of the kmon interface, and compiles a PID information file (linking PIDs to their process binaries and command lines), that can be used to link logged PIDs to processes names. The pids.dat file looks like (only the PIDs that appear in the kmon log are listed): 0 [IDLE] 1 init [2] 4 [watchdog/0] 7 [watchdog/1] 8 [events/0] 9 [events/1] 225 [pdflush] 4970[kjournald] 5838/usr/sbin/cupsd; 5871/usr/sbin/gpm;-m;/dev/psaux;-t;exps2;-Rms3; 7572icewmtray; 7611irssi; 25302 rxvt;-sl;1000;-bg;black;-fg;white;-fn;9x15;-geometry;118x84;+sb; 25307 rxvt;-sl;1000;-bg;black;-fg;white;-fn;9x15;-geometry;118x84;+sb; 25311 /usr/lib/iceape/iceape-bin; Another small utility can translate the kmon binary log into text: http://www.xmailserver.org/kmon/kmonparse.c That emits something like: cpu=0,ts=14929534,op=DEQ,pid=25311 cpu=0,ts=14929535,op=SWC,prev=25311,next=0 cpu=0,ts=14953518,op=WAK,from=0,to=8 cpu=0,ts=14953520,op=QUE,pid=8 cpu=0,ts=14953522,op=SWC,prev=0,next=8 cpu=1,ts=14912505,op=WAK,from=9,to=27233 cpu=1,ts=14912507,op=QUE,pid=27233 cpu=1,ts=14912510,op=DEQ,pid=9 cpu=1,ts=14912513,op=SWC,prev=9,next=0 cpu=1,ts=14962510,op=WAK,from=0,to=9 cpu=1,ts=14962512,op=QUE,pid=9 cpu=1,ts=14962514,op=SWC,prev=0,next=9 cpu=0,ts=14953524,op=WAK,from=8,to=27233 cpu=0,ts=14953526,op=QUE,pid=27233 cpu=0,ts=14953528,op=DEQ,pid=8 Times gets a default scaling to microsecs (configurable with the '-s' option of kmonparse), and they get re-based according to the first entry in the kmon log. I had something similar to kmon a long time ago, and it helped me a lot in fetching out scheduler data when the system is under real life load. You can study task migrations, latencies, run-time patterns, etc... The Quilt patch series are kept here: http://www.xmailserver.org/kmon/patches/ Signed-off-by:
[patch 2/4] KMON - kmon core implementation ...
This is the core implementation of the kmon interface.
Signed-off-by: Davide Libenzi <[EMAIL PROTECTED]>
- Davide
Index: linux-2.6.21.scdev/include/linux/kmon.h
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-2.6.21.scdev/include/linux/kmon.h 2007-05-06 14:10:51.0
-0700
@@ -0,0 +1,77 @@
+/*
+ * include/linux/kmon.h
+ *
+ * Copyright (C) 2007 Davide Libenzi <[EMAIL PROTECTED]>
+ *
+ */
+
+#ifndef _LINUX_KMON_H
+#define _LINUX_KMON_H
+
+#define KMON_START _IO('K', 1)
+#define KMON_STOP _IO('K', 2)
+#define KMON_BUFFSIZE _IOR('K', 3, long)
+
+
+#ifdef __KERNEL__
+
+struct kmon_ring {
+ unsigned long head, tail;
+ unsigned long size;
+ void *data;
+};
+
+struct kmon_buffer {
+ void *data;
+ unsigned long size;
+};
+
+struct kmon_notifier {
+ struct list_head lnk;
+ void (*write)(struct kmon_notifier *, const struct kmon_buffer *, int);
+};
+
+int kmon_ring_write(struct kmon_ring *rng, const struct kmon_buffer *kbuf, int
n);
+unsigned long kmon_ring_read(struct kmon_ring *rng, struct kmon_buffer *kbuf);
+void kmon_ring_commit_read(struct kmon_ring *rng, unsigned long size);
+int kmon_add_data(const void *data, unsigned long size);
+void kmon_notify_add(struct kmon_notifier *knfy);
+void kmon_notify_remove(struct kmon_notifier *knfy);
+int kmon_setup(void);
+void kmon_cleanup(void);
+
+unsigned long kmon_ring_avail(const struct kmon_ring *rng)
+{
+ return (rng->head - rng->tail) & (rng->size - 1);
+}
+
+static inline void kmon_put16(unsigned char *buf, u16 v)
+{
+ *buf++ = (unsigned char) v;
+ *buf = (unsigned char) (v >> 8);
+}
+
+static inline void kmon_put32(unsigned char *buf, u32 v)
+{
+ *buf++ = (unsigned char) v;
+ *buf++ = (unsigned char) (v >> 8);
+ *buf++ = (unsigned char) (v >> 16);
+ *buf = (unsigned char) (v >> 24);
+}
+
+static inline void kmon_put64(unsigned char *buf, u64 v)
+{
+ *buf++ = (unsigned char) v;
+ *buf++ = (unsigned char) (v >> 8);
+ *buf++ = (unsigned char) (v >> 16);
+ *buf++ = (unsigned char) (v >> 24);
+ *buf++ = (unsigned char) (v >> 32);
+ *buf++ = (unsigned char) (v >> 40);
+ *buf++ = (unsigned char) (v >> 48);
+ *buf = (unsigned char) (v >> 56);
+}
+
+#endif /* __KERNEL__ */
+
+#endif /* _LINUX_KMON_H */
+
Index: linux-2.6.21.scdev/drivers/char/kmon-dev.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-2.6.21.scdev/drivers/char/kmon-dev.c 2007-05-06 14:10:51.0
-0700
@@ -0,0 +1,268 @@
+/*
+ * drivers/char/kmon-dev.c
+ *
+ * Copyright (C) 2007 Davide Libenzi <[EMAIL PROTECTED]>
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#define KMON_BUFSIZE_DEFAULT (1024 * 1024)
+#define KMON "kmon v0.17"
+
+#define KMON_FL_OVERFLOW (1 << 0)
+
+struct kmon_ctx {
+ struct kmon_notifier knfy;
+ struct mutex mtx;
+ wait_queue_head_t wqh;
+ struct kmon_ring rng;
+ unsigned long flags;
+};
+
+static int kmon_alloc_ring(struct kmon_ring *rng, unsigned long size)
+{
+ size = roundup_pow_of_two(size);
+ rng->data = vmalloc(size);
+ if (rng->data == NULL)
+ return -ENOMEM;
+ rng->head = rng->tail = 0;
+ rng->size = size;
+
+ return 0;
+}
+
+static void kmon_nfy_write(struct kmon_notifier *knfy, const struct
kmon_buffer *kbuf,
+ int n)
+{
+ struct kmon_ctx *ctx = container_of(knfy, struct kmon_ctx, knfy);
+ int error;
+
+ mutex_lock(>mtx);
+ if (likely((ctx->flags & KMON_FL_OVERFLOW) == 0)) {
+ error = kmon_ring_write(>rng, kbuf, n);
+ if (unlikely(error))
+ ctx->flags |= KMON_FL_OVERFLOW;
+ }
+ if (waitqueue_active(>wqh))
+ wake_up_locked(>wqh);
+ mutex_unlock(>mtx);
+}
+
+static int kmon_open(struct inode *inode, struct file *file)
+{
+ int error;
+ struct kmon_ctx *ctx;
+
+ ctx = (struct kmon_ctx *) kzalloc(sizeof(struct kmon_ctx), GFP_KERNEL);
+ if (ctx == NULL)
+ return -ENOMEM;
+ error = kmon_alloc_ring(>rng, KMON_BUFSIZE_DEFAULT);
+ if (error) {
+ kfree(ctx);
+ return error;
+ }
+ init_waitqueue_head(>wqh);
+ mutex_init(>mtx);
+
+ file->private_data = ctx;
+
+ return 0;
+}
+
+static int kmon_release(struct inode *inode, struct file *file)
+{
+ struct kmon_ctx *ctx = file->private_data;
+
+ if (ctx->knfy.write != NULL)
+ kmon_notify_remove(>knfy);
+ vfree(ctx->rng.data);
+ mutex_destroy(>mtx);
+ kfree(ctx);
+
+
[patch 3/4] KMON - kmon scheduler instrumentation ...
Hooks the kmon interface to the scheduler operations.
Signed-off-by: Davide Libenzi <[EMAIL PROTECTED]>
- Davide
Index: linux-2.6.21.scdev/kernel/sched.c
===
--- linux-2.6.21.scdev.orig/kernel/sched.c 2007-05-06 14:10:29.0
-0700
+++ linux-2.6.21.scdev/kernel/sched.c 2007-05-06 14:10:30.0 -0700
@@ -52,6 +52,7 @@
#include
#include
#include
+#include
#include
#include
@@ -691,10 +692,12 @@
list_del(>run_list);
if (list_empty(array->queue + p->prio))
__clear_bit(p->prio, array->bitmap);
+ kmon_st_task_dequeue(p);
}
static void enqueue_task(struct task_struct *p, struct prio_array *array)
{
+ kmon_st_task_enqueue(p);
sched_info_queued(p);
list_add_tail(>run_list, array->queue + p->prio);
__set_bit(p->prio, array->bitmap);
@@ -1417,6 +1420,8 @@
int new_cpu;
#endif
+ kmon_st_task_wakeup(in_interrupt() ? NULL: current, p);
+
rq = task_rq_lock(p, );
old_state = p->state;
if (!(old_state & state))
@@ -3412,6 +3417,7 @@
prev->timestamp = prev->last_ran = now;
sched_info_switch(prev, next);
+ kmon_st_task_switch(prev, next);
if (likely(prev != next)) {
next->timestamp = next->last_ran = now;
rq->nr_switches++;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] Intel IXP4xx network drivers
Hi, The next 3 patches: [1/3] changes "depends on HDLC" to "select HDLC" for WAN/generic HDLC network drivers [2/3] adds "fuse" functions to help determine installed IXP4xx CPU components and to reset/disable/enable them. [3/3] adds IXP4xx drivers for: hardware queue manager, NPE (on-chip network coprocessors), built-in Ethernet ports, built-in HSS (sync serial) ports (currently only non-channelized HDLC). Patch [3/3] requires patches [1/3] and [2/3] The code is based on publicly available information: - Intel IXP4xx Developer's Manual and others e-papers - Intel IXP400 Access Library Software (BSD license) - previous works by Christian Hohnstaedt <[EMAIL PROTECTED]> While I have decided to rewrite most things from scratch, his patch was a great help in understanding what's going on within the IXP400 code (I took some fragments of his code as well). Thanks, Christian. The code is tested with IXP425 CPU. [1/3] drivers/net/wan/Kconfig | 31 +- [2/3] include/asm-arm/arch-ixp4xx/ixp4xx-regs.h | 47 ++ [3/3] arch/arm/mach-ixp4xx/ixdp425-setup.c | 27 + drivers/net/Kconfig | 34 + drivers/net/Makefile |1 drivers/net/ixp4xx/Makefile |4 drivers/net/ixp4xx/ixp4xx_eth.c | 1002 +++ drivers/net/ixp4xx/ixp4xx_hss.c | 1048 drivers/net/ixp4xx/ixp4xx_npe.c | 731 + drivers/net/ixp4xx/ixp4xx_qmgr.c | 273 +++ drivers/net/ixp4xx/npe.h | 41 + drivers/net/ixp4xx/qmgr.h | 124 +++ drivers/net/wan/Kconfig | 10 include/asm-arm/arch-ixp4xx/platform.h| 19 -- Krzysztof Halasa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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: VFS: fix passing of AT_PHDR value in auxv to ELF interpreter
On Fri, May 04, 2007 at 09:24:05PM -0700, Jeremy Fitzhardinge wrote: > > Indeed, I haven't seen that. For ET_DYN executables, it could be done a > > thing like load_addr+elf_ppnt->p_vaddr (in the function that creates the > > auxv, as ity has access to the elf header), and for ET_EXEC do what I > > propose. I think this is trivial to do. I'll do it as soon as I come back > > in front of my machine. > > > > I don't think you need to special-case it. You can compute the offset > between the linked address and the load address (first > PT_LOAD[0]->p_vaddr - load_addr) and use that to offset all the other > addresses. Indeed. And it has the advantage to work for prelinked objects. (but I have to understand anyway how does the kernel handles prelinked (or not) pie executables) > > > > I don't understand. Yes it is what it is supposed to be, and the kernel > > is supposed to give the vaddr of the phdr table to the interpreter and > > not load addr + offset of phdr in file, which is sometimes wrong. > > > > How can it be wrong? Does the PT_PHDR point to a different array of > Phdr entries? No, of course, but in my case I wanted to build an executable with a modified rpath. I had to add a new PT_LOAD segment. To do so, as the program header is generally located at the very beginning of the executable, I had to copy it to the end, and so the address where it was loaded was completely different. The load address was typically 0x08048000, and the phdr location was 0x0804a570. But the kernel gave to the ld.so in the auxv the addr 0x08048570 for the phdr. And it provoked a segfault because of the .bss which was between the segments. (and even if there was no .bss, it would have worked only by chance because the segments could all fit in a page of 4kb) Quentin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: console font limits
On Friday 04 May 2007 11:34:40 Jesse Barnes wrote: > On Thursday, May 03, 2007, Antonino A. Daplas wrote: > > On Thu, 2007-05-03 at 23:58 -0400, Daniel Hazelton wrote: > > > On Thursday 03 May 2007 20:39:05 H. Peter Anvin wrote: > > > > Kyle Moffett wrote: > > > > > > I guess I could start on that work again - shouldn't take me all that > > > long to recover the stuff I lost when a blackout caused my hard drive > > > to get corrupted beyond recovery (and the automated journal replay > > > didn't do a damned thing - I think it actually *added* to the > > > corruption, but I don't think any filesystem would have survived that) > > > > You might want to look at the modesetting-101 branch of DRM. It's goal > > is similar to yours. They even have a drm framebuffer. I don't know > > how far they are with their goal, but I can see some progress. > > > > Here's their git tree: > > > > git://git.freedesktop.org/git/mesa/drm#modesetting-101 Nope. Address doesn't work for me. > It sounds like we'll need a new KD_* flag for this work too, something like > KD_TEXT_BUT_ONLY_ON_PANIC, sine with the above tree, the kernel will have > intimite knowledge of the current graphics mode, framebuffer location, > etc. It should be enough to clear the scanout buffer and output the > printk, though if there's a lot of rendering going on, the DRM driver > might have to be pretty smart about it. Yeah, I had thought about this. What I was thinking was that, on panic, the kernel could either kill the graphics mode entirely or do something like what the Amiga used to do - ie: scroll the screeen *down* and insert the error output at the top. (well, the opposite, really - scroll up and insert, just to keep the code simple and elegant) Other than that, well... I figure that if the kernel is using DRM internally it can easily tell DRM to cancel out all extended rendering contexts - OpenGL, overlays and such - when the panic happens. DRH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Appletouch is gone!
On Thu, 3 May 2007, Thomas Meyer wrote: > With current git head from linus' tree and LOCALVERSION_AUTO [=y] and > USB_APPLETOUCH [=m] > find /lib/modules/ -name apple* > /lib/modules/2.6.20/kernel/drivers/usb/input/appletouch.ko > /lib/modules/2.6.21/kernel/drivers/usb/input/appletouch.ko This doesn't seem to be a bug specific to current state of the git tree. You probably previously had .config which selected some other driver from drivers/usb/input and therefore build system correctly descended into it. The patch below should solve your issue. Greg, could you please take it through your tree? Thanks. From: Jiri Kosina <[EMAIL PROTECTED]> USB: add forgotten values to Makefile There are several CONFIG_ values related to drivers/usb/input directory that are missing in drivers/usb/Makefile, and therefore they are not sufficient to cause Kbuild to recurse into input/ subdirectory when they are set. Add missing values. Signed-off-by: Jiri Kosina <[EMAIL PROTECTED]> diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile index f5de58a..18ef432 100644 --- a/drivers/usb/Makefile +++ b/drivers/usb/Makefile @@ -25,12 +25,18 @@ obj-$(CONFIG_USB) += storage/ obj-$(CONFIG_USB_ACECAD) += input/ obj-$(CONFIG_USB_AIPTEK) += input/ +obj-$(CONFIG_USB_APPLETOUCH) += input/ obj-$(CONFIG_USB_ATI_REMOTE) += input/ +obj-$(CONFIG_USB_ATI_REMOTE2) += input/ +obj-$(CONFIG_USB_GTCO) += input/ obj-$(CONFIG_USB_KBTAB)+= input/ +obj-$(CONFIG_USB_KEYSPAN_REMOTE) += input/ obj-$(CONFIG_USB_MTOUCH) += input/ obj-$(CONFIG_USB_POWERMATE)+= input/ +obj-$(CONFIG_USB_TOUCHSCREEN) += input/ obj-$(CONFIG_USB_WACOM)+= input/ obj-$(CONFIG_USB_XPAD) += input/ +obj-$(CONFIG_USB_YEALINK) += input/ obj-$(CONFIG_USB_CATC) += net/ obj-$(CONFIG_USB_KAWETH) += net/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] make hci_notifier a blocking notifier (was Re: BUG: sleeping function called from invalid context at net/core/sock.c:1523)
On 5/6/07, Alan Stern <[EMAIL PROTECTED]> wrote: On Sun, 6 May 2007, Satyam Sharma wrote: > Anyway, the hci_notifier is called from the following six call sites: > > hci_dev_open() and hci_dev_close() -> both called from > hci_sock_ioctl() => both can sleep > hci_register_dev() and hci_unregister_dev() => again both are capable > of sleeping > hci_suspend_dev() and hci_resume_dev() -> called from the .suspend() > and .resume() of the hci_usb_driver, and again both of these can sleep > > Is there any other reason why hci_notifier must be an atomic notifier? > > (CC'ing Alan Stern just in case, apparently hci_notifier became atomic > when notifier chains were classified into atomic / blocking) I don't remember exactly why this particular choice was made. Perhaps we found that the notifier callout routines didn't use any blocking primitives (we may have been mistaken about this -- there was a lot of code to check) and so therefore the choice didn't matter. In that case we probably just decided to make it an atomic notifier to keep things simple. As you found, changing it to a blocking notifier is very easy. Provided all the callers are non-atomic it should work just fine. Okay, I'll go ahead and try the patch, then, and report back. Thanks, Ray - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: parallel port problems with 2.6.21_rc5 and 2.6.21_rc6_git3-20070410174235
Randy Dunlap wrote: On Wed, 11 Apr 2007 20:40:23 +0200 Markus Koßmann wrote: When using either the unpatched 2.6.21_rc5 or SUSEs patched 2.6.21_rc6_git3-20070410174235 on a SUSE-10.2 x86_64 system the parallel port doesn't work right. If I "cat some_asciifile >/dev/lp0" the output on my Epson Stylus Color 880 is unreadable. "cat /dev/zero >/dev/lp0" creates random characters on the paper. Printing using cups also doesn't work any more. Switching back to SUSEs 2.6.18.8-0.1 kernel fixes the problem. Any Ideas, what might be broken here ? Nope, but I have the same problem. I'll dig into it some day, but it's not very high priority for me. At some point that could be a problem, I have a shared printer on parallel (and replacing a printer for 11x17 work isn't cheap), as well as one PL/IP requirement, which is embedded in industrial machinery not likely to be upgraded. Non-critical in the sense that I'm sure I can run old kernels for a decade if needed, but hopefully something to be fixed. Since there's no regressions list any more, I guess we will all have to complain about problems individually. :-( -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kconfig text confusion: Battery Class Support?
On Mon, 2007-05-07 at 00:27 +0400, Anton Vorontsov wrote: > Hello Rusty, > > On Sun, May 06, 2007 at 10:06:52PM +1000, Rusty Russell wrote: > > Hi all, > > > > I know writing decent Kconfig help entries is an obscure art, but can > > we please try harder to make the help, y'know, helpful? See below for > > my experience with 2.6.21-mm1. > Thank you for the message, Rusty. It's "fixed" already in battery2-2.6.git. Thanks, that sounds much easier to navigate! 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: [linux-dvb] [PATCH] dvb-core: Handle failures to create devices
On 06/05/07 23:50, Trent Piepho wrote:
I've tested this and can confirm it works. dvb_class will be set too late
without the change to subsys_initcall.
On Tue, 1 May 2007, Simon Arlott wrote:
dvb-core is not started early enough when device drivers that use dvb are
compiled in so device_register_device fails (silently) since dvb_class is
^dvb_register_device
NULL, this runs dvb_init using subsys_initcall instead of module_init.
dvb_register_device will now check the return value of class_device_create.
All the printks had missing level prefixes so I've fixed these too.
Probably better to make this a separate patch, since it's not related.
- printk ("%s: could get find free device id...\n", __FUNCTION__);
+ printk(KERN_ERR "%s: could get find free device id...\n",
__FUNCTION__);
"couldn't find free device id"
If it's ok with you, I'll import your patch as two seperate patches with
the spelling errors fixed?
That's fine with me.
+ dprintk(KERN_DEBUG "DVB: register adapter%d/%s%d @ minor: %i
(0x%02x)\n",
adap->num, dnames[type], id, nums2minor(adap->num, type, id),
nums2minor(adap->num, type, id));
The dvb-core dvbdev_debug parameter does nothing but turn on this one
single dprintk. I'm tempted to just delete it.
Just always output that information, or remove it? (I have it enabled,
although I'm not sure if there's any point).
--
Simon Arlott
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 pata-2.6 fix queue] hpt366: don't check enablebits for HPT36x
On Fri, May 04, 2007 at 11:18:37PM +0400, Sergei Shtylyov wrote: > HPT36x chip don't seem to have the channel enable bits, > so prevent the IDE core from checking them... > > Signed-off-by: Sergei Shtylyov <[EMAIL PROTECTED]> Earlier this evening I reported that HPT366 was broken in 2.6.21. I confirm that this fixes it for me. Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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-dvb] [PATCH] dvb-core: Handle failures to create devices
I've tested this and can confirm it works. dvb_class will be set too late
without the change to subsys_initcall.
On Tue, 1 May 2007, Simon Arlott wrote:
> dvb-core is not started early enough when device drivers that use dvb are
> compiled in so device_register_device fails (silently) since dvb_class is
^dvb_register_device
> NULL, this runs dvb_init using subsys_initcall instead of module_init.
>
> dvb_register_device will now check the return value of class_device_create.
> All the printks had missing level prefixes so I've fixed these too.
Probably better to make this a separate patch, since it's not related.
> - printk ("%s: could get find free device id...\n", __FUNCTION__);
> + printk(KERN_ERR "%s: could get find free device id...\n",
> __FUNCTION__);
"couldn't find free device id"
If it's ok with you, I'll import your patch as two seperate patches with
the spelling errors fixed?
> + dprintk(KERN_DEBUG "DVB: register adapter%d/%s%d @ minor: %i
> (0x%02x)\n",
> adap->num, dnames[type], id, nums2minor(adap->num, type, id),
> nums2minor(adap->num, type, id));
The dvb-core dvbdev_debug parameter does nothing but turn on this one
single dprintk. I'm tempted to just delete it.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.22 patch] iop: combined watchdog timer driver for iop3xx and iop13xx
On 5/6/07, Wim Van Sebroeck <[EMAIL PROTECTED]> wrote: Hi Dan, > >Could you split this patch into 2 patches: one that deals with the moving > >of > >the architecture dependant code (and explaining why) and one with the new > >watchdog drivers? I will continue my review today. > > > > I am one of the maintainers of this architecture, (Lennert Buytenhek > is the other). I will go ahead and split this up so you can sign-off > on the watchdog specific bits. The intent is to move all hardware > definitions under #include . You are right this > should have been a separate patch. I reviewed the rest of the code. Looks OK to me. One small remark though: Can we change the ifdef's in the code as described in section 2 point 2 of the Documentation/SubmittingPatches document? Ok, I can add this cleanup. Barring any objections I'll go ahead and submit the revised patch with an "Acked-by: Wim Van Sebroeck " to Russell's ARM patch tracker. Thanks, Wim. Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
xfs_ilock: possible recursive locking detected
[ 119.948000] =
[ 119.948000] [ INFO: possible recursive locking detected ]
[ 119.948000] 2.6.21-git #185
[ 119.948000] -
[ 119.948000] cc1/6496 is trying to acquire lock:
[ 119.948000] (&(>i_lock)->mr_lock){}, at: []
xfs_ilock+0x60/0xb0
[ 119.948000]
[ 119.948000] but task is already holding lock:
[ 119.948000] (&(>i_lock)->mr_lock){}, at: []
xfs_ilock+0x60/0xb0
[ 119.948000]
[ 119.948000] other info that might help us debug this:
[ 119.948000] 2 locks held by cc1/6496:
[ 119.948000] #0: (>i_mutex){--..}, at: []
mutex_lock+0x1c/0x20
[ 119.948000] #1: (&(>i_lock)->mr_lock){}, at: []
xfs_ilock+0x60/0xb0
[ 119.948000]
[ 119.948000] stack backtrace:
[ 119.948000] [] show_trace_log_lvl+0x1a/0x30
[ 119.948000] [] show_trace+0x12/0x20
[ 119.948000] [] dump_stack+0x16/0x20
[ 119.948000] [] print_deadlock_bug+0xc7/0xe0
[ 119.948000] [] check_deadlock+0x6b/0x80
[ 119.948000] [] __lock_acquire+0x352/0xbb0
[ 119.948000] [] lock_acquire+0x62/0x80
[ 119.948000] [] down_write+0x3a/0x60
[ 119.948000] [] xfs_ilock+0x60/0xb0
[ 119.948000] [] xfs_iget_core+0x2a1/0x5f0
[ 119.948000] [] xfs_iget+0xb1/0x110
[ 119.948000] [] xfs_trans_iget+0xa8/0x140
[ 119.948000] [] xfs_ialloc+0xaf/0x4c0
[ 119.948000] [] xfs_dir_ialloc+0x6d/0x280
[ 119.948000] [] xfs_create+0x249/0x670
[ 119.948000] [] xfs_vn_mknod+0x20a/0x350
[ 119.948000] [] xfs_vn_create+0x12/0x20
[ 119.948000] [] vfs_create+0xb6/0x100
[ 119.948000] [] open_namei_create+0x4e/0xa0
[ 119.948000] [] open_namei+0x553/0x590
[ 119.948000] [] do_filp_open+0x2c/0x60
[ 119.948000] [] do_sys_open+0x50/0xe0
[ 119.948000] [] sys_open+0x1c/0x20
[ 119.948000] [] sysenter_past_esp+0x5d/0x99
[ 119.948000] ===
--
Simon Arlott
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] MM: implement MADV_FREE lazy freeing of anonymous memory
Nick Piggin wrote: OK, sure. I think we need more numbers though. Thinking about the issue some more, I think I know just the number we might want to know. It is pretty obvious that the kernel needs to do less work with the MADV_FREE code present. However, it is possible that userspace needs to do more work, by accessing pages that are not in the CPU cache, or in another CPU's cache. In the test cases where you see similar performance on the workload with and without the MADV_FREE code, are you by any chance seeing lower system time and higher user time? I think that maybe for 2.6.22 we should just alias MADV_FREE to run with the MADV_DONTNEED functionality, so that the glibc people can make the change on their side while we figure out what will be the best thing to do on the kernel side. I'll send in a patch that does that once Linus has committed your most recent flood of patches. What do you think? -- Politics is the struggle between those who want to make their country the best in the world, and those who believe it already is. Each group calls the other unpatriotic. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.21] kernel panic
On Sun, 6 May 2007, Folkert van Heusden wrote:
> > > A few moments ago a system of mine running 2.6.21 on a P4 with
> > > hyperthreading, 2GB ram, IDE disk, crashed: [10371.128320] BUG:
> > > unable to handle kernel paging request at virtual address 00100100
> > > [10371.128419] printing eip:
> > [...]
> > > [10371.131825] EIP is at hiddev_send_event+0xa1/0xd3
> >
> > I will look into it. Are you able to reproduce the problem, or did it
> > happen just randomly? Is there any userspace driver using the hiddev
> > interface at the moment it crashes?
> > There have been no changes in the hiddev code for a pretty long time.
[...]
> This is the first time it was followed by an oops. Connected via hid are
> 2 temperature sensors and an UPS. Has been running fine for ages.
OK, I think the patch below should solve this. I am pretty surprised
though that this bug wasn't triggered/reported by anyone anytime sooner,
it has been there for ages too (but ok, the race window should be pretty
small and hiddev is usually not high-throughput interface).
Could you please test it and let me know?
From: Jiri Kosina <[EMAIL PROTECTED]>
USB HID: hiddev - fix race between hiddev_send_event() and hiddev_release()
There is a small race window in which hiddev_release() could corrupt the
list that is being processed for new event in hiddev_send_event().
Synchronize the operations over this list.
Signed-off-by: Jiri Kosina <[EMAIL PROTECTED]>
diff --git a/drivers/usb/input/hiddev.c b/drivers/usb/input/hiddev.c
index a8b3d66..488d61b 100644
--- a/drivers/usb/input/hiddev.c
+++ b/drivers/usb/input/hiddev.c
@@ -51,6 +51,7 @@ struct hiddev {
wait_queue_head_t wait;
struct hid_device *hid;
struct list_head list;
+ spinlock_t list_lock;
};
struct hiddev_list {
@@ -161,7 +162,9 @@ static void hiddev_send_event(struct hid
{
struct hiddev *hiddev = hid->hiddev;
struct hiddev_list *list;
+ unsigned long flags;
+ spin_lock_irqsave(>list_lock, flags);
list_for_each_entry(list, >list, node) {
if (uref->field_index != HID_FIELD_INDEX_NONE ||
(list->flags & HIDDEV_FLAG_REPORT) != 0) {
@@ -171,6 +174,7 @@ static void hiddev_send_event(struct hid
kill_fasync(>fasync, SIGIO, POLL_IN);
}
}
+ spin_unlock_irqrestore(>list_lock, flags);
wake_up_interruptible(>wait);
}
@@ -235,9 +239,13 @@ static int hiddev_fasync(int fd, struct
static int hiddev_release(struct inode * inode, struct file * file)
{
struct hiddev_list *list = file->private_data;
+ unsigned long flags;
hiddev_fasync(-1, file, 0);
+
+ spin_lock_irqsave(>hiddev->list_lock, flags);
list_del(>node);
+ spin_unlock_irqrestore(>hiddev->list_lock, flags);
if (!--list->hiddev->open) {
if (list->hiddev->exist)
@@ -257,6 +265,7 @@ static int hiddev_release(struct inode *
static int hiddev_open(struct inode *inode, struct file *file)
{
struct hiddev_list *list;
+ unsigned long flags;
int i = iminor(inode) - HIDDEV_MINOR_BASE;
@@ -267,7 +276,11 @@ static int hiddev_open(struct inode *ino
return -ENOMEM;
list->hiddev = hiddev_table[i];
+
+ spin_lock_irqsave(>hiddev->list_lock, flags);
list_add_tail(>node, _table[i]->list);
+ spin_unlock_irqrestore(>hiddev->list_lock, flags);
+
file->private_data = list;
if (!list->hiddev->open++)
@@ -773,6 +786,7 @@ int hiddev_connect(struct hid_device *hi
init_waitqueue_head(>wait);
INIT_LIST_HEAD(>list);
+ spin_lock_init(>list_lock);
hiddev->hid = hid;
hiddev->exist = 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/
JBD: ext2online wants too many credits (744 > 256)
2.6.20.6, FC4: I created a 91248k ext3 fs with 4k blocksize: | mke2fs -j -b 4096 /dev/vol1/project | mke2fs 1.38 (30-Jun-2005) | Filesystem label= | OS type: Linux | Block size=4096 (log=2) | Fragment size=4096 (log=2) | 23552 inodes, 23552 blocks | 1177 blocks (5.00%) reserved for the super user | First data block=0 | Maximum filesystem blocks=25165824 | 1 block group | 32768 blocks per group, 32768 fragments per group | 23552 inodes per group Writing inode tables: done Creating journal (1024 blocks): done Writing superblocks and filesystem accounting information: done Next, I tried to resize it to about 3G using ext2online while mounted: | # ext2online /dev/vol1/project | ext2online v1.1.18 - 2001/03/18 for EXT2FS 0.5b | ext2online: ext2_ioctl: No space left on device | | ext2online: unable to resize /dev/mapper/vol1-project At that time the kernel said: |JBD: ext2online wants too many credits (744 > 256) What is the limitation I should be aware of? Has it something to do with the journal log size? The size actually did increase a bit, to 128112k. Steps to reproduce: Create a 3G partition, say /dev/vol1/project mke2fs -j -b 4096 /dev/vol1/project 22812 mount it ext2online /dev/vol1/project said: | ext2online v1.1.18 - 2001/03/18 for EXT2FS 0.5b | ext2online: ext2_ioctl: No space left on device | | ext2online: unable to resize /dev/mapper/vol1-project kernel said: | JBD: ext2online wants too many credits (721 > 256) -- Frank - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] nfsctl: Use vfs_path_lookup
use vfs_path_lookup instead of open-coding the necessary functionality.
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
fs/nfsctl.c | 16 ++--
1 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/fs/nfsctl.c b/fs/nfsctl.c
index c043136..51f1b31 100644
--- a/fs/nfsctl.c
+++ b/fs/nfsctl.c
@@ -23,19 +23,15 @@
static struct file *do_open(char *name, int flags)
{
struct nameidata nd;
+ struct vfsmount *mnt;
int error;
- nd.mnt = do_kern_mount("nfsd", 0, "nfsd", NULL);
+ mnt = do_kern_mount("nfsd", 0, "nfsd", NULL);
+ if (IS_ERR(mnt))
+ return (struct file *)mnt;
- if (IS_ERR(nd.mnt))
- return (struct file *)nd.mnt;
-
- nd.dentry = dget(nd.mnt->mnt_root);
- nd.last_type = LAST_ROOT;
- nd.flags = 0;
- nd.depth = 0;
-
- error = path_walk(name, );
+ error = vfs_path_lookup(mnt->mnt_root, mnt, name, 0, );
+ mntput(mnt);/* drop do_kern_mount reference */
if (error)
return ERR_PTR(error);
--
1.5.2.rc1.20.g86b9
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] make hci_notifier a blocking notifier (was Re: BUG: sleeping function called from invalid context at net/core/sock.c:1523)
On Sun, 6 May 2007, Satyam Sharma wrote: > Anyway, the hci_notifier is called from the following six call sites: > > hci_dev_open() and hci_dev_close() -> both called from > hci_sock_ioctl() => both can sleep > hci_register_dev() and hci_unregister_dev() => again both are capable > of sleeping > hci_suspend_dev() and hci_resume_dev() -> called from the .suspend() > and .resume() of the hci_usb_driver, and again both of these can sleep > > Is there any other reason why hci_notifier must be an atomic notifier? > > (CC'ing Alan Stern just in case, apparently hci_notifier became atomic > when notifier chains were classified into atomic / blocking) I don't remember exactly why this particular choice was made. Perhaps we found that the notifier callout routines didn't use any blocking primitives (we may have been mistaken about this -- there was a lot of code to check) and so therefore the choice didn't matter. In that case we probably just decided to make it an atomic notifier to keep things simple. As you found, changing it to a blocking notifier is very easy. Provided all the callers are non-atomic it should work just fine. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
OOPS when swsusp/resume when connected to the internet via BT and GPRS
Hi all, today I experienced OOPS when connected via BT/GPRS to the internet, then swsup and resumed with dongle in HID proxy mode. Please see details in dmesg log: Restarting tasks ... <6>usb 3-1: USB disconnect, address 3 done. BUG: unable to handle kernel NULL pointer dereference at virtual address 0008 printing eip: c018db5d *pde = Oops: [#1] PREEMPT Modules linked in: ppp_deflate zlib_deflate bsd_comp ppp_async ppp_generic slhc usbhid nls_iso8859_1 nls_cp437 vfat fat sg sr_mod sd_mod usb_storage bnep rfcomm hidp l2cap lp fuse eeprom hci_usb bluetooth 8250_pci 8250 serial_core snd_intel8x0 sn d_intel8x0m snd_ac97_codec wlan_scan_sta ac97_bus ath_rate_sample nsc_ircc snd_pcm ide_cd ath_pci wlan ath_hal(P) 8139too m ii snd_timer snd irda ehci_hcd psmouse pcspkr i2c_i801 iTCO_wdt iTCO_vendor_support rtc cdrom parport_pc parport snd_page_a lloc uhci_hcd crc_ccitt CPU:0 EIP:0060:[]Tainted: P VLI EFLAGS: 00010282 (2.6.21 #3) EIP is at sysfs_move_dir+0x3e/0x117 eax: ebx: efd7df40 ecx: f79a1e7c edx: c1b88940 esi: c1b91e28 edi: ebp: c1b88940 esp: f79a1e50 ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Process pppd (pid: 6550, ti=f79a task=f29d6ab0 task.ti=f79a) Stack: c03475a4 f7f86e68 fff4 efd7df40 f7f86e68 fff4 c1b88940 c01d27ec f12a5240 c0347596 efd7df40 f12a5240 f12a5240 f7f86e00 c1b88940 c023c984 f7f86e68 f7f36640 ef67b000 Call Trace: [] kobject_move+0xaf/0xfa [] device_move+0x49/0xd7 [] rfcomm_tty_close+0x23/0x7a [rfcomm] [] release_dev+0x1df/0x5e7 [] inode_has_perm+0x66/0x6e [] __posix_lock_file_conf+0x44e/0x48b [] file_has_perm+0x89/0x91 [] tty_release+0xf/0x18 [] __fput+0x96/0x15e [] filp_close+0x51/0x58 [] sys_close+0x75/0xbf [] syscall_call+0x7/0xb === Code: 40 30 eb 0b a1 a0 79 42 c0 8b 40 14 8b 40 38 89 44 24 08 85 d2 74 05 8b 72 30 eb 0b a1 a0 79 42 c0 8b 40 14 8b 70 38 8b 7c 24 08 <8b> 47 08 31 ff 3b 46 08 0f 84 c1 00 00 00 8b 54 24 08 8b 42 08 EIP: [] sysfs_move_dir+0x3e/0x117 SS:ESP 0068:f79a1e50 Thanks for fixing this issue Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.21-mm1
> From: Andrew Morton [mailto:[EMAIL PROTECTED]
> On Sun, 6 May 2007 22:44:29 +0200 Sam Ravnborg <[EMAIL PROTECTED]>
wrote:
>
> > On Sun, May 06, 2007 at 08:33:48AM +0400, Dan Kruchinin wrote:
> > > >
> > >
>
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6
.21-
> mm1/
> > >
> > > I have the following message after kernel compilation:
> > >
> > > ---
> > > ...
> > > WARNING: init/built-in.o - Section mismatch: reference to
.init.text:
> > > from .text between 'rest_init' (at offset 0x11e) and 'try_name'
> >
> > Covered in another mail.
> >
> > > ...
> > > ...
> > > WARNING: drivers/dma/async_tx.o - Section mismatch: reference to
> > > .init.data: from .data after 'channel_table' (at offset 0x20)
> > > WARNING: drivers/dma/async_tx.o - Section mismatch: reference to
> > > .init.data: from .data after 'channel_table' (at offset 0x24)
> > > WARNING: drivers/dma/async_tx.o - Section mismatch: reference to
> > > .init.data: from .data after 'channel_table' (at offset 0x28)
> > > WARNING: drivers/dma/async_tx.o - Section mismatch: reference to
> > > .init.data: from .data after 'channel_table' (at offset 0x2c)
> > > WARNING: drivers/dma/async_tx.o - Section mismatch: reference to
> > > .init.data: from .data after 'channel_table' (at offset 0x30)
> > > WARNING: drivers/dma/async_tx.o - Section mismatch: reference to
> > > .init.data: from .data after 'channel_table' (at offset 0x34)
> > > WARNING: drivers/dma/async_tx.o - Section mismatch: reference to
> > > .init.data: from .data after 'channel_table' (at offset 0x38)
> > > WARNING: drivers/dma/async_tx.o - Section mismatch: reference to
> > > .init.data: from .data after 'channel_table' (at offset 0x3c)
> > > WARNING: drivers/dma/async_tx.o - Section mismatch: reference to
> > > .init.data: from .data after 'channel_table' (at offset 0x40)
> > > WARNING: drivers/dma/async_tx.o - Section mismatch: reference to
> > > .init.data: from .data after 'channel_table' (at offset 0x44)
> >
> > We have following code:
> > /* guarantee that calls that happen before init will not find a
channel */
> > static struct chan_ref_percpu __initdata null_chan_ref[NR_CPUS];
> >
> > static struct chan_ref_percpu *channel_table[] = {
> > DMA_TX_ARRAY_INIT(null_chan_ref)
> > };
> >
> > The DMA_TX_ARRAY_INIT is some macro obscufation that serves no
> > real use and just hide a few assignements.
> > What happens here is that we assign channel_table a value
> > that are used as cover-up until the real assignment happens
> > in the init function.
> > So the only real way to fix this seems to remove the otherwise
correct
> > __initdata mark on null_chan_ref.
> > Thats one pointer wasted pr. cpu (in total NR_CPUS).
> >
>
> (add Dan to cc)
Not sure if there is a better way to do this, but I went ahead and added
a global flag that gets set after init. It also lets DMA_TX_ARRAY_INIT
go away, but it adds another branch to the fast path.
I rebased "git://lost.foo-projects.org/~dwillia2/git/iop md-accel-linus"
with the following:
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index f2d8b75..95a87a0 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -76,27 +76,12 @@ enum dma_transaction_type {
DMA_PQ_ZERO_SUM,
DMA_MEMSET,
DMA_MEMCPY_CRC32C,
- DMA_INTERRUPT, /* when updating, make this the last entry and
- * update the DMA_TX_ARRAY_INIT macro
- */
+ DMA_INTERRUPT, /* when updating, make this the last entry */
};
/* last transaction type for creation of the capabilities mask */
#define DMA_TX_TYPE_END (DMA_INTERRUPT + 1)
-/* helper macro for clients defining transaction arrays */
-#define DMA_TX_ARRAY_INIT(x) \
- [DMA_MEMCPY] = x, \
- [DMA_XOR] = x, \
- [DMA_PQ_XOR] = x, \
- [DMA_DUAL_XOR] = x, \
- [DMA_PQ_UPDATE] = x,\
- [DMA_ZERO_SUM] = x, \
- [DMA_PQ_ZERO_SUM] = x, \
- [DMA_MEMSET] = x, \
- [DMA_MEMCPY_CRC32C] = x,\
- [DMA_INTERRUPT] = x,
-
/**
* dma_cap_mask_t - capabilities bitmap modeled after cpumask_t.
* See linux/cpumask.h
diff --git a/drivers/dma/async_tx.c b/drivers/dma/async_tx.c
index 6bbbacc..6450cfd 100644
--- a/drivers/dma/async_tx.c
+++ b/drivers/dma/async_tx.c
@@ -52,12 +52,8 @@ struct chan_ref_percpu {
struct dma_chan_ref *ref;
};
-/* guarantee that calls that happen before init will not find a channel
*/
-static struct chan_ref_percpu __initdata null_chan_ref[NR_CPUS];
-
-static struct chan_ref_percpu *channel_table[] = {
- DMA_TX_ARRAY_INIT(null_chan_ref)
-};
+static int channel_table_initialized;
+static struct chan_ref_percpu *channel_table[DMA_TX_TYPE_END];
/**
* async_tx_lock - protect modification of async_tx_master_list and
serialize
@@ -260,6 +256,7 @@ async_tx_init(void)
dma_async_client_register(_tx_dma);
dma_async_client_chan_request(_tx_dma);
+
Re: [patch 14/22] pollfs: pollable futex
Andrew Morton wrote: > On Sun, 6 May 2007 00:50:47 -0700 "Ulrich Drepper" <[EMAIL PROTECTED]> wrote: > >>> I really do not understand your point. You're too smart to not appreciate >>> the beauty and the simmetry of objects that responds to a common interface >>> (our files, win32 handles), and that fits our existing kernel >>> infrastructure. >> You're blinded by this symmetry. Not everything that looks like a >> good fit is a good idea. This is one case. Get over it, poll is not >> powerful enough to serve as the unifying event mechanism. > > What is your position on the timerfd/signalfd/etc patches? > > Seems to me that if we were to have fancy new event-delivery machinery > like kevent then the timerfd/signalfd work is heading in the other > direction and ultimately would prove to have been unneeded? IMHO, I thought we had already gone down the *fd road with inotify, posix message queue, and _hundred_ others file objects with poll methods. I also think that inotify+(e)poll proves how well the fd/epoll model fits together, scales, and that a new fancy event-delivery machinery is not necessary. And it makes me wonder why I hadn't followed its "watch" approach for futexes: futex_init(); // Davide's anon fd futex_add_watch(int fd, void *addr, int val, uint32_t mask); futex_rm_watch(int fd, uint32_t wd); Anyway, this unifying event machinery can be built, if needed, in user space by libevent and others. -- Davi Arnaut - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Kernel-discuss] Re: [PATCH 3/8] Universal power supply class (was: battery class)
Hi Paul, On Sat, May 05, 2007 at 05:29:56PM +0300, Paul Sokolovsky wrote: > Hello Anton, > > But in real world, it's rather common to colloquially name > such kind of power "AC", and that's "term" is known to many-many > people, and intuitively understood even for those, who didn't hit it yet. > Actually, this discussion is good confirmation that's the case - > people understand in what meaning it is used here, and go to point > that it's not "scientifically" correct. I fully agree here. Yes, AC is common term, but might be really confusing for people who really know what AC is. ;-) In past review we tried to drop any point of confusions (we agreed to separate capacity, charge and energy terms), and now we've found another point: AC, DC, MAINS. So, let's again eliminate any possibility of confusion, and name things with correct terms. Thanks, -- Anton Vorontsov email: [EMAIL PROTECTED] backup email: [EMAIL PROTECTED] irc://irc.freenode.org/bd2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-usb-users] [SOLVED] Serial buffer corruption [was Re: FTDI usb-serial possible bug]
On Sun, 6 May 2007, Alan Cox wrote: > > However, whatever policy the buffer uses, the fundamental point it's that > > when I flush the input buffer I should be sure that each byte read > > after the flush is *new* (current) data and not old one. This because > > Define "new" and "old" in this case. I don't believe you can give a > precise definition or that such a thing is physically possible. One can come close. It would make sense to say that after a flush, subsequent reads should retrieve _contiguous_ bytes from the input stream. In other words, rule out the possibility that the read would get bytes 1-10 (from some buffer somewhere) followed by bytes 30-60 (because bytes 11-29 were dropped by the flush). By contrast, it would be permissible for the read to obtain bytes 20-60, even though 20-29 may have been entered the input stream before the flush occurred. > The hardware itself has buffers at both ends of the link, there may be > buffers in modems, muxes and the like as well. We can certainly flush > input buffers in the kernel but it isn't clear we can always do so at the > hardware level, let alone at the remote end or buffers on devices on the > link. This is of course the fly in the ointment. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/5] fs: Mark link_path_walk static
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
fs/namei.c|4 +++-
include/linux/namei.h |1 -
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/fs/namei.c b/fs/namei.c
index 090cce4..925c62e 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -108,6 +108,8 @@
* any extra contention...
*/
+static int fastcall link_path_walk(const char *name, struct nameidata *nd);
+
/* In order to reduce some races, while at the same time doing additional
* checking and hopefully speeding things up, we copy filenames to the
* kernel data space before using them..
@@ -999,7 +1001,7 @@ return_err:
* Retry the whole path once, forcing real lookup requests
* instead of relying on the dcache.
*/
-int fastcall link_path_walk(const char *name, struct nameidata *nd)
+static int fastcall link_path_walk(const char *name, struct nameidata *nd)
{
struct nameidata save = *nd;
int result;
diff --git a/include/linux/namei.h b/include/linux/namei.h
index 4718788..d60a5eb 100644
--- a/include/linux/namei.h
+++ b/include/linux/namei.h
@@ -73,7 +73,6 @@ extern int FASTCALL(path_lookup(const char *, unsigned,
struct nameidata *));
extern int vfs_path_lookup(struct dentry *, struct vfsmount *,
const char *, unsigned int, struct nameidata *);
extern int FASTCALL(path_walk(const char *, struct nameidata *));
-extern int FASTCALL(link_path_walk(const char *, struct nameidata *));
extern void path_release(struct nameidata *);
extern void path_release_on_umount(struct nameidata *);
--
1.5.2.rc1.20.g86b9
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] get_unmapped_area: remove now unused ret variable (was Re: 2.6.21-mm1)
On Sun, 2007-05-06 at 11:03 +0200, Frederik Deweerdt wrote:
> On Sat, May 05, 2007 at 01:49:55AM -0700, Andrew Morton wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm1/
> >
>
> mm/mmap.c:1393: warning: unused variable 'ret'
>
> The get_unmapped_area-doesnt-need-hugetlbfs-hacks-anymore.patch and
> get_unmapped_area-handles-map_fixed-in-generic-code.patch rendered the ret
> variable useless.
Ah good catch.. I wonder why my gcc didn't spot it...
> Regards,
> Frederik
>
> Signed-off-by: Frederik Deweerdt <[EMAIL PROTECTED]>
Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> diff --git a/mm/mmap.c b/mm/mmap.c
> index b0f6eb8..fabf7f4 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -1390,7 +1390,6 @@ unsigned long
> get_unmapped_area(struct file *file, unsigned long addr, unsigned long len,
> unsigned long pgoff, unsigned long flags)
> {
> - unsigned long ret;
> unsigned long (*get_area)(struct file *, unsigned long,
> unsigned long, unsigned long, unsigned long);
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Kernel-discuss] Re: [PATCH 3/8] Universal power supply class (was: battery class)
On Sun, May 06, 2007 at 03:06:04PM -0300, Henrique de Moraes Holschuh wrote: > On Sat, 05 May 2007, Paul Sokolovsky wrote: > > Saturday, May 5, 2007, 4:46:26 PM, you wrote: > > > On Sat, 2007-05-05 at 00:54 -0300, Henrique de Moraes Holschuh wrote: > > >> Given that USB-power *is* usually also "dumb" (i.e. it doesn't do any > > >> control signaling over the USB bus for power-control purposes), > > > > > it might be dumb, but it is useful to know wether the PDA is charging > > > from usb or mains power. and some devices allow one to switch on / off > > > the ability to charge via usb > > > > And USB does have power budgetting requirements, etc. (like > > was already pointed in own of initial review messages). So, USB > > is definitely not the same thing as "dumb DC". > > Everything does. A dumb DC power source is a dumb DC power source. USB is > no different here, *unless* it is using USB signaling to control the power > link, at which point it is not a dumb DC power source anymore. > > There really is no difference beween an AC brick, a DC brick, an AC/DC > brick, or an USB port supplying DC power in a dumb way in a laptop or > handheld: they are all supposed-continous DC power supplies with a maximum > power budget. > > But the "GUI should show it differently" part does make sense. I am not > completely convinced a high number of top-level types is the best way to go > about it, though. I'd use subtypes, and a comprehensive enough set of > standard types and sub-types, along with a description of exactly what they > are to be used for. This will make it MUCH easier on the userspace side for > GUI authors, and it will be much better for people to not use the wrong > types when converting to the new class... Um... well, if we'll speak for easiness, then just "type" is more easy and less error-prone than type + subtype. ;-) So, personally I see nothing wrong with MAINS/USB/Battery/UPS power supply types. Though, as you may noticed I'm easy to convince. ;-) So, if you'll elaborate it, I might finally will see my wrongness. Just in case I'll be convinced... .type = POWER_SUPPLY_TYPE_MAINS, .subtype = POWER_SUPPLY_SUBTYPE_USB, Looks okay? .type = POWER_SUPPLY_TYPE_MAINS, .subtype = POWER_SUPPLY_SUBTYPE_AC, And SUBTYPE_AC looks not good already, because we indeed tried to avoid AC/DC meanings in type fields, because current_type attribute will be better. So, what subtype name we should use? .type = POWER_SUPPLY_TYPE_BATTERY, .subtype = POWER_SUPPLY_SUBTYPE_, What should be in "" for plain batteries? Should UPS be subtype of battery type? .type = POWER_SUPPLY_TYPE_MAINS, .subtype = POWER_SUPPLY_SUBTYPE_UPS, Just wrong. So, notice that subtype brings complications, not solves them. Thanks! -- Anton Vorontsov email: [EMAIL PROTECTED] backup email: [EMAIL PROTECTED] irc://irc.freenode.org/bd2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] [TRIVIAL] Small cleanups for do_path_lookup (V2)
On Sun, May 06, 2007 at 01:47:54PM -0400, Josef 'Jeff' Sipek wrote: > (For changes since V1, see the end of this email.) > > The following 2 patches are trivial cleanups to do_path_lookup in namei.c. > Since these changes are trivial, they can go into 2.6.22-rc1 without any > problems. > > Josef 'Jeff' Sipek (2): > fs: Fix indentation in do_path_lookup > fs: Use path_walk in do_path_lookup Ok for both patches. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.21-mm1
On Mon, 7 May 2007 02:34:26 +0530 "Satyam Sharma" <[EMAIL PROTECTED]> wrote:
> On 5/7/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > On Sun, 06 May 2007 15:59:53 +0100 Simon Arlott <[EMAIL PROTECTED]> wrote:
> >
> > > On 05/05/07 09:49, Andrew Morton wrote:
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm1/
> > >
> > > I'm currently in the middle of a bisect over the last week of commits to
> > > linus'
> > > tree, but I got the following with -mm1 that isn't showing up in the
> > > latest
> > > 2.6.21-git:
> > >
> > > [ 15.644778] BUG: sleeping function called from invalid context at
> > > kernel/mutex.c:86
> > > [ 15.644873] in_atomic():1, irqs_disabled():1
> > > [ 15.644882] 2 locks held by modprobe/2765:
> > > [ 15.644889] #0: (devlist_lock){--..}, at: []
> > > mutex_lock+0x1f/0x30
> > > [ 15.645058] #1: (modlist_lock){}, at: []
> > > __symbol_get+0x1d/0x90
> > > [ 15.645207] irq event stamp: 11772
> > > [ 15.645271] hardirqs last enabled at (11771): []
> > > slab_free+0xc3/0x200
> > > [ 15.645289] hardirqs last disabled at (11772): []
> > > _spin_lock_irqsave+0x16/0x60
> > > [ 15.645364] softirqs last enabled at (11216): []
> > > __do_softirq+0x96/0xb0
> > > [ 15.645439] softirqs last disabled at (11211): []
> > > do_softirq+0x82/0x100
> > > [ 15.645517] [] show_trace_log_lvl+0x1a/0x30
> > > [ 15.645586] [] show_trace+0x12/0x20
> > > [ 15.645654] [] dump_stack+0x15/0x20
> > > [ 15.645665] [] __might_sleep+0xcd/0xf0
> > > [ 15.645737] [] mutex_lock+0x18/0x30
> > > [ 15.645806] [] sysfs_create_link+0x6c/0x130
> > > [ 15.645823] [] use_module+0x11a/0x170
> > > [ 15.645892] [] __symbol_get+0x6c/0x90
> > > [ 15.645904] [] dvb_init+0x98c/0xd70 [saa7134_dvb]
> > > [ 15.645984] [] mpeg_ops_attach+0x3d/0x50
> > > [ 15.646058] [] saa7134_ts_register+0x29/0x70
> > > [ 15.646070] [] dvb_register+0x10/0x12 [saa7134_dvb]
> > > [ 15.646141] [] sys_init_module+0xf7/0x150
> > > [ 15.646153] [] sysenter_past_esp+0x5f/0x99
> > > [ 15.646221] ===
> >
> > Looks like a locking error in the DVB code.
>
> Actually, kernel/module.c:__symbol_get() does
> spinlock_irq_save(_lock) and then calls use_module().
>
> But when CONFIG_MODULE_UNLOAD=y, use_module() wants to
> sysfs_create_link() (I wonder why) which will clearly blow up.
OK, thanks.
What appears to have hapened is that Trent's not-yet-in-mainline
add-ability-to-keep-track-of-callers-of-symbol_getput.patch assumes that
use_module() is atomic, but Kay's now-in-mainline
gregkh-driver-sys-modules-holders.patch concurrently assumed that
use_module() is not atomic.
But use_module() already had a GFP_ATOMIC allocation in it, which tends to
indicate that sticking a sysfs_create_link() into use_module() wasn't an
appropriate thing to do.
gargh. Could we please have some statement regarding use_module()'s
caller-provided environment and locking expectations?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.21-mm1
On Sun, May 06, 2007 at 02:08:57PM -0700, Andrew Morton wrote:
> On Sun, 6 May 2007 22:57:32 +0200 Sam Ravnborg <[EMAIL PROTECTED]> wrote:
>
> > On Sun, May 06, 2007 at 02:49:49AM -0400, [EMAIL PROTECTED] wrote:
> > > On Sat, 05 May 2007 01:49:55 PDT, Andrew Morton said:
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm1/
> > >
> > > MODPOST vmlinux
> > > WARNING: mm/built-in.o - Section mismatch: reference to .init.text: from
> > > .text between 'kmem_cache_create' (at offset 0x20dff) and 'cache_reap'
> > > WARNING: mm/built-in.o - Section mismatch: reference to .init.text: from
> > > .text between 'kmem_cache_create' (at offset 0x20e41) and 'cache_reap'
> > >
> > > Built with CONFIG_SLAB, CONFIG_SMP, x86_64.
> >
> > It comes from this code (mm/slab.c):
> > /*
> > * For setting up all the kmem_list3s for cache whose buffer_size is same as
> > * size of kmem_list3.
> > */
> > static void __init set_up_list3s(struct kmem_cache *cachep, int index)
> > {
> > int node;
> >
> > for_each_online_node(node) {
> > cachep->nodelists[node] = _list3[index + node];
> > cachep->nodelists[node]->next_reap = jiffies +
> > REAPTIMEOUT_LIST3 +
> > ((unsigned long)cachep) % REAPTIMEOUT_LIST3;
> > }
> > }
> >
> > It is supposed to be used only during early init and thus marked __init.
> > And initkmem_list3 is marked __initdata so that matches.
> >
> > But set_up_list3s() is used outside __init marked functions and thus result
> > in an error.
> >
> > I do not know how to fix this.
> >
>
> Yes, this is one of those rare places which triggers a warning but where no
> changes are needed.
>
> I'm thinking that we could address this with a new section __nowarn and
> __nowarndata (or whatever). These will have the same behaviour as regular
> .text and .data, only the symbol-checking tool would know about them and
> would suppress the warnings.
>
> Perhaps there's some other way of communication this information from the C
> level down into the checker - I haven't thought about it much.
The current approach is to rely on symbols being proper resolved but binutils
are playing tricks and does not always provide info to resolve static symbols.
Originally I thought this was pure inlining issues but it seems to be more than
that.
But introducing a special section just to say "references to .init.text" is OK
seems like a bit of overengineering to me.
I will give it a try during the coming week.
Sam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/5] fs: Mark link_path_walk static
On Sun, May 06, 2007 at 01:41:28PM -0400, Josef 'Jeff' Sipek wrote: > +/* forward declaration */ > +static int fastcall link_path_walk(const char *name, struct nameidata *nd); I don't think we need that comment, otherwise this looks 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 5/5] fs: Remove path_walk export
On Sun, May 06, 2007 at 01:41:29PM -0400, Josef 'Jeff' Sipek wrote: > Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]> > --- > fs/namei.c|3 +-- > include/linux/namei.h |1 - > 2 files changed, 1 insertions(+), 3 deletions(-) Ok. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] fs: Introduce vfs_path_lookup
On Sun, May 06, 2007 at 01:41:25PM -0400, Josef 'Jeff' Sipek wrote: > Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]> > --- > fs/namei.c| 32 > include/linux/namei.h |2 ++ > 2 files changed, 34 insertions(+), 0 deletions(-) Looks good to me. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/5] sunrpc: Use vfs_path_lookup
On Sun, May 06, 2007 at 01:41:26PM -0400, Josef 'Jeff' Sipek wrote: > use vfs_path_lookup instead of open-coding the necessary functionality. > > Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]> > Acked-by: Trond Myklebust <[EMAIL PROTECTED]> > --- > net/sunrpc/rpc_pipe.c | 16 +++- > 1 files changed, 7 insertions(+), 9 deletions(-) Looks good to me. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/5] nfsctl: Use vfs_path_lookup
On Sun, May 06, 2007 at 01:41:27PM -0400, Josef 'Jeff' Sipek wrote:
> use vfs_path_lookup instead of open-coding the necessary functionality.
>
> Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
> ---
> fs/nfsctl.c | 15 +--
> 1 files changed, 5 insertions(+), 10 deletions(-)
>
> diff --git a/fs/nfsctl.c b/fs/nfsctl.c
> index c043136..c97df14 100644
> --- a/fs/nfsctl.c
> +++ b/fs/nfsctl.c
> @@ -23,19 +23,14 @@
> static struct file *do_open(char *name, int flags)
> {
> struct nameidata nd;
> + struct vfsmount *mnt;
> int error;
>
> - nd.mnt = do_kern_mount("nfsd", 0, "nfsd", NULL);
> + mnt = do_kern_mount("nfsd", 0, "nfsd", NULL);
> + if (IS_ERR(mnt))
> + return (struct file *)mnt;
>
> - if (IS_ERR(nd.mnt))
> - return (struct file *)nd.mnt;
> -
> - nd.dentry = dget(nd.mnt->mnt_root);
> - nd.last_type = LAST_ROOT;
> - nd.flags = 0;
> - nd.depth = 0;
> -
> - error = path_walk(name, );
> + error = vfs_path_lookup(mnt->mnt_root, mnt, name, 0, );
> if (error)
> return ERR_PTR(error);
I think you're leaking a reference on the mount here as we didn't
do a mntget before. We need to do an additional mntput just after
the lookup to drop the reference from do_kern_mount.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Kernel-discuss] Re: [PATCH 3/8] Universal power supply class (was: battery class)
On Sat, May 05, 2007 at 03:39:40PM +0200, pHilipp Zabel wrote: > > > secondary notion too, as that is common. It would be generic. > > > > > > Or maybe I just didn't get the idea behind the "type" attribute :-) > > > > > > I'd appreciate if these were documented in the text file. > > > > I think I got the start point of confusion. It's indeed bad to call such > > power supply type as AC. Maybe I should it rename to ADAPTER? Or WALL? > > or MAINS? Philipp, much thanks! MAINS indeed feels perfect for that. -- Anton Vorontsov email: [EMAIL PROTECTED] backup email: [EMAIL PROTECTED] irc://irc.freenode.org/bd2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.21-mm1
On 06/05/07 21:08, Andrew Morton wrote:
On Sun, 06 May 2007 15:59:53 +0100 Simon Arlott <[EMAIL PROTECTED]> wrote:
On 05/05/07 09:49, Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm1/
I'm currently in the middle of a bisect over the last week of commits to linus'
Don't accidentally switch from SLAB to SLOB.
tree, but I got the following with -mm1 that isn't showing up in the latest
2.6.21-git:
[ 15.644778] BUG: sleeping function called from invalid context at
kernel/mutex.c:86
[ 15.644873] in_atomic():1, irqs_disabled():1
[ 15.644882] 2 locks held by modprobe/2765:
[ 15.644889] #0: (devlist_lock){--..}, at: [] mutex_lock+0x1f/0x30
[ 15.645058] #1: (modlist_lock){}, at: []
__symbol_get+0x1d/0x90
[ 15.645207] irq event stamp: 11772
[ 15.645271] hardirqs last enabled at (11771): []
slab_free+0xc3/0x200
[ 15.645289] hardirqs last disabled at (11772): []
_spin_lock_irqsave+0x16/0x60
[ 15.645364] softirqs last enabled at (11216): []
__do_softirq+0x96/0xb0
[ 15.645439] softirqs last disabled at (11211): []
do_softirq+0x82/0x100
[ 15.645517] [] show_trace_log_lvl+0x1a/0x30
[ 15.645586] [] show_trace+0x12/0x20
[ 15.645654] [] dump_stack+0x15/0x20
[ 15.645665] [] __might_sleep+0xcd/0xf0
[ 15.645737] [] mutex_lock+0x18/0x30
[ 15.645806] [] sysfs_create_link+0x6c/0x130
[ 15.645823] [] use_module+0x11a/0x170
[ 15.645892] [] __symbol_get+0x6c/0x90
[ 15.645904] [] dvb_init+0x98c/0xd70 [saa7134_dvb]
[ 15.645984] [] mpeg_ops_attach+0x3d/0x50
[ 15.646058] [] saa7134_ts_register+0x29/0x70
[ 15.646070] [] dvb_register+0x10/0x12 [saa7134_dvb]
[ 15.646141] [] sys_init_module+0xf7/0x150
[ 15.646153] [] sysenter_past_esp+0x5f/0x99
[ 15.646221] ===
Looks like a locking error in the DVB code.
And this fantastic Oops:
[ 40.965119] BUG: unable to handle kernel NULL pointer dereference at virtual
address 0080
[ 40.965252] printing eip:
[ 40.965252] b016d4a5
[ 40.965300] *pde =
[ 40.965352] Oops: [#1]
[ 40.965467] PREEMPT
It occurs when racoon is started so must be IPSEC related, I'll have more information
once I finish bisecting and merge -mm1 again.
Thanks.
Unfortunately I can't reproduce either of these anymore...
--
Simon Arlott
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.21-mm1
Hi Simon,
On 5/7/07, Satyam Sharma <[EMAIL PROTECTED]> wrote:
On 5/7/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Sun, 06 May 2007 15:59:53 +0100 Simon Arlott <[EMAIL PROTECTED]> wrote:
>
> > On 05/05/07 09:49, Andrew Morton wrote:
> > >
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm1/
> >
> > I'm currently in the middle of a bisect over the last week of commits to
linus'
> > tree, but I got the following with -mm1 that isn't showing up in the latest
> > 2.6.21-git:
> >
> > [ 15.644778] BUG: sleeping function called from invalid context at
kernel/mutex.c:86
> > [ 15.644873] in_atomic():1, irqs_disabled():1
> > [ 15.644882] 2 locks held by modprobe/2765:
> > [ 15.644889] #0: (devlist_lock){--..}, at: []
mutex_lock+0x1f/0x30
> > [ 15.645058] #1: (modlist_lock){}, at: []
__symbol_get+0x1d/0x90
> > [ 15.645207] irq event stamp: 11772
> > [ 15.645271] hardirqs last enabled at (11771): []
slab_free+0xc3/0x200
> > [ 15.645289] hardirqs last disabled at (11772): []
_spin_lock_irqsave+0x16/0x60
> > [ 15.645364] softirqs last enabled at (11216): []
__do_softirq+0x96/0xb0
> > [ 15.645439] softirqs last disabled at (11211): []
do_softirq+0x82/0x100
> > [ 15.645517] [] show_trace_log_lvl+0x1a/0x30
> > [ 15.645586] [] show_trace+0x12/0x20
> > [ 15.645654] [] dump_stack+0x15/0x20
> > [ 15.645665] [] __might_sleep+0xcd/0xf0
> > [ 15.645737] [] mutex_lock+0x18/0x30
> > [ 15.645806] [] sysfs_create_link+0x6c/0x130
> > [ 15.645823] [] use_module+0x11a/0x170
> > [ 15.645892] [] __symbol_get+0x6c/0x90
> > [ 15.645904] [] dvb_init+0x98c/0xd70 [saa7134_dvb]
> > [ 15.645984] [] mpeg_ops_attach+0x3d/0x50
> > [ 15.646058] [] saa7134_ts_register+0x29/0x70
> > [ 15.646070] [] dvb_register+0x10/0x12 [saa7134_dvb]
> > [ 15.646141] [] sys_init_module+0xf7/0x150
> > [ 15.646153] [] sysenter_past_esp+0x5f/0x99
> > [ 15.646221] ===
>
> Looks like a locking error in the DVB code.
Actually, kernel/module.c:__symbol_get() does
spinlock_irq_save(_lock) and then calls use_module().
But when CONFIG_MODULE_UNLOAD=y, use_module() wants to
sysfs_create_link() (I wonder why) which will clearly blow up.
Ah, at first I thought you had CONFIG_MODULE_UNLOAD=y for 21-mm and =n
for 21-git which is why you weren't able to reproduce this on 21-git.
But on checking I found 21-git has a different __symbol_get which
calls strong_try_module_get(owner) directly and not use_module().
Perhaps Andrew missed this patch?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Kernel-discuss] Re: [PATCH 3/8] Universal power supply class (was: battery class)
On Sun, May 06, 2007 at 03:09:37PM -0300, Henrique de Moraes Holschuh wrote: > On Sat, 05 May 2007, ian wrote: > > On Sat, 2007-05-05 at 00:54 -0300, Henrique de Moraes Holschuh wrote: > > > > > Given that USB-power *is* usually also "dumb" (i.e. it doesn't do any > > > control signaling over the USB bus for power-control purposes), > > > > it might be dumb, but it is useful to know wether the PDA is charging > > from usb or mains power. and some devices allow one to switch on / off > > the ability to charge via usb > > Which, at the proper abstraction level provided by this class, means that it > allows one to switch on or off a power supply channel. > > Laptops let one do this with their batteries, too. It is the same thing. I > didn't check if the class comes with an attribute for "enable/disable this > power source", but if doesn't, we need to add one: it *is* a generic and > widely used capability in laptops, and according to you, also on PDAs. Yup, this is simple matter of adding such attribute (plus implemention of set_property function, which is trivial). -- Anton Vorontsov email: [EMAIL PROTECTED] backup email: [EMAIL PROTECTED] irc://irc.freenode.org/bd2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] the OLPC laptop is not available for $100
On Sat, May 05, 2007 at 07:30:52PM +0200, Adrian Bunk wrote: > On Sat, May 05, 2007 at 01:49:55AM -0700, Andrew Morton wrote: > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm1/ > > > > > > - Added the git-battery tree to the -mm lineup (Anton Vorontsov > > <[EMAIL PROTECTED]>). It presently generates mysterious depmod error > > messages. > >... > > Changes since 2.6.21-rc7-mm2: > >... > > git-battery.patch > >... > > git trees > >... > > The price might drop to $100 in a few years. > > But currently, a more reasonable name might be "$175 laptop". > > Let's simply call it "OLPC laptop" without any price tag. > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> Both patches applied. Thanks! -- Anton Vorontsov email: [EMAIL PROTECTED] backup email: [EMAIL PROTECTED] irc://irc.freenode.org/bd2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.21-mm1
On Sun, 6 May 2007 22:57:32 +0200 Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> On Sun, May 06, 2007 at 02:49:49AM -0400, [EMAIL PROTECTED] wrote:
> > On Sat, 05 May 2007 01:49:55 PDT, Andrew Morton said:
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm1/
> >
> > MODPOST vmlinux
> > WARNING: mm/built-in.o - Section mismatch: reference to .init.text: from
> > .text between 'kmem_cache_create' (at offset 0x20dff) and 'cache_reap'
> > WARNING: mm/built-in.o - Section mismatch: reference to .init.text: from
> > .text between 'kmem_cache_create' (at offset 0x20e41) and 'cache_reap'
> >
> > Built with CONFIG_SLAB, CONFIG_SMP, x86_64.
>
> It comes from this code (mm/slab.c):
> /*
> * For setting up all the kmem_list3s for cache whose buffer_size is same as
> * size of kmem_list3.
> */
> static void __init set_up_list3s(struct kmem_cache *cachep, int index)
> {
> int node;
>
> for_each_online_node(node) {
> cachep->nodelists[node] = _list3[index + node];
> cachep->nodelists[node]->next_reap = jiffies +
> REAPTIMEOUT_LIST3 +
> ((unsigned long)cachep) % REAPTIMEOUT_LIST3;
> }
> }
>
> It is supposed to be used only during early init and thus marked __init.
> And initkmem_list3 is marked __initdata so that matches.
>
> But set_up_list3s() is used outside __init marked functions and thus result
> in an error.
>
> I do not know how to fix this.
>
Yes, this is one of those rare places which triggers a warning but where no
changes are needed.
I'm thinking that we could address this with a new section __nowarn and
__nowarndata (or whatever). These will have the same behaviour as regular
.text and .data, only the symbol-checking tool would know about them and
would suppress the warnings.
Perhaps there's some other way of communication this information from the C
level down into the checker - I haven't thought about it much.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.21-mm1
On 06/05/07 21:54, Andrew Morton wrote: On Sun, 06 May 2007 21:36:32 +0100 Simon Arlott <[EMAIL PROTECTED]> wrote: On 05/05/07 09:49, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm1/ Not sure exactly what's going on here, but it happened with a lock held on my (XFS) filesystem while compiling part of the kernel because I can't do anything with it now. [ 1128.122000] BUG: sleeping function called from invalid context at block/cfq-iosched.c:1895 [ 1128.122000] in_atomic():1, irqs_disabled():0 [ 1128.122000] INFO: lockdep is turned off. [ 1128.122000] BUG: unable to handle kernel paging request at virtual address 8b0c4034 [ 1128.122000] printing eip: [ 1128.122000] b0104e36 [ 1128.123000] *pde = [ 1128.123000] Oops: [#1] [ 1128.123000] PREEMPT [ 1128.123000] Modules linked in: drbd mt352 saa7134_dvb dvb_pll video_buf_dvb dvb_core [ 1128.123000] CPU:0 [ 1128.123000] EIP:0060:[]Not tainted VLI [ 1128.123000] EFLAGS: 00010246 (2.6.21-git #195) [ 1128.123000] EIP is at dump_trace+0x66/0xb0 [ 1128.123000] eax: ebx: b18f6fd0 ecx: b06323ec edx: b05afc71 [ 1128.123000] esi: 8b0c4000 edi: 8b0c4ffd ebp: b18f6fd0 esp: b18f6fb8 [ 1128.123000] ds: 007b es: 007b fs: gs: ss: 0068 [ 1128.123000] Process pdflush (pid: 186, ti=b18f6000 task=eff88b10 task.ti=b18f7000) [ 1128.123000] Stack: b000205d fffc b05b9937 efd1adb4 0010 b18f6ff0 b0104f3a [ 1128.123000]b06323ec b05b9937 b05d33e6 efd1adb4 b05d33e6 b18f7000 b0104f62 [ 1128.123000]b05b9937 b18f700c [ 1128.123000] Call Trace: [ 1128.123000] [] show_trace_log_lvl+0x1a/0x30 [ 1128.123000] [] show_stack_log_lvl+0x8b/0xb0 [ 1128.123000] [] show_registers+0x1c3/0x320 [ 1128.123000] [] die+0x105/0x230 [ 1128.123000] [] do_page_fault+0x2cf/0x5b0 [ 1128.123000] [] error_code+0x6a/0x70 [ 1128.123000] [] show_trace_log_lvl+0x1a/0x30 [ 1128.123000] [] show_trace+0x12/0x20 [ 1128.123000] === [ 1128.123000] Code: 18 8b 4d 08 8b 45 0c 8b 53 04 ff 51 08 8b 03 39 d8 76 06 89 c3 39 f3 77 e4 8b 4d 08 ba 71 fc 5a b0 8b 45 0c ff 51 0c 85 c0 78 38 <8b> 76 34 85 f6 74 31 8d 76 00 e8 bb d7 00 00 eb b3 89 eb eb af [ 1128.123000] EIP: [] dump_trace+0x66/0xb0 SS:ESP 0068:b18f6fb8 Mess. Someone incorrectly called the IO scheduler under a spinlock (or similar), CFQ tried to do a dump_stack(), but the dump_stack() code exploded. Usually this happens when the x86_64 tree contains stacktrace improvements, but the unwinder (at least) wasn't present in -mm1. How come those addresses are 0xb0.., btw? You're running a different vm split? I'm using CONFIG_VMSPLIT_3G_OPT, yes. -- Simon Arlott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Ext3 vs NTFS performance
On Fri, 4 May 2007 10:46:10 +0100, Christoph Hellwig wrote: > > Which means the right place to fix this is samba. Samba just need > to intersept lseek and pread/pwrite to never allocate sparse files > but do the right thing instead. Now what the right thing would probably > be a preallocate instead of writing zeroes, and we need to provide the > infrastructure for them to do it, which is in progress currently. Why do preallocate and not just truncate the file? If the write is a single 0x00 somewhere beyond EOF, as appears to be the pattern, truncate will do just as well if not better. And it is available now. Jörn -- Joern's library part 6: http://www.gzip.org/zlib/feldspar.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
