[GIT PULL] iscsi-target merge for v3.1-rc1

[GIT PULL] iscsi-target merge for v3.1-rc1

[Nicholas A. Bellinger]

Hi Linus,

So in the spirit of timely pull requests ahead of your upcoming summer
vacation, here is the long awaited and much debated initial merge commit
for v3.1-rc1 of drivers/target/iscsi to sync with latest bleeding edge
LIO v4.1 codebase.

As with the v3.0 merge canidate this spring, this commit contains a
fully functional in-kernel iscsi-target that uses the mainline target
infrastructure for a native configfs control plane, and is compatiable
with rtslib v2.x python object library.

Please go ahead and pull from:

  master.kernel.org:/pub/scm/linux/kernel/git/nab/target-pending.git for-linus-merge

This tree is also available from kernel.org mirrors at:

  git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git for-linus-merge

I'll be tracking fixes from the merge canidate posted this morning, and
considering the amount of changes from Andy and Christoph over the last
months, this code will certainly require alot more testing throughout
the duration of v3.1 development cycle to get all the bugs shaken out.

Again, I would like to thank Andy and Christoph for pushing forward v4.1
development.  Also big thanks to all the folks over the numerous
releases who have helped to review and make incremental improvements to
the codebase, all those folks who reported bugs and in some cases, drove
the efforts to rentlessly to verify the proper fixes.

Please let us know if you have any immediate concerns,

Thank you!

Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Andy Grover <agrover@redhat.com>
Acked-by: Roland Dreier <roland@kernel.org>
Signed-off-by: Nicholas A. Bellinger <nab@linux-iscsi.org>

