Re: Serial driver - overrun possible to overrun flip buffer? (2.4.0-test7)

From: Russell King [EMAIL PROTECTED] Date: Fri, 1 Sep 2000 16:23:39 +0100 (BST) At the marked line (! - line 647), what if flip.count is equal to TTY_FLIPBUF_SIZE? Surely we're writing to a character outside the flag_buf_ptr array? If that is the case, should we not move this

Re: 512 byte magic multiplier (was: Large File support and blocks)

From: Daniel Phillips [EMAIL PROTECTED] Date:Fri, 01 Sep 2000 20:49:14 +0200 Curiously, this field is measured in 512 byte units, giving a 2TB Ext2 filesize limit. That's starting to look uncomfortably small - I can easily imagine a single database file wanting to be

Re: thread group comments

From: Ulrich Drepper [EMAIL PROTECTED] Date:01 Sep 2000 14:52:28 -0700 1st Problem: One signal handler process process-wide What is handled correctly now is sending signals to the group. Also that every thread has its mask. But there must be exactly one signal

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux

Date:Wed, 6 Sep 2000 01:43:47 +0100 (BST) From: Alex Buell [EMAIL PROTECTED] Only, with the former, I get to restart the application everytime it croaks, with the latter (modules excluded) I have to reboot. This is much more time consuming and means you really have to

Re: Using Yarrow in /dev/random

Date:Mon, 11 Sep 2000 13:08:59 + From: Pravir Chandra [EMAIL PROTECTED] I've been working to change the implementation of /dev/random over to the Yarrow-160a algorithm created by Bruce Schneier and John Kelsey. We've been working on parallel development for Linux and

Re: Availability of kdb

On Mon, 11 Sep 2000, Jeff V. Merkey wrote: Thanks Ted. I know, but a kernel debugger is one of those nasty pieaces of software that can quickly get out of sync if it's maintained separately from the tree -- the speed at which changes occur in Linux would render it a very difficult project

Re: Availability of kdb

Date: Mon, 11 Sep 2000 17:51:20 -0600 From: "Jeff V. Merkey" [EMAIL PROTECTED] I support source level in the kernel. Based on Andi Klein's review, I have grabbed ext2utils and am looking at a minimal int 0x13 interface to load files into memory. hardest problem here for Linux is

Re: [BUG] threaded processes get stuck in rt_sigsuspend/fillonedir/exit_notify

Date:Mon, 11 Sep 2000 18:27:30 -0700 From: David Ford [EMAIL PROTECTED] I've told Linus several times about this problems but he puts out one test release after the other without this fixed. This is kinda important, I run DNS tools which are threaded amongst numerous

Re: Using Yarrow in /dev/random

Date: Tue, 12 Sep 2000 09:56:12 + From: Pravir Chandra [EMAIL PROTECTED] i agree that the yarrow generator does place some faith on the crypto cipher and the accumulator uses a hash, but current /dev/random places faith on a crc and urandom uses a hash. No, not true. The

Re: Using Yarrow in /dev/random

Date:Wed, 13 Sep 2000 01:23:30 +0200 (CEST) From: Igmar Palsenberg [EMAIL PROTECTED] No, not true. The mixing into the entropy pool uses a twisted LFSR, but all outputs from the pool (to either /dev/random or /dev/urandom) filters the output through SHA-1 as a

Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee

Date:Wed, 13 Sep 2000 12:54:49 +0200 (CEST) From: Trond Myklebust [EMAIL PROTECTED] Don't forget that 2^20 10^6, hence if you really want units of microseconds, you actually only need to save 3 bytes worth of data per timestamp. For the purposes of NFS, however the

Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee

Date: Wed, 13 Sep 2000 22:35:10 +0200 (CEST) From: Trond Myklebust [EMAIL PROTECTED] You might be able to steal a couple of bytes and then rewrite ext2fs to mask those out from the 'i_generation' field, but it would mean that you could no longer boot your old 2.2.16 kernel without

Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee

From: "Albert D. Cahalan" [EMAIL PROTECTED] Date:Wed, 13 Sep 2000 19:20:42 -0400 (EDT) The ext2 inode has 6 obviously free bytes, 6 that are only used on filesystems marked as Hurd-type, and 8 that seem to be claimed by competing security and EA projects. So, being

Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee

