[Cluster-devel] [PATCH] dlm: remove BUG() before panic()

2020-05-07 Thread Arnd Bergmann 
Building a kernel with clang sometimes fails with an objtool error in dlm:

fs/dlm/lock.o: warning: objtool: revert_lock_pc()+0xbd: can't find jump dest 
instruction at .text+0xd7fc

The problem is that BUG() never returns and the compiler knows
that anything after it is unreachable, however the panic still
emits some code that does not get fully eliminated.

Having both BUG() and panic() is really pointless as the BUG()
kills the current process and the subsequent panic() never hits.
In most cases, we probably don't really want either and should
replace the DLM_ASSERT() statements with WARN_ON(), as has
been done for some of them.

Remove the BUG() here so the user at least sees the panic message
and we can reliably build randconfig kernels.

Fixes: e7fd41792fc0 ("[DLM] The core of the DLM for GFS2/CLVM")
Cc: Josh Poimboeuf 
Cc: clang-built-li...@googlegroups.com
Signed-off-by: Arnd Bergmann 
---
 fs/dlm/dlm_internal.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/fs/dlm/dlm_internal.h b/fs/dlm/dlm_internal.h
index 416d9de35679..4311d01b02a8 100644
--- a/fs/dlm/dlm_internal.h
+++ b/fs/dlm/dlm_internal.h
@@ -97,7 +97,6 @@ do { \
__LINE__, __FILE__, #x, jiffies); \
 {do} \
 printk("\n"); \
-BUG(); \
 panic("DLM:  Record message above and reboot.\n"); \
   } \
 }
-- 
2.26.0

[Cluster-devel] [PATCH v2 00/24] drivers, fs: y2038 updates

2019-12-13 Thread Arnd Bergmann 
These are updates to devidce drivers and file systems that for some
reason or another were not included in the kernel in the previous
y2038 series.

I've gone through all users of time_t again to make sure the
kernel is in a long-term maintainable state.

Posting these as a series for better organization, but each change
here is applicable standalone.

Please merge, review, ack/nack etc as you see fit. I will
add these to my y2038 branch [1] for linux-next, but can keep
rebasing for feedback and to remove any patches that get
picked up by a maintainer.

Changes since v1 [2]:

- Add Acks I received
- Rebase to v5.5-rc1, droping patches that got merged already
- Add NFS, XFS and the final three patches from another series
- Rewrite etnaviv patches

  Arnd

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/log/?h=y2038
[2] https://lore.kernel.org/lkml/20191108213257.3097633-1-a...@arndb.de/

Arnd Bergmann (24):
  Input: input_event: fix struct padding on sparc64
  fat: use prandom_u32() for i_generation
  dlm: use SO_SNDTIMEO_NEW instead of SO_SNDTIMEO_OLD
  xtensa: ISS: avoid struct timeval
  um: ubd: use 64-bit time_t where possible
  acct: stop using get_seconds()
  tsacct: add 64-bit btime field
  packet: clarify timestamp overflow
  quota: avoid time_t in v1_disk_dqblk definition
  hostfs: pass 64-bit timestamps to/from user space
  hfs/hfsplus: use 64-bit inode timestamps
  drm/msm: avoid using 'timespec'
  drm/etnaviv: reject timeouts with tv_nsec >= NSEC_PER_SEC
  drm/etnaviv: avoid deprecated timespec
  sunrpc: convert to time64_t for expiry
  nfs: use time64_t internally
  nfs: fix timstamp debug prints
  nfs: fscache: use timespec64 in inode auxdata
  xfs: rename compat_time_t to old_time32_t
  xfs: disallow broken ioctls without compat-32-bit-time
  xfs: quota: move to time64_t interfaces
  y2038: remove obsolete jiffies conversion functions
  y2038: rename itimerval to __kernel_old_itimerval
  y2038: sparc: remove use of struct timex

 arch/sparc/kernel/sys_sparc_64.c  | 29 +-
 arch/um/drivers/cow.h |  2 +-
 arch/um/drivers/cow_user.c|  7 ++-
 arch/um/drivers/ubd_kern.c| 10 ++--
 arch/um/include/shared/os.h   |  2 +-
 arch/um/os-Linux/file.c   |  2 +-
 .../platforms/iss/include/platform/simcall.h  |  4 +-
 drivers/gpu/drm/etnaviv/etnaviv_drv.c | 20 ---
 drivers/gpu/drm/etnaviv/etnaviv_drv.h | 11 ++--
 drivers/gpu/drm/etnaviv/etnaviv_gem.c |  4 +-
 drivers/gpu/drm/etnaviv/etnaviv_gem.h |  2 +-
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c |  5 +-
 drivers/gpu/drm/etnaviv/etnaviv_gpu.h |  5 +-
 drivers/gpu/drm/msm/msm_drv.h |  3 +-
 drivers/input/evdev.c | 14 ++---
 drivers/input/misc/uinput.c   | 14 +++--
 fs/dlm/lowcomms.c |  6 +-
 fs/fat/inode.c|  3 +-
 fs/hfs/hfs_fs.h   | 28 +++--
 fs/hfs/inode.c|  4 +-
 fs/hfsplus/hfsplus_fs.h   | 28 +++--
 fs/hfsplus/inode.c| 12 ++--
 fs/hostfs/hostfs.h| 22 ---
 fs/hostfs/hostfs_kern.c   | 15 +++--
 fs/nfs/fscache-index.c|  6 +-
 fs/nfs/fscache.c  | 18 --
 fs/nfs/fscache.h  |  8 ++-
 fs/nfs/nfs4xdr.c  | 10 ++--
 fs/quota/quotaio_v1.h |  6 +-
 fs/xfs/xfs_dquot.c|  6 +-
 fs/xfs/xfs_ioctl.c| 26 +
 fs/xfs/xfs_ioctl32.c  |  2 +-
 fs/xfs/xfs_ioctl32.h  |  2 +-
 fs/xfs/xfs_qm.h   |  6 +-
 fs/xfs/xfs_quotaops.c |  6 +-
 fs/xfs/xfs_trans_dquot.c  |  8 ++-
 include/linux/jiffies.h   | 20 ---
 include/linux/sunrpc/cache.h  | 42 --
 include/linux/sunrpc/gss_api.h|  4 +-
 include/linux/sunrpc/gss_krb5.h   |  2 +-
 include/linux/syscalls.h  |  9 ++-
 include/uapi/linux/acct.h |  2 +
 include/uapi/linux/input.h|  1 +
 include/uapi/linux/taskstats.h|  6 +-
 include/uapi/linux/time_types.h   |  5 ++
 include/uapi/linux/timex.h|  2 +
 kernel/acct.c |  4 +-
 kernel/time/itimer.c  | 18 +++---
 kernel/time/time.c| 58 ++-
 kernel/tsacct.c   |  9 ++-
 net/packet/af_packet.c| 27 +
 net/sunrpc/auth_gss/gss_krb5_mech.c   | 12 +++-
 net/sunrpc/auth_

[Cluster-devel] [PATCH v2 03/24] dlm: use SO_SNDTIMEO_NEW instead of SO_SNDTIMEO_OLD

2019-12-13 Thread Arnd Bergmann 
Eliminate one more use of 'struct timeval' from the kernel so
we can eventually remove the definition as well.

The kernel supports the new format with a 64-bit time_t version
of timeval here, so use that instead of the old timeval.

Acked-by: Deepa Dinamani 
Signed-off-by: Arnd Bergmann 
---
 fs/dlm/lowcomms.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/fs/dlm/lowcomms.c b/fs/dlm/lowcomms.c
index 3951d39b9b75..cdfaf4f0e11a 100644
--- a/fs/dlm/lowcomms.c
+++ b/fs/dlm/lowcomms.c
@@ -1035,7 +1035,7 @@ static void sctp_connect_to_sock(struct connection *con)
int result;
int addr_len;
struct socket *sock;
-   struct timeval tv = { .tv_sec = 5, .tv_usec = 0 };
+   struct __kernel_sock_timeval tv = { .tv_sec = 5, .tv_usec = 0 };
 
