Re: [PATCH] OpenBSD Networking-related randomization port

2005-01-29 Thread Arjan van de Ven
On Fri, 2005-01-28 at 23:12 +0100, Lorenzo Hernndez Garca-Hierro
wrote:
 El vie, 28-01-2005 a las 21:47 +0100, Arjan van de Ven escribi:
  as for obsd_get_random_long().. would it be possible to use the
  get_random_int() function from the patches I posted the other day? They
  use the existing random.c infrastructure instead of making a copy...
 
 As seen at
  the functions at obsd_rand.c so we wouldn't need to add more maintenance 
 overhead, I hope you can understand why I want it like that

I actually DON'T understand that. 
What you say kinda sorta makes sense if you're an external patch. But if
you are inside the kernel (that was the goal of this patch, right?) then
the argument is actually entirely the wrong way around...

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] OpenBSD Networking-related randomization port

2005-01-29 Thread Arjan van de Ven
On Fri, 2005-01-28 at 23:12 +0100, Lorenzo Hernndez Garca-Hierro
wrote:
 El vie, 28-01-2005 a las 21:47 +0100, Arjan van de Ven escribi:
  as for obsd_get_random_long().. would it be possible to use the
  get_random_int() function from the patches I posted the other day? They
  use the existing random.c infrastructure instead of making a copy...
 
 As seen at
 http://www.kernel.org/pub/linux/kernel/people/arjan/execshield/00-randomize-A0
  you can suppose that there's 


I actually meant
http://www.kernel.org/pub/linux/kernel/people/arjan/randomize/02-
randomize-infrastructure
which I posted for inclusion in the main kernel 2 or 3 days ago.
That's nice and stand alone to get a random value; we should be able to
share 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] relayfs redux, part 2

2005-01-29 Thread Andi Kleen
Tom Zanussi [EMAIL PROTECTED] writes:

 Hi,

 This patch is the result of the latest round of liposuction on relayfs
 - the patch size is now 44K, down from 110K and the 200K before that.
 I'm posting it as a patch against 2.6.10 rather than -mm in order to
 make it easier to review, but will create one for -mm once the changes
 have settled down.

The logging fast path seems still a bit slow to me. I would like
to have a logging macro that is not much worse than a stdio putc,
basically something like

  get_cpu();
  if (buffer space  N) { 
  memcpy(buffer, input, N);
  buffer pointer += N;
  } else { 
  FreeBuffer(input, N); 
  }
  put_cpu();

This would need interrupt protection only if interrupts can access
it, best you use separate buffers for that too.

-Andi
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Patch 4/6 randomize the stack pointer

2005-01-29 Thread Arjan van de Ven

 I actually just tried to paxtest a fresh Fedora Core 3, unadultered,
 that I installed, and it FAILED every test.  After a while, spender
 reminded me about PT_GNU_STACK.  It failed everything but the Executable
 Stack test after execstack -c *.  The randomization tests gave
 13(heap-etexec), 16(heap-etdyn), 17(stack), and none for main exec
 (etexec,et_dyn) or shared library randomization.

because you ran prelink.
and you did not compile paxtest with -fPIE -pie to make it a PIE
executable.

 
 Also, before you say it, I read, comprehended, and anylized the source.
  This was PaXtest 0.9.6, and I did specific traces (after changing
 body.c to prevent it from forking) to look for mprotect() and mmap()
 calls and find out what they do (I saw probably glibc getting mmap()ed
 in, there wasn't anything in the source doing the mmap() calls I saw).
 There were no dirty tricks to mprotect() a high area of memory, which is
 something Ingo called foul on in 0.9.5.

there is one actually if you look careful enough.


 
 if (strlen(a)  4)
   a[5] = '\0';
 foo(a);
 
 void foo(char *a) {
char b[5];
strcpy(b,a);
 }
 
 This code is safe, but you can't tell from looking at foo().  You don't
 get a look at every other object being compiled against this one that
 may call foo() either.  So compile time buffer overflow detection is a
 best-effort at best.

actually this one gets caught, since this will be turned into a checking
strcpy which aborts after the 5th character.


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: compat ioctl for submiting URB

2005-01-29 Thread Christopher Li
It is nice to know all that. I guess I did not know much about
the other 64 bit systems. I will update and resend my patch.

Thanks!

Chris

On Fri, Jan 28, 2005 at 09:45:38PM -0800, Roland Dreier wrote:
 Christopher This patch is for the case that running 32 bit
 Christopher application on a 64 bit kernel. So far only x86_64
 Christopher allow you to do that.
 
 Actually, at least ia64, mips, parisc, ppc64, s390 and sparc64 also
 support 32-bit applications on a 64-bit kernel.  All of those
 architectures except s390 can use USB.  I guess vmware doesn't run on
 most of those architectures but any solution in the mainline kernel
 should be generic enough to handle them all.
 
  - R.
 -
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: [ANN] removal of certain net drivers coming soon: eepro100, xircom_tulip_cb, iph5526

2005-01-29 Thread Greg KH
On Thu, Jan 27, 2005 at 03:45:40PM -0500, Jeff Garzik wrote:
 
 (GregKH cc'd for his deprecated list)

It's a file in the Documentation/ directory, feel free to just patch it,
adding entries for these drivers.

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] relayfs redux, part 2

2005-01-29 Thread Greg KH
On Fri, Jan 28, 2005 at 01:38:22PM -0600, Tom Zanussi wrote:
 +extern void * alloc_rchan_buf(unsigned long size,
 +   struct page ***page_array,
 +   int *page_count);
 +extern void free_rchan_buf(void *buf,
 +struct page **page_array,
 +int page_count);

As these will be polluting the global namespace of the kernel, could
you add relayfs_ to the front of them?

Also, any reason why you haven't exported the fops of relayfs so that
others can use this in their filesystems (like proc and debugfs)?

 +/**
 + *   rchan_create_file - create relay file, including parent directories
 + *   @chanpath: path to file, including filename
 + *   @dentry: result dentry
 + *   @data: data to associate with the file
 + *
 + *   Returns 0 if successful, negative otherwise.
 + */
 +static inline int rchan_create_file(const char *chanpath,
 + struct dentry **dentry,
 + struct rchan_buf *data)
 +{
 + int err;
 + const char * fname;
 + struct dentry *topdir;
 +
 + err = rchan_create_dir(chanpath, fname, topdir);
 + if (err  (err != -EEXIST))
 + return err;
 +
 + err = relayfs_create_file(fname, topdir, dentry, data, S_IRUSR);
 +
 + return err;
 +}

Why not just return the * to the dentry?  Gets rid of one paramater...

Also, if a path is passed to this function, when the channel is
finally torn down, that path is not removed, right?  Or did I miss that
in the code somewhere?

 +/**
 + *   check_attribute_flags - check sanity of channel attributes
 + *   @flags: channel attributes
 + *
 + *   Returns 0 if successful, negative otherwise.
 + */
 +static inline int check_attribute_flags(u32 *attribute_flags)
 +{
 + u32 flags = *attribute_flags;
 +
 + if ((flags  RELAY_MODE_CONTINUOUS) 
 + (flags  RELAY_MODE_NO_OVERWRITE))
 + return -EINVAL; /* Can't have it both ways */
 +
 + if (!(flags  RELAY_MODE_CONTINUOUS) 
 + !(flags  RELAY_MODE_NO_OVERWRITE))
 + *attribute_flags |= RELAY_MODE_CONTINUOUS; /* Default */
 +
 + return 0;
 +}

Why be nice to your caller?  Just force them to get the flags right, and
if not, error out, you don't have to provide a default as this is a
required parameter to start up a channel, right?

 +/*
 + * Per-cpu relay channel buffer
 + */
 +struct rchan_buf
 +{
 + void *start;/* start of channel buffer */
 + void *data; /* start of current sub-buffer */
 + local_t offset; /* current offset into sub-buffer */
 + unsigned bufsize;   /* sub-buffer size */
 + unsigned alloc_size;/* total buffer size allocated */
 + unsigned nbufs; /* number of sub-buffers */
 + unsigned bufs_produced; /* count of sub-buffers produced */
 + unsigned bufs_consumed; /* count of sub-buffers consumed */
 + wait_queue_head_t read_wait;/* reader wait queue */
 + struct work_struct wake_readers; /* reader wake-up work struct */
 + struct rchan_callbacks *cb; /* client callbacks */
 + struct work_struct work;/* remove file work struct */
 + u32 flags;  /* relay channel attributes */
 + struct dentry *dentry;  /* channel file dentry */
 + atomic_t refcount;  /* channel refcount */

Please use struct kref for this.

 + struct page **page_array;   /* array of current buffer pages */
 + int page_count; /* number of current buffer pages */
 + unsigned *padding;  /* padding counts per sub-buffer */
 + unsigned *commit;   /* commit counts per sub-buffer */
 + int finalized;  /* buffer has been finalized */
 +} cacheline_aligned;

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: compat ioctl for submiting URB

2005-01-29 Thread Christopher Li
On Sat, Jan 29, 2005 at 07:33:31AM +0100, Andi Kleen wrote:
 
 Looks reasonable from a first look.
 
 Issues:
 - Should use CONFIG_COMPAT, not x86-64 specific symbols

Agree.

 - Why can't you set URB_COMPAT transparently in the emulation
 layer?  Then existing applications would hopefully work without
 changes, right?

The existing application is don't need to set the USB_COMPAT flag.
It is use internally to track the URB is submit from 32 bit user
space. I guess I don't have to use that flag.

 
 You may also want to preserve the __user casts, otherwise
 Al Viro and other sparse users will be unhappy.

I did try. Which place are you referring to? I guess miss some of
it.

Chris

 
 Thanks for attacking this long standing problem.
 
 -Andi
 
 -
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: [discuss] [PATCH] Move HPET options from top level, enable HPET_TIMER prompt

2005-01-29 Thread Andi Kleen
On Fri, Jan 28, 2005 at 11:55:13AM -0500, Pavel Roskin wrote:
 Hello!
 
 make menuconfig for x86_64 looks somewhat funky:
 
 [ ] Provide RTC interrupt (NEW)

I will move that thanks.

 Code maturity level options  ---
 General setup  ---
 ...
 
 I believe all x86_64 specific options for HPET timer should be moved to 
 the Processor type and features menu.  That's where they are located for 
 i386.  There are two such options - HPET_TIMER and HPET_EMULATE_RTC.
 
 Also, there is no prompt for HPET_TIMER, so it's always set.  However, the 
 help text ends with If unsure, say Y.  Kind of pointless, isn't it?  I 
 enabled the prompt and deselected HPET_TIMER.  The kernel compiled and 
 booted just fine.  Kernel messages don't indicate that HPET is used, but 
 they said so when HPET_TIMER was enabled.

I prefer to keep it always enabled.

-Andi
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] OpenBSD Networking-related randomization port

2005-01-29 Thread Valdis . Kletnieks
On Fri, 28 Jan 2005 21:47:45 +0100, Arjan van de Ven said:

 as for obsd_get_random_long().. would it be possible to use the
 get_random_int() function from the patches I posted the other day? They
 use the existing random.c infrastructure instead of making a copy...
 
 I still don't understand why you need a obsd_rand.c and can't use the
 normal random.c

Note that obsd_rand.c started off life as a BSD-licensed file - I was told
that was a show-stopper when I submitted basically the same patch a while back.

So re-working it to use get_random_int()  would be a good idea, I think


pgpGPHRoyvvic.pgp
Description: PGP signature


Re: ptrace single-stepping change breaks Wine

2005-01-29 Thread Kari Hurtta

[ Reading just long long thread (actually from
gmane.comp.emulators.wine.devel) ]

[EMAIL PROTECTED]
Linus Torvalds [EMAIL PROTECTED]:

 +
 + /*
 +  * Was the TF flag set by a debugger? If so, clear it now,
 +  * so that register information is correct.
 +  */
 + if (tsk-ptrace  PT_DTRACE) {
 + regs-eflags = ~TF_MASK;
 + tsk-ptrace = ~PT_DTRACE;
=
 + if (!tsk-ptrace  PT_DTRACE)
 ===
 + goto clear_TF;
 + }
   }

Perhaps, I'm stupid.

But is there something strange on that test of tsk-ptrace variable?

Before that PT_DTRACE was cleared from that same tsk-ptrace variable.

/ Kari Hurtta
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] compat USB ioctl take II was Re: compat ioctl for submiting URB

2005-01-29 Thread Christopher Li
On Sat, Jan 29, 2005 at 07:33:31AM +0100, Andi Kleen wrote:
 Issues:
 - Should use CONFIG_COMPAT, not x86-64 specific symbols
Fixed.

 - Why can't you set URB_COMPAT transparently in the emulation
 layer?  Then existing applications would hopefully work without
 changes, right?

Now I see it. That is not what I intent. I must misplace it.
I remove the USB_COMPAT in the new patch any way. It looks
cleaner.

 You may also want to preserve the __user casts, otherwise

Not sure where it is. But I need to verify this patch on Monday.
I don't have an AMD 64 at home.

Thanks.

Chris

Index: linux-2.5/include/linux/compat_ioctl.h
===
--- linux-2.5.orig/include/linux/compat_ioctl.h 2005-01-26 17:23:57.0 
-0800
+++ linux-2.5/include/linux/compat_ioctl.h  2005-01-29 00:57:16.0 
-0800
@@ -692,6 +692,9 @@
 COMPATIBLE_IOCTL(USBDEVFS_CONNECTINFO)
 COMPATIBLE_IOCTL(USBDEVFS_HUB_PORTINFO)
 COMPATIBLE_IOCTL(USBDEVFS_RESET)
+COMPATIBLE_IOCTL(USBDEVFS_SUBMITURB32)
+COMPATIBLE_IOCTL(USBDEVFS_REAPURB32)
+COMPATIBLE_IOCTL(USBDEVFS_REAPURBNDELAY32)
 COMPATIBLE_IOCTL(USBDEVFS_CLEAR_HALT)
 /* MTD */
 COMPATIBLE_IOCTL(MEMGETINFO)
Index: linux-2.5/include/linux/usbdevice_fs.h
===
--- linux-2.5.orig/include/linux/usbdevice_fs.h 2005-01-25 12:08:02.0 
-0800
+++ linux-2.5/include/linux/usbdevice_fs.h  2005-01-29 00:59:10.0 
-0800
@@ -32,6 +32,7 @@
 #define _LINUX_USBDEVICE_FS_H
 
 #include linux/types.h
+#include linux/compat.h
 
 /* - */
 
@@ -123,6 +124,22 @@
char port [127];/* e.g. port 3 connects to device 27 */
 };
 
+struct usbdevfs_urb32 {
+   unsigned char type;
+   unsigned char endpoint;
+   compat_int_t status;
+   compat_uint_t flags;
+   compat_caddr_t buffer;
+   compat_int_t buffer_length;
+   compat_int_t actual_length;
+   compat_int_t start_frame;
+   compat_int_t number_of_packets;
+   compat_int_t error_count;
+   compat_uint_t signr;
+   compat_caddr_t usercontext; /* unused */
+   struct usbdevfs_iso_packet_desc iso_frame_desc[0];
+};
+
 #define USBDEVFS_CONTROL   _IOWR('U', 0, struct usbdevfs_ctrltransfer)
 #define USBDEVFS_BULK  _IOWR('U', 2, struct usbdevfs_bulktransfer)
 #define USBDEVFS_RESETEP   _IOR('U', 3, unsigned int)
@@ -130,9 +147,12 @@
 #define USBDEVFS_SETCONFIGURATION  _IOR('U', 5, unsigned int)
 #define USBDEVFS_GETDRIVER _IOW('U', 8, struct usbdevfs_getdriver)
 #define USBDEVFS_SUBMITURB _IOR('U', 10, struct usbdevfs_urb)
+#define USBDEVFS_SUBMITURB32   _IOR('U', 10, struct usbdevfs_urb32)
 #define USBDEVFS_DISCARDURB_IO('U', 11)
 #define USBDEVFS_REAPURB   _IOW('U', 12, void *)
+#define USBDEVFS_REAPURB32 _IOW('U', 12, u32)
 #define USBDEVFS_REAPURBNDELAY _IOW('U', 13, void *)
+#define USBDEVFS_REAPURBdø©NDELAY32   _IOW('U', 13, u32)
 #define USBDEVFS_DISCSIGNAL_IOR('U', 14, struct 
usbdevfs_disconnectsignal)
 #define USBDEVFS_CLAIMINTERFACE_IOR('U', 15, unsigned int)
 #define USBDEVFS_RELEASEINTERFACE  _IOR('U', 16, unsigned int)
@@ -143,5 +163,4 @@
 #define USBDEVFS_CLEAR_HALT_IOR('U', 21, unsigned int)
 #define USBDEVFS_DISCONNECT_IO('U', 22)
 #define USBDEVFS_CONNECT   _IO('U', 23)
-
 #endif /* _LINUX_USBDEVICE_FS_H */
Index: linux-2.5/fs/compat_ioctl.c
===
--- linux-2.5.orig/fs/compat_ioctl.c2005-01-25 12:08:12.0 -0800
+++ linux-2.5/fs/compat_ioctl.c 2005-01-29 00:59:27.0 -0800
@@ -2570,229 +2570,11 @@
 return sys_ioctl(fd, USBDEVFS_BULK, (unsigned long)p);
 }
 