Date: Thu, 14 Sep 2000 15:09:35 +0200 (CEST) From: Trond Myklebust [EMAIL PROTECTED] Would it perhaps make sense to use one of these last 'free' fields as a pointer to an 'inode entension'? If you still want ext2fs to be able to accommodate new projects and ideas, then it seems

Re: Quantum lct08 Promise Ultra66

From: "Mike" [EMAIL PROTECTED] Date:Thu, 14 Sep 2000 20:34:42 +0400 Just have compiled 2.4.0-test8 today... Nothing interesting Everything goes the same way as 2 test releases before... All my devices are detected right, but... :-( Kernel panic again at the file

Re: NFS locking bug -- limited mtime resolution means nfs_lock() doesnot provide coherency guarantee

Date: Fri, 15 Sep 2000 01:06:24 +0200 (MEST) From: [EMAIL PROTECTED] (Rogier Wolff) My suggestion is indeed effectivly (almost) doubling the inode size. However, it provides an upgrade path, where you can double-boot with a kernel that DOESN"T know about the inodes. The 2.2

Re: reading 1 hardsector size, not one block size

Date:Fri, 29 Sep 2000 17:49:04 -0600 From: "Jeff V. Merkey" [EMAIL PROTECTED] This is going to be a continuing problem for non-Unix file systems like NTFS and NWFS that rely on the ability to read and write variable length sector runs. It's not just non-Unix file

Re: What is up with Redhat 7.0?

Date:Sat, 30 Sep 2000 04:10:59 +0200 From: Marc Lehmann [EMAIL PROTECTED] Do you really think that explicitly supporting broken distributions (redhat 7.0 comes with a experimental snapshot of gcc which is neither binary compatible to 2.95 nor to 3.0, cutting binary

Re: reading 1 hardsector size, not one block size

Date: Fri, 29 Sep 2000 22:16:53 -0700 (PDT) From: Andre Hedrick [EMAIL PROTECTED] Basically you can de-stroke a drive with what you let the OS/FS report. Once this is done there is no way any FS can get to the stuff beyond what it knows about. I'm not sure what you mean by

Re: Proposal: Linux Kernel Patch Management System

Date: Thu, 14 Sep 2000 15:45:24 -0700 From: Larry McVoy [EMAIL PROTECTED] I'm going to have to respectfully disagree. First of all, having a flag day where everyone switches to BK just isn't a realistic expectation, even if the license wasn't an issue. Things just don't work

Re: Proposal: Linux Kernel Patch Management System

Date:Wed, 13 Sep 2000 03:30:39 -0700 From: "David S. Miller" [EMAIL PROTECTED] From: Daniel Quinlan [EMAIL PROTECTED] Date: Wed, 13 Sep 2000 03:18:14 -0700 (PDT) How exactly does a system to tracking patches and bugs/fixes (not to mention helping Linus

Re: Proposal: Linux Kernel Patch Management System

Date:Wed, 13 Sep 2000 02:27:07 -0700 From: "David S. Miller" [EMAIL PROTECTED] rsync [EMAIL PROTECTED]:/home/torvalds/src/linux \ ftp.kernel.org:/pub/linux/kernel/LIVE/linux would be the real helper for people like me whose only real issue now is bothering

Re: Proposal: Linux Kernel Patch Management System

From: "Dunlap, Randy" [EMAIL PROTECTED] Date: Wed, 13 Sep 2000 09:17:55 -0700 I appreciate Alan and you doing the kernel Status/TODO lists, but I think that you ought to simplify it for yourself at least (not that this would help Linus) by having maintainers do it instead of

Re: tty_[un]register_devfs putting 3K structures on the stack

Date:Fri, 06 Oct 2000 12:01:34 -0500 From: Jeff Dike [EMAIL PROTECTED] tty_register_devfs and tty_unregister_devfs both declare "struct tty_struct" locals. According to gdb: (gdb) p sizeof(struct tty_struct) $20 = 3084 This eats up most of a 4K page, and on UML

Re: serial problems

Date: Tue, 24 Oct 2000 11:14:13 +0200 From: octave klaba [EMAIL PROTECTED] Can you actually give me some details of how your system "crashed"? It certainly shouldn't have. Kermit will sometimes hang waiting for the terminal to flush if it's enabled hardware flow control and

Re: CLOCAL and TIOCMIWAIT

Date:Mon, 26 Feb 2001 22:19:20 -0500 From: Jeremy Jackson [EMAIL PROTECTED] I had written a simple program 10-20 lines C to count pulses at rate of 1 per second give or take. It turned out that the driver disabled the UART's generation of interrupts completely for certain

Re: [CFT][RFC] ext2_new_inode() fixes and cleanup

Date: Thu, 30 Nov 2000 17:13:27 -0500 (EST) From: Alexander Viro [EMAIL PROTECTED] * search for appropriate cylinder group had been taken out of the ext2_new_inode() into helper functions - find_cg_dir(sb, parent_group) and find_cg_other(sb, parent_group). Bug caught by

Re: /dev/random probs in 2.4test(12-pre3)

From: "Albert D. Cahalan" [EMAIL PROTECTED] Date:Sat, 2 Dec 2000 17:00:32 -0500 (EST) Any programmer who has evolved sufficiently from a scriptie should take necessary precautions to check how much data was transferred. Those who don't..well, there is still tomorrow.

Re: Fasttrak100 questions...

Date:Sat, 2 Dec 2000 17:18:43 + (GMT) From: Alan Cox [EMAIL PROTECTED] This is currently happening with lucent winmodem driver: there's modified version of serial.c, and customers are asked to compile it and (staticaly-)link it against proprietary code to get usable

Re: /dev/random probs in 2.4test(12-pre3)

Date: Sat, 2 Dec 2000 18:34:44 -0500 (EST) From: Alexander Viro [EMAIL PROTECTED] Erm... Not that ignoring the return values was a bright idea, but the lack of reliable ordered datagram protocol in IP family is not a good thing. It can be implemented over TCP, but it's a big

Re: Fasttrak100 questions...

Date: Sat, 2 Dec 2000 18:21:26 -0700 From: "Jeff V. Merkey" [EMAIL PROTECTED] Under this argument, it is argued that the engineer who had source code access "inevitably used" negative knowledge he gained from his study of the Linux sources. Absent the vague descriptions of

Re: lost dirs after fsck-1.18 (kt133, ide, dma, test10, test11)

From: "Saber Taylor" [EMAIL PROTECTED] Date:Sun, 03 Dec 2000 05:59:47 - Well that's the last time I run a devel kernel with a nontest system. sigh. Had one directory replaced with a different directory and also a directory replaced with a file. Possible further

Re: Serial cardbus code.... for testing, please.....

Date: Fri, 8 Dec 2000 13:27:51 -0800 (PST) From: Linus Torvalds [EMAIL PROTECTED] I didn't have time to do more than just quickly apply the patch and leave in a hurry, but my Vaio certainly recognized the serial port on the combo cardbus card I have with this patch. Everything

Re: Serial cardbus code.... for testing, please.....

Date: Fri, 8 Dec 2000 23:41:54 -0800 (PST) From: Linus Torvalds [EMAIL PROTECTED] This is a problem that many drivers have: when the card is removed, the driver sees an interrupt (which happens to be the CardBus card removal interrupt, but the serial driver doesn't know that, and

Re: Serial cardbus code.... for testing, please.....

Date: Sat, 9 Dec 2000 10:13:50 -0800 (PST) From: Linus Torvalds [EMAIL PROTECTED] I checked my VAIO's, and they all have a Ricoh cardbus bridge. Ted claimed he had a TI1311 or something, I think. So his VAIO is definitely different from the ones I have. That may be enough of a

Re: Serial cardbus code.... for testing, please.....

Date: Sat, 09 Dec 2000 11:13:59 -0500 From: Jeff Garzik [EMAIL PROTECTED] Note how the "rs_interrupt()" routine _tries_ to avoid this by having a pass counter value, but that logic never triggers because we will loop forever in receive_chars(), so the rs_interrupt() counter

Re: Signal 11

Date:Fri, 15 Dec 2000 01:09:29 + (GMT) From: Alan Cox [EMAIL PROTECTED] oWe tell vendors to build RPMv3 , glibc 2.1.x Curious HOW do you tell vendors?? When they ask. More usefully Dan Quinlann and most vendors put together a recommended set of things to

Re: /dev/random: really secure?

Date:Mon, 18 Dec 2000 21:38:01 +0100 From: Jamie Lokier [EMAIL PROTECTED] David Schwartz wrote: The code does its best to estimate how much actual entropy it is gathering. A potential weakness. The entropy estimator can be manipulated by feeding data which looks

Re: /dev/random: really secure?

Date: Tue, 19 Dec 2000 12:49:48 +0100 From: Kurt Garloff [EMAIL PROTECTED] On Mon, Dec 18, 2000 at 04:33:13PM -0500, Theodore Y. Ts'o wrote: Note that writing to /dev/random does *not* update the entropy estimate, for this very reason. The assumption is that inputs

Re: 2.4.0-test10-pre6: Use of abs()

Date: Wed, 1 Nov 2000 09:46:19 -0500 From: [EMAIL PROTECTED] On Mon, Oct 30, 2000 at 05:14:34PM +0100, Martin Dalecki wrote: Of corse right! BTW. There are tons of places where log2 is calculated explicitly in kernel which should be replaced with the corresponding built

Re: non-gcc linux? (was Re: Where did kgcc go in 2.4.0-test10?)

Date:Thu, 02 Nov 2000 12:31:51 -0700 From: Tim Riker [EMAIL PROTECTED] Me or Alan? I did not mean this as a dig. I feel strongly that one should have the choice here. I do not choose to enforce my beliefs on anyone else. I am suggesting only that others should provide the

Re: non-gcc linux? (was Re: Where did kgcc go in 2.4.0-test10?)

Date: Thu, 02 Nov 2000 13:53:55 -0700 From: Tim Riker [EMAIL PROTECTED] As is being discussed here, C99 has some replacements to the gcc syntax the kernel uses. I believe the C99 syntax will win in the near future, and thus the gcc syntax will have to be removed at some point. In

Re: Can EINTR be handled the way BSD handles it? -- a plea from a user-land

Date:Fri, 03 Nov 2000 14:44:17 -0500 From: [EMAIL PROTECTED] My problem is that pthread_create (glibc 2.1.3, kernel 2.2.17 i686) is failing because, deep inside glibc somewhere, nanosleep() is returning EINTR. Sounds like it might be a bug in pthread_create although

Re: Can EINTR be handled the way BSD handles it? -- a plea from auser-land programmer...

Date:Mon, 6 Nov 2000 09:13:25 -0500 (EST) From: George Talbot [EMAIL PROTECTED] I respectfully disagree that programs which don't surround some of the most common system calls with do { rv = __some_system_call__(...); }

Re: Can EINTR be handled the way BSD handles it? -- a plea from a user-land programmer...

From: Ulrich Drepper [EMAIL PROTECTED] Date: 06 Nov 2000 10:50:37 -0800 Arguably though the bug is in glibc, in that if it's using signals behinds the scenes, it should have passed SA_RESTART to sigaction. Why are you talking such a nonsense? The claim was made that pthreads

Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)

Date:Thu, 9 Nov 2000 13:39:04 + (GMT) From: Paul Jakma [EMAIL PROTECTED] I actually think Linus has been too loose/vague on modules. The official COPYING txt file in the tree contains an exception on linking to the kernel using syscalls from linus and the GPL. nothing

Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)

Date:Thu, 09 Nov 2000 08:43:14 -0500 From: Michael Rothwell [EMAIL PROTECTED] And how would a hypothetical Advanced Linux Kernel Project be different? Set aside the GKHI and the issue of binary-only hook modules; how would an "enterprise" fork be any different than RT or

Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)

Date:Wed, 08 Nov 2000 16:35:33 -0500 From: Michael Rothwell [EMAIL PROTECTED] Sounds great; unfortunately, the core group has spoken out against a modular kernel. This is true; that's because a modular kernel means that interfaces have to be frozen in time, usually forever.

Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)

