On Wed, Oct 31, 2018 at 12:58:03AM +0300, Vasily Averin wrote:
> bh was not released after error in ext4_journal_get_write_access()
>
> Fixes ac27a0ec112a ("ext4: initial copy of files from ext3") # 2.6.19
>
> Signed-off-by: Vasily Averin
Thanks, applied. I fixed up the commit description and
On Wed, Oct 31, 2018 at 12:57:55AM +0300, Vasily Averin wrote:
> gdb_bh must be released in case of errors before update of s_group_desc
> but it must not be released after update of group descriptors
> because in this case bh can be used later.
>
> Fixes 01f795f9e0d6 ("ext4: add online resizing
On Wed, Oct 31, 2018 at 12:57:55AM +0300, Vasily Averin wrote:
> gdb_bh must be released in case of errors before update of s_group_desc
> but it must not be released after update of group descriptors
> because in this case bh can be used later.
>
> Fixes 01f795f9e0d6 ("ext4: add online resizing
On Wed, Oct 31, 2018 at 12:57:45AM +0300, Vasily Averin wrote:
> Fixes 33afdcc5402d ("ext4: add a function which sets up group blocks ...") #
> 3.3
>
> Signed-off-by: Vasily Averin
Thanks, applied. I adjusted the patch summary:
ext4: add missing brelse() in set_flexbg_block_bitmap()'s
On Wed, Oct 31, 2018 at 12:57:45AM +0300, Vasily Averin wrote:
> Fixes 33afdcc5402d ("ext4: add a function which sets up group blocks ...") #
> 3.3
>
> Signed-off-by: Vasily Averin
Thanks, applied. I adjusted the patch summary:
ext4: add missing brelse() in set_flexbg_block_bitmap()'s
On Wed, Oct 31, 2018 at 12:57:37AM +0300, Vasily Averin wrote:
> currently bh is set to NULL only during first iteration of for cycle,
> then this pointer is not cleared after end of using.
> Therefore rollback after errors can lead to extra brelse(bh) call,
> decrements bh counter and later
On Wed, Oct 31, 2018 at 12:57:37AM +0300, Vasily Averin wrote:
> currently bh is set to NULL only during first iteration of for cycle,
> then this pointer is not cleared after end of using.
> Therefore rollback after errors can lead to extra brelse(bh) call,
> decrements bh counter and later
#syz dup: general protection fault in rb_erase
The fix for this is already in Linux's tree (merged on October 24th).
#syz dup: general protection fault in rb_erase
The fix for this is already in Linux's tree (merged on October 24th).
On Thu, Oct 25, 2018 at 03:39:01PM -0400, Eric S. Raymond wrote:
>
> Under Jacobsen vs. Katzer (535 f 3d 1373 fed cir 2008) authors of
> GPLed software have a specific right to relief (including injunctive
> relief) against misappropriation of their software. That ruling (which
> was the case of
On Thu, Oct 25, 2018 at 03:39:01PM -0400, Eric S. Raymond wrote:
>
> Under Jacobsen vs. Katzer (535 f 3d 1373 fed cir 2008) authors of
> GPLed software have a specific right to relief (including injunctive
> relief) against misappropriation of their software. That ruling (which
> was the case of
On Thu, Oct 25, 2018 at 09:59:38PM +0200, Johannes Berg wrote:
> > So, thinking about this more, can you guarantee (somehow) that the
> > workqueue is empty at this point?
>
> (I hadn't looked at the code then - obviously that's guaranteed)
We can guarantee it from someone who is looking at the
On Thu, Oct 25, 2018 at 09:59:38PM +0200, Johannes Berg wrote:
> > So, thinking about this more, can you guarantee (somehow) that the
> > workqueue is empty at this point?
>
> (I hadn't looked at the code then - obviously that's guaranteed)
We can guarantee it from someone who is looking at the
On Thu, Oct 25, 2018 at 08:05:40AM -0700, Bart Van Assche wrote:
> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
> index fc9129d5909e..0ef275fe526c 100644
> --- a/kernel/workqueue.c
> +++ b/kernel/workqueue.c
> @@ -1383,6 +1383,10 @@ static void __queue_work(int cpu, struct
>
On Thu, Oct 25, 2018 at 08:05:40AM -0700, Bart Van Assche wrote:
> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
> index fc9129d5909e..0ef275fe526c 100644
> --- a/kernel/workqueue.c
> +++ b/kernel/workqueue.c
> @@ -1383,6 +1383,10 @@ static void __queue_work(int cpu, struct
>
The following changes since commit 17b57b1883c1285f3d0dc2266e8f79286a7bef38:
Linux 4.19-rc6 (2018-09-30 07:15:35 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git
tags/ext4_for_linus
for you to fetch changes up to
The following changes since commit 17b57b1883c1285f3d0dc2266e8f79286a7bef38:
Linux 4.19-rc6 (2018-09-30 07:15:35 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git
tags/ext4_for_linus
for you to fetch changes up to
On Wed, Oct 24, 2018 at 09:15:34AM -0400, Theodore Y. Ts'o wrote:
> At least for ext4, the primary problem is that we want to use a 64-bit
> telldir/seekdir cookie if all 64-bits will make it to user space, and
> a 32-bit telldir cookie if only 32 bits will make it userspace. This
>
On Wed, Oct 24, 2018 at 09:15:34AM -0400, Theodore Y. Ts'o wrote:
> At least for ext4, the primary problem is that we want to use a 64-bit
> telldir/seekdir cookie if all 64-bits will make it to user space, and
> a 32-bit telldir cookie if only 32 bits will make it userspace. This
>
On Wed, Oct 24, 2018 at 12:47:57PM +1100, NeilBrown wrote:
>
> I doubt it was copied - more likely independent evolution.
> But on reflection, I see that it is probably reasonable that it
> shouldn't be used this way - or at all in this context.
> I'll try to understand what the issues really are
On Wed, Oct 24, 2018 at 12:47:57PM +1100, NeilBrown wrote:
>
> I doubt it was copied - more likely independent evolution.
> But on reflection, I see that it is probably reasonable that it
> shouldn't be used this way - or at all in this context.
> I'll try to understand what the issues really are
On Tue, Oct 23, 2018 at 09:19:53PM +0100, Phillip Potter wrote:
> diff --git a/include/linux/file_type.h b/include/linux/file_type.h
Shouldn't this be in include/uapi/linux/fs_types.h?
One of things which must be made crystal clear is these definitions
MUST NOT ever change. It would break the
On Tue, Oct 23, 2018 at 09:19:53PM +0100, Phillip Potter wrote:
> diff --git a/include/linux/file_type.h b/include/linux/file_type.h
Shouldn't this be in include/uapi/linux/fs_types.h?
One of things which must be made crystal clear is these definitions
MUST NOT ever change. It would break the
On Tue, Oct 23, 2018 at 04:22:54PM +0200, Rainer Fiebig wrote:
>
> And whether that CoC does come with a political agenda or is just being
> *perceived* so, is irrelevant: the perception *is* the reality. And by
> embracing this CoC, Linux is now being perceived as also supporting the
> agenda
On Tue, Oct 23, 2018 at 04:22:54PM +0200, Rainer Fiebig wrote:
>
> And whether that CoC does come with a political agenda or is just being
> *perceived* so, is irrelevant: the perception *is* the reality. And by
> embracing this CoC, Linux is now being perceived as also supporting the
> agenda
On Tue, Oct 23, 2018 at 02:42:03AM -0700, syzbot wrote:
> syzbot has found a reproducer for the following crash on:
>
> HEAD commit:ca9eb48fe01f Merge tag 'regulator-v5.0' of git://git.kerne..
> git tree: upstream
> console output:
On Tue, Oct 23, 2018 at 02:42:03AM -0700, syzbot wrote:
> syzbot has found a reproducer for the following crash on:
>
> HEAD commit:ca9eb48fe01f Merge tag 'regulator-v5.0' of git://git.kerne..
> git tree: upstream
> console output:
On Tue, Oct 23, 2018 at 03:25:08PM +1100, NeilBrown wrote:
>
> Yes, you could, and you can. But if it was Linus who was behaving
> inappropriately, where did you go then? This is why I think whatever
> "code" we have should be overtly a statement Linus makes about his
> behaviour, in the first
On Tue, Oct 23, 2018 at 03:25:08PM +1100, NeilBrown wrote:
>
> Yes, you could, and you can. But if it was Linus who was behaving
> inappropriately, where did you go then? This is why I think whatever
> "code" we have should be overtly a statement Linus makes about his
> behaviour, in the first
Neil,
I disagree with your framing, and thus your analysis, and thus your
proposed solution.
On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote:
> If, for example, Linus or Andrew said "if you cannot work with any given
> maintainer, I will consider your patch directly, but you need to
Neil,
I disagree with your framing, and thus your analysis, and thus your
proposed solution.
On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote:
> If, for example, Linus or Andrew said "if you cannot work with any given
> maintainer, I will consider your patch directly, but you need to
On Sun, Oct 21, 2018 at 11:26:08PM +0100, Josh Triplett wrote:
> On Mon, Oct 22, 2018 at 08:20:11AM +1100, NeilBrown wrote:
> > I call on you, Greg:
> > - to abandon this divisive attempt to impose a "Code of Conduct"
> > - to revert 8a104f8b5867c68
> > - to return to your core competence of
On Sun, Oct 21, 2018 at 11:26:08PM +0100, Josh Triplett wrote:
> On Mon, Oct 22, 2018 at 08:20:11AM +1100, NeilBrown wrote:
> > I call on you, Greg:
> > - to abandon this divisive attempt to impose a "Code of Conduct"
> > - to revert 8a104f8b5867c68
> > - to return to your core competence of
On Sat, Oct 20, 2018 at 03:14:20PM -0400, jonsm...@gmail.com wrote:
>
> Which is why the lawyers need to go over this document and I haven't
> seen anything posted from them. In the same vein Mauro is concerned
> that the way this is code is written it is a binding contract in
> Brazil.
My
On Sat, Oct 20, 2018 at 03:14:20PM -0400, jonsm...@gmail.com wrote:
>
> Which is why the lawyers need to go over this document and I haven't
> seen anything posted from them. In the same vein Mauro is concerned
> that the way this is code is written it is a binding contract in
> Brazil.
My
On Wed, Oct 17, 2018 at 05:28:55PM -0600, Andreas Dilger wrote:
>
> Looking at the patch there are two effects that it has:
> - optimize a very rare case where there is an allocation failure before
> locking
> - return an unnecessary error if "ei->jinode" is allocated before locking
>
> I don't
On Wed, Oct 17, 2018 at 05:28:55PM -0600, Andreas Dilger wrote:
>
> Looking at the patch there are two effects that it has:
> - optimize a very rare case where there is an allocation failure before
> locking
> - return an unnecessary error if "ei->jinode" is allocated before locking
>
> I don't
On Tue, Oct 16, 2018 at 10:55:26PM +0800, fishland wrote:
> The jinode does not need protected by *i_lock*, we can return
> directly if memory allocation fails.
>
I don't see anything wrong with this patch, but at the same time, I'm
not sure I see the benefit, either. Checking for the
On Tue, Oct 16, 2018 at 10:55:26PM +0800, fishland wrote:
> The jinode does not need protected by *i_lock*, we can return
> directly if memory allocation fails.
>
I don't see anything wrong with this patch, but at the same time, I'm
not sure I see the benefit, either. Checking for the
On Tue, Oct 16, 2018 at 04:02:07PM +0200, Dmitry Vyukov wrote:
> I am not sure how exactly this should be classified. To significant
> degree these "$FOO" discriminations are informational and only really
> affect the data format passed in.
The problem is that putting something which is simply
On Tue, Oct 16, 2018 at 04:02:07PM +0200, Dmitry Vyukov wrote:
> I am not sure how exactly this should be classified. To significant
> degree these "$FOO" discriminations are informational and only really
> affect the data format passed in.
The problem is that putting something which is simply
On Mon, Oct 15, 2018 at 03:22:42PM +0200, Dmitry Vyukov wrote:
> Now that you mention EXT4_IOC_SWAP_BOOT, I think I looked at the wrong
> program, there is a subsequent one that does ioctl(0x6611) where
> 0x6611 is in fact EXT4_IOC_SWAP_BOOT. So I think it's this one:
>
> 05:23:28 executing
On Mon, Oct 15, 2018 at 03:22:42PM +0200, Dmitry Vyukov wrote:
> Now that you mention EXT4_IOC_SWAP_BOOT, I think I looked at the wrong
> program, there is a subsequent one that does ioctl(0x6611) where
> 0x6611 is in fact EXT4_IOC_SWAP_BOOT. So I think it's this one:
>
> 05:23:28 executing
On Fri, Oct 12, 2018 at 10:42:39AM +0200, Arnd Bergmann wrote:
> I wonder if mixing in ktime_get_real() is flawed to start with:
> This depends on read_persistent_clock64() actually returning
> a meaningful time, but in many cases it does not; x86 being
> a notable exception.
>
> We have three
On Fri, Oct 12, 2018 at 10:42:39AM +0200, Arnd Bergmann wrote:
> I wonder if mixing in ktime_get_real() is flawed to start with:
> This depends on read_persistent_clock64() actually returning
> a meaningful time, but in many cases it does not; x86 being
> a notable exception.
>
> We have three
hat this warning may still remain for machines that do not have
> UEFI RNG support (which initializes the RNG pools durting setup_arch()),
> or for x86 machines without RDRAND (or booting without "random.trust=on"
> or CONFIG_RANDOM_TRUST_CPU=y).
>
> Signed-off-by: Kees C
hat this warning may still remain for machines that do not have
> UEFI RNG support (which initializes the RNG pools durting setup_arch()),
> or for x86 machines without RDRAND (or booting without "random.trust=on"
> or CONFIG_RANDOM_TRUST_CPU=y).
>
> Signed-off-by: Kees C
On Thu, Oct 11, 2018 at 07:14:30AM -0700, h...@zytor.com wrote:
> >
> >I mean - what is the baud rate of a pty ?
>
> Whatever the master wants it to be...
I think Alan's point is that it is highly unlikely you would be able
to push the equivalent of 4 gbps through a PTY layer. The TTY later
was
On Thu, Oct 11, 2018 at 07:14:30AM -0700, h...@zytor.com wrote:
> >
> >I mean - what is the baud rate of a pty ?
>
> Whatever the master wants it to be...
I think Alan's point is that it is highly unlikely you would be able
to push the equivalent of 4 gbps through a PTY layer. The TTY later
was
On Wed, Oct 10, 2018 at 04:27:58PM +0200, Arnd Bergmann wrote:
> The two new variables are only used in an #ifdef, so they cause a
> warning without CONFIG_QUOTA:
>
> fs/ext4/super.c: In function 'parse_options':
> fs/ext4/super.c:1977:26: error: unused variable 'grp_qf_name'
>
On Wed, Oct 10, 2018 at 04:27:58PM +0200, Arnd Bergmann wrote:
> The two new variables are only used in an #ifdef, so they cause a
> warning without CONFIG_QUOTA:
>
> fs/ext4/super.c: In function 'parse_options':
> fs/ext4/super.c:1977:26: error: unused variable 'grp_qf_name'
>
On Tue, Oct 09, 2018 at 10:51:02AM +1100, Stephen Rothwell wrote:
> Hi Ted,
>
> After merging the ext4 tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
Oops, my bad. Thanks for catching this. I failed to a new helper
function inside #ifdef CONFIG_QUOTA .. #endif.
On Tue, Oct 09, 2018 at 10:51:02AM +1100, Stephen Rothwell wrote:
> Hi Ted,
>
> After merging the ext4 tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
Oops, my bad. Thanks for catching this. I failed to a new helper
function inside #ifdef CONFIG_QUOTA .. #endif.
On Mon, Oct 08, 2018 at 06:29:54PM +0200, Dmitry Vyukov wrote:
>
> The program that triggered it did the following:
>
> 05:23:28 executing program 5:
> r0 = creat(&(0x7f0001c0)='./file0\x00', 0x0)
> socketpair$unix(0x1, 0x1, 0x0, &(0x7f000380)={0x,
> 0x})
On Mon, Oct 08, 2018 at 06:29:54PM +0200, Dmitry Vyukov wrote:
>
> The program that triggered it did the following:
>
> 05:23:28 executing program 5:
> r0 = creat(&(0x7f0001c0)='./file0\x00', 0x0)
> socketpair$unix(0x1, 0x1, 0x0, &(0x7f000380)={0x,
> 0x})
On Tue, Sep 11, 2018 at 01:02:00PM +, mario.limoncie...@dell.com wrote:
> > I tried 9370 and it detects the adapter correctly. IIRC I did the same
> > for 5530 and it worked as well.
>
> Thanks for confirming that. Hopefully the same change can be ported to PD
> controller
> firmware then
On Tue, Sep 11, 2018 at 01:02:00PM +, mario.limoncie...@dell.com wrote:
> > I tried 9370 and it detects the adapter correctly. IIRC I did the same
> > for 5530 and it worked as well.
>
> Thanks for confirming that. Hopefully the same change can be ported to PD
> controller
> firmware then
On Mon, Sep 10, 2018 at 09:16:12PM +0530, Souptick Joarder wrote:
> Return type of ext4_page_mkwrite and ext4_filemap_fault are
> changed to use vm_fault_t type.
>
> With this patch all the callers of block_page_mkwrite_return()
> are changed to handle vm_fault_t. So converting the return type
>
On Mon, Sep 10, 2018 at 09:16:12PM +0530, Souptick Joarder wrote:
> Return type of ext4_page_mkwrite and ext4_filemap_fault are
> changed to use vm_fault_t type.
>
> With this patch all the callers of block_page_mkwrite_return()
> are changed to handle vm_fault_t. So converting the return type
>
On Tue, Sep 25, 2018 at 04:44:03PM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:846e8dd47c26 Merge tag 'scsi-fixes' of git://git.kernel.or..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=15c874a140
>
On Tue, Sep 25, 2018 at 04:44:03PM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:846e8dd47c26 Merge tag 'scsi-fixes' of git://git.kernel.or..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=15c874a140
>
On Mon, Sep 24, 2018 at 06:19:02AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:46c163a036b4 Add linux-next specific files for 20180921
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=1283fef140
> kernel
On Mon, Sep 24, 2018 at 06:19:02AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:46c163a036b4 Add linux-next specific files for 20180921
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=1283fef140
> kernel
On Sun, Sep 30, 2018 at 11:58:02PM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:17b57b1883c1 Linux 4.19-rc6
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1672d71140
> kernel config:
On Sun, Sep 30, 2018 at 11:58:02PM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:17b57b1883c1 Linux 4.19-rc6
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1672d71140
> kernel config:
This is fixed with the following patch.
- Ted
>From c4a928ee604e31354c969b461aa9a6171825096a Mon Sep 17 00:00:00 2001
From: Theodore Ts'o
Date: Tue, 2 Oct 2018 01:34:44 -0400
Subject: [PATCH] ext4: fix argument checking in EXT4_IOC_MOVE_EXT
If
This is fixed with the following patch.
- Ted
>From c4a928ee604e31354c969b461aa9a6171825096a Mon Sep 17 00:00:00 2001
From: Theodore Ts'o
Date: Tue, 2 Oct 2018 01:34:44 -0400
Subject: [PATCH] ext4: fix argument checking in EXT4_IOC_MOVE_EXT
If
On Mon, Oct 01, 2018 at 04:04:42PM +0100, Alan Cox wrote:
> > Systems restricted by LSMs to the point where CAP_SYS_ADMIN is not
> > trusted have exactly the same issues. i.e. there's nobody trusted by
> > the kernel to administer the storage stack, and nobody has defined a
> > workable security
On Mon, Oct 01, 2018 at 04:04:42PM +0100, Alan Cox wrote:
> > Systems restricted by LSMs to the point where CAP_SYS_ADMIN is not
> > trusted have exactly the same issues. i.e. there's nobody trusted by
> > the kernel to administer the storage stack, and nobody has defined a
> > workable security
On Thu, Sep 27, 2018 at 08:43:10AM -0400, Jeff Layton wrote:
>
> Basically, the problem (as I see it) is that we can end up evicting
> uncleanable data from the cache before you have a chance to call fsync,
> and that means that the results of a read after a write are not
> completely reliable.
On Thu, Sep 27, 2018 at 08:43:10AM -0400, Jeff Layton wrote:
>
> Basically, the problem (as I see it) is that we can end up evicting
> uncleanable data from the cache before you have a chance to call fsync,
> and that means that the results of a read after a write are not
> completely reliable.
On Wed, Sep 26, 2018 at 07:10:55PM +0100, Alan Cox wrote:
> In almost all cases you don't care so you wouldn't use it. In those cases
> where it might matter it's almost always the case that a reader won't
> consume it before it hits the media.
>
> That's why I suggested having an fbarrier() so
On Wed, Sep 26, 2018 at 07:10:55PM +0100, Alan Cox wrote:
> In almost all cases you don't care so you wouldn't use it. In those cases
> where it might matter it's almost always the case that a reader won't
> consume it before it hits the media.
>
> That's why I suggested having an fbarrier() so
On Wed, Sep 26, 2018 at 05:55:18PM +0300, Дмитрий Леонтьев wrote:
> Or: "Why you should not use "kill switch" option proposed by smdy to
> protest against CoC"
>
> Hello.
>
> I'm neither a great software developer nor a lawyer, but I'm not a
> novice and I'm very annoyed whan I see this:
>
>
On Wed, Sep 26, 2018 at 05:55:18PM +0300, Дмитрий Леонтьев wrote:
> Or: "Why you should not use "kill switch" option proposed by smdy to
> protest against CoC"
>
> Hello.
>
> I'm neither a great software developer nor a lawyer, but I'm not a
> novice and I'm very annoyed whan I see this:
>
>
On Tue, Sep 25, 2018 at 08:44:39PM -0400, TongZhang wrote:
> Yes, this is exactly what I am saying.
> A process can change its own name using prctl or /proc/self/comm.
> prctl is protected by security_task_prctl, whereas /proc/self/comm is not
> protected by this LSM hook.
>
> A system admin may
On Tue, Sep 25, 2018 at 08:44:39PM -0400, TongZhang wrote:
> Yes, this is exactly what I am saying.
> A process can change its own name using prctl or /proc/self/comm.
> prctl is protected by security_task_prctl, whereas /proc/self/comm is not
> protected by this LSM hook.
>
> A system admin may
On Tue, Sep 25, 2018 at 01:52:57PM -0400, Stephen Smalley wrote:
> On 09/25/2018 01:27 PM, Tong Zhang wrote:
> > Kernel Version: 4.18.5
> >
> > Problem Description:
> >
> > When setting nice value, it is checked by LSM function
> > security_task_setnice().
> > see kernel/sched/core.c:3972
On Tue, Sep 25, 2018 at 01:52:57PM -0400, Stephen Smalley wrote:
> On 09/25/2018 01:27 PM, Tong Zhang wrote:
> > Kernel Version: 4.18.5
> >
> > Problem Description:
> >
> > When setting nice value, it is checked by LSM function
> > security_task_setnice().
> > see kernel/sched/core.c:3972
On Tue, Sep 25, 2018 at 07:35:11PM +0200, Adam Borowski wrote:
> Isn't this what the snippet for O_TMPFILE in "man 2 open" does?:
>
> char path[PATH_MAX];
> fd = open("/path/to/dir", O_TMPFILE | O_RDWR,
> S_IRUSR |
On Tue, Sep 25, 2018 at 07:35:11PM +0200, Adam Borowski wrote:
> Isn't this what the snippet for O_TMPFILE in "man 2 open" does?:
>
> char path[PATH_MAX];
> fd = open("/path/to/dir", O_TMPFILE | O_RDWR,
> S_IRUSR |
On Tue, Sep 25, 2018 at 12:41:18PM -0400, Jeff Layton wrote:
> That's all well and good, but still doesn't quite solve the main concern
> with all of this. It's suppose we have this series of events:
>
> open file r/w
> write 1024 bytes to offset 0
>
> read 1024 bytes from offset 0
>
> Open,
On Tue, Sep 25, 2018 at 12:41:18PM -0400, Jeff Layton wrote:
> That's all well and good, but still doesn't quite solve the main concern
> with all of this. It's suppose we have this series of events:
>
> open file r/w
> write 1024 bytes to offset 0
>
> read 1024 bytes from offset 0
>
> Open,
On Tue, Sep 25, 2018 at 07:15:34AM -0400, Jeff Layton wrote:
> Linux has dozens of filesystems and they all behave differently in this
> regard. A catastrophic failure (paradoxically) makes things simpler for
> the fs developer, but even on local filesystems isolated errors can
> occur. It's also
On Tue, Sep 25, 2018 at 07:15:34AM -0400, Jeff Layton wrote:
> Linux has dozens of filesystems and they all behave differently in this
> regard. A catastrophic failure (paradoxically) makes things simpler for
> the fs developer, but even on local filesystems isolated errors can
> occur. It's also
On Tue, Sep 25, 2018 at 02:36:45PM +0200, Christoph Conrads wrote:
> The CoC is a political document:
> https://web.archive.org/web/20180924234027/https://twitter.com/coralineada/status/1041465346656530432
...
> Here is the author's post-meritocracy manifesto:
> https://postmeritocracy.org/
On Tue, Sep 25, 2018 at 02:36:45PM +0200, Christoph Conrads wrote:
> The CoC is a political document:
> https://web.archive.org/web/20180924234027/https://twitter.com/coralineada/status/1041465346656530432
...
> Here is the author's post-meritocracy manifesto:
> https://postmeritocracy.org/
People can decide who they want to respond to, but I'm going to gently
suggest that before people think about responding to a particular
e-mail, that they do a quick check using "git log --author=xy...@example.com"
then decide how much someone appears to be a member of the community
before
People can decide who they want to respond to, but I'm going to gently
suggest that before people think about responding to a particular
e-mail, that they do a quick check using "git log --author=xy...@example.com"
then decide how much someone appears to be a member of the community
before
On Thu, Sep 20, 2018 at 02:16:40AM +0100, Olof Johansson wrote:
> > But there are too many ways this can go wrong, maybe not now or next
> > week but in five or ten years, when maybe a different kind of person
> > is on the TAB, or maybe external pressure is brought to bear on TAB
> > members.
On Thu, Sep 20, 2018 at 02:16:40AM +0100, Olof Johansson wrote:
> > But there are too many ways this can go wrong, maybe not now or next
> > week but in five or ten years, when maybe a different kind of person
> > is on the TAB, or maybe external pressure is brought to bear on TAB
> > members.
[ This pull request was originally intended for 4.19-rc4, but some
testing hiccups delayed my sending this earlier. Given Linus's
comments, I'm not sure whether PULL requests should be going to Linus
or Greg, so I'm sending it to both. -- Ted ]
The following changes since commit
[ This pull request was originally intended for 4.19-rc4, but some
testing hiccups delayed my sending this earlier. Given Linus's
comments, I'm not sure whether PULL requests should be going to Linus
or Greg, so I'm sending it to both. -- Ted ]
The following changes since commit
The following changes since commit 9a47249d444d344051c7c0e909fad0e88515a5c2:
random: Make crng state queryable (2018-08-02 17:33:06 -0400)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random.git tags/for_linus
for you to fetch changes up to
The following changes since commit 9a47249d444d344051c7c0e909fad0e88515a5c2:
random: Make crng state queryable (2018-08-02 17:33:06 -0400)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random.git tags/for_linus
for you to fetch changes up to
On Thu, Sep 06, 2018 at 03:13:23PM +0100, Matt Hart wrote:
> On 6 September 2018 at 15:04, Theodore Y. Ts'o wrote:
> > On Thu, Sep 06, 2018 at 06:45:15AM -0700, Guenter Roeck wrote:
> >> Build results:
> >> total: 134 pass: 133 fail: 1
>
> Do you build
On Thu, Sep 06, 2018 at 03:13:23PM +0100, Matt Hart wrote:
> On 6 September 2018 at 15:04, Theodore Y. Ts'o wrote:
> > On Thu, Sep 06, 2018 at 06:45:15AM -0700, Guenter Roeck wrote:
> >> Build results:
> >> total: 134 pass: 133 fail: 1
>
> Do you build
On Thu, Sep 06, 2018 at 09:41:04AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:b36fdc6853a3 Merge tag 'gpio-v4.19-2' of git://git.kernel...
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1716bc9e40
>
On Thu, Sep 06, 2018 at 09:41:04AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:b36fdc6853a3 Merge tag 'gpio-v4.19-2' of git://git.kernel...
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1716bc9e40
>
P.S. This is the second time the vm_fualt_t change has broken things.
The first time, when it went through the ext4 tree, I NACK'ed it after
a 60 seconds smoke test showed it was broken. This time it went
through the mm tree...
In the future, even for "trivial" changes, could you *please* run
401 - 500 of 3865 matches
Mail list logo