Nicholas Bellinger (3):
  iscsi: Resolve iscsi_proto.h naming conflicts with
    drivers/target/iscsi
  iscsi: Add Serial Number Arithmetic LT and GT into iscsi_proto.h
  iscsi-target: Add iSCSI fabric support for target v4.1

 drivers/infiniband/ulp/iser/iser_initiator.c      |    2 +-
 drivers/scsi/be2iscsi/be_main.h                   |    4 +-
 drivers/scsi/bnx2i/bnx2i_hwi.c                    |    8 +-
 drivers/scsi/libiscsi.c                           |   22 +-
 drivers/target/Kconfig                            |    1 +
 drivers/target/Makefile                           |    2 +-
 drivers/target/iscsi/Kconfig                      |    8 +
 drivers/target/iscsi/Makefile                     |   20 +
 drivers/target/iscsi/iscsi_target.c               | 4559 +++++++++++++++++++++
 drivers/target/iscsi/iscsi_target.h               |   42 +
 drivers/target/iscsi/iscsi_target_auth.c          |  490 +++
 drivers/target/iscsi/iscsi_target_auth.h          |   31 +
 drivers/target/iscsi/iscsi_target_configfs.c      | 1882 +++++++++
 drivers/target/iscsi/iscsi_target_configfs.h      |    7 +
 drivers/target/iscsi/iscsi_target_core.h          |  859 ++++
 drivers/target/iscsi/iscsi_target_datain_values.c |  531 +++
 drivers/target/iscsi/iscsi_target_datain_values.h |   12 +
 drivers/target/iscsi/iscsi_target_device.c        |   87 +
 drivers/target/iscsi/iscsi_target_device.h        |    9 +
 drivers/target/iscsi/iscsi_target_erl0.c          | 1004 +++++
 drivers/target/iscsi/iscsi_target_erl0.h          |   15 +
 drivers/target/iscsi/iscsi_target_erl1.c          | 1299 ++++++
 drivers/target/iscsi/iscsi_target_erl1.h          |   26 +
 drivers/target/iscsi/iscsi_target_erl2.c          |  474 +++
 drivers/target/iscsi/iscsi_target_erl2.h          |   18 +
 drivers/target/iscsi/iscsi_target_login.c         | 1232 ++++++
 drivers/target/iscsi/iscsi_target_login.h         |   12 +
 drivers/target/iscsi/iscsi_target_nego.c          | 1067 +++++
 drivers/target/iscsi/iscsi_target_nego.h          |   17 +
 drivers/target/iscsi/iscsi_target_nodeattrib.c    |  263 ++
 drivers/target/iscsi/iscsi_target_nodeattrib.h    |   14 +
 drivers/target/iscsi/iscsi_target_parameters.c    | 1905 +++++++++
 drivers/target/iscsi/iscsi_target_parameters.h    |  269 ++
 drivers/target/iscsi/iscsi_target_seq_pdu_list.c  |  664 +++
 drivers/target/iscsi/iscsi_target_seq_pdu_list.h  |   86 +
 drivers/target/iscsi/iscsi_target_stat.c          |  950 +++++
 drivers/target/iscsi/iscsi_target_stat.h          |   64 +
 drivers/target/iscsi/iscsi_target_tmr.c           |  849 ++++
 drivers/target/iscsi/iscsi_target_tmr.h           |   14 +
 drivers/target/iscsi/iscsi_target_tpg.c           |  759 ++++
 drivers/target/iscsi/iscsi_target_tpg.h           |   41 +
 drivers/target/iscsi/iscsi_target_tq.c            |  551 +++
 drivers/target/iscsi/iscsi_target_tq.h            |   88 +
 drivers/target/iscsi/iscsi_target_util.c          | 1819 ++++++++
 drivers/target/iscsi/iscsi_target_util.h          |   60 +
 include/scsi/iscsi_proto.h                        |   60 +-
 46 files changed, 22161 insertions(+), 35 deletions(-)
 create mode 100644 drivers/target/iscsi/Kconfig
 create mode 100644 drivers/target/iscsi/Makefile
 create mode 100644 drivers/target/iscsi/iscsi_target.c
 create mode 100644 drivers/target/iscsi/iscsi_target.h
 create mode 100644 drivers/target/iscsi/iscsi_target_auth.c
 create mode 100644 drivers/target/iscsi/iscsi_target_auth.h
 create mode 100644 drivers/target/iscsi/iscsi_target_configfs.c
 create mode 100644 drivers/target/iscsi/iscsi_target_configfs.h
 create mode 100644 drivers/target/iscsi/iscsi_target_core.h
 create mode 100644 drivers/target/iscsi/iscsi_target_datain_values.c
 create mode 100644 drivers/target/iscsi/iscsi_target_datain_values.h
 create mode 100644 drivers/target/iscsi/iscsi_target_device.c
 create mode 100644 drivers/target/iscsi/iscsi_target_device.h
 create mode 100644 drivers/target/iscsi/iscsi_target_erl0.c
 create mode 100644 drivers/target/iscsi/iscsi_target_erl0.h
 create mode 100644 drivers/target/iscsi/iscsi_target_erl1.c
 create mode 100644 drivers/target/iscsi/iscsi_target_erl1.h
 create mode 100644 drivers/target/iscsi/iscsi_target_erl2.c
 create mode 100644 drivers/target/iscsi/iscsi_target_erl2.h
 create mode 100644 drivers/target/iscsi/iscsi_target_login.c
 create mode 100644 drivers/target/iscsi/iscsi_target_login.h
 create mode 100644 drivers/target/iscsi/iscsi_target_nego.c
 create mode 100644 drivers/target/iscsi/iscsi_target_nego.h
 create mode 100644 drivers/target/iscsi/iscsi_target_nodeattrib.c
 create mode 100644 drivers/target/iscsi/iscsi_target_nodeattrib.h
 create mode 100644 drivers/target/iscsi/iscsi_target_parameters.c
 create mode 100644 drivers/target/iscsi/iscsi_target_parameters.h
 create mode 100644 drivers/target/iscsi/iscsi_target_seq_pdu_list.c
 create mode 100644 drivers/target/iscsi/iscsi_target_seq_pdu_list.h
 create mode 100644 drivers/target/iscsi/iscsi_target_stat.c
 create mode 100644 drivers/target/iscsi/iscsi_target_stat.h
 create mode 100644 drivers/target/iscsi/iscsi_target_tmr.c
 create mode 100644 drivers/target/iscsi/iscsi_target_tmr.h
 create mode 100644 drivers/target/iscsi/iscsi_target_tpg.c
 create mode 100644 drivers/target/iscsi/iscsi_target_tpg.h
 create mode 100644 drivers/target/iscsi/iscsi_target_tq.c
 create mode 100644 drivers/target/iscsi/iscsi_target_tq.h
 create mode 100644 drivers/target/iscsi/iscsi_target_util.c
 create mode 100644 drivers/target/iscsi/iscsi_target_util.h

