El lun, 18-04-2005 a las 12:26 -0700, David S. Miller escribió:
Stephen Hemminger has already added TCP port randomization on
connect() to the 2.6.x tree. See
net/ipv4/tcp_ipv4.c:tcp_v4_hash_connect(), where randomized port
selection occurs. And unlike your patch, Stephen did add ipv6
On Mon, Apr 18, 2005 at 02:48:41PM +0200, Rao Davide wrote:
Is LVM working on the alpha port 2.6 kernel series ?
works fine for me.
If so where do I get libdevmapper so that I can build the userspace LVM
utils ?
I tryied downloading
On Mon, 18 Apr 2005, Lorenzo Hernández García-Hierro wrote:
Adding a trusted user group-like configuration option could be useful,
as it's done within grsecurity, among that the whole thing might be good
to depend on a config. option, but that implies using weird ifdef's and
the other folks.
On Mon, Apr 18, 2005 at 05:41:46PM +0100, Andy Armstrong wrote:
For those who haven't seen it the Cherry CyMotion Linux keyboard is a
decent quality keyboard with the Windows specific keys replaced with
Linux keys. It's got a nice little picture of Tux on it too. The
supplied patches aren't
Here's an attempt at dynamic sched domains aka isolated cpusets
o This functionality is on top of CPUSETs and provides a way to
completely isolate any set of CPUs dynamically.
o There is a new cpu_isolated flag that allows users to convert
an exclusive cpuset to an isolated one
o The
On 18 Apr 2005, at 19:14, Greg KH wrote:
Your patches are line-wrapped, and the tabs were stripped out :(
Ah poop - sorry about that. I'm using the Mac mail client which managed
to give me the impression it was going to send them clean.
Care to redo them, add a signed-off-by: line and send them
El lun, 18-04-2005 a las 15:24 -0400, Rik van Riel escribió:
This looks like a very bad default to me!
Your patch would force people to run system monitoring
applications as root, because otherwise they cannot get
some of the information they can get now. Forcing that
these applications
Arjan van de Ven wrote:
you should since that physical page can be reused, say by a root
process, and you'd be majorly screwed
I don't understand what you mean by reused. The whole point behind pinning the memory
is that it stays where it is. It doesn't get moved around and it doesn't get
On Mon, 2005-04-18 at 15:00 -0500, Timur Tabi wrote:
Arjan van de Ven wrote:
you should since that physical page can be reused, say by a root
process, and you'd be majorly screwed
I don't understand what you mean by reused. The whole point behind pinning
the memory
is that it stays
On Mon, Apr 18, 2005 at 09:40:40PM +0200, Arjan van de Ven wrote:
On Mon, 2005-04-18 at 11:25 -0500, Timur Tabi wrote:
Arjan van de Ven wrote:
this is a myth; linux is free to move the page about in physical memory
even if it's mlock()ed!!
darn, yes, this is true.
I know people who
On Wed, Apr 13, 2005 at 12:45:51PM +, Paul Slootman wrote:
We have a variety of Dell rackmount systems, also on Cyclades, and see
this mess everywhere.
I had reported this problem a little while ago, see
http://marc.theaimsgroup.com/?l=linux-kernelm=111036598927105w=2
but unfortunately
El lun, 18-04-2005 a las 16:01 -0400, Rik van Riel escribió:
On Mon, 18 Apr 2005, Lorenzo Hernández García-Hierro wrote:
Adding a trusted user group-like configuration option could be useful,
as it's done within grsecurity, among that the whole thing might be good
to depend on a config.
Dave Jones writes the following:
On Mon, Apr 18, 2005 at 08:46:52PM +0200, Lorenzo Hernández García-Hierro
wrote:
This patch changes the permissions of the following procfs entries to
restrict non-root users from accessing them:
[snip]
- /proc/uptime
?!
[snip]
-
Arjan van de Ven wrote:
you just said that you didn't care that it got munlock'd. So you don't
care that it gets freed either. And then reused.
Well, I can live with the app being able to call munlock(), because the apps that our
customers use don't call munlock(). What I can't live with is a
On Mon, 2005-04-18 at 22:18 +0200, Lorenzo Hernndez Garca-Hierro
wrote:
For this purpose I (re)submitted a patch originally made by Serge E.
Hallyn that adds a hook in order to catch task lookups, thus, providing
an easy way to handle and determine when a task can lookup'ed.
It's at:
This patch adds a new function valid_signal() that tests if its argument
is a valid signal number.
The reasons for adding this new function are:
- some code currently testing _NSIG directly has off-by-one errors. Using
this function instead avoids such errors.
- some code currently tests
The patch below converts most of the current code that uses _NSIG directly
to instead use the valid_signal() function added by the previous patch.
This avoids gcc -W warnings and off-by-one errors and it's also nice and
readable, no doubt about what the code tests.
Signed-off-by: Jesper Juhl
On Mon, 18 Apr 2005, Jesper Juhl wrote:
This patch adds a new function valid_signal() that tests if its argument
is a valid signal number.
The reasons for adding this new function are:
- some code currently testing _NSIG directly has off-by-one errors. Using
this function instead
Hi Derek,
My comments on your code:
+Changes:
+v0.1 26 March 2005
+ Initial Release - developed on uClinux with 2.6.9 kernel
+v0.2 11 April 2005
+ Coding style changes
+
Changelogs are not welcome in kernel code.
+#include linux/config.h
On 18 Apr 2005, at 19:14, Greg KH wrote:
Care to redo them, add a signed-off-by: line and send them to the
linux-usb-devel mailing list and CC: the hid maintainer?
All done. Sorry for the inconvenience.
--
Andy Armstrong, hexten.net
-
To unsubscribe from this list: send the line unsubscribe
On Mon, 18 Apr 2005 20:07:04 +0200, Lorenzo =?ISO-8859-1?Q?Hern=E1ndez_?=
=?ISO-8859-1?Q?Garc=EDa-Hierro?= said:
The limit is only checked when process is created on a fork() call, but
during execution it's uid can change, thus, the limit for the new uid
could be exceed.
The only two ways I
Lorenzo Hernández García-Hierro wrote:
El lun, 18-04-2005 a las 15:05 -0400, Dave Jones escribió:
This is utterly absurd. You can find out anything thats in /proc/cpuinfo
by calling cpuid instructions yourself.
Please enlighten me as to what security gains we achieve
by not allowing users to
Matt Mackall wrote:
On Sat, Apr 16, 2005 at 01:08:47AM +, David Wagner wrote:
http://eprint.iacr.org/2005/029
Unfortunately, this paper's analysis of /dev/random is so shallow that
they don't even know what hash it's using. Almost all of section 5.3
is wrong (and was when I read it
hello,
I'm trying to mount root filesystem on cramfs (2.6.11,
compiled with mtd and CRAMFS support), however I get
following well known error message:
VFS: Cannot open root device mtdblock1 or
unknown-block(31,1)
Please append a correct root= boot option
Kernel panic - not syncing: VFS: Unable
On Mon, Apr 18, 2005 at 01:55:06PM +0100, Alan Cox wrote:
On Llu, 2005-04-18 at 00:47, Adrian Bunk wrote:
Are there any external drivers using these exports, and if there are,
why aren't they in the kernel?
Its a standard API
If there aren't and someone will at some time in the future
This patch lacked a small bit.
Updated patch below.
cu
Adrian
-- snip --
This patch makes needlessly global code static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
drivers/usb/media/pwc/pwc-ctrl.c | 78 +++
drivers/usb/media/pwc/pwc-if.c |2
On Mon, 2005-04-18 at 19:00 +0100, Stephen C. Tweedie wrote:
Note that there _is_ some additional complexity here. It's not entirely
free. Specifically, if we have other tasks waiting on our provisional
window, then we need to be very careful about the life expectancy of the
wait
On Sun, Apr 17, 2005 at 10:26:43PM +0200, Daniel Ritz wrote:
from your dmesg:
PCI: :00:0b.0 pmc: 7601, current_state, pmcsr: 00040, new:
ACPI: PCI Interrupt :00:0b.0[A] - GSI 19 (level, low) - IRQ 19
3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
On Mon, 18 Apr 2005 11:56:15 +0200, Alexander Nyberg wrote:
This patch fixes the NMI checking problems in -mm x64 for me. It
What problems?
Sorry, in -mm on x64 check_nmi_watchdog() has started to be run as a
late_initcall(). Currently it reports the NMIs as stuck on a few systems
although
Hello, James.
On Mon, Apr 18, 2005 at 10:33:21AM -0500, James Bottomley wrote:
On Mon, 2005-04-11 at 03:45 +0900, Tejun Heo wrote:
scmd-eh_timeout is used to resolve the race between command
completion and timeout. However, during error handling,
scsi_send_eh_cmnd uses
On Tue, 2005-04-19 at 07:31 +0900, Tejun Heo wrote:
The original code also uses timer pending status as a signal that
command completed normally in scsi_eh_done() function, and the same
race also exists in the original code, no matter what we do, unless we
make timer expiration and removal of
On Wed, 2005-04-13 at 12:45 +, Paul Slootman wrote:
Phil Oester [EMAIL PROTECTED] wrote:
On Sat, Mar 26, 2005 at 03:10:05PM +, Russell King wrote:
Doesn't matter. The problem is that dwmw2's NS16550A patch (from ages
ago) changes the prescaler setting for this device so we can use
James Bottomley wrote:
On Tue, 2005-04-19 at 07:31 +0900, Tejun Heo wrote:
The original code also uses timer pending status as a signal that
command completed normally in scsi_eh_done() function, and the same
race also exists in the original code, no matter what we do, unless we
make timer
On Sat, Apr 16, 2005 at 11:46:13AM -0700, Paul Ionescu wrote:
Was this setup supposed to work ?
Not yet, sorry. This patch was simply decoupling the power state
of the device from its physical presence in the slot. It had
nothing to do about programming p2p bridges and subordinate
devices
Dinakar Guniguntala wrote:
Here's an attempt at dynamic sched domains aka isolated cpusets
Very good, I was wondering when someone would try to implement this ;)
It needs some work. A few initial comments on the kernel/sched.c change
- sorry, don't have too much time right now...
---
Hello.
I've been trying to run Fedora Core 3 on dual P3 machine (Asus P2B-DS board,
Intel BX chipset), but every time I try to boot it, it hangs moments after
mounting local filesystems. It doesn't really matter if I boot SMP or non-SMP
kernel and I've tried several, from 2.6.9 to latest
Hi Andrew,
This patch against kernel 2.6.12-rc2 adds missing button codes for the
Leadtek Winfast remote controls.
Concerning the KEY_* values, I tried to be coherent with the other
remote controls supported by the kernel.
Best regards,
Nicolas
--
Add missing button codes for the Leadtek
On Mon, Apr 18, 2005 at 12:14:06PM -0500, Miller, Mike (OS Dev) wrote:
From: Christoph Hellwig [mailto:[EMAIL PROTECTED]
This looks like a patch for Linux 2.4. Such major changes for the
2.4 tree don't make sense anymore, especially for
functionality not even in Linux 2.6.
This
This patch contains the following cleanups:
- make two needlessly global functions static
- kill an ancient version variable
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
drivers/net/ne3210.c |9 +++--
1 files changed, 3 insertions(+), 6 deletions(-)
---
This patch contains the following cleanups:
- make the needlessly global function seeq8005_init static
- kill an ancient version variable
- remove some outdated Emacs settings
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
This patch was already sent on:
- 21 Feb 2005
drivers/net/seeq8005.c
This patch makes two needlessly global functions static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
drivers/media/video/bttv-driver.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
--- linux-2.6.12-rc2-mm3-full/drivers/media/video/bttv-driver.c.old
2005-04-19
This patch contains the following possible cleanups:
- make needlessly global code static
- remove the following unneeded EXPORT_SYMBOL:
- cx88-core.c: cx88_pci_irqs
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
drivers/media/video/cx88/cx88-core.c |5 ++---
This patch contains the following possible cleanups:
- make needlessly global code static
- #if 0 the following unused global functions:
- dibusb/dvb-dibusb-usb.c: dibusb_set_streaming_mode
- frontends/mt352.c: mt352_read
- ttpci/av7110_hw.c: av7110_reset_arm
- ttpci/av7110_hw.c:
This patch contains the following possible cleanups:
- #if 0 the following unused global functions:
- hpsb_lock
- hpsb_send_gasp
- ieee1394_transactions.h: remove the stale hpsb_lock64 prototype
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
drivers/ieee1394/ieee1394_transactions.c |
This patch makes some needlessly global code static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
drivers/isdn/hardware/eicon/dadapter.c |2 +-
drivers/isdn/hisax/hfc4s8s_l1.c|4 ++--
drivers/isdn/hysdn/hycapi.c| 20 +++-
This patch makes some needlessly global code static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
drivers/md/dm-hw-handler.c|2 +-
drivers/md/dm-path-selector.c |2 +-
drivers/md/dm-table.c |2 +-
drivers/md/dm-zero.c |4 ++--
drivers/md/md.c
This patch makes a needlessly global function static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
--- linux-2.6.12-rc2-mm3-full/drivers/media/common/saa7146_fops.c.old
2005-04-19 01:21:37.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/media/common/saa7146_fops.c
2005-04-19
This patch makes a needlessly global struct static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
--- linux-2.6.12-rc2-mm3-full/drivers/media/video/saa7134/saa7134-dvb.c.old
2005-04-19 01:39:58.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/media/video/saa7134/saa7134-dvb.c
This patch contains the following possible cleanups:
- make two needlessly global structs static
- #if 0 the EXPORT_SYMBOL'ed but unused function tveeprom_dump
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
drivers/media/video/tveeprom.c |6 --
include/media/tveeprom.h |1 -
On Wed, 2005-04-13 at 19:21 -0700, Venkatesh Pallipadi wrote:
This adds another timer combination of PIT/HPET to go with
HPET/HPET, HPET/TSC and PIT/TSC!
This system that has HPET and doesn't have Legacy support, does it support
routing HPET interrupts through IOAPIC in standard routing
On Mon, 2005-04-18 at 14:38 -0500, Linas Vepstas wrote:
Hi,
The patch below appears to fix a problem where a number of dead processes
linger on the system. On a highly loaded system, dozens of processes
were found stuck in do_exit(), calling thier very last schedule(), and
then being
On Mon, 2005-04-18 at 14:38 -0500, Linas Vepstas wrote:
Hi,
The patch below appears to fix a problem where a number of dead processes
linger on the system. On a highly loaded system, dozens of processes
were found stuck in do_exit(), calling thier very last schedule(), and
then being
Hm, I think I got this set up properly, but don't have an automated
script to generate the changelog and diffstat messages yet, so bear with
me...
Could you merge with:
kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6.git/
It should be against your latest git tree. It contains a
On Mon, Apr 18, 2005 at 10:56:57AM -0500, Tom Zanussi wrote:
Kingsley Cheung writes:
On Wed, Mar 23, 2005 at 08:02:54PM +1100, [EMAIL PROTECTED] wrote:
Hi
I'm using relayfs to relay data from a kernel module to user space on
a SuSE 2.6.5 kernel. I'm not absolutely sure what
On Tue, 2005-04-19 at 11:07 +1000, Benjamin Herrenschmidt wrote:
On Mon, 2005-04-18 at 14:38 -0500, Linas Vepstas wrote:
Hi,
The patch below appears to fix a problem where a number of dead processes
linger on the system. On a highly loaded system, dozens of processes
were found
On Mon, Apr 11, 2005 at 01:25:32AM -0700, Andrew Morton wrote:
...
All 819 patches:
...
bk-netdev.patch
...
drivers/net/wireless/hostap/hostap.c:#include hostap_crypt.c
drivers/net/wireless/hostap/hostap.c:#include hostap_ap.c
drivers/net/wireless/hostap/hostap.c:#include hostap_info.c
On Tue, Apr 19, 2005 at 04:03:12AM +0200, Adrian Bunk wrote:
drivers/net/wireless/hostap/hostap.c:#include hostap_crypt.c
Please do not #include .c files.
A tested patch would be appreciated.. ;-)
A proper separation in a .c file and a header file is the better
solution.
Agreed and this
Rik van Riel wrote:
(B
(BOn Mon, 18 Apr 2005, Takashi Ikebe wrote:
(B
(B
(B
(BI believe process status copy consume more time, may be below sequences are
(Bneeded;
(B- Stop the service on ACT-process.
(B- Copy on memory/on transaction status to shared memory.
(B
(B
(B
(BNo need
This patch makes two needlessly global fimware images static const.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
drivers/net/appletalk/cops_ffdrv.h |2 +-
drivers/net/appletalk/cops_ltdrv.h |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
---
This patch makes a needlessly global struct static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
--- linux-2.6.12-rc2-mm3-full/drivers/net/arcnet/capmode.c.old 2005-04-19
03:03:23.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/net/arcnet/capmode.c 2005-04-19
03:03:53.0
This patch contains the following cleanups:
- mkiss.c: make a needlessly global variable static
- dmascc.c: remove the unused global function dmascc_setup
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
drivers/net/hamradio/dmascc.c | 10 --
drivers/net/hamradio/mkiss.c |2 +-
This patch contains the following cleanups:
- make a needlessly global function static
- remove the unneeded global function irport_probe
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
drivers/net/irda/irport.c | 15 +--
1 files changed, 1 insertion(+), 14 deletions(-)
---
This patch contains the following possible cleanups:
- make some needlessly global code static
- remove the unneeded global function DBG_REG
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
drivers/mmc/wbsd.c | 30 --
drivers/mmc/wbsd.h |7 ---
2 files
This patch contains the follwing cleanups:
- make needlessly global code static
- remove obsolete Emacs settings
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
drivers/net/pcmcia/ibmtr_cs.c |3 --
drivers/net/tokenring/3c359.c |3 +-
On Mon, 18 Apr 2005 00:33:57 -0700
Ashmi Bhanushali [EMAIL PROTECTED] wrote:
hi all..
i m a new bee in lunix kernel. and i m trying to implement FIFO+
queuing for packet forwarding in linux kernel by modifying the
original code for packet forwarding(FIFO).
The more useful way to do this is
On Mon, Apr 18, 2005 at 09:40:37PM +, David Wagner wrote:
Yes, that is a minor glitch, but I believe all their points remain
valid nonetheless. My advice is to apply the appropriate s/MD5/SHA1/g
substitution, and re-read the paper to see what you can get out of it.
The problem is not
On Tue, Apr 19, 2005 at 11:14:27AM +0900, Takashi Ikebe wrote:
this makes software developer crazy
are you serious? how is live patching of .text easier than some of
the other suggestions which all are more or less sane and things like
gdb, oprofile, etc. will deal with w/o problems?
Theodore Ts'o wrote:
For one, /dev/urandom and /dev/random don't use the same pool
(anymore). They used to, a long time ago, but certainly as of the
writing of the paper this was no longer true. This invalidates the
entire last paragraph of Section 5.3.
Ok, you're right, this is a serious
Alright, let's try some small i2c and w1 patches...
Could you merge with:
kernel.org/pub/scm/linux/kernel/git/gregkh/i2c-2.6.git/
It contains 4 small patches, 2 i2c and 2 w1 bugfixes, diffstat is
below, I'll figure out how to send the individual patches later.
thanks,
greg k-h
Christoph,
FYI - Emulex is committed to completing the effort for creating a
vendor-agnostic open-source hbaapi library for linux, including the thornier
issues of performing CT passthru and RNID functionality. As soon as the
library exists, an open-source SMI-S provider would become
Sorry, I may mistake the point,
(BChris Wedgwood wrote:
(B
(BFor me, is seems very dangerous to estimate the primary copy is not
(Bbroken through status takeover..
(B
(B
(B
(Bthat would also be a problem for live patching too, if you have bad
(Bstate, you have bad state --- live
Greetings,
For months I have been reading as much as I can about the current
stable/unstable development model, but still have a question.
Has the Linux Kernel reached a point where the majority of developers feel
that (at least for now) no *MAJOR* rip it out, stomp on it, burn it and
start
modprobe tcrypt hangs the box on both kernels.
The last printks are:
wp256 test runs ok
testing wp384
NNnUnable to handle kernel paging request at virtual address eXXX
Nothing is printed after this and system locks up solid.
No Sysrq-B.
IIRC, 2.6.9 was okay.
Just a heads-up.
--
vda
-
To
On Tue, Apr 19, 2005 at 02:19:57PM +0900, Takashi Ikebe wrote:
What I want to say is takeover may makes memory unstable, because
there are extra operations to reserve current (unstable) status to
memory.
mmap is coherent between processes
Live patching never force target process to reserve
Hmmm ... interesting patch. My reaction to the changes in
kernel/cpuset.c are complicated:
* I'm supposed to be on vacation the rest of this month,
so trying (entirely unsuccessfully so far) not to think
about this.
* This is perhaps the first non-trivial cpuset patch to come
in the
401 - 475 of 475 matches
Mail list logo