if (con->nodeid == 0) {
log_print("attempt to connect sock 0 foiled");
@@ -1087,12 +1087,12 @@ static void sctp_connect_to_sock(struct connection *con)
 * since O_NONBLOCK argument in connect() function does not work here,
 * then, we should restore the default value of this attribute.
 */
-   kernel_setsockopt(sock, SOL_SOCKET, SO_SNDTIMEO_OLD, (char *),
+   kernel_setsockopt(sock, SOL_SOCKET, SO_SNDTIMEO_NEW, (char *),
  sizeof(tv));
result = sock->ops->connect(sock, (struct sockaddr *), addr_len,
   0);
memset(, 0, sizeof(tv));
-   kernel_setsockopt(sock, SOL_SOCKET, SO_SNDTIMEO_OLD, (char *),
+   kernel_setsockopt(sock, SOL_SOCKET, SO_SNDTIMEO_NEW, (char *),
  sizeof(tv));
 
if (result == -EINPROGRESS)
-- 
2.20.0

[Cluster-devel] [PATCH 00/16] drivers: y2038 updates

2019-11-08 Thread Arnd Bergmann 
These are updates to devidce drivers and file systems that for some
reason or another were not included in the kernel in the previous
y2038 series.

I've gone through all users of time_t again to make sure the
kernel is in a long-term maintainable state.

Posting these as a series for better organization, but each change
here is applicable standalone.

Please merge, review, ack/nack etc as you see fit. My plan is to
include any patches that don't get a reply this time around in
a future pull request, probably for linux-5.6.

As mentioned before, the full series of 90 patches is available at
https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/log/?h=y2038-endgame

Arnd

Arnd Bergmann (16):
  staging: exfat: use prandom_u32() for i_generation
  fat: use prandom_u32() for i_generation
  net: sock: use __kernel_old_timespec instead of timespec
  dlm: use SO_SNDTIMEO_NEW instead of SO_SNDTIMEO_OLD
  xtensa: ISS: avoid struct timeval
  um: ubd: use 64-bit time_t where possible
  acct: stop using get_seconds()
  tsacct: add 64-bit btime field
  netfilter: nft_meta: use 64-bit time arithmetic
  packet: clarify timestamp overflow
  quota: avoid time_t in v1_disk_dqblk definition
  hostfs: pass 64-bit timestamps to/from user space
  hfs/hfsplus: use 64-bit inode timestamps
  drm/msm: avoid using 'timespec'
  drm/etnaviv: use ktime_t for timeouts
  firewire: ohci: stop using get_seconds() for BUS_TIME

 arch/um/drivers/cow.h |  2 +-
 arch/um/drivers/cow_user.c|  7 +++--
 arch/um/drivers/ubd_kern.c| 10 +++
 arch/um/include/shared/os.h   |  2 +-
 arch/um/os-Linux/file.c   |  2 +-
 .../platforms/iss/include/platform/simcall.h  |  4 +--
 drivers/firewire/ohci.c   |  2 +-
 drivers/gpu/drm/etnaviv/etnaviv_drv.c | 19 ++---
 drivers/gpu/drm/etnaviv/etnaviv_drv.h | 21 ++
 drivers/gpu/drm/etnaviv/etnaviv_gem.c |  5 ++--
 drivers/gpu/drm/etnaviv/etnaviv_gem.h |  2 +-
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c |  4 +--
 drivers/gpu/drm/etnaviv/etnaviv_gpu.h |  4 +--
 drivers/gpu/drm/msm/msm_drv.h |  3 +-
 drivers/staging/exfat/exfat_super.c   |  4 +--
 fs/dlm/lowcomms.c |  6 ++--
 fs/fat/inode.c|  3 +-
 fs/hfs/hfs_fs.h   | 26 +
 fs/hfs/inode.c|  4 +--
 fs/hfsplus/hfsplus_fs.h   | 26 +
 fs/hfsplus/inode.c| 12 
 fs/hostfs/hostfs.h| 22 +--
 fs/hostfs/hostfs_kern.c   | 15 ++
 fs/quota/quotaio_v1.h |  6 ++--
 include/linux/skbuff.h|  7 +++--
 include/uapi/linux/acct.h |  2 ++
 include/uapi/linux/taskstats.h|  6 +++-
 kernel/acct.c |  4 ++-
 kernel/tsacct.c   |  9 --
 net/compat.c  |  2 +-
 net/ipv4/tcp.c| 28 +++
 net/netfilter/nft_meta.c  | 10 +++
 net/packet/af_packet.c| 27 +++---
 net/socket.c  |  2 +-
 34 files changed, 184 insertions(+), 124 deletions(-)

-- 
2.20.0

Cc: jd...@addtoit.com
Cc: rich...@nod.at
Cc: jcmvb...@gmail.com
Cc: stef...@s5r6.in-berlin.de
Cc: l.st...@pengutronix.de
Cc: linux+etna...@armlinux.org.uk
Cc: christian.gmei...@gmail.com
Cc: airl...@linux.ie
Cc: dan...@ffwll.ch
Cc: robdcl...@gmail.com
Cc: s...@poorly.run
Cc: valdis.kletni...@vt.edu
Cc: gre...@linuxfoundation.org
Cc: ccaul...@redhat.com
Cc: teigl...@redhat.com
Cc: hirof...@mail.parknet.co.jp
Cc: j...@suse.com
Cc: da...@davemloft.net
Cc: eduma...@google.com
Cc: pa...@netfilter.org
Cc: kad...@netfilter.org
Cc: f...@strlen.de
Cc: will...@google.com
Cc: v...@zeniv.linux.org.uk
Cc: rfont...@redhat.com
Cc: t...@linutronix.de
Cc: linux...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Cc: linux1394-de...@lists.sourceforge.net
Cc: etna...@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org>
Cc: linux-arm-...@vger.kernel.org>
Cc: freedr...@lists.freedesktop.org>
Cc: de...@driverdev.osuosl.org>
Cc: cluster-devel@redhat.com>
Cc: linux-fsde...@vger.kernel.org>
Cc: net...@vger.kernel.org>
Cc: netfilter-de...@vger.kernel.org>
Cc: coret...@netfilter.org>

[Cluster-devel] [PATCH 04/16] dlm: use SO_SNDTIMEO_NEW instead of SO_SNDTIMEO_OLD

2019-11-08 Thread Arnd Bergmann 
Eliminate one more use of 'struct timeval' from the kernel so
we can eventually remove the definition as well.

The kernel supports the new format with a 64-bit time_t version
of timeval here, so use that instead of the old timeval.

Signed-off-by: Arnd Bergmann 
---
 fs/dlm/lowcomms.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/fs/dlm/lowcomms.c b/fs/dlm/lowcomms.c
index 3951d39b9b75..cdfaf4f0e11a 100644
--- a/fs/dlm/lowcomms.c
+++ b/fs/dlm/lowcomms.c
@@ -1035,7 +1035,7 @@ static void sctp_connect_to_sock(struct connection *con)
int result;
int addr_len;
struct socket *sock;
-   struct timeval tv = { .tv_sec = 5, .tv_usec = 0 };
+   struct __kernel_sock_timeval tv = { .tv_sec = 5, .tv_usec = 0 };
 
if (con->nodeid == 0) {
log_print("attempt to connect sock 0 foiled");
@@ -1087,12 +1087,12 @@ static void sctp_connect_to_sock(struct connection *con)
 * since O_NONBLOCK argument in connect() function does not work here,
 * then, we should restore the default value of this attribute.
 */
-   kernel_setsockopt(sock, SOL_SOCKET, SO_SNDTIMEO_OLD, (char *),
+   kernel_setsockopt(sock, SOL_SOCKET, SO_SNDTIMEO_NEW, (char *),
  sizeof(tv));
result = sock->ops->connect(sock, (struct sockaddr *), addr_len,
   0);
memset(, 0, sizeof(tv));
-   kernel_setsockopt(sock, SOL_SOCKET, SO_SNDTIMEO_OLD, (char *),
+   kernel_setsockopt(sock, SOL_SOCKET, SO_SNDTIMEO_NEW, (char *),
  sizeof(tv));
 
if (result == -EINPROGRESS)
-- 
2.20.0

Re: [PATCH v5 03/18] gfs2: add compat_ioctl support

2019-08-19 Thread Arnd Bergmann 
On Sun, Aug 18, 2019 at 10:17 PM Andreas Grünbacher
 wrote:
> Am So., 18. Aug. 2019 um 21:32 Uhr schrieb Arnd Bergmann :
> > On Fri, Aug 16, 2019 at 7:32 PM Andreas Gruenbacher  
> > wrote:
> > > On Wed, Aug 14, 2019 at 10:45 PM Arnd Bergmann  wrote:
> > > > +   /* These are just misnamed, they actually get/put from/to user 
> > > > an int */
> > > > +   switch(cmd) {
> > > > +   case FS_IOC32_GETFLAGS:
> > > > +   cmd = FS_IOC_GETFLAGS;
> > > > +   break;
> > > > +   case FS_IOC32_SETFLAGS:
> > > > +   cmd = FS_IOC_SETFLAGS;
> > > > +   break;
> > >
> > > I'd like the code to be more explicit here:
> > >
> > > case FITRIM:
> > > case FS_IOC_GETFSLABEL:
> > >   break;
> > > default:
> > >   return -ENOIOCTLCMD;
> >
> > I've looked at it again: if we do this, the function actually becomes
> > longer than the native gfs2_ioctl(). Should we just make a full copy then?
>
> I don't think the length of gfs2_compat_ioctl is really an issue as
> long as the function is that simple.

True. The most important goal should just be to make it easy to
add the correct handler the next time another command is added
to the ioctl function.

Just let me know which version you want for that:

1. my original patch
2. the version from your reply
3. my version below with compat_ptr() added
4. ...

> > static long gfs2_compat_ioctl(struct file *filp, unsigned int cmd,
> > unsigned long arg)
> > {
> > switch(cmd) {
> > case FS_IOC32_GETFLAGS:
> > return gfs2_get_flags(filp, (u32 __user *)arg);
> > case FS_IOC32_SETFLAGS:
> > return gfs2_set_flags(filp, (u32 __user *)arg);
> > case FITRIM:
> > return gfs2_fitrim(filp, (void __user *)arg);
> > case FS_IOC_GETFSLABEL:
> > return gfs2_getlabel(filp, (char __user *)arg);
> > }
> >
> > return -ENOTTY;
> > }
>
> Don't we still need the compat_ptr conversion? That seems to be the
> main point of having a compat_ioctl operation.

Right, of course. Fixed now in my tree.

 Arnd

Re: [PATCH v5 03/18] gfs2: add compat_ioctl support

2019-08-18 Thread Arnd Bergmann 
On Fri, Aug 16, 2019 at 7:32 PM Andreas Gruenbacher  wrote:
>
> On Wed, Aug 14, 2019 at 10:45 PM Arnd Bergmann  wrote:
> > +   /* These are just misnamed, they actually get/put from/to user an 
> > int */
> > +   switch(cmd) {
> > +   case FS_IOC32_GETFLAGS:
> > +   cmd = FS_IOC_GETFLAGS;
> > +   break;
> > +   case FS_IOC32_SETFLAGS:
> > +   cmd = FS_IOC_SETFLAGS;
> > +   break;
>
> I'd like the code to be more explicit here:
>
> case FITRIM:
> case FS_IOC_GETFSLABEL:
>   break;
> default:
>   return -ENOIOCTLCMD;

I've looked at it again: if we do this, the function actually becomes
longer than
the native gfs2_ioctl(). Should we just make a full copy then?

static long gfs2_compat_ioctl(struct file *filp, unsigned int cmd,
unsigned long arg)
{
switch(cmd) {
case FS_IOC32_GETFLAGS:
return gfs2_get_flags(filp, (u32 __user *)arg);
case FS_IOC32_SETFLAGS:
return gfs2_set_flags(filp, (u32 __user *)arg);
case FITRIM:
return gfs2_fitrim(filp, (void __user *)arg);
case FS_IOC_GETFSLABEL:
return gfs2_getlabel(filp, (char __user *)arg);
}

return -ENOTTY;
}

> Should we feed this through the gfs2 tree?

A later patch that removes the FITRIM handling from fs/compat_ioctl.c
depends on it, so I'd like to keep everything together.

 Arnd

[Cluster-devel] [PATCH v5 00/18] compat_ioctl.c removal, part 2/3

2019-08-14 Thread Arnd Bergmann 
This is a follow-up to part 1/3 that I posted after -rc2.
I hope these are still largely uncontroversial changes, and
I would like to get them into linux-5.4.

Part 1 was in

https://lore.kernel.org/lkml/capcyv4i_nhzv155rcgnaq189aq2lfd2g8pa1d5nbzqo9e_u...@mail.gmail.com/

Part 3 will be one kernel release after part 2 is merged,
as that still needs a little extra work.

The entire series is available at

git://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git compat_ioctl

  Arnd

Al Viro (2):
  compat_ioctl: unify copy-in of ppp filters
  compat_ioctl: move PPPIOCSCOMPRESS to ppp_generic

Arnd Bergmann (16):
  xfs: compat_ioctl: use compat_ptr()
  xfs: compat_ioctl: add missing conversions
  gfs2: add compat_ioctl support
  fs: compat_ioctl: move FITRIM emulation into file systems
  watchdog: cpwd: use generic compat_ptr_ioctl
  compat_ioctl: move WDIOC handling into wdt drivers
  compat_ioctl: reimplement SG_IO handling
  af_unix: add compat_ioctl support
  compat_ioctl: handle SIOCOUTQNSD
  compat_ioctl: move SIOCOUTQ out of compat_ioctl.c
  tty: handle compat PPP ioctls
  compat_ioctl: handle PPPIOCGIDLE for 64-bit time_t
  compat_ioctl: ppp: move simple commands into ppp_generic.c
  compat_ioctl: move SG_GET_REQUEST_TABLE handling
  pktcdvd: add compat_ioctl handler
  scsi: sd: enable compat ioctls for sed-opal

 Documentation/networking/ppp_generic.txt  |   2 +
 arch/powerpc/platforms/52xx/mpc52xx_gpt.c |   1 +
 arch/um/drivers/harddog_kern.c|   1 +
 block/scsi_ioctl.c| 132 -
 drivers/block/pktcdvd.c   |  25 ++
 drivers/char/ipmi/ipmi_watchdog.c |   1 +
 drivers/hwmon/fschmd.c|   1 +
 drivers/net/ppp/ppp_generic.c | 245 ++-
 drivers/rtc/rtc-ds1374.c  |   1 +
 drivers/scsi/sd.c |  14 +-
 drivers/scsi/sg.c |  59 +++-
 drivers/tty/tty_io.c  |   5 +
 drivers/watchdog/acquirewdt.c |   1 +
 drivers/watchdog/advantechwdt.c   |   1 +
 drivers/watchdog/alim1535_wdt.c   |   1 +
 drivers/watchdog/alim7101_wdt.c   |   1 +
 drivers/watchdog/ar7_wdt.c|   1 +
 drivers/watchdog/at91rm9200_wdt.c |   1 +
 drivers/watchdog/ath79_wdt.c  |   1 +
 drivers/watchdog/bcm63xx_wdt.c|   1 +
 drivers/watchdog/cpu5wdt.c|   1 +
 drivers/watchdog/cpwd.c   |  25 +-
 drivers/watchdog/eurotechwdt.c|   1 +
 drivers/watchdog/f71808e_wdt.c|   1 +
 drivers/watchdog/gef_wdt.c|   1 +
 drivers/watchdog/geodewdt.c   |   1 +
 drivers/watchdog/ib700wdt.c   |   1 +
 drivers/watchdog/ibmasr.c |   1 +
 drivers/watchdog/indydog.c|   1 +
 drivers/watchdog/intel_scu_watchdog.c |   1 +
 drivers/watchdog/iop_wdt.c|   1 +
 drivers/watchdog/it8712f_wdt.c|   1 +
 drivers/watchdog/ixp4xx_wdt.c |   1 +
 drivers/watchdog/ks8695_wdt.c |   1 +
 drivers/watchdog/m54xx_wdt.c  |   1 +
 drivers/watchdog/machzwd.c|   1 +
 drivers/watchdog/mixcomwd.c   |   1 +
 drivers/watchdog/mtx-1_wdt.c  |   1 +
 drivers/watchdog/mv64x60_wdt.c|   1 +
 drivers/watchdog/nuc900_wdt.c |   1 +
 drivers/watchdog/nv_tco.c |   1 +
 drivers/watchdog/pc87413_wdt.c|   1 +
 drivers/watchdog/pcwd.c   |   1 +
 drivers/watchdog/pcwd_pci.c   |   1 +
 drivers/watchdog/pcwd_usb.c   |   1 +
 drivers/watchdog/pika_wdt.c   |   1 +
 drivers/watchdog/pnx833x_wdt.c|   1 +
 drivers/watchdog/rc32434_wdt.c|   1 +
 drivers/watchdog/rdc321x_wdt.c|   1 +
 drivers/watchdog/riowd.c  |   1 +
 drivers/watchdog/sa1100_wdt.c |   1 +
 drivers/watchdog/sb_wdog.c|   1 +
 drivers/watchdog/sbc60xxwdt.c |   1 +
 drivers/watchdog/sbc7240_wdt.c|   1 +
 drivers/watchdog/sbc_epx_c3.c |   1 +
 drivers/watchdog/sbc_fitpc2_wdt.c |   1 +
 drivers/watchdog/sc1200wdt.c  |   1 +
 drivers/watchdog/sc520_wdt.c  |   1 +
 drivers/watchdog/sch311x_wdt.c|   1 +
 drivers/watchdog/scx200_wdt.c |   1 +
 drivers/watchdog/smsc37b787_wdt.c |   1 +
 drivers/watchdog/w83877f_wdt.c|   1 +
 drivers/watchdog/w83977f_wdt.c|   1 +
 drivers/watchdog/wafer5823wdt.c   |   1 +
 drivers/watchdog/watchdog_dev.c   |   1 +
 drivers/watchdog/wdrtas.c |   1 +
 drivers/watchdog/wdt.c|   1 +
 drivers/watchdog/wdt285.c |   1 +
 drivers/watchdog/wdt977.c |   1 +
 drivers/watchdog/wdt_pci.c|   1 +
 fs/compat_ioctl.c

[PATCH v5 03/18] gfs2: add compat_ioctl support

2019-08-14 Thread Arnd Bergmann 
Out of the four ioctl commands supported on gfs2, only FITRIM
works in compat mode.

Add a proper handler based on the ext4 implementation.

Fixes: 6ddc5c3ddf25 ("gfs2: getlabel support")
Signed-off-by: Arnd Bergmann 
---
 fs/gfs2/file.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/fs/gfs2/file.c b/fs/gfs2/file.c
index 52fa1ef8400b..49287f0b96d0 100644
--- a/fs/gfs2/file.c
+++ b/fs/gfs2/file.c
@@ -6,6 +6,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -354,6 +355,25 @@ static long gfs2_ioctl(struct file *filp, unsigned int 
cmd, unsigned long arg)
return -ENOTTY;
 }
 
+#ifdef CONFIG_COMPAT
+static long gfs2_compat_ioctl(struct file *filp, unsigned int cmd, unsigned 
long arg)
+{
+   /* These are just misnamed, they actually get/put from/to user an int */
+   switch(cmd) {
+   case FS_IOC32_GETFLAGS:
+   cmd = FS_IOC_GETFLAGS;
+   break;
+   case FS_IOC32_SETFLAGS:
+   cmd = FS_IOC_SETFLAGS;
+   break;
+   }
+
+   return gfs2_ioctl(filp, cmd, (unsigned long)compat_ptr(arg));
+}
+#else
+#define gfs2_compat_ioctl NULL
+#endif
+
 /**
  * gfs2_size_hint - Give a hint to the size of a write request
  * @filep: The struct file
@@ -1294,6 +1314,7 @@ const struct file_operations gfs2_file_fops = {
.write_iter = gfs2_file_write_iter,
.iopoll = iomap_dio_iopoll,
.unlocked_ioctl = gfs2_ioctl,
+   .compat_ioctl   = gfs2_compat_ioctl,
.mmap   = gfs2_mmap,
.open   = gfs2_open,
.release= gfs2_release,
@@ -1309,6 +1330,7 @@ const struct file_operations gfs2_file_fops = {
 const struct file_operations gfs2_dir_fops = {
.iterate_shared = gfs2_readdir,
.unlocked_ioctl = gfs2_ioctl,
+   .compat_ioctl   = gfs2_compat_ioctl,
.open   = gfs2_open,
.release= gfs2_release,
.fsync  = gfs2_fsync,
@@ -1325,6 +1347,7 @@ const struct file_operations gfs2_file_fops_nolock = {
.write_iter = gfs2_file_write_iter,
.iopoll = iomap_dio_iopoll,
.unlocked_ioctl = gfs2_ioctl,
+   .compat_ioctl   = gfs2_compat_ioctl,
.mmap   = gfs2_mmap,
.open   = gfs2_open,
.release= gfs2_release,
@@ -1338,6 +1361,7 @@ const struct file_operations gfs2_file_fops_nolock = {
 const struct file_operations gfs2_dir_fops_nolock = {
.iterate_shared = gfs2_readdir,
.unlocked_ioctl = gfs2_ioctl,
+   .compat_ioctl   = gfs2_compat_ioctl,
.open   = gfs2_open,
.release= gfs2_release,
.fsync  = gfs2_fsync,
-- 
2.20.0

[Cluster-devel] [PATCH] socket: move compat timeout handling into sock.c

2019-01-08 Thread Arnd Bergmann 
This is a cleanup to prepare for the addition of 64-bit time_t
in O_SNDTIMEO/O_RCVTIMEO. The existing compat handler seems
unnecessarily complex and error-prone, moving it all into the
main setsockopt()/getsockopt() implementation requires half
as much code and is easier to extend.

32-bit user space can now use old_timeval32 on both 32-bit
and 64-bit machines, while 64-bit code can use
__old_kernel_timeval.

Signed-off-by: Arnd Bergmann 
---
 net/compat.c| 66 +
 net/core/sock.c | 65 +++-
 2 files changed, 44 insertions(+), 87 deletions(-)

diff --git a/net/compat.c b/net/compat.c
index 959d1c51826d..ce8f6e8cdcd2 100644
--- a/net/compat.c
+++ b/net/compat.c
@@ -348,28 +348,6 @@ static int do_set_attach_filter(struct socket *sock, int 
level, int optname,
  sizeof(struct sock_fprog));
 }
 
-static int do_set_sock_timeout(struct socket *sock, int level,
-   int optname, char __user *optval, unsigned int optlen)
-{
-   struct compat_timeval __user *up = (struct compat_timeval __user 
*)optval;
-   struct timeval ktime;
-   mm_segment_t old_fs;
-   int err;
-
-   if (optlen < sizeof(*up))
-   return -EINVAL;
-   if (!access_ok(up, sizeof(*up)) ||
-   __get_user(ktime.tv_sec, >tv_sec) ||
-   __get_user(ktime.tv_usec, >tv_usec))
-   return -EFAULT;
-   old_fs = get_fs();
-   set_fs(KERNEL_DS);
-   err = sock_setsockopt(sock, level, optname, (char *), 
sizeof(ktime));
-   set_fs(old_fs);
-
-   return err;
-}
-
 static int compat_sock_setsockopt(struct socket *sock, int level, int optname,
char __user *optval, unsigned int optlen)
 {
@@ -377,10 +355,6 @@ static int compat_sock_setsockopt(struct socket *sock, int 
level, int optname,
optname == SO_ATTACH_REUSEPORT_CBPF)
return do_set_attach_filter(sock, level, optname,
optval, optlen);
-   if (!COMPAT_USE_64BIT_TIME &&
-   (optname == SO_RCVTIMEO || optname == SO_SNDTIMEO))
-   return do_set_sock_timeout(sock, level, optname, optval, 
optlen);
-
return sock_setsockopt(sock, level, optname, optval, optlen);
 }
 
@@ -417,44 +391,6 @@ COMPAT_SYSCALL_DEFINE5(setsockopt, int, fd, int, level, 
int, optname,
return __compat_sys_setsockopt(fd, level, optname, optval, optlen);
 }
 
-static int do_get_sock_timeout(struct socket *sock, int level, int optname,
-   char __user *optval, int __user *optlen)
-{
-   struct compat_timeval __user *up;
-   struct timeval ktime;
-   mm_segment_t old_fs;
-   int len, err;
-
-   up = (struct compat_timeval __user *) optval;
-   if (get_user(len, optlen))
-   return -EFAULT;
-   if (len < sizeof(*up))
-   return -EINVAL;
-   len = sizeof(ktime);
-   old_fs = get_fs();
-   set_fs(KERNEL_DS);
-   err = sock_getsockopt(sock, level, optname, (char *) , );
-   set_fs(old_fs);
-
-   if (!err) {
-   if (put_user(sizeof(*up), optlen) ||
-   !access_ok(up, sizeof(*up)) ||
-   __put_user(ktime.tv_sec, >tv_sec) ||
-   __put_user(ktime.tv_usec, >tv_usec))
-   err = -EFAULT;
-   }
-   return err;
-}
-
-static int compat_sock_getsockopt(struct socket *sock, int level, int optname,
-   char __user *optval, int __user *optlen)
-{
-   if (!COMPAT_USE_64BIT_TIME &&
-   (optname == SO_RCVTIMEO || optname == SO_SNDTIMEO))
-   return do_get_sock_timeout(sock, level, optname, optval, 
optlen);
-   return sock_getsockopt(sock, level, optname, optval, optlen);
-}
-
 int compat_sock_get_timestamp(struct sock *sk, struct timeval __user 
*userstamp)
 {
struct compat_timeval __user *ctv;
@@ -527,7 +463,7 @@ static int __compat_sys_getsockopt(int fd, int level, int 
optname,
}
 
if (level == SOL_SOCKET)
-   err = compat_sock_getsockopt(sock, level,
+   err = sock_getsockopt(sock, level,
optname, optval, optlen);
else if (sock->ops->compat_getsockopt)
err = sock->ops->compat_getsockopt(sock, level,
diff --git a/net/core/sock.c b/net/core/sock.c
index 6aa2e7e0b4fb..e50b9a2abc92 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -335,14 +335,48 @@ int __sk_backlog_rcv(struct sock *sk, struct sk_buff *skb)
 }
 EXPORT_SYMBOL(__sk_backlog_rcv);
 
+static int sock_get_timeout(long timeo, void *optval)
+{
+   struct __kernel_old_timeval tv;
+
+   if (timeo == MAX_SCHEDULE_TIMEOUT) {
+   tv.tv_sec = 0;
+   tv.tv_usec = 0;
+   }

Re: [Cluster-devel] [PATCH 2/3] socket: Rename SO_RCVTIMEO/ SO_SNDTIMEO with _OLD suffixes

2019-01-08 Thread Arnd Bergmann 
On Tue, Jan 8, 2019 at 6:24 AM Deepa Dinamani  wrote:
>
> SO_RCVTIMEO and SO_SNDTIMEO socket options use struct timeval
> as the time format. struct timeval is not y2038 safe.
> The subsequent patches in the series add support for new socket
> timeout options with _NEW suffix that are y2038 safe.
> Rename the existing options with _OLD suffix forms so that the
> right option is enabled for userspace applications according
> to the architecture and time_t definition of libc.
>
> Signed-off-by: Deepa Dinamani 

Looks good overall. A few minor concerns:

The description above makes it sound like there is a bug with y2038-safety
in this particular interface, which I think is just not what you meant,
as the change is only needed for compatiblity with new C libraries
that work around the y2038 problem in general by changing their
timeval definition.

> diff --git a/fs/dlm/lowcomms.c b/fs/dlm/lowcomms.c
> index 76976d6e50f9..c98ad9777ad9 100644
> --- a/fs/dlm/lowcomms.c
> +++ b/fs/dlm/lowcomms.c
> @@ -1089,12 +1089,12 @@ static void sctp_connect_to_sock(struct connection 
> *con)
>  * since O_NONBLOCK argument in connect() function does not work here,
>  * then, we should restore the default value of this attribute.
>  */
> -   kernel_setsockopt(sock, SOL_SOCKET, SO_SNDTIMEO, (char *),
> +   kernel_setsockopt(sock, SOL_SOCKET, SO_SNDTIMEO_OLD, (char *),
>   sizeof(tv));
> result = sock->ops->connect(sock, (struct sockaddr *), addr_len,
>0);
> memset(, 0, sizeof(tv));
> -   kernel_setsockopt(sock, SOL_SOCKET, SO_SNDTIMEO, (char *),
> +   kernel_setsockopt(sock, SOL_SOCKET, SO_SNDTIMEO_OLD, (char *),
>   sizeof(tv));
>
> if (result == -EINPROGRESS)

It took me a bit to realize there that this is safe as well even if
we don't use SO_SNDTIMEO_NEW, for the same reason.

> --- a/net/compat.c
> +++ b/net/compat.c
> @@ -378,7 +378,7 @@ static int compat_sock_setsockopt(struct socket *sock, 
> int level, int optname,
> return do_set_attach_filter(sock, level, optname,
> optval, optlen);
> if (!COMPAT_USE_64BIT_TIME &&
> -   (optname == SO_RCVTIMEO || optname == SO_SNDTIMEO))
> +   (optname == SO_RCVTIMEO_OLD || optname == SO_SNDTIMEO_OLD))
> return do_set_sock_timeout(sock, level, optname, optval, 
> optlen);
>
> return sock_setsockopt(sock, level, optname, optval, optlen);
> @@ -450,7 +450,7 @@ static int compat_sock_getsockopt(struct socket *sock, 
> int level, int optname,
> char __user *optval, int __user *optlen)
>  {
> if (!COMPAT_USE_64BIT_TIME &&
> -   (optname == SO_RCVTIMEO || optname == SO_SNDTIMEO))
> +   (optname == SO_RCVTIMEO_OLD || optname == SO_SNDTIMEO_OLD))
> return do_get_sock_timeout(sock, level, optname, optval, 
> optlen);
> return sock_getsockopt(sock, level, optname, optval, optlen);
>  }

I looked at the original code and noticed that it's horrible, which of course
is not your fault, but I wonder if we should just fix it now to avoid that
get_fs()/set_fs() hack, since that code mostly implements what you
also have in your patch 3 (which is done more nicely).

I'll follow up with a patch to demonstrate what I mean here. Your third
patch will then just have to add another code path so we can handle
all of old_timespec32 (for existing 32-bit user space), __kernel_old_timespec
(for sparc64) and __kernel_sock_timeval (for everything else).

   Arnd

[Cluster-devel] [PATCH] gfs2: call ktime_get_coarse_real_ts64() directly

2018-06-20 Thread Arnd Bergmann 
current_kernel_time64() is now just a deprecated wrapper around
ktime_get_coarse_real_ts64(), so let's just call that directly.

Signed-off-by: Arnd Bergmann 
---
 fs/gfs2/log.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/gfs2/log.c b/fs/gfs2/log.c
index 0248835625f1..c7b1c0f75a55 100644
--- a/fs/gfs2/log.c
+++ b/fs/gfs2/log.c
@@ -689,7 +689,7 @@ void gfs2_write_log_header(struct gfs2_sbd *sdp, struct 
gfs2_jdesc *jd,
hash = ~crc32(~0, lh, LH_V1_SIZE);
lh->lh_hash = cpu_to_be32(hash);
 
-   tv = current_kernel_time64();
+   ktime_get_coarse_real_ts64();
lh->lh_nsec = cpu_to_be32(tv.tv_nsec);
lh->lh_sec = cpu_to_be64(tv.tv_sec);
addr = gfs2_log_bmap(sdp);
-- 
2.9.0

[Cluster-devel] [PATCH] gfs2: select CONFIG_LIBCRC32C

2018-02-02 Thread Arnd Bergmann 
The new crc32c logic in gfs2_log_header_v2 causes a link
error without libcrc32c:

ERROR: "crc32c" [fs/gfs2/gfs2.ko] undefined!

While the original patch selected CONFIG_CRYPTO_CRC32C to deal
with this issue, it turned out to be the wrong symbol.

Fixes: c1696fb85d33 ("GFS2: Introduce new gfs2_log_header_v2")
Signed-off-by: Arnd Bergmann <a...@arndb.de>
---
 fs/gfs2/Kconfig | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/fs/gfs2/Kconfig b/fs/gfs2/Kconfig
index c0225d4b5435..3ed2b088dcfd 100644
--- a/fs/gfs2/Kconfig
+++ b/fs/gfs2/Kconfig
@@ -3,8 +3,7 @@ config GFS2_FS
depends on (64BIT || LBDAF)
select FS_POSIX_ACL
select CRC32
-   select CRYPTO
-   select CRYPTO_CRC32C
+   select LIBCRC32C
select QUOTACTL
select FS_IOMAP
help
-- 
2.9.0

Re: [Cluster-devel] [PATCH 04/21] fs: Replace CURRENT_TIME with current_fs_time() for inode timestamps

2016-06-10 Thread Arnd Bergmann 
On Wednesday, June 8, 2016 10:04:48 PM CEST Deepa Dinamani wrote:
> 
> Signed-off-by: Deepa Dinamani 
> Cc: Steve French 
> Cc: linux-c...@vger.kernel.org
> Cc: samba-techni...@lists.samba.org
> Cc: Joern Engel 
> Cc: Prasad Joshi 
> Cc: lo...@logfs.org
> Cc: Andrew Morton 
> Cc: Julia Lawall 
> Cc: David Howells 
> Cc: Firo Yang 
> Cc: Jaegeuk Kim 
> Cc: Changman Lee 
> ...


Hi Deepa,


Just FYI, the vger.kernel.org list server and some others
intentionally reject mails with more than 1024 characters in the
Cc header, to stop people from cross-posting to too many folks.

I realize that you merged the patch after Linus' comment about
doing things in fewer steps for the simple conversion, which is
fine, but then the patch should be obvious enough that you
don't need to Cc every single maintainer and mailing list.

I've had some cases like this, and I usually remove the people
that are less likely to reply, leaving one per subsystem.
Leaving out the cleartext names is another trick you can use
if you think that you really need to Cc more people than
allowed ;-)

Arnd

Re: [Cluster-devel] [RFC 00/32] making inode time stamps y2038 ready

2014-06-10 Thread Arnd Bergmann 
On Wednesday 04 June 2014 17:10:24 H. Peter Anvin wrote:
 On 06/04/2014 12:24 PM, Arnd Bergmann wrote:
  
  For other timekeeping stuff in the kernel, I agree that using some
  64-bit representation (nanoseconds, 32/32 unsigned seconds/nanoseconds,
  ...) has advantages, that's exactly the point I was making earlier
  against simply extending the internal time_t/timespec to 64-bit
  seconds for everything.
  
 
 How much of a performance issue is it to make time_t 64 bits, and for
 the bits there are, how hard are they to fix?

Probably very little overhead for most uses, it's more the regression
potential in the less common parts of the kernel I'm worried about.

There is a significant but not overwhelming number of uses of the
main problematic types in the kernel:

arnd@wuerfel:~/arm-soc$ git grep -wl time_t | wc
188 1885566
arnd@wuerfel:~/arm-soc$ git grep -wl timeval | wc
320 320   10353
arnd@wuerfel:~/arm-soc$ git grep -wl timespec | wc
406 406   10886

I believe we have to audit all of them anyway if we want to change
the kernel to less problematic types and introduce new user
interfaces.

IMHO this work is helped if we change the uses to a new type
as we find the problems. This lets us do the work one subsystem
at a time and avoid accidental ABI changes. I don't care much what
type that will be, and having a 96-bit type will certainly work
well in a lot of cases, but I don't see a strong reason to use
that over other types, especially when they can be more efficient.

Arnd

Re: [Cluster-devel] [RFC 00/32] making inode time stamps y2038 ready

2014-06-04 Thread Arnd Bergmann 
On Tuesday 03 June 2014, Dave Chinner wrote:
 On Tue, Jun 03, 2014 at 04:22:19PM +0200, Arnd Bergmann wrote:
  On Monday 02 June 2014 14:57:26 H. Peter Anvin wrote:
   On 06/02/2014 12:55 PM, Arnd Bergmann wrote:
  The possible uses I can see for non-ktime_t types in the kernel are:
  * inodes need 96 bit timestamps to represent the full range of values
that can be stored in a file system, you made a convincing argument
for that. Almost everything else can fit into 64 bit on a 32-bit
kernel, in theory also on a 64-bit kernel if we want that.
 
 Just ot be pedantic, inodes don't need 96 bit timestamps - some
 filesystems can *support up to* 96 bit timestamps. If the kernel
 only supports 64 bit timestamps and that's all the kernel can
 represent, then the upper bits of the 96 bit on-disk inode
 timestamps simply remain zero.

I meant the reverse: since we have file systems that can store
96-bit timestamps when using 64-bit kernels, we need to extend
32-bit kernels to have the same internal representation so we
can actually read those file systems correctly.

 If you move the filesystem between kernels with different time
 ranges, then the filesystem needs to be able to tell the kernel what
 it's supported range is.  This is where having the VFS limit the
 range of supported timestamps is important: the limit is the
 min(kernel range, filesystem range). This allows the filesystems
 to be indepenent of the kernel time representation, and the kernel
 to be independent of the physical filesystem time encoding

I agree it makes sense to let the kernel know about the limits
of the file system it accesses, but for the reverse, we're probably
better off just making the kernel representation large enough (i.e.
96 bits) so it can work with any known file system. We need another
check at the user space boundary to turn that into a value that the
user can understand, but that's another problem.

Arnd

Re: [Cluster-devel] [RFC 00/32] making inode time stamps y2038 ready

2014-06-04 Thread Arnd Bergmann 
On Monday 02 June 2014, Joseph S. Myers wrote:
 On Mon, 2 Jun 2014, Arnd Bergmann wrote:
 
  Ok. Sorry about missing linux-api, I confused it with linux-arch, which
  may not be as relevant here, except for the one question whether we
  actually want to have the new ABI on all 32-bit architectures or only
  as an opt-in for those that expect to stay around for another 24 years.
 
 For glibc I think it will make the most sense to add the support for 
 64-bit time_t across all architectures that currently have 32-bit time_t 
 (with the new interfaces having fallback support to implementation in 
 terms of the 32-bit kernel interfaces, if the 64-bit syscalls are 
 unavailable either at runtime or in the kernel headers against which glibc 
 is compiled - this fallback code will of course need to check for overflow 
 when passing a time value to the kernel, hopefully with error handling 
 consistent with whatever the kernel ends up doing when a filesystem can't 
 support a timestamp).  If some architectures don't provide the new 
 interfaces in the kernel then that will mean the fallback code in glibc 
 can't be removed until glibc support for those architectures is removed 
 (as opposed to removing it when glibc no longer supports kernels predating 
 the kernel support).

Ok, that's a good reason to just provide the new interfaces on all
architectures right away. Thanks for the insight!

Arnd

Re: [Cluster-devel] [RFC 00/32] making inode time stamps y2038 ready

2014-06-04 Thread Arnd Bergmann 
On Wednesday 04 June 2014 13:30:32 Nicolas Pitre wrote:
 On Wed, 4 Jun 2014, Arnd Bergmann wrote:
 
  On Tuesday 03 June 2014, Dave Chinner wrote:
   Just ot be pedantic, inodes don't need 96 bit timestamps - some
   filesystems can *support up to* 96 bit timestamps. If the kernel
   only supports 64 bit timestamps and that's all the kernel can
   represent, then the upper bits of the 96 bit on-disk inode
   timestamps simply remain zero.
  
  I meant the reverse: since we have file systems that can store
  96-bit timestamps when using 64-bit kernels, we need to extend
  32-bit kernels to have the same internal representation so we
  can actually read those file systems correctly.
  
   If you move the filesystem between kernels with different time
   ranges, then the filesystem needs to be able to tell the kernel what
   it's supported range is.  This is where having the VFS limit the
   range of supported timestamps is important: the limit is the
   min(kernel range, filesystem range). This allows the filesystems
   to be indepenent of the kernel time representation, and the kernel
   to be independent of the physical filesystem time encoding
  
  I agree it makes sense to let the kernel know about the limits
  of the file system it accesses, but for the reverse, we're probably
  better off just making the kernel representation large enough (i.e.
  96 bits) so it can work with any known file system.
 
 Depends...  96 bit handling may get prohibitive on 32-bit archs.
 
 The important point here is for the kernel to be able to represent the 
 time _range_ used by any known filesystem, not necessarily the time 
 _precision_.
 
 For example, a 64 bit representation can be made of 40 bits for seconds 
 spanning 34865 years, and 24 bits for fractional seconds providing 
 precision down to 60 nanosecs.  That ought to be plenty good on 32 bit 
 systems while still being cheap to handle.

I have checked earlier that we don't do any computation on inode
time stamps in common code, we just pass them around, so there is
very little runtime overhead. There is a small bit of space overhead
(12 byte) per inode, but that structure is already on the order of
500 bytes.

For other timekeeping stuff in the kernel, I agree that using some
64-bit representation (nanoseconds, 32/32 unsigned seconds/nanoseconds,
...) has advantages, that's exactly the point I was making earlier
against simply extending the internal time_t/timespec to 64-bit
seconds for everything.

Arnd

Re: [Cluster-devel] [RFC 00/32] making inode time stamps y2038 ready

2014-06-03 Thread Arnd Bergmann 
On Saturday 31 May 2014 18:30:49 Vyacheslav Dubeyko wrote:
 By the way, what about NILFS2? Is NILFS2 ready for suggested approach
 without any changes?

nilfs2 and a lot of other file systems don't need any changes for
this, because they don't assign the inode time stamp fields to
a 'struct timespec'.

FWIW, nilfs2 uses a 64-bit seconds value, which is always safe and
can represent the full range of user space timespec on all machines.

Arnd

Re: [Cluster-devel] [RFC 00/32] making inode time stamps y2038 ready

2014-06-03 Thread Arnd Bergmann 
On Monday 02 June 2014 14:57:26 H. Peter Anvin wrote:
 On 06/02/2014 12:55 PM, Arnd Bergmann wrote:
 
  The bit that is really going to hurt is every single ioctl that uses a
  timespec.
 
  Honestly, though, I really don't understand the point with struct
  inode_time.  It seems like the zeroeth-order thing is to change the
  kernel internal version of struct timespec to have a 64-bit time... it
  isn't just about inodes.  We then should be explicit about the external
  uses of time, and use accessors.
  
  I picked these because they are fairly isolated from all other uses,
  in particular since inode times are the only things where we really
  care about times in the distant past or future (decades away as opposed
  to things that happened between boot and shutdown).
  
 
 If nothing else, I would expect to be able to set the system time to
 weird values for testing.  So I'm not so sure I agree with that...

I think John Stultz and Thomas Gleixner have already started looking
at how the timekeeping code can be updated. Once that is done, we should
be able to add a functional 64-bit gettimeofday/settimeofday syscall
pair. While I definitely agree this is one of the most basic things to
have, it's also not an area of the kernel that is easy to change.

  For other kernel-internal uses, we may be better off migrating to
  a completely different representation, such as nanoseconds since
  boot or the architecture specific ktime_t, but this is really something
  to decide for each subsystem.
 
 Having a bunch of different time representations in the kernel seems
 like a real headache...

We already have time_t, ktime_t, timeval, timespec, compat_timespec,
clock_t, cputime_t, cputime64_t, tm, nanoseconds, jiffies, jiffies64,
and lots of driver or file system specific representations. I'm all for
removing a bunch of these from the kernel, but my feeling is that this is
one of the cases where we first have to add new ones in order to remove
those that are already there.
To complicate things further, we also have various times bases
(realtime/utc, realtime/tai, monotonic, monotonic_raw, boottime, ...),
and at least for the timespec values we pass around, it's not always
obvious which one is used, of if that's the right one.

We probably don't want to add a lot of new representations, and it's
possible that we can change most of the internal code we have to
ktime_t and then convert that to whatever user space wants at the
interfaces.

The possible uses I can see for non-ktime_t types in the kernel are:
* inodes need 96 bit timestamps to represent the full range of values
  that can be stored in a file system, you made a convincing argument
  for that. Almost everything else can fit into 64 bit on a 32-bit
  kernel, in theory also on a 64-bit kernel if we want that.
* A number of interfaces pass relative timespecs: nanosleep(), poll(),
  select(), sigtimedwait(), alarm(), futex() and probably more. There is
  nothing wrong with the use of timespec here, and it may be good to
  annotate that by using a new type (e.g. struct timeout) that is defined
  as compatible with the current timespec.
* For new user interfaces, we need a new type such as the
  __kernel_timespec64 I introduced, so it doesn't clash with the normal
  user timespec that may be smaller, depending on the libc.
* A lot of drivers will need new ioctl commands, and for drivers that
  just need time stamps (audio, v4l, sockets, ...) it may be more
  efficient and more correct to use a new timestamp_t (e.g. boot time
  64-bit nanoseconds) than __kernel_timespec64, which is not normally
  monotonic and requires a normalization step. If we end up introducing
  such a type in the user interface, we can also start using it in the
  kernel.

Arnd

Re: [Cluster-devel] [RFC 00/32] making inode time stamps y2038 ready

2014-06-03 Thread Arnd Bergmann 
On Tuesday 03 June 2014 14:33:10 Joseph S. Myers wrote:
 On Tue, 3 Jun 2014, Arnd Bergmann wrote:
 
  I think John Stultz and Thomas Gleixner have already started looking
  at how the timekeeping code can be updated. Once that is done, we should
  be able to add a functional 64-bit gettimeofday/settimeofday syscall
  pair. While I definitely agree this is one of the most basic things to
  have, it's also not an area of the kernel that is easy to change.
 
 64-bit clock_gettime / clock_settime instead of gettimeofday / 
 settimeofday should avoid the need for the kernel to have a 64-bit version 
 of struct timeval.  (Userspace 64-bit gettimeofday / settimeofday would 
 need to use a combination of the syscalls if the tz pointer is non-NULL.)

Yes, that's what I meant.

Arnd

Re: [Cluster-devel] [RFC 00/32] making inode time stamps y2038 ready

2014-06-02 Thread Arnd Bergmann 
On Monday 02 June 2014 13:52:19 Joseph S. Myers wrote:
 On Fri, 30 May 2014, Arnd Bergmann wrote:
 
  a) is this the right approach in general? The previous discussion
 pointed this way, but there may be other opinions.
 
 The syscall changes seem like the sort of thing I'd expect, although 
 patches adding new syscalls or otherwise affecting the kernel/userspace 
 interface (as opposed to those relating to an individual filesystem) 
 should go to linux-api as well as other relevant lists.

Ok. Sorry about missing linux-api, I confused it with linux-arch, which
may not be as relevant here, except for the one question whether we
actually want to have the new ABI on all 32-bit architectures or only
as an opt-in for those that expect to stay around for another 24 years.

Two more questions for you:

- are you (and others) happy with adding this type of stat syscall
  (fstatat64/fstat64) as opposed to the more generic xstat that has
  been discussed in the past and that never made it through the bike-
  shedding discussion?

- once we have enough buy-in from reviewers to merge this initial
  series, should we proceed to define rest of the syscall ABI
  (minus driver ioctls) so glibc and kernel can do the conversion
  on top of that, or should we better try to do things one syscall
  family at a time and actually get the kernel to handle them
  correctly internally?

Arnd

Re: [Cluster-devel] [RFC 00/32] making inode time stamps y2038 ready

2014-06-02 Thread Arnd Bergmann 
On Monday 02 June 2014 12:26:22 H. Peter Anvin wrote:
 On 06/02/2014 12:19 PM, Arnd Bergmann wrote:
  On Monday 02 June 2014 13:52:19 Joseph S. Myers wrote:
  On Fri, 30 May 2014, Arnd Bergmann wrote:
 
  a) is this the right approach in general? The previous discussion
 pointed this way, but there may be other opinions.
 
  The syscall changes seem like the sort of thing I'd expect, although 
  patches adding new syscalls or otherwise affecting the kernel/userspace 
  interface (as opposed to those relating to an individual filesystem) 
  should go to linux-api as well as other relevant lists.
  
  Ok. Sorry about missing linux-api, I confused it with linux-arch, which
  may not be as relevant here, except for the one question whether we
  actually want to have the new ABI on all 32-bit architectures or only
  as an opt-in for those that expect to stay around for another 24 years.
  
  Two more questions for you:
  
  - are you (and others) happy with adding this type of stat syscall
(fstatat64/fstat64) as opposed to the more generic xstat that has
been discussed in the past and that never made it through the bike-
shedding discussion?
  
  - once we have enough buy-in from reviewers to merge this initial
series, should we proceed to define rest of the syscall ABI
(minus driver ioctls) so glibc and kernel can do the conversion
on top of that, or should we better try to do things one syscall
family at a time and actually get the kernel to handle them
correctly internally?
  
 
 The bit that is really going to hurt is every single ioctl that uses a
 timespec.
 
 Honestly, though, I really don't understand the point with struct
 inode_time.  It seems like the zeroeth-order thing is to change the
 kernel internal version of struct timespec to have a 64-bit time... it
 isn't just about inodes.  We then should be explicit about the external
 uses of time, and use accessors.

I picked these because they are fairly isolated from all other uses,
in particular since inode times are the only things where we really
care about times in the distant past or future (decades away as opposed
to things that happened between boot and shutdown).

For other kernel-internal uses, we may be better off migrating to
a completely different representation, such as nanoseconds since
boot or the architecture specific ktime_t, but this is really something
to decide for each subsystem.

I just tried building an arm32 kernel with a s64 time_t, and that
failed horribly, I get linker errors for missing 64-bit divides
and lots of warnings for code that expects time_t pointers to
functions taking a 'long' or vice versa. I also think the only
way to maintain ABI compatibility is to separate the internal uses
from the interface, which means auditing all code in the end.

Arnd

Re: [Cluster-devel] [RFC 00/32] making inode time stamps y2038 ready

2014-05-31 Thread Arnd Bergmann 
On Saturday 31 May 2014 16:51:15 Richard Cochran wrote:
 On Fri, May 30, 2014 at 10:01:24PM +0200, Arnd Bergmann wrote:
  
  I picked this because it is a fairly isolated problem, as the
  inode time stamps are rarely assigned to any other time values.
  As a byproduct of this work, I documented for each of the file
  systems we support how long the on-disk format can work[1].
 
 Why are some of the time stamp expiration dates marked as never?

It's an approximation:
with 64-bit timestamps, you can represent close to 300 billion
years, which is way past the time that our planet can sustain
life of any form[1].

Arnd

[1] http://en.wikipedia.org/wiki/Timeline_of_the_far_future

[Cluster-devel] [RFC 25/32] gfs2: convert to struct inode_time

2014-05-30 Thread Arnd Bergmann 
gfs2 uses 64-bit integers for inode timestamps, which will work
basically forever, but the VFS uses struct timespec for timestamps,
which is only good until 2038 on 32-bit CPUs.

This gets us one small step closer to lifting the VFS limit by using
struct inode_time in gfs2.

Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Steven Whitehouse swhit...@redhat.com
Cc: cluster-devel@redhat.com
---
 fs/gfs2/dir.c   | 6 +++---
 fs/gfs2/glops.c | 4 ++--
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/fs/gfs2/dir.c b/fs/gfs2/dir.c
index 1a349f9..ec57538 100644
--- a/fs/gfs2/dir.c
+++ b/fs/gfs2/dir.c
@@ -835,7 +835,7 @@ static struct gfs2_leaf *new_leaf(struct inode *inode, 
struct buffer_head **pbh,
struct gfs2_leaf *leaf;
struct gfs2_dirent *dent;
struct qstr name = { .name =  };
-   struct timespec tv = CURRENT_TIME;
+   struct inode_time tv = CURRENT_TIME;
 
error = gfs2_alloc_blocks(ip, bn, n, 0, NULL);
if (error)
@@ -1716,7 +1716,7 @@ int gfs2_dir_add(struct inode *inode, const struct qstr 
*name,
struct gfs2_inode *ip = GFS2_I(inode);
struct buffer_head *bh = da-bh;
struct gfs2_dirent *dent = da-dent;
-   struct timespec tv;
+   struct inode_time tv;
struct gfs2_leaf *leaf;
int error;
 
@@ -1794,7 +1794,7 @@ int gfs2_dir_del(struct gfs2_inode *dip, const struct 
dentry *dentry)
const struct qstr *name = dentry-d_name;
struct gfs2_dirent *dent, *prev = NULL;
struct buffer_head *bh;
-   struct timespec tv = CURRENT_TIME;
+   struct inode_time tv = CURRENT_TIME;
 
/* Returns _either_ the entry (if its first in block) or the
   previous entry otherwise */
diff --git a/fs/gfs2/glops.c b/fs/gfs2/glops.c
index fc11007..b55308f 100644
--- a/fs/gfs2/glops.c
+++ b/fs/gfs2/glops.c
@@ -318,7 +318,7 @@ static void gfs2_set_nlink(struct inode *inode, u32 nlink)
 static int gfs2_dinode_in(struct gfs2_inode *ip, const void *buf)
 {
const struct gfs2_dinode *str = buf;
-   struct timespec atime;
+   struct inode_time atime;
u16 height, depth;
 
if (unlikely(ip-i_no_addr != be64_to_cpu(str-di_num.no_addr)))
@@ -341,7 +341,7 @@ static int gfs2_dinode_in(struct gfs2_inode *ip, const void 
*buf)
gfs2_set_inode_blocks(ip-i_inode, be64_to_cpu(str-di_blocks));
atime.tv_sec = be64_to_cpu(str-di_atime);
atime.tv_nsec = be32_to_cpu(str-di_atime_nsec);
-   if (timespec_compare(ip-i_inode.i_atime, atime)  0)
+   if (inode_time_compare(ip-i_inode.i_atime, atime)  0)
ip-i_inode.i_atime = atime;
ip-i_inode.i_mtime.tv_sec = be64_to_cpu(str-di_mtime);
ip-i_inode.i_mtime.tv_nsec = be32_to_cpu(str-di_mtime_nsec);
-- 
1.8.3.2

[Cluster-devel] [RFC 00/32] making inode time stamps y2038 ready

2014-05-30 Thread Arnd Bergmann 
Based on the recent discussion about 64-bit time_t for new
architectures, and for solving the year 2038 problem in general,
I decided to try out what it would take to solve part of the
kernel side of things.

This is a proof-of-concept work to get us to the point where
two system calls (utimes and stat) provide a working interface
to user space to pass 64-bit inode time stamps in and out of
the kernel all the way to the file systems.

I picked this because it is a fairly isolated problem, as the
inode time stamps are rarely assigned to any other time values.
As a byproduct of this work, I documented for each of the file
systems we support how long the on-disk format can work[1].

Obviously we also need to convert all the other syscalls and
have a proper libc implementation using those for this to
be really useful, but it's a start and it can be tested
independently (I didn't so far, want to wait for initial
feedback).

All the interesting stuff is in the first five patches here,
the rest is the straightforward conversion of all file systems
that use 'timespec' values internally.

There are of course a number of open questions:

a) is this the right approach in general? The previous discussion
   pointed this way, but there may be other opinions.
b) what type should we use internally to represent inode time
   stamps? The code contains three different versions that would
   all work, we just have to pick a good tradeoff between
   efficiency and the range of times we want to cover.
c) Should we continue this way for all 32-bit platforms for
   consistency, including future ones, or should we go to
   different 64-bit types right away? My feeling is that the
   second approach would complicate this work.

Arnd

[1] http://kernelnewbies.org/y2038

Arnd Bergmann (32):
  fs: introduce new 'struct inode_time'
  uapi: add struct __kernel_timespec{32,64}
  fs: introduce sys_utimens64at
  fs: introduce sys_newfstat64/sys_newfstatat64
  arch: hook up new stat and utimes syscalls
  isofs: fix timestamps beyond 2027
  fs/nfs: convert to struct inode_time
  fs/ceph: convert to 'struct inode_time'
  fs/pstore: convert to struct inode_time
  fs/coda: convert to struct inode_time
  xfs: convert to struct inode_time
  btrfs: convert to struct inode_time
  ext3: convert to struct inode_time
  ext4: convert to struct inode_time
  cifs: convert to struct inode_time
  ntfs: convert to struct inode_time
  ubifs: convert to struct inode_time
  ocfs2: convert to struct inode_time
  fs/fat: convert to struct inode_time
  afs: convert to struct inode_time
  udf: convert to struct inode_time
  fs: convert simple fs to inode_time
  logfs: convert to struct inode_time
  hfs, hfsplus: convert to struct inode_time
  gfs2: convert to struct inode_time
  reiserfs: convert to struct inode_time
  jffs2: convert to struct inode_time
  adfs: convert to struct inode_time
  f2fs: convert to struct inode_time
  fuse: convert to struct inode_time
  scsi: fnic: use current_kernel_time() for timestamp
  fs: use new inode_time definition unconditionally

 arch/alpha/kernel/osf_sys.c|  2 +-
 arch/arm/include/asm/unistd.h  |  2 +-
 arch/arm/include/uapi/asm/stat.h   | 25 +
 arch/arm/include/uapi/asm/unistd.h |  3 +++
 arch/arm/kernel/calls.S|  3 +++
 arch/arm64/include/asm/unistd32.h  |  5 +++-
 arch/x86/include/uapi/asm/stat.h   | 28 +++
 arch/x86/syscalls/syscall_32.tbl   |  3 +++
 drivers/block/rbd.c|  2 +-
 drivers/firmware/efi/efi-pstore.c  | 28 +--
 drivers/scsi/fnic/fnic_trace.c |  2 +-
 drivers/tty/tty_io.c   |  2 +-
 drivers/usb/gadget/f_fs.c  |  2 +-
 fs/adfs/inode.c|  4 +--
 fs/afs/afs.h   |  6 ++---
 fs/afs/fsclient.c  |  2 +-
 fs/attr.c  |  8 +++---
 fs/btrfs/file.c|  6 ++---
 fs/btrfs/inode.c   |  4 +--
 fs/btrfs/ioctl.c   |  4 +--
 fs/btrfs/root-tree.c   |  2 +-
 fs/btrfs/transaction.c |  2 +-
 fs/ceph/cache.c|  2 +-
 fs/ceph/caps.c |  6 ++---
 fs/ceph/file.c |  4 +--
 fs/ceph/inode.c| 20 +++---
 fs/ceph/super.h|  8 +++---
 fs/cifs/cache.c|  6 ++---
 fs/cifs/cifsglob.h |  6 ++---
 fs/cifs/cifsproto.h|  6 ++---
 fs/cifs/cifssmb.c  |  5 ++--
 fs/cifs/inode.c|  2 +-
 fs/cifs/netmisc.c  | 15 ++-
 fs/coda/coda_linux.c   | 18 -
 fs/compat.c| 19 ++---
 fs/configfs/inode.c|  6 ++---
 fs/cramfs/inode.c  |  2 +-
 fs/ext3/inode.c|  4 +--
 fs/ext4/ext4.h | 10 +++
 fs/ext4/extents.c  |  2 +-
 fs/f2fs/file.c