question regarding the Linux block device cache
Hi, I am working on a file system that allow multiple files to share data blocks. That is, a data block can be shared by two or more files. Now my question is: suppose file A and B share the same data block D. Now a process open file A and read block D, then this process closes file A. If another process open file B and read block D right after the first process closes A, is the data of block D read from some cache or has to be loaded from disk again? I think this has to do with the Linux block device buffer cache. But I am not quite familiar with this part. Can someone help me or direct me to the right place to find the answer? Thanks in advance! -x - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC] Delete JFFS (version 1)
> I argue that you can count the users (who aren't on 2.4) on one hand, and > developers don't seem to have cared for it in ages. Rather than ask on mailing-lists, it's probably easier to just make the jffs compilation fail (with a #error). This way, if someone uses it, he'll bump into it, no matter how much he wants to ignore messages posted on mailing-lists. Stefan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] fs: introduce perform_write aop
On Fri, Mar 09, 2007 at 10:39:13AM +, Christoph Hellwig wrote: > > One problem with this interface is that it cannot be used to write into the > > filesystem by any means other than already-initialised buffers via iovecs. > > So > > prepare/commit have to stay around for non-user data... > > Actually I think that's a a good thing to a certain extent. It reminds > us that all other users are horrible abuse of the interface. I'd even > go so far as to make batch_write a callback that the filesystem passes > to generic_file_aio_write to make clear it's not a generic thing but > a helper. (It's not a generic thing because it's the upper layer writing > into the pagecache, not a pagecache to fs below operation). > > The still leaves open on how to get rid of ->prepare_write and ->commit_write > compltely, and for that we'll probably need ->kernel_read and ->kernel_write > file operations. But that's a step you shouldn't consider yet when doing > this work. ->kernel_write() as opposed to genericizing ->perform_write() would be fine with me. Just so long as we get rid of ->prepare_write and ->commit_write in that other kernel code doesn't call them directly. That interface just doesn't work for Ocfs2. There, we have the triple whammy of having to order cluster locks with page locks, avoiding nesting cluster locks in the case that the user data has to be paged in (causing a lock in ->readpage()) and grabbing / zeroing adjacent pages to fill holes. So, a combination of ->perform_write and ->kernel_write() could really help me solve my write woes. Right now I've got Ocfs2 implementing it's own lowest-level buffered write code - think generic_file_buffered_write() replacement for Ocfs2. With some duplicated code above that layer. What's nice is that I can abstract away the "copy data into some target pages" bits such that the majority of that code is re-usable for ocfs2's splice write operation. I'm not sure we could have that low a level of abstraction for anyhing above individual the file system though which also has to deal with non-kernel writes though. That's where a ->kernel_write() might come in handy. --Mark -- Mark Fasheh Senior Software Developer, Oracle [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: question regarding the Linux block device cache
I read the code and found that a block buffer is not necessarily freed even if the corresponding inode is released. Looks like block buffer can stay around as long as the system still has free memory. Is my understanding correct? -x On 3/9/07, Xin Zhao <[EMAIL PROTECTED]> wrote: Hi, I am working on a file system that allow multiple files to share data blocks. That is, a data block can be shared by two or more files. Now my question is: suppose file A and B share the same data block D. Now a process open file A and read block D, then this process closes file A. If another process open file B and read block D right after the first process closes A, is the data of block D read from some cache or has to be loaded from disk again? I think this has to do with the Linux block device buffer cache. But I am not quite familiar with this part. Can someone help me or direct me to the right place to find the answer? Thanks in advance! -x - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kernel OOPSes when changing DVB-T adapter in 2.6.21-rc3
Hi, I am trying change Freecom DVB-T dongle with Leadtek DVB-T dongle and I got this OOPS: -- usb 2-3: new high speed USB device using ehci_hcd and address 2 usb 2-3: configuration #1 chosen from 1 choice dvb-usb: found a 'WideView WT-220U PenType Receiver (Typhoon/Freecom)' in cold state, will try to load a firmware dvb-usb: downloading firmware from file 'dvb-usb-wt220u-02.fw' usbcore: registered new interface driver dvb_usb_dtt200u usb 2-3: USB disconnect, address 2 dvb-usb: generic DVB-USB module successfully deinitialized and disconnected. usb 2-3: new high speed USB device using ehci_hcd and address 3 usb 2-3: configuration #1 chosen from 1 choice dvb-usb: found a 'WideView WT-220U PenType Receiver (Typhoon/Freecom)' in warm state. dvb-usb: will use the device's hardware PID filter (table count: 15). DVB: registering new adapter (WideView WT-220U PenType Receiver (Typhoon/Freecom)). DVB: registering frontend 0 (WideView USB DVB-T)... input: IR-receiver inside an USB DVB receiver as /class/input/input18 dvb-usb: schedule remote query interval to 300 msecs. dvb-usb: WideView WT-220U PenType Receiver (Typhoon/Freecom) successfully initialized and connected. dvb-usb: recv bulk message failed: -110 usb 2-3: USB disconnect, address 3 BUG: unable to handle kernel paging request at virtual address 00100100 printing eip: c027552d *pde = 36209067 *pte = Oops: [#1] PREEMPT Modules linked in: dvb_usb_dtt200u dvb_usb dvb_core dvb_pll ppp_deflate zlib_deflate bsd_comp ppp_async ppp_generic slhc bnep rfcomm hidp l2cap lp fuse eeprom hci_usb bluetooth eth1394 usbhid 8250_pci 8250 serial_core nsc_ircc snd_intel8x0m snd_intel8x0 snd_ac97_codCT 24ec irda ide_cd ac97_bus snd_pcm snd_timer snd parport_pc cdrom crc_ccitt ohci1394 ieee1394 8139too mii snd_page_alloc parport ohci_hcd i2c_i801 psmouse pcspkr iTCO_wdt iTCO_vendor_support rtc uhci_hcd ehci_hcd CPU:0 EIP:0060:[]Not tainted VLICT 24 EFLAGS: 00010206 (2.6.21-rc3 #2) EIP is at evdev_disconnect+0x87/0xae eax: ebx: 000ffcf0 ecx: c1916000 edx: f616e000 esi: e7520dc0 edi: f697d800 ebp: f697dec4 esp: c1917e78 ds: 007b es: 007b fs: 00d8 gs: ss: 0068 Process khubd (pid: 130, ti=c1916000 task=c18fea70 task.ti=c1916000) Stack: c037b488 e7520df0 c0273983 e33ba000 f6f7fc18 fcc2a420 f1673800 fcc1319f e33ba000 fcc122da fcc29502 f6f7fc18 fcc2a420 f1673800 fcc12386 f6f7fc18 fcc2a420 f6f7fc00 c0266522 ffed f6f7fc18 fcc2a44c Call Trace: [] input_unregister_device+0x89/0x111 [] dvb_usb_remote_exit+0x27/0x32 [dvb_usb] [] dvb_usb_exit+0xb/0x87 [dvb_usb] [] dvb_usb_device_exit+0x30/0x44 [dvb_usb] [] usb_unbind_interface+0x3e/0x7c [] __device_release_driver+0x6e/0x8b [] device_release_driver+0x1d/0x32 [] bus_remove_device+0x5b/0x69 [] device_del+0xfa/0x152 [] usb_disable_device+0x5c/0xbb [] usb_disconnect+0x82/0x114 [] hub_thread+0x375/0xa76 [] __sched_text_start+0x4a9/0x54c [] __wake_up_common+0x31/0x4f [] autoremove_wake_function+0x0/0x35 [] hub_thread+0x0/0xa76 [] kthread+0xa0/0xc8 [] kthread+0x0/0xc8 [] kernel_thread_helper+0x7/0x10 === Code: e8 fc 0e ea ff 8b 5e 4c eb 1b 8d 83 08 04 00 00 b9 06 00 02 00 ba 1d 00 00 00 e8 b5 df ee ff 8b 9b 10 04 00 00 81 eb 10 04 00 00 <8b> 83 10 04 00 00 0f 18 00 90 8d 93 10 04 00 00 8d 46 4c 39 c2 EIP: [] evdev_disconnect+0x87/0xae SS:ESP 0068:c1917e78 - Thanks for fix 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: [PATCH] dvb-core: Fix several locking related problems.
On Sun, Mar 04, 2007 at 05:45:54PM +, Simon Arlott wrote:
> Fix several instances of dvb-core functions using mutex_lock_interruptible
> and returning -ERESTARTSYS where the calling function will either never
> retry or never check the return value.
>
> These cause a race condition with dvb_dmxdev_filter_free and
> dvb_dvr_release, both of which are filesystem release functions whose
> return value is ignored and will never be retried. When this happens it
> becomes impossible to open dvr0 again (-EBUSY) since it has not been
> released properly.
>
> Signed-off-by: Simon Arlott <[EMAIL PROTECTED]>
Acked-By: Johannes Stezenbach <[EMAIL PROTECTED]>
I can't test this but to me it looks good.
Mauro, could you please pick it up and keep it in the
linuxtv.org repository for a while for testing?
Thanks,
Johannes
> ---
> On 04/03/07 15:41, Andreas Oberritter wrote:
> >please send an updated patch together with
> >Signed-off-by line to Mauro <[EMAIL PROTECTED]> and ask him to apply
> >it for inclusion into the -mm tree for further testing.
>
> Unless there are other -mm trees I've not heard about, presumably I should
> just do this myself. Doesn't linux-dvb have it's own development tree this
> would get better tested in?
>
> The dvb_dvr_release change has been working for me for 6 months and the
> dvb_dmxdev_filter_free (dvb_dmxdev_filter_free) change looks equivalent.
> See http://www.linuxtv.org/pipermail/linux-dvb/2007-February/016120.html
> for an example of the bug before and after fixing.
>
> All the other changes run ok for me but should have lockdep enabled when
> testing (if there's a possible deadlock somewhere, using _interruptible
> will hide it).
>
> drivers/media/dvb/dvb-core/dmxdev.c| 12 +++-
> drivers/media/dvb/dvb-core/dvb_demux.c | 21 +++--
> drivers/media/dvb/dvb-core/dvbdev.c|9 +++--
> 3 files changed, 13 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/media/dvb/dvb-core/dmxdev.c
> b/drivers/media/dvb/dvb-core/dmxdev.c
> index fc77de4..a5c0e1a 100644
> --- a/drivers/media/dvb/dvb-core/dmxdev.c
> +++ b/drivers/media/dvb/dvb-core/dmxdev.c
> @@ -180,8 +180,7 @@ static int dvb_dvr_release(struct inode *inode, struct
> file *file)
> struct dvb_device *dvbdev = file->private_data;
> struct dmxdev *dmxdev = dvbdev->priv;
>
> - if (mutex_lock_interruptible(>mutex))
> - return -ERESTARTSYS;
> + mutex_lock(>mutex);
>
> if ((file->f_flags & O_ACCMODE) == O_WRONLY) {
> dmxdev->demux->disconnect_frontend(dmxdev->demux);
> @@ -673,13 +672,8 @@ static int dvb_demux_open(struct inode *inode, struct
> file *file)
> static int dvb_dmxdev_filter_free(struct dmxdev *dmxdev,
> struct dmxdev_filter *dmxdevfilter)
> {
> - if (mutex_lock_interruptible(>mutex))
> - return -ERESTARTSYS;
> -
> - if (mutex_lock_interruptible(>mutex)) {
> - mutex_unlock(>mutex);
> - return -ERESTARTSYS;
> - }
> + mutex_lock(>mutex);
> + mutex_lock(>mutex);
>
> dvb_dmxdev_filter_stop(dmxdevfilter);
> dvb_dmxdev_filter_reset(dmxdevfilter);
> diff --git a/drivers/media/dvb/dvb-core/dvb_demux.c
> b/drivers/media/dvb/dvb-core/dvb_demux.c
> index fcff5ea..6d8d1c3 100644
> --- a/drivers/media/dvb/dvb-core/dvb_demux.c
> +++ b/drivers/media/dvb/dvb-core/dvb_demux.c
> @@ -673,8 +673,7 @@ static int dmx_ts_feed_stop_filtering(struct
> dmx_ts_feed *ts_feed)
> struct dvb_demux *demux = feed->demux;
> int ret;
>
> - if (mutex_lock_interruptible(>mutex))
> - return -ERESTARTSYS;
> + mutex_lock(>mutex);
>
> if (feed->state < DMX_STATE_GO) {
> mutex_unlock(>mutex);
> @@ -748,8 +747,7 @@ static int dvbdmx_release_ts_feed(struct dmx_demux *dmx,
> struct dvb_demux *demux = (struct dvb_demux *)dmx;
> struct dvb_demux_feed *feed = (struct dvb_demux_feed *)ts_feed;
>
> - if (mutex_lock_interruptible(>mutex))
> - return -ERESTARTSYS;
> + mutex_lock(>mutex);
>
> if (feed->state == DMX_STATE_FREE) {
> mutex_unlock(>mutex);
> @@ -916,8 +914,7 @@ static int dmx_section_feed_stop_filtering(struct
> dmx_section_feed *feed)
> struct dvb_demux *dvbdmx = dvbdmxfeed->demux;
> int ret;
>
> - if (mutex_lock_interruptible(>mutex))
> - return -ERESTARTSYS;
> + mutex_lock(>mutex);
>
> if (!dvbdmx->stop_feed) {
> mutex_unlock(>mutex);
> @@ -942,8 +939,7 @@ static int dmx_section_feed_release_filter(struct
> dmx_section_feed *feed,
> struct dvb_demux_feed *dvbdmxfeed = (struct dvb_demux_feed *)feed;
> struct dvb_demux *dvbdmx = dvbdmxfeed->demux;
>
> - if (mutex_lock_interruptible(>mutex))
> - return -ERESTARTSYS;
> + mutex_lock(>mutex);
>
> if (dvbdmxfilter->feed != dvbdmxfeed) {
> mutex_unlock(>mutex);
> @@ -1016,8 +1012,7 @@
Re: [PATCH 0/2] resource control file system - aka containers on top of nsproxy!
On 3/9/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote: 1. What is the fundamental unit over which resource-management is applied? Individual tasks or individual containers? /me thinks latter. Yes In which case, it makes sense to stick resource control information in the container somewhere. Yes, that's what all my patches have been doing. 2. Regarding space savings, if 100 tasks are in a container (I dont know what is a typical number) -and- lets say that all tasks are to share the same resource allocation (which seems to be natural), then having a 'struct container_group *' pointer in each task_struct seems to be not very efficient (simply because we dont need that task-level granularity of managing resource allocation). I think you should re-read my patches. Previously, each task had N pointers, one for its container in each potential hierarchy. The container_group concept means that each task has 1 pointer, to a set of container pointers (one per hierarchy) shared by all tasks that have exactly the same set of containers (in the various different hierarchies). It doesn't give task-level granularity of resource management (unless you create a separate container for each task), it just gives a space saving. 3. This next leads me to think that 'tasks' file in each directory doesnt make sense for containers. In fact it can lend itself to error situations (by administrator/script mistake) when some tasks of a container are in one resource class while others are in a different class. Instead, from a containers pov, it may be usefull to write a 'container id' (if such a thing exists) into the tasks file which will move all the tasks of the container into the new resource class. This is the same requirement we discussed long back of moving all threads of a process into new resource class. I think you need to give a more concrete example and use case of what you're trying to propose here. I don't really see what advantage you're getting. Paul - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] rcfs core patch
On Fri, Mar 09, 2007 at 11:44:22PM +0530, Srivatsa Vaddagiri wrote: > On Fri, Mar 09, 2007 at 01:48:16AM +0100, Herbert Poetzl wrote: > > > There have been various projects attempting to provide resource > > > management support in Linux, including CKRM/Resource Groups and UBC. > > let me note here, once again, that you forgot Linux-VServer > > which does quite non-intrusive resource management ... > Sorry, not intentionally. Maybe it slipped because I haven't > seen much res mgmt related patches from Linux Vserver on > lkml recently. mainly because I got the impression that we planned to work on the various spaces first, and handle things like resource management later .. but it seems that resource management is now in focus, while the spaces got somewhat delayed ... > Note that I -did- talk about VServer at one point in past > (http://lkml.org/lkml/2006/06/15/112)! noted and appreciated (although this was about CPU resources, which IMHO is a special resource like the networking, as you are mostly interested in 'bandwidth' limitations there, not in resource limits per se (and of course, it wasn't even cited correctly, as it is Linux-VServer not vserver ...) > > the basic 'context' (pid space) is the grouping mechanism > > we use for resource management too > so tasks sharing the same nsproxy->pid_ns is the fundamental > unit of resource management (as far as vserver/container goes)? we currently have a 'process' context, which holds the administrative data (capabilities and flags) and the resource accounting and limits, which basically contains the pid namespace, so yes and no it contains a reference to the 'main' nsproxy, which is used to copy spaces from when you enter the guest (or some set of spaces), and it defines the unit we consider a process container > > > As you know, the introduction of 'struct container' was objected > > > to and was felt redundant as a means to group tasks. Thats where > > > I took a shot at converting over Paul Menage's patch to avoid > > > 'struct container' abstraction and insead work with 'struct > > > nsproxy'. > > > > which IMHO isn't a step in the right direction, as > > you will need to handle different nsproxies within > > the same 'resource container' (see previous email) > > Isn't that made simple because of the fact that we have pointers to > namespace objects (and not actual objects themselves) in nsproxy? > > I mean, all that is required to manage multiple nsproxy's > is to have the pointer to the same resource object in all of them. > > In system call terms, if someone does a unshare of uts namespace, > he will get into a new nsproxy object sure (which has a pointer to the > new uts namespace) but the new nsproxy object will still be pointing > to the old resource controlling objects. yes, that is why I agreed, that the container (or resource limit/accounting/controlling object) can be seen as space too (and handled like that) > > > When we support task movement across resource classes, we need to > > > find a nsproxy which has the right combination of resource classes > > > that the task's nsproxy can be hooked to. > > > > no, not necessarily, we can simply create a new one > > and give it the proper resource or whatever-spaces > > That would be the simplest, agreeably. But not optimal in terms of > storage? > > Pls note that task-movement can be not-so-infrequent > (in other words, frequent) in context of non-container workload > management. not only there, also with solutions like Linux-VServer (it is quite common to enter guests or subsets of the space mix assigned) > > why is the filesystem approach so favored for this > > kind of manipulations? > > > > IMHO it is one of the worst interfaces I can imagine > > (to move tasks between spaces and/or assign resources) > > but yes, I'm aware that filesystems are 'in' nowadays > > Ease of use maybe. Scripts can be more readily used with a fs-based > interface. correct, but what about security and/or atomicity? i.e. how to assure that some action really was taken and/or how to wait for completion? sure, all this _can_ be done, no doubt, but it is much harder to do with a fs based interface than with e.g. a syscall interface ... > -- > Regards, > vatsa > ___ > Containers mailing list > [EMAIL PROTECTED] > https://lists.osdl.org/mailman/listinfo/containers - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] rcfs core patch
On Fri, Mar 09, 2007 at 11:25:47AM -0800, Paul Jackson wrote: > > Ease of use maybe. Scripts can be more readily used with a fs-based > > interface. > > And, as I might have already stated, file system API's are a natural > fit for hierarchically shaped data, especially if the nodes in the > hierarchy would benefit from file system like permission attributes. personally, I'd prefer to avoid hierarchical structures wherever possible, because they tend to make processing and checks a lot more complicated than necessary, and if we really want hierarchical structures, it might be more than sufficient to keep the hierarchy in userspace, and use a flat representation inside the kernel ... but hey, I'm all for running a hypervisor under a hypervisor running inside a hypervisor :) best, Herbert > -- > I won't rest till it's the best ... > Programmer, Linux Scalability > Paul Jackson <[EMAIL PROTECTED]> 1.925.600.0401 > ___ > Containers mailing list > [EMAIL PROTECTED] > https://lists.osdl.org/mailman/listinfo/containers - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] rcfs core patch
On Fri, Mar 09, 2007 at 11:27:07PM +0530, Srivatsa Vaddagiri wrote: > On Fri, Mar 09, 2007 at 01:38:19AM +0100, Herbert Poetzl wrote: > > > 2) you allow a task to selectively reshare namespaces/subsystems with > > >another task, i.e. you can update current->task_proxy to point to > > >a proxy that matches your existing task_proxy in some ways and the > > >task_proxy of your destination in others. In that case a trivial > > >implementation would be to allocate a new task_proxy and copy some > > >pointers from the old task_proxy and some from the new. But then > > >whenever a task moves between different groupings it acquires a > > >new unique task_proxy. So moving a bunch of tasks between two > > >groupings, they'd all end up with unique task_proxy objects with > > >identical contents. > > this is exactly what Linux-VServer does right now, and I'm > > still not convinced that the nsproxy really buys us anything > > compared to a number of different pointers to various spaces > > (located in the task struct) > Are you saying that the current scheme of storing pointers to > different spaces (uts_ns, ipc_ns etc) in nsproxy doesn't buy > anything? > Or are you referring to storage of pointers to resource > (name)spaces in nsproxy doesn't buy anything? > In either case, doesn't it buy speed and storage space? let's do a few examples here, just to illustrate the advantages and disadvantages of nsproxy as separate structure over nsproxy as part of the task_struct 1) typical setup, 100 guests as shell servers, 5 tasks each when unused, 10 tasks when used 10% used in average a) separate nsproxy, we need at least 100 structs to handle that (saves some space) we might end up with ~500 nsproxies, if the shell clones a new namespace (so might not save that much space) we do a single inc/dec when the nsproxy is reused, but do the full N inc/dec when we have to copy an nsproxy (might save some refcounting) we need to do the indirection step, from task to nsproxy to space (and data) b) we have ~600 tasks with 600 times the nsproxy data (uses up some more space) we have to do the full N inc/dev when we create a new task (more refcounting) we do not need to do the indirection, we access spaces directly from the 'hot' task struct (makes hot pathes quite fast) so basically we trade a little more space and overhead on task creation for having no indirection to the data accessed quite often throughout the tasks life (hopefully) 2) context migration: for whatever reason, we decide to migrate a task into a subset (space mix) of a context 1000 times a) separate nsproxy, we need to create a new one consisting of the 'new' mix, which will - allocate the nsproxy struct - inc refcounts to all copied spaces - inc refcount nsproxy and assign to task - dec refcount existing task nsproxy after task completion - dec nsproxy refcount - dec refcounts for all spaces - free up nsproxy struct b) nsproxy data in task struct - inc/dec refcounts to changed spaces after task completion - dec refcounts to spaces so here we gain nothing with the nsproxy, unless the chosen subset is identical to the one already used, where we end up with a single refcount instead of N > > I'd prefer to do accounting (and limits) in a very simple > > and especially performant way, and the reason for doing > > so is quite simple: > Can you elaborate on the relationship between data structures > used to store those limits to the task_struct? sure it is one to many, i.e. each task points to exactly one context struct, while a context can consist of zero, one or many tasks (no back- pointers there) > Does task_struct store pointers to those objects directly? it contains a single pointer to the context struct, and that contains (as a substruct) the accounting and limit information HTC, Herbert > -- > Regards, > vatsa > ___ > Containers mailing list > [EMAIL PROTECTED] > https://lists.osdl.org/mailman/listinfo/containers - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] rcfs core patch
Herbert wrote: > personally, I'd prefer to avoid hierarchical > structures wherever possible, Sure - avoid them if you like. But sometimes they work out rather well. And file system API's are sometimes the best fit for them. I'm all for choosing the simplest API topology that makes sense. But encoding higher dimension topologies into lower dimension API's, just because they seem "simpler" results in obfuscation, convolution and obscurity, which ends up costing everyone more than getting the natural fit. "Make everything as simple as possible, but not simpler." -- Albert Einstein -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.925.600.0401 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] resource control file system - aka containers on top of nsproxy!
I think maybe I didnt communicate what I mean by a container here (although I thought I did). I am referring to a container in a vserver context (set of tasks which share the same namespace). On Fri, Mar 09, 2007 at 02:09:35PM -0800, Paul Menage wrote: > >2. Regarding space savings, if 100 tasks are in a container (I dont know > > what is a typical number) -and- lets say that all tasks are to share > > the same resource allocation (which seems to be natural), then having > > a 'struct container_group *' pointer in each task_struct seems to be not > > very efficient (simply because we dont need that task-level granularity > > of > > managing resource allocation). > > I think you should re-read my patches. > > Previously, each task had N pointers, one for its container in each > potential hierarchy. The container_group concept means that each task > has 1 pointer, to a set of container pointers (one per hierarchy) > shared by all tasks that have exactly the same set of containers (in > the various different hierarchies). Ok, let me see if I can convey what I had in mind better: uts_ns pid_ns ipc_ns \|/ --- | nsproxy| / | \\ <-- 'nsproxy' pointer T1 T2 T3 ...T1000 | | | | <-- 'containers' pointer (4/8 KB for 1000 task) --- | container_group | -- / -- | container | -- | -- | cpu_limit | -- (T1, T2, T3 ..T1000) are part of a vserver lets say sharing the same uts/pid/ipc_ns. Now where do we store the resource control information for this unit/set-of-tasks in your patches? (tsk->containers->container[cpu_ctlr.hierarchy] + X)->cpu_limit (The X is to account for the fact that cotainer structure points to a 'struct container_subsys_state' embedded in some other structure. Its usually zero if the structure is embedded at the top) I understand that container_group also points directly to 'struct container_subsys_state', in which case, the above is optimized to: (tsk->containers->subsys[cpu_ctlr.subsys_id] + X)->cpu_limit Did I get that correct? Compare that to: --- | cpu_limit | uts_ns pid_ns ipc_ns -- \|/ | |nsproxy | / | \| T1 T2 T3 .T1000 We save on 4/8 KB (for 1000 tasks) by avoiding the 'containers' pointer in each task_struct (just to get to the resource limit information). So my observation was (again note primarily from a vserver context): given that (T1, T2, T3 ..T1000) will all need to be managed as a unit (because they are all sharing the same nsproxy pointer), then having the '->containers' pointer in -each- one of them to tell the unit's limit is not optimal. Instead store the limit in the proper unit structure (in this case nsproxy - but whatever else is more suitable vserver datastructure (pid_ns?) which represent the fundamental unit of res mgmt in vservers). (I will respond to remaining comments later ..too early in the morning now!) -- Regards, vatsa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] resource control file system - aka containers on top of nsproxy!
On Sat, Mar 10, 2007 at 12:11:05AM +0530, Srivatsa Vaddagiri wrote: > On Fri, Mar 09, 2007 at 02:16:08AM +0100, Herbert Poetzl wrote: > > On Thu, Mar 08, 2007 at 05:00:54PM +0530, Srivatsa Vaddagiri wrote: > > > On Thu, Mar 08, 2007 at 01:50:01PM +1300, Sam Vilain wrote: > > > > 7. resource namespaces > > > > > > It should be. Imagine giving 20% bandwidth to a user X. X wants to > > > divide this bandwidth further between multi-media (10%), kernel > > > compilation (5%) and rest (5%). So, > > > > sounds quite nice, but ... > > > > > > Is the subservient namespace's resource usage counting against > > > > ours too? > > > > > > Yes, the resource usage of children should be accounted when capping > > > parent resource usage. > > > > it will require to do accounting many times > > (and limit checks of course), which in itself > > might be a way to DoS the kernel by creating > > more and more resource groups > > I was only pointing out the usefullness of the feature and not > necessarily saying it -should- be implemented! Ofcourse I understand it > will make the controller complicated and thats why probably none of the > recontrollers we are seeing posted on lkml don't support hierarchical > res mgmt. > > > > > Can we dynamically alter the subservient namespace's resource > > > > allocations? > > > > > > Should be possible yes. That lets user X completely manage his > > > allocation among whatever sub-groups he creates. > > > > what happens if the parent changes, how is > > the resource change (if it was a reduction) > > propagated to the children? > > > > e.g. your guest has 1024 file handles, now > > you reduce it to 512, but the guest had two > > children, both with 256 file handles each ... > > I believe CKRM handled this quite neatly (by defining child shares to be > relative to parent shares). > > In your example, 256+256 add up to 512 which is within the parent's > new limit, so nothing happens :) yes, but that might as well be fatal, because now the children can easily DoS the parent by using up all the file handles, where the 'original' setup (2 x 256) left 512 file handles 'reserved' ... of course, you could as well have adjusted that to 2 x 128 + 256 for the parent, but that is policy and IMHO policy does not belong into the kernel, it should be handled by userspace (maybe invoked by the kernel in some kind of helper functionality or so) > You also picked an example of exhaustible/non-reclaimable resource, > which makes it hard to define what should happen if parent's limit > goes below 512. which was quite intentional, and brings us to another issues when adjusting resource limits (not even in a hierarchical way) > Either nothing happens or perhaps a task is killed, don't know. > In case of memory, I would say that some of child's pages may > get kicked out and in case of cpu, child will start getting fewer > cycles. btw, kicking out pages when rss limit is reached might be the obvious choice (if we think Virtual Machine here) but it might not be the best choice from the overall performance PoV, which might be much better off by keeping the page in memory (if there is enough memory available) but penalizing the guest like the page was actually kicked out (and needs to be fetched later on) note: this is something we should think about when we want to address specific limits like RSS, because IMHO we should not optimize for the single guest case, but for the big picture ... > > > The patches should give visibility to both nsproxy objects (by > > > showing what tasks share the same nsproxy objects and letting > > > tasks move across nsproxy objects if allowed) and the resource > > > control objects pointed to by nsproxy (struct cpuset, struct > > > cpu_limit, struct rss_limit etc). > > > > the nsproxy is not really relevant, as it > > is some kind of strange indirection, which > > does not necessarily depict the real relations, > > regardless wether you do the re-sharing of > > those nsproies or not .. > > So what are you recommending we do instead? > My thought was whatever is the fundamental unit to which resource > management needs to be applied, lets store resource parameters (or > pointers to them) there (rather than duplicating the information in > each task_struct). we do not want to duplicate any information in the task struct, but we might want to put some (or maybe all) of the spaces back (as pointer reference) to the task struct, just to avoid the nsproxy indirection note that IMHO not all spaces make sense to be separated e.g. while it is quite useful to have network and pid space separated, others might be joined to form larger consistant structures ... for example, I could as well live with pid and resource accounting/limits sharing one common struct/space ... (doesn't mean that separate spaces are not nice :) best, Herbert > -- > Regards, > vatsa > ___ > Containers mailing list > [EMAIL PROTECTED] >
Re: [ckrm-tech] [PATCH 0/2] resource control file system - aka containers on top of nsproxy!
On Sat, Mar 10, 2007 at 07:32:20AM +0530, Srivatsa Vaddagiri wrote:
> Ok, let me see if I can convey what I had in mind better:
>
> uts_ns pid_ns ipc_ns
> \|/
> ---
> | nsproxy|
>
> / | \\ <-- 'nsproxy' pointer
> T1 T2 T3 ...T1000
> | | | | <-- 'containers' pointer (4/8 KB for 1000 task)
> ---
> | container_group |
> --
> /
>--
> | container |
>--
> |
>--
> | cpu_limit |
>--
[snip]
> We save on 4/8 KB (for 1000 tasks) by avoiding the 'containers' pointer
> in each task_struct (just to get to the resource limit information).
Having the 'containers' pointer in each task-struct is great from a
non-container res mgmt perspective. It lets you dynamically decide what
is the fundamental unit of res mgmt.
It could be {T1, T5} tasks/threads of a process, or {T1, T3, T8, T10} tasks of
a session (for limiting login time per session), or {T1, T2 ..T10, T18, T27}
tasks of a user etc.
But from a vserver/container pov, this level flexibility (at a -task- level) of
deciding the unit of res mgmt is IMHO not needed. The
vserver/container/namespace (tsk->nsproxy->some_ns) to which a task
belongs automatically defines that unit of res mgmt.
--
Regards,
vatsa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] futex: restartable futex_wait
LTP test sigaction_16_24 fails, because it expects sem_wait to be restarted
if SA_RESTART is set. sem_wait is implemented with futex_wait, that currently
doesn't support being restarted. Ulrich confirms that the call should be
restartable.
Implement a restart_block method to handle the relative timeout, and allow
restarts.
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
Index: linux-2.6/kernel/futex.c
===
--- linux-2.6.orig/kernel/futex.c
+++ linux-2.6/kernel/futex.c
@@ -978,6 +978,7 @@ static void unqueue_me_pi(struct futex_q
drop_futex_key_refs(>key);
}
+static long futex_wait_restart(struct restart_block *restart);
static int futex_wait(u32 __user *uaddr, u32 val, unsigned long time)
{
struct task_struct *curr = current;
@@ -1077,11 +1078,22 @@ static int futex_wait(u32 __user *uaddr,
return 0;
if (time == 0)
return -ETIMEDOUT;
+
/*
* We expect signal_pending(current), but another thread may
* have handled it for us already.
*/
- return -EINTR;
+ if (time == MAX_SCHEDULE_TIMEOUT)
+ return -ERESTARTSYS;
+ else {
+ struct restart_block *restart;
+ restart = _thread_info()->restart_block;
+ restart->fn = futex_wait_restart;
+ restart->arg0 = (unsigned long)uaddr;
+ restart->arg1 = (unsigned long)val;
+ restart->arg2 = time;
+ return -ERESTART_RESTARTBLOCK;
+ }
out_unlock_release_sem:
queue_unlock(, hb);
@@ -1091,6 +1103,17 @@ static int futex_wait(u32 __user *uaddr,
return ret;
}
+static long futex_wait_restart(struct restart_block *restart)
+{
+ u32 __user *uaddr = (u32 __user *)restart->arg0;
+ u32 val = (u32)restart->arg1;
+ unsigned long time = restart->arg2;
+
+ restart->fn = do_no_restart_syscall;
+ return (long)futex_wait(uaddr, val, time);
+}
+
+
/*
* Userspace tried a 0 -> TID atomic transition of the futex value
* and failed. The kernel side here does the whole locking operation:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: SATA resume slowness, e1000 MSI warning
"Kok, Auke" <[EMAIL PROTECTED]> writes: > Eric W. Biederman wrote: > > [CHOP] > >> Below is an additional set of warnings that should help debug this. >> The old code just got lucky that it triggered a warning when this happens. > > > I'm trying this patch together with the other 2 that you sent out a few days > ago. I'm seeing some minor issues with this and lots of bogus warnings as far > as > I can see. > > If I suspend/resume and unload e1000, then reinsert e1000.ko, I immediately > hit > the WARN_ON at `msi.c:516: WARN_ON(!hlist_empty(>saved_cap_space));` > > I'm not sure that's useful debugging information. even though saved state > exists > the module has been removed, so you might want to purge the state table when > the > driver gets removed? > > > anyway, back to testing. Sorry I should have been clear. With the last two patches I sent out: pci: Repair pci_save/restore_state so we can restore one save many times. msi: Safer state caching. Those WARN_ON's are now totally bogus. In essence the WARN_ON's were testing to ensure pci_save_state and pci_restore_state were paired. The assumptions was that pci_restore_state would remove everything from the list that pci_save_state placed on it. When I reworked the code and removed the bogus pairing requirement it meant that if we ever save state and have a pci-e or pci-x capability we will have a state structure on the list until the kernel reboots. In summary: pci_save_state and pci_restore_state were making a wrong assumption about the world. The WARN_ON patch tested to ensure the world matched those functions. When I fixed those functions to match the world the WARN_ON's became completely bogus. 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: 2.6.21-rc3-mm2: BUG: at drivers/pci/pci.c:679 pci_restore_state during suspend testing
Andrew Morton <[EMAIL PROTECTED]> writes: >> On Fri, 9 Mar 2007 01:13:14 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]> >> wrote: >> I get the following traces from 2.6.21-rc3-mm2 during the "resume" phase >> of testing with 'echo test > /sys/power/disk && echo disk > >> /sys/power/state': >> >> acpi thermal:00: resuming >> pci :00:00.0: resuming >> pcieport-driver :00:01.0: resuming >> BUG: at drivers/pci/pci.c:679 pci_restore_state() >> >> Call Trace: >> [] pci_restore_state+0x229/0x270 >> [] pcie_portdrv_restore_config+0x19/0x40 >> [] pcie_portdrv_resume+0x11/0x20 >> [] pci_device_resume+0x2c/0x70 >> [] resume_device+0xe1/0x160 >> [] dpm_resume+0xa9/0x110 >> [] device_resume+0x48/0x60 >> [] pm_suspend_disk+0x235/0x250 >> [] enter_state+0x65/0x250 >> [] state_store+0x7a/0xa0 >> [] subsys_attr_store+0x24/0x30 >> [] sysfs_write_file+0x100/0x140 >> [] vfs_write+0xdf/0x180 >> [] sys_write+0x50/0x90 >> [] system_call+0x7e/0x83 > > Yes, a number of people (including myself) have been hitting these > new warnings. I don't think we know why yet, but Eric is offline > for a bit and I'm travelling. We'll sort it out over the next few > weeks I guess. I'm online again. I had fun getting caught in the trailing edge of a blizzard in Nebraska earlier but I have found my way back to my apartment and my computer and friends. Jeff Garzik is the one who really spotted what the problem is. He pointed out that pci_save_state and pci_restore_state have not historically required being paired (as the usually are during suspend and resume) and there is a practical use in resetting devices for not requiring them to be paired. The recent additions to pci_save_state and pci_restore_state for the msi, pci-e, pci-x all assumed those calls would be paired, and thus allocated a buffer on save and freed the buffer and restore. My WARN_ON's tested to ensure all of the buffers were freed. However drivers like the tg3 that use pci_save/restore_state for more than just suspend/resume wind up triggering the warning. I have recently sent out two patches to remove the pairing requirement but I haven't figured out suspend/resume for any of my machines so I couldn't test them. 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/
[GIT PATCH] PCI fixes for 2.6.21-rc3
Here are some PCI fixes against 2.6.21-rc3 They fix a problem that shows up with the libata drivers and fix a number of section mismatches. All of these have been in the -mm tree. Please pull from: master.kernel.org:/pub/scm/linux/kernel/git/gregkh/pci-2.6.git/ The full patches will be sent to the linux-pci mailing list, if anyone wants to see it thanks, greg k-h drivers/pci/pci.c | 15 --- drivers/pci/pcie/aer/aerdrv.c |6 +++--- drivers/pci/pcie/portdrv_pci.c |6 +++--- drivers/pci/search.c |2 +- 4 files changed, 15 insertions(+), 14 deletions(-) --- Sam Ravnborg (3): pcie: fix section mismatch warning PCI: aer: fix section mismatch warning pci: fix section mismatch warning Tejun Heo (1): PCI: allow multiple calls to pcim_pin_device() - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 PATCH] Driver core fixes for 2.6.21-rc3
Here are some driver core fixes for 2.6.21-rc3. They fix the following thing: - fix reference counting bug when removing any driver module from the system by reverting a previous "fix". - allow older versions of HAL to find network devices even if CONFIG_SYSFS_DEPRECATED is disabled. - fix an oops when moving kobjects to the same destination location as they currently are caused by the bluetooth layer. - export a symbol to allow the wireless core to be built as a module - remove the devfs entry in the MAINTAINERS file. All of these have been in the -mm tree. Please pull from: master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6.git/ Patches will be sent as a follow-on to this message to lkml for people to see. thanks, greg k-h MAINTAINERS |3 --- drivers/base/core.c | 23 ++- kernel/module.c |6 -- lib/kobject.c |2 ++ 4 files changed, 16 insertions(+), 18 deletions(-) --- Dmitriy Monakhov (1): kobject: new_device->kref wasn't putted after error in kobject_move() Greg Kroah-Hartman (2): Revert "driver core: refcounting fix" Driver core: add device symlink back to sysfs Johannes Berg (1): driver core: export device_rename J??rn Engel (1): Remove devfs from MAINTAINERS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/5] Revert "driver core: refcounting fix"
This reverts commit 63ce18cfe685115ff8d341bae4c9204a79043cf0. It was the incorrect fix and causes a reference counting bug whenever any driver module is removed from the system. Mike Galbraith <[EMAIL PROTECTED]> is looking for the real fix for his problem. Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- kernel/module.c |6 -- 1 files changed, 0 insertions(+), 6 deletions(-) diff --git a/kernel/module.c b/kernel/module.c index f77e893..fbc51de 100644 --- a/kernel/module.c +++ b/kernel/module.c @@ -2419,12 +2419,6 @@ void module_remove_driver(struct device_driver *drv) kfree(driver_name); } } - /* -* Undo the additional reference we added in module_add_driver() -* via kset_find_obj() -*/ - if (drv->mod_name) - kobject_put(>kobj); } EXPORT_SYMBOL(module_remove_driver); #endif -- 1.5.0.2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] Driver core: add device symlink back to sysfs
This moves the device symlink back to sysfs even if
CONFIG_SYSFS_DEPRECATED is enabled as too many userspace programs (well,
HAL), still rely on this link to be present.
I will rework the ability for sysfs to change layouts like this in the
future, but for now, this patch should fix people's network connections.
Cc: Kay Sievers <[EMAIL PROTECTED]>
Cc: Matt Mackall <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/base/core.c | 21 +
1 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 89ebe36..fb16f29 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -584,17 +584,17 @@ int device_add(struct device *dev)
if (dev->kobj.parent != >class->subsys.kset.kobj)
sysfs_create_link(>class->subsys.kset.kobj,
>kobj, dev->bus_id);
-#ifdef CONFIG_SYSFS_DEPRECATED
if (parent) {
sysfs_create_link(>kobj, >parent->kobj,
"device");
+#ifdef CONFIG_SYSFS_DEPRECATED
class_name = make_class_name(dev->class->name,
>kobj);
if (class_name)
sysfs_create_link(>parent->kobj,
>kobj, class_name);
- }
#endif
+ }
}
if ((error = device_add_attrs(dev)))
@@ -651,17 +651,17 @@ int device_add(struct device *dev)
if (dev->kobj.parent != >class->subsys.kset.kobj)
sysfs_remove_link(>class->subsys.kset.kobj,
dev->bus_id);
-#ifdef CONFIG_SYSFS_DEPRECATED
if (parent) {
+#ifdef CONFIG_SYSFS_DEPRECATED
char *class_name = make_class_name(dev->class->name,
>kobj);
if (class_name)
sysfs_remove_link(>parent->kobj,
class_name);
kfree(class_name);
+#endif
sysfs_remove_link(>kobj, "device");
}
-#endif
down(>class->sem);
/* notify any interfaces that the device is now gone */
@@ -761,17 +761,17 @@ void device_del(struct device * dev)
if (dev->kobj.parent != >class->subsys.kset.kobj)
sysfs_remove_link(>class->subsys.kset.kobj,
dev->bus_id);
-#ifdef CONFIG_SYSFS_DEPRECATED
if (parent) {
+#ifdef CONFIG_SYSFS_DEPRECATED
char *class_name = make_class_name(dev->class->name,
>kobj);
if (class_name)
sysfs_remove_link(>parent->kobj,
class_name);
kfree(class_name);
+#endif
sysfs_remove_link(>kobj, "device");
}
-#endif
down(>class->sem);
/* notify any interfaces that the device is now gone */
@@ -1071,8 +1071,8 @@ static int device_move_class_links(struct device *dev,
struct device *old_parent,
struct device *new_parent)
{
+ int error = 0;
#ifdef CONFIG_SYSFS_DEPRECATED
- int error;
char *class_name;
class_name = make_class_name(dev->class->name, >kobj);
@@ -1100,7 +1100,12 @@ out:
kfree(class_name);
return error;
#else
- return 0;
+ if (old_parent)
+ sysfs_remove_link(>kobj, "device");
+ if (new_parent)
+ error = sysfs_create_link(>kobj, _parent->kobj,
+ "device");
+ return error;
#endif
}
--
1.5.0.2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] kobject: new_device->kref wasn't putted after error in kobject_move()
From: Dmitriy Monakhov <[EMAIL PROTECTED]> If error happen we jump to "out" label, in this case new_device not yet became the parent but it wasn't putted. Signed-off-by: Monakhov Dmitriy <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- lib/kobject.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/lib/kobject.c b/lib/kobject.c index f4f6176..057921c 100644 --- a/lib/kobject.c +++ b/lib/kobject.c @@ -385,9 +385,11 @@ int kobject_move(struct kobject *kobj, struct kobject *new_parent) goto out; old_parent = kobj->parent; kobj->parent = new_parent; + new_parent = NULL; kobject_put(old_parent); kobject_uevent_env(kobj, KOBJ_MOVE, envp); out: + kobject_put(new_parent); kobject_put(kobj); kfree(devpath_string); kfree(devpath); -- 1.5.0.2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] Remove devfs from MAINTAINERS
From: Jörn Engel <[EMAIL PROTECTED]> Remove last remaining trace of devfs. Signed-off-by: Jörn Engel <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- MAINTAINERS |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 9993b90..17555bb 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1103,9 +1103,6 @@ W:http://lanana.org/docs/device-list/index.html L: linux-kernel@vger.kernel.org S: Maintained -DEVICE FILESYSTEM -S: Obsolete - DIGI INTL. EPCA DRIVER P: Digi International, Inc M: [EMAIL PROTECTED] -- 1.5.0.2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/5] driver core: export device_rename
From: Johannes Berg <[EMAIL PROTECTED]> In wireless we'd like to allow renaming of the phy devices we surface in sysfs. The base wireless code, however, can be built modular and thus we need device_rename exported. Signed-off-by: Johannes Berg <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- drivers/base/core.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/base/core.c b/drivers/base/core.c index fb16f29..f191afe 100644 --- a/drivers/base/core.c +++ b/drivers/base/core.c @@ -1065,7 +1065,7 @@ int device_rename(struct device *dev, char *new_name) return error; } - +EXPORT_SYMBOL_GPL(device_rename); static int device_move_class_links(struct device *dev, struct device *old_parent, -- 1.5.0.2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] pcie: fix section mismatch warning
From: Sam Ravnborg <[EMAIL PROTECTED]>
Fix following section mismatch warning (when compiled with CONFIG_HOTPLUG=n):
WARNING: drivers/pci/built-in.o - Section mismatch: reference to
.init.text:pcie_portdrv_probe from .data between 'pcie_portdrv' (at offset
0xe40) and 'pcie_portdrv_err_handler'
This warning was fixed by renaming pcie_portdrv to pcie_portdriver so we pass
the whitelist.
Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/pci/pcie/portdrv_pci.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/pcie/portdrv_pci.c b/drivers/pci/pcie/portdrv_pci.c
index f17e7ed..0be5a0b 100644
--- a/drivers/pci/pcie/portdrv_pci.c
+++ b/drivers/pci/pcie/portdrv_pci.c
@@ -276,7 +276,7 @@ static struct pci_error_handlers pcie_portdrv_err_handler =
{
.resume = pcie_portdrv_err_resume,
};
-static struct pci_driver pcie_portdrv = {
+static struct pci_driver pcie_portdriver = {
.name = (char *)device_name,
.id_table = _pci_ids[0],
@@ -298,7 +298,7 @@ static int __init pcie_portdrv_init(void)
printk(KERN_WARNING "PCIE: bus_register error: %d\n", retval);
goto out;
}
- retval = pci_register_driver(_portdrv);
+ retval = pci_register_driver(_portdriver);
if (retval)
pcie_port_bus_unregister();
out:
@@ -307,7 +307,7 @@ static int __init pcie_portdrv_init(void)
static void __exit pcie_portdrv_exit(void)
{
- pci_unregister_driver(_portdrv);
+ pci_unregister_driver(_portdriver);
pcie_port_bus_unregister();
}
--
1.5.0.2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] PCI: allow multiple calls to pcim_pin_device()
From: Tejun Heo <[EMAIL PROTECTED]>
Sanity check in pcim_pin_device() was too restrictive in that it didn't
allow multiple calls to the function, which is against the devres
philosohpy of fire-and-forget. Track pinned status separately and allow
pinning multiple times.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Acked-by: Ian McDonald <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/pci/pci.c | 15 ---
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index df49530..a32db06 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -757,7 +757,8 @@ int pci_enable_device(struct pci_dev *dev)
* when a device is enabled using managed PCI device enable interface.
*/
struct pci_devres {
- unsigned int disable:1;
+ unsigned int enabled:1;
+ unsigned int pinned:1;
unsigned int orig_intx:1;
unsigned int restore_intx:1;
u32 region_mask;
@@ -781,7 +782,7 @@ static void pcim_release(struct device *gendev, void *res)
if (this->restore_intx)
pci_intx(dev, this->orig_intx);
- if (this->disable)
+ if (this->enabled && !this->pinned)
pci_disable_device(dev);
}
@@ -820,12 +821,12 @@ int pcim_enable_device(struct pci_dev *pdev)
dr = get_pci_dr(pdev);
if (unlikely(!dr))
return -ENOMEM;
- WARN_ON(!!dr->disable);
+ WARN_ON(!!dr->enabled);
rc = pci_enable_device(pdev);
if (!rc) {
pdev->is_managed = 1;
- dr->disable = 1;
+ dr->enabled = 1;
}
return rc;
}
@@ -843,9 +844,9 @@ void pcim_pin_device(struct pci_dev *pdev)
struct pci_devres *dr;
dr = find_pci_dr(pdev);
- WARN_ON(!dr || !dr->disable);
+ WARN_ON(!dr || !dr->enabled);
if (dr)
- dr->disable = 0;
+ dr->pinned = 1;
}
/**
@@ -876,7 +877,7 @@ pci_disable_device(struct pci_dev *dev)
dr = find_pci_dr(dev);
if (dr)
- dr->disable = 0;
+ dr->enabled = 0;
if (atomic_sub_return(1, >enable_cnt) != 0)
return;
--
1.5.0.2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] PCI: aer: fix section mismatch warning
From: Sam Ravnborg <[EMAIL PROTECTED]>
Fix following section mismatch warning (when compiled with CONFIG_HOTPLUG=n):
WARNING: drivers/pci/built-in.o - Section mismatch: reference to
.init.text:aer_probe from .data between 'aerdrv' (at offset 0x1608) and
'aer_error_handlers'
Warning was fixed by renaming aerdrv to aerdriver so we pass the whitelist.
Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/pci/pcie/aer/aerdrv.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/pcie/aer/aerdrv.c b/drivers/pci/pcie/aer/aerdrv.c
index b164de0..db6ad8e 100644
--- a/drivers/pci/pcie/aer/aerdrv.c
+++ b/drivers/pci/pcie/aer/aerdrv.c
@@ -66,7 +66,7 @@ static struct pci_error_handlers aer_error_handlers = {
.resume = aer_error_resume,
};
-static struct pcie_port_service_driver aerdrv = {
+static struct pcie_port_service_driver aerdriver = {
.name = "aer",
.id_table = _id[0],
@@ -328,7 +328,7 @@ static void aer_error_resume(struct pci_dev *dev)
**/
static int __init aer_service_init(void)
{
- return pcie_port_service_register();
+ return pcie_port_service_register();
}
/**
@@ -338,7 +338,7 @@ static int __init aer_service_init(void)
**/
static void __exit aer_service_exit(void)
{
- pcie_port_service_unregister();
+ pcie_port_service_unregister();
}
module_init(aer_service_init);
--
1.5.0.2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Use more gcc extensions in the Linux headers
On Sat, 10 Mar 2007 09:57:32 +1100, Rusty Russell said: > +/* GCC is awesome. */ > #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) > \ > + sizeof(typeof(int[1 - 2*!!__builtin_types_compatible_p(typeof(arr), \ >typeof([0]))]))*0) -/* GCC is awesome. */ +/* GCC leaves me speechless. */ pgpYI648COpfb.pgp Description: PGP signature
[PATCH 4/4] pci: fix section mismatch warning
From: Sam Ravnborg <[EMAIL PROTECTED]>
drivers/pci/search.c caused following section mismatch warning
(if compiled with CONFIG_HOTPLUG=n):
WARNING: drivers/pci/built-in.o - Section mismatch: reference to .init.text:
from .text.pci_find_bus after 'pci_find_bus' (at offset 0x24)
This was due to pci_find_bus() calling a function marked __devinit.
Fix was to remove the __devinit from the offending function.
Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/pci/search.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/pci/search.c b/drivers/pci/search.c
index ff98ead..2dd8681 100644
--- a/drivers/pci/search.c
+++ b/drivers/pci/search.c
@@ -15,7 +15,7 @@
DECLARE_RWSEM(pci_bus_sem);
-static struct pci_bus * __devinit
+static struct pci_bus *
pci_do_find_bus(struct pci_bus* bus, unsigned char busnr)
{
struct pci_bus* child;
--
1.5.0.2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Use more gcc extensions in the Linux headers
On Fri, 09 Mar 2007 23:03:05 -0500 [EMAIL PROTECTED] wrote: > On Sat, 10 Mar 2007 09:57:32 +1100, Rusty Russell said: > > > +/* GCC is awesome. */ > > #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) > > \ > > + sizeof(typeof(int[1 - 2*!!__builtin_types_compatible_p(typeof(arr), \ > > typeof([0]))]))*0) > > -/* GCC is awesome. */ > +/* GCC leaves me speechless. */ "awesome" can mean "inspiring awe or admiration or wonder" (amazing) or it can mean "awful" (as in terrifying). 8) --- ~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/
[RFC PATCH 1/3] Add ability to keep track of callers of symbol_(get|put)
From: Trent Piepho <[EMAIL PROTECTED]>
When a module uses symbol_get() to increase the ref count of another
module, there is no record what module called symbol_get(). A module
can
show up as having other users, but there is no way to tell who those
users are.
This adds that ability to symbol_put() and symbol_get().
__symbol_get() and __symbol_put() get another parameter, which specifies
the module that is doing the getting or putting. symbol_put_addr() is
renamed to __symbol_put_addr() and has the same parameter added. The
module can be NULL, in which case the symbol's owner's refcount is
incremented without recording who did it, as was the case before.
The macros symbol_get(), symbol_put(), and symbol_put_addr() will use
THIS_MODULE as the getter/putter and so don't have an extra parameter.
A
macro symbol_put_user() is added that allows specifying the putting
module.
The module_use structure that keeps track of one modules use of another
gains a count member. The module_use will not go away until the count
goes down to zero. The count wasn't necessary before because a module
could only use another module once, when the module is linked in, and
un-use that module once, when it is unloaded.
When a module calls symbol_get() to get a symbol from module that owns
the symbol, the ref count of the owning module is _not_ incremented if
the getting module was already listed as using the owning module.
Rather, the count of that module_use is incremented.
When a module is loaded and the kernel module linker is resolving
symbols, it will not increment the module_use count for each symbol
used,
but will just leave it at one. We don't count each symbol resolved,
because during module unloading we wouldn't know how many times to
decrement the module_use count.
When the module is unloaded, the module_use count will only be
decremented by one, which should bring it to zero. If it's not zero,
then the remaining count is the number of symbol_get()s the module did
that were unmatched with a symbol_put().
Signed-off-by: Trent Piepho <[EMAIL PROTECTED]>
Signed-off-by: Mauro Carvalho Chehab <[EMAIL PROTECTED]>
diff --git a/include/linux/module.h b/include/linux/module.h
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -169,9 +169,10 @@ struct notifier_block;
#ifdef CONFIG_MODULES
/* Get/put a kernel symbol (calls must be symmetric) */
-void *__symbol_get(const char *symbol);
+void *__symbol_get(const char *symbol, struct module *user);
void *__symbol_get_gpl(const char *symbol);
-#define symbol_get(x) ((typeof())(__symbol_get(MODULE_SYMBOL_PREFIX
#x)))
+#define symbol_get(x) ((typeof())(__symbol_get(MODULE_SYMBOL_PREFIX
#x, \
+ THIS_MODULE)))
#ifndef __GENKSYMS__
#ifdef CONFIG_MODVERSIONS
@@ -388,9 +389,11 @@ extern void __module_put_and_exit(struct
#ifdef CONFIG_MODULE_UNLOAD
unsigned int module_refcount(struct module *mod);
-void __symbol_put(const char *symbol);
-#define symbol_put(x) __symbol_put(MODULE_SYMBOL_PREFIX #x)
-void symbol_put_addr(void *addr);
+void __symbol_put(const char *symbol, struct module *user);
+#define symbol_put(x) __symbol_put(MODULE_SYMBOL_PREFIX #x,
THIS_MODULE)
+#define symbol_put_user(x,u) __symbol_put(MODULE_SYMBOL_PREFIX #x, (u))
+void __symbol_put_addr(void *addr, struct module *user);
+#define symbol_put_addr(x) __symbol_put_addr((x), THIS_MODULE)
/* Sometimes we know we already have a refcount, and it's easier not
to handle the error case (which only happens with rmmod --wait). */
diff --git a/kernel/module.c b/kernel/module.c
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -516,30 +516,39 @@ struct module_use
{
struct list_head list;
struct module *module_which_uses;
+ int count;
};
-/* Does a already use b? */
-static int already_uses(struct module *a, struct module *b)
+/* Does a already use b? Return NULL if it doesn't, a pointer to the
+ relevant module_use structure if it does. */
+static struct module_use *already_uses(struct module *a, struct module
*b)
{
struct module_use *use;
list_for_each_entry(use, >modules_which_use_me, list) {
if (use->module_which_uses == a) {
DEBUGP("%s uses %s!\n", a->name, b->name);
- return 1;
+ return use;
}
}
DEBUGP("%s does not use %s!\n", a->name, b->name);
- return 0;
-}
-
-/* Module a uses b */
-static int use_module(struct module *a, struct module *b)
+ return NULL;
+}
+
+/* Module a uses b
+ If inc is set, then the use count will be incremented. */
+static int use_module(struct module *a, struct module *b, bool inc)
{
struct module_use *use;
int no_warn;
- if (b == NULL || already_uses(a, b)) return 1;
+ if (b == NULL) return 1;
+
+ if ((use = already_uses(a, b))) {
+ if (inc) use->count++;
+ DEBUGP("%s: %s already used %s, count now at
[RFC PATCH 2/3] Update mtd use of symbol_(get|put)
From: Trent Piepho <[EMAIL PROTECTED]>
Make the mtd sub-system work with changes to __symbol_get(). mtd calls
__symbol_get() directly, rather than through the symbol_get() macro
because it uses a string it created with sprintf to specify the symbol
to
attach to. It needs to be updated to supply THIS_MODULE as the user
parameter added to __symbol_get().
Signed-off-by: Trent Piepho <[EMAIL PROTECTED]>
diff --git a/drivers/mtd/chips/gen_probe.c
b/drivers/mtd/chips/gen_probe.c
--- a/drivers/mtd/chips/gen_probe.c
+++ b/drivers/mtd/chips/gen_probe.c
@@ -211,10 +211,10 @@ static inline struct mtd_info *cfi_cmdse
sprintf(probename, MODULE_SYMBOL_PREFIX "cfi_cmdset_%4.4X", type);
- probe_function = __symbol_get(probename);
+ probe_function = __symbol_get(probename, THIS_MODULE);
if (!probe_function) {
request_module(probename + sizeof(MODULE_SYMBOL_PREFIX) - 1);
- probe_function = __symbol_get(probename);
+ probe_function = __symbol_get(probename, THIS_MODULE);
}
if (probe_function) {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 3/3] Update dvb use of symbol_(get|put)
From: Trent Piepho <[EMAIL PROTECTED]>
Make the dvb sub-system use the ability of symbol_(put|get) to keep track
of what module did the putting or getting. In the dvb sub-system,
symbol_put is called through the macro dvb_attach(). A driver for a
bridge or card will attach frontends, tuners, or other helper drivers,
and this card driver will be listed as the user of the helper drivers.
When the card driver unloads, a single function in dvb-core,
dvb_frontend_detach(), will release all the helper drivers. Since the
get() happened in the card driver, but the put() is happening in
dvb-core, it is necessary to use __symbol_put_addr() so that a user other
than THIS_MODULE (which would be dvb-core, while we want the card driver)
can be specified.
Signed-off-by: Trent Piepho <[EMAIL PROTECTED]>
diff --git a/drivers/media/dvb/bt8xx/dst.c b/drivers/media/dvb/bt8xx/dst.c
--- a/drivers/media/dvb/bt8xx/dst.c
+++ b/drivers/media/dvb/bt8xx/dst.c
@@ -1718,12 +1718,9 @@ static void dst_release(struct dvb_front
if (state->dst_ca) {
dvb_unregister_device(state->dst_ca);
#ifdef CONFIG_DVB_CORE_ATTACH
- symbol_put(dst_ca_attach);
+ symbol_put_user(dst_ca_attach, fe->dvb->module);
#endif
}
-#ifdef CONFIG_DVB_CORE_ATTACH
- symbol_put(dst_attach);
-#endif
kfree(state);
}
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c
b/drivers/media/dvb/dvb-core/dvb_frontend.c
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -1127,19 +1127,20 @@ void dvb_frontend_detach(struct dvb_fron
void dvb_frontend_detach(struct dvb_frontend* fe)
{
void *ptr;
+ struct module *mod = fe->dvb->module;
if (fe->ops.release_sec) {
fe->ops.release_sec(fe);
- symbol_put_addr(fe->ops.release_sec);
+ __symbol_put_addr(fe->ops.release_sec, mod);
}
if (fe->ops.tuner_ops.release) {
fe->ops.tuner_ops.release(fe);
- symbol_put_addr(fe->ops.tuner_ops.release);
+ __symbol_put_addr(fe->ops.tuner_ops.release, mod);
}
ptr = (void*)fe->ops.release;
if (ptr) {
- fe->ops.release(fe);
- symbol_put_addr(ptr);
+ fe->ops.release(fe); /* This call will de-allocate fe! */
+ __symbol_put_addr(ptr, mod);
}
}
#else
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers/media/video/se401.c: check kmalloc() return value.
Hi Oliver, Em Sex, 2007-03-09 às 09:31 +0100, Oliver Neukum escreveu: > Am Freitag, 9. März 2007 08:30 schrieb Amit Choudhary: > > Description: Check the return value of kmalloc() in function > > se401_start_stream(), in file drivers/media/video/se401.c. > > Firstly, USB patches to the USB list. No. In this case, the proper lists for the devices under /drivers/media is the V4L mailing list (at video4linux-list@redhat.com and [EMAIL PROTECTED]), were you will reach the maintainers of those code (no matter if those devices are USB or not). Cheers, Mauro - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] proc: maps protection
Andrew Morton wrote: On Thu, 8 Mar 2007 12:55:25 -0800 Kees Cook <[EMAIL PROTECTED]> wrote: On Tue, Mar 06, 2007 at 08:22:11PM -0800, Arjan van de Ven wrote: [Adding Cc:lkml] How about using a reduced check, as is done for fd and environ? This would allow root-running system monitors to still do their job. Effectively, this changes the test from "is ptracing" to just "can ptrace". If this still isn't considered safe, I'll add the maps_protect file... btw I consider it an information leak that any user can see which files/libraries any other user and root has mmap'd. (and with glibc's stdio mmap feature that goes even beyond direct mmap to fopen()'d). If root or some other user wants to watch hillary-vs-obama-in-the-mud.avi, no other user has ANY business even seeing that. So at minimum it's a privacy issue showing the filenames... So, what's the state of this? Is the reduced "allowed to ptrace" check good enough for inclusion? What is needed for some form of this patch to be included? I'm happy to try new approaches if I can get some further input. I just don't know what it will break - we're changing things so that user A cannot monitor user B's memory maps. I feel that it's sure to break various people's fancy custom system activity monitoring/logging setups, and the sort of users who will be affected are, alas, the sort of people who won't run a kernel with this change in it for another couple of years yet. except if they run RHEL or FC kernels, in which case they already have that change Do we actually need to disable the whole interface? If all you're concerned about is the pathname then perhaps the knob could cause that pathname to be replaced with "". That'll cause things to break less seriously and still allows somewhat useful info to be gathered. the problem part is that you can see EXACLTY where glibc is loaded in memory, which effectively defeats address space randomization for local users - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ipv6 crash in latest git
# CONFIG_DEBUG_SHIRQ is not set Linux version 2.6.21-rc3-ga967e127 ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (SUSE Linu7 Command line: root=/dev/sda1 console=tty0 console=ttyS0,115200n8 debug ... Starting yum-updatesd: [ OK ] Starting Avahi daemon... [ OK ] Starting HAL daemon: Unable to handle kernel NULL pointer dereference at 0100 RIP: [] memcmp+0x8/0x22 PGD 0 Oops: [1] SMP CPU 0 Modules linked in: video sbs i2c_ec i2c_core dock asus_acpi backlight rtc_cmos Pid: 0, comm: swapper Not tainted 2.6.21-rc3-ga967e127 #21 RIP: 0010:[] [] memcmp+0x8/0x22 RSP: 0018:807bfd28 EFLAGS: 00010202 RAX: 00ff RBX: RCX: 0010 RDX: 0010 RSI: 810026020900 RDI: 0100 RBP: 0080 R08: 807bfe20 R09: 81003ecc9000 R10: R11: 0001 R12: 0004 R13: 8100360426c0 R14: 810026020800 R15: 807bfe20 FS: () GS:80726000() knlGS: CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b CR2: 0100 CR3: 3620 CR4: 06e0 Process swapper (pid: 0, threadinfo 8075e000, task 806bb480) Stack: 8051f24c 00808054b7d9 810026020900 0022 0100 810026020800 80720240 80720254 0001 807bfe20 Call Trace: [] fib6_add+0x9d/0x539 [] __ip6_ins_rt+0x32/0x47 [] ip6_pol_route_input+0x14a/0x1d1 [] ip6_route_input+0x84/0x8e [] ipv6_rcv+0x2ac/0x365 [] process_backlog+0x84/0x102 [] net_rx_action+0xa8/0x166 [] e1000_intr+0x10c/0x134 [] __do_softirq+0x55/0xc3 [] ack_apic_level+0x3a/0x4c [] call_softirq+0x1c/0x28 [] do_softirq+0x2c/0x7d [] do_IRQ+0x13e/0x160 [] mwait_idle+0x0/0x48 [] ret_from_intr+0x0/0xa [] datagram_poll+0x0/0xc8 [] mwait_idle+0x42/0x48 [] cpu_idle+0x8b/0xae [] start_kernel+0x29b/0x2a7 [] _sinittext+0x15c/0x160 Code: 0f b6 17 29 c2 89 d0 75 10 48 ff c7 48 ff c6 48 ff c9 48 85 RIP [] memcmp+0x8/0x22 RSP CR2: 0100 Kernel panic - not syncing: Aiee, killing interrupt handler! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Use more gcc extensions in the Linux headers
Hi. On Fri, 2007-03-09 at 23:03 -0500, [EMAIL PROTECTED] wrote: > On Sat, 10 Mar 2007 09:57:32 +1100, Rusty Russell said: > > > +/* GCC is awesome. */ > > #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) > > \ > > + sizeof(typeof(int[1 - 2*!!__builtin_types_compatible_p(typeof(arr), \ > > typeof([0]))]))*0) > > -/* GCC is awesome. */ > +/* GCC leaves me speechless. */ A speechless Rusty would be horrible. That said, it would be nice if the comment was something more like the normal Rusty pearl of wisdom. I understand the first part, but have no idea was + sizeof(typeof(int[ does... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Pluggable Schedulers (was: [ANNOUNCE] RSDL completely fair starvation free interactive cpu scheduler)
William Lee Irwin III wrote: > William Lee Irwin III wrote: > >> This sort of concern is too subjective for me to have an opinion on it. > > On Fri, Mar 09, 2007 at 11:43:46PM +0300, Al Boldi wrote: > > How diplomatic. > > Impoliteness doesn't accomplish anything I want to do. Fair enough. But being honest about it, without flaming, may be more constructive. > William Lee Irwin III wrote: > >> My preferred sphere of operation is the Manichean domain of faster vs. > >> slower, functionality vs. non-functionality, and the like. For me, such > >> design concerns are like the need for a kernel to format pagetables so > >> the x86 MMU decodes what was intended, or for a compiler to emit valid > >> assembly instructions, or for a programmer to write C the compiler > >> won't reject with parse errors. > > On Fri, Mar 09, 2007 at 11:43:46PM +0300, Al Boldi wrote: > > Sure, but I think, even from a technical point of view, competition is a > > good thing to have. Pluggable schedulers give us this kind of > > competition, that forces each scheduler to refine or become obsolete. > > Think evolution. > > I'm more of a cooperative than competitive person, not to say that > flies well in Linux. There are more productive uses of time than having > everyone NIH'ing everyone else's code. If the result isn't so great, > I'd rather send them code or talk them about what needs to be done. Ok, let's call it cooperative competitiveness. You know, the kind of competitiveness that drives improvements that helps everybody > Linus Torvalds wrote: > >> And hey, you can try to prove me wrong. Code talks. So far, nobody has > >> really ever come close. > >> So go and code it up, and show the end result. So far, nobody who > >> actually *does* CPU schedulers have really wanted to do it, because > >> they all want to muck around with their own private versions of the > >> data structures. > > On Fri, Mar 09, 2007 at 11:43:46PM +0300, Al Boldi wrote: > > What about PlugSched? > > The extant versions of it fall well short of Linus' challenge as well > as my original goals for it. Do you mean Peter Williams' PlugSched-6.5-for-2.6.20? > A useful exercise may also be enumerating > your expectations and having those who actually work with the code > describe how well those are actually met. A runtime configurable framework that allows for dynamically extensible schedulers. PlugSched seems to be a good start. Thanks! -- Al - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.21-rc3 snd-usb-audio lockdep report.
=
[ INFO: possible recursive locking detected ]
2.6.20-1.2962.fc7 #1
-
rosegardenseque/5229 is trying to acquire lock:
(>list_mutex){}, at: []
snd_seq_deliver_event+0x93/0x173 [snd_seq]
but task is already holding lock:
(>list_mutex){}, at: []
snd_seq_deliver_event+0x93/0x173 [snd_seq]
other info that might help us debug this:
1 lock held by rosegardenseque/5229:
#0: (>list_mutex){}, at: []
snd_seq_deliver_event+0x93/0x173 [snd_seq]
stack backtrace:
Call Trace:
[] __lock_acquire+0x151/0xbc4
[] lock_acquire+0x4c/0x65
[] :snd_seq:snd_seq_deliver_event+0x93/0x173
[] down_read+0x3e/0x4a
[] :snd_seq:snd_seq_deliver_event+0x93/0x173
[] :snd_seq:snd_seq_kernel_client_dispatch+0x54/0x68
[] :snd_seq_dummy:dummy_input+0x54/0x5a
[] :snd_seq:snd_seq_deliver_single_event+0xf8/0x1ec
[] :snd_seq:snd_seq_deliver_event+0xe2/0x173
[] :snd_seq:snd_seq_dispatch_event+0xed/0x110
[] :snd_seq:snd_seq_check_queue+0xbc/0x105
[] :snd_seq:snd_seq_enqueue_event+0xb6/0xca
[] :snd_seq:snd_seq_client_enqueue_event+0xcf/0x101
[] :snd_seq:snd_seq_write+0x140/0x198
[] vfs_write+0xcf/0x178
[] sys_write+0x47/0x70
[] tracesys+0xdc/0xe1
--
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: TCP MSG_PEEK assertion issue ...
Apologies ... I definitely had no idea where to post this thanks! Dave -Original Message- From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: linux-kernel@vger.kernel.org Sent: Fri, 9 Mar 2007 4:10 PM Subject: Re: TCP MSG_PEEK assertion issue ... Keep trying, you might hit the proper mailing list after a few more attempts. :-) Please post networking issues to netdev@vger.kernel.org, thank you. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ AOL now offers free email to everyone. Find out more about what's free from AOL at AOL.com. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] CIFS: reset file mode when CIFS client notices that ATTR_READONLY is no longer set
Jeff Layton wrote: This problem and patch were discovered and written by Alan Tyson of HP, who asked that I post this. The problem is this: When the CIFS client mounts a share that does not have Unix extensions, it will turn off the "w" bits in the file mode if it sees that ATTR_READONLY is set. It has no corresponding logic, however, to reenable write permissions if the ATTR_READONLY flag is later removed. This results in a situation where a file gets "stuck" as read-only. Steps to reproduce this bug are in the following samba.org BZ: https://bugzilla.samba.org/show_bug.cgi?id=4443 The patch below corrects this with the following logic: If unix extensions were not negotiated for the mount, and the server does not report ATTR_READONLY being set for the file then check the mode bits on the inode. If no write bits are set, then assume that ATTR_READONLY was previously set for this file but is not now, and set any write bits allowed by the mnt_file_mode. This logic seems reasonable, but I'm not certain that there aren't cases where it would fall down. Comments and/or ACK's appreciated... Signed-off-by: Jeff Layton <[EMAIL PROTECTED]> diff --git a/fs/cifs/inode.c b/fs/cifs/inode.c index 86b9dbb..e75a844 100644 --- a/fs/cifs/inode.c +++ b/fs/cifs/inode.c @@ -494,6 +494,12 @@ int cifs_get_inode_info(struct inode **pinode, mode e.g. 555 */ if (cifsInfo->cifsAttrs & ATTR_READONLY) inode->i_mode &= ~(S_IWUGO); + else if ((inode->i_mode & S_IWUGO) == 0) + /* the ATTR_READONLY flag may have been */ + /* changed on server -- set any w bits */ + /* allowed by mnt_file_mode */ + inode->i_mode |= (S_IWUGO & + cifs_sb->mnt_file_mode); /* BB add code here - validate if device or weird share or device type? */ } diff --git a/fs/cifs/readdir.c b/fs/cifs/readdir.c index 44cfb52..2a374d5 100644 --- a/fs/cifs/readdir.c +++ b/fs/cifs/readdir.c @@ -219,6 +219,10 @@ static void fill_in_inode(struct inode *tmp_inode, int new_buf_type, tmp_inode->i_mode |= S_IFREG; if (attr & ATTR_READONLY) tmp_inode->i_mode &= ~(S_IWUGO); + else if ((tmp_inode->i_mode & S_IWUGO) == 0) + /* the ATTR_READONLY flag may have been changed on */ + /* server -- set any w bits allowed by mnt_file_mode */ + tmp_inode->i_mode |= (S_IWUGO & cifs_sb->mnt_file_mode); } /* could add code here - to validate if device or weird share type? */ /* can not fill in nlink here as in qpathinfo version and Unx search */ OK - this is checked in to cifs tree. Let me know if you think it is important enough to push up at this stage to mainline. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] drivers: PMC MSP71xx LED driver
> On Fri, 9 Mar 2007 14:20:56 -0800 Marc St-Jean <[EMAIL PROTECTED]> wrote:
>
>
> > > +typedef enum {
> > > + MSP_LED_INPUT = 0,
> > > + MSP_LED_OUTPUT,
> > > +} msp_led_direction_t;
> >
> > No typedefs, please. Convert this to
> >
> > enum msp_led_direction {
> > ...
> > };
>
> Alright I'll change it but it wasn't mentioned in the review of
> the previous drivers and they've been resubmitted with some.
> A quick search shows several drivers typedef'ing enums with and
> without *_t suffixes.
Poeple do bad things, and it sometimes gets missed.
> Is there a new style rule or are only core kernel types allowed to
> use _t?
The general rule is: no typedefs.
typedefs make sense when the underlying type can change: u64, size_t,
resource_size_t, etc. We also use them for really hairy definitions like
filler_t. Nothing else. Please don't use them just to save typing.
>
> > > +/* Output modes */
> > > +typedef enum {
> > > + MSP_LED_OFF = 0,/* Off steady */
> > > + MSP_LED_ON, /* On steady */
> > > + MSP_LED_BLINK, /* On for initialPeriod, off
> > for finalPeriod */
> > > + MSP_LED_BLINK_INVERT, /* Off for initialPeriod, on for
> > finalPeriod */
> > > +} msp_led_mode_t;
> >
> > Ditto.
> >
> > > +/* For non-LED pins, these macros set HI and LO accordingly */
> > > +#define msp_led_pin_hi msp_led_turn_off
> > > +#define msp_led_pin_lo msp_led_turn_on
> >
> > eww.
> >
> > static inline wrapper functions are preferred. Write code in C, not cpp
> > where possible.
>
> I agree the wrappers are cleaner but don't understand how this relates
> to C++.
cpp == C preprocessor.
It would be better to do
/*
* nice comment goes here
*/
static inline void msp_led_pin_hi(...)
{
msp_led_turn_off(...);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 00/20] 2.6.20-stable review
This is the start of the stable review cycle for the 2.6.20.3 release. There are 20 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let us know. If anyone is a maintainer of the proper subsystem, and wants to add a Signed-off-by: line to the patch, please respond with it. These patches are sent out with a number of different people on the Cc: line. If you wish to be a reviewer, please email [EMAIL PROTECTED] to add your name to the list. If you want to be off the reviewer list, also email us. Responses should be made by Tuesday March 13 00:00:00 UTC. Anything received after that time might be too late. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 02/20] nf_conntrack/nf_nat: fix incorrect config ifdefs
-stable review patch. If anyone has any objections, please let us know. -- From: Patrick McHardy <[EMAIL PROTECTED]> [NETFILTER]: nf_conntrack/nf_nat: fix incorrect config ifdefs The nf_conntrack_netlink config option is named CONFIG_NF_CT_NETLINK, but multiple files use CONFIG_IP_NF_CONNTRACK_NETLINK or CONFIG_NF_CONNTRACK_NETLINK for ifdefs. Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- net/ipv4/netfilter/nf_nat_core.c |3 +-- net/ipv4/netfilter/nf_nat_proto_gre.c |3 +-- net/ipv4/netfilter/nf_nat_proto_icmp.c |3 +-- net/ipv4/netfilter/nf_nat_proto_tcp.c |3 +-- net/ipv4/netfilter/nf_nat_proto_udp.c |3 +-- net/netfilter/nf_conntrack_proto_gre.c |3 +-- 6 files changed, 6 insertions(+), 12 deletions(-) --- a/net/ipv4/netfilter/nf_nat_core.c +++ b/net/ipv4/netfilter/nf_nat_core.c @@ -540,8 +540,7 @@ void nf_nat_protocol_unregister(struct n } EXPORT_SYMBOL(nf_nat_protocol_unregister); -#if defined(CONFIG_IP_NF_CONNTRACK_NETLINK) || \ -defined(CONFIG_IP_NF_CONNTRACK_NETLINK_MODULE) +#if defined(CONFIG_NF_CT_NETLINK) || defined(CONFIG_NF_CT_NETLINK_MODULE) int nf_nat_port_range_to_nfattr(struct sk_buff *skb, const struct nf_nat_range *range) --- a/net/ipv4/netfilter/nf_nat_proto_gre.c +++ b/net/ipv4/netfilter/nf_nat_proto_gre.c @@ -152,8 +152,7 @@ static struct nf_nat_protocol gre __read .manip_pkt = gre_manip_pkt, .in_range = gre_in_range, .unique_tuple = gre_unique_tuple, -#if defined(CONFIG_IP_NF_CONNTRACK_NETLINK) || \ -defined(CONFIG_IP_NF_CONNTRACK_NETLINK_MODULE) +#if defined(CONFIG_NF_CT_NETLINK) || defined(CONFIG_NF_CT_NETLINK_MODULE) .range_to_nfattr= nf_nat_port_range_to_nfattr, .nfattr_to_range= nf_nat_port_nfattr_to_range, #endif --- a/net/ipv4/netfilter/nf_nat_proto_icmp.c +++ b/net/ipv4/netfilter/nf_nat_proto_icmp.c @@ -78,8 +78,7 @@ struct nf_nat_protocol nf_nat_protocol_i .manip_pkt = icmp_manip_pkt, .in_range = icmp_in_range, .unique_tuple = icmp_unique_tuple, -#if defined(CONFIG_IP_NF_CONNTRACK_NETLINK) || \ -defined(CONFIG_IP_NF_CONNTRACK_NETLINK_MODULE) +#if defined(CONFIG_NF_CT_NETLINK) || defined(CONFIG_NF_CT_NETLINK_MODULE) .range_to_nfattr= nf_nat_port_range_to_nfattr, .nfattr_to_range= nf_nat_port_nfattr_to_range, #endif --- a/net/ipv4/netfilter/nf_nat_proto_tcp.c +++ b/net/ipv4/netfilter/nf_nat_proto_tcp.c @@ -140,8 +140,7 @@ struct nf_nat_protocol nf_nat_protocol_t .manip_pkt = tcp_manip_pkt, .in_range = tcp_in_range, .unique_tuple = tcp_unique_tuple, -#if defined(CONFIG_IP_NF_CONNTRACK_NETLINK) || \ -defined(CONFIG_IP_NF_CONNTRACK_NETLINK_MODULE) +#if defined(CONFIG_NF_CT_NETLINK) || defined(CONFIG_NF_CT_NETLINK_MODULE) .range_to_nfattr= nf_nat_port_range_to_nfattr, .nfattr_to_range= nf_nat_port_nfattr_to_range, #endif --- a/net/ipv4/netfilter/nf_nat_proto_udp.c +++ b/net/ipv4/netfilter/nf_nat_proto_udp.c @@ -130,8 +130,7 @@ struct nf_nat_protocol nf_nat_protocol_u .manip_pkt = udp_manip_pkt, .in_range = udp_in_range, .unique_tuple = udp_unique_tuple, -#if defined(CONFIG_IP_NF_CONNTRACK_NETLINK) || \ -defined(CONFIG_IP_NF_CONNTRACK_NETLINK_MODULE) +#if defined(CONFIG_NF_CT_NETLINK) || defined(CONFIG_NF_CT_NETLINK_MODULE) .range_to_nfattr= nf_nat_port_range_to_nfattr, .nfattr_to_range= nf_nat_port_nfattr_to_range, #endif --- a/net/netfilter/nf_conntrack_proto_gre.c +++ b/net/netfilter/nf_conntrack_proto_gre.c @@ -281,8 +281,7 @@ static struct nf_conntrack_l4proto nf_co .new = gre_new, .destroy = gre_destroy, .me = THIS_MODULE, -#if defined(CONFIG_NF_CONNTRACK_NETLINK) || \ -defined(CONFIG_NF_CONNTRACK_NETLINK_MODULE) +#if defined(CONFIG_NF_CT_NETLINK) || defined(CONFIG_NF_CT_NETLINK_MODULE) .tuple_to_nfattr = nf_ct_port_tuple_to_nfattr, .nfattr_to_tuple = nf_ct_port_nfattr_to_tuple, #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 05/20] nfnetlink_log: fix use after free
-stable review patch. If anyone has any objections, please let us know. -- From: Patrick McHardy <[EMAIL PROTECTED]> [NETFILTER]: nfnetlink_log: fix use after free Paranoia: instance_put() might have freed the inst pointer when we spin_unlock_bh(). Signed-off-by: Michal Miroslaw <[EMAIL PROTECTED]> Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- net/netfilter/nfnetlink_log.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/net/netfilter/nfnetlink_log.c +++ b/net/netfilter/nfnetlink_log.c @@ -397,8 +397,8 @@ static void nfulnl_timer(unsigned long d if (timer_pending(>timer))/* is it always true or false here? */ del_timer(>timer); __nfulnl_send(inst); - instance_put(inst); spin_unlock_bh(>lock); + instance_put(inst); } /* This is an inline function, we don't really care about a 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/
[patch 03/20] tcp conntrack: accept SYN|URG as valid
-stable review patch. If anyone has any objections, please let us know.
--
From: Patrick McHardy <[EMAIL PROTECTED]>
[NETFILTER]: tcp conntrack: accept SYN|URG as valid
Some stacks apparently send packets with SYN|URG set. Linux accepts
these packets, so TCP conntrack should to.
Pointed out by Martijn Posthuma <[EMAIL PROTECTED]>.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
net/ipv4/netfilter/ip_conntrack_proto_tcp.c |4 +++-
net/netfilter/nf_conntrack_proto_tcp.c |4 +++-
2 files changed, 6 insertions(+), 2 deletions(-)
--- a/net/ipv4/netfilter/ip_conntrack_proto_tcp.c
+++ b/net/ipv4/netfilter/ip_conntrack_proto_tcp.c
@@ -821,8 +821,10 @@ void ip_conntrack_tcp_update(struct sk_b
static const u8 tcp_valid_flags[(TH_FIN|TH_SYN|TH_RST|TH_PUSH|TH_ACK|TH_URG) +
1] =
{
[TH_SYN]= 1,
- [TH_SYN|TH_ACK] = 1,
[TH_SYN|TH_PUSH]= 1,
+ [TH_SYN|TH_URG] = 1,
+ [TH_SYN|TH_PUSH|TH_URG] = 1,
+ [TH_SYN|TH_ACK] = 1,
[TH_SYN|TH_ACK|TH_PUSH] = 1,
[TH_RST]= 1,
[TH_RST|TH_ACK] = 1,
--- a/net/netfilter/nf_conntrack_proto_tcp.c
+++ b/net/netfilter/nf_conntrack_proto_tcp.c
@@ -778,8 +778,10 @@ EXPORT_SYMBOL_GPL(nf_conntrack_tcp_updat
static u8 tcp_valid_flags[(TH_FIN|TH_SYN|TH_RST|TH_PUSH|TH_ACK|TH_URG) + 1] =
{
[TH_SYN]= 1,
- [TH_SYN|TH_ACK] = 1,
[TH_SYN|TH_PUSH]= 1,
+ [TH_SYN|TH_URG] = 1,
+ [TH_SYN|TH_PUSH|TH_URG] = 1,
+ [TH_SYN|TH_ACK] = 1,
[TH_SYN|TH_ACK|TH_PUSH] = 1,
[TH_RST]= 1,
[TH_RST|TH_ACK] = 1,
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 01/20] conntrack: fix {nf, ip}_ct_iterate_cleanup endless loops
-stable review patch. If anyone has any objections, please let us know.
--
From: Patrick McHardy <[EMAIL PROTECTED]>
[NETFILTER]: conntrack: fix {nf,ip}_ct_iterate_cleanup endless loops
Fix {nf,ip}_ct_iterate_cleanup unconfirmed list handling:
- unconfirmed entries can not be killed manually, they are removed on
confirmation or final destruction of the conntrack entry, which means
we might iterate forever without making forward progress.
This can happen in combination with the conntrack event cache, which
holds a reference to the conntrack entry, which is only released when
the packet makes it all the way through the stack or a different
packet is handled.
- taking references to an unconfirmed entry and using it outside the
locked section doesn't work, the list entries are not refcounted and
another CPU might already be waiting to destroy the entry
What the code really wants to do is make sure the references of the hash
table to the selected conntrack entries are released, so they will be
destroyed once all references from skbs and the event cache are dropped.
Since unconfirmed entries haven't even entered the hash yet, simply mark
them as dying and skip confirmation based on that.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
include/linux/netfilter_ipv4/ip_conntrack_core.h |2 +-
include/net/netfilter/nf_conntrack_core.h|2 +-
net/ipv4/netfilter/ip_conntrack_core.c |2 +-
net/netfilter/nf_conntrack_core.c|2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
--- a/include/linux/netfilter_ipv4/ip_conntrack_core.h
+++ b/include/linux/netfilter_ipv4/ip_conntrack_core.h
@@ -45,7 +45,7 @@ static inline int ip_conntrack_confirm(s
int ret = NF_ACCEPT;
if (ct) {
- if (!is_confirmed(ct))
+ if (!is_confirmed(ct) && !is_dying(ct))
ret = __ip_conntrack_confirm(pskb);
ip_ct_deliver_cached_events(ct);
}
--- a/include/net/netfilter/nf_conntrack_core.h
+++ b/include/net/netfilter/nf_conntrack_core.h
@@ -64,7 +64,7 @@ static inline int nf_conntrack_confirm(s
int ret = NF_ACCEPT;
if (ct) {
- if (!nf_ct_is_confirmed(ct))
+ if (!nf_ct_is_confirmed(ct) && !nf_ct_is_dying(ct))
ret = __nf_conntrack_confirm(pskb);
nf_ct_deliver_cached_events(ct);
}
--- a/net/ipv4/netfilter/ip_conntrack_core.c
+++ b/net/ipv4/netfilter/ip_conntrack_core.c
@@ -1242,7 +1242,7 @@ get_next_corpse(int (*iter)(struct ip_co
list_for_each_entry(h, , list) {
ct = tuplehash_to_ctrack(h);
if (iter(ct, data))
- goto found;
+ set_bit(IPS_DYING_BIT, >status);
}
write_unlock_bh(_conntrack_lock);
return NULL;
--- a/net/netfilter/nf_conntrack_core.c
+++ b/net/netfilter/nf_conntrack_core.c
@@ -1052,7 +1052,7 @@ get_next_corpse(int (*iter)(struct nf_co
list_for_each_entry(h, , list) {
ct = nf_ct_tuplehash_to_ctrack(h);
if (iter(ct, data))
- goto found;
+ set_bit(IPS_DYING_BIT, >status);
}
write_unlock_bh(_conntrack_lock);
return NULL;
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 07/20] nfnetlink_log: fix possible NULL pointer dereference
-stable review patch. If anyone has any objections, please let us know.
--
From: Michal Miroslaw <[EMAIL PROTECTED]>
[NETFILTER]: nfnetlink_log: fix possible NULL pointer dereference
Eliminate possible NULL pointer dereference in nfulnl_recv_config().
Signed-off-by: Michal Miroslaw <[EMAIL PROTECTED]>
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
net/netfilter/nfnetlink_log.c |4
1 file changed, 4 insertions(+)
--- a/net/netfilter/nfnetlink_log.c
+++ b/net/netfilter/nfnetlink_log.c
@@ -867,6 +867,9 @@ nfulnl_recv_config(struct sock *ctnl, st
ret = -EINVAL;
break;
}
+
+ if (!inst)
+ goto out;
} else {
if (!inst) {
UDEBUG("no config command, and no instance for "
@@ -920,6 +923,7 @@ nfulnl_recv_config(struct sock *ctnl, st
out_put:
instance_put(inst);
+out:
return ret;
}
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 12/20] nfnetlink_log: fix reference counting
-stable review patch. If anyone has any objections, please let us know.
--
From: Michal Miroslaw <[EMAIL PROTECTED]>
[NETFILTER]: nfnetlink_log: fix reference counting
Fix reference counting (memory leak) problem in __nfulnl_send() and callers
related to packet queueing.
Signed-off-by: Michal Miroslaw <[EMAIL PROTECTED]>
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
net/netfilter/nfnetlink_log.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/net/netfilter/nfnetlink_log.c
+++ b/net/netfilter/nfnetlink_log.c
@@ -220,7 +220,8 @@ _instance_destroy2(struct nfulnl_instanc
/* timer "holds" one reference (we have one more) */
if (timer_pending(>timer)) {
del_timer(>timer);
- instance_put(inst);
+
+instance_put(inst);
}
if (inst->qlen)
__nfulnl_send(inst);
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 11/20] nfnetlink_log: fix crash on bridged packet
-stable review patch. If anyone has any objections, please let us know.
--
From: Patrick McHardy <[EMAIL PROTECTED]>
[NETFILTER]: nfnetlink_log: fix crash on bridged packet
physoutdev is only set on purely bridged packet, when nfnetlink_log is used
in the OUTPUT/FORWARD/POSTROUTING hooks on packets forwarded from or to a
bridge it crashes when trying to dereference skb->nf_bridge->physoutdev.
Reported by Holger Eitzenberger <[EMAIL PROTECTED]>
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
net/netfilter/nfnetlink_log.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/netfilter/nfnetlink_log.c
+++ b/net/netfilter/nfnetlink_log.c
@@ -491,7 +491,7 @@ __build_packet_message(struct nfulnl_ins
* for physical device (when called from ipv4) */
NFA_PUT(inst->skb, NFULA_IFINDEX_OUTDEV,
sizeof(tmp_uint), _uint);
- if (skb->nf_bridge) {
+ if (skb->nf_bridge && skb->nf_bridge->physoutdev) {
tmp_uint =
htonl(skb->nf_bridge->physoutdev->ifindex);
NFA_PUT(inst->skb, NFULA_IFINDEX_PHYSOUTDEV,
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 16/20] fix for bugzilla #7544 (keyspan USB-to-serial converter)
-stable review patch. If anyone has any objections, please let us know.
--
From: Rainer Weikusat <[EMAIL PROTECTED]>
At least the Keyspan USA-19HS USB-to-serial converter supports
two different configurations, one where the input endpoints
have interrupt transfer type and one where they are bulk endpoints.
The default UHCI configuration uses the interrupt input endpoints.
The keyspan driver, OTOH, assumes that the device has only bulk
endpoints (all URBs are initialized by calling usb_fill_bulk_urb
in keyspan.c/ keyspan_setup_urb). This causes the interval field
of the input URBs to have a value of zero instead of one, which
'accidentally' worked with Linux at least up to 2.6.17.11 but
stopped to with 2.6.18, which changed the UHCI support code handling
URBs for interrupt endpoints. The patch below modifies to driver to
initialize its input URBs either as interrupt or as bulk URBs,
depending on the transfertype contained in the associated endpoint
descriptor (only tested with the default configuration) enabling
the driver to again receive data from the serial converter.
Greg K-H reworked the patch.
Signed-off-by: Rainer Weikusat <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/usb/serial/keyspan.c | 49 +++
1 file changed, 45 insertions(+), 4 deletions(-)
--- a/drivers/usb/serial/keyspan.c
+++ b/drivers/usb/serial/keyspan.c
@@ -1275,11 +1275,31 @@ static int keyspan_fake_startup (struct
}
/* Helper functions used by keyspan_setup_urbs */
+static struct usb_endpoint_descriptor const *find_ep(struct usb_serial const
*serial,
+int endpoint)
+{
+ struct usb_host_interface *iface_desc;
+ struct usb_endpoint_descriptor *ep;
+ int i;
+
+ iface_desc = serial->interface->cur_altsetting;
+ for (i = 0; i < iface_desc->desc.bNumEndpoints; ++i) {
+ ep = _desc->endpoint[i].desc;
+ if (ep->bEndpointAddress == endpoint)
+ return ep;
+ }
+ dev_warn(>interface->dev, "found no endpoint descriptor for "
+"endpoint %x\n", endpoint);
+ return NULL;
+}
+
static struct urb *keyspan_setup_urb (struct usb_serial *serial, int endpoint,
int dir, void *ctx, char *buf, int len,
void (*callback)(struct urb *))
{
struct urb *urb;
+ struct usb_endpoint_descriptor const *ep_desc;
+ char const *ep_type_name;
if (endpoint == -1)
return NULL;/* endpoint not needed */
@@ -1291,11 +1311,32 @@ static struct urb *keyspan_setup_urb (st
return NULL;
}
- /* Fill URB using supplied data. */
- usb_fill_bulk_urb(urb, serial->dev,
- usb_sndbulkpipe(serial->dev, endpoint) | dir,
- buf, len, callback, ctx);
+ ep_desc = find_ep(serial, endpoint);
+ if (!ep_desc) {
+ /* leak the urb, something's wrong and the callers don't care */
+ return urb;
+ }
+ if (usb_endpoint_xfer_int(ep_desc)) {
+ ep_type_name = "INT";
+ usb_fill_int_urb(urb, serial->dev,
+usb_sndintpipe(serial->dev, endpoint) | dir,
+buf, len, callback, ctx,
+ep_desc->bInterval);
+ } else if (usb_endpoint_xfer_bulk(ep_desc)) {
+ ep_type_name = "BULK";
+ usb_fill_bulk_urb(urb, serial->dev,
+ usb_sndbulkpipe(serial->dev, endpoint) | dir,
+ buf, len, callback, ctx);
+ } else {
+ dev_warn(>interface->dev,
+"unsupported endpoint type %x\n",
+ep_desc->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK);
+ usb_free_urb(urb);
+ return NULL;
+ }
+ dbg("%s - using urb %p for %s endpoint %x",
+ __func__, urb, ep_type_name, endpoint);
return urb;
}
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 13/20] Fix bug 7994 sleeping function called from invalid context
-stable review patch. If anyone has any objections, please let us know.
--
From: Douglas Gilbert <[EMAIL PROTECTED]>
- addresses the reported bug (with GFP_KERNEL -> GFP_ATOMIC)
- improves error checking, and
- is a subset of the changes to scsi_debug in lk 2.6.21-rc*
Compiled and lightly tested (in lk 2.6.21-rc2 environment).
Signed-off-by: Douglas Gilbert <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/scsi/scsi_debug.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
--- a/drivers/scsi/scsi_debug.c
+++ b/drivers/scsi/scsi_debug.c
@@ -954,7 +954,9 @@ static int resp_inquiry(struct scsi_cmnd
int alloc_len, n, ret;
alloc_len = (cmd[3] << 8) + cmd[4];
- arr = kzalloc(SDEBUG_MAX_INQ_ARR_SZ, GFP_KERNEL);
+ arr = kzalloc(SDEBUG_MAX_INQ_ARR_SZ, GFP_ATOMIC);
+ if (! arr)
+ return DID_REQUEUE << 16;
if (devip->wlun)
pq_pdt = 0x1e; /* present, wlun */
else if (scsi_debug_no_lun_0 && (0 == devip->lun))
@@ -1217,7 +1219,9 @@ static int resp_report_tgtpgs(struct scs
alen = ((cmd[6] << 24) + (cmd[7] << 16) + (cmd[8] << 8)
+ cmd[9]);
- arr = kzalloc(SDEBUG_MAX_TGTPGS_ARR_SZ, GFP_KERNEL);
+ arr = kzalloc(SDEBUG_MAX_TGTPGS_ARR_SZ, GFP_ATOMIC);
+ if (! arr)
+ return DID_REQUEUE << 16;
/*
* EVPD page 0x88 states we have two ports, one
* real and a fake port with no device connected.
@@ -1996,6 +2000,8 @@ static int scsi_debug_slave_configure(st
if (sdp->host->max_cmd_len != SCSI_DEBUG_MAX_CMD_LEN)
sdp->host->max_cmd_len = SCSI_DEBUG_MAX_CMD_LEN;
devip = devInfoReg(sdp);
+ if (NULL == devip)
+ return 1; /* no resources, will be marked offline */
sdp->hostdata = devip;
if (sdp->host->cmd_per_lun)
scsi_adjust_queue_depth(sdp, SDEBUG_TAGGED_QUEUING,
@@ -2044,7 +2050,7 @@ static struct sdebug_dev_info * devInfoR
}
}
if (NULL == open_devip) { /* try and make a new one */
- open_devip = kzalloc(sizeof(*open_devip),GFP_KERNEL);
+ open_devip = kzalloc(sizeof(*open_devip),GFP_ATOMIC);
if (NULL == open_devip) {
printk(KERN_ERR "%s: out of memory at line %d\n",
__FUNCTION__, __LINE__);
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 14/20] bcm43xx: Fix problem with >1 GB RAM
-stable review patch. If anyone has any objections, please let us know.
--
From: Larry Finger <[EMAIL PROTECTED]>
[PATCH] bcm43xx: Fix problem with >1 GB RAM
Some versions of the bcm43xx chips only support 30-bit DMA, which means
that the descriptors and buffers must be in the first 1 GB of RAM. On
the i386 and x86_64 architectures with more than 1 GB RAM, an incorrect
assignment may occur. This patch ensures that the various DMA addresses
are within the capability of the chip. Testing has been limited to x86_64
as no one has an i386 system with more than 1 GB RAM.
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
Signed-off-by: John W. Linville <[EMAIL PROTECTED]>
Cc: Chuck Ebbert <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/net/wireless/bcm43xx/bcm43xx.h |1
drivers/net/wireless/bcm43xx/bcm43xx_dma.c | 171 +
2 files changed, 125 insertions(+), 47 deletions(-)
--- a/drivers/net/wireless/bcm43xx/bcm43xx.h
+++ b/drivers/net/wireless/bcm43xx/bcm43xx.h
@@ -766,6 +766,7 @@ struct bcm43xx_private {
* This is currently always BCM43xx_BUSTYPE_PCI
*/
u8 bustype;
+ u64 dma_mask;
u16 board_vendor;
u16 board_type;
--- a/drivers/net/wireless/bcm43xx/bcm43xx_dma.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_dma.c
@@ -145,16 +145,14 @@ dma_addr_t map_descbuffer(struct bcm43xx
int tx)
{
dma_addr_t dmaaddr;
+ int direction = PCI_DMA_FROMDEVICE;
- if (tx) {
- dmaaddr = dma_map_single(>bcm->pci_dev->dev,
-buf, len,
-DMA_TO_DEVICE);
- } else {
- dmaaddr = dma_map_single(>bcm->pci_dev->dev,
+ if (tx)
+ direction = PCI_DMA_TODEVICE;
+
+ dmaaddr = pci_map_single(ring->bcm->pci_dev,
buf, len,
-DMA_FROM_DEVICE);
- }
+direction);
return dmaaddr;
}
@@ -166,13 +164,13 @@ void unmap_descbuffer(struct bcm43xx_dma
int tx)
{
if (tx) {
- dma_unmap_single(>bcm->pci_dev->dev,
+ pci_unmap_single(ring->bcm->pci_dev,
addr, len,
-DMA_TO_DEVICE);
+PCI_DMA_TODEVICE);
} else {
- dma_unmap_single(>bcm->pci_dev->dev,
+ pci_unmap_single(ring->bcm->pci_dev,
addr, len,
-DMA_FROM_DEVICE);
+PCI_DMA_FROMDEVICE);
}
}
@@ -183,8 +181,8 @@ void sync_descbuffer_for_cpu(struct bcm4
{
assert(!ring->tx);
- dma_sync_single_for_cpu(>bcm->pci_dev->dev,
- addr, len, DMA_FROM_DEVICE);
+ pci_dma_sync_single_for_cpu(ring->bcm->pci_dev,
+ addr, len, PCI_DMA_FROMDEVICE);
}
static inline
@@ -194,8 +192,8 @@ void sync_descbuffer_for_device(struct b
{
assert(!ring->tx);
- dma_sync_single_for_device(>bcm->pci_dev->dev,
- addr, len, DMA_FROM_DEVICE);
+ pci_dma_sync_single_for_cpu(ring->bcm->pci_dev,
+ addr, len, PCI_DMA_TODEVICE);
}
/* Unmap and free a descriptor buffer. */
@@ -214,17 +212,53 @@ void free_descriptor_buffer(struct bcm43
static int alloc_ringmemory(struct bcm43xx_dmaring *ring)
{
- struct device *dev = &(ring->bcm->pci_dev->dev);
-
- ring->descbase = dma_alloc_coherent(dev, BCM43xx_DMA_RINGMEMSIZE,
- &(ring->dmabase), GFP_KERNEL);
+ ring->descbase = pci_alloc_consistent(ring->bcm->pci_dev,
BCM43xx_DMA_RINGMEMSIZE,
+ &(ring->dmabase));
if (!ring->descbase) {
- printk(KERN_ERR PFX "DMA ringmemory allocation failed\n");
- return -ENOMEM;
+ /* Allocation may have failed due to pci_alloc_consistent
+ insisting on use of GFP_DMA, which is more restrictive
+ than necessary... */
+ struct dma_desc *rx_ring;
+ dma_addr_t rx_ring_dma;
+
+ rx_ring = kzalloc(BCM43xx_DMA_RINGMEMSIZE, GFP_KERNEL);
+ if (!rx_ring)
+ goto out_err;
+
+ rx_ring_dma = pci_map_single(ring->bcm->pci_dev, rx_ring,
+BCM43xx_DMA_RINGMEMSIZE,
+PCI_DMA_BIDIRECTIONAL);
+
+ if (pci_dma_mapping_error(rx_ring_dma) ||
+ rx_ring_dma + BCM43xx_DMA_RINGMEMSIZE >
ring->bcm->dma_mask) {
+ /* Sigh... */
+ if
[patch 15/20] Fix compat_getsockopt
-stable review patch. If anyone has any objections, please let us know.
--
From: Johannes Berg <[EMAIL PROTECTED]>
[NET]: Fix compat_sock_common_getsockopt typo.
This patch fixes a typo in compat_sock_common_getsockopt.
Signed-off-by: Johannes Berg <[EMAIL PROTECTED]>
Acked-by: James Morris <[EMAIL PROTECTED]>
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
net/core/sock.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -1597,7 +1597,7 @@ int compat_sock_common_getsockopt(struct
{
struct sock *sk = sock->sk;
- if (sk->sk_prot->compat_setsockopt != NULL)
+ if (sk->sk_prot->compat_getsockopt != NULL)
return sk->sk_prot->compat_getsockopt(sk, level, optname,
optval, optlen);
return sk->sk_prot->getsockopt(sk, level, optname, optval, optlen);
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 17/20] Fix callback bug in connector
-stable review patch. If anyone has any objections, please let us know.
--
From: Philipp Reisner <[EMAIL PROTECTED]>
[CONNECTOR]: Bugfix for cn_call_callback()
When system under heavy stress and must allocate new work
instead of reusing old one, new work must use correct
completion callback.
Patch is based on Philipp's and Lars' work.
I only cleaned small stuff (and removed spaces instead of tabs).
Signed-off-by: Philipp Reisner <[EMAIL PROTECTED]>
Signed-off-by: Lars Ellenberg <[EMAIL PROTECTED]>
Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/connector/connector.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
--- a/drivers/connector/connector.c
+++ b/drivers/connector/connector.c
@@ -128,7 +128,7 @@ EXPORT_SYMBOL_GPL(cn_netlink_send);
*/
static int cn_call_callback(struct cn_msg *msg, void (*destruct_data)(void *),
void *data)
{
- struct cn_callback_entry *__cbq;
+ struct cn_callback_entry *__cbq, *__new_cbq;
struct cn_dev *dev =
int err = -ENODEV;
@@ -148,27 +148,27 @@ static int cn_call_callback(struct cn_ms
} else {
struct cn_callback_data *d;
- __cbq = kzalloc(sizeof(*__cbq), GFP_ATOMIC);
- if (__cbq) {
- d = &__cbq->data;
+ err = -ENOMEM;
+ __new_cbq = kzalloc(sizeof(struct
cn_callback_entry), GFP_ATOMIC);
+ if (__new_cbq) {
+ d = &__new_cbq->data;
d->callback_priv = msg;
d->callback = __cbq->data.callback;
d->ddata = data;
d->destruct_data = destruct_data;
- d->free = __cbq;
+ d->free = __new_cbq;
- INIT_WORK(&__cbq->work,
+ INIT_WORK(&__new_cbq->work,
_queue_wrapper);
-
+
if (queue_work(dev->cbdev->cn_queue,
- &__cbq->work))
+ &__new_cbq->work))
err = 0;
else {
- kfree(__cbq);
+ kfree(__new_cbq);
err = -EINVAL;
}
- } else
- err = -ENOMEM;
+ }
}
break;
}
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 18/20] Fix sparc64 device register probing
-stable review patch. If anyone has any objections, please let us know.
--
From: David Miller <[EMAIL PROTECTED]>
[SPARC]: Fix bus handling in build_device_resources().
We mistakedly modify 'bus' in the innermost loop. What
should happen is that at each register index iteration,
we start with the same 'bus'.
So preserve it's value at the top level, and use a loop
local variable 'dbus' for iteration.
This bug causes registers other than the first to be
decoded improperly.
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
arch/sparc/kernel/of_device.c |7 ---
arch/sparc64/kernel/of_device.c |7 ---
2 files changed, 8 insertions(+), 6 deletions(-)
--- a/arch/sparc/kernel/of_device.c
+++ b/arch/sparc/kernel/of_device.c
@@ -495,7 +495,7 @@ static void __init build_device_resource
u32 *reg = (preg + (index * ((na + ns) * 4)));
struct device_node *dp = op->node;
struct device_node *pp = p_op->node;
- struct of_bus *pbus;
+ struct of_bus *pbus, *dbus;
u64 size, result = OF_BAD_ADDR;
unsigned long flags;
int dna, dns;
@@ -516,6 +516,7 @@ static void __init build_device_resource
dna = na;
dns = ns;
+ dbus = bus;
while (1) {
dp = pp;
@@ -528,13 +529,13 @@ static void __init build_device_resource
pbus = of_match_bus(pp);
pbus->count_cells(dp, , );
- if (build_one_resource(dp, bus, pbus, addr,
+ if (build_one_resource(dp, dbus, pbus, addr,
dna, dns, pna))
break;
dna = pna;
dns = pns;
- bus = pbus;
+ dbus = pbus;
}
build_res:
--- a/arch/sparc64/kernel/of_device.c
+++ b/arch/sparc64/kernel/of_device.c
@@ -581,7 +581,7 @@ static void __init build_device_resource
u32 *reg = (preg + (index * ((na + ns) * 4)));
struct device_node *dp = op->node;
struct device_node *pp = p_op->node;
- struct of_bus *pbus;
+ struct of_bus *pbus, *dbus;
u64 size, result = OF_BAD_ADDR;
unsigned long flags;
int dna, dns;
@@ -599,6 +599,7 @@ static void __init build_device_resource
dna = na;
dns = ns;
+ dbus = bus;
while (1) {
dp = pp;
@@ -611,13 +612,13 @@ static void __init build_device_resource
pbus = of_match_bus(pp);
pbus->count_cells(dp, , );
- if (build_one_resource(dp, bus, pbus, addr,
+ if (build_one_resource(dp, dbus, pbus, addr,
dna, dns, pna))
break;
dna = pna;
dns = pns;
- bus = pbus;
+ dbus = pbus;
}
build_res:
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 19/20] Fix timewait jiffies
-stable review patch. If anyone has any objections, please let us know.
--
From: Eric Dumazet <[EMAIL PROTECTED]>
[INET]: twcal_jiffie should be unsigned long, not int
Signed-off-by: Eric Dumazet <[EMAIL PROTECTED]>
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
include/net/inet_timewait_sock.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/include/net/inet_timewait_sock.h
+++ b/include/net/inet_timewait_sock.h
@@ -66,7 +66,7 @@ struct inet_hashinfo;
struct inet_timewait_death_row {
/* Short-time timewait calendar */
int twcal_hand;
- int twcal_jiffie;
+ unsigned long twcal_jiffie;
struct timer_list twcal_timer;
struct hlist_head twcal_row[INET_TWDR_RECYCLE_SLOTS];
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 20/20] Fix UDP header pointer after pskb_trim_rcsum()
-stable review patch. If anyone has any objections, please let us know. -- From: Herbert Xu <[EMAIL PROTECTED]> [UDP]: Reread uh pointer after pskb_trim The header may have moved when trimming. Signed-off-by: Herbert Xu <[EMAIL PROTECTED]> Signed-off-by: David S. Miller <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- net/ipv4/udp.c |1 + 1 file changed, 1 insertion(+) --- a/net/ipv4/udp.c +++ b/net/ipv4/udp.c @@ -1214,6 +1214,7 @@ int __udp4_lib_rcv(struct sk_buff *skb, if (ulen < sizeof(*uh) || pskb_trim_rcsum(skb, ulen)) goto short_packet; + uh = skb->h.uh; udp4_csum_init(skb, uh); -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 04/20] nfnetlink_log: fix reference leak
-stable review patch. If anyone has any objections, please let us know.
--
From: Patrick McHardy <[EMAIL PROTECTED]>
[NETFILTER]: nfnetlink_log: fix reference leak
Stop reference leaking in nfulnl_log_packet(). If we start a timer we
are already taking another reference.
Signed-off-by: Michal Miroslaw <[EMAIL PROTECTED]>
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
net/netfilter/nfnetlink_log.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
--- a/net/netfilter/nfnetlink_log.c
+++ b/net/netfilter/nfnetlink_log.c
@@ -720,15 +720,16 @@ nfulnl_log_packet(unsigned int pf,
inst->timer.expires = jiffies + (inst->flushtimeout*HZ/100);
add_timer(>timer);
}
- spin_unlock_bh(>lock);
+unlock_and_release:
+ spin_unlock_bh(>lock);
+ instance_put(inst);
return;
alloc_failure:
- spin_unlock_bh(>lock);
- instance_put(inst);
UDEBUG("error allocating skb\n");
/* FIXME: statistics */
+ goto unlock_and_release;
}
static int
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 08/20] ip6_route_me_harder should take into account mark
-stable review patch. If anyone has any objections, please let us know.
--
From: Yasuyuki Kozakai <[EMAIL PROTECTED]>
[NETFILTER]: ip6_route_me_harder should take into account mark
Signed-off-by: Yasuyuki Kozakai <[EMAIL PROTECTED]>
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
net/ipv6/netfilter.c |1 +
1 file changed, 1 insertion(+)
--- a/net/ipv6/netfilter.c
+++ b/net/ipv6/netfilter.c
@@ -15,6 +15,7 @@ int ip6_route_me_harder(struct sk_buff *
struct dst_entry *dst;
struct flowi fl = {
.oif = skb->sk ? skb->sk->sk_bound_dev_if : 0,
+ .mark = skb->mark,
.nl_u =
{ .ip6_u =
{ .daddr = iph->daddr,
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Odd suspend regression in 2.6.21-rc[123]
Ray Lee wrote:
> In 2.6.21-rc1,2,3, my laptop will fully suspend to ram, but then
> *immediately* resumes back from suspension. (It resumes just fine, as well.)
[...]
> HP/Compaq NX6125 system, AMD64, dmesg attached.
hg bisect found the below patch as the culprit, and reverting it does
fix the regression. It's supposed to address "sometime ac/battery update
stops after resume from disk." This thread:
http://lkml.org/lkml/2007/2/24/111 appears to talk about the same issue,
and therefore it may be solved without the below patch, so perhaps we
can all be happy.
Regardless, I think my laptop no longer being able to go into S3 sleep
is a bit more important than someone else's laptop merely not showing
the correct AC status :-).
Please revert. (git patch id ed41dab90eb40ac4911e60406bc653661f0e4ce1)
Ray
ACPI: Disable GPEs in preparation for sleep.
http://bugzilla.kernel.org/show_bug.cgi?id=7887
Signed-off-by: Alexey Starikovskiy <[EMAIL PROTECTED]>
Signed-off-by: Vladimir Lebedev <[EMAIL PROTECTED]>
Signed-off-by: Len Brown <[EMAIL PROTECTED]>
committer: Len Brown <[EMAIL PROTECTED]>
diff -r 31db4f8c1b77 -r 2a00d393c882 drivers/acpi/hardware/hwsleep.c
--- a/drivers/acpi/hardware/hwsleep.c Fri Feb 09 10:45:33 2007 -0800
+++ b/drivers/acpi/hardware/hwsleep.c Sat Feb 10 01:30:35 2007 -0500
@@ -235,6 +235,14 @@ acpi_status acpi_enter_sleep_state_prep(
"While executing method _SST"));
}
+ /*
+* 1) Disable/Clear all GPEs
+*/
+ status = acpi_hw_disable_all_gpes();
+ if (ACPI_FAILURE(status)) {
+ return_ACPI_STATUS(status);
+ }
+
return_ACPI_STATUS(AE_OK);
}
@@ -290,13 +298,8 @@ acpi_status asmlinkage acpi_enter_sleep_
}
/*
-* 1) Disable/Clear all GPEs
* 2) Enable all wakeup GPEs
*/
- status = acpi_hw_disable_all_gpes();
- if (ACPI_FAILURE(status)) {
- return_ACPI_STATUS(status);
- }
acpi_gbl_system_awake_and_running = FALSE;
status = acpi_hw_enable_all_wakeup_gpes();
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 09/20] nf_conntrack: fix incorrect classification of IPv6 fragments as ESTABLISHED
-stable review patch. If anyone has any objections, please let us know. -- From: Patrick McHardy <[EMAIL PROTECTED]> [NETFILTER]: nf_conntrack: fix incorrect classification of IPv6 fragments as ESTABLISHED The individual fragments of a packet reassembled by conntrack have the conntrack reference from the reassembled packet attached, but nfctinfo is not copied. This leaves it initialized to 0, which unfortunately is the value of IP_CT_ESTABLISHED. The result is that all IPv6 fragments are tracked as ESTABLISHED, allowing them to bypass a usual ruleset which accepts ESTABLISHED packets early. Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c |1 + 1 file changed, 1 insertion(+) --- a/net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c +++ b/net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c @@ -257,6 +257,7 @@ static unsigned int ipv6_conntrack_in(un } nf_conntrack_get(reasm->nfct); (*pskb)->nfct = reasm->nfct; + (*pskb)->nfctinfo = reasm->nfctinfo; return NF_ACCEPT; } -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 10/20] nfnetlink_log: zero-terminate prefix
-stable review patch. If anyone has any objections, please let us know. -- From: Patrick McHardy <[EMAIL PROTECTED]> [NETFILTER]: nfnetlink_log: zero-terminate prefix Userspace expects a zero-terminated string, so include the trailing zero in the netlink message. Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- net/netfilter/nfnetlink_log.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/net/netfilter/nfnetlink_log.c +++ b/net/netfilter/nfnetlink_log.c @@ -620,7 +620,7 @@ nfulnl_log_packet(unsigned int pf, plen = 0; if (prefix) - plen = strlen(prefix); + plen = strlen(prefix) + 1; /* all macros expand to constant values at compile time */ /* FIXME: do we want to make the size calculation conditional based on -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 06/20] nfnetlink_log: fix NULL pointer dereference
-stable review patch. If anyone has any objections, please let us know. -- From: Micha Mirosaw <[EMAIL PROTECTED]> [NETFILTER]: nfnetlink_log: fix NULL pointer dereference Fix the nasty NULL dereference on multiple packets per netlink message. BUG: unable to handle kernel NULL pointer dereference at virtual address 0004 printing eip: f8a4b3bf *pde = Oops: 0002 [#1] SMP Modules linked in: nfnetlink_log ipt_ttl ipt_REDIRECT xt_tcpudp iptable_nat nf_nat nf_conntrack _ipv4 xt_state ipt_ipp2p xt_NFLOG xt_hashlimit ip6_tables iptable_filter xt_multiport xt_mark i pt_set iptable_raw xt_MARK iptable_mangle ip_tables cls_fw cls_u32 sch_esfq sch_htb ip_set_ipma p ip_set ipt_ULOG x_tables dm_snapshot dm_mirror loop e1000 parport_pc parport e100 floppy ide_ cd cdrom CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00010206 (2.6.20 #5) EIP is at __nfulnl_send+0x24/0x51 [nfnetlink_log] eax: ebx: f2b5cbc0 ecx: c03f5f54 edx: c03f4000 esi: f2b5cbc8 edi: c03f5f54 ebp: f8a4b3ec esp: c03f5f30 ds: 007b es: 007b ss: 0068 Process swapper (pid: 0, ti=c03f4000 task=c03bece0 task.ti=c03f4000) Stack: f2b5cbc0 f8a4b401 0100 c0444080 c012af49 f6f19100 f6f19000 c1707800 c03f5f54 c03f5f54 0123 0021 c03e8d08 c0426380 0009 c0126932 0046 c03e9980 c03e6000 0047b007 c01269bd Call Trace: [] nfulnl_timer+0x15/0x25 [nfnetlink_log] [] run_timer_softirq+0x10a/0x164 [] __do_softirq+0x60/0xba [] do_softirq+0x31/0x35 [] do_IRQ+0x62/0x74 [] common_interrupt+0x23/0x28 [] default_idle+0x0/0x3f [] default_idle+0x2d/0x3f [] cpu_idle+0xa0/0xb9 [] start_kernel+0x1a8/0x1ac [] unknown_bootoption+0x0/0x181 === Code: 5e 5f 5b 5e 5f 5d c3 53 89 c3 8d 40 1c 83 7b 1c 00 74 05 e8 2c ee 6d c7 83 7b 14 00 75 04 31 c0 eb 34 83 7b 10 01 76 09 8b 43 18 <66> c7 40 04 03 00 8b 53 34 8b 43 14 b9 40 00 00 00 e8 08 9a 84 EIP: [] __nfulnl_send+0x24/0x51 [nfnetlink_log] SS:ESP 0068:c03f5f30 <0>Kernel panic - not syncing: Fatal exception in interrupt <0>Rebooting in 5 seconds.. Panic no more! Signed-off-by: Micha Mirosaw <[EMAIL PROTECTED]> Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- net/netfilter/nfnetlink_log.c |1 + 1 file changed, 1 insertion(+) --- a/net/netfilter/nfnetlink_log.c +++ b/net/netfilter/nfnetlink_log.c @@ -564,6 +564,7 @@ __build_packet_message(struct nfulnl_ins } nlh->nlmsg_len = inst->skb->tail - old_tail; + inst->lastnlh = nlh; return 0; nlmsg_failure: -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 00/20] 2.6.20-stable review
On Fri, Mar 09, 2007 at 10:16:03PM -0800, Greg KH wrote: > This is the start of the stable review cycle for the 2.6.20.3 release. Oh, the rolled up patch is at: kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.20.3-rc1.gz thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2/9] signalfd/timerfd v1 - signalfd core ...
On Fri, 9 Mar 2007, Davide Libenzi wrote: > This patch series implements the new signalfd() and signalfd_dequeue() -- Of course, wrong description. The signalfd_dequeue() call is gone, and signals are dequeued by read(2). - Davide - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 6/9] signalfd/timerfd v1 - timerfd core ...
On Fri, 2007-03-09 at 15:41 -0800, Davide Libenzi wrote: > This patch introduces a new system call for timers events delivered > though file descriptors. This allows timer event to be used with > standard POSIX poll(2), select(2) and read(2). As a consequence of > supporting the Linux f_op->poll subsystem, they can be used with > epoll(2) too. > The system call is defined as: > > int timerfd(int ufd, int tmrtype, const struct timespec *utmr); > > The "ufd" parameter allows for re-use (re-programming) of an existing > timerfd w/out going through the close/open cycle (same as signalfd). > If "ufd" is -1, s new file descriptor will be created, otherwise the > existing "ufd" will be re-programmed. > The "tmrtype" parameter allows to specify the timer type. The following > values are supported: > > TFD_TIMER_REL > The time specified in the "utmr" parameter is a relative time > from NOW. > > TFD_TIMER_ABS > The timer specified in the "utmr" parameter is an absolute time. > > TFD_TIMER_SEQ > The time specified in the "utmr" parameter is an interval at > which a continuous clock rate will be generated. > > The function returns the new (or same, in case "ufd" is a valid timerfd > descriptor) file, or -1 in case of error. > As stated before, the timerfd file descriptor supports poll(2), select(2) > and epoll(2). When a timer event happened on the timerfd, a POLLIN mask > will be returned. > The read(2) call can be used, and it will return a u32 variable holding > the number of "ticks" that happened on the interface since the last call > to read(2). The read(2) call supportes the O_NONBLOCK flag too, and EAGAIN > will be returned if no ticks happened. > A quick test program, shows timerfd working correctly on my amd64 box: > > http://www.xmailserver.org/timerfd-test.c > Why did you ignore the existing POSIX timer API? -- Nicholas Miell <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Use attribute groups in struct device_type
Greg,
Please consider applying the patch below. It switches struct device_type
to using attribute groups which os more flexible. I am using it in my
input class_device -> device conversion (which is 99% done btw).
I looked through -mm and the latest git and there does not seem to be
any users of struct device_type yet...
--
Dmitry
Driver core: use attribute groups in struct device_type
Attribute groups are more flexible than attribute lists
(an attribute list can be represented by anonymous group)
so switch struct device_type to use them.
Also rework attribute creation for devices so that they all
cleaned up properly in case of errors.
Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
---
drivers/base/core.c| 115 +
include/linux/device.h |2
2 files changed, 70 insertions(+), 47 deletions(-)
Index: work/drivers/base/core.c
===
--- work.orig/drivers/base/core.c
+++ work/drivers/base/core.c
@@ -259,64 +259,95 @@ static ssize_t store_uevent(struct devic
return count;
}
-static int device_add_groups(struct device *dev)
+static int device_add_attributes(struct device *dev,
+struct device_attribute *attrs)
+{
+ int error = 0;
+ int i;
+
+ if (attrs) {
+ for (i = 0; attr_name(attrs[i]); i++) {
+ error = device_create_file(dev, [i]);
+ if (error)
+ break;
+ }
+ if (error)
+ while (--i >= 0)
+ device_remove_file(dev, [i]);
+ }
+ return error;
+}
+
+static void device_remove_attributes(struct device *dev,
+struct device_attribute *attrs)
{
int i;
+
+ if (attrs)
+ for (i = 0; attr_name(attrs[i]); i++)
+ device_remove_file(dev, [i]);
+}
+
+static int device_add_groups(struct device *dev,
+struct attribute_group **groups)
+{
int error = 0;
+ int i;
- if (dev->groups) {
- for (i = 0; dev->groups[i]; i++) {
- error = sysfs_create_group(>kobj, dev->groups[i]);
+ if (groups) {
+ for (i = 0; groups[i]; i++) {
+ error = sysfs_create_group(>kobj, groups[i]);
if (error) {
while (--i >= 0)
- sysfs_remove_group(>kobj,
dev->groups[i]);
- goto out;
+ sysfs_remove_group(>kobj,
groups[i]);
+ break;
}
}
}
-out:
return error;
}
-static void device_remove_groups(struct device *dev)
+static void device_remove_groups(struct device *dev,
+struct attribute_group **groups)
{
int i;
- if (dev->groups) {
- for (i = 0; dev->groups[i]; i++) {
- sysfs_remove_group(>kobj, dev->groups[i]);
- }
- }
+
+ if (groups)
+ for (i = 0; groups[i]; i++)
+ sysfs_remove_group(>kobj, groups[i]);
}
static int device_add_attrs(struct device *dev)
{
struct class *class = dev->class;
struct device_type *type = dev->type;
- int error = 0;
- int i;
+ int error;
- if (class && class->dev_attrs) {
- for (i = 0; attr_name(class->dev_attrs[i]); i++) {
- error = device_create_file(dev, >dev_attrs[i]);
- if (error)
- break;
- }
+ if (class) {
+ error = device_add_attributes(dev, class->dev_attrs);
if (error)
- while (--i >= 0)
- device_remove_file(dev, >dev_attrs[i]);
+ return error;
}
- if (type && type->attrs) {
- for (i = 0; attr_name(type->attrs[i]); i++) {
- error = device_create_file(dev, >attrs[i]);
- if (error)
- break;
- }
+ if (type) {
+ error = device_add_groups(dev, type->groups);
if (error)
- while (--i >= 0)
- device_remove_file(dev, >attrs[i]);
+ goto err_remove_class_attrs;
}
+ error = device_add_groups(dev, dev->groups);
+ if (error)
+ goto err_remove_type_groups;
+
+ return 0;
+
+ err_remove_type_groups:
+ if (type)
+ device_remove_groups(dev, type->groups);
+ err_remove_class_attrs:
+ if (class)
+
Re: [patch 6/9] signalfd/timerfd v1 - timerfd core ...
On Fri, 9 Mar 2007, Nicholas Miell wrote: > Why did you ignore the existing POSIX timer API? The existing POSIX API is a standard and a very good one. Too bad it does not deliver to files. The timerfd code is, as you can probably read from the code, a really thin wrapper around the existing hrtimer.c Linux code. - Davide - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sys_write() racy for multi-threaded append?
I apologize for throwing around words like "stupid". Whether or not the current semantics can be improved, that's not a constructive way to characterize them. I'm sorry. As three people have ably pointed out :-), the particular case of a pipe/FIFO isn't seekable and doesn't need the f_pos member anyway (it's effectively always O_APPEND). That's what I get for checking against standards documents at 3AM. Of course, this has nothing to do with the point that led me to comment on pipes/FIFOs (which was that there exist file types that never return 0 The behavior of lseek() on devices which are incapable of seeking is implementation-defined. The value of the file offset associated with such a device is undefined. Tracking f_pos accurately when writes from multiple threads hit the same fd (pipe or not) isn't portable, but I recall situations where it would have been useful. And if f_pos has to be kept at all in the uncontended case, it costs you little or nothing to do it in a thread-safe manner -- as long as you don't overconstrain the semantics such that you forbid the transient overshoot associated with a short write. In fact, unless there's something I've missed, increasing f_pos before entering vfs_write() happens to be _faster_ than the current code for common load patterns, both single- and multi-threaded (although getting the full benefit in the multi-threaded case will take some fiddling with f_count placement). I say it costs "little or nothing" only because altering an loff_t atomically is not free. But even on x86, with its inability to atomically modify any 64-bit entity in memory, an uncontended spinlock on a cacheline already in L1 is so cheap that making the f_pos changes atomic will (I think) be lost in the noise. In any case, rewriting read_write.c is proving interesting. I'll let you all know if anything comes of it. In the meantime, thanks for your (really quite friendly under the circumstances) comments. Cheers, - Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 6/9] signalfd/timerfd v1 - timerfd core ...
On Fri, 2007-03-09 at 22:38 -0800, Davide Libenzi wrote: > On Fri, 9 Mar 2007, Nicholas Miell wrote: > > > Why did you ignore the existing POSIX timer API? > > The existing POSIX API is a standard and a very good one. Too bad it does > not deliver to files. The timerfd code is, as you can probably read from > the code, a really thin wrapper around the existing hrtimer.c Linux code. So extend the existing POSIX timer API to deliver expiry events via a fd. -- Nicholas Miell <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 6/9] signalfd/timerfd v1 - timerfd core ...
On Fri, 9 Mar 2007, Nicholas Miell wrote: > On Fri, 2007-03-09 at 22:38 -0800, Davide Libenzi wrote: > > On Fri, 9 Mar 2007, Nicholas Miell wrote: > > > > > Why did you ignore the existing POSIX timer API? > > > > The existing POSIX API is a standard and a very good one. Too bad it does > > not deliver to files. The timerfd code is, as you can probably read from > > the code, a really thin wrapper around the existing hrtimer.c Linux code. > > So extend the existing POSIX timer API to deliver expiry events via a > fd. It'll be out of standard as timerfd is, w/out code savings. Look at the code and tell me what could be saved. Prolly the ten lines of the timer callback. Lines that you'll have to drop inside the current posix timer layer. Better leave standards alone, especially like in this case, when the savings are not there. - Davide - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Use attribute groups in struct device_type
On Sat, Mar 10, 2007 at 01:37:34AM -0500, Dmitry Torokhov wrote: > Greg, > > Please consider applying the patch below. It switches struct device_type > to using attribute groups which os more flexible. I am using it in my > input class_device -> device conversion (which is 99% done btw). Argh, I never sent you my version of that, did I? Very sorry about that, I was working on fixing up the device namespace issue first, which isn't done yet :( Anyway, my patch that did that is below, feel free to use it or not if you want. > I looked through -mm and the latest git and there does not seem to be > any users of struct device_type yet... Yes, the input patch below uses it and I have a block-device patch from Kay in my tree that Andrew doesn't pull from (as it's usually really messed up and I know to hide this kind of breakage from him...) thanks, greg k-h >From [EMAIL PROTECTED] Wed Sep 13 22:59:01 2006 Date: Wed, 13 Sep 2006 16:11:35 +0200 From: Kay Sievers <[EMAIL PROTECTED]> To: Greg KH <[EMAIL PROTECTED]> Subject: Driver core: convert input core to use struct device From: Kay Sievers <[EMAIL PROTECTED]> Converts from using struct "class_device" to "struct device" making everything show up properly in /sys/devices/ with symlinks from the /sys/class directory. Signed-off-by: Kay Sievers <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- drivers/hid/hid-input.c |2 drivers/hwmon/hdaps.c |2 drivers/input/evdev.c | 12 -- drivers/input/input.c | 110 -- drivers/input/joydev.c| 12 -- drivers/input/joystick/a3d.c |2 drivers/input/joystick/adi.c |2 drivers/input/joystick/cobra.c|2 drivers/input/joystick/gf2k.c |2 drivers/input/joystick/grip.c |2 drivers/input/joystick/grip_mp.c |2 drivers/input/joystick/guillemot.c|2 drivers/input/joystick/iforce/iforce-main.c |4 drivers/input/joystick/magellan.c |2 drivers/input/joystick/sidewinder.c |2 drivers/input/joystick/spaceball.c|2 drivers/input/joystick/spaceorb.c |2 drivers/input/joystick/stinger.c |2 drivers/input/joystick/tmdc.c |2 drivers/input/joystick/twidjoy.c |2 drivers/input/joystick/warrior.c |2 drivers/input/keyboard/atkbd.c|2 drivers/input/keyboard/corgikbd.c |2 drivers/input/keyboard/lkkbd.c|2 drivers/input/keyboard/newtonkbd.c|2 drivers/input/keyboard/spitzkbd.c |2 drivers/input/keyboard/sunkbd.c |2 drivers/input/keyboard/xtkbd.c|2 drivers/input/misc/pcspkr.c |2 drivers/input/misc/wistron_btns.c |2 drivers/input/mouse/psmouse-base.c|2 drivers/input/mouse/sermouse.c|2 drivers/input/mouse/vsxxxaa.c |2 drivers/input/mousedev.c | 24 +--- drivers/input/touchscreen/ads7846.c |2 drivers/input/touchscreen/corgi_ts.c |2 drivers/input/touchscreen/elo.c |2 drivers/input/touchscreen/h3600_ts_input.c|2 drivers/input/touchscreen/penmount.c |2 drivers/input/tsdev.c | 12 -- drivers/media/dvb/dvb-usb/dvb-usb-remote.c|2 drivers/media/video/bt8xx/bttv-input.c|2 drivers/media/video/cx88/cx88-input.c |2 drivers/media/video/saa7134/saa7134-input.c |2 drivers/media/video/usbvideo/konicawc.c |2 drivers/media/video/usbvideo/quickcam_messenger.c |2 drivers/usb/input/acecad.c|2 drivers/usb/input/aiptek.c|2 drivers/usb/input/appletouch.c|2 drivers/usb/input/ati_remote.c|2 drivers/usb/input/ati_remote2.c |2 drivers/usb/input/gtco.c |2 drivers/usb/input/itmtouch.c |2 drivers/usb/input/kbtab.c |2 drivers/usb/input/keyspan_remote.c|2 drivers/usb/input/mtouchusb.c |2 drivers/usb/input/powermate.c |2 drivers/usb/input/touchkitusb.c |2 drivers/usb/input/usbkbd.c|2 drivers/usb/input/usbmouse.c |2
Re: [PATCH] Use attribute groups in struct device_type
On Fri, Mar 09, 2007 at 10:54:43PM -0800, Greg KH wrote:
> On Sat, Mar 10, 2007 at 01:37:34AM -0500, Dmitry Torokhov wrote:
> > Greg,
> >
> > Please consider applying the patch below. It switches struct device_type
> > to using attribute groups which os more flexible. I am using it in my
> > input class_device -> device conversion (which is 99% done btw).
>
> Argh, I never sent you my version of that, did I? Very sorry about
> that, I was working on fixing up the device namespace issue first, which
> isn't done yet :(
>
> Anyway, my patch that did that is below, feel free to use it or not if
> you want.
>
> > I looked through -mm and the latest git and there does not seem to be
> > any users of struct device_type yet...
>
> Yes, the input patch below uses it and I have a block-device patch from
> Kay in my tree that Andrew doesn't pull from (as it's usually really
> messed up and I know to hide this kind of breakage from him...)
Oops, that patch didn't use it, this follow-on patch from Kay uses them.
thanks,
greg k-h
>From [EMAIL PROTECTED] Sat Oct 7 13:11:36 2006
From: Kay Sievers <[EMAIL PROTECTED]>
Date: Sat, 07 Oct 2006 21:54:55 +0200
Subject: Driver core: swich input_device to device_type
Message-Id: <[EMAIL PROTECTED]>
Signed-off-by: Kay Sievers <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/input/input.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -853,16 +853,10 @@ static int input_add_uevent_modalias_var
static int input_dev_uevent(struct device *d, char **envp,
int num_envp, char *buffer, int buffer_size)
{
- struct input_dev *dev;
+ struct input_dev *dev = to_input_dev(d);
int i = 0;
int len = 0;
- /* input is a single class, this is only valid for input_dev's */
- if (strncmp("input", kobject_name(>kobj), 5) != 0)
- return 0;
-
- dev = to_input_dev(d);
-
INPUT_ADD_HOTPLUG_VAR("PRODUCT=%x/%x/%x/%x",
dev->id.bustype, dev->id.vendor,
dev->id.product, dev->id.version);
@@ -898,10 +892,13 @@ static int input_dev_uevent(struct devic
return 0;
}
+struct device_type input_dev_type = {
+ .uevent = input_dev_uevent,
+ .release= input_dev_release,
+};
+
struct class input_class = {
.name = "input",
- .dev_release= input_dev_release,
- .dev_uevent = input_dev_uevent,
};
EXPORT_SYMBOL_GPL(input_class);
@@ -922,6 +919,7 @@ struct input_dev *input_allocate_device(
if (dev) {
device_initialize(>d);
dev->d.class = _class;
+ dev->d.type = _dev_type;
mutex_init(>mutex);
INIT_LIST_HEAD(>h_list);
INIT_LIST_HEAD(>node);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Pluggable Schedulers (was: [ANNOUNCE] RSDL completely fair starvation free interactive cpu scheduler)
William Lee Irwin III wrote: This sort of concern is too subjective for me to have an opinion on it. On Fri, Mar 09, 2007 at 11:43:46PM +0300, Al Boldi wrote: >>> How diplomatic. William Lee Irwin III wrote: >> Impoliteness doesn't accomplish anything I want to do. On Sat, Mar 10, 2007 at 08:34:25AM +0300, Al Boldi wrote: > Fair enough. But being honest about it, without flaming, may be more > constructive. There was no flamage. It is literally true. William Lee Irwin III wrote: >> I'm more of a cooperative than competitive person, not to say that >> flies well in Linux. There are more productive uses of time than having >> everyone NIH'ing everyone else's code. If the result isn't so great, >> I'd rather send them code or talk them about what needs to be done. On Sat, Mar 10, 2007 at 08:34:25AM +0300, Al Boldi wrote: > Ok, let's call it cooperative competitiveness. You know, the kind of > competitiveness that drives improvements that helps everybody This trips over ideological issues best not discussed on lkml. William Lee Irwin III wrote: >> The extant versions of it fall well short of Linus' challenge as well >> as my original goals for it. On Sat, Mar 10, 2007 at 08:34:25AM +0300, Al Boldi wrote: > Do you mean Peter Williams' PlugSched-6.5-for-2.6.20? You'd be well-served by talking to Peter Williams sometime. He's a knowledgable individual. I should also mention that Con Kolivas did significant amounts of work to get the early codebase he inherited from me working before things were handed off to Peter Williams. William Lee Irwin III wrote: >> A useful exercise may also be enumerating >> your expectations and having those who actually work with the code >> describe how well those are actually met. On Sat, Mar 10, 2007 at 08:34:25AM +0300, Al Boldi wrote: > A runtime configurable framework that allows for dynamically extensible > schedulers. PlugSched seems to be a good start. Last I checked there were limits to runtime configurability centering around only supporting a compiled-in set of scheduling drivers, unless Peter's taken it the rest of the way without my noticing. It's unclear what you have in mind in terms of dynamic extensibility. My only guess would be pluggable scheduling policy/class support for individual schedulers in addition to plugging the individual schedulers, except I'm rather certain that Williams' code doesn't do anything with modules. -- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Use attribute groups in struct device_type
On Saturday 10 March 2007 01:55, Greg KH wrote: > On Fri, Mar 09, 2007 at 10:54:43PM -0800, Greg KH wrote: > > On Sat, Mar 10, 2007 at 01:37:34AM -0500, Dmitry Torokhov wrote: > > > Greg, > > > > > > Please consider applying the patch below. It switches struct device_type > > > to using attribute groups which os more flexible. I am using it in my > > > input class_device -> device conversion (which is 99% done btw). > > > > Argh, I never sent you my version of that, did I? Very sorry about > > that, I was working on fixing up the device namespace issue first, which > > isn't done yet :( > > > > Anyway, my patch that did that is below, feel free to use it or not if > > you want. > > > > > I looked through -mm and the latest git and there does not seem to be > > > any users of struct device_type yet... > > > > Yes, the input patch below uses it and I have a block-device patch from > > Kay in my tree that Andrew doesn't pull from (as it's usually really > > messed up and I know to hide this kind of breakage from him...) > > Oops, that patch didn't use it, this follow-on patch from Kay uses them. > Ok, so input portion in your tree does not use type->attrs so we don't have a conflict here. Unless my patch messes up Kay's blockdev patch badly I'd like you to accept it. Input uses 3 attribute groups and I don't want to open-code their creation/removal. -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 9/9] signalfd/timerfd v1 - timerfd compat code ...
On Fri, 9 Mar 2007, Davide Libenzi wrote: > +asmlinkage long compat_sys_timerfd(int ufd, int tmrtype, > +const struct timespec __user *utmr) compat_timespec, that is. - Davide - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] Make entire ACPI submenu dependent on PM.
This patch is right, and I applied it. On i386, it did what it should -- made the menus look better. Testing x86_64 exposed a latent bug, however. Since CONFIG_X86_64_ACPI_NUMA=y does a select on ACPI, it is possible to config a kernel with PM=n and ACPI=y, which violates ACPI's dependency on PM. Basically, select of something that has dependencies doesn't enforce those dependencies. When will somebody re-write Kconfig into something that humans can use? -Len On Sunday 04 March 2007 13:17, Robert P. J. Day wrote: > > Make the visibility of the entire ACPI submenu dependent on PM. > > Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]> > > --- > > given that de-selecting Power Management (PM) de-activates the > entire contents of the ACPI submenu, it seems pointless to leave the > top-level menu entry visible. but this is just a hack and i'll leave > it to the official maintainers to do it properly. :-) > > diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig > index 7c49e10..3208ce0 100644 > --- a/drivers/acpi/Kconfig > +++ b/drivers/acpi/Kconfig > @@ -7,6 +7,7 @@ menu "ACPI (Advanced Configuration and Power Interface) > Support" > depends on !X86_VISWS > depends on !IA64_HP_SIM > depends on IA64 || X86 > + depends on PM > > config ACPI > bool "ACPI Support" > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 PATCH] ACPI patches for 2.6.21-rc3
Hi Linus, please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git release This should delete a good part of the 2.6.21-rc regression list. This will update the files shown below. thanks! -Len ps. individual patches are available on linux-acpi@vger.kernel.org and a consolidated plain patch is available here: ftp://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release/2.6.21/acpi-release-20070126-2.6.21-rc3.diff.gz Documentation/kernel-parameters.txt |3 arch/i386/kernel/acpi/boot.c| 23 arch/ia64/sn/kernel/io_acpi_init.c | 44 arch/ia64/sn/kernel/setup.c |2 drivers/acpi/Kconfig| 12 ++ drivers/acpi/blacklist.c| 10 +- drivers/acpi/ec.c | 40 drivers/acpi/events/evmisc.c| 25 - drivers/acpi/ibm_acpi.c | 28 + drivers/acpi/power.c| 20 +--- drivers/acpi/resources/rscreate.c | 25 - drivers/acpi/video.c| 38 +++ drivers/ata/libata-acpi.c |7 + drivers/misc/asus-laptop.c |2 drivers/misc/sony-laptop.c |2 drivers/pnp/pnpacpi/rsparser.c | 120 ++-- 16 files changed, 271 insertions(+), 130 deletions(-) through these commits: Adrian Bunk (1): asus-laptop: make code static Alexey Starikovskiy (2): ACPICA: Fix ACPI Global Lock re-entrancy ACPI: ec: fix race in status register access Andrew Morton (1): sony-laptop: fix uninitialised variable Anthony Godshall, Ampro Computers, Inc (1): ACPI: make blacklist more verbose Bernhard Walle (1): ACPI: Add kernel-parameters hint that acpi=off doesn't work on IA64. Henrique de Moraes Holschuh (3): ACPI: ibm-acpi: fix initial status of backlight device ACPI: ibm-acpi: make ibm-acpi bay support optional ACPI: ibm-acpi: improve backlight power handling John Keller (2): ACPI: Altix: cannot register acpi bus driver before bus scan ACPI: Altix: reinitialize acpi tables Julius Volz (1): ACPI: video: Fix spelling and grammar mistakes Konstantin Karasyov (2): ACPI: fix S3 fan resume issue ACPI: ThinkPad Z60m: usb mouse stops working after suspend to RAM Kristen Accardi (1): libata-acpi: allow _GTF on SATA, but disable on PATA for now Len Brown (2): ACPI: fix Thinkpad 600/600E/600X interrupts ACPI: repair nvidia early quirk breakage on x86_64 Michael Karcher (1): ACPI: fix parallel port IRQ after resume from S3 Robert P. J. Day (1): ACPI: Kconfig: hide ACPI menu when CONFIG_PM=n Shaohua Li (1): ACPI: fix boot hang w/o "noapic" on MSI MS-6390-L with this log: commit 63e34ca93a62f472144db60fa3b8c0d15721 Merge: 51e7fff... 9327f46... Author: Len Brown <[EMAIL PROTECTED]> Date: Fri Mar 9 23:19:50 2007 -0500 Pull misc-for-upstream into release branch commit 51e7fff1c2b763da910db3a875eac5b992df91d9 Merge: bdf3aaf... 9e19721... Author: Len Brown <[EMAIL PROTECTED]> Date: Fri Mar 9 23:19:25 2007 -0500 Pull bugzilla-8110 into release branch commit bdf3aaf9519ddd8a026b5e04e713d2fa673532e5 Merge: b252630... 610a3d0... Author: Len Brown <[EMAIL PROTECTED]> Date: Fri Mar 9 23:19:19 2007 -0500 Pull bugzilla-8066 into release branch commit b2526300ab242dc31f9006dbf9a4de40797571bc Merge: cb2ebc5... df33c77... Author: Len Brown <[EMAIL PROTECTED]> Date: Fri Mar 9 23:18:53 2007 -0500 Pull bugzilla-7907 into release branch commit cb2ebc59ff52cee770cfd6ba5f23a6cc3c214648 Merge: 3dfb737... 7292576... Author: Len Brown <[EMAIL PROTECTED]> Date: Fri Mar 9 23:18:46 2007 -0500 Pull bugzilla-7570 into release branch commit 3dfb737998c265d3c8a15b931dc4d72335ab8255 Merge: 63be2d9... 2f894ef... Author: Len Brown <[EMAIL PROTECTED]> Date: Fri Mar 9 23:18:35 2007 -0500 Pull bugzilla-6859 into release branch commit 63be2d9305a5865580c6faee2c1eb477c09eac18 Merge: 653351b... 362ea08... Author: Len Brown <[EMAIL PROTECTED]> Date: Fri Mar 9 23:18:22 2007 -0500 Pull bugzilla-6316 into release branch commit 653351b0b9c97d4ec93aed499b542cbcd85309ca Merge: 5cb69bc... 74586fc... Author: Len Brown <[EMAIL PROTECTED]> Date: Fri Mar 9 23:18:05 2007 -0500 Pull bugzilla-5966 into release branch commit 5cb69bcacea70024252138a9cb4229a142a93389 Merge: c207908... c9bf296... Author: Len Brown <[EMAIL PROTECTED]> Date: Fri Mar 9 23:17:46 2007 -0500 Pull ibm into release branch commit c207908fcc451e31d7fbba31541bd04f93787eb4 Merge: a967e12... 3fd0b2d... Author: Len Brown <[EMAIL PROTECTED]> Date: Fri Mar 9 23:17:39 2007 -0500 Pull altix into release branch commit 9e197219605513c14d3eae41039ecf1b82d1920d Author: Alexey Starikovskiy <[EMAIL PROTECTED]> Date: Wed Mar 7 18:29:35 2007 -0500 ACPI: ec: fix race in status register access Delay the read of the EC status register until after the event that
Re: [patch 6/9] signalfd/timerfd v1 - timerfd core ...
On Fri, 2007-03-09 at 22:53 -0800, Davide Libenzi wrote: > On Fri, 9 Mar 2007, Nicholas Miell wrote: > > > On Fri, 2007-03-09 at 22:38 -0800, Davide Libenzi wrote: > > > On Fri, 9 Mar 2007, Nicholas Miell wrote: > > > > > > > Why did you ignore the existing POSIX timer API? > > > > > > The existing POSIX API is a standard and a very good one. Too bad it does > > > not deliver to files. The timerfd code is, as you can probably read from > > > the code, a really thin wrapper around the existing hrtimer.c Linux code. > > > > So extend the existing POSIX timer API to deliver expiry events via a > > fd. > > It'll be out of standard as timerfd is, w/out code savings. Look at the > code and tell me what could be saved. Prolly the ten lines of the timer > callback. Lines that you'll have to drop inside the current posix timer > layer. Better leave standards alone, especially like in this case, when > the savings are not there. > OK, here's a more formal listing of my objections to the introduction of timerfd in this form: A) It is a new general-purpose ABI intended for wide-scale usage, and thus must be maintained forever. B) It is less functional than the existing ABIs -- modulo their "delivery via signals only" limitation, which can be corrected (and has been already in other operating systems). C) Being an entirely new creation that completely ignores past work in this area, it has no hope of ever getting into POSIX. which means D) At some point in time, Linux is going to get the POSIX version (in whatever form it takes), making this new ABI useless dead weight (see point A). -- Nicholas Miell <[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/
sparc atomicity patches reverted
The sparc64 one doesn't even compile, please fix this up and resubmit,
thank you. I'd like you to redo the 32-bit sparc patch too.
Please, I recommend that you use {sec,clear,etc.}_ti_thread_flag() in
this and the 32-bit sparc TI_USEDFPU patch, instead of the task
versions which could add an unnecessary pointer dereference to go from
tsk to the thread_info.
It is likely that had you used the thread based flag helpers from the
start, you would not have created this build failure.
Thanks again.
arch/sparc64/kernel/process.c: In function $,1rx(Bflush_thread$,1ry(B:
arch/sparc64/kernel/process.c:416: error: $,1rx(Btsk$,1ry(B undeclared
(first use in this function)
arch/sparc64/kernel/process.c:416: error: (Each undeclared identifier is
reported only once
arch/sparc64/kernel/process.c:416: error: for each function it appears in.)
diff --git a/arch/sparc64/kernel/process.c b/arch/sparc64/kernel/process.c
index 7d75cd4..646ace4 100644
--- a/arch/sparc64/kernel/process.c
+++ b/arch/sparc64/kernel/process.c
@@ -413,8 +413,13 @@ void flush_thread(void)
struct thread_info *t = current_thread_info();
struct mm_struct *mm;
- if (t->flags & _TIF_ABI_PENDING)
- t->flags ^= (_TIF_ABI_PENDING | _TIF_32BIT);
+ if (test_tsk_thread_flag(tsk, TIF_ABI_PENDING)) {
+ clear_tsk_thread_flag(tsk, TIF_ABI_PENDING);
+ if (test_tsk_thread_flag(tsk, TIF_32BIT))
+ clear_tsk_thread_flag(tsk, TIF_32BIT);
+ else
+ set_tsk_thread_flag(tsk, TIF_32BIT);
+ }
mm = t->task->mm;
if (mm)
--
1.5.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: [PATCH] Use attribute groups in struct device_type
On Sat, Mar 10, 2007 at 02:12:04AM -0500, Dmitry Torokhov wrote: > On Saturday 10 March 2007 01:55, Greg KH wrote: > > On Fri, Mar 09, 2007 at 10:54:43PM -0800, Greg KH wrote: > > > On Sat, Mar 10, 2007 at 01:37:34AM -0500, Dmitry Torokhov wrote: > > > > Greg, > > > > > > > > Please consider applying the patch below. It switches struct device_type > > > > to using attribute groups which os more flexible. I am using it in my > > > > input class_device -> device conversion (which is 99% done btw). > > > > > > Argh, I never sent you my version of that, did I? Very sorry about > > > that, I was working on fixing up the device namespace issue first, which > > > isn't done yet :( > > > > > > Anyway, my patch that did that is below, feel free to use it or not if > > > you want. > > > > > > > I looked through -mm and the latest git and there does not seem to be > > > > any users of struct device_type yet... > > > > > > Yes, the input patch below uses it and I have a block-device patch from > > > Kay in my tree that Andrew doesn't pull from (as it's usually really > > > messed up and I know to hide this kind of breakage from him...) > > > > Oops, that patch didn't use it, this follow-on patch from Kay uses them. > > > > Ok, so input portion in your tree does not use type->attrs so we don't > have a conflict here. Unless my patch messes up Kay's blockdev patch > badly I'd like you to accept it. Input uses 3 attribute groups and I > don't want to open-code their creation/removal. I'll take your patch and see if it messes up Kay's. If it does, I'm sure he will fix it up for me later :) thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH][RSDL-mm 0/6] Rotating Staircase DeadLine scheduler for -mm
What follows this email is a series of patches for the RSDL cpu scheduler as found in 2.6.21-rc3-mm1. This series is for 2.6.21-rc3-mm2 and has some bugfixes for the issues found so far. While it is not clear that I've attended to all the bugs, it is worth noting that a complete rewrite is a teensy bit more than a trivial change shall we say ;) akpm it still has trouble on that monster config of yours but there's so much else going on in this -mm I don't know what to make of it. getting ppc to work on qemu was more work than I thought and I haven't succeeded there yet either :| A rolled up patch can be found here: http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc3-mm2-rsdl.patch Patch series here: http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc3-mm2/ and the patch series will follow. If time permits I will make available a newer version for the older kernels soon. Changelog: - Made it possible for the idle task to schedule on cpu_hotplug. - Fixed the accounting across fork() - Recalculation of priority for tasks that have already run this major rotation and are now on the expired array was wrong. It has been corrected. - The bitmap error that has been hit on some architectures was made more verbose to make it clear that something has gone wrong, and will keep going off if the problem persists. -- -ck - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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][RSDL-mm 1/6] lists: add list splice tail
From: Con Kolivas <[EMAIL PROTECTED]>
Add a list_splice_tail variant of list_splice.
Patch-by: Peter Zijlstra <[EMAIL PROTECTED]>
Signed-off-by: Con Kolivas <[EMAIL PROTECTED]>
Cc: Ingo Molnar <[EMAIL PROTECTED]>
Cc: Nick Piggin <[EMAIL PROTECTED]>
Cc: "Siddha, Suresh B" <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
include/linux/list.h | 42 ++
1 file changed, 42 insertions(+)
Index: linux-2.6.21-rc3-mm2/include/linux/list.h
===
--- linux-2.6.21-rc3-mm2.orig/include/linux/list.h 2007-03-08
22:03:18.0 +1100
+++ linux-2.6.21-rc3-mm2/include/linux/list.h 2007-03-10 13:41:56.0
+1100
@@ -333,6 +333,20 @@ static inline void __list_splice(struct
at->prev = last;
}
+static inline void __list_splice_tail(struct list_head *list,
+ struct list_head *head)
+{
+ struct list_head *first = list->next;
+ struct list_head *last = list->prev;
+ struct list_head *at = head->prev;
+
+ first->prev = at;
+ at->next = first;
+
+ last->next = head;
+ head->prev = last;
+}
+
/**
* list_splice - join two lists
* @list: the new list to add.
@@ -345,6 +359,18 @@ static inline void list_splice(struct li
}
/**
+ * list_splice_tail - join two lists at one's tail
+ * @list: the new list to add.
+ * @head: the place to add it in the first list.
+ */
+static inline void list_splice_tail(struct list_head *list,
+ struct list_head *head)
+{
+ if (!list_empty(list))
+ __list_splice_tail(list, head);
+}
+
+/**
* list_splice_init - join two lists and reinitialise the emptied list.
* @list: the new list to add.
* @head: the place to add it in the first list.
@@ -417,6 +443,22 @@ static inline void list_splice_init_rcu(
}
/**
+ * list_splice_tail_init - join 2 lists at one's tail & reinitialise emptied
+ * @list: the new list to add.
+ * @head: the place to add it in the first list.
+ *
+ * The list at @list is reinitialised
+ */
+static inline void list_splice_tail_init(struct list_head *list,
+struct list_head *head)
+{
+ if (!list_empty(list)) {
+ __list_splice_tail(list, head);
+ INIT_LIST_HEAD(list);
+ }
+}
+
+/**
* list_entry - get the struct for this entry
* @ptr: the list_head pointer.
* @type: the type of the struct this is embedded in.
--
-ck
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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][RSDL-mm 2/6] sched: remove sleepavg from proc
From: Con Kolivas <[EMAIL PROTECTED]> Remove the sleep_avg field from proc output as it will be removed from the task_struct. Signed-off-by: Con Kolivas <[EMAIL PROTECTED]> Cc: Ingo Molnar <[EMAIL PROTECTED]> Cc: Nick Piggin <[EMAIL PROTECTED]> Cc: "Siddha, Suresh B" <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- fs/proc/array.c |2 -- 1 file changed, 2 deletions(-) Index: linux-2.6.21-rc3-mm2/fs/proc/array.c === --- linux-2.6.21-rc3-mm2.orig/fs/proc/array.c 2007-03-08 22:03:17.0 +1100 +++ linux-2.6.21-rc3-mm2/fs/proc/array.c2007-03-10 13:54:13.0 +1100 @@ -171,7 +171,6 @@ static inline char * task_state(struct t buffer += sprintf(buffer, "State:\t%s\n" - "SleepAVG:\t%lu%%\n" "Tgid:\t%d\n" "Pid:\t%d\n" "PPid:\t%d\n" @@ -179,7 +178,6 @@ static inline char * task_state(struct t "Uid:\t%d\t%d\t%d\t%d\n" "Gid:\t%d\t%d\t%d\t%d\n", get_task_state(p), - (p->sleep_avg/1024)*100/(102000/1024), p->tgid, p->pid, pid_alive(p) ? rcu_dereference(p->parent)->tgid : 0, tracer_pid, -- -ck - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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][RSDL-mm 4/6] sched implement 180 bit sched bitmap
From: Con Kolivas <[EMAIL PROTECTED]>
Modify the sched_find_first_bit function to work on a 180bit long bitmap.
Signed-off-by: Con Kolivas <[EMAIL PROTECTED]>
Cc: Ingo Molnar <[EMAIL PROTECTED]>
Cc: Nick Piggin <[EMAIL PROTECTED]>
Cc: "Siddha, Suresh B" <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
include/asm-generic/bitops/sched.h | 10 ++
include/asm-s390/bitops.h | 12 +---
2 files changed, 7 insertions(+), 15 deletions(-)
Index: linux-2.6.21-rc3-mm2/include/asm-generic/bitops/sched.h
===
--- linux-2.6.21-rc3-mm2.orig/include/asm-generic/bitops/sched.h
2006-11-30 11:30:41.0 +1100
+++ linux-2.6.21-rc3-mm2/include/asm-generic/bitops/sched.h 2007-03-10
13:54:18.0 +1100
@@ -6,8 +6,8 @@
/*
* Every architecture must define this function. It's the fastest
- * way of searching a 140-bit bitmap where the first 100 bits are
- * unlikely to be set. It's guaranteed that at least one of the 140
+ * way of searching a 180-bit bitmap where the first 100 bits are
+ * unlikely to be set. It's guaranteed that at least one of the 180
* bits is cleared.
*/
static inline int sched_find_first_bit(const unsigned long *b)
@@ -15,7 +15,7 @@ static inline int sched_find_first_bit(c
#if BITS_PER_LONG == 64
if (unlikely(b[0]))
return __ffs(b[0]);
- if (likely(b[1]))
+ if (b[1])
return __ffs(b[1]) + 64;
return __ffs(b[2]) + 128;
#elif BITS_PER_LONG == 32
@@ -27,7 +27,9 @@ static inline int sched_find_first_bit(c
return __ffs(b[2]) + 64;
if (b[3])
return __ffs(b[3]) + 96;
- return __ffs(b[4]) + 128;
+ if (b[4])
+ return __ffs(b[4]) + 128;
+ return __ffs(b[5]) + 160;
#else
#error BITS_PER_LONG not defined
#endif
Index: linux-2.6.21-rc3-mm2/include/asm-s390/bitops.h
===
--- linux-2.6.21-rc3-mm2.orig/include/asm-s390/bitops.h 2006-11-30
11:30:41.0 +1100
+++ linux-2.6.21-rc3-mm2/include/asm-s390/bitops.h 2007-03-10
13:54:18.0 +1100
@@ -729,17 +729,7 @@ find_next_bit (const unsigned long * add
return offset + find_first_bit(p, size);
}
-/*
- * Every architecture must define this function. It's the fastest
- * way of searching a 140-bit bitmap where the first 100 bits are
- * unlikely to be set. It's guaranteed that at least one of the 140
- * bits is cleared.
- */
-static inline int sched_find_first_bit(unsigned long *b)
-{
- return find_first_bit(b, 140);
-}
-
+#include
#include
#include
--
-ck
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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][RSDL-mm 3/6] sched: remove noninteractive flag
From: Con Kolivas <[EMAIL PROTECTED]>
Remove the TASK_NONINTERACTIVE flag as it will no longer be used.
Signed-off-by: Con Kolivas <[EMAIL PROTECTED]>
Cc: Ingo Molnar <[EMAIL PROTECTED]>
Cc: Nick Piggin <[EMAIL PROTECTED]>
Cc: "Siddha, Suresh B" <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
fs/pipe.c |7 +--
include/linux/sched.h |3 +--
2 files changed, 2 insertions(+), 8 deletions(-)
Index: linux-2.6.21-rc3-mm2/fs/pipe.c
===
--- linux-2.6.21-rc3-mm2.orig/fs/pipe.c 2007-03-07 21:20:36.0 +1100
+++ linux-2.6.21-rc3-mm2/fs/pipe.c 2007-03-10 13:54:18.0 +1100
@@ -41,12 +41,7 @@ void pipe_wait(struct pipe_inode_info *p
{
DEFINE_WAIT(wait);
- /*
-* Pipes are system-local resources, so sleeping on them
-* is considered a noninteractive wait:
-*/
- prepare_to_wait(>wait, ,
- TASK_INTERRUPTIBLE | TASK_NONINTERACTIVE);
+ prepare_to_wait(>wait, , TASK_INTERRUPTIBLE);
if (pipe->inode)
mutex_unlock(>inode->i_mutex);
schedule();
Index: linux-2.6.21-rc3-mm2/include/linux/sched.h
===
--- linux-2.6.21-rc3-mm2.orig/include/linux/sched.h 2007-03-08
22:03:18.0 +1100
+++ linux-2.6.21-rc3-mm2/include/linux/sched.h 2007-03-10 13:54:18.0
+1100
@@ -150,8 +150,7 @@ extern unsigned long weighted_cpuload(co
#define EXIT_ZOMBIE16
#define EXIT_DEAD 32
/* in tsk->state again */
-#define TASK_NONINTERACTIVE64
-#define TASK_DEAD 128
+#define TASK_DEAD 64
#define __set_task_state(tsk, state_value) \
do { (tsk)->state = (state_value); } while (0)
--
-ck
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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][RSDL-mm 6/6] sched: document rsdl cpu scheduler
From: Con Kolivas <[EMAIL PROTECTED]> Add comprehensive documentation of the RSDL cpu scheduler design. Signed-off-by: Con Kolivas <[EMAIL PROTECTED]> Cc: Ingo Molnar <[EMAIL PROTECTED]> Cc: Nick Piggin <[EMAIL PROTECTED]> Cc: "Siddha, Suresh B" <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- Documentation/sched-design.txt | 273 ++- 1 files changed, 267 insertions(+), 6 deletions(-) diff -puN Documentation/sched-design.txt~sched-document-rsdl-cpu-scheduler Documentation/sched-design.txt --- a/Documentation/sched-design.txt~sched-document-rsdl-cpu-scheduler +++ a/Documentation/sched-design.txt @@ -1,11 +1,14 @@ - Goals, Design and Implementation of the - new ultra-scalable O(1) scheduler + Goals, Design and Implementation of the ultra-scalable O(1) scheduler by + Ingo Molnar and the Rotating Staircase Deadline cpu scheduler policy + designed by Con Kolivas. - This is an edited version of an email Ingo Molnar sent to - lkml on 4 Jan 2002. It describes the goals, design, and - implementation of Ingo's new ultra-scalable O(1) scheduler. - Last Updated: 18 April 2002. + This was originally an edited version of an email Ingo Molnar sent to + lkml on 4 Jan 2002. It describes the goals, design, and implementation + of Ingo's ultra-scalable O(1) scheduler. It now contains a description + of the Rotating Staircase Deadline priority scheduler that was built on + this design. + Last Updated: Sun Feb 25 2007 Goal @@ -163,3 +166,261 @@ certain code paths and data constructs. code is smaller than the old one. Ingo + + +Rotating Staircase Deadline cpu scheduler policy + + +Design summary +== + +A novel design which incorporates a foreground-background descending priority +system (the staircase) with runqueue managed minor and major epochs (rotation +and deadline). + + +Features + + +A starvation free, strict fairness O(1) scalable design with interactivity +as good as the above restrictions can provide. There is no interactivity +estimator, no sleep/run measurements and only simple fixed accounting. +The design has strict enough a design and accounting that task behaviour +can be modelled and maximum scheduling latencies can be predicted by +the virtual deadline mechanism that manages runqueues. The prime concern +in this design is to maintain fairness at all costs determined by nice level, +yet to maintain as good interactivity as can be allowed within the +constraints of strict fairness. + + +Design description +== + +RSDL works off the principle of providing each task a quota of runtime that +it is allowed to run at each priority level equal to its static priority +(ie. its nice level) and every priority below that. When each task is queued, +the cpu that it is queued onto also keeps a record of that quota. If the +task uses up its quota it is decremented one priority level. Also, if the cpu +notices a quota full has been used for that priority level, it pushes +everything remaining at that priority level to the next lowest priority +level. Once every runtime quota has been consumed of every priority level, +a task is queued on the "expired" array. When no other tasks exist with +quota, the expired array is activated and fresh quotas are handed out. This +is all done in O(1). + + +Design details +== + +Each cpu has its own runqueue which micromanages its own epochs, and each +task keeps a record of its own entitlement of cpu time. Most of the rest +of these details apply to non-realtime tasks as rt task management is +straight forward. + +Each runqueue keeps a record of what major epoch it is up to in the +rq->prio_rotation field which is incremented on each major epoch. It also +keeps a record of quota available to each priority value valid for that +major epoch in rq->prio_quota[]. + +Each task keeps a record of what major runqueue epoch it was last running +on in p->rotation. It also keeps a record of what priority levels it has +already been allocated quota from during this epoch in a bitmap p->bitmap. + +The only tunable that determines all other details is the RR_INTERVAL. This +is set to 6ms (minimum on 1000HZ, higher at different HZ values). + +All tasks are initially given a quota based on RR_INTERVAL. This is equal to +RR_INTERVAL between nice values of 0 and 19, and progressively larger for +nice values from -1 to -20. This is assigned to p->quota and only changes +with changes in nice level. + +As a task is first queued, it checks in recalc_task_prio to see if it has +run at this runqueue's current priority rotation. If it has not, it will +have its p->prio level set to equal its p->static_prio (nice level) and will +be given a p->time_slice equal to the p->quota, and has its allocation +bitmap bit set in p->bitmap for its static priority (nice value). This +quota is then also added
Re: [patch 6/9] signalfd/timerfd v1 - timerfd core ...
On Fri, 9 Mar 2007, Nicholas Miell wrote: > On Fri, 2007-03-09 at 22:53 -0800, Davide Libenzi wrote: > > On Fri, 9 Mar 2007, Nicholas Miell wrote: > > > > > > So extend the existing POSIX timer API to deliver expiry events via a > > > fd. > > > > It'll be out of standard as timerfd is, w/out code savings. Look at the > > code and tell me what could be saved. Prolly the ten lines of the timer > > callback. Lines that you'll have to drop inside the current posix timer > > layer. Better leave standards alone, especially like in this case, when > > the savings are not there. > > > > OK, here's a more formal listing of my objections to the introduction of > timerfd in this form: > > A) It is a new general-purpose ABI intended for wide-scale usage, and > thus must be maintained forever. Yup > B) It is less functional than the existing ABIs -- modulo their > "delivery via signals only" limitation, which can be corrected (and has > been already in other operating systems). Less functional? Please, do tell me ... > C) Being an entirely new creation that completely ignores past work in > this area, it has no hope of ever getting into POSIX. > > which means > > D) At some point in time, Linux is going to get the POSIX version (in > whatever form it takes), making this new ABI useless dead weight (see > point A). Adding parameters/fields to a standard is going to create even more confusion than a new *single* function. And the code to cross-link the timerfd and the current posix timers is going to end up in being more complex than the current one. - Davide - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RSDL v0.28 for 2.6.20
Here is an update for RSDL to version 0.28 Full patch: http://ck.kolivas.org/patches/staircase-deadline/2.6.20-sched-rsdl-0.28.patch Series: http://ck.kolivas.org/patches/staircase-deadline/2.6.20/ The patch to get you from 0.26 to 0.28: http://ck.kolivas.org/patches/staircase-deadline/2.6.20/sched-rsdl-0.26-0.28.patch A similar patch and directories will be made for 2.6.21-rc3 without further announcement -- -ck - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
How soon is soon? MCP55 NCQ support on Linux...
Hi, I have seen your message in LKML archive: http://marc.theaimsgroup.com/?l=linux-kernel=116046278930988=2 It's dated 2006.10.10 and states that a patch to support NCQ on MCP55/MCP61 under Linux is coming "soon". Now it's five months later and I would like to ask when will it be supported? Especially when this seems to be the last NVidia chipset that has NCQ but isn't supported under Linux. Thanks in advance, Zoltán Böszörményi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ALIGN
On Wed, Mar 07, 2007 at 08:38:27AM -0800, Linus Torvalds wrote: > > > On Wed, 7 Mar 2007, Oleg Verych wrote: > > > > Probably it can be used to get rid of gccisms and "type fluff" due to > > bitwise arithmetics in ALIGN? > > Hell no. > > The typeof is there to make sure we have the right type, and it's simple. Right. Now i see. Thanks! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
patch msi-safer-state-caching.patch added to gregkh-2.6 tree
This is a note to let you know that I've just added the patch titled
Subject: msi: Safer state caching.
to my gregkh-2.6 tree. Its filename is
msi-safer-state-caching.patch
This tree can be found at
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/
>From [EMAIL PROTECTED] Thu Mar 8 12:05:21 2007
From: Eric W. Biederman <[EMAIL PROTECTED]>
Date: Thu, 08 Mar 2007 13:04:57 -0700
Subject: msi: Safer state caching.
To: Andrew Morton <[EMAIL PROTECTED]>, Linus Torvalds <[EMAIL PROTECTED]>
Cc: Jeff Garzik <[EMAIL PROTECTED]>, "Kok, Auke" <[EMAIL PROTECTED]>, Ingo
Molnar <[EMAIL PROTECTED]>, "Michael S. Tsirkin" <[EMAIL PROTECTED]>, Pavel
Machek <[EMAIL PROTECTED]>, Jens Axboe <[EMAIL PROTECTED]>, Adrian Bunk <[EMAIL
PROTECTED]>, Linux Kernel Mailing List , Thomas
Gleixner <[EMAIL PROTECTED]>, [EMAIL PROTECTED], Michal Piotrowski <[EMAIL
PROTECTED]>, Greg Kroah-Hartman <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>,
[EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
From: Eric W. Biederman <[EMAIL PROTECTED]>
There are two ways pci_save_state and pci_restore_state are used. As
helper functions during suspend/resume, and as helper functions around
a hardware reset event. When used as helper functions around a hardware
reset event there is no reason to believe the calls will be paired, nor
is there a good reason to believe that if we restore the msi state from
before the reset that it will match the current msi state. Since arch
code may change the msi message without going through the driver, drivers
currently do not have enough information to even know when to call
pci_save_state to ensure they will have msi state in sync with the other
kernel irq reception data structures.
It turns out the solution is straight forward, cache the state in the
existing msi data structures (not the magic pci saved things) and
have the msi code update the cached state each time we write to the hardware.
This means we never need to read the hardware to figure out what the hardware
state should be.
By modifying the caching in this manner we get to remove our save_state
routines and only need to provide restore_state routines.
The only fields that were at all tricky to regenerate were the msi and msi-x
control registers and the way we regenerate them currently is a bit dependent
upon assumptions on how we use the allow msi registers to be configured and used
making the code a little bit brittle. If we ever change what cases we allow
or how we configure the msi bits we can address the fragility then.
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/pci/msi.c| 150 +++
drivers/pci/pci.c|2
drivers/pci/pci.h|2
include/linux/msi.h |8 --
include/linux/pci_regs.h |1
5 files changed, 29 insertions(+), 134 deletions(-)
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -100,6 +100,7 @@ static void msi_set_mask_bit(unsigned in
BUG();
break;
}
+ entry->msi_attrib.masked = !!flag;
}
void read_msi_msg(unsigned int irq, struct msi_msg *msg)
@@ -179,6 +180,7 @@ void write_msi_msg(unsigned int irq, str
default:
BUG();
}
+ entry->msg = *msg;
}
void mask_msi_irq(unsigned int irq)
@@ -225,164 +227,60 @@ static struct msi_desc* alloc_msi_entry(
}
#ifdef CONFIG_PM
-static int __pci_save_msi_state(struct pci_dev *dev)
-{
- int pos, i = 0;
- u16 control;
- struct pci_cap_saved_state *save_state;
- u32 *cap;
-
- if (!dev->msi_enabled)
- return 0;
-
- pos = pci_find_capability(dev, PCI_CAP_ID_MSI);
- if (pos <= 0)
- return 0;
-
- save_state = kzalloc(sizeof(struct pci_cap_saved_state) + sizeof(u32) *
5,
- GFP_KERNEL);
- if (!save_state) {
- printk(KERN_ERR "Out of memory in pci_save_msi_state\n");
- return -ENOMEM;
- }
- cap = _state->data[0];
-
- pci_read_config_dword(dev, pos, [i++]);
- control = cap[0] >> 16;
- pci_read_config_dword(dev, pos + PCI_MSI_ADDRESS_LO, [i++]);
- if (control & PCI_MSI_FLAGS_64BIT) {
- pci_read_config_dword(dev, pos + PCI_MSI_ADDRESS_HI, [i++]);
- pci_read_config_dword(dev, pos + PCI_MSI_DATA_64, [i++]);
- } else
- pci_read_config_dword(dev, pos + PCI_MSI_DATA_32, [i++]);
- if (control & PCI_MSI_FLAGS_MASKBIT)
- pci_read_config_dword(dev, pos + PCI_MSI_MASK_BIT, [i++]);
- save_state->cap_nr = PCI_CAP_ID_MSI;
- pci_add_saved_cap(dev, save_state);
- return 0;
-}
-
static void __pci_restore_msi_state(struct pci_dev *dev)
{
- int i = 0, pos;
+ int pos;
u16 control;
- struct pci_cap_saved_state *save_state;
- u32 *cap;
+ struct msi_desc
patch pci-repair-pci_save-restore_state-so-we-can-restore-one-save-many-times.patch added to gregkh-2.6 tree
This is a note to let you know that I've just added the patch titled
Subject: pci: Repair pci_save/restore_state so we can restore one save
many times.
to my gregkh-2.6 tree. Its filename is
pci-repair-pci_save-restore_state-so-we-can-restore-one-save-many-times.patch
This tree can be found at
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/
>From [EMAIL PROTECTED] Thu Mar 8 12:06:39 2007
From: Eric W. Biederman <[EMAIL PROTECTED]>
Date: Thu, 08 Mar 2007 13:06:13 -0700
Subject: pci: Repair pci_save/restore_state so we can restore one save many
times.
To: Andrew Morton <[EMAIL PROTECTED]>, Linus Torvalds <[EMAIL PROTECTED]>
Cc: Jeff Garzik <[EMAIL PROTECTED]>, "Kok, Auke" <[EMAIL PROTECTED]>, Ingo
Molnar <[EMAIL PROTECTED]>, "Michael S. Tsirkin" <[EMAIL PROTECTED]>, Pavel
Machek <[EMAIL PROTECTED]>, Jens Axboe <[EMAIL PROTECTED]>, Adrian Bunk <[EMAIL
PROTECTED]>, Linux Kernel Mailing List , Thomas
Gleixner <[EMAIL PROTECTED]>, [EMAIL PROTECTED], Michal Piotrowski <[EMAIL
PROTECTED]>, Greg Kroah-Hartman <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>,
[EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
From: Eric W. Biederman <[EMAIL PROTECTED]>
Because we do not reserve space for the pci-x and pci-e state in struct
pci dev we need to dynamically allocate it. However because we need
to support restore being called multiple times after a single save
it is never safe to free the buffers we have allocated to hold the
state.
So this patch modifies the save routines to first check to see
if we have already allocated a state buffer before allocating
a new one. Then the restore routines are modified to not free
the state after restoring it. Simple and it fixes some subtle
error path handling bugs, that are hard to test for.
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/pci/pci.c | 12 ++--
include/linux/pci.h |5 -
2 files changed, 6 insertions(+), 11 deletions(-)
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -551,7 +551,9 @@ static int pci_save_pcie_state(struct pc
if (pos <= 0)
return 0;
- save_state = kzalloc(sizeof(*save_state) + sizeof(u16) * 4, GFP_KERNEL);
+ save_state = pci_find_saved_cap(dev, PCI_CAP_ID_EXP);
+ if (!save_state)
+ save_state = kzalloc(sizeof(*save_state) + sizeof(u16) * 4,
GFP_KERNEL);
if (!save_state) {
dev_err(>dev, "Out of memory in pci_save_pcie_state\n");
return -ENOMEM;
@@ -582,8 +584,6 @@ static void pci_restore_pcie_state(struc
pci_write_config_word(dev, pos + PCI_EXP_LNKCTL, cap[i++]);
pci_write_config_word(dev, pos + PCI_EXP_SLTCTL, cap[i++]);
pci_write_config_word(dev, pos + PCI_EXP_RTCTL, cap[i++]);
- pci_remove_saved_cap(save_state);
- kfree(save_state);
}
@@ -597,7 +597,9 @@ static int pci_save_pcix_state(struct pc
if (pos <= 0)
return 0;
- save_state = kzalloc(sizeof(*save_state) + sizeof(u16), GFP_KERNEL);
+ save_state = pci_find_saved_cap(dev, PCI_CAP_ID_EXP);
+ if (!save_state)
+ save_state = kzalloc(sizeof(*save_state) + sizeof(u16),
GFP_KERNEL);
if (!save_state) {
dev_err(>dev, "Out of memory in pci_save_pcie_state\n");
return -ENOMEM;
@@ -622,8 +624,6 @@ static void pci_restore_pcix_state(struc
cap = (u16 *)_state->data[0];
pci_write_config_word(dev, pos + PCI_X_CMD, cap[i++]);
- pci_remove_saved_cap(save_state);
- kfree(save_state);
}
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -222,11 +222,6 @@ static inline void pci_add_saved_cap(str
hlist_add_head(_cap->next, _dev->saved_cap_space);
}
-static inline void pci_remove_saved_cap(struct pci_cap_saved_state *cap)
-{
- hlist_del(>next);
-}
-
/*
* For PCI devices, the region numbers are assigned this way:
*
Patches currently in gregkh-2.6 which might be from [EMAIL PROTECTED] are
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc3 - oops on remove of USB dongle
Greg> On Fri, Mar 09, 2007 at 10:40:21AM -0500, John Stoffel wrote: >> >> Hi all, >> >> I've just compiled and installed 2.6.21-rc3 on my Dual CPU Dell >> Precision 610MT system. Dual 550mhz Xeon, 768mb of RAM. Mix of SCSI, >> ATA drives. I'm using the new ATA_ drivers for my PATA disks. >> >> After booting, I pulled my seldom used USB->serial device from the >> system to toss in my bag to bring to work. It's a Belkin F5U109 >> dongle. I noticed the following oops: Greg> Ugh, I have a fix for this in my tree, I'll send it to Linus in Greg> a few hours. Greg> sorry for taking so long with this... No problem. Oliver Neukum sent me a pair of patches to try (appended below) and they seem to have done the trick just fine now. I can plug/unplug the device without any more oopses. Hopefully this will make it into 2.6.21-rc4 Cheers, John - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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-rc3 - oops on remove of USB dongle
Duh... forgot the patches: 2.6.21-rc-usb-serial.patch Description: two patches for usbserial oops on 2.6.21-rc3
Re: [linux-usb-devel] Question re hiddev
On Friday 09 March 2007, Adam Kropelin wrote: >Gene Heskett wrote: >> On Thursday 08 March 2007, Gene Heskett wrote: >>> Greetings; >>> >>> Belkin is being non-responsive to requests for updated drivers for >>> their line of UPS's, all of which now have a USB port which is the >>> Belkin recommended way to talk to these things. >>> >>> Unforch, the belkin supplied *nix stuff was last compiled on an rh5.2 >>> machine using gcc-2.7.2, so there has been some bitrot. >>> >>> I believe the problem to be that when their version of upsd is >>> trying to open the /dev/name its given, it is assuming and hard >>> coded to do the ioctl's to set the ports speed in baudrate, width of >>> word, parity etc. >>> >>> Getting failure messages for that, it retrys the open until it has >>> 1024 links to /dev/hiddev0 according to an lsof|grep hiddev0, all of >>> which presumably have failed so it never actually opens the >>> /dev/hiddev0 port in r/w mode successfully. >>> >>> I can, from a shell, 'cat' the data from this port, its not very fast >>> taking about 8-10 seconds to output all the integers or bytes to >>> constitute a complete screen update when translated by the gui into >>> sensible data. >>> >>> My proposal, and I'll see if I can make a patch, is to add to the >>> hiddev.c code, stubs for these otherwise useless functions that do >>> nothing but return a 0 indicating success so that these legacy >>> drivers can make use of a port whose data is just fine but fails >>> these configuration things that don't mean squat to hiddev anyway. >>> >>> Would this effort at making legacy drivers who think they are >>> using /dev/ttySx, work with /dev/hiddev constitute an acceptable >>> reason for such a patch to hiddev.c? >> >> Its been about a day now, and no one has commented. Am I an idiot or >> ?? > >I think you fundamentally misunderstand hiddev. It's an interface to HID >devices, which are not (NOT!) byte streams of the sort you'd get on >/dev/ttySx. hiddev speaks in specific structures via read/write/ioctl as >detailed in Documentation/usb/hiddev.txt. Any application which is >making tty ioctls to set baud rate, etc. will never work (unmodified) >with hiddev. > >Your Belkin UPS may follow the USB HID class spec for Power Devices, in >which case a suite like NUT will be able to handle it with their >USB-generic driver. > >--Adam I *think* I had the nut daemon working a couple of days ago, it at least ran without getting a tummy ache and upchucking into the logs. But as for using that data usefully, nuts docs might as well be written in swahili. It also doesn't seem to have a gui like the belkin programs give. Or I don't know how to set it up to use a gui. Either is a strong possibility... If anyone else has it working, please speak up. The ups is a Belkin F6C-1500, with some more adjectives appended that have nothing to do with the electronics in it. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) UPS interrupted the server's power - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 PATCH] USB fixes for 2.6.21-rc3
Here are some USB fixes and new device ids against 2.6.21-rc3. These patches contain a number of fixes that lots of people have reported with regards to usb-serial devices oopsing and providing incorrect minor numbers. They also add a number of new device ids and some other minor fixes. All of these have been in the -mm releases. Please pull from: master.kernel.org:/pub/scm/linux/kernel/git/gregkh/usb-2.6.git/ The full patches will be sent to the linux-usb-devel mailing list, if anyone wants to see them. thanks, greg k-h drivers/usb/class/cdc-acm.c|8 ++-- drivers/usb/core/devio.c | 13 ++--- drivers/usb/core/hub.c |9 +--- drivers/usb/core/message.c |9 +++- drivers/usb/gadget/at91_udc.c |6 +- drivers/usb/gadget/goku_udc.c | 29 drivers/usb/gadget/pxa2xx_udc.c|2 +- drivers/usb/host/ehci-hub.c|3 +- drivers/usb/host/uhci-hub.c| 11 +++-- drivers/usb/misc/ftdi-elan.c | 18 ++- drivers/usb/net/dm9601.c |4 ++ drivers/usb/serial/airprime.c | 47 +++ drivers/usb/serial/cp2101.c|2 + drivers/usb/serial/ftdi_sio.c | 90 ++- drivers/usb/serial/ftdi_sio.h | 21 drivers/usb/serial/ipaq.c |2 + drivers/usb/serial/usb-serial.c| 22 drivers/usb/storage/unusual_devs.h | 17 +++ 18 files changed, 186 insertions(+), 127 deletions(-) --- Alan Stern (2): USB: set the correct interval for interrupt URBs UHCI: fix port resume problem Andre Spahlinger (1): USB: ipaq.c: Additional devices Andrew Nayenko (1): USB storage: Nokia 6288 unusual_devs entry Cyrill Gorcunov (1): USB Elan FTDI: check for workqueue creation David Brownell (1): USB: at91_udc, fix more modpost bogosity (rename driver struct) Gard Spreemann (1): USB: Product ID for FT232RL in ftdi_sio Jim Radford (2): usb-serial: fix shutdown / device_unregister order USB: ftdi_sio: use port_probe / port_remove thereby fixing access to the latency_timer Jon K Hellan (1): USB: New device IDs for cp2101 driver Martin Schiller (1): USB: RTS/DTR signal patch for airprime driver Max Dmitrichenko (1): USB: fix Unaligned access in EHCI driver Michael Olberg (1): USB: add QL355P power supply ids to fdti_sio Milan Svoboda (1): USB: pxa2xx_udc: fix hardcoded irq number Oliver Neukum (5): USB: ratelimit debounce error messages USB: kill dead code from hub.c USB: fix usb-serial device naming bug USB: further fix for usb-serial USB: fix spinlock recursion in cdc-acm.c Phil Dibowitz (1): USB storage: Removed duplicate supertop unusual_dev entry Ralf Baechle (1): USB: goku_udc: Remove crude cache coherency code Thomas Schleusener (1): USB: add Additional PIDs in ftdi_sio YOSHIFUJI Hideaki (1): USBNET: DM9501: Add Corega FEther USB-TXC support. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 with 2.6.21rc2-git (ata: conflict with ide0/1)
Jeff Garzik wrote: > Which patch? > > Since this affects libata directly, and since devres came in via libata, > I would rather that libata bugs not get /too/ blocked by patches in > other trees. This one. http://article.gmane.org/gmane.linux.kernel/495515 -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] devres: release resources on device_del()
Some platform devices are driven without driver attached, so managed resources can be acquired without driver attached. Make sure such resources are released by calling devres_release_all() in device_del(). Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> --- This one fixes oops on pata_platform and pata_legacy unload. libata being the only user of devres at the moment. I think this can go through libata-dev#upstream. drivers/base/core.c |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/drivers/base/core.c b/drivers/base/core.c index cf2a398..89ebe36 100644 --- a/drivers/base/core.c +++ b/drivers/base/core.c @@ -787,6 +787,13 @@ void device_del(struct device * dev) device_remove_attrs(dev); bus_remove_device(dev); + /* +* Some platform devices are driven without driver attached +* and managed resources may have been acquired. Make sure +* all resources are released. +*/ + devres_release_all(dev); + /* Notify the platform of the removal, in case they * need to do anything... */ -- 1.5.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/
