Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1217750 > unrolled thread

[GIT PULL] SG changes for 4.3

Back to article view | Back to linux.kernel

Contents

  [GIT PULL] SG changes for 4.3 Jens Axboe <axboe@fb.com> - 2015-09-02 19:00 +0200
    Re: [GIT PULL] SG changes for 4.3 Linus Torvalds <torvalds@linux-foundation.org> - 2015-09-03 00:40 +0200
      Re: [GIT PULL] SG changes for 4.3 Jens Axboe <axboe@fb.com> - 2015-09-03 00:50 +0200
        Re: [GIT PULL] SG changes for 4.3 Jens Axboe <axboe@fb.com> - 2015-09-03 01:00 +0200
          Re: [GIT PULL] SG changes for 4.3 Ming Lin <mlin@kernel.org> - 2015-09-03 06:30 +0200
            Re: [GIT PULL] SG changes for 4.3 Jens Axboe <axboe@fb.com> - 2015-09-03 16:40 +0200

#1217750 — [GIT PULL] SG changes for 4.3

Hi Linus,

This pull request contains a set of scatter-gather related changes/fixes
for 4.3. It contains:

- Add support for limited chaining of sg tables even for architectures
  that do not set ARCH_HAS_SG_CHAIN. From Christoph.

- Add sg chain support to target_rd. From Christoph.

- Fixup open coded sg->page_link in crypto/omap-sham. From Christoph.

- Fixup open coded crypto ->page_link manipulation. From Dan.

- Also from Dan, automated fixup of manual sg_unmark_end()
  manipulations.

- Also from Dan, automated fixup of open coded sg_phys()
  implementations.

- From Robert Jarzmik, addition of an sg table splitting helper that
  drivers can use.

Please pull!


  git://git.kernel.dk/linux-block.git for-4.3/sg


----------------------------------------------------------------
Christoph Hellwig (3):
      scatterlist: allow limited chaining without ARCH_HAS_SG_CHAIN
      target/rd: always chain S/G list
      crypto/omap-sham: remove an open coded access to ->page_link

Dan Williams (3):
      crypto: replace scatterwalk_sg_chain with sg_chain
      scatterlist: remove open coded sg_unmark_end instances
      scatterlist: use sg_phys()

Robert Jarzmik (1):
      lib: scatterlist: add sg splitting function

 arch/arm/mm/dma-mapping.c                    |   2 +-
 arch/microblaze/kernel/dma.c                 |   3 +-
 block/blk-merge.c                            |   2 +-
 crypto/algif_skcipher.c                      |   2 +-
 crypto/ccm.c                                 |   8 +-
 crypto/gcm.c                                 |   4 +-
 drivers/crypto/bfin_crc.c                    |   3 +-
 drivers/crypto/omap-sham.c                   |   2 +-
 drivers/crypto/qce/sha.c                     |   2 +-
 drivers/crypto/sahara.c                      |   2 +-
 drivers/crypto/talitos.c                     |   2 +-
 drivers/iommu/intel-iommu.c                  |   4 +-
 drivers/iommu/iommu.c                        |   2 +-
 drivers/mmc/card/queue.c                     |   4 +-
 drivers/staging/android/ion/ion_chunk_heap.c |   4 +-
 drivers/target/target_core_rd.c              |  44 ------
 include/crypto/scatterwalk.h                 |  10 +-
 include/linux/scatterlist.h                  |   9 +-
 lib/Kconfig                                  |   7 +
 lib/Makefile                                 |   1 +
 lib/scatterlist.c                            |   4 -
 lib/sg_split.c                               | 202 +++++++++++++++++++++++++++
 22 files changed, 238 insertions(+), 85 deletions(-)
 create mode 100644 lib/sg_split.c

-- 
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1217884

Jens,

On Wed, Sep 2, 2015 at 9:58 AM, Jens Axboe <axboe@fb.com> wrote:
>
> This pull request contains a set of scatter-gather related changes/fixes
> for 4.3. It contains:

This results in several new and annoying warnings. They may all be ok
code, but they are very distracting. Please stop introducing new
warnings to the build, because by now most of the warnings I see come
from the block layer.

   block/blk-merge.c: In function ‘blk_queue_split’:
   include/linux/blkdev.h:1368:21: warning: ‘bvprv.bv_offset’ may be
used uninitialized in this function [-Wmaybe-uninitialized]
     ((bprv->bv_offset + bprv->bv_len) & queue_virt_boundary(q));