Date: Thu, 9 Nov 2000 14:26:33 + (GMT) From: Alan Cox [EMAIL PROTECTED] Actually, he's been quite specific. It's ok to have binary modules as long as they conform to the interface defined in /proc/ksyms. What is completely unclear is if he has the authority to say that

Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)

From: [EMAIL PROTECTED] Date:Fri, 10 Nov 2000 11:41:09 + It has the potential to to make patches easier to re-work for different kernel versions, and to enable development maintence and fixing of the patch to be done independently of a kernel build. And it also has the

Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)

Date: Fri, 10 Nov 2000 10:36:31 -0800 From: "Matt D. Robinson" [EMAIL PROTECTED] As soon as I finish writing raw write disk routines (not using kiobufs), we can _maybe_ get LKCD accepted one of these days, especially now that we don't have to build 'lcrash' against a kernel

Re: kernel panic: EXT4-fs (device loop0): panic forced after error

On Sun, May 06, 2018 at 11:40:10PM +0900, Tetsuo Handa wrote: > > We could add a full kernel-mode fsck which gets run before mount --- > > the question is how much complexity we want to add. If SELinux is > > enabled, then we have to check xattr consinsistency, etc., etc. > > You are thinking

Re: [Ksummit-discuss] bug-introducing patches

On Fri, May 04, 2018 at 09:51:14PM +, Sasha Levin wrote: > I don't have an objection to moving this to it's own tag. It will make > my scripts somewhat simpler for sure. It's not a matter "moving this it's own tag", but creating a new tag --- because what is in the docs is a lie. It does not