Re: [GIT PULL] iscsi-target merge for v3.1-rc1

[Andrew Morton]

On Sat, 23 Jul 2011 16:16:15 -0700 "Nicholas A. Bellinger" <nab@linux-iscsi.org> wrote:

> So in the spirit of timely pull requests ahead of your upcoming summer
> vacation, here is the long awaited and much debated initial merge commit
> for v3.1-rc1 of drivers/target/iscsi to sync with latest bleeding edge
> LIO v4.1 codebase.

None of this is in linux-next?  How did that happen?

Re: [GIT PULL] iscsi-target merge for v3.1-rc1

[Nicholas A. Bellinger]

On Sat, 2011-07-23 at 16:33 -0700, Andrew Morton wrote:
> On Sat, 23 Jul 2011 16:16:15 -0700 "Nicholas A. Bellinger" <nab@linux-iscsi.org> wrote:
> 
> > So in the spirit of timely pull requests ahead of your upcoming summer
> > vacation, here is the long awaited and much debated initial merge commit
> > for v3.1-rc1 of drivers/target/iscsi to sync with latest bleeding edge
> > LIO v4.1 codebase.
> 
> None of this is in linux-next?  How did that happen?

I am happy to start using linux-next for target-pending.git mainline
items, but unfortuately these have yet to see direct linux-next testing
just yet..

Stephen, would you pretty please add target-pending.git/for-next into
linux-next build testing..?

Thanks,

--nab

Re: [GIT PULL] iscsi-target merge for v3.1-rc1

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1161 bytes --]

Hi Nicholas,

On Sat, 23 Jul 2011 17:19:23 -0700 "Nicholas A. Bellinger" <nab@linux-iscsi.org> wrote:
>
> On Sat, 2011-07-23 at 16:33 -0700, Andrew Morton wrote:
> > On Sat, 23 Jul 2011 16:16:15 -0700 "Nicholas A. Bellinger" <nab@linux-iscsi.org> wrote:
> > 
> > > So in the spirit of timely pull requests ahead of your upcoming summer
> > > vacation, here is the long awaited and much debated initial merge commit
> > > for v3.1-rc1 of drivers/target/iscsi to sync with latest bleeding edge
> > > LIO v4.1 codebase.
> > 
> > None of this is in linux-next?  How did that happen?
> 
> I am happy to start using linux-next for target-pending.git mainline
> items, but unfortuately these have yet to see direct linux-next testing
> just yet..
> 
> Stephen, would you pretty please add target-pending.git/for-next into
> linux-next build testing..?

Sure, just send me the url of the git tree (and branch) and I will add it
tomorrow (assuming this is stuff still destined for v3.1 - stuff for v3.2
sould wait until after v3.1-rc1).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [GIT PULL] iscsi-target merge for v3.1-rc1

[Andrew Morton]

On Sat, 23 Jul 2011 16:16:15 -0700
"Nicholas A. Bellinger" <nab@linux-iscsi.org> wrote:

> Please go ahead and pull from:
> 
>   master.kernel.org:/pub/scm/linux/kernel/git/nab/target-pending.git for-linus-merge

i386 allyesconfig:

ERROR: "__udivdi3" [drivers/target/target_core_mod.ko] undefined!

somewhere in drivers/target/target_core_transport.c:transport_allocate_data_tasks().

Re: [GIT PULL] iscsi-target merge for v3.1-rc1

[Linus Torvalds]

