* Re: nvidia on sparc32
From: Andrew Morton @ 2006-04-08 8:39 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-fbdev-devel
In-Reply-To: <20060408.012707.80122971.davem@davemloft.net>
"David S. Miller" <davem@davemloft.net> wrote:
>
> From: Andrew Morton <akpm@osdl.org>
> Date: Sat, 8 Apr 2006 01:21:07 -0700
>
> > In file included from drivers/video/nvidia/nv_setup.c:50: include/video/vga.h:24:21: asm/vga.h: No such file or directory
> >
> > Dave, do you think a copy of the sparc64 vga.h will suffice?
>
> Sure, but none of this is ever likely to work.
>
> FWIW, all sparc32 systems with PCI have internal devices only and no
> PCI add-in cards, and they'll never see an NVIDIA device.
>
> So it's a different situation than sparc64 where someone could put an
> NVIDIA card into a PCI slot and we'd like that to work.
>
> I wish there were an easy way to eliminate nonsense configuration
> combinations for a given platform.
hm, OK, thanks. Given that it all compiles with the borrowed vga.h, I
guess the simplest thing to do is to run with that - it fixes allmodconfig,
avoids mucking up the Kconfig files and gives us wide compile coverage.
What thinkest thou?
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* xen-unstable hg tree doesn't compile: io_apic.c:127: warning: ‘prev’ is used uninitialized in this function
From: Hans-Christian Armingeon @ 2006-04-08 8:35 UTC (permalink / raw)
To: xen-devel
Hi,
the current hg tree doesn't compile on x86.
gcc -O2 -fomit-frame-pointer -DNDEBUG -m32 -march=i686 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -nostdinc -fno-builtin -fno-common -fno-strict-aliasing -iwithprefix include -Werror -Wno-pointer-arith -pipe -I/usr/src/xen/xen-unstable.hg-3.0-20060408.1/xen/include -I/usr/src/xen/xen-unstable.hg-3.0-20060408.1/xen/include/asm-x86/mach-generic -I/usr/src/xen/xen-unstable.hg-3.0-20060408.1/xen/include/asm-x86/mach-default -msoft-float -g -D__XEN__ -c io_apic.c -o io_apic.o
cc1: warnings being treated as errors
io_apic.c: In function ‘ioapic_guest_write’:
io_apic.c:127: warning: ‘prev’ is used uninitialized in this function
make[5]: *** [io_apic.o] Error 1
make[5]: Leaving directory `/usr/src/xen/xen-unstable.hg-3.0-20060408.1/xen/arch/x86'
make[4]: *** [/usr/src/xen/xen-unstable.hg-3.0-20060408.1/xen/arch/x86/built_in.o] Error 2
make[4]: Leaving directory `/usr/src/xen/xen-unstable.hg-3.0-20060408.1/xen/arch/x86'
make[3]: *** [/usr/src/xen/xen-unstable.hg-3.0-20060408.1/xen/xen] Error 2
make[3]: Leaving directory `/usr/src/xen/xen-unstable.hg-3.0-20060408.1/xen'
make[2]: *** [install] Error 2
make[2]: Leaving directory `/usr/src/xen/xen-unstable.hg-3.0-20060408.1/xen'
make[1]: *** [install-xen] Error 2
make[1]: Leaving directory `/usr/src/xen/xen-unstable.hg-3.0-20060408.1'
make: *** [build-stamp] Error 2
I know, this is caused by the Werror flag. Can somebody remove this?
Thanks in advance,
Johnny
^ permalink raw reply
* Re: nvidia on sparc32
From: David S. Miller @ 2006-04-08 8:27 UTC (permalink / raw)
To: akpm; +Cc: linux-fbdev-devel
In-Reply-To: <20060408012107.2dc6f594.akpm@osdl.org>
From: Andrew Morton <akpm@osdl.org>
Date: Sat, 8 Apr 2006 01:21:07 -0700
> In file included from drivers/video/nvidia/nv_setup.c:50: include/video/vga.h:24:21: asm/vga.h: No such file or directory
>
> Dave, do you think a copy of the sparc64 vga.h will suffice?
Sure, but none of this is ever likely to work.
FWIW, all sparc32 systems with PCI have internal devices only and no
PCI add-in cards, and they'll never see an NVIDIA device.
So it's a different situation than sparc64 where someone could put an
NVIDIA card into a PCI slot and we'd like that to work.
I wish there were an easy way to eliminate nonsense configuration
combinations for a given platform.
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: [PATCH] Add a /proc/self/exedir link
From: Jan Engelhardt @ 2006-04-08 8:26 UTC (permalink / raw)
To: Andreas Schwab
Cc: Neil Brown, Tony Luck, Mike Hearn, Eric W. Biederman,
linux-kernel, akpm
In-Reply-To: <jeirplrbka.fsf@sykes.suse.de>
>>> It leaks information about the parts of the pathname below the
>>> directory that you otherwise would not be able to see. E.g. if
>>> I have $HOME/top-secret-projects/secret-code-name1/binary
>>> where the top-secret-projects directory isn't readable by you,
>>> then you may find out secret-code-name1 by reading the
>>> /proc/{pid}/exedir symlink.
>>
>> But we already have /proc/{pid}/exe which is a symlink to the
>> executable, thus exposing all the directory names already.
In which case the administrator of the machine should make /proc/xyz
directories mode 0700. (Patches are floating around.)
Jan Engelhardt
--
^ permalink raw reply
* Re: [PATCH] PCI Error Recovery: e100 network device driver
From: Francois Romieu @ 2006-04-08 8:12 UTC (permalink / raw)
To: Linas Vepstas
Cc: Greg KH, linux-kernel, jesse.brandeburg, linuxppc-dev,
john.ronciak, jeffrey.t.kirsher, netdev, linux-pci, Jeff Garzik
In-Reply-To: <20060407231134.GN25225@austin.ibm.com>
Linas Vepstas <linas@austin.ibm.com> :
> Index: linux-2.6.17-rc1/drivers/net/e100.c
> ===================================================================
> --- linux-2.6.17-rc1.orig/drivers/net/e100.c 2006-04-07 16:21:46.000000000 -0500
> +++ linux-2.6.17-rc1/drivers/net/e100.c 2006-04-07 18:10:52.411266545 -0500
[...]
> +static pci_ers_result_t e100_io_error_detected(struct pci_dev *pdev, pci_channel_state_t state)
80 cols limit.
[...]
> +static pci_ers_result_t e100_io_slot_reset(struct pci_dev *pdev)
> +{
> + struct net_device *netdev = pci_get_drvdata(pdev);
> + struct nic *nic = netdev_priv(netdev);
> +
> + if (pci_enable_device(pdev)) {
> + printk(KERN_ERR "e100: Cannot re-enable PCI device after reset.\n");
- The driver supports {get/set}_msglevel. Please consider using netif_msg_xxx
(see include/linux/netdevice.h).
- s/e100/DRV_NAME/ (or netdev->name, or pci_name(...) depending on the
context).
[...]
> +static struct pci_error_handlers e100_err_handler = {
> + .error_detected = e100_io_error_detected,
> + .slot_reset = e100_io_slot_reset,
> + .resume = e100_io_resume,
> +};
Nit: I'd rather follow the style in the declaration of e100_driver.
--
Ueimor
^ permalink raw reply
* nvidia on sparc32
From: Andrew Morton @ 2006-04-08 8:21 UTC (permalink / raw)
To: linux-fbdev-devel; +Cc: David S. Miller
In file included from drivers/video/nvidia/nv_setup.c:50: include/video/vga.h:24:21: asm/vga.h: No such file or directory
Dave, do you think a copy of the sparc64 vga.h will suffice?
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* iptables and mac filtering
From: vlad f halilow @ 2006-04-08 8:21 UTC (permalink / raw)
To: netfilter
Hi there. Please help with strange issuse. I have debian woody with
2.6.12 kernel + iptables.1.3.3. (unstable) under vmware workstation. I
try to block connection to my PPPoE server (rp-pppoe) by mac-address of
client. something like
#iptables -I INPUT -m mac --mac-source blablag -j DROP
. Line inserted showed by iptables -L -v -n but not block any IP-less
requests from address specified. Ping or any IP protocols blocking
success, but pppoe discovery, exchange and traffic pass the filter
wthout any problem with no rule countr increment. How i can fix this
thing? Or what i to do wrong?
^ permalink raw reply
* Re: freescale lite 5200 board and kernel 2.6
From: Matthias Fechner @ 2006-04-08 8:21 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060406221056.GA15540@raptus.dandreoli.com>
[-- Attachment #1: Type: text/plain, Size: 381 bytes --]
Hello Domenico,
* Domenico Andreoli <cavokz@gmail.com> [07-04-06 00:10]:
> kernel is built following the instructions on your wiki, i attached
> the config file. please have a look, let me know if any check/test may
> be advised.
sry, but I have now time to try your kernel config, but I attached
mine which is working fine for me.
Maybe this helps you.
Best regards,
Matthias
[-- Attachment #2: config-mpc52xx.bz2 --]
[-- Type: application/octet-stream, Size: 4800 bytes --]
^ permalink raw reply
* Re: [PATCH] PCI Error Recovery: e100 network device driver
From: Francois Romieu @ 2006-04-08 8:12 UTC (permalink / raw)
To: Linas Vepstas
Cc: Greg KH, Jeff Garzik, netdev, linux-pci, linux-kernel,
linuxppc-dev, john.ronciak, jesse.brandeburg, jeffrey.t.kirsher
In-Reply-To: <20060407231134.GN25225@austin.ibm.com>
Linas Vepstas <linas@austin.ibm.com> :
> Index: linux-2.6.17-rc1/drivers/net/e100.c
> ===================================================================
> --- linux-2.6.17-rc1.orig/drivers/net/e100.c 2006-04-07 16:21:46.000000000 -0500
> +++ linux-2.6.17-rc1/drivers/net/e100.c 2006-04-07 18:10:52.411266545 -0500
[...]
> +static pci_ers_result_t e100_io_error_detected(struct pci_dev *pdev, pci_channel_state_t state)
80 cols limit.
[...]
> +static pci_ers_result_t e100_io_slot_reset(struct pci_dev *pdev)
> +{
> + struct net_device *netdev = pci_get_drvdata(pdev);
> + struct nic *nic = netdev_priv(netdev);
> +
> + if (pci_enable_device(pdev)) {
> + printk(KERN_ERR "e100: Cannot re-enable PCI device after reset.\n");
- The driver supports {get/set}_msglevel. Please consider using netif_msg_xxx
(see include/linux/netdevice.h).
- s/e100/DRV_NAME/ (or netdev->name, or pci_name(...) depending on the
context).
[...]
> +static struct pci_error_handlers e100_err_handler = {
> + .error_detected = e100_io_error_detected,
> + .slot_reset = e100_io_slot_reset,
> + .resume = e100_io_resume,
> +};
Nit: I'd rather follow the style in the declaration of e100_driver.
--
Ueimor
^ permalink raw reply
* atyfb on sparc32
From: Andrew Morton @ 2006-04-08 8:09 UTC (permalink / raw)
To: linux-fbdev-devel
drivers/video/aty/atyfb_base.c: In function `atyfb_ioctl':
drivers/video/aty/atyfb_base.c:1752: error: `FBTYPE_PCI_GENERIC' undeclared (first use in this function)
drivers/video/aty/atyfb_base.c:1752: error: (Each undeclared identifier is reported only once
drivers/video/aty/atyfb_base.c:1752: error: for each function it appears in.)
drivers/video/aty/atyfb_base.c: In function `atyfb_mmap':
drivers/video/aty/atyfb_base.c:1869: warning: integer constant is too large for "unsigned long" type
drivers/video/aty/atyfb_base.c: In function `atyfb_setup_sparc':
drivers/video/aty/atyfb_base.c:2893: error: `_PAGE_CACHE' undeclared (first use in this function)
drivers/video/aty/atyfb_base.c:2894: error: `_PAGE_E' undeclared (first use in this function)
drivers/video/aty/atyfb_base.c:2907: error: `_PAGE_IE' undeclared (first use in this function)
drivers/video/aty/atyfb_base.c: In function `atyfb_pci_probe':
drivers/video/aty/atyfb_base.c:3466: warning: integer constant is too large for "unsigned long" type
drivers/video/aty/atyfb_base.c:3466: warning: large integer implicitly truncated to unsigned type
drivers/video/aty/atyfb_base.c:3469: error: `_PAGE_CACHE' undeclared (first use in this function)
drivers/video/aty/atyfb_base.c:3470: error: `_PAGE_E' undeclared (first use in this function)
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* GIT 1.3.0-rc3
From: Junio C Hamano @ 2006-04-08 8:07 UTC (permalink / raw)
To: git
I do not think there are any more remaining major issue for a
real 1.3.0, so here is hopefully the final round of rc. Testing,
fixing and polishing are appreciated.
Changes since v1.3.0-rc2 are as follows:
* documentation (Francis Daly, Jon Loeliger, Marco Roeland)
* add regexp to pickaxe (Petr Baudis)
* add git-clean (Pavel Roskin)
* cvsimport fix (Johannes Schindelin)
* svnimport fix (Karl Hasselström)
* imap-send updates (Mike McCormack)
* assorted build and porting fixes (Johannes Schindelin)
* gitk updates (Keith Packard, Mark Wooding, Paul Mackerras, Pavel Roskin
Rutger Nijlunsing, Stephen Rothwell)
* http-fetch can use PROPFIND in place of objects/info/packs (Nick Hengeveld)
* deltifier bounds safety (Nicolas Pitre)
* clone fix
* fix blame, broken by recent revision walker updates
* use built-in-xdiff in combine-diff
* use built-in-xdiff in blame
* support -S in blame
* diff_flush() memory leak fix when NO_OUTPUT
* make human-date parsing friendlier to our European friends.
* optimize thin-pack generation by pack-objects
^ permalink raw reply
* ipt_unclean query
From: Sumit @ 2006-04-08 8:06 UTC (permalink / raw)
To: netfilter-devel
Hi Devs,
After making an unclean DROP ruleset I got "not-working" complains form
some of my clients who using specific stock-trading application.
Simply looking to dmesg I found there are few message states that
ipt_unclean: TCP flags bad: 0x0015
This message mean unclean match is dropping tcp packet with ACK,RST,
and FIN flags. This I confirm with ipt_unclean.c code
As per RFC793 (TCP)
... ... ...
In all states except SYN-SENT, all reset (RST) segments are validated by
checking their SEQ-fields. A reset is valid if its sequence number is
in the window.
... ... ...
Then is there any significance of dropping ACK+RST+FIN combination?
Happy Netfiltering,
--
_____ __ __ ____ ____ __ ______
/\ ___\ /\ \ /\ \ /\ \ \/ /\ \ /\ \ /\__ _\
\ \ ____\ \ \ \\_| \\ \ \_ /\ \ \\ \ \\__ \ \/
\//\___ \ \ \______ / \ \__\ \ \__\\ \__\ \ \__\
\/_____/ \/_____ / \/__/ \/__/ \/__/ \/__/
^ permalink raw reply
* Re: RT task scheduling
From: Ingo Molnar @ 2006-04-08 8:03 UTC (permalink / raw)
To: Bill Huey
Cc: Darren Hart, linux-kernel, Thomas Gleixner, Stultz, John,
Peter Williams, Siddha, Suresh B, Nick Piggin
In-Reply-To: <20060408075430.GA19403@gnuppy.monkey.org>
* Bill Huey <billh@gnuppy.monkey.org> wrote:
> The last time I looked at it I thought it did something pretty
> simplistic in that it just dumped any RT thread to another CPU but
> didn't do it in a strict manner with regard to priority. Maybe that's
> changed or else I didn't pay attention to it that as carefully as I
> thought.
well as Darren's testcase shows, it might still have some bug - but the
mechanism is intended to be strict. (the implementation had a couple of
strictness bugs (they show up as long latencies on SMP) but those were
ironed out months ago.)
> As far as CPU binding goes, I'm wanting a method of getting around the
> latency of the rt overload logic in certain cases at the expense of
> rebalancing. That's what I ment by it.
yeah, that certainly makes sense, and it's one reason why i'm thinking
about the separate SCHED_FIFO_GLOBAL policy for 'globally scheduled' RT
tasks, while still keeping the current lightweight non-global RT
scheduling. Global scheduling either means a global lock, or as in the
-rt implementation means a "global IPI", but there's always a nontrivial
"global" cost involved.
Ingo
^ permalink raw reply
* Re: [patch 1/1] pc-speaker: add SND_SILENT
From: Stas Sergeev @ 2006-04-08 8:02 UTC (permalink / raw)
To: dtor_core; +Cc: 7eggert, Linux kernel, vojtech
In-Reply-To: <d120d5000603270834j79e707ffu760eba3062531b64@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 580 bytes --]
Hi.
Dmitry Torokhov wrote:
> etc. All these alternative bells would not disrupt operation of your
> snd_pcsp module but it still would disable the bell because it does
> not know better.
OK, I now used INPUT_DEVICE_ID_MATCH_BUS, and, with something
like the attached patch, it seems to work. So essentially my
driver has enough of the knowledge about the device in question,
and this seems to be possible exactly only with the input subsystem.
(which makes me confident again that using the input subsystem
was exactly the right choice :)
What do you think about that approach?
[-- Attachment #2: input_en.diff --]
[-- Type: text/x-patch, Size: 1637 bytes --]
--- a/include/linux/input.h 2006-04-05 17:10:01.000000000 +0400
+++ b/include/linux/input.h 2006-04-05 17:36:49.000000000 +0400
@@ -862,7 +862,7 @@
struct pt_regs *regs;
int state;
-
+ int enabled;
int sync;
int abs[ABS_MAX + 1];
@@ -1019,6 +1019,8 @@
int input_open_device(struct input_handle *);
void input_close_device(struct input_handle *);
+void input_enable_device(struct input_handle *handle, int enab);
+
int input_accept_process(struct input_handle *handle, struct file *file);
int input_flush_device(struct input_handle* handle, struct file* file);
--- a/drivers/input/input.c 2006-01-12 11:23:09.000000000 +0300
+++ b/drivers/input/input.c 2006-04-05 17:51:27.000000000 +0400
@@ -36,6 +36,7 @@
EXPORT_SYMBOL(input_release_device);
EXPORT_SYMBOL(input_open_device);
EXPORT_SYMBOL(input_close_device);
+EXPORT_SYMBOL(input_enable_device);
EXPORT_SYMBOL(input_accept_process);
EXPORT_SYMBOL(input_flush_device);
EXPORT_SYMBOL(input_event);
@@ -52,7 +53,7 @@
{
struct input_handle *handle;
- if (type > EV_MAX || !test_bit(type, dev->evbit))
+ if (type > EV_MAX || !test_bit(type, dev->evbit) || !dev->enabled)
return;
add_input_randomness(type, code, value);
@@ -265,6 +266,11 @@
up(&dev->sem);
}
+void input_enable_device(struct input_handle *handle, int enab)
+{
+ handle->dev->enabled = enab;
+}
+
static void input_link_handle(struct input_handle *handle)
{
list_add_tail(&handle->d_node, &handle->dev->h_list);
@@ -712,6 +718,7 @@
class_device_initialize(&dev->cdev);
INIT_LIST_HEAD(&dev->h_list);
INIT_LIST_HEAD(&dev->node);
+ dev->enabled = 1;
}
return dev;
^ permalink raw reply
* Re: [PATCH] Fix checking for multiple boot tags in board config.
From: Imre Deak @ 2006-04-08 7:58 UTC (permalink / raw)
To: ext Jonathan McDowell; +Cc: linux-omap-open-source
In-Reply-To: <20060407155818.GV22929@earth.li>
On Fri, 2006-04-07 at 16:58 +0100, ext Jonathan McDowell wrote:
> On Fri, Apr 07, 2006 at 06:50:15PM +0300, Imre Deak wrote:
> > On Fri, 2006-04-07 at 16:00 +0100, ext Jonathan McDowell wrote:
> > > Currently if we look for more than one instance of a boot tag and it's
> > > defined in the board config rather than passed by the boot loader we can
> > > get stuck in a loop where the same tag is processed many times. This can
> > > be seen with the gpio-switch driver, for example. The patch below fixes
> > > this by respecting the skip parameter to get_config when we're scanning
> > > the board config structure.
> > >
> > > Signed-Off-By: Jonathan McDowell <noodles@earth.li>
> > >
> > > diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
> > > index 0625df5..39ab667 100644
> > > --- a/arch/arm/plat-omap/common.c
> > > +++ b/arch/arm/plat-omap/common.c
> > > @@ -114,8 +114,12 @@ static const void *get_config(u16 tag, s
> > > * in the kernel. */
> > > for (i = 0; i < omap_board_config_size; i++) {
> > > if (omap_board_config[i].tag == tag) {
> > > - kinfo = &omap_board_config[i];
> > > - break;
> > > + if (skip == 0) {
> > > + kinfo = &omap_board_config[i];
> > > + break;
> > > + } else {
> > > + skip--;
> > > + }
> > > }
> > > }
> > > if (kinfo == NULL)
> >
> > Should the case be handled when a configuration is present in both the
> > boot tag and the board config? If so, we should stop parsing after the
> > boot tags whenever the requested tag is found, even if there are less
> > then 'skip' instances of it, and return NULL.
>
> If a config option that can appear multiple times (ie when the skip
> option would apply) is present in both the boot tag and board config I'd
> expect both to have effect. You might have some instances of a device
> that exist on all variants of the board (that would be in the board
> config) and then some additional instances that would be controlled by
> the boot tags passed by the boot loader. Though equally I can see the
> argument for the other way when you'd want to override the defaults. :)
>
Ok, I didn't consider the semantic where we merge the two
configurations. And since it was the implied behavior so far, fixing it
with your patch seems to be the right thing.
--Imre
^ permalink raw reply
* Re: SuSE 10.0 and it's RPM 4.1.1??
From: Yawar Amin @ 2006-04-08 7:57 UTC (permalink / raw)
To: linux-newbie
In-Reply-To: <20060407182326.GA1046@lnx2.kvinet.com>
On 4/8/06, Hal MacArgle <haltec@kvinet.com> wrote:
> > If I recall correctly RPM stands for Red Hat Package Manager which I believe
> > is uses by Fedora/Redhat and FreeMandriva/Mandriva/Mandrake.
>
> True AFAIK; plus others including Slackware that has the rpm
> program but warns us that it doesn't work with all apps... Open
> Source keeps us on our toes, eh?? Could it be with SuSe that it means
> something like Reliable Package Manager, instead of RedHat Package
> Manager?? Stranger things have happened.. The study of acronyms is
> another PhD dissertation..
Believe it or not, RPM stands for RPM Package Manager.
--
Yawar
Malaysia +60 (12) 918 6642
Bangladesh +880 (174) 614 754 or +880 (2) 882 1848 or +880 (175) 003
706 or +880 (189) 250 170
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* Re: [PATCH rc1-mm] de_thread: fix deadlockable process addition
From: Eric W. Biederman @ 2006-04-08 7:55 UTC (permalink / raw)
To: Andrew Morton; +Cc: oleg, ebiederm, linux-kernel
In-Reply-To: <20060407155619.18f3c5ec.akpm@osdl.org>
Andrew Morton <akpm@osdl.org> writes:
> Andrew Morton <akpm@osdl.org> wrote:
>>
>> Oleg Nesterov <oleg@tv-sign.ru> wrote:
>> >
>> > - if (likely(p->tasks.prev != LIST_POISON2))
>> > + if (likely(p->tasks.prev != LIST_POISON2)) {
>>
>> argh.
>>
>> c'mon guys, we can't put a dependency on list_head poisoning into generic
>> code.
>>
>
> A suitable fix might be to add a new list_del_poison() (or
> list_del_rcu_something()?) and use that everywhere.
>
> But it should use a different poisoning pattern, so we know that the kernel
> will still work correctly when someone removes the list_head debugging.
Agreed. That is ugly. I would recommend some new functions
list functions but in thinking about this I believe I see
how we can avoid this case completely.
The first step is to optimize thread_group_leader to be
defined in terms of tasks and not process ids. Which
is one less pointer dereference.
The second step is to modify de_thread to reduce the
old thread group leader to a thread. This requires changing the
leaders parents, changing the leaders thread_group leader, unhashing
the leader from the process group and session, and removing
the leader from the task list.
With those two changes exit.c should not need to account for
the de_thread case.
Oleg please take a hard look and see if you can find anything
that will break with the patch below.
I believe that is all that is needed to cleanly keep do_each_thread
from seeing a single thread multiple times.
Eric
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 541f482..2964a2c 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1203,7 +1203,7 @@ extern void wait_task_inactive(task_t *
#define while_each_thread(g, t) \
while ((t = next_thread(t)) != g)
-#define thread_group_leader(p) (p->pid == p->tgid)
+#define thread_group_leader(p) (p == p->group_leader)
static inline task_t *next_thread(task_t *p)
{
diff --git a/fs/exec.c b/fs/exec.c
index 0291a68..9b0f9c4 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -721,9 +721,14 @@ static int de_thread(struct task_struct
list_add_tail(¤t->tasks, &init_task.tasks);
current->parent = current->real_parent = leader->real_parent;
- leader->parent = leader->real_parent = child_reaper;
+ leader->parent = leader->real_parent = current;
current->group_leader = current;
- leader->group_leader = leader;
+ leader->group_leader = current;
+
+ /* Reduce leader to a thread */
+ detach_pid(leader, PIDTYPE_PGID, current->signal->pgrp);
+ detach_pid(leader, PIDTYPE_SID current->signal->session);
+ list_del_init(&leader->tasks);
add_parent(current);
add_parent(leader);
^ permalink raw reply related
* Re: Slow guest network I/O when CPU is pegged - Looking for acknowledgement from developers
From: Keir Fraser @ 2006-04-08 7:56 UTC (permalink / raw)
To: Matt Ayres; +Cc: xen-devel@lists.xensource.com
In-Reply-To: <4436AE88.1080200@tektonic.net>
On 7 Apr 2006, at 19:25, Matt Ayres wrote:
> Ok, so we all know that guest network I/O is slow when the system
> CPU's are being utilized extensively whether it be from dom0 or from
> other guests. Lots of people have written about this and I can post
> concrete tests if required.
>
> I'm just looking for one of the Xen developers to acknowledge that
> they have been able to replicate the problem and it is indeed being
> worked on or will be sometime in the near future. No one has
> acknowledged any of the previous threads on either list so I want to
> make sure it is an outstanding issue that is not being overlooked.
It depends on the setup but poor scheduling is the main reason for poor
network performance, usually. SEDF seems to have some problems with
real-time domains (like domain0 with its default scheduling parameters)
and gives them all the CPU they want -- this is obviously going to be
bad if a client domain is scheduled on the same CPU. Since UDP has no
flow control, dom0 can keep itself busy generating or forwarding UDP
packets to the domU that get dropped continually in netback driver.
DomU will hardly ever get scheduled. Even in the case of TCP, any drops
will be interpreted as congestion and transmit rate will be cut.
Basically I think the SEDF scheduler needs cleaning up: probably by
removing the mass of confusing conditionally compiled options and then
focusing on the remaining code that is actually compiled in. Another
option is to try specifying the BVT scheduler and see if that works
better. Or try setting dom0 to have non-real-time guarantees. Or give
dom0 its own hyperthread on an Intel system (strongly recommended if
it's possible).
Apart from that, if you really are genuinely loading up CPUs with
CPU-intensive workloads, and expecting them also to be able to process
a significant amount of network traffic then something has to give. You
can only run CPUs at 100%.
-- Keir
^ permalink raw reply
* Re: RT task scheduling
From: Bill Huey @ 2006-04-08 7:54 UTC (permalink / raw)
To: Ingo Molnar
Cc: Darren Hart, linux-kernel, Thomas Gleixner, Stultz, John,
Peter Williams, Siddha, Suresh B, Nick Piggin, Bill Huey (hui)
In-Reply-To: <20060408072530.GA14364@elte.hu>
On Sat, Apr 08, 2006 at 09:25:30AM +0200, Ingo Molnar wrote:
> > to the contrary, the "RT overload" code in the -rt tree does strict,
> > system-wide RT priority scheduling. That's the whole point of it.
>
> so after this "clarification of terminology" i hope you are in picture
> now, so could you please explain to me what you meant by:
> > > You should consider for a moment to allow for the binding of a
> > > thread to a CPU to determine the behavior of a SCHED_FIFO class task
> > > instead of creating a new run category. [...]
>
> to me it still makes no sense, and much of the followups were based on
> this. Or were you simply confused about what the scheduling code in -rt
> does precisely? Did that get clarified now?
The last time I looked at it I thought it did something pretty simplistic
in that it just dumped any RT thread to another CPU but didn't do it in
a strict manner with regard to priority. Maybe that's changed or else I
didn't pay attention to it that as carefully as I thought.
As far as CPU binding goes, I'm wanting a method of getting around the
latency of the rt overload logic in certain cases at the expense of
rebalancing. That's what I ment by it.
bill
^ permalink raw reply
* Re: [RFC] packet/socket owner match (fireflier) using skfilter
From: edwin @ 2006-04-08 7:50 UTC (permalink / raw)
To: Bodo Eggert; +Cc: linux-kernel, fireflier-devel
In-Reply-To: <Pine.LNX.4.58.0604072149110.2496@be1.lrz>
On Fri, Apr 07, 2006 at 10:06:45PM +0200, Bodo Eggert wrote:
> On Fri, 7 Apr 2006 edwin@gurde.com wrote:
>
> If apache is running a CGI script, it must pass the socket (bound to
> remote:port,local:80, to the CGI at fd 2*. If your firewall is blocking
> this, your CGI scripts will stop working.
Hmm, an exception could be made for programs like apache.
The user would then create a rule that says that apache is allowed to pass on
file descriptors.
Or a rule could be created for the userspace part of fireflier that would auto-add the cgi-scripts
to apache's group sid. Which IMHO would be the best, because the user will still have control on
what programs have access to the network. He can see that list at any time, and modify it, if not correct.
If we would simply allow file descriptors to be passed on, he wouldn't have that control.
(none of this is implemented yet)
> > running a program via NFS, and giving access for it to the network? why
> > would I want that?
>
> Why not? E.g. you could set up a farm of redundand apache servers.
Ok, so the userspace part of fireflier will have to deal with nfs mounts as a special case.
It should store the rules in "server,path,executable hash" format, and do the inode lookup on startup,
or when the first packet arrives.
> > Aren't inodes stored on the disk?
>
> At least Mostly, but is this a requirement?
Currently it is, until we implement path+hash rules for nfs mounts,etc.
What devices can I safely assume that the inodes won't change over boots/mounts?
Cheers,
Edwin
^ permalink raw reply
* Re: Problems with Scanner class in Blackdown JDK
From: Yawar Amin @ 2006-04-08 7:45 UTC (permalink / raw)
To: linux-newbie
In-Reply-To: <20060406220514.42082.qmail@web37807.mail.mud.yahoo.com>
On 4/7/06, Mac <macduineabhan@yahoo.com> wrote:
> I switched to Sun's JDK, and I'm still having the same
> problem. What can you recommend?
>
> Mac
http://java.sun.com/j2se/1.5.0/docs/api/java/util/Scanner.html says
java.util.Scanner has only been present in the API since version 1.5.
You need to use the latest version of the JDK.
--
Yawar
Malaysia +60 (12) 918 6642
Bangladesh +880 (174) 614 754 or +880 (2) 882 1848 or +880 (175) 003
706 or +880 (189) 250 170
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* Re: [RFC][PATCH 0/7] fireflier LSM for labeling sockets based on its creator (owner)
From: edwin @ 2006-04-08 7:41 UTC (permalink / raw)
To: Chris Wright
Cc: linux-security-module, James Morris, linux-kernel,
fireflier-devel, sds
In-Reply-To: <20060407194545.GA15997@sorel.sous-sol.org>
On Fri, Apr 07, 2006 at 12:45:45PM -0700, Chris Wright wrote:
>
> > Summary of how fireflier LSM works:
> > - each program is associated a sid, depending on its mountpoint+inode, i.e. 2
> > processes launched from the same program have the same sid
>
> That sounds like a problem. Ptrace can undermine that really easily.
I forgot to mention, if a process gets ptraced, it is getting a different sid.
> Also bind mounts will give you a different sid for same exectuable, with
> a possible way to get into interesting 'group' situation.
I should use something else instead of the mountpoint to make sure inodes are unique.
Maybe I should use the device, instead of the mountpoint.
>
> > - each socket created by a processis labeled with the process's sid
> > - if 2 or more programs have access to the socket, it is labeled with a "group
> > sid". A group sid contains a list of the sids of programs having access
> > - userspace, or iptables module can match packets on this "fireflier context"
>
> How do you keep from joining the group?
New processes aren't added to a group, instead a new group is created.
So if A, and B are in group 1; and C would have to be added, then a new group (2) is created, that
contains all what the previous contained (A,B), and the newly added sid (C)
When you create rules for group A, and B; any socket labeled with that group sid will be accessed only by A and B.
> what do you do about ptrace,
As stated above, ptracing means a new sid (I used the unsafe flag passed to certain function by the kernel, maybe I
should also implement the ptrace hook)
/proc/[pid]/mem,
Restricting access to /proc/[pid]/mem can be done properly by SELinux.
Is it worth to implement access restriction to /proc/self/mem in fireflier lsm?
If so, should I restrict access to it for all programs except the process itself?
> fd passing,
I implemented the file_receive hook. Is there any other way to pass a fd? (besides fork+execve which is covered)
> bind mounts,
using the device instead of mountpoint? But are devices named consistently between boots? what if somebody adds/removes
a harddisk/usb stick? will that change the device naming?
> /proc/self/mem,
Why is this a security risk? Can a child process access the parent's data through /proc/self/mem?
> etc.
You made me curious, what other ways are there to gain access to the "data" and open files held by another process?
(Of course if somebody wants "full" security, he should use SELinux.)
>
> > - how do I generate an SELinux policy, that does what this LSM module does?
>
> Sounds like the best solution.
Yes, but writing such a policy will take time, that is why it is planned for version 2.1, or 2.2.
I will try to write a policy module generator userspace program, but I don't know how to create
"group labels". How do I label a socket, in such a way, that I'll be able to determine all the programs having access
to it? Can an inode have multiple labels (contexts)?
Having a fireflier lsm in 2.0 (although with reduced security compared to SELinux) is better than having no lsm at all.
FYI fireflier 1.x, and 1.99beta accepted a packet if the first (!) program found to have access to a socket was
in its list of rules. (finding this was done searching /proc for an open socket having the proper inode,
determined from /proc/net/tcp|udp|tcp6|udp6)
Thanks in advance,
Edwin
^ permalink raw reply
* Re: 3.0.2 kernels
From: Keir Fraser @ 2006-04-08 7:34 UTC (permalink / raw)
To: Brian Hays; +Cc: xen-devel
In-Reply-To: <e4ca66ec0604071721p70db06d6m6dfc8dcb2496aecd@mail.gmail.com>
On 8 Apr 2006, at 01:21, Brian Hays wrote:
> I've noticed that when executing "make kernels" in the 3.0.2 tree
> separate "xen0" and "xenU" are no longer created. Is this by design?
> Is there a way to have both kernels built when executing make dist?
>
> Thank you,
> Brian
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
'KERNELS="linux-2.6-xen0 linux-2.6-xenU" make kernels'
or 'make linux-2.6-xen0-build linux-2.6-xenU-build'
-- Keir
^ permalink raw reply
* RE: upgrading from 3.0.1 to 3.0.2
From: James Harper @ 2006-04-08 7:33 UTC (permalink / raw)
To: rhce admin, xen-devel
Fwiw, I just upgraded two servers.
The first one didn't boot first time around because the install script
hadn't done a 'depmod -a 2.6.16-xen' so mkinitramfs didn't install any
modules.
The second one refuses to start xend properly for some reason, but I
just noticed it is pointing at a local but unmaintained Debian
repository, so everything is much more out of date than it should be.
I'm upgrading it now.
I haven't encountered any of the problems that you refer too.
James
> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> bounces@lists.xensource.com] On Behalf Of rhce admin
> Sent: Saturday, 8 April 2006 14:55
> To: xen-devel@lists.xensource.com
> Subject: [Xen-devel] upgrading from 3.0.1 to 3.0.2
>
> Hi All,
>
> I've tried upgrading from 3.0.1 to 3.0.2 on a couple of test servers
and
> had the same strange results on both... In both cases I had a running
> 3.0.1 server, then downloaded the 3.0.2 source. Next, I extracted the
> files and executed "make XEN_TARGET_X86_PAE=y world". Upon completion
I
> executed "dist/install.sh", changed the grub.conf and rebooted. Once
the
> machines rebooted both began complaining that files in "/etc/rc.d/*"
were
> missing. Various services failed to start because of this as well as
> networking.
>
> Does anyone know what may have caused this based on the steps above?
Is
> there a more preferred way to upgrade from one version to the next?
^ permalink raw reply
* Re: [RFC] Hypercalls from HVM guests
From: Keir Fraser @ 2006-04-08 7:31 UTC (permalink / raw)
To: Steve Ofsthun; +Cc: xen-devel
In-Reply-To: <4436BDE2.5090504@virtualiron.com>
On 7 Apr 2006, at 20:30, Steve Ofsthun wrote:
>> Actually, maybe using an unused index for CPUID (e.g. 0xb0000000)
>> would
>> be better? As that's defined to return all zero's, and not cause any
>> traps whatever value you use (unless the CPU is so old that it doesn't
>> support CPUID, of course).
>
> This sounds encouraging, but is CPUID always trapped by the HVM code?
It can be, and in practise yes it is so this could work.
-- Keir
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.