On Tue, 2020-11-24 at 13:32 -0800, Kees Cook wrote:
> On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> > Really, no ... something which produces no improvement has no value
> > at all ... we really shouldn't be wasting maintainer time with it
> > because it has a cost to merge.
On Wed, Nov 25, 2020 at 12:53 AM Finn Thain wrote:
>
> I'm saying that supporting the official language spec makes more sense
> than attempting to support a multitude of divergent interpretations of the
> spec (i.e. gcc, clang, coverity etc.)
Making the kernel strictly conforming is a ship that
On Mon, Nov 23, 2020 at 9:38 PM James Bottomley
wrote:
>
> So you think a one line patch should take one minute to produce ... I
> really don't think that's grounded in reality.
No, I have not said that. Please don't put words in my mouth (again).
I have said *authoring* lines of *this* kind
On Wed, 25 Nov 2020, Miguel Ojeda wrote:
>
> The C standard has nothing to do with this. We use compiler extensions
> of several kinds, for many years. Even discounting those extensions, the
> kernel is not even conforming to C due to e.g. strict aliasing. I am not
> sure what you are
On Tue, Nov 24, 2020 at 1:58 AM Finn Thain wrote:
>
> What I meant was that you've used pessimism as if it was fact.
"future mistakes that it might prevent" is neither pessimism nor states a fact.
> For example, "There is no way to guess what the effect would be if the
> compiler trained
On Tue, Nov 24, 2020 at 11:24 PM Finn Thain wrote:
>
> These statements are not "missing" unless you presume that code written
> before the latest de facto language spec was written should somehow be
> held to that spec.
There is no "language spec" the kernel adheres to. Even if it did,
kernel
On Tue, 24 Nov 2020, Kees Cook wrote:
> On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> > Really, no ... something which produces no improvement has no value at
> > all ... we really shouldn't be wasting maintainer time with it because
> > it has a cost to merge. I'm not
On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> Really, no ... something which produces no improvement has no value at
> all ... we really shouldn't be wasting maintainer time with it because
> it has a cost to merge. I'm not sure we understand where the balance
> lies in value
On Mon, Nov 23, 2020 at 05:32:51PM -0800, Nick Desaulniers wrote:
> On Sun, Nov 22, 2020 at 8:17 AM Kees Cook wrote:
> >
> > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > > If none of the 140 patches here fix a real bug, and there is no change
> > > to machine code then it
Hi,
GFS2's freeze/thaw mechanism uses a special freeze glock to control its
operation. It does this with a sync glock operation (glops.c) called
freeze_go_sync. When the freeze glock is demoted (glock's do_xmote) the
glops function causes the file system to be frozen. This is intended. However,
Hi,
Before this patch, function gfs2_statfs_sync called sb_start_write. This is a
violation of the basic vfs rules that state that sb_start_write should always
be taken before s_umount. See this document:
https://www.kernel.org/doc/htmldocs/filesystems/API-sb-start-write.html
"Since freeze
Commit 20f82c38 ("gfs2: Rework read and page fault locking") has lifted the
glock lock taking from the low-level ->readpage and ->readahead address space
operations to the higher-level ->read_iter file and ->fault vm operations. The
glocks are still taken in LM_ST_SHARED mode only. On
On Tue, Nov 24, 2020 at 4:44 PM Bob Peterson wrote:
> If gfs2 tries to mount a (corrupt) file system that has no resource groups
> it still tries to set preferences on the first one, which causes a kernel null
> pointer dereference. This patch adds a check to function gfs2_ri_update so
> this
Hi,
If gfs2 tries to mount a (corrupt) file system that has no resource groups
it still tries to set preferences on the first one, which causes a kernel null
pointer dereference. This patch adds a check to function gfs2_ri_update so
this condition is detected and reported back as an error.
Hi,
On Fri, Nov 13, 2020 at 5:58 PM Alexander Aring wrote:
>
> This patch removes unaligned memory access handling for receiving
> midcomms messages. The allocated receive buffer is always memory aligned
> as the code shows, but each dlm message length and their structure fields
> are always
On Mon, Nov 23, 2020 at 08:38:46PM +, Mark Brown wrote:
> On Fri, 20 Nov 2020 12:21:39 -0600, Gustavo A. R. Silva wrote:
> > This series aims to fix almost all remaining fall-through warnings in
> > order to enable -Wimplicit-fallthrough for Clang.
> >
> > In preparation to enable
On Mon, Nov 23, 2020 at 04:03:45PM -0400, Jason Gunthorpe wrote:
> On Fri, Nov 20, 2020 at 12:21:39PM -0600, Gustavo A. R. Silva wrote:
>
> > IB/hfi1: Fix fall-through warnings for Clang
> > IB/mlx4: Fix fall-through warnings for Clang
> > IB/qedr: Fix fall-through warnings for Clang
> >
On Mon, 23 Nov 2020, Joe Perches wrote:
> On Tue, 2020-11-24 at 11:58 +1100, Finn Thain wrote:
> > it's not for me to prove that such patches don't affect code
> > generation. That's for the patch author and (unfortunately) for
> > reviewers.
>
> Ideally, that proof would be provided by the
On 11/22/20 10:22 AM, Joe Perches wrote:
> On Sun, 2020-11-22 at 08:33 -0800, Tom Rix wrote:
>> On 11/21/20 9:10 AM, Joe Perches wrote:
>>> On Sat, 2020-11-21 at 08:50 -0800, t...@redhat.com wrote:
A difficult part of automating commits is composing the subsystem
preamble in the commit
On Fri, Nov 20, 2020 at 12:21:39PM -0600, Gustavo A. R. Silva wrote:
> IB/hfi1: Fix fall-through warnings for Clang
> IB/mlx4: Fix fall-through warnings for Clang
> IB/qedr: Fix fall-through warnings for Clang
> RDMA/mlx5: Fix fall-through warnings for Clang
I picked these four to the
On Mon, 23 Nov 2020 17:32:51 -0800 Nick Desaulniers wrote:
> On Sun, Nov 22, 2020 at 8:17 AM Kees Cook wrote:
> > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > > If none of the 140 patches here fix a real bug, and there is no change
> > > to machine code then it sounds to
On Fri, 20 Nov 2020 12:21:39 -0600, Gustavo A. R. Silva wrote:
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
>
> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> add multiple
On Mon, 23 Nov 2020, Miguel Ojeda wrote:
> On Mon, 23 Nov 2020, Finn Thain wrote:
>
> > On Sun, 22 Nov 2020, Miguel Ojeda wrote:
> >
> > >
> > > It isn't that much effort, isn't it? Plus we need to take into
> > > account the future mistakes that it might prevent, too.
> >
> > We should
23 matches
Mail list logo