On Mon, Jul 25, 2011 at 4:37 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Sat, 23 Jul 2011 16:16:15 -0700
> "Nicholas A. Bellinger" <nab@linux-iscsi.org> wrote:
>
>> Please go ahead and pull from:
>>
>>   master.kernel.org:/pub/scm/linux/kernel/git/nab/target-pending.git for-linus-merge
>
> i386 allyesconfig:
>
> ERROR: "__udivdi3" [drivers/target/target_core_mod.ko] undefined!
>
> somewhere in drivers/target/target_core_transport.c:transport_allocate_data_tasks().

.. looks like somebody isn't doing a "sector_div()" for a sector_t.

Nicholas: full 64-bit divides are dog slow on most 32-bit targets, and
gcc is very iffy at doing a 64/32->32 divide (or even a 64/32->64 one,
which is still much faster than the full 64/64->64 one). So we very
much on purpose don't allow for __udivdi3 (which is gcc-speak for that
out-of-line "64/64->64" operation), so it generates link-time errors.

Note the odd semantics for sector_div():

  sector_div(a,b)

basically does a "a = a/b" (and then returns the remainder, but nobody
uses it and maybe we should skip that part).

                   Linus

Re: [GIT PULL] iscsi-target merge for v3.1-rc1

[Andrew Morton]

On Mon, 25 Jul 2011 16:46:03 -0700
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Mon, Jul 25, 2011 at 4:37 PM, Andrew Morton
> <akpm@linux-foundation.org> wrote:
> > On Sat, 23 Jul 2011 16:16:15 -0700
> > "Nicholas A. Bellinger" <nab@linux-iscsi.org> wrote:
> >
> >> Please go ahead and pull from:
> >>
> >> __ master.kernel.org:/pub/scm/linux/kernel/git/nab/target-pending.git for-linus-merge
> >
> > i386 allyesconfig:
> >
> > ERROR: "__udivdi3" [drivers/target/target_core_mod.ko] undefined!
> >
> > somewhere in drivers/target/target_core_transport.c:transport_allocate_data_tasks().
> 
> .. looks like somebody isn't doing a "sector_div()" for a sector_t.
> 

Also looks like the code isn't tested a lot on 32-bit machines.

Is that even a possible combination?

Re: [GIT PULL] iscsi-target merge for v3.1-rc1

[Andrew Morton]

On Mon, 25 Jul 2011 16:37:39 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:

> On Sat, 23 Jul 2011 16:16:15 -0700
> "Nicholas A. Bellinger" <nab@linux-iscsi.org> wrote:
> 
> > Please go ahead and pull from:
> > 
> >   master.kernel.org:/pub/scm/linux/kernel/git/nab/target-pending.git for-linus-merge
> 
> i386 allyesconfig:
> 
> ERROR: "__udivdi3" [drivers/target/target_core_mod.ko] undefined!
> 
> somewhere in drivers/target/target_core_transport.c:transport_allocate_data_tasks().

Probably the best place to fix this is within DIV_ROUND_UP(): make it
handle 64-bits on 32-bit.

This will have the pleasing side-effect of breaking
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c, which felt a need to duplicate the
existing DIV_ROUND_UP() implementation.

Re: [GIT PULL] iscsi-target merge for v3.1-rc1

[Nicholas A. Bellinger]

On Mon, 2011-07-25 at 16:50 -0700, Andrew Morton wrote:
> On Mon, 25 Jul 2011 16:37:39 -0700
> Andrew Morton <akpm@linux-foundation.org> wrote:
> 
> > On Sat, 23 Jul 2011 16:16:15 -0700
> > "Nicholas A. Bellinger" <nab@linux-iscsi.org> wrote:
> > 
> > > Please go ahead and pull from:
> > > 
> > >   master.kernel.org:/pub/scm/linux/kernel/git/nab/target-pending.git for-linus-merge
> > 
> > i386 allyesconfig:
> > 
> > ERROR: "__udivdi3" [drivers/target/target_core_mod.ko] undefined!
> > 
> > somewhere in drivers/target/target_core_transport.c:transport_allocate_data_tasks().
> 
> Probably the best place to fix this is within DIV_ROUND_UP(): make it
> handle 64-bits on 32-bit.
> 
> This will have the pleasing side-effect of breaking
> drivers/scsi/cxgbi/cxgb4i/cxgb4i.c, which felt a need to duplicate the
> existing DIV_ROUND_UP() implementation.
> 

