Re: [Ext2-devel] Re: [RFC] ext3/jbd race: releasing in-use journal_heads
Suparna Bhattacharya <[EMAIL PROTECTED]> wrote: > > (let me know if the interface in the patch > I just posted seems like the right direction to use when we go for the > cleanup) Well what are the semantics? Pass in an inclusive max_index and the gang lookup functions terminate when they hit an item whose index is greater than max_index? And return the number of items thus found? Seems sensible, and all the comparisons do the right thing if max_index = -1. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] del_timer_sync scalability patch
Christoph Lameter <[EMAIL PROTECTED]> wrote:
>
> When a potential periodic timer is deleted through timer_del_sync, all
> cpus are scanned to determine if the timer is running on that cpu. In a
> NUMA configuration doing so will cause NUMA interlink traffic which limits
> the scalability of timers.
>
> The following patch makes the timer remember where the timer was last
> started. It is then possible to only wait for the completion of the timer
> on that specific cpu.
OK, I stared at this for a while and cannot see holes in it. There may
still be one though - this code is tricky. Probably any such holes would
be covered up by the fact that timers never migrate between CPUs anyway,
unless the handler chooses to do add_timer_on(), which I'm sure none do..
Ingo, could you take a look? Especially what happens if the timer hops
CPUs after the
/* Get where the timer ran last */
base = timer->last_running;
statement. Do we have sufficient barriers in there for this?
A few tidyings which I'd suggest:
- Remove TIMER_INIT_LASTRUNNING: struct initialisers set unmentioned fields
to zero anyway.
- Rename set_last_running() to timer_set_last_running, move it to timer.h.
Then use it in init_timer() to avoid an ifdef.
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/include/linux/timer.h | 21 ++---
25-akpm/kernel/timer.c| 10 +-
2 files changed, 11 insertions(+), 20 deletions(-)
diff -puN include/linux/timer.h~del_timer_sync-scalability-patch-tidy
include/linux/timer.h
--- 25/include/linux/timer.h~del_timer_sync-scalability-patch-tidy
2005-03-07 23:28:55.0 -0800
+++ 25-akpm/include/linux/timer.h 2005-03-07 23:30:23.0 -0800
@@ -26,12 +26,6 @@ struct timer_list {
#define TIMER_MAGIC0x4b87ad6e
-#ifdef CONFIG_SMP
-#define TIMER_INIT_LASTRUNNING .last_running = NULL,
-#else
-#define TIMER_INIT_LASTRUNNING
-#endif
-
#define TIMER_INITIALIZER(_function, _expires, _data) {\
.function = (_function),\
.expires = (_expires), \
@@ -39,9 +33,16 @@ struct timer_list {
.base = NULL, \
.magic = TIMER_MAGIC, \
.lock = SPIN_LOCK_UNLOCKED, \
- TIMER_INIT_LASTRUNNING \
}
+static inline void
+timer_set_last_running(struct timer_list *timer, struct tvec_t_base_s *base)
+{
+#ifdef CONFIG_SMP
+ timer->last_running = base;
+#endif
+}
+
/***
* init_timer - initialize a timer.
* @timer: the timer to be initialized
@@ -49,11 +50,9 @@ struct timer_list {
* init_timer() must be done to a timer prior calling *any* of the
* other timer functions.
*/
-static inline void init_timer(struct timer_list * timer)
+static inline void init_timer(struct timer_list *timer)
{
-#ifdef CONFIG_SMP
- timer->last_running = NULL;
-#endif
+ timer_set_last_running(timer, NULL);
timer->base = NULL;
timer->magic = TIMER_MAGIC;
spin_lock_init(>lock);
diff -puN kernel/timer.c~del_timer_sync-scalability-patch-tidy kernel/timer.c
--- 25/kernel/timer.c~del_timer_sync-scalability-patch-tidy 2005-03-07
23:28:55.0 -0800
+++ 25-akpm/kernel/timer.c 2005-03-07 23:28:55.0 -0800
@@ -86,14 +86,6 @@ static inline void set_running_timer(tve
#endif
}
-static inline void set_last_running(struct timer_list *timer,
- tvec_base_t *base)
-{
-#ifdef CONFIG_SMP
- timer->last_running = base;
-#endif
-}
-
/* Fake initialization */
static DEFINE_PER_CPU(tvec_base_t, tvec_bases) = { SPIN_LOCK_UNLOCKED };
@@ -482,7 +474,7 @@ repeat:
set_running_timer(base, timer);
smp_wmb();
timer->base = NULL;
- set_last_running(timer, base);
+ timer_set_last_running(timer, base);
spin_unlock_irq(>lock);
{
u32 preempt_count = preempt_count();
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc4-mm1] connector: Add a fork connector
Hello,
This patch cannot be apply on a 2.6.11-mm1 because connector is
missing in this release. The connector module should be back in the next
kernel release. That's why it applies on a 2.6.11-rc4-mm1 tree.
Also, there is a problem with the drivers/connector/connector.c file.
The test
if (msg->len != nlh->nlmsg_len - sizeof(*msg) - sizeof(*nlh))
must be replaced by
if (NLMSG_SPACE(msg->len + sizeof(*msg)) != nlh->nlmsg_len)
Without this change, there is a problem with the size of messages. It
should be fix in future version of the connector module.
ChangeLog:
- Add parenthesis around sizeof(struct cn_msg) + CN_FORK_INFO_SIZE
in the CN_FORK_MSG_SIZE macro
- fork_cn_lock is declared with DEFINE_SPINLOCK()
- fork_cn_lock is defined as static and local to fork_connector()
- Create a specific module cn_fork.c in drivers/connector to
register the callback
- Improve the callback that turns on/off the fork connector. Now
to enable the fork connector you need to send a message with
the length of the data equal to sizeof(int) and data is '1' to
enable (or '0' to disable).
TODO:
- Run the lmbench with the user space application that manages
group of processus. if fork connector is not used the only
overhead is a test in the do_fork() routine.
Thank you everyone for your comments,
Best regards,
Guillaume
Signed-off by: Guillaume Thouvenin <[EMAIL PROTECTED]>
---
drivers/connector/Kconfig | 11 +
drivers/connector/Makefile |1
drivers/connector/cn_fork.c | 85
include/linux/connector.h |4 ++
kernel/fork.c | 44 ++
5 files changed, 145 insertions(+)
diff -uprN -X dontdiff linux-2.6.11-rc4-mm1/drivers/connector/cn_fork.c
linux-2.6.11-rc4-mm1-cnfork/drivers/connector/cn_fork.c
--- linux-2.6.11-rc4-mm1/drivers/connector/cn_fork.c1970-01-01
01:00:00.0 +0100
+++ linux-2.6.11-rc4-mm1-cnfork/drivers/connector/cn_fork.c 2005-03-01
13:13:05.0 +0100
@@ -0,0 +1,85 @@
+/*
+ * cn_fork.c
+ *
+ * 2005 Copyright (c) Guillaume Thouvenin <[EMAIL PROTECTED]>
+ * All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+
+#include
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Guillaume Thouvenin <[EMAIL PROTECTED]>");
+MODULE_DESCRIPTION("Enable or disable the usage of the fork connector");
+
+int cn_fork_enable = 0;
+struct cb_id cb_fork_id = { CN_IDX_FORK, CN_VAL_FORK };
+
+/**
+ * cn_fork_callback - enable or disable the fork connector
+ * @data: message send by the connector
+ *
+ * The callback allows to enable or disable the sending of information
+ * about fork in the do_fork() routine. To enable the fork, the user
+ * space application must send the integer 1 in the data part of the
+ * message. To disable the fork connector, it must send the integer 0.
+ */
+static void cn_fork_callback(void *data)
+{
+ struct cn_msg *msg = (struct cn_msg *)data;
+
+ if (cn_already_initialized && (msg->len == sizeof(cn_fork_enable)))
+ memcpy(_fork_enable, msg->data, sizeof(cn_fork_enable));
+}
+
+/**
+ * cn_fork_init - initialization entry point
+ *
+ * This routine will be run at kernel boot time because this driver is
+ * built in the kernel. It adds the connector callback to the connector
+ * driver.
+ */
+static int cn_fork_init(void)
+{
+ int err;
+
+ err = cn_add_callback(_fork_id, "cn_fork", _fork_callback);
+ if (err) {
+ printk(KERN_WARNING "Failed to register cn_fork\n");
+ return -EINVAL;
+ }
+
+ printk(KERN_NOTICE "cn_fork is registered\n");
+ return 0;
+}
+
+/**
+ * cn_fork_exit - exit entry point
+ *
+ * As this driver is always statically compiled into the kernel the
+ * cn_fork_exit has no effect.
+ */
+static void cn_fork_exit(void)
+{
+ cn_del_callback(_fork_id);
+}
+
+module_init(cn_fork_init);
+module_exit(cn_fork_exit);
diff -uprN -X dontdiff linux-2.6.11-rc4-mm1/drivers/connector/Kconfig
linux-2.6.11-rc4-mm1-cnfork/drivers/connector/Kconfig
--- linux-2.6.11-rc4-mm1/drivers/connector/Kconfig 2005-02-23
11:12:15.0 +0100
+++
Re: pci_fixup_video() bogosity
On Tue, 2005-03-08 at 00:57 -0500, Jon Smirl wrote: > On Tue, 08 Mar 2005 15:38:29 +1100, Benjamin Herrenschmidt > <[EMAIL PROTECTED]> wrote: > > Hi ! > > > > While working on writing a VGA access arbiter for kernel & userland, > > I wondered how to properly get my "initial" state at boot. For that, > > I looked at how the new PCI ROM stuff does to find out who owns the > > memory shadow at c, and found it quite bogus. > > > > >From what I see, the code is only based on looking at what bridges > > have VGA forwarding enabled. It doesn't test the actual IO and Memory > > enable bits of the VGA cards themselves. > > Let's fix it up and make it more robust. I was playing with checking > IO/mem enable and forgot to finish it. Ok, have a look at my prototype VGA arbiter. I need something similar to spot the "default" VGA device at boot, maybe your stuff could be moved completely to the arbiter ? > > > What if you have 2 cards under the same bridge ? > > I believe the default on x86 is to pick the one in the lowest slot > number. What happens on PPC? What I mean is your code won't work afaik, you should check the one which has MEM/IO enabled. On PPC, I don't know, depends on the firmware, pretty much all pmac cards come with the legacy decoding disabled anyway (they are fully posted in "native" mode by the firmware). Some PPC's have x86 emulators and/or some VGA capabilities, but then, I expect only one of them to be left enabled by the firmware. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 10/13] remove aggressive idle balancing
Nick, On Mon, Mar 07, 2005 at 07:28:23PM +1100, Nick Piggin wrote: > Siddha, Suresh B wrote: > > We are resetting the nr_balance_failed to cache_nice_tries after kicking > > active balancing. But can_migrate_task will succeed only if > > nr_balance_failed > cache_nice_tries. > > > > It is indeed, thanks for catching that. We should probably make it > reset the count to the point where it will start moving cache hot > tasks (ie. cache_nice_tries+1). That still might not be enough. We probably need to pass push_cpu's sd to move_tasks call in active_load_balance, instead of current busiest_cpu's sd. Just like push_cpu, we need to add one more field to the runqueue which will specify the domain level of the push_cpu at which we have an imbalance. > > I'll look at that and send Andrew a patch. > > > > >>That said, we currently aren't doing _really_ well for SMT on > >>some workloads, however with this patch we are heading in the > >>right direction I think. > > > > > > Lets take an example of three packages with two logical threads each. > > Assume P0 is loaded with two processes(one in each logical thread), > > P1 contains only one process and P2 is idle. > > > > In this example, active balance will be kicked on one of the threads(assume > > thread 0) in P0, which then should find an idle package and move it to > > one of the idle threads in P2. > > > > With your current patch, idle package check in active_load_balance has > > disappeared, and we may endup moving the process from thread 0 to thread 1 > > in P0. I can't really make logic out of the active_load_balance code > > after your patch 10/13 > > > > Ah yep, right you are there, too. I obviously hadn't looked closely > enough at the recent active_load_balance patches that had gone in :( > What should probably do is heed the "push_cpu" prescription (push_cpu > is now unused). push_cpu might not be the ideal destination in all cases. Take a NUMA domain above SMT+SMP domains in my above example. Assume P0, P1 is in node-0 and P2, P3 in node-1. Assume Loads of P0,P1,P2 are same as the above example,with P3 containing one process load. Now any idle thread in P2 or P3 can trigger active load balance on P0. We should be selecting thread in P2 ideally (currently this is what we get with idle package check). But with push_cpu, we might move to the idle thread in P3 and then finally move to P2(it will be a two step process) thanks, suresh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] VGA arbitration: draft of kernel side
Hi !
Ok, so here is a first, totally untested draft for the kernel side
of the VGA arbiter.
BIG NOTE: It's really only the basic arbiter itself, which provides the
API I drafted a bit earlier, with arch hooks similar to what Alan proposed,
it does _NOT_ yet provides a userland interface (to a library providing the
same API hopefully).
It's totally untested (just tested that it builds on ppc32). Some
refinements from my original ideas is the notion of "default" VGA device
which is for vgacon (which would then be able to pass "NULL" to
vga_get/tryget/put, which is handy since current vgacon has no idea of
what a PCI device is). Possible room for a non-PCI device there, but I
haven't completely decided how to deal with that case (see comments in
the code).
Note about vgacon (or vesafb for what matters): I haven't yet looked at
what is involved in getting those adapted to the arbiter. As far as vgacon
is concerned, I strongly suspect that we'll need a way for a console write
to return -EAGAIN, telling to the printk core to come back later (either on
the next printk or from schedul'able time). That shouldn't be too difficult
tho. vesafb may need additional massaging too.
I don't know how much time I'll have on my hands to more forward with
adapting vgacon and doing a userland interface, I expect to be fairly busy
the rest of the week, so if any of you feel like picking up from there,
just let me know.
Ben.
Index: linux-work/include/linux/pci.h
===
--- linux-work.orig/include/linux/pci.h 2005-01-24 17:09:57.0 +1100
+++ linux-work/include/linux/pci.h 2005-03-08 15:26:25.0 +1100
@@ -1064,5 +1064,6 @@
#define PCIPCI_VSFX16
#define PCIPCI_ALIMAGIK32
+
#endif /* __KERNEL__ */
#endif /* LINUX_PCI_H */
Index: linux-work/drivers/pci/Makefile
===
--- linux-work.orig/drivers/pci/Makefile2005-01-24 17:09:38.0
+1100
+++ linux-work/drivers/pci/Makefile 2005-03-08 15:20:23.0 +1100
@@ -4,7 +4,7 @@
obj-y += access.o bus.o probe.o remove.o pci.o quirks.o \
names.o pci-driver.o search.o pci-sysfs.o \
- rom.o
+ rom.o vga.o
obj-$(CONFIG_PROC_FS) += proc.o
ifndef CONFIG_SPARC64
Index: linux-work/drivers/pci/remove.c
===
--- linux-work.orig/drivers/pci/remove.c2005-01-24 17:09:38.0
+1100
+++ linux-work/drivers/pci/remove.c 2005-03-08 15:25:52.0 +1100
@@ -26,6 +26,7 @@
static void pci_destroy_dev(struct pci_dev *dev)
{
+ vga_arbiter_del_pci_device(pdev);
pci_proc_detach_device(dev);
pci_remove_sysfs_dev_files(dev);
device_unregister(>dev);
Index: linux-work/drivers/pci/pci.h
===
--- linux-work.orig/drivers/pci/pci.h 2005-01-24 17:09:38.0 +1100
+++ linux-work/drivers/pci/pci.h2005-03-08 15:26:51.0 +1100
@@ -88,3 +88,7 @@
return NULL;
}
+
+/* VGA arbiter functions */
+extern void vga_arbiter_add_pci_device(struct pci_dev *pdev);
+extern void vga_arbiter_del_pci_device(struct pci_dev *pdev);
Index: linux-work/drivers/pci/vga.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-work/drivers/pci/vga.c2005-03-08 18:04:57.0 +1100
@@ -0,0 +1,403 @@
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "pci.h"
+
+/*
+ * We keep a list of all vga devices in the system to speed
+ * up the various operations of the arbiter
+ */
+struct vga_device
+{
+ struct list_headlist;
+ struct pci_dev *pdev;
+ unsigned intdecodes;/* what does it decodes */
+ unsigned intowns; /* what does it owns */
+ unsigned intlocks; /* what does it locks */
+};
+
+static LIST_HEAD( vga_list);
+static spinlock_t vga_lock;
+static DECLARE_WAIT_QUEUE_HEAD(vga_wait_queue);
+
+#ifndef __ARCH_HAS_VGA_DEFAULT_DEVICE
+static struct pci_dev *vga_default;
+#endif
+
+
+/* Find somebody in our list */
+static struct vga_device *vgadev_find(struct pci_dev *pdev)
+{
+ struct vga_device *vgadev;
+
+ list_for_each_entry(vgadev, _list, list)
+ if (pdev == vgadev->pdev)
+ return vgadev;
+ return NULL;
+}
+
+/* Returns the default VGA device (vgacon's babe) */
+#ifndef __ARCH_HAS_VGA_DEFAULT_DEVICE
+struct pci_dev *vga_default_device(void)
+{
+ return vga_default;
+}
+#endif
+
+/* Architecture can override enabling/disabling of a given
+ * device resources here
+ */
+#ifndef
Re: [Ext2-devel] Re: [RFC] ext3/jbd race: releasing in-use journal_heads
On Mon, Mar 07, 2005 at 10:46:18PM -0800, Andrew Morton wrote: > Suparna Bhattacharya <[EMAIL PROTECTED]> wrote: > > > > > > yup, looks like the same issue we hit in wait_on_page_writeback_range > > during AIO work - probably want to break out of the outer loop as well > > when this happens. > > The `next = page_index' before breaking will do that for us. > > > > > How hard would it be to add an end_index parameter to the radix tree > > lookup, since we seem to be hitting this in multiple places ? > > Really easy if you do it ;) > > Let's wait for this particular peiece of code to settle down, do a cleanup > sometime? > OK - we can postpone this (let me know if the interface in the patch I just posted seems like the right direction to use when we go for the cleanup). Regards Suparna -- Suparna Bhattacharya ([EMAIL PROTECTED]) Linux Technology Center IBM Software Lab, India - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ext2-devel] Re: [RFC] ext3/jbd race: releasing in-use journal_heads
Suparna Bhattacharya <[EMAIL PROTECTED]> wrote: > > > yup, looks like the same issue we hit in wait_on_page_writeback_range > during AIO work - probably want to break out of the outer loop as well > when this happens. The `next = page_index' before breaking will do that for us. > > How hard would it be to add an end_index parameter to the radix tree > lookup, since we seem to be hitting this in multiple places ? Really easy if you do it ;) Let's wait for this particular peiece of code to settle down, do a cleanup sometime? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] del_timer_sync scalability patch
When a potential periodic timer is deleted through timer_del_sync, all
cpus are scanned to determine if the timer is running on that cpu. In a
NUMA configuration doing so will cause NUMA interlink traffic which limits
the scalability of timers.
The following patch makes the timer remember where the timer was last
started. It is then possible to only wait for the completion of the timer
on that specific cpu.
Signed-off-by: Shai Fultheim <[EMAIL PROTECTED]>
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Index: linux-2.6.11/include/linux/timer.h
===
--- linux-2.6.11.orig/include/linux/timer.h 2005-03-07 21:42:43.539328640
-0800
+++ linux-2.6.11/include/linux/timer.h 2005-03-07 21:42:50.993195480 -0800
@@ -19,10 +19,19 @@ struct timer_list {
unsigned long data;
struct tvec_t_base_s *base;
+#ifdef CONFIG_SMP
+ struct tvec_t_base_s *last_running;
+#endif
};
#define TIMER_MAGIC0x4b87ad6e
+#ifdef CONFIG_SMP
+#define TIMER_INIT_LASTRUNNING .last_running = NULL,
+#else
+#define TIMER_INIT_LASTRUNNING
+#endif
+
#define TIMER_INITIALIZER(_function, _expires, _data) {\
.function = (_function),\
.expires = (_expires), \
@@ -30,6 +39,7 @@ struct timer_list {
.base = NULL, \
.magic = TIMER_MAGIC, \
.lock = SPIN_LOCK_UNLOCKED, \
+ TIMER_INIT_LASTRUNNING \
}
/***
@@ -41,6 +51,9 @@ struct timer_list {
*/
static inline void init_timer(struct timer_list * timer)
{
+#ifdef CONFIG_SMP
+ timer->last_running = NULL;
+#endif
timer->base = NULL;
timer->magic = TIMER_MAGIC;
spin_lock_init(>lock);
Index: linux-2.6.11/kernel/timer.c
===
--- linux-2.6.11.orig/kernel/timer.c2005-03-07 21:42:43.539328640 -0800
+++ linux-2.6.11/kernel/timer.c 2005-03-07 22:01:27.733425160 -0800
@@ -84,6 +84,14 @@ static inline void set_running_timer(tve
#endif
}
+static inline void set_last_running(struct timer_list *timer,
+ tvec_base_t *base)
+{
+#ifdef CONFIG_SMP
+ timer->last_running = base;
+#endif
+}
+
/* Fake initialization */
static DEFINE_PER_CPU(tvec_base_t, tvec_bases) = { SPIN_LOCK_UNLOCKED };
@@ -335,33 +343,41 @@ EXPORT_SYMBOL(del_timer);
*
* The function returns whether it has deactivated a pending timer or not.
*
- * del_timer_sync() is slow and complicated because it copes with timer
- * handlers which re-arm the timer (periodic timers). If the timer handler
- * is known to not do this (a single shot timer) then use
- * del_singleshot_timer_sync() instead.
+ * del_timer_sync() copes with time handlers which re-arm the timer (periodic
+ * timers). If the timer handler is known to not do this (a single shot
+ * timer) then use del_singleshot_timer_sync() instead.
*/
int del_timer_sync(struct timer_list *timer)
{
tvec_base_t *base;
- int i, ret = 0;
+ int ret = 0;
check_timer(timer);
del_again:
ret += del_timer(timer);
- for_each_online_cpu(i) {
- base = _cpu(tvec_bases, i);
- if (base->running_timer == timer) {
- while (base->running_timer == timer) {
- cpu_relax();
- preempt_check_resched();
- }
- break;
+ /* Get where the timer ran last */
+ base = timer->last_running;
+ if (base) {
+ /*
+* If the timer is still executing then wait until the
+* run is complete.
+*/
+ while (base->running_timer == timer) {
+ cpu_relax();
+ preempt_check_resched();
}
}
smp_rmb();
- if (timer_pending(timer))
+ /*
+* If the timer is no longer pending and its last run
+* was where we checked then the timer
+* is truly off. If the timer has been started on some other
+* cpu in the meantime (due to a race condition) then
+* we need to repeat what we have done.
+*/
+ if (timer_pending(timer) || timer->last_running != base)
goto del_again;
return ret;
@@ -464,6 +480,7 @@ repeat:
set_running_timer(base, timer);
smp_wmb();
timer->base = NULL;
+ set_last_running(timer, base);
spin_unlock_irq(>lock);
{
u32 preempt_count = preempt_count();
-
To unsubscribe from this list: send the line "unsubscribe
dereferencing module-internal pointer in scripts/mod/file2alias.c
Hi,
Is there any feasible way to dereference a pointer inside
__mod_*_device_table which points to a string?
e.g.:
include/linux/mod_devicetable.h:
struct pcmcia_device_id {
...
const char * prod_id;
...
}
drivers/some/driver.c:
static struct pcmcia_device_id some_ids[] = {
{.prod_id = "some device string", ...},
...
}
MODULE_DEVICE_TABLE(some_ids);
scripts/mod/file2alias.c:
do_pcmcia_entry (..., struct pcmcia_device_id *id, ...)
{
const char *tmp = id->prod_id + SOME_MAGIC_VALUE;
}
Thanks,
Dominik
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: NFS client bug in 2.6.8-2.6.11
Bernardo Innocenti wrote: Trond Myklebust wrote: I also can't reproduce the problem on an older client running 2.4.21. Well, actually I tried harder with the 2.4.21 client and I obtained a similar effect: naraku:/pub/linux/distro/fedora-devel# ll ls: .: Stale NFS file handle naraku:/pub/linux/distro/fedora-devel# cd - /arc/linux naraku:/arc/linux# cd - /pub/linux/distro/fedora-devel naraku:/pub/linux/distro/fedora-devel# ll ... (lots of files) So, instead of ENOENT I get ESTALE on 2.4.21. May well be a server bug then. The server is running 2.6.10-1.766_FC3. Do you think I should try installing a vanilla kernel on the server? -- // Bernardo Innocenti - Develer S.r.l., R dept. \X/ http://www.develer.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] [request for inclusion] Realtime LSM
Matt Mackall <[EMAIL PROTECTED]> wrote:
>
> Add a pair of rlimits for allowing non-root tasks to raise nice and rt
> priorities. Defaults to traditional behavior. Originally written by
> Chris Wright.
It needs some dinking with because Ingo has been playing games in my
resource.h. Here's the end result. Unlike yours, this will work on alpha,
mips and sparc[64], too ;)
From: Matt Mackall <[EMAIL PROTECTED]>
Add a pair of rlimits for allowing non-root tasks to raise nice and rt
priorities. Defaults to traditional behavior. Originally written by
Chris Wright.
The patch implements a simple rlimit ceiling for the RT (and nice) priorities
a task can set. The rlimit defaults to 0, meaning no change in behavior by
default. A value of 50 means RT priority levels 1-50 are allowed. A value of
100 means all 99 privilege levels from 1 to 99 are allowed. CAP_SYS_NICE is
blanket permission.
Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
Acked-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/include/asm-generic/resource.h |7 ++-
25-akpm/include/linux/sched.h |1 +
25-akpm/kernel/sched.c | 25 +++--
25-akpm/kernel/sys.c |2 +-
4 files changed, 27 insertions(+), 8 deletions(-)
diff -puN include/asm-generic/resource.h~nice-and-rt-prio-rlimits
include/asm-generic/resource.h
--- 25/include/asm-generic/resource.h~nice-and-rt-prio-rlimits 2005-03-07
22:50:45.0 -0800
+++ 25-akpm/include/asm-generic/resource.h 2005-03-07 22:52:10.0
-0800
@@ -41,8 +41,11 @@
#define RLIMIT_LOCKS 10 /* maximum file locks held */
#define RLIMIT_SIGPENDING 11 /* max number of pending signals */
#define RLIMIT_MSGQUEUE12 /* maximum bytes in POSIX
mqueues */
+#define RLIMIT_NICE13 /* max nice prio allowed to raise to
+ 0-39 for nice level 19 .. -20 */
+#define RLIMIT_RTPRIO 14 /* maximum realtime priority */
-#define RLIM_NLIMITS 13
+#define RLIM_NLIMITS 15
/*
* SuS says limits have to be unsigned.
@@ -81,6 +84,8 @@
[RLIMIT_LOCKS] = { RLIM_INFINITY, RLIM_INFINITY }, \
[RLIMIT_SIGPENDING] = { 0, 0 }, \
[RLIMIT_MSGQUEUE] = { MQ_BYTES_MAX, MQ_BYTES_MAX }, \
+ [RLIMIT_NICE] = { 0, 0 }, \
+ [RLIMIT_RTPRIO] = { 0, 0 }, \
}
#endif /* __KERNEL__ */
diff -puN include/linux/sched.h~nice-and-rt-prio-rlimits include/linux/sched.h
--- 25/include/linux/sched.h~nice-and-rt-prio-rlimits 2005-03-07
22:50:45.0 -0800
+++ 25-akpm/include/linux/sched.h 2005-03-07 22:50:45.0 -0800
@@ -872,6 +872,7 @@ extern void sched_idle_next(void);
extern void set_user_nice(task_t *p, long nice);
extern int task_prio(const task_t *p);
extern int task_nice(const task_t *p);
+extern int can_nice(const task_t *p, const int nice);
extern int task_curr(const task_t *p);
extern int idle_cpu(int cpu);
extern int sched_setscheduler(struct task_struct *, int, struct sched_param *);
diff -puN kernel/sched.c~nice-and-rt-prio-rlimits kernel/sched.c
--- 25/kernel/sched.c~nice-and-rt-prio-rlimits 2005-03-07 22:50:45.0
-0800
+++ 25-akpm/kernel/sched.c 2005-03-07 22:50:45.0 -0800
@@ -3304,6 +3304,19 @@ struct task_struct *kgdb_get_idle(int th
}
#endif
+/*
+ * can_nice - check if a task can reduce its nice value
+ * @p: task
+ * @nice: nice value
+ */
+int can_nice(const task_t *p, const int nice)
+{
+ /* convert nice value [19,-20] to rlimit style value [0,39] */
+ int nice_rlim = 19 - nice;
+ return (nice_rlim <= p->signal->rlim[RLIMIT_NICE].rlim_cur ||
+ capable(CAP_SYS_NICE));
+}
+
#ifdef __ARCH_WANT_SYS_NICE
/*
@@ -3323,12 +3336,8 @@ asmlinkage long sys_nice(int increment)
* We don't have to worry. Conceptually one call occurs first
* and we have a single winner.
*/
- if (increment < 0) {
- if (!capable(CAP_SYS_NICE))
- return -EPERM;
- if (increment < -40)
- increment = -40;
- }
+ if (increment < -40)
+ increment = -40;
if (increment > 40)
increment = 40;
@@ -3338,6 +3347,9 @@ asmlinkage long sys_nice(int increment)
if (nice > 19)
nice = 19;
+ if (increment < 0 && !can_nice(current, nice))
+ return -EPERM;
+
retval = security_task_setnice(current, nice);
if (retval)
return retval;
@@ -3453,6 +3465,7 @@ recheck:
return -EINVAL;
if ((policy == SCHED_FIFO || policy == SCHED_RR) &&
+ param->sched_priority > p->signal->rlim[RLIMIT_RTPRIO].rlim_cur &&
Re: [ patch 4/7] drivers/serial/jsm: new serial device driver
On Mon, Mar 07, 2005 at 05:46:51PM -0500, Wen Xiong wrote:
> +static ssize_t jsm_driver_version_show(struct device_driver *ddp, char *buf)
> +{
> + return snprintf(buf, PAGE_SIZE, "jsm_version: %s\n", JSM_VERSION);
Again, drop the "prefix:" from every sysfs file, it should not be there
(the data type is inferred by the name of the file, you do not have to
repeat it again.)
> +static ssize_t jsm_tty_state_show(struct class_device *class_dev, char *buf)
> +{
> + struct jsm_channel *ch;
> +
> + if (class_dev) {
> + ch = class_get_devdata(class_dev);
> + if ( ch && (ch->ch_bd->state == BOARD_READY))
> + return snprintf(buf, PAGE_SIZE, "%s\n",
> ch->ch_open_count ? "Open" : "Closed");
> + }
> +
> + return -EINVAL;
> +}
> +static CLASS_DEVICE_ATTR(state, S_IRUGO, jsm_tty_state_show, NULL);
Who needs to know if a port is open or not?
> +static ssize_t jsm_tty_baud_show(struct class_device *class_dev, char *buf)
> +{
> + struct jsm_channel *ch;
> +
> + if (class_dev) {
> + ch = class_get_devdata(class_dev);
> + if ( ch && (ch->ch_bd->state == BOARD_READY))
> + return snprintf(buf, PAGE_SIZE, "%d\n", ch->ch_old_baud);
> + }
> +
> + return -EINVAL;
> +}
> +static CLASS_DEVICE_ATTR(baud, S_IRUGO, jsm_tty_baud_show, NULL);
No, please delete these, and the other sysfs files that duplicate the
same info that you can get by using the standard Linux termios calls.
There is no need for them here.
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 6/7] drivers/serial/jsm: new serial device driver
On Mon, Mar 07, 2005 at 05:48:56PM -0500, Wen Xiong wrote: > Since some tools in Digi company need these new ioctls to access device > driver. I still keep these new ioctls. What tools? What are they used for? Why do they need them? Why can't they just use the sysfs files? As the driver isn't in the kernel tree, there should not be any users expecting these ioctls to be around, right? 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: Linux 2.6.11-ac1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/08/2005 03:49 PM, Chris Wright wrote: > * Clemens Schwaighofer ([EMAIL PROTECTED]) wrote: > >>>2.6.11-ac1 >>>oFix jbd race in ext3(Stephen Tweedie) >> >>will that patch actually appear in 2.6.11.2? At least it looks like a >>candidate for me ... > > > Yes, we are intending to pick up bits from -ac (you might have missed > that in another thread). Probably. I am sorry :) I sort of got lost in the tons of RFD, etc threads :) - -- [ Clemens Schwaighofer -=:~ ] [ TBWA\ && TEQUILA\ Japan IT Group ] [6-17-2 Ginza Chuo-ku, Tokyo 104-0061, JAPAN ] [ Tel: +81-(0)3-3545-7703Fax: +81-(0)3-3545-7343 ] [ http://www.tequila.co.jphttp://www.tbwajapan.co.jp ] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCLUunjBz/yQjBxz8RArh2AJ4oMATN/P+9TPtFEDrGQhu2iox+MQCfZobG kc+hXDhfKyHhGK7UF6dKw2I= =CVCH -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11-ac1
* Clemens Schwaighofer ([EMAIL PROTECTED]) wrote: > --On Monday, March 07, 2005 09:34:22 PM + Alan Cox > <[EMAIL PROTECTED]> wrote: > > >For a couple of reasons I've not yet merged Greg's 2.6.11.1 yet but this > >diff should actually apply to either right now. > > > >2.6.11-ac1 > >oFix jbd race in ext3(Stephen Tweedie) > > will that patch actually appear in 2.6.11.2? At least it looks like a > candidate for me ... Yes, we are intending to pick up bits from -ac (you might have missed that in another thread). thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [request for inclusion] Realtime LSM
On Mon, Mar 07, 2005 at 10:45:05PM -0800, Chris Wright wrote:
> * Matt Mackall ([EMAIL PROTECTED]) wrote:
> > On Mon, Mar 07, 2005 at 07:50:20PM -0800, Andrew Morton wrote:
> > > Consider this a prod in the direction of those who were pushing
> > > alternatives ;)
> >
> > I think Chris Wright's last rlimit patch is more sensible and ready to
> > go. And I think I may have even convinced Ingo on this point before
> > the conversation died last time around. So here's that patch again,
> > updated to 2.6.11. Compiles cleanly. Chris, please add a signed-off-by.
>
> Only very minor nits below.
>
> > Add a pair of rlimits for allowing non-root tasks to raise nice and rt
> > priorities. Defaults to traditional behavior. Originally written by
> > Chris Wright.
> >
> > Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
> >
> > Index: rlimits/include/asm-generic/resource.h
> > ===
> > --- rlimits.orig/include/asm-generic/resource.h 2005-03-02
> > 18:30:27.0 -0800
> > +++ rlimits/include/asm-generic/resource.h 2005-03-07 20:21:04.0
> > -0800
> > @@ -20,8 +20,10 @@
> > #define RLIMIT_LOCKS 10 /* maximum file locks held */
> > #define RLIMIT_SIGPENDING 11 /* max number of pending signals */
> > #define RLIMIT_MSGQUEUE12 /* maximum bytes in POSIX
> > mqueues */
> > -
> > -#define RLIM_NLIMITS 13
> > +#define RLIMIT_NICE13 /* max nice prio allowed to
> > raise to
> > + 0-39 for nice level 19 .. -20 */
> > +#define RLIMIT_RTPRIO 14 /* maximum realtime priority */
>
> Needs one more tab to keep in line with rest.
That's just tab damage from the patch.
> > +#define RLIM_NLIMITS 15
>
>
> > #endif
> >
> > /*
> > @@ -53,6 +55,8 @@
> > [RLIMIT_LOCKS] = { RLIM_INFINITY, RLIM_INFINITY }, \
> > [RLIMIT_SIGPENDING] = { MAX_SIGPENDING, MAX_SIGPENDING }, \
> > [RLIMIT_MSGQUEUE] = { MQ_BYTES_MAX, MQ_BYTES_MAX }, \
> > + [RLIMIT_NICE] = { 0, 0 }, \
> > + [RLIMIT_RTPRIO] = { 0, 0 }, \
>
> Might as well fit in with rest of file on these too.
>
> Also, missed alpha, sparc, sparc64, and mips. BTW, where's that last
> cleanup from Ingo to consolidate these? Ah, just saw these are inflight
> to Linus' tree, nevermind.
Uhh, is that not what I've already done above?
> -#define RLIM_NLIMITS 13
> +#define RLIMIT_NICE 13 /* max nice prio allowed to raise to
> +0-39 for nice level 19 .. -20 */
> +#define RLIMIT_RTPRIO14 /* maximum realtime priority */
Heh.
Anyway...
--
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: NFS client bug in 2.6.8-2.6.11
ty den 08.03.2005 Klokka 07:38 (+0100) skreiv Bernardo Innocenti: > Trond Myklebust wrote: > > ty den 08.03.2005 Klokka 05:53 (+0100) skreiv Bernardo Innocenti: > > > >>Appears to be a client bug. > > > > Why? > > Two clients started showing the problem after > being upgraded from FC2 to FC3, while the server > remained unchanged. Can you produce tcpdumps to back that up? Neil's problem appeared rather to be server-related. Neither of us could reproduce his problem when the server was exporting an XFS partition. The other thing to try is to turn off subtree checking on the server. Cheers, Trond -- Trond Myklebust <[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] [request for inclusion] Realtime LSM
* Matt Mackall ([EMAIL PROTECTED]) wrote:
> On Mon, Mar 07, 2005 at 07:50:20PM -0800, Andrew Morton wrote:
> > Consider this a prod in the direction of those who were pushing
> > alternatives ;)
>
> I think Chris Wright's last rlimit patch is more sensible and ready to
> go. And I think I may have even convinced Ingo on this point before
> the conversation died last time around. So here's that patch again,
> updated to 2.6.11. Compiles cleanly. Chris, please add a signed-off-by.
Only very minor nits below.
> Add a pair of rlimits for allowing non-root tasks to raise nice and rt
> priorities. Defaults to traditional behavior. Originally written by
> Chris Wright.
>
> Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
>
> Index: rlimits/include/asm-generic/resource.h
> ===
> --- rlimits.orig/include/asm-generic/resource.h 2005-03-02
> 18:30:27.0 -0800
> +++ rlimits/include/asm-generic/resource.h2005-03-07 20:21:04.0
> -0800
> @@ -20,8 +20,10 @@
> #define RLIMIT_LOCKS 10 /* maximum file locks held */
> #define RLIMIT_SIGPENDING11 /* max number of pending signals */
> #define RLIMIT_MSGQUEUE 12 /* maximum bytes in POSIX
> mqueues */
> -
> -#define RLIM_NLIMITS 13
> +#define RLIMIT_NICE 13 /* max nice prio allowed to raise to
> +0-39 for nice level 19 .. -20 */
> +#define RLIMIT_RTPRIO14 /* maximum realtime priority */
Needs one more tab to keep in line with rest.
> +#define RLIM_NLIMITS 15
> #endif
>
> /*
> @@ -53,6 +55,8 @@
> [RLIMIT_LOCKS] = { RLIM_INFINITY, RLIM_INFINITY }, \
> [RLIMIT_SIGPENDING] = { MAX_SIGPENDING, MAX_SIGPENDING }, \
> [RLIMIT_MSGQUEUE] = { MQ_BYTES_MAX, MQ_BYTES_MAX }, \
> + [RLIMIT_NICE] = { 0, 0 }, \
> + [RLIMIT_RTPRIO] = { 0, 0 }, \
Might as well fit in with rest of file on these too.
Also, missed alpha, sparc, sparc64, and mips. BTW, where's that last
cleanup from Ingo to consolidate these? Ah, just saw these are inflight
to Linus' tree, nevermind.
Below fixes those nits, and rediffs against that inflight cleanup so it
should apply cleanly on top of that.
thanks,
-chris
--
Add a pair of rlimits for allowing non-root tasks to raise nice and rt
priorities. Defaults to traditional behavior. Originally written by
Chris Wright.
Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
= include/asm-generic/resource.h 1.1 vs edited =
--- 1.1/include/asm-generic/resource.h 2005-01-20 21:00:51 -08:00
+++ edited/include/asm-generic/resource.h 2005-03-07 21:15:00 -08:00
@@ -41,8 +41,10 @@
#define RLIMIT_LOCKS 10 /* maximum file locks held */
#define RLIMIT_SIGPENDING 11 /* max number of pending signals */
#define RLIMIT_MSGQUEUE12 /* maximum bytes in POSIX
mqueues */
-
-#define RLIM_NLIMITS 13
+#define RLIMIT_NICE13 /* max nice prio allowed to raise to
+ 0-39 for nice level 19 .. -20 */
+#define RLIMIT_RTPRIO 14 /* maximum realtime priority */
+#define RLIM_NLIMITS 15
/*
* SuS says limits have to be unsigned.
@@ -81,6 +83,8 @@
[RLIMIT_LOCKS] = { RLIM_INFINITY, RLIM_INFINITY }, \
[RLIMIT_SIGPENDING] = { MAX_SIGPENDING, MAX_SIGPENDING }, \
[RLIMIT_MSGQUEUE] = { MQ_BYTES_MAX, MQ_BYTES_MAX }, \
+ [RLIMIT_NICE] = { 0, 0 }, \
+ [RLIMIT_RTPRIO] = { 0, 0 }, \
}
#endif /* __KERNEL__ */
= include/linux/sched.h 1.279 vs edited =
--- 1.279/include/linux/sched.h 2005-03-04 22:41:13 -08:00
+++ edited/include/linux/sched.h2005-03-07 21:43:39 -08:00
@@ -792,6 +792,7 @@ extern void sched_idle_next(void);
extern void set_user_nice(task_t *p, long nice);
extern int task_prio(const task_t *p);
extern int task_nice(const task_t *p);
+extern int can_nice(const task_t *p, const int nice);
extern int task_curr(const task_t *p);
extern int idle_cpu(int cpu);
extern int sched_setscheduler(struct task_struct *, int, struct sched_param *);
= kernel/sched.c 1.394 vs edited =
--- 1.394/kernel/sched.c2005-03-04 22:41:14 -08:00
+++ edited/kernel/sched.c 2005-03-07 21:43:39 -08:00
@@ -3278,6 +3278,19 @@ out_unlock:
EXPORT_SYMBOL(set_user_nice);
+/*
+ * can_nice - check if a task can reduce its nice value
+ * @p: task
+ * @nice: nice value
+ */
+int can_nice(const task_t *p, const int nice)
+{
+ /* convert nice value [19,-20] to rlimit style value [0,39] */
+ int nice_rlim = 19 - nice;
+ return (nice_rlim <= p->signal->rlim[RLIMIT_NICE].rlim_cur ||
+ capable(CAP_SYS_NICE));
+}
+
#ifdef
Re: [PATCH] [request for inclusion] Realtime LSM
* Chris Wright <[EMAIL PROTECTED]> wrote: > > Yes. In kernel "damage control" is an optional extra not a necessity > > with this solution. Not so sure about with the RT LSB solution though. > > This has one advantage over RT LSM in that area, which is it places an > upper bound on the priority (in control of the admin). So it's > possible to save some space for damage control in the top few prio > slots. it's not just purely for damage control - there have been requests of being able to 'partition' the RT priorities space between applications. (It's an afterthought but nice nevertheless.) Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [request for inclusion] Realtime LSM
* Peter Williams ([EMAIL PROTECTED]) wrote:
> But the patch you describe still seems a little loose to me in that it
> doesn't control both which users AND which programs they can run.
> Although I suppose that can be managed by suitable setting of file
> permissions?
rlimits are typically handled per user or per group. this is set during
login and the limits apply to the users session. none of the solutions
limit which programs the user can run, however strictly group based priv
granting can reduce the number of processes with the privs (using setgid
programs).
> Also I presume that root privileges are needed to set the rlimits which
> means that the program has to be setuid root or run from a setuid root
> wrapper. In the first of these cases the program will be running for a
> (hopefully) short while with way more privilege than it needs. This is
> why I'm attracted to mechanisms that allow programs to be given a subset
> of root's privileges and only for specified users.
typically this is handled via pam during login, so yes, root (or more
specifically CAP_SYS_RESOURCE) is required, but need not be in any
wrapper. limiting the allowed programs a user/role/domain/context/etc
can run is the goal of other type of security restrictions (such as
SELinux).
> I would be nice to have a solution to this particular problem that fits
> in with such a generalized "granular" privilege mechanism (when/if such
> a mechanism becomes available in the future) rather than a quirky fix
> that is specific to this problem and doesn't generalize well to similar
> problems when they arise in the future. However, I agree with your
> opinion that granting CAP_SYS_NICE is dangerous without some limit on
> the priority levels is dangerous and think that a generalized "granular"
> privilege mechanism would need to include such restrictions.
>
> >The patch does not attempt to do any
> >"damage control" of abuse caused by RT tasks, and is hence much simpler
> >than my patch or Con's SCHED_ISO patch. ("damage control" could be done
> >from userspace anyway)
>
> Yes. In kernel "damage control" is an optional extra not a necessity
> with this solution. Not so sure about with the RT LSB solution though.
This has one advantage over RT LSM in that area, which is it places an
upper bound on the priority (in control of the admin). So it's possible
to save some space for damage control in the top few prio slots.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.6.10 - direct-io async short read bug
Sébastien Dugué <[EMAIL PROTECTED]> wrote:
>
> When reading a file in async mode (using kernel AIO), and the file
> size is lower than the requested size (short read), the direct IO
> layer reports an incorrect number of bytes read (transferred).
>
> That case is handled for the sync path in 'direct_io_worker'
> (fs/direct-io.c) where a check is made against the file size.
>
> This patch does the same thing for the async path.
It looks sane to me. It needs a couple of fixes, below. One of them is
horrid and isn't really a fix at all, but it improves things.
Would Suparna and Badari have time to check the logic of these two patches
please?
- i_size is 64 bit, ssize_t is 32-bit
- whitespace tweaks.
- i_size_read() in interrupt context is a no-no.
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/fs/direct-io.c | 14 +++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff -puN fs/direct-io.c~direct-io-async-short-read-fix-fix fs/direct-io.c
--- 25/fs/direct-io.c~direct-io-async-short-read-fix-fix2005-03-07
22:28:52.0 -0800
+++ 25-akpm/fs/direct-io.c 2005-03-07 22:37:18.0 -0800
@@ -231,7 +231,7 @@ static void finished_one_bio(struct dio
if (dio->bio_count == 1) {
if (dio->is_async) {
ssize_t transferred;
- ssize_t i_size;
+ loff_t i_size;
loff_t offset;
/*
@@ -241,11 +241,19 @@ static void finished_one_bio(struct dio
spin_unlock_irqrestore(>bio_lock, flags);
/* Check for short read case */
+
+ /*
+* We should use i_size_read() here. But we're called
+* in interrupt context. If this CPU happened to be
+* in the middle of i_size_write() when the interrupt
+* occurred, i_size_read() would lock up.
+* So we just risk getting a wrong result instead :(
+*/
+ i_size = dio->inode->i_size;
transferred = dio->result;
- i_size = i_size_read (dio->inode);
offset = dio->iocb->ki_pos;
- if ((dio->rw == READ) && ((offset + transferred) >
i_size))
+ if ((dio->rw == READ) && (offset+transferred > i_size))
transferred = i_size - offset;
dio_complete(dio, offset, transferred);
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: NFS client bug in 2.6.8-2.6.11
Trond Myklebust wrote: ty den 08.03.2005 Klokka 05:53 (+0100) skreiv Bernardo Innocenti: Appears to be a client bug. Why? Two clients started showing the problem after being upgraded from FC2 to FC3, while the server remained unchanged. I also can't reproduce the problem on an older client running 2.4.21. I'll test with 2.6.7 as soon as I can reboot the client I'm using right now. -- // Bernardo Innocenti - Develer S.r.l., R dept. \X/ http://www.develer.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] unified device list allocator
On Tue, Mar 08, 2005 at 06:31:27AM +, Christoph Hellwig wrote: > On Mon, Mar 07, 2005 at 10:11:55PM -0800, Matt Mackall wrote: > > > - when called with the major argument as 0 it returns an unused major > > > number > > >from the top of the old 255 entries major list. This should be > > > replaced > > >by a real dynamic dev_t allocator, similar to alloc_chrdev_region. > > > > Umm, this replaces alloc_chrdev_region too. If instead you mean "let's > > migrate all the users to a sensible interface", I agree. And that > > means killing alloc_chrdev_region too. (baseminor makes no sense for > > dynamic allocation - you either know your prefered major and minor or > > you know neither.) > > The thing is this blkdev_register useage should be replace by an API > like alloc_chrdev_region. I don't particularly care about the actual > implementation. Ok, I can work on a follow-up that does that. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] unified device list allocator
On Mon, Mar 07, 2005 at 10:11:55PM -0800, Matt Mackall wrote: > > - when called with the major argument as 0 it returns an unused major > > number > >from the top of the old 255 entries major list. This should be replaced > >by a real dynamic dev_t allocator, similar to alloc_chrdev_region. > > Umm, this replaces alloc_chrdev_region too. If instead you mean "let's > migrate all the users to a sensible interface", I agree. And that > means killing alloc_chrdev_region too. (baseminor makes no sense for > dynamic allocation - you either know your prefered major and minor or > you know neither.) The thing is this blkdev_register useage should be replace by an API like alloc_chrdev_region. I don't particularly care about the actual implementation. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [request for inclusion] Realtime LSM
On Mon, Mar 07, 2005 at 11:30:57PM -0600, Jack O'Quin wrote: > Andrew Morton <[EMAIL PROTECTED]> writes: > > > Matt Mackall <[EMAIL PROTECTED]> wrote: > >> > >> I think Chris Wright's last rlimit patch is more sensible and ready to > >> go. > > > > I must say that I like rlimits - very straightforward, although somewhat > > awkward to use from userspace due to shortsighted shell design. > > > > Does anyone have serious objections to this approach? > > 1. is likely to introduce multiuser system security holes like the one > created recently when the mlock() rlimits bug was fixed (DoS attacks) I wouldn't say "likely". But anything's possible, so I wouldn't rule it out entirely. > 2. requires updates to all the shells Requires update to the PAM distro for our purposes. > 3. forces Windows and Mac musicians to learn and understand PAM Or for the distro (ubuntu or whatever) to catch up. The alternative is for the user to compile their own kernel module and mess with its arcane interface. > 4. is undocumented and has never been tested in any real music studios Well you'll have a bit to test it before it goes to Linus. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: Slowdown on 3000 socket-machines tracked down
Nick Piggin wrote: Ben Greear wrote: Nick Piggin wrote: Ben Greear wrote: In that case, writing the network only test would help to confirm the problem is not a networking one - so not useless by any means. It's not trivial to write something like this :) I'll be using something I already have. If I can't reproduce the problem, then perhaps it is due to sendfile and someone can write a customized test. The main reason I offered is because people are ignoring the bug report for the most part and asking for a test case. I may be able to offer an independent verification of the problem which might convince someone to write up a dedicated test case... OK, no that sounds good, please do make the test case. I have actually been following up with Christian regarding the disk IO / memory management side of things but the thread has gone offline for some reason :\ Initial test setup: two machines, running connections between them. Mostly asymetric (about 50Mbps in one direction, GigE in the other). Each connection is trying some random rate between 128kbps and 3Mbps in one direction, and 1kbps in the other direction. Sending machine is dual 3.0Ghz xeons, 1MB cache, HT, and emt64 (running 32-bit kernel & user space though). 1GB of RAM Receiving machine is dual 2.8Ghz xeons, 512 MB cache, HT, 32-bit. 2GB of RAM (but only 850Mbps of low memory of course...saw the thing OOM kill me with 1GB of free high memory :( ) Zero latency: 2000 TCP connections: When I first start, I see errors indicating I'm out of low memory..but it quickly recovers. Probably because my program takes a small bit of time before it starts reading the sockets. 986Mbps of ethernet traffic (counting all ethernet headers) 3000 TCP connections: Same memory issue 986Mbps of ethernet traffic, about 82kpps 4000 TCP connections: Had to drop max_backlog to 5000 from 1 to keep the machine from going OOM and killing my traffic generator (on the receiving side). 986Mbps of ethernet traffic I will work on some numbers with latency tomorrow (had to stop and re-write some of my code to better handle managing the 8000 endpoints that 4000 connections requires!) I think we can assume that the problem is either related to latency, or sendfile, since 4000 connections with no latency rocks along just fine... Ben -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.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: [Ext2-devel] Re: [RFC] ext3/jbd race: releasing in-use journal_heads
Just as an idea of what I meant (dug up an old WIP patch):
--- radix-tree.c2004-04-01 10:32:15.384556136 +0530
+++ radix-tree.c.end2004-04-01 11:11:07.176069944 +0530
@@ -562,7 +562,8 @@ EXPORT_SYMBOL(radix_tree_gang_lookup);
*/
static unsigned int
__lookup_tag(struct radix_tree_root *root, void **results, unsigned long index,
- unsigned int max_items, unsigned long *next_index, int tag)
+ unsigned long max_index, unsigned int max_items,
+ unsigned long *next_index, int tag)
{
unsigned int nr_found = 0;
unsigned int shift;
@@ -596,7 +597,8 @@ __lookup_tag(struct radix_tree_root *roo
if (tag_get(slot, tag, j)) {
BUG_ON(slot->slots[j] == NULL);
results[nr_found++] = slot->slots[j];
- if (nr_found == max_items)
+ if ((nr_found == max_items) ||
+ (index > max_index))
goto out;
}
}
@@ -624,12 +626,15 @@ out:
*/
unsigned int
radix_tree_gang_lookup_tag(struct radix_tree_root *root, void **results,
- unsigned long first_index, unsigned int max_items, int tag)
+ unsigned long first_index, unsigned long end_index,
+ unsigned int max_items, int tag)
{
const unsigned long max_index = radix_tree_maxindex(root->height);
unsigned long cur_index = first_index;
unsigned int ret = 0;
+ if (max_index > end_index)
+ max_index = end_index;
while (ret < max_items) {
unsigned int nr_found;
unsigned long next_index; /* Index of next search */
@@ -637,7 +642,8 @@ radix_tree_gang_lookup_tag(struct radix_
if (cur_index > max_index)
break;
nr_found = __lookup_tag(root, results + ret, cur_index,
- max_items - ret, _index, tag);
+ max_index, max_items - ret,
+ _index, tag);
ret += nr_found;
if (next_index == 0)
break;
On Tue, Mar 08, 2005 at 11:58:27AM +0530, Suparna Bhattacharya wrote:
>
> yup, looks like the same issue we hit in wait_on_page_writeback_range
> during AIO work - probably want to break out of the outer loop as well
> when this happens.
>
> From the old changelog:
> >>
> >> wait_on_page_writeback_range shouldn't wait for pages beyond the
> >> specified range. Ideally, the radix-tree-lookup could accept an
> >> end_index parameter so that it doesn't return the extra pages
> >> in the first place, but for now we just add a few extra checks
> >> to skip such pages.
> >>
>
> How hard would it be to add an end_index parameter to the radix tree
> lookup, since we seem to be hitting this in multiple places ?
>
> Regards
> Suparna
>
>
> On Mon, Mar 07, 2005 at 03:50:01PM -0800, Andrew Morton wrote:
> > "Stephen C. Tweedie" <[EMAIL PROTECTED]> wrote:
> > >
> > > In invalidate_inode_pages2_range(), what happens if we lookup a pagevec,
> > > get a bunch of pages back, but all the pages in the vec are beyond the
> > > end of the range we want?
> >
> > hmm, yes. Another one :(
> >
> > > @@ -271,12 +271,13 @@ int invalidate_inode_pages2_range(struct
> > > int was_dirty;
> > >
> > > lock_page(page);
> > > + if (page->mapping == mapping)
> > > + next = page->index + 1;
> > > if (page->mapping != mapping || page->index > end) {
> > > unlock_page(page);
> > > continue;
> > > }
> > > wait_on_page_writeback(page);
> > > - next = page->index + 1;
> > > if (next == 0)
> > > wrapped = 1;
> > > while (page_mapped(page)) {
> >
> > truncate_inode_pages_range() seems to dtrt here. Can we do it in the same
> > manner in invalidate_inode_pages2_range()?
> >
> >
> > Something like:
> >
> >
> > diff -puN mm/truncate.c~invalidate_inode_pages2_range-livelock-fix
> > mm/truncate.c
> > --- 25/mm/truncate.c~invalidate_inode_pages2_range-livelock-fix Mon Mar
> > 7 15:47:25 2005
> > +++ 25-akpm/mm/truncate.c Mon Mar 7 15:49:09 2005
> > @@ -305,15 +305,22 @@ int invalidate_inode_pages2_range(struct
> > min(end - next, (pgoff_t)PAGEVEC_SIZE - 1) + 1)) {
> > for (i = 0; !ret && i < pagevec_count(); i++) {
> > struct page *page = pvec.pages[i];
> > + pgoff_t page_index;
> > int was_dirty;
> >
> > lock_page(page);
> > -
Re: [PATCH] [request for inclusion] Realtime LSM
Ingo Molnar wrote:
* Peter Williams <[EMAIL PROTECTED]> wrote:
I don't object to rlimits per se and I think that they are useful but
not as a sole solution to this problem. Being able to give a task
preferential treatment is a permissions issue and should be solved as
one.
Having RT cpu usage limits on tasks is a useful tool to have when
granting normal users the privilege of running tasks as RT tasks so
that you can limit the damage that they can do BUT the presence of a
limit on a task is not a very good criterion for granting that
privilege.
i think you are talking about my rlimit patch (the 'RT CPU limit' patch)
- but that one is not in discussion here.
what is being discussed currently is the other rlimit patch (from Chris
Wright and Matt Mackall) which implements a simple rlimit ceiling for
the RT (and nice) priorities a task can set. The rlimit defaults to 0,
meaning no change in behavior by default. A value of 50 means RT
priority levels 1-50 are allowed. A value of 100 means all 99 privilege
levels from 1 to 99 are allowed. CAP_SYS_NICE is blanket permission.
It's all pretty finegrained and and it's a quite straightforward
extension of what we have today.
OK. My misunderstanding.
But the patch you describe still seems a little loose to me in that it
doesn't control both which users AND which programs they can run.
Although I suppose that can be managed by suitable setting of file
permissions?
Also I presume that root privileges are needed to set the rlimits which
means that the program has to be setuid root or run from a setuid root
wrapper. In the first of these cases the program will be running for a
(hopefully) short while with way more privilege than it needs. This is
why I'm attracted to mechanisms that allow programs to be given a subset
of root's privileges and only for specified users.
I would be nice to have a solution to this particular problem that fits
in with such a generalized "granular" privilege mechanism (when/if such
a mechanism becomes available in the future) rather than a quirky fix
that is specific to this problem and doesn't generalize well to similar
problems when they arise in the future. However, I agree with your
opinion that granting CAP_SYS_NICE is dangerous without some limit on
the priority levels is dangerous and think that a generalized "granular"
privilege mechanism would need to include such restrictions.
The patch does not attempt to do any
"damage control" of abuse caused by RT tasks, and is hence much simpler
than my patch or Con's SCHED_ISO patch. ("damage control" could be done
from userspace anyway)
Yes. In kernel "damage control" is an optional extra not a necessity
with this solution. Not so sure about with the RT LSB solution though.
Peter
--
Peter Williams [EMAIL PROTECTED]
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] [request for inclusion] Realtime LSM
On Tue, Mar 08, 2005 at 04:40:02PM +1100, Peter Williams wrote: > The granting of the ability to switch to and from RT mode should require > a means to specify which users it applies to and also which programs it > applies to. The RT rlimits mechanism doesn't meet these criteria. a) rlimits are per-process b) rlimits are typically administered per-user c) any user can trivially gain any privilege of any process they own so in some sense per-process limits are meaningless So rlimits are in fact as granular as can be, both in theory and in practice. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ext2-devel] Re: [RFC] ext3/jbd race: releasing in-use journal_heads
yup, looks like the same issue we hit in wait_on_page_writeback_range
during AIO work - probably want to break out of the outer loop as well
when this happens.
>From the old changelog:
>>
>> wait_on_page_writeback_range shouldn't wait for pages beyond the
>> specified range. Ideally, the radix-tree-lookup could accept an
>> end_index parameter so that it doesn't return the extra pages
>> in the first place, but for now we just add a few extra checks
>> to skip such pages.
>>
How hard would it be to add an end_index parameter to the radix tree
lookup, since we seem to be hitting this in multiple places ?
Regards
Suparna
On Mon, Mar 07, 2005 at 03:50:01PM -0800, Andrew Morton wrote:
> "Stephen C. Tweedie" <[EMAIL PROTECTED]> wrote:
> >
> > In invalidate_inode_pages2_range(), what happens if we lookup a pagevec,
> > get a bunch of pages back, but all the pages in the vec are beyond the
> > end of the range we want?
>
> hmm, yes. Another one :(
>
> > @@ -271,12 +271,13 @@ int invalidate_inode_pages2_range(struct
> > int was_dirty;
> >
> > lock_page(page);
> > + if (page->mapping == mapping)
> > + next = page->index + 1;
> > if (page->mapping != mapping || page->index > end) {
> > unlock_page(page);
> > continue;
> > }
> > wait_on_page_writeback(page);
> > - next = page->index + 1;
> > if (next == 0)
> > wrapped = 1;
> > while (page_mapped(page)) {
>
> truncate_inode_pages_range() seems to dtrt here. Can we do it in the same
> manner in invalidate_inode_pages2_range()?
>
>
> Something like:
>
>
> diff -puN mm/truncate.c~invalidate_inode_pages2_range-livelock-fix
> mm/truncate.c
> --- 25/mm/truncate.c~invalidate_inode_pages2_range-livelock-fix Mon Mar
> 7 15:47:25 2005
> +++ 25-akpm/mm/truncate.c Mon Mar 7 15:49:09 2005
> @@ -305,15 +305,22 @@ int invalidate_inode_pages2_range(struct
> min(end - next, (pgoff_t)PAGEVEC_SIZE - 1) + 1)) {
> for (i = 0; !ret && i < pagevec_count(); i++) {
> struct page *page = pvec.pages[i];
> + pgoff_t page_index;
> int was_dirty;
>
> lock_page(page);
> - if (page->mapping != mapping || page->index > end) {
> + page_index = page->index;
> + if (page_index > end) {
> + next = page_index;
> + unlock_page(page);
> + break;
> + }
> + if (page->mapping != mapping) {
> unlock_page(page);
> continue;
> }
> wait_on_page_writeback(page);
> - next = page->index + 1;
> + next = page_index + 1;
> if (next == 0)
> wrapped = 1;
> while (page_mapped(page)) {
> @@ -323,7 +330,7 @@ int invalidate_inode_pages2_range(struct
>*/
> unmap_mapping_range(mapping,
> page->index << PAGE_CACHE_SHIFT,
> - (end - page->index + 1)
> + (end - page_index + 1)
> << PAGE_CACHE_SHIFT,
> 0);
> did_range_unmap = 1;
> @@ -332,7 +339,7 @@ int invalidate_inode_pages2_range(struct
>* Just zap this page
>*/
> unmap_mapping_range(mapping,
> - page->index << PAGE_CACHE_SHIFT,
> + page_index << PAGE_CACHE_SHIFT,
> PAGE_CACHE_SIZE, 0);
> }
> }
> _
>
>
>
> ---
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595_id=14396=click
> ___
> Ext2-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/ext2-devel
--
Suparna Bhattacharya ([EMAIL PROTECTED])
Linux Technology Center
IBM Software Lab, India
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Re: [announce 7/7] fbsplash - documentation
On Tue, 8 Mar 2005 04:18:07 +0100, Arnd Bergmann <[EMAIL PROTECTED]> wrote: > On Dinsdag 08 März 2005 03:17, Michal Januszewski wrote: > > > +It's possible to set path to the splash helper by writing it to > > +/proc/sys/kernel/fbsplash. > > It should probably just use its own hotplug agent instead of calling > the helper directly. Framebuffer is already generating hotplug add/remove messages. HOTPLUG_TIME='Mon Feb 28 02:15:25 EST 2005' PHYSDEVPATH=/devices/pci:00/:00:01.0/:01:00.0 SUBSYSTEM=graphics HOTPLUG_ARGS= DEVPATH=/class/graphics/fb0 HOTPLUG_TYPE=graphics ACTION=add PHYSDEVDRIVER=radeonfb DEBUG=yes PHYSDEVBUS=pci SEQNUM=537 This event can be caught in early userspace. The helper app will need to live on initramfs/initrd and be small. Statically link it to klibc. You can use the modular fb patch that has been recently posted (just about to go in -mm) to make hotplug fbdev debugging much simpler. Alternatively you might want to look at how request_firmware works. You could easily load the picture as if it were firmware. I'm looking at modifying request_firmware to be more general right now. A direct call to call_usermodehelper() requires you to build a path and app name into the driver. -- Jon Smirl [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2/2 Prezeroing large blocks of pages during allocation Version 4
Hi, Mel Gorman wrote: +#define BITS_PER_ALLOC_TYPE 5 #define ALLOC_KERNNORCLM 0 #define ALLOC_KERNRCLM 1 #define ALLOC_USERRCLM 2 #define ALLOC_FALLBACK 3 +#define ALLOC_USERZERO 4 +#define ALLOC_KERNZERO 5 Now, 5bits per MAX_ORDER pages. I think it is simpler to use "char[]" for representing type of memory alloc type than bitmap. Thanks -- Kame <[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] unified device list allocator
On Tue, Mar 08, 2005 at 05:56:27AM +, Christoph Hellwig wrote: > On Mon, Mar 07, 2005 at 09:50:35PM -0800, Andrew Morton wrote: > > > register_blkdev only happens at module_init time (and in fact should go > > > away completely, so I'm not happy wit hthe surgey to keep it barely alive > > > at all) > > > > Is anyone working on that? > > I had a patch from a long time ago that just killed it, but that one isn't > useable for current users anymore. > > There's two things it's doing currently: > > - when called with the major argument as 0 it returns an unused major number >from the top of the old 255 entries major list. This should be replaced >by a real dynamic dev_t allocator, similar to alloc_chrdev_region. Umm, this replaces alloc_chrdev_region too. If instead you mean "let's migrate all the users to a sensible interface", I agree. And that means killing alloc_chrdev_region too. (baseminor makes no sense for dynamic allocation - you either know your prefered major and minor or you know neither.) > - /proc/devices. This interface has traditionally been used by things >like installer but these day's it's totally bogus as the one major, one >driver limitation got lifeted. We'll probably have to deprecate it and >kill it in half a year or a similar timespan. I think killing /proc/devices has to wait until after devfs removal, when everyone is more or less comfortable with its alternatives. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Atheros wi-fi card drivers (?)
> A different one than the one that's supported by OpenBSD's reverse-engineered > HAL? I guess so :-) -- Mateusz Berezecki <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11-ac1
--On Monday, March 07, 2005 09:34:22 PM + Alan Cox <[EMAIL PROTECTED]> wrote: For a couple of reasons I've not yet merged Greg's 2.6.11.1 yet but this diff should actually apply to either right now. 2.6.11-ac1 o Fix jbd race in ext3(Stephen Tweedie) will that patch actually appear in 2.6.11.2? At least it looks like a candidate for me ... [ Clemens Schwaighofer -=:~ ] [ TBWA\ && TEQUILA\ Japan IT Group ] [6-17-2 Ginza Chuo-ku, Tokyo 104-0061, JAPAN ] [ Tel: +81-(0)3-3545-7703Fax: +81-(0)3-3545-7343 ] [ http://www.tequila.co.jphttp://www.tbwajapan.co.jp ] pgpzmcmZz0gRq.pgp Description: PGP signature
Re: [PATCH] unified device list allocator
On Mon, Mar 07, 2005 at 09:33:02PM -0800, Andrew Morton wrote:
> Matt Mackall <[EMAIL PROTECTED]> wrote:
> >
> > + /* search for insertion point in reverse for dynamic allocation */
> > + list_for_each_prev(l, list) {
>
> hrmph. Any time we do anything in O(n) time, some smarty comes along with
> a workload which blows us out of the water. Although it's hard to think of
> any register_blkdev()-intensive workloads.
>
> It's not possible to do this with prio-trees?
I thought about using rbtrees. But I decided it was overkill. Beyond
the 4k limit of the current proc code, currently that's limited to
~256 entries per block/char and will be limited to about ~1024 each
for the foreseeable future. It's only walked on driver init/exit and
when catting said proc file (where O(n) is unavoidable). In other
words, worst case we're talking less than a millisecond at
boot/shutdown.
--
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [request for inclusion] Realtime LSM
* Peter Williams ([EMAIL PROTECTED]) wrote: > Andrew Morton wrote: > >Matt Mackall <[EMAIL PROTECTED]> wrote: > > > >>I think Chris Wright's last rlimit patch is more sensible and ready to > >>go. > > > > > >I must say that I like rlimits - very straightforward, although somewhat > >awkward to use from userspace due to shortsighted shell design. > > > >Does anyone have serious objections to this approach? > > I don't object to rlimits per se and I think that they are useful but > not as a sole solution to this problem. Being able to give a task > preferential treatment is a permissions issue and should be solved as one. > > Having RT cpu usage limits on tasks is a useful tool to have when > granting normal users the privilege of running tasks as RT tasks so that > you can limit the damage that they can do BUT the presence of a limit on > a task is not a very good criterion for granting that privilege. > > The granting of the ability to switch to and from RT mode should require > a means to specify which users it applies to and also which programs it > applies to. The RT rlimits mechanism doesn't meet these criteria. > > In summary, IMHO you should put them both in but modify the RT rlimits > patch so that it plays no part in the decision as to whether the task is > allowed to run as RT or not. I'm not sure I follow you. This patch just sets the max RT priority a process can have (defaults to 0, as w/out the patch). Increasing that value is a form of permission granting, giving the process the ability to increase its RT prio if it chooses to ask for it. thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: setserial is lieing to us, how to fix?
On Tuesday 08 March 2005 00:05, Alan Curry wrote: >Gene Heskett writes the following: >>I'm on the horn with another linux user, and we have a question re >> the setserial command. Its reporting the base baud rate, but not >> the actual. We need to know the actual settings in use at the >> moment for a serial port. How can we discover this? > >stty speed -F /dev/ttyXY > Just what the doctor ordered, many thanks. >The setserial spd_* options can affect speed but they are obsolete > so you shouldn't be using them. If stty says 38400 then the > setserial spd_* is in effect. If spd_normal, then 38400 means > 38400. If spd_hi, then 38400 means 57600. If spd_vhi, then 38400 > means 115200. If spd_shi, then 38400 means 230400. If spd_warp, > then 38400 means 460800. Then there's spd_cust, which is more > weird. >- >To unsubscribe from this list: send the line "unsubscribe > linux-kernel" in the body of a message to [EMAIL PROTECTED] >More majordomo info at http://vger.kernel.org/majordomo-info.html >Please read the FAQ at http://www.tux.org/lkml/ -- 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) 99.34% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attorneys please note, additions to this message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pci_fixup_video() bogosity
On Tue, 08 Mar 2005 15:38:29 +1100, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > Hi ! > > While working on writing a VGA access arbiter for kernel & userland, > I wondered how to properly get my "initial" state at boot. For that, > I looked at how the new PCI ROM stuff does to find out who owns the > memory shadow at c, and found it quite bogus. > > >From what I see, the code is only based on looking at what bridges > have VGA forwarding enabled. It doesn't test the actual IO and Memory > enable bits of the VGA cards themselves. Let's fix it up and make it more robust. I was playing with checking IO/mem enable and forgot to finish it. > What if you have 2 cards under the same bridge ? I believe the default on x86 is to pick the one in the lowest slot number. What happens on PPC? -- Jon Smirl [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] unified device list allocator
On Mon, Mar 07, 2005 at 09:50:35PM -0800, Andrew Morton wrote: > > register_blkdev only happens at module_init time (and in fact should go > > away completely, so I'm not happy wit hthe surgey to keep it barely alive > > at all) > > Is anyone working on that? I had a patch from a long time ago that just killed it, but that one isn't useable for current users anymore. There's two things it's doing currently: - when called with the major argument as 0 it returns an unused major number from the top of the old 255 entries major list. This should be replaced by a real dynamic dev_t allocator, similar to alloc_chrdev_region. - /proc/devices. This interface has traditionally been used by things like installer but these day's it's totally bogus as the one major, one driver limitation got lifeted. We'll probably have to deprecate it and kill it in half a year or a similar timespan. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] unified device list allocator
Christoph Hellwig <[EMAIL PROTECTED]> wrote:
>
> On Mon, Mar 07, 2005 at 09:33:02PM -0800, Andrew Morton wrote:
> > Matt Mackall <[EMAIL PROTECTED]> wrote:
> > >
> > > + /* search for insertion point in reverse for dynamic allocation */
> > > +list_for_each_prev(l, list) {
> >
> > hrmph. Any time we do anything in O(n) time, some smarty comes along with
> > a workload which blows us out of the water. Although it's hard to think of
> > any register_blkdev()-intensive workloads.
> >
> > It's not possible to do this with prio-trees?
>
> Andrew, I think in this particular case you suffer of a sporadic severe
> condition of overengineeritis.
heh. I like to see our fancy data structures getting used.
> register_blkdev only happens at module_init time (and in fact should go
> away completely, so I'm not happy wit hthe surgey to keep it barely alive
> at all)
Is anyone working on that?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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) radeonfb: PLL access workaround
> > > > Please test and let me know if it works. If it's fine, then it should go > > to -mm, and eventually after a while, to a 2.6.11.x update. > > > > Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> I've tested this on my M7 chips which hung on boot with radeonfb but no fbcon on 2.6.11, and it works fine, if things need a vote for 2.6.11.x after its been in -mm for a while I'll vote for it :-) Dave. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [request for inclusion] Realtime LSM
* Peter Williams <[EMAIL PROTECTED]> wrote:
> I don't object to rlimits per se and I think that they are useful but
> not as a sole solution to this problem. Being able to give a task
> preferential treatment is a permissions issue and should be solved as
> one.
>
> Having RT cpu usage limits on tasks is a useful tool to have when
> granting normal users the privilege of running tasks as RT tasks so
> that you can limit the damage that they can do BUT the presence of a
> limit on a task is not a very good criterion for granting that
> privilege.
i think you are talking about my rlimit patch (the 'RT CPU limit' patch)
- but that one is not in discussion here.
what is being discussed currently is the other rlimit patch (from Chris
Wright and Matt Mackall) which implements a simple rlimit ceiling for
the RT (and nice) priorities a task can set. The rlimit defaults to 0,
meaning no change in behavior by default. A value of 50 means RT
priority levels 1-50 are allowed. A value of 100 means all 99 privilege
levels from 1 to 99 are allowed. CAP_SYS_NICE is blanket permission.
It's all pretty finegrained and and it's a quite straightforward
extension of what we have today. The patch does not attempt to do any
"damage control" of abuse caused by RT tasks, and is hence much simpler
than my patch or Con's SCHED_ISO patch. ("damage control" could be done
from userspace anyway)
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] resync ATI PCI idents into base kernel
On Mon, Mar 07, 2005 at 09:50:19PM +, Linux Kernel Mailing List wrote:
> ChangeSet 1.1982.132.7, 2005/03/07 13:50:19-08:00, [EMAIL PROTECTED]
>
> [PATCH] resync ATI PCI idents into base kernel
>
>
>
> pci_ids.h | 11 +++
> 1 files changed, 11 insertions(+)
>
>
> diff -Nru a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> --- a/include/linux/pci_ids.h 2005-03-07 14:17:11 -08:00
> +++ b/include/linux/pci_ids.h 2005-03-07 14:17:11 -08:00
> @@ -352,10 +352,21 @@
> #define PCI_DEVICE_ID_ATI_RS300_133 0x5831
> #define PCI_DEVICE_ID_ATI_RS300_166 0x5832
> #define PCI_DEVICE_ID_ATI_RS300_200 0x5833
> +#define PCI_DEVICE_ID_ATI_RS350_100 0x7830
> +#define PCI_DEVICE_ID_ATI_RS350_133 0x7831
> +#define PCI_DEVICE_ID_ATI_RS350_166 0x7832
> +#define PCI_DEVICE_ID_ATI_RS350_200 0x7833
> +#define PCI_DEVICE_ID_ATI_RS400_100 0x5a30
> +#define PCI_DEVICE_ID_ATI_RS400_133 0x5a31
> +#define PCI_DEVICE_ID_ATI_RS400_166 0x5a32
> +#define PCI_DEVICE_ID_ATI_RS400_200 0x5a33
> +#define PCI_DEVICE_ID_ATI_RS480 0x5950
Was there a reason you did this without using tabs, like the rest of the
file?
Again, the maintainer chain is well documented...
{sigh}
Oh, no Signed-off-by: line either :(
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] unified device list allocator
On Mon, Mar 07, 2005 at 09:33:02PM -0800, Andrew Morton wrote:
> Matt Mackall <[EMAIL PROTECTED]> wrote:
> >
> > + /* search for insertion point in reverse for dynamic allocation */
> > + list_for_each_prev(l, list) {
>
> hrmph. Any time we do anything in O(n) time, some smarty comes along with
> a workload which blows us out of the water. Although it's hard to think of
> any register_blkdev()-intensive workloads.
>
> It's not possible to do this with prio-trees?
Andrew, I think in this particular case you suffer of a sporadic severe
condition of overengineeritis.
register_blkdev only happens at module_init time (and in fact should go
away completely, so I'm not happy wit hthe surgey to keep it barely alive
at all)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] [request for inclusion] Realtime LSM
* Matt Mackall <[EMAIL PROTECTED]> wrote: > Add a pair of rlimits for allowing non-root tasks to raise nice and rt > priorities. Defaults to traditional behavior. Originally written by > Chris Wright. > > Signed-off-by: Matt Mackall <[EMAIL PROTECTED]> this too looks good to me. Acked-by: Ingo Molnar <[EMAIL PROTECTED]> (no strong feelings either way, other than rlimits feel a bit less hackish.) Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [request for inclusion] Realtime LSM
Andrew Morton wrote: Matt Mackall <[EMAIL PROTECTED]> wrote: I think Chris Wright's last rlimit patch is more sensible and ready to go. I must say that I like rlimits - very straightforward, although somewhat awkward to use from userspace due to shortsighted shell design. Does anyone have serious objections to this approach? I don't object to rlimits per se and I think that they are useful but not as a sole solution to this problem. Being able to give a task preferential treatment is a permissions issue and should be solved as one. Having RT cpu usage limits on tasks is a useful tool to have when granting normal users the privilege of running tasks as RT tasks so that you can limit the damage that they can do BUT the presence of a limit on a task is not a very good criterion for granting that privilege. The granting of the ability to switch to and from RT mode should require a means to specify which users it applies to and also which programs it applies to. The RT rlimits mechanism doesn't meet these criteria. In summary, IMHO you should put them both in but modify the RT rlimits patch so that it plays no part in the decision as to whether the task is allowed to run as RT or not. Peter -- Peter Williams [EMAIL PROTECTED] "Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Restore PWC driver
On Mon, Mar 07, 2005 at 09:26:43PM -0800, Greg KH wrote: > Ick, Alan, couldn't you have had the decency to run this through the USB > developers, and at least pinged me on it? Especially due to all of the > hate-email I have gotten over this driver in the past. > > As it is, the coding style sucks in places, and you didn't really need > to make it a new subdirectory (although due to the increased size of the > driver, it's probably better now...) > > And, there's no MAINTAINERS entry for who I need to bug about this > thing. Agree with greg on all these bits, and similar (although not as bad) for the other bits Alan sent. Alan, could you please go through the subsystem maintainer & -mm process like everyone else? A little public review can't hurt your patches either. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] unified device list allocator
Matt Mackall <[EMAIL PROTECTED]> wrote:
>
> + /* search for insertion point in reverse for dynamic allocation */
> +list_for_each_prev(l, list) {
hrmph. Any time we do anything in O(n) time, some smarty comes along with
a workload which blows us out of the water. Although it's hard to think of
any register_blkdev()-intensive workloads.
It's not possible to do this with prio-trees?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Restore PWC driver
On Mon, Mar 07, 2005 at 09:26:43PM -0800, Greg KH wrote: > So, who's going to fix up: Add: - the sparse warnings. to that list. Oh, and those sparse warnings show that this driver is now completely broken on big-endian boxes. So, who should I be bouncing the emails that I'm about to get from the angry mob of ppc users/developers that always throw large, blunt objects at me whenever I add code that breaks on their machines? Ick, ick, ick... 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: NFS client bug in 2.6.8-2.6.11
ty den 08.03.2005 Klokka 05:53 (+0100) skreiv Bernardo Innocenti: > Appears to be a client bug. Why? -- Trond Myklebust <[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] [request for inclusion] Realtime LSM
Andrew Morton <[EMAIL PROTECTED]> writes: > Matt Mackall <[EMAIL PROTECTED]> wrote: >> >> I think Chris Wright's last rlimit patch is more sensible and ready to >> go. > > I must say that I like rlimits - very straightforward, although somewhat > awkward to use from userspace due to shortsighted shell design. > > Does anyone have serious objections to this approach? 1. is likely to introduce multiuser system security holes like the one created recently when the mlock() rlimits bug was fixed (DoS attacks) 2. requires updates to all the shells 3. forces Windows and Mac musicians to learn and understand PAM 4. is undocumented and has never been tested in any real music studios -- joq - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Restore PWC driver
On Mon, Mar 07, 2005 at 09:49:40PM +, Linux Kernel Mailing List wrote: > ChangeSet 1.1982.132.4, 2005/03/07 13:49:40-08:00, [EMAIL PROTECTED] > > [PATCH] Restore PWC driver > > PWC has a new maintainer (Luc Saillard) and also the various contentious > binary hooks removed and replaced with reverse engineering work. > > Please restore it to the kernel Ick, Alan, couldn't you have had the decency to run this through the USB developers, and at least pinged me on it? Especially due to all of the hate-email I have gotten over this driver in the past. As it is, the coding style sucks in places, and you didn't really need to make it a new subdirectory (although due to the increased size of the driver, it's probably better now...) And, there's no MAINTAINERS entry for who I need to bug about this thing. Bleah. So, who's going to fix up: - the MAINTAINERS entry - the coding style - drop that unneeded changelog file - fix the module help text to point to the proper file (or put the file in the proper place.) - get rid of the c++ crud in the header file - drop the "magic" nonsense - the ioctls to work on 64bit machines ? And I found all of that in just a quick glance over the code... Double bleah. 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: [ACPI] s4bios: does anyone use it?
Hi,
>> >
>> > Is there single user of s4bios? It used to work for me 4 notebooks
>> > ago, but I never really used it.
>>
>> I don't have anymore my toshiba laptop where S4 bios was first
>> implemented.
>>
>> > I think I'm the only person that ever
>> > seen it working, but I could be wrong.
>>
>> You are indeed wrong.
>
>Okay, so we had 2 users in past but have 0 users now? :-).
I wonder how could anyone use S4BIOS in 2.6.11. S4 and S4b all came into
'enter_state'. and in acpi_sleep_init:
if (i == ACPI_STATE_S4) {
if (acpi_gbl_FACS->S4bios_f) {
sleep_states[i] = 1;
printk(" S4bios");
acpi_pm_ops.pm_disk_mode =
PM_DISK_FIRMWARE;
}
if (sleep_states[i])
acpi_pm_ops.pm_disk_mode =
PM_DISK_PLATFORM;
}
That means we actually can't set PM_DISK_FIRMWARE (always set
PM_DISK_PLATFORM). Is this intended? If no, .pm_disk_mode should be a
mask.
Thanks,
Shaohua
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] unified device list allocator
(This patch is against -mm1, which has different locking than mainline)
This patch introduces a simple allocator for tracking reservations of
block and character device ranges. After poking around, I came to the
conclusion that we can't avoid having a separate data structure for
reservations vs currently available devices so I tidied up the current
scheme. Note that everything below is about allocation/reservation of
namespace as opposed to lookup/open of existing devices and thus is
only invoked at init/exit and reading /proc/devices.
The new allocator is a simple linked list of dev_t range start and end
points. This lets us allocate regions of multiple majors (as is done
by SCSI) or just a portion of a major (as is done by several types of
character device). Dynamic allocation is handled by passing in a start
and end base address.
This unifies a lot of the code for registering block and character. It
also does away with the hash tables, which were complicating the code
and made allocating more devices than available hash table entries
difficult. As these tables are now only used at driver load, unload,
and for /proc/devices, and the number of entries is relatively
limited, the hash tables are no longer necessary.
If this is acceptable, the next steps are to add the helper functions
SCSI needs to allocate its spread of majors in > major chunks, add
fallback to the 1023-256 range for dynamic allocation of majors, add
change the proc bits to use seq_file. This will let us have dynamic
allocation of the entire address space of arbitrary numbers of
devices.
Tested on a laptop with a typical mix of static and dynamic block and
char devices, with identical allocations to the stock kernel. Save
about 3k in code and hash tables.
Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
Index: mm1/drivers/block/genhd.c
===
--- mm1.orig/drivers/block/genhd.c 2005-03-01 16:09:21.0 -0800
+++ mm1/drivers/block/genhd.c 2005-03-01 16:10:32.0 -0800
@@ -14,100 +14,46 @@
#include
#include
#include
-
-#define MAX_PROBE_HASH 255 /* random */
+#include
+#include
static struct subsystem block_subsys;
-
static DECLARE_MUTEX(block_subsys_sem);
-
-/*
- * Can be deleted altogether. Later.
- *
- */
-static struct blk_major_name {
- struct blk_major_name *next;
- int major;
- char name[16];
-} *major_names[MAX_PROBE_HASH];
-
-/* index in the above - for now: assume no multimajor ranges */
-static inline int major_to_index(int major)
-{
- return major % MAX_PROBE_HASH;
-}
+static LIST_HEAD(blkdev_names);
#ifdef CONFIG_PROC_FS
-/* get block device names in somewhat random order */
int get_blkdev_list(char *p)
{
- struct blk_major_name *n;
- int i, len;
+ int len;
len = sprintf(p, "\nBlock devices:\n");
down(_subsys_sem);
- for (i = 0; i < ARRAY_SIZE(major_names); i++) {
- for (n = major_names[i]; n; n = n->next)
- len += sprintf(p+len, "%3d %s\n",
- n->major, n->name);
- }
+ len += get_dev_list(p, _names);
up(_subsys_sem);
-
return len;
}
#endif
int register_blkdev(unsigned int major, const char *name)
{
- struct blk_major_name **n, *p;
- int index, ret = 0;
+ dev_t r;
+ int ret;
down(_subsys_sem);
- /* temporary */
- if (major == 0) {
- for (index = ARRAY_SIZE(major_names)-1; index > 0; index--) {
- if (major_names[index] == NULL)
- break;
- }
-
- if (index == 0) {
- printk("register_blkdev: failed to get major for %s\n",
- name);
- ret = -EBUSY;
- goto out;
- }
- major = index;
- ret = major;
- }
-
- p = kmalloc(sizeof(struct blk_major_name), GFP_KERNEL);
- if (p == NULL) {
- ret = -ENOMEM;
- goto out;
- }
-
- p->major = major;
- strlcpy(p->name, name, sizeof(p->name));
- p->next = NULL;
- index = major_to_index(major);
-
- for (n = _names[index]; *n; n = &(*n)->next) {
- if ((*n)->major == major)
- break;
- }
- if (!*n)
- *n = p;
- else
- ret = -EBUSY;
+ if (!major) {
+ ret = register_dev(MKDEV(1, 0), MKDEV(254, 0),
+ MKDEV(1, 0), name, _names, );
+ ret = ret ? ret : MAJOR(r);
+ } else
+ ret = register_dev(MKDEV(major, 0), MKDEV(major, 0),
+ MKDEV(1, 0), name, _names, NULL);
- if (ret < 0) {
+ if (ret == -EBUSY)
printk("register_blkdev: cannot get major %d for %s\n",
Re: [PATCH] [request for inclusion] Realtime LSM
> * Andrew Morton <[EMAIL PROTECTED]> wrote: > >> Still. It seems to be what we deserve if all that fancy stuff we have >> cannot address this very simple and very real-world problem. Ingo Molnar <[EMAIL PROTECTED]> writes: > please describe this "very simple and very real-world problem" in simple > terms. Lets make sure "problem" and "solution" didnt become detached. Linux audio users need to run large, complex low-latency desktop audio applications without granting them full root privileges. These applications require reliable SCHED_FIFO (or equivalent) scheduling, and the ability to lock process images into memory. We need to be able to drop and reacquire these privileges from time to time. We strongly prefer using the POSIX realtime interfaces. For desktop musicians this needs to be simple to administer, yet still reasonably secure. Denial of service attacks are not a serious threat in our environment, but we really don't want people turning our systems into open spam relays or creating hidden setuid root shells. Ours is *not* a timesharing multiuser environment. Multiple users may access these systems, but only one at a time. Many musicians have a Mac or Windows background, systems which grant realtime privileges to all tasks indiscriminantly. The realtime LSM allows us to grant similar privileges while maintaining better control over who gets them, a significant improvement over our competition. AFAICT, video and probably some other desktop multimedia applications have similar needs, but others should speak for them. I do know that audio is highly sensitive to realtime performance glitches. We believe that this LSM meets our needs, because hundreds of us have used it successfully for over a year. This is the last missing piece that allows us to reap the benefits of the excellent kernel latency improvements Ingo, Andrew and others have made over the last several years. -- joq - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [0/many] Acrypto - asynchronous crypto layer for linux kernel 2.6
On Mar 07, 2005, at 15:37, Evgeniy Polyakov wrote: I'm pleased to announce asynchronous crypto layer for Linux kernel 2.6. It supports following features: - multiple asynchronous crypto device queues - crypto session routing - crypto session binding - modular load balancing - crypto session batching genetically implemented by design - crypto session priority - different kinds of crypto operation(RNG, asymmetrical crypto, HMAC and any other) Did you include support for the new key/keyring infrastructure introduced a couple versions ago by David Howells? It allows userspace to create and manage various sorts of "keys" in kernelspace. If you create and register a few keytypes for various symmetric and asymmetric ciphers, you could then take advantage of its support for securely passing keys around in and out of userspace. Cheers, Kyle Moffett -BEGIN GEEK CODE BLOCK- Version: 3.12 GCM/CS/IT/U d- s++: a18 C>$ UB/L/X/*(+)>$ P+++()>$ L(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+ PGP+++ t+(+++) 5 X R? tv-(--) b(++) DI+ D+ G e->$ h!*()>++$ r !y?(-) --END GEEK CODE BLOCK-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: setserial is lieing to us, how to fix?
Gene Heskett writes the following: > >I'm on the horn with another linux user, and we have a question re the >setserial command. Its reporting the base baud rate, but not the >actual. We need to know the actual settings in use at the moment for >a serial port. How can we discover this? stty speed -F /dev/ttyXY The setserial spd_* options can affect speed but they are obsolete so you shouldn't be using them. If stty says 38400 then the setserial spd_* is in effect. If spd_normal, then 38400 means 38400. If spd_hi, then 38400 means 57600. If spd_vhi, then 38400 means 115200. If spd_shi, then 38400 means 230400. If spd_warp, then 38400 means 460800. Then there's spd_cust, which is more weird. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [announce 7/7] fbsplash - documentation
Arnd Bergmann wrote: Nothing about the init command seems really necessary. Why not just do that stuff from an /sbin/init script? I'm not a kernel hacker by any definition, but I'm pretty sure its neccasery because we want it to be done before /sbin/init is ran, AKA hide the kernel messages :) -- [Name ] :: [Matan I. Peled] [Location ] :: [Israel] [Public Key] :: [0xD6F42CA5] [Keyserver ] :: [keyserver.kjsl.com] encrypted/signed plain text preferred signature.asc Description: OpenPGP digital signature
Re: [PATCH] [request for inclusion] Realtime LSM
* Matt Mackall ([EMAIL PROTECTED]) wrote: > On Tue, Mar 08, 2005 at 04:32:50AM +, Christoph Hellwig wrote: > > On Mon, Mar 07, 2005 at 08:28:21PM -0800, Andrew Morton wrote: > > > > please describe this "very simple and very real-world problem" in simple > > > > terms. Lets make sure "problem" and "solution" didnt become detached. > > > > > > > > > > Well others can do that better than I but I'd describe it as > > > > > > - Audio apps need to meet their realtime requirements > > Add video, data acquisition, motion control, CD burning, etc.. > > > > - The way to implement that is to give them !SCHED_OTHER and mlockall > > > capabilities. > > > > > > - But they don't want to run as root. > > > > Which all fits very nicely with MEMLOCK rlimit and a tiny wrapper > > that sets !SCHED_OTHER and execs the audio app.. > > This is somewhat complicated by the fact that the existing apps are > already running and instead need promotion. Then we run into problems > lie set_rlimit doesn't want to work on other processes and issues with > sched_setparam on other threads, etc. > > Part of me wants to say, well you designed it wrong. You should have > planned a setuid launcher for the rt threads. But at the same time, > the rlimits thing seems like a reasonably clean way to give RT access > to users, and still allows for protect watchdog processes.. > > > and as I mentioned a few times if we really want to go for a magic > > uid/gid-based approach we should at least have one that's useable for > > all capabilities so it can replace the oracle hack aswell. But the > > proponents of the patch weren't iterested to invest the tiniest bit > > of work over what they submited. > > Does the mlock rlimit not already address the Oracle problem? It does, that's effectively dead code as far as I'm concerned. The mlock bit just came in a bit later. I had a patch around here to rip it out, this should be a good time to dust that off. thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] PCI bridge driver rewrite (rev 02)
On Mar 07, 2005, at 19:20, Adam Belay wrote: 6.) Open Firmware * I don't know much about it, but I believe it does do similar things to ACPI. * Hopefully it uses EISA ids, but not really sure. If not, it wouldn't be included. OpenFirmware is very similar to ACPI, except OpenFirmware interprets the FORTH programs in the firmware itself, whereas ACPI does it in the OS. The reason for the difference is that on Intel/x86 there is no compatible way to call directly into the firmware from 32-bit code. You won't find the two on the same system, and they basically provide the same services: device tree, power management, etc. Cheers, Kyle Moffett -BEGIN GEEK CODE BLOCK- Version: 3.12 GCM/CS/IT/U d- s++: a18 C>$ UB/L/X/*(+)>$ P+++()>$ L(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+ PGP+++ t+(+++) 5 X R? tv-(--) b(++) DI+ D+ G e->$ h!*()>++$ r !y?(-) --END GEEK CODE BLOCK-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
NFS client bug in 2.6.8-2.6.11
Hello, This problem was previously described by Neil Conway. All relevant information here: http://lkml.org/lkml/2005/2/10/97 I still see this very same problem on 2.6.11 vanilla and in Fedora/RawHide hernels. It has haunted me for a couple of months on several Fedora clients. Strangely, a Gentoo client isn't affected, but I couldn't investigate further. When the current directory becomes inaccessible, it remains so until I cd somewhere else and then cd back to it. Sometimes I must wait a few seconds before cd succeeds. Here's a sample session: [executing a find / in another shell to trigger the bug] beetle:/pub/linux/distro/fedora-devel# ll ls: .: No such file or directory beetle:/pub/linux/distro/fedora-devel# cd - / beetle:/# cd - bash: cd: /pub/linux/distro/fedora-devel: No such file or directory beetle:/# [...a few seconds later...] beetle:/# cd - /pub/linux/distro/fedora-devel Appears to be a client bug. The problem only happens when there's heavy filesystem activity on other filesystems (local or NFS). NFS mount options: rw,_netdev,rsize=32768,wsize=32768,hard,intr,proto=udp,addr=10.3.3.1 -- // Bernardo Innocenti - Develer S.r.l., R dept. \X/ http://www.develer.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] [request for inclusion] Realtime LSM
On Tue, Mar 08, 2005 at 04:32:50AM +, Christoph Hellwig wrote: > On Mon, Mar 07, 2005 at 08:28:21PM -0800, Andrew Morton wrote: > > > please describe this "very simple and very real-world problem" in simple > > > terms. Lets make sure "problem" and "solution" didnt become detached. > > > > > > > Well others can do that better than I but I'd describe it as > > > > - Audio apps need to meet their realtime requirements Add video, data acquisition, motion control, CD burning, etc.. > > - The way to implement that is to give them !SCHED_OTHER and mlockall > > capabilities. > > > > - But they don't want to run as root. > > Which all fits very nicely with MEMLOCK rlimit and a tiny wrapper > that sets !SCHED_OTHER and execs the audio app.. This is somewhat complicated by the fact that the existing apps are already running and instead need promotion. Then we run into problems lie set_rlimit doesn't want to work on other processes and issues with sched_setparam on other threads, etc. Part of me wants to say, well you designed it wrong. You should have planned a setuid launcher for the rt threads. But at the same time, the rlimits thing seems like a reasonably clean way to give RT access to users, and still allows for protect watchdog processes.. > and as I mentioned a few times if we really want to go for a magic > uid/gid-based approach we should at least have one that's useable for > all capabilities so it can replace the oracle hack aswell. But the > proponents of the patch weren't iterested to invest the tiniest bit > of work over what they submited. Does the mlock rlimit not already address the Oracle problem? -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] inotify for 2.6.11-mm1, updated
On Tue, 2005-03-08 at 04:40 +, Christoph Hellwig wrote: > Why do you need the classdevice? I'm really not too eager about adding > tons of new misdevices now that we can route directly to individual majors > with cdev_add & stuff. Especially when you're actually relying on class > device you should have your own one instead of relying on an onsolete > layer. We have sysfs knobs and /sys/class/misc/inotify makes sense. > Actually, you fixed that in read_write.c, just compat.c is still missing. > Looks like you forget to fix that one and didn't have a chance to compile-test > the 32bit compat layer? Yah, I just missed it. It is fixed in my tree. Thanks, Robert Love - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [request for inclusion] Realtime LSM
Matt Mackall <[EMAIL PROTECTED]> wrote: > > I think Chris Wright's last rlimit patch is more sensible and ready to > go. I must say that I like rlimits - very straightforward, although somewhat awkward to use from userspace due to shortsighted shell design. Does anyone have serious objections to this approach? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
setserial is lieing to us, how to fix?
Greetings; I'm on the horn with another linux user, and we have a question re the setserial command. Its reporting the base baud rate, but not the actual. We need to know the actual settings in use at the moment for a serial port. How can we discover this? -- 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) 99.34% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attorneys please note, additions to this message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
pci_fixup_video() bogosity
Hi ! While working on writing a VGA access arbiter for kernel & userland, I wondered how to properly get my "initial" state at boot. For that, I looked at how the new PCI ROM stuff does to find out who owns the memory shadow at c, and found it quite bogus. >From what I see, the code is only based on looking at what bridges have VGA forwarding enabled. It doesn't test the actual IO and Memory enable bits of the VGA cards themselves. What if you have 2 cards under the same bridge ? Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] inotify for 2.6.11-mm1, updated
> > this one seems totally unrelated.
>
> Eh? We did not add that. ;)
Sorry, I thought I saw a + somewhere there at the beggining of the line,
my fault.
> > Should probably use the /dev/mem major.
>
> Hrm, should we?
>
> Also, the memory class stuff is all local to mem.c. For example, I
> cannot get at /sys/class/mem. The misc. device stuff is exported.
Why do you need the classdevice? I'm really not too eager about adding
tons of new misdevices now that we can route directly to individual majors
with cdev_add & stuff. Especially when you're actually relying on class
device you should have your own one instead of relying on an onsolete
layer.
> > do you really need a spinlock of your own in every inode? Inode memory
> > usage is a quite big problem.
>
> Yah, we do. For a couple of reasons. First, by introducing our own
> lock, we never need touch i_lock, and avoid that scalability mess
> altogether. Second, and most importantly, i_lock is an outermost lock.
> We need our lock to be nestable, because we walk inode -> inotify_watch
> -> inotify_device. I've tried various rewrites to not need our own
> lock. None are pretty.
>
> I can offer to the "inode memory worries me" people that they can always
> disable CONFIG_INOTIFY.
They're bound to use distro kernels unfortunaly.. These people is anyone
doing big-scale fileserving at least.
> + if ((ret + (type == READ)) > 0) {
> + struct dentry *dentry = file->f_dentry;
> + if (type == READ)
> + fsnotify_access(dentry, dentry->d_inode,
> + dentry->d_name.name);
> + else
> + fsnotify_modify(dentry, dentry->d_inode,
> + dentry->d_name.name);
> + }
Arguments two and three are still redudant.
Actually, you fixed that in read_write.c, just compat.c is still missing.
Looks like you forget to fix that one and didn't have a chance to compile-test
the 32bit compat layer?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] [request for inclusion] Realtime LSM
On Mon, Mar 07, 2005 at 07:50:20PM -0800, Andrew Morton wrote:
>
> So I still have the rt-lsm patch floating about, saying "merge me, merge
> me!". I'm not sure that the world would end were I to do so.
>
> Consider this a prod in the direction of those who were pushing
> alternatives ;)
I think Chris Wright's last rlimit patch is more sensible and ready to
go. And I think I may have even convinced Ingo on this point before
the conversation died last time around. So here's that patch again,
updated to 2.6.11. Compiles cleanly. Chris, please add a signed-off-by.
Add a pair of rlimits for allowing non-root tasks to raise nice and rt
priorities. Defaults to traditional behavior. Originally written by
Chris Wright.
Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
Index: rlimits/include/linux/sched.h
===
--- rlimits.orig/include/linux/sched.h 2005-03-03 22:50:14.0 -0800
+++ rlimits/include/linux/sched.h 2005-03-07 20:18:30.0 -0800
@@ -791,6 +791,7 @@ extern void sched_idle_next(void);
extern void set_user_nice(task_t *p, long nice);
extern int task_prio(const task_t *p);
extern int task_nice(const task_t *p);
+extern int can_nice(const task_t *p, const int nice);
extern int task_curr(const task_t *p);
extern int idle_cpu(int cpu);
extern int sched_setscheduler(struct task_struct *, int, struct sched_param *);
Index: rlimits/kernel/sched.c
===
--- rlimits.orig/kernel/sched.c 2005-03-02 22:51:08.0 -0800
+++ rlimits/kernel/sched.c 2005-03-07 20:23:17.0 -0800
@@ -3273,6 +3273,19 @@ out_unlock:
EXPORT_SYMBOL(set_user_nice);
+/*
+ * can_nice - check if a task can reduce its nice value
+ * @p: task
+ * @nice: nice value
+ */
+int can_nice(const task_t *p, const int nice)
+{
+ /* convert nice value [19,-20] to rlimit style value [0,39] */
+ int nice_rlim = 19 - nice;
+ return (nice_rlim <= p->signal->rlim[RLIMIT_NICE].rlim_cur ||
+ capable(CAP_SYS_NICE));
+}
+
#ifdef __ARCH_WANT_SYS_NICE
/*
@@ -3292,12 +3305,8 @@ asmlinkage long sys_nice(int increment)
* We don't have to worry. Conceptually one call occurs first
* and we have a single winner.
*/
- if (increment < 0) {
- if (!capable(CAP_SYS_NICE))
- return -EPERM;
- if (increment < -40)
- increment = -40;
- }
+ if (increment < -40)
+ increment = -40;
if (increment > 40)
increment = 40;
@@ -3307,6 +3316,9 @@ asmlinkage long sys_nice(int increment)
if (nice > 19)
nice = 19;
+ if (increment < 0 && !can_nice(current, nice))
+ return -EPERM;
+
retval = security_task_setnice(current, nice);
if (retval)
return retval;
@@ -3422,6 +3434,7 @@ recheck:
return -EINVAL;
if ((policy == SCHED_FIFO || policy == SCHED_RR) &&
+ param->sched_priority > p->signal->rlim[RLIMIT_RTPRIO].rlim_cur &&
!capable(CAP_SYS_NICE))
return -EPERM;
if ((current->euid != p->euid) && (current->euid != p->uid) &&
Index: rlimits/kernel/sys.c
===
--- rlimits.orig/kernel/sys.c 2005-03-02 22:51:07.0 -0800
+++ rlimits/kernel/sys.c2005-03-07 20:18:30.0 -0800
@@ -225,7 +225,7 @@ static int set_one_prio(struct task_stru
error = -EPERM;
goto out;
}
- if (niceval < task_nice(p) && !capable(CAP_SYS_NICE)) {
+ if (niceval < task_nice(p) && !can_nice(p, niceval)) {
error = -EACCES;
goto out;
}
Index: rlimits/include/asm-generic/resource.h
===
--- rlimits.orig/include/asm-generic/resource.h 2005-03-02 18:30:27.0
-0800
+++ rlimits/include/asm-generic/resource.h 2005-03-07 20:21:04.0
-0800
@@ -20,8 +20,10 @@
#define RLIMIT_LOCKS 10 /* maximum file locks held */
#define RLIMIT_SIGPENDING 11 /* max number of pending signals */
#define RLIMIT_MSGQUEUE12 /* maximum bytes in POSIX
mqueues */
-
-#define RLIM_NLIMITS 13
+#define RLIMIT_NICE13 /* max nice prio allowed to raise to
+ 0-39 for nice level 19 .. -20 */
+#define RLIMIT_RTPRIO 14 /* maximum realtime priority */
+#define RLIM_NLIMITS 15
#endif
/*
@@ -53,6 +55,8 @@
[RLIMIT_LOCKS] = { RLIM_INFINITY, RLIM_INFINITY }, \
[RLIMIT_SIGPENDING] = { MAX_SIGPENDING, MAX_SIGPENDING }, \
[RLIMIT_MSGQUEUE] = { MQ_BYTES_MAX, MQ_BYTES_MAX }, \
+ [RLIMIT_NICE] = { 0, 0 }, \
+
Re: [PATCH] [request for inclusion] Realtime LSM
On Mon, Mar 07, 2005 at 08:28:21PM -0800, Andrew Morton wrote: > > please describe this "very simple and very real-world problem" in simple > > terms. Lets make sure "problem" and "solution" didnt become detached. > > > > Well others can do that better than I but I'd describe it as > > - Audio apps need to meet their realtime requirements > > - The way to implement that is to give them !SCHED_OTHER and mlockall > capabilities. > > - But they don't want to run as root. Which all fits very nicely with MEMLOCK rlimit and a tiny wrapper that sets !SCHED_OTHER and execs the audio app.. and as I mentioned a few times if we really want to go for a magic uid/gid-based approach we should at least have one that's useable for all capabilities so it can replace the oracle hack aswell. But the proponents of the patch weren't iterested to invest the tiniest bit of work over what they submited. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [request for inclusion] Realtime LSM
Ingo Molnar <[EMAIL PROTECTED]> wrote: > > > * Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > next we > > > $CAPABILITY for $FOO and we're headed straight to interface-hell. > > > > "interface hell"? Wow. > > > > Still. It seems to be what we deserve if all that fancy stuff we have > > cannot address this very simple and very real-world problem. > > please describe this "very simple and very real-world problem" in simple > terms. Lets make sure "problem" and "solution" didnt become detached. > Well others can do that better than I but I'd describe it as - Audio apps need to meet their realtime requirements - The way to implement that is to give them !SCHED_OTHER and mlockall capabilities. - But they don't want to run as root. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [request for inclusion] Realtime LSM
* Andrew Morton <[EMAIL PROTECTED]> wrote: > > next we > > $CAPABILITY for $FOO and we're headed straight to interface-hell. > > "interface hell"? Wow. > > Still. It seems to be what we deserve if all that fancy stuff we have > cannot address this very simple and very real-world problem. please describe this "very simple and very real-world problem" in simple terms. Lets make sure "problem" and "solution" didnt become detached. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [request for inclusion] Realtime LSM
Christoph Hellwig <[EMAIL PROTECTED]> wrote: > > On Mon, Mar 07, 2005 at 07:50:20PM -0800, Andrew Morton wrote: > > > > So I still have the rt-lsm patch floating about, saying "merge me, merge > > me!". I'm not sure that the world would end were I to do so. > > > > Consider this a prod in the direction of those who were pushing > > alternatives ;) > > It's still a really bad idea. It solves a real problem and is well encapsulated. The world won't end if we merge it. Still. My point is: we're still awaiting anything better and thei is just hanging around and hanging around. > You let the magic gid for oracle hugetlb > patch go in with that reasonsing Which continues to cause zero problems. > now ew have relatime-lsm, Not yet. > next we > $CAPABILITY for $FOO and we're headed straight to interface-hell. "interface hell"? Wow. Still. It seems to be what we deserve if all that fancy stuff we have cannot address this very simple and very real-world problem. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Page fault scalability patch V18: Overview
On Mon, 7 Mar 2005, Darren Williams wrote: > Pid: 362, CPU 0, comm: kscrubd0 > psr : 121008022038 ifs : 8308 ip : [] > Not tainted > ip is at scrubd_rmpage+0x61/0x140 Would you try the new version on oss.sgi.com please. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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) radeonfb: PLL access workaround
On Tue, 2005-03-08 at 11:59 +1100, Benjamin Herrenschmidt wrote:
> Hi !
>
> So you remember all those weird lockups at boot that happened in late
> 2.6.11-rc with radeonfb. I posted a "workaround" which just moved code
> around a bit and it appeared to work. I finally got some real infos
> about the problem from ATI, and it seems my "workaround" is not very
> safe and there are other potential issues realted to HW bugs when
> accessing the PLL registers.
>
> This patch implements all of these workarounds (and puts back the code
> where it was before my previous fix).
>
> Please test and let me know if it works. If it's fine, then it should go
> to -mm, and eventually after a while, to a 2.6.11.x update.
>
> Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Here's a new one adding a missing bit..
Index: linux-work/drivers/video/aty/radeonfb.h
===
--- linux-work.orig/drivers/video/aty/radeonfb.h2005-03-08
11:30:37.0 +1100
+++ linux-work/drivers/video/aty/radeonfb.h 2005-03-08 14:49:24.0
+1100
@@ -22,11 +22,6 @@
#include
-/* Some weird black magic use by Apple driver that we don't use for
- * now --BenH
- */
-#undef HAS_PLL_M9_GPIO_MAGIC
-
/***
* Most of the definitions here are adapted right from XFree86 *
***/
@@ -312,7 +307,6 @@
int is_mobility;
int is_IGP;
int R300_cg_workaround;
- int m9p_workaround;
int reversed_DAC;
int reversed_TMDS;
struct panel_info panel_info;
@@ -397,6 +391,11 @@
#define OUTREGP(addr,val,mask) _OUTREGP(rinfo, addr, val,mask)
+/* This function is required to workaround a hardware bug in some (all?)
+ * revisions of the R300. This workaround should be called after every
+ * CLOCK_CNTL_INDEX register access. If not, register reads afterward
+ * may not be correct.
+ */
static inline void R300_cg_workardound(struct radeonfb_info *rinfo)
{
u32 save, tmp;
@@ -407,35 +406,36 @@
OUTREG(CLOCK_CNTL_INDEX, save);
}
+/*
+ * PLL accesses suffer from various HW issues on the different chip
+ * families. Some R300's need the above workaround, rv200 & friends
+ * need a couple of dummy reads after any write of CLOCK_CNTL_INDEX,
+ * and some RS100/200 need a dummy read before writing to
+ * CLOCK_CNTL_INDEX as well. Instead of testing every chip revision,
+ * we just unconditionally do the workarounds at once since PLL
+ * accesses are far from beeing performance critical. Except for R300
+ * one which stays separate for now
+ */
+
+static inline void radeon_pll_workaround_before(struct radeonfb_info *rinfo)
+{
+ (void)INREG(CRTC_GEN_CNTL);
+}
+
+static inline void radeon_pll_workaround_after(struct radeonfb_info *rinfo)
+{
+ (void)INREG(CLOCK_CNTL_DATA);
+ (void)INREG(CRTC_GEN_CNTL);
+}
static inline u32 __INPLL(struct radeonfb_info *rinfo, u32 addr)
{
u32 data;
-#ifdef HAS_PLL_M9_GPIO_MAGIC
- u32 sv[3];
-
- if (rinfo->m9p_workaround) {
- sv[0] = INREG(0x19c);
- sv[1] = INREG(0x1a0);
- sv[2] = INREG(0x198);
- OUTREG(0x198, 0);
- OUTREG(0x1a0, 0);
- OUTREG(0x19c, 0);
- }
-#endif /* HAS_PLL_M9_GPIO_MAGIC */
+ radeon_pll_workaround_before(rinfo);
OUTREG8(CLOCK_CNTL_INDEX, addr & 0x003f);
- data = (INREG(CLOCK_CNTL_DATA));
-
-#ifdef HAS_PLL_M9_GPIO_MAGIC
- if (rinfo->m9p_workaround) {
- (void)INREG(CRTC_GEN_CNTL);
- data = INREG(CLOCK_CNTL_DATA);
- OUTREG(0x19c, sv[0]);
- OUTREG(0x1a0, sv[1]);
- OUTREG(0x198, sv[2]);
- }
-#endif /* HAS_PLL_M9_GPIO_MAGIC */
+ radeon_pll_workaround_after(rinfo);
+ data = INREG(CLOCK_CNTL_DATA);
if (rinfo->R300_cg_workaround)
R300_cg_workardound(rinfo);
return data;
@@ -455,32 +455,16 @@
#define INPLL(addr)_INPLL(rinfo, addr)
-static inline void __OUTPLL(struct radeonfb_info *rinfo, unsigned int index,
u32 val)
+static inline void __OUTPLL(struct radeonfb_info *rinfo, unsigned int index,
+ u32 val)
{
-#ifdef HAS_PLL_M9_GPIO_MAGIC
- u32 sv[3];
-
- if (rinfo->m9p_workaround) {
- sv[0] = INREG(0x19c);
- sv[1] = INREG(0x1a0);
- sv[2] = INREG(0x198);
- OUTREG(0x198, 0);
- OUTREG(0x1a0, 0);
- OUTREG(0x19c, 0);
- mdelay(1);
- }
-#endif /* HAS_PLL_M9_GPIO_MAGIC */
+ radeon_pll_workaround_before(rinfo);
OUTREG8(CLOCK_CNTL_INDEX, (index & 0x003f) | 0x0080);
+
Re: [PATCH] [request for inclusion] Realtime LSM
On Mon, Mar 07, 2005 at 07:50:20PM -0800, Andrew Morton wrote: > > So I still have the rt-lsm patch floating about, saying "merge me, merge > me!". I'm not sure that the world would end were I to do so. > > Consider this a prod in the direction of those who were pushing > alternatives ;) It's still a really bad idea. You let the magic gid for oracle hugetlb patch go in with that reasonsing, now ew have relatime-lsm, next we $CAPABILITY for $FOO and we're headed straight to interface-hell. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [request for inclusion] Realtime LSM
So I still have the rt-lsm patch floating about, saying "merge me, merge me!". I'm not sure that the world would end were I to do so. Consider this a prod in the direction of those who were pushing alternatives ;) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
status of network swapping in linux?
(please CC, not on the list.) Hi all, I have an embedded machine that needs a _tiny_ little bit more memory for some of its tasks than it has. Unfortunately, it does not have an IDE or USB controller, but it does have a 10/100 and three gigabit ethernet interfaces. There have been a number of efforts in the past for making network swapping (either via NFS or NBD) work without deadlocking, but most of those projects appear to have been abandoned. Is it just too hard to get right? Any info appreciated. thanks, Lennert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [uml-devel] Re: Partial fix! - Was: Re: [BUG report] UML linux-2.6 latest BK doesn't compile
On Saturday 05 March 2005 20:45, Jeff Dike wrote: > [EMAIL PROTECTED] said: > > Yes. I finally found a way to get it to compile. Compiling without > > TT mode and WITHOUT static build it still fails with the same problem > > (__bb_init_func problem I already reported). But compiling without TT > > but WITH static build the __bb_init_func problem goes away but instead > > I get a __gcov_init missing symbol in my modules. > > > > Note I have gcc-3.3.4-11 (SuSE 9.2) and it defines __gcov_init. So I > > added this as an export symbol and lo and behold the kernel and > > modules compiled and I am now up an running with UML and NTFS as a > > module. (-: > > Can you try this patch? It exports either __gcov_init or __bb_init_func > depending on your gcc version. a) wrong because you say __GNUC_PATCHLEVEL__ > 4 rather than >= b) wrong because for he the link failed on __bb_init_func at the beginning. So in the case you need to export BOTH symbols. -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/1] fix syscallN() macro errno value checking for i386
On Sunday 30 January 2005 19:30, jerome lacoste wrote:
> On Sun, 30 Jan 2005 18:00:22 +0100, Arnd Bergmann <[EMAIL PROTECTED]> wrote:
> > On Sünnavend 29 Januar 2005 02:01, [EMAIL PROTECTED] wrote:
> > > From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
> > > Cc: David Howells <[EMAIL PROTECTED]>
> > >
> > > The errno values which are visible for userspace are actually in the
> > > range -1 - -129, not until -128 (): this value was added:
> > >
> > > #define EKEYREJECTED129 /* Key was rejected by service */
> > >
> > > And this would break ucLibc (for what I heard).
> > >
> > > This is just a quick-fix, because putting a macro inside errno.h
> > > instead of having it copied in two places would be probably nicer.
> >
> > Yes. Note that your patch only fixes the bug on i386. The code has been
> > copied to many other architectures, and some of them have been updated
> > less recently and are checking for values lower than 128. There should
> > really be a way to keep them all in sync.
>
> what about something along?
>
> #define EKEYNEXT130 /* key counter */
>
> and
>
> if ((unsigned long)(res) >= (unsigned long)(-EKEYNEXT)) {
Yes, I agree with you... I didn't do it that way because of this mail:
"Subject: Re: Fw: Re: [patch 02/11] uml: fix compilation for missing headers
From: David Howells <[EMAIL PROTECTED]>
To: Andrew Morton <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
Date: Fri Jan 14 12:19:33 2005
[]
> I think that the max errno value should become a macro defined in errno.h.
I agree with him on this, but I seem to remember that this didn't go down very
well.
David"
Now, I don't know why it was not done that way, but I wanted to do a quick-fix
to merge it. Somebody please fix it definitively... in 2.6.11 official this
is still unfixed.
--
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] vfs: adds the S_PRIVATE flag and adds use to security
* Andrew Morton ([EMAIL PROTECTED]) wrote: > Jeffrey Mahoney <[EMAIL PROTECTED]> wrote: > > > > This patch adds an S_PRIVATE flag to inode->i_flags to mark an inode as > > filesystem-internal. As such, it should be excepted from the security > > infrastructure to allow the filesystem to perform its own access control. > > OK, thanks. I'll assume that the other three patches are unchanged. > > I don't think we've heard from the SELinux team regarding these patches? I've no issue with these patches. Acked-by: Chris Wright <[EMAIL PROTECTED]> -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Alsa-devel] Re: intel 8x0 went silent in 2.6.11
At Mon, 07 Mar 2005 21:16:10 +0100, Pierre Ossman wrote: > > Takashi Iwai wrote: > > >At Fri, 04 Mar 2005 22:16:03 +0100, > >Pierre Ossman wrote: > > > > > >>It seems I spoke too soon. The defaults picked by the driver are > >>actually fine. It seems to be alsactl store/restore that did something > >>strange when coming from an older kernel. > >> > >> > > > >My guess is that kmix is the cuplrit. > >kmix tends to turn on all mixer switches uncoditionally, and > >saves/restores the mixer config by itself. > > > > > I use Gnome, not KDE so kmix is not an issue. OK. (Then it might be a gnome mixer :) > >Look at /etc/asound.state whether it contains the value of "Headphone > >Jack Sense" control true or false. > > > > > It saves the setting once I've been in 2.6.11. From an earlier kernel > there is no such entry. Of course, the earlier version didn't have this. And did you take a look at the latest content? What stands on it? Maybe you once saved a value wrongly corrected by any reason? > >BTW, the default value of this control switch was fixed for ThinkPads > >on ALSA tree since long time ago, but unfortunately the patch wasn't > >accepted for 2.6.11... > > > > > My machine is a hp/compaq, not a thinkpad, so I don't know if it would > have any effect here. The fix is not only for ThinkPads but for all machines with AD1981 codec and not known to work with "headphone jack" stuff. Takashi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [uml-devel] [BUG: UML 2.6.11-rc4-bk-latest] sleeping function called from invalid context and segmentation fault
On Tuesday 22 February 2005 21:41, Blaisorblade wrote: > On Friday 18 February 2005 16:33, Anton Altaparmakov wrote: > > On Wed, 2005-02-16 at 19:35 +0100, Blaisorblade wrote: > > > On Monday 14 February 2005 12:48, Anton Altaparmakov wrote: > > > > Hi, > > > > > > > > I get a few Debug messages of the form from UML: > > > > > > > > Debug: sleeping function called from invalid context at > > > > include/asm/arch/semaphore.h:107 > > > > in_atomic():0, irqs_disabled():1 > > > > Call Trace: > > > > 087d77b0: [<0809aaa5>] __might_sleep+0x135/0x180 > > > > 087d77d8: [<084d377f>] mcount+0xf/0x20 > > > > 087d77e0: [<0807cc13>] uml_console_write+0x33/0x80 > > > > > > > > Most are coming via uml_console_write. > > > > > > The problem is that the UML tty drivers use a semaphore instead of a > > > spinlock for the locking, which also causes some other problems. > > > > > > The attached patch should fix this, but I've not yet made sure it is > > > not deadlock-prone (I didn't hit any during some very limited testing). > > > > > > So it's not yet ready for 2.6.11. > > > > Trying with the above patch in now only get two "sleeping function > > called from invalid context" warnings during boot and none during > > running. > > I'll look at whether I can produce them... if it's no problem, post their > traces anyway, please. I'm not able... I *did* enable CONFIG_DEBUG_SPINLOCK and CONFIG_DEBUG_SPINLOCK_SLEEP, but still I don't get them. Maybe I have not an interesting enough test case (or kobject debugging is flooding the dmesg ring buffer, which is doing too). > > However I get a lot of those errors: > > > > arch/um/drivers/line.c:262: spin_lock(arch/um/drivers/line.c:085b5900) > > already locked by arch/um/drivers/line.c/262 > > Ok, I'll be looking into them ASAP (which infortunately means not very > soon, sorry). > At a quick look, I see that line 262 is a "spin_lock" called by > line_write_interrupt. I used spin_lock_irqsave everywhere else... but > actually the interrupt must explicitly disable interrupts (I forgot) so, > the simple answer seems to be using spin_lock_irqsave() would fix it. I've done this in the patch I'm working on. I've various stuff on the press, however it should go in for 2.6.12-rc1, I hope. > I > cannot make a patch now. > > > Also both before and after the patch I see a lot of messages like: > > > > kernel: line_write_room: tty2: no room left in buffer > I've never seen them... Ok, correction, I've seen a lot of these... > Anyway, I'm not sure this is a needed warning: > > in include/linux/tty_driver.h, the .write_room member must tell the > available space... it's reasonable that the TTY layer will call a > flush_buffers function. However, looking at stdio_console, I'm seeing that, > in fact, there is no flush_chars function(!!). I'll provide one ASAP. I've not yet removed the warning in the patch, just to be a bit too careful. I'm providing a flush_chars and flush_buffers method. That said, there must be something else going on... it is easy to get the "repeated chars" problem (cat a file is enough), which I thought linked to this: it's when some data is printed and re-printed many times... , and everybody started noticing it just around 2.6.9 / 2.6.10. I'm not sure, but maybe something else is causing the problem... I'm going to work on the ring-buffer handling too, so that I make sure the unusual code paths are also correct (which code paths are usual and which are unusual could have changed). -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] whitespace cleanups for fs/cifs/file.c
On Mon, 7 Mar 2005, Jörn Engel wrote:
> On Mon, 7 March 2005 03:28:46 -0700, Andreas Dilger wrote:
> >
> > Ironically, the whitespace patch gets the small things right, but misses
> > on the big readability issues, such as cifs_open() being 220 lines long
> > and having a _really_ hard time staying inside 80 columns because of so
> > many levels of nested conditionals.
> >
> > Judicious use of gotos and some helper functions would help a lot
> > here (e.g. after CIFSSMBOpen() "if (rc) { ... goto out; }" and
> > "if (!file->private_data) goto out;", would avoid indenting the rest
> > of the function 16 columns. Adding a couple helper functions like
> > "cifs_convert_flags()" to return desiredAccess and disposition, and
> > "cifs_init_private_data()" to allocate ->private_data and initialize
> > the masses of fields would be good.
> >
> > Is it possible that pCifsInode can ever be NULL??? Similarly, "if (buf)"
> > on line 196 is needless, as it has already been checked on line 153
> > (and we abort in that case). Also, kfree() can handle NULL pointers.
>
> Jesper knows those problems already (at least some of them). Right
> now, his biggest problem appears to be patch submission. As soon as
> Steve accepts his patches and the backlog is shrinking, he might get
> to those issues, one at a time.
>
> Unless my glass ball needs cleaning again. Jesper? ;)
>
That is the plan. Small steps.
--
Jesper
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] whitespace cleanups for fs/cifs/file.c
On Mon, 7 Mar 2005, Andreas Dilger wrote:
> On Mar 07, 2005 10:26 +0100, Edgar, Bob wrote:
> > I lurk on the list and didn't comment last time but there is one aspect
> > of this patch that I think is "bad" style. The function declaration should
> > not be on the same line with the type. Why? Try to find the file where a
> > function is defined instead of used. If you grep "^funcname" you'll find
> > it quite simply. The same is true in YFE (mine being vi) /^funcname gets
> > me there in one shot.
> >
> > This may not seem an important thing but when you are coming into a
> > project cold and don't know how anything works or where it lives it
> > can be very important. Consider trying to find where some common
> > function from a library is defined in a project with sever 1000 files.
>
> Tags is your friend. See "make tags" (for vim) or "make TAGS" (for *emacs).
> This is far more efficient than "grep -r ^funcname linux" if you don't even
> know what file a function/struct is defined in. Use CTRL-] to jump to the
> function/struct under the cursor and CTRL-T to pop back out.
>
>
> Ironically, the whitespace patch gets the small things right, but misses
> on the big readability issues, such as cifs_open() being 220 lines long
> and having a _really_ hard time staying inside 80 columns because of so
> many levels of nested conditionals.
>
I wanted to stick to smaller changes initially. I can submit a patch for
that function if Steve wants it.
> Judicious use of gotos and some helper functions would help a lot
> here (e.g. after CIFSSMBOpen() "if (rc) { ... goto out; }" and
> "if (!file->private_data) goto out;", would avoid indenting the rest
> of the function 16 columns. Adding a couple helper functions like
> "cifs_convert_flags()" to return desiredAccess and disposition, and
> "cifs_init_private_data()" to allocate ->private_data and initialize
> the masses of fields would be good.
>
> Is it possible that pCifsInode can ever be NULL??? Similarly, "if (buf)"
> on line 196 is needless, as it has already been checked on line 153
> (and we abort in that case). Also, kfree() can handle NULL pointers.
>
I'm aware of those isues, and I am planning to submit patches for them,
but I wanted to wait and get Steve's response to the smaller cleanups
first.
--
Jesper
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [announce 7/7] fbsplash - documentation
On Dinsdag 08 März 2005 03:17, Michal Januszewski wrote: > +It's possible to set path to the splash helper by writing it to > +/proc/sys/kernel/fbsplash. It should probably just use its own hotplug agent instead of calling the helper directly. > +Splash protocol v1 specified an additional 'fbsplash mode' after the > +framebuffer number. Splash protocol v1 is deprecated and should not be used. When you're submitting a patch for inclusion, the interface should really be stable. I'd completely drop all references to the old version and only support one interface here. Moreover, you should not do versioned interfaces unless you expect incompatible changes in future releases. As long as you still do, that is a sign that the patch is not ready for inclusion. > +Splash protocol v2 specifies the following commands: > + > +getpic > +-- > + The kernel issues this command to request image data. It's up to the > userspace > + helper to find a background image appropriate for the specified theme and > the > + current resolution. The userspace helper should respond by issuing the > + FBIOSPLASH_SETPIC ioctl. > + > +init > + > + The kernel issues this command after the fbsplash device is created and > + the fbsplash interface is initialized. Upon receiving 'init', the userspace > + helper should parse the kernel command line (/proc/cmdline) or otherwise > + decide whether fbsplash is to be activated. > + > + To activate fbsplash on the first console the helper should issue the > + FBIOSPLASH_SETCFG, FBIOSPLASH_SETPIC and FBIOSPLASH_SETSTATE commands, > + in the above-mentioned order. > + > + When the userspace helper is called in an early phase of the boot process > + (right after the initialization of fbcon), no filesystems will be mounted. > + The helper program should mount sysfs and then create the appropriate > + framebuffer, fbsplash and tty0 devices (if they don't already exist) to get > + current display settings and to be able to communicate with the kernel side. > + It should probably also mount the procfs to be able to parse the kernel > + command line parameters. Nothing about the init command seems really necessary. Why not just do that stuff from an /sbin/init script? > +modechange > +-- > + The kernel issues this command on a mode change. The helper's response > should > + be similar to the response to the 'init' command. Note that this time the > + console sem is held and all ioctls must be performed with origin set to > + FB_SPLASH_IO_ORIG_KERNEL. > > +FB_SPLASH_IO_ORIG_KERNEL instructs fbsplash not to try to acquire the console > +semaphore. Not surprisingly, FB_SPLASH_IO_ORIG_USER instructs it to acquire > +the console sem. That sounds really dangerous. Can you guarantee that nothing unexpected happens when a malicious user calls the ioctls with FB_SPLASH_IO_ORIG_KERNEL from a regular user process? > +Info on used structures: > + > +Definition of struct vc_splash can be found in linux/console_splash.h. It's > +heavily commented. Note that the 'theme' field should point to a string Not that heavily documented, actually ;-). > +no longer than FB_SPLASH_THEME_LEN. When FBIOSPLASH_GETCFG call is > +performed, the theme field should point to a char buffer of length > +FB_SPLASH_THEME_LEN. Then don't make it pointer but instead a field of that length. Pointers in ioctl arguments only cause trouble in mixed 32/64 bit environments. > +Definition of struct fb_splash_iowrapper can be found in linux/fb.h. > +The fields in this struct have the following meaning: > + > +vc: > +Virtual console number. This should not be needed. I notice you are creating your own miscdevice for passing ioctl commands. That seems a little backwards since there already is a character device for the frame buffer. Can't you simply add your ioctl commands there? > +origin: > +Specifies if the ioctl is performed as a response to a kernel request. The > +splash helper should set this field to FB_SPLASH_IO_ORIG_KERNEL, userspace > +programs should set it to FB_SPLASH_IO_ORIG_USER. This field is necessary to > +avoid console semaphore deadlocks. As I mentioned, this means there is thinko in your locking scheme. > +data: > +Pointer to a data structure appropriate for the performed ioctl. Type of > +the data struct is specified in the ioctls description. This is very wrong. Using ioctl() for anything is bad enough because it contains an indirection from a system call. Here, you add yet another indirection. Instead of this, you should at least have a single data structure for each ioctl number, without using pointers to other structures. Arnd <>< - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Support HPET with a single timer for system time
This patch removes the check for the existence of multiple HPET timers. It allows the use of HPET with only a single timer for system time if HPET_EMULATE_RTC is not set. Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]> Signed-off-by: Shai Fultheim <[EMAIL PROTECTED]> Index: linux-2.6.10/arch/i386/kernel/time_hpet.c === --- linux-2.6.10.orig/arch/i386/kernel/time_hpet.c 2005-02-28 13:04:28.0 -0800 +++ linux-2.6.10/arch/i386/kernel/time_hpet.c 2005-03-01 12:11:18.702195056 -0800 @@ -121,11 +121,16 @@ int __init hpet_enable(void) id = hpet_readl(HPET_ID); /* -* We are checking for value '1' or more in number field. -* So, we are OK with HPET_EMULATE_RTC part too, where we need -* to have atleast 2 timers. +* We are checking for value '1' or more in number field if +* CONFIG_HPET_EMULATE_RTC is set because we will need an +* additional timer for RTC emulation. +* However, we can do with one timer otherwise using the +* the single HPET timer for system time. */ - if (!(id & HPET_ID_NUMBER) || + if ( +#ifdef CONFIG_HPET_EMULATE_RTC + !(id & HPET_ID_NUMBER) || +#endif !(id & HPET_ID_LEGSUP)) return -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/
[42/many] arch: um config
--- ./arch/um/Kconfig~ 2005-03-02 10:38:09.0 +0300 +++ ./arch/um/Kconfig 2005-03-07 21:30:55.0 +0300 @@ -289,6 +289,8 @@ source "crypto/Kconfig" +source "acrypto/Kconfig" + source "lib/Kconfig" menu "SCSI 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/
Missing include file in linux/ixjuser.h
Hi! There's a problem in the include/linux/ixjuser.h file. It uses the __user macro, but doesn't include the linux/compiler.h file. This doesn't seem to be a problem for the kernel (I'm guessing since some other file includes compiler.h), but it makes a difference when compiling user-space programs that uses ixjuser.h. Including linux/compiler.h in ixjuser.h solves the problem. Fredrik Tolf - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[5/many] acrypto: crypto_conn.c
--- /tmp/empty/crypto_conn.c1970-01-01 03:00:00.0 +0300
+++ ./acrypto/crypto_conn.c 2005-03-07 21:11:01.0 +0300
@@ -0,0 +1,160 @@
+/*
+ * crypto_conn.c
+ *
+ * Copyright (c) 2004 Evgeniy Polyakov <[EMAIL PROTECTED]>
+ *
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "acrypto.h"
+#include "crypto_lb.h"
+#include "crypto_conn.h"
+#include "crypto_user_ioctl.h"
+#include "crypto_user_direct.h"
+
+struct cb_id crypto_conn_id = { 0xdead, 0x };
+static char crypto_conn_name[] = "crconn";
+
+static void crypto_conn_callback(void *data)
+{
+ struct cn_msg *msg, *reply;
+ struct crypto_conn_data *d, *cmd;
+ struct crypto_device *dev;
+ u32 sessions;
+
+ msg = (struct cn_msg *)data;
+ d = (struct crypto_conn_data *)msg->data;
+
+ if (msg->len < sizeof(*d)) {
+ dprintk(KERN_ERR "Wrong message to crypto connector:
msg->len=%u < %u.\n",
+ msg->len, sizeof(*d));
+ return;
+ }
+
+ if (msg->len != sizeof(*d) + d->len) {
+ dprintk(KERN_ERR "Wrong message to crypto connector:
msg->len=%u != %u.\n",
+ msg->len, sizeof(*d) + d->len);
+ return;
+ }
+
+ dev = crypto_device_get_name(d->name);
+ if (!dev) {
+ dprintk(KERN_INFO "Crypto device %s was not found.\n", d->name);
+ return;
+ }
+
+ switch (d->cmd) {
+ case CRYPTO_READ_SESSIONS:
+ reply = kmalloc(sizeof(*msg) + sizeof(*cmd) + sizeof(sessions),
GFP_ATOMIC);
+ if (reply) {
+ memcpy(reply, msg, sizeof(*reply));
+ reply->len = sizeof(*cmd) + sizeof(sessions);
+
+ /*
+* See protocol description in connector.c
+*/
+ reply->ack++;
+
+ cmd = (struct crypto_conn_data *)(reply + 1);
+ memcpy(cmd, d, sizeof(*cmd));
+ cmd->len = sizeof(sessions);
+
+ sessions = atomic_read(>refcnt);
+
+ memcpy(cmd + 1, , sizeof(sessions));
+
+ cn_netlink_send(reply, 0);
+
+ kfree(reply);
+ } else
+ dprintk(KERN_ERR "Failed to allocate %d bytes in reply
to comamnd 0x%x.\n",
+ sizeof(*msg) + sizeof(*cmd), d->cmd);
+ break;
+ case CRYPTO_GET_STAT:
+ reply = kmalloc(sizeof(*msg) + sizeof(*cmd) + sizeof(struct
crypto_device_stat), GFP_ATOMIC);
+ if (reply) {
+ struct crypto_device_stat *ptr;
+
+ memcpy(reply, msg, sizeof(*reply));
+ reply->len = sizeof(*cmd) + sizeof(*ptr);
+
+ /*
+* See protocol description in connector.c
+*/
+ reply->ack++;
+
+ cmd = (struct crypto_conn_data *)(reply + 1);
+ memcpy(cmd, d, sizeof(*cmd));
+ cmd->len = sizeof(*ptr);
+
+ ptr = (struct crypto_device_stat *)(cmd + 1);
+ memcpy(ptr, >stat, sizeof(*ptr));
+
+ cn_netlink_send(reply, 0);
+
+ kfree(reply);
+ } else
+ dprintk(KERN_ERR "Failed to allocate %d bytes in reply
to comamnd 0x%x.\n",
+ sizeof(*msg) + sizeof(*cmd), d->cmd);
+ break;
+ case CRYPTO_REQUEST:
+#if 1
+ {
+ struct crypto_user_direct *usr;
+
+ usr = (struct crypto_user_direct *)(d->data);
+
+ crypto_user_direct_add_request(msg->seq, msg->ack, usr);
+ }
+#endif
+ break;
+ default:
+ dprintk(KERN_ERR "Wrong operation 0x%04x for crypto
connector.\n",
+ d->cmd);
+ return;
+ }
+
+ crypto_device_put(dev);
+}
+
+int
[5/5] bd: script for unbinding any filters
./ubd unbind dev /dev/bd0 filter acrypto ./ubd unbind dev /dev/bd0 filter xor ./ubd unbind dev /dev/bd0 filter fd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[29/many] arch: ia64 config
--- ./arch/ia64/Kconfig~2005-03-02 10:38:26.0 +0300 +++ ./arch/ia64/Kconfig 2005-03-07 21:27:38.0 +0300 @@ -417,3 +417,5 @@ source "security/Kconfig" source "crypto/Kconfig" + +source "acrypto/Kconfig" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[27/many] arch: h8300 config
--- ./arch/h8300/Kconfig~ 2005-03-02 10:38:17.0 +0300 +++ ./arch/h8300/Kconfig2005-03-07 21:27:13.0 +0300 @@ -191,4 +191,6 @@ source "crypto/Kconfig" +source "acrypto/Kconfig" + source "lib/Kconfig" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Alsa-devel] Re: intel 8x0 went silent in 2.6.11
At Mon, 07 Mar 2005 21:13:23 +0100, Pierre Ossman wrote: > > Lee Revell wrote: > > >So is there a bug or not? Mark seems to be the only one affected. > > > >It's important to follow up, because these so-called "ALSA regressions" > >are generating bad press. > > > >Lee > > > > > > > I can generate the error using the following procedure: > > 1. Boot in 2.6.10. Remove /etc/asound.conf and store the current mixer > settings. > 2. Boot in 2.6.11 and let alsactl restore the mixer. > > Provided the machine is powered down between each attempt this gives the > same result. 'Headphone Jack Sense' ends up not muted (which means that > the built-in speakers are dead). > > I fail to find where FC saves/restores the mixer settings so I can't > test without it. There are commands in modprobe.conf but asound.conf > still gets updated when I remove these lines. So there must be some more > place[s] where alsactl gets called. Usually it's called either in init script or in udev configuration. Or, it's not set up via alsactl but by other apps (e.g. kmix). I'm not sure whether GNOME does anything special in this regard, though. Takashi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[??/many] list of files to be sent in a next couple of e-mails with small description
announce - asynchronous crypto layer announce files - file with this cruft bench - acrypto benchmark vs cryptoloop vs dm_crypt iok.c - userspace application which uses ioctl based acrypto access ucon_crypto.c - userspace application which uses direct process' VMA access acrypto_Kconfig.patch - acrypto kernel config file acrypto_Makefile.patch - acrypto make file acrypto_acrypto.h.patch - base definition used in acrypto and it's users acrypto_async_provider.c.patch - asynchronous crypto provider [AES CBC mode only] - sync crypto based acrypto_crypto_conn.c.patch - kernel connector's backend - allows statistic fetching acrypto_crypto_conn.h.patch - definitions for kernel connector's subsystem acrypto_crypto_def.h.patch - various acrypto definitions like crypto modes, types of operation and so on... acrypto_crypto_dev.c.patch - main crypto device add/remove routings acrypto_crypto_lb.c.patch - crypto load balancer's subsystem and main crypto session queues watcher acrypto_crypto_lb.h.patch - definitions for crypto load balancer processing acrypto_crypto_main.c.patch - main routings - session allocations/deallocations and so on... acrypto_crypto_route.h.patch - crypto routing subsystem acrypto_crypto_stat.c.patch - acrypto statistic helpers acrypto_crypto_stat.h.patch - acrypto statistic helpers declarations acrypto_crypto_user.c.patch - base userspace/kernelspace acrypto helpers acrypto_crypto_user.h.patch - above declarations acrypto_crypto_user_direct.c.patch - direct process' VMA access helpers acrypto_crypto_user_direct.h.patch - above declarations acrypto_crypto_user_ioctl.c.patch - ioctl based userspace access acrypto_crypto_user_ioctl.h.patch - above declarations acrypto_simple_lb.c.patch - simple load balancer alpha arm arm26 cris frv h8300 i386 ia64 m32r m68k m68knommu mips parisc ppc ppc64 s390 sh sh64 sparc sparc64 um v850 x86_64 - small patches to enable acrypto config menu bd.patch - asynchronous block device ubd.c - userspace utility to configure asynchronous block device bind unbind - simple scripts to show ubd usage - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.11 Permedia-2 Framebuffer] driver broken (?).
Hello, Jim On Mon, 7 Mar 2005, Jim Hague wrote: > On 05-Mar-2005 Guennadi Liakhovetski wrote: > > Worked on 2.6.10-rc2. With 2.6.11 during boot upon switching to fb, text > > becomes orange, penguins look sick (not sharp). X starts and runs normal > > (doesn't use fb), switching to vt not possible any more. Disabling > > fb-console in kernel config fixes VTs. Reverting pm2fb.c fixes the > > problem. > > I've just tried a stock 2.6.11 fresh from the tarball, and I see some of what > you are seeing. > > I don't see any problems with text colour or images. Text is white, Tux is > 100% > normal. This on a single processor K6/2-450 with a Creative Graphics Blaster > Exxtreme, BTW. > > However, I do see the problem switching back to a vt from X. In fact it does > work, except that the video is blanked. This is a bug in pm2fb.c exposed by > recent changes to fbcon. Please try this fix (works for me) and let me know if > it restores normal service for you too. Thanks for the patch. Yes, it does fix switching between X and VT. As for colours / graphics, disabling CONFIG_FB_PM2_FIFO_DISCONNECT fixes that too, but it worked under 2.6.10-rc2 with that option on too. What does it do and why I cannot use it under 2.6.11 any more? The help text to this option is not very enlightening... Thanks Guennadi > > --- drivers/video/pm2fb.c.orig 2005-03-07 15:35:28.0 + > +++ drivers/video/pm2fb.c 2005-03-07 18:34:13.0 + > @@ -747,7 +747,7 @@ > } > if ((info->var.vmode & FB_VMODE_MASK)==FB_VMODE_DOUBLE) > video |= PM2F_LINE_DOUBLE; > - if (info->var.activate==FB_ACTIVATE_NOW) > + if ((info->var.activate & FB_ACTIVATE_MASK)==FB_ACTIVATE_NOW) > video |= PM2F_VIDEO_ENABLE; > par->video = video; > > Returning to your problems with text colour and images, can you try > with CONFIG_FB_PM2_FIFO_DISCONNECT=n and see if that makes a difference. > > Thanks. > > -- > Jim Hague - [EMAIL PROTECTED] Never trust a computer you can't lift. > --- Guennadi Liakhovetski - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[16/many] acrypto: crypto_user.h
--- /tmp/empty/crypto_user.h1970-01-01 03:00:00.0 +0300
+++ ./acrypto/crypto_user.h 2005-03-07 20:35:36.0 +0300
@@ -0,0 +1,52 @@
+/*
+ * crypto_user.h
+ *
+ * Copyright (c) 2004 Evgeniy Polyakov <[EMAIL PROTECTED]>
+ *
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#ifndef __CRYPTO_USER_H
+#define __CRYPTO_USER_H
+
+#define MAX_DATA_SIZE 3
+#define ALIGN_DATA_SIZE(size) ((size + PAGE_SIZE - 1) & ~(PAGE_SIZE - 1))
+
+enum crypto_user_data_types
+{
+ CRYPTO_USER_DATA_SRC = 0,
+ CRYPTO_USER_DATA_DST,
+ CRYPTO_USER_DATA_KEY,
+ CRYPTO_USER_DATA_IV,
+};
+
+struct crypto_user_data
+{
+ __u16 data_size;
+ __u16 data_type;
+};
+
+
+#ifdef __KERNEL__
+
+int crypto_user_alloc_crypto_data(struct crypto_data *data, int src_size, int
dst_size, int key_size, int iv_size);
+void crypto_user_free_crypto_data(struct crypto_data *data);
+void crypto_user_fill_sg(void *ptr, u16 size, struct scatterlist *sg);
+struct scatterlist *crypto_user_get_sg(struct crypto_user_data *ud, struct
crypto_data *data);
+int crypto_user_fill_sg_data(struct crypto_user_data *ud, struct crypto_data
*data, void *ptr);
+
+#endif /* __KERNEL__ */
+#endif /* __CRYPTO_USER_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/
[26/many] arch: frv config
--- ./arch/frv/Kconfig~ 2005-03-02 10:37:54.0 +0300 +++ ./arch/frv/Kconfig 2005-03-07 21:26:53.0 +0300 @@ -498,4 +498,6 @@ source "crypto/Kconfig" +source "acrypto/Kconfig" + source "lib/Kconfig" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[30/many] arch: m32r config
--- ./arch/m32r/Kconfig~2005-03-02 10:37:30.0 +0300 +++ ./arch/m32r/Kconfig 2005-03-07 21:27:51.0 +0300 @@ -364,4 +364,6 @@ source "crypto/Kconfig" +source "acrypto/Kconfig" + source "lib/Kconfig" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