(it gives this for bv_len too). The reason seems to be that disgusting
situation where "bvprv" is uninitiatlized unless "split" is true, and
the code looks like it is correct, but the compiler clearly has a hard
time seeing it. It took me a while too, so I can't really blame it.

Either initialize bvprv to something explicit, or make the code clear
enough that the compiler can see that it is never used uninitialized.
Because those compiler warnings are sometimes real, and we can't just
ignore them.

There was another type-based warning introduced by your core block
pull (size_t vs unsigned int).

                  Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1217886

On 09/02/2015 04:34 PM, Linus Torvalds wrote:
> Jens,
>
> On Wed, Sep 2, 2015 at 9:58 AM, Jens Axboe <axboe@fb.com> wrote:
>>
>> This pull request contains a set of scatter-gather related changes/fixes
>> for 4.3. It contains:
>
> This results in several new and annoying warnings. They may all be ok
> code, but they are very distracting. Please stop introducing new
> warnings to the build, because by now most of the warnings I see come
> from the block layer.
>
>     block/blk-merge.c: In function ‘blk_queue_split’:
>     include/linux/blkdev.h:1368:21: warning: ‘bvprv.bv_offset’ may be
> used uninitialized in this function [-Wmaybe-uninitialized]
>       ((bprv->bv_offset + bprv->bv_len) & queue_virt_boundary(q));
>
> (it gives this for bv_len too). The reason seems to be that disgusting
> situation where "bvprv" is uninitiatlized unless "split" is true, and
> the code looks like it is correct, but the compiler clearly has a hard
> time seeing it. It took me a while too, so I can't really blame it.
>
> Either initialize bvprv to something explicit, or make the code clear
> enough that the compiler can see that it is never used uninitialized.
> Because those compiler warnings are sometimes real, and we can't just
> ignore them.
>
> There was another type-based warning introduced by your core block
> pull (size_t vs unsigned int).

I think it's a repeat offender that got reintroduced. I'll fix it up.

-- 
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1217901

On 09/02/2015 04:41 PM, Jens Axboe wrote:
> On 09/02/2015 04:34 PM, Linus Torvalds wrote:
>> Jens,
>>
>> On Wed, Sep 2, 2015 at 9:58 AM, Jens Axboe <axboe@fb.com> wrote:
>>>
>>> This pull request contains a set of scatter-gather related changes/fixes
>>> for 4.3. It contains:
>>
>> This results in several new and annoying warnings. They may all be ok
>> code, but they are very distracting. Please stop introducing new
>> warnings to the build, because by now most of the warnings I see come
>> from the block layer.
>>
>>     block/blk-merge.c: In function ‘blk_queue_split’:
>>     include/linux/blkdev.h:1368:21: warning: ‘bvprv.bv_offset’ may be
>> used uninitialized in this function [-Wmaybe-uninitialized]
>>       ((bprv->bv_offset + bprv->bv_len) & queue_virt_boundary(q));
>>
>> (it gives this for bv_len too). The reason seems to be that disgusting
>> situation where "bvprv" is uninitiatlized unless "split" is true, and
>> the code looks like it is correct, but the compiler clearly has a hard
>> time seeing it. It took me a while too, so I can't really blame it.
>>
>> Either initialize bvprv to something explicit, or make the code clear
>> enough that the compiler can see that it is never used uninitialized.
>> Because those compiler warnings are sometimes real, and we can't just
>> ignore them.
>>
>> There was another type-based warning introduced by your core block
>> pull (size_t vs unsigned int).
>
> I think it's a repeat offender that got reintroduced. I'll fix it up.

This seems to make it happier. Will go out later in the merge window.

http://git.kernel.dk/cgit/linux-block/commit/?h=for-linus&id=5014c311baa2b21384321fa4a9f617a92e3e56f0

-- 
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1218024