Thanks for the input everyone.  :)

How about the following to add a new DIV_ROUND_UP_ULL macro, and enable
it's usage within the offending transport_allocate_data_tasks() change
causing the regression in question for target_core_mod..?

Is there anything else that should be done to avoid unnecessary 64-bit
divide instruction slowness for generic 32-bit arch operation here..?

Thank you,

--nab

diff --git a/drivers/target/target_core_transport.c b/drivers/target/target_core_transport.c
index a244c90..8032e1e 100644
--- a/drivers/target/target_core_transport.c
+++ b/drivers/target/target_core_transport.c
@@ -4054,17 +4054,16 @@ static int transport_allocate_data_tasks(
        struct se_task *task;
        struct se_device *dev = cmd->se_dev;
        unsigned long flags;
-       sector_t sectors;
        int task_count, i, ret;
-       sector_t dev_max_sectors = dev->se_sub_dev->se_dev_attrib.max_sectors;
+       sector_t sectors, dev_max_sectors = dev->se_sub_dev->se_dev_attrib.max_sectors;
        u32 sector_size = dev->se_sub_dev->se_dev_attrib.block_size;
        struct scatterlist *sg;
        struct scatterlist *cmd_sg;
 
        WARN_ON(cmd->data_length % sector_size);
        sectors = DIV_ROUND_UP(cmd->data_length, sector_size);
-       task_count = DIV_ROUND_UP(sectors, dev_max_sectors);
-
+       task_count = DIV_ROUND_UP_ULL(sectors, dev_max_sectors);
+       
        cmd_sg = sgl;
        for (i = 0; i < task_count; i++) {
                unsigned int task_size;
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 953352a..d66cba7 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -56,6 +56,17 @@
 
 #define FIELD_SIZEOF(t, f) (sizeof(((t*)0)->f))
 #define DIV_ROUND_UP(n,d) (((n) + (d) - 1) / (d))
+#define DIV_ROUND_UP_ULL(n,d) (                                \
+{                                                      \
+       unsigned long long _tmp = n, _off;              \
+       int _res;                                       \
+       /* Round up using asm/div64.h:do_div */         \
+       _off = do_div(_tmp, d);                         \
+       if (_off != 0)                                  \
+               _tmp++;                                 \
+       _res = _tmp;                                    \
+}                                                      \
+)
 
 /* The `const' in roundup() prevents gcc-3.3 from calling __divdi3 */
 #define roundup(x, y) (                                        \

Re: [GIT PULL] iscsi-target merge for v3.1-rc1

[Linus Torvalds]

On Mon, Jul 25, 2011 at 11:51 PM, Nicholas A. Bellinger
<nab@linux-iscsi.org> wrote:
>
> How about the following to add a new DIV_ROUND_UP_ULL macro

Hmm.

>  #define DIV_ROUND_UP(n,d) (((n) + (d) - 1) / (d))
> +#define DIV_ROUND_UP_ULL(n,d) (                                \
> +{                                                      \
> +       unsigned long long _tmp = n, _off;              \
> +       int _res;                                       \
> +       /* Round up using asm/div64.h:do_div */         \
> +       _off = do_div(_tmp, d);                         \
> +       if (_off != 0)                                  \
> +               _tmp++;                                 \
> +       _res = _tmp;                                    \
> +}                                                      \
> +)

That looks buggy. Why the "_res = _tmp" there? All that does is to
truncate the result to "int", which looks bogus.

And it just looks unnecessarily complicated. Just a simple

#define DIV_ROUND_UP_ULL(ll,d) \
  ({ unsigned long long _tmp = (ll)+(d)-1; do_div(_tmp, d); _tmp; })

looks like it would work and be simpler. Avoid the conditional, do the
same "add 'd-1' thing as the regular ROUND_UP().

Untested. And not much thinking involved.

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

Re: [GIT PULL] iscsi-target merge for v3.1-rc1

[Nicholas A. Bellinger]