Re: [Ksummit-discuss] bug-introducing patches

On Fri, May 04, 2018 at 10:40:55AM -0700, Greg KH wrote: > Ugh, what? I don't understand what you are proposing here, what we have > today is just fine, what is broken with it? What we have today is this: Cc: sta...@kernel.org # 3.11 Cc: sta...@kernel.org # 4.8+ Cc:

Re: [Ksummit-discuss] bug-introducing patches

On Tue, May 08, 2018 at 08:29:14PM +, Sasha Levin wrote: > > This is interesting. We have a group of power users who are testing out > -rc releases, who are usually happy to test out a fast moving target and > provide helpful reports back. We also have a group who run a -stable > kernel

Re: [PATCH v3] ext4: handle errors on ext4_commit_super

On Mon, Apr 23, 2018 at 08:46:26AM -0600, Jaegeuk Kim wrote: > When remounting ext4 from ro to rw, currently it allows its transition, > even if ext4_commit_super() returns EIO. Even worse thing is, after that, > fs/buffer complains buffer dirty bits like: > > Call trace: > []

Re: [Ksummit-discuss] bug-introducing patches

On Tue, May 08, 2018 at 02:34:41AM +, Sasha Levin via Ksummit-discuss wrote: > > Tony, I'm curious, how many users are you aware of who actually run > Linus's tree? All the users I've encountered so far on Azure seem to be > running something based on -stable. The people who run Linus's tree

