On Mon, Jul 11, 2005 at 09:31:39AM -0400, Stephen Smalley wrote:
> I was planning on leaving the security_inode_post* hooks intact at least
> until the other filesystem types that support security xattrs have all
> been converted to use the new hook,
Having these transactional guarantees just for
On Mon, Jul 11, 2005 at 08:53:02AM -0400, Stephen Smalley wrote:
> > Please set the xattr from security_inode_init_security by using ->setxattr,
> > that
> > way we don't need to duplicate this code everywhere.
>
> That doesn't allow us to ensure that the setting of the xattr occurs in
> the same
Hi,
On Mon, 11 Jul 2005, Horst von Brand wrote:
> > I don't generally disagree with that, I just think that defines are not
> > part of that list.
>
> Covered in "bad coding style" and "hard to read code", at least.
Somehow I missed the last lkml debate about where simple defines where a
prob
Roman Zippel <[EMAIL PROTECTED]> wrote:
> On Sun, 10 Jul 2005, Pekka Enberg wrote:
[...]
> > Would you please be so kind to define your criteria for things that
> > "need fixing" so we could see if can reach some sort of an agreement on
> > this. My list is roughly as follows:
> >
> > - Errone
Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
> On Sun, Jul 10, 2005 at 09:21:42PM +0300, Pekka Enberg wrote:
> > Hmm. So we disagree on that issue as well. I think the point of review
> > is to improve code and help others conform with the existing coding
> > style which is why I find it strange that
On Mon, Jul 11, 2005 at 11:07:17AM -0500, Michael C Thompson wrote:
> > > Ultimately, the part where we differ most, is the processing of
> > > information in
> > > fs/dcache.c to give dynamic updates in response to file system activity
> > > (such
> > > as attaching audit information to an audit
Hi,
On Mon, 2005-07-11 at 17:14, Jan Kara wrote:
> Which kernel was that? We had a similar bug in 2.6.11 kernel but it
> should be fixed in 2.6.12.
This was 2.6.13-rc2 from today's git.
> I suppose you get the same BUG if you run
> just quotaoff(8), right?
I just tried --- yes.
Cheers,
St
Hello,
> On Fri, 2005-07-08 at 14:58, Stephen Smalley wrote:
> > This patch modifies ext3 to call the inode_init_security LSM hook to
> > obtain the security attribute for a newly created inode and to set the
> > resulting attribute on the new inode as part of the same transaction.
> > This para
Hi,
On Fri, 2005-07-08 at 14:58, Stephen Smalley wrote:
> This patch modifies ext3 to call the inode_init_security LSM hook to
> obtain the security attribute for a newly created inode and to set the
> resulting attribute on the new inode as part of the same transaction.
> This parallels the exist
Hello,
attached patch adds an operation SWRITE to ll_rw_block(). When this
operation is specified ll_rw_block() waits for a buffer lock and doesn't
just skip the locked buffer. Under some circumstances we need to make
sure that current data are really being sent to disk and the old
ll_rw_block
On Mon, 2005-07-11 at 00:40 +0100, Christoph Hellwig wrote:
> On Fri, Jul 08, 2005 at 09:25:21AM -0400, Stephen Smalley wrote:
> > The following patch set enables atomic security labeling of newly
> > created inodes by altering the fs code to invoke a new LSM hook to
> > obtain the security attribu
On Mon, 2005-07-11 at 00:39 +0100, Christoph Hellwig wrote:
> On Fri, Jul 08, 2005 at 09:55:14AM -0400, Stephen Smalley wrote:
> > +int
> > +ext2_init_security(struct inode *inode, struct inode *dir)
> > +{
> > + int err;
> > + size_t len;
> > + void *value;
> > + char *name;
> > +
> > +
Jens Axboe wrote:
On Fri, Jul 01 2005, Bryan Henderson wrote:
Wouldn't a commercial class drive that ignores explicit flushes be
infamous? I'm ready to accept that there are SCSI drives that cache
writes in volatile storage by default (but frankly, I'm still skeptical),
but I'm not read
Web sayfamizi ziyaret ediniz
Tel : 0212 521 11 11 - 521 04 04 - 521 36 96 - 531 76 18 - 532 91 11
Sinirsiz Müsteri Memnuniyetini Esas Alarak 30 Yildir ilkeli ve Kaliteli Hizmet
Vermektedir.
Vade Takas yapilir.
2 El Otomotivde Tek isim
Kaliteye Çagri ...Hizmete Çagri...Güvene Çagri...
Web : http://
On Fri, 2005-07-01 at 13:26 +0530, Suparna Bhattacharya wrote:
> Has anyone else noticed major throughput regressions for random
> reads/writes with aio-stress in 2.6.12 ?
> Or have there been any other FS/IO regressions lately ?
>
> On one test system I see a degradation from around 17+ MB/s to 1
15 matches
Mail list logo