On Tue, 2011-07-26 at 00:09 -0700, Linus Torvalds wrote:
> On Mon, Jul 25, 2011 at 11:51 PM, Nicholas A. Bellinger
> <nab@linux-iscsi.org> wrote:
> >
> > How about the following to add a new DIV_ROUND_UP_ULL macro
> 
> Hmm.
> 
> >  #define DIV_ROUND_UP(n,d) (((n) + (d) - 1) / (d))
> > +#define DIV_ROUND_UP_ULL(n,d) (                                \
> > +{                                                      \
> > +       unsigned long long _tmp = n, _off;              \
> > +       int _res;                                       \
> > +       /* Round up using asm/div64.h:do_div */         \
> > +       _off = do_div(_tmp, d);                         \
> > +       if (_off != 0)                                  \
> > +               _tmp++;                                 \
> > +       _res = _tmp;                                    \
> > +}                                                      \
> > +)
> 
> That looks buggy. Why the "_res = _tmp" there? All that does is to
> truncate the result to "int", which looks bogus.
> 
> And it just looks unnecessarily complicated. Just a simple
> 
> #define DIV_ROUND_UP_ULL(ll,d) \
>   ({ unsigned long long _tmp = (ll)+(d)-1; do_div(_tmp, d); _tmp; })
> 
> looks like it would work and be simpler. Avoid the conditional, do the
> same "add 'd-1' thing as the regular ROUND_UP().
> 
> Untested. And not much thinking involved.
> 

Fixing this up in lio-core-2.6.git now and pushing out into
target-pending.git/for-next now unless you have any other concerns.

Thank you,

--nab

Re: [GIT PULL] iscsi-target merge for v3.1-rc1

[Andrew Morton]

On Tue, 26 Jul 2011 00:09:40 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote:

> Just a simple
> 
> #define DIV_ROUND_UP_ULL(ll,d) \
>   ({ unsigned long long _tmp = (ll)+(d)-1; do_div(_tmp, d); _tmp; })
> 
> looks like it would work and be simpler. Avoid the conditional, do the
> same "add 'd-1' thing as the regular ROUND_UP().
> 

We might end up needing a DIV_ROUND_UP_SECTOR_T because that guy's
type/size is Kconfigurable.

otoh DIV_ROUND_UP_ULL won't have many callsites - the occasional
conversion from UL to ULL then back to UL wouldn't kill us.  Unless
there be subtle problems with such a conversion.

Re: [GIT PULL] iscsi-target merge for v3.1-rc1

[Nicholas A. Bellinger]

On Tue, 2011-07-26 at 00:43 -0700, Andrew Morton wrote:
> On Tue, 26 Jul 2011 00:09:40 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote:
> 
> > Just a simple
> > 
> > #define DIV_ROUND_UP_ULL(ll,d) \
> >   ({ unsigned long long _tmp = (ll)+(d)-1; do_div(_tmp, d); _tmp; })
> > 
> > looks like it would work and be simpler. Avoid the conditional, do the
> > same "add 'd-1' thing as the regular ROUND_UP().
> > 
> 
> We might end up needing a DIV_ROUND_UP_SECTOR_T because that guy's
> type/size is Kconfigurable.
> 
> otoh DIV_ROUND_UP_ULL won't have many callsites - the occasional
> conversion from UL to ULL then back to UL wouldn't kill us.  Unless
> there be subtle problems with such a conversion.
> 

Makes sense to me, and sending out updated series..  Anything else to
consider here folks before pushing into target-pending.git/for-next..?

Thanks!

--nab

Re: [GIT PULL] iscsi-target merge for v3.1-rc1

[Olivier Galibert]

On Tue, Jul 26, 2011 at 12:09:40AM -0700, Linus Torvalds wrote:
> And it just looks unnecessarily complicated. Just a simple
> 
> #define DIV_ROUND_UP_ULL(ll,d) \
>   ({ unsigned long long _tmp = (ll)+(d)-1; do_div(_tmp, d); _tmp; })
> 
> looks like it would work and be simpler. Avoid the conditional, do the
> same "add 'd-1' thing as the regular ROUND_UP().
> 
> Untested. And not much thinking involved.