Re: [PATCH v3 2/3] fs: Convert kiocb rw_hint from enum to u16

On Wed, May 09, 2018 at 08:23:00AM -0600, Jens Axboe wrote: > Streams is essentially the only thing ki_hint is currently used for, > with the write life time hints mapping to a stream. The idea for the > user side API was to have other things than just write life time hints. > > Since Adam wants

Re: [PATCH v3 2/3] fs: Convert kiocb rw_hint from enum to u16

On Tue, May 08, 2018 at 10:42:01AM -0700, adam.manzana...@wdc.com wrote: > diff --git a/include/linux/fs.h b/include/linux/fs.h > index 760d8da1b6c7..7a90ce387e00 100644 > --- a/include/linux/fs.h > +++ b/include/linux/fs.h > @@ -284,6 +284,8 @@ enum rw_hint { > WRITE_LIFE_EXTREME =

Re: WARNING: bad unlock balance in xfs_iunlock

>>> C reproducer: https://syzkaller.appspot.com/x/repro.c?id=5719304272084992 >>> syzkaller reproducer: >>> https://syzkaller.appspot.com/x/repro.syz?id=5767783983874048 >> >> What a mess. A hand built, hopelessly broken filesystem image made >> up of hex dumps, written into a mmap()d region of

Re: [PATCH 3.18 00/24] 3.18.107-stable review

On Fri, Apr 27, 2018 at 03:57:35PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.18.107 release. The kernel.org page currently lists 3.18 as EOL. I assume we released an update for Spectre/Meltdown after we declared it end of life, but I was surprised

Re: Linux messages full of `random: get_random_u32 called from`

On Thu, Apr 26, 2018 at 10:20:44PM -0700, Sultan Alsawaf wrote: > > I noted at least 20,000 mmc interrupts before I intervened in the boot > process to provide entropy > myself. That's just for mmc, so I'm sure there were even more interrupts > elsewhere. Is 20k+ interrupts > really not

Re: Linux messages full of `random: get_random_u32 called from`

On Fri, Apr 27, 2018 at 05:38:52PM +0200, Jason A. Donenfeld wrote: > > Please correct me if I'm wrong, but my present understanding of this > is that crng readiness used to be broken, meaning people would have a > seeded rng without it actually being seeded. You fixed this bug, and > now people

Re: [PATCH] ext4: make function ‘ext4_getfsmap_find_fixed_metadata’ static

On Sat, May 05, 2018 at 10:04:52PM +0200, Mathieu Malaterre wrote: > Since function ‘ext4_getfsmap_find_fixed_metadata’ can be made static, > make it so. Remove the following gcc warning (W=1): > > fs/ext4/fsmap.c:405:5: warning: no previous prototype for > ‘ext4_getfsmap_find_fixed_metadata’

Re: [PATCH 1/2] random: Omit double-printing ratelimit messages

On Thu, May 10, 2018 at 01:52:10PM +0100, Dmitry Safonov wrote: > Currently "suppressed" messages will be printed once in a second for > unseeded/urandom warnings, but there is already custom message which > says how many warnings are missing. So, let's skip suppressed messages > until crng_init

Re: Fixing Linux getrandom() in stable

(Quoting somewhat out of order) On Sun, May 13, 2018 at 09:23:39PM +, Thorsten Glaser wrote: > > It’s also no solution for the arc4random API… seems like a cultural > clash (BSD expectations vs. what Linux can actually deliver). It's instructive to look how OpenBSD solves this problem.

Re: [RFC v2 3/4] ext4: add verifier check for symlink with append/immutable flags

On Fri, May 11, 2018 at 11:12:18PM +0200, Jan Kara wrote: > On Thu 10-05-18 16:13:58, Luis R. Rodriguez wrote: > > The Linux VFS does not allow a way to set append/immuttable > > attributes to symlinks, this is just not possible. If this is > > detected inform the user as the filesystem must be

Re: [PATCH v2] fs: ext4: Adding new return type vm_fault_t

On Thu, May 10, 2018 at 08:11:36PM +0530, Souptick Joarder wrote: > Use new return type vm_fault_t for fault handler. For now, > this is just documenting that the function returns a > VM_FAULT value rather than an errno. Once all instances are > converted, vm_fault_t will become a distinct type. >

Re: [PATCH 1/2] random: Omit double-printing ratelimit messages

On Thu, May 10, 2018 at 08:50:07PM +0100, Dmitry Safonov wrote: > random uses __ratelimit() which calls ___ratelimit() with a function > name. Depending on !RATELIMIT_MSG_ON_RELEASE it prints how many > messages were suppressed every ratelimit interval (1 second for random) > and flushes

Re: [PATCH 1/2] random: Omit double-printing ratelimit messages

On Thu, May 10, 2018 at 07:37:40PM +0100, Dmitry Safonov wrote: > > Ok, then what's the purpose of those messages? > :pr_notice("random: %d get_random_xx warning(s) missed " > : "due to ratelimiting\n", > : unseeded_warning.missed); > :

Re: general protection fault in lo_ioctl (2)

On Tue, May 08, 2018 at 08:05:12PM +0900, Tetsuo Handa wrote: > > So, it is time to think how to solve this race condition, as well as how to > solve > lockdep's deadlock warning (and I guess that syzbot is actually hitting > deadlocks). > An approach which serializes loop operations using

Re: kernel panic: EXT4-fs (device loop0): panic forced after error

On Sat, May 05, 2018 at 05:57:02PM -0700, syzbot wrote: > Hello, > > syzbot found the following crash on: > > EXT4-fs error (device loop0): ext4_iget:4756: inode #2: comm > syz-executor909: root inode unallocated > Kernel panic - not syncing: EXT4-fs (device loop0): panic forced after error I

Re: serial: custom baud rate

On Fri, May 04, 2018 at 02:34:51PM +0530, Muni Sekhar wrote: > > See the setserial man page:t > > > > https://linux.die.net/man/8/setserial > > > > Not all serial devices support the spd_cust and divisor, however. In > > general, only devices where the kernel directly programs the > >

Re: [Ksummit-discuss] bug-introducing patches

On Fri, May 04, 2018 at 03:31:17PM +0300, Jani Nikula wrote: > On Fri, 04 May 2018, David Howells wrote: > > Sasha Levin via Ksummit-discuss wrote: > > > >>Cc: sta...@vger.kernel.org # commit-id-of-(2) > > This has been documented since > > commit

Re: kernel panic: EXT4-fs (device loop0): panic forced after error

On Sun, May 06, 2018 at 02:03:57PM +0900, Tetsuo Handa wrote: > > Since syzbot is hitting this error path inside mount() request, calling > panic() when something went wrong inside mount() request might be > overkill. We can recover without shutting down the system, can't we? We could add a full

Re: kernel panic: EXT4-fs (device loop0): panic forced after error

On Sun, May 06, 2018 at 11:15:45AM +0200, Dmitry Vyukov wrote: > >> I don't get why syzbot considers this a bug. It created a corrupted > >> file system, mounted it as root, and said file system had the flag > >> which says, "panic if you find a file system corruption". > > In what world is this

Re: Linux messages full of `random: get_random_u32 called from`

On Fri, May 18, 2018 at 01:27:03AM +, Trent Piepho wrote: > > I've hit this on an embedded system. mke2fs hangs trying to format a > persistent writable filesystem, which is where the random seed to > initialize the kernel entropy pool would be stored, because it wants 16 > bytes of

Re: random: Wake up writers when random pools are zapped

On Fri, May 18, 2018 at 02:57:36PM +0800, Herbert Xu wrote: > As it is when the pool is zapped with RNDCLEARPOOL writers are > not woken up and therefore the pool may remain in the empty state > indefinitely. > > This patch wakes them up unless the write threshold is set to zero. > >

Re: [PATCH] fscrypt: use unbound workqueue for decryption

On Fri, Apr 20, 2018 at 04:30:02PM -0700, Eric Biggers wrote: > Improve fscrypt read performance by switching the decryption workqueue > from bound to unbound. With the bound workqueue, when multiple bios > completed on the same CPU, they were decrypted on that same CPU. But > with the unbound

Bugs involving maliciously crafted file system

On Wed, May 23, 2018 at 01:01:59PM -0500, Eric Sandeen wrote: > > What I'm personally hung up on are the bugs where the "exploit" involves > merely > mounting a crafted filesystem that in reality would never (until the heat > death > of the universe) corrupt itself into that state on its own;

Re: Bugs involving maliciously crafted file system

On Thu, May 24, 2018 at 10:49:31AM +1000, Dave Chinner wrote: > > We've learnt this lesson the hard way over and over again: don't > parse untrusted input in privileged contexts. How many times do we > have to make the same mistakes before people start to learn from > them? Good question. For

Re: [REVIEW][PATCH 0/6] Wrapping up the vfs support for unprivileged mounts

On Wed, May 23, 2018 at 06:22:56PM -0500, Eric W. Biederman wrote: > > Very slowly the work has been progressing to ensure the vfs has the > necessary support for mounting filesystems without privilege. What's the thinking behind how system administrators and/or file systems would configure

Re: [PATCH] doc: document scope NOFS, NOIO APIs

ere is no mention in the core-api Documentation and there are > > people looking there to find answers how to use a specific API. > > > > Cc: "Darrick J. Wong" <darrick.w...@oracle.com> > > Cc: David Sterba <dste...@suse.cz> > > Requested-by: "Th

Re: [PATCH 1/5] random: fix crng_ready() test

On Wed, May 16, 2018 at 05:07:08PM -0700, Srivatsa S. Bhat wrote: > > On a Photon OS VM running on VMware ESXi, this patch causes a boot speed > regression of 5 minutes :-( [ The VM doesn't have haveged or rng-tools > (rngd) installed. ] > > [1.420246] EXT4-fs (sda2): re-mounted. Opts:

Re: [PATCH 1/5] random: fix crng_ready() test

On Thu, May 17, 2018 at 08:01:04AM +0200, Christophe LEROY wrote: > > On a powerpc embedded board which has an mpc8xx processor running at 133Mhz, > I now get the startup done in more than 7 minutes instead of 30 seconds. > This is due to the webserver blocking on read on /dev/random until we get

Re: [PATCH 1/2] random: Omit double-printing ratelimit messages

On Wed, May 16, 2018 at 04:46:13PM +0100, Dmitry Safonov wrote: > > Yeah, but what you print is not total sum, it's since the last > > interval because without mentioned flag ___ratelimit() will flush > > missed counter and print "suppressed" message. They might even > > double if say other

Re: [PATCH] jbd2: remove the conditional test

On Mon, Feb 05, 2018 at 10:24:39PM +0800, Wang Long wrote: > kmem_cache_destroy already handles null pointers, so we can remove the > conditional test entirely. > > This patch also set NULL after the kmem_cache_destroy in function > jbd2_journal_destroy_handle_cache. > > Signed-off-by: Wang Long

Re: [PATCH] ext4: Remove unnecessary NULL checks in ext4.

On Tue, Feb 06, 2018 at 07:15:30PM +0800, Sean Fu wrote: > NULL check is done in kmem_cache_destroy. So remove NULL checks in ext4. > > Signed-off-by: Sean Fu Thanks, applied. I clarified the patch summary to be: ext4: remove NULL check before calling

Re: [PATCH] ext4: report delalloc reserve as non-free in statfs mangled by project quota

On Fri, Feb 02, 2018 at 01:40:05PM +0300, Konstantin Khlebnikov wrote: > This reserved space isn't committed yet but cannot be used for allocations. > For userspace it has no difference from used space. XFS already does this. > > Signed-off-by: Konstantin Khlebnikov >

Re: Linux messages full of `random: get_random_u32 called from`

On Fri, May 18, 2018 at 10:56:18PM +, Trent Piepho wrote: > > I feel like "fix" might overstate the result a bit. > > This ends up taking a full second to make each UUID. Having gone to > great effort to make an iMX25 complete userspace startup in 250 ms, a > full second, per UUID, in early

Re: what trees/branches to test on syzbot

On Sat, Jun 09, 2018 at 03:17:21PM -0700, Linus Torvalds wrote: > I think it would be lovely to get linux-next back eventually, but it > sounds like it's just too noisy right now, and yes, we should have a > baseline for the standard tree first. > > But once there's a "this is known for the

Re: building in 32bit chroot on x86_64 host broken

On Sat, Jun 09, 2018 at 09:23:55PM +0900, Masahiro Yamada wrote: > Just a note. > > In case of cross-compiling, not only ARCH but also CROSS_COMPILE > must be passed when you do "make *config". Sure, what was being discussed was people who build 32-bit x86 kernels on a 64-bit platform. I do

Re: what trees/branches to test on syzbot

On Sun, Jun 10, 2018 at 08:11:05AM +0200, Dmitry Vyukov wrote: > > The set of trees where a crash happened is visible on dashboard, so > one can see if it's only linux-next or whole set of trees. Potentially > syzbot can act differently depending on this predicate, but I don't > see what should

Re: [PATCH v6 0/4] enable early printing of hashed pointers

On Thu, Jun 07, 2018 at 09:31:04AM +1000, Tobin C. Harding wrote: > > I'm also happy to take the whole patch series through the random tree > > if everyone else is OK with it. > > Looks like every one is happy (or silent) now Ted, can you please take > this version through your tree. Ok, it's

Re: [PATCH 00/32] VFS: Introduce filesystem context [ver #8]

On Mon, Jun 18, 2018 at 09:30:50PM +0100, David Howells wrote: > > The fscontext code *requires* you to parse the parameters *before* any attempt > to access the superblock is made. Note that this will actually be a problem > for, say, ext4 which passes a text string stored in the superblock

Re: [PATCH] vfs: Support FALLOC_FL_NO_HIDE_STALE flag with fallocate

On Fri, Jun 15, 2018 at 06:51:08PM +0800, Sig Shen wrote: > FALLOC_FL_NO_HIDE_STALE flag must be set if user want to issue > a discard request for block devices. But vfs_fallocate() will > return with an error -EOPNOTSUPP indicating lack of support > if this flag is set. > > fix it by allowing

Re: Bugs involving maliciously crafted file system

On Mon, Jun 11, 2018 at 03:07:24PM +0200, Dmitry Vyukov wrote: > > These can't be weaponized to execute code, but if a BUG_ON is > triggerable over a network, or from VM guest, then it's likely more > critical than a local code execution. That's why I am saying that > automated evaluation is

Re: Bugs involving maliciously crafted file system

On Sat, May 26, 2018 at 07:12:49PM +0200, Dmitry Vyukov wrote: > > I don't see that "some kind of machine learning or expert system > evaluation" is feasible. At least not in short/mid-term. There are > innocently-looking bugs that actually turn out to be very bad, and > there are badly looking

Re: PostgreSQL licensed code on Linux

On Tue, May 29, 2018 at 03:26:43PM -0400, Kent Overstreet wrote: > > That seems to indicate that we've had already PostgreSQL licensed code on > > Linux since Kent's addition of bcache to Linux in 2013. The portion of code > > is rather small though, to me it seems to cover only crc_table[], > >

Re: [PATCH] ext4: prefer strlcpy to strncpy

On Mon, May 28, 2018 at 11:21:53PM -0700, Nick Desaulniers wrote: > Fixes a stringop-truncation warning from gcc-8. > > Signed-off-by: Nick Desaulniers I'll note that the ext4 superblock fields are *not* guaranteed to be NULL terminated. Code that references them must, and do, deal with this

  1   2   3   4   5   6   7   8   9   >