On Monday 13 August 2007 02:12, Jens Axboe wrote:
> > It is a system wide problem. Every block device needs throttling,
> > otherwise queues expand without limit. Currently, block devices
> > that use the standard request library get a slipshod form of
> > throttling for free in the form of limit
--- David Howells <[EMAIL PROTECTED]> wrote:
> Casey Schaufler <[EMAIL PROTECTED]> wrote:
>
> > The specification of your push interface that the push operation
> > not affect how others access the process is OK for SELinux, but
> > not for any other MAC scheme that I've dealt with, and I think
On Mon, Aug 13, 2007 at 10:56:53PM +0200, Andi Kleen wrote:
> On Mon, Aug 13, 2007 at 10:24:52PM +0200, Michal Piotrowski wrote:
> > On 13/08/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
> > > > Unclassified
> > > >
> > > > Subject : reset during bootup - 2.6.23-rc2 (git d23cf676)
> > >
> > >
On Mon, Aug 13, 2007 at 10:24:52PM +0200, Michal Piotrowski wrote:
> On 13/08/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
> > > Unclassified
> > >
> > > Subject : reset during bootup - 2.6.23-rc2 (git d23cf676)
> >
> > This is already fixed in mainline
>
> commit b8d3f2448b8f4ba24f301e235855
On 13/08/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
> > Unclassified
> >
> > Subject : reset during bootup - 2.6.23-rc2 (git d23cf676)
>
> This is already fixed in mainline
commit b8d3f2448b8f4ba24f301e23585547ba1acc1f04
>
> There is a real regression with failing builds on some old binuti
Casey Schaufler <[EMAIL PROTECTED]> wrote:
> The specification of your push interface that the push operation
> not affect how others access the process is OK for SELinux, but
> not for any other MAC scheme that I've dealt with, and I think
> that's most of them. Nuts. Smack, for example, uses exa
> Unclassified
>
> Subject : reset during bootup - 2.6.23-rc2 (git d23cf676)
This is already fixed in mainline
There is a real regression with failing builds on some old binutils on
x86-64 know, but I don't know how to fix it.
-Andi
-
To unsubscribe from this list: send the line "unsub
On Mon, 2007-08-13 at 19:59 +0200, Michal Piotrowski wrote:
> FS
>
> Subject : NFSv4 poops itself
> References : http://lkml.org/lkml/2007/7/27/144
> Last known good : ?
> Submitter : Jeff Garzik <[EMAIL PROTECTED]>
> Caused-By : ?
> Handled-By : Trond Myklebust <[E
On 13/08/07, Trond Myklebust <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-08-13 at 19:59 +0200, Michal Piotrowski wrote:
>
> > FS
> >
> > Subject : NFSv4 poops itself
> > References : http://lkml.org/lkml/2007/7/27/144
> > Last known good : ?
> > Submitter : Jeff Garzik <[EMAIL PROT
On Aug 13 2007 19:59, Michal Piotrowski wrote:
>
>Subject : Kconfig prompts without help text
>References : http://lkml.org/lkml/2007/7/16/326
>Last known good : ?
>Submitter : Stefan Richter <[EMAIL PROTECTED]>
>Caused-By : ?
>Handled-By : Jan Engelhardt <[EMAIL PROT
Hi all,
Here is a list of some known regressions in 2.6.23-rc3.
Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions
List of Aces
NameRegressions fixed since 21-Jun-2007
Adrian Bunk9
Andi Kleen
Hi all,
Here is a list of some known regressions in 2.6.23-rc3
with patches available.
Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions
List of Aces
NameRegressions fixed since 21-Jun-2007
Adrian Bunk9
Bodo Eggert wrote:
> Warning: I'm only looking at the patch.
>
> You are supposed to print an error message for a user, not to write in a
> chat window to a 1337 script kiddie. OK, you just matched the current style,
> and your patch is IMHO OK for a quick security fix, but:
>
> - Security fixes s
--- David Howells <[EMAIL PROTECTED]> wrote:
> Casey Schaufler <[EMAIL PROTECTED]> wrote:
>
> > > (1) int security_get_context(void **_context);
> > >
> > > This allocates and gives the caller a blob that describes the current
> > > context of all the LSM module states attached to the cur
Casey Schaufler <[EMAIL PROTECTED]> wrote:
> > (1) int security_get_context(void **_context);
> >
> > This allocates and gives the caller a blob that describes the current
> > context of all the LSM module states attached to the current task and
> > stores a pointer to it in *_conte
--- David Howells <[EMAIL PROTECTED]> wrote:
> Stephen Smalley <[EMAIL PROTECTED]> wrote:
>
> > Seems like over-design - we don't need to support LSM stacking, and we
> > don't need to support pushing/popping more than one level of context.
>
> It will, at some point hopefully, be possible for
--- Stephen Smalley <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-08-13 at 15:51 +0100, David Howells wrote:
> ...
> > Actually, to address Stephen Smalley's requirements also, how about making
> > things a bit more complex. Have the following suite of functions:
> >
> > (1) int security_get_co
Stephen Smalley <[EMAIL PROTECTED]> wrote:
> Seems like over-design - we don't need to support LSM stacking, and we
> don't need to support pushing/popping more than one level of context.
It will, at some point hopefully, be possible for someone to try, say, NFS
exporting a cached ISO9660 mount (
--- Stephen Smalley <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-08-13 at 11:54 +0100, David Howells wrote:
> > Casey Schaufler <[EMAIL PROTECTED]> wrote:
> >
> > > Sigh. So it's not only SELinux specific, but RedHat specific as well.
> >
> > *Blink*. How did you come to that conclusion?
> >
> >
On Mon, 2007-08-13 at 15:51 +0100, David Howells wrote:
> Casey Schaufler <[EMAIL PROTECTED]> wrote:
>
> > I haven't looked into the issues at all and I bet there are plenty,
> > maybe in audit and places outside of the security realm, but this
> > looks like a clean approach from the LSM interfac
Casey Schaufler <[EMAIL PROTECTED]> wrote:
> I haven't looked into the issues at all and I bet there are plenty,
> maybe in audit and places outside of the security realm, but this
> looks like a clean approach from the LSM interface standpoint. Do
> you want the entire task or just task->security
Hello.
There are several locations that handle
-EIOCBQUEUED error code.
According to include/linux/errno.h ,
it seems this code is NFS related and
caller will receive completion event later.
But I couldn't figure out where is the beginning point
and what is happening.
What functions are called be
On Mon, 2007-08-13 at 11:54 +0100, David Howells wrote:
> Casey Schaufler <[EMAIL PROTECTED]> wrote:
>
> > Sigh. So it's not only SELinux specific, but RedHat specific as well.
>
> *Blink*. How did you come to that conclusion?
>
> > > (3) The cache driver wants to access the files in the cach
--- David Howells <[EMAIL PROTECTED]> wrote:
> Casey Schaufler <[EMAIL PROTECTED]> wrote:
>
> > Sigh. So it's not only SELinux specific, but RedHat specific as well.
>
> *Blink*. How did you come to that conclusion?
>
> > > (3) The cache driver wants to access the files in the cache, but it
On Sat, 2007-08-11 at 08:56 -0700, Casey Schaufler wrote:
> --- David Howells <[EMAIL PROTECTED]> wrote:
>
> > Casey Schaufler <[EMAIL PROTECTED]> wrote:
> >
> > > How would you expect an LSM that is not SELinux to interface with
> > > CacheFiles?
> >
> > You have to understand that I didn't kno
On Monday 13 August 2007 05:18, Evgeniy Polyakov wrote:
> > Say you have a device mapper device with some physical device
> > sitting underneath, the classic use case for this throttle code.
> > Say 8,000 threads each submit an IO in parallel. The device mapper
> > mapping function will be called
[EMAIL PROTECTED] wrote:
Would this just be relevant to network devices or would it improve
support for jostled usb and sata hot-plugging I wonder?
good question, I suspect that some of the error handling would be
similar (for devices that are unreachable not haning the system for
example), b
On Mon, 13 Aug 2007 08:01:34 -0400
Jeff Layton <[EMAIL PROTECTED]> wrote:
> On Sat, 11 Aug 2007 03:57:39 +0100
> Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> >
> > I like the idea of checking ia_valid after return a lot. But instead of
> > going BUG() it should just do the default action, that
On Mon, Aug 13, 2007 at 05:18:14AM -0700, Daniel Phillips ([EMAIL PROTECTED])
wrote:
> > If limit is for
> > 1gb of pending block io, and system has for example 2gbs of ram (or
> > any other resonable parameters), then there is no way we can deadlock
> > in allocation, since it will not force pag
On Mon, Aug 13, 2007 at 04:18:03AM -0700, Daniel Phillips ([EMAIL PROTECTED])
wrote:
> > No. Since all requests for virtual device end up in physical devices,
> > which have limits, this mechanism works. Virtual device will
> > essentially call either generic_make_request() for new physical
> > de
On Monday 13 August 2007 05:04, Evgeniy Polyakov wrote:
> On Mon, Aug 13, 2007 at 04:04:26AM -0700, Daniel Phillips
([EMAIL PROTECTED]) wrote:
> > On Monday 13 August 2007 01:14, Evgeniy Polyakov wrote:
> > > > Oops, and there is also:
> > > >
> > > > 3) The bio throttle, which is supposed to prev
On Mon, Aug 13, 2007 at 04:04:26AM -0700, Daniel Phillips ([EMAIL PROTECTED])
wrote:
> On Monday 13 August 2007 01:14, Evgeniy Polyakov wrote:
> > > Oops, and there is also:
> > >
> > > 3) The bio throttle, which is supposed to prevent deadlock, can
> > > itself deadlock. Let me see if I can reme
On Sat, 11 Aug 2007 03:57:39 +0100
Christoph Hellwig <[EMAIL PROTECTED]> wrote:
>
> I like the idea of checking ia_valid after return a lot. But instead of
> going BUG() it should just do the default action, that we can avoid
> touching all the filesystem and only need to change those that need
>
On Monday 13 August 2007 04:03, Evgeniy Polyakov wrote:
> On Mon, Aug 13, 2007 at 03:12:33AM -0700, Daniel Phillips
([EMAIL PROTECTED]) wrote:
> > > This is not a very good solution, since it requires all users of
> > > the bios to know how to free it.
> >
> > No, only the specific ->endio needs t
On Monday 13 August 2007 01:23, Evgeniy Polyakov wrote:
> On Sun, Aug 12, 2007 at 10:36:23PM -0700, Daniel Phillips
([EMAIL PROTECTED]) wrote:
> > (previous incomplete message sent accidentally)
> >
> > On Wednesday 08 August 2007 02:54, Evgeniy Polyakov wrote:
> > > On Tue, Aug 07, 2007 at 10:55:
On Monday 13 August 2007 01:14, Evgeniy Polyakov wrote:
> > Oops, and there is also:
> >
> > 3) The bio throttle, which is supposed to prevent deadlock, can
> > itself deadlock. Let me see if I can remember how it goes.
> >
> > * generic_make_request puts a bio in flight
> > * the bio gets pas
On Mon, Aug 13, 2007 at 03:12:33AM -0700, Daniel Phillips ([EMAIL PROTECTED])
wrote:
> > This is not a very good solution, since it requires all users of the
> > bios to know how to free it.
>
> No, only the specific ->endio needs to know that, which is set by the
> bio owner, so this knowledge
Casey Schaufler <[EMAIL PROTECTED]> wrote:
> Sigh. So it's not only SELinux specific, but RedHat specific as well.
*Blink*. How did you come to that conclusion?
> > (3) The cache driver wants to access the files in the cache, but it's
> > running in the security context of either the af
On Monday 13 August 2007 03:22, Jens Axboe wrote:
> I never compared the bio to struct page, I'd obviously agree that
> shrinking struct page was a worthy goal and that it'd be ok to uglify
> some code to do that. The same isn't true for struct bio.
I thought I just said that.
Regards,
Daniel
-
On Mon, Aug 13, 2007 at 11:03:21AM +1000, David Chinner wrote:
> > --- linux-2.6.23-rc2-mm2.orig/fs/buffer.c
> > +++ linux-2.6.23-rc2-mm2/fs/buffer.c
> > @@ -1713,7 +1713,6 @@ done:
> > * The page and buffer_heads can be released at any time from
> > * here on.
> >
On Mon, Aug 13 2007, Daniel Phillips wrote:
> On Monday 13 August 2007 03:06, Jens Axboe wrote:
> > On Mon, Aug 13 2007, Daniel Phillips wrote:
> > > Of course not. Nothing I said stops endio from being called in the
> > > usual way as well. For this to work, endio just needs to know that
> > > o
On Monday 13 August 2007 03:06, Jens Axboe wrote:
> On Mon, Aug 13 2007, Daniel Phillips wrote:
> > Of course not. Nothing I said stops endio from being called in the
> > usual way as well. For this to work, endio just needs to know that
> > one call means "end" and the other means "destroy", thi
On Monday 13 August 2007 02:18, Evgeniy Polyakov wrote:
> On Mon, Aug 13, 2007 at 02:08:57AM -0700, Daniel Phillips
([EMAIL PROTECTED]) wrote:
> > > But that idea fails as well, since reference counts and IO
> > > completion are two completely seperate entities. So unless end IO
> > > just happens
On Mon, Aug 13 2007, Daniel Phillips wrote:
> On Monday 13 August 2007 02:13, Jens Axboe wrote:
> > On Mon, Aug 13 2007, Daniel Phillips wrote:
> > > On Monday 13 August 2007 00:45, Jens Axboe wrote:
> > > > On Mon, Aug 13 2007, Jens Axboe wrote:
> > > > > > You did not comment on the one about put
On Monday 13 August 2007 02:13, Jens Axboe wrote:
> On Mon, Aug 13 2007, Daniel Phillips wrote:
> > On Monday 13 August 2007 00:45, Jens Axboe wrote:
> > > On Mon, Aug 13 2007, Jens Axboe wrote:
> > > > > You did not comment on the one about putting the bio
> > > > > destructor in the ->endio handl
On Mon, Aug 13, 2007 at 02:08:57AM -0700, Daniel Phillips ([EMAIL PROTECTED])
wrote:
> > But that idea fails as well, since reference counts and IO completion
> > are two completely seperate entities. So unless end IO just happens
> > to be the last user holding a reference to the bio, you cannot
On Mon, Aug 13 2007, Daniel Phillips wrote:
> On Monday 13 August 2007 00:45, Jens Axboe wrote:
> > On Mon, Aug 13 2007, Jens Axboe wrote:
> > > > You did not comment on the one about putting the bio destructor
> > > > in the ->endio handler, which looks dead simple. The majority of
> > > > cases
On Mon, Aug 13 2007, Daniel Phillips wrote:
> On Monday 13 August 2007 00:28, Jens Axboe wrote:
> > On Sun, Aug 12 2007, Daniel Phillips wrote:
> > > Right, that is done by bi_vcnt. I meant bi_max_vecs, which you can
> > > derive efficiently from BIO_POOL_IDX() provided the bio was
> > > allocated
On Monday 13 August 2007 00:45, Jens Axboe wrote:
> On Mon, Aug 13 2007, Jens Axboe wrote:
> > > You did not comment on the one about putting the bio destructor
> > > in the ->endio handler, which looks dead simple. The majority of
> > > cases just use the default endio handler and the default
> >
On Aug 12 2007 20:21, [EMAIL PROTECTED] wrote:
>
> per the message below MD (or DM) would need to be modified to work
> reasonably well with one of the disk components being over an
> unreliable link (like a network link)
Does not dm-multipath do something like that?
> are the MD/DM maintainers
On Monday 13 August 2007 00:28, Jens Axboe wrote:
> On Sun, Aug 12 2007, Daniel Phillips wrote:
> > Right, that is done by bi_vcnt. I meant bi_max_vecs, which you can
> > derive efficiently from BIO_POOL_IDX() provided the bio was
> > allocated in the standard way.
>
> That would only be feasible,
On Mon, 13 Aug 2007, David Greaves wrote:
[EMAIL PROTECTED] wrote:
per the message below MD (or DM) would need to be modified to work
reasonably well with one of the disk components being over an unreliable
link (like a network link)
are the MD/DM maintainers interested in extending their
On Sun, Aug 12, 2007 at 10:36:23PM -0700, Daniel Phillips ([EMAIL PROTECTED])
wrote:
> (previous incomplete message sent accidentally)
>
> On Wednesday 08 August 2007 02:54, Evgeniy Polyakov wrote:
> > On Tue, Aug 07, 2007 at 10:55:38PM +0200, Jens Axboe wrote:
> >
> > So, what did we decide? To
Hi Daniel.
On Sun, Aug 12, 2007 at 04:16:10PM -0700, Daniel Phillips ([EMAIL PROTECTED])
wrote:
> Your patch is close to the truth, but it needs to throttle at the top
> (virtual) end of each block device stack instead of the bottom
> (physical) end. It does head in the direction of eliminatin
On Sun, Aug 12, 2007 at 11:44:00PM -0700, Daniel Phillips ([EMAIL PROTECTED])
wrote:
> On Sunday 12 August 2007 22:36, I wrote:
> > Note! There are two more issues I forgot to mention earlier.
>
> Oops, and there is also:
>
> 3) The bio throttle, which is supposed to prevent deadlock, can itsel
[EMAIL PROTECTED] wrote:
per the message below MD (or DM) would need to be modified to work
reasonably well with one of the disk components being over an unreliable
link (like a network link)
are the MD/DM maintainers interested in extending their code in this
direction? or would they prefer
Paul Clements wrote:
Well, if people would like to see a timeout option, I actually coded up
a patch a couple of years ago to do just that, but I never got it into
mainline because you can do almost as well by doing a check at
user-level (I basically ping the nbd connection periodically and if
On Mon, Aug 13 2007, Jens Axboe wrote:
> > You did not comment on the one about putting the bio destructor in
> > the ->endio handler, which looks dead simple. The majority of cases
> > just use the default endio handler and the default destructor. Of the
> > remaining cases, where a specializ
On Sun, Aug 12 2007, Daniel Phillips wrote:
> On Tuesday 07 August 2007 13:55, Jens Axboe wrote:
> > I don't like structure bloat, but I do like nice design. Overloading
> > is a necessary evil sometimes, though. Even today, there isn't enough
> > room to hold bi_rw and bi_flags in the same variabl
On Sunday 12 August 2007 22:36, I wrote:
> Note! There are two more issues I forgot to mention earlier.
Oops, and there is also:
3) The bio throttle, which is supposed to prevent deadlock, can itself
deadlock. Let me see if I can remember how it goes.
* generic_make_request puts a bio in fl
60 matches
Mail list logo