Overflow risk?  Of course DIV_ROUND_UP has the same issue, and looks
slight easier to trigger, maybe.

  OG.

Re: [GIT PULL] iscsi-target merge for v3.1-rc1

[Alexey Dobriyan]

On Tue, Jul 26, 2011 at 1:08 PM, Olivier Galibert <galibert@pobox.com> wrote:
> On Tue, Jul 26, 2011 at 12:09:40AM -0700, Linus Torvalds wrote:
>> And it just looks unnecessarily complicated. Just a simple
>>
>> #define DIV_ROUND_UP_ULL(ll,d) \
>>   ({ unsigned long long _tmp = (ll)+(d)-1; do_div(_tmp, d); _tmp; })
>>
>> looks like it would work and be simpler. Avoid the conditional, do the
>> same "add 'd-1' thing as the regular ROUND_UP().
>>
>> Untested. And not much thinking involved.
>
> Overflow risk?  Of course DIV_ROUND_UP has the same issue, and looks
> slight easier to trigger, maybe.

Can we please make DIV_ROUND_UP to demultiplex based on argument type inside?
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] iscsi-target merge for v3.1-rc1

[Nicholas A. Bellinger]

On Mon, 2011-07-25 at 16:37 -0700, Andrew Morton wrote:
> On Sat, 23 Jul 2011 16:16:15 -0700
> "Nicholas A. Bellinger" <nab@linux-iscsi.org> wrote:
> 
> > Please go ahead and pull from:
> > 
> >   master.kernel.org:/pub/scm/linux/kernel/git/nab/target-pending.git for-linus-merge
> 
> i386 allyesconfig:
> 
> ERROR: "__udivdi3" [drivers/target/target_core_mod.ko] undefined!
> 
> somewhere in drivers/target/target_core_transport.c:transport_allocate_data_tasks().

Mmmm, I was under the assumption that DIV_ROUND_UP() did unsigned long
long division correctly for sector_t on 32-bit , but apparently not with
the new v4.1 transport_allocate_data_tasks() code..   Andy..?  

Once upon a time we used the following __udivdi3() and __umoddi3()
wrappers around do_div() to handle this instruction in target_core_mod
for 32-bit, but we ended up removing these during the .38 merge in favor
of IIRC direct do_div() usage.  These wrappers are still in use for LIO
backports on 32-bit x86 and arm however..

So I'll go ahead and make sure this works on i386 with lio-core-2.6.git
shortly, and double check __udivdi3() usage with iscsi-target in
for-next.  Andrew and Christoph, did have any input on a preffered
method of handling this case in the new v4.1 DIV_ROUND_UP() usage..?

Thank you!

--nab

Re: [GIT PULL] iscsi-target merge for v3.1-rc1

[Andy Grover]

On 07/25/2011 05:32 PM, Nicholas A. Bellinger wrote:
> On Mon, 2011-07-25 at 16:37 -0700, Andrew Morton wrote:
>> On Sat, 23 Jul 2011 16:16:15 -0700
>> "Nicholas A. Bellinger" <nab@linux-iscsi.org> wrote:
>>
>>> Please go ahead and pull from:
>>>
>>>   master.kernel.org:/pub/scm/linux/kernel/git/nab/target-pending.git for-linus-merge
>>
>> i386 allyesconfig:
>>
>> ERROR: "__udivdi3" [drivers/target/target_core_mod.ko] undefined!
>>
>> somewhere in drivers/target/target_core_transport.c:transport_allocate_data_tasks().
> 
> Mmmm, I was under the assumption that DIV_ROUND_UP() did unsigned long
> long division correctly for sector_t on 32-bit , but apparently not with
> the new v4.1 transport_allocate_data_tasks() code..   Andy..?  

sectors = DIV_ROUND_UP(cmd->data_length, sector_size);
task_count = DIV_ROUND_UP(sectors, dev_max_sectors);

sectors is a sector_t but the value will never be >32bits, since
data_length is u32.

We could just cast sectors to a u32 and be ok for this particular
usage... DIV_ROUND_UP handling 64bit would of course also resolve the
issue nicely.

Regards -- Andy