1. 21 10月, 2018 11 次提交
  2. 30 9月, 2018 2 次提交
  3. 21 9月, 2018 5 次提交
    • J
      ocfs2: fix ocfs2 read block panic · 234b69e3
      Junxiao Bi 提交于
      While reading block, it is possible that io error return due to underlying
      storage issue, in this case, BH_NeedsValidate was left in the buffer head.
      Then when reading the very block next time, if it was already linked into
      journal, that will trigger the following panic.
      
      [203748.702517] kernel BUG at fs/ocfs2/buffer_head_io.c:342!
      [203748.702533] invalid opcode: 0000 [#1] SMP
      [203748.702561] Modules linked in: ocfs2 ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs sunrpc dm_switch dm_queue_length dm_multipath bonding be2iscsi iscsi_boot_sysfs bnx2i cnic uio cxgb4i iw_cxgb4 cxgb4 cxgb3i libcxgbi iw_cxgb3 cxgb3 mdio ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr ipv6 iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ipmi_devintf iTCO_wdt iTCO_vendor_support dcdbas ipmi_ssif i2c_core ipmi_si ipmi_msghandler acpi_pad pcspkr sb_edac edac_core lpc_ich mfd_core shpchp sg tg3 ptp pps_core ext4 jbd2 mbcache2 sr_mod cdrom sd_mod ahci libahci megaraid_sas wmi dm_mirror dm_region_hash dm_log dm_mod
      [203748.703024] CPU: 7 PID: 38369 Comm: touch Not tainted 4.1.12-124.18.6.el6uek.x86_64 #2
      [203748.703045] Hardware name: Dell Inc. PowerEdge R620/0PXXHP, BIOS 2.5.2 01/28/2015
      [203748.703067] task: ffff880768139c00 ti: ffff88006ff48000 task.ti: ffff88006ff48000
      [203748.703088] RIP: 0010:[<ffffffffa05e9f09>]  [<ffffffffa05e9f09>] ocfs2_read_blocks+0x669/0x7f0 [ocfs2]
      [203748.703130] RSP: 0018:ffff88006ff4b818  EFLAGS: 00010206
      [203748.703389] RAX: 0000000008620029 RBX: ffff88006ff4b910 RCX: 0000000000000000
      [203748.703885] RDX: 0000000000000001 RSI: 0000000000000000 RDI: 00000000023079fe
      [203748.704382] RBP: ffff88006ff4b8d8 R08: 0000000000000000 R09: ffff8807578c25b0
      [203748.704877] R10: 000000000f637376 R11: 000000003030322e R12: 0000000000000000
      [203748.705373] R13: ffff88006ff4b910 R14: ffff880732fe38f0 R15: 0000000000000000
      [203748.705871] FS:  00007f401992c700(0000) GS:ffff880bfebc0000(0000) knlGS:0000000000000000
      [203748.706370] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [203748.706627] CR2: 00007f4019252440 CR3: 00000000a621e000 CR4: 0000000000060670
      [203748.707124] Stack:
      [203748.707371]  ffff88006ff4b828 ffffffffa0609f52 ffff88006ff4b838 0000000000000001
      [203748.707885]  0000000000000000 0000000000000000 ffff880bf67c3800 ffffffffa05eca00
      [203748.708399]  00000000023079ff ffffffff81c58b80 0000000000000000 0000000000000000
      [203748.708915] Call Trace:
      [203748.709175]  [<ffffffffa0609f52>] ? ocfs2_inode_cache_io_unlock+0x12/0x20 [ocfs2]
      [203748.709680]  [<ffffffffa05eca00>] ? ocfs2_empty_dir_filldir+0x80/0x80 [ocfs2]
      [203748.710185]  [<ffffffffa05ec0cb>] ocfs2_read_dir_block_direct+0x3b/0x200 [ocfs2]
      [203748.710691]  [<ffffffffa05f0fbf>] ocfs2_prepare_dx_dir_for_insert.isra.57+0x19f/0xf60 [ocfs2]
      [203748.711204]  [<ffffffffa065660f>] ? ocfs2_metadata_cache_io_unlock+0x1f/0x30 [ocfs2]
      [203748.711716]  [<ffffffffa05f4f3a>] ocfs2_prepare_dir_for_insert+0x13a/0x890 [ocfs2]
      [203748.712227]  [<ffffffffa05f442e>] ? ocfs2_check_dir_for_entry+0x8e/0x140 [ocfs2]
      [203748.712737]  [<ffffffffa061b2f2>] ocfs2_mknod+0x4b2/0x1370 [ocfs2]
      [203748.713003]  [<ffffffffa061c385>] ocfs2_create+0x65/0x170 [ocfs2]
      [203748.713263]  [<ffffffff8121714b>] vfs_create+0xdb/0x150
      [203748.713518]  [<ffffffff8121b225>] do_last+0x815/0x1210
      [203748.713772]  [<ffffffff812192e9>] ? path_init+0xb9/0x450
      [203748.714123]  [<ffffffff8121bca0>] path_openat+0x80/0x600
      [203748.714378]  [<ffffffff811bcd45>] ? handle_pte_fault+0xd15/0x1620
      [203748.714634]  [<ffffffff8121d7ba>] do_filp_open+0x3a/0xb0
      [203748.714888]  [<ffffffff8122a767>] ? __alloc_fd+0xa7/0x130
      [203748.715143]  [<ffffffff81209ffc>] do_sys_open+0x12c/0x220
      [203748.715403]  [<ffffffff81026ddb>] ? syscall_trace_enter_phase1+0x11b/0x180
      [203748.715668]  [<ffffffff816f0c9f>] ? system_call_after_swapgs+0xe9/0x190
      [203748.715928]  [<ffffffff8120a10e>] SyS_open+0x1e/0x20
      [203748.716184]  [<ffffffff816f0d5e>] system_call_fastpath+0x18/0xd7
      [203748.716440] Code: 00 00 48 8b 7b 08 48 83 c3 10 45 89 f8 44 89 e1 44 89 f2 4c 89 ee e8 07 06 11 e1 48 8b 03 48 85 c0 75 df 8b 5d c8 e9 4d fa ff ff <0f> 0b 48 8b 7d a0 e8 dc c6 06 00 48 b8 00 00 00 00 00 00 00 10
      [203748.717505] RIP  [<ffffffffa05e9f09>] ocfs2_read_blocks+0x669/0x7f0 [ocfs2]
      [203748.717775]  RSP <ffff88006ff4b818>
      
      Joesph ever reported a similar panic.
      Link: https://oss.oracle.com/pipermail/ocfs2-devel/2013-May/008931.html
      
      Link: http://lkml.kernel.org/r/20180912063207.29484-1-junxiao.bi@oracle.comSigned-off-by: NJunxiao Bi <junxiao.bi@oracle.com>
      Cc: Joseph Qi <jiangqi903@gmail.com>
      Cc: Mark Fasheh <mark@fasheh.com>
      Cc: Joel Becker <jlbec@evilplan.org>
      Cc: Changwei Ge <ge.changwei@h3c.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      234b69e3
    • D
      fs/proc/kcore.c: fix invalid memory access in multi-page read optimization · a1b3d2f2
      Dominique Martinet 提交于
      The 'm' kcore_list item could point to kclist_head, and it is incorrect to
      look at m->addr / m->size in this case.
      
      There is no choice but to run through the list of entries for every
      address if we did not find any entry in the previous iteration
      
      Reset 'm' to NULL in that case at Omar Sandoval's suggestion.
      
      [akpm@linux-foundation.org: add comment]
      Link: http://lkml.kernel.org/r/1536100702-28706-1-git-send-email-asmadeus@codewreck.org
      Fixes: bf991c22 ("proc/kcore: optimize multiple page reads")
      Signed-off-by: NDominique Martinet <asmadeus@codewreck.org>
      Reviewed-by: NAndrew Morton <akpm@linux-foundation.org>
      Cc: Omar Sandoval <osandov@osandov.com>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Cc: Eric Biederman <ebiederm@xmission.com>
      Cc: James Morse <james.morse@arm.com>
      Cc: Bhupesh Sharma <bhsharma@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a1b3d2f2
    • R
      Revert "ubifs: xattr: Don't operate on deleted inodes" · f061c1cc
      Richard Weinberger 提交于
      This reverts commit 11a6fc3d.
      UBIFS wants to assert that xattr operations are only issued on files
      with positive link count. The said patch made this operations return
      -ENOENT for unlinked files such that the asserts will no longer trigger.
      This was wrong since xattr operations are perfectly fine on unlinked
      files.
      Instead the assertions need to be fixed/removed.
      
      Cc: <stable@vger.kernel.org>
      Fixes: 11a6fc3d ("ubifs: xattr: Don't operate on deleted inodes")
      Reported-by: NKoen Vandeputte <koen.vandeputte@ncentric.com>
      Tested-by: NJoel Stanley <joel@jms.id.au>
      Signed-off-by: NRichard Weinberger <richard@nod.at>
      f061c1cc
    • S
      ubifs: drop false positive assertion · d3bdc016
      Sascha Hauer 提交于
      The following sequence triggers
      
      	ubifs_assert(c, c->lst.taken_empty_lebs > 0);
      
      at the end of ubifs_remount_fs():
      
      mount -t ubifs /dev/ubi0_0 /mnt
      echo 1 > /sys/kernel/debug/ubifs/ubi0_0/ro_error
      umount /mnt
      mount -t ubifs -o ro /dev/ubix_y /mnt
      mount -o remount,ro /mnt
      
      The resulting
      
      UBIFS assert failed in ubifs_remount_fs at 1878 (pid 161)
      
      is a false positive. In the case above c->lst.taken_empty_lebs has
      never been changed from its initial zero value. This will only happen
      when the deferred recovery is done.
      
      Fix this by doing the assertion only when recovery has been done
      already.
      Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
      Signed-off-by: NRichard Weinberger <richard@nod.at>
      d3bdc016
    • R
      ubifs: Check for name being NULL while mounting · 37f31b6c
      Richard Weinberger 提交于
      The requested device name can be NULL or an empty string.
      Check for that and refuse to continue. UBIFS has to do this manually
      since we cannot use mount_bdev(), which checks for this condition.
      
      Fixes: 1e51764a ("UBIFS: add new flash file system")
      Reported-by: syzbot+38bd0f7865e5c6379280@syzkaller.appspotmail.com
      Signed-off-by: NRichard Weinberger <richard@nod.at>
      37f31b6c
  4. 19 9月, 2018 1 次提交
    • T
      ext2, dax: set ext2_dax_aops for dax files · 9e796c9d
      Toshi Kani 提交于
      Sync syscall to DAX file needs to flush processor cache, but it
      currently does not flush to existing DAX files.  This is because
      'ext2_da_aops' is set to address_space_operations of existing DAX
      files, instead of 'ext2_dax_aops', since S_DAX flag is set after
      ext2_set_aops() in the open path.
      
      Similar to ext4, change ext2_iget() to initialize i_flags before
      ext2_set_aops().
      
      Fixes: fb094c90 ("ext2, dax: introduce ext2_dax_aops")
      Signed-off-by: NToshi Kani <toshi.kani@hpe.com>
      Suggested-by: NJan Kara <jack@suse.cz>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: "Theodore Ts'o" <tytso@mit.edu>
      Cc: Andreas Dilger <adilger.kernel@dilger.ca>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NJan Kara <jack@suse.cz>
      9e796c9d
  5. 16 9月, 2018 4 次提交
  6. 15 9月, 2018 5 次提交
  7. 14 9月, 2018 1 次提交
    • B
      pstore: Fix incorrect persistent ram buffer mapping · 831b624d
      Bin Yang 提交于
      persistent_ram_vmap() returns the page start vaddr.
      persistent_ram_iomap() supports non-page-aligned mapping.
      
      persistent_ram_buffer_map() always adds offset-in-page to the vaddr
      returned from these two functions, which causes incorrect mapping of
      non-page-aligned persistent ram buffer.
      
      By default ftrace_size is 4096 and max_ftrace_cnt is nr_cpu_ids. Without
      this patch, the zone_sz in ramoops_init_przs() is 4096/nr_cpu_ids which
      might not be page aligned. If the offset-in-page > 2048, the vaddr will be
      in next page. If the next page is not mapped, it will cause kernel panic:
      
      [    0.074231] BUG: unable to handle kernel paging request at ffffa19e0081b000
      ...
      [    0.075000] RIP: 0010:persistent_ram_new+0x1f8/0x39f
      ...
      [    0.075000] Call Trace:
      [    0.075000]  ramoops_init_przs.part.10.constprop.15+0x105/0x260
      [    0.075000]  ramoops_probe+0x232/0x3a0
      [    0.075000]  platform_drv_probe+0x3e/0xa0
      [    0.075000]  driver_probe_device+0x2cd/0x400
      [    0.075000]  __driver_attach+0xe4/0x110
      [    0.075000]  ? driver_probe_device+0x400/0x400
      [    0.075000]  bus_for_each_dev+0x70/0xa0
      [    0.075000]  driver_attach+0x1e/0x20
      [    0.075000]  bus_add_driver+0x159/0x230
      [    0.075000]  ? do_early_param+0x95/0x95
      [    0.075000]  driver_register+0x70/0xc0
      [    0.075000]  ? init_pstore_fs+0x4d/0x4d
      [    0.075000]  __platform_driver_register+0x36/0x40
      [    0.075000]  ramoops_init+0x12f/0x131
      [    0.075000]  do_one_initcall+0x4d/0x12c
      [    0.075000]  ? do_early_param+0x95/0x95
      [    0.075000]  kernel_init_freeable+0x19b/0x222
      [    0.075000]  ? rest_init+0xbb/0xbb
      [    0.075000]  kernel_init+0xe/0xfc
      [    0.075000]  ret_from_fork+0x3a/0x50
      Signed-off-by: NBin Yang <bin.yang@intel.com>
      [kees: add comments describing the mapping differences, updated commit log]
      Fixes: 24c3d2f3 ("staging: android: persistent_ram: Make it possible to use memory outside of bootmem")
      Cc: stable@vger.kernel.org
      Signed-off-by: NKees Cook <keescook@chromium.org>
      831b624d
  8. 13 9月, 2018 1 次提交
  9. 12 9月, 2018 5 次提交
  10. 10 9月, 2018 1 次提交
  11. 09 9月, 2018 2 次提交
  12. 08 9月, 2018 1 次提交
    • D
      afs: Fix cell specification to permit an empty address list · ecfe951f
      David Howells 提交于
      Fix the cell specification mechanism to allow cells to be pre-created
      without having to specify at least one address (the addresses will be
      upcalled for).
      
      This allows the cell information preload service to avoid the need to issue
      loads of DNS lookups during boot to get the addresses for each cell (500+
      lookups for the 'standard' cell list[*]).  The lookups can be done later as
      each cell is accessed through the filesystem.
      
      Also remove the print statement that prints a line every time a new cell is
      added.
      
      [*] There are 144 cells in the list.  Each cell is first looked up for an
          SRV record, and if that fails, for an AFSDB record.  These get a list
          of server names, each of which then has to be looked up to get the
          addresses for that server.  E.g.:
      
      	dig srv _afs3-vlserver._udp.grand.central.org
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ecfe951f
  13. 06 9月, 2018 1 次提交