-/* This needs more work before we can enable it.  Unfortunately
- * because of the fancy asynchronous way URB status/error is written
- * back to userspace, we'll need to fiddle with USB devio internals
- * and/or reimplement entirely the frontend of it ourselves. -DaveM
- *
- * The issue is:
- *
- * When an URB is submitted via usbdevicefs it is put onto an
- * asynchronous queue.  When the URB completes, it may be reaped
- * via another ioctl.  During this reaping the status is written
- * back to userspace along with the length of the transfer.
- *
- * We must translate into 64-bit kernel types so we pass in a kernel
- * space copy of the usbdevfs_urb structure.  This would mean that we
- * must do something to deal with the async entry reaping.  First we
- * have to deal somehow with this transitory memory we've allocated.
- * This is problematic since there are many call sites from which the
- * async entries can be destroyed (and thus when we'd need to free up
- * this kernel memory).  One of which is the close() op of usbdevicefs.
- * To handle that we'd need to make our own 

[PATCH 1/4] readahead: unneeded prev_page assignments

2005-01-29 Thread Oleg Nesterov
There is no point in setting ra-prev_page before 'goto out',
it will be overwritten anyway.

Signed-off-by: Oleg Nesterov [EMAIL PROTECTED]

--- 2.6.11-rc2/mm/readahead.c~  Wed Jan 12 11:44:55 2005
+++ 2.6.11-rc2/mm/readahead.c   Mon Jan 24 20:19:38 2005
@@ -432,7 +432,6 @@ page_cache_readahead(struct address_spac
 
if (newsize == 0 || (ra-flags  RA_FLAG_INCACHE)) {
newsize = 1;
-   ra-prev_page = offset;
goto out;   /* No readahead or file already in cache */
}
/*
@@ -443,7 +442,6 @@ page_cache_readahead(struct address_spac
if ((ra-size == 0  offset == 0)  /* first io and start of file */
|| (ra-size == -1  ra-prev_page == offset - 1)) {
/* First sequential */
-   ra-prev_page  = offset + newsize - 1;
ra-size = get_init_ra_size(newsize, max);
ra-start = offset;
if (!blockable_page_cache_readahead(mapping, filp, offset,
@@ -475,7 +473,6 @@ page_cache_readahead(struct address_spac
 */
if ((offset != (ra-prev_page+1) || (ra-size == 0))) {
ra_off(ra);
-   ra-prev_page  = offset + newsize - 1;
blockable_page_cache_readahead(mapping, filp, offset,
 newsize, ra, 1);
goto out;
@@ -545,7 +542,7 @@ page_cache_readahead(struct address_spac
 
 out:
ra-prev_page = offset + newsize - 1;
-   return(newsize);
+   return newsize;
 }
 
 /*
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 2/4] readahead: cleanup get_next_ra_size

2005-01-29 Thread Oleg Nesterov
get_next_ra_size() can get all info from file_ra_state.

Signed-off-by: Oleg Nesterov [EMAIL PROTECTED]

--- 2.6.11-rc2/mm/readahead.c~  2005-01-26 19:29:49.0 +0300
+++ 2.6.11-rc2/mm/readahead.c   2005-01-27 22:14:39.0 +0300
@@ -85,14 +85,16 @@ static unsigned long get_init_ra_size(un
  * not for each call to readahead.  If a cache miss occured, reduce next I/O
  * size, else increase depending on how close to max we are.
  */
-static unsigned long get_next_ra_size(unsigned long cur, unsigned long max,
-   unsigned long min, unsigned long * flags)
+static unsigned long get_next_ra_size(struct file_ra_state *ra)
 {
+   unsigned long max = get_max_readahead(ra);
+   unsigned long min = get_min_readahead(ra);
+   unsigned long cur = ra-size;
unsigned long newsize;
 
-   if (*flags  RA_FLAG_MISS) {
+   if (ra-flags  RA_FLAG_MISS) {
+   ra-flags = ~RA_FLAG_MISS;
newsize = max((cur - 2), min);
-   *flags = ~RA_FLAG_MISS;
} else if (cur  max / 16) {
newsize = 4 * cur;
} else {
@@ -413,7 +415,7 @@ page_cache_readahead(struct address_spac
 struct file *filp, unsigned long offset,
 unsigned long req_size)
 {
-   unsigned long max, min;
+   unsigned long max;
unsigned long newsize = req_size;
unsigned long block;
 
@@ -427,7 +429,6 @@ page_cache_readahead(struct address_spac
goto out;
 
max = get_max_readahead(ra);
-   min = get_min_readahead(ra);
newsize = min(req_size, max);
 
if (newsize == 0 || (ra-flags  RA_FLAG_INCACHE)) {
@@ -457,8 +458,7 @@ page_cache_readahead(struct address_spac
 * immediately.
 */
if (req_size = max) {
-   ra-ahead_size = get_next_ra_size(ra-size, max, min,
- ra-flags);
+   ra-ahead_size = get_next_ra_size(ra);
ra-ahead_start = ra-start + ra-size;
blockable_page_cache_readahead(mapping, filp,
 ra-ahead_start, ra-ahead_size, ra, 1);
@@ -484,8 +484,7 @@ page_cache_readahead(struct address_spac
 */
 
if (ra-ahead_start == 0) {  /* no ahead window yet */
-   ra-ahead_size = get_next_ra_size(ra-size, max, min,
- ra-flags);
+   ra-ahead_size = get_next_ra_size(ra);
ra-ahead_start = ra-start + ra-size;
block = ((offset + newsize -1) = ra-ahead_start);
if (!blockable_page_cache_readahead(mapping, filp,
@@ -517,9 +516,8 @@ page_cache_readahead(struct address_spac
if ((offset + newsize - 1) = ra-ahead_start) {
ra-start = ra-ahead_start;
ra-size = ra-ahead_size;
-   ra-ahead_start = ra-ahead_start + ra-ahead_size;
-   ra-ahead_size = get_next_ra_size(ra-ahead_size,
- max, min, ra-flags);
+   ra-ahead_start = ra-start + ra-size;
+   ra-ahead_size = get_next_ra_size(ra);
block = ((offset + newsize - 1) = ra-ahead_start);
if (!blockable_page_cache_readahead(mapping, filp,
ra-ahead_start, ra-ahead_size, ra, 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/


[PATCH 3/4] readahead: factor out duplicated code

2005-01-29 Thread Oleg Nesterov
This patch introduces make_ahead_window() function for
simplification of page_cache_readahead.

Signed-off-by: Oleg Nesterov [EMAIL PROTECTED]

--- 2.6.11-rc2/mm/readahead.c~  2005-01-27 22:14:39.0 +0300
+++ 2.6.11-rc2/mm/readahead.c   2005-01-29 15:51:04.0 +0300
@@ -406,6 +406,37 @@ blockable_page_cache_readahead(struct ad
return check_ra_success(ra, nr_to_read, actual);
 }
 
+static int make_ahead_window(struct address_space *mapping, struct file *filp,
+   struct file_ra_state *ra, int force)
+{
+   int block, ret;
+
+   ra-ahead_size = get_next_ra_size(ra);
+   ra-ahead_start = ra-start + ra-size;
+
+   block = force || (ra-prev_page = ra-ahead_start);
+   ret = blockable_page_cache_readahead(mapping, filp,
+   ra-ahead_start, ra-ahead_size, ra, block);
+
+   if (!ret  !force) {
+   /* A read failure in blocking mode, implies pages are
+* all cached. So we can safely assume we have taken
+* care of all the pages requested in this call.
+* A read failure in non-blocking mode, implies we are
+* reading more pages than requested in this call.  So
+* we safely assume we have taken care of all the pages
+* requested in this call.
+*
+* Just reset the ahead window in case we failed due to
+* congestion.  The ahead window will any way be closed
+* in case we failed due to excessive page cache hits.
+*/
+   ra-ahead_start = 0;
+   ra-ahead_size = 0;
+   }
+
+   return ret;
+}
 /*
  * page_cache_readahead is the main function.  If performs the adaptive
  * readahead window size management and submits the readahead I/O.
@@ -415,9 +446,8 @@ page_cache_readahead(struct address_spac
 struct file *filp, unsigned long offset,
 unsigned long req_size)
 {
-   unsigned long max;
-   unsigned long newsize = req_size;
-   unsigned long block;
+   unsigned long max, newsize = req_size;
+   int sequential = (offset == ra-prev_page + 1);
 
/*
 * Here we detect the case where the application is performing
@@ -428,6 +458,7 @@ page_cache_readahead(struct address_spac
if (offset == ra-prev_page  req_size == 1  ra-size != 0)
goto out;
 
+   ra-prev_page = offset;
max = get_max_readahead(ra);
newsize = min(req_size, max);
 
@@ -435,13 +466,16 @@ page_cache_readahead(struct address_spac
newsize = 1;
goto out;   /* No readahead or file already in cache */
}
+
+   ra-prev_page += newsize - 1;
+
/*
 * Special case - first read.  We'll assume it's a whole-file read if
 * at start of file, and grow the window fast.  Or detect first
 * sequential access
 */
if ((ra-size == 0  offset == 0)  /* first io and start of file */
-   || (ra-size == -1  ra-prev_page == offset - 1)) {
+   || (ra-size == -1  sequential)) {
/* First sequential */
ra-size = get_init_ra_size(newsize, max);
ra-start = offset;
@@ -457,12 +491,9 @@ page_cache_readahead(struct address_spac
 * IOs,* thus preventing stalls. so issue the ahead window
 * immediately.
 */
-   if (req_size = max) {
-   ra-ahead_size = get_next_ra_size(ra);
-   ra-ahead_start = ra-start + ra-size;
-   blockable_page_cache_readahead(mapping, filp,
-ra-ahead_start, ra-ahead_size, ra, 1);
-   }
+   if (req_size = max)
+   make_ahead_window(mapping, filp, ra, 1);
+
goto out;
}
 
@@ -471,7 +502,7 @@ page_cache_readahead(struct address_spac
 * partial page reads and first access were handled above,
 * so this must be the next page otherwise it is random
 */
-   if ((offset != (ra-prev_page+1) || (ra-size == 0))) {
+   if (!sequential || (ra-size == 0)) {
ra_off(ra);
blockable_page_cache_readahead(mapping, filp, offset,
 newsize, ra, 1);
@@ -484,27 +515,8 @@ page_cache_readahead(struct address_spac
 */
 
if (ra-ahead_start == 0) {  /* no ahead window yet */
-   ra-ahead_size = get_next_ra_size(ra);
-   ra-ahead_start = ra-start + ra-size;
-   block = ((offset + newsize -1) = ra-ahead_start);
-   if (!blockable_page_cache_readahead(mapping, filp,
-   ra-ahead_start, ra-ahead_size, ra, block)) {
-   /* A read failure in blocking mode, implies pages are
-* all cached. So we can safely assume we 

Re: multiple neighbour cache tables for AF_INET

2005-01-29 Thread Herbert Xu
On Sat, Jan 29, 2005 at 07:46:05AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:
 In article [EMAIL PROTECTED] (at Sat, 29 Jan 2005 09:19:49 +1100), Herbert 
 Xu [EMAIL PROTECTED] says:
 
  IMHO you need to give the user a way to specify which table they want
  to operate on.  If they don't specify one, then the current behaviour
  of choosing the first table found is reasonble.
 
 We have dev. Isn't is sufficient?

It could be used for neigh_add/neigh_delete.  We'll need to add a way
to query whether a given table is the right one for a device.

For dump it isn't the same.  However, perhaps it's not too important
to query a specific table.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 4/4] readahead: cleanup blockable_page_cache_readahead

2005-01-29 Thread Oleg Nesterov
I think that do_page_cache_readahead() can be inlined
in blockable_page_cache_readahead(), this makes the
code a bit more readable in my opinion.

Also makes check_ra_success() static inline.

Signed-off-by: Oleg Nesterov [EMAIL PROTECTED]

--- 2.6.11-rc2/mm/readahead.c~  2005-01-29 15:51:04.0 +0300
+++ 2.6.11-rc2/mm/readahead.c   2005-01-29 16:37:05.0 +0300
@@ -348,8 +348,8 @@ int force_page_cache_readahead(struct ad
  * readahead isn't helping.
  *
  */
-int check_ra_success(struct file_ra_state *ra, unsigned long nr_to_read,
-unsigned long actual)
+static inline int check_ra_success(struct file_ra_state *ra,
+   unsigned long nr_to_read, unsigned long actual)
 {
if (actual == 0) {
ra-cache_hit += nr_to_read;
@@ -394,15 +394,11 @@ blockable_page_cache_readahead(struct ad
 {
int actual;
 
-   if (block) {
-   actual = __do_page_cache_readahead(mapping, filp,
-   offset, nr_to_read);
-   } else {
-   actual = do_page_cache_readahead(mapping, filp,
-   offset, nr_to_read);
-   if (actual == -1)
-   return 0;
-   }
+   if (!block  bdi_read_congested(mapping-backing_dev_info))
+   return 0;
+
+   actual = __do_page_cache_readahead(mapping, filp, offset, nr_to_read);
+
return check_ra_success(ra, nr_to_read, actual);
 }
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 3/4] readahead: factor out duplicated code

2005-01-29 Thread Oleg Nesterov
 This patch introduces make_ahead_window() function for
 simplification of page_cache_readahead.

If you will count this patch acceptable, I'll rediff it against
next mm iteration.

For your convenience here is the code with the patch applied.

int make_ahead_window(mapping, filp, ra, int force)
{
int block, ret;

ra-ahead_size = get_next_ra_size(ra);
ra-ahead_start = ra-start + ra-size;

block = force || (ra-prev_page = ra-ahead_start);
ret = blockable_page_cache_readahead(mapping, filp,
ra-ahead_start, ra-ahead_size, ra, block);

if (!ret  !force) {
ra-ahead_start = 0;
ra-ahead_size = 0;
}

return ret;
}

unsigned long page_cache_readahead(mapping, ra, filp, offset, req_size)
{
unsigned long max, newsize = req_size;
int sequential = (offset == ra-prev_page + 1);

if (offset == ra-prev_page  req_size == 1  ra-size != 0)
goto out;

ra-prev_page = offset;
max = get_max_readahead(ra);
newsize = min(req_size, max);

if (newsize == 0 || (ra-flags  RA_FLAG_INCACHE)) {
newsize = 1;
goto out;
}

ra-prev_page += newsize - 1;

if ((ra-size == 0  offset == 0) ||
(ra-size == -1  sequential)) {
ra-size = get_init_ra_size(newsize, max);
ra-start = offset;
if (!blockable_page_cache_readahead(mapping, filp, offset, 
ra-size, ra, 1))
goto out;

if (req_size = max)
make_ahead_window(mapping, filp, ra, 1);

goto out;
}

if (!sequential || (ra-size == 0)) {
ra_off(ra);
blockable_page_cache_readahead(mapping, filp, offset, newsize, 
ra, 1);
goto out;
}


if (ra-ahead_start == 0) {
if (!make_ahead_window(mapping, filp, ra, 0))
goto out;
}

if (ra-prev_page = ra-ahead_start) {
ra-start = ra-ahead_start;
ra-size = ra-ahead_size;
make_ahead_window(mapping, filp, ra, 0);
}
out:
return newsize;
}
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


I2C updates for 2.4.29

2005-01-29 Thread Jean Delvare
Hi Marcelo, hi all,

I have a number of I2C updates for 2.4.29 waiting. All of them are
rather small and independent, gathered during the 2.4.28 cycle and
already applied to i2c CVS.

Individual patches follow, please apply.

Thanks.

-- 
Jean Delvare
http://khali.linux-fr.org/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 2.4] I2C updates for 2.4.29 (1/3)

2005-01-29 Thread Jean Delvare
Original reports and discussion:
http://archives.andrew.net.au/lm-sensors/msg28512.html
http://archives.andrew.net.au/lm-sensors/msg28581.html

Bottom line:
The bit and pcf i2c algorithms should declare themselves fully I2C
capable, but do not.

Credits go to Ian Campbell for noticing and proposing patches.

This is a backport from Linux 2.6.11-rc1.

--- linux-2.4.29/drivers/i2c/i2c-algo-bit.c.orig2004-02-18 
14:36:31.0 +0100
+++ linux-2.4.29/drivers/i2c/i2c-algo-bit.c 2005-01-29 11:33:33.0 
+0100
@@ -522,8 +522,8 @@
 
 static u32 bit_func(struct i2c_adapter *adap)
 {
-   return I2C_FUNC_SMBUS_EMUL | I2C_FUNC_10BIT_ADDR | 
-  I2C_FUNC_PROTOCOL_MANGLING;
+   return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL |
+  I2C_FUNC_10BIT_ADDR | I2C_FUNC_PROTOCOL_MANGLING;
 }
 
 
--- linux-2.4.29/drivers/i2c/i2c-algo-pcf.c.orig2005-01-29 
11:40:01.0 +0100
+++ linux-2.4.29/drivers/i2c/i2c-algo-pcf.c 2005-01-29 11:33:40.0 
+0100
@@ -435,8 +435,8 @@
 
 static u32 pcf_func(struct i2c_adapter *adap)
 {
-   return I2C_FUNC_SMBUS_EMUL | I2C_FUNC_10BIT_ADDR | 
-  I2C_FUNC_PROTOCOL_MANGLING; 
+   return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL |
+  I2C_FUNC_10BIT_ADDR | I2C_FUNC_PROTOCOL_MANGLING;
 }
 
 /* -exported algorithm data: - */


-- 
Jean Delvare
http://khali.linux-fr.org/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] Fix large allocation in nfsd init

2005-01-29 Thread Anton Blanchard

Hi Neil,

 Given that the purpose of this order-5 allocation is to provide
 storage for 1024 struct svc_cacherep structs, it would seem that a
 better approach would be to just do 1024 kmallocs.
 
 I'll try to knock a patch together in next week sometime.

That works for me.

Anton
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 2.4] I2C updates for 2.4.29 (2/3)

2005-01-29 Thread Jean Delvare
While editing i2c-algo-bit.c and i2c-algo-pcf.c (see 1/3 of this patch
set), I noticed that both files include header files they do not need at
all (namely linux/ioport.h and asm/uaccess.h). The following patch
cleans this, additionally bringing the files in line with what we have
in i2c CVS (thus the blank lines changes).

--- linux-2.4.29/drivers/i2c/i2c-algo-bit.c.orig2005-01-29 
11:33:33.0 +0100
+++ linux-2.4.29/drivers/i2c/i2c-algo-bit.c 2005-01-29 11:35:39.0 
+0100
@@ -28,14 +28,12 @@
 #include linux/delay.h
 #include linux/slab.h
 #include linux/init.h
-#include asm/uaccess.h
-#include linux/ioport.h
 #include linux/errno.h
 #include linux/sched.h
-
 #include linux/i2c.h
 #include linux/i2c-algo-bit.h
 
+
 /* - global defines --- */
 #define DEB(x) if (i2c_debug=1) x;
 #define DEB2(x) if (i2c_debug=2) x;
--- linux-2.4.29/drivers/i2c/i2c-algo-pcf.c.orig2005-01-29 
11:33:40.0 +0100
+++ linux-2.4.29/drivers/i2c/i2c-algo-pcf.c 2005-01-29 11:35:45.0 
+0100
@@ -32,15 +32,13 @@
 #include linux/delay.h
 #include linux/slab.h
 #include linux/init.h
-#include asm/uaccess.h
-#include linux/ioport.h
 #include linux/errno.h
 #include linux/sched.h
-
 #include linux/i2c.h
 #include linux/i2c-algo-pcf.h
 #include i2c-pcf8584.h
 
+
 /* - global defines --- */
 #define DEB(x) if (i2c_debug=1) x
 #define DEB2(x) if (i2c_debug=2) x


-- 
Jean Delvare
http://khali.linux-fr.org/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: Fwd: Re: flush_cache_page()

2005-01-29 Thread Russell King
On Tue, Jan 11, 2005 at 04:07:09PM -0800, Linus Torvalds wrote:
 On Tue, 11 Jan 2005, Russell King wrote:
  Any responses on this?  Didn't get any last time I mailed this out.
 
 I don't have any real objections. I'd like it verified that gcc can
 compile away all the overhead on the architectures that don't use the pfn, 
 since page_to_pfn() can be a bit expensive otherwise.. But I don't see 
 anything wrong with the approach.

Thanks for the response.  However, apart from Ralph, Paul and yourself,
it seems none of the other architecture maintainers care about this
patch - the original mail was BCC'd to the architecture list.  Maybe
that's an implicit acceptance of this patch, I don't know.

I do know that page_to_pfn() will generate code on some platforms which
don't require it due to them declaring flush_cache_page() as a function.
However, I assert that if they don't need this overhead, that's for them
to fix up.  I don't know all their quirks so it isn't something I can
tackle.

In other words, unless I actually receive some real help from the other
architecture maintainers on this to address your concerns, ARM version 6
CPUs with aliasing L1 caches (== 16K) will remain a dead dodo with
mainline Linux kernels.

(This mail BCC'd to the architecture list again in the vain hope that
someone will offer assistance.)

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA  - http://pcmcia.arm.linux.org.uk/
 2.6 Serial core


[PATCH 2.4] I2C updates for 2.4.29 (3/3)

2005-01-29 Thread Jean Delvare
Original discussion:
http://archives.andrew.net.au/lm-sensors/msg29038.html
http://archives.andrew.net.au/lm-sensors/msg29041.html

Bottom line:
The id member of the i2c_client structure was discarded in Linux 2.6
due to a lack of consistent use and overall need. While we of course
won't backport this to Linux 2.4 so as to not break compatibility with
existing 2.4 drivers, it still seems wise to update the documentation so
that new drivers written for Linux 2.4 today (*sigh*) do not rely on it.

--- linux-2.4.29/Documentation/i2c/writing-clients.orig 2005-01-21 
21:51:06.0 +0100
+++ linux-2.4.29/Documentation/i2c/writing-clients  2005-01-23 
18:21:47.0 +0100
@@ -380,9 +380,6 @@
 
 For now, you can ignore the `flags' parameter. It is there for future use.
 
-  /* Unique ID allocation */
-  static int foo_id = 0;
-
   int foo_detect_client(struct i2c_adapter *adapter, int address, 
 unsigned short flags, int kind)
   {
@@ -518,7 +515,6 @@
 data-type = kind;
 /* SENSORS ONLY END */
 
-new_client-id = foo_id++; /* Automatically unique */
 data-valid = 0; /* Only if you use this field */
 init_MUTEX(data-update_lock); /* Only if you use this field */
 


-- 
Jean Delvare
http://khali.linux-fr.org/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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 4081] New: OpenOffice crashes while starting due to a threading error

2005-01-29 Thread Richard Hughes
On Fri, 28 Jan 2005 15:57:13 -0800, Stephen Hemminger wrote:
 Note: on 2.6.10
   /dev/dri/card0  crw-rw-rw-
 on 2.6.11-rc2
   /dev/dri/card0  crw-rw
   /dev/dri/card1  crw-rw
 
 Changing permissions seems to fix (it for startup), will try more and see
 if udev remembers not to turn them back.

Me too. (2.6.11-rc2-bk3, openoffice.org-1.1.3) I straced soffice and found
it hanging on /dev/dri:

geteuid32() = 500
stat64(/dev/dri, {st_mode=S_IFDIR|0755, st_size=80, ...}) = 0
stat64(/dev/dri/card14, 0xbff9c8bc)   = -1 ENOENT (No such file or directory)
munmap(0x9b4838, 8192)  = -1 EINVAL (Invalid argument)
munmap(0x949e248, 322082)   = -1 EINVAL (Invalid argument)
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++

and with a chmod a+rw /dev/dri/card* everything is okay until I reboot,
and it defaults back to crw-rw

What is at fault? Certainly oo shouldn't just seg-fault, but should the
permissions on /dev/dri/card* be crw-rw or crw-rw-rw-?

Richard Hughes

-- 

http://www.hughsie.com/PUBLIC-KEY


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] Make User Mode Linux compile in 2.6.11-rc2-bk6.

2005-01-29 Thread Rob Landley
User Mode Linux doesn't compile in 2.6.11-rc2-bk6.  Here's the change I
made to sys_call_table.c to make it compile.  (I ran the result and brought
up a shell.)

We're really close to finally having a usable UML kernel in mainline.
2.6.9's ARCH=um built but was very unstable, 2.6.10 didn't even build
for me, but 2.6.11-rc1-mm2 builds fine unmodified, and ran my tests
correctly to completion.

Here's the patch.  Nothing fancy, it simply removes or stubs out all the
syscalls the compiler complains about.

Rob

Signed-off-by: Rob Landley [EMAIL PROTECTED]

--- linux-2.6.10/arch/um/kernel/sys_call_table.c2005-01-28 
21:20:38.0 -0600
+++ linux-2.6.10-um/arch/um/kernel/sys_call_table.c 2005-01-28 
21:40:30.735892144 -0600
@@ -20,7 +20,7 @@
 #define NFSSERVCTL sys_ni_syscall
 #endif
 
-#define LAST_GENERIC_SYSCALL __NR_vperfctr_read
+#define LAST_GENERIC_SYSCALL (NR_syscalls-1)
 
 #if LAST_GENERIC_SYSCALL  LAST_ARCH_SYSCALL
 #define LAST_SYSCALL LAST_GENERIC_SYSCALL
@@ -52,13 +52,7 @@
 extern syscall_handler_t sys_mbind;
 extern syscall_handler_t sys_get_mempolicy;
 extern syscall_handler_t sys_set_mempolicy;
-extern syscall_handler_t sys_sys_kexec_load;
 extern syscall_handler_t sys_sys_setaltroot;
-extern syscall_handler_t sys_vperfctr_open;
-extern syscall_handler_t sys_vperfctr_control;
-extern syscall_handler_t sys_vperfctr_unlink;
-extern syscall_handler_t sys_vperfctr_iresume;
-extern syscall_handler_t sys_vperfctr_read;
 
 syscall_handler_t *sys_call_table[] = {
[ __NR_restart_syscall ] = (syscall_handler_t *) sys_restart_syscall,
@@ -273,7 +267,7 @@
[ __NR_mq_timedreceive ] = (syscall_handler_t *) sys_mq_timedreceive,
[ __NR_mq_notify ] = (syscall_handler_t *) sys_mq_notify,
[ __NR_mq_getsetattr ] = (syscall_handler_t *) sys_mq_getsetattr,
-   [ __NR_sys_kexec_load ] = (syscall_handler_t *) sys_kexec_load,
+   [ __NR_sys_kexec_load ] = (syscall_handler_t *) sys_ni_syscall,
[ __NR_waitid ] = (syscall_handler_t *) sys_waitid,
 #if 0
[ __NR_sys_setaltroot ] = (syscall_handler_t *) sys_sys_setaltroot,
@@ -281,11 +275,6 @@
[ __NR_add_key ] = (syscall_handler_t *) sys_add_key,
[ __NR_request_key ] = (syscall_handler_t *) sys_request_key,
[ __NR_keyctl ] = (syscall_handler_t *) sys_keyctl,
-   [ __NR_vperfctr_open ] = (syscall_handler_t *) sys_vperfctr_open,
-   [ __NR_vperfctr_control ] = (syscall_handler_t *) sys_vperfctr_control,
-   [ __NR_vperfctr_unlink ] = (syscall_handler_t *) sys_vperfctr_unlink,
-   [ __NR_vperfctr_iresume ] = (syscall_handler_t *) sys_vperfctr_iresume,
-   [ __NR_vperfctr_read ] = (syscall_handler_t *) sys_vperfctr_read,
 
ARCH_SYSCALLS
[ LAST_SYSCALL + 1 ... NR_syscalls ] = 
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: Possible bug in keyboard.c (2.6.10)

2005-01-29 Thread Roman Zippel
Hi,

On Fri, 28 Jan 2005, Vojtech Pavlik wrote:

 I'm very sorry about the locking, but the thing grew up in times of
 kernel 2.0, which didn't require any locking. There are a few possible
 races with device registration/unregistration, and it's on my list to
 fix that, however under normal operation there shouldn't be any need for
 locks, as there are no complex structures built that'd become
 inconsistent. 

I wouldn't say that there is no need for that, but that these events are 
rather rare, but it can happen. Unfortunately the lack of locking is all 
over the keyboard/vc/tty layer. It would have been nice if input had 
introduced some improvement here.
This seriously becomes a problem as soon we want to allow the user to 
dynamically attach/detach devices.

  I tried to find a few times to find any discussion about the input
  layer design, but I couldn't find anything.
 
 You have to search in very old archives. There was quite a lot of it,
 and it was going off on a lot of tangents. In the end, I just wrote it.

How old and which archives?

  - a single input device structure for all types: this structure is quite 
  big, where most of its contents is irrelevant for most devices.
 
 I actually think this is a big plus. 
 
 Real word devices cannot be confined into predefined structures, as
 hardware develops, mice get more buttons, wheels, force feedback, 

That doesn't necessarilly mean we have to pack everything into a single 
structure. E.g. we present pci boards with multiple functions as multiple 
devices, the same can be done for input devices. More important is that 
kernel drivers only expect a certain class of devices, e.g. the keyboard 
driver only needs the keyboard related parts and would also allow us to 
add more keyboard specific callbacks instead of sending events.

  Some of my favourites in the input layer:
  - the keyboard sound/led handling: the keyboard driver basically fakes 
  events for the device and input_event() is clever enough to also tell 
  the device about it. This is quite an abuse of event system for general 
  device/driver communication.
 
 The intention here is that we have two types of events, input and
 output. Most events are input (REL, ABS, ...), while some travel the
 opposite direction. For simplicity, the interface is the same -
 input_event(), which then, based on the event type decides where to
 forward it - whether up or down the stream (or both, where other users
 of the device may be interested in the change).

This is rather a hint that the abstraction is wrong, e.g. why not send 
sound events to the pckbd _handler_? A device should just send input 
events and handlers handle them and with sysfs we should actually rename 
the latter to input_drivers (it's less confusing this way).

Some other problems I have with the current design:
- unified keyboard/mouse device: one rather annoying problem, which is 
neither solved by the input system or the linuxconsole patches, is that 
one can't use keyboards with different mappings (e.g. german and english 
is what I have here). I have a patch which makes the keymap data more 
dynamic and assigns it to keyboard device, which has the positive side 
effect that all keyboards don't have to send the same keycodes anymore 
(and we don't have to break all the keyboards anymore which don't use AT 
style keycodes).
I'm not convinced we need this unifying layer in the kernel. We need a 
keyboard driver in the kernel for the tty layer, but we have no kernel 
user for mouse or joystick events, so why not do some simple preprocessing 
and leave the rest to userspace?
- kbd raw mode: the emulation code should really go. I'm playing with the 
idea of merging input and serio infrastructure (or basically turning serio 
devices into (raw) input devices), the differences are not that big (at 
least the management part, the event path might still differ). This way 
the keyboard driver can ask the kbd device for the raw device and read 
the events directly.

  - fine grained matching/filtering: I have no idea why the input layer has 
  to do this down to the single event instead of just the event type.
 
 I wonder what do you mean by this, the layer itself doesn't have any
 codepaths dependent directly on event code, just on the types.

E.g. also input_match_device.

 If you wonder why the input_event() function checks whether the event
 generated by a device really is possible for that device and ignores it
 if not, that's to make the drivers life easier by, in the example of a
 PS/2 mouse always reporting the state of the middle button, even when
 the PS/2 mouse is a 2-button mouse. The driver only needs to say that
 the middle button doesn't exist in the bitmap setup and the packet
 processing routine doesn't need to care about it.

I don't really see what's the point of this.
Such functionality is only needed by the minority of drivers, but 
increases setup complexity, bloats structures and adds unnecessary runtime 
test 

Re: [Bug 4081] New: OpenOffice crashes while starting due to a threading error

2005-01-29 Thread Bernd Eckenfels
In article [EMAIL PROTECTED] you wrote:
 stat64(/dev/dri/card14, 0xbff9c8bc)   = -1 ENOENT (No such file or 
 directory)

 What is at fault? Certainly oo shouldn't just seg-fault, but should the
 permissions on /dev/dri/card* be crw-rw or crw-rw-rw-?

it is not a permission thing, it tells you, that you have not card14 - and i
dont know the dri interface but it looks unlikely that there ever will be
one .)

Greetings
Bernd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: OpenOffice crashes due to incorrect access permissions on /dev/dri/card*

2005-01-29 Thread Richard Hughes
On Sat, 29 Jan 2005 12:49:16 +, Richard Hughes wrote:
 Note, that strace glxgears gives exactly the same output, going from 0 to
 14 and then seg-faulting, so it's *not just a oo problem*.

I know it's bad to answer your own post, but here goes.

I changed my /etc/udev/permissions.d/50-udev.permissions config to read:

dri/*:root:root:0666

changing it from 

dri/*:root:root:0660

And oowriter and glxgears work from bootup. Shall I file a bug with udev?

Richard Hughes

-- 

http://www.hughsie.com/PUBLIC-KEY


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[2.6 patch] drivers/block/aoe/aoechr.c cleanups

2005-01-29 Thread Adrian Bunk
This patch contains the following cleanups:
- make the needlessly global struct aoe_fops static
- #if 0 the unused global function aoechr_hdump

Signed-off-by: Adrian Bunk [EMAIL PROTECTED]

---

 drivers/block/aoe/aoechr.c |6 +-
 1 files changed, 5 insertions(+), 1 deletion(-)

--- linux-2.6.11-rc2-mm1-full/drivers/block/aoe/aoechr.c.old2005-01-29 
13:43:34.0 +0100
+++ linux-2.6.11-rc2-mm1-full/drivers/block/aoe/aoechr.c2005-01-29 
13:44:16.0 +0100
@@ -99,6 +99,8 @@
up(emsgs_sema);
 }
 
+#if 0
+
 #define PERLINE 16
 void
 aoechr_hdump(char *buf, int n)
@@ -134,6 +136,8 @@
kfree(fbuf);
 }
 
+#endif  /*  0  */
+
 static ssize_t
 aoechr_write(struct file *filp, const char __user *buf, size_t cnt, loff_t 
*offp)
 {
@@ -233,7 +237,7 @@
}
 }
 
-struct file_operations aoe_fops = {
+static struct file_operations aoe_fops = {
.write = aoechr_write,
.read = aoechr_read,
.open = aoechr_open,

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[2.6 patch] cfq-iosched.c: make some code static

2005-01-29 Thread Adrian Bunk
This patch makes some needlessly global code static.

Signed-off-by: Adrian Bunk [EMAIL PROTECTED]

--- linux-2.6.11-rc2-mm1-full/drivers/block/cfq-iosched.c.old   2005-01-29 
14:05:30.0 +0100
+++ linux-2.6.11-rc2-mm1-full/drivers/block/cfq-iosched.c   2005-01-29 
14:05:49.0 +0100
@@ -1790,7 +1790,7 @@
.store  = cfq_attr_store,
 };
 
-struct kobj_type cfq_ktype = {
+static struct kobj_type cfq_ktype = {
.sysfs_ops  = cfq_sysfs_ops,
.default_attrs  = default_attrs,
 };
@@ -1819,7 +1819,7 @@
.elevator_owner =   THIS_MODULE,
 };
 
-int cfq_init(void)
+static int cfq_init(void)
 {
int ret;
 

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[2.6 patch] drivers/block/paride/ cleanups

2005-01-29 Thread Adrian Bunk
The patch below does the following cleanups in each if the five changed
C files:
- #ifndef MODULE: remove unused setup function
- make a needlessly global struct static
- pf.c: pf_init_units can be static and __init

After this cleanup, setup.h is completely unuse and therefore removed.

Signed-off-by: Adrian Bunk [EMAIL PROTECTED]

---

 drivers/block/paride/pcd.c   |   22 ---
 drivers/block/paride/pd.c|   23 ---
 drivers/block/paride/pf.c|   25 +---
 drivers/block/paride/pg.c|   21 --
 drivers/block/paride/pt.c|   22 ---
 drivers/block/paride/setup.h |   69 ---
 6 files changed, 6 insertions(+), 176 deletions(-)

--- linux-2.6.11-rc2-mm1-full/drivers/block/paride/pcd.c.old2005-01-29 
14:10:23.0 +0100
+++ linux-2.6.11-rc2-mm1-full/drivers/block/paride/pcd.c2005-01-29 
14:10:50.0 +0100
@@ -142,26 +142,6 @@
 
 static spinlock_t pcd_lock;
 
-#ifndef MODULE
-
-#include setup.h
-
-static STT pcd_stt[6] = {
-   {drive0, 6, drive0},
-   {drive1, 6, drive1},
-   {drive2, 6, drive2},
-   {drive3, 6, drive3},
-   {disable, 1, disable},
-   {nice, 1, nice}
-};
-
-void pcd_setup(char *str, int *ints)
-{
-   generic_setup(pcd_stt, 6, str);
-}
-
-#endif
-
 module_param(verbose, bool, 0644);
 module_param(major, int, 0);
 module_param(name, charp, 0);
@@ -218,7 +198,7 @@
struct gendisk *disk;
 };
 
-struct pcd_unit pcd[PCD_UNITS];
+static struct pcd_unit pcd[PCD_UNITS];
 
 static char pcd_scratch[64];
 static char pcd_buffer[2048];  /* raw block buffer */
--- linux-2.6.11-rc2-mm1-full/drivers/block/paride/pd.c.old 2005-01-29 
14:11:08.0 +0100
+++ linux-2.6.11-rc2-mm1-full/drivers/block/paride/pd.c 2005-01-29 
14:11:45.0 +0100
@@ -157,27 +157,6 @@
 
 static DEFINE_SPINLOCK(pd_lock);
 
-#ifndef MODULE
-
-#include setup.h
-
-static STT pd_stt[7] = {
-   {drive0, 8, drive0},
-   {drive1, 8, drive1},
-   {drive2, 8, drive2},
-   {drive3, 8, drive3},
-   {disable, 1, disable},
-   {cluster, 1, cluster},
-   {nice, 1, nice}
-};
-
-void pd_setup(char *str, int *ints)
-{
-   generic_setup(pd_stt, 7, str);
-}
-
-#endif
-
 module_param(verbose, bool, 0);
 module_param(major, int, 0);
 module_param(name, charp, 0);
@@ -255,7 +234,7 @@
struct gendisk *gd;
 };
 
-struct pd_unit pd[PD_UNITS];
+static struct pd_unit pd[PD_UNITS];
 
 static char pd_scratch[512];   /* scratch block buffer */
 
--- linux-2.6.11-rc2-mm1-full/drivers/block/paride/pf.c.old 2005-01-29 
14:11:57.0 +0100
+++ linux-2.6.11-rc2-mm1-full/drivers/block/paride/pf.c 2005-01-29 
14:13:16.0 +0100
@@ -156,27 +156,6 @@
 
 static spinlock_t pf_spin_lock;
 
-#ifndef MODULE
-
-#include setup.h
-
-static STT pf_stt[7] = {
-   {drive0, 7, drive0},
-   {drive1, 7, drive1},
-   {drive2, 7, drive2},
-   {drive3, 7, drive3},
-   {disable, 1, disable},
-   {cluster, 1, cluster},
-   {nice, 1, nice}
-};
-
-void pf_setup(char *str, int *ints)
-{
-   generic_setup(pf_stt, 7, str);
-}
-
-#endif
-
 module_param(verbose, bool, 0644);
 module_param(major, int, 0);
 module_param(name, charp, 0);
@@ -256,7 +235,7 @@
struct gendisk *disk;
 };
 
-struct pf_unit units[PF_UNITS];
+static struct pf_unit units[PF_UNITS];
 
 static int pf_identify(struct pf_unit *pf);
 static void pf_lock(struct pf_unit *pf, int func);
@@ -290,7 +269,7 @@
.media_changed  = pf_check_media,
 };
 
-void pf_init_units(void)
+static void __init pf_init_units(void)
 {
struct pf_unit *pf;
int unit;
--- linux-2.6.11-rc2-mm1-full/drivers/block/paride/pg.c.old 2005-01-29 
14:13:47.0 +0100
+++ linux-2.6.11-rc2-mm1-full/drivers/block/paride/pg.c 2005-01-29 
14:14:10.0 +0100
@@ -167,25 +167,6 @@
 
 #include asm/uaccess.h
 
-#ifndef MODULE
-
-#include setup.h
-
-static STT pg_stt[5] = {
-   {drive0, 6, drive0},
-   {drive1, 6, drive1},
-   {drive2, 6, drive2},
-   {drive3, 6, drive3},
-   {disable, 1, disable}
-};
-
-void pg_setup(char *str, int *ints)
-{
-   generic_setup(pg_stt, 5, str);
-}
-
-#endif
-
 module_param(verbose, bool, 0644);
 module_param(major, int, 0);
 module_param(name, charp, 0);
@@ -237,7 +218,7 @@
char name[PG_NAMELEN];  /* pg0, pg1, ... */
 };
 
-struct pg devices[PG_UNITS];
+static struct pg devices[PG_UNITS];
 
 static int pg_identify(struct pg *dev, int log);
 
--- linux-2.6.11-rc2-mm1-full/drivers/block/paride/pt.c.old 2005-01-29 
14:14:21.0 +0100
+++ linux-2.6.11-rc2-mm1-full/drivers/block/paride/pt.c 2005-01-29 
14:14:38.0 +0100
@@ -150,26 +150,6 @@
 
 #include asm/uaccess.h
 
-#ifndef MODULE
-
-#include setup.h
-
-static STT pt_stt[5] = {
-   {drive0, 6, drive0},
-   {drive1, 6, drive1},
-   {drive2, 6, drive2},
-   {drive3, 6, drive3},
-   {disable, 1, disable}
-};
-
-void
-pt_setup(char *str, int *ints)
-{
-   

[2.6 patch] deadline-iosched.c: make a struct static

2005-01-29 Thread Adrian Bunk
This patch makes a needlessly global struct static.

Signed-off-by: Adrian Bunk [EMAIL PROTECTED]

--- linux-2.6.11-rc2-mm1-full/drivers/block/deadline-iosched.c.old  
2005-01-29 14:07:00.0 +0100
+++ linux-2.6.11-rc2-mm1-full/drivers/block/deadline-iosched.c  2005-01-29 
14:07:10.0 +0100
@@ -909,7 +909,7 @@
.store  = deadline_attr_store,
 };
 
-struct kobj_type deadline_ktype = {
+static struct kobj_type deadline_ktype = {
.sysfs_ops  = deadline_sysfs_ops,
.default_attrs  = default_attrs,
 };

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: [Wbsd-devel] [PATCH 540] MMC_WBSD depends on ISA

2005-01-29 Thread Pierre Ossman
Pierre Ossman wrote:
Geert Uytterhoeven wrote:
MMC_WBSD depends on ISA (needs isa_virt_to_bus())

Thanks. Shouldn't have missed something so obvious :)
Russell, can you fix this in your next merge?
Russell, please undo this patch. isa_virt_to_bus() is not dependent on 
CONFIG_ISA. It causes problems on x86_64 platforms which cannot enable 
ISA support.

Rgds
Pierre
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[2.6 patch] drivers/block/cciss*: misc cleanups

2005-01-29 Thread Adrian Bunk
This patch contains the following cleanups:
- make some needlesly global code static
- cciss_scsi.c: remove the unused global function cciss_scsi_info
- cciss.c:
  - init_cciss_module - cciss_init
  - cleanup_cciss_module - cciss_cleanup

Signed-off-by: Adrian Bunk [EMAIL PROTECTED]

---

 drivers/block/cciss.c  |   15 +--
 drivers/block/cciss_scsi.c |   35 ---
 drivers/block/cciss_scsi.h |1 -
 3 files changed, 9 insertions(+), 42 deletions(-)

--- linux-2.6.11-rc2-mm1-full/drivers/block/cciss_scsi.h.old2005-01-29 
13:50:28.0 +0100
+++ linux-2.6.11-rc2-mm1-full/drivers/block/cciss_scsi.h2005-01-29 
13:51:05.0 +0100
@@ -39,7 +39,6 @@
 #define SCSI_CCISS_CAN_QUEUE 2
 
 /* 
-   info:   cciss_scsi_info,\
 
 Note, cmd_per_lun could give us some trouble, so I'm setting it very low.
 Likewise, SCSI_CCISS_CAN_QUEUE is set very conservatively.
--- linux-2.6.11-rc2-mm1-full/drivers/block/cciss_scsi.c.old2005-01-29 
13:50:40.0 +0100
+++ linux-2.6.11-rc2-mm1-full/drivers/block/cciss_scsi.c2005-01-29 
13:51:05.0 +0100
@@ -53,9 +53,7 @@
int cmd_type);
 
 
-const char *cciss_scsi_info(struct Scsi_Host *sa);
-
-int cciss_scsi_proc_info(
+static int cciss_scsi_proc_info(
struct Scsi_Host *sh,
char *buffer, /* data buffer */
char **start,  /* where data in buffer starts */
@@ -63,7 +61,7 @@
int length,/* length of data in buffer */
int func); /* 0 == read, 1 == write */
 
-int cciss_scsi_queue_command (struct scsi_cmnd *cmd, 
+static int cciss_scsi_queue_command (struct scsi_cmnd *cmd, 
void (* done)(struct scsi_cmnd *));
 
 static struct cciss_scsi_hba_t ccissscsi[MAX_CTLR] = {
@@ -712,8 +710,6 @@
return 1;
 }
 
-static void __exit cleanup_cciss_module(void);
-
 static void
 cciss_unmap_one(struct pci_dev *pdev,
CommandList_struct *cp,
@@ -1114,7 +1110,7 @@
 }
 
 
-int
+static int
 cciss_scsi_proc_info(struct Scsi_Host *sh,
char *buffer, /* data buffer */
char **start,  /* where data in buffer starts */
@@ -1149,29 +1145,6 @@
buffer, length);
 } 
 
-/* this is via the generic proc support */
-const char *
-cciss_scsi_info(struct Scsi_Host *sa)
-{
-   static char buf[300];
-   ctlr_info_t *ci;
-
-   /* probably need to work on putting a bit more info in here... */
-   /* this is output via the /proc filesystem. */
-
-   ci = (ctlr_info_t *) sa-hostdata[0];
-
-   sprintf(buf, %s %c%c%c%c\n,
-   ci-product_name, 
-   ci-firm_ver[0],
-   ci-firm_ver[1],
-   ci-firm_ver[2],
-   ci-firm_ver[3]);
-
-   return buf; 
-}
-
-
 /* cciss_scatter_gather takes a struct scsi_cmnd, (cmd), and does the pci 
dma mapping  and fills in the scatter gather entries of the 
cciss command, cp. */
@@ -1225,7 +1198,7 @@
 }
 
 
-int 
+static int 
 cciss_scsi_queue_command (struct scsi_cmnd *cmd, void (* done)(struct 
scsi_cmnd *))
 {
ctlr_info_t **c;
--- linux-2.6.11-rc2-mm1-full/drivers/block/cciss.c.old 2005-01-29 
13:50:55.0 +0100
+++ linux-2.6.11-rc2-mm1-full/drivers/block/cciss.c 2005-01-29 
14:25:31.0 +0100
@@ -61,7 +61,7 @@
 #include linux/cciss_ioctl.h
 
 /* define the PCI info for the cards we can control */
-const struct pci_device_id cciss_pci_device_id[] = {
+static const struct pci_device_id cciss_pci_device_id[] = {
{ PCI_VENDOR_ID_COMPAQ, PCI_DEVICE_ID_COMPAQ_CISS,
0x0E11, 0x4070, 0, 0, 0},
{ PCI_VENDOR_ID_COMPAQ, PCI_DEVICE_ID_COMPAQ_CISSB,
@@ -2878,7 +2878,7 @@
  *  This is it.  Register the PCI driver information for the cards we control
  *  the OS will call our registered routines when it finds one of our cards. 
  */
-int __init cciss_init(void)
+static int __init cciss_init(void)
 {
printk(KERN_INFO DRIVER_NAME \n);
 
@@ -2886,12 +2886,7 @@
return pci_module_init(cciss_pci_driver);
 }
 
-static int __init init_cciss_module(void)
-{
-   return ( cciss_init());
-}
-
-static void __exit cleanup_cciss_module(void)
+static void __exit cciss_cleanup(void)
 {
int i;
 
@@ -2909,5 +2904,5 @@
remove_proc_entry(cciss, proc_root_driver);
 }
 
-module_init(init_cciss_module);
-module_exit(cleanup_cciss_module);
+module_init(cciss_init);
+module_exit(cciss_cleanup);

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: [Wbsd-devel] [PATCH 540] MMC_WBSD depends on ISA

2005-01-29 Thread Christoph Hellwig
On Sat, Jan 29, 2005 at 02:37:39PM +0100, Pierre Ossman wrote:
 Pierre Ossman wrote:
 Geert Uytterhoeven wrote:
 
 MMC_WBSD depends on ISA (needs isa_virt_to_bus())
 
 
 
 Thanks. Shouldn't have missed something so obvious :)
 
 Russell, can you fix this in your next merge?
 
 
 Russell, please undo this patch. isa_virt_to_bus() is not dependent on 
 CONFIG_ISA. It causes problems on x86_64 platforms which cannot enable 
 ISA support.
 
 Rgds
 Pierre
 -
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
---end quoted text---
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] OProfile: Fix oops on undetected CPU type

2005-01-29 Thread John Levon
On Fri, Jan 28, 2005 at 12:06:19PM -0700, Zwane Mwaikambo wrote:

 = drivers/oprofile/oprofile_files.c 1.7 vs edited =
 --- 1.7/drivers/oprofile/oprofile_files.c 2005-01-04 19:48:23 -07:00
 +++ edited/drivers/oprofile/oprofile_files.c  2005-01-28 11:36:25 -07:00
 @@ -63,7 +63,9 @@ static struct file_operations pointer_si
  
  static ssize_t cpu_type_read(struct file * file, char __user * buf, size_t 
 count, loff_t * offset)
  {
 - return oprofilefs_str_to_user(oprofile_ops.cpu_type, buf, count, 
 offset);
 + if (oprofile_ops.cpu_type)
 + return oprofilefs_str_to_user(oprofile_ops.cpu_type, buf, 
 count, offset);
 + return -EIO;

This is wrong: you need to investigate why .cpu_type isn't set: in
particular, it should have fallen back to timer mode.
oprofile_arch_init() should have returned -ENODEV, and that should have
set timer mode.

Unfortunately bkcvs seems out of date so I can't even look at this
myself.

john
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


system calls

2005-01-29 Thread Rodrigo Ramos
Hi,


I would like to know how many groups of system calls are there at Linux
2.4 and 2.6? Where can I find these informations in the Kernel?


Best Regards,
Rodrigo Ramos
www.triforsec.com.br

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: Fwd: Re: flush_cache_page()

2005-01-29 Thread James Bottomley
On Sat, 2005-01-29 at 11:37 +, Russell King wrote:
 Thanks for the response.  However, apart from Ralph, Paul and yourself,
 it seems none of the other architecture maintainers care about this
 patch - the original mail was BCC'd to the architecture list.  Maybe
 that's an implicit acceptance of this patch, I don't know.

Well, OK, I'll try to answer for parisc, since we have huge VIPT
aliasing caches as well.

Right now, we have a scheme in flush_cache_page to make sure it's only
called when necessary (cache flushes are expensive for us and show up as
the primary cpu consumer in all of our profiles).  Our scheme is to see
if a translation exists for the page and skip the flush if it doesn't.

Obviously, like MIPS, we're also walking the page tables without
locking...

Looking at the callers of this, it seems it would be very unlikely to
call this with a missing translation, in that case, we can use the pfn
to flush the page through a temporary alias space instead and just take
the odd hit if no translation exists.  

 In other words, unless I actually receive some real help from the other
 architecture maintainers on this to address your concerns, ARM version 6
 CPUs with aliasing L1 caches (== 16K) will remain a dead dodo with
 mainline Linux kernels.

I've probably been told and forgotten, but what problems do you have
with your VIPT (Arm 6 is VIPT, not VIVT, right?) cache 16k which we
don't have with our 4MB VIPT caches on pa (which work, but cause us
grief with enormous amounts of flushing)?

James



RE: [Discuss][i386] Platform SMIs and their interferance with tsc based delay calibration

2005-01-29 Thread Pallipadi, Venkatesh
 

-Original Message-
From: Andrew Morton [mailto:[EMAIL PROTECTED] 
Subject: Re: [Discuss][i386] Platform SMIs and their 
interferance with tsc based delay calibration


Please don't send emails which contain 500-column lines?

Sorry. Something got messed up during cut and paste onto my mailer.

  Solution:
  The patch below makes the calibration routine aware of 
asynchronous events
 like SMIs. We increase the delay calibration time and also 
identify any
 significant errors (greater than 12.5%) in the calibration 
and notify it
 to user. Like to know your comments on this.

I find calibrate_delay_tsc() quite confusing.  Are you sure that the
variable names are correct?

 + tsc_rate_max = (post_end - pre_start) / DELAY_CALIBRATION_TICKS;
 + tsc_rate_min = (pre_end - post_start) / DELAY_CALIBRATION_TICKS;

that looks strange.  I'm sure it all makes sense if one understands the
algorithm, but it shouldn't be this hard.  Please reissue the 
patch with
adequate comments which describe what the code is doing.


I will resend the patch soon with more comments. I think the variable 
names here are bit confusing.

Shouldn't calibrate_delay_tsc() be __devinit?  (That may 
generate warnings
from reference_discarded.pl, but they're false positives)


From a maintainability POV it's not good that x86 is no longer 
using the
generic calibrate_delay() code.  Can you rework the code so that all
architectures must implement arch_calibrate_delay(), then 
provide stubs for
all except x86?  After all, other architectures/platforms may 
have the same
problem.


Agreed. I will add a stub in other architectures. That way we don't 
have to duplicate the current delay_calibration under i386.

Thanks,
Venki
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: [Discuss][i386] Platform SMIs and their interferance with tsc based delay calibration

2005-01-29 Thread Pallipadi, Venkatesh

-Original Message-
From: Andi Kleen [mailto:[EMAIL PROTECTED] 
Sent: Friday, January 28, 2005 10:24 PM
To: Pallipadi, Venkatesh
Cc: Seth, Rohit; Mallick, Asit K; 
linux-kernel@vger.kernel.org; [EMAIL PROTECTED]
Subject: Re: [Discuss][i386] Platform SMIs and their 
interferance with tsc based delay calibration

Venkatesh Pallipadi [EMAIL PROTECTED] writes:
 +
 +/*
 + * If the upper limit and lower limit of the tsc_rate 
is more than
 + * 12.5% apart.
 + */
 +if (pre_start == 0 || pre_end == 0 ||
 +(tsc_rate_max - tsc_rate_min)  (tsc_rate_max  3)) {
 +printk(KERN_WARNING TSC calibration may not be 
precise.  
 +   Too many SMIs? 
 +   Consider running with \lpj=\ boot option\n);
 +return 0;
 +}

I think it would be better to rerun it a few times automatically
before giving up. This way it would hopefully work 
transparently but slower
for most users. 

Agreed. Actually, I was doing that earlier, with each retry 
calibrating for 1 HZ. But, once I moved to 10 HZ, I removed the retires.

The message is too obscure too to be usable and needs
more explanation.

I will try to improve the message in next revision of the patch.

And also in case the platforms in questions support EM64T 
x86-64 would need to be changed too :)

Yes. I will send out a patch for x86-64 too, once the i386 patch 
gets finalized. I wanted to have a shorted patch reviewed first :).

Thanks,
Venki
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: Ooops unmounting a defect DVD

2005-01-29 Thread James Bottomley
I wouldn't have noticed this at all since you didn't send it to the scsi
list, but fortunately, Al Viro drew it politely to my attention as
another example of SCSI refcounting problems.

The issue seems to be that we have a spurious scsi_cd_put() on the error
path of sr_open().  The sr_block_..() functions are the real block
opens and should be refcounted, the sr_...() are the pseudo cdrom opens
and should not be refcounted.

Could you try this and see if it fixes the problem?

James

= drivers/scsi/sr.c 1.124 vs edited =
--- 1.124/drivers/scsi/sr.c 2005-01-29 08:30:34 -06:00
+++ edited/drivers/scsi/sr.c2005-01-29 08:39:09 -06:00
@@ -544,7 +544,6 @@
return 0;
 
 error_out:
-   scsi_cd_put(cd);
return retval;  
 }
 


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: [Wbsd-devel] [PATCH 540] MMC_WBSD depends on ISA

2005-01-29 Thread Russell King
Christoph, did you mean to add anything?

On Sat, Jan 29, 2005 at 01:57:14PM +, Christoph Hellwig wrote:
 On Sat, Jan 29, 2005 at 02:37:39PM +0100, Pierre Ossman wrote:
  Pierre Ossman wrote:
  Geert Uytterhoeven wrote:
  
  MMC_WBSD depends on ISA (needs isa_virt_to_bus())
  
  
  
  Thanks. Shouldn't have missed something so obvious :)
  
  Russell, can you fix this in your next merge?
  
  
  Russell, please undo this patch. isa_virt_to_bus() is not dependent on 
  CONFIG_ISA. It causes problems on x86_64 platforms which cannot enable 
  ISA support.
  
  Rgds
  Pierre
  -
  To unsubscribe from this list: send the line unsubscribe linux-kernel in
  the body of a message to [EMAIL PROTECTED]
  More majordomo info at  http://vger.kernel.org/majordomo-info.html
  Please read the FAQ at  http://www.tux.org/lkml/
 ---end quoted text---

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA  - http://pcmcia.arm.linux.org.uk/
 2.6 Serial core
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: [Wbsd-devel] [PATCH 540] MMC_WBSD depends on ISA

2005-01-29 Thread Christoph Hellwig
On Sat, Jan 29, 2005 at 02:54:17PM +, Russell King wrote:
 Christoph, did you mean to add anything?

Yes, this somehow got lost:

-

  Russell, please undo this patch. isa_virt_to_bus() is not dependent on 
  CONFIG_ISA. It causes problems on x86_64 platforms which cannot enable 
  ISA support.
  

Actually it is, x86_64 just refuses to set CONFIG_ISA despite having
isa-like devices.

Either way a new driver shouldn't use isa_virt_to_bus at all but rather
use the proper DMA API and all those problems go away.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: [Wbsd-devel] [PATCH 540] MMC_WBSD depends on ISA

2005-01-29 Thread Russell King
On Sat, Jan 29, 2005 at 03:00:23PM +, Christoph Hellwig wrote:
 Either way a new driver shouldn't use isa_virt_to_bus at all but rather
 use the proper DMA API and all those problems go away.

One thing which comes up in this instance is: what struct device should
be used.

With ISA devices doing DMA, the device which actually owns the DMA
is the ISA DMA controller, not the device wiggling its DMA request
signal to the ISA DMA controller.

Given that, shouldn't the ISA DMA code have its own struct device to
represent the ISA DMA engine for things like the floppy driver and
other drivers using the ISA DMA engine?

To me, it makes no sense to pass the ISA device wiggling its DMA request
into the DMA API - this ISA device doesn't care whether the ISA DMA engine
can only access the first 16MB of memory or not (which is ISA DMA engine
specific), so the DMA mask on the ISA device is rather meaningless.

(This type of DMA also appears on later ARM platforms as well, hence
why I have given the whole issue some thought.)

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA  - http://pcmcia.arm.linux.org.uk/
 2.6 Serial core
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: [Wbsd-devel] [PATCH 540] MMC_WBSD depends on ISA

2005-01-29 Thread Christoph Hellwig
On Sat, Jan 29, 2005 at 03:13:46PM +, Russell King wrote:
 One thing which comes up in this instance is: what struct device should
 be used.

Current convention is to use a NULL device, it's from pre-generic
DMA times were only the pci_* types existed.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: [Wbsd-devel] [PATCH 540] MMC_WBSD depends on ISA

2005-01-29 Thread Pierre Ossman
Christoph Hellwig wrote:
Russell, please undo this patch. isa_virt_to_bus() is not dependent on 
CONFIG_ISA. It causes problems on x86_64 platforms which cannot enable 
ISA support.

 

Actually it is, x86_64 just refuses to set CONFIG_ISA despite having
isa-like devices.
Either way a new driver shouldn't use isa_virt_to_bus at all but rather
use the proper DMA API and all those problems go away.
 

The problem was that the DMA API didn't work for x86_64 when I wrote the 
driver. I see now that it has been fixed.
isa_virt_to_bus still works even though CONFIG_ISA is not configured. So 
I still think that the ISA dependency should be removed.
I'll move to the new API when I have the time to properly test it.

Rgds
Pierre
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: UDF madness

2005-01-29 Thread Christoph Hellwig
On Wed, Jan 26, 2005 at 08:11:41PM -0800, Andrew Morton wrote:
 Yes, me too.  generic_shutdown_super() takes lock_super().  And udf uses
 lock_super for protecting its block allocation data strutures.  Trivial
 deadlock on unmount.
 
 Filesystems really shouldn't be using lock_super() for internal purposes,
 and the main filesystems have been taught to not do that any more, but UDF
 is a holdout.
 
 It seems that this deadlock was introduced on Jan 5 by the udf: fix
 reservation discarding patch which added the udf_discard_prealloc() call
 into udf_clear_inode().  The below dopey patch prevents the deadlock, but
 perhaps we can think of something more appealing.  Ideally, use a new lock
 altogether?
 
 (I had UDF deadlock on me once during the untar.  That was a multi-process
 lockup and is probably due to a lock ranking bug.  Will poke at that a bit
 further).

Okay, below is a fix to switch udf to it's own private locking.  It's
safe because it doesn't intefer with VFS lock_super usage anywhere.

udf_free_inode has some more updates than simply switching the used
lock:

 - clear_inode() call moved outside locked section to avoid another
   deadlock
 - unused variable ino killed
 - is_directory moved into the conditional it's actually used in


Signed-off-by: Christoph Hellwig [EMAIL PROTECTED]

(note that I see memory corruption in UDF_I_DATA(inode), but I've
reproduced that with a kernel without all recent udf changes.  I'll
debug that one further)

--- 1.13/fs/udf/balloc.c2004-10-20 10:37:15 +02:00
+++ edited/fs/udf/balloc.c  2005-01-29 16:11:49 +01:00
@@ -148,6 +148,7 @@ static void udf_bitmap_free_blocks(struc
struct udf_bitmap *bitmap,
kernel_lb_addr bloc, uint32_t offset, uint32_t count)
 {
+   struct udf_sb_info *sbi = UDF_SB(sb);
struct buffer_head * bh = NULL;
unsigned long block;
unsigned long block_group;
@@ -156,7 +157,7 @@ static void udf_bitmap_free_blocks(struc
int bitmap_nr;
unsigned long overflow;
 
-   lock_super(sb);
+   down(sbi-s_alloc_sem);
if (bloc.logicalBlockNum  0 ||
(bloc.logicalBlockNum + count)  UDF_SB_PARTLEN(sb, 
bloc.partitionReferenceNum))
{
@@ -215,7 +216,7 @@ error_return:
sb-s_dirt = 1;
if (UDF_SB_LVIDBH(sb))
mark_buffer_dirty(UDF_SB_LVIDBH(sb));
-   unlock_super(sb);
+   up(sbi-s_alloc_sem);
return;
 }
 
@@ -224,13 +225,13 @@ static int udf_bitmap_prealloc_blocks(st
struct udf_bitmap *bitmap, uint16_t partition, uint32_t first_block,
uint32_t block_count)
 {
+   struct udf_sb_info *sbi = UDF_SB(sb);
int alloc_count = 0;
int bit, block, block_group, group_start;
int nr_groups, bitmap_nr;
struct buffer_head *bh;
 
-   lock_super(sb);
-
+   down(sbi-s_alloc_sem);
if (first_block  0 || first_block = UDF_SB_PARTLEN(sb, partition))
goto out;
 
@@ -279,7 +280,7 @@ out:
mark_buffer_dirty(UDF_SB_LVIDBH(sb));
}
sb-s_dirt = 1;
-   unlock_super(sb);
+   up(sbi-s_alloc_sem);
return alloc_count;
 }
 
@@ -287,6 +288,7 @@ static int udf_bitmap_new_block(struct s
struct inode * inode,
struct udf_bitmap *bitmap, uint16_t partition, uint32_t goal, int *err)
 {
+   struct udf_sb_info *sbi = UDF_SB(sb);
int newbit, bit=0, block, block_group, group_start;
int end_goal, nr_groups, bitmap_nr, i;
struct buffer_head *bh = NULL;
@@ -294,7 +296,7 @@ static int udf_bitmap_new_block(struct s
int newblock = 0;
 
*err = -ENOSPC;
-   lock_super(sb);
+   down(sbi-s_alloc_sem);
 
 repeat:
if (goal  0 || goal = UDF_SB_PARTLEN(sb, partition))
@@ -367,7 +369,7 @@ repeat:
}
if (i = (nr_groups*2))
{
-   unlock_super(sb);
+   up(sbi-s_alloc_sem);
return newblock;
}
if (bit  sb-s_blocksize  3)
@@ -376,7 +378,7 @@ repeat:
bit = udf_find_next_one_bit(bh-b_data, sb-s_blocksize  3, 
group_start  3);
if (bit = sb-s_blocksize  3)
{
-   unlock_super(sb);
+   up(sbi-s_alloc_sem);
return 0;
}
 
@@ -390,7 +392,7 @@ got_block:
 */
if (inode  DQUOT_ALLOC_BLOCK(inode, 1))
{
-   unlock_super(sb);
+   up(sbi-s_alloc_sem);
*err = -EDQUOT;
return 0;
}
@@ -413,13 +415,13 @@ got_block:
mark_buffer_dirty(UDF_SB_LVIDBH(sb));
}
sb-s_dirt = 1;
-   unlock_super(sb);
+   up(sbi-s_alloc_sem);
*err = 0;
return newblock;
 
 error_return:
*err = -EIO;
-   unlock_super(sb);
+   up(sbi-s_alloc_sem);
return 0;
 }
 
@@ -428,6 +430,7 @@ static void udf_table_free_blocks(struct
struct inode * table,
kernel_lb_addr bloc, uint32_t offset, 

radeonfb - oops

2005-01-29 Thread Pawe Sikora
Hi,

I get on serial console only this:

# dmesg

radeonfb_pci_register BEGIN
radeonfb: ref_clk=2700, ref_div=60, xclk=15500 from BIOS
radeonfb: probed SDR SGRAM 65536k videoram
radeon_get_moninfo: bios 4 scratch = 202
Unable to handle kernel paging request at virtual address 083d5020
 printing eip:
c0215abc
*pgd = 0296a001
*pmd = 
Oops:  [#1]
Modules linked in: radeonfb snd_emu10k1 snd_rawmidi snd_seq_device 
snd_ac97_codec snd_util_mem snd_hwdep radeon button nfs 8139too mii md5 ipv6 
ext2 mbcache nfsd exportfs lockd sunrpc via_agp agpgart loop ide_cd cdrom 
psmouse snd_pcm_oss snd_pcm snd_timer snd_page_alloc snd_mixer_oss snd 
soundcore ide_disk xfs via82cxxx ide_core
CPU:0
EIP:0060:[c0215abc]Not tainted VLI
EFLAGS: 00010206   (2.6.10-0.105) 
EIP is at fb_find_mode+0x12c/0x3f0
eax: 083d5036   ebx:    ecx: 0006   edx: c012a840
esi: d0a17381   edi: 083d5020   ebp: c3593dd0   esp: c3593d7c
ds: 007b   es: 007b   ss: 0068
Process modprobe (pid: 4594, threadinfo=c3592000 task=c8d8d040)
Stack: 0082 083d5020 d0a17380  003c  0001 003c 
   0008 01e0 0280 0001 0001 0001 0007 d0a17380 
   c3677000 c3593dfc c3593dfc c3593dfc c3593e9c c3593df4 d0a1506d c012a840 
Call Trace:
 [c013a20a] show_stack+0x7a/0x90
 [c013a38d] show_registers+0x14d/0x1b0
 [c013a552] die+0xc2/0x140
 [c014afef] do_page_fault+0x2ff/0x75d
 [c0139e5b] error_code+0x2b/0x30
 [d0a1506d] radeon_init_disp_var+0x7d/0x80 [radeonfb]
 [d0a14f84] radeon_init_disp+0x34/0xa0 [radeonfb]
 [d0a16a30] radeon_set_fbinfo+0xd0/0xe0 [radeonfb]
 [d0a16d1f] radeonfb_pci_register+0x2df/0x5f0 [radeonfb]
 [c01ec607] pci_device_probe_static+0x47/0x60
 [c01ec651] __pci_device_probe+0x31/0x50
 [c01ec696] pci_device_probe+0x26/0x40
 [c024438c] driver_probe_device+0x2c/0x70
 [c02444b5] driver_attach+0x55/0x90
 [c024494b] bus_add_driver+0x8b/0xb0
 [c0244eeb] driver_register+0x2b/0x30
 [c01ec8af] pci_register_driver+0x5f/0x80
 [c0165131] sys_init_module+0x101/0x180
 [c0138d19] sysenter_past_esp+0x52/0x79
Code: 0c 89 7d bc 73 7c c7 45 b8 00 00 00 00 89 f6 8b 45 b8 8b 55 08 8b 04 02 
85 c0 89 45 b0 74 35 8b 75 e8 89 c7 8b 4d e4 49 78 08 ac ae 75 08 84 c0 75 
f5 31 c0 eb 04 19 c0 0c 01 85 c0 75 16 b9 ff 

# lspci -v

01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY
[Radeon 7000/VE] (prog-if 00 [VGA])
Subsystem: Giga-byte Technology RV100 QY
   [RADEON 7000 PRO MAYA AV Series]
Flags: bus master, stepping, 66Mhz, medium devsel, latency 32, IRQ 
145
Memory at d000 (32-bit, prefetchable) [size=128M]
I/O ports at a800 [size=256]
Memory at dfef (32-bit, non-prefetchable) [size=64K]
Expansion ROM at dfec [disabled] [size=128K]
Capabilities: [58] AGP version 2.0
Capabilities: [50] Power Management version 2

# sources

linux-2.6.10 + minor radeon fixes from BK:

linux-2.6-radeonfb-fix-rom-enable-disable.patch
linux-2.6-radeonfb-fix-section-usage.patch

Help will be appreciated.

Regards,
Pawe.

-- 
/* Copyright (C) 2003, SCO, Inc. This is valuable Intellectual Property. */

   #define say(x) lie(x)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] ppc32: Add support for Pegasos machines

2005-01-29 Thread Olaf Hering
 On Wed, Jan 26, Linux Kernel Mailing List wrote:

 ChangeSet 1.2046, 2005/01/25 20:33:08-08:00, [EMAIL PROTECTED]
 
   [PATCH] ppc32: Add support for Pegasos machines
   
   This patch, mostly from Sven Luther and reworked by me, adds support for
   Pegasos machines to the ppc32 arch. The patch contains all of the arch
   code. I'll send separately a few driver changes as well.
   
   Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
   Signed-off-by: Andrew Morton [EMAIL PROTECTED]
   Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
 
 
 
  arch/ppc/platforms/chrp_pci.c   |   38 +---

 diff -Nru a/arch/ppc/platforms/chrp_pci.c b/arch/ppc/platforms/chrp_pci.c
 --- a/arch/ppc/platforms/chrp_pci.c   2005-01-25 21:14:21 -08:00
 +++ b/arch/ppc/platforms/chrp_pci.c   2005-01-25 21:14:21 -08:00
 @@ -195,7 +215,7 @@
   struct pci_controller *hose;
   unsigned int *dma;
   char *model, *machine;
 - int is_longtrail = 0, is_mot = 0;
 + int is_longtrail = 0, is_mot = 0, is_pegasos = 0;
   struct device_node *root = find_path_device(/);
  
   /*
 @@ -207,6 +227,10 @@
   if (machine != NULL) {
   is_longtrail = strncmp(machine, IBM,LongTrail, 13) == 0;
   is_mot = strncmp(machine, MOT, 3) == 0;
 + if (strncmp(machine, Pegasos2, 8) == 0)
 + is_pegasos = 2;
 + else if (strncmp(machine, Pegasos, 7) == 0)
 + is_pegasos = 1;
   }
   for (dev = root-child; dev != NULL; dev = dev-sibling) {
   if (dev-type == NULL || strcmp(dev-type, pci) != 0)
 @@ -275,5 +303,7 @@
   }
   }
  
 - ppc_md.pcibios_fixup = chrp_pcibios_fixup;
 + /* Do not fixup interrupts from OF tree on pegasos */
 + if (is_pegasos != 0)
 + ppc_md.pcibios_fixup = chrp_pcibios_fixup;
  }

This breaks other chrp boards, like a B50.

PCI: Enabling device :00:10.0 (0140 - 0143)
sym0: 875 rev 0x4 at pci :00:10.0 irq 7
sym0: No NVRAM, ID 7, Fast-20, SE, parity checking
sym0: SCSI BUS has been reset.
scsi0 : sym-2.1.18n
sym0:0:0: ABORT operation started.
sym0:0:0: ABORT operation timed-out.
sym0:0:0: DEVICE RESET operation started.
sym0:0:0: DEVICE RESET operation timed-out.
sym0:0:0: BUS RESET operation started.
sym0:0:0: BUS RESET operation timed-out.
sym0:0:0: HOST RESET operation started.
Uninitialised timer!
This is just a warning.  Your computer is OK
function=0xc02a, data=0x2828
Call trace:
 [c0028028] check_timer_failed+0x7c/0x9c
 [c0028074] del_timer+0x2c/0xb0
 [c0111c68] __sym_eh_done+0x8c/0x98
 [c0110654] sym_xpt_done+0x2c/0x40
 [c0117930] sym_flush_comp_queue+0x160/0x190
 [c0117fd0] sym_start_up+0x194/0x7d8
 [c0111994] sym_eh_handler+0x1bc/0x2d0
 [c0107644] scsi_try_host_reset+0x8c/0x104
 [c0108ac0] scsi_error_handler+0x8c0/0xe68
 [c0006e14] kernel_thread+0x44/0x60
sym0: SCSI BUS has been reset.
sym0:0:0: HOST RESET operation timed-out.
scsi: Device offlined - not ready after error recovery: host 0 channel 0 id 0 
lun 0


Signed-off-by: Olaf Hering [EMAIL PROTECTED]

--- ./arch/ppc/platforms/chrp_pci.c~2005-01-29 16:22:09.288047704 +0100
+++ ./arch/ppc/platforms/chrp_pci.c 2005-01-29 16:44:03.905193820 +0100
@@ -304,6 +304,6 @@
}
 
/* Do not fixup interrupts from OF tree on pegasos */
-   if (is_pegasos != 0)
+   if (!is_pegasos)
ppc_md.pcibios_fixup = chrp_pcibios_fixup;
 }
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: [Wbsd-devel] [PATCH 540] MMC_WBSD depends on ISA

2005-01-29 Thread Christoph Hellwig
On Sat, Jan 29, 2005 at 04:31:16PM +0100, Pierre Ossman wrote:
 The problem was that the DMA API didn't work for x86_64 when I wrote the 
 driver. I see now that it has been fixed.
 isa_virt_to_bus still works even though CONFIG_ISA is not configured. So 

It may not exist 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: [Wbsd-devel] [PATCH 540] MMC_WBSD depends on ISA

2005-01-29 Thread Pierre Ossman
Christoph Hellwig wrote:
On Sat, Jan 29, 2005 at 04:31:16PM +0100, Pierre Ossman wrote:
 

The problem was that the DMA API didn't work for x86_64 when I wrote the 
driver. I see now that it has been fixed.
isa_virt_to_bus still works even though CONFIG_ISA is not configured. So 
   

It may not exist at all.
 

For i386 and x86_64 it's defined as virt_to_phys in asm/io.h without any 
#ifdef:s protecting it.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [Wbsd-devel] [PATCH 540] MMC_WBSD depends on ISA

2005-01-29 Thread Christoph Hellwig
On Sat, Jan 29, 2005 at 05:08:32PM +0100, Pierre Ossman wrote:
 For i386 and x86_64 it's defined as virt_to_phys in asm/io.h without any 
 #ifdef:s protecting it.

Not all the world is a PC

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: [Wbsd-devel] [PATCH 540] MMC_WBSD depends on ISA

2005-01-29 Thread Pierre Ossman
Christoph Hellwig wrote:
On Sat, Jan 29, 2005 at 05:08:32PM +0100, Pierre Ossman wrote:
 

For i386 and x86_64 it's defined as virt_to_phys in asm/io.h without any 
#ifdef:s protecting it.
   

Not all the world is a PC
 

Then the dependency should in that case be on architectures. It is 
connected similar to a floppy (which is not dependent on ISA and uses 
isa_virt_to_bus).

The point is that isa_virt_to_bus() is the method used by devices 
connected in the same way. This works on the platforms where the device 
can be found (i386 and x86_64). We can not make it dependent on ISA 
since you cannot enable ISA on all platforms where it exists (i.e. 
x86_64). Either fix that or make the driver depend on architecture the 
same way floppy does.

Using the generic DMA API might be a viable option now that x86_64 seems 
to be fixed. But it doesn't have a good track record so I'm not prepared 
to commit any changes until I have time to properly test it. There might 
still be assumptions about PCI lurking around.

Rgds
Pierre
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Patch 4/6 randomize the stack pointer

2005-01-29 Thread Arjan van de Ven
On Sat, 2005-01-29 at 11:21 -0500, John Richard Moser wrote:
 -BEGIN PGP SIGNED MESSAGE-

 These are the only places mprotect() is mentioned; a visual scan
 confirms no trickery:
 
 if( fork() == 0 ) {
 /* Perform a dirty (but not unrealistic) trick to circumvent
  * the kernel protection.
  */
 if( paxtest_mode == 1 ) {
 pthread_t thread;
 pthread_create(thread, NULL, test_thread, dummy);
 doit();
 pthread_kill(thread, SIGTERM);
 } else {

 So, there you have it.  These tests do not intentionally kill
 exec-shield based on its known issue with tracking the upper limit of
 the code segment.


here they do.
dummy is a local NESTED function, which causes the stack to *correctly*
be marked executable, due to the need of trampolines. 
That disables execshield for any tests that use dummy.o, which most of
them are.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] OProfile: Fix oops on undetected CPU type

2005-01-29 Thread Zwane Mwaikambo
On Sat, 29 Jan 2005, John Levon wrote:

 On Fri, Jan 28, 2005 at 12:06:19PM -0700, Zwane Mwaikambo wrote:
 
  = drivers/oprofile/oprofile_files.c 1.7 vs edited =
  --- 1.7/drivers/oprofile/oprofile_files.c   2005-01-04 19:48:23 -07:00
  +++ edited/drivers/oprofile/oprofile_files.c2005-01-28 11:36:25 
  -07:00
  @@ -63,7 +63,9 @@ static struct file_operations pointer_si
   
   static ssize_t cpu_type_read(struct file * file, char __user * buf, size_t 
  count, loff_t * offset)
   {
  -   return oprofilefs_str_to_user(oprofile_ops.cpu_type, buf, count, 
  offset);
  +   if (oprofile_ops.cpu_type)
  +   return oprofilefs_str_to_user(oprofile_ops.cpu_type, buf, 
  count, offset);
  +   return -EIO;
 
 This is wrong: you need to investigate why .cpu_type isn't set: in
 particular, it should have fallen back to timer mode.
 oprofile_arch_init() should have returned -ENODEV, and that should have
 set timer mode.
 
 Unfortunately bkcvs seems out of date so I can't even look at this
 myself.

Yes you are right, i checked bk and there was a lot of shuffling about due 
to the timer override. But it looks like we're depending on the timer 
variable being set. We could always just run timer_init if cpu_type is not 
set.

Signed-off-by: Zwane Mwaikambo [EMAIL PROTECTED]

= drivers/oprofile/oprof.c 1.11 vs edited =
--- 1.11/drivers/oprofile/oprof.c   2005-01-04 19:48:23 -07:00
+++ edited/drivers/oprofile/oprof.c 2005-01-29 09:38:24 -07:00
@@ -157,7 +157,7 @@ static int __init oprofile_init(void)
 
oprofile_arch_init(oprofile_ops);
 
-   if (timer) {
+   if (timer || !oprofile_ops.cpu_type) {
printk(KERN_INFO oprofile: using timer interrupt.\n);
oprofile_timer_init(oprofile_ops);
}
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Patch 4/6 randomize the stack pointer

2005-01-29 Thread Arjan van de Ven
On Sat, 2005-01-29 at 11:21 -0500, John Richard Moser wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 
 
 Arjan van de Ven wrote:
 I actually just tried to paxtest a fresh Fedora Core 3, unadultered,
 that I installed, and it FAILED every test.  After a while, spender
 reminded me about PT_GNU_STACK.  It failed everything but the Executable
 Stack test after execstack -c *.  The randomization tests gave
 13(heap-etexec), 16(heap-etdyn), 17(stack), and none for main exec
 (etexec,et_dyn) or shared library randomization.
  
  
  because you ran prelink.
  and you did not compile paxtest with -fPIE -pie to make it a PIE
  executable.
  

what I get is

Executable anonymous mapping : Killed
Executable bss   : Killed
Executable data  : Vulnerable
Executable heap  : Killed
Executable stack : Killed
Executable anonymous mapping (mprotect)  : Vulnerable
Executable bss (mprotect): Vulnerable
Executable data (mprotect)   : Vulnerable
Executable heap (mprotect)   : Vulnerable
Executable shared library bss (mprotect) : Vulnerable
Executable shared library data (mprotect): Vulnerable
Executable stack (mprotect)  : Vulnerable
Anonymous mapping randomisation test : No randomisation
Heap randomisation test (ET_EXEC): 13 bits (guessed)
Heap randomisation test (ET_DYN) : 13 bits (guessed)
Main executable randomisation (ET_EXEC)  : 12 bits (guessed)
Main executable randomisation (ET_DYN)   : 12 bits (guessed)
Shared library randomisation test: 12 bits (guessed)
Stack randomisation test (SEGMEXEC)  : 17 bits (guessed)
Stack randomisation test (PAGEEXEC)  : 17 bits (guessed)
Return to function (strcpy)  : paxtest: bad luck, try
different compiler options.
Return to function (strcpy, RANDEXEC): paxtest: bad luck, try
different compiler options.
Return to function (memcpy)  : Vulnerable
Return to function (memcpy, RANDEXEC): Vulnerable
Executable shared library bss: Killed
Executable shared library data   : Killed
Writable text segments   : Vulnerable


I'm not entirely happy yet (it shows a bug in mmap randomisation) but
it's way better than what you get in your tests (this is the desabotaged
0.9.6 version fwiw)


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: Why does the kernel need a gig of VM?

2005-01-29 Thread Chris Friesen
John Richard Moser wrote:
So what's the layout of that top 1G?  What's it all used for?  Is there
some obscene restriction of 1G of shared memory or something that gets
mapped up there?
How much does it need, and why?  What, if anything, is variable and
likely to do more than 10 or 15 megs of variation?
I'm guessing the high runners in the variable category are likely to be 
the page cache, all kinds of in-flight IO buffers, and such.

Chris
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: Fwd: Re: flush_cache_page()

2005-01-29 Thread Ralf Baechle
On Sat, Jan 29, 2005 at 08:29:22AM -0600, James Bottomley wrote:

 On Sat, 2005-01-29 at 11:37 +, Russell King wrote:
  Thanks for the response.  However, apart from Ralph, Paul and yourself,

Who are you talking about ;-)

  it seems none of the other architecture maintainers care about this
  patch - the original mail was BCC'd to the architecture list.  Maybe
  that's an implicit acceptance of this patch, I don't know.
 
 Well, OK, I'll try to answer for parisc, since we have huge VIPT
 aliasing caches as well.
 
 Right now, we have a scheme in flush_cache_page to make sure it's only
 called when necessary (cache flushes are expensive for us and show up as
 the primary cpu consumer in all of our profiles).  Our scheme is to see
 if a translation exists for the page and skip the flush if it doesn't.
 
 Obviously, like MIPS, we're also walking the page tables without
 locking...

VIPT caches on MIPS R4000-class processors will perform an address
translation using the TLB to obtain the physical address that will be
compared against the cache tags.  This may result in TLB reloads which are
an ugly case to deal with if the flush is being performed for a mm other
than current-mm.  Since a long time the flush_cache_page implementation
assumes getting this right is too hard but I suppose it's an optimization
that should be attempted and which would require pagetable lookups.

The current implementation actually does lookups as an optimization (and
I'm just asking myself if that is still correct) by looking at the present
bit of the pte to deciede if data from that page may have entered the cache
at all so we can avoid the flush entirely.

 Looking at the callers of this, it seems it would be very unlikely to
 call this with a missing translation, in that case, we can use the pfn
 to flush the page through a temporary alias space instead and just take
 the odd hit if no translation exists.  

That would be the MIPS optimization for the case of flushing on behalf of
another process.

  Ralf

PS: Don't get me started on PIVT caches ...
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Patch 4/6 randomize the stack pointer

2005-01-29 Thread John Richard Moser
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1





Arjan van de Ven wrote:
 On Sat, 2005-01-29 at 11:21 -0500, John Richard Moser wrote:
 
-BEGIN PGP SIGNED MESSAGE-
 
 
These are the only places mprotect() is mentioned; a visual scan
confirms no trickery:

if( fork() == 0 ) {
/* Perform a dirty (but not unrealistic) trick to circumvent
 * the kernel protection.
 */
if( paxtest_mode == 1 ) {
pthread_t thread;
pthread_create(thread, NULL, test_thread, dummy);
doit();
pthread_kill(thread, SIGTERM);
} else {
 
 
So, there you have it.  These tests do not intentionally kill
exec-shield based on its known issue with tracking the upper limit of
the code segment.
 
 
 
 here they do.
 dummy is a local NESTED function, which causes the stack to *correctly*
 be marked executable, due to the need of trampolines. 
 That disables execshield for any tests that use dummy.o, which most of
 them are.
 

Only in Blackhat mode.  I ran in Kiddie and Blackhat mode, and my
second batch of tests (tests.txt, my errata) was run after execstack -c.

 

[EMAIL PROTECTED]:/mnt/redhat/root/paxtest-0.9.6 # strace ./execstack 21 |
grep mprotect
mprotect(0x20822000, 4096, PROT_NONE)   = 0
[EMAIL PROTECTED]:/mnt/redhat/root/paxtest-0.9.6 # strace ./execstack 21 |
grep EXEC
old_mmap(NULL, 64996, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x265d9000
old_mmap(NULL, 1232332, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x265e9000
mmap2(NULL, 8392704, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x26716000

I killed the fork() line and straced it.
0x26716000 is only ~600 megs up,  I find my stack at ~1.5G under
segmexec, I'd guess it'd be at ~3G under normal things like execshield.
 You know what *looks*

getstack1:  0xfefcead7
getstack1:  0xfefe9947
getstack1:  0xfeedd4f7
getstack1:  0xfefe6e37
getstack1:  0xfee412b7
getstack1:  0xfee71737

Yeah it's pretty high under exec shield.

none of these are doing ANYTHING weird (grepping for EXEC and scanning
for PROT_EXEC and related addresses), aside from the normal mapping of
libraries by the system, which is probably what's killing Exec Shield's
anonymous mapping, heap, data, bss, library data, library bss. . .

To put it bluntly, you're wrong.  The tests are valid.

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB+8DuhDd4aOud5P8RAscYAKCErG3KB5M9gMwZ1BRqTDBKyYYLrACfcYeb
0ptJYTE+uUx0QYSHmKXWlsA=
=PL8+
-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: Patch 4/6 randomize the stack pointer

2005-01-29 Thread John Richard Moser
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Arjan van de Ven wrote:
 On Sat, 2005-01-29 at 11:21 -0500, John Richard Moser wrote:
 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Arjan van de Ven wrote:

I actually just tried to paxtest a fresh Fedora Core 3, unadultered,
that I installed, and it FAILED every test.  After a while, spender
reminded me about PT_GNU_STACK.  It failed everything but the Executable
Stack test after execstack -c *.  The randomization tests gave
13(heap-etexec), 16(heap-etdyn), 17(stack), and none for main exec
(etexec,et_dyn) or shared library randomization.


because you ran prelink.
and you did not compile paxtest with -fPIE -pie to make it a PIE
executable.

 
 
 what I get is
 
 Executable anonymous mapping : Killed
 Executable bss   : Killed
 Executable data  : Vulnerable
 Executable heap  : Killed
 Executable stack : Killed
 Executable anonymous mapping (mprotect)  : Vulnerable
 Executable bss (mprotect): Vulnerable
 Executable data (mprotect)   : Vulnerable
 Executable heap (mprotect)   : Vulnerable
 Executable shared library bss (mprotect) : Vulnerable
 Executable shared library data (mprotect): Vulnerable
 Executable stack (mprotect)  : Vulnerable
 Anonymous mapping randomisation test : No randomisation
 Heap randomisation test (ET_EXEC): 13 bits (guessed)
 Heap randomisation test (ET_DYN) : 13 bits (guessed)
 Main executable randomisation (ET_EXEC)  : 12 bits (guessed)
 Main executable randomisation (ET_DYN)   : 12 bits (guessed)
 Shared library randomisation test: 12 bits (guessed)
 Stack randomisation test (SEGMEXEC)  : 17 bits (guessed)
 Stack randomisation test (PAGEEXEC)  : 17 bits (guessed)
 Return to function (strcpy)  : paxtest: bad luck, try
 different compiler options.
 Return to function (strcpy, RANDEXEC): paxtest: bad luck, try
 different compiler options.
 Return to function (memcpy)  : Vulnerable
 Return to function (memcpy, RANDEXEC): Vulnerable
 Executable shared library bss: Killed
 Executable shared library data   : Killed
 Writable text segments   : Vulnerable
 
 
 I'm not entirely happy yet (it shows a bug in mmap randomisation) but
 it's way better than what you get in your tests (this is the desabotaged
 0.9.6 version fwiw)
 

I used 0.9.6 too, it had a slight bug in the randomization test
(getmain.c), which I pointed out in another post.

void foo( int unused )
{
printf( %p\n, __builtin_return_address(0) );
//printf( 0x%08x\n, ((unsigned long*)unused)[-1] );
}

I'm curious as to what the hell you're doing to get these results.  Exec
Shield came with the sysctl sys/kernel/exec-shield = 1 and
sys/kernel/exec-shield-randomize = 1.  I tried exec-shield = 0, 1, 2,
and 3 and couldn't get anything but the stack to kill on a Barton cored
32 bit athlon xp.

The tests I did were on a Fedora Core 3 i net-installed last night, no
adulteration.  Whatever black magic you're doing, it's not working here.
 
 

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB+8H/hDd4aOud5P8RAlIEAJkBwhIxdrXZ+jNz46oRg1SoSPmOHQCgiWfJ
HxzCBB43i6iLLhli5boKzoM=
=etT7
-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/


[2.6 patch] mark the mcd cdrom driver as BROKEN

2005-01-29 Thread Adrian Bunk
The mcd driver drives only very old hardware (some single and double 
speed CD drives that were connected either via the soundcard or a 
special ISA card), and the mcdx driver offers more functionality for the 
same hardware.

My plan is to mark MCD as broken in 2.6.11 and if noone complains 
completely remove this driver some time later.


Signed-off-by: Adrian Bunk [EMAIL PROTECTED]


--- linux-2.6.11-rc2-mm1-full/drivers/cdrom/Kconfig.old 2005-01-29 
17:12:26.0 +0100
+++ linux-2.6.11-rc2-mm1-full/drivers/cdrom/Kconfig 2005-01-29 
17:12:50.0 +0100
@@ -105,7 +105,7 @@
 
 config MCD
tristate Mitsumi (standard) [no XA/Multisession] CDROM support
-   depends on CD_NO_IDESCSI
+   depends on CD_NO_IDESCSI  BROKEN
---help---
  This is the older of the two drivers for the older Mitsumi models
  LU-005, FX-001 and FX-001D. This is not the right driver for the

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[2.6 patch] drivers/cdrom/isp16.c: small cleanups

2005-01-29 Thread Adrian Bunk
This patch makes the needlessly global function isp16_init static.

As a result, it turned out that both this function and some other code 
are only required #ifdef MODULE.

Signed-off-by: Adrian Bunk [EMAIL PROTECTED]

---

 drivers/cdrom/isp16.c |   13 -
 drivers/cdrom/isp16.h |1 -
 2 files changed, 8 insertions(+), 6 deletions(-)

--- linux-2.6.11-rc2-mm1-full/drivers/cdrom/isp16.h.old 2005-01-29 
16:46:18.0 +0100
+++ linux-2.6.11-rc2-mm1-full/drivers/cdrom/isp16.h 2005-01-29 
16:47:11.0 +0100
@@ -71,4 +71,3 @@
 #define ISP16_IO_BASE 0xF8D
 #define ISP16_IO_SIZE 5  /* ports used from 0xF8D up to 0xF91 */
 
-int isp16_init(void);
--- linux-2.6.11-rc2-mm1-full/drivers/cdrom/isp16.c.old 2005-01-29 
16:47:19.0 +0100
+++ linux-2.6.11-rc2-mm1-full/drivers/cdrom/isp16.c 2005-01-29 
17:46:38.0 +0100
@@ -58,6 +58,7 @@
 #include asm/io.h
 #include isp16.h
 
+#ifdef MODULE
 static short isp16_detect(void);
 static short isp16_c928__detect(void);
 static short isp16_c929__detect(void);
@@ -66,6 +67,7 @@
 static short isp16_type;   /* dependent on type of interface card */
 static u_char isp16_ctrl;
 static u_short isp16_enable_port;
+#endif  /*  MODULE  */
 
 static int isp16_cdrom_base = ISP16_CDROM_IO_BASE;
 static int isp16_cdrom_irq = ISP16_CDROM_IRQ;
@@ -106,13 +108,13 @@
 
 __setup(isp16=, isp16_setup);
 
-#endif /* MODULE */
+#else  /* MODULE */
 
 /*
  *  ISP16 initialisation.
  *
  */
-int __init isp16_init(void)
+static int __init isp16_init(void)
 {
u_char expected_drive;
 
@@ -366,15 +368,16 @@
return 0;
 }
 
+module_init(isp16_init);
+
+#endif
+
 void __exit isp16_exit(void)
 {
release_region(ISP16_IO_BASE, ISP16_IO_SIZE);
printk(KERN_INFO ISP16: module released.\n);
 }
 
-#ifdef MODULE
-module_init(isp16_init);
-#endif
 module_exit(isp16_exit);
 
 MODULE_LICENSE(GPL);

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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 patch] mark the mcd cdrom driver as BROKEN

2005-01-29 Thread Jean Delvare
Hi Adrian,

 The mcd driver drives only very old hardware (some single and double 
 speed CD drives that were connected either via the soundcard or a 
 special ISA card), and the mcdx driver offers more functionality for
 the  same hardware.
 
 My plan is to mark MCD as broken in 2.6.11 and if noone complains 
 completely remove this driver some time later.
 (...)
 - depends on CD_NO_IDESCSI
 + depends on CD_NO_IDESCSI  BROKEN

Shouldn't we introduce a DEPRECATED option for use in cases like this
one?

Thanks,
-- 
Jean Delvare
http://khali.linux-fr.org/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Patch 4/6 randomize the stack pointer

2005-01-29 Thread Jakub Jelinek
On Sat, Jan 29, 2005 at 01:31:46AM -0500, John Richard Moser wrote:
 Finally, although an NX stack is nice, you should probably take into
 account IBM's stack smash protector, ProPolice.  Any attack that can
 evade SSP reliably can evade an NX stack; but ProPolice protects from
 other overflows.  Now I'm sure RH is over there inventing something that
 detects buffer overflows at compile time and misses or warns about the
 ones it can't identify:
 
 if (strlen(a)  4)
   a[5] = '\0';
 foo(a);
 
 void foo(char *a) {
char b[5];
strcpy(b,a);
 }
 
 This code is safe, but you can't tell from looking at foo().  You don't
 get a look at every other object being compiled against this one that
 may call foo() either.  So compile time buffer overflow detection is a
 best-effort at best.

If strlen(a)  4 above, then -D_FORTIFY_SOURCE={1,2} compiled program
will be terminated in the strcpy call.  At compile time it computes
that the strcpy call can fill in at most 5 bytes and if it copies more,
then it terminates.

 ProPolice protects local variables with 0 overhead; passed arguments
 with a few instructions; and the return pointer and stack frame pointer
 with a couple instructions.  At runtime.  Want to impress me?  Actually
 deploy ProPolice instead of showing up 3 years from now waving around
 your own patch that you wrote that half-impliments half of it.  If you
 want something better, it's GPL, so grab it and start hacking.

__builtin_object_size () checking/-D_FORTIFY_SOURCE=n changes are (partly)
orthogonal to ProPolice.  There are exploits prevented by
-D_FORTIFY_SOURCE={1,2} checking and not ProPolice and vice versa.
Things that the former protects and the latter does not are e.g.
some non-automatic buffer overflows or heap overflows, some format string
vulnerabilities and for automatic variables e.g. those that don't
overflow into another function's frame, but just overwrite other local
variables in the same function.  ProPolice on the other side will detect
stack overflows that overflow into another function's frame, even if they
aren't done through string operations (string.h, s*printf, gets, etc.)
or if the compiler can't figure out what certain arguments to these
functions points to (and where) at compile time.

The ideas in IBM's ProPolice changes are good and worth
implementing, but the current implementation is bad.

FYI, you can find some details about -D_FORTIFY_SOURCE=n in
http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02055.html

Jakub
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: OpenOffice crashes due to incorrect access permissions on /dev/dri/card*

2005-01-29 Thread Alessandro Suardi
On Sat, 29 Jan 2005 13:02:51 +, Richard Hughes [EMAIL PROTECTED] wrote:
 On Sat, 29 Jan 2005 12:49:16 +, Richard Hughes wrote:
  Note, that strace glxgears gives exactly the same output, going from 0 to
  14 and then seg-faulting, so it's *not just a oo problem*.
 
 I know it's bad to answer your own post, but here goes.
 
 I changed my /etc/udev/permissions.d/50-udev.permissions config to read:
 
 dri/*:root:root:0666
 
 changing it from
 
 dri/*:root:root:0660
 
 And oowriter and glxgears work from bootup. Shall I file a bug with udev?

Interesting. On my FC2 (without udev) under 2.6.11-rc2-bk5
both programs work fine with /dev/dri/card0 in its default
 permissions - 666 (obviously).

However, if I manually chmod /dev/dri/card0 to 660 I don't
 get a SEGV, but rather

[EMAIL PROTECTED] asuardi]$ glxgears
libGL error: failed to open DRM: Operation not permitted
libGL error: reverting to (slow) indirect rendering
711 frames in 5.0 seconds = 142.200 FPS
X connection to :0.0 broken (explicit kill or server shutdown).
[EMAIL PROTECTED] asuardi]$ ooffice
libGL error: failed to open DRM: Operation not permitted
libGL error: reverting to (slow) indirect rendering

And both still work.

Relevant strace portion from glxgears says

read(3, \1\355\21\0\3\0\0\0\0\200\204\370\0\0\0\0\t\0\0\0\33\0..., 32) = 32
readv(3, [{PCI:1:0:0, 9}, {\0\0\0, 3}], 2) = 12
geteuid32() = 41
stat64(/dev/dri, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64(/dev/dri/card0, {st_mode=S_IFCHR|0660, st_rdev=makedev(226,
0), ...}) = 0
open(/dev/dri/card0, O_RDWR)  = -1 EACCES (Permission denied)
open(/dev/dri/card0, O_RDWR)  = -1 EACCES (Permission denied)
unlink(/dev/dri/card0)= -1 EACCES (Permission denied)
geteuid32() = 41
stat64(/dev/dri, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64(/dev/dri/card1, 0xb0dc)= -1 ENOENT (No such file or directory)
...
stat64(/dev/dri, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64(/dev/dri/card14, 0xb0dc)   = -1 ENOENT (No such file or directory)
write(2, libGL error: failed to open DRM:..., 57libGL error: failed
to open DRM: Operation not permitted
) = 57
write(2, libGL error: reverting to (slow)..., 52libGL error:
reverting to (slow) indirect rendering
) = 52
mmap2(NULL, 266240, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0xb7b68000
write(3, \222\3\2\0\0\0\0\0\220\24$\2\1\0\0\0\2\0\0\0\200\10\0\0...,
2544) = 2544

This with libGL and glxgears from FC2 updated RPMs 
 xorg-x11-Mesa-libGL-6.7.0-11
 xorg-x11-tools-6.7.0-11

--alessandro
 
 And every dream, every, is just a dream after all
  
(Heather Nova, Paper Cup)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: [Discuss][i386] Platform SMIs and their interferance with tsc based delay calibration

2005-01-29 Thread Linus Torvalds


On Fri, 28 Jan 2005, Venkatesh Pallipadi wrote:

 Current tsc based delay_calibration can result in significant errors in
 loops_per_jiffy count when the platform events like SMIs (System
 Management Interrupts that are non-maskable) are present. This could
 lead to potential kernel panic(). This issue is becoming more visible
 with 2.6 kernel (as default HZ is 1000) and on platforms with higher SMI
 handling latencies. During the boot time, SMIs are mostly used by BIOS
 (for things like legacy keyboard emulation).

Hmm. I see the problem, but I don't know that I'm 100% happy with this
patch, though.

In particular, I don't see why you didn't just put this in the generic 
calibrate_delay() routine. You seem to have basically duplicated it, and 
added the guess from an external timer code - and I don't see what's 
non-generic about that, except for some trivial what's the current timer 
lookup.

Linus
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: system calls

2005-01-29 Thread Robert Love
On Sat, 2005-01-29 at 10:53 -0300, Rodrigo Ramos wrote:

 I would like to know how many groups of system calls are there at Linux
 2.4 and 2.6? Where can I find these informations in the Kernel?

I don't know what you mean by groups (a nonempty set G with binary
operation * s.t. G is associativity, there exists e in G s.t. e*a=a*e=a,
and there exists i in G s.t. i*b=b*i=e?).

System calls are implemented per-architecture.  You can see the list at
the bottom of arch/i386/kernel/entry.S.  There is about 290.

System calls are prefixed by sys_.  Thus, read(2) is implemented in
the kernel as sys_read().  It, for example, can be found in
fs/read_write.c.

Hope this helps.

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 4/6 randomize the stack pointer

2005-01-29 Thread John Richard Moser
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Jakub Jelinek wrote:
 On Sat, Jan 29, 2005 at 01:31:46AM -0500, John Richard Moser wrote:
 
Finally, although an NX stack is nice, you should probably take into
account IBM's stack smash protector, ProPolice.  Any attack that can
evade SSP reliably can evade an NX stack; but ProPolice protects from
other overflows.  Now I'm sure RH is over there inventing something that
detects buffer overflows at compile time and misses or warns about the
ones it can't identify:

if (strlen(a)  4)
  a[5] = '\0';
foo(a);

void foo(char *a) {
   char b[5];
   strcpy(b,a);
}

This code is safe, but you can't tell from looking at foo().  You don't
get a look at every other object being compiled against this one that
may call foo() either.  So compile time buffer overflow detection is a
best-effort at best.
 
 
 If strlen(a)  4 above, then -D_FORTIFY_SOURCE={1,2} compiled program
 will be terminated in the strcpy call.  At compile time it computes
 that the strcpy call can fill in at most 5 bytes and if it copies more,
 then it terminates.

And somehow you check every operation like this with less overhead than
propolice?

 
 
ProPolice protects local variables with 0 overhead; passed arguments
with a few instructions; and the return pointer and stack frame pointer
with a couple instructions.  At runtime.  Want to impress me?  Actually
deploy ProPolice instead of showing up 3 years from now waving around
your own patch that you wrote that half-impliments half of it.  If you
want something better, it's GPL, so grab it and start hacking.
 
 
 __builtin_object_size () checking/-D_FORTIFY_SOURCE=n changes are (partly)
 orthogonal to ProPolice.  There are exploits prevented by
 -D_FORTIFY_SOURCE={1,2} checking and not ProPolice and vice versa.

So a belt-and-suspenders approach is better.

 Things that the former protects and the latter does not are e.g.
 some non-automatic buffer overflows or heap overflows, some format string
 vulnerabilities and for automatic variables e.g. those that don't
 overflow into another function's frame, but just overwrite other local
 variables in the same function.  ProPolice on the other side will detect
 stack overflows that overflow into another function's frame,

or past the top of any buffer by at most 2 ints (I didn't check with 1
int or 1 char when I wrote my regression suite), definitely before it
hits the SFP and return pointer

 even if they
 aren't done through string operations (string.h, s*printf, gets, etc.)
 or if the compiler can't figure out what certain arguments to these
 functions points to (and where) at compile time.
 
 The ideas in IBM's ProPolice changes are good and worth
 implementing, but the current implementation is bad.
 

Lies.  I've read the paper on the current implementation, it's
definitely good.  It only operates on C/C++ code though, but that's the
scope of it.

 FYI, you can find some details about -D_FORTIFY_SOURCE=n in
 http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02055.html
 
   Jakub
 

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB+8yPhDd4aOud5P8RAsekAJsGklzrgWi7ymrRmfhXpqv2LjB//gCeNBDy
8sCZBhtzy6l6L/WDjQpMq6A=
=4/Dz
-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: [2.6 patch] drivers/cdrom/isp16.c: small cleanups

2005-01-29 Thread Bartlomiej Zolnierkiewicz
Hi,

On Sat, 29 Jan 2005 18:11:08 +0100, Adrian Bunk [EMAIL PROTECTED] wrote:
 This patch makes the needlessly global function isp16_init static.
 
 As a result, it turned out that both this function and some other code
 are only required #ifdef MODULE.

Your patch is correct but it is wrong. ;)

#ifdefs around isp16_init() need to be removed as
otherwise this driver is not initialized in built-in case.

Bartlomiej

 Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
 
 ---
 
  drivers/cdrom/isp16.c |   13 -
  drivers/cdrom/isp16.h |1 -
  2 files changed, 8 insertions(+), 6 deletions(-)
 
 --- linux-2.6.11-rc2-mm1-full/drivers/cdrom/isp16.h.old 2005-01-29 
 16:46:18.0 +0100
 +++ linux-2.6.11-rc2-mm1-full/drivers/cdrom/isp16.h 2005-01-29 
 16:47:11.0 +0100
 @@ -71,4 +71,3 @@
  #define ISP16_IO_BASE 0xF8D
  #define ISP16_IO_SIZE 5  /* ports used from 0xF8D up to 0xF91 */
 
 -int isp16_init(void);
 --- linux-2.6.11-rc2-mm1-full/drivers/cdrom/isp16.c.old 2005-01-29 
 16:47:19.0 +0100
 +++ linux-2.6.11-rc2-mm1-full/drivers/cdrom/isp16.c 2005-01-29 
 17:46:38.0 +0100
 @@ -58,6 +58,7 @@
  #include asm/io.h
  #include isp16.h
 
 +#ifdef MODULE
  static short isp16_detect(void);
  static short isp16_c928__detect(void);
  static short isp16_c929__detect(void);
 @@ -66,6 +67,7 @@
  static short isp16_type;   /* dependent on type of interface card */
  static u_char isp16_ctrl;
  static u_short isp16_enable_port;
 +#endif  /*  MODULE  */
 
  static int isp16_cdrom_base = ISP16_CDROM_IO_BASE;
  static int isp16_cdrom_irq = ISP16_CDROM_IRQ;
 @@ -106,13 +108,13 @@
 
  __setup(isp16=, isp16_setup);
 
 -#endif /* MODULE */
 +#else  /* MODULE */
 
  /*
   *  ISP16 initialisation.
   *
   */
 -int __init isp16_init(void)
 +static int __init isp16_init(void)
  {
 u_char expected_drive;
 
 @@ -366,15 +368,16 @@
 return 0;
  }
 
 +module_init(isp16_init);
 +
 +#endif
 +
  void __exit isp16_exit(void)
  {
 release_region(ISP16_IO_BASE, ISP16_IO_SIZE);
 printk(KERN_INFO ISP16: module released.\n);
  }
 
 -#ifdef MODULE
 -module_init(isp16_init);
 -#endif
  module_exit(isp16_exit);
 
  MODULE_LICENSE(GPL);

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: Ooops unmounting a defect DVD

2005-01-29 Thread Oliver Neukum
Am Samstag, 29. Januar 2005 15:46 schrieb James Bottomley:
 I wouldn't have noticed this at all since you didn't send it to the scsi
 list, but fortunately, Al Viro drew it politely to my attention as
 another example of SCSI refcounting problems.

Sorry, it happening in cdrom_release fooled me into considering it
a generic cdrom problem.

 The issue seems to be that we have a spurious scsi_cd_put() on the error
 path of sr_open().  The sr_block_..() functions are the real block
 opens and should be refcounted, the sr_...() are the pseudo cdrom opens
 and should not be refcounted.
 
 Could you try this and see if it fixes the problem?

It fully fixes the problem. Thank you.

Regards
Oliver
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Patch 4/6 randomize the stack pointer

2005-01-29 Thread Christoph Hellwig
On Sat, Jan 29, 2005 at 12:49:05PM -0500, John Richard Moser wrote:
  The ideas in IBM's ProPolice changes are good and worth
  implementing, but the current implementation is bad.
  
 
 Lies.  I've read the paper on the current implementation, it's
 definitely good.  It only operates on C/C++ code though, but that's the
 scope of it.

Yeah, I guess your extensive compiler internals experience and knowledge
of gcc internals weights a lot more than the opinion of the gcc team..

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Patch 4/6 randomize the stack pointer

2005-01-29 Thread John Richard Moser
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Christoph Hellwig wrote:
 On Sat, Jan 29, 2005 at 12:49:05PM -0500, John Richard Moser wrote:
 
The ideas in IBM's ProPolice changes are good and worth
implementing, but the current implementation is bad.


Lies.  I've read the paper on the current implementation, it's
definitely good.  It only operates on C/C++ code though, but that's the
scope of it.
 
 
 Yeah, I guess your extensive compiler internals experience and knowledge
 of gcc internals weights a lot more than the opinion of the gcc team..
 

I read implementation as the way it's implemented, not as the
quality of the code.

Did I miss the target?  *Aims in the other direction then?*

 

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB+9GthDd4aOud5P8RAm/FAJwNvbrxPP8fcJmMM//vcYL10nMXTACggi57
jOKfS4FU1sdPL7AjKRgMmBg=
=igR0
-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: Patch 4/6 randomize the stack pointer

2005-01-29 Thread Rik van Riel
On Sat, 29 Jan 2005, John Richard Moser wrote:
Did I miss the target?  *Aims in the other direction then?*
Depends.  If you aimed to kick your own arse, you did pretty well.
--
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it. - Brian W. Kernighan
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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 01/04] Adding cipher mode context information to crypto_tfm

2005-01-29 Thread Fruhwirth Clemens
On Tue, 2005-01-25 at 10:52 -0500, James Morris wrote:
 On Mon, 24 Jan 2005, Andrew Morton wrote:
 
  These patches clash badly with Michael Ludvig's work:
  
  ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc2/2.6.11-rc2-mm1/broken-out/cryptoapi-prepare-for-processing-multiple-buffers-at.patch
  ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc2/2.6.11-rc2-mm1/broken-out/cryptoapi-update-padlock-to-process-multiple-blocks-at.patch
  
  so someone's going to have to rework things.  Ordinarily Michael would go
  first due to test coverage.
  
  James, your call please.  Also, please advise on the suitability of
  Michael's patches for a 2.6.11 merge.

 Perhaps temporarily drop the multible block changes above until we get the
 generic scatterwalk code in and a cleaned up design to handle cipher mode
 offload.

Andrew, do you agree with James on dropping this patches temporarily?
I'm running into a mess with patches for patches, and I'd be easier for
me to have my scatterwalk code in -mm to build on.

James, anything new on ipsec testing? Is there something else missing
for a GO from your side for scatterwalk generic?

I'm almost finished with my port of Michaels multiblock extensions, but
I run into a few single problems.

First, I'd set the bytes, a multiblock call can digest, to 4096, page
size. Why? Because, the scatterwalk code, even James original
implementation, will trigger heavy memcpy because the needscratch check
will always return true for page boundary crossing sections.

ATM max_nbytes isn't set to 4096, but to ((size_t)-1), the maximum value
of size_t. This is algorithm specific and set in padlock implementation.
(My port will drop these changes). But setting it to 4096 causes another
problem: the last fragment of a run might be shorter than 4096, but the
scatterwalk code (James and mine) wasn't designed to
change the stepsize/blocksize dynamically. Therefore, Michaels addition
to crypt(..) will wrongly process the whole last 4096 block, trashing
all data remaining data. That's not likely to break things, but the
behavior is certainly wrong.

So a lot of slippery details here. My advise is, drop Michaels patches
for now, merge scatterwalker and add an ability to change the stepsize
dynamically in the run. Then I will finish my port and post it.

If we can agree on this agenda, I'll shift my focus to scatterwalker
testing.

-- 
Fruhwirth Clemens [EMAIL PROTECTED]  http://clemens.endorphin.org


signature.asc
Description: This is a digitally signed message part


Re: Patch 4/6 randomize the stack pointer

2005-01-29 Thread Christoph Hellwig
On Sat, Jan 29, 2005 at 01:10:54PM -0500, John Richard Moser wrote:
  Yeah, I guess your extensive compiler internals experience and knowledge
  of gcc internals weights a lot more than the opinion of the gcc team..
  
 
 I read implementation as the way it's implemented, not as the
 quality of the code.

Doesn't really matter, it'd fit for both.

 
 Did I miss the target?  *Aims in the other direction then?*

Yes.  Try to search for propolice in the gcc mailglist archives
as a start.  Doing a little bit of research before calling someone
a liar is usually considered a good idea.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: system calls

2005-01-29 Thread Andries Brouwer
On Sat, Jan 29, 2005 at 12:47:38PM -0500, Robert Love wrote:

 System calls are prefixed by sys_.  Thus, read(2) is implemented in
 the kernel as sys_read().

Now that you say this - of course you know that the actual
situation is much more messy. Sometimes I wonder whether
it would be useful to make such a statement more true
and for example change sys_olduname, sys_uname, sys_newuname
into sys_oldolduname, sys_olduname, sys_uname.

Andries
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] OpenBSD Networking-related randomization port

2005-01-29 Thread Florian Weimer
* Lorenzo Hernández García-Hierro:

 As it's impact is minimal (in performance and development/maintenance
 terms), I recommend to merge it, as it gives a basic prevention for the
 so-called system fingerprinting (which is used most by kids to know
 how old and insecure could be a target system, many time used as the
 first, even only-one, data to decide if attack or not the target host)
 among other things.

The most important result of such a patch is source port randomization
for DNS queries to resolvers.  This gives you a few more bits (DNS
itself has just a 16 bit unique ID, which isn't too hard to
brute-force these days, unfortunately).
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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 01/04] Adding cipher mode context information to crypto_tfm

2005-01-29 Thread Andrew Morton
Fruhwirth Clemens [EMAIL PROTECTED] wrote:

 My advise is, drop Michaels patches
  for now, merge scatterwalker and add an ability to change the stepsize
  dynamically in the run. Then I will finish my port and post it.
 
  If we can agree on this agenda, I'll shift my focus to scatterwalker
  testing.

Sure.  Just work against Linus's tree.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: critical bugs in md raid5 and ATA disk failure/recovery modes

2005-01-29 Thread Pavel Machek
Hi!

  The nasty part there is that it can affect completely unrelated
  data too (on a traditional disk you normally only lose the data
  that is currently being written) because of of the relationship
  between stripes on different disks.

Well, you could set stripe size to 512B; that way, RAID-5 would be
*very* slow, but it should have same characteristics as normal disc
w.r.t. crash. Unrelated data would not be lost, and you'd either get
old data or new data...

Nasty part might be that if it went to degraded mode (before resync is
done), data on disk might silently change; that's bad I guess.

Performance would not be good, also.
Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: critical bugs in md raid5 and ATA disk failure/recovery modes

2005-01-29 Thread Andi Kleen
 Well, you could set stripe size to 512B; that way, RAID-5 would be
 *very* slow, but it should have same characteristics as normal disc
 w.r.t. crash. Unrelated data would not be lost, and you'd either get
 old data or new data...

When you lose a disk during recovery you can still lose
unrelated data (any sibling in a stripe set because its parity
information is incomplete).  RAID-1 doesn't have this problem though.

-Andi
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: critical bugs in md raid5 and ATA disk failure/recovery modes

2005-01-29 Thread Pavel Machek
Hi!

  Well, you could set stripe size to 512B; that way, RAID-5 would be
  *very* slow, but it should have same characteristics as normal disc
  w.r.t. crash. Unrelated data would not be lost, and you'd either get
  old data or new data...
 
 When you lose a disk during recovery you can still lose
 unrelated data (any sibling in a stripe set because its parity
 information is incomplete).  RAID-1 doesn't have this problem though.

You are right, I'd have to do soething very special... Like if I know
it is 4K filesystem, raid-5 from 5 disks could do the trick. Like

Disk1   Disk2   Disk3   Disk4   Disk5
bytes0-511  512-10231024-1535   1536-2048   parity


no, even that does not work. You could add single bit for each 4K
saying this stripe is being written (with barriers etc) and return
read errors if bit is set might actually do the trick, but that's no
longer raid-5... (Can ext3 handle error in journal?)
Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: AT keyboard dead on 2.6

2005-01-29 Thread Vojtech Pavlik
On Fri, Jan 28, 2005 at 02:27:20PM -0500, Dmitry Torokhov wrote:
 On Fri, 28 Jan 2005 20:22:32 +0100, Wiktor [EMAIL PROTECTED] wrote:
  Hi,
  
  This dmesg looks like the keyboard works perfectly OK. Do new lines
  appear in dmesg when you press keys while the system is running?
  
  .no? no, they don't. i've new dmesg for you - it reports
  timeouts while trying to perform keyboard reset (by atkbd.reset=1).
  after detection pressing any keys has absolutley no effect. maybe it's
  some timeout-violation?
  
 
 Could you please try editing drivers/input/serio/i8042.c and add
 udelay(20) before and after calls to i8042_write_data() in
 i8042_kbd_write() and i8042_command().
 
Uh? What that'd help? All the communication proceeds OK, up to proper
registration of the input device, but the keyboard seems to stay in a
'disabled' state. The keyboard, not the controller, because if it were
the controller, atkbd.c wouldn't get the 'fa' responses back via
functioning interrupts.

Wiktor, can you try atkbd.dumbkbd=1?

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: AT keyboard dead on 2.6

2005-01-29 Thread Vojtech Pavlik
On Fri, Jan 28, 2005 at 08:22:32PM +0100, Wiktor wrote:
 Hi,
 
 This dmesg looks like the keyboard works perfectly OK. Do new lines
 appear in dmesg when you press keys while the system is running?
 
 .no? no, they don't. i've new dmesg for you - it reports 
 timeouts while trying to perform keyboard reset (by atkbd.reset=1). 
 after detection pressing any keys has absolutley no effect. maybe it's 
 some timeout-violation?

It still looks OK. It seems to be a very ancient keyboard. Can you try with
a newer one? That'd tell us whether it's the controller or the keyboard
that is giving problems.

What keyboard model is it? What machine?

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: AT keyboard dead on 2.6

2005-01-29 Thread Vojtech Pavlik
On Fri, Jan 28, 2005 at 08:49:03PM +0100, Wiktor wrote:
 Hi,
 
 Could you please try editing drivers/input/serio/i8042.c and add
 udelay(20) before and after calls to i8042_write_data() in
 i8042_kbd_write() and i8042_command().
 
 of course i could, will it make kernel not detect smoked AUX port? 
 (problem is solved by i8042.noaux=1 cause my hardware has smoked PS/2 
 port) i would rather think about testing devices before assuming thet 
 work and trying to use them (maybe not as standard kernel feature, but 
 it would be nice stuff for people with self-built machines where not 
 everything works). Thanks for your help
 
Well, the kernel tests the AUX port and it seemed OK, that's the
problem. Unfortunately it's not always possible to detect whether
there's a problem with some device.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 1/3] Fix MUX mode disabling.

2005-01-29 Thread Vojtech Pavlik
You can pull this changeset from:
bk://kernel.bkbits.net/vojtech/for-linus

===

[EMAIL PROTECTED], 2005-01-28 21:11:52+01:00, [EMAIL PROTECTED]
  input: Fix MUX mode disabling.
  
  Signed-off-by: Vojtech Pavlik [EMAIL PROTECTED]


 i8042.c |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

===

diff -Nru a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
--- a/drivers/input/serio/i8042.c   2005-01-29 17:37:27 +01:00
+++ b/drivers/input/serio/i8042.c   2005-01-29 17:37:27 +01:00
@@ -482,7 +482,7 @@
if (i8042_command(param, I8042_CMD_AUX_LOOP) || param != 0x0f)
return -1;
param = mode ? 0x56 : 0xf6;
-   if (i8042_command(param, I8042_CMD_AUX_LOOP) || param != 0xa9)
+   if (i8042_command(param, I8042_CMD_AUX_LOOP) || param != (mode ? 0xa9 
: 0x09))
return -1;
param = mode ? 0xa4 : 0xa5;
if (i8042_command(param, I8042_CMD_AUX_LOOP) || param == (mode ? 0x5b 
: 0x5a))
@@ -787,7 +787,8 @@
  * Disable MUX mode if present.
  */
 
-   i8042_set_mux_mode(0, NULL);
+   if (i8042_mux_present)
+   i8042_set_mux_mode(0, NULL);
 
 /*
  * Restore the original control register setting.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: i8042 access timings

2005-01-29 Thread Vojtech Pavlik
On Fri, Jan 28, 2005 at 04:20:58PM +0200, Jaco Kroon wrote:
 Vojtech Pavlik wrote:
 On Thu, Jan 27, 2005 at 09:29:47PM +0100, Andries Brouwer wrote:
 
 
 So what _might_ happen is that we write the command, and then 
 i8042_wait_write() thinks that there is space to write the data 
 immediately, and writes the data, but now the data got lost because the 
 buffer was busy.
 
 Hmm - I just answered the same post and concluded that I didnt understand,
 so you have progressed further. I considered the same possibility,
 but the data was not lost since we read it again later.
 Only the ready flag was lost.
 
  
 What I believe is happening is that we're talking to SMM emulation of
 the i8042, which doesn't have a clue about these commands, while the
 underlying real hardware implementation does. And because of that they
 disagree on what should happen when the command is issued, and since the
 SMM emulation lazily synchronizes with the real HW, we only get the data
 back with the next command.
 
 I still don't have an explanation why both 'usb-handoff' and 'acpi=off'
 help, I'd expect only the first to, but it might be related to the SCI
 interrupt routing which isn't done when 'acpi=off'. Just a wild guess.
 
 
 Ok, I'm not too clued up with recent hardware and the BIOS programming 
 that goes with it (being a system admin/application programmer), what 
 exactly is usb-handoff?

usb-handoff is a kernel option that enables a PCI quirk routine that
takes the USB controller out of BIOS's hands. Until that is done (the
linux USB drivers also do it, only later), the BIOS owns the USB
controller and tries to emulate a PS/2 mouse and keyboard for systems
which can't handle USB.

  acpi=off obviously just turns all acpi support 
 in the kernel off. 

Indeed.

 SCI is also a new abbreviation I haven't seen 
 before.

System Configuration Interrupt. In addition to SMI (System Management
Interrupt), these are two interrupts the BIOS uses to do its job behind
the operating system's back.

  Whilst I've seen SMM before, I'm not sure what it stands for (I 

SMM is System Management Mode. It's a special mode of the CPU, which is
entered when a SMI is triggered by some event, like an port write trap
in the case of the emulated PS/2 mouse. 

Using SMM the BIOS can emulate any device it wishes to, and the OS will
think it's real. It's an even more privileged mode than what the OS runs
in.

 assume it's something to do with simulation of legacy devices for older 
 operating systems)?

It also does thermal monitoring, often is used for turning the backlight
off on notebooks, and handling various magic Fn- key combinations.

 From the kernel-parameters documentation:
 
 usb-handoff [HW] Enably early USB BIOS - OS handoff
 
 I guess this means the OS takes over control of the USB devices at an 
 earlier stage than usual - possibly before ACPI gets initialised? 

Before the i8042 keyboard driver gets initialized. That's the important
part, because the handoff stops the BIOS from emulating a PS/2 mouse,
and thus blocking access to the real PS/2 mouse controller.

 I'm 
 unable to determine much from looking at drivers/pci/quirks.c (which is 
 where the usb-handoff parameter is defined).
 
 usb-handoff=1 does however also fix the problem.  Ok.  This makes it 
 even more confusing (and probably more complicated).  The appropriate 
 section from dmesg that shows that it is working correctly:
 
 i8042_init()
 ACPI: PS/2 Keyboard Controller [KBC0] at I/O 0x60, 0x64, irq 1
 ACPI: PS/2 Mouse Controller [MSE0] at irq 12
 i8042_controller_init()
 i8042_flush()
 drivers/input/serio/i8042.c: 20 - i8042 (command) [4]
 drivers/input/serio/i8042.c: 47 - i8042 (return) [4]
 drivers/input/serio/i8042.c: 60 - i8042 (command) [4]
 drivers/input/serio/i8042.c: 56 - i8042 (parameter) [4]
 i8042_check_aux()
 drivers/input/serio/i8042.c: Interrupt 12, without any data [8]
 i8042_flush()
 drivers/input/serio/i8042.c: d3 - i8042 (command) [13]
 drivers/input/serio/i8042.c: 5a - i8042 (parameter) [13]
 drivers/input/serio/i8042.c: a5 - i8042 (return) [13]
 i8042_check_aux:  passed

I don't like the interrupt message, I'll check why it's enabled so
early. It may have a good reason to, as well. Other than that, it looks
very much OK.

 So as with acpi=off, we get a correct return.  Now that usb is 
 mentioned, I think either myself or Sebastian has mentioned that the 
 keyboard does not work unless USB1.1 support is compiled in.  Another 
 clue possibly?

Compiling USB 1.1 support does the very same thing as specifying
usb-handoff on the command like - tells the BIOS to keep its hands off
the USB _and_ PS/2 controllers.

 Another question - would it be usefull at all to see what happens if the 
 AUX_LOOP test is never performed but only AUX_TEST?  Or does AUX_TEST 
 rely on the fact that AUX_LOOP must first fail/timeout somehow?

No. You can use AUX_TEST event before AUX_LOOP. But I expect it to fail
similarly when BIOS is active.

-- 
Vojtech Pavlik
SuSE 

[PATCH 2/3] Document the atkbd.softraw module parameter.

2005-01-29 Thread Vojtech Pavlik
You can pull this changeset from:
bk://kernel.bkbits.net/vojtech/for-linus

===

[EMAIL PROTECTED], 2005-01-29 12:27:56+01:00, [EMAIL PROTECTED]
  input: Document the atkbd.softraw module parameter.
  
  From: Andries Brouwer [EMAIL PROTECTED]
  Signed-off-by: Vojtech Pavlik [EMAIL PROTECTED]


 kernel-parameters.txt |   10 +++---
 1 files changed, 7 insertions(+), 3 deletions(-)

===

diff -Nru a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
--- a/Documentation/kernel-parameters.txt   2005-01-29 17:37:19 +01:00
+++ b/Documentation/kernel-parameters.txt   2005-01-29 17:37:19 +01:00
@@ -226,15 +226,19 @@
 
atascsi=[HW,SCSI] Atari SCSI
 
-   atkbd.extra=[HW] Enable extra LEDs and keys on IBM RapidAccess, 
EzKey
-   and similar keyboards
+   atkbd.extra=[HW] Enable extra LEDs and keys on IBM RapidAccess,
+   EzKey and similar keyboards
 
atkbd.reset=[HW] Reset keyboard during initialization
 
atkbd.set=  [HW] Select keyboard code set 
Format: int (2 = AT (default) 3 = PS/2)
 
-   atkbd.scroll=   [HW] Enable scroll wheel on MS Office and similar 
keyboards
+   atkbd.scroll=   [HW] Enable scroll wheel on MS Office and similar
+   keyboards
+
+   atkbd.softraw=  [HW] Choose between synthetic and real raw mode
+   Format: bool (0 = real, 1 = synthetic (default))

atkbd.softrepeat=
[HW] Use software keyboard repeat

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


2.6.10-ac11 announcement?

2005-01-29 Thread Ralf Hildebrandt
Where is the 2.6.10-ac11 announcement?

-- 
Ralf Hildebrandt (i.A. des IT-Zentrum)  [EMAIL PROTECTED]
Charite - Universitätsmedizin BerlinTel.  +49 (0)30-450 570-155
Gemeinsame Einrichtung von FU- und HU-BerlinFax.  +49 (0)30-450 570-962
IT-Zentrum Standort CBF send no mail to [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


patch - ftdi_sio.c floods my logs with write request of 0 bytes

2005-01-29 Thread Elias Oltmanns
Hi there,

unfortunately, I'm everything else but a developer, so please be a bit
patient with me.

As indicated by the subject, I got annoyed by the error message
mentioned flooding my log files. Comparing ftdi_sio.c to some of the
other usb-serial converter drivers, I decided to apply the following
small patch:


--- linux-2.6.10.orig/drivers/usb/serial/ftdi_sio.c 2004-12-24 
21:35:24.0 +
+++ linux-2.6.10/drivers/usb/serial/ftdi_sio.c  2005-01-29 17:10:11.0 
+
@@ -1518,7 +1518,7 @@
dbg(%s port %d, %d bytes, __FUNCTION__, port-number, count);
 
if (count == 0) {
-   err(write request of 0 bytes);
+   dbg(%s - write request of 0 bytes, __FUNCTION__);
return 0;
}



It solved my problem but I can't judge, of course, whether the use of
err() instead of dbg() is justified or even common in this place, as,
for instance, ftdi_sio.c is considered experimental. Therefore I would
be grateful to get a short response.

Thank you very much in advance,

Elias
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


How do I get a list of all pids on 2.6? (what's wrong with this code)

2005-01-29 Thread Jed Brazos
Hi,

  I'm trying to list all of the tasks and their
children. (Im using a 2.6.5-7 kernel)

  The code below does not list all of the pids as
compared to the /proc entries.

  Why does the following code not list all of the
active pids in the system?

please cc this id.

  ---




void list_pids(void)
{
struct task_struct *tp;
struct list_head   *_p;
struct list_head   *_n;
struct task_struct *p;


read_lock(tasklist_lock);
for (tp = init_task;  (tp = next_task(tp)) !=
init_task; ) {
 printk([parent]  pid =%d\n ,tp-pid );
 list_for_each_safe(_p,_n, tp-children ){
 p = list_entry(_p,struct
task_struct,sibling);
 printk(   [child]  pid =%d   \n, p-pid
);

 }
}
read_unlock(tasklist_lock);
 return ;
}






__ 
Do you Yahoo!? 
All your favorites on one personal page – Try My Yahoo!
http://my.yahoo.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: AT keyboard dead on 2.6

2005-01-29 Thread Vojtech Pavlik
On Fri, Jan 28, 2005 at 09:22:20PM +0100, Wiktor wrote:
 Hi,
 
 We do test AUX port and your port appears to be perfectly functional
 from the kernel point of view - it porperly responds to AUX_LOOP
 commands, does not claim to support MUX mode and KBC properly sets
 status register when asked to disable interface...
 
 ok, but how AUX block KBD port? if procesor-interface works, it 
 shouldn't disturb communication in any way!

The AUX and KBD ports share the same processor interface. If the AUX
port is enabled, and somehow keeps the interface for itself, then the
keyboard wouldn't work.

For some reason, however, the keyboard is recognized, which means it
_can_ communicate with the kernel. I don't understand why it doesn't, at
the moment.

 how it is possible that 
 tests do not detect broken down port? 

The kernel issues the AUX_TEST command, which instructs the port
controller to test whether the port is OK. And the controller returns
with Yes, it is.

 if kernel enables it in some way 
 (when disabling port from command line, KBD works ok), it should be 
 detected that AUX does not work correctly and lock it somehow? 

Remember, it's the keyboard that doesn't work in that case. How the
kernel should know the AUX port is the cause, and how it should discern
that from the user not typing?

 can it be 
 etermined by analyzing data flow? 

No.

 or maybe tests are not enought good, 
 maybe some corelations when using both KBD and AUX exist and are not 
 tested? as my keyboard works now, i'm not keen on solving this, but to 
 make the world better and dominate it, some runtime hardware failures 
 handling could be added.
 
We're pretty happy when it works on functional hardware at the moment.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3/3] Fix 'event field not found' message filling logs

2005-01-29 Thread Vojtech Pavlik
You can pull this changeset from:
bk://kernel.bkbits.net/vojtech/for-linus

===

[EMAIL PROTECTED], 2005-01-29 13:09:24+01:00, [EMAIL PROTECTED]
  input: Ignore non-LED events in hid-input hidinput_event(). This gets rid
 of the event field not found message caused by EV_MSC type events.
  
  Signed-off-by: Vojtech Pavlik [EMAIL PROTECTED]


 hid-input.c |3 +++
 1 files changed, 3 insertions(+)

===

diff -Nru a/drivers/usb/input/hid-input.c b/drivers/usb/input/hid-input.c
--- a/drivers/usb/input/hid-input.c 2005-01-29 17:37:11 +01:00
+++ b/drivers/usb/input/hid-input.c 2005-01-29 17:37:11 +01:00
@@ -492,6 +492,9 @@
if (type == EV_FF)
return hid_ff_event(hid, dev, type, code, value);
 
+   if (type != EV_LED)
+   return -1;
+
if ((offset = hid_find_field(hid, type, code, field)) == -1) {
warn(event field not found);
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/


Re: [PATCH] Restrict procfs permissions

2005-01-29 Thread Rene Scharfe
Al Viro wrote:
On Sat, Jan 29, 2005 at 03:45:42AM +0100, Rene Scharfe wrote:
The patch is inspired by the /proc restriction parts of the
GrSecurity patch.  The main difference is the ability to configure
the restrictions dynamically.  You can change the umask setting by
running
# mount -o remount,umask=007 /proc
Testing has been *very* light so far -- it compiles and boots.
Patch is against 2.6.11-rc2-bk6.
Comments are very welcome.

It leaves already existing inodes with whatever mode they used to
have.
I said configure the restrictions dynamically but I meant doesn't
need a recompile to change settings.  I expect the umask to be
specified in /etc/fstab and rarely changed in a running system.  With
that in mind I think the patch is useful as-is, especially because it's
so small.  But I agree, that thing is a dirty hack. :]
_IF_ you want to do that sort of things, do it right - add
-permission() that would apply that umask before checks and if you
want it to be seen in results of stat(2) - add -gettattr() and do
the same there.
Aww, that sounds expensive.  My favourite solution would be to only 
allow the umask to be changed at mount time, not when remounting.

Calling parse_options from proc_fill_super, only and not from 
proc_remount does not help very much because proc_fill_super is only 
called at boot (or proc module load time).  Is there another way?

While we are here: how would one change the uid or gid parameter? With a 
built-in proc fs the mount -a -t proc in the init scripts only results 
in a proc_remount call which (in mainline) doesn't bother looking at 
parameters at all.  The same is true for a unmount, mount sequence.

Thanks,
Rene
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: OpenOffice crashes due to incorrect access permissions on /dev/dri/card*

2005-01-29 Thread Jon Smirl
On Sat, 29 Jan 2005 13:02:51 +, Richard Hughes [EMAIL PROTECTED] wrote:
 On Sat, 29 Jan 2005 12:49:16 +, Richard Hughes wrote:
  Note, that strace glxgears gives exactly the same output, going from 0 to
  14 and then seg-faulting, so it's *not just a oo problem*.
 
 I know it's bad to answer your own post, but here goes.
 
 I changed my /etc/udev/permissions.d/50-udev.permissions config to read:
 
 dri/*:root:root:0666
 
 changing it from
 
 dri/*:root:root:0660
 
 And oowriter and glxgears work from bootup. Shall I file a bug with udev?

Your user ID needs to belong to group DRI.

-- 
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/


[PATCH 0/3] - Three more input fixes for 2.6.11

2005-01-29 Thread Vojtech Pavlik
Hi!

The previous set introduced one bug, mostly harmless, but pretty
annoying - the hid-input driver fills the logs with the 'event field not
found' message. I'm sorry for that, I just tested that the patch does
what it should and didn't check the logs.

The last of these three patches fixes that.

The first fixes the MUX disabling routine in i8042 to really do
something on reboot, and the second patch from Andries adds a
documentation entry for atkbd.softraw.

Please include them before 2.6.11, as the bug described above would
cause a lot of e-mails to be sent to me.

The patches are available at

bk://kernel.bkbits.net/vojtech/for-linus

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 0/16] New set of input patches

2005-01-29 Thread Vojtech Pavlik
On Thu, Jan 27, 2005 at 01:18:55PM -0500, Dmitry Torokhov wrote:
 On Thu, 27 Jan 2005 17:36:05 +0100, Vojtech Pavlik [EMAIL PROTECTED] wrote:
  On Thu, Jan 27, 2005 at 05:15:18PM +0100, Vojtech Pavlik wrote:
  
   OK. I'll go through them, and apply as appropriate. I still need to wrap
   my mind around the start() and stop() methods and see the necessity. I
   still think a variable in the serio struct, only accessed by the serio.c
   core driver itself (and never by the port driver) that'd cause all
   serio_interrupt() calls to be ignored until set in the asynchronous port
   registration would be well enough.
  
  I've read he start() and stop() code, and I came to the conclusion
  again that we don't need them as serio port driver methods. i8042 uses
  them to set the exists variable only and uses that variable _solely_ for
  the purpose of skipping calls to serio_interrupt(), serio_cleanup() and
  serio_unregister().
  
  By instead checking a member of the serio struct in these functions, and
  doing nothing if not set, we achieve the same goal, without adding extra
  cruft to the interface, making it allowed to call these serio functions
  on a non-registered or half-registered serio struct, with the effect
  being defined to nothing.
  
 
 No, you can not peek into serio structure from a driver, not when it
 was dynamically allocated and can be gone at any time. Please consider
 the following screnario when shutting down 8042 when you have a MUX
 with several ports:
 
 The rough call sequence is:
 i8042_exit
   serio_unregister_port
  driver-disconnect
 serio_close
i8042-close
  free(serio)
 
 We need to keep interrupts passed to serio core until serio_close is
 completed so device properly ACKs/responds to cleanup commands.
 Additionally, in i8042 close we do not free IRQ until last port is
 unregistered nor we disable the port because we want to support
 hotplugging. If interrupt comes after port was freed but before
 serio_unregister_port has returned i8042_interrupt will call
 serio_interrupt for port that was just free()ed. Special flag in serio
 will not help because you need to know that port pointer is valid. You
 could try pinning the port in memory buy taking a refernce but then
 asynchronous unregister is not possible and it is needed in some
 cases.
 
 I think that having these 2 interface functions helps clearly define
 these sequence points when port can/can not be used, simplifies logic
 and alerts driver authors of this potential problem.
 
You're right. I forgot that serio isn't anymore tied to the driver and
can cease to exist on its own asynchronously. However, I'm still not
sure whether it's worth it. We might as well simply drop the unregister
call in i8042_open for AUX completely and forget about asynchronous
unregisters and use normal refcounting. As far as grep knows, it's the
only user.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: Possible bug in keyboard.c (2.6.10)

2005-01-29 Thread Vojtech Pavlik
On Fri, Jan 28, 2005 at 10:59:39PM +0100, Andries Brouwer wrote:
 On Fri, Jan 28, 2005 at 12:10:05PM +0100, Vojtech Pavlik wrote:
 
  And, btw, raw mode in 2.6 is not badly broken. It works as it is
  intended to. If you want the 2.4 behavior on x86, you just need to
  specify atkbd.softraw=0 on the kernel command line.
 
 Thanks for pointing that out - I should have read patch-2.6.9 more
 carefully. I'll add that to the setkeycodes.8 man page.
 
 Nevertheless I disagree a bit. raw mode is by definition the mode
 where scan codes are passed unmodified to user space.
 So before 2.6.9 this was just broken, and since 2.6.9 it is broken
 by default but there is a boot option to make it work.

The problem is that users wouldn't be happy if I passed USB usage codes
when they enable raw mode with an USB keyboard.

The expectation is that 'it will work'.

Because of that, the 'softraw=0' option _only_ works for AT and PS/2
keyboards, with any other keyboard type it has no effect.

 What is the reason that you do not make this the default?

To have all keyboard types behave the same, instead of having a single
exception, although I admit that the exception would be for the most
common case.

 The current default is really messy and confusing, especially
 when people have to map keys using setkeycodes.

The emulated rawmode is there mainly for X. If it weren't for X, I
wouldn't bother generating rawmode for keyboards other than PS/2, and
for PS/2 I'd have kept the true raw data there.

However, on 2.6, where you can have more than one keyboard, it'd be
better to use the EVIOCSKEYCODE ioctl on the event device instead of the
KDSKEYCODE ioctl on the console, as the later only changes the first
found keyboard.

Also, if setkeycodes used the event device, it'd get the raw scancodes
easily, as they're embedded in the event stream together with the
keycodes.

I'd hoped someone of the lineak/.../... multimedia key people will make
such an utility, but now I see that what one doesn't do himself, doesn't
happen. I will write it, possibly as a patch to setkeycodes.

 BTW, now that I read the corresponding code:
 
 if (atkbd_softrepeat)
 atkbd_softraw = 1;
 
 if (!atkbd_softrepeat) {
 atkbd-dev.rep[REP_DELAY] = 250;
 atkbd-dev.rep[REP_PERIOD] = 33;
 } else atkbd_softraw = 1;
 
 The else part is superfluous.

It indeed is. It's been removed, too.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: AT keyboard dead on 2.6

2005-01-29 Thread Vojtech Pavlik
On Fri, Jan 28, 2005 at 08:39:42PM +0100, Wiktor wrote:

 Hi, IT WORKED!
 
 Please try i8042.noaux=1. You say you're using a serial mouse in your
 other e-mail, so the system may not have an AUX port yet the kernel
 thinks it does. This may cause the keyboard to stop responding.
 
 command line linux-new init=/bin/bash i8042.noaux=1 atkbd.reset=1 
 booted 2.6.8.1 kernel with working keyboard. reset succeded. If AUX port 
 is what not-keen-on-hardware people call PS/2 port, the problem is 
 solved. my mainboard has damaged PS/2 port - it is detected but it does 
 NOT work. Thanks for paying attention.
 
Yes, the AUX port and PS/2 mouse port are two names for the same thing.

Do you still need atkbd.reset=1?

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: Possible bug in keyboard.c (2.6.10)

2005-01-29 Thread Vojtech Pavlik
On Sat, Jan 29, 2005 at 01:11:08PM +0100, Roman Zippel wrote:

  I'm very sorry about the locking, but the thing grew up in times of
  kernel 2.0, which didn't require any locking. There are a few possible
  races with device registration/unregistration, and it's on my list to
  fix that, however under normal operation there shouldn't be any need for
  locks, as there are no complex structures built that'd become
  inconsistent. 
 
 I wouldn't say that there is no need for that, but that these events are 
 rather rare, but it can happen.

Sorry, I meant to say that of course locking is needed for protecting
the device and handler lists, but that the event delivery path itself
is in my opinion safe, and that there is no need to eg. lock
input_event() against concurrent use by different callers.

 Unfortunately the lack of locking is all 
 over the keyboard/vc/tty layer. It would have been nice if input had 
 introduced some improvement here.
 This seriously becomes a problem as soon we want to allow the user to 
 dynamically attach/detach devices.

I agree, and I plan to fix the locking at least in input and keyboard.
How far it'll go into vc/tty I can't promise.`

   I tried to find a few times to find any discussion about the input
   layer design, but I couldn't find anything.
  
  You have to search in very old archives. There was quite a lot of it,
  and it was going off on a lot of tangents. In the end, I just wrote it.
 
 How old and which archives?

1999 I think, some discussion was on L-K, the rest on
[EMAIL PROTECTED], which, unfortunately, doesn't have
a web-based archive.

   - a single input device structure for all types: this structure is quite 
   big, where most of its contents is irrelevant for most devices.
  
  I actually think this is a big plus. 
  
  Real word devices cannot be confined into predefined structures, as
  hardware develops, mice get more buttons, wheels, force feedback, 
 
 That doesn't necessarilly mean we have to pack everything into a single 
 structure. E.g. we present pci boards with multiple functions as multiple 
 devices, the same can be done for input devices. More important is that 
 kernel drivers only expect a certain class of devices, e.g. the keyboard 
 driver only needs the keyboard related parts and would also allow us to 
 add more keyboard specific callbacks instead of sending events.

The USB HID devices often are crossing the device type boundaries. A
keyboard with a few mouse buttons, for example. Yes, we could split it,
but I really doubt the gain.

The GGI people went the way of predefined device types ...

  The intention here is that we have two types of events, input and
  output. Most events are input (REL, ABS, ...), while some travel the
  opposite direction. For simplicity, the interface is the same -
  input_event(), which then, based on the event type decides where to
  forward it - whether up or down the stream (or both, where other users
  of the device may be interested in the change).
 
 This is rather a hint that the abstraction is wrong, e.g. why not send 
 sound events to the pckbd _handler_? A device should just send input 
 events and handlers handle them and with sysfs we should actually rename 
 the latter to input_drivers (it's less confusing this way).

You imply that the atkbd module would register itself both as an input
device, and as an input handler? That's quite an interesting idea I
haven't thought about before.

But then all the handlers also have to register themselves as devices,
for generating the LED and Sound events. Probably we then could get rid
of the handlers altogether and have devices only, which would both send
and receive events.

It would work, but to me this looks even more confusing. 

 Some other problems I have with the current design:
 - unified keyboard/mouse device: one rather annoying problem, which is 
 neither solved by the input system or the linuxconsole patches, is that 
 one can't use keyboards with different mappings (e.g. german and english 
 is what I have here).

The unified mouse device was planned for backward compatibility only,
unfortunately it stuck, since for userspace that was the easiest way to
deal with hotplug.

The single keyboard similarly was the easiest way how to plug the input
into keyboard.c. James Simmons was working on the vc part of the code,
but it never made it there. It sort of lives in the linuxconsole
patches, but was never really finished either.

 I have a patch which makes the keymap data more 
 dynamic and assigns it to keyboard device,

Cool! How do you load the keymaps for the specific devices? How do you
assign the devices to vcs? Can a user have per-vc keymaps?

 which has the positive side effect that all keyboards don't have to
 send the same keycodes anymore (and we don't have to break all the
 keyboards anymore which don't use AT style keycodes).

Well, I think the fact that the input layer uses an unified set of
numbers for the keys really helps in 

  1   2   >