On Wed, Sep 2, 2015 at 3:50 PM, Jens Axboe <axboe@fb.com> wrote:
> On 09/02/2015 04:41 PM, Jens Axboe wrote:
>>
>> On 09/02/2015 04:34 PM, Linus Torvalds wrote:
>>>
>>> Jens,
>>>
>>> On Wed, Sep 2, 2015 at 9:58 AM, Jens Axboe <axboe@fb.com> wrote:
>>>>
>>>>
>>>> This pull request contains a set of scatter-gather related changes/fixes
>>>> for 4.3. It contains:
>>>
>>>
>>> This results in several new and annoying warnings. They may all be ok
>>> code, but they are very distracting. Please stop introducing new
>>> warnings to the build, because by now most of the warnings I see come
>>> from the block layer.
>>>
>>>     block/blk-merge.c: In function ‘blk_queue_split’:
>>>     include/linux/blkdev.h:1368:21: warning: ‘bvprv.bv_offset’ may be
>>> used uninitialized in this function [-Wmaybe-uninitialized]
>>>       ((bprv->bv_offset + bprv->bv_len) & queue_virt_boundary(q));
>>>
>>> (it gives this for bv_len too). The reason seems to be that disgusting
>>> situation where "bvprv" is uninitiatlized unless "split" is true, and
>>> the code looks like it is correct, but the compiler clearly has a hard
>>> time seeing it. It took me a while too, so I can't really blame it.
>>>
>>> Either initialize bvprv to something explicit, or make the code clear
>>> enough that the compiler can see that it is never used uninitialized.
>>> Because those compiler warnings are sometimes real, and we can't just
>>> ignore them.
>>>
>>> There was another type-based warning introduced by your core block
>>> pull (size_t vs unsigned int).
>>
>>
>> I think it's a repeat offender that got reintroduced. I'll fix it up.
>
>
> This seems to make it happier. Will go out later in the merge window.
>
> http://git.kernel.dk/cgit/linux-block/commit/?h=for-linus&id=5014c311baa2b21384321fa4a9f617a92e3e56f0

Thanks Jens.

I didn't see these warnings with gcc 4.8.4.
What gcc version did you use or need to turn on some config option to
see the warning?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1218295

On 09/02/2015 10:28 PM, Ming Lin wrote:
> On Wed, Sep 2, 2015 at 3:50 PM, Jens Axboe <axboe@fb.com> wrote:
>> On 09/02/2015 04:41 PM, Jens Axboe wrote:
>>>
>>> On 09/02/2015 04:34 PM, Linus Torvalds wrote:
>>>>
>>>> Jens,
>>>>
>>>> On Wed, Sep 2, 2015 at 9:58 AM, Jens Axboe <axboe@fb.com> wrote:
>>>>>
>>>>>
>>>>> This pull request contains a set of scatter-gather related changes/fixes
>>>>> for 4.3. It contains:
>>>>
>>>>
>>>> This results in several new and annoying warnings. They may all be ok
>>>> code, but they are very distracting. Please stop introducing new
>>>> warnings to the build, because by now most of the warnings I see come
>>>> from the block layer.
>>>>
>>>>      block/blk-merge.c: In function ‘blk_queue_split’:
>>>>      include/linux/blkdev.h:1368:21: warning: ‘bvprv.bv_offset’ may be
>>>> used uninitialized in this function [-Wmaybe-uninitialized]
>>>>        ((bprv->bv_offset + bprv->bv_len) & queue_virt_boundary(q));
>>>>
>>>> (it gives this for bv_len too). The reason seems to be that disgusting
>>>> situation where "bvprv" is uninitiatlized unless "split" is true, and
>>>> the code looks like it is correct, but the compiler clearly has a hard
>>>> time seeing it. It took me a while too, so I can't really blame it.
>>>>
>>>> Either initialize bvprv to something explicit, or make the code clear
>>>> enough that the compiler can see that it is never used uninitialized.
>>>> Because those compiler warnings are sometimes real, and we can't just
>>>> ignore them.
>>>>
>>>> There was another type-based warning introduced by your core block
>>>> pull (size_t vs unsigned int).
>>>
>>>
>>> I think it's a repeat offender that got reintroduced. I'll fix it up.
>>
>>
>> This seems to make it happier. Will go out later in the merge window.
>>
>> https://urldefense.proofpoint.com/v1/url?u=http://git.kernel.dk/cgit/linux-block/commit/?h%3Dfor-linus%26id%3D5014c311baa2b21384321fa4a9f617a92e3e56f0&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=3JMVyziIyZtZ5cv9eWNLwQ%3D%3D%0A&m=japm7LD5hS2iGfc2KmNCva0tg%2FTlU%2BypJqbyuKQJk6U%3D%0A&s=dbea685c3231dae01cce41309c39c6c1597bd0dd1b4d6fbe5ee4caae86385fe8
>
> Thanks Jens.
>
> I didn't see these warnings with gcc 4.8.4.
> What gcc version did you use or need to turn on some config option to
> see the warning?

axboe@lenny:~ $ gcc --version
gcc (Ubuntu 5.1.0-0ubuntu11~14.04.1) 5.1.0

Looks like gcc is growing dumber.

-- 
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web